Re: [RFC v2 08/32] x86/traps: Add #VE support for TDX guest

[Andi Kleen]

On 5/7/2021 2:36 PM, Dave Hansen wrote:
> On 4/26/21 11:01 AM, Kuppuswamy Sathyanarayanan wrote:
> ...
> > The #VE cannot be nested before TDGETVEINFO is called, if there is any
> > reason for it to nest the TD would shut down. The TDX module guarantees
> > that no NMIs (or #MC or similar) can happen in this window. After
> > TDGETVEINFO the #VE handler can nest if needed, although we don’t expect
> > it to happen normally.
> I think this description really needs some work.  Does "The #VE cannot
> be nested" mean that "hardware guarantees that #VE will not be
> generated", or "the #VE must not be nested"?

The next half sentence answers this question..

"if there is any reason for it to nest the TD would shut down."

So it cannot nest.


> What does "the TD would shut down" mean?  I think you mean that instead
> of delivering a nested #VE the hardware would actually exit to the host
> and TDX would prevent the guest from being reentered.  Right?


Yes that's a shutdown. I Suppose we could add your sentence.


> I find that description a bit unsatisfying.  Could we make this a bit
> more concrete?


I don't see what could be added. If you have concrete suggestions please 
just propose something.


>   By the way, what about *normal* interrupts?


Normal interrupts are blocked of course like in every other exception or 
interrupt entry.

> Maybe we should talk about this in terms of *rules* that folks need to
> follow.  Maybe:
>
> 	NMIs and machine checks are suppressed.  Before this point any
> 	#VE is fatal.  After this point, NMIs and additional #VEs are
> 	permitted.

Okay that's fine for me.


-Andi