* Dave Hansen <[email protected]> wrote:
> On 07/17/2015 12:45 AM, Ingo Molnar wrote:
> > Just curious: does any released hardware have AVX-512? I went by Wikipedia,
> > which
> > seems to list pre-release hw:
>
>
> >> We might know the size and composition of the individual components, but
> >> we do
> >> not know the size of the buffer. Different implementations of a given
> >> feature
> >> are quite free to have different data stored in the buffer, or even to
> >> rearrange
> >> or pad it. That's why the sizes are not explicitly called out by the
> >> architecture and why we enumerated them before your patch that caused this
> >> regression.
> >
> > But we _have_ to know their structure and layout of the XSAVE context for
> > any
> > reasonable ptrace and signal frame support.
>
> There are two different things here. One is the structure and layout inside
> of
> the state components. That obviously needs full kernel knowledge and can not
> be
> opaque, especially when the kernel needs to go looking at it (like with MPX's
> BNDCSR for instance).
>
> But, the relative layout of the components is up for grabs. The CPU is
> completely free (architecturally) to pad components or rearrange things.
>
> It's not opaque (it's fully enumerated in CPUID), but it's far from something
> which is static or which we can realistically represent in a static structure.
Ok, agreed.
> > Can you set/get AVX-512 registers via ptrace? MPX state?
>
> The xsave buffer is just copied out to userspace with REGSET_XSTATE.
> Userspace
> needs to do the same song and dance with CPUID to parse it that the kernel
> does.
Indeed - I missed REGSET_XSTATE and its interaction with
update_regset_xstate_info().
Good - I have no other complaints.
> > This needs some (very minor) changes to kernel/fork.c to allow an
> > architecture
> > to determine the full task_struct size dynamically - but looks very doable
> > and
> > clean. Wanna try this, or should I?
>
> I think you already did this later in the thread.
Yeah, wanted to get a fix for the regression to Linus ASAP. If we go changing
core
code in kernel/fork.c we better have it in -rc3.
So right now I have these two applied:
0f6df268588f x86/fpu, sched: Dynamically allocate 'struct fpu'
218d096a24b4 x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT
and use it on x86
... do we need any of the other patches you sent to get working AVX512 support?
I think we should be fine, but I don't have the hardware.
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/
