Rebase the patch and fix the uncrustify.

Reference: https://github.com/abdattar/edk2/tree/smbios_3_5_0_v2

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>

Abdul Lateef Attar (1):
MdePkg/Include: Smbios Specification 3.5.0 changes

MdePkg/Include/IndustryStandard/SmBios.h | 144 +++++++++++++++++++-
1 file changed, 140 insertions(+), 4 deletions(-)

--
2.25.1

Hi,

tianocore doesn't use interrupts (other than timer).

Yes I realized that by diving into the code. I can see microvm using
the Xen timer while OvmfPkgX64 uses 8254 PIT.

Min, what happened to the patch series changing that?

(the plan is to always use the lapci except when compiling with csm
enabled because pit/pic support is needed for backward compatibility
reasons then).

take care,
Gerd

On Fri, 2022-01-07 at 13:17 +0100, kraxel@... wrote:

On Thu, Jan 06, 2022 at 02:21:59PM +0000, Boeuf, Sebastien wrote:

On Wed, 2022-01-05 at 17:55 +0100, kraxel@... wrote:

On Wed, Jan 05, 2022 at 01:44:01PM +0000, Boeuf, Sebastien wrote:

Ah nevermind I found out QEMU was installed from packaging.

On ubuntu.

We don't have packages for Cloud Hypervisor, but we can
download
a static binary from a specific release, do you think that
would be
acceptable?

As far I know the same happens for qemu on windows,
so that should be fine.

Cool!

BTW, about microvm, I saw that you're skipping QEMU, so does that
mean
you're not *really* testing that OVMF works with microvm, or am I
missing something?

Correct, not tested right now.  The code needs some improvements,
it's
not flexible enough, havn't found the time to do that yet.  Also have
to check whenever the qemu version shipped by ubuntu is new enough to
actually have microvm support ...

Okay thanks for your confirmation, that makes sense :)

take care,
  Gerd

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

On Fri, 2022-01-07 at 13:07 +0100, kraxel@... wrote:

  Hi,

microvm has no lpc bridge, so I had to do it in a different way
...

Cloud Hypervisor doesn't emulate any LPC bridge or ISA bus.

Ok, doing it microvm-style makes sense then.

Ok thanks for the confirmation. Hopefully it won't conflict with what
QEMU uses/needs.

Works fine for me.

qemu-system-x86_64 -nographic -machine microvm,rtc=on -bios
Build/MicrovmX64/DEBUG_GCC5/FV/MICROVM.fd

Thanks for the confirmation, something might be wrong with the
interrupt used for my serial device.

tianocore doesn't use interrupts (other than timer).

Yes I realized that by diving into the code. I can see microvm using
the Xen timer while OvmfPkgX64 uses 8254 PIT.

Cloud Hypervisor only has an IOAPIC, it doesn't rely on any PIC,
which
is why I'm not sure what might be missing to get the EFI shell to
receive the interrupts.

PIC is optional for microvm too, and everything works fine for me
with
"-machine microvm,rtc=on,pic=off,pit=off"

Yes that's interesting and after some investigations I think the
problem is that I don't get TerminalConInTimerHandler handler to be
triggered. I can see the handler is correctly registered but for some
reasons, it's never used. I'm wondering if that might be an issue
related to a lack of timer support. Especially I see the UEFI service
SetTimer() is being used for the polling mechanism, so I wonder what is
the backend for it.

take care,
  Gerd

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

On Thu, Jan 06, 2022 at 02:21:59PM +0000, Boeuf, Sebastien wrote:

On Wed, 2022-01-05 at 17:55 +0100, kraxel@... wrote:

On Wed, Jan 05, 2022 at 01:44:01PM +0000, Boeuf, Sebastien wrote:

Ah nevermind I found out QEMU was installed from packaging.

On ubuntu.

We don't have packages for Cloud Hypervisor, but we can download
a static binary from a specific release, do you think that would be
acceptable?

As far I know the same happens for qemu on windows,
so that should be fine.

Cool!

BTW, about microvm, I saw that you're skipping QEMU, so does that mean
you're not *really* testing that OVMF works with microvm, or am I
missing something?

Correct, not tested right now. The code needs some improvements, it's
not flexible enough, havn't found the time to do that yet. Also have
to check whenever the qemu version shipped by ubuntu is new enough to
actually have microvm support ...

take care,
Gerd

Hi,

microvm has no lpc bridge, so I had to do it in a different way ...

Cloud Hypervisor doesn't emulate any LPC bridge or ISA bus.

Ok, doing it microvm-style makes sense then.

Works fine for me.

qemu-system-x86_64 -nographic -machine microvm,rtc=on -bios
Build/MicrovmX64/DEBUG_GCC5/FV/MICROVM.fd

Thanks for the confirmation, something might be wrong with the
interrupt used for my serial device.

tianocore doesn't use interrupts (other than timer).

Cloud Hypervisor only has an IOAPIC, it doesn't rely on any PIC, which
is why I'm not sure what might be missing to get the EFI shell to
receive the interrupts.

PIC is optional for microvm too, and everything works fine for me with
"-machine microvm,rtc=on,pic=off,pit=off"

take care,
Gerd

Chanage the name "Uiapp" to "Enter Setup".

Cc: Guo Dong <guo.dong@...>
Cc: Ray Ni <ray.ni@...>
Cc: Maurice Ma <maurice.ma@...>
Cc: Benjamin You <benjamin.you@...>
Signed-off-by: Yuanhao Xie <yuanhao.xie@...>
---
UefiPayloadPkg/UefiPayloadPkg.fdf | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf b/UefiPayloadPkg/UefiPayloadPkg.fdf
index f619a23139..0928e72007 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.fdf
+++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
@@ -104,7 +104,7 @@ INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
!endif
INF UefiCpuPkg/CpuDxe/CpuDxe.inf
INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
-INF MdeModulePkg/Application/UiApp/UiApp.inf
+INF RuleOverride = UI MdeModulePkg/Application/UiApp/UiApp.inf
INF MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf
INF PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.inf
INF MdeModulePkg/Universal/Metronome/Metronome.inf
@@ -357,3 +357,11 @@ INF ShellPkg/Application/Shell/Shell.inf
FILE RAW = $(NAMED_GUID) {
RAW RAW |.raw
}
+
+[Rule.Common.UEFI_APPLICATION.UI]
+ FILE APPLICATION = $(NAMED_GUID) {
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="Enter Setup"
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
\ No newline at end of file
--
2.30.0.windows.1

Reviewed-by: Liming Gao <gaoliming@...>

This version has been merged into edk2.

Thanks
Liming

-----邮件原件-----
发件人: Chu, Maggie <maggie.chu@...>
发送时间: 2022年1月5日 18:37
收件人: devel@edk2.groups.io; Chu, Maggie <maggie.chu@...>
抄送: Gao, Liming <gaoliming@...>; Kinney, Michael D
<michael.d.kinney@...>; Liu, Zhiguang <zhiguang.liu@...>
主题: RE: [edk2-devel] [PATCH v3] MdePkg: Add registers of boot partition
feature

Created PR for the patch : https://github.com/tianocore/edk2/pull/2361

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Maggie
Chu
Sent: Wednesday, January 5, 2022 6:35 PM
To: devel@edk2.groups.io
Cc: Gao, Liming <gaoliming@...>; Kinney, Michael D
<michael.d.kinney@...>; Liu, Zhiguang <zhiguang.liu@...>
Subject: [edk2-devel] [PATCH v3] MdePkg: Add registers of boot partition
feature

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3757

Add registers of boot partition feature which defined in NVM Express 1.4

Spec

Cc: Liming Gao <gaoliming@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Signed-off-by: Maggie Chu <maggie.chu@...>
---
MdePkg/Include/IndustryStandard/Nvme.h | 108
++++++++++++++++++++-----
1 file changed, 89 insertions(+), 19 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Nvme.h
b/MdePkg/Include/IndustryStandard/Nvme.h
index 7d4aee9dc8..4a1d92c45d 100644
--- a/MdePkg/Include/IndustryStandard/Nvme.h
+++ b/MdePkg/Include/IndustryStandard/Nvme.h
@@ -2,11 +2,12 @@
Definitions based on NVMe spec. version 1.1. (C) Copyright 2016
Hewlett Packard Enterprise Development LP<BR>- Copyright (c) 2017, Intel
Corporation. All rights reserved.<BR>+ Copyright (c) 2017 - 2021, Intel
Corporation. All rights reserved.<BR> SPDX-License-Identifier:
BSD-2-Clause-Patent @par Specification Reference: NVMe
Specification 1.1+ NVMe Specification 1.4 **/ @@ -18,18 +19,21 @@
// // controller register offsets //-#define NVME_CAP_OFFSET 0x0000
// Controller Capabilities-#define NVME_VER_OFFSET 0x0008
// Version-#define NVME_INTMS_OFFSET 0x000c // Interrupt
Mask Set-#define NVME_INTMC_OFFSET 0x0010 // Interrupt
Mask Clear-#define NVME_CC_OFFSET 0x0014 // Controller
Configuration-#define NVME_CSTS_OFFSET 0x001c // Controller
Status-#define NVME_NSSR_OFFSET 0x0020 // NVM Subsystem
Reset-#define NVME_AQA_OFFSET 0x0024 // Admin Queue
Attributes-#define NVME_ASQ_OFFSET 0x0028 // Admin
Submission Queue Base Address-#define NVME_ACQ_OFFSET 0x0030
// Admin Completion Queue Base Address-#define NVME_SQ0_OFFSET
0x1000 // Submission Queue 0 (admin) Tail Doorbell-#define
NVME_CQ0_OFFSET 0x1004 // Completion Queue 0 (admin)
Head Doorbell+#define NVME_CAP_OFFSET 0x0000 //
Controller Capabilities+#define NVME_VER_OFFSET 0x0008 //
Version+#define NVME_INTMS_OFFSET 0x000c // Interrupt
Mask Set+#define NVME_INTMC_OFFSET 0x0010 // Interrupt
Mask Clear+#define NVME_CC_OFFSET 0x0014 // Controller
Configuration+#define NVME_CSTS_OFFSET 0x001c //
Controller Status+#define NVME_NSSR_OFFSET 0x0020 // NVM
Subsystem Reset+#define NVME_AQA_OFFSET 0x0024 //
Admin Queue Attributes+#define NVME_ASQ_OFFSET 0x0028
// Admin Submission Queue Base Address+#define NVME_ACQ_OFFSET
0x0030 // Admin Completion Queue Base Address+#define
NVME_BPINFO_OFFSET 0x0040 // Boot Partition
Information+#define NVME_BPRSEL_OFFSET 0x0044 // Boot
Partition Read Select+#define NVME_BPMBL_OFFSET 0x0048 //
Boot Partition Memory Buffer Location+#define NVME_SQ0_OFFSET
0x1000 // Submission Queue 0 (admin) Tail Doorbell+#define
NVME_CQ0_OFFSET 0x1004 // Completion Queue 0 (admin)
Head Doorbell // // These register offsets are defined as 0x1000 + (N *

(4 <<

CAP.DSTRD))@@ -51,11 +55,14 @@ typedef struct {
UINT8 To; // Timeout UINT16 Dstrd : 4; UINT16
Nssrs : 1; // NVM Subsystem Reset Supported NSSRS- UINT16
Css : 4; // Command Sets Supported - Bit 37- UINT16 Rsvd3 : 7;+
UINT16 Css : 8; // Command Sets Supported - Bit 37+ UINT16
Bps : 1; // Boot Partition Support - Bit 45 in NVMe1.4+ UINT16
Rsvd3 : 2; UINT8 Mpsmin : 4; UINT8 Mpsmax : 4;-
UINT8 Rsvd4;+ UINT8 Pmrs : 1;+ UINT8 Cmbs :
1;+ UINT8 Rsvd4 : 6; } NVME_CAP; //@@ -115,7 +122,36 @@
typedef struct {
#define NVME_ACQ UINT64 //-// 3.1.11 Offset (1000h + ((2y) * (4 <<
CAP.DSTRD))): SQyTDBL - Submission Queue y Tail Doorbell+// 3.1.13 Offset
40h: BPINFO - Boot Partition Information+//+typedef struct {+ UINT32
Bpsz : 15; // Boot Partition Size+ UINT32 Rsvd1 : 9;+ UINT32
Brs : 2; // Boot Read Status+ UINT32 Rsvd2 : 5;+ UINT32
Abpid : 1; // Active Boot Partition ID+} NVME_BPINFO;++//+// 3.1.14

