Tianocore/edk2.git/MdeModulePkg/Bus/Pci, branch dependabot/github_actions/github/codeql-action-4.39.1

MdeModulePkg: Use DUMP_HEX Macro

2026-10-23T03:44:49+00:00

Several places in MdeModulePkg were implementing their own versions of hex dumping logic; use the DebugLib.h macro instead. Prints change slightly, they are now standardized with uppercase hex, prefixes on every row instead of in the header only, and VarCheckHiiLib no longer indents rows with *ASCII*. Signed-off-by: Oliver Smith-Denny

MdeModulePkg:NvmExpressDxe fix memory leak

2026-10-19T17:25:48+00:00

Memory leak anytime the FormatNvm function is called. Signed-off-by: Sean Brogan

MdeModulePkg:NvmExpressDxe/UnitTest set LastBlock correctly

2026-10-19T17:25:48+00:00

LastBlock field is inclusive. To lower confusion it should be initialized to the intended value which was to create metadata for an 8mb disk. Signed-off-by: Sean Brogan

MdeModulePkg:NvmExpressDxe/UnitTest remove useless code

2026-10-19T17:25:48+00:00

NamespaceData was allocated, zeroed, and never modifed. Then it was copied over another buffer that was already zero. Then it was leaked. Remove local variable NamespaceData and the associated code. Signed-off-by: Sean Brogan

MdeModulePkg:NvmExpressDxe/UnitTest Add additional host based unit tests

2026-10-19T17:25:48+00:00

Add tests for MediaClear functions in the Nvme Media Sanitize Unit tests Signed-off-by: Sean Brogan

MdeModulePkg/PciBusDxe: Consume PCI bridge register macros

2026-10-19T06:48:00+00:00

Replace hardcoded PCI configuration-space offsets with the type-safe macros from MdePkg/Include/IndustryStandard/Pci22.h. This removes magic numbers from the PciBus driver and makes the code easier to read and maintain. No functional change. 1. MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c - GatherDeviceInfo() / InitializePciDevice(): use PCI_BASE_ADDRESSREG_OFFSET and PCI_BASE_ADDRESSREG5_OFFSET as the BAR scan loop bounds instead of 0x10/0x24. - GatherPpbInfo(): use PCI_BASE_ADDRESSREG_OFFSET / PCI_BASE_ADDRESSREG1_OFFSET for the two PPB BARs, and the PCI_BRIDGE_* offset macros instead of 0x1C/0x24/0x28. - GatherP2CInfo(): use PCI_BASE_ADDRESSREG_OFFSET instead of 0x10 for the CardBus bridge BAR. - InitializePpb(): use the PCI_BRIDGE_* offset macros instead of hardcoded offsets (0x1C/0x1D/0x20/0x22/0x24/0x26/0x28/0x2C/0x30/0x32) when initializing the I/O, 32-bit memory, and 64-bit memory windows to their disabled state (base set to all-ones, limit to all-zeros). - IsPciDeviceRejected(): use PCI_CARD_MEMORY_BASE_0, PCI_CARD_IO_BASE_0_LOWER, and PCI_CARD_IO_LIMIT_1_LOWER in place of 0x1C/0x2C/0x38 for the CardBus BAR scan, and PCI_BASE_ADDRESSREG1_OFFSET / PCI_BASE_ADDRESSREG5_OFFSET instead of 0x14/0x24 for the standard PCI BAR scan. - ResetAllPpbBusNumber(): use PCI_BRIDGE_PRIMARY_BUS_REGISTER_OFFSET instead of 0x18. 2. MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c - Use PCI_BASE_ADDRESSREG_OFFSET / PCI_BASE_ADDRESSREG5_OFFSET as the BAR scan loop bounds instead of 0x10/0x24. 3. MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c - ProgramPpbAperture(): replace hardcoded PCI bridge aperture offsets with the PCI_BRIDGE_* macros in the PPB_IO_RANGE, PPB_MEM32_RANGE, PPB_PMEM32_RANGE, and PPB_PMEM64_RANGE cases. 4. MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c - Use PCI_BRIDGE_PRIMARY_BUS_REGISTER_OFFSET, PCI_BRIDGE_SECONDARY_BUS_REGISTER_OFFSET, and PCI_BRIDGE_SUBORDINATE_BUS_REGISTER_OFFSET instead of 0x18/0x19/0x1A when programming and reading the bridge bus-number registers. 5. MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c - Use PCI_INT_LINE_OFFSET instead of 0x3C when writing the device Interrupt Line register to 0xFF (no connection / unknown). References: - PCI Local Bus Specification, Revision 2.2 - PCI-to-PCI Bridge Architecture Specification, Revision 1.2 - PCI Express Base Specification, Revision 7.0 Cc: Sachin Ganesh Cc: Dhanaraj V Cc: Sergiy Yakovlev Cc: Dhiinesh M Signed-off-by: Varun G

MdeModulePkg/PciBusDxe: Add Google Tests for BAR parsing

2026-10-14T18:22:11+00:00

