From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agfyr-0006Uk-1h for qemu-devel@nongnu.org; Thu, 17 Mar 2016 18:01:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agfyn-00033N-2j for qemu-devel@nongnu.org; Thu, 17 Mar 2016 18:01:20 -0400 Date: Thu, 17 Mar 2016 21:03:43 +1100 From: David Gibson Message-ID: <20160317100343.GT9032@voom> References: <1457672078-17307-1-git-send-email-bharata@linux.vnet.ibm.com> <20160314104728.5ff09f86@nial.brq.redhat.com> <20160316034803.GC13176@in.ibm.com> <20160316164850.2c3420db@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1hc8QtWIxzfIcV03" Content-Disposition: inline In-Reply-To: <20160316164850.2c3420db@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: mjrosato@linux.vnet.ibm.com, thuth@redhat.com, pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru, armbru@redhat.com, agraf@suse.de, qemu-devel@nongnu.org, borntraeger@de.ibm.com, qemu-ppc@nongnu.org, Bharata B Rao , pbonzini@redhat.com, afaerber@suse.de, mdroth@linux.vnet.ibm.com --1hc8QtWIxzfIcV03 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2016 at 04:48:50PM +0100, Igor Mammedov wrote: > On Wed, 16 Mar 2016 09:18:03 +0530 > Bharata B Rao wrote: >=20 > > On Mon, Mar 14, 2016 at 10:47:28AM +0100, Igor Mammedov wrote: > > > On Fri, 11 Mar 2016 10:24:29 +0530 > > > Bharata B Rao wrote: > > > =20 > > > > Hi, > > > >=20 > > > > This is the next version of "Core based CPU hotplug for PowerPC sPA= PR" that > > > > was posted at > > > > https://lists.gnu.org/archive/html/qemu-ppc/2016-03/msg00081.html > > > >=20 > > > > device_add semantics > > > > -------------------- > > > > For -smp 16,sockets=3D1,cores=3D2,threads=3D8,maxcpus=3D32 > > > > (qemu) device_add spapr-cpu-core,id=3Dcore2,core=3D16,cpu_model=3Dh= ost[,threads=3D8] =20 > > > do you plan to allow user to hotplug different cpu_models? > > > If not it would be better to hide cpu_model from user > > > and set it from machine pre_plug handler. =20 > >=20 > > In my earlier implementations I derived cpu model from -cpu and threads= from > > -smp,threads=3D commandline options and never exposed them to device_add > > command. > >=20 > > Though we don't support heterogenous systems (different cpu models and/= or > > threads) now, it was felt that it should be easy enough to support such > > systems if required in future, that's how cpu_model and threads became > > options for device_add. > >=20 > > One of the things that David felt was missing from my earlier QMP query > > command (and which is true in your QMP query implementation also) is th= at > > we aren't exporting cpu_model at all, at least for not-yet-plugged core= s. > > So should we include that or let management figure that out since it > > would already know about the CPU model. > 1. > so since you are not planning supporting heterogeneous setup yet, > I'd suggest to refrain from making user to provide cpu_model at > device_add time. Instead make machine code to set it for cores it > creates before core.realize() (yet another use for pre_plug()). >=20 > That way mgmt doesn't have to figure out what cpu_model to set at > device_add time and doesn't have find out what property to use for it. Yes.. of course you could also do the same thing for nr_threads, so I'm wondering whether there's a good argument to keep one in pre_plug() and one in query-hotpluggable-cpus. > 2. > If you still insist on providing cpu_model property at > device_add time, you'd better extend QMP command query-hotpluggable-cpus > to provide it in 'props' list along with valid value. Yes, that's definitely true. > But I'd go with #1 as questions of using cpu_model-s vs QOM types and > discovery of mapping of cpu-model to QOM types is not clear yet > and need to be discussed further. Hm, I suppose so. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --1hc8QtWIxzfIcV03 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW6oD/AAoJEGw4ysog2bOSYNsP/A9Ybn5m+fRpXtytNgbpTDXF 6ztPbbQ7PDpm+W7iHtlOfaWIXplOVJva6BJqYr19OE3Fl47HD/jKQ878J0lUpLrd dOArv2rzfegCHGkxO37ytKbO5iFoL4lu1qoJb+d9pb8Ck4nV3aycXwnxm1ZWcJ5A caBQDYqAmtk3ccXlWegx25N6AtBMTBbv4MgD+xmxY5UMdQV5xFPUL955etMszE6I HaQHXbQiKHJMN4yBuzOS64TCAOWvC0qrkv64GIk0rnvBfvuumaGzlUE3yi7jUJ+B cfJPl/SiJsAwICjq8wO6IuEDuJeDuTr+bnKtScG0w4hb4t9BtHaWdIUegYuK4THu TKKJ8Efuah2CHbbAcv3A3ppnOwWdUu175XaglNPua/Fi6LkVwyDXKwAjmqKkOq+E 3HLdXfkE1gjmAYmfWvJOq0HvHANDAQGHKkfCos+PL3qTMVsYEYmhcyjeza1Rw/et U79KCsoHgkJ9Y/esX6K0A7nwdjOaaBC1j95FAatooCmBJAHlBKUZKVPeoWazMSxa 8ZydVjMQVNqfkfZoh4kgW3bz493XGrbiUx2HWMSg9bLUHPhFqmsubjwKu3+BNej7 U77Pa62nstVWNFWnc+EjCQ9WxhFHUJd8i/hdu4Kmk7i8DODVKsQ+nRxkaAIVaGKD XsYPhnKQLDsNI7yDtEfx =b++M -----END PGP SIGNATURE----- --1hc8QtWIxzfIcV03--