Page MenuHomeFreeBSD

pci_host_generic: Permit multiple bridges to share the same I/O window
Needs ReviewPublic

Authored by jhb on Jun 1 2024, 4:14 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Jan 10, 1:38 PM
Unknown Object (File)
Tue, Jan 7, 2:03 PM
Unknown Object (File)
Dec 12 2024, 6:10 PM
Unknown Object (File)
Dec 2 2024, 6:35 PM
Unknown Object (File)
Nov 27 2024, 7:16 AM
Unknown Object (File)
Nov 22 2024, 5:02 PM
Unknown Object (File)
Nov 3 2024, 4:59 AM
Unknown Object (File)
Oct 22 2024, 11:23 AM

Details

Reviewers
imp
Summary

Some systems share a single window for I/O port resources across
multiple bridges. Prior to commit d79b6b8ec267, each bridge used its
own private rman meaning that multiple downstream devices could
allocate the same or overlapping I/O port resource ranges. Since most
systems only used firmware-assigned ranges for I/O port resources,
this worked ok in practice. After commit d79b6b8ec267, only the first
bridge was able to allocate the parent memory resource for the I/O
port resource range and other bridges were not able to allocate I/O
port resources to child devices.

Add a new quirk to handle this case. The device_t of the first bridge
that succesfully allocates a memory resource for an I/O port resource
range is saved in a global variable. For each subsequent bridge,
check if the new bridges I/O port resource ranges are identical to
those in the first bridge. If so, enable the new
PCIE_SHARED_IO_WINDOW quirk. When this quirk is active, attempts to
allocate an I/O port resource allocate from the rman in the first
bridge and request sub-mappings from the parent memory resource
allocated by the first bridge.

Reported by: imp
Fixes: d79b6b8ec267 pci_host_generic: Don't rewrite resource start address for translation

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 57985
Build 54873: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Jun 1 2024, 4:14 AM
jhb created this revision.

This looks good, I'll test it when I return from BSDCan

sys/dev/pci/pci_host_generic.c
269

This will need to not use type once D44207 lands. I will just have to fixup whichever change lands second.

@imp did you get a chance to test this?

In D45434#1045067, @jhb wrote:

@imp did you get a chance to test this?

No. I'll have to do it tomorrow. The machine that did this is my second choice and I've been focused on the primary one...

@allanjude, @kevans, @markj in reference to testing on large arm64 boxes with multiple top-level pcibX devices

sys/dev/pci/pci_host_generic.c
86

This doesn't compile, as tuple is not declared anywhere.

Hmm, Warner notes that this does not resolve his reported issue, but his reported issue is also not a regression? (I had been waiting to MFC all my rman changes to stable/14 under the impression it introduced a regression)

Do we have a way to create a bootable BE from installworld/installkernel/distribution that's scripted?
The scripts in the tree assume you are UPDATING the system, but I'd like to just create a generic stable/14 to test this machine w/o this patch.

Hmm, I'm not sure. Presumably you could create the alternate be, mount it, then do make installworld installetc installkernel DESTDIR=/foo'?