Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.

["Liming Gao" <liming.gao@intel.com>]

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.chen@intel.com>; devel@edk2.groups.io;
>lersek@redhat.com; Ni, Ray <ray.ni@intel.com>
>Cc: Kinney, Michael D <michael.d.kinney@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; lersek@redhat.com; Ni, Ray <ray.ni@intel.com>;
>Gao, Liming <liming.gao@intel.com>
>> Cc: Kinney, Michael D <michael.d.kinney@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.ni@intel.com>; Chen, Marc W <marc.w.chen@intel.com>;
>> > devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
>> > Cc: Kinney, Michael D <michael.d.kinney@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; lersek@redhat.com; Ni, Ray
>> > <ray.ni@intel.com>;
>> > >> Gao, Liming <liming.gao@intel.com>
>> > >> Cc: Kinney, Michael D <michael.d.kinney@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.chen@intel.com>;
>Ni,
>> > >>> Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
>> > >>> Cc: Kinney, Michael D <michael.d.kinney@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.chen@intel.com>; Gao, Liming
>> > >>>>> <liming.gao@intel.com>; devel@edk2.groups.io
>> > >>>>> Cc: Kinney, Michael D <michael.d.kinney@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.gao@intel.com>; devel@edk2.groups.io
>> > >>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>> > >>>>>> <ray.ni@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.gao@intel.com>; devel@edk2.groups.io
>> > >>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>> > >>>>>>> <ray.ni@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.chen@intel.com>
>> > >>>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray
>> > >>>>>>>> <ray.ni@intel.com>
>> > >>>>>>>> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess
>and
>> > >>>>>> MmControl
>> > >>>>>>>> definition.
>> > >>>>>>>>
>> > >>>>>>>> Marc:
>> > >>>>>>>>   The change is good. Reviewed-by: Liming Gao
>> > >>> <liming.gao@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.kinney@intel.com>; Gao,
>> > Liming
>> > >>>>>>>>> <liming.gao@intel.com>; Ni, Ray <ray.ni@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.kinney@intel.com>
>> > >>>>>>>>> Cc: Liming Gao <liming.gao@intel.com>
>> > >>>>>>>>> Cc: Ray Ni <ray.ni@intel.com>
>> > >>>>>>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
>> > >>>>>>>>> Signed-off-by: Marc W Chen <marc.w.chen@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
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>
>> > >>>
>> > >>>
>> > >
>> >
>> >
>> >
>
>
>