From: "Andreas Färber" <afaerber@suse.de>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: ehabkost@redhat.com, aik@ozlabs.ru, armbru@redhat.com,
Bharata B Rao <bharata@linux.vnet.ibm.com>,
agraf@suse.de, qemu-devel@nongnu.org, pbonzini@redhat.com,
imammedo@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH v0 4/8] spapr: Introduce CPU core device
Date: Mon, 22 Feb 2016 16:58:46 +0100 [thread overview]
Message-ID: <56CB3036.7050900@suse.de> (raw)
In-Reply-To: <20160222074758.GJ2808@voom.fritz.box>
Am 22.02.2016 um 08:47 schrieb David Gibson:
> On Mon, Feb 22, 2016 at 07:44:40AM +0100, Andreas Färber wrote:
>> Am 22.02.2016 um 06:01 schrieb Bharata B Rao:
>>> sPAPR CPU core device is a container of CPU thread devices. CPU hotplug is
>>> performed in the granularity of CPU core device by setting the "realized"
>>> property of this device to "true". When hotplugged, CPU core creates CPU
>>> thread devices.
>>>
>>> TODO: Right now allows for only homogeneous configurations as we depend
>>> on global smp_threads and machine->cpu_model.
>>>
>>> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
>>> ---
>>> 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 += ppc.o ppc_booke.o
>>> obj-$(CONFIG_PSERIES) += spapr.o spapr_vio.o spapr_events.o
>>> obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
>>> obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o spapr_rng.o
>>> +obj-$(CONFIG_PSERIES) += spapr_cpu_package.o
>>> ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
>>> obj-y += 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 <bharata@linux.vnet.ibm.com>
>>> + *
>>> + * This work is licensed under the terms of the GNU GPL, version 2 or 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 <sysemu/cpus.h>
>>> +#include "qemu/error-report.h"
>>> +
>>> +static void spapr_cpu_package_instance_init(Object *obj)
>>> +{
>>> + int i;
>>> + CPUState *cpu;
>>> + MachineState *machine = MACHINE(qdev_get_machine());
>>> + sPAPRCPUPackage *package = SPAPR_CPU_PACKAGE(obj);
>>> +
>>> + /* Create as many CPU threads as specified in the topology */
>>> + for (i = 0; i < smp_threads; i++) {
>>> + cpu = cpu_generic_init(machine->cpu_type, machine->cpu_model);
>>
>> No, no, no. This is horribly violating QOM design.
>
> Ok.. why? There does not, to me, seem to be any remotely easily
> discoverable means of finding out what QOM design principles are.
>
> It also would have been nice if you weighed in on my RFC this code is
> based on.
It would've been nice had you joined our KVM call prompted by _your_
suggestions (which again you could've discussed at KVM Forum where I had
a session specifically for discussing this topic), but you didn't.
I did discuss several aspects on the call and in the recorded session
and will not write it by email again. Feel free to put it on the call
agenda again.
I told Bharata that you can't have a base type that suddenly mutates its
topology, therefore we discussed the possibility of having a QOM
_interface_, not a base type as apparently done here. We deliberately do
not have multi-inheritence in QOM; there's not just ppc in the world.
My time for reading list mails is limited. Make it easy for me to
understand what the difference is between your package and my core and
why instead of reusing my posted cpu-core type you need to propose your
own cpu-package type. In one point you are right, we keep going in
circles and sometimes backwards rather than forward here.
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
next prev parent reply other threads:[~2016-02-22 15:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 5:01 [Qemu-devel] [RFC PATCH v0 0/8] cpu-package hotplug Bharata B Rao
2016-02-22 5:01 ` [Qemu-devel] [RFC PATCH v0 1/8] cpu: Store CPU typename in MachineState Bharata B Rao
2016-02-22 8:04 ` David Gibson
2016-02-22 5:01 ` [Qemu-devel] [RFC PATCH v0 2/8] cpu: Don't realize CPU from cpu_generic_init() Bharata B Rao
2016-02-22 5:01 ` [Qemu-devel] [RFC PATCH v0 3/8] cpu: CPU package abstract device Bharata B Rao
2016-02-22 5:01 ` [Qemu-devel] [RFC PATCH v0 4/8] spapr: Introduce CPU core device Bharata B Rao
2016-02-22 6:44 ` Andreas Färber
2016-02-22 7:47 ` David Gibson
2016-02-22 15:58 ` Andreas Färber [this message]
2016-02-22 23:24 ` David Gibson
2016-02-22 8:05 ` Bharata B Rao
2016-02-22 15:48 ` Andreas Färber
2016-02-22 5:01 ` [Qemu-devel] [RFC PATCH v0 5/8] spapr: Convert boot CPUs into CPU core device initialization Bharata B Rao
2016-02-22 5:01 ` [Qemu-devel] [RFC PATCH v0 6/8] spapr: CPU hotplug support Bharata B Rao
2016-02-22 5:01 ` [Qemu-devel] [RFC PATCH v0 7/8] qmp: Implement query cpu-packages Bharata B Rao
2016-02-22 16:49 ` Eric Blake
2016-02-23 8:37 ` Igor Mammedov
2016-02-22 5:01 ` [Qemu-devel] [RFC PATCH v0 8/8] hmp: Implement 'info cpu-slots' Bharata B Rao
2016-02-22 5:10 ` [Qemu-devel] [RFC PATCH v0 0/8] cpu-package hotplug Bharata B Rao
2016-02-22 15:32 ` Andreas Färber
2016-02-22 23:28 ` David Gibson
2016-02-23 6:11 ` Bharata B Rao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56CB3036.7050900@suse.de \
--to=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=armbru@redhat.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).