From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from cavan.codon.org.uk (cavan.codon.org.uk [176.126.240.207]) by mx.groups.io with SMTP id smtpd.web12.173.1609972468277851640 for ; Wed, 06 Jan 2021 14:34:29 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: codon.org.uk, ip: 176.126.240.207, mailfrom: mjg59@codon.org.uk) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id A59484164D; Wed, 6 Jan 2021 22:34:25 +0000 (UTC) Date: Wed, 6 Jan 2021 22:34:25 +0000 From: "Matthew Garrett" To: "Dong, Guo" Cc: "devel@edk2.groups.io" , "patrick.rudolph@9elements.com" , "You, Benjamin" Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation? Message-ID: <20210106223425.GA3280@codon.org.uk> References: <20201227204035.GA16211@codon.org.uk> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > Yes. If a device is hidden, the Payload could not scan and find the reso= urce for it. > I would prefer bootloader report these PCI resource range to payload. >=20 > Thanks, > Guo >=20 > > -----Original Message----- > > From: devel@edk2.groups.io On Behalf Of Patrick > > Rudolph > > Sent: Wednesday, January 6, 2021 6:57 AM > > To: devel@edk2.groups.io; You, Benjamin > > Cc: Dong, Guo ; mjg59@srcf.ucam.org > > Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource > > allocation? > >=20 > > 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 drive= r. > >=20 > > Kind Regards, > > Patrick Rudolph > >=20 > > Patrick Rudolph > > B.Sc. Electrical Engineering > > System Firmware Developer > >=20 > >=20 > > 9elements GmbH, Kortumstra=DFe 19-21, 44787 Bochum, Germany > > Email: patrick.rudolph@9elements.com > > Phone: +49 234 68 94 188 > >=20 > > Sitz der Gesellschaft: Bochum > > Handelsregister: Amtsgericht Bochum, HRB 17519 > > Gesch=E4ftsf=FChrung: Sebastian Deutsch, Eray Basar > >=20 > > Datenschutzhinweise nach Art. 13 DSGVO > >=20 > >=20 > > Am Mo., 4. Jan. 2021 um 07:34 Uhr schrieb Benjamin You > > : > > > > > > Hi, > > > > > > Current PCI Host Bridge driver treats resources reported from root b= ridges > > > as continuous and performs rigorous checking against overlaps with e= xisting > > > resources such as MMCONF. > > > > > > I think to support the case where a root bridge reports a non-contin= uous > > range > > > that encompasses the MMCONF, a policy could be defined for the PCI H= ost > > 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 behavi= or > > (with > > > default as FALSE to maintain backward compatibility). > > > > > > Thanks, > > > > > > - ben > > > > > > > -----Original Message----- > > > > From: 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 resour= ce > > > > allocation? > > > > > > > > > > > > Hi, > > > > > > > > The pcihostbridgelib in the uefipayloadpkg would scan the PCI bri= dge to > > collect > > > > the assigned PCI resource information. > > > > During scanning, there is an assumption that the PCI memory resour= ce is > > > > allocated continuously without gaps. > > > > > > > > In your case, it looks the lowest resource address is 9F800000, an= d the high > > > > resource address is FE0FFFFF. > > > > There is a gap (0xE0000000 ~ 0xF0000000) between them used for PCI= e > > base > > > > address. > > > > > > > > You could check which PCI device is assigned with FE0FFFFF in core= boot, and > > > > change it before 0xE0000000. > > > > > > > > I am thinking we could update pcihostbridgelib to get the PCI reso= urce > > > > information from bootloader (coreboot and SBL) > > > > instead of scanning the PCI bridge to get the range. Let me know i= f having > > > > comments. > > > > > > > > Thanks, > > > > Guo > > > > > > > > > -----Original Message----- > > > > > From: 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. Bas= ed on > > > > > debug logs, my GCD looks like this: > > > > > > > > > > GCDMemType Range Capabilities At= tributes > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > 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 MM= CONF > > > > > window, and this is where I'd expect it to be. 9f800000 is the b= ase 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=3D0 > > > > > Io: 1000 - EFFF Translation=3D0 > > > > > Mem: 9F800000 - FE0FFFFF Translation=3D0 > > > > > > > > > > Which obviously collides with MMCONF, along with a couple of oth= er > > > > > allocations. Is it trying to merge the entire range of MMIO regi= ons into > > > > > a single aperture? Does this seem like a Coreboot or a UefiPaylo= adPkg > > > > > issue? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > >=20 > >=20 > >=20 >=20