| Message ID | 20230213140103.1518173-17-vsementsov@yandex-team.ru |
|---|---|
| State | New |
| Headers | show |
| Series | pci hotplug tracking | expand |
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 <vsementsov@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? > @@ -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); > + }
Philippe Mathieu-Daudé <philmd@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 <vsementsov@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); >> + }
On 14.02.23 11:58, Markus Armbruster wrote: > Philippe Mathieu-Daudé<philmd@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<vsementsov@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. > If we agree to depreacte "device", we probably can deprecate "path" too, and add duplicating "qom-path" to other events. So, we'll have a consistent and clear API.
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' } } diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c index 08ac37581e..efa90e9e6e 100644 --- a/hw/pci/pcie.c +++ b/hw/pci/pcie.c @@ -47,6 +47,13 @@ static bool pcie_sltctl_powered_off(uint16_t sltctl) && (sltctl & PCI_EXP_SLTCTL_PIC) == PCI_EXP_SLTCTL_PWR_IND_OFF; } +static bool pcie_sltctl_powered_on(uint16_t sltctl) +{ + return (sltctl & PCI_EXP_SLTCTL_PCC) == PCI_EXP_SLTCTL_PWR_ON && + (sltctl & PCI_EXP_SLTCTL_PIC) == PCI_EXP_SLTCTL_PWR_IND_ON && + (sltctl & PCI_EXP_SLTCTL_AIC) == PCI_EXP_SLTCTL_ATTN_IND_OFF; +} + static LedActivity pcie_led_state_to_qapi(uint16_t value) { switch (value) { @@ -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); + } + /* * If the slot is populated, power indicator is off and power * controller is off, it is safe to detach the devices. diff --git a/hw/pci/shpc.c b/hw/pci/shpc.c index 70447bba08..105be8f1c1 100644 --- a/hw/pci/shpc.c +++ b/hw/pci/shpc.c @@ -299,6 +299,12 @@ static bool shpc_slot_is_off(uint8_t state, uint8_t power, uint8_t attn) return state == SHPC_STATE_DISABLED && power == SHPC_LED_OFF; } +static bool shpc_slot_is_on(uint8_t state, uint8_t power, uint8_t attn) +{ + return state == SHPC_STATE_ENABLED && power == SHPC_LED_ON && + attn == SHPC_LED_OFF; +} + static void shpc_slot_command(PCIDevice *d, uint8_t target, uint8_t state, uint8_t power, uint8_t attn) { @@ -366,6 +372,12 @@ static void shpc_slot_command(PCIDevice *d, uint8_t target, SHPC_SLOT_EVENT_MRL | SHPC_SLOT_EVENT_PRESENCE; } + + if (!shpc_slot_is_on(old_state, old_power, old_attn) && + shpc_slot_is_on(state, power, attn) && child_dev) + { + qapi_event_send_device_on(child_dev->canonical_path); + } } static void shpc_command(PCIDevice *d)
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 <vsementsov@yandex-team.ru> --- qapi/qdev.json | 13 +++++++++++++ hw/pci/pcie.c | 13 +++++++++++++ hw/pci/shpc.c | 12 ++++++++++++ 3 files changed, 38 insertions(+)