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

Hi,

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/[email protected]

    https://lore.kernel.org/lkml/[email protected]

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 | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 --
2.49.0

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.

---
 arch/x86/kernel/cpu/cacheinfo.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

index b3a520959b51..7a95e1ce73f8 100644
@@ -208,6 +208,9 @@ union l3_cache {
 	unsigned val;
 };
 
+#define AMD_CPUID4_FULLY_ASSOCIATIVE	0xffff
+
+/* L2/L3 associativity mapping */
 static const unsigned short assocs[] = {
 	[1] = 1,
 	[2] = 2,

@@ -219,7 +222,7 @@ static const unsigned short assocs[] = {
 	[0xc] = 64,
 	[0xd] = 96,
 	[0xe] = 128,
-	[0xf] = 0xffff /* fully associative - no way to show this currently */
+	[0xf] = AMD_CPUID4_FULLY_ASSOCIATIVE
 };
 
 static const unsigned char levels[] = { 1, 1, 2, 3 };

@@ -258,7 +261,7 @@ amd_cpuid4(int leaf, union _cpuid4_leaf_eax *eax,
 	case 0:
 		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;

@@ -295,7 +298,7 @@ amd_cpuid4(int leaf, union _cpuid4_leaf_eax *eax,
 	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;
 	ebx->split.ways_of_associativity = assoc - 1;

2.49.0

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.

---
 arch/x86/kernel/cpu/cacheinfo.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

index 7a95e1ce73f8..038f819da20e 100644
@@ -208,13 +208,20 @@ union l3_cache {
 	unsigned val;
 };
 
+/*
+ * 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
 
 /* L2/L3 associativity mapping */
 static const unsigned short assocs[] = {
 	[1] = 1,
 	[2] = 2,
+	[3] = 3,
 	[4] = 4,
+	[5] = 6,
 	[6] = 8,
 	[8] = 16,
 	[0xa] = 32,

@@ -267,7 +274,7 @@ amd_cpuid4(int leaf, 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;
 		assoc = assocs[l2.assoc];
 		line_size = l2.line_size;

@@ -276,7 +283,7 @@ amd_cpuid4(int leaf, 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];
 		line_size = l3.line_size;

2.49.0

Could you please send these against tip:master?

tip:x86/cpu already has your previous series, and I don't see the need to create a version skew between v6.15 and the x86 tree for v6.16.

Thanks,

Ingo

Hi,

Sure, I've just sent v2 over tip:master here:

https://lore.kernel.org/lkml/[email protected]

Ironically, this PQ was originally on top of tip:x86/cpu, but I was not sure if the tip:x86/cpu CPUID refactorings will be sent to Linus at this merge window or the next — so I thought I'd make everyone's life "easier" by just basing on -rc1 instead.

(The -stable trees will have trouble merging this v2 -- but at least v1
shows the same PQ before the CPUID refactorings at tip:x86/cpu.)

Thanks a lot,

--
Ahmed S. Darwish
Linutronix GmbH

Applied, thanks!

Ingo