On 02/08/2018 03:48 AM, Viktor Mihajlovski wrote:
Presently s390x is the only architecture not exposing specific
CPU information via QMP query-cpus. Upstream discussion has shown
that it could make sense to report the architecture specific CPU
state, e.g. to detect that a CPU has been stopped.
With this change the output of query-cpus will look like this on
s390:
[{"arch": "s390", "current": true,
"props": {"core-id": 0}, "cpu_state": "operating", "CPU": 0,
"qom_path": "/machine/unattached/device[0]",
"halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu_state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]",
"halted": true, "thread_id": 63116}]
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
+++ b/qapi-schema.json
@@ -413,7 +413,7 @@
# Since: 2.6
##
{ 'enum': 'CpuInfoArch',
- 'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 'other' ] }
+ 'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 's390', 'other' ] }
Missing a documentation line that mentions when the enum grew. Also, has
a conflict with this other proposed addition, which demonstrates what
the documentation should look like (should be easy to resolve, though):
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg01986.html
##
+# @CpuInfoS390State:
+#
+# An enumeration of cpu states that can be assumed by a virtual
+# S390 CPU
+#
+# Since: 2.12
+##
+{ 'enum': 'CpuInfoS390State',
+ 'data': [ 'uninitialized', 'stopped', 'check_stop', 'operating', 'load' ] }
+
Is there a consistency reason for naming this 'check_stop', or can we go
with our preference for using dash 'check-stop'?
+##
+# @CpuInfoS390:
+#
+# Additional information about a virtual S390 CPU
+#
+# @cpu_state: the CPUs state
+#
+# Since: 2.12
+##
+{ 'struct': 'CpuInfoS390', 'data': { 'cpu_state': 'CpuInfoS390State' } }
Likewise for 'cpu-state'
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org