5 # This document describes all commands currently supported by QMP.
7 # Most of the time their usage is exactly the same as in the user Monitor, this
8 # means that any other document which also describe commands (the manpage,
9 # QEMU's manual, etc) can and should be consulted.
11 # QMP has two types of commands: regular and query commands. Regular commands
12 # usually change the Virtual Machine's state someway, while query commands just
13 # return information. The sections below are divided accordingly.
15 # It's important to observe that all communication examples are formatted in
16 # a reader-friendly way, so that they're easier to understand. However, in real
17 # protocol usage, they're emitted as a single line.
19 # Also, the following notation is used to denote data flow:
23 # | -> data issued by the Client
24 # | <- Server data response
26 # Please, refer to the QMP specification (docs/interop/qmp-spec.txt) for
27 # detailed information on the Server command and response formats.
29 # = Stability Considerations
31 # The current QMP command set (described in this file) may be useful for a
32 # number of use cases, however it's limited and several commands have bad
33 # defined semantics, specially with regard to command completion.
35 # These problems are going to be solved incrementally in the next QEMU releases
36 # and we're going to establish a deprecation policy for badly defined commands.
38 # If you're planning to adopt QMP, please observe the following:
40 # 1. The deprecation policy will take effect and be documented soon, please
41 # check the documentation of each used command as soon as a new release of
44 # 2. DO NOT rely on anything which is not explicit documented
46 # 3. Errors, in special, are not documented. Applications should NOT check
47 # for specific errors classes or data (it's strongly recommended to only
48 # check for the "error" key)
52 { 'pragma': { 'doc-required': true } }
54 # Whitelists to permit QAPI rule violations; think twice before you
57 # Commands allowed to return a non-dictionary:
58 'returns-whitelist': [
59 'human-monitor-command',
61 'query-migrate-cache-size',
65 'name-case-whitelist': [
66 'ACPISlotType', # DIMM, visible through query-acpi-ospm-status
67 'CpuInfoMIPS', # PC, visible through query-cpu
68 'CpuInfoTricore', # PC, visible through query-cpu
69 'BlockdevVmdkSubformat', # all members, to match VMDK spec spellings
70 'BlockdevVmdkAdapterType', # legacyESX, to match VMDK spec spellings
71 'QapiErrorClass', # all members, visible through errors
72 'UuidInfo', # UUID, visible through query-uuid
73 'X86CPURegister32', # all members, visible indirectly through qom-get
74 'q_obj_CpuInfo-base' # CPU, visible through query-cpu
77 # Documentation generated with qapi-gen.py is in source order, with
78 # included sub-schemas inserted at the first include directive
79 # (subsequent include directives have no effect). To get a sane and
80 # stable order, it's best to include each sub-schema just once, or
81 # include it first right here.
83 { 'include': 'common.json' }
84 { 'include': 'sockets.json' }
85 { 'include': 'run-state.json' }
86 { 'include': 'crypto.json' }
87 { 'include': 'block.json' }
88 { 'include': 'char.json' }
89 { 'include': 'job.json' }
90 { 'include': 'net.json' }
91 { 'include': 'rdma.json' }
92 { 'include': 'rocker.json' }
93 { 'include': 'tpm.json' }
94 { 'include': 'ui.json' }
95 { 'include': 'authz.json' }
96 { 'include': 'migration.json' }
97 { 'include': 'transaction.json' }
98 { 'include': 'trace.json' }
99 { 'include': 'introspect.json' }
100 { 'include': 'misc.json' }
101 { 'include': 'target.json' }
102 { 'include': 'audio.json' }