From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad8uz-0000Zx-PJ for qemu-devel@nongnu.org; Mon, 07 Mar 2016 23:06:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad8ux-0002zh-Vj for qemu-devel@nongnu.org; Mon, 07 Mar 2016 23:06:45 -0500 Date: Tue, 8 Mar 2016 14:57:10 +1100 From: David Gibson Message-ID: <20160308035710.GU22546@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> <20160307083155.GA7164@in.ibm.com> <20160307114011.20456e8c@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XSEVMyPRvc8xgDhM" Content-Disposition: inline In-Reply-To: <20160307114011.20456e8c@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 --XSEVMyPRvc8xgDhM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2016 at 11:40:11AM +0100, Igor Mammedov wrote: > On Mon, 7 Mar 2016 14:01:55 +0530 > Bharata B Rao wrote: >=20 > > On Mon, Mar 07, 2016 at 02:36:55PM +1100, David Gibson wrote: > > > On Fri, Mar 04, 2016 at 07:07:20PM +0100, Igor Mammedov wrote: =20 > > > > On Fri, 4 Mar 2016 16:32:53 +0530 > > > > Bharata B Rao wrote: > > > > =20 > > > > > On Fri, Mar 04, 2016 at 11:38:45AM +0100, Igor Mammedov wrote: = =20 > > > > > > On Fri, 4 Mar 2016 12:24:16 +0530 > > > > > > Bharata B Rao wrote: > > > > > > =20 > > > > > > > Add an abstract CPU core type that could be used by machines = that want > > > > > > > to define and hotplug CPUs in core granularity. > > > > > > >=20 > > > > > > > Signed-off-by: Bharata B Rao > > > > > > > --- > > > > > > > hw/cpu/Makefile.objs | 1 + > > > > > > > hw/cpu/core.c | 44 +++++++++++++++++++++++++++++++++= +++++++++++ > > > > > > > include/hw/cpu/core.h | 30 ++++++++++++++++++++++++++++++ > > > > > > > 3 files changed, 75 insertions(+) > > > > > > > create mode 100644 hw/cpu/core.c > > > > > > > create mode 100644 include/hw/cpu/core.h > > > > > > >=20 > > > > > > > diff --git a/hw/cpu/Makefile.objs b/hw/cpu/Makefile.objs > > > > > > > index 0954a18..942a4bb 100644 > > > > > > > --- a/hw/cpu/Makefile.objs > > > > > > > +++ b/hw/cpu/Makefile.objs > > > > > > > @@ -2,4 +2,5 @@ obj-$(CONFIG_ARM11MPCORE) +=3D arm11mpcore.o > > > > > > > obj-$(CONFIG_REALVIEW) +=3D realview_mpcore.o > > > > > > > obj-$(CONFIG_A9MPCORE) +=3D a9mpcore.o > > > > > > > obj-$(CONFIG_A15MPCORE) +=3D a15mpcore.o > > > > > > > +obj-y +=3D core.o > > > > > > > =20 > > > > > > > diff --git a/hw/cpu/core.c b/hw/cpu/core.c > > > > > > > new file mode 100644 > > > > > > > index 0000000..d8caf37 > > > > > > > --- /dev/null > > > > > > > +++ b/hw/cpu/core.c > > > > > > > @@ -0,0 +1,44 @@ > > > > > > > +/* > > > > > > > + * CPU core abstract device > > > > > > > + * > > > > > > > + * Copyright (C) 2016 Bharata B Rao > > > > > > > + * > > > > > > > + * This work is licensed under the terms of the GNU GPL, ver= sion 2 or later. > > > > > > > + * See the COPYING file in the top-level directory. > > > > > > > + */ > > > > > > > +#include "hw/cpu/core.h" > > > > > > > + > > > > > > > +static char *core_prop_get_slot(Object *obj, Error **errp) > > > > > > > +{ > > > > > > > + CPUCore *core =3D CPU_CORE(obj); > > > > > > > + > > > > > > > + return g_strdup(core->slot); > > > > > > > +} > > > > > > > + > > > > > > > +static void core_prop_set_slot(Object *obj, const char *val,= Error **errp) > > > > > > > +{ > > > > > > > + CPUCore *core =3D CPU_CORE(obj); > > > > > > > + > > > > > > > + core->slot =3D g_strdup(val); > > > > > > > +} > > > > > > > + > > > > > > > +static void cpu_core_instance_init(Object *obj) > > > > > > > +{ > > > > > > > + object_property_add_str(obj, "slot", core_prop_get_slot,= core_prop_set_slot, > > > > > > > + NULL); > > > > > > > +} > > > > > > > + > > > > > > > +static const TypeInfo cpu_core_type_info =3D { > > > > > > > + .name =3D TYPE_CPU_CORE, > > > > > > > + .parent =3D TYPE_DEVICE, > > > > > > > + .abstract =3D true, > > > > > > > + .instance_size =3D sizeof(CPUCore), > > > > > > > + .instance_init =3D cpu_core_instance_init, > > > > > > > +}; > > > > > > > + > > > > > > > +static void cpu_core_register_types(void) > > > > > > > +{ > > > > > > > + type_register_static(&cpu_core_type_info); > > > > > > > +} > > > > > > > + > > > > > > > +type_init(cpu_core_register_types) > > > > > > > diff --git a/include/hw/cpu/core.h b/include/hw/cpu/core.h > > > > > > > new file mode 100644 > > > > > > > index 0000000..2daa724 > > > > > > > --- /dev/null > > > > > > > +++ b/include/hw/cpu/core.h > > > > > > > @@ -0,0 +1,30 @@ > > > > > > > +/* > > > > > > > + * CPU core abstract device > > > > > > > + * > > > > > > > + * Copyright (C) 2016 Bharata B Rao > > > > > > > + * > > > > > > > + * This work is licensed under the terms of the GNU GPL, ver= sion 2 or later. > > > > > > > + * See the COPYING file in the top-level directory. > > > > > > > + */ > > > > > > > +#ifndef HW_CPU_CORE_H > > > > > > > +#define HW_CPU_CORE_H > > > > > > > + > > > > > > > +#include "qemu/osdep.h" > > > > > > > +#include "hw/qdev.h" > > > > > > > + > > > > > > > +#define TYPE_CPU_CORE "cpu-core" > > > > > > > + > > > > > > > +#define CPU_CORE(obj) \ > > > > > > > + OBJECT_CHECK(CPUCore, (obj), TYPE_CPU_CORE) > > > > > > > + > > > > > > > +typedef struct CPUCore { > > > > > > > + /*< private >*/ > > > > > > > + DeviceState parent_obj; > > > > > > > + > > > > > > > + /*< public >*/ > > > > > > > + char *slot; > > > > > > > +} CPUCore; > > > > > > > + > > > > > > > +#define CPU_CORE_SLOT_PROP "slot" =20 > > > > > > as it's generic property I'd rename to 'core' so it would fit a= ll users =20 > > > > >=20 > > > > > Ok. Also note that this is a string property which is associated = with the > > > > > link name (string) that we created from machine object to this co= re. I think > > > > > it would be ideal if this becomes an interger property in which = case it > > > > > becomes easier to feed the core location into your CPUSlotPropert= ies.core. =20 > > > > agreed, it should be core number. =20 > > >=20 > > > The slot stuff is continuing to confuse me a bit. I see that we need > > > some kind of "address" value, but how best to do it is not clear to > > > me. > > >=20 > > > Changing this to an integer sounds like it's probably a good idea. > > > I'm a bit wary of just calling it "core" though. Do all platforms > > > even necessarily have a core id? > > >=20 > > > I'm wondering if the addressing is something that needs to move the > > > the platform specific subtypes, while some other stuff can move to the > > > generic base type. > > > =20 > > > > > > on top of that I'd add numeric 'threads' property to base class= so > > > > > > all derived cores would inherit it. > > > > > >=20 > > > > > > Then as easy integration with -smp threads=3Dx, a machine could= push > > > > > > a global variable 'cpu-core.threads=3D[smp_threads]' which would > > > > > > 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 explic= itly > > > > > > 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 p= roperty > > > > > > 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 thread= creation > > > > > is dependent upon: nr_threads and cpu_model. If thread objects ca= n be > > > > > created at core realize time, then we don't have to resort to the= ugliness > > > > > of creating the threads from either of the property setters. I al= ways > > > > > assumed that we shouldn't be creating objects from realize, but i= f 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 done > > > > for failure path. =20 > > >=20 > > > Right, moving the "nr_threads" property to the base type seems like a > > > good idea to me. =20 > >=20 > > And we will also move the cpu_model property (now being tracked by > > an ObjectClass pointer) to the base type ? > I'm not sure that moving cpu_model to the base class is the right thing, > I'd keep it local to platform for now. I tend to agree, although I'm not sure that I could really explain why :/ > Could you have several spapr core types? One per CPU model? > That way you won't need to track cpu_model when using device_add. We could in theory, but it would be pretty inconvenient. Because this is a paravirt platform, there really can't be any core-level difference between them, and it would mean creating a fair batch of core types for the various minor POWER7 and POWER8 variants - and needing to update this whenever IBM makes a new version. I suspect it would also introduce more wrinkles in order to have a correct "spapr-core-host" type matching the "HOST" cpu thread type. Since KVM (HV) only supports the HOST thread type, that's a fairly big issue. --=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 --XSEVMyPRvc8xgDhM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW3k2WAAoJEGw4ysog2bOS5yQP/3rlFHSI0SSni12kh/HhwrQo j/R9h1BU9A0kKIl6l433kdLRVsKKVjIraDcAeQ/b76KsGGlpW9Pyg+e0OSnAtbPL GM+VXxEbJMWu9WSsETxuJOAj7pv+dRe9V05VUsH4GOrKq9pjBDvw83e3Zmkizh5C C2VwmrT4g0v/9cxPfjuJOH4Nvyx/zeZ9b1L9oiGsBBLP+Ejy3dgo55xNCZKW+/TU iVVrfmtCIpo9rsHAt0WXYhpsT1Mdht7PZd2rdyrlUN+uddwFkO9WQ3T26rdPKaDT nrsL+riKn3ppp2+Mw4pBE2WhLsghIJeUiqSjlBHMcoASNZ3filvGHax0FGyZvE3l E1SKZ6VfbVa16uDln1m0AN5TOsiQnJVJXVMMbtmd8s8WoxbX4TJFlJu/RYjy6DSr QXR+8YNvnMxs6CNWQP4zvHKVjbrVhvKF/bXZ3RPNAxzP5hVzBJSMMapAy6nufan3 K0JExdyjplQ4PWPmUIKSCBxO4Ady14zI1SE6D0QtPzXZZU4bGvl+dEwZFN3wwXT+ sVBlBxPxq139TsoFFrAj0qeWPutI8YaW5CxwVcpQDQaAtkGkku15V5K6ZtQIRN3Q 17utl57zSXu6GXf7PPd74Sc0lpXIPptXwLrcBah13DLpJZawBkPXZNh9TRI5dUfE GPRxyyiaX+hTetvmHqu/ =G/OU -----END PGP SIGNATURE----- --XSEVMyPRvc8xgDhM--