Re: [edk2] Does ARM platform produce MP protocol?

[Achin Gupta]

On Wed, Mar 06, 2019 at 02:22:25PM +0100, Ard Biesheuvel wrote:
> On Wed, 6 Mar 2019 at 13:41, Achin Gupta  wrote:
> >
> > On Wed, Mar 06, 2019 at 10:37:58AM +0100, Ard Biesheuvel wrote:
> > > (adding Achin and Charles)
> > >
> > > On Wed, 6 Mar 2019 at 10:16, Ni, Ray  wrote:
> > > >
> > > > > -Original Message-
> > > > > From: edk2-devel  On Behalf Of Ard
> > > > > Biesheuvel
> > > > > Sent: Wednesday, March 6, 2019 3:38 PM
> > > > > To: Ni, Ray 
> > > > > Cc: edk2-devel@lists.01.org
> > > > > Subject: Re: [edk2] Does ARM platform produce MP protocol?
> > > > >
> > > > > On Wed, 6 Mar 2019 at 06:44, Ni, Ray  wrote:
> > > > > >
> > > > > > Ard, Leif,
> > > > > > I am a bit interested in how ARM platform supports the MP?
> > > > > > PI Spec defines below protocol but I failed to find a driver in ARM 
> > > > > > platform
> > > > > producing this protocol.
> > > > > > Or did I miss anything?
> > > > > >
> > > > >
> > > > > No you are right. We don't expose that on ARM, since UEFI only runs 
> > > > > on a
> > > > > single core. Bringing up and taking down cores is done via a protocol 
> > > > > called
> > > > > PSCI, which is implemented by firmware running at a higher privilege 
> > > > > level.
> > > > >
> > > > > So while it would be possible to implement the MP protocol on top of 
> > > > > PSCI,
> > > > > we haven't identified a use case for it yet. (The OS calls PSCI 
> > > > > directly to boot
> > > > > the secondary cores)
> >
> > IIUC, the MP protocol enables communication between processors that are 
> > already
> > up instead of bringing them up or taking them down. So, it is orthogonal to
> > PSCI. Is that what you meant?
> >
>
> Surely, StartupThisAP starts up the AP, no?

I was talking about the EFI_MM_MP_PROTOCOL which I thought was the original bone
of contention.

PSCI has a direct intersection with the EFI_MP_SERVICES_PROTOCOL.

cheers,
Achin

>
> In any case, I didn't dig any deeper, but I know that PSCI can be used
> (even in the UEFI context) to execute pieces of code on another core
> (ACS uses this IIRC)
>
> > > >
> > > > Is below EFI_MM_MP_PROTOCOL (added in PI spec 1.6) implemented in ARM?
> > > > Or will it be implemented by an ARM module?
> > >
> > > No it is currently not implemented, and I am not aware of any plans to do 
> > > so.
> >
> > +1. There is no need to do this until UEFI runs on a single core on Arm.
> >
>
> until -> as long as ??
>
> > >
> > > > I am asking this because MP_SERVICES protocol exposes CPU location 
> > > > information
> > > > (Package/Core/Thread) through *GetProcessorInfo*, but MM_MP protocol 
> > > > doesn't
> > > > have a way to expose that information.
> > > > If such location information isn't exposed by MM_MP, is that because 
> > > > ARM doesn't
> > > > care about the location information? Or because ARM cares but forgot to 
> > > > add similar
> > > > *GetProcessorInfo* interface to MM_MP when changing the PI spec?
> > > > Or ARM doesn't use the MM_MP at all?
> >
> > Even if Arm used this protocol, it can work with the logical processor 
> > number. I
> > don't see a need to expose the location information to the caller. It seems 
> > very
> > Intel specific. Is the EFI_MP_SERVICES_PROTOCOL used on Arm?
> >
>
> No, that is what started the discussion.
>
> > > >
> > >
> > > I don't know the history of this protocol and who proposed it, but
> > > today, we don't have a need for running per-CPU initialization code in
> > > the context of MM. Even if MM is a component of the more privileged
> > > firmware running on an ARM system, it is running in a sandbox that was
> > > primarily designed around exposing MM services to UEFI code running at
> > > the same privilege level as the OS (such as the authenticated variable
> > > store). Platform initialization code (which is more likely to require
> > > dispatch to each core) runs in the secure world as well, but not in
> > > the context of MM.
> > >
> > > I will let Achin chime in here as well.
> >
> > +1.
> >

Re: [edk2] [PATCH 02/10] StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable

[Achin Gupta]

On Thu, Mar 07, 2019 at 11:09:35AM +0100, Ard Biesheuvel wrote:
> On Wed, 6 Mar 2019 at 16:37, Achin Gupta  wrote:
> >
> > On Wed, Mar 06, 2019 at 04:17:51PM +0100, Ard Biesheuvel wrote:
> > > On Wed, 6 Mar 2019 at 16:16, Achin Gupta  wrote:
> > > >
> > > > Hi Ard,
> > > >
> > > > On Tue, Mar 05, 2019 at 02:32:40PM +0100, Ard Biesheuvel wrote:
> > > > > The PCD PcdStandaloneMmEnable is unused, and shouldn't exist in the
> > > > > first place since the value is implied by the context (it is never
> > > > > valid to set it to FALSE for standalone MM or TRUE for traditional
> > > > > MM). So drop it.
> > > >
> > > > This is being used to determine if the ArmVExpressPkg should include 
> > > > support for
> > > > StMM comm. buffer or not [1] but it does look redundant now.
> > > >
> > >
> > > If that is the case, the PCD should be defined in that package.
> >
> > The Arm FVP port for StMM needs a rewrite on the lines of other platforms. 
> > This
> > change is fine.
> >
>
> Yes, you are right. SynQuacer also needs some tweaks to align with
> these changes, but I will post those separately.
>
> So with those changes merged, the only thing preventing us from
> building the SynQuacer + MM platform from upstream sources is the
> MmCommunicate VA vs PA issue. Is there any progress on that front?

I am looking at this now after my holiday. I have some questions that I will
post separately.

cheers,
Achin

>
> Thanks,
> Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 09/10] StandaloneMmPkg/Core: remove legacy boot support

[Achin Gupta]

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:47PM +0100, Ard Biesheuvel wrote:
> Remove the support for booting 'legacy' (i.e., non-UEFI boot) OSes.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/Core/StandaloneMmCore.h |  22 
>  StandaloneMmPkg/Core/StandaloneMmCore.c | 124 ++--
>  2 files changed, 33 insertions(+), 113 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h 
> b/StandaloneMmPkg/Core/StandaloneMmCore.h
> index 74338dc9da0d..5d336b3dbbf6 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> @@ -635,28 +635,6 @@ MmDriverDispatchHandler (
>
>@return Status Code
>
> -**/
> -EFI_STATUS
> -EFIAPI
> -MmLegacyBootHandler (
> -  IN EFI_HANDLE   DispatchHandle,
> -  IN CONST VOID   *Context,OPTIONAL
> -  IN OUT VOID *CommBuffer, OPTIONAL
> -  IN OUT UINTN*CommBufferSize  OPTIONAL
> -  );
> -
> -/**
> -  This function is the main entry point for an MM handler dispatch
> -  or communicate-based callback.
> -
> -  @param  DispatchHandle  The unique handle assigned to this handler by 
> MmiHandlerRegister().
> -  @param  Context Points to an optional handler context which was 
> specified when the handler was registered.
> -  @param  CommBuffer  A pointer to a collection of data in memory that 
> will
> -  be conveyed from a non-MM environment into an MM 
> environment.
> -  @param  CommBufferSize  The size of the CommBuffer.
> -
> -  @return Status Code
> -
>  **/
>  EFI_STATUS
>  EFIAPI
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.c 
> b/StandaloneMmPkg/Core/StandaloneMmCore.c
> index 766cdb5c848c..fb6b3055e9c6 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.c
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.c
> @@ -87,21 +87,12 @@ EFI_MM_SYSTEM_TABLE  gMmCoreMmst = {
>MmiHandlerUnRegister
>  };
>
> -//
> -// Flag to determine if the platform has performed a legacy boot.
> -// If this flag is TRUE, then the runtime code and runtime data associated 
> with the
> -// MM IPL are converted to free memory, so the MM Core must guarantee that is
> -// does not touch of the code/data associated with the MM IPL if this flag 
> is TRUE.
> -//
> -BOOLEAN  mInLegacyBoot = FALSE;
> -
>  //
>  // Table of MMI Handlers that are registered by the MM Core when it is 
> initialized
>  //
>  MM_CORE_MMI_HANDLERS  mMmCoreMmiHandlers[] = {
>{ MmReadyToLockHandler,,  NULL, TRUE  
> },
>{ MmEndOfDxeHandler,   ,NULL, FALSE 
> },
> -  { MmLegacyBootHandler, ,   NULL, FALSE 
> },
>{ MmExitBootServiceHandler,, NULL, FALSE 
> },
>{ MmReadyToBootHandler,,  NULL, FALSE 
> },
>{ NULL,NULL,   NULL, FALSE 
> },
> @@ -142,47 +133,6 @@ MmEfiNotAvailableYetArg5 (
>return EFI_NOT_AVAILABLE_YET;
>  }
>
> -/**
> -  Software MMI handler that is called when a Legacy Boot event is signaled.  
> The MM
> -  Core uses this signal to know that a Legacy Boot has been performed and 
> that
> -  gMmCorePrivate that is shared between the UEFI and MM execution 
> environments can
> -  not be accessed from MM anymore since that structure is considered free 
> memory by
> -  a legacy OS.
> -
> -  @param  DispatchHandle  The unique handle assigned to this handler by 
> MmiHandlerRegister().
> -  @param  Context Points to an optional handler context which was 
> specified when the handler was registered.
> -  @param  CommBuffer  A pointer to a collection of data in memory that 
> will
> -  be conveyed from a non-MM environment into an MM 
> environment.
> -  @param  CommBufferSize  The size of the CommBuffer.
> -
> -  @return Status Code
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -MmLegacyBootHandler (
> -  IN EFI_HANDLE  DispatchHandle,
> -  IN CONST VOID  *Context,OPTIONAL
> -  IN OUT VOID*CommBuffer, OPTIONAL
> -  IN OUT UINTN   *CommBufferSize  OPTIONAL
> -  )
> -{
> -  EFI_HANDLE  MmHandle;
> -  EFI_STATUS  Status = EFI_SUCCESS;
> -
> -  if (!mInLegacyBoot) {
> -MmHandle = NULL;
> -Status = MmInstallProtocolInterface (
> -   ,
> -   ,
> -   EFI_NATIVE_INTERFACE,
> -   NULL
> -   );
> -  }
> -  mInLegacyBoot = TRUE;
> -  return Status;
> -}
> -
>  /**
>Software MMI handler that is called when a ExitBoot Service event is 
> signaled.
>
> @@ -396,7 +346,6 @@ MmEntryPoint (
>  {
>EFI_STATUS  Status;
>EFI_MM_COMMUNICATE_HEADER  *CommunicateHeader;
> -  BOOLEAN InLegacyBoot;
>
>DEBUG ((DEBUG_INFO, "MmEntryPoint ...\n"));
>
> @@ -413,44 +362,42 @@ MmEntryPoint (
>//
>// If a legacy boot has occured, then make sure gMmCorePrivate is not 
> accessed

Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal architected PI events into MM context

[Achin Gupta]

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:48PM +0100, Ard Biesheuvel wrote:
> PI defines a few architected events that have significance in the MM
> context as well as in the non-secure DXE context. So register notify
> handlers for these events, and relay them into the standalone MM world.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf |  5 +++
>  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c   | 47 
> +++-
>  2 files changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf 
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> index 88beafa39c05..8bf269270f9d 100644
> --- a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> @@ -48,6 +48,11 @@ [LibraryClasses]
>  [Protocols]
>gEfiMmCommunicationProtocolGuid  ## PRODUCES
>
> +[Guids]
> +  gEfiEndOfDxeEventGroupGuid
> +  gEfiEventExitBootServicesGuid
> +  gEfiEventReadyToBootGuid
> +
>  [Pcd.common]
>gArmTokenSpaceGuid.PcdMmBufferBase
>gArmTokenSpaceGuid.PcdMmBufferSize
> diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c 
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> index feb9fa9f4ead..3203cf801a19 100644
> --- a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> @@ -265,6 +265,43 @@ GetMmCompatibility ()
>return Status;
>  }
>
> +STATIC EFI_GUID* CONST mGuidedEventGuid[] = {
> +  ,
> +  ,
> +  ,
> +};
> +
> +STATIC EFI_EVENT mGuidedEvent[ARRAY_SIZE (mGuidedEventGuid)];
> +
> +/**
> +  Event notification that is fired when GUIDed Event Group is signaled.
> +
> +  @param  Event The Event that is being processed, not used.
> +  @param  Context   Event Context, not used.
> +
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +MmGuidedEventNotify (
> +  IN EFI_EVENT  Event,
> +  IN VOID   *Context
> +  )
> +{
> +  EFI_MM_COMMUNICATE_HEADER   Header;
> +  UINTN   Size;
> +
> +  //
> +  // Use Guid to initialize EFI_SMM_COMMUNICATE_HEADER structure
> +  //
> +  CopyGuid (, Context);
> +  Header.MessageLength = 1;
> +  Header.Data[0] = 0;
> +
> +  Size = sizeof (Header);
> +  MmCommunicationCommunicate (, , );
> +}
> +
>  /**
>The Entry Point for MM Communication
>
> @@ -287,6 +324,7 @@ MmCommunicationInitialize (
>)
>  {
>EFI_STATUS Status;
> +  UINTN  Index;
>
>// Check if we can make the MM call
>Status = GetMmCompatibility ();
> @@ -351,8 +389,13 @@ MmCommunicationInitialize (
>NULL,
>
>);
> -  if (Status == EFI_SUCCESS) {
> -return Status;
> +  ASSERT_EFI_ERROR (Status);
> +
> +  for (Index = 0; Index < ARRAY_SIZE (mGuidedEventGuid); Index++) {
> +Status = gBS->CreateEventEx (EVT_NOTIFY_SIGNAL, TPL_CALLBACK,
> +MmGuidedEventNotify, mGuidedEventGuid[Index],
> +mGuidedEventGuid[Index], [Index]);
> +ASSERT_EFI_ERROR (Status);
>}
>
>gBS->UninstallProtocolInterface (
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 08/10] StandaloneMmPkg/Core: drop support for dispatching FVs into MM

[Achin Gupta]

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:46PM +0100, Ard Biesheuvel wrote:
> Remove the support that permits calls into the MM context to dispatch
> firmware volumes that are not part of the initial standalone MM firmware
> volume.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/Core/StandaloneMmCore.h | 22 --
>  StandaloneMmPkg/Core/Dispatcher.c   | 46 
>  StandaloneMmPkg/Core/StandaloneMmCore.c |  1 -
>  3 files changed, 69 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h 
> b/StandaloneMmPkg/Core/StandaloneMmCore.h
> index 0d20bcaa6be5..74338dc9da0d 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> @@ -635,28 +635,6 @@ MmDriverDispatchHandler (
>
>@return Status Code
>
> -**/
> -EFI_STATUS
> -EFIAPI
> -MmFvDispatchHandler (
> -  IN EFI_HANDLE   DispatchHandle,
> -  IN CONST VOID   *Context,OPTIONAL
> -  IN OUT VOID *CommBuffer, OPTIONAL
> -  IN OUT UINTN*CommBufferSize  OPTIONAL
> -  );
> -
> -/**
> -  This function is the main entry point for an MM handler dispatch
> -  or communicate-based callback.
> -
> -  @param  DispatchHandle  The unique handle assigned to this handler by 
> MmiHandlerRegister().
> -  @param  Context Points to an optional handler context which was 
> specified when the handler was registered.
> -  @param  CommBuffer  A pointer to a collection of data in memory that 
> will
> -  be conveyed from a non-MM environment into an MM 
> environment.
> -  @param  CommBufferSize  The size of the CommBuffer.
> -
> -  @return Status Code
> -
>  **/
>  EFI_STATUS
>  EFIAPI
> diff --git a/StandaloneMmPkg/Core/Dispatcher.c 
> b/StandaloneMmPkg/Core/Dispatcher.c
> index bede4832cfb7..4b2f38f700a0 100644
> --- a/StandaloneMmPkg/Core/Dispatcher.c
> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> @@ -883,52 +883,6 @@ MmAddToDriverList (
>return EFI_SUCCESS;
>  }
>
> -/**
> -  This function is the main entry point for an MM handler dispatch
> -  or communicate-based callback.
> -
> -  @param  DispatchHandle  The unique handle assigned to this handler by 
> SmiHandlerRegister().
> -  @param  Context Points to an optional handler context which was 
> specified when the handler was registered.
> -  @param  CommBuffer  A pointer to a collection of data in memory that 
> will
> -  be conveyed from a non-MM environment into an MM 
> environment.
> -  @param  CommBufferSize  The size of the CommBuffer.
> -
> -  @return Status Code
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -MmFvDispatchHandler (
> -  IN EFI_HANDLE   DispatchHandle,
> -  IN CONST VOID   *Context,OPTIONAL
> -  IN OUT VOID *CommBuffer, OPTIONAL
> -  IN OUT UINTN*CommBufferSize  OPTIONAL
> -  )
> -{
> -  EFI_STATUSStatus;
> -  EFI_MM_COMMUNICATE_FV_DISPATCH_DATA  *CommunicationFvDispatchData;
> -  EFI_FIRMWARE_VOLUME_HEADER*FwVolHeader;
> -
> -  DEBUG ((DEBUG_INFO, "MmFvDispatchHandler\n"));
> -
> -  CommunicationFvDispatchData = CommBuffer;
> -
> -  DEBUG ((DEBUG_INFO, "  Dispatch - 0x%016lx - 0x%016lx\n", 
> CommunicationFvDispatchData->Address,
> -  CommunicationFvDispatchData->Size));
> -
> -  FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER 
> *)(UINTN)CommunicationFvDispatchData->Address;
> -
> -  MmCoreFfsFindMmDriver (FwVolHeader);
> -
> -  //
> -  // Execute the MM Dispatcher on any newly discovered FVs and previously
> -  // discovered MM drivers that have been discovered but not dispatched.
> -  //
> -  Status = MmDispatcher ();
> -
> -  return Status;
> -}
> -
>  /**
>Traverse the discovered list for any drivers that were discovered but not 
> loaded
>because the dependency experessions evaluated to false.
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.c 
> b/StandaloneMmPkg/Core/StandaloneMmCore.c
> index ec53b8d8bec4..766cdb5c848c 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.c
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.c
> @@ -99,7 +99,6 @@ BOOLEAN  mInLegacyBoot = FALSE;
>  // Table of MMI Handlers that are registered by the MM Core when it is 
> initialized
>  //
>  MM_CORE_MMI_HANDLERS  mMmCoreMmiHandlers[] = {
> -  { MmFvDispatchHandler, , NULL, TRUE  
> },
>{ MmReadyToLockHandler,,  NULL, TRUE  
> },
>{ MmEndOfDxeHandler,   ,NULL, FALSE 
> },
>{ MmLegacyBootHandler, ,   NULL, FALSE 
> },
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 07/10] StandaloneMmPkg/Core: dispatch all drivers at init time

[Achin Gupta]

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:45PM +0100, Ard Biesheuvel wrote:
> Instead of deferring dispatch of the remaining MM drivers once the
> CPU driver has been dispatched, proceed and dispatch all drivers.
> This makes sense for standalone MM, since all dispatchable drivers
> should be present in the initial firmware volume anyway: dispatch
> of additional FVs originating in the non-secure side is not supported.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/Core/Dispatcher.c   | 92 
>  StandaloneMmPkg/Core/StandaloneMmCore.c |  1 -
>  2 files changed, 93 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/Dispatcher.c 
> b/StandaloneMmPkg/Core/Dispatcher.c
> index 8a2ad5118d92..bede4832cfb7 100644
> --- a/StandaloneMmPkg/Core/Dispatcher.c
> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> @@ -575,7 +575,6 @@ MmDispatcher (
>LIST_ENTRY*Link;
>EFI_MM_DRIVER_ENTRY  *DriverEntry;
>BOOLEAN   ReadyToRun;
> -  BOOLEAN   PreviousMmEntryPointRegistered;
>
>DEBUG ((DEBUG_INFO, "MmDispatcher\n"));
>
> @@ -639,11 +638,6 @@ MmDispatcher (
>DriverEntry->Initialized  = TRUE;
>RemoveEntryList (>ScheduledLink);
>
> -  //
> -  // Cache state of MmEntryPointRegistered before calling entry point
> -  //
> -  PreviousMmEntryPointRegistered = 
> gMmCorePrivate->MmEntryPointRegistered;
> -
>//
>// For each MM driver, pass NULL as ImageHandle
>//
> @@ -661,20 +655,6 @@ MmDispatcher (
>  DEBUG ((DEBUG_INFO, "StartImage Status - %r\n", Status));
>  MmFreePages(DriverEntry->ImageBuffer, DriverEntry->NumberOfPage);
>}
> -
> -  if (!PreviousMmEntryPointRegistered && 
> gMmCorePrivate->MmEntryPointRegistered) {
> -//
> -// Return immediately if the MM Entry Point was registered by the MM
> -// Driver that was just dispatched.  The MM IPL will reinvoke the MM
> -// Core Dispatcher.  This is required so MM Mode may be enabled as 
> soon
> -// as all the dependent MM Drivers for MM Mode have been dispatched.
> -// Once the MM Entry Point has been registered, then MM Mode will be
> -// used.
> -//
> -gRequestDispatch = TRUE;
> -gDispatcherRunning = FALSE;
> -return EFI_NOT_READY;
> -  }
>  }
>
>  //
> @@ -903,78 +883,6 @@ MmAddToDriverList (
>return EFI_SUCCESS;
>  }
>
> -/**
> -  This function is the main entry point for an MM handler dispatch
> -  or communicate-based callback.
> -
> -  Event notification that is fired every time a FV dispatch protocol is 
> added.
> -  More than one protocol may have been added when this event is fired, so you
> -  must loop on MmLocateHandle () to see how many protocols were added and
> -  do the following to each FV:
> -  If the Fv has already been processed, skip it. If the Fv has not been
> -  processed then mark it as being processed, as we are about to process it.
> -  Read the Fv and add any driver in the Fv to the mDiscoveredList.The
> -  mDiscoveredList is never free'ed and contains variables that define
> -  the other states the MM driver transitions to..
> -  While you are at it read the A Priori file into memory.
> -  Place drivers in the A Priori list onto the mScheduledQueue.
> -
> -  @param  DispatchHandle  The unique handle assigned to this handler by 
> SmiHandlerRegister().
> -  @param  Context Points to an optional handler context which was 
> specified when the handler was registered.
> -  @param  CommBuffer  A pointer to a collection of data in memory that 
> will
> -  be conveyed from a non-MM environment into an MM 
> environment.
> -  @param  CommBufferSize  The size of the CommBuffer.
> -
> -  @return Status Code
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -MmDriverDispatchHandler (
> -  IN EFI_HANDLE  DispatchHandle,
> -  IN CONST VOID  *Context,OPTIONAL
> -  IN OUT VOID*CommBuffer, OPTIONAL
> -  IN OUT UINTN   *CommBufferSize  OPTIONAL
> -  )
> -{
> -  EFI_STATUSStatus;
> -
> -  DEBUG ((DEBUG_INFO, "MmDriverDispatchHandler\n"));
> -
> -  //
> -  // Execute the MM Dispatcher on any newly discovered FVs and previously
> -  // discovered MM drivers that have been discovered but not dispatched.
> -  //
> -  Status = MmDispatcher ();
> -
> -  //
> -  // Check to see if CommBuffer and CommBufferSize are valid
> -  //
> -  if (CommBuffer != NULL && CommBufferSize != NULL) {
> -if (*CommBufferSize > 0) {
> -  if (Status == EFI_NOT_READY) {
> -//
> -// If a the MM Core Entry Point was just registered, then set flag to
> -// request the MM Dispatcher to be restarted.
> -//
> -*(UINT8 *)CommBuffer = COMM_BUFFER_MM_DISPATCH_RESTART;
> -  } else if (!EFI_ERROR (Status)) {
> -//
> -// 

Re: [edk2] [PATCH 06/10] StandaloneMmPkg/Core: permit encapsulated firmware volumes

[Achin Gupta]

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:44PM +0100, Ard Biesheuvel wrote:
> Standalone MM requires 4 KB section alignment for all images, so that
> strict permissions can be applied. Unfortunately, this results in a
> lot of wasted space, which is usually costly in the secure world
> environment that standalone MM is expected to operate in.
>
> So let's permit the standalone MM drivers (but not the core) to be
> delivered in a compressed firmware volume.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/Core/StandaloneMmCore.inf |  1 +
>  StandaloneMmPkg/Core/FwVol.c  | 99 ++--
>  2 files changed, 91 insertions(+), 9 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf 
> b/StandaloneMmPkg/Core/StandaloneMmCore.inf
> index ff2b8b9cef03..83d31e2d92c5 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
> @@ -49,6 +49,7 @@ [LibraryClasses]
>BaseMemoryLib
>CacheMaintenanceLib
>DebugLib
> +  ExtractGuidedSectionLib
>FvLib
>HobLib
>MemoryAllocationLib
> diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
> index 5abf98c24797..d95491f252f9 100644
> --- a/StandaloneMmPkg/Core/FwVol.c
> +++ b/StandaloneMmPkg/Core/FwVol.c
> @@ -14,6 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>
>  #include "StandaloneMmCore.h"
>  #include 
> +#include 
>
>  //
>  // List of file types supported by dispatcher
> @@ -65,15 +66,25 @@ Returns:
>
>  --*/
>  {
> -  EFI_STATUS  Status;
> -  EFI_STATUS  DepexStatus;
> -  EFI_FFS_FILE_HEADER *FileHeader;
> -  EFI_FV_FILETYPE FileType;
> -  VOID*Pe32Data;
> -  UINTN   Pe32DataSize;
> -  VOID*Depex;
> -  UINTN   DepexSize;
> -  UINTN   Index;
> +  EFI_STATUS  Status;
> +  EFI_STATUS  DepexStatus;
> +  EFI_FFS_FILE_HEADER *FileHeader;
> +  EFI_FV_FILETYPE FileType;
> +  VOID*Pe32Data;
> +  UINTN   Pe32DataSize;
> +  VOID*Depex;
> +  UINTN   DepexSize;
> +  UINTN   Index;
> +  EFI_COMMON_SECTION_HEADER   *Section;
> +  VOID*SectionData;
> +  UINTN   SectionDataSize;
> +  UINT32  DstBufferSize;
> +  VOID*ScratchBuffer;
> +  UINT32  ScratchBufferSize;
> +  VOID*DstBuffer;
> +  UINT16  SectionAttribute;
> +  UINT32  AuthenticationStatus;
> +  EFI_FIRMWARE_VOLUME_HEADER  *InnerFvHeader;
>
>DEBUG ((DEBUG_INFO, "MmCoreFfsFindMmDriver - 0x%x\n", FwVolHeader));
>
> @@ -83,6 +94,71 @@ Returns:
>
>FvIsBeingProcesssed (FwVolHeader);
>
> +  //
> +  // First check for encapsulated compressed firmware volumes
> +  //
> +  FileHeader = NULL;
> +  do {
> +Status = FfsFindNextFile (EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE,
> +   FwVolHeader, );
> +if (EFI_ERROR (Status)) {
> +  break;
> +}
> +Status = FfsFindSectionData (EFI_SECTION_GUID_DEFINED, FileHeader,
> +   , );
> +if (EFI_ERROR (Status)) {
> +  break;
> +}
> +Section = (EFI_COMMON_SECTION_HEADER *)(FileHeader + 1);
> +Status = ExtractGuidedSectionGetInfo (Section, ,
> +   , );
> +if (EFI_ERROR (Status)) {
> +  break;
> +}
> +
> +//
> +// Allocate scratch buffer
> +//
> +ScratchBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES 
> (ScratchBufferSize));
> +if (ScratchBuffer == NULL) {
> +  return EFI_OUT_OF_RESOURCES;
> +}
> +
> +//
> +// Allocate destination buffer, extra one page for adjustment
> +//
> +DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES 
> (DstBufferSize));
> +if (DstBuffer == NULL) {
> +  return EFI_OUT_OF_RESOURCES;
> +}
> +
> +//
> +// Call decompress function
> +//
> +Status = ExtractGuidedSectionDecode (Section, , ScratchBuffer,
> +);
> +FreePages (ScratchBuffer, EFI_SIZE_TO_PAGES (ScratchBufferSize));
> +if (EFI_ERROR (Status)) {
> +  goto FreeDstBuffer;
> +}
> +
> +DEBUG ((DEBUG_INFO,
> +  "Processing compressed firmware volume (AuthenticationStatus == %x)\n",
> +  AuthenticationStatus));
> +
> +Status = FindFfsSectionInSections (DstBuffer, DstBufferSize,
> +   EFI_SECTION_FIRMWARE_VOLUME_IMAGE, );
> +if (EFI_ERROR (Status)) {
> +  goto FreeDstBuffer;
> +}
> +
> +

Re: [edk2] [PATCH 05/10] StandaloneMmPkg/StandaloneMmCoreEntryPoint: drop explicit SerialPortLib call

[Achin Gupta]

On Wed, Mar 06, 2019 at 05:41:30PM +0100, Ard Biesheuvel wrote:
> On Wed, 6 Mar 2019 at 17:35, Achin Gupta  wrote:
> >
> > Hi Ard,
> >
> > On Tue, Mar 05, 2019 at 02:32:43PM +0100, Ard Biesheuvel wrote:
> > > Sending DEBUG output to the serial port should only be done via
> > > DebugLib calls, which is in charge of initializing the serial
> > > port when appropriate. So drop the explicit SerialPortInitialize ()
> > > invocation, and rely on normal constructor ordering to get the
> > > serial port into the appropriate state at the right time.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel 
> > > ---
> > >  
> > > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > >  | 3 ---
> > >  1 file changed, 3 deletions(-)
> > >
> > > diff --git 
> > > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > >  
> > > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > > index 5cca532456fd..c8e11a253d24 100644
> > > --- 
> > > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > > +++ 
> > > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > > @@ -232,9 +232,6 @@ _ModuleEntryPoint (
> > >VOID*TeData;
> > >UINTN   TeDataSize;
> > >
> > > -  Status = SerialPortInitialize ();
> > > -  ASSERT_EFI_ERROR (Status);
> >
> > This is done in the first few instructions after EL3 ERETs into S-EL0 to
> > initialise the StMM partition. The constructors will be called a bit later. 
> > I
> > agree with the change but does EDK2 provide a mechanism for early prints to 
> > the
> > console in case we need this in future.
> >
>
> If so, the correct way to achieve this would be to call the DebugLib
> constructor by hand, and that should call the SerialPortLib
> constructor. Unfortunately, EDK2 is not put together like that, and
> especially constructor ordering is slightly broken.

Thanks!

Reviewed-by: achin.gu...@arm.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 05/10] StandaloneMmPkg/StandaloneMmCoreEntryPoint: drop explicit SerialPortLib call

[Achin Gupta]

Hi Ard,

On Tue, Mar 05, 2019 at 02:32:43PM +0100, Ard Biesheuvel wrote:
> Sending DEBUG output to the serial port should only be done via
> DebugLib calls, which is in charge of initializing the serial
> port when appropriate. So drop the explicit SerialPortInitialize ()
> invocation, and rely on normal constructor ordering to get the
> serial port into the appropriate state at the right time.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
>  | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git 
> a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
>  
> b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> index 5cca532456fd..c8e11a253d24 100644
> --- 
> a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> +++ 
> b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> @@ -232,9 +232,6 @@ _ModuleEntryPoint (
>VOID*TeData;
>UINTN   TeDataSize;
>
> -  Status = SerialPortInitialize ();
> -  ASSERT_EFI_ERROR (Status);

This is done in the first few instructions after EL3 ERETs into S-EL0 to
initialise the StMM partition. The constructors will be called a bit later. I
agree with the change but does EDK2 provide a mechanism for early prints to the
console in case we need this in future.

cheers,
Achin

> -
>// Get Secure Partition Manager Version Information
>Status = GetSpmVersion ();
>if (EFI_ERROR (Status)) {
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 03/10] StandaloneMmPkg: switch to NULL DebugLib resolution

[Achin Gupta]

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:41PM +0100, Ard Biesheuvel wrote:
> Building StandaloneMmPkg from its .DSC is mainly intended for build
> coverage, and so platform specific configuration such as UART addresses
> don't belong here.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/StandaloneMmPkg.dsc | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/StandaloneMmPkg/StandaloneMmPkg.dsc 
> b/StandaloneMmPkg/StandaloneMmPkg.dsc
> index f279d9e7e5c7..8def9688fe7d 100644
> --- a/StandaloneMmPkg/StandaloneMmPkg.dsc
> +++ b/StandaloneMmPkg/StandaloneMmPkg.dsc
> @@ -43,7 +43,7 @@ [LibraryClasses]
>#
>BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
>BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> -  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
>
> DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
>FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf
>
> HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
> @@ -66,10 +66,6 @@ [LibraryClasses.AARCH64]
>ArmSvcLib|ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf
>
> CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
>
> PeCoffExtraActionLib|StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
> -  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
> -  
> PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
> -  # ARM PL011 UART Driver
> -  
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>
>
> StandaloneMmCoreEntryPoint|StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
>
> @@ -83,11 +79,6 @@ [PcdsFixedAtBuild]
>gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xff
>gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x0f
>
> -[PcdsFixedAtBuild.AARCH64]
> -  ## PL011 - Serial Terminal
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c0b
> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
> -
>  
> ###
>  #
>  # Components Section - list of the modules and components that will be 
> processed by compilation
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 02/10] StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable

[Achin Gupta]

On Wed, Mar 06, 2019 at 04:17:51PM +0100, Ard Biesheuvel wrote:
> On Wed, 6 Mar 2019 at 16:16, Achin Gupta  wrote:
> >
> > Hi Ard,
> >
> > On Tue, Mar 05, 2019 at 02:32:40PM +0100, Ard Biesheuvel wrote:
> > > The PCD PcdStandaloneMmEnable is unused, and shouldn't exist in the
> > > first place since the value is implied by the context (it is never
> > > valid to set it to FALSE for standalone MM or TRUE for traditional
> > > MM). So drop it.
> >
> > This is being used to determine if the ArmVExpressPkg should include 
> > support for
> > StMM comm. buffer or not [1] but it does look redundant now.
> >
>
> If that is the case, the PCD should be defined in that package.

The Arm FVP port for StMM needs a rewrite on the lines of other platforms. This
change is fine.

Reviewed-by: achin.gu...@arm.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 02/10] StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable

[Achin Gupta]

Hi Ard,

On Tue, Mar 05, 2019 at 02:32:40PM +0100, Ard Biesheuvel wrote:
> The PCD PcdStandaloneMmEnable is unused, and shouldn't exist in the
> first place since the value is implied by the context (it is never
> valid to set it to FALSE for standalone MM or TRUE for traditional
> MM). So drop it.

This is being used to determine if the ArmVExpressPkg should include support for
StMM comm. buffer or not [1] but it does look redundant now.

cheers,
Achin

[1] https://lists.01.org/pipermail/edk2-devel/2018-December/034432.html

>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/StandaloneMmPkg.dec  
>  | 3 ---
>  StandaloneMmPkg/StandaloneMmPkg.dsc  
>  | 3 ---
>  
> StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
>  | 3 ---
>  3 files changed, 9 deletions(-)
>
> diff --git a/StandaloneMmPkg/StandaloneMmPkg.dec 
> b/StandaloneMmPkg/StandaloneMmPkg.dec
> index 0b5fbf9e1767..2d178c5e20a6 100644
> --- a/StandaloneMmPkg/StandaloneMmPkg.dec
> +++ b/StandaloneMmPkg/StandaloneMmPkg.dec
> @@ -39,6 +39,3 @@ [Guids]
>gEfiStandaloneMmNonSecureBufferGuid  = { 0xf00497e3, 0xbfa2, 0x41a1, { 
> 0x9d, 0x29, 0x54, 0xc2, 0xe9, 0x37, 0x21, 0xc5 }}
>gEfiArmTfCpuDriverEpDescriptorGuid   = { 0x6ecbd5a1, 0xc0f8, 0x4702, { 
> 0x83, 0x01, 0x4f, 0xc2, 0xc5, 0x47, 0x0a, 0x51 }}
>
> -[PcdsFeatureFlag]
> -  
> gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|FALSE|BOOLEAN|0x0001
> -
> diff --git a/StandaloneMmPkg/StandaloneMmPkg.dsc 
> b/StandaloneMmPkg/StandaloneMmPkg.dsc
> index e8d71ad56f52..f279d9e7e5c7 100644
> --- a/StandaloneMmPkg/StandaloneMmPkg.dsc
> +++ b/StandaloneMmPkg/StandaloneMmPkg.dsc
> @@ -78,9 +78,6 @@ [LibraryClasses.AARCH64]
>  # Pcd Section - list of all EDK II PCD Entries defined by this Platform
>  #
>  
> 
> -[PcdsFeatureFlag]
> -  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|TRUE
> -
>  [PcdsFixedAtBuild]
>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80CF
>gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xff
> diff --git 
> a/StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
>  
> b/StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
> index eef3d7c6e253..181c15b9345a 100644
> --- 
> a/StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
> +++ 
> b/StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
> @@ -37,9 +37,6 @@ [Packages]
>MdePkg/MdePkg.dec
>StandaloneMmPkg/StandaloneMmPkg.dec
>
> -[FeaturePcd]
> -  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
> -
>  [LibraryClasses]
>StandaloneMmMmuLib
>PcdLib
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Does ARM platform produce MP protocol?

[Achin Gupta]

On Wed, Mar 06, 2019 at 10:37:58AM +0100, Ard Biesheuvel wrote:
> (adding Achin and Charles)
>
> On Wed, 6 Mar 2019 at 10:16, Ni, Ray  wrote:
> >
> > > -Original Message-
> > > From: edk2-devel  On Behalf Of Ard
> > > Biesheuvel
> > > Sent: Wednesday, March 6, 2019 3:38 PM
> > > To: Ni, Ray 
> > > Cc: edk2-devel@lists.01.org
> > > Subject: Re: [edk2] Does ARM platform produce MP protocol?
> > >
> > > On Wed, 6 Mar 2019 at 06:44, Ni, Ray  wrote:
> > > >
> > > > Ard, Leif,
> > > > I am a bit interested in how ARM platform supports the MP?
> > > > PI Spec defines below protocol but I failed to find a driver in ARM 
> > > > platform
> > > producing this protocol.
> > > > Or did I miss anything?
> > > >
> > >
> > > No you are right. We don't expose that on ARM, since UEFI only runs on a
> > > single core. Bringing up and taking down cores is done via a protocol 
> > > called
> > > PSCI, which is implemented by firmware running at a higher privilege 
> > > level.
> > >
> > > So while it would be possible to implement the MP protocol on top of PSCI,
> > > we haven't identified a use case for it yet. (The OS calls PSCI directly 
> > > to boot
> > > the secondary cores)

