Messages in this thread | | | Subject | Re: [RFC v2 08/32] x86/traps: Add #VE support for TDX guest | From | Andi Kleen <> | Date | Thu, 13 May 2021 12:47:04 -0700 |
| |
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
| |