Re: [PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>

[H. Peter Anvin]

On March 18, 2025 12:09:59 PM PDT, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>On 18/03/2025 6:48 pm, H. Peter Anvin wrote:
>> One more thing is that we ought to be able to make cpuid a const function, allowing the compiler to elide multiple calls. (Slight warning for feature-enabling MSRs changing CPUID), but that would require changing the API to returning a structure, since a pure or const structure can't return values by reference.
>
>It's not only the feature-enabling MSRs.  It's also OSXSAVE/OSPKE/etc in
>CR4, and on Intel CPUs, the CPUID instruction still has a side effect
>for microcode patch revision MSR.
>
>There are a few too many side effects to call it const/pure.
>
>That said, when experimenting with the same in Xen, there was nothing
>interesting the compiler could do with const/pure because of how the
>existing logic is laid out.  Removing volatile and the memory clobber
>however did allow the compiler to make slightly better code.
>
>~Andrew

Well, I guess I lump CRs, DRs and MSRs together. There is also CPUID for serialization, which is really a totally different use for the same instruction. 

tglx has suggested that we should cache or even preload the cpuid data (the latter would have the potential advantage of making the memory data structures a little easier to manage, given the very large potential space.)

The biggest issue is that there is no general mechanism for detecting which cpuid leaves have subleaves, and if they do, how many. I *believe* all existing subleaf sets are dense, but one could at least hypothetically see a vendor or VM define a CPUID leaf with a sparse subleaf set.