diff mbox

[v2] qmp: Add qom_path field to query-cpus command

Message ID 1431111862-26377-1-git-send-email-ehabkost@redhat.com
State New
Headers show

Commit Message

Eduardo Habkost May 8, 2015, 7:04 p.m. UTC
This will allow clients to query additional information directly using
qom-get on the CPU objects.

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
Changes v1 -> v2:
* Renamed field from "qom-path" to "qom_path", to keep consistency
  with existing CpuInfo fields
* Added "(since 2.4)" to QAPI schema documentation
* Added the new field to example on qmp-commands.hx

Reference to previous discussion:

  Date: Mon, 4 May 2015 15:37:40 -0300
  From: Eduardo Habkost <ehabkost@redhat.com>
  Message-ID: <20150504183740.GM17796@thinpad.lan.raisama.net>
  Subject: Re: [Qemu-devel] [PATCH] cpu: Register QOM links at /machine/cpus/<index>

The summary is: even if we provide predictable QOM paths for the CPU
objects, the qom-path field will be useful to allow the QOM objects and
query-cpu data to be matched correctly.
---
 cpus.c           | 1 +
 qapi-schema.json | 7 +++++--
 qmp-commands.hx  | 7 +++++--
 3 files changed, 11 insertions(+), 4 deletions(-)

Comments

Eric Blake May 8, 2015, 9:16 p.m. UTC | #1
On 05/08/2015 01:04 PM, Eduardo Habkost wrote:
> This will allow clients to query additional information directly using
> qom-get on the CPU objects.
> 
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> Reviewed-by: Andreas Färber <afaerber@suse.de>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
> Changes v1 -> v2:
> * Renamed field from "qom-path" to "qom_path", to keep consistency
>   with existing CpuInfo fields
> * Added "(since 2.4)" to QAPI schema documentation
> * Added the new field to example on qmp-commands.hx
> 

Reviewed-by: Eric Blake <eblake@redhat.com>
Markus Armbruster May 12, 2015, 3:38 p.m. UTC | #2
Eduardo Habkost <ehabkost@redhat.com> writes:

> This will allow clients to query additional information directly using
> qom-get on the CPU objects.
>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> Reviewed-by: Andreas Färber <afaerber@suse.de>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
> Changes v1 -> v2:
> * Renamed field from "qom-path" to "qom_path", to keep consistency
>   with existing CpuInfo fields
> * Added "(since 2.4)" to QAPI schema documentation
> * Added the new field to example on qmp-commands.hx
>
> Reference to previous discussion:
>
>   Date: Mon, 4 May 2015 15:37:40 -0300
>   From: Eduardo Habkost <ehabkost@redhat.com>
>   Message-ID: <20150504183740.GM17796@thinpad.lan.raisama.net>
>   Subject: Re: [Qemu-devel] [PATCH] cpu: Register QOM links at /machine/cpus/<index>
>
> The summary is: even if we provide predictable QOM paths for the CPU
> objects, the qom-path field will be useful to allow the QOM objects and
> query-cpu data to be matched correctly.
> ---
>  cpus.c           | 1 +
>  qapi-schema.json | 7 +++++--
>  qmp-commands.hx  | 7 +++++--
>  3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/cpus.c b/cpus.c
> index 62d157a..de6469f 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -1435,6 +1435,7 @@ CpuInfoList *qmp_query_cpus(Error **errp)
>          info->value->CPU = cpu->cpu_index;
>          info->value->current = (cpu == first_cpu);
>          info->value->halted = cpu->halted;
> +        info->value->qom_path = object_get_canonical_path(OBJECT(cpu));
>          info->value->thread_id = cpu->thread_id;
>  #if defined(TARGET_I386)
>          info->value->has_pc = true;
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 9c92482..921ce70 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -679,6 +679,8 @@
>  # @halted: true if the virtual CPU is in the halt state.  Halt usually refers
>  #          to a processor specific low power mode.
>  #
> +# @qom_path: path to the CPU object in the QOM tree (since 2.4)
> +#
>  # @pc: #optional If the target is i386 or x86_64, this is the 64-bit instruction
>  #                pointer.
>  #                If the target is Sparc, this is the PC component of the
> @@ -699,8 +701,9 @@
>  #        data is sent to the client, the guest may no longer be halted.
>  ##
>  { 'struct': 'CpuInfo',
> -  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', '*pc': 'int',
> -           '*nip': 'int', '*npc': 'int', '*PC': 'int', 'thread_id': 'int'} }
> +  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', 'qom_path': 'str',

Long line.

> +           '*pc': 'int', '*nip': 'int', '*npc': 'int', '*PC': 'int',
> +           'thread_id': 'int'} }
>  
>  ##
>  # @query-cpus:
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index 7506774..14e109e 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -2569,6 +2569,7 @@ Return a json-array. Each CPU is represented by a json-object, which contains:
>  - "CPU": CPU index (json-int)
>  - "current": true if this is the current CPU, false otherwise (json-bool)
>  - "halted": true if the cpu is halted, false otherwise (json-bool)
> +- "qom_path": path to the CPU object in the QOM tree (json-str)
>  - Current program counter. The key's name depends on the architecture:
>       "pc": i386/x86_64 (json-int)
>       "nip": PPC (json-int)
> @@ -2585,14 +2586,16 @@ Example:
>              "CPU":0,
>              "current":true,
>              "halted":false,
> -            "pc":3227107138
> +            "qom_path":"/machine/unattached/device[0]",
> +            "pc":3227107138,
>              "thread_id":3134
>           },
>           {
>              "CPU":1,
>              "current":false,
>              "halted":true,
> -            "pc":7108165
> +            "qom_path":"/machine/unattached/device[2]",
> +            "pc":7108165,
>              "thread_id":3135
>           }
>        ]

