> That way using [2] and [1 - modulo it should match only concrete type] > machine would be able to override hotplug handlers for TYPE_VIRTIO_PMEM_PCI > and explicitly call machine + pci hotplug handlers in necessary order. > > flow would look like: > [acpi|shcp|native pci-e eject]-> > hotplug_ctrl = qdev_get_hotplug_handler(dev); > hotplug_handler_unplug(hotplug_ctrl, dev, &local_err); -> > machine_unplug() > machine_virtio_pci_pmem_cb(): > // we now that's device has 2 stage hotplug handlers, > // so we can arrange hotplug sequence in necessary order > hotplug_ctrl2 = qdev_get_bus_hotplug_handler(dev); > > //then do unplug in whatever order that's correct, > // I'd assume tear down/stop PCI device first, flushing > // command virtio command queues and that unplug memory > itself. > hotplug_handler_unplug(hotplug_ctrl2, dev, &local_err); > memory_device_unplug() >
Looking into the details, this order is not possible. The unplug will essentially do a device_unparent() leading to the whole hierarchy getting destroyed. The memory_device part always has to come first. > Similar logic applies to device_add/device_del paths, with a difference that > origin point would be monitor/qmp. > > Point is to have a single explicit callback chain that applies to a concrete > device type. That way if ever change an ordering of calling plug callbacks > in qdev core, the expected for a device callback sequence would still > remain in place ensuring that device (un)plugged as expected. > > Also it should be easier to trace for a reader, than 2 disjoint callbacks of > composite device (which only know to author of that device and then only > till he/she remembers how that thing works). > -- Thanks, David / dhildenb
