All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Igor Mammedov <imammedo@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 16:53:43 -0300	[thread overview]
Message-ID: <20191129195343.GF14595@habkost.net> (raw)
In-Reply-To: <20191129134055.08f27e7a@redhat.com>

On Fri, Nov 29, 2019 at 01:40:55PM +0100, Igor Mammedov wrote:
> 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.
> 

I thought we had very few places that set realized=true directly,
so changing this behavior would be easy.

I was mistaken.  Grepping for 'set_bool.*"realized"' found more
than 300 matches.

> 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.

We could introduce a "plugged" property which implicitly calls
the hotplug handler, and run a global s/"realized"/"plugged"/
substitution in the whole tree.  Would it be worth the trouble,
though?

-- 
Eduardo



  reply	other threads:[~2019-11-29 19:57 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
2019-11-29 19:53     ` Eduardo Habkost [this message]
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=20191129195343.GF14595@habkost.net \
    --to=ehabkost@redhat.com \
    --cc=damien.hedde@greensocs.com \
    --cc=imammedo@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.