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

["Marc W Chen" <marc.w.chen@intel.com>]

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.gao@intel.com>; Chen, Marc
> W <marc.w.chen@intel.com>; 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.
> 
> 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
> >> > >>>>>>>>>
> >> > >>>>>>>>>
> >> > >>>>>>>>>
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >
> >> >
> >> >
> >> >
> >
> >
> >