From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahqxW-0000wR-Pf for qemu-devel@nongnu.org; Sun, 20 Mar 2016 23:56:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ahqxV-0007pu-Ge for qemu-devel@nongnu.org; Sun, 20 Mar 2016 23:56:50 -0400 Date: Mon, 21 Mar 2016 14:57:53 +1100 From: David Gibson Message-ID: <20160321035753.GE23586@voom.redhat.com> 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> <20160317100343.GT9032@voom> <20160318032932.GA20937@in.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vmttodhTwj0NAgWp" Content-Disposition: inline In-Reply-To: <20160318032932.GA20937@in.ibm.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: Bharata B Rao 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, pbonzini@redhat.com, Igor Mammedov , afaerber@suse.de, mdroth@linux.vnet.ibm.com --vmttodhTwj0NAgWp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 18, 2016 at 08:59:32AM +0530, Bharata B Rao wrote: > On Thu, Mar 17, 2016 at 09:03:43PM +1100, David Gibson wrote: > > 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= sPAPR" that > > > > > > was posted at > > > > > > https://lists.gnu.org/archive/html/qemu-ppc/2016-03/msg00081.ht= ml > > > > > >=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= =3Dhost[,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 thr= eads from > > > > -smp,threads=3D commandline options and never exposed them to devic= e_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 bec= ame > > > > options for device_add. > > > >=20 > > > > One of the things that David felt was missing from my earlier QMP q= uery > > > > command (and which is true in your QMP query implementation also) i= s that > > > > we aren't exporting cpu_model at all, at least for not-yet-plugged = cores. > > > > 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. > >=20 > > 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. >=20 > Right, so what should be the way forward ? Should we keep cpu_model=3D and > threads=3D options with device_add or just threads=3D or neither ? I'm inclined to keep them both in device_add - I like the idea of having an example on day 0 of advertising extra properties (beyond nr_threads and location) to set from query-hotpluggable-cpus. But, I'd probably change my mind if Igor or someone has a stronger opinion. If we advertise cpu_model, however, it should probably be changed to cpu thread class name, since IIUC that's an existing advertised part of the QOM interface, but cpu_model isn't. --=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 --vmttodhTwj0NAgWp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW73FBAAoJEGw4ysog2bOSXqQP+gN+UKcG1pNxqVqw5O9mxv8E DzJjP3JqqNfcTMlzBck/PE3sg0U07mBMPJzEVpl9v5J03IvLbx2HQ1rrJzi869vG hWL/W+h63fIOGfmzt+iFd2fTl0p3kzMCcJOvrMn1fRxEVzG8rBdhbNWcquMIcosf 7rEqgETwifN3LOszS+/evAi4yJfT6GOjB61mrfn3sSfGkRxdT/OUt+kXkPZRxqWU KuwldWWOkolQZNZuLdOL90niH+0wEHoX+fqdMTTLZdvOn+iEkH2io5HEwXFa3eA+ ilD3tAwiDMDvy0aPD08gmKJa7NvY1UU+L+kNX27T+vud6VJ7lirUwHOCcmOufvnY m4QyAH16tn/Yx/63ayjn/7JUnLcPQJkQRoxQfmj6LjcTQfW/hyqmWS5C93Tjpp2E 7E2Sp4Z7u9EUm/8KZr1TC7pycTIkmdEz0ElN4+F0bAV228xhTPwWusYXiyd/fofY D+IAH5f7Xl7Xv4XQHdUQIbpJouw7yoOiK7x898K6fx32LoTN+Cd37vRm5rV+SzXP kw/mrgoIMuj6v3jOu/fqPJc2m41+Lor7zrs1UHGGhXlWABr7yZBVfHRELsVNKp1p r7mmRkBvCTE++FXj/bWo5+qShjDWEpfJlpD0KekIJkWR8sa1sPmnJmVEHxks9dmB 9WrxahECYDo+UR6w/YgX =N1zv -----END PGP SIGNATURE----- --vmttodhTwj0NAgWp--