* UefiPayloadPkg and over-eager PCI resource allocation?
@ 2020-12-27 20:40 mjg59
2021-01-04 3:17 ` [edk2-devel] " Guo Dong
0 siblings, 1 reply; 13+ messages in thread
From: mjg59 @ 2020-12-27 20:40 UTC (permalink / raw)
To: devel
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2020-12-27 20:40 UefiPayloadPkg and over-eager PCI resource allocation? mjg59
@ 2021-01-04 3:17 ` Guo Dong
2021-01-04 6:34 ` Benjamin You
0 siblings, 1 reply; 13+ messages in thread
From: Guo Dong @ 2021-01-04 3:17 UTC (permalink / raw)
To: devel@edk2.groups.io, mjg59@srcf.ucam.org
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?
>
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-04 3:17 ` [edk2-devel] " Guo Dong
@ 2021-01-04 6:34 ` Benjamin You
2021-01-06 13:56 ` Patrick Rudolph
0 siblings, 1 reply; 13+ messages in thread
From: Benjamin You @ 2021-01-04 6:34 UTC (permalink / raw)
To: devel@edk2.groups.io, Dong, Guo, mjg59@srcf.ucam.org
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?
> >
> >
> >
> >
>
>
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-04 6:34 ` Benjamin You
@ 2021-01-06 13:56 ` Patrick Rudolph
2021-01-06 22:20 ` Guo Dong
0 siblings, 1 reply; 13+ messages in thread
From: Patrick Rudolph @ 2021-01-06 13:56 UTC (permalink / raw)
To: devel, You, Benjamin; +Cc: Dong, Guo, mjg59@srcf.ucam.org
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?
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-06 13:56 ` Patrick Rudolph
@ 2021-01-06 22:20 ` Guo Dong
2021-01-06 22:34 ` Matthew Garrett
0 siblings, 1 reply; 13+ messages in thread
From: Guo Dong @ 2021-01-06 22:20 UTC (permalink / raw)
To: devel@edk2.groups.io, patrick.rudolph@9elements.com,
You, Benjamin
Cc: mjg59@srcf.ucam.org
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?
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-06 22:20 ` Guo Dong
@ 2021-01-06 22:34 ` Matthew Garrett
2021-01-06 23:04 ` Guo Dong
0 siblings, 1 reply; 13+ messages in thread
From: Matthew Garrett @ 2021-01-06 22:34 UTC (permalink / raw)
To: Dong, Guo
Cc: devel@edk2.groups.io, patrick.rudolph@9elements.com,
You, Benjamin
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?
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-06 22:34 ` Matthew Garrett
@ 2021-01-06 23:04 ` Guo Dong
2021-01-07 4:09 ` Benjamin You
0 siblings, 1 reply; 13+ messages in thread
From: Guo Dong @ 2021-01-06 23:04 UTC (permalink / raw)
To: devel@edk2.groups.io, mjg59@srcf.ucam.org
Cc: patrick.rudolph@9elements.com, You, Benjamin
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?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-06 23:04 ` Guo Dong
@ 2021-01-07 4:09 ` Benjamin You
2021-01-07 13:14 ` Laszlo Ersek
0 siblings, 1 reply; 13+ messages in thread
From: Benjamin You @ 2021-01-07 4:09 UTC (permalink / raw)
To: Dong, Guo, devel@edk2.groups.io, mjg59@srcf.ucam.org
Cc: patrick.rudolph@9elements.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?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-07 4:09 ` Benjamin You
@ 2021-01-07 13:14 ` Laszlo Ersek
2021-01-07 22:04 ` Matthew Garrett
0 siblings, 1 reply; 13+ messages in thread
From: Laszlo Ersek @ 2021-01-07 13:14 UTC (permalink / raw)
To: devel, benjamin.you, Dong, Guo, mjg59@srcf.ucam.org
Cc: patrick.rudolph@9elements.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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-07 13:14 ` Laszlo Ersek
@ 2021-01-07 22:04 ` Matthew Garrett
2021-01-07 22:28 ` Laszlo Ersek
0 siblings, 1 reply; 13+ messages in thread
From: Matthew Garrett @ 2021-01-07 22:04 UTC (permalink / raw)
To: Laszlo Ersek
Cc: devel, benjamin.you, Dong, Guo, patrick.rudolph@9elements.com
On Thu, Jan 07, 2021 at 02:14:06PM +0100, Laszlo Ersek wrote:
> 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.
No, bus 0 includes addresses above and below MMCONFIG, and I'm not
really sure how it could avoid doing so without moving MMCONFIG. Certain
resources in bus 0 are required to be in the high 0xf0000000 range, and
there's not enough space between the top of MMCONFIG and there to map
everything else from bus 0 and keep them accessible to 32-bit
environments. So that would presumably mean pushing MMCONFIG down from
0xe0000000, which is certainly possible but I'd worry that some things
may make assumptions about where it's located.
(The resource layout under Coreboot matches the resource layout under
vendor firmware running on the same system, so this doesn't seem like a
Coreboot-specific thing - if EDK2 requires that there be no overlap
between MMCONFIG and the resources allocated to single bus, it seems
like EDK2 doesn't match the expectations of vendor UEFI implementations
and may cause problems in future. Older versions of UEFIPayload don't
seem to enforce this)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-07 22:04 ` Matthew Garrett
@ 2021-01-07 22:28 ` Laszlo Ersek
2021-01-07 22:39 ` Matthew Garrett
0 siblings, 1 reply; 13+ messages in thread
From: Laszlo Ersek @ 2021-01-07 22:28 UTC (permalink / raw)
To: devel, mjg59; +Cc: benjamin.you, Dong, Guo, patrick.rudolph@9elements.com
On 01/07/21 23:04, Matthew Garrett wrote:
> On Thu, Jan 07, 2021 at 02:14:06PM +0100, Laszlo Ersek wrote:
>
>> 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.
>
> No, bus 0 includes addresses above and below MMCONFIG, and I'm not
> really sure how it could avoid doing so without moving MMCONFIG. Certain
> resources in bus 0 are required to be in the high 0xf0000000 range, and
> there's not enough space between the top of MMCONFIG and there to map
> everything else from bus 0 and keep them accessible to 32-bit
> environments. So that would presumably mean pushing MMCONFIG down from
> 0xe0000000, which is certainly possible but I'd worry that some things
> may make assumptions about where it's located.
>
> (The resource layout under Coreboot matches the resource layout under
> vendor firmware running on the same system, so this doesn't seem like a
> Coreboot-specific thing - if EDK2 requires that there be no overlap
> between MMCONFIG and the resources allocated to single bus, it seems
> like EDK2 doesn't match the expectations of vendor UEFI implementations
> and may cause problems in future. Older versions of UEFIPayload don't
> seem to enforce this)
The last statement is intriguing, it suggests something could be bisected...
But then I run a git-log on
UefiPayloadPkg/Library/PciHostBridgeLib
and I find *one* commit, namely the *ridiculously* huge commit
04af8bf262f1 ("UefiPayloadPkg: Enhance UEFI payload for coreboot and
Slim Bootloader", 2019-04-15).
That commit lists *at least* 10 separate high-level tasks in the commit
message, and has the beautiful diffstat
50 files changed, 8566 insertions(+)
In other words, it's a code drop that's *maybe* tolerable for the
github.com "squash on merge" crowd, but honestly, it has *no place* in edk2.
I don't know what to recommend. And every time I obsess publicly in the
edk2 community about the importance of bisectability, I mostly draw
blank stares. Go figure.
... Apparently said commit was the initial addition of UefiPayloadPkg as
a whole to edk2. From the commit message, it was meant to replace
CorebootModulePkg and CorebootPayloadPkg. At commit 04af8bf262f1, those
separate packages still exist.
... Hm, they were removed later, in commit f684c3f5eef4 ("Coreboot*Pkg:
Retire CorebootPayloadPkg and CorebootModulePkg", 2019-05-10). So
perhaps a UEFI Payload built from CorebootModulePkg and
CorebootPayloadPkg could be bisected, up to and excluding commit
f684c3f5eef4.
However, if the symptom appeared with the "big switch" from Coreboot*Pkg
to UefiPayloadPkg (that is, with commit 04af8bf262f1), then it's a
design limitation in PciHostBridgeLib :(
Laszlo
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-07 22:28 ` Laszlo Ersek
@ 2021-01-07 22:39 ` Matthew Garrett
2021-01-08 2:18 ` Guo Dong
0 siblings, 1 reply; 13+ messages in thread
From: Matthew Garrett @ 2021-01-07 22:39 UTC (permalink / raw)
To: Laszlo Ersek
Cc: devel, benjamin.you, Dong, Guo, patrick.rudolph@9elements.com
On Thu, Jan 07, 2021 at 11:28:13PM +0100, Laszlo Ersek wrote:
> But then I run a git-log on
>
> UefiPayloadPkg/Library/PciHostBridgeLib
>
> and I find *one* commit, namely the *ridiculously* huge commit
> 04af8bf262f1 ("UefiPayloadPkg: Enhance UEFI payload for coreboot and
> Slim Bootloader", 2019-04-15).
Yeah, that commit is present in my working tree. And there don't seem to
be any recent changes to PciHostBridgeDxe. Hmm, now I'm confused.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
2021-01-07 22:39 ` Matthew Garrett
@ 2021-01-08 2:18 ` Guo Dong
0 siblings, 0 replies; 13+ messages in thread
From: Guo Dong @ 2021-01-08 2:18 UTC (permalink / raw)
To: devel@edk2.groups.io, mjg59@srcf.ucam.org, Laszlo Ersek
Cc: You, Benjamin, patrick.rudolph@9elements.com
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Matthew
> Garrett
> Sent: Thursday, January 7, 2021 3:40 PM
> To: Laszlo Ersek <lersek@redhat.com>
> Cc: devel@edk2.groups.io; You, Benjamin <benjamin.you@intel.com>; Dong,
> Guo <guo.dong@intel.com>; patrick.rudolph@9elements.com
> Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource
> allocation?
>
> On Thu, Jan 07, 2021 at 11:28:13PM +0100, Laszlo Ersek wrote:
>
> > But then I run a git-log on
> >
> > UefiPayloadPkg/Library/PciHostBridgeLib
> >
> > and I find *one* commit, namely the *ridiculously* huge commit
> > 04af8bf262f1 ("UefiPayloadPkg: Enhance UEFI payload for coreboot and
> > Slim Bootloader", 2019-04-15).
>
> Yeah, that commit is present in my working tree. And there don't seem to
> be any recent changes to PciHostBridgeDxe. Hmm, now I'm confused.
>
I don't remember we changed PciHostBridgeDxe recently. And also don't know
how it could work if the PCI resource has a big range including PCI CFG space.
Anyway, maybe you could narrow down which commit caused this issue.
Every time we made change, we tried to make it as compatible change.
But I did remove some hardcoded values in the UEFI payload from a big
patch "UefiPayloadPkg: Remove PEI phase from Payload". But I don't know
how they could be related with your current issue.
Thanks,
Guo
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-01-08 2:18 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-12-27 20:40 UefiPayloadPkg and over-eager PCI resource allocation? mjg59
2021-01-04 3:17 ` [edk2-devel] " Guo Dong
2021-01-04 6:34 ` Benjamin You
2021-01-06 13:56 ` Patrick Rudolph
2021-01-06 22:20 ` Guo Dong
2021-01-06 22:34 ` Matthew Garrett
2021-01-06 23:04 ` Guo Dong
2021-01-07 4:09 ` Benjamin You
2021-01-07 13:14 ` Laszlo Ersek
2021-01-07 22:04 ` Matthew Garrett
2021-01-07 22:28 ` Laszlo Ersek
2021-01-07 22:39 ` Matthew Garrett
2021-01-08 2:18 ` Guo Dong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox