On Tue, Jun 23, 2020 at 03:03:22PM +0200, Peter Zijlstra wrote:

On Tue, Jun 23, 2020 at 02:12:37PM +0200, Joerg Roedel wrote:

quoted

On Tue, Jun 23, 2020 at 01:50:14PM +0200, Peter Zijlstra wrote:

quoted

If SNP is the sole reason #VC needs to be IST, then I'd strongly urge
you to only make it IST if/when you try and make SNP happen, not before.

It is not the only reason, when ES guests gain debug register support
then #VC also needs to be IST, because #DB can be promoted into #VC
then, and as #DB is IST for a reason, #VC needs to be too.

Didn't I read somewhere that that is only so for Rome/Naples but not for
the later chips (Milan) which have #DB pass-through?

Probably, not sure which chips will get debug register virtualization
under SEV-ES. But even when it is supported, the HV can (and sometimes
will) intercept #DB, which then causes it to be promoted to #VC.

We're talking about the 3rd case where the only reason things 'work' is
because we'll have to panic():

 - #MC

Okay, #MC is special and can only be handled on a best-effort basis, as
#MC could happen anytime, also while already executing the #MC handler.

 - #DB with BUS LOCK DEBUG EXCEPTION

If I understand the problem correctly, this can be solved by moving off
the IST stack to the current task stack in the #DB handler, like I plan
to do for #VC, no?

 - #VC SNP

This has to panic for other reasons that can't be worked around. It
boils down to detecting that the HV is doing something fishy and bail
out to avoid further harm (like in the #MC handler).


Regards,

	Joerg