qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH v4 18/24] qdev: hotplug: provide do_u


From: Igor Mammedov
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler
Date: Mon, 8 Oct 2018 16:12:29 +0200

On Mon, 8 Oct 2018 14:41:50 +0200
David Hildenbrand <address@hidden> wrote:

> 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.
It looks the same to me but I'm not familiar with virtio or PCI.
I'd ask Michael if it's safe thing to do.





reply via email to

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