From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4bhS-0002Im-9e for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:28:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4bhL-0000My-Qb for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:27:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4bhL-0000Mo-JV for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:27:47 -0500 Message-ID: <4F54F78C.9090709@redhat.com> Date: Mon, 05 Mar 2012 19:27:40 +0200 From: Avi Kivity MIME-Version: 1.0 References: <87ehuhrpel.fsf@elfo.elfo> <4F272A92.2010609@suse.de> <4F272D8C.8020608@codemonkey.ws> <4F27E98E.2080501@suse.de> <4F54C1C0.6030803@samsung.com> <4F54CA04.4070804@redhat.com> <4F54CFA3.6080400@samsung.com> <4F54D769.5050000@redhat.com> <4F54DF1C.605@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: i.mitsyanko@samsung.com, KVM devel mailing list , quintela@redhat.com, Developers qemu-devel , Dmitry Solodkiy , Anthony Liguori , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 03/05/2012 05:50 PM, Peter Maydell wrote: > On 5 March 2012 15:43, Andreas F=C3=A4rber wrote: > > Mid-term also depends on how me want to proceed with LPAE softmmu-wis= e > > (bump "arm" to 64-bit target_phys_addr_t, or do LPAE and AArch64 in a > > new "arm64"). > > For LPAE I would have thought we want to make "arm" go to a 64 bit > target_phys_addr_t, since that's exactly what it is: same old > ARM architecture with wider physical addresses :-) > > I notice that for the architectures we currently have that have > 32 and 64 bit versions we have separate {i386,x86_64}-softmmu, > {ppc,ppc64}-softmmu, {mips,mips64}-softmmu. What's the advantage > of separating out the 64 bit flavours that way rather than > having everything be a single binary? The registers are smaller; if target_ulong fits in a long then everything is faster. Although, you could pretend that target_ulong is 32-bit when in 32-bit mode, and zero the high half when switching modes, if the target allows it (I believe i386->x86_64 does, but 8086->i386 does not). --=20 error compiling committee.c: too many arguments to function