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.8047.1610025254595057129 for ; Thu, 07 Jan 2021 05:14:14 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ahl9YvKF; 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=1610025253; 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=W922sVoGke3fzIkarNFgSU6QpUHPJLswQzDHjVfwVqY=; b=ahl9YvKFS+lybxdi6z/tamn4/2Y9CL8qLt/QVVnL+Qm7F2sEm3ggknMGZTBseF0eWSO0nw 6lanHwBnRf2/17xY0kOEAMfgHKqJMi/Qhl8KncCXSfrUfvfv1yThD//3V/xXemdirPsRkX IeHhEZnSL8asY/o34IH8q2jRjT2XUiI= 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-522-x5djXXZnOdONi4fPV6ZJkw-1; Thu, 07 Jan 2021 08:14:10 -0500 X-MC-Unique: x5djXXZnOdONi4fPV6ZJkw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D1D89100B735; Thu, 7 Jan 2021 13:14:08 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-119.ams2.redhat.com [10.36.114.119]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9269074AA0; Thu, 7 Jan 2021 13:14:07 +0000 (UTC) Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation? To: devel@edk2.groups.io, benjamin.you@intel.com, "Dong, Guo" , "mjg59@srcf.ucam.org" Cc: "patrick.rudolph@9elements.com" References: <20201227204035.GA16211@codon.org.uk> <20210106223425.GA3280@codon.org.uk> From: "Laszlo Ersek" Message-ID: <26ee2dc5-e3fa-8726-eb62-2eb966cc996f@redhat.com> Date: Thu, 7 Jan 2021 14:14:06 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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 05:09, Benjamin You wrote: > Hi, > > The PCI_ROOT_BRIDGE data structure defined in MdeModulePkg\Include\Library\ > PciHostBridgeLib.h does not support reporting non-continuous resources managed > by a root bridge. This is probably proper since it reflects the range of > addresses the root bridge forwards downstream. > > Could the PCI Host Bridge driver be configured to relax the checking against > conflicting resources and exclude those overlapping ranges from the root > bridge resources reported to GCD? If this relaxation is turned on, other BIOS > components should ensure address map consistency. I don't think this will work well. Each (contiguous) aperture type, captured in the PCI_ROOT_BRIDGE structure, is not only used for sanitizing the GCD IO space map or memory space map (as appropriate). Namely, at least the MMIO apertures are also used in RootBridgeIoCheckParameter(), for verifying the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Mem.{Read,Write} member function calls that arrive from (minimally) the PciBusDxe driver. If the MMCONFIG area overlaps such an aperture of the PCI_ROOT_BRIDGE structure, then RootBridgeIoCheckParameter() will not catch EFI_PCI_IO_PROTOCOL.Mem{Read,Write} calls that ultimately translate to that PCI_ROOT_BRIDGE structure *but* mistakenly land in MMCONFIG. I tend to agree with Guo's idea -- more or less, make coreboot export a list of [bus range] -> [contiguous mmio range] entries. Then "UefiPayloadPkg/Library/PciHostBridgeLib" can turn each such entry into a PCI_ROOT_BRIDGE structure. It's not a problem if a single physical root bridge is described by multiple PCI_ROOT_BRIDGE objects, as long as for any two PCI_ROOT_BRIDGE objects, their Bus apertures are distinct. (Other aperture types need not be distinct between PCI_ROOT_BRIDGE objects.) 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. Thanks Laszlo