> From: Andy Lutomirski <luto@xxxxxxxxxx> > On Thu, Oct 1, 2020 at 1:43 PM Chang S. Bae <chang.seok.bae@xxxxxxxxx> wrote: > > "xstate.disable=0x6000" will disable AMX on a system that has AMX > > compiled into XFEATURE_MASK_USER_SUPPORTED. > Can we please use words for this? Perhaps: > xstate.disable=amx,zmm Yes, I think it is reasonable to add support for keywords for the features that are both supported by the hardware and known by the kernel. However, we need to continue to support numerical state-component bitmap format. Otherwise, it would not be possible to coerce a legacy kernel (eg. a distro kernel) to enable a feature on a new machine until it has been updated to know that keyword. > and maybe add a list in /proc/cpuinfo or somewhere in /proc or /sys that shows all the currently enabled xsave states. Agreed, if we invent keywords, the list of supported+known keywords should be available on the system. I do not advocate /proc/cpuinfo -- which is already an out of control parsing mess. We could add the keywords to dmesg, since we already print the supported XSAVE BV: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' Or maybe a sysfs attribute or a modparam that simply lists them all. We wouldn't be able to dynamically _write_ to that attribute, since the cmdline is boot-time only. > > "xstate.enable=0x6000" will enable AMX on a system that does NOT have > > AMX compiled into XFEATURE_MASK_USER_SUPPORTED (assuming the kernel is > > new enough to support this feature). > > This sounds like it will be quite confusing to anyone reading the kernel code to discover that a feature that is not "SUPPORTED" is nonetheless enabled. Right now, this cmdline will only allow a new kernel to enable/disable kernel support for AMX on hardware that also supports AMX. But we hope to re-use this XSTATE code -- unchanged -- for future features that require just this simple state management support from the kernel. We anticipate a future hardware enumeration mechanism to identify such qualified features to assist the kernel in deciding whether to support a feature or not, by default. The kernel can use the combination of its build-time config with advice from this boot-time enumeration to decide if it wants to enable a particular feature or not. And at the end, a user is empowered to override that default using this cmdline. Thanks, -Len
