Summary: | New AMD cache size computation logic does not work for some CPUs, hypervisors | ||
---|---|---|---|
Product: | glibc | Reporter: | Florian Weimer <fw> |
Component: | dynamic-link | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | critical | CC: | fweimer, jamborm, sam |
Priority: | P1 | Flags: | fw:
security-
|
Version: | 2.38 | ||
Target Milestone: | 2.39 | ||
See Also: |
https://bugzilla.redhat.com/show_bug.cgi?id=2196271 https://sourceware.org/bugzilla/show_bug.cgi?id=29953 |
||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Florian Weimer
2023-05-08 16:42:13 UTC
Just to clarify: this regression affects sysconf (_SC_LEVEL2_CACHE_SIZE) and similar configuration values, so it impacts more than just glibc-internal tuning decisions. Initial patch posted (still alters results compared to what we had before): [PATCH] x86: Fix for cache computation on AMD legacy cpus. <https://sourceware.org/pipermail/libc-alpha/2023-June/148763.html> Has this been addressed(*)? If so, could the respective commit ID's be posted here for reference, please? (*) https://sourceware.org/pipermail/libc-alpha/2023-June/148812.html would suggest that it was but perhaps not entirely? Fixed for 2.39 via: commit dcad5c8578130dec7f35fd5b0885304b59f9f543 Author: Sajan Karumanchi <sajan.karumanchi@amd.com> Date: Tue Aug 1 15:20:55 2023 +0000 x86: Fix for cache computation on AMD legacy cpus. Some legacy AMD CPUs and hypervisors have the _cpuid_ '0x8000_001D' set to Zero, thus resulting in zeroed-out computed cache values. This patch reintroduces the old way of cache computation as a fail-safe option to handle these exceptions. Fixed 'level4_cache_size' value through handle_amd(). Reviewed-by: Premachandra Mallappa <premachandra.mallappa@amd.com> Tested-by: Florian Weimer <fweimer@redhat.com> It seems that we are still missing the backport to 2.37. |