From: Ingo Molnar <mingo@kernel.org>
To: Dave Hansen <dave@sr71.net>
Cc: dave.hansen@linux.intel.com, mingo@redhat.com, x86@kernel.org,
bp@alien8.de, fenghua.yu@intel.com, tim.c.chen@linux.intel.com,
linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 08/11] x86, fpu: add C structures for AVX-512 state components
Date: Fri, 28 Aug 2015 07:00:01 +0200 [thread overview]
Message-ID: <20150828050000.GC25556@gmail.com> (raw)
In-Reply-To: <20150827171110.76A7A0C2@viggo.jf.intel.com>
* Dave Hansen <dave@sr71.net> wrote:
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> AVX-512 has 3 separate state components:
> 1. opmask registers
> 2. zmm upper half of registers 0-15
> 3. new zmm registers (16-31)
>
> This patch adds C structures for the three components along with
> a few comments mostly lifted from the SDM to explain what they
> do. This will allow us to check our structures against what the
> hardware tells us about the sizes of the components.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: x86@kernel.org
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: Tim Chen <tim.c.chen@linux.intel.com>
> Cc: linux-kernel@vger.kernel.org
> ---
>
> b/arch/x86/include/asm/fpu/types.h | 43 ++++++++++++++++++++++++++++++++++---
> 1 file changed, 40 insertions(+), 3 deletions(-)
>
> diff -puN arch/x86/include/asm/fpu/types.h~avx-512-structs arch/x86/include/asm/fpu/types.h
> --- a/arch/x86/include/asm/fpu/types.h~avx-512-structs 2015-08-27 10:08:03.909740783 -0700
> +++ b/arch/x86/include/asm/fpu/types.h 2015-08-27 10:08:03.912740919 -0700
> @@ -129,6 +129,12 @@ enum xfeature_nr {
> struct reg_128_bit {
> u8 regbytes[128/8];
> };
> +struct reg_256_bit {
> + u8 regbytes[256/8];
> +};
> +struct reg_512_bit {
> + u8 regbytes[512/8];
> +};
>
> /*
> * State component 2:
> @@ -177,6 +183,33 @@ struct mpx_bndcsr_state {
> };
> } __packed;
>
> +/* AVX-512 Components: */
> +
> +/*
> + * State component 5 is used for the 8 64-bit opmask registers
> + * k0–k7 (opmask state).
> + */
> +struct avx_512_opmask_state {
> + u64 opmask_reg[8];
> +} __packed;
> +
> +/*
> + * State component 6 is used for the upper 256 bits of the
> + * registers ZMM0–ZMM15. These 16 256-bit values are denoted
> + * ZMM0_H–ZMM15_H (ZMM_Hi256 state).
> + */
> +struct avx_512_zmm_uppers_state {
> + struct reg_256_bit zmm_upper[16];
> +} __packed;
> +
> +/*
> + * State component 7 is used for the 16 512-bit registers
> + * ZMM16–ZMM31 (Hi16_ZMM state).
> + */
> +struct avx_512_hi16_state {
> + struct reg_512_bit hi16_zmm[16];
> +} __packed;
> +
> struct xstate_header {
> u64 xfeatures;
> u64 xcomp_bv;
> @@ -184,9 +217,13 @@ struct xstate_header {
> } __attribute__((packed));
>
> /* New processor state extensions should be added here: */
> -#define XSTATE_RESERVE (sizeof(struct ymmh_struct) + \
> - sizeof(struct mpx_bndreg_state) + \
> - sizeof(struct mpx_bndcsr_state) )
> +#define XSTATE_RESERVE (sizeof(struct ymmh_struct) + \
> + sizeof(struct mpx_bndreg_state) + \
> + sizeof(struct mpx_bndcsr_state) + \
> + sizeof(struct avx_512_opmask_state) + \
> + sizeof(struct avx_512_zmm_uppers_state) + \
> + sizeof(struct avx_512_hi16_state))
So in a previous mail I suggested getting rid of XSTATE_RESERVE, which removes the
usage of the C structures..
What we could use these C structures for is to double check that the xstate size
given by CPUID for that particular xstate feature is equal to the C structure size
- or if it's larger, it's a multiple of the natural cache line size, or so?
Any 'failure' in such a check should be print-once and non-fatal, as in 90% of the
cases I'd expect the kernel assumptions/checks to be buggy, not the hardware
itself.
We should perhaps also print a gentle (non-warning) kernel message if we find an
xfeature that the kernel doesn't know about, with its essential parameters: the
bit number, the size and the offset position within the xstate buffer.
Thanks,
Ingo
next prev parent reply other threads:[~2015-08-28 5:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-27 17:11 [PATCH 00/11] [v2] x86, fpu: XSAVE cleanups and sanity checks Dave Hansen
2015-08-27 17:11 ` [PATCH 01/11] x86, fpu: kill LWP support Dave Hansen
2015-08-28 4:50 ` Ingo Molnar
2015-08-27 17:11 ` [PATCH 02/11] x86, fpu: rename xfeature_bit Dave Hansen
2015-08-28 5:16 ` Ingo Molnar
2015-08-27 17:11 ` [PATCH 03/11] x86, fpu: rework XSTATE_* macros to remove magic '2' Dave Hansen
2015-08-27 17:11 ` [PATCH 04/11] x86, fpu: remove xfeature_nr Dave Hansen
2015-08-28 5:06 ` Ingo Molnar
2015-08-27 17:11 ` [PATCH 05/11] x86, fpu: add helper xfeature_nr_enabled() instead of test_bit() Dave Hansen
2015-08-28 5:04 ` Ingo Molnar
2015-08-27 17:11 ` [PATCH 06/11] x86, fpu: rework MPX 'xstate' types Dave Hansen
2015-08-27 17:11 ` [PATCH 07/11] x86, fpu: rework YMM definition Dave Hansen
2015-08-27 17:11 ` [PATCH 09/11] x86, fpu: correct and check XSAVE xstate size calculations Dave Hansen
2015-08-28 4:54 ` Ingo Molnar
2015-08-28 14:31 ` Dave Hansen
2015-08-28 16:44 ` Andi Kleen
2015-08-27 17:11 ` [PATCH 10/11] x86, fpu: check to ensure increasing-offset xstate offsets Dave Hansen
2015-08-27 17:11 ` [PATCH 08/11] x86, fpu: add C structures for AVX-512 state components Dave Hansen
2015-08-28 5:00 ` Ingo Molnar [this message]
2015-08-27 17:11 ` [PATCH 11/11] x86, fpu: check CPU-provided sizes against struct declarations Dave Hansen
2015-08-28 5:25 ` Ingo Molnar
2015-08-28 16:02 ` Dave Hansen
2015-08-28 5:18 ` [PATCH 00/11] [v2] x86, fpu: XSAVE cleanups and sanity checks Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2015-08-25 20:12 [PATCH 00/11] " Dave Hansen
2015-08-25 20:12 ` [PATCH 08/11] x86, fpu: add C structures for AVX-512 state components Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150828050000.GC25556@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dave@sr71.net \
--cc=fenghua.yu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.