From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4a8G-0000bT-1s for qemu-devel@nongnu.org; Mon, 05 Mar 2012 10:47:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4a8A-0007l4-QR for qemu-devel@nongnu.org; Mon, 05 Mar 2012 10:47:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4a8A-0007kW-I8 for qemu-devel@nongnu.org; Mon, 05 Mar 2012 10:47:22 -0500 Message-ID: <4F54E004.5040104@redhat.com> Date: Mon, 05 Mar 2012 17:47:16 +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: <4F54DF1C.605@suse.de> 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: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Peter Maydell , i.mitsyanko@samsung.com, KVM devel mailing list , quintela@redhat.com, Developers qemu-devel , Dmitry Solodkiy , Anthony Liguori 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, but = it > >>> does solve the problem. > >>> > >> > >> OK, but it will turn qemu from it's "long term path to suppress *all= * > >> target specific code" :) > >> > >=20 > > The other alternative is to s/target_phys_addr_t/uint64_t/ in the mem= ory > > API. I think 32-on-32 is quite rare these days, so it wouldn't be mu= ch > > of a performance issue. > > Maybe rare, but 32-bit ARM netbooks and tablets are gaining marketshare. > > Mid-term also depends on how me want to proceed with LPAE softmmu-wise > (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