All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org, Dou Liyang <douly.fnst@cn.fujitsu.com>,
	fanc.fnst@cn.fujitsu.com, caoj.fnst@cn.fujitsu.com,
	stefanha@redhat.com, izumi.taku@jp.fujitsu.com,
	vilanova@ac.upc.edu, peter.maydell@linaro.org,
	Andrew Jones <drjones@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Thomas Huth <thuth@redhat.com>
Subject: Re: [Qemu-devel] [RFC 11/13] numa: use new machine.cpu property with -numa cpus=... CLI
Date: Thu, 19 Jan 2017 15:36:52 +0100	[thread overview]
Message-ID: <20170119153652.4ea82c8e@nial.brq.redhat.com> (raw)
In-Reply-To: <20170118184637.GJ3491@thinpad.lan.raisama.net>

On Wed, 18 Jan 2017 16:46:37 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Wed, Jan 18, 2017 at 06:13:27PM +0100, Igor Mammedov wrote:
> > add compat layer to legacy cpu_index based '-numa cpus=...'
> > CLI option, which will use new machine.cpu property to set
> > numa mapping if that propety is available.
> > 
> > This way machine that supports machine.cpu property will
> > not break legacy CLI but will be able to move away from
> > using numa_info[node_id].node_cpu bitmaps and use only
> > possible_cpus instead.
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > ---
> >  numa.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++---------------
> >  1 file changed, 48 insertions(+), 15 deletions(-)
> > 
> > diff --git a/numa.c b/numa.c
> > index 887ee58..0c34130 100644
> > --- a/numa.c
> > +++ b/numa.c
> > @@ -141,10 +141,35 @@ uint32_t numa_get_node(ram_addr_t addr, Error **errp)
> >      return -1;
> >  }
> >  
> > -static void numa_node_parse(NumaNodeOptions *node, QemuOpts *opts, Error **errp)
> > +static void numa_cpu_set_nid(MachineState *ms, CpuInstanceProperties *props,
> > +                             Error **errp)
> > +{
> > +    Visitor *v;
> > +    QObject *qobj;
> > +    Error *local_error = NULL;
> > +
> > +    v = qobject_output_visitor_new(&qobj);
> > +    visit_type_CpuInstanceProperties(v, "cpu", &props, &local_error);
> > +    visit_complete(v, &qobj);
> > +    visit_free(v);
> > +    if (local_error) {
> > +        goto end;
> > +    }
> > +    v = qobject_input_visitor_new(qobj, true);
> > +    object_property_set(OBJECT(ms), v, "cpu", &local_error);
> > +    visit_free(v);
> > +    qobject_decref(qobj);
> > +end:
> > +    error_propagate(errp, local_error);
> > +}
> > +
> > +static void numa_node_parse(MachineState *ms, NumaNodeOptions *node,
> > +                            QemuOpts *opts, Error **errp)
> >  {
> >      uint16_t nodenr;
> >      uint16List *cpus = NULL;
> > +    MachineClass *mc = MACHINE_GET_CLASS(ms);
> > +    bool has_cpu_prop = object_property_find(OBJECT(ms), "cpu", NULL);
> >  
> >      if (node->has_nodeid) {
> >          nodenr = node->nodeid;
> > @@ -172,6 +197,19 @@ static void numa_node_parse(NumaNodeOptions *node, QemuOpts *opts, Error **errp)
> >              return;
> >          }
> >          bitmap_set(numa_info[nodenr].node_cpu, cpus->value, 1);
> > +        if (mc->cpu_index_to_instance_props && has_cpu_prop) {
> > +            CpuInstanceProperties props;
> > +            Error *local_error = NULL;
> > +
> > +            props = mc->cpu_index_to_instance_props(ms, cpus->value);
> > +            props.has_node_id = true;
> > +            props.node_id = nodenr;
> > +            numa_cpu_set_nid(ms, &props, &local_error);
> > +            if (local_error) {
> > +                error_propagate(errp, local_error);
> > +                return;
> > +            }
> > +        }
> >      }  
> 
> With this, now we have two completely different ways to store the
> results of "-numa node,cpus...", and both are likely to stay
> forever if we take too long to update the other machines.
> 
> Do you plan to make ppc/spapr and arm/virt use the new
> machine.cpu system so we could remove numa_info[].node_cpu
> completely in the same series?
this RFC is just to demonstrate an approach.

