# 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:
#
# @watchdog: the watchdog action is configured to pause and has been triggered
#
# @guest-panicked: guest has been panicked as a result of guest OS panic
+#
+# @colo: guest is paused to save/restore VM state under colo checkpoint,
+# VM can not get into this state unless colo capability is enabled
+# for migration. (since 2.8)
##
{ 'enum': 'RunState',
'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
- 'guest-panicked' ] }
+ 'guest-panicked', 'colo' ] }
##
# @StatusInfo:
#
# @failed: some error occurred during migration process.
#
+# @colo: VM is in the process of fault tolerance, VM can not get into this
+# state unless colo capability is enabled for migration. (since 2.8)
+#
# Since: 2.3
#
##
{ 'enum': 'MigrationStatus',
'data': [ 'none', 'setup', 'cancelling', 'cancelled',
- 'active', 'postcopy-active', 'completed', 'failed' ] }
+ 'active', 'postcopy-active', 'completed', 'failed', 'colo' ] }
##
# @MigrationInfo
# been migrated, pulling the remaining pages along as needed. NOTE: If
# the migration fails during postcopy the VM will fail. (since 2.6)
#
+# @x-colo: If enabled, migration will never end, and the state of the VM on the
+# primary side will be migrated continuously to the VM on secondary
+# side, this process is called COarse-Grain LOck Stepping (COLO) for
+# Non-stop Service. (since 2.8)
+#
# Since: 1.2
##
{ 'enum': 'MigrationCapability',
'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
- 'compress', 'events', 'postcopy-ram'] }
+ 'compress', 'events', 'postcopy-ram', 'x-colo'] }
##
# @MigrationCapabilityStatus
# hostname must be provided so that the server's x509
# certificate identity can be validated. (Since 2.7)
#
+# @max-bandwidth: to set maximum speed for migration. maximum speed in
+# bytes per second. (Since 2.8)
+#
+# @downtime-limit: set maximum tolerated downtime for migration. maximum
+# downtime in milliseconds (Since 2.8)
+#
+# @x-checkpoint-delay: The delay time (in ms) between two COLO checkpoints in
+# periodic mode. (Since 2.8)
+#
# Since: 2.4
##
{ 'enum': 'MigrationParameter',
'data': ['compress-level', 'compress-threads', 'decompress-threads',
'cpu-throttle-initial', 'cpu-throttle-increment',
- 'tls-creds', 'tls-hostname'] }
+ 'tls-creds', 'tls-hostname', 'max-bandwidth',
+ 'downtime-limit', 'x-checkpoint-delay' ] }
#
# @migrate-set-parameters
#
-# Set the following migration parameters
+# Set various migration parameters. See MigrationParameters for details.
#
-# @compress-level: compression level
-#
-# @compress-threads: compression thread count
-#
-# @decompress-threads: decompression thread count
-#
-# @cpu-throttle-initial: Initial percentage of time guest cpus are throttled
-# when migration auto-converge is activated. The
-# default value is 20. (Since 2.7)
-#
-# @cpu-throttle-increment: throttle percentage increase each time
-# auto-converge detects that migration is not making
-# progress. The default value is 10. (Since 2.7)
-#
-# @tls-creds: ID of the 'tls-creds' object that provides credentials for
-# establishing a TLS connection over the migration data channel.
-# On the outgoing side of the migration, the credentials must
-# be for a 'client' endpoint, while for the incoming side the
-# credentials must be for a 'server' endpoint. Setting this
-# will enable TLS for all migrations. The default is unset,
-# resulting in unsecured migration at the QEMU level. (Since 2.7)
-#
-# @tls-hostname: hostname of the target host for the migration. This is
-# required when using x509 based TLS credentials and the
-# migration URI does not already include a hostname. For
-# example if using fd: or exec: based migration, the
-# hostname must be provided so that the server's x509
-# certificate identity can be validated. (Since 2.7)
+# @x-checkpoint-delay: the delay time between two checkpoints. (Since 2.8)
#
# Since: 2.4
##
-{ 'command': 'migrate-set-parameters',
- 'data': { '*compress-level': 'int',
- '*compress-threads': 'int',
- '*decompress-threads': 'int',
- '*cpu-throttle-initial': 'int',
- '*cpu-throttle-increment': 'int',
- '*tls-creds': 'str',
- '*tls-hostname': 'str'} }
+{ 'command': 'migrate-set-parameters', 'boxed': true,
+ 'data': 'MigrationParameters' }
#
# @MigrationParameters
#
-# @compress-level: compression level
+# Optional members can be omitted on input ('migrate-set-parameters')
+# but most members will always be present on output
+# ('query-migrate-parameters'), with the exception of tls-creds and
+# tls-hostname.
#
-# @compress-threads: compression thread count
+# @compress-level: #optional compression level
#
-# @decompress-threads: decompression thread count
+# @compress-threads: #optional compression thread count
#
-# @cpu-throttle-initial: Initial percentage of time guest cpus are throttled
-# when migration auto-converge is activated. The
-# default value is 20. (Since 2.7)
+# @decompress-threads: #optional decompression thread count
#
-# @cpu-throttle-increment: throttle percentage increase each time
+# @cpu-throttle-initial: #optional Initial percentage of time guest cpus are
+# throttledwhen migration auto-converge is activated.
+# The default value is 20. (Since 2.7)
+#
+# @cpu-throttle-increment: #optional throttle percentage increase each time
# auto-converge detects that migration is not making
# progress. The default value is 10. (Since 2.7)
#
-# @tls-creds: ID of the 'tls-creds' object that provides credentials for
-# establishing a TLS connection over the migration data channel.
-# On the outgoing side of the migration, the credentials must
-# be for a 'client' endpoint, while for the incoming side the
+# @tls-creds: #optional ID of the 'tls-creds' object that provides credentials
+# for establishing a TLS connection over the migration data
+# channel. On the outgoing side of the migration, the credentials
+# must be for a 'client' endpoint, while for the incoming side the
# credentials must be for a 'server' endpoint. Setting this
# will enable TLS for all migrations. The default is unset,
# resulting in unsecured migration at the QEMU level. (Since 2.7)
#
-# @tls-hostname: hostname of the target host for the migration. This is
-# required when using x509 based TLS credentials and the
+# @tls-hostname: #optional hostname of the target host for the migration. This
+# is required when using x509 based TLS credentials and the
# migration URI does not already include a hostname. For
# example if using fd: or exec: based migration, the
# hostname must be provided so that the server's x509
# certificate identity can be validated. (Since 2.7)
#
+# @max-bandwidth: to set maximum speed for migration. maximum speed in
+# bytes per second. (Since 2.8)
+#
+# @downtime-limit: set maximum tolerated downtime for migration. maximum
+# downtime in milliseconds (Since 2.8)
+#
+# @x-checkpoint-delay: the delay time between two COLO checkpoints. (Since 2.8)
+#
# Since: 2.4
##
{ 'struct': 'MigrationParameters',
- 'data': { 'compress-level': 'int',
- 'compress-threads': 'int',
- 'decompress-threads': 'int',
- 'cpu-throttle-initial': 'int',
- 'cpu-throttle-increment': 'int',
- 'tls-creds': 'str',
- 'tls-hostname': 'str'} }
+ 'data': { '*compress-level': 'int',
+ '*compress-threads': 'int',
+ '*decompress-threads': 'int',
+ '*cpu-throttle-initial': 'int',
+ '*cpu-throttle-increment': 'int',
+ '*tls-creds': 'str',
+ '*tls-hostname': 'str',
+ '*max-bandwidth': 'int',
+ '*downtime-limit': 'int',
+ '*x-checkpoint-delay': 'int'} }
+
##
# @query-migrate-parameters
#
# Since: 2.5
{ 'command': 'migrate-start-postcopy' }
+##
+# @COLOMessage
+#
+# The message transmission between Primary side and Secondary side.
+#
+# @checkpoint-ready: Secondary VM (SVM) is ready for checkpointing
+#
+# @checkpoint-request: Primary VM (PVM) tells SVM to prepare for checkpointing
+#
+# @checkpoint-reply: SVM gets PVM's checkpoint request
+#
+# @vmstate-send: VM's state will be sent by PVM.
+#
+# @vmstate-size: The total size of VMstate.
+#
+# @vmstate-received: VM's state has been received by SVM.
+#
+# @vmstate-loaded: VM's state has been loaded by SVM.
+#
+# Since: 2.8
+##
+{ 'enum': 'COLOMessage',
+ 'data': [ 'checkpoint-ready', 'checkpoint-request', 'checkpoint-reply',
+ 'vmstate-send', 'vmstate-size', 'vmstate-received',
+ 'vmstate-loaded' ] }
+
+##
+# @COLOMode
+#
+# The colo mode
+#
+# @unknown: unknown mode
+#
+# @primary: master side
+#
+# @secondary: slave side
+#
+# Since: 2.8
+##
+{ 'enum': 'COLOMode',
+ 'data': [ 'unknown', 'primary', 'secondary'] }
+
+##
+# @FailoverStatus
+#
+# An enumeration of COLO failover status
+#
+# @none: no failover has ever happened
+#
+# @require: got failover requirement but not handled
+#
+# @active: in the process of doing failover
+#
+# @completed: finish the process of failover
+#
+# Since: 2.8
+##
+{ 'enum': 'FailoverStatus',
+ 'data': [ 'none', 'require', 'active', 'completed'] }
+
+##
+# @x-colo-lost-heartbeat
+#
+# Tell qemu that heartbeat is lost, request it to do takeover procedures.
+# If this command is sent to the PVM, the Primary side will exit COLO mode.
+# If sent to the Secondary, the Secondary side will run failover work,
+# then takes over server operation to become the service VM.
+#
+# Since: 2.8
+##
+{ 'command': 'x-colo-lost-heartbeat' }
+
##
# @MouseInfo:
#
#
# @unix: unix socket
#
+# @vsock: vsock family (since 2.8)
+#
# @unknown: otherwise
#
# Since: 2.1
##
{ 'enum': 'NetworkAddressFamily',
- 'data': [ 'ipv4', 'ipv6', 'unix', 'unknown' ] }
+ 'data': [ 'ipv4', 'ipv6', 'unix', 'vsock', 'unknown' ] }
##
# @VncBasicInfo
#
# Returns: nothing on success
#
+# Notes: This command is deprecated in favor of 'migrate-set-parameters'
+#
# Since: 0.14.0
##
{ 'command': 'migrate_set_downtime', 'data': {'value': 'number'} }
#
# Returns: nothing on success
#
-# Notes: A value lesser than zero will be automatically round up to zero.
+# Notes: This command is deprecated in favor of 'migrate-set-parameters'
#
# Since: 0.14.0
##
##
{ '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.
#
# @queues: #optional number of queues to be created for multiqueue capable tap
#
+# @poll-us: #optional maximum number of microseconds that could
+# be spent on busy polling for tap (since 2.7)
+#
# Since 1.2
##
{ 'struct': 'NetdevTapOptions',
'*fds': 'str',
'*script': 'str',
'*downscript': 'str',
+ '*br': 'str',
'*helper': 'str',
'*sndbuf': 'size',
'*vnet_hdr': 'bool',
'*vhostfd': 'str',
'*vhostfds': 'str',
'*vhostforce': 'bool',
- '*queues': 'uint32'} }
+ '*queues': 'uint32',
+ '*poll-us': 'uint32'} }
##
# @NetdevSocketOptions
'*queues': 'int' } }
##
-# @NetClientOptions
+# @NetClientDriver
+#
+# Available netdev drivers.
+#
+# Since 2.7
+##
+{ 'enum': 'NetClientDriver',
+ 'data': [ 'none', 'nic', 'user', 'tap', 'l2tpv3', 'socket', 'vde', 'dump',
+ 'bridge', 'hubport', 'netmap', 'vhost-user' ] }
+
+##
+# @Netdev
+#
+# Captures the configuration of a network device.
+#
+# @id: identifier for monitor commands.
#
-# A discriminated record of network device traits.
+# @type: Specify the driver used for interpreting remaining arguments.
#
# Since 1.2
#
# 'l2tpv3' - since 2.1
-#
##
-{ 'union': 'NetClientOptions',
+{ 'union': 'Netdev',
+ 'base': { 'id': 'str', 'type': 'NetClientDriver' },
+ 'discriminator': 'type',
'data': {
'none': 'NetdevNoneOptions',
'nic': 'NetLegacyNicOptions',
'*vlan': 'int32',
'*id': 'str',
'*name': 'str',
- 'opts': 'NetClientOptions' } }
+ 'opts': 'NetLegacyOptions' } }
##
-# @Netdev
+# @NetLegacyOptions
#
-# Captures the configuration of a network device.
-#
-# @id: identifier for monitor commands.
-#
-# @opts: device type specific properties
+# Like Netdev, but for use only by the legacy command line options
#
# Since 1.2
##
-{ 'struct': 'Netdev',
+{ 'union': 'NetLegacyOptions',
'data': {
- 'id': 'str',
- 'opts': 'NetClientOptions' } }
+ 'none': 'NetdevNoneOptions',
+ 'nic': 'NetLegacyNicOptions',
+ 'user': 'NetdevUserOptions',
+ 'tap': 'NetdevTapOptions',
+ 'l2tpv3': 'NetdevL2TPv3Options',
+ 'socket': 'NetdevSocketOptions',
+ 'vde': 'NetdevVdeOptions',
+ 'dump': 'NetdevDumpOptions',
+ 'bridge': 'NetdevBridgeOptions',
+ 'netmap': 'NetdevNetmapOptions',
+ 'vhost-user': 'NetdevVhostUserOptions' } }
##
# @NetFilterDirection
'data': {
'path': 'str' } }
+##
+# @VsockSocketAddress
+#
+# Captures a socket address in the vsock namespace.
+#
+# @cid: unique host identifier
+# @port: port
+#
+# Note that string types are used to allow for possible future hostname or
+# service resolution support.
+#
+# Since 2.8
+##
+{ 'struct': 'VsockSocketAddress',
+ 'data': {
+ 'cid': 'str',
+ 'port': 'str' } }
+
##
# @SocketAddress
#
'data': {
'inet': 'InetSocketAddress',
'unix': 'UnixSocketAddress',
+ 'vsock': 'VsockSocketAddress',
'fd': 'String' } }
##
# @cpu-max: maximum number of CPUs supported by the machine type
# (since 1.5.0)
#
+# @hotpluggable-cpus: cpu hotplug via -device is supported (since 2.7.0)
+#
# Since: 1.2.0
##
{ 'struct': 'MachineInfo',
'data': { 'name': 'str', '*alias': 'str',
- '*is-default': 'bool', 'cpu-max': 'int' } }
+ '*is-default': 'bool', 'cpu-max': 'int',
+ 'hotpluggable-cpus': 'bool'} }
##
# @query-machines:
#
# @name: the name of the CPU definition
#
+# @migration-safe: #optional whether a CPU definition can be safely used for
+# migration in combination with a QEMU compatibility machine
+# when migrating between different QMU versions and between
+# hosts with different sets of (hardware or software)
+# capabilities. If not provided, information is not available
+# and callers should not assume the CPU definition to be
+# migration-safe. (since 2.8)
+#
+# @static: whether a CPU definition is static and will not change depending on
+# QEMU version, machine type, machine options and accelerator options.
+# A static model is always migration-safe. (since 2.8)
+#
+# @unavailable-features: #optional List of properties that prevent
+# the CPU model from running in the current
+# host. (since 2.8)
+#
+# @unavailable-features is a list of QOM property names that
+# represent CPU model attributes that prevent the CPU from running.
+# If the QOM property is read-only, that means there's no known
+# way to make the CPU model run in the current host. Implementations
+# that choose not to provide specific information return the
+# property name "type".
+# If the property is read-write, it means that it MAY be possible
+# to run the CPU model in the current host if that property is
+# changed. Management software can use it as hints to suggest or
+# choose an alternative for the user, or just to generate meaningful
+# error messages explaining why the CPU model can't be used.
+# If @unavailable-features is an empty list, the CPU model is
+# runnable using the current host and machine-type.
+# If @unavailable-features is not present, runnability
+# information for the CPU is not available.
+#
# Since: 1.2.0
##
{ 'struct': 'CpuDefinitionInfo',
- 'data': { 'name': 'str' } }
+ 'data': { 'name': 'str', '*migration-safe': 'bool', 'static': 'bool',
+ '*unavailable-features': [ 'str' ] } }
##
# @query-cpu-definitions:
##
{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
+##
+# @CpuModelInfo:
+#
+# Virtual CPU model.
+#
+# A CPU model consists of the name of a CPU definition, to which
+# delta changes are applied (e.g. features added/removed). Most magic values
+# that an architecture might require should be hidden behind the name.
+# However, if required, architectures can expose relevant properties.
+#
+# @name: the name of the CPU definition the model is based on
+# @props: #optional a dictionary of QOM properties to be applied
+#
+# Since: 2.8.0
+##
+{ 'struct': 'CpuModelInfo',
+ 'data': { 'name': 'str',
+ '*props': 'any' } }
+
+##
+# @CpuModelExpansionType
+#
+# An enumeration of CPU model expansion types.
+#
+# @static: Expand to a static CPU model, a combination of a static base
+# model name and property delta changes. As the static base model will
+# never change, the expanded CPU model will be the same, independant of
+# independent of QEMU version, machine type, machine options, and
+# accelerator options. Therefore, the resulting model can be used by
+# tooling without having to specify a compatibility machine - e.g. when
+# displaying the "host" model. static CPU models are migration-safe.
+#
+# @full: Expand all properties. The produced model is not guaranteed to be
+# migration-safe, but allows tooling to get an insight and work with
+# model details.
+#
+# Since: 2.8.0
+##
+{ 'enum': 'CpuModelExpansionType',
+ 'data': [ 'static', 'full' ] }
+
+
+##
+# @CpuModelExpansionInfo
+#
+# The result of a cpu model expansion.
+#
+# @model: the expanded CpuModelInfo.
+#
+# Since: 2.8.0
+##
+{ 'struct': 'CpuModelExpansionInfo',
+ 'data': { 'model': 'CpuModelInfo' } }
+
+
+##
+# @query-cpu-model-expansion:
+#
+# Expands a given CPU model (or a combination of CPU model + additional options)
+# to different granularities, allowing tooling to get an understanding what a
+# specific CPU model looks like in QEMU under a certain configuration.
+#
+# This interface can be used to query the "host" CPU model.
+#
+# The data 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 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
+# an unknown CPU definition name, unknown properties or properties
+# with a wrong type. Also returns an error if an expansion type is
+# not supported.
+#
+# Since: 2.8.0
+##
+{ 'command': 'query-cpu-model-expansion',
+ 'data': { 'type': 'CpuModelExpansionType',
+ 'model': 'CpuModelInfo' },
+ 'returns': 'CpuModelExpansionInfo' }
+
+##
+# @CpuModelCompareResult:
+#
+# An enumeration of CPU model comparation results. The result is usually
+# 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.
+#
+# @identical: If model A is identical to model B, model A is guaranteed to run
+# where model B runs and the other way around.
+#
+# @superset: If model A is a superset of model B, model B is guaranteed to run
+# where model A runs. There are no guarantees about the other way.
+#
+# @subset: If model A is a subset of model B, model A is guaranteed to run
+# where model B runs. There are no guarantees about the other way.
+#
+# Since: 2.8.0
+##
+{ 'enum': 'CpuModelCompareResult',
+ 'data': [ 'incompatible', 'identical', 'superset', 'subset' ] }
+
+##
+# @CpuModelCompareInfo
+#
+# The result of a CPU model comparison.
+#
+# @result: The result of the compare operation.
+# @responsible-properties: List of properties that led to the comparison result
+# not being identical.
+#
+# @responsible-properties is a list of QOM property names that led to
+# both CPUs not being detected as identical. For identical models, this
+# list is empty.
+# If a QOM property is read-only, that means there's no known way to make the
+# CPU models identical. If the special property name "type" is included, the
+# models are by definition not identical and cannot be made identical.
+#
+# Since: 2.8.0
+##
+{ 'struct': 'CpuModelCompareInfo',
+ 'data': {'result': 'CpuModelCompareResult',
+ 'responsible-properties': ['str']
+ }
+}
+
+##
+# @query-cpu-model-comparison:
+#
+# Compares two CPU models, returning how they compare in a specific
+# configuration. The results indicates how both models compare regarding
+# runnability. This result can be used by tooling to make decisions if a
+# certain CPU model will run in a certain configuration or if a compatible
+# CPU model has to be created by baselining.
+#
+# Usually, a CPU model is compared against the maximum possible CPU model
+# 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.
+# (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 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
+# an unknown cpu definition name, unknown properties or properties
+# with wrong types.
+#
+# Since: 2.8.0
+##
+{ 'command': 'query-cpu-model-comparison',
+ '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.
#
# Since 1.6
##
-
{ 'struct': 'RxFilterInfo',
'data': {
'name': 'str',
#
# Since: 2.1
##
-
{ 'struct': 'Memdev',
'data': {
'size': 'size',
## @ACPISlotType
#
# @DIMM: memory slot
+# @CPU: logical CPU slot (since 2.7)
#
-{ 'enum': 'ACPISlotType', 'data': [ 'DIMM' ] }
+{ 'enum': 'ACPISlotType', 'data': [ 'DIMM', 'CPU' ] }
## @ACPIOSTInfo
#
#
# @pause: system pauses
#
-# Since: 2.1
+# Since: 2.1 (poweroff since 2.8)
##
{ 'enum': 'GuestPanicAction',
- 'data': [ 'pause' ] }
+ 'data': [ 'pause', 'poweroff' ] }
##
# @rtc-reset-reinjection
# Note: currently there are 4 properties that could be present
# but management should be prepared to pass through other
# properties with device_add command to allow for future
-# interface extension.
+# interface extension. This also requires the filed names to be kept in
+# sync with the properties passed to -device/device_add.
#
-# @node: #optional NUMA node ID the CPU belongs to
-# @socket: #optional socket number within node/board the CPU belongs to
-# @core: #optional core number within socket the CPU belongs to
-# @thread: #optional thread number within core the CPU belongs to
+# @node-id: #optional NUMA node ID the CPU belongs to
+# @socket-id: #optional socket number within node/board the CPU belongs to
+# @core-id: #optional core number within socket the CPU belongs to
+# @thread-id: #optional thread number within core the CPU belongs to
#
# Since: 2.7
##
{ 'struct': 'CpuInstanceProperties',
- 'data': { '*node': 'int',
- '*socket': 'int',
- '*core': 'int',
- '*thread': 'int'
+ 'data': { '*node-id': 'int',
+ '*socket-id': 'int',
+ '*core-id': 'int',
+ '*thread-id': 'int'
}
}
projects / mirror_qemu.git / blobdiff