[PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[Jim Mattson]

Reject guest writes to EFER (and nested VMRUN with VMCB12 EFER) that set
EFER.LMSLE when CPUID.80000008H:EBX.EferLmsleUnsupported[bit 20] is set
in the guest's CPUID.

Commit c53c632592a4 ("KVM: SVM: Disallow EFER.LMSLE when not supported by
hardware") prevented EFER.LMSLE from being enabled in supported_efer_bits
on hosts that set EferLmsleUnsupported, but missed checking the guest
CPUID capability in __kvm_valid_efer(). As a result, on a host that
supports EFER.LMSLE (e.g. Rome), a guest whose userspace VMM sets
EferLmsleUnsupported in guest CPUID (e.g. for migration compatibility
with Milan, Genoa, or Turin) can still set EFER.LMSLE without triggering
a #GP.

Fixes: c53c632592a4 ("KVM: SVM: Disallow EFER.LMSLE when not supported by hardware")
Assisted-by: LLM
Signed-off-by: Jim Mattson <jmattson@google.com>
---
 arch/x86/kvm/msrs.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
index dd3bb04878ca..6dbaf063cc8d 100644
--- a/arch/x86/kvm/msrs.c
+++ b/arch/x86/kvm/msrs.c
@@ -598,8 +598,11 @@ static bool __kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
 	if (efer & EFER_NX && !guest_cpu_cap_has(vcpu, X86_FEATURE_NX))
 		return false;
 
-	return true;
+	if (efer & EFER_LMSLE &&
+	    guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ))
+		return false;
 
+	return true;
 }
 bool kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
 {
-- 
2.55.0.1082.g2b9226bbc0-goog

Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[Sean Christopherson]

On Fri, Sep 18, 2026, Jim Mattson wrote:
> Reject guest writes to EFER (and nested VMRUN with VMCB12 EFER) that set
> EFER.LMSLE when CPUID.80000008H:EBX.EferLmsleUnsupported[bit 20] is set
> in the guest's CPUID.
> 
> Commit c53c632592a4 ("KVM: SVM: Disallow EFER.LMSLE when not supported by
> hardware") prevented EFER.LMSLE from being enabled in supported_efer_bits
> on hosts that set EferLmsleUnsupported, but missed checking the guest
> CPUID capability in __kvm_valid_efer(). As a result, on a host that
> supports EFER.LMSLE (e.g. Rome), a guest whose userspace VMM sets
> EferLmsleUnsupported in guest CPUID (e.g. for migration compatibility
> with Milan, Genoa, or Turin) can still set EFER.LMSLE without triggering
> a #GP.
> 
> Fixes: c53c632592a4 ("KVM: SVM: Disallow EFER.LMSLE when not supported by hardware")
> Assisted-by: LLM
> Signed-off-by: Jim Mattson <jmattson@google.com>
> ---
>  arch/x86/kvm/msrs.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
> index dd3bb04878ca..6dbaf063cc8d 100644
> --- a/arch/x86/kvm/msrs.c
> +++ b/arch/x86/kvm/msrs.c
> @@ -598,8 +598,11 @@ static bool __kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
>  	if (efer & EFER_NX && !guest_cpu_cap_has(vcpu, X86_FEATURE_NX))
>  		return false;
>  
> -	return true;
> +	if (efer & EFER_LMSLE &&
> +	    guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ))
> +		return false;
>  
> +	return true;

In case anyone else was wondering, this is NOT whitespace damage, the "movement"
of the "return true" is due to deleting a trailing spurious newline, e.g. my
configuration of diff yeilds:

diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
index dd3bb04878ca..6dbaf063cc8d 100644
--- a/arch/x86/kvm/msrs.c
+++ b/arch/x86/kvm/msrs.c
@@ -598,8 +598,11 @@ static bool __kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
 	if (efer & EFER_NX && !guest_cpu_cap_has(vcpu, X86_FEATURE_NX))
 		return false;
 
+	if (efer & EFER_LMSLE &&
+	    guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ))
+		return false;
+
 	return true;
