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

[Jan Kiszka]

On 2011-06-28 13:53, Avi Kivity wrote:
> 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.

Then we need a type for that. Or we need to demand that
target_phys_addr_t is defined large enough to support all buses that the
particular arch wants to address. Hardcoding 64 bit or anything is not
appropriate for a generic subsystem.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux