CPUID

In the x86 architecture, the CPUID instruction is a processor supplementary instruction allowing software to discover details of the processor. It was introduced by Intel in 1993 with the launch of the Pentium and late 486 processors.
A program can use the CPUID to determine processor type and whether features such as MMX/SSE are implemented.

History

Prior to the general availability of the CPUID instruction, programmers would write esoteric machine code which exploited minor differences in CPU behavior in order to determine the processor make and model. With the introduction of the 80386 processor, EDX on reset indicated the revision but this was only readable after reset and there was no standard way for applications to read the value.
Outside the x86 family, developers are mostly still required to use esoteric processes to determine the variations in CPU design that are present.
For example, in the Motorola 68000 series — which never had a CPUID instruction of any kind — certain specific instructions required elevated privileges. These could be used to tell various CPU family members apart. In the Motorola 68010 the instruction MOVE from SR became privileged. Because the 68000 offered an unprivileged MOVE from SR the two different CPUs could be told apart by a CPU error condition being triggered.
While the CPUID instruction is specific to the x86 architecture, other architectures often provide on-chip registers which can be read in prescribed ways to obtain the same sorts of information provided by the x86 CPUID instruction.

Calling CPUID

The CPUID opcode is 0F A2.
In assembly language, the CPUID instruction takes no parameters as CPUID implicitly uses the EAX register to determine the main category of information returned. In Intel's more recent terminology, this is called the CPUID leaf. CPUID should be called with EAX = 0 first, as this will store in the EAX register the highest EAX calling parameter that the CPU implements.
To obtain extended function information CPUID should be called with the most significant bit of EAX set. To determine the highest extended function calling parameter, call CPUID with EAX = 80000000h.
CPUID leaves greater than 3 but less than 80000000 are accessible only when the model-specific registers have IA32_MISC_ENABLE.BOOT_NT4 = 0. As the name suggests, Windows NT 4.0 until SP6 did not boot properly unless this bit was set, but later versions of Windows do not need it, so basic leaves greater than 4 can be assumed visible on current Windows systems., basic valid leaves go up to 23h, but the information returned by some leaves are not disclosed in the publicly available documentation, i.e. they are "reserved".
Some of the more recently added leaves also have sub-leaves, which are selected via the ECX register before calling CPUID.

EAX=0: Highest Function Parameter and Manufacturer ID

This returns the CPU's manufacturer ID string – a twelve-character ASCII string stored in EBX, EDX, ECX. The highest basic calling parameter is returned in EAX.
Here is a list of processors and the highest function implemented.
The following are known processor manufacturer ID strings:"AuthenticAMD" – AMD"CentaurHauls" – IDT WinChip/Centaur "CyrixInstead" – Cyrix/early STMicroelectronics and IBM"GenuineIntel" – Intel"GenuineIotel" – Intel "TransmetaCPU" – Transmeta"GenuineTMx86" – Transmeta"Geode by NSC" – National Semiconductor"NexGenDriven" – NexGen"RiseRiseRise" – Rise"SiS SiS SiS " – SiS"UMC UMC UMC " – UMC"Vortex86 SoC" – DM&P Vortex86"Shanghai" – Zhaoxin"HygonGenuine" – Hygon"GenuineRDC" – RDC Semiconductor Co. Ltd."E2K MACHINE " – MCST Elbrus"VIA VIA VIA " – VIA"AMD ISBETTER" – early engineering samples of AMD K5 processor
The following are ID strings used by open source soft CPU cores:"GenuineAO486" – ao486 CPU "MiSTer AO486" – ao486 CPU "GenuineIntel" – v586 core
The following are known ID strings from virtual machines:"ConnectixCPU" – Connectix Virtual PC "Virtual CPU " – Microsoft Virtual PC 7; Microsoft x86-to-ARM "AuthenticAMD" – Microsoft x86-to-ARM "GenuineIntel" – Apple Rosetta 2"Insignia 586" – Insignia RealPC and SoftWindows 98"Compaq FX!32" – Compaq FX!32 "PowerVM Lx86" – PowerVM Lx86 "Neko Project" – Neko Project II
For instance, on a GenuineIntel processor, values returned in EBX is 0x756e6547, EDX is 0x49656e69 and ECX is 0x6c65746e. The following example code displays the vendor ID string as well as the highest calling parameter that the CPU implements.

.intel_syntax noprefix
.text
.m0:.string "CPUID: %x\n"
.m1:.string "Largest basic function number implemented: %i\n"
.m2:.string "Vendor ID: %s\n"
.globl main
main:
push r12
mov eax, 1
sub rsp, 16
cpuid
lea rdi,.m0
mov esi, eax
call printf
xor eax, eax
cpuid
lea rdi,.m1
mov esi, eax
mov r12d, edx
mov ebp, ecx
call printf
mov 3, ebx
lea rsi, 3
lea rdi,.m2
mov 7, r12d
mov 11, ebp
call printf
add rsp, 16
pop r12
ret
.section.note.GNU-stack,"",@progbits

On some processors, it is possible to modify the Manufacturer ID string reported by CPUID. by writing a new ID string to particular MSRs using the WRMSR instruction. This has been used on non-Intel processors to enable features and optimizations that have been disabled in software for CPUs that don't return the GenuineIntel ID string. Processors that are known to possess such MSRs include:

