From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZEuA-0003Vm-9o for qemu-devel@nongnu.org; Fri, 26 Feb 2016 04:41:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZEu7-0006ay-Dh for qemu-devel@nongnu.org; Fri, 26 Feb 2016 04:41:46 -0500 Received: from e23smtp03.au.ibm.com ([202.81.31.145]:50977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZEu6-0006aL-Sd for qemu-devel@nongnu.org; Fri, 26 Feb 2016 04:41:43 -0500 Received: from localhost by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 26 Feb 2016 19:41:35 +1000 Date: Fri, 26 Feb 2016 15:10:32 +0530 From: Bharata B Rao Message-ID: <20160226094032.GB10503@in.ibm.com> References: <1456417362-20652-1-git-send-email-bharata@linux.vnet.ibm.com> <1456417362-20652-6-git-send-email-bharata@linux.vnet.ibm.com> <20160226040317.GH20657@voom.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160226040317.GH20657@voom.fritz.box> Subject: Re: [Qemu-devel] [RFC PATCH v0 5/6] qmp, spapr: Show hot-plugged/pluggable CPU slots in the Machine Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: mjrosato@linux.vnet.ibm.com, agraf@suse.de, thuth@redhat.com, pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru, qemu-devel@nongnu.org, armbru@redhat.com, borntraeger@de.ibm.com, qemu-ppc@nongnu.org, pbonzini@redhat.com, imammedo@redhat.com, afaerber@suse.de, mdroth@linux.vnet.ibm.com David, I am responding to just one comment here and will respond to others in detail later. On Fri, Feb 26, 2016 at 03:03:17PM +1100, David Gibson wrote: > > > + if (!strstart(prop->name, SPAPR_MACHINE_CPU_CORE_PROP, NULL)) { > > + continue; > > + } > > + > > + elem = g_new0(CPUSlotInfoList, 1); > > + s = g_new0(CPUSlotInfo, 1); > > + > > + obj = object_property_get_link(root_container, prop->name, NULL); > > + if (obj) { > > + /* Slot populated */ > > + dev = DEVICE(obj); > > + core = SPAPR_CPU_CORE(obj); > > + > > + if (dev->id) { > > + s->has_id = true; > > + s->id = g_strdup(dev->id); > > + } > > + s->realized = object_property_get_bool(obj, "realized", NULL); > > + s->nr_cpus = core->nr_threads; > > + s->has_nr_cpus = true; > > + s->qom_path = object_get_canonical_path(obj); > > + s->has_qom_path = true; > > + if (s->realized) { > > + spapr_cpuinfo_list(obj, &cpu_prev); > > + } > > + s->has_cpus = true; > > + } else { > > + /* Slot empty */ > > + s->has_id = false; > > + s->has_nr_cpus = false; > > + s->has_qom_path = false; > > + s->has_cpus = false; > > + s->realized = false; > > Um.. doesn't this leave out the cpu model and nr_threads for a > non-populated slot? Which is crucial information for mgmt to populate > the slot. Actually if we don't allow heterogenous configurations, management currently knows how to get model and threads that have already been specified with -cpu and -smp global options respectively. If we want to support heterogenous configurations, should we then have supported model types and thread values listed here ? At the moment I am not sure what those supported types and thread values could be. Regards, Bharata.