Re: [PATCH v2] MIPS: Add basic R5900 support

[Paul Burton <paul.burton@imgtec.com>]

[-- Attachment #1: Type: text/plain, Size: 3408 bytes --]

Hi Maciej/Fredrik,

On Monday, 18 September 2017 10:05:56 PDT Maciej W. Rozycki wrote:
> Hi Fredrik,
> 
> > >  For the initial R5900 support I think there are two options here,
> > > 
> > > depending on what hardware supports:
> > > 
> > > 1. If (for binary compatibility reasons) 128-bit GPR support can somehow
> > > 
> > >    be disabled in hardware, by flipping a CP0 register bit or suchlike,
> > >    then I suggest doing that in the first stage.
> > 
> > Unfortunately I haven't found such a switch. There is also a set of
> > 128-bit
> > multimedia instructions to consider (GCC is perhaps unlikely to generate
> > those but assembly code is an option too).
> 
>  The usual minimal approach is to have compiler intrinsics implemented.
> 
> > > 2. Otherwise I think that the context initialisation/switch code has to
> > > be
> > > 
> > >    adjusted such that the upper GPR halves are set to a known state,
> > >    either zeroed or sign-extended from bit #63 (or #31 really, given the
> > >    initial 32-bit port only) according to hardware requirements, so as
> > >    to
> > >    make execution stable and prevent data from leaking between contexts.
> > > 
> > > Later on proper 128-bit support can be added, though for that to make
> > > sense you need to have compiler support too, which AFAICT is currently
> > > missing.  Myself I'd rather defer commenting on that further support
> > > until
> > > we get to it, although of course someone else might be willing to sketch
> > > an idea.
> > 
> > I have a working 32-bit kernel now, except that BusyBox randomly crashes
> > unless the kernel saves/restores 64-bit GPRs. The executables and
> > libraries
> > declare "ELF 32-bit LSB, MIPS, MIPS-III version 1" so in theory, I
> > suppose,
> > they ought to be 32-bit only. It is possible that the error lies in the
> > kernel handling of the GPRs but I have double-checked this in several
> > ways.
> 
>  Virtually all 64-bit MIPS processors have the CP0.Status.UX bit, which
> the Linux kernel keeps clear for o32 processes (CP0.Status.PX is currently
> unsupported and is kept clear as well), which means that an attempt to use
> any instruction that affects register bits beyond bit #31 will cause a
> Reserved Instruction exception, and in turn SIGILL being sent to the
> program.

This isn't actually true - we currently set ST0_UX unconditionally if the 
kernel is built with CONFIG_64BIT=y. It doesn't matter whether a user program 
is MIPS32 or MIPS64 code, it always runs with UX=1. We also always save all 64 
bits of each GPR - not just the least significant 32 bits when running an o32 
program.

This means 32 bit user code could try using MIPS64 instructions if it wanted 
to, it would just probably be a bad idea.

I think this would be nice to change such that we had UX=PX=0 for o32 
programs, UX=0 PX=1 for n32 programs, UX=1 PX=x for n64 programs, but right 
now we just have UX=1 always for 64 bit kernels.

> > Are there other Linux MIPS implementations that reset GPRs like this?
> 
>  No, because keeping CP0.Status.UX clear guarantees that only instructions
> which sign-extend register results from bit #31 can be used.

I agree that there are no other implementations with this issue - but the 
reason isn't the UX bit, it's that instructions sign extend into wider GPRs 
and the kernel always saves at least as much of a GPR as user code can access.

Thanks,
    Paul

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]