Processor	MSRs
IDT WinChip	`108h-109h`
VIA C3, C7	`1108h-1109h`
VIA Nano	`1206h-1207h`
Transmeta Crusoe, Efficeon	`80860001h-80860003h`
AMD Geode GX, LX	`3000h-3001h`
DM&P Vortex86EX2	`52444300h-52444301h`

EAX=1: Processor Info and Feature Bits

This returns the CPU's stepping, model, and family information in register EAX, feature flags in registers EDX and ECX, and additional feature info in register EBX.

Stepping ID is a product revision number assigned due to fixed errata or other changes.
The actual processor model is derived from the Model, Extended Model ID and Family ID fields. If the Family ID field is either 6 or 15, the model is equal to the sum of the Extended Model ID field shifted left by 4 bits and the Model field. Otherwise, the model is equal to the value of the Model field.
The actual processor family is derived from the Family ID and Extended Family ID fields. If the Family ID field is equal to 15, the family is equal to the sum of the Extended Family ID and the Family ID fields. Otherwise, the family is equal to the value of the Family ID field.
The meaning of the Processor Type field is given in the table below.

Type	Encoding in Binary
Original equipment manufacturer Processor	00
Intel Overdrive Processor	01
Dual processor	10
Reserved value	11

As of October 2023, the following x86 processor family IDs are known:

Bits	EBX	Valid
7:0	Brand Index
15:8	`CLFLUSH` line size	if `CLFLUSH` feature flag is set. CPUID.01.EDX.CLFSH = 1
23:16	Maximum number of addressable IDs for logical processors in this physical package; The nearest power-of-2 integer that is not smaller than this value is the number of unique initial APIC IDs reserved for addressing different logical processors in a physical package. Former use: Number of logical processors per physical processor; two for the Pentium 4 processor with Hyper-Threading Technology.	if Hyper-threading feature flag is set. CPUID.01.EDX.HTT = 1
31:24	Local APIC ID: The initial APIC-ID is used to identify the executing logical processor.	Pentium 4 and subsequent processors.

The processor info and feature flags are manufacturer specific but usually, the Intel values are used by other manufacturers for the sake of compatibility.
Reserved fields should be masked before using them for processor identification purposes.

EAX=2: Cache and TLB Descriptor Information

This returns a list of descriptors indicating cache and TLB capabilities in EAX, EBX, ECX and EDX registers.
On processors that support this leaf, calling CPUID with EAX=2 will cause the bottom byte of EAX to be set to 01h and the remaining 15 bytes of EAX/EBX/ECX/EDX to be filled with 15 descriptors, one byte each. These descriptors provide information about the processor's caches, TLBs and prefetch. This is typically one cache or TLB per descriptor, but some descriptor-values provide other information as well - in particular, 00h is used for an empty descriptor, FFh indicates that the leaf does not contain valid cache information and that leaf 4h should be used instead, and FEh indicates that the leaf does not contain valid TLB information and that leaf 18h should be used instead. The descriptors may appear in any order.
For each of the four registers, if bit 31 is set, then the register should not be considered to contain valid descriptors
The table below provides, for known descriptor values, a condensed description of the cache or TLB indicated by that descriptor value. The suffixes used in the table are:

K,M,G : binary kilobyte, megabyte, gigabyte
E : entries
p : page-size
L : cache-line size
S : cache sector size
A : associativity

L2C/L3C:
4M, 16A, 64L

EAX=3: Processor Serial Number

This returns the processor's serial number. The processor serial number was introduced on Intel Pentium III, but due to privacy concerns, this feature is no longer implemented on later models. Transmeta's Efficeon and Crusoe processors also provide this feature. AMD CPUs however, do not implement this feature in any CPU models.
For Intel Pentium III CPUs, the lower 64 bits of the 96-bit serial number are returned in the EDX:ECX registers. For Transmeta Efficeon CPUs, it is returned in the EBX:EAX registers. And for Transmeta Crusoe CPUs, it is returned in the EBX register only.
Note that the processor serial number feature must be enabled in the BIOS setting in order to function.

EAX=4 and EAX=8000'001Dh: Cache Hierarchy and Topology

These two leaves are used to provide information about the cache hierarchy levels available to the processor core on which the CPUID instruction is run. Leaf 4 is used on Intel processors and leaf 8000'001Dh is used on AMD processors - they both return data in EAX, EBX, ECX and EDX, using the same data format except that leaf 4 returns a few additional fields that are considered "reserved" for leaf 8000'001Dh. They both provide CPU cache information in a series of sub-leaves selected by ECX - to get information about all the cache levels, it is necessary to invoke CPUID repeatedly, with EAX=4 or 8000'001Dh and ECX set to increasing values starting from 0 until a sub-leaf not describing any caches is found. The sub-leaves that do return cache information may appear in any order, but all of them will appear before the first sub-leaf not describing any caches.
In the below table, fields that are defined for leaf 4 but not for leaf 8000'001Dh are highlighted with yellow cell coloring and a item.

