| # -*- Mode: Python -*- |
| ## |
| # = 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/interop/qmp-spec.txt) for |
| # 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) |
| # |
| ## |
| |
| { '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 |
| ] } } |
| |
| # Documentation generated with qapi-gen.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 right here. |
| |
| { 'include': 'common.json' } |
| { 'include': 'sockets.json' } |
| { 'include': 'run-state.json' } |
| { 'include': 'crypto.json' } |
| { 'include': 'block.json' } |
| { 'include': 'char.json' } |
| { 'include': 'job.json' } |
| { 'include': 'net.json' } |
| { 'include': 'rocker.json' } |
| { 'include': 'tpm.json' } |
| { 'include': 'ui.json' } |
| { 'include': 'migration.json' } |
| { 'include': 'transaction.json' } |
| { 'include': 'trace.json' } |
| { 'include': 'introspect.json' } |
| { 'include': 'misc.json' } |