RE: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
> From: Andy Lutomirski > On Thu, Oct 1, 2020 at 1:43 PM Chang S. Bae 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.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] 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
RE: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
> From: Randy Dunlap > What do these bitmasks look like? what do the bits mean? > Where does a user find this info? The XSAVE state component bitmaps are detailed in the Intel Software Developer's Manual, volume 1, Chapter 13: "Managing State using the XSAVE Feature Set". http://intel.com/sdm In the kernel source, they are enumerated in xstate.c and you can observe them in dmesg: [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' Thanks, -Len
Re: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
On 10/2/20 10:15 AM, Andy Lutomirski wrote: >> "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. Yeah, if we do this, XFEATURE_MASK_USER_SUPPORTED needs a name change for sure.
Re: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
On 10/1/20 1:39 PM, Chang S. Bae wrote:
> + if ((custom & XFEATURE_MASK_XTILE) != XFEATURE_MASK_XTILE) {
> + pr_warn("x86/fpu: Disable 0x%x components due to
> incorrect setup\n",
> + XFEATURE_MASK_XTILE);
> + custom &= ~(XFEATURE_MASK_XTILE);
> + }
Saying "incorrect setup" is pretty much just wasting the bytes. We
might as well just say "disabling due to random error", or "disabling
due to the easter bunny". Each are equally actionable. How about:
"error in xstate.disable parameter. Additionally disabling '%s'".
Re: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
On Thu, Oct 1, 2020 at 1:43 PM Chang S. Bae 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 and maybe add a list in /proc/cpuinfo or somewhere in /proc or /sys that shows all the currently enabled xsave states. > > "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.
Re: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
Hi-- On 10/1/20 1:39 PM, Chang S. Bae wrote: > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index a1068742a6df..742167c6f789 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -5838,6 +5838,21 @@ > which allow the hypervisor to 'idle' the guest on lock > contention. > > + xstate.enable= [X86-64] > + xstate.disable= [X86-64] > + The kernel is compiled with a default xstate bitmask -- > + enabling it to use the XSAVE hardware to efficiently > + save and restore thread states on context switch. > + xstate.enable allows adding to that default mask at > + boot-time without recompiling the kernel just to support > + the new thread state. (Note that the kernel will ignore > + any bits in the mask that do not correspond to features > + that are actually available in CPUID) xstate.disable in CPUID.) > + allows clearing bits in the default mask, forcing the > + kernel to forget that it supports the specified thread > + state. When a bit set for both, the kernel takes > + xstate.disable in a priority. as a priority. What do these bitmasks look like? what do the bits mean? Where does a user find this info? thanks. -- ~Randy
