FAILED: patch "[PATCH] x86/cpu/topology: Always try cpu_parse_topology_ext() on" failed to apply to 6.6-stable tree

FAILED: patch "[PATCH] x86/cpu/topology: Always try cpu_parse_topology_ext() on" failed to apply to 6.6-stable tree

[gregkh]

The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y
git checkout FETCH_HEAD
git cherry-pick -x cba4262a19afae21665ee242b3404bcede5a94d7
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2025091431-craftily-size-46c6@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..

Possible dependencies:



thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From cba4262a19afae21665ee242b3404bcede5a94d7 Mon Sep 17 00:00:00 2001
From: K Prateek Nayak <kprateek.nayak@amd.com>
Date: Mon, 1 Sep 2025 17:04:15 +0000
Subject: [PATCH] x86/cpu/topology: Always try cpu_parse_topology_ext() on
 AMD/Hygon

Support for parsing the topology on AMD/Hygon processors using CPUID leaf 0xb
was added in

  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.

The 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, the "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).

While at it, break down the single large comment in parse_topology_amd() to
better highlight the purpose of each CPUID leaf.

Fixes: 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available")
Suggested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org # Only v6.9 and above; depends on x86 topology rewrite
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]

diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c
index 827dd0dbb6e9..c79ebbb639cb 100644
--- a/arch/x86/kernel/cpu/topology_amd.c
+++ b/arch/x86/kernel/cpu/topology_amd.c
@@ -175,27 +175,30 @@ 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.
+	 * get SMT and CORE shift from leaf 0xb. If either leaf is
+	 * available, cpu_parse_topology_ext() will return true.
 	 */
-	if (cpu_feature_enabled(X86_FEATURE_TOPOEXT))
-		has_topoext = cpu_parse_topology_ext(tscan);
+	bool has_xtopology = cpu_parse_topology_ext(tscan);
 
 	if (cpu_feature_enabled(X86_FEATURE_AMD_HTR_CORES))
 		tscan->c->topo.cpu_type = cpuid_ebx(0x80000026);
 
-	if (!has_topoext && !parse_8000_0008(tscan))
+	/*
+	 * If XTOPOLOGY leaves (0x26/0xb) are not available, try to
+	 * get the CORE shift from leaf 0x8000_0008 first.
+	 */
+	if (!has_xtopology && !parse_8000_0008(tscan))
 		return;
 
-	/* Prefer leaf 0x8000001e if available */
-	if (parse_8000_001e(tscan, has_topoext))
+	/*
+	 * Prefer leaf 0x8000001e if available to get the SMT shift and
+	 * the initial APIC ID if XTOPOLOGY leaves are not available.
+	 */
+	if (parse_8000_001e(tscan, has_xtopology))
 		return;
 
 	/* Try the NODEID MSR */

[PATCH 6.6.y] x86/cpu/amd: Always try detect_extended_topology() on AMD processors

[K Prateek Nayak]

commit cba4262a19afae21665ee242b3404bcede5a94d7 upstream.

Support for parsing the topology on AMD/Hygon processors using CPUID leaf 0xb
was added in

  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.

The 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].

The support for the 0xb leaf is expected to be confirmed by ensuring

  leaf <= max supported cpuid_level

and then parsing the level 0 of the 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, the "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 detect_extended_topology() on AMD processors to first
parse the topology using the extended topology leaf 0xb before using the
TOPOEXT leaf (0x8000001e).

Parsing of "DIE_TYPE" in detect_extended_topology() is specific to CPUID
leaf 0x1f which is only supported on Intel platforms. Continue using the
TOPOEXT leaf (0x8000001e) to derive the "cpu_die_id" on AMD platforms.

  [ prateek: Adapted the fix from the original commit to stable kernel
    which doesn't contain the x86 topology rewrite, renamed
    cpu_parse_topology_ext() with the erstwhile
    detect_extended_topology() function in commit message, dropped
    references to extended topology leaf 0x80000026 which the stable
    kernels aren't aware of, make a note of "cpu_die_id" parsing
    nuances in detect_extended_topology() and why AMD processors should
    still rely on TOPOEXT leaf for "cpu_die_id". ]

Fixes: 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available")
Suggested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
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]
---
Hello Greg,

This will need a review from the x86 folks. Once they are okay with
the changes, I'll attach the same patch on v5.15.y, v5.10.y, and v5.4.y
stable backport threads.

