qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] KVM call agenda for tuesday 31


From: Avi Kivity
Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31
Date: Mon, 05 Mar 2012 17:47:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

On 03/05/2012 05:43 PM, Andreas Färber 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" :)
> >>
> > 
> > The other alternative is to s/target_phys_addr_t/uint64_t/ in the memory
> > 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").

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]