Re: Fixing MIPS delay slot emulation weakness?

[Rich Felker]

On Sun, Dec 16, 2018 at 01:50:13PM +0000, Maciej W. Rozycki wrote:
> On Sat, 15 Dec 2018, Rich Felker wrote:
> 
> > >  I think "trivial" is an understatement, you at least need to decode the 
> > > delay-slot instruction enough to tell privileged and user instructions 
> > > apart and send SIGILL where appropriate.  Some user instructions send 
> > > exceptions too and you need to handle them accordingly.
> > 
> > I meant simply that making them safe is trivial if they're not
> > accessing memory, only modifying the regisster file in the signal
> > context. Not that emulating them is trivial.
> 
>  OK, fair enough.
> 
> > On the other hand it might be cleaner, safer, and easier to simply
> > write a full mips ISA emulator, put it in the vdso, and have the
> > kernel immediately return-to-userspace on hitting floating point
> > instructions and let the emulator code there take care of it all and
> > then return to the normal flow of execution.
> 
>  The problem is matching hardware being run on and then maintaining that 
> stuff.  I'd call that a maintenance nightmare, I'm afraid.  See what pain 
> we have to go through already to get FPU emulation right, and there's much 
> less variation.
> 
> > >  OTOH, for things like ADDIUPC you need to interpret the instruction 
> > > anyway, as the value of the PC used for calculation will be wrong except 
> > > in the original location.
> > 
> > Indeed. Assuming arbitrary ISA extensions including stuff that does
> > PC-relative arithmetic, there's no way to execute it out-of-place
> > without knowing how to interpret it.
> 
>  Well, ADDIUPC is a standard microMIPS instruction.  Then R6 has more 
> stuff like that in the regular MIPS instruction set, e.g. AUIPC, LWPC.
> 
> > >  What about all the odd and especially vendor-specific load/store 
> > > instructions like ASET, SAA or SWAPW?  Would we need to have all the 
> > > possible encodings provided in the VDSO?
> > 
> > Can all kinds of weird stuff like this go in delay slots? I'm more
> > familiar with SH delay slots where lots of instructions are
> > slot-illegal. If so perhaps the full-emulator-in-userspace approach is
> > better.
> 
>  I've double-checked and ASET is actually not allowed in a delay slot, 
> because it uses multiple bus cycles for data access.  This is also why 
> LWP, LWM, etc. are not allowed either.  Also control transfer instructions 
> are not allowed (unlike with SPARC), such as branches, ERET or YIELD (not 
> that the two latter instructions matter for us).  Most of stuff is allowed 
> in delay slots though.
> 
>  It doesn't help that information about that is scattered across many 
> documents.  You can check for the NODS flag in the opcodes library from 
> binutils though, which is almost 100% accurate, except for the SYNC 
> instructions, for semantic reasons (i.e. they are allowed, but we don't 
> want GAS to reorder them).  Most of the disallowed stuff is in the 
> microMIPS instruction set, due to encodings that execute as hardware 
> macros.

I think it suffices to emulate what compilers generate in delay slots,
which should be fairly minimal and stable. At the very least we could
enumerate everything GCC and LLVM already emit there, and get them to
upstream a policy of not adding new insns as fpu-delay-slot-allowed.
If someone is writing asm by hand to do ridiculous things in the delay
slot with random ISA extensions, they shouldn't expect it to work.

Rich