qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Igor Mammedov <imammedo@redhat.com>
Cc: mjrosato@linux.vnet.ibm.com, thuth@redhat.com,
	pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru,
	armbru@redhat.com, agraf@suse.de, qemu-devel@nongnu.org,
	borntraeger@de.ibm.com, qemu-ppc@nongnu.org,
	Bharata B Rao <bharata@linux.vnet.ibm.com>,
	pbonzini@redhat.com, afaerber@suse.de, mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [RFC PATCH v1 00/10] Core based CPU hotplug for PowerPC sPAPR
Date: Mon, 7 Mar 2016 14:53:20 +1100	[thread overview]
Message-ID: <20160307035320.GG22546@voom.fritz.box> (raw)
In-Reply-To: <20160304115718.1af31ee0@nial.brq.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 7204 bytes --]

On Fri, Mar 04, 2016 at 11:57:18AM +0100, Igor Mammedov wrote:
> On Fri,  4 Mar 2016 12:24:11 +0530
> Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:
> 
> > 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]
> looks fine to me, only I'd do following changes:
> s/nr_threads/threads/
> s/slot/core/ and make it numeric property
> 
> > - Is there need for machine to core object links ? If not, what would
> >   determine the slot/location of the core device ?
> I'd drop links altogether for this series as they were a part of an attempt
> to implement QOM based introspection interface, which is not must have
> provided QMP interface would provide all necessary for hotplug information
> which links aren't capable of to do.

Yeah, I tend to agree.

> Back in the days Anthony suggested that we 'might' use links to implement
> hotplug because there wasn't any other infrastructure hotplug
> infrastructure for bus-less devices. But now we have HOTPLUG_HANDLER
> interface that obsoleted, what links were supposed to handle at
> link set time hooks.
> 
> But somehow we stuck on links idea, though their initial role in hotplug
> were obsoleted and we still trying to fit them in design where
> they are not really necessary.
> 
> > - How to fit this with CPUSlotProperties HMP interface that Igor is
> >   working on ?
> I'll try to re-factor QMP interface RFC on top of this series
> so it would be easier for you to review it wrt spapr.
> 
> 
> > 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
> > 
> 
> 

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      reply	other threads:[~2016-03-07  3:53 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04  6:54 [Qemu-devel] [RFC PATCH v1 00/10] Core based CPU hotplug for PowerPC sPAPR Bharata B Rao
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 [this message]

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=20160307035320.GG22546@voom.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=armbru@redhat.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --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).