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

"tip-bot2 for Ahmed S. Darwish" <[email protected]>
Newsgroups dev.linux.lists.x86-cpuid,org.kernel.vger.linux-kernel
Message-ID <174422761402.31282.13417527364559338124.tip-bot2@tip-bot2>
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 <[email protected]>
AuthorDate:    Wed, 09 Apr 2025 14:22:30 +02:00
Committer:     Ingo Molnar <[email protected]>
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 <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Cc: Andrew Cooper <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: John Ogness <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
---
 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;
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.