From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLXKu-0000e6-Ew for qemu-devel@nongnu.org; Wed, 11 Feb 2015 08:28:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLXKq-0007hx-DT for qemu-devel@nongnu.org; Wed, 11 Feb 2015 08:28:12 -0500 Received: from eddie.linux-mips.org ([148.251.95.138]:56198 helo=cvs.linux-mips.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLXKq-0007hs-3p for qemu-devel@nongnu.org; Wed, 11 Feb 2015 08:28:08 -0500 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S27013236AbbBKN2GwLmw4 convert rfc822-to-quoted-printable (ORCPT ); Wed, 11 Feb 2015 14:28:06 +0100 Date: Wed, 11 Feb 2015 13:28:06 +0000 (GMT) Sender: "Maciej W. Rozycki" From: "Maciej W. Rozycki" In-Reply-To: Message-ID: References: <54D89A42.2010004@imgtec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-7 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all required configurations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Leon Alrae , QEMU Developers , Aurelien Jarno , Richard Henderson On Mon, 9 Feb 2015, Peter Maydell wrote: > >> I'm not sure if it's a good idea to change the meaning of linux-us= er > >> qemu-mips64 and qemu-mips64el, this will cause unnecessary confusi= on in > >> my opinion. I think we=A2d be better off leaving it consistent acr= oss 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 wha= t's > > already there. >=20 > I think "don't break executable names that are already present" > is a hard requirement. These get baked into binfmt-misc configuration= s > 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 pe= rhaps > > 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. WDY= T? >=20 > So which of these four does the current "mips64/mips64el" correspond > to? That's the third in the list, right? And the current mipsn32/mips= n32el > 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 ad= ded=20 (i.e. in an incremental manner and not really architected) results in w= hat=20 looks like a random selection of arbitrary names that are all but obvio= us=20 to the user. Only "mipsn32/mipsn32el" have any notion of the selected ABI in the na= me,=20 but then they lack any emphasis that this is a 64-bit ABI. The remaini= ng=20 two pairs, "mips/mipsel" and "mips64/mips64el", respectively refer to=20 architecture names rather than a particular ABI, in the traditional sen= se=20 (such as used by the GNU config.guess/config.sub scripts or reported by= =20 uname(2) on Linux) merely meaning 32-bit or 64-bit MIPS processors with= out=20 any further implication as to the ABI (of course in the context of Linu= x a=20 32-bit CPU cannot support anything but o32, but that's an indirect=20 implication only). Of course ideally we'd have a single executable supporting all the ABI= s=20 and selecting the right one on the fly. Or maybe two, to account for t= he=20 two endiannesses, although being able to switch that at the run time so= =20 that a single "interpreter" handles all MIPS executables would be a gre= at=20 feature too. But that's a differenr matter, and if such a unified=20 configuration is ever implemented, then we can simply alias all the=20 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= =20 assumption that we want to be able to reproduce a simulated user-mode=20 environment just as it would look like on actual hardware. This could = be=20 for any reason, I think performance in the first place as QEMU run on a= =20 decent host machine can often be much, much faster than actual target=20 hardware, and then the inability to reproduce target hardware beyond th= e=20 CPU or to run a real Linux kernel on such hardware in the system emulat= ion=20 mode. So referring to the MIPS target -- as one I'm the most familiar with -= -=20 we have a choice of 3 Linux user ABIs in both endiannesses each. And t= hen=20 we have a bunch of processors we already simulate or the simulation of=20 which can be added, often in a straightforward manner as lots of=20 documentation is available. And now I expect to be able to pick any=20 compatible CPU-ABI pair and simulate it. It should correctly simulate = all=20 the instructions CPU implements and correctly trap with SIGILL on all t= he=20 instructions CPU does not implement. It can then be used for example f= or=20 toolchain correctness validation. I don't know exactly how ARM architecture subsetting has been defined,= =20 but with the MIPS architecture it has been the case that 32-bit additio= ns=20 were added to a 64-bit architecture. Specifically the MIPS IV=20 architecture, a 64-bit one, added several features to the MIPS III=20 architecture, also a 64-bit one. These were conditional move operation= s,=20 extra floating-point condition bits, the indexed addressing mode for=20 floating-point load/store instructions and cache prefetch instructions.= =20 These were naturally available for 32-bit aka o32 programs run in the=20 32-bit compatibility user mode. This is unlike any 64-bit instructions= as=20 these are not allowed in the 32-bit compatibility user mode and trap wi= th=20 a Reserved Instruction exception as if they were unimplemented. More recently there have been vendor-specific architecture extensions=20 added to 64-bit processors, that also affect o32 executable environment= =2E =20 At least one of them -- the Lemote Loongson-2E processor -- has been=20 publicly documented and we already have support for its extensions in=20 place. Other extensions can follow if the respective vendors decide to= =20 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 ha= ve=20 64-bit processors enabled for o32 programs. And I think for performanc= e=20 reasons it makes sense to keep a configuration with only 32-bit process= ors=20 enabled as well. Does it make the design principles I have in mind any clearer to you? Maciej