From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJ1ik-0000pp-8L for qemu-devel@nongnu.org; Fri, 22 Mar 2013 09:09:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJ1ih-00056L-CD for qemu-devel@nongnu.org; Fri, 22 Mar 2013 09:09:22 -0400 Received: from mail-la0-x22d.google.com ([2a00:1450:4010:c03::22d]:50428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJ1ih-000564-5I for qemu-devel@nongnu.org; Fri, 22 Mar 2013 09:09:19 -0400 Received: by mail-la0-f45.google.com with SMTP id er20so7291726lab.32 for ; Fri, 22 Mar 2013 06:09:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1363905812.31522.28@snotra> References: <0738307B-4C19-4650-92F1-14B038202B6C@suse.de> <1363905812.31522.28@snotra> From: Peter Maydell Date: Fri, 22 Mar 2013 13:08:57 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Scott Wood Cc: "qemu-ppc@nongnu.org list:PowerPC" , Alexander Graf , qemu-devel qemu-devel On 21 March 2013 22:43, Scott Wood wrote: > What if the update is to a parent memory region, not to the one directly > associated with the device? > > Or does add() get called for all child regions (recursively) in such cases? 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. This code isn't the first use of the memory API listeners, so it's all well-tested code. >> However, maybe with a bit of brainstorming we could come up with a >> reasonably generic scheme. > In the kernel API? Or do you mean a generic scheme within QEMU that encodes > any reasonably expected mechanism for setting the device adress (e.g. assume > that it is either a 64-bit attribute, or uses the legacy ARM API), 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. Well, nor is the ARM memory listener, but why have two bits of code doing the same thing when you could have one? -- PMM