Re: [PATCH v3 14/15] qapi: introduce DEVICE_ON event

[Markus Armbruster <armbru@redhat.com>]

Vladimir Sementsov-Ogievskiy <vsementsov@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 <vsementsov@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.

[...]