IIUC, the MP protocol enables communication between processors that are already
up instead of bringing them up or taking them down. So, it is orthogonal to
PSCI. Is that what you meant?

> >
> > Is below EFI_MM_MP_PROTOCOL (added in PI spec 1.6) implemented in ARM?
> > Or will it be implemented by an ARM module?
>
> No it is currently not implemented, and I am not aware of any plans to do so.

+1. There is no need to do this until UEFI runs on a single core on Arm.

>
> > I am asking this because MP_SERVICES protocol exposes CPU location 
> > information
> > (Package/Core/Thread) through *GetProcessorInfo*, but MM_MP protocol doesn't
> > have a way to expose that information.
> > If such location information isn't exposed by MM_MP, is that because ARM 
> > doesn't
> > care about the location information? Or because ARM cares but forgot to add 
> > similar
> > *GetProcessorInfo* interface to MM_MP when changing the PI spec?
> > Or ARM doesn't use the MM_MP at all?

Even if Arm used this protocol, it can work with the logical processor number. I
don't see a need to expose the location information to the caller. It seems very
Intel specific. Is the EFI_MP_SERVICES_PROTOCOL used on Arm?

> >
>
> I don't know the history of this protocol and who proposed it, but
> today, we don't have a need for running per-CPU initialization code in
> the context of MM. Even if MM is a component of the more privileged
> firmware running on an ARM system, it is running in a sandbox that was
> primarily designed around exposing MM services to UEFI code running at
> the same privilege level as the OS (such as the authenticated variable
> store). Platform initialization code (which is more likely to require
> dispatch to each core) runs in the secure world as well, but not in
> the context of MM.
>
> I will let Achin chime in here as well.

+1.

I will let Charles comment on the history. Maybe this protocol was designed
for Arm systems where MM is the most privileged firmware. The upstream
implementation runs MM in the lowest privilege level. Either way, this protocol
sense only when MM on Arm is MP capable.

cheers,
Achin


>
>
> > typedef struct _EFI_MM_MP_PROTOCOL {
> > UINT32   Revision,
> > UINT32   Attributes,
> > EFI_MM_ GET_NUMBER_OF_PROCESSORS GetNumberOfProcessors,
> > EFI_MM_DISPATCH_PROCEDUREDispatchProcedure,
> > EFI_MM_BROADCAST_PROCEDURE   BroadcastProcedure,
> > EFI_MM_SET_STARTUP_PROCEDURE SetStartupProcedure,
> > EFI_CHECK_FOR_PROCEDURE  CheckOnProcedure,
> > EFI_WAIT_FOR_PROCEDURE   WaitForProcedure,
> > }EFI_MM_MP_PROTOCOL;
> > >
> > > > typedef struct _EFI_MP_SERVICES_PROTOCOL {
> > > > EFI_MP_SERVICES_GET_NUMBER_OF_PROCESSORS
> > > GetNumberOfProcessors;
> > > > EFI_MP_SERVICES_GET_PROCESSOR_INFO GetProcessorInfo;
> > > > EFI_MP_SERVICES_STARTUP_ALL_APS StartupAllAPs;
> > > > EFI_MP_SERVICES_STARTUP_THIS_AP StartupThisAP;
> > > > EFI_MP_SERVICES_SWITCH_BSP SwitchBSP;
> > > EFI_MP_SERVICES_ENABLEDISABLEAP
> > > > EnableDisableAP; EFI_MP_SERVICES_WHOAMI WhoAmI; }
> > > > EFI_MP_SERVICES_PROTOCOL;
> > > >
> > > > Thanks,
> > > > Ray
> > > ___
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list

Re: [edk2] [PATCH v2 00/11] StandaloneMmPkg: assorted fixes and improvements

[Achin Gupta]

Hi Ard,

For all the patches...

Reviewed-by: Achin Gupta 

Jiewen. There are changes to the generic Standalone MM code in this series. Do 
you want to have a look as well?

cheers,
Achin 

From: Ard Biesheuvel 
Sent: 16 January 2019 20:22
To: edk2-devel@lists.01.org
Cc: Ard Biesheuvel; Achin Gupta; Jiewen Yao; Supreeth Venkatesh; Leif Lindholm; 
Jagadeesh Ujja; Thomas Abraham; Sami Mujawar
Subject: [PATCH v2 00/11] StandaloneMmPkg: assorted fixes and improvements

This series addresses a number of issues I ran into while bringing up
the standalone MM based authenticated variable store on the SynQuacer
(AArch64) platform.

Patches #1 - #3 are based on Jagadeesh's patch that imports some staging
code into StandaloneMmPkg, with the following changes:
- drop unused source files, GUID references are other unused bit,
- clean up comments referring to the MM core implementation.

Patches #4 - #9 are obvious fixes/improvements.

Patch #10 adds support for TE formatted MM_CORE_STANDALONE binaries.
This is useful given that the 4 KB section alignment we require in
AArch64 implementations of standalone MM (due to the strict separation
between code and date) results in 8 KB of wasted space at the start of
the firmware volume. This can be reduced to 4 KB when using a TE image
and the FIXED attribute in the associated [Rule] section, by leveraging
an existing optimization in the FFS generation code that aligns TE images
by reducing FFS padding rather than adding more.

Patch #11 is another space optimization: it reuses the existing support
for encapsulated compressed firmware volumes in FFS files to shrink the
size of the primary standalone MM FV considerably. Again, due to
alignment requirements, there is significant bloat in the uncompressed
images (4 KB for the PE/COFF header, and up to 4 KB per section for the
.text, .data and .reloc sections), making the absolute minimum size of
any trivial MM_STANDALONE module 16 KB.

Changes since v1:
- add patches #1 - #3
- add Supreeth's ack to patches #4 - #7

Cc: Achin Gupta 
Cc: Jiewen Yao 
Cc: Supreeth Venkatesh 
Cc: Leif Lindholm 
Cc: Jagadeesh Ujja 
Cc: Thomas Panakamattam Abraham 
Cc: Sami Mujawar 

Ard Biesheuvel (11):
  StandaloneMmPkg: add HobLib implementation for MM_STANDALONE modules
  StandaloneMmPkg: add MM_STANDALONE MemoryAllocationLib implementation
  StandaloneMmPkg/StandaloneMmCoreHobLib: restrict to MM_CORE_STANDALONE
  StandaloneMmPkg/StandaloneMmCpu: fix typo Standlone -> Standalone
  StandaloneMmPkg/StandaloneMmCoreEntryPoint: add missing SerialPortLib
ref
  StandaloneMmPkg/StandaloneMmCoreEntryPoint: use %a modifier for ASCII
strings
  StandaloneMmPkg/StandaloneMmCoreEntryPoint: remove bogus
ASSERT_EFI_ERROR()s
  StandaloneMmPkg/StandaloneMmPeCoffExtraActionLib: ignore runtime
attribute
  StandaloneMmPkg/Core/Dispatcher: don't copy dispatched image twice
  StandaloneMmPkg/StandaloneMmCoreEntryPoint: permit the use of TE
images
  StandaloneMmPkg/Core: permit encapsulated firmware volumes

 StandaloneMmPkg/Core/Dispatcher.c |  30 +-
 StandaloneMmPkg/Core/FwVol.c  |  99 ++-
 StandaloneMmPkg/Core/StandaloneMmCore.inf |   1 +
 .../StandaloneMmCpu/AArch64/EventHandle.c |   2 +-
 .../StandaloneMmCpu/AArch64/StandaloneMmCpu.c |   6 +-
 .../StandaloneMmCpu/AArch64/StandaloneMmCpu.h |   8 +-
 .../AArch64/StandaloneMmCpu.inf   |   4 +-
 .../AArch64/SetPermissions.c  | 109 +--
 .../AArch64/StandaloneMmCoreEntryPoint.c  |   7 +-
 .../StandaloneMmCoreEntryPoint.inf|   4 +
 .../StandaloneMmCoreHobLib.inf|   2 +-
 .../StandaloneMmHobLib/StandaloneMmHobLib.c   | 649 ++
 .../StandaloneMmHobLib/StandaloneMmHobLib.inf |  45 +
 .../StandaloneMmMemoryAllocationLib.c | 822 ++
 .../StandaloneMmMemoryAllocationLib.inf   |  42 +
 .../StandaloneMmPeCoffExtraActionLib.c|   9 +-
 16 files changed, 1716 insertions(+), 123 deletions(-)
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf

--
2.17.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 04/11] MdePkg/Include: Add StandaloneMmServicesTableLib library

[Achin Gupta]

On Mon, Jan 07, 2019 at 07:55:36PM +0100, Ard Biesheuvel wrote:
> On Mon, 7 Jan 2019 at 19:50, Achin Gupta  wrote:
> >
> > On Mon, Jan 07, 2019 at 06:33:26PM +0100, Ard Biesheuvel wrote:
> > > On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek  wrote:
> > > >
> > > > On 01/04/19 12:57, Ard Biesheuvel wrote:
> > > > > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek  wrote:
> > > > >>
> > > > >> On 01/03/19 12:03, Ard Biesheuvel wrote:
> > > > >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja 
> > > > >>>  wrote:
> > > > >>>>
> > > > >>>> Some of the existing DXE drivers can be refactored to execute 
> > > > >>>> within
> > > > >>>> the Standalone MM execution environment as well. Allow such 
> > > > >>>> drivers to
> > > > >>>> get access to the Standalone MM services tables.
> > > > >>>>
> > > > >>>> Add a mechanism to determine the execution mode is required.
> > > > >>>> i.e, in MM or non-MM
> > > > >>>>
> > > > >>>> Contributed-under: TianoCore Contribution Agreement 1.1
> > > > >>>> Signed-off-by: Jagadeesh Ujja 
> > > > >>>> ---
> > > > >>>>  MdePkg/Include/Library/StandaloneMmServicesTableLib.h 
> > > > >>>>| 43 
> > > > >>>>  
> > > > >>>> MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
> > > > >>>>| 39 ++
> > > > >>>>  
> > > > >>>> MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
> > > > >>>>  | 36 
> > > > >>>>  MdePkg/MdePkg.dec 
> > > > >>>>|  4 ++
> > > > >>>>  4 files changed, 122 insertions(+)
> > > > >>>>
> > > > >>>
> > > > >>> OK, so since the PI spec only refers to MM mode now, this library
> > > > >>> class should be
> > > > >>>
> > > > >>> MmServicesTableLib|Include/Library/MmServicesTableLib.h
> > > > >>>
> > > > >>> with an implementation in MdeModulePkg that exposes the deprecated 
> > > > >>> SMM
> > > > >>> system table as the MM system table.
> > > > >>>
> > > > >>> In StandaloneMmPkg, we can add an implementation that exposes the
> > > > >>> standalone MM system table.
> > > > >>>
> > > > >>> (They are binary compatible, so it is just a matter of casting one
> > > > >>> pointer to the other)
> > > > >>>
> > > > >>> With this in place, we can go ahead and update FaultTolerantWrite 
> > > > >>> and
> > > > >>> Variable SMM driver to switch from SmmServicesTableLib to
> > > > >>> MmServicesTableLib. This will require existing x86 platforms to 
> > > > >>> define
> > > > >>> a new library class resolution for MmServicesTableLib, referring to
> > > > >>> the implementation in MdeModulePkg. This is unfortunate, but it is 
> > > > >>> an
> > > > >>> unavoidable consequence of the PI spec changes.
> > > > >>
> > > > >> It shouldn't be too intrusive or hard to review, I expect.
> > > > >>
> > > > >>>
> > > > >>> Remaining question is what to do with InSmm() ...
> > > > >>
> > > > >> I'm lacking the context on this; on the other hand, I can refer back 
> > > > >> to
> > > > >> at least one earlier discussion -- there had been multiple -- of the
> > > > >> discrepancy between the PI spec and the edk2 code. See:
> > > > >>
> > > > >> - bullet (9) in
> > > > >> <http://mid.mail-archive.com/aada511c-bdb9-d833-caa5-bee56cc47d27@redhat.com>,
> > > > >> - and
> > > > >> <http://mid.mail-archive.com/0C09AFA07DD0434D9E2A0C6AEB0483103BB55B46@shsmsx102.ccr.corp.intel.com>.
> > > > 

Re: [edk2] [PATCH v2 04/11] MdePkg/Include: Add StandaloneMmServicesTableLib library

[Achin Gupta]

On Mon, Jan 07, 2019 at 06:33:26PM +0100, Ard Biesheuvel wrote:
> On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek  wrote:
> >
> > On 01/04/19 12:57, Ard Biesheuvel wrote:
> > > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek  wrote:
> > >>
> > >> On 01/03/19 12:03, Ard Biesheuvel wrote:
> > >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja  
> > >>> wrote:
> > 
> >  Some of the existing DXE drivers can be refactored to execute within
> >  the Standalone MM execution environment as well. Allow such drivers to
> >  get access to the Standalone MM services tables.
> > 
> >  Add a mechanism to determine the execution mode is required.
> >  i.e, in MM or non-MM
> > 
> >  Contributed-under: TianoCore Contribution Agreement 1.1
> >  Signed-off-by: Jagadeesh Ujja 
> >  ---
> >   MdePkg/Include/Library/StandaloneMmServicesTableLib.h 
> > | 43 
> >   
> >  MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
> > | 39 ++
> >   
> >  MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
> >   | 36 
> >   MdePkg/MdePkg.dec 
> > |  4 ++
> >   4 files changed, 122 insertions(+)
> > 
> > >>>
> > >>> OK, so since the PI spec only refers to MM mode now, this library
> > >>> class should be
> > >>>
> > >>> MmServicesTableLib|Include/Library/MmServicesTableLib.h
> > >>>
> > >>> with an implementation in MdeModulePkg that exposes the deprecated SMM
> > >>> system table as the MM system table.
> > >>>
> > >>> In StandaloneMmPkg, we can add an implementation that exposes the
> > >>> standalone MM system table.
> > >>>
> > >>> (They are binary compatible, so it is just a matter of casting one
> > >>> pointer to the other)
> > >>>
> > >>> With this in place, we can go ahead and update FaultTolerantWrite and
> > >>> Variable SMM driver to switch from SmmServicesTableLib to
> > >>> MmServicesTableLib. This will require existing x86 platforms to define
> > >>> a new library class resolution for MmServicesTableLib, referring to
> > >>> the implementation in MdeModulePkg. This is unfortunate, but it is an
> > >>> unavoidable consequence of the PI spec changes.
> > >>
> > >> It shouldn't be too intrusive or hard to review, I expect.
> > >>
> > >>>
> > >>> Remaining question is what to do with InSmm() ...
> > >>
> > >> I'm lacking the context on this; on the other hand, I can refer back to
> > >> at least one earlier discussion -- there had been multiple -- of the
> > >> discrepancy between the PI spec and the edk2 code. See:
> > >>
> > >> - bullet (9) in
> > >> ,
> > >> - and
> > >> .
> > >>
> > >> Not sure how that can be applied to Arm.
> > >>
> > >
> > > The code I posted yesterday does not use InMm() at all. For standalone
> > > MM, it should always return TRUE anyway, and any code that a driver
> > > would execute if it returned FALSE needs to be factored out anyway,
> > > since it should not end up in standalone MM binaries as dead code.
> > >
> >
> > OK. That seems to make sense. I've read up a bit on "standalone MM" in
> > the PI v1.6 spec, vol 4. Having no access to UEFI protocols even in the
> > entry point function, at driver init time, seems challenging to me. I
> > guess I'll learn more about this as a part of the usual list traffic.
> >
> > What is the MODULE_TYPE that standalone MM drivers use, in place of
> > DXE_SMM_DRIVER (= EFI_FV_FILETYPE_MM, 0x0A)?
> >
> > Hm... from the other patches, it seems to be MM_STANDALONE (=
> > EFI_FV_FILETYPE_MM_STANDALONE, 0x0E). OK.
> >
> > If I'd like to see a short summary of standalone MM, relative to
> > traditional MM, and why it is more suitable -- I presume -- for aarch64,
> > which document should I look at, from
> > , for example?
> >
> 
> Perhaps Achin can answer this, since he has been driving the spec side
> of this? (and maintains StandaloneMmPkg)

The idea behind MM Standalone mode was to sandbox MM code in self sufficient
execution context. This was a step to avoid some of the vulnerabilities in
traditional SMM due to code and data sharing with DXE. 

On AArch64, the MM standalone mode is initialised during the SEC phase. This
corresponds to Trustzone initialisation. Furthermore, the MM standalone
execution context is placed in user mode (Secure EL0) instead of running it in a
privileged processor mode (S-EL1 or EL3 on AArch64, Ring -2 or SMM on x86). This
restricts what the MM standalone context can see and do. Lastly, after SEC no
more MM Standalone drivers can be initialized during PEI or DXE (in contrast to
the example in PI 1.6 Section 1.5.2). 

Hope that makes sense?

I have not seen 

Re: [edk2] [edk2-platforms PATCH v2 0/2] *** Enable Standalone Management Mode Core Interface on AARCH64 FVP ***

[Achin Gupta]

Hi Ard,

Sorry for the delay. I have posted these now. 

cheers,
Achin

From: Ard Biesheuvel 
Sent: 12 December 2018 22:04
To: Achin Gupta
Cc: Supreeth Venkatesh; Leif Lindholm; edk2-devel@lists.01.org; nd
Subject: Re: [edk2-platforms PATCH v2 0/2] *** Enable Standalone Management 
Mode Core Interface on AARCH64 FVP ***

On Sun, 9 Dec 2018 at 17:32, Achin Gupta  wrote:
>
> Hi Leif,Ard,
>
> These patches are the last bits to complete support for Standalone MM on the
> FVP. All other patches have been merged now. Could you please review these?
>

Sure.

Could they be rebased onto current edk2-platforms and resent please?

Thanks

> On Fri, May 04, 2018 at 09:44:34PM +0100, Supreeth Venkatesh wrote:
> > ***
> > PI Specification v1.5 "Volume 4: Management Mode Core Interface"
> > introduces the concept of MM Standalone Mode. This patchset enables
> > Standalone Management Mode Core Interface on AARCH64 FVP.
> > ***
> >
> > Supreeth Venkatesh (2):
> >   VExpressPkg: Add dsc and fdf files for generating Standalone MM Image.
> >   Platform/VExpressPkg: Enable MM communication driver.
> >
> >  .../ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc|  11 ++
> >  .../ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf|   4 +
> >  .../ArmVExpress-StandaloneMm-FVP-AArch64.dsc   | 102 
> >  .../ArmVExpress-StandaloneMm-FVP-AArch64.fdf   | 184 
> > +
> >  4 files changed, 301 insertions(+)
> >  create mode 100644 
> > Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.dsc
> >  create mode 100644 
> > Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.fdf
> >
> > --
> > 2.16.2
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2-platforms PATCH v3 2/2] Platform/VExpressPkg: Enable MM communication driver.

[Achin Gupta]

From: Supreeth Venkatesh 

This patch enables MmCommunicationDxe on AArch64 Fixed Virtual
Platform (FVP) by defining required PCDs and driver inf file.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 11 +++
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf |  4 
 2 files changed, 15 insertions(+)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
index 0941ede..c08fb50 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -116,6 +116,11 @@
   ## Trustzone enable (to make the transition from EL3 to NS EL2 in 
ArmPlatformPkg/Sec)
   gArmTokenSpaceGuid.PcdTrustzoneSupport|TRUE
 
+!if $(ARM_STANDALONE_MM_ENABLE) == TRUE
+  gArmTokenSpaceGuid.PcdMmBufferBase|0xFF60
+  gArmTokenSpaceGuid.PcdMmBufferSize|0x1
+!endif
+
   #
   # ARM PrimeCell
   #
@@ -224,6 +229,12 @@
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
 !endif
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
+
+!if $(ARM_STANDALONE_MM_ENABLE) == TRUE
+  # Standalone MM Support
+  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
+!endif
+
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 
   
NULL|EmbeddedPkg/Library/NvVarStoreFormattedLib/NvVarStoreFormattedLib.inf
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
index c3e573e..f592577 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
@@ -86,6 +86,10 @@ FvNameGuid = 87940482-fc81-41c3-87e6-399cf85ac8a0
 !if $(SECURE_BOOT_ENABLE) == TRUE
   INF 
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
 !endif
+!if $(ARM_STANDALONE_MM_ENABLE) == TRUE
+  # Standalone MM Support
+  INF ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
+!endif
   INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
   INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
   INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2-platforms PATCH v3 1/2] VExpressPkg: Add dsc and fdf files for generating Standalone MM Image.

[Achin Gupta]

From: Supreeth Venkatesh 

This patch adds description file and firmware device file to generate
secure world Standalone Management Mode (MM) image on AArch64 FVP. The
secure world Standalone Management Mode (MM) image generated on AArch64
FVP feeds into the fiptool as BL32 image.
These files provide reference for Standalone Management Mode (MM) image
generation on AArch64 FVP.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.dsc | 102 
+++
 Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.fdf | 184 

 2 files changed, 286 insertions(+)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.dsc
new file mode 100644
index 000..56d94d3
--- /dev/null
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.dsc
@@ -0,0 +1,102 @@
+#
+#  Copyright (c) 2011-2018, ARM Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = ArmVExpress-StandaloneMm-FVP-AArch64
+  PLATFORM_GUID  = 49269c13-165c-46f0-85a4-16f290610588
+  PLATFORM_VERSION   = 1.0
+  DSC_SPECIFICATION  = 0x00010011
+!ifdef $(EDK2_OUT_DIR)
+  OUTPUT_DIRECTORY   = $(EDK2_OUT_DIR)
+!else
+  OUTPUT_DIRECTORY   = Build/ArmVExpress-StandaloneMm-FVP-AArch64
+!endif
+  SUPPORTED_ARCHITECTURES= AARCH64
+  BUILD_TARGETS  = DEBUG|RELEASE
+  SKUID_IDENTIFIER   = DEFAULT
+  FLASH_DEFINITION   = 
Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.fdf
+
+[LibraryClasses.common]
+  #
+  # Basic
+  #
+  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+  
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
+  FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf
+  
HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
+  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+  MemLib|StandaloneMmPkg/Library/StandaloneMmMemLib/StandaloneMmMemLib.inf
+  
MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationLib.inf
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
+  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+  
ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
+
+  #
+  # Entry point
+  #
+  
StandaloneMmDriverEntryPoint|StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
+
+[LibraryClasses.AARCH64]
+  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
+  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf
+  ArmSvcLib|ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf
+  
CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
+  
PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
+  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
+  # ARM PL011 UART Driver
+  
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
+
+  
StandaloneMmCoreEntryPoint|StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
+
+[BuildOptions]
+GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 -march=armv8-a+nofp
+
+
+
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+
+[PcdsFeatureFlag]
+  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|TRUE
+
+[PcdsFixedAtBuild]
+  gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80CF
+  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xff
+  gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x0f
+
+  ## PL011 - Serial Terminal
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c0b
+  

[edk2] [edk2-platforms PATCH v3 0/2] *** Enable Standalone Management Mode Core Interface on AARCH64 FVP ***

[Achin Gupta]

***
PI Specification v1.5 "Volume 4: Management Mode Core Interface"
introduces the concept of MM Standalone Mode. This patchset enables
Standalone Management Mode Core Interface on AARCH64 FVP.
***

Supreeth Venkatesh (2):
  VExpressPkg: Add dsc and fdf files for generating Standalone MM Image.
  Platform/VExpressPkg: Enable MM communication driver.

 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc  |  11 ++
 Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.dsc | 102 
+++
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf  |   4 +
 Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.fdf | 184 

 4 files changed, 301 insertions(+)
 create mode 100644 
Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.dsc
 create mode 100644 
Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.fdf

-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-platforms PATCH v2 0/2] *** Enable Standalone Management Mode Core Interface on AARCH64 FVP ***

[Achin Gupta]

Hi Leif,Ard,

These patches are the last bits to complete support for Standalone MM on the
FVP. All other patches have been merged now. Could you please review these?

cheers,
Achin

On Fri, May 04, 2018 at 09:44:34PM +0100, Supreeth Venkatesh wrote:
> ***
> PI Specification v1.5 "Volume 4: Management Mode Core Interface"
> introduces the concept of MM Standalone Mode. This patchset enables
> Standalone Management Mode Core Interface on AARCH64 FVP.
> ***
> 
> Supreeth Venkatesh (2):
>   VExpressPkg: Add dsc and fdf files for generating Standalone MM Image.
>   Platform/VExpressPkg: Enable MM communication driver.
> 
>  .../ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc|  11 ++
>  .../ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf|   4 +
>  .../ArmVExpress-StandaloneMm-FVP-AArch64.dsc   | 102 
>  .../ArmVExpress-StandaloneMm-FVP-AArch64.fdf   | 184 
> +
>  4 files changed, 301 insertions(+)
>  create mode 100644 
> Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.dsc
>  create mode 100644 
> Platform/ARM/VExpressPkg/ArmVExpress-StandaloneMm-FVP-AArch64.fdf
> 
> -- 
> 2.16.2
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/2] StandaloneMM: Update permissions for Standalone MM drivers memory area

[Achin Gupta]

Hi Sughosh,

On Mon, Dec 03, 2018 at 12:49:00PM +0530, Sughosh Ganu wrote:
> Changes since v2:
> Incorporate review comments from Achin to move
> StandaloneMmPeCoffExtraActionLib.c under AArch64 directory.
> 
> Changes since v1:
> A new patch has been added to reflect the library class added for
> changing the MMU attributes in StandaloneMM image, based on review
> comments from Ard Biesheuvel.
> 
> Sughosh Ganu (2):
>   StandaloneMM: Include the newly added library class for MMU functions
>   StandaloneMM: Update permissions for Standalone MM drivers memory area
> 
>  
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
>   
>  |   2 +-
>  ArmPkg/Library/RvdPeCoffExtraActionLib/RvdPeCoffExtraActionLib.inf => 
> StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
>  |  18 +-
>  
> StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/AArch64/StandaloneMmPeCoffExtraActionLib.c
>  | 222 
> 
>  3 files changed, 234 insertions(+), 8 deletions(-)
>  copy ArmPkg/Library/RvdPeCoffExtraActionLib/RvdPeCoffExtraActionLib.inf => 
> StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
>  (72%)
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/AArch64/StandaloneMmPeCoffExtraActionLib.c
> 
> -- 
> 2.7.4
> 
> 

