[RFC PATCH v2 2/2] ARM: VFP: preserve the HW context when calling signal handlers

[Imre Deak]

On Sat, Feb 06, 2010 at 01:12:03PM +0100, ext Russell King - ARM Linux wrote:
> On Sat, Feb 06, 2010 at 12:02:21PM +0200, Imre Deak wrote:
> > Right, don't know what made me think that this will work out. Perhaps
> > someone mentioning that the corresponding IOCTL is not in use yet. But that
> > was about half a year ago :)
> > 
> > I'll resend adding the new regs only to the signal frame, leaving the above
> > as is.
> 
> Second point on this.  Currently, the VFP context which we thought
> about saving onto the sigframe looks like this:
> 
> #if __LINUX_ARM_ARCH__ < 6
> /* For ARM pre-v6, we use fstmiax and fldmiax.  This adds one extra
>  * word after the registers, and a word of padding at the end for
>  * alignment.  */
> #define VFP_MAGIC               0x56465001
> #define VFP_STORAGE_SIZE        152
> #else
> #define VFP_MAGIC               0x56465002
> #define VFP_STORAGE_SIZE        144
> #endif
> 
> struct vfp_sigframe
> {
>         unsigned long           magic;
>         unsigned long           size;
>         union vfp_state         storage;
> };
> 
> This is horribly outdated.  We save:
> 
> - 16 or 32 64-bit registers depending on whether VFPv3
> - one 32-bit word of fpmx state if < ARMv6
> - one 32-bit word of fpexc
> - one 32-bit word of fpscr
> - one 32-bit word of fpinst
> - one 32-bit word of fpinst2
> - cpu if SMP
>
> This gives potentially the following options:
> 
> VFPv3	ARMv6	SMP
> n	n	n	16*8+5*4 = 148
> y	n	n	32*8+5*4 = 276
> n	y	n	16*8+4*4 = 144
> y	y	n	32*8+4*4 = 272
> n	n	y	16*8+6*4 = 152	*
> y	n	y	32*8+6*4 = 280	*
> n	y	y	16*8+5*4 = 148
> y	y	y	32*8+5*4 = 276

But the proposed patch didn't use union vfp_state, but a fixed size
struct for all 8 possibilities. Then the only drawback would be
undefined regs in certain cases, but the register positions would be
fixed. Also cpu is not part of the that struct.

> 
> The two marked with '*' are very unlikely to occur.
> 
> I think this technically comes under the heading of 'a disaster
> waiting to happen'.
> 
> We currently have no way to convey these possibilities to anything
> dealing with stack frames; certainly userspace applications which may
> decide to inspect the sigframe aren't going to deal with all these
> possibilities correctly - if we're lucky, they'll get one case right.
> 
> The stack frame should not care about whether we're running on SMP or
> not - and that rules out using vfp_hard_struct or vfp_state in the
> sigframe.  So we're into having a different structure.
> 
> Since sigframes are tagged, let's make use of that facility.  Let's
> save the 64-bit VFP registers - that way, the size of this structure
> defines how many registers there are.  num_regs = struct size / 8.
> 
> Save fpmx_state as a separate tagged entity if it's present.  (I doubt
> anyone has need to use this - it's just required to preserve VFP state.)
> 
> Then, save the remainder of the state information (fpexc, fpscr, fpinst,
> fpinst2 but _not_ cpu) as another separate tagged entity.
> 
> This means anyone who wants to inspect the VFP state has two or three
> tags to look for, but they're all well-defined, and are hopefully
> protected against the complexities of having to work out how to decode
> the current variable sized structure which we have at present.

Would this still give a benefit over the one fixed struct solution?

--Imre