public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Kun Qin via groups.io" <Kun.Qin=microsoft.com@groups.io>
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@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: [edk2-devel] Proposing v3 of MM communicate buffer
Date: Thu, 8 Aug 2024 17:41:48 +0000	[thread overview]
Message-ID: <BL1PR21MB3160535474514AF6B7A9144EE9B92@BL1PR21MB3160.namprd21.prod.outlook.com> (raw)
In-Reply-To: <MN6PR11MB8244D9A826CC54507A9A433A8CB92@MN6PR11MB8244.namprd11.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 4211 bytes --]

Hi Ray,

Thanks for your feedback. The ARM platforms I was exposed to have consistent operation mode is only AARCH64, so this proposal 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 processors 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 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 32bit environment: mu_feature_mm_supv/MmSupervisorPkg/Drivers/MmPeiLaunchers/MmIplX64Relay.inf at main * microsoft/mu_feature_mm_supv (github.com)<https://github.com/microsoft/mu_feature_mm_supv/blob/main/MmSupervisorPkg/Drivers/MmPeiLaunchers/MmIplX64Relay.inf>. 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.com>
Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Tan, Dun <dun.tan@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 like your proposed solution as it is backward compatible.

But, I think the new PPI/Protocol is only useful when the CPU mode where PPI/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 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.

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 practical problem.

Thanks,
Ray

________________________________
From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> on behalf of Kun Qin via groups.io <Kun.Qin=microsoft.com@groups.io<mailto:Kun.Qin=microsoft.com@groups.io>>
Sent: Thursday, August 8, 2024 2:14
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto: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 mode (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 communicate 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/CodeFirst/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 helpful for future usage of MM

communicate? Any input is appreciated.



Regards,

Kun





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120307): https://edk2.groups.io/g/devel/message/120307
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]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 13836 bytes --]

  reply	other threads:[~2024-08-09  6:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-07 18:14 [edk2-devel] Proposing v3 of MM communicate buffer Kun Qin via groups.io
2024-08-07 20:25 ` Kun Qin via groups.io
2024-08-08  8:14 ` Ni, Ray
2024-08-08 17:41   ` Kun Qin via groups.io [this message]
2024-08-09  3:47     ` Ni, Ray
2024-08-09  7:58       ` Kun Qin via groups.io
2024-08-12  5:50         ` Ni, Ray
2024-08-12 19:07           ` Kun Qin via groups.io

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BL1PR21MB3160535474514AF6B7A9144EE9B92@BL1PR21MB3160.namprd21.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox