[PATCH resend 1/2] arm64: defer reloading a task's FPSIMD state to userland resume

[will.deacon@arm.com (Will Deacon)]

Hello,

On Tue, Feb 04, 2014 at 02:49:14PM +0000, Ard Biesheuvel wrote:
> On 3 February 2014 17:36, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Jan 31, 2014 at 10:13:15AM +0000, Ard Biesheuvel wrote:
> >> If a task gets scheduled out and back in again and nothing has touched
> >> its FPSIMD state in the mean time, there is really no reason to reload
> >> it from memory. Similarly, repeated calls to kernel_neon_begin() and
> >> kernel_neon_end() will preserve and restore the FPSIMD state every time.
> >>
> >> This patch defers the FPSIMD state restore to the last possible moment,
> >> i.e., right before the task re-enters userland. If a task does not enter
> >> userland at all (for any reason), the existing FPSIMD state is preserved
> >> and may be reused by the owning task if it gets scheduled in again on the
> >> same CPU.
> >
> > The one situation I'm unsure of here is how you deal with the saved fpsimd
> > state potentially being updated by a signal handler or a debugger. In this
> > case, we probably need to set _TIF_FOREIGN_FPSTATE to force a reload, or are
> > you handling this some other way?
> >
> 
> If I am reading the code correctly, the signal handler is entered
> using the normal userland resume path, so I don't think it requires
> special treatment.

It was the exiting of the signal handler that I was worried about, where it
may have modified the interrupted programs fpsimd state on the stack.

> For the ptrace() case, it should suffice to set the 'last_cpu' field
> to (u32)-1 to indicate that the FPSIMD context should be reloaded from
> memory regardless of which CPU the debuggee is restarted on.

Something like that sounds right, but it needs adding/testing.

Will