Applied to my qapi-next branch with the long line wrapped, thanks!
Eduardo Habkost May 12, 2015, 3:47 p.m. UTC | #3
On Tue, May 12, 2015 at 05:38:37PM +0200, Markus Armbruster wrote:
[...]
> > @@ -699,8 +701,9 @@
> >  #        data is sent to the client, the guest may no longer be halted.
> >  ##
> >  { 'struct': 'CpuInfo',
> > -  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', '*pc': 'int',
> > -           '*nip': 'int', '*npc': 'int', '*PC': 'int', 'thread_id': 'int'} }
> > +  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', 'qom_path': 'str',
> 
> Long line.

It has exactly 80 characters.
Markus Armbruster May 12, 2015, 5:42 p.m. UTC | #4
Eduardo Habkost <ehabkost@redhat.com> writes:

> On Tue, May 12, 2015 at 05:38:37PM +0200, Markus Armbruster wrote:
> [...]
>> > @@ -699,8 +701,9 @@
>> >  #        data is sent to the client, the guest may no longer be halted.
>> >  ##
>> >  { 'struct': 'CpuInfo',
>> > -  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', '*pc': 'int',
>> > - '*nip': 'int', '*npc': 'int', '*PC': 'int', 'thread_id': 'int'}
>> > }
>> > + 'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool',
>> > qom_path': 'str',
>> 
>> Long line.
>
> It has exactly 80 characters.

Several characters too wide for my taste.

I just realized checkpatch is fine with 80.  I'll revert my line wrap if
you feel strongly about it.
Eduardo Habkost May 12, 2015, 7:18 p.m. UTC | #5
On Tue, May 12, 2015 at 07:42:17PM +0200, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
> > On Tue, May 12, 2015 at 05:38:37PM +0200, Markus Armbruster wrote:
> > [...]
> >> > @@ -699,8 +701,9 @@
> >> >  #        data is sent to the client, the guest may no longer be halted.
> >> >  ##
> >> >  { 'struct': 'CpuInfo',
> >> > -  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', '*pc': 'int',
> >> > - '*nip': 'int', '*npc': 'int', '*PC': 'int', 'thread_id': 'int'}
> >> > }
> >> > + 'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool',
> >> > qom_path': 'str',
> >> 
> >> Long line.
> >
> > It has exactly 80 characters.
> 
> Several characters too wide for my taste.

I thought I had broken some documented line length limit.

> 
> I just realized checkpatch is fine with 80.  I'll revert my line wrap if
> you feel strongly about it.

Please keep your line wrap, I don't mind.
diff mbox

Patch

diff --git a/cpus.c b/cpus.c
index 62d157a..de6469f 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1435,6 +1435,7 @@  CpuInfoList *qmp_query_cpus(Error **errp)
         info->value->CPU = cpu->cpu_index;
         info->value->current = (cpu == first_cpu);
         info->value->halted = cpu->halted;
+        info->value->qom_path = object_get_canonical_path(OBJECT(cpu));
         info->value->thread_id = cpu->thread_id;
 #if defined(TARGET_I386)
         info->value->has_pc = true;
diff --git a/qapi-schema.json b/qapi-schema.json
index 9c92482..921ce70 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -679,6 +679,8 @@ 
 # @halted: true if the virtual CPU is in the halt state.  Halt usually refers
 #          to a processor specific low power mode.
 #
+# @qom_path: path to the CPU object in the QOM tree (since 2.4)
+#
 # @pc: #optional If the target is i386 or x86_64, this is the 64-bit instruction
 #                pointer.
 #                If the target is Sparc, this is the PC component of the
@@ -699,8 +701,9 @@ 
 #        data is sent to the client, the guest may no longer be halted.
 ##
 { 'struct': 'CpuInfo',
-  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', '*pc': 'int',
-           '*nip': 'int', '*npc': 'int', '*PC': 'int', 'thread_id': 'int'} }
+  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', 'qom_path': 'str',
+           '*pc': 'int', '*nip': 'int', '*npc': 'int', '*PC': 'int',
+           'thread_id': 'int'} }
 
 ##
 # @query-cpus:
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 7506774..14e109e 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2569,6 +2569,7 @@  Return a json-array. Each CPU is represented by a json-object, which contains:
 - "CPU": CPU index (json-int)
 - "current": true if this is the current CPU, false otherwise (json-bool)
 - "halted": true if the cpu is halted, false otherwise (json-bool)
+- "qom_path": path to the CPU object in the QOM tree (json-str)
 - Current program counter. The key's name depends on the architecture:
      "pc": i386/x86_64 (json-int)
      "nip": PPC (json-int)
@@ -2585,14 +2586,16 @@  Example:
             "CPU":0,
             "current":true,
             "halted":false,
-            "pc":3227107138
+            "qom_path":"/machine/unattached/device[0]",
+            "pc":3227107138,
             "thread_id":3134
          },
          {
             "CPU":1,
             "current":false,
             "halted":true,
-            "pc":7108165
+            "qom_path":"/machine/unattached/device[2]",
+            "pc":7108165,
             "thread_id":3135
          }
       ]