Messages in this thread | | | Subject | Re: x86 CPU features detection for applications (and AMX) | From | Dave Hansen <> | Date | Thu, 8 Jul 2021 07:36:44 -0700 |
| |
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.
| |