Reviewed-by: Achin Gupta 

Pushed as 34b1d7eafee0..f7f94ffe8828
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/5] StandaloneMmPkg: Miscellaneous fixes

[Achin Gupta]

Hi Sughosh,

On Mon, Dec 03, 2018 at 12:50:51PM +0530, Sughosh Ganu wrote:
> Miscellaneous fixes in StandaloneMmPkg code.
> 
> This patcheset is to be applied on top of the following patchset
> "StandaloneMM: Update permissions for Standalone MM drivers memory area"
> 
> 
> Achin Gupta (5):
>   StandaloneMmPkg: Add missing dependency on PL011UartClockLib
>   StandaloneMmPkg: Enforce alignment check for AArch64
>   StandaloneMmPkg: Zero data structure explicitly
>   StandaloneMmPkg: Replace dependency on ArmMmuLib
>   StandaloneMmPkg: Update dependency on PeCoffExtraActionLib
> 
>  StandaloneMmPkg/StandaloneMmPkg.dsc  
>| 8 +---
>  
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
>  | 3 ++-
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> -- 
> 2.7.4
> 
> 

Reviewed-by: Achin Gupta 

Pushed as 4ceb9c01f9b2..0d1fb6cc8a15
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/2] StandaloneMM: Update permissions for Standalone MM drivers memory area

[Achin Gupta]

Hi Sughosh,

On Sat, Dec 01, 2018 at 09:56:52AM +0530, Sughosh Ganu wrote:
> hi Achin,
> 
> On Sat Dec 01, 2018 at 05:08:50AM +0530, Achin Gupta wrote:
> > Hi Sughosh,
> > 
> > +Jiewen
> > 
> > I took the patches for a spin and it looks like the FVP port is broken. Some
> > reasons are:
> > 
> > 1. The build breaks due to a reference to ArmMmuLib in StandaloneMmPkg.dsc
> > 2. There is a broken dependency on PL011UartClockLib in StandaloneMmPkg.dsc
> > 3. GCC flags to enforce strict alignment and no fp are required in
> >StandaloneMmPkg.dsc to avoid a runtime fault
> > 4. There is a data structre in StandaloneMmCoreEntryPoint.c that needs to be
> >memzeroed due to the alignment checks
> > 
> > Even after these fixes, I am unable to boot the MM SP. The SP boots with the
> > previous revision of your patches and the above fixes. Something has broken
> > between the two. I am suspecting the MMU library for S-EL0.
> 
> I had tested the patches which i had sent out for ArmPkg changes with
> the error handling and error reporting feature on sgi575 before
> posting the patches. In addition to the changes that you mention, i
> was required to make a couple of more changes in the StandadloneMm
> description file.
> 
> 1) 
> StandaloneMmMmuLib|ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> 
> This was changed from ArmMmuLib which was used earlier.

yes! this was the change i was referring to in 1.

> 
> 2) 
> PeCoffExtraActionLib|StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
> 
> I had changed this to reflect the change made in the patch
> StandaloneMM: Update permissions for Standalone MM drivers memory area

Doh! of course it does not work without this change. Thanks! Could you roll it
in your patchstack?

> 
> Can you please confirm that you tested with these two additional
> changes made. Meanwhile, I will incorporate your review comments which
> you make below. Thanks.

I was able to initialise the SP on the FVP and the MM communication driver
initialised correctly. I did not test the MM SP further. I have pushed my
changes on top of your patches here [1]. Could you please check they work for
you as well and include the relevant changes in the next rev of your patchstack?

cheers,
Achin

[1] https://github.com/achingupta/edk2/commits/ag/stmm_perm_v2

> 
> -sughosh
> 
> > 
> > Lets sort this out first. Apart from this, could you move this library into
> > an AArch64 directory as is the case for other Arm specific libraries
> > e.g. StandaloneMmCoreEntryPoint/AArch64
> > 
> > cheers,
> > Achin
> > 
> > On Tue, Nov 27, 2018 at 11:52:53AM +0530, Sughosh Ganu wrote:
> > > Changes since v1:
> > > A new patch has been added to reflect the library class added for
> > > changing the MMU attributes in StandaloneMM image, based on review
> > > comments from Ard Biesheuvel.
> > > 
> > > 
> > > These patches needs to be applied on top of the following patch series
> > >  - "ArmPkg related changes for StandaloneMM package".
> > > 
> > > 
> > > Sughosh Ganu (2):
> > >   StandaloneMM: Include the newly added library class for MMU functions
> > >   StandaloneMM: Update permissions for Standalone MM drivers memory area
> > > 
> > >  .../StandaloneMmCoreEntryPoint.inf |   2 +-
> > >  .../StandaloneMmPeCoffExtraActionLib.inf   |  18 +-
> > >  .../StandaloneMmPeCoffExtraActionLib.c | 222 
> > > +
> > >  3 files changed, 234 insertions(+), 8 deletions(-)
> > >  copy ArmPkg/Library/RvdPeCoffExtraActionLib/RvdPeCoffExtraActionLib.inf 
> > > => 
> > > StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
> > >  (72%)
> > >  create mode 100644 
> > > StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.c
> > > 
> > > -- 
> > > 2.7.4
> > > 
> 
> -- 
> -sughosh
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/2] StandaloneMM: Update permissions for Standalone MM drivers memory area

[Achin Gupta]

Hi Sughosh,

+Jiewen

I took the patches for a spin and it looks like the FVP port is broken. Some
reasons are:

1. The build breaks due to a reference to ArmMmuLib in StandaloneMmPkg.dsc
2. There is a broken dependency on PL011UartClockLib in StandaloneMmPkg.dsc
3. GCC flags to enforce strict alignment and no fp are required in
   StandaloneMmPkg.dsc to avoid a runtime fault
4. There is a data structre in StandaloneMmCoreEntryPoint.c that needs to be
   memzeroed due to the alignment checks

Even after these fixes, I am unable to boot the MM SP. The SP boots with the
previous revision of your patches and the above fixes. Something has broken
between the two. I am suspecting the MMU library for S-EL0.

Lets sort this out first. Apart from this, could you move this library into
an AArch64 directory as is the case for other Arm specific libraries
e.g. StandaloneMmCoreEntryPoint/AArch64

cheers,
Achin

On Tue, Nov 27, 2018 at 11:52:53AM +0530, Sughosh Ganu wrote:
> Changes since v1:
> A new patch has been added to reflect the library class added for
> changing the MMU attributes in StandaloneMM image, based on review
> comments from Ard Biesheuvel.
> 
> 
> These patches needs to be applied on top of the following patch series
>  - "ArmPkg related changes for StandaloneMM package".
> 
> 
> Sughosh Ganu (2):
>   StandaloneMM: Include the newly added library class for MMU functions
>   StandaloneMM: Update permissions for Standalone MM drivers memory area
> 
>  .../StandaloneMmCoreEntryPoint.inf |   2 +-
>  .../StandaloneMmPeCoffExtraActionLib.inf   |  18 +-
>  .../StandaloneMmPeCoffExtraActionLib.c | 222 
> +
>  3 files changed, 234 insertions(+), 8 deletions(-)
>  copy ArmPkg/Library/RvdPeCoffExtraActionLib/RvdPeCoffExtraActionLib.inf => 
> StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
>  (72%)
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.c
> 
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 7/7] ArmPkg: Extra action to update permissions for S-ELO MM Image

[Achin Gupta]

Hi Ard,

Just a polite poke that Sughosh had posted the patches as I had described below
here [1] & here [2]. Please let us know what you think.

cheers,
Achin

[1] https://lists.01.org/pipermail/edk2-devel/2018-October/031377.html
[2] https://lists.01.org/pipermail/edk2-devel/2018-October/031384.html

On Wed, Oct 24, 2018 at 08:05:22AM -0300, Ard Biesheuvel wrote:
> On 24 October 2018 at 05:22, Achin Gupta  wrote:
> > Hi Ard,
> >
> > Please see CIL..
> >
> 
> FYI I will be on leave until 5th of November, so I will get to this
> once I get back.
> 
> -- 
> Ard.
> 
> > On Fri, Aug 24, 2018 at 03:55:29PM +0100, Ard Biesheuvel wrote:
> >> On 21 August 2018 at 07:50, Sughosh Ganu  wrote:
> >> > hi Ard,
> >> >
> >> > On Tue July 23, 2018 at 11:03PM +0530, Supreeth Venkatesh wrote:
> >> >>
> >> >> On Sat, 2018-07-21 at 20:06 +0900, Ard Biesheuvel wrote:
> >> >> > On 20 July 2018 at 21:38, Sughosh Ganu  wrote:
> >> >> > >
> >> >> > > From: Achin Gupta 
> >> >> > >
> >> >> > > The Standalone MM drivers runs in S-EL0 in AArch64 on ARM Standard
> >> >> > > Platforms and is deployed during SEC phase. The memory allocated to
> >> >> > > the Standalone MM drivers should be marked as RO+X.
> >> >> > >
> >> >> > > During PE/COFF Image section parsing, this patch implements extra
> >> >> > > action "UpdatePeCoffPermissions" to request the privileged firmware
> >> >> > > in
> >> >> > > EL3 to update the permissions.
> >> >> > >
> >> >> > > Contributed-under: TianoCore Contribution Agreement 1.1
> >> >> > > Signed-off-by: Sughosh Ganu 
> >> >> > Apologies for bringing this up only now, but I don't think I was ever
> >> >> > cc'ed on these patches.
> >> >> >
> >> >> Apologies if you have missed it. But I am pretty sure it was part of
> >> >> earlier large patch-set on which you and leif were copied, as it was
> >> >> part of ArmPkg.
> >> >> >
> >> >> > We are relying on a debug hook in the PE/COFF loader to ensure that
> >> >> > we
> >> >> > don't end up with memory that is both writable and executable in the
> >> >> > secure world. Do we really think that is a good idea?
> >> >> >
> >> >> > (I know this code was derived from a proof of concept that I did
> >> >> > years
> >> >> > ago, but that was just a PoC)
> >> >> I think we need a little bit more details on what is your suggestion?
> >> >>
> >> >> A little bit background here: This code runs in S-EL0 and Request gets
> >> >> sent to secure world SPM to ensure that the region permissions are
> >> >> updated correctly via the "ArmMmuStandaloneMmCoreLib" SVC -
> >> >> ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64.
> >> >>
> >> >> DebugPeCoffExtraActionLib is just used to extract image region
> >> >> information, but the region permission
> >> >> update request is sent to secure world for validation.
> >> >>
> >> >> With the above explanation, can you provide an insight into what was
> >> >> your thinking?
> >> >> Do you want us to create a separate library and call it
> >> >> as PeCoffExtraActionLib to avoid the "Debug" word though it is a hook
> >> >> to PeCoffExtraActionLib in MdePkg or do we want to create this library
> >> >> in a separate package (may be in MdePkg?) or something totally
> >> >> different.
> >> >
> >> > Supreeth had replied to your comments on the patch. Can you please
> >> > check this. If you feel that this needs to be implemented differently,
> >> > can you please suggest it to us. Thanks.
> >> >
> >>
> >> My point is that such a fundamental action that needs to occur while
> >> loading the PE/COFF image should not be hooked into the loader this
> >> way.
> >
> > Based upon our discussion at the Linaro Connect, we investigated leveraging 
> > the
> > DXE Image Protection support [1] in Standalone MM (StMM). Amongst other
> > challenges, there is a chicken and egg problem. I will try and explain.
> >
> > DX

Re: [edk2] [PATCH v2 7/7] ArmPkg: Extra action to update permissions for S-ELO MM Image

[Achin Gupta]

Hi Ard,

Please see CIL..

On Fri, Aug 24, 2018 at 03:55:29PM +0100, Ard Biesheuvel wrote:
> On 21 August 2018 at 07:50, Sughosh Ganu  wrote:
> > hi Ard,
> >
> > On Tue July 23, 2018 at 11:03PM +0530, Supreeth Venkatesh wrote:
> >>
> >> On Sat, 2018-07-21 at 20:06 +0900, Ard Biesheuvel wrote:
> >> > On 20 July 2018 at 21:38, Sughosh Ganu  wrote:
> >> > >
> >> > > From: Achin Gupta 
> >> > >
> >> > > The Standalone MM drivers runs in S-EL0 in AArch64 on ARM Standard
> >> > > Platforms and is deployed during SEC phase. The memory allocated to
> >> > > the Standalone MM drivers should be marked as RO+X.
> >> > >
> >> > > During PE/COFF Image section parsing, this patch implements extra
> >> > > action "UpdatePeCoffPermissions" to request the privileged firmware
> >> > > in
> >> > > EL3 to update the permissions.
> >> > >
> >> > > Contributed-under: TianoCore Contribution Agreement 1.1
> >> > > Signed-off-by: Sughosh Ganu 
> >> > Apologies for bringing this up only now, but I don't think I was ever
> >> > cc'ed on these patches.
> >> >
> >> Apologies if you have missed it. But I am pretty sure it was part of
> >> earlier large patch-set on which you and leif were copied, as it was
> >> part of ArmPkg.
> >> >
> >> > We are relying on a debug hook in the PE/COFF loader to ensure that
> >> > we
> >> > don't end up with memory that is both writable and executable in the
> >> > secure world. Do we really think that is a good idea?
> >> >
> >> > (I know this code was derived from a proof of concept that I did
> >> > years
> >> > ago, but that was just a PoC)
> >> I think we need a little bit more details on what is your suggestion?
> >>
> >> A little bit background here: This code runs in S-EL0 and Request gets
> >> sent to secure world SPM to ensure that the region permissions are
> >> updated correctly via the "ArmMmuStandaloneMmCoreLib" SVC -
> >> ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64.
> >>
> >> DebugPeCoffExtraActionLib is just used to extract image region
> >> information, but the region permission
> >> update request is sent to secure world for validation.
> >>
> >> With the above explanation, can you provide an insight into what was
> >> your thinking?
> >> Do you want us to create a separate library and call it
> >> as PeCoffExtraActionLib to avoid the "Debug" word though it is a hook
> >> to PeCoffExtraActionLib in MdePkg or do we want to create this library
> >> in a separate package (may be in MdePkg?) or something totally
> >> different.
> >
> > Supreeth had replied to your comments on the patch. Can you please
> > check this. If you feel that this needs to be implemented differently,
> > can you please suggest it to us. Thanks.
> >
> 
> My point is that such a fundamental action that needs to occur while
> loading the PE/COFF image should not be hooked into the loader this
> way.

Based upon our discussion at the Linaro Connect, we investigated leveraging the
DXE Image Protection support [1] in Standalone MM (StMM). Amongst other
challenges, there is a chicken and egg problem. I will try and explain.

DXE Memory protection has dependencies that cannot be fulfilled in StMM. A
non-exhaustive list is:

1. Dependency on CPU_ARCH protocol
2. Dependency on Loaded Image patch protocol
3. Dependency on Boot services 

There is an inherent assumption that this support will never be used in
SMM. Furthermore, in StMM, permissions are changed when the StMM drivers are
first dispatched. A dependency on a driver to change the permissions is the
chicken and egg. So we need a library.

One option is to introduce a memory protection library in StMM i.e. a library
interface like StandaloneMmImageProtect(). This function will be called from
generic code after the PE-COFF loader has loaded and relocated the StMM driver
image. However, this support is not required on x86. They will have to include a
NULL library implementation. This would be in addition to the NULL
PeCoffExtraActionLib they already include through MdePkg.dsc.

I am hesitant to take this approach in the absence of a requirement on x86. At
the same time, the current approach of leveraging the DebugPeCoffExtraActionLib
in ArmPkg does not make sense either.

IMO, the better approach would be to add a AArch64 specific
StandaloneMmPeCoffExtraActionLib in the StandaloneMmPkg. Memory protection will
be 

Re: [edk2] Missing Library in StandaloneMmPkg

[Achin Gupta]

Hi Eugene,

Apologies for the confusion and inconvenience! I will try and explain.

The original patchset for MM Standalone support on x86 and AArch64 had around 16
patches. These included changes to the StandaloneMmPkg, ArmPkg, BaseTools & the
Arm VExpressPkg mainly. This patchset was split into three main categories (The
BaseTools changes were upstreamed separately)

1. StandaloneMmPkg changes. These were merged into master as described here
   [1]. These include all the generic code, Secure world code on AArch64 and x86
   support.

2. edk2-platform changes. These are still under review here [2]. These include
   the ARM AEM FVP changes to support Standalone MM.

3. ArmPkg changes. These are under review here [3]. These include all the Normal
   world code to support Standalone MM e.g. the communication driver. They also
   include the ArmMmuStandaloneMmCoreLib implementation.

Late in the review cycle, Ard raised some valid concerns about how the
PeCoffExtraActionLib has been used by patchset [3]. You can see this thread here
[4]. He has also suggested an alternative approach to solve the impasse. We are
investigating this within Arm at the moment.

The plan is to get [2] & [3] merged and this would complete upstream support for
Standalone MM on AArch64 AEM FVP. In the meantime, these patches should work in
any case. Please let me or Sughosh know if you run into any issues. We can
provide instructions if that helps. Please let us know.

Once we are past this hurdle, there is a plan to add support for Standalone MM
for AArch64 on QEMU.

One the maintenance front, me and Yao Jiewen are the maintainers. 

Feature wise, on the Arm front, the next major step is to add support for
multiple S-EL0 Standalone MM partitions. This will take 6-9 months at least to
be available upstream as we are still writing the Arm specifications to support
this.

I hope this makes things clearer. Please let me know.

cheers,
Achin
 
[1] https://lists.01.org/pipermail/edk2-devel/2018-July/027322.html
[2] https://lists.01.org/pipermail/edk2-devel/2018-May/024489.html
[3] https://lists.01.org/pipermail/edk2-devel/2018-July/027383.html
[4] https://lists.01.org/pipermail/edk2-devel/2018-August/029003.html

On Mon, Oct 15, 2018 at 08:00:41PM +, Cohen, Eugene wrote:
>Supreeth, thanks for the fast response.
> 
> 
>I'm struggling with what to do next - it sounds like we have a partial
>StandaloneMmPkg implementation on master.  I'm willing to complete the
>implementation for our needs but would first like to understand what
>the plan is for completing and maintaining the package (and not just on
>the ARM side).
> 
> 
>Thanks,
> 
> 
>Eugene
> 
> 
>From: Supreeth Venkatesh 
>Sent: Monday, October 15, 2018 1:49 PM
>To: Cohen, Eugene ; edk2-devel@lists.01.org; Achin Gupta
>; Jiewen Yao ; Sughosh Ganu
>
>Cc: Dong Wei 
>Subject: RE: Missing Library in StandaloneMmPkg
> 
> 
>Eugene,
>The working StandaloneMm available here:
>[1]https://github.com/supven01/edk2
>[2]https://github.com/supven01/edk2-platforms
>(Caveat: Working Version as of July 2018, May not be latest)
>As you mentioned, the patches were sent in June/July for Review.
>I have not received any comments/feedback on those.
>As you say, it has either not been reviewed by the maintainers or
>merged yet.
>I am no longer working on StandaloneMm at this point.
>However, Achin or Sughosh will be able to point you to the latest code
>base.
>Thanks,
>Supreeth
>-Original Message-----
>From: Cohen, Eugene <[3]eug...@hp.com>
>Sent: Monday, October 15, 2018 2:29 PM
>To: [4]edk2-devel@lists.01.org; Achin Gupta <[5]achin.gu...@arm.com>;
>Jiewen Yao <[6]jiewen@intel.com>; Supreeth Venkatesh
><[7]supreeth.venkat...@arm.com>; Sughosh Ganu <[8]sughosh.g...@arm.com>
>Subject: Missing Library in StandaloneMmPkg
>Greetings,
>It appears that StandaloneMmPkg/StandaloneMmPkg.dsc contains a
>reference to this library:
>ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf
>but it does not actually appear in the tree.
>The AArch64StandaloneMm branch on edk2-staging is "stale" (not my words
>but what GitHub calls it) and it does not contain this library so I'm
>led to believe that there is some other branch where this is being
>developed. I also see patch submissions from July that are not yet
>integrated (StandaloneMmServicesTableLib in particular).
>Can I get a summary of the state of the project, in general and on ARM
>platforms? Is there a repo or branch we should be going to where we can
>see a usable system?
>Thanks,
>Eugene
>IMPORTANT NOTICE: T

Re: [edk2] [PATCH v2 7/7] ArmPkg: Extra action to update permissions for S-ELO MM Image

[Achin Gupta]

Hi Ard,

Apologies for the delay! CIL.

On Fri, Aug 24, 2018 at 03:55:29PM +0100, Ard Biesheuvel wrote:
> On 21 August 2018 at 07:50, Sughosh Ganu  wrote:
> > hi Ard,
> >
> > On Tue July 23, 2018 at 11:03PM +0530, Supreeth Venkatesh wrote:
> >>
> >> On Sat, 2018-07-21 at 20:06 +0900, Ard Biesheuvel wrote:
> >> > On 20 July 2018 at 21:38, Sughosh Ganu  wrote:
> >> > >
> >> > > From: Achin Gupta 
> >> > >
> >> > > The Standalone MM drivers runs in S-EL0 in AArch64 on ARM Standard
> >> > > Platforms and is deployed during SEC phase. The memory allocated to
> >> > > the Standalone MM drivers should be marked as RO+X.

This is a bit misleading. For Standalone MM drivers, memory is allocated from
the heap which is marked as RW+XN by the SPM in the S-EL1 page tables. This
allows PeCoffLoaderLoadImage() to load the image from the FV into its newly
allocated buffer. Before the driver can be executed, its rodata and code
sections need a permission update from RW+XN to RO+XN and RO+X respectively. 

This patch does these permission changes after the relocation fixups have been
done in PeCoffLoaderRelocateImageExtraAction().

> >> > >
> >> > > During PE/COFF Image section parsing, this patch implements extra
> >> > > action "UpdatePeCoffPermissions" to request the privileged firmware
> >> > > in
> >> > > EL3 to update the permissions.
> >> > >
> >> > > Contributed-under: TianoCore Contribution Agreement 1.1
> >> > > Signed-off-by: Sughosh Ganu 
> >> > Apologies for bringing this up only now, but I don't think I was ever
> >> > cc'ed on these patches.
> >> >
> >> Apologies if you have missed it. But I am pretty sure it was part of
> >> earlier large patch-set on which you and leif were copied, as it was
> >> part of ArmPkg.
> >> >
> >> > We are relying on a debug hook in the PE/COFF loader to ensure that
> >> > we
> >> > don't end up with memory that is both writable and executable in the
> >> > secure world. Do we really think that is a good idea?
> >> >
> >> > (I know this code was derived from a proof of concept that I did
> >> > years
> >> > ago, but that was just a PoC)
> >> I think we need a little bit more details on what is your suggestion?
> >>
> >> A little bit background here: This code runs in S-EL0 and Request gets
> >> sent to secure world SPM to ensure that the region permissions are
> >> updated correctly via the "ArmMmuStandaloneMmCoreLib" SVC -
> >> ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64.
> >>
> >> DebugPeCoffExtraActionLib is just used to extract image region
> >> information, but the region permission
> >> update request is sent to secure world for validation.
> >>
> >> With the above explanation, can you provide an insight into what was
> >> your thinking?
> >> Do you want us to create a separate library and call it
> >> as PeCoffExtraActionLib to avoid the "Debug" word though it is a hook
> >> to PeCoffExtraActionLib in MdePkg or do we want to create this library
> >> in a separate package (may be in MdePkg?) or something totally
> >> different.
> >
> > Supreeth had replied to your comments on the patch. Can you please
> > check this. If you feel that this needs to be implemented differently,
> > can you please suggest it to us. Thanks.
> >
> 
> My point is that such a fundamental action that needs to occur while
> loading the PE/COFF image should not be hooked into the loader this
> way.

IIUC, your concern is about the way the PeCoffLoaderRelocateImageExtraAction()
has been used? Is it meant to fulfil a different purpose? PE-COFF image loading
and relocation is done by generic code and this seemed like the best mechanism
to introduce an arch. specific hook.

I agree that implementing the hooks in a DebugPeCoffExtraActionLib is not
suitable for upstreaming. We could implement this within the StandaloneMmPkg as
an Aarch64 library since it is unlikely it will ever be used in the ArmPkg
itself.

Please let us know what you think.

cheers,
Achin
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/1] ArmPkg/OpteeLib: Add APIs to communicate with OP-TEE

[Achin Gupta]

Hi Sumit,

Apologies for not replying sooner. Some questions and thoughts inline.

On Mon, Aug 27, 2018 at 03:28:52PM +0530, Sumit Garg wrote:
> On Fri, 24 Aug 2018 at 23:33, Matteo Carlini  wrote:
> >
> > +Achin
> >
> > SPD (for OP-TEE and other Trusted-OSes payloads running at S-EL1) and SPM 
> > (for Secure Partitions at S-EL0) are currently mutually exclusive into 
> > Trusted Firmware-A codebase.
> >
> > In other words, you cannot turn them on in parallel and execute both a 
> > S-EL1 Trusted OS AND (one or many) S-EL0 Secure Partitions in the Secure 
> > World with the current Software Architecture.
> >
> 
> IIUC, currently BL32 image is common in Trusted Firmware-A code-base.
> If we turn on SPD then BL32= else if we turn on SPM
> then BL32=, correct?

Yes! BL32 is a TOS image if SPD is enabled. It is a S-EL0 Standalone MM Secure
partition image if SPM is enabled.

> 
> But I think SMC calling conventions (SMC Calling Convention [1] and
> Management Mode Interface Specification [2]) doesn't put any such
> restrictions as SMC function IDs are totally separate.

Yes, this was an implementation choice to ensure that either a S-EL1 payload
(Trusted OS) or a S-EL0 payload (MM SP) could be included in an Arm TF build but
not both.

> 
> > Achin and other Arm architects are trying to figure out a way for solving 
> > this problem without the need for a v8.4 Secure-EL2 Hypervisor, obviously 
> > without leveraging the isolation benefits of it (see also [1]).
> >
> 
> Agree we won't be having isolation benefits which provides added level
> of Security.
> 
> > But Ard is right: there could be use-cases to ship UEFI systems with OP-TEE 
> > and TAs on top...and this should still be currently possible using the SPD 
> > dispatcher into TF-A. I've not looked deeply into this patch, but it 
> > doesn’t seem to contradict the above Sw architecture.
> >
> > The question would be: would you foresee the need for running one (or many) 
> > other (UEFI/EDK2-based) Secure Services in the Secure World into a Secure 
> > Partition (using the StandaloneMmPkg) *together* with OP-TEE?
> >
> 
> As per following quote from Management Mode Interface Specification [2]:
> 
> "Management Mode (MM) provides an environment for implementing OS
> agnostic services (MM services) like RAS error handling, secure
> variable storage, and firmware updates in system firmware. The
> services can be invoked synchronously and asynchronously."
> 
> It seems that MM mode is designed for more robust and platform
> specific services whereas OP-TEE (or any trusted OS) use-cases seem to
> be more complex like Entropy pool (RNG as in our case), DRM (could be
> valid use-case for Android TV or Chromebook), keymaster or keystore
> (for Edge devices) etc.

It really depends upon the secure sw stack, use case and the requirements. MM
interface specification specifies a blocking SMC (MM_COMMUNICATE) to access a
secure service implemented in S-EL0.  

In the UEFI/PI/EDK2 context, MM drivers are used to satisfy a variety of use
cases during boot through the EFI_MM_COMMUNICATION_PROTOCOL (the bad press of
SMM aside!). MM_COMMUNICATE SMC provides a channel into the secure world to the
backend of this protocol on Arm systems. So any service accessible through this
protocol could be implemented on Arm systems in a MM SP.

IIUC, in your case there is OP-TEE and firmware in the secure world. OP-TEE has
a static TA that provides the random data service and you want to leverage it at
boot time? Ditto for other services? So you do not really need an MM partition
running alongside OP-TEE?

In any case, what we are working on is to define a set of standard SMC
interfaces that can be used to talk to a secure service in a payload in S-EL1 or
S-EL0. This standard ABI will avoid the need to use payload specific SMCs in the
normal world e.g. OP-TEE specific SMCs.

Side topic! Do you foresee a usecase for DRM through UEFI during boot? Would it
work in the absence of RPC support in the Optee Library? IIUC, at runtime, DRM
traffic will be routed through the OP-TEE driver in the OS instead of UEFI since
there is no UEFI runtime service interface to do DRM?

> 
> So it looks like they complement each other and we will have more
> robustness once we migrate to v8.4 Secure-EL2 Hypervisor for isolation
> support.

In a way yes! The robustness bit is not really related to the interface used to
access as service.

> 
> Please feel free to correct me if I missed something.

Hope this makes sense.

cheers,
Achin

> 
> Regards,
> Sumit
> 
> [1] 
> http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
> [2] 
> http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf
> 
> > Thanks
> > Matteo
> >
> > [1]: 
> > https://community.arm.com/processors/b/blog/posts/architecting-more-secure-world-with-isolation-and-virtualization
> >
> > > -Original Message-
> > > From: Udit Kumar 
> > > Sent: 24 

Re: [edk2] [PATCH v2 09/10] StandaloneMmPkg: Add CPU driver suitable for ARM Platforms.

[Achin Gupta]

Thanks Sughosh.

Reviewed-by: Achin Gupta 


