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. Maciej
