]> git.ipfire.org Git - thirdparty/linux.git/commit
x86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity
authorAhmed S. Darwish <darwi@linutronix.de>
Wed, 9 Apr 2025 12:22:30 +0000 (14:22 +0200)
committerIngo Molnar <mingo@kernel.org>
Wed, 9 Apr 2025 18:47:05 +0000 (20:47 +0200)
commitd274cde0dbe0217ee2f2ddbb1a3c545dedf81a06
tree7d8a22e4522c432c7193e7e1dff69e568749a932
parente37aa1211fbfeb9d5e79f4a4b0da898e6d0d53bb
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