[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler

From: David Hildenbrand
Subject: Re: [Qemu-ppc] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler
Date: Mon, 8 Oct 2018 14:41:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 08/10/2018 14:19, Igor Mammedov wrote:
> On Mon, 8 Oct 2018 13:47:53 +0200
> David Hildenbrand <address@hidden> 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.



David / dhildenb

reply via email to

[Prev in Thread] Current Thread [Next in Thread]