]> git.proxmox.com Git - mirror_qemu.git/blobdiff - qapi-schema.json
virtio-balloon: convert VMSTATE_VIRTIO_DEVICE
[mirror_qemu.git] / qapi-schema.json
index 8ab2ae9b78f71df454311709a1a635d0e546ddfb..c3dcf11a4acdd31cae25ea2555cd9f902f18010d 100644 (file)
 # QAPI introspection
 { 'include': 'qapi/introspect.json' }
 
+##
+# @qmp_capabilities:
+#
+# Enable QMP capabilities.
+#
+# Arguments: None.
+#
+# Example:
+#
+# -> { "execute": "qmp_capabilities" }
+# <- { "return": {} }
+#
+# Notes: This command is valid exactly when first connecting: it must be
+# issued before any other command will be accepted, and will fail once the
+# monitor is accepting other commands. (see qemu docs/qmp-spec.txt)
+#
+# Since: 0.13
+#
+##
+{ 'command': 'qmp_capabilities' }
+
 ##
 # @LostTickPolicy:
 #
 ##
 { 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
 
+##
+# @device_add:
+#
+# @driver: the name of the new device's driver
+#
+# @bus: #optional the device's parent bus (device tree path)
+#
+# @id: the device's ID, must be unique
+#
+# Additional arguments depend on the type.
+#
+# Add a device.
+#
+# Notes:
+# 1. For detailed information about this command, please refer to the
+#    'docs/qdev-device-use.txt' file.
+#
+# 2. It's possible to list device properties by running QEMU with the
+#    "-device DEVICE,help" command-line argument, where DEVICE is the
+#    device's name
+#
+# Example:
+#
+# -> { "execute": "device_add",
+#      "arguments": { "driver": "e1000", "id": "net1",
+#                     "bus": "pci.0",
+#                     "mac": "52:54:00:12:34:56" } }
+# <- { "return": {} }
+#
+# TODO This command effectively bypasses QAPI completely due to its
+# "additional arguments" business.  It shouldn't have been added to
+# the schema in this form.  It should be qapified properly, or
+# replaced by a properly qapified command.
+#
+# Since: 0.13
+##
+{ 'command': 'device_add',
+  'data': {'driver': 'str', 'id': 'str'},
+  'gen': false } # so we can get the additional arguments
+
 ##
 # @device_del:
 #
 #
 # @downscript: #optional script to shut down the interface
 #
+# @br: #optional bridge name (since 2.8)
+#
 # @helper: #optional command to execute to configure bridge
 #
 # @sndbuf: #optional send buffer limit. Understands [TGMKkb] suffixes.
     '*fds':        'str',
     '*script':     'str',
     '*downscript': 'str',
+    '*br':         'str',
     '*helper':     'str',
     '*sndbuf':     'size',
     '*vnet_hdr':   'bool',
 #   global properties may affect expansion of CPU models. Using
 #   query-cpu-model-expansion while using these is not advised.
 #
-# Some architectures may not support all expansion types.
+# Some architectures may not support all expansion types. s390x supports
+# "full" and "static".
 #
 # Returns: a CpuModelExpansionInfo. Returns an error if expanding CPU models is
 #          not supported, if the model cannot be expanded, if the model contains
 # @CpuModelCompareResult:
 #
 # An enumeration of CPU model comparation results. The result is usually
-# calcualted using e.g. CPU features or CPU generations.
+# calculated using e.g. CPU features or CPU generations.
 #
 # @incompatible: If model A is incompatible to model B, model A is not
 #                guaranteed to run where model B runs and the other way around.
 # CPU model has to be created by baselining.
 #
 # Usually, a CPU model is compared against the maximum possible CPU model
-# of a ceratin configuration (e.g. the "host" model for KVM). If that CPU
+# of a certain configuration (e.g. the "host" model for KVM). If that CPU
 # model is identical or a subset, it will run in that configuration.
 #
 # The result returned by this command may be affected by:
 #
 # * QEMU version: CPU models may look different depending on the QEMU version.
 #   (Except for CPU models reported as "static" in query-cpu-definitions.)
-# * machine-type: CPU model  may look different depending on the machine-type.
+# * machine-type: CPU model may look different depending on the machine-type.
 #   (Except for CPU models reported as "static" in query-cpu-definitions.)
 # * machine options (including accelerator): in some architectures, CPU models
 #   may look different depending on machine and accelerator options. (Except for
 #   global properties may affect expansion of CPU models. Using
 #   query-cpu-model-expansion while using these is not advised.
 #
-# Some architectures may not support comparing CPU models.
+# Some architectures may not support comparing CPU models. s390x supports
+# comparing CPU models.
 #
 # Returns: a CpuModelBaselineInfo. Returns an error if comparing CPU models is
 #          not supported, if a model cannot be used, if a model contains
   'data': { 'modela': 'CpuModelInfo', 'modelb': 'CpuModelInfo' },
   'returns': 'CpuModelCompareInfo' }
 
+##
+# @CpuModelBaselineInfo
+#
+# The result of a CPU model baseline.
+#
+# @model: the baselined CpuModelInfo.
+#
+# Since: 2.8.0
+##
+{ 'struct': 'CpuModelBaselineInfo',
+  'data': { 'model': 'CpuModelInfo' } }
+
+##
+# @query-cpu-model-baseline:
+#
+# Baseline two CPU models, creating a compatible third model. The created
+# model will always be a static, migration-safe CPU model (see "static"
+# CPU model expansion for details).
+#
+# This interface can be used by tooling to create a compatible CPU model out
+# two CPU models. The created CPU model will be identical to or a subset of
+# both CPU models when comparing them. Therefore, the created CPU model is
+# guaranteed to run where the given CPU models run.
+#
+# The result returned by this command may be affected by:
+#
+# * QEMU version: CPU models may look different depending on the QEMU version.
+#   (Except for CPU models reported as "static" in query-cpu-definitions.)
+# * machine-type: CPU model may look different depending on the machine-type.
+#   (Except for CPU models reported as "static" in query-cpu-definitions.)
+# * machine options (including accelerator): in some architectures, CPU models
+#   may look different depending on machine and accelerator options. (Except for
+#   CPU models reported as "static" in query-cpu-definitions.)
+# * "-cpu" arguments and global properties: arguments to the -cpu option and
+#   global properties may affect expansion of CPU models. Using
+#   query-cpu-model-expansion while using these is not advised.
+#
+# Some architectures may not support baselining CPU models. s390x supports
+# baselining CPU models.
+#
+# Returns: a CpuModelBaselineInfo. Returns an error if baselining CPU models is
+#          not supported, if a model cannot be used, if a model contains
+#          an unknown cpu definition name, unknown properties or properties
+#          with wrong types.
+#
+# Since: 2.8.0
+##
+{ 'command': 'query-cpu-model-baseline',
+  'data': { 'modela': 'CpuModelInfo',
+            'modelb': 'CpuModelInfo' },
+  'returns': 'CpuModelBaselineInfo' }
+
 # @AddfdInfo:
 #
 # Information about a file descriptor that was added to an fd set.