Lemme try to make some sense of this because the wild use of names and things
is making my head spin...
On Mon, Aug 18, 2025 at 06:04:31AM +0000, K Prateek Nayak wrote:
> When running an AMD guest on QEMU with > 255 cores, the following FW_BUG
> was noticed with recent kernels:
>
> [Firmware Bug]: CPU 512: APIC ID mismatch. CPUID: 0x0000 APIC: 0x0200
>
> Naveen, Sairaj debugged the cause to commit c749ce393b8f ("x86/cpu: Use
> common topology code for AMD") where, after the rework, the initial
> APICID was set using the CPUID leaf 0x8000001e EAX[31:0] as opposed to
That's
CPUID_Fn8000001E_ECX [Node Identifiers] (Core::X86::Cpuid::NodeId)
> the value from CPUID leaf 0xb EDX[31:0] previously.
That's
CPUID_Fn0000000B_EDX [Extended Topology Enumeration]
(Core::X86::Cpuid::ExtTopEnumEdx)
> This led us down a rabbit hole of XTOPOEXT vs TOPOEXT support, preferred
What is XTOPOEXT?
CPUID_Fn0000000B_EDX?
Please define all your things properly so that we can have common base when
reading this text.
TOPOEXT is, I presume:
#define X86_FEATURE_TOPOEXT ( 6*32+22) /* "topoext" Topology extensions CPUID leafs */
Our PPR says:
CPUID_Fn80000001_ECX [Feature Identifiers] (Core::X86::Cpuid::FeatureExtIdEcx)
"22 TopologyExtensions: topology extensions support. Read-only. Reset:
Fixed,1. 1=Indicates support for Core::X86::Cpuid::CachePropEax0 and
Core::X86::Cpuid::ExtApicId."
Those leafs are:
CPUID_Fn8000001D_EAX_x00 [Cache Properties (DC)] (Core::X86::Cpuid::CachePropEax0)
DC topology info. Probably not important for this here.
and
CPUID_Fn8000001E_EAX [Extended APIC ID] (Core::X86::Cpuid::ExtApicId)
the extended APIC ID is there.
How is this APIC ID different from the extended APIC ID in
CPUID_Fn0000000B_EDX [Extended Topology Enumeration] (Core::X86::Cpuid::ExtTopEnumEdx)
?
> order of their parsing, and QEMU nuances like [1] where QEMU 0's out the
> CPUID leaf 0x8000001e on CPUs where Core ID crosses 255 fearing a
> Core ID collision in the 8 bit field which leads to the reported FW_BUG.
Is that what the hw does though?
Has this been verified instead of willy nilly clearing CPUID leafs in qemu?
> Following were major observations during the debug which the two
> patches address respectively:
>
> 1. The support for CPUID leaf 0xb is independent of the TOPOEXT feature
Yes, PPR says so.
> and is rather linked to the x2APIC enablement.
Because the SDM says:
"Bits 31-00: x2APIC ID of the current logical processor."
?
Is our version not containing the x2APIC ID?
> On baremetal, this has
> not been a problem since TOPOEXT support (Fam 0x15 and above)
> predates the support for CPUID leaf 0xb (Fam 0x17[Zen2] and above)
> however, in virtualized environment, the support for x2APIC can be
> enabled independent of topoext where QEMU expects the guest to parse
> the topology and the APICID from CPUID leaf 0xb.
So we're fixing a qemu bug?
Why isn't qemu force-enabling TOPOEXT support when one requests x2APIC?
My initial reaction: fix qemu.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