Offset

44h: BPRSEL - Boot Partition Read Select+//+typedef struct {+ UINT32
Bprsz : 10; // Boot Partition Read Size+ UINT32 Bprof : 20; // Boot
Partition Read Offset+ UINT32 Rsvd1 : 1;+ UINT32 Bpid : 1;
// Boot Partition Identifier+} NVME_BPRSEL;++//+// 3.1.15 Offset 48h:
BPMBL - Boot Partition Memory Buffer Location (Optional)+//+typedef struct
{+ UINT64 Rsvd1 : 12;+ UINT64 Bmbba : 52; // Boot Partition
Memory Buffer Base Address+} NVME_BPMBL;++//+// 3.1.25 Offset (1000h +
((2y) * (4 << CAP.DSTRD))): SQyTDBL - Submission Queue y Tail Doorbell //
typedef struct { UINT16 Sqt;@@ -353,7 +389,7 @@ typedef struct {
UINT8 Avscc; /* Admin Vendor Specific Command
Configuration */ UINT8 Apsta; /* Autonomous Power
State Transition Attributes */ //- // Below fields before Rsvd2 are
defined in NVM Express 1.3 Spec+ // Below fields before Rsvd2 are defined
in NVM Express 1.4 Spec // UINT16 Wctemp;
/* Warning Composite Temperature Threshold */ UINT16
Cctemp; /* Critical Composite Temperature Threshold */@@ -361,7
+397,12 @@ typedef struct {
UINT32 Hmpre; /* Host Memory Buffer
Preferred Size */ UINT32 Hmmin; /* Host
Memory Buffer Minimum Size */ UINT8 Tnvmcap[16];
/* Total NVM Capacity */- UINT8 Rsvd2[216]; /*
Reserved as of NVM Express */+ UINT8 Unvmcap[16];
/* Unallocated NVM Capacity */+ UINT32 Rpmbs;
/* Replay Protected Memory Block Support */+ UINT16
Edstt; /* Extended Device Self-test Time */+ UINT8
Dsto; /* Device Self-test Options */+ UINT8
Fwug; /* Firmware Update Granularity */+ UINT8
Rsvd2[192]; /* Reserved as of Nvm Express 1.4 Spec */ // // NVM
Command Set Attributes //@@ -433,6 +474,34 @@ typedef struct {
UINT8 VendorData[3712]; /* Vendor specific data */ }
NVME_ADMIN_NAMESPACE_DATA; +//+// RPMB Device Configuration Block
Data Structure as of Nvm Express 1.4 Spec+//+typedef struct {+ UINT8
Bppe; /* Boot Partition Protection Enable */+ UINT8 Bpl;
/* Boot Partition Lock */+ UINT8 Nwpac; /* Namespace Write
Protection Authentication Control */+ UINT8 Rsvd1[509]; /* Reserved
as of Nvm Express 1.4 Spec */+}
NVME_RPMB_CONFIGURATION_DATA;++#define
RPMB_FRAME_STUFF_BYTES 223++//+// RPMB Data Frame as of Nvm
Express 1.4 Spec+//+typedef struct {+ UINT8
Sbakamc[RPMB_FRAME_STUFF_BYTES]; /* [222-N:00] Stuff Bytes */+
/* [222:222-(N-1)] Authentication Key or Message Authentication Code (MAC)
*/+ UINT8 Rpmbt; /* RPMB Target
*/+ UINT64 Nonce[2];+ UINT32 Wcounter;
/* Write Counter */+ UINT32 Address;
/* Starting address of data to be programmed to or read from the RPMB. */+
UINT32 Scount; /* Sector Count */+
UINT16 Result;+ UINT16 Rpmessage;
/* Request/Response Message */+ // UINT8 *Data;
/* Data to be written or read by signed access where M = 512 * Sector

Count.

*/+} NVME_RPMB_DATA_FRAME;+ // // NvmExpress Admin Identify Cmd
//@@ -564,6 +633,7 @@ typedef struct {
#define LID_ERROR_INFO 0x1 #define LID_SMART_INFO 0x2
#define LID_FW_SLOT_INFO 0x3+ #define LID_BP_INFO 0x15
UINT32 Rsvd1 : 8; UINT32 Numd : 12; /* Number of
Dwords */ UINT32 Rsvd2 : 4; /* Reserved as of Nvm Express
1.1 Spec */--
2.26.2.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85283): https://edk2.groups.io/g/devel/message/85283
Mute This Topic: https://groups.io/mt/88211217/1807365
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [maggie.chu@...]
-=-=-=-=-=-=

Hi,

+#define FW_CFG_NX_STACK_ITEM "opt/ovmf/PcdSetNxForStack"

Why this is needed?

+//
+// Values we program into the PM base address registers //
+#define PIIX4_PMBA_VALUE 0xB000
+#define ICH9_PMBASE_VALUE 0x0600

They are in OvmfPkg/Include/OvmfPlatforms.h, no need to copy them over.