it would be better to do conversion within the same merge
window (however note ARM is not even close to -device based cpus)
so I would prefer do it incrementally per target
(under promise of not abandoning project midways)
above said doing conversion for x86 and spapr within one merge
windows seems feasible.

  reply	other threads:[~2017-01-19 14:37 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18 17:13 [Qemu-devel] [RFC 00/13] numa: add '-numa cpu' option Igor Mammedov
2017-01-18 17:13 ` [Qemu-devel] [RFC 01/13] numa: access CPU's node id via property in hmp_info_numa() Igor Mammedov
2017-01-18 18:18   ` Eduardo Habkost
2017-01-19 14:41     ` Igor Mammedov
2017-01-18 17:13 ` [Qemu-devel] [RFC 02/13] pc: cleanup: move smbios_set_cpuid() into pc_build_smbios() Igor Mammedov
2017-01-20 19:01   ` Eduardo Habkost
2017-01-18 17:13 ` [Qemu-devel] [RFC 03/13] pc: don't return cpu pointer from pc_new_cpu() as it's not needed anymore Igor Mammedov
2017-01-20 19:02   ` Eduardo Habkost
2017-01-18 17:13 ` [Qemu-devel] [RFC 04/13] make possible_cpu_arch_ids() return const pointer Igor Mammedov
2017-01-18 17:13 ` [Qemu-devel] [RFC 05/13] pc: move pcms->possible_cpus init out of pc_cpus_init() Igor Mammedov
2017-01-20  3:31   ` Dou Liyang
2017-01-20 15:33     ` Igor Mammedov
2017-01-18 17:13 ` [Qemu-devel] [RFC 06/13] pc: calculate topology only once when possible_cpus is initialised Igor Mammedov
2017-01-18 17:13 ` [Qemu-devel] [RFC 07/13] pc: pass apic_id to pc_find_cpu_slot() directly so lookup could be done without CPU object Igor Mammedov
2017-01-18 17:13 ` [Qemu-devel] [RFC 08/13] pc: add writeonly 'cpu' property to PCMachine Igor Mammedov
2017-01-18 18:27   ` Eduardo Habkost
2017-01-19 14:45     ` Igor Mammedov
2017-01-18 18:57   ` Eduardo Habkost
2017-01-19 15:04     ` Igor Mammedov
2017-01-23  6:50       ` Bharata B Rao
2017-01-23 15:03         ` Eduardo Habkost
2017-01-24 10:07           ` Igor Mammedov
2017-01-18 17:13 ` [Qemu-devel] [RFC 09/13] numa: introduce '-numa cpu' cpu option Igor Mammedov
2017-01-18 18:22   ` Eric Blake
2017-01-19 15:09     ` Igor Mammedov
2017-01-20 13:40   ` Paolo Bonzini
2017-01-20 15:33     ` Igor Mammedov
2017-01-18 17:13 ` [Qemu-devel] [RFC 10/13] numa: replace cpu_index_to_socket_id() with cpu_index_to_instance_props() Igor Mammedov
2017-01-18 17:13 ` [Qemu-devel] [RFC 11/13] numa: use new machine.cpu property with -numa cpus=... CLI Igor Mammedov
2017-01-18 18:46   ` Eduardo Habkost
2017-01-19 14:36     ` Igor Mammedov [this message]
2017-01-18 17:13 ` [Qemu-devel] [RFC 12/13] pc: drop usage of legacy numa_get_node_for_cpu() Igor Mammedov
2017-01-18 17:13 ` [Qemu-devel] [RFC 13/13] pc: cpu: make sure that cpu.node-id matches -numa mapping Igor Mammedov
2017-01-19  9:45 ` [Qemu-devel] [RFC 00/13] numa: add '-numa cpu' option Daniel P. Berrange
2017-01-19 10:55   ` Eduardo Habkost
2017-01-19 14:09   ` Igor Mammedov
2017-01-20 15:37 ` Igor Mammedov

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=20170119153652.4ea82c8e@nial.brq.redhat.com \
    --to=imammedo@redhat.com \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=douly.fnst@cn.fujitsu.com \
    --cc=drjones@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=fanc.fnst@cn.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    --cc=vilanova@ac.upc.edu \
    /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.