From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Perry Yuan <perry.yuan@amd.com>,
Sohil Mehta <sohil.mehta@intel.com>,
"Xin Li (Intel)" <xin@zytor.com>,
Joerg Roedel <joerg.roedel@amd.com>, Avi Kivity <avi@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Yosry Ahmed <yosry.ahmed@linux.dev>
Subject: Re: [PATCH v2 1/2] KVM: x86: Advertise EferLmsleUnsupported to userspace
Date: Tue, 14 Oct 2025 15:49:41 -0700 [thread overview]
Message-ID: <aO7ThZJtciBPciRj@google.com> (raw)
In-Reply-To: <20251001001529.1119031-2-jmattson@google.com>
On Tue, Sep 30, 2025, Jim Mattson wrote:
> CPUID.80000008H:EBX.EferLmsleUnsupported[bit 20] is a defeature
> bit. When this bit is clear, EFER.LMSLE is supported. When this bit is
> set, EFER.LMLSE is unsupported. KVM has never supported EFER.LMSLE, so
> it cannot support a 0-setting of this bit.
>
> Pass through the bit in KVM_GET_SUPPORTED_CPUID to advertise the
> unavailability of EFER.LMSLE to userspace.
This really needs to capture the discussion/context from v1. Without that,
saying the KVM "has never supported" LMSLE and then _partially_ disabling LSMLE
is all kinds of confusing.
> Signed-off-by: Jim Mattson <jmattson@google.com>
> ---
> v1 -> v2:
> Pass through the bit from hardware, rather than forcing it to be set.
>
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/kvm/cpuid.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 751ca35386b0..f9b593721917 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -338,6 +338,7 @@
> #define X86_FEATURE_AMD_STIBP (13*32+15) /* Single Thread Indirect Branch Predictors */
> #define X86_FEATURE_AMD_STIBP_ALWAYS_ON (13*32+17) /* Single Thread Indirect Branch Predictors always-on preferred */
> #define X86_FEATURE_AMD_IBRS_SAME_MODE (13*32+19) /* Indirect Branch Restricted Speculation same mode protection*/
> +#define X86_FEATURE_EFER_LMSLE_MBZ (13*32+20) /* EFER.LMSLE must be zero */
> #define X86_FEATURE_AMD_PPIN (13*32+23) /* "amd_ppin" Protected Processor Inventory Number */
> #define X86_FEATURE_AMD_SSBD (13*32+24) /* Speculative Store Bypass Disable */
> #define X86_FEATURE_VIRT_SSBD (13*32+25) /* "virt_ssbd" Virtualized Speculative Store Bypass Disable */
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index e2836a255b16..4823970611fd 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -1096,6 +1096,7 @@ void kvm_set_cpu_caps(void)
> F(AMD_STIBP),
> F(AMD_STIBP_ALWAYS_ON),
> F(AMD_IBRS_SAME_MODE),
> + F(EFER_LMSLE_MBZ),
Do we want to make this PASSTHROUGH_F()? I.e. explicitly ignore any host
manipulations of CPUID state? I can't imagine the kernel would ever clear the
bit, but I also don't see any downside to being paranoid.
This is what I have locally and will apply unless someone objects.
---
From: Jim Mattson <jmattson@google.com>
Date: Tue, 30 Sep 2025 17:14:07 -0700
Subject: [PATCH] KVM: x86: Advertise EferLmsleUnsupported to userspace
CPUID.80000008H:EBX.EferLmsleUnsupported[bit 20] is a defeature
bit. When this bit is clear, EFER.LMSLE is supported. When this bit is
set, EFER.LMLSE is unsupported. KVM has never _emulated_ EFER.LMSLE, so
KVM cannot truly support a 0-setting of this bit.
However, KVM has allowed the guest to enable EFER.LMSLE in hardware
since commit eec4b140c924 ("KVM: SVM: Allow EFER.LMSLE to be set with
nested svm"), i.e. KVM partially virtualizes long-mode segment limits _if_
they are supported by the underlying hardware.
Pass through the bit in KVM_GET_SUPPORTED_CPUID to advertise the
unavailability of EFER.LMSLE to userspace based on the raw underlying
hardware. Attempting to enable EFER.LSMLE on such CPUs simply doesn't
work, e.g. immediately crashes on VMRUN.
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev>
Link: https://lore.kernel.org/r/20251001001529.1119031-2-jmattson@google.com
[sean: add context about partial virtualization, use PASSTHROUGH_F]
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kvm/cpuid.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 4091a776e37a..6bdf868c8f8e 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -338,6 +338,7 @@
#define X86_FEATURE_AMD_STIBP (13*32+15) /* Single Thread Indirect Branch Predictors */
#define X86_FEATURE_AMD_STIBP_ALWAYS_ON (13*32+17) /* Single Thread Indirect Branch Predictors always-on preferred */
#define X86_FEATURE_AMD_IBRS_SAME_MODE (13*32+19) /* Indirect Branch Restricted Speculation same mode protection*/
+#define X86_FEATURE_EFER_LMSLE_MBZ (13*32+20) /* EFER.LMSLE must be zero */
#define X86_FEATURE_AMD_PPIN (13*32+23) /* "amd_ppin" Protected Processor Inventory Number */
#define X86_FEATURE_AMD_SSBD (13*32+24) /* Speculative Store Bypass Disable */
#define X86_FEATURE_VIRT_SSBD (13*32+25) /* "virt_ssbd" Virtualized Speculative Store Bypass Disable */
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 52524e0ca97f..d563a948318b 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -1135,6 +1135,7 @@ void kvm_set_cpu_caps(void)
F(AMD_STIBP),
F(AMD_STIBP_ALWAYS_ON),
F(AMD_IBRS_SAME_MODE),
+ PASSTHROUGH_F(EFER_LMSLE_MBZ),
F(AMD_PSFD),
F(AMD_IBPB_RET),
);
base-commit: 7c8b465a1c91f674655ea9cec5083744ec5f796a
--
next prev parent reply other threads:[~2025-10-14 22:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-01 0:14 [PATCH v2 0/2] KVM: SVM: Handle EferLmsleUnsupported Jim Mattson
2025-10-01 0:14 ` [PATCH v2 1/2] KVM: x86: Advertise EferLmsleUnsupported to userspace Jim Mattson
2025-10-01 15:17 ` Yosry Ahmed
2025-10-07 7:59 ` Nikunj A Dadhania
2025-10-14 22:49 ` Sean Christopherson [this message]
2025-10-01 0:14 ` [PATCH v2 2/2] KVM: SVM: Disallow EFER.LMSLE when not supported by hardware Jim Mattson
2025-10-01 15:18 ` Yosry Ahmed
2025-10-01 15:25 ` Yosry Ahmed
2025-10-07 8:02 ` Nikunj A Dadhania
2025-10-20 16:33 ` [PATCH v2 0/2] KVM: SVM: Handle EferLmsleUnsupported Sean Christopherson
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=aO7ThZJtciBPciRj@google.com \
--to=seanjc@google.com \
--cc=avi@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=perry.yuan@amd.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
--cc=yosry.ahmed@linux.dev \
/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