Bit	EAX	EBX	EDX	Bit
0	Cache Type: 0: 1: Data Cache 2: Instruction Cache 3: Unified Cache 4-31:	System coherency line size in bytes,	`WBINVD` cache invalidation execution scope.A value of 0 indicates that the `INVD`/`WBINVD` instructions will invalidate all lower-levels caches of this cache, including caches that belong to sibling processors sharing this cache. A value of 1 indicates that lower-level caches of sibling processors that are sharing this cache are not guaranteed to be all cleared.	0
1	Cache Type: 0: 1: Data Cache 2: Instruction Cache 3: Unified Cache 4-31:	System coherency line size in bytes,	Cache inclusiveness. If 1, then cache is inclusive of lower-level caches.	1
2	Cache Type: 0: 1: Data Cache 2: Instruction Cache 3: Unified Cache 4-31:	System coherency line size in bytes,		2
3	Cache Type: 0: 1: Data Cache 2: Instruction Cache 3: Unified Cache 4-31:	System coherency line size in bytes,	'	3
4	Cache Type: 0: 1: Data Cache 2: Instruction Cache 3: Unified Cache 4-31:	System coherency line size in bytes,	'	4
7:5	Cache Level	System coherency line size in bytes,	'	7:5
8	Self initializing cache level	System coherency line size in bytes,	'	8
9	Fully Associative Cache	System coherency line size in bytes,	'	9
10		System coherency line size in bytes,	'	10
11		System coherency line size in bytes,	'	11
13:12	'	Physical line partitions,	'	13:12
21:14	Maximum number of addressable IDs for logical processors sharing this cache,	Physical line partitions,	'	21:14
25:22	Maximum number of addressable IDs for logical processors sharing this cache,	Ways of cache associativity,	'	25:22
31:26		Ways of cache associativity,	'	31:26

For any caches that are valid and not fully-associative, the value returned in ECX is the number of sets in the cache minus 1.
For any given cache described by a sub-leaf of CPUID leaf 4 or 8000'001Dh, the total cache size in bytes can be computed as:
CacheSize = * * *
For example, on Intel Crystalwell CPUs, executing CPUID with EAX=4 and ECX=4 will cause the processor to return the following size information for its level-4 cache in EBX and ECX: EBX=03C0F03F and ECX=00001FFF - this should be taken to mean that this cache has a cache line size of 64 bytes, has 16 cache lines per tag, is 16-way set-associative with 8192 sets, for a total size of 64*16*16*8192=134217728 bytes, or 128 binary megabytes.

EAX=4 and EAX=Bh: Intel Thread/Core and Cache Topology

These two leaves are used for processor topology and cache hierarchy enumeration in Intel multi-core processors. AMD does not use these leaves but has alternate ways of doing the core enumeration.
Unlike most other CPUID leaves, leaf Bh will return different values in EDX depending on which logical processor the CPUID instruction runs; the value returned in EDX is actually the x2APIC id of the logical processor. The x2APIC id space is not continuously mapped to logical processors, however; there can be gaps in the mapping, meaning that some intermediate x2APIC ids don't necessarily correspond to any logical processor. Additional information for mapping the x2APIC ids to cores is provided in the other registers. Although the leaf Bh has sub-leaves, the value returned in EDX is only affected by the logical processor on which the instruction is running but not by the subleaf.
The processor topology exposed by leaf Bh is a hierarchical one, but with the strange caveat that the order of levels in this hierarchy doesn't necessarily correspond to the order in the physical hierarchy. However, every logical level can be queried as an ECX subleaf for its correspondence to a "level type", which can be either SMT, core, or "invalid". The level id space starts at 0 and is continuous, meaning that if a level id is invalid, all higher level ids will also be invalid. The level type is returned in bits 15:08 of ECX, while the number of logical processors at the level queried is returned in EBX. Finally, the connection between these levels and x2APIC ids is returned in EAX as the number of bits that the x2APIC id must be shifted in order to obtain a unique id at the next level.
As an example, a dual-core Westmere processor capable of hyperthreading could have x2APIC ids 0, 1, 4 and 5 for its four logical processors. Leaf Bh, subleaf 0 of CPUID could for instance return 100h in ECX, meaning that level 0 describes the SMT layer, and return 2 in EBX because there are two logical processors per physical core. The value returned in EAX for this 0-subleaf should be 1 in this case, because shifting the aforementioned x2APIC ids to the right by one bit gives a unique core number and erases the SMT id bit inside each core. A simpler way to interpret this information is that the last bit of the x2APIC id identifies the SMT/hyperthreading unit inside each core in our example. Advancing to subleaf 1 could for instance return 201h in ECX, meaning that this is a core-type level, and 4 in EBX because there are 4 logical processors in the package; EAX returned could be any value greater than 3, because it so happens that bit number 2 is used to identify the core in the x2APIC id. Note that bit number 1 of the x2APIC id is not used in this example. However, EAX returned at this level could well be 4 because that also gives a unique id at the package level when shifting the x2APIC id by 4 bits. Finally, you may wonder what the EAX=4 leaf can tell us that we didn't find out already. In EAX it returns the APIC mask bits reserved for a package; that would be 111b in our example because bits 0 to 2 are used for identifying logical processors inside this package, but bit 1 is also reserved although not used as part of the logical processor identification scheme. In other words, APIC ids 0 to 7 are reserved for the package, even though half of these values don't map to a logical processor.
The cache hierarchy of the processor is explored by looking at the sub-leaves of leaf 4. The APIC ids are also used in this hierarchy to convey information about how the different levels of cache are shared by the SMT units and cores. To continue our example, the L2 cache, which is shared by SMT units of the same core but not between physical cores on the Westmere is indicated by EAX being set to 1, while the information that the L3 cache is shared by the whole package is indicated by setting those bits to 111b. The cache details, including cache type, size, and associativity are communicated via the other registers on leaf 4.
Beware that older versions of the Intel app note 485 contain some misleading information, particularly with respect to identifying and counting cores in a multi-core processor; errors from misinterpreting this information have even been incorporated in the Microsoft sample code for using CPUID, even for the 2013 edition of Visual Studio, and also in the sandpile.org page for CPUID, but the Intel code sample for identifying processor topology has the correct interpretation, and the current Intel Software Developer's Manual has a more clear language. The cross-platform production code from Wildfire Games also implements the correct interpretation of the Intel documentation.
Topology detection examples involving older Intel processors that lack x2APIC are given in a 2010 Intel presentation. Beware that using that older detection method on 2010 and newer Intel processors may overestimate the number of cores and logical processors because the old detection method assumes there are no gaps in the APIC id space, and this assumption is violated by some newer processors, but these newer processors also come with an x2APIC, so their topology can be correctly determined using the EAX=Bh leaf method.

