From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mx.groups.io with SMTP id smtpd.web11.575.1609974285350754611 for ; Wed, 06 Jan 2021 15:04:45 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=PYkhLM5Y; spf=pass (domain: intel.com, ip: 192.55.52.43, mailfrom: guo.dong@intel.com) IronPort-SDR: lQl2QJdYIsUllv7YoTBEqX1XLKQOSwFRGkbS7umXsFU/KaCF6/brqdzua5W79MIc4otRFEaBGg soQs6NFB7Tlg== X-IronPort-AV: E=McAfee;i="6000,8403,9856"; a="262115980" X-IronPort-AV: E=Sophos;i="5.79,328,1602572400"; d="scan'208";a="262115980" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 15:04:44 -0800 IronPort-SDR: WAu46Y3ocFk8n3Ysg+VjNSfe+uXefc8Jn8xU8o+R2/yMuOLGM1VsdnsQoIPA+V6HxOBfzFst9p iqc4/JEzaNnQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,328,1602572400"; d="scan'208";a="395772890" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga004.fm.intel.com with ESMTP; 06 Jan 2021 15:04:44 -0800 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 6 Jan 2021 15:04:43 -0800 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 6 Jan 2021 15:04:43 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.48) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Wed, 6 Jan 2021 15:04:43 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cOc84djtnoPHqCpd8mY8cDpyUwCHPoPJx8E+fxn3YdrT/Np36+lI9FKwzIGFFX+uNL1X5AXCNATTMgBQxZ4Pf7V1eQNEIhfkxULm7Cnjw1XLKRLyMGoOFhxmUDiwJZCQpko9nbRdnNaYLMpqhHreBWkbfdhkBiGl3ukvlpZ51U8Bp1Hx0+nJ1OKzfMuSdI7fhlk8Qq0waZrh7UV475h2tzkI1iRQaMLPcni4ZyASTG8qcgBKDrz/W+6Qgm091SWzW2xB91D7K+79M/Hieyb9WfuhHsreTY/+ZPvKneqmDwaMB2ItWxoLXucLVemxt86r+Q3+NzwjgyBkN2qze164Tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hh0dvhkrJ4VOBM00AMM2Mo1dCepaX95s6BxAuJgRv0s=; b=P4mWMBzCa4liM5VHucSwlHMgCq5tlmPxTrXkUwiMEmDMIRwRgycCoMNltRTR0WiJmFsxNCLZxfQiXvJww4ZQsOEyrJ5o33nh4USvB7Vsb6S24YHdSPXAwJ9Ag3NZlUmyaMQq9/zOcvwdyr28UtTVPlxaFc8WIelwi3cSB2jhaifyGTRNNedwA37xROXq2ILc/35gg9zC+uTdlmUOg52xXYbXft7LoI+66H+OU/pQpphXJm52wT0cciucTyoWRqtw4w/miKbkxmzRx3mI6th2YHoq74SoR8bqzgJ6Q28Gylnir8hhykqfXVbFDZOK8MiS/Fn/TcBIi0+pBAboFhinnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hh0dvhkrJ4VOBM00AMM2Mo1dCepaX95s6BxAuJgRv0s=; b=PYkhLM5YGgeTgUYhYPZ0MfleqpL2aCJOomD3kbSl2JRYHOdp/lvM9F9HJj24hEaw78lXHsUpGCsuskRra638DWRvhbGSomBNuK72yGPgTslv/X8GzSqbqFRalRtUK1M3Fp3kisrB55iR9DAzZw3nZHzDnjLQwd8BKr84bN0mqmk= Received: from BYAPR11MB3622.namprd11.prod.outlook.com (2603:10b6:a03:fe::30) by BYAPR11MB3253.namprd11.prod.outlook.com (2603:10b6:a03:77::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Wed, 6 Jan 2021 23:04:42 +0000 Received: from BYAPR11MB3622.namprd11.prod.outlook.com ([fe80::cc51:e99f:f09d:1268]) by BYAPR11MB3622.namprd11.prod.outlook.com ([fe80::cc51:e99f:f09d:1268%7]) with mapi id 15.20.3742.006; Wed, 6 Jan 2021 23:04:42 +0000 From: "Guo Dong" To: "devel@edk2.groups.io" , "mjg59@srcf.ucam.org" CC: "patrick.rudolph@9elements.com" , "You, Benjamin" Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation? Thread-Topic: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation? Thread-Index: AQHW4j0GQsuQUlThDUC4pnnMHgHBsKoWxu3ggAA76ACAA6BHAIAAi/oQgAAEm4CAAAP8AA== Date: Wed, 6 Jan 2021 23:04:42 +0000 Message-ID: References: <20201227204035.GA16211@codon.org.uk> <20210106223425.GA3280@codon.org.uk> In-Reply-To: <20210106223425.GA3280@codon.org.uk> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: edk2.groups.io; dkim=none (message not signed) header.d=none;edk2.groups.io; dmarc=none action=none header.from=intel.com; x-originating-ip: [68.2.51.172] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1b774b3-1c97-40a8-e2c1-08d8b2977408 x-ms-traffictypediagnostic: BYAPR11MB3253: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 42izrBFAaw95hIOBVHNv0BsgZBcO2bmHp7CLbZkWHPciEoxAU7/ShII7owdDvCfX/jwaRzfQdoXtot6ujJjObPukw/sEyz0WN0CZgE8oqVGuuaR49QuIRgk8P2VGBvipX3U55sSVFuugrlyp42BfMZXw1Rf42TFCBxjKoWuL8PTGQhD1ictk6zTSV5K+oREcwqp51jcqGK7pMWKkPCEZRgTImBvZ+zFR/jfdtHVXMwxsDx+cAGDPyJbu3L7s/tzNMbxfP9QeO09dKtXBTrfbIXWBxdJQ7bxNkmFmUFc2K1ZZ4JNEPi54Pd6J+aFMpq3g0eDz3bfzRWKkWL+9OoXeyiQehjpR8Y1lroDBcRzUwCjCpe2Ru5ey0gVnk81gHlnuz+Apg6budrXZemEjqcSmOPWshtD+7T5MNvrcWXS3ngsoQUIuQkqNBcEsUu3ZefMiC8UWFNiDWxLO3KL/I+5R9A== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR11MB3622.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(376002)(39860400002)(366004)(136003)(396003)(346002)(71200400001)(8676002)(8936002)(5660300002)(55016002)(9686003)(107886003)(26005)(66574015)(83380400001)(53546011)(6506007)(186003)(66446008)(316002)(2906002)(33656002)(7696005)(966005)(110136005)(478600001)(76116006)(54906003)(4326008)(66476007)(86362001)(52536014)(66946007)(66556008)(64756008);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?zEfmauc9Q+MvjqVTAMuS6FRSibDeU3nJh5lBumRc4h+SNoZ/Mw39qpAIa+?= =?iso-8859-1?Q?rIK1cUJjlVHmGlwZbfjgQ6wGvCoL5lxQrCrfUdLKzu8hGXfK+HN/oLNVLy?= =?iso-8859-1?Q?+2BFCnY6/EUC3YIj2t9rMhYZMboeuOXSPVU3gjYElBYh51Symc17UtVBm7?= =?iso-8859-1?Q?ebzl0TdKGI5N0ttM25ziVUJSECQxrrNYTZMf6Q3o0zQTD9aATjqy4f0ycd?= =?iso-8859-1?Q?uNpi0I+AoaP/Dnaadkrh2VsZ1hWIKZq7aZnL7Wnq88dKcsI75BdkH0eWDV?= =?iso-8859-1?Q?9ga8ALzEtqPYRkRHv8ALjhVwu6FJCNxhuMD8mnpaKSYmlU45Ch1jFwxw3c?= =?iso-8859-1?Q?ZBFmzSkHgcHjh7GHgVm60HI9zFY2DAQfPyJfUlvvXGy3lsGzTugsvP2/OA?= =?iso-8859-1?Q?K9BM7vf9ZDXoZME1vR9lzzy47eTA2XpbHrCbaRdoIRzRRR3plyFD2iK0VO?= =?iso-8859-1?Q?OOUx9ejWY3Ui6CI7BioP4QPWHQ6coWr2HOvkePI6vCq/FAfXouQ66e2G/A?= =?iso-8859-1?Q?uQ17zJopaBYrm0AW3kVnyfEtokPWuH8YKvbQiQSi4nn2ItSCWDBXC98bcp?= =?iso-8859-1?Q?p95BpgFV6aCoDBw03mQNzuSmPXRV+IR0syt2VZUuu6c9PekIbATp1r7Mr4?= =?iso-8859-1?Q?pLjImwh6Df10k18y7mmvT1/KQCCukPGlJNoA9e3xS3lvVY1SrzFHjzH3EM?= =?iso-8859-1?Q?2bymmrv4TkkTD6UkwMh0cOhaZKdz9IJ+mvFy4vDCxw+xvqI5ku0xMPfD/Y?= =?iso-8859-1?Q?pDtCqB8wQpbCLsh6iOEZ+lCuzm+dHtEgdHPFUeBzaBl8ohcPxzpY6+V2Hi?= =?iso-8859-1?Q?FSz/Rm4JyGEKZqdmkmQKi9vLfAPebRfWDD8Hf8ugBvjj6D5GSmkNMrwzO9?= =?iso-8859-1?Q?uM7HyYbIW2EYTfKo4N1jqFoxesGIvkuVbwHfiRkjT1DFbzw4NDFuTSLKDK?= =?iso-8859-1?Q?Sn60bMnCE19IF6Ep4grMNAfS+bHdeRo2rh5jOKxWuWG9EI8urs24ePI3tg?= =?iso-8859-1?Q?0DIrZ8+L3Z+Pgl5qI=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3622.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e1b774b3-1c97-40a8-e2c1-08d8b2977408 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2021 23:04:42.7791 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: o1nm6Z7MjvnkKDFCOA3ywHAEY7twvtUEUotw4Vt69uQT4ZazVpFOBmPzIzFJbfgVEiHWsusa9xdYwSg3pmko7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3253 Return-Path: guo.dong@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is not related with OS. For example, SBL add a new HOB (coreboot could put such info in coreboot t= able) for the PCI resources,=20 So in the UEFI payload, it could retrieve and use these info, instead of r= unning ScanForRootBridges() in uefipayloadpkg\library\pcihostbridgelib\PciH= ostBridgeSupport.c since the UEFI payload assumption. Thanks, Guo > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Matthew > Garrett > Sent: Wednesday, January 6, 2021 3:34 PM > To: Dong, Guo > Cc: devel@edk2.groups.io; patrick.rudolph@9elements.com; You, Benjamin > > Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource > allocation? >=20 > How should these ranges be reported? They need to be treated as reserved > by the OS, not exposed as PCI resources. >=20 > 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 re= source for > it. > > I would prefer bootloader report these PCI resource range to payload. > > > > Thanks, > > Guo > > > > > -----Original Message----- > > > From: devel@edk2.groups.io On Behalf Of Patri= ck > > > Rudolph > > > Sent: Wednesday, January 6, 2021 6:57 AM > > > To: devel@edk2.groups.io; You, Benjamin > > > Cc: Dong, Guo ; 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 activ= e > > > BARs, like UART in ACPI mode or the PMC/P2SB device. > > > Those memory regions are marked as reserved in e820 tables and colli= de > > > with the assumption of a contiguous memory space. > > > It is contiguous, but that is not visible by the PCI Host bridge dri= ver. > > > > > > Kind Regards, > > > Patrick Rudolph > > > > > > Patrick Rudolph > > > B.Sc. Electrical Engineering > > > System Firmware Developer > > > > > > > > > 9elements GmbH, Kortumstra=DFe 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=E4ftsf=FChrung: 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 > 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-cont= inuous > > > 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 MMI= O > > > resources > > > > reported to GCD. (MMCONF is defined by PcdPciExpressBaseAddress an= d > > > > PcdPciExpressBaseSize). A PCD could be defined to enable such beha= vior > > > (with > > > > default as FALSE to maintain backward compatibility). > > > > > > > > Thanks, > > > > > > > > - ben > > > > > > > > > -----Original Message----- > > > > > From: devel@edk2.groups.io On Behalf Of G= uo > > > 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 reso= urce > > > > > allocation? > > > > > > > > > > > > > > > Hi, > > > > > > > > > > The pcihostbridgelib in the uefipayloadpkg would scan the PCI b= ridge to > > > collect > > > > > the assigned PCI resource information. > > > > > During scanning, there is an assumption that the PCI memory reso= urce > 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 P= CIe > > > base > > > > > address. > > > > > > > > > > You could check which PCI device is assigned with FE0FFFFF in co= reboot, > and > > > > > change it before 0xE0000000. > > > > > > > > > > I am thinking we could update pcihostbridgelib to get the PCI re= source > > > > > 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 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 resour= ce > > > allocation? > > > > > > > > > > > > I'm trying to run UefiPayloadPkg on a Coreboot-based system. B= ased > on > > > > > > debug logs, my GCD looks like this: > > > > > > > > > > > > GCDMemType Range Capabilities = Attributes > > > > > > =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, > > > 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 als= o > some > > > > > > other windows, but nothing that collides with the MMCONF regio= n. > 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 o= ther > > > > > > allocations. Is it trying to merge the entire range of MMIO re= gions > into > > > > > > a single aperture? Does this seem like a Coreboot or a UefiPay= loadPkg > > > > > > issue? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 >=20 >=20