I wasn't sure what the exact procedure is when the backport patch is
different from the upstream fix due to large changes. I've retained
Boris' S-o-b and added the "commit
cba4262a19afae21665ee242b3404bcede5a94d7 upstream." message nonetheless.

Let me know if any of this should be changed and I'll send out a
follow-up version.

Changes have been tested on Zen1 (contains TOPOEXT but not 0xb leaf),
Zen3 (contains both TOPOEXT and 0xb leaf) and Zen4 (contains TOPOEXT,
0xb leaf, and the extended leaf 0x80000026) based EPYC platforms.

No difference was observed in c->x86_max_cores, c->x86_coreid_bits,
c->phys_proc_id, c->apicid, c->initial_apicid, __max_die_per_package
after applying the patch on the above platforms.
---
 arch/x86/kernel/cpu/amd.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 864d62e94614..3c247ea85d8b 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -391,11 +391,20 @@ static void legacy_fixup_core_id(struct cpuinfo_x86 *c)
  */
 static void amd_get_topology(struct cpuinfo_x86 *c)
 {
+	/*
+	 * Try to get the topology information from the 0xb leaf first.
+	 * If detect_extended_topology() returns 0, parsing was successful
+	 * and APIC ID, cpu_core_id, phys_proc_id, __max_die_per_package
+	 * are already populated.
+	 */
+	bool has_extended_topology = !detect_extended_topology(c);
 	int cpu = smp_processor_id();
 
+	if (has_extended_topology)
+		c->x86_coreid_bits = get_count_order(c->x86_max_cores);
+
 	/* get information required for multi-node processors */
 	if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
-		int err;
 		u32 eax, ebx, ecx, edx;
 
 		cpuid(0x8000001e, &eax, &ebx, &ecx, &edx);
@@ -405,21 +414,17 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
 		if (c->x86 == 0x15)
 			c->cu_id = ebx & 0xff;
 
-		if (c->x86 >= 0x17) {
+		/*
+		 * It the extended topology leaf 0xb leaf doesn't exits,
+		 * derive CORE information from the 0x8000001e leaf.
+		 */
+		if (!has_extended_topology && c->x86 >= 0x17) {
 			c->cpu_core_id = ebx & 0xff;
 
 			if (smp_num_siblings > 1)
 				c->x86_max_cores /= smp_num_siblings;
 		}
 
-		/*
-		 * In case leaf B is available, use it to derive
-		 * topology information.
-		 */
-		err = detect_extended_topology(c);
-		if (!err)
-			c->x86_coreid_bits = get_count_order(c->x86_max_cores);
-
 		cacheinfo_amd_init_llc_id(c, cpu);
 
 	} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
-- 
2.34.1

Re: [PATCH 6.6.y] x86/cpu/amd: Always try detect_extended_topology() on AMD processors

[Greg KH]

On Mon, Sep 15, 2025 at 05:18:25AM +0000, K Prateek Nayak wrote:
> commit cba4262a19afae21665ee242b3404bcede5a94d7 upstream.
> 
> Support for parsing the topology on AMD/Hygon processors using CPUID leaf 0xb
> was added in
> 
>   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.
> 
> The 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].
> 
> The support for the 0xb leaf is expected to be confirmed by ensuring
> 
>   leaf <= max supported cpuid_level
> 
> and then parsing the level 0 of the 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, the "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 detect_extended_topology() on AMD processors to first
> parse the topology using the extended topology leaf 0xb before using the
> TOPOEXT leaf (0x8000001e).
> 
> Parsing of "DIE_TYPE" in detect_extended_topology() is specific to CPUID
> leaf 0x1f which is only supported on Intel platforms. Continue using the
> TOPOEXT leaf (0x8000001e) to derive the "cpu_die_id" on AMD platforms.
> 
>   [ prateek: Adapted the fix from the original commit to stable kernel
>     which doesn't contain the x86 topology rewrite, renamed
>     cpu_parse_topology_ext() with the erstwhile
>     detect_extended_topology() function in commit message, dropped
>     references to extended topology leaf 0x80000026 which the stable
>     kernels aren't aware of, make a note of "cpu_die_id" parsing
>     nuances in detect_extended_topology() and why AMD processors should
>     still rely on TOPOEXT leaf for "cpu_die_id". ]

That's a lot of changes.  Why not just use a newer kernel for this new
hardware?  Why backport this in such a different way?  That is going to
cause other changes in the future to be harder to backport in the
future.

What's driving the requirement to run new hardware on old kernels?

thanks,

greg k-h

Re: [PATCH 6.6.y] x86/cpu/amd: Always try detect_extended_topology() on AMD processors