EAX=5: MONITOR/MWAIT Features

This returns feature information related to the MONITOR and MWAIT instructions in the EAX, EBX, ECX and EDX registers.

Bit	EAX	EBX	EDX	Bit
3:0	Smallest monitor-line size in bytes	Largest monitor-line size in bytes	Number of C0 sub-states supported for `MWAIT`	3:0
7:4	Smallest monitor-line size in bytes	Largest monitor-line size in bytes	Number of C1 sub-states supported for `MWAIT`	7:4
11:8	Smallest monitor-line size in bytes	Largest monitor-line size in bytes	Number of C2 sub-states supported for `MWAIT`	11:8
15:12	Smallest monitor-line size in bytes	Largest monitor-line size in bytes	Number of C3 sub-states supported for `MWAIT`	15:12
19:16	'	'	Number of C4 sub-states supported for `MWAIT`	19:16
23:20	'	'	Number of C5 sub-states supported for `MWAIT`	23:20
27:24	'	'	Number of C6 sub-states supported for `MWAIT`	27:24
31:28	'	'	Number of C7 sub-states supported for `MWAIT`	31:28

EAX=6: Thermal and Power Management

This returns feature bits in the EAX register and additional information in the EBX, ECX and EDX registers.

Bit	EBX	ECX	EDX	Bit
0	Number of Interrupt Thresholds in Digital Thermal Sensor	Effective frequency interface supported - `IA32_MPERF` and `IA32_APERF` MSRs	Hardware Feedback reporting: Performance Capability Reporting supported	0
1	Number of Interrupt Thresholds in Digital Thermal Sensor		Hardware Feedback reporting: Efficiency Capability Reporting supported	1
2	Number of Interrupt Thresholds in Digital Thermal Sensor	'	'	2
3	Number of Interrupt Thresholds in Digital Thermal Sensor	Performance-Energy Bias capability - `IA32_ENERGY_PERF_BIAS` MSR	'	3
7:4	'	'	'	7:4
11:8	'	Number of Intel Thread Director classes supported by hardware	Size of Hardware Feedback interface structure minus 1	11:8
15:12	'	Number of Intel Thread Director classes supported by hardware	'	15:12
31:16	'		Index of this logical processor's row in hardware feedback interface structure	31:16

EAX=7, ECX=0: Extended Features

This returns extended feature flags in EBX, ECX, and EDX. Returns the maximum ECX value for EAX=7 in EAX.

EAX=7, ECX=1: Extended Features

This returns extended feature flags in all four registers.

EAX=7, ECX=2: Extended Features

This returns extended feature flags in EDX.
EAX, EBX and ECX are reserved.

EAX=0Dh: XSAVE Features and State Components

This leaf is used to enumerate XSAVE features and state components.
The XSAVE instruction set extension is designed to save/restore CPU extended state in a manner that can be extended to cover new instruction set extensions without the OS context-switching code needing to understand the specifics of the new extensions. This is done by defining a series of state-components, each with a size and offset within a given save area, and each corresponding to a subset of the state needed for one CPU extension or another. The EAX=0Dh CPUID leaf is used to provide information about which state-components the CPU supports and what their sizes/offsets are, so that the OS can reserve the proper amount of space and set the associated enable-bits.
The state-components can be subdivided into two groups: user-state, and supervisor-state. The user-state items are enabled by setting their associated bits in the XCR0 control register, while the supervisor-state items are enabled by setting their associated bits in the IA32_XSS MSR - the indicated state items then become the state-components that can be saved and restored with the XSAVE/XRSTOR family of instructions.
The XSAVE mechanism can handle up to 63 state-components in this manner. State-components 0 and 1 have fixed offsets and sizes - for state-components 2 to 62, their sizes, offsets and a few additional flags can be queried by executing CPUID with EAX=0Dh and ECX set to the index of the state-component. This will return the following items in EAX, EBX and ECX :

