[RFC PATCH v2 1/2] ARM: VFP: add support to sync the VFP state of the current thread

[Russell King - ARM Linux]

On Thu, Feb 04, 2010 at 11:38:02PM +0200, Imre Deak wrote:
> So far vfp_sync_state worked only for threads other than the current
> one. This worked for tracing other threads, but not for PTRACE_TRACEME.
> Syncing for the current thread will also be needed by an upcoming patch
> adding support for VFP context save / restore around signal handlers.
> 
> For SMP we need get_cpu now, since we have to protect the FPEXC
> register, other than this things remained the same for threads other
> than the current.

I don't think we should make this function any more complicated than it
already is.

For entering signal handlers, the situation is a lot more simple than
that found in vfp_sync_state() - since we know that we're always going
to be running the thread we're concerned with:

	- if VFP is enabled
		- use vfp_save_state() to save a copy of VFP state
		- disable VFP
	- if VFP is disabled
		- save a copy of ti->vfp_state

On signal return:

	- restore copy of ti->vfp_state
	- atomically (wrt preemption)
		- if last_VFP_context[cpu] is &ti->vfp_state
			- NULL out last_VFP_context[cpu]
		- disable VFP

There's no need to fiddle with ti->vfp_state.hard.cpu.

Note that saving the vfp_hard_struct to userspace is not on since it
then becomes a userspace API; it has to be translated into something
that we can keep better control over for userspace.  Moreover,
vfp_hard_struct contains state private to the kernel; allowing userspace
to have control over things like 'cpu' is a very bad idea.