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!
