From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mx.groups.io with SMTP id smtpd.web12.3970.1609992572538650502 for ; Wed, 06 Jan 2021 20:09:32 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=YevAzlwf; spf=pass (domain: intel.com, ip: 192.55.52.151, mailfrom: benjamin.you@intel.com) IronPort-SDR: gLqnrHUCDcprJpzCdI/on1K6axBKqFCehfCGoQredseYQdyinln821a94JU0hpiGGUXmHjuwjy 9dF8SjAZf4fA== X-IronPort-AV: E=McAfee;i="6000,8403,9856"; a="157154293" X-IronPort-AV: E=Sophos;i="5.79,328,1602572400"; d="scan'208";a="157154293" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 20:09:30 -0800 IronPort-SDR: VQi0xtNfzB5SeBB3hxZRGgSq3uIw1C8uQujq05lSGXpd9pt0HBx6iEz4CSWBBnH19LZwOZ4Hsn YIOukvqz5CBw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,328,1602572400"; d="scan'208";a="462899590" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga001.fm.intel.com with ESMTP; 06 Jan 2021 20:09:29 -0800 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx601.amr.corp.intel.com (10.18.126.81) 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 20:09:28 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx602.amr.corp.intel.com (10.18.126.82) 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 20:09:28 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.173) by edgegateway.intel.com (192.55.55.70) 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 20:09:28 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hA2FBau9labHa62vupQZTru24NHn90VaoHbduE+w6esp7ZS3owylPZ6KCUOnfQP6vqVG95eF5xKeKWW78geIZZcGi/4FQgvApwQFI70rppFlqbPcsRF93pr1Mg0HtZ0r0lrJ9uexnWdNQZSOSjD/RH8utQOxHk6pYGU+cp5+0Ey5s08G9eQSaRdTeo4Xg06RGR1g9iCqEf+eDHDRdjjN9oozPt97CoNlTA5q+bT3pjlJFYozAW4eVpdFEv1vPBf4FkGQQqL4ETqXlH9Pad+xFDfA9+RMPY9KC4eP3v5WK/kZRc7V8V9ySotq0oCtuGi3a7pEZQbK1VoM4DKw22Zf1g== 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=+sJzE+JjBDLcZPAnSK4upqwZ2w/T4yK6haiOs1ZVc9w=; b=l/mDJczWF9A+9EH6hA00FBkA9TD1Tj6lEbayD1c8IaP17G8sGsNLzAAlOdiL1lpTJr+n9PIx58uqeFSuMR4SLIpR3SwnjOX4lM6lU2GRceu148UlKABsQiffdedEG7sSaSthJbCw77DGc1BtrO09rMe1B0r4nzIQ7vAhEtFrPCauA7iKi0b5YkR0uTfoaPnlLhJ6HpilMRKNZWaXoK4YS0BCUIpAnxV2ndt7kMO2jhOTfoNJwRvvo5TUnPDx4oG9FU7huZxDIt38YyrUClEt+c5Gu7wNJSdHk8E6WjRiN8g0BhorO8MiVnnRvlDXJnzFyAex23GFYk3jvEEXyWV5eQ== 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=+sJzE+JjBDLcZPAnSK4upqwZ2w/T4yK6haiOs1ZVc9w=; b=YevAzlwfg1MPfpXLoodqPIWEBJRbu2g5p/fkFPMP+ToezWZlf8Vz+4alMCuuAtCxo3NrYdi7GjKtSIdZvRPCXLZ/ycT24fDYBHaYIT6DxQq3CqEpwYUT8X0WA71RWPZvyy0F0TdAjZc51LRPIBic73MhHBuEAzRxGNk8Juu0g9E= Received: from BN8PR11MB3748.namprd11.prod.outlook.com (2603:10b6:408:86::21) by BN6PR11MB2049.namprd11.prod.outlook.com (2603:10b6:404:46::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Thu, 7 Jan 2021 04:09:27 +0000 Received: from BN8PR11MB3748.namprd11.prod.outlook.com ([fe80::1c43:b8d:cb4f:5cdc]) by BN8PR11MB3748.namprd11.prod.outlook.com ([fe80::1c43:b8d:cb4f:5cdc%5]) with mapi id 15.20.3742.006; Thu, 7 Jan 2021 04:09:27 +0000 From: "Benjamin You" To: "Dong, Guo" , "devel@edk2.groups.io" , "mjg59@srcf.ucam.org" CC: "patrick.rudolph@9elements.com" Subject: Re: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation? Thread-Topic: [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation? Thread-Index: AQHW4j0Ifjlsx7o+PUKybQhNc3bN2qoWy8CAgAAtk1CAA6nJAIAAjLIAgAAD44CAAAh2AIAATjUQ Date: Thu, 7 Jan 2021 04:09:26 +0000 Message-ID: References: <20201227204035.GA16211@codon.org.uk> <20210106223425.GA3280@codon.org.uk> In-Reply-To: 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: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.196] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 99691c43-8c16-4709-bddf-08d8b2c2063a x-ms-traffictypediagnostic: BN6PR11MB2049: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 24NZtQ8S4GOfyLfafXFBEOKs80AHjLwok+0LbLEoKtJrxNkvGEfv1F50vfOBZkS8x+zsu9O/pB0T7dxouo/8T3UAPKQmKyyMtRCBKZQqTnfGLYVCIVXeO5vp8GepvGJ/nYTgX2SVkPSKaHgvIYZsj8nq9VXg8RALrmCkGvBbXpTDsZR0OE56v4CPUqjqE5qKGS55cJaP9W3x6eXO/CDoJ/u0gTGb+ygCH7M//jJuNE2vdp7UpMROUiWIUp2aCX26T/4dDwLheTqsuUufKLVYixn8G3WSsCY3qQii5ulECXUeWDXHm6OYoRvrtu+sveV12SDC2XXhZjX7/Uxh09PX/Lvcb3D1ToB0Jj9O93kKEj72jAoCdvq5oxKII/fQYTjA03fUm0D8I4yRr4v0Cy3Obe6FixmhAsAVWaDeRQZo67SShaGanENZ/T8siStvmC+J4eRC9OF+KKBECeztpbQUZw== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN8PR11MB3748.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(396003)(346002)(39860400002)(366004)(136003)(376002)(66946007)(55016002)(86362001)(52536014)(76116006)(6506007)(66556008)(53546011)(66476007)(26005)(186003)(4326008)(66446008)(66574015)(5660300002)(2906002)(8676002)(9686003)(7696005)(33656002)(316002)(71200400001)(110136005)(30864003)(83380400001)(966005)(8936002)(64756008)(478600001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?i44VddzckunSQe7ayZQBZKqzUVNUug6afL9KuY+/BsAXu18lyS572iIZho?= =?iso-8859-1?Q?6dzwn13kU5DyICHSUwu4lKBZ7/9tOaQ/oXXltm7wbx9HGJg8tFDkF17XGN?= =?iso-8859-1?Q?0k6qhR4EO5EBqkJQOIP1OokmuIF9R3UWnipeqdW07Yf/srQM3CP5hyAt+4?= =?iso-8859-1?Q?14/3UWkYfiTWs3uL5qQBbEbqHJQWdh3A7noK59YzK2mE6ovE7Pxipn8Ks9?= =?iso-8859-1?Q?kl6BMEa+U0HPQtVrW9sWIFhRIcXxR0bVPfhtAGnjsOq2tB7z9g36ckx4VE?= =?iso-8859-1?Q?B1JugPsDWB2nR2IGybb9XySojbamHU++MfldH7rIMS3DgWKhowQX2Cm+zf?= =?iso-8859-1?Q?QtC+yTWJZsFMl1Wu//yeylPleGi4Se+6wPCs0WOx/cJu089Hmc9Cg36ow4?= =?iso-8859-1?Q?MMq+7Oxw26HkEWbC+CphsogQJ+t+pjf+07rSSW4uVbFbBn127oVPvp9rE+?= =?iso-8859-1?Q?qTlnmPASf5NCnGZpIg1042K4q5fNKgxVjBOjh9oirF/BaJaLj2bAuIAPms?= =?iso-8859-1?Q?QDaykaVgd4+n0F3iKzyTAbaQ3YUEvG6ngwFYwS4gJWuyw+xpfW7i4qkMDG?= =?iso-8859-1?Q?PsxZW+FdzEqXBiOxDAaXKiqMWR0fa9KKU+G+QBUjkDMcdru90VLYCVRP9J?= =?iso-8859-1?Q?2BDhn1QCihGFhkAmJfBNJukNAO6dFExAFMINeELN1XL8Fp6ViP7FvCWH8T?= =?iso-8859-1?Q?hjhjYG17tJUBqv9CcRwV6w96jQ3x7VuDkC6YOfTvmKw8sVxSUutRqjAnCL?= =?iso-8859-1?Q?qZDdXb3hg72I5+URyUjRrP4pMvz/A25jCWOk8dqVOilAySgnZOBe09tQCL?= =?iso-8859-1?Q?+XyNECi/JtrST9ym/1qFYvlDMah4fKMdoWn5cbfgjEmNXljyePpsoNznWv?= =?iso-8859-1?Q?xwD755lsOVTUmnUmXIa5TDGEIvFJclg8u2fSAvRgn+l+DgkMTS16JV1RkD?= =?iso-8859-1?Q?ZheqhVioYedRfCKiRYUfOTa+Gbw7OvwFkH1ScrwMjdla7bt88O/TBqunVV?= =?iso-8859-1?Q?4ZaoIAiYMShw2sR2M=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR11MB3748.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99691c43-8c16-4709-bddf-08d8b2c2063a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2021 04:09:26.9388 (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: QVw8EmXhTiA1WE7sCb0u5zhiZ0GKjlu3h1rMqG1w+JrwO96EYiw+u4jD7rIb2ht0smXzZp/A1MnDUgSVMArm0g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB2049 Return-Path: benjamin.you@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The PCI_ROOT_BRIDGE data structure defined in MdeModulePkg\Include\Library= \ PciHostBridgeLib.h does not support reporting non-continuous resources man= aged by a root bridge. This is probably proper since it reflects the range of= =20 addresses the root bridge forwards downstream. Could the PCI Host Bridge driver be configured to relax the checking again= st conflicting resources and exclude those overlapping ranges from the root bridge resources reported to GCD? If this relaxation is turned on, other B= IOS components should ensure address map consistency. Thanks, - ben > -----Original Message----- > From: Dong, Guo > Sent: Thursday, January 7, 2021 7:05 AM > 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? >=20 >=20 > This is not related with OS. > For example, SBL add a new HOB (coreboot could put such info in coreboot > table) for the PCI resources, > So in the UEFI payload, it could retrieve and use these info, instead of= running > ScanForRootBridges() in > uefipayloadpkg\library\pcihostbridgelib\PciHostBridgeSupport.c since the= UEFI > payload assumption. >=20 > Thanks, > Guo >=20 > > -----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? > > > > How should these ranges be reported? They need to be treated as reserv= ed > > 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 On Behalf Of Pat= rick > > > > 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 resour= ce > > > > allocation? > > > > > > > > Hi, > > > > In addition to MMCONF there might be hidden PCI devices having act= ive > > > > BARs, like UART in ACPI mode or the PMC/P2SB device. > > > > Those memory regions are marked as reserved in e820 tables and col= lide > > > > with the assumption of a contiguous memory space. > > > > It is contiguous, but that is not visible by the PCI Host bridge d= river. > > > > > > > > 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 ro= ot > > bridges > > > > > as continuous and performs rigorous checking against overlaps wi= th > > existing > > > > > resources such as MMCONF. > > > > > > > > > > I think to support the case where a root bridge reports a non-co= ntinuous > > > > range > > > > > that encompasses the MMCONF, a policy could be defined for the P= CI > > Host > > > > Bridge > > > > > driver to optionally carve out the MMCONF from the root bridge M= MIO > > > > resources > > > > > reported to GCD. (MMCONF is defined by PcdPciExpressBaseAddress = and > > > > > PcdPciExpressBaseSize). A PCD could be defined to enable such be= havior > > > > (with > > > > > default as FALSE to maintain backward compatibility). > > > > > > > > > > Thanks, > > > > > > > > > > - ben > > > > > > > > > > > -----Original Message----- > > > > > > From: 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 re= source > > > > > > 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 re= source > > 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 kn= ow 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 reso= urce > > > > 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 > > > > > > > =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 000000000000000= 0 > > > > > > > 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 th= e > > MMCONF > > > > > > > window, and this is where I'd expect it to be. 9f800000 is t= he base of > > > > > > > the PCIe host bridge aperture, which is also where I'd expec= t 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 a= lso > > some > > > > > > > other windows, but nothing that collides with the MMCONF reg= ion. > > 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= 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > >