From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 2D6437803DA for ; Mon, 20 May 2024 06:54:44 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=sVy7khJ1UAFo7Dp2+jE+HGal2U56KSQYpHB1UNT2nZM=; c=relaxed/simple; d=groups.io; h=From:To:CC:Subject:Thread-Topic:Thread-Index:Date:Message-ID:References:In-Reply-To:Accept-Language:msip_labels:MIME-Version:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type; s=20240206; t=1716188082; v=1; b=TC9TLOmk3HxSOYrCslMYtr/eXe3GcAN0ZuahkpzRJrSNch/a+EVlIuATxyO9ni7NXZ4DUiGG HChxETpp6DSpe9tF+6x2rJk/hvOu29ANbSvjXSvJ2LuEtZykb63e4CfnP89zhIjFj9Kz77musln Yafht35eQ99zBUw4ZgyPfS4aPFY+xyLzxKIC6cMC1IiY6QsLIovc7tw0xeU+uW/DEa8snLkVb0U kcjRItTPrmmQQh0emVNVTazMvwHiHNRrYmDDtoCxYMf8uG5El+8lVkviFfIvpfffU2KaN3jWJmH fV9lMVRWEEJ9vLyXQlW9tErGporDpl889zupcvQYFoCPg== X-Received: by 127.0.0.2 with SMTP id Cnq8YY7687511xTtI7PIIq4C; Sun, 19 May 2024 23:54:42 -0700 X-Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by mx.groups.io with SMTP id smtpd.web10.54417.1716188081699853463 for ; Sun, 19 May 2024 23:54:41 -0700 X-CSE-ConnectionGUID: +MCNOXj8TsO84wM3MJOA7A== X-CSE-MsgGUID: qnoNiFp+QGGcYFxcVlX3Jw== X-IronPort-AV: E=McAfee;i="6600,9927,11077"; a="12484948" X-IronPort-AV: E=Sophos;i="6.08,174,1712646000"; d="scan'208,217";a="12484948" X-Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 May 2024 23:54:40 -0700 X-CSE-ConnectionGUID: zZ0mG9cbT/GKx7YwLqrriA== X-CSE-MsgGUID: sZOI5jFlRtmD1zKQYmlR1Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,174,1712646000"; d="scan'208,217";a="32456725" X-Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmviesa009.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 19 May 2024 23:54:39 -0700 X-Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 19 May 2024 23:54:40 -0700 X-Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) 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.2507.39 via Frontend Transport; Sun, 19 May 2024 23:54:40 -0700 X-Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101) 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.2507.39; Sun, 19 May 2024 23:54:39 -0700 X-Received: from MN6PR11MB8244.namprd11.prod.outlook.com (2603:10b6:208:470::14) by DM6PR11MB4593.namprd11.prod.outlook.com (2603:10b6:5:2a3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7587.35; Mon, 20 May 2024 06:54:38 +0000 X-Received: from MN6PR11MB8244.namprd11.prod.outlook.com ([fe80::41a4:c775:32e6:76a8]) by MN6PR11MB8244.namprd11.prod.outlook.com ([fe80::41a4:c775:32e6:76a8%4]) with mapi id 15.20.7587.028; Mon, 20 May 2024 06:54:38 +0000 From: "Ni, Ray" To: Nhi Pham , "devel@edk2.groups.io" , "Tan, Dun" CC: Liming Gao , "Wu, Jiaxin" , Ard Biesheuvel , Leif Lindholm , Sami Mujawar , "Gerd Hoffmann" , Andrew Fish , "Yao, Jiewen" Subject: Re: [edk2-devel] [PATCH 0/9] Allocate and unblock variable runtime cache buffer in PEI Thread-Topic: [edk2-devel] [PATCH 0/9] Allocate and unblock variable runtime cache buffer in PEI Thread-Index: AQHaqD+LljehAQs07Emcr6Vx/ADrhbGfUiEAgABhds4= Date: Mon, 20 May 2024 06:54:37 +0000 Message-ID: References: <20240517094917.513-1-dun.tan@intel.com> <6a4e2b6f-fbab-45cb-9cbb-e5fb2f027f36@os.amperecomputing.com> In-Reply-To: <6a4e2b6f-fbab-45cb-9cbb-e5fb2f027f36@os.amperecomputing.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN6PR11MB8244:EE_|DM6PR11MB4593:EE_ x-ms-office365-filtering-correlation-id: 8c9785dd-df33-43be-28ca-08dc7899b749 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam-message-info: =?us-ascii?Q?lvfQq0NCIRadmgQdMaRG7qRH7qqddfwTf6AeTq4iIUf07Msx7L8q8ei8TJJz?= =?us-ascii?Q?iXIxF7qMu+X2hCkKhGC6SZfFAONHNlbgzJHpGVk/jwFWQ1eBIYUFbCSl/DQe?= =?us-ascii?Q?gZV0RyKQiaTSPLlE+2+V0HG8lp8XobEWYx79stNNibko/6uhkpEz6IYKjdLf?= =?us-ascii?Q?uEzUns6Q/GlB1qJl+wvmKy1uR4q9X469uuFZF/XFgw6rCa2L2LXil4SB9Zpo?= =?us-ascii?Q?sqSnqW2bqz9uukqo6EiBWJZOU2R1Y30s5TrohprP3eNk3oqiB6Rau97cNPUa?= =?us-ascii?Q?kESq3ndN+Jj0lHO+On1BeJZG5mMdDRdVvFpIAkQ9viux42zA9Ab8rb1y7O3X?= =?us-ascii?Q?V9TnbDnvP/DUzdj8OgTCeOHJt/vKruBv8aVDn6i6wLHYipavkbpnJaAlDXo1?= =?us-ascii?Q?y87R3TSM+EGouwi4CzHj9kh+9J1r4kCiTYD48w++KA1Cpf4vkjqJnOA1xN61?= =?us-ascii?Q?R7D72E6YZTh8GPEkwN7nj0zyA7bdPZRLj/K0XbQa8GUZomjCoyARXpvRZPrE?= =?us-ascii?Q?IrC/Jss+sX4tclYMIzt3xN5VFOkupRAmM2VXmt7IDwtMx1Nrpt51h3rqmtR0?= =?us-ascii?Q?AFbmeHZgJLGqaUZqkhIDIjPZKwuLlsV0XCopA0731n0OpkDK4mhz2e0jJRUj?= =?us-ascii?Q?pyE4rqWdHCIorCxJ3gm1yfTHBi2CfT+gRFlzOMXGgmhnqSBArkpG9gFpYwnF?= =?us-ascii?Q?sX8U8/DyjxFG7nyssZhlfUHUR6u+79Vh7qWAk8t21Vj5g58JN6WDfmG9vZcK?= =?us-ascii?Q?HOOkW9H6T7XX9aB5nWxdcZgPHctR0eSi3PTFWY7SCgoVRYrTBjAbxbrhDX3M?= =?us-ascii?Q?n1mQodIxSN14oFhUPtT3VvUfitjiFhAPYaulYhR6yndwJb0ArnIvPvQ8JmgQ?= =?us-ascii?Q?jUMWIlqTqS+i0NK3Q+qqRrZydYxMQJ4gOHj42xwYLXIywXmZ5nJXyVrHTWmY?= =?us-ascii?Q?9ApjDHDCL/YJCek4um3N5bYXyiMmU/dgwv7nf50izNOTTxFYYif/xlJqabYM?= =?us-ascii?Q?SQAb/ChvyzRYGD4NGB8mAAenO2SNQyU/cx7eHyIYYjNi1F7zzFcqfnsssY5g?= =?us-ascii?Q?fy/VrXWnUqEj4EvQgLBJmsS5XKHgj2l5fd2+nfmGlqiCONzSQGWeOJmrTyhn?= =?us-ascii?Q?2igNyihZPxpieNBmvz/T9Kj8vAVbny6AEt8/a31EgK4M9qNHmhIui/JH3iVe?= =?us-ascii?Q?Sx3XxakTfgJQf9Y9o/yrVAMlZ8zn3TMLOtK25yxuc7Azdz175o0DkZRpSw+M?= =?us-ascii?Q?eClSlnkkyzYanzsnkDHPzAmZyWUdPEyV8OBM6oep1Q=3D=3D?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?hv8O71FedviLRFamSh96xmvooVvFgKixMccxWRNwA12Nmx+qbUG0lakZnGoN?= =?us-ascii?Q?+78G+nzTRdXOCpVl3gzI7t4rwAsF5YGOVJdSdzcOLpGzv2D4SRTpbYCzeE48?= =?us-ascii?Q?MhXWMnTBgHHPpalVrVu6ysRn+WEx+0kqp30FKXzfUmSD2MheaPmJqbyILkrC?= =?us-ascii?Q?tFCia6hNdLgN1ilJaU4I2XzehfehXmBDj76l3TjFYcKy2dKopfRtKGcukksl?= =?us-ascii?Q?tiQG1dI8Hh1/Ctx8R8GFWbgivttmr+D7ot7a6oW/X+5k3bd8CSggpvmtHj+Q?= =?us-ascii?Q?qlLgo7F48NnRUN7x6Y+2/6FFWP2Q5BugyFADLTK2us6Ehvb5W02OUy7F9j18?= =?us-ascii?Q?2dbbkkzV3rP4XhyYEOEd3B+ueYP8h59aHuX33w4+OaV583R5BTDFbzRU/a43?= =?us-ascii?Q?NUI/TN6Qd8DtZnGUGKQyCKYbUuO/VsUtqt3eG1+eCHqdi3aMZgVHq87yEJ7G?= =?us-ascii?Q?pSZ5e/XHA4bLnDUYzxkRZ75/UswdNrLupGblOF8pfnpf8dh64U+daq3dIRLC?= =?us-ascii?Q?VRZ7Css91mt1pcZoiGMxfzdTUCuhUfENloSxExOj8qUDc4E/KUZ4+JEVaRYf?= =?us-ascii?Q?Jcu9JXEt45ikqCHDe+SPsprgwmj92vvwR9ExZLvQ+LOgg0Xa6jpupGfmabJM?= =?us-ascii?Q?BodTarwuoE8Aon4qCMcENnboa4lzaABuff0FrKnV6XhYmJLGya3QJKgjF81r?= =?us-ascii?Q?fF1ZjPqlLSurf45wkKbLUbtr/SDZJR5dz8zDikYODdSCdHa8bdxrNRYsLjUS?= =?us-ascii?Q?kQd9E/7nqNdQWZ84FU1JhiPMmEnPC0Bb6+xtnlfbaAm07A9be0ZYqH0NAEUW?= =?us-ascii?Q?e6HwRV8+s0yrvjoAZFpxrQ01kSSps32qzEdsDAcRsCbM/az2O4iTMyTFrAeO?= =?us-ascii?Q?DFIwAi/laBmgfG18qKHnzPqg0ijVrvCs9PZg+Ji5Ly0mFjlXno+/BG0qhntW?= =?us-ascii?Q?IWErnNJH+fdZtCZCYp5ucJP8NMd+O8GMmjX/P7BHzSCoej2k9I271Aq0dRtQ?= =?us-ascii?Q?2DLlIAPyFew/6kJWofLiNLtPeBeRNEZZq1XYi730cjfciFNmMZq6bON/jkrr?= =?us-ascii?Q?cCZVjrPvQnaoxgj+yMmPPDSQpsbG6AiW7mMIrT6N4ukgikYuqKea4FGwv/vQ?= =?us-ascii?Q?HyrhkmI8Z+8RI9BxhV4VmUsJpuPe7IMlmSkrl3vQ1cgUZfdnYBdHxB9XTBXJ?= =?us-ascii?Q?zMclUuqKowoxJGJZJWCz+D9UmvwKOcgAjVp/8cDmdUVL2xA0cli4KWSLlacs?= =?us-ascii?Q?gvvBp82rd/Ro/4Gx5qodFp+kSVrCnFu4eh04h7mgj6Yo72VVekPCujOkACif?= =?us-ascii?Q?9A5nDwq/4BYp+7MlL334bDQht8KIRWv/yt13n6uyqLLIZitt++EjZSAjJtRX?= =?us-ascii?Q?kn6Xt8IKRI2x9Q/1XbCHeKB6i2jgea4R4c6BQTgSQHx6F1RjwBAd1kyDYHnv?= =?us-ascii?Q?ZiJyFDYoBGZPfMFNRtUua4mgep8ips7UHgMlvc6oB6m362GD/6UElbJcUmTl?= =?us-ascii?Q?7J8GZsoT676I+TeQimuoOL2Bp3Ec+Jt2N4dZjK2d1b4fBAB7GGtYk6sYSGUT?= =?us-ascii?Q?NFokQ7gyuH+KsApPsG4=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN6PR11MB8244.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c9785dd-df33-43be-28ca-08dc7899b749 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2024 06:54:37.9729 (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: wMpmbsZuu3LbgSAHLEQrWzotitdJ0U5MRsbfj3CfhgJpeehlAB+Bw5YoAtTaozBLRUEZj1qDtSpC879L2ghXxg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4593 X-OriginatorOrg: intel.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Sun, 19 May 2024 23:54:41 -0700 Resent-From: ray.ni@intel.com Reply-To: devel@edk2.groups.io,ray.ni@intel.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: RoxgVw9fR0VHOyWL1dzr18Qgx7686176AA= Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MN6PR11MB82440A604ED091712CCA3E858CE92MN6PR11MB8244namp_" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=TC9TLOmk; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io --_000_MN6PR11MB82440A604ED091712CCA3E858CE92MN6PR11MB8244namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I remember ARM platform could have a PEI-less design so that SEC directly i= nvokes DXE. So I can imagine that a SEC logic to create the VARIABLE_RUNTIME_CACHE_INFO= HOB. Then it comes to how to calculate the size before bios boots. I think it's doable. There are 3 caches. Volatile cache size is hardcode by a PCD. NV cache size= can equal to the bios NV variable region size. HOB cache size can be calcu= lated by: 1. collect all default values in IFR/VFR 2. convert the default variable to auth/non-auth type depending on the BIOS NV= variable region format. Both steps can be performed in bios-build phase. There is no runtime inform= ation needed. Thanks, Ray ________________________________ From: Nhi Pham Sent: Monday, May 20, 2024 9:01 To: devel@edk2.groups.io ; Tan, Dun Cc: Ni, Ray ; Liming Gao ; Wu, = Jiaxin ; Ard Biesheuvel ; L= eif Lindholm ; Sami Mujawar ; Gerd Hoffmann ; Andrew Fish ; Yao, = Jiewen Subject: Re: [edk2-devel] [PATCH 0/9] Allocate and unblock variable runtime= cache buffer in PEI On 5/17/2024 4:49 PM, duntan via groups.io wrote: > This patch set defines a new VARIABLE_RUNTIME_CACHE_INFO HOB. The HOB is = used to store the address and size of the buffer that will be used for vari= able runtime service when the PcdEnableVariableRuntimeCache is TRUE. > In following patches, when PcdEnableVariableRuntimeCache is TRUE, Variabl= ePei will install a callback of gEfiPeiMemoryDiscoveredPpiGuid to allocate = the needed buffer for different type variable runtime cache and build the H= OB. > Then VariableSmmRuntimeDxe driver will consume gEdkiiVariableRuntimeCache= InfoHobGuid to initialize the variable runtime cache related content. The c= ode to allocate and unblock the runtime cache buffer in VariableSmmRuntimeD= xe is also removed in this patc set. > > PR for review: https://github.com/tianocore/edk2/pull/5607 Per design, SMM or StandaloneMM needs to access these runtime cache buffers for cache coherency. I'm not sure how to implement the MmUnblockMemoryLib for ARM to dynamically request mapping of the non-secure runtime cache buffers in StandaloneMM (Secure World). Is it possible to have these runtime buffers allocated statically with predefined PCD at build time. On ARM, they can also define the buffers in device tree (manifest)? Thanks, Nhi -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119072): https://edk2.groups.io/g/devel/message/119072 Mute This Topic: https://groups.io/mt/106150796/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --_000_MN6PR11MB82440A604ED091712CCA3E858CE92MN6PR11MB8244namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I remember ARM platform could have a PEI-less design so that SEC directly i= nvokes DXE.

