> 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 >
On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote:> 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.Right, I dealt with that by unconditionally shifting/unshifting the #VC IST entry in do_nmi() (thanks to Davin Kaplan for the idea). It might cause one of the IST stacks to be unused during nesting, but that is fine. The stack memory for #VC is only allocated when SEV-ES is active (in an SEV-ES VM). Regards, Joerg
On Sat, Apr 25, 2020 at 1:23 PM Joerg Roedel <joro at 8bytes.org> wrote:> > On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote: > > 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. > > Right, I dealt with that by unconditionally shifting/unshifting the #VC IST entry > in do_nmi() (thanks to Davin Kaplan for the idea). It might cause > one of the IST stacks to be unused during nesting, but that is fine. The > stack memory for #VC is only allocated when SEV-ES is active (in an > SEV-ES VM).Blech. It probably works, but still, yuck. It's a bit sad that we seem to be growing more and more poorly designed happens-anywhere exception types at an alarming rate. We seem to have #NM, #MC, #VC, #HV, and #DB. This doesn't really scale. --Andy
Possibly Parallel Threads
- [PATCH] Allow RDTSC and RDTSCP from userspace
- [PATCH] Allow RDTSC and RDTSCP from userspace
- Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)
- Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)
- Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)