Re: [PATCH AUTOSEL 5.10 2/6] x86/cpu: Don't clear X86_FEATURE_LAHF_LM flag in init_amd_k8() on AMD when running in a virtual machine

[Sean Christopherson <seanjc@google.com>]

On Fri, Apr 18, 2025, Borislav Petkov wrote:
> On Fri, Apr 18, 2025 at 10:19:14AM -0700, Sean Christopherson wrote:
> > Uh, and the hypervisor too?  Why is the hypervisor enumerating an old K8 CPU for
> > what appears to be a modern workload?
> > 
> > > I'd say this is not good stable candidate.
> > 
> > Eh, practically speaking, there's no chance of this causing problems.  The setup
> > is all kinds of weird, but AIUI, K8 CPUs don't support virtualization so there's
> > no chance that the underlying CPU is actually affected by the K8 bug, because the
> > underlying CPU can't be K8.  And no bare metal CPU will ever set the HYPERVISOR
> > bit, so there won't be false positives on that front.
> > 
> > I personally object to the patch itself; it's not the kernel's responsibility to
> > deal with a misconfigured VM.  But unless we revert the commit, I don't see any
> > reason to withhold this from stable@.
> 
> I objected back then but it is some obscure VM migration madness (pasting the
> whole reply here because it didn't land on any ML):
> 
> Date: Tue,  17 Dec 2024 21:32:21 +0100
> From: Max Grobecker <max@grobecker.info>
> To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
>  Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Max Grobecker <max@grobecker.info>, x86@kernel.org
> Subject: Re: [PATCH v2] Don't clear X86_FEATURE_LAHF_LM flag in init_amd_k8()
>  on AMD when running in a virtual machine
> Message-ID: <d77caeea-b922-4bf5-8349-4b5acab4d2eb>
> MIME-Version: 1.0
> Content-Transfer-Encoding: 8bit
> Content-Type: text/plain; charset=utf-8
> 
> Hi,
> 
> sorry for my late response, was hit by a flu last days.
> 
> On Tue, 10 Dec 2024 13:51:50 +0100, Borislav Petkov wrote:
> > Lemme get this straight: you - I don't know who "we" is - are running K8
> > models in guests? Why?
> 
> Oh, I see, I missed to explain that, indeed.
> 
> This error happens, when I start a virtual machine using libvirt/QEMU while 
> not passing through the host CPU. I do this, because I want to be 
> able to live-migrate the VM between hosts, that have slightly different CPUs.
> Migration works, but only if I choose the generic "kvm64" CPU preset to be
> used with QEMU using the "-cpu kvm64" parameter:
>  
>   qemu-system-x86_64 -cpu kvm64
>  
> I also explicitly enabled additional features like SSE4.1 or AXV2 to have as
> most features as I can but still being able to do live-migration between hosts.
>   
> By using this config, the CPU is identified as "Common KVM processor"
> inside the VM:
> 
>   processor       : 0
>   vendor_id       : AuthenticAMD
>   cpu family      : 15
>   model           : 6
>   model name      : Common KVM processor
> 
> Also, the model reads as 0x06, which is set by that kvm64 CPU preset,
> but usually does not pose a problem.

IMO, this is blatantly a QEMU bug (I verified the behavior when using "kvm64" on AMD).
As per QEMU commit d1cd4bf419 ("introduce kvm64 CPU"), the vendor + FMS enumerates
an Intel P4:

        .name = "kvm64",
        .level = 0xd,
        .vendor = CPUID_VENDOR_INTEL,
        .family = 15,
        .model = 6,

Per x86_cpu_load_model(), QEMU overrides the vendor when using KVM (at a glance,
I can't find the code that actually overrides the vendor, gotta love QEMU's object
model):

    /*
     * vendor property is set here but then overloaded with the
     * host cpu vendor for KVM and HVF.
     */
    object_property_set_str(OBJECT(cpu), "vendor", def->vendor, &error_abort);

Overriding the vendor but using Intel's P4 FMS is flat out wrong.  IMO, QEMU
should use the same FMS as qemu64 for kvm64 when running on AMD.

        .name = "qemu64",
        .level = 0xd,
        .vendor = CPUID_VENDOR_AMD,
        .family = 15,
        .model = 107,
        .stepping = 1,

Yeah, scraping FMS information is a bad idea, but what QEMU is doing is arguably
far worse.

> The original vendor id of the host CPU is still visible to the guest, and in
> case the host uses an AMD CPU the combination of "AuthenticAMD" and model 0x06
> triggers the bug and the lahf_lm flag vanishes.
> If the guest is running with the same settings on an Intel CPU and therefore 
> reads "GenuineIntel" as the vendor string, the model is still 0x06, but also 
> the lahf_lm flag is still listed in /proc/cpuinfo.
> 
> The CPU is mistakenly identified to be an AMD K8 model, while, in fact, nearly
> all features a modern Epyc or Xeon CPU is offering, are available.