From patchwork Fri May 8 19:04:22 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eduardo Habkost X-Patchwork-Id: 470166 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 912B3140283 for ; Sat, 9 May 2015 05:05:01 +1000 (AEST) Received: from localhost ([::1]:57299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqnZz-0005My-4z for incoming@patchwork.ozlabs.org; Fri, 08 May 2015 15:04:59 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqnZj-00055b-Gf for qemu-devel@nongnu.org; Fri, 08 May 2015 15:04:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqnZf-0007H2-Go for qemu-devel@nongnu.org; Fri, 08 May 2015 15:04:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqnZf-0007FG-8Q for qemu-devel@nongnu.org; Fri, 08 May 2015 15:04:39 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t48J4Rl3003787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 8 May 2015 15:04:27 -0400 Received: from localhost (ovpn-113-208.phx2.redhat.com [10.3.113.208]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t48J4PJx010941; Fri, 8 May 2015 15:04:26 -0400 From: Eduardo Habkost To: qemu-devel@nongnu.org Date: Fri, 8 May 2015 16:04:22 -0300 Message-Id: <1431111862-26377-1-git-send-email-ehabkost@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id t48J4Rl3003787 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, mimu@linux.vnet.ibm.com, mdroth@linux.vnet.ibm.com, bharata@linux.vnet.ibm.com, agraf@suse.de, lcapitulino@redhat.com, borntraeger@de.ibm.com, Paolo Bonzini , cornelia.huck@de.ibm.com, Igor Mammedov , Jiri Denemark , =?UTF-8?q?Andreas=20F=C3=A4rber?= , david@gibson.dropbear.id.au Subject: [Qemu-devel] [PATCH v2] qmp: Add qom_path field to query-cpus command X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org This will allow clients to query additional information directly using qom-get on the CPU objects. Reviewed-by: David Gibson Reviewed-by: Andreas Färber Signed-off-by: Eduardo Habkost Reviewed-by: Eric Blake --- 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 Message-ID: <20150504183740.GM17796@thinpad.lan.raisama.net> Subject: Re: [Qemu-devel] [PATCH] cpu: Register QOM links at /machine/cpus/ 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', + '*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 } ]