# -*- Mode: Python -*- # vim: filetype=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) # ## { 'include': 'pragma.json' } # 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': 'error.json' } { 'include': 'common.json' } { 'include': 'sockets.json' } { 'include': 'run-state.json' } { 'include': 'crypto.json' } { 'include': 'block.json' } { 'include': 'block-export.json' } { 'include': 'char.json' } { 'include': 'dump.json' } { 'include': 'job.json' } { 'include': 'net.json' } { 'include': 'rdma.json' } { 'include': 'rocker.json' } { 'include': 'tpm.json' } { 'include': 'ui.json' } { 'include': 'authz.json' } { 'include': 'migration.json' } { 'include': 'transaction.json' } { 'include': 'trace.json' } { 'include': 'control.json' } { 'include': 'introspect.json' } { 'include': 'qom.json' } { 'include': 'qdev.json' } { 'include': 'machine.json' } { 'include': 'machine-target.json' } { 'include': 'misc.json' } { 'include': 'misc-target.json' } { 'include': 'audio.json' } { 'include': 'acpi.json' } { 'include': 'pci.json' }