[ANNOUNCE] x86-cpuid-db: Release v3.0

[ANNOUNCE] x86-cpuid-db: Release v3.0

[Ahmed S. Darwish]

Hi,

I'm happy to announce release 3.0 of the x86-cpuid-db project:

   https://gitlab.com/x86-cpuid.org/x86-cpuid-db
   https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/releases/v3.0

Changelog v3.0
--------------

Introduce the Linux-defined synthetic CPUID leaves 0x4c780001 and
0x4c780002.  The range ID prefix 0x4c78 is for Linux in its shorthand ASCII
form "Lx", where Linux becomes a virtual vendor akin to hardware vendors
like AMD or Intel.

In these leaves, provide a 1:1 bitfield mapping for what Linux defines in
its synthetic X86_FEATURE words at <asm/cpufeatures.h>.  Designate leaf
0x4c780001 for feature words in a linear order; i.e., subleaf 0 registers
EAX to EDX, then subleaf 1 registers, and so on.  Similarly, designate leaf
0x4c780001 for the X86_BUG words.

Here is the synthetic leaves bitfield listing:

   https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v3.0/db/xml/leaf_4c780001.xml
   https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v3.0/db/xml/leaf_4c780002.xml

With that, the Linux kernel x86 feature query code can have zero special
cases.  The synthetic CPUID leaves and X86_FEATURE words are collected,
parsed, modified, and queried just like their hardware-backed counterparts.

Update the CPUID database:

 - Leaf 0x23: Introduce subleaf 2, Auto Counter Reload (ACR)
 - Leaf 0x23: Introduce subleaf 4/5, PEBS capabilities and counters
 - Leaf 0x1c: Return LBR depth as a bitmask instead of individual bits
 - Leaf 0x0a: Define more descriptive PMU bitfield names

Thanks to Dave Hansen (Intel), also add the bits:

 - Leaf 0x0a: Various missing PMU events
 - Leaf 0x06: Missing IA32_HWP_CTL flag
 - Leaf 0x0f: Missing non-CPU (IO) Intel RDT bits

Release coverage
----------------

   CPUID leaves:        64 leaves
   CPUID bitfields:     1104 entries
   Linux feature flags: 465 entries
   Xen feature flags:   198 entries

Artifacts
---------

The generated CSV and C header files can be quickly checked in full from
the release artifacts at:

   https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/releases/v3.0

Thanks!
Ahmed

Re: [ANNOUNCE] x86-cpuid-db: Release v3.0

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

On Fri, 2026-03-27 at 04:05 +0100, Ahmed S. Darwish wrote:
> Hi,
> 
> I'm happy to announce release 3.0 of the x86-cpuid-db project:
> 
>    https://gitlab.com/x86-cpuid.org/x86-cpuid-db
>    https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/releases/v3.0

It still doesn't iterate over the hypervisor blocks at 0x4000_0x00 and
find all of them. Both Xen and KVM will advertise the Hyper-V leaves at
0x4000_0000 and then their own get shifted to 0x4000_0100. And now we
can host HyperV-enlightened Xen guests under KVM, perhaps we could do
HyperV, then Xen, then KVM at 0x4000_0200?

I was checking to see if it has all the ways to detect the Extended
Destination ID enlightenment documented in the last page ("Hypervisor
detection via CPUID") of https://david.woodhou.se/ExtDestId.pdf 

I think I see the Xen and KVM bits there, and I guess reporting them
with different strings in feature.c is kind of OK? The Bhyve and
Viridian bits are missing.

Also, the leaf at 0x40000010 isn't necessarily VMware-specific; it's
seen elsewhere too. At least EC2 exposes it under KVM. See thread at
about https://lore.kernel.org/all/aLDo3F3KKW0MzlcH@google.com/ 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [ANNOUNCE] x86-cpuid-db: Release v3.0

[Ahmed S. Darwish]

Hi!

On Fri, 27 Mar 2026, David Woodhouse wrote:
>
> It still doesn't iterate over the hypervisor blocks at 0x4000_0x00 and
> find all of them. Both Xen and KVM will advertise the Hyper-V leaves at
> 0x4000_0000 and then their own get shifted to 0x4000_0100. And now we
> can host HyperV-enlightened Xen guests under KVM, perhaps we could do
> HyperV, then Xen, then KVM at 0x4000_0200?
>
> I was checking to see if it has all the ways to detect the Extended
> Destination ID enlightenment documented in the last page ("Hypervisor
> detection via CPUID") of https://david.woodhou.se/ExtDestId.pdf
>
> I think I see the Xen and KVM bits there, and I guess reporting them
> with different strings in feature.c is kind of OK? The Bhyve and
> Viridian bits are missing.
>
> Also, the leaf at 0x40000010 isn't necessarily VMware-specific; it's
> seen elsewhere too. At least EC2 exposes it under KVM. See thread at
> about https://lore.kernel.org/all/aLDo3F3KKW0MzlcH@google.com/
>

Yes, it's in the plan.

The priority is to get the CPUID model into the kernel:

  [PATCH v6 00/90] x86: Introduce a centralized CPUID data model
  https://lore.kernel.org/lkml/20260327021645.555257-1-darwi@linutronix.de

including its newly-introduced X86_FEATURE synthetic and hardware-backed
words routing to the CPUID tables.

Then, convert the remaining call sites invoking CPUID, then begin tackling
the guest code querying leaves at the 0x4000 range.

Thanks,
Ahmed