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.c...@intel.com>; devel@edk2.groups.io; >ler...@redhat.com; Ni, Ray <ray...@intel.com> >Cc: Kinney, Michael D <michael.d.kin...@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; 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 >> >> 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...@intel.com>; Chen, Marc W <marc.w.c...@intel.com>; >> > devel@edk2.groups.io; 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/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; 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 (#45513): https://edk2.groups.io/g/devel/message/45513 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] -=-=-=-=-=-=-=-=-=-=-=-
