From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJ7ge-0007V1-NL for qemu-devel@nongnu.org; Wed, 26 Oct 2011 13:54:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJ7gd-0001cu-FS for qemu-devel@nongnu.org; Wed, 26 Oct 2011 13:54:48 -0400 Received: from server514f.exghost.com ([72.32.253.73]:1173 helo=server514.appriver.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJ7gd-0001cq-1B for qemu-devel@nongnu.org; Wed, 26 Oct 2011 13:54:47 -0400 Received: from [72.32.253.65] (HELO FE03.exg4.exghost.com) by server514.appriver.com (CommuniGate Pro SMTP 5.4.1) with ESMTP id 182419209 for qemu-devel@nongnu.org; Wed, 26 Oct 2011 12:54:44 -0500 Message-ID: <4EA84963.9030007@virtualcomputer.com> Date: Wed, 26 Oct 2011 13:54:43 -0400 From: John Baboval MIME-Version: 1.0 References: <4EA81094.5050400@virtualcomputer.com> In-Reply-To: <4EA81094.5050400@virtualcomputer.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] New Memory API Question List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org So I've figured out the answer to my own question... I was, in fact, missing something. The destructor for the subregion is not overwritten. It's the parent region's destructor that is written. On 10/26/2011 09:52 AM, John Baboval wrote: > Sorry for coming late to the party on this... I only read qemu-devel > through a filter so I missed all the discussions on the new memory > API. I have a question as to how it works and how it's supposed to > work in certain scenarios. > > It's a question of flow. I'm following the code path through the > creation of a new memory subregion. If I'm reading this properly, it > would seem that a MemoryRegion - for example the ones used by VGA - go > through the following flow: > > memory_region_init_ram() - (mr->destructor is set to > memory_region_destructor_ram) > memory_region_add_subregion(system_memory, ...) -> > memory_region_update_topology() -> > address_space_update_topology() > address_space_update_topology_part() > as_memory_range_add() - through the ops vector > memory_region_prepare_ram_addr() > > > At this point it seems that the destructor is overwritten with the > memory_region_destructor_iomem(), and it loses track of the proper way > to ever free the memory region. Is this correct, or am I missing > something? > > Or does it not matter because nobody ever calls memory_region_destroy > for system memory regions? > > Thanks, > -John >