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)
Mon, Jul 8, 7:24 AM
Unknown Object (File)
Sat, Jul 6, 10:38 AM
Unknown Object (File)
Tue, Jul 2, 7:16 AM
Unknown Object (File)
Thu, Jun 27, 3:26 PM
Unknown Object (File)
Jun 6 2024, 10:12 PM
Unknown Object (File)
Jun 2 2024, 5:24 PM
Subscribers
None

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...