From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31
Date: Mon, 05 Mar 2012 19:27:40 +0200
Message-ID: <4F54F78C.9090709@redhat.com>
References: <87ehuhrpel.fsf@elfo.elfo> <4F272A92.2010609@suse.de> <4F272D8C.8020608@codemonkey.ws> <4F27E98E.2080501@suse.de> <CAFEAcA_u2qTgnaNMvVRn_K+3SrbaTLMUs4NH654wgQGAnFGxTg@mail.gmail.com> <CAFEAcA86m4wKbDFQk=Qmn3mUDDuPod9q15HgGBgPk0sFkC2sag@mail.gmail.com> <4F54C1C0.6030803@samsung.com> <4F54CA04.4070804@redhat.com> <4F54CFA3.6080400@samsung.com> <4F54D769.5050000@redhat.com> <4F54DF1C.605@suse.de> <CAFEAcA_oEp7B3V-_fzPz9JO+ZK6w1UsXmgsP7R9w0BeHrFCpsQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>,
	i.mitsyanko@samsung.com, Anthony Liguori <anthony@codemonkey.ws>,
	quintela@redhat.com, Developers qemu-devel <qemu-devel@nongnu.org>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	Dmitry Solodkiy <d.solodkiy@samsung.com>
To: Peter Maydell <peter.maydell@linaro.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:53205 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755082Ab2CER1w (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 5 Mar 2012 12:27:52 -0500
In-Reply-To: <CAFEAcA_oEp7B3V-_fzPz9JO+ZK6w1UsXmgsP7R9w0BeHrFCpsQ@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 03/05/2012 05:50 PM, Peter Maydell wrote:
> On 5 March 2012 15:43, Andreas F=C3=A4rber <afaerber@suse.de> wrote:
> > Mid-term also depends on how me want to proceed with LPAE softmmu-w=
ise
> > (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