From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu2C0-00028m-Ju for qemu-devel@nongnu.org; Tue, 02 Jul 2013 11:08:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uu2Bz-0005Co-0t for qemu-devel@nongnu.org; Tue, 02 Jul 2013 11:08:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu2By-0005Bk-PH for qemu-devel@nongnu.org; Tue, 02 Jul 2013 11:08:30 -0400 Message-ID: <51D2ECEA.3050706@redhat.com> Date: Tue, 02 Jul 2013 17:08:26 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1372444009-11544-1-git-send-email-pbonzini@redhat.com> <1372444009-11544-26-git-send-email-pbonzini@redhat.com> <51D2E6C4.2080400@siemens.com> In-Reply-To: <51D2E6C4.2080400@siemens.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 25/30] exec: put memory map in AddressSpaceDispatch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel@nongnu.org Il 02/07/2013 16:42, Jan Kiszka ha scritto: >> > +typedef PhysPageEntry Node[L2_SIZE]; >> > + >> > struct AddressSpaceDispatch { >> > /* This is a multi-level map on the physical address space. >> > * The bottom level has pointers to MemoryRegionSections. >> > */ >> > PhysPageEntry phys_map; >> > + Node *nodes; >> > + MemoryRegionSection *sections; > Why not sticking the whole current PhysPageMap into here? Wouldn't that > also allow to overcome prev_map completely (next patch)? (BTW, this is also why patch 21 has two separate arguments to phys_page_find). Sticking a pointer would add one useless pointer chase. Storing it by value makes it unclear who owns the PhysPageMap and doesn't say that AddressSpaceDispatch cannot extend the vectors. In the end, this seemed like a good compromise. Paolo