KVM: nVMX: Pull KVM L0's desired controls directly from vmcs01
authorSean Christopherson <seanjc@google.com>
Tue, 10 Aug 2021 17:19:50 +0000 (10:19 -0700)
committerPaolo Bonzini <pbonzini@redhat.com>
Fri, 13 Aug 2021 07:35:15 +0000 (03:35 -0400)
commit389ab25216c9d09e0d335e764eeeb84c2089614f
tree55b6d47587cc1174ac086b1d476cfe15ccf8bb6d
parentee3b6e41bc26c628b0c06aacd2758a316fe583be
KVM: nVMX: Pull KVM L0's desired controls directly from vmcs01

When preparing controls for vmcs02, grab KVM's desired controls from
vmcs01's shadow state instead of recalculating the controls from scratch,
or in the secondary execution controls, instead of using the dedicated
cache.  Calculating secondary exec controls is eye-poppingly expensive
due to the guest CPUID checks, hence the dedicated cache, but the other
calculations aren't exactly free either.

Explicitly clear several bits (x2APIC, DESC exiting, and load EFER on
exit) as appropriate as they may be set in vmcs01, whereas the previous
implementation relied on dynamic bits being cleared in the calculator.

Intentionally propagate VM_{ENTRY,EXIT}_LOAD_IA32_PERF_GLOBAL_CTRL from
vmcs01 to vmcs02.  Whether or not PERF_GLOBAL_CTRL is loaded depends on
whether or not perf itself is active, so unless perf stops between the
exit from L1 and entry to L2, vmcs01 will hold the desired value.  This
is purely an optimization as atomic_switch_perf_msrs() will set/clear
the control as needed at VM-Enter, i.e. it avoids two extra VMWRITEs in
the case where perf is active (versus starting with the bits clear in
vmcs02, which was the previous behavior).

Cc: Zeng Guang <guang.zeng@intel.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210810171952.2758100-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
arch/x86/kvm/vmx/nested.c
arch/x86/kvm/vmx/vmx.h