Re: [PATCH v5 07/35] x86: Introduce a centralized CPUID data model

Hi Boris,

On Fri, 16 Jan 2026, Borislav Petkov wrote:
>
> Btw, why are we calling them dynamic?
>
> This is confusing. Those leafs simply have multiple subleafs specified
> in ECX.
>
> Let's please not invent our own things here but simply stick to the
> nomenclature in the vendor docs.
>
> This is a very simple explanation IMO:
>
> "The information is accessed by (1) selecting the CPUID function setting
> EAX and optionally ECX for some functions,"
>
>
> and there's no talk about dynamic and whatnot.
>
...
>
> This is where the problem lies: you're calling static leaves those which
> have one subleaf and dynamic those which have multiple.
>
> But if one "static" leaf starts adding subleafs, the "static" one
> becomes "dynamic". And that's confusing. Nothing dynamic about it. You
> simply have CPUID leafs with 1 or more subleafs. And that should be the
> nomenclature we use.
>

Due to the differing leaf/subleaf output formats, at
arch/x86/include/asm/cpuid/leaf_types.h we have the storage types:

    struct leaf_0x4_n	{ ... };	// CPUID(0x4),  subleaves 0 -> n

    struct leaf_0xd_0	{ ... };	// CPUID(0xd),  subleaf 0
    struct leaf_0xd_1	{ ... };	// CPUID(0xd),  subleaf 1
    struct leaf_0xd_n	{ ... };	// CPUID(0xd),  subleaves 2 -> n

    struct leaf_0x10_0	{ ... };	// CPUID(0x10), subleaf 0
    struct leaf_0x10_n	{ ... };	// CPUID(0x10), subleaves 1 -> n

where "n" is known at runtime.

Then, for CPUID(0xd) subleaf 0 and 1 call sites we have:

    /*
     * "Static" access
     */

    const struct leaf_0xd_0 *ld_0;
    const struct leaf_0xd_1 *ld_1;

    ld_0 = cpuid_subleaf(c, 0xd, 0);
//                       |   |   └────────┐
//                       |   └─────────┐  |
//                       *             *  *
//  ld_0 =              &c.cpuid.leaf_0xd_0[0];

    ld_1 = cpuid_subleaf(c, 0xd, 1);
//                       |   |   └────────┐
//                       |   └─────────┐  |
//                       *             *  *
//  ld_1 =              &c.cpuid.leaf_0xd_1[0];

And for CPUID(0xd) subleaves 2 to n, we have:

    /*
     * "Dynamic" access
     */

    const struct leaf_0xd_n *ld;
    for (int i = XFEATURE_SSE; i < XFEATURE_MAX; i++) {
	ld = cpuid_subleaf_n(c, 0xd, i);
//                           |   |   └──────────┐
//                           |   └─────────┐    |
//                           *             *    *
//      ld =                &c.cpuid.leaf_0xd_n[i];
    }

Similarly, for CPUID(0x4) call sites we have:

    /*
     * "Dynamic" CPUID(0x4) subleaf access, 0 -> n
     */

    const struct leaf_0x4_n *l4;
    for (int i = 0; i < cpuid_subleaf_count(c, 0x4); i++) {

	l4 = cpuid_subleaf_n(c, 0x4, i);
//                           |   |   └──────────┐
//                           |   └─────────┐    |
//                           *             *    *
//      l4 =                &c.cpuid.leaf_0xd_n[i];
    }

So the root-cause of all these "static" vs. "dynamic" distinctions was to
catch call sites, at compile-time, when using the wrong CPUID storage
output type relative to the requested leaf/subleaf.

I'll get rid of this static/dynamic terminology and think of something
better.

(and an ACK for all the other snipped remarks.)

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH