From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web10.1802.1610058502982793868 for ; Thu, 07 Jan 2021 14:28:23 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HJSsOUf0; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610058502; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+96sGJnkGrKSZWMx5OjMnjaYnnt0CyqQpD57gmRefeE=; b=HJSsOUf0dzF2FDZMw7jRAzVBkBi19S5hFQG+wZQPyd8JOxcFUU2eKsJXx78mx8bMs8i/h0 WfBa4L+Md9blwVrXD9JQApkAf6Kp4g9gTVLUk1ahj5JSVS2AKU6rVD2e2tlmWImnBd1dVa oB0+CrYbYLO+PC8Bpcfhv/Wbhy241uw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-198-RW3j2ihaMI6Nvi7GtSJeWw-1; Thu, 07 Jan 2021 17:28:17 -0500 X-MC-Unique: RW3j2ihaMI6Nvi7GtSJeWw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 44737107ACE6; Thu, 7 Jan 2021 22:28:16 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-164.ams2.redhat.com [10.36.112.164]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9ECCD19C84; Thu, 7 Jan 2021 22:28:14 +0000 (UTC) Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation? To: devel@edk2.groups.io, mjg59@srcf.ucam.org Cc: benjamin.you@intel.com, "Dong, Guo" , "patrick.rudolph@9elements.com" References: <20201227204035.GA16211@codon.org.uk> <20210106223425.GA3280@codon.org.uk> <26ee2dc5-e3fa-8726-eb62-2eb966cc996f@redhat.com> <20210107220413.GA28363@codon.org.uk> From: "Laszlo Ersek" Message-ID: <8bf5849f-bb4d-f00c-bdee-d86cabb05754@redhat.com> Date: Thu, 7 Jan 2021 23:28:13 +0100 MIME-Version: 1.0 In-Reply-To: <20210107220413.GA28363@codon.org.uk> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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