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

[Kirill A. Shutemov]

On Thu, Dec 23, 2021 at 08:45:40PM +0100, Borislav Petkov wrote:
> What happens if the NMI handler triggers a #VE after all? Or where is it
> enforced that TDX guests should set panic_on_oops?

Kernel will handle the #VE normally inside NMI handler. (We tested it once
again, just in case.)

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

#VE cannot possibly happen there: no #VE-inducing instructions, code and
data are in guest private memory.

VMM can remove private memory from under us, but access to unaccepted (or
missing) private memory leads to VM termination, not to #VE.

The situation is similar to NMIs vs. breakpoints.

> > + * be handled.
> > + *
> > + * For dis-allowed or invalid #VE just return failure.
> > + *
> > + * Return True on success and False on failure.
> 
> You lost me here - function returns false unconditionally. And that
> bla about CPUID from user being a valid case doesn't really look like
> one when I look at the code. Especially since ve_raise_fault() sends a
> SIGSEGV for user #VEs.

tdx_virt_exception_user()/tdx_virt_exception_kernel() will be populated by
following patches. The patch adds generic infrastructure for #VE handling.

-- 
 Kirill A. Shutemov