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