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; ler...@redhat.com; Ni, Ray <ray...@intel.com>; > Gao, Liming <liming....@intel.com> > Cc: Kinney, Michael D <michael.d.kin...@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.c...@intel.com>; Ni, > > Ray <ray...@intel.com>; Gao, Liming <liming....@intel.com> > > Cc: Kinney, Michael D <michael.d.kin...@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.c...@intel.com>; Gao, Liming > > >> <liming....@intel.com>; devel@edk2.groups.io > > >> Cc: Kinney, Michael D <michael.d.kin...@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....@intel.com>; devel@edk2.groups.io > > >>> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Ni, Ray > > >>> <ray...@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....@intel.com>; devel@edk2.groups.io > > >>>> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Ni, Ray > > >>>> <ray...@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.c...@intel.com> > > >>>>> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Ni, Ray > > >>>>> <ray...@intel.com> > > >>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and > > >>> MmControl > > >>>>> definition. > > >>>>> > > >>>>> Marc: > > >>>>> The change is good. Reviewed-by: Liming Gao > > <liming....@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.kin...@intel.com>; Gao, Liming > > >>>>>> <liming....@intel.com>; Ni, Ray <ray...@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.kin...@intel.com> > > >>>>>> Cc: Liming Gao <liming....@intel.com> > > >>>>>> Cc: Ray Ni <ray...@intel.com> > > >>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023 > > >>>>>> Signed-off-by: Marc W Chen <marc.w.c...@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 > > >>>>>> > > >>>>>> > > >>>>>> > > > > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44948): https://edk2.groups.io/g/devel/message/44948 Mute This Topic: https://groups.io/mt/32639140/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-