Eduardo Habkost <ehabk...@redhat.com> writes: > This will allow clients to query additional information directly using > qom-get on the CPU objects. > > Reviewed-by: David Gibson <da...@gibson.dropbear.id.au> > Reviewed-by: Andreas Färber <afaer...@suse.de> > Signed-off-by: Eduardo Habkost <ehabk...@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 <ehabk...@redhat.com> > Message-ID: <20150504183740.gm17...@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!