Re: [RFC PATCH 13/22] x86/fpu/xstate: Expand dynamic user state area on first use

[Bae, Chang Seok]

On Tue, 2020-11-03 at 13:41 -0800, Dave Hansen wrote:
> On 11/3/20 1:32 PM, Bae, Chang Seok wrote:
> > On Wed, 2020-10-14 at 09:29 -0700, Dave Hansen wrote:
> > > On 10/14/20 9:10 AM, Andy Lutomirski wrote:
> > > > I was suggesting something a little bit different.  We'd keep XMM,
> > > > YMM, ZMM, etc state stored exactly the way we do now and, for
> > > > AMX-using tasks, we would save the AMX state in an entirely
> > > > separate
> > > > buffer.  This way the pain of having a variable xstate layout is
> > > > confined just to AMX tasks.
> > > 
> > > OK, got it.
> > > 
> > > So, we'd either need a second set of XSAVE/XRSTORs, or "manual"
> > > copying
> > > of the registers out to memory.  We can preserve the modified
> > > optimization if we're careful about ordering, but only for *ONE* of
> > > the
> > > XSAVE buffers (if we use two).
> > 
> > For what is worth,
> > 
> > If using two buffers, the buffer for saving the tile data also needs
> > space
> > for the legacy states.
> 
> Just to be clear, you're talking about the 512-byte 'struct
> fxregs_state' which is the first member of 'struct xregs_state', right?

Yes.

> 
> > The AMX state is stored at the end of the XSAVE buffer (at least for
> > now).
> > So, the layout (in terms of offsets of non-AMX states) won't be changed
> > at
> > run-time.
> 
> I don't know what point you are trying to make here.

I was trying to clarify the concern that Andy had:

	"the pain of having a variable xstate layout"

Thanks,
Chang