Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

[Avi Kivity <avi@redhat.com>]

On 06/28/2011 01:28 PM, Jan Kiszka wrote:
> On 2011-06-28 12:03, Michael S. Tsirkin wrote:
> >>  +struct MemoryRegion {
> >>  +    /* All fields are private - violators will be prosecuted */
> >>  +    const MemoryRegionOps *ops;
> >>  +    MemoryRegion *parent;
> >>  +    uint64_t size;
> >>  +    target_phys_addr_t addr;
> >>  +    target_phys_addr_t offset;
> >>  +    ram_addr_t ram_addr;
> >>  +    bool has_ram_addr;
> >>  +    MemoryRegion *alias;
> >>  +    target_phys_addr_t alias_offset;
> >>  +    unsigned priority;
> >>  +    bool may_overlap;
> >>  +    QTAILQ_HEAD(subregions, MemoryRegion) subregions;
> >>  +    QTAILQ_ENTRY(MemoryRegion) subregions_link;
> >>  +    QTAILQ_HEAD(coalesced_ranges, CoalescedMemoryRange) coalesced;
> >>  +    const char *name;
> >
> >  I'm never completely sure whether these should be target addresses
> >  or bus addresses or just uint64_t.
> >  With pci on a 32 bit system you can stick a 64 bit address
> >  in a BAR and the result will be that it is never accessed
> >  from the CPU.
> >
>
> Memory regions are not bound to any current or future PCI
> specifications. Any fixed bit width would be wrong here, ie. size should
> rather be target_phys_addr_t.

The point is that different buses have different widths. 
target_phys_addr_t matches just one bus in the system.  It needs to be 
the maximum size of all buses present to be useful.

-- 
error compiling committee.c: too many arguments to function