xref: /openbmc/qemu/qapi/qapi-schema.json (revision 3ae8a100)
1# -*- Mode: Python -*-
2##
3# = Introduction
4#
5# This document describes all commands currently supported by QMP.
6#
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.
10#
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.
14#
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.
18#
19# Also, the following notation is used to denote data flow:
20#
21# Example:
22#
23# | -> data issued by the Client
24# | <- Server data response
25#
26# Please, refer to the QMP specification (docs/interop/qmp-spec.txt) for
27# detailed information on the Server command and response formats.
28#
29# = Stability Considerations
30#
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.
34#
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.
37#
38# If you're planning to adopt QMP, please observe the following:
39#
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
42#        QEMU is available
43#
44#     2. DO NOT rely on anything which is not explicit documented
45#
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)
49#
50##
51
52{ 'pragma': { 'doc-required': true } }
53
54# Whitelists to permit QAPI rule violations; think twice before you
55# add to them!
56{ 'pragma': {
57    # Commands allowed to return a non-dictionary:
58    'returns-whitelist': [
59        'human-monitor-command',
60        'qom-get',
61        'query-migrate-cache-size',
62        'query-tpm-models',
63        'query-tpm-types',
64        'ringbuf-read' ],
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        'QapiErrorClass',       # all members, visible through errors
70        'UuidInfo',             # UUID, visible through query-uuid
71        'X86CPURegister32',     # all members, visible indirectly through qom-get
72        'q_obj_CpuInfo-base'    # CPU, visible through query-cpu
73    ] } }
74
75# Documentation generated with qapi-gen.py is in source order, with
76# included sub-schemas inserted at the first include directive
77# (subsequent include directives have no effect).  To get a sane and
78# stable order, it's best to include each sub-schema just once, or
79# include it first right here.
80
81{ 'include': 'common.json' }
82{ 'include': 'sockets.json' }
83{ 'include': 'run-state.json' }
84{ 'include': 'crypto.json' }
85{ 'include': 'block.json' }
86{ 'include': 'char.json' }
87{ 'include': 'job.json' }
88{ 'include': 'net.json' }
89{ 'include': 'rocker.json' }
90{ 'include': 'tpm.json' }
91{ 'include': 'ui.json' }
92{ 'include': 'migration.json' }
93{ 'include': 'transaction.json' }
94{ 'include': 'trace.json' }
95{ 'include': 'introspect.json' }
96{ 'include': 'misc.json' }
97