From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VaS9H-0003WA-78 for qemu-devel@nongnu.org; Sun, 27 Oct 2013 11:21:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VaS9B-000318-6W for qemu-devel@nongnu.org; Sun, 27 Oct 2013 11:21:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VaS9A-000314-UO for qemu-devel@nongnu.org; Sun, 27 Oct 2013 11:20:57 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9RFKsuK018740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 27 Oct 2013 11:20:55 -0400 Date: Sun, 27 Oct 2013 16:20:44 +0100 From: igor Mammedov Message-ID: <20131027162044.19769397@redhat.com> In-Reply-To: <20131025133421.GA27529@amt.cnet> References: <20131024211158.064049176@amt.cnet> <20131024211249.723543071@amt.cnet> <5269B378.6040409@redhat.com> <20131025045805.GA18280@amt.cnet> <20131025115718.15b6e788@redhat.com> <20131025133421.GA27529@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [patch 2/2] i386: pc: align gpa<->hpa on 1GB boundary List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: aarcange@redhat.com, Paolo Bonzini , qemu-devel@nongnu.org, gleb@redhat.com On Fri, 25 Oct 2013 11:34:22 -0200 Marcelo Tosatti wrote: > On Fri, Oct 25, 2013 at 11:57:18AM +0200, igor Mammedov wrote: > > On Fri, 25 Oct 2013 02:58:05 -0200 > > Marcelo Tosatti wrote: > > > > > On Fri, Oct 25, 2013 at 12:55:36AM +0100, Paolo Bonzini wrote: > > > > > + if (hpagesize == (1<<30)) { > > > > > + unsigned long holesize = 0x100000000ULL - > > > > > below_4g_mem_size; + > > > > > + memory_region_init_alias(ram_above_4g, NULL, > > > > > "ram-above-4g", ram, > > > > > + 0x100000000ULL, > > > > > + above_4g_mem_size - > > > > > holesize); > > > > > + memory_region_add_subregion(system_memory, > > > > > 0x100000000ULL, > > > > > + ram_above_4g); > > > > > + > > > > > + ram_above_4g_piecetwo = > > > > > g_malloc(sizeof(*ram_above_4g_piecetwo)); > > > > > + memory_region_init_alias(ram_above_4g_piecetwo, > > > > > NULL, > > > > > + "ram-above-4g-piecetwo", > > > > > ram, > > > > > + 0x100000000ULL - > > > > > holesize, holesize); > > > > > + memory_region_add_subregion(system_memory, > > > > > + 0x100000000ULL + > > > > > + above_4g_mem_size - > > > > > holesize, > > > > > + > > > > > ram_above_4g_piecetwo); > > > > > > > > Why break it in two? You can just allocate extra holesize > > > > bytes in the "ram" MemoryRegion, and not map the part that > > > > corresponds to [0x100000000ULL - holesize, 0x100000000ULL). > > > > > > - If the "ram" MemoryRegion is backed with 1GB hugepages, you > > > might not want to allocate extra holesize bytes (which might > > > require an entire 1GB page). > > From POV of moddeling current "ram" as dimm devices, aliasing > > wouldn't work nice. But breaking one block in two or more is fine > > since then blocks could be represented as several dimm devices. > > > > +3Gb backend ram it could be split in blocks like this: > > > > [ 3Gb (1Gb pages backed) ] > > [tail1 (below_4gb - 3Gb) (2mb pages backed) ] > > [above_4gb whole X Gb pages (1Gb pages backed)] > > [tail2 (2mb pages backed)] > > Yes, thought of that, unfortunately its cumbersome to add an interface > for the user to supply both 2MB and 1GB hugetlbfs pages. Could 2Mb tails be automated, meaning if host uses 1Gb hugepages and there is/are tail/s, QEMU should be able to figure out alignment issues and allocate with appropriate pages. Goal is separate host part allocation aspect from guest related one, aliasing 32-bit hole size at the end doesn't help it at all, it's quite opposite, it's making current code more complicated and harder to fix in the future.