All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: libvir-list@redhat.com, pbonzini@redhat.com, berrange@redhat.com,
	qemu-devel@nongnu.org, ehabkost@redhat.com
Subject: Re: [Qemu-devel] [PATCH v4 1/3] machine: show if CLI option '-numa node, mem' is supported in QAPI schema
Date: Mon, 10 Jun 2019 14:31:08 +0200	[thread overview]
Message-ID: <20190610143109.10c4979b@redhat.com> (raw)
In-Reply-To: <87h8915m7u.fsf@dusky.pond.sub.org>

On Fri, 07 Jun 2019 19:39:17 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Igor Mammedov <imammedo@redhat.com> writes:
> 
> > Legacy '-numa node,mem' option has a number of issues and mgmt often
> > defaults to it. Unfortunately it's no possible to replace it with
> > an alternative '-numa memdev' without breaking migration compatibility.
> > What's possible though is to deprecate it, keeping option working with
> > old machine types only.
> >
> > In order to help users to find out if being deprecated CLI option
> > '-numa node,mem' is still supported by particular machine type, add new
> > "numa-mem-supported" property to MachineInfo description in QAPI schema.  
> 
> Suggest s/to MachineInfo description in QAPI schema/to output of
> query-machines/, because query-machines is the external interface people
> know.

fixed