Bit	EAX	EBX	ECX	Bit
0	Size in bytes of state-component	Offset of state-component from the start of the `XSAVE`/`XRSTOR` save area	User/supervisor state-component: 0=user-state 1=supervisor-state	0
1	Size in bytes of state-component	Offset of state-component from the start of the `XSAVE`/`XRSTOR` save area	64-byte alignment enable when state save compaction is used. If this bit is set for a state-component, then, when storing state with compaction, padding will be inserted between the preceding state-component and this state-component as needed to provide 64-byte alignment. If this bit is not set, the state-component will be stored directly after the preceding one.	1
31:2	Size in bytes of state-component	Offset of state-component from the start of the `XSAVE`/`XRSTOR` save area		31:2

Attempting to query an unsupported state-component in this manner results in EAX,EBX,ECX and EDX all being set to 0.
Sub-leaves 0 and 1 of CPUID leaf 0Dh are used to provide feature information:

EBX	ECX	EDX:EAX
Maximum size of XSAVE save area for the set of state-components currently set in `XCR0`.	Maximum size of XSAVE save area if all state-components supported by `XCR0` on this CPU were enabled at the same time.	64-bit bitmap of state-components supported by `XCR0` on this CPU.

EAX	EBX	EDX:ECX
XSAVE feature flags	Size of XSAVE area containing all the state-components currently set in `XCR0` and `IA32_XSS` combined.	64-bit bitmap of state-components supported by `IA32_XSS` on this CPU.

As of July 2023, the XSAVE state-components that have been architecturally defined are:

EAX=12h: SGX Capabilities

This leaf provides information about the supported capabilities of the Intel Software Guard Extensions feature. The leaf provides multiple sub-leaves, selected with ECX.
Sub-leaf 0 provides information about supported SGX leaf functions in EAX and maximum supported SGX enclave sizes in EDX; ECX is reserved. EBX provides a bitmap of bits that can be set in the MISCSELECT field in the SECS - this field is used to control information written to the MISC region of the SSA when an AEX occurs.
Sub-leaf 1 provides a bitmap of which bits can be set in the 128-bit ATTRIBUTES field of SECS in EDX:ECX:EBX:EAX. The top 64 bits are a bitmap of which bits can be set in the XFRM - this mask is a bitmask of which CPU state-components will be saved to the SSA in case of an AEX; this has the same layout as the XCR0 control register. The other bits are given in EAX and EBX, as follows:
Sub-leaves 2 and up are used to provide information about which physical memory regions are available for use as EPC sections under SGX.

Bits	EAX	EBX	ECX	EDX	Bits
3:0	Sub-leaf type: 0000: Invalid 0001: EPC section other: reserved	Bits 51:32 of physical base address of EPC section	EPC Section properties: 0000: Invalid 0001: Has confidentiality, integrity, and replay protection 0010: Has confidentiality protection only 0011: Has confidentiality and integrity protection other: reserved	Bits 51:32 of size of EPC section	3:0
11:4	'	Bits 51:32 of physical base address of EPC section	'	Bits 51:32 of size of EPC section	11:4
19:12	Bits 31:12 of physical base address of EPC section	Bits 51:32 of physical base address of EPC section	Bits 31:12 of size of EPC section	Bits 51:32 of size of EPC section	19:12
31:20	Bits 31:12 of physical base address of EPC section	'	Bits 31:12 of size of EPC section	'	31:20

EAX=14h: Processor Trace

This leaf provides feature information for Intel Processor Trace.
For sub-leaf 0, the value returned in EAX is the index of the highest sub-leaf supported for CPUID with EAX=14h. EBX and ECX provide feature flags, EDX is reserved.

EAX=15h and EAX=16h: CPU, TSC, Bus and Core Crystal Clock Frequencies

These two leaves provide information about various frequencies in the CPU in EAX, EBX and ECX.

EAX	EBX	ECX
Ratio of TSC frequency to Core Crystal Clock frequency, denominator	Ratio of TSC frequency to Core Crystal Clock frequency, numerator	Core Crystal Clock frequency, in units of Hz

If the returned values in EBX and ECX of leaf 15h are both nonzero, then the TSC frequency in Hz is given by TSCFreq = ECX*.
On some processors, CPUID_15h_ECX is zero but CPUID_16h_EAX is present and not zero. On all known processors where this is the case, the TSC frequency is equal to the Processor Base Frequency, and the Core Crystal Clock Frequency in Hz can be computed as CoreCrystalFreq = * .
On processors that enumerate the TSC/Core Crystal Clock ratio in CPUID leaf 15h, the APIC timer frequency will be the Core Crystal Clock frequency divided by the divisor specified by the APIC's Divide Configuration Register.

EAX=17h: SoC Vendor Attribute Enumeration

This leaf is present in systems where an x86 CPU IP core is implemented in an SoC from another vendor - whereas the other leaves of CPUID provide information about the x86 CPU core, this leaf provides information about the SoC. This leaf takes a sub-leaf index in ECX.
Sub-leaf 0 returns a maximum sub-leaf index in EAX, and SoC identification information in EBX/ECX/EDX:

