| Message ID | 20190926214302.21990-1-sean.j.christopherson@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | KVM: nVMX: Bug fix for consuming stale vmcs02.GUEST_CR3 | expand |
On 9/26/19 11:43 PM, Sean Christopherson wrote: > Reto Buerki reported a failure in a nested VMM when running with HLT > interception disabled in L1. When putting L2 into HLT, KVM never actually > enters L2 and instead cancels the nested run and pretends that VM-Enter to > L2 completed and then exited on HLT (which KVM intercepted). Because KVM > never actually runs L2, KVM skips the pending MMU update for L2 and so > leaves a stale value in vmcs02.GUEST_CR3. If the next wake event for L2 > triggers a nested VM-Exit, KVM will refresh vmcs12->guest_cr3 from > vmcs02.GUEST_CR3 and consume the stale value. > > Fix the issue by unconditionally writing vmcs02.GUEST_CR3 during nested > VM-Enter instead of deferring the update to vmx_set_cr3(), and skip the > update of GUEST_CR3 in vmx_set_cr3() when running L2. I.e. make the > nested code fully responsible for vmcs02.GUEST_CR3. > > I really wanted to go with a different fix of handling this as a one-off > case in the HLT flow (in nested_vmx_run()), and then following that up > with a cleanup of VMX's CR3 handling, e.g. to do proper dirty tracking > instead of having the nested code do manual VMREADs and VMWRITEs. I even > went so far as to hide vcpu->arch.cr3 (put CR3 in vcpu->arch.regs), but > things went south when I started working through the dirty tracking logic. > > Because EPT can be enabled *without* unrestricted guest, enabling EPT > doesn't always mean GUEST_CR3 really is the guest CR3 (unlike SVM's NPT). > And because the unrestricted guest handling of GUEST_CR3 is dependent on > whether the guest has paging enabled, VMX can't even do a clean handoff > based on unrestricted guest. In a nutshell, dynamically handling the > transitions of GUEST_CR3 ownership in VMX is a nightmare, so fixing this > purely within the context of nested VMX turned out to be the cleanest fix. > > Sean Christopherson (2): > KVM: nVMX: Always write vmcs02.GUEST_CR3 during nested VM-Enter > KVM: VMX: Skip GUEST_CR3 VMREAD+VMWRITE if the VMCS is up-to-date > > arch/x86/kvm/vmx/nested.c | 8 ++++++++ > arch/x86/kvm/vmx/vmx.c | 15 ++++++++++----- > 2 files changed, 18 insertions(+), 5 deletions(-) Tested-by: Reto Buerki <reet@codelabs.ch> Thanks!
Sean Christopherson <sean.j.christopherson@intel.com> writes: > Reto Buerki reported a failure in a nested VMM when running with HLT > interception disabled in L1. When putting L2 into HLT, KVM never actually > enters L2 and instead cancels the nested run and pretends that VM-Enter to > L2 completed and then exited on HLT (which KVM intercepted). Because KVM > never actually runs L2, KVM skips the pending MMU update for L2 and so > leaves a stale value in vmcs02.GUEST_CR3. If the next wake event for L2 > triggers a nested VM-Exit, KVM will refresh vmcs12->guest_cr3 from > vmcs02.GUEST_CR3 and consume the stale value. > > Fix the issue by unconditionally writing vmcs02.GUEST_CR3 during nested > VM-Enter instead of deferring the update to vmx_set_cr3(), and skip the > update of GUEST_CR3 in vmx_set_cr3() when running L2. I.e. make the > nested code fully responsible for vmcs02.GUEST_CR3. > > I really wanted to go with a different fix of handling this as a one-off > case in the HLT flow (in nested_vmx_run()), and then following that up > with a cleanup of VMX's CR3 handling, e.g. to do proper dirty tracking > instead of having the nested code do manual VMREADs and VMWRITEs. I even > went so far as to hide vcpu->arch.cr3 (put CR3 in vcpu->arch.regs), but > things went south when I started working through the dirty tracking logic. > > Because EPT can be enabled *without* unrestricted guest, enabling EPT > doesn't always mean GUEST_CR3 really is the guest CR3 (unlike SVM's NPT). > And because the unrestricted guest handling of GUEST_CR3 is dependent on > whether the guest has paging enabled, VMX can't even do a clean handoff > based on unrestricted guest. In a nutshell, dynamically handling the > transitions of GUEST_CR3 ownership in VMX is a nightmare, so fixing this > purely within the context of nested VMX turned out to be the cleanest fix. > > Sean Christopherson (2): > KVM: nVMX: Always write vmcs02.GUEST_CR3 during nested VM-Enter > KVM: VMX: Skip GUEST_CR3 VMREAD+VMWRITE if the VMCS is up-to-date > Series: Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>