From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Thu, 11 Jul 2019 09:13:13 -0700 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8AF3430C26A9; Thu, 11 Jul 2019 16:13:12 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-231.ams2.redhat.com [10.36.117.231]) by smtp.corp.redhat.com (Postfix) with ESMTP id C447060920; Thu, 11 Jul 2019 16:13:10 +0000 (UTC) Subject: Re: [edk2-devel] [Patch v5 1/2] MdePkg: Add new MM MP Protocol definition. To: devel@edk2.groups.io, ray.ni@intel.com, "Dong, Eric" Cc: "Kinney, Michael D" , "Gao, Liming" References: <20190710075624.16420-1-eric.dong@intel.com> <20190710075624.16420-2-eric.dong@intel.com> <734D49CCEBEEF84792F5B80ED585239D5C223BE7@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <385ee804-aa92-886d-0a65-f49636266495@redhat.com> Date: Thu, 11 Jul 2019 18:13:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C223BE7@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Thu, 11 Jul 2019 16:13:12 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Ray, On 07/11/19 08:42, Ni, Ray wrote: > + MdePkg maintainers >=20 > We need to follow the open source community process to include MdePkg > maintainers for this change review. >=20 > Laszlo, > You are in the Cc list and had given Regression-Tested-By for V3 patch s= eries. > It would be great if you could give patch owner a hint to avoid breaking= the process > though I understand it's not responsibility of the people in the CC list= . =F0=9F=98=8A I'm unaware of any changes to the process. In the commit message of the patch, Cc: tags should be included for all "M" folks under XxxPkg, and also for all "R" folks who are listed with interest in the given area (possibly the entirety of XxxPkg). The contributor's git config should not include a "sendemail.suppresscc=3Dbodycc" setting; otherwise those Cc: tags will not actually copy the intended reviewers. For a given XxxPkg patch, at least one Acked-by or Required-by is needed from an "M" person listed under XxxPkg in "Maintainers.txt", on the mailing list, before the patch can be pushed. Reviews and comments from others are welcome for the patch. The patch should not be pushed as long as reasonable questions are still open for it (regardless of origin). A patch should generally spend at least 24 hours on the list before it is pushed, even if an "M" approval arrives earlier than that (so that others have a chance at noticing the patch and at commenting). Once no questions seem to remain open, the patch has spent the minimum time on the list, and there is public "M" approval, the patch can be pushed. An "M" person can defer to another "M" or "R" person, if he/she chooses so. This is best done formally, i.e., wait until the deferred-to person approves the patch, and then the first "M" person can give their own Acked-by. (Standing for "I haven't reviewed in detail, but given the circumstances / other reviews, I'm OK with this patch".) When the patch is pushed, all feedback tags, given on the list for the patch (regardless of origin), should be picked up, by whoever is pushing the patch. Let's consider the current state of this series, as an example. - The first patch (for MdePkg) has an "M" review, from Liming. - The second patch (for UefiCpuPkg) has an "M" review, from you. - The series has an open question (regarding regression testing), from myself. - The series was posted more than 24 hours ago (as far as I can see). So once I (hopefully) report back with an R-t-b for the series, the series becomes pushable (assuming noone opens another question meanwhile). In that case, any "M" person is welcome to push the patch series -- in the current case, it will likely be Eric. When Eric prepares for pushing the series, he's expected to pick up - Liming's R-b for the first patch, - my (to be posted) R-t-b for the first patch, - your R-b for the second patch, - my (to be posted) R-t-b for the second patch. (I will likely send my R-t-b in response to the blurb (the "v5 0/2" email), which means that the feedback tag applies to every patch in the series.) This "tag pickup" procedure is difficult to get right when using a MUA that does not support a "threaded" view, and it is easy to get right with a MUA that does. When I'm about to push a series, I tend to perform one full scan over the thread: - Whenever I reach patch-level feedback, I run "git rebase -i" for the full series, just to pick up that one tag. (A single "reword" action among the "pick"s.) - Whenever I reach series-level feedback (grouped under the blurb), I run "git rebase -i" for the full series again, and I apply the tag to every patch in the series (all actions are set to "reword"). Thanks Laszlo >> -----Original Message----- >> From: Dong, Eric >> Sent: Wednesday, July 10, 2019 3:56 PM >> To: devel@edk2.groups.io >> Cc: Ni, Ray ; Laszlo Ersek >> Subject: [Patch v5 1/2] MdePkg: Add new MM MP Protocol definition. >> >> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1937 >> >> EFI MM MP Protocol is defined in the PI 1.5 specification. >> >> The MM MP protocol provides a set of functions to allow execution of >> procedures on processors that have entered MM. This protocol has the >> following properties: >> 1. The caller can invoke execution of a procedure on a processor, other= than >> the caller, that has also entered MM. Supports blocking and non-blockin= g >> modes of operation. >> 2. The caller can invoke a procedure on multiple processors. Supports >> blocking and non-blocking modes of operation. >> >> Cc: Ray Ni >> Cc: Laszlo Ersek >> Signed-off-by: Eric Dong >> Reviewed-by: Ray Ni >> --- >> MdePkg/Include/Pi/PiMultiPhase.h | 16 ++ >> MdePkg/Include/Protocol/MmMp.h | 333 >> +++++++++++++++++++++++++++++++ >> MdePkg/MdePkg.dec | 3 + >> 3 files changed, 352 insertions(+) >> create mode 100644 MdePkg/Include/Protocol/MmMp.h >> >> diff --git a/MdePkg/Include/Pi/PiMultiPhase.h >> b/MdePkg/Include/Pi/PiMultiPhase.h >> index eb12527767..a5056799e1 100644 >> --- a/MdePkg/Include/Pi/PiMultiPhase.h >> +++ b/MdePkg/Include/Pi/PiMultiPhase.h >> @@ -176,4 +176,20 @@ VOID >> IN OUT VOID *Buffer >> ); >> >> +/** >> + The function prototype for invoking a function on an Application Pro= cessor. >> + >> + This definition is used by the UEFI MM MP Serices Protocol. >> + >> + @param[in] ProcedureArgument The pointer to private data buffer. >> + >> + @retval EFI_SUCCESS Excutive the procedure successfully >> + >> +**/ >> +typedef >> +EFI_STATUS >> +(EFIAPI *EFI_AP_PROCEDURE2)( >> + IN VOID *ProcedureArgument >> +); >> + >> #endif >> diff --git a/MdePkg/Include/Protocol/MmMp.h >> b/MdePkg/Include/Protocol/MmMp.h new file mode 100644 index >> 0000000000..beace1386c >> --- /dev/null >> +++ b/MdePkg/Include/Protocol/MmMp.h >> @@ -0,0 +1,333 @@ >> +/** @file >> + EFI MM MP Protocol is defined in the PI 1.5 specification. >> + >> + The MM MP protocol provides a set of functions to allow execution of >> + procedures on processors that have entered MM. This protocol has the >> following properties: >> + 1. The caller can only invoke execution of a procedure on a processo= r, >> other than the caller, that >> + has also entered MM. >> + 2. It is possible to invoke a procedure on multiple processors. Supp= orts >> blocking and non-blocking >> + modes of operation. >> + >> + Copyright (c) 2019, Intel Corporation. All rights reserved.
>> + SPDX-License-Identifier: BSD-2-Clause-Patent >> + >> +**/ >> + >> +#ifndef _MM_MP_H_ >> +#define _MM_MP_H_ >> + >> +#include >> + >> +#define EFI_MM_MP_PROTOCOL_GUID \ >> + { \ >> + 0x5d5450d7, 0x990c, 0x4180, {0xa8, 0x3, 0x8e, 0x63, 0xf0, 0x60, >> +0x83, 0x7 } \ >> + } >> + >> +// >> +// Revision definition. >> +// >> +#define EFI_MM_MP_PROTOCOL_REVISION 0x00 >> + >> +// >> +// Attribute flags >> +// >> +#define EFI_MM_MP_TIMEOUT_SUPPORTED 0x01 >> + >> +// >> +// Completion token >> +// >> +typedef VOID* MM_COMPLETION; >> + >> +typedef struct { >> + MM_COMPLETION Completion; >> + EFI_STATUS Status; >> +} MM_DISPATCH_COMPLETION_TOKEN; >> + >> +typedef struct _EFI_MM_MP_PROTOCOL EFI_MM_MP_PROTOCOL; >> + >> +/** >> + Service to retrieves the number of logical processor in the platform= . >> + >> + @param[in] This The EFI_MM_MP_PROTOCOL instance. >> + @param[out] NumberOfProcessors Pointer to the total number of logic= al >> processors in the system, >> + including the BSP and all APs. >> + >> + @retval EFI_SUCCESS The number of processors was retriev= ed >> successfully >> + @retval EFI_INVALID_PARAMETER NumberOfProcessors is NULL >> +**/ >> +typedef >> +EFI_STATUS >> +(EFIAPI *EFI_MM_GET_NUMBER_OF_PROCESSORS) ( >> + IN CONST EFI_MM_MP_PROTOCOL *This, >> + OUT UINTN *NumberOfProcessors >> +); >> + >> + >> +/** >> + This service allows the caller to invoke a procedure one of the >> +application processors (AP). This >> + function uses an optional token parameter to support blocking and >> +non-blocking modes. If the token >> + is passed into the call, the function will operate in a non-blocking >> +fashion and the caller can >> + check for completion with CheckOnProcedure or WaitForProcedure. >> + >> + @param[in] This The EFI_MM_MP_PROTOCOL instanc= e. >> + @param[in] Procedure A pointer to the procedure to = be run on >> the designated target >> + AP of the system. Type EFI_AP_= PROCEDURE2 is defined >> below in >> + related definitions. >> + @param[in] CpuNumber The zero-based index of the pr= ocessor >> number of the target >> + AP, on which the code stream i= s supposed to run. If the >> number >> + points to the calling processo= r then it will not run the >> + supplied code. >> + @param[in] TimeoutInMicroseconds Indicates the time limit in >> microseconds for this AP to >> + finish execution of Procedure,= either for blocking or >> + non-blocking mode. Zero means = infinity. If the timeout >> + expires before this AP returns= from Procedure, then >> Procedure >> + on the AP is terminated. If th= e timeout expires in >> blocking >> + mode, the call returns EFI_TIM= EOUT. If the timeout >> expires >> + in non-blocking mode, the time= out determined can be >> through >> + CheckOnProcedure or WaitForPro= cedure. >> + Note that timeout support is o= ptional. Whether an >> + implementation supports this f= eature, can be >> determined via >> + the Attributes data member. >> + @param[in,out] ProcedureArguments Allows the caller to pass a li= st of >> parameters to the code >> + that is run by the AP. It is a= n optional common mailbox >> + between APs and the caller to = share information. >> + @param[in,out] Token This is parameter is broken in= to two >> components: >> + 1.Token->Completion is an opti= onal parameter that >> allows the >> + caller to execute the procedur= e in a blocking or non- >> blocking >> + fashion. If it is NULL the cal= l is blocking, and the call will >> + not return until the AP has co= mpleted the procedure. If >> the >> + token is not NULL, the call wi= ll return immediately. The >> caller >> + can check whether the procedur= e has completed with >> + CheckOnProcedure or WaitForPro= cedure. >> + 2.Token->Status The implementa= tion updates the >> address pointed >> + at by this variable with the s= tatus code returned by >> Procedure >> + when it completes execution on= the target AP, or with >> EFI_TIMEOUT >> + if the Procedure fails to comp= lete within the optional >> timeout. >> + The implementation will update= this variable with >> EFI_NOT_READY >> + prior to starting Procedure on= the target AP. >> + @param[in,out] CPUStatus This optional pointer may be u= sed to get >> the status code returned >> + by Procedure when it completes= execution on the >> target AP, or with >> + EFI_TIMEOUT if the Procedure f= ails to complete within >> the optional >> + timeout. The implementation wi= ll update this variable >> with >> + EFI_NOT_READY prior to startin= g Procedure on the >> target AP. >> + >> + @retval EFI_SUCCESS In the blocking case, this ind= icates that >> Procedure has completed >> + execution on the target AP. >> + In the non-blocking case this = indicates that the >> procedure has >> + been successfully scheduled fo= r execution on the target >> AP. >> + @retval EFI_INVALID_PARAMETER The input arguments are out of >> range. Either the target AP is the >> + caller of the function, or the= Procedure or Token is NULL >> + @retval EFI_NOT_READY If the target AP is busy execu= ting another >> procedure >> + @retval EFI_ALREADY_STARTED Token is already in use for an= other >> procedure >> + @retval EFI_TIMEOUT In blocking mode, the timeout = expired >> before the specified AP >> + has finished **/ typedef >> +EFI_STATUS (EFIAPI *EFI_MM_DISPATCH_PROCEDURE) ( >> + IN CONST EFI_MM_MP_PROTOCOL *This, >> + IN EFI_AP_PROCEDURE2 Procedure, >> + IN UINTN CpuNumber, >> + IN UINTN TimeoutInMicroseconds, >> + IN OUT VOID *ProcedureArguments OPTIONAL, >> + IN OUT MM_COMPLETION *Token, >> + IN OUT EFI_STATUS *CPUStatus >> +); >> + >> +/** >> + This service allows the caller to invoke a procedure on all running >> +application processors (AP) >> + except the caller. This function uses an optional token parameter to >> +support blocking and >> + nonblocking modes. If the token is passed into the call, the functio= n >> +will operate in a non-blocking >> + fashion and the caller can check for completion with CheckOnProcedur= e or >> WaitForProcedure. >> + >> + It is not necessary for the implementation to run the procedure on e= very >> processor on the platform. >> + Processors that are powered down in such a way that they cannot >> + respond to interrupts, may be excluded from the broadcast. >> + >> + >> + @param[in] This The EFI_MM_MP_PROTOCOL instanc= e. >> + @param[in] Procedure A pointer to the code stream t= o be run on >> the APs that have >> + entered MM. Type EFI_AP_PROCED= URE is defined >> below in related >> + definitions. >> + @param[in] TimeoutInMicroseconds Indicates the time limit in >> microseconds for the APs to finish >> + execution of Procedure, either= for blocking or non- >> blocking mode. >> + Zero means infinity. If the ti= meout expires before all >> APs return >> + from Procedure, then Procedure= on the failed APs is >> terminated. If >> + the timeout expires in blockin= g mode, the call returns >> EFI_TIMEOUT. >> + If the timeout expires in non-= blocking mode, the >> timeout determined >> + can be through CheckOnProcedur= e or >> WaitForProcedure. >> + Note that timeout support is o= ptional. Whether an >> implementation >> + supports this feature can be d= etermined via the >> Attributes data >> + member. >> + @param[in,out] ProcedureArguments Allows the caller to pass a li= st of >> parameters to the code >> + that is run by the AP. It is a= n optional common mailbox >> + between APs and the caller to = share information. >> + @param[in,out] Token This is parameter is broken in= to two >> components: >> + 1.Token->Completion is an opti= onal parameter that >> allows the >> + caller to execute the procedur= e in a blocking or non- >> blocking >> + fashion. If it is NULL the cal= l is blocking, and the call will >> + not return until the AP has co= mpleted the procedure. If >> the >> + token is not NULL, the call wi= ll return immediately. The >> caller >> + can check whether the procedur= e has completed with >> + CheckOnProcedure or WaitForPro= cedure. >> + 2.Token->Status The implementa= tion updates the >> address pointed >> + at by this variable with the s= tatus code returned by >> Procedure >> + when it completes execution on= the target AP, or with >> EFI_TIMEOUT >> + if the Procedure fails to comp= lete within the optional >> timeout. >> + The implementation will update= this variable with >> EFI_NOT_READY >> + prior to starting Procedure on= the target AP >> + @param[in,out] CPUStatus This optional pointer may be u= sed to get >> the individual status >> + returned by every AP that part= icipated in the broadcast. >> This >> + parameter if used provides the= base address of an array >> to hold >> + the EFI_STATUS value of each A= P in the system. The size >> of the >> + array can be ascertained by th= e >> GetNumberOfProcessors function. >> + As mentioned above, the broadc= ast may not include >> every processor >> + in the system. Some implementa= tions may exclude >> processors that >> + have been powered down in such= a way that they are >> not responsive >> + to interrupts. Additionally th= e broadcast excludes the >> processor >> + which is making the BroadcastP= rocedure call. For every >> excluded >> + processor, the array entry mus= t >> + contain a value of EFI_NOT_STARTED >> + >> + @retval EFI_SUCCESS In the blocking case, this ind= icates that >> Procedure has completed >> + execution on the APs. In the n= on-blocking case this >> indicates that >> + the procedure has been success= fully scheduled for >> execution on the >> + APs. >> + @retval EFI_INVALID_PARAMETER Procedure or Token is NULL. >> + @retval EFI_NOT_READY If a target AP is busy executi= ng another >> procedure. >> + @retval EFI_TIMEOUT In blocking mode, the timeout = expired >> before all enabled APs have >> + finished. >> + @retval EFI_ALREADY_STARTED Before the AP procedure associ= ated >> with the Token is finished, the >> + same Token cannot be used to d= ispatch or broadcast >> another procedure. >> + >> +**/ >> +typedef >> +EFI_STATUS >> +(EFIAPI *EFI_MM_BROADCAST_PROCEDURE) ( >> + IN CONST EFI_MM_MP_PROTOCOL *This, >> + IN EFI_AP_PROCEDURE2 Procedure, >> + IN UINTN TimeoutInMicroseconds, >> + IN OUT VOID *ProcedureArguments OPTIONAL, >> + IN OUT MM_COMPLETION *Token, >> + IN OUT EFI_STATUS *CPUStatus >> +); >> + >> + >> +/** >> + This service allows the caller to set a startup procedure that will >> +be executed when an AP powers >> + up from a state where core configuration and context is lost. The >> +procedure is execution has the >> + following properties: >> + 1. The procedure executes before the processor is handed over to the >> operating system. >> + 2. All processors execute the same startup procedure. >> + 3. The procedure may run in parallel with other procedures invoked >> +through the functions in this >> + protocol, or with processors that are executing an MM handler or run= ning >> in the operating system. >> + >> + >> + @param[in] This The EFI_MM_MP_PROTOCOL instance= . >> + @param[in] Procedure A pointer to the code stream to= be run on >> the designated target AP >> + of the system. Type EFI_AP_PROC= EDURE is defined >> below in Volume 2 >> + with the related definitions of >> + EFI_MP_SERVICES_PROTOCOL.Startu= pAllAPs. >> + If caller may pass a value of N= ULL to deregister any >> existing >> + startup procedure. >> + @param[in,out] ProcedureArguments Allows the caller to pass a lis= t of >> parameters to the code that is >> + run by the AP. It is an optiona= l common mailbox >> between APs and >> + the caller to share information >> + >> + @retval EFI_SUCCESS The Procedure has been set succ= essfully. >> + @retval EFI_INVALID_PARAMETER The Procedure is NULL. >> +**/ >> +typedef >> +EFI_STATUS >> +(EFIAPI *EFI_MM_SET_STARTUP_PROCEDURE) ( >> + IN CONST EFI_MM_MP_PROTOCOL *This, >> + IN EFI_AP_PROCEDURE Procedure, >> + IN OUT VOID *ProcedureArguments OPTIONAL >> +); >> + >> +/** >> + When non-blocking execution of a procedure on an AP is invoked with >> +DispatchProcedure, >> + via the use of a token, this function can be used to check for compl= etion of >> the procedure on the AP. >> + The function takes the token that was passed into the >> +DispatchProcedure call. If the procedure >> + is complete, and therefore it is now possible to run another >> +procedure on the same AP, this function >> + returns EFI_SUCESS. In this case the status returned by the procedur= e >> +that executed on the AP is >> + returned in the token's Status field. If the procedure has not yet >> +completed, then this function >> + returns EFI_NOT_READY. >> + >> + When a non-blocking execution of a procedure is invoked with >> + BroadcastProcedure, via the use of a token, this function can be use= d >> + to check for completion of the procedure on all the broadcast APs. >> + The function takes the token that was passed into the >> + BroadcastProcedure call. If the procedure is complete on all >> + broadcast APs this function returns EFI_SUCESS. In this case the Sta= tus >> field in the token passed into the function reflects the overall result= of the >> invocation, which may be EFI_SUCCESS, if all executions succeeded, or t= he >> first observed failure. >> + If the procedure has not yet completed on the broadcast APs, the >> + function returns EFI_NOT_READY. >> + >> + @param[in] This The EFI_MM_MP_PROTOCOL instance= . >> + @param[in] Token This parameter describes the to= ken that was >> passed into >> + DispatchProcedure or BroadcastP= rocedure. >> + >> + @retval EFI_SUCCESS Procedure has completed. >> + @retval EFI_NOT_READY The Procedure has not completed= . >> + @retval EFI_INVALID_PARAMETER Token or Token->Completion is >> NULL >> + @retval EFI_NOT_FOUND Token is not currently in use f= or a non- >> blocking call >> + >> +**/ >> +typedef >> +EFI_STATUS >> +(EFIAPI *EFI_CHECK_FOR_PROCEDURE) ( >> + IN CONST EFI_MM_MP_PROTOCOL *This, >> + IN MM_COMPLETION Token >> +); >> + >> +/** >> + When a non-blocking execution of a procedure on an AP is invoked via >> +DispatchProcedure, >> + this function will block the caller until the remote procedure has c= ompleted >> on the designated AP. >> + The non-blocking procedure invocation is identified by the Token >> +parameter, which must match the >> + token that used when DispatchProcedure was called. Upon completion >> +the status returned by >> + the procedure that executed on the AP is used to update the token's >> Status field. >> + >> + When a non-blocking execution of a procedure on an AP is invoked via >> + BroadcastProcedure this function will block the caller until the >> + remote procedure has completed on all of the APs that entered MM. Th= e >> + non-blocking procedure invocation is identified by the Token >> + parameter, which must match the token that used when >> + BroadcastProcedure was called. Upon completion the overall status >> + returned by the procedures that executed on the broadcast AP is used = to >> update the token's Status field. The overall status may be EFI_SUCCESS= , if all >> executions succeeded, or the first observed failure. >> + >> + >> + @param[in] This The EFI_MM_MP_PROTOCOL instance= . >> + @param[in] Token This parameter describes the to= ken that was >> passed into >> + DispatchProcedure or BroadcastP= rocedure. >> + >> + @retval EFI_SUCCESS Procedure has completed. >> + @retval EFI_INVALID_PARAMETER Token or Token->Completion is >> NULL >> + @retval EFI_NOT_FOUND Token is not currently in use f= or a non- >> blocking call >> + >> +**/ >> +typedef >> +EFI_STATUS >> +(EFIAPI *EFI_WAIT_FOR_PROCEDURE) ( >> + IN CONST EFI_MM_MP_PROTOCOL *This, >> + IN MM_COMPLETION Token >> +); >> + >> + >> + >> +/// >> +/// The MM MP protocol provides a set of functions to allow execution >> +of procedures on processors that /// have entered MM. >> +/// >> +struct _EFI_MM_MP_PROTOCOL { >> + UINT32 Revision; >> + UINT32 Attributes; >> + EFI_MM_GET_NUMBER_OF_PROCESSORS GetNumberOfProcessors; >> + EFI_MM_DISPATCH_PROCEDURE DispatchProcedure; >> + EFI_MM_BROADCAST_PROCEDURE BroadcastProcedure; >> + EFI_MM_SET_STARTUP_PROCEDURE SetStartupProcedure; >> + EFI_CHECK_FOR_PROCEDURE CheckForProcedure; >> + EFI_WAIT_FOR_PROCEDURE WaitForProcedure; >> +}; >> + >> +extern EFI_GUID gEfiMmMpProtocolGuid; >> + >> +#endif >> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index >> 6c563375ee..b382efd578 100644 >> --- a/MdePkg/MdePkg.dec >> +++ b/MdePkg/MdePkg.dec >> @@ -1167,6 +1167,9 @@ >> # Protocols defined in PI 1.5. >> # >> >> + ## Include/Protocol/MmMp.h >> + gEfiMmMpProtocolGuid =3D { 0x5d5450d7, 0x990c, 0x4180, { 0xa8, 0x3, >> + 0x8e, 0x63, 0xf0, 0x60, 0x83, 0x7 }} >> + >> ## Include/Protocol/MmEndOfDxe.h >> gEfiMmEndOfDxeProtocolGuid =3D { 0x24e70042, 0xd5c5, 0x4260, { 0x8c,= 0x39, >> 0xa, 0xd3, 0xaa, 0x32, 0xe9, 0x3d }} >> >> -- >> 2.21.0.windows.1 >=20 >=20 >=20 >=20