Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.

[David Daney]

On 10/07/2014 11:44 AM, Andy Lutomirski wrote:
> 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.

Yes, gas for MIPS already has an instruction attribute for instructions 
that cannot be placed in delay slots.  It should be a fairly simple 
matter to extend this to instructions that cannot be emulated.

Thanks,
David Daney


> --Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/