From: "Xin Li (Intel)" <[email protected]>
On a userspace MSR filter change, set FRED MSR intercepts.
Because the following eight FRED MSRs,
MSR_IA32_FRED_RSP[123], MSR_IA32_FRED_STKLVLS,
MSR_IA32_FRED_SSP[123], MSR_IA32_FRED_CONFIG,
are used by the kernel itself to take an exception at any time, they
should be context-switched by Intel VT-x automatically in order to
preserve the FRED architectural invariant that there should NEVER be
a "gap" during which it is unsafe to take an exception.
KVM leverages Intel VT-x hardware to automatically context switch the
eight FRED MSRs using:
1) Dedicated host and guest VMCS fields for each MSR.
2) VM-entry/exit controls to manage the automated loading and saving
of the eight FRED MSRs.
Consequently, passing these MSRs through to the guest would only add
unnecessary handling code without benefit.
Both MSR_IA32_FRED_RSP0 and MSR_IA32_FRED_SSP0 (aka MSR_IA32_PL0_SSP)
are dedicated for userspace event delivery, IOW they are NOT used in
any kernel event delivery and the execution of ERETS. Thus KVM can
run safely with guest values in the two MSRs. As a result, save and
restore of their guest values are deferred until vCPU context switch,
Host MSR_IA32_FRED_RSP0 is restored upon returning to userspace, and
Host MSR_IA32_PL0_SSP is managed with XRSTORS/XSAVES.
MSR_IA32_PL0_SSP (aka MSR_IA32_FRED_SSP0) is part of CET supervisor
state, but all four FRED SSP MSRs are architecturally visible on any
processor that enumerates FRED. Even if CET is absent, these MSRs
remain accessible via RDMSR/WRMSR, though FRED transitions will not
use them.
Intercept MSR_IA32_PL0_SSP if CET shadow stacks are unsupported (even
with FRED present). Since this MSR is rarely accessed and ignored by
XSAVES in this configuration, interception avoids the overhead of
manually context switching the hardware MSR during vcpu_load/put.
This behavior is consistent with the current setup in
vmx_recalc_msr_intercepts(), so no change is needed to the interception
logic for MSR_IA32_PL0_SSP.
Signed-off-by: Xin Li (Intel) <[email protected]>
Signed-off-by: Sohil Mehta <[email protected]>
---
v10:
- Improve the commit message and code comment with an explanation
from hpa (Chao Gao and Dave Hansen).
---
arch/x86/kvm/vmx/vmx.c | 67 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index dc80ca5f804d..09bbbc680aa7 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -4304,6 +4304,72 @@ static void vmx_recalc_pmu_msr_intercepts(struct
kvm_vcpu *vcpu)
MSR_TYPE_RW, intercept);
}
+static void vmx_set_intercept_for_fred_msr(struct kvm_vcpu *vcpu)
+{
+ bool intercept = !guest_cpu_cap_has(vcpu, X86_FEATURE_FRED);
+
+ if (!kvm_cpu_cap_has(X86_FEATURE_FRED))
+ return;
+
+ /*
+ * Because the following eight FRED MSRs,
+ * MSR_IA32_FRED_RSP[123], MSR_IA32_FRED_STKLVLS,
+ * MSR_IA32_FRED_SSP[123], MSR_IA32_FRED_CONFIG,
+ * are used by the kernel itself to take an exception at any time, they
+ * should be context-switched by Intel VT-x automatically in order to
+ * preserve the FRED architectural invariant that there should NEVER be
+ * a "gap" during which it is unsafe to take an exception.
+ *
+ * KVM leverages Intel VT-x hardware to automatically context switch the
+ * eight FRED MSRs using:
+ *
+ * 1) Dedicated host and guest VMCS fields for each MSR.
+ *
+ * 2) VM-entry/exit controls to manage the automated loading and
saving
+ * of the eight FRED MSRs.
+ *
+ * Consequently, passing these MSRs through to the guest would only add
+ * unnecessary handling code without benefit.
+ */
+ vmx_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP1, MSR_TYPE_RW,
intercept);
+ vmx_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP2, MSR_TYPE_RW,
intercept);
+ vmx_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP3, MSR_TYPE_RW,
intercept);
+ vmx_set_intercept_for_msr(vcpu, MSR_IA32_FRED_STKLVLS, MSR_TYPE_RW,
intercept);
+ vmx_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP1, MSR_TYPE_RW,
intercept);
+ vmx_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP2, MSR_TYPE_RW,
intercept);
+ vmx_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP3, MSR_TYPE_RW,
intercept);
+ vmx_set_intercept_for_msr(vcpu, MSR_IA32_FRED_CONFIG, MSR_TYPE_RW,
intercept);
+
+ /*
+ * MSR_IA32_FRED_RSP0 and MSR_IA32_PL0_SSP (aka MSR_IA32_FRED_SSP0) are
+ * designed for event delivery while executing in userspace. Since KVM
+ * operates entirely in kernel mode (CPL is always 0 after any VM exit),
+ * it can safely retain and operate with guest-defined values for these
+ * MSRs.
+ *
+ * Disabling interception of the two MSRs offers two advantages:
+ * 1) Simplicity: Eliminates dedicated MSR handling code.
+ * 2) Performance: Avoids frequent VM-exits since the two MSRs are
+ * per user thread variables and frequently accessed.
+ *
+ * MSR_IA32_PL0_SSP (aka MSR_IA32_FRED_SSP0) is part of CET supervisor
+ * state, but all four FRED SSP MSRs are architecturally visible on any
+ * processor that enumerates FRED. Even if CET is absent, these MSRs
+ * remain accessible via RDMSR/WRMSR, though FRED transitions will not
+ * use them.
+ *
+ * Intercept MSR_IA32_PL0_SSP if CET shadow stacks are unsupported (even
+ * with FRED present). Since this MSR is rarely accessed and ignored by
+ * XSAVES in this configuration, interception avoids the overhead of
+ * manually context switching the hardware MSR during vcpu_load/put.
+ *
+ * This behavior is consistent with the current setup in
+ * vmx_recalc_msr_intercepts(), so no change is needed to the
interception
+ * logic for MSR_IA32_PL0_SSP.
+ */
+ vmx_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP0, MSR_TYPE_RW,
intercept);
+}
+
static void vmx_recalc_msr_intercepts(struct kvm_vcpu *vcpu)
{
bool intercept;
@@ -4371,6 +4437,7 @@ static void vmx_recalc_msr_intercepts(struct kvm_vcpu
*vcpu)
}
vmx_recalc_pmu_msr_intercepts(vcpu);
+ vmx_set_intercept_for_fred_msr(vcpu);
/*
* x2APIC and LBR MSR intercepts are modified on-demand and cannot be
--
2.43.0
