qemu/qapi-schema.json

6029 lines
158 KiB
JSON
Raw Normal View History

# -*- Mode: 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/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)
#
##
# QAPI common definitions
{ 'include': 'qapi/common.json' }
# QAPI crypto definitions
{ 'include': 'qapi/crypto.json' }
# QAPI block definitions
{ 'include': 'qapi/block.json' }
# QAPI event definitions
{ 'include': 'qapi/event.json' }
# Tracing commands
{ 'include': 'qapi/trace.json' }
qapi: New QMP command query-qmp-schema for QMP introspection qapi/introspect.json defines the introspection schema. It's designed for QMP introspection, but should do for similar uses, such as QGA. The introspection schema does not reflect all the rules and restrictions that apply to QAPI schemata. A valid QAPI schema has an introspection value conforming to the introspection schema, but the converse is not true. Introspection lowers away a number of schema details, and makes implicit things explicit: * The built-in types are declared with their JSON type. All integer types are mapped to 'int', because how many bits we use internally is an implementation detail. It could be pressed into external interface service as very approximate range information, but that's a bad idea. If we need range information, we better do it properly. * Implicit type definitions are made explicit, and given auto-generated names: - Array types, named by appending "List" to the name of their element type, like in generated C. - The enumeration types implicitly defined by simple union types, named by appending "Kind" to the name of their simple union type, like in generated C. - Types that don't occur in generated C. Their names start with ':' so they don't clash with the user's names. * All type references are by name. * The struct and union types are generalized into an object type. * Base types are flattened. * Commands take a single argument and return a single result. Dictionary argument or list result is an implicit type definition. The empty object type is used when a command takes no arguments or produces no results. The argument is always of object type, but the introspection schema doesn't reflect that. The 'gen': false directive is omitted as implementation detail. The 'success-response' directive is omitted as well for now, even though it's not an implementation detail, because it's not used by QMP. * Events carry a single data value. Implicit type definition and empty object type use, just like for commands. The value is of object type, but the introspection schema doesn't reflect that. * Types not used by commands or events are omitted. Indirect use counts as use. * Optional members have a default, which can only be null right now Instead of a mandatory "optional" flag, we have an optional default. No default means mandatory, default null means optional without default value. Non-null is available for optional with default (possible future extension). * Clients should *not* look up types by name, because type names are not ABI. Look up the command or event you're interested in, then follow the references. TODO Should we hide the type names to eliminate the temptation? New generator scripts/qapi-introspect.py computes an introspection value for its input, and generates a C variable holding it. It can generate awfully long lines. Marked TODO. A new test-qmp-input-visitor test case feeds its result for both tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a QmpInputVisitor to verify it actually conforms to the schema. New QMP command query-qmp-schema takes its return value from that variable. Its reply is some 85KiBytes for me right now. If this turns out to be too much, we have a couple of options: * We can use shorter names in the JSON. Not the QMP style. * Optionally return the sub-schema for commands and events given as arguments. Right now qmp_query_schema() sends the string literal computed by qmp-introspect.py. To compute sub-schema at run time, we'd have to duplicate parts of qapi-introspect.py in C. Unattractive. * Let clients cache the output of query-qmp-schema. It changes only on QEMU upgrades, i.e. rarely. Provide a command query-qmp-schema-hash. Clients can have a cache indexed by hash, and re-query the schema only when they don't have it cached. Even simpler: put the hash in the QMP greeting. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2015-09-16 14:06:28 +03:00
# QAPI introspection
{ 'include': 'qapi/introspect.json' }
##
# = QMP commands
##
##
# @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:
#
# Policy for handling lost ticks in timer devices.
#
# @discard: throw away the missed tick(s) and continue with future injection
# normally. Guest time may be delayed, unless the OS has explicit
# handling of lost ticks
#
# @delay: continue to deliver ticks at the normal rate. Guest time will be
# delayed due to the late tick
#
# @merge: merge the missed tick(s) into one tick and inject. Guest time
# may be delayed, depending on how the OS reacts to the merging
# of ticks
#
# @slew: deliver ticks at a higher rate to catch up with the missed tick. The
# guest time should not be delayed once catchup is complete.
#
# Since: 2.0
##
{ 'enum': 'LostTickPolicy',
'data': ['discard', 'delay', 'merge', 'slew' ] }
##
# @add_client:
#
# Allow client connections for VNC, Spice and socket based
# character devices to be passed in to QEMU via SCM_RIGHTS.
#
# @protocol: protocol name. Valid names are "vnc", "spice" or the
# name of a character device (eg. from -chardev id=XXXX)
#
# @fdname: file descriptor name previously passed via 'getfd' command
#
# @skipauth: #optional whether to skip authentication. Only applies
# to "vnc" and "spice" protocols
#
# @tls: #optional whether to perform TLS. Only applies to the "spice"
# protocol
#
# Returns: nothing on success.
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "add_client", "arguments": { "protocol": "vnc",
# "fdname": "myclient" } }
# <- { "return": {} }
#
##
{ 'command': 'add_client',
'data': { 'protocol': 'str', 'fdname': 'str', '*skipauth': 'bool',
'*tls': 'bool' } }
##
# @NameInfo:
#
# Guest name information.
#
# @name: #optional The name of the guest
#
# Since: 0.14.0
##
{ 'struct': 'NameInfo', 'data': {'*name': 'str'} }
##
# @query-name:
#
# Return the name information of a guest.
#
# Returns: @NameInfo of the guest
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-name" }
# <- { "return": { "name": "qemu-name" } }
#
##
{ 'command': 'query-name', 'returns': 'NameInfo' }
##
# @KvmInfo:
#
# Information about support for KVM acceleration
#
# @enabled: true if KVM acceleration is active
#
# @present: true if KVM acceleration is built into this executable
#
# Since: 0.14.0
##
{ 'struct': 'KvmInfo', 'data': {'enabled': 'bool', 'present': 'bool'} }
##
# @query-kvm:
#
# Returns information about KVM acceleration
#
# Returns: @KvmInfo
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-kvm" }
# <- { "return": { "enabled": true, "present": true } }
#
##
{ 'command': 'query-kvm', 'returns': 'KvmInfo' }
##
# @RunState:
#
# An enumeration of VM run states.
#
# @debug: QEMU is running on a debugger
#
# @finish-migrate: guest is paused to finish the migration process
#
# @inmigrate: guest is paused waiting for an incoming migration. Note
# that this state does not tell whether the machine will start at the
# end of the migration. This depends on the command-line -S option and
# any invocation of 'stop' or 'cont' that has happened since QEMU was
# started.
#
# @internal-error: An internal error that prevents further guest execution
# has occurred
#
# @io-error: the last IOP has failed and the device is configured to pause
# on I/O errors
#
# @paused: guest has been paused via the 'stop' command
#
# @postmigrate: guest is paused following a successful 'migrate'
#
# @prelaunch: QEMU was started with -S and guest has not started
#
# @restore-vm: guest is paused to restore VM state
#
# @running: guest is actively running
#
# @save-vm: guest is paused to save the VM state
#
# @shutdown: guest is shut down (and -no-shutdown is in use)
#
# @suspended: guest is suspended (ACPI S3)
#
# @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', 'colo' ] }
##
# @StatusInfo:
#
# Information about VCPU run state
#
# @running: true if all VCPUs are runnable, false if not runnable
#
# @singlestep: true if VCPUs are in single-step mode
#
# @status: the virtual machine @RunState
#
# Since: 0.14.0
#
# Notes: @singlestep is enabled through the GDB stub
##
{ 'struct': 'StatusInfo',
'data': {'running': 'bool', 'singlestep': 'bool', 'status': 'RunState'} }
##
# @query-status:
#
# Query the run status of all VCPUs
#
# Returns: @StatusInfo reflecting all VCPUs
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-status" }
# <- { "return": { "running": true,
# "singlestep": false,
# "status": "running" } }
#
##
{ 'command': 'query-status', 'returns': 'StatusInfo' }
##
# @UuidInfo:
#
# Guest UUID information (Universally Unique Identifier).
#
# @UUID: the UUID of the guest
#
# Since: 0.14.0
#
# Notes: If no UUID was specified for the guest, a null UUID is returned.
##
{ 'struct': 'UuidInfo', 'data': {'UUID': 'str'} }
##
# @query-uuid:
#
# Query the guest UUID information.
#
# Returns: The @UuidInfo for the guest
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-uuid" }
# <- { "return": { "UUID": "550e8400-e29b-41d4-a716-446655440000" } }
#
##
{ 'command': 'query-uuid', 'returns': 'UuidInfo' }
##
# @ChardevInfo:
#
# Information about a character device.
#
# @label: the label of the character device
#
# @filename: the filename of the character device
#
# @frontend-open: shows whether the frontend device attached to this backend
# (eg. with the chardev=... option) is in open or closed state
# (since 2.1)
#
# Notes: @filename is encoded using the QEMU command line character device
# encoding. See the QEMU man page for details.
#
# Since: 0.14.0
##
{ 'struct': 'ChardevInfo', 'data': {'label': 'str',
'filename': 'str',
'frontend-open': 'bool'} }
##
# @query-chardev:
#
# Returns information about current character devices.
#
# Returns: a list of @ChardevInfo
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-chardev" }
# <- {
# "return": [
# {
# "label": "charchannel0",
# "filename": "unix:/var/lib/libvirt/qemu/seabios.rhel6.agent,server",
# "frontend-open": false
# },
# {
# "label": "charmonitor",
# "filename": "unix:/var/lib/libvirt/qemu/seabios.rhel6.monitor,server",
# "frontend-open": true
# },
# {
# "label": "charserial0",
# "filename": "pty:/dev/pts/2",
# "frontend-open": true
# }
# ]
# }
#
##
{ 'command': 'query-chardev', 'returns': ['ChardevInfo'] }
##
# @ChardevBackendInfo:
#
# Information about a character device backend
#
# @name: The backend name
#
# Since: 2.0
##
{ 'struct': 'ChardevBackendInfo', 'data': {'name': 'str'} }
##
# @query-chardev-backends:
#
# Returns information about character device backends.
#
# Returns: a list of @ChardevBackendInfo
#
# Since: 2.0
#
# Example:
#
# -> { "execute": "query-chardev-backends" }
# <- {
# "return":[
# {
# "name":"udp"
# },
# {
# "name":"tcp"
# },
# {
# "name":"unix"
# },
# {
# "name":"spiceport"
# }
# ]
# }
#
##
{ 'command': 'query-chardev-backends', 'returns': ['ChardevBackendInfo'] }
##
# @DataFormat:
#
# An enumeration of data format.
#
# @utf8: Data is a UTF-8 string (RFC 3629)
#
# @base64: Data is Base64 encoded binary (RFC 3548)
#
# Since: 1.4
##
{ 'enum': 'DataFormat',
'data': [ 'utf8', 'base64' ] }
##
# @ringbuf-write:
#
# Write to a ring buffer character device.
#
# @device: the ring buffer character device name
#
# @data: data to write
#
# @format: #optional data encoding (default 'utf8').
# - base64: data must be base64 encoded text. Its binary
# decoding gets written.
# - utf8: data's UTF-8 encoding is written
# - data itself is always Unicode regardless of format, like
# any other string.
#
# Returns: Nothing on success
#
# Since: 1.4
#
# Example:
#
# -> { "execute": "ringbuf-write",
# "arguments": { "device": "foo",
# "data": "abcdefgh",
# "format": "utf8" } }
# <- { "return": {} }
#
##
{ 'command': 'ringbuf-write',
'data': {'device': 'str', 'data': 'str',
'*format': 'DataFormat'} }
##
# @ringbuf-read:
#
# Read from a ring buffer character device.
#
# @device: the ring buffer character device name
#
# @size: how many bytes to read at most
#
# @format: #optional data encoding (default 'utf8').
# - base64: the data read is returned in base64 encoding.
# - utf8: the data read is interpreted as UTF-8.
# Bug: can screw up when the buffer contains invalid UTF-8
# sequences, NUL characters, after the ring buffer lost
# data, and when reading stops because the size limit is
# reached.
# - The return value is always Unicode regardless of format,
# like any other string.
#
# Returns: data read from the device
#
# Since: 1.4
#
# Example:
#
# -> { "execute": "ringbuf-read",
# "arguments": { "device": "foo",
# "size": 1000,
# "format": "utf8" } }
# <- { "return": "abcdefgh" }
#
##
{ 'command': 'ringbuf-read',
'data': {'device': 'str', 'size': 'int', '*format': 'DataFormat'},
'returns': 'str' }
##
# @EventInfo:
#
# Information about a QMP event
#
# @name: The event name
#
# Since: 1.2.0
##
{ 'struct': 'EventInfo', 'data': {'name': 'str'} }
##
# @query-events:
#
# Return a list of supported QMP events by this server
#
# Returns: A list of @EventInfo for all supported events
#
# Since: 1.2.0
#
# Example:
#
# -> { "execute": "query-events" }
# <- {
# "return": [
# {
# "name":"SHUTDOWN"
# },
# {
# "name":"RESET"
# }
# ]
# }
#
# Note: This example has been shortened as the real response is too long.
#
##
{ 'command': 'query-events', 'returns': ['EventInfo'] }
##
# @MigrationStats:
#
# Detailed migration status.
#
# @transferred: amount of bytes already transferred to the target VM
#
# @remaining: amount of bytes remaining to be transferred to the target VM
#
# @total: total amount of bytes involved in the migration process
#
# @duplicate: number of duplicate (zero) pages (since 1.2)
#
# @skipped: number of skipped zero pages (since 1.5)
#
# @normal: number of normal pages (since 1.2)
#
# @normal-bytes: number of normal bytes sent (since 1.2)
#
# @dirty-pages-rate: number of pages dirtied by second by the
# guest (since 1.3)
#
# @mbps: throughput in megabits/sec. (since 1.6)
#
# @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',
'postcopy-requests' : 'int' } }
##
# @XBZRLECacheStats:
#
# Detailed XBZRLE migration cache statistics
#
# @cache-size: XBZRLE cache size
#
# @bytes: amount of bytes already transferred to the target VM
#
# @pages: amount of pages transferred to the target VM
#
# @cache-miss: number of cache miss
#
# @cache-miss-rate: rate of cache miss (since 2.1)
#
# @overflow: number of overflows
#
# Since: 1.2
##
{ 'struct': 'XBZRLECacheStats',
'data': {'cache-size': 'int', 'bytes': 'int', 'pages': 'int',
'cache-miss': 'int', 'cache-miss-rate': 'number',
'overflow': 'int' } }
##
# @MigrationStatus:
#
# An enumeration of migration status.
#
# @none: no migration has ever happened.
#
# @setup: migration process has been initiated.
#
# @cancelling: in the process of cancelling migration.
#
# @cancelled: cancelling migration is finished.
#
# @active: in the process of doing migration.
#
# @postcopy-active: like active, but now in postcopy mode. (since 2.5)
#
# @completed: migration is finished.
#
# @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', 'colo' ] }
##
# @MigrationInfo:
#
# Information about current migration process.
#
# @status: #optional @MigrationStatus describing the current migration status.
# If this field is not returned, no migration process
# has been initiated
#
# @ram: #optional @MigrationStats containing detailed migration
# status, only returned if status is 'active' or
# 'completed'(since 1.2)
#
# @disk: #optional @MigrationStats containing detailed disk migration
# status, only returned if status is 'active' and it is a block
# migration
#
# @xbzrle-cache: #optional @XBZRLECacheStats containing detailed XBZRLE
# migration statistics, only returned if XBZRLE feature is on and
# status is 'active' or 'completed' (since 1.2)
#
# @total-time: #optional total amount of milliseconds since migration started.
# If migration has ended, it returns the total migration
# time. (since 1.2)
#
# @downtime: #optional only present when migration finishes correctly
# total downtime in milliseconds for the guest.
# (since 1.3)
#
# @expected-downtime: #optional only present while migration is active
# expected downtime in milliseconds for the guest in last walk
# of the dirty bitmap. (since 1.3)
#
# @setup-time: #optional amount of setup time in milliseconds _before_ the
# iterations begin but _after_ the QMP command is issued. This is designed
# to provide an accounting of any activities (such as RDMA pinning) which
# may be expensive, but do not actually occur during the iterative
# migration rounds themselves. (since 1.6)
#
# @cpu-throttle-percentage: #optional percentage of time guest cpus are being
# throttled during auto-converge. This is only present when auto-converge
# has started throttling guest cpus. (Since 2.7)
#
migration: add reporting of errors for outgoing migration Currently if an application initiates an outgoing migration, it may or may not, get an error reported back on failure. If the error occurs synchronously to the 'migrate' command execution, the client app will see the error message. This is the case for DNS lookup failures. If the error occurs asynchronously to the monitor command though, the error will be thrown away and the client left guessing about what went wrong. This is the case for failure to connect to the TCP server (eg due to wrong port, or firewall rules, or other similar errors). In the future we'll be adding more scope for errors to happen asynchronously with the TLS protocol handshake. TLS errors are hard to diagnose even when they are well reported, so discarding errors entirely will make it impossible to debug TLS connection problems. Management apps which do migration are already using 'query-migrate' / 'info migrate' to check up on progress of background migration operations and to see their end status. This is a fine place to also include the error message when things go wrong. This patch thus adds an 'error-desc' field to the MigrationInfo struct, which will be populated when the 'status' is set to 'failed': (qemu) migrate -d tcp:localhost:9001 (qemu) info migrate capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off x-postcopy-ram: off Migration status: failed (Error connecting to socket: Connection refused) total time: 0 milliseconds In the HMP, when doing non-detached migration, it is also possible to display this error message directly to the app. (qemu) migrate tcp:localhost:9001 Error connecting to socket: Connection refused Or with QMP { "execute": "query-migrate", "arguments": {} } { "return": { "status": "failed", "error-desc": "address resolution failed for myhost:9000: No address associated with hostname" } } Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <1461751518-12128-11-git-send-email-berrange@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-04-27 13:05:00 +03:00
# @error-desc: #optional the human readable error description string, when
# @status is 'failed'. Clients should not attempt to parse the
# error strings. (Since 2.7)
migration: add reporting of errors for outgoing migration Currently if an application initiates an outgoing migration, it may or may not, get an error reported back on failure. If the error occurs synchronously to the 'migrate' command execution, the client app will see the error message. This is the case for DNS lookup failures. If the error occurs asynchronously to the monitor command though, the error will be thrown away and the client left guessing about what went wrong. This is the case for failure to connect to the TCP server (eg due to wrong port, or firewall rules, or other similar errors). In the future we'll be adding more scope for errors to happen asynchronously with the TLS protocol handshake. TLS errors are hard to diagnose even when they are well reported, so discarding errors entirely will make it impossible to debug TLS connection problems. Management apps which do migration are already using 'query-migrate' / 'info migrate' to check up on progress of background migration operations and to see their end status. This is a fine place to also include the error message when things go wrong. This patch thus adds an 'error-desc' field to the MigrationInfo struct, which will be populated when the 'status' is set to 'failed': (qemu) migrate -d tcp:localhost:9001 (qemu) info migrate capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off x-postcopy-ram: off Migration status: failed (Error connecting to socket: Connection refused) total time: 0 milliseconds In the HMP, when doing non-detached migration, it is also possible to display this error message directly to the app. (qemu) migrate tcp:localhost:9001 Error connecting to socket: Connection refused Or with QMP { "execute": "query-migrate", "arguments": {} } { "return": { "status": "failed", "error-desc": "address resolution failed for myhost:9000: No address associated with hostname" } } Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <1461751518-12128-11-git-send-email-berrange@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-04-27 13:05:00 +03:00
#
# Since: 0.14.0
##
{ 'struct': 'MigrationInfo',
'data': {'*status': 'MigrationStatus', '*ram': 'MigrationStats',
'*disk': 'MigrationStats',
'*xbzrle-cache': 'XBZRLECacheStats',
'*total-time': 'int',
'*expected-downtime': 'int',
'*downtime': 'int',
'*setup-time': 'int',
migration: add reporting of errors for outgoing migration Currently if an application initiates an outgoing migration, it may or may not, get an error reported back on failure. If the error occurs synchronously to the 'migrate' command execution, the client app will see the error message. This is the case for DNS lookup failures. If the error occurs asynchronously to the monitor command though, the error will be thrown away and the client left guessing about what went wrong. This is the case for failure to connect to the TCP server (eg due to wrong port, or firewall rules, or other similar errors). In the future we'll be adding more scope for errors to happen asynchronously with the TLS protocol handshake. TLS errors are hard to diagnose even when they are well reported, so discarding errors entirely will make it impossible to debug TLS connection problems. Management apps which do migration are already using 'query-migrate' / 'info migrate' to check up on progress of background migration operations and to see their end status. This is a fine place to also include the error message when things go wrong. This patch thus adds an 'error-desc' field to the MigrationInfo struct, which will be populated when the 'status' is set to 'failed': (qemu) migrate -d tcp:localhost:9001 (qemu) info migrate capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off x-postcopy-ram: off Migration status: failed (Error connecting to socket: Connection refused) total time: 0 milliseconds In the HMP, when doing non-detached migration, it is also possible to display this error message directly to the app. (qemu) migrate tcp:localhost:9001 Error connecting to socket: Connection refused Or with QMP { "execute": "query-migrate", "arguments": {} } { "return": { "status": "failed", "error-desc": "address resolution failed for myhost:9000: No address associated with hostname" } } Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <1461751518-12128-11-git-send-email-berrange@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-04-27 13:05:00 +03:00
'*cpu-throttle-percentage': 'int',
'*error-desc': 'str'} }
##
# @query-migrate:
#
# Returns information about current migration process. If migration
# is active there will be another json-object with RAM migration
# status and if block migration is active another one with block
# migration status.
#
# Returns: @MigrationInfo
#
# Since: 0.14.0
#
# Example:
#
# 1. Before the first migration
#
# -> { "execute": "query-migrate" }
# <- { "return": {} }
#
# 2. Migration is done and has succeeded
#
# -> { "execute": "query-migrate" }
# <- { "return": {
# "status": "completed",
# "ram":{
# "transferred":123,
# "remaining":123,
# "total":246,
# "total-time":12345,
# "setup-time":12345,
# "downtime":12345,
# "duplicate":123,
# "normal":123,
# "normal-bytes":123456,
# "dirty-sync-count":15
# }
# }
# }
#
# 3. Migration is done and has failed
#
# -> { "execute": "query-migrate" }
# <- { "return": { "status": "failed" } }
#
# 4. Migration is being performed and is not a block migration:
#
# -> { "execute": "query-migrate" }
# <- {
# "return":{
# "status":"active",
# "ram":{
# "transferred":123,
# "remaining":123,
# "total":246,
# "total-time":12345,
# "setup-time":12345,
# "expected-downtime":12345,
# "duplicate":123,
# "normal":123,
# "normal-bytes":123456,
# "dirty-sync-count":15
# }
# }
# }
#
# 5. Migration is being performed and is a block migration:
#
# -> { "execute": "query-migrate" }
# <- {
# "return":{
# "status":"active",
# "ram":{
# "total":1057024,
# "remaining":1053304,
# "transferred":3720,
# "total-time":12345,
# "setup-time":12345,
# "expected-downtime":12345,
# "duplicate":123,
# "normal":123,
# "normal-bytes":123456,
# "dirty-sync-count":15
# },
# "disk":{
# "total":20971520,
# "remaining":20880384,
# "transferred":91136
# }
# }
# }
#
# 6. Migration is being performed and XBZRLE is active:
#
# -> { "execute": "query-migrate" }
# <- {
# "return":{
# "status":"active",
# "capabilities" : [ { "capability": "xbzrle", "state" : true } ],
# "ram":{
# "total":1057024,
# "remaining":1053304,
# "transferred":3720,
# "total-time":12345,
# "setup-time":12345,
# "expected-downtime":12345,
# "duplicate":10,
# "normal":3333,
# "normal-bytes":3412992,
# "dirty-sync-count":15
# },
# "xbzrle-cache":{
# "cache-size":67108864,
# "bytes":20971520,
# "pages":2444343,
# "cache-miss":2244,
# "cache-miss-rate":0.123,
# "overflow":34434
# }
# }
# }
#
##
{ 'command': 'query-migrate', 'returns': 'MigrationInfo' }
##
# @MigrationCapability:
#
# Migration capabilities enumeration
#
# @xbzrle: Migration supports xbzrle (Xor Based Zero Run Length Encoding).
# This feature allows us to minimize migration traffic for certain work
# loads, by sending compressed difference of the pages
#
# @rdma-pin-all: Controls whether or not the entire VM memory footprint is
# mlock()'d on demand or all at once. Refer to docs/rdma.txt for usage.
# Disabled by default. (since 2.0)
#
# @zero-blocks: During storage migration encode blocks of zeroes efficiently. This
# essentially saves 1MB of zeroes per block on the wire. Enabling requires
# source and target VM to support this feature. To enable it is sufficient
# to enable the capability on the source VM. The feature is disabled by
# default. (since 1.6)
#
# @compress: Use multiple compression threads to accelerate live migration.
# This feature can help to reduce the migration traffic, by sending
# compressed pages. Please note that if compress and xbzrle are both
# on, compress only takes effect in the ram bulk stage, after that,
# it will be disabled and only xbzrle takes effect, this can help to
# minimize migration traffic. The feature is disabled by default.
# (since 2.4 )
#
# @events: generate events for each migration state change
# (since 2.4 )
#
# @auto-converge: If enabled, QEMU will automatically throttle down the guest
# to speed up convergence of RAM migration. (since 1.6)
#
# @postcopy-ram: Start executing on the migration target before all of RAM has
# 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', 'x-colo'] }
##
# @MigrationCapabilityStatus:
#
# Migration capability information
#
# @capability: capability enum
#
# @state: capability state bool
#
# Since: 1.2
##
{ 'struct': 'MigrationCapabilityStatus',
'data': { 'capability' : 'MigrationCapability', 'state' : 'bool' } }
##
# @migrate-set-capabilities:
#
# Enable/Disable the following migration capabilities (like xbzrle)
#
# @capabilities: json array of capability modifications to make
#
# Since: 1.2
#
# Example:
#
# -> { "execute": "migrate-set-capabilities" , "arguments":
# { "capabilities": [ { "capability": "xbzrle", "state": true } ] } }
#
##
{ 'command': 'migrate-set-capabilities',
'data': { 'capabilities': ['MigrationCapabilityStatus'] } }
##
# @query-migrate-capabilities:
#
# Returns information about the current migration capabilities status
#
# Returns: @MigrationCapabilitiesStatus
#
# Since: 1.2
#
# Example:
#
# -> { "execute": "query-migrate-capabilities" }
# <- { "return": [
# {"state": false, "capability": "xbzrle"},
# {"state": false, "capability": "rdma-pin-all"},
# {"state": false, "capability": "auto-converge"},
# {"state": false, "capability": "zero-blocks"},
# {"state": false, "capability": "compress"},
# {"state": true, "capability": "events"},
# {"state": false, "capability": "postcopy-ram"},
# {"state": false, "capability": "x-colo"}
# ]}
#
##
{ 'command': 'query-migrate-capabilities', 'returns': ['MigrationCapabilityStatus']}
##
# @MigrationParameter:
#
# Migration parameters enumeration
#
# @compress-level: Set the compression level to be used in live migration,
# the compression level is an integer between 0 and 9, where 0 means
# no compression, 1 means the best compression speed, and 9 means best
# compression ratio which will consume more CPU.
#
# @compress-threads: Set compression thread count to be used in live migration,
# the compression thread count is an integer between 1 and 255.
#
# @decompress-threads: Set decompression thread count to be used in live
# migration, the decompression thread count is an integer between 1
# and 255. Usually, decompression is at least 4 times as fast as
# compression, so set the decompress-threads to the number about 1/4
# of compress-threads is adequate.
#
# @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)
#
# @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', 'max-bandwidth',
'downtime-limit', 'x-checkpoint-delay' ] }
##
# @migrate-set-parameters:
#
# Set various migration parameters. See MigrationParameters for details.
#
# Since: 2.4
#
# Example:
#
# -> { "execute": "migrate-set-parameters" ,
# "arguments": { "compress-level": 1 } }
#
##
{ 'command': 'migrate-set-parameters', 'boxed': true,
'data': 'MigrationParameters' }
##
# @MigrationParameters:
#
# 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-level: #optional compression level
#
# @compress-threads: #optional compression thread count
#
# @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: #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: #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',
'*max-bandwidth': 'int',
'*downtime-limit': 'int',
'*x-checkpoint-delay': 'int'} }
##
# @query-migrate-parameters:
#
# Returns information about the current migration parameters
#
# Returns: @MigrationParameters
#
# Since: 2.4
#
# Example:
#
# -> { "execute": "query-migrate-parameters" }
# <- { "return": {
# "decompress-threads": 2,
# "cpu-throttle-increment": 10,
# "compress-threads": 8,
# "compress-level": 1,
# "cpu-throttle-initial": 20,
# "max-bandwidth": 33554432,
# "downtime-limit": 300
# }
# }
#
##
{ 'command': 'query-migrate-parameters',
'returns': 'MigrationParameters' }
##
# @client_migrate_info:
#
# Set migration information for remote display. This makes the server
# ask the client to automatically reconnect using the new parameters
# once migration finished successfully. Only implemented for SPICE.
#
# @protocol: must be "spice"
# @hostname: migration target hostname
# @port: #optional spice tcp port for plaintext channels
# @tls-port: #optional spice tcp port for tls-secured channels
# @cert-subject: #optional server certificate subject
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "client_migrate_info",
# "arguments": { "protocol": "spice",
# "hostname": "virt42.lab.kraxel.org",
# "port": 1234 } }
# <- { "return": {} }
#
##
{ 'command': 'client_migrate_info',
'data': { 'protocol': 'str', 'hostname': 'str', '*port': 'int',
'*tls-port': 'int', '*cert-subject': 'str' } }
##
# @migrate-start-postcopy:
#
# Followup to a migration command to switch the migration to postcopy mode.
# The postcopy-ram capability must be set before the original migration
# command.
#
# Since: 2.5
#
# Example:
#
# -> { "execute": "migrate-start-postcopy" }
# <- { "return": {} }
#
##
{ 'command': 'migrate-start-postcopy' }
##
# @COLOMessage:
COLO: Introduce checkpointing protocol We need communications protocol of user-defined to control the checkpointing process. The new checkpointing request is started by Primary VM, and the interactive process like below: Checkpoint synchronizing points: Primary Secondary initial work 'checkpoint-ready' <-------------------- @ 'checkpoint-request' @ --------------------> Suspend (Only in hybrid mode) 'checkpoint-reply' <-------------------- @ Suspend&Save state 'vmstate-send' @ --------------------> Send state Receive state 'vmstate-received' <-------------------- @ Release packets Load state 'vmstate-load' <-------------------- @ Resume Resume (Only in hybrid mode) Start Comparing (Only in hybrid mode) NOTE: 1) '@' who sends the message 2) Every sync-point is synchronized by two sides with only one handshake(single direction) for low-latency. If more strict synchronization is required, a opposite direction sync-point should be added. 3) Since sync-points are single direction, the remote side may go forward a lot when this side just receives the sync-point. 4) For now, we only support 'periodic' checkpoint, for which the Secondary VM is not running, later we will support 'hybrid' mode. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-27 09:42:57 +03:00
#
# 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
#
# Example:
#
# -> { "execute": "x-colo-lost-heartbeat" }
# <- { "return": {} }
#
##
{ 'command': 'x-colo-lost-heartbeat' }
##
# @MouseInfo:
#
# Information about a mouse device.
#
# @name: the name of the mouse device
#
# @index: the index of the mouse device
#
# @current: true if this device is currently receiving mouse events
#
# @absolute: true if this device supports absolute coordinates as input
#
# Since: 0.14.0
##
{ 'struct': 'MouseInfo',
'data': {'name': 'str', 'index': 'int', 'current': 'bool',
'absolute': 'bool'} }
##
# @query-mice:
#
# Returns information about each active mouse device
#
# Returns: a list of @MouseInfo for each device
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-mice" }
# <- { "return": [
# {
# "name":"QEMU Microsoft Mouse",
# "index":0,
# "current":false,
# "absolute":false
# },
# {
# "name":"QEMU PS/2 Mouse",
# "index":1,
# "current":true,
# "absolute":true
# }
# ]
# }
#
##
{ 'command': 'query-mice', 'returns': ['MouseInfo'] }
##
# @CpuInfoArch:
#
# An enumeration of cpu types that enable additional information during
# @query-cpus.
#
# Since: 2.6
##
{ 'enum': 'CpuInfoArch',
'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 'other' ] }
##
# @CpuInfo:
#
# Information about a virtual CPU
#
# @CPU: the index of the virtual CPU
#
# @current: this only exists for backwards compatibility and should be ignored
#
# @halted: true if the virtual CPU is in the halt state. Halt usually refers
# to a processor specific low power mode.
#
# @qom_path: path to the CPU object in the QOM tree (since 2.4)
#
# @thread_id: ID of the underlying host thread
#
# @arch: architecture of the cpu, which determines which additional fields
# will be listed (since 2.6)
#
# Since: 0.14.0
#
# Notes: @halted is a transient state that changes frequently. By the time the
# data is sent to the client, the guest may no longer be halted.
##
{ 'union': 'CpuInfo',
'base': {'CPU': 'int', 'current': 'bool', 'halted': 'bool',
'qom_path': 'str', 'thread_id': 'int', 'arch': 'CpuInfoArch' },
'discriminator': 'arch',
'data': { 'x86': 'CpuInfoX86',
'sparc': 'CpuInfoSPARC',
'ppc': 'CpuInfoPPC',
'mips': 'CpuInfoMIPS',
'tricore': 'CpuInfoTricore',
'other': 'CpuInfoOther' } }
##
# @CpuInfoX86:
#
# Additional information about a virtual i386 or x86_64 CPU
#
# @pc: the 64-bit instruction pointer
#
# Since: 2.6
##
{ 'struct': 'CpuInfoX86', 'data': { 'pc': 'int' } }
##
# @CpuInfoSPARC:
#
# Additional information about a virtual SPARC CPU
#
# @pc: the PC component of the instruction pointer
#
# @npc: the NPC component of the instruction pointer
#
# Since: 2.6
##
{ 'struct': 'CpuInfoSPARC', 'data': { 'pc': 'int', 'npc': 'int' } }
##
# @CpuInfoPPC:
#
# Additional information about a virtual PPC CPU
#
# @nip: the instruction pointer
#
# Since: 2.6
##
{ 'struct': 'CpuInfoPPC', 'data': { 'nip': 'int' } }
##
# @CpuInfoMIPS:
#
# Additional information about a virtual MIPS CPU
#
# @PC: the instruction pointer
#
# Since: 2.6
##
{ 'struct': 'CpuInfoMIPS', 'data': { 'PC': 'int' } }
##
# @CpuInfoTricore:
#
# Additional information about a virtual Tricore CPU
#
# @PC: the instruction pointer
#
# Since: 2.6
##
{ 'struct': 'CpuInfoTricore', 'data': { 'PC': 'int' } }
##
# @CpuInfoOther:
#
# No additional information is available about the virtual CPU
#
# Since: 2.6
#
##
{ 'struct': 'CpuInfoOther', 'data': { } }
##
# @query-cpus:
#
# Returns a list of information about each virtual CPU.
#
# Returns: a list of @CpuInfo for each virtual CPU
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-cpus" }
# <- { "return": [
# {
# "CPU":0,
# "current":true,
# "halted":false,
# "qom_path":"/machine/unattached/device[0]",
# "arch":"x86",
# "pc":3227107138,
# "thread_id":3134
# },
# {
# "CPU":1,
# "current":false,
# "halted":true,
# "qom_path":"/machine/unattached/device[2]",
# "arch":"x86",
# "pc":7108165,
# "thread_id":3135
# }
# ]
# }
#
##
{ 'command': 'query-cpus', 'returns': ['CpuInfo'] }
##
# @IOThreadInfo:
#
# Information about an iothread
#
# @id: the identifier of the iothread
#
# @thread-id: ID of the underlying host thread
#
# Since: 2.0
##
{ 'struct': 'IOThreadInfo',
'data': {'id': 'str', 'thread-id': 'int'} }
##
# @query-iothreads:
#
# Returns a list of information about each iothread.
#
# Note: this list excludes the QEMU main loop thread, which is not declared
# using the -object iothread command-line option. It is always the main thread
# of the process.
#
# Returns: a list of @IOThreadInfo for each iothread
#
# Since: 2.0
#
# Example:
#
# -> { "execute": "query-iothreads" }
# <- { "return": [
# {
# "id":"iothread0",
# "thread-id":3134
# },
# {
# "id":"iothread1",
# "thread-id":3135
# }
# ]
# }
#
##
{ 'command': 'query-iothreads', 'returns': ['IOThreadInfo'] }
##
# @NetworkAddressFamily:
#
# The network address family
#
# @ipv4: IPV4 family
#
# @ipv6: IPV6 family
#
# @unix: unix socket
#
# @vsock: vsock family (since 2.8)
#
# @unknown: otherwise
#
# Since: 2.1
##
{ 'enum': 'NetworkAddressFamily',
'data': [ 'ipv4', 'ipv6', 'unix', 'vsock', 'unknown' ] }
##
# @VncBasicInfo:
#
# The basic information for vnc network connection
#
# @host: IP address
#
# @service: The service name of the vnc port. This may depend on the host
# system's service database so symbolic names should not be relied
# on.
#
# @family: address family
#
# @websocket: true in case the socket is a websocket (since 2.3).
#
# Since: 2.1
##
{ 'struct': 'VncBasicInfo',
'data': { 'host': 'str',
'service': 'str',
'family': 'NetworkAddressFamily',
'websocket': 'bool' } }
##
# @VncServerInfo:
#
# The network connection information for server
#
# @auth: #optional authentication method
#
# Since: 2.1
##
{ 'struct': 'VncServerInfo',
'base': 'VncBasicInfo',
'data': { '*auth': 'str' } }
##
# @VncClientInfo:
#
# Information about a connected VNC client.
#
# @x509_dname: #optional If x509 authentication is in use, the Distinguished
# Name of the client.
#
# @sasl_username: #optional If SASL authentication is in use, the SASL username
# used for authentication.
#
# Since: 0.14.0
##
{ 'struct': 'VncClientInfo',
'base': 'VncBasicInfo',
'data': { '*x509_dname': 'str', '*sasl_username': 'str' } }
##
# @VncInfo:
#
# Information about the VNC session.
#
# @enabled: true if the VNC server is enabled, false otherwise
#
# @host: #optional The hostname the VNC server is bound to. This depends on
# the name resolution on the host and may be an IP address.
#
# @family: #optional 'ipv6' if the host is listening for IPv6 connections
# 'ipv4' if the host is listening for IPv4 connections
# 'unix' if the host is listening on a unix domain socket
# 'unknown' otherwise
#
# @service: #optional The service name of the server's port. This may depends
# on the host system's service database so symbolic names should not
# be relied on.
#
# @auth: #optional the current authentication type used by the server
# 'none' if no authentication is being used
# 'vnc' if VNC authentication is being used
# 'vencrypt+plain' if VEncrypt is used with plain text authentication
# 'vencrypt+tls+none' if VEncrypt is used with TLS and no authentication
# 'vencrypt+tls+vnc' if VEncrypt is used with TLS and VNC authentication
# 'vencrypt+tls+plain' if VEncrypt is used with TLS and plain text auth
# 'vencrypt+x509+none' if VEncrypt is used with x509 and no auth
# 'vencrypt+x509+vnc' if VEncrypt is used with x509 and VNC auth
# 'vencrypt+x509+plain' if VEncrypt is used with x509 and plain text auth
# 'vencrypt+tls+sasl' if VEncrypt is used with TLS and SASL auth
# 'vencrypt+x509+sasl' if VEncrypt is used with x509 and SASL auth
#
# @clients: a list of @VncClientInfo of all currently connected clients
#
# Since: 0.14.0
##
{ 'struct': 'VncInfo',
'data': {'enabled': 'bool', '*host': 'str',
'*family': 'NetworkAddressFamily',
'*service': 'str', '*auth': 'str', '*clients': ['VncClientInfo']} }
##
# @VncPrimaryAuth:
#
# vnc primary authentication method.
#
# Since: 2.3
##
{ 'enum': 'VncPrimaryAuth',
'data': [ 'none', 'vnc', 'ra2', 'ra2ne', 'tight', 'ultra',
'tls', 'vencrypt', 'sasl' ] }
##
# @VncVencryptSubAuth:
#
# vnc sub authentication method with vencrypt.
#
# Since: 2.3
##
{ 'enum': 'VncVencryptSubAuth',
'data': [ 'plain',
'tls-none', 'x509-none',
'tls-vnc', 'x509-vnc',
'tls-plain', 'x509-plain',
'tls-sasl', 'x509-sasl' ] }
##
# @VncInfo2:
#
# Information about a vnc server
#
# @id: vnc server name.
#
# @server: A list of @VncBasincInfo describing all listening sockets.
# The list can be empty (in case the vnc server is disabled).
# It also may have multiple entries: normal + websocket,
# possibly also ipv4 + ipv6 in the future.
#
# @clients: A list of @VncClientInfo of all currently connected clients.
# The list can be empty, for obvious reasons.
#
# @auth: The current authentication type used by the server
#
# @vencrypt: #optional The vencrypt sub authentication type used by the server,
# only specified in case auth == vencrypt.
#
# @display: #optional The display device the vnc server is linked to.
#
# Since: 2.3
##
{ 'struct': 'VncInfo2',
'data': { 'id' : 'str',
'server' : ['VncBasicInfo'],
'clients' : ['VncClientInfo'],
'auth' : 'VncPrimaryAuth',
'*vencrypt' : 'VncVencryptSubAuth',
'*display' : 'str' } }
##
# @query-vnc:
#
# Returns information about the current VNC server
#
# Returns: @VncInfo
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-vnc" }
# <- { "return": {
# "enabled":true,
# "host":"0.0.0.0",
# "service":"50402",
# "auth":"vnc",
# "family":"ipv4",
# "clients":[
# {
# "host":"127.0.0.1",
# "service":"50401",
# "family":"ipv4"
# }
# ]
# }
# }
#
##
{ 'command': 'query-vnc', 'returns': 'VncInfo' }
##
# @query-vnc-servers:
#
# Returns a list of vnc servers. The list can be empty.
#
# Returns: a list of @VncInfo2
#
# Since: 2.3
##
{ 'command': 'query-vnc-servers', 'returns': ['VncInfo2'] }
##
# @SpiceBasicInfo:
#
# The basic information for SPICE network connection
#
# @host: IP address
#
# @port: port number
#
# @family: address family
#
# Since: 2.1
##
{ 'struct': 'SpiceBasicInfo',
'data': { 'host': 'str',
'port': 'str',
'family': 'NetworkAddressFamily' } }
##
# @SpiceServerInfo:
#
# Information about a SPICE server
#
# @auth: #optional authentication method
#
# Since: 2.1
##
{ 'struct': 'SpiceServerInfo',
'base': 'SpiceBasicInfo',
'data': { '*auth': 'str' } }
##
# @SpiceChannel:
#
# Information about a SPICE client channel.
#
# @connection-id: SPICE connection id number. All channels with the same id
# belong to the same SPICE session.
#
# @channel-type: SPICE channel type number. "1" is the main control
# channel, filter for this one if you want to track spice
# sessions only
#
# @channel-id: SPICE channel ID number. Usually "0", might be different when
# multiple channels of the same type exist, such as multiple
# display channels in a multihead setup
#
# @tls: true if the channel is encrypted, false otherwise.
#
# Since: 0.14.0
##
{ 'struct': 'SpiceChannel',
'base': 'SpiceBasicInfo',
'data': {'connection-id': 'int', 'channel-type': 'int', 'channel-id': 'int',
'tls': 'bool'} }
##
# @SpiceQueryMouseMode:
#
# An enumeration of Spice mouse states.
#
# @client: Mouse cursor position is determined by the client.
#
# @server: Mouse cursor position is determined by the server.
#
# @unknown: No information is available about mouse mode used by
# the spice server.
#
# Note: spice/enums.h has a SpiceMouseMode already, hence the name.
#
# Since: 1.1
##
{ 'enum': 'SpiceQueryMouseMode',
'data': [ 'client', 'server', 'unknown' ] }
##
# @SpiceInfo:
#
# Information about the SPICE session.
#
# @enabled: true if the SPICE server is enabled, false otherwise
#
# @migrated: true if the last guest migration completed and spice
# migration had completed as well. false otherwise. (since 1.4)
#
# @host: #optional The hostname the SPICE server is bound to. This depends on
# the name resolution on the host and may be an IP address.
#
# @port: #optional The SPICE server's port number.
#
# @compiled-version: #optional SPICE server version.
#
# @tls-port: #optional The SPICE server's TLS port number.
#
# @auth: #optional the current authentication type used by the server
# 'none' if no authentication is being used
# 'spice' uses SASL or direct TLS authentication, depending on command
# line options
#
# @mouse-mode: The mode in which the mouse cursor is displayed currently. Can
# be determined by the client or the server, or unknown if spice
# server doesn't provide this information. (since: 1.1)
#
# @channels: a list of @SpiceChannel for each active spice channel
#
# Since: 0.14.0
##
{ 'struct': 'SpiceInfo',
'data': {'enabled': 'bool', 'migrated': 'bool', '*host': 'str', '*port': 'int',
'*tls-port': 'int', '*auth': 'str', '*compiled-version': 'str',
'mouse-mode': 'SpiceQueryMouseMode', '*channels': ['SpiceChannel']} }
##
# @query-spice:
#
# Returns information about the current SPICE server
#
# Returns: @SpiceInfo
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-spice" }
# <- { "return": {
# "enabled": true,
# "auth": "spice",
# "port": 5920,
# "tls-port": 5921,
# "host": "0.0.0.0",
# "channels": [
# {
# "port": "54924",
# "family": "ipv4",
# "channel-type": 1,
# "connection-id": 1804289383,
# "host": "127.0.0.1",
# "channel-id": 0,
# "tls": true
# },
# {
# "port": "36710",
# "family": "ipv4",
# "channel-type": 4,
# "connection-id": 1804289383,
# "host": "127.0.0.1",
# "channel-id": 0,
# "tls": false
# },
# [ ... more channels follow ... ]
# ]
# }
# }
#
##
{ 'command': 'query-spice', 'returns': 'SpiceInfo' }
##
# @BalloonInfo:
#
# Information about the guest balloon device.
#
# @actual: the number of bytes the balloon currently contains
#
# Since: 0.14.0
#
##
{ 'struct': 'BalloonInfo', 'data': {'actual': 'int' } }
##
# @query-balloon:
#
# Return information about the balloon device.
#
# Returns: @BalloonInfo on success
#
# If the balloon driver is enabled but not functional because the KVM
# kernel module cannot support it, KvmMissingCap
#
# If no balloon device is present, DeviceNotActive
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-balloon" }
# <- { "return": {
# "actual": 1073741824,
# }
# }
#
##
{ 'command': 'query-balloon', 'returns': 'BalloonInfo' }
##
# @PciMemoryRange:
#
# A PCI device memory region
#
# @base: the starting address (guest physical)
#
# @limit: the ending address (guest physical)
#
# Since: 0.14.0
##
{ 'struct': 'PciMemoryRange', 'data': {'base': 'int', 'limit': 'int'} }
##
# @PciMemoryRegion:
#
# Information about a PCI device I/O region.
#
# @bar: the index of the Base Address Register for this region
#
# @type: 'io' if the region is a PIO region
# 'memory' if the region is a MMIO region
#
# @size: memory size
#
# @prefetch: #optional if @type is 'memory', true if the memory is prefetchable
#
# @mem_type_64: #optional if @type is 'memory', true if the BAR is 64-bit
#
# Since: 0.14.0
##
{ 'struct': 'PciMemoryRegion',
'data': {'bar': 'int', 'type': 'str', 'address': 'int', 'size': 'int',
'*prefetch': 'bool', '*mem_type_64': 'bool' } }
##
# @PciBusInfo:
#
# Information about a bus of a PCI Bridge device
#
# @number: primary bus interface number. This should be the number of the
# bus the device resides on.
#
# @secondary: secondary bus interface number. This is the number of the
# main bus for the bridge
#
# @subordinate: This is the highest number bus that resides below the
# bridge.
#
# @io_range: The PIO range for all devices on this bridge
#
# @memory_range: The MMIO range for all devices on this bridge
#
# @prefetchable_range: The range of prefetchable MMIO for all devices on
# this bridge
#
# Since: 2.4
##
{ 'struct': 'PciBusInfo',
'data': {'number': 'int', 'secondary': 'int', 'subordinate': 'int',
'io_range': 'PciMemoryRange',
'memory_range': 'PciMemoryRange',
'prefetchable_range': 'PciMemoryRange' } }
##
# @PciBridgeInfo:
#
# Information about a PCI Bridge device
#
# @bus: information about the bus the device resides on
#
# @devices: a list of @PciDeviceInfo for each device on this bridge
#
# Since: 0.14.0
##
{ 'struct': 'PciBridgeInfo',
'data': {'bus': 'PciBusInfo', '*devices': ['PciDeviceInfo']} }
##
# @PciDeviceClass:
#
# Information about the Class of a PCI device
#
# @desc: #optional a string description of the device's class
#
# @class: the class code of the device
#
# Since: 2.4
##
{ 'struct': 'PciDeviceClass',
'data': {'*desc': 'str', 'class': 'int'} }
##
# @PciDeviceId:
#
# Information about the Id of a PCI device
#
# @device: the PCI device id
#
# @vendor: the PCI vendor id
#
# Since: 2.4
##
{ 'struct': 'PciDeviceId',
'data': {'device': 'int', 'vendor': 'int'} }
##
# @PciDeviceInfo:
#
# Information about a PCI device
#
# @bus: the bus number of the device
#
# @slot: the slot the device is located in
#
# @function: the function of the slot used by the device
#
# @class_info: the class of the device
#
# @id: the PCI device id
#
# @irq: #optional if an IRQ is assigned to the device, the IRQ number
#
# @qdev_id: the device name of the PCI device
#
# @pci_bridge: if the device is a PCI bridge, the bridge information
#
# @regions: a list of the PCI I/O regions associated with the device
#
# Notes: the contents of @class_info.desc are not stable and should only be
# treated as informational.
#
# Since: 0.14.0
##
{ 'struct': 'PciDeviceInfo',
'data': {'bus': 'int', 'slot': 'int', 'function': 'int',
'class_info': 'PciDeviceClass', 'id': 'PciDeviceId',
'*irq': 'int', 'qdev_id': 'str', '*pci_bridge': 'PciBridgeInfo',
'regions': ['PciMemoryRegion']} }
##
# @PciInfo:
#
# Information about a PCI bus
#
# @bus: the bus index
#
# @devices: a list of devices on this bus
#
# Since: 0.14.0
##
{ 'struct': 'PciInfo', 'data': {'bus': 'int', 'devices': ['PciDeviceInfo']} }
##
# @query-pci:
#
# Return information about the PCI bus topology of the guest.
#
# Returns: a list of @PciInfo for each PCI bus. Each bus is
# represented by a json-object, which has a key with a json-array of
# all PCI devices attached to it. Each device is represented by a
# json-object.
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "query-pci" }
# <- { "return": [
# {
# "bus": 0,
# "devices": [
# {
# "bus": 0,
# "qdev_id": "",
# "slot": 0,
# "class_info": {
# "class": 1536,
# "desc": "Host bridge"
# },
# "id": {
# "device": 32902,
# "vendor": 4663
# },
# "function": 0,
# "regions": [
# ]
# },
# {
# "bus": 0,
# "qdev_id": "",
# "slot": 1,
# "class_info": {
# "class": 1537,
# "desc": "ISA bridge"
# },
# "id": {
# "device": 32902,
# "vendor": 28672
# },
# "function": 0,
# "regions": [
# ]
# },
# {
# "bus": 0,
# "qdev_id": "",
# "slot": 1,
# "class_info": {
# "class": 257,
# "desc": "IDE controller"
# },
# "id": {
# "device": 32902,
# "vendor": 28688
# },
# "function": 1,
# "regions": [
# {
# "bar": 4,
# "size": 16,
# "address": 49152,
# "type": "io"
# }
# ]
# },
# {
# "bus": 0,
# "qdev_id": "",
# "slot": 2,
# "class_info": {
# "class": 768,
# "desc": "VGA controller"
# },
# "id": {
# "device": 4115,
# "vendor": 184
# },
# "function": 0,
# "regions": [
# {
# "prefetch": true,
# "mem_type_64": false,
# "bar": 0,
# "size": 33554432,
# "address": 4026531840,
# "type": "memory"
# },
# {
# "prefetch": false,
# "mem_type_64": false,
# "bar": 1,
# "size": 4096,
# "address": 4060086272,
# "type": "memory"
# },
# {
# "prefetch": false,
# "mem_type_64": false,
# "bar": 6,
# "size": 65536,
# "address": -1,
# "type": "memory"
# }
# ]
# },
# {
# "bus": 0,
# "qdev_id": "",
# "irq": 11,
# "slot": 4,
# "class_info": {
# "class": 1280,
# "desc": "RAM controller"
# },
# "id": {
# "device": 6900,
# "vendor": 4098
# },
# "function": 0,
# "regions": [
# {
# "bar": 0,
# "size": 32,
# "address": 49280,
# "type": "io"
# }
# ]
# }
# ]
# }
# ]
# }
#
# Note: This example has been shortened as the real response is too long.
#
##
{ 'command': 'query-pci', 'returns': ['PciInfo'] }
##
# @quit:
#
# This command will cause the QEMU process to exit gracefully. While every
# attempt is made to send the QMP response before terminating, this is not
# guaranteed. When using this interface, a premature EOF would not be
# unexpected.
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "quit" }
# <- { "return": {} }
##
{ 'command': 'quit' }
##
# @stop:
#
# Stop all guest VCPU execution.
#
# Since: 0.14.0
#
# Notes: This function will succeed even if the guest is already in the stopped
# state. In "inmigrate" state, it will ensure that the guest
# remains paused once migration finishes, as if the -S option was
# passed on the command line.
#
# Example:
#
# -> { "execute": "stop" }
# <- { "return": {} }
#
##
{ 'command': 'stop' }
##
# @system_reset:
#
# Performs a hard reset of a guest.
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "system_reset" }
# <- { "return": {} }
#
##
{ 'command': 'system_reset' }
##
# @system_powerdown:
#
# Requests that a guest perform a powerdown operation.
#
# Since: 0.14.0
#
# Notes: A guest may or may not respond to this command. This command
# returning does not indicate that a guest has accepted the request or
# that it has shut down. Many guests will respond to this command by
# prompting the user in some way.
# Example:
#
# -> { "execute": "system_powerdown" }
# <- { "return": {} }
#
##
{ 'command': 'system_powerdown' }
##
# @cpu:
#
# This command is a nop that is only provided for the purposes of compatibility.
#
# Since: 0.14.0
#
# Notes: Do not use this command.
##
{ 'command': 'cpu', 'data': {'index': 'int'} }
##
# @cpu-add:
#
# Adds CPU with specified ID
#
# @id: ID of CPU to be created, valid values [0..max_cpus)
#
# Returns: Nothing on success
#
# Since: 1.5
#
# Example:
#
# -> { "execute": "cpu-add", "arguments": { "id": 2 } }
# <- { "return": {} }
#
##
{ 'command': 'cpu-add', 'data': {'id': 'int'} }
##
# @memsave:
#
# Save a portion of guest memory to a file.
#
# @val: the virtual address of the guest to start from
#
# @size: the size of memory region to save
#
# @filename: the file to save the memory to as binary data
#
# @cpu-index: #optional the index of the virtual CPU to use for translating the
# virtual address (defaults to CPU 0)
#
# Returns: Nothing on success
#
# Since: 0.14.0
#
# Notes: Errors were not reliably returned until 1.1
#
# Example:
#
# -> { "execute": "memsave",
# "arguments": { "val": 10,
# "size": 100,
# "filename": "/tmp/virtual-mem-dump" } }
# <- { "return": {} }
#
##
{ 'command': 'memsave',
'data': {'val': 'int', 'size': 'int', 'filename': 'str', '*cpu-index': 'int'} }
##
# @pmemsave:
#
# Save a portion of guest physical memory to a file.
#
# @val: the physical address of the guest to start from
#
# @size: the size of memory region to save
#
# @filename: the file to save the memory to as binary data
#
# Returns: Nothing on success
#
# Since: 0.14.0
#
# Notes: Errors were not reliably returned until 1.1
#
# Example:
#
# -> { "execute": "pmemsave",
# "arguments": { "val": 10,
# "size": 100,
# "filename": "/tmp/physical-mem-dump" } }
# <- { "return": {} }
#
##
{ 'command': 'pmemsave',
'data': {'val': 'int', 'size': 'int', 'filename': 'str'} }
##
# @cont:
#
# Resume guest VCPU execution.
#
# Since: 0.14.0
#
# Returns: If successful, nothing
# If QEMU was started with an encrypted block device and a key has
# not yet been set, DeviceEncrypted.
#
# Notes: This command will succeed if the guest is currently running. It
# will also succeed if the guest is in the "inmigrate" state; in
# this case, the effect of the command is to make sure the guest
# starts once migration finishes, removing the effect of the -S
# command line option if it was passed.
#
# Example:
#
# -> { "execute": "cont" }
# <- { "return": {} }
#
##
{ 'command': 'cont' }
##
# @system_wakeup:
#
# Wakeup guest from suspend. Does nothing in case the guest isn't suspended.
#
# Since: 1.1
#
# Returns: nothing.
#
# Example:
#
# -> { "execute": "system_wakeup" }
# <- { "return": {} }
#
##
{ 'command': 'system_wakeup' }
##
# @inject-nmi:
#
# Injects a Non-Maskable Interrupt into the default CPU (x86/s390) or all CPUs (ppc64).
# The command fails when the guest doesn't support injecting.
#
# Returns: If successful, nothing
#
# Since: 0.14.0
#
# Note: prior to 2.1, this command was only supported for x86 and s390 VMs
#
# Example:
#
# -> { "execute": "inject-nmi" }
# <- { "return": {} }
#
##
{ 'command': 'inject-nmi' }
##
# @set_link:
#
# Sets the link status of a virtual network adapter.
#
# @name: the device name of the virtual network adapter
#
# @up: true to set the link status to be up
#
# Returns: Nothing on success
# If @name is not a valid network device, DeviceNotFound
#
# Since: 0.14.0
#
# Notes: Not all network adapters support setting link status. This command
# will succeed even if the network adapter does not support link status
# notification.
#
# Example:
#
# -> { "execute": "set_link",
# "arguments": { "name": "e1000.0", "up": false } }
# <- { "return": {} }
#
##
{ 'command': 'set_link', 'data': {'name': 'str', 'up': 'bool'} }
##
# @balloon:
#
# Request the balloon driver to change its balloon size.
#
# @value: the target size of the balloon in bytes
#
# Returns: Nothing on success
# If the balloon driver is enabled but not functional because the KVM
# kernel module cannot support it, KvmMissingCap
# If no balloon device is present, DeviceNotActive
#
# Notes: This command just issues a request to the guest. When it returns,
# the balloon size may not have changed. A guest can change the balloon
# size independent of this command.
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "balloon", "arguments": { "value": 536870912 } }
# <- { "return": {} }
#
##
{ 'command': 'balloon', 'data': {'value': 'int'} }
##
# @Abort:
#
# This action can be used to test transaction failure.
#
# Since: 1.6
##
{ 'struct': 'Abort',
'data': { } }
##
# @ActionCompletionMode:
#
# An enumeration of Transactional completion modes.
#
# @individual: Do not attempt to cancel any other Actions if any Actions fail
# after the Transaction request succeeds. All Actions that
# can complete successfully will do so without waiting on others.
# This is the default.
#
# @grouped: If any Action fails after the Transaction succeeds, cancel all
# Actions. Actions do not complete until all Actions are ready to
# complete. May be rejected by Actions that do not support this
# completion mode.
#
# Since: 2.5
##
{ 'enum': 'ActionCompletionMode',
'data': [ 'individual', 'grouped' ] }
##
# @TransactionAction:
#
# A discriminated record of operations that can be performed with
# @transaction. Action @type can be:
#
# - @abort: since 1.6
# - @block-dirty-bitmap-add: since 2.5
# - @block-dirty-bitmap-clear: since 2.5
# - @blockdev-backup: since 2.3
# - @blockdev-snapshot: since 2.5
# - @blockdev-snapshot-internal-sync: since 1.7
# - @blockdev-snapshot-sync: since 1.1
# - @drive-backup: since 1.6
#
# Since: 1.1
##
{ 'union': 'TransactionAction',
'data': {
'abort': 'Abort',
'block-dirty-bitmap-add': 'BlockDirtyBitmapAdd',
'block-dirty-bitmap-clear': 'BlockDirtyBitmap',
'blockdev-backup': 'BlockdevBackup',
'blockdev-snapshot': 'BlockdevSnapshot',
'blockdev-snapshot-internal-sync': 'BlockdevSnapshotInternal',
'blockdev-snapshot-sync': 'BlockdevSnapshotSync',
'drive-backup': 'DriveBackup'
} }
##
# @TransactionProperties:
#
# Optional arguments to modify the behavior of a Transaction.
#
# @completion-mode: #optional Controls how jobs launched asynchronously by
# Actions will complete or fail as a group.
# See @ActionCompletionMode for details.
#
# Since: 2.5
##
{ 'struct': 'TransactionProperties',
'data': {
'*completion-mode': 'ActionCompletionMode'
}
}
##
# @transaction:
#
# Executes a number of transactionable QMP commands atomically. If any
# operation fails, then the entire set of actions will be abandoned and the
# appropriate error returned.
#
# For external snapshots, the dictionary contains the device, the file to use for
# the new snapshot, and the format. The default format, if not specified, is
# qcow2.
#
# Each new snapshot defaults to being created by QEMU (wiping any
# contents if the file already exists), but it is also possible to reuse
# an externally-created file. In the latter case, you should ensure that
# the new image file has the same contents as the current one; QEMU cannot
# perform any meaningful check. Typically this is achieved by using the
# current image file as the backing file for the new image.
#
# On failure, the original disks pre-snapshot attempt will be used.
#
# For internal snapshots, the dictionary contains the device and the snapshot's
# name. If an internal snapshot matching name already exists, the request will
# be rejected. Only some image formats support it, for example, qcow2, rbd,
# and sheepdog.
#
# On failure, qemu will try delete the newly created internal snapshot in the
# transaction. When an I/O error occurs during deletion, the user needs to fix
# it later with qemu-img or other command.
#
# @actions: List of @TransactionAction;
# information needed for the respective operations.
#
# @properties: #optional structure of additional options to control the
# execution of the transaction. See @TransactionProperties
# for additional detail.
#
# Returns: nothing on success
#
# Errors depend on the operations of the transaction
#
# Note: The transaction aborts on the first failure. Therefore, there will be
# information on only one failed operation returned in an error condition, and
# subsequent actions will not have been attempted.
#
# Since: 1.1
#
# Example:
#
# -> { "execute": "transaction",
# "arguments": { "actions": [
# { "type": "blockdev-snapshot-sync", "data" : { "device": "ide-hd0",
# "snapshot-file": "/some/place/my-image",
# "format": "qcow2" } },
# { "type": "blockdev-snapshot-sync", "data" : { "node-name": "myfile",
# "snapshot-file": "/some/place/my-image2",
# "snapshot-node-name": "node3432",
# "mode": "existing",
# "format": "qcow2" } },
# { "type": "blockdev-snapshot-sync", "data" : { "device": "ide-hd1",
# "snapshot-file": "/some/place/my-image2",
# "mode": "existing",
# "format": "qcow2" } },
# { "type": "blockdev-snapshot-internal-sync", "data" : {
# "device": "ide-hd2",
# "name": "snapshot0" } } ] } }
# <- { "return": {} }
#
##
{ 'command': 'transaction',
'data': { 'actions': [ 'TransactionAction' ],
'*properties': 'TransactionProperties'
}
}
##
# @human-monitor-command:
#
# Execute a command on the human monitor and return the output.
#
# @command-line: the command to execute in the human monitor
#
# @cpu-index: #optional The CPU to use for commands that require an implicit CPU
#
# Returns: the output of the command as a string
#
# Since: 0.14.0
#
# Notes: This command only exists as a stop-gap. Its use is highly
# discouraged. The semantics of this command are not
# guaranteed: this means that command names, arguments and
# responses can change or be removed at ANY time. Applications
# that rely on long term stability guarantees should NOT
# use this command.
#
# Known limitations:
#
# * This command is stateless, this means that commands that depend
# on state information (such as getfd) might not work
#
# * Commands that prompt the user for data (eg. 'cont' when the block
# device is encrypted) don't currently work
#
# Example:
#
# -> { "execute": "human-monitor-command",
# "arguments": { "command-line": "info kvm" } }
# <- { "return": "kvm support: enabled\r\n" }
#
##
{ 'command': 'human-monitor-command',
'data': {'command-line': 'str', '*cpu-index': 'int'},
'returns': 'str' }
##
# @migrate_cancel:
#
# Cancel the current executing migration process.
#
# Returns: nothing on success
#
# Notes: This command succeeds even if there is no migration process running.
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "migrate_cancel" }
# <- { "return": {} }
#
##
{ 'command': 'migrate_cancel' }
##
# @migrate_set_downtime:
#
# Set maximum tolerated downtime for migration.
#
# @value: maximum downtime in seconds
#
# Returns: nothing on success
#
# Notes: This command is deprecated in favor of 'migrate-set-parameters'
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "migrate_set_downtime", "arguments": { "value": 0.1 } }
# <- { "return": {} }
#
##
{ 'command': 'migrate_set_downtime', 'data': {'value': 'number'} }
##
# @migrate_set_speed:
#
# Set maximum speed for migration.
#
# @value: maximum speed in bytes per second.
#
# Returns: nothing on success
#
# Notes: This command is deprecated in favor of 'migrate-set-parameters'
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "migrate_set_speed", "arguments": { "value": 1024 } }
# <- { "return": {} }
#
##
{ 'command': 'migrate_set_speed', 'data': {'value': 'int'} }
##
# @migrate-set-cache-size:
#
# Set cache size to be used by XBZRLE migration
#
# @value: cache size in bytes
#
# The size will be rounded down to the nearest power of 2.
# The cache size can be modified before and during ongoing migration
#
# Returns: nothing on success
#
# Since: 1.2
#
# Example:
#
# -> { "execute": "migrate-set-cache-size",
# "arguments": { "value": 536870912 } }
# <- { "return": {} }
#
##
{ 'command': 'migrate-set-cache-size', 'data': {'value': 'int'} }
##
# @query-migrate-cache-size:
#
# Query migration XBZRLE cache size
#
# Returns: XBZRLE cache size in bytes
#
# Since: 1.2
#
# Example:
#
# -> { "execute": "query-migrate-cache-size" }
# <- { "return": 67108864 }
#
##
{ 'command': 'query-migrate-cache-size', 'returns': 'int' }
##
# @ObjectPropertyInfo:
#
# @name: the name of the property
#
# @type: the type of the property. This will typically come in one of four
# forms:
#
# 1) A primitive type such as 'u8', 'u16', 'bool', 'str', or 'double'.
# These types are mapped to the appropriate JSON type.
#
# 2) A child type in the form 'child<subtype>' where subtype is a qdev
# device type name. Child properties create the composition tree.
#
# 3) A link type in the form 'link<subtype>' where subtype is a qdev
# device type name. Link properties form the device model graph.
#
# Since: 1.2
##
{ 'struct': 'ObjectPropertyInfo',
'data': { 'name': 'str', 'type': 'str' } }
##
# @qom-list:
#
# This command will list any properties of a object given a path in the object
# model.
#
# @path: the path within the object model. See @qom-get for a description of
# this parameter.
#
# Returns: a list of @ObjectPropertyInfo that describe the properties of the
# object.
#
# Since: 1.2
##
{ 'command': 'qom-list',
'data': { 'path': 'str' },
'returns': [ 'ObjectPropertyInfo' ] }
##
# @qom-get:
#
# This command will get a property from a object model path and return the
# value.
#
# @path: The path within the object model. There are two forms of supported
# paths--absolute and partial paths.
#
# Absolute paths are derived from the root object and can follow child<>
# or link<> properties. Since they can follow link<> properties, they
# can be arbitrarily long. Absolute paths look like absolute filenames
# and are prefixed with a leading slash.
#
# Partial paths look like relative filenames. They do not begin
# with a prefix. The matching rules for partial paths are subtle but
# designed to make specifying objects easy. At each level of the
# composition tree, the partial path is matched as an absolute path.
# The first match is not returned. At least two matches are searched
# for. A successful result is only returned if only one match is
# found. If more than one match is found, a flag is return to
# indicate that the match was ambiguous.
#
# @property: The property name to read
#
# Returns: The property value. The type depends on the property
# type. child<> and link<> properties are returned as #str
# pathnames. All integer property types (u8, u16, etc) are
# returned as #int.
#
# Since: 1.2
##
{ 'command': 'qom-get',
'data': { 'path': 'str', 'property': 'str' },
'returns': 'any' }
##
# @qom-set:
#
# This command will set a property from a object model path.
#
# @path: see @qom-get for a description of this parameter
#
# @property: the property name to set
#
# @value: a value who's type is appropriate for the property type. See @qom-get
# for a description of type mapping.
#
# Since: 1.2
##
{ 'command': 'qom-set',
'data': { 'path': 'str', 'property': 'str', 'value': 'any' } }
##
# @set_password:
#
# Sets the password of a remote display session.
#
# @protocol: `vnc' to modify the VNC server password
# `spice' to modify the Spice server password
#
# @password: the new password
#
# @connected: #optional how to handle existing clients when changing the
# password. If nothing is specified, defaults to `keep'
# `fail' to fail the command if clients are connected
# `disconnect' to disconnect existing clients
# `keep' to maintain existing clients
#
# Returns: Nothing on success
# If Spice is not enabled, DeviceNotFound
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "set_password", "arguments": { "protocol": "vnc",
# "password": "secret" } }
# <- { "return": {} }
#
##
{ 'command': 'set_password',
'data': {'protocol': 'str', 'password': 'str', '*connected': 'str'} }
##
# @expire_password:
#
# Expire the password of a remote display server.
#
# @protocol: the name of the remote display protocol `vnc' or `spice'
#
# @time: when to expire the password.
# `now' to expire the password immediately
# `never' to cancel password expiration
# `+INT' where INT is the number of seconds from now (integer)
# `INT' where INT is the absolute time in seconds
#
# Returns: Nothing on success
# If @protocol is `spice' and Spice is not active, DeviceNotFound
#
# Since: 0.14.0
#
# Notes: Time is relative to the server and currently there is no way to
# coordinate server time with client time. It is not recommended to
# use the absolute time version of the @time parameter unless you're
# sure you are on the same machine as the QEMU instance.
#
# Example:
#
# -> { "execute": "expire_password", "arguments": { "protocol": "vnc",
# "time": "+60" } }
# <- { "return": {} }
#
##
{ 'command': 'expire_password', 'data': {'protocol': 'str', 'time': 'str'} }
##
# @change-vnc-password:
#
# Change the VNC server password.
#
# @password: the new password to use with VNC authentication
#
# Since: 1.1
#
# Notes: An empty password in this command will set the password to the empty
# string. Existing clients are unaffected by executing this command.
##
{ 'command': 'change-vnc-password', 'data': {'password': 'str'} }
##
# @change:
#
# This command is multiple commands multiplexed together.
#
# @device: This is normally the name of a block device but it may also be 'vnc'.
# when it's 'vnc', then sub command depends on @target
#
# @target: If @device is a block device, then this is the new filename.
# If @device is 'vnc', then if the value 'password' selects the vnc
# change password command. Otherwise, this specifies a new server URI
# address to listen to for VNC connections.
#
# @arg: If @device is a block device, then this is an optional format to open
# the device with.
# If @device is 'vnc' and @target is 'password', this is the new VNC
# password to set. If this argument is an empty string, then no future
# logins will be allowed.
#
# Returns: Nothing on success.
# If @device is not a valid block device, DeviceNotFound
# If the new block device is encrypted, DeviceEncrypted. Note that
# if this error is returned, the device has been opened successfully
# and an additional call to @block_passwd is required to set the
# device's password. The behavior of reads and writes to the block
# device between when these calls are executed is undefined.
#
# Notes: This interface is deprecated, and it is strongly recommended that you
# avoid using it. For changing block devices, use
# blockdev-change-medium; for changing VNC parameters, use
# change-vnc-password.
#
# Since: 0.14.0
#
# Example:
#
# 1. Change a removable medium
#
# -> { "execute": "change",
# "arguments": { "device": "ide1-cd0",
# "target": "/srv/images/Fedora-12-x86_64-DVD.iso" } }
# <- { "return": {} }
#
# 2. Change VNC password
#
# -> { "execute": "change",
# "arguments": { "device": "vnc", "target": "password",
# "arg": "foobar1" } }
# <- { "return": {} }
#
##
{ 'command': 'change',
'data': {'device': 'str', 'target': 'str', '*arg': 'str'} }
##
# @ObjectTypeInfo:
#
# This structure describes a search result from @qom-list-types
#
# @name: the type name found in the search
#
# Since: 1.1
#
# Notes: This command is experimental and may change syntax in future releases.
##
{ 'struct': 'ObjectTypeInfo',
'data': { 'name': 'str' } }
##
# @qom-list-types:
#
# This command will return a list of types given search parameters
#
# @implements: if specified, only return types that implement this type name
#
# @abstract: if true, include abstract types in the results
#
# Returns: a list of @ObjectTypeInfo or an empty list if no results are found
#
# Since: 1.1
##
{ 'command': 'qom-list-types',
'data': { '*implements': 'str', '*abstract': 'bool' },
'returns': [ 'ObjectTypeInfo' ] }
##
# @DevicePropertyInfo:
#
# Information about device properties.
#
# @name: the name of the property
# @type: the typename of the property
qmp: Print descriptions of object properties Add a new "description" field to DevicePropertyInfo. The descriptions can serve as documentation in the code, and they can be used to provide better help. For example: $./qemu-system-x86_64 -device virtio-blk-pci,? Before this patch: virtio-blk-pci.iothread=link<iothread> virtio-blk-pci.x-data-plane=bool virtio-blk-pci.scsi=bool virtio-blk-pci.config-wce=bool virtio-blk-pci.serial=str virtio-blk-pci.secs=uint32 virtio-blk-pci.heads=uint32 virtio-blk-pci.cyls=uint32 virtio-blk-pci.discard_granularity=uint32 virtio-blk-pci.bootindex=int32 virtio-blk-pci.opt_io_size=uint32 virtio-blk-pci.min_io_size=uint16 virtio-blk-pci.physical_block_size=uint16 virtio-blk-pci.logical_block_size=uint16 virtio-blk-pci.drive=str virtio-blk-pci.virtio-backend=child<virtio-blk-device> virtio-blk-pci.command_serr_enable=on/off virtio-blk-pci.multifunction=on/off virtio-blk-pci.rombar=uint32 virtio-blk-pci.romfile=str virtio-blk-pci.addr=pci-devfn virtio-blk-pci.event_idx=on/off virtio-blk-pci.indirect_desc=on/off virtio-blk-pci.vectors=uint32 virtio-blk-pci.ioeventfd=on/off virtio-blk-pci.class=uint32 After: virtio-blk-pci.iothread=link<iothread> virtio-blk-pci.x-data-plane=bool (on/off) virtio-blk-pci.scsi=bool (on/off) virtio-blk-pci.config-wce=bool (on/off) virtio-blk-pci.serial=str virtio-blk-pci.secs=uint32 virtio-blk-pci.heads=uint32 virtio-blk-pci.cyls=uint32 virtio-blk-pci.discard_granularity=uint32 virtio-blk-pci.bootindex=int32 virtio-blk-pci.opt_io_size=uint32 virtio-blk-pci.min_io_size=uint16 virtio-blk-pci.physical_block_size=uint16 (A power of two between 512 and 32768) virtio-blk-pci.logical_block_size=uint16 (A power of two between 512 and 32768) virtio-blk-pci.drive=str (ID of a drive to use as a backend) virtio-blk-pci.virtio-backend=child<virtio-blk-device> virtio-blk-pci.command_serr_enable=bool (on/off) virtio-blk-pci.multifunction=bool (on/off) virtio-blk-pci.rombar=uint32 virtio-blk-pci.romfile=str virtio-blk-pci.addr=int32 (Slot and optional function number, example: 06.0 or 06) virtio-blk-pci.event_idx=bool (on/off) virtio-blk-pci.indirect_desc=bool (on/off) virtio-blk-pci.vectors=uint32 virtio-blk-pci.ioeventfd=bool (on/off) virtio-blk-pci.class=uint32 Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2014-10-07 10:33:23 +04:00
# @description: #optional if specified, the description of the property.
# (since 2.2)
#
# Since: 1.2
##
{ 'struct': 'DevicePropertyInfo',
qmp: Print descriptions of object properties Add a new "description" field to DevicePropertyInfo. The descriptions can serve as documentation in the code, and they can be used to provide better help. For example: $./qemu-system-x86_64 -device virtio-blk-pci,? Before this patch: virtio-blk-pci.iothread=link<iothread> virtio-blk-pci.x-data-plane=bool virtio-blk-pci.scsi=bool virtio-blk-pci.config-wce=bool virtio-blk-pci.serial=str virtio-blk-pci.secs=uint32 virtio-blk-pci.heads=uint32 virtio-blk-pci.cyls=uint32 virtio-blk-pci.discard_granularity=uint32 virtio-blk-pci.bootindex=int32 virtio-blk-pci.opt_io_size=uint32 virtio-blk-pci.min_io_size=uint16 virtio-blk-pci.physical_block_size=uint16 virtio-blk-pci.logical_block_size=uint16 virtio-blk-pci.drive=str virtio-blk-pci.virtio-backend=child<virtio-blk-device> virtio-blk-pci.command_serr_enable=on/off virtio-blk-pci.multifunction=on/off virtio-blk-pci.rombar=uint32 virtio-blk-pci.romfile=str virtio-blk-pci.addr=pci-devfn virtio-blk-pci.event_idx=on/off virtio-blk-pci.indirect_desc=on/off virtio-blk-pci.vectors=uint32 virtio-blk-pci.ioeventfd=on/off virtio-blk-pci.class=uint32 After: virtio-blk-pci.iothread=link<iothread> virtio-blk-pci.x-data-plane=bool (on/off) virtio-blk-pci.scsi=bool (on/off) virtio-blk-pci.config-wce=bool (on/off) virtio-blk-pci.serial=str virtio-blk-pci.secs=uint32 virtio-blk-pci.heads=uint32 virtio-blk-pci.cyls=uint32 virtio-blk-pci.discard_granularity=uint32 virtio-blk-pci.bootindex=int32 virtio-blk-pci.opt_io_size=uint32 virtio-blk-pci.min_io_size=uint16 virtio-blk-pci.physical_block_size=uint16 (A power of two between 512 and 32768) virtio-blk-pci.logical_block_size=uint16 (A power of two between 512 and 32768) virtio-blk-pci.drive=str (ID of a drive to use as a backend) virtio-blk-pci.virtio-backend=child<virtio-blk-device> virtio-blk-pci.command_serr_enable=bool (on/off) virtio-blk-pci.multifunction=bool (on/off) virtio-blk-pci.rombar=uint32 virtio-blk-pci.romfile=str virtio-blk-pci.addr=int32 (Slot and optional function number, example: 06.0 or 06) virtio-blk-pci.event_idx=bool (on/off) virtio-blk-pci.indirect_desc=bool (on/off) virtio-blk-pci.vectors=uint32 virtio-blk-pci.ioeventfd=bool (on/off) virtio-blk-pci.class=uint32 Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2014-10-07 10:33:23 +04:00
'data': { 'name': 'str', 'type': 'str', '*description': 'str' } }
##
# @device-list-properties:
#
# List properties associated with a device.
#
# @typename: the type name of a device
#
# Returns: a list of DevicePropertyInfo describing a devices properties
#
# Since: 1.2
##
{ 'command': 'device-list-properties',
'data': { 'typename': 'str'},
'returns': [ 'DevicePropertyInfo' ] }
##
# @migrate:
#
# Migrates the current running guest to another Virtual Machine.
#
# @uri: the Uniform Resource Identifier of the destination VM
#
# @blk: #optional do block migration (full disk copy)
#
# @inc: #optional incremental disk copy migration
#
# @detach: this argument exists only for compatibility reasons and
# is ignored by QEMU
#
# Returns: nothing on success
#
# Since: 0.14.0
#
# Notes:
#
# 1. The 'query-migrate' command should be used to check migration's progress
# and final result (this information is provided by the 'status' member)
#
# 2. All boolean arguments default to false
#
# 3. The user Monitor's "detach" argument is invalid in QMP and should not
# be used
#
# Example:
#
# -> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } }
# <- { "return": {} }
#
##
{ 'command': 'migrate',
'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool' } }
##
# @migrate-incoming:
#
# Start an incoming migration, the qemu must have been started
# with -incoming defer
#
# @uri: The Uniform Resource Identifier identifying the source or
# address to listen on
#
# Returns: nothing on success
#
# Since: 2.3
#
# Notes:
#
# 1. It's a bad idea to use a string for the uri, but it needs to stay
# compatible with -incoming and the format of the uri is already exposed
# above libvirt.
#
# 2. QEMU must be started with -incoming defer to allow migrate-incoming to
# be used.
#
# 3. The uri format is the same as for -incoming
#
# Example:
#
# -> { "execute": "migrate-incoming",
# "arguments": { "uri": "tcp::4446" } }
# <- { "return": {} }
#
##
{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } }
##
# @xen-save-devices-state:
#
# Save the state of all devices to file. The RAM and the block devices
# of the VM are not saved by this command.
#
# @filename: the file to save the state of the devices to as binary
# data. See xen-save-devices-state.txt for a description of the binary
# format.
#
# Returns: Nothing on success
#
# Since: 1.1
#
# Example:
#
# -> { "execute": "xen-save-devices-state",
# "arguments": { "filename": "/tmp/save" } }
# <- { "return": {} }
#
##
{ 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
##
# @xen-set-global-dirty-log:
#
# Enable or disable the global dirty log mode.
#
# @enable: true to enable, false to disable.
#
# Returns: nothing
#
# Since: 1.3
#
# Example:
#
# -> { "execute": "xen-set-global-dirty-log",
# "arguments": { "enable": true } }
# <- { "return": {} }
#
##
{ '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: #optional 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', '*bus': 'str', '*id': 'str'},
'gen': false } # so we can get the additional arguments
##
# @device_del:
#
# Remove a device from a guest
#
# @id: the device's ID or QOM path
#
# Returns: Nothing on success
# If @id is not a valid device, DeviceNotFound
#
# Notes: When this command completes, the device may not be removed from the
# guest. Hot removal is an operation that requires guest cooperation.
# This command merely requests that the guest begin the hot removal
# process. Completion of the device removal process is signaled with a
# DEVICE_DELETED event. Guest reset will automatically complete removal
# for all devices.
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "device_del",
# "arguments": { "id": "net1" } }
# <- { "return": {} }
#
# -> { "execute": "device_del",
# "arguments": { "id": "/machine/peripheral-anon/device[0]" } }
# <- { "return": {} }
#
##
{ 'command': 'device_del', 'data': {'id': 'str'} }
##
# @DumpGuestMemoryFormat:
#
# An enumeration of guest-memory-dump's format.
#
# @elf: elf format
#
# @kdump-zlib: kdump-compressed format with zlib-compressed
#
# @kdump-lzo: kdump-compressed format with lzo-compressed
#
# @kdump-snappy: kdump-compressed format with snappy-compressed
#
# Since: 2.0
##
{ 'enum': 'DumpGuestMemoryFormat',
'data': [ 'elf', 'kdump-zlib', 'kdump-lzo', 'kdump-snappy' ] }
##
# @dump-guest-memory:
#
# Dump guest's memory to vmcore. It is a synchronous operation that can take
# very long depending on the amount of guest memory.
#
# @paging: if true, do paging to get guest's memory mapping. This allows
# using gdb to process the core file.
#
# IMPORTANT: this option can make QEMU allocate several gigabytes
# of RAM. This can happen for a large guest, or a
# malicious guest pretending to be large.
#
# Also, paging=true has the following limitations:
#
# 1. The guest may be in a catastrophic state or can have corrupted
# memory, which cannot be trusted
# 2. The guest can be in real-mode even if paging is enabled. For
# example, the guest uses ACPI to sleep, and ACPI sleep state
# goes in real-mode
# 3. Currently only supported on i386 and x86_64.
#
# @protocol: the filename or file descriptor of the vmcore. The supported
# protocols are:
#
# 1. file: the protocol starts with "file:", and the following
# string is the file's path.
# 2. fd: the protocol starts with "fd:", and the following string
# is the fd's name.
#
# @detach: #optional if true, QMP will return immediately rather than
# waiting for the dump to finish. The user can track progress
# using "query-dump". (since 2.6).
#
# @begin: #optional if specified, the starting physical address.
#
# @length: #optional if specified, the memory size, in bytes. If you don't
# want to dump all guest's memory, please specify the start @begin
# and @length
#
# @format: #optional if specified, the format of guest memory dump. But non-elf
# format is conflict with paging and filter, ie. @paging, @begin and
# @length is not allowed to be specified with non-elf @format at the
# same time (since 2.0)
#
# Note: All boolean arguments default to false
#
# Returns: nothing on success
#
# Since: 1.2
#
# Example:
#
# -> { "execute": "dump-guest-memory",
# "arguments": { "protocol": "fd:dump" } }
# <- { "return": {} }
#
##
{ 'command': 'dump-guest-memory',
'data': { 'paging': 'bool', 'protocol': 'str', '*detach': 'bool',
'*begin': 'int', '*length': 'int',
'*format': 'DumpGuestMemoryFormat'} }
##
# @DumpStatus:
#
# Describe the status of a long-running background guest memory dump.
#
# @none: no dump-guest-memory has started yet.
#
# @active: there is one dump running in background.
#
# @completed: the last dump has finished successfully.
#
# @failed: the last dump has failed.
#
# Since: 2.6
##
{ 'enum': 'DumpStatus',
'data': [ 'none', 'active', 'completed', 'failed' ] }
##
# @DumpQueryResult:
#
# The result format for 'query-dump'.
#
# @status: enum of @DumpStatus, which shows current dump status
#
# @completed: bytes written in latest dump (uncompressed)
#
# @total: total bytes to be written in latest dump (uncompressed)
#
# Since: 2.6
##
{ 'struct': 'DumpQueryResult',
'data': { 'status': 'DumpStatus',
'completed': 'int',
'total': 'int' } }
##
# @query-dump:
#
# Query latest dump status.
#
# Returns: A @DumpStatus object showing the dump status.
#
# Since: 2.6
#
# Example:
#
# -> { "execute": "query-dump" }
# <- { "return": { "status": "active", "completed": 1024000,
# "total": 2048000 } }
#
##
{ 'command': 'query-dump', 'returns': 'DumpQueryResult' }
##
# @DumpGuestMemoryCapability:
#
# A list of the available formats for dump-guest-memory
#
# Since: 2.0
##
{ 'struct': 'DumpGuestMemoryCapability',
'data': {
'formats': ['DumpGuestMemoryFormat'] } }
##
# @query-dump-guest-memory-capability:
#
# Returns the available formats for dump-guest-memory
#
# Returns: A @DumpGuestMemoryCapability object listing available formats for
# dump-guest-memory
#
# Since: 2.0
#
# Example:
#
# -> { "execute": "query-dump-guest-memory-capability" }
# <- { "return": { "formats":
# ["elf", "kdump-zlib", "kdump-lzo", "kdump-snappy"] }
#
##
{ 'command': 'query-dump-guest-memory-capability',
'returns': 'DumpGuestMemoryCapability' }
##
# @dump-skeys:
#
# Dump guest's storage keys
#
# @filename: the path to the file to dump to
#
# This command is only supported on s390 architecture.
#
# Since: 2.5
#
# Example:
#
# -> { "execute": "dump-skeys",
# "arguments": { "filename": "/tmp/skeys" } }
# <- { "return": {} }
#
##
{ 'command': 'dump-skeys',
'data': { 'filename': 'str' } }
##
# @netdev_add:
#
# Add a network backend.
#
# @type: the type of network backend. Current valid values are 'user', 'tap',
# 'vde', 'socket', 'dump' and 'bridge'
#
# @id: the name of the new network backend
#
# Additional arguments depend on the type.
#
# 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.14.0
#
# Returns: Nothing on success
# If @type is not a valid network backend, DeviceNotFound
#
# Example:
#
# -> { "execute": "netdev_add",
# "arguments": { "type": "user", "id": "netdev1",
# "dnssearch": "example.org" } }
# <- { "return": {} }
#
##
{ 'command': 'netdev_add',
'data': {'type': 'str', 'id': 'str'},
'gen': false } # so we can get the additional arguments
##
# @netdev_del:
#
# Remove a network backend.
#
# @id: the name of the network backend to remove
#
# Returns: Nothing on success
# If @id is not a valid network backend, DeviceNotFound
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "netdev_del", "arguments": { "id": "netdev1" } }
# <- { "return": {} }
#
##
{ 'command': 'netdev_del', 'data': {'id': 'str'} }
##
# @object-add:
#
# Create a QOM object.
#
# @qom-type: the class name for the object to be created
#
# @id: the name of the new object
#
# @props: #optional a dictionary of properties to be passed to the backend
#
# Returns: Nothing on success
# Error if @qom-type is not a valid class name
#
# Since: 2.0
#
# Example:
#
# -> { "execute": "object-add",
# "arguments": { "qom-type": "rng-random", "id": "rng1",
# "props": { "filename": "/dev/hwrng" } } }
# <- { "return": {} }
#
##
{ 'command': 'object-add',
'data': {'qom-type': 'str', 'id': 'str', '*props': 'any'} }
##
# @object-del:
#
# Remove a QOM object.
#
# @id: the name of the QOM object to remove
#
# Returns: Nothing on success
# Error if @id is not a valid id for a QOM object
#
# Since: 2.0
#
# Example:
#
# -> { "execute": "object-del", "arguments": { "id": "rng1" } }
# <- { "return": {} }
#
##
{ 'command': 'object-del', 'data': {'id': 'str'} }
##
# @NetdevNoneOptions:
#
# Use it alone to have zero network devices.
#
# Since: 1.2
##
{ 'struct': 'NetdevNoneOptions',
'data': { } }
##
# @NetLegacyNicOptions:
#
# Create a new Network Interface Card.
#
# @netdev: #optional id of -netdev to connect to
#
# @macaddr: #optional MAC address
#
# @model: #optional device model (e1000, rtl8139, virtio etc.)
#
# @addr: #optional PCI device address
#
# @vectors: #optional number of MSI-x vectors, 0 to disable MSI-X
#
# Since: 1.2
##
{ 'struct': 'NetLegacyNicOptions',
'data': {
'*netdev': 'str',
'*macaddr': 'str',
'*model': 'str',
'*addr': 'str',
'*vectors': 'uint32' } }
##
# @String:
#
# A fat type wrapping 'str', to be embedded in lists.
#
# Since: 1.2
##
{ 'struct': 'String',
'data': {
'str': 'str' } }
##
# @NetdevUserOptions:
#
# Use the user mode network stack which requires no administrator privilege to
# run.
#
# @hostname: #optional client hostname reported by the builtin DHCP server
#
# @restrict: #optional isolate the guest from the host
#
# @ipv4: #optional whether to support IPv4, default true for enabled
# (since 2.6)
#
# @ipv6: #optional whether to support IPv6, default true for enabled
# (since 2.6)
#
# @ip: #optional legacy parameter, use net= instead
#
# @net: #optional IP network address that the guest will see, in the
# form addr[/netmask] The netmask is optional, and can be
# either in the form a.b.c.d or as a number of valid top-most
# bits. Default is 10.0.2.0/24.
#
# @host: #optional guest-visible address of the host
#
# @tftp: #optional root directory of the built-in TFTP server
#
# @bootfile: #optional BOOTP filename, for use with tftp=
#
# @dhcpstart: #optional the first of the 16 IPs the built-in DHCP server can
# assign
#
# @dns: #optional guest-visible address of the virtual nameserver
#
# @dnssearch: #optional list of DNS suffixes to search, passed as DHCP option
# to the guest
#
# @ipv6-prefix: #optional IPv6 network prefix (default is fec0::) (since
# 2.6). The network prefix is given in the usual
# hexadecimal IPv6 address notation.
#
# @ipv6-prefixlen: #optional IPv6 network prefix length (default is 64)
# (since 2.6)
#
# @ipv6-host: #optional guest-visible IPv6 address of the host (since 2.6)
#
# @ipv6-dns: #optional guest-visible IPv6 address of the virtual
# nameserver (since 2.6)
#
# @smb: #optional root directory of the built-in SMB server
#
# @smbserver: #optional IP address of the built-in SMB server
#
# @hostfwd: #optional redirect incoming TCP or UDP host connections to guest
# endpoints
#
# @guestfwd: #optional forward guest TCP connections
#
# Since: 1.2
##
{ 'struct': 'NetdevUserOptions',
'data': {
'*hostname': 'str',
'*restrict': 'bool',
'*ipv4': 'bool',
'*ipv6': 'bool',
'*ip': 'str',
'*net': 'str',
'*host': 'str',
'*tftp': 'str',
'*bootfile': 'str',
'*dhcpstart': 'str',
'*dns': 'str',
'*dnssearch': ['String'],
'*ipv6-prefix': 'str',
'*ipv6-prefixlen': 'int',
'*ipv6-host': 'str',
'*ipv6-dns': 'str',
'*smb': 'str',
'*smbserver': 'str',
'*hostfwd': ['String'],
'*guestfwd': ['String'] } }
##
# @NetdevTapOptions:
#
# Connect the host TAP network interface name to the VLAN.
#
# @ifname: #optional interface name
#
# @fd: #optional file descriptor of an already opened tap
#
# @fds: #optional multiple file descriptors of already opened multiqueue capable
# tap
#
# @script: #optional script to initialize the interface
#
# @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.
#
# @vnet_hdr: #optional enable the IFF_VNET_HDR flag on the tap interface
#
# @vhost: #optional enable vhost-net network accelerator
#
# @vhostfd: #optional file descriptor of an already opened vhost net device
#
# @vhostfds: #optional file descriptors of multiple already opened vhost net
# devices
#
# @vhostforce: #optional vhost on for non-MSIX virtio guests
#
# @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',
'data': {
'*ifname': 'str',
'*fd': 'str',
'*fds': 'str',
'*script': 'str',
'*downscript': 'str',
'*br': 'str',
'*helper': 'str',
'*sndbuf': 'size',
'*vnet_hdr': 'bool',
'*vhost': 'bool',
'*vhostfd': 'str',
'*vhostfds': 'str',
'*vhostforce': 'bool',
'*queues': 'uint32',
'*poll-us': 'uint32'} }
##
# @NetdevSocketOptions:
#
# Connect the VLAN to a remote VLAN in another QEMU virtual machine using a TCP
# socket connection.
#
# @fd: #optional file descriptor of an already opened socket
#
# @listen: #optional port number, and optional hostname, to listen on
#
# @connect: #optional port number, and optional hostname, to connect to
#
# @mcast: #optional UDP multicast address and port number
#
# @localaddr: #optional source address and port for multicast and udp packets
#
# @udp: #optional UDP unicast address and port number
#
# Since: 1.2
##
{ 'struct': 'NetdevSocketOptions',
'data': {
'*fd': 'str',
'*listen': 'str',
'*connect': 'str',
'*mcast': 'str',
'*localaddr': 'str',
'*udp': 'str' } }
##
# @NetdevL2TPv3Options:
#
# Connect the VLAN to Ethernet over L2TPv3 Static tunnel
#
# @src: source address
#
# @dst: destination address
#
# @srcport: #optional source port - mandatory for udp, optional for ip
#
# @dstport: #optional destination port - mandatory for udp, optional for ip
#
# @ipv6: #optional - force the use of ipv6
#
# @udp: #optional - use the udp version of l2tpv3 encapsulation
#
# @cookie64: #optional - use 64 bit coookies
#
# @counter: #optional have sequence counter
#
# @pincounter: #optional pin sequence counter to zero -
# workaround for buggy implementations or
# networks with packet reorder
#
# @txcookie: #optional 32 or 64 bit transmit cookie
#
# @rxcookie: #optional 32 or 64 bit receive cookie
#
# @txsession: 32 bit transmit session
#
# @rxsession: #optional 32 bit receive session - if not specified
# set to the same value as transmit
#
# @offset: #optional additional offset - allows the insertion of
# additional application-specific data before the packet payload
#
# Since: 2.1
##
{ 'struct': 'NetdevL2TPv3Options',
'data': {
'src': 'str',
'dst': 'str',
'*srcport': 'str',
'*dstport': 'str',
'*ipv6': 'bool',
'*udp': 'bool',
'*cookie64': 'bool',
'*counter': 'bool',
'*pincounter': 'bool',
'*txcookie': 'uint64',
'*rxcookie': 'uint64',
'txsession': 'uint32',
'*rxsession': 'uint32',
'*offset': 'uint32' } }
##
# @NetdevVdeOptions:
#
# Connect the VLAN to a vde switch running on the host.
#
# @sock: #optional socket path
#
# @port: #optional port number
#
# @group: #optional group owner of socket
#
# @mode: #optional permissions for socket
#
# Since: 1.2
##
{ 'struct': 'NetdevVdeOptions',
'data': {
'*sock': 'str',
'*port': 'uint16',
'*group': 'str',
'*mode': 'uint16' } }
##
# @NetdevDumpOptions:
#
# Dump VLAN network traffic to a file.
#
# @len: #optional per-packet size limit (64k default). Understands [TGMKkb]
# suffixes.
#
# @file: #optional dump file path (default is qemu-vlan0.pcap)
#
# Since: 1.2
##
{ 'struct': 'NetdevDumpOptions',
'data': {
'*len': 'size',
'*file': 'str' } }
##
# @NetdevBridgeOptions:
#
# Connect a host TAP network interface to a host bridge device.
#
# @br: #optional bridge name
#
# @helper: #optional command to execute to configure bridge
#
# Since: 1.2
##
{ 'struct': 'NetdevBridgeOptions',
'data': {
'*br': 'str',
'*helper': 'str' } }
##
# @NetdevHubPortOptions:
#
# Connect two or more net clients through a software hub.
#
# @hubid: hub identifier number
#
# Since: 1.2
##
{ 'struct': 'NetdevHubPortOptions',
'data': {
'hubid': 'int32' } }
##
# @NetdevNetmapOptions:
#
# Connect a client to a netmap-enabled NIC or to a VALE switch port
#
# @ifname: Either the name of an existing network interface supported by
# netmap, or the name of a VALE port (created on the fly).
# A VALE port name is in the form 'valeXXX:YYY', where XXX and
# YYY are non-negative integers. XXX identifies a switch and
# YYY identifies a port of the switch. VALE ports having the
# same XXX are therefore connected to the same switch.
#
# @devname: #optional path of the netmap device (default: '/dev/netmap').
#
# Since: 2.0
##
{ 'struct': 'NetdevNetmapOptions',
'data': {
'ifname': 'str',
'*devname': 'str' } }
##
# @NetdevVhostUserOptions:
#
# Vhost-user network backend
#
# @chardev: name of a unix socket chardev
#
# @vhostforce: #optional vhost on for non-MSIX virtio guests (default: false).
#
vhost-user: add multiple queue support This patch is initially based a patch from Nikolay Nikolaev. This patch adds vhost-user multiple queue support, by creating a nc and vhost_net pair for each queue. Qemu exits if find that the backend can't support the number of requested queues (by providing queues=# option). The max number is queried by a new message, VHOST_USER_GET_QUEUE_NUM, and is sent only when protocol feature VHOST_USER_PROTOCOL_F_MQ is present first. The max queue check is done at vhost-user initiation stage. We initiate one queue first, which, in the meantime, also gets the max_queues the backend supports. In older version, it was reported that some messages are sent more times than necessary. Here we came an agreement with Michael that we could categorize vhost user messages to 2 types: non-vring specific messages, which should be sent only once, and vring specific messages, which should be sent per queue. Here I introduced a helper function vhost_user_one_time_request(), which lists following messages as non-vring specific messages: VHOST_USER_SET_OWNER VHOST_USER_RESET_DEVICE VHOST_USER_SET_MEM_TABLE VHOST_USER_GET_QUEUE_NUM For above messages, we simply ignore them when they are not sent the first time. Signed-off-by: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com> Signed-off-by: Changchun Ouyang <changchun.ouyang@intel.com> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Tested-by: Marcel Apfelbaum <marcel@redhat.com>
2015-09-23 07:20:00 +03:00
# @queues: #optional number of queues to be created for multiqueue vhost-user
# (default: 1) (Since 2.5)
#
# Since: 2.1
##
{ 'struct': 'NetdevVhostUserOptions',
'data': {
'chardev': 'str',
vhost-user: add multiple queue support This patch is initially based a patch from Nikolay Nikolaev. This patch adds vhost-user multiple queue support, by creating a nc and vhost_net pair for each queue. Qemu exits if find that the backend can't support the number of requested queues (by providing queues=# option). The max number is queried by a new message, VHOST_USER_GET_QUEUE_NUM, and is sent only when protocol feature VHOST_USER_PROTOCOL_F_MQ is present first. The max queue check is done at vhost-user initiation stage. We initiate one queue first, which, in the meantime, also gets the max_queues the backend supports. In older version, it was reported that some messages are sent more times than necessary. Here we came an agreement with Michael that we could categorize vhost user messages to 2 types: non-vring specific messages, which should be sent only once, and vring specific messages, which should be sent per queue. Here I introduced a helper function vhost_user_one_time_request(), which lists following messages as non-vring specific messages: VHOST_USER_SET_OWNER VHOST_USER_RESET_DEVICE VHOST_USER_SET_MEM_TABLE VHOST_USER_GET_QUEUE_NUM For above messages, we simply ignore them when they are not sent the first time. Signed-off-by: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com> Signed-off-by: Changchun Ouyang <changchun.ouyang@intel.com> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Tested-by: Marcel Apfelbaum <marcel@redhat.com>
2015-09-23 07:20:00 +03:00
'*vhostforce': 'bool',
'*queues': 'int' } }
##
# @NetClientDriver:
#
qapi: Change Netdev into a flat union This is a mostly-mechanical conversion that creates a new flat union 'Netdev' QAPI type that covers all the branches of the former 'NetClientOptions' simple union, where the branches are now listed in a new 'NetClientDriver' enum rather than generated from the simple union. The existence of a flat union has no change to the command line syntax accepted for new code, and will make it possible for a future patch to switch the QMP command to parse a boxed union for no change to valid QMP; but it does have some ripple effect on the C code when dealing with the new types. While making the conversion, note that the 'NetLegacy' type remains unchanged: it applies only to legacy command line options, and will not be ported to QMP, so it should remain a wrapper around a simple union; to avoid confusion, the type named 'NetClientOptions' is now gone, and we introduce 'NetLegacyOptions' in its place. Then, in the C code, we convert from NetLegacy to Netdev as soon as possible, so that the bulk of the net stack only has to deal with one QAPI type, not two. Note that since the old legacy code always rejected 'hubport', we can just omit that branch from the new 'NetLegacyOptions' simple union. Based on an idea originally by Zoltán Kővágó <DirtY.iCE.hu@gmail.com>: Message-Id: <01a527fbf1a5de880091f98cf011616a78adeeee.1441627176.git.DirtY.iCE.hu@gmail.com> although the sed script in that patch no longer applies due to other changes in the tree since then, and I also did some manual cleanups (such as fixing whitespace to keep checkpatch happy). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1468468228-27827-13-git-send-email-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Fixup from Eric squashed in] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-07-14 06:50:23 +03:00
# Available netdev drivers.
#
# Since: 2.7
qapi: Change Netdev into a flat union This is a mostly-mechanical conversion that creates a new flat union 'Netdev' QAPI type that covers all the branches of the former 'NetClientOptions' simple union, where the branches are now listed in a new 'NetClientDriver' enum rather than generated from the simple union. The existence of a flat union has no change to the command line syntax accepted for new code, and will make it possible for a future patch to switch the QMP command to parse a boxed union for no change to valid QMP; but it does have some ripple effect on the C code when dealing with the new types. While making the conversion, note that the 'NetLegacy' type remains unchanged: it applies only to legacy command line options, and will not be ported to QMP, so it should remain a wrapper around a simple union; to avoid confusion, the type named 'NetClientOptions' is now gone, and we introduce 'NetLegacyOptions' in its place. Then, in the C code, we convert from NetLegacy to Netdev as soon as possible, so that the bulk of the net stack only has to deal with one QAPI type, not two. Note that since the old legacy code always rejected 'hubport', we can just omit that branch from the new 'NetLegacyOptions' simple union. Based on an idea originally by Zoltán Kővágó <DirtY.iCE.hu@gmail.com>: Message-Id: <01a527fbf1a5de880091f98cf011616a78adeeee.1441627176.git.DirtY.iCE.hu@gmail.com> although the sed script in that patch no longer applies due to other changes in the tree since then, and I also did some manual cleanups (such as fixing whitespace to keep checkpatch happy). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1468468228-27827-13-git-send-email-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Fixup from Eric squashed in] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-07-14 06:50:23 +03:00
##
{ 'enum': 'NetClientDriver',
'data': [ 'none', 'nic', 'user', 'tap', 'l2tpv3', 'socket', 'vde', 'dump',
'bridge', 'hubport', 'netmap', 'vhost-user' ] }
##
# @Netdev:
qapi: Change Netdev into a flat union This is a mostly-mechanical conversion that creates a new flat union 'Netdev' QAPI type that covers all the branches of the former 'NetClientOptions' simple union, where the branches are now listed in a new 'NetClientDriver' enum rather than generated from the simple union. The existence of a flat union has no change to the command line syntax accepted for new code, and will make it possible for a future patch to switch the QMP command to parse a boxed union for no change to valid QMP; but it does have some ripple effect on the C code when dealing with the new types. While making the conversion, note that the 'NetLegacy' type remains unchanged: it applies only to legacy command line options, and will not be ported to QMP, so it should remain a wrapper around a simple union; to avoid confusion, the type named 'NetClientOptions' is now gone, and we introduce 'NetLegacyOptions' in its place. Then, in the C code, we convert from NetLegacy to Netdev as soon as possible, so that the bulk of the net stack only has to deal with one QAPI type, not two. Note that since the old legacy code always rejected 'hubport', we can just omit that branch from the new 'NetLegacyOptions' simple union. Based on an idea originally by Zoltán Kővágó <DirtY.iCE.hu@gmail.com>: Message-Id: <01a527fbf1a5de880091f98cf011616a78adeeee.1441627176.git.DirtY.iCE.hu@gmail.com> although the sed script in that patch no longer applies due to other changes in the tree since then, and I also did some manual cleanups (such as fixing whitespace to keep checkpatch happy). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1468468228-27827-13-git-send-email-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Fixup from Eric squashed in] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-07-14 06:50:23 +03:00
#
# 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
##
qapi: Change Netdev into a flat union This is a mostly-mechanical conversion that creates a new flat union 'Netdev' QAPI type that covers all the branches of the former 'NetClientOptions' simple union, where the branches are now listed in a new 'NetClientDriver' enum rather than generated from the simple union. The existence of a flat union has no change to the command line syntax accepted for new code, and will make it possible for a future patch to switch the QMP command to parse a boxed union for no change to valid QMP; but it does have some ripple effect on the C code when dealing with the new types. While making the conversion, note that the 'NetLegacy' type remains unchanged: it applies only to legacy command line options, and will not be ported to QMP, so it should remain a wrapper around a simple union; to avoid confusion, the type named 'NetClientOptions' is now gone, and we introduce 'NetLegacyOptions' in its place. Then, in the C code, we convert from NetLegacy to Netdev as soon as possible, so that the bulk of the net stack only has to deal with one QAPI type, not two. Note that since the old legacy code always rejected 'hubport', we can just omit that branch from the new 'NetLegacyOptions' simple union. Based on an idea originally by Zoltán Kővágó <DirtY.iCE.hu@gmail.com>: Message-Id: <01a527fbf1a5de880091f98cf011616a78adeeee.1441627176.git.DirtY.iCE.hu@gmail.com> although the sed script in that patch no longer applies due to other changes in the tree since then, and I also did some manual cleanups (such as fixing whitespace to keep checkpatch happy). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1468468228-27827-13-git-send-email-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Fixup from Eric squashed in] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-07-14 06:50:23 +03:00
{ 'union': 'Netdev',
'base': { 'id': 'str', 'type': 'NetClientDriver' },
'discriminator': 'type',
'data': {
'none': 'NetdevNoneOptions',
'nic': 'NetLegacyNicOptions',
'user': 'NetdevUserOptions',
'tap': 'NetdevTapOptions',
'l2tpv3': 'NetdevL2TPv3Options',
'socket': 'NetdevSocketOptions',
'vde': 'NetdevVdeOptions',
'dump': 'NetdevDumpOptions',
'bridge': 'NetdevBridgeOptions',
'hubport': 'NetdevHubPortOptions',
'netmap': 'NetdevNetmapOptions',
'vhost-user': 'NetdevVhostUserOptions' } }
##
# @NetLegacy:
#
# Captures the configuration of a network device; legacy.
#
# @vlan: #optional vlan number
#
# @id: #optional identifier for monitor commands
#
# @name: #optional identifier for monitor commands, ignored if @id is present
#
# @opts: device type specific properties (legacy)
#
# Since: 1.2
##
{ 'struct': 'NetLegacy',
'data': {
'*vlan': 'int32',
'*id': 'str',
'*name': 'str',
qapi: Change Netdev into a flat union This is a mostly-mechanical conversion that creates a new flat union 'Netdev' QAPI type that covers all the branches of the former 'NetClientOptions' simple union, where the branches are now listed in a new 'NetClientDriver' enum rather than generated from the simple union. The existence of a flat union has no change to the command line syntax accepted for new code, and will make it possible for a future patch to switch the QMP command to parse a boxed union for no change to valid QMP; but it does have some ripple effect on the C code when dealing with the new types. While making the conversion, note that the 'NetLegacy' type remains unchanged: it applies only to legacy command line options, and will not be ported to QMP, so it should remain a wrapper around a simple union; to avoid confusion, the type named 'NetClientOptions' is now gone, and we introduce 'NetLegacyOptions' in its place. Then, in the C code, we convert from NetLegacy to Netdev as soon as possible, so that the bulk of the net stack only has to deal with one QAPI type, not two. Note that since the old legacy code always rejected 'hubport', we can just omit that branch from the new 'NetLegacyOptions' simple union. Based on an idea originally by Zoltán Kővágó <DirtY.iCE.hu@gmail.com>: Message-Id: <01a527fbf1a5de880091f98cf011616a78adeeee.1441627176.git.DirtY.iCE.hu@gmail.com> although the sed script in that patch no longer applies due to other changes in the tree since then, and I also did some manual cleanups (such as fixing whitespace to keep checkpatch happy). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1468468228-27827-13-git-send-email-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Fixup from Eric squashed in] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-07-14 06:50:23 +03:00
'opts': 'NetLegacyOptions' } }
##
# @NetLegacyOptions:
#
qapi: Change Netdev into a flat union This is a mostly-mechanical conversion that creates a new flat union 'Netdev' QAPI type that covers all the branches of the former 'NetClientOptions' simple union, where the branches are now listed in a new 'NetClientDriver' enum rather than generated from the simple union. The existence of a flat union has no change to the command line syntax accepted for new code, and will make it possible for a future patch to switch the QMP command to parse a boxed union for no change to valid QMP; but it does have some ripple effect on the C code when dealing with the new types. While making the conversion, note that the 'NetLegacy' type remains unchanged: it applies only to legacy command line options, and will not be ported to QMP, so it should remain a wrapper around a simple union; to avoid confusion, the type named 'NetClientOptions' is now gone, and we introduce 'NetLegacyOptions' in its place. Then, in the C code, we convert from NetLegacy to Netdev as soon as possible, so that the bulk of the net stack only has to deal with one QAPI type, not two. Note that since the old legacy code always rejected 'hubport', we can just omit that branch from the new 'NetLegacyOptions' simple union. Based on an idea originally by Zoltán Kővágó <DirtY.iCE.hu@gmail.com>: Message-Id: <01a527fbf1a5de880091f98cf011616a78adeeee.1441627176.git.DirtY.iCE.hu@gmail.com> although the sed script in that patch no longer applies due to other changes in the tree since then, and I also did some manual cleanups (such as fixing whitespace to keep checkpatch happy). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1468468228-27827-13-git-send-email-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Fixup from Eric squashed in] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-07-14 06:50:23 +03:00
# Like Netdev, but for use only by the legacy command line options
#
# Since: 1.2
##
qapi: Change Netdev into a flat union This is a mostly-mechanical conversion that creates a new flat union 'Netdev' QAPI type that covers all the branches of the former 'NetClientOptions' simple union, where the branches are now listed in a new 'NetClientDriver' enum rather than generated from the simple union. The existence of a flat union has no change to the command line syntax accepted for new code, and will make it possible for a future patch to switch the QMP command to parse a boxed union for no change to valid QMP; but it does have some ripple effect on the C code when dealing with the new types. While making the conversion, note that the 'NetLegacy' type remains unchanged: it applies only to legacy command line options, and will not be ported to QMP, so it should remain a wrapper around a simple union; to avoid confusion, the type named 'NetClientOptions' is now gone, and we introduce 'NetLegacyOptions' in its place. Then, in the C code, we convert from NetLegacy to Netdev as soon as possible, so that the bulk of the net stack only has to deal with one QAPI type, not two. Note that since the old legacy code always rejected 'hubport', we can just omit that branch from the new 'NetLegacyOptions' simple union. Based on an idea originally by Zoltán Kővágó <DirtY.iCE.hu@gmail.com>: Message-Id: <01a527fbf1a5de880091f98cf011616a78adeeee.1441627176.git.DirtY.iCE.hu@gmail.com> although the sed script in that patch no longer applies due to other changes in the tree since then, and I also did some manual cleanups (such as fixing whitespace to keep checkpatch happy). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1468468228-27827-13-git-send-email-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Fixup from Eric squashed in] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-07-14 06:50:23 +03:00
{ 'union': 'NetLegacyOptions',
'data': {
qapi: Change Netdev into a flat union This is a mostly-mechanical conversion that creates a new flat union 'Netdev' QAPI type that covers all the branches of the former 'NetClientOptions' simple union, where the branches are now listed in a new 'NetClientDriver' enum rather than generated from the simple union. The existence of a flat union has no change to the command line syntax accepted for new code, and will make it possible for a future patch to switch the QMP command to parse a boxed union for no change to valid QMP; but it does have some ripple effect on the C code when dealing with the new types. While making the conversion, note that the 'NetLegacy' type remains unchanged: it applies only to legacy command line options, and will not be ported to QMP, so it should remain a wrapper around a simple union; to avoid confusion, the type named 'NetClientOptions' is now gone, and we introduce 'NetLegacyOptions' in its place. Then, in the C code, we convert from NetLegacy to Netdev as soon as possible, so that the bulk of the net stack only has to deal with one QAPI type, not two. Note that since the old legacy code always rejected 'hubport', we can just omit that branch from the new 'NetLegacyOptions' simple union. Based on an idea originally by Zoltán Kővágó <DirtY.iCE.hu@gmail.com>: Message-Id: <01a527fbf1a5de880091f98cf011616a78adeeee.1441627176.git.DirtY.iCE.hu@gmail.com> although the sed script in that patch no longer applies due to other changes in the tree since then, and I also did some manual cleanups (such as fixing whitespace to keep checkpatch happy). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1468468228-27827-13-git-send-email-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Fixup from Eric squashed in] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-07-14 06:50:23 +03:00
'none': 'NetdevNoneOptions',
'nic': 'NetLegacyNicOptions',
'user': 'NetdevUserOptions',
'tap': 'NetdevTapOptions',
'l2tpv3': 'NetdevL2TPv3Options',
'socket': 'NetdevSocketOptions',
'vde': 'NetdevVdeOptions',
'dump': 'NetdevDumpOptions',
'bridge': 'NetdevBridgeOptions',
'netmap': 'NetdevNetmapOptions',
'vhost-user': 'NetdevVhostUserOptions' } }
##
# @NetFilterDirection:
#
# Indicates whether a netfilter is attached to a netdev's transmit queue or
# receive queue or both.
#
# @all: the filter is attached both to the receive and the transmit
# queue of the netdev (default).
#
# @rx: the filter is attached to the receive queue of the netdev,
# where it will receive packets sent to the netdev.
#
# @tx: the filter is attached to the transmit queue of the netdev,
# where it will receive packets sent by the netdev.
#
# Since: 2.5
##
{ 'enum': 'NetFilterDirection',
'data': [ 'all', 'rx', 'tx' ] }
##
# @InetSocketAddress:
#
# Captures a socket address or address range in the Internet namespace.
#
# @host: host part of the address
#
# @port: port part of the address, or lowest port if @to is present
#
# @numeric: #optional true if the host/port are guaranteed to be numeric,
# false if name resolution should be attempted. Defaults to false.
# (Since 2.9)
#
# @to: highest port to try
#
# @ipv4: whether to accept IPv4 addresses, default try both IPv4 and IPv6
# #optional
#
# @ipv6: whether to accept IPv6 addresses, default try both IPv4 and IPv6
# #optional
#
# Since: 1.3
##
{ 'struct': 'InetSocketAddress',
'data': {
'host': 'str',
'port': 'str',
'*numeric': 'bool',
'*to': 'uint16',
'*ipv4': 'bool',
'*ipv6': 'bool' } }
##
# @UnixSocketAddress:
#
# Captures a socket address in the local ("Unix socket") namespace.
#
# @path: filesystem path to use
#
# Since: 1.3
##
{ 'struct': 'UnixSocketAddress',
'data': {
'path': 'str' } }
##
# @VsockSocketAddress:
#
# Captures a socket address in the vsock namespace.
#
# @cid: unique host identifier
# @port: port
#
# Note: 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:
#
# Captures the address of a socket, which could also be a named file descriptor
#
# Since: 1.3
##
{ 'union': 'SocketAddress',
'data': {
'inet': 'InetSocketAddress',
'unix': 'UnixSocketAddress',
'vsock': 'VsockSocketAddress',
'fd': 'String' } }
##
# @getfd:
#
# Receive a file descriptor via SCM rights and assign it a name
#
# @fdname: file descriptor name
#
# Returns: Nothing on success
#
# Since: 0.14.0
#
# Notes: If @fdname already exists, the file descriptor assigned to
# it will be closed and replaced by the received file
# descriptor.
#
# The 'closefd' command can be used to explicitly close the
# file descriptor when it is no longer needed.
#
# Example:
#
# -> { "execute": "getfd", "arguments": { "fdname": "fd1" } }
# <- { "return": {} }
#
##
{ 'command': 'getfd', 'data': {'fdname': 'str'} }
##
# @closefd:
#
# Close a file descriptor previously passed via SCM rights
#
# @fdname: file descriptor name
#
# Returns: Nothing on success
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "closefd", "arguments": { "fdname": "fd1" } }
# <- { "return": {} }
#
##
{ 'command': 'closefd', 'data': {'fdname': 'str'} }
##
# @MachineInfo:
#
# Information describing a machine.
#
# @name: the name of the machine
#
# @alias: #optional an alias for the machine name
#
# @is-default: #optional whether the machine is default
#
# @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',
'hotpluggable-cpus': 'bool'} }
##
# @query-machines:
#
# Return a list of supported machines
#
# Returns: a list of MachineInfo
#
# Since: 1.2.0
##
{ 'command': 'query-machines', 'returns': ['MachineInfo'] }
##
# @CpuDefinitionInfo:
#
# Virtual CPU definition.
#
# @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)
# @typename: Type name that can be used as argument to @device-list-properties,
# to introspect properties configurable using -cpu or -global.
# (since 2.9)
#
# @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', '*migration-safe': 'bool', 'static': 'bool',
'*unavailable-features': [ 'str' ], 'typename': 'str' } }
##
# @query-cpu-definitions:
#
# Return a list of supported virtual CPU definitions
#
# Returns: a list of CpuDefInfo
#
# Since: 1.2.0
##
{ '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.
#
# @fdset-id: The ID of the fd set that @fd was added to.
#
# @fd: The file descriptor that was received via SCM rights and
# added to the fd set.
#
# Since: 1.2.0
##
{ 'struct': 'AddfdInfo', 'data': {'fdset-id': 'int', 'fd': 'int'} }
##
# @add-fd:
#
# Add a file descriptor, that was passed via SCM rights, to an fd set.
#
# @fdset-id: #optional The ID of the fd set to add the file descriptor to.
#
# @opaque: #optional A free-form string that can be used to describe the fd.
#
# Returns: @AddfdInfo on success
#
# If file descriptor was not received, FdNotSupplied
#
# If @fdset-id is a negative value, InvalidParameterValue
#
# Notes: The list of fd sets is shared by all monitor connections.
#
# If @fdset-id is not specified, a new fd set will be created.
#
# Since: 1.2.0
#
# Example:
#
# -> { "execute": "add-fd", "arguments": { "fdset-id": 1 } }
# <- { "return": { "fdset-id": 1, "fd": 3 } }
#
##
{ 'command': 'add-fd', 'data': {'*fdset-id': 'int', '*opaque': 'str'},
'returns': 'AddfdInfo' }
##
# @remove-fd:
#
# Remove a file descriptor from an fd set.
#
# @fdset-id: The ID of the fd set that the file descriptor belongs to.
#
# @fd: #optional The file descriptor that is to be removed.
#
# Returns: Nothing on success
# If @fdset-id or @fd is not found, FdNotFound
#
# Since: 1.2.0
#
# Notes: The list of fd sets is shared by all monitor connections.
#
# If @fd is not specified, all file descriptors in @fdset-id
# will be removed.
#
# Example:
#
# -> { "execute": "remove-fd", "arguments": { "fdset-id": 1, "fd": 3 } }
# <- { "return": {} }
#
##
{ 'command': 'remove-fd', 'data': {'fdset-id': 'int', '*fd': 'int'} }
##
# @FdsetFdInfo:
#
# Information about a file descriptor that belongs to an fd set.
#
# @fd: The file descriptor value.
#
# @opaque: #optional A free-form string that can be used to describe the fd.
#
# Since: 1.2.0
##
{ 'struct': 'FdsetFdInfo',
'data': {'fd': 'int', '*opaque': 'str'} }
##
# @FdsetInfo:
#
# Information about an fd set.
#
# @fdset-id: The ID of the fd set.
#
# @fds: A list of file descriptors that belong to this fd set.
#
# Since: 1.2.0
##
{ 'struct': 'FdsetInfo',
'data': {'fdset-id': 'int', 'fds': ['FdsetFdInfo']} }
##
# @query-fdsets:
#
# Return information describing all fd sets.
#
# Returns: A list of @FdsetInfo
#
# Since: 1.2.0
#
# Note: The list of fd sets is shared by all monitor connections.
#
# Example:
#
# -> { "execute": "query-fdsets" }
# <- { "return": [
# {
# "fds": [
# {
# "fd": 30,
# "opaque": "rdonly:/path/to/file"
# },
# {
# "fd": 24,
# "opaque": "rdwr:/path/to/file"
# }
# ],
# "fdset-id": 1
# },
# {
# "fds": [
# {
# "fd": 28
# },
# {
# "fd": 29
# }
# ],
# "fdset-id": 0
# }
# ]
# }
#
##
{ 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
##
# @TargetInfo:
#
# Information describing the QEMU target.
#
# @arch: the target architecture (eg "x86_64", "i386", etc)
#
# Since: 1.2.0
##
{ 'struct': 'TargetInfo',
'data': { 'arch': 'str' } }
##
# @query-target:
#
# Return information about the target for this QEMU
#
# Returns: TargetInfo
#
# Since: 1.2.0
##
{ 'command': 'query-target', 'returns': 'TargetInfo' }
##
# @QKeyCode:
#
# An enumeration of key name.
#
# This is used by the @send-key command.
#
# @unmapped: since 2.0
# @pause: since 2.0
# @ro: since 2.4
# @kp_comma: since 2.4
# @kp_equals: since 2.6
# @power: since 2.6
# @hiragana: since 2.9
# @henkan: since 2.9
# @yen: since 2.9
#
# Since: 1.3.0
#
##
{ 'enum': 'QKeyCode',
'data': [ 'unmapped',
'shift', 'shift_r', 'alt', 'alt_r', 'altgr', 'altgr_r', 'ctrl',
'ctrl_r', 'menu', 'esc', '1', '2', '3', '4', '5', '6', '7', '8',
'9', '0', 'minus', 'equal', 'backspace', 'tab', 'q', 'w', 'e',
'r', 't', 'y', 'u', 'i', 'o', 'p', 'bracket_left', 'bracket_right',
'ret', 'a', 's', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'semicolon',
'apostrophe', 'grave_accent', 'backslash', 'z', 'x', 'c', 'v', 'b',
'n', 'm', 'comma', 'dot', 'slash', 'asterisk', 'spc', 'caps_lock',
'f1', 'f2', 'f3', 'f4', 'f5', 'f6', 'f7', 'f8', 'f9', 'f10',
'num_lock', 'scroll_lock', 'kp_divide', 'kp_multiply',
'kp_subtract', 'kp_add', 'kp_enter', 'kp_decimal', 'sysrq', 'kp_0',
'kp_1', 'kp_2', 'kp_3', 'kp_4', 'kp_5', 'kp_6', 'kp_7', 'kp_8',
'kp_9', 'less', 'f11', 'f12', 'print', 'home', 'pgup', 'pgdn', 'end',
'left', 'up', 'down', 'right', 'insert', 'delete', 'stop', 'again',
'props', 'undo', 'front', 'copy', 'open', 'paste', 'find', 'cut',
'lf', 'help', 'meta_l', 'meta_r', 'compose', 'pause',
'ro', 'hiragana', 'henkan', 'yen',
'kp_comma', 'kp_equals', 'power' ] }
##
# @KeyValue:
#
# Represents a keyboard key.
#
# Since: 1.3.0
##
{ 'union': 'KeyValue',
'data': {
'number': 'int',
'qcode': 'QKeyCode' } }
##
# @send-key:
#
# Send keys to guest.
#
# @keys: An array of @KeyValue elements. All @KeyValues in this array are
# simultaneously sent to the guest. A @KeyValue.number value is sent
# directly to the guest, while @KeyValue.qcode must be a valid
# @QKeyCode value
#
# @hold-time: #optional time to delay key up events, milliseconds. Defaults
# to 100
#
# Returns: Nothing on success
# If key is unknown or redundant, InvalidParameter
#
# Since: 1.3.0
#
# Example:
#
# -> { "execute": "send-key",
# "arguments": { "keys": [ { "type": "qcode", "data": "ctrl" },
# { "type": "qcode", "data": "alt" },
# { "type": "qcode", "data": "delete" } ] } }
# <- { "return": {} }
#
##
{ 'command': 'send-key',
'data': { 'keys': ['KeyValue'], '*hold-time': 'int' } }
##
# @screendump:
#
# Write a PPM of the VGA screen to a file.
#
# @filename: the path of a new PPM file to store the image
#
# Returns: Nothing on success
#
# Since: 0.14.0
#
# Example:
#
# -> { "execute": "screendump",
# "arguments": { "filename": "/tmp/image" } }
# <- { "return": {} }
#
##
{ 'command': 'screendump', 'data': {'filename': 'str'} }
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
##
# @ChardevCommon:
#
# Configuration shared across all chardev backends
#
# @logfile: #optional The name of a logfile to save output
# @logappend: #optional true to append instead of truncate
# (default to false to truncate)
#
# Since: 2.6
##
{ 'struct': 'ChardevCommon', 'data': { '*logfile': 'str',
'*logappend': 'bool' } }
##
# @ChardevFile:
#
# Configuration info for file chardevs.
#
# @in: #optional The name of the input file
# @out: The name of the output file
# @append: #optional Open the file in append mode (default false to
# truncate) (Since 2.6)
#
# Since: 1.4
##
{ 'struct': 'ChardevFile', 'data': { '*in' : 'str',
'out' : 'str',
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
'*append': 'bool' },
'base': 'ChardevCommon' }
##
# @ChardevHostdev:
#
# Configuration info for device and pipe chardevs.
#
# @device: The name of the special file for the device,
# i.e. /dev/ttyS0 on Unix or COM1: on Windows
#
# Since: 1.4
##
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
{ 'struct': 'ChardevHostdev', 'data': { 'device' : 'str' },
'base': 'ChardevCommon' }
##
# @ChardevSocket:
#
# Configuration info for (stream) socket chardevs.
#
# @addr: socket address to listen on (server=true)
# or connect to (server=false)
char: introduce support for TLS encrypted TCP chardev backend This integrates support for QIOChannelTLS object in the TCP chardev backend. If the 'tls-creds=NAME' option is passed with the '-chardev tcp' argument, then it will setup the chardev such that the client is required to establish a TLS handshake when connecting. There is no support for checking the client certificate against ACLs in this initial patch. This is pending work to QOM-ify the ACL object code. A complete invocation to run QEMU as the server for a TLS encrypted serial dev might be $ qemu-system-x86_64 \ -nodefconfig -nodefaults -device sga -display none \ -chardev socket,id=s0,host=127.0.0.1,port=9000,tls-creds=tls0,server \ -device isa-serial,chardev=s0 \ -object tls-creds-x509,id=tls0,endpoint=server,verify-peer=off,\ dir=/home/berrange/security/qemutls To test with the gnutls-cli tool as the client: $ gnutls-cli --priority=NORMAL -p 9000 \ --x509cafile=/home/berrange/security/qemutls/ca-cert.pem \ 127.0.0.1 If QEMU was told to use 'anon' credential type, then use the priority string 'NORMAL:+ANON-DH' with gnutls-cli Alternatively, if setting up a chardev to operate as a client, then the TLS credentials registered must be for the client endpoint. First a TLS server must be setup, which can be done with the gnutls-serv tool $ gnutls-serv --priority=NORMAL -p 9000 --echo \ --x509cafile=/home/berrange/security/qemutls/ca-cert.pem \ --x509certfile=/home/berrange/security/qemutls/server-cert.pem \ --x509keyfile=/home/berrange/security/qemutls/server-key.pem Then QEMU can connect with $ qemu-system-x86_64 \ -nodefconfig -nodefaults -device sga -display none \ -chardev socket,id=s0,host=127.0.0.1,port=9000,tls-creds=tls0 \ -device isa-serial,chardev=s0 \ -object tls-creds-x509,id=tls0,endpoint=client,\ dir=/home/berrange/security/qemutls Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1453202071-10289-5-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-19 14:14:31 +03:00
# @tls-creds: #optional the ID of the TLS credentials object (since 2.6)
# @server: #optional create server socket (default: true)
# @wait: #optional wait for incoming connection on server
# sockets (default: false).
# @nodelay: #optional set TCP_NODELAY socket option (default: false)
# @telnet: #optional enable telnet protocol on server
# sockets (default: false)
# @reconnect: #optional For a client socket, if a socket is disconnected,
# then attempt a reconnect after the given number of seconds.
# Setting this to zero disables this function. (default: 0)
# (Since: 2.2)
#
# Since: 1.4
##
{ 'struct': 'ChardevSocket', 'data': { 'addr' : 'SocketAddress',
char: introduce support for TLS encrypted TCP chardev backend This integrates support for QIOChannelTLS object in the TCP chardev backend. If the 'tls-creds=NAME' option is passed with the '-chardev tcp' argument, then it will setup the chardev such that the client is required to establish a TLS handshake when connecting. There is no support for checking the client certificate against ACLs in this initial patch. This is pending work to QOM-ify the ACL object code. A complete invocation to run QEMU as the server for a TLS encrypted serial dev might be $ qemu-system-x86_64 \ -nodefconfig -nodefaults -device sga -display none \ -chardev socket,id=s0,host=127.0.0.1,port=9000,tls-creds=tls0,server \ -device isa-serial,chardev=s0 \ -object tls-creds-x509,id=tls0,endpoint=server,verify-peer=off,\ dir=/home/berrange/security/qemutls To test with the gnutls-cli tool as the client: $ gnutls-cli --priority=NORMAL -p 9000 \ --x509cafile=/home/berrange/security/qemutls/ca-cert.pem \ 127.0.0.1 If QEMU was told to use 'anon' credential type, then use the priority string 'NORMAL:+ANON-DH' with gnutls-cli Alternatively, if setting up a chardev to operate as a client, then the TLS credentials registered must be for the client endpoint. First a TLS server must be setup, which can be done with the gnutls-serv tool $ gnutls-serv --priority=NORMAL -p 9000 --echo \ --x509cafile=/home/berrange/security/qemutls/ca-cert.pem \ --x509certfile=/home/berrange/security/qemutls/server-cert.pem \ --x509keyfile=/home/berrange/security/qemutls/server-key.pem Then QEMU can connect with $ qemu-system-x86_64 \ -nodefconfig -nodefaults -device sga -display none \ -chardev socket,id=s0,host=127.0.0.1,port=9000,tls-creds=tls0 \ -device isa-serial,chardev=s0 \ -object tls-creds-x509,id=tls0,endpoint=client,\ dir=/home/berrange/security/qemutls Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1453202071-10289-5-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-19 14:14:31 +03:00
'*tls-creds' : 'str',
'*server' : 'bool',
'*wait' : 'bool',
'*nodelay' : 'bool',
'*telnet' : 'bool',
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
'*reconnect' : 'int' },
'base': 'ChardevCommon' }
##
# @ChardevUdp:
#
# Configuration info for datagram socket chardevs.
#
# @remote: remote address
# @local: #optional local address
#
# Since: 1.5
##
{ 'struct': 'ChardevUdp', 'data': { 'remote' : 'SocketAddress',
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
'*local' : 'SocketAddress' },
'base': 'ChardevCommon' }
##
# @ChardevMux:
#
# Configuration info for mux chardevs.
#
# @chardev: name of the base chardev.
#
# Since: 1.5
##
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
{ 'struct': 'ChardevMux', 'data': { 'chardev' : 'str' },
'base': 'ChardevCommon' }
##
# @ChardevStdio:
#
# Configuration info for stdio chardevs.
#
# @signal: #optional Allow signals (such as SIGINT triggered by ^C)
# be delivered to qemu. Default: true in -nographic mode,
# false otherwise.
#
# Since: 1.5
##
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
{ 'struct': 'ChardevStdio', 'data': { '*signal' : 'bool' },
'base': 'ChardevCommon' }
##
# @ChardevSpiceChannel:
#
# Configuration info for spice vm channel chardevs.
#
# @type: kind of channel (for example vdagent).
#
# Since: 1.5
##
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
{ 'struct': 'ChardevSpiceChannel', 'data': { 'type' : 'str' },
'base': 'ChardevCommon' }
##
# @ChardevSpicePort:
#
# Configuration info for spice port chardevs.
#
# @fqdn: name of the channel (see docs/spice-port-fqdn.txt)
#
# Since: 1.5
##
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
{ 'struct': 'ChardevSpicePort', 'data': { 'fqdn' : 'str' },
'base': 'ChardevCommon' }
##
# @ChardevVC:
#
# Configuration info for virtual console chardevs.
#
# @width: console width, in pixels
# @height: console height, in pixels
# @cols: console width, in chars
# @rows: console height, in chars
#
# Since: 1.5
##
{ 'struct': 'ChardevVC', 'data': { '*width' : 'int',
'*height' : 'int',
'*cols' : 'int',
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
'*rows' : 'int' },
'base': 'ChardevCommon' }
##
Revert "chardev: Make the name of memory device consistent" This reverts commit 6a85e60cb994bd95d1537aafbff65816f3de4637. Commit 51767e7 "qemu-char: Add new char backend CirMemCharDriver" introduced a memory ring buffer character device driver named "memory". Commit 3949e59 "qemu-char: Saner naming of memchar stuff & doc fixes" changed the driver name to "ringbuf", along with a whole bunch of other names, with the following rationale: Naming is a mess. The code calls the device driver CirMemCharDriver, the public API calls it "memory", "memchardev", or "memchar", and the special commands are named like "memchar-FOO". "memory" is a particularly unfortunate choice, because there's another character device driver called MemoryDriver. Moreover, the device's distinctive property is that it's a ring buffer, not that's in memory. This is what we released in 1.4.0. Unfortunately, the rename missed a critical instance of "memory": the actual driver name. Thus, the new device could be used only by an entirely undocumented name. The documented name did not work. Bummer. Commit 6a85e60 fixes this by changing the documentation to match the code. It also changes some, but not all related occurences of "ringbuf" to "memory". Left alone are identifiers in C code, HMP and QMP commands. The latter are external interface, so they can't be changed. The result is an inconsistent mess. Moreover, "memory" is a rotten name. The device's distinctive property is that it's a ring buffer, not that's in memory. User's don't care whether it's in RAM, flash, or carved into chocolate tablets by Oompa Loompas. Revert the commit. Next commit will fix just the bug. Cc: qemu-stable@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1374849874-25531-2-git-send-email-armbru@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-26 18:44:32 +04:00
# @ChardevRingbuf:
#
# Configuration info for ring buffer chardevs.
#
# @size: #optional ring buffer size, must be power of two, default is 65536
#
# Since: 1.5
##
qemu-char: add logfile facility to all chardev backends Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11 15:44:41 +03:00
{ 'struct': 'ChardevRingbuf', 'data': { '*size' : 'int' },
'base': 'ChardevCommon' }
##
# @ChardevBackend:
#
# Configuration info for the new chardev backend.
#
# Since: 1.4 (testdev since 2.2)
##
{ 'union': 'ChardevBackend', 'data': { 'file' : 'ChardevFile',
'serial' : 'ChardevHostdev',
'parallel': 'ChardevHostdev',
'pipe' : 'ChardevHostdev',
'socket' : 'ChardevSocket',
'udp' : 'ChardevUdp',
'pty' : 'ChardevCommon',
'null' : 'ChardevCommon',
'mux' : 'ChardevMux',
'msmouse': 'ChardevCommon',
'braille': 'ChardevCommon',
'testdev': 'ChardevCommon',
'stdio' : 'ChardevStdio',
'console': 'ChardevCommon',
'spicevmc' : 'ChardevSpiceChannel',
'spiceport' : 'ChardevSpicePort',
'vc' : 'ChardevVC',
'ringbuf': 'ChardevRingbuf',
# next one is just for compatibility
Revert "chardev: Make the name of memory device consistent" This reverts commit 6a85e60cb994bd95d1537aafbff65816f3de4637. Commit 51767e7 "qemu-char: Add new char backend CirMemCharDriver" introduced a memory ring buffer character device driver named "memory". Commit 3949e59 "qemu-char: Saner naming of memchar stuff & doc fixes" changed the driver name to "ringbuf", along with a whole bunch of other names, with the following rationale: Naming is a mess. The code calls the device driver CirMemCharDriver, the public API calls it "memory", "memchardev", or "memchar", and the special commands are named like "memchar-FOO". "memory" is a particularly unfortunate choice, because there's another character device driver called MemoryDriver. Moreover, the device's distinctive property is that it's a ring buffer, not that's in memory. This is what we released in 1.4.0. Unfortunately, the rename missed a critical instance of "memory": the actual driver name. Thus, the new device could be used only by an entirely undocumented name. The documented name did not work. Bummer. Commit 6a85e60 fixes this by changing the documentation to match the code. It also changes some, but not all related occurences of "ringbuf" to "memory". Left alone are identifiers in C code, HMP and QMP commands. The latter are external interface, so they can't be changed. The result is an inconsistent mess. Moreover, "memory" is a rotten name. The device's distinctive property is that it's a ring buffer, not that's in memory. User's don't care whether it's in RAM, flash, or carved into chocolate tablets by Oompa Loompas. Revert the commit. Next commit will fix just the bug. Cc: qemu-stable@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1374849874-25531-2-git-send-email-armbru@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-26 18:44:32 +04:00
'memory' : 'ChardevRingbuf' } }
##
# @ChardevReturn:
#
# Return info about the chardev backend just created.
#
# @pty: #optional name of the slave pseudoterminal device, present if
# and only if a chardev of type 'pty' was created
#
# Since: 1.4
##
{ 'struct' : 'ChardevReturn', 'data': { '*pty' : 'str' } }
##
# @chardev-add:
#
# Add a character device backend
#
# @id: the chardev's ID, must be unique
# @backend: backend type and parameters
#
# Returns: ChardevReturn.
#
# Since: 1.4
#
# Example:
#
# -> { "execute" : "chardev-add",
# "arguments" : { "id" : "foo",
# "backend" : { "type" : "null", "data" : {} } } }
# <- { "return": {} }
#
# -> { "execute" : "chardev-add",
# "arguments" : { "id" : "bar",
# "backend" : { "type" : "file",
# "data" : { "out" : "/tmp/bar.log" } } } }
# <- { "return": {} }
#
# -> { "execute" : "chardev-add",
# "arguments" : { "id" : "baz",
# "backend" : { "type" : "pty", "data" : {} } } }
# <- { "return": { "pty" : "/dev/pty/42" } }
#
##
{ 'command': 'chardev-add', 'data': {'id' : 'str',
'backend' : 'ChardevBackend' },
'returns': 'ChardevReturn' }
##
# @chardev-remove:
#
# Remove a character device backend
#
# @id: the chardev's ID, must exist and not be in use
#
# Returns: Nothing on success
#
# Since: 1.4
#
# Example:
#
# -> { "execute": "chardev-remove", "arguments": { "id" : "foo" } }
# <- { "return": {} }
#
##
{ 'command': 'chardev-remove', 'data': {'id': 'str'} }
##
# @TpmModel:
#
# An enumeration of TPM models
#
# @tpm-tis: TPM TIS model
#
# Since: 1.5
##
{ 'enum': 'TpmModel', 'data': [ 'tpm-tis' ] }
##
# @query-tpm-models:
#
# Return a list of supported TPM models
#
# Returns: a list of TpmModel
#
# Since: 1.5
#
# Example:
#
# -> { "execute": "query-tpm-models" }
# <- { "return": [ "tpm-tis" ] }
#
##
{ 'command': 'query-tpm-models', 'returns': ['TpmModel'] }
##
# @TpmType:
#
# An enumeration of TPM types
#
# @passthrough: TPM passthrough type
#
# Since: 1.5
##
{ 'enum': 'TpmType', 'data': [ 'passthrough' ] }
##
# @query-tpm-types:
#
# Return a list of supported TPM types
#
# Returns: a list of TpmType
#
# Since: 1.5
#
# Example:
#
# -> { "execute": "query-tpm-types" }
# <- { "return": [ "passthrough" ] }
#
##
{ 'command': 'query-tpm-types', 'returns': ['TpmType'] }
##
# @TPMPassthroughOptions:
#
# Information about the TPM passthrough type
#
# @path: #optional string describing the path used for accessing the TPM device
#
# @cancel-path: #optional string showing the TPM's sysfs cancel file
# for cancellation of TPM commands while they are executing
#
# Since: 1.5
##
{ 'struct': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
'*cancel-path' : 'str'} }
##
# @TpmTypeOptions:
#
# A union referencing different TPM backend types' configuration options
#
# @type: 'passthrough' The configuration options for the TPM passthrough type
#
# Since: 1.5
##
{ 'union': 'TpmTypeOptions',
'data': { 'passthrough' : 'TPMPassthroughOptions' } }
##
# @TPMInfo:
#
# Information about the TPM
#
# @id: The Id of the TPM
#
# @model: The TPM frontend model
#
# @options: The TPM (backend) type configuration options
#
# Since: 1.5
##
{ 'struct': 'TPMInfo',
'data': {'id': 'str',
'model': 'TpmModel',
'options': 'TpmTypeOptions' } }
##
# @query-tpm:
#
# Return information about the TPM device
#
# Returns: @TPMInfo on success
#
# Since: 1.5
#
# Example:
#
# -> { "execute": "query-tpm" }
# <- { "return":
# [
# { "model": "tpm-tis",
# "options":
# { "type": "passthrough",
# "data":
# { "cancel-path": "/sys/class/misc/tpm0/device/cancel",
# "path": "/dev/tpm0"
# }
# },
# "id": "tpm0"
# }
# ]
# }
#
##
{ 'command': 'query-tpm', 'returns': ['TPMInfo'] }
##
# @AcpiTableOptions:
#
# Specify an ACPI table on the command line to load.
#
# At most one of @file and @data can be specified. The list of files specified
# by any one of them is loaded and concatenated in order. If both are omitted,
# @data is implied.
#
# Other fields / optargs can be used to override fields of the generic ACPI
# table header; refer to the ACPI specification 5.0, section 5.2.6 System
# Description Table Header. If a header field is not overridden, then the
# corresponding value from the concatenated blob is used (in case of @file), or
# it is filled in with a hard-coded value (in case of @data).
#
# String fields are copied into the matching ACPI member from lowest address
# upwards, and silently truncated / NUL-padded to length.
#
# @sig: #optional table signature / identifier (4 bytes)
#
# @rev: #optional table revision number (dependent on signature, 1 byte)
#
# @oem_id: #optional OEM identifier (6 bytes)
#
# @oem_table_id: #optional OEM table identifier (8 bytes)
#
# @oem_rev: #optional OEM-supplied revision number (4 bytes)
#
# @asl_compiler_id: #optional identifier of the utility that created the table
# (4 bytes)
#
# @asl_compiler_rev: #optional revision number of the utility that created the
# table (4 bytes)
#
# @file: #optional colon (:) separated list of pathnames to load and
# concatenate as table data. The resultant binary blob is expected to
# have an ACPI table header. At least one file is required. This field
# excludes @data.
#
# @data: #optional colon (:) separated list of pathnames to load and
# concatenate as table data. The resultant binary blob must not have an
# ACPI table header. At least one file is required. This field excludes
# @file.
#
# Since: 1.5
##
{ 'struct': 'AcpiTableOptions',
'data': {
'*sig': 'str',
'*rev': 'uint8',
'*oem_id': 'str',
'*oem_table_id': 'str',
'*oem_rev': 'uint32',
'*asl_compiler_id': 'str',
'*asl_compiler_rev': 'uint32',
'*file': 'str',
'*data': 'str' }}
##
# @CommandLineParameterType:
#
# Possible types for an option parameter.
#
# @string: accepts a character string
#
# @boolean: accepts "on" or "off"
#
# @number: accepts a number
#
# @size: accepts a number followed by an optional suffix (K)ilo,
# (M)ega, (G)iga, (T)era
#
# Since: 1.5
##
{ 'enum': 'CommandLineParameterType',
'data': ['string', 'boolean', 'number', 'size'] }
##
# @CommandLineParameterInfo:
#
# Details about a single parameter of a command line option.
#
# @name: parameter name
#
# @type: parameter @CommandLineParameterType
#
# @help: #optional human readable text string, not suitable for parsing.
#
# @default: #optional default value string (since 2.1)
#
# Since: 1.5
##
{ 'struct': 'CommandLineParameterInfo',
'data': { 'name': 'str',
'type': 'CommandLineParameterType',
'*help': 'str',
'*default': 'str' } }
##
# @CommandLineOptionInfo:
#
# Details about a command line option, including its list of parameter details
#
# @option: option name
#
# @parameters: an array of @CommandLineParameterInfo
#
# Since: 1.5
##
{ 'struct': 'CommandLineOptionInfo',
'data': { 'option': 'str', 'parameters': ['CommandLineParameterInfo'] } }
##
# @query-command-line-options:
#
# Query command line option schema.
#
# @option: #optional option name
#
# Returns: list of @CommandLineOptionInfo for all options (or for the given
# @option). Returns an error if the given @option doesn't exist.
#
# Since: 1.5
#
# Example:
#
# -> { "execute": "query-command-line-options",
# "arguments": { "option": "option-rom" } }
# <- { "return": [
# {
# "parameters": [
# {
# "name": "romfile",
# "type": "string"
# },
# {
# "name": "bootindex",
# "type": "number"
# }
# ],
# "option": "option-rom"
# }
# ]
# }
#
##
{'command': 'query-command-line-options', 'data': { '*option': 'str' },
'returns': ['CommandLineOptionInfo'] }
##
# @X86CPURegister32:
#
# A X86 32-bit register
#
# Since: 1.5
##
{ 'enum': 'X86CPURegister32',
'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] }
##
# @X86CPUFeatureWordInfo:
#
# Information about a X86 CPU feature word
#
# @cpuid-input-eax: Input EAX value for CPUID instruction for that feature word
#
# @cpuid-input-ecx: #optional Input ECX value for CPUID instruction for that
# feature word
#
# @cpuid-register: Output register containing the feature bits
#
# @features: value of output register, containing the feature bits
#
# Since: 1.5
##
{ 'struct': 'X86CPUFeatureWordInfo',
'data': { 'cpuid-input-eax': 'int',
'*cpuid-input-ecx': 'int',
'cpuid-register': 'X86CPURegister32',
'features': 'int' } }
net: add support of mac-programming over macvtap in QEMU side Currently macvtap based macvlan device is working in promiscuous mode, we want to implement mac-programming over macvtap through Libvirt for better performance. Design: QEMU notifies Libvirt when rx-filter config is changed in guest, then Libvirt query the rx-filter information by a monitor command, and sync the change to macvtap device. Related rx-filter config of the nic contains main mac, rx-mode items and vlan table. This patch adds a QMP event to notify management of rx-filter change, and adds a monitor command for management to query rx-filter information. Test: If we repeatedly add/remove vlan, and change macaddr of vlan interfaces in guest by a loop script. Result: The events will flood the QMP client(management), management takes too much resource to process the events. Event_throttle API (set rate to 1 ms) can avoid the events to flood QMP client, but it could cause an unexpected delay (~1ms), guests guests normally expect rx-filter updates immediately. So we use a flag for each nic to avoid events flooding, the event is emitted once until the query command is executed. The flag implementation could not introduce unexpected delay. There maybe exist an uncontrollable delay if we let Libvirt do the real change, guests normally expect rx-filter updates immediately. But it's another separate issue, we can investigate it when the work in Libvirt side is done. Michael S. Tsirkin: tweaked to enable events on start Michael S. Tsirkin: fixed not to crash when no id Michael S. Tsirkin: fold in patch: "additional fixes for mac-programming feature" Amos Kong: always notify QMP client if mactable is changed Amos Kong: return NULL list if no net client supports rx-filter query Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amos Kong <akong@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-14 11:45:52 +04:00
qapi: Lazy creation of array types Commit ac88219a had several TODO markers about whether we needed to automatically create the corresponding array type alongside any other type. It turns out that most of the time, we don't! There are a few exceptions: 1) We have a few situations where we use an array type in internal code but do not expose that type through QMP; fix it by declaring a dummy type that forces the generator to see that we want to use the array type. 2) The builtin arrays (such as intList for QAPI ['int']) must always be generated, because of the way our QAPI_TYPES_BUILTIN compile guard works: we have situations (at the very least tests/test-qmp-output-visitor.c) that include both top-level "qapi-types.h" (via "error.h") and a secondary "test-qapi-types.h". If we were to only emit the builtin types when used locally, then the first .h file would not include all types, but the second .h does not declare anything at all because the first .h set QAPI_TYPES_BUILTIN, and we would end up with compilation error due to things like unknown type 'int8List'. Actually, we may need to revisit how we do type guards, and change from a single QAPI_TYPES_BUILTIN over to a different usage pattern that does one #ifdef per qapi type - right now, the only types that are declared multiple times between two qapi .json files for inclusion by a single .c file happen to be the builtin arrays. But now that we have QAPI 'include' statements, it is logical to assume that we will soon reach a point where we want to reuse non-builtin types (yes, I'm thinking about what it will take to add introspection to QGA, where we will want to reuse the SchemaInfo type and friends). One #ifdef per type will help ensure that generating the same qapi type into more than one qapi-types.h won't cause collisions when both are included in the same .c file; but we also have to solve how to avoid creating duplicate qapi-types.c entry points. So that is a problem left for another day. Generated code for qapi-types and qapi-visit is drastically reduced; less than a third of the arrays that were blindly created were actually needed (a quick grep shows we dropped from 219 to 69 *List types), and the .o files lost more than 30% of their bulk. [For best results, diff the generated files with 'git diff --patience --no-index pre post'.] Interestingly, the introspection output is unchanged - this is because we already cull all types that are not indirectly reachable from a command or event, so introspection was already using only a subset of array types. The subset of types introspected is now a much larger percentage of the overall set of array types emitted in qapi-types.h (since the larger set shrunk), but still not 100% (evidence that the array types emitted for our new Dummy structs, and the new struct itself, don't affect QMP). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1444710158-8723-9-git-send-email-eblake@redhat.com> [Moved array info tracking to a later patch] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-13 07:22:28 +03:00
##
# @DummyForceArrays:
qapi: Lazy creation of array types Commit ac88219a had several TODO markers about whether we needed to automatically create the corresponding array type alongside any other type. It turns out that most of the time, we don't! There are a few exceptions: 1) We have a few situations where we use an array type in internal code but do not expose that type through QMP; fix it by declaring a dummy type that forces the generator to see that we want to use the array type. 2) The builtin arrays (such as intList for QAPI ['int']) must always be generated, because of the way our QAPI_TYPES_BUILTIN compile guard works: we have situations (at the very least tests/test-qmp-output-visitor.c) that include both top-level "qapi-types.h" (via "error.h") and a secondary "test-qapi-types.h". If we were to only emit the builtin types when used locally, then the first .h file would not include all types, but the second .h does not declare anything at all because the first .h set QAPI_TYPES_BUILTIN, and we would end up with compilation error due to things like unknown type 'int8List'. Actually, we may need to revisit how we do type guards, and change from a single QAPI_TYPES_BUILTIN over to a different usage pattern that does one #ifdef per qapi type - right now, the only types that are declared multiple times between two qapi .json files for inclusion by a single .c file happen to be the builtin arrays. But now that we have QAPI 'include' statements, it is logical to assume that we will soon reach a point where we want to reuse non-builtin types (yes, I'm thinking about what it will take to add introspection to QGA, where we will want to reuse the SchemaInfo type and friends). One #ifdef per type will help ensure that generating the same qapi type into more than one qapi-types.h won't cause collisions when both are included in the same .c file; but we also have to solve how to avoid creating duplicate qapi-types.c entry points. So that is a problem left for another day. Generated code for qapi-types and qapi-visit is drastically reduced; less than a third of the arrays that were blindly created were actually needed (a quick grep shows we dropped from 219 to 69 *List types), and the .o files lost more than 30% of their bulk. [For best results, diff the generated files with 'git diff --patience --no-index pre post'.] Interestingly, the introspection output is unchanged - this is because we already cull all types that are not indirectly reachable from a command or event, so introspection was already using only a subset of array types. The subset of types introspected is now a much larger percentage of the overall set of array types emitted in qapi-types.h (since the larger set shrunk), but still not 100% (evidence that the array types emitted for our new Dummy structs, and the new struct itself, don't affect QMP). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1444710158-8723-9-git-send-email-eblake@redhat.com> [Moved array info tracking to a later patch] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-13 07:22:28 +03:00
#
# Not used by QMP; hack to let us use X86CPUFeatureWordInfoList internally
#
# Since: 2.5
qapi: Lazy creation of array types Commit ac88219a had several TODO markers about whether we needed to automatically create the corresponding array type alongside any other type. It turns out that most of the time, we don't! There are a few exceptions: 1) We have a few situations where we use an array type in internal code but do not expose that type through QMP; fix it by declaring a dummy type that forces the generator to see that we want to use the array type. 2) The builtin arrays (such as intList for QAPI ['int']) must always be generated, because of the way our QAPI_TYPES_BUILTIN compile guard works: we have situations (at the very least tests/test-qmp-output-visitor.c) that include both top-level "qapi-types.h" (via "error.h") and a secondary "test-qapi-types.h". If we were to only emit the builtin types when used locally, then the first .h file would not include all types, but the second .h does not declare anything at all because the first .h set QAPI_TYPES_BUILTIN, and we would end up with compilation error due to things like unknown type 'int8List'. Actually, we may need to revisit how we do type guards, and change from a single QAPI_TYPES_BUILTIN over to a different usage pattern that does one #ifdef per qapi type - right now, the only types that are declared multiple times between two qapi .json files for inclusion by a single .c file happen to be the builtin arrays. But now that we have QAPI 'include' statements, it is logical to assume that we will soon reach a point where we want to reuse non-builtin types (yes, I'm thinking about what it will take to add introspection to QGA, where we will want to reuse the SchemaInfo type and friends). One #ifdef per type will help ensure that generating the same qapi type into more than one qapi-types.h won't cause collisions when both are included in the same .c file; but we also have to solve how to avoid creating duplicate qapi-types.c entry points. So that is a problem left for another day. Generated code for qapi-types and qapi-visit is drastically reduced; less than a third of the arrays that were blindly created were actually needed (a quick grep shows we dropped from 219 to 69 *List types), and the .o files lost more than 30% of their bulk. [For best results, diff the generated files with 'git diff --patience --no-index pre post'.] Interestingly, the introspection output is unchanged - this is because we already cull all types that are not indirectly reachable from a command or event, so introspection was already using only a subset of array types. The subset of types introspected is now a much larger percentage of the overall set of array types emitted in qapi-types.h (since the larger set shrunk), but still not 100% (evidence that the array types emitted for our new Dummy structs, and the new struct itself, don't affect QMP). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1444710158-8723-9-git-send-email-eblake@redhat.com> [Moved array info tracking to a later patch] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-13 07:22:28 +03:00
##
{ 'struct': 'DummyForceArrays',
'data': { 'unused': ['X86CPUFeatureWordInfo'] } }
net: add support of mac-programming over macvtap in QEMU side Currently macvtap based macvlan device is working in promiscuous mode, we want to implement mac-programming over macvtap through Libvirt for better performance. Design: QEMU notifies Libvirt when rx-filter config is changed in guest, then Libvirt query the rx-filter information by a monitor command, and sync the change to macvtap device. Related rx-filter config of the nic contains main mac, rx-mode items and vlan table. This patch adds a QMP event to notify management of rx-filter change, and adds a monitor command for management to query rx-filter information. Test: If we repeatedly add/remove vlan, and change macaddr of vlan interfaces in guest by a loop script. Result: The events will flood the QMP client(management), management takes too much resource to process the events. Event_throttle API (set rate to 1 ms) can avoid the events to flood QMP client, but it could cause an unexpected delay (~1ms), guests guests normally expect rx-filter updates immediately. So we use a flag for each nic to avoid events flooding, the event is emitted once until the query command is executed. The flag implementation could not introduce unexpected delay. There maybe exist an uncontrollable delay if we let Libvirt do the real change, guests normally expect rx-filter updates immediately. But it's another separate issue, we can investigate it when the work in Libvirt side is done. Michael S. Tsirkin: tweaked to enable events on start Michael S. Tsirkin: fixed not to crash when no id Michael S. Tsirkin: fold in patch: "additional fixes for mac-programming feature" Amos Kong: always notify QMP client if mactable is changed Amos Kong: return NULL list if no net client supports rx-filter query Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amos Kong <akong@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-14 11:45:52 +04:00
##
# @RxState:
#
# Packets receiving state
#
# @normal: filter assigned packets according to the mac-table
#
# @none: don't receive any assigned packet
#
# @all: receive all assigned packets
#
# Since: 1.6
##
{ 'enum': 'RxState', 'data': [ 'normal', 'none', 'all' ] }
##
# @RxFilterInfo:
#
# Rx-filter information for a NIC.
#
# @name: net client name
#
# @promiscuous: whether promiscuous mode is enabled
#
# @multicast: multicast receive state
#
# @unicast: unicast receive state
#
# @vlan: vlan receive state (Since 2.0)
#
net: add support of mac-programming over macvtap in QEMU side Currently macvtap based macvlan device is working in promiscuous mode, we want to implement mac-programming over macvtap through Libvirt for better performance. Design: QEMU notifies Libvirt when rx-filter config is changed in guest, then Libvirt query the rx-filter information by a monitor command, and sync the change to macvtap device. Related rx-filter config of the nic contains main mac, rx-mode items and vlan table. This patch adds a QMP event to notify management of rx-filter change, and adds a monitor command for management to query rx-filter information. Test: If we repeatedly add/remove vlan, and change macaddr of vlan interfaces in guest by a loop script. Result: The events will flood the QMP client(management), management takes too much resource to process the events. Event_throttle API (set rate to 1 ms) can avoid the events to flood QMP client, but it could cause an unexpected delay (~1ms), guests guests normally expect rx-filter updates immediately. So we use a flag for each nic to avoid events flooding, the event is emitted once until the query command is executed. The flag implementation could not introduce unexpected delay. There maybe exist an uncontrollable delay if we let Libvirt do the real change, guests normally expect rx-filter updates immediately. But it's another separate issue, we can investigate it when the work in Libvirt side is done. Michael S. Tsirkin: tweaked to enable events on start Michael S. Tsirkin: fixed not to crash when no id Michael S. Tsirkin: fold in patch: "additional fixes for mac-programming feature" Amos Kong: always notify QMP client if mactable is changed Amos Kong: return NULL list if no net client supports rx-filter query Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amos Kong <akong@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-14 11:45:52 +04:00
# @broadcast-allowed: whether to receive broadcast
#
# @multicast-overflow: multicast table is overflowed or not
#
# @unicast-overflow: unicast table is overflowed or not
#
# @main-mac: the main macaddr string
#
# @vlan-table: a list of active vlan id
#
# @unicast-table: a list of unicast macaddr string
#
# @multicast-table: a list of multicast macaddr string
#
# Since: 1.6
net: add support of mac-programming over macvtap in QEMU side Currently macvtap based macvlan device is working in promiscuous mode, we want to implement mac-programming over macvtap through Libvirt for better performance. Design: QEMU notifies Libvirt when rx-filter config is changed in guest, then Libvirt query the rx-filter information by a monitor command, and sync the change to macvtap device. Related rx-filter config of the nic contains main mac, rx-mode items and vlan table. This patch adds a QMP event to notify management of rx-filter change, and adds a monitor command for management to query rx-filter information. Test: If we repeatedly add/remove vlan, and change macaddr of vlan interfaces in guest by a loop script. Result: The events will flood the QMP client(management), management takes too much resource to process the events. Event_throttle API (set rate to 1 ms) can avoid the events to flood QMP client, but it could cause an unexpected delay (~1ms), guests guests normally expect rx-filter updates immediately. So we use a flag for each nic to avoid events flooding, the event is emitted once until the query command is executed. The flag implementation could not introduce unexpected delay. There maybe exist an uncontrollable delay if we let Libvirt do the real change, guests normally expect rx-filter updates immediately. But it's another separate issue, we can investigate it when the work in Libvirt side is done. Michael S. Tsirkin: tweaked to enable events on start Michael S. Tsirkin: fixed not to crash when no id Michael S. Tsirkin: fold in patch: "additional fixes for mac-programming feature" Amos Kong: always notify QMP client if mactable is changed Amos Kong: return NULL list if no net client supports rx-filter query Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amos Kong <akong@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-14 11:45:52 +04:00
##
{ 'struct': 'RxFilterInfo',
net: add support of mac-programming over macvtap in QEMU side Currently macvtap based macvlan device is working in promiscuous mode, we want to implement mac-programming over macvtap through Libvirt for better performance. Design: QEMU notifies Libvirt when rx-filter config is changed in guest, then Libvirt query the rx-filter information by a monitor command, and sync the change to macvtap device. Related rx-filter config of the nic contains main mac, rx-mode items and vlan table. This patch adds a QMP event to notify management of rx-filter change, and adds a monitor command for management to query rx-filter information. Test: If we repeatedly add/remove vlan, and change macaddr of vlan interfaces in guest by a loop script. Result: The events will flood the QMP client(management), management takes too much resource to process the events. Event_throttle API (set rate to 1 ms) can avoid the events to flood QMP client, but it could cause an unexpected delay (~1ms), guests guests normally expect rx-filter updates immediately. So we use a flag for each nic to avoid events flooding, the event is emitted once until the query command is executed. The flag implementation could not introduce unexpected delay. There maybe exist an uncontrollable delay if we let Libvirt do the real change, guests normally expect rx-filter updates immediately. But it's another separate issue, we can investigate it when the work in Libvirt side is done. Michael S. Tsirkin: tweaked to enable events on start Michael S. Tsirkin: fixed not to crash when no id Michael S. Tsirkin: fold in patch: "additional fixes for mac-programming feature" Amos Kong: always notify QMP client if mactable is changed Amos Kong: return NULL list if no net client supports rx-filter query Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amos Kong <akong@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-14 11:45:52 +04:00
'data': {
'name': 'str',
'promiscuous': 'bool',
'multicast': 'RxState',
'unicast': 'RxState',
'vlan': 'RxState',
net: add support of mac-programming over macvtap in QEMU side Currently macvtap based macvlan device is working in promiscuous mode, we want to implement mac-programming over macvtap through Libvirt for better performance. Design: QEMU notifies Libvirt when rx-filter config is changed in guest, then Libvirt query the rx-filter information by a monitor command, and sync the change to macvtap device. Related rx-filter config of the nic contains main mac, rx-mode items and vlan table. This patch adds a QMP event to notify management of rx-filter change, and adds a monitor command for management to query rx-filter information. Test: If we repeatedly add/remove vlan, and change macaddr of vlan interfaces in guest by a loop script. Result: The events will flood the QMP client(management), management takes too much resource to process the events. Event_throttle API (set rate to 1 ms) can avoid the events to flood QMP client, but it could cause an unexpected delay (~1ms), guests guests normally expect rx-filter updates immediately. So we use a flag for each nic to avoid events flooding, the event is emitted once until the query command is executed. The flag implementation could not introduce unexpected delay. There maybe exist an uncontrollable delay if we let Libvirt do the real change, guests normally expect rx-filter updates immediately. But it's another separate issue, we can investigate it when the work in Libvirt side is done. Michael S. Tsirkin: tweaked to enable events on start Michael S. Tsirkin: fixed not to crash when no id Michael S. Tsirkin: fold in patch: "additional fixes for mac-programming feature" Amos Kong: always notify QMP client if mactable is changed Amos Kong: return NULL list if no net client supports rx-filter query Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amos Kong <akong@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-14 11:45:52 +04:00
'broadcast-allowed': 'bool',
'multicast-overflow': 'bool',
'unicast-overflow': 'bool',
'main-mac': 'str',
'vlan-table': ['int'],
'unicast-table': ['str'],
'multicast-table': ['str'] }}
##
# @query-rx-filter:
#
# Return rx-filter information for all NICs (or for the given NIC).
#
# @name: #optional net client name
#
# Returns: list of @RxFilterInfo for all NICs (or for the given NIC).
# Returns an error if the given @name doesn't exist, or given
# NIC doesn't support rx-filter querying, or given net client
# isn't a NIC.
#
# Since: 1.6
#
# Example:
#
# -> { "execute": "query-rx-filter", "arguments": { "name": "vnet0" } }
# <- { "return": [
# {
# "promiscuous": true,
# "name": "vnet0",
# "main-mac": "52:54:00:12:34:56",
# "unicast": "normal",
# "vlan": "normal",
# "vlan-table": [
# 4,
# 0
# ],
# "unicast-table": [
# ],
# "multicast": "normal",
# "multicast-overflow": false,
# "unicast-overflow": false,
# "multicast-table": [
# "01:00:5e:00:00:01",
# "33:33:00:00:00:01",
# "33:33:ff:12:34:56"
# ],
# "broadcast-allowed": false
# }
# ]
# }
#
net: add support of mac-programming over macvtap in QEMU side Currently macvtap based macvlan device is working in promiscuous mode, we want to implement mac-programming over macvtap through Libvirt for better performance. Design: QEMU notifies Libvirt when rx-filter config is changed in guest, then Libvirt query the rx-filter information by a monitor command, and sync the change to macvtap device. Related rx-filter config of the nic contains main mac, rx-mode items and vlan table. This patch adds a QMP event to notify management of rx-filter change, and adds a monitor command for management to query rx-filter information. Test: If we repeatedly add/remove vlan, and change macaddr of vlan interfaces in guest by a loop script. Result: The events will flood the QMP client(management), management takes too much resource to process the events. Event_throttle API (set rate to 1 ms) can avoid the events to flood QMP client, but it could cause an unexpected delay (~1ms), guests guests normally expect rx-filter updates immediately. So we use a flag for each nic to avoid events flooding, the event is emitted once until the query command is executed. The flag implementation could not introduce unexpected delay. There maybe exist an uncontrollable delay if we let Libvirt do the real change, guests normally expect rx-filter updates immediately. But it's another separate issue, we can investigate it when the work in Libvirt side is done. Michael S. Tsirkin: tweaked to enable events on start Michael S. Tsirkin: fixed not to crash when no id Michael S. Tsirkin: fold in patch: "additional fixes for mac-programming feature" Amos Kong: always notify QMP client if mactable is changed Amos Kong: return NULL list if no net client supports rx-filter query Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amos Kong <akong@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-14 11:45:52 +04:00
##
{ 'command': 'query-rx-filter', 'data': { '*name': 'str' },
'returns': ['RxFilterInfo'] }
##
# @InputButton:
#
# Button of a pointer input device (mouse, tablet).
#
# Since: 2.0
##
{ 'enum' : 'InputButton',
'data' : [ 'left', 'middle', 'right', 'wheel-up', 'wheel-down' ] }
##
# @InputAxis:
#
# Position axis of a pointer input device (mouse, tablet).
#
# Since: 2.0
##
{ 'enum' : 'InputAxis',
'data' : [ 'x', 'y' ] }
##
# @InputKeyEvent:
#
# Keyboard input event.
#
# @key: Which key this event is for.
# @down: True for key-down and false for key-up events.
#
# Since: 2.0
##
{ 'struct' : 'InputKeyEvent',
'data' : { 'key' : 'KeyValue',
'down' : 'bool' } }
##
# @InputBtnEvent:
#
# Pointer button input event.
#
# @button: Which button this event is for.
# @down: True for key-down and false for key-up events.
#
# Since: 2.0
##
{ 'struct' : 'InputBtnEvent',
'data' : { 'button' : 'InputButton',
'down' : 'bool' } }
##
# @InputMoveEvent:
#
# Pointer motion input event.
#
# @axis: Which axis is referenced by @value.
# @value: Pointer position. For absolute coordinates the
# valid range is 0 -> 0x7ffff
#
# Since: 2.0
##
{ 'struct' : 'InputMoveEvent',
'data' : { 'axis' : 'InputAxis',
'value' : 'int' } }
##
# @InputEvent:
#
# Input event union.
#
# @type: the input type, one of:
# - 'key': Input event of Keyboard
# - 'btn': Input event of pointer buttons
# - 'rel': Input event of relative pointer motion
# - 'abs': Input event of absolute pointer motion
#
# Since: 2.0
##
{ 'union' : 'InputEvent',
'data' : { 'key' : 'InputKeyEvent',
'btn' : 'InputBtnEvent',
'rel' : 'InputMoveEvent',
'abs' : 'InputMoveEvent' } }
##
# @input-send-event:
#
# Send input event(s) to guest.
#
# @device: #optional display device to send event(s) to.
# @head: #optional head to send event(s) to, in case the
# display device supports multiple scanouts.
# @events: List of InputEvent union.
#
# Returns: Nothing on success.
#
# The @device and @head parameters can be used to send the input event
# to specific input devices in case (a) multiple input devices of the
# same kind are added to the virtual machine and (b) you have
# configured input routing (see docs/multiseat.txt) for those input
# devices. The parameters work exactly like the device and head
# properties of input devices. If @device is missing, only devices
# that have no input routing config are admissible. If @device is
# specified, both input devices with and without input routing config
# are admissible, but devices with input routing config take
# precedence.
#
# Since: 2.6
#
# Note: The consoles are visible in the qom tree, under
# /backend/console[$index]. They have a device link and head property,
# so it is possible to map which console belongs to which device and
# display.
#
# Example:
#
# 1. Press left mouse button.
#
# -> { "execute": "input-send-event",
# "arguments": { "device": "video0",
# "events": [ { "type": "btn",
# "data" : { "down": true, "button": "left" } } ] } }
# <- { "return": {} }
#
# -> { "execute": "input-send-event",
# "arguments": { "device": "video0",
# "events": [ { "type": "btn",
# "data" : { "down": false, "button": "left" } } ] } }
# <- { "return": {} }
#
# 2. Press ctrl-alt-del.
#
# -> { "execute": "input-send-event",
# "arguments": { "events": [
# { "type": "key", "data" : { "down": true,
# "key": {"type": "qcode", "data": "ctrl" } } },
# { "type": "key", "data" : { "down": true,
# "key": {"type": "qcode", "data": "alt" } } },
# { "type": "key", "data" : { "down": true,
# "key": {"type": "qcode", "data": "delete" } } } ] } }
# <- { "return": {} }
#
# 3. Move mouse pointer to absolute coordinates (20000, 400).
#
# -> { "execute": "input-send-event" ,
# "arguments": { "events": [
# { "type": "abs", "data" : { "axis": "x", "value" : 20000 } },
# { "type": "abs", "data" : { "axis": "y", "value" : 400 } } ] } }
# <- { "return": {} }
#
##
{ 'command': 'input-send-event',
'data': { '*device': 'str',
'*head' : 'int',
'events' : [ 'InputEvent' ] } }
##
# @NumaOptions:
#
# A discriminated record of NUMA options. (for OptsVisitor)
#
# Since: 2.1
##
{ 'union': 'NumaOptions',
'data': {
'node': 'NumaNodeOptions' }}
##
# @NumaNodeOptions:
#
# Create a guest NUMA node. (for OptsVisitor)
#
# @nodeid: #optional NUMA node ID (increase by 1 from 0 if omitted)
#
# @cpus: #optional VCPUs belonging to this node (assign VCPUS round-robin
# if omitted)
#
# @mem: #optional memory size of this node; mutually exclusive with @memdev.
# Equally divide total memory among nodes if both @mem and @memdev are
# omitted.
#
# @memdev: #optional memory backend object. If specified for one node,
# it must be specified for all nodes.
#
# Since: 2.1
##
{ 'struct': 'NumaNodeOptions',
'data': {
'*nodeid': 'uint16',
'*cpus': ['uint16'],
'*mem': 'size',
'*memdev': 'str' }}
##
# @HostMemPolicy:
#
# Host memory policy types
#
# @default: restore default policy, remove any nondefault policy
#
# @preferred: set the preferred host nodes for allocation
#
# @bind: a strict policy that restricts memory allocation to the
# host nodes specified
#
# @interleave: memory allocations are interleaved across the set
# of host nodes specified
#
# Since: 2.1
##
{ 'enum': 'HostMemPolicy',
'data': [ 'default', 'preferred', 'bind', 'interleave' ] }
##
# @Memdev:
#
# Information about memory backend
#
# @id: #optional backend's ID if backend has 'id' property (since 2.9)
#
# @size: memory backend size
#
# @merge: enables or disables memory merge support
#
# @dump: includes memory backend's memory in a core dump or not
#
# @prealloc: enables or disables memory preallocation
#
# @host-nodes: host nodes for its memory policy
#
# @policy: memory policy of memory backend
#
# Since: 2.1
##
{ 'struct': 'Memdev',
'data': {
'*id': 'str',
'size': 'size',
'merge': 'bool',
'dump': 'bool',
'prealloc': 'bool',
'host-nodes': ['uint16'],
'policy': 'HostMemPolicy' }}
##
# @query-memdev:
#
# Returns information for all memory backends.
#
# Returns: a list of @Memdev.
#
# Since: 2.1
#
# Example:
#
# -> { "execute": "query-memdev" }
# <- { "return": [
# {
# "id": "mem1",
# "size": 536870912,
# "merge": false,
# "dump": true,
# "prealloc": false,
# "host-nodes": [0, 1],
# "policy": "bind"
# },
# {
# "size": 536870912,
# "merge": false,
# "dump": true,
# "prealloc": true,
# "host-nodes": [2, 3],
# "policy": "preferred"
# }
# ]
# }
#
##
{ 'command': 'query-memdev', 'returns': ['Memdev'] }
##
# @PCDIMMDeviceInfo:
#
# PCDIMMDevice state information
#
# @id: #optional device's ID
#
# @addr: physical address, where device is mapped
#
# @size: size of memory that the device provides
#
# @slot: slot number at which device is plugged in
#
# @node: NUMA node number where device is plugged in
#
# @memdev: memory backend linked with device
#
# @hotplugged: true if device was hotplugged
#
# @hotpluggable: true if device if could be added/removed while machine is running
#
# Since: 2.1
##
{ 'struct': 'PCDIMMDeviceInfo',
'data': { '*id': 'str',
'addr': 'int',
'size': 'int',
'slot': 'int',
'node': 'int',
'memdev': 'str',
'hotplugged': 'bool',
'hotpluggable': 'bool'
}
}
##
# @MemoryDeviceInfo:
#
# Union containing information about a memory device
#
# Since: 2.1
##
{ 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'PCDIMMDeviceInfo'} }
##
# @query-memory-devices:
#
# Lists available memory devices and their state
#
# Since: 2.1
#
# Example:
#
# -> { "execute": "query-memory-devices" }
# <- { "return": [ { "data":
# { "addr": 5368709120,
# "hotpluggable": true,
# "hotplugged": true,
# "id": "d1",
# "memdev": "/objects/memX",
# "node": 0,
# "size": 1073741824,
# "slot": 0},
# "type": "dimm"
# } ] }
#
##
{ 'command': 'query-memory-devices', 'returns': ['MemoryDeviceInfo'] }
##
# @ACPISlotType:
#
# @DIMM: memory slot
# @CPU: logical CPU slot (since 2.7)
##
{ 'enum': 'ACPISlotType', 'data': [ 'DIMM', 'CPU' ] }
##
# @ACPIOSTInfo:
#
# OSPM Status Indication for a device
# For description of possible values of @source and @status fields
# see "_OST (OSPM Status Indication)" chapter of ACPI5.0 spec.
#
# @device: #optional device ID associated with slot
#
# @slot: slot ID, unique per slot of a given @slot-type
#
# @slot-type: type of the slot
#
# @source: an integer containing the source event
#
# @status: an integer containing the status code
#
# Since: 2.1
##
{ 'struct': 'ACPIOSTInfo',
'data' : { '*device': 'str',
'slot': 'str',
'slot-type': 'ACPISlotType',
'source': 'int',
'status': 'int' } }
##
# @query-acpi-ospm-status:
#
# Return a list of ACPIOSTInfo for devices that support status
# reporting via ACPI _OST method.
#
# Since: 2.1
#
# Example:
#
# -> { "execute": "query-acpi-ospm-status" }
# <- { "return": [ { "device": "d1", "slot": "0", "slot-type": "DIMM", "source": 1, "status": 0},
# { "slot": "1", "slot-type": "DIMM", "source": 0, "status": 0},
# { "slot": "2", "slot-type": "DIMM", "source": 0, "status": 0},
# { "slot": "3", "slot-type": "DIMM", "source": 0, "status": 0}
# ]}
#
##
{ 'command': 'query-acpi-ospm-status', 'returns': ['ACPIOSTInfo'] }
##
# @WatchdogExpirationAction:
#
# An enumeration of the actions taken when the watchdog device's timer is
# expired
#
# @reset: system resets
#
# @shutdown: system shutdown, note that it is similar to @powerdown, which
# tries to set to system status and notify guest
#
# @poweroff: system poweroff, the emulator program exits
#
# @pause: system pauses, similar to @stop
#
# @debug: system enters debug state
#
# @none: nothing is done
#
# @inject-nmi: a non-maskable interrupt is injected into the first VCPU (all
# VCPUS on x86) (since 2.4)
#
# Since: 2.1
##
{ 'enum': 'WatchdogExpirationAction',
'data': [ 'reset', 'shutdown', 'poweroff', 'pause', 'debug', 'none',
'inject-nmi' ] }
##
# @IoOperationType:
#
# An enumeration of the I/O operation types
#
# @read: read operation
#
# @write: write operation
#
# Since: 2.1
##
{ 'enum': 'IoOperationType',
'data': [ 'read', 'write' ] }
##
# @GuestPanicAction:
#
# An enumeration of the actions taken when guest OS panic is detected
#
# @pause: system pauses
#
# Since: 2.1 (poweroff since 2.8)
##
{ 'enum': 'GuestPanicAction',
'data': [ 'pause', 'poweroff' ] }
##
# @rtc-reset-reinjection:
#
# This command will reset the RTC interrupt reinjection backlog.
# Can be used if another mechanism to synchronize guest time
# is in effect, for example QEMU guest agent's guest-set-time
# command.
#
# Since: 2.1
#
# Example:
#
# -> { "execute": "rtc-reset-reinjection" }
# <- { "return": {} }
#
##
{ 'command': 'rtc-reset-reinjection' }
qmp/hmp: add rocker device support Add QMP/HMP support for rocker devices. This is mostly for debugging purposes to see inside the device's tables and port configurations. Some examples: (qemu) info rocker sw1 name: sw1 id: 0x0000013512005452 ports: 4 (qemu) info rocker-ports sw1 ena/ speed/ auto port link duplex neg? sw1.1 up 10G FD No sw1.2 up 10G FD No sw1.3 !ena 10G FD No sw1.4 !ena 10G FD No (qemu) info rocker-of-dpa-flows sw1 prio tbl hits key(mask) --> actions 2 60 pport 1 vlan 1 LLDP src 00:02:00:00:02:00 dst 01:80:c2:00:00:0e 2 60 pport 1 vlan 1 ARP src 00:02:00:00:02:00 dst 00:02:00:00:03:00 2 60 pport 2 vlan 2 IPv6 src 00:02:00:00:03:00 dst 33:33:ff:00:00:02 proto 58 3 50 vlan 2 dst 33:33:ff:00:00:02 --> write group 0x32000001 goto tbl 60 2 60 pport 2 vlan 2 IPv6 src 00:02:00:00:03:00 dst 33:33:ff:00:03:00 proto 58 3 50 1 vlan 2 dst 33:33:ff:00:03:00 --> write group 0x32000001 goto tbl 60 2 60 pport 2 vlan 2 ARP src 00:02:00:00:03:00 dst 00:02:00:00:02:00 3 50 2 vlan 2 dst 00:02:00:00:02:00 --> write group 0x02000001 goto tbl 60 2 60 1 pport 2 vlan 2 IP src 00:02:00:00:03:00 dst 00:02:00:00:02:00 proto 1 3 50 2 vlan 1 dst 00:02:00:00:03:00 --> write group 0x01000002 goto tbl 60 2 60 1 pport 1 vlan 1 IP src 00:02:00:00:02:00 dst 00:02:00:00:03:00 proto 1 2 60 pport 1 vlan 1 IPv6 src 00:02:00:00:02:00 dst 33:33:ff:00:00:01 proto 58 3 50 vlan 1 dst 33:33:ff:00:00:01 --> write group 0x31000000 goto tbl 60 2 60 pport 1 vlan 1 IPv6 src 00:02:00:00:02:00 dst 33:33:ff:00:02:00 proto 58 3 50 1 vlan 1 dst 33:33:ff:00:02:00 --> write group 0x31000000 goto tbl 60 1 60 173 pport 2 vlan 2 LLDP src <any> dst 01:80:c2:00:00:0e --> write group 0x02000000 1 60 6 pport 2 vlan 2 IPv6 src <any> dst <any> --> write group 0x02000000 1 60 174 pport 1 vlan 1 LLDP src <any> dst 01:80:c2:00:00:0e --> write group 0x01000000 1 60 174 pport 2 vlan 2 IP src <any> dst <any> --> write group 0x02000000 1 60 6 pport 1 vlan 1 IPv6 src <any> dst <any> --> write group 0x01000000 1 60 181 pport 2 vlan 2 ARP src <any> dst <any> --> write group 0x02000000 1 10 715 pport 2 --> apply new vlan 2 goto tbl 20 1 60 177 pport 1 vlan 1 ARP src <any> dst <any> --> write group 0x01000000 1 60 174 pport 1 vlan 1 IP src <any> dst <any> --> write group 0x01000000 1 10 717 pport 1 --> apply new vlan 1 goto tbl 20 1 0 1432 pport 0(0xffff) --> goto tbl 10 (qemu) info rocker-of-dpa-groups sw1 id (decode) --> buckets 0x32000001 (type L2 multicast vlan 2 index 1) --> groups [0x02000001,0x02000000] 0x02000001 (type L2 interface vlan 2 pport 1) --> pop vlan out pport 1 0x01000002 (type L2 interface vlan 1 pport 2) --> pop vlan out pport 2 0x02000000 (type L2 interface vlan 2 pport 0) --> pop vlan out pport 0 0x01000000 (type L2 interface vlan 1 pport 0) --> pop vlan out pport 0 0x31000000 (type L2 multicast vlan 1 index 0) --> groups [0x01000002,0x01000000] [Added "query-" prefixes to rocker.json commands as suggested by Eric Blake <eblake@redhat.com>. --Stefan] Signed-off-by: Scott Feldman <sfeldma@gmail.com> Signed-off-by: Jiri Pirko <jiri@resnulli.us> Message-id: 1433985681-56138-5-git-send-email-sfeldma@gmail.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-06-11 04:21:21 +03:00
# Rocker ethernet network switch
{ 'include': 'qapi/rocker.json' }
##
# @ReplayMode:
#
# Mode of the replay subsystem.
#
# @none: normal execution mode. Replay or record are not enabled.
#
# @record: record mode. All non-deterministic data is written into the
# replay log.
#
# @play: replay mode. Non-deterministic data required for system execution
# is read from the log.
#
# Since: 2.5
##
{ 'enum': 'ReplayMode',
'data': [ 'none', 'record', 'play' ] }
arm: qmp: add query-gic-capabilities interface This patch add "query-gic-capabilities" but does not implement it. The command is ARM-only. The command will return a list of GICCapability structs that describes all GIC versions that current QEMU and system support. Libvirt is possibly the first consumer of this new command. Before this patch, a libvirt user can successfully configure all kinds of GIC devices for ARM guests, no matter whether current QEMU/kernel supports them. If the specified GIC version/type is not supported, the user will get an ambiguous "QEMU boot failure" error when trying to start the VM. This is not user-friendly. With this patch, libvirt should be able to query which type (and which version) of GIC device is supported. Using this information, libvirt can warn the user during configuration of guests when specified GIC device type is not supported. Or better, we can just list those versions that we support, and filter out the unsupported ones. For example, if we got the query result: {"return": [{"emulated": false, "version": 3, "kernel": true}, {"emulated": true, "version": 2, "kernel": false}]} then it means that we support emulated GIC version 2 using: qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ... or KVM-accelerated GIC version 3 using: qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ... If we specify other explicit GIC versions rather than the above, QEMU will not be able to boot. The community is working on a more generic way to query these kinds of information about valid values of machine properties. However, due to the importance of supporting this specific use case, weecided to first implement this ad-hoc one; then when the generic method is ready, we can move on to that one smoothly. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com [PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
##
# @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
#
# Example:
#
# -> { "execute": "xen-load-devices-state",
# "arguments": { "filename": "/tmp/resume" } }
# <- { "return": {} }
#
##
{ 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} }
arm: qmp: add query-gic-capabilities interface This patch add "query-gic-capabilities" but does not implement it. The command is ARM-only. The command will return a list of GICCapability structs that describes all GIC versions that current QEMU and system support. Libvirt is possibly the first consumer of this new command. Before this patch, a libvirt user can successfully configure all kinds of GIC devices for ARM guests, no matter whether current QEMU/kernel supports them. If the specified GIC version/type is not supported, the user will get an ambiguous "QEMU boot failure" error when trying to start the VM. This is not user-friendly. With this patch, libvirt should be able to query which type (and which version) of GIC device is supported. Using this information, libvirt can warn the user during configuration of guests when specified GIC device type is not supported. Or better, we can just list those versions that we support, and filter out the unsupported ones. For example, if we got the query result: {"return": [{"emulated": false, "version": 3, "kernel": true}, {"emulated": true, "version": 2, "kernel": false}]} then it means that we support emulated GIC version 2 using: qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ... or KVM-accelerated GIC version 3 using: qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ... If we specify other explicit GIC versions rather than the above, QEMU will not be able to boot. The community is working on a more generic way to query these kinds of information about valid values of machine properties. However, due to the importance of supporting this specific use case, weecided to first implement this ad-hoc one; then when the generic method is ready, we can move on to that one smoothly. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com [PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
##
# @GICCapability:
#
# The struct describes capability for a specific GIC (Generic
# Interrupt Controller) version. These bits are not only decided by
# QEMU/KVM software version, but also decided by the hardware that
# the program is running upon.
#
# @version: version of GIC to be described. Currently, only 2 and 3
# are supported.
#
# @emulated: whether current QEMU/hardware supports emulated GIC
# device in user space.
#
# @kernel: whether current QEMU/hardware supports hardware
# accelerated GIC device in kernel.
#
# Since: 2.6
##
{ 'struct': 'GICCapability',
'data': { 'version': 'int',
'emulated': 'bool',
'kernel': 'bool' } }
##
# @query-gic-capabilities:
#
# This command is ARM-only. It will return a list of GICCapability
# objects that describe its capability bits.
#
# Returns: a list of GICCapability objects.
#
# Since: 2.6
#
# Example:
#
# -> { "execute": "query-gic-capabilities" }
# <- { "return": [{ "version": 2, "emulated": true, "kernel": false },
# { "version": 3, "emulated": false, "kernel": true } ] }
#
arm: qmp: add query-gic-capabilities interface This patch add "query-gic-capabilities" but does not implement it. The command is ARM-only. The command will return a list of GICCapability structs that describes all GIC versions that current QEMU and system support. Libvirt is possibly the first consumer of this new command. Before this patch, a libvirt user can successfully configure all kinds of GIC devices for ARM guests, no matter whether current QEMU/kernel supports them. If the specified GIC version/type is not supported, the user will get an ambiguous "QEMU boot failure" error when trying to start the VM. This is not user-friendly. With this patch, libvirt should be able to query which type (and which version) of GIC device is supported. Using this information, libvirt can warn the user during configuration of guests when specified GIC device type is not supported. Or better, we can just list those versions that we support, and filter out the unsupported ones. For example, if we got the query result: {"return": [{"emulated": false, "version": 3, "kernel": true}, {"emulated": true, "version": 2, "kernel": false}]} then it means that we support emulated GIC version 2 using: qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ... or KVM-accelerated GIC version 3 using: qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ... If we specify other explicit GIC versions rather than the above, QEMU will not be able to boot. The community is working on a more generic way to query these kinds of information about valid values of machine properties. However, due to the importance of supporting this specific use case, weecided to first implement this ad-hoc one; then when the generic method is ready, we can move on to that one smoothly. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com [PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-30 19:27:24 +03:00
##
{ '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.
#
# @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
#
# 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.
#
# 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
#
# Example:
#
# For pseries machine type started with -smp 2,cores=2,maxcpus=4 -cpu POWER8:
#
# -> { "execute": "query-hotpluggable-cpus" }
# <- {"return": [
# { "props": { "core": 8 }, "type": "POWER8-spapr-cpu-core",
# "vcpus-count": 1 },
# { "props": { "core": 0 }, "type": "POWER8-spapr-cpu-core",
# "vcpus-count": 1, "qom-path": "/machine/unattached/device[0]"}
# ]}'
#
# For pc machine type started with -smp 1,maxcpus=2:
#
# -> { "execute": "query-hotpluggable-cpus" }
# <- {"return": [
# {
# "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
# "props": {"core-id": 0, "socket-id": 1, "thread-id": 0}
# },
# {
# "qom-path": "/machine/unattached/device[0]",
# "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
# "props": {"core-id": 0, "socket-id": 0, "thread-id": 0}
# }
# ]}
#
##
{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }