Ping.
And some addition. We have the case, when the commit
commit 7bed89958bfbf40df9ca681cefbdca63abdde39d
Author: Maxim Levitsky <mlevitsk@redhat.com>
Date: Tue Oct 6 14:38:58 2020 +0200
device_core: use drain_call_rcu in in qmp_device_add
Soon, a device removal might only happen on RCU callback execution.
This is okay for device-del which provides a DEVICE_DELETED event,
but not for the failure case of device-add. To avoid changing
monitor semantics, just drain all pending RCU callbacks on error.
sensibly slows down vm initialization (several calls to device_add of pc-dimm).
And looking at commit message, I see that what I do in the series is exactly a
suggestion to change monitor semantics.
What do you think?
Maybe we need a boolean "async" parameter for device_add, which will turn off
drain_call_rcu() call and rely on user to handle DEVICE_ON?
On 05.10.23 12:29, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
Main thing this series does is DEVICE_ON event - a counter-part to
DEVICE_DELETED. A guest-driven event that device is powered-on.
Details are in patch 2. The new event is paried with corresponding
command query-hotplug.
v8:
- improve naming, wording and style
- make new QMP interface experimental
Vladimir Sementsov-Ogievskiy (4):
qapi/qdev.json: unite DEVICE_* event data into single structure
qapi: add DEVICE_ON and query-hotplug infrastructure
shpc: implement DEVICE_ON event and query-hotplug
pcie: implement DEVICE_ON event and query-hotplug
hw/core/hotplug.c | 12 +++
hw/pci-bridge/pci_bridge_dev.c | 14 +++
hw/pci-bridge/pcie_pci_bridge.c | 1 +
hw/pci/pcie.c | 83 +++++++++++++++
hw/pci/pcie_port.c | 1 +
hw/pci/shpc.c | 86 +++++++++++++++
include/hw/hotplug.h | 11 ++
include/hw/pci/pci_bridge.h | 2 +
include/hw/pci/pcie.h | 2 +
include/hw/pci/shpc.h | 2 +
include/hw/qdev-core.h | 7 ++
include/monitor/qdev.h | 6 ++
qapi/qdev.json | 178 +++++++++++++++++++++++++++++---
softmmu/qdev-monitor.c | 58 +++++++++++
14 files changed, 451 insertions(+), 12 deletions(-)