[Top][All Lists]

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

Re: [Qemu-devel] [RFC][PATCH 09/15] memory: Introduce address_space_look

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC][PATCH 09/15] memory: Introduce address_space_lookup_region
Date: Mon, 06 May 2013 16:54:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

Il 06/05/2013 16:51, Jan Kiszka ha scritto:
> On 2013-05-06 16:39, Paolo Bonzini wrote:
>> Il 06/05/2013 16:26, Jan Kiszka ha scritto:
>>> This new service so far only replaces phys_page_find as public API. In a
>>> follow-up step, it will return the effective memory region for the
>>> specified address, i.e. after resolving what are currently sub-pages.
>>> Moreover, it will also once encapsulate locking and reference counting
>>> when we introduce BQL-free dispatching.
>> In my IOMMU rebase I have a similar function:
>> /* address_space_translate: translate an address range into an address space
>>  * into a MemoryRegionSection and an address range into that section.
>>  *
>>  * @as: #AddressSpace to be accessed
>>  * @addr: address within that address space
>>  * @xlat: pointer to address within the returned memory region section's
>>  * #MemoryRegion.
>>  * @len: pointer to length
>>  * @is_write: indicates the transfer direction
>>  */
>> MemoryRegionSection *address_space_translate(AddressSpace *as, hwaddr addr,
>>                                              hwaddr *xlat, hwaddr *len,
>>                                              bool is_write);
>> It wraps (actually, replaces) both phys_page_find and
>> memory_region_section_addr.
> Good, looks like we are heading in similar directions. What is the
> purpose of len? When does is_write matter?

Both matter when adding the IOMMU.  is_write is needed to check for
permissions, and len because the translation will be valid for one page
only (not for the full size of the MemoryRegion.

I can implement address_space_translate on top of
address_space_lookup_region and include your next patch too, so we're
fine here.


> In a later step, this should become something like
> address_space_get_region_ref (to be paired with memory_region_unref,
> once done). So this one also takes care of incrementing the reference
> counter or acquiring the BQL, as necessary. Currently, it asks the
> caller to specify if the BQL is already held, but that will change.
> Jan

reply via email to

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