Support for parsing the topology on AMD/Hygon processors using CPUID
leaf 0xb was added in commit 3986a0a805e6 ("x86/CPU/AMD: Derive CPU
topology from CPUID function 0xB when available"). In an effort to keep
all the topology parsing bits in one place, this commit also introduced
a pseudo dependency on the TOPOEXT feature to parse the CPUID leaf 0xb.
TOPOEXT feature (CPUID 0x80000001 ECX[22]) advertises the support for
Cache Properties leaf 0x8000001d and the CPUID leaf 0x8000001e EAX for
"Extended APIC ID" however support for 0xb was introduced alongside the
x2APIC support not only on AMD [1], but also historically on x86 [2].
Similar to 0xb, the support for extended CPU topology leaf 0x80000026
too does not depend on the TOPOEXT feature.
The support for these leaves is expected to be confirmed by ensuring
"leaf <= {extended_}cpuid_level" and then parsing the level 0 of the
respective leaf to confirm EBX[15:0] (LogProcAtThisLevel) is non-zero as
stated in the definition of "CPUID_Fn0000000B_EAX_x00 [Extended Topology
Enumeration] (Core::X86::Cpuid::ExtTopEnumEax0)" in Processor
Programming Reference (PPR) for AMD Family 19h Model 01h Rev B1 Vol1 [3]
Sec. 2.1.15.1 "CPUID Instruction Functions".
This has not been a problem on baremetal platforms since support for
TOPOEXT (Fam 0x15 and later) predates the support for CPUID leaf 0xb
(Fam 0x17[Zen2] and later), however, for AMD guests on QEMU, "x2apic"
feature can be enabled independent of the "topoext" feature where QEMU
expects topology and the initial APICID to be parsed using the CPUID
leaf 0xb (especially when number of cores > 255) which is populated
independent of the "topoext" feature flag.
Unconditionally call cpu_parse_topology_ext() on AMD and Hygon
processors to first parse the topology using the XTOPOLOGY leaves
(0x80000026 / 0xb) before using the TOPOEXT leaf (0x8000001e).
Cc: stable@vger.kernel.org # Only v6.9 and above
Link: https://lore.kernel.org/lkml/1529686927-7665-1-git-send-email-suravee.suthikulpanit@amd.com/ [1]
Link: https://lore.kernel.org/lkml/20080818181435.523309000@linux-os.sc.intel.com/ [2]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 [3]
Suggested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Fixes: 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available")
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
Changelog v3..v4:
o Quoted relevant section of the PPR justifying the changes.
o Moved this patch up ahead.
o Cc'd stable and made a note that backports should target v6.9 and
above since this depends on the x86 topology rewrite.
---
arch/x86/kernel/cpu/topology_amd.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c
index 827dd0dbb6e9..4e3134a5550c 100644
--- a/arch/x86/kernel/cpu/topology_amd.c
+++ b/arch/x86/kernel/cpu/topology_amd.c
@@ -175,18 +175,14 @@ static void topoext_fixup(struct topo_scan *tscan)
static void parse_topology_amd(struct topo_scan *tscan)
{
- bool has_topoext = false;
-
/*
- * If the extended topology leaf 0x8000_001e is available
- * try to get SMT, CORE, TILE, and DIE shifts from extended
+ * Try to get SMT, CORE, TILE, and DIE shifts from extended
* CPUID leaf 0x8000_0026 on supported processors first. If
* extended CPUID leaf 0x8000_0026 is not supported, try to
* get SMT and CORE shift from leaf 0xb first, then try to
* get the CORE shift from leaf 0x8000_0008.
*/
- if (cpu_feature_enabled(X86_FEATURE_TOPOEXT))
- has_topoext = cpu_parse_topology_ext(tscan);
+ bool has_topoext = cpu_parse_topology_ext(tscan);
if (cpu_feature_enabled(X86_FEATURE_AMD_HTR_CORES))
tscan->c->topo.cpu_type = cpuid_ebx(0x80000026);
--
2.34.1On Mon, Aug 25, 2025 at 07:57:30AM +0000, K Prateek Nayak wrote:
> This has not been a problem on baremetal platforms since support for
> TOPOEXT (Fam 0x15 and later) predates the support for CPUID leaf 0xb
> (Fam 0x17[Zen2] and later), however, for AMD guests on QEMU, "x2apic"
> feature can be enabled independent of the "topoext" feature where QEMU
> expects topology and the initial APICID to be parsed using the CPUID
> leaf 0xb (especially when number of cores > 255) which is populated
> independent of the "topoext" feature flag.
This sounds like we're fixing the kernel because someone *might* supply
a funky configuration to qemu. You need to understand that we're not wagging
the dog and fixing the kernel because of that.
If someone manages to enable some weird concoction of feature flags in qemu,
we certainly won't "fix" that in the kernel.
So let's concentrate that text around fixing the issue of parsing CPUID
topology leafs which we should parse and looking at CPUID flags only for those
feature leafs, for which those flags are existing.
If qemu wants stuff to work, then it better emulate the feature flag
configuration like the hw does.
> Unconditionally call cpu_parse_topology_ext() on AMD and Hygon
> processors to first parse the topology using the XTOPOLOGY leaves
> (0x80000026 / 0xb) before using the TOPOEXT leaf (0x8000001e).
>
> Cc: stable@vger.kernel.org # Only v6.9 and above
> Link: https://lore.kernel.org/lkml/1529686927-7665-1-git-send-email-suravee.suthikulpanit@amd.com/ [1]
> Link: https://lore.kernel.org/lkml/20080818181435.523309000@linux-os.sc.intel.com/ [2]
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 [3]
> Suggested-by: Naveen N Rao (AMD) <naveen@kernel.org>
> Fixes: 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available")
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
> ---
> Changelog v3..v4:
>
> o Quoted relevant section of the PPR justifying the changes.
>
> o Moved this patch up ahead.
>
> o Cc'd stable and made a note that backports should target v6.9 and
> above since this depends on the x86 topology rewrite.
Put that explanation in the CC:stable comment.
> ---
> arch/x86/kernel/cpu/topology_amd.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c
> index 827dd0dbb6e9..4e3134a5550c 100644
> --- a/arch/x86/kernel/cpu/topology_amd.c
> +++ b/arch/x86/kernel/cpu/topology_amd.c
> @@ -175,18 +175,14 @@ static void topoext_fixup(struct topo_scan *tscan)
>
> static void parse_topology_amd(struct topo_scan *tscan)
> {
> - bool has_topoext = false;
> -
> /*
> - * If the extended topology leaf 0x8000_001e is available
> - * try to get SMT, CORE, TILE, and DIE shifts from extended
> + * Try to get SMT, CORE, TILE, and DIE shifts from extended
> * CPUID leaf 0x8000_0026 on supported processors first. If
> * extended CPUID leaf 0x8000_0026 is not supported, try to
> * get SMT and CORE shift from leaf 0xb first, then try to
> * get the CORE shift from leaf 0x8000_0008.
> */
> - if (cpu_feature_enabled(X86_FEATURE_TOPOEXT))
> - has_topoext = cpu_parse_topology_ext(tscan);
> + bool has_topoext = cpu_parse_topology_ext(tscan);
Ok, I see what the point here is - you want to parse topology regardless of
X86_FEATURE_TOPOEXT.
Which is true - latter "indicates support for Core::X86::Cpuid::CachePropEax0
and Core::X86::Cpuid::ExtApicId" only and the leafs cpu_parse_topology_ext()
attempts to parse are different ones.
So, "has_topoext" doesn't have anything to do with X86_FEATURE_TOPOEXT - it
simply means that the topology extensions parser found some extensions and
parsed them. So let's rename that variable differently so that there is no
confusion.
You can do the renaming in parse_8000_001e() in a later patch as that is only
a cosmetic thing and we don't want to send that to stable.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hello Boris,
On 8/30/2025 10:49 PM, Borislav Petkov wrote:
> On Mon, Aug 25, 2025 at 07:57:30AM +0000, K Prateek Nayak wrote:
>> This has not been a problem on baremetal platforms since support for
>> TOPOEXT (Fam 0x15 and later) predates the support for CPUID leaf 0xb
>> (Fam 0x17[Zen2] and later), however, for AMD guests on QEMU, "x2apic"
>> feature can be enabled independent of the "topoext" feature where QEMU
>> expects topology and the initial APICID to be parsed using the CPUID
>> leaf 0xb (especially when number of cores > 255) which is populated
>> independent of the "topoext" feature flag.
>
> This sounds like we're fixing the kernel because someone *might* supply
> a funky configuration to qemu. You need to understand that we're not wagging
> the dog and fixing the kernel because of that.
>
> If someone manages to enable some weird concoction of feature flags in qemu,
> we certainly won't "fix" that in the kernel.
>
> So let's concentrate that text around fixing the issue of parsing CPUID
> topology leafs which we should parse and looking at CPUID flags only for those
> feature leafs, for which those flags are existing.
>
> If qemu wants stuff to work, then it better emulate the feature flag
> configuration like the hw does.
Ack. I'll add the relevant details in
Documentation/arch/x86/topology.rst in the next version as discussed but
I believe you discovered the intentions for this fix in the kernel
below.
>
>> Unconditionally call cpu_parse_topology_ext() on AMD and Hygon
>> processors to first parse the topology using the XTOPOLOGY leaves
>> (0x80000026 / 0xb) before using the TOPOEXT leaf (0x8000001e).
>>
>> Cc: stable@vger.kernel.org # Only v6.9 and above
>> Link: https://lore.kernel.org/lkml/1529686927-7665-1-git-send-email-suravee.suthikulpanit@amd.com/ [1]
>> Link: https://lore.kernel.org/lkml/20080818181435.523309000@linux-os.sc.intel.com/ [2]
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 [3]
>> Suggested-by: Naveen N Rao (AMD) <naveen@kernel.org>
>> Fixes: 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available")
>> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
>> ---
>> Changelog v3..v4:
>>
>> o Quoted relevant section of the PPR justifying the changes.
>>
>> o Moved this patch up ahead.
>>
>> o Cc'd stable and made a note that backports should target v6.9 and
>> above since this depends on the x86 topology rewrite.
>
> Put that explanation in the CC:stable comment.
Ack.
>
>> ---
>> arch/x86/kernel/cpu/topology_amd.c | 8 ++------
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c
>> index 827dd0dbb6e9..4e3134a5550c 100644
>> --- a/arch/x86/kernel/cpu/topology_amd.c
>> +++ b/arch/x86/kernel/cpu/topology_amd.c
>> @@ -175,18 +175,14 @@ static void topoext_fixup(struct topo_scan *tscan)
>>
>> static void parse_topology_amd(struct topo_scan *tscan)
>> {
>> - bool has_topoext = false;
>> -
>> /*
>> - * If the extended topology leaf 0x8000_001e is available
>> - * try to get SMT, CORE, TILE, and DIE shifts from extended
>> + * Try to get SMT, CORE, TILE, and DIE shifts from extended
>> * CPUID leaf 0x8000_0026 on supported processors first. If
>> * extended CPUID leaf 0x8000_0026 is not supported, try to
>> * get SMT and CORE shift from leaf 0xb first, then try to
>> * get the CORE shift from leaf 0x8000_0008.
>> */
>> - if (cpu_feature_enabled(X86_FEATURE_TOPOEXT))
>> - has_topoext = cpu_parse_topology_ext(tscan);
>> + bool has_topoext = cpu_parse_topology_ext(tscan);
>
> Ok, I see what the point here is - you want to parse topology regardless of
> X86_FEATURE_TOPOEXT.
>
> Which is true - latter "indicates support for Core::X86::Cpuid::CachePropEax0
> and Core::X86::Cpuid::ExtApicId" only and the leafs cpu_parse_topology_ext()
> attempts to parse are different ones.
>
> So, "has_topoext" doesn't have anything to do with X86_FEATURE_TOPOEXT - it
> simply means that the topology extensions parser found some extensions and
> parsed them. So let's rename that variable differently so that there is no
> confusion.
>
> You can do the renaming in parse_8000_001e() in a later patch as that is only
> a cosmetic thing and we don't want to send that to stable.
Ack! Does "has_xtopology" sound good or should we go for something more
explicit like "has_xtopology_0x26_0xb"?
Patch 3 will get rid of that "has_topoext" argument in parse_8000_001e()
entirely so I'll rename the local variable here and use the subsequent
cleanup for parse_8000_001e().
--
Thanks and Regards,
Prateek
On Mon, Sep 01, 2025 at 09:51:53AM +0530, K Prateek Nayak wrote:
> Ack! Does "has_xtopology" sound good or should we go for something more
> explicit like "has_xtopology_0x26_0xb"?
has_xtopology with a comment above it to explicitly state what it means,
sounds good.
> Patch 3 will get rid of that "has_topoext" argument in parse_8000_001e()
> entirely so I'll rename the local variable here and use the subsequent
> cleanup for parse_8000_001e().
Ok.
So pls send this one now so that I can queue it as an urgent fix and then the
cleanups can go ontop later.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
© 2016 - 2025 Red Hat, Inc.