All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: peter.maydell@linaro.org, ehabkost@redhat.com,
	libvir-list@redhat.com, Michal Privoznik <mprivozn@redhat.com>,
	qemu-devel@nongnu.org, groug@kaod.org, qemu-arm@nongnu.org,
	qemu-ppc@nongnu.org, marcel.apfelbaum@gmail.com,
	pbonzini@redhat.com, rth@twiddle.net,
	david@gibson.dropbear.id.au
Subject: Re: [PATCH v4] numa: forbid '-numa node,mem' for 5.1 and newer machine types
Date: Mon, 8 Jun 2020 17:12:46 +0200	[thread overview]
Message-ID: <20200608171246.6a4adce0@redhat.com> (raw)
In-Reply-To: <20200608085442-mutt-send-email-mst@kernel.org>

On Mon, 8 Jun 2020 08:55:08 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Mon, Jun 08, 2020 at 08:03:44AM -0400, Igor Mammedov wrote:
> > Deprecation period is run out and it's a time to flip the switch
> > introduced by cd5ff8333a.  Disable legacy option for new machine
> > types (since 5.1) and amend documentation.
> > 
> > '-numa node,memdev' shall be used instead of disabled option
> > with new machine types.
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > Reviewed-by: Michal Privoznik <mprivozn@redhat.com>  
> 
> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
> 
Thanks!

> numa things so I'm guessing Eduardo's tree?
yep, it's pure NUMA so it should go via Eduardo's tere.


