linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
       [not found] <20201001203913.9125-1-chang.seok.bae@intel.com>
@ 2020-10-01 20:39 ` Chang S. Bae
  2020-10-02  2:09   ` Randy Dunlap
                     ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Chang S. Bae @ 2020-10-01 20:39 UTC (permalink / raw)
  To: tglx, mingo, bp, luto, x86
  Cc: len.brown, dave.hansen, jing2.liu, ravi.v.shankar, linux-kernel,
	chang.seok.bae, linux-doc

"xstate.disable=0x6000" will disable AMX on a system that has AMX compiled
into XFEATURE_MASK_USER_SUPPORTED.

"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).

While this cmdline is currently enabled only for AMX, it is intended to be
easily enabled to be useful for future XSAVE-enabled features.

Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Reviewed-by: Len Brown <len.brown@intel.com>
Cc: x86@kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 .../admin-guide/kernel-parameters.txt         | 15 ++++++
 arch/x86/include/asm/fpu/types.h              |  6 +++
 arch/x86/kernel/fpu/init.c                    | 52 +++++++++++++++++--
 3 files changed, 70 insertions(+), 3 deletions(-)

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
+			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.
+
 	xirc2ps_cs=	[NET,PCMCIA]
 			Format:
 			<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 002248dba6dc..2a944e8903bb 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -148,6 +148,12 @@ enum xfeature {
 #define XFEATURE_MASK_XTILE		(XFEATURE_MASK_XTILE_DATA \
 					 | XFEATURE_MASK_XTILE_CFG)
 
+#define XFEATURE_REGION_MASK(max_bit, min_bit) \
+	((BIT_ULL((max_bit) - (min_bit) + 1) - 1) << (min_bit))
+
+#define XFEATURE_MASK_CONFIGURABLE \
+	XFEATURE_REGION_MASK(XFEATURE_XTILE_DATA, XFEATURE_XTILE_CFG)
+
 #define FIRST_EXTENDED_XFEATURE	XFEATURE_YMM
 
 struct reg_128_bit {
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 8e2a77bc1782..a354286e7c90 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -227,13 +227,42 @@ static void __init fpu__init_system_xstate_size_legacy(void)
  * This must be called after fpu__init_parse_early_param() is called and
  * xfeatures_mask is enumerated.
  */
+
+static u64 xstate_enable;
+static u64 xstate_disable;
+
 u64 __init fpu__get_supported_xfeatures_mask(void)
 {
 	u64 mask = XFEATURE_MASK_USER_SUPPORTED | XFEATURE_MASK_SUPERVISOR_SUPPORTED;
 
-	if (!IS_ENABLED(CONFIG_X86_64))
-		mask &= ~(XFEATURE_MASK_XTILE);
-
+	if (!IS_ENABLED(CONFIG_X86_64)) {
+		mask  &= ~(XFEATURE_MASK_XTILE);
+	} else if (xstate_enable || xstate_disable) {
+		u64 custom = mask;
+		u64 unknown;
+
+		custom |= xstate_enable;
+		custom &= ~xstate_disable;
+
+		unknown = custom & ~mask;
+		if (unknown) {
+			/*
+			 * User should fully understand the result of using undocumented
+			 * xstate component
+			 */
+			pr_warn("x86/fpu: Attempt to enable unknown xstate features 0x%llx\n",
+				unknown);
+			WARN_ON_FPU(1);
+		}
+
+		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);
+		}
+
+		mask = custom;
+	}
 	return mask;
 }
 
@@ -254,6 +283,7 @@ static void __init fpu__init_parse_early_param(void)
 {
 	char arg[32];
 	char *argptr = arg;
+	u64 mask;
 	int bit;
 
 #ifdef CONFIG_X86_32
@@ -283,6 +313,22 @@ static void __init fpu__init_parse_early_param(void)
 	    bit >= 0 &&
 	    bit < NCAPINTS * 32)
 		setup_clear_cpu_cap(bit);
