diff mbox series

[v2,06/25] KVM: VMX: Defer enabling FRED MSRs save/load until after set CPUID

Message ID 20240207172646.3981-7-xin3.li@intel.com (mailing list archive)
State New
Headers show
Series Enable FRED with KVM VMX | expand

Commit Message

Li, Xin3 Feb. 7, 2024, 5:26 p.m. UTC 
Clear FRED VM entry/exit controls when initializing a vCPU, and set
these controls only if FRED is enumerated after set CPUID.

FRED VM entry/exit controls need to be set to establish context
sufficient to support FRED event delivery immediately after VM entry
and exit.  However it is not required to save/load FRED MSRs for
a non-FRED guest, which aren't supposed to access FRED MSRs.

Signed-off-by: Xin Li <xin3.li@intel.com>
Tested-by: Shan Kang <shan.kang@intel.com>
---

Changes since v1:
* Use kvm_cpu_cap_has() instead of cpu_feature_enabled() (Chao Gao).
* Clear FRED VM entry/exit controls if FRED is not enumerated (Chao Gao).
* Use guest_can_use() to trace FRED enumeration in a vcpu (Chao Gao).
---
 arch/x86/kvm/governed_features.h |  1 +
 arch/x86/kvm/vmx/vmx.c           | 32 +++++++++++++++++++++++++++++++-
 2 files changed, 32 insertions(+), 1 deletion(-)

Comments

Chao Gao April 19, 2024, 11:02 a.m. UTC | #1 
On Wed, Feb 07, 2024 at 09:26:26AM -0800, Xin Li wrote:
>Clear FRED VM entry/exit controls when initializing a vCPU, and set
>these controls only if FRED is enumerated after set CPUID.
>
>FRED VM entry/exit controls need to be set to establish context
>sufficient to support FRED event delivery immediately after VM entry
>and exit. However it is not required to save/load FRED MSRs for
>a non-FRED guest, which aren't supposed to access FRED MSRs.
>
>Signed-off-by: Xin Li <xin3.li@intel.com>
>Tested-by: Shan Kang <shan.kang@intel.com>

Reviewed-by: Chao Gao <chao.gao@intel.com>
Sean Christopherson June 12, 2024, 9:19 p.m. UTC | #2 
On Wed, Feb 07, 2024, Xin Li wrote:
> Clear FRED VM entry/exit controls when initializing a vCPU, and set
> these controls only if FRED is enumerated after set CPUID.
> 
> FRED VM entry/exit controls need to be set to establish context
> sufficient to support FRED event delivery immediately after VM entry
> and exit.  However it is not required to save/load FRED MSRs for
> a non-FRED guest, which aren't supposed to access FRED MSRs.

Does this actually provide a measurable performance boost?  If not, just do the
unnecessary load/store on entry/exit.

Generally speaking, the only time KVM dynamically toggles entry/exit controls is
when KVM wants to run the guest with a host value, e.g. with the host's
PERF_GLOBAL_CTRL.
Li, Xin3 June 13, 2024, 3:31 a.m. UTC | #3 
> On Wed, Feb 07, 2024, Xin Li wrote:
> > Clear FRED VM entry/exit controls when initializing a vCPU, and set
> > these controls only if FRED is enumerated after set CPUID.
> >
> > FRED VM entry/exit controls need to be set to establish context
> > sufficient to support FRED event delivery immediately after VM entry
> > and exit.  However it is not required to save/load FRED MSRs for
> > a non-FRED guest, which aren't supposed to access FRED MSRs.
> 
> Does this actually provide a measurable performance boost?  If not, just do the
> unnecessary load/store on entry/exit.

No performance measurement yet.  Will make the change.

> 
> Generally speaking, the only time KVM dynamically toggles entry/exit controls is
> when KVM wants to run the guest with a host value, e.g. with the host's
> PERF_GLOBAL_CTRL.

Simple rule.

Thanks!
    Xin
diff mbox series

Patch

diff --git a/arch/x86/kvm/governed_features.h b/arch/x86/kvm/governed_features.h
index ad463b1ed4e4..507ca73e52e9 100644
--- a/arch/x86/kvm/governed_features.h
+++ b/arch/x86/kvm/governed_features.h
@@ -17,6 +17,7 @@  KVM_GOVERNED_X86_FEATURE(PFTHRESHOLD)
 KVM_GOVERNED_X86_FEATURE(VGIF)
 KVM_GOVERNED_X86_FEATURE(VNMI)
 KVM_GOVERNED_X86_FEATURE(LAM)
+KVM_GOVERNED_X86_FEATURE(FRED)
 
 #undef KVM_GOVERNED_X86_FEATURE
 #undef KVM_GOVERNED_FEATURE
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 4023474ea002..34b6676f60d8 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -4402,6 +4402,9 @@  static u32 vmx_vmentry_ctrl(void)
 	if (cpu_has_perf_global_ctrl_bug())
 		vmentry_ctrl &= ~VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL;
 
+	/* Whether to load guest FRED MSRs is deferred until after set CPUID */
+	vmentry_ctrl &= ~VM_ENTRY_LOAD_IA32_FRED;
+
 	return vmentry_ctrl;
 }
 
@@ -4430,7 +4433,13 @@  static u32 vmx_vmexit_ctrl(void)
 
 static u64 vmx_secondary_vmexit_ctrl(void)
 {
-	return vmcs_config.secondary_vmexit_ctrl;
+	u64 secondary_vmexit_ctrl = vmcs_config.secondary_vmexit_ctrl;
+
+	/* Whether to save/load FRED MSRs is deferred until after set CPUID */
+	secondary_vmexit_ctrl &= ~(SECONDARY_VM_EXIT_SAVE_IA32_FRED |
+				   SECONDARY_VM_EXIT_LOAD_IA32_FRED);
+
+	return secondary_vmexit_ctrl;
 }
 
 static void vmx_refresh_apicv_exec_ctrl(struct kvm_vcpu *vcpu)
@@ -7762,10 +7771,31 @@  static void update_intel_pt_cfg(struct kvm_vcpu *vcpu)
 		vmx->pt_desc.ctl_bitmask &= ~(0xfULL << (32 + i * 4));
 }
 
+static void vmx_vcpu_config_fred_after_set_cpuid(struct kvm_vcpu *vcpu)
+{
+	struct vcpu_vmx *vmx = to_vmx(vcpu);
+
+	kvm_governed_feature_check_and_set(vcpu, X86_FEATURE_FRED);
+
+	if (guest_can_use(vcpu, X86_FEATURE_FRED)) {
+		vm_entry_controls_setbit(vmx, VM_ENTRY_LOAD_IA32_FRED);
+		secondary_vm_exit_controls_setbit(vmx,
+						  SECONDARY_VM_EXIT_SAVE_IA32_FRED |
+						  SECONDARY_VM_EXIT_LOAD_IA32_FRED);
+	} else {
+		vm_entry_controls_clearbit(vmx, VM_ENTRY_LOAD_IA32_FRED);
+		secondary_vm_exit_controls_clearbit(vmx,
+						    SECONDARY_VM_EXIT_SAVE_IA32_FRED |
+						    SECONDARY_VM_EXIT_LOAD_IA32_FRED);
+	}
+}
+
 static void vmx_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
 {
 	struct vcpu_vmx *vmx = to_vmx(vcpu);
 
+	vmx_vcpu_config_fred_after_set_cpuid(vcpu);
+
 	/*
 	 * XSAVES is effectively enabled if and only if XSAVE is also exposed
 	 * to the guest.  XSAVES depends on CR4.OSXSAVE, and CR4.OSXSAVE can be