From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mx.groups.io with SMTP id smtpd.web10.3703.1637229586874429141 for ; Thu, 18 Nov 2021 01:59:47 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=oyEKOQDO; spf=pass (domain: intel.com, ip: 192.55.52.115, mailfrom: jiewen.yao@intel.com) X-IronPort-AV: E=McAfee;i="6200,9189,10171"; a="234390861" X-IronPort-AV: E=Sophos;i="5.87,244,1631602800"; d="scan'208";a="234390861" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2021 01:59:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,244,1631602800"; d="scan'208";a="550109596" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by fmsmga008.fm.intel.com with ESMTP; 18 Nov 2021 01:59:45 -0800 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) 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.2242.12; Thu, 18 Nov 2021 01:59:45 -0800 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Thu, 18 Nov 2021 01:59:45 -0800 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) 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.2242.12 via Frontend Transport; Thu, 18 Nov 2021 01:59:45 -0800 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.174) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Thu, 18 Nov 2021 01:59:44 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ikBGQKqU/rn0+14EO6azkhrEkieGi60xyqMholC2puIZDqDIn0LHmVphPCxAkMiGJEp0QUm74m14Wq01Zn62J0CMHT20IVmM/8wTQRb1s9s9n5OVTGYIeZFN+frCnblhV8FP54iP5NAFXQ77bO0yJlIENCY4T0/hZdorc7PnCkEqz5XlHeG8nsVB/D6ln36qQ0YgrwecF4kTmTcvj26TFD92HyiDPAYuj+T49tcaPb8Y4UEBUXLxXRvfeKEo2b6Lb/fhlGFqRVUnW9/E/y20+1IytDUv2PQBwvgRiu6o1n0M+jZZbF+ek8LzPmR5R5J+XWU40YzHshEd3g6kROHKmQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DlsjXqt8EOGH05nZ7pio2R9xWufVYCDWtzEiiW5r1qQ=; b=j2I/8FcpUKFy/f6iyUj5wQRu9+3EXSgaG6VmuZBKN+dFrCqyE/mhxHUrQI6abTlDqAQwioOPaAhU1WS6QZy+xGM/T7481ubgWiwFzIgM/md6BOZtux0pahS3T64AoFyFkp7eVWWgxoo2N8u5RwRartbIEH006Ejl2vbDLgrSvZc0YTdlBKYb54G1DzH8aLHsrOqa/rlsZJ+8pO0Xk1VUJWlo4AV3tkTAqZDZz0YiJ9yTKXnyNgRtPj4UOlwJwuc/7cOE8ZDvNoJEeZA/SJTB1H0C4yp+rsSxPe8bFZujf1IO+jVpd5VBlpnMVl51NtJRFDQwqIDvqvjzTPgMrz2tfw== 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=DlsjXqt8EOGH05nZ7pio2R9xWufVYCDWtzEiiW5r1qQ=; b=oyEKOQDOQSNpm3wXsT6h9h/FZubTFvSCiyhHuh+DcC1y+QqnGkpm8iEJtSeQcKd//O/j+9LxAz1T3b2DIUsTBnMWyO3ikbQ1+x1YVoVy/y8VA1hu774QT07ML7H7yAqp3vbQThtq/l006q174Sy0+w5WQWVToiDxZ/qX67rotIk= Received: from MW4PR11MB5872.namprd11.prod.outlook.com (2603:10b6:303:169::14) by MWHPR11MB1613.namprd11.prod.outlook.com (2603:10b6:301:e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.27; Thu, 18 Nov 2021 09:59:42 +0000 Received: from MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::1d07:d296:b2c7:7114]) by MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::1d07:d296:b2c7:7114%8]) with mapi id 15.20.4669.016; Thu, 18 Nov 2021 09:59:42 +0000 From: "Yao, Jiewen" To: Gerd Hoffmann , "Xu, Min M" CC: "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , Tom Lendacky Subject: Re: [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx Thread-Topic: [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx Thread-Index: AQHX2uMZH+dNhguCw0OBghbxJplRDawH11AAgAEwN+A= Date: Thu, 18 Nov 2021 09:59:41 +0000 Message-ID: References: <867e8a2aaf28c308b20a659057217453c6e38e00.1635769996.git.min.m.xu@intel.com> <20211103063045.kmttoxyluifwo2bq@sirius.home.kraxel.org> <20211117151942.iqow75zq2lrn5xlc@sirius.home.kraxel.org> In-Reply-To: <20211117151942.iqow75zq2lrn5xlc@sirius.home.kraxel.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.6.200.16 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e42a98a-7a8a-4f05-e14d-08d9aa7a243a x-ms-traffictypediagnostic: MWHPR11MB1613: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ibw4dPWNC/gTLuSZJYJyct8UY1quICdeRAYAjcg89rytd771q2kD5wCStdSHoagWwi3cCEngISunPZrUdPwvgn0vg5biLrI69cjzFPICD95kxJXRCJDaoHUXc0bmbn2XcqJ8vEyVVAvMjFuAmXy5fB7jRXmHttP1xm8U55fBa5/t+Dl/jEWYcymKM2Gqan4fPWy0d0ZVTnrcwoxOsmCfdCNqL8AlnxTJBCkfU5XNM8ku6eonMUGuIO83r0y+LhJhmfjkgECNdMDPbMCI7qDP4nZz3A8YiGbt+8fPCXPaDg4smZAIh1cdtkjO0ZRM55GzFXRHnWPLshuRx3Z9rp3LSIwNFPO6AHSEGxtSuBPZTQirDFm6ugI2Goib45EctjVbUzH+Ejvr4TZMbcr/dFD6wspWIpVt6wmAetWKiZjtR623qKjBsLlsF5JCVEKv+Rwhna4Fuh9PWTRwfG1l7TGGmW2wYEqqWzhduKCaevr1g6XJMI3I4bXRGunOJzci5HOTlbOR4AuwiMEw2fOXhPSGaRZGmABa53lW3sC3fl3qnBfa7mPlCvP+JJQfNaKUoKFe0o+OVahUqftLOBzJ/CX96Y3Vqx911YeIAp2KQVoIDYwVzcFNeYRSOc+vClYvV6uDGRCMNRqY79inlrf+wKGKHlwno8Anf4rAaT2pJbbVgsH1TY549fdlST1e5kwAhll0CwyMTMUIbYAiCFsd4vtjLkRrNtNG4RpNZPchgSBqiwoqEAki30k4JRKDEKgPtlyVlSzbInSXXnOZK8v1na4N5mjlR4JihPPcbNiBNs7qQsbsS4aJLrRhdxQzORdXj057LGzdov4wackwda25341uMg== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR11MB5872.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(366004)(122000001)(5660300002)(38100700002)(15650500001)(33656002)(26005)(508600001)(316002)(53546011)(52536014)(6636002)(6506007)(7696005)(186003)(54906003)(966005)(110136005)(4326008)(2906002)(71200400001)(8676002)(38070700005)(66946007)(66446008)(64756008)(66476007)(66556008)(9686003)(83380400001)(76116006)(86362001)(82960400001)(8936002)(55016002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?r7L5dSV2crp5IOSloLUa6daJW8gKouDB4lYkvuifSFrJqve3jxlrM/gNTdN+?= =?us-ascii?Q?CFcjRohoLi8L4BjGo8l5RddiNjkX/49+C25p9hGyaVqwatFMqTQyPOs2+7Xe?= =?us-ascii?Q?jNyIxCGBOwp1TG4rVVoCueRC63d7JdZFAYY0Dkw1uVo/6t9SSDQNxUjPFIvl?= =?us-ascii?Q?wDUr2IyO9iZfcVVWMOp+imJWutQ4UC9gqbSRpnJMomnyklzzUIxYVyeB9NWB?= =?us-ascii?Q?SPn0qkYZPAiFSTd+DRFMp55kn2MVRqOrQiX3cmY3j7aSppWS1BDF6uwC+ado?= =?us-ascii?Q?jNzzVIGmOQbVoQ17IIRYbFY8PHf1+5mn8Ow/iYZpKOvgjhlsi8qy0ozvIEJ9?= =?us-ascii?Q?6MmFZUHGMZKKG9qfsGsd1Fn1oXmFZk9q2MjK1UKkt5Ljx9p5XabnkHyzzQ1P?= =?us-ascii?Q?ls92Xq7BOelykFLGdJWpzuNsoFjvKDo/LQtNEhqqnqrFCrmLYYAOrNnEKBl2?= =?us-ascii?Q?ZU6S0EYg52iGFhCF1kB0QC5O9+lf6t1SUwAK4s6C2qMLK2xc5eVnBEqkTE+g?= =?us-ascii?Q?LYm2vTR3RgYQScs01hGnRp+nhzkWB8DZuzfLPV/2gvur+uYupUfAoCF54E7p?= =?us-ascii?Q?OEdB4bOl+2WRAPPnfUAw0ZrrPKAVhtbNmSlm7o+3a3Z0hCRRzCaLt0BwjZ4B?= =?us-ascii?Q?rgghJdVENutuReH3FTqmjrohEDfTDgJ5K+RyVDtoH2o0ZBQfOMs/+9VMyFDx?= =?us-ascii?Q?4ywAvP+mMDW6NED5EuwFMMhlgGjmU/BrtXGm2MRW2Jkol60ykDqWN0Z6570l?= =?us-ascii?Q?VE1a/M6TcoEcUzVjsH1k0xaCvJoDcJXxM96iaU1fJg3AVNhwvzNfUYkw+B1x?= =?us-ascii?Q?6lCr0+SpAAqmzDG21cKaZRWlrDNR4y/32aAVSjPVN+7INr3UDS4QkFDW+l0a?= =?us-ascii?Q?INysTEdTjBSMsKJmS/OJ50KlGy2f493OQ8hLiOzePljfcW9BjD5Gap+hRgvK?= =?us-ascii?Q?rEqx8SthJIjqpM8BHtjjvTOeXjMqW2rB/zKIvmz7jxhgNPHD3OJXzw8SX4cP?= =?us-ascii?Q?idsvXq/4YsT0EDlEDfUODdArbvXYsWsErh+zEravGXeCnCzhVPnyYfqPXPd9?= =?us-ascii?Q?FOnlb3qC6RVxgh3U6PQPjzpuvj8u6HCOgzpwzG8fwqiFsaLB8xiOE7ZfjoYh?= =?us-ascii?Q?PcqlsNLS6mSJ1zcLe8EuGF3PgVWVE1v6OX+EmyrWaCrPtFOnngk83hXQJZ2s?= =?us-ascii?Q?IL0/7j5IYo+PwJTQHVo1wNEyflb+9ZoHo5/PGOLLX9ombs9rPv+5NHjpobFf?= =?us-ascii?Q?cVG+Axxc1tTPWSQOtJSkTRelIxP9YlPmwxB4yfOewmj+xLZTx5WYnNav1iiu?= =?us-ascii?Q?hi1eJjzjJzM2EnaMhdKzOkI9yiOfu0DMTLtEH3NsOOUMVfKpyC7NbD2g3zxM?= =?us-ascii?Q?Ud6VaHsRjx9/EV4TelOqVscYa6Rtj15qd8qPZBqeDaLj7Gx9MzRPzcyNIrZl?= =?us-ascii?Q?7y2Bp9jCwwyu0wavFyuQbgQUeV3IvppU87cGAooD6p0QW7vr592uiU8SmPYB?= =?us-ascii?Q?SC7V3GsynMJin9QokjzZpi62Ww+VFoNmVcWie4OmyFIiLYDiSaFwXXi+0oDy?= =?us-ascii?Q?uASokf+1QIJju2gk/8ruckPY4Zbb7u+Z5uC+I3kxPJpsa9PihEwYKZTNlz6r?= =?us-ascii?Q?Rrxalf9txdmgZAXeOuSvxtc=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR11MB5872.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9e42a98a-7a8a-4f05-e14d-08d9aa7a243a X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2021 09:59:41.8563 (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: w57xOi6gd7i9641hNWIcuux6XeQ2bsLv1gLUBpU3cOm58hkTwKIg4AkJ8GOLIPoYgPH90KxFqvNhCy1KzrGL8g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1613 Return-Path: jiewen.yao@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comment on config-B. > -----Original Message----- > From: Gerd Hoffmann > Sent: Wednesday, November 17, 2021 11:20 PM > To: Xu, Min M > Cc: devel@edk2.groups.io; Ard Biesheuvel ; Jus= ten, > Jordan L ; Brijesh Singh ; > Erdem Aktas ; James Bottomley > ; Yao, Jiewen ; Tom Lendacky > > Subject: Re: [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Td= x >=20 > On Tue, Nov 16, 2021 at 12:11:33PM +0000, Xu, Min M wrote: > > On November 3, 2021 2:31 PM, Gerd Hoffmann wrote: > > > Hi, > > > > > > > - AcceptPages: > > > > To mitigate the performance impact of accepting pages in SEC pha= se on > > > > BSP, BSP will parse memory resources and assign each AP the task= of > > > > accepting a subset of pages. This command may be called several = times > > > > until all memory resources are processed. In accepting pages, Pa= geLevel > > > > may fall back to smaller one if SIZE_MISMATCH error is returned. > > > > > > Why add an assembler version of this? There already is a C version (= in TdxLib, > > > patch #2). When adding lazy accept at some point in the future we wi= ll stop > > > accepting all pages in the SEC phase anyway. There is Mp support (pa= tch #14) > > > so you can distribute the load to all CPUs in PEI / DXE phase if you = want > > > (although the benefits of parallel accept will be much smaller once l= azy > > > accept is there). > > There are below considerations about accept pages in SEC phase. > > > > 1. There is a minimal memory requirement in DxeCore [1]. In legacy > > Ovmf the memory is initialized in PEI phase. >=20 > Yes. >=20 > > But TDVF has 2 configurations (Config-A and Config-B) [2]. PEI phase > > is skipped in Config-B. So we have to accept memories in SEC phase. >=20 > I'm sure I've asked this before: Why skip the PEI phase? So far > I have not seen any convincing argument for it. [Jiewen] First, keeping or skipping PEI phase is a platform decision, not an archite= cture decision. Skipping PEI phase is valid architecture design. In EDKII, most platforms choose to include PEI. And we also have multiple platforms skipping PEI phase. For example: https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/JunoPk= g/ArmJuno.fdf https://github.com/tianocore/edk2-platforms/blob/master/Platform/BeagleBoar= d/BeagleBoardPkg/BeagleBoardPkg.fdf https://github.com/tianocore/edk2-platforms/blob/master/Platform/Hisilicon/= HiKey/HiKey.fdf https://github.com/tianocore/edk2-platforms/blob/master/Platform/Hisilicon/= HiKey960/HiKey960.fdf https://github.com/tianocore/edk2-platforms/blob/master/Platform/RaspberryP= i/RPi3/RPi3.fdf https://github.com/tianocore/edk2-platforms/blob/master/Platform/RaspberryP= i/RPi4/RPi4.fdf Second, the confidential computing changes the threat model completely. One of our goal is to simplify the design for CC-firmware (TDVF) - remove u= nnecessary modules, remove unnecessary interface, make the image smaller an= d faster. That will reduce the validation effort, too. That is the main motivation. Third, I have explained this clearly in the original email and review meeti= ng. Because it is a big change, the original maintainer (Laszlo) recommend we u= se two configuration. Config-A is to keep current architecture, to maximum compatible with OVMF. = And we don't remove VMM out of TCB. Config-B is to have a new TDVF design, to maximum satisfy the security requ= irement. And we remove VMM out of TCB. We agreed, and we are proceeding. > Jiewen argued this is a simplification. Which is not completely wrong, > but it's also only half the truth. Switching all OVMF builds over to > PEI-less boot doesn't work because some features supported by OVMF > depend on PEI Modules. Therefore TDX Config-B skipping the PEI phase > means we would have to maintain two boot work flows (with and without > PEI phase) for OVMF. Which in turn would imply more work for > maintenance, testing and so on. [Jiewen] I am not asking your to OVMF build to PEI-less. But if you want to do, I will not object. As EDKII maintainer, I don't see a burden to maintain multiple boot work fl= ow. We are already doing that on other project. As least for me, I don't see an= y problem. If you think it is a burden, you may work partial of the feature. EDKII is a big project. Nobody knows everything, including me. I will also = rely on other people to handle some features I am not familiar with. I don't see any problem. On contrast, if we keep PEI for config B, it adds extra burden from securit= y assurance perspective. That means, every issue in PEI may be exposed to TDVF. Comparing the effort to maintain the work flow and the effort to handle pot= ential security issue, I would choose to maintain the work flow. I have experience to wait for 1 year embargo to fix EDKII security issue, i= t is very painful and brings huge burden. > Also note that accepting all memory in SEC phase would be temporary > only. Once we have support for lazy accept in OVMF we will accept most > memory in DXE phase (or leave it to the linux kernel), whereas SEC/PEI > will accept only a small fraction of the memory. Just enough to allow > DXE phase initialize memory management & lazy accept support. >=20 > > This is to make the code consistent in Config-A and Config-B. >=20 > I want TDVF be consistent with the rest of OVMF. Makes long-term > maintenance easier. Building a single binary for both SEV and TDX with > full confidential computing support (including config-b features) will > be easier too. [Jiewen] I am not convinced that TDVF be consist with rest of OVMF. The goal of project is different. The choice can be different. I don't see a reason that one platform must be in this way, just because ot= her platform does in this way. Easy and difficult are very subjective term. I think a PEI-less TDVF is much easier to maintain, comparing with complica= ted OVMF flow, at least from security perspective. The less code we have, the less issue we have. > > 2. TDVF's MP support is via Mailbox [3] . BSP wakes up APs by putting > > command/parameters in Mailbox. So we have this patch [4]. While > > EDK2's MP support (CpuMpPei/CpuDxe) is via INIT-SIPI-SIPI. They're > > different. We cannot distribute the load to all CPUs with EDK2's MP > > service. >=20 > > Patch #14 [5] is the commit to enable TDX in MpInitLib. Actually this > > is to make sure the CpuMpPei/CpuDxe will not break in Td guest in > > run-time. Patch #14 is rather simple, for example, ApWorker is not > > supported. >=20 > Well, MpInitLib seems to have full support (including ApWorker) for SEV. > I'd expect you can add TDX support too, and schedule the jobs you want > run on the APs via TDX mailbox instead of using IPIs. >=20 > And I think to support parallel lazy accept in the DXE phase (for lazy > accept) you will need proper MpInitLib support anyway. >=20 > > 3. In current TDVF implementation, Stack is not set for APs. So C > > functions cannot be called for APs. If stack is set for APs, then more > > memories should be reserved in MEMFD. For example, if 1 AP needs 4k > > size stack, then 15 AP need 60k memory. (We assume only 1+15 CPUs > > accept memory). This makes things complicated. >=20 > I think skipping PEI phase and moving stuff to SEC phase makes things > complicated. Reserving stacks in MEMFD would only be needed because you > can't allocate memory in the SEC phase. When you initialize the APs in > PEI instead you can just allocate memory and the MEMFD dependency goes > away. >=20 > > Based on above considerations, we use the current design that BSP-APs > > accept memory in SEC phase (in assembly code). >=20 > I think the design doesn't make much sense for the reasons outlined > above. >=20 > I'd suggest to put aside parallel accept for now and just let the BSP > accept the memory for initial TDX support. Focus on adding lazy accept > support next. Finally re-evaluate parallel accept support, *after* > merging lazy accept. >=20 > With a major change in the memory acceptance workflow being planned it > doesn't look like a good idea to me to tune memory accept performance > *now*. >=20 > My naive expectation would be that parallel accept in SEC/PEI simply > isn't worth the effort due to the small amount of memory being needed. > Parallel accept in DXE probably is useful, but how much it speeds up > boot depends on how much accepted memory we must hand over to the linux > kernel so it has enough room to successfully initialize memory > management & lazy accept. >=20 > take care, > Gerd