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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
