* Re: x86 CPU features detection for applications (and AMX) [not found] ` <e376bcb9-cd79-7665-5859-ae808dd286f1@intel.com> @ 2021-07-08 6:05 ` Florian Weimer 2021-07-08 14:19 ` Dave Hansen 0 siblings, 1 reply; 5+ messages in thread From: Florian Weimer @ 2021-07-08 6:05 UTC (permalink / raw) To: Dave Hansen; +Cc: libc-alpha, linux-api, x86, linux-arch, H.J. Lu, linux-kernel * Dave Hansen: > On 6/23/21 8:04 AM, Florian Weimer wrote: >> https://www.gnu.org/software/libc/manual/html_node/X86.html > ... >> Previously kernel developers have expressed dismay that we didn't >> coordinate the interface with them. This is why I want raise this now. > > This looks basically like someone dumped a bunch of CPUID bit values and > exposed them to applications without considering whether applications > would ever need them. For instance, why would an app ever care about: > > PKS – Protection keys for supervisor-mode pages. > > And how could glibc ever give applications accurate information about > whether PKS "is supported by the operating system"? It just plain > doesn't know, or at least only knows from a really weak ABI like > /proc/cpuinfo. glibc is expected to mask these bits for CPU_FEATURE_USABLE because they have unknown semantics (to glibc). They are still exposed via HAS_CPU_FEATURE. I argued against HAS_CPU_FEATURE because the mere presence of this interface will introduce application bugs because application really must use CPU_FEATURE_USABLE instead. I wanted to go with a curated set of bits, but we couldn't get consensus around that. Curiously, the present interface can expose changing CPU state (if the kernel updates some fixed memory region accordingly), my preferred interface would not have supported that. > It also doesn't seem to tell applications what they want which is, "can > I, the application, *use* this feature?" CPU_FEATURE_USABLE is supposed to be that interface. Thanks, Florian ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: x86 CPU features detection for applications (and AMX) 2021-07-08 6:05 ` x86 CPU features detection for applications (and AMX) Florian Weimer @ 2021-07-08 14:19 ` Dave Hansen 2021-07-08 14:31 ` Florian Weimer 0 siblings, 1 reply; 5+ messages in thread From: Dave Hansen @ 2021-07-08 14:19 UTC (permalink / raw) To: Florian Weimer Cc: libc-alpha, linux-api, x86, linux-arch, H.J. Lu, linux-kernel On 7/7/21 11:05 PM, Florian Weimer wrote: >> This looks basically like someone dumped a bunch of CPUID bit values and >> exposed them to applications without considering whether applications >> would ever need them. For instance, why would an app ever care about: >> >> PKS – Protection keys for supervisor-mode pages. >> >> And how could glibc ever give applications accurate information about >> whether PKS "is supported by the operating system"? It just plain >> doesn't know, or at least only knows from a really weak ABI like >> /proc/cpuinfo. > glibc is expected to mask these bits for CPU_FEATURE_USABLE because they > have unknown semantics (to glibc). 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*. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: x86 CPU features detection for applications (and AMX) 2021-07-08 14:19 ` Dave Hansen @ 2021-07-08 14:31 ` Florian Weimer 2021-07-08 14:36 ` Dave Hansen 0 siblings, 1 reply; 5+ messages in thread From: Florian Weimer @ 2021-07-08 14:31 UTC (permalink / raw) To: Dave Hansen; +Cc: libc-alpha, linux-api, x86, linux-arch, H.J. Lu, linux-kernel * Dave Hansen: > On 7/7/21 11:05 PM, Florian Weimer wrote: >>> This looks basically like someone dumped a bunch of CPUID bit values and >>> exposed them to applications without considering whether applications >>> would ever need them. For instance, why would an app ever care about: >>> >>> PKS – Protection keys for supervisor-mode pages. >>> >>> And how could glibc ever give applications accurate information about >>> whether PKS "is supported by the operating system"? It just plain >>> doesn't know, or at least only knows from a really weak ABI like >>> /proc/cpuinfo. >> glibc is expected to mask these bits for CPU_FEATURE_USABLE because they >> have unknown semantics (to glibc). > > 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.) Thanks, Florian ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: x86 CPU features detection for applications (and AMX) 2021-07-08 14:31 ` Florian Weimer @ 2021-07-08 14:36 ` Dave Hansen 2021-07-08 14:41 ` Florian Weimer 0 siblings, 1 reply; 5+ messages in thread From: Dave Hansen @ 2021-07-08 14:36 UTC (permalink / raw) To: Florian Weimer Cc: libc-alpha, linux-api, x86, linux-arch, H.J. Lu, linux-kernel 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: x86 CPU features detection for applications (and AMX) 2021-07-08 14:36 ` Dave Hansen @ 2021-07-08 14:41 ` Florian Weimer 0 siblings, 0 replies; 5+ messages in thread From: Florian Weimer @ 2021-07-08 14:41 UTC (permalink / raw) To: Dave Hansen; +Cc: libc-alpha, linux-api, x86, linux-arch, H.J. Lu, linux-kernel * Dave Hansen: > 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. That's an interesing point. 3 looks potentially more useful than the feature/usable distinction to me. The recent RTM change suggests that there are more states, but we probably can't do much about such soft-disable changes. Thanks, Florian ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-07-08 14:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <87tulo39ms.fsf@oldenburg.str.redhat.com>
[not found] ` <e376bcb9-cd79-7665-5859-ae808dd286f1@intel.com>
2021-07-08 6:05 ` x86 CPU features detection for applications (and AMX) Florian Weimer
2021-07-08 14:19 ` Dave Hansen
2021-07-08 14:31 ` Florian Weimer
2021-07-08 14:36 ` Dave Hansen
2021-07-08 14:41 ` Florian Weimer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox