[PATCH v2 0/2] qmp: Expose MachineClass::default_ram_id

[PATCH v2 0/2] qmp: Expose MachineClass::default_ram_id

[Michal Privoznik]

v2 of:

https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg07103.html

diff to v1:
- in 2/2 I made the default-ram-id optional, because as it turns out,
    not every machine type has it set.

Michal Privoznik (2):
  qapi: Fix comment format for @CpuInstanceProperties
  qmp: Expose MachineClass::default_ram_id

 hw/core/machine-qmp-cmds.c | 4 ++++
 qapi/machine.json          | 8 ++++++--
 2 files changed, 10 insertions(+), 2 deletions(-)

-- 
2.26.2

[PATCH v2 1/2] qapi: Fix comment format for @CpuInstanceProperties

[Michal Privoznik]

In 176d2cda0de, the @die-id attribute was introduced to
CpuInstanceProperties type. However, it mangled the comment.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 qapi/machine.json | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/qapi/machine.json b/qapi/machine.json
index ff7b5032e3..39caa1d914 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -824,7 +824,8 @@
 # @node-id: NUMA node ID the CPU belongs to
 # @socket-id: socket number within node/board the CPU belongs to
 # @die-id: die number within node/board the CPU belongs to (Since 4.1)
-# @core-id: core number within die the CPU belongs to# @thread-id: thread number within core the CPU belongs to
+# @core-id: core number within die the CPU belongs to
+# @thread-id: thread number within core the CPU belongs to
 #
 # Note: currently there are 5 properties that could be present
 #       but management should be prepared to pass through other
-- 
2.26.2

Re: [PATCH v2 1/2] qapi: Fix comment format for @CpuInstanceProperties

[Igor Mammedov]

On Tue, 26 May 2020 10:25:34 +0200
Michal Privoznik <mprivozn@redhat.com> wrote:

> In 176d2cda0de, the @die-id attribute was introduced to
> CpuInstanceProperties type. However, it mangled the comment.
> 
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

Reviewed-by: Igor Mammedov <imammedo@redhat.com>

> ---
>  qapi/machine.json | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/qapi/machine.json b/qapi/machine.json
> index ff7b5032e3..39caa1d914 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -824,7 +824,8 @@
>  # @node-id: NUMA node ID the CPU belongs to
>  # @socket-id: socket number within node/board the CPU belongs to
>  # @die-id: die number within node/board the CPU belongs to (Since 4.1)
> -# @core-id: core number within die the CPU belongs to# @thread-id: thread number within core the CPU belongs to
> +# @core-id: core number within die the CPU belongs to
> +# @thread-id: thread number within core the CPU belongs to
>  #
>  # Note: currently there are 5 properties that could be present
>  #       but management should be prepared to pass through other

[PATCH v2 2/2] qmp: Expose MachineClass::default_ram_id

[Michal Privoznik]

If a management application (like Libvirt) want's to preserve
migration ability and switch to '-machine memory-backend' it
needs to set exactly the same RAM id as QEMU would. Since the id
is machine type dependant, expose it under 'query-machines'
result. Some machine types don't have the attribute set (riscv
family for example), therefore the QMP attribute must be
optional.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 hw/core/machine-qmp-cmds.c | 4 ++++
 qapi/machine.json          | 5 ++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
index 2c5da8413d..3e11a740c9 100644
--- a/hw/core/machine-qmp-cmds.c
+++ b/hw/core/machine-qmp-cmds.c
@@ -238,6 +238,10 @@ MachineInfoList *qmp_query_machines(Error **errp)
             info->default_cpu_type = g_strdup(mc->default_cpu_type);
             info->has_default_cpu_type = true;
         }
+        if (mc->default_ram_id) {
+            info->default_ram_id = g_strdup(mc->default_ram_id);
+            info->has_default_ram_id = true;
+        }
 
         entry = g_malloc0(sizeof(*entry));
         entry->value = info;
diff --git a/qapi/machine.json b/qapi/machine.json
index 39caa1d914..76c1606390 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -355,13 +355,16 @@
 # @default-cpu-type: default CPU model typename if none is requested via
 #                    the -cpu argument. (since 4.2)
 #
+# @default-ram-id: the default ID of initial RAM memory backend (since 5.1)
+#
 # Since: 1.2.0
 ##
 { 'struct': 'MachineInfo',
   'data': { 'name': 'str', '*alias': 'str',
             '*is-default': 'bool', 'cpu-max': 'int',
             'hotpluggable-cpus': 'bool',  'numa-mem-supported': 'bool',
-            'deprecated': 'bool', '*default-cpu-type': 'str' } }
+            'deprecated': 'bool', '*default-cpu-type': 'str',
+            '*default-ram-id': 'str' } }
 
 ##
 # @query-machines:
-- 
2.26.2

Re: [PATCH v2 2/2] qmp: Expose MachineClass::default_ram_id

[Igor Mammedov]

On Tue, 26 May 2020 10:25:35 +0200
Michal Privoznik <mprivozn@redhat.com> wrote:

