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.280.1616520552171665288 for ; Tue, 23 Mar 2021 10:29:12 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=gK0AvmSY; spf=pass (domain: intel.com, ip: 192.55.52.151, mailfrom: guo.dong@intel.com) IronPort-SDR: T4Wt6ZMSu/4nXAMLJhxNRrshms3KUM6eKB6r5uKwB8y2h7++ge0/iZNqknstXp4y3bvIksnLLq BanfY0rNVRvA== X-IronPort-AV: E=McAfee;i="6000,8403,9932"; a="170492439" X-IronPort-AV: E=Sophos;i="5.81,272,1610438400"; d="scan'208,217";a="170492439" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Mar 2021 10:29:10 -0700 IronPort-SDR: mdzzZkcyjXAgsdb8axijAOYhMOX/JJQaEgCgQ6twS0817RJRTG9ibgPP5TlRSZXD0HDvly1UpC TT4qt0/Dz0GQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,272,1610438400"; d="scan'208,217";a="524914366" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by orsmga004.jf.intel.com with ESMTP; 23 Mar 2021 10:29:09 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 23 Mar 2021 10:29:06 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Tue, 23 Mar 2021 10:29:06 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.57) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Tue, 23 Mar 2021 10:29:04 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T25oOA1eXFZZ0bGFLDlCikuznJuzy40rtUMLKX9Xx1woPlsSuCXwxgLKNh3wWNX1yUaK+VsrlZpiUzqrcLOL86P1MZ3RgYOiXcGeHCWZ64fgC2eT/HV6aLaCBh/b5b0wF9VmO/WFkqyTMLvIeGOUXtdCy2+6c/EikcYJHufK6clujI14rnGtMidQczQ0bB7GyKsQZUv5sQV9HVnJAR6i78CL4oLU7dlsLX2Q8KdExRdyESMEsgp6S2je9kkMa1XkhVbSLG7VmrnOWHK39hf3J+JYU7M5NmdfW1iE+M7adFLO83HCjqyTDMykMft9FFMX0OO4YkkugI7iXPWOXmE3Tg== 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=tgK4DmMpZoCvXd2JeI/HcEEaT5mDhw/fiGr05puUujc=; b=E8eSyP3/exOwiF0c7OTejmU7KV52HGp8elr45XylIH+pEdyrvP+SkZMBJdRF0KDWkAeen9fFD6RF3kSGPO4umSq5K5DRow7NBENumyqiUQGCTMLWqB6rejIDI7DcC5lGx6gWs/4gP0pcgU4qxnhqkChr8EgIkBD8h34NvAq/R29ZN+ITO1FP2ESjqDUeD9kvpFSZqLaE2pBetgXFxuKk0ZuOuSvEOO09H/nta/Y7TD3hVRHtmLJwFNDvFul2C9JE5xZnqHI5tL2FfQPXvosGp1/p3+BO9itg0DodTzj3mOd5009p17ur5l3Y0MBWGhB33XNeYLVxXv+tisiCyKaYOA== 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=tgK4DmMpZoCvXd2JeI/HcEEaT5mDhw/fiGr05puUujc=; b=gK0AvmSY3T+IKTxmoqKzuOEg5vADUVTsP+ngp4eOChZrbcAwm1oYgLrY/2pE5V23Y5op6NBcGkT7UIq3WLWs0dszWYPv8JwLJwJr6459dupYpI9ct0/y9TinbuLXz35AdInqN3w4f1F+ymq8vkpM7lh992oHRgbdUSlOmGfxuFk= Received: from BYAPR11MB3622.namprd11.prod.outlook.com (2603:10b6:a03:fe::30) by BYAPR11MB3558.namprd11.prod.outlook.com (2603:10b6:a03:b3::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Tue, 23 Mar 2021 17:29:03 +0000 Received: from BYAPR11MB3622.namprd11.prod.outlook.com ([fe80::9d0a:3b97:a353:663d]) by BYAPR11MB3622.namprd11.prod.outlook.com ([fe80::9d0a:3b97:a353:663d%3]) with mapi id 15.20.3933.034; Tue, 23 Mar 2021 17:29:03 +0000 From: "Guo Dong" To: Andrew Fish , edk2-devel-groups-io CC: "lersek@redhat.com" , "Liu, Zhiguang" , "Ni, Ray" , "Wang, Jian J" , "Wu, Hao A" , "Bi, Dandan" , Liming Gao Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob Thread-Topic: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob Thread-Index: AQHXH/Csz45HJ4QJdUOIor4me/Ez1qqRpRSQgAAZtQCAAAlNkA== Date: Tue, 23 Mar 2021 17:29:02 +0000 Message-ID: References: <20210323032438.950-1-zhiguang.liu@intel.com> <20210323032438.950-3-zhiguang.liu@intel.com> <41831DD2-0EBC-4B29-B6A0-BE56F322F478@apple.com> In-Reply-To: <41831DD2-0EBC-4B29-B6A0-BE56F322F478@apple.com> 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: apple.com; dkim=none (message not signed) header.d=none;apple.com; 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: 8f44d0f6-e039-4f7b-66a9-08d8ee21271b x-ms-traffictypediagnostic: BYAPR11MB3558: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: InqOgACZAx7n/ir/iWhI4RHigmpnSkQcVWipTdvbZtcycpeRge+lcQFq8x5Y4hA1jzmi7jDburAaTumAV+BGPbLqiLaKKOd7KtinU4UqgeZ0UtsgPjnp90uxsOw69eWrUQi7vLH6WEqmgu/s2rXDzkiClwqeJEmPW7gp/cWMvRi5cnmkxKo+sA0BgQHih3VNpG4kphDlxPu9JUX+AKHks5piwTekl9wf9XFFXgRrGTwJLfSQTv6MVgkFTMecHMyvy7w993qJXZUkAd8Jyj3mkGyNr2HFaKCKG5r96S/m9QTybTl/ZTNc8ntHccanmjAub/sE1klRwpzqZzAodcimoqVzZa6OLDdBSVpg/4LnBG7//Jec/pXda3alSc1mDrNt21JvBqO13Vv5C6nkszvMYrrTkmIp3gnaKw4ZtgLyn/3THbh49isLA+N8aK0RbZvfbn6nAgUqwmPOFkQ1ttXa7YFtLdFAfK9X2KAxYkvSo3Isasbtrz//wqwUKqy1UDr0wZADC11y/jGfcv1BIx0YZQqyX6vIXCWZB27B9maBd3U3UNrdvQTfooSQjy/m5oRN6aJu+a9QkArHaByylUYpFORZA85OHwVSGJ14dIUX3eIyT4cjeEJ6mlFDVrG5mQos5sG07F+kJMpSzXW5syqsd7uKGzsOeNA9vqaf7VNoClRVEXRHNjNQhE7B5SgNh4f4aVxglnzjUMjaBmpPnzDC+ZeZ758RK71whxqyVWvPwOk= 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:(396003)(376002)(366004)(39860400002)(136003)(346002)(26005)(478600001)(966005)(66556008)(66946007)(110136005)(45080400002)(66446008)(64756008)(54906003)(76116006)(316002)(83380400001)(66476007)(21615005)(86362001)(186003)(71200400001)(166002)(33656002)(4326008)(8936002)(9686003)(2906002)(55016002)(7696005)(5660300002)(52536014)(38100700001)(6506007)(53546011)(8676002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?BlgbZyf6+IQX2M9OvjTpd/bhMF7TwSi/do+ixZknUyI01DRvSc3vZLhSxYrh?= =?us-ascii?Q?kBJ6Q2nQ7zP8qYo+OAwvcMTXUkEux7l9gcMD96CRSZ+Ps7daDAReIJ9097Th?= =?us-ascii?Q?Mq4FfNiFwyIb3akRJjzm437aohCqx6IZKNEOcjJGQtwwqhv6vTVOwPQ1NpUU?= =?us-ascii?Q?QWq42KRfz4vMQnAgFvc8WmEvtQma1DO2p8QCg/5spOPnEXsHK5qIkS4fVabc?= =?us-ascii?Q?BbdRg8vVi3uCd7iBnOF7sW9c2lD+ezFeTfuSPl/WELrlWffOLraXC6i47owg?= =?us-ascii?Q?hKRNm6HCfeasjazHlccNQQfstY002Dbtc96dQk3PnBvYrjSh/AtzlxYrcGq8?= =?us-ascii?Q?+nZkjRbYby/xlQ6Lobi09Rcj5IdXT+Km7sIwRHI6IKgM2H59mqOZypWWi57g?= =?us-ascii?Q?v6gh1nJatv0w6GNO88TeokM58tjkZ60xFsKigPqSDPNuYzPNV88x/QlAlWZh?= =?us-ascii?Q?7N3LcLeRQFurKWbIe6GoJj4va5BLZ3Uk9NblO6mLEGiZC926gtT2UUbjhCfX?= =?us-ascii?Q?B3qtoRYXwVbCR9sjDyId3oSjjx3Tzni/COMGS7jMLBg7y9uOM2K63eiItmhn?= =?us-ascii?Q?9D9fR0aJ9pYl4Kh/wgRrCU7C8z5g/qBYvc5xlN3cTE0Kux8sIn3QzkHDFNFM?= =?us-ascii?Q?WXSQF6iS0lQGQsRsSbdPP6RgwBauPlF3mnY9IPu+lee3JdoxHReCBqr1x0ot?= =?us-ascii?Q?7AXc+qBklIzzS0zyvmkWARcA/XiFlcZh9IMxld06XE5RfRmVf4tJQo2CfR/a?= =?us-ascii?Q?0iu3M+Ae7zJn34ztcnivTF16VKKF3IJxG5fY8ag2e/HISBewvavjvwHIh2TF?= =?us-ascii?Q?aIMJL6vVvHiW4+SAroaQdzUyNFRh7pNUTHHkH+tsBTEsa+XN4ARw73YgXe0z?= =?us-ascii?Q?DcuDI8mWZFqC28wKhi+9QxvJw/Bn18Opf+NiNQ5PVnjL2NfOkzheHPe6dl06?= =?us-ascii?Q?K26HR8Sme4mA+CFq2nFSJgMTESmoMzqsB/XUQpYfbTprmeY9jgK+SK5bTqoC?= =?us-ascii?Q?dOmTTNIKdm274VG9gad8YytlXtwUbygHJU1rBDug3wMOfc6C8PIlIF0M6dAL?= =?us-ascii?Q?K7GMxJaanqM6bldDl/wUWPU/6Z3FPITCdYAeEbnMmVmJJVHBZs0O/viE0uBE?= =?us-ascii?Q?uTCtX7NBOfO1h4QKZdqjGfqEBgvMAntkfXe1C5IAPR/B0tflA6Lzzak82Er+?= =?us-ascii?Q?6jch6blZFS0U+PVNL5pPC2XbhybDA1hM4Yc2DZ6L5ODh6auJ++v/ekvdAP90?= =?us-ascii?Q?BRkjwB8h5GKQzW8JVKSJzJLCu/p4sHPUBYaeqz6caQz+c/h4ox3tAW+9n3Kb?= =?us-ascii?Q?WRk=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: 8f44d0f6-e039-4f7b-66a9-08d8ee21271b X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2021 17:29:02.8494 (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: hbYLbsEFlheu81eWyVuZ1Z4Hw+JNDqo3CfcQ7WL+gai702zafsF5jcR2Q/6am4Bz6wbMLAM+AVxgRiZ3xwiAtA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3558 Return-Path: guo.dong@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BYAPR11MB36228ADDF9BA93B7ED9F5EFF9E649BYAPR11MB3622namp_" --_000_BYAPR11MB36228ADDF9BA93B7ED9F5EFF9E649BYAPR11MB3622namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The universal payload specification proposes to re-use the existing GUID from UEFI f= or the HOB. I don't know if we have to update the UEFI spec firstly in order to reuse = the GUID. Any idea? Thanks, Guo From: Andrew Fish Sent: Tuesday, March 23, 2021 9:13 AM To: edk2-devel-groups-io ; Dong, Guo Cc: lersek@redhat.com; Liu, Zhiguang ; Ni, Ray ; Wang, Jian J ; Wu, Hao A ; Bi, Dandan ; Liming Gao Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install A= cpi table from Hob My concern is gEfiAcpiTableGuid is owned by the UEFI Spec and any off labe= l usage should probably be defined by the PI Spec. Is this a code 1st proposal or just an implementation? Thanks, Andrew Fish On Mar 23, 2021, at 8:45 AM, Guo Dong > wrote: Add my comments on the ideas behind. UefiPayloadPkg is not a platform specific package, it tries to provide a g= eneric payload using platform independent Modules. This allows to reuse the= payload for different boot firmware solutions (Slim Bootloader, Coreboot, = EDK2 bootloader) on different platforms. Just like other DXE modules (e.g. variable DXE driver, firmware performan= ce DXE driver), standardizing and modularizing platform independent modules= through a HOB as the AcpiTableDxe patch did to support potential data from= PEI/bootloader is a nature way for EDKII modules reuse. Understood the con= cerns to keep AcpiTableDxe as simple as possible. I think it deserve for co= de reuse by adding PEI/bootloader HOB support. Thanks, Guo -----Original Message----- From: devel@edk2.groups.io > On Behalf Of Laszlo Ersek Sent: Tuesday, March 23, 2021 5:40 AM To: Liu, Zhiguang >;= Ni, Ray >; Dong, Guo > Cc: devel@edk2.groups.io; Wang, Jian J >; Wu, Hao A >; Bi, Dandan >; Liming Gao > Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install A= cpi table from Hob On 03/23/21 04:24, Zhiguang Liu wrote: If HOB contains APCI table information, entry point of AcpiTableDxe.inf should parse the APCI table from HOB, and install these tables. We assume the whole ACPI table (starting with EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER) is contained by a single gEfiAcpiTableGuid HOB. This way, for UefiPayloadPkg, there is no need to specially hanle acpi tab= le. Zhiguang Liu (2): MdeModulePkg/ACPI: Install ACPI table from HOB. UefiPayloadPkg: Remove code that installs APCI MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf | 3 ++- MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 134 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---- ---- UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 13 ++-----= ------ UefiPayloadPkg/BlSupportDxe/BlSupportDxe.h | 5 +---- UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf | 5 ++--- 5 files changed, 133 insertions(+), 27 deletions(-) Where does this idea come from? (1) There is no bugzilla for this, apparently (not linked in the commit messages anyway). (2) Also, I'm not sure if reusing an existing (and standardized) GUID for this purpose is a good idea. I think an edk2-only (MdeModulePkg-defined), brand new GUID, for the HOB, would be better. (3) I'm also not convinced at all that this *whole approach* is sound. The fact that UefiPayloadPkg has the ACPI content available to it in a particular data representation (as a HOB, for example) is just a platform trait. Why should that platform trait leak into the central implementation of the ACPI table protocol? UefiPayloadPkg can call the ACPI table protocol interfaces to install its tables. OVMF does the same -- OVMF also does not construct its own ACPI tables, but downloads them in a quirky representation from QEMU. We didn't hack the central AcpiTableDxe driver for that use case; instead, we dissected the blob (in OvmfPkg) into individual tables, and called the proper ACPI table protocol method (InstallAcpiTable()) with the individual tables. I disagree with the code complexity / platform quirk in AcpiTableDxe. At the bare minimum, this feature should be possible to compile out altogether. I don't necessarily mean a FeaturePCD; there could be a new INF file too, that shares most of the functionality with the current core driver, but also includes (from a different source file) the new logi= c. But I'd really like if this mess were kept out of MdeModulePkg altogether. It's the job of the platform ACPI driver to use the ACPI table protocol. Of course if you can show that this HOB usage is standard / publicly specified, that's different. Please do not merge this series. Laszlo --_000_BYAPR11MB36228ADDF9BA93B7ED9F5EFF9E649BYAPR11MB3622namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 =

