Re: [PATCH v3 0/4] x86/cpu/topology: Work around the nuances of virtualization on AMD/Hygon

[Borislav Petkov]

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