2018-02-27 02:13:27 +03:00
|
|
|
# -*- Mode: Python -*-
|
2020-07-29 21:50:24 +03:00
|
|
|
# vim: filetype=python
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
|
|
|
|
##
|
|
|
|
# = Miscellanea
|
|
|
|
##
|
|
|
|
|
2018-04-27 22:28:50 +03:00
|
|
|
{ 'include': 'common.json' }
|
|
|
|
|
2018-02-27 02:13:27 +03:00
|
|
|
##
|
|
|
|
# @LostTickPolicy:
|
|
|
|
#
|
2020-02-11 21:37:44 +03:00
|
|
|
# Policy for handling lost ticks in timer devices. Ticks end up getting
|
|
|
|
# lost when, for example, the guest is paused.
|
|
|
|
#
|
|
|
|
# @discard: throw away the missed ticks and continue with future injection
|
|
|
|
# normally. The guest OS will see the timer jump ahead by a
|
|
|
|
# potentially quite significant amount all at once, as if the
|
|
|
|
# intervening chunk of time had simply not existed; needless to
|
|
|
|
# say, such a sudden jump can easily confuse a guest OS which is
|
|
|
|
# not specifically prepared to deal with it. Assuming the guest
|
|
|
|
# OS can deal correctly with the time jump, the time in the guest
|
|
|
|
# and in the host should now match.
|
|
|
|
#
|
|
|
|
# @delay: continue to deliver ticks at the normal rate. The guest OS will
|
|
|
|
# not notice anything is amiss, as from its point of view time will
|
|
|
|
# have continued to flow normally. The time in the guest should now
|
|
|
|
# be behind the time in the host by exactly the amount of time during
|
|
|
|
# which ticks have been missed.
|
|
|
|
#
|
|
|
|
# @slew: deliver ticks at a higher rate to catch up with the missed ticks.
|
|
|
|
# The guest OS will not notice anything is amiss, as from its point
|
|
|
|
# of view time will have continued to flow normally. Once the timer
|
|
|
|
# has managed to catch up with all the missing ticks, the time in
|
|
|
|
# the guest and in the host should match.
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# Since: 2.0
|
|
|
|
##
|
|
|
|
{ 'enum': 'LostTickPolicy',
|
2019-04-01 18:01:40 +03:00
|
|
|
'data': ['discard', 'delay', 'slew' ] }
|
2018-02-27 02:13:27 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @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: whether to skip authentication. Only applies
|
|
|
|
# to "vnc" and "spice" protocols
|
|
|
|
#
|
|
|
|
# @tls: 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: 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" } }
|
|
|
|
#
|
|
|
|
##
|
2018-06-20 18:39:44 +03:00
|
|
|
{ 'command': 'query-name', 'returns': 'NameInfo', 'allow-preconfig': true }
|
2018-02-27 02:13:27 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @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' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @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" } }
|
|
|
|
#
|
|
|
|
##
|
2018-06-20 18:39:44 +03:00
|
|
|
{ 'command': 'query-uuid', 'returns': 'UuidInfo', 'allow-preconfig': true }
|
2018-02-27 02:13:27 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @IOThreadInfo:
|
|
|
|
#
|
|
|
|
# Information about an iothread
|
|
|
|
#
|
|
|
|
# @id: the identifier of the iothread
|
|
|
|
#
|
|
|
|
# @thread-id: ID of the underlying host thread
|
|
|
|
#
|
|
|
|
# @poll-max-ns: maximum polling time in ns, 0 means polling is disabled
|
|
|
|
# (since 2.9)
|
|
|
|
#
|
|
|
|
# @poll-grow: how many ns will be added to polling time, 0 means that it's not
|
|
|
|
# configured (since 2.9)
|
|
|
|
#
|
|
|
|
# @poll-shrink: how many ns will be removed from polling time, 0 means that
|
|
|
|
# it's not configured (since 2.9)
|
|
|
|
#
|
|
|
|
# Since: 2.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'IOThreadInfo',
|
|
|
|
'data': {'id': 'str',
|
|
|
|
'thread-id': 'int',
|
|
|
|
'poll-max-ns': 'int',
|
|
|
|
'poll-grow': 'int',
|
|
|
|
'poll-shrink': 'int' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-iothreads:
|
|
|
|
#
|
|
|
|
# Returns a list of information about each iothread.
|
|
|
|
#
|
|
|
|
# Note: this list excludes the QEMU main loop thread, which is not declared
|
2020-02-13 20:56:26 +03:00
|
|
|
# using the -object iothread command-line option. It is always the main thread
|
|
|
|
# of the process.
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# 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
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
#
|
|
|
|
##
|
2018-06-20 18:39:44 +03:00
|
|
|
{ 'command': 'query-iothreads', 'returns': ['IOThreadInfo'],
|
|
|
|
'allow-preconfig': true }
|
2018-02-27 02:13:27 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @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.
|
|
|
|
#
|
2020-02-13 20:56:30 +03:00
|
|
|
# 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
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-balloon" }
|
|
|
|
# <- { "return": {
|
|
|
|
# "actual": 1073741824,
|
|
|
|
# }
|
|
|
|
# }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'command': 'query-balloon', 'returns': 'BalloonInfo' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @BALLOON_CHANGE:
|
|
|
|
#
|
|
|
|
# Emitted when the guest changes the actual BALLOON level. This value is
|
|
|
|
# equivalent to the @actual field return by the 'query-balloon' command
|
|
|
|
#
|
|
|
|
# @actual: actual level of the guest memory balloon in bytes
|
|
|
|
#
|
|
|
|
# Note: this event is rate-limited.
|
|
|
|
#
|
|
|
|
# Since: 1.2
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# <- { "event": "BALLOON_CHANGE",
|
|
|
|
# "data": { "actual": 944766976 },
|
|
|
|
# "timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'event': 'BALLOON_CHANGE',
|
|
|
|
'data': { 'actual': 'int' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @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
|
|
|
|
#
|
2020-02-13 20:56:30 +03:00
|
|
|
# @type: - 'io' if the region is a PIO region
|
|
|
|
# - 'memory' if the region is a MMIO region
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# @size: memory size
|
|
|
|
#
|
|
|
|
# @prefetch: if @type is 'memory', true if the memory is prefetchable
|
|
|
|
#
|
|
|
|
# @mem_type_64: 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: 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
|
|
|
|
#
|
2018-09-18 12:58:52 +03:00
|
|
|
# @subsystem: the PCI subsystem id (since 3.1)
|
|
|
|
#
|
|
|
|
# @subsystem-vendor: the PCI subsystem vendor id (since 3.1)
|
|
|
|
#
|
2018-02-27 02:13:27 +03:00
|
|
|
# Since: 2.4
|
|
|
|
##
|
|
|
|
{ 'struct': 'PciDeviceId',
|
2018-10-02 16:55:38 +03:00
|
|
|
'data': {'device': 'int', 'vendor': 'int', '*subsystem': 'int',
|
|
|
|
'*subsystem-vendor': 'int'} }
|
2018-02-27 02:13:27 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @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: if an IRQ is assigned to the device, the IRQ number
|
|
|
|
#
|
2020-03-17 22:59:08 +03:00
|
|
|
# @irq_pin: the IRQ pin, zero means no IRQ (since 5.1)
|
|
|
|
#
|
2018-02-27 02:13:27 +03:00
|
|
|
# @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',
|
2020-03-17 22:59:08 +03:00
|
|
|
'*irq': 'int', 'irq_pin': 'int', 'qdev_id': 'str',
|
|
|
|
'*pci_bridge': 'PciBridgeInfo', 'regions': ['PciMemoryRegion'] }}
|
2018-02-27 02:13:27 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @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
|
2020-02-13 20:56:26 +03:00
|
|
|
# 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.
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# 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'] }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @stop:
|
|
|
|
#
|
|
|
|
# Stop all guest VCPU execution.
|
|
|
|
#
|
|
|
|
# Since: 0.14.0
|
|
|
|
#
|
2020-02-13 20:56:26 +03:00
|
|
|
# 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.
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# 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' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @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: the index of the virtual CPU to use for translating the
|
2020-02-13 20:56:26 +03:00
|
|
|
# virtual address (defaults to CPU 0)
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# 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
|
|
|
|
#
|
2020-02-13 20:56:26 +03:00
|
|
|
# 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.
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "cont" }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'command': 'cont' }
|
|
|
|
|
2018-05-11 20:24:43 +03:00
|
|
|
##
|
2018-07-05 12:14:02 +03:00
|
|
|
# @x-exit-preconfig:
|
2018-05-11 20:24:43 +03:00
|
|
|
#
|
|
|
|
# Exit from "preconfig" state
|
|
|
|
#
|
|
|
|
# This command makes QEMU exit the preconfig state and proceed with
|
|
|
|
# VM initialization using configuration data provided on the command line
|
|
|
|
# and via the QMP monitor during the preconfig state. The command is only
|
|
|
|
# available during the preconfig state (i.e. when the --preconfig command
|
|
|
|
# line option was in use).
|
|
|
|
#
|
|
|
|
# Since 3.0
|
|
|
|
#
|
|
|
|
# Returns: nothing
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
2018-07-05 12:14:02 +03:00
|
|
|
# -> { "execute": "x-exit-preconfig" }
|
2018-05-11 20:24:43 +03:00
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
|
|
|
##
|
2018-07-05 12:14:02 +03:00
|
|
|
{ 'command': 'x-exit-preconfig', 'allow-preconfig': true }
|
2018-05-11 20:24:43 +03:00
|
|
|
|
2018-02-27 02:13:27 +03:00
|
|
|
##
|
|
|
|
# @system_wakeup:
|
|
|
|
#
|
qmp hmp: Make system_wakeup check wake-up support and run state
The qmp/hmp command 'system_wakeup' is simply a direct call to
'qemu_system_wakeup_request' from vl.c. This function verifies if
runstate is SUSPENDED and if the wake up reason is valid before
proceeding. However, no error or warning is thrown if any of those
pre-requirements isn't met. There is no way for the caller to
differentiate between a successful wakeup or an error state caused
when trying to wake up a guest that wasn't suspended.
This means that system_wakeup is silently failing, which can be
considered a bug. Adding error handling isn't an API break in this
case - applications that didn't check the result will remain broken,
the ones that check it will have a chance to deal with it.
Adding to that, the commit before previous created a new QMP API called
query-current-machine, with a new flag called wakeup-suspend-support,
that indicates if the guest has the capability of waking up from suspended
state. Although such guest will never reach SUSPENDED state and erroring
it out in this scenario would suffice, it is more informative for the user
to differentiate between a failure because the guest isn't suspended versus
a failure because the guest does not have support for wake up at all.
All this considered, this patch changes qmp_system_wakeup to check if
the guest is capable of waking up from suspend, and if it is suspended.
After this patch, this is the output of system_wakeup in a guest that
does not have wake-up from suspend support (ppc64):
(qemu) system_wakeup
wake-up from suspend is not supported by this guest
(qemu)
And this is the output of system_wakeup in a x86 guest that has the
support but isn't suspended:
(qemu) system_wakeup
Unable to wake up: guest is not in suspended state
(qemu)
Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20181205194701.17836-4-danielhb413@gmail.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-05 22:47:01 +03:00
|
|
|
# Wake up guest from suspend. If the guest has wake-up from suspend
|
|
|
|
# support enabled (wakeup-suspend-support flag from
|
|
|
|
# query-current-machine), wake-up guest from suspend if the guest is
|
|
|
|
# in SUSPENDED state. Return an error otherwise.
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# Since: 1.1
|
|
|
|
#
|
|
|
|
# Returns: nothing.
|
|
|
|
#
|
qmp hmp: Make system_wakeup check wake-up support and run state
The qmp/hmp command 'system_wakeup' is simply a direct call to
'qemu_system_wakeup_request' from vl.c. This function verifies if
runstate is SUSPENDED and if the wake up reason is valid before
proceeding. However, no error or warning is thrown if any of those
pre-requirements isn't met. There is no way for the caller to
differentiate between a successful wakeup or an error state caused
when trying to wake up a guest that wasn't suspended.
This means that system_wakeup is silently failing, which can be
considered a bug. Adding error handling isn't an API break in this
case - applications that didn't check the result will remain broken,
the ones that check it will have a chance to deal with it.
Adding to that, the commit before previous created a new QMP API called
query-current-machine, with a new flag called wakeup-suspend-support,
that indicates if the guest has the capability of waking up from suspended
state. Although such guest will never reach SUSPENDED state and erroring
it out in this scenario would suffice, it is more informative for the user
to differentiate between a failure because the guest isn't suspended versus
a failure because the guest does not have support for wake up at all.
All this considered, this patch changes qmp_system_wakeup to check if
the guest is capable of waking up from suspend, and if it is suspended.
After this patch, this is the output of system_wakeup in a guest that
does not have wake-up from suspend support (ppc64):
(qemu) system_wakeup
wake-up from suspend is not supported by this guest
(qemu)
And this is the output of system_wakeup in a x86 guest that has the
support but isn't suspended:
(qemu) system_wakeup
Unable to wake up: guest is not in suspended state
(qemu)
Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20181205194701.17836-4-danielhb413@gmail.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-05 22:47:01 +03:00
|
|
|
# Note: prior to 4.0, this command does nothing in case the guest
|
2020-02-13 20:56:26 +03:00
|
|
|
# isn't suspended.
|
qmp hmp: Make system_wakeup check wake-up support and run state
The qmp/hmp command 'system_wakeup' is simply a direct call to
'qemu_system_wakeup_request' from vl.c. This function verifies if
runstate is SUSPENDED and if the wake up reason is valid before
proceeding. However, no error or warning is thrown if any of those
pre-requirements isn't met. There is no way for the caller to
differentiate between a successful wakeup or an error state caused
when trying to wake up a guest that wasn't suspended.
This means that system_wakeup is silently failing, which can be
considered a bug. Adding error handling isn't an API break in this
case - applications that didn't check the result will remain broken,
the ones that check it will have a chance to deal with it.
Adding to that, the commit before previous created a new QMP API called
query-current-machine, with a new flag called wakeup-suspend-support,
that indicates if the guest has the capability of waking up from suspended
state. Although such guest will never reach SUSPENDED state and erroring
it out in this scenario would suffice, it is more informative for the user
to differentiate between a failure because the guest isn't suspended versus
a failure because the guest does not have support for wake up at all.
All this considered, this patch changes qmp_system_wakeup to check if
the guest is capable of waking up from suspend, and if it is suspended.
After this patch, this is the output of system_wakeup in a guest that
does not have wake-up from suspend support (ppc64):
(qemu) system_wakeup
wake-up from suspend is not supported by this guest
(qemu)
And this is the output of system_wakeup in a x86 guest that has the
support but isn't suspended:
(qemu) system_wakeup
Unable to wake up: guest is not in suspended state
(qemu)
Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20181205194701.17836-4-danielhb413@gmail.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-05 22:47:01 +03:00
|
|
|
#
|
2018-02-27 02:13:27 +03:00
|
|
|
# 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' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @balloon:
|
|
|
|
#
|
|
|
|
# Request the balloon driver to change its balloon size.
|
|
|
|
#
|
|
|
|
# @value: the target size of the balloon in bytes
|
|
|
|
#
|
2020-02-13 20:56:30 +03:00
|
|
|
# Returns: - Nothing on success
|
|
|
|
# - If the balloon driver is enabled but not functional because the KVM
|
2018-02-27 02:13:27 +03:00
|
|
|
# kernel module cannot support it, KvmMissingCap
|
2020-02-13 20:56:30 +03:00
|
|
|
# - If no balloon device is present, DeviceNotActive
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# 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'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @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: The CPU to use for commands that require an implicit CPU
|
|
|
|
#
|
2019-10-18 11:14:54 +03:00
|
|
|
# Features:
|
|
|
|
# @savevm-monitor-nodes: If present, HMP command savevm only snapshots
|
|
|
|
# monitor-owned nodes if they have no parents.
|
|
|
|
# This allows the use of 'savevm' with
|
|
|
|
# -blockdev. (since 4.2)
|
|
|
|
#
|
2018-02-27 02:13:27 +03:00
|
|
|
# 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 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'},
|
2019-10-18 11:14:54 +03:00
|
|
|
'returns': 'str',
|
|
|
|
'features': [ 'savevm-monitor-nodes' ] }
|
2018-02-27 02:13:27 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @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.
|
|
|
|
#
|
2020-02-13 20:56:26 +03:00
|
|
|
# @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. See change-vnc-password for additional notes.
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
qapi: Mark deprecated QMP parts with feature 'deprecated'
Add feature 'deprecated' to the deprecated QMP commands, so their
deprecation becomes visible in output of query-qmp-schema. Looks like
this:
{"name": "query-cpus",
"ret-type": "[164]",
"meta-type": "command",
"arg-type": "0",
---> "features": ["deprecated"]}
Management applications could conceivably use this for static
checking.
The deprecated commands are change, cpu-add, migrate-set-cache-size,
migrate_set_downtime, migrate_set_speed, query-cpus, query-events,
query-migrate-cache-size.
The deprecated command arguments are block-commit arguments @base and
@top, and block_set_io_throttle, blockdev-change-medium,
blockdev-close-tray, blockdev-open-tray, eject argument @device.
The deprecated command results are query-cpus-fast result @arch,
query-block result @dirty-bitmaps, query-named-block-nodes result
@encryption_key_missing and result @dirty-bitmaps's member @status.
Same for query-block result @inserted, which mirrors
query-named-block-nodes.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20200317115459.31821-27-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
2020-03-17 14:54:51 +03:00
|
|
|
# Features:
|
|
|
|
# @deprecated: This command is deprecated. For changing block
|
2020-08-10 22:50:01 +03:00
|
|
|
# devices, use 'blockdev-change-medium' instead; for changing VNC
|
|
|
|
# parameters, use 'change-vnc-password' instead.
|
qapi: Mark deprecated QMP parts with feature 'deprecated'
Add feature 'deprecated' to the deprecated QMP commands, so their
deprecation becomes visible in output of query-qmp-schema. Looks like
this:
{"name": "query-cpus",
"ret-type": "[164]",
"meta-type": "command",
"arg-type": "0",
---> "features": ["deprecated"]}
Management applications could conceivably use this for static
checking.
The deprecated commands are change, cpu-add, migrate-set-cache-size,
migrate_set_downtime, migrate_set_speed, query-cpus, query-events,
query-migrate-cache-size.
The deprecated command arguments are block-commit arguments @base and
@top, and block_set_io_throttle, blockdev-change-medium,
blockdev-close-tray, blockdev-open-tray, eject argument @device.
The deprecated command results are query-cpus-fast result @arch,
query-block result @dirty-bitmaps, query-named-block-nodes result
@encryption_key_missing and result @dirty-bitmaps's member @status.
Same for query-block result @inserted, which mirrors
query-named-block-nodes.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20200317115459.31821-27-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
2020-03-17 14:54:51 +03:00
|
|
|
#
|
2020-02-13 20:56:30 +03:00
|
|
|
# Returns: - Nothing on success.
|
|
|
|
# - If @device is not a valid block device, DeviceNotFound
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# 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',
|
qapi: Mark deprecated QMP parts with feature 'deprecated'
Add feature 'deprecated' to the deprecated QMP commands, so their
deprecation becomes visible in output of query-qmp-schema. Looks like
this:
{"name": "query-cpus",
"ret-type": "[164]",
"meta-type": "command",
"arg-type": "0",
---> "features": ["deprecated"]}
Management applications could conceivably use this for static
checking.
The deprecated commands are change, cpu-add, migrate-set-cache-size,
migrate_set_downtime, migrate_set_speed, query-cpus, query-events,
query-migrate-cache-size.
The deprecated command arguments are block-commit arguments @base and
@top, and block_set_io_throttle, blockdev-change-medium,
blockdev-close-tray, blockdev-open-tray, eject argument @device.
The deprecated command results are query-cpus-fast result @arch,
query-block result @dirty-bitmaps, query-named-block-nodes result
@encryption_key_missing and result @dirty-bitmaps's member @status.
Same for query-block result @inserted, which mirrors
query-named-block-nodes.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20200317115459.31821-27-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
2020-03-17 14:54:51 +03:00
|
|
|
'data': {'device': 'str', 'target': 'str', '*arg': 'str'},
|
|
|
|
'features': [ 'deprecated' ] }
|
2018-02-27 02:13:27 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @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' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @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'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @MemoryInfo:
|
|
|
|
#
|
|
|
|
# Actual memory information in bytes.
|
|
|
|
#
|
|
|
|
# @base-memory: size of "base" memory specified with command line
|
|
|
|
# option -m.
|
|
|
|
#
|
|
|
|
# @plugged-memory: size of memory that can be hot-unplugged. This field
|
|
|
|
# is omitted if target doesn't support memory hotplug
|
2018-10-05 12:20:14 +03:00
|
|
|
# (i.e. CONFIG_MEM_DEVICE not defined at build time).
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# Since: 2.11.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'MemoryInfo',
|
|
|
|
'data' : { 'base-memory': 'size', '*plugged-memory': 'size' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-memory-size-summary:
|
|
|
|
#
|
|
|
|
# Return the amount of initially allocated and present hotpluggable (if
|
|
|
|
# enabled) memory in bytes.
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "query-memory-size-summary" }
|
|
|
|
# <- { "return": { "base-memory": 4294967296, "plugged-memory": 0 } }
|
|
|
|
#
|
|
|
|
# Since: 2.11.0
|
|
|
|
##
|
|
|
|
{ 'command': 'query-memory-size-summary', 'returns': 'MemoryInfo' }
|
|
|
|
|
|
|
|
|
|
|
|
##
|
|
|
|
# @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: The ID of the fd set to add the file descriptor to.
|
|
|
|
#
|
|
|
|
# @opaque: A free-form string that can be used to describe the fd.
|
|
|
|
#
|
2020-02-13 20:56:30 +03:00
|
|
|
# Returns: - @AddfdInfo on success
|
|
|
|
# - If file descriptor was not received, FdNotSupplied
|
|
|
|
# - If @fdset-id is a negative value, InvalidParameterValue
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# 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 } }
|
|
|
|
#
|
|
|
|
##
|
2018-12-08 14:16:04 +03:00
|
|
|
{ 'command': 'add-fd',
|
|
|
|
'data': { '*fdset-id': 'int',
|
|
|
|
'*opaque': 'str' },
|
2018-02-27 02:13:27 +03:00
|
|
|
'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: The file descriptor that is to be removed.
|
|
|
|
#
|
2020-02-13 20:56:30 +03:00
|
|
|
# Returns: - Nothing on success
|
|
|
|
# - If @fdset-id or @fd is not found, FdNotFound
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# 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: 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'] }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @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: table signature / identifier (4 bytes)
|
|
|
|
#
|
|
|
|
# @rev: table revision number (dependent on signature, 1 byte)
|
|
|
|
#
|
|
|
|
# @oem_id: OEM identifier (6 bytes)
|
|
|
|
#
|
|
|
|
# @oem_table_id: OEM table identifier (8 bytes)
|
|
|
|
#
|
|
|
|
# @oem_rev: OEM-supplied revision number (4 bytes)
|
|
|
|
#
|
|
|
|
# @asl_compiler_id: identifier of the utility that created the table
|
|
|
|
# (4 bytes)
|
|
|
|
#
|
|
|
|
# @asl_compiler_rev: revision number of the utility that created the
|
|
|
|
# table (4 bytes)
|
|
|
|
#
|
|
|
|
# @file: 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: 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: human readable text string, not suitable for parsing.
|
|
|
|
#
|
|
|
|
# @default: 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: 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"
|
|
|
|
# }
|
|
|
|
# ]
|
|
|
|
# }
|
|
|
|
#
|
|
|
|
##
|
2018-12-08 14:16:04 +03:00
|
|
|
{'command': 'query-command-line-options',
|
|
|
|
'data': { '*option': 'str' },
|
2018-05-11 19:51:43 +03:00
|
|
|
'returns': ['CommandLineOptionInfo'],
|
|
|
|
'allow-preconfig': true }
|
2018-02-27 02:13:27 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @PCDIMMDeviceInfo:
|
|
|
|
#
|
|
|
|
# PCDIMMDevice state information
|
|
|
|
#
|
|
|
|
# @id: 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'
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-19 12:49:01 +03:00
|
|
|
##
|
|
|
|
# @VirtioPMEMDeviceInfo:
|
|
|
|
#
|
|
|
|
# VirtioPMEM state information
|
|
|
|
#
|
|
|
|
# @id: device's ID
|
|
|
|
#
|
|
|
|
# @memaddr: physical address in memory, where device is mapped
|
|
|
|
#
|
|
|
|
# @size: size of memory that the device provides
|
|
|
|
#
|
|
|
|
# @memdev: memory backend linked with device
|
|
|
|
#
|
|
|
|
# Since: 4.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'VirtioPMEMDeviceInfo',
|
|
|
|
'data': { '*id': 'str',
|
|
|
|
'memaddr': 'size',
|
|
|
|
'size': 'size',
|
|
|
|
'memdev': 'str'
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
virtio-mem: Paravirtualized memory hot(un)plug
This is the very basic/initial version of virtio-mem. An introduction to
virtio-mem can be found in the Linux kernel driver [1]. While it can be
used in the current state for hotplug of a smaller amount of memory, it
will heavily benefit from resizeable memory regions in the future.
Each virtio-mem device manages a memory region (provided via a memory
backend). After requested by the hypervisor ("requested-size"), the
guest can try to plug/unplug blocks of memory within that region, in order
to reach the requested size. Initially, and after a reboot, all memory is
unplugged (except in special cases - reboot during postcopy).
The guest may only try to plug/unplug blocks of memory within the usable
region size. The usable region size is a little bigger than the
requested size, to give the device driver some flexibility. The usable
region size will only grow, except on reboots or when all memory is
requested to get unplugged. The guest can never plug more memory than
requested. Unplugged memory will get zapped/discarded, similar to in a
balloon device.
The block size is variable, however, it is always chosen in a way such that
THP splits are avoided (e.g., 2MB). The state of each block
(plugged/unplugged) is tracked in a bitmap.
As virtio-mem devices (e.g., virtio-mem-pci) will be memory devices, we now
expose "VirtioMEMDeviceInfo" via "query-memory-devices".
--------------------------------------------------------------------------
There are two important follow-up items that are in the works:
1. Resizeable memory regions: Use resizeable allocations/RAM blocks to
grow/shrink along with the usable region size. This avoids creating
initially very big VMAs, RAM blocks, and KVM slots.
2. Protection of unplugged memory: Make sure the gust cannot actually
make use of unplugged memory.
Other follow-up items that are in the works:
1. Exclude unplugged memory during migration (via precopy notifier).
2. Handle remapping of memory.
3. Support for other architectures.
--------------------------------------------------------------------------
Example usage (virtio-mem-pci is introduced in follow-up patches):
Start QEMU with two virtio-mem devices (one per NUMA node):
$ qemu-system-x86_64 -m 4G,maxmem=20G \
-smp sockets=2,cores=2 \
-numa node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 \
[...]
-object memory-backend-ram,id=mem0,size=8G \
-device virtio-mem-pci,id=vm0,memdev=mem0,node=0,requested-size=0M \
-object memory-backend-ram,id=mem1,size=8G \
-device virtio-mem-pci,id=vm1,memdev=mem1,node=1,requested-size=1G
Query the configuration:
(qemu) info memory-devices
Memory device [virtio-mem]: "vm0"
memaddr: 0x140000000
node: 0
requested-size: 0
size: 0
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem0
Memory device [virtio-mem]: "vm1"
memaddr: 0x340000000
node: 1
requested-size: 1073741824
size: 1073741824
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem1
Add some memory to node 0:
(qemu) qom-set vm0 requested-size 500M
Remove some memory from node 1:
(qemu) qom-set vm1 requested-size 200M
Query the configuration again:
(qemu) info memory-devices
Memory device [virtio-mem]: "vm0"
memaddr: 0x140000000
node: 0
requested-size: 524288000
size: 524288000
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem0
Memory device [virtio-mem]: "vm1"
memaddr: 0x340000000
node: 1
requested-size: 209715200
size: 209715200
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem1
[1] https://lkml.kernel.org/r/20200311171422.10484-1-david@redhat.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20200626072248.78761-11-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-26 10:22:37 +03:00
|
|
|
##
|
|
|
|
# @VirtioMEMDeviceInfo:
|
|
|
|
#
|
|
|
|
# VirtioMEMDevice state information
|
|
|
|
#
|
|
|
|
# @id: device's ID
|
|
|
|
#
|
|
|
|
# @memaddr: physical address in memory, where device is mapped
|
|
|
|
#
|
|
|
|
# @requested-size: the user requested size of the device
|
|
|
|
#
|
|
|
|
# @size: the (current) size of memory that the device provides
|
|
|
|
#
|
|
|
|
# @max-size: the maximum size of memory that the device can provide
|
|
|
|
#
|
|
|
|
# @block-size: the block size of memory that the device provides
|
|
|
|
#
|
|
|
|
# @node: NUMA node number where device is assigned to
|
|
|
|
#
|
|
|
|
# @memdev: memory backend linked with the region
|
|
|
|
#
|
|
|
|
# Since: 5.1
|
|
|
|
##
|
|
|
|
{ 'struct': 'VirtioMEMDeviceInfo',
|
|
|
|
'data': { '*id': 'str',
|
|
|
|
'memaddr': 'size',
|
|
|
|
'requested-size': 'size',
|
|
|
|
'size': 'size',
|
|
|
|
'max-size': 'size',
|
|
|
|
'block-size': 'size',
|
|
|
|
'node': 'int',
|
|
|
|
'memdev': 'str'
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-27 02:13:27 +03:00
|
|
|
##
|
|
|
|
# @MemoryDeviceInfo:
|
|
|
|
#
|
|
|
|
# Union containing information about a memory device
|
|
|
|
#
|
2019-06-19 12:49:01 +03:00
|
|
|
# nvdimm is included since 2.12. virtio-pmem is included since 4.1.
|
virtio-mem: Paravirtualized memory hot(un)plug
This is the very basic/initial version of virtio-mem. An introduction to
virtio-mem can be found in the Linux kernel driver [1]. While it can be
used in the current state for hotplug of a smaller amount of memory, it
will heavily benefit from resizeable memory regions in the future.
Each virtio-mem device manages a memory region (provided via a memory
backend). After requested by the hypervisor ("requested-size"), the
guest can try to plug/unplug blocks of memory within that region, in order
to reach the requested size. Initially, and after a reboot, all memory is
unplugged (except in special cases - reboot during postcopy).
The guest may only try to plug/unplug blocks of memory within the usable
region size. The usable region size is a little bigger than the
requested size, to give the device driver some flexibility. The usable
region size will only grow, except on reboots or when all memory is
requested to get unplugged. The guest can never plug more memory than
requested. Unplugged memory will get zapped/discarded, similar to in a
balloon device.
The block size is variable, however, it is always chosen in a way such that
THP splits are avoided (e.g., 2MB). The state of each block
(plugged/unplugged) is tracked in a bitmap.
As virtio-mem devices (e.g., virtio-mem-pci) will be memory devices, we now
expose "VirtioMEMDeviceInfo" via "query-memory-devices".
--------------------------------------------------------------------------
There are two important follow-up items that are in the works:
1. Resizeable memory regions: Use resizeable allocations/RAM blocks to
grow/shrink along with the usable region size. This avoids creating
initially very big VMAs, RAM blocks, and KVM slots.
2. Protection of unplugged memory: Make sure the gust cannot actually
make use of unplugged memory.
Other follow-up items that are in the works:
1. Exclude unplugged memory during migration (via precopy notifier).
2. Handle remapping of memory.
3. Support for other architectures.
--------------------------------------------------------------------------
Example usage (virtio-mem-pci is introduced in follow-up patches):
Start QEMU with two virtio-mem devices (one per NUMA node):
$ qemu-system-x86_64 -m 4G,maxmem=20G \
-smp sockets=2,cores=2 \
-numa node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 \
[...]
-object memory-backend-ram,id=mem0,size=8G \
-device virtio-mem-pci,id=vm0,memdev=mem0,node=0,requested-size=0M \
-object memory-backend-ram,id=mem1,size=8G \
-device virtio-mem-pci,id=vm1,memdev=mem1,node=1,requested-size=1G
Query the configuration:
(qemu) info memory-devices
Memory device [virtio-mem]: "vm0"
memaddr: 0x140000000
node: 0
requested-size: 0
size: 0
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem0
Memory device [virtio-mem]: "vm1"
memaddr: 0x340000000
node: 1
requested-size: 1073741824
size: 1073741824
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem1
Add some memory to node 0:
(qemu) qom-set vm0 requested-size 500M
Remove some memory from node 1:
(qemu) qom-set vm1 requested-size 200M
Query the configuration again:
(qemu) info memory-devices
Memory device [virtio-mem]: "vm0"
memaddr: 0x140000000
node: 0
requested-size: 524288000
size: 524288000
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem0
Memory device [virtio-mem]: "vm1"
memaddr: 0x340000000
node: 1
requested-size: 209715200
size: 209715200
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem1
[1] https://lkml.kernel.org/r/20200311171422.10484-1-david@redhat.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20200626072248.78761-11-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-26 10:22:37 +03:00
|
|
|
# virtio-mem is included since 5.1.
|
2019-06-19 12:49:01 +03:00
|
|
|
#
|
2018-02-27 02:13:27 +03:00
|
|
|
# Since: 2.1
|
|
|
|
##
|
2018-03-11 06:02:12 +03:00
|
|
|
{ 'union': 'MemoryDeviceInfo',
|
|
|
|
'data': { 'dimm': 'PCDIMMDeviceInfo',
|
2019-06-19 12:49:01 +03:00
|
|
|
'nvdimm': 'PCDIMMDeviceInfo',
|
virtio-mem: Paravirtualized memory hot(un)plug
This is the very basic/initial version of virtio-mem. An introduction to
virtio-mem can be found in the Linux kernel driver [1]. While it can be
used in the current state for hotplug of a smaller amount of memory, it
will heavily benefit from resizeable memory regions in the future.
Each virtio-mem device manages a memory region (provided via a memory
backend). After requested by the hypervisor ("requested-size"), the
guest can try to plug/unplug blocks of memory within that region, in order
to reach the requested size. Initially, and after a reboot, all memory is
unplugged (except in special cases - reboot during postcopy).
The guest may only try to plug/unplug blocks of memory within the usable
region size. The usable region size is a little bigger than the
requested size, to give the device driver some flexibility. The usable
region size will only grow, except on reboots or when all memory is
requested to get unplugged. The guest can never plug more memory than
requested. Unplugged memory will get zapped/discarded, similar to in a
balloon device.
The block size is variable, however, it is always chosen in a way such that
THP splits are avoided (e.g., 2MB). The state of each block
(plugged/unplugged) is tracked in a bitmap.
As virtio-mem devices (e.g., virtio-mem-pci) will be memory devices, we now
expose "VirtioMEMDeviceInfo" via "query-memory-devices".
--------------------------------------------------------------------------
There are two important follow-up items that are in the works:
1. Resizeable memory regions: Use resizeable allocations/RAM blocks to
grow/shrink along with the usable region size. This avoids creating
initially very big VMAs, RAM blocks, and KVM slots.
2. Protection of unplugged memory: Make sure the gust cannot actually
make use of unplugged memory.
Other follow-up items that are in the works:
1. Exclude unplugged memory during migration (via precopy notifier).
2. Handle remapping of memory.
3. Support for other architectures.
--------------------------------------------------------------------------
Example usage (virtio-mem-pci is introduced in follow-up patches):
Start QEMU with two virtio-mem devices (one per NUMA node):
$ qemu-system-x86_64 -m 4G,maxmem=20G \
-smp sockets=2,cores=2 \
-numa node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 \
[...]
-object memory-backend-ram,id=mem0,size=8G \
-device virtio-mem-pci,id=vm0,memdev=mem0,node=0,requested-size=0M \
-object memory-backend-ram,id=mem1,size=8G \
-device virtio-mem-pci,id=vm1,memdev=mem1,node=1,requested-size=1G
Query the configuration:
(qemu) info memory-devices
Memory device [virtio-mem]: "vm0"
memaddr: 0x140000000
node: 0
requested-size: 0
size: 0
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem0
Memory device [virtio-mem]: "vm1"
memaddr: 0x340000000
node: 1
requested-size: 1073741824
size: 1073741824
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem1
Add some memory to node 0:
(qemu) qom-set vm0 requested-size 500M
Remove some memory from node 1:
(qemu) qom-set vm1 requested-size 200M
Query the configuration again:
(qemu) info memory-devices
Memory device [virtio-mem]: "vm0"
memaddr: 0x140000000
node: 0
requested-size: 524288000
size: 524288000
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem0
Memory device [virtio-mem]: "vm1"
memaddr: 0x340000000
node: 1
requested-size: 209715200
size: 209715200
max-size: 8589934592
block-size: 2097152
memdev: /objects/mem1
[1] https://lkml.kernel.org/r/20200311171422.10484-1-david@redhat.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20200626072248.78761-11-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-26 10:22:37 +03:00
|
|
|
'virtio-pmem': 'VirtioPMEMDeviceInfo',
|
|
|
|
'virtio-mem': 'VirtioMEMDeviceInfo'
|
2018-03-11 06:02:12 +03:00
|
|
|
}
|
|
|
|
}
|
2018-02-27 02:13:27 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @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'] }
|
|
|
|
|
2020-06-26 10:22:44 +03:00
|
|
|
##
|
|
|
|
# @MEMORY_DEVICE_SIZE_CHANGE:
|
|
|
|
#
|
|
|
|
# Emitted when the size of a memory device changes. Only emitted for memory
|
|
|
|
# devices that can actually change the size (e.g., virtio-mem due to guest
|
|
|
|
# action).
|
|
|
|
#
|
|
|
|
# @id: device's ID
|
|
|
|
# @size: the new size of memory that the device provides
|
|
|
|
#
|
|
|
|
# Note: this event is rate-limited.
|
|
|
|
#
|
|
|
|
# Since: 5.1
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# <- { "event": "MEMORY_DEVICE_SIZE_CHANGE",
|
|
|
|
# "data": { "id": "vm0", "size": 1073741824},
|
|
|
|
# "timestamp": { "seconds": 1588168529, "microseconds": 201316 } }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'event': 'MEMORY_DEVICE_SIZE_CHANGE',
|
|
|
|
'data': { '*id': 'str', 'size': 'size' } }
|
|
|
|
|
|
|
|
|
2018-02-27 02:13:27 +03:00
|
|
|
##
|
|
|
|
# @MEM_UNPLUG_ERROR:
|
|
|
|
#
|
|
|
|
# Emitted when memory hot unplug error occurs.
|
|
|
|
#
|
|
|
|
# @device: device name
|
|
|
|
#
|
|
|
|
# @msg: Informative message
|
|
|
|
#
|
|
|
|
# Since: 2.4
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# <- { "event": "MEM_UNPLUG_ERROR"
|
|
|
|
# "data": { "device": "dimm1",
|
|
|
|
# "msg": "acpi: device unplug for unsupported device"
|
|
|
|
# },
|
|
|
|
# "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'event': 'MEM_UNPLUG_ERROR',
|
|
|
|
'data': { 'device': 'str', 'msg': 'str' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @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: 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'] }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @ACPI_DEVICE_OST:
|
|
|
|
#
|
|
|
|
# Emitted when guest executes ACPI _OST method.
|
|
|
|
#
|
2018-02-11 12:36:05 +03:00
|
|
|
# @info: OSPM Status Indication
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# Since: 2.1
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# <- { "event": "ACPI_DEVICE_OST",
|
|
|
|
# "data": { "device": "d1", "slot": "0",
|
|
|
|
# "slot-type": "DIMM", "source": 1, "status": 0 } }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'event': 'ACPI_DEVICE_OST',
|
|
|
|
'data': { 'info': 'ACPIOSTInfo' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @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' ] }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @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
|
2020-02-13 20:56:26 +03:00
|
|
|
# data. See xen-save-devices-state.txt for a description of the binary
|
|
|
|
# format.
|
2018-02-27 02:13:27 +03:00
|
|
|
#
|
|
|
|
# Since: 2.7
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# -> { "execute": "xen-load-devices-state",
|
|
|
|
# "arguments": { "filename": "/tmp/resume" } }
|
|
|
|
# <- { "return": {} }
|
|
|
|
#
|
|
|
|
##
|
|
|
|
{ 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @GuidInfo:
|
|
|
|
#
|
|
|
|
# GUID information.
|
|
|
|
#
|
|
|
|
# @guid: the globally unique identifier
|
|
|
|
#
|
|
|
|
# Since: 2.9
|
|
|
|
##
|
|
|
|
{ 'struct': 'GuidInfo', 'data': {'guid': 'str'} }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-vm-generation-id:
|
|
|
|
#
|
|
|
|
# Show Virtual Machine Generation ID
|
|
|
|
#
|
|
|
|
# Since: 2.9
|
|
|
|
##
|
|
|
|
{ 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
|
2018-03-08 15:48:42 +03:00
|
|
|
|