From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXsiY-0003NH-TT for qemu-devel@nongnu.org; Mon, 22 Feb 2016 10:48:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXsiW-00073j-7P for qemu-devel@nongnu.org; Mon, 22 Feb 2016 10:48:10 -0500 Received: from mx2.suse.de ([195.135.220.15]:49865) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXsiV-00073a-Tp for qemu-devel@nongnu.org; Mon, 22 Feb 2016 10:48:08 -0500 References: <1456117285-22273-1-git-send-email-bharata@linux.vnet.ibm.com> <1456117285-22273-5-git-send-email-bharata@linux.vnet.ibm.com> <56CAAE58.3060705@suse.de> <20160222080507.GF9382@in.ibm.com> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Message-ID: <56CB2DB5.20103@suse.de> Date: Mon, 22 Feb 2016 16:48:05 +0100 MIME-Version: 1.0 In-Reply-To: <20160222080507.GF9382@in.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH v0 4/8] spapr: Introduce CPU core device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bharata@linux.vnet.ibm.com Cc: ehabkost@redhat.com, aik@ozlabs.ru, armbru@redhat.com, agraf@suse.de, qemu-devel@nongnu.org, pbonzini@redhat.com, imammedo@redhat.com, david@gibson.dropbear.id.au Am 22.02.2016 um 09:05 schrieb Bharata B Rao: > On Mon, Feb 22, 2016 at 07:44:40AM +0100, Andreas F=E4rber wrote: >> Am 22.02.2016 um 06:01 schrieb Bharata B Rao: >>> sPAPR CPU core device is a container of CPU thread devices. CPU hotpl= ug is >>> performed in the granularity of CPU core device by setting the "reali= zed" >>> property of this device to "true". When hotplugged, CPU core creates = CPU >>> thread devices. >>> >>> TODO: Right now allows for only homogeneous configurations as we depe= nd >>> on global smp_threads and machine->cpu_model. >>> >>> Signed-off-by: Bharata B Rao >>> --- >>> hw/ppc/Makefile.objs | 1 + >>> hw/ppc/spapr_cpu_package.c | 50 ++++++++++++++++++++++++++++= ++++++++++ >>> include/hw/ppc/spapr_cpu_package.h | 26 ++++++++++++++++++++ >>> 3 files changed, 77 insertions(+) >>> create mode 100644 hw/ppc/spapr_cpu_package.c >>> create mode 100644 include/hw/ppc/spapr_cpu_package.h >>> >>> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs >>> index c1ffc77..3000982 100644 >>> --- a/hw/ppc/Makefile.objs >>> +++ b/hw/ppc/Makefile.objs >>> @@ -4,6 +4,7 @@ obj-y +=3D ppc.o ppc_booke.o >>> obj-$(CONFIG_PSERIES) +=3D spapr.o spapr_vio.o spapr_events.o >>> obj-$(CONFIG_PSERIES) +=3D spapr_hcall.o spapr_iommu.o spapr_rtas.o >>> obj-$(CONFIG_PSERIES) +=3D spapr_pci.o spapr_rtc.o spapr_drc.o spapr= _rng.o >>> +obj-$(CONFIG_PSERIES) +=3D spapr_cpu_package.o >>> ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy) >>> obj-y +=3D spapr_pci_vfio.o >>> endif >>> diff --git a/hw/ppc/spapr_cpu_package.c b/hw/ppc/spapr_cpu_package.c >>> new file mode 100644 >>> index 0000000..3120a16 >>> --- /dev/null >>> +++ b/hw/ppc/spapr_cpu_package.c >>> @@ -0,0 +1,50 @@ >>> +/* >>> + * sPAPR CPU package device, acts as container of CPU thread devices= . >>> + * >>> + * Copyright (C) 2016 Bharata B Rao >>> + * >>> + * This work is licensed under the terms of the GNU GPL, version 2 o= r later. >>> + * See the COPYING file in the top-level directory. >>> + */ >>> +#include "hw/cpu/package.h" >>> +#include "hw/ppc/spapr_cpu_package.h" >>> +#include "hw/boards.h" >>> +#include >>> +#include "qemu/error-report.h" >>> + >>> +static void spapr_cpu_package_instance_init(Object *obj) >>> +{ >>> + int i; >>> + CPUState *cpu; >>> + MachineState *machine =3D MACHINE(qdev_get_machine()); >>> + sPAPRCPUPackage *package =3D SPAPR_CPU_PACKAGE(obj); >>> + >>> + /* Create as many CPU threads as specified in the topology */ >>> + for (i =3D 0; i < smp_threads; i++) { >>> + cpu =3D cpu_generic_init(machine->cpu_type, machine->cpu_mod= el); >> >> No, no, no. This is horribly violating QOM design. >> >> Please compare the x86 RFC. >=20 > Are you referring to the in-place initialization of child objects like > that you did in socket based x86 hotplug RFC last year ? Yes, in-place object_initialize() is one of two options. The other is using object_initialize() with g_try_malloc0() from property setters, like Alexey did for xics I think. But mainly the idea is to not bend your QOM types to reuse the legacy glue but to use true QOM concepts in the design of those new objects. If there is some big hurdle I'm missing, please say so openly. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N=FC= rnberg)