On Tue, Oct 7, 2014 at 11:32 AM, Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx> wrote: > Well, I am not a subscriber to mail-list, so I read it the first time and > some notes: > > > 3) The signal happened during execution of emulated instruction - signals > are under control of kernel and we can easily delay a signal during > execution of emulated instruction until return from do_dsemulret. It is not > a big deal - nor code, nor performance. Thank you for good point. If you go down this particular rabbit hole, you will never come back out. What happens if one of those out-of-line instructions causes a synchronous trap? What if SIGSTOP arrives before ret? What if another thread removes the magic ret sequence? > > 4) The voice for doing any instruction emulation in kernel - it is not a > MIPS business model to force customer to put details of all Coprocessor 2 > instructions public. We provide an interface and the rest is a customer > business. Besides that it is really painful to make a differentiation > between Cavium Octeon and some another CPU instructions with the same > opcode. On other side, leaving emulation of their instructions to them is > not a wise after having some good way doing that multiple years. IMO this is all backwards. If MIPS customers put proprietary instructions into their ISA, they leave out the FPU, and they put a proprietary insn in a branch delay slot, then I think that they deserve a fatal signal. There's a really easy solution for new systems: fix the toolchain. Teach the assembler to disallow any proprietary instructions in an FP branch delay slot. --Andy
