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

[Blue Swirl]

On Thu, Oct 4, 2012 at 6:38 AM, 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.
>
> 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.

My line of thought was that memory.c would not be tied to physical
addresses, but it would be more general. Then exec.c would specialize
the API to use target_phys_addr_t. Similarly PCI would specialize it
to pcibus_t, PIO to pio_addr_t and DMA to dma_addr_t.

>
> We were also planning to rename target_phys_addt_t to hw_addr.
>
> But both of those are for another patch.  For now, AddressSpace follows
> MemoryRegion, it's just a small abstraction on top.
>
>
> --
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.
>