Subject: Re: [PATCH] MIPS: Add emulation for fpureg-mem unaligned access

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 11 Jul 2012 01:05:04 +0100 (BST)

On Wed, 20 Jun 2012, Lluís Batlle i Rossell wrote:

> > > Well, I think I take my words back. Handling the ldc1/sdc1 cases in MIPS32 is
> > > tricker than I thought first, because I can't use ldl/ldr or sdl/sdr there.
> > > Given my ability with mips assembly, I leave the patch as is.

 I suggest that for 32-bit kernels you simply reuse the existing snippets 
from that function and handle ldc1/sdc1 with a pair of lwl/ldr or swl/swr 
pairs ordered as appropriate for the endianness selected -- that should be 
fairly easy.

 Also regardless of that, please make sure that your code handles the two 
possible settings of CP0 Status register's bit FR correctly, as the 32-bit 
halves of floating-point data are distributed differently across 
floating-point registers based on this bit's setting (check if an o32 and 
an n64 or n32 program gets these values right).

> > why is there a reason for this ? Unaligned FPU access shouts to me simply
> > broken code, go fix that. But maybe I'm wrong ?

 Since we're emulating these accesses at all I concur Lluís we should stay 
consistent across the whole instruction set.

> Right, the patch allows broken code to run further, instead of fail straight.
> The crash can be still achieved disabling the emulation of unaligned accesses
> completely, through debugfs, for example.

 sysmips(MIPS_FIXADE, 0) is another way.

> As Jonas reported, I think that maybe I should rework the patch for it to emit
> sigbus instead of sigill on ldc1,ldc1 for mips32. Do I understand it right?

 Have you checked your code against a non-FPU processor (or with the 
"nofpu" kernel option) too?

  Maciej

---

From: Lluís Batlle i Rossell <[email-masked]>
Date: Mon, 30 Jul 2012 21:47:54 +0200

Hello Maciej,

> pairs ordered as appropriate for the endianness selected -- that should be 

Hm I still don't understand well enough how to do that. Would I need to get some
aligned memory (a stack automatic variable for example), copy the double word
there with proper endianness, and then call again ldc1? (similar for sdc1)

> an n64 or n32 program gets these values right).

Hm I'm failing to find in the mips-iv.pdf how to check that FR bit, although I
see it mentioned there. Sorry.

> "nofpu" kernel option) too?

No. Would in that case the processor have the fpu disabled? I understand that
the code path is called only in a particular case of 'unaligned access'
exception.

Thank you for your comments.

Regards,
Lluís.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 31 Jul 2012 00:56:54 +0100 (BST)

Hi Lluís

> there with proper endianness, and then call again ldc1? (similar for sdc1)

 No need to copy anything to scratch space, you'd just handle the thing 
piecewise in 32-bit chunks, transferring one FPR first, followed with the 
other one -- this is exactly what LDC1/SDC1 logically do in the 32-bit 
mode anyway.  Of course FPR indices are swapped between endiannesses (or 
data in memory is swapped -- depending on how you look at it).

> see it mentioned there. Sorry.

 That'll be set in Linux's task status structure somewhere as the 
floating-point model is implied by the ABI (FR is clear for o32 and set 
for n32/n64) -- no need to poke at hardware.  Have a look at FP context 
switching code -- it has to take similar measures.  There may be some code 
that checks that in the FPU emulator as well.

> the code path is called only in a particular case of 'unaligned access'

 It may well possibly be, I'm not sure offhand, but unaligned access 
emulation just has to work the same for floating-point transfers 
regardless of whether the FPU has been enabled or is fully emulated.  
This just have to be verified.

 The MIPS/Linux user ABI specifies the presence of an FPU unconditionally 
and a missing or disabled unit is automatically emulated in software 
transparently (except for the performance loss of course).

  Maciej

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 31 Jul 2012 15:40:01 +0200

On Sat, Jun 16, 2012 at 12:22:53AM +0200, Lluis Batlle i Rossell wrote:

> Reusing most of the code from lw,ld,sw,sd emulation,
> I add the emulation for lwc1,ldc1,swc1,sdc1.
> 
> This avoids the direct SIGBUS sent to userspace processes that have
> misaligned memory accesses.
> 
> I've tested the change in Loongson2F, with an own test program, and
> WebKit 1.4.0, as both were killed by sigbus without this patch.

A misaligned FPU access is a strong indication for broken, non-portable
software.  which means you're likely trying to fix the wrong issue.  It's
quite intentional that there is no unaligned handling for the FPU in the
kernel - and afaics there isn't for any other MIPS UNIX.

  Ralf

---

From: Lluís Batlle i Rossell <[email-masked]>
Date: Tue, 31 Jul 2012 16:07:23 +0200

> kernel - and afaics there isn't for any other MIPS UNIX.

Ah, I had no idea it was intentional. 

Maybe there could be a cleaner declaration of that intention, though. The only
code there was "I herewith declare: this does not happen.  So send SIGBUS."

Thank you,
Lluís.

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 31 Jul 2012 17:10:05 +0200

> code there was "I herewith declare: this does not happen.  So send SIGBUS."

To give you an idea, the emulation is on the order of a 1000 times slower
than the processing a properly aligned load in hardware.  And even where
hardware does unaligned handling such as on x86 there still is a performance
penalty though that would far less severe.

So given that proper alignment is always the right thing.  There are very
few cases were handling misalignment in software is justified, for example
the IP stack.  Even the checks if a packet is misaligned would cause a
performance penalty and it's (assuming sane networking hardware) a very
rare event.

lwl/lwr in the IP stack would be a bad tradeoff.  It's faster than the
unaligned exception handler but would slow down processing of every
correctly aligned packet.  So lwl/lwr are only a good choice where a high
fraction of misaligned packets is expected.

  Ralf