Page MenuHomeFreeBSD

bhyve: fix CPUID L3 Cache Size reporting for AMD/SVM
ClosedPublic

Authored by kib on Dec 24 2024, 4:21 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 7, 11:15 PM
Unknown Object (File)
Wed, Mar 5, 2:15 AM
Unknown Object (File)
Tue, Mar 4, 4:52 PM
Unknown Object (File)
Sat, Mar 1, 10:14 PM
Unknown Object (File)
Jan 21 2025, 8:36 PM
Unknown Object (File)
Jan 11 2025, 9:38 AM
Unknown Object (File)
Jan 9 2025, 1:45 PM
Unknown Object (File)
Jan 8 2025, 2:17 PM

Details

Summary
Adjust leaf 0x8000_001D %ecx 3 on AMD (L3 cache params).
- Report cache as 1-way associative.  Glibc does not believe that there
  are fully associative L3 caches, ignoring the leaf and falling back to
  legacy way of reading cache params.
- Do not report 4095 logical CPUs per L3 cache, report the true total
  number of emulated CPUs.  The insanely large value tricked some
  version of glibc to overflow 32bit calculation of the L3 cache size,
  as reported in the PR.

Also, for leaf 0x8000_0008, do not clip ApicIdSize to zero if less than
4.  This effectively falls back to legacy.

PR:     279901

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib requested review of this revision.Dec 24 2024, 4:21 AM
kib edited the summary of this revision. (Show Details)

Revert back to 1-way assoc cache.

mp added a subscriber: mp.

Thanks for the patch and update. LGTM!

This revision is now accepted and ready to land.Wed, Mar 5, 1:03 AM

Let me test it too, within a day.