On Fri, Mar 26, 2021 at 8:34 AM Len Brown <l...@kernel.org> wrote: > > On Thu, Mar 25, 2021 at 9:42 PM Andy Lutomirski <l...@kernel.org> wrote: > > > Regardless of what you call AMX, AMX requires kernel enabling. > > I submit, that after the generic XFD support is in place, > there is exactly 1 bit that needs to be flipped to enable > user applications to benefit from AMX.
The TILERELEASE opcode itself is rather longer than one bit, and the supporting code to invoke it at the right time, to avoid corrupting user state, and avoid causing performance regressions merely by existing will be orders of magnitude more than 1 bit. Of course, all of this is zero bits in the current series because the code is missing.entirely. To avoid email thread blowup: > If there is a new requirement that the kernel cmdline not allow anything > that a distro didn't explicitly validate, then about 99.9% of the kernel > cmdline > options that exist today would need to be removed. > > Does such a requirement exist, or does it not? This isn't just about validation. There's also ABI, performance, and correctness: ABI: The AVX-512 enablement *already* broke user ABI. Sadly no one told anyone in the kernel community until about 5 years after the fact, and it's a bit late to revert AVX-512. But we don't want to enable AMX until the ABI has a reasonable chance of being settled. Ditto for future features. As it stands, if you xstate.enable some 16MB feature, the system may well simply fail to boot as too many user processes explode. Performance: We *still* don't know the performance implications of leaving the AMX features in use inappropriately. Does it completely destroy idle? Will it literally operate CPUs out of spec such that Intel's reliability estimates will be invalidated? (We had that with NVMe APST. Let's not repeat this with XSTATE.) The performance impacts and transitions for AVX-512 are, to put it charitably, forthcoming. Correctness: PKRU via the kernel's normal XSAVE path would simply be incorrect. Do we really trust that this won't get repeated? Also, frankly, a command line option that may well break lots of userspace but that we fully expect Intel to recommend setting is not a good thing. --Andy
