Re: x86 CPU features detection for applications (and AMX)

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]