Re: [PATCH v7 107/120] x86/cpuid: Parse leaves backing X86_FEATURE words
Maciej Wieczor-Retman <[email protected]> Tue, 2 Jun 2026 20:26:40 +0200
| Newsgroups | dev.linux.lists.x86-cpuid,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 2026-05-28 at 17:39:09 +0200, Ahmed S. Darwish wrote: >Add CPUID parser support for: > > CPUID(0x7) > CPUID(0x7).1 > CPUID(0xd).1 > CPUID(0x80000001) > CPUID(0x8000000a) > CPUID(0x8000001f) > CPUID(0x80000021) > >where one or more of these leaves output registers back the X86_FEATURE >words at <asm/cpufeatures.h>. > >Handle CPUID(0x7).1 via a custom reader. Its availability depends on the >subleaf count reported by CPUID(0x7).0, so check that first. > >Do not use a custom reader for CPUID(0xd).1. Per the Intel SDM regarding >CPUID(0xd)'s subleaf availability: "sub-leafs 0 and 1 are always valid". > >Note, this prepares for later changes that will route X86_FEATURE queries >from cpuinfo_x86::x86_capability[] to the system's CPUID tables. > >Signed-off-by: Ahmed S. Darwish <[email protected]> >--- > arch/x86/include/asm/cpuid/types.h | 7 +++++++ > arch/x86/kernel/cpu/cpuid_parser.c | 13 +++++++++++++ > arch/x86/kernel/cpu/cpuid_parser.h | 7 +++++++ > 3 files changed, 27 insertions(+) > >diff --git a/arch/x86/include/asm/cpuid/types.h b/arch/x86/include/asm/cpuid/types.h >index 7671f8d24014..1de66781cb5c 100644 >--- a/arch/x86/include/asm/cpuid/types.h >+++ b/arch/x86/include/asm/cpuid/types.h >@@ -214,8 +214,11 @@ struct cpuid_leaves { > CPUID_LEAF_N ( 0x4, 8 ); > CPUID_LEAF ( 0x5, 0 ); > CPUID_LEAF ( 0x6, 0 ); >+ CPUID_LEAF ( 0x7, 0 ); >+ CPUID_LEAF ( 0x7, 1 ); > CPUID_LEAF ( 0x9, 0 ); > CPUID_LEAF ( 0xa, 0 ); >+ CPUID_LEAF ( 0xd, 1 ); I think I found one mismatch using your lovely debugfs features :) Specifically seems that CPU0 mismatches on EBX in leaf 0xD, subleaf 1: Leaf 0x0000000d, subleaf 1: cached: EAX=0x0000000f *EBX=0x00000240 ECX=0x0000dd00 EDX=0x00000000 actual: EAX=0x0000000f EBX=0x000006a0 ECX=0x0000dd00 EDX=0x00000000 EBX reports 'the size in bytes of the xsave area containing all states enabled by XCR0 | IA32_XSS'. Because all the other CPUs are fine (no mismatch) it looks like boot cpu didn't get updated after the xsave area size was updated. From some digging around I believe the update gets done in get_xsave_compacted_size() (MSR_IA32_XSS is updated) Going back up the call chain I arrived at all the fpu init code. I have no idea if this is the right way to fix it but the below snippet does eliminate the mismatch: arch/x86/kernel/cpu/common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 8c52503ae360..2a4fa4760025 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2566,6 +2566,8 @@ void __init arch_cpu_finalize_init(void) fpu__init_system(); fpu__init_cpu(); + cpuid_refresh_leaf(&boot_cpu_data, 0xd); + /* * This needs to follow the FPU initializtion, since EFI depends on it. */ -- 2.53.0 -- Kind regards Maciej Wieczór-Retman