Re: qom device lifecycle interaction with hotplug/hotunplug ?

[Igor Mammedov]

On Thu, 28 Nov 2019 16:00:06 +0000
Peter Maydell <address@hidden> 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
>