Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 16 Dec 2018 13:50:13 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@linux-mips.org>
To:     Rich Felker <dalias@libc.org>
cc:     Andy Lutomirski <luto@kernel.org>,
        Linux MIPS Mailing List <linux-mips@linux-mips.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Paul Burton <paul.burton@imgtec.com>,
        David Daney <david.daney@cavium.com>,
        Ralf Baechle <ralf@linux-mips.org>,
        Paul Burton <paul.burton@mips.com>,
        James Hogan <jhogan@kernel.org>
Subject: Re: Fixing MIPS delay slot emulation weakness?
In-Reply-To: <20181216023259.GE23599@brightrain.aerifal.cx>
Message-ID: <alpine.LFD.2.21.1812160319120.11202@eddie.linux-mips.org>
References: <CALCETrWaWTupSp6V=XXhvExtFdS6ewx_0A7hiGfStqpeuqZn8g@mail.gmail.com> <20181215225009.GB23599@brightrain.aerifal.cx> <alpine.LFD.2.21.1812160054300.11202@eddie.linux-mips.org> <20181216023259.GE23599@brightrain.aerifal.cx>
User-Agent: Alpine 2.21 (LFD 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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