[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: qom device lifecycle interaction with hotplug/hotunplug ?
From: |
Peter Maydell |
Subject: |
Re: qom device lifecycle interaction with hotplug/hotunplug ? |
Date: |
Thu, 28 Nov 2019 17:57:56 +0000 |
On Thu, 28 Nov 2019 at 17:27, Igor Mammedov <address@hidden> wrote:
>
> On Thu, 28 Nov 2019 16:00:06 +0000
> Peter Maydell <address@hidden> wrote:
> > 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.
Well, as Eduardo says, if we don't currently do it then
we probably have a lot of subtly buggy code. Requiring it to work
imposes a requirement on the 'unrealize' function that it
doesn't just do required cleanup/resource releasing actions,
but also returns the device back to exactly the state it was in
after instance_init, so that 'realize' will work correctly.
That's quite a lot of code auditing/effort if we don't actually
have a current or future use for making this work, rather than
just requiring that an unrealized device object is immediately
finalized without possibility of resurrection.
If we do have a plausible usecase then I think we should document
that unrealize needs to handle this, and also have a basic
smoke test of the realize->unrealize->realize.
thanks
-- PMM