On Thu, Feb 27, 2025 at 09:02:22PM -0000, tip-bot2 for Max Grobecker wrote: > This can prevent some docker containers from starting or build scripts to create > unoptimized binaries. Who does docker containers with a K8 CPU model? What's the advantage? > Admittably, this is more a small inconvenience than a severe bug in the kernel > and the shoddy scripts that rely on parsing /proc/cpuinfo > should be fixed instead. Yes. I find such "wag-the-dog" patches awful. > This patch adds an additional check to see if we're running inside a Avoid having "This patch" or "This commit" in the commit message. It is tautologically useless. Also, do $ git grep 'This patch' Documentation/process for more details. > virtual machine (X86_FEATURE_HYPERVISOR is present), which, to my > understanding, can't be present on a real K8 processor as it was introduced > only with the later/other Athlon64 models. > > Example output with the "lahf_lm" flag missing in the flags list > (should be shown between "hypervisor" and "abm"): > > $ cat /proc/cpuinfo > processor : 0 > vendor_id : AuthenticAMD > cpu family : 15 > model : 6 > model name : Common KVM processor > stepping : 1 > microcode : 0x1000065 > cpu MHz : 2599.998 > cache size : 512 KB > physical id : 0 > siblings : 1 > core id : 0 > cpu cores : 1 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 13 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp > lm rep_good nopl cpuid extd_apicid tsc_known_freq pni > pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt > tsc_deadline_timer aes xsave avx f16c hypervisor abm > 3dnowprefetch vmmcall bmi1 avx2 bmi2 xsaveopt This dump is purely useless - it is clear what the code does currently. No need to dump it. > > ... while kcpuid shows the feature to be present in the CPU: > > # kcpuid -d | grep lahf > lahf_lm - LAHF/SAHF available in 64-bit mode > > [ mingo: Updated the comment a bit. ] > > Signed-off-by: Max Grobecker <max@xxxxxxxxxxxxxx> > Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx> > Cc: Borislav Petkov <bp@xxxxxxxxx> > Link: https://lore.kernel.org/r/533f9cf-1957-41e8-a8cc-ddce5438f658-max@xxxxxxxxxxxxxx > --- > arch/x86/kernel/cpu/amd.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c > index 54194f5..c1f0a5f 100644 > --- a/arch/x86/kernel/cpu/amd.c > +++ b/arch/x86/kernel/cpu/amd.c > @@ -631,8 +631,11 @@ static void init_amd_k8(struct cpuinfo_x86 *c) > * Some BIOSes incorrectly force this feature, but only K8 revision D > * (model = 0x14) and later actually support it. > * (AMD Erratum #110, docId: 25759). > + * Only clear capability flag if we're running on baremetal, > + * as we might see a wrong model ID as a guest kernel. In such a case, > + * we can safely assume we're not affected by this erratum. > */ This comment needs to be in the commit message - we don't document every use of X86_FEATURE_HYPERVISOR. > - if (c->x86_model < 0x14 && cpu_has(c, X86_FEATURE_LAHF_LM)) { > + if (c->x86_model < 0x14 && cpu_has(c, X86_FEATURE_LAHF_LM) && !cpu_has(c, X86_FEATURE_HYPERVISOR)) { > clear_cpu_cap(c, X86_FEATURE_LAHF_LM); > if (!rdmsrl_amd_safe(0xc001100d, &value)) { > value &= ~BIT_64(32); But again, I'm very sceptical about K8 and docker containers and don't buy it. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
![]() |