From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf49F-0004NK-Ga for qemu-devel@nongnu.org; Mon, 06 Apr 2015 06:20:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yf497-0008BD-7X for qemu-devel@nongnu.org; Mon, 06 Apr 2015 06:20:53 -0400 Received: from e23smtp07.au.ibm.com ([202.81.31.140]:46892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf496-0008Al-IW for qemu-devel@nongnu.org; Mon, 06 Apr 2015 06:20:45 -0400 Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 6 Apr 2015 20:20:40 +1000 Date: Mon, 6 Apr 2015 15:49:24 +0530 From: Bharata B Rao Message-ID: <20150406101923.GC16874@in.ibm.com> References: <1427117764-23008-1-git-send-email-bharata@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1427117764-23008-1-git-send-email-bharata@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 00/23] CPU and Memory hotplug for PowerPC sPAPR guests Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: mdroth@linux.vnet.ibm.com, agraf@suse.de, qemu-ppc@nongnu.org, tyreld@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com, imammedo@redhat.com, afaerber@suse.de, david@gibson.dropbear.id.au On Mon, Mar 23, 2015 at 07:05:41PM +0530, Bharata B Rao wrote: > Hi, > > This is the version 2 of the patchset that provides CPU and memory hotplug > support for PowerPC sPAPR guests. [snip] > TODOs > ----- > - Share code between pc_dimm_plug() and spapr_memory_plug(). > - Make the algorithm that looks up the NUMA node given the physical address > more efficient. > - Test/enable migration after hotplug. While I am using a bitmap based CPU enumeration (patch 14/23 in this patchset), to correctly support CPU hot removal, it appears that supporting hot removal with migration is non trivial if we allow removal in arbitrary order and not necessarily remove-last-added-cpu-first order. If there are holes in CPU index map (like 0-15,20-23) at the source VM due to hot removal, the CPU index map at the target VM will be 0-19 by default. I see there was a patch to solve somewhat similar problem on x86 last year (https://lists.nongnu.org/archive/html/qemu-devel/2014-01/msg01607.html), but don't see it being pursued further. What would be the ideal or recommended way to solve this problem ? Easiest would be to enforce hot removal in LIFO order, but I guess that would be restrictive. Regards, Bharata.