On 03/05/2012 09:10 AM, Avi Kivity wrote:
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.
I think this makes sense independent of other discussions regarding fixing
target_phys_addr_t size.
Hardware addresses should be independent of the target. If we wanted to use a
hw_addr_t that would be okay too.
Regards,
Anthony Liguori
--
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
