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:

quoted

On Tue, Jun 23, 2020 at 11:45:19AM +0200, Joerg Roedel wrote:

quoted

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.

quoted

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.

quoted

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.