Re: [PATCH v6 00/90] x86: Introduce a centralized CPUID data model
"H. Peter Anvin" <[email protected]> Wed, 06 May 2026 06:59:12 -0700
| Newsgroups | dev.linux.lists.x86-cpuid,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On May 6, 2026 1:50:49 AM PDT, Borislav Petkov <[email protected]> wrote: >On Tue, May 05, 2026 at 12:11:50PM -0700, Christian Ludloff wrote: >> First, 4C78_0000 EAX should report the max 4C78 leaf, in >> case there is future expansion. (CPUID does always grow.) > >Makes sense to me. That'll tell people up to where we have those defined. > >> Second, the number of words reported in 0001h and 0002h >> should be enumerated, in case the list grows, and so that a >> program can tell between all-zero and not-present. (ECX>0 >> sub leaves, basically.) > >That's good point. So we have now: > >words 3, 7, 8, 11, 17, 21 > >which are Linux-defined. You've mapped them to E[ABCD]X regs. Sure. > >We could define subleafs and keep the main function number 4C78_0001 same. >Sure. > >And 0002 is for Linux bug flags then. > >That keeps the feature flags where they belong: word 1 is for Linux synthetic >feature bits and word 2 is for Linux bug flags. Makes sense. > >> Since 0001h has already used up all four registers, it can't >> report a max sub leaf in EAX – so maybe e.g. 0000h EBX >> has to do the job instead: it could do e.g. two byte fields, to >> report the number of words instead, i.e. 0000h BL => 0001h >> words, and 0001h BH => 0002h words. (Or wider fields... if >> you expect more future growth for words.) > >Do we care? > >Those leafs are purely for documentation and no CPUID execution would ever >return them... (famous last words :)). > >> That said, it would be good to get the initial set of commits >> done so that db updates can start to flow in, to catch up... > >Yah, that's why we're talking about them now, before stuff is cast in stone. > >I didn't even know you've documented them on sandpile.org before yesterday and >was under the assumption that no one cares about those leafs outside of the >kernel. As it should be. > >Goes to show once again how we should be very very careful what we're >exporting outside of the kernel. > >Thx. > Sadly, not true; modutila at least does use these numbers due to the brain damaged way that cpu feature modprobe strings was done.