lkml.org 
[lkml]   [2021]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] KVM: nVMX: Fix nested bus lock VM exit
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!

\
 
 \ /
  Last update: 2021-09-10 17:20    [W:0.049 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site