From: Jason Baron <jbaron@redhat.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org, mst@redhat.com
Subject: Re: [PATCH] pci hotplug: rescan bridge after device hotplug
Date: Wed, 23 May 2012 11:53:47 -0400 [thread overview]
Message-ID: <20120523155346.GA23940@redhat.com> (raw)
In-Reply-To: <CAE9FiQVPyjsB=oWp80sgqzkWw8KqX0GHg+csM39juo2N67P2Tg@mail.gmail.com>
On Tue, May 22, 2012 at 09:07:54PM -0700, Yinghai Lu wrote:
> On Tue, May 22, 2012 at 8:31 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> > On Tue, May 22, 2012 at 7:43 PM, Jason Baron <jbaron@redhat.com> wrote:
> >> On Tue, May 22, 2012 at 02:21:13PM -0700, Yinghai Lu wrote:
> >>> On Tue, May 22, 2012 at 1:11 PM, Jason Baron <jbaron@redhat.com> wrote:
> >>> > I'm tyring to support bridge hotplug and devices below it in qemu via acpi
> >>> > hotplug. Currently only 1 level or 32 slots are supported. By allowing for a
> >>> > second level, we will be able to support 32^2 devices.
> >>> >
> >>> > If I first hotplug the bridge with no devices intially below it, the hotplug
> >>> > code sets the bridge memory window to 0 and does not increase it when
> >>> > subsequent devices are added below it.
> >>> >
> >>> > Fix this, by calling pci_rescan_bus_bridge_resize(), on the bridge directly
> >>> > below the root to re-size all the birdge windows that may have changed.
> >>> >
> >>> > Signed-off-by: Jason Baron <jbaron@redhat.com>
> >>> > ---
> >>> > drivers/pci/hotplug/acpiphp_glue.c | 8 ++++++++
> >>> > 1 files changed, 8 insertions(+), 0 deletions(-)
> >>> >
> >>> > diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
> >>> > index 806c44f..8960c1e 100644
> >>> > --- a/drivers/pci/hotplug/acpiphp_glue.c
> >>> > +++ b/drivers/pci/hotplug/acpiphp_glue.c
> >>> > @@ -792,6 +792,7 @@ static int __ref enable_device(struct acpiphp_slot *slot)
> >>> > {
> >>> > struct pci_dev *dev;
> >>> > struct pci_bus *bus = slot->bridge->pci_bus;
> >>> > + struct pci_bus *rescan_bus;
> >>> > struct acpiphp_func *func;
> >>> > int retval = 0;
> >>> > int num, max, pass;
> >>> > @@ -821,6 +822,13 @@ static int __ref enable_device(struct acpiphp_slot *slot)
> >>> > }
> >>> > }
> >>> >
> >>> > + /* Ensure we rescan/setup a bridge for new devs hanging off of it */
> >>> > + rescan_bus = bus;
> >>> > + while (rescan_bus->parent && rescan_bus->parent->self)
> >>> > + rescan_bus = rescan_bus->parent;
> >>> > + if (rescan_bus->self)
> >>> > + pci_rescan_bus_bridge_resize(rescan_bus->self);
> >>> > +
> >>>
> >>> No, you can not do that. some parents bus could have other devices
> >>> and driver could be loaded for those devices.
> >>> so can not release resources that are used by those devices to resize
> >>> parent bridges.
> >>>
> >>
> >> hmmm...this patch also does what I want:
> >>
> >>
> >> diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
> >> index 806c44f..be63c72 100644
> >> --- a/drivers/pci/hotplug/acpiphp_glue.c
> >> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> >> @@ -821,6 +821,10 @@ static int __ref enable_device(struct acpiphp_slot *slot)
> >> }
> >> }
> >>
> >> + /* Ensure we rescan/setup a bridge for new devs hanging off of it */
> >> + if (bus->self)
> >> + pci_assign_unassigned_bridge_resources(bus->self);
> >> +
> >> list_for_each_entry(func, &slot->funcs, sibling)
> >> acpiphp_bus_add(func);
> >>
> >>
> >> There appears to be a precedant for something very similar in:
> >> drivers/pci/hotplug/pciehp_pci.c:pciehp_configure_device(), where there
> >> is a call to 'pci_assign_unassigned_bridge_resources(), when a new
> >> device is added...
> >
> > the bus could have other devices under that bridge already.
> >
> > so pci_assign_unassigned_bridge_resources() will still try to release
> > the bridge resource and
> > those devices resources.
> >
> > but pciehp we could do that, because it will only have one device
> > under that pcie root port or downstream port.
> >
> > so you can make qemu to support pcie and pciehp.
> >
> > for hot add one hotplug bridge support, we have
> > bus->self->is_hotplug_bridge to set, so it will have allocate
> > minimum resource.
> >
> > so you also could try to use quirk etc to get that bit set.
> > please check
> > drivers/pci/quirks.c::
> > /* Allow manual resource allocation for PCI hotplug bridges
> > * via pci=hpmemsize=nnM and pci=hpiosize=nnM parameters. For
> > * some PCI-PCI hotplug bridges, like PLX 6254 (former HINT HB6),
> > * kernel fails to allocate resources when hotplug device is
> > * inserted and PCI bus is rescanned.
> > */
> > static void __devinit quirk_hotplug_bridge(struct pci_dev *dev)
> > {
> > dev->is_hotplug_bridge = 1;
> > }
> >
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HINT, 0x0020, quirk_hotplug_bridge);
> >
> > but still would prefer you to make qemu to support pciehp.
>
> another solution could be:
>
> in qemu acpi dsdt, you could set bridge size for new added bridge.
>
> current pbus_size_mem() will not shrink the old bridge resource size.
>
> Thanks
>
> Yinghai Lu
ok, I also tried hard-wiring the bridge io/mem base and limit registers on the
qemu side. That seems to work without any guest-side hotplug code changes. And
would seem to be more flexible than putting the limits in acpi.
Thanks,
-Jason
next prev parent reply other threads:[~2012-05-23 16:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 20:11 [PATCH] pci hotplug: rescan bridge after device hotplug Jason Baron
2012-05-22 20:34 ` Yinghai Lu
2012-05-22 21:18 ` Yinghai Lu
2012-05-22 21:21 ` Yinghai Lu
2012-05-23 2:43 ` Jason Baron
2012-05-23 3:31 ` Yinghai Lu
2012-05-23 4:07 ` Yinghai Lu
2012-05-23 15:53 ` Jason Baron [this message]
2012-05-23 17:16 ` Yinghai Lu
2012-05-23 18:44 ` Jason Baron
2012-05-23 19:08 ` Michael S. Tsirkin
2012-05-23 19:20 ` Michael S. Tsirkin
2012-05-23 20:53 ` Yinghai Lu
2012-05-23 21:18 ` Michael S. Tsirkin
2012-05-23 20:31 ` Yinghai Lu
2012-05-23 20:49 ` Michael S. Tsirkin
2012-05-23 19:13 ` Michael S. Tsirkin
2012-05-23 20:52 ` Jason Baron
2012-05-24 0:00 ` Yinghai Lu
2012-05-24 13:43 ` Jason Baron
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=20120523155346.GA23940@redhat.com \
--to=jbaron@redhat.com \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=mst@redhat.com \
--cc=yinghai@kernel.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.