Messages in this thread | | | Date | Tue, 23 Jun 2020 14:52:01 +0200 | From | Peter Zijlstra <> | Subject | Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace) |
| |
On Tue, Jun 23, 2020 at 02:04:33PM +0200, Joerg Roedel wrote: > On Tue, Jun 23, 2020 at 01:48:18PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 23, 2020 at 01:30:07PM +0200, Joerg Roedel wrote: > > > But you cannot do a recursion check in #VC, because the NMI can happen > > on the first instruction of #VC, before we can increment our counter, > > and then the #VC can happen on NMI because the IST stack is a goner, and > > we're fscked again (or on a per-cpu variable we touch in our elaborate > > NMI setup, etc..). > > No, the recursion check is fine, because overwriting an already used IST > stack doesn't matter (as long as it can be detected) if we are going to > panic anyway. It doesn't matter because the kernel will not leave the > currently running handler anymore.
You only have that guarantee when any SNP #VC from kernel is an automatic panic. But in that case, what's the point of having the recursion count?
> > I'll keep repeating this, x86_64 exceptions are a trainwreck, and IST in > > specific is utter crap. > > I agree, but don't forget the most prominent underlying reason for IST: > The SYSCALL gap. If SYSCALL would switch stacks most of those issues > would not exist. IST would still be needed because there are no task > gates in x86-64, but still...
We could all go back to int80 ;-) /me runs like heck
| |