qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Damien Hedde <damien.hedde@greensocs.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	qemu-s390x <qemu-s390x@nongnu.org>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Mark Burton" <mark.burton@greensocs.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Edgar Iglesias" <edgari@xilinx.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v5 06/13] hw/core/qdev: handle parent bus change regarding resettable
Date: Fri, 29 Nov 2019 18:41:26 +0000	[thread overview]
Message-ID: <CAFEAcA981i_W=8y+7_8JV=oMLT51TBMB8bTJJaiJJZqj6MuSAQ@mail.gmail.com> (raw)
In-Reply-To: <20191018150630.31099-7-damien.hedde@greensocs.com>

On Fri, 18 Oct 2019 at 16:07, Damien Hedde <damien.hedde@greensocs.com> wrote:
>
> In qdev_set_parent_bus(), when changing the parent bus of a
> realized device, if the source and destination buses are not in the
> same reset state, some adaptation are required. This patch adds

"adaptations"

> needed call to resettable_change_parent() to make sure a device reset
> state stays coherent with its parent bus.
>
> The addition is a no-op if:
> 1. the device being parented is not realized.
> 2. the device is realized, but both buses are not under reset.
>
> Case 2 means that as long as qdev_set_parent_bus() is called
> during the machine realization procedure (which is before the
> machine reset so nothing is in reset), it is a no op.
>
> There are 49 call sites of qdev_set_parent_bus(). All but one fall
> into the no-op case:
> + 28 calls related to virtio (in hw/{s390x,display,virtio}/
>   {vhost,virtio}-xxx.c) to set a _vdev_/_vgpu_ composing device
>   parent bus just before realizing the _vdev_/_vgpu_.
> + hw/qdev.c: when creating a device in qdev_try_create()
> + hw/sysbus.c: when initializing a device in the sysbus
> + hw/display/virtio-gpu-pci.c: before realizing VirtIOGPUPCIBase/vgpu
> + hw/display/virtio-vga.c: before realizing VirtIOVGABase/vgpu
> + hw/i386/amd_iommu.c: before realizing AMDVIState/pci
> + hw/misc/auxbus.c: when creating an AUXBus
> + hw/misc/auxbus.c: when creating an AUXBus child
> + hw/misc/macio/macio.c: when initializing a MACIOState child
> + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/pmu
> + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/cuda
> + hw/pci-host/designware.c: before realizing DesignwarePCIEHost/root
> + hw/pci-host/gpex.c: before realizing GPEXHost/root
> + hw/pci-host/prep.c: when initializaing PREPPCIState/pci_dev
> + hw/pci-host/q35.c: before realizing Q35PCIHost/mch
> + hw/pci-host/versatile.c: when initializing PCIVPBState/pci_dev
> + hw/pci-host/xilinx-pcie.c: before realizing XilinxPCIEHost/root
> + hw/s390x/event-facility.c: when creating SCLPEventFacility/
>                              TYPE_SCLP_QUIESCE
> + hw/s390x/event-facility.c: ditto with SCLPEventFacility/
>                              TYPE_SCLP_CPU_HOTPLUG
> + hw/s390x/sclp.c: Not trivial because it is called on a SLCPDevice
>   just after realizing it. Ok because at this point the destination
>   bus (sysbus) is not in reset; the realize step is before the
>   machine reset.
> + hw/sd/core.c: Not OK. Used in sdbus_reparent_card(). See below.
> + hw/ssi/ssi.c: Used to put spi slave on spi bus and connect the cs
>   line in ssi_auto_connect_slave(). Ok because this function is only
>   used in realize step in hw/ssi/aspeed_smc.ci, hw/ssi/imx_spi.c,
>   hw/ssi/mss-spi.c, hw/ssi/xilinx_spi.c and hw/ssi/xilinx_spips.c.
> + hw/xen/xen-legacy-backend.c: when creating a XenLegacyDevice device
> + qdev-monitor.c: in device hotplug creation procedure before realize

This is a really useful analysis to have in the commit message;
thanks!

(Side note: I wonder if the sclp.c case could be reordered so
it realizes the device after parenting it? Anyway, not something
to worry about now.)

> Note that this commit alone will have no effect, right now there is no
> use of resettable API to reset anything. So a bus will never be tagged
> as in-reset by this same API.
>
> The one place where side-effect will occurs is in hw/sd/core.c in
> sdbus_reparent_card(). This function is only used in the raspi machines,
> including during the sysbus reset procedure. This case will be fixed by
> a following commit before globally enabling resettable API for sysbus
> reset.
>
> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM


  reply	other threads:[~2019-11-29 18:45 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 [this message]
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
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='CAFEAcA981i_W=8y+7_8JV=oMLT51TBMB8bTJJaiJJZqj6MuSAQ@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=berrange@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=damien.hedde@greensocs.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).