From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mx.groups.io with SMTP id smtpd.web11.13933.1630309772291901452 for ; Mon, 30 Aug 2021 00:49:32 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=cWNyxYJA; spf=pass (domain: intel.com, ip: 192.55.52.136, mailfrom: jiaqi.gao@intel.com) X-IronPort-AV: E=McAfee;i="6200,9189,10091"; a="197791511" X-IronPort-AV: E=Sophos;i="5.84,362,1620716400"; d="scan'208,217";a="197791511" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Aug 2021 00:49:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,362,1620716400"; d="scan'208,217";a="644902882" Received: from orsmsx604.amr.corp.intel.com ([10.22.229.17]) by orsmga005.jf.intel.com with ESMTP; 30 Aug 2021 00:49:30 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 30 Aug 2021 00:49:30 -0700 Received: from orsmsx604.amr.corp.intel.com (10.22.229.17) by ORSMSX610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 30 Aug 2021 00:49:30 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Mon, 30 Aug 2021 00:49:30 -0700 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (104.47.51.48) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Mon, 30 Aug 2021 00:49:29 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ad+PfKMPU0WyigA1Nb7UKfy6EUqY6MvZt+v3LgnH6GTpJ0vZwLnZ9v7X5u/3DG/bSZWsnz7xcTIOePLvdLdoAZiDQ9eJ5xK6P+OgykrRyt5QsTmT5HGVj3moGtDH90VioCiRFAE0vkefgS07uOggOtDcaw/Nd0asdTata5vcRATuLQGDUM4lNc7c4XmchP1NNOhhGeUgnFl0fy20Daqvd+WPyWI4Opnn7bst/886khLPuKK3VqD6GAmmW5tq/A8pK1SsMIDdVTNiZDDL+BO0MoUSH/Y/RSOKEVP4ZT2pg0C3MVV6sztucpnrN8RsnP/rUgsZKxYMZIINvrk3hxHYJg== 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=+Ixm9l+O+k/baTuyJQ4Y657RwEsmG7lRlBXweQoytQs=; b=lyBzO8QdAGXWRGKsqnQfSqMbtj7wwQBob15pal/hocYo7eSWV+lrb9xJ2mkqpKu3wVAdYmv+GjoJJjlEcXVtvYzUXLz+kfLeDd+cMRRxcJ5gL3GVjJeSWjVr7l1how5iDeNL8TIuPHsm3SeR/hexJTfp6Vzrpeo5vax3fgeJDx/kDjArSZYcs6TBbBl/+FO3+ZGcJBlBB9GA4DW0AvUu/yR1W1YlcC04FJm8Ax6heIfNRquClHh2fHOIvlRZEjYsuUMsVemB+3wcQD/OWxmkgP7Lw3xZTSoojLaPhUoK5uymKhe4gsSdLpm9kjzFiQgeUYj3GYTQpZElJ3BatLjoTg== 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=+Ixm9l+O+k/baTuyJQ4Y657RwEsmG7lRlBXweQoytQs=; b=cWNyxYJA3A0PggH2No04sorvxwz1nVvfX4DPFygcnZ9axzPLJix2PFtaR3oqhNO4A8/ACQdc3hVygdyHTT9eGW+g66zmbDl4Zu7QkCAqe6PEspO1wtG1ZjfvHWXObdqmz1XYa4pzaDkTfvc6rIRMjcPlPkaLxRYqFvRSDuhJ1Fc= Received: from BN9PR11MB5484.namprd11.prod.outlook.com (2603:10b6:408:105::16) by BN9PR11MB5274.namprd11.prod.outlook.com (2603:10b6:408:133::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.24; Mon, 30 Aug 2021 07:49:27 +0000 Received: from BN9PR11MB5484.namprd11.prod.outlook.com ([fe80::f954:8df:981f:5b77]) by BN9PR11MB5484.namprd11.prod.outlook.com ([fe80::f954:8df:981f:5b77%5]) with mapi id 15.20.4457.024; Mon, 30 Aug 2021 07:49:27 +0000 From: jiaqi.gao@intel.com To: "devel@edk2.groups.io" CC: "Wang, Jian J" , "Wu, Hao A" , "Bi, Dandan" , "gaoliming@byosoft.com.cn" , "Ni, Ray" , "Kinney, Michael D" , "Yao, Jiewen" , "Zimmer, Vincent" , "Justen, Jordan L" , "Xu, Min M" Subject: [edk2-devel] [RFC] Design review for Lazy Page Accept in TDVF Thread-Topic: [edk2-devel] [RFC] Design review for Lazy Page Accept in TDVF Thread-Index: AdedbiDItZYG7+qFSi+EURejkaV4og== Date: Mon, 30 Aug 2021 07:49:27 +0000 Message-ID: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.1.3 dlp-reaction: no-action 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-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa473306-366f-4036-e971-08d96b8ab19b x-ms-traffictypediagnostic: BN9PR11MB5274: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xdiLsh8eY0iV0RTkZUmeidpepFfOwaQvapDFwOQa2q+oIQgXvi6F7K8B+0JOonm8mWUSUHWu2fI8bjS6fkG46BPuAL5CEFWPJ/DYpOEZvXLfdzgWtC2/C8I9yPHIg7GuiQayTm0FKGiTz4hmV24SPFS9jnEgaolcnv+e+EefJJUDaUB4NBbdtC8UAx7yNAynVkp8To2w5yLDt+v6y+LBcRpQP8C5JsRmBHoO0RUZbBxi+SYLHD1RrjqaHm55SxkWF0CPBYKEf9J0nP1i3GbrMffMXJlkTp+f7/S4DlUHlfaIzYjB4T9HRBiUY6+c0ffTEpJV6Oovj2/pdvsLifWCZ7+xk/NRV0Dt1jFBV5YbNWsaPrEc74A6SgdaxCp60EIyzbe//af+mHaDjWTO2KcAkZ+8suFdklYq66XSmwOJazMXTNZfvBSuImV8CGcnjMfhG/avItPaGC8EMGp3KJVoCswDm2tZYqzeYYE9nu7Hp9b6nIDpfvmw3EYmDqBECzLn2a7+DNAmYxwCmTjQbA4eKCj7FdPBmm1CFGrKOqsv99vdbBZcBIczCAaz40u847zEYUhzh5xElYlsxPuvnwLbkeAfAYGeChdoLSS0eF53d49brXajSaJHvWN5XO7fzldSnwrQaFAmmYOHL/LBntoqcQtA/VcauvLUfDk7DJdUCGa787PeE2ln6CyOj1jCG5LFrScZU55XB7BUgl8O5tOGVAO+bcTeCJty/KEJd79Wpolo8bCKlWiXp1nhFtiZew5o4YihFOWjhIULO6iGHUUQP03xr6yMuvdK272VKMuJtRl51aIanNcJyfWVJQ+mlkYzseTKaQIaBcRU78PRBcrmsA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR11MB5484.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(366004)(376002)(396003)(346002)(136003)(39860400002)(6506007)(6916009)(66946007)(38100700002)(66476007)(66556008)(64756008)(66446008)(7696005)(478600001)(71200400001)(8936002)(8676002)(76116006)(186003)(52536014)(107886003)(38070700005)(26005)(122000001)(33656002)(2906002)(54906003)(9686003)(4326008)(5660300002)(55016002)(966005)(45080400002)(166002)(316002)(86362001)(83380400001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?QA6diYV6hKu+62fPGAQVRlXFFkaHUCUGw4SmqG+KGnqijvym0LbonmVXOPKd?= =?us-ascii?Q?YG1IBUPLNPPfm2dLrdC4+KcDEwPp41HLTrPhYvCkVxd/vMT9Ks5jVsHgWw4N?= =?us-ascii?Q?e7NsZMUrURaqaBSl3sMgHJBclAC3cDMYp927fja5GSWcDpell1lLb0jJxKtE?= =?us-ascii?Q?hT4KBN7FgOoZMYgVzrsiY0PD1hn487Jtx+gQGMLxF1rdKFATGvw50b9c8u2j?= =?us-ascii?Q?jXTNrWBKkctUWW/vG9qyLNJry+4hBJHIiIBmWU97PXxf59JSWJ85wXB5B+Jb?= =?us-ascii?Q?F1ueZNZ0zUpgvXcdSM8PCYvQSObWYNRgtvp3/lllGfSXLYleSKTbblvVPIhQ?= =?us-ascii?Q?HWSaGKNixy2acm5KhO0EvqavACfYaJvjLhY/5aPPFbXlyPayfXrAMuRpF2B0?= =?us-ascii?Q?Uh+eQhulm4I+K/Td6RspuGZhoo7Kt3mFT3KdoN3z+uBWc3bRII1USu9gKBq2?= =?us-ascii?Q?LhVOZ9ursWrjc17++x7oyyS9OGMBSAlFq9U0OHTOa0y9RJLUCNFKBe80ZoRZ?= =?us-ascii?Q?+PYlpBHMLu2R4qRvJBb20TM+rEBuN2Z6Neb4CCEqjEiz1fTEniy7hLFdRByX?= =?us-ascii?Q?G79OXGqpZeFawTeHFziXk/v0AasQb2FxQqJNgfywMBzuZxjtxWRvj8UttRjG?= =?us-ascii?Q?q6pSHrn91bcB83CE73jGS1XUpJ5kb//ne6bExtRJoTKtKqeTVmxDIOfBrq1Y?= =?us-ascii?Q?P7mEQsfSayIs1Mx+dKbAyj1QvSUunomXbziMIhJ6reGHphJNU3ikBWFRhckd?= =?us-ascii?Q?+ZKwK2omuFOSZNkfsEvMXSPMCbCTdKbZW7Tb5KfcHpaFXRmM/ppHE/FsHMaS?= =?us-ascii?Q?1BbVSUk3xZ3aDim1mgbx6Klz0Jeexa0yRmH5vtUKXvaRoDjmsR2wMioODtZO?= =?us-ascii?Q?jEDQfYQdR4XBNcOyxwG+JyHIZ/hso9A6fXUsJ42feY/6n/ecQSLqjF5hdV/c?= =?us-ascii?Q?RBUsmDPmLOBbPM7Ekh3/V+dHGDqvfIO8+tfwn4Vw9IH9+npDg+I1XtmfqygI?= =?us-ascii?Q?qh1CCmkZnudEVXYDXlKqKMsQU7hGl3GG4/O586Sgbx9lh4oWFV2SeVTPY9tf?= =?us-ascii?Q?tYM6vYQqqnKuVMhsj1b01u01fHlvHB4mvi3NAnePWeCDHnd7WncMZ7XKZvt2?= =?us-ascii?Q?N3Dh6hA6RQEXbKPBpP7FGTzV/LAWWiKsg4DmXg1pICjWFnQK7/xXOWt/i/ez?= =?us-ascii?Q?N9sn1Y73R5xNiZOctTU7XKUxKRPNnJ1SsLXjLl2/niG5zuzT2pSVwdp5MBcu?= =?us-ascii?Q?knTw0ToaNcIj9Yz42/uyk6PkijRbl7Pk2xKBkiAjSVKWKMJoHCLx9r2KK8Vo?= =?us-ascii?Q?leirf1QbFOOLZafQFcPHQjV0?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5484.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa473306-366f-4036-e971-08d96b8ab19b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2021 07:49:27.7944 (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: pDprxeUMYIDN1wsyV1PAB9HHlMsZBDFlZyCH0e7RLvQE2FbLiP6JD/qRUysGlw7VTzeSdu+U1Y/Eg3hMr3hQ7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5274 Return-Path: jiaqi.gao@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BN9PR11MB5484D7B4F68DFBDF53AD2454F2CB9BN9PR11MB5484namp_" --_000_BN9PR11MB5484D7B4F68DFBDF53AD2454F2CB9BN9PR11MB5484namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Motivation: Intel TDX provides memory encryption and integrity multi-tenancy for hardwa= re protection. A TD-guest uses TDCALL to accept shared memory as private. H= owever, accept whole system memory may take a long time which will have an = adverse impact on the boot time performance. We introduce Lazy Page Accept = method which means only part of the memory is accepted by TDVF and rest of = it is left to OS to be accepted. Issue: Memory size that need to be accepted by TDVF cannot be determined at the be= ginning in some cases. For example, kernel/initrd size can be large and may= exceed the memory that has been accepted. Because of this, we have to prov= ide a method to accept memory dynamically. We propose three options to address this issue: 1. Modifying the memory allocation (MdeModulePkg/Core/Dxe/Mem) logic to = accept memory when OUT_OF_RESOURCE occurs. 2. Changing the process flow of QEMU direct boot and GRUB to accept memo= ry when loading the image fails and returns OUT_OF_RESOURCE. 3. Adding AcceptMemory() as a boot service interface to simplify the imp= lementation of option 2. Underlying implementation of accepting memory is provided by a protocol whi= ch can be installed by architecture-specific drivers such as TdxDxe. The details are in the design slides: https://edk2.groups.io/g/devel/files/= Designs/2021/0830/TDVF%20Lazy%20Page%20Accept%28v0.7%29.pptx I am seeking your feedback on this proposal. Thank you! References: [1] tdx-virtual-firmware-design-guide-rev-1.pdf. https://software.intel.com= /content/dam/develop/external/us/en/documents/tdx-virtual-firmware-design-g= uide-rev-1.pdf [2] A POC of Lazy Page Accept in TDVF. https://github.com/mxu9/edk2/pull/9/= commits [3] Add new unaccepted memory type in mu_basecore. https://github.com/micro= soft/mu_basecore/pull/66 Best Regards, Gao Jiaqi --_000_BN9PR11MB5484D7B4F68DFBDF53AD2454F2CB9BN9PR11MB5484namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Motivation:

