From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPMev-0003Wx-Fn for qemu-devel@nongnu.org; Tue, 19 Jul 2016 00:29:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPMeh-00078G-Cd for qemu-devel@nongnu.org; Tue, 19 Jul 2016 00:29:19 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:5314 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPMeh-00077S-3T for qemu-devel@nongnu.org; Tue, 19 Jul 2016 00:29:15 -0400 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u6J4TAHD005511 for ; Tue, 19 Jul 2016 00:29:10 -0400 Received: from e28smtp07.in.ibm.com (e28smtp07.in.ibm.com [125.16.236.7]) by mx0b-001b2d01.pphosted.com with ESMTP id 2495r7k97w-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Jul 2016 00:29:10 -0400 Received: from localhost by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 19 Jul 2016 09:59:06 +0530 Date: Tue, 19 Jul 2016 09:58:59 +0530 From: Bharata B Rao Reply-To: bharata@linux.vnet.ibm.com References: <1468833560-17397-1-git-send-email-david@gibson.dropbear.id.au> <20160718150618.icfohmtdzuhaqorz@andariel.pipo.sk> <20160718182035.5ede8ab3@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160718182035.5ede8ab3@nial.brq.redhat.com> Message-Id: <20160719042859.GC7036@in.ibm.com> Subject: Re: [Qemu-devel] [RFC 0/2] cpu-add compatibility for query-hotpluggable-cpus implementations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Peter Krempa , David Gibson , qemu-devel@nongnu.org, groug@kaod.org, qemu-ppc@nongnu.org, abologna@redhat.com On Mon, Jul 18, 2016 at 06:20:35PM +0200, Igor Mammedov wrote: > On Mon, 18 Jul 2016 17:06:18 +0200 > Peter Krempa wrote: > > > On Mon, Jul 18, 2016 at 19:19:18 +1000, David Gibson wrote: > > > I'm not entirely sure if this is a good idea, and if it is whether > > > this is a good approach to it. But I'd like to discuss it and see if > > > anyone has better ideas. > > > > > > As you may know we've hit a bunch of complications with cpu_index > > > which will impose some limitations with what we can do with the new > > > query-hotpluggable-cpus interface, and we've run out of time to > > > address these in qemu-2.7. > > > > > > At the same time we're hitting complications with the fact that the > > > new qemu interface requires a new libvirt interface to use properly, > > > and that has follow on effects further up the stack. > > > > The libvirt interface is basically now depending on adding a working > > implementation for qemu or a different hypervisor. APIs without > > implementation are not accepted upstream. > > > > It looks like there are the following problems which make the above > > hard: > > > > First of the problem is the missing link between the NUMA topology > > (currently confirured via 'cpu id' which is not linked in any way to the > > query-hotpluggable-cpus entries). This basically means that I'll have to > > re-implement the qemu numbering scheme and hope that it doesn't change > > until a better approach is added. > with current 'in order' plug/unplug limitation behavior is the same as > for cpu-add (wrt x86) so device_add could be used as direct replacement > of cpu-add in NUMA case. > > Numa node to CPU in query-hotpluggable-cpus a missing part > but once numa mapping for hotplugged CPUs (which is broken now) is fixed > (fix https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg00595.html) > I'll be ready to extend x86.query-hotpluggable-cpus with numa mapping > that -numa cpus=1,2,3... happened to configure. > (note: that device_add cpu,node=X that doesn't match whatever has been > configured with -numa cpus=... will rise error, as numa configuration > is static and fixed at VM creation time, meaning that "node" option > in query-hotpluggable-cpus is optional and only to inform users to > which node cpu belongs) > > > Secondly from my understanding of the current state it's impossible to > > select an arbitrary cpu to hotplug but they need to happen 'in order' of > > the cpu id pointed out above (which is not accessible). The grand plan > > is to allow adding the cpus in any order. This makes the feature look > > like a proof of concept rather than something useful. > having out-of-order plug/unplug would be nice but that wasn't > the grand plan. Main reason is to replace cpu-add with 'device_add cpu' and > on top of that provide support for 'device_del cpu' instead of adding cpu-del > command. > And as result of migration to device_add to avoid changing -smp to match > present cpus count on target and reuse the same interface as other devices. > > We can still pick 'out of order' device_add cpu using migration_id patch > and revert in-order limit patch. It would work for x86, > but I think there were issues with SPAPR, that's why I'm in favor of > in-order limit approach. Not that the migration_id patch doesn't work for sPAPR, but it was felt that having too many IDs (cpu_dt_id, arch_id, migration_id) is not good/idea/preferable and could cause confusion. I am not clear as to why limiting the out-of-order hotplug is a show stopper for libvirt actually. Isn't that how it is for cpu-add currently ? Regards, Bharata.