qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API
Date: Tue, 28 Jun 2011 14:53:22 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]