* [PATCH] MdePkg: Add MmAccess and MmControl definition.
@ 2019-07-29 4:25 Marc W Chen
2019-08-01 8:42 ` [edk2-devel] " Liming Gao
0 siblings, 1 reply; 18+ messages in thread
From: Marc W Chen @ 2019-07-29 4:25 UTC (permalink / raw)
To: devel; +Cc: Michael D Kinney, Liming Gao, Ray Ni
EFI MmAccess and MmControl PPIs are defined in the PI 1.5 specification.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
---
MdePkg/Include/Ppi/MmAccess.h | 155 +++++++++++++++++++++++++++++++++++++++++
MdePkg/Include/Ppi/MmControl.h | 90 ++++++++++++++++++++++++
MdePkg/MdePkg.dec | 6 ++
3 files changed, 251 insertions(+)
create mode 100644 MdePkg/Include/Ppi/MmAccess.h
create mode 100644 MdePkg/Include/Ppi/MmControl.h
diff --git a/MdePkg/Include/Ppi/MmAccess.h b/MdePkg/Include/Ppi/MmAccess.h
new file mode 100644
index 0000000000..636e7288a0
--- /dev/null
+++ b/MdePkg/Include/Ppi/MmAccess.h
@@ -0,0 +1,155 @@
+/** @file
+ EFI MM Access PPI definition.
+
+ This PPI is used to control the visibility of the MMRAM on the platform.
+ The EFI_PEI_MM_ACCESS_PPI abstracts the location and characteristics of MMRAM. The
+ principal functionality found in the memory controller includes the following:
+ - Exposing the MMRAM to all non-MM agents, or the "open" state
+ - Shrouding the MMRAM to all but the MM agents, or the "closed" state
+ - Preserving the system integrity, or "locking" the MMRAM, such that the settings cannot be
+ perturbed by either boot service or runtime agents
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Revision Reference:
+ This PPI is introduced in PI Version 1.5.
+
+**/
+
+#ifndef _MM_ACCESS_PPI_H_
+#define _MM_ACCESS_PPI_H_
+
+#define EFI_PEI_MM_ACCESS_PPI_GUID \
+ { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
+
+typedef struct _EFI_PEI_MM_ACCESS_PPI EFI_PEI_MM_ACCESS_PPI;
+
+/**
+ Opens the MMRAM area to be accessible by a PEIM.
+
+ This function "opens" MMRAM so that it is visible while not inside of MM. The function should
+ return EFI_UNSUPPORTED if the hardware does not support hiding of MMRAM. The function
+ should return EFI_DEVICE_ERROR if the MMRAM configuration is locked.
+
+ @param PeiServices An indirect pointer to the PEI Services Table published by the PEI Foundation.
+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
+ @param DescriptorIndex The region of MMRAM to Open.
+
+ @retval EFI_SUCCESS The operation was successful.
+ @retval EFI_UNSUPPORTED The system does not support opening and closing of MMRAM.
+ @retval EFI_DEVICE_ERROR MMRAM cannot be opened, perhaps because it is locked.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_OPEN)(
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_ACCESS_PPI *This,
+ IN UINTN DescriptorIndex
+ );
+
+/**
+ Inhibits access to the MMRAM.
+
+ This function "closes" MMRAM so that it is not visible while outside of MM. The function should
+ return EFI_UNSUPPORTED if the hardware does not support hiding of MMRAM.
+
+ @param PeiServices An indirect pointer to the PEI Services Table published by the PEI Foundation.
+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
+ @param DescriptorIndex The region of MMRAM to Close.
+
+ @retval EFI_SUCCESS The operation was successful.
+ @retval EFI_UNSUPPORTED The system does not support opening and closing of MMRAM.
+ @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_CLOSE)(
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_ACCESS_PPI *This,
+ IN UINTN DescriptorIndex
+ );
+
+/**
+ This function prohibits access to the MMRAM region. This function is usually implemented such
+ that it is a write-once operation.
+
+ @param PeiServices An indirect pointer to the PEI Services Table published by the PEI Foundation.
+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
+ @param DescriptorIndex The region of MMRAM to Lock.
+
+ @retval EFI_SUCCESS The operation was successful.
+ @retval EFI_UNSUPPORTED The system does not support opening and closing of MMRAM.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_LOCK)(
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_ACCESS_PPI *This,
+ IN UINTN DescriptorIndex
+ );
+
+/**
+ Queries the memory controller for the possible regions that will support MMRAM.
+
+ This function describes the MMRAM regions.
+ This data structure forms the contract between the MM_ACCESS and MM_IPL drivers. There is an
+ ambiguity when any MMRAM region is remapped. For example, on some chipsets, some MMRAM
+ regions can be initialized at one physical address but is later accessed at another processor address.
+ There is currently no way for the MM IPL driver to know that it must use two different addresses
+ depending on what it is trying to do. As a result, initial configuration and loading can use the
+ physical address PhysicalStart while MMRAM is open. However, once the region has been
+ closed and needs to be accessed by agents in MM, the CpuStart address must be used.
+ This PPI publishes the available memory that the chipset can shroud for the use of installing code.
+ These regions serve the dual purpose of describing which regions have been open, closed, or locked.
+ In addition, these regions may include overlapping memory ranges, depending on the chipset
+ implementation. The latter might include a chipset that supports T-SEG, where memory near the top
+ of the physical DRAM can be allocated for MMRAM too.
+ The key thing to note is that the regions that are described by the PPI are a subset of the capabilities
+ of the hardware.
+
+ @param PeiServices An indirect pointer to the PEI Services Table published by the PEI Foundation.
+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
+ @param MmramMapSize A pointer to the size, in bytes, of the MmramMemoryMap buffer. On input, this value is
+ the size of the buffer that is allocated by the caller. On output, it is the size of the
+ buffer that was returned by the firmware if the buffer was large enough, or, if the
+ buffer was too small, the size of the buffer that is needed to contain the map.
+ @param MmramMap A pointer to the buffer in which firmware places the current memory map. The map is
+ an array of EFI_MMRAM_DESCRIPTORs
+
+ @retval EFI_SUCCESS The chipset supported the given resource.
+ @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter was too small. The current
+ buffer size needed to hold the memory map is returned in
+ MmramMapSize.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_ACCESS_PPI *This,
+ IN OUT UINTN *MmramMapSize,
+ IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
+ );
+
+///
+/// EFI MM Access PPI is used to control the visibility of the MMRAM on the platform.
+/// It abstracts the location and characteristics of MMRAM. The platform should report
+/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is that the north bridge or
+/// memory controller would publish this PPI.
+///
+struct _EFI_PEI_MM_ACCESS_PPI {
+ EFI_PEI_MM_OPEN Open;
+ EFI_PEI_MM_CLOSE Close;
+ EFI_PEI_MM_LOCK Lock;
+ EFI_PEI_MM_CAPABILITIES GetCapabilities;
+ BOOLEAN LockState;
+ BOOLEAN OpenState;
+};
+
+extern EFI_GUID gEfiPeiMmAccessPpiGuid;
+
+#endif
diff --git a/MdePkg/Include/Ppi/MmControl.h b/MdePkg/Include/Ppi/MmControl.h
new file mode 100644
index 0000000000..983ed95cd5
--- /dev/null
+++ b/MdePkg/Include/Ppi/MmControl.h
@@ -0,0 +1,90 @@
+/** @file
+ EFI MM Control PPI definition.
+
+ This PPI is used initiate synchronous MMI activations. This PPI could be published by a processor
+ driver to abstract the MMI IPI or a driver which abstracts the ASIC that is supporting the APM port.
+ Because of the possibility of performing MMI IPI transactions, the ability to generate this event
+ from a platform chipset agent is an optional capability for both IA-32 and x64-based systems.
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Revision Reference:
+ This PPI is introduced in PI Version 1.5.
+
+**/
+
+
+#ifndef _MM_CONTROL_PPI_H_
+#define _MM_CONTROL_PPI_H_
+
+#define EFI_PEI_MM_CONTROL_PPI_GUID \
+ { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }
+
+typedef struct _EFI_PEI_MM_CONTROL_PPI EFI_PEI_MM_CONTROL_PPI;
+
+/**
+ Invokes PPI activation from the PI PEI environment.
+
+ @param PeiServices An indirect pointer to the PEI Services Table published by the PEI Foundation.
+ @param This The PEI_MM_CONTROL_PPI instance.
+ @param ArgumentBuffer The value passed to the MMI handler. This value corresponds to the
+ SwMmiInputValue in the RegisterContext parameter for the Register()
+ function in the EFI_MM_SW_DISPATCH_PROTOCOL and in the Context parameter
+ in the call to the DispatchFunction
+ @param ArgumentBufferSize The size of the data passed in ArgumentBuffer or NULL if ArgumentBuffer is NULL.
+ @param Periodic An optional mechanism to periodically repeat activation.
+ @param ActivationInterval An optional parameter to repeat at this period one
+ time or, if the Periodic Boolean is set, periodically.
+
+ @retval EFI_SUCCESS The MMI has been engendered.
+ @retval EFI_DEVICE_ERROR The timing is unsupported.
+ @retval EFI_INVALID_PARAMETER The activation period is unsupported.
+ @retval EFI_NOT_STARTED The MM base service has not been initialized.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_ACTIVATE) (
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_CONTROL_PPI * This,
+ IN OUT INT8 *ArgumentBuffer OPTIONAL,
+ IN OUT UINTN *ArgumentBufferSize OPTIONAL,
+ IN BOOLEAN Periodic OPTIONAL,
+ IN UINTN ActivationInterval OPTIONAL
+ );
+
+/**
+ Clears any system state that was created in response to the Trigger() call.
+
+ @param PeiServices General purpose services available to every PEIM.
+ @param This The PEI_MM_CONTROL_PPI instance.
+ @param Periodic Optional parameter to repeat at this period one
+ time or, if the Periodic Boolean is set, periodically.
+
+ @retval EFI_SUCCESS The MMI has been engendered.
+ @retval EFI_DEVICE_ERROR The source could not be cleared.
+ @retval EFI_INVALID_PARAMETER The service did not support the Periodic input argument.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *PEI_MM_DEACTIVATE) (
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_CONTROL_PPI * This,
+ IN BOOLEAN Periodic OPTIONAL
+ );
+
+///
+/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It provides an abstraction of the
+/// platform hardware that generates an MMI. There are often I/O ports that, when accessed, will
+/// generate the MMI. Also, the hardware optionally supports the periodic generation of these signals.
+///
+struct _PEI_MM_CONTROL_PPI {
+ PEI_MM_ACTIVATE Trigger;
+ PEI_MM_DEACTIVATE Clear;
+};
+
+extern EFI_GUID gEfiPeiMmControlPpiGuid;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index b382efd578..34e0f39395 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -925,6 +925,12 @@
## Include/Ppi/SecHobData.h
gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4, 0xee, 0xf5, 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
+ ## Include/Ppi/MmAccess.h
+ gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
+
+ ## Include/Ppi/MmControl.h
+ gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43, { 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
+
#
# PPIs defined in PI 1.7.
#
--
2.16.2.windows.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-07-29 4:25 [PATCH] MdePkg: Add MmAccess and MmControl definition Marc W Chen
@ 2019-08-01 8:42 ` Liming Gao
2019-08-01 8:48 ` Marc W Chen
2019-08-01 8:52 ` Marc W Chen
0 siblings, 2 replies; 18+ messages in thread
From: Liming Gao @ 2019-08-01 8:42 UTC (permalink / raw)
To: devel@edk2.groups.io, Chen, Marc W; +Cc: Kinney, Michael D, Ni, Ray
Marc:
The change is good. Reviewed-by: Liming Gao <liming.gao@intel.com>
Besides, I see BZ also mention to remove the one in MdeModulePkg. Have you the following patches for the change in MdeModulePkg?
Thanks
Liming
>-----Original Message-----
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Marc W Chen
>Sent: Monday, July 29, 2019 12:26 PM
>To: devel@edk2.groups.io
>Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
><liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
>Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
>definition.
>
>EFI MmAccess and MmControl PPIs are defined in the PI 1.5 specification.
>
>Cc: Michael D Kinney <michael.d.kinney@intel.com>
>Cc: Liming Gao <liming.gao@intel.com>
>Cc: Ray Ni <ray.ni@intel.com>
>Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
>Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
>---
> MdePkg/Include/Ppi/MmAccess.h | 155
>+++++++++++++++++++++++++++++++++++++++++
> MdePkg/Include/Ppi/MmControl.h | 90 ++++++++++++++++++++++++
> MdePkg/MdePkg.dec | 6 ++
> 3 files changed, 251 insertions(+)
> create mode 100644 MdePkg/Include/Ppi/MmAccess.h
> create mode 100644 MdePkg/Include/Ppi/MmControl.h
>
>diff --git a/MdePkg/Include/Ppi/MmAccess.h
>b/MdePkg/Include/Ppi/MmAccess.h
>new file mode 100644
>index 0000000000..636e7288a0
>--- /dev/null
>+++ b/MdePkg/Include/Ppi/MmAccess.h
>@@ -0,0 +1,155 @@
>+/** @file
>+ EFI MM Access PPI definition.
>+
>+ This PPI is used to control the visibility of the MMRAM on the platform.
>+ The EFI_PEI_MM_ACCESS_PPI abstracts the location and characteristics of
>MMRAM. The
>+ principal functionality found in the memory controller includes the following:
>+ - Exposing the MMRAM to all non-MM agents, or the "open" state
>+ - Shrouding the MMRAM to all but the MM agents, or the "closed" state
>+ - Preserving the system integrity, or "locking" the MMRAM, such that the
>settings cannot be
>+ perturbed by either boot service or runtime agents
>+
>+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
>+ SPDX-License-Identifier: BSD-2-Clause-Patent
>+
>+ @par Revision Reference:
>+ This PPI is introduced in PI Version 1.5.
>+
>+**/
>+
>+#ifndef _MM_ACCESS_PPI_H_
>+#define _MM_ACCESS_PPI_H_
>+
>+#define EFI_PEI_MM_ACCESS_PPI_GUID \
>+ { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a, 0xc3, 0x2e,
>0xd6 }}
>+
>+typedef struct _EFI_PEI_MM_ACCESS_PPI EFI_PEI_MM_ACCESS_PPI;
>+
>+/**
>+ Opens the MMRAM area to be accessible by a PEIM.
>+
>+ This function "opens" MMRAM so that it is visible while not inside of MM.
>The function should
>+ return EFI_UNSUPPORTED if the hardware does not support hiding of
>MMRAM. The function
>+ should return EFI_DEVICE_ERROR if the MMRAM configuration is locked.
>+
>+ @param PeiServices An indirect pointer to the PEI Services Table
>published by the PEI Foundation.
>+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
>+ @param DescriptorIndex The region of MMRAM to Open.
>+
>+ @retval EFI_SUCCESS The operation was successful.
>+ @retval EFI_UNSUPPORTED The system does not support opening and
>closing of MMRAM.
>+ @retval EFI_DEVICE_ERROR MMRAM cannot be opened, perhaps
>because it is locked.
>+
>+**/
>+typedef
>+EFI_STATUS
>+(EFIAPI *EFI_PEI_MM_OPEN)(
>+ IN EFI_PEI_SERVICES **PeiServices,
>+ IN EFI_PEI_MM_ACCESS_PPI *This,
>+ IN UINTN DescriptorIndex
>+ );
>+
>+/**
>+ Inhibits access to the MMRAM.
>+
>+ This function "closes" MMRAM so that it is not visible while outside of MM.
>The function should
>+ return EFI_UNSUPPORTED if the hardware does not support hiding of
>MMRAM.
>+
>+ @param PeiServices An indirect pointer to the PEI Services Table
>published by the PEI Foundation.
>+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
>+ @param DescriptorIndex The region of MMRAM to Close.
>+
>+ @retval EFI_SUCCESS The operation was successful.
>+ @retval EFI_UNSUPPORTED The system does not support opening and
>closing of MMRAM.
>+ @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
>+
>+**/
>+typedef
>+EFI_STATUS
>+(EFIAPI *EFI_PEI_MM_CLOSE)(
>+ IN EFI_PEI_SERVICES **PeiServices,
>+ IN EFI_PEI_MM_ACCESS_PPI *This,
>+ IN UINTN DescriptorIndex
>+ );
>+
>+/**
>+ This function prohibits access to the MMRAM region. This function is usually
>implemented such
>+ that it is a write-once operation.
>+
>+ @param PeiServices An indirect pointer to the PEI Services Table
>published by the PEI Foundation.
>+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
>+ @param DescriptorIndex The region of MMRAM to Lock.
>+
>+ @retval EFI_SUCCESS The operation was successful.
>+ @retval EFI_UNSUPPORTED The system does not support opening and
>closing of MMRAM.
>+
>+**/
>+typedef
>+EFI_STATUS
>+(EFIAPI *EFI_PEI_MM_LOCK)(
>+ IN EFI_PEI_SERVICES **PeiServices,
>+ IN EFI_PEI_MM_ACCESS_PPI *This,
>+ IN UINTN DescriptorIndex
>+ );
>+
>+/**
>+ Queries the memory controller for the possible regions that will support
>MMRAM.
>+
>+ This function describes the MMRAM regions.
>+ This data structure forms the contract between the MM_ACCESS and
>MM_IPL drivers. There is an
>+ ambiguity when any MMRAM region is remapped. For example, on some
>chipsets, some MMRAM
>+ regions can be initialized at one physical address but is later accessed at
>another processor address.
>+ There is currently no way for the MM IPL driver to know that it must use
>two different addresses
>+ depending on what it is trying to do. As a result, initial configuration and
>loading can use the
>+ physical address PhysicalStart while MMRAM is open. However, once the
>region has been
>+ closed and needs to be accessed by agents in MM, the CpuStart address
>must be used.
>+ This PPI publishes the available memory that the chipset can shroud for the
>use of installing code.
>+ These regions serve the dual purpose of describing which regions have
>been open, closed, or locked.
>+ In addition, these regions may include overlapping memory ranges,
>depending on the chipset
>+ implementation. The latter might include a chipset that supports T-SEG,
>where memory near the top
>+ of the physical DRAM can be allocated for MMRAM too.
>+ The key thing to note is that the regions that are described by the PPI are a
>subset of the capabilities
>+ of the hardware.
>+
>+ @param PeiServices An indirect pointer to the PEI Services Table
>published by the PEI Foundation.
>+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
>+ @param MmramMapSize A pointer to the size, in bytes, of the
>MmramMemoryMap buffer. On input, this value is
>+ the size of the buffer that is allocated by the caller. On
>output, it is the size of the
>+ buffer that was returned by the firmware if the buffer was
>large enough, or, if the
>+ buffer was too small, the size of the buffer that is needed to
>contain the map.
>+ @param MmramMap A pointer to the buffer in which firmware
>places the current memory map. The map is
>+ an array of EFI_MMRAM_DESCRIPTORs
>+
>+ @retval EFI_SUCCESS The chipset supported the given resource.
>+ @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter was too
>small. The current
>+ buffer size needed to hold the memory map is returned in
>+ MmramMapSize.
>+
>+**/
>+typedef
>+EFI_STATUS
>+(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
>+ IN EFI_PEI_SERVICES **PeiServices,
>+ IN EFI_PEI_MM_ACCESS_PPI *This,
>+ IN OUT UINTN *MmramMapSize,
>+ IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
>+ );
>+
>+///
>+/// EFI MM Access PPI is used to control the visibility of the MMRAM on the
>platform.
>+/// It abstracts the location and characteristics of MMRAM. The platform
>should report
>+/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is that the
>north bridge or
>+/// memory controller would publish this PPI.
>+///
>+struct _EFI_PEI_MM_ACCESS_PPI {
>+ EFI_PEI_MM_OPEN Open;
>+ EFI_PEI_MM_CLOSE Close;
>+ EFI_PEI_MM_LOCK Lock;
>+ EFI_PEI_MM_CAPABILITIES GetCapabilities;
>+ BOOLEAN LockState;
>+ BOOLEAN OpenState;
>+};
>+
>+extern EFI_GUID gEfiPeiMmAccessPpiGuid;
>+
>+#endif
>diff --git a/MdePkg/Include/Ppi/MmControl.h
>b/MdePkg/Include/Ppi/MmControl.h
>new file mode 100644
>index 0000000000..983ed95cd5
>--- /dev/null
>+++ b/MdePkg/Include/Ppi/MmControl.h
>@@ -0,0 +1,90 @@
>+/** @file
>+ EFI MM Control PPI definition.
>+
>+ This PPI is used initiate synchronous MMI activations. This PPI could be
>published by a processor
>+ driver to abstract the MMI IPI or a driver which abstracts the ASIC that is
>supporting the APM port.
>+ Because of the possibility of performing MMI IPI transactions, the ability to
>generate this event
>+ from a platform chipset agent is an optional capability for both IA-32 and
>x64-based systems.
>+
>+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
>+ SPDX-License-Identifier: BSD-2-Clause-Patent
>+
>+ @par Revision Reference:
>+ This PPI is introduced in PI Version 1.5.
>+
>+**/
>+
>+
>+#ifndef _MM_CONTROL_PPI_H_
>+#define _MM_CONTROL_PPI_H_
>+
>+#define EFI_PEI_MM_CONTROL_PPI_GUID \
>+ { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }
>+
>+typedef struct _EFI_PEI_MM_CONTROL_PPI EFI_PEI_MM_CONTROL_PPI;
>+
>+/**
>+ Invokes PPI activation from the PI PEI environment.
>+
>+ @param PeiServices An indirect pointer to the PEI Services Table
>published by the PEI Foundation.
>+ @param This The PEI_MM_CONTROL_PPI instance.
>+ @param ArgumentBuffer The value passed to the MMI handler. This
>value corresponds to the
>+ SwMmiInputValue in the RegisterContext parameter for the
>Register()
>+ function in the EFI_MM_SW_DISPATCH_PROTOCOL and in
>the Context parameter
>+ in the call to the DispatchFunction
>+ @param ArgumentBufferSize The size of the data passed in
>ArgumentBuffer or NULL if ArgumentBuffer is NULL.
>+ @param Periodic An optional mechanism to periodically repeat
>activation.
>+ @param ActivationInterval An optional parameter to repeat at this period
>one
>+ time or, if the Periodic Boolean is set, periodically.
>+
>+ @retval EFI_SUCCESS The MMI has been engendered.
>+ @retval EFI_DEVICE_ERROR The timing is unsupported.
>+ @retval EFI_INVALID_PARAMETER The activation period is unsupported.
>+ @retval EFI_NOT_STARTED The MM base service has not been initialized.
>+
>+**/
>+typedef
>+EFI_STATUS
>+(EFIAPI *EFI_PEI_MM_ACTIVATE) (
>+ IN EFI_PEI_SERVICES **PeiServices,
>+ IN EFI_PEI_MM_CONTROL_PPI * This,
>+ IN OUT INT8 *ArgumentBuffer OPTIONAL,
>+ IN OUT UINTN *ArgumentBufferSize OPTIONAL,
>+ IN BOOLEAN Periodic OPTIONAL,
>+ IN UINTN ActivationInterval OPTIONAL
>+ );
>+
>+/**
>+ Clears any system state that was created in response to the Trigger() call.
>+
>+ @param PeiServices General purpose services available to every PEIM.
>+ @param This The PEI_MM_CONTROL_PPI instance.
>+ @param Periodic Optional parameter to repeat at this period one
>+ time or, if the Periodic Boolean is set, periodically.
>+
>+ @retval EFI_SUCCESS The MMI has been engendered.
>+ @retval EFI_DEVICE_ERROR The source could not be cleared.
>+ @retval EFI_INVALID_PARAMETER The service did not support the Periodic
>input argument.
>+
>+**/
>+typedef
>+EFI_STATUS
>+(EFIAPI *PEI_MM_DEACTIVATE) (
>+ IN EFI_PEI_SERVICES **PeiServices,
>+ IN EFI_PEI_MM_CONTROL_PPI * This,
>+ IN BOOLEAN Periodic OPTIONAL
>+ );
>+
>+///
>+/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It provides an
>abstraction of the
>+/// platform hardware that generates an MMI. There are often I/O ports
>that, when accessed, will
>+/// generate the MMI. Also, the hardware optionally supports the periodic
>generation of these signals.
>+///
>+struct _PEI_MM_CONTROL_PPI {
>+ PEI_MM_ACTIVATE Trigger;
>+ PEI_MM_DEACTIVATE Clear;
>+};
>+
>+extern EFI_GUID gEfiPeiMmControlPpiGuid;
>+
>+#endif
>diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
>index b382efd578..34e0f39395 100644
>--- a/MdePkg/MdePkg.dec
>+++ b/MdePkg/MdePkg.dec
>@@ -925,6 +925,12 @@
> ## Include/Ppi/SecHobData.h
> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4, 0xee, 0xf5,
>0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
>
>+ ## Include/Ppi/MmAccess.h
>+ gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17,
>0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
>+
>+ ## Include/Ppi/MmControl.h
>+ gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43, { 0x8d, 0xef,
>0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
>+
> #
> # PPIs defined in PI 1.7.
> #
>--
>2.16.2.windows.1
>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-01 8:42 ` [edk2-devel] " Liming Gao
@ 2019-08-01 8:48 ` Marc W Chen
2019-08-02 2:12 ` Laszlo Ersek
2019-08-01 8:52 ` Marc W Chen
1 sibling, 1 reply; 18+ messages in thread
From: Marc W Chen @ 2019-08-01 8:48 UTC (permalink / raw)
To: Gao, Liming, devel@edk2.groups.io; +Cc: Kinney, Michael D, Ni, Ray
Hi Liming
Since there are multiple packages are still using SmmAccess.h, we need to change all packages to use MmAccess.h instead of SmmAccess.h first, then clean up SmmAccess.h from MdeModulePkg will be the last step.
Below are the packages that has "include <Ppi/SmmAccess.h>" for your reference.
* Edk2 repo:
o MdeModulePkg
o OvmfPkg
o UefiCpuPkg
* Edk2Platform repo:
o MinPlatformPkg
o QuarkSocPkg
Thanks,
Marc
> -----Original Message-----
> From: Gao, Liming
> Sent: Thursday, August 1, 2019 4:42 PM
> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> <ray.ni@intel.com>
> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> definition.
>
> Marc:
> The change is good. Reviewed-by: Liming Gao <liming.gao@intel.com>
>
> Besides, I see BZ also mention to remove the one in MdeModulePkg. Have
> you the following patches for the change in MdeModulePkg?
>
> Thanks
> Liming
> >-----Original Message-----
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >Marc W Chen
> >Sent: Monday, July 29, 2019 12:26 PM
> >To: devel@edk2.groups.io
> >Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> ><liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> >Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> >definition.
> >
> >EFI MmAccess and MmControl PPIs are defined in the PI 1.5 specification.
> >
> >Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >Cc: Liming Gao <liming.gao@intel.com>
> >Cc: Ray Ni <ray.ni@intel.com>
> >Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> >Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> >---
> > MdePkg/Include/Ppi/MmAccess.h | 155
> >+++++++++++++++++++++++++++++++++++++++++
> > MdePkg/Include/Ppi/MmControl.h | 90 ++++++++++++++++++++++++
> > MdePkg/MdePkg.dec | 6 ++
> > 3 files changed, 251 insertions(+)
> > create mode 100644 MdePkg/Include/Ppi/MmAccess.h
> > create mode 100644 MdePkg/Include/Ppi/MmControl.h
> >
> >diff --git a/MdePkg/Include/Ppi/MmAccess.h
> >b/MdePkg/Include/Ppi/MmAccess.h
> >new file mode 100644
> >index 0000000000..636e7288a0
> >--- /dev/null
> >+++ b/MdePkg/Include/Ppi/MmAccess.h
> >@@ -0,0 +1,155 @@
> >+/** @file
> >+ EFI MM Access PPI definition.
> >+
> >+ This PPI is used to control the visibility of the MMRAM on the platform.
> >+ The EFI_PEI_MM_ACCESS_PPI abstracts the location and characteristics of
> >MMRAM. The
> >+ principal functionality found in the memory controller includes the
> following:
> >+ - Exposing the MMRAM to all non-MM agents, or the "open" state
> >+ - Shrouding the MMRAM to all but the MM agents, or the "closed" state
> >+ - Preserving the system integrity, or "locking" the MMRAM, such that the
> >settings cannot be
> >+ perturbed by either boot service or runtime agents
> >+
> >+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
> >+ SPDX-License-Identifier: BSD-2-Clause-Patent
> >+
> >+ @par Revision Reference:
> >+ This PPI is introduced in PI Version 1.5.
> >+
> >+**/
> >+
> >+#ifndef _MM_ACCESS_PPI_H_
> >+#define _MM_ACCESS_PPI_H_
> >+
> >+#define EFI_PEI_MM_ACCESS_PPI_GUID \
> >+ { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a, 0xc3, 0x2e,
> >0xd6 }}
> >+
> >+typedef struct _EFI_PEI_MM_ACCESS_PPI EFI_PEI_MM_ACCESS_PPI;
> >+
> >+/**
> >+ Opens the MMRAM area to be accessible by a PEIM.
> >+
> >+ This function "opens" MMRAM so that it is visible while not inside of MM.
> >The function should
> >+ return EFI_UNSUPPORTED if the hardware does not support hiding of
> >MMRAM. The function
> >+ should return EFI_DEVICE_ERROR if the MMRAM configuration is locked.
> >+
> >+ @param PeiServices An indirect pointer to the PEI Services Table
> >published by the PEI Foundation.
> >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >+ @param DescriptorIndex The region of MMRAM to Open.
> >+
> >+ @retval EFI_SUCCESS The operation was successful.
> >+ @retval EFI_UNSUPPORTED The system does not support opening
> and
> >closing of MMRAM.
> >+ @retval EFI_DEVICE_ERROR MMRAM cannot be opened, perhaps
> >because it is locked.
> >+
> >+**/
> >+typedef
> >+EFI_STATUS
> >+(EFIAPI *EFI_PEI_MM_OPEN)(
> >+ IN EFI_PEI_SERVICES **PeiServices,
> >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> >+ IN UINTN DescriptorIndex
> >+ );
> >+
> >+/**
> >+ Inhibits access to the MMRAM.
> >+
> >+ This function "closes" MMRAM so that it is not visible while outside of
> MM.
> >The function should
> >+ return EFI_UNSUPPORTED if the hardware does not support hiding of
> >MMRAM.
> >+
> >+ @param PeiServices An indirect pointer to the PEI Services Table
> >published by the PEI Foundation.
> >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >+ @param DescriptorIndex The region of MMRAM to Close.
> >+
> >+ @retval EFI_SUCCESS The operation was successful.
> >+ @retval EFI_UNSUPPORTED The system does not support opening
> and
> >closing of MMRAM.
> >+ @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> >+
> >+**/
> >+typedef
> >+EFI_STATUS
> >+(EFIAPI *EFI_PEI_MM_CLOSE)(
> >+ IN EFI_PEI_SERVICES **PeiServices,
> >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> >+ IN UINTN DescriptorIndex
> >+ );
> >+
> >+/**
> >+ This function prohibits access to the MMRAM region. This function is
> usually
> >implemented such
> >+ that it is a write-once operation.
> >+
> >+ @param PeiServices An indirect pointer to the PEI Services Table
> >published by the PEI Foundation.
> >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >+ @param DescriptorIndex The region of MMRAM to Lock.
> >+
> >+ @retval EFI_SUCCESS The operation was successful.
> >+ @retval EFI_UNSUPPORTED The system does not support opening
> and
> >closing of MMRAM.
> >+
> >+**/
> >+typedef
> >+EFI_STATUS
> >+(EFIAPI *EFI_PEI_MM_LOCK)(
> >+ IN EFI_PEI_SERVICES **PeiServices,
> >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> >+ IN UINTN DescriptorIndex
> >+ );
> >+
> >+/**
> >+ Queries the memory controller for the possible regions that will support
> >MMRAM.
> >+
> >+ This function describes the MMRAM regions.
> >+ This data structure forms the contract between the MM_ACCESS and
> >MM_IPL drivers. There is an
> >+ ambiguity when any MMRAM region is remapped. For example, on some
> >chipsets, some MMRAM
> >+ regions can be initialized at one physical address but is later accessed at
> >another processor address.
> >+ There is currently no way for the MM IPL driver to know that it must use
> >two different addresses
> >+ depending on what it is trying to do. As a result, initial configuration and
> >loading can use the
> >+ physical address PhysicalStart while MMRAM is open. However, once the
> >region has been
> >+ closed and needs to be accessed by agents in MM, the CpuStart address
> >must be used.
> >+ This PPI publishes the available memory that the chipset can shroud for
> the
> >use of installing code.
> >+ These regions serve the dual purpose of describing which regions have
> >been open, closed, or locked.
> >+ In addition, these regions may include overlapping memory ranges,
> >depending on the chipset
> >+ implementation. The latter might include a chipset that supports T-SEG,
> >where memory near the top
> >+ of the physical DRAM can be allocated for MMRAM too.
> >+ The key thing to note is that the regions that are described by the PPI are
> a
> >subset of the capabilities
> >+ of the hardware.
> >+
> >+ @param PeiServices An indirect pointer to the PEI Services Table
> >published by the PEI Foundation.
> >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >+ @param MmramMapSize A pointer to the size, in bytes, of the
> >MmramMemoryMap buffer. On input, this value is
> >+ the size of the buffer that is allocated by the caller. On
> >output, it is the size of the
> >+ buffer that was returned by the firmware if the buffer
> was
> >large enough, or, if the
> >+ buffer was too small, the size of the buffer that is
> needed to
> >contain the map.
> >+ @param MmramMap A pointer to the buffer in which firmware
> >places the current memory map. The map is
> >+ an array of EFI_MMRAM_DESCRIPTORs
> >+
> >+ @retval EFI_SUCCESS The chipset supported the given resource.
> >+ @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter was too
> >small. The current
> >+ buffer size needed to hold the memory map is returned
> in
> >+ MmramMapSize.
> >+
> >+**/
> >+typedef
> >+EFI_STATUS
> >+(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> >+ IN EFI_PEI_SERVICES **PeiServices,
> >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> >+ IN OUT UINTN *MmramMapSize,
> >+ IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> >+ );
> >+
> >+///
> >+/// EFI MM Access PPI is used to control the visibility of the MMRAM on
> the
> >platform.
> >+/// It abstracts the location and characteristics of MMRAM. The platform
> >should report
> >+/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is that the
> >north bridge or
> >+/// memory controller would publish this PPI.
> >+///
> >+struct _EFI_PEI_MM_ACCESS_PPI {
> >+ EFI_PEI_MM_OPEN Open;
> >+ EFI_PEI_MM_CLOSE Close;
> >+ EFI_PEI_MM_LOCK Lock;
> >+ EFI_PEI_MM_CAPABILITIES GetCapabilities;
> >+ BOOLEAN LockState;
> >+ BOOLEAN OpenState;
> >+};
> >+
> >+extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> >+
> >+#endif
> >diff --git a/MdePkg/Include/Ppi/MmControl.h
> >b/MdePkg/Include/Ppi/MmControl.h
> >new file mode 100644
> >index 0000000000..983ed95cd5
> >--- /dev/null
> >+++ b/MdePkg/Include/Ppi/MmControl.h
> >@@ -0,0 +1,90 @@
> >+/** @file
> >+ EFI MM Control PPI definition.
> >+
> >+ This PPI is used initiate synchronous MMI activations. This PPI could be
> >published by a processor
> >+ driver to abstract the MMI IPI or a driver which abstracts the ASIC that is
> >supporting the APM port.
> >+ Because of the possibility of performing MMI IPI transactions, the ability
> to
> >generate this event
> >+ from a platform chipset agent is an optional capability for both IA-32 and
> >x64-based systems.
> >+
> >+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
> >+ SPDX-License-Identifier: BSD-2-Clause-Patent
> >+
> >+ @par Revision Reference:
> >+ This PPI is introduced in PI Version 1.5.
> >+
> >+**/
> >+
> >+
> >+#ifndef _MM_CONTROL_PPI_H_
> >+#define _MM_CONTROL_PPI_H_
> >+
> >+#define EFI_PEI_MM_CONTROL_PPI_GUID \
> >+ { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce, 0x74,
> 0xc5 }
> >+
> >+typedef struct _EFI_PEI_MM_CONTROL_PPI EFI_PEI_MM_CONTROL_PPI;
> >+
> >+/**
> >+ Invokes PPI activation from the PI PEI environment.
> >+
> >+ @param PeiServices An indirect pointer to the PEI Services Table
> >published by the PEI Foundation.
> >+ @param This The PEI_MM_CONTROL_PPI instance.
> >+ @param ArgumentBuffer The value passed to the MMI handler. This
> >value corresponds to the
> >+ SwMmiInputValue in the RegisterContext parameter for
> the
> >Register()
> >+ function in the EFI_MM_SW_DISPATCH_PROTOCOL and
> in
> >the Context parameter
> >+ in the call to the DispatchFunction
> >+ @param ArgumentBufferSize The size of the data passed in
> >ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> >+ @param Periodic An optional mechanism to periodically repeat
> >activation.
> >+ @param ActivationInterval An optional parameter to repeat at this
> period
> >one
> >+ time or, if the Periodic Boolean is set, periodically.
> >+
> >+ @retval EFI_SUCCESS The MMI has been engendered.
> >+ @retval EFI_DEVICE_ERROR The timing is unsupported.
> >+ @retval EFI_INVALID_PARAMETER The activation period is unsupported.
> >+ @retval EFI_NOT_STARTED The MM base service has not been
> initialized.
> >+
> >+**/
> >+typedef
> >+EFI_STATUS
> >+(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> >+ IN EFI_PEI_SERVICES **PeiServices,
> >+ IN EFI_PEI_MM_CONTROL_PPI * This,
> >+ IN OUT INT8 *ArgumentBuffer OPTIONAL,
> >+ IN OUT UINTN *ArgumentBufferSize OPTIONAL,
> >+ IN BOOLEAN Periodic OPTIONAL,
> >+ IN UINTN ActivationInterval OPTIONAL
> >+ );
> >+
> >+/**
> >+ Clears any system state that was created in response to the Trigger() call.
> >+
> >+ @param PeiServices General purpose services available to every
> PEIM.
> >+ @param This The PEI_MM_CONTROL_PPI instance.
> >+ @param Periodic Optional parameter to repeat at this period one
> >+ time or, if the Periodic Boolean is set, periodically.
> >+
> >+ @retval EFI_SUCCESS The MMI has been engendered.
> >+ @retval EFI_DEVICE_ERROR The source could not be cleared.
> >+ @retval EFI_INVALID_PARAMETER The service did not support the
> Periodic
> >input argument.
> >+
> >+**/
> >+typedef
> >+EFI_STATUS
> >+(EFIAPI *PEI_MM_DEACTIVATE) (
> >+ IN EFI_PEI_SERVICES **PeiServices,
> >+ IN EFI_PEI_MM_CONTROL_PPI * This,
> >+ IN BOOLEAN Periodic OPTIONAL
> >+ );
> >+
> >+///
> >+/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It provides an
> >abstraction of the
> >+/// platform hardware that generates an MMI. There are often I/O ports
> >that, when accessed, will
> >+/// generate the MMI. Also, the hardware optionally supports the periodic
> >generation of these signals.
> >+///
> >+struct _PEI_MM_CONTROL_PPI {
> >+ PEI_MM_ACTIVATE Trigger;
> >+ PEI_MM_DEACTIVATE Clear;
> >+};
> >+
> >+extern EFI_GUID gEfiPeiMmControlPpiGuid;
> >+
> >+#endif
> >diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> >index b382efd578..34e0f39395 100644
> >--- a/MdePkg/MdePkg.dec
> >+++ b/MdePkg/MdePkg.dec
> >@@ -925,6 +925,12 @@
> > ## Include/Ppi/SecHobData.h
> > gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4, 0xee, 0xf5,
> >0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> >
> >+ ## Include/Ppi/MmAccess.h
> >+ gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be, { 0x88,
> 0x17,
> >0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> >+
> >+ ## Include/Ppi/MmControl.h
> >+ gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43, { 0x8d,
> 0xef,
> >0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> >+
> > #
> > # PPIs defined in PI 1.7.
> > #
> >--
> >2.16.2.windows.1
> >
> >
> >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-01 8:42 ` [edk2-devel] " Liming Gao
2019-08-01 8:48 ` Marc W Chen
@ 2019-08-01 8:52 ` Marc W Chen
2019-08-01 10:04 ` Ni, Ray
1 sibling, 1 reply; 18+ messages in thread
From: Marc W Chen @ 2019-08-01 8:52 UTC (permalink / raw)
To: Gao, Liming, devel@edk2.groups.io; +Cc: Kinney, Michael D, Ni, Ray
Hi Liming
Another thought, do you think it is ok to keep SmmAccess.h in MdeModulePkg? We can use #define and typedef to convert MmAccess to SmmAccess, just like current SmmAccess Protocol in MdePkg.
Thanks,
Marc
> -----Original Message-----
> From: Chen, Marc W
> Sent: Thursday, August 1, 2019 4:48 PM
> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> <ray.ni@intel.com>
> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> definition.
>
> Hi Liming
>
> Since there are multiple packages are still using SmmAccess.h, we need to
> change all packages to use MmAccess.h instead of SmmAccess.h first, then
> clean up SmmAccess.h from MdeModulePkg will be the last step.
> Below are the packages that has "include <Ppi/SmmAccess.h>" for your
> reference.
> * Edk2 repo:
> o MdeModulePkg
> o OvmfPkg
> o UefiCpuPkg
> * Edk2Platform repo:
> o MinPlatformPkg
> o QuarkSocPkg
>
> Thanks,
> Marc
>
> > -----Original Message-----
> > From: Gao, Liming
> > Sent: Thursday, August 1, 2019 4:42 PM
> > To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > <ray.ni@intel.com>
> > Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> > definition.
> >
> > Marc:
> > The change is good. Reviewed-by: Liming Gao <liming.gao@intel.com>
> >
> > Besides, I see BZ also mention to remove the one in MdeModulePkg. Have
> > you the following patches for the change in MdeModulePkg?
> >
> > Thanks
> > Liming
> > >-----Original Message-----
> > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > >Marc W Chen
> > >Sent: Monday, July 29, 2019 12:26 PM
> > >To: devel@edk2.groups.io
> > >Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> > ><liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> > >Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> > >definition.
> > >
> > >EFI MmAccess and MmControl PPIs are defined in the PI 1.5 specification.
> > >
> > >Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > >Cc: Liming Gao <liming.gao@intel.com>
> > >Cc: Ray Ni <ray.ni@intel.com>
> > >Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> > >Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> > >---
> > > MdePkg/Include/Ppi/MmAccess.h | 155
> > >+++++++++++++++++++++++++++++++++++++++++
> > > MdePkg/Include/Ppi/MmControl.h | 90 ++++++++++++++++++++++++
> > > MdePkg/MdePkg.dec | 6 ++
> > > 3 files changed, 251 insertions(+)
> > > create mode 100644 MdePkg/Include/Ppi/MmAccess.h
> > > create mode 100644 MdePkg/Include/Ppi/MmControl.h
> > >
> > >diff --git a/MdePkg/Include/Ppi/MmAccess.h
> > >b/MdePkg/Include/Ppi/MmAccess.h
> > >new file mode 100644
> > >index 0000000000..636e7288a0
> > >--- /dev/null
> > >+++ b/MdePkg/Include/Ppi/MmAccess.h
> > >@@ -0,0 +1,155 @@
> > >+/** @file
> > >+ EFI MM Access PPI definition.
> > >+
> > >+ This PPI is used to control the visibility of the MMRAM on the platform.
> > >+ The EFI_PEI_MM_ACCESS_PPI abstracts the location and characteristics
> of
> > >MMRAM. The
> > >+ principal functionality found in the memory controller includes the
> > following:
> > >+ - Exposing the MMRAM to all non-MM agents, or the "open" state
> > >+ - Shrouding the MMRAM to all but the MM agents, or the "closed" state
> > >+ - Preserving the system integrity, or "locking" the MMRAM, such that
> the
> > >settings cannot be
> > >+ perturbed by either boot service or runtime agents
> > >+
> > >+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
> > >+ SPDX-License-Identifier: BSD-2-Clause-Patent
> > >+
> > >+ @par Revision Reference:
> > >+ This PPI is introduced in PI Version 1.5.
> > >+
> > >+**/
> > >+
> > >+#ifndef _MM_ACCESS_PPI_H_
> > >+#define _MM_ACCESS_PPI_H_
> > >+
> > >+#define EFI_PEI_MM_ACCESS_PPI_GUID \
> > >+ { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a, 0xc3, 0x2e,
> > >0xd6 }}
> > >+
> > >+typedef struct _EFI_PEI_MM_ACCESS_PPI EFI_PEI_MM_ACCESS_PPI;
> > >+
> > >+/**
> > >+ Opens the MMRAM area to be accessible by a PEIM.
> > >+
> > >+ This function "opens" MMRAM so that it is visible while not inside of
> MM.
> > >The function should
> > >+ return EFI_UNSUPPORTED if the hardware does not support hiding of
> > >MMRAM. The function
> > >+ should return EFI_DEVICE_ERROR if the MMRAM configuration is locked.
> > >+
> > >+ @param PeiServices An indirect pointer to the PEI Services Table
> > >published by the PEI Foundation.
> > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >+ @param DescriptorIndex The region of MMRAM to Open.
> > >+
> > >+ @retval EFI_SUCCESS The operation was successful.
> > >+ @retval EFI_UNSUPPORTED The system does not support opening
> > and
> > >closing of MMRAM.
> > >+ @retval EFI_DEVICE_ERROR MMRAM cannot be opened, perhaps
> > >because it is locked.
> > >+
> > >+**/
> > >+typedef
> > >+EFI_STATUS
> > >+(EFIAPI *EFI_PEI_MM_OPEN)(
> > >+ IN EFI_PEI_SERVICES **PeiServices,
> > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > >+ IN UINTN DescriptorIndex
> > >+ );
> > >+
> > >+/**
> > >+ Inhibits access to the MMRAM.
> > >+
> > >+ This function "closes" MMRAM so that it is not visible while outside of
> > MM.
> > >The function should
> > >+ return EFI_UNSUPPORTED if the hardware does not support hiding of
> > >MMRAM.
> > >+
> > >+ @param PeiServices An indirect pointer to the PEI Services Table
> > >published by the PEI Foundation.
> > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >+ @param DescriptorIndex The region of MMRAM to Close.
> > >+
> > >+ @retval EFI_SUCCESS The operation was successful.
> > >+ @retval EFI_UNSUPPORTED The system does not support opening
> > and
> > >closing of MMRAM.
> > >+ @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> > >+
> > >+**/
> > >+typedef
> > >+EFI_STATUS
> > >+(EFIAPI *EFI_PEI_MM_CLOSE)(
> > >+ IN EFI_PEI_SERVICES **PeiServices,
> > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > >+ IN UINTN DescriptorIndex
> > >+ );
> > >+
> > >+/**
> > >+ This function prohibits access to the MMRAM region. This function is
> > usually
> > >implemented such
> > >+ that it is a write-once operation.
> > >+
> > >+ @param PeiServices An indirect pointer to the PEI Services Table
> > >published by the PEI Foundation.
> > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >+ @param DescriptorIndex The region of MMRAM to Lock.
> > >+
> > >+ @retval EFI_SUCCESS The operation was successful.
> > >+ @retval EFI_UNSUPPORTED The system does not support opening
> > and
> > >closing of MMRAM.
> > >+
> > >+**/
> > >+typedef
> > >+EFI_STATUS
> > >+(EFIAPI *EFI_PEI_MM_LOCK)(
> > >+ IN EFI_PEI_SERVICES **PeiServices,
> > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > >+ IN UINTN DescriptorIndex
> > >+ );
> > >+
> > >+/**
> > >+ Queries the memory controller for the possible regions that will support
> > >MMRAM.
> > >+
> > >+ This function describes the MMRAM regions.
> > >+ This data structure forms the contract between the MM_ACCESS and
> > >MM_IPL drivers. There is an
> > >+ ambiguity when any MMRAM region is remapped. For example, on
> some
> > >chipsets, some MMRAM
> > >+ regions can be initialized at one physical address but is later accessed at
> > >another processor address.
> > >+ There is currently no way for the MM IPL driver to know that it must use
> > >two different addresses
> > >+ depending on what it is trying to do. As a result, initial configuration and
> > >loading can use the
> > >+ physical address PhysicalStart while MMRAM is open. However, once
> the
> > >region has been
> > >+ closed and needs to be accessed by agents in MM, the CpuStart address
> > >must be used.
> > >+ This PPI publishes the available memory that the chipset can shroud for
> > the
> > >use of installing code.
> > >+ These regions serve the dual purpose of describing which regions have
> > >been open, closed, or locked.
> > >+ In addition, these regions may include overlapping memory ranges,
> > >depending on the chipset
> > >+ implementation. The latter might include a chipset that supports T-SEG,
> > >where memory near the top
> > >+ of the physical DRAM can be allocated for MMRAM too.
> > >+ The key thing to note is that the regions that are described by the PPI
> are
> > a
> > >subset of the capabilities
> > >+ of the hardware.
> > >+
> > >+ @param PeiServices An indirect pointer to the PEI Services Table
> > >published by the PEI Foundation.
> > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >+ @param MmramMapSize A pointer to the size, in bytes, of the
> > >MmramMemoryMap buffer. On input, this value is
> > >+ the size of the buffer that is allocated by the caller. On
> > >output, it is the size of the
> > >+ buffer that was returned by the firmware if the buffer
> > was
> > >large enough, or, if the
> > >+ buffer was too small, the size of the buffer that is
> > needed to
> > >contain the map.
> > >+ @param MmramMap A pointer to the buffer in which firmware
> > >places the current memory map. The map is
> > >+ an array of EFI_MMRAM_DESCRIPTORs
> > >+
> > >+ @retval EFI_SUCCESS The chipset supported the given resource.
> > >+ @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter was too
> > >small. The current
> > >+ buffer size needed to hold the memory map is
> returned
> > in
> > >+ MmramMapSize.
> > >+
> > >+**/
> > >+typedef
> > >+EFI_STATUS
> > >+(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> > >+ IN EFI_PEI_SERVICES **PeiServices,
> > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > >+ IN OUT UINTN *MmramMapSize,
> > >+ IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> > >+ );
> > >+
> > >+///
> > >+/// EFI MM Access PPI is used to control the visibility of the MMRAM on
> > the
> > >platform.
> > >+/// It abstracts the location and characteristics of MMRAM. The platform
> > >should report
> > >+/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is that the
> > >north bridge or
> > >+/// memory controller would publish this PPI.
> > >+///
> > >+struct _EFI_PEI_MM_ACCESS_PPI {
> > >+ EFI_PEI_MM_OPEN Open;
> > >+ EFI_PEI_MM_CLOSE Close;
> > >+ EFI_PEI_MM_LOCK Lock;
> > >+ EFI_PEI_MM_CAPABILITIES GetCapabilities;
> > >+ BOOLEAN LockState;
> > >+ BOOLEAN OpenState;
> > >+};
> > >+
> > >+extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> > >+
> > >+#endif
> > >diff --git a/MdePkg/Include/Ppi/MmControl.h
> > >b/MdePkg/Include/Ppi/MmControl.h
> > >new file mode 100644
> > >index 0000000000..983ed95cd5
> > >--- /dev/null
> > >+++ b/MdePkg/Include/Ppi/MmControl.h
> > >@@ -0,0 +1,90 @@
> > >+/** @file
> > >+ EFI MM Control PPI definition.
> > >+
> > >+ This PPI is used initiate synchronous MMI activations. This PPI could be
> > >published by a processor
> > >+ driver to abstract the MMI IPI or a driver which abstracts the ASIC that
> is
> > >supporting the APM port.
> > >+ Because of the possibility of performing MMI IPI transactions, the ability
> > to
> > >generate this event
> > >+ from a platform chipset agent is an optional capability for both IA-32
> and
> > >x64-based systems.
> > >+
> > >+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
> > >+ SPDX-License-Identifier: BSD-2-Clause-Patent
> > >+
> > >+ @par Revision Reference:
> > >+ This PPI is introduced in PI Version 1.5.
> > >+
> > >+**/
> > >+
> > >+
> > >+#ifndef _MM_CONTROL_PPI_H_
> > >+#define _MM_CONTROL_PPI_H_
> > >+
> > >+#define EFI_PEI_MM_CONTROL_PPI_GUID \
> > >+ { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce, 0x74,
> > 0xc5 }
> > >+
> > >+typedef struct _EFI_PEI_MM_CONTROL_PPI EFI_PEI_MM_CONTROL_PPI;
> > >+
> > >+/**
> > >+ Invokes PPI activation from the PI PEI environment.
> > >+
> > >+ @param PeiServices An indirect pointer to the PEI Services Table
> > >published by the PEI Foundation.
> > >+ @param This The PEI_MM_CONTROL_PPI instance.
> > >+ @param ArgumentBuffer The value passed to the MMI handler.
> This
> > >value corresponds to the
> > >+ SwMmiInputValue in the RegisterContext parameter
> for
> > the
> > >Register()
> > >+ function in the EFI_MM_SW_DISPATCH_PROTOCOL
> and
> > in
> > >the Context parameter
> > >+ in the call to the DispatchFunction
> > >+ @param ArgumentBufferSize The size of the data passed in
> > >ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> > >+ @param Periodic An optional mechanism to periodically repeat
> > >activation.
> > >+ @param ActivationInterval An optional parameter to repeat at this
> > period
> > >one
> > >+ time or, if the Periodic Boolean is set, periodically.
> > >+
> > >+ @retval EFI_SUCCESS The MMI has been engendered.
> > >+ @retval EFI_DEVICE_ERROR The timing is unsupported.
> > >+ @retval EFI_INVALID_PARAMETER The activation period is unsupported.
> > >+ @retval EFI_NOT_STARTED The MM base service has not been
> > initialized.
> > >+
> > >+**/
> > >+typedef
> > >+EFI_STATUS
> > >+(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> > >+ IN EFI_PEI_SERVICES **PeiServices,
> > >+ IN EFI_PEI_MM_CONTROL_PPI * This,
> > >+ IN OUT INT8 *ArgumentBuffer OPTIONAL,
> > >+ IN OUT UINTN *ArgumentBufferSize OPTIONAL,
> > >+ IN BOOLEAN Periodic OPTIONAL,
> > >+ IN UINTN ActivationInterval OPTIONAL
> > >+ );
> > >+
> > >+/**
> > >+ Clears any system state that was created in response to the Trigger() call.
> > >+
> > >+ @param PeiServices General purpose services available to every
> > PEIM.
> > >+ @param This The PEI_MM_CONTROL_PPI instance.
> > >+ @param Periodic Optional parameter to repeat at this period
> one
> > >+ time or, if the Periodic Boolean is set, periodically.
> > >+
> > >+ @retval EFI_SUCCESS The MMI has been engendered.
> > >+ @retval EFI_DEVICE_ERROR The source could not be cleared.
> > >+ @retval EFI_INVALID_PARAMETER The service did not support the
> > Periodic
> > >input argument.
> > >+
> > >+**/
> > >+typedef
> > >+EFI_STATUS
> > >+(EFIAPI *PEI_MM_DEACTIVATE) (
> > >+ IN EFI_PEI_SERVICES **PeiServices,
> > >+ IN EFI_PEI_MM_CONTROL_PPI * This,
> > >+ IN BOOLEAN Periodic OPTIONAL
> > >+ );
> > >+
> > >+///
> > >+/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It provides
> an
> > >abstraction of the
> > >+/// platform hardware that generates an MMI. There are often I/O ports
> > >that, when accessed, will
> > >+/// generate the MMI. Also, the hardware optionally supports the
> periodic
> > >generation of these signals.
> > >+///
> > >+struct _PEI_MM_CONTROL_PPI {
> > >+ PEI_MM_ACTIVATE Trigger;
> > >+ PEI_MM_DEACTIVATE Clear;
> > >+};
> > >+
> > >+extern EFI_GUID gEfiPeiMmControlPpiGuid;
> > >+
> > >+#endif
> > >diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > >index b382efd578..34e0f39395 100644
> > >--- a/MdePkg/MdePkg.dec
> > >+++ b/MdePkg/MdePkg.dec
> > >@@ -925,6 +925,12 @@
> > > ## Include/Ppi/SecHobData.h
> > > gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4, 0xee,
> 0xf5,
> > >0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> > >
> > >+ ## Include/Ppi/MmAccess.h
> > >+ gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be, { 0x88,
> > 0x17,
> > >0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> > >+
> > >+ ## Include/Ppi/MmControl.h
> > >+ gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43, { 0x8d,
> > 0xef,
> > >0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> > >+
> > > #
> > > # PPIs defined in PI 1.7.
> > > #
> > >--
> > >2.16.2.windows.1
> > >
> > >
> > >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-01 8:52 ` Marc W Chen
@ 2019-08-01 10:04 ` Ni, Ray
2019-08-01 10:15 ` Marc W Chen
0 siblings, 1 reply; 18+ messages in thread
From: Ni, Ray @ 2019-08-01 10:04 UTC (permalink / raw)
To: Chen, Marc W, Gao, Liming, devel@edk2.groups.io; +Cc: Kinney, Michael D
Marc,
Is the purpose to avoid platform code update with the wrapper header file in MdeModulePkg?
Certain platforms they may require to not depend on MdeModulePkg but just depend on MdePkg.
Having SmmAccess.h in MdeModulePkg doesn't help.
It also bring confusing.
Thanks,
Ray
> -----Original Message-----
> From: Chen, Marc W
> Sent: Thursday, August 1, 2019 4:53 PM
> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> <ray.ni@intel.com>
> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> definition.
>
> Hi Liming
>
> Another thought, do you think it is ok to keep SmmAccess.h in
> MdeModulePkg? We can use #define and typedef to convert MmAccess to
> SmmAccess, just like current SmmAccess Protocol in MdePkg.
>
> Thanks,
> Marc
>
> > -----Original Message-----
> > From: Chen, Marc W
> > Sent: Thursday, August 1, 2019 4:48 PM
> > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > <ray.ni@intel.com>
> > Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> MmControl
> > definition.
> >
> > Hi Liming
> >
> > Since there are multiple packages are still using SmmAccess.h, we need
> > to change all packages to use MmAccess.h instead of SmmAccess.h first,
> > then clean up SmmAccess.h from MdeModulePkg will be the last step.
> > Below are the packages that has "include <Ppi/SmmAccess.h>" for your
> > reference.
> > * Edk2 repo:
> > o MdeModulePkg
> > o OvmfPkg
> > o UefiCpuPkg
> > * Edk2Platform repo:
> > o MinPlatformPkg
> > o QuarkSocPkg
> >
> > Thanks,
> > Marc
> >
> > > -----Original Message-----
> > > From: Gao, Liming
> > > Sent: Thursday, August 1, 2019 4:42 PM
> > > To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>
> > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > > <ray.ni@intel.com>
> > > Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> MmControl
> > > definition.
> > >
> > > Marc:
> > > The change is good. Reviewed-by: Liming Gao <liming.gao@intel.com>
> > >
> > > Besides, I see BZ also mention to remove the one in MdeModulePkg.
> > > Have you the following patches for the change in MdeModulePkg?
> > >
> > > Thanks
> > > Liming
> > > >-----Original Message-----
> > > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf
> > > >Of Marc W Chen
> > > >Sent: Monday, July 29, 2019 12:26 PM
> > > >To: devel@edk2.groups.io
> > > >Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> > > ><liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> > > >Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> > > >definition.
> > > >
> > > >EFI MmAccess and MmControl PPIs are defined in the PI 1.5
> specification.
> > > >
> > > >Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > > >Cc: Liming Gao <liming.gao@intel.com>
> > > >Cc: Ray Ni <ray.ni@intel.com>
> > > >Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> > > >Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> > > >---
> > > > MdePkg/Include/Ppi/MmAccess.h | 155
> > > >+++++++++++++++++++++++++++++++++++++++++
> > > > MdePkg/Include/Ppi/MmControl.h | 90
> ++++++++++++++++++++++++
> > > > MdePkg/MdePkg.dec | 6 ++
> > > > 3 files changed, 251 insertions(+) create mode 100644
> > > > MdePkg/Include/Ppi/MmAccess.h create mode 100644
> > > > MdePkg/Include/Ppi/MmControl.h
> > > >
> > > >diff --git a/MdePkg/Include/Ppi/MmAccess.h
> > > >b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644 index
> > > >0000000000..636e7288a0
> > > >--- /dev/null
> > > >+++ b/MdePkg/Include/Ppi/MmAccess.h
> > > >@@ -0,0 +1,155 @@
> > > >+/** @file
> > > >+ EFI MM Access PPI definition.
> > > >+
> > > >+ This PPI is used to control the visibility of the MMRAM on the
> platform.
> > > >+ The EFI_PEI_MM_ACCESS_PPI abstracts the location and
> > > >+ characteristics
> > of
> > > >MMRAM. The
> > > >+ principal functionality found in the memory controller includes
> > > >+ the
> > > following:
> > > >+ - Exposing the MMRAM to all non-MM agents, or the "open" state
> > > >+ - Shrouding the MMRAM to all but the MM agents, or the "closed"
> > > >+ state
> > > >+ - Preserving the system integrity, or "locking" the MMRAM, such
> > > >+ that
> > the
> > > >settings cannot be
> > > >+ perturbed by either boot service or runtime agents
> > > >+
> > > >+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
> > > >+ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > >+
> > > >+ @par Revision Reference:
> > > >+ This PPI is introduced in PI Version 1.5.
> > > >+
> > > >+**/
> > > >+
> > > >+#ifndef _MM_ACCESS_PPI_H_
> > > >+#define _MM_ACCESS_PPI_H_
> > > >+
> > > >+#define EFI_PEI_MM_ACCESS_PPI_GUID \
> > > >+ { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
> > > >+0xc3, 0x2e,
> > > >0xd6 }}
> > > >+
> > > >+typedef struct _EFI_PEI_MM_ACCESS_PPI EFI_PEI_MM_ACCESS_PPI;
> > > >+
> > > >+/**
> > > >+ Opens the MMRAM area to be accessible by a PEIM.
> > > >+
> > > >+ This function "opens" MMRAM so that it is visible while not
> > > >+ inside of
> > MM.
> > > >The function should
> > > >+ return EFI_UNSUPPORTED if the hardware does not support hiding
> > > >+ of
> > > >MMRAM. The function
> > > >+ should return EFI_DEVICE_ERROR if the MMRAM configuration is
> locked.
> > > >+
> > > >+ @param PeiServices An indirect pointer to the PEI Services
> Table
> > > >published by the PEI Foundation.
> > > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > > >+ @param DescriptorIndex The region of MMRAM to Open.
> > > >+
> > > >+ @retval EFI_SUCCESS The operation was successful.
> > > >+ @retval EFI_UNSUPPORTED The system does not support opening
> > > and
> > > >closing of MMRAM.
> > > >+ @retval EFI_DEVICE_ERROR MMRAM cannot be opened, perhaps
> > > >because it is locked.
> > > >+
> > > >+**/
> > > >+typedef
> > > >+EFI_STATUS
> > > >+(EFIAPI *EFI_PEI_MM_OPEN)(
> > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > > >+ IN UINTN DescriptorIndex
> > > >+ );
> > > >+
> > > >+/**
> > > >+ Inhibits access to the MMRAM.
> > > >+
> > > >+ This function "closes" MMRAM so that it is not visible while
> > > >+ outside of
> > > MM.
> > > >The function should
> > > >+ return EFI_UNSUPPORTED if the hardware does not support hiding
> > > >+ of
> > > >MMRAM.
> > > >+
> > > >+ @param PeiServices An indirect pointer to the PEI Services
> Table
> > > >published by the PEI Foundation.
> > > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > > >+ @param DescriptorIndex The region of MMRAM to Close.
> > > >+
> > > >+ @retval EFI_SUCCESS The operation was successful.
> > > >+ @retval EFI_UNSUPPORTED The system does not support opening
> > > and
> > > >closing of MMRAM.
> > > >+ @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> > > >+
> > > >+**/
> > > >+typedef
> > > >+EFI_STATUS
> > > >+(EFIAPI *EFI_PEI_MM_CLOSE)(
> > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > > >+ IN UINTN DescriptorIndex
> > > >+ );
> > > >+
> > > >+/**
> > > >+ This function prohibits access to the MMRAM region. This
> > > >+function is
> > > usually
> > > >implemented such
> > > >+ that it is a write-once operation.
> > > >+
> > > >+ @param PeiServices An indirect pointer to the PEI Services
> Table
> > > >published by the PEI Foundation.
> > > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > > >+ @param DescriptorIndex The region of MMRAM to Lock.
> > > >+
> > > >+ @retval EFI_SUCCESS The operation was successful.
> > > >+ @retval EFI_UNSUPPORTED The system does not support opening
> > > and
> > > >closing of MMRAM.
> > > >+
> > > >+**/
> > > >+typedef
> > > >+EFI_STATUS
> > > >+(EFIAPI *EFI_PEI_MM_LOCK)(
> > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > > >+ IN UINTN DescriptorIndex
> > > >+ );
> > > >+
> > > >+/**
> > > >+ Queries the memory controller for the possible regions that will
> > > >+support
> > > >MMRAM.
> > > >+
> > > >+ This function describes the MMRAM regions.
> > > >+ This data structure forms the contract between the MM_ACCESS and
> > > >MM_IPL drivers. There is an
> > > >+ ambiguity when any MMRAM region is remapped. For example, on
> > some
> > > >chipsets, some MMRAM
> > > >+ regions can be initialized at one physical address but is later
> > > >+ accessed at
> > > >another processor address.
> > > >+ There is currently no way for the MM IPL driver to know that it
> > > >+ must use
> > > >two different addresses
> > > >+ depending on what it is trying to do. As a result, initial
> > > >+ configuration and
> > > >loading can use the
> > > >+ physical address PhysicalStart while MMRAM is open. However,
> > > >+ once
> > the
> > > >region has been
> > > >+ closed and needs to be accessed by agents in MM, the CpuStart
> > > >+ address
> > > >must be used.
> > > >+ This PPI publishes the available memory that the chipset can
> > > >+ shroud for
> > > the
> > > >use of installing code.
> > > >+ These regions serve the dual purpose of describing which regions
> > > >+ have
> > > >been open, closed, or locked.
> > > >+ In addition, these regions may include overlapping memory
> > > >+ ranges,
> > > >depending on the chipset
> > > >+ implementation. The latter might include a chipset that supports
> > > >+ T-SEG,
> > > >where memory near the top
> > > >+ of the physical DRAM can be allocated for MMRAM too.
> > > >+ The key thing to note is that the regions that are described by
> > > >+ the PPI
> > are
> > > a
> > > >subset of the capabilities
> > > >+ of the hardware.
> > > >+
> > > >+ @param PeiServices An indirect pointer to the PEI Services
> Table
> > > >published by the PEI Foundation.
> > > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > > >+ @param MmramMapSize A pointer to the size, in bytes, of the
> > > >MmramMemoryMap buffer. On input, this value is
> > > >+ the size of the buffer that is
> > > >+ allocated by the caller. On
> > > >output, it is the size of the
> > > >+ buffer that was returned by the
> > > >+ firmware if the buffer
> > > was
> > > >large enough, or, if the
> > > >+ buffer was too small, the size of
> > > >+ the buffer that is
> > > needed to
> > > >contain the map.
> > > >+ @param MmramMap A pointer to the buffer in which
> firmware
> > > >places the current memory map. The map is
> > > >+ an array of EFI_MMRAM_DESCRIPTORs
> > > >+
> > > >+ @retval EFI_SUCCESS The chipset supported the given resource.
> > > >+ @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter was
> too
> > > >small. The current
> > > >+ buffer size needed to hold the
> > > >+ memory map is
> > returned
> > > in
> > > >+ MmramMapSize.
> > > >+
> > > >+**/
> > > >+typedef
> > > >+EFI_STATUS
> > > >+(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > > >+ IN OUT UINTN *MmramMapSize,
> > > >+ IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> > > >+ );
> > > >+
> > > >+///
> > > >+/// EFI MM Access PPI is used to control the visibility of the
> > > >+MMRAM on
> > > the
> > > >platform.
> > > >+/// It abstracts the location and characteristics of MMRAM. The
> > > >+platform
> > > >should report
> > > >+/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is that
> > > >+the
> > > >north bridge or
> > > >+/// memory controller would publish this PPI.
> > > >+///
> > > >+struct _EFI_PEI_MM_ACCESS_PPI {
> > > >+ EFI_PEI_MM_OPEN Open;
> > > >+ EFI_PEI_MM_CLOSE Close;
> > > >+ EFI_PEI_MM_LOCK Lock;
> > > >+ EFI_PEI_MM_CAPABILITIES GetCapabilities;
> > > >+ BOOLEAN LockState;
> > > >+ BOOLEAN OpenState;
> > > >+};
> > > >+
> > > >+extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> > > >+
> > > >+#endif
> > > >diff --git a/MdePkg/Include/Ppi/MmControl.h
> > > >b/MdePkg/Include/Ppi/MmControl.h new file mode 100644 index
> > > >0000000000..983ed95cd5
> > > >--- /dev/null
> > > >+++ b/MdePkg/Include/Ppi/MmControl.h
> > > >@@ -0,0 +1,90 @@
> > > >+/** @file
> > > >+ EFI MM Control PPI definition.
> > > >+
> > > >+ This PPI is used initiate synchronous MMI activations. This PPI
> > > >+ could be
> > > >published by a processor
> > > >+ driver to abstract the MMI IPI or a driver which abstracts the
> > > >+ ASIC that
> > is
> > > >supporting the APM port.
> > > >+ Because of the possibility of performing MMI IPI transactions,
> > > >+ the ability
> > > to
> > > >generate this event
> > > >+ from a platform chipset agent is an optional capability for both
> > > >+ IA-32
> > and
> > > >x64-based systems.
> > > >+
> > > >+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
> > > >+ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > >+
> > > >+ @par Revision Reference:
> > > >+ This PPI is introduced in PI Version 1.5.
> > > >+
> > > >+**/
> > > >+
> > > >+
> > > >+#ifndef _MM_CONTROL_PPI_H_
> > > >+#define _MM_CONTROL_PPI_H_
> > > >+
> > > >+#define EFI_PEI_MM_CONTROL_PPI_GUID \
> > > >+ { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce,
> > > >+0x74,
> > > 0xc5 }
> > > >+
> > > >+typedef struct _EFI_PEI_MM_CONTROL_PPI
> EFI_PEI_MM_CONTROL_PPI;
> > > >+
> > > >+/**
> > > >+ Invokes PPI activation from the PI PEI environment.
> > > >+
> > > >+ @param PeiServices An indirect pointer to the PEI Services Table
> > > >published by the PEI Foundation.
> > > >+ @param This The PEI_MM_CONTROL_PPI instance.
> > > >+ @param ArgumentBuffer The value passed to the MMI handler.
> > This
> > > >value corresponds to the
> > > >+ SwMmiInputValue in the
> > > >+ RegisterContext parameter
> > for
> > > the
> > > >Register()
> > > >+ function in the
> > > >+ EFI_MM_SW_DISPATCH_PROTOCOL
> > and
> > > in
> > > >the Context parameter
> > > >+ in the call to the DispatchFunction
> > > >+ @param ArgumentBufferSize The size of the data passed in
> > > >ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> > > >+ @param Periodic An optional mechanism to periodically repeat
> > > >activation.
> > > >+ @param ActivationInterval An optional parameter to repeat at this
> > > period
> > > >one
> > > >+ time or, if the Periodic Boolean is set, periodically.
> > > >+
> > > >+ @retval EFI_SUCCESS The MMI has been engendered.
> > > >+ @retval EFI_DEVICE_ERROR The timing is unsupported.
> > > >+ @retval EFI_INVALID_PARAMETER The activation period is
> unsupported.
> > > >+ @retval EFI_NOT_STARTED The MM base service has not been
> > > initialized.
> > > >+
> > > >+**/
> > > >+typedef
> > > >+EFI_STATUS
> > > >+(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > >+ IN EFI_PEI_MM_CONTROL_PPI * This,
> > > >+ IN OUT INT8 *ArgumentBuffer OPTIONAL,
> > > >+ IN OUT UINTN *ArgumentBufferSize OPTIONAL,
> > > >+ IN BOOLEAN Periodic OPTIONAL,
> > > >+ IN UINTN ActivationInterval OPTIONAL
> > > >+ );
> > > >+
> > > >+/**
> > > >+ Clears any system state that was created in response to the Trigger()
> call.
> > > >+
> > > >+ @param PeiServices General purpose services available to every
> > > PEIM.
> > > >+ @param This The PEI_MM_CONTROL_PPI instance.
> > > >+ @param Periodic Optional parameter to repeat at this period
> > one
> > > >+ time or, if the Periodic Boolean is set, periodically.
> > > >+
> > > >+ @retval EFI_SUCCESS The MMI has been engendered.
> > > >+ @retval EFI_DEVICE_ERROR The source could not be cleared.
> > > >+ @retval EFI_INVALID_PARAMETER The service did not support the
> > > Periodic
> > > >input argument.
> > > >+
> > > >+**/
> > > >+typedef
> > > >+EFI_STATUS
> > > >+(EFIAPI *PEI_MM_DEACTIVATE) (
> > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > >+ IN EFI_PEI_MM_CONTROL_PPI * This,
> > > >+ IN BOOLEAN Periodic OPTIONAL
> > > >+ );
> > > >+
> > > >+///
> > > >+/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It
> provides
> > an
> > > >abstraction of the
> > > >+/// platform hardware that generates an MMI. There are often I/O
> > > >+ports
> > > >that, when accessed, will
> > > >+/// generate the MMI. Also, the hardware optionally supports the
> > periodic
> > > >generation of these signals.
> > > >+///
> > > >+struct _PEI_MM_CONTROL_PPI {
> > > >+ PEI_MM_ACTIVATE Trigger;
> > > >+ PEI_MM_DEACTIVATE Clear;
> > > >+};
> > > >+
> > > >+extern EFI_GUID gEfiPeiMmControlPpiGuid;
> > > >+
> > > >+#endif
> > > >diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
> > > >b382efd578..34e0f39395 100644
> > > >--- a/MdePkg/MdePkg.dec
> > > >+++ b/MdePkg/MdePkg.dec
> > > >@@ -925,6 +925,12 @@
> > > > ## Include/Ppi/SecHobData.h
> > > > gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4,
> > > >0xee,
> > 0xf5,
> > > >0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> > > >
> > > >+ ## Include/Ppi/MmAccess.h
> > > >+ gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be, { 0x88,
> > > 0x17,
> > > >0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> > > >+
> > > >+ ## Include/Ppi/MmControl.h
> > > >+ gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43, { 0x8d,
> > > 0xef,
> > > >0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> > > >+
> > > > #
> > > > # PPIs defined in PI 1.7.
> > > > #
> > > >--
> > > >2.16.2.windows.1
> > > >
> > > >
> > > >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-01 10:04 ` Ni, Ray
@ 2019-08-01 10:15 ` Marc W Chen
2019-08-02 2:14 ` Laszlo Ersek
0 siblings, 1 reply; 18+ messages in thread
From: Marc W Chen @ 2019-08-01 10:15 UTC (permalink / raw)
To: Ni, Ray, Gao, Liming, devel@edk2.groups.io; +Cc: Kinney, Michael D
Yes, my purpose is to avoid platform code update if the package is allowed to use MdeModulePkg like OvmfPkg.
For those packages that cannot depend on MdeModulePkg must change to use new definition.
Thanks,
Marc
> -----Original Message-----
> From: Ni, Ray
> Sent: Thursday, August 1, 2019 6:04 PM
> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
> <liming.gao@intel.com>; devel@edk2.groups.io
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> definition.
>
> Marc,
> Is the purpose to avoid platform code update with the wrapper header file in
> MdeModulePkg?
> Certain platforms they may require to not depend on MdeModulePkg but
> just depend on MdePkg.
> Having SmmAccess.h in MdeModulePkg doesn't help.
>
> It also bring confusing.
>
> Thanks,
> Ray
>
> > -----Original Message-----
> > From: Chen, Marc W
> > Sent: Thursday, August 1, 2019 4:53 PM
> > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > <ray.ni@intel.com>
> > Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> > definition.
> >
> > Hi Liming
> >
> > Another thought, do you think it is ok to keep SmmAccess.h in
> > MdeModulePkg? We can use #define and typedef to convert MmAccess to
> > SmmAccess, just like current SmmAccess Protocol in MdePkg.
> >
> > Thanks,
> > Marc
> >
> > > -----Original Message-----
> > > From: Chen, Marc W
> > > Sent: Thursday, August 1, 2019 4:48 PM
> > > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > > <ray.ni@intel.com>
> > > Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > MmControl
> > > definition.
> > >
> > > Hi Liming
> > >
> > > Since there are multiple packages are still using SmmAccess.h, we need
> > > to change all packages to use MmAccess.h instead of SmmAccess.h first,
> > > then clean up SmmAccess.h from MdeModulePkg will be the last step.
> > > Below are the packages that has "include <Ppi/SmmAccess.h>" for your
> > > reference.
> > > * Edk2 repo:
> > > o MdeModulePkg
> > > o OvmfPkg
> > > o UefiCpuPkg
> > > * Edk2Platform repo:
> > > o MinPlatformPkg
> > > o QuarkSocPkg
> > >
> > > Thanks,
> > > Marc
> > >
> > > > -----Original Message-----
> > > > From: Gao, Liming
> > > > Sent: Thursday, August 1, 2019 4:42 PM
> > > > To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>
> > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > > > <ray.ni@intel.com>
> > > > Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > MmControl
> > > > definition.
> > > >
> > > > Marc:
> > > > The change is good. Reviewed-by: Liming Gao <liming.gao@intel.com>
> > > >
> > > > Besides, I see BZ also mention to remove the one in MdeModulePkg.
> > > > Have you the following patches for the change in MdeModulePkg?
> > > >
> > > > Thanks
> > > > Liming
> > > > >-----Original Message-----
> > > > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> Behalf
> > > > >Of Marc W Chen
> > > > >Sent: Monday, July 29, 2019 12:26 PM
> > > > >To: devel@edk2.groups.io
> > > > >Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> > > > ><liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> > > > >Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> MmControl
> > > > >definition.
> > > > >
> > > > >EFI MmAccess and MmControl PPIs are defined in the PI 1.5
> > specification.
> > > > >
> > > > >Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > > > >Cc: Liming Gao <liming.gao@intel.com>
> > > > >Cc: Ray Ni <ray.ni@intel.com>
> > > > >Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> > > > >Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> > > > >---
> > > > > MdePkg/Include/Ppi/MmAccess.h | 155
> > > > >+++++++++++++++++++++++++++++++++++++++++
> > > > > MdePkg/Include/Ppi/MmControl.h | 90
> > ++++++++++++++++++++++++
> > > > > MdePkg/MdePkg.dec | 6 ++
> > > > > 3 files changed, 251 insertions(+) create mode 100644
> > > > > MdePkg/Include/Ppi/MmAccess.h create mode 100644
> > > > > MdePkg/Include/Ppi/MmControl.h
> > > > >
> > > > >diff --git a/MdePkg/Include/Ppi/MmAccess.h
> > > > >b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644 index
> > > > >0000000000..636e7288a0
> > > > >--- /dev/null
> > > > >+++ b/MdePkg/Include/Ppi/MmAccess.h
> > > > >@@ -0,0 +1,155 @@
> > > > >+/** @file
> > > > >+ EFI MM Access PPI definition.
> > > > >+
> > > > >+ This PPI is used to control the visibility of the MMRAM on the
> > platform.
> > > > >+ The EFI_PEI_MM_ACCESS_PPI abstracts the location and
> > > > >+ characteristics
> > > of
> > > > >MMRAM. The
> > > > >+ principal functionality found in the memory controller includes
> > > > >+ the
> > > > following:
> > > > >+ - Exposing the MMRAM to all non-MM agents, or the "open" state
> > > > >+ - Shrouding the MMRAM to all but the MM agents, or the "closed"
> > > > >+ state
> > > > >+ - Preserving the system integrity, or "locking" the MMRAM, such
> > > > >+ that
> > > the
> > > > >settings cannot be
> > > > >+ perturbed by either boot service or runtime agents
> > > > >+
> > > > >+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
> > > > >+ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > >+
> > > > >+ @par Revision Reference:
> > > > >+ This PPI is introduced in PI Version 1.5.
> > > > >+
> > > > >+**/
> > > > >+
> > > > >+#ifndef _MM_ACCESS_PPI_H_
> > > > >+#define _MM_ACCESS_PPI_H_
> > > > >+
> > > > >+#define EFI_PEI_MM_ACCESS_PPI_GUID \
> > > > >+ { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
> > > > >+0xc3, 0x2e,
> > > > >0xd6 }}
> > > > >+
> > > > >+typedef struct _EFI_PEI_MM_ACCESS_PPI EFI_PEI_MM_ACCESS_PPI;
> > > > >+
> > > > >+/**
> > > > >+ Opens the MMRAM area to be accessible by a PEIM.
> > > > >+
> > > > >+ This function "opens" MMRAM so that it is visible while not
> > > > >+ inside of
> > > MM.
> > > > >The function should
> > > > >+ return EFI_UNSUPPORTED if the hardware does not support hiding
> > > > >+ of
> > > > >MMRAM. The function
> > > > >+ should return EFI_DEVICE_ERROR if the MMRAM configuration is
> > locked.
> > > > >+
> > > > >+ @param PeiServices An indirect pointer to the PEI Services
> > Table
> > > > >published by the PEI Foundation.
> > > > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > > > >+ @param DescriptorIndex The region of MMRAM to Open.
> > > > >+
> > > > >+ @retval EFI_SUCCESS The operation was successful.
> > > > >+ @retval EFI_UNSUPPORTED The system does not support
> opening
> > > > and
> > > > >closing of MMRAM.
> > > > >+ @retval EFI_DEVICE_ERROR MMRAM cannot be opened,
> perhaps
> > > > >because it is locked.
> > > > >+
> > > > >+**/
> > > > >+typedef
> > > > >+EFI_STATUS
> > > > >+(EFIAPI *EFI_PEI_MM_OPEN)(
> > > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > > > >+ IN UINTN DescriptorIndex
> > > > >+ );
> > > > >+
> > > > >+/**
> > > > >+ Inhibits access to the MMRAM.
> > > > >+
> > > > >+ This function "closes" MMRAM so that it is not visible while
> > > > >+ outside of
> > > > MM.
> > > > >The function should
> > > > >+ return EFI_UNSUPPORTED if the hardware does not support hiding
> > > > >+ of
> > > > >MMRAM.
> > > > >+
> > > > >+ @param PeiServices An indirect pointer to the PEI Services
> > Table
> > > > >published by the PEI Foundation.
> > > > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > > > >+ @param DescriptorIndex The region of MMRAM to Close.
> > > > >+
> > > > >+ @retval EFI_SUCCESS The operation was successful.
> > > > >+ @retval EFI_UNSUPPORTED The system does not support
> opening
> > > > and
> > > > >closing of MMRAM.
> > > > >+ @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> > > > >+
> > > > >+**/
> > > > >+typedef
> > > > >+EFI_STATUS
> > > > >+(EFIAPI *EFI_PEI_MM_CLOSE)(
> > > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > > > >+ IN UINTN DescriptorIndex
> > > > >+ );
> > > > >+
> > > > >+/**
> > > > >+ This function prohibits access to the MMRAM region. This
> > > > >+function is
> > > > usually
> > > > >implemented such
> > > > >+ that it is a write-once operation.
> > > > >+
> > > > >+ @param PeiServices An indirect pointer to the PEI Services
> > Table
> > > > >published by the PEI Foundation.
> > > > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > > > >+ @param DescriptorIndex The region of MMRAM to Lock.
> > > > >+
> > > > >+ @retval EFI_SUCCESS The operation was successful.
> > > > >+ @retval EFI_UNSUPPORTED The system does not support
> opening
> > > > and
> > > > >closing of MMRAM.
> > > > >+
> > > > >+**/
> > > > >+typedef
> > > > >+EFI_STATUS
> > > > >+(EFIAPI *EFI_PEI_MM_LOCK)(
> > > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > > > >+ IN UINTN DescriptorIndex
> > > > >+ );
> > > > >+
> > > > >+/**
> > > > >+ Queries the memory controller for the possible regions that will
> > > > >+support
> > > > >MMRAM.
> > > > >+
> > > > >+ This function describes the MMRAM regions.
> > > > >+ This data structure forms the contract between the MM_ACCESS
> and
> > > > >MM_IPL drivers. There is an
> > > > >+ ambiguity when any MMRAM region is remapped. For example, on
> > > some
> > > > >chipsets, some MMRAM
> > > > >+ regions can be initialized at one physical address but is later
> > > > >+ accessed at
> > > > >another processor address.
> > > > >+ There is currently no way for the MM IPL driver to know that it
> > > > >+ must use
> > > > >two different addresses
> > > > >+ depending on what it is trying to do. As a result, initial
> > > > >+ configuration and
> > > > >loading can use the
> > > > >+ physical address PhysicalStart while MMRAM is open. However,
> > > > >+ once
> > > the
> > > > >region has been
> > > > >+ closed and needs to be accessed by agents in MM, the CpuStart
> > > > >+ address
> > > > >must be used.
> > > > >+ This PPI publishes the available memory that the chipset can
> > > > >+ shroud for
> > > > the
> > > > >use of installing code.
> > > > >+ These regions serve the dual purpose of describing which regions
> > > > >+ have
> > > > >been open, closed, or locked.
> > > > >+ In addition, these regions may include overlapping memory
> > > > >+ ranges,
> > > > >depending on the chipset
> > > > >+ implementation. The latter might include a chipset that supports
> > > > >+ T-SEG,
> > > > >where memory near the top
> > > > >+ of the physical DRAM can be allocated for MMRAM too.
> > > > >+ The key thing to note is that the regions that are described by
> > > > >+ the PPI
> > > are
> > > > a
> > > > >subset of the capabilities
> > > > >+ of the hardware.
> > > > >+
> > > > >+ @param PeiServices An indirect pointer to the PEI Services
> > Table
> > > > >published by the PEI Foundation.
> > > > >+ @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > > > >+ @param MmramMapSize A pointer to the size, in bytes, of
> the
> > > > >MmramMemoryMap buffer. On input, this value is
> > > > >+ the size of the buffer that is
> > > > >+ allocated by the caller. On
> > > > >output, it is the size of the
> > > > >+ buffer that was returned by the
> > > > >+ firmware if the buffer
> > > > was
> > > > >large enough, or, if the
> > > > >+ buffer was too small, the size of
> > > > >+ the buffer that is
> > > > needed to
> > > > >contain the map.
> > > > >+ @param MmramMap A pointer to the buffer in which
> > firmware
> > > > >places the current memory map. The map is
> > > > >+ an array of EFI_MMRAM_DESCRIPTORs
> > > > >+
> > > > >+ @retval EFI_SUCCESS The chipset supported the given
> resource.
> > > > >+ @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter was
> > too
> > > > >small. The current
> > > > >+ buffer size needed to hold the
> > > > >+ memory map is
> > > returned
> > > > in
> > > > >+ MmramMapSize.
> > > > >+
> > > > >+**/
> > > > >+typedef
> > > > >+EFI_STATUS
> > > > >+(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> > > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > > >+ IN EFI_PEI_MM_ACCESS_PPI *This,
> > > > >+ IN OUT UINTN *MmramMapSize,
> > > > >+ IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> > > > >+ );
> > > > >+
> > > > >+///
> > > > >+/// EFI MM Access PPI is used to control the visibility of the
> > > > >+MMRAM on
> > > > the
> > > > >platform.
> > > > >+/// It abstracts the location and characteristics of MMRAM. The
> > > > >+platform
> > > > >should report
> > > > >+/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is that
> > > > >+the
> > > > >north bridge or
> > > > >+/// memory controller would publish this PPI.
> > > > >+///
> > > > >+struct _EFI_PEI_MM_ACCESS_PPI {
> > > > >+ EFI_PEI_MM_OPEN Open;
> > > > >+ EFI_PEI_MM_CLOSE Close;
> > > > >+ EFI_PEI_MM_LOCK Lock;
> > > > >+ EFI_PEI_MM_CAPABILITIES GetCapabilities;
> > > > >+ BOOLEAN LockState;
> > > > >+ BOOLEAN OpenState;
> > > > >+};
> > > > >+
> > > > >+extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> > > > >+
> > > > >+#endif
> > > > >diff --git a/MdePkg/Include/Ppi/MmControl.h
> > > > >b/MdePkg/Include/Ppi/MmControl.h new file mode 100644 index
> > > > >0000000000..983ed95cd5
> > > > >--- /dev/null
> > > > >+++ b/MdePkg/Include/Ppi/MmControl.h
> > > > >@@ -0,0 +1,90 @@
> > > > >+/** @file
> > > > >+ EFI MM Control PPI definition.
> > > > >+
> > > > >+ This PPI is used initiate synchronous MMI activations. This PPI
> > > > >+ could be
> > > > >published by a processor
> > > > >+ driver to abstract the MMI IPI or a driver which abstracts the
> > > > >+ ASIC that
> > > is
> > > > >supporting the APM port.
> > > > >+ Because of the possibility of performing MMI IPI transactions,
> > > > >+ the ability
> > > > to
> > > > >generate this event
> > > > >+ from a platform chipset agent is an optional capability for both
> > > > >+ IA-32
> > > and
> > > > >x64-based systems.
> > > > >+
> > > > >+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
> > > > >+ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > >+
> > > > >+ @par Revision Reference:
> > > > >+ This PPI is introduced in PI Version 1.5.
> > > > >+
> > > > >+**/
> > > > >+
> > > > >+
> > > > >+#ifndef _MM_CONTROL_PPI_H_
> > > > >+#define _MM_CONTROL_PPI_H_
> > > > >+
> > > > >+#define EFI_PEI_MM_CONTROL_PPI_GUID \
> > > > >+ { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce,
> > > > >+0x74,
> > > > 0xc5 }
> > > > >+
> > > > >+typedef struct _EFI_PEI_MM_CONTROL_PPI
> > EFI_PEI_MM_CONTROL_PPI;
> > > > >+
> > > > >+/**
> > > > >+ Invokes PPI activation from the PI PEI environment.
> > > > >+
> > > > >+ @param PeiServices An indirect pointer to the PEI Services
> Table
> > > > >published by the PEI Foundation.
> > > > >+ @param This The PEI_MM_CONTROL_PPI instance.
> > > > >+ @param ArgumentBuffer The value passed to the MMI handler.
> > > This
> > > > >value corresponds to the
> > > > >+ SwMmiInputValue in the
> > > > >+ RegisterContext parameter
> > > for
> > > > the
> > > > >Register()
> > > > >+ function in the
> > > > >+ EFI_MM_SW_DISPATCH_PROTOCOL
> > > and
> > > > in
> > > > >the Context parameter
> > > > >+ in the call to the DispatchFunction
> > > > >+ @param ArgumentBufferSize The size of the data passed in
> > > > >ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> > > > >+ @param Periodic An optional mechanism to periodically
> repeat
> > > > >activation.
> > > > >+ @param ActivationInterval An optional parameter to repeat at
> this
> > > > period
> > > > >one
> > > > >+ time or, if the Periodic Boolean is set, periodically.
> > > > >+
> > > > >+ @retval EFI_SUCCESS The MMI has been engendered.
> > > > >+ @retval EFI_DEVICE_ERROR The timing is unsupported.
> > > > >+ @retval EFI_INVALID_PARAMETER The activation period is
> > unsupported.
> > > > >+ @retval EFI_NOT_STARTED The MM base service has not been
> > > > initialized.
> > > > >+
> > > > >+**/
> > > > >+typedef
> > > > >+EFI_STATUS
> > > > >+(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> > > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > > >+ IN EFI_PEI_MM_CONTROL_PPI * This,
> > > > >+ IN OUT INT8 *ArgumentBuffer OPTIONAL,
> > > > >+ IN OUT UINTN *ArgumentBufferSize OPTIONAL,
> > > > >+ IN BOOLEAN Periodic OPTIONAL,
> > > > >+ IN UINTN ActivationInterval OPTIONAL
> > > > >+ );
> > > > >+
> > > > >+/**
> > > > >+ Clears any system state that was created in response to the Trigger()
> > call.
> > > > >+
> > > > >+ @param PeiServices General purpose services available to
> every
> > > > PEIM.
> > > > >+ @param This The PEI_MM_CONTROL_PPI instance.
> > > > >+ @param Periodic Optional parameter to repeat at this
> period
> > > one
> > > > >+ time or, if the Periodic Boolean is set, periodically.
> > > > >+
> > > > >+ @retval EFI_SUCCESS The MMI has been engendered.
> > > > >+ @retval EFI_DEVICE_ERROR The source could not be cleared.
> > > > >+ @retval EFI_INVALID_PARAMETER The service did not support the
> > > > Periodic
> > > > >input argument.
> > > > >+
> > > > >+**/
> > > > >+typedef
> > > > >+EFI_STATUS
> > > > >+(EFIAPI *PEI_MM_DEACTIVATE) (
> > > > >+ IN EFI_PEI_SERVICES **PeiServices,
> > > > >+ IN EFI_PEI_MM_CONTROL_PPI * This,
> > > > >+ IN BOOLEAN Periodic OPTIONAL
> > > > >+ );
> > > > >+
> > > > >+///
> > > > >+/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It
> > provides
> > > an
> > > > >abstraction of the
> > > > >+/// platform hardware that generates an MMI. There are often I/O
> > > > >+ports
> > > > >that, when accessed, will
> > > > >+/// generate the MMI. Also, the hardware optionally supports the
> > > periodic
> > > > >generation of these signals.
> > > > >+///
> > > > >+struct _PEI_MM_CONTROL_PPI {
> > > > >+ PEI_MM_ACTIVATE Trigger;
> > > > >+ PEI_MM_DEACTIVATE Clear;
> > > > >+};
> > > > >+
> > > > >+extern EFI_GUID gEfiPeiMmControlPpiGuid;
> > > > >+
> > > > >+#endif
> > > > >diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
> > > > >b382efd578..34e0f39395 100644
> > > > >--- a/MdePkg/MdePkg.dec
> > > > >+++ b/MdePkg/MdePkg.dec
> > > > >@@ -925,6 +925,12 @@
> > > > > ## Include/Ppi/SecHobData.h
> > > > > gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4,
> > > > >0xee,
> > > 0xf5,
> > > > >0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> > > > >
> > > > >+ ## Include/Ppi/MmAccess.h
> > > > >+ gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be,
> { 0x88,
> > > > 0x17,
> > > > >0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> > > > >+
> > > > >+ ## Include/Ppi/MmControl.h
> > > > >+ gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43,
> { 0x8d,
> > > > 0xef,
> > > > >0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> > > > >+
> > > > > #
> > > > > # PPIs defined in PI 1.7.
> > > > > #
> > > > >--
> > > > >2.16.2.windows.1
> > > > >
> > > > >
> > > > >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-01 8:48 ` Marc W Chen
@ 2019-08-02 2:12 ` Laszlo Ersek
0 siblings, 0 replies; 18+ messages in thread
From: Laszlo Ersek @ 2019-08-02 2:12 UTC (permalink / raw)
To: devel, marc.w.chen, Gao, Liming; +Cc: Kinney, Michael D, Ni, Ray
On 08/01/19 10:48, Marc W Chen wrote:
> Hi Liming
>
> Since there are multiple packages are still using SmmAccess.h, we need to change all packages to use MmAccess.h instead of SmmAccess.h first, then clean up SmmAccess.h from MdeModulePkg will be the last step.
> Below are the packages that has "include <Ppi/SmmAccess.h>" for your reference.
> * Edk2 repo:
> o MdeModulePkg
> o OvmfPkg
> o UefiCpuPkg
> * Edk2Platform repo:
> o MinPlatformPkg
> o QuarkSocPkg
We discussed this in the past. I agree with introducing the new PI
names, and also expecting new platforms / new code in general to use the
new name.
I don't understand why existent code has to be updated. Not just the
#include directives, or the INF files -- that's not too bad. But
replacing a bunch of type names, in structures, local variables,
function declarations, and so on -- that's quite a bit of risk for
regressions, without any actual benefit.
In fact, where do you stop? Assume some static function uses "Smm" in
the name, in a driver. Will you want to rename that to "Mm" too? If so,
that's *really* bad (way to risky). And if not, then the resultant code
will be inconsistent, because type names will be the modern "MM" kind,
but local function and variable names will be the old "Smm" kind.
Please keep the old "SMM" identifiers in MdeModulePkg. They can be
redefined as macros / typedefs on top of the new "MM" ones in MdePkg.
Thanks
Laszlo
>> -----Original Message-----
>> From: Gao, Liming
>> Sent: Thursday, August 1, 2019 4:42 PM
>> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>
>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>> <ray.ni@intel.com>
>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
>> definition.
>>
>> Marc:
>> The change is good. Reviewed-by: Liming Gao <liming.gao@intel.com>
>>
>> Besides, I see BZ also mention to remove the one in MdeModulePkg. Have
>> you the following patches for the change in MdeModulePkg?
>>
>> Thanks
>> Liming
>>> -----Original Message-----
>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>>> Marc W Chen
>>> Sent: Monday, July 29, 2019 12:26 PM
>>> To: devel@edk2.groups.io
>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
>>> definition.
>>>
>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5 specification.
>>>
>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>>> Cc: Liming Gao <liming.gao@intel.com>
>>> Cc: Ray Ni <ray.ni@intel.com>
>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
>>> ---
>>> MdePkg/Include/Ppi/MmAccess.h | 155
>>> +++++++++++++++++++++++++++++++++++++++++
>>> MdePkg/Include/Ppi/MmControl.h | 90 ++++++++++++++++++++++++
>>> MdePkg/MdePkg.dec | 6 ++
>>> 3 files changed, 251 insertions(+)
>>> create mode 100644 MdePkg/Include/Ppi/MmAccess.h
>>> create mode 100644 MdePkg/Include/Ppi/MmControl.h
>>>
>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
>>> b/MdePkg/Include/Ppi/MmAccess.h
>>> new file mode 100644
>>> index 0000000000..636e7288a0
>>> --- /dev/null
>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
>>> @@ -0,0 +1,155 @@
>>> +/** @file
>>> + EFI MM Access PPI definition.
>>> +
>>> + This PPI is used to control the visibility of the MMRAM on the platform.
>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and characteristics of
>>> MMRAM. The
>>> + principal functionality found in the memory controller includes the
>> following:
>>> + - Exposing the MMRAM to all non-MM agents, or the "open" state
>>> + - Shrouding the MMRAM to all but the MM agents, or the "closed" state
>>> + - Preserving the system integrity, or "locking" the MMRAM, such that the
>>> settings cannot be
>>> + perturbed by either boot service or runtime agents
>>> +
>>> + Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>>> +
>>> + @par Revision Reference:
>>> + This PPI is introduced in PI Version 1.5.
>>> +
>>> +**/
>>> +
>>> +#ifndef _MM_ACCESS_PPI_H_
>>> +#define _MM_ACCESS_PPI_H_
>>> +
>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a, 0xc3, 0x2e,
>>> 0xd6 }}
>>> +
>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI EFI_PEI_MM_ACCESS_PPI;
>>> +
>>> +/**
>>> + Opens the MMRAM area to be accessible by a PEIM.
>>> +
>>> + This function "opens" MMRAM so that it is visible while not inside of MM.
>>> The function should
>>> + return EFI_UNSUPPORTED if the hardware does not support hiding of
>>> MMRAM. The function
>>> + should return EFI_DEVICE_ERROR if the MMRAM configuration is locked.
>>> +
>>> + @param PeiServices An indirect pointer to the PEI Services Table
>>> published by the PEI Foundation.
>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>> + @param DescriptorIndex The region of MMRAM to Open.
>>> +
>>> + @retval EFI_SUCCESS The operation was successful.
>>> + @retval EFI_UNSUPPORTED The system does not support opening
>> and
>>> closing of MMRAM.
>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be opened, perhaps
>>> because it is locked.
>>> +
>>> +**/
>>> +typedef
>>> +EFI_STATUS
>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
>>> + IN EFI_PEI_SERVICES **PeiServices,
>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>> + IN UINTN DescriptorIndex
>>> + );
>>> +
>>> +/**
>>> + Inhibits access to the MMRAM.
>>> +
>>> + This function "closes" MMRAM so that it is not visible while outside of
>> MM.
>>> The function should
>>> + return EFI_UNSUPPORTED if the hardware does not support hiding of
>>> MMRAM.
>>> +
>>> + @param PeiServices An indirect pointer to the PEI Services Table
>>> published by the PEI Foundation.
>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>> + @param DescriptorIndex The region of MMRAM to Close.
>>> +
>>> + @retval EFI_SUCCESS The operation was successful.
>>> + @retval EFI_UNSUPPORTED The system does not support opening
>> and
>>> closing of MMRAM.
>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
>>> +
>>> +**/
>>> +typedef
>>> +EFI_STATUS
>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
>>> + IN EFI_PEI_SERVICES **PeiServices,
>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>> + IN UINTN DescriptorIndex
>>> + );
>>> +
>>> +/**
>>> + This function prohibits access to the MMRAM region. This function is
>> usually
>>> implemented such
>>> + that it is a write-once operation.
>>> +
>>> + @param PeiServices An indirect pointer to the PEI Services Table
>>> published by the PEI Foundation.
>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>> + @param DescriptorIndex The region of MMRAM to Lock.
>>> +
>>> + @retval EFI_SUCCESS The operation was successful.
>>> + @retval EFI_UNSUPPORTED The system does not support opening
>> and
>>> closing of MMRAM.
>>> +
>>> +**/
>>> +typedef
>>> +EFI_STATUS
>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
>>> + IN EFI_PEI_SERVICES **PeiServices,
>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>> + IN UINTN DescriptorIndex
>>> + );
>>> +
>>> +/**
>>> + Queries the memory controller for the possible regions that will support
>>> MMRAM.
>>> +
>>> + This function describes the MMRAM regions.
>>> + This data structure forms the contract between the MM_ACCESS and
>>> MM_IPL drivers. There is an
>>> + ambiguity when any MMRAM region is remapped. For example, on some
>>> chipsets, some MMRAM
>>> + regions can be initialized at one physical address but is later accessed at
>>> another processor address.
>>> + There is currently no way for the MM IPL driver to know that it must use
>>> two different addresses
>>> + depending on what it is trying to do. As a result, initial configuration and
>>> loading can use the
>>> + physical address PhysicalStart while MMRAM is open. However, once the
>>> region has been
>>> + closed and needs to be accessed by agents in MM, the CpuStart address
>>> must be used.
>>> + This PPI publishes the available memory that the chipset can shroud for
>> the
>>> use of installing code.
>>> + These regions serve the dual purpose of describing which regions have
>>> been open, closed, or locked.
>>> + In addition, these regions may include overlapping memory ranges,
>>> depending on the chipset
>>> + implementation. The latter might include a chipset that supports T-SEG,
>>> where memory near the top
>>> + of the physical DRAM can be allocated for MMRAM too.
>>> + The key thing to note is that the regions that are described by the PPI are
>> a
>>> subset of the capabilities
>>> + of the hardware.
>>> +
>>> + @param PeiServices An indirect pointer to the PEI Services Table
>>> published by the PEI Foundation.
>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>> + @param MmramMapSize A pointer to the size, in bytes, of the
>>> MmramMemoryMap buffer. On input, this value is
>>> + the size of the buffer that is allocated by the caller. On
>>> output, it is the size of the
>>> + buffer that was returned by the firmware if the buffer
>> was
>>> large enough, or, if the
>>> + buffer was too small, the size of the buffer that is
>> needed to
>>> contain the map.
>>> + @param MmramMap A pointer to the buffer in which firmware
>>> places the current memory map. The map is
>>> + an array of EFI_MMRAM_DESCRIPTORs
>>> +
>>> + @retval EFI_SUCCESS The chipset supported the given resource.
>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter was too
>>> small. The current
>>> + buffer size needed to hold the memory map is returned
>> in
>>> + MmramMapSize.
>>> +
>>> +**/
>>> +typedef
>>> +EFI_STATUS
>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
>>> + IN EFI_PEI_SERVICES **PeiServices,
>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>> + IN OUT UINTN *MmramMapSize,
>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
>>> + );
>>> +
>>> +///
>>> +/// EFI MM Access PPI is used to control the visibility of the MMRAM on
>> the
>>> platform.
>>> +/// It abstracts the location and characteristics of MMRAM. The platform
>>> should report
>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is that the
>>> north bridge or
>>> +/// memory controller would publish this PPI.
>>> +///
>>> +struct _EFI_PEI_MM_ACCESS_PPI {
>>> + EFI_PEI_MM_OPEN Open;
>>> + EFI_PEI_MM_CLOSE Close;
>>> + EFI_PEI_MM_LOCK Lock;
>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
>>> + BOOLEAN LockState;
>>> + BOOLEAN OpenState;
>>> +};
>>> +
>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
>>> +
>>> +#endif
>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
>>> b/MdePkg/Include/Ppi/MmControl.h
>>> new file mode 100644
>>> index 0000000000..983ed95cd5
>>> --- /dev/null
>>> +++ b/MdePkg/Include/Ppi/MmControl.h
>>> @@ -0,0 +1,90 @@
>>> +/** @file
>>> + EFI MM Control PPI definition.
>>> +
>>> + This PPI is used initiate synchronous MMI activations. This PPI could be
>>> published by a processor
>>> + driver to abstract the MMI IPI or a driver which abstracts the ASIC that is
>>> supporting the APM port.
>>> + Because of the possibility of performing MMI IPI transactions, the ability
>> to
>>> generate this event
>>> + from a platform chipset agent is an optional capability for both IA-32 and
>>> x64-based systems.
>>> +
>>> + Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>>> +
>>> + @par Revision Reference:
>>> + This PPI is introduced in PI Version 1.5.
>>> +
>>> +**/
>>> +
>>> +
>>> +#ifndef _MM_CONTROL_PPI_H_
>>> +#define _MM_CONTROL_PPI_H_
>>> +
>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce, 0x74,
>> 0xc5 }
>>> +
>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI EFI_PEI_MM_CONTROL_PPI;
>>> +
>>> +/**
>>> + Invokes PPI activation from the PI PEI environment.
>>> +
>>> + @param PeiServices An indirect pointer to the PEI Services Table
>>> published by the PEI Foundation.
>>> + @param This The PEI_MM_CONTROL_PPI instance.
>>> + @param ArgumentBuffer The value passed to the MMI handler. This
>>> value corresponds to the
>>> + SwMmiInputValue in the RegisterContext parameter for
>> the
>>> Register()
>>> + function in the EFI_MM_SW_DISPATCH_PROTOCOL and
>> in
>>> the Context parameter
>>> + in the call to the DispatchFunction
>>> + @param ArgumentBufferSize The size of the data passed in
>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
>>> + @param Periodic An optional mechanism to periodically repeat
>>> activation.
>>> + @param ActivationInterval An optional parameter to repeat at this
>> period
>>> one
>>> + time or, if the Periodic Boolean is set, periodically.
>>> +
>>> + @retval EFI_SUCCESS The MMI has been engendered.
>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
>>> + @retval EFI_INVALID_PARAMETER The activation period is unsupported.
>>> + @retval EFI_NOT_STARTED The MM base service has not been
>> initialized.
>>> +
>>> +**/
>>> +typedef
>>> +EFI_STATUS
>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
>>> + IN EFI_PEI_SERVICES **PeiServices,
>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
>>> + IN OUT INT8 *ArgumentBuffer OPTIONAL,
>>> + IN OUT UINTN *ArgumentBufferSize OPTIONAL,
>>> + IN BOOLEAN Periodic OPTIONAL,
>>> + IN UINTN ActivationInterval OPTIONAL
>>> + );
>>> +
>>> +/**
>>> + Clears any system state that was created in response to the Trigger() call.
>>> +
>>> + @param PeiServices General purpose services available to every
>> PEIM.
>>> + @param This The PEI_MM_CONTROL_PPI instance.
>>> + @param Periodic Optional parameter to repeat at this period one
>>> + time or, if the Periodic Boolean is set, periodically.
>>> +
>>> + @retval EFI_SUCCESS The MMI has been engendered.
>>> + @retval EFI_DEVICE_ERROR The source could not be cleared.
>>> + @retval EFI_INVALID_PARAMETER The service did not support the
>> Periodic
>>> input argument.
>>> +
>>> +**/
>>> +typedef
>>> +EFI_STATUS
>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
>>> + IN EFI_PEI_SERVICES **PeiServices,
>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
>>> + IN BOOLEAN Periodic OPTIONAL
>>> + );
>>> +
>>> +///
>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It provides an
>>> abstraction of the
>>> +/// platform hardware that generates an MMI. There are often I/O ports
>>> that, when accessed, will
>>> +/// generate the MMI. Also, the hardware optionally supports the periodic
>>> generation of these signals.
>>> +///
>>> +struct _PEI_MM_CONTROL_PPI {
>>> + PEI_MM_ACTIVATE Trigger;
>>> + PEI_MM_DEACTIVATE Clear;
>>> +};
>>> +
>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
>>> +
>>> +#endif
>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
>>> index b382efd578..34e0f39395 100644
>>> --- a/MdePkg/MdePkg.dec
>>> +++ b/MdePkg/MdePkg.dec
>>> @@ -925,6 +925,12 @@
>>> ## Include/Ppi/SecHobData.h
>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4, 0xee, 0xf5,
>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
>>>
>>> + ## Include/Ppi/MmAccess.h
>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be, { 0x88,
>> 0x17,
>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
>>> +
>>> + ## Include/Ppi/MmControl.h
>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43, { 0x8d,
>> 0xef,
>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
>>> +
>>> #
>>> # PPIs defined in PI 1.7.
>>> #
>>> --
>>> 2.16.2.windows.1
>>>
>>>
>>>
>
>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-01 10:15 ` Marc W Chen
@ 2019-08-02 2:14 ` Laszlo Ersek
2019-08-06 8:56 ` Marc W Chen
0 siblings, 1 reply; 18+ messages in thread
From: Laszlo Ersek @ 2019-08-02 2:14 UTC (permalink / raw)
To: devel, marc.w.chen, Ni, Ray, Gao, Liming; +Cc: Kinney, Michael D
On 08/01/19 12:15, Marc W Chen wrote:
> Yes, my purpose is to avoid platform code update if the package is allowed to use MdeModulePkg like OvmfPkg.
> For those packages that cannot depend on MdeModulePkg must change to use new definition.
Agreed.
Thanks!
Laszlo
>> -----Original Message-----
>> From: Ni, Ray
>> Sent: Thursday, August 1, 2019 6:04 PM
>> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
>> <liming.gao@intel.com>; devel@edk2.groups.io
>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
>> definition.
>>
>> Marc,
>> Is the purpose to avoid platform code update with the wrapper header file in
>> MdeModulePkg?
>> Certain platforms they may require to not depend on MdeModulePkg but
>> just depend on MdePkg.
>> Having SmmAccess.h in MdeModulePkg doesn't help.
>>
>> It also bring confusing.
>>
>> Thanks,
>> Ray
>>
>>> -----Original Message-----
>>> From: Chen, Marc W
>>> Sent: Thursday, August 1, 2019 4:53 PM
>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>>> <ray.ni@intel.com>
>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
>>> definition.
>>>
>>> Hi Liming
>>>
>>> Another thought, do you think it is ok to keep SmmAccess.h in
>>> MdeModulePkg? We can use #define and typedef to convert MmAccess to
>>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
>>>
>>> Thanks,
>>> Marc
>>>
>>>> -----Original Message-----
>>>> From: Chen, Marc W
>>>> Sent: Thursday, August 1, 2019 4:48 PM
>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>>>> <ray.ni@intel.com>
>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>>> MmControl
>>>> definition.
>>>>
>>>> Hi Liming
>>>>
>>>> Since there are multiple packages are still using SmmAccess.h, we need
>>>> to change all packages to use MmAccess.h instead of SmmAccess.h first,
>>>> then clean up SmmAccess.h from MdeModulePkg will be the last step.
>>>> Below are the packages that has "include <Ppi/SmmAccess.h>" for your
>>>> reference.
>>>> * Edk2 repo:
>>>> o MdeModulePkg
>>>> o OvmfPkg
>>>> o UefiCpuPkg
>>>> * Edk2Platform repo:
>>>> o MinPlatformPkg
>>>> o QuarkSocPkg
>>>>
>>>> Thanks,
>>>> Marc
>>>>
>>>>> -----Original Message-----
>>>>> From: Gao, Liming
>>>>> Sent: Thursday, August 1, 2019 4:42 PM
>>>>> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>
>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>>>>> <ray.ni@intel.com>
>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>>> MmControl
>>>>> definition.
>>>>>
>>>>> Marc:
>>>>> The change is good. Reviewed-by: Liming Gao <liming.gao@intel.com>
>>>>>
>>>>> Besides, I see BZ also mention to remove the one in MdeModulePkg.
>>>>> Have you the following patches for the change in MdeModulePkg?
>>>>>
>>>>> Thanks
>>>>> Liming
>>>>>> -----Original Message-----
>>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
>> Behalf
>>>>>> Of Marc W Chen
>>>>>> Sent: Monday, July 29, 2019 12:26 PM
>>>>>> To: devel@edk2.groups.io
>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
>>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
>>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> MmControl
>>>>>> definition.
>>>>>>
>>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
>>> specification.
>>>>>>
>>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>>>>>> Cc: Liming Gao <liming.gao@intel.com>
>>>>>> Cc: Ray Ni <ray.ni@intel.com>
>>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
>>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
>>>>>> ---
>>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
>>>>>> +++++++++++++++++++++++++++++++++++++++++
>>>>>> MdePkg/Include/Ppi/MmControl.h | 90
>>> ++++++++++++++++++++++++
>>>>>> MdePkg/MdePkg.dec | 6 ++
>>>>>> 3 files changed, 251 insertions(+) create mode 100644
>>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
>>>>>> MdePkg/Include/Ppi/MmControl.h
>>>>>>
>>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
>>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644 index
>>>>>> 0000000000..636e7288a0
>>>>>> --- /dev/null
>>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
>>>>>> @@ -0,0 +1,155 @@
>>>>>> +/** @file
>>>>>> + EFI MM Access PPI definition.
>>>>>> +
>>>>>> + This PPI is used to control the visibility of the MMRAM on the
>>> platform.
>>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
>>>>>> + characteristics
>>>> of
>>>>>> MMRAM. The
>>>>>> + principal functionality found in the memory controller includes
>>>>>> + the
>>>>> following:
>>>>>> + - Exposing the MMRAM to all non-MM agents, or the "open" state
>>>>>> + - Shrouding the MMRAM to all but the MM agents, or the "closed"
>>>>>> + state
>>>>>> + - Preserving the system integrity, or "locking" the MMRAM, such
>>>>>> + that
>>>> the
>>>>>> settings cannot be
>>>>>> + perturbed by either boot service or runtime agents
>>>>>> +
>>>>>> + Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>>>>>> +
>>>>>> + @par Revision Reference:
>>>>>> + This PPI is introduced in PI Version 1.5.
>>>>>> +
>>>>>> +**/
>>>>>> +
>>>>>> +#ifndef _MM_ACCESS_PPI_H_
>>>>>> +#define _MM_ACCESS_PPI_H_
>>>>>> +
>>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
>>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
>>>>>> +0xc3, 0x2e,
>>>>>> 0xd6 }}
>>>>>> +
>>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI EFI_PEI_MM_ACCESS_PPI;
>>>>>> +
>>>>>> +/**
>>>>>> + Opens the MMRAM area to be accessible by a PEIM.
>>>>>> +
>>>>>> + This function "opens" MMRAM so that it is visible while not
>>>>>> + inside of
>>>> MM.
>>>>>> The function should
>>>>>> + return EFI_UNSUPPORTED if the hardware does not support hiding
>>>>>> + of
>>>>>> MMRAM. The function
>>>>>> + should return EFI_DEVICE_ERROR if the MMRAM configuration is
>>> locked.
>>>>>> +
>>>>>> + @param PeiServices An indirect pointer to the PEI Services
>>> Table
>>>>>> published by the PEI Foundation.
>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>>>>> + @param DescriptorIndex The region of MMRAM to Open.
>>>>>> +
>>>>>> + @retval EFI_SUCCESS The operation was successful.
>>>>>> + @retval EFI_UNSUPPORTED The system does not support
>> opening
>>>>> and
>>>>>> closing of MMRAM.
>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be opened,
>> perhaps
>>>>>> because it is locked.
>>>>>> +
>>>>>> +**/
>>>>>> +typedef
>>>>>> +EFI_STATUS
>>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>>>>> + IN UINTN DescriptorIndex
>>>>>> + );
>>>>>> +
>>>>>> +/**
>>>>>> + Inhibits access to the MMRAM.
>>>>>> +
>>>>>> + This function "closes" MMRAM so that it is not visible while
>>>>>> + outside of
>>>>> MM.
>>>>>> The function should
>>>>>> + return EFI_UNSUPPORTED if the hardware does not support hiding
>>>>>> + of
>>>>>> MMRAM.
>>>>>> +
>>>>>> + @param PeiServices An indirect pointer to the PEI Services
>>> Table
>>>>>> published by the PEI Foundation.
>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>>>>> + @param DescriptorIndex The region of MMRAM to Close.
>>>>>> +
>>>>>> + @retval EFI_SUCCESS The operation was successful.
>>>>>> + @retval EFI_UNSUPPORTED The system does not support
>> opening
>>>>> and
>>>>>> closing of MMRAM.
>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
>>>>>> +
>>>>>> +**/
>>>>>> +typedef
>>>>>> +EFI_STATUS
>>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>>>>> + IN UINTN DescriptorIndex
>>>>>> + );
>>>>>> +
>>>>>> +/**
>>>>>> + This function prohibits access to the MMRAM region. This
>>>>>> +function is
>>>>> usually
>>>>>> implemented such
>>>>>> + that it is a write-once operation.
>>>>>> +
>>>>>> + @param PeiServices An indirect pointer to the PEI Services
>>> Table
>>>>>> published by the PEI Foundation.
>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>>>>> + @param DescriptorIndex The region of MMRAM to Lock.
>>>>>> +
>>>>>> + @retval EFI_SUCCESS The operation was successful.
>>>>>> + @retval EFI_UNSUPPORTED The system does not support
>> opening
>>>>> and
>>>>>> closing of MMRAM.
>>>>>> +
>>>>>> +**/
>>>>>> +typedef
>>>>>> +EFI_STATUS
>>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>>>>> + IN UINTN DescriptorIndex
>>>>>> + );
>>>>>> +
>>>>>> +/**
>>>>>> + Queries the memory controller for the possible regions that will
>>>>>> +support
>>>>>> MMRAM.
>>>>>> +
>>>>>> + This function describes the MMRAM regions.
>>>>>> + This data structure forms the contract between the MM_ACCESS
>> and
>>>>>> MM_IPL drivers. There is an
>>>>>> + ambiguity when any MMRAM region is remapped. For example, on
>>>> some
>>>>>> chipsets, some MMRAM
>>>>>> + regions can be initialized at one physical address but is later
>>>>>> + accessed at
>>>>>> another processor address.
>>>>>> + There is currently no way for the MM IPL driver to know that it
>>>>>> + must use
>>>>>> two different addresses
>>>>>> + depending on what it is trying to do. As a result, initial
>>>>>> + configuration and
>>>>>> loading can use the
>>>>>> + physical address PhysicalStart while MMRAM is open. However,
>>>>>> + once
>>>> the
>>>>>> region has been
>>>>>> + closed and needs to be accessed by agents in MM, the CpuStart
>>>>>> + address
>>>>>> must be used.
>>>>>> + This PPI publishes the available memory that the chipset can
>>>>>> + shroud for
>>>>> the
>>>>>> use of installing code.
>>>>>> + These regions serve the dual purpose of describing which regions
>>>>>> + have
>>>>>> been open, closed, or locked.
>>>>>> + In addition, these regions may include overlapping memory
>>>>>> + ranges,
>>>>>> depending on the chipset
>>>>>> + implementation. The latter might include a chipset that supports
>>>>>> + T-SEG,
>>>>>> where memory near the top
>>>>>> + of the physical DRAM can be allocated for MMRAM too.
>>>>>> + The key thing to note is that the regions that are described by
>>>>>> + the PPI
>>>> are
>>>>> a
>>>>>> subset of the capabilities
>>>>>> + of the hardware.
>>>>>> +
>>>>>> + @param PeiServices An indirect pointer to the PEI Services
>>> Table
>>>>>> published by the PEI Foundation.
>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>>>>> + @param MmramMapSize A pointer to the size, in bytes, of
>> the
>>>>>> MmramMemoryMap buffer. On input, this value is
>>>>>> + the size of the buffer that is
>>>>>> + allocated by the caller. On
>>>>>> output, it is the size of the
>>>>>> + buffer that was returned by the
>>>>>> + firmware if the buffer
>>>>> was
>>>>>> large enough, or, if the
>>>>>> + buffer was too small, the size of
>>>>>> + the buffer that is
>>>>> needed to
>>>>>> contain the map.
>>>>>> + @param MmramMap A pointer to the buffer in which
>>> firmware
>>>>>> places the current memory map. The map is
>>>>>> + an array of EFI_MMRAM_DESCRIPTORs
>>>>>> +
>>>>>> + @retval EFI_SUCCESS The chipset supported the given
>> resource.
>>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter was
>>> too
>>>>>> small. The current
>>>>>> + buffer size needed to hold the
>>>>>> + memory map is
>>>> returned
>>>>> in
>>>>>> + MmramMapSize.
>>>>>> +
>>>>>> +**/
>>>>>> +typedef
>>>>>> +EFI_STATUS
>>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>>>>> + IN OUT UINTN *MmramMapSize,
>>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
>>>>>> + );
>>>>>> +
>>>>>> +///
>>>>>> +/// EFI MM Access PPI is used to control the visibility of the
>>>>>> +MMRAM on
>>>>> the
>>>>>> platform.
>>>>>> +/// It abstracts the location and characteristics of MMRAM. The
>>>>>> +platform
>>>>>> should report
>>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is that
>>>>>> +the
>>>>>> north bridge or
>>>>>> +/// memory controller would publish this PPI.
>>>>>> +///
>>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
>>>>>> + EFI_PEI_MM_OPEN Open;
>>>>>> + EFI_PEI_MM_CLOSE Close;
>>>>>> + EFI_PEI_MM_LOCK Lock;
>>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
>>>>>> + BOOLEAN LockState;
>>>>>> + BOOLEAN OpenState;
>>>>>> +};
>>>>>> +
>>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
>>>>>> +
>>>>>> +#endif
>>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
>>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644 index
>>>>>> 0000000000..983ed95cd5
>>>>>> --- /dev/null
>>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
>>>>>> @@ -0,0 +1,90 @@
>>>>>> +/** @file
>>>>>> + EFI MM Control PPI definition.
>>>>>> +
>>>>>> + This PPI is used initiate synchronous MMI activations. This PPI
>>>>>> + could be
>>>>>> published by a processor
>>>>>> + driver to abstract the MMI IPI or a driver which abstracts the
>>>>>> + ASIC that
>>>> is
>>>>>> supporting the APM port.
>>>>>> + Because of the possibility of performing MMI IPI transactions,
>>>>>> + the ability
>>>>> to
>>>>>> generate this event
>>>>>> + from a platform chipset agent is an optional capability for both
>>>>>> + IA-32
>>>> and
>>>>>> x64-based systems.
>>>>>> +
>>>>>> + Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>>>>>> +
>>>>>> + @par Revision Reference:
>>>>>> + This PPI is introduced in PI Version 1.5.
>>>>>> +
>>>>>> +**/
>>>>>> +
>>>>>> +
>>>>>> +#ifndef _MM_CONTROL_PPI_H_
>>>>>> +#define _MM_CONTROL_PPI_H_
>>>>>> +
>>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
>>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce,
>>>>>> +0x74,
>>>>> 0xc5 }
>>>>>> +
>>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
>>> EFI_PEI_MM_CONTROL_PPI;
>>>>>> +
>>>>>> +/**
>>>>>> + Invokes PPI activation from the PI PEI environment.
>>>>>> +
>>>>>> + @param PeiServices An indirect pointer to the PEI Services
>> Table
>>>>>> published by the PEI Foundation.
>>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
>>>>>> + @param ArgumentBuffer The value passed to the MMI handler.
>>>> This
>>>>>> value corresponds to the
>>>>>> + SwMmiInputValue in the
>>>>>> + RegisterContext parameter
>>>> for
>>>>> the
>>>>>> Register()
>>>>>> + function in the
>>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
>>>> and
>>>>> in
>>>>>> the Context parameter
>>>>>> + in the call to the DispatchFunction
>>>>>> + @param ArgumentBufferSize The size of the data passed in
>>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
>>>>>> + @param Periodic An optional mechanism to periodically
>> repeat
>>>>>> activation.
>>>>>> + @param ActivationInterval An optional parameter to repeat at
>> this
>>>>> period
>>>>>> one
>>>>>> + time or, if the Periodic Boolean is set, periodically.
>>>>>> +
>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
>>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
>>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
>>> unsupported.
>>>>>> + @retval EFI_NOT_STARTED The MM base service has not been
>>>>> initialized.
>>>>>> +
>>>>>> +**/
>>>>>> +typedef
>>>>>> +EFI_STATUS
>>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
>>>>>> + IN OUT INT8 *ArgumentBuffer OPTIONAL,
>>>>>> + IN OUT UINTN *ArgumentBufferSize OPTIONAL,
>>>>>> + IN BOOLEAN Periodic OPTIONAL,
>>>>>> + IN UINTN ActivationInterval OPTIONAL
>>>>>> + );
>>>>>> +
>>>>>> +/**
>>>>>> + Clears any system state that was created in response to the Trigger()
>>> call.
>>>>>> +
>>>>>> + @param PeiServices General purpose services available to
>> every
>>>>> PEIM.
>>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
>>>>>> + @param Periodic Optional parameter to repeat at this
>> period
>>>> one
>>>>>> + time or, if the Periodic Boolean is set, periodically.
>>>>>> +
>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
>>>>>> + @retval EFI_DEVICE_ERROR The source could not be cleared.
>>>>>> + @retval EFI_INVALID_PARAMETER The service did not support the
>>>>> Periodic
>>>>>> input argument.
>>>>>> +
>>>>>> +**/
>>>>>> +typedef
>>>>>> +EFI_STATUS
>>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
>>>>>> + IN BOOLEAN Periodic OPTIONAL
>>>>>> + );
>>>>>> +
>>>>>> +///
>>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It
>>> provides
>>>> an
>>>>>> abstraction of the
>>>>>> +/// platform hardware that generates an MMI. There are often I/O
>>>>>> +ports
>>>>>> that, when accessed, will
>>>>>> +/// generate the MMI. Also, the hardware optionally supports the
>>>> periodic
>>>>>> generation of these signals.
>>>>>> +///
>>>>>> +struct _PEI_MM_CONTROL_PPI {
>>>>>> + PEI_MM_ACTIVATE Trigger;
>>>>>> + PEI_MM_DEACTIVATE Clear;
>>>>>> +};
>>>>>> +
>>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
>>>>>> +
>>>>>> +#endif
>>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
>>>>>> b382efd578..34e0f39395 100644
>>>>>> --- a/MdePkg/MdePkg.dec
>>>>>> +++ b/MdePkg/MdePkg.dec
>>>>>> @@ -925,6 +925,12 @@
>>>>>> ## Include/Ppi/SecHobData.h
>>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4,
>>>>>> 0xee,
>>>> 0xf5,
>>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
>>>>>>
>>>>>> + ## Include/Ppi/MmAccess.h
>>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be,
>> { 0x88,
>>>>> 0x17,
>>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
>>>>>> +
>>>>>> + ## Include/Ppi/MmControl.h
>>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43,
>> { 0x8d,
>>>>> 0xef,
>>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
>>>>>> +
>>>>>> #
>>>>>> # PPIs defined in PI 1.7.
>>>>>> #
>>>>>> --
>>>>>> 2.16.2.windows.1
>>>>>>
>>>>>>
>>>>>>
>
>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-02 2:14 ` Laszlo Ersek
@ 2019-08-06 8:56 ` Marc W Chen
2019-08-06 10:08 ` Ni, Ray
0 siblings, 1 reply; 18+ messages in thread
From: Marc W Chen @ 2019-08-06 8:56 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Ni, Ray, Gao, Liming
Cc: Kinney, Michael D
Hi Liming and Ray
Do you also agree?
Thanks,
Marc
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
> Ersek
> Sent: Friday, August 2, 2019 10:14 AM
> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>; Ni, Ray
> <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> definition.
>
> On 08/01/19 12:15, Marc W Chen wrote:
> > Yes, my purpose is to avoid platform code update if the package is allowed
> to use MdeModulePkg like OvmfPkg.
> > For those packages that cannot depend on MdeModulePkg must change to
> use new definition.
>
> Agreed.
>
> Thanks!
> Laszlo
>
> >> -----Original Message-----
> >> From: Ni, Ray
> >> Sent: Thursday, August 1, 2019 6:04 PM
> >> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
> >> <liming.gao@intel.com>; devel@edk2.groups.io
> >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> MmControl
> >> definition.
> >>
> >> Marc,
> >> Is the purpose to avoid platform code update with the wrapper header
> file in
> >> MdeModulePkg?
> >> Certain platforms they may require to not depend on MdeModulePkg but
> >> just depend on MdePkg.
> >> Having SmmAccess.h in MdeModulePkg doesn't help.
> >>
> >> It also bring confusing.
> >>
> >> Thanks,
> >> Ray
> >>
> >>> -----Original Message-----
> >>> From: Chen, Marc W
> >>> Sent: Thursday, August 1, 2019 4:53 PM
> >>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> >>> <ray.ni@intel.com>
> >>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> MmControl
> >>> definition.
> >>>
> >>> Hi Liming
> >>>
> >>> Another thought, do you think it is ok to keep SmmAccess.h in
> >>> MdeModulePkg? We can use #define and typedef to convert MmAccess
> to
> >>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
> >>>
> >>> Thanks,
> >>> Marc
> >>>
> >>>> -----Original Message-----
> >>>> From: Chen, Marc W
> >>>> Sent: Thursday, August 1, 2019 4:48 PM
> >>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> >>>> <ray.ni@intel.com>
> >>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >>> MmControl
> >>>> definition.
> >>>>
> >>>> Hi Liming
> >>>>
> >>>> Since there are multiple packages are still using SmmAccess.h, we need
> >>>> to change all packages to use MmAccess.h instead of SmmAccess.h first,
> >>>> then clean up SmmAccess.h from MdeModulePkg will be the last step.
> >>>> Below are the packages that has "include <Ppi/SmmAccess.h>" for your
> >>>> reference.
> >>>> * Edk2 repo:
> >>>> o MdeModulePkg
> >>>> o OvmfPkg
> >>>> o UefiCpuPkg
> >>>> * Edk2Platform repo:
> >>>> o MinPlatformPkg
> >>>> o QuarkSocPkg
> >>>>
> >>>> Thanks,
> >>>> Marc
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Gao, Liming
> >>>>> Sent: Thursday, August 1, 2019 4:42 PM
> >>>>> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>
> >>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> >>>>> <ray.ni@intel.com>
> >>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >>> MmControl
> >>>>> definition.
> >>>>>
> >>>>> Marc:
> >>>>> The change is good. Reviewed-by: Liming Gao
> <liming.gao@intel.com>
> >>>>>
> >>>>> Besides, I see BZ also mention to remove the one in MdeModulePkg.
> >>>>> Have you the following patches for the change in MdeModulePkg?
> >>>>>
> >>>>> Thanks
> >>>>> Liming
> >>>>>> -----Original Message-----
> >>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> >> Behalf
> >>>>>> Of Marc W Chen
> >>>>>> Sent: Monday, July 29, 2019 12:26 PM
> >>>>>> To: devel@edk2.groups.io
> >>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> >>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> >>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >> MmControl
> >>>>>> definition.
> >>>>>>
> >>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
> >>> specification.
> >>>>>>
> >>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >>>>>> Cc: Liming Gao <liming.gao@intel.com>
> >>>>>> Cc: Ray Ni <ray.ni@intel.com>
> >>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> >>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> >>>>>> ---
> >>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
> >>>>>> +++++++++++++++++++++++++++++++++++++++++
> >>>>>> MdePkg/Include/Ppi/MmControl.h | 90
> >>> ++++++++++++++++++++++++
> >>>>>> MdePkg/MdePkg.dec | 6 ++
> >>>>>> 3 files changed, 251 insertions(+) create mode 100644
> >>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
> >>>>>> MdePkg/Include/Ppi/MmControl.h
> >>>>>>
> >>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
> >>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644 index
> >>>>>> 0000000000..636e7288a0
> >>>>>> --- /dev/null
> >>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
> >>>>>> @@ -0,0 +1,155 @@
> >>>>>> +/** @file
> >>>>>> + EFI MM Access PPI definition.
> >>>>>> +
> >>>>>> + This PPI is used to control the visibility of the MMRAM on the
> >>> platform.
> >>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
> >>>>>> + characteristics
> >>>> of
> >>>>>> MMRAM. The
> >>>>>> + principal functionality found in the memory controller includes
> >>>>>> + the
> >>>>> following:
> >>>>>> + - Exposing the MMRAM to all non-MM agents, or the "open" state
> >>>>>> + - Shrouding the MMRAM to all but the MM agents, or the "closed"
> >>>>>> + state
> >>>>>> + - Preserving the system integrity, or "locking" the MMRAM, such
> >>>>>> + that
> >>>> the
> >>>>>> settings cannot be
> >>>>>> + perturbed by either boot service or runtime agents
> >>>>>> +
> >>>>>> + Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
> >>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> >>>>>> +
> >>>>>> + @par Revision Reference:
> >>>>>> + This PPI is introduced in PI Version 1.5.
> >>>>>> +
> >>>>>> +**/
> >>>>>> +
> >>>>>> +#ifndef _MM_ACCESS_PPI_H_
> >>>>>> +#define _MM_ACCESS_PPI_H_
> >>>>>> +
> >>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
> >>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
> >>>>>> +0xc3, 0x2e,
> >>>>>> 0xd6 }}
> >>>>>> +
> >>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI EFI_PEI_MM_ACCESS_PPI;
> >>>>>> +
> >>>>>> +/**
> >>>>>> + Opens the MMRAM area to be accessible by a PEIM.
> >>>>>> +
> >>>>>> + This function "opens" MMRAM so that it is visible while not
> >>>>>> + inside of
> >>>> MM.
> >>>>>> The function should
> >>>>>> + return EFI_UNSUPPORTED if the hardware does not support hiding
> >>>>>> + of
> >>>>>> MMRAM. The function
> >>>>>> + should return EFI_DEVICE_ERROR if the MMRAM configuration is
> >>> locked.
> >>>>>> +
> >>>>>> + @param PeiServices An indirect pointer to the PEI Services
> >>> Table
> >>>>>> published by the PEI Foundation.
> >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >>>>>> + @param DescriptorIndex The region of MMRAM to Open.
> >>>>>> +
> >>>>>> + @retval EFI_SUCCESS The operation was successful.
> >>>>>> + @retval EFI_UNSUPPORTED The system does not support
> >> opening
> >>>>> and
> >>>>>> closing of MMRAM.
> >>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be opened,
> >> perhaps
> >>>>>> because it is locked.
> >>>>>> +
> >>>>>> +**/
> >>>>>> +typedef
> >>>>>> +EFI_STATUS
> >>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
> >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >>>>>> + IN UINTN DescriptorIndex
> >>>>>> + );
> >>>>>> +
> >>>>>> +/**
> >>>>>> + Inhibits access to the MMRAM.
> >>>>>> +
> >>>>>> + This function "closes" MMRAM so that it is not visible while
> >>>>>> + outside of
> >>>>> MM.
> >>>>>> The function should
> >>>>>> + return EFI_UNSUPPORTED if the hardware does not support hiding
> >>>>>> + of
> >>>>>> MMRAM.
> >>>>>> +
> >>>>>> + @param PeiServices An indirect pointer to the PEI Services
> >>> Table
> >>>>>> published by the PEI Foundation.
> >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >>>>>> + @param DescriptorIndex The region of MMRAM to Close.
> >>>>>> +
> >>>>>> + @retval EFI_SUCCESS The operation was successful.
> >>>>>> + @retval EFI_UNSUPPORTED The system does not support
> >> opening
> >>>>> and
> >>>>>> closing of MMRAM.
> >>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> >>>>>> +
> >>>>>> +**/
> >>>>>> +typedef
> >>>>>> +EFI_STATUS
> >>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
> >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >>>>>> + IN UINTN DescriptorIndex
> >>>>>> + );
> >>>>>> +
> >>>>>> +/**
> >>>>>> + This function prohibits access to the MMRAM region. This
> >>>>>> +function is
> >>>>> usually
> >>>>>> implemented such
> >>>>>> + that it is a write-once operation.
> >>>>>> +
> >>>>>> + @param PeiServices An indirect pointer to the PEI Services
> >>> Table
> >>>>>> published by the PEI Foundation.
> >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >>>>>> + @param DescriptorIndex The region of MMRAM to Lock.
> >>>>>> +
> >>>>>> + @retval EFI_SUCCESS The operation was successful.
> >>>>>> + @retval EFI_UNSUPPORTED The system does not support
> >> opening
> >>>>> and
> >>>>>> closing of MMRAM.
> >>>>>> +
> >>>>>> +**/
> >>>>>> +typedef
> >>>>>> +EFI_STATUS
> >>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
> >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >>>>>> + IN UINTN DescriptorIndex
> >>>>>> + );
> >>>>>> +
> >>>>>> +/**
> >>>>>> + Queries the memory controller for the possible regions that will
> >>>>>> +support
> >>>>>> MMRAM.
> >>>>>> +
> >>>>>> + This function describes the MMRAM regions.
> >>>>>> + This data structure forms the contract between the MM_ACCESS
> >> and
> >>>>>> MM_IPL drivers. There is an
> >>>>>> + ambiguity when any MMRAM region is remapped. For example, on
> >>>> some
> >>>>>> chipsets, some MMRAM
> >>>>>> + regions can be initialized at one physical address but is later
> >>>>>> + accessed at
> >>>>>> another processor address.
> >>>>>> + There is currently no way for the MM IPL driver to know that it
> >>>>>> + must use
> >>>>>> two different addresses
> >>>>>> + depending on what it is trying to do. As a result, initial
> >>>>>> + configuration and
> >>>>>> loading can use the
> >>>>>> + physical address PhysicalStart while MMRAM is open. However,
> >>>>>> + once
> >>>> the
> >>>>>> region has been
> >>>>>> + closed and needs to be accessed by agents in MM, the CpuStart
> >>>>>> + address
> >>>>>> must be used.
> >>>>>> + This PPI publishes the available memory that the chipset can
> >>>>>> + shroud for
> >>>>> the
> >>>>>> use of installing code.
> >>>>>> + These regions serve the dual purpose of describing which regions
> >>>>>> + have
> >>>>>> been open, closed, or locked.
> >>>>>> + In addition, these regions may include overlapping memory
> >>>>>> + ranges,
> >>>>>> depending on the chipset
> >>>>>> + implementation. The latter might include a chipset that supports
> >>>>>> + T-SEG,
> >>>>>> where memory near the top
> >>>>>> + of the physical DRAM can be allocated for MMRAM too.
> >>>>>> + The key thing to note is that the regions that are described by
> >>>>>> + the PPI
> >>>> are
> >>>>> a
> >>>>>> subset of the capabilities
> >>>>>> + of the hardware.
> >>>>>> +
> >>>>>> + @param PeiServices An indirect pointer to the PEI Services
> >>> Table
> >>>>>> published by the PEI Foundation.
> >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >>>>>> + @param MmramMapSize A pointer to the size, in bytes, of
> >> the
> >>>>>> MmramMemoryMap buffer. On input, this value is
> >>>>>> + the size of the buffer that is
> >>>>>> + allocated by the caller. On
> >>>>>> output, it is the size of the
> >>>>>> + buffer that was returned by the
> >>>>>> + firmware if the buffer
> >>>>> was
> >>>>>> large enough, or, if the
> >>>>>> + buffer was too small, the size of
> >>>>>> + the buffer that is
> >>>>> needed to
> >>>>>> contain the map.
> >>>>>> + @param MmramMap A pointer to the buffer in which
> >>> firmware
> >>>>>> places the current memory map. The map is
> >>>>>> + an array of EFI_MMRAM_DESCRIPTORs
> >>>>>> +
> >>>>>> + @retval EFI_SUCCESS The chipset supported the given
> >> resource.
> >>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter
> was
> >>> too
> >>>>>> small. The current
> >>>>>> + buffer size needed to hold the
> >>>>>> + memory map is
> >>>> returned
> >>>>> in
> >>>>>> + MmramMapSize.
> >>>>>> +
> >>>>>> +**/
> >>>>>> +typedef
> >>>>>> +EFI_STATUS
> >>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >>>>>> + IN OUT UINTN *MmramMapSize,
> >>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> >>>>>> + );
> >>>>>> +
> >>>>>> +///
> >>>>>> +/// EFI MM Access PPI is used to control the visibility of the
> >>>>>> +MMRAM on
> >>>>> the
> >>>>>> platform.
> >>>>>> +/// It abstracts the location and characteristics of MMRAM. The
> >>>>>> +platform
> >>>>>> should report
> >>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is
> that
> >>>>>> +the
> >>>>>> north bridge or
> >>>>>> +/// memory controller would publish this PPI.
> >>>>>> +///
> >>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
> >>>>>> + EFI_PEI_MM_OPEN Open;
> >>>>>> + EFI_PEI_MM_CLOSE Close;
> >>>>>> + EFI_PEI_MM_LOCK Lock;
> >>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
> >>>>>> + BOOLEAN LockState;
> >>>>>> + BOOLEAN OpenState;
> >>>>>> +};
> >>>>>> +
> >>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> >>>>>> +
> >>>>>> +#endif
> >>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
> >>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644 index
> >>>>>> 0000000000..983ed95cd5
> >>>>>> --- /dev/null
> >>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
> >>>>>> @@ -0,0 +1,90 @@
> >>>>>> +/** @file
> >>>>>> + EFI MM Control PPI definition.
> >>>>>> +
> >>>>>> + This PPI is used initiate synchronous MMI activations. This PPI
> >>>>>> + could be
> >>>>>> published by a processor
> >>>>>> + driver to abstract the MMI IPI or a driver which abstracts the
> >>>>>> + ASIC that
> >>>> is
> >>>>>> supporting the APM port.
> >>>>>> + Because of the possibility of performing MMI IPI transactions,
> >>>>>> + the ability
> >>>>> to
> >>>>>> generate this event
> >>>>>> + from a platform chipset agent is an optional capability for both
> >>>>>> + IA-32
> >>>> and
> >>>>>> x64-based systems.
> >>>>>> +
> >>>>>> + Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
> >>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> >>>>>> +
> >>>>>> + @par Revision Reference:
> >>>>>> + This PPI is introduced in PI Version 1.5.
> >>>>>> +
> >>>>>> +**/
> >>>>>> +
> >>>>>> +
> >>>>>> +#ifndef _MM_CONTROL_PPI_H_
> >>>>>> +#define _MM_CONTROL_PPI_H_
> >>>>>> +
> >>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
> >>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce,
> >>>>>> +0x74,
> >>>>> 0xc5 }
> >>>>>> +
> >>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
> >>> EFI_PEI_MM_CONTROL_PPI;
> >>>>>> +
> >>>>>> +/**
> >>>>>> + Invokes PPI activation from the PI PEI environment.
> >>>>>> +
> >>>>>> + @param PeiServices An indirect pointer to the PEI Services
> >> Table
> >>>>>> published by the PEI Foundation.
> >>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
> >>>>>> + @param ArgumentBuffer The value passed to the MMI
> handler.
> >>>> This
> >>>>>> value corresponds to the
> >>>>>> + SwMmiInputValue in the
> >>>>>> + RegisterContext parameter
> >>>> for
> >>>>> the
> >>>>>> Register()
> >>>>>> + function in the
> >>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
> >>>> and
> >>>>> in
> >>>>>> the Context parameter
> >>>>>> + in the call to the DispatchFunction
> >>>>>> + @param ArgumentBufferSize The size of the data passed in
> >>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> >>>>>> + @param Periodic An optional mechanism to periodically
> >> repeat
> >>>>>> activation.
> >>>>>> + @param ActivationInterval An optional parameter to repeat at
> >> this
> >>>>> period
> >>>>>> one
> >>>>>> + time or, if the Periodic Boolean is set, periodically.
> >>>>>> +
> >>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> >>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
> >>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
> >>> unsupported.
> >>>>>> + @retval EFI_NOT_STARTED The MM base service has not been
> >>>>> initialized.
> >>>>>> +
> >>>>>> +**/
> >>>>>> +typedef
> >>>>>> +EFI_STATUS
> >>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> >>>>>> + IN OUT INT8 *ArgumentBuffer OPTIONAL,
> >>>>>> + IN OUT UINTN *ArgumentBufferSize
> OPTIONAL,
> >>>>>> + IN BOOLEAN Periodic OPTIONAL,
> >>>>>> + IN UINTN ActivationInterval OPTIONAL
> >>>>>> + );
> >>>>>> +
> >>>>>> +/**
> >>>>>> + Clears any system state that was created in response to the
> Trigger()
> >>> call.
> >>>>>> +
> >>>>>> + @param PeiServices General purpose services available to
> >> every
> >>>>> PEIM.
> >>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
> >>>>>> + @param Periodic Optional parameter to repeat at this
> >> period
> >>>> one
> >>>>>> + time or, if the Periodic Boolean is set, periodically.
> >>>>>> +
> >>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> >>>>>> + @retval EFI_DEVICE_ERROR The source could not be cleared.
> >>>>>> + @retval EFI_INVALID_PARAMETER The service did not support the
> >>>>> Periodic
> >>>>>> input argument.
> >>>>>> +
> >>>>>> +**/
> >>>>>> +typedef
> >>>>>> +EFI_STATUS
> >>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
> >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> >>>>>> + IN BOOLEAN Periodic OPTIONAL
> >>>>>> + );
> >>>>>> +
> >>>>>> +///
> >>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It
> >>> provides
> >>>> an
> >>>>>> abstraction of the
> >>>>>> +/// platform hardware that generates an MMI. There are often I/O
> >>>>>> +ports
> >>>>>> that, when accessed, will
> >>>>>> +/// generate the MMI. Also, the hardware optionally supports the
> >>>> periodic
> >>>>>> generation of these signals.
> >>>>>> +///
> >>>>>> +struct _PEI_MM_CONTROL_PPI {
> >>>>>> + PEI_MM_ACTIVATE Trigger;
> >>>>>> + PEI_MM_DEACTIVATE Clear;
> >>>>>> +};
> >>>>>> +
> >>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
> >>>>>> +
> >>>>>> +#endif
> >>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
> >>>>>> b382efd578..34e0f39395 100644
> >>>>>> --- a/MdePkg/MdePkg.dec
> >>>>>> +++ b/MdePkg/MdePkg.dec
> >>>>>> @@ -925,6 +925,12 @@
> >>>>>> ## Include/Ppi/SecHobData.h
> >>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4,
> >>>>>> 0xee,
> >>>> 0xf5,
> >>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> >>>>>>
> >>>>>> + ## Include/Ppi/MmAccess.h
> >>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be,
> >> { 0x88,
> >>>>> 0x17,
> >>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> >>>>>> +
> >>>>>> + ## Include/Ppi/MmControl.h
> >>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43,
> >> { 0x8d,
> >>>>> 0xef,
> >>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> >>>>>> +
> >>>>>> #
> >>>>>> # PPIs defined in PI 1.7.
> >>>>>> #
> >>>>>> --
> >>>>>> 2.16.2.windows.1
> >>>>>>
> >>>>>>
> >>>>>>
> >
> >
> >
> >
>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-06 8:56 ` Marc W Chen
@ 2019-08-06 10:08 ` Ni, Ray
2019-08-07 4:52 ` Liming Gao
2019-08-07 16:10 ` Laszlo Ersek
0 siblings, 2 replies; 18+ messages in thread
From: Ni, Ray @ 2019-08-06 10:08 UTC (permalink / raw)
To: Chen, Marc W, devel@edk2.groups.io, lersek@redhat.com,
Gao, Liming
Cc: Kinney, Michael D
Laszlo,
Do you want to avoid touching the OvmfPkg due the file removal in MdeModulePkg?
I prefer to remove the files in MdeModulePkg to avoid future confusion.
Thanks,
Ray
> -----Original Message-----
> From: Chen, Marc W
> Sent: Tuesday, August 6, 2019 4:57 PM
> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray <ray.ni@intel.com>;
> Gao, Liming <liming.gao@intel.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> definition.
>
> Hi Liming and Ray
>
> Do you also agree?
>
> Thanks,
> Marc
>
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
> > Ersek
> > Sent: Friday, August 2, 2019 10:14 AM
> > To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>; Ni,
> > Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> MmControl
> > definition.
> >
> > On 08/01/19 12:15, Marc W Chen wrote:
> > > Yes, my purpose is to avoid platform code update if the package is
> > > allowed
> > to use MdeModulePkg like OvmfPkg.
> > > For those packages that cannot depend on MdeModulePkg must change
> to
> > use new definition.
> >
> > Agreed.
> >
> > Thanks!
> > Laszlo
> >
> > >> -----Original Message-----
> > >> From: Ni, Ray
> > >> Sent: Thursday, August 1, 2019 6:04 PM
> > >> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
> > >> <liming.gao@intel.com>; devel@edk2.groups.io
> > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > MmControl
> > >> definition.
> > >>
> > >> Marc,
> > >> Is the purpose to avoid platform code update with the wrapper
> > >> header
> > file in
> > >> MdeModulePkg?
> > >> Certain platforms they may require to not depend on MdeModulePkg
> > >> but just depend on MdePkg.
> > >> Having SmmAccess.h in MdeModulePkg doesn't help.
> > >>
> > >> It also bring confusing.
> > >>
> > >> Thanks,
> > >> Ray
> > >>
> > >>> -----Original Message-----
> > >>> From: Chen, Marc W
> > >>> Sent: Thursday, August 1, 2019 4:53 PM
> > >>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > >>> <ray.ni@intel.com>
> > >>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > MmControl
> > >>> definition.
> > >>>
> > >>> Hi Liming
> > >>>
> > >>> Another thought, do you think it is ok to keep SmmAccess.h in
> > >>> MdeModulePkg? We can use #define and typedef to convert
> MmAccess
> > to
> > >>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
> > >>>
> > >>> Thanks,
> > >>> Marc
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Chen, Marc W
> > >>>> Sent: Thursday, August 1, 2019 4:48 PM
> > >>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > >>>> <ray.ni@intel.com>
> > >>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >>> MmControl
> > >>>> definition.
> > >>>>
> > >>>> Hi Liming
> > >>>>
> > >>>> Since there are multiple packages are still using SmmAccess.h, we
> > >>>> need to change all packages to use MmAccess.h instead of
> > >>>> SmmAccess.h first, then clean up SmmAccess.h from MdeModulePkg
> will be the last step.
> > >>>> Below are the packages that has "include <Ppi/SmmAccess.h>" for
> > >>>> your reference.
> > >>>> * Edk2 repo:
> > >>>> o MdeModulePkg
> > >>>> o OvmfPkg
> > >>>> o UefiCpuPkg
> > >>>> * Edk2Platform repo:
> > >>>> o MinPlatformPkg
> > >>>> o QuarkSocPkg
> > >>>>
> > >>>> Thanks,
> > >>>> Marc
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Gao, Liming
> > >>>>> Sent: Thursday, August 1, 2019 4:42 PM
> > >>>>> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>
> > >>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > >>>>> <ray.ni@intel.com>
> > >>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >>> MmControl
> > >>>>> definition.
> > >>>>>
> > >>>>> Marc:
> > >>>>> The change is good. Reviewed-by: Liming Gao
> > <liming.gao@intel.com>
> > >>>>>
> > >>>>> Besides, I see BZ also mention to remove the one in
> MdeModulePkg.
> > >>>>> Have you the following patches for the change in MdeModulePkg?
> > >>>>>
> > >>>>> Thanks
> > >>>>> Liming
> > >>>>>> -----Original Message-----
> > >>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> > >> Behalf
> > >>>>>> Of Marc W Chen
> > >>>>>> Sent: Monday, July 29, 2019 12:26 PM
> > >>>>>> To: devel@edk2.groups.io
> > >>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> > >>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> > >>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >> MmControl
> > >>>>>> definition.
> > >>>>>>
> > >>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
> > >>> specification.
> > >>>>>>
> > >>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > >>>>>> Cc: Liming Gao <liming.gao@intel.com>
> > >>>>>> Cc: Ray Ni <ray.ni@intel.com>
> > >>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> > >>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> > >>>>>> ---
> > >>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
> > >>>>>> +++++++++++++++++++++++++++++++++++++++++
> > >>>>>> MdePkg/Include/Ppi/MmControl.h | 90
> > >>> ++++++++++++++++++++++++
> > >>>>>> MdePkg/MdePkg.dec | 6 ++
> > >>>>>> 3 files changed, 251 insertions(+) create mode 100644
> > >>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
> > >>>>>> MdePkg/Include/Ppi/MmControl.h
> > >>>>>>
> > >>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
> > >>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644 index
> > >>>>>> 0000000000..636e7288a0
> > >>>>>> --- /dev/null
> > >>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
> > >>>>>> @@ -0,0 +1,155 @@
> > >>>>>> +/** @file
> > >>>>>> + EFI MM Access PPI definition.
> > >>>>>> +
> > >>>>>> + This PPI is used to control the visibility of the MMRAM on
> > >>>>>> + the
> > >>> platform.
> > >>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
> > >>>>>> + characteristics
> > >>>> of
> > >>>>>> MMRAM. The
> > >>>>>> + principal functionality found in the memory controller
> > >>>>>> + includes the
> > >>>>> following:
> > >>>>>> + - Exposing the MMRAM to all non-MM agents, or the "open"
> > >>>>>> + state
> > >>>>>> + - Shrouding the MMRAM to all but the MM agents, or the
> "closed"
> > >>>>>> + state
> > >>>>>> + - Preserving the system integrity, or "locking" the MMRAM,
> > >>>>>> + such that
> > >>>> the
> > >>>>>> settings cannot be
> > >>>>>> + perturbed by either boot service or runtime agents
> > >>>>>> +
> > >>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> > >>>>>> + reserved.<BR>
> > >>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> > >>>>>> +
> > >>>>>> + @par Revision Reference:
> > >>>>>> + This PPI is introduced in PI Version 1.5.
> > >>>>>> +
> > >>>>>> +**/
> > >>>>>> +
> > >>>>>> +#ifndef _MM_ACCESS_PPI_H_
> > >>>>>> +#define _MM_ACCESS_PPI_H_
> > >>>>>> +
> > >>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
> > >>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
> > >>>>>> +0xc3, 0x2e,
> > >>>>>> 0xd6 }}
> > >>>>>> +
> > >>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI
> EFI_PEI_MM_ACCESS_PPI;
> > >>>>>> +
> > >>>>>> +/**
> > >>>>>> + Opens the MMRAM area to be accessible by a PEIM.
> > >>>>>> +
> > >>>>>> + This function "opens" MMRAM so that it is visible while not
> > >>>>>> + inside of
> > >>>> MM.
> > >>>>>> The function should
> > >>>>>> + return EFI_UNSUPPORTED if the hardware does not support
> > >>>>>> + hiding of
> > >>>>>> MMRAM. The function
> > >>>>>> + should return EFI_DEVICE_ERROR if the MMRAM configuration
> is
> > >>> locked.
> > >>>>>> +
> > >>>>>> + @param PeiServices An indirect pointer to the PEI Services
> > >>> Table
> > >>>>>> published by the PEI Foundation.
> > >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >>>>>> + @param DescriptorIndex The region of MMRAM to Open.
> > >>>>>> +
> > >>>>>> + @retval EFI_SUCCESS The operation was successful.
> > >>>>>> + @retval EFI_UNSUPPORTED The system does not support
> > >> opening
> > >>>>> and
> > >>>>>> closing of MMRAM.
> > >>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be opened,
> > >> perhaps
> > >>>>>> because it is locked.
> > >>>>>> +
> > >>>>>> +**/
> > >>>>>> +typedef
> > >>>>>> +EFI_STATUS
> > >>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >>>>>> + IN UINTN DescriptorIndex
> > >>>>>> + );
> > >>>>>> +
> > >>>>>> +/**
> > >>>>>> + Inhibits access to the MMRAM.
> > >>>>>> +
> > >>>>>> + This function "closes" MMRAM so that it is not visible while
> > >>>>>> + outside of
> > >>>>> MM.
> > >>>>>> The function should
> > >>>>>> + return EFI_UNSUPPORTED if the hardware does not support
> > >>>>>> + hiding of
> > >>>>>> MMRAM.
> > >>>>>> +
> > >>>>>> + @param PeiServices An indirect pointer to the PEI Services
> > >>> Table
> > >>>>>> published by the PEI Foundation.
> > >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >>>>>> + @param DescriptorIndex The region of MMRAM to Close.
> > >>>>>> +
> > >>>>>> + @retval EFI_SUCCESS The operation was successful.
> > >>>>>> + @retval EFI_UNSUPPORTED The system does not support
> > >> opening
> > >>>>> and
> > >>>>>> closing of MMRAM.
> > >>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> > >>>>>> +
> > >>>>>> +**/
> > >>>>>> +typedef
> > >>>>>> +EFI_STATUS
> > >>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >>>>>> + IN UINTN DescriptorIndex
> > >>>>>> + );
> > >>>>>> +
> > >>>>>> +/**
> > >>>>>> + This function prohibits access to the MMRAM region. This
> > >>>>>> +function is
> > >>>>> usually
> > >>>>>> implemented such
> > >>>>>> + that it is a write-once operation.
> > >>>>>> +
> > >>>>>> + @param PeiServices An indirect pointer to the PEI Services
> > >>> Table
> > >>>>>> published by the PEI Foundation.
> > >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >>>>>> + @param DescriptorIndex The region of MMRAM to Lock.
> > >>>>>> +
> > >>>>>> + @retval EFI_SUCCESS The operation was successful.
> > >>>>>> + @retval EFI_UNSUPPORTED The system does not support
> > >> opening
> > >>>>> and
> > >>>>>> closing of MMRAM.
> > >>>>>> +
> > >>>>>> +**/
> > >>>>>> +typedef
> > >>>>>> +EFI_STATUS
> > >>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >>>>>> + IN UINTN DescriptorIndex
> > >>>>>> + );
> > >>>>>> +
> > >>>>>> +/**
> > >>>>>> + Queries the memory controller for the possible regions that
> > >>>>>> +will support
> > >>>>>> MMRAM.
> > >>>>>> +
> > >>>>>> + This function describes the MMRAM regions.
> > >>>>>> + This data structure forms the contract between the
> MM_ACCESS
> > >> and
> > >>>>>> MM_IPL drivers. There is an
> > >>>>>> + ambiguity when any MMRAM region is remapped. For example,
> on
> > >>>> some
> > >>>>>> chipsets, some MMRAM
> > >>>>>> + regions can be initialized at one physical address but is
> > >>>>>> + later accessed at
> > >>>>>> another processor address.
> > >>>>>> + There is currently no way for the MM IPL driver to know that
> > >>>>>> + it must use
> > >>>>>> two different addresses
> > >>>>>> + depending on what it is trying to do. As a result, initial
> > >>>>>> + configuration and
> > >>>>>> loading can use the
> > >>>>>> + physical address PhysicalStart while MMRAM is open. However,
> > >>>>>> + once
> > >>>> the
> > >>>>>> region has been
> > >>>>>> + closed and needs to be accessed by agents in MM, the
> > >>>>>> + CpuStart address
> > >>>>>> must be used.
> > >>>>>> + This PPI publishes the available memory that the chipset can
> > >>>>>> + shroud for
> > >>>>> the
> > >>>>>> use of installing code.
> > >>>>>> + These regions serve the dual purpose of describing which
> > >>>>>> + regions have
> > >>>>>> been open, closed, or locked.
> > >>>>>> + In addition, these regions may include overlapping memory
> > >>>>>> + ranges,
> > >>>>>> depending on the chipset
> > >>>>>> + implementation. The latter might include a chipset that
> > >>>>>> + supports T-SEG,
> > >>>>>> where memory near the top
> > >>>>>> + of the physical DRAM can be allocated for MMRAM too.
> > >>>>>> + The key thing to note is that the regions that are described
> > >>>>>> + by the PPI
> > >>>> are
> > >>>>> a
> > >>>>>> subset of the capabilities
> > >>>>>> + of the hardware.
> > >>>>>> +
> > >>>>>> + @param PeiServices An indirect pointer to the PEI Services
> > >>> Table
> > >>>>>> published by the PEI Foundation.
> > >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >>>>>> + @param MmramMapSize A pointer to the size, in bytes, of
> > >> the
> > >>>>>> MmramMemoryMap buffer. On input, this value is
> > >>>>>> + the size of the buffer that
> > >>>>>> + is allocated by the caller. On
> > >>>>>> output, it is the size of the
> > >>>>>> + buffer that was returned by
> > >>>>>> + the firmware if the buffer
> > >>>>> was
> > >>>>>> large enough, or, if the
> > >>>>>> + buffer was too small, the
> > >>>>>> + size of the buffer that is
> > >>>>> needed to
> > >>>>>> contain the map.
> > >>>>>> + @param MmramMap A pointer to the buffer in which
> > >>> firmware
> > >>>>>> places the current memory map. The map is
> > >>>>>> + an array of
> > >>>>>> + EFI_MMRAM_DESCRIPTORs
> > >>>>>> +
> > >>>>>> + @retval EFI_SUCCESS The chipset supported the given
> > >> resource.
> > >>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter
> > was
> > >>> too
> > >>>>>> small. The current
> > >>>>>> + buffer size needed to hold
> > >>>>>> + the memory map is
> > >>>> returned
> > >>>>> in
> > >>>>>> + MmramMapSize.
> > >>>>>> +
> > >>>>>> +**/
> > >>>>>> +typedef
> > >>>>>> +EFI_STATUS
> > >>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >>>>>> + IN OUT UINTN *MmramMapSize,
> > >>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> > >>>>>> + );
> > >>>>>> +
> > >>>>>> +///
> > >>>>>> +/// EFI MM Access PPI is used to control the visibility of
> > >>>>>> +the MMRAM on
> > >>>>> the
> > >>>>>> platform.
> > >>>>>> +/// It abstracts the location and characteristics of MMRAM.
> > >>>>>> +The platform
> > >>>>>> should report
> > >>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is
> > that
> > >>>>>> +the
> > >>>>>> north bridge or
> > >>>>>> +/// memory controller would publish this PPI.
> > >>>>>> +///
> > >>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
> > >>>>>> + EFI_PEI_MM_OPEN Open;
> > >>>>>> + EFI_PEI_MM_CLOSE Close;
> > >>>>>> + EFI_PEI_MM_LOCK Lock;
> > >>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
> > >>>>>> + BOOLEAN LockState;
> > >>>>>> + BOOLEAN OpenState;
> > >>>>>> +};
> > >>>>>> +
> > >>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> > >>>>>> +
> > >>>>>> +#endif
> > >>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
> > >>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644 index
> > >>>>>> 0000000000..983ed95cd5
> > >>>>>> --- /dev/null
> > >>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
> > >>>>>> @@ -0,0 +1,90 @@
> > >>>>>> +/** @file
> > >>>>>> + EFI MM Control PPI definition.
> > >>>>>> +
> > >>>>>> + This PPI is used initiate synchronous MMI activations. This
> > >>>>>> + PPI could be
> > >>>>>> published by a processor
> > >>>>>> + driver to abstract the MMI IPI or a driver which abstracts
> > >>>>>> + the ASIC that
> > >>>> is
> > >>>>>> supporting the APM port.
> > >>>>>> + Because of the possibility of performing MMI IPI
> > >>>>>> + transactions, the ability
> > >>>>> to
> > >>>>>> generate this event
> > >>>>>> + from a platform chipset agent is an optional capability for
> > >>>>>> + both
> > >>>>>> + IA-32
> > >>>> and
> > >>>>>> x64-based systems.
> > >>>>>> +
> > >>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> > >>>>>> + reserved.<BR>
> > >>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> > >>>>>> +
> > >>>>>> + @par Revision Reference:
> > >>>>>> + This PPI is introduced in PI Version 1.5.
> > >>>>>> +
> > >>>>>> +**/
> > >>>>>> +
> > >>>>>> +
> > >>>>>> +#ifndef _MM_CONTROL_PPI_H_
> > >>>>>> +#define _MM_CONTROL_PPI_H_
> > >>>>>> +
> > >>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
> > >>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5,
> > >>>>>> +0xce, 0x74,
> > >>>>> 0xc5 }
> > >>>>>> +
> > >>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
> > >>> EFI_PEI_MM_CONTROL_PPI;
> > >>>>>> +
> > >>>>>> +/**
> > >>>>>> + Invokes PPI activation from the PI PEI environment.
> > >>>>>> +
> > >>>>>> + @param PeiServices An indirect pointer to the PEI Services
> > >> Table
> > >>>>>> published by the PEI Foundation.
> > >>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
> > >>>>>> + @param ArgumentBuffer The value passed to the MMI
> > handler.
> > >>>> This
> > >>>>>> value corresponds to the
> > >>>>>> + SwMmiInputValue in the
> > >>>>>> + RegisterContext parameter
> > >>>> for
> > >>>>> the
> > >>>>>> Register()
> > >>>>>> + function in the
> > >>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
> > >>>> and
> > >>>>> in
> > >>>>>> the Context parameter
> > >>>>>> + in the call to the DispatchFunction
> > >>>>>> + @param ArgumentBufferSize The size of the data passed in
> > >>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> > >>>>>> + @param Periodic An optional mechanism to periodically
> > >> repeat
> > >>>>>> activation.
> > >>>>>> + @param ActivationInterval An optional parameter to repeat at
> > >> this
> > >>>>> period
> > >>>>>> one
> > >>>>>> + time or, if the Periodic Boolean is set, periodically.
> > >>>>>> +
> > >>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> > >>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
> > >>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
> > >>> unsupported.
> > >>>>>> + @retval EFI_NOT_STARTED The MM base service has not
> been
> > >>>>> initialized.
> > >>>>>> +
> > >>>>>> +**/
> > >>>>>> +typedef
> > >>>>>> +EFI_STATUS
> > >>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> > >>>>>> + IN OUT INT8 *ArgumentBuffer OPTIONAL,
> > >>>>>> + IN OUT UINTN *ArgumentBufferSize
> > OPTIONAL,
> > >>>>>> + IN BOOLEAN Periodic OPTIONAL,
> > >>>>>> + IN UINTN ActivationInterval OPTIONAL
> > >>>>>> + );
> > >>>>>> +
> > >>>>>> +/**
> > >>>>>> + Clears any system state that was created in response to the
> > Trigger()
> > >>> call.
> > >>>>>> +
> > >>>>>> + @param PeiServices General purpose services available to
> > >> every
> > >>>>> PEIM.
> > >>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
> > >>>>>> + @param Periodic Optional parameter to repeat at this
> > >> period
> > >>>> one
> > >>>>>> + time or, if the Periodic Boolean is set, periodically.
> > >>>>>> +
> > >>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> > >>>>>> + @retval EFI_DEVICE_ERROR The source could not be cleared.
> > >>>>>> + @retval EFI_INVALID_PARAMETER The service did not support
> > >>>>>> + the
> > >>>>> Periodic
> > >>>>>> input argument.
> > >>>>>> +
> > >>>>>> +**/
> > >>>>>> +typedef
> > >>>>>> +EFI_STATUS
> > >>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> > >>>>>> + IN BOOLEAN Periodic OPTIONAL
> > >>>>>> + );
> > >>>>>> +
> > >>>>>> +///
> > >>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It
> > >>> provides
> > >>>> an
> > >>>>>> abstraction of the
> > >>>>>> +/// platform hardware that generates an MMI. There are often
> > >>>>>> +I/O ports
> > >>>>>> that, when accessed, will
> > >>>>>> +/// generate the MMI. Also, the hardware optionally supports
> > >>>>>> +the
> > >>>> periodic
> > >>>>>> generation of these signals.
> > >>>>>> +///
> > >>>>>> +struct _PEI_MM_CONTROL_PPI {
> > >>>>>> + PEI_MM_ACTIVATE Trigger;
> > >>>>>> + PEI_MM_DEACTIVATE Clear;
> > >>>>>> +};
> > >>>>>> +
> > >>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
> > >>>>>> +
> > >>>>>> +#endif
> > >>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
> > >>>>>> b382efd578..34e0f39395 100644
> > >>>>>> --- a/MdePkg/MdePkg.dec
> > >>>>>> +++ b/MdePkg/MdePkg.dec
> > >>>>>> @@ -925,6 +925,12 @@
> > >>>>>> ## Include/Ppi/SecHobData.h
> > >>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4,
> > >>>>>> 0xee,
> > >>>> 0xf5,
> > >>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> > >>>>>>
> > >>>>>> + ## Include/Ppi/MmAccess.h
> > >>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be,
> > >> { 0x88,
> > >>>>> 0x17,
> > >>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> > >>>>>> +
> > >>>>>> + ## Include/Ppi/MmControl.h
> > >>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43,
> > >> { 0x8d,
> > >>>>> 0xef,
> > >>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> > >>>>>> +
> > >>>>>> #
> > >>>>>> # PPIs defined in PI 1.7.
> > >>>>>> #
> > >>>>>> --
> > >>>>>> 2.16.2.windows.1
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >
> > >
> > >
> > >
> >
> >
> >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-06 10:08 ` Ni, Ray
@ 2019-08-07 4:52 ` Liming Gao
2019-08-07 16:10 ` Laszlo Ersek
1 sibling, 0 replies; 18+ messages in thread
From: Liming Gao @ 2019-08-07 4:52 UTC (permalink / raw)
To: Ni, Ray, Chen, Marc W, devel@edk2.groups.io, lersek@redhat.com
Cc: Kinney, Michael D, Gao, Liming
Ray:
I agree Marc option to keep SMM definition and keep SmmAccess.h in MdeModulePkg.
And, this header file can be updated to refer the definition in MmAccess.h from MdePkg.
This way aligns to current SMM definition in MdePkg.
Thanks
Liming
>-----Original Message-----
>From: Ni, Ray
>Sent: Tuesday, August 06, 2019 6:09 PM
>To: Chen, Marc W <marc.w.chen@intel.com>; devel@edk2.groups.io;
>lersek@redhat.com; Gao, Liming <liming.gao@intel.com>
>Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
>definition.
>
>Laszlo,
>Do you want to avoid touching the OvmfPkg due the file removal in
>MdeModulePkg?
>
>I prefer to remove the files in MdeModulePkg to avoid future confusion.
>
>Thanks,
>Ray
>
>> -----Original Message-----
>> From: Chen, Marc W
>> Sent: Tuesday, August 6, 2019 4:57 PM
>> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray <ray.ni@intel.com>;
>> Gao, Liming <liming.gao@intel.com>
>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
>> definition.
>>
>> Hi Liming and Ray
>>
>> Do you also agree?
>>
>> Thanks,
>> Marc
>>
>> > -----Original Message-----
>> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
>> > Ersek
>> > Sent: Friday, August 2, 2019 10:14 AM
>> > To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>; Ni,
>> > Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
>> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>> > Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> MmControl
>> > definition.
>> >
>> > On 08/01/19 12:15, Marc W Chen wrote:
>> > > Yes, my purpose is to avoid platform code update if the package is
>> > > allowed
>> > to use MdeModulePkg like OvmfPkg.
>> > > For those packages that cannot depend on MdeModulePkg must change
>> to
>> > use new definition.
>> >
>> > Agreed.
>> >
>> > Thanks!
>> > Laszlo
>> >
>> > >> -----Original Message-----
>> > >> From: Ni, Ray
>> > >> Sent: Thursday, August 1, 2019 6:04 PM
>> > >> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
>> > >> <liming.gao@intel.com>; devel@edk2.groups.io
>> > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>> > >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > MmControl
>> > >> definition.
>> > >>
>> > >> Marc,
>> > >> Is the purpose to avoid platform code update with the wrapper
>> > >> header
>> > file in
>> > >> MdeModulePkg?
>> > >> Certain platforms they may require to not depend on MdeModulePkg
>> > >> but just depend on MdePkg.
>> > >> Having SmmAccess.h in MdeModulePkg doesn't help.
>> > >>
>> > >> It also bring confusing.
>> > >>
>> > >> Thanks,
>> > >> Ray
>> > >>
>> > >>> -----Original Message-----
>> > >>> From: Chen, Marc W
>> > >>> Sent: Thursday, August 1, 2019 4:53 PM
>> > >>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
>> > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>> > >>> <ray.ni@intel.com>
>> > >>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > MmControl
>> > >>> definition.
>> > >>>
>> > >>> Hi Liming
>> > >>>
>> > >>> Another thought, do you think it is ok to keep SmmAccess.h in
>> > >>> MdeModulePkg? We can use #define and typedef to convert
>> MmAccess
>> > to
>> > >>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
>> > >>>
>> > >>> Thanks,
>> > >>> Marc
>> > >>>
>> > >>>> -----Original Message-----
>> > >>>> From: Chen, Marc W
>> > >>>> Sent: Thursday, August 1, 2019 4:48 PM
>> > >>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
>> > >>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>> > >>>> <ray.ni@intel.com>
>> > >>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > >>> MmControl
>> > >>>> definition.
>> > >>>>
>> > >>>> Hi Liming
>> > >>>>
>> > >>>> Since there are multiple packages are still using SmmAccess.h, we
>> > >>>> need to change all packages to use MmAccess.h instead of
>> > >>>> SmmAccess.h first, then clean up SmmAccess.h from
>MdeModulePkg
>> will be the last step.
>> > >>>> Below are the packages that has "include <Ppi/SmmAccess.h>" for
>> > >>>> your reference.
>> > >>>> * Edk2 repo:
>> > >>>> o MdeModulePkg
>> > >>>> o OvmfPkg
>> > >>>> o UefiCpuPkg
>> > >>>> * Edk2Platform repo:
>> > >>>> o MinPlatformPkg
>> > >>>> o QuarkSocPkg
>> > >>>>
>> > >>>> Thanks,
>> > >>>> Marc
>> > >>>>
>> > >>>>> -----Original Message-----
>> > >>>>> From: Gao, Liming
>> > >>>>> Sent: Thursday, August 1, 2019 4:42 PM
>> > >>>>> To: devel@edk2.groups.io; Chen, Marc W
><marc.w.chen@intel.com>
>> > >>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>> > >>>>> <ray.ni@intel.com>
>> > >>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > >>> MmControl
>> > >>>>> definition.
>> > >>>>>
>> > >>>>> Marc:
>> > >>>>> The change is good. Reviewed-by: Liming Gao
>> > <liming.gao@intel.com>
>> > >>>>>
>> > >>>>> Besides, I see BZ also mention to remove the one in
>> MdeModulePkg.
>> > >>>>> Have you the following patches for the change in MdeModulePkg?
>> > >>>>>
>> > >>>>> Thanks
>> > >>>>> Liming
>> > >>>>>> -----Original Message-----
>> > >>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
>> > >> Behalf
>> > >>>>>> Of Marc W Chen
>> > >>>>>> Sent: Monday, July 29, 2019 12:26 PM
>> > >>>>>> To: devel@edk2.groups.io
>> > >>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
>> > >>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
>> > >>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > >> MmControl
>> > >>>>>> definition.
>> > >>>>>>
>> > >>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
>> > >>> specification.
>> > >>>>>>
>> > >>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>> > >>>>>> Cc: Liming Gao <liming.gao@intel.com>
>> > >>>>>> Cc: Ray Ni <ray.ni@intel.com>
>> > >>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
>> > >>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
>> > >>>>>> ---
>> > >>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
>> > >>>>>> +++++++++++++++++++++++++++++++++++++++++
>> > >>>>>> MdePkg/Include/Ppi/MmControl.h | 90
>> > >>> ++++++++++++++++++++++++
>> > >>>>>> MdePkg/MdePkg.dec | 6 ++
>> > >>>>>> 3 files changed, 251 insertions(+) create mode 100644
>> > >>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
>> > >>>>>> MdePkg/Include/Ppi/MmControl.h
>> > >>>>>>
>> > >>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
>> > >>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644 index
>> > >>>>>> 0000000000..636e7288a0
>> > >>>>>> --- /dev/null
>> > >>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
>> > >>>>>> @@ -0,0 +1,155 @@
>> > >>>>>> +/** @file
>> > >>>>>> + EFI MM Access PPI definition.
>> > >>>>>> +
>> > >>>>>> + This PPI is used to control the visibility of the MMRAM on
>> > >>>>>> + the
>> > >>> platform.
>> > >>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
>> > >>>>>> + characteristics
>> > >>>> of
>> > >>>>>> MMRAM. The
>> > >>>>>> + principal functionality found in the memory controller
>> > >>>>>> + includes the
>> > >>>>> following:
>> > >>>>>> + - Exposing the MMRAM to all non-MM agents, or the "open"
>> > >>>>>> + state
>> > >>>>>> + - Shrouding the MMRAM to all but the MM agents, or the
>> "closed"
>> > >>>>>> + state
>> > >>>>>> + - Preserving the system integrity, or "locking" the MMRAM,
>> > >>>>>> + such that
>> > >>>> the
>> > >>>>>> settings cannot be
>> > >>>>>> + perturbed by either boot service or runtime agents
>> > >>>>>> +
>> > >>>>>> + Copyright (c) 2019, Intel Corporation. All rights
>> > >>>>>> + reserved.<BR>
>> > >>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>> > >>>>>> +
>> > >>>>>> + @par Revision Reference:
>> > >>>>>> + This PPI is introduced in PI Version 1.5.
>> > >>>>>> +
>> > >>>>>> +**/
>> > >>>>>> +
>> > >>>>>> +#ifndef _MM_ACCESS_PPI_H_
>> > >>>>>> +#define _MM_ACCESS_PPI_H_
>> > >>>>>> +
>> > >>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
>> > >>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
>> > >>>>>> +0xc3, 0x2e,
>> > >>>>>> 0xd6 }}
>> > >>>>>> +
>> > >>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI
>> EFI_PEI_MM_ACCESS_PPI;
>> > >>>>>> +
>> > >>>>>> +/**
>> > >>>>>> + Opens the MMRAM area to be accessible by a PEIM.
>> > >>>>>> +
>> > >>>>>> + This function "opens" MMRAM so that it is visible while not
>> > >>>>>> + inside of
>> > >>>> MM.
>> > >>>>>> The function should
>> > >>>>>> + return EFI_UNSUPPORTED if the hardware does not support
>> > >>>>>> + hiding of
>> > >>>>>> MMRAM. The function
>> > >>>>>> + should return EFI_DEVICE_ERROR if the MMRAM configuration
>> is
>> > >>> locked.
>> > >>>>>> +
>> > >>>>>> + @param PeiServices An indirect pointer to the PEI
>Services
>> > >>> Table
>> > >>>>>> published by the PEI Foundation.
>> > >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>> > >>>>>> + @param DescriptorIndex The region of MMRAM to Open.
>> > >>>>>> +
>> > >>>>>> + @retval EFI_SUCCESS The operation was successful.
>> > >>>>>> + @retval EFI_UNSUPPORTED The system does not support
>> > >> opening
>> > >>>>> and
>> > >>>>>> closing of MMRAM.
>> > >>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be opened,
>> > >> perhaps
>> > >>>>>> because it is locked.
>> > >>>>>> +
>> > >>>>>> +**/
>> > >>>>>> +typedef
>> > >>>>>> +EFI_STATUS
>> > >>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
>> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>> > >>>>>> + IN UINTN DescriptorIndex
>> > >>>>>> + );
>> > >>>>>> +
>> > >>>>>> +/**
>> > >>>>>> + Inhibits access to the MMRAM.
>> > >>>>>> +
>> > >>>>>> + This function "closes" MMRAM so that it is not visible while
>> > >>>>>> + outside of
>> > >>>>> MM.
>> > >>>>>> The function should
>> > >>>>>> + return EFI_UNSUPPORTED if the hardware does not support
>> > >>>>>> + hiding of
>> > >>>>>> MMRAM.
>> > >>>>>> +
>> > >>>>>> + @param PeiServices An indirect pointer to the PEI
>Services
>> > >>> Table
>> > >>>>>> published by the PEI Foundation.
>> > >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>> > >>>>>> + @param DescriptorIndex The region of MMRAM to Close.
>> > >>>>>> +
>> > >>>>>> + @retval EFI_SUCCESS The operation was successful.
>> > >>>>>> + @retval EFI_UNSUPPORTED The system does not support
>> > >> opening
>> > >>>>> and
>> > >>>>>> closing of MMRAM.
>> > >>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
>> > >>>>>> +
>> > >>>>>> +**/
>> > >>>>>> +typedef
>> > >>>>>> +EFI_STATUS
>> > >>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
>> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>> > >>>>>> + IN UINTN DescriptorIndex
>> > >>>>>> + );
>> > >>>>>> +
>> > >>>>>> +/**
>> > >>>>>> + This function prohibits access to the MMRAM region. This
>> > >>>>>> +function is
>> > >>>>> usually
>> > >>>>>> implemented such
>> > >>>>>> + that it is a write-once operation.
>> > >>>>>> +
>> > >>>>>> + @param PeiServices An indirect pointer to the PEI
>Services
>> > >>> Table
>> > >>>>>> published by the PEI Foundation.
>> > >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>> > >>>>>> + @param DescriptorIndex The region of MMRAM to Lock.
>> > >>>>>> +
>> > >>>>>> + @retval EFI_SUCCESS The operation was successful.
>> > >>>>>> + @retval EFI_UNSUPPORTED The system does not support
>> > >> opening
>> > >>>>> and
>> > >>>>>> closing of MMRAM.
>> > >>>>>> +
>> > >>>>>> +**/
>> > >>>>>> +typedef
>> > >>>>>> +EFI_STATUS
>> > >>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
>> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>> > >>>>>> + IN UINTN DescriptorIndex
>> > >>>>>> + );
>> > >>>>>> +
>> > >>>>>> +/**
>> > >>>>>> + Queries the memory controller for the possible regions that
>> > >>>>>> +will support
>> > >>>>>> MMRAM.
>> > >>>>>> +
>> > >>>>>> + This function describes the MMRAM regions.
>> > >>>>>> + This data structure forms the contract between the
>> MM_ACCESS
>> > >> and
>> > >>>>>> MM_IPL drivers. There is an
>> > >>>>>> + ambiguity when any MMRAM region is remapped. For example,
>> on
>> > >>>> some
>> > >>>>>> chipsets, some MMRAM
>> > >>>>>> + regions can be initialized at one physical address but is
>> > >>>>>> + later accessed at
>> > >>>>>> another processor address.
>> > >>>>>> + There is currently no way for the MM IPL driver to know that
>> > >>>>>> + it must use
>> > >>>>>> two different addresses
>> > >>>>>> + depending on what it is trying to do. As a result, initial
>> > >>>>>> + configuration and
>> > >>>>>> loading can use the
>> > >>>>>> + physical address PhysicalStart while MMRAM is open. However,
>> > >>>>>> + once
>> > >>>> the
>> > >>>>>> region has been
>> > >>>>>> + closed and needs to be accessed by agents in MM, the
>> > >>>>>> + CpuStart address
>> > >>>>>> must be used.
>> > >>>>>> + This PPI publishes the available memory that the chipset can
>> > >>>>>> + shroud for
>> > >>>>> the
>> > >>>>>> use of installing code.
>> > >>>>>> + These regions serve the dual purpose of describing which
>> > >>>>>> + regions have
>> > >>>>>> been open, closed, or locked.
>> > >>>>>> + In addition, these regions may include overlapping memory
>> > >>>>>> + ranges,
>> > >>>>>> depending on the chipset
>> > >>>>>> + implementation. The latter might include a chipset that
>> > >>>>>> + supports T-SEG,
>> > >>>>>> where memory near the top
>> > >>>>>> + of the physical DRAM can be allocated for MMRAM too.
>> > >>>>>> + The key thing to note is that the regions that are described
>> > >>>>>> + by the PPI
>> > >>>> are
>> > >>>>> a
>> > >>>>>> subset of the capabilities
>> > >>>>>> + of the hardware.
>> > >>>>>> +
>> > >>>>>> + @param PeiServices An indirect pointer to the PEI
>Services
>> > >>> Table
>> > >>>>>> published by the PEI Foundation.
>> > >>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>> > >>>>>> + @param MmramMapSize A pointer to the size, in bytes,
>of
>> > >> the
>> > >>>>>> MmramMemoryMap buffer. On input, this value is
>> > >>>>>> + the size of the buffer that
>> > >>>>>> + is allocated by the caller. On
>> > >>>>>> output, it is the size of the
>> > >>>>>> + buffer that was returned by
>> > >>>>>> + the firmware if the buffer
>> > >>>>> was
>> > >>>>>> large enough, or, if the
>> > >>>>>> + buffer was too small, the
>> > >>>>>> + size of the buffer that is
>> > >>>>> needed to
>> > >>>>>> contain the map.
>> > >>>>>> + @param MmramMap A pointer to the buffer in which
>> > >>> firmware
>> > >>>>>> places the current memory map. The map is
>> > >>>>>> + an array of
>> > >>>>>> + EFI_MMRAM_DESCRIPTORs
>> > >>>>>> +
>> > >>>>>> + @retval EFI_SUCCESS The chipset supported the given
>> > >> resource.
>> > >>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter
>> > was
>> > >>> too
>> > >>>>>> small. The current
>> > >>>>>> + buffer size needed to hold
>> > >>>>>> + the memory map is
>> > >>>> returned
>> > >>>>> in
>> > >>>>>> + MmramMapSize.
>> > >>>>>> +
>> > >>>>>> +**/
>> > >>>>>> +typedef
>> > >>>>>> +EFI_STATUS
>> > >>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
>> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>> > >>>>>> + IN OUT UINTN *MmramMapSize,
>> > >>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
>> > >>>>>> + );
>> > >>>>>> +
>> > >>>>>> +///
>> > >>>>>> +/// EFI MM Access PPI is used to control the visibility of
>> > >>>>>> +the MMRAM on
>> > >>>>> the
>> > >>>>>> platform.
>> > >>>>>> +/// It abstracts the location and characteristics of MMRAM.
>> > >>>>>> +The platform
>> > >>>>>> should report
>> > >>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation
>is
>> > that
>> > >>>>>> +the
>> > >>>>>> north bridge or
>> > >>>>>> +/// memory controller would publish this PPI.
>> > >>>>>> +///
>> > >>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
>> > >>>>>> + EFI_PEI_MM_OPEN Open;
>> > >>>>>> + EFI_PEI_MM_CLOSE Close;
>> > >>>>>> + EFI_PEI_MM_LOCK Lock;
>> > >>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
>> > >>>>>> + BOOLEAN LockState;
>> > >>>>>> + BOOLEAN OpenState;
>> > >>>>>> +};
>> > >>>>>> +
>> > >>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
>> > >>>>>> +
>> > >>>>>> +#endif
>> > >>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
>> > >>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644 index
>> > >>>>>> 0000000000..983ed95cd5
>> > >>>>>> --- /dev/null
>> > >>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
>> > >>>>>> @@ -0,0 +1,90 @@
>> > >>>>>> +/** @file
>> > >>>>>> + EFI MM Control PPI definition.
>> > >>>>>> +
>> > >>>>>> + This PPI is used initiate synchronous MMI activations. This
>> > >>>>>> + PPI could be
>> > >>>>>> published by a processor
>> > >>>>>> + driver to abstract the MMI IPI or a driver which abstracts
>> > >>>>>> + the ASIC that
>> > >>>> is
>> > >>>>>> supporting the APM port.
>> > >>>>>> + Because of the possibility of performing MMI IPI
>> > >>>>>> + transactions, the ability
>> > >>>>> to
>> > >>>>>> generate this event
>> > >>>>>> + from a platform chipset agent is an optional capability for
>> > >>>>>> + both
>> > >>>>>> + IA-32
>> > >>>> and
>> > >>>>>> x64-based systems.
>> > >>>>>> +
>> > >>>>>> + Copyright (c) 2019, Intel Corporation. All rights
>> > >>>>>> + reserved.<BR>
>> > >>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>> > >>>>>> +
>> > >>>>>> + @par Revision Reference:
>> > >>>>>> + This PPI is introduced in PI Version 1.5.
>> > >>>>>> +
>> > >>>>>> +**/
>> > >>>>>> +
>> > >>>>>> +
>> > >>>>>> +#ifndef _MM_CONTROL_PPI_H_
>> > >>>>>> +#define _MM_CONTROL_PPI_H_
>> > >>>>>> +
>> > >>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
>> > >>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5,
>> > >>>>>> +0xce, 0x74,
>> > >>>>> 0xc5 }
>> > >>>>>> +
>> > >>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
>> > >>> EFI_PEI_MM_CONTROL_PPI;
>> > >>>>>> +
>> > >>>>>> +/**
>> > >>>>>> + Invokes PPI activation from the PI PEI environment.
>> > >>>>>> +
>> > >>>>>> + @param PeiServices An indirect pointer to the PEI Services
>> > >> Table
>> > >>>>>> published by the PEI Foundation.
>> > >>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
>> > >>>>>> + @param ArgumentBuffer The value passed to the MMI
>> > handler.
>> > >>>> This
>> > >>>>>> value corresponds to the
>> > >>>>>> + SwMmiInputValue in the
>> > >>>>>> + RegisterContext parameter
>> > >>>> for
>> > >>>>> the
>> > >>>>>> Register()
>> > >>>>>> + function in the
>> > >>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
>> > >>>> and
>> > >>>>> in
>> > >>>>>> the Context parameter
>> > >>>>>> + in the call to the DispatchFunction
>> > >>>>>> + @param ArgumentBufferSize The size of the data passed in
>> > >>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
>> > >>>>>> + @param Periodic An optional mechanism to periodically
>> > >> repeat
>> > >>>>>> activation.
>> > >>>>>> + @param ActivationInterval An optional parameter to repeat
>at
>> > >> this
>> > >>>>> period
>> > >>>>>> one
>> > >>>>>> + time or, if the Periodic Boolean is set, periodically.
>> > >>>>>> +
>> > >>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
>> > >>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
>> > >>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
>> > >>> unsupported.
>> > >>>>>> + @retval EFI_NOT_STARTED The MM base service has not
>> been
>> > >>>>> initialized.
>> > >>>>>> +
>> > >>>>>> +**/
>> > >>>>>> +typedef
>> > >>>>>> +EFI_STATUS
>> > >>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
>> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
>> > >>>>>> + IN OUT INT8 *ArgumentBuffer OPTIONAL,
>> > >>>>>> + IN OUT UINTN *ArgumentBufferSize
>> > OPTIONAL,
>> > >>>>>> + IN BOOLEAN Periodic OPTIONAL,
>> > >>>>>> + IN UINTN ActivationInterval OPTIONAL
>> > >>>>>> + );
>> > >>>>>> +
>> > >>>>>> +/**
>> > >>>>>> + Clears any system state that was created in response to the
>> > Trigger()
>> > >>> call.
>> > >>>>>> +
>> > >>>>>> + @param PeiServices General purpose services available to
>> > >> every
>> > >>>>> PEIM.
>> > >>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
>> > >>>>>> + @param Periodic Optional parameter to repeat at this
>> > >> period
>> > >>>> one
>> > >>>>>> + time or, if the Periodic Boolean is set, periodically.
>> > >>>>>> +
>> > >>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
>> > >>>>>> + @retval EFI_DEVICE_ERROR The source could not be cleared.
>> > >>>>>> + @retval EFI_INVALID_PARAMETER The service did not support
>> > >>>>>> + the
>> > >>>>> Periodic
>> > >>>>>> input argument.
>> > >>>>>> +
>> > >>>>>> +**/
>> > >>>>>> +typedef
>> > >>>>>> +EFI_STATUS
>> > >>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
>> > >>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
>> > >>>>>> + IN BOOLEAN Periodic OPTIONAL
>> > >>>>>> + );
>> > >>>>>> +
>> > >>>>>> +///
>> > >>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It
>> > >>> provides
>> > >>>> an
>> > >>>>>> abstraction of the
>> > >>>>>> +/// platform hardware that generates an MMI. There are often
>> > >>>>>> +I/O ports
>> > >>>>>> that, when accessed, will
>> > >>>>>> +/// generate the MMI. Also, the hardware optionally supports
>> > >>>>>> +the
>> > >>>> periodic
>> > >>>>>> generation of these signals.
>> > >>>>>> +///
>> > >>>>>> +struct _PEI_MM_CONTROL_PPI {
>> > >>>>>> + PEI_MM_ACTIVATE Trigger;
>> > >>>>>> + PEI_MM_DEACTIVATE Clear;
>> > >>>>>> +};
>> > >>>>>> +
>> > >>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
>> > >>>>>> +
>> > >>>>>> +#endif
>> > >>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
>> > >>>>>> b382efd578..34e0f39395 100644
>> > >>>>>> --- a/MdePkg/MdePkg.dec
>> > >>>>>> +++ b/MdePkg/MdePkg.dec
>> > >>>>>> @@ -925,6 +925,12 @@
>> > >>>>>> ## Include/Ppi/SecHobData.h
>> > >>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4,
>> > >>>>>> 0xee,
>> > >>>> 0xf5,
>> > >>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
>> > >>>>>>
>> > >>>>>> + ## Include/Ppi/MmAccess.h
>> > >>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be,
>> > >> { 0x88,
>> > >>>>> 0x17,
>> > >>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
>> > >>>>>> +
>> > >>>>>> + ## Include/Ppi/MmControl.h
>> > >>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43,
>> > >> { 0x8d,
>> > >>>>> 0xef,
>> > >>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
>> > >>>>>> +
>> > >>>>>> #
>> > >>>>>> # PPIs defined in PI 1.7.
>> > >>>>>> #
>> > >>>>>> --
>> > >>>>>> 2.16.2.windows.1
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-06 10:08 ` Ni, Ray
2019-08-07 4:52 ` Liming Gao
@ 2019-08-07 16:10 ` Laszlo Ersek
2019-08-10 3:32 ` Marc W Chen
1 sibling, 1 reply; 18+ messages in thread
From: Laszlo Ersek @ 2019-08-07 16:10 UTC (permalink / raw)
To: Ni, Ray, Chen, Marc W, devel@edk2.groups.io, Gao, Liming
Cc: Kinney, Michael D
On 08/06/19 12:08, Ni, Ray wrote:
> Laszlo,
> Do you want to avoid touching the OvmfPkg due the file removal in MdeModulePkg?
My main problem with this *specific* update proposal is that the
identifiers (type names and such) that would be subject to removal were
publicly specified in earlier PI spec releases.
I don't suggest that we maintain two parallel sets of typedefs and such
in edk2. It's fine to keep the new "MM" nomenclature the main one. But
we should keep the "SMM" set of terms too, as a thin wrapper, if that's
technically feasible.
If we remove "SMM", that will not only affect OvmfPkg unpleasantly, but
a bunch of other, out-of-tree code. And the reason I suddenly care about
out-of-tree code is that such code was written against a public industry
spec (= earlier versions of the PI spec).
I don't think that the simplicity that would come from removing "SMM"
altogether, is well-balanced against the pain that it would cause for
platforms.
Earlier this was solved in the following commits:
- 07c6a47e70ba ("MdePkg: Add new definitions for Management Mode.",
2017-08-29)
- 2f208e59e4b9 ("MdePkg: Reference new definitions for Management
Mode.", 2017-08-29)
Thanks
Laszlo
> I prefer to remove the files in MdeModulePkg to avoid future confusion.
>
> Thanks,
> Ray
>
>> -----Original Message-----
>> From: Chen, Marc W
>> Sent: Tuesday, August 6, 2019 4:57 PM
>> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray <ray.ni@intel.com>;
>> Gao, Liming <liming.gao@intel.com>
>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
>> definition.
>>
>> Hi Liming and Ray
>>
>> Do you also agree?
>>
>> Thanks,
>> Marc
>>
>>> -----Original Message-----
>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
>>> Ersek
>>> Sent: Friday, August 2, 2019 10:14 AM
>>> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>; Ni,
>>> Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>>> Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> MmControl
>>> definition.
>>>
>>> On 08/01/19 12:15, Marc W Chen wrote:
>>>> Yes, my purpose is to avoid platform code update if the package is
>>>> allowed
>>> to use MdeModulePkg like OvmfPkg.
>>>> For those packages that cannot depend on MdeModulePkg must change
>> to
>>> use new definition.
>>>
>>> Agreed.
>>>
>>> Thanks!
>>> Laszlo
>>>
>>>>> -----Original Message-----
>>>>> From: Ni, Ray
>>>>> Sent: Thursday, August 1, 2019 6:04 PM
>>>>> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
>>>>> <liming.gao@intel.com>; devel@edk2.groups.io
>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>>> MmControl
>>>>> definition.
>>>>>
>>>>> Marc,
>>>>> Is the purpose to avoid platform code update with the wrapper
>>>>> header
>>> file in
>>>>> MdeModulePkg?
>>>>> Certain platforms they may require to not depend on MdeModulePkg
>>>>> but just depend on MdePkg.
>>>>> Having SmmAccess.h in MdeModulePkg doesn't help.
>>>>>
>>>>> It also bring confusing.
>>>>>
>>>>> Thanks,
>>>>> Ray
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Chen, Marc W
>>>>>> Sent: Thursday, August 1, 2019 4:53 PM
>>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>>>>>> <ray.ni@intel.com>
>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>>> MmControl
>>>>>> definition.
>>>>>>
>>>>>> Hi Liming
>>>>>>
>>>>>> Another thought, do you think it is ok to keep SmmAccess.h in
>>>>>> MdeModulePkg? We can use #define and typedef to convert
>> MmAccess
>>> to
>>>>>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
>>>>>>
>>>>>> Thanks,
>>>>>> Marc
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Chen, Marc W
>>>>>>> Sent: Thursday, August 1, 2019 4:48 PM
>>>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>>>>>>> <ray.ni@intel.com>
>>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>>>>>> MmControl
>>>>>>> definition.
>>>>>>>
>>>>>>> Hi Liming
>>>>>>>
>>>>>>> Since there are multiple packages are still using SmmAccess.h, we
>>>>>>> need to change all packages to use MmAccess.h instead of
>>>>>>> SmmAccess.h first, then clean up SmmAccess.h from MdeModulePkg
>> will be the last step.
>>>>>>> Below are the packages that has "include <Ppi/SmmAccess.h>" for
>>>>>>> your reference.
>>>>>>> * Edk2 repo:
>>>>>>> o MdeModulePkg
>>>>>>> o OvmfPkg
>>>>>>> o UefiCpuPkg
>>>>>>> * Edk2Platform repo:
>>>>>>> o MinPlatformPkg
>>>>>>> o QuarkSocPkg
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marc
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Gao, Liming
>>>>>>>> Sent: Thursday, August 1, 2019 4:42 PM
>>>>>>>> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>
>>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>>>>>>>> <ray.ni@intel.com>
>>>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>>>>>> MmControl
>>>>>>>> definition.
>>>>>>>>
>>>>>>>> Marc:
>>>>>>>> The change is good. Reviewed-by: Liming Gao
>>> <liming.gao@intel.com>
>>>>>>>>
>>>>>>>> Besides, I see BZ also mention to remove the one in
>> MdeModulePkg.
>>>>>>>> Have you the following patches for the change in MdeModulePkg?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Liming
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
>>>>> Behalf
>>>>>>>>> Of Marc W Chen
>>>>>>>>> Sent: Monday, July 29, 2019 12:26 PM
>>>>>>>>> To: devel@edk2.groups.io
>>>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
>>>>>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
>>>>>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>>>>> MmControl
>>>>>>>>> definition.
>>>>>>>>>
>>>>>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
>>>>>> specification.
>>>>>>>>>
>>>>>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>>>>>>>>> Cc: Liming Gao <liming.gao@intel.com>
>>>>>>>>> Cc: Ray Ni <ray.ni@intel.com>
>>>>>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
>>>>>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
>>>>>>>>> ---
>>>>>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
>>>>>>>>> +++++++++++++++++++++++++++++++++++++++++
>>>>>>>>> MdePkg/Include/Ppi/MmControl.h | 90
>>>>>> ++++++++++++++++++++++++
>>>>>>>>> MdePkg/MdePkg.dec | 6 ++
>>>>>>>>> 3 files changed, 251 insertions(+) create mode 100644
>>>>>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
>>>>>>>>> MdePkg/Include/Ppi/MmControl.h
>>>>>>>>>
>>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
>>>>>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644 index
>>>>>>>>> 0000000000..636e7288a0
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
>>>>>>>>> @@ -0,0 +1,155 @@
>>>>>>>>> +/** @file
>>>>>>>>> + EFI MM Access PPI definition.
>>>>>>>>> +
>>>>>>>>> + This PPI is used to control the visibility of the MMRAM on
>>>>>>>>> + the
>>>>>> platform.
>>>>>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
>>>>>>>>> + characteristics
>>>>>>> of
>>>>>>>>> MMRAM. The
>>>>>>>>> + principal functionality found in the memory controller
>>>>>>>>> + includes the
>>>>>>>> following:
>>>>>>>>> + - Exposing the MMRAM to all non-MM agents, or the "open"
>>>>>>>>> + state
>>>>>>>>> + - Shrouding the MMRAM to all but the MM agents, or the
>> "closed"
>>>>>>>>> + state
>>>>>>>>> + - Preserving the system integrity, or "locking" the MMRAM,
>>>>>>>>> + such that
>>>>>>> the
>>>>>>>>> settings cannot be
>>>>>>>>> + perturbed by either boot service or runtime agents
>>>>>>>>> +
>>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
>>>>>>>>> + reserved.<BR>
>>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>>>>>>>>> +
>>>>>>>>> + @par Revision Reference:
>>>>>>>>> + This PPI is introduced in PI Version 1.5.
>>>>>>>>> +
>>>>>>>>> +**/
>>>>>>>>> +
>>>>>>>>> +#ifndef _MM_ACCESS_PPI_H_
>>>>>>>>> +#define _MM_ACCESS_PPI_H_
>>>>>>>>> +
>>>>>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
>>>>>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
>>>>>>>>> +0xc3, 0x2e,
>>>>>>>>> 0xd6 }}
>>>>>>>>> +
>>>>>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI
>> EFI_PEI_MM_ACCESS_PPI;
>>>>>>>>> +
>>>>>>>>> +/**
>>>>>>>>> + Opens the MMRAM area to be accessible by a PEIM.
>>>>>>>>> +
>>>>>>>>> + This function "opens" MMRAM so that it is visible while not
>>>>>>>>> + inside of
>>>>>>> MM.
>>>>>>>>> The function should
>>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not support
>>>>>>>>> + hiding of
>>>>>>>>> MMRAM. The function
>>>>>>>>> + should return EFI_DEVICE_ERROR if the MMRAM configuration
>> is
>>>>>> locked.
>>>>>>>>> +
>>>>>>>>> + @param PeiServices An indirect pointer to the PEI Services
>>>>>> Table
>>>>>>>>> published by the PEI Foundation.
>>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>>>>>>>> + @param DescriptorIndex The region of MMRAM to Open.
>>>>>>>>> +
>>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
>>>>>>>>> + @retval EFI_UNSUPPORTED The system does not support
>>>>> opening
>>>>>>>> and
>>>>>>>>> closing of MMRAM.
>>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be opened,
>>>>> perhaps
>>>>>>>>> because it is locked.
>>>>>>>>> +
>>>>>>>>> +**/
>>>>>>>>> +typedef
>>>>>>>>> +EFI_STATUS
>>>>>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
>>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>>>>>>>> + IN UINTN DescriptorIndex
>>>>>>>>> + );
>>>>>>>>> +
>>>>>>>>> +/**
>>>>>>>>> + Inhibits access to the MMRAM.
>>>>>>>>> +
>>>>>>>>> + This function "closes" MMRAM so that it is not visible while
>>>>>>>>> + outside of
>>>>>>>> MM.
>>>>>>>>> The function should
>>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not support
>>>>>>>>> + hiding of
>>>>>>>>> MMRAM.
>>>>>>>>> +
>>>>>>>>> + @param PeiServices An indirect pointer to the PEI Services
>>>>>> Table
>>>>>>>>> published by the PEI Foundation.
>>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>>>>>>>> + @param DescriptorIndex The region of MMRAM to Close.
>>>>>>>>> +
>>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
>>>>>>>>> + @retval EFI_UNSUPPORTED The system does not support
>>>>> opening
>>>>>>>> and
>>>>>>>>> closing of MMRAM.
>>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
>>>>>>>>> +
>>>>>>>>> +**/
>>>>>>>>> +typedef
>>>>>>>>> +EFI_STATUS
>>>>>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
>>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>>>>>>>> + IN UINTN DescriptorIndex
>>>>>>>>> + );
>>>>>>>>> +
>>>>>>>>> +/**
>>>>>>>>> + This function prohibits access to the MMRAM region. This
>>>>>>>>> +function is
>>>>>>>> usually
>>>>>>>>> implemented such
>>>>>>>>> + that it is a write-once operation.
>>>>>>>>> +
>>>>>>>>> + @param PeiServices An indirect pointer to the PEI Services
>>>>>> Table
>>>>>>>>> published by the PEI Foundation.
>>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>>>>>>>> + @param DescriptorIndex The region of MMRAM to Lock.
>>>>>>>>> +
>>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
>>>>>>>>> + @retval EFI_UNSUPPORTED The system does not support
>>>>> opening
>>>>>>>> and
>>>>>>>>> closing of MMRAM.
>>>>>>>>> +
>>>>>>>>> +**/
>>>>>>>>> +typedef
>>>>>>>>> +EFI_STATUS
>>>>>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
>>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>>>>>>>> + IN UINTN DescriptorIndex
>>>>>>>>> + );
>>>>>>>>> +
>>>>>>>>> +/**
>>>>>>>>> + Queries the memory controller for the possible regions that
>>>>>>>>> +will support
>>>>>>>>> MMRAM.
>>>>>>>>> +
>>>>>>>>> + This function describes the MMRAM regions.
>>>>>>>>> + This data structure forms the contract between the
>> MM_ACCESS
>>>>> and
>>>>>>>>> MM_IPL drivers. There is an
>>>>>>>>> + ambiguity when any MMRAM region is remapped. For example,
>> on
>>>>>>> some
>>>>>>>>> chipsets, some MMRAM
>>>>>>>>> + regions can be initialized at one physical address but is
>>>>>>>>> + later accessed at
>>>>>>>>> another processor address.
>>>>>>>>> + There is currently no way for the MM IPL driver to know that
>>>>>>>>> + it must use
>>>>>>>>> two different addresses
>>>>>>>>> + depending on what it is trying to do. As a result, initial
>>>>>>>>> + configuration and
>>>>>>>>> loading can use the
>>>>>>>>> + physical address PhysicalStart while MMRAM is open. However,
>>>>>>>>> + once
>>>>>>> the
>>>>>>>>> region has been
>>>>>>>>> + closed and needs to be accessed by agents in MM, the
>>>>>>>>> + CpuStart address
>>>>>>>>> must be used.
>>>>>>>>> + This PPI publishes the available memory that the chipset can
>>>>>>>>> + shroud for
>>>>>>>> the
>>>>>>>>> use of installing code.
>>>>>>>>> + These regions serve the dual purpose of describing which
>>>>>>>>> + regions have
>>>>>>>>> been open, closed, or locked.
>>>>>>>>> + In addition, these regions may include overlapping memory
>>>>>>>>> + ranges,
>>>>>>>>> depending on the chipset
>>>>>>>>> + implementation. The latter might include a chipset that
>>>>>>>>> + supports T-SEG,
>>>>>>>>> where memory near the top
>>>>>>>>> + of the physical DRAM can be allocated for MMRAM too.
>>>>>>>>> + The key thing to note is that the regions that are described
>>>>>>>>> + by the PPI
>>>>>>> are
>>>>>>>> a
>>>>>>>>> subset of the capabilities
>>>>>>>>> + of the hardware.
>>>>>>>>> +
>>>>>>>>> + @param PeiServices An indirect pointer to the PEI Services
>>>>>> Table
>>>>>>>>> published by the PEI Foundation.
>>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
>>>>>>>>> + @param MmramMapSize A pointer to the size, in bytes, of
>>>>> the
>>>>>>>>> MmramMemoryMap buffer. On input, this value is
>>>>>>>>> + the size of the buffer that
>>>>>>>>> + is allocated by the caller. On
>>>>>>>>> output, it is the size of the
>>>>>>>>> + buffer that was returned by
>>>>>>>>> + the firmware if the buffer
>>>>>>>> was
>>>>>>>>> large enough, or, if the
>>>>>>>>> + buffer was too small, the
>>>>>>>>> + size of the buffer that is
>>>>>>>> needed to
>>>>>>>>> contain the map.
>>>>>>>>> + @param MmramMap A pointer to the buffer in which
>>>>>> firmware
>>>>>>>>> places the current memory map. The map is
>>>>>>>>> + an array of
>>>>>>>>> + EFI_MMRAM_DESCRIPTORs
>>>>>>>>> +
>>>>>>>>> + @retval EFI_SUCCESS The chipset supported the given
>>>>> resource.
>>>>>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap parameter
>>> was
>>>>>> too
>>>>>>>>> small. The current
>>>>>>>>> + buffer size needed to hold
>>>>>>>>> + the memory map is
>>>>>>> returned
>>>>>>>> in
>>>>>>>>> + MmramMapSize.
>>>>>>>>> +
>>>>>>>>> +**/
>>>>>>>>> +typedef
>>>>>>>>> +EFI_STATUS
>>>>>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
>>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>>>>>>>>> + IN OUT UINTN *MmramMapSize,
>>>>>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
>>>>>>>>> + );
>>>>>>>>> +
>>>>>>>>> +///
>>>>>>>>> +/// EFI MM Access PPI is used to control the visibility of
>>>>>>>>> +the MMRAM on
>>>>>>>> the
>>>>>>>>> platform.
>>>>>>>>> +/// It abstracts the location and characteristics of MMRAM.
>>>>>>>>> +The platform
>>>>>>>>> should report
>>>>>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation is
>>> that
>>>>>>>>> +the
>>>>>>>>> north bridge or
>>>>>>>>> +/// memory controller would publish this PPI.
>>>>>>>>> +///
>>>>>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
>>>>>>>>> + EFI_PEI_MM_OPEN Open;
>>>>>>>>> + EFI_PEI_MM_CLOSE Close;
>>>>>>>>> + EFI_PEI_MM_LOCK Lock;
>>>>>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
>>>>>>>>> + BOOLEAN LockState;
>>>>>>>>> + BOOLEAN OpenState;
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
>>>>>>>>> +
>>>>>>>>> +#endif
>>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
>>>>>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644 index
>>>>>>>>> 0000000000..983ed95cd5
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
>>>>>>>>> @@ -0,0 +1,90 @@
>>>>>>>>> +/** @file
>>>>>>>>> + EFI MM Control PPI definition.
>>>>>>>>> +
>>>>>>>>> + This PPI is used initiate synchronous MMI activations. This
>>>>>>>>> + PPI could be
>>>>>>>>> published by a processor
>>>>>>>>> + driver to abstract the MMI IPI or a driver which abstracts
>>>>>>>>> + the ASIC that
>>>>>>> is
>>>>>>>>> supporting the APM port.
>>>>>>>>> + Because of the possibility of performing MMI IPI
>>>>>>>>> + transactions, the ability
>>>>>>>> to
>>>>>>>>> generate this event
>>>>>>>>> + from a platform chipset agent is an optional capability for
>>>>>>>>> + both
>>>>>>>>> + IA-32
>>>>>>> and
>>>>>>>>> x64-based systems.
>>>>>>>>> +
>>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
>>>>>>>>> + reserved.<BR>
>>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>>>>>>>>> +
>>>>>>>>> + @par Revision Reference:
>>>>>>>>> + This PPI is introduced in PI Version 1.5.
>>>>>>>>> +
>>>>>>>>> +**/
>>>>>>>>> +
>>>>>>>>> +
>>>>>>>>> +#ifndef _MM_CONTROL_PPI_H_
>>>>>>>>> +#define _MM_CONTROL_PPI_H_
>>>>>>>>> +
>>>>>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
>>>>>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5,
>>>>>>>>> +0xce, 0x74,
>>>>>>>> 0xc5 }
>>>>>>>>> +
>>>>>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
>>>>>> EFI_PEI_MM_CONTROL_PPI;
>>>>>>>>> +
>>>>>>>>> +/**
>>>>>>>>> + Invokes PPI activation from the PI PEI environment.
>>>>>>>>> +
>>>>>>>>> + @param PeiServices An indirect pointer to the PEI Services
>>>>> Table
>>>>>>>>> published by the PEI Foundation.
>>>>>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
>>>>>>>>> + @param ArgumentBuffer The value passed to the MMI
>>> handler.
>>>>>>> This
>>>>>>>>> value corresponds to the
>>>>>>>>> + SwMmiInputValue in the
>>>>>>>>> + RegisterContext parameter
>>>>>>> for
>>>>>>>> the
>>>>>>>>> Register()
>>>>>>>>> + function in the
>>>>>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
>>>>>>> and
>>>>>>>> in
>>>>>>>>> the Context parameter
>>>>>>>>> + in the call to the DispatchFunction
>>>>>>>>> + @param ArgumentBufferSize The size of the data passed in
>>>>>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
>>>>>>>>> + @param Periodic An optional mechanism to periodically
>>>>> repeat
>>>>>>>>> activation.
>>>>>>>>> + @param ActivationInterval An optional parameter to repeat at
>>>>> this
>>>>>>>> period
>>>>>>>>> one
>>>>>>>>> + time or, if the Periodic Boolean is set, periodically.
>>>>>>>>> +
>>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
>>>>>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
>>>>>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
>>>>>> unsupported.
>>>>>>>>> + @retval EFI_NOT_STARTED The MM base service has not
>> been
>>>>>>>> initialized.
>>>>>>>>> +
>>>>>>>>> +**/
>>>>>>>>> +typedef
>>>>>>>>> +EFI_STATUS
>>>>>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
>>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
>>>>>>>>> + IN OUT INT8 *ArgumentBuffer OPTIONAL,
>>>>>>>>> + IN OUT UINTN *ArgumentBufferSize
>>> OPTIONAL,
>>>>>>>>> + IN BOOLEAN Periodic OPTIONAL,
>>>>>>>>> + IN UINTN ActivationInterval OPTIONAL
>>>>>>>>> + );
>>>>>>>>> +
>>>>>>>>> +/**
>>>>>>>>> + Clears any system state that was created in response to the
>>> Trigger()
>>>>>> call.
>>>>>>>>> +
>>>>>>>>> + @param PeiServices General purpose services available to
>>>>> every
>>>>>>>> PEIM.
>>>>>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
>>>>>>>>> + @param Periodic Optional parameter to repeat at this
>>>>> period
>>>>>>> one
>>>>>>>>> + time or, if the Periodic Boolean is set, periodically.
>>>>>>>>> +
>>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
>>>>>>>>> + @retval EFI_DEVICE_ERROR The source could not be cleared.
>>>>>>>>> + @retval EFI_INVALID_PARAMETER The service did not support
>>>>>>>>> + the
>>>>>>>> Periodic
>>>>>>>>> input argument.
>>>>>>>>> +
>>>>>>>>> +**/
>>>>>>>>> +typedef
>>>>>>>>> +EFI_STATUS
>>>>>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
>>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
>>>>>>>>> + IN BOOLEAN Periodic OPTIONAL
>>>>>>>>> + );
>>>>>>>>> +
>>>>>>>>> +///
>>>>>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It
>>>>>> provides
>>>>>>> an
>>>>>>>>> abstraction of the
>>>>>>>>> +/// platform hardware that generates an MMI. There are often
>>>>>>>>> +I/O ports
>>>>>>>>> that, when accessed, will
>>>>>>>>> +/// generate the MMI. Also, the hardware optionally supports
>>>>>>>>> +the
>>>>>>> periodic
>>>>>>>>> generation of these signals.
>>>>>>>>> +///
>>>>>>>>> +struct _PEI_MM_CONTROL_PPI {
>>>>>>>>> + PEI_MM_ACTIVATE Trigger;
>>>>>>>>> + PEI_MM_DEACTIVATE Clear;
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
>>>>>>>>> +
>>>>>>>>> +#endif
>>>>>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
>>>>>>>>> b382efd578..34e0f39395 100644
>>>>>>>>> --- a/MdePkg/MdePkg.dec
>>>>>>>>> +++ b/MdePkg/MdePkg.dec
>>>>>>>>> @@ -925,6 +925,12 @@
>>>>>>>>> ## Include/Ppi/SecHobData.h
>>>>>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4,
>>>>>>>>> 0xee,
>>>>>>> 0xf5,
>>>>>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
>>>>>>>>>
>>>>>>>>> + ## Include/Ppi/MmAccess.h
>>>>>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be,
>>>>> { 0x88,
>>>>>>>> 0x17,
>>>>>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
>>>>>>>>> +
>>>>>>>>> + ## Include/Ppi/MmControl.h
>>>>>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43,
>>>>> { 0x8d,
>>>>>>>> 0xef,
>>>>>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
>>>>>>>>> +
>>>>>>>>> #
>>>>>>>>> # PPIs defined in PI 1.7.
>>>>>>>>> #
>>>>>>>>> --
>>>>>>>>> 2.16.2.windows.1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-07 16:10 ` Laszlo Ersek
@ 2019-08-10 3:32 ` Marc W Chen
2019-08-10 3:34 ` Liming Gao
[not found] ` <15B9725390DC0000.29320@groups.io>
0 siblings, 2 replies; 18+ messages in thread
From: Marc W Chen @ 2019-08-10 3:32 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Ni, Ray, Gao, Liming
Cc: Kinney, Michael D
Hi Liming
Since the SmmAccess.h of MdeModulePkg removal is still under discussion, can we push the MmAccess.h and MmControl.h to MdePkg first? I have other tasks pending by this.
We can keep discussing the SmmAccess after push the code.
Thanks,
Marc
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
> Ersek
> Sent: Thursday, August 8, 2019 12:11 AM
> To: Ni, Ray <ray.ni@intel.com>; Chen, Marc W <marc.w.chen@intel.com>;
> devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> definition.
>
> On 08/06/19 12:08, Ni, Ray wrote:
> > Laszlo,
> > Do you want to avoid touching the OvmfPkg due the file removal in
> MdeModulePkg?
>
> My main problem with this *specific* update proposal is that the
> identifiers (type names and such) that would be subject to removal were
> publicly specified in earlier PI spec releases.
>
> I don't suggest that we maintain two parallel sets of typedefs and such
> in edk2. It's fine to keep the new "MM" nomenclature the main one. But
> we should keep the "SMM" set of terms too, as a thin wrapper, if that's
> technically feasible.
>
> If we remove "SMM", that will not only affect OvmfPkg unpleasantly, but
> a bunch of other, out-of-tree code. And the reason I suddenly care about
> out-of-tree code is that such code was written against a public industry
> spec (= earlier versions of the PI spec).
>
> I don't think that the simplicity that would come from removing "SMM"
> altogether, is well-balanced against the pain that it would cause for
> platforms.
>
> Earlier this was solved in the following commits:
> - 07c6a47e70ba ("MdePkg: Add new definitions for Management Mode.",
> 2017-08-29)
> - 2f208e59e4b9 ("MdePkg: Reference new definitions for Management
> Mode.", 2017-08-29)
>
> Thanks
> Laszlo
>
> > I prefer to remove the files in MdeModulePkg to avoid future confusion.
> >
> > Thanks,
> > Ray
> >
> >> -----Original Message-----
> >> From: Chen, Marc W
> >> Sent: Tuesday, August 6, 2019 4:57 PM
> >> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray
> <ray.ni@intel.com>;
> >> Gao, Liming <liming.gao@intel.com>
> >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> MmControl
> >> definition.
> >>
> >> Hi Liming and Ray
> >>
> >> Do you also agree?
> >>
> >> Thanks,
> >> Marc
> >>
> >>> -----Original Message-----
> >>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> Laszlo
> >>> Ersek
> >>> Sent: Friday, August 2, 2019 10:14 AM
> >>> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>; Ni,
> >>> Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
> >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> >>> Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >> MmControl
> >>> definition.
> >>>
> >>> On 08/01/19 12:15, Marc W Chen wrote:
> >>>> Yes, my purpose is to avoid platform code update if the package is
> >>>> allowed
> >>> to use MdeModulePkg like OvmfPkg.
> >>>> For those packages that cannot depend on MdeModulePkg must
> change
> >> to
> >>> use new definition.
> >>>
> >>> Agreed.
> >>>
> >>> Thanks!
> >>> Laszlo
> >>>
> >>>>> -----Original Message-----
> >>>>> From: Ni, Ray
> >>>>> Sent: Thursday, August 1, 2019 6:04 PM
> >>>>> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
> >>>>> <liming.gao@intel.com>; devel@edk2.groups.io
> >>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> >>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >>> MmControl
> >>>>> definition.
> >>>>>
> >>>>> Marc,
> >>>>> Is the purpose to avoid platform code update with the wrapper
> >>>>> header
> >>> file in
> >>>>> MdeModulePkg?
> >>>>> Certain platforms they may require to not depend on MdeModulePkg
> >>>>> but just depend on MdePkg.
> >>>>> Having SmmAccess.h in MdeModulePkg doesn't help.
> >>>>>
> >>>>> It also bring confusing.
> >>>>>
> >>>>> Thanks,
> >>>>> Ray
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Chen, Marc W
> >>>>>> Sent: Thursday, August 1, 2019 4:53 PM
> >>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> >>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> >>>>>> <ray.ni@intel.com>
> >>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >>> MmControl
> >>>>>> definition.
> >>>>>>
> >>>>>> Hi Liming
> >>>>>>
> >>>>>> Another thought, do you think it is ok to keep SmmAccess.h in
> >>>>>> MdeModulePkg? We can use #define and typedef to convert
> >> MmAccess
> >>> to
> >>>>>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Marc
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Chen, Marc W
> >>>>>>> Sent: Thursday, August 1, 2019 4:48 PM
> >>>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> >>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> >>>>>>> <ray.ni@intel.com>
> >>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >>>>>> MmControl
> >>>>>>> definition.
> >>>>>>>
> >>>>>>> Hi Liming
> >>>>>>>
> >>>>>>> Since there are multiple packages are still using SmmAccess.h, we
> >>>>>>> need to change all packages to use MmAccess.h instead of
> >>>>>>> SmmAccess.h first, then clean up SmmAccess.h from
> MdeModulePkg
> >> will be the last step.
> >>>>>>> Below are the packages that has "include <Ppi/SmmAccess.h>" for
> >>>>>>> your reference.
> >>>>>>> * Edk2 repo:
> >>>>>>> o MdeModulePkg
> >>>>>>> o OvmfPkg
> >>>>>>> o UefiCpuPkg
> >>>>>>> * Edk2Platform repo:
> >>>>>>> o MinPlatformPkg
> >>>>>>> o QuarkSocPkg
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Marc
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Gao, Liming
> >>>>>>>> Sent: Thursday, August 1, 2019 4:42 PM
> >>>>>>>> To: devel@edk2.groups.io; Chen, Marc W
> <marc.w.chen@intel.com>
> >>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> >>>>>>>> <ray.ni@intel.com>
> >>>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >>>>>> MmControl
> >>>>>>>> definition.
> >>>>>>>>
> >>>>>>>> Marc:
> >>>>>>>> The change is good. Reviewed-by: Liming Gao
> >>> <liming.gao@intel.com>
> >>>>>>>>
> >>>>>>>> Besides, I see BZ also mention to remove the one in
> >> MdeModulePkg.
> >>>>>>>> Have you the following patches for the change in MdeModulePkg?
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Liming
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> >>>>> Behalf
> >>>>>>>>> Of Marc W Chen
> >>>>>>>>> Sent: Monday, July 29, 2019 12:26 PM
> >>>>>>>>> To: devel@edk2.groups.io
> >>>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao,
> Liming
> >>>>>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> >>>>>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >>>>> MmControl
> >>>>>>>>> definition.
> >>>>>>>>>
> >>>>>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
> >>>>>> specification.
> >>>>>>>>>
> >>>>>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >>>>>>>>> Cc: Liming Gao <liming.gao@intel.com>
> >>>>>>>>> Cc: Ray Ni <ray.ni@intel.com>
> >>>>>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> >>>>>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> >>>>>>>>> ---
> >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
> >>>>>>>>> +++++++++++++++++++++++++++++++++++++++++
> >>>>>>>>> MdePkg/Include/Ppi/MmControl.h | 90
> >>>>>> ++++++++++++++++++++++++
> >>>>>>>>> MdePkg/MdePkg.dec | 6 ++
> >>>>>>>>> 3 files changed, 251 insertions(+) create mode 100644
> >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
> >>>>>>>>> MdePkg/Include/Ppi/MmControl.h
> >>>>>>>>>
> >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
> >>>>>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644
> index
> >>>>>>>>> 0000000000..636e7288a0
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
> >>>>>>>>> @@ -0,0 +1,155 @@
> >>>>>>>>> +/** @file
> >>>>>>>>> + EFI MM Access PPI definition.
> >>>>>>>>> +
> >>>>>>>>> + This PPI is used to control the visibility of the MMRAM on
> >>>>>>>>> + the
> >>>>>> platform.
> >>>>>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
> >>>>>>>>> + characteristics
> >>>>>>> of
> >>>>>>>>> MMRAM. The
> >>>>>>>>> + principal functionality found in the memory controller
> >>>>>>>>> + includes the
> >>>>>>>> following:
> >>>>>>>>> + - Exposing the MMRAM to all non-MM agents, or the "open"
> >>>>>>>>> + state
> >>>>>>>>> + - Shrouding the MMRAM to all but the MM agents, or the
> >> "closed"
> >>>>>>>>> + state
> >>>>>>>>> + - Preserving the system integrity, or "locking" the MMRAM,
> >>>>>>>>> + such that
> >>>>>>> the
> >>>>>>>>> settings cannot be
> >>>>>>>>> + perturbed by either boot service or runtime agents
> >>>>>>>>> +
> >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> >>>>>>>>> + reserved.<BR>
> >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> >>>>>>>>> +
> >>>>>>>>> + @par Revision Reference:
> >>>>>>>>> + This PPI is introduced in PI Version 1.5.
> >>>>>>>>> +
> >>>>>>>>> +**/
> >>>>>>>>> +
> >>>>>>>>> +#ifndef _MM_ACCESS_PPI_H_
> >>>>>>>>> +#define _MM_ACCESS_PPI_H_
> >>>>>>>>> +
> >>>>>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
> >>>>>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
> >>>>>>>>> +0xc3, 0x2e,
> >>>>>>>>> 0xd6 }}
> >>>>>>>>> +
> >>>>>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI
> >> EFI_PEI_MM_ACCESS_PPI;
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + Opens the MMRAM area to be accessible by a PEIM.
> >>>>>>>>> +
> >>>>>>>>> + This function "opens" MMRAM so that it is visible while not
> >>>>>>>>> + inside of
> >>>>>>> MM.
> >>>>>>>>> The function should
> >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not support
> >>>>>>>>> + hiding of
> >>>>>>>>> MMRAM. The function
> >>>>>>>>> + should return EFI_DEVICE_ERROR if the MMRAM
> configuration
> >> is
> >>>>>> locked.
> >>>>>>>>> +
> >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> Services
> >>>>>> Table
> >>>>>>>>> published by the PEI Foundation.
> >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >>>>>>>>> + @param DescriptorIndex The region of MMRAM to Open.
> >>>>>>>>> +
> >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not support
> >>>>> opening
> >>>>>>>> and
> >>>>>>>>> closing of MMRAM.
> >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be opened,
> >>>>> perhaps
> >>>>>>>>> because it is locked.
> >>>>>>>>> +
> >>>>>>>>> +**/
> >>>>>>>>> +typedef
> >>>>>>>>> +EFI_STATUS
> >>>>>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
> >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >>>>>>>>> + IN UINTN DescriptorIndex
> >>>>>>>>> + );
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + Inhibits access to the MMRAM.
> >>>>>>>>> +
> >>>>>>>>> + This function "closes" MMRAM so that it is not visible while
> >>>>>>>>> + outside of
> >>>>>>>> MM.
> >>>>>>>>> The function should
> >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not support
> >>>>>>>>> + hiding of
> >>>>>>>>> MMRAM.
> >>>>>>>>> +
> >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> Services
> >>>>>> Table
> >>>>>>>>> published by the PEI Foundation.
> >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >>>>>>>>> + @param DescriptorIndex The region of MMRAM to Close.
> >>>>>>>>> +
> >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not support
> >>>>> opening
> >>>>>>>> and
> >>>>>>>>> closing of MMRAM.
> >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> >>>>>>>>> +
> >>>>>>>>> +**/
> >>>>>>>>> +typedef
> >>>>>>>>> +EFI_STATUS
> >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
> >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >>>>>>>>> + IN UINTN DescriptorIndex
> >>>>>>>>> + );
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + This function prohibits access to the MMRAM region. This
> >>>>>>>>> +function is
> >>>>>>>> usually
> >>>>>>>>> implemented such
> >>>>>>>>> + that it is a write-once operation.
> >>>>>>>>> +
> >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> Services
> >>>>>> Table
> >>>>>>>>> published by the PEI Foundation.
> >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >>>>>>>>> + @param DescriptorIndex The region of MMRAM to Lock.
> >>>>>>>>> +
> >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not support
> >>>>> opening
> >>>>>>>> and
> >>>>>>>>> closing of MMRAM.
> >>>>>>>>> +
> >>>>>>>>> +**/
> >>>>>>>>> +typedef
> >>>>>>>>> +EFI_STATUS
> >>>>>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
> >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >>>>>>>>> + IN UINTN DescriptorIndex
> >>>>>>>>> + );
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + Queries the memory controller for the possible regions that
> >>>>>>>>> +will support
> >>>>>>>>> MMRAM.
> >>>>>>>>> +
> >>>>>>>>> + This function describes the MMRAM regions.
> >>>>>>>>> + This data structure forms the contract between the
> >> MM_ACCESS
> >>>>> and
> >>>>>>>>> MM_IPL drivers. There is an
> >>>>>>>>> + ambiguity when any MMRAM region is remapped. For
> example,
> >> on
> >>>>>>> some
> >>>>>>>>> chipsets, some MMRAM
> >>>>>>>>> + regions can be initialized at one physical address but is
> >>>>>>>>> + later accessed at
> >>>>>>>>> another processor address.
> >>>>>>>>> + There is currently no way for the MM IPL driver to know that
> >>>>>>>>> + it must use
> >>>>>>>>> two different addresses
> >>>>>>>>> + depending on what it is trying to do. As a result, initial
> >>>>>>>>> + configuration and
> >>>>>>>>> loading can use the
> >>>>>>>>> + physical address PhysicalStart while MMRAM is open.
> However,
> >>>>>>>>> + once
> >>>>>>> the
> >>>>>>>>> region has been
> >>>>>>>>> + closed and needs to be accessed by agents in MM, the
> >>>>>>>>> + CpuStart address
> >>>>>>>>> must be used.
> >>>>>>>>> + This PPI publishes the available memory that the chipset can
> >>>>>>>>> + shroud for
> >>>>>>>> the
> >>>>>>>>> use of installing code.
> >>>>>>>>> + These regions serve the dual purpose of describing which
> >>>>>>>>> + regions have
> >>>>>>>>> been open, closed, or locked.
> >>>>>>>>> + In addition, these regions may include overlapping memory
> >>>>>>>>> + ranges,
> >>>>>>>>> depending on the chipset
> >>>>>>>>> + implementation. The latter might include a chipset that
> >>>>>>>>> + supports T-SEG,
> >>>>>>>>> where memory near the top
> >>>>>>>>> + of the physical DRAM can be allocated for MMRAM too.
> >>>>>>>>> + The key thing to note is that the regions that are described
> >>>>>>>>> + by the PPI
> >>>>>>> are
> >>>>>>>> a
> >>>>>>>>> subset of the capabilities
> >>>>>>>>> + of the hardware.
> >>>>>>>>> +
> >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> Services
> >>>>>> Table
> >>>>>>>>> published by the PEI Foundation.
> >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> >>>>>>>>> + @param MmramMapSize A pointer to the size, in bytes,
> of
> >>>>> the
> >>>>>>>>> MmramMemoryMap buffer. On input, this value is
> >>>>>>>>> + the size of the buffer that
> >>>>>>>>> + is allocated by the caller. On
> >>>>>>>>> output, it is the size of the
> >>>>>>>>> + buffer that was returned by
> >>>>>>>>> + the firmware if the buffer
> >>>>>>>> was
> >>>>>>>>> large enough, or, if the
> >>>>>>>>> + buffer was too small, the
> >>>>>>>>> + size of the buffer that is
> >>>>>>>> needed to
> >>>>>>>>> contain the map.
> >>>>>>>>> + @param MmramMap A pointer to the buffer in which
> >>>>>> firmware
> >>>>>>>>> places the current memory map. The map is
> >>>>>>>>> + an array of
> >>>>>>>>> + EFI_MMRAM_DESCRIPTORs
> >>>>>>>>> +
> >>>>>>>>> + @retval EFI_SUCCESS The chipset supported the given
> >>>>> resource.
> >>>>>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap
> parameter
> >>> was
> >>>>>> too
> >>>>>>>>> small. The current
> >>>>>>>>> + buffer size needed to hold
> >>>>>>>>> + the memory map is
> >>>>>>> returned
> >>>>>>>> in
> >>>>>>>>> + MmramMapSize.
> >>>>>>>>> +
> >>>>>>>>> +**/
> >>>>>>>>> +typedef
> >>>>>>>>> +EFI_STATUS
> >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >>>>>>>>> + IN OUT UINTN *MmramMapSize,
> >>>>>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> >>>>>>>>> + );
> >>>>>>>>> +
> >>>>>>>>> +///
> >>>>>>>>> +/// EFI MM Access PPI is used to control the visibility of
> >>>>>>>>> +the MMRAM on
> >>>>>>>> the
> >>>>>>>>> platform.
> >>>>>>>>> +/// It abstracts the location and characteristics of MMRAM.
> >>>>>>>>> +The platform
> >>>>>>>>> should report
> >>>>>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation
> is
> >>> that
> >>>>>>>>> +the
> >>>>>>>>> north bridge or
> >>>>>>>>> +/// memory controller would publish this PPI.
> >>>>>>>>> +///
> >>>>>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
> >>>>>>>>> + EFI_PEI_MM_OPEN Open;
> >>>>>>>>> + EFI_PEI_MM_CLOSE Close;
> >>>>>>>>> + EFI_PEI_MM_LOCK Lock;
> >>>>>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
> >>>>>>>>> + BOOLEAN LockState;
> >>>>>>>>> + BOOLEAN OpenState;
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> >>>>>>>>> +
> >>>>>>>>> +#endif
> >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
> >>>>>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644
> index
> >>>>>>>>> 0000000000..983ed95cd5
> >>>>>>>>> --- /dev/null
> >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
> >>>>>>>>> @@ -0,0 +1,90 @@
> >>>>>>>>> +/** @file
> >>>>>>>>> + EFI MM Control PPI definition.
> >>>>>>>>> +
> >>>>>>>>> + This PPI is used initiate synchronous MMI activations. This
> >>>>>>>>> + PPI could be
> >>>>>>>>> published by a processor
> >>>>>>>>> + driver to abstract the MMI IPI or a driver which abstracts
> >>>>>>>>> + the ASIC that
> >>>>>>> is
> >>>>>>>>> supporting the APM port.
> >>>>>>>>> + Because of the possibility of performing MMI IPI
> >>>>>>>>> + transactions, the ability
> >>>>>>>> to
> >>>>>>>>> generate this event
> >>>>>>>>> + from a platform chipset agent is an optional capability for
> >>>>>>>>> + both
> >>>>>>>>> + IA-32
> >>>>>>> and
> >>>>>>>>> x64-based systems.
> >>>>>>>>> +
> >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> >>>>>>>>> + reserved.<BR>
> >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> >>>>>>>>> +
> >>>>>>>>> + @par Revision Reference:
> >>>>>>>>> + This PPI is introduced in PI Version 1.5.
> >>>>>>>>> +
> >>>>>>>>> +**/
> >>>>>>>>> +
> >>>>>>>>> +
> >>>>>>>>> +#ifndef _MM_CONTROL_PPI_H_
> >>>>>>>>> +#define _MM_CONTROL_PPI_H_
> >>>>>>>>> +
> >>>>>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
> >>>>>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5,
> >>>>>>>>> +0xce, 0x74,
> >>>>>>>> 0xc5 }
> >>>>>>>>> +
> >>>>>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
> >>>>>> EFI_PEI_MM_CONTROL_PPI;
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + Invokes PPI activation from the PI PEI environment.
> >>>>>>>>> +
> >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> Services
> >>>>> Table
> >>>>>>>>> published by the PEI Foundation.
> >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
> >>>>>>>>> + @param ArgumentBuffer The value passed to the MMI
> >>> handler.
> >>>>>>> This
> >>>>>>>>> value corresponds to the
> >>>>>>>>> + SwMmiInputValue in the
> >>>>>>>>> + RegisterContext parameter
> >>>>>>> for
> >>>>>>>> the
> >>>>>>>>> Register()
> >>>>>>>>> + function in the
> >>>>>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
> >>>>>>> and
> >>>>>>>> in
> >>>>>>>>> the Context parameter
> >>>>>>>>> + in the call to the DispatchFunction
> >>>>>>>>> + @param ArgumentBufferSize The size of the data passed in
> >>>>>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> >>>>>>>>> + @param Periodic An optional mechanism to periodically
> >>>>> repeat
> >>>>>>>>> activation.
> >>>>>>>>> + @param ActivationInterval An optional parameter to repeat
> at
> >>>>> this
> >>>>>>>> period
> >>>>>>>>> one
> >>>>>>>>> + time or, if the Periodic Boolean is set,
> periodically.
> >>>>>>>>> +
> >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> >>>>>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
> >>>>>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
> >>>>>> unsupported.
> >>>>>>>>> + @retval EFI_NOT_STARTED The MM base service has not
> >> been
> >>>>>>>> initialized.
> >>>>>>>>> +
> >>>>>>>>> +**/
> >>>>>>>>> +typedef
> >>>>>>>>> +EFI_STATUS
> >>>>>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> >>>>>>>>> + IN OUT INT8 *ArgumentBuffer OPTIONAL,
> >>>>>>>>> + IN OUT UINTN *ArgumentBufferSize
> >>> OPTIONAL,
> >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL,
> >>>>>>>>> + IN UINTN ActivationInterval OPTIONAL
> >>>>>>>>> + );
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + Clears any system state that was created in response to the
> >>> Trigger()
> >>>>>> call.
> >>>>>>>>> +
> >>>>>>>>> + @param PeiServices General purpose services available
> to
> >>>>> every
> >>>>>>>> PEIM.
> >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
> >>>>>>>>> + @param Periodic Optional parameter to repeat at this
> >>>>> period
> >>>>>>> one
> >>>>>>>>> + time or, if the Periodic Boolean is set,
> periodically.
> >>>>>>>>> +
> >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> >>>>>>>>> + @retval EFI_DEVICE_ERROR The source could not be
> cleared.
> >>>>>>>>> + @retval EFI_INVALID_PARAMETER The service did not support
> >>>>>>>>> + the
> >>>>>>>> Periodic
> >>>>>>>>> input argument.
> >>>>>>>>> +
> >>>>>>>>> +**/
> >>>>>>>>> +typedef
> >>>>>>>>> +EFI_STATUS
> >>>>>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
> >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL
> >>>>>>>>> + );
> >>>>>>>>> +
> >>>>>>>>> +///
> >>>>>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It
> >>>>>> provides
> >>>>>>> an
> >>>>>>>>> abstraction of the
> >>>>>>>>> +/// platform hardware that generates an MMI. There are often
> >>>>>>>>> +I/O ports
> >>>>>>>>> that, when accessed, will
> >>>>>>>>> +/// generate the MMI. Also, the hardware optionally supports
> >>>>>>>>> +the
> >>>>>>> periodic
> >>>>>>>>> generation of these signals.
> >>>>>>>>> +///
> >>>>>>>>> +struct _PEI_MM_CONTROL_PPI {
> >>>>>>>>> + PEI_MM_ACTIVATE Trigger;
> >>>>>>>>> + PEI_MM_DEACTIVATE Clear;
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
> >>>>>>>>> +
> >>>>>>>>> +#endif
> >>>>>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
> >>>>>>>>> b382efd578..34e0f39395 100644
> >>>>>>>>> --- a/MdePkg/MdePkg.dec
> >>>>>>>>> +++ b/MdePkg/MdePkg.dec
> >>>>>>>>> @@ -925,6 +925,12 @@
> >>>>>>>>> ## Include/Ppi/SecHobData.h
> >>>>>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4,
> >>>>>>>>> 0xee,
> >>>>>>> 0xf5,
> >>>>>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> >>>>>>>>>
> >>>>>>>>> + ## Include/Ppi/MmAccess.h
> >>>>>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be,
> >>>>> { 0x88,
> >>>>>>>> 0x17,
> >>>>>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> >>>>>>>>> +
> >>>>>>>>> + ## Include/Ppi/MmControl.h
> >>>>>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43,
> >>>>> { 0x8d,
> >>>>>>>> 0xef,
> >>>>>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> >>>>>>>>> +
> >>>>>>>>> #
> >>>>>>>>> # PPIs defined in PI 1.7.
> >>>>>>>>> #
> >>>>>>>>> --
> >>>>>>>>> 2.16.2.windows.1
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >
>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-10 3:32 ` Marc W Chen
@ 2019-08-10 3:34 ` Liming Gao
[not found] ` <15B9725390DC0000.29320@groups.io>
1 sibling, 0 replies; 18+ messages in thread
From: Liming Gao @ 2019-08-10 3:34 UTC (permalink / raw)
To: Chen, Marc W, devel@edk2.groups.io, lersek@redhat.com, Ni, Ray
Cc: Kinney, Michael D
I agree. The patch to add them in MdePkg is clear. I will push it next Monday.
Thanks
Liming
> -----Original Message-----
> From: Chen, Marc W
> Sent: Saturday, August 10, 2019 11:33 AM
> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
>
> Hi Liming
>
> Since the SmmAccess.h of MdeModulePkg removal is still under discussion, can we push the MmAccess.h and MmControl.h to MdePkg
> first? I have other tasks pending by this.
> We can keep discussing the SmmAccess after push the code.
>
> Thanks,
> Marc
>
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
> > Ersek
> > Sent: Thursday, August 8, 2019 12:11 AM
> > To: Ni, Ray <ray.ni@intel.com>; Chen, Marc W <marc.w.chen@intel.com>;
> > devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> > definition.
> >
> > On 08/06/19 12:08, Ni, Ray wrote:
> > > Laszlo,
> > > Do you want to avoid touching the OvmfPkg due the file removal in
> > MdeModulePkg?
> >
> > My main problem with this *specific* update proposal is that the
> > identifiers (type names and such) that would be subject to removal were
> > publicly specified in earlier PI spec releases.
> >
> > I don't suggest that we maintain two parallel sets of typedefs and such
> > in edk2. It's fine to keep the new "MM" nomenclature the main one. But
> > we should keep the "SMM" set of terms too, as a thin wrapper, if that's
> > technically feasible.
> >
> > If we remove "SMM", that will not only affect OvmfPkg unpleasantly, but
> > a bunch of other, out-of-tree code. And the reason I suddenly care about
> > out-of-tree code is that such code was written against a public industry
> > spec (= earlier versions of the PI spec).
> >
> > I don't think that the simplicity that would come from removing "SMM"
> > altogether, is well-balanced against the pain that it would cause for
> > platforms.
> >
> > Earlier this was solved in the following commits:
> > - 07c6a47e70ba ("MdePkg: Add new definitions for Management Mode.",
> > 2017-08-29)
> > - 2f208e59e4b9 ("MdePkg: Reference new definitions for Management
> > Mode.", 2017-08-29)
> >
> > Thanks
> > Laszlo
> >
> > > I prefer to remove the files in MdeModulePkg to avoid future confusion.
> > >
> > > Thanks,
> > > Ray
> > >
> > >> -----Original Message-----
> > >> From: Chen, Marc W
> > >> Sent: Tuesday, August 6, 2019 4:57 PM
> > >> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray
> > <ray.ni@intel.com>;
> > >> Gao, Liming <liming.gao@intel.com>
> > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > MmControl
> > >> definition.
> > >>
> > >> Hi Liming and Ray
> > >>
> > >> Do you also agree?
> > >>
> > >> Thanks,
> > >> Marc
> > >>
> > >>> -----Original Message-----
> > >>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > Laszlo
> > >>> Ersek
> > >>> Sent: Friday, August 2, 2019 10:14 AM
> > >>> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>; Ni,
> > >>> Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
> > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > >>> Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >> MmControl
> > >>> definition.
> > >>>
> > >>> On 08/01/19 12:15, Marc W Chen wrote:
> > >>>> Yes, my purpose is to avoid platform code update if the package is
> > >>>> allowed
> > >>> to use MdeModulePkg like OvmfPkg.
> > >>>> For those packages that cannot depend on MdeModulePkg must
> > change
> > >> to
> > >>> use new definition.
> > >>>
> > >>> Agreed.
> > >>>
> > >>> Thanks!
> > >>> Laszlo
> > >>>
> > >>>>> -----Original Message-----
> > >>>>> From: Ni, Ray
> > >>>>> Sent: Thursday, August 1, 2019 6:04 PM
> > >>>>> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
> > >>>>> <liming.gao@intel.com>; devel@edk2.groups.io
> > >>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > >>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >>> MmControl
> > >>>>> definition.
> > >>>>>
> > >>>>> Marc,
> > >>>>> Is the purpose to avoid platform code update with the wrapper
> > >>>>> header
> > >>> file in
> > >>>>> MdeModulePkg?
> > >>>>> Certain platforms they may require to not depend on MdeModulePkg
> > >>>>> but just depend on MdePkg.
> > >>>>> Having SmmAccess.h in MdeModulePkg doesn't help.
> > >>>>>
> > >>>>> It also bring confusing.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Ray
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Chen, Marc W
> > >>>>>> Sent: Thursday, August 1, 2019 4:53 PM
> > >>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> > >>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > >>>>>> <ray.ni@intel.com>
> > >>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >>> MmControl
> > >>>>>> definition.
> > >>>>>>
> > >>>>>> Hi Liming
> > >>>>>>
> > >>>>>> Another thought, do you think it is ok to keep SmmAccess.h in
> > >>>>>> MdeModulePkg? We can use #define and typedef to convert
> > >> MmAccess
> > >>> to
> > >>>>>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Marc
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Chen, Marc W
> > >>>>>>> Sent: Thursday, August 1, 2019 4:48 PM
> > >>>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> > >>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > >>>>>>> <ray.ni@intel.com>
> > >>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >>>>>> MmControl
> > >>>>>>> definition.
> > >>>>>>>
> > >>>>>>> Hi Liming
> > >>>>>>>
> > >>>>>>> Since there are multiple packages are still using SmmAccess.h, we
> > >>>>>>> need to change all packages to use MmAccess.h instead of
> > >>>>>>> SmmAccess.h first, then clean up SmmAccess.h from
> > MdeModulePkg
> > >> will be the last step.
> > >>>>>>> Below are the packages that has "include <Ppi/SmmAccess.h>" for
> > >>>>>>> your reference.
> > >>>>>>> * Edk2 repo:
> > >>>>>>> o MdeModulePkg
> > >>>>>>> o OvmfPkg
> > >>>>>>> o UefiCpuPkg
> > >>>>>>> * Edk2Platform repo:
> > >>>>>>> o MinPlatformPkg
> > >>>>>>> o QuarkSocPkg
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> Marc
> > >>>>>>>
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: Gao, Liming
> > >>>>>>>> Sent: Thursday, August 1, 2019 4:42 PM
> > >>>>>>>> To: devel@edk2.groups.io; Chen, Marc W
> > <marc.w.chen@intel.com>
> > >>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > >>>>>>>> <ray.ni@intel.com>
> > >>>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >>>>>> MmControl
> > >>>>>>>> definition.
> > >>>>>>>>
> > >>>>>>>> Marc:
> > >>>>>>>> The change is good. Reviewed-by: Liming Gao
> > >>> <liming.gao@intel.com>
> > >>>>>>>>
> > >>>>>>>> Besides, I see BZ also mention to remove the one in
> > >> MdeModulePkg.
> > >>>>>>>> Have you the following patches for the change in MdeModulePkg?
> > >>>>>>>>
> > >>>>>>>> Thanks
> > >>>>>>>> Liming
> > >>>>>>>>> -----Original Message-----
> > >>>>>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> > >>>>> Behalf
> > >>>>>>>>> Of Marc W Chen
> > >>>>>>>>> Sent: Monday, July 29, 2019 12:26 PM
> > >>>>>>>>> To: devel@edk2.groups.io
> > >>>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao,
> > Liming
> > >>>>>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> > >>>>>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >>>>> MmControl
> > >>>>>>>>> definition.
> > >>>>>>>>>
> > >>>>>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
> > >>>>>> specification.
> > >>>>>>>>>
> > >>>>>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > >>>>>>>>> Cc: Liming Gao <liming.gao@intel.com>
> > >>>>>>>>> Cc: Ray Ni <ray.ni@intel.com>
> > >>>>>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> > >>>>>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> > >>>>>>>>> ---
> > >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
> > >>>>>>>>> +++++++++++++++++++++++++++++++++++++++++
> > >>>>>>>>> MdePkg/Include/Ppi/MmControl.h | 90
> > >>>>>> ++++++++++++++++++++++++
> > >>>>>>>>> MdePkg/MdePkg.dec | 6 ++
> > >>>>>>>>> 3 files changed, 251 insertions(+) create mode 100644
> > >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
> > >>>>>>>>> MdePkg/Include/Ppi/MmControl.h
> > >>>>>>>>>
> > >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
> > >>>>>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644
> > index
> > >>>>>>>>> 0000000000..636e7288a0
> > >>>>>>>>> --- /dev/null
> > >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
> > >>>>>>>>> @@ -0,0 +1,155 @@
> > >>>>>>>>> +/** @file
> > >>>>>>>>> + EFI MM Access PPI definition.
> > >>>>>>>>> +
> > >>>>>>>>> + This PPI is used to control the visibility of the MMRAM on
> > >>>>>>>>> + the
> > >>>>>> platform.
> > >>>>>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
> > >>>>>>>>> + characteristics
> > >>>>>>> of
> > >>>>>>>>> MMRAM. The
> > >>>>>>>>> + principal functionality found in the memory controller
> > >>>>>>>>> + includes the
> > >>>>>>>> following:
> > >>>>>>>>> + - Exposing the MMRAM to all non-MM agents, or the "open"
> > >>>>>>>>> + state
> > >>>>>>>>> + - Shrouding the MMRAM to all but the MM agents, or the
> > >> "closed"
> > >>>>>>>>> + state
> > >>>>>>>>> + - Preserving the system integrity, or "locking" the MMRAM,
> > >>>>>>>>> + such that
> > >>>>>>> the
> > >>>>>>>>> settings cannot be
> > >>>>>>>>> + perturbed by either boot service or runtime agents
> > >>>>>>>>> +
> > >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> > >>>>>>>>> + reserved.<BR>
> > >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> > >>>>>>>>> +
> > >>>>>>>>> + @par Revision Reference:
> > >>>>>>>>> + This PPI is introduced in PI Version 1.5.
> > >>>>>>>>> +
> > >>>>>>>>> +**/
> > >>>>>>>>> +
> > >>>>>>>>> +#ifndef _MM_ACCESS_PPI_H_
> > >>>>>>>>> +#define _MM_ACCESS_PPI_H_
> > >>>>>>>>> +
> > >>>>>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
> > >>>>>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
> > >>>>>>>>> +0xc3, 0x2e,
> > >>>>>>>>> 0xd6 }}
> > >>>>>>>>> +
> > >>>>>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI
> > >> EFI_PEI_MM_ACCESS_PPI;
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + Opens the MMRAM area to be accessible by a PEIM.
> > >>>>>>>>> +
> > >>>>>>>>> + This function "opens" MMRAM so that it is visible while not
> > >>>>>>>>> + inside of
> > >>>>>>> MM.
> > >>>>>>>>> The function should
> > >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not support
> > >>>>>>>>> + hiding of
> > >>>>>>>>> MMRAM. The function
> > >>>>>>>>> + should return EFI_DEVICE_ERROR if the MMRAM
> > configuration
> > >> is
> > >>>>>> locked.
> > >>>>>>>>> +
> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > Services
> > >>>>>> Table
> > >>>>>>>>> published by the PEI Foundation.
> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to Open.
> > >>>>>>>>> +
> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not support
> > >>>>> opening
> > >>>>>>>> and
> > >>>>>>>>> closing of MMRAM.
> > >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be opened,
> > >>>>> perhaps
> > >>>>>>>>> because it is locked.
> > >>>>>>>>> +
> > >>>>>>>>> +**/
> > >>>>>>>>> +typedef
> > >>>>>>>>> +EFI_STATUS
> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >>>>>>>>> + IN UINTN DescriptorIndex
> > >>>>>>>>> + );
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + Inhibits access to the MMRAM.
> > >>>>>>>>> +
> > >>>>>>>>> + This function "closes" MMRAM so that it is not visible while
> > >>>>>>>>> + outside of
> > >>>>>>>> MM.
> > >>>>>>>>> The function should
> > >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not support
> > >>>>>>>>> + hiding of
> > >>>>>>>>> MMRAM.
> > >>>>>>>>> +
> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > Services
> > >>>>>> Table
> > >>>>>>>>> published by the PEI Foundation.
> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to Close.
> > >>>>>>>>> +
> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not support
> > >>>>> opening
> > >>>>>>>> and
> > >>>>>>>>> closing of MMRAM.
> > >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> > >>>>>>>>> +
> > >>>>>>>>> +**/
> > >>>>>>>>> +typedef
> > >>>>>>>>> +EFI_STATUS
> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >>>>>>>>> + IN UINTN DescriptorIndex
> > >>>>>>>>> + );
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + This function prohibits access to the MMRAM region. This
> > >>>>>>>>> +function is
> > >>>>>>>> usually
> > >>>>>>>>> implemented such
> > >>>>>>>>> + that it is a write-once operation.
> > >>>>>>>>> +
> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > Services
> > >>>>>> Table
> > >>>>>>>>> published by the PEI Foundation.
> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to Lock.
> > >>>>>>>>> +
> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not support
> > >>>>> opening
> > >>>>>>>> and
> > >>>>>>>>> closing of MMRAM.
> > >>>>>>>>> +
> > >>>>>>>>> +**/
> > >>>>>>>>> +typedef
> > >>>>>>>>> +EFI_STATUS
> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >>>>>>>>> + IN UINTN DescriptorIndex
> > >>>>>>>>> + );
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + Queries the memory controller for the possible regions that
> > >>>>>>>>> +will support
> > >>>>>>>>> MMRAM.
> > >>>>>>>>> +
> > >>>>>>>>> + This function describes the MMRAM regions.
> > >>>>>>>>> + This data structure forms the contract between the
> > >> MM_ACCESS
> > >>>>> and
> > >>>>>>>>> MM_IPL drivers. There is an
> > >>>>>>>>> + ambiguity when any MMRAM region is remapped. For
> > example,
> > >> on
> > >>>>>>> some
> > >>>>>>>>> chipsets, some MMRAM
> > >>>>>>>>> + regions can be initialized at one physical address but is
> > >>>>>>>>> + later accessed at
> > >>>>>>>>> another processor address.
> > >>>>>>>>> + There is currently no way for the MM IPL driver to know that
> > >>>>>>>>> + it must use
> > >>>>>>>>> two different addresses
> > >>>>>>>>> + depending on what it is trying to do. As a result, initial
> > >>>>>>>>> + configuration and
> > >>>>>>>>> loading can use the
> > >>>>>>>>> + physical address PhysicalStart while MMRAM is open.
> > However,
> > >>>>>>>>> + once
> > >>>>>>> the
> > >>>>>>>>> region has been
> > >>>>>>>>> + closed and needs to be accessed by agents in MM, the
> > >>>>>>>>> + CpuStart address
> > >>>>>>>>> must be used.
> > >>>>>>>>> + This PPI publishes the available memory that the chipset can
> > >>>>>>>>> + shroud for
> > >>>>>>>> the
> > >>>>>>>>> use of installing code.
> > >>>>>>>>> + These regions serve the dual purpose of describing which
> > >>>>>>>>> + regions have
> > >>>>>>>>> been open, closed, or locked.
> > >>>>>>>>> + In addition, these regions may include overlapping memory
> > >>>>>>>>> + ranges,
> > >>>>>>>>> depending on the chipset
> > >>>>>>>>> + implementation. The latter might include a chipset that
> > >>>>>>>>> + supports T-SEG,
> > >>>>>>>>> where memory near the top
> > >>>>>>>>> + of the physical DRAM can be allocated for MMRAM too.
> > >>>>>>>>> + The key thing to note is that the regions that are described
> > >>>>>>>>> + by the PPI
> > >>>>>>> are
> > >>>>>>>> a
> > >>>>>>>>> subset of the capabilities
> > >>>>>>>>> + of the hardware.
> > >>>>>>>>> +
> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > Services
> > >>>>>> Table
> > >>>>>>>>> published by the PEI Foundation.
> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI instance.
> > >>>>>>>>> + @param MmramMapSize A pointer to the size, in bytes,
> > of
> > >>>>> the
> > >>>>>>>>> MmramMemoryMap buffer. On input, this value is
> > >>>>>>>>> + the size of the buffer that
> > >>>>>>>>> + is allocated by the caller. On
> > >>>>>>>>> output, it is the size of the
> > >>>>>>>>> + buffer that was returned by
> > >>>>>>>>> + the firmware if the buffer
> > >>>>>>>> was
> > >>>>>>>>> large enough, or, if the
> > >>>>>>>>> + buffer was too small, the
> > >>>>>>>>> + size of the buffer that is
> > >>>>>>>> needed to
> > >>>>>>>>> contain the map.
> > >>>>>>>>> + @param MmramMap A pointer to the buffer in which
> > >>>>>> firmware
> > >>>>>>>>> places the current memory map. The map is
> > >>>>>>>>> + an array of
> > >>>>>>>>> + EFI_MMRAM_DESCRIPTORs
> > >>>>>>>>> +
> > >>>>>>>>> + @retval EFI_SUCCESS The chipset supported the given
> > >>>>> resource.
> > >>>>>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap
> > parameter
> > >>> was
> > >>>>>> too
> > >>>>>>>>> small. The current
> > >>>>>>>>> + buffer size needed to hold
> > >>>>>>>>> + the memory map is
> > >>>>>>> returned
> > >>>>>>>> in
> > >>>>>>>>> + MmramMapSize.
> > >>>>>>>>> +
> > >>>>>>>>> +**/
> > >>>>>>>>> +typedef
> > >>>>>>>>> +EFI_STATUS
> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >>>>>>>>> + IN OUT UINTN *MmramMapSize,
> > >>>>>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> > >>>>>>>>> + );
> > >>>>>>>>> +
> > >>>>>>>>> +///
> > >>>>>>>>> +/// EFI MM Access PPI is used to control the visibility of
> > >>>>>>>>> +the MMRAM on
> > >>>>>>>> the
> > >>>>>>>>> platform.
> > >>>>>>>>> +/// It abstracts the location and characteristics of MMRAM.
> > >>>>>>>>> +The platform
> > >>>>>>>>> should report
> > >>>>>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The expectation
> > is
> > >>> that
> > >>>>>>>>> +the
> > >>>>>>>>> north bridge or
> > >>>>>>>>> +/// memory controller would publish this PPI.
> > >>>>>>>>> +///
> > >>>>>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
> > >>>>>>>>> + EFI_PEI_MM_OPEN Open;
> > >>>>>>>>> + EFI_PEI_MM_CLOSE Close;
> > >>>>>>>>> + EFI_PEI_MM_LOCK Lock;
> > >>>>>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
> > >>>>>>>>> + BOOLEAN LockState;
> > >>>>>>>>> + BOOLEAN OpenState;
> > >>>>>>>>> +};
> > >>>>>>>>> +
> > >>>>>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> > >>>>>>>>> +
> > >>>>>>>>> +#endif
> > >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
> > >>>>>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644
> > index
> > >>>>>>>>> 0000000000..983ed95cd5
> > >>>>>>>>> --- /dev/null
> > >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
> > >>>>>>>>> @@ -0,0 +1,90 @@
> > >>>>>>>>> +/** @file
> > >>>>>>>>> + EFI MM Control PPI definition.
> > >>>>>>>>> +
> > >>>>>>>>> + This PPI is used initiate synchronous MMI activations. This
> > >>>>>>>>> + PPI could be
> > >>>>>>>>> published by a processor
> > >>>>>>>>> + driver to abstract the MMI IPI or a driver which abstracts
> > >>>>>>>>> + the ASIC that
> > >>>>>>> is
> > >>>>>>>>> supporting the APM port.
> > >>>>>>>>> + Because of the possibility of performing MMI IPI
> > >>>>>>>>> + transactions, the ability
> > >>>>>>>> to
> > >>>>>>>>> generate this event
> > >>>>>>>>> + from a platform chipset agent is an optional capability for
> > >>>>>>>>> + both
> > >>>>>>>>> + IA-32
> > >>>>>>> and
> > >>>>>>>>> x64-based systems.
> > >>>>>>>>> +
> > >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> > >>>>>>>>> + reserved.<BR>
> > >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> > >>>>>>>>> +
> > >>>>>>>>> + @par Revision Reference:
> > >>>>>>>>> + This PPI is introduced in PI Version 1.5.
> > >>>>>>>>> +
> > >>>>>>>>> +**/
> > >>>>>>>>> +
> > >>>>>>>>> +
> > >>>>>>>>> +#ifndef _MM_CONTROL_PPI_H_
> > >>>>>>>>> +#define _MM_CONTROL_PPI_H_
> > >>>>>>>>> +
> > >>>>>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
> > >>>>>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5,
> > >>>>>>>>> +0xce, 0x74,
> > >>>>>>>> 0xc5 }
> > >>>>>>>>> +
> > >>>>>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
> > >>>>>> EFI_PEI_MM_CONTROL_PPI;
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + Invokes PPI activation from the PI PEI environment.
> > >>>>>>>>> +
> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > Services
> > >>>>> Table
> > >>>>>>>>> published by the PEI Foundation.
> > >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
> > >>>>>>>>> + @param ArgumentBuffer The value passed to the MMI
> > >>> handler.
> > >>>>>>> This
> > >>>>>>>>> value corresponds to the
> > >>>>>>>>> + SwMmiInputValue in the
> > >>>>>>>>> + RegisterContext parameter
> > >>>>>>> for
> > >>>>>>>> the
> > >>>>>>>>> Register()
> > >>>>>>>>> + function in the
> > >>>>>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
> > >>>>>>> and
> > >>>>>>>> in
> > >>>>>>>>> the Context parameter
> > >>>>>>>>> + in the call to the DispatchFunction
> > >>>>>>>>> + @param ArgumentBufferSize The size of the data passed in
> > >>>>>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> > >>>>>>>>> + @param Periodic An optional mechanism to periodically
> > >>>>> repeat
> > >>>>>>>>> activation.
> > >>>>>>>>> + @param ActivationInterval An optional parameter to repeat
> > at
> > >>>>> this
> > >>>>>>>> period
> > >>>>>>>>> one
> > >>>>>>>>> + time or, if the Periodic Boolean is set,
> > periodically.
> > >>>>>>>>> +
> > >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> > >>>>>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
> > >>>>>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
> > >>>>>> unsupported.
> > >>>>>>>>> + @retval EFI_NOT_STARTED The MM base service has not
> > >> been
> > >>>>>>>> initialized.
> > >>>>>>>>> +
> > >>>>>>>>> +**/
> > >>>>>>>>> +typedef
> > >>>>>>>>> +EFI_STATUS
> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> > >>>>>>>>> + IN OUT INT8 *ArgumentBuffer OPTIONAL,
> > >>>>>>>>> + IN OUT UINTN *ArgumentBufferSize
> > >>> OPTIONAL,
> > >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL,
> > >>>>>>>>> + IN UINTN ActivationInterval OPTIONAL
> > >>>>>>>>> + );
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + Clears any system state that was created in response to the
> > >>> Trigger()
> > >>>>>> call.
> > >>>>>>>>> +
> > >>>>>>>>> + @param PeiServices General purpose services available
> > to
> > >>>>> every
> > >>>>>>>> PEIM.
> > >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
> > >>>>>>>>> + @param Periodic Optional parameter to repeat at this
> > >>>>> period
> > >>>>>>> one
> > >>>>>>>>> + time or, if the Periodic Boolean is set,
> > periodically.
> > >>>>>>>>> +
> > >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> > >>>>>>>>> + @retval EFI_DEVICE_ERROR The source could not be
> > cleared.
> > >>>>>>>>> + @retval EFI_INVALID_PARAMETER The service did not support
> > >>>>>>>>> + the
> > >>>>>>>> Periodic
> > >>>>>>>>> input argument.
> > >>>>>>>>> +
> > >>>>>>>>> +**/
> > >>>>>>>>> +typedef
> > >>>>>>>>> +EFI_STATUS
> > >>>>>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> > >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL
> > >>>>>>>>> + );
> > >>>>>>>>> +
> > >>>>>>>>> +///
> > >>>>>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM. It
> > >>>>>> provides
> > >>>>>>> an
> > >>>>>>>>> abstraction of the
> > >>>>>>>>> +/// platform hardware that generates an MMI. There are often
> > >>>>>>>>> +I/O ports
> > >>>>>>>>> that, when accessed, will
> > >>>>>>>>> +/// generate the MMI. Also, the hardware optionally supports
> > >>>>>>>>> +the
> > >>>>>>> periodic
> > >>>>>>>>> generation of these signals.
> > >>>>>>>>> +///
> > >>>>>>>>> +struct _PEI_MM_CONTROL_PPI {
> > >>>>>>>>> + PEI_MM_ACTIVATE Trigger;
> > >>>>>>>>> + PEI_MM_DEACTIVATE Clear;
> > >>>>>>>>> +};
> > >>>>>>>>> +
> > >>>>>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
> > >>>>>>>>> +
> > >>>>>>>>> +#endif
> > >>>>>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
> > >>>>>>>>> b382efd578..34e0f39395 100644
> > >>>>>>>>> --- a/MdePkg/MdePkg.dec
> > >>>>>>>>> +++ b/MdePkg/MdePkg.dec
> > >>>>>>>>> @@ -925,6 +925,12 @@
> > >>>>>>>>> ## Include/Ppi/SecHobData.h
> > >>>>>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4,
> > >>>>>>>>> 0xee,
> > >>>>>>> 0xf5,
> > >>>>>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> > >>>>>>>>>
> > >>>>>>>>> + ## Include/Ppi/MmAccess.h
> > >>>>>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd, 0x48be,
> > >>>>> { 0x88,
> > >>>>>>>> 0x17,
> > >>>>>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> > >>>>>>>>> +
> > >>>>>>>>> + ## Include/Ppi/MmControl.h
> > >>>>>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43,
> > >>>>> { 0x8d,
> > >>>>>>>> 0xef,
> > >>>>>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> > >>>>>>>>> +
> > >>>>>>>>> #
> > >>>>>>>>> # PPIs defined in PI 1.7.
> > >>>>>>>>> #
> > >>>>>>>>> --
> > >>>>>>>>> 2.16.2.windows.1
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >
> >
> >
> >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
[not found] ` <15B9725390DC0000.29320@groups.io>
@ 2019-08-13 9:19 ` Liming Gao
2019-08-14 9:53 ` Marc W Chen
0 siblings, 1 reply; 18+ messages in thread
From: Liming Gao @ 2019-08-13 9:19 UTC (permalink / raw)
To: devel@edk2.groups.io, Gao, Liming, Chen, Marc W,
lersek@redhat.com, Ni, Ray
Cc: Kinney, Michael D
Push @6f33f7a262314af35e2b99c849e08928ea49aa55
>-----Original Message-----
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Liming Gao
>Sent: Saturday, August 10, 2019 11:34 AM
>To: Chen, Marc W <marc.w.chen@intel.com>; devel@edk2.groups.io;
>lersek@redhat.com; Ni, Ray <ray.ni@intel.com>
>Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
>definition.
>
>I agree. The patch to add them in MdePkg is clear. I will push it next Monday.
>
>Thanks
>Liming
>> -----Original Message-----
>> From: Chen, Marc W
>> Sent: Saturday, August 10, 2019 11:33 AM
>> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray <ray.ni@intel.com>;
>Gao, Liming <liming.gao@intel.com>
>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
>definition.
>>
>> Hi Liming
>>
>> Since the SmmAccess.h of MdeModulePkg removal is still under discussion,
>can we push the MmAccess.h and MmControl.h to MdePkg
>> first? I have other tasks pending by this.
>> We can keep discussing the SmmAccess after push the code.
>>
>> Thanks,
>> Marc
>>
>> > -----Original Message-----
>> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
>> > Ersek
>> > Sent: Thursday, August 8, 2019 12:11 AM
>> > To: Ni, Ray <ray.ni@intel.com>; Chen, Marc W <marc.w.chen@intel.com>;
>> > devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
>> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>> > Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>MmControl
>> > definition.
>> >
>> > On 08/06/19 12:08, Ni, Ray wrote:
>> > > Laszlo,
>> > > Do you want to avoid touching the OvmfPkg due the file removal in
>> > MdeModulePkg?
>> >
>> > My main problem with this *specific* update proposal is that the
>> > identifiers (type names and such) that would be subject to removal were
>> > publicly specified in earlier PI spec releases.
>> >
>> > I don't suggest that we maintain two parallel sets of typedefs and such
>> > in edk2. It's fine to keep the new "MM" nomenclature the main one. But
>> > we should keep the "SMM" set of terms too, as a thin wrapper, if that's
>> > technically feasible.
>> >
>> > If we remove "SMM", that will not only affect OvmfPkg unpleasantly, but
>> > a bunch of other, out-of-tree code. And the reason I suddenly care about
>> > out-of-tree code is that such code was written against a public industry
>> > spec (= earlier versions of the PI spec).
>> >
>> > I don't think that the simplicity that would come from removing "SMM"
>> > altogether, is well-balanced against the pain that it would cause for
>> > platforms.
>> >
>> > Earlier this was solved in the following commits:
>> > - 07c6a47e70ba ("MdePkg: Add new definitions for Management Mode.",
>> > 2017-08-29)
>> > - 2f208e59e4b9 ("MdePkg: Reference new definitions for Management
>> > Mode.", 2017-08-29)
>> >
>> > Thanks
>> > Laszlo
>> >
>> > > I prefer to remove the files in MdeModulePkg to avoid future confusion.
>> > >
>> > > Thanks,
>> > > Ray
>> > >
>> > >> -----Original Message-----
>> > >> From: Chen, Marc W
>> > >> Sent: Tuesday, August 6, 2019 4:57 PM
>> > >> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray
>> > <ray.ni@intel.com>;
>> > >> Gao, Liming <liming.gao@intel.com>
>> > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>> > >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > MmControl
>> > >> definition.
>> > >>
>> > >> Hi Liming and Ray
>> > >>
>> > >> Do you also agree?
>> > >>
>> > >> Thanks,
>> > >> Marc
>> > >>
>> > >>> -----Original Message-----
>> > >>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
>> > Laszlo
>> > >>> Ersek
>> > >>> Sent: Friday, August 2, 2019 10:14 AM
>> > >>> To: devel@edk2.groups.io; Chen, Marc W <marc.w.chen@intel.com>;
>Ni,
>> > >>> Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
>> > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>> > >>> Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > >> MmControl
>> > >>> definition.
>> > >>>
>> > >>> On 08/01/19 12:15, Marc W Chen wrote:
>> > >>>> Yes, my purpose is to avoid platform code update if the package is
>> > >>>> allowed
>> > >>> to use MdeModulePkg like OvmfPkg.
>> > >>>> For those packages that cannot depend on MdeModulePkg must
>> > change
>> > >> to
>> > >>> use new definition.
>> > >>>
>> > >>> Agreed.
>> > >>>
>> > >>> Thanks!
>> > >>> Laszlo
>> > >>>
>> > >>>>> -----Original Message-----
>> > >>>>> From: Ni, Ray
>> > >>>>> Sent: Thursday, August 1, 2019 6:04 PM
>> > >>>>> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
>> > >>>>> <liming.gao@intel.com>; devel@edk2.groups.io
>> > >>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
>> > >>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > >>> MmControl
>> > >>>>> definition.
>> > >>>>>
>> > >>>>> Marc,
>> > >>>>> Is the purpose to avoid platform code update with the wrapper
>> > >>>>> header
>> > >>> file in
>> > >>>>> MdeModulePkg?
>> > >>>>> Certain platforms they may require to not depend on
>MdeModulePkg
>> > >>>>> but just depend on MdePkg.
>> > >>>>> Having SmmAccess.h in MdeModulePkg doesn't help.
>> > >>>>>
>> > >>>>> It also bring confusing.
>> > >>>>>
>> > >>>>> Thanks,
>> > >>>>> Ray
>> > >>>>>
>> > >>>>>> -----Original Message-----
>> > >>>>>> From: Chen, Marc W
>> > >>>>>> Sent: Thursday, August 1, 2019 4:53 PM
>> > >>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
>> > >>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>> > >>>>>> <ray.ni@intel.com>
>> > >>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > >>> MmControl
>> > >>>>>> definition.
>> > >>>>>>
>> > >>>>>> Hi Liming
>> > >>>>>>
>> > >>>>>> Another thought, do you think it is ok to keep SmmAccess.h in
>> > >>>>>> MdeModulePkg? We can use #define and typedef to convert
>> > >> MmAccess
>> > >>> to
>> > >>>>>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
>> > >>>>>>
>> > >>>>>> Thanks,
>> > >>>>>> Marc
>> > >>>>>>
>> > >>>>>>> -----Original Message-----
>> > >>>>>>> From: Chen, Marc W
>> > >>>>>>> Sent: Thursday, August 1, 2019 4:48 PM
>> > >>>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
>> > >>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>> > >>>>>>> <ray.ni@intel.com>
>> > >>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > >>>>>> MmControl
>> > >>>>>>> definition.
>> > >>>>>>>
>> > >>>>>>> Hi Liming
>> > >>>>>>>
>> > >>>>>>> Since there are multiple packages are still using SmmAccess.h,
>we
>> > >>>>>>> need to change all packages to use MmAccess.h instead of
>> > >>>>>>> SmmAccess.h first, then clean up SmmAccess.h from
>> > MdeModulePkg
>> > >> will be the last step.
>> > >>>>>>> Below are the packages that has "include <Ppi/SmmAccess.h>"
>for
>> > >>>>>>> your reference.
>> > >>>>>>> * Edk2 repo:
>> > >>>>>>> o MdeModulePkg
>> > >>>>>>> o OvmfPkg
>> > >>>>>>> o UefiCpuPkg
>> > >>>>>>> * Edk2Platform repo:
>> > >>>>>>> o MinPlatformPkg
>> > >>>>>>> o QuarkSocPkg
>> > >>>>>>>
>> > >>>>>>> Thanks,
>> > >>>>>>> Marc
>> > >>>>>>>
>> > >>>>>>>> -----Original Message-----
>> > >>>>>>>> From: Gao, Liming
>> > >>>>>>>> Sent: Thursday, August 1, 2019 4:42 PM
>> > >>>>>>>> To: devel@edk2.groups.io; Chen, Marc W
>> > <marc.w.chen@intel.com>
>> > >>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>> > >>>>>>>> <ray.ni@intel.com>
>> > >>>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess
>and
>> > >>>>>> MmControl
>> > >>>>>>>> definition.
>> > >>>>>>>>
>> > >>>>>>>> Marc:
>> > >>>>>>>> The change is good. Reviewed-by: Liming Gao
>> > >>> <liming.gao@intel.com>
>> > >>>>>>>>
>> > >>>>>>>> Besides, I see BZ also mention to remove the one in
>> > >> MdeModulePkg.
>> > >>>>>>>> Have you the following patches for the change in
>MdeModulePkg?
>> > >>>>>>>>
>> > >>>>>>>> Thanks
>> > >>>>>>>> Liming
>> > >>>>>>>>> -----Original Message-----
>> > >>>>>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
>On
>> > >>>>> Behalf
>> > >>>>>>>>> Of Marc W Chen
>> > >>>>>>>>> Sent: Monday, July 29, 2019 12:26 PM
>> > >>>>>>>>> To: devel@edk2.groups.io
>> > >>>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao,
>> > Liming
>> > >>>>>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
>> > >>>>>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
>> > >>>>> MmControl
>> > >>>>>>>>> definition.
>> > >>>>>>>>>
>> > >>>>>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
>> > >>>>>> specification.
>> > >>>>>>>>>
>> > >>>>>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>> > >>>>>>>>> Cc: Liming Gao <liming.gao@intel.com>
>> > >>>>>>>>> Cc: Ray Ni <ray.ni@intel.com>
>> > >>>>>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
>> > >>>>>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
>> > >>>>>>>>> ---
>> > >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
>> > >>>>>>>>> +++++++++++++++++++++++++++++++++++++++++
>> > >>>>>>>>> MdePkg/Include/Ppi/MmControl.h | 90
>> > >>>>>> ++++++++++++++++++++++++
>> > >>>>>>>>> MdePkg/MdePkg.dec | 6 ++
>> > >>>>>>>>> 3 files changed, 251 insertions(+) create mode 100644
>> > >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
>> > >>>>>>>>> MdePkg/Include/Ppi/MmControl.h
>> > >>>>>>>>>
>> > >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
>> > >>>>>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644
>> > index
>> > >>>>>>>>> 0000000000..636e7288a0
>> > >>>>>>>>> --- /dev/null
>> > >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
>> > >>>>>>>>> @@ -0,0 +1,155 @@
>> > >>>>>>>>> +/** @file
>> > >>>>>>>>> + EFI MM Access PPI definition.
>> > >>>>>>>>> +
>> > >>>>>>>>> + This PPI is used to control the visibility of the MMRAM on
>> > >>>>>>>>> + the
>> > >>>>>> platform.
>> > >>>>>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
>> > >>>>>>>>> + characteristics
>> > >>>>>>> of
>> > >>>>>>>>> MMRAM. The
>> > >>>>>>>>> + principal functionality found in the memory controller
>> > >>>>>>>>> + includes the
>> > >>>>>>>> following:
>> > >>>>>>>>> + - Exposing the MMRAM to all non-MM agents, or the
>"open"
>> > >>>>>>>>> + state
>> > >>>>>>>>> + - Shrouding the MMRAM to all but the MM agents, or the
>> > >> "closed"
>> > >>>>>>>>> + state
>> > >>>>>>>>> + - Preserving the system integrity, or "locking" the MMRAM,
>> > >>>>>>>>> + such that
>> > >>>>>>> the
>> > >>>>>>>>> settings cannot be
>> > >>>>>>>>> + perturbed by either boot service or runtime agents
>> > >>>>>>>>> +
>> > >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
>> > >>>>>>>>> + reserved.<BR>
>> > >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>> > >>>>>>>>> +
>> > >>>>>>>>> + @par Revision Reference:
>> > >>>>>>>>> + This PPI is introduced in PI Version 1.5.
>> > >>>>>>>>> +
>> > >>>>>>>>> +**/
>> > >>>>>>>>> +
>> > >>>>>>>>> +#ifndef _MM_ACCESS_PPI_H_
>> > >>>>>>>>> +#define _MM_ACCESS_PPI_H_
>> > >>>>>>>>> +
>> > >>>>>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
>> > >>>>>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
>> > >>>>>>>>> +0xc3, 0x2e,
>> > >>>>>>>>> 0xd6 }}
>> > >>>>>>>>> +
>> > >>>>>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI
>> > >> EFI_PEI_MM_ACCESS_PPI;
>> > >>>>>>>>> +
>> > >>>>>>>>> +/**
>> > >>>>>>>>> + Opens the MMRAM area to be accessible by a PEIM.
>> > >>>>>>>>> +
>> > >>>>>>>>> + This function "opens" MMRAM so that it is visible while not
>> > >>>>>>>>> + inside of
>> > >>>>>>> MM.
>> > >>>>>>>>> The function should
>> > >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not
>support
>> > >>>>>>>>> + hiding of
>> > >>>>>>>>> MMRAM. The function
>> > >>>>>>>>> + should return EFI_DEVICE_ERROR if the MMRAM
>> > configuration
>> > >> is
>> > >>>>>> locked.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
>> > Services
>> > >>>>>> Table
>> > >>>>>>>>> published by the PEI Foundation.
>> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
>instance.
>> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
>Open.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
>> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
>support
>> > >>>>> opening
>> > >>>>>>>> and
>> > >>>>>>>>> closing of MMRAM.
>> > >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be opened,
>> > >>>>> perhaps
>> > >>>>>>>>> because it is locked.
>> > >>>>>>>>> +
>> > >>>>>>>>> +**/
>> > >>>>>>>>> +typedef
>> > >>>>>>>>> +EFI_STATUS
>> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
>> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>> > >>>>>>>>> + IN UINTN DescriptorIndex
>> > >>>>>>>>> + );
>> > >>>>>>>>> +
>> > >>>>>>>>> +/**
>> > >>>>>>>>> + Inhibits access to the MMRAM.
>> > >>>>>>>>> +
>> > >>>>>>>>> + This function "closes" MMRAM so that it is not visible while
>> > >>>>>>>>> + outside of
>> > >>>>>>>> MM.
>> > >>>>>>>>> The function should
>> > >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not
>support
>> > >>>>>>>>> + hiding of
>> > >>>>>>>>> MMRAM.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
>> > Services
>> > >>>>>> Table
>> > >>>>>>>>> published by the PEI Foundation.
>> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
>instance.
>> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
>Close.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
>> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
>support
>> > >>>>> opening
>> > >>>>>>>> and
>> > >>>>>>>>> closing of MMRAM.
>> > >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
>> > >>>>>>>>> +
>> > >>>>>>>>> +**/
>> > >>>>>>>>> +typedef
>> > >>>>>>>>> +EFI_STATUS
>> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
>> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>> > >>>>>>>>> + IN UINTN DescriptorIndex
>> > >>>>>>>>> + );
>> > >>>>>>>>> +
>> > >>>>>>>>> +/**
>> > >>>>>>>>> + This function prohibits access to the MMRAM region. This
>> > >>>>>>>>> +function is
>> > >>>>>>>> usually
>> > >>>>>>>>> implemented such
>> > >>>>>>>>> + that it is a write-once operation.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
>> > Services
>> > >>>>>> Table
>> > >>>>>>>>> published by the PEI Foundation.
>> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
>instance.
>> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
>Lock.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
>> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
>support
>> > >>>>> opening
>> > >>>>>>>> and
>> > >>>>>>>>> closing of MMRAM.
>> > >>>>>>>>> +
>> > >>>>>>>>> +**/
>> > >>>>>>>>> +typedef
>> > >>>>>>>>> +EFI_STATUS
>> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
>> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>> > >>>>>>>>> + IN UINTN DescriptorIndex
>> > >>>>>>>>> + );
>> > >>>>>>>>> +
>> > >>>>>>>>> +/**
>> > >>>>>>>>> + Queries the memory controller for the possible regions that
>> > >>>>>>>>> +will support
>> > >>>>>>>>> MMRAM.
>> > >>>>>>>>> +
>> > >>>>>>>>> + This function describes the MMRAM regions.
>> > >>>>>>>>> + This data structure forms the contract between the
>> > >> MM_ACCESS
>> > >>>>> and
>> > >>>>>>>>> MM_IPL drivers. There is an
>> > >>>>>>>>> + ambiguity when any MMRAM region is remapped. For
>> > example,
>> > >> on
>> > >>>>>>> some
>> > >>>>>>>>> chipsets, some MMRAM
>> > >>>>>>>>> + regions can be initialized at one physical address but is
>> > >>>>>>>>> + later accessed at
>> > >>>>>>>>> another processor address.
>> > >>>>>>>>> + There is currently no way for the MM IPL driver to know
>that
>> > >>>>>>>>> + it must use
>> > >>>>>>>>> two different addresses
>> > >>>>>>>>> + depending on what it is trying to do. As a result, initial
>> > >>>>>>>>> + configuration and
>> > >>>>>>>>> loading can use the
>> > >>>>>>>>> + physical address PhysicalStart while MMRAM is open.
>> > However,
>> > >>>>>>>>> + once
>> > >>>>>>> the
>> > >>>>>>>>> region has been
>> > >>>>>>>>> + closed and needs to be accessed by agents in MM, the
>> > >>>>>>>>> + CpuStart address
>> > >>>>>>>>> must be used.
>> > >>>>>>>>> + This PPI publishes the available memory that the chipset
>can
>> > >>>>>>>>> + shroud for
>> > >>>>>>>> the
>> > >>>>>>>>> use of installing code.
>> > >>>>>>>>> + These regions serve the dual purpose of describing which
>> > >>>>>>>>> + regions have
>> > >>>>>>>>> been open, closed, or locked.
>> > >>>>>>>>> + In addition, these regions may include overlapping memory
>> > >>>>>>>>> + ranges,
>> > >>>>>>>>> depending on the chipset
>> > >>>>>>>>> + implementation. The latter might include a chipset that
>> > >>>>>>>>> + supports T-SEG,
>> > >>>>>>>>> where memory near the top
>> > >>>>>>>>> + of the physical DRAM can be allocated for MMRAM too.
>> > >>>>>>>>> + The key thing to note is that the regions that are described
>> > >>>>>>>>> + by the PPI
>> > >>>>>>> are
>> > >>>>>>>> a
>> > >>>>>>>>> subset of the capabilities
>> > >>>>>>>>> + of the hardware.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
>> > Services
>> > >>>>>> Table
>> > >>>>>>>>> published by the PEI Foundation.
>> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
>instance.
>> > >>>>>>>>> + @param MmramMapSize A pointer to the size, in
>bytes,
>> > of
>> > >>>>> the
>> > >>>>>>>>> MmramMemoryMap buffer. On input, this value is
>> > >>>>>>>>> + the size of the buffer that
>> > >>>>>>>>> + is allocated by the caller. On
>> > >>>>>>>>> output, it is the size of the
>> > >>>>>>>>> + buffer that was returned by
>> > >>>>>>>>> + the firmware if the buffer
>> > >>>>>>>> was
>> > >>>>>>>>> large enough, or, if the
>> > >>>>>>>>> + buffer was too small, the
>> > >>>>>>>>> + size of the buffer that is
>> > >>>>>>>> needed to
>> > >>>>>>>>> contain the map.
>> > >>>>>>>>> + @param MmramMap A pointer to the buffer in
>which
>> > >>>>>> firmware
>> > >>>>>>>>> places the current memory map. The map is
>> > >>>>>>>>> + an array of
>> > >>>>>>>>> + EFI_MMRAM_DESCRIPTORs
>> > >>>>>>>>> +
>> > >>>>>>>>> + @retval EFI_SUCCESS The chipset supported the given
>> > >>>>> resource.
>> > >>>>>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap
>> > parameter
>> > >>> was
>> > >>>>>> too
>> > >>>>>>>>> small. The current
>> > >>>>>>>>> + buffer size needed to hold
>> > >>>>>>>>> + the memory map is
>> > >>>>>>> returned
>> > >>>>>>>> in
>> > >>>>>>>>> + MmramMapSize.
>> > >>>>>>>>> +
>> > >>>>>>>>> +**/
>> > >>>>>>>>> +typedef
>> > >>>>>>>>> +EFI_STATUS
>> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
>> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
>> > >>>>>>>>> + IN OUT UINTN *MmramMapSize,
>> > >>>>>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
>> > >>>>>>>>> + );
>> > >>>>>>>>> +
>> > >>>>>>>>> +///
>> > >>>>>>>>> +/// EFI MM Access PPI is used to control the visibility of
>> > >>>>>>>>> +the MMRAM on
>> > >>>>>>>> the
>> > >>>>>>>>> platform.
>> > >>>>>>>>> +/// It abstracts the location and characteristics of MMRAM.
>> > >>>>>>>>> +The platform
>> > >>>>>>>>> should report
>> > >>>>>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The
>expectation
>> > is
>> > >>> that
>> > >>>>>>>>> +the
>> > >>>>>>>>> north bridge or
>> > >>>>>>>>> +/// memory controller would publish this PPI.
>> > >>>>>>>>> +///
>> > >>>>>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
>> > >>>>>>>>> + EFI_PEI_MM_OPEN Open;
>> > >>>>>>>>> + EFI_PEI_MM_CLOSE Close;
>> > >>>>>>>>> + EFI_PEI_MM_LOCK Lock;
>> > >>>>>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
>> > >>>>>>>>> + BOOLEAN LockState;
>> > >>>>>>>>> + BOOLEAN OpenState;
>> > >>>>>>>>> +};
>> > >>>>>>>>> +
>> > >>>>>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
>> > >>>>>>>>> +
>> > >>>>>>>>> +#endif
>> > >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
>> > >>>>>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644
>> > index
>> > >>>>>>>>> 0000000000..983ed95cd5
>> > >>>>>>>>> --- /dev/null
>> > >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
>> > >>>>>>>>> @@ -0,0 +1,90 @@
>> > >>>>>>>>> +/** @file
>> > >>>>>>>>> + EFI MM Control PPI definition.
>> > >>>>>>>>> +
>> > >>>>>>>>> + This PPI is used initiate synchronous MMI activations. This
>> > >>>>>>>>> + PPI could be
>> > >>>>>>>>> published by a processor
>> > >>>>>>>>> + driver to abstract the MMI IPI or a driver which abstracts
>> > >>>>>>>>> + the ASIC that
>> > >>>>>>> is
>> > >>>>>>>>> supporting the APM port.
>> > >>>>>>>>> + Because of the possibility of performing MMI IPI
>> > >>>>>>>>> + transactions, the ability
>> > >>>>>>>> to
>> > >>>>>>>>> generate this event
>> > >>>>>>>>> + from a platform chipset agent is an optional capability for
>> > >>>>>>>>> + both
>> > >>>>>>>>> + IA-32
>> > >>>>>>> and
>> > >>>>>>>>> x64-based systems.
>> > >>>>>>>>> +
>> > >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
>> > >>>>>>>>> + reserved.<BR>
>> > >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>> > >>>>>>>>> +
>> > >>>>>>>>> + @par Revision Reference:
>> > >>>>>>>>> + This PPI is introduced in PI Version 1.5.
>> > >>>>>>>>> +
>> > >>>>>>>>> +**/
>> > >>>>>>>>> +
>> > >>>>>>>>> +
>> > >>>>>>>>> +#ifndef _MM_CONTROL_PPI_H_
>> > >>>>>>>>> +#define _MM_CONTROL_PPI_H_
>> > >>>>>>>>> +
>> > >>>>>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
>> > >>>>>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5,
>> > >>>>>>>>> +0xce, 0x74,
>> > >>>>>>>> 0xc5 }
>> > >>>>>>>>> +
>> > >>>>>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
>> > >>>>>> EFI_PEI_MM_CONTROL_PPI;
>> > >>>>>>>>> +
>> > >>>>>>>>> +/**
>> > >>>>>>>>> + Invokes PPI activation from the PI PEI environment.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
>> > Services
>> > >>>>> Table
>> > >>>>>>>>> published by the PEI Foundation.
>> > >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
>> > >>>>>>>>> + @param ArgumentBuffer The value passed to the MMI
>> > >>> handler.
>> > >>>>>>> This
>> > >>>>>>>>> value corresponds to the
>> > >>>>>>>>> + SwMmiInputValue in the
>> > >>>>>>>>> + RegisterContext parameter
>> > >>>>>>> for
>> > >>>>>>>> the
>> > >>>>>>>>> Register()
>> > >>>>>>>>> + function in the
>> > >>>>>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
>> > >>>>>>> and
>> > >>>>>>>> in
>> > >>>>>>>>> the Context parameter
>> > >>>>>>>>> + in the call to the DispatchFunction
>> > >>>>>>>>> + @param ArgumentBufferSize The size of the data passed
>in
>> > >>>>>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
>> > >>>>>>>>> + @param Periodic An optional mechanism to
>periodically
>> > >>>>> repeat
>> > >>>>>>>>> activation.
>> > >>>>>>>>> + @param ActivationInterval An optional parameter to
>repeat
>> > at
>> > >>>>> this
>> > >>>>>>>> period
>> > >>>>>>>>> one
>> > >>>>>>>>> + time or, if the Periodic Boolean is set,
>> > periodically.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
>> > >>>>>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
>> > >>>>>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
>> > >>>>>> unsupported.
>> > >>>>>>>>> + @retval EFI_NOT_STARTED The MM base service has not
>> > >> been
>> > >>>>>>>> initialized.
>> > >>>>>>>>> +
>> > >>>>>>>>> +**/
>> > >>>>>>>>> +typedef
>> > >>>>>>>>> +EFI_STATUS
>> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
>> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
>> > >>>>>>>>> + IN OUT INT8 *ArgumentBuffer
>OPTIONAL,
>> > >>>>>>>>> + IN OUT UINTN *ArgumentBufferSize
>> > >>> OPTIONAL,
>> > >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL,
>> > >>>>>>>>> + IN UINTN ActivationInterval OPTIONAL
>> > >>>>>>>>> + );
>> > >>>>>>>>> +
>> > >>>>>>>>> +/**
>> > >>>>>>>>> + Clears any system state that was created in response to the
>> > >>> Trigger()
>> > >>>>>> call.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @param PeiServices General purpose services
>available
>> > to
>> > >>>>> every
>> > >>>>>>>> PEIM.
>> > >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI instance.
>> > >>>>>>>>> + @param Periodic Optional parameter to repeat at
>this
>> > >>>>> period
>> > >>>>>>> one
>> > >>>>>>>>> + time or, if the Periodic Boolean is set,
>> > periodically.
>> > >>>>>>>>> +
>> > >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
>> > >>>>>>>>> + @retval EFI_DEVICE_ERROR The source could not be
>> > cleared.
>> > >>>>>>>>> + @retval EFI_INVALID_PARAMETER The service did not
>support
>> > >>>>>>>>> + the
>> > >>>>>>>> Periodic
>> > >>>>>>>>> input argument.
>> > >>>>>>>>> +
>> > >>>>>>>>> +**/
>> > >>>>>>>>> +typedef
>> > >>>>>>>>> +EFI_STATUS
>> > >>>>>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
>> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
>> > >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
>> > >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL
>> > >>>>>>>>> + );
>> > >>>>>>>>> +
>> > >>>>>>>>> +///
>> > >>>>>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM.
>It
>> > >>>>>> provides
>> > >>>>>>> an
>> > >>>>>>>>> abstraction of the
>> > >>>>>>>>> +/// platform hardware that generates an MMI. There are
>often
>> > >>>>>>>>> +I/O ports
>> > >>>>>>>>> that, when accessed, will
>> > >>>>>>>>> +/// generate the MMI. Also, the hardware optionally
>supports
>> > >>>>>>>>> +the
>> > >>>>>>> periodic
>> > >>>>>>>>> generation of these signals.
>> > >>>>>>>>> +///
>> > >>>>>>>>> +struct _PEI_MM_CONTROL_PPI {
>> > >>>>>>>>> + PEI_MM_ACTIVATE Trigger;
>> > >>>>>>>>> + PEI_MM_DEACTIVATE Clear;
>> > >>>>>>>>> +};
>> > >>>>>>>>> +
>> > >>>>>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
>> > >>>>>>>>> +
>> > >>>>>>>>> +#endif
>> > >>>>>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
>index
>> > >>>>>>>>> b382efd578..34e0f39395 100644
>> > >>>>>>>>> --- a/MdePkg/MdePkg.dec
>> > >>>>>>>>> +++ b/MdePkg/MdePkg.dec
>> > >>>>>>>>> @@ -925,6 +925,12 @@
>> > >>>>>>>>> ## Include/Ppi/SecHobData.h
>> > >>>>>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8,
>{0xb4,
>> > >>>>>>>>> 0xee,
>> > >>>>>>> 0xf5,
>> > >>>>>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
>> > >>>>>>>>>
>> > >>>>>>>>> + ## Include/Ppi/MmAccess.h
>> > >>>>>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd,
>0x48be,
>> > >>>>> { 0x88,
>> > >>>>>>>> 0x17,
>> > >>>>>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
>> > >>>>>>>>> +
>> > >>>>>>>>> + ## Include/Ppi/MmControl.h
>> > >>>>>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e,
>0x4f43,
>> > >>>>> { 0x8d,
>> > >>>>>>>> 0xef,
>> > >>>>>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
>> > >>>>>>>>> +
>> > >>>>>>>>> #
>> > >>>>>>>>> # PPIs defined in PI 1.7.
>> > >>>>>>>>> #
>> > >>>>>>>>> --
>> > >>>>>>>>> 2.16.2.windows.1
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>
>> > >>>
>> > >>>
>> > >
>> >
>> >
>> >
>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-13 9:19 ` Liming Gao
@ 2019-08-14 9:53 ` Marc W Chen
2019-08-18 5:20 ` Ni, Ray
2019-08-18 5:21 ` Ni, Ray
0 siblings, 2 replies; 18+ messages in thread
From: Marc W Chen @ 2019-08-14 9:53 UTC (permalink / raw)
To: Gao, Liming, devel@edk2.groups.io, lersek@redhat.com, Ni, Ray
Cc: Kinney, Michael D
Thanks Liming for pushing the code.
Can we have a conclusion for the SmmAccess.h removal from MdeModulePkg? Who can make the decision? Or do we need any further discussion?
Thanks,
Marc
> -----Original Message-----
> From: Gao, Liming
> Sent: Tuesday, August 13, 2019 5:20 PM
> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Chen, Marc
> W <marc.w.chen@intel.com>; lersek@redhat.com; Ni, Ray
> <ray.ni@intel.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> definition.
>
> Push @6f33f7a262314af35e2b99c849e08928ea49aa55
>
> >-----Original Message-----
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >Liming Gao
> >Sent: Saturday, August 10, 2019 11:34 AM
> >To: Chen, Marc W <marc.w.chen@intel.com>; devel@edk2.groups.io;
> >lersek@redhat.com; Ni, Ray <ray.ni@intel.com>
> >Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> >Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> >definition.
> >
> >I agree. The patch to add them in MdePkg is clear. I will push it next Monday.
> >
> >Thanks
> >Liming
> >> -----Original Message-----
> >> From: Chen, Marc W
> >> Sent: Saturday, August 10, 2019 11:33 AM
> >> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray
> <ray.ni@intel.com>;
> >Gao, Liming <liming.gao@intel.com>
> >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> MmControl
> >definition.
> >>
> >> Hi Liming
> >>
> >> Since the SmmAccess.h of MdeModulePkg removal is still under discussion,
> >can we push the MmAccess.h and MmControl.h to MdePkg
> >> first? I have other tasks pending by this.
> >> We can keep discussing the SmmAccess after push the code.
> >>
> >> Thanks,
> >> Marc
> >>
> >> > -----Original Message-----
> >> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> Laszlo
> >> > Ersek
> >> > Sent: Thursday, August 8, 2019 12:11 AM
> >> > To: Ni, Ray <ray.ni@intel.com>; Chen, Marc W
> <marc.w.chen@intel.com>;
> >> > devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> >> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> >> > Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >MmControl
> >> > definition.
> >> >
> >> > On 08/06/19 12:08, Ni, Ray wrote:
> >> > > Laszlo,
> >> > > Do you want to avoid touching the OvmfPkg due the file removal in
> >> > MdeModulePkg?
> >> >
> >> > My main problem with this *specific* update proposal is that the
> >> > identifiers (type names and such) that would be subject to removal were
> >> > publicly specified in earlier PI spec releases.
> >> >
> >> > I don't suggest that we maintain two parallel sets of typedefs and such
> >> > in edk2. It's fine to keep the new "MM" nomenclature the main one. But
> >> > we should keep the "SMM" set of terms too, as a thin wrapper, if that's
> >> > technically feasible.
> >> >
> >> > If we remove "SMM", that will not only affect OvmfPkg unpleasantly, but
> >> > a bunch of other, out-of-tree code. And the reason I suddenly care
> about
> >> > out-of-tree code is that such code was written against a public industry
> >> > spec (= earlier versions of the PI spec).
> >> >
> >> > I don't think that the simplicity that would come from removing "SMM"
> >> > altogether, is well-balanced against the pain that it would cause for
> >> > platforms.
> >> >
> >> > Earlier this was solved in the following commits:
> >> > - 07c6a47e70ba ("MdePkg: Add new definitions for Management
> Mode.",
> >> > 2017-08-29)
> >> > - 2f208e59e4b9 ("MdePkg: Reference new definitions for Management
> >> > Mode.", 2017-08-29)
> >> >
> >> > Thanks
> >> > Laszlo
> >> >
> >> > > I prefer to remove the files in MdeModulePkg to avoid future
> confusion.
> >> > >
> >> > > Thanks,
> >> > > Ray
> >> > >
> >> > >> -----Original Message-----
> >> > >> From: Chen, Marc W
> >> > >> Sent: Tuesday, August 6, 2019 4:57 PM
> >> > >> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray
> >> > <ray.ni@intel.com>;
> >> > >> Gao, Liming <liming.gao@intel.com>
> >> > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> >> > >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >> > MmControl
> >> > >> definition.
> >> > >>
> >> > >> Hi Liming and Ray
> >> > >>
> >> > >> Do you also agree?
> >> > >>
> >> > >> Thanks,
> >> > >> Marc
> >> > >>
> >> > >>> -----Original Message-----
> >> > >>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> >> > Laszlo
> >> > >>> Ersek
> >> > >>> Sent: Friday, August 2, 2019 10:14 AM
> >> > >>> To: devel@edk2.groups.io; Chen, Marc W
> <marc.w.chen@intel.com>;
> >Ni,
> >> > >>> Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
> >> > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> >> > >>> Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >> > >> MmControl
> >> > >>> definition.
> >> > >>>
> >> > >>> On 08/01/19 12:15, Marc W Chen wrote:
> >> > >>>> Yes, my purpose is to avoid platform code update if the package is
> >> > >>>> allowed
> >> > >>> to use MdeModulePkg like OvmfPkg.
> >> > >>>> For those packages that cannot depend on MdeModulePkg must
> >> > change
> >> > >> to
> >> > >>> use new definition.
> >> > >>>
> >> > >>> Agreed.
> >> > >>>
> >> > >>> Thanks!
> >> > >>> Laszlo
> >> > >>>
> >> > >>>>> -----Original Message-----
> >> > >>>>> From: Ni, Ray
> >> > >>>>> Sent: Thursday, August 1, 2019 6:04 PM
> >> > >>>>> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
> >> > >>>>> <liming.gao@intel.com>; devel@edk2.groups.io
> >> > >>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> >> > >>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >> > >>> MmControl
> >> > >>>>> definition.
> >> > >>>>>
> >> > >>>>> Marc,
> >> > >>>>> Is the purpose to avoid platform code update with the wrapper
> >> > >>>>> header
> >> > >>> file in
> >> > >>>>> MdeModulePkg?
> >> > >>>>> Certain platforms they may require to not depend on
> >MdeModulePkg
> >> > >>>>> but just depend on MdePkg.
> >> > >>>>> Having SmmAccess.h in MdeModulePkg doesn't help.
> >> > >>>>>
> >> > >>>>> It also bring confusing.
> >> > >>>>>
> >> > >>>>> Thanks,
> >> > >>>>> Ray
> >> > >>>>>
> >> > >>>>>> -----Original Message-----
> >> > >>>>>> From: Chen, Marc W
> >> > >>>>>> Sent: Thursday, August 1, 2019 4:53 PM
> >> > >>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> >> > >>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> >> > >>>>>> <ray.ni@intel.com>
> >> > >>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >> > >>> MmControl
> >> > >>>>>> definition.
> >> > >>>>>>
> >> > >>>>>> Hi Liming
> >> > >>>>>>
> >> > >>>>>> Another thought, do you think it is ok to keep SmmAccess.h in
> >> > >>>>>> MdeModulePkg? We can use #define and typedef to convert
> >> > >> MmAccess
> >> > >>> to
> >> > >>>>>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
> >> > >>>>>>
> >> > >>>>>> Thanks,
> >> > >>>>>> Marc
> >> > >>>>>>
> >> > >>>>>>> -----Original Message-----
> >> > >>>>>>> From: Chen, Marc W
> >> > >>>>>>> Sent: Thursday, August 1, 2019 4:48 PM
> >> > >>>>>>> To: Gao, Liming <liming.gao@intel.com>;
> devel@edk2.groups.io
> >> > >>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> >> > >>>>>>> <ray.ni@intel.com>
> >> > >>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >> > >>>>>> MmControl
> >> > >>>>>>> definition.
> >> > >>>>>>>
> >> > >>>>>>> Hi Liming
> >> > >>>>>>>
> >> > >>>>>>> Since there are multiple packages are still using SmmAccess.h,
> >we
> >> > >>>>>>> need to change all packages to use MmAccess.h instead of
> >> > >>>>>>> SmmAccess.h first, then clean up SmmAccess.h from
> >> > MdeModulePkg
> >> > >> will be the last step.
> >> > >>>>>>> Below are the packages that has "include <Ppi/SmmAccess.h>"
> >for
> >> > >>>>>>> your reference.
> >> > >>>>>>> * Edk2 repo:
> >> > >>>>>>> o MdeModulePkg
> >> > >>>>>>> o OvmfPkg
> >> > >>>>>>> o UefiCpuPkg
> >> > >>>>>>> * Edk2Platform repo:
> >> > >>>>>>> o MinPlatformPkg
> >> > >>>>>>> o QuarkSocPkg
> >> > >>>>>>>
> >> > >>>>>>> Thanks,
> >> > >>>>>>> Marc
> >> > >>>>>>>
> >> > >>>>>>>> -----Original Message-----
> >> > >>>>>>>> From: Gao, Liming
> >> > >>>>>>>> Sent: Thursday, August 1, 2019 4:42 PM
> >> > >>>>>>>> To: devel@edk2.groups.io; Chen, Marc W
> >> > <marc.w.chen@intel.com>
> >> > >>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> >> > >>>>>>>> <ray.ni@intel.com>
> >> > >>>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess
> >and
> >> > >>>>>> MmControl
> >> > >>>>>>>> definition.
> >> > >>>>>>>>
> >> > >>>>>>>> Marc:
> >> > >>>>>>>> The change is good. Reviewed-by: Liming Gao
> >> > >>> <liming.gao@intel.com>
> >> > >>>>>>>>
> >> > >>>>>>>> Besides, I see BZ also mention to remove the one in
> >> > >> MdeModulePkg.
> >> > >>>>>>>> Have you the following patches for the change in
> >MdeModulePkg?
> >> > >>>>>>>>
> >> > >>>>>>>> Thanks
> >> > >>>>>>>> Liming
> >> > >>>>>>>>> -----Original Message-----
> >> > >>>>>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> >On
> >> > >>>>> Behalf
> >> > >>>>>>>>> Of Marc W Chen
> >> > >>>>>>>>> Sent: Monday, July 29, 2019 12:26 PM
> >> > >>>>>>>>> To: devel@edk2.groups.io
> >> > >>>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao,
> >> > Liming
> >> > >>>>>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> >> > >>>>>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >> > >>>>> MmControl
> >> > >>>>>>>>> definition.
> >> > >>>>>>>>>
> >> > >>>>>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
> >> > >>>>>> specification.
> >> > >>>>>>>>>
> >> > >>>>>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >> > >>>>>>>>> Cc: Liming Gao <liming.gao@intel.com>
> >> > >>>>>>>>> Cc: Ray Ni <ray.ni@intel.com>
> >> > >>>>>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> >> > >>>>>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> >> > >>>>>>>>> ---
> >> > >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
> >> > >>>>>>>>> +++++++++++++++++++++++++++++++++++++++++
> >> > >>>>>>>>> MdePkg/Include/Ppi/MmControl.h | 90
> >> > >>>>>> ++++++++++++++++++++++++
> >> > >>>>>>>>> MdePkg/MdePkg.dec | 6 ++
> >> > >>>>>>>>> 3 files changed, 251 insertions(+) create mode 100644
> >> > >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
> >> > >>>>>>>>> MdePkg/Include/Ppi/MmControl.h
> >> > >>>>>>>>>
> >> > >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
> >> > >>>>>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644
> >> > index
> >> > >>>>>>>>> 0000000000..636e7288a0
> >> > >>>>>>>>> --- /dev/null
> >> > >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
> >> > >>>>>>>>> @@ -0,0 +1,155 @@
> >> > >>>>>>>>> +/** @file
> >> > >>>>>>>>> + EFI MM Access PPI definition.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + This PPI is used to control the visibility of the MMRAM on
> >> > >>>>>>>>> + the
> >> > >>>>>> platform.
> >> > >>>>>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
> >> > >>>>>>>>> + characteristics
> >> > >>>>>>> of
> >> > >>>>>>>>> MMRAM. The
> >> > >>>>>>>>> + principal functionality found in the memory controller
> >> > >>>>>>>>> + includes the
> >> > >>>>>>>> following:
> >> > >>>>>>>>> + - Exposing the MMRAM to all non-MM agents, or the
> >"open"
> >> > >>>>>>>>> + state
> >> > >>>>>>>>> + - Shrouding the MMRAM to all but the MM agents, or the
> >> > >> "closed"
> >> > >>>>>>>>> + state
> >> > >>>>>>>>> + - Preserving the system integrity, or "locking" the MMRAM,
> >> > >>>>>>>>> + such that
> >> > >>>>>>> the
> >> > >>>>>>>>> settings cannot be
> >> > >>>>>>>>> + perturbed by either boot service or runtime agents
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> >> > >>>>>>>>> + reserved.<BR>
> >> > >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @par Revision Reference:
> >> > >>>>>>>>> + This PPI is introduced in PI Version 1.5.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +**/
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +#ifndef _MM_ACCESS_PPI_H_
> >> > >>>>>>>>> +#define _MM_ACCESS_PPI_H_
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
> >> > >>>>>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
> >> > >>>>>>>>> +0xc3, 0x2e,
> >> > >>>>>>>>> 0xd6 }}
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI
> >> > >> EFI_PEI_MM_ACCESS_PPI;
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +/**
> >> > >>>>>>>>> + Opens the MMRAM area to be accessible by a PEIM.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + This function "opens" MMRAM so that it is visible while
> not
> >> > >>>>>>>>> + inside of
> >> > >>>>>>> MM.
> >> > >>>>>>>>> The function should
> >> > >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not
> >support
> >> > >>>>>>>>> + hiding of
> >> > >>>>>>>>> MMRAM. The function
> >> > >>>>>>>>> + should return EFI_DEVICE_ERROR if the MMRAM
> >> > configuration
> >> > >> is
> >> > >>>>>> locked.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> >> > Services
> >> > >>>>>> Table
> >> > >>>>>>>>> published by the PEI Foundation.
> >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> >instance.
> >> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
> >Open.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> >> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
> >support
> >> > >>>>> opening
> >> > >>>>>>>> and
> >> > >>>>>>>>> closing of MMRAM.
> >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be
> opened,
> >> > >>>>> perhaps
> >> > >>>>>>>>> because it is locked.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +**/
> >> > >>>>>>>>> +typedef
> >> > >>>>>>>>> +EFI_STATUS
> >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
> >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >> > >>>>>>>>> + IN UINTN DescriptorIndex
> >> > >>>>>>>>> + );
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +/**
> >> > >>>>>>>>> + Inhibits access to the MMRAM.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + This function "closes" MMRAM so that it is not visible
> while
> >> > >>>>>>>>> + outside of
> >> > >>>>>>>> MM.
> >> > >>>>>>>>> The function should
> >> > >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not
> >support
> >> > >>>>>>>>> + hiding of
> >> > >>>>>>>>> MMRAM.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> >> > Services
> >> > >>>>>> Table
> >> > >>>>>>>>> published by the PEI Foundation.
> >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> >instance.
> >> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
> >Close.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> >> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
> >support
> >> > >>>>> opening
> >> > >>>>>>>> and
> >> > >>>>>>>>> closing of MMRAM.
> >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +**/
> >> > >>>>>>>>> +typedef
> >> > >>>>>>>>> +EFI_STATUS
> >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
> >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >> > >>>>>>>>> + IN UINTN DescriptorIndex
> >> > >>>>>>>>> + );
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +/**
> >> > >>>>>>>>> + This function prohibits access to the MMRAM region. This
> >> > >>>>>>>>> +function is
> >> > >>>>>>>> usually
> >> > >>>>>>>>> implemented such
> >> > >>>>>>>>> + that it is a write-once operation.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> >> > Services
> >> > >>>>>> Table
> >> > >>>>>>>>> published by the PEI Foundation.
> >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> >instance.
> >> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
> >Lock.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> >> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
> >support
> >> > >>>>> opening
> >> > >>>>>>>> and
> >> > >>>>>>>>> closing of MMRAM.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +**/
> >> > >>>>>>>>> +typedef
> >> > >>>>>>>>> +EFI_STATUS
> >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
> >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >> > >>>>>>>>> + IN UINTN DescriptorIndex
> >> > >>>>>>>>> + );
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +/**
> >> > >>>>>>>>> + Queries the memory controller for the possible regions
> that
> >> > >>>>>>>>> +will support
> >> > >>>>>>>>> MMRAM.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + This function describes the MMRAM regions.
> >> > >>>>>>>>> + This data structure forms the contract between the
> >> > >> MM_ACCESS
> >> > >>>>> and
> >> > >>>>>>>>> MM_IPL drivers. There is an
> >> > >>>>>>>>> + ambiguity when any MMRAM region is remapped. For
> >> > example,
> >> > >> on
> >> > >>>>>>> some
> >> > >>>>>>>>> chipsets, some MMRAM
> >> > >>>>>>>>> + regions can be initialized at one physical address but is
> >> > >>>>>>>>> + later accessed at
> >> > >>>>>>>>> another processor address.
> >> > >>>>>>>>> + There is currently no way for the MM IPL driver to know
> >that
> >> > >>>>>>>>> + it must use
> >> > >>>>>>>>> two different addresses
> >> > >>>>>>>>> + depending on what it is trying to do. As a result, initial
> >> > >>>>>>>>> + configuration and
> >> > >>>>>>>>> loading can use the
> >> > >>>>>>>>> + physical address PhysicalStart while MMRAM is open.
> >> > However,
> >> > >>>>>>>>> + once
> >> > >>>>>>> the
> >> > >>>>>>>>> region has been
> >> > >>>>>>>>> + closed and needs to be accessed by agents in MM, the
> >> > >>>>>>>>> + CpuStart address
> >> > >>>>>>>>> must be used.
> >> > >>>>>>>>> + This PPI publishes the available memory that the chipset
> >can
> >> > >>>>>>>>> + shroud for
> >> > >>>>>>>> the
> >> > >>>>>>>>> use of installing code.
> >> > >>>>>>>>> + These regions serve the dual purpose of describing which
> >> > >>>>>>>>> + regions have
> >> > >>>>>>>>> been open, closed, or locked.
> >> > >>>>>>>>> + In addition, these regions may include overlapping
> memory
> >> > >>>>>>>>> + ranges,
> >> > >>>>>>>>> depending on the chipset
> >> > >>>>>>>>> + implementation. The latter might include a chipset that
> >> > >>>>>>>>> + supports T-SEG,
> >> > >>>>>>>>> where memory near the top
> >> > >>>>>>>>> + of the physical DRAM can be allocated for MMRAM too.
> >> > >>>>>>>>> + The key thing to note is that the regions that are described
> >> > >>>>>>>>> + by the PPI
> >> > >>>>>>> are
> >> > >>>>>>>> a
> >> > >>>>>>>>> subset of the capabilities
> >> > >>>>>>>>> + of the hardware.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> >> > Services
> >> > >>>>>> Table
> >> > >>>>>>>>> published by the PEI Foundation.
> >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> >instance.
> >> > >>>>>>>>> + @param MmramMapSize A pointer to the size, in
> >bytes,
> >> > of
> >> > >>>>> the
> >> > >>>>>>>>> MmramMemoryMap buffer. On input, this value is
> >> > >>>>>>>>> + the size of the buffer that
> >> > >>>>>>>>> + is allocated by the caller. On
> >> > >>>>>>>>> output, it is the size of the
> >> > >>>>>>>>> + buffer that was returned by
> >> > >>>>>>>>> + the firmware if the buffer
> >> > >>>>>>>> was
> >> > >>>>>>>>> large enough, or, if the
> >> > >>>>>>>>> + buffer was too small, the
> >> > >>>>>>>>> + size of the buffer that is
> >> > >>>>>>>> needed to
> >> > >>>>>>>>> contain the map.
> >> > >>>>>>>>> + @param MmramMap A pointer to the buffer in
> >which
> >> > >>>>>> firmware
> >> > >>>>>>>>> places the current memory map. The map is
> >> > >>>>>>>>> + an array of
> >> > >>>>>>>>> + EFI_MMRAM_DESCRIPTORs
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @retval EFI_SUCCESS The chipset supported the
> given
> >> > >>>>> resource.
> >> > >>>>>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap
> >> > parameter
> >> > >>> was
> >> > >>>>>> too
> >> > >>>>>>>>> small. The current
> >> > >>>>>>>>> + buffer size needed to hold
> >> > >>>>>>>>> + the memory map is
> >> > >>>>>>> returned
> >> > >>>>>>>> in
> >> > >>>>>>>>> + MmramMapSize.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +**/
> >> > >>>>>>>>> +typedef
> >> > >>>>>>>>> +EFI_STATUS
> >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> >> > >>>>>>>>> + IN OUT UINTN *MmramMapSize,
> >> > >>>>>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> >> > >>>>>>>>> + );
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +///
> >> > >>>>>>>>> +/// EFI MM Access PPI is used to control the visibility of
> >> > >>>>>>>>> +the MMRAM on
> >> > >>>>>>>> the
> >> > >>>>>>>>> platform.
> >> > >>>>>>>>> +/// It abstracts the location and characteristics of MMRAM.
> >> > >>>>>>>>> +The platform
> >> > >>>>>>>>> should report
> >> > >>>>>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The
> >expectation
> >> > is
> >> > >>> that
> >> > >>>>>>>>> +the
> >> > >>>>>>>>> north bridge or
> >> > >>>>>>>>> +/// memory controller would publish this PPI.
> >> > >>>>>>>>> +///
> >> > >>>>>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
> >> > >>>>>>>>> + EFI_PEI_MM_OPEN Open;
> >> > >>>>>>>>> + EFI_PEI_MM_CLOSE Close;
> >> > >>>>>>>>> + EFI_PEI_MM_LOCK Lock;
> >> > >>>>>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
> >> > >>>>>>>>> + BOOLEAN LockState;
> >> > >>>>>>>>> + BOOLEAN OpenState;
> >> > >>>>>>>>> +};
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +#endif
> >> > >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
> >> > >>>>>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644
> >> > index
> >> > >>>>>>>>> 0000000000..983ed95cd5
> >> > >>>>>>>>> --- /dev/null
> >> > >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
> >> > >>>>>>>>> @@ -0,0 +1,90 @@
> >> > >>>>>>>>> +/** @file
> >> > >>>>>>>>> + EFI MM Control PPI definition.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + This PPI is used initiate synchronous MMI activations. This
> >> > >>>>>>>>> + PPI could be
> >> > >>>>>>>>> published by a processor
> >> > >>>>>>>>> + driver to abstract the MMI IPI or a driver which abstracts
> >> > >>>>>>>>> + the ASIC that
> >> > >>>>>>> is
> >> > >>>>>>>>> supporting the APM port.
> >> > >>>>>>>>> + Because of the possibility of performing MMI IPI
> >> > >>>>>>>>> + transactions, the ability
> >> > >>>>>>>> to
> >> > >>>>>>>>> generate this event
> >> > >>>>>>>>> + from a platform chipset agent is an optional capability for
> >> > >>>>>>>>> + both
> >> > >>>>>>>>> + IA-32
> >> > >>>>>>> and
> >> > >>>>>>>>> x64-based systems.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> >> > >>>>>>>>> + reserved.<BR>
> >> > >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @par Revision Reference:
> >> > >>>>>>>>> + This PPI is introduced in PI Version 1.5.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +**/
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +#ifndef _MM_CONTROL_PPI_H_
> >> > >>>>>>>>> +#define _MM_CONTROL_PPI_H_
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
> >> > >>>>>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5,
> >> > >>>>>>>>> +0xce, 0x74,
> >> > >>>>>>>> 0xc5 }
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
> >> > >>>>>> EFI_PEI_MM_CONTROL_PPI;
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +/**
> >> > >>>>>>>>> + Invokes PPI activation from the PI PEI environment.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> >> > Services
> >> > >>>>> Table
> >> > >>>>>>>>> published by the PEI Foundation.
> >> > >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI
> instance.
> >> > >>>>>>>>> + @param ArgumentBuffer The value passed to the
> MMI
> >> > >>> handler.
> >> > >>>>>>> This
> >> > >>>>>>>>> value corresponds to the
> >> > >>>>>>>>> + SwMmiInputValue in the
> >> > >>>>>>>>> + RegisterContext parameter
> >> > >>>>>>> for
> >> > >>>>>>>> the
> >> > >>>>>>>>> Register()
> >> > >>>>>>>>> + function in the
> >> > >>>>>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
> >> > >>>>>>> and
> >> > >>>>>>>> in
> >> > >>>>>>>>> the Context parameter
> >> > >>>>>>>>> + in the call to the DispatchFunction
> >> > >>>>>>>>> + @param ArgumentBufferSize The size of the data
> passed
> >in
> >> > >>>>>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> >> > >>>>>>>>> + @param Periodic An optional mechanism to
> >periodically
> >> > >>>>> repeat
> >> > >>>>>>>>> activation.
> >> > >>>>>>>>> + @param ActivationInterval An optional parameter to
> >repeat
> >> > at
> >> > >>>>> this
> >> > >>>>>>>> period
> >> > >>>>>>>>> one
> >> > >>>>>>>>> + time or, if the Periodic Boolean is set,
> >> > periodically.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
> >> > >>>>>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
> >> > >>>>>> unsupported.
> >> > >>>>>>>>> + @retval EFI_NOT_STARTED The MM base service has
> not
> >> > >> been
> >> > >>>>>>>> initialized.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +**/
> >> > >>>>>>>>> +typedef
> >> > >>>>>>>>> +EFI_STATUS
> >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >> > >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> >> > >>>>>>>>> + IN OUT INT8 *ArgumentBuffer
> >OPTIONAL,
> >> > >>>>>>>>> + IN OUT UINTN *ArgumentBufferSize
> >> > >>> OPTIONAL,
> >> > >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL,
> >> > >>>>>>>>> + IN UINTN ActivationInterval
> OPTIONAL
> >> > >>>>>>>>> + );
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +/**
> >> > >>>>>>>>> + Clears any system state that was created in response to
> the
> >> > >>> Trigger()
> >> > >>>>>> call.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @param PeiServices General purpose services
> >available
> >> > to
> >> > >>>>> every
> >> > >>>>>>>> PEIM.
> >> > >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI
> instance.
> >> > >>>>>>>>> + @param Periodic Optional parameter to repeat at
> >this
> >> > >>>>> period
> >> > >>>>>>> one
> >> > >>>>>>>>> + time or, if the Periodic Boolean is set,
> >> > periodically.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR The source could not be
> >> > cleared.
> >> > >>>>>>>>> + @retval EFI_INVALID_PARAMETER The service did not
> >support
> >> > >>>>>>>>> + the
> >> > >>>>>>>> Periodic
> >> > >>>>>>>>> input argument.
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +**/
> >> > >>>>>>>>> +typedef
> >> > >>>>>>>>> +EFI_STATUS
> >> > >>>>>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
> >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> >> > >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> >> > >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL
> >> > >>>>>>>>> + );
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +///
> >> > >>>>>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM.
> >It
> >> > >>>>>> provides
> >> > >>>>>>> an
> >> > >>>>>>>>> abstraction of the
> >> > >>>>>>>>> +/// platform hardware that generates an MMI. There are
> >often
> >> > >>>>>>>>> +I/O ports
> >> > >>>>>>>>> that, when accessed, will
> >> > >>>>>>>>> +/// generate the MMI. Also, the hardware optionally
> >supports
> >> > >>>>>>>>> +the
> >> > >>>>>>> periodic
> >> > >>>>>>>>> generation of these signals.
> >> > >>>>>>>>> +///
> >> > >>>>>>>>> +struct _PEI_MM_CONTROL_PPI {
> >> > >>>>>>>>> + PEI_MM_ACTIVATE Trigger;
> >> > >>>>>>>>> + PEI_MM_DEACTIVATE Clear;
> >> > >>>>>>>>> +};
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
> >> > >>>>>>>>> +
> >> > >>>>>>>>> +#endif
> >> > >>>>>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> >index
> >> > >>>>>>>>> b382efd578..34e0f39395 100644
> >> > >>>>>>>>> --- a/MdePkg/MdePkg.dec
> >> > >>>>>>>>> +++ b/MdePkg/MdePkg.dec
> >> > >>>>>>>>> @@ -925,6 +925,12 @@
> >> > >>>>>>>>> ## Include/Ppi/SecHobData.h
> >> > >>>>>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8,
> >{0xb4,
> >> > >>>>>>>>> 0xee,
> >> > >>>>>>> 0xf5,
> >> > >>>>>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> >> > >>>>>>>>>
> >> > >>>>>>>>> + ## Include/Ppi/MmAccess.h
> >> > >>>>>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd,
> >0x48be,
> >> > >>>>> { 0x88,
> >> > >>>>>>>> 0x17,
> >> > >>>>>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> >> > >>>>>>>>> +
> >> > >>>>>>>>> + ## Include/Ppi/MmControl.h
> >> > >>>>>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e,
> >0x4f43,
> >> > >>>>> { 0x8d,
> >> > >>>>>>>> 0xef,
> >> > >>>>>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> >> > >>>>>>>>> +
> >> > >>>>>>>>> #
> >> > >>>>>>>>> # PPIs defined in PI 1.7.
> >> > >>>>>>>>> #
> >> > >>>>>>>>> --
> >> > >>>>>>>>> 2.16.2.windows.1
> >> > >>>>>>>>>
> >> > >>>>>>>>>
> >> > >>>>>>>>>
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >
> >> >
> >> >
> >> >
> >
> >
> >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-14 9:53 ` Marc W Chen
@ 2019-08-18 5:20 ` Ni, Ray
2019-08-18 5:21 ` Ni, Ray
1 sibling, 0 replies; 18+ messages in thread
From: Ni, Ray @ 2019-08-18 5:20 UTC (permalink / raw)
To: Chen, Marc W, Gao, Liming, devel@edk2.groups.io,
lersek@redhat.com
Cc: Kinney, Michael D
I don't have strong preference on removing SmmAccess.h from MdeModulePkg.
If people except me all agreed to keep that header file for compatibility, I am ok.
> -----Original Message-----
> From: Chen, Marc W
> Sent: Wednesday, August 14, 2019 5:54 PM
> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; lersek@redhat.com; Ni, Ray <ray.ni@intel.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
>
> Thanks Liming for pushing the code.
>
> Can we have a conclusion for the SmmAccess.h removal from MdeModulePkg? Who can make the decision? Or do we need any
> further discussion?
>
> Thanks,
> Marc
>
> > -----Original Message-----
> > From: Gao, Liming
> > Sent: Tuesday, August 13, 2019 5:20 PM
> > To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Chen, Marc
> > W <marc.w.chen@intel.com>; lersek@redhat.com; Ni, Ray
> > <ray.ni@intel.com>
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> > definition.
> >
> > Push @6f33f7a262314af35e2b99c849e08928ea49aa55
> >
> > >-----Original Message-----
> > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > >Liming Gao
> > >Sent: Saturday, August 10, 2019 11:34 AM
> > >To: Chen, Marc W <marc.w.chen@intel.com>; devel@edk2.groups.io;
> > >lersek@redhat.com; Ni, Ray <ray.ni@intel.com>
> > >Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > >Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> > >definition.
> > >
> > >I agree. The patch to add them in MdePkg is clear. I will push it next Monday.
> > >
> > >Thanks
> > >Liming
> > >> -----Original Message-----
> > >> From: Chen, Marc W
> > >> Sent: Saturday, August 10, 2019 11:33 AM
> > >> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray
> > <ray.ni@intel.com>;
> > >Gao, Liming <liming.gao@intel.com>
> > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > MmControl
> > >definition.
> > >>
> > >> Hi Liming
> > >>
> > >> Since the SmmAccess.h of MdeModulePkg removal is still under discussion,
> > >can we push the MmAccess.h and MmControl.h to MdePkg
> > >> first? I have other tasks pending by this.
> > >> We can keep discussing the SmmAccess after push the code.
> > >>
> > >> Thanks,
> > >> Marc
> > >>
> > >> > -----Original Message-----
> > >> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > Laszlo
> > >> > Ersek
> > >> > Sent: Thursday, August 8, 2019 12:11 AM
> > >> > To: Ni, Ray <ray.ni@intel.com>; Chen, Marc W
> > <marc.w.chen@intel.com>;
> > >> > devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> > >> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > >> > Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >MmControl
> > >> > definition.
> > >> >
> > >> > On 08/06/19 12:08, Ni, Ray wrote:
> > >> > > Laszlo,
> > >> > > Do you want to avoid touching the OvmfPkg due the file removal in
> > >> > MdeModulePkg?
> > >> >
> > >> > My main problem with this *specific* update proposal is that the
> > >> > identifiers (type names and such) that would be subject to removal were
> > >> > publicly specified in earlier PI spec releases.
> > >> >
> > >> > I don't suggest that we maintain two parallel sets of typedefs and such
> > >> > in edk2. It's fine to keep the new "MM" nomenclature the main one. But
> > >> > we should keep the "SMM" set of terms too, as a thin wrapper, if that's
> > >> > technically feasible.
> > >> >
> > >> > If we remove "SMM", that will not only affect OvmfPkg unpleasantly, but
> > >> > a bunch of other, out-of-tree code. And the reason I suddenly care
> > about
> > >> > out-of-tree code is that such code was written against a public industry
> > >> > spec (= earlier versions of the PI spec).
> > >> >
> > >> > I don't think that the simplicity that would come from removing "SMM"
> > >> > altogether, is well-balanced against the pain that it would cause for
> > >> > platforms.
> > >> >
> > >> > Earlier this was solved in the following commits:
> > >> > - 07c6a47e70ba ("MdePkg: Add new definitions for Management
> > Mode.",
> > >> > 2017-08-29)
> > >> > - 2f208e59e4b9 ("MdePkg: Reference new definitions for Management
> > >> > Mode.", 2017-08-29)
> > >> >
> > >> > Thanks
> > >> > Laszlo
> > >> >
> > >> > > I prefer to remove the files in MdeModulePkg to avoid future
> > confusion.
> > >> > >
> > >> > > Thanks,
> > >> > > Ray
> > >> > >
> > >> > >> -----Original Message-----
> > >> > >> From: Chen, Marc W
> > >> > >> Sent: Tuesday, August 6, 2019 4:57 PM
> > >> > >> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray
> > >> > <ray.ni@intel.com>;
> > >> > >> Gao, Liming <liming.gao@intel.com>
> > >> > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > >> > >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >> > MmControl
> > >> > >> definition.
> > >> > >>
> > >> > >> Hi Liming and Ray
> > >> > >>
> > >> > >> Do you also agree?
> > >> > >>
> > >> > >> Thanks,
> > >> > >> Marc
> > >> > >>
> > >> > >>> -----Original Message-----
> > >> > >>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > >> > Laszlo
> > >> > >>> Ersek
> > >> > >>> Sent: Friday, August 2, 2019 10:14 AM
> > >> > >>> To: devel@edk2.groups.io; Chen, Marc W
> > <marc.w.chen@intel.com>;
> > >Ni,
> > >> > >>> Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
> > >> > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > >> > >>> Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >> > >> MmControl
> > >> > >>> definition.
> > >> > >>>
> > >> > >>> On 08/01/19 12:15, Marc W Chen wrote:
> > >> > >>>> Yes, my purpose is to avoid platform code update if the package is
> > >> > >>>> allowed
> > >> > >>> to use MdeModulePkg like OvmfPkg.
> > >> > >>>> For those packages that cannot depend on MdeModulePkg must
> > >> > change
> > >> > >> to
> > >> > >>> use new definition.
> > >> > >>>
> > >> > >>> Agreed.
> > >> > >>>
> > >> > >>> Thanks!
> > >> > >>> Laszlo
> > >> > >>>
> > >> > >>>>> -----Original Message-----
> > >> > >>>>> From: Ni, Ray
> > >> > >>>>> Sent: Thursday, August 1, 2019 6:04 PM
> > >> > >>>>> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
> > >> > >>>>> <liming.gao@intel.com>; devel@edk2.groups.io
> > >> > >>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > >> > >>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >> > >>> MmControl
> > >> > >>>>> definition.
> > >> > >>>>>
> > >> > >>>>> Marc,
> > >> > >>>>> Is the purpose to avoid platform code update with the wrapper
> > >> > >>>>> header
> > >> > >>> file in
> > >> > >>>>> MdeModulePkg?
> > >> > >>>>> Certain platforms they may require to not depend on
> > >MdeModulePkg
> > >> > >>>>> but just depend on MdePkg.
> > >> > >>>>> Having SmmAccess.h in MdeModulePkg doesn't help.
> > >> > >>>>>
> > >> > >>>>> It also bring confusing.
> > >> > >>>>>
> > >> > >>>>> Thanks,
> > >> > >>>>> Ray
> > >> > >>>>>
> > >> > >>>>>> -----Original Message-----
> > >> > >>>>>> From: Chen, Marc W
> > >> > >>>>>> Sent: Thursday, August 1, 2019 4:53 PM
> > >> > >>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> > >> > >>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > >> > >>>>>> <ray.ni@intel.com>
> > >> > >>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >> > >>> MmControl
> > >> > >>>>>> definition.
> > >> > >>>>>>
> > >> > >>>>>> Hi Liming
> > >> > >>>>>>
> > >> > >>>>>> Another thought, do you think it is ok to keep SmmAccess.h in
> > >> > >>>>>> MdeModulePkg? We can use #define and typedef to convert
> > >> > >> MmAccess
> > >> > >>> to
> > >> > >>>>>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
> > >> > >>>>>>
> > >> > >>>>>> Thanks,
> > >> > >>>>>> Marc
> > >> > >>>>>>
> > >> > >>>>>>> -----Original Message-----
> > >> > >>>>>>> From: Chen, Marc W
> > >> > >>>>>>> Sent: Thursday, August 1, 2019 4:48 PM
> > >> > >>>>>>> To: Gao, Liming <liming.gao@intel.com>;
> > devel@edk2.groups.io
> > >> > >>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > >> > >>>>>>> <ray.ni@intel.com>
> > >> > >>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >> > >>>>>> MmControl
> > >> > >>>>>>> definition.
> > >> > >>>>>>>
> > >> > >>>>>>> Hi Liming
> > >> > >>>>>>>
> > >> > >>>>>>> Since there are multiple packages are still using SmmAccess.h,
> > >we
> > >> > >>>>>>> need to change all packages to use MmAccess.h instead of
> > >> > >>>>>>> SmmAccess.h first, then clean up SmmAccess.h from
> > >> > MdeModulePkg
> > >> > >> will be the last step.
> > >> > >>>>>>> Below are the packages that has "include <Ppi/SmmAccess.h>"
> > >for
> > >> > >>>>>>> your reference.
> > >> > >>>>>>> * Edk2 repo:
> > >> > >>>>>>> o MdeModulePkg
> > >> > >>>>>>> o OvmfPkg
> > >> > >>>>>>> o UefiCpuPkg
> > >> > >>>>>>> * Edk2Platform repo:
> > >> > >>>>>>> o MinPlatformPkg
> > >> > >>>>>>> o QuarkSocPkg
> > >> > >>>>>>>
> > >> > >>>>>>> Thanks,
> > >> > >>>>>>> Marc
> > >> > >>>>>>>
> > >> > >>>>>>>> -----Original Message-----
> > >> > >>>>>>>> From: Gao, Liming
> > >> > >>>>>>>> Sent: Thursday, August 1, 2019 4:42 PM
> > >> > >>>>>>>> To: devel@edk2.groups.io; Chen, Marc W
> > >> > <marc.w.chen@intel.com>
> > >> > >>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > >> > >>>>>>>> <ray.ni@intel.com>
> > >> > >>>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess
> > >and
> > >> > >>>>>> MmControl
> > >> > >>>>>>>> definition.
> > >> > >>>>>>>>
> > >> > >>>>>>>> Marc:
> > >> > >>>>>>>> The change is good. Reviewed-by: Liming Gao
> > >> > >>> <liming.gao@intel.com>
> > >> > >>>>>>>>
> > >> > >>>>>>>> Besides, I see BZ also mention to remove the one in
> > >> > >> MdeModulePkg.
> > >> > >>>>>>>> Have you the following patches for the change in
> > >MdeModulePkg?
> > >> > >>>>>>>>
> > >> > >>>>>>>> Thanks
> > >> > >>>>>>>> Liming
> > >> > >>>>>>>>> -----Original Message-----
> > >> > >>>>>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> > >On
> > >> > >>>>> Behalf
> > >> > >>>>>>>>> Of Marc W Chen
> > >> > >>>>>>>>> Sent: Monday, July 29, 2019 12:26 PM
> > >> > >>>>>>>>> To: devel@edk2.groups.io
> > >> > >>>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao,
> > >> > Liming
> > >> > >>>>>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> > >> > >>>>>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > >> > >>>>> MmControl
> > >> > >>>>>>>>> definition.
> > >> > >>>>>>>>>
> > >> > >>>>>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
> > >> > >>>>>> specification.
> > >> > >>>>>>>>>
> > >> > >>>>>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > >> > >>>>>>>>> Cc: Liming Gao <liming.gao@intel.com>
> > >> > >>>>>>>>> Cc: Ray Ni <ray.ni@intel.com>
> > >> > >>>>>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> > >> > >>>>>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> > >> > >>>>>>>>> ---
> > >> > >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
> > >> > >>>>>>>>> +++++++++++++++++++++++++++++++++++++++++
> > >> > >>>>>>>>> MdePkg/Include/Ppi/MmControl.h | 90
> > >> > >>>>>> ++++++++++++++++++++++++
> > >> > >>>>>>>>> MdePkg/MdePkg.dec | 6 ++
> > >> > >>>>>>>>> 3 files changed, 251 insertions(+) create mode 100644
> > >> > >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
> > >> > >>>>>>>>> MdePkg/Include/Ppi/MmControl.h
> > >> > >>>>>>>>>
> > >> > >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
> > >> > >>>>>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644
> > >> > index
> > >> > >>>>>>>>> 0000000000..636e7288a0
> > >> > >>>>>>>>> --- /dev/null
> > >> > >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
> > >> > >>>>>>>>> @@ -0,0 +1,155 @@
> > >> > >>>>>>>>> +/** @file
> > >> > >>>>>>>>> + EFI MM Access PPI definition.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + This PPI is used to control the visibility of the MMRAM on
> > >> > >>>>>>>>> + the
> > >> > >>>>>> platform.
> > >> > >>>>>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
> > >> > >>>>>>>>> + characteristics
> > >> > >>>>>>> of
> > >> > >>>>>>>>> MMRAM. The
> > >> > >>>>>>>>> + principal functionality found in the memory controller
> > >> > >>>>>>>>> + includes the
> > >> > >>>>>>>> following:
> > >> > >>>>>>>>> + - Exposing the MMRAM to all non-MM agents, or the
> > >"open"
> > >> > >>>>>>>>> + state
> > >> > >>>>>>>>> + - Shrouding the MMRAM to all but the MM agents, or the
> > >> > >> "closed"
> > >> > >>>>>>>>> + state
> > >> > >>>>>>>>> + - Preserving the system integrity, or "locking" the MMRAM,
> > >> > >>>>>>>>> + such that
> > >> > >>>>>>> the
> > >> > >>>>>>>>> settings cannot be
> > >> > >>>>>>>>> + perturbed by either boot service or runtime agents
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> > >> > >>>>>>>>> + reserved.<BR>
> > >> > >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @par Revision Reference:
> > >> > >>>>>>>>> + This PPI is introduced in PI Version 1.5.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +**/
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +#ifndef _MM_ACCESS_PPI_H_
> > >> > >>>>>>>>> +#define _MM_ACCESS_PPI_H_
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
> > >> > >>>>>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
> > >> > >>>>>>>>> +0xc3, 0x2e,
> > >> > >>>>>>>>> 0xd6 }}
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI
> > >> > >> EFI_PEI_MM_ACCESS_PPI;
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +/**
> > >> > >>>>>>>>> + Opens the MMRAM area to be accessible by a PEIM.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + This function "opens" MMRAM so that it is visible while
> > not
> > >> > >>>>>>>>> + inside of
> > >> > >>>>>>> MM.
> > >> > >>>>>>>>> The function should
> > >> > >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not
> > >support
> > >> > >>>>>>>>> + hiding of
> > >> > >>>>>>>>> MMRAM. The function
> > >> > >>>>>>>>> + should return EFI_DEVICE_ERROR if the MMRAM
> > >> > configuration
> > >> > >> is
> > >> > >>>>>> locked.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > >> > Services
> > >> > >>>>>> Table
> > >> > >>>>>>>>> published by the PEI Foundation.
> > >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> > >instance.
> > >> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
> > >Open.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> > >> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
> > >support
> > >> > >>>>> opening
> > >> > >>>>>>>> and
> > >> > >>>>>>>>> closing of MMRAM.
> > >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be
> > opened,
> > >> > >>>>> perhaps
> > >> > >>>>>>>>> because it is locked.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +**/
> > >> > >>>>>>>>> +typedef
> > >> > >>>>>>>>> +EFI_STATUS
> > >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
> > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >> > >>>>>>>>> + IN UINTN DescriptorIndex
> > >> > >>>>>>>>> + );
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +/**
> > >> > >>>>>>>>> + Inhibits access to the MMRAM.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + This function "closes" MMRAM so that it is not visible
> > while
> > >> > >>>>>>>>> + outside of
> > >> > >>>>>>>> MM.
> > >> > >>>>>>>>> The function should
> > >> > >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not
> > >support
> > >> > >>>>>>>>> + hiding of
> > >> > >>>>>>>>> MMRAM.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > >> > Services
> > >> > >>>>>> Table
> > >> > >>>>>>>>> published by the PEI Foundation.
> > >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> > >instance.
> > >> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
> > >Close.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> > >> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
> > >support
> > >> > >>>>> opening
> > >> > >>>>>>>> and
> > >> > >>>>>>>>> closing of MMRAM.
> > >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +**/
> > >> > >>>>>>>>> +typedef
> > >> > >>>>>>>>> +EFI_STATUS
> > >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
> > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >> > >>>>>>>>> + IN UINTN DescriptorIndex
> > >> > >>>>>>>>> + );
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +/**
> > >> > >>>>>>>>> + This function prohibits access to the MMRAM region. This
> > >> > >>>>>>>>> +function is
> > >> > >>>>>>>> usually
> > >> > >>>>>>>>> implemented such
> > >> > >>>>>>>>> + that it is a write-once operation.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > >> > Services
> > >> > >>>>>> Table
> > >> > >>>>>>>>> published by the PEI Foundation.
> > >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> > >instance.
> > >> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
> > >Lock.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> > >> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
> > >support
> > >> > >>>>> opening
> > >> > >>>>>>>> and
> > >> > >>>>>>>>> closing of MMRAM.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +**/
> > >> > >>>>>>>>> +typedef
> > >> > >>>>>>>>> +EFI_STATUS
> > >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
> > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >> > >>>>>>>>> + IN UINTN DescriptorIndex
> > >> > >>>>>>>>> + );
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +/**
> > >> > >>>>>>>>> + Queries the memory controller for the possible regions
> > that
> > >> > >>>>>>>>> +will support
> > >> > >>>>>>>>> MMRAM.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + This function describes the MMRAM regions.
> > >> > >>>>>>>>> + This data structure forms the contract between the
> > >> > >> MM_ACCESS
> > >> > >>>>> and
> > >> > >>>>>>>>> MM_IPL drivers. There is an
> > >> > >>>>>>>>> + ambiguity when any MMRAM region is remapped. For
> > >> > example,
> > >> > >> on
> > >> > >>>>>>> some
> > >> > >>>>>>>>> chipsets, some MMRAM
> > >> > >>>>>>>>> + regions can be initialized at one physical address but is
> > >> > >>>>>>>>> + later accessed at
> > >> > >>>>>>>>> another processor address.
> > >> > >>>>>>>>> + There is currently no way for the MM IPL driver to know
> > >that
> > >> > >>>>>>>>> + it must use
> > >> > >>>>>>>>> two different addresses
> > >> > >>>>>>>>> + depending on what it is trying to do. As a result, initial
> > >> > >>>>>>>>> + configuration and
> > >> > >>>>>>>>> loading can use the
> > >> > >>>>>>>>> + physical address PhysicalStart while MMRAM is open.
> > >> > However,
> > >> > >>>>>>>>> + once
> > >> > >>>>>>> the
> > >> > >>>>>>>>> region has been
> > >> > >>>>>>>>> + closed and needs to be accessed by agents in MM, the
> > >> > >>>>>>>>> + CpuStart address
> > >> > >>>>>>>>> must be used.
> > >> > >>>>>>>>> + This PPI publishes the available memory that the chipset
> > >can
> > >> > >>>>>>>>> + shroud for
> > >> > >>>>>>>> the
> > >> > >>>>>>>>> use of installing code.
> > >> > >>>>>>>>> + These regions serve the dual purpose of describing which
> > >> > >>>>>>>>> + regions have
> > >> > >>>>>>>>> been open, closed, or locked.
> > >> > >>>>>>>>> + In addition, these regions may include overlapping
> > memory
> > >> > >>>>>>>>> + ranges,
> > >> > >>>>>>>>> depending on the chipset
> > >> > >>>>>>>>> + implementation. The latter might include a chipset that
> > >> > >>>>>>>>> + supports T-SEG,
> > >> > >>>>>>>>> where memory near the top
> > >> > >>>>>>>>> + of the physical DRAM can be allocated for MMRAM too.
> > >> > >>>>>>>>> + The key thing to note is that the regions that are described
> > >> > >>>>>>>>> + by the PPI
> > >> > >>>>>>> are
> > >> > >>>>>>>> a
> > >> > >>>>>>>>> subset of the capabilities
> > >> > >>>>>>>>> + of the hardware.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > >> > Services
> > >> > >>>>>> Table
> > >> > >>>>>>>>> published by the PEI Foundation.
> > >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> > >instance.
> > >> > >>>>>>>>> + @param MmramMapSize A pointer to the size, in
> > >bytes,
> > >> > of
> > >> > >>>>> the
> > >> > >>>>>>>>> MmramMemoryMap buffer. On input, this value is
> > >> > >>>>>>>>> + the size of the buffer that
> > >> > >>>>>>>>> + is allocated by the caller. On
> > >> > >>>>>>>>> output, it is the size of the
> > >> > >>>>>>>>> + buffer that was returned by
> > >> > >>>>>>>>> + the firmware if the buffer
> > >> > >>>>>>>> was
> > >> > >>>>>>>>> large enough, or, if the
> > >> > >>>>>>>>> + buffer was too small, the
> > >> > >>>>>>>>> + size of the buffer that is
> > >> > >>>>>>>> needed to
> > >> > >>>>>>>>> contain the map.
> > >> > >>>>>>>>> + @param MmramMap A pointer to the buffer in
> > >which
> > >> > >>>>>> firmware
> > >> > >>>>>>>>> places the current memory map. The map is
> > >> > >>>>>>>>> + an array of
> > >> > >>>>>>>>> + EFI_MMRAM_DESCRIPTORs
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @retval EFI_SUCCESS The chipset supported the
> > given
> > >> > >>>>> resource.
> > >> > >>>>>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap
> > >> > parameter
> > >> > >>> was
> > >> > >>>>>> too
> > >> > >>>>>>>>> small. The current
> > >> > >>>>>>>>> + buffer size needed to hold
> > >> > >>>>>>>>> + the memory map is
> > >> > >>>>>>> returned
> > >> > >>>>>>>> in
> > >> > >>>>>>>>> + MmramMapSize.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +**/
> > >> > >>>>>>>>> +typedef
> > >> > >>>>>>>>> +EFI_STATUS
> > >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > >> > >>>>>>>>> + IN OUT UINTN *MmramMapSize,
> > >> > >>>>>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> > >> > >>>>>>>>> + );
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +///
> > >> > >>>>>>>>> +/// EFI MM Access PPI is used to control the visibility of
> > >> > >>>>>>>>> +the MMRAM on
> > >> > >>>>>>>> the
> > >> > >>>>>>>>> platform.
> > >> > >>>>>>>>> +/// It abstracts the location and characteristics of MMRAM.
> > >> > >>>>>>>>> +The platform
> > >> > >>>>>>>>> should report
> > >> > >>>>>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The
> > >expectation
> > >> > is
> > >> > >>> that
> > >> > >>>>>>>>> +the
> > >> > >>>>>>>>> north bridge or
> > >> > >>>>>>>>> +/// memory controller would publish this PPI.
> > >> > >>>>>>>>> +///
> > >> > >>>>>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
> > >> > >>>>>>>>> + EFI_PEI_MM_OPEN Open;
> > >> > >>>>>>>>> + EFI_PEI_MM_CLOSE Close;
> > >> > >>>>>>>>> + EFI_PEI_MM_LOCK Lock;
> > >> > >>>>>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
> > >> > >>>>>>>>> + BOOLEAN LockState;
> > >> > >>>>>>>>> + BOOLEAN OpenState;
> > >> > >>>>>>>>> +};
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +#endif
> > >> > >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
> > >> > >>>>>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644
> > >> > index
> > >> > >>>>>>>>> 0000000000..983ed95cd5
> > >> > >>>>>>>>> --- /dev/null
> > >> > >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
> > >> > >>>>>>>>> @@ -0,0 +1,90 @@
> > >> > >>>>>>>>> +/** @file
> > >> > >>>>>>>>> + EFI MM Control PPI definition.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + This PPI is used initiate synchronous MMI activations. This
> > >> > >>>>>>>>> + PPI could be
> > >> > >>>>>>>>> published by a processor
> > >> > >>>>>>>>> + driver to abstract the MMI IPI or a driver which abstracts
> > >> > >>>>>>>>> + the ASIC that
> > >> > >>>>>>> is
> > >> > >>>>>>>>> supporting the APM port.
> > >> > >>>>>>>>> + Because of the possibility of performing MMI IPI
> > >> > >>>>>>>>> + transactions, the ability
> > >> > >>>>>>>> to
> > >> > >>>>>>>>> generate this event
> > >> > >>>>>>>>> + from a platform chipset agent is an optional capability for
> > >> > >>>>>>>>> + both
> > >> > >>>>>>>>> + IA-32
> > >> > >>>>>>> and
> > >> > >>>>>>>>> x64-based systems.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> > >> > >>>>>>>>> + reserved.<BR>
> > >> > >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @par Revision Reference:
> > >> > >>>>>>>>> + This PPI is introduced in PI Version 1.5.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +**/
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +#ifndef _MM_CONTROL_PPI_H_
> > >> > >>>>>>>>> +#define _MM_CONTROL_PPI_H_
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
> > >> > >>>>>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5,
> > >> > >>>>>>>>> +0xce, 0x74,
> > >> > >>>>>>>> 0xc5 }
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
> > >> > >>>>>> EFI_PEI_MM_CONTROL_PPI;
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +/**
> > >> > >>>>>>>>> + Invokes PPI activation from the PI PEI environment.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > >> > Services
> > >> > >>>>> Table
> > >> > >>>>>>>>> published by the PEI Foundation.
> > >> > >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI
> > instance.
> > >> > >>>>>>>>> + @param ArgumentBuffer The value passed to the
> > MMI
> > >> > >>> handler.
> > >> > >>>>>>> This
> > >> > >>>>>>>>> value corresponds to the
> > >> > >>>>>>>>> + SwMmiInputValue in the
> > >> > >>>>>>>>> + RegisterContext parameter
> > >> > >>>>>>> for
> > >> > >>>>>>>> the
> > >> > >>>>>>>>> Register()
> > >> > >>>>>>>>> + function in the
> > >> > >>>>>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
> > >> > >>>>>>> and
> > >> > >>>>>>>> in
> > >> > >>>>>>>>> the Context parameter
> > >> > >>>>>>>>> + in the call to the DispatchFunction
> > >> > >>>>>>>>> + @param ArgumentBufferSize The size of the data
> > passed
> > >in
> > >> > >>>>>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> > >> > >>>>>>>>> + @param Periodic An optional mechanism to
> > >periodically
> > >> > >>>>> repeat
> > >> > >>>>>>>>> activation.
> > >> > >>>>>>>>> + @param ActivationInterval An optional parameter to
> > >repeat
> > >> > at
> > >> > >>>>> this
> > >> > >>>>>>>> period
> > >> > >>>>>>>>> one
> > >> > >>>>>>>>> + time or, if the Periodic Boolean is set,
> > >> > periodically.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> > >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
> > >> > >>>>>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
> > >> > >>>>>> unsupported.
> > >> > >>>>>>>>> + @retval EFI_NOT_STARTED The MM base service has
> > not
> > >> > >> been
> > >> > >>>>>>>> initialized.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +**/
> > >> > >>>>>>>>> +typedef
> > >> > >>>>>>>>> +EFI_STATUS
> > >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >> > >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> > >> > >>>>>>>>> + IN OUT INT8 *ArgumentBuffer
> > >OPTIONAL,
> > >> > >>>>>>>>> + IN OUT UINTN *ArgumentBufferSize
> > >> > >>> OPTIONAL,
> > >> > >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL,
> > >> > >>>>>>>>> + IN UINTN ActivationInterval
> > OPTIONAL
> > >> > >>>>>>>>> + );
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +/**
> > >> > >>>>>>>>> + Clears any system state that was created in response to
> > the
> > >> > >>> Trigger()
> > >> > >>>>>> call.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @param PeiServices General purpose services
> > >available
> > >> > to
> > >> > >>>>> every
> > >> > >>>>>>>> PEIM.
> > >> > >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI
> > instance.
> > >> > >>>>>>>>> + @param Periodic Optional parameter to repeat at
> > >this
> > >> > >>>>> period
> > >> > >>>>>>> one
> > >> > >>>>>>>>> + time or, if the Periodic Boolean is set,
> > >> > periodically.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> > >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR The source could not be
> > >> > cleared.
> > >> > >>>>>>>>> + @retval EFI_INVALID_PARAMETER The service did not
> > >support
> > >> > >>>>>>>>> + the
> > >> > >>>>>>>> Periodic
> > >> > >>>>>>>>> input argument.
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +**/
> > >> > >>>>>>>>> +typedef
> > >> > >>>>>>>>> +EFI_STATUS
> > >> > >>>>>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
> > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > >> > >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> > >> > >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL
> > >> > >>>>>>>>> + );
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +///
> > >> > >>>>>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM.
> > >It
> > >> > >>>>>> provides
> > >> > >>>>>>> an
> > >> > >>>>>>>>> abstraction of the
> > >> > >>>>>>>>> +/// platform hardware that generates an MMI. There are
> > >often
> > >> > >>>>>>>>> +I/O ports
> > >> > >>>>>>>>> that, when accessed, will
> > >> > >>>>>>>>> +/// generate the MMI. Also, the hardware optionally
> > >supports
> > >> > >>>>>>>>> +the
> > >> > >>>>>>> periodic
> > >> > >>>>>>>>> generation of these signals.
> > >> > >>>>>>>>> +///
> > >> > >>>>>>>>> +struct _PEI_MM_CONTROL_PPI {
> > >> > >>>>>>>>> + PEI_MM_ACTIVATE Trigger;
> > >> > >>>>>>>>> + PEI_MM_DEACTIVATE Clear;
> > >> > >>>>>>>>> +};
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> +#endif
> > >> > >>>>>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > >index
> > >> > >>>>>>>>> b382efd578..34e0f39395 100644
> > >> > >>>>>>>>> --- a/MdePkg/MdePkg.dec
> > >> > >>>>>>>>> +++ b/MdePkg/MdePkg.dec
> > >> > >>>>>>>>> @@ -925,6 +925,12 @@
> > >> > >>>>>>>>> ## Include/Ppi/SecHobData.h
> > >> > >>>>>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8,
> > >{0xb4,
> > >> > >>>>>>>>> 0xee,
> > >> > >>>>>>> 0xf5,
> > >> > >>>>>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> > >> > >>>>>>>>>
> > >> > >>>>>>>>> + ## Include/Ppi/MmAccess.h
> > >> > >>>>>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd,
> > >0x48be,
> > >> > >>>>> { 0x88,
> > >> > >>>>>>>> 0x17,
> > >> > >>>>>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> + ## Include/Ppi/MmControl.h
> > >> > >>>>>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e,
> > >0x4f43,
> > >> > >>>>> { 0x8d,
> > >> > >>>>>>>> 0xef,
> > >> > >>>>>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> > >> > >>>>>>>>> +
> > >> > >>>>>>>>> #
> > >> > >>>>>>>>> # PPIs defined in PI 1.7.
> > >> > >>>>>>>>> #
> > >> > >>>>>>>>> --
> > >> > >>>>>>>>> 2.16.2.windows.1
> > >> > >>>>>>>>>
> > >> > >>>>>>>>>
> > >> > >>>>>>>>>
> > >> > >>>>
> > >> > >>>>
> > >> > >>>>
> > >> > >>>>
> > >> > >>>
> > >> > >>>
> > >> > >>>
> > >> > >
> > >> >
> > >> >
> > >> >
> > >
> > >
> > >
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
2019-08-14 9:53 ` Marc W Chen
2019-08-18 5:20 ` Ni, Ray
@ 2019-08-18 5:21 ` Ni, Ray
1 sibling, 0 replies; 18+ messages in thread
From: Ni, Ray @ 2019-08-18 5:21 UTC (permalink / raw)
To: Chen, Marc W, Gao, Liming, devel@edk2.groups.io,
lersek@redhat.com
Cc: Kinney, Michael D
Marc,
Thanks for your contribution! It's a big step already to have the header files in MdePkg.
Thanks,
Ray
> -----Original Message-----
> From: Ni, Ray
> Sent: Sunday, August 18, 2019 1:20 PM
> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io;
> lersek@redhat.com
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
>
> I don't have strong preference on removing SmmAccess.h from MdeModulePkg.
> If people except me all agreed to keep that header file for compatibility, I am ok.
>
> > -----Original Message-----
> > From: Chen, Marc W
> > Sent: Wednesday, August 14, 2019 5:54 PM
> > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; lersek@redhat.com; Ni, Ray <ray.ni@intel.com>
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.
> >
> > Thanks Liming for pushing the code.
> >
> > Can we have a conclusion for the SmmAccess.h removal from MdeModulePkg? Who can make the decision? Or do we need
> any
> > further discussion?
> >
> > Thanks,
> > Marc
> >
> > > -----Original Message-----
> > > From: Gao, Liming
> > > Sent: Tuesday, August 13, 2019 5:20 PM
> > > To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Chen, Marc
> > > W <marc.w.chen@intel.com>; lersek@redhat.com; Ni, Ray
> > > <ray.ni@intel.com>
> > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > > Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> > > definition.
> > >
> > > Push @6f33f7a262314af35e2b99c849e08928ea49aa55
> > >
> > > >-----Original Message-----
> > > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > > >Liming Gao
> > > >Sent: Saturday, August 10, 2019 11:34 AM
> > > >To: Chen, Marc W <marc.w.chen@intel.com>; devel@edk2.groups.io;
> > > >lersek@redhat.com; Ni, Ray <ray.ni@intel.com>
> > > >Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > > >Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> > > >definition.
> > > >
> > > >I agree. The patch to add them in MdePkg is clear. I will push it next Monday.
> > > >
> > > >Thanks
> > > >Liming
> > > >> -----Original Message-----
> > > >> From: Chen, Marc W
> > > >> Sent: Saturday, August 10, 2019 11:33 AM
> > > >> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray
> > > <ray.ni@intel.com>;
> > > >Gao, Liming <liming.gao@intel.com>
> > > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > > >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > > MmControl
> > > >definition.
> > > >>
> > > >> Hi Liming
> > > >>
> > > >> Since the SmmAccess.h of MdeModulePkg removal is still under discussion,
> > > >can we push the MmAccess.h and MmControl.h to MdePkg
> > > >> first? I have other tasks pending by this.
> > > >> We can keep discussing the SmmAccess after push the code.
> > > >>
> > > >> Thanks,
> > > >> Marc
> > > >>
> > > >> > -----Original Message-----
> > > >> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > > Laszlo
> > > >> > Ersek
> > > >> > Sent: Thursday, August 8, 2019 12:11 AM
> > > >> > To: Ni, Ray <ray.ni@intel.com>; Chen, Marc W
> > > <marc.w.chen@intel.com>;
> > > >> > devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> > > >> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > > >> > Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > > >MmControl
> > > >> > definition.
> > > >> >
> > > >> > On 08/06/19 12:08, Ni, Ray wrote:
> > > >> > > Laszlo,
> > > >> > > Do you want to avoid touching the OvmfPkg due the file removal in
> > > >> > MdeModulePkg?
> > > >> >
> > > >> > My main problem with this *specific* update proposal is that the
> > > >> > identifiers (type names and such) that would be subject to removal were
> > > >> > publicly specified in earlier PI spec releases.
> > > >> >
> > > >> > I don't suggest that we maintain two parallel sets of typedefs and such
> > > >> > in edk2. It's fine to keep the new "MM" nomenclature the main one. But
> > > >> > we should keep the "SMM" set of terms too, as a thin wrapper, if that's
> > > >> > technically feasible.
> > > >> >
> > > >> > If we remove "SMM", that will not only affect OvmfPkg unpleasantly, but
> > > >> > a bunch of other, out-of-tree code. And the reason I suddenly care
> > > about
> > > >> > out-of-tree code is that such code was written against a public industry
> > > >> > spec (= earlier versions of the PI spec).
> > > >> >
> > > >> > I don't think that the simplicity that would come from removing "SMM"
> > > >> > altogether, is well-balanced against the pain that it would cause for
> > > >> > platforms.
> > > >> >
> > > >> > Earlier this was solved in the following commits:
> > > >> > - 07c6a47e70ba ("MdePkg: Add new definitions for Management
> > > Mode.",
> > > >> > 2017-08-29)
> > > >> > - 2f208e59e4b9 ("MdePkg: Reference new definitions for Management
> > > >> > Mode.", 2017-08-29)
> > > >> >
> > > >> > Thanks
> > > >> > Laszlo
> > > >> >
> > > >> > > I prefer to remove the files in MdeModulePkg to avoid future
> > > confusion.
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Ray
> > > >> > >
> > > >> > >> -----Original Message-----
> > > >> > >> From: Chen, Marc W
> > > >> > >> Sent: Tuesday, August 6, 2019 4:57 PM
> > > >> > >> To: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray
> > > >> > <ray.ni@intel.com>;
> > > >> > >> Gao, Liming <liming.gao@intel.com>
> > > >> > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > > >> > >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > > >> > MmControl
> > > >> > >> definition.
> > > >> > >>
> > > >> > >> Hi Liming and Ray
> > > >> > >>
> > > >> > >> Do you also agree?
> > > >> > >>
> > > >> > >> Thanks,
> > > >> > >> Marc
> > > >> > >>
> > > >> > >>> -----Original Message-----
> > > >> > >>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > > >> > Laszlo
> > > >> > >>> Ersek
> > > >> > >>> Sent: Friday, August 2, 2019 10:14 AM
> > > >> > >>> To: devel@edk2.groups.io; Chen, Marc W
> > > <marc.w.chen@intel.com>;
> > > >Ni,
> > > >> > >>> Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > >> > >>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > > >> > >>> Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > > >> > >> MmControl
> > > >> > >>> definition.
> > > >> > >>>
> > > >> > >>> On 08/01/19 12:15, Marc W Chen wrote:
> > > >> > >>>> Yes, my purpose is to avoid platform code update if the package is
> > > >> > >>>> allowed
> > > >> > >>> to use MdeModulePkg like OvmfPkg.
> > > >> > >>>> For those packages that cannot depend on MdeModulePkg must
> > > >> > change
> > > >> > >> to
> > > >> > >>> use new definition.
> > > >> > >>>
> > > >> > >>> Agreed.
> > > >> > >>>
> > > >> > >>> Thanks!
> > > >> > >>> Laszlo
> > > >> > >>>
> > > >> > >>>>> -----Original Message-----
> > > >> > >>>>> From: Ni, Ray
> > > >> > >>>>> Sent: Thursday, August 1, 2019 6:04 PM
> > > >> > >>>>> To: Chen, Marc W <marc.w.chen@intel.com>; Gao, Liming
> > > >> > >>>>> <liming.gao@intel.com>; devel@edk2.groups.io
> > > >> > >>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> > > >> > >>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > > >> > >>> MmControl
> > > >> > >>>>> definition.
> > > >> > >>>>>
> > > >> > >>>>> Marc,
> > > >> > >>>>> Is the purpose to avoid platform code update with the wrapper
> > > >> > >>>>> header
> > > >> > >>> file in
> > > >> > >>>>> MdeModulePkg?
> > > >> > >>>>> Certain platforms they may require to not depend on
> > > >MdeModulePkg
> > > >> > >>>>> but just depend on MdePkg.
> > > >> > >>>>> Having SmmAccess.h in MdeModulePkg doesn't help.
> > > >> > >>>>>
> > > >> > >>>>> It also bring confusing.
> > > >> > >>>>>
> > > >> > >>>>> Thanks,
> > > >> > >>>>> Ray
> > > >> > >>>>>
> > > >> > >>>>>> -----Original Message-----
> > > >> > >>>>>> From: Chen, Marc W
> > > >> > >>>>>> Sent: Thursday, August 1, 2019 4:53 PM
> > > >> > >>>>>> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io
> > > >> > >>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > > >> > >>>>>> <ray.ni@intel.com>
> > > >> > >>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > > >> > >>> MmControl
> > > >> > >>>>>> definition.
> > > >> > >>>>>>
> > > >> > >>>>>> Hi Liming
> > > >> > >>>>>>
> > > >> > >>>>>> Another thought, do you think it is ok to keep SmmAccess.h in
> > > >> > >>>>>> MdeModulePkg? We can use #define and typedef to convert
> > > >> > >> MmAccess
> > > >> > >>> to
> > > >> > >>>>>> SmmAccess, just like current SmmAccess Protocol in MdePkg.
> > > >> > >>>>>>
> > > >> > >>>>>> Thanks,
> > > >> > >>>>>> Marc
> > > >> > >>>>>>
> > > >> > >>>>>>> -----Original Message-----
> > > >> > >>>>>>> From: Chen, Marc W
> > > >> > >>>>>>> Sent: Thursday, August 1, 2019 4:48 PM
> > > >> > >>>>>>> To: Gao, Liming <liming.gao@intel.com>;
> > > devel@edk2.groups.io
> > > >> > >>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > > >> > >>>>>>> <ray.ni@intel.com>
> > > >> > >>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > > >> > >>>>>> MmControl
> > > >> > >>>>>>> definition.
> > > >> > >>>>>>>
> > > >> > >>>>>>> Hi Liming
> > > >> > >>>>>>>
> > > >> > >>>>>>> Since there are multiple packages are still using SmmAccess.h,
> > > >we
> > > >> > >>>>>>> need to change all packages to use MmAccess.h instead of
> > > >> > >>>>>>> SmmAccess.h first, then clean up SmmAccess.h from
> > > >> > MdeModulePkg
> > > >> > >> will be the last step.
> > > >> > >>>>>>> Below are the packages that has "include <Ppi/SmmAccess.h>"
> > > >for
> > > >> > >>>>>>> your reference.
> > > >> > >>>>>>> * Edk2 repo:
> > > >> > >>>>>>> o MdeModulePkg
> > > >> > >>>>>>> o OvmfPkg
> > > >> > >>>>>>> o UefiCpuPkg
> > > >> > >>>>>>> * Edk2Platform repo:
> > > >> > >>>>>>> o MinPlatformPkg
> > > >> > >>>>>>> o QuarkSocPkg
> > > >> > >>>>>>>
> > > >> > >>>>>>> Thanks,
> > > >> > >>>>>>> Marc
> > > >> > >>>>>>>
> > > >> > >>>>>>>> -----Original Message-----
> > > >> > >>>>>>>> From: Gao, Liming
> > > >> > >>>>>>>> Sent: Thursday, August 1, 2019 4:42 PM
> > > >> > >>>>>>>> To: devel@edk2.groups.io; Chen, Marc W
> > > >> > <marc.w.chen@intel.com>
> > > >> > >>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
> > > >> > >>>>>>>> <ray.ni@intel.com>
> > > >> > >>>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess
> > > >and
> > > >> > >>>>>> MmControl
> > > >> > >>>>>>>> definition.
> > > >> > >>>>>>>>
> > > >> > >>>>>>>> Marc:
> > > >> > >>>>>>>> The change is good. Reviewed-by: Liming Gao
> > > >> > >>> <liming.gao@intel.com>
> > > >> > >>>>>>>>
> > > >> > >>>>>>>> Besides, I see BZ also mention to remove the one in
> > > >> > >> MdeModulePkg.
> > > >> > >>>>>>>> Have you the following patches for the change in
> > > >MdeModulePkg?
> > > >> > >>>>>>>>
> > > >> > >>>>>>>> Thanks
> > > >> > >>>>>>>> Liming
> > > >> > >>>>>>>>> -----Original Message-----
> > > >> > >>>>>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> > > >On
> > > >> > >>>>> Behalf
> > > >> > >>>>>>>>> Of Marc W Chen
> > > >> > >>>>>>>>> Sent: Monday, July 29, 2019 12:26 PM
> > > >> > >>>>>>>>> To: devel@edk2.groups.io
> > > >> > >>>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao,
> > > >> > Liming
> > > >> > >>>>>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> > > >> > >>>>>>>>> Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> > > >> > >>>>> MmControl
> > > >> > >>>>>>>>> definition.
> > > >> > >>>>>>>>>
> > > >> > >>>>>>>>> EFI MmAccess and MmControl PPIs are defined in the PI 1.5
> > > >> > >>>>>> specification.
> > > >> > >>>>>>>>>
> > > >> > >>>>>>>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > > >> > >>>>>>>>> Cc: Liming Gao <liming.gao@intel.com>
> > > >> > >>>>>>>>> Cc: Ray Ni <ray.ni@intel.com>
> > > >> > >>>>>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
> > > >> > >>>>>>>>> Signed-off-by: Marc W Chen <marc.w.chen@intel.com>
> > > >> > >>>>>>>>> ---
> > > >> > >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h | 155
> > > >> > >>>>>>>>> +++++++++++++++++++++++++++++++++++++++++
> > > >> > >>>>>>>>> MdePkg/Include/Ppi/MmControl.h | 90
> > > >> > >>>>>> ++++++++++++++++++++++++
> > > >> > >>>>>>>>> MdePkg/MdePkg.dec | 6 ++
> > > >> > >>>>>>>>> 3 files changed, 251 insertions(+) create mode 100644
> > > >> > >>>>>>>>> MdePkg/Include/Ppi/MmAccess.h create mode 100644
> > > >> > >>>>>>>>> MdePkg/Include/Ppi/MmControl.h
> > > >> > >>>>>>>>>
> > > >> > >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmAccess.h
> > > >> > >>>>>>>>> b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644
> > > >> > index
> > > >> > >>>>>>>>> 0000000000..636e7288a0
> > > >> > >>>>>>>>> --- /dev/null
> > > >> > >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmAccess.h
> > > >> > >>>>>>>>> @@ -0,0 +1,155 @@
> > > >> > >>>>>>>>> +/** @file
> > > >> > >>>>>>>>> + EFI MM Access PPI definition.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + This PPI is used to control the visibility of the MMRAM on
> > > >> > >>>>>>>>> + the
> > > >> > >>>>>> platform.
> > > >> > >>>>>>>>> + The EFI_PEI_MM_ACCESS_PPI abstracts the location and
> > > >> > >>>>>>>>> + characteristics
> > > >> > >>>>>>> of
> > > >> > >>>>>>>>> MMRAM. The
> > > >> > >>>>>>>>> + principal functionality found in the memory controller
> > > >> > >>>>>>>>> + includes the
> > > >> > >>>>>>>> following:
> > > >> > >>>>>>>>> + - Exposing the MMRAM to all non-MM agents, or the
> > > >"open"
> > > >> > >>>>>>>>> + state
> > > >> > >>>>>>>>> + - Shrouding the MMRAM to all but the MM agents, or the
> > > >> > >> "closed"
> > > >> > >>>>>>>>> + state
> > > >> > >>>>>>>>> + - Preserving the system integrity, or "locking" the MMRAM,
> > > >> > >>>>>>>>> + such that
> > > >> > >>>>>>> the
> > > >> > >>>>>>>>> settings cannot be
> > > >> > >>>>>>>>> + perturbed by either boot service or runtime agents
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> > > >> > >>>>>>>>> + reserved.<BR>
> > > >> > >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @par Revision Reference:
> > > >> > >>>>>>>>> + This PPI is introduced in PI Version 1.5.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +**/
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +#ifndef _MM_ACCESS_PPI_H_
> > > >> > >>>>>>>>> +#define _MM_ACCESS_PPI_H_
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +#define EFI_PEI_MM_ACCESS_PPI_GUID \
> > > >> > >>>>>>>>> + { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
> > > >> > >>>>>>>>> +0xc3, 0x2e,
> > > >> > >>>>>>>>> 0xd6 }}
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +typedef struct _EFI_PEI_MM_ACCESS_PPI
> > > >> > >> EFI_PEI_MM_ACCESS_PPI;
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +/**
> > > >> > >>>>>>>>> + Opens the MMRAM area to be accessible by a PEIM.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + This function "opens" MMRAM so that it is visible while
> > > not
> > > >> > >>>>>>>>> + inside of
> > > >> > >>>>>>> MM.
> > > >> > >>>>>>>>> The function should
> > > >> > >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not
> > > >support
> > > >> > >>>>>>>>> + hiding of
> > > >> > >>>>>>>>> MMRAM. The function
> > > >> > >>>>>>>>> + should return EFI_DEVICE_ERROR if the MMRAM
> > > >> > configuration
> > > >> > >> is
> > > >> > >>>>>> locked.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > > >> > Services
> > > >> > >>>>>> Table
> > > >> > >>>>>>>>> published by the PEI Foundation.
> > > >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> > > >instance.
> > > >> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
> > > >Open.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> > > >> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
> > > >support
> > > >> > >>>>> opening
> > > >> > >>>>>>>> and
> > > >> > >>>>>>>>> closing of MMRAM.
> > > >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be
> > > opened,
> > > >> > >>>>> perhaps
> > > >> > >>>>>>>>> because it is locked.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +**/
> > > >> > >>>>>>>>> +typedef
> > > >> > >>>>>>>>> +EFI_STATUS
> > > >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_OPEN)(
> > > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > > >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > > >> > >>>>>>>>> + IN UINTN DescriptorIndex
> > > >> > >>>>>>>>> + );
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +/**
> > > >> > >>>>>>>>> + Inhibits access to the MMRAM.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + This function "closes" MMRAM so that it is not visible
> > > while
> > > >> > >>>>>>>>> + outside of
> > > >> > >>>>>>>> MM.
> > > >> > >>>>>>>>> The function should
> > > >> > >>>>>>>>> + return EFI_UNSUPPORTED if the hardware does not
> > > >support
> > > >> > >>>>>>>>> + hiding of
> > > >> > >>>>>>>>> MMRAM.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > > >> > Services
> > > >> > >>>>>> Table
> > > >> > >>>>>>>>> published by the PEI Foundation.
> > > >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> > > >instance.
> > > >> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
> > > >Close.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> > > >> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
> > > >support
> > > >> > >>>>> opening
> > > >> > >>>>>>>> and
> > > >> > >>>>>>>>> closing of MMRAM.
> > > >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +**/
> > > >> > >>>>>>>>> +typedef
> > > >> > >>>>>>>>> +EFI_STATUS
> > > >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CLOSE)(
> > > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > > >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > > >> > >>>>>>>>> + IN UINTN DescriptorIndex
> > > >> > >>>>>>>>> + );
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +/**
> > > >> > >>>>>>>>> + This function prohibits access to the MMRAM region. This
> > > >> > >>>>>>>>> +function is
> > > >> > >>>>>>>> usually
> > > >> > >>>>>>>>> implemented such
> > > >> > >>>>>>>>> + that it is a write-once operation.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > > >> > Services
> > > >> > >>>>>> Table
> > > >> > >>>>>>>>> published by the PEI Foundation.
> > > >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> > > >instance.
> > > >> > >>>>>>>>> + @param DescriptorIndex The region of MMRAM to
> > > >Lock.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @retval EFI_SUCCESS The operation was successful.
> > > >> > >>>>>>>>> + @retval EFI_UNSUPPORTED The system does not
> > > >support
> > > >> > >>>>> opening
> > > >> > >>>>>>>> and
> > > >> > >>>>>>>>> closing of MMRAM.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +**/
> > > >> > >>>>>>>>> +typedef
> > > >> > >>>>>>>>> +EFI_STATUS
> > > >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_LOCK)(
> > > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > > >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > > >> > >>>>>>>>> + IN UINTN DescriptorIndex
> > > >> > >>>>>>>>> + );
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +/**
> > > >> > >>>>>>>>> + Queries the memory controller for the possible regions
> > > that
> > > >> > >>>>>>>>> +will support
> > > >> > >>>>>>>>> MMRAM.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + This function describes the MMRAM regions.
> > > >> > >>>>>>>>> + This data structure forms the contract between the
> > > >> > >> MM_ACCESS
> > > >> > >>>>> and
> > > >> > >>>>>>>>> MM_IPL drivers. There is an
> > > >> > >>>>>>>>> + ambiguity when any MMRAM region is remapped. For
> > > >> > example,
> > > >> > >> on
> > > >> > >>>>>>> some
> > > >> > >>>>>>>>> chipsets, some MMRAM
> > > >> > >>>>>>>>> + regions can be initialized at one physical address but is
> > > >> > >>>>>>>>> + later accessed at
> > > >> > >>>>>>>>> another processor address.
> > > >> > >>>>>>>>> + There is currently no way for the MM IPL driver to know
> > > >that
> > > >> > >>>>>>>>> + it must use
> > > >> > >>>>>>>>> two different addresses
> > > >> > >>>>>>>>> + depending on what it is trying to do. As a result, initial
> > > >> > >>>>>>>>> + configuration and
> > > >> > >>>>>>>>> loading can use the
> > > >> > >>>>>>>>> + physical address PhysicalStart while MMRAM is open.
> > > >> > However,
> > > >> > >>>>>>>>> + once
> > > >> > >>>>>>> the
> > > >> > >>>>>>>>> region has been
> > > >> > >>>>>>>>> + closed and needs to be accessed by agents in MM, the
> > > >> > >>>>>>>>> + CpuStart address
> > > >> > >>>>>>>>> must be used.
> > > >> > >>>>>>>>> + This PPI publishes the available memory that the chipset
> > > >can
> > > >> > >>>>>>>>> + shroud for
> > > >> > >>>>>>>> the
> > > >> > >>>>>>>>> use of installing code.
> > > >> > >>>>>>>>> + These regions serve the dual purpose of describing which
> > > >> > >>>>>>>>> + regions have
> > > >> > >>>>>>>>> been open, closed, or locked.
> > > >> > >>>>>>>>> + In addition, these regions may include overlapping
> > > memory
> > > >> > >>>>>>>>> + ranges,
> > > >> > >>>>>>>>> depending on the chipset
> > > >> > >>>>>>>>> + implementation. The latter might include a chipset that
> > > >> > >>>>>>>>> + supports T-SEG,
> > > >> > >>>>>>>>> where memory near the top
> > > >> > >>>>>>>>> + of the physical DRAM can be allocated for MMRAM too.
> > > >> > >>>>>>>>> + The key thing to note is that the regions that are described
> > > >> > >>>>>>>>> + by the PPI
> > > >> > >>>>>>> are
> > > >> > >>>>>>>> a
> > > >> > >>>>>>>>> subset of the capabilities
> > > >> > >>>>>>>>> + of the hardware.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > > >> > Services
> > > >> > >>>>>> Table
> > > >> > >>>>>>>>> published by the PEI Foundation.
> > > >> > >>>>>>>>> + @param This The EFI_PEI_MM_ACCESS_PPI
> > > >instance.
> > > >> > >>>>>>>>> + @param MmramMapSize A pointer to the size, in
> > > >bytes,
> > > >> > of
> > > >> > >>>>> the
> > > >> > >>>>>>>>> MmramMemoryMap buffer. On input, this value is
> > > >> > >>>>>>>>> + the size of the buffer that
> > > >> > >>>>>>>>> + is allocated by the caller. On
> > > >> > >>>>>>>>> output, it is the size of the
> > > >> > >>>>>>>>> + buffer that was returned by
> > > >> > >>>>>>>>> + the firmware if the buffer
> > > >> > >>>>>>>> was
> > > >> > >>>>>>>>> large enough, or, if the
> > > >> > >>>>>>>>> + buffer was too small, the
> > > >> > >>>>>>>>> + size of the buffer that is
> > > >> > >>>>>>>> needed to
> > > >> > >>>>>>>>> contain the map.
> > > >> > >>>>>>>>> + @param MmramMap A pointer to the buffer in
> > > >which
> > > >> > >>>>>> firmware
> > > >> > >>>>>>>>> places the current memory map. The map is
> > > >> > >>>>>>>>> + an array of
> > > >> > >>>>>>>>> + EFI_MMRAM_DESCRIPTORs
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @retval EFI_SUCCESS The chipset supported the
> > > given
> > > >> > >>>>> resource.
> > > >> > >>>>>>>>> + @retval EFI_BUFFER_TOO_SMALL The MmramMap
> > > >> > parameter
> > > >> > >>> was
> > > >> > >>>>>> too
> > > >> > >>>>>>>>> small. The current
> > > >> > >>>>>>>>> + buffer size needed to hold
> > > >> > >>>>>>>>> + the memory map is
> > > >> > >>>>>>> returned
> > > >> > >>>>>>>> in
> > > >> > >>>>>>>>> + MmramMapSize.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +**/
> > > >> > >>>>>>>>> +typedef
> > > >> > >>>>>>>>> +EFI_STATUS
> > > >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
> > > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > > >> > >>>>>>>>> + IN EFI_PEI_MM_ACCESS_PPI *This,
> > > >> > >>>>>>>>> + IN OUT UINTN *MmramMapSize,
> > > >> > >>>>>>>>> + IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
> > > >> > >>>>>>>>> + );
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +///
> > > >> > >>>>>>>>> +/// EFI MM Access PPI is used to control the visibility of
> > > >> > >>>>>>>>> +the MMRAM on
> > > >> > >>>>>>>> the
> > > >> > >>>>>>>>> platform.
> > > >> > >>>>>>>>> +/// It abstracts the location and characteristics of MMRAM.
> > > >> > >>>>>>>>> +The platform
> > > >> > >>>>>>>>> should report
> > > >> > >>>>>>>>> +/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The
> > > >expectation
> > > >> > is
> > > >> > >>> that
> > > >> > >>>>>>>>> +the
> > > >> > >>>>>>>>> north bridge or
> > > >> > >>>>>>>>> +/// memory controller would publish this PPI.
> > > >> > >>>>>>>>> +///
> > > >> > >>>>>>>>> +struct _EFI_PEI_MM_ACCESS_PPI {
> > > >> > >>>>>>>>> + EFI_PEI_MM_OPEN Open;
> > > >> > >>>>>>>>> + EFI_PEI_MM_CLOSE Close;
> > > >> > >>>>>>>>> + EFI_PEI_MM_LOCK Lock;
> > > >> > >>>>>>>>> + EFI_PEI_MM_CAPABILITIES GetCapabilities;
> > > >> > >>>>>>>>> + BOOLEAN LockState;
> > > >> > >>>>>>>>> + BOOLEAN OpenState;
> > > >> > >>>>>>>>> +};
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +extern EFI_GUID gEfiPeiMmAccessPpiGuid;
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +#endif
> > > >> > >>>>>>>>> diff --git a/MdePkg/Include/Ppi/MmControl.h
> > > >> > >>>>>>>>> b/MdePkg/Include/Ppi/MmControl.h new file mode 100644
> > > >> > index
> > > >> > >>>>>>>>> 0000000000..983ed95cd5
> > > >> > >>>>>>>>> --- /dev/null
> > > >> > >>>>>>>>> +++ b/MdePkg/Include/Ppi/MmControl.h
> > > >> > >>>>>>>>> @@ -0,0 +1,90 @@
> > > >> > >>>>>>>>> +/** @file
> > > >> > >>>>>>>>> + EFI MM Control PPI definition.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + This PPI is used initiate synchronous MMI activations. This
> > > >> > >>>>>>>>> + PPI could be
> > > >> > >>>>>>>>> published by a processor
> > > >> > >>>>>>>>> + driver to abstract the MMI IPI or a driver which abstracts
> > > >> > >>>>>>>>> + the ASIC that
> > > >> > >>>>>>> is
> > > >> > >>>>>>>>> supporting the APM port.
> > > >> > >>>>>>>>> + Because of the possibility of performing MMI IPI
> > > >> > >>>>>>>>> + transactions, the ability
> > > >> > >>>>>>>> to
> > > >> > >>>>>>>>> generate this event
> > > >> > >>>>>>>>> + from a platform chipset agent is an optional capability for
> > > >> > >>>>>>>>> + both
> > > >> > >>>>>>>>> + IA-32
> > > >> > >>>>>>> and
> > > >> > >>>>>>>>> x64-based systems.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + Copyright (c) 2019, Intel Corporation. All rights
> > > >> > >>>>>>>>> + reserved.<BR>
> > > >> > >>>>>>>>> + SPDX-License-Identifier: BSD-2-Clause-Patent
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @par Revision Reference:
> > > >> > >>>>>>>>> + This PPI is introduced in PI Version 1.5.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +**/
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +#ifndef _MM_CONTROL_PPI_H_
> > > >> > >>>>>>>>> +#define _MM_CONTROL_PPI_H_
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +#define EFI_PEI_MM_CONTROL_PPI_GUID \
> > > >> > >>>>>>>>> + { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5,
> > > >> > >>>>>>>>> +0xce, 0x74,
> > > >> > >>>>>>>> 0xc5 }
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +typedef struct _EFI_PEI_MM_CONTROL_PPI
> > > >> > >>>>>> EFI_PEI_MM_CONTROL_PPI;
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +/**
> > > >> > >>>>>>>>> + Invokes PPI activation from the PI PEI environment.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @param PeiServices An indirect pointer to the PEI
> > > >> > Services
> > > >> > >>>>> Table
> > > >> > >>>>>>>>> published by the PEI Foundation.
> > > >> > >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI
> > > instance.
> > > >> > >>>>>>>>> + @param ArgumentBuffer The value passed to the
> > > MMI
> > > >> > >>> handler.
> > > >> > >>>>>>> This
> > > >> > >>>>>>>>> value corresponds to the
> > > >> > >>>>>>>>> + SwMmiInputValue in the
> > > >> > >>>>>>>>> + RegisterContext parameter
> > > >> > >>>>>>> for
> > > >> > >>>>>>>> the
> > > >> > >>>>>>>>> Register()
> > > >> > >>>>>>>>> + function in the
> > > >> > >>>>>>>>> + EFI_MM_SW_DISPATCH_PROTOCOL
> > > >> > >>>>>>> and
> > > >> > >>>>>>>> in
> > > >> > >>>>>>>>> the Context parameter
> > > >> > >>>>>>>>> + in the call to the DispatchFunction
> > > >> > >>>>>>>>> + @param ArgumentBufferSize The size of the data
> > > passed
> > > >in
> > > >> > >>>>>>>>> ArgumentBuffer or NULL if ArgumentBuffer is NULL.
> > > >> > >>>>>>>>> + @param Periodic An optional mechanism to
> > > >periodically
> > > >> > >>>>> repeat
> > > >> > >>>>>>>>> activation.
> > > >> > >>>>>>>>> + @param ActivationInterval An optional parameter to
> > > >repeat
> > > >> > at
> > > >> > >>>>> this
> > > >> > >>>>>>>> period
> > > >> > >>>>>>>>> one
> > > >> > >>>>>>>>> + time or, if the Periodic Boolean is set,
> > > >> > periodically.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> > > >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR The timing is unsupported.
> > > >> > >>>>>>>>> + @retval EFI_INVALID_PARAMETER The activation period is
> > > >> > >>>>>> unsupported.
> > > >> > >>>>>>>>> + @retval EFI_NOT_STARTED The MM base service has
> > > not
> > > >> > >> been
> > > >> > >>>>>>>> initialized.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +**/
> > > >> > >>>>>>>>> +typedef
> > > >> > >>>>>>>>> +EFI_STATUS
> > > >> > >>>>>>>>> +(EFIAPI *EFI_PEI_MM_ACTIVATE) (
> > > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > > >> > >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> > > >> > >>>>>>>>> + IN OUT INT8 *ArgumentBuffer
> > > >OPTIONAL,
> > > >> > >>>>>>>>> + IN OUT UINTN *ArgumentBufferSize
> > > >> > >>> OPTIONAL,
> > > >> > >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL,
> > > >> > >>>>>>>>> + IN UINTN ActivationInterval
> > > OPTIONAL
> > > >> > >>>>>>>>> + );
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +/**
> > > >> > >>>>>>>>> + Clears any system state that was created in response to
> > > the
> > > >> > >>> Trigger()
> > > >> > >>>>>> call.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @param PeiServices General purpose services
> > > >available
> > > >> > to
> > > >> > >>>>> every
> > > >> > >>>>>>>> PEIM.
> > > >> > >>>>>>>>> + @param This The PEI_MM_CONTROL_PPI
> > > instance.
> > > >> > >>>>>>>>> + @param Periodic Optional parameter to repeat at
> > > >this
> > > >> > >>>>> period
> > > >> > >>>>>>> one
> > > >> > >>>>>>>>> + time or, if the Periodic Boolean is set,
> > > >> > periodically.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + @retval EFI_SUCCESS The MMI has been engendered.
> > > >> > >>>>>>>>> + @retval EFI_DEVICE_ERROR The source could not be
> > > >> > cleared.
> > > >> > >>>>>>>>> + @retval EFI_INVALID_PARAMETER The service did not
> > > >support
> > > >> > >>>>>>>>> + the
> > > >> > >>>>>>>> Periodic
> > > >> > >>>>>>>>> input argument.
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +**/
> > > >> > >>>>>>>>> +typedef
> > > >> > >>>>>>>>> +EFI_STATUS
> > > >> > >>>>>>>>> +(EFIAPI *PEI_MM_DEACTIVATE) (
> > > >> > >>>>>>>>> + IN EFI_PEI_SERVICES **PeiServices,
> > > >> > >>>>>>>>> + IN EFI_PEI_MM_CONTROL_PPI * This,
> > > >> > >>>>>>>>> + IN BOOLEAN Periodic OPTIONAL
> > > >> > >>>>>>>>> + );
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +///
> > > >> > >>>>>>>>> +/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM.
> > > >It
> > > >> > >>>>>> provides
> > > >> > >>>>>>> an
> > > >> > >>>>>>>>> abstraction of the
> > > >> > >>>>>>>>> +/// platform hardware that generates an MMI. There are
> > > >often
> > > >> > >>>>>>>>> +I/O ports
> > > >> > >>>>>>>>> that, when accessed, will
> > > >> > >>>>>>>>> +/// generate the MMI. Also, the hardware optionally
> > > >supports
> > > >> > >>>>>>>>> +the
> > > >> > >>>>>>> periodic
> > > >> > >>>>>>>>> generation of these signals.
> > > >> > >>>>>>>>> +///
> > > >> > >>>>>>>>> +struct _PEI_MM_CONTROL_PPI {
> > > >> > >>>>>>>>> + PEI_MM_ACTIVATE Trigger;
> > > >> > >>>>>>>>> + PEI_MM_DEACTIVATE Clear;
> > > >> > >>>>>>>>> +};
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +extern EFI_GUID gEfiPeiMmControlPpiGuid;
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> +#endif
> > > >> > >>>>>>>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > > >index
> > > >> > >>>>>>>>> b382efd578..34e0f39395 100644
> > > >> > >>>>>>>>> --- a/MdePkg/MdePkg.dec
> > > >> > >>>>>>>>> +++ b/MdePkg/MdePkg.dec
> > > >> > >>>>>>>>> @@ -925,6 +925,12 @@
> > > >> > >>>>>>>>> ## Include/Ppi/SecHobData.h
> > > >> > >>>>>>>>> gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8,
> > > >{0xb4,
> > > >> > >>>>>>>>> 0xee,
> > > >> > >>>>>>> 0xf5,
> > > >> > >>>>>>>>> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
> > > >> > >>>>>>>>>
> > > >> > >>>>>>>>> + ## Include/Ppi/MmAccess.h
> > > >> > >>>>>>>>> + gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd,
> > > >0x48be,
> > > >> > >>>>> { 0x88,
> > > >> > >>>>>>>> 0x17,
> > > >> > >>>>>>>>> 0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> + ## Include/Ppi/MmControl.h
> > > >> > >>>>>>>>> + gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e,
> > > >0x4f43,
> > > >> > >>>>> { 0x8d,
> > > >> > >>>>>>>> 0xef,
> > > >> > >>>>>>>>> 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
> > > >> > >>>>>>>>> +
> > > >> > >>>>>>>>> #
> > > >> > >>>>>>>>> # PPIs defined in PI 1.7.
> > > >> > >>>>>>>>> #
> > > >> > >>>>>>>>> --
> > > >> > >>>>>>>>> 2.16.2.windows.1
> > > >> > >>>>>>>>>
> > > >> > >>>>>>>>>
> > > >> > >>>>>>>>>
> > > >> > >>>>
> > > >> > >>>>
> > > >> > >>>>
> > > >> > >>>>
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >
> > > >
> > > >
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-08-18 5:21 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-07-29 4:25 [PATCH] MdePkg: Add MmAccess and MmControl definition Marc W Chen
2019-08-01 8:42 ` [edk2-devel] " Liming Gao
2019-08-01 8:48 ` Marc W Chen
2019-08-02 2:12 ` Laszlo Ersek
2019-08-01 8:52 ` Marc W Chen
2019-08-01 10:04 ` Ni, Ray
2019-08-01 10:15 ` Marc W Chen
2019-08-02 2:14 ` Laszlo Ersek
2019-08-06 8:56 ` Marc W Chen
2019-08-06 10:08 ` Ni, Ray
2019-08-07 4:52 ` Liming Gao
2019-08-07 16:10 ` Laszlo Ersek
2019-08-10 3:32 ` Marc W Chen
2019-08-10 3:34 ` Liming Gao
[not found] ` <15B9725390DC0000.29320@groups.io>
2019-08-13 9:19 ` Liming Gao
2019-08-14 9:53 ` Marc W Chen
2019-08-18 5:20 ` Ni, Ray
2019-08-18 5:21 ` Ni, Ray
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox