From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1vZU-0004kw-Fw for qemu-devel@nongnu.org; Wed, 24 Jul 2013 05:41:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1vZS-00046V-Ur for qemu-devel@nongnu.org; Wed, 24 Jul 2013 05:41:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1vZS-00046K-M7 for qemu-devel@nongnu.org; Wed, 24 Jul 2013 05:41:22 -0400 Message-ID: <51EFA130.5050400@redhat.com> Date: Wed, 24 Jul 2013 11:41:04 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1374596592-7027-1-git-send-email-imammedo@redhat.com> <1374596592-7027-11-git-send-email-imammedo@redhat.com> <51EEB8C6.1030601@redhat.com> <20130724103622.73cf0869@nial.usersys.redhat.com> In-Reply-To: <20130724103622.73cf0869@nial.usersys.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 10/16] dimm: add busy slot check and slot auto-allocation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: vasilis.liaskovitis@profitbricks.com, hutao@cn.fujitsu.com, qemu-devel@nongnu.org Il 24/07/2013 10:36, Igor Mammedov ha scritto: > On Tue, 23 Jul 2013 19:09:26 +0200 > Paolo Bonzini wrote: > >> Il 23/07/2013 18:23, Igor Mammedov ha scritto: >>> - if slot property is not specified on -device/device_add command, >>> treat default value as request for assigning DimmDevice to >>> the first free slot. >> >> Even with "-m" instead of "-numa mem", I think this is problematic >> because we still need to separate the host and guest parts of the DIMM >> device. "-numa mem" (or the QMP command that Wanlong added) will be >> necessary to allocate memory on the host side before adding a DIMM. > why not do host allocation part at the same time when DIMM is added, is > there a real need to separate DIMM device? > > I probably miss something but -numa mem option and co aside what problem > couldn't be solved during DIMM device initialization and would require > a split DIMM device? Because otherwise, every option we add to "-numa mem" will have to be added to "-device dimm". For example, -device dimm,policy=interleave makes no sense to me. In fact, this is no different from having to do drive_add or netdev_add before device_add. First you tell QEMU about the host resources to use, then you add the guest device and bind the device to those resources. >> So slots will have three states: free (created with "-m"), allocated (a >> free slot moves to this state with "-numa mem...,populated=no" when >> migrating, or with the QMP command for regular hotplug), populated (an >> allocated slot moves to this state with "-device dimm"). >> >> You would be able to plug a DIMM only into an allocated slot, and the >> size will be specified on the slot rather than the DIMM device. > 'slot' property is there only for migration sake to provide stable > numeric ID for QEMU<->ACPI BIOS interface. It's not used for any other > purpose and wasn't intended for any other usage.. How would you otherwise refer to the memory you want to affect in a set-mem-policy monitor command? > on baremetal slot has noting to do with size of plugged in DIMM, On baremetal slots also belong to a specific NUMA node, for what it's worth. There are going to be differences with baremetal no matter what. > why we > would model it other way if it only brings problems: like predefined size, It doesn't have to be predefined. In the previous discussions (and also based on Vasilis and Hu Tao's implementations) I assumed predefined slot sizes. Now I understand the benefit of having a simpler command-line with "-m", but then in return you need three slot states instead of just unpopulated/populated. So you'd just do set-mem-policy 0 size=2G # free->allocated device_add dimm,slotid=0 # allocated->populated to hotplug a 2G DIMM. And you'll be able to pin it to host NUMA nodes, and assign it to guest NUMA nodes, like this: set-mem-policy 0 size=2G,nodeid=1,policy=membind host-nodes=0-1 device_add dimm,slotid=0 Again, this is the same as drive_add/device_add. Paolo > allocated, free etc. I think slot should be either free or busy. > > >> >> In general, I don't think free slots should be managed by the DimmBus, >> and host vs. guest separation should be there even if we accept your >> "-m" extension (doesn't look bad at all, I must say). >> >> Paolo >