diff options
| author | Ahmed S. Darwish <[email protected]> | 2025-04-09 12:22:31 +0000 |
|---|---|---|
| committer | Ingo Molnar <[email protected]> | 2025-04-09 18:47:05 +0000 |
| commit | d02c83d75f9f76dda046edbd9f39b911427677c9 (patch) | |
| tree | 0c74237e88599a4a928c60c6f960005412ecd26a /net/core/dev_api.c | |
| parent | x86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity (diff) | |
| download | kernel-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
