From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZhXM-0003Zv-Vf for qemu-devel@nongnu.org; Fri, 25 Oct 2013 09:34:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZhXG-0000Gh-V4 for qemu-devel@nongnu.org; Fri, 25 Oct 2013 09:34:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZhXG-0000Gb-Lc for qemu-devel@nongnu.org; Fri, 25 Oct 2013 09:34:42 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9PDYfm0029662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Oct 2013 09:34:41 -0400 Date: Fri, 25 Oct 2013 11:34:22 -0200 From: Marcelo Tosatti Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131025115718.15b6e788@redhat.com> 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: igor Mammedov Cc: aarcange@redhat.com, Paolo Bonzini , qemu-devel@nongnu.org, gleb@redhat.com 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.