All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.