public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Matthew Garrett" <mjg59@srcf.ucam.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: devel@edk2.groups.io, benjamin.you@intel.com, "Dong,
	Guo" <guo.dong@intel.com>,
	"patrick.rudolph@9elements.com" <patrick.rudolph@9elements.com>
Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation?
Date: Thu, 7 Jan 2021 22:04:13 +0000	[thread overview]
Message-ID: <20210107220413.GA28363@codon.org.uk> (raw)
In-Reply-To: <26ee2dc5-e3fa-8726-eb62-2eb966cc996f@redhat.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)

  reply	other threads:[~2021-01-07 22:04 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
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 [this message]
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=20210107220413.GA28363@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