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.
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.
Greetings, Max