Messages in this thread |  | | Date | Mon, 8 Feb 2021 17:33:06 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC v1 05/26] x86/traps: Add #VE support for TDX guest |
| |
On Mon, Feb 08, 2021 at 08:23:01AM -0800, Andi Kleen wrote: > > Which is supposedly then set up to avoid #VE during the syscall gap, > > yes? Which then results in #VE not having to be IST. > > Yes that is currently true because all memory is pre-accepted. > > If we ever do lazy accept we would need to make sure the memory accessed in > the syscall gap is already accepted, or move over to an IST.
I think we're going to mandate the entry text/data will have to be pre-accepted to avoid IST. ISTs really are crap.
> > > +#ifdef CONFIG_INTEL_TDX_GUEST > > > +DEFINE_IDTENTRY(exc_virtualization_exception) > > > +{ > > > + struct ve_info ve; > > > + int ret; > > > + > > > + RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU"); > > > + > > > + /* Consume #VE info before re-enabling interrupts */ > > > > So what happens if NMI happens here, and triggers a nested #VE ? > > Yes that's a gap. We should probably bail out and reexecute the original > instruction. The VE handler would need to set a flag for that. > > Or alternatively the NMI always gets the VE information and puts > it on some internal stack, but that would seem clunkier.
The same is possible with MCE and #DB I imagine.
|  |