On Wed, Jun 23, 2021 at 05:04:27PM +0200, Florian Weimer wrote: Copying in Catalin & Will. > We have an interface in glibc to query CPU features: > X86-specific Facilities > <https://www.gnu.org/software/libc/manual/html_node/X86.html> > CPU_FEATURE_USABLE all preconditions for a feature are met, > HAS_CPU_FEATURE means it's in silicon but possibly dormant. > CPU_FEATURE_USABLE is supposed to look at XCR0, AT_HWCAP2 etc. before > enabling the relevant bit (so it cannot pass through any unknown bits). ... > When we designed this glibc interface, we assumed that bits would be > static during the life-time of the process, initialized at process > start. That follows the model of previous x86 CPU feature enablement. ... > This still wouldn't cover the enable/disable side, but at least it would > work for CPU features which are modal and come and go. The fact that we > tell GCC to cache the returned pointer from that internal function, but > not that the data is immutable works to our advantage here. > On the other hand, maybe there is a way to give users a better > interface. Obviously we want to avoid a syscall for a simple CPU > feature check. And we also need something to enable/disable CPU > features. This enabling and disabling of CPU features sounds like something that might also become relevant for arm64, for example I can see a use case for having something that allows some of the more expensive features to be masked from some userspace processes for resource management purposes. This sounds like a bit of a different use case to x86 AIUI but I think there's overlap in the actual operations that would be needed.
Attachment:
signature.asc
Description: PGP signature
