Messages in this thread | | | Date | Wed, 29 Dec 2021 17:07:34 +0000 | From | Sean Christopherson <> | Subject | Re: [PATCH 04/26] x86/traps: Add #VE support for TDX guest |
| |
On Wed, Dec 29, 2021, Borislav Petkov wrote: > On Wed, Dec 29, 2021 at 02:31:12AM +0300, Kirill A. Shutemov wrote: > What I read is: > > "Interrupts, including NMIs, are blocked by the hardware starting with > #VE delivery until TDGETVEINFO is called."
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.
> but this simply means that *if* you get a #VE anywhere, NMIs are masked > until TDGETVEINFO.
Yep.
> If you get a #VE during the NMI entry code, then you're toast...
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).
| |