> > ---
> > v1:
> >  - rebased on top of current master
> >  - move compat mode from 4.2 to 5.0
> > v2:
> >  - move deprection text to recently removed section
> > v3:
> >  - increase title line length for (deprecated.rst)
> >      '``-numa node,mem=``\ *size* (removed in 5.1)'
> > v4:
> >  - use error_append_hint() for suggesting valid CLI
> > 
> > CC: peter.maydell@linaro.org
> > CC: ehabkost@redhat.com
> > CC: marcel.apfelbaum@gmail.com
> > CC: mst@redhat.com
> > CC: pbonzini@redhat.com
> > CC: rth@twiddle.net
> > CC: david@gibson.dropbear.id.au
> > CC: libvir-list@redhat.com
> > CC: qemu-arm@nongnu.org
> > CC: qemu-ppc@nongnu.org
> > CC: eblake@redhat.com
> > CC: groug@kaod.org
> > ---
> >  docs/system/deprecated.rst | 37 ++++++++++++++++++++-----------------
> >  hw/arm/virt.c              |  2 +-
> >  hw/core/numa.c             |  7 +++++++
> >  hw/i386/pc.c               |  1 -
> >  hw/i386/pc_piix.c          |  1 +
> >  hw/i386/pc_q35.c           |  1 +
> >  hw/ppc/spapr.c             |  2 +-
> >  qemu-options.hx            |  9 +++++----
> >  8 files changed, 36 insertions(+), 24 deletions(-)
> > 
> > diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> > index 544ece0a45..e74a5717c8 100644
> > --- a/docs/system/deprecated.rst
> > +++ b/docs/system/deprecated.rst
> > @@ -101,23 +101,6 @@ error in the future.
> >  The ``-realtime mlock=on|off`` argument has been replaced by the
> >  ``-overcommit mem-lock=on|off`` argument.
> >  
> > -``-numa node,mem=``\ *size* (since 4.1)
> > -'''''''''''''''''''''''''''''''''''''''
> > -
> > -The parameter ``mem`` of ``-numa node`` is used to assign a part of
> > -guest RAM to a NUMA node. But when using it, it's impossible to manage specified
> > -RAM chunk on the host side (like bind it to a host node, setting bind policy, ...),
> > -so guest end-ups with the fake NUMA configuration with suboptiomal performance.
> > -However since 2014 there is an alternative way to assign RAM to a NUMA node
> > -using parameter ``memdev``, which does the same as ``mem`` and adds
> > -means to actualy manage node RAM on the host side. Use parameter ``memdev``
> > -with *memory-backend-ram* backend as an replacement for parameter ``mem``
> > -to achieve the same fake NUMA effect or a properly configured
> > -*memory-backend-file* backend to actually benefit from NUMA configuration.
> > -In future new machine versions will not accept the option but it will still
> > -work with old machine types. User can check QAPI schema to see if the legacy
> > -option is supported by looking at MachineInfo::numa-mem-supported property.
> > -
> >  ``-numa`` node (without memory specified) (since 4.1)
> >  '''''''''''''''''''''''''''''''''''''''''''''''''''''
> >  
> > @@ -516,3 +499,23 @@ long starting at 1MiB, the old command::
> >  can be rewritten as::
> >  
> >    qemu-nbd -t --image-opts driver=raw,offset=1M,size=100M,file.driver=qcow2,file.file.driver=file,file.file.filename=file.qcow2
> > +
> > +Command line options
> > +--------------------
> > +
> > +``-numa node,mem=``\ *size* (removed in 5.1)
> > +''''''''''''''''''''''''''''''''''''''''''''
> > +
> > +The parameter ``mem`` of ``-numa node`` is used to assign a part of
> > +guest RAM to a NUMA node. But when using it, it's impossible to manage specified
> > +RAM chunk on the host side (like bind it to a host node, setting bind policy, ...),
> > +so guest end-ups with the fake NUMA configuration with suboptiomal performance.
> > +However since 2014 there is an alternative way to assign RAM to a NUMA node
> > +using parameter ``memdev``, which does the same as ``mem`` and adds
> > +means to actualy manage node RAM on the host side. Use parameter ``memdev``
> > +with *memory-backend-ram* backend as an replacement for parameter ``mem``
> > +to achieve the same fake NUMA effect or a properly configured
> > +*memory-backend-file* backend to actually benefit from NUMA configuration.
> > +In future new machine versions will not accept the option but it will still
> > +work with old machine types. User can check QAPI schema to see if the legacy
> > +option is supported by looking at MachineInfo::numa-mem-supported property.
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index 37462a6f78..063d4703f7 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -2262,7 +2262,6 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
> >      hc->pre_plug = virt_machine_device_pre_plug_cb;
> >      hc->plug = virt_machine_device_plug_cb;
> >      hc->unplug_request = virt_machine_device_unplug_request_cb;
> > -    mc->numa_mem_supported = true;
> >      mc->nvdimm_supported = true;
> >      mc->auto_enable_numa_with_memhp = true;
> >      mc->default_ram_id = "mach-virt.ram";
> > @@ -2375,6 +2374,7 @@ DEFINE_VIRT_MACHINE_AS_LATEST(5, 1)
> >  static void virt_machine_5_0_options(MachineClass *mc)
> >  {
> >      virt_machine_5_1_options(mc);
> > +    mc->numa_mem_supported = true;
> >  }
> >  DEFINE_VIRT_MACHINE(5, 0)
> >  
> > diff --git a/hw/core/numa.c b/hw/core/numa.c
> > index 316bc50d75..7814e646e4 100644
> > --- a/hw/core/numa.c
> > +++ b/hw/core/numa.c
> > @@ -117,6 +117,13 @@ static void parse_numa_node(MachineState *ms, NumaNodeOptions *node,
> >      }
> >  
> >      if (node->has_mem) {
> > +        if (!mc->numa_mem_supported) {
> > +            error_setg(errp, "Parameter -numa node,mem is not supported by this"
> > +                      " machine type");
> > +            error_append_hint(errp, "Use -numa node,memdev instead");
> > +            return;
> > +        }
> > +
> >          numa_info[nodenr].node_mem = node->mem;
> >          if (!qtest_enabled()) {
> >              warn_report("Parameter -numa node,mem is deprecated,"
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 2128f3d6fe..a86136069c 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -1960,7 +1960,6 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
> >      hc->unplug = pc_machine_device_unplug_cb;
> >      mc->default_cpu_type = TARGET_DEFAULT_CPU_TYPE;
> >      mc->nvdimm_supported = true;
> > -    mc->numa_mem_supported = true;
> >      mc->default_ram_id = "pc.ram";
> >  
> >      object_class_property_add(oc, PC_MACHINE_DEVMEM_REGION_SIZE, "int",
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > index f66e1d73ce..8955436efa 100644
> > --- a/hw/i386/pc_piix.c
> > +++ b/hw/i386/pc_piix.c
> > @@ -438,6 +438,7 @@ static void pc_i440fx_5_0_machine_options(MachineClass *m)
> >      pc_i440fx_5_1_machine_options(m);
> >      m->alias = NULL;
> >      m->is_default = false;
> > +    m->numa_mem_supported = true;
> >      compat_props_add(m->compat_props, hw_compat_5_0, hw_compat_5_0_len);
> >      compat_props_add(m->compat_props, pc_compat_5_0, pc_compat_5_0_len);
> >  }
> > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> > index 4ba8ac8774..af6b32adb7 100644
> > --- a/hw/i386/pc_q35.c
> > +++ b/hw/i386/pc_q35.c
> > @@ -366,6 +366,7 @@ static void pc_q35_5_0_machine_options(MachineClass *m)
> >  {
> >      pc_q35_5_1_machine_options(m);
> >      m->alias = NULL;
> > +    m->numa_mem_supported = true;
> >      compat_props_add(m->compat_props, hw_compat_5_0, hw_compat_5_0_len);
> >      compat_props_add(m->compat_props, pc_compat_5_0, pc_compat_5_0_len);
> >  }
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 3b1a5ed865..210d61d1b3 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -4511,7 +4511,6 @@ 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;
> >      mc->auto_enable_numa = true;
> >  
> >      smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
> > @@ -4599,6 +4598,7 @@ static void spapr_machine_5_0_class_options(MachineClass *mc)
> >  {
> >      spapr_machine_5_1_class_options(mc);
> >      compat_props_add(mc->compat_props, hw_compat_5_0, hw_compat_5_0_len);
> > +    mc->numa_mem_supported = true;
> >  }
> >  
> >  DEFINE_SPAPR_MACHINE(5_0, "5.0", false);
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 93bde2bbc8..196f468786 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -239,10 +239,11 @@ SRST
> >          -numa node,nodeid=0 -numa node,nodeid=1 \
> >          -numa cpu,node-id=0,socket-id=0 -numa cpu,node-id=1,socket-id=1
> >  
> > -    '\ ``mem``\ ' assigns a given RAM amount to a node. '\ ``memdev``\ '
> > -    assigns RAM from a given memory backend device to a node. If
> > -    '\ ``mem``\ ' and '\ ``memdev``\ ' are omitted in all nodes, RAM is
> > -    split equally between them.
> > +    Legacy '\ ``mem``\ ' assigns a given RAM amount to a node (not supported
> > +    for 5.1 and newer machine types). '\ ``memdev``\ ' assigns RAM from
> > +    a given memory backend device to a node. If '\ ``mem``\ ' and
> > +    '\ ``memdev``\ ' are omitted in all nodes, RAM is split equally between them.
> > +
> >  
> >      '\ ``mem``\ ' and '\ ``memdev``\ ' are mutually exclusive.
> >      Furthermore, if one node uses '\ ``memdev``\ ', all of them have to
> > -- 
> > 2.26.2  
> 


WARNING: multiple messages have this Message-ID (diff)
From: Igor Mammedov <imammedo@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: peter.maydell@linaro.org, ehabkost@redhat.com,
	libvir-list@redhat.com, Michal Privoznik <mprivozn@redhat.com>,
	qemu-devel@nongnu.org, groug@kaod.org, qemu-arm@nongnu.org,
	qemu-ppc@nongnu.org, pbonzini@redhat.com, rth@twiddle.net,
	david@gibson.dropbear.id.au
Subject: Re: [PATCH v4] numa: forbid '-numa node,mem' for 5.1 and newer machine types
Date: Mon, 8 Jun 2020 17:12:46 +0200	[thread overview]
Message-ID: <20200608171246.6a4adce0@redhat.com> (raw)
In-Reply-To: <20200608085442-mutt-send-email-mst@kernel.org>

On Mon, 8 Jun 2020 08:55:08 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Mon, Jun 08, 2020 at 08:03:44AM -0400, Igor Mammedov wrote:
> > Deprecation period is run out and it's a time to flip the switch
> > introduced by cd5ff8333a.  Disable legacy option for new machine
> > types (since 5.1) and amend documentation.
> > 
> > '-numa node,memdev' shall be used instead of disabled option
> > with new machine types.
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > Reviewed-by: Michal Privoznik <mprivozn@redhat.com>  
> 
> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
> 
Thanks!

> numa things so I'm guessing Eduardo's tree?
yep, it's pure NUMA so it should go via Eduardo's tere.


> > ---
> > v1:
> >  - rebased on top of current master
> >  - move compat mode from 4.2 to 5.0
> > v2:
> >  - move deprection text to recently removed section
> > v3:
> >  - increase title line length for (deprecated.rst)
> >      '``-numa node,mem=``\ *size* (removed in 5.1)'
> > v4:
> >  - use error_append_hint() for suggesting valid CLI
> > 
> > CC: peter.maydell@linaro.org
> > CC: ehabkost@redhat.com
> > CC: marcel.apfelbaum@gmail.com
> > CC: mst@redhat.com
> > CC: pbonzini@redhat.com
> > CC: rth@twiddle.net
> > CC: david@gibson.dropbear.id.au
> > CC: libvir-list@redhat.com
> > CC: qemu-arm@nongnu.org
> > CC: qemu-ppc@nongnu.org
> > CC: eblake@redhat.com
> > CC: groug@kaod.org
> > ---
> >  docs/system/deprecated.rst | 37 ++++++++++++++++++++-----------------
> >  hw/arm/virt.c              |  2 +-
> >  hw/core/numa.c             |  7 +++++++
> >  hw/i386/pc.c               |  1 -
> >  hw/i386/pc_piix.c          |  1 +
> >  hw/i386/pc_q35.c           |  1 +
> >  hw/ppc/spapr.c             |  2 +-
> >  qemu-options.hx            |  9 +++++----
> >  8 files changed, 36 insertions(+), 24 deletions(-)
> > 
> > diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> > index 544ece0a45..e74a5717c8 100644
> > --- a/docs/system/deprecated.rst
> > +++ b/docs/system/deprecated.rst
> > @@ -101,23 +101,6 @@ error in the future.
> >  The ``-realtime mlock=on|off`` argument has been replaced by the
> >  ``-overcommit mem-lock=on|off`` argument.
> >  
> > -``-numa node,mem=``\ *size* (since 4.1)
> > -'''''''''''''''''''''''''''''''''''''''
> > -
> > -The parameter ``mem`` of ``-numa node`` is used to assign a part of
> > -guest RAM to a NUMA node. But when using it, it's impossible to manage specified
> > -RAM chunk on the host side (like bind it to a host node, setting bind policy, ...),
> > -so guest end-ups with the fake NUMA configuration with suboptiomal performance.
> > -However since 2014 there is an alternative way to assign RAM to a NUMA node
> > -using parameter ``memdev``, which does the same as ``mem`` and adds
> > -means to actualy manage node RAM on the host side. Use parameter ``memdev``
> > -with *memory-backend-ram* backend as an replacement for parameter ``mem``
> > -to achieve the same fake NUMA effect or a properly configured
> > -*memory-backend-file* backend to actually benefit from NUMA configuration.
> > -In future new machine versions will not accept the option but it will still
> > -work with old machine types. User can check QAPI schema to see if the legacy
> > -option is supported by looking at MachineInfo::numa-mem-supported property.
> > -
> >  ``-numa`` node (without memory specified) (since 4.1)
> >  '''''''''''''''''''''''''''''''''''''''''''''''''''''
> >  
> > @@ -516,3 +499,23 @@ long starting at 1MiB, the old command::
> >  can be rewritten as::
> >  
> >    qemu-nbd -t --image-opts driver=raw,offset=1M,size=100M,file.driver=qcow2,file.file.driver=file,file.file.filename=file.qcow2
> > +
> > +Command line options
> > +--------------------
> > +
> > +``-numa node,mem=``\ *size* (removed in 5.1)
> > +''''''''''''''''''''''''''''''''''''''''''''
> > +
> > +The parameter ``mem`` of ``-numa node`` is used to assign a part of
> > +guest RAM to a NUMA node. But when using it, it's impossible to manage specified
> > +RAM chunk on the host side (like bind it to a host node, setting bind policy, ...),
> > +so guest end-ups with the fake NUMA configuration with suboptiomal performance.
> > +However since 2014 there is an alternative way to assign RAM to a NUMA node
> > +using parameter ``memdev``, which does the same as ``mem`` and adds
> > +means to actualy manage node RAM on the host side. Use parameter ``memdev``
> > +with *memory-backend-ram* backend as an replacement for parameter ``mem``
> > +to achieve the same fake NUMA effect or a properly configured
> > +*memory-backend-file* backend to actually benefit from NUMA configuration.
> > +In future new machine versions will not accept the option but it will still
> > +work with old machine types. User can check QAPI schema to see if the legacy
> > +option is supported by looking at MachineInfo::numa-mem-supported property.
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index 37462a6f78..063d4703f7 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -2262,7 +2262,6 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
> >      hc->pre_plug = virt_machine_device_pre_plug_cb;
> >      hc->plug = virt_machine_device_plug_cb;
> >      hc->unplug_request = virt_machine_device_unplug_request_cb;
> > -    mc->numa_mem_supported = true;
> >      mc->nvdimm_supported = true;
> >      mc->auto_enable_numa_with_memhp = true;
> >      mc->default_ram_id = "mach-virt.ram";
> > @@ -2375,6 +2374,7 @@ DEFINE_VIRT_MACHINE_AS_LATEST(5, 1)
> >  static void virt_machine_5_0_options(MachineClass *mc)
> >  {
> >      virt_machine_5_1_options(mc);
> > +    mc->numa_mem_supported = true;
> >  }
> >  DEFINE_VIRT_MACHINE(5, 0)
> >  
> > diff --git a/hw/core/numa.c b/hw/core/numa.c
> > index 316bc50d75..7814e646e4 100644
> > --- a/hw/core/numa.c
> > +++ b/hw/core/numa.c
> > @@ -117,6 +117,13 @@ static void parse_numa_node(MachineState *ms, NumaNodeOptions *node,
> >      }
> >  
> >      if (node->has_mem) {
> > +        if (!mc->numa_mem_supported) {
> > +            error_setg(errp, "Parameter -numa node,mem is not supported by this"
> > +                      " machine type");
> > +            error_append_hint(errp, "Use -numa node,memdev instead");
> > +            return;
> > +        }
> > +
> >          numa_info[nodenr].node_mem = node->mem;
> >          if (!qtest_enabled()) {
> >              warn_report("Parameter -numa node,mem is deprecated,"
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 2128f3d6fe..a86136069c 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -1960,7 +1960,6 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
> >      hc->unplug = pc_machine_device_unplug_cb;
> >      mc->default_cpu_type = TARGET_DEFAULT_CPU_TYPE;
> >      mc->nvdimm_supported = true;
> > -    mc->numa_mem_supported = true;
> >      mc->default_ram_id = "pc.ram";
> >  
> >      object_class_property_add(oc, PC_MACHINE_DEVMEM_REGION_SIZE, "int",
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > index f66e1d73ce..8955436efa 100644
> > --- a/hw/i386/pc_piix.c
> > +++ b/hw/i386/pc_piix.c
> > @@ -438,6 +438,7 @@ static void pc_i440fx_5_0_machine_options(MachineClass *m)
> >      pc_i440fx_5_1_machine_options(m);
> >      m->alias = NULL;
> >      m->is_default = false;
> > +    m->numa_mem_supported = true;
> >      compat_props_add(m->compat_props, hw_compat_5_0, hw_compat_5_0_len);
> >      compat_props_add(m->compat_props, pc_compat_5_0, pc_compat_5_0_len);
> >  }
> > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> > index 4ba8ac8774..af6b32adb7 100644
> > --- a/hw/i386/pc_q35.c
> > +++ b/hw/i386/pc_q35.c
> > @@ -366,6 +366,7 @@ static void pc_q35_5_0_machine_options(MachineClass *m)
> >  {
> >      pc_q35_5_1_machine_options(m);
> >      m->alias = NULL;
> > +    m->numa_mem_supported = true;
> >      compat_props_add(m->compat_props, hw_compat_5_0, hw_compat_5_0_len);
> >      compat_props_add(m->compat_props, pc_compat_5_0, pc_compat_5_0_len);
> >  }
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 3b1a5ed865..210d61d1b3 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -4511,7 +4511,6 @@ 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;
> >      mc->auto_enable_numa = true;
> >  
> >      smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
> > @@ -4599,6 +4598,7 @@ static void spapr_machine_5_0_class_options(MachineClass *mc)
> >  {
> >      spapr_machine_5_1_class_options(mc);
> >      compat_props_add(mc->compat_props, hw_compat_5_0, hw_compat_5_0_len);
> > +    mc->numa_mem_supported = true;
> >  }
> >  
> >  DEFINE_SPAPR_MACHINE(5_0, "5.0", false);
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 93bde2bbc8..196f468786 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -239,10 +239,11 @@ SRST
> >          -numa node,nodeid=0 -numa node,nodeid=1 \
> >          -numa cpu,node-id=0,socket-id=0 -numa cpu,node-id=1,socket-id=1
> >  
> > -    '\ ``mem``\ ' assigns a given RAM amount to a node. '\ ``memdev``\ '
> > -    assigns RAM from a given memory backend device to a node. If
> > -    '\ ``mem``\ ' and '\ ``memdev``\ ' are omitted in all nodes, RAM is
> > -    split equally between them.
> > +    Legacy '\ ``mem``\ ' assigns a given RAM amount to a node (not supported
> > +    for 5.1 and newer machine types). '\ ``memdev``\ ' assigns RAM from
> > +    a given memory backend device to a node. If '\ ``mem``\ ' and
> > +    '\ ``memdev``\ ' are omitted in all nodes, RAM is split equally between them.
> > +
> >  
> >      '\ ``mem``\ ' and '\ ``memdev``\ ' are mutually exclusive.
> >      Furthermore, if one node uses '\ ``memdev``\ ', all of them have to
> > -- 
> > 2.26.2  
> 



  reply	other threads:[~2020-06-08 15:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08 12:03 [PATCH v4] numa: forbid '-numa node, mem' for 5.1 and newer machine types Igor Mammedov
2020-06-08 12:03 ` Igor Mammedov
2020-06-08 12:55 ` [PATCH v4] numa: forbid '-numa node,mem' " Michael S. Tsirkin
2020-06-08 12:55   ` Michael S. Tsirkin
2020-06-08 15:12   ` Igor Mammedov [this message]
2020-06-08 15:12     ` Igor Mammedov
2020-06-08 15:27 ` Greg Kurz
2020-06-08 15:27   ` Greg Kurz
2020-06-08 15:53 ` Eric Blake
2020-06-23  9:35 ` Paolo Bonzini

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=20200608171246.6a4adce0@redhat.com \
    --to=imammedo@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=groug@kaod.org \
    --cc=libvir-list@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mprivozn@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    /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.