linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Shelton, Ben" <benjamin.h.shelton@intel.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: Convention for PCI device to handle bridge window change
Date: Wed, 7 Oct 2015 14:20:52 -0500	[thread overview]
Message-ID: <20151007192052.GD27633@localhost> (raw)
In-Reply-To: <20150820165959.GB14073@bhshelto-vm>

Hi Ben,

Sorry for the late response.  I didn't notice this until now.

On Thu, Aug 20, 2015 at 12:00:00PM -0500, Shelton, Ben wrote:
> Hi all,
> 
> I'm working on an issue with an x64-based emulation system that has
> multiple PCI-accessible FPGAs, each of which sits behind a PCI bridge.
> 
> We program the first FPGA and then warm-reboot the CPU.  When it comes
> back up, there is an additional PCIe device that has been programmed
> into the FPGA, and the kernel goes through the remapping process to
> figure out how to fit everything.  The remapping succeeds by moving
> several of the FPGA bridges out of the way.  The bridges get set up
> properly, but the FPGA resources themselves get released but not
> reassigned, and the BAR of the FPGA behind each bridge that got
> relocated is still set to the old address.  If I add a hack in the boot
> process to call pci_assign_resource() for those particular devices if
> they have not been assigned, then everything works as expected.

When you say "warm-reboot the CPU," I assume you mean that you're
rebooting Linux from scratch, and it has no knowledge about the
previous boot.  But apparently BIOS isn't involved?  At least on x86,
BIOS usually assigns space for most or all PCI devices, but in your
case it sounds like Linux is doing the assignment.

> Where is the usual place to handle updating the BAR for a device after
> the bridge window of the bridge it's behind has changed?

If the Linux PCI core is changing a bridge window, it should also
change the BARs of any devices below the bridge.  Maybe a complete
dmesg log would help me understand what's happening.

Bjorn

      reply	other threads:[~2015-10-07 19:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-20 17:00 Convention for PCI device to handle bridge window change Shelton, Ben
2015-10-07 19: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=20151007192052.GD27633@localhost \
    --to=helgaas@kernel.org \
    --cc=benjamin.h.shelton@intel.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 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).