Re: qom device lifecycle interaction with hotplug/hotunplug ?

[Igor Mammedov <imammedo@redhat.com>]

On Fri, 29 Nov 2019 14:05:23 +0100
Damien Hedde <damien.hedde@greensocs.com> wrote:

> On 11/29/19 1:45 PM, Peter Maydell wrote:
> > On Fri, 29 Nov 2019 at 12:26, Igor Mammedov <imammedo@redhat.com> wrote:  
> >> But from the my very limited understanding, on real hardware,
> >> once device is uplugged it's gone (finalized) from machine
> >> perspective, so it's unclear to my why someone would use
> >> realize->unrealize->realize hotplug scenario.  
> > 
> > Well, on real hardware 'unplug' is different from 'unrealize'.
> > So I think for QEMU if we wanted to allow this sort of 'unplug
> > and replug the same device' we should do it by:
> > 
> >  instance_init -> realize -> plug -> unplug -> plug -> unplug ->
> >    unrealize -> finalize
> > 
> > So unrealize/finalize is when the device is actually destroyed,
> > and if you're going to replug the device you don't destroy it
> > on unplug.
> >   
> 
> Hello everybody,
> 
> What I was initially wondering (or afraid of) when this question/problem
> comes to me is;
> Are there some cases where QEMU does the following (in the context of an
> hotplugged device):
> 
> instance_init -> realize (and plug) -> unrealize -> change some
> properties -> realize
> with no unplug / plug in between

not that I know of (at least not with device_add/del)

> because I have the impression, the realize was here to allow setting
> properties.

in theory it should be
 instance_init -> set properties -> realize
and ping pong realize <-> unrealize, should work as far the device
in question takes that in consideration.

In practice for generic arbitrary device it probably won't work
out of the box since people tended to put too much in realize
and didn't care about proper cleanup since device in question
typically is destroyed right after unrealize.

So it's probably implementable for some internal device
if it doesn't use device_add/del, otherwise millage might vary.

> But it may be pure nonsense as I do not know well the
> underlying mechanisms there.
> 
> Regards,
> --
> Damien
>