From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZd8S-0002sX-Tw for qemu-devel@nongnu.org; Fri, 25 Oct 2013 04:52:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZd8J-0002X5-7w for qemu-devel@nongnu.org; Fri, 25 Oct 2013 04:52:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZd8J-0002Wp-0B for qemu-devel@nongnu.org; Fri, 25 Oct 2013 04:52:39 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9P8qcKv001367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Oct 2013 04:52:38 -0400 Message-ID: <526A3152.2020603@redhat.com> Date: Fri, 25 Oct 2013 09:52:34 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20131024211158.064049176@amt.cnet> <20131024211249.723543071@amt.cnet> <5269B378.6040409@redhat.com> <20131025045805.GA18280@amt.cnet> In-Reply-To: <20131025045805.GA18280@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1 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, qemu-devel@nongnu.org, gleb@redhat.com Il 25/10/2013 05:58, Marcelo Tosatti ha scritto: > 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). > > - 1GB backed RAM can be mapped with 2MB pages. > >> 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). > > Why the description of memory subregions and aliases are part of machine > types? It affects the migration stream, which stores RAM offsets instead of physical addresses. Let's say you have an 8 GB guest and the hole size is 0.25 GB. If the huge page size is 2MB, you have: Physical address Length RAM offsets 0 3.75 GB pc.ram @ 0 4 GB 4.25 GB pc.ram @ 3.75 GB If the huge page size is 1GB, you have: Physical address Length RAM offsets 0 3.75 GB pc.ram @ 0 4 GB 4 GB pc.ram @ 4 GB 8 GB 0.25 GB pc.ram @ 3.75 GB So your memory "rotates" around the 3.75 GB boundary when you migrate from a non-gbpages host to a gbpages host or vice versa. If we're doing it only for new machine types, it's even simpler to just have two RAM regions: Physical address Length RAM offsets 0 3.75 GB pc.ram-below-4g @ 0 4 GB 4.25 GB pc.ram-above-4g @ 0 Because offsets are zero, and lengths match the RAM block lengths, you do not need any complication with aliasing. This still has to be done only for new machine types. Paolo