[v2] x86/cacheinfo: Fixes for CPUID(0x80000005) and CPUID(0x80000006)

[PATCH v2 1/2] x86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity

Posted by Ahmed S. Darwish 10 months ago

For the AMD CPUID(4) emulation cache info logic, the same associativity
mapping array, assocs[], is used for both CPUID(0x80000005) and
CPUID(0x80000006).

This is incorrect since per the AMD manuals, the mappings for
CPUID(0x80000005) L1d/L1i associativity is:

   n = 0x1 -> 0xfe	n
   n = 0xff		fully associative

while assocs[] maps these values to:

   n = 0x1, 0x2, 0x4	n
   n = 0x3, 0x7, 0x9	0
   n = 0x6		8
   n = 0x8		16
   n = 0xa		32
   n = 0xb		48
   n = 0xc		64
   n = 0xd		96
   n = 0xe		128
   n = 0xf		fully associative

which is only valid for CPUID(0x80000006).

Parse CPUID(0x80000005) L1d/L1i associativity values as shown in the AMD
manuals.  Since the 0xffff literal is used to denote full associativity
at the AMD CPUID(4)-emulation logic, define AMD_CPUID4_FULLY_ASSOCIATIVE
for it instead of spreading that literal in more places.

Mark the assocs[] mapping array as only valid for CPUID(0x80000006) L2/L3
cache information.

