* Dave Hansen <[email protected]> wrote:
>
> From: Dave Hansen <[email protected]>
>
> 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 <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: [email protected]
> Cc: Borislav Petkov <[email protected]>
> Cc: Fenghua Yu <[email protected]>
> Cc: Tim Chen <[email protected]>
> Cc: [email protected]
> ---
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
