From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz2Lh-0001AJ-4M for qemu-devel@nongnu.org; Tue, 16 Jul 2013 06:19:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uz2Lf-0008AX-PO for qemu-devel@nongnu.org; Tue, 16 Jul 2013 06:19:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65375) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz2Lf-0008AM-FX for qemu-devel@nongnu.org; Tue, 16 Jul 2013 06:19:11 -0400 Date: Tue, 16 Jul 2013 12:19:01 +0200 From: Igor Mammedov Message-ID: <20130716121901.157d7e85@nial.usersys.redhat.com> In-Reply-To: <51E4E604.6060608@redhat.com> 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> 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 , Hu Tao , qemu-devel@nongnu.org, Vasilis Liaskovitis , Bandan Das , gaowanlong@cn.fujitsu.com 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. 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. In addition command line -device would be used in migration case to describe already hot-plugged dimms on target. > BTW, how do you specify which module you are plugging in? I.e., what if > I have three 1G ranges at 0, 1G and 2G, and I want to plug the first and > the third? > This is especially important with hot-unplug, because then you can have > this kind of hole in the address space. If you migrate the VM, you have > to reproduce the situation in the destination command line. Could we add optional advising 'base-addr' property to replicate exact source configuration on target? some thing like: -device dimm,node=X,size=Y,base-addr=Z where mgmt could get actual X,Y,Z inspecting dim device via qom-get. and if base-addr is not set parent of dimm would auto-allocate address where dimm is mapped. > > Paolo >