On 07/17/2015 12:32 PM, Ingo Molnar wrote:
> ... 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.
I don't think so, but I'll go verify by actually running with those
x86/fpu commits.
--
To unsubscribe from th
* Dave Hansen 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
> >> no
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
* Ingo Molnar wrote:
> > The least we can do is detect that the kernel undersized the buffer and
> > disable support for the features that do not fit. A very lightly tested
> > patch
> > to do that is attached. I'm not super eager to put that in to an -rc2
> > kernel
> > though.
>
> Ok,
* Dave Hansen wrote:
> On 07/15/2015 04:07 AM, Ingo Molnar wrote:
> > * Dave Hansen wrote:
> >>> /*
> >>> - * Setup init_xstate_buf to represent the init state of
> >>> + * Setup init_xstate_ctx to represent the init state of
> >>>* all the features managed by the xsave
> >>>*/
> >>
On Wed, Jul 15, 2015 at 5:34 PM, Dave Hansen
wrote:
>
> I understand why you were misled by it, but the old "xsave_hdr_struct"
> was wrong. Fenghua even posted patches to remove it before the FPU
> rework (you were cc'd):
>
> https://lkml.org/lkml/2015/4/18/164
Oh, and that patch looks l
On Wed, Jul 15, 2015 at 5:34 PM, Dave Hansen
wrote:
>
> The old code sized the buffer in a fully architectural way and it
> worked. The CPU *tells* you how much memory the 'xsave' instruction is
> going to scribble on. The new code just merrily calls it and let it
> scribble away. This is as cl
On 07/15/2015 04:07 AM, Ingo Molnar wrote:
> * Dave Hansen wrote:
>>> /*
>>> -* Setup init_xstate_buf to represent the init state of
>>> +* Setup init_xstate_ctx to represent the init state of
>>> * all the features managed by the xsave
>>> */
>>> - init_xstate_buf = alloc_
* Dave Hansen wrote:
> On 05/05/2015 10:49 AM, Ingo Molnar wrote:
> > @@ -574,12 +573,10 @@ static void setup_init_fpu_buf(void)
> > on_boot_cpu = 0;
> >
> > /*
> > -* Setup init_xstate_buf to represent the init state of
> > +* Setup init_xstate_ctx to represent the init state
Actually we could statically associate a biggerbuffer based on the XCR0
features we support. That would preclude dynamic enabling and really just adds
complexity for no good reason.
On July 14, 2015 12:46:17 PM PDT, Dave Hansen
wrote:
>On 05/05/2015 10:49 AM, Ingo Molnar wrote:
>> @@ -574,12
On 05/05/2015 10:49 AM, Ingo Molnar wrote:
> @@ -574,12 +573,10 @@ static void setup_init_fpu_buf(void)
> on_boot_cpu = 0;
>
> /*
> - * Setup init_xstate_buf to represent the init state of
> + * Setup init_xstate_ctx to represent the init state of
>* all the features
11 matches
Mail list logo
