Messages in this thread | | | Subject | Re: [PATCH 04/26] x86/traps: Add #VE support for TDX guest | From | Dave Hansen <> | Date | Wed, 29 Dec 2021 10:42:38 -0800 |
| |
On 12/28/21 3:31 PM, Kirill A. Shutemov wrote: > 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. ... > The situation is similar to NMIs vs. breakpoints.
Or page faults for that matter.
Page faults are architecturally permitted to occur in the NMI entry path. But, there's no facility to handle them. The kernel (mostly easily) avoids doing things that might cause page faults in the NMI entry path.
The same goes for #VE's in the same path. A guest is written to avoid #VE in the NMI entry. If they happen in that path, there's a bug somewhere.
I wouldn't go as far as to say "#VE cannot possibly happen there (NMI entry code)". They *CAN* happen there, but the kernel is doing everything it can to avoid them.
| |