From: Collin Walling <walling@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>, qemu-devel@nongnu.org
Cc: Thomas Huth <thuth@redhat.com>,
Pierre Morel <pmorel@linux.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v2 2/6] s390x/pci: Fix hotplugging of PCI bridges
Date: Mon, 4 Feb 2019 17:48:49 -0500 [thread overview]
Message-ID: <83c38b9c-4b61-0067-2053-cdfe34b128bf@linux.ibm.com> (raw)
In-Reply-To: <20190130155733.32742-3-david@redhat.com>
On 1/30/19 10:57 AM, David Hildenbrand wrote:
> When hotplugging a PCI bridge right now to the root port, we resolve
> pci_get_bus(pdev)->parent_dev, which results in a SEGFAULT. Hotplugging
> really only works right now when hotplugging to another bridge.
>
> Instead, we have to properly check if we are already at the root.
>
> Let's cleanup the code while at it a bit and factor out updating the
> subordiante bus number into a separate function. The check for
s/subordiante/subordinate
> "old_nr < nr" is right now not strictly necessary, but makes it more
> obvious what is actually going on.
>
> Most probably fixing up the topology is not our responsibility when
> hotplugging. The guest has to sort this out. But let's keep it for now
> and only fix current code to not crash.
>
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> hw/s390x/s390-pci-bus.c | 28 +++++++++++++++++++---------
> 1 file changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> index b7c4613fde..9b5c5fff60 100644
> --- a/hw/s390x/s390-pci-bus.c
> +++ b/hw/s390x/s390-pci-bus.c
> @@ -843,6 +843,21 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> }
> }
>
> +static void s390_pci_update_subordinate(PCIDevice *dev, uint32_t nr)
> +{
> + uint32_t old_nr;
> +
> + pci_default_write_config(dev, PCI_SUBORDINATE_BUS, nr, 1);
> + while (!pci_bus_is_root(pci_get_bus(dev))) {
> + dev = pci_get_bus(dev)->parent_dev;
> +
> + old_nr = pci_default_read_config(dev, PCI_SUBORDINATE_BUS, 1);
> + if (old_nr < nr) {
> + pci_default_write_config(dev, PCI_SUBORDINATE_BUS, nr, 1);
> + }
> + }
> +} > +
> static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> Error **errp)
> {
> @@ -851,26 +866,21 @@ static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> S390PCIBusDevice *pbdev = NULL;
>
> if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_BRIDGE)) {
> - BusState *bus;
> PCIBridge *pb = PCI_BRIDGE(dev);
> - PCIDevice *pdev = PCI_DEVICE(dev);
>
> + pdev = PCI_DEVICE(dev);
> pci_bridge_map_irq(pb, dev->id, s390_pci_map_irq);
> pci_setup_iommu(&pb->sec_bus, s390_pci_dma_iommu, s);
>
> - bus = BUS(&pb->sec_bus);
> - qbus_set_hotplug_handler(bus, DEVICE(s), errp);
> + qbus_set_hotplug_handler(BUS(&pb->sec_bus), DEVICE(s), errp);
>
> if (dev->hotplugged) {
> pci_default_write_config(pdev, PCI_PRIMARY_BUS,
> pci_dev_bus_num(pdev), 1);
> s->bus_no += 1;
> pci_default_write_config(pdev, PCI_SECONDARY_BUS, s->bus_no, 1);
> - do {
> - pdev = pci_get_bus(pdev)->parent_dev;
> - pci_default_write_config(pdev, PCI_SUBORDINATE_BUS,
> - s->bus_no, 1);
> - } while (pci_get_bus(pdev) && pci_dev_bus_num(pdev));
> +
> + s390_pci_update_subordinate(pdev, s->bus_no);
> }
> } else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
> pdev = PCI_DEVICE(dev);
>
Looks good to me...
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Side note: unrelated to the changes here -- and if you can clarify for
me -- any idea why we do s->bus_no += 1? This throws me off a bit and
begs me to ask what exactly is the S390pciState object suppose to
represent? (My guess is that it is representative of the entire PCI
topology, and we increment the bus_no to denote the subordinate bus
number?)
(let me know if these kind of discussions are too noisy and deemed
inappropriate for the mailing list, and I'll start pestering you off-
list instead)
next prev parent reply other threads:[~2019-02-04 22:55 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 15:57 [Qemu-devel] [PATCH v2 0/6] s390x/pci: remaining hot/un)plug patches David Hildenbrand
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 1/6] s390x/pci: Fix primary bus number for PCI bridges David Hildenbrand
2019-02-04 22:58 ` Collin Walling
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 2/6] s390x/pci: Fix hotplugging of " David Hildenbrand
2019-02-04 22:48 ` Collin Walling [this message]
2019-02-04 23:43 ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2019-02-05 9:24 ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 3/6] s390x/pci: Warn when adding PCI devices without the 'zpci' feature David Hildenbrand
2019-02-04 20:19 ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-02-04 21:54 ` David Hildenbrand
2019-02-04 22:42 ` Collin Walling
2019-02-04 22:45 ` David Hildenbrand
2019-02-05 9:32 ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 4/6] s390x/pci: Introduce unplug requests and split unplug handler David Hildenbrand
2019-01-31 20:40 ` Collin Walling
2019-01-31 21:11 ` David Hildenbrand
2019-02-01 10:38 ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 5/6] s390x/pci: Drop release timer and replace it with a flag David Hildenbrand
2019-01-31 20:33 ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-01-31 21:12 ` David Hildenbrand
2019-01-31 21:21 ` [Qemu-devel] " David Hildenbrand
2019-02-01 10:08 ` Cornelia Huck
2019-02-01 10:37 ` David Hildenbrand
2019-02-01 10:42 ` Cornelia Huck
2019-02-01 10:39 ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 6/6] s390x/pci: Unplug remaining requested devices on pcihost reset David Hildenbrand
2019-01-31 20:26 ` Collin Walling
2019-01-31 21:13 ` David Hildenbrand
2019-02-01 10:19 ` Cornelia Huck
2019-02-01 15:06 ` David Hildenbrand
2019-02-05 9:35 ` Cornelia Huck
2019-01-30 16:27 ` [Qemu-devel] [PATCH v2 0/6] s390x/pci: remaining hot/un)plug patches Cornelia Huck
2019-01-31 20:43 ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-01-31 21:21 ` David Hildenbrand
2019-02-01 8:35 ` Cornelia Huck
2019-02-01 9:18 ` David Hildenbrand
2019-02-01 15:44 ` Collin Walling
2019-02-05 9:55 ` [Qemu-devel] " Cornelia Huck
2019-02-05 9:55 ` David Hildenbrand
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=83c38b9c-4b61-0067-2053-cdfe34b128bf@linux.ibm.com \
--to=walling@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@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 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).