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

On 7/8/21 7:31 AM, Florian Weimer wrote:

quoted

OK, so if I call CPU_FEATURE_USABLE(PKS) on a system *WITH* PKS
supported in the operating system, I'll get false from an interface that
claims to be:

quoted

This macro returns a nonzero value (true) if the processor has the
feature name and the feature is supported by the operating system.

The interface just seems buggy by *design*.

Yes, but that is largely a documentation matter.  We should have said
something about “userspace” there, and that the bit needs to be known to
glibc.  There is another exception: FSGSBASE, and that's a real bug we
need to fix (it has to go through AT_HWCAP2).

If we want to avoid that, we need to go down the road of a curated set
of CPUID bits, where a bit only exists if we have taught glibc its
semantics.  You still might get a false negative by running against an
older glibc than the application was built for.  (We are not going to
force applications that e.g. look for FSGSBASE only run with a glibc
that is at least of that version which implemented semantics for the
FSGSBASE bit.)

That's kinda my whole point.

These *MUST* be curated to be meaningful.  Right now, someone just
dumped a set of CPUID bits into the documentation.

The interface really needs *three* modes:

1. Yes, the CPU/OS supports this feature
2. No, the CPU/OS doesn't support this feature
3. Hell if I know, never heard of this feature
	
The interface really conflates 2 and 3.  To me, that makes it
fundamentally flawed.