> If a management application (like Libvirt) want's to preserve
> migration ability and switch to '-machine memory-backend' it
> needs to set exactly the same RAM id as QEMU would. Since the id
> is machine type dependant, expose it under 'query-machines'
> result. Some machine types don't have the attribute set (riscv
> family for example), therefore the QMP attribute must be
> optional.
> 
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>  hw/core/machine-qmp-cmds.c | 4 ++++
>  qapi/machine.json          | 5 ++++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
> index 2c5da8413d..3e11a740c9 100644
> --- a/hw/core/machine-qmp-cmds.c
> +++ b/hw/core/machine-qmp-cmds.c
> @@ -238,6 +238,10 @@ MachineInfoList *qmp_query_machines(Error **errp)
>              info->default_cpu_type = g_strdup(mc->default_cpu_type);
>              info->has_default_cpu_type = true;
>          }
> +        if (mc->default_ram_id) {
> +            info->default_ram_id = g_strdup(mc->default_ram_id);
> +            info->has_default_ram_id = true;
> +        }
>  
>          entry = g_malloc0(sizeof(*entry));
>          entry->value = info;
> diff --git a/qapi/machine.json b/qapi/machine.json
> index 39caa1d914..76c1606390 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -355,13 +355,16 @@
>  # @default-cpu-type: default CPU model typename if none is requested via
>  #                    the -cpu argument. (since 4.2)
>  #
> +# @default-ram-id: the default ID of initial RAM memory backend (since 5.1)
> +#
>  # Since: 1.2.0
>  ##
>  { 'struct': 'MachineInfo',
>    'data': { 'name': 'str', '*alias': 'str',
>              '*is-default': 'bool', 'cpu-max': 'int',
>              'hotpluggable-cpus': 'bool',  'numa-mem-supported': 'bool',
> -            'deprecated': 'bool', '*default-cpu-type': 'str' } }
> +            'deprecated': 'bool', '*default-cpu-type': 'str',
> +            '*default-ram-id': 'str' } }
>  
>  ##
>  # @query-machines:

Re: [PATCH v2 2/2] qmp: Expose MachineClass::default_ram_id

[Igor Mammedov]

On Tue, 26 May 2020 10:25:35 +0200
Michal Privoznik <mprivozn@redhat.com> wrote:

> If a management application (like Libvirt) want's to preserve
> migration ability and switch to '-machine memory-backend' it
> needs to set exactly the same RAM id as QEMU would. Since the id
> is machine type dependant, expose it under 'query-machines'
> result. Some machine types don't have the attribute set (riscv
> family for example), therefore the QMP attribute must be
> optional.
> 
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

Reviewed-by: Igor Mammedov <imammedo@redhat.com>

> ---
>  hw/core/machine-qmp-cmds.c | 4 ++++
>  qapi/machine.json          | 5 ++++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
> index 2c5da8413d..3e11a740c9 100644
> --- a/hw/core/machine-qmp-cmds.c
> +++ b/hw/core/machine-qmp-cmds.c
> @@ -238,6 +238,10 @@ MachineInfoList *qmp_query_machines(Error **errp)
>              info->default_cpu_type = g_strdup(mc->default_cpu_type);
>              info->has_default_cpu_type = true;
>          }
> +        if (mc->default_ram_id) {
> +            info->default_ram_id = g_strdup(mc->default_ram_id);
> +            info->has_default_ram_id = true;
> +        }
>  
>          entry = g_malloc0(sizeof(*entry));
>          entry->value = info;
> diff --git a/qapi/machine.json b/qapi/machine.json
> index 39caa1d914..76c1606390 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -355,13 +355,16 @@
>  # @default-cpu-type: default CPU model typename if none is requested via
>  #                    the -cpu argument. (since 4.2)
>  #
> +# @default-ram-id: the default ID of initial RAM memory backend (since 5.1)
> +#
>  # Since: 1.2.0
>  ##
>  { 'struct': 'MachineInfo',
>    'data': { 'name': 'str', '*alias': 'str',
>              '*is-default': 'bool', 'cpu-max': 'int',
>              'hotpluggable-cpus': 'bool',  'numa-mem-supported': 'bool',
> -            'deprecated': 'bool', '*default-cpu-type': 'str' } }
> +            'deprecated': 'bool', '*default-cpu-type': 'str',
> +            '*default-ram-id': 'str' } }
>  
>  ##
>  # @query-machines:

Re: [PATCH v2 0/2] qmp: Expose MachineClass::default_ram_id

[Eduardo Habkost]

Hi Michal,

It looks like this has fallen through the cracks, my apologies.

I'm queueing this for 5.2.  I assume this is the latest version,
correct?


On Tue, May 26, 2020 at 10:25:33AM +0200, Michal Privoznik wrote:
> v2 of:
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg07103.html
> 
> diff to v1:
> - in 2/2 I made the default-ram-id optional, because as it turns out,
>     not every machine type has it set.
> 
> Michal Privoznik (2):
>   qapi: Fix comment format for @CpuInstanceProperties
>   qmp: Expose MachineClass::default_ram_id
> 
>  hw/core/machine-qmp-cmds.c | 4 ++++
>  qapi/machine.json          | 8 ++++++--
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> -- 
> 2.26.2
> 

-- 
Eduardo

Re: [PATCH v2 0/2] qmp: Expose MachineClass::default_ram_id

[Michal Privoznik]

On 7/27/20 8:41 PM, Eduardo Habkost wrote:
> Hi Michal,
> 
> It looks like this has fallen through the cracks, my apologies.
> 
> I'm queueing this for 5.2.  I assume this is the latest version,
> correct?
> 

Yes. No worries, I forgot about it too :-) If I remembered, I would have 
pinged.

Michal