From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaZ9g-0000za-LP for qemu-devel@nongnu.org; Mon, 29 Feb 2016 20:31:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaZ9d-0003Dx-EJ for qemu-devel@nongnu.org; Mon, 29 Feb 2016 20:31:16 -0500 Date: Tue, 1 Mar 2016 12:21:27 +1100 From: David Gibson Message-ID: <20160301012127.GJ5427@voom.redhat.com> References: <1456417362-20652-1-git-send-email-bharata@linux.vnet.ibm.com> <1456417362-20652-3-git-send-email-bharata@linux.vnet.ibm.com> <20160226181339.5592.52630@loki> <20160229055018.GE5756@in.ibm.com> <20160229110316.02ab92d5@nial.brq.redhat.com> <20160229125525.GF5756@in.ibm.com> <20160229161525.566bee7b@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWOmaDnDlrCGjNh4" Content-Disposition: inline In-Reply-To: <20160229161525.566bee7b@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v0 2/6] spapr: CPU core device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: mjrosato@linux.vnet.ibm.com, agraf@suse.de, thuth@redhat.com, pkrempa@redhat.com, Michael Roth , aik@ozlabs.ru, qemu-devel@nongnu.org, armbru@redhat.com, borntraeger@de.ibm.com, qemu-ppc@nongnu.org, Bharata B Rao , pbonzini@redhat.com, afaerber@suse.de, ehabkost@redhat.com --pWOmaDnDlrCGjNh4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 29, 2016 at 04:15:25PM +0100, Igor Mammedov wrote: > On Mon, 29 Feb 2016 18:25:25 +0530 > Bharata B Rao wrote: > > On Mon, Feb 29, 2016 at 11:03:16AM +0100, Igor Mammedov wrote: > > > On Mon, 29 Feb 2016 11:20:19 +0530 > > > Bharata B Rao wrote: [snip] > > > > > "slot" seems intended to be a machine-agnostic of mapping device > > > > > types discovered from qmp_query_cpu_slots() to an appropriate > > > > > "bus" location, but here's it a field specific to TYPE_SPAPR_CPU_= CORE. > > > > > It seems like maybe TYPE_CPU_CORE is a better place, but then on > > > > > x86 I suppose it might be TYPE_CPU_SOCKET or something instead...= =20 > > > >=20 > > > > Correct. > > > > =20 > > > > >=20 > > > > > It almost seems like a TYPE_INTERFACE_SLOTABLE would be the > > > > > right approach, but I don't know how we could expose that as > > > > > a property. I guess it's somewhat implied that this "interface" > > > > > exists if qmp_query_cpu_slots() returns the type, but I wonder > > > > > if something a bit more formal should be modeled to make the > > > > > implementation requirements a bit clearer. > > > > >=20 > > > > > Maybe have TYPE_CPU_{CORE,SOCKET} classes have a get_slot/set_slot > > > > > class method, expose them via "slot" property, then have the > > > > > defaults generate "not implemented" errors? =20 > > > >=20 > > > > Yes makes sense. In fact David has often times said that generic > > > > properties/routines should be pushed to base class wherever possibl= e. > > > >=20 > > > > I didn't do that in this first iteration to keep the generic changes > > > > as minimum as possible, but yes slot should be a property of the > > > > base class of core or socket. =20 > > > Then what will happen to slot if there isn't any core/socket device > > > to query it, i.e. cpu hasn't been plugged in yet? > > > To me slot looks like a machine belonged feature. =20 > >=20 > > Yes slot belongs to the machine and it is represented by a link that > > is created b/n the machine object and the core object that sits in > > the slot. > >=20 > > In the context of this thread, slot is actually the slot name that > > identifies the machine slot which the core occupies or will occupy after > > hotplug. Thus slot name which is named slot here, it is a property of t= he > > core device. > >=20 > > (qemu) device_add spapr-cpu-core,slot=3Dcore[2] > > ^ > Is 'slot' a term used by SPAPR on real hardware? So.. PAPR is a para-virtualized interface, so it never appears on real hardware. But, no, "slot" is not a term used by PAPR. > I'd thought that it's 'core', that's why I suggested to use > 'core' for POWER as that matched real world concept, see > my other reply in "[RFC PATCH v0 4/6] spapr: CPU hotplug support" thread > of this series. I don't think it uses "core" either, I believe it uses just "cpu" but meaning a multi-thread core, rather than a single logical cpu thread. --=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 --pWOmaDnDlrCGjNh4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW1O6XAAoJEGw4ysog2bOSi2MQAM9NrRIb8ooa22+JZf4RAnXD 1eqf4x1GgN7fAe8lDEYydNOm8NnWzU2gaKsXbFwkIhzCqkZDUI9W/UKlq5mvKum3 XjDuOcmyxqPrgLnebvTaRsELW4hh6M6tyeknbyXJKZzXElWvHXUDVLIUwKVoYssZ cx55HvnJd00+XKRdRWb1n2XUxGLdTOG1cQHScj/NdXnU3Qveap1BoV+Csq89KQnH U/h3ZXPtmRxZ0nluEW1pubb+WAQbYQuTxoEdOLKqrPTzftXsqMxG79onw5dHpNPk 2tDtEuv+jglS/1iDzjzITZh6SvAh5sy3v32YT5KesYKW8E/Nlg53e5YMKYgLS3xV 1gWbwOur82nhzgB1mBFIr1o5liLcaq0D6wHz1PiQfiRb5tpDVUiMovUJBkIdCD4r Cd7225Q/F/oiMB//AKu9yXd+ay9IQiHnGZ893pph4MrPMfIR28TnsxKPOmTF2ekW SeVlobns/u9MTojK3OmhfsRqbTMbu3dXBEuZFgbiqfuBFfg2tg+DB1RzRRR+TuGQ bYufz8JSis+J0GG2jiUlP2bHZaHgh7FAQQNcy9Gj1ywd5KvpkLvloNKMV6vW1rZe KdvYDMJnb5Nkvp5GdSkhMngt44zOlcEAQMVXfS7UGdBv6k1r7Q8oicSF7Sup2hja dTGlDEryG5o+nCSJMnAr =RUf0 -----END PGP SIGNATURE----- --pWOmaDnDlrCGjNh4--