qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v1] Add declarations for hierarchical memory regio


From: Blue Swirl
Subject: Re: [Qemu-devel] [RFC v1] Add declarations for hierarchical memory region API
Date: Sun, 22 May 2011 12:32:33 +0300

On Sun, May 22, 2011 at 9:45 AM, Avi Kivity <address@hidden> wrote:
> On 05/20/2011 08:59 PM, Blue Swirl wrote:
>>
>> On Thu, May 19, 2011 at 5:12 PM, Avi Kivity<address@hidden>  wrote:
>> >  The memory API separates the attributes of a memory region (its size,
>> > how
>> >  reads or writes are handled, dirty logging, and coalescing) from where
>> > it
>> >  is mapped and whether it is enabled.  This allows a device to configure
>> >  a memory region once, then hand it off to its parent bus to map it
>> > according
>> >  to the bus configuration.
>> >
>> >  Hierarchical registration also allows a device to compose a region out
>> > of
>> >  a number of sub-regions with different properties; for example some may
>> > be
>> >  RAM while others may be MMIO.
>
>> >  +void memory_region_set_log(MemoryRegion *mr, bool log, unsigned
>> > client);
>> >  +/* Enable memory coalescing for the region.  MMIO ->write callbacks
>> > may be
>> >  + * delayed until a non-coalesced MMIO is issued.
>> >  + */
>> >  +void memory_region_set_coalescing(MemoryRegion *mr);
>> >  +/* Enable memory coalescing for a sub-range of the region.  MMIO
>> > ->write
>> >  + * callbacks may be delayed until a non-coalesced MMIO is issued.
>> >  + */
>> >  +void memory_region_add_coalescing(MemoryRegion *mr,
>> >  +                                  target_phys_addr_t offset,
>> >  +                                  target_phys_addr_t size);
>> >  +/* Disable MMIO coalescing for the region. */
>> >  +void memory_region_clear_coalescing(MemoryRegion *mr);
>>
>> Perhaps the interface could be more generic, like
>> +void memory_region_set_property(MemoryRegion *mr, unsigned flags);
>> +void memory_region_clear_property(MemoryRegion *mr, unsigned flags);
>>
>
> Coalescing is a complex property, not just a boolean attribute.  We probably
> will have a number of boolean attributes later, though.

But what is the difference between adding coalescing to an area and
setting the bit property 'coalescing' to an area? At least what you
propose now is not so complex that it couldn't be handled as a single
bit.

>> >  + * conflicts are resolved by having a higher @priority hide a lower
>> > @priority.
>> >  + * Subregions without priority are taken as @priority 0.
>> >  + */
>> >  +void memory_region_add_subregion_overlap(MemoryRegion *mr,
>> >  +                                         target_phys_addr_t offset,
>> >  +                                         MemoryRegion *subregion,
>> >  +                                         unsigned priority);
>> >  +/* Remove a subregion. */
>> >  +void memory_region_del_subregion(MemoryRegion *mr,
>> >  +                                 MemoryRegion *subregion);
>>
>> What would the subregions be used for?
>
> Subregions describe the flow of data through the memory bus.  We'd have a
> subregion for the PCI bus, with its own subregions for various BARs, with
> some having subregions for dispatching different MMIO types within the BAR.
>
> This allows, for example, the PCI layer to move a BAR without the PCI device
> knowing anything about it.

But why can't a first class region be used for that?



reply via email to

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