Re: [Qemu-devel] [RFC v1 19/22] memory: per-AddressSpace dispatch

[Peter Maydell]

On 4 October 2012 07:38, Avi Kivity <address@hidden> wrote:
> On 10/03/2012 10:24 PM, Blue Swirl wrote:
>> >
>> >  #else
>> > -void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
>> > -                            int len, int is_write)
>> > +
>> > +void address_space_rw(AddressSpace *as, target_phys_addr_t addr, uint8_t 
>> > *buf,
>> > +                      int len, bool is_write)
>>
>> I'd make address_space_* use uint64_t instead of target_phys_addr_t
>> for the address. It may actually be buggy for 32 bit
>> target_phys_addr_t  and 64 bit DMA addresses, if such architectures
>> exist. Maybe memory.c could be made target independent one day.

I thought target_phys_addr_t was supposed to be "widest necessary
address", so an architecture with 64 bit DMA addresses should be
implemented with 64 bit target_phys_addr_t...

> We can make target_phys_addr_t 64 bit unconditionally.  The fraction of
> deployments where both host and guest are 32 bits is dropping, and I
> doubt the performance drop is noticable.

I benchmarked it on ARM when I switched ARM to always 64 bit physaddrs;
it was just about measurable (maybe half a percent or so) but not
significant (we don't use this type in the fast path for memory
accesses, only in the slow/IO path).

I'd favour just moving everything to 64 bits (the remaining
32 bit targets are: cris, lm32, m68k, microblaze, or32, sh4, unicore32,
xtensa). However it does require some review of devices to check that
they're not using target_phys_addr_t when they meant uint32_t [eg
in registers for DMA devices] or relying on 32 bit wraparound.

-- PMM