From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz2YN-0004ss-Dn for qemu-devel@nongnu.org; Tue, 16 Jul 2013 06:32:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uz2Y8-0004wL-F5 for qemu-devel@nongnu.org; Tue, 16 Jul 2013 06:32:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz2Y8-0004vz-4H for qemu-devel@nongnu.org; Tue, 16 Jul 2013 06:32:04 -0400 Message-ID: <51E52112.3010803@redhat.com> Date: Tue, 16 Jul 2013 12:31:46 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <6b5ff346b23fba9a8707507fda7f9b71719a55be.1372234719.git.hutao@cn.fujitsu.com> <51CAB866.2080507@redhat.com> <51CBC8B3.8070708@cn.fujitsu.com> <51CBE1DD.9020301@redhat.com> <20130715170551.GC11958@dhcp-192-168-178-175.profitbricks.localdomain> <51E42D06.9080004@redhat.com> <20130716012744.GE10917@G08FNSTD100614.fnst.cn.fujitsu.com> <51E4E604.6060608@redhat.com> <20130716121901.157d7e85@nial.usersys.redhat.com> In-Reply-To: <20130716121901.157d7e85@nial.usersys.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Igor Mammedov Cc: Eduardo Habkost , Hu Tao , qemu-devel@nongnu.org, Vasilis Liaskovitis , Bandan Das , gaowanlong@cn.fujitsu.com Il 16/07/2013 12:19, Igor Mammedov ha scritto: > On Tue, 16 Jul 2013 08:19:48 +0200 > Paolo Bonzini wrote: > >> Il 16/07/2013 03:27, Hu Tao ha scritto: >>>> I think it's the same. One "-numa mem" option = one "-device dimm" >>>> option; both define one range. Unused memory ranges may remain if you >>>> stumble upon a unusable range such as the PCI window. For example two >>>> "-numa mem,size=2G" options would allocate memory from 0 to 2G and from >>>> 4 to 6G. >>> >>> So we can drop -dimm if we agree on -numa mem? >> >> Yes, the point of the "-numa mem" proposal was to avoid the concept of a >> "partially initialized device" that you had for DIMMs. > I've though -numa mem was for mapping initial memory to numa nodes. > It seem wrong to use it for representing dimm device and also limiting > possible hotplugged regions to specified at startup ranges. It's not for DIMM devices, it is for reserving areas of the address space for hot-plugged RAM. DIMM hotplug is done with "device_add dimm" (and you can also use "-numa mem,populated=no,... -device dimm,..." to start a VM with hot-unpluggable memory). > we can leave -numa for initial memory mapping and manage of the mapping > of hotpluggable regions with -device dimm,node=X,size=Y. > > It that case command line -device dimm will provide a fully initialized > dimm device usable at startup (but hot-unplugable) and > (monitor) device_add dimm,,node=X,size=Y > would serve hot-plug case. > > That way arbitrary sized dimm could be hot-pluged without specifying them > at startup, like it's done on bare-metal. But the memory ranges need to be specified at startup in the ACPI tables, and that's what "-numa mem" is for. > In addition command line -device would be used in migration case to describe > already hot-plugged dimms on target. Yep. Paolo