On Fri, Jul 13, 2018 at 08:35:29PM +0530, Sughosh Ganu wrote:
> From: Supreeth Venkatesh 
> 
> This patch adds a simple CPU driver that exports the
> EFI_MM_CONFIGURATION_PROTOCOL to allow registration of the Standalone
> MM Foundation entry point. It preserves the existing notification
> mechanism for the configuration protocol.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sughosh Ganu 
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> ---
>  .../Drivers/StandaloneMmCpu/AArch64/EventHandle.c  | 220 +++
>  .../StandaloneMmCpu/AArch64/StandaloneMmCpu.c  | 232 
> +
>  .../StandaloneMmCpu/AArch64/StandaloneMmCpu.h  |  64 ++
>  .../StandaloneMmCpu/AArch64/StandaloneMmCpu.inf|  59 ++
>  StandaloneMmPkg/Include/Guid/MpInformation.h   |  41 
>  5 files changed, 616 insertions(+)
>  create mode 100644 
> StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c
>  create mode 100644 
> StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.c
>  create mode 100644 
> StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.h
>  create mode 100644 
> StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
>  create mode 100644 StandaloneMmPkg/Include/Guid/MpInformation.h
> 
> diff --git a/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c 
> b/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c
> new file mode 100644
> index ..2814577b3fcc
> --- /dev/null
> +++ b/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c
> @@ -0,0 +1,220 @@
> +/** @file
> +
> +  Copyright (c) 2016 HP Development Company, L.P.
> +  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include  // for EFI_SYSTEM_CONTEXT
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "StandaloneMmCpu.h"
> +
> +EFI_STATUS
> +EFIAPI
> +MmFoundationEntryRegister (
> +  IN CONST EFI_MM_CONFIGURATION_PROTOCOL  *This,
> +  IN EFI_MM_ENTRY_POINTMmEntryPoint
> +  );
> +
> +//
> +// On ARM platforms every event is expected to have a GUID associated with
> +// it. It will be used by the MM Entry point to find the handler for the
> +// event. It will either be populated in a EFI_MM_COMMUNICATE_HEADER by the
> +// caller of the event (e.g. MM_COMMUNICATE SMC) or by the CPU driver
> +// (e.g. during an asynchronous event). In either case, this context is
> +// maintained in an array which has an entry for each CPU. The pointer to 
> this
> +// array is held in PerCpuGuidedEventContext. Memory is allocated once the
> +// number of CPUs in the system are made known through the
> +// MP_INFORMATION_HOB_DATA.
> +//
> +EFI_MM_COMMUNICATE_HEADER **PerCpuGuidedEventContext = NULL;
> +
> +// Descriptor with whereabouts of memory used for communication with the 
> normal world
> +EFI_MMRAM_DESCRIPTOR  mNsCommBuffer;
> +
> +MP_INFORMATION_HOB_DATA *mMpInformationHobData;
> +
> +EFI_MM_CONFIGURATION_PROTOCOL mMmConfig = {
> +  0,
> +  MmFoundationEntryRegister
> +};
> +
> +STATIC EFI_MM_ENTRY_POINT mMmEntryPoint = NULL;
> +
> +EFI_STATUS
> +PiMmStandloneArmTfCpuDriverEntry (
> +  IN UINTN EventId,
> +  IN UINTN CpuNumber,
> +  IN UINTN NsCommBufferAddr
> +  )
> +{
> +  EFI_MM_COMMUNICATE_HEADER *GuidedEventContext = NULL;
> +  EFI_MM_ENTRY_CONTEXTMmEntryPointContext = {0};
> +  EFI_STATUS  Status;
> +  UINTN   NsCommBufferSize;
> +
> +  DEBUG ((DEBUG_INFO, "Received event - 0x%x on cpu %d\n", EventId, 
> CpuNumber));
> +
> +  Status = EFI_SUCCESS;
> +  //
> +  // ARM TF passes SMC FID of the MM_COMMUNICATE interface as the Event ID 
> upon
> +  // receipt of a synchronous MM request. Use the Event ID to distinguish
> +  // between synchronous and asynchronous events.
> +  //
> +  if (ARM_SMC_ID_MM_COMMUNICATE_AARCH64 != EventId) {
> +DEBUG ((DEBUG_INFO, "UnReco

Re: [edk2] [PATCH v2 08/10] StandaloneMmPkg: Add an AArch64 specific entry point library.

[Achin Gupta]

Thanks Sughosh.

Reviewed-by: Achin Gupta 

On Fri, Jul 13, 2018 at 08:35:28PM +0530, Sughosh Ganu wrote:
> From: Supreeth Venkatesh 
> 
> The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
> Platforms and is initialised during the SEC phase. ARM Trusted firmware
> in EL3 is responsible for initialising the architectural context for
> S-EL0 and loading the Standalone MM image. The memory allocated to this
> image is marked as RO+X. Heap memory is marked as RW+XN.
> 
> Certain actions have to be completed prior to executing the generic code
> in the Standalone MM Core module. These are:
> 
> 1. Memory permission attributes for each section of the Standalone MM
>Core module need to be changed prior to accessing any RW data.
> 
> 2. A Hob list has to be created with information that allows the MM
>environment to initialise and dispatch drivers.
> 
> Furthermore, this module is responsible for handing over runtime MM
> events to the Standalone MM CPU driver and returning control to ARM
> Trusted Firmware upon event completion. Hence it needs to know the CPU
> driver entry point.
> 
> This patch implements an entry point module that ARM Trusted Firmware
> jumps to in S-EL0. It then performs the above actions before calling the
> Standalone MM Foundation entry point and handling subsequent MM events.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sughosh Ganu 
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> ---
>  .../Library/AArch64/StandaloneMmCoreEntryPoint.h   | 215 +++
>  .../AArch64/CreateHobList.c| 209 ++
>  .../AArch64/SetPermissions.c   | 289 +++
>  .../AArch64/StandaloneMmCoreEntryPoint.c   | 306 
> +
>  .../StandaloneMmCoreEntryPoint.inf |  55 
>  5 files changed, 1074 insertions(+)
>  create mode 100644 
> StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/CreateHobList.c
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
> 
> diff --git 
> a/StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h 
> b/StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h
> new file mode 100644
> index ..e4e5875b5d22
> --- /dev/null
> +++ b/StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h
> @@ -0,0 +1,215 @@
> +/** @file
> +  Entry point to the Standalone MM Foundation when initialized during the SEC
> +  phase on ARM platforms
> +
> +Copyright (c) 2017 - 2018, ARM Ltd. All rights reserved.
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD 
> License
> +which accompanies this distribution.  The full text of the license may be 
> found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __STANDALONEMMCORE_ENTRY_POINT_H__
> +#define __STANDALONEMMCORE_ENTRY_POINT_H__
> +
> +#include 
> +#include 
> +
> +#define CPU_INFO_FLAG_PRIMARY_CPU  0x0001
> +
> +typedef struct {
> +  UINT8  Type;   /* type of the structure */
> +  UINT8  Version;/* version of this structure */
> +  UINT16 Size;  /* size of this structure in bytes */
> +  UINT32 Attr;  /* attributes: unused bits SBZ */
> +} EFI_PARAM_HEADER;
> +
> +typedef struct {
> +  UINT64 Mpidr;
> +  UINT32 LinearId;
> +  UINT32 Flags;
> +} EFI_SECURE_PARTITION_CPU_INFO;
> +
> +typedef struct {
> +  EFI_PARAM_HEADER  Header;
> +  UINT64SpMemBase;
> +  UINT64SpMemLimit;
> +  UINT64SpImageBase;
> +  UINT64SpStackBase;
> +  UINT64SpHeapBase;
> +  UINT64SpNsCommBufBase;
> +  UINT64SpSharedBufBase;
> +  UINT64SpImageSize;
> +  UINT64SpPcpuStackSize;
> +  UINT64SpHeapSize;
> +  UINT64SpNsCommBufSize;
> +  UINT64SpPcpuSharedBufSize;
> +  UINT32

Re: [edk2] [PATCH 09/10] StandaloneMmPkg: Add CPU driver suitable for ARM Platforms.

[Achin Gupta]

Hi Sughosh,

CIL.

On Tue, Jul 03, 2018 at 03:12:52PM +0530, Supreeth Venkatesh wrote:
> This patch adds a simple CPU driver that exports the
> EFI_MM_CONFIGURATION_PROTOCOL to allow registration of the Standalone
> MM Foundation entry point. It preserves the existing notification
> mechanism for the configuration protocol.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> Cc: Jiewen Yao 
> Cc: Achin Gupta 
> ---
>  .../Drivers/StandaloneMmCpu/AArch64/EventHandle.c  | 208 +++
>  .../StandaloneMmCpu/AArch64/StandaloneMmCpu.c  | 219 
> +
>  .../StandaloneMmCpu/AArch64/StandaloneMmCpu.h  |  64 ++
>  .../StandaloneMmCpu/AArch64/StandaloneMmCpu.inf|  59 ++
>  StandaloneMmPkg/Include/Guid/MpInformation.h   |  41 
>  5 files changed, 591 insertions(+)
>  create mode 100644 
> StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c
>  create mode 100644 
> StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.c
>  create mode 100644 
> StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.h
>  create mode 100644 
> StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
>  create mode 100644 StandaloneMmPkg/Include/Guid/MpInformation.h
> 
> diff --git a/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c 
> b/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c
> new file mode 100644
> index 000..5f39216
> --- /dev/null
> +++ b/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c
> @@ -0,0 +1,208 @@
> +/** @file
> +
> +  Copyright (c) 2016 HP Development Company, L.P.
> +  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include  // for EFI_SYSTEM_CONTEXT
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "StandaloneMmCpu.h"
> +
> +EFI_STATUS
> +EFIAPI
> +MmFoundationEntryRegister(
> +  IN CONST EFI_MM_CONFIGURATION_PROTOCOL  *This,
> +  IN EFI_MM_ENTRY_POINTMmEntryPoint
> +  );
> +
> +//
> +// On ARM platforms every event is expected to have a GUID associated with
> +// it. It will be used by the MM Entry point to find the handler for the
> +// event. It will either be populated in a EFI_MM_COMMUNICATE_HEADER by the
> +// caller of the event (e.g. MM_COMMUNICATE SMC) or by the CPU driver
> +// (e.g. during an asynchronous event). In either case, this context is
> +// maintained in an array which has an entry for each CPU. The pointer to 
> this
> +// array is held in PerCpuGuidedEventContext. Memory is allocated once the
> +// number of CPUs in the system are made known through the
> +// MP_INFORMATION_HOB_DATA.
> +//
> +EFI_MM_COMMUNICATE_HEADER **PerCpuGuidedEventContext = NULL;
> +
> +// Descriptor with whereabouts of memory used for communication with the 
> normal world
> +EFI_MMRAM_DESCRIPTOR  mNsCommBuffer;
> +
> +MP_INFORMATION_HOB_DATA *mMpInformationHobData;
> +
> +EFI_MM_CONFIGURATION_PROTOCOL mMmConfig = {
> +  0,
> +  MmFoundationEntryRegister
> +};
> +
> +static EFI_MM_ENTRY_POINT mMmEntryPoint = NULL;
> +
> +EFI_STATUS
> +PiMmStandloneArmTfCpuDriverEntry (
> +  IN UINTN EventId,
> +  IN UINTN CpuNumber,
> +  IN UINTN NsCommBufferAddr
> +  )
> +{
> +  EFI_MM_COMMUNICATE_HEADER *GuidedEventContext = NULL;
> +  EFI_MM_ENTRY_CONTEXTMmEntryPointContext = {0};
> +  EFI_STATUS  Status;
> +  UINTN   NsCommBufferSize;
> +
> +  DEBUG ((DEBUG_INFO, "Received event - 0x%x on cpu %d\n", EventId, 
> CpuNumber));
> +
> +  Status = EFI_SUCCESS;
> +  //
> +  // ARM TF passes SMC FID of the MM_COMMUNICATE interface as the Event ID 
> upon
> +  // receipt of a synchronous MM request. Use the Event ID to distinguish
> +  // between synchronous and asynchronous events.
> +  //
> +  if (ARM_SMC_ID_MM_COMMUNICATE_AARCH64 != EventId) {
> +DEBUG ((DEBUG_INFO, "UnRecognized Event - 0x%x\n", EventId));
> +return EFI_INVALID_PA

Re: [edk2] [PATCH 08/10] StandaloneMmPkg: Add an AArch64 specific entry point library.

[Achin Gupta]

Hi Sughosh,

Thanks a lot for picking this up. CIL..

On Tue, Jul 03, 2018 at 03:12:39PM +0530, Supreeth Venkatesh wrote:
> The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
> Platforms and is initialised during the SEC phase. ARM Trusted firmware
> in EL3 is responsible for initialising the architectural context for
> S-EL0 and loading the Standalone MM image. The memory allocated to this
> image is marked as RO+X. Heap memory is marked as RW+XN.
> 
> Certain actions have to be completed prior to executing the generic code
> in the Standalone MM Core module. These are:
> 
> 1. Memory permission attributes for each section of the Standalone MM
>Core module need to be changed prior to accessing any RW data.
> 
> 2. A Hob list has to be created with information that allows the MM
>environment to initialise and dispatch drivers.
> 
> Furthermore, this module is responsible for handing over runtime MM
> events to the Standalone MM CPU driver and returning control to ARM
> Trusted Firmware upon event completion. Hence it needs to know the CPU
> driver entry point.
> 
> This patch implements an entry point module that ARM Trusted Firmware
> jumps to in S-EL0. It then performs the above actions before calling the
> Standalone MM Foundation entry point and handling subsequent MM events.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> Cc: Jiewen Yao 
> Cc: Achin Gupta 
> ---
>  .../Library/AArch64/StandaloneMmCoreEntryPoint.h   | 214 +++
>  .../AArch64/CreateHobList.c| 200 ++
>  .../AArch64/SetPermissions.c   | 275 
>  .../AArch64/StandaloneMmCoreEntryPoint.c   | 287 
> +
>  .../StandaloneMmCoreEntryPoint.inf |  55 
>  5 files changed, 1031 insertions(+)
>  create mode 100644 
> StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/CreateHobList.c
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
> 
> diff --git 
> a/StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h 
> b/StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h
> new file mode 100644
> index 000..6eb74af
> --- /dev/null
> +++ b/StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h
> @@ -0,0 +1,214 @@
> +/** @file
> +  Entry point to the Standalone MM Foundation when initialized during the SEC
> +  phase on ARM platforms
> +
> +Copyright (c) 2017 - 2018, ARM Ltd. All rights reserved.
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD 
> License
> +which accompanies this distribution.  The full text of the license may be 
> found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __STANDALONEMMCORE_ENTRY_POINT_H__
> +#define __STANDALONEMMCORE_ENTRY_POINT_H__
> +
> +#include 
> +#include 
> +
> +#define CPU_INFO_FLAG_PRIMARY_CPU  0x0001
> +
> +typedef struct {
> +  UINT8  Type;   /* type of the structure */
> +  UINT8  Version;/* version of this structure */
> +  UINT16 Size;  /* size of this structure in bytes */
> +  UINT32 Attr;  /* attributes: unused bits SBZ */
> +} EFI_PARAM_HEADER;
> +
> +typedef struct {
> +  UINT64 Mpidr;
> +  UINT32 LinearId;
> +  UINT32 Flags;
> +} EFI_SECURE_PARTITION_CPU_INFO;
> +
> +typedef struct {
> +  EFI_PARAM_HEADER  Header;
> +  UINT64SpMemBase;
> +  UINT64SpMemLimit;
> +  UINT64SpImageBase;
> +  UINT64SpStackBase;
> +  UINT64SpHeapBase;
> +  UINT64SpNsCommBufBase;
> +  UINT64SpSharedBufBase;
> +  UINT64SpImageSize;
> +  UINT64SpPcpuStackSize;
> +  UINT64SpHeapSize;
> +  UINT64SpNsCommBufSize;
> +  UINT64SpPcpuSharedBufSize;
> +  UINT32  

Re: [edk2] [PATCH v3 00/17] *** Standalone Management Mode Core Interface for AARCH64 Platforms ***

[Achin Gupta]

Hi Jiewen,

On Mon, Jun 18, 2018 at 03:12:46PM +, Yao, Jiewen wrote:
> Yes. I think so.
>
> However, I found the V3 just contains partial of the patch. It is hard to 
> find some V2 and some V3.
> Also this series includes multiple package. We need different package 
> maintainer to push different patches.
>
> I recommend we do in this way:
> Please split this big one into 3 - BaseTool patch, ArmPkg patch, and 
> StandaloneMmPkg patch.
>
> Then BaseTool maintainer can push BaseTool patch, ArmPkg maintainer can push 
> ArmPkg patch, and I can help push StandaloneMmPkg patch.

Thomas and Sugosh will refactor the patches and repost since Supreeth is on
holiday. I started late but would like to finish reviewing the Arm specific bits
in the StandaloneMmPkg before they are merged. Will not take more than 2
days. Could you please merge after I ack. Hope that is fine?

cheers,
Achin

>
> Thank you
> Yao Jiewen
>
> > -Original Message-
> > From: Thomas Abraham [mailto:thomas.abra...@arm.com]
> > Sent: Monday, June 18, 2018 6:07 AM
> > To: Sughosh Ganu 
> > Cc: Supreeth Venkatesh ;
> > edk2-devel@lists.01.org; Yao, Jiewen ; Gao, Liming
> > 
> > Subject: Re: [edk2] [PATCH v3 00/17] *** Standalone Management Mode Core
> > Interface for AARCH64 Platforms ***
> >
> > On Wed, Jun 6, 2018 at 4:50 PM, Sughosh Ganu  wrote:
> > > On Tue, Jun 5, 2018 at 3:43 AM, Supreeth Venkatesh
> > >  wrote:
> > >> ***
> > >> This patchset v3 contains only the patches that got feedback/comments
> > frome the previous revision v2.
> > >> The patches are
> > >> [PATCH v3 06/17] StandaloneMmPkg: Delete StandaloneMmPkg file.
> > >> [PATCH v3 13/17] StandaloneMmPkg: Add an AArch64 specific entry point
> > library.
> > >> [PATCH v3 17/17] BaseTools/AutoGen: Update header file for MM modules.
> > >>
> > >> Changes Since v2:
> > >> (*) Address feedback provided for the commit "BaseTools/AutoGen: Update
> > header file for MM modules."
> > >> (*) Edit parameters for the StandaloneMmCpu Driver in the commit
> > "StandaloneMmPkg: Add an AArch64 specific entry point library."
> > >>
> > >> Changes Since v1:
> > >> (*) Reorder and Reword commits.
> > >> (*) Reorganize structure of StandaloneMmPkg and rename libraries.
> > >> (*) Address Review Comments from Achin, Jiewen and Daniil.
> > >> ***
> > >> Supreeth Venkatesh (17):
> > >>   ArmPkg: Add PCDs needed for MM communication driver.
> > >>   ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
> > >>   ArmPkg/Include: Add MM interface SVC return codes.
> > >>   ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.
> > >>   ArmPkg/ArmMmuLib: Add MMU library inf file suitable for use in S-EL0.
> > >>   StandaloneMmPkg: Delete StandaloneMmPkg file.
> > >>   StandaloneMmPkg/FvLib: Add a common FV Library for management
> > mode.
> > >>   StandaloneMmPkg/MemLib: Add Standalone MM instance of memory
> > check
> > >> library.
> > >>   StandaloneMmPkg/MemoryAllocationLib: Add MM memory allocation
> > library.
> > >>   StandaloneMmPkg/HobLib: Add HOB Library for management mode.
> > >>   StandaloneMmPkg: MM driver entry point library.
> > >>   StandaloneMmPkg/Core: Implementation of Standalone MM Core
> > Module.
> > >>   StandaloneMmPkg: Add an AArch64 specific entry point library.
> > >>   StandaloneMmPkg: Add CPU driver suitable for ARM Platforms.
> > >>   StandaloneMmPkg: Describe the declaration and definition files.
> > >>   ArmPkg: Extra action to update permissions for S-ELO MM Image.
> > >>   BaseTools/AutoGen: Update header file for MM modules.
> > >
> > > Tested all changes for RAS error injection and error handling on
> > > SGI575 platform.
> > >
> > > Tested-by: Sughosh Ganu 
> > >
> > > -sughosh
> >
> > There have been no further comments on this series. Can this patch
> > series be merged?
> >
> > Thanks,
> > Thomas.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 17/18] StandaloneMmPkg: Add application to test MM communication protocol.

[Achin Gupta]

Hi Supreeth,

I agree with Jiewen that these should not be a part of this series. Can you push
these in a separate series?

cheers,
Achin

On Fri, Apr 06, 2018 at 03:42:22PM +0100, Supreeth Venkatesh wrote:
> This patch adds a simple application that uses the MM
> communication protocol to pass a copy of the UEFI system table to
> the MM environment in the secure world.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  .../Application/MmCommTestApp/MmCommTest.c | 81 
> ++
>  .../Application/MmCommTestApp/MmCommTest.h | 37 ++
>  .../Application/MmCommTestApp/MmCommTest.inf   | 57 +++
>  3 files changed, 175 insertions(+)
>  create mode 100644 StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.c
>  create mode 100644 StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.h
>  create mode 100644 StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.inf
> 
> diff --git a/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.c 
> b/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.c
> new file mode 100644
> index 00..efbafdde62
> --- /dev/null
> +++ b/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.c
> @@ -0,0 +1,81 @@
> +/** @file
> +  This sample application demos how to communicate
> +  with secure partition using MM communication protocol
> +
> +  Copyright (c) 2006 - 2008, Intel Corporation. All rights reserved.
> +  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "MmCommTest.h"
> +
> +#include 
> +
> +#include 
> +
> +EFI_MM_COMMUNICATION_PROTOCOL  *mMmCommunication = NULL;
> +
> +EFI_STATUS
> +MmIplNotifyCommTest (
> +  VOID
> +  )
> +{
> +  EFI_MM_COMMUNICATE_TESTMmCommTest;
> +  UINTN  Size;
> +
> +  DEBUG ((DEBUG_INFO, "MmIplNotifyCommTest\n"));
> +
> +  CopyGuid (, );
> +  CopyMem (, gST, sizeof (EFI_SYSTEM_TABLE));
> +  MmCommTest.MessageLength = sizeof (EFI_MM_COMMUNICATE_TEST_DATA);
> +
> +  //
> +  // Generate the MM_COMMUNICATE SMC and return the result
> +  //
> +  Size = sizeof (MmCommTest);
> +  return mMmCommunication->Communicate (NULL, , );
> +}
> +
> +/**
> +  The user Entry Point for Application. The user code starts with this 
> function
> +  as the real entry point for the application.
> +
> +  @param[in] ImageHandleThe firmware allocated handle for the EFI image.
> +  @param[in] SystemTableA pointer to the EFI System Table.
> +
> +  @retval EFI_SUCCESS   The entry point is executed successfully.
> +  @retval other Some error occurs when executing this entry 
> point.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +MmCommTestEntryPoint (
> +  IN EFI_HANDLEImageHandle,
> +  IN EFI_SYSTEM_TABLE  *SystemTable
> +  )
> +{
> +  EFI_STATUS Status;
> +
> +  Status = gBS->LocateProtocol (, NULL, 
> (VOID **) );
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  return MmIplNotifyCommTest ();
> +}
> diff --git a/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.h 
> b/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.h
> new file mode 100644
> index 00..8e8305a060
> --- /dev/null
> +++ b/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.h
> @@ -0,0 +1,37 @@
> +/** @file
> +  GUIDs for MM Event.
> +
> +Copyright (c) 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +
> +This program and the accompanying materials are licensed and made available 
> under
> +the terms and conditions of the BSD License that accompanies this 
> distribution.
> +The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php.
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
>

Re: [edk2] [PATCH v1 16/18] BaseTools/AutoGen: Update header file for MM modules.

[Achin Gupta]

Hi Supreeth,

CIL.

On Fri, Apr 06, 2018 at 03:42:21PM +0100, Supreeth Venkatesh wrote:
> This patch corrects the Module Type Header file for Management Mode(MM)
> as specified in PI v1.6 Specification. Also, it updates parameter for
> auto generated template functions from EFI_SMM_SYSTEM_TABLE2 to
> EFI_MM_SYSTEM_TABLE.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>

-Achin & +Jiewen if possible!

Acked-by: Achin Gupta <achin.gu...@arm.com>

cheers,
Achin

> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  BaseTools/Source/Python/AutoGen/GenC.py | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
> b/BaseTools/Source/Python/AutoGen/GenC.py
> index 4d9ea1b2a8..8601e4ee70 100644
> --- a/BaseTools/Source/Python/AutoGen/GenC.py
> +++ b/BaseTools/Source/Python/AutoGen/GenC.py
> @@ -270,7 +270,7 @@ EFI_STATUS
>  EFIAPI
>  ${Function} (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>);
>  ${END}
>  """)
> @@ -283,7 +283,7 @@ EFI_STATUS
>  EFIAPI
>  ProcessModuleEntryPointList (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>)
>  
>  {
> @@ -297,7 +297,7 @@ EFI_STATUS
>  EFIAPI
>  ProcessModuleEntryPointList (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>)
>  
>  {
> @@ -312,7 +312,7 @@ EFI_STATUS
>  EFIAPI
>  ProcessModuleEntryPointList (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>)
>  
>  {
> @@ -680,7 +680,7 @@ EFI_STATUS
>  EFIAPI
>  ${Function} (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2  *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>);${END}
>  """),
>  }
> @@ -760,7 +760,7 @@ VOID
>  EFIAPI
>  ProcessLibrary${Type}List (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2  *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>)
>  {
>  ${BEGIN}  EFI_STATUS  Status;
> @@ -784,8 +784,8 @@ gModuleTypeHeaderFile = {
>  "UEFI_DRIVER"   :   ["Uefi.h",  "Library/BaseLib.h", 
> "Library/DebugLib.h", "Library/UefiBootServicesTableLib.h", 
> "Library/UefiDriverEntryPoint.h"],
>  "UEFI_APPLICATION"  :   ["Uefi.h",  "Library/BaseLib.h", 
> "Library/DebugLib.h", "Library/UefiBootServicesTableLib.h", 
> "Library/UefiApplicationEntryPoint.h"],
>  "SMM_CORE"  :   ["PiDxe.h", "Library/BaseLib.h", 
> "Library/DebugLib.h", "Library/UefiDriverEntryPoint.h"],
> -"MM_STANDALONE" :   ["PiSmm.h", "Library/BaseLib.h", 
> "Library/DebugLib.h", "Library/SmmDriverStandaloneEntryPoint.h"],
> -"MM_CORE_STANDALONE" :  ["PiSmm.h", "Library/BaseLib.h", 
> "Library/DebugLib.h", "Library/SmmCoreStandaloneEntryPoint.h"],
> +"MM_STANDALONE" :   ["PiMm.h",  "Library/BaseLib.h", 
> "Library/DebugLib.h", "Library/MmDriverStandaloneEntryPoint.h"],
> +"MM_CORE_STANDALONE":   ["PiMm.h",  "Library/BaseLib.h", 
> "Library/DebugLib.h", "Library/MmCoreStandaloneEntryPoint.h"],
>  "USER_DEFINED"  :   [gBasicHeaderFile]
>  }
>  
> -- 
> 2.16.2
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 15/18] ArmPkg: Extra action to update permissions for S-ELO MM Image.

[Achin Gupta]

Hi Supreeth,

This file was originally contributed by Ard a while back so worth poking him and
Leif for review. If MM is expected to be the only use case of this library then
it might make sense to pull in under the StandaloneMmPkg instead of relying on
PcdStandaloneMmEnable.

Cheers,
Achin

On Fri, Apr 06, 2018 at 03:42:20PM +0100, Supreeth Venkatesh wrote:
> The Standalone MM drivers runs in S-EL0 in AArch64 on ARM Standard
> Platforms and is deployed during SEC phase. The memory allocated to the
> Standalone MM drivers should be marked as RO+X.
> 
> During PE/COFF Image section parsing, this patch implements extra action
> "UpdatePeCoffPermissions" to request the privileged firmware in EL3 to
> update the permissions.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  .../DebugPeCoffExtraActionLib.c| 185 
> +++--
>  .../DebugPeCoffExtraActionLib.inf  |   7 +
>  2 files changed, 181 insertions(+), 11 deletions(-)
> 
> diff --git 
> a/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c 
> b/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
> index f298e58cdf..c87aaf05c7 100644
> --- a/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
> +++ b/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
> @@ -15,14 +15,165 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, 
> EITHER EXPRESS OR IMPLIED.
>  **/
>  
>  #include 
> -#include 
>  
> +#include 
>  #include 
> -#include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  
> +typedef RETURN_STATUS (*REGION_PERMISSION_UPDATE_FUNC) (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  );
> +
> +STATIC
> +RETURN_STATUS
> +UpdatePeCoffPermissions (
> +  IN  CONST PE_COFF_LOADER_IMAGE_CONTEXT  *ImageContext,
> +  IN  REGION_PERMISSION_UPDATE_FUNC   NoExecUpdater,
> +  IN  REGION_PERMISSION_UPDATE_FUNC   ReadOnlyUpdater
> +  )
> +{
> +  RETURN_STATUS Status;
> +  EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION   Hdr;
> +  EFI_IMAGE_OPTIONAL_HEADER_UNION   HdrData;
> +  UINTN Size;
> +  UINTN ReadSize;
> +  UINT32SectionHeaderOffset;
> +  UINTN NumberOfSections;
> +  UINTN Index;
> +  EFI_IMAGE_SECTION_HEADER  SectionHeader;
> +  PE_COFF_LOADER_IMAGE_CONTEXT  TmpContext;
> +  EFI_PHYSICAL_ADDRESS  Base;
> +
> +  //
> +  // We need to copy ImageContext since PeCoffLoaderGetImageInfo ()
> +  // will mangle the ImageAddress field
> +  //
> +  CopyMem (, ImageContext, sizeof (TmpContext));
> +
> +  if (TmpContext.PeCoffHeaderOffset == 0) {
> +Status = PeCoffLoaderGetImageInfo ();
> +if (RETURN_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR,
> +"%a: PeCoffLoaderGetImageInfo () failed (Status = %r)\n",
> +__FUNCTION__, Status));
> +  return Status;
> +}
> +  }
> +
> +  if (TmpContext.IsTeImage &&
> +  TmpContext.ImageAddress == ImageContext->ImageAddress) {
> +DEBUG ((DEBUG_INFO, "%a: ignoring XIP TE image at 0x%lx\n", __FUNCTION__,
> +  ImageContext->ImageAddress));
> +return RETURN_SUCCESS;
> +  }
> +
> +  if (TmpContext.SectionAlignment < EFI_PAGE_SIZE) {
> +//
> +// The sections need to be at least 4 KB aligned, since that is the
> +// granularity at which we can tighten permissions. So just clear the
> +// noexec permissions on the entire region.
> +//
> +if (!TmpContext.IsTeImage) {
> +  DEBUG ((DEBUG_WARN,
> +"%a: non-TE Image at 0x%lx has SectionAlignment < 4 KB (%lu)\n",
> +__FUNCTION__, ImageContext->ImageAddress, 
> TmpContext.SectionAlignment));
> +}
> +Base = ImageContext->ImageAddress & ~(EFI_PAGE_SIZE - 1);
> +Size = ImageContext->ImageAddress - Base + ImageContext->ImageSize;
> +return NoExecUpdater (Base, ALIGN_VALUE (Size, EFI_PAGE_SIZE));
> +  }
> +
> +  //
> +  // Read the PE/COFF Header. For PE32 (32-bit) this will read in too much
> +  // data, but that should not hurt anything. Hdr.Pe32->OptionalHeader.Magic
> +  // determines if this is a PE32 or PE32+ image. The magic is in the same
> +  // location in both images.
> +  //
> +  Hdr.Union = 
> +  Size = sizeof

Re: [edk2] [PATCH v1 14/18] StandaloneMmPkg: Describe the declaration, definition and fdf files.

[Achin Gupta]

Hi Supreeth,

One CIL.

On Fri, Apr 06, 2018 at 03:42:19PM +0100, Supreeth Venkatesh wrote:
> This patch describes the package declarations, definitions and firmware
> device files for creating standalone management mode image with
> core/foundation and drivers.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  StandaloneMmPkg/StandaloneMmPkg.dec |  47 +
>  StandaloneMmPkg/StandaloneMmPkg.dsc | 132 ++
>  StandaloneMmPkg/StandaloneMmPkg.fdf | 184 
> 
>  3 files changed, 363 insertions(+)
>  create mode 100644 StandaloneMmPkg/StandaloneMmPkg.dec
>  create mode 100644 StandaloneMmPkg/StandaloneMmPkg.dsc
>  create mode 100644 StandaloneMmPkg/StandaloneMmPkg.fdf
> 
> diff --git a/StandaloneMmPkg/StandaloneMmPkg.dec 
> b/StandaloneMmPkg/StandaloneMmPkg.dec
> new file mode 100644
> index 00..36521bb039
> --- /dev/null
> +++ b/StandaloneMmPkg/StandaloneMmPkg.dec
> @@ -0,0 +1,47 @@
> +## @file
> +# This package is a platform package that provide platform module/library
> +# required by Standalone MM platform.
> +#
> +# Copyright (c) 2016-2017, ARM Ltd. All rights reserved.
> +#
> +# This program and the accompanying materials
> +# are licensed and made available under the terms and conditions of the BSD 
> License
> +# which accompanies this distribution. The full text of the license may be 
> found at
> +# http://opensource.org/licenses/bsd-license.php
> +#
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +#
> +#
> +
> +[Defines]
> +  DEC_SPECIFICATION  = 0x0001001A
> +  PACKAGE_NAME   = StandaloneMmPkg
> +  PACKAGE_GUID   = 2AE82968-7769-4A85-A5BC-A0954CE54A5C
> +  PACKAGE_VERSION= 1.0
> +
> +[Includes]
> +  Include
> +
> +[LibraryClasses]
> +
> +[Guids]
> +  gStandaloneMmPkgTokenSpaceGuid   = { 0x18fe7632, 0xf5c8, 0x4e63, { 
> 0x8d, 0xe8, 0x17, 0xa5, 0x5c, 0x59, 0x13, 0xbd }}
> +  gMpInformationHobGuid= { 0xba33f15d, 0x4000, 0x45c1, { 
> 0x8e, 0x88, 0xf9, 0x16, 0x92, 0xd4, 0x57, 0xe3 }}
> +  gMmFvDispatchGuid= { 0xb65694cc, 0x09e3, 0x4c3b, { 
> 0xb5, 0xcd, 0x05, 0xf4, 0x4d, 0x3c, 0xdb, 0xff }}
> +
> +  ## Include/Guid/MmCoreData.h
> +  gMmCoreDataHobGuid   = { 0xa160bf99, 0x2aa4, 0x4d7d, { 
> 0x99, 0x93, 0x89, 0x9c, 0xb1, 0x2d, 0xf3, 0x76 }}
> +
> +  ## Include/Guid/MmramMemoryReserve.h
> +  gEfiMmPeiMmramMemoryReserveGuid  = { 0x0703f912, 0xbf8d, 0x4e2a, { 
> 0xbe, 0x07, 0xab, 0x27, 0x25, 0x25, 0xc5, 0x92 }}
> +
> +  gEfiStandaloneMmNonSecureBufferGuid  = { 0xf00497e3, 0xbfa2, 0x41a1, { 
> 0x9d, 0x29, 0x54, 0xc2, 0xe9, 0x37, 0x21, 0xc5 }}
> +  gEfiArmTfCpuDriverEpDescriptorGuid   = { 0x6ecbd5a1, 0xc0f8, 0x4702, { 
> 0x83, 0x01, 0x4f, 0xc2, 0xc5, 0x47, 0x0a, 0x51 }}
> +
> +[PcdsFeatureFlag]
> +  
> gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|FALSE|BOOLEAN|0x0001
> +
> +[Protocols]
> +  gEfiMmConfigurationProtocolGuid  = { 0xc109319, 0xc149, 0x450e,  { 
> 0xa3, 0xe3, 0xb9, 0xba, 0xdd, 0x9d, 0xc3, 0xa4 }}
> +
> diff --git a/StandaloneMmPkg/StandaloneMmPkg.dsc 
> b/StandaloneMmPkg/StandaloneMmPkg.dsc
> new file mode 100644
> index 00..8cc996f6b0
> --- /dev/null
> +++ b/StandaloneMmPkg/StandaloneMmPkg.dsc
> @@ -0,0 +1,132 @@
> +## @file
> +# Standalone MM Platform.
> +#
> +# Copyright (c) 2015, Intel Corporation. All rights reserved.
> +# Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
> +#
> +#This program and the accompanying materials
> +#are licensed and made available under the terms and conditions of the 
> BSD License
> +#which accompanies this distribution. The full text of the license may 
> be found at
> +#http://opensource.org/licenses/bsd-license.php
> +#
> +#THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +#WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +#
> +##
> +
> +
> +#
> +# Defines Section - statements that will be processed to create a Makefile.
> +#
> +
> +[Defines]
> +  PLATFORM_NAME  = StandaloneMm
> +  PLATFORM_GUID  = 9A4BBA60-B4

