I don't have strong preference on removing SmmAccess.h from MdeModulePkg. If people except me all agreed to keep that header file for compatibility, I am ok.
> -----Original Message----- > From: Chen, Marc W > Sent: Wednesday, August 14, 2019 5:54 PM > To: Gao, Liming <liming....@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. > > 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 (#46013): https://edk2.groups.io/g/devel/message/46013 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] -=-=-=-=-=-=-=-=-=-=-=-
