Branch: refs/heads/master
Home: https://github.com/tianocore/edk2
Commit: 4aa7e66c06f8b837845aff2afd7c1c0b35d9afba
https://github.com/tianocore/edk2/commit/4aa7e66c06f8b837845aff2afd7c1c0b35d9afba
Author: Foster Nong <foster.n...@intel.com>
Date: 2022-10-14 (Fri, 14 Oct 2022)
Changed paths:
M MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
Log Message:
-----------
MdeModulePkg: Fixed extra 1 SR-IOV reserved bus
Below code will calculate the reserved bus number for the each PF.
Based on the VF routing ID algorithm, PFRid and LastVF in below code
already sure that "All VFs and PFs must have distinct Routing IDs".
PF will be assigned Routing ID based on secBusNumber, ReservedBusNum
will add into SubBusNumber directly. So the SR-IOV device will be
assigned bus range as SecBusNumber ~ (SubBusNumber=(SecBusNumber +
ReservedBusNum)).
Thus "+1" in below code will cause extra 1 bus, and introduce a bus hole.
PFRid = EFI_PCI_RID (Bus, Device, Func);
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride;
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) -
Bus + 1);
In SR-IOV spec, there is a note in section 2.1.2:
Note: Bus Numbers are a constrained resource. Devices are strongly
encouraged to avoid leaving ?holes? in their Bus Number usage to avoid
wasting Bus Numbers
So the issue can be fixed with below code change.
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) -
Bus);
https://bugzilla.tianocore.org/show_bug.cgi?id=4069
Signed-off-by: Foster Nong <foster.n...@intel.com>
Reviewed-by: Ray Ni <ray...@intel.com>
Commit: 8fc06b6e19e3df93cc989b4f85877d8a7783e5bf
https://github.com/tianocore/edk2/commit/8fc06b6e19e3df93cc989b4f85877d8a7783e5bf
Author: Foster Nong <foster.n...@intel.com>
Date: 2022-10-14 (Fri, 14 Oct 2022)
Changed paths:
M MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
M MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
M MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
Log Message:
-----------
Fix bug on SRIOV ReservedBusNum when ARI enable.
If a device which support both features SR-IOV/ARI has multi
functions, which maybe support 8-255. After enable ARI forwarding in
the root port and ARI Capable Hierarchy in the SR-IOV PF0.
The device will support and expose multi functions(0-255) with ARI ID routing.
In next device loop in below for() code, actually it still be in the
same SR-IOV device, and just some PF which is over 8 or higher
one(n*8), PciAllocateBusNumber() will allocate bus
number(ReservedBusNum - TempReservedBusNum)) for this PF. if reset
TempReservedBusNum as 0 in this case,it will allocate wrong bus number
for this PF because TempReservedBusNum should be total previous PF's
reserved bus numbers.
code:
for (Device = 0; Device <= PCI_MAX_DEVICE; Device++) {
TempReservedBusNum = 0;
for (Func = 0; Func <= PCI_MAX_FUNC; Func++) {
//
// Check to see whether a pci device is present
//
Status = PciDevicePresent (
PciRootBridgeIo,
&Pci,
StartBusNumber,
Device,
Func
);
...
Status = PciAllocateBusNumber (PciDevice, *SubBusNumber,
(UINT8)(PciDevice->ReservedBusNum - TempReservedBusNum), SubBusNumber);
The solution is add a new flag IsAriEnabled to help handle this case.
if ARI is enabled, then TempReservedBusNum will not be reset again
during all functions(1-255) scan with checking flag IsAriEnabled.
Signed-off-by: Foster Nong <foster.n...@intel.com>
Reviewed-by: Ray Ni <ray...@intel.com>
Compare: https://github.com/tianocore/edk2/compare/e0200cc47a69...8fc06b6e19e3
_______________________________________________
edk2-commits mailing list
edk2-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-commits
