[lkml]   [2016]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

* Andy Lutomirski <> wrote:

> > Running the task in user space, would have to ensure
> > "registers valid" is true, and make "memory valid"
> > false, because userspace could write to the registers.
> >
> > Doing a ptrace fpstate_read would make "memory valid"
> > true, but does not need to invalidate "registers valid".
> >
> > Doing a ptrace fpstate_write would make "memory valid"
> > true, but would invalidate "registers valid".
> >
> > Context switching away from a task would make "memory
> > valid" true, by virtue of copying the fpstate to
> > memory.
> >
> > Ingo, would you have any objection to patches tracking
> > the validity of both register and memory states
> > independently?

I'd like to reserve judgement - but tentatively I see no red flags
at the moment, but in any case I'd like to start with:

> >
> > We can get rid of fpu.counter, since nobody uses it
> > any more.
> We should definitely do this.
> Maybe getting in some cleanups first (my lazy fpu deletion,
> fpu.counter removal, etc) first is the way to go.

Could you guys please submit all pending FPU bits that aren't new
functionality to -tip? I'll remove lazy FPU handling if you don't
beat me to it.

Plus after lazy FPU removal we should take another good look and
make the FPU state machine even more obvious and self-documenting.

Upstream merge commit 597f03f9d133 would be a good base.



 \ /
  Last update: 2016-10-04 08:36    [W:0.111 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site