pci: Reserve bus numbers required by SR-IOV VFsHEADmain

Some firmware assigns only one bus number to each PCI-PCI bridge.  This
prevents later SR-IOV VF enumeration when a VF routing ID falls on a bus
number already allocated to a sibling bridge.

Reserve only the additional bus numbers required by SR-IOV PFs.
Enumerate all directly attached functions before child drivers and
bridges attach, inspect their device_t objects for SR-IOV, and grow the
PCI bus resource through the highest possible VF routing ID.

First VF Offset and VF Stride may change when NumVFs changes.  Probe
every valid NumVFs value and preserve the original setting.  When the
upstream hierarchy uses ARI, temporarily enable the SR-IOV ARI Hierarchy
control in the lowest-numbered PF while sizing, then restore it.  Scope
active-VF detection to each conventional PCI slot; an ARI bus remains
one slot-0 hierarchy.  If firmware left VFs enabled on a device, do not
modify it and reserve only its active layout.

During runtime configuration, consult the PCI bus's owned resource
range rather than PCI-PCI bridge registers.  This recognizes an existing
boot-time reservation beneath both PCI-PCI and host bridges and avoids a
second, overlapping bus-number allocation.

This avoids consuming bus numbers behind unrelated bridges.  The runtime
allocation in pci_iov.c remains as a fallback when the boot-time range
cannot be enlarged.  hw.pci.clear_buses remains useful when firmware
assigned a required number to another bridge before enumeration.

Validated the targeted implementation on an Intel E810-XXV behind a
non-ARI root port.  With hw.pci.clear_buses=1 and no global reserve
tunable, the PF bridge received buses 1-2 while three unrelated bridges
each received one bus.  A VF with First VF Offset 0x100 attached as
iavf0 at pci0:2:0:0, and detached cleanly.

Reviewed by:	jhb, manpages (ziaee)
MFC after:	2 weeks
Sponsored by:	BBOX.io
Differential Revision:	https://reviews.freebsd.org/D58624

0 files changed, 0 insertions, 0 deletions