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

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

[Ahmed S. Darwish]

Hi,

Changelog v2:
-------------

Rebase over tip:master, as of now:

   5c5e95d43de9 ("Merge branch into tip/master: 'x86/nmi'")

per Ingo's request.

Changelog v1:
-------------

https://lore.kernel.org/lkml/20250409105429.1048199-1-darwi@linutronix.de

While working on the x86-cpuid-db CPUID model on top of the CPUID(2) and
CPUID(4) cleanups at tip/x86/cpu,[*] I've discovered some L1/2/3 cache
associativity parsing issues for the AMD CPUID(4) emulation logic .

Here are the fixes on top of -rc1.

* Summary:

The AMD CPUID(4) emulation logic, uses CPUID(0x80000005) and
CPUID(0x80000006) for extracting the L1/L2/L3 cache info.  It then uses
an assocs[] associativity mapping array to map the extracted
associativity values to their CPUID(4) equivalents.

Using the same associativity mapping array for both leaves is invalid.

Per the AMD manuals, the associativity field semantics between
CPUID(0x80000005) and CPUID(0x80000006) is different.  The first patch
fixes that for the former leaf.  For the latter leaf, the second patch
completes the associativity mapping array and handles the special case of
an L2/L3 associativity of 9, which is just a marker — not a real cache
associativity value.

* Example testing for L1d cacheinfo:

On a Qemu-emulated AMD machine without CPUID(0x8000001d) topology
extensions, and with below cpuid(1) view:

   L1 data cache information (0x80000005/ecx):
      line size (bytes) = 0x40 (64)
      lines per tag     = 0x1 (1)
      associativity     = 0x8 (8)
      size (KB)         = 0x20 (32)
   L1 instruction cache information (0x80000005/edx):
      line size (bytes) = 0x40 (64)
      lines per tag     = 0x1 (1)
      associativity     = 0x4 (4)
      size (KB)         = 0x40 (64)
   L2 unified cache information (0x80000006/ecx):
      line size (bytes) = 0x40 (64)
      lines per tag     = 0x1 (1)
      associativity     = 8-way (6)
      size (KB)         = 0x200 (512)
   L3 cache information (0x80000006/edx):
      line size (bytes)     = 0x40 (64)
      lines per tag         = 0x1 (1)
      associativity         = 16-way (8)
      size (in 512KB units) = 0x10 (16)

Before applying this PQ, we get:

   /sys/devices/system/cpu/cpu[0-8]/cache/index0/ways_of_associativity: 16
   /sys/devices/system/cpu/cpu[0-8]/cache/index0/number_of_sets: 32

and after:

   /sys/devices/system/cpu/cpu[0-8]/cache/index0/ways_of_associativity: 8
   /sys/devices/system/cpu/cpu[0-8]/cache/index0/number_of_sets: 64

Thanks,

[*] https://lore.kernel.org/lkml/20250304085152.51092-1-darwi@linutronix.de
    https://lore.kernel.org/lkml/20250324133324.23458-1-darwi@linutronix.de

8<--

Ahmed S. Darwish (2):
  x86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity
  x86/cacheinfo: Properly parse CPUID(0x80000006) L2/L3 associativity

 arch/x86/kernel/cpu/cacheinfo.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

base-commit: 5c5e95d43de95309622fbf85bf55765ca2cae551
--
2.49.0

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

[Ahmed S. Darwish]

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

[PATCH v2 2/2] x86/cacheinfo: Properly parse CPUID(0x80000006) L2/L3 associativity

[Ahmed S. Darwish]

Complete the AMD CPUID(4) emulation logic, which uses CPUID(0x80000006)
for L2/L3 cache info and an assocs[] associativity mapping array, by
adding entries for 3-way caches and 6-way caches.

Properly handle the case where CPUID(0x80000006) returns an L2/L3
associativity of 9.  This is not real associativity, but a marker to
indicate that the respective L2/L3 cache information should be retrieved
from CPUID(0x8000001d) instead.  If such a marker is encountered, return
early from legacy_amd_cpuid4(), thus effectively emulating an "invalid
index" CPUID(4) response with a cache type of zero.