> 
> > "numa-mem-supported" is set to 'true' for machines that currently support
> > NUMA, but it will be flipped to 'false' later on, once deprecation period
> > expires and kept 'true' only for old machine types that used to support
> > the legacy option so it won't break existing configuration that are using
> > it.
> >
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > ---
> >
> > Notes:
> >     v4:
> >       * drop idea to use "qom-list-properties" and use MachineInfo instead
> >         which could be inspected with 'query-machines'
> >
> >  include/hw/boards.h | 3 +++
> >  hw/arm/virt.c       | 1 +
> >  hw/i386/pc.c        | 1 +
> >  hw/ppc/spapr.c      | 1 +
> >  qapi/misc.json      | 5 ++++-
> >  vl.c                | 1 +
> >  6 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/hw/boards.h b/include/hw/boards.h
> > index 6f7916f..86894b6 100644
> > --- a/include/hw/boards.h
> > +++ b/include/hw/boards.h
> > @@ -158,6 +158,8 @@ typedef struct {
> >   * @kvm_type:
> >   *    Return the type of KVM corresponding to the kvm-type string option or
> >   *    computed based on other criteria such as the host kernel capabilities.
> > + * @numa_mem_supported:
> > + *    true if '--numa node.mem' option is supported and false otherwise
> >   */
> >  struct MachineClass {
> >      /*< private >*/
> > @@ -210,6 +212,7 @@ struct MachineClass {
> >      bool ignore_boot_device_suffixes;
> >      bool smbus_no_migration_support;
> >      bool nvdimm_supported;
> > +    bool numa_mem_supported;
> >  
> >      HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
> >                                             DeviceState *dev);
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index bf54f10..481a603 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -1943,6 +1943,7 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
> >      assert(!mc->get_hotplug_handler);
> >      mc->get_hotplug_handler = virt_machine_get_hotplug_handler;
> >      hc->plug = virt_machine_device_plug_cb;
> > +    mc->numa_mem_supported = true;
> >  }
> >  
> >  static void virt_instance_init(Object *obj)
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 2632b73..05b8368 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -2747,6 +2747,7 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
> >      nc->nmi_monitor_handler = x86_nmi;
> >      mc->default_cpu_type = TARGET_DEFAULT_CPU_TYPE;
> >      mc->nvdimm_supported = true;
> > +    mc->numa_mem_supported = true;
> >  
> >      object_class_property_add(oc, PC_MACHINE_DEVMEM_REGION_SIZE, "int",
> >          pc_machine_get_device_memory_region_size, NULL,
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 2ef3ce4..265ecfb 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -4336,6 +4336,7 @@ static void spapr_machine_class_init(ObjectClass *oc, void *data)
> >       * in which LMBs are represented and hot-added
> >       */
> >      mc->numa_mem_align_shift = 28;
> > +    mc->numa_mem_supported = true;
> >  
> >      smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
> >      smc->default_caps.caps[SPAPR_CAP_VSX] = SPAPR_CAP_ON;  
> 
> This is correct when the TYPE_VIRT_MACHINE, TYPE_PC_MACHINE and
> TYPE_SPAPR_MACHINE are exactly the machines supporting NUMA.  How could
> I check that?

We don't have an interface to communicate that to users as far as I know.

Eduardo pointed out to the patch that might serve as starting point for it though.

> 
> > diff --git a/qapi/misc.json b/qapi/misc.json
> > index 8b3ca4f..d0bdccb 100644
> > --- a/qapi/misc.json
> > +++ b/qapi/misc.json
> > @@ -2018,12 +2018,15 @@
> >  #
> >  # @hotpluggable-cpus: cpu hotplug via -device is supported (since 2.7.0)
> >  #
> > +# @numa-mem-supported: true if '-numa node,mem' option is supported by machine
> > +#                      type and false otherwise (since 4.1)  
> 
> 
> "by the machine type", for consistency with @cpu-max.  Also, rather long
> line.

fixed

> 
> > +#
> >  # Since: 1.2.0
> >  ##
> >  { 'struct': 'MachineInfo',
> >    'data': { 'name': 'str', '*alias': 'str',
> >              '*is-default': 'bool', 'cpu-max': 'int',
> > -            'hotpluggable-cpus': 'bool'} }
> > +            'hotpluggable-cpus': 'bool', 'numa-mem-supported': 'bool'} }
> >  
> >  ##
> >  # @query-machines:
> > diff --git a/vl.c b/vl.c
> > index 5550bd7..5bf17f5 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -1520,6 +1520,7 @@ MachineInfoList *qmp_query_machines(Error **errp)
> >          info->name = g_strdup(mc->name);
> >          info->cpu_max = !mc->max_cpus ? 1 : mc->max_cpus;
> >          info->hotpluggable_cpus = mc->has_hotpluggable_cpus;
> > +        info->numa_mem_supported = mc->numa_mem_supported;
> >  
> >          entry = g_malloc0(sizeof(*entry));
> >          entry->value = info;  



  parent reply	other threads:[~2019-06-10 12:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30  8:33 [Qemu-devel] [PATCH v4 0/3] numa: deprecate '-numa node, mem' and default memory distribution Igor Mammedov
2019-05-30  8:33 ` [Qemu-devel] [PATCH v4 1/3] machine: show if CLI option '-numa node, mem' is supported in QAPI schema Igor Mammedov
2019-06-07 17:39   ` Markus Armbruster
2019-06-07 18:02     ` Eduardo Habkost
2019-06-11  8:29       ` Markus Armbruster
2019-06-10 12:31     ` Igor Mammedov [this message]
2019-06-10 13:10   ` [Qemu-devel] [PATCH v5 " Igor Mammedov
2019-06-11  8:30     ` Markus Armbruster
2019-05-30  8:33 ` [Qemu-devel] [PATCH v4 2/3] numa: deprecate 'mem' parameter of '-numa node' option Igor Mammedov
2019-05-30  8:33 ` [Qemu-devel] [PATCH v4 3/3] numa: deprecate implict memory distribution between nodes Igor Mammedov
2019-06-05 17:33 ` [Qemu-devel] [PATCH v4 0/3] numa: deprecate '-numa node, mem' and default memory distribution Daniel P. Berrangé
2019-06-05 18:06   ` Eduardo Habkost
2019-06-06  9:16     ` Daniel P. Berrangé
2019-06-07 17:28 ` Markus Armbruster
2019-06-10 12:19   ` Igor Mammedov
2019-06-17 13:11 ` 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=20190610143109.10c4979b@redhat.com \
    --to=imammedo@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.