From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwbAt-00017x-4g for qemu-devel@nongnu.org; Tue, 09 Jul 2013 12:53:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UwbAs-0001GP-22 for qemu-devel@nongnu.org; Tue, 09 Jul 2013 12:53:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10885) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwbAr-0001GJ-PN for qemu-devel@nongnu.org; Tue, 09 Jul 2013 12:53:57 -0400 Date: Tue, 9 Jul 2013 18:53:47 +0200 From: Igor Mammedov Message-ID: <20130709185347.4b8d8bd3@nial.usersys.redhat.com> In-Reply-To: <51CBE1DD.9020301@redhat.com> References: <6b5ff346b23fba9a8707507fda7f9b71719a55be.1372234719.git.hutao@cn.fujitsu.com> <51CAB866.2080507@redhat.com> <51CBC8B3.8070708@cn.fujitsu.com> <51CBE1DD.9020301@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 05/14] vl: handle "-device dimm" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Eduardo Habkost , mst@redhat.com, Hu Tao , qemu-devel@nongnu.org, Vasilis Liaskovitis , Bandan Das , gaowanlong@cn.fujitsu.com On Thu, 27 Jun 2013 08:55:25 +0200 Paolo Bonzini wrote: > Il 27/06/2013 07:08, Wanlong Gao ha scritto: > > Do we really need to specify the memory range? I suspect that we can > > follow current design of normal memory in hot-plug memory. > > I think we can do both. I'm afraid that the configuration of the VM > will not be perfectly reproducible without specifying the range, more so > if you allow hotplug. > > > Currently, > > we just specify the size of normal memory in each node, and the range > > in normal memory is node by node. Then I think we can just specify > > the memory size of hot-plug in each node, then the hot-plug memory > > range is also node by node, and the whole hot-plug memory block is > > just located after the normal memory block. If so, the option can > > come like: > > -numa node,nodeid=0,mem=2G,cpus=0-1,mem-hotplug=2G,mem-policy=membind,mem-hostnode=0-1,mem-hotplug-policy=interleave,mem-hotplug-hostnode=1 > > -numa node,nodeid=1,mem=2G,cpus=2-3,mem-hotplug=2G,mem-policy=preferred,mem-hostnode=1,mem-hotplug-policy=membind,mem-hotplug-hostnode=0-1 > > I think specifying different policies and bindings for normal and > hotplug memory is too much fine-grained. If you really want that, then > you would need something like > > -numa node,nodeid=0,cpus=0-1 \ > -numa mem,nodeid=0,size=2G,policy=membind,hostnode=0-1 \ > -numa mem,nodeid=0,size=2G,policy=interleave,hostnode=1,populated=no > > Hmm... this actually doesn't look too bad, and it is much more > future-proof. Eduardo, what do you think about it? Should Wanlong redo > his patches to support this "-numa mem" syntax? Parsing it should be > easy using the QemuOpts visitor, too. Is hot-plugged memory and its bindings to numa nodes have to be specified at startup? How about extending -m option to support following syntax: -m initial_mem[, number_of_hotplug_dimms, max_mem]] and dynamically forming MEMXX._CRS/_PXM resources on demand instead of creating static resources in SSDT. without necessity to specify to be hot-plugged DIMMs at startup, hot-plug could become more flexible since arbitrarily sized DIMMs with required NUMA mapping could be specified during hot-plug time, for example: device_add dimm,id=dimm1,bus=membus.0,size=3G,node=1,... the only limit would be left is a number of increments(DIMM slots), due to need to pre-generate ACPI memory devices that could supply _CRS/_PXM resources later. > Paolo > >