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




Reply via email to