Re: [PATCH 04/26] x86/traps: Add #VE support for TDX guest

[Borislav Petkov <bp@alien8.de>]

On Wed, Dec 29, 2021 at 05:07:34PM +0000, Sean Christopherson wrote:
> FWIW, virtual/guest NMIs are blocked by the TDX module until pending #VE info
> is retrieved via TDGETVEINFO.  Hardware has nothing to do with that behavior.

The TDX module can block NMIs?! Can we get that functionality exported
to baremetal too pls? Then we can get rid of the NMI nesting crap.

> Yes?  The rules would be the same as whatever existing rules we have for taking
> #DBs in NMI, but that's because the subsequent IRET unblocking NMIs, not because
> there's anything special about #VE.  Pending NMIs are blocked by the regular NMI
> status (unblocked by IRET) _and_ by an unread #VE info.
> 
> The unread #VE info clause in NMI blocking is purely to prevent an NMI from being
> injected before the guest's #VE handler can do TDGETVEINFO, otherwise a #VE at
> _any_ point in the NMI handler would be fatal due to it clobbering the unread #VE
> info (it'd be a similar problem to SEV-ES's GHCB juggling).

I guess this is what Kirill means with:

"The critical part is that #VE must not be triggered in NMI entry code,
before kernel is ready to handle nested NMIs."

I read that as "you die if you get it then" but it sounds like it is
"it'll overwrite #VE info and you'll probably die eventually." Or so.

Yeah, so this commit message text - and I actually think that this is
much more important than to put just in a commit message - so this text
would need a lot more scrubbing and put somewhere - maybe over the #VE
handler - and explain what the situation is wrt NMIs and #VEs. And those
formulations about a TDX guest expecting stuff to be a certain way are
just silly.

TDX guest either enforces them or throws hands in the air and does not
boot.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette