From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZe9V-0007fI-AT for qemu-devel@nongnu.org; Fri, 25 Oct 2013 05:58:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZe9P-0003wZ-7t for qemu-devel@nongnu.org; Fri, 25 Oct 2013 05:57:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14216) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZe9P-0003wV-0c for qemu-devel@nongnu.org; Fri, 25 Oct 2013 05:57:51 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9P9vnuw013527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Oct 2013 05:57:49 -0400 Date: Fri, 25 Oct 2013 11:57:18 +0200 From: igor Mammedov Message-ID: <20131025115718.15b6e788@redhat.com> In-Reply-To: <20131025045805.GA18280@amt.cnet> References: <20131024211158.064049176@amt.cnet> <20131024211249.723543071@amt.cnet> <5269B378.6040409@redhat.com> <20131025045805.GA18280@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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 02:58:05 -0200 Marcelo Tosatti wrote: > On Fri, Oct 25, 2013 at 12:55:36AM +0100, Paolo Bonzini wrote: > > > + if (hpagesize =3D=3D (1<<30)) { > > > + unsigned long holesize =3D 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 =3D > > > 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); > >=20 > > 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). >=20 > - 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). =46rom 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)] > - 1GB backed RAM can be mapped with 2MB pages. >=20 > > Also, as Peter said this cannot depend on host considerations. > > Just do it unconditionally, but only for new machine types (pc-1.8 > > and q35-1.8, since unfortunately we're too close to hard freeze). >=20 > Why the description of memory subregions and aliases are part of > machine types? >=20 >=20