qemu-cr16/qapi/qdev.json

# -*- 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.
#
# @json-cli-hotplug: If present, the "-device" command line option
#     supports JSON syntax without the reference counting leak that
#     broke hot-unplug
#
# .. admonition:: Notes
#
#     1. Additional arguments depend on the type.
#
#     2. For detailed information about this command, please refer to
#        the 'docs/qdev-device-use.txt' file.
#
#     3. 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.
#
# .. qmp-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', 'json-cli-hotplug'] }

##
# @device_del:
#
# Remove a device from a guest
#
# @id: the device's ID or QOM path
#
# Errors:
#     - If @id is not a valid device, DeviceNotFound
#
# .. note:: 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
#
# .. qmp-example::
#
#     -> { "execute": "device_del",
#          "arguments": { "id": "net1" } }
#     <- { "return": {} }
#
# .. qmp-example::
#
#     -> { "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
#
# .. qmp-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
#
# .. qmp-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' } }

##
# @device-sync-config:
#
# Synchronize device configuration from host to guest part.  First,
# copy the configuration from the host part (backend) to the guest
# part (frontend).  Then notify guest software that device
# configuration changed.
#
# The command may be used to notify the guest about block device
# capacity change.  Currently only vhost-user-blk device supports
# this.
#
# @id: the device's ID or QOM path
#
# Features:
#
# @unstable: The command is experimental.
#
# Since: 9.2
##
{ 'command': 'device-sync-config',
  'features': [ 'unstable' ],
  'data': {'id': 'str'} }