From: Bjorn Helgaas <helgaas@kernel.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org, geoff@hostfission.com
Subject: Re: [PATCH] PCI: Release unused bridge resources during resize
Date: Mon, 10 Jun 2024 10:20:34 -0500 [thread overview]
Message-ID: <20240610152034.GA943788@bhelgaas> (raw)
In-Reply-To: <20240607170156.3e59f580.alex.williamson@redhat.com>
On Fri, Jun 07, 2024 at 05:01:56PM -0600, Alex Williamson wrote:
> On Fri, 7 Jun 2024 17:33:20 -0500
> Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> > On Tue, May 07, 2024 at 03:31:23PM -0600, Alex Williamson wrote:
> > > Resizing BARs can be blocked when a device in the bridge hierarchy
> > > itself consumes resources from the resized range. This scenario is
> > > common with Intel Arc DG2 GPUs where the following is a typical
> > > topology:
> > >
> > > +-[0000:5d]-+-00.0-[5e-61]----00.0-[5f-61]--+-01.0-[60]----00.0 Intel Corporation DG2 [Arc A380]
> > > \-04.0-[61]----00.0 Intel Corporation DG2 Audio Controller
> ...
> > > pci 0000:60:00.0: BAR 2 [mem 0xbfe0000000-0xbfefffffff 64bit pref]: releasing
> > > pcieport 0000:5f:01.0: bridge window [mem 0xbfe0000000-0xbfefffffff 64bit pref]: releasing
> > > pci 0000:5e:00.0: bridge window [mem 0xbfe0000000-0xbfefffffff 64bit pref]: releasing
> > > pci 0000:5e:00.0: BAR 0 [mem 0xbff0000000-0xbff07fffff 64bit pref]: releasing
> > > pcieport 0000:5d:00.0: bridge window [mem 0xbfe0000000-0xbff07fffff 64bit pref]: releasing
> > > pcieport 0000:5d:00.0: bridge window [mem 0xb000000000-0xb2ffffffff 64bit pref]: assigned
> > > pci 0000:5e:00.0: bridge window [mem 0xb000000000-0xb1ffffffff 64bit pref]: assigned
> > > pci 0000:5e:00.0: BAR 0 [mem 0xb200000000-0xb2007fffff 64bit pref]: assigned
It didn't occur to me before, but don't we have a potential issue here
because we relocated 5e:00.0 BAR 0 from 0xbff0000000 to 0xb200000000
without notifying any code that might be using it?
I'm worried about vendor-specific perf/EDAC/etc drivers that can't
claim the the bridge using pci_register_driver() because the pcieport
driver is in the way. I think some of those drivers go behind the
back of the driver model to locate their device and ioremap the BAR
direction.
Bjorn
prev parent reply other threads:[~2024-06-10 15:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 21:31 [PATCH] PCI: Release unused bridge resources during resize Alex Williamson
2024-05-13 13:46 ` Ilpo Järvinen
2024-05-16 13:49 ` Alex Williamson
2024-05-20 14:59 ` Ilpo Järvinen
2024-06-07 20:44 ` Alex Williamson
2024-06-07 22:33 ` Bjorn Helgaas
2024-06-07 23:01 ` Alex Williamson
2024-06-10 15:20 ` Bjorn Helgaas [this message]
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=20240610152034.GA943788@bhelgaas \
--to=helgaas@kernel.org \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=geoff@hostfission.com \
--cc=linux-pci@vger.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.