So I can imagine that a SEC logic to create the VARIABLE_RUNTIME_CACHE_INFO= HOB.

Then it comes to how to calculate the size before bios boots.
I think it's doable.
There are 3 caches. Volatile cache size is hardcode by a PCD. NV cache size= can equal to the bios NV variable region size. HOB cache size can be calcu= lated by:
  1. collect all default values in IFR/VFR
  2. convert the default variable to auth/non-auth type depending on the BIOS NV= variable region format.
Both steps can be performed in bios-build phase. There is no runtime inform= ation needed.

Thanks,
Ray
From: Nhi Pham <nhi@os.a= mperecomputing.com>
Sent: Monday, May 20, 2024 9:01
To: devel@edk2.groups.io <devel@edk2.groups.io>; Tan, Dun <= dun.tan@intel.com>
Cc: Ni, Ray <ray.ni@intel.com>; Liming Gao <gaoliming@byoso= ft.com.cn>; Wu, Jiaxin <jiaxin.wu@intel.com>; Ard Biesheuvel <a= rdb+tianocore@kernel.org>; Leif Lindholm <quic_llindhol@quicinc.com&g= t;; Sami Mujawar <sami.mujawar@arm.com>; Gerd Hoffmann <kraxel@red= hat.com>; Andrew Fish <afish@apple.com>; Yao, Jiewen <jiewen.yao@intel.com&= gt;
Subject: Re: [edk2-devel] [PATCH 0/9] Allocate and unblock variable = runtime cache buffer in PEI
 