+VOID
+PciExBarInitialization (

+VOID
+MiscInitialization (

Cut+Paste from PlatformPei

Please refactor the code (move the functions needed to a Library?) so we
don't have multiple copies of the setup code.

As we're discussing the PlatformInitLib (which wraps the functions in PlatformPei), SecPlatformLibQemuTdx is deprecated.

Thanks
Min

On January 3, 2022 4:02 PM, Gerd Hoffmann wrote:

PCDs cannot be set in SEC phase, so the values should be saved in a
Hob (for example, PLATFORM_INFO_HOB). In early DXE phase these values
are set to the PCDs. This is how TdxDxe does today.

Other tasks can be done in SEC phase. I think there should be a lib
(for example, PlatformPeiLib) to wrap these functions so that they can
be re-used by OvmfPkg/PlatformPei.

Yes, I think we need a PlatformLib for the platform initialization code. With
PEI we would simply link the lib into PlatformPei, without PEI we would link
parts of the lib into SEC and parts of the lib into DXE.

After carefully study the PlatformPei code and a quick PoC (PlatformInitLib which wraps the basic functions in PlatformPei), I found it's not a easy task for such a lib which can be used in both PlatformPei and Pei-less boot.
1. PlatformInitLib should work both in SEC and PEI. So it cannot use global variables between different functions. mHostBridgeDevId and mPhysMemAddressWidth are the examples. So these variables must be provided by the caller thru the input function parameters.
2. PlatformInitLib cannot set PCDs in the code. So a Guid hob should be created to store the PCDs and pass them to DXE phase. Then these PCDs will be set at the very beginning of DXE phase.
3. The pointer to the HobList should be saved somewhere so that HobLib functions can be called in SEC phase. In my PoC it is saved in OVMF_WORK_AREA.
4. In PlatformPei there are many if-else to check if it is SMM/S3/Microvm/Cloud-Hypervisor/SEV/TDX. There are also Bhyve and Xen PlatformPei variants. In the current PlatformPei those if-else check depends on the PCDs and global variables. Because of (1) it needs input parameters for all these if-else check. Maybe a big environment variable data structure is needed.
But anyway a complete functional PlatformInitLib is a big task. My suggestion is that in TDVF-Config-B we first propose a basic functional PlatformInitLib. This lib can boot up Tdx guest and legacy OVMF guest in TDVF-Config-B. OvmfPkg/PlatformPei is not refactored by this basic PlatformInitLib this time. This is because PlatformPei serves SMM/S3/Microvm/Cloud-Hypervisor/SEV/TDX. It is a big risk for such refactor. We can revisit PlatformPei in the future.

PEI-less booting up legacy guest doesn't support TPM.

So to boot up legacy guest without PEI phase, there will be below changes.
1. OvmfStartupLib: (like TdxStartupLib)
- Decompress DxeFv, locate DxeCore, create IdentityMappingPageTables,

then jump to DxeCore.

Yes. Basically rename TdxStartupLib to OvmfStartupLib and add some
IfTdx() checks.

Yes, agree.

2. PlatformPeiLib:
- Wrap the functions to do memory initialization, etc. (see tasks
1-5)

Yes. Move code from PlatformPei to PlatformLib. Might also need some
reorganization due to SEC restrictions.

As I explained above, a basic PlatformInitLib is the first stage and some reorganization is needed.

3. OvmfLegacyDxe
- Set the PCDs (see task 6)

Well, in Tdx mode you have to set some PCDs too ...

TdxDxe.inf can set the PCDs.

Also not sure we actually need a new Dxe. Can't we just handle that in
PlatformDxe in case of a PEI-less boot?

Do you mean "OvmfPkg/PlatformDxe/Platform.inf"? I am afraid PlatformDxe cannot do this task.
It is not in APRIORI DXE list so it cannot be guaranteed to be loaded at the very beginning of DXE phase. While some PCDs are required in the very early stage of DXE phase.

I know there are many discussions in above options. Can we follow below

road map so that we can discuss 3 (How to achieve ONE Binary) in more
details?

1. Basic Config-B (PEI-less and only Tdx guest) 2. Advanced Config-B
(RTMR based measurement) 3. One Binary Config-B (support legacy guest)

IMHO step #1 must be reorganizing the platform initialization code for PEI-
less boot (create PlatformLib as discussed above).

This patch series side-steps that by simply duplicating the code. PCI
initialization for example. Also setting the tdx PCDs. Having two (or even
more) copies of the same code in the tree is a bad idea though.
It makes long-term maintenance harder for various reasons.

As I explained above, a basic PlatformInitLib is the first stage. There will be an advanced PlatformInitLib in the future which implements more complicated functions.

... and given that TDX-capable
hardware is not yet production ready I find it rather important that
testing the PEI-less boot workflow does not require TDX.

It'll also make it much easier to add CI coverage.

I am thinking if SEV features are covered in CI?
Because I want to make sure our changes don't impact SEV.

AmdSevX64.dsc has build-test coverage. There is no qemu boot test
because FlashRomImage() (in OvmfPkg/PlatformCI/PlatformBuildLib.py)
is not flexible enough for that. Fixing that and adding a boot test (in non-sev
mode) shouldn't be that difficult though.

Same for IntelTdx.dsc: adding a CI boot test (in non-tdx mode) should be
easy, and it should help preventing regressions in PEI-less boot flow.

Agree. We will add a CI boot test (in non-tdx mode).

Thanks
Min

[AMD Official Use Only]

Gentle reminder...please review and merge the changeset.

Reviewed-by: Guomin Jiang <guomin.jiang@...>

Guomin

Since it's now the new year, I thought it might be worth pinging people again to try and get these patches pushed.

--

Rebecca Cran

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430

This change added support of installing `EFI_MM_COMMUNICATION3_PROTOCOL`.

MmCommunicate v3 routine that calculates message length is also updated
to remove ambiguity in contrast to v1 routine.

Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Eric Dong <eric.dong@...>
Cc: Ray Ni <ray.ni@...>

Signed-off-by: Kun Qin <kuqin12@...>
---

Notes:
v3:
- Newly added v3 communicate protocol instance

v4:
- Rebased with uncrustify changes.

MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 190 ++++++++++++++++++++
MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf | 2 +
2 files changed, 192 insertions(+)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index 4f00cebaf5ed..910f54bed5fb 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -11,6 +11,7 @@
#include <Protocol/SmmBase2.h>
#include <Protocol/SmmCommunication.h>
#include <Protocol/MmCommunication2.h>
+#include <Protocol/MmCommunication3.h>
#include <Protocol/SmmAccess2.h>
#include <Protocol/SmmConfiguration.h>
#include <Protocol/SmmControl2.h>
@@ -34,6 +35,7 @@
#include <Library/UefiRuntimeLib.h>
#include <Library/PcdLib.h>
#include <Library/ReportStatusCodeLib.h>
+#include <Library/SafeIntLib.h>

#include "PiSmmCorePrivateData.h"

@@ -146,6 +148,41 @@ SmmCommunicationMmCommunicate2 (
IN OUT UINTN *CommSize OPTIONAL
);

+/**
+ Communicates with a registered handler.
+
+ This function provides a service to send and receive messages from a registered UEFI service.
+
+ @param[in] This The EFI_MM_COMMUNICATION3_PROTOCOL instance.
+ @param[in, out] CommBufferPhysical Physical address of the MM communication buffer, of which content must
+ start with EFI_MM_COMMUNICATE_HEADER_V3.
+ @param[in, out] CommBufferVirtual Virtual address of the MM communication buffer, of which content must
+ start with EFI_MM_COMMUNICATE_HEADER_V3.
+ @param[in, out] CommSize The size of the data buffer being passed in. On exit, the size of data
+ being returned. Zero if the handler does not wish to reply with any data.
+ This parameter is optional and may be NULL.
+
+ @retval EFI_SUCCESS The message was successfully posted.
+ @retval EFI_INVALID_PARAMETER CommBufferPhysical was NULL or CommBufferVirtual was NULL.
+ @retval EFI_BAD_BUFFER_SIZE The buffer is too large for the MM implementation.
+ If this error is returned, the MessageLength field
+ in the CommBuffer header or the integer pointed by
+ CommSize, are updated to reflect the maximum payload
+ size the implementation can accommodate.
+ @retval EFI_ACCESS_DENIED The CommunicateBuffer parameter or CommSize parameter,
+ if not omitted, are in address range that cannot be
+ accessed by the MM environment.
+
+**/
+EFI_STATUS
+EFIAPI
+MmCommunicationMmCommunicate3 (
+ IN CONST EFI_MM_COMMUNICATION3_PROTOCOL *This,
+ IN OUT VOID *CommBufferPhysical,
+ IN OUT VOID *CommBufferVirtual,
+ IN OUT UINTN *CommSize OPTIONAL
+ );
+
/**
Event notification that is fired every time a gEfiSmmConfigurationProtocol installs.

@@ -275,6 +312,13 @@ EFI_MM_COMMUNICATION2_PROTOCOL mMmCommunication2 = {
SmmCommunicationMmCommunicate2
};

+//
+// PI 1.7 MM Communication Protocol 3 instance
+//
+EFI_MM_COMMUNICATION3_PROTOCOL mMmCommunication3 = {
+ MmCommunicationMmCommunicate3
+};
+
//
// SMM Core Private Data structure that contains the data shared between
// the SMM IPL and the SMM Core.
@@ -651,6 +695,150 @@ SmmCommunicationMmCommunicate2 (
);
}

+/**
+ Communicates with a registered handler.
+
+ This function provides a service to send and receive messages from a registered UEFI service.
+
+ @param[in] This The EFI_MM_COMMUNICATION3_PROTOCOL instance.
+ @param[in, out] CommBufferPhysical Physical address of the MM communication buffer, of which content must
+ start with EFI_MM_COMMUNICATE_HEADER_V3.
+ @param[in, out] CommBufferVirtual Virtual address of the MM communication buffer, of which content must
+ start with EFI_MM_COMMUNICATE_HEADER_V3.
+ @param[in, out] CommSize The size of the data buffer being passed in. On exit, the size of data
+ being returned. Zero if the handler does not wish to reply with any data.
+ This parameter is optional and may be NULL.
+
+ @retval EFI_SUCCESS The message was successfully posted.
+ @retval EFI_INVALID_PARAMETER CommBufferPhysical was NULL or CommBufferVirtual was NULL.
+ @retval EFI_BAD_BUFFER_SIZE The buffer is too large for the MM implementation.
+ If this error is returned, the MessageLength field
+ in the CommBuffer header or the integer pointed by
+ CommSize, are updated to reflect the maximum payload
+ size the implementation can accommodate.
+ @retval EFI_ACCESS_DENIED The CommunicateBuffer parameter or CommSize parameter,
+ if not omitted, are in address range that cannot be
+ accessed by the MM environment.
+
+**/
+EFI_STATUS
+EFIAPI
+MmCommunicationMmCommunicate3 (
+ IN CONST EFI_MM_COMMUNICATION3_PROTOCOL *This,
+ IN OUT VOID *CommBufferPhysical,
+ IN OUT VOID *CommBufferVirtual,
+ IN OUT UINTN *CommSize OPTIONAL
+ )
+{
+ EFI_STATUS Status;
+ EFI_MM_COMMUNICATE_HEADER_V3 *CommunicateHeader;
+ BOOLEAN OldInSmm;
+ UINTN TempCommSize;
+ UINT64 LongCommSize;
+
+ //
+ // Check parameters
+ //
+ if (CommBufferPhysical == NULL) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ CommunicateHeader = (EFI_MM_COMMUNICATE_HEADER_V3 *)CommBufferPhysical;
+
+ if (CommSize == NULL) {
+ Status = SafeUint64Add (sizeof (EFI_MM_COMMUNICATE_HEADER_V3), CommunicateHeader->MessageSize, &LongCommSize);
+ if (EFI_ERROR (Status)) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ Status = SafeUint64ToUintn (LongCommSize, &TempCommSize);
+ if (EFI_ERROR (Status)) {
+ return EFI_INVALID_PARAMETER;
+ }
+ } else {
+ TempCommSize = *CommSize;
+ //
+ // CommSize must hold the entire EFI_MM_COMMUNICATE_HEADER_V3
+ //
+ if (TempCommSize < sizeof (EFI_MM_COMMUNICATE_HEADER_V3)) {
+ return EFI_INVALID_PARAMETER;
+ }
+ }
+
+ //
+ // If not already in SMM, then generate a Software SMI
+ //
+ if (!gSmmCorePrivate->InSmm && gSmmCorePrivate->SmmEntryPointRegistered) {
+ //
+ // Put arguments for Software SMI in gSmmCorePrivate
+ //
+ gSmmCorePrivate->CommunicationBuffer = CommBufferPhysical;
+ gSmmCorePrivate->BufferSize = TempCommSize;
+
+ //
+ // Generate Software SMI
+ //
+ Status = mSmmControl2->Trigger (mSmmControl2, NULL, NULL, FALSE, 0);
+ if (EFI_ERROR (Status)) {
+ return EFI_UNSUPPORTED;
+ }
+
+ //
+ // Return status from software SMI
+ //
+ if (CommSize != NULL) {
+ *CommSize = gSmmCorePrivate->BufferSize;
+ }
+
+ return gSmmCorePrivate->ReturnStatus;
+ }
+
+ //
+ // If we are in SMM, then the execution mode must be physical, which means that
+ // OS established virtual addresses can not be used. If SetVirtualAddressMap()
+ // has been called, then a direct invocation of the Software SMI is not allowed,
+ // so return EFI_INVALID_PARAMETER.
+ //
+ if (EfiGoneVirtual ()) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ //
+ // If we are not in SMM, don't allow call SmiManage() directly when SMRAM is closed or locked.
+ //
+ if ((!gSmmCorePrivate->InSmm) && (!mSmmAccess->OpenState || mSmmAccess->LockState)) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ //
+ // Save current InSmm state and set InSmm state to TRUE
+ //
+ OldInSmm = gSmmCorePrivate->InSmm;
+ gSmmCorePrivate->InSmm = TRUE;
+
+ //
+ // Before SetVirtualAddressMap(), we are in SMM or SMRAM is open and unlocked, call SmiManage() directly.
+ //
+ TempCommSize -= sizeof (EFI_MM_COMMUNICATE_HEADER_V3);
+ Status = gSmmCorePrivate->Smst->SmiManage (
+ &CommunicateHeader->MessageGuid,
+ NULL,
+ CommunicateHeader->MessageData,
+ &TempCommSize
+ );
+ TempCommSize += sizeof (EFI_MM_COMMUNICATE_HEADER_V3);
+ if (CommSize != NULL) {
+ *CommSize = TempCommSize;
+ }
+
+ //
+ // Restore original InSmm state
+ //
+ gSmmCorePrivate->InSmm = OldInSmm;
+
+ return (Status == EFI_SUCCESS) ? EFI_SUCCESS : EFI_NOT_FOUND;
+}
+
/**
Event notification that is fired when GUIDed Event Group is signaled.

@@ -1859,6 +2047,8 @@ SmmIplEntry (
&mSmmCommunication,
&gEfiMmCommunication2ProtocolGuid,
&mMmCommunication2,
+ &gEfiMmCommunication3ProtocolGuid,
+ &mMmCommunication3,
NULL
);
ASSERT_EFI_ERROR (Status);
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
index 6109d6b5449c..afab228cc04c 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
@@ -46,11 +46,13 @@ [LibraryClasses]
DxeServicesLib
PcdLib
ReportStatusCodeLib
+ SafeIntLib

[Protocols]
gEfiSmmBase2ProtocolGuid ## PRODUCES
gEfiSmmCommunicationProtocolGuid ## PRODUCES
gEfiMmCommunication2ProtocolGuid ## PRODUCES
+ gEfiMmCommunication3ProtocolGuid ## PRODUCES
gEfiSmmAccess2ProtocolGuid ## CONSUMES
## NOTIFY
## CONSUMES
--
2.34.1.windows.1

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430

MM communicate protocols are expanded with EFI_MM_COMMUNICATE_HEADER_V3
structure that cooperates with updated field types and flexible array.
The PiSmmCore implementation is updated to detect and process incoming
data accordingly.

Two checks are also performed to prevent legacy communicate data or
unsupported data is fed into MM core under agreed header guid.

Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Supreeth Venkatesh <supreeth.venkatesh@...>

Signed-off-by: Kun Qin <kuqin12@...>
---

Notes:
v3:
- Newly added

v4:
- Rebased with uncrusitify changes.

StandaloneMmPkg/Core/StandaloneMmCore.c | 35 ++++++++++++++++----
StandaloneMmPkg/Core/StandaloneMmCore.inf | 1 +
2 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.c b/StandaloneMmPkg/Core/StandaloneMmCore.c
index d221f1d1115d..8afb22493cb2 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.c
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.c
@@ -338,8 +338,12 @@ MmEntryPoint (
IN CONST EFI_MM_ENTRY_CONTEXT *MmEntryContext
)
{
- EFI_STATUS Status;
- EFI_MM_COMMUNICATE_HEADER *CommunicateHeader;
+ EFI_STATUS Status;
+ EFI_MM_COMMUNICATE_HEADER_V3 *CommunicateHeader;
+ EFI_MM_COMMUNICATE_HEADER *LegacyCommunicateHeader;
+ EFI_GUID *CommGuid;
+ VOID *CommData;
+ UINTN CommHeaderSize;

DEBUG ((DEBUG_INFO, "MmEntryPoint ...\n"));

@@ -377,19 +381,36 @@ MmEntryPoint (
gMmCorePrivate->CommunicationBuffer = 0;
gMmCorePrivate->ReturnStatus = EFI_INVALID_PARAMETER;
} else {
- CommunicateHeader = (EFI_MM_COMMUNICATE_HEADER *)(UINTN)gMmCorePrivate->CommunicationBuffer;
- gMmCorePrivate->BufferSize -= OFFSET_OF (EFI_MM_COMMUNICATE_HEADER, Data);
+ CommGuid = &((EFI_MM_COMMUNICATE_HEADER_V3 *)(UINTN)gMmCorePrivate->CommunicationBuffer)->HeaderGuid;
+ //
+ // Check if the signature matches EFI_MM_COMMUNICATE_HEADER_V3 definition
+ //
+ if (CompareGuid (CommGuid, &gCommunicateHeaderV3Guid)) {
+ CommunicateHeader = (EFI_MM_COMMUNICATE_HEADER_V3 *)(UINTN)gMmCorePrivate->CommunicationBuffer;
+ ASSERT (CommunicateHeader->Signature == EFI_MM_COMMUNICATE_HEADER_V3_SIGNATURE);
+ ASSERT (CommunicateHeader->Version <= EFI_MM_COMMUNICATE_HEADER_V3_VERSION);
+ CommGuid = &CommunicateHeader->MessageGuid;
+ CommData = CommunicateHeader->MessageData;
+ CommHeaderSize = sizeof (EFI_MM_COMMUNICATE_HEADER_V3);
+ } else {
+ LegacyCommunicateHeader = (EFI_MM_COMMUNICATE_HEADER *)(UINTN)gMmCorePrivate->CommunicationBuffer;
+ CommGuid = &LegacyCommunicateHeader->HeaderGuid;
+ CommData = LegacyCommunicateHeader->Data;
+ CommHeaderSize = OFFSET_OF (EFI_MM_COMMUNICATE_HEADER, Data);
+ }
+
+ gMmCorePrivate->BufferSize -= CommHeaderSize;
Status = MmiManage (
- &CommunicateHeader->HeaderGuid,
+ CommGuid,
NULL,
- CommunicateHeader->Data,
+ CommData,
(UINTN *)&gMmCorePrivate->BufferSize
);
//
// Update CommunicationBuffer, BufferSize and ReturnStatus
// Communicate service finished, reset the pointer to CommBuffer to NULL
//
- gMmCorePrivate->BufferSize += OFFSET_OF (EFI_MM_COMMUNICATE_HEADER, Data);
+ gMmCorePrivate->BufferSize += CommHeaderSize;
gMmCorePrivate->CommunicationBuffer = 0;
gMmCorePrivate->ReturnStatus = (Status == EFI_SUCCESS) ? EFI_SUCCESS : EFI_NOT_FOUND;
}
diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf b/StandaloneMmPkg/Core/StandaloneMmCore.inf
index c44b9ff33303..e2e6cd32beee 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
@@ -75,6 +75,7 @@ [Guids]
gEfiEventLegacyBootGuid
gEfiEventExitBootServicesGuid
gEfiEventReadyToBootGuid
+ gCommunicateHeaderV3Guid ## CONSUMES ## GUID # Communicate header

#
# This configuration fails for CLANGPDB, which does not support PIE in the GCC
--
2.34.1.windows.1

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430

MM communicate protocols are expanded with EFI_MM_COMMUNICATE_HEADER_V3
structure that cooperates with updated field types and flexible array.
The PiSmmCore implementation is updated to detect and process incoming
data accordingly.

Two checks are also performed to prevent legacy communicate data or
unsupported data is fed into MM core under agreed header guid.

Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Eric Dong <eric.dong@...>
Cc: Ray Ni <ray.ni@...>

Signed-off-by: Kun Qin <kuqin12@...>
---

Notes:
v3:
- Newly added

v4:
- Rebased with uncrusitify changes.

MdeModulePkg/Core/PiSmmCore/PiSmmCore.c | 51 ++++++++++++++------
MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf | 1 +
2 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index 9e5c6cbe33dd..8d57f71dc969 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -647,12 +647,16 @@ SmmEntryPoint (
IN CONST EFI_SMM_ENTRY_CONTEXT *SmmEntryContext
)
{
- EFI_STATUS Status;
- EFI_SMM_COMMUNICATE_HEADER *CommunicateHeader;
- BOOLEAN InLegacyBoot;
- BOOLEAN IsOverlapped;
- VOID *CommunicationBuffer;
- UINTN BufferSize;
+ EFI_STATUS Status;
+ EFI_MM_COMMUNICATE_HEADER_V3 *CommunicateHeader;
+ EFI_SMM_COMMUNICATE_HEADER *LegacyCommunicateHeader;
+ BOOLEAN InLegacyBoot;
+ BOOLEAN IsOverlapped;
+ VOID *CommunicationBuffer;
+ UINTN BufferSize;
+ EFI_GUID *CommGuid;
+ VOID *CommData;
+ UINTN CommHeaderSize;

//
// Update SMST with contents of the SmmEntryContext structure
@@ -708,19 +712,36 @@ SmmEntryPoint (
gSmmCorePrivate->CommunicationBuffer = NULL;
gSmmCorePrivate->ReturnStatus = EFI_ACCESS_DENIED;
} else {
- CommunicateHeader = (EFI_SMM_COMMUNICATE_HEADER *)CommunicationBuffer;
- BufferSize -= OFFSET_OF (EFI_SMM_COMMUNICATE_HEADER, Data);
- Status = SmiManage (
- &CommunicateHeader->HeaderGuid,
- NULL,
- CommunicateHeader->Data,
- &BufferSize
- );
+ CommGuid = &((EFI_MM_COMMUNICATE_HEADER_V3 *)CommunicationBuffer)->HeaderGuid;
+ //
+ // Check if the signature matches EFI_MM_COMMUNICATE_HEADER_V3 definition
+ //
+ if (CompareGuid (CommGuid, &gCommunicateHeaderV3Guid)) {
+ CommunicateHeader = (EFI_MM_COMMUNICATE_HEADER_V3 *)CommunicationBuffer;
+ ASSERT (CommunicateHeader->Signature == EFI_MM_COMMUNICATE_HEADER_V3_SIGNATURE);
+ ASSERT (CommunicateHeader->Version <= EFI_MM_COMMUNICATE_HEADER_V3_VERSION);
+ CommGuid = &CommunicateHeader->MessageGuid;
+ CommData = CommunicateHeader->MessageData;
+ CommHeaderSize = sizeof (EFI_MM_COMMUNICATE_HEADER_V3);
+ } else {
+ LegacyCommunicateHeader = (EFI_SMM_COMMUNICATE_HEADER *)CommunicationBuffer;
+ CommGuid = &LegacyCommunicateHeader->HeaderGuid;
+ CommData = LegacyCommunicateHeader->Data;
+ CommHeaderSize = OFFSET_OF (EFI_SMM_COMMUNICATE_HEADER, Data);
+ }
+
+ BufferSize -= CommHeaderSize;
+ Status = SmiManage (
+ CommGuid,
+ NULL,
+ CommData,
+ &BufferSize
+ );
//
// Update CommunicationBuffer, BufferSize and ReturnStatus
// Communicate service finished, reset the pointer to CommBuffer to NULL
//
- gSmmCorePrivate->BufferSize = BufferSize + OFFSET_OF (EFI_SMM_COMMUNICATE_HEADER, Data);
+ gSmmCorePrivate->BufferSize = BufferSize + CommHeaderSize;
gSmmCorePrivate->CommunicationBuffer = NULL;
gSmmCorePrivate->ReturnStatus = (Status == EFI_SUCCESS) ? EFI_SUCCESS : EFI_NOT_FOUND;
}
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
index c8bfae3860fc..5a0929a45e19 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
@@ -118,6 +118,7 @@ [Guids]
gSmiHandlerProfileGuid
gEdkiiEndOfS3ResumeGuid ## SOMETIMES_PRODUCES ## GUID # Install protocol
gEdkiiS3SmmInitDoneGuid ## SOMETIMES_PRODUCES ## GUID # Install protocol
+ gCommunicateHeaderV3Guid ## CONSUMES ## GUID # Communicate header

[UserExtensions.TianoCore."ExtraFiles"]
PiSmmCoreExtra.uni
--
2.34.1.windows.1

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430

This change introduces a new definition for MM communicate PPI v3.

This PPI will be installed under a new GUID in contrast to exisiting
EFI_PEI_MM_COMMUNICATION_PPI.

Data communicated to MM through EFI_PEI_MM_COMMUNICATION3_PPI should
always start with EFI_MM_COMMUNICATE_HEADER_V3 with its HeaderGuid,
Signature and Version fields properly populated.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Marvin Häuser <mhaeuser@...>
Cc: Bret Barkelew <Bret.Barkelew@...>
Cc: Michael Kubacki <michael.kubacki@...>

Signed-off-by: Kun Qin <kuqin12@...>
---

Notes:
v3:
- Newly introduced v3 communicate PPI

v4:
- Rebased with uncrustify changes.

MdePkg/Include/Ppi/MmCommunication3.h | 57 ++++++++++++++++++++
MdePkg/MdePkg.dec | 3 ++
2 files changed, 60 insertions(+)

diff --git a/MdePkg/Include/Ppi/MmCommunication3.h b/MdePkg/Include/Ppi/MmCommunication3.h
new file mode 100644
index 000000000000..1cc75c38c012
--- /dev/null
+++ b/MdePkg/Include/Ppi/MmCommunication3.h
@@ -0,0 +1,57 @@
+/** @file
+ EFI MM Communication v3 PPI definition.
+
+ This Ppi provides a means of communicating between PEIM and MMI
+ handlers inside of MM.
+
+Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.<BR>
+Copyright (c) Microsoft Corporation.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef MM_COMMUNICATION3_PPI_H_
+#define MM_COMMUNICATION3_PPI_H_
+
+#include <Pi/PiMultiPhase.h>
+
+#define EFI_PEI_MM_COMMUNICATION3_PPI_GUID \
+ { \
+ 0xe70febf6, 0x13ef, 0x4a21, { 0x89, 0x9e, 0xb2, 0x36, 0xf8, 0x25, 0xff, 0xc9 } \
+ }
+
+typedef struct _EFI_PEI_MM_COMMUNICATION3_PPI EFI_PEI_MM_COMMUNICATION3_PPI;
+
+/**
+ Communicates with a registered handler.
+
+ This function provides a service to send and receive messages from a registered UEFI service.
+
+ @param[in] This The EFI_PEI_MM_COMMUNICATE3 instance.
+ @param[in, out] CommBuffer A pointer to the buffer to convey into MMRAM.
+ @param[in, out] CommSize The size of the data buffer being passed in.On exit, the size of data
+ being returned. Zero if the handler does not wish to reply with any data.
+
+ @retval EFI_SUCCESS The message was successfully posted.
+ @retval EFI_INVALID_PARAMETER The CommBuffer was NULL.
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_COMMUNICATE3)(
+ IN CONST EFI_PEI_MM_COMMUNICATION3_PPI *This,
+ IN OUT VOID *CommBuffer,
+ IN OUT UINTN *CommSize
+ );
+
+///
+/// EFI MM Communication PPI provides runtime services for communicating
+/// between DXE drivers and a registered SMI handler.
+///
+struct _EFI_PEI_MM_COMMUNICATION3_PPI {
+ EFI_PEI_MM_COMMUNICATE3 Communicate;
+};
+
+extern EFI_GUID gEfiPeiMmCommunication3PpiGuid;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 8c61661e4ee7..cb42078fa330 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -1012,6 +1012,9 @@ [Ppis]
## Include/Ppi/DelayedDispatch.h
gEfiPeiDelayedDispatchPpiGuid = { 0x869c711d, 0x649c, 0x44fe, { 0x8b, 0x9e, 0x2c, 0xbb, 0x29, 0x11, 0xc3, 0xe6 }}

+ ## Include/Ppi/MmCommunication3.h
+ gEfiPeiMmCommunication3PpiGuid = { 0xe70febf6, 0x13ef, 0x4a21, { 0x89, 0x9e, 0xb2, 0x36, 0xf8, 0x25, 0xff, 0xc9 }}
+
[Protocols]
## Include/Protocol/Pcd.h
gPcdProtocolGuid = { 0x11B34006, 0xD85B, 0x4D0A, { 0xA2, 0x90, 0xD5, 0xA5, 0x71, 0x31, 0x0E, 0xF7 }}
--
2.34.1.windows.1

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430

This change introduces a new definition for MM communicate protocol v3.

This protocol will be installed under a new GUID in contrast to exisiting
EFI_MM_COMMUNICATION_PROTOCOL.

Data communicated to MM through EFI_MM_COMMUNICATION3_PROTOCOL should
always start with EFI_MM_COMMUNICATE_HEADER_V3 with its HeaderGuid,
Signature and Version fields properly populated.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Marvin Häuser <mhaeuser@...>
Cc: Bret Barkelew <Bret.Barkelew@...>
Cc: Michael Kubacki <michael.kubacki@...>

Signed-off-by: Kun Qin <kuqin12@...>
---

Notes:
v3:
- Newly introduced v3 of communicate protocol

v4:
- Rebased with uncrustify changes.

MdePkg/Include/Protocol/MmCommunication3.h | 70 ++++++++++++++++++++
MdePkg/MdePkg.dec | 3 +
2 files changed, 73 insertions(+)

diff --git a/MdePkg/Include/Protocol/MmCommunication3.h b/MdePkg/Include/Protocol/MmCommunication3.h
new file mode 100644
index 000000000000..0df9e5b875b7
--- /dev/null
+++ b/MdePkg/Include/Protocol/MmCommunication3.h
@@ -0,0 +1,70 @@
+/** @file
+ EFI MM Communication Protocol 2 as defined in the PI 1.7 errata A specification.
+
+ This protocol provides a means of communicating between drivers outside of MM and MMI
+ handlers inside of MM.
+
+ Copyright (c) 2017, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2019, Arm Limited. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef MM_COMMUNICATION3_H_
+#define MM_COMMUNICATION3_H_
+
+#include <Pi/PiMultiPhase.h>
+
+#define EFI_MM_COMMUNICATION3_PROTOCOL_GUID \
+ { \
+ 0xf7234a14, 0xdf2, 0x46c0, { 0xad, 0x28, 0x90, 0xe6, 0xb8, 0x83, 0xa7, 0x2f } \
+ }
+
+typedef struct _EFI_MM_COMMUNICATION3_PROTOCOL EFI_MM_COMMUNICATION3_PROTOCOL;
+
+/**
+ Communicates with a registered handler.
+
+ This function provides a service to send and receive messages from a registered UEFI service.
+
+ @param[in] This The EFI_MM_COMMUNICATION3_PROTOCOL instance.
+ @param[in, out] CommBufferPhysical Physical address of the MM communication buffer, of which content must
+ start with EFI_MM_COMMUNICATE_HEADER_V3.
+ @param[in, out] CommBufferVirtual Virtual address of the MM communication buffer, of which content must
+ start with EFI_MM_COMMUNICATE_HEADER_V3.
+ @param[in, out] CommSize The size of the data buffer being passed in. On exit, the size of data
+ being returned. Zero if the handler does not wish to reply with any data.
+ This parameter is optional and may be NULL.
+
+ @retval EFI_SUCCESS The message was successfully posted.
+ @retval EFI_INVALID_PARAMETER CommBufferPhysical was NULL or CommBufferVirtual was NULL.
+ @retval EFI_BAD_BUFFER_SIZE The buffer is too large for the MM implementation.
+ If this error is returned, the MessageLength field
+ in the CommBuffer header or the integer pointed by
+ CommSize, are updated to reflect the maximum payload
+ size the implementation can accommodate.
+ @retval EFI_ACCESS_DENIED The CommunicateBuffer parameter or CommSize parameter,
+ if not omitted, are in address range that cannot be
+ accessed by the MM environment.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_MM_COMMUNICATE3)(
+ IN CONST EFI_MM_COMMUNICATION3_PROTOCOL *This,
+ IN OUT VOID *CommBufferPhysical,
+ IN OUT VOID *CommBufferVirtual,
+ IN OUT UINTN *CommSize OPTIONAL
+ );
+
+///
+/// EFI MM Communication Protocol provides runtime services for communicating
+/// between DXE drivers and a registered MMI handler.
+///
+struct _EFI_MM_COMMUNICATION3_PROTOCOL {
+ EFI_MM_COMMUNICATE3 Communicate;
+};
+
+extern EFI_GUID gEfiMmCommunication3ProtocolGuid;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 11c08e617511..8c61661e4ee7 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -1357,6 +1357,9 @@ [Protocols]
## Include/Protocol/MmCommunication2.h
gEfiMmCommunication2ProtocolGuid = { 0x378daedc, 0xf06b, 0x4446, { 0x83, 0x14, 0x40, 0xab, 0x93, 0x3c, 0x87, 0xa3 }}

+ ## Include/Protocol/MmCommunication3.h
+ gEfiMmCommunication3ProtocolGuid = { 0xf7234a14, 0xdf2, 0x46c0, { 0xad, 0x28, 0x90, 0xe6, 0xb8, 0x83, 0xa7, 0x2f }}
+
#
# Protocols defined in UEFI2.1/UEFI2.0/EFI1.1
#
--
2.34.1.windows.1

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430

This change introduces a new definition for MM communicate header
structure, intending to provide better portability between different
architectures (IA32 & X64) and adapt to flexible array supported by
modern compilers.

The original MessageLength field of EFI_MM_COMMUNICATE_HEADER, as a
generic definition, was used for both PEI and DXE MM communication. On a
system that supports PEI MM launch, but operates PEI in 32bit mode and MM
foundation in 64bit, the current EFI_MM_COMMUNICATE_HEADER definition
will cause structure parse error due to UINTN used. This introduction
removes the architecture dependent field by defining this field as
UINT64.

The new signature could help identifying whether the data received is
compiliant with this new data structure, which will help for binary
release modules to identify usage of legacy data structure.

Version field is also added to indicate the current version of header in
case there is need for minor modification in the future.

The data field of MM communicate message is replaced with flexible array
to allow users not having to consume extra data during communicate and
author code more intrinsically.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Marvin Häuser <mhaeuser@...>
Cc: Bret Barkelew <Bret.Barkelew@...>
Cc: Michael Kubacki <michael.kubacki@...>

Signed-off-by: Kun Qin <kuqin12@...>
---

Notes:
v3:
- Newly introduced communicate v3
- Used flexible arrays [Marvin]
- Added static assert [Michael]

v4:
- Rebased with uncrusitify changes.

MdePkg/Include/Pi/PiMultiPhase.h | 57 ++++++++++++++++++++
MdePkg/MdePkg.dec | 5 ++
2 files changed, 62 insertions(+)

diff --git a/MdePkg/Include/Pi/PiMultiPhase.h b/MdePkg/Include/Pi/PiMultiPhase.h
index a7e95820ef65..178606eacfb0 100644
--- a/MdePkg/Include/Pi/PiMultiPhase.h
+++ b/MdePkg/Include/Pi/PiMultiPhase.h
@@ -103,6 +103,17 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#define EFI_SMRAM_CLOSED EFI_MMRAM_CLOSED
#define EFI_SMRAM_LOCKED EFI_MMRAM_LOCKED

+///
+/// MM Communicate header constants
+///
+#define COMMUNICATE_HEADER_V3_GUID \
+ { \
+ 0x68e8c853, 0x2ba9, 0x4dd7, { 0x9a, 0xc0, 0x91, 0xe1, 0x61, 0x55, 0xc9, 0x35 } \
+ }
+
+#define EFI_MM_COMMUNICATE_HEADER_V3_SIGNATURE 0x4D434833 // "MCH3"
+#define EFI_MM_COMMUNICATE_HEADER_V3_VERSION 3
+
///
/// Structure describing a MMRAM region and its accessibility attributes.
///
@@ -149,6 +160,50 @@ typedef struct _EFI_MM_RESERVED_MMRAM_REGION {
UINT64 MmramReservedSize;
} EFI_MM_RESERVED_MMRAM_REGION;

+#pragma pack(1)
+
+///
+/// To avoid confusion in interpreting frames, the buffer communicating to MM core through
+/// EFI_MM_COMMUNICATE3 or later should always start with EFI_MM_COMMUNICATE_HEADER_V3.
+///
+typedef struct {
+ ///
+ /// Indicator GUID for MM core that the communication buffer is compliant with this v3 header.
+ /// Must be gCommunicateHeaderV3Guid.
+ ///
+ EFI_GUID HeaderGuid;
+ ///
+ /// Signature to indicate data is compliant with new MM communicate header structure.
+ /// Must be "MCH3".
+ ///
+ UINT32 Signature;
+ ///
+ /// MM communicate data format version, MM foundation entry point should check if incoming
+ /// data is a supported format before proceeding.
+ /// Must be 3.
+ ///
+ UINT32 Version;
+ ///
+ /// Allows for disambiguation of the message format.
+ ///
+ EFI_GUID MessageGuid;
+ ///
+ /// Describes the size of MessageData (in bytes) and does not include the size of the header.
+ ///
+ UINT64 MessageSize;
+ ///
+ /// Designates an array of bytes that is MessageSize in size.
+ ///
+ UINT8 MessageData[];
+} EFI_MM_COMMUNICATE_HEADER_V3;
+
+#pragma pack()
+
+STATIC_ASSERT (
+ (sizeof (EFI_MM_COMMUNICATE_HEADER_V3) == OFFSET_OF (EFI_MM_COMMUNICATE_HEADER_V3, MessageData)), \
+ "sizeof (EFI_MM_COMMUNICATE_HEADER_V3) does not align with the beginning of flexible array MessageData"
+ );
+
typedef enum {
EFI_PCD_TYPE_8,
EFI_PCD_TYPE_16,
@@ -208,4 +263,6 @@ EFI_STATUS
IN VOID *ProcedureArgument
);

+extern EFI_GUID gCommunicateHeaderV3Guid;
+
#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 59b405928bf8..11c08e617511 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -826,6 +826,11 @@ [Guids]
## Include/Protocol/CcMeasurement.h
gEfiCcFinalEventsTableGuid = { 0xdd4a4648, 0x2de7, 0x4665, { 0x96, 0x4d, 0x21, 0xd9, 0xef, 0x5f, 0xb4, 0x46 }}

+ #
+ # GUID indicates the MM communication data is compliant with v3 communication header.
+ #
+ gCommunicateHeaderV3Guid = { 0x68e8c853, 0x2ba9, 0x4dd7, { 0x9a, 0xc0, 0x91, 0xe1, 0x61, 0x55, 0xc9, 0x35 } }
+
[Guids.IA32, Guids.X64]
## Include/Guid/Cper.h
gEfiIa32X64ErrorTypeCacheCheckGuid = { 0xA55701F5, 0xE3EF, 0x43de, { 0xAC, 0x72, 0x24, 0x9B, 0x57, 0x3F, 0xAD, 0x2C }}
--
2.34.1.windows.1

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3430

This change includes specification update markdown file that describes
the proposed PI Specification v1.7 Errata A in detail and potential
impact to the existing codebase.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Andrew Fish <afish@...>
Cc: Leif Lindholm <leif@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Marvin Häuser <mhaeuser@...>
Cc: Bret Barkelew <Bret.Barkelew@...>

Signed-off-by: Kun Qin <kuqin12@...>
---

Notes:
v3:
- switched to use communicate v3 instead of sprinkle structure updates

v4:
- No review, no change.

CodeFirst/BZ3430-SpecChange.md | 277 ++++++++++++++++++++
1 file changed, 277 insertions(+)

diff --git a/CodeFirst/BZ3430-SpecChange.md b/CodeFirst/BZ3430-SpecChange.md
new file mode 100644
index 000000000000..39a96b9a44f0
--- /dev/null
+++ b/CodeFirst/BZ3430-SpecChange.md
@@ -0,0 +1,277 @@
+# Title: Introduction of `EFI_MM_COMMUNICATE_HEADER_V3` and `MM_COMMUNICATE3_*` interface
+
+## Status: Draft
+
+## Document: UEFI Platform Initialization Specification Version 1.7 Errata A
+
+## License
+
+SPDX-License-Identifier: CC-BY-4.0
+
+## Submitter: [TianoCore Community](https://www.tianocore.org)
+
+## Summary of the change
+
+Introduce `EFI_PEI_MM_COMMUNICATION3_PPI` and `EFI_MM_COMMUNICATE3_PROTOCOL` that works with communication buffer starts with `EFI_MM_COMMUNICATE_HEADER_V3` to provide better portability between different architectures (IA32 & X64) and adapt to flexible array supported by modern compilers.
+
+## Benefits of the change
+
+In PI Spec v1.7 Errata A, Vol.4, Sec 5.7 MM Communication Protocol, the MessageLength field of `EFI_MM_COMMUNICATE_HEADER` (also defined as `EFI_SMM_COMMUNICATE_HEADER`) is defined as type UINTN.
+
+But this structure, as a generic definition, could be used for both PEI and DXE MM communication. Thus for a system that supports PEI Standalone MM launch, but operates PEI in 32bit mode and MM foundation in 64bit, the current `EFI_MM_COMMUNICATE_HEADER` definition will cause structure parse error due to UINTN used.
+
+This proposed data structure resolved it by introducing `EFI_MM_COMMUNICATE_HEADER_V3` that defines the MessageSize as UINT64 to remove data size ambiguity.
+
+The data structure still starts with a `HeaderGuid` field that is typed as `EFI_GUID`. This will be populated as `gCommunicateHeaderV3Guid` or `COMMUNICATE_HEADER_V3_GUID` as an indicator to differentiate new data format vesus legacy format.
+
+Furthermore, the addition of signature could help identifying whether the data received is compiliant with this new data structure, which will help for binary release modules to identify usage of legacy `EFI_MM_COMMUNICATE_HEADER`.
+
+Version field is also added to indicate the current version of header in case there is need for minor modification in the future.
+
+In addition, the data field of MM communicate message is replaced with flexible array to allow users not having to consume extra data during communicate and author code more intrinsically.
+
+On the non-MM environment side, the Standalone MM DXE IPL agent can add installation of `EFI_MM_COMMUNICATE3_PROTOCOL`, while the Standalone MM PEI IPL agent that launches MM foundation should publish and only publish `EFI_PEI_MM_COMMUNICATION3_PPI` for MM communication during PEI phase.
+
+For communication data that starts with `EFI_MM_COMMUNICATE_HEADER_V3`, callers always need to use V3 protocol/PPI to communicate with updated MM cores. These interface introductions instead of replacement can maintain the compatibility for existing codebase while resolving size mismatching occurred during data transfer between different architectures.
+
+## Impact of the change
+
+This change will impact the MM cores and IPLs:
+
+```bash
+MdeModulePkg/Core/PiSmmCore/PiSmmCore
+StandaloneMmPkg/Core/StandaloneMmCore
+MdeModulePkg/Core/PiSmmCore/PiSmmIpl
+```
+
+To cooporate with the newly proposed data format, existing MM cores need to be updated to parse incoming data properly to tell if the data is compliant with new or legacy format.
+
+The existing PiSmmIpl will need to be updated to publish `EFI_MM_COMMUNICATE3_PROTOCOL` for consumers that would like to invoke MMI with new data format.
+
+For potential proprietary IPLs that launches Standalone MM in PEI phase, if any, the PEIM should change to publish `EFI_PEI_MM_COMMUNICATION3_PPI` instead of `EFI_MM_COMMUNICATE_PPI`.
+
+Accordingly, all consumers in PEI phase that communicate to PEI launched Standalone MM should switch to use `EFI_PEI_MM_COMMUNICATION3_PPI` and `EFI_MM_COMMUNICATE_HEADER_V3`.
+
+## Detailed description of the change [normative updates]
+
+### Specification Changes
+
+1. In PI Specification v1.7 Errata A: Vol. 4-1.5.1 Initializing MM Standalone Mode in PEI phase, the last bullet point of step 3 should be changed to:
+
+ ```c
+ Publishes the EFI_PEI_MM_COMMUNICATION3_PPI
+ ```
+
+1. In PI Specification v1.7 Errata A: Vol. 4, section 6.5 MM Communication PPI, add the following:
+
+ ```markdown
+ # EFI_PEI_MM_COMMUNICATION_PPI
+
+ ## Summary
+
+ This PPI provides a means of communicating between drivers outside of MM and MMI handlers inside of MM in PEI phase.
+
+ ## GUID
+
+ #define EFI_PEI_MM_COMMUNICATION3_PPI_GUID \
+ { \
+ 0xe70febf6, 0x13ef, 0x4a21, { 0x89, 0x9e, 0xb2, 0x36, 0xf8, 0x25, 0xff, 0xc9 } \
+ }
+
+ ## PPI Structure
+
+ typedef struct _EFI_PEI_MM_COMMUNICATION3_PPI {
+ EFI_PEI_MM_COMMUNICATE3 Communicate;
+ } EFI_PEI_MM_COMMUNICATION3_PPI;
+
+ ## Members
+
+ ### Communicate
+
+ Sends/receives a message for a registered handler. See the Communicate() function description.
+
+ ## Description
+
+ This PPI provides services for communicating between PEIM and a registered MMI handler.
+
+ # EFI_PEI_MM_COMMUNICATION_PPI.Communicate()
+
+ ## Summary
+ Communicates with a registered handler.
+
+ ## Prototype
+ typedef
+ EFI_STATUS
+ (EFIAPI *EFI_PEI_MM_COMMUNICATE3)(
+ IN CONST EFI_PEI_MM_COMMUNICATION3_PPI *This,
+ IN OUT VOID *CommBuffer,
+ IN OUT UINTN *CommSize
+ );
+
+ ## Parameters
+
+ ### This
+ The EFI_PEI_MM_COMMUNICATE3 instance.
+
+ ### CommBuffer
+
+ Pointer to the buffer to convey into MMRAM.
+
+ ### CommSize
+
+ The size of the data buffer being passed in. On exit, the size of data being returned. Zero if the handler does not wish to reply with any data.
+
+ ## Description
+
+ This function provides a service to send and receive messages from a registered PEI service. The EFI_PEI_MM_COMMUNICATION3_PPI driver is responsible for doing any of the copies such that the data lives in PEI-service-accessible RAM.
+
+ A given implementation of the EFI_PEI_MM_COMMUNICATION3_PPI may choose to use the EFI_MM_CONTROL_PPI for effecting the mode transition, or it may use some other method.
+
+ The agent invoking the communication interface must be physical/virtually 1:1 mapped.
+
+ To avoid confusion in interpreting frames, the CommBuffer parameter should always begin with EFI_MM_COMMUNICATE_HEADER_V3. The header data is mandatory for messages sent into the MM agent.
+
+ Once inside of MM, the MM infrastructure will call all registered handlers with the same HandlerType as the GUID specified by HeaderGuid and the CommBuffer pointing to Data.
+
+ This function is not reentrant.
+
+ ## Status Codes Returned
+ EFI_SUCCESS The message was successfully posted.
+ EFI_INVALID_PARAMETER The CommBuffer was NULL.
+ ```
+
+1. In PI Specification v1.7 Errata A: Vol. 4, section 6.5 MM Communication PPI, add the following:
+
+ ```markdown
+ # EFI_MM_COMMUNICATION3_PROTOCOL
+
+ ## Summary
+
+ This protocol provides a means of communicating between drivers outside of MM and MMI handlers inside of MM, for communication buffer that is compliant with EFI_MM_COMMUNICATE_HEADER_V3.
+
+ ## GUID
+
+ #define EFI_MM_COMMUNICATION3_PROTOCOL_GUID \
+ { \
+ 0xf7234a14, 0xdf2, 0x46c0, { 0xad, 0x28, 0x90, 0xe6, 0xb8, 0x83, 0xa7, 0x2f } \
+ }
+
+ ## Prototype
+ typedef struct _EFI_MM_COMMUNICATION3_PROTOCOL {
+ EFI_MM_COMMUNICATE3 Communicate;
+ } EFI_MM_COMMUNICATION3_PROTOCOL;
+
+ ## Members
+
+ ### Communicate
+
+ Sends/receives a message for a registered handler. See the Communicate() function description.
+
+ ## Description
+
+ This protocol provides runtime services for communicating between DXE drivers and a registered MMI handler.
+
+ # EFI_MM_COMMUNICATION3_PROTOCOL.Communicate()
+
+ ## Summary
+
+ Communicates with a registered handler.
+
+ ## Prototype
+
+ typedef
+ EFI_STATUS
+ (EFIAPI *EFI_MM_COMMUNICATE3)(
+ IN CONST EFI_MM_COMMUNICATION3_PROTOCOL *This,
+ IN OUT VOID *CommBufferPhysical,
+ IN OUT VOID *CommBufferVirtual,
+ IN OUT UINTN *CommSize OPTIONAL
+ );
+
+ ## Parameters
+
+ ### This
+
+ The EFI_MM_COMMUNICATION3_PROTOCOL instance.
+
+ ### CommBufferPhysical
+
+ Physical address of the buffer to convey into MMRAM, of which content must start with EFI_MM_COMMUNICATE_HEADER_V3.
+
+ ### CommBufferVirtual
+
+ Virtual address of the buffer to convey into MMRAM, of which content must start with EFI_MM_COMMUNICATE_HEADER_V3.
+
+ ### CommSize
+
+ The size of the data buffer being passed in. On exit, the size of data being returned. Zero if the handler does not wish to reply with any data. This parameter is optional and may be NULL.
+
+ ## Description
+
+ Usage is similar to EFI_MM_COMMUNICATION_PROTOCOL.Communicate() except for the notes below:
+
+ * Communication buffer transfer to MM core should start with EFI_MM_COMMUNICATE_HEADER_V3.
+ * Instead of passing just the physical address via the CommBuffer parameter, the caller must pass both the physical and the virtual addresses of the communication buffer.
+ * If no virtual remapping has taken place, the physical address will be equal to the virtual address, and so the caller is required to pass the same value for both parameters.
+
+ ## Related Definitions
+ typedef struct {
+ EFI_GUID HeaderGuid;
+ UINT32 Signature;
+ UINT32 Version;
+ EFI_GUID MessageGuid;
+ UINT64 MessageSize;
+ UINT8 MessageData[ANYSIZE_ARRAY];
+ } EFI_MM_COMMUNICATE_HEADER_V3;
+
+ #define COMMUNICATE_HEADER_V3_GUID \
+ { \
+ 0x68e8c853, 0x2ba9, 0x4dd7, { 0x9a, 0xc0, 0x91, 0xe1, 0x61, 0x55, 0xc9, 0x35 } \
+ }
+
+ #define EFI_MM_COMMUNICATE_HEADER_V3_SIGNATURE 0x4D434833 // "MCH3"
+ #define EFI_MM_COMMUNICATE_HEADER_V3_VERSION 3
+
+ ### HeaderGuid
+
+ Indicator GUID for MM core that the communication buffer is compliant with this v3 header. Must be COMMUNICATE_HEADER_V3_GUID.
+
+ ### Signature
+
+ Signature to indicate data is compliant with new MM communicate header structure. Must be "MCH3".
+
+ ### Version
+
+ MM communicate data format version, MM foundation entry point should check if incoming data is a supported format before proceeding. Must be 3.
+
+ ### MessageGuid
+
+ Allows for disambiguation of the message format.
+
+ ### MessageSize
+
+ Describes the size of MessageData (in bytes) and does not include the size of the header.
+
+ ### MessageData
+
+ Designates an array of bytes that is MessageSize in size.
+
+ ## Status Codes Returned
+
+ EFI_SUCCESS The message was successfully posted.
+ EFI_INVALID_PARAMETER CommBufferPhysical was NULL or CommBufferVirtual was NULL.
+ EFI_BAD_BUFFER_SIZE The buffer is too large for the MM implementation. If this error is returned, the MessageLength field in the CommBuffer header or the integer pointed by CommSize, are updated to reflect the maximum payload size the implementation can accommodate.
+ EFI_ACCESS_DENIED The CommunicateBuffer parameter or CommSize parameter, if not omitted, are in address range that cannot be accessed by the MM environment.
+ ```
+
+### Code Changes
+
+1. Add data structure and its related definitions in `MdePkg/Include/Pi/PiMultiPhase.h` to match new definition.
+
+1. Add interface definition of `MdePkg/Include/Protocol/MmCommunication3.h` and `MdePkg/Include/Protocol/MmCommunication3.h`, respectively, to match newly proposed interfaces.
+
+1. Extend PiSmmCore to inspect `HeaderGuid` of incoming communication data. If it matches `COMMUNICATE_HEADER_V3_GUID`, parse the incoming data to start with `EFI_MM_COMMUNICATE_HEADER_V3`, otherwise it will be parse as existing way.
+
+1. Extend StandaloneMmCore to inspect `HeaderGuid` of incoming communication data. If it matches `COMMUNICATE_HEADER_V3_GUID`, parse the incoming data to start with `EFI_MM_COMMUNICATE_HEADER_V3`, otherwise it will be parse as existing way.
+
+1. Extend PiSmmIpl to publish `EFI_MM_COMMUNICATION3_PROTOCOL`, the implementation of `EFI_MM_COMMUNICATION3_PROTOCOL.Communicate()` should parse the incoming data as it starts with `EFI_MM_COMMUNICATE_HEADER_V3`, when applicable.
--
2.34.1.windows.1