qemu/qapi/qdev.json
Kevin Wolf 5dacda5167 vl: Enable JSON syntax for -device
Like we already do for -object, introduce support for JSON syntax in
-device, which can be kept stable in the long term and guarantees that a
single code path with identical behaviour is used for both QMP and the
command line. Compared to the QemuOpts based code, the parser contains
less surprises and has support for non-scalar options (lists and
structs). Switching management tools to JSON means that we can more
easily change the "human" CLI syntax from QemuOpts to the keyval parser
later.

In the QAPI schema, a feature flag is added to the device-add command to
allow management tools to detect support for this.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20211008133442.141332-16-kwolf@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-10-15 16:11:22 +02:00

159 lines
4.3 KiB
Python

# -*- Mode: Python -*-
# vim: filetype=python
#
# This work is licensed under the terms of the GNU GPL, version 2 or later.
# See the COPYING file in the top-level directory.
##
# = Device infrastructure (qdev)
##
{ 'include': 'qom.json' }
##
# @device-list-properties:
#
# List properties associated with a device.
#
# @typename: the type name of a device
#
# Returns: a list of ObjectPropertyInfo describing a devices properties
#
# Note: objects can create properties at runtime, for example to describe
# links between different devices and/or objects. These properties
# are not included in the output of this command.
#
# Since: 1.2
##
{ 'command': 'device-list-properties',
'data': { 'typename': 'str'},
'returns': [ 'ObjectPropertyInfo' ] }
##
# @device_add:
#
# Add a device.
#
# @driver: the name of the new device's driver
#
# @bus: the device's parent bus (device tree path)
#
# @id: the device's ID, must be unique
#
# Features:
# @json-cli: If present, the "-device" command line option supports JSON
# syntax with a structure identical to the arguments of this
# command.
#
# Notes:
#
# Additional arguments depend on the type.
#
# 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
'features': ['json-cli'] }
##
# @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. If a guest-side error in the hot removal process is
# detected, the device will not be removed and a DEVICE_UNPLUG_GUEST_ERROR
# event is sent. Some errors cannot be detected.
#
# Since: 0.14
#
# 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'} }
##
# @DEVICE_DELETED:
#
# Emitted whenever the device removal completion is acknowledged by the guest.
# At this point, it's safe to reuse the specified device ID. Device removal can
# be initiated by the guest or by HMP/QMP commands.
#
# @device: the device's ID if it has one
#
# @path: the device's QOM path
#
# Since: 1.5
#
# Example:
#
# <- { "event": "DEVICE_DELETED",
# "data": { "device": "virtio-net-pci-0",
# "path": "/machine/peripheral/virtio-net-pci-0" },
# "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
#
##
{ 'event': 'DEVICE_DELETED',
'data': { '*device': 'str', 'path': 'str' } }
##
# @DEVICE_UNPLUG_GUEST_ERROR:
#
# Emitted when a device hot unplug fails due to a guest reported error.
#
# @device: the device's ID if it has one
#
# @path: the device's QOM path
#
# Since: 6.2
#
# Example:
#
# <- { "event": "DEVICE_UNPLUG_GUEST_ERROR"
# "data": { "device": "core1",
# "path": "/machine/peripheral/core1" },
# },
# "timestamp": { "seconds": 1615570772, "microseconds": 202844 } }
#
##
{ 'event': 'DEVICE_UNPLUG_GUEST_ERROR',
'data': { '*device': 'str', 'path': 'str' } }