From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) by mx.groups.io with SMTP id smtpd.web10.8128.1609941428420821408 for ; Wed, 06 Jan 2021 05:57:08 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@9elements.com header.s=google header.b=I6ER030P; spf=pass (domain: 9elements.com, ip: 209.85.210.51, mailfrom: patrick.rudolph@9elements.com) Received: by mail-ot1-f51.google.com with SMTP id b24so3073435otj.0 for ; Wed, 06 Jan 2021 05:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9elements.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mSRx1TdiagC2Xha2JcQTmH3M+/qMg6/NNAz6n3zShXM=; b=I6ER030PkzWAj2ZZuQPd+EeizQMcZld4YEZ8spcp2pVCL1FTxYpzDRzyxd70l88k5T JzKgb1v74cF6mqHg5HuODwSFd3mixQNXDUVwrAq/xQT0+ltGaIHxv9+T0up5tn1/bYGB huTzIHgiKuOq5SJxoVX/r1/VtN42I+Ha7vy2VO3H5oF6r2yW1WabOhAv0K3jdtiPARP3 BaBCy85XnmIgn4mNDMZi1X8PkDOZBzLRcRDcmaAgBUqdyM1S9kQmVH88o7A/1zyDrYWU IIqVH6eAEmvkkBTo7aANRQ0pRfrNEne1Xt7FrGP5FFb2lvIKrMbDde5pa4dV+OT7WSyh r0iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mSRx1TdiagC2Xha2JcQTmH3M+/qMg6/NNAz6n3zShXM=; b=VYpHVgZphpAC9WN5/UU+4QW2KkucEunRYwdFlhMzg8DafohjBiV+YHte18GDfeSe02 0+MklsoA/XWSa08Shx6NFuY9V+8fWR/x6HZl3ysGkwrKey2RoLHI+ePQbMTAecoohT+G YfBjzTVD7Nh7hR5hHPbyBYtX4irhAsStRecI3N+0pLRS0LJG86x6qSMwAJF87KfPxm8f J3quSnEXPhLq+iAumc4pTMsEHHbZXYorBCbGssV9N/Dd7Q2x2JrOblI7hwqsI1VNmWOs RSRSgRnHr6+zElonKodY7SrDDLF1If1Avo6QuL3hyktQGP+Rd2GCC/Ij6ETm4uSzTL3Q 4f9w== X-Gm-Message-State: AOAM530UOIgznePanudqY3vRTkmXxPwe5z+UMUGr6oDJf2Yg9X3Vku45 1/hjPRmRkLP5mvpn/fXtxeygPBu5hrtkuUwYShczWEOjZ8tC0g== X-Google-Smtp-Source: ABdhPJxH8OdlwDoHwKh5g17lCa8p8XVe+LRothoyuLj6z+pqT0em5zR+RuRPXVhTWeMpyN6qjbhNElD9Ms1GvuEW9xY= X-Received: by 2002:a05:6830:1e7a:: with SMTP id m26mr3305261otr.78.1609941427391; Wed, 06 Jan 2021 05:57:07 -0800 (PST) MIME-Version: 1.0 References: <20201227204035.GA16211@codon.org.uk> In-Reply-To: From: "Patrick Rudolph" Date: Wed, 6 Jan 2021 14:56:56 +0100 Message-ID: Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation? To: devel@edk2.groups.io, "You, Benjamin" Cc: "Dong, Guo" , "mjg59@srcf.ucam.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=9Fe 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=C3=A4ftsf=C3=BChrung: Sebastian Deutsch, Eray Basar Datenschutzhinweise nach Art. 13 DSGVO Am Mo., 4. Jan. 2021 um 07:34 Uhr schrieb Benjamin You : > > Hi, > > Current PCI Host Bridge driver treats resources reported from root bridg= es > as continuous and performs rigorous checking against overlaps with exist= ing > 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 reso= urces > 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 On Behalf Of Guo Don= g > > 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 i= s > > allocated continuously without gaps. > > > > In your case, it looks the lowest resource address is 9F800000, and th= e high > > resource address is FE0FFFFF. > > There is a gap (0xE0000000 ~ 0xF0000000) between them used for PCIe ba= se > > 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 ha= ving > > comments. > > > > Thanks, > > Guo > > > > > -----Original Message----- > > > From: devel@edk2.groups.io On Behalf Of Matth= ew > > > Garrett > > > Sent: Sunday, December 27, 2020 1:41 PM > > > To: devel@edk2.groups.io > > > Subject: [edk2-devel] UefiPayloadPkg and over-eager PCI resource all= ocation? > > > > > > I'm trying to run UefiPayloadPkg on a Coreboot-based system. Based o= n > > > debug logs, my GCD looks like this: > > > > > > GCDMemType Range Capabilities Attrib= utes > > > =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, F000000= 0) > > > type 1 cap 870000000002600F conflicts with aperture [9F800000,FE1000= 00) > > > 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=3D0 > > > Io: 1000 - EFFF Translation=3D0 > > > Mem: 9F800000 - FE0FFFFF Translation=3D0 > > > > > > 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 UefiPayloadPk= g > > > issue? > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > >