[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 13:47:53 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 |
> 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
- 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 <=
- 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, 2018/10/08
- 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