Add host-based Google Test coverage for PciParseBar() and PciIovParseVfBar(). Cover absent BARs, 16-bit and 32-bit I/O BARs, 32-bit memory BARs, and 64-bit memory BARs. Also verify that a resource following a 64-bit BAR retains its physical BAR number because the upper DWORD consumes the intermediate BAR register. Add equivalent SR-IOV VF BAR coverage, including InitialVFs length scaling, system page alignment, 64-bit VF BAR parsing, and physical VF BAR numbering after a 64-bit VF BAR. Provide test-only PCI configuration access and boot service mocks. Stub unrelated PciBusDxe dependencies pulled in by PciEnumeratorSupport.c, and register the test application in MdeModulePkgHostTest.dsc. Signed-off-by: Aaron Pop

MdeModulePkg/PciBusDxe: Preserve physical BAR numbering

2026-10-14T18:22:11+00:00

PCI BARs are by six consecutive 32-bit configurationv registers. 64-bit BARs consume two of those registers: the first contains the low address bits and the second contains the high address bits. These are represented in the private PCI_IO_DEVICE as PciBar[PCI_MAX_BAR] and VfPciBar[PCI_MAX_BAR]. PciBusDxe previously maintained a separate BarIndex while walking the configuration registers. PciParseBar() and PciIovParseVfBar() advance the configuration offset by two registers when parsing a 64-bit BAR, but their callers incremented BarIndex only once. As a result, every BAR following a 64-bit BAR was stored in the preceding array entry. For example, a BAR at offset 0x18 following a 64-bit BAR at offset 0x10 was recorded as PciBar[1] instead of PciBar[2]. This breaks the invariant that PciBar[Index] and VfPciBar[Index] describe the corresponding physical BAR register. It can cause later resource handling and diagnostics to associate a BAR with the wrong hardware slot. VF BAR programming retained the configuration offset in each entry, which could mask the problem, but its array and resource node indices were still incorrect. Derive the BAR index directly from the configuration offset in both parsers. Remove the redundant BarIndex parameters and let each caller advance using the offset returned by the parser. This preserves holes for the upper DWORDs of 64-bit BARs and keeps conventional and SR-IOV VF BAR numbering aligned with the hardware configuration space. Signed-off-by: Aaron Pop

MdeModulePkg/PciBusDxe: Keep discovery order of equally aligned BARs

2026-10-12T09:31:30+00:00

InsertResourceNode() keeps the resource list of a bridge sorted by descending alignment. The new node is inserted at the head of the list and then moved towards the tail, but it stops in front of the first node that it does not need to follow. Resources that rank equal, such as BARs of the same size, therefore end up in the reverse order of their discovery (LIFO), and the last discovered one is assigned the lowest address. Linux also sorts the resources by descending alignment in pdev_sort_resources() (drivers/pci/setup-bus.c), but it inserts a new resource after all the resources with the same alignment, so these keep their discovery order (FIFO). When the OS reassigns the PCI resources instead of keeping the firmware assignment (for example Linux on ARM64 ACPI systems, unless the firmware requests to preserve the PCI boot configuration through _DSM function 5), this difference makes it swap the addresses of equally sized BARs. While doing so, a BAR is temporarily programmed with a range that is still decoded by another device, which is not handled by some platforms, such as VMMs that do not allow overlapping BARs. Insert the new node at the tail of the list and move it towards the head instead, swapping the roles of the two compared nodes, so that resources that rank equal keep their discovery order, consistent with Linux. Resources with the same alignment are also sorted by the remainder of their length modulo the alignment. In practice, the remainder is only non-zero for the window of a child bridge, whose length is a multiple of the window granularity but whose alignment is the largest alignment of the resources behind it. Such a window leaves a gap in front of the next resource with the same alignment, so resources without a remainder should come first. However, the check only ranks a zero remainder first for the node that is being inserted, not for the existing node that it is compared with, so the relative order of windows with and without a remainder also depends on the insertion order. Reversing it can waste address space. For example, on QEMU q35 with three PCIe root ports, where the first one has a 3 MB MMIO window aligned to 2 MB and the other two have a 2 MB window, the 3 MB window would be placed first, leaving a 1 MB gap and growing the MMIO32 aperture of the root bridge from 8 MB to 9 MB. Therefore, rank a zero remainder first for both compared nodes. Resources without a remainder now always come first, regardless of the discovery order, which never increases the size of the aperture, and only resources that rank equal are ordered by their discovery. Update the description of InsertResourceNode() to document the full ordering. Signed-off-by: Shubham Aggarwal

MdeModulePkg/NvmExpressDxe: Use BaseLib for 64-bit multiplication

2026-09-29T02:10:55+00:00

Commit bf0dc7d78701 ("MdeModulePkg: Fix comparison with wider widths") changed PrpListIndex and PrpEntryIndex from UINTN to UINT64. In NvmeCreatePrpList(), performing arithmetic with `PrpListIndex * EFI_PAGE_SIZE` and pointer indexing with `(UINT64 *)PrpListBase + PrpEntryIndex` results in 64-bit multiplication. Fix this issue by using MultU64x32() for 64-bit page offset calculations and casting PrpEntryIndex to UINTN for pointer indexing. Signed-off-by: Michael D Kinney