From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USFxn-0007si-VP for qemu-devel@nongnu.org; Tue, 16 Apr 2013 20:11:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USFxl-0001Bo-6x for qemu-devel@nongnu.org; Tue, 16 Apr 2013 20:11:03 -0400 Date: Tue, 16 Apr 2013 19:10:48 -0500 From: Scott Wood In-Reply-To: (from peter.maydell@linaro.org on Tue Apr 16 03:25:50 2013) Message-ID: <1366157448.23030.25@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH v2 3/6] memory: add memory_region_to_address() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-ppc@nongnu.org, Alexander Graf , qemu-devel@nongnu.org On 04/16/2013 03:25:50 AM, Peter Maydell wrote: > On 16 April 2013 00:19, Scott Wood wrote: > > This is useful for when a user of the memory region API needs to > > communicate the absolute bus address to something outside QEMU > > (in particular, KVM). > > > > Signed-off-by: Scott Wood > > --- > > TODO: Use add/del memory listeners later in the patchset, which =20 > would > > eliminate the need for this patch. >=20 > Yes, please do. I will. Alex wanted a respun patchset to work with the latest kernel =20 API, and I didn't have a chance to address this yet. It's still RFC. > > +/* memory_region_to_address: Find the full address of the start of =20 > the > > + * given #MemoryRegion, ignoring aliases. There is no =20 > guarantee > > + * that the #MemoryRegion is actually visible at this =20 > address, if > > + * there are overlapping regions. > > + * > > + * @mr: #MemoryRegion being queried > > + * @asp: if non-NULL, returns the #AddressSpace @mr is mapped in, =20 > if any > > + */ > > +hwaddr memory_region_to_address(MemoryRegion *mr, AddressSpace =20 > **asp); >=20 > A MemoryRegion can appear in more than one AddressSpace (or none at =20 > all), > so I don't think this is a very clearly defined API to put in the > memory API itself. (It's ok to make that kind of assumption as a user > of the memory APIs for particular cases, eg in how a memory listener > callback function behaves. But we shouldn't be baking those =20 > assumptions > into new API functions.) I'm not sure how it's different from memory_region_to_address_space in =20 that regard, other than its ability to gracefully handle the "or none =20 at all" case. How does it work to be in more than one AddressSpace, if there's a =20 parent chain? More than one "as" with the same "as->root"? Or are you =20 referring to aliases? -Scott=