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 (#44940): https://edk2.groups.io/g/devel/message/44940 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] -=-=-=-=-=-=-=-=-=-=-=-