The universal payload specification proposes t= o re-use the existing GUID from UEFI for the HOB.

I don’= ;t know if we have to update the UEFI spec firstly in order to reuse the GU= ID.

Any idea?

 =

Thanks,

Guo

 =

From: Andrew Fish <afish@apple.com> Sent: Tuesday, March 23, 2021 9:13 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Dong, Guo &l= t;guo.dong@intel.com>
Cc: lersek@redhat.com; Liu, Zhiguang <zhiguang.liu@intel.com>= ; Ni, Ray <ray.ni@intel.com>; Wang, Jian J <jian.j.wang@intel.com&= gt;; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.c= om>; Liming Gao <gaoliming@byosoft.com.cn>
Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver in= stall Acpi table from Hob

 

My concern is gEfiAcpiTableGuid is owned by th= e UEFI Spec and any off label usage should probably be defined by the PI Sp= ec. 

 

Is this a code 1st proposal or just an implementati= on? 

 

Thanks,

 

Andrew Fish



On Mar 23, 2021, at 8:45 AM, Guo Dong <guo.dong@intel.com> wrote:

 


Add my comments on the ideas behind.
UefiPayloadPkg is not a platform specific package, it tries to provide a g= eneric payload using platform independent Modules. This allows to reuse the= payload for different boot firmware solutions (Slim Bootloader, Coreboot, = EDK2 bootloader) on different platforms.

