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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
