From: Sean Christopherson <seanjc@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
tglx@linutronix.de, rafael@kernel.org, lenb@kernel.org
Subject: Re: [PATCH 11/11] x86/cpu: Make all all CPUID leaf names consistent
Date: Mon, 9 Dec 2024 08:27:58 -0800 [thread overview]
Message-ID: <Z1cajm9oqRZWDp_4@google.com> (raw)
In-Reply-To: <d6680add-f4d2-4d65-a711-3f80bfd43f6d@intel.com>
On Fri, Dec 06, 2024, Dave Hansen wrote:
> On 11/29/24 10:27, Borislav Petkov wrote:
> > Well, enum cpuid_leafs as it is now is the *indices* into the cap flags array:
> >
> > struct cpuinfo_x86 {
> >
> > ...
> >
> > __u32 x86_capability[NCAPINTS + NBUGINTS];
> >
> > And having a "CPUID_" prefixed thing and a "CPUID_LEAF_" prefixed other thing
> > is going to cause confusion.
+1.
What about CPUID_FN_xxx for thing architectural leaf function number? E.g.
CPUID_FN_80000007 or maybe even CPUID_FN_0x80000007. CPUID_LEAF_xxx is arguably
wrong anyways for entries with sub-leaves.
There's still potential for confusion, but I think it would be clear enough to
be offset by the niceness of replacing all the open coded CPUID function literals.
> > And renaming enum cpuid_leafs is going to cause a massive churn...
>
> Wait a sec though:
>
> $ git grep 'enum cpuid_leafs' arch/x86/
> arch/x86/include/asm/cpufeature.h:enum cpuid_leafs
> arch/x86/kvm/cpuid.c:static __always_inline void kvm_cpu_cap_mask(enum
> cpuid_leafs leaf, u32 mask)
>
> So there is only one direct reference to the type.
>
> I think all it will take to rename the _type_ is something like the
> attached. Also, I think the new name 'x86_capability_words' and variable
> 'cap_nr' make the KVM site a lot more readable.
KVM's usage of the type will be gone in 6.14[*] (not yet applied, but it will be,
soon). Unless renaming the enum type is central to your plans, maybe just wait
until after 6.14 to clean that up? Note, we should also rename KVM's enum
kvm_only_cpuid_leafs to align with whatever the new enum name ends up being.
As for "cap_nr", IMO that is a net negative relative to "leaf". For all CPUID
leaves that KVM cares about, the array entry is guaranteed to correspond to a
single CPUID leaf, albeit for only one output register. KVM has definitely
bastardized "leaf", but I do think it helps convey that the "word" being modified
corresponds 1:1 with a specific CPUID leaf output.
[*] https://lore.kernel.org/all/20241128013424.4096668-27-seanjc@google.com
next prev parent reply other threads:[~2024-12-09 16:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 21:33 [PATCH 00/11] x86/cpu: Centralize and standardize CPUID leaf naming Dave Hansen
2024-10-30 21:33 ` [PATCH 01/11] x86/cpu: Move MWAIT leaf definition to common header Dave Hansen
2024-10-30 21:33 ` [PATCH 02/11] x86/cpu: Use MWAIT leaf definition Dave Hansen
2024-10-30 21:33 ` [PATCH 03/11] x86/cpu: Remove unnecessary MwAIT leaf checks Dave Hansen
2024-10-30 21:33 ` [PATCH 04/11] x86/acpi: Check MWAIT feature instead of CPUID level Dave Hansen
2024-10-30 21:33 ` [PATCH 05/11] x86/cpu: Move DCA leaf definition Dave Hansen
2024-10-30 21:33 ` [PATCH 06/11] x86/cpu: Move TSC CPUID " Dave Hansen
2024-10-30 21:33 ` [PATCH 07/11] x86/tsc: Move away from TSC leaf magic numbers Dave Hansen
2024-10-30 21:33 ` [PATCH 08/11] x86/tsc: Remove CPUID "frequency" " Dave Hansen
2024-10-30 21:33 ` [PATCH 09/11] x86/fpu: Move CPUID leaf definitions to common code Dave Hansen
2024-10-30 21:33 ` [PATCH 10/11] x86/fpu: Remove unnecessary CPUID level check Dave Hansen
2024-10-30 21:33 ` [PATCH 11/11] x86/cpu: Make all all CPUID leaf names consistent Dave Hansen
2024-10-31 10:18 ` Borislav Petkov
2024-10-31 17:19 ` Dave Hansen
2024-11-29 18:27 ` Borislav Petkov
2024-12-06 23:01 ` Dave Hansen
2024-12-09 16:27 ` Sean Christopherson [this message]
2024-12-09 17:25 ` Dave Hansen
2024-12-09 20:23 ` Sean Christopherson
2024-12-10 11:28 ` Borislav Petkov
2024-12-10 11:19 ` Borislav Petkov
-- strict thread matches above, loose matches on Subject: below --
2024-11-20 19:53 [PATCH 00/11] x86/cpu: Centralize and standardize CPUID leaf naming Dave Hansen
2024-11-20 19:53 ` [PATCH 11/11] x86/cpu: Make all all CPUID leaf names consistent Dave Hansen
2024-11-20 20:23 ` Dave Jiang
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=Z1cajm9oqRZWDp_4@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox