On Tue, Jun 23, 2020 at 01:11:07PM +0200, Joerg Roedel wrote: > Hi Peter, > > On Tue, Jun 23, 2020 at 12:45:59PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 23, 2020 at 11:45:19AM +0200, Joerg Roedel wrote: > > > Or maybe you have a better idea how to implement this, so I'd like to > > > hear your opinion first before I spend too many days implementing > > > something. > > > > OK, excuse my ignorance, but I'm not seeing how that IST shifting > > nonsense would've helped in the first place. > > > > If I understand correctly the problem is: > > > > <#VC> > > shift IST > > <NMI> > > ... does stuff > > <#VC> # again, safe because the shift > > > > But what happens if you get the NMI before your IST adjustment? > > The v3 patchset implements an unconditional shift of the #VC IST entry > in the NMI handler, before it can trigger a #VC exception. Going by that other thread -- where you said that any memory access can trigger a #VC, there just isn't such a guarantee. > > Either way around we get to fix this up in NMI (and any other IST > > exception that can happen while in #VC, hello #MC). And more complexity > > there is the very last thing we need :-( > > Yes, in whatever way this gets implemented, it needs some fixup in the > NMI handler. But that can happen in C code, so it does not make the > assembly more complex, at least. > > > There's no way you can fix up the IDT without getting an NMI first. > > Not sure what you mean by this. I was talking about the case where #VC would try and fix up its own IST.
