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