From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJbeX-0002qr-FU for qemu-devel@nongnu.org; Wed, 11 Sep 2013 00:03:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJbeR-0007ZT-FX for qemu-devel@nongnu.org; Wed, 11 Sep 2013 00:03:41 -0400 Received: from [222.73.24.84] (port=50129 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJbeR-0007WG-2v for qemu-devel@nongnu.org; Wed, 11 Sep 2013 00:03:35 -0400 Date: Wed, 11 Sep 2013 12:01:44 +0800 From: Hu Tao Message-ID: <20130911040144.GA25851@localhost.localdomain> References: <1374596592-7027-1-git-send-email-imammedo@redhat.com> MIME-Version: 1.0 In-Reply-To: <1374596592-7027-1-git-send-email-imammedo@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: Re: [Qemu-devel] [PATCH 00/16 RFC v6] ACPI memory hotplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: vasilis.liaskovitis@profitbricks.com, pbonzini@redhat.com, qemu-devel@nongnu.org On Tue, Jul 23, 2013 at 06:22:56PM +0200, Igor Mammedov wrote: > As opposed to previous approach, > This series allows to hotplug 'arbitrary' DIMM devices specifying size, > NUMA node mapping, slot and address where to map it, at runtime. > > Due to ACPI limitation there is need to specify a number of possible > DIMM devices. For this task -m option was extended to support > following format: > > -m [mem=]RamSize[,slots=N,maxmem=M] > > To allow memory hotplug user must specify a pair additional parameters: > 'slots' - number of possible increments > 'maxmem' - max possible total memory size QEMU is allowed to use, > including RamSize. > > minimal monitor command syntax to hotplug DIMM device: > > device_add dimm,id=dimmX > > DIMM device provides following properties that could be used with > device_add / -device to alter default behavior: > > id - unique string identifying device [mandatory] > slot - number in range [0-slots) [optional], if not specified > the first free slot is used > node - NUMA node id [optional] (default: 0) > size - amount of memory to add [optional] (default: 1Gb) > start - guest's physical address where to plug DIMM [optional], > if not specified the first gap in hotplug memory region > that fits DIMM is used > > -device option could be used for adding potentially hotunplugable DIMMs > and also for specifying hotplugged DIMMs in migration case (not tested). > > Current implementation supports only x86-64 variant and places hotplug > memory region above 4Gb before 64-bit PCI hole. > > Tested guests: > - Fedora 19x64 > - Windows 2012DCx64 > - Windows 2008DCx64 > > Known limitations/bugs/TODOs: > - only hot-add supported > - q35 is not supported yet > - max number of supported DIMM devices 255 (due to ACPI object name > limit), could be increased creating several containers and putting > DIMMs there. (exercise for future) > - failed hotplug action consumes 1 slot (device_add doesn't delete > device if realize failed) > - e820 table doesn't include DIMM devices added with -device / > (or after reboot devices added with device_add) > - Windows 2008 remembers DIMM configuration, so if DIMM with other > start/size is added into the same slot, it refuses to use it insisting > on old mapping. With this series we can hotplug memory of arbitrary size, but Linux expects a minimum size of hotpluggable memory. Take 128M in x86_64 for example, if first hotplug 64M memory (less than 128M) than we can't add another 64M memory. So the question is should we have a lower limit of hotplugged memory in qemu (which is easy but it's not qemu's problem, and different OS/hardware may have different limits)? Or maybe we can fix it in Linux (which is difficult and I'm not sure it'll casue any compatibility problem)?