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.