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 '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 75 ] } } 76 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. 82 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