Re: [edk2] [PATCH v1 12/18] StandaloneMmPkg/CpuMm: Add CPU driver suitable for ARM Platforms.

[Achin Gupta]

Hi Supreeth,

Usual comment about copyright years and invalid comments. I also noticed some
TODOs and have provided comments for them. Please see inline

On Fri, Apr 06, 2018 at 03:42:17PM +0100, Supreeth Venkatesh wrote:
> This patch adds a simple CPU driver that exports the
> EFI_MM_CONFIGURATION_PROTOCOL to allow registration of the Standalone
> MM Foundation entry point. It preserves the existing notification
> mechanism for the configuration protocol.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  StandaloneMmPkg/Drivers/CpuMm/Arm/Entry.S  |  33 +++

This file is not used.

>  StandaloneMmPkg/Drivers/CpuMm/Arm/EventHandle.c| 231 
> +
>  StandaloneMmPkg/Drivers/CpuMm/Arm/Init.c   | 229 
>  .../CpuMm/Arm/PiMmStandloneArmTfCpuDriver.h|  89 
>  .../CpuMm/Arm/PiMmStandloneArmTfCpuDriver.inf  |  60 ++
>  StandaloneMmPkg/Drivers/CpuMm/Arm/StateSave.c  |  51 +
>  StandaloneMmPkg/Include/Guid/MpInformation.h   |  41 
>  7 files changed, 734 insertions(+)
>  create mode 100644 StandaloneMmPkg/Drivers/CpuMm/Arm/Entry.S
>  create mode 100644 StandaloneMmPkg/Drivers/CpuMm/Arm/EventHandle.c
>  create mode 100644 StandaloneMmPkg/Drivers/CpuMm/Arm/Init.c
>  create mode 100644 
> StandaloneMmPkg/Drivers/CpuMm/Arm/PiMmStandloneArmTfCpuDriver.h
>  create mode 100644 
> StandaloneMmPkg/Drivers/CpuMm/Arm/PiMmStandloneArmTfCpuDriver.inf
>  create mode 100644 StandaloneMmPkg/Drivers/CpuMm/Arm/StateSave.c
>  create mode 100644 StandaloneMmPkg/Include/Guid/MpInformation.h
> 
> diff --git a/StandaloneMmPkg/Drivers/CpuMm/Arm/Entry.S 
> b/StandaloneMmPkg/Drivers/CpuMm/Arm/Entry.S
> new file mode 100644
> index 00..0b6e1c330d
> --- /dev/null
> +++ b/StandaloneMmPkg/Drivers/CpuMm/Arm/Entry.S
> @@ -0,0 +1,33 @@
> +//
> +//  Copyright (c) 2017, ARM Limited. All rights reserved.
> +//
> +//  This program and the accompanying materials
> +//  are licensed and made available under the terms and conditions of the 
> BSD License
> +//  which accompanies this distribution.  The full text of the license may 
> be found at
> +//  http://opensource.org/licenses/bsd-license.php
> +//
> +//  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +//  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +//
> +//
> +
> +#include 
> +#include 
> +#include 
> +
> +.text
> +.align 3
> +
> +GCC_ASM_IMPORT(PiMmStandloneArmTfCpuDriverEntry)
> +GCC_ASM_EXPORT(_PiMmStandloneArmTfCpuDriverEntry)
> +
> +// Stub entry point to ensure that the stacks are completely unwound before
> +// signalling completion of event handling
> +ASM_PFX(_PiMmStandloneArmTfCpuDriverEntry):
> +  blPiMmStandloneArmTfCpuDriverEntry
> +  mov   x1, x0
> +  mov   x0, #(ARM_SMC_ID_MM_EVENT_COMPLETE_AARCH64 & 0x)
> +  movk  x0, #((ARM_SMC_ID_MM_EVENT_COMPLETE_AARCH64 >> 16) & 0x), lsl #16
> +  svc   #0
> +LoopForever:
> +  b LoopForever
> diff --git a/StandaloneMmPkg/Drivers/CpuMm/Arm/EventHandle.c 
> b/StandaloneMmPkg/Drivers/CpuMm/Arm/EventHandle.c
> new file mode 100644
> index 00..7b19f53ecb
> --- /dev/null
> +++ b/StandaloneMmPkg/Drivers/CpuMm/Arm/EventHandle.c
> @@ -0,0 +1,231 @@
> +/** @file
> +
> +  Copyright (c) 2016 HP Development Company, L.P.
> +  Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include  // for EFI_SYSTEM_CONTEXT
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "PiMmStandloneArmTfCpuDriver.h"
> +
> +EFI_STATUS
> +EFIAPI
> +MmFoundationEntryRegister(
> +  IN CONST EFI_MM_CONFIGURATION_PROTOCOL  *This,
> +  IN EFI_MM_ENTRY_POINTMmEntryPoint
> +  );
> +
> +//
> +// On ARM platforms every event is expected to have a GUID associated with
> +// it. It will be used by the MM Entry point to find the handler for the
&g

Re: [edk2] [PATCH v1 11/18] StandaloneMmPkg: MM driver entry point library.

[Achin Gupta]

Hi Supreeth,

Some of the DXE references will have to be removed and copyright years need to
be updated. If that sounds reasonable then..

Acked-by: Achin Gupta <achin.gu...@arm.com>

cheers,
Achin

On Fri, Apr 06, 2018 at 03:42:16PM +0100, Supreeth Venkatesh wrote:
> This patch implements module entry point library for Standalone
> management mode (MM) Drivers.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  .../Include/Library/MmDriverStandaloneEntryPoint.h | 148 
> +
>  .../StandaloneMmDriverEntryPoint.c | 102 ++
>  .../StandaloneMmDriverEntryPoint.inf   |  41 ++
>  3 files changed, 291 insertions(+)
>  create mode 100644 
> StandaloneMmPkg/Include/Library/MmDriverStandaloneEntryPoint.h
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
> 
> diff --git a/StandaloneMmPkg/Include/Library/MmDriverStandaloneEntryPoint.h 
> b/StandaloneMmPkg/Include/Library/MmDriverStandaloneEntryPoint.h
> new file mode 100644
> index 00..6fb9224e2e
> --- /dev/null
> +++ b/StandaloneMmPkg/Include/Library/MmDriverStandaloneEntryPoint.h
> @@ -0,0 +1,148 @@
> +/** @file
> +  Module entry point library for UEFI drivers, DXE Drivers, DXE Runtime 
> Drivers,
> +  and DXE SMM Drivers.
> +
> +Copyright (c) 2006 - 2008, Intel Corporation. All rights reserved.
> +Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
> +
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD 
> License
> +which accompanies this distribution.  The full text of the license may be 
> found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __MODULE_ENTRY_POINT_H__
> +#define __MODULE_ENTRY_POINT_H__
> +
> +///
> +///Declare the PI Specification Revision that this driver requires to 
> execute correctly.
> +///
> +extern CONST UINT32   _gMmRevision;
> +
> +/**
> +  The entry point of PE/COFF Image for a DXE Driver, DXE Runtime Driver, DXE 
> SMM Driver, or UEFI Driver.
> +
> +  This function is the entry point for a DXE Driver, DXE Runtime Driver, DXE 
> SMM Driver,
> +  or UEFI Driver.  This function must call ProcessLibraryConstructorList() 
> and
> +  ProcessModuleEntryPointList(). If the return status from 
> ProcessModuleEntryPointList()
> +  is an error status, then ProcessLibraryDestructorList() must be called. 
> The return value
> +  from ProcessModuleEntryPointList() is returned. If 
> _gDriverUnloadImageCount is greater
> +  than zero, then an unload handler must be registered for this image and 
> the unload handler
> +  must invoke ProcessModuleUnloadList().
> +  If _gUefiDriverRevision is not zero and SystemTable->Hdr.Revision is less 
> than _gUefiDriverRevison,
> +  then return EFI_INCOMPATIBLE_VERSION.
> +
> +
> +  @param  ImageHandle  The image handle of the DXE Driver, DXE Runtime 
> Driver, DXE SMM Driver, or UEFI Driver.
> +  @param  SystemTable  A pointer to the EFI System Table.
> +
> +  @retval  EFI_SUCCESS   The DXE Driver, DXE Runtime Driver, DXE 
> SMM Driver,
> + or UEFI Driver exited normally.
> +  @retval  EFI_INCOMPATIBLE_VERSION  _gUefiDriverRevision is greater than 
> SystemTable->Hdr.Revision.
> +  @retval  Other Return value from 
> ProcessModuleEntryPointList().
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +_ModuleEntryPoint (
> +  IN EFI_HANDLE ImageHandle,
> +  IN EFI_MM_SYSTEM_TABLE*MmSystemTable
> +  );
> +
> +
> +/**
> +  Required by the EBC compiler and identical in functionality to 
> _ModuleEntryPoint().
> +
> +  This function is required to call _ModuleEntryPoint() passing in 
> ImageHandle, and SystemTable.
> +
> +  @param  ImageHandle  The image handle of the DXE Driver, DXE Runtime 
> Driver, DXE SMM Driver, or UEFI Driver.
> +  @param  SystemTable  A pointer to the EFI System Table.
> +
> +  @retval  EFI_SUCCESS   The DXE Driver, DXE Runtime Driver, DXE 
> SMM Driver,
> + or UEFI Driver exited normally.
> +  @retval  EFI_INCOMPATIBLE_VERSION  _gUefiDriverRevision is greater t

Re: [edk2] [PATCH v1 10/18] StandaloneMmPkg/HobLib: Add AARCH64 Specific HOB Library for management mode.

[Achin Gupta]

Hi Supreeth,

On Fri, Apr 06, 2018 at 03:42:15PM +0100, Supreeth Venkatesh wrote:
> The Standalone MM environment is initialized during the SEC phase on ARM
> Standard Platforms. The MM Core driver implements an entry point module
> which is architecture specific and runs prior to the generic core driver
> code. The former creates a Hob list that the latter consumes. This
> happens in the same phase.
> 
> This patch implements a Hob library that can be used by the entry point
> module to produce a Hob list and by the core driver code to consume it.

References to DXE core need to be removed and the copyright years needs to be
updated.

I think it is worth getting this hoblib reviewed by the ArmPkg maintainers. 

Acked-by: Achin Gupta <achin.gu...@arm.com>

> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  StandaloneMmPkg/Library/HobLib/Arm/HobLib.c | 697 
> 
>  StandaloneMmPkg/Library/HobLib/HobLib.inf   |  45 ++
>  2 files changed, 742 insertions(+)
>  create mode 100644 StandaloneMmPkg/Library/HobLib/Arm/HobLib.c
>  create mode 100644 StandaloneMmPkg/Library/HobLib/HobLib.inf
> 
> diff --git a/StandaloneMmPkg/Library/HobLib/Arm/HobLib.c 
> b/StandaloneMmPkg/Library/HobLib/Arm/HobLib.c
> new file mode 100644
> index 00..62abf47f95
> --- /dev/null
> +++ b/StandaloneMmPkg/Library/HobLib/Arm/HobLib.c
> @@ -0,0 +1,697 @@
> +/** @file
> +  HOB Library implementation for DxeCore driver.
> +
> +Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
> +Copyright (c) 2017, ARM Limited. All rights reserved.
> +
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD 
> License
> +which accompanies this distribution.  The full text of the license may be 
> found at
> +http://opensource.org/licenses/bsd-license.php.
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +//
> +// Cache copy of HobList pointer.
> +//
> +VOID *gHobList = NULL;
> +
> +/**
> +  Returns the pointer to the HOB list.
> +
> +  This function returns the pointer to first HOB in the list.
> +  For PEI phase, the PEI service GetHobList() can be used to retrieve the 
> pointer
> +  to the HOB list.  For the DXE phase, the HOB list pointer can be retrieved 
> through
> +  the EFI System Table by looking up theHOB list GUID in the System 
> Configuration Table.
> +  Since the System Configuration Table does not exist that the time the DXE 
> Core is
> +  launched, the DXE Core uses a global variable from the DXE Core Entry 
> Point Library
> +  to manage the pointer to the HOB list.
> +
> +  If the pointer to the HOB list is NULL, then ASSERT().
> +
> +  @return The pointer to the HOB list.
> +
> +**/
> +VOID *
> +EFIAPI
> +GetHobList (
> +  VOID
> +  )
> +{
> +  ASSERT (gHobList != NULL);
> +  return gHobList;
> +}
> +
> +/**
> +  Returns the next instance of a HOB type from the starting HOB.
> +
> +  This function searches the first instance of a HOB type from the starting 
> HOB pointer.
> +  If there does not exist such HOB type from the starting HOB pointer, it 
> will return NULL.
> +  In contrast with macro GET_NEXT_HOB(), this function does not skip the 
> starting HOB pointer
> +  unconditionally: it returns HobStart back if HobStart itself meets the 
> requirement;
> +  caller is required to use GET_NEXT_HOB() if it wishes to skip current 
> HobStart.
> +
> +  If HobStart is NULL, then ASSERT().
> +
> +  @param  Type  The HOB type to return.
> +  @param  HobStart  The starting HOB pointer to search from.
> +
> +  @return The next instance of a HOB type from the starting HOB.
> +
> +**/
> +VOID *
> +EFIAPI
> +GetNextHob (
> +  IN UINT16 Type,
> +  IN CONST VOID *HobStart
> +  )
> +{
> +  EFI_PEI_HOB_POINTERS  Hob;
> +
> +  ASSERT (HobStart != NULL);
> +
> +  Hob.Raw = (UINT8 *) HobStart;
> +  //
> +  // Parse the HOB list until end of list or matching type is found.
> +  //
> +  while (!END_OF_HOB_LIST (Hob)) {
> +if (Hob.Header->HobType == Type) {
> +  return Hob.Raw;
> +}
> +Hob.Raw = GET_NEXT_HOB (Hob);
> +  }
> +  return NULL;
> +}
> +
> +/**
> +  Returns the first instance of a HOB type among the wh

Re: [edk2] [PATCH v1 09/18] StandaloneMmPkg/MemoryAllocationLib: Add MM memory allocation library.

[Achin Gupta]

Hi Supreeth,

On Fri, Apr 06, 2018 at 03:42:14PM +0100, Supreeth Venkatesh wrote:
> This patch implements management mode memory allocation services.The
> implementation borrows the MM Core Memory Allocation services as the
> primitive for memory allocation instead of using MM System Table
> services.

The commit message did not really register with me. Once the MMRAM ranges have
been conveyed to the MMST memory allocation services (through
MemoryAllocationLibConstructor()), all functions in MemoryAllocationLib.c use
the MMST services. The message seems to indicate otherwise.

On Arm, the gEfiMmPeiMmramMemoryReserveGuid HOB is used to convey the MMRAM
ranges. It seems x86 uses gMmCoreDataHobGuid HOB. So it worth getting this
reviewed by Jiewen.

The copyright years in the files need to be updated.

With that in mind..

Acked-by: Achin Gupta <achin.gu...@arm.com>

> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  StandaloneMmPkg/Include/Guid/MmCoreData.h  | 132 +++
>  StandaloneMmPkg/Include/Guid/MmramMemoryReserve.h  |  62 ++
>  .../MemoryAllocationLib/MemoryAllocationLib.c  | 907 
> +
>  .../MemoryAllocationLib/MemoryAllocationLib.inf|  49 ++
>  .../MemoryAllocationLib/MemoryAllocationServices.h |  38 +
>  5 files changed, 1188 insertions(+)
>  create mode 100644 StandaloneMmPkg/Include/Guid/MmCoreData.h
>  create mode 100644 StandaloneMmPkg/Include/Guid/MmramMemoryReserve.h
>  create mode 100644 
> StandaloneMmPkg/Library/MemoryAllocationLib/MemoryAllocationLib.c
>  create mode 100644 
> StandaloneMmPkg/Library/MemoryAllocationLib/MemoryAllocationLib.inf
>  create mode 100644 
> StandaloneMmPkg/Library/MemoryAllocationLib/MemoryAllocationServices.h
> 
> diff --git a/StandaloneMmPkg/Include/Guid/MmCoreData.h 
> b/StandaloneMmPkg/Include/Guid/MmCoreData.h
> new file mode 100644
> index 00..c0ac772014
> --- /dev/null
> +++ b/StandaloneMmPkg/Include/Guid/MmCoreData.h
> @@ -0,0 +1,132 @@
> +/** @file
> +  MM Core data.
> +
> +Copyright (c) 2015, Intel Corporation. All rights reserved.
> +This program and the accompanying materials are licensed and made available 
> under
> +the terms and conditions of the BSD License that accompanies this 
> distribution.
> +The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php.
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __MM_CORE_DATA_H__
> +#define __MM_CORE_DATA_H__
> +
> +#define MM_CORE_DATA_HOB_GUID \
> +  { 0xa160bf99, 0x2aa4, 0x4d7d, { 0x99, 0x93, 0x89, 0x9c, 0xb1, 0x2d, 0xf3, 
> 0x76 }}
> +
> +extern EFI_GUID gMmCoreDataHobGuid;
> +
> +typedef struct {
> +  //
> +  // Address pointer to MM_CORE_PRIVATE_DATA
> +  //
> +  EFI_PHYSICAL_ADDRESS   Address;
> +} MM_CORE_DATA_HOB_DATA;
> +
> +
> +///
> +/// Define values for the communications buffer used when 
> gEfiEventDxeDispatchGuid is
> +/// event signaled.  This event is signaled by the DXE Core each time the 
> DXE Core
> +/// dispatcher has completed its work.  When this event is signaled, the MM 
> Core
> +/// if notified, so the MM Core can dispatch MM drivers.  If 
> COMM_BUFFER_MM_DISPATCH_ERROR
> +/// is returned in the communication buffer, then an error occurred 
> dispatching MM
> +/// Drivers.  If COMM_BUFFER_MM_DISPATCH_SUCCESS is returned, then the MM 
> Core
> +/// dispatched all the drivers it could.  If COMM_BUFFER_MM_DISPATCH_RESTART 
> is
> +/// returned, then the MM Core just dispatched the MM Driver that registered
> +/// the MM Entry Point enabling the use of MM Mode.  In this case, the MM 
> Core
> +/// should be notified again to dispatch more MM Drivers using MM Mode.
> +///
> +#define COMM_BUFFER_MM_DISPATCH_ERROR0x00
> +#define COMM_BUFFER_MM_DISPATCH_SUCCESS  0x01
> +#define COMM_BUFFER_MM_DISPATCH_RESTART  0x02
> +
> +///
> +/// Signature for the private structure shared between the MM IPL and the MM 
> Core
> +///
> +#define MM_CORE_PRIVATE_DATA_SIGNATURE  SIGNATURE_32 ('m', 'm', 'i', 'c')
> +
> +///
> +/// Private structure that is used to share information between the MM IPL 
> and
> +/// the MM Core.  This structure is allocated from memory of type 
> EfiRuntimeServicesData.
> +/// Since runtime memory types are converted to available memory when a 
> legacy boot
> +/// is performed, the MM Core must not access any fields of this structure 
> if a legacy
> +/// boot is

Re: [edk2] [PATCH v1 08/18] StandaloneMmPkg/MemLib: AARCH64 Specific instance of memory check library.

[Achin Gupta]

Hi Jiewen,

On Mon, Apr 16, 2018 at 10:30:55PM +, Yao, Jiewen wrote:
> Hi
> I don't think this lib is generic, because it hardcode the physical address 
> bits.
> 
> PhysicalAddressBits = 36;
> 
> For X86 CPU, we get it from CPUID. :-)
> 
> As enhancement, we may put most common C-code logic (such as CopyMem, or 
> memmap calculation) to StandaloneMmPkg/MemLib, and only include the 
> PhysicalAddresBit calculation under StandaloneMmPkg/MemLib/Arm folder.
> 
> As such, we know clearly on which one is ARM specific.

My point was that the hardocoded PA bits were not introduced to make this code
work on Arm. This has been present in the StandaloneMmPkg from the outset. I
guess for x86 you have moved on to getting this information from the
CPUID. Afaics, this function is not be used on Arm platforms but Supreeth will
double check. If that is the case then only the generic library will be required
minus this function.

cheers,
Achin

> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Achin
> > Gupta
> > Sent: Monday, April 16, 2018 11:13 PM
> > To: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> > Cc: ard.biesheu...@linaro.org; edk2-devel@lists.01.org;
> > leif.lindh...@linaro.org; Yao, Jiewen <jiewen@intel.com>; Gao, Liming
> > <liming@intel.com>; Kinney, Michael D <michael.d.kin...@intel.com>;
> > n...@arm.com
> > Subject: Re: [edk2] [PATCH v1 08/18] StandaloneMmPkg/MemLib: AARCH64
> > Specific instance of memory check library.
> > 
> > Hi Supreeth,
> > 
> > On Fri, Apr 06, 2018 at 03:42:13PM +0100, Supreeth Venkatesh wrote:
> > > MM memory check library library implementation. This library consumes
> > > MM_ACCESS_PROTOCOL to get MMRAM information. In order to use this
> > > library instance, the platform should produce all MMRAM range via
> > > MM_ACCESS_PROTOCOL, including the range for firmware (like MM Core
> > > and MM driver) and/or specific dedicated hardware.
> > >
> > > This patch provides services for MM Memory Operation.
> > > The management mode Mem Library provides function for checking if buffer
> > > is outside MMRAM and valid. It also provides functions for copy data
> > > from MMRAM to non-MMRAM, from non-MMRAM to MMRAM,
> > > from non-MMRAM to non-MMRAM, or set data in non-MMRAM.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> > > Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> > > ---
> > >  StandaloneMmPkg/Include/Library/MemLib.h| 140 ++
> > >  StandaloneMmPkg/Library/MemLib/Arm/MemLib.c | 276
> > 
> > 
> > Why is this Library Arm specific. Apart from cosmetics tweaks, it has not
> > changed since it was originally contributed?
> > 
> > cheers,
> > Achin
> > 
> > >  StandaloneMmPkg/Library/MemLib/MemLib.inf   |  47 +
> > >  3 files changed, 463 insertions(+)
> > >  create mode 100644 StandaloneMmPkg/Include/Library/MemLib.h
> > >  create mode 100644 StandaloneMmPkg/Library/MemLib/Arm/MemLib.c
> > >  create mode 100644 StandaloneMmPkg/Library/MemLib/MemLib.inf
> > >
> > > diff --git a/StandaloneMmPkg/Include/Library/MemLib.h
> > b/StandaloneMmPkg/Include/Library/MemLib.h
> > > new file mode 100644
> > > index 00..3264f10010
> > > --- /dev/null
> > > +++ b/StandaloneMmPkg/Include/Library/MemLib.h
> > > @@ -0,0 +1,140 @@
> > > +/** @file
> > > +  Provides services for MM Memory Operation.
> > > +
> > > +  The MM Mem Library provides function for checking if buffer is outside
> > MMRAM and valid.
> > > +  It also provides functions for copy data from MMRAM to non-MMRAM,
> > from non-MMRAM to MMRAM,
> > > +  from non-MMRAM to non-MMRAM, or set data in non-MMRAM.
> > > +
> > > +  Copyright (c) 2015, Intel Corporation. All rights reserved.
> > > +  Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
> > > +
> > > +  This program and the accompanying materials
> > > +  are licensed and made available under the terms and conditions of the 
> > > BSD
> > License
> > > +  which accompanies this distribution.  The full text of the license may 
> > > be
> > found at
> > > +  http://opensource.org/licenses/bsd-license.php
> > > +
> > > +  THE PROGRAM IS DISTRIBUTED UNDER T

Re: [edk2] [PATCH v1 08/18] StandaloneMmPkg/MemLib: AARCH64 Specific instance of memory check library.

[Achin Gupta]

Hi Supreeth,

On Fri, Apr 06, 2018 at 03:42:13PM +0100, Supreeth Venkatesh wrote:
> MM memory check library library implementation. This library consumes
> MM_ACCESS_PROTOCOL to get MMRAM information. In order to use this
> library instance, the platform should produce all MMRAM range via
> MM_ACCESS_PROTOCOL, including the range for firmware (like MM Core
> and MM driver) and/or specific dedicated hardware.
> 
> This patch provides services for MM Memory Operation.
> The management mode Mem Library provides function for checking if buffer
> is outside MMRAM and valid. It also provides functions for copy data
> from MMRAM to non-MMRAM, from non-MMRAM to MMRAM,
> from non-MMRAM to non-MMRAM, or set data in non-MMRAM.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  StandaloneMmPkg/Include/Library/MemLib.h| 140 ++
>  StandaloneMmPkg/Library/MemLib/Arm/MemLib.c | 276 
> 

Why is this Library Arm specific. Apart from cosmetics tweaks, it has not
changed since it was originally contributed?

cheers,
Achin

>  StandaloneMmPkg/Library/MemLib/MemLib.inf   |  47 +
>  3 files changed, 463 insertions(+)
>  create mode 100644 StandaloneMmPkg/Include/Library/MemLib.h
>  create mode 100644 StandaloneMmPkg/Library/MemLib/Arm/MemLib.c
>  create mode 100644 StandaloneMmPkg/Library/MemLib/MemLib.inf
> 
> diff --git a/StandaloneMmPkg/Include/Library/MemLib.h 
> b/StandaloneMmPkg/Include/Library/MemLib.h
> new file mode 100644
> index 00..3264f10010
> --- /dev/null
> +++ b/StandaloneMmPkg/Include/Library/MemLib.h
> @@ -0,0 +1,140 @@
> +/** @file
> +  Provides services for MM Memory Operation.
> +
> +  The MM Mem Library provides function for checking if buffer is outside 
> MMRAM and valid.
> +  It also provides functions for copy data from MMRAM to non-MMRAM, from 
> non-MMRAM to MMRAM,
> +  from non-MMRAM to non-MMRAM, or set data in non-MMRAM.
> +
> +  Copyright (c) 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#ifndef _MM_MEM_LIB_H_
> +#define _MM_MEM_LIB_H_
> +
> +/**
> +  This function check if the buffer is valid per processor architecture and 
> not overlap with MMRAM.
> +
> +  @param Buffer  The buffer start address to be checked.
> +  @param Length  The buffer length to be checked.
> +
> +  @retval TRUE  This buffer is valid per processor architecture and not 
> overlap with MMRAM.
> +  @retval FALSE This buffer is not valid per processor architecture or 
> overlap with MMRAM.
> +**/
> +BOOLEAN
> +EFIAPI
> +MmIsBufferOutsideMmValid (
> +  IN EFI_PHYSICAL_ADDRESS  Buffer,
> +  IN UINT64Length
> +  );
> +
> +/**
> +  Copies a source buffer (non-MMRAM) to a destination buffer (MMRAM).
> +
> +  This function copies a source buffer (non-MMRAM) to a destination buffer 
> (MMRAM).
> +  It checks if source buffer is valid per processor architecture and not 
> overlap with MMRAM.
> +  If the check passes, it copies memory and returns EFI_SUCCESS.
> +  If the check fails, it return EFI_SECURITY_VIOLATION.
> +  The implementation must be reentrant.
> +
> +  @param  DestinationBuffer   The pointer to the destination buffer of the 
> memory copy.
> +  @param  SourceBufferThe pointer to the source buffer of the memory 
> copy.
> +  @param  Length  The number of bytes to copy from SourceBuffer 
> to DestinationBuffer.
> +
> +  @retval EFI_SECURITY_VIOLATION The SourceBuffer is invalid per processor 
> architecture or overlap with MMRAM.
> +  @retval EFI_SUCCESSMemory is copied.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +MmCopyMemToSmram (
> +  OUT VOID   *DestinationBuffer,
> +  IN CONST VOID  *SourceBuffer,
> +  IN UINTN   Length
> +  );
> +
> +/**
> +  Copies a source buffer (MMRAM) to a destination buffer (NON-MMRAM).
> +
> +  This function copies a source buffer (non-MMRAM) to a destination buffer 
> (MMRAM).
> +  It checks if destination buffer is valid per processor architecture and 
> not ove

Re: [edk2] [PATCH v1 07/18] StandaloneMmPkg/FvLib: Add a common FV Library for management mode.

[Achin Gupta]

Hi Supreeth,

On Fri, Apr 06, 2018 at 03:42:12PM +0100, Supreeth Venkatesh wrote:
> This patch implements a firmware volume library that can be used by the
> Standalone management mode core module to parse the firmware volume.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>

I have not contributed to this patch at all. Could you please remove me? 

Not being an expert, I will wait for Jiewen's feedback cycle to complete.

cheers,
Achin

> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  StandaloneMmPkg/Include/Library/FvLib.h | 109 ++
>  StandaloneMmPkg/Library/FvLib/FvLib.c   | 366 
> 
>  StandaloneMmPkg/Library/FvLib/FvLib.inf |  57 +
>  3 files changed, 532 insertions(+)
>  create mode 100644 StandaloneMmPkg/Include/Library/FvLib.h
>  create mode 100644 StandaloneMmPkg/Library/FvLib/FvLib.c
>  create mode 100644 StandaloneMmPkg/Library/FvLib/FvLib.inf
> 
> diff --git a/StandaloneMmPkg/Include/Library/FvLib.h 
> b/StandaloneMmPkg/Include/Library/FvLib.h
> new file mode 100644
> index 00..13e1ae2b01
> --- /dev/null
> +++ b/StandaloneMmPkg/Include/Library/FvLib.h
> @@ -0,0 +1,109 @@
> +/** @file
> +
> +Copyright (c) 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
> +
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD 
> License
> +which accompanies this distribution.  The full text of the license may be 
> found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef _FV_LIB_H_
> +#define _FV_LIB_H_
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> +  Given the input file pointer, search for the next matching file in the
> +  FFS volume as defined by SearchType. The search starts from FileHeader 
> inside
> +  the Firmware Volume defined by FwVolHeader.
> +
> +  @param  SearchType  Filter to find only files of this type.
> +  Type EFI_FV_FILETYPE_ALL causes no filtering to be 
> done.
> +  @param  FwVolHeader Pointer to the FV header of the volume to search.
> +  This parameter must point to a valid FFS volume.
> +  @param  FileHeader  Pointer to the current file from which to begin 
> searching.
> +  This pointer will be updated upon return to reflect 
> the file found.
> +
> +  @retval EFI_NOT_FOUND  No files matching the search criteria were found
> +  @retval EFI_SUCCESS
> +**/
> +EFI_STATUS
> +EFIAPI
> +FfsFindNextFile (
> +  IN EFI_FV_FILETYPE SearchType,
> +  IN EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader,
> +  IN OUT EFI_FFS_FILE_HEADER **FileHeader
> +  );
> +
> +/**
> +  Given the input file pointer, search for the next matching section in the
> +  FFS volume.
> +
> +  @param  SearchTypeFilter to find only sections of this type.
> +  @param  FfsFileHeader Pointer to the current file to search.
> +  @param  SectionHeader Pointer to the Section matching SectionType in 
> FfsFileHeader.
> +NULL if section not found
> +
> +  @retval  EFI_NOT_FOUND  No files matching the search criteria were found
> +  @retval  EFI_SUCCESS
> +**/
> +EFI_STATUS
> +FfsFindSection (
> +  IN EFI_SECTION_TYPE  SectionType,
> +  IN EFI_FFS_FILE_HEADER   *FfsFileHeader,
> +  IN OUT EFI_COMMON_SECTION_HEADER **SectionHeader
> +  );
> +
> +/**
> +  Locates a section within a series of sections
> +  with the specified section type.
> +
> +  @param[in]   SectionsThe sections to search
> +  @param[in]   SizeOfSections  Total size of all sections
> +  @param[in]   SectionType The section type to locate
> +  @param[out]  FoundSectionThe FFS section if found
> +
> +  @retval EFI_SUCCESS   The file and section was found
> +  @retval EFI_NOT_FOUND The file and section was not found
> +  @retval EFI_VOLUME_CORRUPTED  The firmware volume was corrupted
> +**/
> +EFI_STATUS
> +EFIAPI
> +FindFfsSectionInSections (
> +  IN  VOID *Sections,
> +  IN  UINTNSizeOfSections,
> +  IN  EFI_SECTION_TYPE SectionType,
> +  OUT EFI_COMMON_SECTION_HEADER**FoundSection
> +  );
> +
> +/**
> +  Given the input file pointer, search for the next matching section in the
> +  FFS volume.
> +
> +  @p

Re: [edk2] [PATCH v1 06/18] StandaloneMmPkg: Add an AArch64 specific entry point library.

[Achin Gupta]

Hi Supreeth,

On Fri, Apr 06, 2018 at 03:42:11PM +0100, Supreeth Venkatesh wrote:
> The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
> Platforms and is initialised during the SEC phase. ARM Trusted firmware
> in EL3 is responsible for initialising the architectural context for
> S-EL0 and loading the Standalone MM image. The memory allocated to this
> image is marked as RO+X. Heap memory is marked as RW+XN.
> 
> Certain actions have to be completed prior to executing the generic code
> in the Standalone MM Core module. These are:
> 
> 1. Memory permission attributes for each section of the Standalone MM
>Core module need to be changed prior to accessing any RW data.
> 
> 2. A Hob list has to be created with information that allows the MM
>environment to initialise and dispatch drivers.
> 
> Furthermore, this module is responsible for handing over runtime MM
> events to the Standalone MM CPU driver and returning control to ARM
> Trusted Firmware upon event completion. Hence it needs to know the CPU
> driver entry point.
> 
> This patch implements an entry point module that ARM Trusted Firmware
> jumps to in S-EL0. It then performs the above actions before calling the
> Standalone MM Foundation entry point and handling subsequent MM events.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  .../Library/Arm/StandaloneMmCoreEntryPoint.h   | 232 +
>  .../Include/Library/MmCoreStandaloneEntryPoint.h   | 101 
>  .../StandaloneMmCoreEntryPoint/Arm/CreateHobList.c | 200 +++
>  .../Arm/SetPermissions.c   | 278 
> +
>  .../Arm/StandaloneMmCoreEntryPoint.c   | 264 +++
>  .../StandaloneMmCoreEntryPoint.inf |  53 
>  StandaloneMmPkg => StandaloneMmPkg~HEAD|   0
>  7 files changed, 1128 insertions(+)
>  create mode 100644 
> StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h

The names of this file and the one below are re-arrangements of the same
words. This is confusing. It would be better to stick to one convention. Since
the name of the package starts with StandaloneMm, everything else should follow
suit.

So can this file be renamed to ArmStandaloneMmCoreEntryPoint.h and the one below
to StandaloneMmCoreEntryPoint.h unless you think this can be done differently?

>  create mode 100644 
> StandaloneMmPkg/Include/Library/MmCoreStandaloneEntryPoint.h



>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/SetPermissions.c

PeCoffExtraActionLib and the HobLib are pre-requisites for these two
files. Should they not appear first in the patch stack?

>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/StandaloneMmCoreEntryPoint.c
>  create mode 100644 
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf

Can this and the tagged file above go in a separate commit? Cannot see how they
are related to the Arm specific entry point.

>  rename StandaloneMmPkg => StandaloneMmPkg~HEAD (100%)
> 
> diff --git a/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h 
> b/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h
> new file mode 100644
> index 00..029c6c476c
> --- /dev/null
> +++ b/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h
> @@ -0,0 +1,232 @@
> +/** @file
> +  Entry point to the Standalone MM Foundation when initialised during the SEC
> +  phase on ARM platforms
> +
> +Copyright (c) 2017, ARM Ltd. All rights reserved.

Copyright year needs to be updated.

> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD 
> License
> +which accompanies this distribution.  The full text of the license may be 
> found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __MODULE_ENTRY_POINT_H__
> +#define __MODULE_ENTRY_POINT_H__

Name of this define needs to be changed

> +
> +#include 
> +#include 
> +
> +#define CPU_INFO_FLAG_PRIMARY_CPU  0x0001
> +
> +typedef
> +EFI_STATUS
> +(*PI_MM_CPU_TP_FW_ENTRYPOINT) (
> +  IN UINTN EventId,
> +  IN UINTN CpuNumber,
> +  IN UINTN NsCommBufferAddr
> +  );

This typedef is not being used.

> +
>

Re: [edk2] [PATCH v1 05/18] ArmPkg/ArmMmuLib: Add MMU library inf file suitable for use in S-EL0.

[Achin Gupta]

On Fri, Apr 06, 2018 at 03:42:10PM +0100, Supreeth Venkatesh wrote:
> This patch adds the definitions, sources, packages and library classes
> needed to compile and link MMU Library suitable for use in S-EL0.
> 
> Currently, this is used only during the Standalone MM Core
> initialization and hence defined as MM_CORE_STANDALONE Module.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  ArmPkg/Library/ArmMmuLib/ArmMmuSecLib.inf | 37 
> +++
>  1 file changed, 37 insertions(+)
>  create mode 100644 ArmPkg/Library/ArmMmuLib/ArmMmuSecLib.inf
> 
> diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuSecLib.inf 
> b/ArmPkg/Library/ArmMmuLib/ArmMmuSecLib.inf
> new file mode 100644
> index 00..5c802923da
> --- /dev/null
> +++ b/ArmPkg/Library/ArmMmuLib/ArmMmuSecLib.inf
> @@ -0,0 +1,37 @@
> +#/** @file
> +#
> +#  Copyright (c) 2017, ARM Limited. All rights reserved.
> +#
> +#  This program and the accompanying materials
> +#  are licensed and made available under the terms and conditions of the BSD 
> License
> +#  which accompanies this distribution. The full text of the license may be 
> found at
> +#  http://opensource.org/licenses/bsd-license.php
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +#
> +#
> +#**/
> +
> +[Defines]
> +  INF_VERSION= 0x0001001A
> +  BASE_NAME  = ArmMmuSecLib
> +  FILE_GUID  = da8f0232-fb14-42f0-922c-63104d2c70bd
> +  MODULE_TYPE= MM_CORE_STANDALONE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = ArmMmuSecLib|MM_CORE_STANDALONE
> +  PI_SPECIFICATION_VERSION   = 0x00010032
> +  CONSTRUCTOR= ArmMmuSecLibConstructor
> +
> +[Sources.AARCH64]
> +  AArch64/ArmMmuSecLib.c
> +
> +[Packages]
> +  ArmPkg/ArmPkg.dec
> +  MdePkg/MdePkg.dec
> +
> +[LibraryClasses]
> +  ArmLib
> +  CacheMaintenanceLib
> +  MemoryAllocationLib
> +
> +
> -- 
> 2.16.2
> 

