On 12 January 2012 20:32, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 01/12/2012 02:06 PM, Peter Maydell wrote: >> >> On 12 January 2012 17:54, Anthony Liguori<aligu...@us.ibm.com> wrote: >>> >>> This simplifies the build quite a bit and improves the builds performance >>> by >>> not rebuilding many objects twice. >>> >>> There were a surprising number of places that had assumed wrong things >>> about the >>> size of target_phys_addr_t including that it was fixed at 32-bit and that >>> it >>> was identical to target_ulong. >> >> >> Up until now, in a lot of CPU-specific code it has been perfectly >> reasonable to assume target_phys_addr_t was 32 bits. > > > No, that's never been a reasonable thing to assume.
Having target_phys_addr_t be possibly larger than the guest physical address type is exactly the thing this patch is changing... >> I don't like this. When target_phys_addr_t was 32 bits, then >> using TARGET_FMT_plx to print offsets into devices isn't >> too unreasonable as you only get 8 hex digits. If you expand >> to 64 bits then suddenly all these offsets which are actually >> really typically small numbers get printed as 16 hex digits, >> which I think looks bad. > Then cast it to a 32-bit number and print it however you like. You're the one changing what was previously a known-to-be-32-bit type to one that's much bigger, you get to fix the printing issues. -- PMM
