Re: [edk2-devel] [edk2-platforms][PATCH V1 09/20] StandaloneMmPkg: parse SP manifest and populate new boot information
Hi Chris, Prior to FF-A, an impdef structure populated by TF-A was passed to a SPM_MM based StMM SP. The data structures used for this are EFI_SECURE_PARTITION_BOOT_INFO and EFI_SECURE_PARTITION_CPU_INFO. With FF-A, we have reduced the amount of information that is passed e.g. the per-cpu information is not passed. The remaining information has been generalized so that it is not specific to StMM SPs. This information is only used at boot time. Hence, passing it once via the FF-A boot information protocol made sense. The FF-A spec does not specify the format in which boot information is passed. An SP manifest is specified in a DT by default. So, this was the natural choice. The same information could be passed using a HOB list but that would require additional support in TF-A. I hope this helps. cheers, Achin On Thu, 2023-07-13 at 09:48 -0700, Chris Fernald wrote: > Achin/Nishant, could you explain the motivation behind falling back > to > device tree for some of the secure partition information? It seems > like > we have this large abstraction framework using FF-A and it seems a > bit > odd to have the secure partition have to directly read device tree > for > some of this information when everything else is query-able from the > framework itself. > > Thanks, > > Chris Fernald > > On 7/13/2023 8:24 AM, Girish Mahadevan via groups.io wrote: > > I had one comment , in-line. > > > > Thanks > > Girish > > > > On 7/11/2023 8:36 AM, Nishant Sharma via groups.io wrote: > > > External email: Use caution opening links or attachments > > > > > > > > > From: Achin Gupta > > > > > > This patch discovers the SP manifest in DT format passed by the > > > SPMC. It > > > then parses it to obtain the boot information required to > > > initialise the > > > SP. > > > > > > Signed-off-by: Achin Gupta > > > Signed-off-by: Sayanta Pattanayak > > > Signed-off-by: Nishant Sharma > > > --- > > > StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h > > > | > > > 2 +- > > > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/Standalone > > > MmCoreEntryPoint.c > > > > 389 +++- > > > 2 files changed, 381 insertions(+), 10 deletions(-) > > > > > > diff --git > > > a/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint. > > > h > > > b/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint. > > > h > > > index c965192c702e..90d67a2f25b5 100644 > > > --- > > > a/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint. > > > h > > > +++ > > > b/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint. > > > h > > > @@ -2,7 +2,7 @@ > > > Entry point to the Standalone MM Foundation when initialized > > > during the SEC > > > phase on ARM platforms > > > > > > -Copyright (c) 2017 - 2021, Arm Ltd. All rights reserved. > > > +Copyright (c) 2017 - 2023, Arm Ltd. All rights reserved. > > > SPDX-License-Identifier: BSD-2-Clause-Patent > > > > > > **/ > > > diff --git > > > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/Standalo > > > neMmCoreEntryPoint.c > > > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/Standalo > > > neMmCoreEntryPoint.c > > > > > > index 9f6af55c86c4..505786aff07c 100644 > > > --- > > > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/Standalo > > > neMmCoreEntryPoint.c > > > +++ > > > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/Standalo > > > neMmCoreEntryPoint.c > > > @@ -38,6 +38,10 @@ SPDX-License-Identifier: BSD-2-Clause-Patent > > > > > > #define BOOT_PAYLOAD_VERSION 1 > > > > > > +#define FFA_PAGE_4K 0 > > > +#define FFA_PAGE_16K 1 > > > +#define FFA_PAGE_64K 2 > > > + > > > PI_MM_ARM_TF_CPU_DRIVER_ENTRYPOINT CpuDriverEntryPoint = NULL; > > > > > > /** > > > @@ -106,6 +110,7 @@ GetAndPrintBootinformation ( > > > } > > > > > > return PayloadBootInfo; > > > +} > > > > > > /** > > > An StMM SP implements partial support for FF-A v1.0. The FF-A > > > ABIs are used to > > > @@ -266,6 +271,308 @@ DelegatedEventLoop ( > > > } > > > } > > > > > > +STATIC > > > +BOOLEAN > > > +CheckDescription ( > > > +IN
Re: [edk2-devel] [edk2-platforms][PATCH V1 19/20] ArmPkg/MmCommunicationDxe: Use the FF-A transport for MM requests
Hi Kun,
IIUC, not much happens during the PEI phase on Arm platforms. Hence the patches
focus on DXE in the Normal world. It would be difficult to provide an effort
estimate as we do not see a use case and consequently this is not on the to-do
list. Would you be able to provide more detail about the scenarios you have in
mind?
cheers,
Achin
From: Kun Qin
Sent: 11 July 2023 20:22
To: devel@edk2.groups.io ; Nishant Sharma
Cc: Ard Biesheuvel ; Sami Mujawar
; Thomas Abraham ; Sayanta
Pattanayak ; Achin Gupta ;
Aditya Angadi
Subject: Re: [edk2-devel] [edk2-platforms][PATCH V1 19/20]
ArmPkg/MmCommunicationDxe: Use the FF-A transport for MM requests
Hi Nishant,
Thank you for sending out the patch. Can you please evaluate how much
effort it would be
to support the same for MmCommunicatePei? I think it would provide
better coverage for
the FFA support if we can have that change.
Thanks,
Kun
On 7/11/2023 7:36 AM, Nishant Sharma wrote:
> From: Achin Gupta
>
> This patch packages requests for accessing a Standalone MM driver
> through the MM communication protocol as FF-A direct messages.
> Corresponding changes in Standalone MM Core ensure that responses are
> packaged in the same way.
>
> Signed-off-by: Achin Gupta
> Co-developed-by: Aditya Angadi
> Signed-off-by: Nishant Sharma
> ---
> ArmPkg/Include/IndustryStandard/ArmFfaSvc.h | 2 +
> ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c | 141
> +---
> 2 files changed, 97 insertions(+), 46 deletions(-)
>
> diff --git a/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h
> b/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h
> index 530af8bd3c2e..493997346143 100644
> --- a/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h
> +++ b/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h
> @@ -23,6 +23,7 @@
> #define ARM_SVC_ID_FFA_RXTX_UNMAP_AARCH320x8467
> #define ARM_SVC_ID_FFA_PARTITION_INFO_GET_AARCH320x8468
> #define ARM_SVC_ID_FFA_ID_GET_AARCH320x8469
> +#define ARM_SVC_ID_FFA_RUN_AARCH32 0x846D
> #define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH32 0x846F
> #define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP_AARCH32 0x8470
> #define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH64 0xC46F
> @@ -31,6 +32,7 @@
> #define ARM_SVC_ID_FFA_SUCCESS_AARCH64 0xC461
> #define ARM_SVC_ID_FFA_MEM_PERM_SET_AARCH32 0x8489
> #define ARM_SVC_ID_FFA_MEM_PERM_GET_AARCH32 0x8488
> +#define ARM_SVC_ID_FFA_INTERRUPT_AARCH32 0x8462
> #define ARM_SVC_ID_FFA_ERROR_AARCH32 0x8460
> #define ARM_SVC_ID_FFA_ERROR_AARCH64 0xC460
> #define ARM_SVC_ID_FFA_MSG_WAIT_AARCH32 0x846B
> diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> index 94a5d96c051d..a70318581bd2 100644
> --- a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> @@ -100,6 +100,7 @@ MmCommunication2Communicate (
> ARM_SMC_ARGS CommunicateSmcArgs;
> EFI_STATUS Status;
> UINTN BufferSize;
> + UINTN Ret;
>
> Status = EFI_ACCESS_DENIED;
> BufferSize = 0;
> @@ -160,60 +161,108 @@ MmCommunication2Communicate (
> return Status;
> }
>
> - // SMC Function ID
> - CommunicateSmcArgs.Arg0 = ARM_SMC_ID_MM_COMMUNICATE_AARCH64;
> -
> - // Cookie
> - CommunicateSmcArgs.Arg1 = 0;
> -
> // Copy Communication Payload
> CopyMem ((VOID *)mNsCommBuffMemRegion.VirtualBase, CommBufferVirtual,
> BufferSize);
>
> - // comm_buffer_address (64-bit physical address)
> - CommunicateSmcArgs.Arg2 = (UINTN)mNsCommBuffMemRegion.PhysicalBase;
> + // Use the FF-A interface if enabled.
> + if (FixedPcdGet32 (PcdFfaEnable) != 0) {
> +// FF-A Interface ID for direct message communication
> +CommunicateSmcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH64;
>
> - // comm_size_address (not used, indicated by setting to zero)
> - CommunicateSmcArgs.Arg3 = 0;
> +// FF-A Destination EndPoint ID, not used as of now
> +CommunicateSmcArgs.Arg1 = mFfaPartId << 16 | mStmmPartInfo.PartId;
>
> +// Reserved for future use(MBZ)
> +CommunicateSmcArgs.Arg2 = 0x0;
> +
> +// comm_buffer_address (64-bit physical address)
> +CommunicateSmcArgs.Arg3 = (UINTN)mNsCommBuffMemRegion.PhysicalBase;
> +
> +// Cookie
> +CommunicateSmcArgs.Arg4 = 0x0;
> +
> +// Not Used
> +CommunicateSmcArgs.Arg5 = 0;
> +
> +// comm_size_address (not used, indicated by set
Re: [edk2-devel] [PATCH 1/3 v6] Drivers/OpTeeRpmb: Add an OP-TEE backed RPMB driver
Hi, CIL... On Thu, Mar 11, 2021 at 06:37:30PM +0200, Ilias Apalodimas wrote: > (+cc Achin) > > On Wed, 10 Mar 2021 at 14:45, Ilias Apalodimas via groups.io > linaro@groups.io> wrote: > > Hi Pierre, > > On Wed, Mar 10, 2021 at 09:58:19AM +, Pierre wrote: > > Hi Ilias, > > Just minor coding style nit picking: > > > > * Drivers/OpTee/OpteeRpmbPkg/FixupPcd.c:FixPcdMemory() I think the > >error codes are missing in the function header > > Ah you mean the return values of locate protocol? > > > * Thanks for adding the IN/OUT function parameter descriptors. Is it > >possible to also add them in the function headers [1] ? > > Sure, I'll send a v7 anyways since I managed to mess up the maintainers > patch > somehow... > > I hope I haven't missed any of your other requests. > > > > > About the FFA/SVC call: > > > > >> If this is an FFA call, is it possible to: > > >> - put a reference in the header to the spec (it should be similar to > the > > >> one at > > >> edk2/ArmPkg/Library/StandaloneMmMmuLib/AArch64/ > ArmMmuStandaloneMmLib.c) > > >> - check the return status of the SVC call against the ones available > at > > >> edk2/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h > > >> - if possible, remove the dependency to > > > > > > > The call is technically an FFA one but at the moment OP-TEE returns > the > > StMM > > > return code which is defined in the last header you mention. > > > The relevant code is in ./core/arch/arm/kernel/stmm_sp.c function > > > tee2stmm_ret_val(). > > > So unless we redefine that in OP-TEE or (better imho), wait for a full > FFA > > > mechanism to be in place, I'd prefer leaving it as is. > > > Keep in mind that adding the full FFA will also get rid of the > hardcoded > > IDs > > > on the beginning of the file. > > > > The description of a FFA_MSG_SEND_DIRECT_REQ (s10.2 of [2]) doesn't seem > to > > return the same error codes as the ones optee returns (in > > optee_os/core/arch/arm/kernel/stmm_sp.c:tee2stmm_ret_val()). I am not > sure a > > new FFA specification will change these error codes. > > Another thing is that I think the mMemMgrId variable described in > > edk2-platforms/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c is currently > > defined as edk2/ArmPkg/Include/IndustryStandard/ > ArmFfaSvc.h:ARM_FFA_DESTINATION_ENDPOINT_ID > > (the name seems to be misleading). > > I think it would be better to: > > > > * align the optee error codes with what is in the FFA spec > > * handle these error codes in edk2 with what is in > >edk2/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h and remove the > >dependendy to edk2/ArmPkg/Include/IndustryStandard/ArmMmSvc.h if > >possible > > * rename > >edk2/ArmPkg/Include/IndustryStandard/ > ArmFfaSvc.h:ARM_FFA_DESTINATION_ENDPOINT_ID > >define to a proper name, according to what is in > >optee_os/core/arch/arm/kernel/stmm_sp.c, and add one define for > >'mem_mgr_id' > > * remove the mMemMgrId and mStorageId variables from > >edk2-platforms/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c and use the > >newly created defines from > >edk2/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h > > > > This would allow to be aligned with the current FFA spec and when a new > one > > comes, these endpoints IDs (mMemMgrId/mStorageId) can just be removed > from > > one location (as you said). > > In the end it seems you and Sami will maintain this, so I will let you > > decide what is best. > > I get the whole point, and for the record you are technically right. > > But there's something (once again) that's 'weird' here. > This StandAloneMM that's compiling over here is only used by OP-TEE. > In order to use that you need to call an SMC into OP-TEE (not FFA) from > the non-secure world to initiate it. > There's an OP-TEE PTA (pseudo-TA), that then converts the message to MM > and > sends it over to StandAloneMM. There are no FFA manifests yet, that's why > the > get/set memory attributes code is still running, to set up page > permissions > as well. > > The FFA mechanism you are seeing right now, is just the internal contract > between OP-TEE and this driver. We did some of the calls depend on FFA > since > this was a good way to start introducing FFA code into EDK2 (which will > eventually be needed), without being too intrusive. > > In the long run OP-TEE will be fully converted into FFA the changes you > are > talking about make sense. In fact there's a ./core/arch/arm/kernel/ > secure_partition.c > in OP-TEE doing exactly that but it's not yet complete. > I tried to describe the entire situation here [1]. > > If anyo
Re: [edk2-devel] [PATCH 1/1] Maintainers: assume co-maintainership of StandaloneMmPkg
Hi Ard/Sami, Thanks for picking this up. Reviewed-by: Achin Gupta On Fri, Dec 06, 2019 at 03:28:48PM +, Ard Biesheuvel wrote: > From: Ard Biesheuvel > > Achin has indicated that he no longer has the bandwidth available to > co-maintain StandaloneMmPkg, and has asked Sami and me to step in. > > Cc: Achin Gupta > Cc: Sami Mujawar > Cc: Jiewen Yao > Signed-off-by: Ard Biesheuvel > --- > Maintainers.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 180ad35d0976..d6e8d5d5c797 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -481,6 +481,7 @@ S: Maintained > > StandaloneMmPkg > F: StandaloneMmPkg/ > -M: Achin Gupta > +M: Ard Biesheuvel > +M: Sami Mujawar > M: Jiewen Yao > R: Supreeth Venkatesh > -- > 2.17.1 > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#52043): https://edk2.groups.io/g/devel/message/52043 Mute This Topic: https://groups.io/mt/67497096/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
Makes sense!
Reviewed-by: Achin Gupta
On Thu, Oct 03, 2019 at 01:10:53PM +0200, Laszlo Ersek wrote:
> Pinging StandaloneMmPkg maintainers again, for reviewing this patch.
>
> Thanks
> Laszlo
>
> On 09/26/19 14:48, Laszlo Ersek wrote:
> > Achin, Jiewen, Supreeth,
> >
> > can one of you guys please review this patch?
> >
> > Thanks
> > Laszlo
> >
> > On 09/17/19 21:49, Laszlo Ersek wrote:
> >> The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
> >> that every firmware volume is processed only once (every driver in every
> >> firmware volume should be discovered only once). For this, the functions
> >> use a linked list.
> >>
> >> In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
> >> those firmware volumes that have been processed is the EFI_HANDLE on which
> >> the DXE or SMM firmware volume protocol is installed. In the
> >> StandaloneMmPkg core however, the key is the address of the firmware
> >> volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
> >>
> >> (EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
> >> EFI_HANDLE just happens to be specified as (VOID*), and therefore the
> >> conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.
> >>
> >> (The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
> >> copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
> >> flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
> >> specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
> >> conversion.)
> >>
> >> We should not exploit this circumstance. Represent the key type faithfully
> >> instead.
> >>
> >> This is a semantic fix; there is no change in operation.
> >>
> >> Cc: Achin Gupta
> >> Cc: Jiewen Yao
> >> Cc: Supreeth Venkatesh
> >> Signed-off-by: Laszlo Ersek
> >> ---
> >>
> >> Notes:
> >> build-tested only
> >>
> >> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
> >> StandaloneMmPkg/Core/Dispatcher.c | 80 +++-
> >> StandaloneMmPkg/Core/FwVol.c| 16 ++--
> >> 3 files changed, 52 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> index dcf91bc5e916..23ddbe169faf 100644
> >> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> @@ -67,7 +67,7 @@ typedef struct {
> >>
> >>LIST_ENTRY ScheduledLink;// mScheduledQueue
> >>
> >> - EFI_HANDLE FvHandle;
> >> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> >>EFI_GUIDFileName;
> >>VOID*Pe32Data;
> >>UINTN Pe32DataSize;
> >> diff --git a/StandaloneMmPkg/Core/Dispatcher.c
> >> b/StandaloneMmPkg/Core/Dispatcher.c
> >> index 3788389f95ed..9853445a64a1 100644
> >> --- a/StandaloneMmPkg/Core/Dispatcher.c
> >> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> >> @@ -5,7 +5,7 @@
> >> is added to the mDiscoveredList. The Before, and After Depex
> >> are
> >> pre-processed as drivers are added to the mDiscoveredList. If
> >> an Apriori
> >> file exists in the FV those drivers are addeded to the
> >> -mScheduledQueue. The mFvHandleList is used to make sure a
> >> +mScheduledQueue. The mFwVolList is used to make sure a
> >> FV is only processed once.
> >>
> >>Step #2 - Dispatch. Remove driver from the mScheduledQueue and load and
> >> @@ -40,13 +40,13 @@
> >> //
> >> // MM Dispatcher Data structures
> >> //
> >> -#define KNOWN_HANDLE_SIGNATURE SIGNATURE_32('k','n','o','w')
> >> +#define KNOWN_FWVOL_SIGNATURE SIGNATURE_32('k','n','o','w')
> >>
> >> typedef struct {
> >> - UINTN Signature;
> >> - LIST_ENTRY Link; // mFvHandleList
> >> - EFI_HANDLE Handle;
> >> -} KNOWN_HANDLE;
> >> + UINTN Signature;
> >> + LIST_ENTRY Link;
Re: [edk2-devel] [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
Hi Laszlo,
Apologies for not getting back earlier as I was travelling. I will have a look
and get back by tomorrow.
cheers,
Achin
On Thu, Oct 03, 2019 at 01:10:53PM +0200, Laszlo Ersek wrote:
> Pinging StandaloneMmPkg maintainers again, for reviewing this patch.
>
> Thanks
> Laszlo
>
> On 09/26/19 14:48, Laszlo Ersek wrote:
> > Achin, Jiewen, Supreeth,
> >
> > can one of you guys please review this patch?
> >
> > Thanks
> > Laszlo
> >
> > On 09/17/19 21:49, Laszlo Ersek wrote:
> >> The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
> >> that every firmware volume is processed only once (every driver in every
> >> firmware volume should be discovered only once). For this, the functions
> >> use a linked list.
> >>
> >> In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
> >> those firmware volumes that have been processed is the EFI_HANDLE on which
> >> the DXE or SMM firmware volume protocol is installed. In the
> >> StandaloneMmPkg core however, the key is the address of the firmware
> >> volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
> >>
> >> (EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
> >> EFI_HANDLE just happens to be specified as (VOID*), and therefore the
> >> conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.
> >>
> >> (The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
> >> copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
> >> flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
> >> specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
> >> conversion.)
> >>
> >> We should not exploit this circumstance. Represent the key type faithfully
> >> instead.
> >>
> >> This is a semantic fix; there is no change in operation.
> >>
> >> Cc: Achin Gupta
> >> Cc: Jiewen Yao
> >> Cc: Supreeth Venkatesh
> >> Signed-off-by: Laszlo Ersek
> >> ---
> >>
> >> Notes:
> >> build-tested only
> >>
> >> StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
> >> StandaloneMmPkg/Core/Dispatcher.c | 80 +++-
> >> StandaloneMmPkg/Core/FwVol.c| 16 ++--
> >> 3 files changed, 52 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> index dcf91bc5e916..23ddbe169faf 100644
> >> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> >> @@ -67,7 +67,7 @@ typedef struct {
> >>
> >>LIST_ENTRY ScheduledLink;// mScheduledQueue
> >>
> >> - EFI_HANDLE FvHandle;
> >> + EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> >>EFI_GUIDFileName;
> >>VOID*Pe32Data;
> >>UINTN Pe32DataSize;
> >> diff --git a/StandaloneMmPkg/Core/Dispatcher.c
> >> b/StandaloneMmPkg/Core/Dispatcher.c
> >> index 3788389f95ed..9853445a64a1 100644
> >> --- a/StandaloneMmPkg/Core/Dispatcher.c
> >> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> >> @@ -5,7 +5,7 @@
> >> is added to the mDiscoveredList. The Before, and After Depex
> >> are
> >> pre-processed as drivers are added to the mDiscoveredList. If
> >> an Apriori
> >> file exists in the FV those drivers are addeded to the
> >> -mScheduledQueue. The mFvHandleList is used to make sure a
> >> +mScheduledQueue. The mFwVolList is used to make sure a
> >> FV is only processed once.
> >>
> >>Step #2 - Dispatch. Remove driver from the mScheduledQueue and load and
> >> @@ -40,13 +40,13 @@
> >> //
> >> // MM Dispatcher Data structures
> >> //
> >> -#define KNOWN_HANDLE_SIGNATURE SIGNATURE_32('k','n','o','w')
> >> +#define KNOWN_FWVOL_SIGNATURE SIGNATURE_32('k','n','o','w')
> >>
> >> typedef struct {
> >> - UINTN Signature;
> >> - LIST_ENTRY Link; // mFvHandleList
> >> - EFI_HANDLE Handle;
> >> -} KNOWN_HANDLE;
> >> + UINTN
