Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru> writes: > On 10.02.23 00:37, Philippe Mathieu-Daudé wrote: >> On 9/2/23 21:08, Vladimir Sementsov-Ogievskiy wrote: >>> We have DEVICE_DELETED event, that signals that device_del command is >>> actually complited. But we don't have a counter-part for device_add. >>> Still it's sensible for SHPC and PCIe-native hotplug, as there are time >>> when the device in some intermediate state. Let's add an event that say >>> that the device is finally powered on, power indicator is on and >>> everything is OK for next manipulation on that device. >>> >>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru> >>> --- >>> qapi/qdev.json | 24 ++++++++++++++++++++++++ >>> hw/pci/pcie.c | 12 ++++++++++++ >>> hw/pci/shpc.c | 12 ++++++++++++ >>> 3 files changed, 48 insertions(+) >>> >>> diff --git a/qapi/qdev.json b/qapi/qdev.json >>> index 40dc34f091..94da7ca228 100644 >>> --- a/qapi/qdev.json >>> +++ b/qapi/qdev.json >>> @@ -220,3 +220,27 @@ >>> ## >>> { 'event': 'HOTPLUG_STATE', >>> 'data': 'HotplugState' } >>> + >>> + >>> +## >>> +# @DEVICE_ON: >>> +# >>> +# Emitted whenever the device insertion completion is acknowledged by the >>> guest. >>> +# For now only emitted for SHPC and PCIe-native hotplug. >>> +# >>> +# @device: device name
Make that "the device's ID if it has one", and ... >>> +# >>> +# @path: device path ... "the device's QOM path", please. >>> +# >>> +# Since: 8.0 >>> +# >>> +# Example: >>> +# >>> +# <- { "event": "DEVICE_ON", >>> +# "data": { "device": "virtio-net-pci-0", >>> +# "path": "/machine/peripheral/virtio-net-pci-0" }, >> >> Why provide both device & path? Could the type_name be helpful? > > I just follow DEVICE_DELETED event. Not sure that it's the best thing to do) The device ID is redundant, since the QOM path of a device with an ID is /machine/peripheral/ID. Fine print: code could conceivably violate this invariant. But code should *not* create devices with IDs. IDs are strictly for the user. We commonly send both device ID and QOM path, mostly for historical reasons: the former precede the latter. There are exceptions, such as query-cpus-fast. Can't say offhand whether CPUs can be created with IDs. It's probably best to remain consistent with DEVICE_DELETED here. I'd be in favour of deprecating and deleting redundant device IDs in QMP output. [...]