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 17:47:16 +0200
Message-ID: <4F54E004.5040104@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>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: i.mitsyanko@samsung.com, Peter Maydell <peter.maydell@linaro.org>,
	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: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:61962 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751108Ab2CEPr2 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 5 Mar 2012 10:47:28 -0500
In-Reply-To: <4F54DF1C.605@suse.de>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 03/05/2012 05:43 PM, Andreas F=C3=A4rber wrote:
> Am 05.03.2012 16:10, schrieb Avi Kivity:
> > On 03/05/2012 04:37 PM, Igor Mitsyanko wrote:
> >>> Well, can't you make sd.c target dependent?  It's not so nice, bu=
t it
> >>> does solve the problem.
> >>>
> >>
> >> OK, but it will turn qemu from it's "long term path to suppress *a=
ll*
> >> target specific code" :)
> >>
> >=20
> > The other alternative is to s/target_phys_addr_t/uint64_t/ in the m=
emory
> > API.  I think 32-on-32 is quite rare these days, so it wouldn't be =
much
> > of a performance issue.
>
> Maybe rare, but 32-bit ARM netbooks and tablets are gaining marketsha=
re.
>
> 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").

I was counting on LPAE to make 32-on-32 rare.

> i386 is 64-on-32 these days already; most of the embedded targets are
> still at most 32-bit though (xtensa, mblaze, ...).

These would be 32-on-64, since the host would usually be x86.  I guess
it would be even more true when the w64 port is complete.

--=20
error compiling committee.c: too many arguments to function