aboutsummaryrefslogtreecommitdiffstats
path: root/net/core/dev_api.c
diff options
context:
space:
mode:
authorAhmed S. Darwish <[email protected]>2025-04-09 12:22:30 +0000
committerIngo Molnar <[email protected]>2025-04-09 18:47:05 +0000
commitd274cde0dbe0217ee2f2ddbb1a3c545dedf81a06 (patch)
tree7d8a22e4522c432c7193e7e1dff69e568749a932 /net/core/dev_api.c
parentx86/cpuid: Add AMX and SPEC_CTRL dependencies (diff)
downloadkernel-d274cde0dbe0217ee2f2ddbb1a3c545dedf81a06.tar.gz
kernel-d274cde0dbe0217ee2f2ddbb1a3c545dedf81a06.zip
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]
Diffstat (limited to 'net/core/dev_api.c')
0 files changed, 0 insertions, 0 deletions