Just like other DXE modules (e.g. variable DXE driver,  firmware perf= ormance DXE driver), standardizing and modularizing platform independent mo= dules through a HOB as the AcpiTableDxe patch did to support potential data= from PEI/bootloader is a nature way for EDKII modules reuse. Understood the concerns to keep AcpiTableDxe as simp= le as possible. I think it deserve for code reuse by adding PEI/bootloader = HOB support.

Thanks,
Guo


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Tuesday, March 23, 2021 5:40 AM
To: Liu, Zhiguang <z= higuang.liu@intel.com>; Ni, Ray <ray.ni@intel.com>; Dong,
Guo <guo.dong@intel.com<= /span>>
Cc: devel@edk2.groups.io; Wang, Jian J <jian.j.wang@= intel.com>; Wu, Hao A
<hao.a.wu@intel.com>; Bi, Dandan <= dandan.bi@intel.com>; Liming Gao
<gaoliming@byosoft= .com.cn>
Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install A= cpi
table from Hob

On 03/23/21 04:24, Zhiguang Liu wrote:

If HOB contains APCI table information, entry poi= nt of AcpiTableDxe.inf
should parse the APCI table from HOB, and install these tables.
We assume the whole ACPI table (starting with

EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)

is contained by a single gEfiAcpiTableGuid HOB. This way, for UefiPayloadPkg, there is no need to specially hanle acpi tab= le.

