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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