On 5/17/2024 4:49 PM, duntan via groups.io wrote:<= br> > This patch set defines a new VARIABLE_RUNTIME_CACHE_INFO HOB. The HOB = is used to store the address and size of the buffer that will be used for v= ariable runtime service when the PcdEnableVariableRuntimeCache is TRUE.
> In following patches, when PcdEnableVariableRuntimeCache is TRUE, Vari= ablePei will install a callback of gEfiPeiMemoryDiscoveredPpiGuid to alloca= te the needed buffer for different type variable runtime cache and build th= e HOB.
> Then VariableSmmRuntimeDxe driver will consume gEdkiiVariableRuntimeCa= cheInfoHobGuid to initialize the variable runtime cache related content. Th= e code to allocate and unblock the runtime cache buffer in VariableSmmRunti= meDxe is also removed in this patc set.
>
> PR for review: https://github.com/tianocore/edk2/pull/5607

Per design, SMM or StandaloneMM needs to access these runtime cache
buffers for cache coherency. I'm not sure how to implement the
MmUnblockMemoryLib for ARM to dynamically request mapping of the
non-secure runtime cache buffers in StandaloneMM (Secure World). Is it
possible to have these runtime buffers allocated statically with
predefined PCD at build time. On ARM, they can also define the buffers
in device tree (manifest)?

Thanks,
Nhi
_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#119072) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--_000_MN6PR11MB82440A604ED091712CCA3E858CE92MN6PR11MB8244namp_--