On 5/12/21 11:30 AM, Sean Christopherson wrote: > On Tue, May 11, 2021, Krish Sadhukhan wrote: >> Move 'nested_run' counter to enter_guest_mode() because, >> i) This counter is common to both Intel and AMD and can be incremented >> from a common place, >> ii) guest mode is a more finer-grained state than the beginning of >> nested_svm_vmrun() and nested_vmx_run(). > > Hooking enter_guest_mode() makes the name a misnomer since it will count cases > such as setting nested state and resuming from SMI, neither of which is a nested > run in the sense of L1 deliberately choosing to run L2. > > And while bumping nested_run at the very beginning of VMLAUNCH/VMRESUME/VMRUN is > arguably wrong in that it counts _attempts_ instead of successful VM-Enters, it's Yes, the original purpose was to track the attempt. That's why the counter is incremented at the beginning. It helps tell if there is any attempt to run L2 VM (and also if VM is actively running L2 VM by monitoring the counter). This helps as sometimes VM owner does not realize software like jailhouse will involve the L2 VM. Without the counter, we may need to temporarily use "/sys/kernel/debug/kvm/mmu_unsync" assuming shadow page table is not used by host if L2 VM is not involved. Dongli Zhang > at least consistent. Moving this to enter_guest_mode() means it's arbitrarily > counting VM-Enter that fails late, but not those that fail early. > > If we really want it to mean "successful VM-Enter", then we should wait until > after VM-Enter actual succeeds, and do it only for actual VM-Enter. >
