From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: sashiko-reviews@lists.linux.dev, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID
Date: Tue, 22 Sep 2026 11:34:50 -0700 [thread overview]
Message-ID: <arLKSkliAXuww3-0@google.com> (raw)
In-Reply-To: <CALMp9eThtND2KddrmySqViNsLyisdd6_ZH01s9jrA9K-_yQzXg@mail.gmail.com>
On Tue, Sep 22, 2026, Jim Mattson wrote:
> On Tue, Sep 22, 2026 at 10:53 AM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Tue, Sep 22, 2026, Jim Mattson wrote:
> > > On Tue, Sep 22, 2026 at 7:26 AM Sean Christopherson <seanjc@google.com> wrote:
> > > >
> > > > On Tue, Sep 22, 2026, Jim Mattson wrote:
> > > > > On Tue, Sep 22, 2026 at 6:57 AM Sean Christopherson <seanjc@google.com> wrote:
> > > > > > Gah, I hate the negative "feature" bits, I've gotten completely turned around
> > > > > > multiple times trying to sort through this.
> > > > >
> > > > > Me too!
> > > > >
> > > > > > IIUC, you're trying to "fix" setups where host CPUID.EFER_LMSLE_MBZ=0, but userspace
> > > > > > configured guest CPUID.EFER_LMSLE_MBZ=1? If so, then Sashiko is right, it needs to
> > > > > > be declared with EMULATED_F(). I would even argue that technically this isn't a KVM
> > > > > > bug, because KVM won't advertise EFER_LMSLE_MBZ in KVM_GET_SUPPORTED_CPUID on such
> > > > > > hosts.
> > >
> > > > > I'm trying to make it possible to run a Rome vCPU on Milan or later.
> > > > >
> > > > > SInce this is a negative feature bit, it must be retained if the host
> > > > > reports it. That blocks running a Rome vCPU on Milan or later.
> > > > > However, a defeatured Rome (which reports LMSLE_MBZ as 1) can be run
> > > >
> > > > So, a partially defeatured Rome? Because it sounds like the CPU reports LMSLE_MBZ=1,
> > > > but then still allows setting EFER.LMSLE=1?
> > >
> > > No; it should not allow setting EFER.LMSLE=1. That will fail on later
> > > platforms and would block live migration from Rome to later platforms.
> >
> > Oh, drat, I misread the "Rome vCPU" vs. "defeatured Rome" paragraph. You want to
> > be able to migrate a vCPU with guest.CPUID.LMSLE_MBZ=1 between a non-defeatured,
> > vanilla Rome and Milan+ (or a defeatured Rome). Correct?
> >
> > If so, then Sashiko is right, the flag needs to be EMULATED_F() so that KVM will
> > advertise EFER_LMSLE_MBZ to userspace on the vanilla Rome host, and also do the
> > right thing when guest.CPUID.EFER_LMSLE_MBZ=0.
>
> No; that's wrong.
Heh, it's not "wrong" per se, just unwise :-)
> KVM_GET_SUPPORTED_CPUID should continue to report EferLmsleUnsupported=0 on
> Rome. Otherwise, we break backwards compatibility for userspace that simply
> transfers KVM_GET_SUPPORTED_CPUID to KVM_SET_CPUID[2] or userspace that just
> doesn't know anything about EferLmsleUnsupported. The "default" for Rome and
> older platforms should still be to claim support for EFER.LMSLE, even though
> that has always been a lie.
But you can't have it both ways, KVM can't enforce a bit it doesn't support.
> > If not correct, then I'm even more confused, because ignoring clear_cpuid,
> > guest_cpu_cap_has() will only ever return true if boot_cpu_has() also returns
> > true, in which case KVM *will* reject the value because EFER_LMSLE will not be
> > listed as a supported EFER bit.
> >
> > if (!boot_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ))
> > kvm_caps.supported_efer_bits |= EFER_LMSLE;
> >
> > > I want KVM to abide by the guest CPUID bit and disallow setting
> > > EFER.LMSLE even on hardware that allows it.
> >
> > Right, and that requires declaring EFER_LMSLE_MBZ with EMULATED_F().
>
> I think you and Sashiko are both wrong. PASSTHROUGH_F() is correct for this bit.
>
> I think I need to report EferLmsleUnsupported=1 in
> KVM_GET_EMULATED_CPUID, so that userspace knows it can opt-in if it
> wants to.
Hmm, I think we should have this be a "partially" emulated feature. KVM definitely
doesn't fully emulate LMSLE, and presumably anyone that cares about migrating
Rome vCPUs to Milan+ hosts is already advertising EFER_LMSLE_MBZ to the guest,
i.e. doesn't need identify which KVM version have the bug and which don't.
E.g. something like this?
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 38450e9fca9a..67807cd95958 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -1416,6 +1416,22 @@ static int cpuid_func_emulated(struct kvm_cpuid_entry2 *entry, u32 func, u32 ind
if (kvm_cpu_cap_has(X86_FEATURE_RDTSCP))
entry->ecx = feature_bit(RDPID);
return 1;
+ case 0x80000008:
+ /*
+ * Honor the guest's EFER_LMSLE_MBZ even if the underlying CPU
+ * allows setting EFER.LMSLE, e.g. to allowing migrating a vCPU
+ * between hosts with and without EFER.LMSLE support. To avoid
+ * breaking existing setups that reflect KVM's supported CPUID
+ * into the guest, KVM doesn't advertise EFER_LMSLE_MBZ unless
+ * it's supported by hardware, i.e. unless KVM *can't* support
+ * EFER.LMSLE=1.
+ */
+ if (include_partially_emulated &&
+ !kvm_cpu_cap_has(X86_FEATURE_EFER_LMSLE_MBZ)) {
+ entry->ebx |= feature_bit(EFER_LMSLE_MBZ);
+ return 1;
+ }
+ return 0;
default:
return 0;
}
prev parent reply other threads:[~2026-09-22 18:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 15:45 [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID Jim Mattson
2026-09-18 15:56 ` Sean Christopherson
2026-09-18 16:01 ` sashiko-bot
2026-09-22 13:57 ` Sean Christopherson
2026-09-22 14:20 ` Jim Mattson
2026-09-22 14:26 ` Sean Christopherson
2026-09-22 14:34 ` Jim Mattson
2026-09-22 17:53 ` Sean Christopherson
2026-09-22 18:08 ` Jim Mattson
2026-09-22 18:34 ` Sean Christopherson [this message]
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=arLKSkliAXuww3-0@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.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 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.