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

[Dave Hansen <dave.hansen@intel.com>]

On 7/8/21 7:31 AM, Florian Weimer wrote:
>> 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:
>>
>>> 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.