2011-09-02 21:34:47 +04:00
|
|
|
# -*- Mode: Python -*-
|
2015-07-06 23:13:50 +03:00
|
|
|
##
|
|
|
|
# = Introduction
|
|
|
|
#
|
|
|
|
# This document describes all commands currently supported by QMP.
|
|
|
|
#
|
|
|
|
# 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.
|
|
|
|
#
|
|
|
|
# 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.
|
|
|
|
#
|
|
|
|
# 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.
|
|
|
|
#
|
|
|
|
# Also, the following notation is used to denote data flow:
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# | -> data issued by the Client
|
|
|
|
# | <- Server data response
|
2011-09-02 21:34:47 +04:00
|
|
|
#
|
2017-07-29 01:46:01 +03:00
|
|
|
# Please, refer to the QMP specification (docs/interop/qmp-spec.txt) for
|
2015-07-06 23:13:50 +03:00
|
|
|
# detailed information on the Server command and response formats.
|
|
|
|
#
|
|
|
|
# = Stability Considerations
|
|
|
|
#
|
|
|
|
# The current QMP command set (described in this file) may be useful for a
|
|
|
|
# number of use cases, however it's limited and several commands have bad
|
|
|
|
# defined semantics, specially with regard to command completion.
|
|
|
|
#
|
|
|
|
# These problems are going to be solved incrementally in the next QEMU releases
|
|
|
|
# and we're going to establish a deprecation policy for badly defined commands.
|
|
|
|
#
|
|
|
|
# If you're planning to adopt QMP, please observe the following:
|
|
|
|
#
|
|
|
|
# 1. The deprecation policy will take effect and be documented soon, please
|
|
|
|
# check the documentation of each used command as soon as a new release of
|
|
|
|
# QEMU is available
|
|
|
|
#
|
|
|
|
# 2. DO NOT rely on anything which is not explicit documented
|
|
|
|
#
|
|
|
|
# 3. Errors, in special, are not documented. Applications should NOT check
|
|
|
|
# for specific errors classes or data (it's strongly recommended to only
|
|
|
|
# check for the "error" key)
|
|
|
|
#
|
|
|
|
##
|
2011-09-02 21:34:48 +04:00
|
|
|
|
2017-03-15 15:56:51 +03:00
|
|
|
{ 'pragma': { 'doc-required': true } }
|
|
|
|
|
2017-03-15 15:56:54 +03:00
|
|
|
# Whitelists to permit QAPI rule violations; think twice before you
|
|
|
|
# add to them!
|
|
|
|
{ 'pragma': {
|
|
|
|
# Commands allowed to return a non-dictionary:
|
|
|
|
'returns-whitelist': [
|
|
|
|
'human-monitor-command',
|
|
|
|
'qom-get',
|
|
|
|
'query-migrate-cache-size',
|
|
|
|
'query-tpm-models',
|
|
|
|
'query-tpm-types',
|
2017-03-15 15:56:55 +03:00
|
|
|
'ringbuf-read' ],
|
|
|
|
'name-case-whitelist': [
|
|
|
|
'ACPISlotType', # DIMM, visible through query-acpi-ospm-status
|
|
|
|
'CpuInfoMIPS', # PC, visible through query-cpu
|
|
|
|
'CpuInfoTricore', # PC, visible through query-cpu
|
|
|
|
'QapiErrorClass', # all members, visible through errors
|
|
|
|
'UuidInfo', # UUID, visible through query-uuid
|
|
|
|
'X86CPURegister32', # all members, visible indirectly through qom-get
|
|
|
|
'q_obj_CpuInfo-base' # CPU, visible through query-cpu
|
|
|
|
] } }
|
2017-03-15 15:56:54 +03:00
|
|
|
|
2017-08-24 22:13:53 +03:00
|
|
|
# Documentation generated with qapi2texi.py is in source order, with
|
|
|
|
# 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
|
|
|
|
# include it first in qapi-schema.json.
|
2014-02-08 14:01:55 +04:00
|
|
|
|
2017-08-24 22:13:53 +03:00
|
|
|
{ 'include': 'qapi/common.json' }
|
2017-08-24 22:13:56 +03:00
|
|
|
{ 'include': 'qapi/sockets.json' }
|
2017-08-24 22:13:57 +03:00
|
|
|
{ 'include': 'qapi/run-state.json' }
|
2015-03-13 20:39:26 +03:00
|
|
|
{ 'include': 'qapi/crypto.json' }
|
2014-06-05 15:45:30 +04:00
|
|
|
{ 'include': 'qapi/block.json' }
|
2017-08-24 22:13:58 +03:00
|
|
|
{ 'include': 'qapi/char.json' }
|
2017-08-24 22:13:59 +03:00
|
|
|
{ 'include': 'qapi/net.json' }
|
2017-08-24 22:13:55 +03:00
|
|
|
{ 'include': 'qapi/rocker.json' }
|
2017-08-24 22:14:03 +03:00
|
|
|
{ 'include': 'qapi/tpm.json' }
|
2017-08-24 22:14:00 +03:00
|
|
|
{ 'include': 'qapi/ui.json' }
|
2017-08-24 22:14:01 +03:00
|
|
|
{ 'include': 'qapi/migration.json' }
|
2017-08-24 22:14:02 +03:00
|
|
|
{ 'include': 'qapi/transaction.json' }
|
2014-08-25 15:19:57 +04:00
|
|
|
{ 'include': 'qapi/trace.json' }
|
qapi: New QMP command query-qmp-schema for QMP introspection
qapi/introspect.json defines the introspection schema. It's designed
for QMP introspection, but should do for similar uses, such as QGA.
The introspection schema does not reflect all the rules and
restrictions that apply to QAPI schemata. A valid QAPI schema has an
introspection value conforming to the introspection schema, but the
converse is not true.
Introspection lowers away a number of schema details, and makes
implicit things explicit:
* The built-in types are declared with their JSON type.
All integer types are mapped to 'int', because how many bits we use
internally is an implementation detail. It could be pressed into
external interface service as very approximate range information,
but that's a bad idea. If we need range information, we better do
it properly.
* Implicit type definitions are made explicit, and given
auto-generated names:
- Array types, named by appending "List" to the name of their
element type, like in generated C.
- The enumeration types implicitly defined by simple union types,
named by appending "Kind" to the name of their simple union type,
like in generated C.
- Types that don't occur in generated C. Their names start with ':'
so they don't clash with the user's names.
* All type references are by name.
* The struct and union types are generalized into an object type.
* Base types are flattened.
* Commands take a single argument and return a single result.
Dictionary argument or list result is an implicit type definition.
The empty object type is used when a command takes no arguments or
produces no results.
The argument is always of object type, but the introspection schema
doesn't reflect that.
The 'gen': false directive is omitted as implementation detail.
The 'success-response' directive is omitted as well for now, even
though it's not an implementation detail, because it's not used by
QMP.
* Events carry a single data value.
Implicit type definition and empty object type use, just like for
commands.
The value is of object type, but the introspection schema doesn't
reflect that.
* Types not used by commands or events are omitted.
Indirect use counts as use.
* Optional members have a default, which can only be null right now
Instead of a mandatory "optional" flag, we have an optional default.
No default means mandatory, default null means optional without
default value. Non-null is available for optional with default
(possible future extension).
* Clients should *not* look up types by name, because type names are
not ABI. Look up the command or event you're interested in, then
follow the references.
TODO Should we hide the type names to eliminate the temptation?
New generator scripts/qapi-introspect.py computes an introspection
value for its input, and generates a C variable holding it.
It can generate awfully long lines. Marked TODO.
A new test-qmp-input-visitor test case feeds its result for both
tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
QmpInputVisitor to verify it actually conforms to the schema.
New QMP command query-qmp-schema takes its return value from that
variable. Its reply is some 85KiBytes for me right now.
If this turns out to be too much, we have a couple of options:
* We can use shorter names in the JSON. Not the QMP style.
* Optionally return the sub-schema for commands and events given as
arguments.
Right now qmp_query_schema() sends the string literal computed by
qmp-introspect.py. To compute sub-schema at run time, we'd have to
duplicate parts of qapi-introspect.py in C. Unattractive.
* Let clients cache the output of query-qmp-schema.
It changes only on QEMU upgrades, i.e. rarely. Provide a command
query-qmp-schema-hash. Clients can have a cache indexed by hash,
and re-query the schema only when they don't have it cached. Even
simpler: put the hash in the QMP greeting.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
2015-09-16 14:06:28 +03:00
|
|
|
{ 'include': 'qapi/introspect.json' }
|
|
|
|
|
2017-01-13 17:41:23 +03:00
|
|
|
##
|
2017-08-24 22:14:08 +03:00
|
|
|
# = Miscellanea
|
2017-01-13 17:41:23 +03:00
|
|
|
##
|
|
|
|
|
2016-09-12 12:18:57 +03:00
|
|
|
##
|
|
|
|
# @qmp_capabilities:
|
|
|
|
#
|
|
|
|
# Enable QMP capabilities.
|
|
|
|
#
|
|
|
|
# Arguments: None.
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "qmp_capabilities" }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
|
|
|
# Notes: This command is valid exactly when first connecting: it must be
|
|
|
|
# issued before any other command will be accepted, and will fail once the
|
2017-07-29 01:46:01 +03:00
|
|
|
# monitor is accepting other commands. (see qemu docs/interop/qmp-spec.txt)
|
2016-09-12 12:18:57 +03:00
|
|
|
#
|
|
|
|
# Since: 0.13
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'command': 'qmp_capabilities' }
|
|
|
|
|
2017-08-24 22:14:07 +03:00
|
|
|
##
|
|
|
|
# @VersionTriple:
|
|
|
|
#
|
|
|
|
# A three-part version number.
|
|
|
|
#
|
|
|
|
# @major: The major version number.
|
|
|
|
#
|
|
|
|
# @minor: The minor version number.
|
|
|
|
#
|
|
|
|
# @micro: The micro version number.
|
|
|
|
#
|
|
|
|
# Since: 2.4
|
|
|
|
##
|
|
|
|
{ 'struct': 'VersionTriple',
|
|
|
|
'data': {'major': 'int', 'minor': 'int', 'micro': 'int'} }
|
|
|
|
|
|
|
|
|
|
|
|
##
|
|
|
|
# @VersionInfo:
|
|
|
|
#
|
|
|
|
# A description of QEMU's version.
|
|
|
|
#
|
|
|
|
# @qemu: The version of QEMU. By current convention, a micro
|
|
|
|
# version of 50 signifies a development branch. A micro version
|
|
|
|
# greater than or equal to 90 signifies a release candidate for
|
|
|
|
# the next minor version. A micro version of less than 50
|
|
|
|
# signifies a stable release.
|
|
|
|
#
|
|
|
|
# @package: QEMU will always set this field to an empty string. Downstream
|
|
|
|
# versions of QEMU should set this to a non-empty string. The
|
|
|
|
# exact format depends on the downstream however it highly
|
|
|
|
# recommended that a unique name is used.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'VersionInfo',
|
|
|
|
'data': {'qemu': 'VersionTriple', 'package': 'str'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-version:
|
|
|
|
#
|
|
|
|
# Returns the current version of QEMU.
|
|
|
|
#
|
|
|
|
# Returns: A @VersionInfo object describing the current version of QEMU.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-version" }
|
|
|
|
# <- {
|
|
|
|
# "return":{
|
|
|
|
# "qemu":{
|
|
|
|
# "major":0,
|
|
|
|
# "minor":11,
|
|
|
|
# "micro":5
|
|
|
|
# },
|
|
|
|
# "package":""
|
|
|
|
# }
|
|
|
|
# }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'command': 'query-version', 'returns': 'VersionInfo' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @CommandInfo:
|
|
|
|
#
|
|
|
|
# Information about a QMP command
|
|
|
|
#
|
|
|
|
# @name: The command name
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'CommandInfo', 'data': {'name': 'str'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-commands:
|
|
|
|
#
|
|
|
|
# Return a list of supported QMP commands by this server
|
|
|
|
#
|
|
|
|
# Returns: A list of @CommandInfo for all supported commands
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-commands" }
|
|
|
|
# <- {
|
|
|
|
# "return":[
|
|
|
|
# {
|
|
|
|
# "name":"query-balloon"
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "name":"system_powerdown"
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
#
|
|
|
|
# Note: This example has been shortened as the real response is too long.
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'command': 'query-commands', 'returns': ['CommandInfo'] }
|
|
|
|
|
2014-02-08 14:01:55 +04:00
|
|
|
##
|
2015-07-03 12:51:01 +03:00
|
|
|
# @LostTickPolicy:
|
2014-02-08 14:01:55 +04:00
|
|
|
#
|
|
|
|
# Policy for handling lost ticks in timer devices.
|
|
|
|
#
|
|
|
|
# @discard: throw away the missed tick(s) and continue with future injection
|
|
|
|
# normally. Guest time may be delayed, unless the OS has explicit
|
|
|
|
# handling of lost ticks
|
|
|
|
#
|
|
|
|
# @delay: continue to deliver ticks at the normal rate. Guest time will be
|
|
|
|
# delayed due to the late tick
|
|
|
|
#
|
|
|
|
# @merge: merge the missed tick(s) into one tick and inject. Guest time
|
|
|
|
# may be delayed, depending on how the OS reacts to the merging
|
|
|
|
# of ticks
|
|
|
|
#
|
|
|
|
# @slew: deliver ticks at a higher rate to catch up with the missed tick. The
|
|
|
|
# guest time should not be delayed once catchup is complete.
|
|
|
|
#
|
|
|
|
# Since: 2.0
|
|
|
|
##
|
|
|
|
{ 'enum': 'LostTickPolicy',
|
|
|
|
'data': ['discard', 'delay', 'merge', 'slew' ] }
|
|
|
|
|
2016-11-17 18:54:51 +03:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @add_client:
|
2012-09-13 23:52:20 +04:00
|
|
|
#
|
|
|
|
# Allow client connections for VNC, Spice and socket based
|
|
|
|
# character devices to be passed in to QEMU via SCM_RIGHTS.
|
|
|
|
#
|
|
|
|
# @protocol: protocol name. Valid names are "vnc", "spice" or the
|
|
|
|
# name of a character device (eg. from -chardev id=XXXX)
|
|
|
|
#
|
|
|
|
# @fdname: file descriptor name previously passed via 'getfd' command
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @skipauth: whether to skip authentication. Only applies
|
2012-09-13 23:52:20 +04:00
|
|
|
# to "vnc" and "spice" protocols
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @tls: whether to perform TLS. Only applies to the "spice"
|
2012-09-13 23:52:20 +04:00
|
|
|
# protocol
|
|
|
|
#
|
|
|
|
# Returns: nothing on success.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 11:06:34 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "add_client", "arguments": { "protocol": "vnc",
|
|
|
|
# "fdname": "myclient" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2012-09-13 23:52:20 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'add_client',
|
|
|
|
'data': { 'protocol': 'str', 'fdname': 'str', '*skipauth': 'bool',
|
|
|
|
'*tls': 'bool' } }
|
|
|
|
|
2011-09-02 21:34:48 +04:00
|
|
|
##
|
|
|
|
# @NameInfo:
|
|
|
|
#
|
|
|
|
# Guest name information.
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @name: The name of the guest
|
2011-09-02 21:34:48 +04:00
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 0.14.0
|
2011-09-02 21:34:48 +04:00
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'NameInfo', 'data': {'*name': 'str'} }
|
2011-09-02 21:34:48 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-name:
|
|
|
|
#
|
|
|
|
# Return the name information of a guest.
|
|
|
|
#
|
|
|
|
# Returns: @NameInfo of the guest
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 0.14.0
|
2016-06-23 11:07:26 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-name" }
|
|
|
|
# <- { "return": { "name": "qemu-name" } }
|
|
|
|
#
|
2011-09-02 21:34:48 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-name', 'returns': 'NameInfo' }
|
2011-08-27 00:38:13 +04:00
|
|
|
|
2011-09-12 22:10:53 +04:00
|
|
|
##
|
|
|
|
# @KvmInfo:
|
|
|
|
#
|
|
|
|
# Information about support for KVM acceleration
|
|
|
|
#
|
|
|
|
# @enabled: true if KVM acceleration is active
|
|
|
|
#
|
|
|
|
# @present: true if KVM acceleration is built into this executable
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'KvmInfo', 'data': {'enabled': 'bool', 'present': 'bool'} }
|
2011-09-12 22:10:53 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-kvm:
|
|
|
|
#
|
|
|
|
# Returns information about KVM acceleration
|
|
|
|
#
|
|
|
|
# Returns: @KvmInfo
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 11:07:57 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-kvm" }
|
|
|
|
# <- { "return": { "enabled": true, "present": true } }
|
|
|
|
#
|
2011-09-12 22:10:53 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-kvm', 'returns': 'KvmInfo' }
|
|
|
|
|
2011-09-14 00:16:25 +04:00
|
|
|
##
|
|
|
|
# @UuidInfo:
|
|
|
|
#
|
2016-06-23 11:10:54 +03:00
|
|
|
# Guest UUID information (Universally Unique Identifier).
|
2011-09-14 00:16:25 +04:00
|
|
|
#
|
|
|
|
# @UUID: the UUID of the guest
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Notes: If no UUID was specified for the guest, a null UUID is returned.
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'UuidInfo', 'data': {'UUID': 'str'} }
|
2011-09-14 00:16:25 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-uuid:
|
|
|
|
#
|
|
|
|
# Query the guest UUID information.
|
|
|
|
#
|
|
|
|
# Returns: The @UuidInfo for the guest
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 0.14.0
|
2016-06-23 11:10:54 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-uuid" }
|
|
|
|
# <- { "return": { "UUID": "550e8400-e29b-41d4-a716-446655440000" } }
|
|
|
|
#
|
2011-09-14 00:16:25 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-uuid', 'returns': 'UuidInfo' }
|
|
|
|
|
2012-05-21 20:59:51 +04:00
|
|
|
##
|
|
|
|
# @EventInfo:
|
|
|
|
#
|
|
|
|
# Information about a QMP event
|
|
|
|
#
|
|
|
|
# @name: The event name
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'EventInfo', 'data': {'name': 'str'} }
|
2012-05-21 20:59:51 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-events:
|
|
|
|
#
|
|
|
|
# Return a list of supported QMP events by this server
|
|
|
|
#
|
|
|
|
# Returns: A list of @EventInfo for all supported events
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
2016-06-23 11:18:23 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-events" }
|
|
|
|
# <- {
|
|
|
|
# "return": [
|
|
|
|
# {
|
|
|
|
# "name":"SHUTDOWN"
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "name":"RESET"
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
#
|
|
|
|
# Note: This example has been shortened as the real response is too long.
|
|
|
|
#
|
2012-05-21 20:59:51 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-events', 'returns': ['EventInfo'] }
|
|
|
|
|
2011-09-21 23:38:35 +04:00
|
|
|
##
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
# @CpuInfoArch:
|
2011-09-21 23:38:35 +04:00
|
|
|
#
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
# An enumeration of cpu types that enable additional information during
|
|
|
|
# @query-cpus.
|
|
|
|
#
|
|
|
|
# Since: 2.6
|
|
|
|
##
|
|
|
|
{ 'enum': 'CpuInfoArch',
|
|
|
|
'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 'other' ] }
|
|
|
|
|
|
|
|
##
|
2016-03-18 01:48:40 +03:00
|
|
|
# @CpuInfo:
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
#
|
2016-03-18 01:48:40 +03:00
|
|
|
# Information about a virtual CPU
|
2011-09-21 23:38:35 +04:00
|
|
|
#
|
|
|
|
# @CPU: the index of the virtual CPU
|
|
|
|
#
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
# @current: this only exists for backwards compatibility and should be ignored
|
2012-07-17 18:17:10 +04:00
|
|
|
#
|
2011-09-21 23:38:35 +04:00
|
|
|
# @halted: true if the virtual CPU is in the halt state. Halt usually refers
|
|
|
|
# to a processor specific low power mode.
|
|
|
|
#
|
2015-05-08 22:04:22 +03:00
|
|
|
# @qom_path: path to the CPU object in the QOM tree (since 2.4)
|
|
|
|
#
|
2011-09-21 23:38:35 +04:00
|
|
|
# @thread_id: ID of the underlying host thread
|
|
|
|
#
|
2017-05-10 14:29:55 +03:00
|
|
|
# @props: properties describing to which node/socket/core/thread
|
|
|
|
# virtual CPU belongs to, provided if supported by board (since 2.10)
|
|
|
|
#
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
# @arch: architecture of the cpu, which determines which additional fields
|
|
|
|
# will be listed (since 2.6)
|
|
|
|
#
|
2011-09-21 23:38:35 +04:00
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Notes: @halted is a transient state that changes frequently. By the time the
|
|
|
|
# data is sent to the client, the guest may no longer be halted.
|
|
|
|
##
|
2016-03-18 01:48:40 +03:00
|
|
|
{ 'union': 'CpuInfo',
|
|
|
|
'base': {'CPU': 'int', 'current': 'bool', 'halted': 'bool',
|
2017-05-10 14:29:55 +03:00
|
|
|
'qom_path': 'str', 'thread_id': 'int',
|
|
|
|
'*props': 'CpuInstanceProperties', 'arch': 'CpuInfoArch' },
|
2016-03-18 01:48:40 +03:00
|
|
|
'discriminator': 'arch',
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
'data': { 'x86': 'CpuInfoX86',
|
|
|
|
'sparc': 'CpuInfoSPARC',
|
|
|
|
'ppc': 'CpuInfoPPC',
|
|
|
|
'mips': 'CpuInfoMIPS',
|
|
|
|
'tricore': 'CpuInfoTricore',
|
|
|
|
'other': 'CpuInfoOther' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @CpuInfoX86:
|
|
|
|
#
|
|
|
|
# Additional information about a virtual i386 or x86_64 CPU
|
|
|
|
#
|
|
|
|
# @pc: the 64-bit instruction pointer
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.6
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
##
|
|
|
|
{ 'struct': 'CpuInfoX86', 'data': { 'pc': 'int' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @CpuInfoSPARC:
|
|
|
|
#
|
|
|
|
# Additional information about a virtual SPARC CPU
|
|
|
|
#
|
|
|
|
# @pc: the PC component of the instruction pointer
|
|
|
|
#
|
|
|
|
# @npc: the NPC component of the instruction pointer
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.6
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
##
|
|
|
|
{ 'struct': 'CpuInfoSPARC', 'data': { 'pc': 'int', 'npc': 'int' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @CpuInfoPPC:
|
|
|
|
#
|
|
|
|
# Additional information about a virtual PPC CPU
|
|
|
|
#
|
|
|
|
# @nip: the instruction pointer
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.6
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
##
|
|
|
|
{ 'struct': 'CpuInfoPPC', 'data': { 'nip': 'int' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @CpuInfoMIPS:
|
|
|
|
#
|
|
|
|
# Additional information about a virtual MIPS CPU
|
|
|
|
#
|
|
|
|
# @PC: the instruction pointer
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.6
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
##
|
|
|
|
{ 'struct': 'CpuInfoMIPS', 'data': { 'PC': 'int' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @CpuInfoTricore:
|
|
|
|
#
|
|
|
|
# Additional information about a virtual Tricore CPU
|
|
|
|
#
|
|
|
|
# @PC: the instruction pointer
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.6
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
##
|
|
|
|
{ 'struct': 'CpuInfoTricore', 'data': { 'PC': 'int' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @CpuInfoOther:
|
|
|
|
#
|
|
|
|
# No additional information is available about the virtual CPU
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.6
|
cpu: Convert CpuInfo into flat union
The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.
When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture. But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture. With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.
This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'. Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:59 +03:00
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'struct': 'CpuInfoOther', 'data': { } }
|
2011-09-21 23:38:35 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-cpus:
|
|
|
|
#
|
|
|
|
# Returns a list of information about each virtual CPU.
|
|
|
|
#
|
|
|
|
# Returns: a list of @CpuInfo for each virtual CPU
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 11:56:56 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-cpus" }
|
|
|
|
# <- { "return": [
|
|
|
|
# {
|
|
|
|
# "CPU":0,
|
|
|
|
# "current":true,
|
|
|
|
# "halted":false,
|
|
|
|
# "qom_path":"/machine/unattached/device[0]",
|
|
|
|
# "arch":"x86",
|
|
|
|
# "pc":3227107138,
|
|
|
|
# "thread_id":3134
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "CPU":1,
|
|
|
|
# "current":false,
|
|
|
|
# "halted":true,
|
|
|
|
# "qom_path":"/machine/unattached/device[2]",
|
|
|
|
# "arch":"x86",
|
|
|
|
# "pc":7108165,
|
|
|
|
# "thread_id":3135
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
#
|
2011-09-21 23:38:35 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-cpus', 'returns': ['CpuInfo'] }
|
|
|
|
|
2014-02-27 14:48:42 +04:00
|
|
|
##
|
|
|
|
# @IOThreadInfo:
|
|
|
|
#
|
|
|
|
# Information about an iothread
|
|
|
|
#
|
|
|
|
# @id: the identifier of the iothread
|
|
|
|
#
|
|
|
|
# @thread-id: ID of the underlying host thread
|
|
|
|
#
|
2017-02-10 12:41:17 +03:00
|
|
|
# @poll-max-ns: maximum polling time in ns, 0 means polling is disabled
|
|
|
|
# (since 2.9)
|
|
|
|
#
|
|
|
|
# @poll-grow: how many ns will be added to polling time, 0 means that it's not
|
|
|
|
# configured (since 2.9)
|
|
|
|
#
|
|
|
|
# @poll-shrink: how many ns will be removed from polling time, 0 means that
|
|
|
|
# it's not configured (since 2.9)
|
|
|
|
#
|
2014-02-27 14:48:42 +04:00
|
|
|
# Since: 2.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'IOThreadInfo',
|
2017-02-10 12:41:17 +03:00
|
|
|
'data': {'id': 'str',
|
|
|
|
'thread-id': 'int',
|
|
|
|
'poll-max-ns': 'int',
|
|
|
|
'poll-grow': 'int',
|
|
|
|
'poll-shrink': 'int' } }
|
2014-02-27 14:48:42 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-iothreads:
|
|
|
|
#
|
|
|
|
# Returns a list of information about each iothread.
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Note: this list excludes the QEMU main loop thread, which is not declared
|
2014-02-27 14:48:42 +04:00
|
|
|
# using the -object iothread command-line option. It is always the main thread
|
|
|
|
# of the process.
|
|
|
|
#
|
|
|
|
# Returns: a list of @IOThreadInfo for each iothread
|
|
|
|
#
|
|
|
|
# Since: 2.0
|
2016-06-23 11:57:59 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-iothreads" }
|
|
|
|
# <- { "return": [
|
|
|
|
# {
|
|
|
|
# "id":"iothread0",
|
|
|
|
# "thread-id":3134
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "id":"iothread1",
|
|
|
|
# "thread-id":3135
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
#
|
2014-02-27 14:48:42 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-iothreads', 'returns': ['IOThreadInfo'] }
|
|
|
|
|
2011-10-21 17:41:37 +04:00
|
|
|
##
|
|
|
|
# @BalloonInfo:
|
|
|
|
#
|
|
|
|
# Information about the guest balloon device.
|
|
|
|
#
|
|
|
|
# @actual: the number of bytes the balloon currently contains
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'BalloonInfo', 'data': {'actual': 'int' } }
|
2011-10-21 17:41:37 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-balloon:
|
|
|
|
#
|
|
|
|
# Return information about the balloon device.
|
|
|
|
#
|
|
|
|
# Returns: @BalloonInfo on success
|
2016-06-23 12:40:02 +03:00
|
|
|
#
|
2011-10-21 17:41:37 +04:00
|
|
|
# If the balloon driver is enabled but not functional because the KVM
|
|
|
|
# kernel module cannot support it, KvmMissingCap
|
2016-06-23 12:40:02 +03:00
|
|
|
#
|
2011-10-21 17:41:37 +04:00
|
|
|
# If no balloon device is present, DeviceNotActive
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 12:40:02 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-balloon" }
|
|
|
|
# <- { "return": {
|
|
|
|
# "actual": 1073741824,
|
|
|
|
# }
|
|
|
|
# }
|
|
|
|
#
|
2011-10-21 17:41:37 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-balloon', 'returns': 'BalloonInfo' }
|
|
|
|
|
2017-08-24 22:14:05 +03:00
|
|
|
##
|
|
|
|
# @BALLOON_CHANGE:
|
|
|
|
#
|
|
|
|
# Emitted when the guest changes the actual BALLOON level. This value is
|
|
|
|
# equivalent to the @actual field return by the 'query-balloon' command
|
|
|
|
#
|
|
|
|
# @actual: actual level of the guest memory balloon in bytes
|
|
|
|
#
|
|
|
|
# Note: this event is rate-limited.
|
|
|
|
#
|
|
|
|
# Since: 1.2
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# <- { "event": "BALLOON_CHANGE",
|
|
|
|
# "data": { "actual": 944766976 },
|
|
|
|
# "timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'event': 'BALLOON_CHANGE',
|
|
|
|
'data': { 'actual': 'int' } }
|
|
|
|
|
2011-10-21 20:15:33 +04:00
|
|
|
##
|
|
|
|
# @PciMemoryRange:
|
|
|
|
#
|
|
|
|
# A PCI device memory region
|
|
|
|
#
|
|
|
|
# @base: the starting address (guest physical)
|
|
|
|
#
|
|
|
|
# @limit: the ending address (guest physical)
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'PciMemoryRange', 'data': {'base': 'int', 'limit': 'int'} }
|
2011-10-21 20:15:33 +04:00
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @PciMemoryRegion:
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
|
|
|
# Information about a PCI device I/O region.
|
|
|
|
#
|
|
|
|
# @bar: the index of the Base Address Register for this region
|
|
|
|
#
|
|
|
|
# @type: 'io' if the region is a PIO region
|
|
|
|
# 'memory' if the region is a MMIO region
|
|
|
|
#
|
2016-06-23 12:44:21 +03:00
|
|
|
# @size: memory size
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @prefetch: if @type is 'memory', true if the memory is prefetchable
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @mem_type_64: if @type is 'memory', true if the BAR is 64-bit
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'PciMemoryRegion',
|
2011-10-21 20:15:33 +04:00
|
|
|
'data': {'bar': 'int', 'type': 'str', 'address': 'int', 'size': 'int',
|
|
|
|
'*prefetch': 'bool', '*mem_type_64': 'bool' } }
|
|
|
|
|
|
|
|
##
|
2015-05-04 18:05:32 +03:00
|
|
|
# @PciBusInfo:
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
2015-05-04 18:05:32 +03:00
|
|
|
# Information about a bus of a PCI Bridge device
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
2015-05-04 18:05:32 +03:00
|
|
|
# @number: primary bus interface number. This should be the number of the
|
|
|
|
# bus the device resides on.
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
2015-05-04 18:05:32 +03:00
|
|
|
# @secondary: secondary bus interface number. This is the number of the
|
|
|
|
# main bus for the bridge
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
2015-05-04 18:05:32 +03:00
|
|
|
# @subordinate: This is the highest number bus that resides below the
|
|
|
|
# bridge.
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
2015-05-04 18:05:32 +03:00
|
|
|
# @io_range: The PIO range for all devices on this bridge
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
2015-05-04 18:05:32 +03:00
|
|
|
# @memory_range: The MMIO range for all devices on this bridge
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
2015-05-04 18:05:32 +03:00
|
|
|
# @prefetchable_range: The range of prefetchable MMIO for all devices on
|
|
|
|
# this bridge
|
|
|
|
#
|
|
|
|
# Since: 2.4
|
|
|
|
##
|
|
|
|
{ 'struct': 'PciBusInfo',
|
|
|
|
'data': {'number': 'int', 'secondary': 'int', 'subordinate': 'int',
|
|
|
|
'io_range': 'PciMemoryRange',
|
|
|
|
'memory_range': 'PciMemoryRange',
|
|
|
|
'prefetchable_range': 'PciMemoryRange' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @PciBridgeInfo:
|
|
|
|
#
|
|
|
|
# Information about a PCI Bridge device
|
|
|
|
#
|
|
|
|
# @bus: information about the bus the device resides on
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
|
|
|
# @devices: a list of @PciDeviceInfo for each device on this bridge
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'PciBridgeInfo',
|
2015-05-04 18:05:32 +03:00
|
|
|
'data': {'bus': 'PciBusInfo', '*devices': ['PciDeviceInfo']} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @PciDeviceClass:
|
|
|
|
#
|
|
|
|
# Information about the Class of a PCI device
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @desc: a string description of the device's class
|
2015-05-04 18:05:32 +03:00
|
|
|
#
|
|
|
|
# @class: the class code of the device
|
|
|
|
#
|
|
|
|
# Since: 2.4
|
|
|
|
##
|
|
|
|
{ 'struct': 'PciDeviceClass',
|
|
|
|
'data': {'*desc': 'str', 'class': 'int'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @PciDeviceId:
|
|
|
|
#
|
|
|
|
# Information about the Id of a PCI device
|
|
|
|
#
|
|
|
|
# @device: the PCI device id
|
|
|
|
#
|
|
|
|
# @vendor: the PCI vendor id
|
|
|
|
#
|
|
|
|
# Since: 2.4
|
|
|
|
##
|
|
|
|
{ 'struct': 'PciDeviceId',
|
|
|
|
'data': {'device': 'int', 'vendor': 'int'} }
|
2011-10-21 20:15:33 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @PciDeviceInfo:
|
|
|
|
#
|
|
|
|
# Information about a PCI device
|
|
|
|
#
|
|
|
|
# @bus: the bus number of the device
|
|
|
|
#
|
|
|
|
# @slot: the slot the device is located in
|
|
|
|
#
|
|
|
|
# @function: the function of the slot used by the device
|
|
|
|
#
|
2015-05-04 18:05:32 +03:00
|
|
|
# @class_info: the class of the device
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
2015-05-04 18:05:32 +03:00
|
|
|
# @id: the PCI device id
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @irq: if an IRQ is assigned to the device, the IRQ number
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
|
|
|
# @qdev_id: the device name of the PCI device
|
|
|
|
#
|
|
|
|
# @pci_bridge: if the device is a PCI bridge, the bridge information
|
|
|
|
#
|
|
|
|
# @regions: a list of the PCI I/O regions associated with the device
|
|
|
|
#
|
|
|
|
# Notes: the contents of @class_info.desc are not stable and should only be
|
|
|
|
# treated as informational.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'PciDeviceInfo',
|
2011-10-21 20:15:33 +04:00
|
|
|
'data': {'bus': 'int', 'slot': 'int', 'function': 'int',
|
2015-05-04 18:05:32 +03:00
|
|
|
'class_info': 'PciDeviceClass', 'id': 'PciDeviceId',
|
2011-10-21 20:15:33 +04:00
|
|
|
'*irq': 'int', 'qdev_id': 'str', '*pci_bridge': 'PciBridgeInfo',
|
|
|
|
'regions': ['PciMemoryRegion']} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @PciInfo:
|
|
|
|
#
|
|
|
|
# Information about a PCI bus
|
|
|
|
#
|
|
|
|
# @bus: the bus index
|
|
|
|
#
|
|
|
|
# @devices: a list of devices on this bus
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'PciInfo', 'data': {'bus': 'int', 'devices': ['PciDeviceInfo']} }
|
2011-10-21 20:15:33 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-pci:
|
|
|
|
#
|
|
|
|
# Return information about the PCI bus topology of the guest.
|
|
|
|
#
|
2016-06-23 12:44:21 +03:00
|
|
|
# Returns: a list of @PciInfo for each PCI bus. Each bus is
|
|
|
|
# represented by a json-object, which has a key with a json-array of
|
|
|
|
# all PCI devices attached to it. Each device is represented by a
|
|
|
|
# json-object.
|
2011-10-21 20:15:33 +04:00
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 12:44:21 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-pci" }
|
|
|
|
# <- { "return": [
|
|
|
|
# {
|
|
|
|
# "bus": 0,
|
|
|
|
# "devices": [
|
|
|
|
# {
|
|
|
|
# "bus": 0,
|
|
|
|
# "qdev_id": "",
|
|
|
|
# "slot": 0,
|
|
|
|
# "class_info": {
|
|
|
|
# "class": 1536,
|
|
|
|
# "desc": "Host bridge"
|
|
|
|
# },
|
|
|
|
# "id": {
|
|
|
|
# "device": 32902,
|
|
|
|
# "vendor": 4663
|
|
|
|
# },
|
|
|
|
# "function": 0,
|
|
|
|
# "regions": [
|
|
|
|
# ]
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "bus": 0,
|
|
|
|
# "qdev_id": "",
|
|
|
|
# "slot": 1,
|
|
|
|
# "class_info": {
|
|
|
|
# "class": 1537,
|
|
|
|
# "desc": "ISA bridge"
|
|
|
|
# },
|
|
|
|
# "id": {
|
|
|
|
# "device": 32902,
|
|
|
|
# "vendor": 28672
|
|
|
|
# },
|
|
|
|
# "function": 0,
|
|
|
|
# "regions": [
|
|
|
|
# ]
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "bus": 0,
|
|
|
|
# "qdev_id": "",
|
|
|
|
# "slot": 1,
|
|
|
|
# "class_info": {
|
|
|
|
# "class": 257,
|
|
|
|
# "desc": "IDE controller"
|
|
|
|
# },
|
|
|
|
# "id": {
|
|
|
|
# "device": 32902,
|
|
|
|
# "vendor": 28688
|
|
|
|
# },
|
|
|
|
# "function": 1,
|
|
|
|
# "regions": [
|
|
|
|
# {
|
|
|
|
# "bar": 4,
|
|
|
|
# "size": 16,
|
|
|
|
# "address": 49152,
|
|
|
|
# "type": "io"
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "bus": 0,
|
|
|
|
# "qdev_id": "",
|
|
|
|
# "slot": 2,
|
|
|
|
# "class_info": {
|
|
|
|
# "class": 768,
|
|
|
|
# "desc": "VGA controller"
|
|
|
|
# },
|
|
|
|
# "id": {
|
|
|
|
# "device": 4115,
|
|
|
|
# "vendor": 184
|
|
|
|
# },
|
|
|
|
# "function": 0,
|
|
|
|
# "regions": [
|
|
|
|
# {
|
|
|
|
# "prefetch": true,
|
|
|
|
# "mem_type_64": false,
|
|
|
|
# "bar": 0,
|
|
|
|
# "size": 33554432,
|
|
|
|
# "address": 4026531840,
|
|
|
|
# "type": "memory"
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "prefetch": false,
|
|
|
|
# "mem_type_64": false,
|
|
|
|
# "bar": 1,
|
|
|
|
# "size": 4096,
|
|
|
|
# "address": 4060086272,
|
|
|
|
# "type": "memory"
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "prefetch": false,
|
|
|
|
# "mem_type_64": false,
|
|
|
|
# "bar": 6,
|
|
|
|
# "size": 65536,
|
|
|
|
# "address": -1,
|
|
|
|
# "type": "memory"
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "bus": 0,
|
|
|
|
# "qdev_id": "",
|
|
|
|
# "irq": 11,
|
|
|
|
# "slot": 4,
|
|
|
|
# "class_info": {
|
|
|
|
# "class": 1280,
|
|
|
|
# "desc": "RAM controller"
|
|
|
|
# },
|
|
|
|
# "id": {
|
|
|
|
# "device": 6900,
|
|
|
|
# "vendor": 4098
|
|
|
|
# },
|
|
|
|
# "function": 0,
|
|
|
|
# "regions": [
|
|
|
|
# {
|
|
|
|
# "bar": 0,
|
|
|
|
# "size": 32,
|
|
|
|
# "address": 49280,
|
|
|
|
# "type": "io"
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
#
|
|
|
|
# Note: This example has been shortened as the real response is too long.
|
|
|
|
#
|
2011-10-21 20:15:33 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-pci', 'returns': ['PciInfo'] }
|
|
|
|
|
2011-09-15 21:20:28 +04:00
|
|
|
##
|
|
|
|
# @quit:
|
|
|
|
#
|
|
|
|
# This command will cause the QEMU process to exit gracefully. While every
|
|
|
|
# attempt is made to send the QMP response before terminating, this is not
|
|
|
|
# guaranteed. When using this interface, a premature EOF would not be
|
|
|
|
# unexpected.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 14:01:27 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "quit" }
|
|
|
|
# <- { "return": {} }
|
2011-09-15 21:20:28 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'quit' }
|
2011-09-15 21:34:39 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @stop:
|
|
|
|
#
|
|
|
|
# Stop all guest VCPU execution.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Notes: This function will succeed even if the guest is already in the stopped
|
2012-10-23 16:54:21 +04:00
|
|
|
# state. In "inmigrate" state, it will ensure that the guest
|
|
|
|
# remains paused once migration finishes, as if the -S option was
|
|
|
|
# passed on the command line.
|
2016-06-23 14:02:39 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "stop" }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2011-09-15 21:34:39 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'stop' }
|
2011-09-15 21:41:46 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @system_reset:
|
|
|
|
#
|
|
|
|
# Performs a hard reset of a guest.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 14:03:06 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "system_reset" }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2011-09-15 21:41:46 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'system_reset' }
|
2011-09-28 18:06:15 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @system_powerdown:
|
|
|
|
#
|
|
|
|
# Requests that a guest perform a powerdown operation.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Notes: A guest may or may not respond to this command. This command
|
|
|
|
# returning does not indicate that a guest has accepted the request or
|
|
|
|
# that it has shut down. Many guests will respond to this command by
|
|
|
|
# prompting the user in some way.
|
2016-06-23 14:03:30 +03:00
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "system_powerdown" }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2011-09-28 18:06:15 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'system_powerdown' }
|
2011-10-06 21:31:39 +04:00
|
|
|
|
2013-04-30 17:41:25 +04:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @cpu-add:
|
2013-04-30 17:41:25 +04:00
|
|
|
#
|
|
|
|
# Adds CPU with specified ID
|
|
|
|
#
|
|
|
|
# @id: ID of CPU to be created, valid values [0..max_cpus)
|
|
|
|
#
|
|
|
|
# Returns: Nothing on success
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 1.5
|
2016-06-23 14:04:10 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "cpu-add", "arguments": { "id": 2 } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2013-04-30 17:41:25 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'cpu-add', 'data': {'id': 'int'} }
|
|
|
|
|
2011-11-22 22:32:37 +04:00
|
|
|
##
|
|
|
|
# @memsave:
|
|
|
|
#
|
|
|
|
# Save a portion of guest memory to a file.
|
|
|
|
#
|
|
|
|
# @val: the virtual address of the guest to start from
|
|
|
|
#
|
|
|
|
# @size: the size of memory region to save
|
|
|
|
#
|
|
|
|
# @filename: the file to save the memory to as binary data
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @cpu-index: the index of the virtual CPU to use for translating the
|
2011-11-22 22:32:37 +04:00
|
|
|
# virtual address (defaults to CPU 0)
|
|
|
|
#
|
|
|
|
# Returns: Nothing on success
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Notes: Errors were not reliably returned until 1.1
|
2016-06-23 14:05:26 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "memsave",
|
|
|
|
# "arguments": { "val": 10,
|
|
|
|
# "size": 100,
|
|
|
|
# "filename": "/tmp/virtual-mem-dump" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2011-11-22 22:32:37 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'memsave',
|
|
|
|
'data': {'val': 'int', 'size': 'int', 'filename': 'str', '*cpu-index': 'int'} }
|
2011-11-22 23:26:46 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @pmemsave:
|
|
|
|
#
|
|
|
|
# Save a portion of guest physical memory to a file.
|
|
|
|
#
|
|
|
|
# @val: the physical address of the guest to start from
|
|
|
|
#
|
|
|
|
# @size: the size of memory region to save
|
|
|
|
#
|
|
|
|
# @filename: the file to save the memory to as binary data
|
|
|
|
#
|
|
|
|
# Returns: Nothing on success
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Notes: Errors were not reliably returned until 1.1
|
2016-06-23 14:06:17 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "pmemsave",
|
|
|
|
# "arguments": { "val": 10,
|
|
|
|
# "size": 100,
|
|
|
|
# "filename": "/tmp/physical-mem-dump" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2011-11-22 23:26:46 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'pmemsave',
|
|
|
|
'data': {'val': 'int', 'size': 'int', 'filename': 'str'} }
|
2011-11-22 23:58:31 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @cont:
|
|
|
|
#
|
|
|
|
# Resume guest VCPU execution.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Returns: If successful, nothing
|
|
|
|
#
|
2012-10-23 16:54:21 +04:00
|
|
|
# Notes: This command will succeed if the guest is currently running. It
|
|
|
|
# will also succeed if the guest is in the "inmigrate" state; in
|
|
|
|
# this case, the effect of the command is to make sure the guest
|
|
|
|
# starts once migration finishes, removing the effect of the -S
|
|
|
|
# command line option if it was passed.
|
2016-06-23 14:07:08 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "cont" }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2011-11-22 23:58:31 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'cont' }
|
|
|
|
|
2012-02-23 16:45:21 +04:00
|
|
|
##
|
|
|
|
# @system_wakeup:
|
|
|
|
#
|
|
|
|
# Wakeup guest from suspend. Does nothing in case the guest isn't suspended.
|
|
|
|
#
|
|
|
|
# Since: 1.1
|
|
|
|
#
|
|
|
|
# Returns: nothing.
|
2016-06-23 14:07:39 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "system_wakeup" }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2012-02-23 16:45:21 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'system_wakeup' }
|
|
|
|
|
2011-11-23 18:55:53 +04:00
|
|
|
##
|
|
|
|
# @inject-nmi:
|
|
|
|
#
|
2014-08-20 16:16:33 +04:00
|
|
|
# Injects a Non-Maskable Interrupt into the default CPU (x86/s390) or all CPUs (ppc64).
|
2016-06-23 14:08:44 +03:00
|
|
|
# The command fails when the guest doesn't support injecting.
|
2011-11-23 18:55:53 +04:00
|
|
|
#
|
|
|
|
# Returns: If successful, nothing
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
2014-08-20 16:16:33 +04:00
|
|
|
# Note: prior to 2.1, this command was only supported for x86 and s390 VMs
|
2016-06-23 14:08:44 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "inject-nmi" }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2011-11-23 18:55:53 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'inject-nmi' }
|
2011-11-23 19:11:55 +04:00
|
|
|
|
2011-11-25 20:38:09 +04:00
|
|
|
##
|
|
|
|
# @balloon:
|
|
|
|
#
|
|
|
|
# Request the balloon driver to change its balloon size.
|
|
|
|
#
|
|
|
|
# @value: the target size of the balloon in bytes
|
|
|
|
#
|
|
|
|
# Returns: Nothing on success
|
|
|
|
# If the balloon driver is enabled but not functional because the KVM
|
|
|
|
# kernel module cannot support it, KvmMissingCap
|
|
|
|
# If no balloon device is present, DeviceNotActive
|
|
|
|
#
|
|
|
|
# Notes: This command just issues a request to the guest. When it returns,
|
|
|
|
# the balloon size may not have changed. A guest can change the balloon
|
|
|
|
# size independent of this command.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 14:10:30 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "balloon", "arguments": { "value": 536870912 } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2011-11-25 20:38:09 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'balloon', 'data': {'value': 'int'} }
|
2011-11-25 20:57:10 +04:00
|
|
|
|
2011-11-25 23:52:45 +04:00
|
|
|
##
|
|
|
|
# @human-monitor-command:
|
|
|
|
#
|
|
|
|
# Execute a command on the human monitor and return the output.
|
|
|
|
#
|
|
|
|
# @command-line: the command to execute in the human monitor
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @cpu-index: The CPU to use for commands that require an implicit CPU
|
2011-11-25 23:52:45 +04:00
|
|
|
#
|
|
|
|
# Returns: the output of the command as a string
|
|
|
|
#
|
2014-06-05 15:45:31 +04:00
|
|
|
# Since: 0.14.0
|
2013-01-22 12:03:13 +04:00
|
|
|
#
|
2014-06-05 15:45:31 +04:00
|
|
|
# Notes: This command only exists as a stop-gap. Its use is highly
|
2016-06-23 14:15:03 +03:00
|
|
|
# discouraged. The semantics of this command are not
|
|
|
|
# guaranteed: this means that command names, arguments and
|
|
|
|
# responses can change or be removed at ANY time. Applications
|
|
|
|
# that rely on long term stability guarantees should NOT
|
|
|
|
# use this command.
|
2012-10-18 18:49:28 +04:00
|
|
|
#
|
2014-06-05 15:45:31 +04:00
|
|
|
# Known limitations:
|
2012-10-18 18:49:28 +04:00
|
|
|
#
|
2017-01-13 17:41:15 +03:00
|
|
|
# * This command is stateless, this means that commands that depend
|
2014-06-05 15:45:31 +04:00
|
|
|
# on state information (such as getfd) might not work
|
2012-10-18 18:49:24 +04:00
|
|
|
#
|
2017-06-23 19:24:15 +03:00
|
|
|
# * Commands that prompt the user for data don't currently work
|
2016-06-23 14:15:03 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "human-monitor-command",
|
|
|
|
# "arguments": { "command-line": "info kvm" } }
|
|
|
|
# <- { "return": "kvm support: enabled\r\n" }
|
|
|
|
#
|
2012-10-18 18:49:24 +04:00
|
|
|
##
|
2014-06-05 15:45:31 +04:00
|
|
|
{ 'command': 'human-monitor-command',
|
|
|
|
'data': {'command-line': 'str', '*cpu-index': 'int'},
|
|
|
|
'returns': 'str' }
|
2012-10-18 18:49:24 +04:00
|
|
|
|
2011-12-13 00:29:34 +04:00
|
|
|
##
|
2012-03-05 17:13:28 +04:00
|
|
|
# @ObjectPropertyInfo:
|
2011-12-13 00:29:34 +04:00
|
|
|
#
|
|
|
|
# @name: the name of the property
|
|
|
|
#
|
|
|
|
# @type: the type of the property. This will typically come in one of four
|
|
|
|
# forms:
|
|
|
|
#
|
|
|
|
# 1) A primitive type such as 'u8', 'u16', 'bool', 'str', or 'double'.
|
|
|
|
# These types are mapped to the appropriate JSON type.
|
|
|
|
#
|
2015-09-04 22:41:01 +03:00
|
|
|
# 2) A child type in the form 'child<subtype>' where subtype is a qdev
|
2011-12-13 00:29:34 +04:00
|
|
|
# device type name. Child properties create the composition tree.
|
|
|
|
#
|
2015-09-04 22:41:01 +03:00
|
|
|
# 3) A link type in the form 'link<subtype>' where subtype is a qdev
|
2011-12-13 00:29:34 +04:00
|
|
|
# device type name. Link properties form the device model graph.
|
|
|
|
#
|
2012-08-10 20:04:10 +04:00
|
|
|
# Since: 1.2
|
2011-12-13 00:29:34 +04:00
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'ObjectPropertyInfo',
|
2011-12-13 00:29:34 +04:00
|
|
|
'data': { 'name': 'str', 'type': 'str' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @qom-list:
|
|
|
|
#
|
2012-01-30 18:55:55 +04:00
|
|
|
# This command will list any properties of a object given a path in the object
|
2011-12-13 00:29:34 +04:00
|
|
|
# model.
|
|
|
|
#
|
2012-01-30 18:55:55 +04:00
|
|
|
# @path: the path within the object model. See @qom-get for a description of
|
2011-12-13 00:29:34 +04:00
|
|
|
# this parameter.
|
|
|
|
#
|
2012-01-30 18:55:55 +04:00
|
|
|
# Returns: a list of @ObjectPropertyInfo that describe the properties of the
|
|
|
|
# object.
|
2011-12-13 00:29:34 +04:00
|
|
|
#
|
2012-08-10 20:04:10 +04:00
|
|
|
# Since: 1.2
|
2011-12-13 00:29:34 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'qom-list',
|
|
|
|
'data': { 'path': 'str' },
|
2012-01-30 18:55:55 +04:00
|
|
|
'returns': [ 'ObjectPropertyInfo' ] }
|
2011-12-13 00:29:35 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @qom-get:
|
|
|
|
#
|
2012-01-30 18:55:55 +04:00
|
|
|
# This command will get a property from a object model path and return the
|
2011-12-13 00:29:35 +04:00
|
|
|
# value.
|
|
|
|
#
|
2012-01-30 18:55:55 +04:00
|
|
|
# @path: The path within the object model. There are two forms of supported
|
2011-12-13 00:29:35 +04:00
|
|
|
# paths--absolute and partial paths.
|
|
|
|
#
|
2012-01-30 18:55:55 +04:00
|
|
|
# Absolute paths are derived from the root object and can follow child<>
|
2011-12-13 00:29:35 +04:00
|
|
|
# or link<> properties. Since they can follow link<> properties, they
|
|
|
|
# can be arbitrarily long. Absolute paths look like absolute filenames
|
|
|
|
# and are prefixed with a leading slash.
|
|
|
|
#
|
|
|
|
# Partial paths look like relative filenames. They do not begin
|
|
|
|
# with a prefix. The matching rules for partial paths are subtle but
|
2012-01-30 18:55:55 +04:00
|
|
|
# designed to make specifying objects easy. At each level of the
|
2011-12-13 00:29:35 +04:00
|
|
|
# composition tree, the partial path is matched as an absolute path.
|
|
|
|
# The first match is not returned. At least two matches are searched
|
|
|
|
# for. A successful result is only returned if only one match is
|
|
|
|
# found. If more than one match is found, a flag is return to
|
|
|
|
# indicate that the match was ambiguous.
|
|
|
|
#
|
|
|
|
# @property: The property name to read
|
|
|
|
#
|
2015-09-04 22:41:01 +03:00
|
|
|
# Returns: The property value. The type depends on the property
|
|
|
|
# type. child<> and link<> properties are returned as #str
|
|
|
|
# pathnames. All integer property types (u8, u16, etc) are
|
|
|
|
# returned as #int.
|
2011-12-13 00:29:35 +04:00
|
|
|
#
|
2012-08-10 20:04:10 +04:00
|
|
|
# Since: 1.2
|
2011-12-13 00:29:35 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'qom-get',
|
|
|
|
'data': { 'path': 'str', 'property': 'str' },
|
2015-09-16 14:06:25 +03:00
|
|
|
'returns': 'any' }
|
2011-12-13 00:29:35 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @qom-set:
|
|
|
|
#
|
2012-01-30 18:55:55 +04:00
|
|
|
# This command will set a property from a object model path.
|
2011-12-13 00:29:35 +04:00
|
|
|
#
|
|
|
|
# @path: see @qom-get for a description of this parameter
|
|
|
|
#
|
|
|
|
# @property: the property name to set
|
|
|
|
#
|
|
|
|
# @value: a value who's type is appropriate for the property type. See @qom-get
|
|
|
|
# for a description of type mapping.
|
|
|
|
#
|
2012-08-10 20:04:10 +04:00
|
|
|
# Since: 1.2
|
2011-12-13 00:29:35 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'qom-set',
|
2015-09-16 14:06:25 +03:00
|
|
|
'data': { 'path': 'str', 'property': 'str', 'value': 'any' } }
|
2011-12-07 17:17:51 +04:00
|
|
|
|
2011-12-08 17:13:50 +04:00
|
|
|
##
|
|
|
|
# @change:
|
|
|
|
#
|
|
|
|
# This command is multiple commands multiplexed together.
|
|
|
|
#
|
|
|
|
# @device: This is normally the name of a block device but it may also be 'vnc'.
|
|
|
|
# when it's 'vnc', then sub command depends on @target
|
|
|
|
#
|
|
|
|
# @target: If @device is a block device, then this is the new filename.
|
|
|
|
# If @device is 'vnc', then if the value 'password' selects the vnc
|
|
|
|
# change password command. Otherwise, this specifies a new server URI
|
|
|
|
# address to listen to for VNC connections.
|
|
|
|
#
|
|
|
|
# @arg: If @device is a block device, then this is an optional format to open
|
|
|
|
# the device with.
|
|
|
|
# If @device is 'vnc' and @target is 'password', this is the new VNC
|
2017-07-19 10:09:42 +03:00
|
|
|
# password to set. See change-vnc-password for additional notes.
|
2011-12-08 17:13:50 +04:00
|
|
|
#
|
|
|
|
# Returns: Nothing on success.
|
|
|
|
# If @device is not a valid block device, DeviceNotFound
|
|
|
|
#
|
2015-11-06 18:27:06 +03:00
|
|
|
# Notes: This interface is deprecated, and it is strongly recommended that you
|
|
|
|
# avoid using it. For changing block devices, use
|
|
|
|
# blockdev-change-medium; for changing VNC parameters, use
|
|
|
|
# change-vnc-password.
|
2011-12-08 17:13:50 +04:00
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 14:22:37 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# 1. Change a removable medium
|
|
|
|
#
|
|
|
|
# -> { "execute": "change",
|
|
|
|
# "arguments": { "device": "ide1-cd0",
|
|
|
|
# "target": "/srv/images/Fedora-12-x86_64-DVD.iso" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
|
|
|
# 2. Change VNC password
|
|
|
|
#
|
|
|
|
# -> { "execute": "change",
|
|
|
|
# "arguments": { "device": "vnc", "target": "password",
|
|
|
|
# "arg": "foobar1" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2011-12-08 17:13:50 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'change',
|
|
|
|
'data': {'device': 'str', 'target': 'str', '*arg': 'str'} }
|
2011-12-14 22:49:14 +04:00
|
|
|
|
2011-12-23 00:40:54 +04:00
|
|
|
##
|
|
|
|
# @ObjectTypeInfo:
|
|
|
|
#
|
|
|
|
# This structure describes a search result from @qom-list-types
|
|
|
|
#
|
|
|
|
# @name: the type name found in the search
|
|
|
|
#
|
2017-07-07 15:22:14 +03:00
|
|
|
# @abstract: the type is abstract and can't be directly instantiated.
|
|
|
|
# Omitted if false. (since 2.10)
|
|
|
|
#
|
2017-07-07 15:22:15 +03:00
|
|
|
# @parent: Name of parent type, if any (since 2.10)
|
|
|
|
#
|
2011-12-23 00:40:54 +04:00
|
|
|
# Since: 1.1
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'ObjectTypeInfo',
|
2017-07-07 15:22:15 +03:00
|
|
|
'data': { 'name': 'str', '*abstract': 'bool', '*parent': 'str' } }
|
2011-12-23 00:40:54 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @qom-list-types:
|
|
|
|
#
|
|
|
|
# This command will return a list of types given search parameters
|
|
|
|
#
|
|
|
|
# @implements: if specified, only return types that implement this type name
|
|
|
|
#
|
|
|
|
# @abstract: if true, include abstract types in the results
|
|
|
|
#
|
|
|
|
# Returns: a list of @ObjectTypeInfo or an empty list if no results are found
|
|
|
|
#
|
|
|
|
# Since: 1.1
|
|
|
|
##
|
|
|
|
{ 'command': 'qom-list-types',
|
|
|
|
'data': { '*implements': 'str', '*abstract': 'bool' },
|
|
|
|
'returns': [ 'ObjectTypeInfo' ] }
|
2011-12-05 20:48:01 +04:00
|
|
|
|
2012-08-10 20:04:09 +04:00
|
|
|
##
|
|
|
|
# @DevicePropertyInfo:
|
|
|
|
#
|
|
|
|
# Information about device properties.
|
|
|
|
#
|
|
|
|
# @name: the name of the property
|
|
|
|
# @type: the typename of the property
|
2017-03-15 15:57:06 +03:00
|
|
|
# @description: if specified, the description of the property.
|
2014-10-07 10:33:23 +04:00
|
|
|
# (since 2.2)
|
2012-08-10 20:04:09 +04:00
|
|
|
#
|
|
|
|
# Since: 1.2
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'DevicePropertyInfo',
|
2014-10-07 10:33:23 +04:00
|
|
|
'data': { 'name': 'str', 'type': 'str', '*description': 'str' } }
|
2012-08-10 20:04:09 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @device-list-properties:
|
|
|
|
#
|
|
|
|
# List properties associated with a device.
|
|
|
|
#
|
|
|
|
# @typename: the type name of a device
|
|
|
|
#
|
|
|
|
# Returns: a list of DevicePropertyInfo describing a devices properties
|
|
|
|
#
|
|
|
|
# Since: 1.2
|
|
|
|
##
|
|
|
|
{ 'command': 'device-list-properties',
|
|
|
|
'data': { 'typename': 'str'},
|
|
|
|
'returns': [ 'DevicePropertyInfo' ] }
|
|
|
|
|
2012-10-03 17:48:19 +04:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @xen-set-global-dirty-log:
|
2012-10-03 17:48:19 +04:00
|
|
|
#
|
|
|
|
# Enable or disable the global dirty log mode.
|
|
|
|
#
|
|
|
|
# @enable: true to enable, false to disable.
|
|
|
|
#
|
|
|
|
# Returns: nothing
|
|
|
|
#
|
|
|
|
# Since: 1.3
|
2016-06-23 14:26:12 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "xen-set-global-dirty-log",
|
|
|
|
# "arguments": { "enable": true } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2012-10-03 17:48:19 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
|
|
|
|
|
2016-09-12 12:18:58 +03:00
|
|
|
##
|
|
|
|
# @device_add:
|
|
|
|
#
|
|
|
|
# @driver: the name of the new device's driver
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @bus: the device's parent bus (device tree path)
|
2016-09-12 12:18:58 +03:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @id: the device's ID, must be unique
|
2016-09-12 12:18:58 +03:00
|
|
|
#
|
|
|
|
# Additional arguments depend on the type.
|
|
|
|
#
|
|
|
|
# Add a device.
|
|
|
|
#
|
|
|
|
# Notes:
|
|
|
|
# 1. For detailed information about this command, please refer to the
|
|
|
|
# 'docs/qdev-device-use.txt' file.
|
|
|
|
#
|
|
|
|
# 2. It's possible to list device properties by running QEMU with the
|
|
|
|
# "-device DEVICE,help" command-line argument, where DEVICE is the
|
|
|
|
# device's name
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "device_add",
|
|
|
|
# "arguments": { "driver": "e1000", "id": "net1",
|
|
|
|
# "bus": "pci.0",
|
|
|
|
# "mac": "52:54:00:12:34:56" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2017-01-13 17:41:17 +03:00
|
|
|
# TODO: This command effectively bypasses QAPI completely due to its
|
2016-09-12 12:18:58 +03:00
|
|
|
# "additional arguments" business. It shouldn't have been added to
|
|
|
|
# the schema in this form. It should be qapified properly, or
|
|
|
|
# replaced by a properly qapified command.
|
|
|
|
#
|
|
|
|
# Since: 0.13
|
|
|
|
##
|
|
|
|
{ 'command': 'device_add',
|
2017-01-13 17:41:18 +03:00
|
|
|
'data': {'driver': 'str', '*bus': 'str', '*id': 'str'},
|
2016-09-12 12:18:58 +03:00
|
|
|
'gen': false } # so we can get the additional arguments
|
|
|
|
|
2012-03-29 19:38:50 +04:00
|
|
|
##
|
|
|
|
# @device_del:
|
|
|
|
#
|
|
|
|
# Remove a device from a guest
|
|
|
|
#
|
2016-06-23 14:27:06 +03:00
|
|
|
# @id: the device's ID or QOM path
|
2012-03-29 19:38:50 +04:00
|
|
|
#
|
|
|
|
# Returns: Nothing on success
|
|
|
|
# If @id is not a valid device, DeviceNotFound
|
|
|
|
#
|
|
|
|
# Notes: When this command completes, the device may not be removed from the
|
|
|
|
# guest. Hot removal is an operation that requires guest cooperation.
|
|
|
|
# This command merely requests that the guest begin the hot removal
|
2013-03-06 16:58:59 +04:00
|
|
|
# process. Completion of the device removal process is signaled with a
|
|
|
|
# DEVICE_DELETED event. Guest reset will automatically complete removal
|
|
|
|
# for all devices.
|
2012-03-29 19:38:50 +04:00
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 14:27:06 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "device_del",
|
|
|
|
# "arguments": { "id": "net1" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
|
|
|
# -> { "execute": "device_del",
|
|
|
|
# "arguments": { "id": "/machine/peripheral-anon/device[0]" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2012-03-29 19:38:50 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'device_del', 'data': {'id': 'str'} }
|
2012-05-07 08:10:47 +04:00
|
|
|
|
2017-08-24 22:14:05 +03:00
|
|
|
##
|
|
|
|
# @DEVICE_DELETED:
|
|
|
|
#
|
|
|
|
# Emitted whenever the device removal completion is acknowledged by the guest.
|
|
|
|
# At this point, it's safe to reuse the specified device ID. Device removal can
|
|
|
|
# be initiated by the guest or by HMP/QMP commands.
|
|
|
|
#
|
|
|
|
# @device: device name
|
|
|
|
#
|
|
|
|
# @path: device path
|
|
|
|
#
|
|
|
|
# Since: 1.5
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# <- { "event": "DEVICE_DELETED",
|
|
|
|
# "data": { "device": "virtio-net-pci-0",
|
|
|
|
# "path": "/machine/peripheral/virtio-net-pci-0" },
|
|
|
|
# "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'event': 'DEVICE_DELETED',
|
|
|
|
'data': { '*device': 'str', 'path': 'str' } }
|
|
|
|
|
2014-02-18 10:11:36 +04:00
|
|
|
##
|
|
|
|
# @DumpGuestMemoryFormat:
|
|
|
|
#
|
|
|
|
# An enumeration of guest-memory-dump's format.
|
|
|
|
#
|
|
|
|
# @elf: elf format
|
|
|
|
#
|
|
|
|
# @kdump-zlib: kdump-compressed format with zlib-compressed
|
|
|
|
#
|
|
|
|
# @kdump-lzo: kdump-compressed format with lzo-compressed
|
|
|
|
#
|
|
|
|
# @kdump-snappy: kdump-compressed format with snappy-compressed
|
|
|
|
#
|
|
|
|
# Since: 2.0
|
|
|
|
##
|
|
|
|
{ 'enum': 'DumpGuestMemoryFormat',
|
|
|
|
'data': [ 'elf', 'kdump-zlib', 'kdump-lzo', 'kdump-snappy' ] }
|
|
|
|
|
2012-05-07 08:10:47 +04:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @dump-guest-memory:
|
2012-05-07 08:10:47 +04:00
|
|
|
#
|
|
|
|
# Dump guest's memory to vmcore. It is a synchronous operation that can take
|
2016-01-11 22:56:18 +03:00
|
|
|
# very long depending on the amount of guest memory.
|
2012-06-28 18:59:15 +04:00
|
|
|
#
|
|
|
|
# @paging: if true, do paging to get guest's memory mapping. This allows
|
2012-09-21 20:10:58 +04:00
|
|
|
# using gdb to process the core file.
|
2012-06-28 18:59:15 +04:00
|
|
|
#
|
2012-09-21 20:10:58 +04:00
|
|
|
# IMPORTANT: this option can make QEMU allocate several gigabytes
|
|
|
|
# of RAM. This can happen for a large guest, or a
|
|
|
|
# malicious guest pretending to be large.
|
|
|
|
#
|
|
|
|
# Also, paging=true has the following limitations:
|
|
|
|
#
|
|
|
|
# 1. The guest may be in a catastrophic state or can have corrupted
|
|
|
|
# memory, which cannot be trusted
|
|
|
|
# 2. The guest can be in real-mode even if paging is enabled. For
|
|
|
|
# example, the guest uses ACPI to sleep, and ACPI sleep state
|
|
|
|
# goes in real-mode
|
2016-01-11 22:56:18 +03:00
|
|
|
# 3. Currently only supported on i386 and x86_64.
|
2012-06-28 18:59:15 +04:00
|
|
|
#
|
2012-05-07 08:10:47 +04:00
|
|
|
# @protocol: the filename or file descriptor of the vmcore. The supported
|
2012-09-21 20:10:58 +04:00
|
|
|
# protocols are:
|
2012-06-28 18:59:15 +04:00
|
|
|
#
|
2012-09-21 20:10:58 +04:00
|
|
|
# 1. file: the protocol starts with "file:", and the following
|
|
|
|
# string is the file's path.
|
|
|
|
# 2. fd: the protocol starts with "fd:", and the following string
|
|
|
|
# is the fd's name.
|
2012-06-28 18:59:15 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @detach: if true, QMP will return immediately rather than
|
2016-02-18 08:16:54 +03:00
|
|
|
# waiting for the dump to finish. The user can track progress
|
|
|
|
# using "query-dump". (since 2.6).
|
2016-02-18 08:16:47 +03:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @begin: if specified, the starting physical address.
|
2012-06-28 18:59:15 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @length: if specified, the memory size, in bytes. If you don't
|
2012-09-21 20:10:58 +04:00
|
|
|
# want to dump all guest's memory, please specify the start @begin
|
|
|
|
# and @length
|
2012-05-07 08:10:47 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @format: if specified, the format of guest memory dump. But non-elf
|
2014-02-18 10:11:36 +04:00
|
|
|
# format is conflict with paging and filter, ie. @paging, @begin and
|
|
|
|
# @length is not allowed to be specified with non-elf @format at the
|
|
|
|
# same time (since 2.0)
|
|
|
|
#
|
2016-06-23 14:29:50 +03:00
|
|
|
# Note: All boolean arguments default to false
|
|
|
|
#
|
2012-05-07 08:10:47 +04:00
|
|
|
# Returns: nothing on success
|
|
|
|
#
|
|
|
|
# Since: 1.2
|
2016-06-23 14:29:50 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "dump-guest-memory",
|
|
|
|
# "arguments": { "protocol": "fd:dump" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2012-05-07 08:10:47 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'dump-guest-memory',
|
2016-02-18 08:16:47 +03:00
|
|
|
'data': { 'paging': 'bool', 'protocol': 'str', '*detach': 'bool',
|
|
|
|
'*begin': 'int', '*length': 'int',
|
|
|
|
'*format': 'DumpGuestMemoryFormat'} }
|
2012-09-21 20:10:58 +04:00
|
|
|
|
2016-02-18 08:16:48 +03:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @DumpStatus:
|
2016-02-18 08:16:48 +03:00
|
|
|
#
|
|
|
|
# Describe the status of a long-running background guest memory dump.
|
|
|
|
#
|
|
|
|
# @none: no dump-guest-memory has started yet.
|
|
|
|
#
|
|
|
|
# @active: there is one dump running in background.
|
|
|
|
#
|
|
|
|
# @completed: the last dump has finished successfully.
|
|
|
|
#
|
|
|
|
# @failed: the last dump has failed.
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.6
|
2016-02-18 08:16:48 +03:00
|
|
|
##
|
|
|
|
{ 'enum': 'DumpStatus',
|
|
|
|
'data': [ 'none', 'active', 'completed', 'failed' ] }
|
|
|
|
|
2016-02-18 08:16:54 +03:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @DumpQueryResult:
|
2016-02-18 08:16:54 +03:00
|
|
|
#
|
|
|
|
# The result format for 'query-dump'.
|
|
|
|
#
|
|
|
|
# @status: enum of @DumpStatus, which shows current dump status
|
|
|
|
#
|
|
|
|
# @completed: bytes written in latest dump (uncompressed)
|
|
|
|
#
|
|
|
|
# @total: total bytes to be written in latest dump (uncompressed)
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.6
|
2016-02-18 08:16:54 +03:00
|
|
|
##
|
|
|
|
{ 'struct': 'DumpQueryResult',
|
|
|
|
'data': { 'status': 'DumpStatus',
|
|
|
|
'completed': 'int',
|
|
|
|
'total': 'int' } }
|
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @query-dump:
|
2016-02-18 08:16:54 +03:00
|
|
|
#
|
|
|
|
# Query latest dump status.
|
|
|
|
#
|
|
|
|
# Returns: A @DumpStatus object showing the dump status.
|
|
|
|
#
|
|
|
|
# Since: 2.6
|
2016-06-23 16:33:42 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-dump" }
|
|
|
|
# <- { "return": { "status": "active", "completed": 1024000,
|
|
|
|
# "total": 2048000 } }
|
|
|
|
#
|
2016-02-18 08:16:54 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'query-dump', 'returns': 'DumpQueryResult' }
|
|
|
|
|
2017-08-24 22:14:05 +03:00
|
|
|
##
|
|
|
|
# @DUMP_COMPLETED:
|
|
|
|
#
|
|
|
|
# Emitted when background dump has completed
|
|
|
|
#
|
|
|
|
# @result: DumpQueryResult type described in qapi-schema.json.
|
|
|
|
#
|
|
|
|
# @error: human-readable error string that provides
|
|
|
|
# hint on why dump failed. Only presents on failure. The
|
|
|
|
# user should not try to interpret the error string.
|
|
|
|
#
|
|
|
|
# Since: 2.6
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# { "event": "DUMP_COMPLETED",
|
|
|
|
# "data": {"result": {"total": 1090650112, "status": "completed",
|
|
|
|
# "completed": 1090650112} } }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'event': 'DUMP_COMPLETED' ,
|
|
|
|
'data': { 'result': 'DumpQueryResult', '*error': 'str' } }
|
|
|
|
|
2014-02-18 10:11:38 +04:00
|
|
|
##
|
|
|
|
# @DumpGuestMemoryCapability:
|
|
|
|
#
|
|
|
|
# A list of the available formats for dump-guest-memory
|
|
|
|
#
|
|
|
|
# Since: 2.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'DumpGuestMemoryCapability',
|
2014-02-18 10:11:38 +04:00
|
|
|
'data': {
|
|
|
|
'formats': ['DumpGuestMemoryFormat'] } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-dump-guest-memory-capability:
|
|
|
|
#
|
|
|
|
# Returns the available formats for dump-guest-memory
|
|
|
|
#
|
|
|
|
# Returns: A @DumpGuestMemoryCapability object listing available formats for
|
|
|
|
# dump-guest-memory
|
|
|
|
#
|
|
|
|
# Since: 2.0
|
2016-06-23 14:31:04 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-dump-guest-memory-capability" }
|
|
|
|
# <- { "return": { "formats":
|
|
|
|
# ["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] }
|
|
|
|
#
|
2014-02-18 10:11:38 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-dump-guest-memory-capability',
|
|
|
|
'returns': 'DumpGuestMemoryCapability' }
|
2012-09-21 20:10:58 +04:00
|
|
|
|
2015-06-26 21:03:16 +03:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @dump-skeys:
|
2015-06-26 21:03:16 +03:00
|
|
|
#
|
|
|
|
# Dump guest's storage keys
|
|
|
|
#
|
|
|
|
# @filename: the path to the file to dump to
|
|
|
|
#
|
|
|
|
# This command is only supported on s390 architecture.
|
|
|
|
#
|
|
|
|
# Since: 2.5
|
2016-06-23 14:31:48 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "dump-skeys",
|
|
|
|
# "arguments": { "filename": "/tmp/skeys" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2015-06-26 21:03:16 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'dump-skeys',
|
|
|
|
'data': { 'filename': 'str' } }
|
|
|
|
|
2013-12-21 02:21:10 +04:00
|
|
|
##
|
|
|
|
# @object-add:
|
|
|
|
#
|
|
|
|
# Create a QOM object.
|
|
|
|
#
|
|
|
|
# @qom-type: the class name for the object to be created
|
|
|
|
#
|
|
|
|
# @id: the name of the new object
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @props: a dictionary of properties to be passed to the backend
|
2013-12-21 02:21:10 +04:00
|
|
|
#
|
|
|
|
# Returns: Nothing on success
|
|
|
|
# Error if @qom-type is not a valid class name
|
|
|
|
#
|
|
|
|
# Since: 2.0
|
2016-06-23 14:34:37 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "object-add",
|
|
|
|
# "arguments": { "qom-type": "rng-random", "id": "rng1",
|
|
|
|
# "props": { "filename": "/dev/hwrng" } } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2013-12-21 02:21:10 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'object-add',
|
2015-09-16 14:06:25 +03:00
|
|
|
'data': {'qom-type': 'str', 'id': 'str', '*props': 'any'} }
|
2013-12-21 02:21:10 +04:00
|
|
|
|
2013-12-21 02:21:09 +04:00
|
|
|
##
|
|
|
|
# @object-del:
|
|
|
|
#
|
|
|
|
# Remove a QOM object.
|
|
|
|
#
|
|
|
|
# @id: the name of the QOM object to remove
|
|
|
|
#
|
|
|
|
# Returns: Nothing on success
|
|
|
|
# Error if @id is not a valid id for a QOM object
|
|
|
|
#
|
|
|
|
# Since: 2.0
|
2016-06-23 14:35:05 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "object-del", "arguments": { "id": "rng1" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2013-12-21 02:21:09 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'object-del', 'data': {'id': 'str'} }
|
|
|
|
|
2012-06-22 22:36:09 +04:00
|
|
|
##
|
|
|
|
# @getfd:
|
|
|
|
#
|
|
|
|
# Receive a file descriptor via SCM rights and assign it a name
|
|
|
|
#
|
|
|
|
# @fdname: file descriptor name
|
|
|
|
#
|
|
|
|
# Returns: Nothing on success
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Notes: If @fdname already exists, the file descriptor assigned to
|
|
|
|
# it will be closed and replaced by the received file
|
|
|
|
# descriptor.
|
2016-06-23 14:35:51 +03:00
|
|
|
#
|
2012-06-22 22:36:09 +04:00
|
|
|
# The 'closefd' command can be used to explicitly close the
|
|
|
|
# file descriptor when it is no longer needed.
|
2016-06-23 14:35:51 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "getfd", "arguments": { "fdname": "fd1" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2012-06-22 22:36:09 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'getfd', 'data': {'fdname': 'str'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @closefd:
|
|
|
|
#
|
|
|
|
# Close a file descriptor previously passed via SCM rights
|
|
|
|
#
|
|
|
|
# @fdname: file descriptor name
|
|
|
|
#
|
|
|
|
# Returns: Nothing on success
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
2016-06-23 14:37:08 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "closefd", "arguments": { "fdname": "fd1" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2012-06-22 22:36:09 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'closefd', 'data': {'fdname': 'str'} }
|
2012-08-10 20:04:11 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @MachineInfo:
|
|
|
|
#
|
|
|
|
# Information describing a machine.
|
|
|
|
#
|
|
|
|
# @name: the name of the machine
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @alias: an alias for the machine name
|
2012-08-10 20:04:11 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @is-default: whether the machine is default
|
2012-08-10 20:04:11 +04:00
|
|
|
#
|
2013-04-08 20:21:02 +04:00
|
|
|
# @cpu-max: maximum number of CPUs supported by the machine type
|
|
|
|
# (since 1.5.0)
|
|
|
|
#
|
2016-06-24 00:23:33 +03:00
|
|
|
# @hotpluggable-cpus: cpu hotplug via -device is supported (since 2.7.0)
|
|
|
|
#
|
2012-08-10 20:04:11 +04:00
|
|
|
# Since: 1.2.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'MachineInfo',
|
2012-08-10 20:04:11 +04:00
|
|
|
'data': { 'name': 'str', '*alias': 'str',
|
2016-06-24 00:23:33 +03:00
|
|
|
'*is-default': 'bool', 'cpu-max': 'int',
|
|
|
|
'hotpluggable-cpus': 'bool'} }
|
2012-08-10 20:04:11 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-machines:
|
|
|
|
#
|
|
|
|
# Return a list of supported machines
|
|
|
|
#
|
|
|
|
# Returns: a list of MachineInfo
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
|
|
|
##
|
|
|
|
{ 'command': 'query-machines', 'returns': ['MachineInfo'] }
|
2012-08-10 20:04:13 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @CpuDefinitionInfo:
|
|
|
|
#
|
|
|
|
# Virtual CPU definition.
|
|
|
|
#
|
|
|
|
# @name: the name of the CPU definition
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @migration-safe: whether a CPU definition can be safely used for
|
2016-09-05 11:52:15 +03:00
|
|
|
# migration in combination with a QEMU compatibility machine
|
|
|
|
# when migrating between different QMU versions and between
|
|
|
|
# hosts with different sets of (hardware or software)
|
|
|
|
# capabilities. If not provided, information is not available
|
|
|
|
# and callers should not assume the CPU definition to be
|
|
|
|
# migration-safe. (since 2.8)
|
|
|
|
#
|
|
|
|
# @static: whether a CPU definition is static and will not change depending on
|
|
|
|
# QEMU version, machine type, machine options and accelerator options.
|
|
|
|
# A static model is always migration-safe. (since 2.8)
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @unavailable-features: List of properties that prevent
|
2016-09-30 21:49:45 +03:00
|
|
|
# the CPU model from running in the current
|
|
|
|
# host. (since 2.8)
|
2016-11-16 21:21:39 +03:00
|
|
|
# @typename: Type name that can be used as argument to @device-list-properties,
|
|
|
|
# to introspect properties configurable using -cpu or -global.
|
|
|
|
# (since 2.9)
|
2016-09-30 21:49:45 +03:00
|
|
|
#
|
|
|
|
# @unavailable-features is a list of QOM property names that
|
|
|
|
# represent CPU model attributes that prevent the CPU from running.
|
|
|
|
# If the QOM property is read-only, that means there's no known
|
|
|
|
# way to make the CPU model run in the current host. Implementations
|
|
|
|
# that choose not to provide specific information return the
|
|
|
|
# property name "type".
|
|
|
|
# If the property is read-write, it means that it MAY be possible
|
|
|
|
# to run the CPU model in the current host if that property is
|
|
|
|
# changed. Management software can use it as hints to suggest or
|
|
|
|
# choose an alternative for the user, or just to generate meaningful
|
|
|
|
# error messages explaining why the CPU model can't be used.
|
|
|
|
# If @unavailable-features is an empty list, the CPU model is
|
|
|
|
# runnable using the current host and machine-type.
|
|
|
|
# If @unavailable-features is not present, runnability
|
|
|
|
# information for the CPU is not available.
|
|
|
|
#
|
2012-08-10 20:04:13 +04:00
|
|
|
# Since: 1.2.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'CpuDefinitionInfo',
|
2016-09-30 21:49:45 +03:00
|
|
|
'data': { 'name': 'str', '*migration-safe': 'bool', 'static': 'bool',
|
2016-11-16 21:21:39 +03:00
|
|
|
'*unavailable-features': [ 'str' ], 'typename': 'str' } }
|
2012-08-10 20:04:13 +04:00
|
|
|
|
2017-08-29 18:30:21 +03:00
|
|
|
##
|
|
|
|
# @MemoryInfo:
|
|
|
|
#
|
|
|
|
# Actual memory information in bytes.
|
|
|
|
#
|
|
|
|
# @base-memory: size of "base" memory specified with command line
|
|
|
|
# option -m.
|
|
|
|
#
|
|
|
|
# @plugged-memory: size of memory that can be hot-unplugged. This field
|
|
|
|
# is omitted if target doesn't support memory hotplug
|
|
|
|
# (i.e. CONFIG_MEM_HOTPLUG not defined on build time).
|
|
|
|
#
|
|
|
|
# Since: 2.11.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'MemoryInfo',
|
|
|
|
'data' : { 'base-memory': 'size', '*plugged-memory': 'size' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-memory-size-summary:
|
|
|
|
#
|
|
|
|
# Return the amount of initially allocated and present hotpluggable (if
|
|
|
|
# enabled) memory in bytes.
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-memory-size-summary" }
|
|
|
|
# <- { "return": { "base-memory": 4294967296, "plugged-memory": 0 } }
|
|
|
|
#
|
|
|
|
# Since: 2.11.0
|
|
|
|
##
|
|
|
|
{ 'command': 'query-memory-size-summary', 'returns': 'MemoryInfo' }
|
|
|
|
|
2012-08-10 20:04:13 +04:00
|
|
|
##
|
|
|
|
# @query-cpu-definitions:
|
|
|
|
#
|
|
|
|
# Return a list of supported virtual CPU definitions
|
|
|
|
#
|
|
|
|
# Returns: a list of CpuDefInfo
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
|
|
|
##
|
|
|
|
{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
|
2012-08-15 00:43:43 +04:00
|
|
|
|
2016-09-05 11:52:39 +03:00
|
|
|
##
|
|
|
|
# @CpuModelInfo:
|
|
|
|
#
|
|
|
|
# Virtual CPU model.
|
|
|
|
#
|
|
|
|
# A CPU model consists of the name of a CPU definition, to which
|
|
|
|
# delta changes are applied (e.g. features added/removed). Most magic values
|
|
|
|
# that an architecture might require should be hidden behind the name.
|
|
|
|
# However, if required, architectures can expose relevant properties.
|
|
|
|
#
|
|
|
|
# @name: the name of the CPU definition the model is based on
|
2017-03-15 15:57:06 +03:00
|
|
|
# @props: a dictionary of QOM properties to be applied
|
2016-09-05 11:52:39 +03:00
|
|
|
#
|
|
|
|
# Since: 2.8.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'CpuModelInfo',
|
|
|
|
'data': { 'name': 'str',
|
|
|
|
'*props': 'any' } }
|
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @CpuModelExpansionType:
|
2016-09-05 11:52:39 +03:00
|
|
|
#
|
|
|
|
# An enumeration of CPU model expansion types.
|
|
|
|
#
|
|
|
|
# @static: Expand to a static CPU model, a combination of a static base
|
|
|
|
# model name and property delta changes. As the static base model will
|
|
|
|
# never change, the expanded CPU model will be the same, independant of
|
|
|
|
# independent of QEMU version, machine type, machine options, and
|
|
|
|
# accelerator options. Therefore, the resulting model can be used by
|
|
|
|
# tooling without having to specify a compatibility machine - e.g. when
|
|
|
|
# displaying the "host" model. static CPU models are migration-safe.
|
|
|
|
#
|
|
|
|
# @full: Expand all properties. The produced model is not guaranteed to be
|
|
|
|
# migration-safe, but allows tooling to get an insight and work with
|
|
|
|
# model details.
|
|
|
|
#
|
2017-01-17 00:11:22 +03:00
|
|
|
# Note: When a non-migration-safe CPU model is expanded in static mode, some
|
|
|
|
# features enabled by the CPU model may be omitted, because they can't be
|
|
|
|
# implemented by a static CPU model definition (e.g. cache info passthrough and
|
|
|
|
# PMU passthrough in x86). If you need an accurate representation of the
|
|
|
|
# features enabled by a non-migration-safe CPU model, use @full. If you need a
|
|
|
|
# static representation that will keep ABI compatibility even when changing QEMU
|
|
|
|
# version or machine-type, use @static (but keep in mind that some features may
|
|
|
|
# be omitted).
|
|
|
|
#
|
2016-09-05 11:52:39 +03:00
|
|
|
# Since: 2.8.0
|
|
|
|
##
|
|
|
|
{ 'enum': 'CpuModelExpansionType',
|
|
|
|
'data': [ 'static', 'full' ] }
|
|
|
|
|
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @CpuModelExpansionInfo:
|
2016-09-05 11:52:39 +03:00
|
|
|
#
|
|
|
|
# The result of a cpu model expansion.
|
|
|
|
#
|
|
|
|
# @model: the expanded CpuModelInfo.
|
|
|
|
#
|
|
|
|
# Since: 2.8.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'CpuModelExpansionInfo',
|
|
|
|
'data': { 'model': 'CpuModelInfo' } }
|
|
|
|
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-cpu-model-expansion:
|
|
|
|
#
|
|
|
|
# Expands a given CPU model (or a combination of CPU model + additional options)
|
|
|
|
# to different granularities, allowing tooling to get an understanding what a
|
|
|
|
# specific CPU model looks like in QEMU under a certain configuration.
|
|
|
|
#
|
|
|
|
# This interface can be used to query the "host" CPU model.
|
|
|
|
#
|
|
|
|
# The data returned by this command may be affected by:
|
|
|
|
#
|
|
|
|
# * QEMU version: CPU models may look different depending on the QEMU version.
|
|
|
|
# (Except for CPU models reported as "static" in query-cpu-definitions.)
|
|
|
|
# * machine-type: CPU model may look different depending on the machine-type.
|
|
|
|
# (Except for CPU models reported as "static" in query-cpu-definitions.)
|
|
|
|
# * machine options (including accelerator): in some architectures, CPU models
|
|
|
|
# may look different depending on machine and accelerator options. (Except for
|
|
|
|
# CPU models reported as "static" in query-cpu-definitions.)
|
|
|
|
# * "-cpu" arguments and global properties: arguments to the -cpu option and
|
|
|
|
# global properties may affect expansion of CPU models. Using
|
|
|
|
# query-cpu-model-expansion while using these is not advised.
|
|
|
|
#
|
2016-09-05 11:52:42 +03:00
|
|
|
# Some architectures may not support all expansion types. s390x supports
|
|
|
|
# "full" and "static".
|
2016-09-05 11:52:39 +03:00
|
|
|
#
|
|
|
|
# Returns: a CpuModelExpansionInfo. Returns an error if expanding CPU models is
|
|
|
|
# not supported, if the model cannot be expanded, if the model contains
|
|
|
|
# an unknown CPU definition name, unknown properties or properties
|
|
|
|
# with a wrong type. Also returns an error if an expansion type is
|
|
|
|
# not supported.
|
|
|
|
#
|
|
|
|
# Since: 2.8.0
|
|
|
|
##
|
|
|
|
{ 'command': 'query-cpu-model-expansion',
|
|
|
|
'data': { 'type': 'CpuModelExpansionType',
|
|
|
|
'model': 'CpuModelInfo' },
|
|
|
|
'returns': 'CpuModelExpansionInfo' }
|
|
|
|
|
2016-09-05 11:52:40 +03:00
|
|
|
##
|
|
|
|
# @CpuModelCompareResult:
|
|
|
|
#
|
|
|
|
# An enumeration of CPU model comparation results. The result is usually
|
2016-09-09 15:35:27 +03:00
|
|
|
# calculated using e.g. CPU features or CPU generations.
|
2016-09-05 11:52:40 +03:00
|
|
|
#
|
|
|
|
# @incompatible: If model A is incompatible to model B, model A is not
|
|
|
|
# guaranteed to run where model B runs and the other way around.
|
|
|
|
#
|
|
|
|
# @identical: If model A is identical to model B, model A is guaranteed to run
|
|
|
|
# where model B runs and the other way around.
|
|
|
|
#
|
|
|
|
# @superset: If model A is a superset of model B, model B is guaranteed to run
|
|
|
|
# where model A runs. There are no guarantees about the other way.
|
|
|
|
#
|
|
|
|
# @subset: If model A is a subset of model B, model A is guaranteed to run
|
|
|
|
# where model B runs. There are no guarantees about the other way.
|
|
|
|
#
|
|
|
|
# Since: 2.8.0
|
|
|
|
##
|
|
|
|
{ 'enum': 'CpuModelCompareResult',
|
|
|
|
'data': [ 'incompatible', 'identical', 'superset', 'subset' ] }
|
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @CpuModelCompareInfo:
|
2016-09-05 11:52:40 +03:00
|
|
|
#
|
|
|
|
# The result of a CPU model comparison.
|
|
|
|
#
|
|
|
|
# @result: The result of the compare operation.
|
|
|
|
# @responsible-properties: List of properties that led to the comparison result
|
|
|
|
# not being identical.
|
|
|
|
#
|
|
|
|
# @responsible-properties is a list of QOM property names that led to
|
|
|
|
# both CPUs not being detected as identical. For identical models, this
|
|
|
|
# list is empty.
|
|
|
|
# If a QOM property is read-only, that means there's no known way to make the
|
|
|
|
# CPU models identical. If the special property name "type" is included, the
|
|
|
|
# models are by definition not identical and cannot be made identical.
|
|
|
|
#
|
|
|
|
# Since: 2.8.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'CpuModelCompareInfo',
|
|
|
|
'data': {'result': 'CpuModelCompareResult',
|
|
|
|
'responsible-properties': ['str']
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-cpu-model-comparison:
|
|
|
|
#
|
|
|
|
# Compares two CPU models, returning how they compare in a specific
|
|
|
|
# configuration. The results indicates how both models compare regarding
|
|
|
|
# runnability. This result can be used by tooling to make decisions if a
|
|
|
|
# certain CPU model will run in a certain configuration or if a compatible
|
|
|
|
# CPU model has to be created by baselining.
|
|
|
|
#
|
|
|
|
# Usually, a CPU model is compared against the maximum possible CPU model
|
2016-09-09 15:35:27 +03:00
|
|
|
# of a certain configuration (e.g. the "host" model for KVM). If that CPU
|
2016-09-05 11:52:40 +03:00
|
|
|
# model is identical or a subset, it will run in that configuration.
|
|
|
|
#
|
|
|
|
# The result returned by this command may be affected by:
|
|
|
|
#
|
|
|
|
# * QEMU version: CPU models may look different depending on the QEMU version.
|
|
|
|
# (Except for CPU models reported as "static" in query-cpu-definitions.)
|
2016-09-09 15:35:27 +03:00
|
|
|
# * machine-type: CPU model may look different depending on the machine-type.
|
2016-09-05 11:52:40 +03:00
|
|
|
# (Except for CPU models reported as "static" in query-cpu-definitions.)
|
|
|
|
# * machine options (including accelerator): in some architectures, CPU models
|
|
|
|
# may look different depending on machine and accelerator options. (Except for
|
|
|
|
# CPU models reported as "static" in query-cpu-definitions.)
|
|
|
|
# * "-cpu" arguments and global properties: arguments to the -cpu option and
|
|
|
|
# global properties may affect expansion of CPU models. Using
|
|
|
|
# query-cpu-model-expansion while using these is not advised.
|
|
|
|
#
|
2016-09-05 11:52:43 +03:00
|
|
|
# Some architectures may not support comparing CPU models. s390x supports
|
|
|
|
# comparing CPU models.
|
2016-09-05 11:52:40 +03:00
|
|
|
#
|
|
|
|
# Returns: a CpuModelBaselineInfo. Returns an error if comparing CPU models is
|
|
|
|
# not supported, if a model cannot be used, if a model contains
|
|
|
|
# an unknown cpu definition name, unknown properties or properties
|
|
|
|
# with wrong types.
|
|
|
|
#
|
|
|
|
# Since: 2.8.0
|
|
|
|
##
|
|
|
|
{ 'command': 'query-cpu-model-comparison',
|
|
|
|
'data': { 'modela': 'CpuModelInfo', 'modelb': 'CpuModelInfo' },
|
|
|
|
'returns': 'CpuModelCompareInfo' }
|
|
|
|
|
2016-09-05 11:52:41 +03:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @CpuModelBaselineInfo:
|
2016-09-05 11:52:41 +03:00
|
|
|
#
|
|
|
|
# The result of a CPU model baseline.
|
|
|
|
#
|
|
|
|
# @model: the baselined CpuModelInfo.
|
|
|
|
#
|
|
|
|
# Since: 2.8.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'CpuModelBaselineInfo',
|
|
|
|
'data': { 'model': 'CpuModelInfo' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-cpu-model-baseline:
|
|
|
|
#
|
|
|
|
# Baseline two CPU models, creating a compatible third model. The created
|
|
|
|
# model will always be a static, migration-safe CPU model (see "static"
|
|
|
|
# CPU model expansion for details).
|
|
|
|
#
|
|
|
|
# This interface can be used by tooling to create a compatible CPU model out
|
|
|
|
# two CPU models. The created CPU model will be identical to or a subset of
|
|
|
|
# both CPU models when comparing them. Therefore, the created CPU model is
|
|
|
|
# guaranteed to run where the given CPU models run.
|
|
|
|
#
|
|
|
|
# The result returned by this command may be affected by:
|
|
|
|
#
|
|
|
|
# * QEMU version: CPU models may look different depending on the QEMU version.
|
|
|
|
# (Except for CPU models reported as "static" in query-cpu-definitions.)
|
2016-09-09 15:35:27 +03:00
|
|
|
# * machine-type: CPU model may look different depending on the machine-type.
|
2016-09-05 11:52:41 +03:00
|
|
|
# (Except for CPU models reported as "static" in query-cpu-definitions.)
|
|
|
|
# * machine options (including accelerator): in some architectures, CPU models
|
|
|
|
# may look different depending on machine and accelerator options. (Except for
|
|
|
|
# CPU models reported as "static" in query-cpu-definitions.)
|
|
|
|
# * "-cpu" arguments and global properties: arguments to the -cpu option and
|
|
|
|
# global properties may affect expansion of CPU models. Using
|
|
|
|
# query-cpu-model-expansion while using these is not advised.
|
|
|
|
#
|
2016-09-05 11:52:44 +03:00
|
|
|
# Some architectures may not support baselining CPU models. s390x supports
|
|
|
|
# baselining CPU models.
|
2016-09-05 11:52:41 +03:00
|
|
|
#
|
|
|
|
# Returns: a CpuModelBaselineInfo. Returns an error if baselining CPU models is
|
|
|
|
# not supported, if a model cannot be used, if a model contains
|
|
|
|
# an unknown cpu definition name, unknown properties or properties
|
|
|
|
# with wrong types.
|
|
|
|
#
|
|
|
|
# Since: 2.8.0
|
|
|
|
##
|
|
|
|
{ 'command': 'query-cpu-model-baseline',
|
|
|
|
'data': { 'modela': 'CpuModelInfo',
|
|
|
|
'modelb': 'CpuModelInfo' },
|
|
|
|
'returns': 'CpuModelBaselineInfo' }
|
|
|
|
|
2016-11-17 18:54:51 +03:00
|
|
|
##
|
2012-08-15 00:43:43 +04:00
|
|
|
# @AddfdInfo:
|
|
|
|
#
|
|
|
|
# Information about a file descriptor that was added to an fd set.
|
|
|
|
#
|
|
|
|
# @fdset-id: The ID of the fd set that @fd was added to.
|
|
|
|
#
|
|
|
|
# @fd: The file descriptor that was received via SCM rights and
|
|
|
|
# added to the fd set.
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'AddfdInfo', 'data': {'fdset-id': 'int', 'fd': 'int'} }
|
2012-08-15 00:43:43 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @add-fd:
|
|
|
|
#
|
|
|
|
# Add a file descriptor, that was passed via SCM rights, to an fd set.
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @fdset-id: The ID of the fd set to add the file descriptor to.
|
2012-08-15 00:43:43 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @opaque: A free-form string that can be used to describe the fd.
|
2012-08-15 00:43:43 +04:00
|
|
|
#
|
|
|
|
# Returns: @AddfdInfo on success
|
2016-06-23 14:39:05 +03:00
|
|
|
#
|
2012-08-15 00:43:43 +04:00
|
|
|
# If file descriptor was not received, FdNotSupplied
|
2016-06-23 14:39:05 +03:00
|
|
|
#
|
2012-10-18 23:19:31 +04:00
|
|
|
# If @fdset-id is a negative value, InvalidParameterValue
|
2012-08-15 00:43:43 +04:00
|
|
|
#
|
|
|
|
# Notes: The list of fd sets is shared by all monitor connections.
|
|
|
|
#
|
|
|
|
# If @fdset-id is not specified, a new fd set will be created.
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
2016-06-23 14:39:05 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "add-fd", "arguments": { "fdset-id": 1 } }
|
|
|
|
# <- { "return": { "fdset-id": 1, "fd": 3 } }
|
|
|
|
#
|
2012-08-15 00:43:43 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'add-fd', 'data': {'*fdset-id': 'int', '*opaque': 'str'},
|
|
|
|
'returns': 'AddfdInfo' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @remove-fd:
|
|
|
|
#
|
|
|
|
# Remove a file descriptor from an fd set.
|
|
|
|
#
|
|
|
|
# @fdset-id: The ID of the fd set that the file descriptor belongs to.
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @fd: The file descriptor that is to be removed.
|
2012-08-15 00:43:43 +04:00
|
|
|
#
|
|
|
|
# Returns: Nothing on success
|
|
|
|
# If @fdset-id or @fd is not found, FdNotFound
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
|
|
|
#
|
|
|
|
# Notes: The list of fd sets is shared by all monitor connections.
|
|
|
|
#
|
|
|
|
# If @fd is not specified, all file descriptors in @fdset-id
|
|
|
|
# will be removed.
|
2016-06-23 14:39:42 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "remove-fd", "arguments": { "fdset-id": 1, "fd": 3 } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2012-08-15 00:43:43 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'remove-fd', 'data': {'fdset-id': 'int', '*fd': 'int'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @FdsetFdInfo:
|
|
|
|
#
|
|
|
|
# Information about a file descriptor that belongs to an fd set.
|
|
|
|
#
|
|
|
|
# @fd: The file descriptor value.
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @opaque: A free-form string that can be used to describe the fd.
|
2012-08-15 00:43:43 +04:00
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'FdsetFdInfo',
|
2012-08-15 00:43:43 +04:00
|
|
|
'data': {'fd': 'int', '*opaque': 'str'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @FdsetInfo:
|
|
|
|
#
|
|
|
|
# Information about an fd set.
|
|
|
|
#
|
|
|
|
# @fdset-id: The ID of the fd set.
|
|
|
|
#
|
|
|
|
# @fds: A list of file descriptors that belong to this fd set.
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'FdsetInfo',
|
2012-08-15 00:43:43 +04:00
|
|
|
'data': {'fdset-id': 'int', 'fds': ['FdsetFdInfo']} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-fdsets:
|
|
|
|
#
|
|
|
|
# Return information describing all fd sets.
|
|
|
|
#
|
|
|
|
# Returns: A list of @FdsetInfo
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
|
|
|
#
|
|
|
|
# Note: The list of fd sets is shared by all monitor connections.
|
|
|
|
#
|
2016-06-23 14:40:29 +03:00
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-fdsets" }
|
|
|
|
# <- { "return": [
|
|
|
|
# {
|
|
|
|
# "fds": [
|
|
|
|
# {
|
|
|
|
# "fd": 30,
|
|
|
|
# "opaque": "rdonly:/path/to/file"
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "fd": 24,
|
|
|
|
# "opaque": "rdwr:/path/to/file"
|
|
|
|
# }
|
|
|
|
# ],
|
|
|
|
# "fdset-id": 1
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "fds": [
|
|
|
|
# {
|
|
|
|
# "fd": 28
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "fd": 29
|
|
|
|
# }
|
|
|
|
# ],
|
|
|
|
# "fdset-id": 0
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
#
|
2012-08-15 00:43:43 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
|
2012-08-20 18:31:38 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @TargetInfo:
|
|
|
|
#
|
|
|
|
# Information describing the QEMU target.
|
|
|
|
#
|
|
|
|
# @arch: the target architecture (eg "x86_64", "i386", etc)
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'TargetInfo',
|
2013-06-04 16:45:28 +04:00
|
|
|
'data': { 'arch': 'str' } }
|
2012-08-20 18:31:38 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @query-target:
|
|
|
|
#
|
|
|
|
# Return information about the target for this QEMU
|
|
|
|
#
|
|
|
|
# Returns: TargetInfo
|
|
|
|
#
|
|
|
|
# Since: 1.2.0
|
|
|
|
##
|
|
|
|
{ 'command': 'query-target', 'returns': 'TargetInfo' }
|
2012-08-31 06:56:24 +04:00
|
|
|
|
2013-03-21 03:23:16 +04:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @AcpiTableOptions:
|
2013-03-21 03:23:16 +04:00
|
|
|
#
|
|
|
|
# Specify an ACPI table on the command line to load.
|
|
|
|
#
|
|
|
|
# At most one of @file and @data can be specified. The list of files specified
|
|
|
|
# by any one of them is loaded and concatenated in order. If both are omitted,
|
|
|
|
# @data is implied.
|
|
|
|
#
|
|
|
|
# Other fields / optargs can be used to override fields of the generic ACPI
|
|
|
|
# table header; refer to the ACPI specification 5.0, section 5.2.6 System
|
|
|
|
# Description Table Header. If a header field is not overridden, then the
|
|
|
|
# corresponding value from the concatenated blob is used (in case of @file), or
|
|
|
|
# it is filled in with a hard-coded value (in case of @data).
|
|
|
|
#
|
|
|
|
# String fields are copied into the matching ACPI member from lowest address
|
|
|
|
# upwards, and silently truncated / NUL-padded to length.
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @sig: table signature / identifier (4 bytes)
|
2013-03-21 03:23:16 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @rev: table revision number (dependent on signature, 1 byte)
|
2013-03-21 03:23:16 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @oem_id: OEM identifier (6 bytes)
|
2013-03-21 03:23:16 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @oem_table_id: OEM table identifier (8 bytes)
|
2013-03-21 03:23:16 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @oem_rev: OEM-supplied revision number (4 bytes)
|
2013-03-21 03:23:16 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @asl_compiler_id: identifier of the utility that created the table
|
2013-03-21 03:23:16 +04:00
|
|
|
# (4 bytes)
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @asl_compiler_rev: revision number of the utility that created the
|
2013-03-21 03:23:16 +04:00
|
|
|
# table (4 bytes)
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @file: colon (:) separated list of pathnames to load and
|
2013-03-21 03:23:16 +04:00
|
|
|
# concatenate as table data. The resultant binary blob is expected to
|
|
|
|
# have an ACPI table header. At least one file is required. This field
|
|
|
|
# excludes @data.
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @data: colon (:) separated list of pathnames to load and
|
2013-03-21 03:23:16 +04:00
|
|
|
# concatenate as table data. The resultant binary blob must not have an
|
|
|
|
# ACPI table header. At least one file is required. This field excludes
|
|
|
|
# @file.
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 1.5
|
2013-03-21 03:23:16 +04:00
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'AcpiTableOptions',
|
2013-03-21 03:23:16 +04:00
|
|
|
'data': {
|
|
|
|
'*sig': 'str',
|
|
|
|
'*rev': 'uint8',
|
|
|
|
'*oem_id': 'str',
|
|
|
|
'*oem_table_id': 'str',
|
|
|
|
'*oem_rev': 'uint32',
|
|
|
|
'*asl_compiler_id': 'str',
|
|
|
|
'*asl_compiler_rev': 'uint32',
|
|
|
|
'*file': 'str',
|
|
|
|
'*data': 'str' }}
|
2013-04-25 13:50:35 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @CommandLineParameterType:
|
|
|
|
#
|
|
|
|
# Possible types for an option parameter.
|
|
|
|
#
|
|
|
|
# @string: accepts a character string
|
|
|
|
#
|
|
|
|
# @boolean: accepts "on" or "off"
|
|
|
|
#
|
|
|
|
# @number: accepts a number
|
|
|
|
#
|
|
|
|
# @size: accepts a number followed by an optional suffix (K)ilo,
|
|
|
|
# (M)ega, (G)iga, (T)era
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 1.5
|
2013-04-25 13:50:35 +04:00
|
|
|
##
|
|
|
|
{ 'enum': 'CommandLineParameterType',
|
|
|
|
'data': ['string', 'boolean', 'number', 'size'] }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @CommandLineParameterInfo:
|
|
|
|
#
|
|
|
|
# Details about a single parameter of a command line option.
|
|
|
|
#
|
|
|
|
# @name: parameter name
|
|
|
|
#
|
|
|
|
# @type: parameter @CommandLineParameterType
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @help: human readable text string, not suitable for parsing.
|
2013-04-25 13:50:35 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @default: default value string (since 2.1)
|
2014-06-05 13:20:43 +04:00
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 1.5
|
2013-04-25 13:50:35 +04:00
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'CommandLineParameterInfo',
|
2013-04-25 13:50:35 +04:00
|
|
|
'data': { 'name': 'str',
|
|
|
|
'type': 'CommandLineParameterType',
|
2014-06-05 13:20:43 +04:00
|
|
|
'*help': 'str',
|
|
|
|
'*default': 'str' } }
|
2013-04-25 13:50:35 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @CommandLineOptionInfo:
|
|
|
|
#
|
|
|
|
# Details about a command line option, including its list of parameter details
|
|
|
|
#
|
|
|
|
# @option: option name
|
|
|
|
#
|
|
|
|
# @parameters: an array of @CommandLineParameterInfo
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 1.5
|
2013-04-25 13:50:35 +04:00
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'CommandLineOptionInfo',
|
2013-04-25 13:50:35 +04:00
|
|
|
'data': { 'option': 'str', 'parameters': ['CommandLineParameterInfo'] } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-command-line-options:
|
|
|
|
#
|
|
|
|
# Query command line option schema.
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @option: option name
|
2013-04-25 13:50:35 +04:00
|
|
|
#
|
|
|
|
# Returns: list of @CommandLineOptionInfo for all options (or for the given
|
|
|
|
# @option). Returns an error if the given @option doesn't exist.
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 1.5
|
2016-06-23 14:46:31 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-command-line-options",
|
|
|
|
# "arguments": { "option": "option-rom" } }
|
|
|
|
# <- { "return": [
|
|
|
|
# {
|
|
|
|
# "parameters": [
|
|
|
|
# {
|
|
|
|
# "name": "romfile",
|
|
|
|
# "type": "string"
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "name": "bootindex",
|
|
|
|
# "type": "number"
|
|
|
|
# }
|
|
|
|
# ],
|
|
|
|
# "option": "option-rom"
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
#
|
2013-04-25 13:50:35 +04:00
|
|
|
##
|
|
|
|
{'command': 'query-command-line-options', 'data': { '*option': 'str' },
|
|
|
|
'returns': ['CommandLineOptionInfo'] }
|
2013-05-06 20:20:07 +04:00
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @X86CPURegister32:
|
2013-05-06 20:20:07 +04:00
|
|
|
#
|
|
|
|
# A X86 32-bit register
|
|
|
|
#
|
|
|
|
# Since: 1.5
|
|
|
|
##
|
|
|
|
{ 'enum': 'X86CPURegister32',
|
|
|
|
'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] }
|
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @X86CPUFeatureWordInfo:
|
2013-05-06 20:20:07 +04:00
|
|
|
#
|
|
|
|
# Information about a X86 CPU feature word
|
|
|
|
#
|
|
|
|
# @cpuid-input-eax: Input EAX value for CPUID instruction for that feature word
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @cpuid-input-ecx: Input ECX value for CPUID instruction for that
|
2013-05-06 20:20:07 +04:00
|
|
|
# feature word
|
|
|
|
#
|
|
|
|
# @cpuid-register: Output register containing the feature bits
|
|
|
|
#
|
|
|
|
# @features: value of output register, containing the feature bits
|
|
|
|
#
|
|
|
|
# Since: 1.5
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'X86CPUFeatureWordInfo',
|
2013-05-06 20:20:07 +04:00
|
|
|
'data': { 'cpuid-input-eax': 'int',
|
|
|
|
'*cpuid-input-ecx': 'int',
|
|
|
|
'cpuid-register': 'X86CPURegister32',
|
|
|
|
'features': 'int' } }
|
net: add support of mac-programming over macvtap in QEMU side
Currently macvtap based macvlan device is working in promiscuous
mode, we want to implement mac-programming over macvtap through
Libvirt for better performance.
Design:
QEMU notifies Libvirt when rx-filter config is changed in guest,
then Libvirt query the rx-filter information by a monitor command,
and sync the change to macvtap device. Related rx-filter config
of the nic contains main mac, rx-mode items and vlan table.
This patch adds a QMP event to notify management of rx-filter change,
and adds a monitor command for management to query rx-filter
information.
Test:
If we repeatedly add/remove vlan, and change macaddr of vlan
interfaces in guest by a loop script.
Result:
The events will flood the QMP client(management), management takes
too much resource to process the events.
Event_throttle API (set rate to 1 ms) can avoid the events to flood
QMP client, but it could cause an unexpected delay (~1ms), guests
guests normally expect rx-filter updates immediately.
So we use a flag for each nic to avoid events flooding, the event
is emitted once until the query command is executed. The flag
implementation could not introduce unexpected delay.
There maybe exist an uncontrollable delay if we let Libvirt do the
real change, guests normally expect rx-filter updates immediately.
But it's another separate issue, we can investigate it when the
work in Libvirt side is done.
Michael S. Tsirkin: tweaked to enable events on start
Michael S. Tsirkin: fixed not to crash when no id
Michael S. Tsirkin: fold in patch:
"additional fixes for mac-programming feature"
Amos Kong: always notify QMP client if mactable is changed
Amos Kong: return NULL list if no net client supports rx-filter query
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-14 11:45:52 +04:00
|
|
|
|
qapi: Lazy creation of array types
Commit ac88219a had several TODO markers about whether we needed
to automatically create the corresponding array type alongside
any other type. It turns out that most of the time, we don't!
There are a few exceptions: 1) We have a few situations where we
use an array type in internal code but do not expose that type
through QMP; fix it by declaring a dummy type that forces the
generator to see that we want to use the array type.
2) The builtin arrays (such as intList for QAPI ['int']) must
always be generated, because of the way our QAPI_TYPES_BUILTIN
compile guard works: we have situations (at the very least
tests/test-qmp-output-visitor.c) that include both top-level
"qapi-types.h" (via "error.h") and a secondary
"test-qapi-types.h". If we were to only emit the builtin types
when used locally, then the first .h file would not include all
types, but the second .h does not declare anything at all because
the first .h set QAPI_TYPES_BUILTIN, and we would end up with
compilation error due to things like unknown type 'int8List'.
Actually, we may need to revisit how we do type guards, and
change from a single QAPI_TYPES_BUILTIN over to a different
usage pattern that does one #ifdef per qapi type - right now,
the only types that are declared multiple times between two qapi
.json files for inclusion by a single .c file happen to be the
builtin arrays. But now that we have QAPI 'include' statements,
it is logical to assume that we will soon reach a point where
we want to reuse non-builtin types (yes, I'm thinking about what
it will take to add introspection to QGA, where we will want to
reuse the SchemaInfo type and friends). One #ifdef per type
will help ensure that generating the same qapi type into more
than one qapi-types.h won't cause collisions when both are
included in the same .c file; but we also have to solve how to
avoid creating duplicate qapi-types.c entry points. So that
is a problem left for another day.
Generated code for qapi-types and qapi-visit is drastically
reduced; less than a third of the arrays that were blindly
created were actually needed (a quick grep shows we dropped
from 219 to 69 *List types), and the .o files lost more than
30% of their bulk. [For best results, diff the generated
files with 'git diff --patience --no-index pre post'.]
Interestingly, the introspection output is unchanged - this is
because we already cull all types that are not indirectly
reachable from a command or event, so introspection was already
using only a subset of array types. The subset of types
introspected is now a much larger percentage of the overall set
of array types emitted in qapi-types.h (since the larger set
shrunk), but still not 100% (evidence that the array types
emitted for our new Dummy structs, and the new struct itself,
don't affect QMP).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1444710158-8723-9-git-send-email-eblake@redhat.com>
[Moved array info tracking to a later patch]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-13 07:22:28 +03:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @DummyForceArrays:
|
qapi: Lazy creation of array types
Commit ac88219a had several TODO markers about whether we needed
to automatically create the corresponding array type alongside
any other type. It turns out that most of the time, we don't!
There are a few exceptions: 1) We have a few situations where we
use an array type in internal code but do not expose that type
through QMP; fix it by declaring a dummy type that forces the
generator to see that we want to use the array type.
2) The builtin arrays (such as intList for QAPI ['int']) must
always be generated, because of the way our QAPI_TYPES_BUILTIN
compile guard works: we have situations (at the very least
tests/test-qmp-output-visitor.c) that include both top-level
"qapi-types.h" (via "error.h") and a secondary
"test-qapi-types.h". If we were to only emit the builtin types
when used locally, then the first .h file would not include all
types, but the second .h does not declare anything at all because
the first .h set QAPI_TYPES_BUILTIN, and we would end up with
compilation error due to things like unknown type 'int8List'.
Actually, we may need to revisit how we do type guards, and
change from a single QAPI_TYPES_BUILTIN over to a different
usage pattern that does one #ifdef per qapi type - right now,
the only types that are declared multiple times between two qapi
.json files for inclusion by a single .c file happen to be the
builtin arrays. But now that we have QAPI 'include' statements,
it is logical to assume that we will soon reach a point where
we want to reuse non-builtin types (yes, I'm thinking about what
it will take to add introspection to QGA, where we will want to
reuse the SchemaInfo type and friends). One #ifdef per type
will help ensure that generating the same qapi type into more
than one qapi-types.h won't cause collisions when both are
included in the same .c file; but we also have to solve how to
avoid creating duplicate qapi-types.c entry points. So that
is a problem left for another day.
Generated code for qapi-types and qapi-visit is drastically
reduced; less than a third of the arrays that were blindly
created were actually needed (a quick grep shows we dropped
from 219 to 69 *List types), and the .o files lost more than
30% of their bulk. [For best results, diff the generated
files with 'git diff --patience --no-index pre post'.]
Interestingly, the introspection output is unchanged - this is
because we already cull all types that are not indirectly
reachable from a command or event, so introspection was already
using only a subset of array types. The subset of types
introspected is now a much larger percentage of the overall set
of array types emitted in qapi-types.h (since the larger set
shrunk), but still not 100% (evidence that the array types
emitted for our new Dummy structs, and the new struct itself,
don't affect QMP).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1444710158-8723-9-git-send-email-eblake@redhat.com>
[Moved array info tracking to a later patch]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-13 07:22:28 +03:00
|
|
|
#
|
|
|
|
# Not used by QMP; hack to let us use X86CPUFeatureWordInfoList internally
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.5
|
qapi: Lazy creation of array types
Commit ac88219a had several TODO markers about whether we needed
to automatically create the corresponding array type alongside
any other type. It turns out that most of the time, we don't!
There are a few exceptions: 1) We have a few situations where we
use an array type in internal code but do not expose that type
through QMP; fix it by declaring a dummy type that forces the
generator to see that we want to use the array type.
2) The builtin arrays (such as intList for QAPI ['int']) must
always be generated, because of the way our QAPI_TYPES_BUILTIN
compile guard works: we have situations (at the very least
tests/test-qmp-output-visitor.c) that include both top-level
"qapi-types.h" (via "error.h") and a secondary
"test-qapi-types.h". If we were to only emit the builtin types
when used locally, then the first .h file would not include all
types, but the second .h does not declare anything at all because
the first .h set QAPI_TYPES_BUILTIN, and we would end up with
compilation error due to things like unknown type 'int8List'.
Actually, we may need to revisit how we do type guards, and
change from a single QAPI_TYPES_BUILTIN over to a different
usage pattern that does one #ifdef per qapi type - right now,
the only types that are declared multiple times between two qapi
.json files for inclusion by a single .c file happen to be the
builtin arrays. But now that we have QAPI 'include' statements,
it is logical to assume that we will soon reach a point where
we want to reuse non-builtin types (yes, I'm thinking about what
it will take to add introspection to QGA, where we will want to
reuse the SchemaInfo type and friends). One #ifdef per type
will help ensure that generating the same qapi type into more
than one qapi-types.h won't cause collisions when both are
included in the same .c file; but we also have to solve how to
avoid creating duplicate qapi-types.c entry points. So that
is a problem left for another day.
Generated code for qapi-types and qapi-visit is drastically
reduced; less than a third of the arrays that were blindly
created were actually needed (a quick grep shows we dropped
from 219 to 69 *List types), and the .o files lost more than
30% of their bulk. [For best results, diff the generated
files with 'git diff --patience --no-index pre post'.]
Interestingly, the introspection output is unchanged - this is
because we already cull all types that are not indirectly
reachable from a command or event, so introspection was already
using only a subset of array types. The subset of types
introspected is now a much larger percentage of the overall set
of array types emitted in qapi-types.h (since the larger set
shrunk), but still not 100% (evidence that the array types
emitted for our new Dummy structs, and the new struct itself,
don't affect QMP).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1444710158-8723-9-git-send-email-eblake@redhat.com>
[Moved array info tracking to a later patch]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-13 07:22:28 +03:00
|
|
|
##
|
|
|
|
{ 'struct': 'DummyForceArrays',
|
|
|
|
'data': { 'unused': ['X86CPUFeatureWordInfo'] } }
|
|
|
|
|
|
|
|
|
2017-02-21 23:46:26 +03:00
|
|
|
##
|
|
|
|
# @NumaOptionsType:
|
|
|
|
#
|
numa: Allow setting NUMA distance for different NUMA nodes
This patch is going to add SLIT table support in QEMU, and provides
additional option `dist` for command `-numa` to allow user set vNUMA
distance by QEMU command.
With this patch, when a user wants to create a guest that contains
several vNUMA nodes and also wants to set distance among those nodes,
the QEMU command would like:
```
-numa node,nodeid=0,cpus=0 \
-numa node,nodeid=1,cpus=1 \
-numa node,nodeid=2,cpus=2 \
-numa node,nodeid=3,cpus=3 \
-numa dist,src=0,dst=1,val=21 \
-numa dist,src=0,dst=2,val=31 \
-numa dist,src=0,dst=3,val=41 \
-numa dist,src=1,dst=2,val=21 \
-numa dist,src=1,dst=3,val=31 \
-numa dist,src=2,dst=3,val=21 \
```
Signed-off-by: He Chen <he.chen@linux.intel.com>
Message-Id: <1493260558-20728-1-git-send-email-he.chen@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-04-27 05:35:58 +03:00
|
|
|
# @node: NUMA nodes configuration
|
|
|
|
#
|
|
|
|
# @dist: NUMA distance configuration (since 2.10)
|
|
|
|
#
|
numa: add '-numa cpu,...' option for property based node mapping
legacy cpu to node mapping is using cpu index values to map
VCPU to node with help of '-numa node,nodeid=node,cpus=x[-y]'
option. However cpu index is internal concept and QEMU users
have to guess /reimplement qemu's logic/ to map it to
a concrete cpu socket/core/thread to make sane CPUs
placement across numa nodes.
This patch allows to map cpu objects to numa nodes using
the same properties as used for cpus with -device/device_add
(socket-id/core-id/thread-id/node-id).
At present valid properties/values to address CPUs could be
fetched using hotpluggable-cpus monitor/qmp command, it will
require user to start qemu twice when creating domain to fetch
possible CPUs for a machine type/-smp layout first and
then the second time with numa explicit mapping for actual
usage. The first step results could be saved and reused to
set/change mapping later as far as machine type/-smp stays
the same.
Proposed impl. supports exact and wildcard matching to
simplify CLI and allow to set mapping for a specific cpu
or group of cpu objects specified by matched properties.
For example:
# exact mapping x86
-numa cpu,node-id=x,socket-id=y,core-id=z,thread-id=n
# exact mapping SPAPR
-numa cpu,node-id=x,core-id=y
# wildcard mapping, all cpu objects that match socket-id=y
# are mapped to node-id=x
-numa cpu,node-id=x,socket-id=y
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1494415802-227633-18-git-send-email-imammedo@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-10 14:30:01 +03:00
|
|
|
# @cpu: property based CPU(s) to node mapping (Since: 2.10)
|
|
|
|
#
|
2017-02-21 23:46:26 +03:00
|
|
|
# Since: 2.1
|
|
|
|
##
|
|
|
|
{ 'enum': 'NumaOptionsType',
|
numa: add '-numa cpu,...' option for property based node mapping
legacy cpu to node mapping is using cpu index values to map
VCPU to node with help of '-numa node,nodeid=node,cpus=x[-y]'
option. However cpu index is internal concept and QEMU users
have to guess /reimplement qemu's logic/ to map it to
a concrete cpu socket/core/thread to make sane CPUs
placement across numa nodes.
This patch allows to map cpu objects to numa nodes using
the same properties as used for cpus with -device/device_add
(socket-id/core-id/thread-id/node-id).
At present valid properties/values to address CPUs could be
fetched using hotpluggable-cpus monitor/qmp command, it will
require user to start qemu twice when creating domain to fetch
possible CPUs for a machine type/-smp layout first and
then the second time with numa explicit mapping for actual
usage. The first step results could be saved and reused to
set/change mapping later as far as machine type/-smp stays
the same.
Proposed impl. supports exact and wildcard matching to
simplify CLI and allow to set mapping for a specific cpu
or group of cpu objects specified by matched properties.
For example:
# exact mapping x86
-numa cpu,node-id=x,socket-id=y,core-id=z,thread-id=n
# exact mapping SPAPR
-numa cpu,node-id=x,core-id=y
# wildcard mapping, all cpu objects that match socket-id=y
# are mapped to node-id=x
-numa cpu,node-id=x,socket-id=y
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1494415802-227633-18-git-send-email-imammedo@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-10 14:30:01 +03:00
|
|
|
'data': [ 'node', 'dist', 'cpu' ] }
|
2017-02-21 23:46:26 +03:00
|
|
|
|
2014-05-14 13:43:08 +04:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @NumaOptions:
|
2014-05-14 13:43:08 +04:00
|
|
|
#
|
|
|
|
# A discriminated record of NUMA options. (for OptsVisitor)
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.1
|
2014-05-14 13:43:08 +04:00
|
|
|
##
|
|
|
|
{ 'union': 'NumaOptions',
|
2017-02-21 23:46:26 +03:00
|
|
|
'base': { 'type': 'NumaOptionsType' },
|
|
|
|
'discriminator': 'type',
|
2014-05-14 13:43:08 +04:00
|
|
|
'data': {
|
numa: Allow setting NUMA distance for different NUMA nodes
This patch is going to add SLIT table support in QEMU, and provides
additional option `dist` for command `-numa` to allow user set vNUMA
distance by QEMU command.
With this patch, when a user wants to create a guest that contains
several vNUMA nodes and also wants to set distance among those nodes,
the QEMU command would like:
```
-numa node,nodeid=0,cpus=0 \
-numa node,nodeid=1,cpus=1 \
-numa node,nodeid=2,cpus=2 \
-numa node,nodeid=3,cpus=3 \
-numa dist,src=0,dst=1,val=21 \
-numa dist,src=0,dst=2,val=31 \
-numa dist,src=0,dst=3,val=41 \
-numa dist,src=1,dst=2,val=21 \
-numa dist,src=1,dst=3,val=31 \
-numa dist,src=2,dst=3,val=21 \
```
Signed-off-by: He Chen <he.chen@linux.intel.com>
Message-Id: <1493260558-20728-1-git-send-email-he.chen@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-04-27 05:35:58 +03:00
|
|
|
'node': 'NumaNodeOptions',
|
numa: add '-numa cpu,...' option for property based node mapping
legacy cpu to node mapping is using cpu index values to map
VCPU to node with help of '-numa node,nodeid=node,cpus=x[-y]'
option. However cpu index is internal concept and QEMU users
have to guess /reimplement qemu's logic/ to map it to
a concrete cpu socket/core/thread to make sane CPUs
placement across numa nodes.
This patch allows to map cpu objects to numa nodes using
the same properties as used for cpus with -device/device_add
(socket-id/core-id/thread-id/node-id).
At present valid properties/values to address CPUs could be
fetched using hotpluggable-cpus monitor/qmp command, it will
require user to start qemu twice when creating domain to fetch
possible CPUs for a machine type/-smp layout first and
then the second time with numa explicit mapping for actual
usage. The first step results could be saved and reused to
set/change mapping later as far as machine type/-smp stays
the same.
Proposed impl. supports exact and wildcard matching to
simplify CLI and allow to set mapping for a specific cpu
or group of cpu objects specified by matched properties.
For example:
# exact mapping x86
-numa cpu,node-id=x,socket-id=y,core-id=z,thread-id=n
# exact mapping SPAPR
-numa cpu,node-id=x,core-id=y
# wildcard mapping, all cpu objects that match socket-id=y
# are mapped to node-id=x
-numa cpu,node-id=x,socket-id=y
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1494415802-227633-18-git-send-email-imammedo@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-10 14:30:01 +03:00
|
|
|
'dist': 'NumaDistOptions',
|
|
|
|
'cpu': 'NumaCpuOptions' }}
|
2014-05-14 13:43:08 +04:00
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @NumaNodeOptions:
|
2014-05-14 13:43:08 +04:00
|
|
|
#
|
|
|
|
# Create a guest NUMA node. (for OptsVisitor)
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @nodeid: NUMA node ID (increase by 1 from 0 if omitted)
|
2014-05-14 13:43:08 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @cpus: VCPUs belonging to this node (assign VCPUS round-robin
|
2014-05-14 13:43:08 +04:00
|
|
|
# if omitted)
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @mem: memory size of this node; mutually exclusive with @memdev.
|
numa: add -numa node,memdev= option
This option provides the infrastructure for binding guest NUMA nodes
to host NUMA nodes. For example:
-object memory-ram,size=1024M,policy=bind,host-nodes=0,id=ram-node0 \
-numa node,nodeid=0,cpus=0,memdev=ram-node0 \
-object memory-ram,size=1024M,policy=interleave,host-nodes=1-3,id=ram-node1 \
-numa node,nodeid=1,cpus=1,memdev=ram-node1
The option replaces "-numa node,mem=".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
MST: conflict resolution
2014-05-14 13:43:17 +04:00
|
|
|
# Equally divide total memory among nodes if both @mem and @memdev are
|
|
|
|
# omitted.
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @memdev: memory backend object. If specified for one node,
|
numa: add -numa node,memdev= option
This option provides the infrastructure for binding guest NUMA nodes
to host NUMA nodes. For example:
-object memory-ram,size=1024M,policy=bind,host-nodes=0,id=ram-node0 \
-numa node,nodeid=0,cpus=0,memdev=ram-node0 \
-object memory-ram,size=1024M,policy=interleave,host-nodes=1-3,id=ram-node1 \
-numa node,nodeid=1,cpus=1,memdev=ram-node1
The option replaces "-numa node,mem=".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
MST: conflict resolution
2014-05-14 13:43:17 +04:00
|
|
|
# it must be specified for all nodes.
|
2014-05-14 13:43:08 +04:00
|
|
|
#
|
|
|
|
# Since: 2.1
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'NumaNodeOptions',
|
2014-05-14 13:43:08 +04:00
|
|
|
'data': {
|
|
|
|
'*nodeid': 'uint16',
|
|
|
|
'*cpus': ['uint16'],
|
numa: add -numa node,memdev= option
This option provides the infrastructure for binding guest NUMA nodes
to host NUMA nodes. For example:
-object memory-ram,size=1024M,policy=bind,host-nodes=0,id=ram-node0 \
-numa node,nodeid=0,cpus=0,memdev=ram-node0 \
-object memory-ram,size=1024M,policy=interleave,host-nodes=1-3,id=ram-node1 \
-numa node,nodeid=1,cpus=1,memdev=ram-node1
The option replaces "-numa node,mem=".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
MST: conflict resolution
2014-05-14 13:43:17 +04:00
|
|
|
'*mem': 'size',
|
|
|
|
'*memdev': 'str' }}
|
2014-06-10 15:15:25 +04:00
|
|
|
|
numa: Allow setting NUMA distance for different NUMA nodes
This patch is going to add SLIT table support in QEMU, and provides
additional option `dist` for command `-numa` to allow user set vNUMA
distance by QEMU command.
With this patch, when a user wants to create a guest that contains
several vNUMA nodes and also wants to set distance among those nodes,
the QEMU command would like:
```
-numa node,nodeid=0,cpus=0 \
-numa node,nodeid=1,cpus=1 \
-numa node,nodeid=2,cpus=2 \
-numa node,nodeid=3,cpus=3 \
-numa dist,src=0,dst=1,val=21 \
-numa dist,src=0,dst=2,val=31 \
-numa dist,src=0,dst=3,val=41 \
-numa dist,src=1,dst=2,val=21 \
-numa dist,src=1,dst=3,val=31 \
-numa dist,src=2,dst=3,val=21 \
```
Signed-off-by: He Chen <he.chen@linux.intel.com>
Message-Id: <1493260558-20728-1-git-send-email-he.chen@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-04-27 05:35:58 +03:00
|
|
|
##
|
|
|
|
# @NumaDistOptions:
|
|
|
|
#
|
|
|
|
# Set the distance between 2 NUMA nodes.
|
|
|
|
#
|
|
|
|
# @src: source NUMA node.
|
|
|
|
#
|
|
|
|
# @dst: destination NUMA node.
|
|
|
|
#
|
|
|
|
# @val: NUMA distance from source node to destination node.
|
|
|
|
# When a node is unreachable from another node, set the distance
|
|
|
|
# between them to 255.
|
|
|
|
#
|
|
|
|
# Since: 2.10
|
|
|
|
##
|
|
|
|
{ 'struct': 'NumaDistOptions',
|
|
|
|
'data': {
|
|
|
|
'src': 'uint16',
|
|
|
|
'dst': 'uint16',
|
|
|
|
'val': 'uint8' }}
|
|
|
|
|
numa: add '-numa cpu,...' option for property based node mapping
legacy cpu to node mapping is using cpu index values to map
VCPU to node with help of '-numa node,nodeid=node,cpus=x[-y]'
option. However cpu index is internal concept and QEMU users
have to guess /reimplement qemu's logic/ to map it to
a concrete cpu socket/core/thread to make sane CPUs
placement across numa nodes.
This patch allows to map cpu objects to numa nodes using
the same properties as used for cpus with -device/device_add
(socket-id/core-id/thread-id/node-id).
At present valid properties/values to address CPUs could be
fetched using hotpluggable-cpus monitor/qmp command, it will
require user to start qemu twice when creating domain to fetch
possible CPUs for a machine type/-smp layout first and
then the second time with numa explicit mapping for actual
usage. The first step results could be saved and reused to
set/change mapping later as far as machine type/-smp stays
the same.
Proposed impl. supports exact and wildcard matching to
simplify CLI and allow to set mapping for a specific cpu
or group of cpu objects specified by matched properties.
For example:
# exact mapping x86
-numa cpu,node-id=x,socket-id=y,core-id=z,thread-id=n
# exact mapping SPAPR
-numa cpu,node-id=x,core-id=y
# wildcard mapping, all cpu objects that match socket-id=y
# are mapped to node-id=x
-numa cpu,node-id=x,socket-id=y
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1494415802-227633-18-git-send-email-imammedo@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-10 14:30:01 +03:00
|
|
|
##
|
|
|
|
# @NumaCpuOptions:
|
|
|
|
#
|
|
|
|
# Option "-numa cpu" overrides default cpu to node mapping.
|
|
|
|
# It accepts the same set of cpu properties as returned by
|
|
|
|
# query-hotpluggable-cpus[].props, where node-id could be used to
|
|
|
|
# override default node mapping.
|
|
|
|
#
|
|
|
|
# Since: 2.10
|
|
|
|
##
|
|
|
|
{ 'struct': 'NumaCpuOptions',
|
|
|
|
'base': 'CpuInstanceProperties',
|
|
|
|
'data' : {} }
|
|
|
|
|
2014-06-10 15:15:25 +04:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @HostMemPolicy:
|
2014-06-10 15:15:25 +04:00
|
|
|
#
|
|
|
|
# Host memory policy types
|
|
|
|
#
|
|
|
|
# @default: restore default policy, remove any nondefault policy
|
|
|
|
#
|
|
|
|
# @preferred: set the preferred host nodes for allocation
|
|
|
|
#
|
|
|
|
# @bind: a strict policy that restricts memory allocation to the
|
|
|
|
# host nodes specified
|
|
|
|
#
|
|
|
|
# @interleave: memory allocations are interleaved across the set
|
|
|
|
# of host nodes specified
|
|
|
|
#
|
2016-11-17 18:54:55 +03:00
|
|
|
# Since: 2.1
|
2014-06-10 15:15:25 +04:00
|
|
|
##
|
|
|
|
{ 'enum': 'HostMemPolicy',
|
|
|
|
'data': [ 'default', 'preferred', 'bind', 'interleave' ] }
|
2014-06-16 14:05:41 +04:00
|
|
|
|
|
|
|
##
|
|
|
|
# @Memdev:
|
|
|
|
#
|
2014-06-19 18:14:43 +04:00
|
|
|
# Information about memory backend
|
2014-06-16 14:05:41 +04:00
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @id: backend's ID if backend has 'id' property (since 2.9)
|
2017-01-10 15:53:15 +03:00
|
|
|
#
|
2014-06-19 18:14:43 +04:00
|
|
|
# @size: memory backend size
|
2014-06-16 14:05:41 +04:00
|
|
|
#
|
|
|
|
# @merge: enables or disables memory merge support
|
|
|
|
#
|
2014-06-19 18:14:43 +04:00
|
|
|
# @dump: includes memory backend's memory in a core dump or not
|
2014-06-16 14:05:41 +04:00
|
|
|
#
|
|
|
|
# @prealloc: enables or disables memory preallocation
|
|
|
|
#
|
|
|
|
# @host-nodes: host nodes for its memory policy
|
|
|
|
#
|
2014-06-19 18:14:43 +04:00
|
|
|
# @policy: memory policy of memory backend
|
2014-06-16 14:05:41 +04:00
|
|
|
#
|
|
|
|
# Since: 2.1
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'Memdev',
|
2014-06-16 14:05:41 +04:00
|
|
|
'data': {
|
2017-01-10 15:53:15 +03:00
|
|
|
'*id': 'str',
|
2014-06-16 14:05:41 +04:00
|
|
|
'size': 'size',
|
|
|
|
'merge': 'bool',
|
|
|
|
'dump': 'bool',
|
|
|
|
'prealloc': 'bool',
|
|
|
|
'host-nodes': ['uint16'],
|
|
|
|
'policy': 'HostMemPolicy' }}
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-memdev:
|
|
|
|
#
|
2014-06-19 18:14:43 +04:00
|
|
|
# Returns information for all memory backends.
|
2014-06-16 14:05:41 +04:00
|
|
|
#
|
|
|
|
# Returns: a list of @Memdev.
|
|
|
|
#
|
|
|
|
# Since: 2.1
|
2016-06-23 14:54:38 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-memdev" }
|
|
|
|
# <- { "return": [
|
|
|
|
# {
|
|
|
|
# "id": "mem1",
|
|
|
|
# "size": 536870912,
|
|
|
|
# "merge": false,
|
|
|
|
# "dump": true,
|
|
|
|
# "prealloc": false,
|
|
|
|
# "host-nodes": [0, 1],
|
|
|
|
# "policy": "bind"
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "size": 536870912,
|
|
|
|
# "merge": false,
|
|
|
|
# "dump": true,
|
|
|
|
# "prealloc": true,
|
|
|
|
# "host-nodes": [2, 3],
|
|
|
|
# "policy": "preferred"
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
#
|
2014-06-16 14:05:41 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-memdev', 'returns': ['Memdev'] }
|
2014-06-19 18:14:43 +04:00
|
|
|
|
|
|
|
##
|
2014-06-16 21:12:25 +04:00
|
|
|
# @PCDIMMDeviceInfo:
|
|
|
|
#
|
|
|
|
# PCDIMMDevice state information
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @id: device's ID
|
2014-06-16 21:12:25 +04:00
|
|
|
#
|
|
|
|
# @addr: physical address, where device is mapped
|
|
|
|
#
|
|
|
|
# @size: size of memory that the device provides
|
|
|
|
#
|
|
|
|
# @slot: slot number at which device is plugged in
|
|
|
|
#
|
|
|
|
# @node: NUMA node number where device is plugged in
|
|
|
|
#
|
|
|
|
# @memdev: memory backend linked with device
|
|
|
|
#
|
|
|
|
# @hotplugged: true if device was hotplugged
|
|
|
|
#
|
|
|
|
# @hotpluggable: true if device if could be added/removed while machine is running
|
|
|
|
#
|
|
|
|
# Since: 2.1
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'PCDIMMDeviceInfo',
|
2014-06-16 21:12:25 +04:00
|
|
|
'data': { '*id': 'str',
|
|
|
|
'addr': 'int',
|
|
|
|
'size': 'int',
|
|
|
|
'slot': 'int',
|
|
|
|
'node': 'int',
|
|
|
|
'memdev': 'str',
|
|
|
|
'hotplugged': 'bool',
|
|
|
|
'hotpluggable': 'bool'
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
##
|
|
|
|
# @MemoryDeviceInfo:
|
|
|
|
#
|
|
|
|
# Union containing information about a memory device
|
|
|
|
#
|
|
|
|
# Since: 2.1
|
|
|
|
##
|
|
|
|
{ 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'PCDIMMDeviceInfo'} }
|
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @query-memory-devices:
|
2014-06-16 21:12:25 +04:00
|
|
|
#
|
|
|
|
# Lists available memory devices and their state
|
|
|
|
#
|
|
|
|
# Since: 2.1
|
2016-06-23 14:55:05 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-memory-devices" }
|
|
|
|
# <- { "return": [ { "data":
|
|
|
|
# { "addr": 5368709120,
|
|
|
|
# "hotpluggable": true,
|
|
|
|
# "hotplugged": true,
|
|
|
|
# "id": "d1",
|
|
|
|
# "memdev": "/objects/memX",
|
|
|
|
# "node": 0,
|
|
|
|
# "size": 1073741824,
|
|
|
|
# "slot": 0},
|
|
|
|
# "type": "dimm"
|
|
|
|
# } ] }
|
|
|
|
#
|
2014-06-16 21:12:25 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-memory-devices', 'returns': ['MemoryDeviceInfo'] }
|
2014-06-16 21:12:26 +04:00
|
|
|
|
2017-08-24 22:14:05 +03:00
|
|
|
##
|
|
|
|
# @MEM_UNPLUG_ERROR:
|
|
|
|
#
|
|
|
|
# Emitted when memory hot unplug error occurs.
|
|
|
|
#
|
|
|
|
# @device: device name
|
|
|
|
#
|
|
|
|
# @msg: Informative message
|
|
|
|
#
|
|
|
|
# Since: 2.4
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# <- { "event": "MEM_UNPLUG_ERROR"
|
|
|
|
# "data": { "device": "dimm1",
|
|
|
|
# "msg": "acpi: device unplug for unsupported device"
|
|
|
|
# },
|
|
|
|
# "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'event': 'MEM_UNPLUG_ERROR',
|
|
|
|
'data': { 'device': 'str', 'msg': 'str' } }
|
|
|
|
|
2016-11-17 18:54:51 +03:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @ACPISlotType:
|
2014-06-16 21:12:26 +04:00
|
|
|
#
|
|
|
|
# @DIMM: memory slot
|
2016-04-22 20:06:36 +03:00
|
|
|
# @CPU: logical CPU slot (since 2.7)
|
2016-11-17 18:54:51 +03:00
|
|
|
##
|
2016-04-22 20:06:36 +03:00
|
|
|
{ 'enum': 'ACPISlotType', 'data': [ 'DIMM', 'CPU' ] }
|
2014-06-16 21:12:26 +04:00
|
|
|
|
2016-11-17 18:54:51 +03:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @ACPIOSTInfo:
|
2014-06-16 21:12:26 +04:00
|
|
|
#
|
|
|
|
# OSPM Status Indication for a device
|
|
|
|
# For description of possible values of @source and @status fields
|
|
|
|
# see "_OST (OSPM Status Indication)" chapter of ACPI5.0 spec.
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @device: device ID associated with slot
|
2014-06-16 21:12:26 +04:00
|
|
|
#
|
|
|
|
# @slot: slot ID, unique per slot of a given @slot-type
|
|
|
|
#
|
|
|
|
# @slot-type: type of the slot
|
|
|
|
#
|
|
|
|
# @source: an integer containing the source event
|
|
|
|
#
|
|
|
|
# @status: an integer containing the status code
|
|
|
|
#
|
|
|
|
# Since: 2.1
|
|
|
|
##
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'ACPIOSTInfo',
|
2014-06-16 21:12:26 +04:00
|
|
|
'data' : { '*device': 'str',
|
|
|
|
'slot': 'str',
|
|
|
|
'slot-type': 'ACPISlotType',
|
|
|
|
'source': 'int',
|
|
|
|
'status': 'int' } }
|
2014-06-16 21:12:28 +04:00
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @query-acpi-ospm-status:
|
2014-06-16 21:12:28 +04:00
|
|
|
#
|
2016-06-23 14:56:06 +03:00
|
|
|
# Return a list of ACPIOSTInfo for devices that support status
|
|
|
|
# reporting via ACPI _OST method.
|
2014-06-16 21:12:28 +04:00
|
|
|
#
|
|
|
|
# Since: 2.1
|
2016-06-23 14:56:06 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-acpi-ospm-status" }
|
|
|
|
# <- { "return": [ { "device": "d1", "slot": "0", "slot-type": "DIMM", "source": 1, "status": 0},
|
|
|
|
# { "slot": "1", "slot-type": "DIMM", "source": 0, "status": 0},
|
|
|
|
# { "slot": "2", "slot-type": "DIMM", "source": 0, "status": 0},
|
|
|
|
# { "slot": "3", "slot-type": "DIMM", "source": 0, "status": 0}
|
|
|
|
# ]}
|
|
|
|
#
|
2014-06-16 21:12:28 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'query-acpi-ospm-status', 'returns': ['ACPIOSTInfo'] }
|
2014-06-18 10:43:32 +04:00
|
|
|
|
2017-08-24 22:14:05 +03:00
|
|
|
##
|
|
|
|
# @ACPI_DEVICE_OST:
|
|
|
|
#
|
|
|
|
# Emitted when guest executes ACPI _OST method.
|
|
|
|
#
|
|
|
|
# @info: ACPIOSTInfo type as described in qapi-schema.json
|
|
|
|
#
|
|
|
|
# Since: 2.1
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# <- { "event": "ACPI_DEVICE_OST",
|
|
|
|
# "data": { "device": "d1", "slot": "0",
|
|
|
|
# "slot-type": "DIMM", "source": 1, "status": 0 } }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'event': 'ACPI_DEVICE_OST',
|
|
|
|
'data': { 'info': 'ACPIOSTInfo' } }
|
|
|
|
|
2014-06-25 01:55:11 +04:00
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @rtc-reset-reinjection:
|
2014-06-25 01:55:11 +04:00
|
|
|
#
|
|
|
|
# This command will reset the RTC interrupt reinjection backlog.
|
|
|
|
# Can be used if another mechanism to synchronize guest time
|
|
|
|
# is in effect, for example QEMU guest agent's guest-set-time
|
|
|
|
# command.
|
|
|
|
#
|
|
|
|
# Since: 2.1
|
2016-06-23 14:57:29 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "rtc-reset-reinjection" }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2014-06-25 01:55:11 +04:00
|
|
|
##
|
|
|
|
{ 'command': 'rtc-reset-reinjection' }
|
2015-06-11 04:21:21 +03:00
|
|
|
|
2017-08-24 22:14:05 +03:00
|
|
|
##
|
|
|
|
# @RTC_CHANGE:
|
|
|
|
#
|
|
|
|
# Emitted when the guest changes the RTC time.
|
|
|
|
#
|
|
|
|
# @offset: offset between base RTC clock (as specified by -rtc base), and
|
|
|
|
# new RTC clock value
|
|
|
|
#
|
|
|
|
# Note: This event is rate-limited.
|
|
|
|
#
|
|
|
|
# Since: 0.13.0
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# <- { "event": "RTC_CHANGE",
|
|
|
|
# "data": { "offset": 78 },
|
|
|
|
# "timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'event': 'RTC_CHANGE',
|
|
|
|
'data': { 'offset': 'int' } }
|
|
|
|
|
2015-09-17 19:23:37 +03:00
|
|
|
##
|
2016-11-17 18:54:52 +03:00
|
|
|
# @ReplayMode:
|
2015-09-17 19:23:37 +03:00
|
|
|
#
|
|
|
|
# Mode of the replay subsystem.
|
|
|
|
#
|
|
|
|
# @none: normal execution mode. Replay or record are not enabled.
|
|
|
|
#
|
|
|
|
# @record: record mode. All non-deterministic data is written into the
|
|
|
|
# replay log.
|
|
|
|
#
|
|
|
|
# @play: replay mode. Non-deterministic data required for system execution
|
|
|
|
# is read from the log.
|
|
|
|
#
|
|
|
|
# Since: 2.5
|
|
|
|
##
|
|
|
|
{ 'enum': 'ReplayMode',
|
|
|
|
'data': [ 'none', 'record', 'play' ] }
|
arm: qmp: add query-gic-capabilities interface
This patch add "query-gic-capabilities" but does not implement it. The
command is ARM-only. The command will return a list of GICCapability
structs that describes all GIC versions that current QEMU and system
support.
Libvirt is possibly the first consumer of this new command.
Before this patch, a libvirt user can successfully configure all kinds
of GIC devices for ARM guests, no matter whether current QEMU/kernel
supports them. If the specified GIC version/type is not supported, the
user will get an ambiguous "QEMU boot failure" error when trying to start
the VM. This is not user-friendly.
With this patch, libvirt should be able to query which type (and which
version) of GIC device is supported. Using this information, libvirt
can warn the user during configuration of guests when specified GIC
device type is not supported. Or better, we can just list those versions
that we support, and filter out the unsupported ones.
For example, if we got the query result:
{"return": [{"emulated": false, "version": 3, "kernel": true},
{"emulated": true, "version": 2, "kernel": false}]}
then it means that we support emulated GIC version 2 using:
qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ...
or KVM-accelerated GIC version 3 using:
qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ...
If we specify other explicit GIC versions rather than the above, QEMU
will not be able to boot.
The community is working on a more generic way to query these kinds of
information about valid values of machine properties. However, due to
the importance of supporting this specific use case, weecided to first
implement this ad-hoc one; then when the generic method is ready, we
can move on to that one smoothly.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com
[PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
|
|
|
|
2016-06-03 12:58:34 +03:00
|
|
|
##
|
|
|
|
# @xen-load-devices-state:
|
|
|
|
#
|
|
|
|
# Load the state of all devices from file. The RAM and the block devices
|
|
|
|
# of the VM are not loaded by this command.
|
|
|
|
#
|
|
|
|
# @filename: the file to load the state of the devices from as binary
|
|
|
|
# data. See xen-save-devices-state.txt for a description of the binary
|
|
|
|
# format.
|
|
|
|
#
|
|
|
|
# Since: 2.7
|
2016-06-23 16:39:50 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "xen-load-devices-state",
|
|
|
|
# "arguments": { "filename": "/tmp/resume" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
2016-06-03 12:58:34 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} }
|
|
|
|
|
arm: qmp: add query-gic-capabilities interface
This patch add "query-gic-capabilities" but does not implement it. The
command is ARM-only. The command will return a list of GICCapability
structs that describes all GIC versions that current QEMU and system
support.
Libvirt is possibly the first consumer of this new command.
Before this patch, a libvirt user can successfully configure all kinds
of GIC devices for ARM guests, no matter whether current QEMU/kernel
supports them. If the specified GIC version/type is not supported, the
user will get an ambiguous "QEMU boot failure" error when trying to start
the VM. This is not user-friendly.
With this patch, libvirt should be able to query which type (and which
version) of GIC device is supported. Using this information, libvirt
can warn the user during configuration of guests when specified GIC
device type is not supported. Or better, we can just list those versions
that we support, and filter out the unsupported ones.
For example, if we got the query result:
{"return": [{"emulated": false, "version": 3, "kernel": true},
{"emulated": true, "version": 2, "kernel": false}]}
then it means that we support emulated GIC version 2 using:
qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ...
or KVM-accelerated GIC version 3 using:
qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ...
If we specify other explicit GIC versions rather than the above, QEMU
will not be able to boot.
The community is working on a more generic way to query these kinds of
information about valid values of machine properties. However, due to
the importance of supporting this specific use case, weecided to first
implement this ad-hoc one; then when the generic method is ready, we
can move on to that one smoothly.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com
[PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
|
|
|
##
|
|
|
|
# @GICCapability:
|
|
|
|
#
|
|
|
|
# The struct describes capability for a specific GIC (Generic
|
|
|
|
# Interrupt Controller) version. These bits are not only decided by
|
|
|
|
# QEMU/KVM software version, but also decided by the hardware that
|
|
|
|
# the program is running upon.
|
|
|
|
#
|
|
|
|
# @version: version of GIC to be described. Currently, only 2 and 3
|
|
|
|
# are supported.
|
|
|
|
#
|
|
|
|
# @emulated: whether current QEMU/hardware supports emulated GIC
|
|
|
|
# device in user space.
|
|
|
|
#
|
|
|
|
# @kernel: whether current QEMU/hardware supports hardware
|
|
|
|
# accelerated GIC device in kernel.
|
|
|
|
#
|
|
|
|
# Since: 2.6
|
|
|
|
##
|
|
|
|
{ 'struct': 'GICCapability',
|
|
|
|
'data': { 'version': 'int',
|
|
|
|
'emulated': 'bool',
|
|
|
|
'kernel': 'bool' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-gic-capabilities:
|
|
|
|
#
|
|
|
|
# This command is ARM-only. It will return a list of GICCapability
|
|
|
|
# objects that describe its capability bits.
|
|
|
|
#
|
|
|
|
# Returns: a list of GICCapability objects.
|
|
|
|
#
|
|
|
|
# Since: 2.6
|
2016-06-23 16:26:12 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-gic-capabilities" }
|
|
|
|
# <- { "return": [{ "version": 2, "emulated": true, "kernel": false },
|
|
|
|
# { "version": 3, "emulated": false, "kernel": true } ] }
|
|
|
|
#
|
arm: qmp: add query-gic-capabilities interface
This patch add "query-gic-capabilities" but does not implement it. The
command is ARM-only. The command will return a list of GICCapability
structs that describes all GIC versions that current QEMU and system
support.
Libvirt is possibly the first consumer of this new command.
Before this patch, a libvirt user can successfully configure all kinds
of GIC devices for ARM guests, no matter whether current QEMU/kernel
supports them. If the specified GIC version/type is not supported, the
user will get an ambiguous "QEMU boot failure" error when trying to start
the VM. This is not user-friendly.
With this patch, libvirt should be able to query which type (and which
version) of GIC device is supported. Using this information, libvirt
can warn the user during configuration of guests when specified GIC
device type is not supported. Or better, we can just list those versions
that we support, and filter out the unsupported ones.
For example, if we got the query result:
{"return": [{"emulated": false, "version": 3, "kernel": true},
{"emulated": true, "version": 2, "kernel": false}]}
then it means that we support emulated GIC version 2 using:
qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ...
or KVM-accelerated GIC version 3 using:
qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ...
If we specify other explicit GIC versions rather than the above, QEMU
will not be able to boot.
The community is working on a more generic way to query these kinds of
information about valid values of machine properties. However, due to
the importance of supporting this specific use case, weecided to first
implement this ad-hoc one; then when the generic method is ready, we
can move on to that one smoothly.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com
[PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'query-gic-capabilities', 'returns': ['GICCapability'] }
|
2016-06-10 03:59:06 +03:00
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @CpuInstanceProperties:
|
2016-06-10 03:59:06 +03:00
|
|
|
#
|
|
|
|
# List of properties to be used for hotplugging a CPU instance,
|
|
|
|
# it should be passed by management with device_add command when
|
|
|
|
# a CPU is being hotplugged.
|
|
|
|
#
|
2017-03-15 15:57:06 +03:00
|
|
|
# @node-id: NUMA node ID the CPU belongs to
|
|
|
|
# @socket-id: socket number within node/board the CPU belongs to
|
|
|
|
# @core-id: core number within socket the CPU belongs to
|
|
|
|
# @thread-id: thread number within core the CPU belongs to
|
2017-01-13 17:41:21 +03:00
|
|
|
#
|
2016-06-10 03:59:06 +03:00
|
|
|
# Note: currently there are 4 properties that could be present
|
|
|
|
# but management should be prepared to pass through other
|
|
|
|
# properties with device_add command to allow for future
|
2016-06-24 00:23:34 +03:00
|
|
|
# interface extension. This also requires the filed names to be kept in
|
|
|
|
# sync with the properties passed to -device/device_add.
|
2016-06-10 03:59:06 +03:00
|
|
|
#
|
|
|
|
# Since: 2.7
|
|
|
|
##
|
|
|
|
{ 'struct': 'CpuInstanceProperties',
|
2016-06-24 00:23:34 +03:00
|
|
|
'data': { '*node-id': 'int',
|
|
|
|
'*socket-id': 'int',
|
|
|
|
'*core-id': 'int',
|
|
|
|
'*thread-id': 'int'
|
2016-06-10 03:59:06 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @HotpluggableCPU:
|
2016-06-10 03:59:06 +03:00
|
|
|
#
|
|
|
|
# @type: CPU object type for usage with device_add command
|
|
|
|
# @props: list of properties to be used for hotplugging CPU
|
|
|
|
# @vcpus-count: number of logical VCPU threads @HotpluggableCPU provides
|
2017-03-15 15:57:06 +03:00
|
|
|
# @qom-path: link to existing CPU object if CPU is present or
|
2016-06-10 03:59:06 +03:00
|
|
|
# omitted if CPU is not present.
|
|
|
|
#
|
|
|
|
# Since: 2.7
|
|
|
|
##
|
|
|
|
{ 'struct': 'HotpluggableCPU',
|
|
|
|
'data': { 'type': 'str',
|
|
|
|
'vcpus-count': 'int',
|
|
|
|
'props': 'CpuInstanceProperties',
|
|
|
|
'*qom-path': 'str'
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
##
|
2016-11-17 18:54:55 +03:00
|
|
|
# @query-hotpluggable-cpus:
|
2016-06-10 03:59:06 +03:00
|
|
|
#
|
|
|
|
# Returns: a list of HotpluggableCPU objects.
|
|
|
|
#
|
|
|
|
# Since: 2.7
|
2016-06-23 16:24:35 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# For pseries machine type started with -smp 2,cores=2,maxcpus=4 -cpu POWER8:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-hotpluggable-cpus" }
|
|
|
|
# <- {"return": [
|
|
|
|
# { "props": { "core": 8 }, "type": "POWER8-spapr-cpu-core",
|
|
|
|
# "vcpus-count": 1 },
|
|
|
|
# { "props": { "core": 0 }, "type": "POWER8-spapr-cpu-core",
|
|
|
|
# "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"}
|
|
|
|
# ]}'
|
|
|
|
#
|
|
|
|
# For pc machine type started with -smp 1,maxcpus=2:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-hotpluggable-cpus" }
|
|
|
|
# <- {"return": [
|
|
|
|
# {
|
|
|
|
# "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
|
|
|
|
# "props": {"core-id": 0, "socket-id": 1, "thread-id": 0}
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "qom-path": "/machine/unattached/device[0]",
|
|
|
|
# "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
|
|
|
|
# "props": {"core-id": 0, "socket-id": 0, "thread-id": 0}
|
|
|
|
# }
|
|
|
|
# ]}
|
|
|
|
#
|
2017-09-13 16:24:13 +03:00
|
|
|
# For s390x-virtio-ccw machine type started with -smp 1,maxcpus=2 -cpu qemu
|
|
|
|
# (Since: 2.11):
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-hotpluggable-cpus" }
|
|
|
|
# <- {"return": [
|
|
|
|
# {
|
2017-10-20 14:58:03 +03:00
|
|
|
# "type": "qemu-s390x-cpu", "vcpus-count": 1,
|
2017-09-13 16:24:13 +03:00
|
|
|
# "props": { "core-id": 1 }
|
|
|
|
# },
|
|
|
|
# {
|
|
|
|
# "qom-path": "/machine/unattached/device[0]",
|
2017-10-20 14:58:03 +03:00
|
|
|
# "type": "qemu-s390x-cpu", "vcpus-count": 1,
|
2017-09-13 16:24:13 +03:00
|
|
|
# "props": { "core-id": 0 }
|
|
|
|
# }
|
|
|
|
# ]}
|
|
|
|
#
|
2016-06-10 03:59:06 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }
|
2017-02-17 02:15:37 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @GuidInfo:
|
|
|
|
#
|
|
|
|
# GUID information.
|
|
|
|
#
|
|
|
|
# @guid: the globally unique identifier
|
|
|
|
#
|
|
|
|
# Since: 2.9
|
|
|
|
##
|
|
|
|
{ 'struct': 'GuidInfo', 'data': {'guid': 'str'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-vm-generation-id:
|
|
|
|
#
|
|
|
|
# Show Virtual Machine Generation ID
|
|
|
|
#
|
2017-10-02 17:13:31 +03:00
|
|
|
# Since: 2.9
|
2017-02-17 02:15:37 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
|
2017-09-07 11:05:26 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @watchdog-set-action:
|
|
|
|
#
|
|
|
|
# Set watchdog action
|
|
|
|
#
|
|
|
|
# Since: 2.11
|
|
|
|
##
|
|
|
|
{ 'command': 'watchdog-set-action', 'data' : {'action': 'WatchdogAction'} }
|