When checking if CPUID(0x80000006) L2/L3 cache info output is valid, and
given the associtivity marker 9 above, do not just check if the whole
ECX/EDX register is zero.  Rather, check if the associativity is zero or
9.  An associativity of zero implies no L2/L3 cache, which make it the
more correct check anyway vs. a zero check of the whole output register.

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 | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index f4817cd50cfb..52727f8c0006 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -89,9 +89,13 @@ static const enum cache_type cache_type_map[] = {
 /*
  * Fallback AMD CPUID(4) emulation
  * AMD CPUs with TOPOEXT can just use CPUID(0x8000001d)
+ *
+ * @AMD_L2_L3_INVALID_ASSOC: cache info for the respective L2/L3 cache should
+ * be determined from CPUID(0x8000001d) instead of CPUID(0x80000006).
  */
 
 #define AMD_CPUID4_FULLY_ASSOCIATIVE	0xffff
+#define AMD_L2_L3_INVALID_ASSOC		0x9
 
 union l1_cache {
 	struct {
@@ -128,7 +132,9 @@ union l3_cache {
 static const unsigned short assocs[] = {
 	[1]		= 1,
 	[2]		= 2,
+	[3]		= 3,
 	[4]		= 4,
+	[5]		= 6,
 	[6]		= 8,
 	[8]		= 16,
 	[0xa]		= 32,
@@ -172,7 +178,7 @@ static void legacy_amd_cpuid4(int index, union _cpuid4_leaf_eax *eax,
 		size_in_kb	= l1->size_in_kb;
 		break;
 	case 2:
-		if (!l2.val)
+		if (!l2.assoc || l2.assoc == AMD_L2_L3_INVALID_ASSOC)
 			return;
 
 		/* Use x86_cache_size as it might have K7 errata fixes */
@@ -182,7 +188,7 @@ static void legacy_amd_cpuid4(int index, union _cpuid4_leaf_eax *eax,
 		size_in_kb	= __this_cpu_read(cpu_info.x86_cache_size);
 		break;
 	case 3:
-		if (!l3.val)
+		if (!l3.assoc || l3.assoc == AMD_L2_L3_INVALID_ASSOC)
 			return;
 
 		assoc		= assocs[l3.assoc];
-- 
2.49.0

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

[Ingo Molnar]

* 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

[tip: x86/cpu] x86/cacheinfo: Properly parse CPUID(0x80000006) L2/L3 associativity

[tip-bot2 for Ahmed S. Darwish]

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

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

x86/cacheinfo: Properly parse CPUID(0x80000006) L2/L3 associativity

Complete the AMD CPUID(4) emulation logic, which uses CPUID(0x80000006)
for L2/L3 cache info and an assocs[] associativity mapping array, by
adding entries for 3-way caches and 6-way caches.

Properly handle the case where CPUID(0x80000006) returns an L2/L3
associativity of 9.  This is not real associativity, but a marker to
indicate that the respective L2/L3 cache information should be retrieved
from CPUID(0x8000001d) instead.  If such a marker is encountered, return
early from legacy_amd_cpuid4(), thus effectively emulating an "invalid
index" CPUID(4) response with a cache type of zero.

When checking if CPUID(0x80000006) L2/L3 cache info output is valid, and
given the associtivity marker 9 above, do not just check if the whole
ECX/EDX register is zero.  Rather, check if the associativity is zero or
9.  An associativity of zero implies no L2/L3 cache, which make it the
more correct check anyway vs. a zero check of the whole output register.

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-3-darwi@linutronix.de
---
 arch/x86/kernel/cpu/cacheinfo.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index f4817cd..52727f8 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -89,9 +89,13 @@ static const enum cache_type cache_type_map[] = {
 /*
  * Fallback AMD CPUID(4) emulation
  * AMD CPUs with TOPOEXT can just use CPUID(0x8000001d)
+ *
+ * @AMD_L2_L3_INVALID_ASSOC: cache info for the respective L2/L3 cache should
+ * be determined from CPUID(0x8000001d) instead of CPUID(0x80000006).
  */
 
 #define AMD_CPUID4_FULLY_ASSOCIATIVE	0xffff
+#define AMD_L2_L3_INVALID_ASSOC		0x9
 
 union l1_cache {
 	struct {
@@ -128,7 +132,9 @@ union l3_cache {
 static const unsigned short assocs[] = {
 	[1]		= 1,
 	[2]		= 2,
+	[3]		= 3,
 	[4]		= 4,
+	[5]		= 6,
 	[6]		= 8,
 	[8]		= 16,
 	[0xa]		= 32,
@@ -172,7 +178,7 @@ static void legacy_amd_cpuid4(int index, union _cpuid4_leaf_eax *eax,
 		size_in_kb	= l1->size_in_kb;
 		break;
 	case 2:
-		if (!l2.val)
+		if (!l2.assoc || l2.assoc == AMD_L2_L3_INVALID_ASSOC)
 			return;
 
 		/* Use x86_cache_size as it might have K7 errata fixes */
@@ -182,7 +188,7 @@ static void legacy_amd_cpuid4(int index, union _cpuid4_leaf_eax *eax,
 		size_in_kb	= __this_cpu_read(cpu_info.x86_cache_size);
 		break;
 	case 3:
-		if (!l3.val)
+		if (!l3.assoc || l3.assoc == AMD_L2_L3_INVALID_ASSOC)
 			return;
 
 		assoc		= assocs[l3.assoc];

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

[tip-bot2 for Ahmed S. Darwish]

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;

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

[Ahmed S. Darwish]

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