On 08/10/2018 14:19, Igor Mammedov wrote: > On Mon, 8 Oct 2018 13:47:53 +0200 > David Hildenbrand <da...@redhat.com> wrote: > >>> 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. > > Question here is if there are anything that should be handled first on > virtio level before memory_device/pmem part is called? > If there isn't it might be fine to swap the order of unplug sequence. >
Was asking myself the same thing, but as we are effectively holding the iothread lock and the guest triggered the unplug, I guess it is fine to unregister the memory region at this point. -- Thanks, David / dhildenb
