From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpBc3-00026l-9M for qemu-devel@nongnu.org; Mon, 13 Aug 2018 08:06:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fpBc0-0005JZ-2O for qemu-devel@nongnu.org; Mon, 13 Aug 2018 08:06:19 -0400 Date: Mon, 13 Aug 2018 09:06:09 -0300 From: Eduardo Habkost Message-ID: <20180813120609.GR15372@localhost.localdomain> References: <1533910017-55158-1-git-send-email-imammedo@redhat.com> <20180810180106.26e1f642@redhat.com> <20180810182835.GZ15372@localhost.localdomain> <20180813090713.76d7f710@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180813090713.76d7f710@redhat.com> Subject: Re: [Qemu-devel] [PATCH] acpi: SRAT: do not create reserved gap entries List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: qemu-devel@nongnu.org, qemu-stable@nongnu.org, lersek@redhat.com, mst@redhat.com On Mon, Aug 13, 2018 at 09:07:13AM +0200, Igor Mammedov wrote: > On Fri, 10 Aug 2018 15:28:35 -0300 > Eduardo Habkost wrote: > > > On Fri, Aug 10, 2018 at 06:01:06PM +0200, Igor Mammedov wrote: > > > On Fri, 10 Aug 2018 16:06:57 +0200 > > > Igor Mammedov wrote: > > > > > > > Commit 848a1cc1e8b04 while introducing SRAT entries for DIMM and NVDIMM > > > > also introduced fake entries for gaps between memory devices, assuming > > > > that we need all possible range covered with SRAT entries. > > > > And it did it wrong since gap would overlap with preceeding entry. > > > > Reproduced with following CLI: > > > > > > > > -m 1G,slots=4,maxmem=8 \ > > > > -object memory-backend-ram,size=1G,id=m0 \ > > > > -device pc-dimm,memdev=m0,addr=0x101000000 \ > > > > -object memory-backend-ram,size=1G,id=m1 \ > > > > -device pc-dimm,memdev=m1 > > > > > > > > However recent development (10efd7e108) showed that gap entries might > > > > be not need. And indeed testing with WS2008DC-WS2016DC guests range > > > > shows that memory hotplug works just fine without gap entries. > > > > > > > > So rather than fixing gap entry borders, just drop them altogether > > > > and simplify code around it. > > > > > > > > Spotted-by: Laszlo Ersek > > > > Signed-off-by: Igor Mammedov > > > > --- > > > > There is no need to update reference blobs since gaps beween dimms > > > > aren't generated by any exsting test case. > > > > > > > > Considering issue is not visible by default lets just merge it into 3.1 > > > > and stable 3.0.1 > > > Pls ignore it for now I'll need to do more extensive testing with old kernels, > > > we might need these holes for old kernels or even new ones. > > > /me goes to read kernel code > > > > > > /per spec possible to hotplug range could be in SRAT, > > > even though I don't like it bu we might end up with static > > > partitioning of hotplug area between nodes like on bare metal > > > to avoid chasing after unknown requirements from windows / > > > > Does that mean we might want to pair DIMM slots with NUMA nodes > > in advance? Do you have a suggestion on how the command-line > > would look like, in this case? > > > > Maybe "-numa mem-slot,slot=X,node=Y"? > it's either, to make it per slot (it implies fixed maximum size per slot) > or a bit more flexible maxmem per node, might be something like: > -numa memory,node=X,maxmem=Y That could work, but maybe it's too much flexibility? It would be tricky to define what is supposed happen when a slot cross multiple NUMA nodes. -- Eduardo