From: Ingo Molnar <mingo@kernel.org>
To: "Ahmed S. Darwish" <darwi@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Cooper <andrew.cooper3@citrix.com>,
"H. Peter Anvin" <hpa@zytor.com>,
John Ogness <john.ogness@linutronix.de>,
x86@kernel.org, x86-cpuid@lists.linux.dev,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 00/26] x86: Introduce centralized CPUID model
Date: Tue, 6 May 2025 11:12:34 +0200 [thread overview]
Message-ID: <aBnSgu_JyEi8fvog@gmail.com> (raw)
In-Reply-To: <20250506050437.10264-1-darwi@linutronix.de>
* Ahmed S. Darwish <darwi@linutronix.de> wrote:
> MAINTAINERS | 1 +
> arch/x86/include/asm/cpu.h | 6 +
> arch/x86/include/asm/cpuid.h | 1 +
> arch/x86/include/asm/cpuid/internal_api.h | 62 +
> arch/x86/include/asm/cpuid/leaf_0x2_api.h | 57 +-
> arch/x86/include/asm/cpuid/leaves.h | 2055 +++++++++++++++++++++
> arch/x86/include/asm/cpuid/table_api.h | 120 ++
> arch/x86/include/asm/cpuid/types.h | 74 +
> arch/x86/include/asm/processor.h | 1 +
> arch/x86/kernel/cpu/Makefile | 2 +
> arch/x86/kernel/cpu/cacheinfo.c | 280 +--
> arch/x86/kernel/cpu/common.c | 65 +-
> arch/x86/kernel/cpu/cpuid_debugfs.c | 98 +
> arch/x86/kernel/cpu/cpuid_scanner.c | 209 +++
> arch/x86/kernel/cpu/cpuid_scanner.h | 117 ++
> arch/x86/kernel/cpu/intel.c | 17 +-
> arch/x86/lib/cpu.c | 41 +-
> tools/arch/x86/kcpuid/cpuid.csv | 4 +-
> 18 files changed, 2926 insertions(+), 284 deletions(-)
> create mode 100644 arch/x86/include/asm/cpuid/internal_api.h
> create mode 100644 arch/x86/include/asm/cpuid/leaves.h
> create mode 100644 arch/x86/include/asm/cpuid/table_api.h
> create mode 100644 arch/x86/kernel/cpu/cpuid_debugfs.c
> create mode 100644 arch/x86/kernel/cpu/cpuid_scanner.c
> create mode 100644 arch/x86/kernel/cpu/cpuid_scanner.h
Regarding CPUID header organization:
- Please move <asm/cpuid/internal_api.h> into <asm/cpuid/table_api.h>.
There's not really much point to making it 'internal' AFAICS, as the
main <asm/cpuid.h> header already includes <asm/cpuid/table_api.h>
and <asm/cpuid/internal_api.h> respectively, so it's not all so much
internal anymore.
- Please just use a single central API header: <asm/cpuid/api.h>, and
remove <asm/cpuid.h>. It's confusing to have both <asm/cpuid.h> and
a proper <asm/cpuid/> header hierarchy.
( I wanted to point to <asm/fpu/api.h> as the shining example to
follow, but then I noticed that somehow we grew a <asm/fpu.h> wart
last year via b0b8a15bb89e. Will fix that ... )
- Is there a strong reason to keep <asm/cpuid/leaf_0x2_api.h>? I think
for_each_leaf_0x2_entry() could just be moved into
<asm/cpuid/api.h>, it's one of the accessors.
- In a similar vein, I don't see much point of keeping
<asm/cpuid/table_api.h> header separate either. <asm/cpuid/api.h>
won't be overly large I think.
- Could we rename <asm/cpuid/leaves.h> to <asm/cpuid/leaf_types.h> or
so? It's really a sub-header of <asm/cpuid/types.h> and should thus
share the nomenclature.
- After all this we'll only have 3 headers left:
<asm/cpuid/types.h>
<asm/cpuid/leaf_types.h>
<asm/cpuid/api.h>
And <asm/cpuid/leaf_types.h> is only a separate header because it's
autogenerated by an external project.
- Wrt. <asm/cpuid/api.h>, we'll need a few followup cleanups there too
I think, such as migrating to the cpuid_*() namespace:
- Rename have_cpuid_p() to cpuid_feature() or so.
- I find the cpudata_cpuid_ namespace a bit confusing:
__cpudata_cpuid_subleaf_idx(__table, __leaf, __subleaf, __idx)
__cpudata_cpuid_subleaf(__table, __leaf, __subleaf)
cpudata_cpuid_subleaf(_cpuinfo, _leaf, _subleaf)
cpudata_cpuid(_cpuinfo, _leaf)
cpudata_cpuid_nr_entries(_cpuinfo, _leaf)
cpudata_cpuid_index(_cpuinfo, _leaf, _idx)
cpudata_cpuid_regs(_cpuinfo, _leaf)
cpudata_cpuid_index_regs(_cpuinfo, _leaf, _idx)
All of CPUID processing is related to 'data', and we don't
really have any 'cpudata' primitives, so the cpudata_ prefix is
confusing to me.
It's particularly confusing for methods like cpudata_cpuid(),
which sounds like a generic method, while in reality it accesses
subleaf 0, right? Why not name it cpuid_subleaf_0() or so?
My suggestion would be to use a structure like this:
__cpuid_subleaf_idx(__table, __leaf, __subleaf, __idx)
__cpuid_subleaf(__table, __leaf, __subleaf)
cpuid_subleaf(_cpuinfo, _leaf, _subleaf)
cpuid_subleaf_0(_cpuinfo, _leaf)
cpuid_leaf_nr_entries(_cpuinfo, _leaf)
cpuid_leaf_index(_cpuinfo, _leaf, _idx)
cpuid_leaf_regs(_cpuinfo, _leaf)
cpuid_leaf_index_regs(_cpuinfo, _leaf, _idx)
Or so? In my book it's a nice bonus that they thus become part
of the overall cpuid_*() API family. Note how these accessors
still are all still either cpuid_leaf_ or cpuid_subleaf_
prefixed.
Thanks,
Ingo
next prev parent reply other threads:[~2025-05-06 9:12 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 5:04 [PATCH v1 00/26] x86: Introduce centralized CPUID model Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 01/26] tools/x86/kcpuid: Update bitfields to x86-cpuid-db v2.4 Ahmed S. Darwish
2025-05-06 8:06 ` [tip: x86/cpu] " tip-bot2 for Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 02/26] x86/cpu: Sanitize CPUID(0x80000000) output Ahmed S. Darwish
2025-05-06 8:15 ` [tip: x86/cpu] " tip-bot2 for Ahmed S. Darwish
2025-05-07 8:50 ` [PATCH v1 02/26] " Andrew Cooper
2025-05-08 20:40 ` H. Peter Anvin
2025-05-08 20:58 ` Andrew Cooper
2025-05-08 22:37 ` H. Peter Anvin
2025-05-09 9:23 ` Ahmed S. Darwish (dev)
2025-05-06 5:04 ` [PATCH v1 03/26] x86/cpuid: Introduce <asm/cpuid/leaves.h> Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 04/26] x86/cpuid: Introduce centralized CPUID data Ahmed S. Darwish
2025-05-14 4:18 ` Sohil Mehta
2025-05-15 21:23 ` Ahmed S. Darwish
2025-05-15 22:12 ` Sohil Mehta
2025-05-06 5:04 ` [PATCH v1 05/26] x86/cpuid: Introduce CPUID scanner Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 06/26] x86/cpuid: Scan CPUID(0x80000000) Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 07/26] x86/cpuid: Introduce debugfs 'x86/scanned_cpuid/[0-ncpus]' Ahmed S. Darwish
2025-05-14 2:56 ` Sohil Mehta
2025-05-15 21:04 ` Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 08/26] x86/cpuid: Introduce external CPUID table accessors Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 09/26] x86/cpu: Use scanned CPUID(0x0) Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 10/26] x86/cpu: Use scanned CPUID(0x80000001) Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 11/26] x86/lib: Add CPUID(0x1) CPU family and model calculation Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 12/26] x86/cpu: Use scanned CPUID(0x1) Ahmed S. Darwish
2025-05-06 8:25 ` Ingo Molnar
2025-05-07 7:36 ` Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 13/26] x86/cpuid: Scan CPUID(0x2) Ahmed S. Darwish
2025-05-06 8:16 ` Ingo Molnar
2025-05-06 8:47 ` Ahmed S. Darwish
2025-05-06 10:39 ` Ingo Molnar
2025-05-06 5:04 ` [PATCH v1 14/26] x86/cpuid: Introduce scanned CPUID(0x2) API Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 15/26] x86/cpu: Use scanned CPUID(0x2) Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 16/26] x86/cacheinfo: " Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 17/26] x86/cpuid: Remove direct CPUID(0x2) query API Ahmed S. Darwish
2025-05-06 8:59 ` Ingo Molnar
2025-05-07 9:15 ` Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 18/26] x86/cpuid: Scan deterministic cache params CPUID leaves Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 19/26] x86/cacheinfo: Use scanned CPUID(0x4) Ahmed S. Darwish
2025-05-06 8:10 ` Ingo Molnar
2025-05-06 8:50 ` Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 20/26] x86/cacheinfo: Use scanned CPUID(0x8000001d) Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 21/26] x86/cpuid: Scan CPUID(0x80000005) and CPUID(0x80000006) Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 22/26] x86/cacheinfo: Use auto-generated data types Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 23/26] x86/cacheinfo: Use scanned CPUID(0x80000005) and CPUID(0x80000006) Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 24/26] x86/cpuid: scanner: Add CPUID table rescan support Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 25/26] x86/cpu: Rescan CPUID table after PSN disable Ahmed S. Darwish
2025-05-06 5:04 ` [PATCH v1 26/26] x86/cpu: Rescan CPUID table after unlocking the full CPUID range Ahmed S. Darwish
2025-05-06 8:23 ` [PATCH v1 00/26] x86: Introduce centralized CPUID model Ingo Molnar
2025-05-06 8:48 ` Ahmed S. Darwish
2025-05-06 9:12 ` Ingo Molnar [this message]
2025-05-07 8:35 ` Ahmed S. Darwish
2025-05-07 8:45 ` Ahmed S. Darwish
2025-05-07 9:32 ` Ahmed S. Darwish
2025-05-09 9:28 ` Ahmed S. Darwish (dev)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aBnSgu_JyEi8fvog@gmail.com \
--to=mingo@kernel.org \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=darwi@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86-cpuid@lists.linux.dev \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.