Bit	EBX	ECX	EDX	Bit
15:0	SoC Vendor ID	SoC Project ID	SoC Stepping ID within an SoC project	15:0
16	SoC Vendor ID scheme 0 : Vendor IDs assigned by Intel 1 : Industry standard enumeration scheme	SoC Project ID	SoC Stepping ID within an SoC project	16
31:17		SoC Project ID	SoC Stepping ID within an SoC project	31:17

Sub-leaves 1 to 3 return a 48-byte SoC vendor brand string in UTF-8 format. Sub-leaf 1 returns the first 16 bytes in EAX,EBX,ECX,EDX ; sub-leaf 2 returns the next 16 bytes and sub-leaf 3 returns the last 16 bytes. The string is allowed but not required to be null-terminated.

EAX=19h: Intel Key Locker Features

This leaf provides feature information for Intel Key Locker in EAX, EBX and ECX. EDX is reserved.

EAX=1Dh: Intel AMX Tile Information

When ECX=0, the highest supported "palette" subleaf is enumerated in EAX. When ECX≥1, information on palette n is returned.

EAX=1Eh: Intel AMX Tile Multiplier (`TMUL`) Information

This leaf returns information on the AMX TMUL unit. The leaf provides multiple sub-leaves, selected with ECX.
Subleaf 0 returns maximum supported sub-leaf in EAX and basic TMUL information in EBX; subleaf 1 returns additional feature information in EAX.

EAX=21h: Reserved for TDX enumeration

When Intel TDX is active, attempts to execute the CPUID instruction by a TD guest will be intercepted by the TDX module.
This module will, when CPUID is invoked with EAX=21h and ECX=0, return the index of the highest supported sub-leaf for leaf 21h in EAX and a TDX module vendor ID string as a 12-byte ASCII string in EBX,EDX,ECX. Intel's own module implementation returns the vendor ID string "IntelTDX" - for this module, additional feature information is not available through CPUID and must instead be obtained through the TDX-specific TDCALL instruction.
This leaf is reserved in hardware and will return 0 in EAX/EBX/ECX/EDX when run directly on the CPU.

EAX=24h, ECX=0: AVX10 Converged Vector ISA

This returns a maximum supported sub-leaf in EAX and AVX10 feature information in EBX.

EAX=24h, ECX=1: Discrete AVX10 Features

Subleaf 1 is reserved for AVX10 features not bound to a version.

EAX=2000'0000h: Highest Xeon Phi Function Implemented

The highest function is returned in EAX.
This leaf is only present on Xeon Phi processors.

EAX=2000'0001h: Xeon Phi Feature Bits

This function returns feature flags.

EAX=4000'0000h-4FFFF'FFFh: Reserved for [Hypervisor]s

When the CPUID instruction is executed under Intel VT-x or AMD-v virtualization, it will be intercepted by the hypervisor, enabling the hypervisor to return CPUID feature flags that differ from those of the underlying hardware. CPUID leaves 40000000h to 4FFFFFFFh are not implemented in hardware, and are reserved for use by hypervisors to provide hypervisor-specific identification and feature information through this interception mechanism.
For leaf 40000000h, the hypervisor is expected to return the index of the highest supported hypervisor CPUID leaf in EAX, and a 12-character hypervisor ID string in EBX,ECX,EDX. For leaf 40000001h, the hypervisor may return an interface identification signature in EAX - e.g. hypervisors that wish to advertise that they are Hyper-V compatible may return 0x31237648—"Hv#1" in EAX. The formats of leaves 40000001h and up to the highest supported leaf are otherwise hypervisor-specific. Hypervisors that implement these leaves will normally also set bit 31 of ECX for CPUID leaf 1 to indicate their presence.
Hypervisors that expose more than one hypervisor interface may provide additional sets of CPUID leaves for the additional interfaces, at a spacing of 100h leaves per interface. For example, when QEMU is configured to provide both Hyper-V and KVM interfaces, it will provide Hyper-V information starting from CPUID leaf 40000000h and KVM information starting from leaf 40000100h.
Some hypervisors that are known to return a hypervisor ID string in leaf 40000000h include:

Hypervisor	ID String	Notes
	`"Microsoft Hv"`
Linux KVM	`"KVMKVMKVM\0\0\0"`	\0 denotes an ASCII NUL character.
Linux KVM	`"Linux KVM Hv"`	Hyper-V emulation
bhyve	`"BHyVE BHyVE "`, `"bhyve bhyve "`	ID string changed from mixed-case to lower-case in 2013. Lower-case string also used in bhyve-derived hypervisors such as xhyve and HyperKit.
Xen	`"XenVMMXenVMM"`	Only when using HVM mode.
QEMU	`"TCGTCGTCGTCG"`	Only when the TCG is enabled.
Parallels	`"prl hyperv"`, `" lrpepyhvr"`	The string is an endianness-swapped version of the string, observed in some versions of Parallels Workstation.
VMware	`"VMwareVMware"`
Project ACRN	`"ACRNACRNACRN"`
VirtualBox	`"VBoxVBoxVBox"`	Only when configured to use the "hyperv" paravirtualization provider.
QNX Hypervisor	`"QXNQSBMV"`	The QNX hypervisor detection method provided in the official QNX documentation checks only the first 8 characters of the string, as provided in EBX and ECX - EDX is ignored and may take any value.
NetBSD NVMM	`"___ NVMM ___"`	-
OpenBSD VMM	`"OpenBSDVMM58"`
Siemens Jailhouse	`"Jailhouse\0\0\0"`	\0 denotes an ASCII NUL character.
Bitdefender Napoca	`"Napocahv"`
FEX-Emu	`"FEXIFEXIEMU\0"`	\0 denotes an ASCII NUL character.
Intel HAXM	`"HAXMHAXMHAXM"`	Project discontinued.
Intel KGT	`"EVMMEVMMEVMM"`	On "trusty" branch of KGT only, which is used for the
Unisys s-Par	`"UnisysSpar64"`
	`"SRESRESRESRE"`	-

