Messages in this thread | | | Date | Fri, 18 Mar 2022 18:34:54 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv6 07/30] x86/traps: Add #VE support for TDX guest |
| |
On Fri, Mar 18, 2022 at 03:19:34PM +0100, Thomas Gleixner wrote: > On Thu, Mar 17 2022 at 21:21, Peter Zijlstra wrote: > > On Thu, Mar 17, 2022 at 08:33:54PM +0300, Kirill A. Shutemov wrote: > >> - in NMI entry code (asm_exc_nmi()) before NMI nesting is safe: > >> + for NMI from user mode, before switched to thread stack > >> + for NMI from kernel, up to end_repead_nmi > >> > >> After that points #VE is safe. > > > > In what way is it guaranteed that #VE isn't raised in those places? What > > does an auditor / future coder looking to changes things, need to > > consider to keep this so. > > > > From vague memories #VE can be raised on any memop, loading the stack > > address in the syscall-gap is a memop. What makes that special? Can we > > get a comment _there_ to explain how this is safe such that we can keep > > it so? > > > > Same for the NMI path I suppose. > > #VE is raised by HLT, CPUID, I/O-Port access, MSR read/write, EPT violations > > So in the hairy places: > > - HLT: No business > - I/O Ports: That would be outright stupid to use > > - CPUID: Should never be used - Emphasis on should :) > - MSRs: Same as CPUID > > - EPT: Well....
EPT violation may result in #VE only on shared memory. If entry code touches shared memory we have a bigger problem than syscall gap.
-- Kirill A. Shutemov
| |