[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aXdmc6F5wLthVDEU@lx-t490>
Date: Mon, 26 Jan 2026 14:04:51 +0100
From: "Ahmed S. Darwish" <darwi@...utronix.de>
To: Borislav Petkov <bp@...en8.de>
Cc: Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Cooper <andrew.cooper3@...rix.com>,
Sean Christopherson <seanjc@...gle.com>,
David Woodhouse <dwmw2@...radead.org>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Sohil Mehta <sohil.mehta@...el.com>,
John Ogness <john.ogness@...utronix.de>, x86@...nel.org,
x86-cpuid@...ts.linux.dev, LKML <linux-kernel@...r.kernel.org>
Subject: 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
Powered by blists - more mailing lists