lkml.org 
[lkml]   [2021]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC v2 08/32] x86/traps: Add #VE support for TDX guest
From
Date

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



\
 
 \ /
  Last update: 2021-05-13 21:48    [W:0.237 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site