On 8/17/2024 1:44 AM, Sean Christopherson wrote: > On Tue, Jul 09, 2024, Manali Shukla wrote: >> @@ -758,6 +759,16 @@ static void nested_vmcb02_prepare_control(struct vcpu_svm *svm, >> } >> } >> >> + /* >> + * If guest intercepts BUSLOCK, use guest's bus_lock_counter value, >> + * otherwise use host bus_lock_counter value. >> + */ >> + if (guest_can_use(vcpu, X86_FEATURE_BUS_LOCK_THRESHOLD) && >> + vmcb12_is_intercept(&svm->nested.ctl, INTERCEPT_BUSLOCK)) >> + vmcb02->control.bus_lock_counter = svm->nested.ctl.bus_lock_counter; >> + else >> + vmcb02->control.bus_lock_counter = vmcb01->control.bus_lock_counter; > > Copying vmcb01's count to/from vmcb02 belongs in the core enabling patch. From > KVM's perspective, the counter is associated with a vCPU, not a VMCB, and so the > count should keep running across nested transitions. > > As written, taking only the core enabling patch will mean that L2 runs with the > wrong count. Amusingly, because '0' means "always exit", L2 would run in a *more* > restrictive environment due to the VMCB being zero-allocated. Yeah. From my testing, with core enabling patch + copying vmcb01's count to/from vmcb02, L2 runs with correct value of bus lock counter and counter continues to run across nested transitions. The bus lock exit happens to L0 hypervisor when buslock is generated from L2 guest. - Manali
