Re: [PATCH] KVM: nVMX: Fix nested bus lock VM exit

[Sean Christopherson <seanjc@google.com>]

On Fri, Sep 10, 2021, Xiaoyao Li wrote:
> On 9/10/2021 1:59 AM, Sean Christopherson wrote:
> > No, nested_vmx_l0_wants_exit() is specifically for cases where L0 wants to handle
> > the exit even if L1 also wants to handle the exit.  For cases where L0 is expected
> > to handle the exit because L1 does _not_ want the exit, the intent is to not have
> > an entry in nested_vmx_l0_wants_exit().  This is a bit of a grey area, arguably L0
> > "wants" the exit because L0 knows BUS_LOCK cannot be exposed to L1.
> 
> No. What I wanted to convey here is exactly "L0 wants to handle it because
> L0 wants it, and no matter L1 wants it or not (i.e., even if L1 wants it) ",
> not "L0 wants it because the feature not exposed to L1/L1 cannot enable it".
> 
> Even for the future case that this feature is exposed to L1, and both L0 and
> L1 enable it. It should exit to L0 first for every bus lock happened in L2
> VM and after L0 handles it, L0 needs to inject a BUS LOCK VM exit to L1 if
> L1 enables it. Every bus lock acquired in L2 VM should be regarded as the
> bus lock happened in L1 VM as well. L2 VM is just an application of L1 VM.
> 
> IMO, the flow should be:
> 
> if (L0 enables it) {
> 	exit to L0;
> 	L0 handling;
> 	if (is_guest_mode(vcpu) && L1 enables it) {
> 		inject BUS_LOCK VM EXIT to L1;
> 	}
> } else if (L1 enables it) {
> 	BUS_LOCK VM exit to L1;
> } else {
> 	BUG();
> }

Ah, we've speculated differently on how nested support would operate.  Let's go
with the original patch plus a brief comment stating it's never exposed to L1.
Since that approach doesn't speculate, it can't be wrong. :-)

Thanks!