From: Sohil Mehta <sohil.mehta@intel.com>
To: kvm@vger.kernel.org, x86@kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H . Peter Anvin" <hpa@zytor.com>, Xin Li <xin@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Nikunj A Dadhania <nikunj@amd.com>,
Shivansh Dhiman <shivansh.dhiman@amd.com>,
David Woodhouse <dwmw@amazon.co.uk>,
Chao Gao <chao.gao@intel.com>,
Binbin Wu <binbin.wu@linux.intel.com>,
Sohil Mehta <sohil.mehta@intel.com>,
Zhao Liu <zhao1.liu@intel.com>, Yosry Ahmed <yosry@kernel.org>,
David Matlack <dmatlack@google.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: [PATCH v10 08/28] KVM: VMX: Set FRED MSR intercepts
Date: Fri, 11 Sep 2026 14:36:38 -0700 [thread overview]
Message-ID: <20260911213659.2025974-9-sohil.mehta@intel.com> (raw)
In-Reply-To: <20260911213659.2025974-1-sohil.mehta@intel.com>
From: "Xin Li (Intel)" <xin@zytor.com>
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) <xin@zytor.com>
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
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
next prev parent reply other threads:[~2026-09-11 21:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 21:36 [PATCH v10 00/28] KVM: Enable FRED support with KVM VMX Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 01/28] KVM: VMX: Enable support for secondary VM exit controls Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 02/28] KVM: VMX: Initialize VM entry/exit FRED controls in vmcs_config Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 03/28] KVM: VMX: Disable FRED if FRED consistency checks fail Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 04/28] x86/cea: Prefix event stack names with ESTACK_ Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 05/28] x86/cea: Use array indexing to simplify exception stack access Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 06/28] x86/fred: Export this_cpu_fred_rsp() for KVM usage Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 07/28] KVM: VMX: Initialize VMCS FRED fields Sohil Mehta
2026-09-11 21:36 ` Sohil Mehta [this message]
2026-09-11 21:36 ` [PATCH v10 09/28] KVM: VMX: Save/restore guest FRED RSP0 Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 10/28] KVM: VMX: Add support for saving and restoring FRED MSRs Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 11/28] KVM: x86: Add a helper to detect if FRED is enabled for a vCPU Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 12/28] KVM: x86: Add a new save/restore flag for FRED metadata Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 13/28] KVM: VMX: Virtualize FRED nested exception tracking Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 14/28] KVM: VMX: Virtualize FRED event_data Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 15/28] KVM: x86: Include CR4.FRED in the emulator CR4 write mask Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 16/28] KVM: x86: Mark CR4.FRED as not reserved Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 17/28] KVM: x86: Handle CR4.FRED when emulating RSM Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 18/28] KVM: VMX: Dump FRED context in dump_vmcs() Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 19/28] KVM: x86: Advertise support for FRED Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 20/28] KVM: nVMX: Enable support for secondary VM exit controls Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 21/28] KVM: nVMX: Handle FRED VMCS fields in nested VMX context Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 22/28] KVM: nVMX: Restrict event data VMCS fields to FRED-supported hosts Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 23/28] KVM: nVMX: Shadow ORIGINAL_EVENT_DATA and INJECTED_EVENT_DATA fields Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 24/28] KVM: nVMX: Validate FRED-related VMCS fields Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 25/28] KVM: nVMX: Enable VMX FRED controls Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 26/28] KVM: selftests: Add FRED MSRs to msrs_test Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 27/28] KVM: selftests: Add a new VM guest mode to run user level code Sohil Mehta
2026-09-11 21:36 ` [PATCH v10 28/28] KVM: selftests: Add fred exception tests Sohil Mehta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260911213659.2025974-9-sohil.mehta@intel.com \
--to=sohil.mehta@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=dmatlack@google.com \
--cc=dwmw@amazon.co.uk \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=shivansh.dhiman@amd.com \
--cc=skhan@linuxfoundation.org \
--cc=tglx@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
--cc=yosry@kernel.org \
--cc=zhao1.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox