From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqlym-00030J-Re for qemu-devel@nongnu.org; Wed, 11 Dec 2013 10:45:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vqlyg-0006fV-QN for qemu-devel@nongnu.org; Wed, 11 Dec 2013 10:45:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqlyg-0006fN-Hc for qemu-devel@nongnu.org; Wed, 11 Dec 2013 10:45:34 -0500 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 rBBFjXx6023300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Dec 2013 10:45:33 -0500 Date: Wed, 11 Dec 2013 16:45:29 +0100 From: Igor Mammedov Message-ID: <20131211164529.0b4d92a6@thinkpad> In-Reply-To: <52A87A89.4000901@redhat.com> References: <1385401393-14291-1-git-send-email-pbonzini@redhat.com> <20131128102652.GA24261@redhat.com> <52A714AC.3050703@redhat.com> <20131210150542.GA27998@amt.cnet> <20131210172144.GA29151@amt.cnet> <20131210210241.GC8476@redhat.com> <20131211134118.GB14071@amt.cnet> <20131211142000.GA23355@redhat.com> <52A87A89.4000901@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH rebased for-1.8] i386: pc: align gpa<->hpa on 1GB boundary (v6) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Marcelo Tosatti , qemu-devel@nongnu.org, "Michael S. Tsirkin" On Wed, 11 Dec 2013 15:45:29 +0100 Paolo Bonzini wrote: > Il 11/12/2013 15:20, Michael S. Tsirkin ha scritto: > > > It means that its necessary to expose that 3-4GB physical memory region > > > in QEMU belongs to the same node (that is, guest must be aware that > > > 3-3.75GB and the tail of RAM are on the same node). > > > > > > So the problem Paolo mentions is fixable. > > I'm not sure if it is fixable. You need a 2M mountpoint to bind the 3G-4G > range correctly, a 1G mountpoint for everything else, and QEMU only allows > to specify one path. we could do it with hugepage memdev backend. something like: -object hugepage-ram,id=mem1gb,size=3G,host-node=0,mem-path=/1gb-hugepage-fs -device dimm,id=hp1g,memdev=mem1gb,node=0 -object hugepage-ram,id=mem2mb,size=500Mb,host-node=1,mem-path=/2mb-hugepage-fs -device dimm,id=hp2mb,memdev=mem2mb,node=1 that basically would allow to distribute initial memory in any way user would like. > > Without Marcelo's patch there is a workaround; if you know the size of the 4G > hole and configure the first two nodes with unequal sizes. For example > > -m 8192 \ > -object memory-ram,id=ram-node0,size=3840M,hostnode=0 -numa node,memdev=ram-node0 \ > -object memory-ram,id=ram-node1,size=4352M,hostnode=1 -numa node,memdev=ram-node1 > > RAM address Host virtual address low bits Guest physical addresses > 0M-3840M 0 0M-3840M > 3840M-8192M 0 4096M-8448M > > Then you'll waste 1GB of RAM (you'll use 9 hugepages instead of 8), but > everything will be aligned. Or you just make your guest 7680M and not waste > the memory. > > But with Marcelo's patch, ram-node1 will be split in two. QEMU will try > to realign the second part of ram-node1, but the result is that the second > part is misaligned and only the first 256M (the tail of guest physical > memory) stays aligned: > > RAM address Host virtual address low bits Guest physical addresses > 0M-3840M 0 0M-3840M > 4096M-8192M 256M 4096M-8192M > 3840M-4096M 0 8192M-8448M > > So you still waste memory, _and_ get incorrect alignment. > > > Okay so > > Marcelo - do you ack this patch for 2.0? > > Paolo - do you re-ack this patch for 2.0? > > I very much prefer Gerd's approach. 2GB low memory for q35 is a bit wasteful, > but we have some time to fix that before release. > > Paolo > -- Regards, Igor