Philippe Mathieu-Daudé <phi...@linaro.org> writes: > On 13/2/23 15:01, Vladimir Sementsov-Ogievskiy wrote: >> We have DEVICE_DELETED event, that signals that device_del command is >> actually completed. 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 | 13 +++++++++++++ >> hw/pci/pcie.c | 13 +++++++++++++ >> hw/pci/shpc.c | 12 ++++++++++++ >> 3 files changed, 38 insertions(+) >> diff --git a/qapi/qdev.json b/qapi/qdev.json >> index b6ad311dd4..2143bb2792 100644 >> --- a/qapi/qdev.json >> +++ b/qapi/qdev.json >> @@ -341,3 +341,16 @@ >> { 'command': 'query-hotplug', >> 'data': { 'id': 'str' }, >> 'returns': 'HotplugInfo' } >> + >> +## >> +# @DEVICE_ON: >> +# >> +# Emitted whenever the device insertion completion is acknowledged by the >> guest. >> +# For now only emitted for SHPC and PCIe-native hotplug. >> +# >> +# @path: the hotplugged device's QOM path >> +# >> +# Since: 8.0 >> +## >> +{ 'event': 'DEVICE_ON', >> + 'data': { 'path': 'str' } } > > Could 'qom-path' or 'canonical-path' be more meaningful here?
@qom-path would be clearer, no doubt. But @path is consistent with the closely related DEVICE_DELETED event. >> @@ -816,6 +823,12 @@ void pcie_cap_slot_write_config(PCIDevice *dev, >> qdev_hotplug_state_event(DEVICE(dev), NULL, child_dev, >> &changed_state); >> } >> + if ((sltsta & PCI_EXP_SLTSTA_PDS) && pcie_sltctl_powered_on(val) && >> + !pcie_sltctl_powered_on(old_slt_ctl) && child_dev) >> + { >> + qapi_event_send_device_on(child_dev->canonical_path); >> + }