From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39898) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJA64-0004w6-Sm for qemu-devel@nongnu.org; Fri, 22 Mar 2013 18:06:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJA5m-0006Ft-Vb for qemu-devel@nongnu.org; Fri, 22 Mar 2013 18:06:00 -0400 Date: Fri, 22 Mar 2013 17:05:13 -0500 From: Scott Wood In-Reply-To: (from peter.maydell@linaro.org on Fri Mar 22 08:08:57 2013) Message-ID: <1363989913.24790.10@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] [Qemu-ppc] [RFC ppc-next PATCH 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 list:PowerPC" , Alexander Graf , qemu-devel qemu-devel On 03/22/2013 08:08:57 AM, Peter Maydell wrote: > On 21 March 2013 22:43, Scott Wood wrote: > > What if the update is to a parent memory region, not to the one =20 > directly > > associated with the device? > > > > Or does add() get called for all child regions (recursively) in =20 > such cases? >=20 > The memory API flattens the tree of memory regions down into a flat > view of the address space. These callbacks get called for the > final flattened view (so you'll never see a pure container in the > callback, only leaves). The callbacks happen for every region which > appears in the address space, in linear order. When an update happens > memory.c identifies the changes between the old flat view and the > new one and calls callbacks appropriately. OK, so .add and .del will be sufficient to capture any manipulation =20 that would affect whether and where the region we care about is mapped? > This code isn't the > first use of the memory API listeners, so it's all well-tested code. Sure, I'm not suggesting the code doesn't work -- just trying to =20 understand how, so I know I'm using it properly. The implementation is =20 a bit opaque (to me at least), and the listener callbacks aren't =20 documented the way the normal API functions are. > >> However, maybe with a bit of brainstorming we could come up with a > >> reasonably generic scheme. >=20 > > In the kernel API? Or do you mean a generic scheme within QEMU =20 > that encodes > > any reasonably expected mechanism for setting the device adress =20 > (e.g. assume > > that it is either a 64-bit attribute, or uses the legacy ARM API), =20 > or > > perhaps a callback into device code? > > > > The MPIC's memory listener isn't that much code... I'm not sure > > there's a great need for a central KVM registry. >=20 > Well, nor is the ARM memory listener, but why have two bits of > code doing the same thing when you could have one? They're not doing quite the same thing, though, and the effort required =20 to unify them is non-zero. The two main issues are the way that the =20 address is communicated to KVM, and the ability to change the mapping =20 after the guest starts. -Scott=