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 71527AC09F4 for ; Fri, 9 Aug 2024 03:47:53 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=o+xif0/xSTHTXYjwADwFVTFf8RMjDDfgiMsRpc4RC1s=; 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=1723175273; v=1; b=YiEVtEfqEL3DwLFFBHguRzcnhEBnPDu2cUCBN52rv66IZNW8X2uEVTaWF4Nt/v9O+cGMO6em uQs8Xx5tdE8KReI4tXS+tBkL+JpcPUkGbPB4Sn2BfFvpTQWvYrEPc+blKNeC0OeEX86fKaZ/Hwt pM0uThzojwxqXAyfWdILW13OzhtYN54wuphXAnY94LTpdb7cb7UeMBO1JT0NkOvlAIYWk/Jcm9S LWF4VwF+wLolnRRF5akF5VFz/sj5titcUWMvoeYfq5AxZTnAoYEDARNLJft0STAiVIUEpnLvnD7 90PmO9GzmVhNudt+t+V6owc48FTHzsiP4SoWguRLwvLuA== X-Received: by 127.0.0.2 with SMTP id 2fKHYY7687511xa1f9k5PyAb; Thu, 08 Aug 2024 20:47:51 -0700 X-Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) by mx.groups.io with SMTP id smtpd.web10.76800.1723175265779931673 for ; Thu, 08 Aug 2024 20:47:45 -0700 X-CSE-ConnectionGUID: pbyYLx7eS2Wigxja0R8jaw== X-CSE-MsgGUID: ITThf9RWRBmmkaLc3uRZ2A== X-IronPort-AV: E=McAfee;i="6700,10204,11158"; a="21217329" X-IronPort-AV: E=Sophos;i="6.09,275,1716274800"; d="scan'208,217";a="21217329" X-Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2024 20:47:45 -0700 X-CSE-ConnectionGUID: tcEjWvb3RVe93g6H2PS3wQ== X-CSE-MsgGUID: rVdS/NjVTEaFOYY4P1542w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,275,1716274800"; d="scan'208,217";a="61558379" X-Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmviesa003.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 08 Aug 2024 20:47:45 -0700 X-Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 Aug 2024 20:47:44 -0700 X-Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 Aug 2024 20:47:44 -0700 X-Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Thu, 8 Aug 2024 20:47:44 -0700 X-Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.41) 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.2507.39; Thu, 8 Aug 2024 20:47:44 -0700 X-Received: from MN6PR11MB8244.namprd11.prod.outlook.com (2603:10b6:208:470::14) by SN7PR11MB7511.namprd11.prod.outlook.com (2603:10b6:806:347::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7828.31; Fri, 9 Aug 2024 03:47:34 +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; Fri, 9 Aug 2024 03:47:34 +0000 From: "Ni, Ray" To: Kun Qin , "devel@edk2.groups.io" CC: "Wu, Jiaxin" , "Tan, Dun" , "Xu, Wei6" , "Zhang, Hongbin1" , "Kinney, Michael D" Subject: Re: [edk2-devel] Proposing v3 of MM communicate buffer Thread-Topic: Proposing v3 of MM communicate buffer Thread-Index: Adro6QAPLf/WRMT7RNuaRkedI6TpYwAgLKmVABOn43AAFYpekQ== Date: Fri, 9 Aug 2024 03:47:34 +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_|SN7PR11MB7511:EE_ x-ms-office365-filtering-correlation-id: fcfadb7c-d411-4af8-739a-08dcb8260110 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam-message-info: =?iso-8859-1?Q?Gt0vh+ad5g8ofwRxtMEqwMXi5jEhbf3jbOb8w68W5hjjZ1mZCJTqRZXK+b?= =?iso-8859-1?Q?GDmHiRiUs/KBhZhiykHRc+VBIzjrTG2p8QBaZVy/JhruuB1pt7igb24hUH?= =?iso-8859-1?Q?jBJdjJYtao4kUkWKG5TdN3qx8mGYV+5miu6S2tA2/ZcTCfCJ4RExCz4S6J?= =?iso-8859-1?Q?LY3PbU/OzkcfujjL7AC0CuKjdDV40XfDWVwox6EzbKCLCbLo0yJVFeS5jQ?= =?iso-8859-1?Q?HqhK+/Zf7/BVEt3XFdHTd6SXgDxV9gNKzKSFJbbZMwwBfpBdFiipvLb3y+?= =?iso-8859-1?Q?thm/COpv+OCfeIt9jQw40X8FtcBpYqpZqBwXQq/MRJLCv9+C/5ywOeG50n?= =?iso-8859-1?Q?pXji6xz0616lfW05l9IHS4F0cs4SKp4ZqR2kOQwZIYjrOyKvy6kq47RwO5?= =?iso-8859-1?Q?fxoWq9CjA6unAVIYauGPCAvuhDX/DCsb3DmirsMqRuevrQ/d7sIaE6gQoW?= =?iso-8859-1?Q?6a+u9G0TyciJW8FguZR4mNCoekU/39IecY9ewWkwomD0mKmIXtsbbZ/I/N?= =?iso-8859-1?Q?L19WRDOGCK89DNi/7F5HGbReniCV/d8eJqeMui7vS6FW3HnESpedoRf840?= =?iso-8859-1?Q?Yw+NP4PDVUpt0r0ahcMhDkIRRRh+R0zzow+Ef23Kd+3jSMY1Og6hq/+sUQ?= =?iso-8859-1?Q?3xc8TVyeLtMq4bF8oijvweu6M0mzuhLepte2Qq+4SVxGAmneBq8e9yDEXC?= =?iso-8859-1?Q?TU+hWHtiv5StHNJSxp1xfyfDru44r7eYN8S+cB5YvSlGl+ov5+rjZBlyom?= =?iso-8859-1?Q?JfKF2aml1gWXKLCSY8zvd/HET/ml9WGaG5kewh1CH5JkAUrmuOgZAAKZvP?= =?iso-8859-1?Q?8RnehoGHu4MiSk88nlcYeqq+rq607qewOerF4+daVcPRn8sxumnacPEItR?= =?iso-8859-1?Q?A5JDCv3z3b95K/VbKFiu63mx84z8lYm9jwd83u2u+ETcGyv8lnUFCGUPWp?= =?iso-8859-1?Q?X0Y0Zu8XOtfsZinAza/7t05QrqBJq4RE8mpxFC52ReWZg/eJfx1svPHN2L?= =?iso-8859-1?Q?8uAW1H/ZK6IC+W9o+9jcXL5/iKwIxP6yCA/KMT5YXngi/rwkdCfFwdzZW7?= =?iso-8859-1?Q?31m+QhjvW7Q/N2OvQCg5B/3L5x9KizPO5u6STUoHbY39tbtgcPa3oWUFCY?= =?iso-8859-1?Q?JZNnc2EtST7HIHXN1TAKdZT5q1f37GvxLvGIvvYGm2NTnJHx//XolGwTsg?= =?iso-8859-1?Q?OGVEBPWI1AAiDTcUvxdnGWnMTYn+jxGych3Vjze9/ejGo80A3x61786Kop?= =?iso-8859-1?Q?grPBqHciwQck3j2YNWowCp6235hKjzo0xdup4zg1m/Mtpiib5KkFEYvRT6?= =?iso-8859-1?Q?8L0SAnQDr3SAnFb6/BfpOHggC8U5h5MtUuRY20K3z7V5hcL6tsJKFJxeCq?= =?iso-8859-1?Q?B6Y2whk+K700E87kefRHrzxJoHbXrtF2bJtOU9N9WQL8gOG7m+9rw=3D?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?BZuuogswHWCPkX6OsxRa/rB4Hp1qjwT1OhWX4JBi03jK58DAAIrQXSaLQl?= =?iso-8859-1?Q?gtGNfJfZTkVDOwLkDnme0uvoGKEszBo7FpgbBjsBTHp4iGuMlMSLbyWRgk?= =?iso-8859-1?Q?iOXkILyt49xe1MiFAk65vJIYJ2HX3KRg1qeg5BV/jYIcmq/PSa6L1ABbFr?= =?iso-8859-1?Q?oPmB6SB0xbZqRIqN9QI0XLxAeeTpDF9Y1bpAZg9eNrWXii/tjqBoges08S?= =?iso-8859-1?Q?PBGyEqPE3qLEeFy2RsVLKaPOEz4rDqPAKr9V/DoYx5Q+fabETZml25bN3Z?= =?iso-8859-1?Q?CNztAOTPY8ttczPoCQsYOlK8+HE9+T+JeQgbJbCwdOppLEiqJqTyOltBIK?= =?iso-8859-1?Q?gu4hR8CVyaVM4J2eepuvjjv6XoPjF3pQdthEzGUIaWs3xyDAWy0YlG18Bm?= =?iso-8859-1?Q?ntiuu2XXMk/poADI/TtOwx0EmDjwgCpOLRHbE/GBYtqTEVy3XYX/gUQM7V?= =?iso-8859-1?Q?q+Ol039iqbEye+44Km0pG7GmFT+RYtsSTXaGqcQIh0GFQ+AWpRCjK9uDvc?= =?iso-8859-1?Q?XCiljwEterON9xzlcCUuVzznI07U8wOa1XhX0lm9Vnpc2/biKUdiUANXl6?= =?iso-8859-1?Q?BniyOxLao+FLZ8Lo73WutoSTXWlEDGCS3P0NNZPJ7am9Rmqc89uklVJfAi?= =?iso-8859-1?Q?W6VltSzGwWfQh9HvlLxeHjiHr4v3SVk/bPsNFRyY34sLKFCauGpCSion/i?= =?iso-8859-1?Q?lysAHXwQlU+xv4Zy3+hcMMi+rUwbw9Xe/I2SL3vhRRmEIVK8aJCNTOMNHt?= =?iso-8859-1?Q?LBfc/YeRw8z4cnfTwxeDE4dbKQLExd+LkmFvhgRTF+XY3y/7uGTHz3lHtu?= =?iso-8859-1?Q?vnBZG8RZsRQp4mYoxK5CjI0BpIZx4vbjWxRjkii7xrAxli6s5jFhjWj2C/?= =?iso-8859-1?Q?gEWBhWT/AYEcd+KYzjhOlpRKrRnE8zzPOxYW+cWE3HRzR2wjN0o/vRUWmH?= =?iso-8859-1?Q?/B+evIJin4QGHYy6p6nzi3kbgI+9KCnByXkRwlwY31kgcL42xsTsbhj29b?= =?iso-8859-1?Q?iHbZ5UoKGCsuKzlNOK6Tg528IbNtpOw7JAsrZktQA8YVnnkv2hFdg1+ork?= =?iso-8859-1?Q?58MrCY+/59sz1JXPDVe7khiXnch0OYHP/s63aBERaQie0NIguj5IQddl50?= =?iso-8859-1?Q?V6A2GMdJBY7KpQlplPqO5GEIoIR3D5wID7cYhQpciMgzFudZ6dLNEfhY1k?= =?iso-8859-1?Q?1X992qURstdbfjw3KPvwB9AfdvfIoPVXz+4c0+m7aFEevaTVZ5ImiIw6Bg?= =?iso-8859-1?Q?2lgFTMSUdJN26oq2mRVYUJy06k+31TFMqzWZFQAXViaXgqF7xtNtgQX1xJ?= =?iso-8859-1?Q?FORfLo+/JYLDVc0k0eo4A0PwLm08KrPp787tjPNMOa/A0NzN6t3ET28wzI?= =?iso-8859-1?Q?seMa2+LKUTQAzgf/8W59nHMJJXlWQX5MKQs1FD4MlysOg+m0U7jyW0zO/z?= =?iso-8859-1?Q?dLBd8zxsaos91hGCEe4eNj/YhyyCFdPOe/itcGFjBgLqpDRnB+u1nyqPIs?= =?iso-8859-1?Q?jPAutOFT2nFtFORgnPHhT1qj5NdctA9r0s2NHLsovcy9trlv0SUrRaaIDr?= =?iso-8859-1?Q?oXhTmZn2NWaaYrnvvfo8nLT2tyMnUjXopcNiF0b5cPY+738HtN1BjRKNF9?= =?iso-8859-1?Q?eVBhotEAdo5/A=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: fcfadb7c-d411-4af8-739a-08dcb8260110 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2024 03:47:34.5453 (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: Cvdihq6Ox3ZfJ8tLeI8EOmAwBrS3qUmD0xTNLrw1JolRIdXYIkIh8teE9T5A+5DY9c2jk3eOK4vI1uMP6aI49w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB7511 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: Thu, 08 Aug 2024 20:47:45 -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: VSXP5Nz5vKf5MUw5QncYiB38x7686176AA= Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MN6PR11MB8244CA42EAA65265B495D05B8CBA2MN6PR11MB8244namp_" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=YiEVtEfq; 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_MN6PR11MB8244CA42EAA65265B495D05B8CBA2MN6PR11MB8244namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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, Wei= 6 ; 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, Wei= 6 ; 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 (#120304): https://edk2.groups.io/g/devel/message/120304 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_MN6PR11MB8244CA42EAA65265B495D05B8CBA2MN6PR11MB8244namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
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 <Kun.Qin@m= icrosoft.com>
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.tan@int= el.com>; Xu, Wei6 <wei6.xu@intel.com>; Zhang, Hongbin1 <hongbin= 1.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 wa= s exposed to have consistent operation mode is only AARCH64, so this propos= al is not particularly attached to any ARM problem.

 

I agree that 32bit PEI/DXE communicate into MM w= ill have issue on x86 platforms as of today. But I have only heard Intel pr= ocessors 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.c= om>
Sent: Thursday, August 8, 2024 1:15 AM
To: devel@edk2.groups.io; Kun Qin <Kun.Qin@microsoft.com>
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>; 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 li= ke your proposed solution as it is backward compatible.

&nbs= p;

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

&nbs= p;

In X= 86, 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 m= eans 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.=

&nbs= p;

Does= 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 prac= tical problem.

&nbs= p;

Than= ks,

Ray<= /span>

&nbs= p;

From:&= nbsp;devel@edk2.groups.io<= /span> <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/kuq= in12/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 (#120304) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--_000_MN6PR11MB8244CA42EAA65265B495D05B8CBA2MN6PR11MB8244namp_--