From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Damien Hedde <damien.hedde@greensocs.com>,
Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: qom device lifecycle interaction with hotplug/hotunplug ?
Date: Fri, 29 Nov 2019 13:40:55 +0100 [thread overview]
Message-ID: <20191129134055.08f27e7a@redhat.com> (raw)
In-Reply-To: <20191128163358.GC14595@habkost.net>
On Thu, 28 Nov 2019 13:33:58 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Thu, Nov 28, 2019 at 04:00:06PM +0000, Peter Maydell 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) ?
>
> Your description seems accurate, and I agree it is confusing.
>
> It would be more consistent if realized=true didn't plug the
> device automatically, and qdev_device_add() asked the hotplug
> handler to plug the device instead.
agreed, it's confusing. But that would not allow to
o = object_new()
set props
o.realize()
reuse the same plug handlers.
we potentially can convert it to device_add input arguments
and then call qdev_device_add() instead, which would then
handle plug handlers, not sure it's doable though.
Other than that I don't have any ideas how to make it less confusing.
> > 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 ?
>
> My interpretation is that this is valid in theory, but likely to
> crash a large portion of our devices if we tried it.
>
next prev parent reply other threads:[~2019-11-29 12:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-28 16:00 qom device lifecycle interaction with hotplug/hotunplug ? Peter Maydell
2019-11-28 16:33 ` Eduardo Habkost
2019-11-29 12:40 ` Igor Mammedov [this message]
2019-11-29 19:53 ` Eduardo Habkost
2019-11-28 17:27 ` Igor Mammedov
2019-11-28 17:57 ` Peter Maydell
2019-11-29 12:26 ` Igor Mammedov
2019-11-29 12:45 ` Peter Maydell
2019-11-29 13:05 ` Damien Hedde
2019-11-29 14:23 ` Igor Mammedov
2019-11-29 20:05 ` Eduardo Habkost
2019-11-30 11:10 ` Peter Maydell
2019-12-03 21:40 ` Eduardo Habkost
2019-12-04 9:18 ` Jens Freimann
2019-12-04 14:35 ` Eduardo Habkost
2019-12-04 16:21 ` Jens Freimann
2019-12-04 18:51 ` Eduardo Habkost
2019-12-11 12:52 ` Damien Hedde
2019-12-18 15:14 ` Jens Freimann
2019-12-11 16:01 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191129134055.08f27e7a@redhat.com \
--to=imammedo@redhat.com \
--cc=damien.hedde@greensocs.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.