From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: mjrosato@linux.vnet.ibm.com, thuth@redhat.com,
pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru,
Bharata B Rao <bharata@linux.vnet.ibm.com>,
armbru@redhat.com, agraf@suse.de, borntraeger@de.ibm.com,
qemu-ppc@nongnu.org, pbonzini@redhat.com, imammedo@redhat.com,
mdroth@linux.vnet.ibm.com, afaerber@suse.de,
david@gibson.dropbear.id.au
Subject: [Qemu-devel] [RFC PATCH v1 00/10] Core based CPU hotplug for PowerPC sPAPR
Date: Fri, 4 Mar 2016 12:24:11 +0530 [thread overview]
Message-ID: <1457074461-14285-1-git-send-email-bharata@linux.vnet.ibm.com> (raw)
Hi,
This is the next version of "Core based CPU hotplug for PowerPC sPAPR" that
was posted at
https://lists.gnu.org/archive/html/qemu-ppc/2016-02/msg00286.html
Here is a quick summary on how this approach is different from the
previous approaches that I have been pursuing with the last one being
v7 that posted here:
https://lists.gnu.org/archive/html/qemu-ppc/2016-01/msg00477.html
- Earlier approaches used an independent PowerPC specific core device while
this approach uses an sPAPR specific core device that is derived from
generic core device.
- The earlier approach didn't have the notion of where the boot time as
well as hot-plugged cores would sit. In this approach QOM links are
created from machine object to all possible core objects. While the
links are set for boot time cores during machine init, the same is done
for hotplugged cores at hotplug time. The name of this link property
is standardized as "core[N]" since these links link the machine object
with core devices. The link name ("core[N]") is used with core device's
"slot" property to identify the QOM link to set for this core.
(qemu) device_add spapr-cpu-core,id=core2,nr_threads=8,cpu_model=host,slot=core[2]
- The ealier approach created threads from instance_init of the core object
using a modified cpu_generic_init() routine. It used smp_threads and
MachineState->cpu_model globals. In the current approach, nr_threads and
cpu_model are obtained as properties and threads are created from
property setters. The thread objects are allocated as part of core
device and object_initialize() is used to initialize them.
Some open questions remain:
- Does this device_add semantics look ok ?
(qemu) device_add spapr-cpu-core,id=core2,nr_threads=8,cpu_model=host,slot=core[2]
- Is there need for machine to core object links ? If not, what would
determine the slot/location of the core device ?
- How to fit this with CPUSlotProperties HMP interface that Igor is
working on ?
This version has the following changes:
- Dropped QMP and HMP enumeration patches for now since it isn't clear
if the approach I took would be preferrable by all archs. Will wait
and see how Igor's patches evolve here.
- Added the following pre-req patches to support CPU removal:
exec: Remove cpu from cpus list during cpu_exec_exit()
exec: Do vmstate unregistration from cpu_exec_exit()
cpu: Reclaim vCPU objects
cpu: Add a sync version of cpu_remove()
- Added sPAPR CPU hot removal support
xics,xics_kvm: Handle CPU unplug correctly
spapr: CPU hot unplug support
- Moved up the "slot" property into abstract cpu-core device.
- Recover when thread creation fails (spapr_cpu_core_create_threads())
- cpu_model property in spapr-cpu-core deivce is now tracked using
ObjectClass pointer instead of string.
- Fail topologies with incomplete cores from within sPAPR's machine init.
- Fixes in spapr-cpu-core object creation from machine init to create
only boottime CPUs.
- Moved board specific wiring code for CPU threads (spapr_cpu_init)
into core's realize method to be called after each thread's realization.
- No specific action under TYPE_CPU in ->plug() handler either for hotplug
or hot removal.
- Moved all core related CPU hotplug routines into spapr_cpu_core.c where
it truly belongs.
- Setting of NUMA node for hotplugged CPUs moved to spapr_cpu_init()).
- Compared to previous implementation of hot removal that was part of
different series earlier, this implementation moves all core removal
logic into spapr_cpu_core.c.
- Some minor cleanups like use of g_new0 instead of g_malloc0 etc.
This patchset is present at:
https://github.com/bharata/qemu/commits/spapr-cpu-core
Bharata B Rao (9):
exec: Remove cpu from cpus list during cpu_exec_exit()
exec: Do vmstate unregistration from cpu_exec_exit()
cpu: Add a sync version of cpu_remove()
cpu: Abstract CPU core type
spapr: CPU core device
spapr: Represent boot CPUs as spapr-cpu-core devices
spapr: CPU hotplug support
xics,xics_kvm: Handle CPU unplug correctly
spapr: CPU hot unplug support
Gu Zheng (1):
cpu: Reclaim vCPU objects
cpus.c | 50 ++++++
exec.c | 44 ++++-
hw/cpu/Makefile.objs | 1 +
hw/cpu/core.c | 44 +++++
hw/intc/xics.c | 14 ++
hw/intc/xics_kvm.c | 8 +-
hw/ppc/Makefile.objs | 1 +
hw/ppc/spapr.c | 174 +++++++++++++++++--
hw/ppc/spapr_cpu_core.c | 361 ++++++++++++++++++++++++++++++++++++++++
hw/ppc/spapr_events.c | 3 +
hw/ppc/spapr_rtas.c | 24 +++
include/hw/cpu/core.h | 30 ++++
include/hw/ppc/spapr.h | 9 +
include/hw/ppc/spapr_cpu_core.h | 42 +++++
include/hw/ppc/xics.h | 1 +
include/qom/cpu.h | 18 ++
include/sysemu/kvm.h | 1 +
kvm-all.c | 57 ++++++-
kvm-stub.c | 5 +
19 files changed, 862 insertions(+), 25 deletions(-)
create mode 100644 hw/cpu/core.c
create mode 100644 hw/ppc/spapr_cpu_core.c
create mode 100644 include/hw/cpu/core.h
create mode 100644 include/hw/ppc/spapr_cpu_core.h
--
2.1.0
next reply other threads:[~2016-03-04 6:54 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 6:54 Bharata B Rao [this message]
2016-03-04 6:54 ` [Qemu-devel] [RFC PATCH v1 01/10] exec: Remove cpu from cpus list during cpu_exec_exit() Bharata B Rao
2016-03-07 2:41 ` David Gibson
2016-03-07 16:23 ` Thomas Huth
2016-03-09 7:57 ` Bharata B Rao
2016-03-09 8:13 ` Thomas Huth
2016-03-04 6:54 ` [Qemu-devel] [RFC PATCH v1 02/10] exec: Do vmstate unregistration from cpu_exec_exit() Bharata B Rao
2016-03-07 2:51 ` David Gibson
2016-03-07 3:38 ` Bharata B Rao
2016-03-04 6:54 ` [Qemu-devel] [RFC PATCH v1 03/10] cpu: Reclaim vCPU objects Bharata B Rao
2016-03-07 19:05 ` Thomas Huth
2016-03-09 4:59 ` Bharata B Rao
2016-03-04 6:54 ` [Qemu-devel] [RFC PATCH v1 04/10] cpu: Add a sync version of cpu_remove() Bharata B Rao
2016-03-04 6:54 ` [Qemu-devel] [RFC PATCH v1 05/10] cpu: Abstract CPU core type Bharata B Rao
2016-03-04 10:38 ` Igor Mammedov
2016-03-04 11:02 ` Bharata B Rao
2016-03-04 18:07 ` Igor Mammedov
2016-03-07 3:36 ` David Gibson
2016-03-07 8:31 ` Bharata B Rao
2016-03-07 10:40 ` Igor Mammedov
2016-03-08 3:57 ` David Gibson
2016-03-08 9:11 ` Igor Mammedov
2016-03-09 2:55 ` David Gibson
2016-03-09 10:32 ` Igor Mammedov
2016-03-10 5:04 ` David Gibson
2016-03-10 9:35 ` Igor Mammedov
2016-03-07 10:29 ` Igor Mammedov
2016-03-08 4:26 ` David Gibson
2016-03-09 10:40 ` Igor Mammedov
2016-03-09 23:42 ` David Gibson
2016-03-10 9:39 ` Igor Mammedov
2016-03-04 6:54 ` [Qemu-devel] [RFC PATCH v1 06/10] spapr: CPU core device Bharata B Rao
2016-03-04 6:54 ` [Qemu-devel] [RFC PATCH v1 07/10] spapr: Represent boot CPUs as spapr-cpu-core devices Bharata B Rao
2016-03-07 3:45 ` David Gibson
2016-03-09 8:01 ` Bharata B Rao
2016-03-04 6:54 ` [Qemu-devel] [RFC PATCH v1 08/10] spapr: CPU hotplug support Bharata B Rao
2016-03-07 3:49 ` David Gibson
2016-03-07 6:29 ` Bharata B Rao
2016-03-07 11:01 ` Igor Mammedov
2016-03-08 4:27 ` David Gibson
2016-03-08 9:37 ` Igor Mammedov
2016-03-09 2:58 ` David Gibson
2016-03-09 7:53 ` Bharata B Rao
2016-03-09 12:53 ` Igor Mammedov
2016-03-09 10:48 ` Igor Mammedov
2016-03-04 6:54 ` [Qemu-devel] [RFC PATCH v1 09/10] xics, xics_kvm: Handle CPU unplug correctly Bharata B Rao
2016-03-04 6:54 ` [Qemu-devel] [RFC PATCH v1 10/10] spapr: CPU hot unplug support Bharata B Rao
2016-03-04 10:57 ` [Qemu-devel] [RFC PATCH v1 00/10] Core based CPU hotplug for PowerPC sPAPR Igor Mammedov
2016-03-07 3:53 ` David Gibson
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=1457074461-14285-1-git-send-email-bharata@linux.vnet.ibm.com \
--to=bharata@linux.vnet.ibm.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=armbru@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mjrosato@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pkrempa@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=thuth@redhat.com \
/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).