Fixes: a326e948c538 ("x86, cacheinfo: Fixup L3 cache information for AMD multi-node processors")
Cc: stable@vger.kernel.org
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
---
 arch/x86/kernel/cpu/cacheinfo.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index cd48d34ac04b..f4817cd50cfb 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -91,6 +91,8 @@ static const enum cache_type cache_type_map[] = {
  * AMD CPUs with TOPOEXT can just use CPUID(0x8000001d)
  */
 
+#define AMD_CPUID4_FULLY_ASSOCIATIVE	0xffff
+
 union l1_cache {
 	struct {
 		unsigned line_size	:8;
@@ -122,6 +124,7 @@ union l3_cache {
 	unsigned int val;
 };
 
+/* L2/L3 associativity mapping */
 static const unsigned short assocs[] = {
 	[1]		= 1,
 	[2]		= 2,
@@ -133,7 +136,7 @@ static const unsigned short assocs[] = {
 	[0xc]		= 64,
 	[0xd]		= 96,
 	[0xe]		= 128,
-	[0xf]		= 0xffff	/* Fully associative */
+	[0xf]		= AMD_CPUID4_FULLY_ASSOCIATIVE
 };
 
 static const unsigned char levels[] = { 1, 1, 2, 3 };
@@ -163,7 +166,7 @@ static void legacy_amd_cpuid4(int index, union _cpuid4_leaf_eax *eax,
 		if (!l1->val)
 			return;
 
-		assoc		= assocs[l1->assoc];
+		assoc		= (l1->assoc == 0xff) ? AMD_CPUID4_FULLY_ASSOCIATIVE : l1->assoc;
 		line_size	= l1->line_size;
 		lines_per_tag	= l1->lines_per_tag;
 		size_in_kb	= l1->size_in_kb;
@@ -201,7 +204,7 @@ static void legacy_amd_cpuid4(int index, union _cpuid4_leaf_eax *eax,
 	eax->split.num_threads_sharing		= 0;
 	eax->split.num_cores_on_die		= topology_num_cores_per_package();
 
-	if (assoc == 0xffff)
+	if (assoc == AMD_CPUID4_FULLY_ASSOCIATIVE)
 		eax->split.is_fully_associative = 1;
 
 	ebx->split.coherency_line_size		= line_size - 1;
-- 
2.49.0

Re: [PATCH v2 1/2] x86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity

Posted by Ingo Molnar 10 months ago

* Ahmed S. Darwish <darwi@linutronix.de> wrote:

> For the AMD CPUID(4) emulation cache info logic, the same associativity
> mapping array, assocs[], is used for both CPUID(0x80000005) and
> CPUID(0x80000006).
> 
> This is incorrect since per the AMD manuals, the mappings for
> CPUID(0x80000005) L1d/L1i associativity is:
> 
>    n = 0x1 -> 0xfe	n
>    n = 0xff		fully associative
> 
> while assocs[] maps these values to:
> 
>    n = 0x1, 0x2, 0x4	n
>    n = 0x3, 0x7, 0x9	0
>    n = 0x6		8
>    n = 0x8		16
>    n = 0xa		32
>    n = 0xb		48
>    n = 0xc		64
>    n = 0xd		96
>    n = 0xe		128
>    n = 0xf		fully associative
> 
> which is only valid for CPUID(0x80000006).
> 
> Parse CPUID(0x80000005) L1d/L1i associativity values as shown in the AMD
> manuals.  Since the 0xffff literal is used to denote full associativity
> at the AMD CPUID(4)-emulation logic, define AMD_CPUID4_FULLY_ASSOCIATIVE
> for it instead of spreading that literal in more places.
> 
> Mark the assocs[] mapping array as only valid for CPUID(0x80000006) L2/L3
> cache information.
> 
> Fixes: a326e948c538 ("x86, cacheinfo: Fixup L3 cache information for AMD multi-node processors")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>

Yeah, so a Cc: stable tag is usually reserved for recent regressions, 
or critical fixes - but this is a bug from 2009, ~16 years old. This 
bug is old enough to receive a driving license in the US, and can 
legally buy beer or wine in Germany.

So I've removed the tags from the two commits in tip:x86/cpu, but note 
that the Fixes tag itself will give backporters enough information so 
they can decide on whether to backport. Greg's -stable process 
typically processes all Fixes tags for example, once Linus pulls this 
into v6.16-to-be.

Thanks,

	Ingo

Re: [PATCH v2 1/2] x86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity

Posted by Ahmed S. Darwish 10 months ago

On Wed, 09 Apr 2025, Ingo Molnar wrote:
>
> Yeah, so a Cc: stable tag is usually reserved for recent regressions,
> or critical fixes - but this is a bug from 2009, ~16 years old. This
> bug is old enough to receive a driving license in the US, and can
> legally buy beer or wine in Germany.
>

Haha, noted :)

> So I've removed the tags from the two commits in tip:x86/cpu, but note
> that the Fixes tag itself will give backporters enough information so
> they can decide on whether to backport. Greg's -stable process
> typically processes all Fixes tags for example, once Linus pulls this
> into v6.16-to-be.

Yup, makes sense.

Thanks a lot for all the support!
Ahmed

[tip: x86/cpu] x86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity

Posted by tip-bot2 for Ahmed S. Darwish 10 months ago

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     d274cde0dbe0217ee2f2ddbb1a3c545dedf81a06
Gitweb:        https://git.kernel.org/tip/d274cde0dbe0217ee2f2ddbb1a3c545dedf81a06
Author:        Ahmed S. Darwish <darwi@linutronix.de>
AuthorDate:    Wed, 09 Apr 2025 14:22:30 +02:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Wed, 09 Apr 2025 20:47:05 +02:00

x86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity

For the AMD CPUID(4) emulation cache info logic, the same associativity
mapping array, assocs[], is used for both CPUID(0x80000005) and
CPUID(0x80000006).

This is incorrect since per the AMD manuals, the mappings for
CPUID(0x80000005) L1d/L1i associativity is:

   n = 0x1 -> 0xfe	n
   n = 0xff		fully associative

while assocs[] maps these values to:

   n = 0x1, 0x2, 0x4	n
   n = 0x3, 0x7, 0x9	0
   n = 0x6		8
   n = 0x8		16
   n = 0xa		32
   n = 0xb		48
   n = 0xc		64
   n = 0xd		96
   n = 0xe		128
   n = 0xf		fully associative

which is only valid for CPUID(0x80000006).

Parse CPUID(0x80000005) L1d/L1i associativity values as shown in the AMD
manuals.  Since the 0xffff literal is used to denote full associativity
at the AMD CPUID(4)-emulation logic, define AMD_CPUID4_FULLY_ASSOCIATIVE
for it instead of spreading that literal in more places.

Mark the assocs[] mapping array as only valid for CPUID(0x80000006) L2/L3
cache information.

Fixes: a326e948c538 ("x86, cacheinfo: Fixup L3 cache information for AMD multi-node processors")
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250409122233.1058601-2-darwi@linutronix.de
---
 arch/x86/kernel/cpu/cacheinfo.c |  9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index cd48d34..f4817cd 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -91,6 +91,8 @@ static const enum cache_type cache_type_map[] = {
  * AMD CPUs with TOPOEXT can just use CPUID(0x8000001d)
  */
 
+#define AMD_CPUID4_FULLY_ASSOCIATIVE	0xffff
+
 union l1_cache {
 	struct {
 		unsigned line_size	:8;
@@ -122,6 +124,7 @@ union l3_cache {
 	unsigned int val;
 };
 
+/* L2/L3 associativity mapping */
 static const unsigned short assocs[] = {
 	[1]		= 1,
 	[2]		= 2,
@@ -133,7 +136,7 @@ static const unsigned short assocs[] = {
 	[0xc]		= 64,
 	[0xd]		= 96,
 	[0xe]		= 128,
-	[0xf]		= 0xffff	/* Fully associative */
+	[0xf]		= AMD_CPUID4_FULLY_ASSOCIATIVE
 };
 
 static const unsigned char levels[] = { 1, 1, 2, 3 };
@@ -163,7 +166,7 @@ static void legacy_amd_cpuid4(int index, union _cpuid4_leaf_eax *eax,
 		if (!l1->val)
 			return;
 
-		assoc		= assocs[l1->assoc];
+		assoc		= (l1->assoc == 0xff) ? AMD_CPUID4_FULLY_ASSOCIATIVE : l1->assoc;
 		line_size	= l1->line_size;
 		lines_per_tag	= l1->lines_per_tag;
 		size_in_kb	= l1->size_in_kb;
@@ -201,7 +204,7 @@ static void legacy_amd_cpuid4(int index, union _cpuid4_leaf_eax *eax,
 	eax->split.num_threads_sharing		= 0;
 	eax->split.num_cores_on_die		= topology_num_cores_per_package();
 
-	if (assoc == 0xffff)
+	if (assoc == AMD_CPUID4_FULLY_ASSOCIATIVE)
 		eax->split.is_fully_associative = 1;
 
 	ebx->split.coherency_line_size		= line_size - 1;