X-Git-Url: https://repo.jachan.dev/qemu.git/blobdiff_plain/d6550e9ed2e1a60d889dfb721de00d9a4e3bafbe..458f3b2c953bdc7110896cb3691251023652523f:/qapi-schema.json diff --git a/qapi-schema.json b/qapi-schema.json index 8483bdfcce..d6a43a108c 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -20,6 +20,27 @@ # 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: # @@ -382,13 +403,17 @@ # # @dirty-sync-count: number of times that dirty ram was synchronized (since 2.1) # +# @postcopy-requests: The number of page requests received from the destination +# (since 2.7) +# # Since: 0.14.0 ## { 'struct': 'MigrationStats', 'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' , 'duplicate': 'int', 'skipped': 'int', 'normal': 'int', 'normal-bytes': 'int', 'dirty-pages-rate' : 'int', - 'mbps' : 'number', 'dirty-sync-count' : 'int' } } + 'mbps' : 'number', 'dirty-sync-count' : 'int', + 'postcopy-requests' : 'int' } } ## # @XBZRLECacheStats @@ -486,7 +511,7 @@ # # @error-desc: #optional the human readable error description string, when # @status is 'failed'. Clients should not attempt to parse the -# error strings. (Since 2.6) +# error strings. (Since 2.7) # # Since: 0.14.0 ## @@ -631,102 +656,88 @@ # 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 canbe validated. (Since 2.7) +# 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) # # 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'] } # # @migrate-set-parameters # -# Set the following migration parameters +# Set various migration parameters. See MigrationParameters for details. +# +# Since: 2.4 +## +{ 'command': 'migrate-set-parameters', 'boxed': true, + 'data': 'MigrationParameters' } + # -# @compress-level: compression level +# @MigrationParameters # -# @compress-threads: compression thread count +# 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. # -# @decompress-threads: decompression thread count +# @compress-level: #optional compression level # -# @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) +# @compress-threads: #optional compression thread count # -# @cpu-throttle-increment: throttle percentage increase each time +# @decompress-threads: #optional decompression thread count +# +# @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 canbe validated. (Since 2.7) +# 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) # # Since: 2.4 ## -{ 'command': 'migrate-set-parameters', +{ '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'} } + '*tls-hostname': 'str', + '*max-bandwidth': 'int', + '*downtime-limit': 'int'} } -# -# @MigrationParameters -# -# @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.6) -# -# @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 canbe validated. (Since 2.6) -# -# 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'} } ## # @query-migrate-parameters # @@ -1808,6 +1819,8 @@ # # 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'} } @@ -1821,7 +1834,7 @@ # # 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 ## @@ -2175,6 +2188,46 @@ ## { '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: # @@ -2571,6 +2624,8 @@ # # @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. @@ -2588,6 +2643,9 @@ # # @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', @@ -2597,6 +2655,7 @@ '*fds': 'str', '*script': 'str', '*downscript': 'str', + '*br': 'str', '*helper': 'str', '*sndbuf': 'size', '*vnet_hdr': 'bool', @@ -2604,7 +2663,8 @@ '*vhostfd': 'str', '*vhostfds': 'str', '*vhostforce': 'bool', - '*queues': 'uint32'} } + '*queues': 'uint32', + '*poll-us': 'uint32'} } ## # @NetdevSocketOptions @@ -2801,16 +2861,32 @@ '*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 # -# A discriminated record of network device traits. +# Captures the configuration of a network device. +# +# @id: identifier for monitor commands. +# +# @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', @@ -2845,23 +2921,28 @@ '*vlan': 'int32', '*id': 'str', '*name': 'str', - 'opts': 'NetClientOptions' } } + 'opts': 'NetLegacyOptions' } } ## -# @Netdev -# -# Captures the configuration of a network device. -# -# @id: identifier for monitor commands. +# @NetLegacyOptions # -# @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 @@ -2982,11 +3063,14 @@ # @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: @@ -3006,10 +3090,43 @@ # # @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: @@ -3022,6 +3139,238 @@ ## { '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. @@ -3778,7 +4127,6 @@ # # Since 1.6 ## - { 'struct': 'RxFilterInfo', 'data': { 'name': 'str', @@ -3998,7 +4346,6 @@ # # Since: 2.1 ## - { 'struct': 'Memdev', 'data': { 'size': 'size', @@ -4075,8 +4422,9 @@ ## @ACPISlotType # # @DIMM: memory slot +# @CPU: logical CPU slot (since 2.7) # -{ 'enum': 'ACPISlotType', 'data': [ 'DIMM' ] } +{ 'enum': 'ACPISlotType', 'data': [ 'DIMM', 'CPU' ] } ## @ACPIOSTInfo # @@ -4200,6 +4548,20 @@ { 'enum': 'ReplayMode', 'data': [ 'none', 'record', 'play' ] } +## +# @xen-load-devices-state: +# +# Load the state of all devices from file. The RAM and the block devices +# of the VM are not loaded by this command. +# +# @filename: the file to load the state of the devices from as binary +# data. See xen-save-devices-state.txt for a description of the binary +# format. +# +# Since: 2.7 +## +{ 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} } + ## # @GICCapability: # @@ -4235,3 +4597,59 @@ # Since: 2.6 ## { 'command': 'query-gic-capabilities', 'returns': ['GICCapability'] } + +## +# CpuInstanceProperties +# +# List of properties to be used for hotplugging a CPU instance, +# it should be passed by management with device_add command when +# a CPU is being hotplugged. +# +# 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. This also requires the filed names to be kept in +# sync with the properties passed to -device/device_add. +# +# @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-id': 'int', + '*socket-id': 'int', + '*core-id': 'int', + '*thread-id': 'int' + } +} + +## +# @HotpluggableCPU +# +# @type: CPU object type for usage with device_add command +# @props: list of properties to be used for hotplugging CPU +# @vcpus-count: number of logical VCPU threads @HotpluggableCPU provides +# @qom-path: #optional link to existing CPU object if CPU is present or +# omitted if CPU is not present. +# +# Since: 2.7 +## +{ 'struct': 'HotpluggableCPU', + 'data': { 'type': 'str', + 'vcpus-count': 'int', + 'props': 'CpuInstanceProperties', + '*qom-path': 'str' + } +} + +## +# @query-hotpluggable-cpus +# +# Returns: a list of HotpluggableCPU objects. +# +# Since: 2.7 +## +{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }