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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250819113447.GJaKRhVx6lBPUc6NMz@fat_crate.local>
Date: Tue, 19 Aug 2025 13:34:47 +0200
From: Borislav Petkov <bp@...en8.de>
To: K Prateek Nayak <kprateek.nayak@....com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Sean Christopherson <seanjc@...gle.com>,
	Paolo Bonzini <pbonzini@...hat.com>, x86@...nel.org,
	Naveen rao <naveen.rao@....com>, Sairaj Kodilkar <sarunkod@....com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	"Xin Li (Intel)" <xin@...or.com>,
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Mario Limonciello <mario.limonciello@....com>,
	"Gautham R. Shenoy" <gautham.shenoy@....com>,
	Babu Moger <babu.moger@....com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@....com>
Subject: Re: [PATCH v3 0/4] x86/cpu/topology: Work around the nuances of
 virtualization on AMD/Hygon

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