Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?

["Laszlo Ersek" <lersek@redhat.com>]

On 01/07/21 05:09, Benjamin You wrote:
> Hi,
> 
> The PCI_ROOT_BRIDGE data structure defined in MdeModulePkg\Include\Library\
> PciHostBridgeLib.h does not support reporting non-continuous resources managed
> by a root bridge. This is probably proper since it reflects the range of 
> addresses the root bridge forwards downstream.
> 
> Could the PCI Host Bridge driver be configured to relax the checking against
> conflicting resources and exclude those overlapping ranges from the root
> bridge resources reported to GCD? If this relaxation is turned on, other BIOS
> components should ensure address map consistency.

I don't think this will work well. Each (contiguous) aperture type,
captured in the PCI_ROOT_BRIDGE structure, is not only used for
sanitizing the GCD IO space map or memory space map (as appropriate).

Namely, at least the MMIO apertures are also used in
RootBridgeIoCheckParameter(), for verifying the

  EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Mem.{Read,Write}

member function calls that arrive from (minimally) the PciBusDxe driver.

If the MMCONFIG area overlaps such an aperture of the PCI_ROOT_BRIDGE
structure, then RootBridgeIoCheckParameter() will not catch
EFI_PCI_IO_PROTOCOL.Mem{Read,Write} calls that ultimately translate to
that PCI_ROOT_BRIDGE structure *but* mistakenly land in MMCONFIG.

I tend to agree with Guo's idea -- more or less, make coreboot export a
list of

  [bus range] -> [contiguous mmio range]

entries. Then "UefiPayloadPkg/Library/PciHostBridgeLib" can turn each
such entry into a PCI_ROOT_BRIDGE structure. It's not a problem if a
single physical root bridge is described by multiple PCI_ROOT_BRIDGE
objects, as long as for any two PCI_ROOT_BRIDGE objects, their Bus
apertures are distinct. (Other aperture types need not be distinct
between PCI_ROOT_BRIDGE objects.)

Now, if coreboot assigns resources such that even a *single bus number*
may have resources straddling the MMCONFIG area, then that's a
fundamental incompatibility between coreboot and edk2. I hope this is
not the case; Matt's log contains "Bus: 0 - 3", so I hope that, given
any single bus (= one-element bus range), the set of related MMIO
resources does not bracket the MMCONFIG area.

Thanks
Laszlo