EAX=8000'0000h: Highest Extended Function Implemented

The highest calling parameter is returned in EAX.
EBX/ECX/EDX return the manufacturer ID string on AMD but not Intel CPUs.

EAX=8000'0001h: Extended Processor Info and Feature Bits

This returns extended feature flags in EDX and ECX.
Many of the bits in EDX are duplicates of EDX from the EAX=1 leaf - these bits are highlighted in light yellow.
AMD feature flags are as follows:

EAX=8000'0002h,8000'0003h,8000'0004h: Processor Brand String

These return the processor brand string in EAX, EBX, ECX and EDX. CPUID must be issued with each parameter in sequence to get the entire 48-byte ASCII processor brand string. It is necessary to check whether the feature is present in the CPU by issuing CPUID with EAX = 80000000h first and checking if the returned value is not less than 80000004h.
The string is specified in Intel/AMD documentation to be null-terminated, however this is not always the case, and software should not rely on it.

include
include
include

int main

On AMD processors, from 180nm Athlon onwards, it is possible to modify the processor brand string returned by CPUID leaves 80000002h-80000004h by using the WRMSR instruction to write a 48-byte replacement string to MSRs C0010030h-C0010035h. This can also be done on AMD Geode GX/LX, albeit using MSRs 300Ah-300Fh.
The string returned by CPUID leaves 80000002h-80000004h frequently contains multiple leading, trailing or middle spaces — a few examples of Processor Brand Strings with many consecutive spaces that have appeared in Intel/AMD CPUs include:
In some cases, determining the CPU vendor requires examining not just the Vendor ID in CPUID leaf 0 and the CPU signature in leaf 1, but also the Processor Brand String in leaves 80000002h-80000004h. Known cases include:

Montage Jintide CPUs can be distinguished from the Intel Xeon CPU models they're based on by the presence of the substring Montage in the brand string of the Montage CPUs CentaurHauls Family 6 CPUs may be either VIA or Zhaoxin CPUs - these can be distinguished by the presence of the substring ZHAOXIN in the brand string of the Zhaoxin CPUs
Apple's Rosetta 2 x86 emulator — which identifies itself as GenuineIntel Family 6 — can be distinguished from the Intel Xeon processor it is emulating by the presence of the substring VirtualApple in the brand string of Rosetta 2.
Microsoft's x86-on-ARM emulator — which, in 64-bit mode, identifies itself as AuthenticAMD Family 0Fh — can be distinguished from the AMD processor it is emulating by the presence of the substring in the emulator's brand string.

EAX=8000'0005h: L1 Cache and TLB Identifiers

This provides information about the processor's level-1 cache and TLB characteristics in EAX, EBX, ECX and EDX as follows:

EAX: information about L1 hugepage TLBs
EBX: information about L1 small-page TLBs
ECX: information about L1 data cache
EDX: information about L1 instruction cache

EAX=8000'0006h: Extended L2 Cache Features

Returns details of the L2 cache in ECX, including the line size in bytes, type of associativity and the cache size in KB.

include
include

int main

EAX=8000'0007h: Processor Power Management Information and RAS Capabilities

This function provides information about power management, power reporting and RAS capabilities of the CPU.

EAX=8000'0008h: Virtual and Physical Address Sizes

Bits	EAX	ECX	EDX	Bits
7:0	Number of Physical Address Bits	Number of Physical Threads in processor	Maximum page count for `INVLPGB` instruction	7:0
11:8	Number of Linear Address Bits	'	Maximum page count for `INVLPGB` instruction	11:8
15:12	Number of Linear Address Bits	APIC ID Size	Maximum page count for `INVLPGB` instruction	15:12
17:16	Guest Physical Address Size	Performance Timestamp Counter size	Maximum ECX value recognized by `RDPRU` instruction	17:16
23:18	Guest Physical Address Size	'	Maximum ECX value recognized by `RDPRU` instruction	23:18
31:24	'	'	Maximum ECX value recognized by `RDPRU` instruction	31:24

EAX=8000'000Ah: SVM features

This leaf returns information about AMD SVM features in EAX, EBX and EDX.

Bits	EAX	EBX	ECX	Bits
5:0	SVM Revision Number	Number of available ASIDs	'	5:0
6	SVM Revision Number	Number of available ASIDs	x2AVIC_EXT	6
7	SVM Revision Number	Number of available ASIDs	'	7
8	'	Number of available ASIDs	'	8
31:9	'	Number of available ASIDs	'	31:9

EAX=8000'001Fh: Encrypted Memory Capabilities