[K Prateek Nayak]

Hello Greg,

On 9/21/2025 10:45 PM, Greg KH wrote:
> On Mon, Sep 15, 2025 at 05:18:25AM +0000, K Prateek Nayak wrote:
>> commit cba4262a19afae21665ee242b3404bcede5a94d7 upstream.

[..snip..]

>>
>>   [ prateek: Adapted the fix from the original commit to stable kernel
>>     which doesn't contain the x86 topology rewrite, renamed
>>     cpu_parse_topology_ext() with the erstwhile
>>     detect_extended_topology() function in commit message, dropped
>>     references to extended topology leaf 0x80000026 which the stable
>>     kernels aren't aware of, make a note of "cpu_die_id" parsing
>>     nuances in detect_extended_topology() and why AMD processors should
>>     still rely on TOPOEXT leaf for "cpu_die_id". ]
> 
> That's a lot of changes.  Why not just use a newer kernel for this new
> hardware?  Why backport this in such a different way?

We are mostly solving problems of virtualization with this one for
now.

QEMU can create a guest with more than 256vCPUs and tell the guest that
each CPU is an individual core leading to weird handling of the
CPUID 0x8000001e leaf when CoreId > 255
https://github.com/qemu/qemu/commit/35ac5dfbcaa4b.

QEMU expects the guest to discover the topology using 0xb leaf which,
the PPR says, is not dependent on the TOPOEXT feature.

> That is going to
> cause other changes in the future to be harder to backport in the
> future.

Thomas thinks this fix should be backported
(https://lore.kernel.org/all/87o6rirrvc.ffs@tglx/) and for any future
conflicts in this area, I'll be more than happy to help out resolve
them.

> 
> What's driving the requirement to run new hardware on old kernels?

Mostly large guests on an older platform running stable kernels is a
concern given QEMU allows a large number of vCPUs for a singe VM
currently.

If you think the maintenance burden outweighs the benefit, please
feel free to drop this fix out of older stable trees for now and we
can opt for a reactive approach if users are having trouble down
the line.

These users can be instructed to enable the topoext feature which
isn't enabled by default when using '-cpu host' cmdline on QEMU for
other historic reasons
https://bugzilla.redhat.com/show_bug.cgi?id=1613277.

-- 
Thanks and Regards,
Prateek

Re: [PATCH 6.6.y] x86/cpu/amd: Always try detect_extended_topology() on AMD processors

[Greg KH]

On Mon, Sep 22, 2025 at 12:00:08PM +0530, K Prateek Nayak wrote:
> Hello Greg,
> 
> On 9/21/2025 10:45 PM, Greg KH wrote:
> > On Mon, Sep 15, 2025 at 05:18:25AM +0000, K Prateek Nayak wrote:
> >> commit cba4262a19afae21665ee242b3404bcede5a94d7 upstream.
> 
> [..snip..]
> 
> >>
> >>   [ prateek: Adapted the fix from the original commit to stable kernel
> >>     which doesn't contain the x86 topology rewrite, renamed
> >>     cpu_parse_topology_ext() with the erstwhile
> >>     detect_extended_topology() function in commit message, dropped
> >>     references to extended topology leaf 0x80000026 which the stable
> >>     kernels aren't aware of, make a note of "cpu_die_id" parsing
> >>     nuances in detect_extended_topology() and why AMD processors should
> >>     still rely on TOPOEXT leaf for "cpu_die_id". ]
> > 
> > That's a lot of changes.  Why not just use a newer kernel for this new
> > hardware?  Why backport this in such a different way?
> 
> We are mostly solving problems of virtualization with this one for
> now.
> 
> QEMU can create a guest with more than 256vCPUs and tell the guest that
> each CPU is an individual core leading to weird handling of the
> CPUID 0x8000001e leaf when CoreId > 255
> https://github.com/qemu/qemu/commit/35ac5dfbcaa4b.
> 
> QEMU expects the guest to discover the topology using 0xb leaf which,
> the PPR says, is not dependent on the TOPOEXT feature.

Great, so these are new guests, use a new kernel!  :)

> > That is going to
> > cause other changes in the future to be harder to backport in the
> > future.
> 
> Thomas thinks this fix should be backported
> (https://lore.kernel.org/all/87o6rirrvc.ffs@tglx/) and for any future
> conflicts in this area, I'll be more than happy to help out resolve
> them.

Ok, if you get the maintainers to sign off on the change, I'll be glad
to take the patch.

thanks,

greg k-h