aboutsummaryrefslogtreecommitdiffstats
path: root/net/core/dev_api.c
diff options
context:
space:
mode:
authorAhmed S. Darwish <[email protected]>2025-04-09 12:22:31 +0000
committerIngo Molnar <[email protected]>2025-04-09 18:47:05 +0000
commitd02c83d75f9f76dda046edbd9f39b911427677c9 (patch)
tree0c74237e88599a4a928c60c6f960005412ecd26a /net/core/dev_api.c
parentx86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity (diff)
downloadkernel-d02c83d75f9f76dda046edbd9f39b911427677c9.tar.gz
kernel-d02c83d75f9f76dda046edbd9f39b911427677c9.zip
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 <[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