lkml.org 
[lkml]   [2015]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH 198/208] x86/fpu: Document the various fpregs state formats
Date
> From: Dave Hansen [mailto:dave.hansen@linux.intel.com]
> Sent: Tuesday, May 05, 2015 12:52 PM
> To: Ingo Molnar; linux-kernel@vger.kernel.org
> Cc: Andy Lutomirski; Borislav Petkov; Yu, Fenghua; H. Peter Anvin; Linus
> Torvalds; Oleg Nesterov; Thomas Gleixner
> Subject: Re: [PATCH 198/208] x86/fpu: Document the various fpregs state
> formats
>
> On 05/05/2015 10:58 AM, Ingo Molnar wrote:
> > +/*
> > + * This is our most modern FPU state format, as saved by the XSAVE
> > + * and restored by the XRSTOR instructions.
> > + *
> > + * It consists of a legacy fxregs portion, an xstate header and
> > + * subsequent fixed size areas as defined by the xstate header.
> > + * Not all CPUs support all the extensions.
> > + */
> > struct xregs_state {
> > struct fxregs_state i387;
> > struct xstate_header header;
> > @@ -150,6 +169,13 @@ struct xregs_state {
> > /* New processor state extensions will go here. */ } __attribute__
> > ((packed, aligned (64)));
>
> Fenghua has a "fix" for this, but I think this misses a pretty big point.

Here is the "fix" patch Dave referred to: https://lkml.org/lkml/2015/4/22/9

>
> This structure includes only the "legacy" state, followed by the header.
> The remainder of the layout here is enumerated in CPUID leaves and can not
> be laid out in a structure because we do not know what it looks like until we
> run CPUID.
>
> There is logically a variable length array at the end of this sucker.


\
 
 \ /
  Last update: 2015-05-06 01:21    [W:0.176 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site