From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ipstk-0007AW-Uh for qemu-devel@nongnu.org; Wed, 07 Nov 2007 16:57:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ipstk-00078d-3p for qemu-devel@nongnu.org; Wed, 07 Nov 2007 16:57:20 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ipstj-00077v-Gt for qemu-devel@nongnu.org; Wed, 07 Nov 2007 16:57:19 -0500 Received: from sp604005mt.neufgp.fr ([84.96.92.11] helo=smtp.Neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ipsti-0003L1-U8 for qemu-devel@nongnu.org; Wed, 07 Nov 2007 16:57:19 -0500 Received: from [84.102.211.92] by sp604005mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id <0JR5000Q4OXXYT64@sp604005mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Wed, 07 Nov 2007 22:56:21 +0100 (CET) Date: Wed, 07 Nov 2007 22:55:57 +0100 From: Fabrice Bellard Subject: Re: [Qemu-devel] Removal of some target CPU macros In-reply-to: <1194463004.855.41.camel@jma4.dev.netgem.com> Message-id: <4732346D.9060304@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <473204A2.3030208@bellard.org> <1194463004.855.41.camel@jma4.dev.netgem.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: l_indien@magic.fr, qemu-devel@nongnu.org Jocelyn Mayer wrote: > On Wed, 2007-11-07 at 19:32 +0100, Fabrice Bellard wrote: >> I noticed that some target CPUs macros have been added while they do not >> seem necessary. I don't like that because it introduces more #ifdefs >> which prevent making a version supporting simultaneously all the CPUs. >> >> In particular I saw the following: >> >> - TARGET_MIPSN32 : it is always combined with TARGET_MIPS64 in >> target-mips/. If its only usage is to select a different Linux ABI, then >> I suggest keeping TARGET_MIPS64 and using another define to choose that. >> >> - TARGET_PPC64H, TARGET_PPCEMB : I see no reason why they cannot be >> handled dynamically as the other PowerPC CPU types, provided that >> TARGET_PPC64 is defined. Is it the long term plan ? > > PowerPC embedded models are already available (should say should be as > none are actually implemented) when PPC64 is defined. But as those are > mainly PowerPC 32 with some extensions to manipulate the 64 bits GPR, > it's a great help if we can avoid doing all operations in 64 bits when > running on a 32 bits host (which would greatly decrease performances by > at least a factor of two, which is not acceptable). Then having a > specific 32 bits target using 64 bits register is very useful if one > want to use those features, but may be disabled if the host is 64 bits. > Note that most (all ?) embedded Freescale PowerPC microcontrollers > implement those extensions and that some ones are greatly interrested > with having an usable emulation avaible for those CPUs. OK for the speed gain, but such features make the code more difficult to test because there are a lot of possible combinations. I'd say the same about the fact that ppc_gpr_t can be 64 bit long on a pure 32 bit CPU. > The PowerPC 64 with hypervisor mode support could be removed only if: > - the fact of emulating hypervisor feature do not slowdown the emulator > (which I greatly doubt, but there may be great surprises) I greatly doubt too. > - someone provide an open-source hypervisor, compatible with the ones > used on real machines, that would allow at least Linux to be able to run > on a CPU with hypervisor mode available. Most 64 bits PowerPC, including > the 970 (ie G5) have the hypervisor mode support implemented. If the > hypervisor mode emulation is present, the OS won't be allowed to access > most SPR and some exceptions will need to have some specific handlers in > the hypervisor firmware. As I don't know such a software available, the > hypervisor mode can not be enabled for "standard" PowerPC 64 emulation; > or no-one will be able to actually use the emulator, except if using the > venerable but mostly undocumented (and nearly impossible to find on real > hardware) PowerPC 620 CPU. > Furthermore, running (or emulating) a SMP machine on a 64 bits PowerPC > with hypervisor features without hypervisor software is exactly > impossible. > Then I don't see how we can do without a separated target for hypervisor > features support. What you say does not justify the separate ppc64h target : it just implies that you need to add a separate machine to make hypervisor tests. Fabrice.