qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: mjrosato@linux.vnet.ibm.com, agraf@suse.de, thuth@redhat.com,
	pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru,
	qemu-devel@nongnu.org, armbru@redhat.com, borntraeger@de.ibm.com,
	qemu-ppc@nongnu.org, pbonzini@redhat.com,
	Igor Mammedov <imammedo@redhat.com>,
	afaerber@suse.de, mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [RFC PATCH v1 08/10] spapr: CPU hotplug support
Date: Wed, 9 Mar 2016 13:23:59 +0530	[thread overview]
Message-ID: <20160309075359.GD29692@in.ibm.com> (raw)
In-Reply-To: <20160309025853.GJ22546@voom.fritz.box>

On Wed, Mar 09, 2016 at 01:58:53PM +1100, David Gibson wrote:
> On Tue, Mar 08, 2016 at 10:37:08AM +0100, Igor Mammedov wrote:
> > On Tue, 8 Mar 2016 15:27:39 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> > 
> > > On Mon, Mar 07, 2016 at 11:59:42AM +0530, Bharata B Rao wrote:
> > > > On Mon, Mar 07, 2016 at 02:49:06PM +1100, David Gibson wrote:  
> > > > > On Fri, Mar 04, 2016 at 12:24:19PM +0530, Bharata B Rao wrote:  
> > > > > > Set up device tree entries for the hotplugged CPU core and use the
> > > > > > exising EPOW event infrastructure to send CPU hotplug notification to
> > > > > > the guest.
> > > > > > 
> > > > > > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > > > > > ---
> > > > > >  hw/ppc/spapr.c                  | 73 ++++++++++++++++++++++++++++++++++++++++-
> > > > > >  hw/ppc/spapr_cpu_core.c         | 60 +++++++++++++++++++++++++++++++++
> > > > > >  hw/ppc/spapr_events.c           |  3 ++
> > > > > >  hw/ppc/spapr_rtas.c             | 24 ++++++++++++++
> > > > > >  include/hw/ppc/spapr.h          |  4 +++
> > > > > >  include/hw/ppc/spapr_cpu_core.h |  2 ++
> > > > > >  6 files changed, 165 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > > > index 5acb612..6c4ac50 100644
> > > > > > --- a/hw/ppc/spapr.c
> > > > > > +++ b/hw/ppc/spapr.c
> > > > > > @@ -603,6 +603,18 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, int offset,
> > > > > >      size_t page_sizes_prop_size;
> > > > > >      uint32_t vcpus_per_socket = smp_threads * smp_cores;
> > > > > >      uint32_t pft_size_prop[] = {0, cpu_to_be32(spapr->htab_shift)};
> > > > > > +    sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(qdev_get_machine());
> > > > > > +    sPAPRDRConnector *drc;
> > > > > > +    sPAPRDRConnectorClass *drck;
> > > > > > +    int drc_index;
> > > > > > +
> > > > > > +    if (smc->dr_cpu_enabled) {
> > > > > > +        drc = spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_CPU, index);
> > > > > > +        g_assert(drc);
> > > > > > +        drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> > > > > > +        drc_index = drck->get_index(drc);
> > > > > > +        _FDT((fdt_setprop_cell(fdt, offset, "ibm,my-drc-index", drc_index)));
> > > > > > +    }
> > > > > >  
> > > > > >      /* Note: we keep CI large pages off for now because a 64K capable guest
> > > > > >       * provisioned with large pages might otherwise try to map a qemu
> > > > > > @@ -987,6 +999,16 @@ static void spapr_finalize_fdt(sPAPRMachineState *spapr,
> > > > > >          _FDT(spapr_drc_populate_dt(fdt, 0, NULL, SPAPR_DR_CONNECTOR_TYPE_LMB));
> > > > > >      }
> > > > > >  
> > > > > > +    if (smc->dr_cpu_enabled) {
> > > > > > +        int offset = fdt_path_offset(fdt, "/cpus");
> > > > > > +        ret = spapr_drc_populate_dt(fdt, offset, NULL,
> > > > > > +                                    SPAPR_DR_CONNECTOR_TYPE_CPU);
> > > > > > +        if (ret < 0) {
> > > > > > +            error_report("Couldn't set up CPU DR device tree properties");
> > > > > > +            exit(1);
> > > > > > +        }
> > > > > > +    }
> > > > > > +
> > > > > >      _FDT((fdt_pack(fdt)));
> > > > > >  
> > > > > >      if (fdt_totalsize(fdt) > FDT_MAX_SIZE) {
> > > > > > @@ -1181,7 +1203,7 @@ static void ppc_spapr_reset(void)
> > > > > >  
> > > > > >  }
> > > > > >  
> > > > > > -static void spapr_cpu_reset(void *opaque)
> > > > > > +void spapr_cpu_reset(void *opaque)
> > > > > >  {
> > > > > >      sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> > > > > >      PowerPCCPU *cpu = opaque;
> > > > > > @@ -1622,6 +1644,8 @@ static void spapr_boot_set(void *opaque, const char *boot_device,
> > > > > >  void spapr_cpu_init(sPAPRMachineState *spapr, PowerPCCPU *cpu, Error **errp)
> > > > > >  {
> > > > > >      CPUPPCState *env = &cpu->env;
> > > > > > +    CPUState *cs = CPU(cpu);
> > > > > > +    int i;
> > > > > >  
> > > > > >      /* Set time-base frequency to 512 MHz */
> > > > > >      cpu_ppc_tb_init(env, TIMEBASE_FREQ);
> > > > > > @@ -1646,6 +1670,14 @@ void spapr_cpu_init(sPAPRMachineState *spapr, PowerPCCPU *cpu, Error **errp)
> > > > > >          }
> > > > > >      }
> > > > > >  
> > > > > > +    /* Set NUMA node for the added CPUs  */
> > > > > > +    for (i = 0; i < nb_numa_nodes; i++) {
> > > > > > +        if (test_bit(cs->cpu_index, numa_info[i].node_cpu)) {
> > > > > > +            cs->numa_node = i;
> > > > > > +            break;
> > > > > > +        }
> > > > > > +    }
> > > > > > +  
> > > > > 
> > > > > This hunk seems like it belongs in a different patch.  
> > > > 
> > > > It appears that this would be needed by other archs also to set the
> > > > NUMA node for the hot-plugged CPU. How about make an API out of this
> > > > and use this something like below ? Igor ?  
> > > 
> > > Is there a way we could put this in the the CPU thread initialization
> > > itself?  Rather than requiring every platform to call a helper.
> > I'd suggest hotplugable CPU entity to have 'node' property, like we have
> > in pc-dimm.
> 
> Ok.  Do you think that makes sense for the base core type (which will
> sometimes be a hotpluggable CPU entity and sometimes might not be)?
> 
> > However machine owns numa mapping, so setting it from thread
> > initialization seems to be wrong.
> 
> Ah.. good point.
> 
> > Could that be done from machine's plug() handler (spapr_core_plug)?
> 
> Yes, I think so.  The core might need a "set node" method, but we
> should be able to control this from the plug() handler.

I am inclined to leave it wherever it is right now which is in the
thread realization path as it is setting a field in CPUState. When we have
node property for core and when other issues with NUMA cli get addressed
we can move this to core plug handler, ok ?

Regards,
Bharata.

  reply	other threads:[~2016-03-09  7:54 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 [this message]
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=20160309075359.GD29692@in.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).