From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Subject: Re: KVM call agenda for tuesday 31 Date: Mon, 05 Mar 2012 16:43:24 +0100 Message-ID: <4F54DF1C.605@suse.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Peter Maydell , i.mitsyanko@samsung.com, KVM devel mailing list , quintela@redhat.com, Developers qemu-devel , Dmitry Solodkiy , Anthony Liguori To: Avi Kivity Return-path: In-Reply-To: <4F54D769.5050000@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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 memor= y > 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 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"). i386 is 64-on-32 these days already; most of the embedded targets are still at most 32-bit though (xtensa, mblaze, ...). Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg