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....@intel.com>; Chen, Marc > W <marc.w.c...@intel.com>; 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. > > 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 (#45598): https://edk2.groups.io/g/devel/message/45598 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] -=-=-=-=-=-=-=-=-=-=-=-
