From: "Matthew Garrett" <mjg59@srcf.ucam.org>
To: "Dong, Guo" <guo.dong@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"patrick.rudolph@9elements.com" <patrick.rudolph@9elements.com>,
"You, Benjamin" <benjamin.you@intel.com>
Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
Date: Wed, 6 Jan 2021 22:34:25 +0000 [thread overview]
Message-ID: <20210106223425.GA3280@codon.org.uk> (raw)
In-Reply-To: <BYAPR11MB36223F9CA8451FEB1FD45D0C9ED00@BYAPR11MB3622.namprd11.prod.outlook.com>
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?
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
next prev parent reply other threads:[~2021-01-06 22:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210106223425.GA3280@codon.org.uk \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox