From: Sean Christopherson <seanjc@google.com>
To: Xin Li <xin@zytor.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, pbonzini@redhat.com, corbet@lwn.net,
tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
luto@kernel.org, peterz@infradead.org,
andrew.cooper3@citrix.com, chao.gao@intel.com,
hch@infradead.org
Subject: Re: [PATCH v6 06/20] KVM: VMX: Set FRED MSR intercepts
Date: Tue, 26 Aug 2025 15:17:01 -0700 [thread overview]
Message-ID: <aK4yXT9y5YHeEWkb@google.com> (raw)
In-Reply-To: <c45a7c91-e393-4f71-8b22-aef6486aaa9e@zytor.com>
On Tue, Aug 26, 2025, Xin Li wrote:
>
> > > Hi Sean,
> > >
> > > I'd like to bring up an issue concerning MSR_IA32_PL0_SSP.
> > >
> > > The FRED spec claims:
> > >
> > > The FRED SSP MSRs are supported by any processor that enumerates
> > > CPUID.(EAX=7,ECX=1):EAX.FRED[bit 17] as 1. If such a processor does not
> > > support CET, FRED transitions will not use the MSRs (because shadow stacks
> > > are not enabled), but the MSRs would still be accessible using MSR-access
> > > instructions (e.g., RDMSR, WRMSR).
> > >
> > > It means KVM needs to handle MSR_IA32_PL0_SSP even when FRED is supported
> > > but CET is not. And this can be broken down into two subtasks:
> > >
> > > 1) Allow such a guest to access MSR_IA32_PL0_SSP w/o triggering #GP. And
> > > this behavior is already implemented in patch 8 of this series.
> > >
> > > 2) Save and restore MSR_IA32_PL0_SSP in both KVM and Qemu for such a guest.
> >
> > What novel work needs to be done in KVM? For QEMU, I assume it's just adding an
> > "or FRED" somewhere. For KVM, I'm missing what additional work would be required
> > that wouldn't be naturally covered by patch 8 (assuming patch 8 is bug-free).
>
> Extra patches:
>
> 1) A patch to save/restore guest MSR_IA32_PL0_SSP (i.e., FRED SSP0), as
> what we have done for RSP0, following is the patch on top of the patch
> saving/restoring RSP0:
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 449a5e02c7de..0bf684342a71 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -1294,8 +1294,13 @@ void vmx_prepare_switch_to_guest(struct kvm_vcpu *vcpu)
>
> wrmsrq(MSR_KERNEL_GS_BASE, vmx->msr_guest_kernel_gs_base);
>
> - if (guest_cpu_cap_has(vcpu, X86_FEATURE_FRED))
> + if (guest_cpu_cap_has(vcpu, X86_FEATURE_FRED)) {
> wrmsrns(MSR_IA32_FRED_RSP0, vmx->msr_guest_fred_rsp0);
> +
> + /* XSAVES/XRSTORS do not cover SSP MSRs */
Eww. I'm with Andrew, fix the SDM. This is silly.
> + if (!kvm_cpu_cap_has(X86_FEATURE_SHSTK))
> + wrmsrns(MSR_IA32_FRED_SSP0, vmx->msr_guest_fred_ssp0);
FWIW, if we can't get an SDM change, don't bother with RDMSR/WRMSRNS, just
configure KVM to intercept accesses. Then in kvm_set_msr_common(), pivot on
X86_FEATURE_SHSTK, e.g.
case MSR_IA32_U_CET:
case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
if (!kvm_cpu_cap_has(X86_FEATURE_SHSTK)) {
WARN_ON_ONCE(msr != MSR_IA32_FRED_SSP0);
vcpu->arch.fred_rsp0_fallback = data;
break;
}
kvm_set_xstate_msr(vcpu, msr_info);
break;
and
case MSR_IA32_U_CET:
case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
if (!kvm_cpu_cap_has(X86_FEATURE_SHSTK)) {
WARN_ON_ONCE(msr_info->index != MSR_IA32_FRED_SSP0);
vcpu->arch.fred_rsp0_fallback = msr_info->data;
break;
}
kvm_get_xstate_msr(vcpu, msr_info);
break;
next prev parent reply other threads:[~2025-08-26 22:17 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 22:36 [PATCH v6 00/20] Enable FRED with KVM VMX Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 01/20] KVM: VMX: Add support for the secondary VM exit controls Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 02/20] KVM: VMX: Initialize VM entry/exit FRED controls in vmcs_config Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 03/20] KVM: VMX: Disable FRED if FRED consistency checks fail Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 04/20] x86/cea: Export an API to get per CPU exception stacks for KVM to use Xin Li (Intel)
2025-08-27 17:33 ` Dave Hansen
2025-08-27 22:18 ` Xin Li
2025-08-21 22:36 ` [PATCH v6 05/20] KVM: VMX: Initialize VMCS FRED fields Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 06/20] KVM: VMX: Set FRED MSR intercepts Xin Li (Intel)
2025-08-25 2:51 ` Xin Li
2025-08-26 18:11 ` Sean Christopherson
2025-08-26 21:59 ` Xin Li
2025-08-26 22:17 ` Sean Christopherson [this message]
2025-08-27 22:24 ` Xin Li
2025-08-27 22:43 ` Xin Li
2025-08-28 23:32 ` Sean Christopherson
2025-08-26 18:50 ` Andrew Cooper
2025-08-26 22:03 ` Xin Li
2025-08-26 22:20 ` Andrew Cooper
2025-08-21 22:36 ` [PATCH v6 07/20] KVM: VMX: Save/restore guest FRED RSP0 Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 08/20] KVM: VMX: Add support for FRED context save/restore Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 09/20] KVM: x86: Add a helper to detect if FRED is enabled for a vCPU Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 10/20] KVM: VMX: Virtualize FRED event_data Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 11/20] KVM: VMX: Virtualize FRED nested exception tracking Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 12/20] KVM: x86: Save/restore the nested flag of an exception Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 13/20] KVM: x86: Mark CR4.FRED as not reserved Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 14/20] KVM: VMX: Dump FRED context in dump_vmcs() Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 15/20] KVM: x86: Advertise support for FRED Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 16/20] KVM: nVMX: Add support for the secondary VM exit controls Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 17/20] KVM: nVMX: Add FRED VMCS fields to nested VMX context handling Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 18/20] KVM: nVMX: Add FRED-related VMCS field checks Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 19/20] KVM: nVMX: Add prerequisites to SHADOW_FIELD_R[OW] macros Xin Li (Intel)
2025-08-21 22:36 ` [PATCH v6 20/20] KVM: nVMX: Allow VMX FRED controls Xin Li (Intel)
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=aK4yXT9y5YHeEWkb@google.com \
--to=seanjc@google.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xin@zytor.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.