linux-kernel - Re: [PATCH v1 00/26] x86: Introduce centralized CPUID model

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aBsbTiBuWmUC3QaP@lx-t490>
Date: Wed, 7 May 2025 10:35:26 +0200
From: "Ahmed S. Darwish" <darwi@...utronix.de>
To: Ingo Molnar <mingo@...nel.org>
Cc: Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	John Ogness <john.ogness@...utronix.de>, x86@...nel.org,
	x86-cpuid@...ts.linux.dev, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 00/26] x86: Introduce centralized CPUID model

On Tue, 06 May, Ingo Molnar wrote:
>
> 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.
>

Yeah, will do.

>
>  - 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.
>

Correct, it aligns much better; will do.

>
>  - 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.
>
>  - After all this we'll only have 3 headers left:
>
> 	<asm/cpuid/types.h>
> 	<asm/cpuid/leaf_types.h>
> 	<asm/cpuid/api.h>
>

The idea (which I admit was not properly executed) was to sepearate the
(quite large) CPUID "raw operations" header with cpuid(), cpuid_count(),
and cpuid_subleaf() from the new "CPUID API" work like cpudata_cpuid(),
cpudata_cpuid_subleaf() and for_each_leaf_0x2_entry().

This way, after all this new CPUID work gets more established, the CPUID
raw operations becomes an implementation detail that call sites should
not be encouraged much to look at.

Would you be OK with at least having:

    asm/cpuid/
    ├── raw.h		Raw CPUID ops; what is now <asm/cpuid/api.h>
    ├── api.h		Everything else (CPUID model API, CPUID(0x2) API, ..)
    ├── leaf_types.h
    └── types.h

because if I merge raw.h and api.h, the new CPUID APIs (which people
should be encouraged to use) would be so deep in the new merged header it
will be no longer visible.

What do you think?

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH