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 0E439740039 for ; Mon, 12 Aug 2024 05:50:09 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=8rKUm2/uFTyJG3Zcbbm5n/ufNRRozTgV3lXJtTtwgyo=; 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=1723441809; v=1; b=CKa7roOb2JMvdFQon30LvzhrYpzmcnmDR6VXkKIJt0s/xB8PhgmjVLQyx5LPiJmBIQSL3NzJ Qs+9v5Nxbph2XrHOJYv6TizWJoIaK5ul9xqh+/+DPvH6z5UWdcdO9MNuXCOyIzVxZiiGNLmYcSr no4cXMiZByRKSRivns/THa+p1wvhKR+CIJPUZ7HE+/Q9gA8yy3q5IfomY5ovbNl0aoWuf/LIhfr 9MkJVVraYvrTkZ9NIbD9h/5lidfTtA0W2yxfVnE9y23ulGNwAenUOWsxPeFtMJHsPyDqCsZ9XKj gX6DLlAJDWJ4ims673MykFqWuPgjYc2LmZlzPvbqZhOvA== X-Received: by 127.0.0.2 with SMTP id cyZ9YY7687511xkHPRyHY2K6; Sun, 11 Aug 2024 22:50:08 -0700 X-Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by mx.groups.io with SMTP id smtpd.web11.39880.1723441807471583794 for ; Sun, 11 Aug 2024 22:50:07 -0700 X-CSE-ConnectionGUID: 5ikmqJ5ESSqU5bh+KnQNaA== X-CSE-MsgGUID: AvevK7PqReKnXqfWYKWvvA== X-IronPort-AV: E=McAfee;i="6700,10204,11161"; a="32926265" X-IronPort-AV: E=Sophos;i="6.09,282,1716274800"; d="scan'208,217";a="32926265" X-Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Aug 2024 22:50:06 -0700 X-CSE-ConnectionGUID: DYY81QULQf+6C9Us+W3Lww== X-CSE-MsgGUID: lKpKmrniQmexJiEmSDLl8w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,282,1716274800"; d="scan'208,217";a="62805445" X-Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmviesa004.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 11 Aug 2024 22:50:06 -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, 11 Aug 2024 22:50:05 -0700 X-Received: from orsedg603.ED.cps.intel.com (10.7.248.4) 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, 11 Aug 2024 22:50:05 -0700 X-Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.168) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Sun, 11 Aug 2024 22:50:05 -0700 X-Received: from MN6PR11MB8244.namprd11.prod.outlook.com (2603:10b6:208:470::14) by DM3PR11MB8713.namprd11.prod.outlook.com (2603:10b6:0:45::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7828.31; Mon, 12 Aug 2024 05:50:02 +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%3]) with mapi id 15.20.7828.023; Mon, 12 Aug 2024 05:50:02 +0000 From: "Ni, Ray" To: Kun Qin , "devel@edk2.groups.io" CC: "Wu, Jiaxin" , "Tan, Dun" , "Xu, Wei6" , "Zhang, Hongbin1" , "Kinney, Michael D" , "Zimmer, Vincent" Subject: Re: [edk2-devel] Proposing v3 of MM communicate buffer Thread-Topic: Proposing v3 of MM communicate buffer Thread-Index: Adro6QAPLf/WRMT7RNuaRkedI6TpYwAgLKmVABOn43AAFYpekQAIQHEgAJLa3U0= Date: Mon, 12 Aug 2024 05:50:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=8a5f3bc2-1702-443d-84a2-a63e5af27909;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2024-08-07T16:33:32Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN6PR11MB8244:EE_|DM3PR11MB8713:EE_ x-ms-office365-filtering-correlation-id: aafee528-5199-4952-095b-08dcba929c38 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam-message-info: =?iso-8859-1?Q?rCI9EjbsD4sHroZgbTqHFKIabloOnhgR8R7ezkMwnX9LSKD7kNLbK92pnk?= =?iso-8859-1?Q?cq3W32V+tsczlo+uo7Wxi/+6fC5GsrZJxISB+ivxWewqe9Mn2xsz147WjE?= =?iso-8859-1?Q?KyAXMJ04gzjdlViTZX1ZBxBkWghnlsFHYjzupYFsdAfuCjb8irhK794oZG?= =?iso-8859-1?Q?7RdtWbjDLfgGiVSsAN2PcNDJgyXXJnRuBuq3yLF4YmyfDfVuObna/Ul2cI?= =?iso-8859-1?Q?YsADvPPlvgFaLq6hH4AQcPI7ItFkKF+20158dvWFjq8sKdStq61OKsOASE?= =?iso-8859-1?Q?XrHa71DD4Spmhnf4jfRdOoyYMEJ5qmCQ8Az/XZreGG4DakBs52DS2T2iyQ?= =?iso-8859-1?Q?vLKCuMBFL7YPVdQrGllHoBuYD6/7FwyB1jRKtt0GdlnnqlCuajS5FGXWN5?= =?iso-8859-1?Q?9l4vDbQ8rHzo5BUAoG5/z2qFmwaE2s7a+DzVGVno8PeWCx/XGihJKLnmVO?= =?iso-8859-1?Q?Sa2XzdhmzWSp8EzsYKaIwybPbiQqRq39vAKkeHYNhsfhm+73XIUxEElvub?= =?iso-8859-1?Q?7AMQgIQBJTSJnOI3yEoL+zgtHGbTp8QbIrBVFg0PHe9JWb/u7NZWtF8Yjx?= =?iso-8859-1?Q?DOGbhNCX6yhdp/jp86b52bE28xQWn4HcaUy+pms1eBy0K5BxT1+8MHArbw?= =?iso-8859-1?Q?6Dt7RdaLfq4Jyq8tE2YFJOsXXXJvU8FM2ZloXhlj9m9iJ9h00glyRrYSlg?= =?iso-8859-1?Q?A/DgocsfQPUuhrxZU9Ys7ISaFGgvtp+6hhL+GS7eyfOhNxNFjLhIvyx7Bf?= =?iso-8859-1?Q?mGCUlhbOsawKZ5bBJQ9Zs6OiZ+wolpOl/4M1KL3M39y0kQCSwa1znna+AV?= =?iso-8859-1?Q?GiG40IqQNkUEu3n4ihv7asTgGaYo6K5b0nXgn/PkPRL9V2RGSX5S3lxlAC?= =?iso-8859-1?Q?uoDimeBRIeaNh/pFf7e3wHl6nX8zEesY8HTEHSHGJCYqETZpnTT8S1i2sQ?= =?iso-8859-1?Q?rduqcUZLg4JbTZ2EvMaEvZJ7dEOPe1kSN5zPfZdNzikE9hGp4i2shhmyPO?= =?iso-8859-1?Q?sgVyPlp1dWaLL1IuJ3KpKyefV9cf5nb82cPO5CSGuAO4ATu8A2PRG4N8uE?= =?iso-8859-1?Q?xuhTclrblBjVyT+qdt8BHW3f29iU+f+fNZgxsNT7P18iWjX5oRtaAqTbaX?= =?iso-8859-1?Q?xKgwW/5cnr8v5ZF+YuaPRV5QuSMu7s40WbuUpyeeZx92cDyft35Wo9AZRB?= =?iso-8859-1?Q?LuQQ4FZ57vgocDf48n5kbYazufrVA2BufBuTcUnS+tU+3idBdeSoUZDQLc?= =?iso-8859-1?Q?lSrxagyum+0ZBnTF9ugyVIRpc3xVuLLnqhqFMPh8kFK6GWKvFJPA22hj9L?= =?iso-8859-1?Q?e/VlP55W0nN+MIvirsx8x4WATSQcCIByfWe3ONkdbOjSVZvlLASk+b2qiX?= =?iso-8859-1?Q?cC3+Thr2MAtwdpc8JDKDC0hkwy8WmQDoJOi3QlpGpkkKZj7k30Pqk=3D?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?gy+zklZ8oALQOC9GcMukTYRC/XqLXqcnC+JNkUT9xeTjpwOyacu9oQ+y0s?= =?iso-8859-1?Q?XF4+B2Zkd3tG/6b07b9vXkdxqSJfFE+rvhHXKGk3u5RleubY/aJtDzGhnX?= =?iso-8859-1?Q?sg1fY4nFWGlhJUxnB8OZd8bIlNivH4ejn5t9a1l7cUi1FkPgEzhVGHXr/E?= =?iso-8859-1?Q?yiMIVKlQ55n2bJwCwJ8z7O1G+plbiFY71KOigaW2hrVgQy3di310Ip6anA?= =?iso-8859-1?Q?HFTP1ZMaVvEeoU6ap2IsMYiMvOyJ16EB/lcwWnaPH5hpREmenZpZ47CPcp?= =?iso-8859-1?Q?AIERgioHcR2pA3ygQXn7UIUzzg8APU/+eKEs4W29o70ciOI65/UaDYmqej?= =?iso-8859-1?Q?x3U661gdQ4MBzhJe+LR2Fz9FfnMfItaInNj6vwrOtZi7o0HWAKw7lf7p+K?= =?iso-8859-1?Q?+s1Z3nmrFZmZltItlrDsD6E2kencxJhB+CRr7mzRPdGmZ/n5MfbXj85D71?= =?iso-8859-1?Q?ZIwhNo4e42EMQFlidODpK2bvkHnv/8G7BMc4En1le+DOuru9cV/AYwE+1N?= =?iso-8859-1?Q?i45Zlw1dhzs+lxbmn4GmL0csxIwUZfCndARJsA5wagbO7ZA0yGFdxdihou?= =?iso-8859-1?Q?El0teUhNiuXrpyHRkTzjf/8e4iF823HHJ5ezZoXOkJHQJFZONVoSCnTmX7?= =?iso-8859-1?Q?Vk3lYHnzyuLetLUaHgxKeuE6CzHOFN91vzDEywiC6lD1UqxQlXyqVs17li?= =?iso-8859-1?Q?keX4UYAnuCWfxOLL+ZWhWCoiCHVKdgZGQoS8g19Get0wLzHGgMbbn3k/bD?= =?iso-8859-1?Q?4WW/YMtyPDUIzlRV/Tw2pL5apaiQ0xOgZHA84QNsKKQ2QqBgAn84tErG+j?= =?iso-8859-1?Q?NO4Pb8oM85f1dU4Ep7wlASdohIHK/MNT9pwxq6b1vPJtdX3mHe2bgOIVJh?= =?iso-8859-1?Q?+GYc5RbL6kIQypXBDDL0ch0u6htnsJAuEVyA4vV8L/BjKR19tH5X2kMwbw?= =?iso-8859-1?Q?3p/SegCkykOy87ROK9q6ppzxQE7d6jbqjEEhaDAHq13WV+6U+/w8g+Gljj?= =?iso-8859-1?Q?WqQ7uzL4Mn9i4D8k3SWaxFB13qnZ8nChZww0yxpXdqittqf2ciwmgJ/d1u?= =?iso-8859-1?Q?28yAFHw9q8SJmZ1muxmOeor9S8StPQLLGjilhzyk+aZOGPm5QvXYENMQKg?= =?iso-8859-1?Q?vdOFWFrA6e96vJL1pIFUcApKLbnaCSbTNtskeZS1JwZ60gYP0ez+3OkWk/?= =?iso-8859-1?Q?HfzQMi0dB9Y+9fbjpXhB5qoKj/bgKHFlNGQkLhNqTWG0NXtbFA8spyVIbb?= =?iso-8859-1?Q?2bv8GK1oPbe3oh/h/ev1JOY3CzYfmYHs4VlOxvD1HysoZacP5+y+Vyza+H?= =?iso-8859-1?Q?4sxXMkRg+v5UWPVI6pbdv2FKef6qBBXmx0GiQ6DBk1JhkkI7xa1EP8pqM8?= =?iso-8859-1?Q?BIwXtOi0/MLF0G2Ta/s34dGdawJdItcvNsZPRj+JUqdw9v0hDI9TvURNS2?= =?iso-8859-1?Q?0OZtFcXGMyRDbLwmObjBTRiJIG0ReuHALrw+GD2Z8AvUWB3qZ1y/3NWOzU?= =?iso-8859-1?Q?EwJtUGceNUsAGYTtxeqLW0ReaWpqrqqmMN8ePaPT3T5US/mpMmbbdIfk2h?= =?iso-8859-1?Q?OMplXcPccgtWONGNCW/voft9Zep6ngt2IUm5g1RQKK9rA1FJPpspuoV22+?= =?iso-8859-1?Q?5wTXukjXLGadQ=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: aafee528-5199-4952-095b-08dcba929c38 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2024 05:50:02.8128 (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: Lc0Ov+inFCakPRSIiRrE+UzkfPwzjHEAAjK54uxgvV9gVJqYpEhYevEeh/qR7CBVF+uEB+xwRK8Ba9MmRlUR4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR11MB8713 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, 11 Aug 2024 22:50:07 -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: yRixgarysWZGYMQc5Znyu9pZx7686176AA= Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MN6PR11MB82446EEFB2BE6CD76B0A66B18C852MN6PR11MB8244namp_" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=CKa7roOb; 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_MN6PR11MB82446EEFB2BE6CD76B0A66B18C852MN6PR11MB8244namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kun, This PR (Mm infra by jiaxinwu =B7 Pull Request #5914) contains all standalone MM infra related code in ed= k2 repo. Please take a look at if you are interested in it. Back to your proposal, can we revisit it once there are platforms that want= to invoke 64bit MM env from 32bit PEI? I personally do not prefer to make = the interfaces complicated to support a platform that only exists in theory= . + Vincent for comments from PI spec perspective. Thanks, Ray ________________________________ From: Kun Qin Sent: Friday, August 9, 2024 15:58 To: Ni, Ray ; devel@edk2.groups.io Cc: Wu, Jiaxin ; Tan, Dun ; Xu, Wei= 6 ; Zhang, Hongbin1 ; Kinney, = Michael D Subject: RE: Proposing v3 of MM communicate buffer Hi Ray, Your description is correct. I believe there are efforts trying to make Sta= ndalone MM launch in PEI happen? i.e. Add standalone mm ipl pei driver by h= ongbin123 =B7 Pull Request #5236 =B7 tianocore/edk2 (github.com) will bring in support for #1 and #2. Tha= nks to Hongbin explaining to me that such efforts are mainly targeting 64bi= t PEI. But I do not think it takes much more work to support 32bit PEI + St= andalone MM once this groundwork is done (again, we can help upstream the c= ode that supports #3 from Project MU if so desired ??). Moreover, just because there are no platforms in the public have such confi= guration, I would perceive it as a great opportunity to introduce the new M= M communicate header definition to prevent further contamination from the o= ld definition. In as the new platforms can setup MM foundation in PEI (32 o= r 64 bit, Intel or AMD) and communicate under the new definition of data st= ructure and PPI. Please let me know your thoughts. Your feedback is really appreciated! Regards, Kun From: Ni, Ray Sent: Thursday, August 8, 2024 8:48 PM To: Kun Qin ; devel@edk2.groups.io Cc: Wu, Jiaxin ; Tan, Dun ; Xu, Wei= 6 ; Zhang, Hongbin1 ; Kinney, = Michael D Subject: [EXTERNAL] Re: Proposing v3 of MM communicate buffer Kun, thanks for explaining that ARM does not require this. IMO, the proposal is only useful in X86 when: * BIOS uses standalone MM * BIOS launches standalone MM in PEI * BIOS PEI runs in 32bit mode I do not see any such platform in open source as the X86 standalone MM is n= ot available yet in edk2 trunk. Thanks, Ray ________________________________ From: Kun Qin > Sent: Friday, August 9, 2024 1:41 To: Ni, Ray >; devel@edk2.groups.= io > Cc: Wu, Jiaxin >; Tan, Dun = >; Xu, Wei6 >; Zhang, Hongbin1 >; Ni, Ray >; Kinney, Michael D > Subject: RE: Proposing v3 of MM communicate buffer Hi Ray, Thanks for your feedback. The ARM platforms I was exposed to have consisten= t operation mode is only AARCH64, so this proposal is not particularly atta= ched to any ARM problem. I agree that 32bit PEI/DXE communicate into MM will have issue on x86 platf= orms as of today. But I have only heard Intel processors moving to support = x64 PEI/DXE. I think introducing a new MM communicate header will help to p= revent the issue to propagate much further as it might take non-Intel x86 p= latforms years to fully move away from 32bit PEI/DXE. Please let me know if= you have any thoughts. Regards, Kun P.S. Project MU have a thunking module that can launch x64 MM core from 32b= it environment: mu_feature_mm_supv/MmSupervisorPkg/Drivers/MmPeiLaunchers/M= mIplX64Relay.inf at main =B7 microsoft/mu_feature_mm_supv (github.com). We can upstream it to edk2 if folks t= hink it will help. From: Ni, Ray > Sent: Thursday, August 8, 2024 1:15 AM To: devel@edk2.groups.io; Kun Qin > Cc: Wu, Jiaxin >; Tan, Dun = >; Xu, Wei6 >; Zhang, Hongbin1 >; Ni, Ray >; Kinney, Michael D > Subject: [EXTERNAL] Re: Proposing v3 of MM communicate buffer Kun, I like your proposed solution as it is backward compatible. But, I think the new PPI/Protocol is only useful when the CPU mode where PP= I/Protocol is produced does not match the CPU mode in MM. In X86, it could be: 32bit PEI + 64bit MM, 32bit DXE + 64bit MM, or vice ve= rsa. But I doubt the value of support these combinations in X86. Because th= at means the IPL (either PEI or DXE module) needs to support invoking MM Co= re in a different CPU mode. And the latest X86 platforms are switching to 64bit PEI + 64bit DXE + 64bit= MM. Does the proposal try to solve some ARM problem? Can you explain the necess= ity? I would like to avoid the complicated interfaces which do not solve a = practical problem. Thanks, Ray ________________________________ From: devel@edk2.groups.io > on behalf of Kun Qin via groups.io > Sent: Thursday, August 8, 2024 2:14 To: devel@edk2.groups.io > Subject: [edk2-devel] Proposing v3 of MM communicate buffer Hi all, I am trying to propose a change into PI spec and would like to gather some = feedback in this forum. Essentially, the current communicate header contains a UINTN field in place= , which is causing programing errors when trying to communicate the message between different operation m= ode (i.e. PEI in IA32 communicate into MM in x64). There are various implementations at large to = compensate for this size discrepancy through the edk2 codebase, thus fixing the existing commun= icate buffer definition will be less feasible. Thus I think proposing a new structure and implement= the corresponding header parser will be a simpler approach, which also allows a bit more flexibility= to inject new features/checks into the communication channel. The proposed change for the spec is detailed here: https://github.com/kuqin12/edk2/blob/BZ3398-MmCommunicate-Length-v4/CodeFir= st/BZ3430-SpecChange.md And the code first change is listed here: https://github.com/kuqin12/edk2/blob/BZ3398-MmCommunicate-Length-v4/ Could you please provide me with any feedback that you think might be helpf= ul for future usage of MM communicate? Any input is appreciated. Regards, Kun -=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 (#120317): https://edk2.groups.io/g/devel/message/120317 Mute This Topic: https://groups.io/mt/107775882/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_MN6PR11MB82446EEFB2BE6CD76B0A66B18C852MN6PR11MB8244namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Kun,
This PR (Mm infra by jiax= inwu =B7 Pull Request #5914) contains all standalone MM infra related c= ode in edk2 repo. Please take a look at if you are interested in it.

Back to your proposal, can we revisit it once there are platforms that want= to invoke 64bit MM env from 32bit PEI? I personally do not prefer to make = the interfaces complicated to support a platform that only exists in theory= .

+ Vincent for comments from PI spec perspective.

Thanks,
Ray
From: Kun Qin <Kun.Qin@m= icrosoft.com>
Sent: Friday, August 9, 2024 15:58
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io <devel= @edk2.groups.io>
Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Tan, Dun <dun.tan@int= el.com>; Xu, Wei6 <wei6.xu@intel.com>; Zhang, Hongbin1 <hongbin= 1.zhang@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>=
Subject: RE: Proposing v3 of MM communicate buffer
 

Hi Ray,

 

Your description is correct. I believe there are e= fforts trying to make Standalone MM launch in PEI happen? i.e. Add standalone mm i= pl pei driver by hongbin123 =B7 Pull Request #5236 =B7 tianocore/edk2 (gith= ub.com) will bring in support for #1 and #2. Thanks to Hongbin explaini= ng to me that such efforts are mainly targeting 64bit PEI. But I do not think it takes much more work to support= 32bit PEI + Standalone MM once this groundwork is done (again, we can help= upstream the code that supports #3 from Project MU if so desired 😊= ).

 

Moreover, just because there are no platforms in t= he public have such configuration, I would perceive it as a great opportuni= ty to introduce the new MM communicate header definition to prevent further= contamination from the old definition. In as the new platforms can setup MM foundation in PEI (32 or 64 bit, Inte= l or AMD) and communicate under the new definition of data structure and PP= I.

 

Please let me know your thoughts. Your feedback is= really appreciated!

 

Regards,

Kun

 

From: Ni, Ray <ray.ni@intel.c= om>
Sent: Thursday, August 8, 2024 8:48 PM
To: Kun Qin <Kun.Qin@microsoft.com>; devel@edk2.groups.io
Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Tan, Dun <dun.tan@int= el.com>; Xu, Wei6 <wei6.xu@intel.com>; Zhang, Hongbin1 <hongbin= 1.zhang@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>=
Subject: [EXTERNAL] Re: Proposing v3 of MM communicate buffer=

 

Kun,= thanks for explaining that ARM does not require this. 

&nbs= p;

IMO,= the proposal is only useful in X86 when:

* BI= OS uses standalone MM

* BI= OS launches standalone MM in PEI

* BI= OS PEI runs in 32bit mode

&nbs= p;

I do= not see any such platform in open source as the X86 standalone MM is not a= vailable yet in edk2 trunk.

&nbs= p;

Than= ks,

Ray<= /span>

From: = Kun Qin <Kun.Qin@microsoft.com<= /a>>
Sent: Friday, August 9, 2024 1:41
To: Ni, Ray <ray.ni@intel.com= >; devel@edk2.groups.io <devel@= edk2.groups.io>
Cc: Wu, Jiaxin <jiaxin.wu@= intel.com>; Tan, Dun <dun.ta= n@intel.com>; Xu, Wei6 <wei6= .xu@intel.com>; Zhang, Hongbin1 <hongbin1.zhang@intel.com>; Ni, Ray <ray.ni@intel.com>; = Kinney, Michael D <michael= .d.kinney@intel.com>
Subject: RE: Proposing v3 of MM communicate buffer

 

Hi Ray,

 

Thanks for your feedback. The ARM platforms I w= as exposed to have consistent operation mode is only AARCH64, so this propo= sal is not particularly attached to any ARM problem.

 

I agree that 32bit PEI/DXE communicate into MM = will have issue on x86 platforms as of today. But I have only heard Intel p= rocessors moving to support x64 PEI/DXE. I think introducing a new MM communicate header will help to prevent the issue to = propagate much further as it might take non-Intel x86 platforms years to fu= lly move away from 32bit PEI/DXE. Please let me know if you have any though= ts.

 

Regards,

Kun

 

P.S. Project MU have a thunking module that can= launch x64 MM core from 32bit environment: mu_feature_mm_supv/MmSupervisorPkg/Drivers/MmPeiLaunchers/MmIplX64Relay.inf= at main =B7 microsoft/mu_feature_mm_supv (github.com). We can upstream= it to edk2 if folks think it will help.

 

From: Ni, Ray <ray.ni@intel.com>
Sent: Thursday, August 8, 2024 1:15 AM
To: devel@edk2.groups.io= ; Kun Qin <Kun.Qin@microsoft.co= m>
Cc: Wu, Jiaxin <jiaxin.wu@= intel.com>; Tan, Dun <dun.ta= n@intel.com>; Xu, Wei6 <wei6= .xu@intel.com>; Zhang, Hongbin1 <hongbin1.zhang@intel.com>; Ni, Ray <ray.ni@intel.com>; = Kinney, Michael D <michael= .d.kinney@intel.com>
Subject: [EXTERNAL] Re: Proposing v3 of MM communicate buffer=

 

Kun= ,

I l= ike your proposed solution as it is backward compatible.

&nb= sp;

But= , I think the new PPI/Protocol is only useful when the CPU mode where PPI/P= rotocol is produced does not match the CPU mode in MM.

&nb= sp;

In = X86, it could be: 32bit PEI + 64bit MM, 32bit DXE + 64bit MM, or vice versa= . But I doubt the value of support these combinations in X86. Because that = means the IPL (either PEI or DXE module) needs to support invoking MM Core in a different CPU mode.

And= the latest X86 platforms are switching to 64bit PEI + 64bit DXE + 64bit MM= .

&nb= sp;

Doe= s the proposal try to solve some ARM problem? Can you explain the necessity= ? I would like to avoid the complicated interfaces which do not solve a pra= ctical problem.

&nb= sp;

Tha= nks,

Ray=

&nb= sp;

From:=  devel@edk2.groups.io= <devel@edk2.groups.io<= /span>> on behalf of Kun Qin via groups.io <Kun.Qin= =3Dmicrosoft.com@groups.io>
Sent: Thursday, August 8, 2024 2:14
To: devel@edk= 2.groups.io <devel@edk2.groups.io>
Subject: [edk2-devel] Proposing v3 of MM communicate buffer

 

Hi all,

 

I am trying to propose a change into PI spec and would like to gather = some feedback in this forum.

 

Essentially, the current communicate header contains a UINTN field in = place, which is causing programing

errors when trying to communicate the message between different operat= ion mode (i.e. PEI in IA32

communicate into MM in x64). There are various implementations at larg= e to compensate for this

size discrepancy through the edk2 codebase, thus fixing the existing c= ommunicate buffer definition

will be less feasible. Thus I think proposing a new structure and impl= ement the corresponding header

parser will be a simpler approach, which also allows a bit more flexib= ility to inject new features/checks

into the communication channel.

 

The proposed change for the spec is detailed here:

https://github.com/= kuqin12/edk2/blob/BZ3398-MmCommunicate-Length-v4/CodeFirst/BZ3430-SpecChang= e.md

 

And the code first change is listed here:

https://github.com/ku= qin12/edk2/blob/BZ3398-MmCommunicate-Length-v4/

 

Could you please provide me with any feedback that you think might be = helpful for future usage of MM

communicate? Any input is appreciated.

 

Regards,

Kun

 

_._,_._,_
Groups.io Links:

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

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

_._,_._,_
--_000_MN6PR11MB82446EEFB2BE6CD76B0A66B18C852MN6PR11MB8244namp_--