2011-09-02 19:34:47 +02:00
|
|
|
# -*- Mode: Python -*-
|
2020-07-29 20:50:24 +02:00
|
|
|
# vim: filetype=python
|
2015-07-06 22:13:50 +02:00
|
|
|
##
|
|
|
|
|
# = Introduction
|
|
|
|
|
#
|
|
|
|
|
# This document describes all commands currently supported by QMP.
|
|
|
|
|
#
|
2023-04-28 12:54:29 +02:00
|
|
|
# Most of the time their usage is exactly the same as in the user
|
|
|
|
|
# Monitor, this means that any other document which also describe
|
|
|
|
|
# commands (the manpage, QEMU's manual, etc) can and should be
|
|
|
|
|
# consulted.
|
2015-07-06 22:13:50 +02:00
|
|
|
#
|
2023-04-28 12:54:29 +02:00
|
|
|
# QMP has two types of commands: regular and query commands. Regular
|
|
|
|
|
# commands usually change the Virtual Machine's state someway, while
|
|
|
|
|
# query commands just return information. The sections below are
|
|
|
|
|
# divided accordingly.
|
2015-07-06 22:13:50 +02:00
|
|
|
#
|
2023-04-28 12:54:29 +02:00
|
|
|
# It's important to observe that all communication examples are
|
|
|
|
|
# formatted in a reader-friendly way, so that they're easier to
|
|
|
|
|
# understand. However, in real protocol usage, they're emitted as a
|
|
|
|
|
# single line.
|
2015-07-06 22:13:50 +02:00
|
|
|
#
|
|
|
|
|
# Also, the following notation is used to denote data flow:
|
|
|
|
|
#
|
|
|
|
|
# Example:
|
|
|
|
|
#
|
2020-09-25 18:23:05 +02:00
|
|
|
# ::
|
|
|
|
|
#
|
|
|
|
|
# -> data issued by the Client
|
|
|
|
|
# <- Server data response
|
2011-09-02 19:34:47 +02:00
|
|
|
#
|
2023-04-28 12:54:29 +02:00
|
|
|
# Please, refer to the QMP specification (docs/interop/qmp-spec.txt)
|
|
|
|
|
# for detailed information on the Server command and response formats.
|
2015-07-06 22:13:50 +02:00
|
|
|
##
|
2011-09-02 19:34:48 +02:00
|
|
|
|
2020-02-24 15:30:03 +01:00
|
|
|
{ 'include': 'pragma.json' }
|
2017-03-15 13:56:54 +01:00
|
|
|
|
2018-02-26 20:48:58 +01:00
|
|
|
# Documentation generated with qapi-gen.py is in source order, with
|
2017-08-24 21:13:53 +02:00
|
|
|
# included sub-schemas inserted at the first include directive
|
|
|
|
|
# (subsequent include directives have no effect). To get a sane and
|
|
|
|
|
# stable order, it's best to include each sub-schema just once, or
|
2018-02-11 10:36:05 +01:00
|
|
|
# include it first right here.
|
2014-02-08 11:01:55 +01:00
|
|
|
|
2019-08-12 07:23:33 +02:00
|
|
|
{ 'include': 'error.json' }
|
2018-02-11 10:36:05 +01:00
|
|
|
{ 'include': 'common.json' }
|
|
|
|
|
{ 'include': 'sockets.json' }
|
|
|
|
|
{ 'include': 'run-state.json' }
|
|
|
|
|
{ 'include': 'crypto.json' }
|
2023-04-25 08:42:23 +02:00
|
|
|
{ 'include': 'job.json' }
|
2018-02-11 10:36:05 +01:00
|
|
|
{ 'include': 'block.json' }
|
2020-09-24 17:26:48 +02:00
|
|
|
{ 'include': 'block-export.json' }
|
2018-02-11 10:36:05 +01:00
|
|
|
{ 'include': 'char.json' }
|
2019-06-19 22:10:47 +02:00
|
|
|
{ 'include': 'dump.json' }
|
2018-02-11 10:36:05 +01:00
|
|
|
{ 'include': 'net.json' }
|
2018-12-21 15:40:24 +01:00
|
|
|
{ 'include': 'rdma.json' }
|
2018-02-11 10:36:05 +01:00
|
|
|
{ 'include': 'rocker.json' }
|
|
|
|
|
{ 'include': 'tpm.json' }
|
|
|
|
|
{ 'include': 'ui.json' }
|
authz: add QAuthZList object type for an access control list
Add a QAuthZList object type that implements the QAuthZ interface. This
built-in implementation maintains a trivial access control list with a
sequence of match rules and a final default policy. This replicates the
functionality currently provided by the qemu_acl module.
To create an instance of this object via the QMP monitor, the syntax
used would be:
{
"execute": "object-add",
"arguments": {
"qom-type": "authz-list",
"id": "authz0",
"props": {
"rules": [
{ "match": "fred", "policy": "allow", "format": "exact" },
{ "match": "bob", "policy": "allow", "format": "exact" },
{ "match": "danb", "policy": "deny", "format": "glob" },
{ "match": "dan*", "policy": "allow", "format": "exact" },
],
"policy": "deny"
}
}
}
This sets up an authorization rule that allows 'fred', 'bob' and anyone
whose name starts with 'dan', except for 'danb'. Everyone unmatched is
denied.
It is not currently possible to create this via -object, since there is
no syntax supported to specify non-scalar properties for objects. This
is likely to be addressed by later support for using JSON with -object,
or an equivalent approach.
In any case the future "authz-listfile" object can be used from the
CLI and is likely a better choice, as it allows the ACL to be refreshed
automatically on change.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-10-21 15:54:59 +02:00
|
|
|
{ 'include': 'authz.json' }
|
2018-02-11 10:36:05 +01:00
|
|
|
{ 'include': 'migration.json' }
|
|
|
|
|
{ 'include': 'transaction.json' }
|
|
|
|
|
{ 'include': 'trace.json' }
|
2021-03-18 16:55:10 +01:00
|
|
|
{ 'include': 'compat.json' }
|
2020-01-29 11:22:37 +01:00
|
|
|
{ 'include': 'control.json' }
|
2018-02-11 10:36:05 +01:00
|
|
|
{ 'include': 'introspect.json' }
|
2019-06-19 22:10:37 +02:00
|
|
|
{ 'include': 'qom.json' }
|
|
|
|
|
{ 'include': 'qdev.json' }
|
2019-06-19 22:10:41 +02:00
|
|
|
{ 'include': 'machine.json' }
|
2019-06-19 22:10:45 +02:00
|
|
|
{ 'include': 'machine-target.json' }
|
2020-10-03 19:13:14 +02:00
|
|
|
{ 'include': 'replay.json' }
|
2020-12-28 16:08:41 +01:00
|
|
|
{ 'include': 'yank.json' }
|
2018-02-11 10:36:05 +01:00
|
|
|
{ 'include': 'misc.json' }
|
2019-06-19 22:10:46 +02:00
|
|
|
{ 'include': 'misc-target.json' }
|
2019-03-08 23:34:12 +01:00
|
|
|
{ 'include': 'audio.json' }
|
2020-09-13 21:53:47 +02:00
|
|
|
{ 'include': 'acpi.json' }
|
2020-09-13 21:53:48 +02:00
|
|
|
{ 'include': 'pci.json' }
|
qmp: Support for querying stats
Gathering statistics is important for development, for monitoring and
for performance measurement. There are tools such as kvm_stat that do
this and they rely on the _user_ knowing the interesting data points
rather than the tool (which can treat them as opaque).
The commands introduced in this commit introduce QMP support for
querying stats; the goal is to take the capabilities of these tools
and making them available throughout the whole virtualization stack,
so that one can observe, monitor and measure virtual machines without
having shell access + root on the host that runs them.
query-stats returns a list of all stats per target type (only VM
and vCPU to start); future commits add extra options for specifying
stat names, vCPU qom paths, and providers. All these are used by the
HMP command "info stats". Because of the development usecases around
statistics, a good HMP interface is important.
query-stats-schemas returns a list of stats included in each target
type, with an option for specifying the provider. The concepts in the
schema are based on the KVM binary stats' own introspection data, just
translated to QAPI.
There are two reasons to have a separate schema that is not tied to
the QAPI schema. The first is the contents of the schemas: the new
introspection data provides different information than the QAPI data,
namely unit of measurement, how the numbers are gathered and change
(peak/instant/cumulative/histogram), and histogram bucket sizes.
There's really no reason to have this kind of metadata in the QAPI
introspection schema (except possibly for the unit of measure, but
there's a very weak justification).
Another reason is the dynamicity of the schema. The QAPI introspection
data is very much static; and while QOM is somewhat more dynamic,
generally we consider that to be a bug rather than a feature these days.
On the other hand, the statistics that are exposed by QEMU might be
passed through from another source, such as KVM, and the disadvantages of
manually updating the QAPI schema for outweight the benefits from vetting
the statistics and filtering out anything that seems "too unstable".
Running old QEMU with new kernel is a supported usecase; if old QEMU
cannot expose statistics from a new kernel, or if a kernel developer
needs to change QEMU before gathering new info from the new kernel,
then that is a poor user interface.
The framework provides a method to register callbacks for these QMP
commands. Most of the work in fact is done by the callbacks, and a
large majority of this patch is new QAPI structs and commands.
Examples (with KVM stats):
- Query all VM stats:
{ "execute": "query-stats", "arguments" : { "target": "vm" } }
{ "return": [
{ "provider": "kvm",
"stats": [
{ "name": "max_mmu_page_hash_collisions", "value": 0 },
{ "name": "max_mmu_rmap_size", "value": 0 },
{ "name": "nx_lpage_splits", "value": 148 },
... ] },
{ "provider": "xyz",
"stats": [ ... ] }
] }
- Query all vCPU stats:
{ "execute": "query-stats", "arguments" : { "target": "vcpu" } }
{ "return": [
{ "provider": "kvm",
"qom_path": "/machine/unattached/device[0]"
"stats": [
{ "name": "guest_mode", "value": 0 },
{ "name": "directed_yield_successful", "value": 0 },
{ "name": "directed_yield_attempted", "value": 106 },
... ] },
{ "provider": "kvm",
"qom_path": "/machine/unattached/device[1]"
"stats": [
{ "name": "guest_mode", "value": 0 },
{ "name": "directed_yield_successful", "value": 0 },
{ "name": "directed_yield_attempted", "value": 106 },
... ] },
] }
- Retrieve the schemas:
{ "execute": "query-stats-schemas" }
{ "return": [
{ "provider": "kvm",
"target": "vcpu",
"stats": [
{ "name": "guest_mode",
"unit": "none",
"base": 10,
"exponent": 0,
"type": "instant" },
{ "name": "directed_yield_successful",
"unit": "none",
"base": 10,
"exponent": 0,
"type": "cumulative" },
... ]
},
{ "provider": "kvm",
"target": "vm",
"stats": [
{ "name": "max_mmu_page_hash_collisions",
"unit": "none",
"base": 10,
"exponent": 0,
"type": "peak" },
... ]
},
{ "provider": "xyz",
"target": "vm",
"stats": [ ... ]
}
] }
Signed-off-by: Mark Kanda <mark.kanda@oracle.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 16:04:31 +01:00
|
|
|
{ 'include': 'stats.json' }
|
2022-08-11 14:24:39 +02:00
|
|
|
{ 'include': 'virtio.json' }
|
2023-03-01 11:58:36 +01:00
|
|
|
{ 'include': 'cryptodev.json' }
|
hw/mem/cxl_type3: Add CXL RAS Error Injection Support.
CXL uses PCI AER Internal errors to signal to the host that an error has
occurred. The host can then read more detailed status from the CXL RAS
capability.
For uncorrectable errors: support multiple injection in one operation
as this is needed to reliably test multiple header logging support in an
OS. The equivalent feature doesn't exist for correctable errors, so only
one error need be injected at a time.
Note:
- Header content needs to be manually specified in a fashion that
matches the specification for what can be in the header for each
error type.
Injection via QMP:
{ "execute": "qmp_capabilities" }
...
{ "execute": "cxl-inject-uncorrectable-errors",
"arguments": {
"path": "/machine/peripheral/cxl-pmem0",
"errors": [
{
"type": "cache-address-parity",
"header": [ 3, 4]
},
{
"type": "cache-data-parity",
"header": [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31]
},
{
"type": "internal",
"header": [ 1, 2, 4]
}
]
}}
...
{ "execute": "cxl-inject-correctable-error",
"arguments": {
"path": "/machine/peripheral/cxl-pmem0",
"type": "physical"
} }
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20230302133709.30373-9-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-02 14:37:09 +01:00
|
|
|
{ 'include': 'cxl.json' }
|