On Sat, Apr 25, 2020 at 5:49 AM Joerg Roedel <jroedel at suse.de> wrote:> > Hi Dave, > > On Fri, Apr 24, 2020 at 03:53:09PM -0700, Dave Hansen wrote: > > Ahh, so any instruction that can have an instruction intercept set > > potentially needs to be able to tolerate a #VC? Those instruction > > intercepts are under the control of the (untrusted relative to the > > guest) hypervisor, right? > > > > >From the main sev-es series: > > > > +#ifdef CONFIG_AMD_MEM_ENCRYPT > > +idtentry vmm_communication do_vmm_communication has_error_code=1 > > +#endif > > The next version of the patch-set (which I will hopefully have ready > next week) will have this changed. The #VC exception handler uses an IST > stack and is set to paranoid=1 and shift_ist. The IST stacks for the #VC > handler are only allocated when SEV-ES is active.shift_ist is gross. What's it for? If it's not needed, I'd rather not use it, and I eventually want to get rid of it for #DB as well. --Andy
On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote:> shift_ist is gross. What's it for? If it's not needed, I'd rather > not use it, and I eventually want to get rid of it for #DB as well.The #VC handler needs to be able to nest, there is no way around that for various reasons, the two most important ones are: 1. The #VC -> NMI -> #VC case. #VCs can happen in the NMI handler, for example (but not exclusivly) for RDPMC. 2. In case of an error the #VC handler needs to print out error information by calling one of the printk wrappers. Those will end up doing IO to some console/serial port/whatever which will also cause #VC exceptions to emulate the access to the output devices. Using shift_ist is perfect for that, the only problem is the race condition with the NMI handler, as shift_ist does not work well with exceptions that can also trigger within the NMI handler. But I have taken care of that for #VC. Regards, Joerg
> On Apr 25, 2020, at 12:10 PM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: >> shift_ist is gross. What's it for? If it's not needed, I'd rather >> not use it, and I eventually want to get rid of it for #DB as well. > > The #VC handler needs to be able to nest, there is no way around that > for various reasons, the two most important ones are: > > 1. The #VC -> NMI -> #VC case. #VCs can happen in the NMI > handler, for example (but not exclusivly) for RDPMC. > > 2. In case of an error the #VC handler needs to print out error > information by calling one of the printk wrappers. Those will > end up doing IO to some console/serial port/whatever which > will also cause #VC exceptions to emulate the access to the > output devices. > > Using shift_ist is perfect for that, the only problem is the race > condition with the NMI handler, as shift_ist does not work well with > exceptions that can also trigger within the NMI handler. But I have > taken care of that for #VC. >I assume the race you mean is: #VC Immediate NMI before IST gets shifted #VC Kaboom. How are you dealing with this? Ultimately, I think that NMI will need to turn off IST before engaging in any funny business. Let me ponder this a bit.> > Regards, > > Joerg >