All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Hedde <damien.hedde@greensocs.com>
To: qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, berrange@redhat.com,
	ehabkost@redhat.com, cohuck@redhat.com,
	mark.burton@greensocs.com, qemu-s390x@nongnu.org,
	edgari@xilinx.com, qemu-arm@nongnu.org, pbonzini@redhat.com,
	philmd@redhat.com, david@gibson.dropbear.id.au
Subject: Re: [PATCH v5 07/13] hw/core/qdev: update hotplug reset regarding resettable
Date: Fri, 8 Nov 2019 16:14:00 +0100	[thread overview]
Message-ID: <47ae7c6f-36ab-8422-9438-b6d26e3695ce@greensocs.com> (raw)
In-Reply-To: <20191018150630.31099-8-damien.hedde@greensocs.com>


On 10/18/19 5:06 PM, Damien Hedde wrote:
> This commit make use of the resettable API to reset the device being
> hotplugged during when it is realized. Also it make sure it is put in
> a reset state coherent with the parent it is plugged into.
> 
> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>
> ---
> 
> I'm not sure I've done everything that's required here since I do not
> understand everything that's behind the hotplug and realize/unrealize.
> I'm a bit lost there...
> 
> One of the remaining question is: do we need to do things related to
> unrealize ?
> It seems, a device can be realized, unrealized, and re-realized ? But
> is that true also for a hotplugged device ?>
> Also resettable API is called there, so children if any are reset too.
> This was not the case before, this a probably not a big deal, as long
> as all children are realized too at this point. I'm not sure we have a
> guarantee on this; the recursive realize is not done in the base bus
> class so it will go only down to first buses level if it is not
> propagated by bus subclasses. Do hotplug devices can have more than
> single level bus subtree (ie: more than some child buses with no
> devices on them) ?
> ---
>  hw/core/qdev.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> index 3933f62d0c..c5d107ea4e 100644
> --- a/hw/core/qdev.c
> +++ b/hw/core/qdev.c
> @@ -930,7 +930,14 @@ static void device_set_realized(Object *obj, bool value, Error **errp)
>              }
>          }
>          if (dev->hotplugged) {

Just thinking that if it is possible to have un-realize then realize
cycle, we probably need some code here (or even before realizing
children) to ensure the reset state is zeroed before doing the following.

> -            device_legacy_reset(dev);
> +            /*
> +             * Reset the device, as well as its subtree which should be
> +             * realized too
> +             */
> +            resettable_assert_reset(OBJECT(dev), RESET_TYPE_COLD);
> +            resettable_change_parent(OBJECT(dev), OBJECT(dev->parent_bus),
> +                                     NULL);
> +            resettable_release_reset(OBJECT(dev), RESET_TYPE_COLD);
>          }
>          dev->pending_deleted_event = false;
>  
>

--
Damien



  reply	other threads:[~2019-11-08 15:34 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18 15:06 [PATCH v5 00/13] Multi-phase reset mechanism Damien Hedde
2019-10-18 15:06 ` [PATCH v5 01/13] add device_legacy_reset function to prepare for reset api change Damien Hedde
2019-10-19 17:35   ` Richard Henderson
2019-12-03 10:55   ` Cornelia Huck
2019-10-18 15:06 ` [PATCH v5 02/13] hw/core/qdev: add trace events to help with resettable transition Damien Hedde
2019-10-19 17:44   ` Richard Henderson
2019-10-31 23:23   ` Philippe Mathieu-Daudé
2019-11-04 12:16     ` Damien Hedde
2019-11-04 14:33       ` Philippe Mathieu-Daudé
2019-12-03 10:57   ` Cornelia Huck
2019-10-18 15:06 ` [PATCH v5 03/13] hw/core: create Resettable QOM interface Damien Hedde
2019-11-29 18:32   ` Peter Maydell
2019-12-02 11:07     ` Damien Hedde
2019-12-02 11:14       ` Peter Maydell
2019-12-03 11:16   ` Cornelia Huck
2019-10-18 15:06 ` [PATCH v5 04/13] hw/core: add Resettable support to BusClass and DeviceClass Damien Hedde
2019-10-19 18:49   ` Richard Henderson
2019-11-29 18:36   ` Peter Maydell
2019-12-02 11:38     ` Damien Hedde
2019-10-18 15:06 ` [PATCH v5 05/13] hw/core/resettable: add support for changing parent Damien Hedde
2019-11-29 18:38   ` Peter Maydell
2019-12-02 11:43     ` Damien Hedde
2019-10-18 15:06 ` [PATCH v5 06/13] hw/core/qdev: handle parent bus change regarding resettable Damien Hedde
2019-11-29 18:41   ` Peter Maydell
2019-12-03 11:37     ` Cornelia Huck
2019-10-18 15:06 ` [PATCH v5 07/13] hw/core/qdev: update hotplug reset " Damien Hedde
2019-11-08 15:14   ` Damien Hedde [this message]
2019-10-18 15:06 ` [PATCH v5 08/13] hw/core: deprecate old reset functions and introduce new ones Damien Hedde
2019-10-31 23:35   ` Philippe Mathieu-Daudé
2019-11-04 12:01     ` Damien Hedde
2019-11-04 15:42       ` Philippe Mathieu-Daudé
2019-11-29 18:42   ` Peter Maydell
2019-10-18 15:06 ` [PATCH v5 09/13] docs/devel/reset.txt: add doc about Resettable interface Damien Hedde
2019-11-29 19:00   ` Peter Maydell
2019-12-06 15:40     ` Damien Hedde
2019-12-06 16:21     ` Damien Hedde
2019-10-18 15:06 ` [PATCH v5 10/13] vl: replace deprecated qbus_reset_all registration Damien Hedde
2019-11-29 19:01   ` Peter Maydell
2019-10-18 15:06 ` [PATCH v5 11/13] hw/s390x/ipl: replace deprecated qdev_reset_all registration Damien Hedde
2019-10-31 23:38   ` Philippe Mathieu-Daudé
2019-11-29 19:02   ` Peter Maydell
2019-12-03 11:41   ` Cornelia Huck
2019-10-18 15:06 ` [PATCH v5 12/13] hw/gpio/bcm2835_gpio: Isolate sdbus reparenting Damien Hedde
2019-11-29 19:05   ` Peter Maydell
2019-12-02 12:27     ` Damien Hedde
2019-12-02 12:33       ` Peter Maydell
2019-12-02 13:05         ` Damien Hedde
2019-12-02 13:10           ` Peter Maydell
2019-10-18 15:06 ` [PATCH v5 13/13] hw/gpio/bcm2835_gpio: Update to resettable Damien Hedde
2019-11-29 19:02   ` Peter Maydell
2019-10-19  9:01 ` [PATCH v5 00/13] Multi-phase reset mechanism no-reply
2019-10-29 15:53 ` Damien Hedde
2019-11-08 15:26   ` Damien Hedde
2019-11-08 15:28     ` Peter Maydell
2019-11-08 15:58       ` Damien Hedde
2019-11-29 19:07 ` Peter Maydell
2019-12-03 11:44 ` Cornelia Huck

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=47ae7c6f-36ab-8422-9438-b6d26e3695ce@greensocs.com \
    --to=damien.hedde@greensocs.com \
    --cc=berrange@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=edgari@xilinx.com \
    --cc=ehabkost@redhat.com \
    --cc=mark.burton@greensocs.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    /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.