Intel TDX provides memory encryption and integrity m= ulti-tenancy for hardware protection. A TD-guest uses TDCALL to accept shar= ed memory as private. However, accept whole system memory may take a long t= ime which will have an adverse impact on the boot time performance. We introduce Lazy Page Accept method which m= eans only part of the memory is accepted by TDVF and rest of it is left to = OS to be accepted.

 

Issue:

Memory size that need to be accepted by TDVF cannot = be determined at the beginning in some cases. For example, kernel/initrd si= ze can be large and may exceed the memory that has been accepted. Because o= f this, we have to provide a method to accept memory dynamically.

 

We propose three options to address this issue:=

  1. Modifying the memory allocation (MdeModulePkg/Core/Dxe/Mem) logic = to accept memory when OUT_OF_RESOURCE occurs.
  2. Chang= ing the process flow of QEMU direct boot and GRUB to accept memory when loa= ding the image fails and returns OUT_OF_RESOURCE.
  3. = Adding AcceptMemory() as a boot service interface to simplify the implement= ation of option 2.

Underlying implementation of accepting memory is pro= vided by a protocol which can be installed by architecture-specific drivers= such as TdxDxe.

 

The details are in the design slides: https://edk2.groups.io/g/devel/files/Designs/2021/0830/TDVF%20Lazy%20Page%2= 0Accept%28v0.7%29.pptx

 

 

I am seeking your feedback on this proposal. Than= k you!

 

References:

[1] tdx-virtual-firmware-design-guide-rev-1.pdf. = https://software.intel.com/content/dam/develop/external/us/en/documents/tdx= -virtual-firmware-design-guide-rev-1.pdf

[2] A POC of Lazy Page Accept in TDVF. https://github.com/mxu9/edk2/pull/9/commits

[3] Add new unaccepted memory type in mu_basecore= . https://github.com/microsoft/mu_basecore/pull/66

 

 

Best Regards,

Gao Jiaqi

 

 

--_000_BN9PR11MB5484D7B4F68DFBDF53AD2454F2CB9BN9PR11MB5484namp_--