+
+	if (cmdline_find_option(boot_command_line, "xstate.enable", arg,
+				sizeof(arg)) &&
+	    !kstrtoull(arg, 16, &mask) &&
+	    (mask &= XFEATURE_MASK_CONFIGURABLE))
+		xstate_enable = mask;
+	else
+		xstate_enable = 0;
+
+	if (cmdline_find_option(boot_command_line, "xstate.disable", arg,
+				sizeof(arg)) &&
+	    !kstrtoull(arg, 16, &mask) &&
+	    (mask &= XFEATURE_MASK_CONFIGURABLE))
+		xstate_disable = mask;
+	else
+		xstate_disable = 0;
 }
 
 /*
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
  2020-10-01 20:39 ` [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support Chang S. Bae
@ 2020-10-02  2:09   ` Randy Dunlap
  2020-10-13 23:00     ` Brown, Len
  2020-10-02 17:15   ` Andy Lutomirski
  2020-10-02 17:25   ` Dave Hansen
  2 siblings, 1 reply; 7+ messages in thread
From: Randy Dunlap @ 2020-10-02  2:09 UTC (permalink / raw)
  To: Chang S. Bae, tglx, mingo, bp, luto, x86
  Cc: len.brown, dave.hansen, jing2.liu, ravi.v.shankar, linux-kernel,
	linux-doc

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
  2020-10-01 20:39 ` [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support Chang S. Bae
  2020-10-02  2:09   ` Randy Dunlap
@ 2020-10-02 17:15   ` Andy Lutomirski
  2020-10-02 17:26     ` Dave Hansen
  2020-10-13 23:38     ` Brown, Len
  2020-10-02 17:25   ` Dave Hansen
  2 siblings, 2 replies; 7+ messages in thread
From: Andy Lutomirski @ 2020-10-02 17:15 UTC (permalink / raw)
  To: Chang S. Bae
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Andrew Lutomirski,
	X86 ML, Len Brown, Dave Hansen, jing2.liu, Ravi V. Shankar, LKML,
	open list:DOCUMENTATION

On Thu, Oct 1, 2020 at 1:43 PM Chang S. Bae <chang.seok.bae@intel.com> 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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
  2020-10-01 20:39 ` [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support Chang S. Bae
  2020-10-02  2:09   ` Randy Dunlap
  2020-10-02 17:15   ` Andy Lutomirski
@ 2020-10-02 17:25   ` Dave Hansen
  2 siblings, 0 replies; 7+ messages in thread
From: Dave Hansen @ 2020-10-02 17:25 UTC (permalink / raw)
  To: Chang S. Bae, tglx, mingo, bp, luto, x86
  Cc: len.brown, jing2.liu, ravi.v.shankar, linux-kernel, linux-doc

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'".

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
  2020-10-02 17:15   ` Andy Lutomirski
@ 2020-10-02 17:26     ` Dave Hansen
  2020-10-13 23:38     ` Brown, Len
  1 sibling, 0 replies; 7+ messages in thread
From: Dave Hansen @ 2020-10-02 17:26 UTC (permalink / raw)
  To: Andy Lutomirski, Chang S. Bae
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, X86 ML, Len Brown,
	jing2.liu, Ravi V. Shankar, LKML, open list:DOCUMENTATION

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.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
  2020-10-02  2:09   ` Randy Dunlap
@ 2020-10-13 23:00     ` Brown, Len
  0 siblings, 0 replies; 7+ messages in thread
From: Brown, Len @ 2020-10-13 23:00 UTC (permalink / raw)
  To: Randy Dunlap, Bae, Chang Seok, tglx, mingo, bp, luto, x86
  Cc: Hansen, Dave, Liu, Jing2, Shankar, Ravi V, linux-kernel, linux-doc


> From: Randy Dunlap <rdunlap@infradead.org> 

> 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.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'

Thanks,
-Len


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support
  2020-10-02 17:15   ` Andy Lutomirski
  2020-10-02 17:26     ` Dave Hansen
@ 2020-10-13 23:38     ` Brown, Len
  1 sibling, 0 replies; 7+ messages in thread
From: Brown, Len @ 2020-10-13 23:38 UTC (permalink / raw)
  To: Andy Lutomirski, Bae, Chang Seok
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, X86 ML, Hansen,
	Dave, Liu, Jing2, Shankar, Ravi V, LKML, open list:DOCUMENTATION

> From: Andy Lutomirski <luto@kernel.org> 

> On Thu, Oct 1, 2020 at 1:43 PM Chang S. Bae <chang.seok.bae@intel.com> 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


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-10-13 23:38 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20201001203913.9125-1-chang.seok.bae@intel.com>
2020-10-01 20:39 ` [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support Chang S. Bae
2020-10-02  2:09   ` Randy Dunlap
2020-10-13 23:00     ` Brown, Len
2020-10-02 17:15   ` Andy Lutomirski
2020-10-02 17:26     ` Dave Hansen
2020-10-13 23:38     ` Brown, Len
2020-10-02 17:25   ` Dave Hansen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).