Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all required configurations

[Maciej W. Rozycki]

On Mon, 9 Feb 2015, Peter Maydell wrote:

> >> I'm not sure if it's a good idea to change the meaning of linux-user
> >> qemu-mips64 and qemu-mips64el, this will cause unnecessary confusion in
> >> my opinion. I think we’d be better off leaving it consistent across QEMU
> >> versions.
> >
> >  Well, this is an example how the names could have been consistent from
> > the beginning, and I actually agree we need to take a notion of what's
> > already there.
> 
> I think "don't break executable names that are already present"
> is a hard requirement. These get baked into binfmt-misc configurations
> and effectively become part of QEMU's ABI to users.

 Acknowledged, I do recognise and accept the requirement.

> > So alternatively these could be called `mips64o32' and
> > `mips64o32el' though I find these names somewhat ugly.  Although perhaps
> > not anymore if we kept what we have now for backwards compatibility and
> > added a set of uniform target names like this:
> >
> > - mips32o32|mips32o32el (or maybe just mipso32|mipso32el),
> >
> > - mips64o32|mips64o32el,
> >
> > - mips64n64|mips64n64el,
> >
> > - mips64n32|mips64n32el.
> >
> > Or maybe just the three latters, leaving mips|mipsel as it is.  WDYT?
> 
> So which of these four does the current "mips64/mips64el" correspond
> to? That's the third in the list, right? And the current mipsn32/mipsn32el
> is the fourth?

 Correct.

> So this is adding alias names for our existing targets
> and creating a new one? I think I'd just leave the current names and
> define new target names where we need to.

 What I have been a bit concerned of is how the way these names were added 
(i.e. in an incremental manner and not really architected) results in what 
looks like a random selection of arbitrary names that are all but obvious 
to the user.

 Only "mipsn32/mipsn32el" have any notion of the selected ABI in the name, 
but then they lack any emphasis that this is a 64-bit ABI.  The remaining 
two pairs, "mips/mipsel" and "mips64/mips64el", respectively refer to 
architecture names rather than a particular ABI, in the traditional sense 
(such as used by the GNU config.guess/config.sub scripts or reported by 
uname(2) on Linux) merely meaning 32-bit or 64-bit MIPS processors without 
any further implication as to the ABI (of course in the context of Linux a 
32-bit CPU cannot support anything but o32, but that's an indirect 
implication only).

 Of course ideally we'd have a single executable supporting all the ABIs 
and selecting the right one on the fly.  Or maybe two, to account for the 
two endiannesses, although being able to switch that at the run time so 
that a single "interpreter" handles all MIPS executables would be a great 
feature too.  But that's a differenr matter, and if such a unified 
configuration is ever implemented, then we can simply alias all the 
individual configuration names invented until then to one another.

> If we could figure out and write down what the design principle
> is for which targets to create to handle different ABIs in linux-user
> that would be handy, because at some point I need to think about
> this to handle the equivalent situation for ARM (a probable
> upcoming ILP32 ABI, and what to do about running 32-bit code on
> 64-bit CPU definitions)...

 I think this is as simple as following what hardware offers, under the 
assumption that we want to be able to reproduce a simulated user-mode 
environment just as it would look like on actual hardware.  This could be 
for any reason, I think performance in the first place as QEMU run on a 
decent host machine can often be much, much faster than actual target 
hardware, and then the inability to reproduce target hardware beyond the 
CPU or to run a real Linux kernel on such hardware in the system emulation 
mode.

 So referring to the MIPS target -- as one I'm the most familiar with -- 
we have a choice of 3 Linux user ABIs in both endiannesses each.  And then 
we have a bunch of processors we already simulate or the simulation of 
which can be added, often in a straightforward manner as lots of 
documentation is available.  And now I expect to be able to pick any 
compatible CPU-ABI pair and simulate it.  It should correctly simulate all 
the instructions CPU implements and correctly trap with SIGILL on all the 
instructions CPU does not implement.  It can then be used for example for 
toolchain correctness validation.

 I don't know exactly how ARM architecture subsetting has been defined, 
but with the MIPS architecture it has been the case that 32-bit additions 
were added to a 64-bit architecture.  Specifically the MIPS IV 
architecture, a 64-bit one, added several features to the MIPS III 
architecture, also a 64-bit one.  These were conditional move operations, 
extra floating-point condition bits, the indexed addressing mode for 
floating-point load/store instructions and cache prefetch instructions. 
These were naturally available for 32-bit aka o32 programs run in the 
32-bit compatibility user mode.  This is unlike any 64-bit instructions as 
these are not allowed in the 32-bit compatibility user mode and trap with 
a Reserved Instruction exception as if they were unimplemented.

 More recently there have been vendor-specific architecture extensions 
added to 64-bit processors, that also affect o32 executable environment.  
At least one of them -- the Lemote Loongson-2E processor -- has been 
publicly documented and we already have support for its extensions in 
place.  Other extensions can follow if the respective vendors decide to 
either contribute their implementation or at least publish the specs.

 So I think as far as the MIPS target is concerned it makes sense to have 
64-bit processors enabled for o32 programs.  And I think for performance 
reasons it makes sense to keep a configuration with only 32-bit processors 
enabled as well.

 Does it make the design principles I have in mind any clearer to you?

  Maciej