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 (#45314): https://edk2.groups.io/g/devel/message/45314
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]
-=-=-=-=-=-=-=-=-=-=-=-
