On Thu, 28 Nov 2019 16:00:06 +0000
Peter Maydell <peter.mayd...@linaro.org> wrote:
> Hi; this is a question which came up in Damien's reset series
> which I don't know the answer to:
>
> What is the interaction of the QOM device lifecycle (instance_init/realize/
> unrealize/instance_finalize) with hotplug and hot-unplug ? I couldn't
> find any documentation of this but maybe I was looking in the wrong
> place...
>
> Looking at device_set_realized() it seems like we treat "realize"
> as meaning "and also do the hot-plug if this is a device we're
> trying to hotplug". On the other hand hot-unplug is I think the
> other way around: when we get a hot-unplug event we assume that
> it should also imply an "unrealize" (but just unrealizing doesn't
> auto-hot-unplug) ?
Let me try to describe it.
device 'hotplug' interface is poorly named nowadays as it's
just 'plug' interface which checks/wires device into existing machine.
'hotplug' attribute is just informs plug controller that it might
wish to take additional actions to complete device initialization
and notify guest.
plug workflow is as follow:
DeviceState::realize()
hotplug_ctrl = qdev_get_hotplug_handler(dev);
hotplug_handler_pre_plug(hotplug_ctrl, dev) // check / prepare / reserve
resources, can fail
// call concrete device realize_fn()
hotplug_handler_plug(hotplug_ctrl, dev) // wire device up to
board/bus/notify guest, shouldn't fail
* now old bus based qdev hotplug are tied to _plug callback that
controller (hotplug_ctrl) that owns bus sets during bus creation.
(Ideally we should split that on _pre_plug and _plug parts)
* also any other QOM object could be controller, to allow buss-less
hotplug (ex: arm-virt machine or pc/q35 machines)
Unplug is a different beast, it could be originated from mgmt side
device_del() and/or from guest side.
device_del() can go 2 ways: qdev_unplug()
* devices that support surprise removal (i.e. does not require guest
cooperation)
go directly to
hotplug_handler_unplug() // tear down device from machine
object_unparent(); -> unrealize() + finalize() // device gone
essentially it's old qdev code behavior as is.
* async removal a bit different, instead of removal it asks
controller to process unplug request hotplug_handler_unplug_request()
and does nothing else.
After guest is prepared to device removal it notifies QEMU in some way
to eject device. That calls the same sequence
hotplug_handler_unplug()
object_unparent()
> Once a device is hot-unplugged (and thus unrealized) is it valid
> for it to be re-hot-plugged, or is the assumption that it's then
> destroyed and a fresh device is created if the user wants to plug
> something in again later ? Put another way, is it valid for a qdev
> device to see state transitions realize -> unrealize -> realize ?
I don't think we do it currently (or maybe we do with failover but
I missed that train), but I don't see why it can't be done.
I theory it's upto the place where actual eject request is originated from,
it could do unrealize -> realize instead of unparent as far as it calls
hotplug_handler_unplug().
>
> thanks
> -- PMM
>
