From mboxrd@z Thu Jan 1 00:00:00 1970 From: imre.deak@nokia.com (Imre Deak) Date: Sat, 6 Feb 2010 18:23:29 +0200 Subject: [RFC PATCH v2 2/2] ARM: VFP: preserve the HW context when calling signal handlers In-Reply-To: <20100206121203.GA17672@n2100.arm.linux.org.uk> References: <20100206092544.GB1923@n2100.arm.linux.org.uk> <20100206100221.GA1109@localhost> <20100206121203.GA17672@n2100.arm.linux.org.uk> Message-ID: <20100206162329.GD1109@localhost> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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