Acked-by: Achin Gupta <achin.gu...@arm.com>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 04/18] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

[Achin Gupta]

Hi Supreeth,

On Fri, Apr 06, 2018 at 03:42:09PM +0100, Supreeth Venkatesh wrote:
> The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
> Platforms. Privileged firmware e.g. ARM Trusted Firmware sets up its
> architectural context including the initial translation tables for the
> S-EL1/EL0 translation regime. The MM environment could still request ARM
> TF to change the memory attributes of memory regions during
> initialization.

The commit message needs more detail to better flesh out why we are doing what
we are doing here i.e. the StandaloneMm image is a FV that encapsulates the MM
foundation and drivers. These are PE-COFF images with data and text
segments. Arm TF does not have visibility of the contents of the FV. Moreover,
the driver images are relocated upon dispatch. However, to initialise the MM
environment, Arm TF has to create translation tables with sane default
attributes for the memory occupied by the FV

I am hoping you can extrapolate from here and clearly describe what problem this
library solves.

> 
> This patch adds a simple MMU library suitable for execution in S-EL0 and
> requesting operations from higher exception levels.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c | 146 
> 
>  1 file changed, 146 insertions(+)
>  create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c
> 
> diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c 
> b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c

I am not sure about the name of the library. ArmMmuSecLib sounds like an MMU
library for the SEC phase in the Normal world. Can we call it
ArmMmuSecStandaloneMmLib or similar.

> new file mode 100644
> index 00..56969e31d1
> --- /dev/null
> +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c
> @@ -0,0 +1,146 @@
> +/** @file
> +*  File managing the MMU for ARMv8 architecture in S-EL0
> +*
> +*  Copyright (c) 2017, ARM Limited. All rights reserved.

Nit: Copyright 2018? For this and other files?

> +*
> +*  This program and the accompanying materials
> +*  are licensed and made available under the terms and conditions of the BSD 
> License
> +*  which accompanies this distribution.  The full text of the license may be 
> found at
> +*  http://opensource.org/licenses/bsd-license.php
> +*
> +*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +*
> +**/
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +EFI_STATUS
> +RequestMemoryPermissionChange(
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length,
> +  IN  UINTN Permissions
> +  )
> +{
> +  EFI_STATUSStatus;
> +  ARM_SVC_ARGS  ChangeMemoryPermissionsSvcArgs = {0};
> +
> +  ChangeMemoryPermissionsSvcArgs.Arg0 = 
> ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64;
> +  ChangeMemoryPermissionsSvcArgs.Arg1 = BaseAddress;
> +  ChangeMemoryPermissionsSvcArgs.Arg2 = (Length >= EFI_PAGE_SIZE) ? \
> + Length >> EFI_PAGE_SHIFT : 1;
> +  ChangeMemoryPermissionsSvcArgs.Arg3 = Permissions;
> +
> +  ArmCallSvc();
> +
> +  Status = ChangeMemoryPermissionsSvcArgs.Arg0;
> +
> +  switch (Status) {
> +  case ARM_SVC_SPM_RET_SUCCESS:
> +Status = EFI_SUCCESS;
> +break;
> +
> +  case ARM_SVC_SPM_RET_NOT_SUPPORTED:
> +Status = EFI_UNSUPPORTED;
> +break;
> +
> +  case ARM_SVC_SPM_RET_INVALID_PARAMS:
> +Status = EFI_INVALID_PARAMETER;
> +break;
> +
> +  case ARM_SVC_SPM_RET_DENIED:
> +Status = EFI_ACCESS_DENIED;
> +break;
> +
> +  case ARM_SVC_SPM_RET_NO_MEMORY:
> +Status = EFI_BAD_BUFFER_SIZE;
> +break;
> +
> +  default:
> +Status = EFI_ACCESS_DENIED;
> +ASSERT (0);
> +  }
> +
> +  return Status;
> +}
> +
> +EFI_STATUS
> +ArmSetMemoryRegionNoExec (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  )
> +{
> +  return RequestMemoryPermissionChange(BaseAddress,
> +   Length,
> +   SET_MEM_ATTR_MAKE_PERM_REQUEST( \
> + SET_MEM_ATTR_DATA_PERM_RO, \
> + SET_MEM_ATTR_CODE_PERM_XN));
> +}
> +
> +EFI_STATUS

Re: [edk2] [PATCH v1 01/18] ArmPkg: Add PCDs needed for MM communication driver.

[Achin Gupta]

On Fri, Apr 06, 2018 at 03:42:06PM +0100, Supreeth Venkatesh wrote:
> This patch defines PCDs to describe the base address and size of
> communication buffer between normal world (uefi) and standalone MM
> environment in the secure world.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  ArmPkg/ArmPkg.dec | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
> index a55b6268ff..b64942220b 100644
> --- a/ArmPkg/ArmPkg.dec
> +++ b/ArmPkg/ArmPkg.dec
> @@ -223,6 +223,9 @@
>gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029
>gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A
>  
> +  gArmTokenSpaceGuid.PcdMmBufferBase|0|UINT64|0x0045
> +  gArmTokenSpaceGuid.PcdMmBufferSize|0|UINT64|0x0046
> +
>  [PcdsFixedAtBuild.common, PcdsDynamic.common]
>#
># ARM Architectural Timer
> -- 
> 2.16.2
> 

Acked-by: Achin Gupta <achin.gu...@arm.com>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 03/18] ArmPkg/Include: Add MM interface SVC return codes.

[Achin Gupta]

Hi Supreeth,

On Fri, Apr 06, 2018 at 03:42:08PM +0100, Supreeth Venkatesh wrote:
> This patch adds the Management Mode(MM) SVC return codes as specified in
> http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf.
> Also, corrects SVC ID for retrieving SPM version information.

The MM interface specification says nothing about these SVCs. At the moment,
this interface is exported by Arm TF. So lets say that instead. Also, it would
make sense to rename this file to ArmTfSpmSvc.h or similar 'cause this SVC
interface is usable by non-MM partitions too.

cheers,
Achin

> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  ArmPkg/Include/IndustryStandard/ArmMmSvc.h | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h 
> b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
> index 4c7b6c3386..a64b9ec23c 100644
> --- a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
> +++ b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
> @@ -20,7 +20,7 @@
>   * delegated events and request the Secure partition manager to perform
>   * privileged operations on its behalf.
>   */
> -#define ARM_SVC_ID_SPM_VERSION_AARCH64 0xC460
> +#define ARM_SVC_ID_SPM_VERSION_AARCH32 0x8460
>  #define ARM_SVC_ID_SP_EVENT_COMPLETE_AARCH64   0xC461
>  #define ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64   0xC464
>  #define ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64   0xC465
> @@ -40,4 +40,11 @@
>  c_perm) & SET_MEM_ATTR_CODE_PERM_MASK) << 
> SET_MEM_ATTR_CODE_PERM_SHIFT) | \
>  (( (d_perm) & SET_MEM_ATTR_DATA_PERM_MASK) << 
> SET_MEM_ATTR_DATA_PERM_SHIFT))
>  
> +/* MM SVC Return error codes */
> +#define ARM_SVC_SPM_RET_SUCCESS   0
> +#define ARM_SVC_SPM_RET_NOT_SUPPORTED-1
> +#define ARM_SVC_SPM_RET_INVALID_PARAMS   -2
> +#define ARM_SVC_SPM_RET_DENIED   -3
> +#define ARM_SVC_SPM_RET_NO_MEMORY-5
> +
>  #endif
> -- 
> 2.16.2
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 02/18] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.

[Achin Gupta]

Hi Supreeth,

CIL.

On Fri, Apr 06, 2018 at 03:42:07PM +0100, Supreeth Venkatesh wrote:
> PI v1.5 Specification Volume 4 defines Management Mode Core Interface
> and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
> means of communicating between drivers outside of MM and MMI
> handlers inside of MM.
> 
> This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE runtime
> driver for AARCH64 platforms. It uses SMCs allocated from the standard
> SMC range defined in DEN0060A_ARM_MM_Interface_Specification.pdf
> to communicate with the standalone MM environment in the secure world.
> 
> This patch also adds the MM Communication driver (.inf) file to
> define entry point for this driver and other compile
> related information the driver needs.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  .../Drivers/MmCommunicationDxe/MmCommunication.c   | 339 
> +
>  .../Drivers/MmCommunicationDxe/MmCommunication.inf |  50 +++
>  2 files changed, 389 insertions(+)
>  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
>  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> 
> diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c 
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> new file mode 100644
> index 00..e801c1c601
> --- /dev/null
> +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> @@ -0,0 +1,339 @@
> +/** @file
> +
> +  Copyright (c) 2016-2017, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +//
> +// Address, Length of the pre-allocated buffer for communication with the 
> secure
> +// world.
> +//
> +STATIC ARM_MEMORY_REGION_DESCRIPTOR  mNsCommBuffMemRegion;
> +
> +// Notification event when virtual address map is set.
> +STATIC EFI_EVENT  mSetVirtualAddressMapEvent;
> +
> +//
> +// Handle to install the MM Communication Protocol
> +//
> +STATIC EFI_HANDLE  mMmCommunicateHandle;
> +
> +/**
> +  Communicates with a registered handler.
> +
> +  This function provides an interface to send and receive messages to the
> +  Standalone MM environment on behalf of UEFI services.  This function is 
> part
> +  of the MM Communication Protocol that may be called in physical mode prior 
> to
> +  SetVirtualAddressMap() and in virtual mode after SetVirtualAddressMap().
> +
> +  @param[in]  ThisThe EFI_MM_COMMUNICATION_PROTOCOL
> +  instance.
> +  @param[in, out] CommBuffer  A pointer to the buffer to convey
> +  into MMRAM.
> +  @param[in, out] CommSizeThe size of the data buffer being
> +  passed in. This is optional.
> +
> +  @retval EFI_SUCCESS The message was successfully posted.
> +  @retval EFI_INVALID_PARAMETER   The CommBuffer was NULL.
> +  @retval EFI_BAD_BUFFER_SIZE The buffer size is incorrect for the MM
> +  implementation. If this error is
> +  returned, the MessageLength field in
> +  the CommBuffer header or the integer
> +  pointed by CommSize are updated to 
> reflect
> +  the maximum payload size the
> +  implementation can accommodate.
> +  @retval EFI_ACCESS_DENIED   The CommunicateBuffer parameter
> +  or CommSize parameter, if not omitted,
> +  are in address range that cannot be
> +  accessed by the MM environment
> +**/
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +MmCommunicationCommunicate (
> +  IN CONST EFI_MM_COMMUNICATION_PROTOCOL  *This,
> +  IN OUT VOID *Com

[edk2] [edk2 PATCH v2 1/1] Maintainers.txt: Add StandaloneMmPkg and maintainers

[achin . gupta]

From: Achin Gupta <achin.gu...@arm.com>

This patch adds maintainers, reviewer and directory for the
StandaloneMmPkg. This package will host an implementation of Standalone
Management Mode as specified in the Platform Initialization (PI)
Specification, Volume 4: Management Mode Core Interface.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta <achin.gu...@arm.com>
---
 Maintainers.txt | 5 +
 StandaloneMmPkg | 0
 2 files changed, 5 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 74f2538..be5d527 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -259,3 +259,8 @@ M: Mang Guo <mang@intel.com>
 Vlv2TbltDevicePkg
 M: David Wei <david@intel.com>
 M: Mang Guo <mang@intel.com>
+
+StandaloneMmPkg
+M: Achin Gupta <achin.gu...@arm.com>
+M: Jiewen Yao <jiewen@intel.com>
+R: Supreeth Venkatesh <supreeth.venkat...@arm.com>
diff --git a/StandaloneMmPkg b/StandaloneMmPkg
new file mode 100644
index 000..e69de29
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2 PATCH v2 0/1] *** Add StandaloneMmPkg and maintainers ***

[achin . gupta]

From: Achin Gupta <achin.gu...@arm.com>

PI Specification v1.5 "Volume 4: Management Mode Core Interface"
introduces the concept of MM Standalone Mode. The StandaloneMmPkg will
host an implementation of this feature.

Development of this package was done in edk2-staging [1]. Support for MM
in Standalone Mode was originally contributed by Yao Jiewen. Subsequent
development for AArch64 was done by Achin Gupta and Supreeth
Venkatesh. The outcome of this work has been posted for review here
[2]. The patches are also hosted here [3].

This patch adds an empty StandaloneMmPkg directory under which these
patches will be hosted. It also nominates the maintainers and reviewers
for this package.

[1] https://github.com/tianocore/edk2-staging/tree/AArch64StandaloneMm
[2] https://lists.01.org/pipermail/edk2-devel/2017-November/017674.html
[3] https://github.com/supven01/edk2/tree/AArch64StandaloneMm

Achin Gupta (1):
  Maintainers.txt: Add StandaloneMmPkg and maintainers

 Maintainers.txt | 5 +
 StandaloneMmPkg | 0
 2 files changed, 5 insertions(+)
 create mode 100644 StandaloneMmPkg

-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2 PATCH v1 1/1] Maintainers.txt: Add StandaloneMmPkg and maintainers

[achin . gupta]

From: Achin Gupta <achin.gu...@arm.com>

This patch adds maintainers, reviewer and directory for the
StandaloneMmPkg. This package will host an implementation of Standalone
Management Mode as specified in the Platform Initialization (PI) Specification,
Volume 4: Management Mode Core Interface.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta <achin.gu...@arm.com>
---
 Maintainers.txt | 5 +
 StandaloneMmPkg | 0
 2 files changed, 5 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 74f2538..be5d527 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -259,3 +259,8 @@ M: Mang Guo <mang@intel.com>
 Vlv2TbltDevicePkg
 M: David Wei <david@intel.com>
 M: Mang Guo <mang@intel.com>
+
+StandaloneMmPkg
+M: Achin Gupta <achin.gu...@arm.com>
+M: Jiewen Yao <jiewen@intel.com>
+R: Supreeth Venkatesh <supreeth.venkat...@arm.com>
diff --git a/StandaloneMmPkg b/StandaloneMmPkg
new file mode 100644
index 000..e69de29
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2 PATCH v1 0/1] *** Add StandaloneMmPkg and maintainers ***

[achin . gupta]

From: Achin Gupta <achin.gu...@arm.com>

PI Specification v1.5 "Volume 4: Management Mode Core Interface" introduces the
concept of MM Standalone Mode. The StandaloneMmPkg will host an implementation
of this feature.

Development of this package was done in edk2-staging [1]. Support for MM in
Standalone Mode was originally contributed by Yao Jiewen. Subsequent development
for AArch64 was done by Achin Gupta and Supreeth Venkatesh. The outcome of this
work has been posted for review here [2]. The patches are also hosted here [3].

This patch adds an empty StandaloneMmPkg directory under which these patches
will be hosted. It also nominates the maintainers and reviewers for this
package.

[1] https://github.com/tianocore/edk2-staging/tree/AArch64StandaloneMm
[2] https://lists.01.org/pipermail/edk2-devel/2017-November/017674.html
[3] https://github.com/supven01/edk2/tree/AArch64StandaloneMm

Achin Gupta (1):
  Maintainers.txt: Add StandaloneMmPkg and maintainers

 Maintainers.txt | 5 +
 StandaloneMmPkg | 0
 2 files changed, 5 insertions(+)
 create mode 100644 StandaloneMmPkg

-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Creation of StandaloneMmPkg

[Achin Gupta]

Hi All,

SOme of you might be aware that me and Supreeth have been working on adding
support for Standalone MM on AArch64. The work is based on Jiewen's patches for
x86 and was being tracked in this edk2-staging branch [1]. This work looked good
enough to post on edk2-devel late last year and Supreeth's been doing just that
here [2].

These patches will need a new package (StandaloneMmPkg) to reside under. Me and
Yao Jiewen will be the maintainers.

Could you please let me know your concerns and what needs to be done to achieve
this? Also, please let me know if I have missed any stakeholder in this
thread.

Cheers!
Achin

[1] https://github.com/tianocore/edk2-staging/tree/AArch64StandaloneMm
[2] https://lists.01.org/pipermail/edk2-devel/2017-December/018504.html
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/3] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.

[Achin Gupta]

Hi Supreeth,

some CIL,

