2015-08-21 07:04:50 +00:00
|
|
|
# -*- Mode: Python -*-
|
2018-03-03 23:23:47 +00: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
|
|
|
|
#
|
|
|
|
# Please, refer to the QMP specification (docs/qmp-spec.txt) for
|
|
|
|
# detailed information on the Server command and response formats.
|
|
|
|
#
|
|
|
|
# = Stability Considerations
|
2015-08-21 07:04:50 +00:00
|
|
|
#
|
2018-03-03 23:23:47 +00:00
|
|
|
# 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)
|
|
|
|
#
|
|
|
|
##
|
|
|
|
|
|
|
|
{ 'pragma': { 'doc-required': true } }
|
|
|
|
|
|
|
|
# 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',
|
|
|
|
'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
|
|
|
|
] } }
|
2015-08-21 07:04:50 +00:00
|
|
|
|
|
|
|
# QAPI common definitions
|
|
|
|
{ 'include': 'qapi/common.json' }
|
|
|
|
|
|
|
|
##
|
2018-03-01 14:06:59 +00:00
|
|
|
# @X86CPURegister32:
|
2015-08-21 07:04:50 +00:00
|
|
|
#
|
|
|
|
# A X86 32-bit register
|
|
|
|
#
|
|
|
|
# Since: 1.5
|
|
|
|
##
|
|
|
|
{ 'enum': 'X86CPURegister32',
|
|
|
|
'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] }
|
|
|
|
|
|
|
|
##
|
2018-03-01 14:06:59 +00:00
|
|
|
# @X86CPUFeatureWordInfo:
|
2015-08-21 07:04:50 +00:00
|
|
|
#
|
|
|
|
# Information about a X86 CPU feature word
|
|
|
|
#
|
|
|
|
# @cpuid-input-eax: Input EAX value for CPUID instruction for that feature word
|
|
|
|
#
|
2018-03-03 23:23:47 +00:00
|
|
|
# @cpuid-input-ecx: Input ECX value for CPUID instruction for that
|
2015-08-21 07:04:50 +00:00
|
|
|
# feature word
|
|
|
|
#
|
|
|
|
# @cpuid-register: Output register containing the feature bits
|
|
|
|
#
|
|
|
|
# @features: value of output register, containing the feature bits
|
|
|
|
#
|
|
|
|
# Since: 1.5
|
|
|
|
##
|
2018-02-19 19:22:10 +00:00
|
|
|
{ 'struct': 'X86CPUFeatureWordInfo',
|
2015-08-21 07:04:50 +00:00
|
|
|
'data': { 'cpuid-input-eax': 'int',
|
|
|
|
'*cpuid-input-ecx': 'int',
|
|
|
|
'cpuid-register': 'X86CPURegister32',
|
|
|
|
'features': 'int' } }
|
|
|
|
|
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).
Backports commit 9f08c8ec73878122ad4b061ed334f0437afaaa32 from qemu
2018-02-19 23:55:33 +00:00
|
|
|
##
|
2018-03-01 14:06:59 +00: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).
Backports commit 9f08c8ec73878122ad4b061ed334f0437afaaa32 from qemu
2018-02-19 23:55:33 +00:00
|
|
|
#
|
|
|
|
# Not used by QMP; hack to let us use X86CPUFeatureWordInfoList internally
|
|
|
|
#
|
2018-03-01 14:06:59 +00: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).
Backports commit 9f08c8ec73878122ad4b061ed334f0437afaaa32 from qemu
2018-02-19 23:55:33 +00:00
|
|
|
##
|
|
|
|
{ 'struct': 'DummyForceArrays',
|
|
|
|
'data': { 'unused': ['X86CPUFeatureWordInfo'] } }
|
|
|
|
|