[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.
- Re: [Qemu-ppc] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler, Igor Mammedov, 2018/10/01
- Re: [Qemu-ppc] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler, David Hildenbrand, 2018/10/02
- Re: [Qemu-ppc] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler, David Hildenbrand, 2018/10/08
- Re: [Qemu-ppc] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler, Igor Mammedov, 2018/10/08
- Re: [Qemu-ppc] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler, David Hildenbrand, 2018/10/08
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler,
Igor Mammedov <=
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler, David Hildenbrand, 2018/10/11
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler, Igor Mammedov, 2018/10/12
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler, David Hildenbrand, 2018/10/12
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler, Igor Mammedov, 2018/10/12
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler, David Hildenbrand, 2018/10/15