-
 }
 bool kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
 {

Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: x86: EFER.LMSLE fix is ineffective due to dropped CPUID bit
--

commit 0daddb3cb6cd07afcd9545a8e1643427a1542393
Author: Jim Mattson <jmattson@google.com>

KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

This commit updates KVM to reject guest writes to EFER that set EFER.LMSLE
when the EferLmsleUnsupported bit is set in the guest's CPUID. It aims to fix
an issue where a guest could enable EFER.LMSLE on hosts that support it, even
if the VMM hid the feature for migration compatibility.

> diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
> index 37d5bed3529f5..c8f894ccfb0f9 100644
> --- a/arch/x86/kvm/msrs.c
> +++ b/arch/x86/kvm/msrs.c
> @@ -598,8 +598,11 @@ static bool __kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
>  	if (efer & EFER_NX && !guest_cpu_cap_has(vcpu, X86_FEATURE_NX))
>  		return false;
>  
> -	return true;
> +	if (efer & EFER_LMSLE &&
> +	    guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ))

[Severity: High]
Does this check actually work as intended on hosts that support LMSLE?

Because X86_FEATURE_EFER_LMSLE_MBZ is defined as a PASSTHROUGH_F,
kvm_cpu_cap_init() clears this bit in kvm_cpu_caps when the host hardware
CPUID does not set it (which is the case when the host supports LMSLE).

Since the bit is missing from kvm_cpu_caps and is not an EMULATED_F,
kvm_set_cpuid() ANDs the VMM-provided CPUID with 0 for this capability.
Consequently, vcpu->arch.cpu_caps does not retain the bit, and
guest_cpu_cap_has() here will unconditionally return false.

Does this mean the bug remains triggerable by a guest running on a host with
LMSLE support when the VMM attempts to hide the feature?

> +		return false;
>  
> +	return true;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918154530.4129698-1-jmattson@google.com?part=1

Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[Sean Christopherson]

On Fri, Sep 18, 2026, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] kvm: x86: EFER.LMSLE fix is ineffective due to dropped CPUID bit
> --
> 
> commit 0daddb3cb6cd07afcd9545a8e1643427a1542393
> Author: Jim Mattson <jmattson@google.com>
> 
> KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID
> 
> This commit updates KVM to reject guest writes to EFER that set EFER.LMSLE
> when the EferLmsleUnsupported bit is set in the guest's CPUID. It aims to fix
> an issue where a guest could enable EFER.LMSLE on hosts that support it, even
> if the VMM hid the feature for migration compatibility.
> 
> > diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
> > index 37d5bed3529f5..c8f894ccfb0f9 100644
> > --- a/arch/x86/kvm/msrs.c
> > +++ b/arch/x86/kvm/msrs.c
> > @@ -598,8 +598,11 @@ static bool __kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
> >  	if (efer & EFER_NX && !guest_cpu_cap_has(vcpu, X86_FEATURE_NX))
> >  		return false;
> >  
> > -	return true;
> > +	if (efer & EFER_LMSLE &&
> > +	    guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ))
> 
> [Severity: High]
> Does this check actually work as intended on hosts that support LMSLE?
>
> Because X86_FEATURE_EFER_LMSLE_MBZ is defined as a PASSTHROUGH_F,
> kvm_cpu_cap_init() clears this bit in kvm_cpu_caps when the host hardware
> CPUID does not set it (which is the case when the host supports LMSLE).
> 
> Since the bit is missing from kvm_cpu_caps and is not an EMULATED_F,
> kvm_set_cpuid() ANDs the VMM-provided CPUID with 0 for this capability.
> Consequently, vcpu->arch.cpu_caps does not retain the bit, and
> guest_cpu_cap_has() here will unconditionally return false.
> 
> Does this mean the bug remains triggerable by a guest running on a host with
> LMSLE support when the VMM attempts to hide the feature?

Gah, I hate the negative "feature" bits, I've gotten completely turned around
multiple times trying to sort through this.

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.

Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[Jim Mattson]

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
on Milan and later.

It's the same feature-hiding we do all of the time—just inverted.

Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[Sean Christopherson]

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?

> on Milan and later.
> 
> It's the same feature-hiding we do all of the time—just inverted.

Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[Jim Mattson]

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.

I want KVM to abide by the guest CPUID bit and disallow setting
EFER.LMSLE even on hardware that allows it.

Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[Sean Christopherson]

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.

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().

Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[Jim Mattson]

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. 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.

> 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.

Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID

[Sean Christopherson]

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;
 	}