Bits	EBX	ECX	EDX	Bits
5:0	C-bit location in page table entry	Maximum ASID value that can be used for a SEV-enabled guest	Minimum ASID value for a guest that is SEV-enabled but not SEV-ES-enabled	5:0
11:6	Physical address width reduction when memory encryption is enabled	Maximum ASID value that can be used for a SEV-enabled guest	Minimum ASID value for a guest that is SEV-enabled but not SEV-ES-enabled	11:6
15:12	Number of VMPLs supported	Maximum ASID value that can be used for a SEV-enabled guest	Minimum ASID value for a guest that is SEV-enabled but not SEV-ES-enabled	15:12
31:16		Maximum ASID value that can be used for a SEV-enabled guest	Minimum ASID value for a guest that is SEV-enabled but not SEV-ES-enabled	31:16

EAX=8FFF'FFFEh and EAX=8FFF'FFFFh: AMD Easter Eggs

Several AMD CPU models will, for CPUID with EAX=8FFF'FFFFh, return an Easter egg string in EAX, EBX, ECX and EDX. Known Easter Egg strings include:

Processor	String
AMD K6	`NexGen‍erationAMD`
AMD K8	`IT'S HAMMER TIME`
AMD Jaguar	`HELLO KITTY! ^-^`

Additionally, AMD K6 CPUs will, for CPUID with EAX=8FFF'FFFEh, return an Easter egg reference to "DEI" in EAX.

EAX=C000'0000h: Highest Centaur">Centaur Technology">Centaur Extended Function

Returns index of highest Centaur leaf in EAX. If the returned value in EAX is less than C0000001h, then Centaur extended leaves are not supported.
Present in CPUs from VIA and Zhaoxin.
On IDT WinChip CPUs, the extended leaves C0000001h-C0000005h do not encode any Centaur-specific functionality but are instead aliases of leaves 80000001h-80000005h.

EAX=C000'0001h: Centaur Feature Information

This leaf returns Centaur feature information in EDX.

EAX=C000'0006h, ECX=0: Zhaoxin Feature Information

This sub-leaf returns feature information in EAX. EBX, ECX and EDX are reserved.

CPUID usage from high-level languages

Inline assembly

This information is easy to access from other languages as well. For instance, the C code for gcc below prints the first five values, returned by the cpuid:

include
include

int main

In MSVC and Borland/Embarcadero C compilers flavored inline assembly, the clobbering information is implicit in the instructions:

include

int main

If either version was written in plain assembly language, the programmer must manually save the results of EAX, EBX, ECX, and EDX elsewhere if they want to keep using the values.

Wrapper functions

GCC also provides a header called <cpuid.h> on systems that have CPUID. The __cpuid is a macro expanding to inline assembly. Typical usage would be:

include
include

int main

But if one requested an extended feature not present on this CPU, they would not notice and might get random, unexpected results. Safer version is also provided in <cpuid.h>. It checks for extended features and does some more safety checks. The output values are not passed using reference-like macro parameters, but more conventional pointers.

include
include

int main

Notice the ampersands in &a, &b, &c, &d and the conditional statement. If the __get_cpuid call receives a correct request, it will return a non-zero value, if it fails, zero.
Microsoft Visual C compiler has builtin function __cpuid so the cpuid instruction may be embedded without using inline assembly, which is handy since the x86-64 version of MSVC does not allow inline assembly at all. The same program for MSVC would be:

include
ifdef _MSC_VER

#include

endif

int main

Many interpreted or compiled scripting languages are capable of using CPUID via an FFI library. shows usage of the Ruby FFI module to execute assembly language that includes the CPUID opcode.
.NET 5 and later versions provide the System.Runtime.Intrinsics.X86.X86base.CpuId method. For instance, the C# code below prints the processor brand if it supports CPUID instruction:
using System.Runtime.InteropServices;
using System.Runtime.Intrinsics.X86;
using System.Text;
namespace X86CPUID

CPU-specific information outside x86

Some of the non-x86 CPU architectures also provide certain forms of structured information about the processor's abilities, commonly as a set of special registers:

ARM architectures have a CPUID coprocessor register which requires exception level EL1 or above to access.
System/370 through z/Architecture IBM mainframe processors have a supervisor-mode-only Store CPU ID instruction, which provides information that includes the CPU type.
The z/Architecture mainframe processors also have a supervisor-mode-only Store Facilities List instruction, and a non-privileged Store Facilities List Extended instruction, which list the installed hardware features.
The MIPS32/64 architecture defines a mandatory Processor Identification and a series of daisy-chained Configuration Registers.
The PowerPC processor has the 32-bit read-only Processor Version Register identifying the processor model in use. The instruction requires supervisor access level.
The RISC-V architecture has an mcpuid "read-only register containing information regarding the capabilities of the CPU implementation"

DSP and transputer-like chip families have not taken up the instruction in any noticeable way, in spite of having as many variations in design. Alternate ways of silicon identification might be present; for example, DSPs from Texas Instruments contain a memory-based register set for each functional unit that starts with identifiers determining the unit type and model, its ASIC design revision and features selected at the design phase, and continues with unit-specific control and data registers. Access to these areas is performed by simply using the existing load and store instructions; thus, for such devices, there is no need for extending the register set for device identification purposes.