On Wed, Oct 25, 2017 at 05:32:57PM +0100, Supreeth Venkatesh wrote:
> PI v1.5 Specification Volume 4 defines Management Mode Core Interface
> and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
> means of communicating between drivers outside of MM and MMI
> handlers inside of MM.
>
> This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE runtime
> driver for AARCH64 platforms. It uses SMCs allocated from the standard
> SMC range defined in
> http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf
> to communicate with the standalone MM environment in the secure world.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  .../Drivers/MmCommunicationDxe/MmCommunication.c   | 339 
> +
>  1 file changed, 339 insertions(+)
>  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
>
> diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c 
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> new file mode 100644
> index 00..ecf70e666c
> --- /dev/null
> +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> @@ -0,0 +1,339 @@
> +/** @file
> +
> +  Copyright (c) 2016-2017, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +/**
> +  Communicates with a registered handler.
> +
> +  This function provides an interface to send and receive messages to the
> +  Standalone MM environment on behalf of UEFI services.  This function is 
> part
> +  of the MM Communication Protocol that may be called in physical mode prior 
> to
> +  SetVirtualAddressMap() and in virtual mode after SetVirtualAddressMap().
> +
> +  @param[in]  ThisThe EFI_MM_COMMUNICATION_PROTOCOL 
> instance.
> +  @param[in, out] CommBuffer  A pointer to the buffer to convey into 
> MMRAM.
> +  @param[in, out] CommSizeThe size of the data buffer being 
> passed in.On exit, the size of data
> +  being returned. Zero if the handler 
> does not wish to reply with any data.
> +
> +  @retval EFI_SUCCESS The message was successfully posted.
> +  @retval EFI_INVALID_PARAMETER   The CommBuffer was NULL.
> +  @retval EFI_BAD_BUFFER_SIZE The buffer is too large for the MM 
> implementation. If this error is
> +  returned, the MessageLength field in 
> the CommBuffer header or the integer
> +  pointed by CommSize are updated to 
> reflect the maximum payload size the
> +  implementation can accommodate.
> +  @retval EFI_ACCESS_DENIED   The CommunicateBuffer parameter or 
> CommSize parameter, if not omitted,
> +  are in address range that cannot be 
> accessed by the MM environment
> +**/
> +EFI_STATUS
> +EFIAPI
> +MmCommunicationCommunicate (
> +  IN CONST EFI_MM_COMMUNICATION_PROTOCOL  *This,
> +  IN OUT VOID *CommBuffer,
> +  IN OUT UINTN*CommSizeOPTIONAL
> +  );
> +
> +//
> +// Address, Length of the pre-allocated buffer for communication with the 
> secure
> +// world.
> +//
> +STATIC ARM_MEMORY_REGION_DESCRIPTOR  mNsCommBuffMemRegion;
> +
> +// Notification event when virtual address map is set.
> +STATIC EFI_EVENT  mSetVirtualAddressMapEvent;
> +
> +//
> +// Handle to install the MM Communication Protocol
> +//
> +STATIC EFI_HANDLE  mMmCommunicateHandle;
> +
> +//
> +// MM Communication Protocol instance
> +//
> +EFI_MM_COMMUNICATION_PROTOCOL  mMmCommunication = {
> +  MmCommunicationCommunicate
> +};
> +
> +/**
> +  Communicates with a registered handler.
> +
> +  This function provides an interface to send and receive messages to the
> +  Standalone MM environment on behalf o

Re: [edk2] [PATCH v1 0/3] *** EFI_MM_COMMUNICATION_PROTOCOL ***

[Achin Gupta]

On Thu, Oct 12, 2017 at 12:43:13PM -0500, Supreeth Venkatesh wrote:
> On Thu, 2017-10-12 at 18:38 +0100, Achin Gupta wrote:
> > Hi Supreeth,
> >
> > Could you acknowledge me as a contributor in the relevant patches and
> > repost?
> Can sure do as done in previous patches. However, Since I wanted you to
> review as well the latest changes, I was not sure whether co-author can
> be reviewer as well. I can add you as co-author in the next patchset,
> if that is what you prefer.

Yes I would prefer that!

Thanks!
Achin

>   
> >
> > cheers,
> > Achin
> >
> > On Thu, Oct 12, 2017 at 06:13:49PM +0100, Supreeth Venkatesh wrote:
> > >
> > > ***
> > > PI v1.5 Specification Volume 4 defines Management Mode Core
> > > Interface
> > > and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
> > > means of communicating between drivers outside of MM and MMI
> > > handlers inside of MM.
> > >
> > > EFI_MM_COMMUNICATION_PROTOCOL
> > > Summary
> > >   This protocol provides a means of communicating between drivers
> > > outside of MM and MMI
> > >   handlers inside of MM.
> > >
> > > GUID
> > >   #define EFI_MM_COMMUNICATION_PROTOCOL_GUID \
> > >   { 0xc68ed8e2, 0x9dc6, 0x4cbd, 0x9d, 0x94, 0xdb, 0x65, 0xac, 0xc5,
> > > 0xc3, 0x32 }
> > >
> > > Prototype
> > >   typedef struct _EFI_MM_COMMUNICATION_PROTOCOL {
> > >   EFI_MM_COMMUNICATE Communicate;
> > >   } EFI_MM_COMMUNICATION_PROTOCOL;
> > >
> > > Members
> > > Communicate
> > >   Sends/receives a message for a registered handler. See the
> > > Communicate()
> > >   function description.
> > >
> > > Description
> > >   This protocol provides runtime services for communicating between
> > > DXE drivers and a registered
> > >   MMI handler.
> > >
> > > EFI_MM_COMMUNICATION_PROTOCOL.Communicate()
> > > Summary
> > >   Communicates with a registered handler.
> > >
> > > Prototype
> > >   typedef
> > >   EFI_STATUS
> > >   (EFIAPI *EFI_MM_COMMUNICATE) (
> > >   IN CONST EFI_MM_COMMUNICATION_PROTOCOL *This,
> > >   IN OUT VOID *CommBuffer,
> > >   IN OUT UINTN *CommSize OPTIONAL
> > >   );
> > >
> > > Parameters
> > >   This - The EFI_MM_COMMUNICATION_PROTOCOL instance.
> > >   CommBuffer - Pointer to the buffer to convey into MMRAM.
> > >   CommSize - The size of the data buffer being passed in. On exit,
> > > the size of data being returned.
> > >  Zero if the handler does not wish to reply
> > > with any data. This parameter is optional
> > >  and may be NULL.
> > >
> > > Description
> > >   This function provides a service to send and receive messages
> > > from a registered UEFI service. The EFI_MM_COMMUNICATION_PROTOCOL
> > > driver is responsible for doing any of the
> > >   copies such that the data lives in boot-service-accessible RAM.
> > >   A given implementation of the EFI_MM_COMMUNICATION_PROTOCOL may
> > > choose to use the EFI_MM_CONTROL_PROTOCOL for effecting the mode
> > > transition, or it may use some other method.
> > >   The agent invoking the communication interface at runtime may be
> > > virtually mapped. The MM infrastructure code and handlers, on the
> > > other hand, execute in physical mode. As a result, the non-MM
> > > agent,
> > >   which may be executing in the virtual-mode OS context (as a
> > > result of an OS invocation of the UEFI SetVirtualAddressMap()
> > > service), should use a contiguous memory buffer with a physical
> > > address before
> > >   invoking this service. If the virtual address of the buffer is
> > > used, the MM Driver may not know how to do the appropriate virtual-
> > > to-physical conversion.
> > >   To avoid confusion in interpreting frames, the CommunicateBuffer
> > > parameter should always begin with EFI_MM_COMMUNICATE_HEADER, which
> > > is defined in Related Definitions below.
> > >   The header data is mandatory for messages sent into the MM agent.
> > >   If the CommSize parameter is omitted the MessageLength field in
> > > the EFI_MM_COMMUNICATE_HEADER,
> > >   in conjunction with the size of the header itself, can be used to
> > > ascertain the total size of the communication payload.
> > >   If the MessageLength is zero, o

Re: [edk2] [PATCH v1 0/3] *** EFI_MM_COMMUNICATION_PROTOCOL ***

[Achin Gupta]

Hi Supreeth,

Could you acknowledge me as a contributor in the relevant patches and repost?

cheers,
Achin

On Thu, Oct 12, 2017 at 06:13:49PM +0100, Supreeth Venkatesh wrote:
> ***
> PI v1.5 Specification Volume 4 defines Management Mode Core Interface
> and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
> means of communicating between drivers outside of MM and MMI
> handlers inside of MM.
>
> EFI_MM_COMMUNICATION_PROTOCOL
> Summary
>   This protocol provides a means of communicating between drivers outside of 
> MM and MMI
>   handlers inside of MM.
>
> GUID
>   #define EFI_MM_COMMUNICATION_PROTOCOL_GUID \
>   { 0xc68ed8e2, 0x9dc6, 0x4cbd, 0x9d, 0x94, 0xdb, 0x65, 0xac, 0xc5, 0xc3, 
> 0x32 }
>
> Prototype
>   typedef struct _EFI_MM_COMMUNICATION_PROTOCOL {
>   EFI_MM_COMMUNICATE Communicate;
>   } EFI_MM_COMMUNICATION_PROTOCOL;
>
> Members
> Communicate
>   Sends/receives a message for a registered handler. See the Communicate()
>   function description.
>
> Description
>   This protocol provides runtime services for communicating between DXE 
> drivers and a registered
>   MMI handler.
>
> EFI_MM_COMMUNICATION_PROTOCOL.Communicate()
> Summary
>   Communicates with a registered handler.
>
> Prototype
>   typedef
>   EFI_STATUS
>   (EFIAPI *EFI_MM_COMMUNICATE) (
>   IN CONST EFI_MM_COMMUNICATION_PROTOCOL *This,
>   IN OUT VOID *CommBuffer,
>   IN OUT UINTN *CommSize OPTIONAL
>   );
>
> Parameters
>   This - The EFI_MM_COMMUNICATION_PROTOCOL instance.
>   CommBuffer - Pointer to the buffer to convey into MMRAM.
>   CommSize - The size of the data buffer being passed in. On exit, the size 
> of data being returned.
>  Zero if the handler does not wish to reply with any 
> data. This parameter is optional
>  and may be NULL.
>
> Description
>   This function provides a service to send and receive messages from a 
> registered UEFI service. The EFI_MM_COMMUNICATION_PROTOCOL driver is 
> responsible for doing any of the
>   copies such that the data lives in boot-service-accessible RAM.
>   A given implementation of the EFI_MM_COMMUNICATION_PROTOCOL may choose to 
> use the EFI_MM_CONTROL_PROTOCOL for effecting the mode transition, or it may 
> use some other method.
>   The agent invoking the communication interface at runtime may be virtually 
> mapped. The MM infrastructure code and handlers, on the other hand, execute 
> in physical mode. As a result, the non-MM agent,
>   which may be executing in the virtual-mode OS context (as a result of an OS 
> invocation of the UEFI SetVirtualAddressMap() service), should use a 
> contiguous memory buffer with a physical address before
>   invoking this service. If the virtual address of the buffer is used, the MM 
> Driver may not know how to do the appropriate virtual-to-physical conversion.
>   To avoid confusion in interpreting frames, the CommunicateBuffer parameter 
> should always begin with EFI_MM_COMMUNICATE_HEADER, which is defined in 
> Related Definitions below.
>   The header data is mandatory for messages sent into the MM agent.
>   If the CommSize parameter is omitted the MessageLength field in the 
> EFI_MM_COMMUNICATE_HEADER,
>   in conjunction with the size of the header itself, can be used to ascertain 
> the total size of the communication payload.
>   If the MessageLength is zero, or too large for the MM implementation to 
> manage, the MM implementation must update the MessageLength to reflect the 
> size of the Data buffer that it can tolerate.
>   If the CommSize parameter is passed into the call, but the integer it 
> points to, has a value of 0, then this must be updated to reflect the maximum 
> size of the CommBuffer that the implementation can tolerate.
>   Once inside of MM, the MM infrastructure will call all registered handlers 
> with the same HandlerType as the GUID specified by HeaderGuid and the 
> CommBuffer pointing to Data.
>   This function is not reentrant.
>   The standard header is used at the beginning of the 
> EFI_MM_INITIALIATION_HEADER structure during MM initialization. See "Related 
> Definitions" below for more information.
>
> Related Definitions
>   typedef struct {
>   EFI_GUID HeaderGuid;
>   UINTN MessageLength;
>   UINT8 Data[ANYSIZE_ARRAY];
>   } EFI_MM_COMMUNICATE_HEADER;
>
>   HeaderGuid - Allows for disambiguation of the message format. Type EFI_GUID 
> is defined in
>InstallProtocolInterface() in the UEFI Specification.
>   MessageLength - Describes the size of Data (in bytes) and does not include 
> the size of the header.
>   Data - Designates an array of bytes that is MessageLength in size.
>
> Status Codes Returned
>   EFI_SUCCESS - The message was successfully posted.
>   EFI_INVALID_PARAMETER - The buffer was NULL.
>   EFI_BAD_BUFFER_SIZE - The buffer is too large for the MM implementation. If 
> this error is
>returned, the MessageLength field 
> in the CommBuffer
>  

Re: [edk2] [PATCH 1/1] ArmPkg/Include: Update MM interface return codes to match specification.

[Achin Gupta]

On Thu, Oct 12, 2017 at 01:30:43AM +0100, Supreeth Venkatesh wrote:
> This patch corrects the Management Mode(MM) return codes as specified in
> http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  ArmPkg/Include/IndustryStandard/ArmStdSmc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h 
> b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> index 37d0796649..2d2af9e37d 100644
> --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> @@ -56,7 +56,7 @@
>  #define ARM_SMC_MM_RET_NOT_SUPPORTED   -1
>  #define ARM_SMC_MM_RET_INVALID_PARAMS  -2
>  #define ARM_SMC_MM_RET_DENIED  -3
> -#define ARM_SMC_MM_RET_NO_MEMORY   -4
> +#define ARM_SMC_MM_RET_NO_MEMORY   -5

Looks good to me.

Thanks!
Achin

>
>  /*
>   * Power State Coordination Interface (PSCI) calls cover a subset of the
> --
> 2.14.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 1/2] ArmPkg/Include: Add standard SMC function IDs for MM interface.

[Achin Gupta]

On Mon, Oct 09, 2017 at 04:15:27PM +0100, Supreeth Venkatesh wrote:
> I can do that.

Thanks!

> However, "-4" is missing in the specification. Is there a chance to rectify 
> specification to add "-4", so that I can do both the defines.

To indicate what error? Anyways, lets take this offline. For the time being, the
code should match the spec.

cheers,
Achin

>
> Thanks,
> Supreeth
> -Original Message-
> From: Achin Gupta
> Sent: Monday, October 9, 2017 3:52 AM
> To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Supreeth Venkatesh 
> <supreeth.venkat...@arm.com>
> Cc: Supreeth Venkatesh <supreeth.venkat...@arm.com>; edk2-devel@lists.01.org; 
> Leif Lindholm <leif.lindh...@linaro.org>; nd <n...@arm.com>
> Subject: Re: [PATCH v2 1/2] ArmPkg/Include: Add standard SMC function IDs for 
> MM interface.
>
> Hi Ard/Supreeth,
>
> On Fri, Oct 06, 2017 at 10:05:46PM +0100, Ard Biesheuvel wrote:
> > On 27 September 2017 at 19:58, Supreeth Venkatesh
> > <supreeth.venkat...@arm.com> wrote:
> > > This patch adds a list of function IDs that fall under the standard
> > > SMC range as defined in
> > > http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf.
> > >
> > > SMCs associated with Management Mode are in the range 0xC440 -
> > > 0xC45f (64 bit) and 0x8440 - 0x845f (32 bit).
> > >
> > > The function(s) available to the normal world:
> > > 1. Request services from the secure MM environment using MM_COMMUNICATE.
> > >
> > > It also defines MM return codes.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> > > Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> >
> > Both patches applied. Thanks.
>
> I should have spotted this earlier but the following define is not spec. 
> compliant. It says:
>
> > +#define ARM_SMC_MM_RET_NO_MEMORY   -4
>
> but should be
>
> > +#define ARM_SMC_MM_RET_NO_MEMORY   -5
>
> Supreeth. Could you please submit a patch to rectify this?
>
> cheers,
> Achin
>
> >
> > > ---
> > >  ArmPkg/Include/IndustryStandard/ArmStdSmc.h | 20
> > > +++-
> > >  1 file changed, 19 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > > b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > > index 593a3ce729..37d0796649 100644
> > > --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > > +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > > @@ -1,6 +1,6 @@
> > >  /** @file
> > >  *
> > > -*  Copyright (c) 2012-2014, ARM Limited. All rights reserved.
> > > +*  Copyright (c) 2012-2017, ARM Limited. All rights reserved.
> > >  *
> > >  *  This program and the accompanying materials
> > >  *  are licensed and made available under the terms and conditions
> > > of the BSD License @@ -40,6 +40,24 @@
> > >  #define ARM_SMC_STD_REVISION_MAJOR0x0
> > >  #define ARM_SMC_STD_REVISION_MINOR0x1
> > >
> > > +/*
> > > + * Management Mode (MM) calls cover a subset of the Standard Service 
> > > Call range.
> > > + * The list below is not exhaustive.
> > > + */
> > > +#define ARM_SMC_ID_MM_VERSION_AARCH32  0x8440
> > > +#define ARM_SMC_ID_MM_VERSION_AARCH64  0xC440
> > > +
> > > +// Request service from secure standalone MM environment
> > > +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH32  0x8441
> > > +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH64  0xC441
> > > +
> > > +/* MM return error codes */
> > > +#define ARM_SMC_MM_RET_SUCCESS  0
> > > +#define ARM_SMC_MM_RET_NOT_SUPPORTED   -1
> > > +#define ARM_SMC_MM_RET_INVALID_PARAMS  -2
> > > +#define ARM_SMC_MM_RET_DENIED  -3
> > > +#define ARM_SMC_MM_RET_NO_MEMORY   -4
> > > +
> > >  /*
> > >   * Power State Coordination Interface (PSCI) calls cover a subset of the
> > >   * Standard Service Call range.
> > > --
> > > 2.14.1
> > >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 1/2] ArmPkg/Include: Add standard SMC function IDs for MM interface.

[Achin Gupta]

Hi Ard/Supreeth,

On Fri, Oct 06, 2017 at 10:05:46PM +0100, Ard Biesheuvel wrote:
> On 27 September 2017 at 19:58, Supreeth Venkatesh
> <supreeth.venkat...@arm.com> wrote:
> > This patch adds a list of function IDs that fall under the standard
> > SMC range as defined in
> > http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf.
> >
> > SMCs associated with Management Mode are in the range 0xC440 -
> > 0xC45f (64 bit) and 0x8440 - 0x845f (32 bit).
> >
> > The function(s) available to the normal world:
> > 1. Request services from the secure MM environment using MM_COMMUNICATE.
> >
> > It also defines MM return codes.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> > Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
>
> Both patches applied. Thanks.

I should have spotted this earlier but the following define is not
spec. compliant. It says:

> +#define ARM_SMC_MM_RET_NO_MEMORY   -4

but should be

> +#define ARM_SMC_MM_RET_NO_MEMORY   -5

Supreeth. Could you please submit a patch to rectify this?

cheers,
Achin

>
> > ---
> >  ArmPkg/Include/IndustryStandard/ArmStdSmc.h | 20 +++-
> >  1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h 
> > b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > index 593a3ce729..37d0796649 100644
> > --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > @@ -1,6 +1,6 @@
> >  /** @file
> >  *
> > -*  Copyright (c) 2012-2014, ARM Limited. All rights reserved.
> > +*  Copyright (c) 2012-2017, ARM Limited. All rights reserved.
> >  *
> >  *  This program and the accompanying materials
> >  *  are licensed and made available under the terms and conditions of the 
> > BSD License
> > @@ -40,6 +40,24 @@
> >  #define ARM_SMC_STD_REVISION_MAJOR0x0
> >  #define ARM_SMC_STD_REVISION_MINOR0x1
> >
> > +/*
> > + * Management Mode (MM) calls cover a subset of the Standard Service Call 
> > range.
> > + * The list below is not exhaustive.
> > + */
> > +#define ARM_SMC_ID_MM_VERSION_AARCH32  0x8440
> > +#define ARM_SMC_ID_MM_VERSION_AARCH64  0xC440
> > +
> > +// Request service from secure standalone MM environment
> > +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH32  0x8441
> > +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH64  0xC441
> > +
> > +/* MM return error codes */
> > +#define ARM_SMC_MM_RET_SUCCESS  0
> > +#define ARM_SMC_MM_RET_NOT_SUPPORTED   -1
> > +#define ARM_SMC_MM_RET_INVALID_PARAMS  -2
> > +#define ARM_SMC_MM_RET_DENIED  -3
> > +#define ARM_SMC_MM_RET_NO_MEMORY   -4
> > +
> >  /*
> >   * Power State Coordination Interface (PSCI) calls cover a subset of the
> >   * Standard Service Call range.
> > --
> > 2.14.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/1] ArmPkg/Include: Add standard SMC and SVC function IDs for MM interface.

[Achin Gupta]

Hi Supreeth,

On Fri, Sep 22, 2017 at 08:25:39PM +0100, Supreeth Venkatesh wrote:
> This patch adds a list of function IDs that fall under the standard
> SMC range as defined in
> http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf.
>
> SMCs associated with Management Mode are in the range 0xC440 -
> 0xC45f (64 bit) and 0x8440 - 0x845f (32 bit).
>
> The function(s) available to the normal world:
> 1. Request services from the secure MM environment using MM_COMMUNICATE.
>
> SVCs are in the range 0xC460 - 0xC47f.
> The functions available to the secure MM partition:
> 1. Signal completion of MM event handling.
> 2. Set/Get memory attributes for a memory region at runtime.
> 3. Get version number of secure partition manager.
>
> Also, it defines memory attributes and MM return codes.

The SVCs in the 0xC460 - 0xC47f range are not a part of the MM interface
specification. At the moment, these are used to implement an interface between
ARM TF in EL3 and S-EL0. These should go into a separate patch that introduces
them as an ARM TF ABI.

cheers,
Achin

>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkat...@arm.com>
> ---
>  ArmPkg/Include/IndustryStandard/ArmStdSmc.h | 46 
> -
>  1 file changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h 
> b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> index 593a3ce729..a625bc2048 100644
> --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> @@ -1,6 +1,6 @@
>  /** @file
>  *
> -*  Copyright (c) 2012-2014, ARM Limited. All rights reserved.
> +*  Copyright (c) 2012-2017, ARM Limited. All rights reserved.
>  *
>  *  This program and the accompanying materials
>  *  are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -40,6 +40,50 @@
>  #define ARM_SMC_STD_REVISION_MAJOR0x0
>  #define ARM_SMC_STD_REVISION_MINOR0x1
>
> +
> +/*
> + * Management Mode (MM) calls cover a subset of the Standard Service Call 
> range.
> + * The list below is not exhaustive.
> + */
> +#define ARM_SMC_ID_MM_VERSION_AARCH32  0x8440
> +#define ARM_SMC_ID_MM_VERSION_AARCH64  0xC440
> +
> +// Request service from secure standalone MM environment
> +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH32  0x8441
> +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH64  0xC441
> +
> +/*
> + * SVC IDs to allow the MM secure partition to initialise itself, handle
> + * delegated events and request the Secure partition manager to perform
> + * privileged operations on its behalf.
> + */
> +#define ARM_SVC_ID_SPM_VERSION_AARCH64 0xC460
> +#define ARM_SVC_ID_SP_EVENT_COMPLETE_AARCH64   0xC461
> +#define ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64   0xC464
> +#define ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64   0xC465
> +
> +#define SET_MEM_ATTR_DATA_PERM_MASK   0x3
> +#define SET_MEM_ATTR_DATA_PERM_SHIFT0
> +#define SET_MEM_ATTR_DATA_PERM_NO_ACCESS0
> +#define SET_MEM_ATTR_DATA_PERM_RW   1
> +#define SET_MEM_ATTR_DATA_PERM_RO   3
> +
> +#define SET_MEM_ATTR_CODE_PERM_MASK   0x1
> +#define SET_MEM_ATTR_CODE_PERM_SHIFT2
> +#define SET_MEM_ATTR_CODE_PERM_X0
> +#define SET_MEM_ATTR_CODE_PERM_XN   1
> +
> +#define SET_MEM_ATTR_MAKE_PERM_REQUEST(d_perm, c_perm)   
>  \
> +c_perm) & SET_MEM_ATTR_CODE_PERM_MASK) << 
> SET_MEM_ATTR_CODE_PERM_SHIFT) | \
> +(( (d_perm) & SET_MEM_ATTR_DATA_PERM_MASK) << 
> SET_MEM_ATTR_DATA_PERM_SHIFT))
> +
> +/* MM return error codes */
> +#define ARM_SMC_MM_RET_SUCCESS  0
> +#define ARM_SMC_MM_RET_NOT_SUPPORTED   -1
> +#define ARM_SMC_MM_RET_INVALID_PARAMS  -2
> +#define ARM_SMC_MM_RET_DENIED  -3
> +#define ARM_SMC_MM_RET_NO_MEMORY   -4
> +
>  /*
>   * Power State Coordination Interface (PSCI) calls cover a subset of the
>   * Standard Service Call range.
> --
> 2.14.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [staging/apei]: New branch request for APEI work

[Achin Gupta]

Hi All,

I would like to create a branch for implementing support for APEI in EDK2. The
intent is to upstream modules that are capable of creating the HEST, BERT, ERST
and EINJ after gathering error and error source information from the platform
and other sources. The work is still very nascent and the branch will be first
populated with some workarounds. These will be used as the basis for further
development.

Could you please do the needful. The attached readme has been populated with
some basic information.

cheers,
Achin
This branch will be used to develop support for ACPI Platform Error Interfaces
(APEI) on ARMv8-A standard platforms.

The branch owners: Achin Gupta <achin.gu...@arm.com>, James Morse 
<james.mo...@arm.com>

# Feature Introduction
The ACPI specification describes APEI which provide a mechanism for the firmware
to convey error information to OSPM. This branch will be used to implement
support for these interfaces in EDK2 and test them on ARM platforms.

# Aims
Upstream support for APEI to EDK2

# Related Modules
* MdeModulePkg
* ArmPkg
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

[Achin Gupta]

Hi gengdongjiu,

On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote:
>
> Hi Laszlo/Biesheuvel/Qemu developer,
>
>Now I encounter a issue and want to consult with you in ARM64 platform， as 
> described below:
>
>when guest OS happen synchronous or asynchronous abort, kvm needs to send 
> the error address to Qemu or UEFI through sigbus to dynamically generate APEI 
> table. from my investigation, there are two ways:
>
>(1) Qemu get the error address, and generate the APEI table, then notify 
> UEFI to know this generation, then inject abort error to guest OS, guest OS 
> read the APEI table.
>(2) Qemu get the error address, and let UEFI to generate the APEI table, 
> then inject abort error to guest OS, guest OS read the APEI table.

Just being pedantic! I don't think we are talking about creating the APEI table
dynamically here. The issue is: Once KVM has received an error that is destined
for a guest it will raise a SIGBUS to Qemu. Now before Qemu can inject the error
into the guest OS, a CPER (Common Platform Error Record) has to be generated
corresponding to the error source (GHES corresponding to memory subsystem,
processor etc) to allow the guest OS to do anything meaningful with the
error. So who should create the CPER is the question.

At the EL3/EL2 interface (Secure Firmware and OS/Hypervisor), an error arrives
at EL3 and secure firmware (at EL3 or a lower secure exception level) is
responsible for creating the CPER. ARM is experimenting with using a Standalone
MM EDK2 image in the secure world to do the CPER creation. This will avoid
adding the same code in ARM TF in EL3 (better for security). The error will then
be injected into the OS/Hypervisor (through SEA/SEI/SDEI) through ARM Trusted
Firmware.

Qemu is essentially fulfilling the role of secure firmware at the EL2/EL1
interface (as discussed with Christoffer below). So it should generate the CPER
before injecting the error.

This is corresponds to (1) above apart from notifying UEFI (I am assuming you
mean guest UEFI). At this time, the guest OS already knows where to pick up the
CPER from through the HEST. Qemu has to create the CPER and populate its address
at the address exported in the HEST. Guest UEFI should not be involved in this
flow. Its job was to create the HEST at boot and that has been done by this
stage.

Qemu folk will be able to add but it looks like support for CPER generation will
need to be added to Qemu. We need to resolve this.

Do shout if I am missing anything above.

cheers,
Achin


>
>
>Do you think which modules generates the APEI table is better? UEFI or 
> Qemu?
>
>
>
>
> On 2017/3/28 21:40, James Morse wrote:
> > Hi gengdongjiu,
> >
> > On 28/03/17 13:16, gengdongjiu wrote:
> >> On 2017/3/28 19:54, Achin Gupta wrote:
> >>> On Tue, Mar 28, 2017 at 01:23:28PM +0200, Christoffer Dall wrote:
> >>>> On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote:
> >>>>> On the host, part of UEFI is involved to generate the CPER records.
> >>>>> In a guest?, I don't know.
> >>>>> Qemu could generate the records, or drive some other component to do it.
> >>>>
> >>>> I think I am beginning to understand this a bit.  Since the guet UEFI
> >>>> instance is specifically built for the machine it runs on, QEMU's virt
> >>>> machine in this case, they could simply agree (by some contract) to
> >>>> place the records at some specific location in memory, and if the guest
> >>>> kernel asks its guest UEFI for that location, things should just work by
> >>>> having logic in QEMU to process error reports and populate guest memory.
> >>>>
> >>>> Is this how others see the world too?
> >>>
> >>> I think so!
> >>>
> >>> AFAIU, the memory where CPERs will reside should be specified in a GHES 
> >>> entry in
> >>> the HEST. Is this not the case with a guest kernel i.e. the guest UEFI 
> >>> creates a
> >>> HEST for the guest Kernel?
> >>>
> >>> If so, then the question is how the guest UEFI finds out where QEMU 
> >>> (acting as
> >>> EL3 firmware) will populate the CPERs. This could either be a contract 
> >>> between
> >>> the two or a guest DXE driver uses the MM_COMMUNICATE call (see [1]) to 
> >>> ask QEMU
> >>> where the memory is.
> >>
> >> whether invoke the guest UEFI will be complex? not see the advantage. it 
> >> seems x86 Qemu
> >> directly generate the ACPI table, but I am not sure, we are checking the 
> >> qemu
> > logical.
> >> let Qemu

Re: [edk2] [PATCH] ArmPlatformPkg/ArmVExpressPkg: Fix memory attributes for NOR Flash

[Achin Gupta]

Hi Ard,

On Thu, Jan 19, 2017 at 10:01:07PM +, Ard Biesheuvel wrote:
> On 19 January 2017 at 21:57, Achin Gupta <achin.gu...@arm.com> wrote:
> > Hi Ard,
> >
> > On Thu, Jan 19, 2017 at 06:16:00PM +, Ard Biesheuvel wrote:
> >> On 19 January 2017 at 12:31, Achin Gupta <achin.gu...@arm.com> wrote:
> >> > Hi Leif/Ard,
> >> >
> >> > On Wed, Jan 18, 2017 at 10:05:00PM +, Leif Lindholm wrote:
> >> >> Hi Achin,
> >> >>
> >> >> On Wed, Jan 18, 2017 at 08:24:06PM +, achin.gu...@arm.com wrote:
> >> >> > From: Achin Gupta <achin.gu...@arm.com>
> >> >> >
> >> >> > The NOR flash banks were being mapped in the translation tables with 
> >> >> > the same
> >> >> > memory attributes as RAM in the system. These attributes mark the 
> >> >> > region as
> >> >> > Normal Memory and could additionally be cacheable or non-cacheable.
> >> >> >
> >> >> > Either type of attributes are unsuitable for NOR Flash since write 
> >> >> > operations
> >> >> > could be performed on it. Normal Memory does not guarantee ordering of
> >> >> > transactions that Device memory does. So the commands sent to the 
> >> >> > Flash device
> >> >> > may not arrive in the right order unless barriers are used. Commands 
> >> >> > might not
> >> >> > get past the CPU caches in case the region has been mapped with 
> >> >> > cacheable
> >> >> > attributes.
> >> >> >
> >> >> > This patch fixes the problem by mapping the NOR Flash memory region 
> >> >> > with Device
> >> >> > memory attributes.
> >> >>
> >> >> To add some background to Ard's comment - this was not unintentionally
> >> >> done:
> >> >> https://github.com/tianocore/edk2/commit/19bb46c411279dcd30d540c56e5993c5f771c319
> >> >
> >> > Thanks! I missed this commit. There is some background to the problem I 
> >> > am
> >> > facing below.
> >> >
> >> >>
> >> >> Was the reasoning behind this commit incorrect - do you have a
> >> >> (pre-DXE?) use-case that creates a problem?
> >> >
> >> > AFAIU, The current memory attributes for NOR Flash work only for reads. 
> >> > They
> >> > should additionally be RO to flag any unexpected writes.
> >> >
> >> > Mine is a DXE use case! In NorFlashDxe.c, commands are send to the Flash 
> >> > (erase
> >> > block etc.). They might never reach the device if there is a write-back 
> >> > cache in
> >> > between. So either device or Normal memory with 
> >> > non-cacheable/write-through
> >> > attributes and barriers should work.
> >> >
> >> > If I turn on cache state modelling in the Base FVP, the code gets stuck 
> >> > in
> >> > NorFlashReadStatusRegister() in the below loop in 
> >> > NorFlashEraseSingleBlock():
> >> >
> >> >   // Wait until the status register gives us the all clear
> >> >   do {
> >> > StatusRegister = NorFlashReadStatusRegister (Instance, BlockAddress);
> >> >   } while ((StatusRegister & P30_SR_BIT_WRITE) != P30_SR_BIT_WRITE);
> >> >
> >> > I think the SEND_NOR_COMMANDs at the beginning of the function get stuck 
> >> > in the
> >> > cache. Changing the flash memory attributes as per this patch solves the
> >> > problem.
> >> >
> >> > The original patch from Ard mentions that the NOR Flash DXE driver 
> >> > should change
> >> > the attributes of the region it wants to write to. Is this what is 
> >> > missing?
> >> >
> >>
> >> NorFlashFvbInitialize() in
> >> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c contains the
> >> following calls:
> >>
> >>   Status = gDS->AddMemorySpace (
> >>   EfiGcdMemoryTypeMemoryMappedIo,
> >>   Instance->DeviceBaseAddress, RuntimeMmioRegionSize,
> >>   EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
> >>   );
> >>   ASSERT_EFI_ERROR (Status);
> >>
> >>   Status = gDS->SetMemorySpaceAttributes (
> >>   Instance->DeviceBaseAddress, RuntimeMmioRegionSize,
> >>

Re: [edk2] [PATCH] ArmPlatformPkg/ArmVExpressPkg: Fix memory attributes for NOR Flash

[Achin Gupta]

Hi Ard,

On Thu, Jan 19, 2017 at 06:16:00PM +, Ard Biesheuvel wrote:
> On 19 January 2017 at 12:31, Achin Gupta <achin.gu...@arm.com> wrote:
> > Hi Leif/Ard,
> >
> > On Wed, Jan 18, 2017 at 10:05:00PM +, Leif Lindholm wrote:
> >> Hi Achin,
> >>
> >> On Wed, Jan 18, 2017 at 08:24:06PM +0000, achin.gu...@arm.com wrote:
> >> > From: Achin Gupta <achin.gu...@arm.com>
> >> >
> >> > The NOR flash banks were being mapped in the translation tables with the 
> >> > same
> >> > memory attributes as RAM in the system. These attributes mark the region 
> >> > as
> >> > Normal Memory and could additionally be cacheable or non-cacheable.
> >> >
> >> > Either type of attributes are unsuitable for NOR Flash since write 
> >> > operations
> >> > could be performed on it. Normal Memory does not guarantee ordering of
> >> > transactions that Device memory does. So the commands sent to the Flash 
> >> > device
> >> > may not arrive in the right order unless barriers are used. Commands 
> >> > might not
> >> > get past the CPU caches in case the region has been mapped with cacheable
> >> > attributes.
> >> >
> >> > This patch fixes the problem by mapping the NOR Flash memory region with 
> >> > Device
> >> > memory attributes.
> >>
> >> To add some background to Ard's comment - this was not unintentionally
> >> done:
> >> https://github.com/tianocore/edk2/commit/19bb46c411279dcd30d540c56e5993c5f771c319
> >
> > Thanks! I missed this commit. There is some background to the problem I am
> > facing below.
> >
> >>
> >> Was the reasoning behind this commit incorrect - do you have a
> >> (pre-DXE?) use-case that creates a problem?
> >
> > AFAIU, The current memory attributes for NOR Flash work only for reads. They
> > should additionally be RO to flag any unexpected writes.
> >
> > Mine is a DXE use case! In NorFlashDxe.c, commands are send to the Flash 
> > (erase
> > block etc.). They might never reach the device if there is a write-back 
> > cache in
> > between. So either device or Normal memory with non-cacheable/write-through
> > attributes and barriers should work.
> >
> > If I turn on cache state modelling in the Base FVP, the code gets stuck in
> > NorFlashReadStatusRegister() in the below loop in 
> > NorFlashEraseSingleBlock():
> >
> >   // Wait until the status register gives us the all clear
> >   do {
> > StatusRegister = NorFlashReadStatusRegister (Instance, BlockAddress);
> >   } while ((StatusRegister & P30_SR_BIT_WRITE) != P30_SR_BIT_WRITE);
> >
> > I think the SEND_NOR_COMMANDs at the beginning of the function get stuck in 
> > the
> > cache. Changing the flash memory attributes as per this patch solves the
> > problem.
> >
> > The original patch from Ard mentions that the NOR Flash DXE driver should 
> > change
> > the attributes of the region it wants to write to. Is this what is missing?
> >
>
> NorFlashFvbInitialize() in
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c contains the
> following calls:
>
>   Status = gDS->AddMemorySpace (
>   EfiGcdMemoryTypeMemoryMappedIo,
>   Instance->DeviceBaseAddress, RuntimeMmioRegionSize,
>   EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
>   );
>   ASSERT_EFI_ERROR (Status);
>
>   Status = gDS->SetMemorySpaceAttributes (
>   Instance->DeviceBaseAddress, RuntimeMmioRegionSize,
>   EFI_MEMORY_UC | EFI_MEMORY_RUNTIME);
>   ASSERT_EFI_ERROR (Status);
>
> which is supposed to set device attributes on the NOR region that is
> actually exposed to the upper layers as read-write capable.
>
> Perhaps you can enable GCD debugging to trace these calls, to ensure
> that the address you are stalled on is actually covered?

Thanks for the pointer. Somehow NorFlashFvbInitialize() gets called and a valid
firmware volume header is not found. This irrespective of the state of cache
modelling. The function proceeds to install a header for which it first tries to
erase the Flash blocks reserved for variable storage.

I am not sure why a FV header is not found. However the flash erase in response
happens with the pre-DXE memory attributes for the flash region. The GCD
services to change the attributes are called later. So this seems like a logical
error in the code. Does this make sense to you? Here is the trace for
reference. The last print was added by me.

>>>>
add-symbol-file 
/home/achgup01/work/genfw

Re: [edk2] [PATCH] ArmPlatformPkg/ArmVExpressPkg: Fix memory attributes for NOR Flash

[Achin Gupta]

Hi Leif/Ard,

On Wed, Jan 18, 2017 at 10:05:00PM +, Leif Lindholm wrote:
> Hi Achin,
>
> On Wed, Jan 18, 2017 at 08:24:06PM +, achin.gu...@arm.com wrote:
> > From: Achin Gupta <achin.gu...@arm.com>
> >
> > The NOR flash banks were being mapped in the translation tables with the 
> > same
> > memory attributes as RAM in the system. These attributes mark the region as
> > Normal Memory and could additionally be cacheable or non-cacheable.
> >
> > Either type of attributes are unsuitable for NOR Flash since write 
> > operations
> > could be performed on it. Normal Memory does not guarantee ordering of
> > transactions that Device memory does. So the commands sent to the Flash 
> > device
> > may not arrive in the right order unless barriers are used. Commands might 
> > not
> > get past the CPU caches in case the region has been mapped with cacheable
> > attributes.
> >
> > This patch fixes the problem by mapping the NOR Flash memory region with 
> > Device
> > memory attributes.
>
> To add some background to Ard's comment - this was not unintentionally
> done:
> https://github.com/tianocore/edk2/commit/19bb46c411279dcd30d540c56e5993c5f771c319

Thanks! I missed this commit. There is some background to the problem I am
facing below.

>
> Was the reasoning behind this commit incorrect - do you have a
> (pre-DXE?) use-case that creates a problem?

AFAIU, The current memory attributes for NOR Flash work only for reads. They
should additionally be RO to flag any unexpected writes.

Mine is a DXE use case! In NorFlashDxe.c, commands are send to the Flash (erase
block etc.). They might never reach the device if there is a write-back cache in
between. So either device or Normal memory with non-cacheable/write-through
attributes and barriers should work.

If I turn on cache state modelling in the Base FVP, the code gets stuck in
NorFlashReadStatusRegister() in the below loop in NorFlashEraseSingleBlock():

  // Wait until the status register gives us the all clear
  do {
StatusRegister = NorFlashReadStatusRegister (Instance, BlockAddress);
  } while ((StatusRegister & P30_SR_BIT_WRITE) != P30_SR_BIT_WRITE);

I think the SEND_NOR_COMMANDs at the beginning of the function get stuck in the
cache. Changing the flash memory attributes as per this patch solves the
problem.

The original patch from Ard mentions that the NOR Flash DXE driver should change
the attributes of the region it wants to write to. Is this what is missing?

Please do let me know if I am missing any subtleties of the driver. I am not a
NOR flash expert :(

cheers,
Achin



>
> Regards,
>
> Leif
>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Achin Gupta <achin.gu...@arm.com>
> > ---
> >  ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git 
> > a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c 
> > b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> > index 14c7e8e..2685114 100644
> > --- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> > +++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> > @@ -116,7 +116,7 @@ ArmPlatformGetVirtualMemoryMap (
> >VirtualMemoryTable[++Index].PhysicalBase = ARM_VE_SMB_NOR0_BASE;
> >VirtualMemoryTable[Index].VirtualBase = ARM_VE_SMB_NOR0_BASE;
> >VirtualMemoryTable[Index].Length = ARM_VE_SMB_NOR0_SZ + 
> > ARM_VE_SMB_NOR1_SZ;
> > -  VirtualMemoryTable[Index].Attributes = CacheAttributes;
> > +  VirtualMemoryTable[Index].Attributes = 
> > ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> >
> >// SMB CS2 - SRAM
> >VirtualMemoryTable[++Index].PhysicalBase = ARM_VE_SMB_SRAM_BASE;
> > --
> > 1.9.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Relocation fixup during AARCH64 SEC PE-COFF generation?

[Achin Gupta]

On Tue, Sep 13, 2016 at 04:25:32PM +0100, Ard Biesheuvel wrote:
> On 13 September 2016 at 16:16, Achin Gupta <achin.gu...@arm.com> wrote:
> > On Tue, Sep 13, 2016 at 03:43:41PM +0100, Ard Biesheuvel wrote:
> >> On 13 September 2016 at 15:12, Ard Biesheuvel <ard.biesheu...@linaro.org> 
> >> wrote:
> >> > On 13 September 2016 at 15:03, Achin Gupta <achin.gu...@arm.com> wrote:
> >> >> Hi All,
> >> >>
> >> >> Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
> >> >> executes directly from within the firmware volume. The FV would 
> >> >> typically be
> >> >> loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC 
> >> >> file
> >> >> types converts a PE-COFF module into a stripped Terse executable as 
> >> >> follows:
> >> >>
> >> >> [Rule.AARCH64.SEC]
> >> >>   FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
> >> >> TE  TEAlign = Auto  $(INF_OUTPUT)/$(MODULE_NAME).efi
> >> >>   }
> >> >>
> >> >> The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" 
> >> >> option
> >> >> when the ELF image is generated. Since the SEC module is able to "XIP" 
> >> >> from the
> >> >> within FV, this means that the relocations have to be fixed up at link 
> >> >> time
> >> >> before the TE image is created.
> >> >>
> >> >
> >> > Correct. GenFv relocates the image based on the runtime address of the
> >> > firmware volume.
> >> >
> >> >> It seems to me that in GenFw.c, at least the static relocations are 
> >> >> fixed up
> >> >> when an ELF image is converted to PE-COFF. Can someone confirm if I am 
> >> >> correct
> >> >> in understanding that dynamic relocations will be left as is in the 
> >> >> PE-COFF
> >> >> image while static relocations will be fixed up?
> >> >>
> >> >
> >> > We usually don't emit dynamic relocations, since we are not linking
> >> > shared objects.
> >>
> >> ... or more specifically, all absolute static relocations are
> >> converted into PE/COFF base relocations, all relative static
> >> relocations are validated against the PE/COFF layout (which we keep
> >> 1:1 identical with the ELF section layout), and all dynamic
> >> relocations are ignored.
> >
> > Thanks Ard. I expect the relative static relocations to be fixed by the 
> > PE-COFF
> > loader at runtime.
> >
>
> No. The PE/COFF loader only processes base relocations, which are
> essentially pointers into the image where absolute addresses are
> stored, and which need to have an offset applied based on the
> difference between the link time base address and the load time base
> address. Like in ELF, no relative dynamic relocations exist.
>
> Only because of the ELF to PE/COFF conversion, we have to ensure that
> any relative references are still valid after the conversion.

Obviously I am not well versed with the correct terminology :(

I guess we are both talking about the base relocations done in
PeCoffLoaderRelocateImage() (MdePkg/Library/BasePeCoffLib/BasePeCoff.c) i.e. the
EFI_IMAGE_REL_BASED_* types defined in EfiImage.h?

>
> >> Note that this implies that proxy generating
> >> static relocations are rejected, since --emit-relocs does not produce
> >> any output for the proxies.
> >
> > You lost me here. What do you mean by "proxy generating static relocations"?
> >
>
> Basically, GOT based relocations that result in a GOT entry to be
> emitted when linking a shared object. Since those relocations are
> essentially instructions to the linker to emit such a GOT entry, the
> absolute relocation itself which causes the GOT entry to hold the
> correct value at runtime is not present in the object file, will hence
> not be emitted by --emit-relocs, and so will not have a corresponding
> PE/COFF base relocation emitted for it. This is the reason why we
> currently cannot support such GOT based relocations.

makes sense! Thanks for the clarification.

Thanks,
Achin


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Relocation fixup during AARCH64 SEC PE-COFF generation?

[Achin Gupta]

On Tue, Sep 13, 2016 at 03:43:41PM +0100, Ard Biesheuvel wrote:
> On 13 September 2016 at 15:12, Ard Biesheuvel <ard.biesheu...@linaro.org> 
> wrote:
> > On 13 September 2016 at 15:03, Achin Gupta <achin.gu...@arm.com> wrote:
> >> Hi All,
> >>
> >> Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
> >> executes directly from within the firmware volume. The FV would typically 
> >> be
> >> loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC 
> >> file
> >> types converts a PE-COFF module into a stripped Terse executable as 
> >> follows:
> >>
> >> [Rule.AARCH64.SEC]
> >>   FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
> >> TE  TEAlign = Auto  $(INF_OUTPUT)/$(MODULE_NAME).efi
> >>   }
> >>
> >> The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" 
> >> option
> >> when the ELF image is generated. Since the SEC module is able to "XIP" 
> >> from the
> >> within FV, this means that the relocations have to be fixed up at link time
> >> before the TE image is created.
> >>
> >
> > Correct. GenFv relocates the image based on the runtime address of the
> > firmware volume.
> >
> >> It seems to me that in GenFw.c, at least the static relocations are fixed 
> >> up
> >> when an ELF image is converted to PE-COFF. Can someone confirm if I am 
> >> correct
> >> in understanding that dynamic relocations will be left as is in the PE-COFF
> >> image while static relocations will be fixed up?
> >>
> >
> > We usually don't emit dynamic relocations, since we are not linking
> > shared objects.
>
> ... or more specifically, all absolute static relocations are
> converted into PE/COFF base relocations, all relative static
> relocations are validated against the PE/COFF layout (which we keep
> 1:1 identical with the ELF section layout), and all dynamic
> relocations are ignored.

Thanks Ard. I expect the relative static relocations to be fixed by the PE-COFF
loader at runtime.

> Note that this implies that proxy generating
> static relocations are rejected, since --emit-relocs does not produce
> any output for the proxies.

You lost me here. What do you mean by "proxy generating static relocations"?

cheers,
Achin
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Relocation fixup during AARCH64 SEC PE-COFF generation?

[Achin Gupta]

Hi All,

Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
executes directly from within the firmware volume. The FV would typically be
loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC file
types converts a PE-COFF module into a stripped Terse executable as follows:

[Rule.AARCH64.SEC]
  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
TE  TEAlign = Auto  $(INF_OUTPUT)/$(MODULE_NAME).efi
  }

The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" option
when the ELF image is generated. Since the SEC module is able to "XIP" from the
within FV, this means that the relocations have to be fixed up at link time
before the TE image is created.

It seems to me that in GenFw.c, at least the static relocations are fixed up
when an ELF image is converted to PE-COFF. Can someone confirm if I am correct
in understanding that dynamic relocations will be left as is in the PE-COFF
image while static relocations will be fixed up?

Please let me know if you need any clarifications.

Thanks a lot,
Achin
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Adding a memory region to GCD on AARCH64?

[Achin Gupta]

Hi Laszlo,

On Thu, Jun 23, 2016 at 04:38:03PM +0200, Laszlo Ersek wrote:
> On 06/23/16 16:19, Achin Gupta wrote:
> > Hi Laszlo,
> >
> > On Wed, Jun 22, 2016 at 09:56:11PM +0200, Laszlo Ersek wrote:
> >> On 06/22/16 20:53, Achin Gupta wrote:
> >>> Hi All,
> >>>
> >>> I having some trouble trying an experiment on the AARCH64 Base FVP with 
> >>> UEFI and
> >>> ARM Trusted Firmware. There is a buffer that is allocated by the latter 
> >>> in DRAM
> >>> with TZC-400 attributes that allow non-secure access. Its extents are made
> >>> available to a UEFI DXE driver through an SMC. AFAIU, it should be added 
> >>> to the
> >>> UEFI memory map/EL2 translation tables and subsequently allocated before 
> >>> it can
> >>> be used.
> >>>
> >>> To add it to the memory map, I successfully call AddMemorySpace() GCD 
> >>> service as
> >>> follows:
> >>>
> >>>  Status = gDS->AddMemorySpace(EfiGcdMemoryTypeSystemMemory,
> >>>   (EFI_PHYSICAL_ADDRESS) mNsBufferAddress,
> >>>   mNsBufferMaxSize,
> >>>   EFI_MEMORY_WB | EFI_MEMORY_XP);
> >>>
> >>> To allocate this buffer, I call AllocateMemorySpace GCD service 
> >>> immediately
> >>> after AddMemorySpace() as follows:
> >>>
> >>> Status = gDS->AllocateMemorySpace(EfiGcdAllocateAddress,
> >>>   EfiGcdMemoryTypeSystemMemory,
> >>>   EFI_PAGE_SHIFT,
> >>>   mNsBufferMaxSize,
> >>>   (EFI_PHYSICAL_ADDRESS *) 
> >>> ,
> >>>   ImageHandle,
> >>>   NULL);
> >>>
> >>> The address of the buffer is 0xfbe0 and size is 0x20 i.e. it is 
> >>> aligned
> >>> to the page boundary. This call fails with EFI_NOT_FOUND. I am unable to 
> >>> figure
> >>> out what is going wrong. Am I using these interfaces in their intended 
> >>> way?
> >>
> >> I recall the following from the relevant volume of the PI spec (please
> >> look it up and double check it): when you add memory space of type
> >> EfiGcdMemoryTypeSystemMemory, it is immediately absorbed by the pool /
> >> page UEFI memory allocation services, for their internal management. So
> >> after you add this, you can't allocate memory *space* of
> >> EfiGcdMemoryTypeSystemMemory. If you want to allocate system memory,
> >> just use the AllocatePool() / AllocatePages() boot services.
> >
> > Makes sense. The spec. says that the new memory range may be automatically
> > allocated for use by UEFI memory services. The EDK2 implementation always 
> > does
> > this in CoreAddMemorySpace() in MdeModulePkg/Core/Dxe/Gcd/Gcd.c.
> >
> >>
> >> The pattern that you use above is valid, but you should use a different
> >> GCD memory type (probably EfiGcdMemoryTypeReserved).
> >
> > I have not tried this memory type. I think there is a more basic problem. 
> > Please
> > see below!
> >
> >>
> >> If you definitely need "system memory" (= plain memory) to reside at
> >> this address, and want to allocate it right after adding it to the
> >> global coherency domain as EfiGcdMemoryTypeSystemMemory, then allocate
> >> it with the AllocatePages() boot service, setting the first argument
> >> (--> EFI_ALLOCATE_TYPE) to AllocateAddress (--> attempt to allocate at
> >> the fixed address).
> >
> > I gave this a try since a similar approach has been followed in some ARM
> > platform code. However, it does not make a difference. I run into a Level 2
> > translation fault as soon as I try to access the buffer. I have disabled 
> > cache
> > state modelling so there are no TLBs or caches. So the translation fault is
> > likely to be 'cause of an invalid/missing page table descriptor.  .
> >
> > I think I am missing something obvious being a UEFI newbie. There are three
> > steps that need to be undertaken in order to access this buffer.
> >
> > 1. Add an identity mapped entry corresponding to the buffer in the 
> > translation
> >tables of the exception level UEFI is executing in (EL2 in my case).
> >
> > 2. Add this buffer in the UEFI 

Re: [edk2] Adding a memory region to GCD on AARCH64?

[Achin Gupta]

Hi Laszlo,

On Wed, Jun 22, 2016 at 09:56:11PM +0200, Laszlo Ersek wrote:
> On 06/22/16 20:53, Achin Gupta wrote:
> > Hi All,
> >
> > I having some trouble trying an experiment on the AARCH64 Base FVP with 
> > UEFI and
> > ARM Trusted Firmware. There is a buffer that is allocated by the latter in 
> > DRAM
> > with TZC-400 attributes that allow non-secure access. Its extents are made
> > available to a UEFI DXE driver through an SMC. AFAIU, it should be added to 
> > the
> > UEFI memory map/EL2 translation tables and subsequently allocated before it 
> > can
> > be used.
> >
> > To add it to the memory map, I successfully call AddMemorySpace() GCD 
> > service as
> > follows:
> >
> >  Status = gDS->AddMemorySpace(EfiGcdMemoryTypeSystemMemory,
> >   (EFI_PHYSICAL_ADDRESS) mNsBufferAddress,
> >   mNsBufferMaxSize,
> >   EFI_MEMORY_WB | EFI_MEMORY_XP);
> >
> > To allocate this buffer, I call AllocateMemorySpace GCD service immediately
> > after AddMemorySpace() as follows:
> >
> > Status = gDS->AllocateMemorySpace(EfiGcdAllocateAddress,
> >   EfiGcdMemoryTypeSystemMemory,
> >   EFI_PAGE_SHIFT,
> >   mNsBufferMaxSize,
> >   (EFI_PHYSICAL_ADDRESS *) 
> > ,
> >   ImageHandle,
> >   NULL);
> >
> > The address of the buffer is 0xfbe0 and size is 0x20 i.e. it is 
> > aligned
> > to the page boundary. This call fails with EFI_NOT_FOUND. I am unable to 
> > figure
> > out what is going wrong. Am I using these interfaces in their intended way?
>
> I recall the following from the relevant volume of the PI spec (please
> look it up and double check it): when you add memory space of type
> EfiGcdMemoryTypeSystemMemory, it is immediately absorbed by the pool /
> page UEFI memory allocation services, for their internal management. So
> after you add this, you can't allocate memory *space* of
> EfiGcdMemoryTypeSystemMemory. If you want to allocate system memory,
> just use the AllocatePool() / AllocatePages() boot services.

Makes sense. The spec. says that the new memory range may be automatically
allocated for use by UEFI memory services. The EDK2 implementation always does
this in CoreAddMemorySpace() in MdeModulePkg/Core/Dxe/Gcd/Gcd.c.

>
> The pattern that you use above is valid, but you should use a different
> GCD memory type (probably EfiGcdMemoryTypeReserved).

I have not tried this memory type. I think there is a more basic problem. Please
see below!

>
> If you definitely need "system memory" (= plain memory) to reside at
> this address, and want to allocate it right after adding it to the
> global coherency domain as EfiGcdMemoryTypeSystemMemory, then allocate
> it with the AllocatePages() boot service, setting the first argument
> (--> EFI_ALLOCATE_TYPE) to AllocateAddress (--> attempt to allocate at
> the fixed address).

I gave this a try since a similar approach has been followed in some ARM
platform code. However, it does not make a difference. I run into a Level 2
translation fault as soon as I try to access the buffer. I have disabled cache
state modelling so there are no TLBs or caches. So the translation fault is
likely to be 'cause of an invalid/missing page table descriptor.  .

I think I am missing something obvious being a UEFI newbie. There are three
steps that need to be undertaken in order to access this buffer.

1. Add an identity mapped entry corresponding to the buffer in the translation
   tables of the exception level UEFI is executing in (EL2 in my case).

2. Add this buffer in the UEFI memory map so that it can either be consumed by
   the memory allocation services or reserved.

3. Allocate this buffer using its physical address so that it is not allocated
   to another driver.

I was under the impression that gDS->AddMemorySpace() will perform both steps
1. and 2. However looking at the behaviour and the code, it seems that it does
only 2.

Is it at all possible to do 1. after the translation tables have been created
and the MMU initialised in the PEI phase. This essentially means adding entries
to live translation tables. Is this expected to be done through architecture
specific mechanisms rather than the GCD services.

>
> Just my two cents.

Thanks a lot for your help!

cheers,
Achin

>
> Thanks
> Laszlo
>
> >
> > I have tried ignoring the error returned by AllocateMemorySpace(). This is 
> > under
> > the assumption 

[edk2] Adding a memory region to GCD on AARCH64?

[Achin Gupta]

Hi All,

I having some trouble trying an experiment on the AARCH64 Base FVP with UEFI and
ARM Trusted Firmware. There is a buffer that is allocated by the latter in DRAM
with TZC-400 attributes that allow non-secure access. Its extents are made
available to a UEFI DXE driver through an SMC. AFAIU, it should be added to the
UEFI memory map/EL2 translation tables and subsequently allocated before it can
be used.

To add it to the memory map, I successfully call AddMemorySpace() GCD service as
follows:

 Status = gDS->AddMemorySpace(EfiGcdMemoryTypeSystemMemory,
  (EFI_PHYSICAL_ADDRESS) mNsBufferAddress,
  mNsBufferMaxSize,
  EFI_MEMORY_WB | EFI_MEMORY_XP);

To allocate this buffer, I call AllocateMemorySpace GCD service immediately
after AddMemorySpace() as follows:

Status = gDS->AllocateMemorySpace(EfiGcdAllocateAddress,
  EfiGcdMemoryTypeSystemMemory,
  EFI_PAGE_SHIFT,
  mNsBufferMaxSize,
  (EFI_PHYSICAL_ADDRESS *) ,
  ImageHandle,
  NULL);

The address of the buffer is 0xfbe0 and size is 0x20 i.e. it is aligned
to the page boundary. This call fails with EFI_NOT_FOUND. I am unable to figure
out what is going wrong. Am I using these interfaces in their intended way?

I have tried ignoring the error returned by AllocateMemorySpace(). This is under
the assumption that AddMemorySpace() must have added it to the translation
tables. So the buffer must be accessible even though it is not yet marked as
allocated. However, I eventually run into translation faults with this approach.

Can anyone provide some insight? Please let me know if you need any
clarifications.

Thanks a lot,
Achin

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg/ArmLib: don't invalidate entire I-cache on range operation

[Achin Gupta]

On Wed, May 11, 2016 at 12:07:51PM +0200, Ard Biesheuvel wrote:
> On 11 May 2016 at 11:35, Achin Gupta <achin.gu...@arm.com> wrote:
> > Hi Ard,
> >
> > Some comments inline!
> >
> > On Wed, May 11, 2016 at 10:41:57AM +0200, Ard Biesheuvel wrote:
> >> Instead of cleaning the data cache to the PoU by virtual address and
> >> subsequently invalidating the entire I-cache, invalidate only the
> >> range that we just cleaned. This way, we don't invalidate other
> >> cachelines unnecessarily.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> >> ---
> >>  ArmPkg/Include/Library/ArmLib.h| 10 
> >> --
> >>  ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c |  3 ++-
> >>  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S |  5 +
> >>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |  5 +
> >>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |  6 ++
> >>  5 files changed, 26 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/ArmPkg/Include/Library/ArmLib.h 
> >> b/ArmPkg/Include/Library/ArmLib.h
> >> index 1689f0072db6..4608b0cc 100644
> >> --- a/ArmPkg/Include/Library/ArmLib.h
> >> +++ b/ArmPkg/Include/Library/ArmLib.h
> >> @@ -183,13 +183,19 @@ ArmInvalidateDataCacheEntryByMVA (
> >>
> >>  VOID
> >>  EFIAPI
> >> -ArmCleanDataCacheEntryToPoUByMVA(
> >> +ArmCleanDataCacheEntryToPoUByMVA (
> >>IN  UINTN   Address
> >>);
> >>
> >>  VOID
> >>  EFIAPI
> >> -ArmCleanDataCacheEntryByMVA(
> >> +ArmInvalidateInstructionCacheEntryToPoUByMVA (
> >> +  IN  UINTN   Address
> >> +  );
> >> +
> >> +VOID
> >> +EFIAPI
> >> +ArmCleanDataCacheEntryByMVA (
> >>  IN  UINTN   Address
> >>  );
> >>
> >> diff --git 
> >> a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
> >> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> index 1045f9068f4d..cc7555061428 100644
> >> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> >> @@ -65,7 +65,8 @@ InvalidateInstructionCacheRange (
> >>)
> >>  {
> >>CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA);
> >> -  ArmInvalidateInstructionCache ();
> >> +  CacheRangeOperation (Address, Length,
> >> +ArmInvalidateInstructionCacheEntryToPoUByMVA);
> >
> > Afaics, CacheRangeOperation() uses the data cache line length by default. 
> > This
> > will match the I$ line length in most cases. But, it would be better to use 
> > the
> > ArmInstructionCacheLineLength() function instead. I suggest that we add a 
> > cache
> > line length parameter to CacheRangeOperation() to allow the distinction.
> >
>
> Good point.
>
> > Also, from my reading of the ARMv8 ARM B2.6.5 & E2.6.5, we need an ISB at 
> > the
> > end of all the operations.
> >
>
> I would assume that a single call to
> ArmInstructionSynchronizationBarrier() at the end of
> InvalidateInstructionCacheRange () should suffice?

Agree. This is what I am doing locally:

@@ -64,8 +64,9 @@ InvalidateInstructionCacheRange (
   IN  UINTN Length
   )
 {
-  CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA);
-  ArmInvalidateInstructionCache ();
+  CacheRangeOperation (Address, Length, ArmDataCacheLineLength(), 
ArmCleanDataCacheEntryToPoUByMVA);
+  CacheRangeOperation (Address, Length, ArmInstructionCacheLineLength(), 
ArmInvalidateInstructionCacheEntryToPoUByMVA);
+  ArmInstructionSynchronizationBarrier();
   return Address;
 }

>
> >>return Address;
> >>  }
> >>
> >> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
> >> b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> >> index 43f7a795acec..9441f47e30ba 100644
> >> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> >> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> >> @@ -23,6 +23,7 @@ GCC_ASM_EXPORT (ArmInvalidateInstructionCache)
> >>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)
> >>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryByMVA)
> >>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryToPoUByMVA)
> >> +GCC_ASM_EXPORT (ArmInvalidateI

Re: [edk2] [PATCH] ArmPkg/ArmLib: don't invalidate entire I-cache on range operation

[Achin Gupta]

Hi Ard,

Some comments inline!

On Wed, May 11, 2016 at 10:41:57AM +0200, Ard Biesheuvel wrote:
> Instead of cleaning the data cache to the PoU by virtual address and
> subsequently invalidating the entire I-cache, invalidate only the
> range that we just cleaned. This way, we don't invalidate other
> cachelines unnecessarily.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Include/Library/ArmLib.h| 10 
> --
>  ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c |  3 ++-
>  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S |  5 +
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |  5 +
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |  6 ++
>  5 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index 1689f0072db6..4608b0cc 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -183,13 +183,19 @@ ArmInvalidateDataCacheEntryByMVA (
>
>  VOID
>  EFIAPI
> -ArmCleanDataCacheEntryToPoUByMVA(
> +ArmCleanDataCacheEntryToPoUByMVA (
>IN  UINTN   Address
>);
>
>  VOID
>  EFIAPI
> -ArmCleanDataCacheEntryByMVA(
> +ArmInvalidateInstructionCacheEntryToPoUByMVA (
> +  IN  UINTN   Address
> +  );
> +
> +VOID
> +EFIAPI
> +ArmCleanDataCacheEntryByMVA (
>  IN  UINTN   Address
>  );
>
> diff --git a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> index 1045f9068f4d..cc7555061428 100644
> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> @@ -65,7 +65,8 @@ InvalidateInstructionCacheRange (
>)
>  {
>CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryToPoUByMVA);
> -  ArmInvalidateInstructionCache ();
> +  CacheRangeOperation (Address, Length,
> +ArmInvalidateInstructionCacheEntryToPoUByMVA);

Afaics, CacheRangeOperation() uses the data cache line length by default. This
will match the I$ line length in most cases. But, it would be better to use the
ArmInstructionCacheLineLength() function instead. I suggest that we add a cache
line length parameter to CacheRangeOperation() to allow the distinction.

Also, from my reading of the ARMv8 ARM B2.6.5 & E2.6.5, we need an ISB at the
end of all the operations.

>return Address;
>  }
>
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> index 43f7a795acec..9441f47e30ba 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> @@ -23,6 +23,7 @@ GCC_ASM_EXPORT (ArmInvalidateInstructionCache)
>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)
>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryByMVA)
>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryToPoUByMVA)
> +GCC_ASM_EXPORT (ArmInvalidateInstructionCacheEntryToPoUByMVA)
>  GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryBySetWay)
>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryBySetWay)
> @@ -80,6 +81,10 @@ ASM_PFX(ArmCleanDataCacheEntryToPoUByMVA):
>dc  cvau, x0// Clean single data cache line to PoU
>ret
>
> +ASM_PFX(ArmInvalidateInstructionCacheEntryToPoUByMVA):
> +  ic  ivau, x0// Invalidate single instruction cache line to PoU
> +  ret
> +
>
>  ASM_PFX(ArmCleanInvalidateDataCacheEntryByMVA):
>dc  civac, x0   // Clean and invalidate single data cache line
> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S 
> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> index 50c760f335de..c765032c9e4d 100644
> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> @@ -18,6 +18,7 @@
>
>  GCC_ASM_EXPORT (ArmInvalidateInstructionCache)
>  GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)
> +GCC_ASM_EXPORT (ArmInvalidateInstructionCacheEntryToPoUByMVA)
>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryByMVA)
>  GCC_ASM_EXPORT (ArmCleanDataCacheEntryToPoUByMVA)
>  GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
> @@ -74,6 +75,10 @@ ASM_PFX(ArmCleanDataCacheEntryToPoUByMVA):
>mcr p15, 0, r0, c7, c11, 1  @clean single data cache line to PoU
>bx  lr
>
> +ASM_PFX(ArmInvalidateInstructionCacheEntryToPoUByMVA):
> +  mcr p15, 0, r0, c7, c5, 1  @Invalidate single instruction cache line 
> to PoU
> +  mcr p15, 0, r0, c7, c5, 7  @Invalidate branch predictor

Is it reasonable to assume that for every Icache invalidation by MVA, the BP
will have to be invalidated for that MVA as well? I guess so!

cheers,
Achin

> +  bx  lr
>
>  ASM_PFX(ArmCleanInvalidateDataCacheEntryByMVA):
>mcr p15, 0, r0, c7, c14, 1  @clean and invalidate single data cache 
> line
> diff --git 

Re: [edk2] I$ maintenance in ArmCacheMaintenanceLib.c

[Achin Gupta]

BTW, digging it a bit deeper and adding edk2-devel belatedly!

For ARMv7 (assuming that is where the code was lifted from), it might be that
the entire I$ was invaidated since it did the same to the branch predictor. The
recommended sequence, as per the ARMv7 ARM, Section A3.5.4, should be:

DCCMVAU [instruction location] ; Clean data cache by MVA to point of unification
DSB; Ensure visibility of the data cleaned from the 
cache
ICIMVAU [instruction location] ; Invalidate instruction cache by MVA to PoU
BPIMVAU [instruction location] ; Invalidate branch predictor by MVA to PoU
DSB; Ensure completion of the invalidations
ISB; Synchronize fetched instruction stream

thanks,
Achin

On Tue, May 10, 2016 at 09:46:03AM +0100, Achin Gupta wrote:
> Thanks Eugene! Thought as much but wanted to be sure. I will put up something
> for review in a bit.
>
> On Mon, May 09, 2016 at 10:53:52PM +, Cohen, Eugene wrote:
> >
> > Through the power of 'git blame' it looks like this dates back to the dawn 
> > of time (Andrew Fish and Olivier) and predates ARMv8.
> >
> > On AArch64 this is implemented thusly:
> >
> >   ic  iallu   // Invalidate entire instruction cache
> >   dsb sy
> >   isb
> >   ret
> >
> > ARMv8 shows an IC IVAU at C5.4.11 so I think we can switch this to a cache 
> > range operation.
> >
> > Eugene
> >
> > > -Original Message-
> > > From: Achin Gupta [mailto:achin.gu...@arm.com]
> > > Sent: Monday, May 09, 2016 1:33 PM
> > > To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Leif Lindholm
> > > <leif.lindh...@arm.com>; Cohen, Eugene <eug...@hp.com>
> > > Subject: I$ maintenance in ArmCacheMaintenanceLib.c
> > >
> > > Hi All,
> > >
> > > Does anyone of you know why on ARM platforms, the entire instruction
> > > cache is invalidated in the following function :
> > >
> > > VOID *
> > > EFIAPI
> > > InvalidateInstructionCacheRange (
> > >   IN  VOID  *Address,
> > >   IN  UINTN Length
> > >   )
> > > {
> > >   CacheRangeOperation (Address, Length,
> > > ArmCleanDataCacheEntryToPoUByMVA);
> > >   ArmInvalidateInstructionCache ();
> > >   return Address;
> > > }
> > >
> > > Afaics, there is no instruction to perform a "IC IVAU" in
> > > ArmPkg/Library/ArmLib/AArch64/AArch64Support.S. Instead of
> > > ArmInvalidateInstructionCache() there should be another
> > > CacheRangeOperation() for the ISide.
> > >
> > > There is another problem that CacheRangeOperation() caters for only
> > > the Data cache line length even though the function name is generic.
> > >
> > > I am looking at the Tianocore edk2 tree (commit 9f64a83). Please let me
> > > know if I am missing anything, else I will cook up some patches to fix the
> > > problem.
> > >
> > > Thanks,
> > > Achin
> > >

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Building a SMM_CORE module as an XIP image

[Achin Gupta]

Hi All,

I am prototyping the proposal made in ECR #1390 (MM in Standalone mode etc) on
the Juno and FVP ARM development platforms. The prototype mainly has a module of
type SMM_CORE that contains:

a. The MM Foundation code in Standalone mode. Lets call the entry point of this
   module SmmMain().

b. Libraries that a) depends upon.

I am able to build this module as a PE/COFF executable. Lets call it
SmmCore.efi. An SMM_CORE module is usually dispatched during DXE. In my use
case, I want to dispatch it from ARM Trusted firmware. To do this I need to
build this module so that:

1. It is an XIP image that can be copied by ARM Trusted Firmware from Flash to
   volatile memory
2. ARM TF is able to pass control to SmmMain() without requiring understand a
   file format like PE/COFF or ELF. Ideally, it should just be enough to pass
   control to the first address of the image.
3. It should be possble to include standalone SMM drivers in this image in the
   future that the MM Foundation can dispatch.

Being a complete newbie, the closest existing solution that I could see is the
mechanism that is used build and run FD images for the Juno and FVP ARM
development platforms. AFAIU, the BL33_AP_UEFI.fd has a branch instruction at
its lowest address that jumps to the _ModuleEntryPoint() of the SEC module. The
SEC module (ArmPlatformPkg/PrePi/PeiMPCore.inf) is pulled into the
FVMAIN_COMPACT as a Terse executable in a file of type
EFI_FV_FILETYPE_SECURITY_CORE..

So, I wrote a SmmCore.fdf similar to ArmVExpress-FVP-AArch64.fdf that pulls in
SmmCore.inf into FV.FVMAIN_COMPACT by tweaking [Rule.Common.SEC] to
[Rule.Common.SMM_CORE]. This pulls in the SmmCore.efi as a SEC File in the
firmware volume.

This hackery creates a SmmCore.fd where the first instruction is a branch. Just
like the BL33_AP_UEFI.fd, ARM TF should be able to load and run this file as
described in 2. above. However, I see that the branch is not to
SmmMain(). Instead it is to the _ModuleEntryPoint() from a DriverEntryPoint
library that the SmmCore.inf depends upon. On closer inspection, I see that the
SmmCore.efi was build with _ModuleEntryPoint() passed as the parameter the
Linker's "-e" and "-u" flags.

I tried adding a build option to SmmCore.dsc to change the entry point as
follows:

*_*_*_DLINK_FLAGS = --entry SmmMain

This appends the correct "-e" option to the linker flags but the branch is still
not to SmmMain().

Having run out of ideas that are within the bounds of the EDK2 build system, I
would like to know:

a. Is this the right approach to fulfill the requirements in at least 1) & 2)
   above?

b. Is it actually possible to make the hack above work? If so, then what am I
   missing?

Any help in this matter will be greatly appreciated. Please let me know if you
need any clarifications.

thanks a lot,
Achin
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel