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

["Benjamin You" <benjamin.you@intel.com>]

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.

Thanks,

- ben

> -----Original Message-----
> From: Dong, Guo <guo.dong@intel.com>
> Sent: Thursday, January 7, 2021 7:05 AM
> To: devel@edk2.groups.io; mjg59@srcf.ucam.org
> Cc: patrick.rudolph@9elements.com; You, Benjamin <benjamin.you@intel.com>
> Subject: RE: [edk2-devel] UefiPayloadPkg and over-eager PCI resource
> allocation?
> 
> 
> This is not related with OS.
> For example, SBL add a new HOB (coreboot could put such info in coreboot
> table) for the PCI resources,
> So in the UEFI payload, it could retrieve and use these info, instead of running
> ScanForRootBridges() in
> uefipayloadpkg\library\pcihostbridgelib\PciHostBridgeSupport.c since the UEFI
> payload assumption.
> 
> Thanks,
> Guo
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Matthew
> > Garrett
> > Sent: Wednesday, January 6, 2021 3:34 PM
> > To: Dong, Guo <guo.dong@intel.com>
> > Cc: devel@edk2.groups.io; patrick.rudolph@9elements.com; You, Benjamin
> > <benjamin.you@intel.com>
> > Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource
> > allocation?
> >
> > How should these ranges be reported? They need to be treated as reserved
> > by the OS, not exposed as PCI resources.
> >
> > On Wed, Jan 06, 2021 at 10:20:30PM +0000, Dong, Guo wrote:
> > >
> > > Yes. If a device is hidden, the Payload could not scan and find the resource
> for
> > it.
> > > I would prefer bootloader report these PCI resource range to payload.
> > >
> > > Thanks,
> > > Guo
> > >
> > > > -----Original Message-----
> > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Patrick
> > > > Rudolph
> > > > Sent: Wednesday, January 6, 2021 6:57 AM
> > > > To: devel@edk2.groups.io; You, Benjamin <benjamin.you@intel.com>
> > > > Cc: Dong, Guo <guo.dong@intel.com>; mjg59@srcf.ucam.org
> > > > Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource
> > > > allocation?
> > > >
> > > > Hi,
> > > > In addition to MMCONF there might be hidden PCI devices having active
> > > > BARs, like UART in ACPI mode or the PMC/P2SB device.
> > > > Those memory regions are marked as reserved in e820 tables and collide
> > > > with the assumption of a contiguous memory space.
> > > > It is contiguous, but that is not visible by the PCI Host bridge driver.
> > > >
> > > > Kind Regards,
> > > > Patrick Rudolph
> > > >
> > > > Patrick Rudolph
> > > > B.Sc. Electrical Engineering
> > > > System Firmware Developer
> > > >
> > > >
> > > > 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
> > > > Email: patrick.rudolph@9elements.com
> > > > Phone:  +49 234 68 94 188
> > > >
> > > > Sitz der Gesellschaft: Bochum
> > > > Handelsregister: Amtsgericht Bochum, HRB 17519
> > > > Geschäftsführung: Sebastian Deutsch, Eray Basar
> > > >
> > > > Datenschutzhinweise nach Art. 13 DSGVO
> > > >
> > > >
> > > > Am Mo., 4. Jan. 2021 um 07:34 Uhr schrieb Benjamin You
> > > > <benjamin.you@intel.com>:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Current PCI Host Bridge driver treats resources reported from root
> > bridges
> > > > > as continuous and performs rigorous checking against overlaps with
> > existing
> > > > > resources such as MMCONF.
> > > > >
> > > > > I think to support the case where a root bridge reports a non-continuous
> > > > range
> > > > > that encompasses the MMCONF, a policy could be defined for the PCI
> > Host
> > > > Bridge
> > > > > driver to optionally carve out the MMCONF from the root bridge MMIO
> > > > resources
> > > > > reported to GCD. (MMCONF is defined by PcdPciExpressBaseAddress and
> > > > > PcdPciExpressBaseSize). A PCD could be defined to enable such behavior
> > > > (with
> > > > > default as FALSE to maintain backward compatibility).
> > > > >
> > > > > Thanks,
> > > > >
> > > > > - ben
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> Guo
> > > > Dong
> > > > > > Sent: Monday, January 4, 2021 11:17 AM
> > > > > > To: devel@edk2.groups.io; mjg59@srcf.ucam.org
> > > > > > Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource
> > > > > > allocation?
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > The pcihostbridgelib  in the uefipayloadpkg would scan the PCI bridge
> to
> > > > collect
> > > > > > the assigned PCI resource information.
> > > > > > During scanning, there is an assumption that the PCI memory resource
> > is
> > > > > > allocated continuously without gaps.
> > > > > >
> > > > > > In your case, it looks the lowest resource address is 9F800000, and the
> > high
> > > > > > resource address is FE0FFFFF.
> > > > > > There is a gap (0xE0000000 ~ 0xF0000000) between them used for PCIe
> > > > base
> > > > > > address.
> > > > > >
> > > > > > You could check which PCI device is assigned with FE0FFFFF in coreboot,
> > and
> > > > > > change it before 0xE0000000.
> > > > > >
> > > > > > I am thinking we could update pcihostbridgelib to get the PCI resource
> > > > > > information from bootloader (coreboot and SBL)
> > > > > > instead of scanning the PCI bridge to get the range. Let me know if
> > having
> > > > > > comments.
> > > > > >
> > > > > > Thanks,
> > > > > > Guo
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > > > Matthew
> > > > > > > Garrett
> > > > > > > Sent: Sunday, December 27, 2020 1:41 PM
> > > > > > > To: devel@edk2.groups.io
> > > > > > > Subject: [edk2-devel] UefiPayloadPkg and over-eager PCI resource
> > > > allocation?
> > > > > > >
> > > > > > > I'm trying to run UefiPayloadPkg on a Coreboot-based system. Based
> > on
> > > > > > > debug logs, my GCD looks like this:
> > > > > > >
> > > > > > > GCDMemType Range                             Capabilities     Attributes
> > > > > > > ========== =================================
> > ================
> > > > > > > ================
> > > > > > > Reserved   0000000000000000-0000000000000FFF
> > 870000000000000F
> > > > > > > 0000000000000000
> > > > > > > SystemMem  0000000000001000-000000000009FFFF
> > 800000000000000F
> > > > > > > 0000000000000000*
> > > > > > > Reserved   00000000000A0000-00000000000FFFFF
> > 870000000000000F
> > > > > > > 0000000000000000
> > > > > > > SystemMem  0000000000100000-0000000099A5DFFF
> > 800000000000000F
> > > > > > > 0000000000000000*
> > > > > > > Reserved   0000000099A5E000-000000009F7FFFFF
> 870000000000000F
> > > > > > > 0000000000000000
> > > > > > > NonExist   000000009F800000-00000000DFFFFFFF
> 0000000000000000
> > > > > > > 0000000000000000
> > > > > > > Reserved   00000000E0000000-00000000EFFFFFFF
> 870000000000000F
> > > > > > > 0000000000000000
> > > > > > > NonExist   00000000F0000000-00000000FBFFFFFF
> 0000000000000000
> > > > > > > 0000000000000000
> > > > > > > Reserved   00000000FC000000-00000000FC000FFF
> > 870000000000000F
> > > > > > > 0000000000000000
> > > > > > > NonExist   00000000FC001000-00000000FDFFFFFF
> 0000000000000000
> > > > > > > 0000000000000000
> > > > > > > Reserved   00000000FE000000-00000000FE00FFFF
> 870000000000000F
> > > > > > > 0000000000000000
> > > > > > > NonExist   00000000FE010000-00000000FEC7FFFF
> 0000000000000000
> > > > > > > 0000000000000000
> > > > > > > MMIO       00000000FEC80000-00000000FECFFFFF
> > C700000000000001
> > > > > > > 0000000000000000*
> > > > > > > NonExist   00000000FED00000-00000000FED0FFFF
> 0000000000000000
> > > > > > > 0000000000000000
> > > > > > > Reserved   00000000FED10000-00000000FED17FFF
> > 870000000000000F
> > > > > > > 0000000000000000
> > > > > > > NonExist   00000000FED18000-00000000FED7FFFF
> 0000000000000000
> > > > > > > 0000000000000000
> > > > > > > Reserved   00000000FED80000-00000000FED83FFF
> > 870000000000000F
> > > > > > > 0000000000000000
> > > > > > > NonExist   00000000FED84000-00000000FED8FFFF
> 0000000000000000
> > > > > > > 0000000000000000
> > > > > > > Reserved   00000000FED90000-00000000FED91FFF
> > 870000000000000F
> > > > > > > 0000000000000000
> > > > > > > NonExist   00000000FED92000-00000000FED9FFFF
> 0000000000000000
> > > > > > > 0000000000000000
> > > > > > > Reserved   00000000FEDA0000-00000000FEDA1FFF
> > 870000000000000F
> > > > > > > 0000000000000000
> > > > > > > NonExist   00000000FEDA2000-00000000FFFFFFFF
> 0000000000000000
> > > > > > > 0000000000000000
> > > > > > > Reserved   0000000100000000-000000085F7FFFFF
> 830000000000000F
> > > > > > > 0000000000000000
> > > > > > > NonExist   000000085F800000-0000007FFFFFFFFF 0000000000000000
> > > > > > > 0000000000000000
> > > > > > >
> > > > > > > At boot I hit an assertion:
> > > > > > >
> > > > > > > PciHostBridgeDxe: IntersectMemoryDescriptor: desc [E0000000,
> > > > F0000000)
> > > > > > > type 1 cap 870000000002600F conflicts with aperture
> > > > [9F800000,FE100000)
> > > > > > > cap 1
> > > > > > >
> > > > > > > which is, at face value, legitimate. However, e0000000 is the
> > MMCONF
> > > > > > > window, and this is where I'd expect it to be. 9f800000 is the base of
> > > > > > > the PCIe host bridge aperture, which is also where I'd expect it to be.
> > > > > > > Coreboot seems to think that this should all work:
> > > > > > >
> > > > > > >  DOMAIN: 0000: Resource ranges:
> > > > > > >  * Base: 9f800000, Size: 40800000, Tag: 200
> > > > > > >  * Base: f0000000, Size: c000000, Tag: 200
> > > > > > >  * Base: fc001000, Size: 1fff000, Tag: 200
> > > > > > >  * Base: fe010000, Size: d00000, Tag: 200
> > > > > > >  * Base: fed18000, Size: 68000, Tag: 200
> > > > > > >  * Base: fed84000, Size: c000, Tag: 200
> > > > > > >  * Base: fed92000, Size: e000, Tag: 200
> > > > > > >  * Base: feda2000, Size: 125e000, Tag: 200
> > > > > > >  * Base: 85f800000, Size: 77a0800000, Tag: 100200
> > > > > > >
> > > > > > > 9f800000+40800000 is e0000000, so that seems fine. There's also
> > some
> > > > > > > other windows, but nothing that collides with the MMCONF region.
> > But
> > > > > > > when we get to Tiano:
> > > > > > >
> > > > > > > PciRoot(0x0)
> > > > > > >   Support/Attr: 7001F / 7001F
> > > > > > >     DmaAbove4G: No
> > > > > > > NoExtConfSpace: No
> > > > > > >      AllocAttr: 0 ()
> > > > > > >            Bus: 0 - 3 Translation=0
> > > > > > >             Io: 1000 - EFFF Translation=0
> > > > > > >            Mem: 9F800000 - FE0FFFFF Translation=0
> > > > > > >
> > > > > > > Which obviously collides with MMCONF, along with a couple of other
> > > > > > > allocations. Is it trying to merge the entire range of MMIO regions
> > into
> > > > > > > a single aperture? Does this seem like a Coreboot or a
> UefiPayloadPkg
> > > > > > > issue?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > 
> >