Zhiguang Liu (2):
 MdeModulePkg/ACPI: Install ACPI table from HOB.
 UefiPayloadPkg: Remove code that installs APCI

MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf   &nbs= p;|   3 ++-
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 134

+++++++++++++++++++++++++++++++++++++++++++++++++= +++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
----

UefiPayloadPkg/BlS= upportDxe/BlSupportDxe.c         &n= bsp;         |  13 ++----= -------
UefiPayloadPkg/BlSupportDxe/BlSupportDxe.h      &= nbsp;           &nbs= p;|   5 +----
UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf      = ;           |  =  5 ++---
5 files changed, 133 insertions(+), 27 deletions(-)


Where does this idea come from?

(1) There is no bugzilla for this, apparently (not linked in the commit messages anyway).

(2) Also, I'm not sure if reusing an existing (and standardized) GUID
for this purpose is a good idea. I think an edk2-only
(MdeModulePkg-defined), brand new GUID, for the HOB, would be better.

(3) I'm also not convinced at all that this *whole approach* is sound.

The fact that UefiPayloadPkg has the ACPI content available to it in a
particular data representation (as a HOB, for example) is just a
platform trait. Why should that platform trait leak into the central
implementation of the ACPI table protocol?

UefiPayloadPkg can call the ACPI table protocol interfaces to install
its tables. OVMF does the same -- OVMF also does not construct its own
ACPI tables, but downloads them in a quirky representation from QEMU. We didn't hack the central AcpiTableDxe driver for that use case; instead, we dissected the blob (in OvmfPkg) into individual tables, and called
the proper ACPI table protocol method (InstallAcpiTable()) with the
individual tables.

I disagree with the code complexity / platform quirk in AcpiTableDxe. At the bare minimum, this feature should be possible to compile out
altogether. I don't necessarily mean a FeaturePCD; there could be a new INF file too, that shares most of the functionality with the current
core driver, but also includes (from a different source file) the new logi= c.

But I'd really like if this mess were kept out of MdeModulePkg
altogether. It's the job of the platform ACPI driver to use the ACPI
table protocol.

Of course if you can show that this HOB usage is standard / publicly
specified, that's different.

Please do not merge this series.

Laszlo







 

--_000_BYAPR11MB36228ADDF9BA93B7ED9F5EFF9E649BYAPR11MB3622namp_--