From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adnu8-0003sn-03 for qemu-devel@nongnu.org; Wed, 09 Mar 2016 18:52:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adnu6-0003nD-K5 for qemu-devel@nongnu.org; Wed, 09 Mar 2016 18:52:35 -0500 Date: Thu, 10 Mar 2016 10:42:26 +1100 From: David Gibson Message-ID: <20160309234226.GO22546@voom.fritz.box> References: <1457074461-14285-1-git-send-email-bharata@linux.vnet.ibm.com> <1457074461-14285-6-git-send-email-bharata@linux.vnet.ibm.com> <20160304113845.667c19ad@nial.brq.redhat.com> <20160304110253.GB5054@in.ibm.com> <20160304190720.4d64abc4@nial.brq.redhat.com> <20160307033655.GD22546@voom.fritz.box> <20160307112929.7578fa9b@nial.brq.redhat.com> <20160308042627.GV22546@voom.fritz.box> <20160309114053.58ebd9fe@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0Wg1ddIY7KV0vpwL" Content-Disposition: inline In-Reply-To: <20160309114053.58ebd9fe@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v1 05/10] cpu: Abstract CPU core type 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, qemu-devel@nongnu.org, agraf@suse.de, armbru@redhat.com, borntraeger@de.ibm.com, qemu-ppc@nongnu.org, Bharata B Rao , g@voom.fritz.box, pbonzini@redhat.com, mdroth@linux.vnet.ibm.com, afaerber@suse.de --0Wg1ddIY7KV0vpwL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 09, 2016 at 11:40:53AM +0100, Igor Mammedov wrote: > On Tue, 8 Mar 2016 15:26:27 +1100 > David Gibson wrote: > > On Mon, Mar 07, 2016 at 11:29:29AM +0100, Igor Mammedov wrote: > > > On Mon, 7 Mar 2016 14:36:55 +1100 > > > David Gibson wrote: [snip] > > > > > > > on top of that I'd add numeric 'threads' property to base cla= ss so > > > > > > > all derived cores would inherit it. > > > > > > >=20 > > > > > > > Then as easy integration with -smp threads=3Dx, a machine cou= ld push > > > > > > > a global variable 'cpu-core.threads=3D[smp_threads]' which wo= uld > > > > > > > make every created cpu-core object to have threads set > > > > > > > at instance_init() time (device_init). > > > > > > >=20 > > > > > > > That way user won't have to specify 'threads=3Dy' for every > > > > > > > device_add spapr-core,core=3Dx > > > > > > > as it will be taken from global property 'cpu-core.threads' > > > > > > > but if user wishes he/she still could override global by expl= icitly > > > > > > > providing thread property at device_add time: > > > > > > > device_add spapr-core,core=3Dx,threads=3Dy > > > > > > >=20 > > > > > > > wrt this series it would mean, instead of creating threads in= property > > > > > > > setter, delaying threads creation to core.realize() time, > > > > > > > but since realize is allowed to fail it should be fine do so.= =20 > > > > > >=20 > > > > > > Ok that would suit us as there are two properties on which thre= ad creation > > > > > > is dependent upon: nr_threads and cpu_model. If thread objects = can be > > > > > > created at core realize time, then we don't have to resort to t= he ugliness > > > > > > of creating the threads from either of the property setters. I = always > > > > > > assumed that we shouldn't be creating objects from realize, but= if that > > > > > > is fine, it is good. =20 > > > > > since realize is allowed to fail, it should be safe from hotplug = pov > > > > > to create internal objects there, as far as proper cleanups are d= one > > > > > for failure path. =20 > > > > =20 > > > [...] =20 > > > > I'm not clear from the above if you're also intending to move at le= ast > > > > the adding of the threads as child properties is supposed to go into > > > > the base type, =20 > > > I'm not sure that I've got question, could you please rephrase? =20 > >=20 > > So, it seems like we're agreed that moving the nr_threads property to > > the base type is a good idea. > >=20 > > My question is, do we also move the object_property_add_child() calls > > for each thread to the base type (possibly via a helper function or > > method the base type provides to derived types)? > I can't think of a reason to do so, > why can't subtype-core.realize() do it? It can, but I'm always suspicious of boilerplate stuff that every subtype *has* to do in order to work properly. > What would one gain creating callbacks and calling them from base class? Enforcing - or at least making as easy as possible - consistency in the child object naming. --=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 --0Wg1ddIY7KV0vpwL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW4LTiAAoJEGw4ysog2bOS06oP/1UkQpLegeudKXWr4w2RRZXH Km9HSibKA/i4WSo+Gsq47b6SrK+K2OU8aI51c8mqWNRDxKtFbAqjQAKZDwhjThoi 5Agy3Ver5QL3D+u+PX740Ba94rwYumWILhHQYbHVdy7li5Dd0hbvDKJuGAMOJ4px HAtArp8UUNarqu1hc45nzxZ81MaEd+eJNCDEEK8kVwwxXJyDStD1gWo5pF3sPzTM a8hWQ+VTTFpDia60u2FdRabEwRugyU/KvWxCpWWYIhLExjoVJ6YNcqLECwU12Oe6 bPzrevP3jbU2w9462Z6vKmzvkOYZNLCnoPz4g9GNpe0tknjNe3F0nWBx7tpJic9b 6FYRDN3s9UHmi4pSOMCm/JhOK5McZ097NygeIiPL7Ay/bDSlSTkyXeqqrt6FGccp vvOnXbvEg8u3iAaOtgAjUp5Wg/btt5ofSW8rDoVraR8zTCaYFSk2tOJuzNnoN7KH r5YK5serYXXxdpVTaFW3wuoxrjfGborcSA3Ye0IVKinlvH5KWfSOLdxDSPJgSykp kMoCiZb096Ndc91s+ESzLp5zPQjm8b9YftLF2xgcb6Fs9K1p+F8JdNowJ+6V046Z 7UU0XwfCizD+Yl5u5Z6HQaHoVi5/eMccQumSVyGKP/gAssoMGhEXSh0g1CcX69dq RK6k4SP+sqmtePx7ljS1 =ESpA -----END PGP SIGNATURE----- --0Wg1ddIY7KV0vpwL--