[edk2] [PATCH v4 6/7] MdePkg/UefiBaseType.h: treat EBC as a non-native machine type

2019-03-31 Thread Ard Biesheuvel
Instead of classifying EBC as a supported machine type and have special
handling in DXE core for loading EBC images, make it a foreign type and
rely on the EDK2 PE/COFF image emulator protocol to claim the image when
the DXE core finds that it cannot be supported natively.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdePkg/Include/Uefi/UefiBaseType.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/Uefi/UefiBaseType.h 
b/MdePkg/Include/Uefi/UefiBaseType.h
index 8c9d571eb1ce..33b872af91a9 100644
--- a/MdePkg/Include/Uefi/UefiBaseType.h
+++ b/MdePkg/Include/Uefi/UefiBaseType.h
@@ -250,14 +250,14 @@ typedef union {
 #if   defined (MDE_CPU_IA32)
 
 #define EFI_IMAGE_MACHINE_TYPE_SUPPORTED(Machine) \
-  (((Machine) == EFI_IMAGE_MACHINE_IA32) || ((Machine) == 
EFI_IMAGE_MACHINE_EBC))
+  ((Machine) == EFI_IMAGE_MACHINE_IA32)
 
 #define EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED(Machine) ((Machine) == 
EFI_IMAGE_MACHINE_X64)
 
 #elif defined (MDE_CPU_X64)
 
 #define EFI_IMAGE_MACHINE_TYPE_SUPPORTED(Machine) \
-  (((Machine) == EFI_IMAGE_MACHINE_X64) || ((Machine) == 
EFI_IMAGE_MACHINE_EBC))
+  ((Machine) == EFI_IMAGE_MACHINE_X64)
 
 #define EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED(Machine) ((Machine) == 
EFI_IMAGE_MACHINE_IA32)
 
@@ -270,7 +270,7 @@ typedef union {
 #elif defined (MDE_CPU_AARCH64)
 
 #define EFI_IMAGE_MACHINE_TYPE_SUPPORTED(Machine) \
-  (((Machine) == EFI_IMAGE_MACHINE_AARCH64) || ((Machine) == 
EFI_IMAGE_MACHINE_EBC))
+  ((Machine) == EFI_IMAGE_MACHINE_AARCH64)
 
 #define EFI_IMAGE_MACHINE_CROSS_TYPE_SUPPORTED(Machine) (FALSE)
 
-- 
2.17.1

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


[edk2] [PATCH v4 5/7] MdeModulePkg/EbcDxe: implement the PE/COFF emulator protocol

2019-03-31 Thread Ard Biesheuvel
Implement the new EDK2 PE/COFF image emulator protocol so that we can
remove the EBC specific handling in the DXE core and other places in
the core code.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf |   3 +
 MdeModulePkg/Universal/EbcDxe/EbcDxe.inf  |   3 +
 MdeModulePkg/Universal/EbcDxe/EbcInt.c| 123 
 MdeModulePkg/Universal/EbcDxe/EbcInt.h|   3 +
 4 files changed, 132 insertions(+)

diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf 
b/MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf
index 8f293f5c7c29..c7a9d519b080 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf
@@ -89,6 +89,8 @@
   BaseMemoryLib
   DebugLib
   BaseLib
+  CacheMaintenanceLib
+  PeCoffLib
 
 [Protocols]
   gEfiDebugSupportProtocolGuid  ## PRODUCES
@@ -98,6 +100,7 @@
   gEfiEbcSimpleDebuggerProtocolGuid ## SOMETIMES_CONSUMES
   gEfiPciRootBridgeIoProtocolGuid   ## SOMETIMES_CONSUMES
   gEfiSimpleFileSystemProtocolGuid  ## SOMETIMES_CONSUMES
+  gEdkiiPeCoffImageEmulatorProtocolGuid ## PRODUCES
 
 [Guids]
   gEfiFileInfoGuid  ## SOMETIMES_CONSUMES ## GUID
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf 
b/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
index d6ee6194a0c8..ecccf2c57ffe 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
@@ -57,7 +57,9 @@
   MdeModulePkg/MdeModulePkg.dec
 
 [LibraryClasses]
+  CacheMaintenanceLib
   MemoryAllocationLib
+  PeCoffLib
   UefiBootServicesTableLib
   BaseMemoryLib
   UefiDriverEntryPoint
@@ -68,6 +70,7 @@
 [Protocols]
   gEfiDebugSupportProtocolGuid  ## PRODUCES
   gEfiEbcProtocolGuid   ## PRODUCES
+  gEdkiiPeCoffImageEmulatorProtocolGuid ## PRODUCES
   gEfiEbcVmTestProtocolGuid ## SOMETIMES_PRODUCES
   gEfiEbcSimpleDebuggerProtocolGuid ## SOMETIMES_CONSUMES
 
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcInt.c 
b/MdeModulePkg/Universal/EbcDxe/EbcInt.c
index 727ba8bcae44..051eb0aaa07b 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcInt.c
+++ b/MdeModulePkg/Universal/EbcDxe/EbcInt.c
@@ -349,6 +349,119 @@ UINTN  mStackNum = 0;
 EFI_EVENT  mEbcPeriodicEvent;
 VM_CONTEXT *mVmPtr = NULL;
 
+/**
+  Check whether the emulator supports executing a certain PE/COFF image
+
+  @param[in] This This pointer for EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL
+  structure
+  @param[in] ImageTypeWhether the image is an application, a boot time
+  driver or a runtime driver.
+  @param[in] DevicePath   Path to device where the image originated
+  (e.g., a PCI option ROM)
+
+  @retval TRUEThe image is supported by the emulator
+  @retval FALSE   The image is not supported by the emulator.
+**/
+BOOLEAN
+EFIAPI
+EbcIsImageSupported (
+  IN  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
+  IN  UINT16  ImageType,
+  IN  EFI_DEVICE_PATH_PROTOCOL*DevicePath   OPTIONAL
+  )
+{
+  if (ImageType != EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION &&
+  ImageType != EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER) {
+return FALSE;
+  }
+  return TRUE;
+}
+
+/**
+  Register a supported PE/COFF image with the emulator. After this call
+  completes successfully, the PE/COFF image may be started as usual, and
+  it is the responsibility of the emulator implementation that any branch
+  into the code section of the image (including returns from functions called
+  from the foreign code) is executed as if it were running on the machine
+  type it was built for.
+
+  @param[in]  This  This pointer for
+EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL structure
+  @param[in]  ImageBase The base address in memory of the PE/COFF image
+  @param[in]  ImageSize The size in memory of the PE/COFF image
+  @param[in,out]  EntryPointThe entry point of the PE/COFF image. Passed by
+reference so that the emulator may modify it.
+
+  @retval EFI_SUCCESS   The image was registered with the emulator and
+can be started as usual.
+  @retval other The image could not be registered.
+
+  If the PE/COFF machine type or image type are not supported by the emulator,
+  then ASSERT().
+**/
+EFI_STATUS
+EFIAPI
+EbcRegisterImage (
+  IN  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
+  IN  EFI_PHYSICAL_ADDRESSImageBase,
+  IN  UINT64  ImageSize,
+  IN  OUT EFI_IMAGE_ENTRY_POINT   *EntryPoint
+  )
+{
+  DEBUG_CODE_BEGIN ();
+PE_COFF_LOADER_IMAGE

[edk2] [PATCH v4 2/7] MdeModulePkg/DxeCore: invoke the emulator protocol for foreign images

2019-03-31 Thread Ard Biesheuvel
When encountering PE/COFF images that cannot be supported natively,
attempt to locate an instance of the PE/COFF image emulator protocol,
and if it supports the image, proceed with loading it and register it
with the emulator.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Core/Dxe/DxeMain.h |   3 +
 MdeModulePkg/Core/Dxe/DxeMain.inf   |   1 +
 MdeModulePkg/Core/Dxe/Image/Image.c | 144 ++--
 3 files changed, 137 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h b/MdeModulePkg/Core/Dxe/DxeMain.h
index 2dec9da5e35b..48ec30a48aa2 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.h
+++ b/MdeModulePkg/Core/Dxe/DxeMain.h
@@ -53,6 +53,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -228,6 +229,8 @@ typedef struct {
   UINT16  Machine;
   /// EBC Protocol pointer
   EFI_EBC_PROTOCOL*Ebc;
+  /// PE/COFF Image Emulator Protocol pointer
+  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL  *PeCoffEmu;
   /// Runtime image list
   EFI_RUNTIME_IMAGE_ENTRY *RuntimeData;
   /// Pointer to Loaded Image Device Path Protocol
diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index 10375443c0f4..ce6fc19be5e4 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -162,6 +162,7 @@
   gEfiHiiPackageListProtocolGuid## SOMETIMES_PRODUCES
   gEfiEbcProtocolGuid   ## SOMETIMES_CONSUMES
   gEfiSmmBase2ProtocolGuid  ## SOMETIMES_CONSUMES
+  gEdkiiPeCoffImageEmulatorProtocolGuid ## SOMETIMES_CONSUMES
 
   # Arch Protocols
   gEfiBdsArchProtocolGuid   ## CONSUMES
diff --git a/MdeModulePkg/Core/Dxe/Image/Image.c 
b/MdeModulePkg/Core/Dxe/Image/Image.c
index eddca140ee1a..cda447d23ec5 100644
--- a/MdeModulePkg/Core/Dxe/Image/Image.c
+++ b/MdeModulePkg/Core/Dxe/Image/Image.c
@@ -29,6 +29,15 @@ LOAD_PE32_IMAGE_PRIVATE_DATA  mLoadPe32PrivateData = {
   }
 };
 
+typedef struct {
+  LIST_ENTRYLink;
+  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL  *Emulator;
+  UINT16MachineType;
+} EMULATOR_ENTRY;
+
+STATIC LIST_ENTRY   mAvailableEmulators;
+STATIC EFI_EVENTmPeCoffEmuProtocolRegistrationEvent;
+STATIC VOID *mPeCoffEmuProtocolNotifyRegistration;
 
 //
 // This code is needed to build the Image handle for the DXE Core
@@ -67,6 +76,7 @@ LOADED_IMAGE_PRIVATE_DATA mCorePrivateImage  = {
   NULL,   // JumpContext
   0,  // Machine
   NULL,   // Ebc
+  NULL,   // PeCoffEmu
   NULL,   // RuntimeData
   NULL// LoadedImageDevicePath
 };
@@ -118,6 +128,39 @@ GetMachineTypeName (
   return L"";
 }
 
+/**
+  Notification event handler registered by CoreInitializeImageServices () to
+  keep track of which PE/COFF image emulators are available.
+
+  @param  Event  The Event that is being processed, not used.
+  @param  ContextEvent Context, not used.
+
+**/
+STATIC
+VOID
+EFIAPI
+PeCoffEmuProtocolNotify (
+  IN  EFI_EVENT   Event,
+  IN  VOID*Context
+  )
+{
+  EFI_STATUS  Status;
+  EMULATOR_ENTRY  *Entry;
+
+  Entry = AllocateZeroPool (sizeof *Entry);
+  ASSERT (Entry != NULL);
+
+  Status = CoreLocateProtocol (,
+   mPeCoffEmuProtocolNotifyRegistration,
+   (VOID **)>Emulator
+   );
+  ASSERT_EFI_ERROR (Status);
+
+  Entry->MachineType = Entry->Emulator->MachineType;
+
+  InsertTailList (, >Link);
+}
+
 /**
   Add the Image Services to EFI Boot Services Table and install the protocol
   interfaces for this image.
@@ -192,6 +235,30 @@ CoreInitializeImageServices (
   gDxeCoreImageHandle = Image->Handle;
   gDxeCoreLoadedImage = >Info;
 
+  //
+  // Create the PE/COFF emulator protocol registration event
+  //
+  Status = CoreCreateEvent (
+ EVT_NOTIFY_SIGNAL,
+ TPL_CALLBACK,
+ PeCoffEmuProtocolNotify,
+ NULL,
+ 
+ );
+  ASSERT_EFI_ERROR(Status);
+
+  //
+  // Register for protocol notifications on this event
+  //
+  Status = CoreRegisterProtocolNotify (
+ ,
+ mPeCoffEmuProtocolRegistrationEvent,
+ 
+ );
+  ASSERT_EFI_ERROR(Status);
+
+  InitializeListHead ();
+
   if (FeaturePcdGet (PcdFrameworkCompatibilitySupport)) {
 //
 // Export DXE Core PE Loader functionality for backward compatibility.
@@ -425,6 +492,45 @@ GetPeCoffImageFixLoadingAssignedAddress(
DEBUG ((EFI_D_INFO|EFI_D_LOAD, "LOADING MODULE FIXED INFO: Loading module 

[edk2] [PATCH v4 7/7] MdeModulePkg/DxeCore: remove explicit EBC handling

2019-03-31 Thread Ard Biesheuvel
Now that the EBC machine type is no longer classified as a
natively supported machine type on the architectures that can
support it via the EBC interpreter, the EBC specific handling
in DXE core is no longer used and can be removed.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Core/Dxe/DxeMain.h |  3 --
 MdeModulePkg/Core/Dxe/DxeMain.inf   |  1 -
 MdeModulePkg/Core/Dxe/Image/Image.c | 53 ++--
 3 files changed, 3 insertions(+), 54 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h b/MdeModulePkg/Core/Dxe/DxeMain.h
index 48ec30a48aa2..6e83f15a4541 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.h
+++ b/MdeModulePkg/Core/Dxe/DxeMain.h
@@ -42,7 +42,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -227,8 +226,6 @@ typedef struct {
   BASE_LIBRARY_JUMP_BUFFER*JumpContext;
   /// Machine type from PE image
   UINT16  Machine;
-  /// EBC Protocol pointer
-  EFI_EBC_PROTOCOL*Ebc;
   /// PE/COFF Image Emulator Protocol pointer
   EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL  *PeCoffEmu;
   /// Runtime image list
diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index ce6fc19be5e4..68413517f2a7 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -160,7 +160,6 @@
   gEfiLoadedImageProtocolGuid   ## PRODUCES
   gEfiLoadedImageDevicePathProtocolGuid ## PRODUCES
   gEfiHiiPackageListProtocolGuid## SOMETIMES_PRODUCES
-  gEfiEbcProtocolGuid   ## SOMETIMES_CONSUMES
   gEfiSmmBase2ProtocolGuid  ## SOMETIMES_CONSUMES
   gEdkiiPeCoffImageEmulatorProtocolGuid ## SOMETIMES_CONSUMES
 
diff --git a/MdeModulePkg/Core/Dxe/Image/Image.c 
b/MdeModulePkg/Core/Dxe/Image/Image.c
index cda447d23ec5..0b8b2ba15ccf 100644
--- a/MdeModulePkg/Core/Dxe/Image/Image.c
+++ b/MdeModulePkg/Core/Dxe/Image/Image.c
@@ -75,7 +75,6 @@ LOADED_IMAGE_PRIVATE_DATA mCorePrivateImage  = {
   NULL,   // JumpBuffer
   NULL,   // JumpContext
   0,  // Machine
-  NULL,   // Ebc
   NULL,   // PeCoffEmu
   NULL,   // RuntimeData
   NULL// LoadedImageDevicePath
@@ -92,9 +91,6 @@ typedef struct {
   CHAR16  *MachineTypeName;
 } MACHINE_TYPE_INFO;
 
-//
-// EBC machine is not listed in this table, because EBC is in the default 
supported scopes of other machine type.
-//
 GLOBAL_REMOVE_IF_UNREFERENCED MACHINE_TYPE_INFO  mMachineTypeInfo[] = {
   {EFI_IMAGE_MACHINE_IA32,   L"IA32"},
   {EFI_IMAGE_MACHINE_IA64,   L"IA64"},
@@ -747,51 +743,15 @@ CoreLoadPeImage (
   InvalidateInstructionCacheRange ((VOID 
*)(UINTN)Image->ImageContext.ImageAddress, 
(UINTN)Image->ImageContext.ImageSize);
 
   //
-  // Copy the machine type from the context to the image private data. This
-  // is needed during image unload to know if we should call an EBC protocol
-  // to unload the image.
+  // Copy the machine type from the context to the image private data.
   //
   Image->Machine = Image->ImageContext.Machine;
 
   //
-  // Get the image entry point. If it's an EBC image, then call into the
-  // interpreter to create a thunk for the entry point and use the returned
-  // value for the entry point.
+  // Get the image entry point.
   //
   Image->EntryPoint   = 
(EFI_IMAGE_ENTRY_POINT)(UINTN)Image->ImageContext.EntryPoint;
-  if (Image->ImageContext.Machine == EFI_IMAGE_MACHINE_EBC) {
-//
-// Locate the EBC interpreter protocol
-//
-Status = CoreLocateProtocol (, NULL, (VOID 
**)>Ebc);
-if (EFI_ERROR(Status) || Image->Ebc == NULL) {
-  DEBUG ((DEBUG_LOAD | DEBUG_ERROR, "CoreLoadPeImage: There is no EBC 
interpreter for an EBC image.\n"));
-  goto Done;
-}
-
-//
-// Register a callback for flushing the instruction cache so that created
-// thunks can be flushed.
-//
-Status = Image->Ebc->RegisterICacheFlush (Image->Ebc, 
(EBC_ICACHE_FLUSH)InvalidateInstructionCacheRange);
-if (EFI_ERROR(Status)) {
-  goto Done;
-}
-
-//
-// Create a thunk for the image's entry point. This will be the new
-// entry point for the image.
-//
-Status = Image->Ebc->CreateThunk (
-   Image->Ebc,
-   Image->Handle,
-   (VOID *)(UINTN) Image->ImageContext.EntryPoint,
-   (VOID **) >EntryPoint
-   );
-if (EFI_ERROR(Status)) {
-  goto Done;
-}
-  } else if (Image->PeCoffEmu != NULL) {
+  if (Image->PeCoffEmu != NULL) {
 Status = Image->PeCof

[edk2] [PATCH v4 4/7] MdeModulePkg/UefiBootManagerLib: allow foreign Driver#### images

2019-03-31 Thread Ard Biesheuvel
Allow PE/COFF images that must execute under emulation for Driver
options, by removing the redundant machine type check from the BDS code.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 7bf96646c690..8e6caaa63548 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1233,10 +1233,8 @@ BmIsLoadOptionPeHeaderValid (
   // Check PE32 or PE32+ magic, and machine type
   //
   OptionalHeader = (EFI_IMAGE_OPTIONAL_HEADER32 *) 
>Pe32.OptionalHeader;
-  if ((OptionalHeader->Magic == EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC ||
-   OptionalHeader->Magic == EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC) &&
-  EFI_IMAGE_MACHINE_TYPE_SUPPORTED (PeHeader->Pe32.FileHeader.Machine)
-  ) {
+  if (OptionalHeader->Magic == EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC ||
+  OptionalHeader->Magic == EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC) {
 //
 // Check the Subsystem:
 //   Driver must be of type BootServiceDriver or RuntimeDriver
-- 
2.17.1

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


[edk2] [PATCH v4 1/7] MdeModulePkg: introduce PE/COFF image emulator protocol

2019-03-31 Thread Ard Biesheuvel
Introduce a protocol that can be invoked by the image loading services
to execute foreign architecture PE/COFF images via an emulator.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h | 107 
 MdeModulePkg/MdeModulePkg.dec   |   4 +
 2 files changed, 111 insertions(+)

diff --git a/MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h 
b/MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h
new file mode 100644
index ..1ca302440e4a
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h
@@ -0,0 +1,107 @@
+/** @file
+  Copyright (c) 2019, Linaro, 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 PECOFF_IMAGE_EMULATOR_PROTOCOL_GUID_H
+#define PECOFF_IMAGE_EMULATOR_PROTOCOL_GUID_H
+
+#define EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL_GUID \
+  { 0x96F46153, 0x97A7, 0x4793, { 0xAC, 0xC1, 0xFA, 0x19, 0xBF, 0x78, 0xEA, 
0x97 } }
+
+typedef struct _EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL 
EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL;
+
+/**
+  Check whether the emulator supports executing a certain PE/COFF image
+
+  @param[in] This This pointer for EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL
+  structure
+  @param[in] ImageTypeWhether the image is an application, a boot time
+  driver or a runtime driver.
+  @param[in] DevicePath   Path to device where the image originated
+  (e.g., a PCI option ROM)
+
+  @retval TRUEThe image is supported by the emulator
+  @retval FALSE   The image is not supported by the emulator.
+**/
+typedef
+BOOLEAN
+(EFIAPI *EDKII_PECOFF_IMAGE_EMULATOR_IS_IMAGE_SUPPORTED) (
+  IN  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
+  IN  UINT16  ImageType,
+  IN  EFI_DEVICE_PATH_PROTOCOL*DevicePath   OPTIONAL
+  );
+
+/**
+  Register a supported PE/COFF image with the emulator. After this call
+  completes successfully, the PE/COFF image may be started as usual, and
+  it is the responsibility of the emulator implementation that any branch
+  into the code section of the image (including returns from functions called
+  from the foreign code) is executed as if it were running on the machine
+  type it was built for.
+
+  @param[in]  This  This pointer for
+EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL structure
+  @param[in]  ImageBase The base address in memory of the PE/COFF image
+  @param[in]  ImageSize The size in memory of the PE/COFF image
+  @param[in,out]  EntryPointThe entry point of the PE/COFF image. Passed by
+reference so that the emulator may modify it.
+
+  @retval EFI_SUCCESS   The image was registered with the emulator and
+can be started as usual.
+  @retval other The image could not be registered.
+
+  If the PE/COFF machine type or image type are not supported by the emulator,
+  then ASSERT().
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_PECOFF_IMAGE_EMULATOR_REGISTER_IMAGE) (
+  IN  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
+  IN  EFI_PHYSICAL_ADDRESSImageBase,
+  IN  UINT64  ImageSize,
+  IN  OUT EFI_IMAGE_ENTRY_POINT   *EntryPoint
+  );
+
+/**
+  Unregister a PE/COFF image that has been registered with the emulator.
+  This should be done before the image is unloaded from memory.
+
+  @param[in] This This pointer for EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL
+  structure
+  @param[in] ImageBaseThe base address in memory of the PE/COFF image
+
+  @retval EFI_SUCCESS The image was unregistered with the emulator.
+  @retval other   Image could not be unloaded.
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_PECOFF_IMAGE_EMULATOR_UNREGISTER_IMAGE) (
+  IN  EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL*This,
+  IN  EFI_PHYSICAL_ADDRESSImageBase
+  );
+
+#define EDKII_PECOFF_IMAGE_EMULATOR_VERSION 0x1
+
+typedef struct _EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL {
+  EDKII_PECOFF_IMAGE_EMULATOR_IS_IMAGE_SUPPORTEDIsImageSupported;
+  EDKII_PECOFF_IMAGE_EMULATOR_REGISTER_IMAGERegisterImage;
+  EDKII_PECOFF_IMAGE_EMULATOR_UNREGISTER_IMAGE  UnregisterImage;
+
+  // Protocol version implemented by the emulator
+  UINT32Version;
+  // The ma

[edk2] [PATCH v4 0/7] MdeModulePkg: add support for dispatching foreign arch PE/COFF images

2019-03-31 Thread Ard Biesheuvel
Add the basic plumbing to DXE core, the PCI bus driver and the boot manager
to allow PE/COFF images to be dispatched that target an architecture that is
not native for the platform, but which is supported by one of potentially
several available emulators.

One implementation of such an emulator can be found here:
https://github.com/ardbiesheuvel/X86EmulatorPkg/tree/upstream-v4

This also allows us to get rid of the special treatment of EBC images in
core code. Instead, the EbcDxe driver is augmented with an implementation
of the EDK2 PE/COFF image emulator protocol so that internal knowledge of
how EBC is implemented (I-cache flushing, thunks) is removed from the DXE
core.

Changes since v3:
- Simplify the handling of option ROMs and Driver images, by simply
  deferring to the LoadImage() boot service to decide whether an image
  can be supported or not - this removes some redundant checks from the
  BDS layer and the PCI bus driver.
- Move the machine type supported by the emulator into the protocol struct,
  so we can optimize away calls into the emulator for each image loaded.
  Instead, the LoadImage() code will only invoke the IsSupported() method for
  images that are known to have a matching machine type.

Note that I have considered, but ultimately dismissed the suggestion to
register and unregister emulators via a new protocol. The main issue is
that registering and unregistering struct containing sets of function
pointers is awfully similar to managing a protocol database, and we already
have the code to do that in EDK2.

So instead, I have removed all the code that iterates over a handle buffer
of emu protocols and invokes each one to see if it will support the image.
Instead, this is all done by CoreLoadImage().

Changes since v2:
- incorporate feedback from Andrew Fish (delivered in person):
  * pass a device path into the IsImageSupported() protocol method so that an
implementation can blacklist or whitelist certain devices, or implement
other policies that depend on the device where the driver originated
  * allow the emulator to supersede the native loading of the image - this
permits things like X86 on X86 emulators for security sandboxing or debug

Changes since v1:
- subsume the EBC handling into the EDK2 emulator protocol and abstract
  away from EBC specifics in core code.
- allow multiple emulator implementations to co-exist
- incorporate Star's review feedback

Cc: Vincent Zimmer 
Cc: Brian Richardson 
Cc: Michael D Kinney 
Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Cc: Liming Gao 
Cc: Jaben Carsey 
Cc: Steven Shi 

Ard Biesheuvel (7):
  MdeModulePkg: introduce PE/COFF image emulator protocol
  MdeModulePkg/DxeCore: invoke the emulator protocol for foreign images
  MdeModulePkg/PciBusDxe: dispatch option ROMs for foreign architectures
  MdeModulePkg/UefiBootManagerLib: allow foreign Driver images
  MdeModulePkg/EbcDxe: implement the PE/COFF emulator protocol
  MdePkg/UefiBaseType.h: treat EBC as a non-native machine type
  MdeModulePkg/DxeCore: remove explicit EBC handling

 .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   |   7 -
 MdeModulePkg/Core/Dxe/DxeMain.h   |   6 +-
 MdeModulePkg/Core/Dxe/DxeMain.inf |   2 +-
 MdeModulePkg/Core/Dxe/Image/Image.c   | 183 --
 .../Include/Protocol/PeCoffImageEmulator.h| 107 ++
 .../Library/UefiBootManagerLib/BmLoadOption.c |   6 +-
 MdeModulePkg/MdeModulePkg.dec |   4 +
 MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf |   3 +
 MdeModulePkg/Universal/EbcDxe/EbcDxe.inf  |   3 +
 MdeModulePkg/Universal/EbcDxe/EbcInt.c| 123 
 MdeModulePkg/Universal/EbcDxe/EbcInt.h|   3 +
 MdePkg/Include/Uefi/UefiBaseType.h|   6 +-
 12 files changed, 381 insertions(+), 72 deletions(-)
 create mode 100644 MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h

-- 
2.17.1

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


[edk2] [PATCH v4 3/7] MdeModulePkg/PciBusDxe: dispatch option ROMs for foreign architectures

2019-03-31 Thread Ard Biesheuvel
Delete the explicit machine type check for option ROM images, and instead,
rely on the LoadImage() boot service to decide whether an option ROM can
be dispatched or not. This permits platforms to ship with emulators to
execute option ROMs that are not native to the processor architecture.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
index c75ef1a82505..54cf4251cc86 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
@@ -699,13 +699,6 @@ ProcessOpRomImage (
   goto NextImage;
 }
 
-//
-// Skip the EFI PCI Option ROM image if its machine type is not supported
-//
-if (!EFI_IMAGE_MACHINE_TYPE_SUPPORTED (EfiRomHeader->EfiMachineType)) {
-  goto NextImage;
-}
-
 //
 // Ignore the EFI PCI Option ROM image if it is an EFI application
 //
-- 
2.17.1

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


Re: [edk2] [PATCH edk2-non-osi] Platform/DeveloperBox: add binary build of TF-A + standalone MM varstore

2019-03-29 Thread Ard Biesheuvel
On Fri, 29 Mar 2019 at 11:06, Leif Lindholm  wrote:
>
> On Fri, Mar 29, 2019 at 10:52:41AM +0100, Ard Biesheuvel wrote:
> > On Fri, 29 Mar 2019 at 09:57, Leif Lindholm  
> > wrote:
> > >
> > > On Fri, Mar 29, 2019 at 08:46:12AM +0100, Ard Biesheuvel wrote:
> > > > Provide a prebuilt binary of the standalone MM payload containing the
> > > > UEFI authenticated variable store drivers. These are built from EDK2
> > > > components, but the resulting image needs to be wrapped in a FIP
> > > > container and built into the secure world TF-A image.
> > > >
> > > > TF-A commit:   e86e202c2e4e
> > > > edk2 commit:   8028f0303218
> > > > edk2-platforms commit: 05fdad573966
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Ard Biesheuvel 
> > >
> > > Reviewed-by: Leif Lindholm 
> > >
> >
> > Turns out I need to respin this based on 0a32c15d2172 (just pushed
> > into edk2-platforms).
>
> Right. Well, the reviewed-by stands, as long as the hash gets updated.
>

Cheers. Pushed as 99907896565e..d04196e99696
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-non-osi] Platform/DeveloperBox: add binary build of TF-A + standalone MM varstore

2019-03-29 Thread Ard Biesheuvel
On Fri, 29 Mar 2019 at 09:57, Leif Lindholm  wrote:
>
> On Fri, Mar 29, 2019 at 08:46:12AM +0100, Ard Biesheuvel wrote:
> > Provide a prebuilt binary of the standalone MM payload containing the
> > UEFI authenticated variable store drivers. These are built from EDK2
> > components, but the resulting image needs to be wrapped in a FIP
> > container and built into the secure world TF-A image.
> >
> > TF-A commit:   e86e202c2e4e
> > edk2 commit:   8028f0303218
> > edk2-platforms commit: 05fdad573966
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
>
> Reviewed-by: Leif Lindholm 
>

Turns out I need to respin this based on 0a32c15d2172 (just pushed
into edk2-platforms).
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms 2/2] Platform/Socionext/DeveloperBox: align with upstream StandaloneMmPkg changes

2019-03-29 Thread Ard Biesheuvel
On Fri, 29 Mar 2019 at 09:56, Leif Lindholm  wrote:
>
> On Fri, Mar 29, 2019 at 08:32:31AM +0100, Ard Biesheuvel wrote:
> > On Fri, 8 Mar 2019 at 16:31, Ard Biesheuvel  
> > wrote:
> > >
> > > Bring DeveloperBox in line with EDK2 core changes to StandaloneMmPkg:
> > > - switch from BaseExtractGuidedSectionLib to PrePiExtractGuidedSectionLib
> > > - include a NULL library class resolution for VariableMmDependency
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel 
> >
> > Leif,
> >
> > I'd like to merge this today if you don't have any objections.
>
> None - that was implied in
> https://lists.01.org/pipermail/edk2-devel/2019-March/038167.html
>
> (There wasn't a 0/2 to put a "for series" on.)
>

Ah, my bad

Pushed as 05fdad573966..0a32c15d2172
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH edk2-non-osi] Platform/DeveloperBox: add binary build of TF-A + standalone MM varstore

2019-03-29 Thread Ard Biesheuvel
Provide a prebuilt binary of the standalone MM payload containing the
UEFI authenticated variable store drivers. These are built from EDK2
components, but the resulting image needs to be wrapped in a FIP
container and built into the secure world TF-A image.

TF-A commit:   e86e202c2e4e
edk2 commit:   8028f0303218
edk2-platforms commit: 05fdad573966

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/Socionext/DeveloperBox/fip_all_arm_tf_mm.bin | Bin 0 -> 374776 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/Platform/Socionext/DeveloperBox/fip_all_arm_tf_mm.bin 
b/Platform/Socionext/DeveloperBox/fip_all_arm_tf_mm.bin
new file mode 100644
index ..eaae94874d4d
Binary files /dev/null and 
b/Platform/Socionext/DeveloperBox/fip_all_arm_tf_mm.bin differ
-- 
2.20.1

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


Re: [edk2] [PATCH edk2-platforms 2/2] Platform/Socionext/DeveloperBox: align with upstream StandaloneMmPkg changes

2019-03-29 Thread Ard Biesheuvel
On Fri, 8 Mar 2019 at 16:31, Ard Biesheuvel  wrote:
>
> Bring DeveloperBox in line with EDK2 core changes to StandaloneMmPkg:
> - switch from BaseExtractGuidedSectionLib to PrePiExtractGuidedSectionLib
> - include a NULL library class resolution for VariableMmDependency
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Leif,

I'd like to merge this today if you don't have any objections.

> ---
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc   | 5 -
>  Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc | 7 +++
>  2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> index 31afc4aac3c4..39077ab5ee79 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> @@ -293,7 +293,10 @@
>VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
>}
>  !else
> -  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> +  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
> +
> +  
> NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
> +  }
>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
>
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
>  !endif
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc 
> b/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
> index 55c5fbb7350d..141b175047b2 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
> @@ -68,9 +68,6 @@
>  [PcdsFixedAtBuild]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x5104
>
> -[PcdsPatchableInModule]
> -  gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|0x0
> -
>  
> 
>  #
>  # Components Section - list of all EDK II Modules needed by this Platform
> @@ -82,8 +79,10 @@
>#
>StandaloneMmPkg/Core/StandaloneMmCore.inf {
>  
> -  
> ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
> +  
> ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
>
> NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> +
> +  gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
>}
>
>StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

2019-03-28 Thread Ard Biesheuvel
On Thu, 28 Mar 2019 at 11:46, Ryszard Knop  wrote:
>
> On Wed, 2019-03-27 at 16:32 +0100, Ard Biesheuvel wrote:
> > On Tue, 29 Jan 2019 at 14:55, Ryszard Knop <
> > ryszard.k...@linux.intel.com> wrote:
> > > +Team
> > >
> >
> > As it turns out, this driver is still broken for non-1:1 mapped DMA.
> >
> > In particular, I am hitting a crash on
> >
> >   E1000MemCopy (
> > (UINT8 *) (UINTN) CpbReceive->BufferAddr,
> > (UINT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
> > TempLen
> >   );
> >
> > (around line 676 in e1000.c), which uses the DMA address
> > 'ReceiveDescriptor->buffer_addr' in a memory copy operation performed
> > by the CPU. This causes a crash on systems where the DMA address is
> > not also a valid CPU address.
>
> Huh, this is new... I don't have access to any system behaving this
> way, so I can't test this, but E1000.c -> E1000TxRxConfigure links
> RxDesc->buffer_addr to the physical addresses, that descriptor is used
> by the hardware to DMA data where needed, and we try to copy from that
> same physical address later, while we should copy from unmapped
> addresses instead.
>

Indeed.

> This probably should be solved by having a separate array/something
> with CurRxInd -> unmapped addresses, but I'll have to talk with my team
> to solve this in a sensible way.
>
> In the meantime, maybe you know if there's a way to simulate this
> situation under QEMU or something?
>

I am using an arm64 board with modified firmware to emulate different
PCIe host bridge configurations. I don't know whether QEMU has support
for non-1:1 mapped DMA on x86, but it does emulate various boards
(such as the raspberry pi 2 iirc) where the CPU and device addressing
is not 1:1.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

2019-03-27 Thread Ard Biesheuvel
On Tue, 29 Jan 2019 at 14:55, Ryszard Knop  wrote:
>
> +Team
>

As it turns out, this driver is still broken for non-1:1 mapped DMA.

In particular, I am hitting a crash on

  E1000MemCopy (
(UINT8 *) (UINTN) CpbReceive->BufferAddr,
(UINT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
TempLen
  );

(around line 676 in e1000.c), which uses the DMA address
'ReceiveDescriptor->buffer_addr' in a memory copy operation performed
by the CPU. This causes a crash on systems where the DMA address is
not also a valid CPU address.





> On Tue, 2019-01-29 at 14:13 +0100, Ryszard Knop wrote:
> > Hi Ard,
> >
> > I've finally got some time to review and merge all of this. A bit
> > problematic thing is that we internally have a separate tree that we
> > need to merge those commits into, then generate the open source tree
> > and related commits from that. This will result in somewhat broken
> > history, so sorry about that in advance - we're still figuring out
> > the
> > proper way to handle multiple source trees on our end without messing
> > it up. I'll push these changes to edk2-staging once we've got it all
> > ready.
> >
> > On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> > > This series fixes the GigUndiDxe in the edk2-staging/Intel_UNDI
> > > branch
> > > at github.com/tianocore so it can be built with GCC on Linux for
> > > ARM
> > > and AARCH64 (as well as X64)
> > >
> > > Ard Biesheuvel (19):
> > >   IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported
> > > architectures
> > >   IntelUndiPkg: remove EOF markers
> > >   IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in
> > > filenames
> > >   IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path
> > > separators
> > >   IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration after type
> > > definition
> > >   IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts for
> > > pointers
> > >   IntelUndiPkg/GigUndiDxe: create GCC alternatives for MSFT build
> > > options
> > >   IntelUndiPkg/GigUndiDxe: add missing VOID** cast
> > >   IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
> > >   IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals
> > >   IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP token pasting
> > >   IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct
> > > pointer
> > > type
> > >   IntelUndiPkg/GigUndiDxe: don't take address of cast expression
> > >   IntelUndiPkg/GigUndiDxe: redefine UNREFERENCED_nPARAMETER macros
> > > for
> > > GCC
> > >   IntelUndiPkg/GigUndiDxe: remove forward declaration of non-
> > > existent
> > > function
> > >   IntelUndiPkg/GigUndiDxe: fix incorrect indentation
> > >   IntelUndiPkg/GigUndiDxe: move MSFT warning overrides to INF file
> > >   IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers
> > >   IntelUndiPkg/GigUndiDxe: remove or reorganize unused variables
> > >
> > >  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  |  6 ++-
> > >  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  |  1 -
> > >  IntelUndiPkg/GigUndiDxe/Brand.c   |  1 -
> > >  IntelUndiPkg/GigUndiDxe/ComponentName.c   |  5 ++-
> > >  IntelUndiPkg/GigUndiDxe/ComponentName.h   |  2 +-
> > >  IntelUndiPkg/GigUndiDxe/Decode.c  |  5 +--
> > >  IntelUndiPkg/GigUndiDxe/Decode.h  |  1 -
> > >  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   |  1 -
> > >  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   |  9 ++---
> > >  IntelUndiPkg/GigUndiDxe/Dma.c | 11 +++---
> > >  IntelUndiPkg/GigUndiDxe/Dma.h |  1 -
> > >  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c |  6 ++-
> > >  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h |  1 -
> > >  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 12 +++---
> > >  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   |  1 -
> > >  IntelUndiPkg/GigUndiDxe/DriverHealth.c|  5 ++-
> > >  IntelUndiPkg/GigUndiDxe/EepromConfig.c|  1 -
> > >  IntelUndiPkg/GigUndiDxe/EepromConfig.h|  3 +-
> > >  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 39 +--
> > > 
> > >  IntelUndiPkg/GigUndiDxe/Hii.c | 11 +++---
> > >  IntelUndiPkg/GigUndiDxe/Hii.h |  1 -
> > >  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  |  3 --
> > >  Int

Re: [edk2] [PATCH edk2-platforms] Platform/Hisilicon: update D06 system firmware description

2019-03-27 Thread Ard Biesheuvel
On Tue, 26 Mar 2019 at 21:22, Leif Lindholm  wrote:
>
> Since the D06 port now depends on updated IMP firmware to function
> properly, there needs to be a one-way upgrade path. Upgrade to the
> current state of things must happen via .hpm. Subsequent capsule updates
> cannot be permitted to go below this version.
>
> So update the firmware descriptor to Version: 3 and
> LowestSupportedFirmwareVersion: 3.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 

Acked-by: Ard Biesheuvel 

> ---
>
> Ming: I would also be cherry-picking this patch into RPF 19.03.
>
>  
> Platform/Hisilicon/D06/Drivers/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
>  | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git 
> a/Platform/Hisilicon/D06/Drivers/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
>  
> b/Platform/Hisilicon/D06/Drivers/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
> index 36175338dd..1287dfd834 100644
> --- 
> a/Platform/Hisilicon/D06/Drivers/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
> +++ 
> b/Platform/Hisilicon/D06/Drivers/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
> @@ -22,9 +22,9 @@
>  #define PACKAGE_VERSION 0x
>  #define PACKAGE_VERSION_STRING  L"Unknown"
>
> -#define CURRENT_FIRMWARE_VERSION0x0002
> -#define CURRENT_FIRMWARE_VERSION_STRING L"0x0002"
> -#define LOWEST_SUPPORTED_FIRMWARE_VERSION   0x0001
> +#define CURRENT_FIRMWARE_VERSION0x0003
> +#define CURRENT_FIRMWARE_VERSION_STRING L"0x0003"
> +#define LOWEST_SUPPORTED_FIRMWARE_VERSION   0x0003
>
>  #define IMAGE_IDSIGNATURE_64('H','W','A', 'R', 
> 'M', '_', 'F', 'd')
>  #define IMAGE_ID_STRING L"ARMPlatformFd"
> --
> 2.11.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH V4 08/17] ArmPkg/SemiHostingDebugLib: Add new APIs

2019-03-26 Thread Ard Biesheuvel
On Tue, 26 Mar 2019 at 13:19, Leif Lindholm  wrote:
>
> Hi Zhichao,
>
> Apologies for delay in responding, due to holiday and stuff.
>
> On the whole this looks fine (one comment below), but I don't actually
> have any platform on which to test this.
>
> Ard: maybe it's time to retire this component?
>

I don't have a problem with that. Adding Eugene, perhaps he has an
opinion as well.


> On Thu, Mar 21, 2019 at 10:04:50PM +0800, Zhichao Gao wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
> >
> > Add new APIs' implementation (DebugVPrint, DebugBPrint)
> > in the DebugLib instance. These APIs would expose print
> > routines with VaList parameter and BaseList parameter.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Zhichao Gao 
> > Cc: Leif Lindholm 
> > Cc: Ard Biesheuvel 
> > Cc: Liming Gao 
> > Cc: Sean Brogan 
> > Cc: Michael Turner 
> > Cc: Bret Barkelew 
> > ---
> >  ArmPkg/Library/SemiHostingDebugLib/DebugLib.c | 106 
> > --
> >  1 file changed, 101 insertions(+), 5 deletions(-)
> >
> > diff --git a/ArmPkg/Library/SemiHostingDebugLib/DebugLib.c 
> > b/ArmPkg/Library/SemiHostingDebugLib/DebugLib.c
> > index ec03edb774..a368dd43b8 100644
> > --- a/ArmPkg/Library/SemiHostingDebugLib/DebugLib.c
> > +++ b/ArmPkg/Library/SemiHostingDebugLib/DebugLib.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >UEFI Debug Library that uses PrintLib to send messages to STDERR.
> >
> > -  Copyright (c) 2006 - 2007, Intel Corporation. All rights reserved.
> > +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> >Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of the 
> > BSD License
> > @@ -27,6 +27,12 @@
> >  //
> >  #define MAX_DEBUG_MESSAGE_LENGTH  0x100
> >
> > +//
> > +// VA_LIST can not initialize to NULL for all compiler, so we use this to
> > +// indicate a null VA_LIST
> > +//
> > +VA_LIST mVaListNull;
>
> I would prefer if this was marked STATIC.
>
> If you feel strongly otherwise, leave it as is.
> Either way:
> Reviewed-by: Leif Lindholm 
>
> /
> Leif
>
> > +
> >  /**
> >
> >Prints a debug message to the debug output device if the specified error 
> > level is enabled.
> > @@ -48,9 +54,41 @@ DebugPrint (
> >IN  CONST CHAR8  *Format,
> >...
> >)
> > +{
> > +  VA_LIST Marker;
> > +
> > +  VA_START (Marker, Format);
> > +  DebugVPrint (ErrorLevel, Format, Marker);
> > +  VA_END (Marker);
> > +}
> > +
> > +
> > +/**
> > +  Prints a debug message to the debug output device if the specified
> > +  error level is enabled base on Null-terminated format string and a
> > +  VA_LIST argument list or a BASE_LIST argument list.
> > +
> > +  If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> > +  GetDebugPrintErrorLevel (), then print the message specified by Format 
> > and
> > +  the associated variable argument list to the debug output device.
> > +
> > +  If Format is NULL, then ASSERT().
> > +
> > +  @param  ErrorLevel  The error level of the debug message.
> > +  @param  Format  Format string for the debug message to print.
> > +  @param  VaListMarkerVA_LIST marker for the variable argument list.
> > +  @param  BaseListMarker  BASE_LIST marker for the variable argument list.
> > +
> > +**/
> > +VOID
> > +DebugPrintMarker (
> > +  IN  UINTN ErrorLevel,
> > +  IN  CONST CHAR8   *Format,
> > +  IN  VA_LIST   VaListMarker,
> > +  IN  BASE_LIST BaseListMarker
> > +  )
> >  {
> >CHAR8AsciiBuffer[MAX_DEBUG_MESSAGE_LENGTH];
> > -  VA_LIST  Marker;
> >
> >//
> >// If Format is NULL, then ASSERT().
> > @@ -67,14 +105,72 @@ DebugPrint (
> >//
> >// Convert the DEBUG() message to a Unicode String
> >//
> > -  VA_START (Marker, Format);
> > -  AsciiVSPrint (AsciiBuffer, sizeof (AsciiBuffer), Format, Marker);
> > -  VA_END (Marker);
> > +  if (BaseListMarker == NULL) {
> > +AsciiVSPrint (AsciiBuffer, sizeof (AsciiBuffer), Format, VaListMarker);
> > +  } else {
> > +AsciiBSPrint (AsciiBuffer, sizeof (AsciiBuffer), Format, 
> > BaseListMarker);
> > +  }
> >
> >SemihostWrit

Re: [edk2] [PATCH] OvmfPkg: retire "create-release.py"

2019-03-25 Thread Ard Biesheuvel
On Mon, 25 Mar 2019 at 14:24, Laszlo Ersek  wrote:
>
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1653
>
> "create-release.py" generates a 2-BSDL copyright block that will no longer
> apply once we fix <https://bugzilla.tianocore.org/show_bug.cgi?id=1373>.
>
> Rather than update "create-release.py", remove it. We haven't used it in
> several years now, plus source releases of upstream edk2 are now covered
> by the edk2 stable tags
> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II#stable-tags>.
>
> Regarding binary releases of upstream OVMF: OVMF and ArmVirtQemu binaries
> built at the edk2 stable tags are being bundled with upstream QEMU,
> similarly to other firmware that runs on QEMU platforms:
> <https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06148.html>.
> Furthermore, the Xen project has provided its own builds of OVMF and
> ArmVirtXen for a good while now.
>
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 

Acked-by: Ard Biesheuvel 

> ---
>
> Notes:
> Repo:   https://github.com/lersek/edk2.git
> Branch: retire_create_release
>
>  OvmfPkg/create-release.py | 208 
>  1 file changed, 208 deletions(-)
>
> diff --git a/OvmfPkg/create-release.py b/OvmfPkg/create-release.py
> deleted file mode 100755
> index 82d8e7b0a2b8..
> --- a/OvmfPkg/create-release.py
> +++ /dev/null
> @@ -1,208 +0,0 @@
> -#!/usr/bin/python
> -#
> -# Copyright (c) 2010 - 2013, 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
> -# 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.
> -#
> -
> -import os
> -import re
> -import StringIO
> -import subprocess
> -import sys
> -import zipfile
> -
> -is_unix = not sys.platform.startswith('win')
> -
> -if not is_unix:
> -print "This script currently only supports unix-like systems"
> -sys.exit(-1)
> -
> -if os.path.exists('OvmfPkgX64.dsc'):
> -os.chdir('..')
> -
> -if not os.path.exists(os.path.join('OvmfPkg', 'OvmfPkgX64.dsc')):
> -print "OvmfPkg/OvmfPkgX64.dsc doesn't exist"
> -sys.exit(-1)
> -
> -def run_and_capture_output(args, checkExitCode = True):
> -p = subprocess.Popen(args=args, stdout=subprocess.PIPE)
> -stdout = p.stdout.read()
> -ret_code = p.wait()
> -if checkExitCode:
> -assert ret_code == 0
> -return stdout
> -
> -gcc_version = run_and_capture_output(args=('gcc', '--version'))
> -gcc_re = re.compile(r'\s*\S+\s+\([^\)]+?\)\s+(\d+(?:\.\d+)*)(?:\s+.*)?')
> -mo = gcc_re.match(gcc_version)
> -if not mo:
> -print "Unable to find GCC version"
> -sys.exit(-1)
> -gcc_version = map(lambda n: int(n), mo.group(1).split('.'))
> -
> -if 'TOOLCHAIN' in os.environ:
> -TOOLCHAIN = os.environ['TOOLCHAIN']
> -else:
> -assert(gcc_version[0] == 4)
> -minor = max(4, min(7, gcc_version[1]))
> -TOOLCHAIN = 'GCC4' + str(minor)
> -
> -def git_based_version():
> -dir = os.getcwd()
> -if not os.path.exists('.git'):
> -os.chdir('OvmfPkg')
> -stdout = run_and_capture_output(args=('git', 'log',
> -  '-n', '1',
> -  '--abbrev-commit'))
> -regex = re.compile(r'^\s*git-svn-id:\s+\S+@(\d+)\s+[0-9a-f\-]+$',
> -   re.MULTILINE)
> -mo = regex.search(stdout)
> -if mo:
> -version = 'r' + mo.group(1)
> -else:
> -version = stdout.split(None, 3)[1]
> -os.chdir(dir)
> -return version
> -
> -def svn_info():
> -dir = os.getcwd()
> -os.chdir('OvmfPkg')
> -stdout = run_and_capture_output(args=('svn', 'info'))
> -os.chdir(dir)
> -return stdout
> -
> -def svn_based_version():
> -buf = svn_info()
> -revision_re = re.compile('^Revision\:\s*([\da-f]+)$', re.MULTILINE)
> -mo = revision_re.search(buf)
> -assert(mo is not None)
> -return 'r' + mo.group(1)
> -
> -def get_revision():
> -if os.path.exists(os.path.join('OvmfPkg', '.svn')):
> -return svn_based_version()
> -else:
>

Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

2019-03-25 Thread Ard Biesheuvel
On Mon, 25 Mar 2019 at 06:28, Hao Wu  wrote:
>
> The series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_siobus_v2
>
> V2 changes:
> * Introduce a static build flag 'USE_LEGACY_ISA_STACK' in OVMF DSC files
>   for users to select between the ISA driver stacks.
> * V1 patch 2/2 is split into 2 patches in V2. The first one will add the
>   new OVMF SioBusDxe driver and list it in the DSC files. Then second one
>   will add the whole new ISA stack in DSC/FDF files.
>
>
> V1 history:
>
> This series will update the OVMF to stop using the ISA drivers within
> IntelFrameworkModulePkg.
>
> As the replacement, a new OVMF Super I/O bus driver has been add which
> will install the Super I/O protocol for ISA serial and PS2 keyboard
> devices. By doing so, these devices can be managed by:
>
>   MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
>   MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
>
> respectively.
>
>
> Tests done:
> A. GCC5 & VS2015x86 tool chains build pass
> B. Launch QEMU (2.4.50, Windows) with command:
>> qemu-system-x86_64.exe -pflash \OVMF.fd -serial file:1.txt 
> -serial file:2.txt
>
>Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under Shell
>using command 'devtree';
>
>    Both the serials and PS2 keyboard are working fine;
>
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Ray Ni 
>
>
> Hao Wu (3):
>   OvmfPkg: Drop the ISA Floppy device support
>   OvmfPkg: Add an Super IO bus driver
>   OvmfPkg: Add a build flag to select ISA driver stack
>

Thanks Hao.

For the series,

Acked-by: Ard Biesheuvel 

but I will leave the final decision to Laszlo.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH V2 1/2] MdeModulePkg/CapsuleRuntimeDxe: IA32 add cache flush function

2019-03-25 Thread Ard Biesheuvel
On Fri, 22 Mar 2019 at 04:09, Zhichao Gao  wrote:
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1462
>
> The IA32 ARCH need cache flush function during capsule update.
> Both arm ARCH and IA32 do not need flush cache function, so
> merge the CapsuleCacheWriteBack() to one file. And add a null
> version for EBC.
>

What is the point of being able to build a DXE_RUNTIME_DRIVER module for EBC?

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Cc: Ard Biesheuvel 
> ---
>  .../Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c | 35 +---
>  .../Universal/CapsuleRuntimeDxe/CapsuleCache.c | 63 
> ++
>  .../Universal/CapsuleRuntimeDxe/CapsuleCacheNull.c | 38 +
>  .../Universal/CapsuleRuntimeDxe/CapsuleReset.c | 16 +-
>  .../CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf| 20 ---
>  5 files changed, 115 insertions(+), 57 deletions(-)
>  create mode 100644 MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleCache.c
>  create mode 100644 
> MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleCacheNull.c
>
> diff --git a/MdeModulePkg/Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c 
> b/MdeModulePkg/Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c
> index d79d2fc693..ec630ab7a8 100644
> --- a/MdeModulePkg/Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c
> +++ b/MdeModulePkg/Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c
> @@ -3,6 +3,7 @@
>PersistAcrossReset capsules
>
>Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +  Copyright (c) 2019, 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 which accompanies this
> @@ -16,8 +17,6 @@
>
>  #include "CapsuleService.h"
>
> -#include 
> -
>  /**
>Whether the platform supports capsules that persist across reset. Note that
>some platforms only support such capsules at boot time.
> @@ -41,35 +40,3 @@ IsPersistAcrossResetCapsuleSupported (
>return FeaturePcdGet (PcdSupportUpdateCapsuleReset) && !EfiAtRuntime ();
>  }
>
> -/**
> -  Writes Back a range of data cache lines covering a set of capsules in 
> memory.
> -
> -  Writes Back the data cache lines specified by ScatterGatherList.
> -
> -  @param  ScatterGatherList Physical address of the data structure that
> -describes a set of capsules in memory
> -
> -**/
> -VOID
> -CapsuleCacheWriteBack (
> -  IN  EFI_PHYSICAL_ADDRESSScatterGatherList
> -  )
> -{
> -  EFI_CAPSULE_BLOCK_DESCRIPTOR*Desc;
> -
> -  Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR *)(UINTN)ScatterGatherList;
> -  do {
> -WriteBackDataCacheRange (Desc, sizeof *Desc);
> -
> -if (Desc->Length > 0) {
> -  WriteBackDataCacheRange ((VOID *)(UINTN)Desc->Union.DataBlock,
> -   Desc->Length
> -   );
> -  Desc++;
> -} else if (Desc->Union.ContinuationPointer > 0) {
> -  Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR 
> *)(UINTN)Desc->Union.ContinuationPointer;
> -}
> -  } while (Desc->Length > 0 || Desc->Union.ContinuationPointer > 0);
> -
> -  WriteBackDataCacheRange (Desc, sizeof *Desc);
> -}
> diff --git a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleCache.c 
> b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleCache.c
> new file mode 100644
> index 00..ab81296a65
> --- /dev/null
> +++ b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleCache.c
> @@ -0,0 +1,63 @@
> +/** @file
> +  Flush the cache is required for most architectures while do capsule
> +  update. It is not support at Runtime.
> +
> +  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +  Copyright (c) 2019, 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 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 "CapsuleService.h"
> +
> +#include 
> +
> +/**
> +  Writes Back a range of data cache lines covering a set of capsules in 
> memory.
> +
> +  Writes Back the data cache lines specified by ScatterGatherList.
> +
> +  @param  ScatterGa

Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

2019-03-22 Thread Ard Biesheuvel
On Fri, 22 Mar 2019 at 10:25, Laszlo Ersek  wrote:
>
> On 03/22/19 02:33, Wu, Hao A wrote:
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Friday, March 22, 2019 3:04 AM
> >> To: Ard Biesheuvel; Wu, Hao A
> >> Cc: edk2-devel@lists.01.org; Justen, Jordan L; Ni, Ray
> >> Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within
> >> IntelFrameworkModulePkg
> >>
> >> On 03/21/19 11:08, Ard Biesheuvel wrote:
> >>> On Thu, 21 Mar 2019 at 07:44, Wu, Hao A  wrote:
> >>>>
> >>>>>>>
> >>>>>>> Just a couple of notes from my side - I'm sure Laszlo will have a much
> >>>>>>> longer list :-)
> >>>>>>>
> >>>>>>> - Dropping the floppy driver is fine with me.
> >>>>>>> - What is OVMF specific about this driver? Is it only the hardcoded
> >>>>>>> list of COM1/COM2/PS2 keyboard? If so, should we split this into a
> >>>>>>> driver and a library class, where the driver lives in MdeModulePkg,
> >>>>>>> and the library is implemented in the context of OVMF?
> >>>>>>
> >>>>>> Hello Ard,
> >>>>>>
> >>>>>> I think the special thing for this one is that:
> >>>>>> For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I
> >>>>>> know, the SIO chip exists on other platforms. The driver proposed here
> >>>>>> simulates the behavior of an SIO chip. IMO, if we find more platforms
> >> that
> >>>>>> do not have a SIO chip, we can convert the driver into a general one.
> >>>>>>
> >>>>>> Also, for the implementation of the services in the Super I/O protocol,
> >>>>>> the proposed driver just does the minimal effort in order to support 
> >>>>>> the
> >>>>>> serial/PS2 keyboard.
> >>>>>
> >>>>> Here's why I'd like the majority of this driver to live under
> >>>>> MdeModulePkg (for example through a lib class separation like Ard
> >> suggests):
> >>>>>
> >>>>> Because then its maintenance would not be the responsibility of OvmfPkg
> >>>>> maintainers.
> >>>>>
> >>>>> Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the
> >>>>> minimal effort in order to support the serial/PS2 keyboard".
> >>>>>
> >>>>> The risk of regressions is extreme (the PS/2 keyboard is the default
> >>>>> one, and if it breaks *subtly*, almost all users will be inconvenienced,
> >>>>> but not necessarily soon enough for us to get reports about it *early*
> >>>>> in the current development cycle).
> >>>>>
> >>>>> I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned
> >>>>> upon nowadays, they may be ugly / platform specific / etc etc etc, but
> >>>>> they have also proved themselves to *work*, and (as far as I remember)
> >>>>> they have required practically zero fixes in order to function well on 
> >>>>> QEMU.
> >>>>>
> >>>>> It is very unwelcome by me to take on the maintenance burden for a
> >>>>> driver that is all of:
> >>>>> - not widely tested,
> >>>>> - replacing a proven set of drivers that is critical to users,
> >>>>> - large.
> >>>>>
> >>>>> I understand that Intel wants to stop maintaining
> >>>>> IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for
> >> me.
> >>>>>
> >>>>> Compare the case if we simply moved the
> >>>>> IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg:
> >>>>> - still large,
> >>>>> - but widely tested (with minimal churn in the past),
> >>>>> - and no risk of regressions.
> >>>>>
> >>>>> So in this form, I'm generally opposed to the switch. The two sets of
> >>>>> drivers need to coexist for a while, and we must expose the new drivers
> >>>>> to users while providing them with some sort of easy fallback. (I'd
> >>>>> prefer that fallback to be dynamically configurable, but, 

Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

2019-03-21 Thread Ard Biesheuvel
On Thu, 21 Mar 2019 at 07:44, Wu, Hao A  wrote:
>
> > >>
> > >> Just a couple of notes from my side - I'm sure Laszlo will have a much
> > >> longer list :-)
> > >>
> > >> - Dropping the floppy driver is fine with me.
> > >> - What is OVMF specific about this driver? Is it only the hardcoded
> > >> list of COM1/COM2/PS2 keyboard? If so, should we split this into a
> > >> driver and a library class, where the driver lives in MdeModulePkg,
> > >> and the library is implemented in the context of OVMF?
> > >
> > > Hello Ard,
> > >
> > > I think the special thing for this one is that:
> > > For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I
> > > know, the SIO chip exists on other platforms. The driver proposed here
> > > simulates the behavior of an SIO chip. IMO, if we find more platforms that
> > > do not have a SIO chip, we can convert the driver into a general one.
> > >
> > > Also, for the implementation of the services in the Super I/O protocol,
> > > the proposed driver just does the minimal effort in order to support the
> > > serial/PS2 keyboard.
> >
> > Here's why I'd like the majority of this driver to live under
> > MdeModulePkg (for example through a lib class separation like Ard suggests):
> >
> > Because then its maintenance would not be the responsibility of OvmfPkg
> > maintainers.
> >
> > Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the
> > minimal effort in order to support the serial/PS2 keyboard".
> >
> > The risk of regressions is extreme (the PS/2 keyboard is the default
> > one, and if it breaks *subtly*, almost all users will be inconvenienced,
> > but not necessarily soon enough for us to get reports about it *early*
> > in the current development cycle).
> >
> > I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned
> > upon nowadays, they may be ugly / platform specific / etc etc etc, but
> > they have also proved themselves to *work*, and (as far as I remember)
> > they have required practically zero fixes in order to function well on QEMU.
> >
> > It is very unwelcome by me to take on the maintenance burden for a
> > driver that is all of:
> > - not widely tested,
> > - replacing a proven set of drivers that is critical to users,
> > - large.
> >
> > I understand that Intel wants to stop maintaining
> > IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for me.
> >
> > Compare the case if we simply moved the
> > IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg:
> > - still large,
> > - but widely tested (with minimal churn in the past),
> > - and no risk of regressions.
> >
> > So in this form, I'm generally opposed to the switch. The two sets of
> > drivers need to coexist for a while, and we must expose the new drivers
> > to users while providing them with some sort of easy fallback. (I'd
> > prefer that fallback to be dynamically configurable, but, again, if your
> > keyboard breaks, how do you interact with e.g. the UEFI shell? So I
> > guess a static build flag would do as well.) I think the old drivers
>
> Hello Laszlo,
>
> I agree with your point. So your suggestion is to:
>
> 1. Duplicate the below drivers into OvmfPkg:
>   PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
>   IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
>   IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
>   IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
>
> 2. Meanwhile, add the proposed SioBusDxe driver in the OvmfPkg as well
>
> 3. Add a static build flag within OvmfPkg to let users choose between:
>a) New OVMF SioBusDxe driver + ISA device drivers under
>   MdeModulePkg/Bus/Isa;
>b) Legacy ISA stack copied from PcAtChipsetPkg & IntelFrameworkModulePkg
>
> Is my understanding correct?
>
> > should be removed only in the edk2 stable tag that comes *after* the
> > next one, once we've given the drivers enough time to "prove themselves".
>
> Do you mean we should keep the copy of the legacy ISA stack from
> PcAtChipsetPkg & IntelFrameworkModulePkg until the announcement of
> edk2-stable201905 tag?
>

I think we should just keep the IntelFrameworkModulePkg components in
place until we are ready to stop using them in OVMF. Cloning them into
OvmfPkg now just so we can remove IntelFrameworkModulePkg in its
entirety has little added value IMO.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 1/2] MdeModulePkg/CapsuleRuntimeDxe: Merge changes form arm to all ARCH

2019-03-20 Thread Ard Biesheuvel
On Wed, 20 Mar 2019 at 02:43, Zhichao Gao  wrote:
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1462
>
> The arm ARCH has already to add a function CapsuleCacheWriteBack to
> flush the cache data to DRAM. That is also required in IA32 ARCH. So
> merge the changes. And this function do not support in runtime phase.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 

After this patch, platforms may return TRUE from
QueryCapsuleCapabilities() while they returned FALSE before, i.e., at
runtime. This behavior change will surely break ARM, but I don't see
how it doesn't break IA32 as well if it now relies on this cache
maintenance to occur in the context of UpdateCapsule().



> ---
>  .../Universal/CapsuleRuntimeDxe/CapsuleReset.c | 21 
>  .../{Arm/CapsuleReset.c => CapsuleResetNull.c} | 29 
> +++---
>  .../CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf| 14 +--
>  3 files changed, 30 insertions(+), 34 deletions(-)
>  rename MdeModulePkg/Universal/CapsuleRuntimeDxe/{Arm/CapsuleReset.c => 
> CapsuleResetNull.c} (51%)
>
> diff --git a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleReset.c 
> b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleReset.c
> index 353f6f2090..8c45f6665e 100644
> --- a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleReset.c
> +++ b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleReset.c
> @@ -16,6 +16,8 @@
>
>  #include "CapsuleService.h"
>
> +#include 
> +
>  /**
>Whether the platform supports capsules that persist across reset. Note that
>some platforms only support such capsules at boot time.
> @@ -46,4 +48,23 @@ CapsuleCacheWriteBack (
>IN  EFI_PHYSICAL_ADDRESSScatterGatherList
>)
>  {
> +  EFI_CAPSULE_BLOCK_DESCRIPTOR*Desc;
> +
> +  if (!EfiAtRuntime()) {
> +Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR *)(UINTN)ScatterGatherList;
> +do {
> +  WriteBackDataCacheRange (Desc, sizeof *Desc);
> +
> +  if (Desc->Length > 0) {
> +WriteBackDataCacheRange ((VOID *)(UINTN)Desc->Union.DataBlock,
> + Desc->Length
> + );
> +Desc++;
> +  } else if (Desc->Union.ContinuationPointer > 0) {
> +Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR 
> *)(UINTN)Desc->Union.ContinuationPointer;
> +  }
> +} while (Desc->Length > 0 || Desc->Union.ContinuationPointer > 0);
> +
> +WriteBackDataCacheRange (Desc, sizeof *Desc);
> +  }
>  }
> diff --git a/MdeModulePkg/Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c 
> b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleResetNull.c
> similarity index 51%
> rename from MdeModulePkg/Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c
> rename to MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleResetNull.c
> index d79d2fc693..3c5cfc1a16 100644
> --- a/MdeModulePkg/Universal/CapsuleRuntimeDxe/Arm/CapsuleReset.c
> +++ b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleResetNull.c
> @@ -1,8 +1,9 @@
>  /** @file
> -  ARM implementation of architecture specific routines related to
> +  Default implementation of architecture specific routines related to
>PersistAcrossReset capsules
>
>Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +  Copyright (c) 2019, 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 which accompanies this
> @@ -31,14 +32,7 @@ IsPersistAcrossResetCapsuleSupported (
>VOID
>)
>  {
> -  //
> -  // ARM requires the capsule payload to be cleaned to the point of coherency
> -  // (PoC), but only permits doing so using cache maintenance instructions 
> that
> -  // operate on virtual addresses. Since at runtime, we don't know the 
> virtual
> -  // addresses of the data structures that make up the scatter/gather list, 
> we
> -  // cannot perform the maintenance, and all we can do is give up.
> -  //
> -  return FeaturePcdGet (PcdSupportUpdateCapsuleReset) && !EfiAtRuntime ();
> +  return FeaturePcdGet (PcdSupportUpdateCapsuleReset);
>  }
>
>  /**
> @@ -55,21 +49,4 @@ CapsuleCacheWriteBack (
>IN  EFI_PHYSICAL_ADDRESSScatterGatherList
>)
>  {
> -  EFI_CAPSULE_BLOCK_DESCRIPTOR*Desc;
> -
> -  Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR *)(UINTN)ScatterGatherList;
> -  do {
> -WriteBackDataCacheRange (Desc, sizeof *Desc);
> -
> -if (Desc->Length > 0) {
> -  WriteBackDataCacheRange ((VOID *)(UINTN)Desc->Union.DataBlock,
> -   Desc->Length
> -   );
> -  Desc++;
> -} else if (Desc->Union.ContinuationPointer > 0) {
> -  Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR 
> *)(UINTN)Desc->Union.ContinuationPointer;
> -}
> -  } while (Desc->Length > 0 || Desc->Union.ContinuationPointer > 0);
> -
> -  WriteBackDataCacheRange (Desc, sizeof *Desc);
>  }
> diff 

Re: [edk2] [PATCH edk2-platforms 0/2] Platforms/ARM/SgiPkg: apply product names for sgiclarka and sgiclarkh platforms

2019-03-15 Thread Ard Biesheuvel
On Fri, 15 Mar 2019 at 13:44, Thomas Abraham  wrote:
>
> On Fri, Mar 15, 2019 at 6:04 PM Ard Biesheuvel
>  wrote:
> >
> > On Fri, 15 Mar 2019 at 13:25, Thomas Abraham  wrote:
> > >
> > > On Fri, Mar 15, 2019 at 5:27 PM Ard Biesheuvel
> > >  wrote:
> > > >
> > > > On Fri, 15 Mar 2019 at 12:40, Jagadeesh Ujja  
> > > > wrote:
> > > > >
> > > > > On Fri, Mar 15, 2019 at 4:55 PM Ard Biesheuvel
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, 15 Mar 2019 at 12:17, Jagadeesh Ujja 
> > > > > >  wrote:
> > > > > > >
> > > > > > > hi Ard,
> > > > > > >
> > > > > > > On Fri, Mar 15, 2019 at 4:14 PM Ard Biesheuvel
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Fri, 15 Mar 2019 at 09:21, Jagadeesh Ujja 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > hi Ard/Leif
> > > > > > > > >
> > > > > > > > > Please let me know if you have any comments on this patch set
> > > > > > > > >
> > > > > > > >
> > > > > > > > HI Jagadeesh,
> > > > > > > >
> > > > > > > > What does RdE1Edge or RdN1Edge mean?
> > > > > > >
> > > > > > > RdE1Edge/RdN1Edge are new product name
> > > > > > > Rd stands for reference design.
> > > > > > >
> > > > > > > The Neoverse E1 Edge Reference Design
> > > > > > > The Neoverse N1 Edge Reference Design
> > > > > > >
> > > > > >
> > > > > > So 'reference design' is the name of the platform based on the
> > > > > > Neoverse E1 and N1, respectively?
> > > > >
> > > > > yes ,
> > > > > 'reference design' is a class of platform, in which we have Neoverse
> > > > > E1/N1 cores support. Going forward other cores can come in
> > > > >
> > > >
> > > > Could we drop the 'edge'? It seems redundant.
> > >
> > > Hi Ard,
> > >
> > > 'edge' here would be required because there is also a 'hyperscale'
> > > class of platform based on N1 cores.
> > > (https://www.anandtech.com/show/13959/arm-announces-neoverse-n1-platform/3).
> > >
> > > >
> > > > I'd prefer it if we could stick with
> > > >
> > > > NeoverseE1
> > > > NeoverseN1
> > > >
> > > > or if the reference design part is relevant
> > > >
> > > > NeoverseE1ReferenceDesign
> > > > NeoverseN1ReferenceDesign
> > >
> > > The ReferenceDesign part is relevant and without which the name would
> > > only indicate the CPU name (NeoverseN1). And so is 'edge' because
> > > there is 'hyperscale' variant as of today and there could be other
> > > variants as well.
> > >
> >
> > Hi Thomas,
> >
> > Thanks for the clarification.
> >
> > So could we go with
> >
> > > > NeoverseE1EdgeReferenceDesign
> > > > NeoverseN1EdgeReferenceDesign
> >
> > instead?
>
> The official product names being used for these two platforms are
> 'RD-N1-Edge' and 'RD-E1-Edge'. So to keep to platform name in line
> with the product name and also to keep it short, 'RdN1Edge' and
> 'RdE1Edge' names are being used in this patch series. Are there any
> limitations in using this shorter name for the platforms.
>

No, I just found them a bit cryptic. But if they are an exact match
with the product names, I don't have any objections.

Reviewed-by: Ard Biesheuvel 

Pushed as 68cc99303e38..a8f34e065815
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v2 3/3] Platform/ARM/SgiPkg: add MM based UEFI secure boot support

2019-03-15 Thread Ard Biesheuvel
On Fri, 15 Mar 2019 at 13:47, Thomas Abraham  wrote:
>
> On Fri, Mar 15, 2019 at 6:12 PM Ard Biesheuvel
>  wrote:
> >
> > On Fri, 15 Mar 2019 at 13:30, Thomas Abraham  wrote:
> > >
> > > On Fri, Mar 15, 2019 at 5:51 PM Ard Biesheuvel
> > >  wrote:
> > > >
> > > > On Tue, 12 Mar 2019 at 17:06, Jagadeesh Ujja  
> > > > wrote:
> > > > >
> > > > > This implements support for UEFI secure boot on SGI platforms using
> > > > > the standalone MM framework. This moves all of the software handling
> > > > > of the UEFI authenticated variable store into the standalone MM
> > > > > context residing in a secure partition.
> > > > >
> > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > Signed-off-by: Jagadeesh Ujja 
> > > > > ---
> > > > >  Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 34 
> > > > > +++-
> > > > >  Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf |  5 +++
> > > > >  Platform/ARM/SgiPkg/SgiPlatform.dsc  | 18 ++-
> > > > >  Platform/ARM/SgiPkg/SgiPlatform.fdf  |  7 +++-
> > > > >  4 files changed, 61 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc 
> > > > > b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > > > > index 49fc919..b6aa90b 100644
> > > > > --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > > > > +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > > > > @@ -26,6 +26,7 @@
> > > > >SKUID_IDENTIFIER   = DEFAULT
> > > > >FLASH_DEFINITION   = 
> > > > > Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
> > > > >DEFINE DEBUG_MESSAGE   = TRUE
> > > > > +  DEFINE SECURE_BOOT_ENABLE  = FALSE
> > > > >
> > > >
> > > > Maybe I wasn't clear before, but I don't see the point of building the
> > > > MM component without secure boot enabled. So can we drop this from
> > > > this side?
> > >
> > > Hi Ard,
> > >
> > > On the SGI platforms, the MM component is used for platform RAS error
> > > handling as well and secure boot is not mandatory in such a build. So
> > > the build of MM component is being kept independent of secure boot.
> > >
> >
> > Hi Thomas,
> >
> > When building the MM side of the platform without secure boot, the
> > only MM modules that are included are
> >
> > > > >INF StandaloneMmPkg/Core/StandaloneMmCore.inf
> > > > >INF 
> > > > > StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
> >
> > neither of which implement RAS handling. So are you saying this is
> > functionality that runs in MM context, but it has not been upstreamed
> > yet?
>
> Hi Ard,
>
> Yes, this functionality is yet to be upstreamed and there is work
> happening in that direction. So the MM build is being kept independent
> of secure boot feature.
>

OK, fair enough.

I will look in more detail once the NorFlashDxe changes are reviewed and merged.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v2 3/3] Platform/ARM/SgiPkg: add MM based UEFI secure boot support

2019-03-15 Thread Ard Biesheuvel
On Fri, 15 Mar 2019 at 13:30, Thomas Abraham  wrote:
>
> On Fri, Mar 15, 2019 at 5:51 PM Ard Biesheuvel
>  wrote:
> >
> > On Tue, 12 Mar 2019 at 17:06, Jagadeesh Ujja  wrote:
> > >
> > > This implements support for UEFI secure boot on SGI platforms using
> > > the standalone MM framework. This moves all of the software handling
> > > of the UEFI authenticated variable store into the standalone MM
> > > context residing in a secure partition.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jagadeesh Ujja 
> > > ---
> > >  Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 34 +++-
> > >  Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf |  5 +++
> > >  Platform/ARM/SgiPkg/SgiPlatform.dsc  | 18 ++-
> > >  Platform/ARM/SgiPkg/SgiPlatform.fdf  |  7 +++-
> > >  4 files changed, 61 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc 
> > > b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > > index 49fc919..b6aa90b 100644
> > > --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > > +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > > @@ -26,6 +26,7 @@
> > >SKUID_IDENTIFIER   = DEFAULT
> > >FLASH_DEFINITION   = 
> > > Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
> > >DEFINE DEBUG_MESSAGE   = TRUE
> > > +  DEFINE SECURE_BOOT_ENABLE  = FALSE
> > >
> >
> > Maybe I wasn't clear before, but I don't see the point of building the
> > MM component without secure boot enabled. So can we drop this from
> > this side?
>
> Hi Ard,
>
> On the SGI platforms, the MM component is used for platform RAS error
> handling as well and secure boot is not mandatory in such a build. So
> the build of MM component is being kept independent of secure boot.
>

Hi Thomas,

When building the MM side of the platform without secure boot, the
only MM modules that are included are

> > >INF StandaloneMmPkg/Core/StandaloneMmCore.inf
> > >INF StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf

neither of which implement RAS handling. So are you saying this is
functionality that runs in MM context, but it has not been upstreamed
yet?



>
> >
> > For the non-secure side, it is a different matter, obviously.
> >
> > ># LzmaF86
> > >DEFINE COMPRESSION_TOOL_GUID   = D42AE6BD-1352-4bfb-909A-CA72A6EAE889
> > > @@ -83,7 +84,17 @@
> > >
> > > HobLib|StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
> > >
> > > MmServicesTableLib|MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
> > >
> > > MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf
> > > -
> > > +!if $(SECURE_BOOT_ENABLE) == TRUE
> > > +  AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
> > > +  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> > > +  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> > > +  
> > > NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
> > > +  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > > +  
> > > PlatformSecureLib|SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> > > +  
> > > SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> > > +  
> > > TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
> > > +  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
> > > +!endif
> > >  
> > > 
> > >  #
> > >  # Pcd Section - list of all EDK II PCD Entries defined by this Platform
> > > @@ -100,6 +111,21 @@
> > >
> > >gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
> > >
> > > +!if $(SECURE_BOOT_ENABLE) == TRUE
> > > +  #Secure Storage
> > > +  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
> > > +  gEfiSecurityPkgTokenSpaceGuid.PcdUserPhysicalPresence|TRUE
> > > +  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
> > > +
> > > +  ## NV Storage - 1MB*3 in NOR2 Flash
> > > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x1040
> > &g

Re: [edk2] [PATCH edk2-platforms 0/2] Platforms/ARM/SgiPkg: apply product names for sgiclarka and sgiclarkh platforms

2019-03-15 Thread Ard Biesheuvel
On Fri, 15 Mar 2019 at 13:25, Thomas Abraham  wrote:
>
> On Fri, Mar 15, 2019 at 5:27 PM Ard Biesheuvel
>  wrote:
> >
> > On Fri, 15 Mar 2019 at 12:40, Jagadeesh Ujja  wrote:
> > >
> > > On Fri, Mar 15, 2019 at 4:55 PM Ard Biesheuvel
> > >  wrote:
> > > >
> > > > On Fri, 15 Mar 2019 at 12:17, Jagadeesh Ujja  
> > > > wrote:
> > > > >
> > > > > hi Ard,
> > > > >
> > > > > On Fri, Mar 15, 2019 at 4:14 PM Ard Biesheuvel
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, 15 Mar 2019 at 09:21, Jagadeesh Ujja 
> > > > > >  wrote:
> > > > > > >
> > > > > > > hi Ard/Leif
> > > > > > >
> > > > > > > Please let me know if you have any comments on this patch set
> > > > > > >
> > > > > >
> > > > > > HI Jagadeesh,
> > > > > >
> > > > > > What does RdE1Edge or RdN1Edge mean?
> > > > >
> > > > > RdE1Edge/RdN1Edge are new product name
> > > > > Rd stands for reference design.
> > > > >
> > > > > The Neoverse E1 Edge Reference Design
> > > > > The Neoverse N1 Edge Reference Design
> > > > >
> > > >
> > > > So 'reference design' is the name of the platform based on the
> > > > Neoverse E1 and N1, respectively?
> > >
> > > yes ,
> > > 'reference design' is a class of platform, in which we have Neoverse
> > > E1/N1 cores support. Going forward other cores can come in
> > >
> >
> > Could we drop the 'edge'? It seems redundant.
>
> Hi Ard,
>
> 'edge' here would be required because there is also a 'hyperscale'
> class of platform based on N1 cores.
> (https://www.anandtech.com/show/13959/arm-announces-neoverse-n1-platform/3).
>
> >
> > I'd prefer it if we could stick with
> >
> > NeoverseE1
> > NeoverseN1
> >
> > or if the reference design part is relevant
> >
> > NeoverseE1ReferenceDesign
> > NeoverseN1ReferenceDesign
>
> The ReferenceDesign part is relevant and without which the name would
> only indicate the CPU name (NeoverseN1). And so is 'edge' because
> there is 'hyperscale' variant as of today and there could be other
> variants as well.
>

Hi Thomas,

Thanks for the clarification.

So could we go with

> > NeoverseE1EdgeReferenceDesign
> > NeoverseN1EdgeReferenceDesign

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


Re: [edk2] [PATCH edk2-platforms v2 3/3] Platform/ARM/SgiPkg: add MM based UEFI secure boot support

2019-03-15 Thread Ard Biesheuvel
On Tue, 12 Mar 2019 at 17:06, Jagadeesh Ujja  wrote:
>
> This implements support for UEFI secure boot on SGI platforms using
> the standalone MM framework. This moves all of the software handling
> of the UEFI authenticated variable store into the standalone MM
> context residing in a secure partition.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja 
> ---
>  Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 34 +++-
>  Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf |  5 +++
>  Platform/ARM/SgiPkg/SgiPlatform.dsc  | 18 ++-
>  Platform/ARM/SgiPkg/SgiPlatform.fdf  |  7 +++-
>  4 files changed, 61 insertions(+), 3 deletions(-)
>
> diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc 
> b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> index 49fc919..b6aa90b 100644
> --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> @@ -26,6 +26,7 @@
>SKUID_IDENTIFIER   = DEFAULT
>FLASH_DEFINITION   = 
> Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
>DEFINE DEBUG_MESSAGE   = TRUE
> +  DEFINE SECURE_BOOT_ENABLE  = FALSE
>

Maybe I wasn't clear before, but I don't see the point of building the
MM component without secure boot enabled. So can we drop this from
this side?

For the non-secure side, it is a different matter, obviously.

># LzmaF86
>DEFINE COMPRESSION_TOOL_GUID   = D42AE6BD-1352-4bfb-909A-CA72A6EAE889
> @@ -83,7 +84,17 @@
>HobLib|StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
>
> MmServicesTableLib|MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
>
> MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf
> -
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
> +  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> +  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> +  
> NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
> +  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +  
> PlatformSecureLib|SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> +  
> SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> +  
> TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
> +  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
> +!endif
>  
> 
>  #
>  # Pcd Section - list of all EDK II PCD Entries defined by this Platform
> @@ -100,6 +111,21 @@
>
>gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
>
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  #Secure Storage
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
> +  gEfiSecurityPkgTokenSpaceGuid.PcdUserPhysicalPresence|TRUE
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
> +
> +  ## NV Storage - 1MB*3 in NOR2 Flash
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x1040
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0010
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x1050
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0010
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x1060
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0010
> +!endif
> +
>  
> ###
>  #
>  # Components Section - list of the modules and components that will be 
> processed by compilation
> @@ -125,6 +151,12 @@
>StandaloneMmPkg/Core/StandaloneMmCore.inf
>
>  [Components.AARCH64]
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
> +  
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
> +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> +!endif
> +
>StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
>
>  
> ###
> diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf 
> b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
> index 810460c..8c05a03 100644
> --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
> +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
> @@ -55,6 +55,11 @@ READ_LOCK_CAP  = TRUE
>  READ_LOCK_STATUS   = TRUE
>
>INF StandaloneMmPkg/Core/StandaloneMmCore.inf
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
> +  INF 
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
> +  INF 

Re: [edk2] [PATCH edk2-platforms 0/2] Platforms/ARM/SgiPkg: apply product names for sgiclarka and sgiclarkh platforms

2019-03-15 Thread Ard Biesheuvel
On Fri, 15 Mar 2019 at 12:40, Jagadeesh Ujja  wrote:
>
> On Fri, Mar 15, 2019 at 4:55 PM Ard Biesheuvel
>  wrote:
> >
> > On Fri, 15 Mar 2019 at 12:17, Jagadeesh Ujja  wrote:
> > >
> > > hi Ard,
> > >
> > > On Fri, Mar 15, 2019 at 4:14 PM Ard Biesheuvel
> > >  wrote:
> > > >
> > > > On Fri, 15 Mar 2019 at 09:21, Jagadeesh Ujja  
> > > > wrote:
> > > > >
> > > > > hi Ard/Leif
> > > > >
> > > > > Please let me know if you have any comments on this patch set
> > > > >
> > > >
> > > > HI Jagadeesh,
> > > >
> > > > What does RdE1Edge or RdN1Edge mean?
> > >
> > > RdE1Edge/RdN1Edge are new product name
> > > Rd stands for reference design.
> > >
> > > The Neoverse E1 Edge Reference Design
> > > The Neoverse N1 Edge Reference Design
> > >
> >
> > So 'reference design' is the name of the platform based on the
> > Neoverse E1 and N1, respectively?
>
> yes ,
> 'reference design' is a class of platform, in which we have Neoverse
> E1/N1 cores support. Going forward other cores can come in
>

Could we drop the 'edge'? It seems redundant.

I'd prefer it if we could stick with

NeoverseE1
NeoverseN1

or if the reference design part is relevant

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


Re: [edk2] [PATCH edk2-platforms v2 0/3] Platform/ARM/SgiPkg: Implement StandaloneMm based secure boot

2019-03-15 Thread Ard Biesheuvel
On Fri, 15 Mar 2019 at 09:19, Jagadeesh Ujja  wrote:
>
> hi Ard/Leif
>
> Please let me know if you have any comments on this patch set
>

I'll have a look, but we need the updated NorFlashDxe in
ArmPlatformPkg before we can merge this anyway.

>
> On Tue, Mar
> On Tue, Mar 12, 2019 at 9:45 PM Jagadeesh Ujja  wrote:
> >
> > Changes since v1:
> > - Addressed all the comments from Ard Biesheuvel.
> >
> > Integrating various pieces together so that the authenticated variable store
> > runs entirely in standalone MM context residing in a secure partition.
> > This primarily involves adding all required library and drivers to platform
> > specific .DSC and .FDF files. This creates separate Nor flash region which
> > is visible to only StandaoneMm drivers, this Nor Flash will co-exist along
> > with general Nor flash region.
> >
> > Jagadeesh Ujja (3):
> >   Platform/ARM/Sgi: define nor2 flash controller memory map
> >   Platform/ARM/Sgi: allow MM_STANDALONE modules to use
> > NorFlashPlatformLib
> >   Platform/ARM/SgiPkg: add MM based UEFI secure boot support
> >
> >  Platform/ARM/SgiPkg/Include/SgiPlatform.h   |  4 ++
> >  Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c   | 63 
> > 
> >  Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf | 33 
> > ++
> >  Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc| 34 
> > ++-
> >  Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf|  5 ++
> >  Platform/ARM/SgiPkg/SgiPlatform.dsc | 18 
> > +-
> >  Platform/ARM/SgiPkg/SgiPlatform.fdf |  7 
> > ++-
> >  7 files changed, 161 insertions(+), 3 deletions(-)
> >  create mode 100644 
> > Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
> >  create mode 100644 
> > Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
> >
> > --
> > 2.7.4
> >
> > In-Reply-To:
> >
> > ___
> > 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] SD : Continue setting up sd even if SD_HIGH_SPEED is not supported

2019-03-15 Thread Ard Biesheuvel
On Fri, 22 Feb 2019 at 08:58,  wrote:
>
> From: "Loh, Tien Hock" 
>
> If SD doesn't support SD_HIGH_SPEED, function should still continue to
> setup SD to go into 4 bits more if it is supported.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Loh Tien Hock 

Thanks Tien Hock

Reviewed-by: Ard Biesheuvel 

I tweaked your patch slightly, to fix some whitespace errors, and
downgrade the severity of the 'high speed not supported' message to
DEBUG_INFO

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


Re: [edk2] [PATCH edk2-platforms 0/2] Platforms/ARM/SgiPkg: apply product names for sgiclarka and sgiclarkh platforms

2019-03-15 Thread Ard Biesheuvel
On Fri, 15 Mar 2019 at 12:17, Jagadeesh Ujja  wrote:
>
> hi Ard,
>
> On Fri, Mar 15, 2019 at 4:14 PM Ard Biesheuvel
>  wrote:
> >
> > On Fri, 15 Mar 2019 at 09:21, Jagadeesh Ujja  wrote:
> > >
> > > hi Ard/Leif
> > >
> > > Please let me know if you have any comments on this patch set
> > >
> >
> > HI Jagadeesh,
> >
> > What does RdE1Edge or RdN1Edge mean?
>
> RdE1Edge/RdN1Edge are new product name
> Rd stands for reference design.
>
> The Neoverse E1 Edge Reference Design
> The Neoverse N1 Edge Reference Design
>

So 'reference design' is the name of the platform based on the
Neoverse E1 and N1, respectively?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

2019-03-15 Thread Ard Biesheuvel
On Fri, 15 Mar 2019 at 08:16, Hao Wu  wrote:
>
> This series will update the OVMF to stop using the ISA drivers within
> IntelFrameworkModulePkg.
>
> As the replacement, a new OVMF Super I/O bus driver has been add which
> will install the Super I/O protocol for ISA serial and PS2 keyboard
> devices. By doing so, these devices can be managed by:
>
>   MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
>   MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
>
> respectively.
>

Just a couple of notes from my side - I'm sure Laszlo will have a much
longer list :-)

- Dropping the floppy driver is fine with me.
- What is OVMF specific about this driver? Is it only the hardcoded
list of COM1/COM2/PS2 keyboard? If so, should we split this into a
driver and a library class, where the driver lives in MdeModulePkg,
and the library is implemented in the context of OVMF?
- Regardless of the previous, adding the new driver should be a patch
of its own.
- I spotted an incorrect reference to PCI_IO_DEV in a comment (patch #2)



>
> Tests done:
> A. GCC5 & VS2015x86 tool chains build pass
> B. Launch QEMU (2.4.50, Windows) with command:
>> qemu-system-x86_64.exe -pflash \OVMF.fd -serial file:1.txt 
> -serial file:2.txt
>
>Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under Shell
>using command 'devtree';
>
>Both the serials and PS2 keyboard are working fine;
>
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Ray Ni 
>
> Hao Wu (2):
>   OvmfPkg: Drop the ISA Floppy device support
>   OvmfPkg: Add an Super IO bus driver to replace the current ISA support
>
>  OvmfPkg/OvmfPkgIa32.dsc   |  10 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc|  10 +-
>  OvmfPkg/OvmfPkgX64.dsc|  10 +-
>  OvmfPkg/OvmfPkgIa32.fdf   |  10 +-
>  OvmfPkg/OvmfPkgIa32X64.fdf|  10 +-
>  OvmfPkg/OvmfPkgX64.fdf|  10 +-
>  OvmfPkg/SioBusDxe/SioBusDxe.inf   |  54 ++
>  OvmfPkg/SioBusDxe/SioBusDxe.h | 332 +++
>  OvmfPkg/SioBusDxe/SioService.h| 221 +++
>  OvmfPkg/SioBusDxe/ComponentName.c | 167 ++
>  OvmfPkg/SioBusDxe/SioBusDxe.c | 622 
>  OvmfPkg/SioBusDxe/SioService.c| 405 +
>  OvmfPkg/SioBusDxe/SioBusDxe.uni   |  21 +
>  13 files changed, 1846 insertions(+), 36 deletions(-)
>  create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.inf
>  create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.h
>  create mode 100644 OvmfPkg/SioBusDxe/SioService.h
>  create mode 100644 OvmfPkg/SioBusDxe/ComponentName.c
>  create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.c
>  create mode 100644 OvmfPkg/SioBusDxe/SioService.c
>  create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.uni
>
> --
> 2.12.0.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms 0/2] Platforms/ARM/SgiPkg: apply product names for sgiclarka and sgiclarkh platforms

2019-03-15 Thread Ard Biesheuvel
On Fri, 15 Mar 2019 at 09:21, Jagadeesh Ujja  wrote:
>
> hi Ard/Leif
>
> Please let me know if you have any comments on this patch set
>

HI Jagadeesh,

What does RdE1Edge or RdN1Edge mean?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 0/4] MdeModulePkg, StandaloneMmPkg: work around VA vs PA ambiguity

2019-03-15 Thread Ard Biesheuvel
On Fri, 15 Mar 2019 at 03:17, Wu, Hao A  wrote:
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Monday, March 11, 2019 11:36 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel; Wang, Jian J; Wu, Hao A; Zeng, Star; Kinney, Michael D;
> > Gao, Liming; Achin Gupta; Yao, Jiewen; Supreeth Venkatesh; Jagadeesh Ujja
> > Subject: [PATCH 0/4] MdeModulePkg, StandaloneMmPkg: work around VA
> > vs PA ambiguity
> >
> > This series proposes one possible approach to work around the issue that the
> > traditional MM and standalone MM implement versions of the communicate
> > protocol
> > that are fundamentally incompatible from the point of view of the caller.
> >
> > In traditional MM, the MM communicate protocol takes a physical pointer for
> > the buffer, so that the SMM execution context can access the memory
> > directly
> > without having to translate it according to the translation regime of the
> > caller.
> >
> > In standalone MM, the buffer that is shared with the MM context is
> > preallocated,
> > and so it is up to the implementation of the MM communicate protocol to
> > copy the
> > data from the caller allocated buffer into the preallocated shared buffer. 
> > In
> > order to be able to do so, the DXE driver needs to copy the contents, and 
> > for
> > this it needs to know the virtual address not the physical address.
> >
> > So this means we have two incompatible versions of the same protocol, and
> > given
> > that we have even re-used the EFI_SMM_COMMUNICATE_PROTOCOL GUID
> > for the new
> > EFI_MM_COMMUNICATE_PROTOCOL, we cannot distinguish
> > programmatically between a
> > MM context that takes physical addresses vs one that takes virtual ones.
> >
> > Since this is known at build time, one way to deal with this is to have two
> > different implementations of a library that defines an abstract
> > MmCommunicate()
> > function, allowing the correct implementation to be selected at integration
> > time.
>
> Hello Ard,
>
> It seems to me that for platforms that include the VariableSmmRuntimeDxe
> driver, they need to add the 'MmCommunicateLib' dependency.
>
> Please grant us some time to evaluate this proposal and its impact. We
> will inform you as soon as there is a result. Thanks.
>

Thank you Hao.

Note that we intend to discuss the issue addressed by this series in
the PIWG call, but the next one is at least two weeks away.

So there is no urgency to reviewing this patch for inclusion, but any
feedback you can give is appreciated.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH 4/4] MdeModulePkg/VariableSmmRuntimeDxe: switch to MmCommunicateLib library

2019-03-11 Thread Ard Biesheuvel
Replace direct calls to the EFI_SMM_COMMUNICATE protocol with calls
to the MmCommunicateLib library, which abstracts differences between
traditional MM and standalone MM.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/MdeModulePkg.dsc|  1 +
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf |  4 ++--
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c   | 10 
+++---
 3 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 84c2629d5adc..e8bafaf5007b 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -140,6 +140,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf
+  
MmCommunicateLib|MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
diff --git 
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
index bd73f7ac29f2..53ab1baa7974 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
@@ -56,13 +56,13 @@ [LibraryClasses]
   DebugLib
   UefiRuntimeLib
   DxeServicesTableLib
+  MmCommunicateLib
   UefiDriverEntryPoint
   TpmMeasurementLib
 
 [Protocols]
   gEfiVariableWriteArchProtocolGuid ## PRODUCES
   gEfiVariableArchProtocolGuid  ## PRODUCES
-  gEfiSmmCommunicationProtocolGuid  ## CONSUMES
   ## CONSUMES
   ## NOTIFY
   ## UNDEFINED # Used to do smm communication
@@ -88,7 +88,7 @@ [Guids]
   gEfiImageSecurityDatabaseGuid
 
 [Depex]
-  gEfiSmmCommunicationProtocolGuid
+  TRUE
 
 [UserExtensions.TianoCore."ExtraFiles"]
   VariableSmmRuntimeDxeExtra.uni
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
index 85d655dc19ff..e52913a1eb6f 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
@@ -34,6 +34,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -49,7 +50,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 EFI_HANDLE   mHandle= NULL;
 EFI_SMM_VARIABLE_PROTOCOL   *mSmmVariable   = NULL;
 EFI_EVENTmVirtualAddressChangeEvent = NULL;
-EFI_SMM_COMMUNICATION_PROTOCOL  *mSmmCommunication  = NULL;
 UINT8   *mVariableBuffer= NULL;
 UINT8   *mVariableBufferPhysical= NULL;
 UINTNmVariableBufferSize;
@@ -179,7 +179,7 @@ SendCommunicateBuffer (
   SMM_VARIABLE_COMMUNICATE_HEADER   *SmmVariableFunctionHeader;
 
   CommSize = DataSize + SMM_COMMUNICATE_HEADER_SIZE + 
SMM_VARIABLE_COMMUNICATE_HEADER_SIZE;
-  Status = mSmmCommunication->Communicate (mSmmCommunication, 
mVariableBufferPhysical, );
+  Status = MmCommunicate (mVariableBufferPhysical, mVariableBuffer, );
   ASSERT_EFI_ERROR (Status);
 
   SmmCommunicateHeader  = (EFI_SMM_COMMUNICATE_HEADER *) mVariableBuffer;
@@ -898,7 +898,6 @@ VariableAddressChangeEvent (
   )
 {
   EfiConvertPointer (0x0, (VOID **) );
-  EfiConvertPointer (0x0, (VOID **) );
 }
 
 /**
@@ -954,7 +953,7 @@ GetVariablePayloadSize (
   //
   // Send data to SMM.
   //
-  Status = mSmmCommunication->Communicate (mSmmCommunication, CommBuffer, 
);
+  Status = MmCommunicate (CommBuffer, CommBuffer, );
   ASSERT_EFI_ERROR (Status);
 
   Status = SmmVariableFunctionHeader->ReturnStatus;
@@ -996,9 +995,6 @@ SmmVariableReady (
 return;
   }
 
-  Status = gBS->LocateProtocol (, NULL, (VOID 
**) );
-  ASSERT_EFI_ERROR (Status);
-
   //
   // Allocate memory for variable communicate buffer.
   //
-- 
2.20.1

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


[edk2] [PATCH 3/4] StandaloneMmPkg: add implementation of MmCommunicateLib

2019-03-11 Thread Ard Biesheuvel
Add an implementation of MmCommunicateLib based on standalone MM.
This version passes the virtual address of the communication buffer
into the MM communicate protocol method.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 
StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
 |  51 +
 
StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c 
  | 113 
 
StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.uni
 |  19 
 3 files changed, 183 insertions(+)

diff --git 
a/StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
 
b/StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
new file mode 100644
index ..c29a8618b3c2
--- /dev/null
+++ 
b/StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
@@ -0,0 +1,51 @@
+## @file
+#  Abstraction library for calls to EFI_MM_COMMUNICATE_PROTOCOL::Communicate
+#
+#  Copyright (c) 2019, Linaro 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]
+  INF_VERSION= 0x0001001B
+  BASE_NAME  = RuntimeDxeMmCommunicateLib
+  MODULE_UNI_FILE= RuntimeDxeMmCommunicateLib.uni
+  FILE_GUID  = 15cd7ca8-ca1a-43a2-8f9c-eabbd3e7e5b5
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = MmCommunicateLib|DXE_RUNTIME_DRIVER
+  CONSTRUCTOR= RuntimeDxeMmCommunicateLibConstructor
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = ARM AARCH64 IA32 X64
+#
+
+[Sources]
+  RuntimeDxeMmCommunicateLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+
+[LibraryClasses]
+  DebugLib
+  UefiBootServicesTableLib
+  UefiRuntimeLib
+
+[Guids]
+  gEfiEventVirtualAddressChangeGuid ## CONSUMES ## Event
+
+[Protocols]
+  gEfiMmCommunicationProtocolGuid   ## CONSUMES
+
+[Depex]
+  gEfiMmCommunicationProtocolGuid
diff --git 
a/StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c
 
b/StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c
new file mode 100644
index ..b5a203865360
--- /dev/null
+++ 
b/StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c
@@ -0,0 +1,113 @@
+/** @file
+  Abstraction library for calls to EFI_MM_COMMUNICATE_PROTOCOL::Communicate
+
+  Copyright (c) 2019, Linaro 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.
+
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+STATIC EFI_MM_COMMUNICATION_PROTOCOL*mMmCommunication;
+STATIC EFI_EVENTmVirtualAddressChangeEvent;
+
+/**
+  Invoke the MM communication protocol
+
+  @param[in] CommBuffer  A pointer to the buffer to convey into MMRAM.
+  @param[in] 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. This parameter is optional and may be
+ NULL.
+
+  @retval EFI_SUCCESSThe message was successfully posted.
+  @retval EFI_INVALID_PARAMETER  The CommBuffer was NULL.
+  @retval EFI_BAD_BUFFER_SIZEThe 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(s) or CommSize
+ parameter, if not omitted, a

[edk2] [PATCH 2/4] MdeModulePkg: add implementation of MmCommunicateLib

2019-03-11 Thread Ard Biesheuvel
Add an implementation of MmCommunicateLib based on traditional SMM.
This version passes the physical address of the communication buffer
into the MM communicate protocol method.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/MdeModulePkg.dsc  
|   1 +
 MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf 
|  51 +
 MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c   
| 114 
 MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.uni 
|  19 
 4 files changed, 185 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 6cd1727a0d61..84c2629d5adc 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -317,6 +317,7 @@ [Components]
   MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf
   
MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
   
MdeModulePkg/Library/DisplayUpdateProgressLibText/DisplayUpdateProgressLibText.inf
+  
MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
 
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
   MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf
diff --git 
a/MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
 
b/MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
new file mode 100644
index ..93b924d5eefb
--- /dev/null
+++ 
b/MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
@@ -0,0 +1,51 @@
+## @file
+#  Abstraction library for calls to EFI_MM_COMMUNICATE_PROTOCOL::Communicate
+#
+#  Copyright (c) 2019, Linaro 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]
+  INF_VERSION= 0x0001001B
+  BASE_NAME  = RuntimeDxeMmCommunicateLib
+  MODULE_UNI_FILE= RuntimeDxeMmCommunicateLib.uni
+  FILE_GUID  = cb3ee7d3-ea6f-494c-ac57-c5f4dc0ab3b9
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = MmCommunicateLib|DXE_RUNTIME_DRIVER
+  CONSTRUCTOR= RuntimeDxeMmCommunicateLibConstructor
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = ARM AARCH64 IA32 X64 EBC
+#
+
+[Sources]
+  RuntimeDxeMmCommunicateLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+
+[LibraryClasses]
+  DebugLib
+  UefiBootServicesTableLib
+  UefiRuntimeLib
+
+[Guids]
+  gEfiEventVirtualAddressChangeGuid ## CONSUMES ## Event
+
+[Protocols]
+  gEfiMmCommunicationProtocolGuid   ## CONSUMES
+
+[Depex]
+  gEfiMmCommunicationProtocolGuid
diff --git 
a/MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c 
b/MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c
new file mode 100644
index ..b4ae5dd1fd9a
--- /dev/null
+++ 
b/MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c
@@ -0,0 +1,114 @@
+/** @file
+  Abstraction library for calls to EFI_MM_COMMUNICATE_PROTOCOL::Communicate
+
+  Copyright (c) 2019, Linaro 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.
+
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+STATIC EFI_MM_COMMUNICATION_PROTOCOL*mMmCommunication;
+STATIC EFI_EVENTmVirtualAddressChangeEvent;
+
+/**
+  Invoke the MM communication protocol
+
+  @param[in] PhysicalCommBuffer  Physical address of the communication buffer.
+  @param[in] VirtualCommBuffer   Virtual address of the communication buffer.
+  @param[in] 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. This parameter

[edk2] [PATCH 0/4] MdeModulePkg, StandaloneMmPkg: work around VA vs PA ambiguity

2019-03-11 Thread Ard Biesheuvel
This series proposes one possible approach to work around the issue that the
traditional MM and standalone MM implement versions of the communicate protocol
that are fundamentally incompatible from the point of view of the caller.

In traditional MM, the MM communicate protocol takes a physical pointer for
the buffer, so that the SMM execution context can access the memory directly
without having to translate it according to the translation regime of the
caller.

In standalone MM, the buffer that is shared with the MM context is preallocated,
and so it is up to the implementation of the MM communicate protocol to copy the
data from the caller allocated buffer into the preallocated shared buffer. In
order to be able to do so, the DXE driver needs to copy the contents, and for
this it needs to know the virtual address not the physical address.

So this means we have two incompatible versions of the same protocol, and given
that we have even re-used the EFI_SMM_COMMUNICATE_PROTOCOL GUID for the new
EFI_MM_COMMUNICATE_PROTOCOL, we cannot distinguish programmatically between a
MM context that takes physical addresses vs one that takes virtual ones.

Since this is known at build time, one way to deal with this is to have two
different implementations of a library that defines an abstract MmCommunicate()
function, allowing the correct implementation to be selected at integration
time.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Star Zeng 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Achin Gupta 
Cc: Jiewen Yao 
Cc: Supreeth Venkatesh 
Cc: Jagadeesh Ujja 

Ard Biesheuvel (4):
  MdeModulePkg: introduce MmCommunicationLib library class
  MdeModulePkg: add implementation of MmCommunicateLib
  StandaloneMmPkg: add implementation of MmCommunicateLib
  MdeModulePkg/VariableSmmRuntimeDxe: switch to MmCommunicateLib library

 MdeModulePkg/MdeModulePkg.dec  
   |   4 +
 MdeModulePkg/MdeModulePkg.dsc  
   |   2 +
 MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf 
   |  51 +
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf   
   |   4 +-
 
StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
 |  51 +
 MdeModulePkg/Include/Library/MmCommunicateLib.h
   |  50 +
 MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c   
   | 114 
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c 
   |  10 +-
 
StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c 
  | 113 +++
 MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.uni 
   |  19 
 
StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.uni
 |  19 
 11 files changed, 428 insertions(+), 9 deletions(-)
 create mode 100644 
MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
 create mode 100644 
StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.inf
 create mode 100644 MdeModulePkg/Include/Library/MmCommunicateLib.h
 create mode 100644 
MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c
 create mode 100644 
StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.c
 create mode 100644 
MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.uni
 create mode 100644 
StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmCommunicateLib.uni

-- 
2.20.1

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


[edk2] [PATCH 1/4] MdeModulePkg: introduce MmCommunicationLib library class

2019-03-11 Thread Ard Biesheuvel
In order to abstract away the difference between traditional and
standalone MM implementations of the MM communicate protocol, which
have different requirements when it comes to the way the address of
the communication buffer is passed, introduce a library class that
can encapsulate calls to the MM communicate protocols, and which
takes both the physical and virtual adresses of the buffer. This
way, it is left up to the library implementation to decide which
address is passed.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/MdeModulePkg.dec   |  4 ++
 MdeModulePkg/Include/Library/MmCommunicateLib.h | 50 
 2 files changed, 54 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index a2130bc43991..0778bf01edca 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -182,6 +182,10 @@ [LibraryClasses]
   #
   DisplayUpdateProgressLib|Include/Library/DisplayUpdateProgressLib.h
 
+  ## @libraryclass  Provides an abstraction for invoking the MM communicate 
protocol
+  #
+  MmCommunicateLib|Include/Library/MmCommunicateLib.h
+
 [Guids]
   ## MdeModule package token space guid
   # Include/Guid/MdeModulePkgTokenSpace.h
diff --git a/MdeModulePkg/Include/Library/MmCommunicateLib.h 
b/MdeModulePkg/Include/Library/MmCommunicateLib.h
new file mode 100644
index ..b302e47f6f8f
--- /dev/null
+++ b/MdeModulePkg/Include/Library/MmCommunicateLib.h
@@ -0,0 +1,50 @@
+/** @file
+  Abstraction library for calls to EFI_MM_COMMUNICATE_PROTOCOL::Communicate
+
+  Copyright (c) 2019, Linaro 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 MM_COMMUNICATE_LIB_H__
+#define MM_COMMUNICATE_LIB_H__
+
+/**
+  Invoke the MM communication protocol
+
+  @param[in] PhysicalCommBuffer  Physical address of the communication buffer.
+  @param[in] VirtualCommBuffer   Virtual address of the communication buffer.
+  @param[in] 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. This parameter is optional and may be
+ NULL.
+
+  @retval EFI_SUCCESSThe message was successfully posted.
+  @retval EFI_INVALID_PARAMETER  The CommBuffer was NULL.
+  @retval EFI_BAD_BUFFER_SIZEThe 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(s) or CommSize
+ parameter, if not omitted, are in address 
range
+ that cannot be accessed by the MM environment.
+
+**/
+EFI_STATUS
+EFIAPI
+MmCommunicate (
+  IN OUT VOID  *PhysicalCommBuffer,
+  IN OUT VOID  *VirtualCommBuffer,
+  IN OUT UINTN *CommSize OPTIONAL
+  );
+
+#endif
-- 
2.20.1

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


Re: [edk2] [PATCH edk2-platforms 1/2] Platform/ARM/SgiPkg: align with upstream StandaloneMmPkg changes

2019-03-11 Thread Ard Biesheuvel
On Mon, 11 Mar 2019 at 14:56, Thomas Abraham  wrote:
>
> On Mon, Mar 11, 2019 at 7:09 PM Ard Biesheuvel
>  wrote:
> >
> > On Mon, 11 Mar 2019 at 14:31, Thomas Abraham  wrote:
> > >
> > > On Fri, Mar 8, 2019 at 9:01 PM Ard Biesheuvel  
> > > wrote:
> > > >
> > > > Bring SgiPkg in line with EDK2 core changes to StandaloneMmPkg:
> > > > - add a resolution for ExtractGuidedSectionLib
> > > > - remove reference to 
> > > > gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
> > > > - update the resolution of StandaloneMmDriverEntryPoint
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Ard Biesheuvel 
> > > > ---
> > > >  Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 8 
> > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc 
> > > > b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > > > index 65dd6ac82c4a..ef16bfa9a20e 100644
> > > > --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > > > +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > > > @@ -43,6 +43,7 @@
> > > >BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> > > >
> > > > DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> > > >
> > > > DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
> > > > +  
> > > > ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
> > >
> > > The build fails with the following error
> > >
> > > /home/thopan01/devel/sgi/sgi-dev/uefi/edk2/EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:37:
> > > undefined reference to `memcpy'
> > > /tmp/ccOj5Ie6.ltrans0.ltrans.o: In function
> > > `ExtractGuidedSectionLibConstructor':
> > > /home/thopan01/devel/sgi/sgi-dev/uefi/edk2/EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:233:
> > > undefined reference to `memcpy'
> > > collect2: error: ld returned 1 exit status
> > >
> > > I will check further why the build fails here.
> > >
> >
> > We need to add this in the .dsc
> >
> >   #
> >   # It is not possible to prevent the ARM compiler for generic
> > intrinsic functions.
> >   # This library provides the instrinsic functions generate by a given 
> > compiler.
> >   # And NULL mean link this library into all ARM images.
> >   #
> >   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
>
> Thanks, it works with this change. So with this change rolled into this patch.
> Reviewed-by: Thomas Abraham 

Thanks Thomas

Pushed as c63c3f071271..68cc99303e38
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms 1/2] Platform/ARM/SgiPkg: align with upstream StandaloneMmPkg changes

2019-03-11 Thread Ard Biesheuvel
On Mon, 11 Mar 2019 at 14:31, Thomas Abraham  wrote:
>
> On Fri, Mar 8, 2019 at 9:01 PM Ard Biesheuvel  
> wrote:
> >
> > Bring SgiPkg in line with EDK2 core changes to StandaloneMmPkg:
> > - add a resolution for ExtractGuidedSectionLib
> > - remove reference to gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
> > - update the resolution of StandaloneMmDriverEntryPoint
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc 
> > b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > index 65dd6ac82c4a..ef16bfa9a20e 100644
> > --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> > @@ -43,6 +43,7 @@
> >BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> >DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> >
> > DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
> > +  
> > ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
>
> The build fails with the following error
>
> /home/thopan01/devel/sgi/sgi-dev/uefi/edk2/EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:37:
> undefined reference to `memcpy'
> /tmp/ccOj5Ie6.ltrans0.ltrans.o: In function
> `ExtractGuidedSectionLibConstructor':
> /home/thopan01/devel/sgi/sgi-dev/uefi/edk2/EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:233:
> undefined reference to `memcpy'
> collect2: error: ld returned 1 exit status
>
> I will check further why the build fails here.
>

We need to add this in the .dsc

  #
  # It is not possible to prevent the ARM compiler for generic
intrinsic functions.
  # This library provides the instrinsic functions generate by a given compiler.
  # And NULL mean link this library into all ARM images.
  #
  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 00/10] StandaloneMmPkg, ArmPkg: cleanups and improvements

2019-03-11 Thread Ard Biesheuvel
On Mon, 11 Mar 2019 at 12:54, Ard Biesheuvel  wrote:
>
> On Tue, 5 Mar 2019 at 14:32, Ard Biesheuvel  wrote:
> >
> > This series is a further cleanup of the StandaloneMmPkg infrastructure
> > used to implement UEFI secure boot on ARM systems.
> >
> > The first 5 patches are simple cleanups.
> >
> > Patch #6 adds support for dispatching a compressed firmware volume in the
> > standalone MM context, so that all drivers except the core can be delivered
> > in an encapsulated compressed FV, which saves quite some space.
> >
> > Patch #7 modifies the driver dispatch logic in the MM context so that the
> > dispatcher continues until all drivers are dispatched, rather than waiting
> > for a nudge from the non-secure side once the CPU driver has been loaded.
> >
> > Patch #8 removes support for the FV dispatch MM call.
> >
> > Patch #9 removes support for legacy boot handling.
> >
> > Patch #10 implements relaying architected PI events from DXE into MM by
> > the MM communicate driver.
> >
> > Cc: Achin Gupta 
> > Cc: Supreeth Venkatesh 
> > Cc: Jiewen Yao 
> > Cc: Leif Lindholm 
> > Cc: Jagadeesh Ujja 
> >
> > Ard Biesheuvel (10):
> >   StandaloneMmPkg: drop redundant definition of
> > gEfiMmConfigurationProtocolGuid
> >   StandaloneMmPkg: switch to NULL DebugLib resolution
> >   StandaloneMmPkg/StandaloneMmCoreEntryPoint: drop explicit
> > SerialPortLib call
> >   StandaloneMmPkg/Core: permit encapsulated firmware volumes
> >   StandaloneMmPkg/Core: dispatch all drivers at init time
> >   StandaloneMmPkg/Core: drop support for dispatching FVs into MM
> >   StandaloneMmPkg/Core: remove legacy boot support
>
> Pushed the 7 patches above as 326598e9b759..b2877855c7ec.
>
> >   StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable
> >   StandaloneMmPkg: remove redundant StandaloneMmDriverEntryPoint driver
>
> These 2 are ready to go, but are dependent on edk2-platforms patches
> that are under review.
>

Unfortunately, I have already broken the SGI build by pushing
'StandaloneMmPkg/Core: permit encapsulated firmware volumes' above, so
no point in deferring these 2.

Pushed as b2877855c7ec..d6253d2f9a33


> >   ArmPkg/MmCommunicationDxe: signal architected PI events into MM
> > context
>
> This one is still under discussion, since we need to clarify which
> events need to be signaled into the MM context.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms 1/2] Platform/ARM/SgiPkg: align with upstream StandaloneMmPkg changes

2019-03-11 Thread Ard Biesheuvel
On Fri, 8 Mar 2019 at 16:31, Ard Biesheuvel  wrote:
>
> Bring SgiPkg in line with EDK2 core changes to StandaloneMmPkg:
> - add a resolution for ExtractGuidedSectionLib
> - remove reference to gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
> - update the resolution of StandaloneMmDriverEntryPoint
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Could I get an ack from the ARM folks please?

> ---
>  Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc 
> b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> index 65dd6ac82c4a..ef16bfa9a20e 100644
> --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> @@ -43,6 +43,7 @@
>BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
>
> DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
> +  
> ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
>FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf
>
> HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
>IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> @@ -56,7 +57,7 @@
>#
># Entry point
>#
> -  
> StandaloneMmDriverEntryPoint|StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
> +  
> StandaloneMmDriverEntryPoint|MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
>
>ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
>
> StandaloneMmMmuLib|ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> @@ -81,9 +82,6 @@
>  # Pcd Section - list of all EDK II PCD Entries defined by this Platform
>  #
>  
> 
> -[PcdsFeatureFlag]
> -  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|TRUE
> -
>  [PcdsFixedAtBuild]
>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80CF
>gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xff
> @@ -93,6 +91,8 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x7FF7
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
>
> +  gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
> +
>  
> ###
>  #
>  # 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 00/10] StandaloneMmPkg, ArmPkg: cleanups and improvements

2019-03-11 Thread Ard Biesheuvel
On Tue, 5 Mar 2019 at 14:32, Ard Biesheuvel  wrote:
>
> This series is a further cleanup of the StandaloneMmPkg infrastructure
> used to implement UEFI secure boot on ARM systems.
>
> The first 5 patches are simple cleanups.
>
> Patch #6 adds support for dispatching a compressed firmware volume in the
> standalone MM context, so that all drivers except the core can be delivered
> in an encapsulated compressed FV, which saves quite some space.
>
> Patch #7 modifies the driver dispatch logic in the MM context so that the
> dispatcher continues until all drivers are dispatched, rather than waiting
> for a nudge from the non-secure side once the CPU driver has been loaded.
>
> Patch #8 removes support for the FV dispatch MM call.
>
> Patch #9 removes support for legacy boot handling.
>
> Patch #10 implements relaying architected PI events from DXE into MM by
> the MM communicate driver.
>
> Cc: Achin Gupta 
> Cc: Supreeth Venkatesh 
> Cc: Jiewen Yao 
> Cc: Leif Lindholm 
> Cc: Jagadeesh Ujja 
>
> Ard Biesheuvel (10):
>   StandaloneMmPkg: drop redundant definition of
> gEfiMmConfigurationProtocolGuid
>   StandaloneMmPkg: switch to NULL DebugLib resolution
>   StandaloneMmPkg/StandaloneMmCoreEntryPoint: drop explicit
> SerialPortLib call
>   StandaloneMmPkg/Core: permit encapsulated firmware volumes
>   StandaloneMmPkg/Core: dispatch all drivers at init time
>   StandaloneMmPkg/Core: drop support for dispatching FVs into MM
>   StandaloneMmPkg/Core: remove legacy boot support

Pushed the 7 patches above as 326598e9b759..b2877855c7ec.

>   StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable
>   StandaloneMmPkg: remove redundant StandaloneMmDriverEntryPoint driver

These 2 are ready to go, but are dependent on edk2-platforms patches
that are under review.

>   ArmPkg/MmCommunicationDxe: signal architected PI events into MM
> context

This one is still under discussion, since we need to clarify which
events need to be signaled into the MM context.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v3] StandaloneMmPkg/Library: Install Variable Arch Protocol

2019-03-11 Thread Ard Biesheuvel
On Tue, 5 Mar 2019 at 17:16, Ard Biesheuvel  wrote:
>
> On Tue, 5 Mar 2019 at 17:15, Yao, Jiewen  wrote:
> >
> > I look at the patch. I don’t have concern.
> >
> > Please go ahead.
> >
>
> Thank you Jiewen,
>
> I will take that as a reviewed-by and proceed with merging the patch
> once the hard freeze is over.
>
>

Pushed as 690d60c0ada5..326598e9b759

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


[edk2] [PATCH edk2-platforms 1/2] Platform/ARM/SgiPkg: align with upstream StandaloneMmPkg changes

2019-03-08 Thread Ard Biesheuvel
Bring SgiPkg in line with EDK2 core changes to StandaloneMmPkg:
- add a resolution for ExtractGuidedSectionLib
- remove reference to gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
- update the resolution of StandaloneMmDriverEntryPoint

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc 
b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
index 65dd6ac82c4a..ef16bfa9a20e 100644
--- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
+++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
@@ -43,6 +43,7 @@
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
   
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
+  
ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
   FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf
   
HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
   IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
@@ -56,7 +57,7 @@
   #
   # Entry point
   #
-  
StandaloneMmDriverEntryPoint|StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
+  
StandaloneMmDriverEntryPoint|MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
 
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
   
StandaloneMmMmuLib|ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
@@ -81,9 +82,6 @@
 # Pcd Section - list of all EDK II PCD Entries defined by this Platform
 #
 

-[PcdsFeatureFlag]
-  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|TRUE
-
 [PcdsFixedAtBuild]
   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80CF
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xff
@@ -93,6 +91,8 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x7FF7
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
 
+  gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
+
 
###
 #
 # 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


[edk2] [PATCH edk2-platforms 2/2] Platform/Socionext/DeveloperBox: align with upstream StandaloneMmPkg changes

2019-03-08 Thread Ard Biesheuvel
Bring DeveloperBox in line with EDK2 core changes to StandaloneMmPkg:
- switch from BaseExtractGuidedSectionLib to PrePiExtractGuidedSectionLib
- include a NULL library class resolution for VariableMmDependency

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc   | 5 -
 Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc | 7 +++
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 31afc4aac3c4..39077ab5ee79 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -293,7 +293,10 @@
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
   }
 !else
-  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
+  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
+
+  
NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
+  }
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
   SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
 !endif
diff --git a/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
index 55c5fbb7350d..141b175047b2 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
@@ -68,9 +68,6 @@
 [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x5104
 
-[PcdsPatchableInModule]
-  gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|0x0
-
 

 #
 # Components Section - list of all EDK II Modules needed by this Platform
@@ -82,8 +79,10 @@
   #
   StandaloneMmPkg/Core/StandaloneMmCore.inf {
 
-  
ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
+  
ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
   
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+
+  gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
   }
 
   StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
-- 
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

2019-03-07 Thread Ard Biesheuvel
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?

Thanks,
Ard.
___
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

2019-03-06 Thread Ard Biesheuvel
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.
___
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

2019-03-06 Thread Ard Biesheuvel
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.
___
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?

2019-03-06 Thread Ard Biesheuvel
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?

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.
>
> 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   B

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

2019-03-06 Thread Ard Biesheuvel
(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)
>
> 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.

> 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?
>

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.


> 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
___
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?

2019-03-05 Thread Ard Biesheuvel
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)

> 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


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

2019-03-05 Thread Ard Biesheuvel
On Tue, 5 Mar 2019 at 17:53, Felix Polyudov  wrote:
>
> There is an architectural difference between EndOfDxe and SmmReadyToLock 
> events.
> It's important to have both of them.
> Here is what PI specification says:
> ==
> Transition from the environment where all of the components are under the 
> authority of the platform manufacturer to the environment where third party 
> modules are executed is a two-step process:
> 1.End of DXE Event is signaled. This event presents the last opportunity to 
> use resources or interfaces that are going to be locked or disabled in 
> anticipation of the invocation of 3rd party extensible modules.
> 2.DXE SMM Ready to Lock Protocol is installed. PI modules that need to lock 
> or protect their resources in anticipation of the invocation of 3rd party 
> extensible modules should register for notification on installation of this 
> protocol and effect the appropriate protections in their notification handlers

Thanks for pointing that out, Felix. I will add SmmReadyToLock as well.


> ==
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
> Jiewen
> Sent: Tuesday, March 05, 2019 11:19 AM
> To: Ard Biesheuvel
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal 
> architected PI events into MM context
>
> For current X86 world, we do use both SmmReadyToLock and EndOfDxe, for almost 
> all X86 platform.
>
> So, let me clarify:
> If we try to align with PI spec, we can add 
> EndOfDxe/ReadyToBoot/ExitBootService.
> If we try to align with security, we can add EndOfDxe/SmmReadyToLock.
>
> It depends upon the what goal we want to achieve. That is why I ask if we 
> have specific use case.
>
> Anyway, I think we can add when it is really needed later.
> So I am OK with current patch.
>
> Thank you
> Yao Jiewen
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Ard Biesheuvel
> > Sent: Tuesday, March 5, 2019 8:07 AM
> > To: Yao, Jiewen 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal
> > architected PI events into MM context
> >
> > On Tue, 5 Mar 2019 at 17:04, Yao, Jiewen  wrote:
> > >
> > > OK. To keep the compatibility of existing MM driver. That makes sense.
> > >
> > > If it is for security, I think EndOfDxe is the only point.
> > > ReadyToBoot and ExitBootService cannot be used for security purpose.
> > >
> >
> > OK, good to know. I will keep them for the time being - MM drivers may
> > be able to release resources or do other useful things when the
> > non-secure side enters runtime mode.
> >
> > > Then do we need SmmReadyToLock ? :-)
> > >
> >
> > Good point. It looked fairly x86 specific to me. Do you think it is
> > likely to be used in OEM code running in MM mode?
> >
> >
> >
> >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > Of
> > > > Ard Biesheuvel
> > > > Sent: Tuesday, March 5, 2019 7:58 AM
> > > > To: Yao, Jiewen 
> > > > Cc: edk2-devel@lists.01.org
> > > > Subject: Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe:
> > signal
> > > > architected PI events into MM context
> > > >
> > > > On Tue, 5 Mar 2019 at 16:56, Yao, Jiewen 
> > wrote:
> > > > >
> > > > > Hi
> > > > > In original SMM infrastructure, there are lots of interaction that SMM
> > has
> > > > to know the DXE status.
> > > > >
> > > > > In StandaloneMm, I don't expect we have many interaction. Is there
> > any
> > > > specific example?
> > > > >
> > > > > I am totally OK to add those. And I just want to know more usage.
> > > > >
> > > > > Reviewed-by: jiewen@intel.com
> > > > >
> > > >
> > > > Jiewen,
> > > >
> > > > Thanks for the review.
> > > >
> > > > It is not 100% clear at the moment, but since existing third party
> > > > software designed to run in MM context may make assumptions about
> > > > security of the platform (e.g., before vs after end of dxe) based on
> > > > these events, we should at least signal the common ones added in this
> > > > patch.
> > > >
> > > >
> > > >
> > > >
&g

Re: [edk2] [PATCH v3] StandaloneMmPkg/Library: Install Variable Arch Protocol

2019-03-05 Thread Ard Biesheuvel
On Tue, 5 Mar 2019 at 17:15, Yao, Jiewen  wrote:
>
> I look at the patch. I don’t have concern.
>
> Please go ahead.
>

Thank you Jiewen,

I will take that as a reviewed-by and proceed with merging the patch
once the hard freeze is over.


> > -Original Message-
> > From: Jagadeesh Ujja [mailto:jagadeesh.u...@arm.com]
> > Sent: Tuesday, March 5, 2019 6:09 AM
> > To: Ard Biesheuvel 
> > Cc: Achin Gupta ; Yao, Jiewen
> > ; Gao, Liming ;
> > edk2-devel@lists.01.org; Zhang, Chao B ; Kinney,
> > Michael D ; Zeng, Star 
> > Subject: Re: [edk2] [PATCH v3] StandaloneMmPkg/Library: Install Variable
> > Arch Protocol
> >
> > hi Jiewen, Achin
> >
> > On Mon, Mar 4, 2019 at 4:16 PM Ard Biesheuvel 
> > wrote:
> > >
> > > (add StandaloneMmPkg maintainers)
> > >
> > Please let me know if you have any comments on this patch
> >
> > > On Mon, 4 Mar 2019 at 09:54, Jagadeesh Ujja 
> > wrote:
> > > >
> > > > In a system implementing the variable store in MM, there are no variable
> > > > arch protocol and variable write arch protocol installed into the
> > > > DXE_SMM protocol database. On such systems, it is not required to
> > > > locate these protocols by the DXE runtime variable drivers because
> > > > it can be assumed that these protocols are already installed in the
> > > > MM context. But then such an implementation will deviate from the
> > > > existing traditional MM based variable driver implementation.
> > > >
> > > > So in order to maintain consistency with the traditional MM variable
> > > > driver implementation, allow platforms to install these protocols into
> > > > the DXE protocol database but these protocol will not be consumed
> > > > by non-secure variable service runtime driver.
> > > >
> > > > The Platform which uses StandaloneMM based secure variable storage
> > > > have to include this library
> > > >
> > > > Example
> > > > In edk2-platforms/Platform/ARM/SgiPkg/SgiPlatform.dsc
> > > >
> > > >   ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
> > > > 
> > > >
> > NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDep
> > endency.inf
> > > >   }
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Jagadeesh Ujja 
> > >
> > > Reviewed-by: Ard Biesheuvel 
> > >
> > > > ---
> > > > Changes since v2:
> > > > - Addressed the comments from Ard Biesheuvel and Zeng Star
> > > >
> > > > Changes since v1:
> > > > - This is a next version of patch
> > > >“MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating
> > Variable Arch Protocol”.
> > > >
> > [https://lists.01.org/pipermail/edk2-devel/2019-February/036885.html]
> > > > - Addressed the comments from Ard Biesheuvel and Zeng Star
> > > > - Can this library be placed in MdePkg rather then the StandaloneMmPkg?
> > > >
> > > >
> > StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependenc
> > y.c   | 54 
> > > >
> > StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependenc
> > y.inf | 46 +
> > > >  2 files changed, 100 insertions(+)
> > > >
> > > > diff --git
> > a/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDepende
> > ncy.c
> > b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDepende
> > ncy.c
> > > > new file mode 100644
> > > > index 000..7e0f31b
> > > > --- /dev/null
> > > > +++
> > b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDepende
> > ncy.c
> > > > @@ -0,0 +1,54 @@
> > > > +/** @file
> > > > +  Runtime DXE part corresponding to StanaloneMM variable module.
> > > > +
> > > > +This module installs variable arch protocol and variable write arch
> > protocol
> > > > +to StandaloneMM runtime variable service.
> > > > +
> > > > +Copyright (c) 2019, 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 foun

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

2019-03-05 Thread Ard Biesheuvel
On Tue, 5 Mar 2019 at 17:04, Yao, Jiewen  wrote:
>
> OK. To keep the compatibility of existing MM driver. That makes sense.
>
> If it is for security, I think EndOfDxe is the only point.
> ReadyToBoot and ExitBootService cannot be used for security purpose.
>

OK, good to know. I will keep them for the time being - MM drivers may
be able to release resources or do other useful things when the
non-secure side enters runtime mode.

> Then do we need SmmReadyToLock ? :-)
>

Good point. It looked fairly x86 specific to me. Do you think it is
likely to be used in OEM code running in MM mode?




> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Ard Biesheuvel
> > Sent: Tuesday, March 5, 2019 7:58 AM
> > To: Yao, Jiewen 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal
> > architected PI events into MM context
> >
> > On Tue, 5 Mar 2019 at 16:56, Yao, Jiewen  wrote:
> > >
> > > Hi
> > > In original SMM infrastructure, there are lots of interaction that SMM has
> > to know the DXE status.
> > >
> > > In StandaloneMm, I don't expect we have many interaction. Is there any
> > specific example?
> > >
> > > I am totally OK to add those. And I just want to know more usage.
> > >
> > > Reviewed-by: jiewen@intel.com
> > >
> >
> > Jiewen,
> >
> > Thanks for the review.
> >
> > It is not 100% clear at the moment, but since existing third party
> > software designed to run in MM context may make assumptions about
> > security of the platform (e.g., before vs after end of dxe) based on
> > these events, we should at least signal the common ones added in this
> > patch.
> >
> >
> >
> >
> > > > -Original Message-
> > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > > > Sent: Tuesday, March 5, 2019 5:33 AM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Ard Biesheuvel ; Achin Gupta
> > > > ; Supreeth Venkatesh
> > > > ; Yao, Jiewen ;
> > > > Leif Lindholm ; Jagadeesh Ujja
> > > > 
> > > > Subject: [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal
> > architected
> > > > PI events into MM context
> > > >
> > > > 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[] = {
> > > > +  ,
> > > > +  ,
> > > > +  ,
> &

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

2019-03-05 Thread Ard Biesheuvel
On Tue, 5 Mar 2019 at 16:56, Yao, Jiewen  wrote:
>
> Hi
> In original SMM infrastructure, there are lots of interaction that SMM has to 
> know the DXE status.
>
> In StandaloneMm, I don't expect we have many interaction. Is there any 
> specific example?
>
> I am totally OK to add those. And I just want to know more usage.
>
> Reviewed-by: jiewen@intel.com
>

Jiewen,

Thanks for the review.

It is not 100% clear at the moment, but since existing third party
software designed to run in MM context may make assumptions about
security of the platform (e.g., before vs after end of dxe) based on
these events, we should at least signal the common ones added in this
patch.




> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Tuesday, March 5, 2019 5:33 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel ; Achin Gupta
> > ; Supreeth Venkatesh
> > ; Yao, Jiewen ;
> > Leif Lindholm ; Jagadeesh Ujja
> > 
> > Subject: [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal architected
> > PI events into MM context
> >
> > 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 v2 0/1] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems

2019-03-05 Thread Ard Biesheuvel
On Tue, 5 Mar 2019 at 03:18, Wu, Hao A  wrote:
>
> > -Original Message-
> > From: Wu, Hao A
> > Sent: Tuesday, March 05, 2019 9:14 AM
> > To: edk2-devel@lists.01.org
> > Cc: Wu, Hao A; Eugene Cohen; Ard Biesheuvel; Ashish Singhal
> > Subject: [PATCH v2 0/1] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC
> > v3 64-bit systems
>
> Since Ashish already posted a patch to add the 64-bit System Address
> support for V3 mode SDHC:
> https://www.mail-archive.com/edk2-devel@lists.01.org/msg52057.html
>
> I think this patch can be dropped.
>
> But since Ashish's patch above is considered as a new feature addition, it
> will be pushed (if passes the review process) after the 19`Q1 release tag.
>
> So Eugene, Ard and Ashish, do you have concern on this?
>

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


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

2019-03-05 Thread Ard Biesheuvel
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


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

2019-03-05 Thread Ard Biesheuvel
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
   //
-  InLegacyBoot = mInLegacyBoot;
-  if (!InLegacyBoot) {
-//
-// TBD: Mark the InMm flag as TRUE
-//
-gMmCorePrivate->InMm = TRUE;
 
+  //
+  // TBD: Mark the InMm flag as TRUE
+  //
+  gMmCorePrivate->InMm = TRUE;
+
+  //
+  // Check to see if this is a Synchronous MMI sent through the MM 
Communication
+  // Protocol or an Asynchronous MMI
+  //
+  if

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

2019-03-05 Thread Ard Biesheuvel
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.

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


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

2019-03-05 Thread Ard Biesheuvel
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)) {
-//
-// Set the flag to show that the MM Dispatcher executed without errors
-//
-*(UINT8 *)CommBuffer = COMM_BUFFER_MM_DISPATCH_SUCCESS;
-  } else {
-//
-// Set the flag to show that the MM Dispatcher encountered an error
- 

[edk2] [PATCH 04/10] StandaloneMmPkg: remove redundant StandaloneMmDriverEntryPoint driver

2019-03-05 Thread Ard Biesheuvel
StandaloneMmDriverEntryPoint is implemented in MdePkg now, so let's
drop the redundant StandaloneMmPkg version.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 
StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
 | 41 
 
StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
   | 99 
 2 files changed, 140 deletions(-)

diff --git 
a/StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
 
b/StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
deleted file mode 100644
index 4d1896db10ba..
--- 
a/StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
+++ /dev/null
@@ -1,41 +0,0 @@
-## @file
-# Module entry point library for Standalone MM driver.
-#
-# Copyright (c) 2015, Intel Corporation. All rights reserved.
-# Copyright (c) 2016-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.
-#
-#
-##
-
-[Defines]
-  INF_VERSION= 0x0001001A
-  BASE_NAME  = StandaloneMmDriverEntryPoint
-  FILE_GUID  = BBC33478-98F8-4B78-B29D-574D681B7E43
-  MODULE_TYPE= MM_STANDALONE
-  VERSION_STRING = 1.0
-  PI_SPECIFICATION_VERSION   = 0x00010032
-  LIBRARY_CLASS  = StandaloneMmDriverEntryPoint|MM_STANDALONE
-
-#
-# The following information is for reference only and not required by the 
build tools.
-#
-#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
-#
-
-[Sources]
-  StandaloneMmDriverEntryPoint.c
-
-[Packages]
-  MdePkg/MdePkg.dec
-
-[LibraryClasses]
-  BaseLib
-  DebugLib
-
diff --git 
a/StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
 
b/StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
deleted file mode 100644
index 64bffcfccc8a..
--- 
a/StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
+++ /dev/null
@@ -1,99 +0,0 @@
-/** @file
-  Entry point to a Standalone MM driver.
-
-Copyright (c) 2015, Intel Corporation. All rights reserved.
-Copyright (c) 2016 - 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.
-
-**/
-
-#include 
-
-#include 
-#include 
-
-VOID
-EFIAPI
-ProcessLibraryConstructorList (
-  IN EFI_HANDLE   ImageHandle,
-  IN IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
-  );
-
-EFI_STATUS
-EFIAPI
-ProcessModuleEntryPointList (
-  IN EFI_HANDLE   ImageHandle,
-  IN IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
-  );
-
-VOID
-EFIAPI
-ProcessLibraryDestructorList (
-  IN EFI_HANDLE   ImageHandle,
-  IN IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
-  );
-
-/**
-  The entry point of PE/COFF Image for a Standalone MM Driver.
-
-  This function is the entry point for a Standalone MM 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 Standalone MM Driver.
-  @param  SystemTable  A pointer to the EFI System Table.
-
-  @retval  EFI_SUCCESS   The Standalone MM 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 IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
-  )
-{
-  EFI_STATUS 

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

2019-03-05 Thread Ard Biesheuvel
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


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

2019-03-05 Thread Ard Biesheuvel
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;
+}
+
+InnerFvHeader = (VOID *)(Section + 1);
+Status = MmCoreFfsFindMmDriver (InnerFvHeader);
+if (EFI_ERROR (Status)) {
+  goto FreeDstBuffer;
+}
+  } while (TRUE);
+
   for (Index = 0; Index < sizeof (mMmFileTypes) / sizeof (mMmFileTypes[0]); 
Index++) {
 DEBUG ((DEBUG_INFO, "Check MmFileTypes - 0x%x\n&

[edk2] [PATCH 00/10] StandaloneMmPkg, ArmPkg: cleanups and improvements

2019-03-05 Thread Ard Biesheuvel
This series is a further cleanup of the StandaloneMmPkg infrastructure
used to implement UEFI secure boot on ARM systems.

The first 5 patches are simple cleanups.

Patch #6 adds support for dispatching a compressed firmware volume in the
standalone MM context, so that all drivers except the core can be delivered
in an encapsulated compressed FV, which saves quite some space.

Patch #7 modifies the driver dispatch logic in the MM context so that the
dispatcher continues until all drivers are dispatched, rather than waiting
for a nudge from the non-secure side once the CPU driver has been loaded.

Patch #8 removes support for the FV dispatch MM call.

Patch #9 removes support for legacy boot handling.

Patch #10 implements relaying architected PI events from DXE into MM by
the MM communicate driver.

Cc: Achin Gupta 
Cc: Supreeth Venkatesh 
Cc: Jiewen Yao 
Cc: Leif Lindholm 
Cc: Jagadeesh Ujja 

Ard Biesheuvel (10):
  StandaloneMmPkg: drop redundant definition of
gEfiMmConfigurationProtocolGuid
  StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable
  StandaloneMmPkg: switch to NULL DebugLib resolution
  StandaloneMmPkg: remove redundant StandaloneMmDriverEntryPoint driver
  StandaloneMmPkg/StandaloneMmCoreEntryPoint: drop explicit
SerialPortLib call
  StandaloneMmPkg/Core: permit encapsulated firmware volumes
  StandaloneMmPkg/Core: dispatch all drivers at init time
  StandaloneMmPkg/Core: drop support for dispatching FVs into MM
  StandaloneMmPkg/Core: remove legacy boot support
  ArmPkg/MmCommunicationDxe: signal architected PI events into MM
context

 StandaloneMmPkg/StandaloneMmPkg.dec
   |   6 -
 StandaloneMmPkg/StandaloneMmPkg.dsc
   |  14 +-
 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf  
   |   5 +
 StandaloneMmPkg/Core/StandaloneMmCore.inf  
   |   1 +
 
StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
 |  41 --
 
StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
 |   3 -
 StandaloneMmPkg/Core/StandaloneMmCore.h
   |  44 ---
 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
   |  47 ++-
 StandaloneMmPkg/Core/Dispatcher.c  
   | 138 
 StandaloneMmPkg/Core/FwVol.c   
   |  99 --
 StandaloneMmPkg/Core/StandaloneMmCore.c
   | 126 +-
 
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
   |   3 -
 
StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
   |  99 --
 13 files changed, 175 insertions(+), 451 deletions(-)
 delete mode 100644 
StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf
 delete mode 100644 
StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c

-- 
2.20.1

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


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

2019-03-05 Thread Ard Biesheuvel
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);
-
   // 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


[edk2] [PATCH 01/10] StandaloneMmPkg: drop redundant definition of gEfiMmConfigurationProtocolGuid

2019-03-05 Thread Ard Biesheuvel
gEfiMmConfigurationProtocolGuid is already defined in MdePkg, so drop
the duplicate definition from StandaloneMmPkg.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 StandaloneMmPkg/StandaloneMmPkg.dec | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/StandaloneMmPkg/StandaloneMmPkg.dec 
b/StandaloneMmPkg/StandaloneMmPkg.dec
index 34108376233d..0b5fbf9e1767 100644
--- a/StandaloneMmPkg/StandaloneMmPkg.dec
+++ b/StandaloneMmPkg/StandaloneMmPkg.dec
@@ -42,6 +42,3 @@ [Guids]
 [PcdsFeatureFlag]
   gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|FALSE|BOOLEAN|0x0001
 
-[Protocols]
-  gEfiMmConfigurationProtocolGuid  = { 0xc109319, 0xc149, 0x450e,  { 
0xa3, 0xe3, 0xb9, 0xba, 0xdd, 0x9d, 0xc3, 0xa4 }}
-
-- 
2.20.1

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


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

2019-03-05 Thread Ard Biesheuvel
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 edk2-platforms 3/3] Platform/ARM/SgiPkg: add MM based UEFI secure boot support

2019-03-04 Thread Ard Biesheuvel
On Mon, 4 Mar 2019 at 11:12, Jagadeesh Ujja  wrote:
>
> This implements support for UEFI secure boot on SGI platforms using
> the standalone MM framework. This moves all of the software handling
> of the UEFI authenticated variable store into the standalone MM
> context residing in a secure partition.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja 
> ---
>  Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 33 +++-
>  Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf |  5 +++
>  Platform/ARM/SgiPkg/SgiPlatform.dsc  | 18 ++-
>  Platform/ARM/SgiPkg/SgiPlatform.fdf  |  9 +-
>  4 files changed, 62 insertions(+), 3 deletions(-)
>
> diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc 
> b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> index 65dd6ac..889be2f 100644
> --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
> @@ -75,7 +75,17 @@
>HobLib|StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
>
> MmServicesTableLib|MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
>
> MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf
> -
> +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE

Does it make sense to make this conditional? Would you build
PlatformStandaloneMm.dsc if MM_SECURE_STORAGE_ENABLE is FALSE?

> +  AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
> +  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> +  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> +  
> NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
> +  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +  
> PlatformSecureLib|SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> +  
> SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> +  
> TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
> +  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
> +!endif
>  
> 
>  #
>  # Pcd Section - list of all EDK II PCD Entries defined by this Platform
> @@ -93,6 +103,21 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x7FF7
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
>
> +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE

Same here

> +  #Secure Storage
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
> +  gEfiSecurityPkgTokenSpaceGuid.PcdUserPhysicalPresence|TRUE
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
> +
> +  ## NV Storage - 1MB*3 in NOR2 Flash
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x1040
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0010
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x1050
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0010
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x1060
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0010
> +!endif
> +
>  
> ###
>  #
>  # Components Section - list of the modules and components that will be 
> processed by compilation
> @@ -118,6 +143,12 @@
>StandaloneMmPkg/Core/StandaloneMmCore.inf
>
>  [Components.AARCH64]
> +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE

Same here

> +  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
> +  
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
> +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> +!endif
> +
>StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
>
>  
> ###
> diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf 
> b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
> index 810460c..04aa5cd 100644
> --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
> +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
> @@ -55,6 +55,11 @@ READ_LOCK_CAP  = TRUE
>  READ_LOCK_STATUS   = TRUE
>
>INF StandaloneMmPkg/Core/StandaloneMmCore.inf
> +!if $(MM_SECURE_STORAGE_ENABLE) == TRUE

and here

> +  INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
> +  INF 
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
> +  INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> +!endif
>INF StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
>
>  
> 
> diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc 
> 

Re: [edk2] [PATCH edk2-platforms 2/3] Platform/ARM/Sgi: allow MM_STANDALONE modules to use NorFlashPlatformLib

2019-03-04 Thread Ard Biesheuvel
On Mon, 4 Mar 2019 at 11:12, Jagadeesh Ujja  wrote:
>
> “NorFlashPlatformLib” library can be used by MM_STANDALONE drivers as
> well. When used in MM mode, the third instance of the NOR flash is used as
> the non-volatile storage. This NOR flash instance is partitioned into
> two regions - first 4MB space is used for secure boot and next 3MB for
> secure variable storage
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja 
> ---
>  Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c   | 63 
> 
>  Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf | 35 
> +++
>  2 files changed, 98 insertions(+)
>
> diff --git 
> a/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c 
> b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
> new file mode 100644
> index 000..06e3f97
> --- /dev/null
> +++ b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
> @@ -0,0 +1,63 @@
> +/** @file
> +
> +  Copyright (c) 2019, 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.
> +
> + **/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +STATIC NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
> +  {
> +// Secure Boot storage space of 4MB
> +SGI_EXP_SMC_CS2_BASE,
> +SGI_EXP_SMC_CS2_BASE,
> +SIZE_256KB * 16,
> +SIZE_256KB,
> +  },
> +  {
> +//Secure variable storage space of 1MB*3
> +SGI_EXP_SMC_CS2_BASE,
> +SGI_EXP_SMC_CS2_BASE + SIZE_256KB * 16,
> +SIZE_256KB * 12,
> +SIZE_256KB,
> +  },
> +};
> +
> +EFI_STATUS
> +NorFlashPlatformInitialization (
> +  VOID
> +  )
> +{
> +  UINT64 SysRegFlash;
> +
> +  SysRegFlash = SGI_EXP_SYSPH_SYSTEM_REGISTERS + SGI_SYSPH_SYS_REG_FLASH;
> +  MmioOr32 (SysRegFlash, SGI_SYSPH_SYS_REG_FLASH_RWEN);
> +  return EFI_SUCCESS;
> +}
> +
> +EFI_STATUS
> +NorFlashPlatformGetDevices (
> +  OUT NOR_FLASH_DESCRIPTION   **NorFlashDevices,
> +  OUT UINT32  *Count
> +  )
> +{
> +  if ((NorFlashDevices == NULL) || (Count == NULL)) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  *NorFlashDevices = mNorFlashDevices;
> +  *Count = ARRAY_SIZE (mNorFlashDevices);
> +  return EFI_SUCCESS;
> +}
> diff --git 
> a/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf 
> b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
> new file mode 100644
> index 000..eedfacc
> --- /dev/null
> +++ b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
> @@ -0,0 +1,35 @@
> +#/** @file
> +#
> +#  Copyright (c) 2019, 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]
> +  INF_VERSION= 0x0001001A
> +  BASE_NAME  = NorFlashSgiLib
> +  FILE_GUID  = 2ce22190-b933-4d1e-99ba-8bf1f0768255
> +  MODULE_TYPE= MM_STANDALONE

Could this be BASE ?

> +  VERSION_STRING = 1.0
> +  PI_SPECIFICATION_VERSION   = 0x00010032

Can we drop this?

> +  LIBRARY_CLASS  = NorFlashPlatformLib
> +
> +[Sources.common]
> +  StandaloneMmNorFlashLib.c
> +
> +[Packages]
> +  ArmPlatformPkg/ArmPlatformPkg.dec
> +  MdePkg/MdePkg.dec
> +  Platform/ARM/SgiPkg/SgiPlatform.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  DebugLib
> +  IoLib
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms 1/3] Platform/ARM/Sgi: define nor2 flash controller memory map

2019-03-04 Thread Ard Biesheuvel
On Mon, 4 Mar 2019 at 11:12, Jagadeesh Ujja  wrote:
>
> Add the definitions of NOR2 flash controller memory map. The NO2 flash
> can be used as an additional non-volatile storage by non-secure code or
> used as a non-volatile storage for secure variables by the StandaloneMM.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja 

Reviewed-by: Ard Biesheuvel 

> ---
>  Platform/ARM/SgiPkg/Include/SgiPlatform.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h 
> b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> index b9a662a..2a7b79d 100644
> --- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> +++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
> @@ -27,6 +27,10 @@
>  #define SGI_EXP_SMC_CS1_BASE  0x0C00
>  #define SGI_EXP_SMC_CS1_SZSIZE_64MB
>
> +// Expansion AXI - SMC Chip Select 2
> +#define SGI_EXP_SMC_CS2_BASE  0x1000
> +#define SGI_EXP_SMC_CS2_SZSIZE_64MB
> +
>  // Expansion AXI - SMSC 91C111 (Ethernet)
>  #define SGI_EXP_SMSC91X_BASE  0x1800
>  #define SGI_EXP_SMSC91X_SZSIZE_64MB
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v3] StandaloneMmPkg/Library: Install Variable Arch Protocol

2019-03-04 Thread Ard Biesheuvel
(add StandaloneMmPkg maintainers)

On Mon, 4 Mar 2019 at 09:54, Jagadeesh Ujja  wrote:
>
> In a system implementing the variable store in MM, there are no variable
> arch protocol and variable write arch protocol installed into the
> DXE_SMM protocol database. On such systems, it is not required to
> locate these protocols by the DXE runtime variable drivers because
> it can be assumed that these protocols are already installed in the
> MM context. But then such an implementation will deviate from the
> existing traditional MM based variable driver implementation.
>
> So in order to maintain consistency with the traditional MM variable
> driver implementation, allow platforms to install these protocols into
> the DXE protocol database but these protocol will not be consumed
> by non-secure variable service runtime driver.
>
> The Platform which uses StandaloneMM based secure variable storage
> have to include this library
>
> Example
> In edk2-platforms/Platform/ARM/SgiPkg/SgiPlatform.dsc
>
>   ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
> 
>   
> NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
>   }
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja 

Reviewed-by: Ard Biesheuvel 

> ---
> Changes since v2:
> - Addressed the comments from Ard Biesheuvel and Zeng Star
>
> Changes since v1:
> - This is a next version of patch
>“MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch 
> Protocol”.
>[https://lists.01.org/pipermail/edk2-devel/2019-February/036885.html]
> - Addressed the comments from Ard Biesheuvel and Zeng Star
> - Can this library be placed in MdePkg rather then the StandaloneMmPkg?
>
>  StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c   | 54 
> 
>  StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf | 46 
> +
>  2 files changed, 100 insertions(+)
>
> diff --git 
> a/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c 
> b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c
> new file mode 100644
> index 000..7e0f31b
> --- /dev/null
> +++ b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.c
> @@ -0,0 +1,54 @@
> +/** @file
> +  Runtime DXE part corresponding to StanaloneMM variable module.
> +
> +This module installs variable arch protocol and variable write arch protocol
> +to StandaloneMM runtime variable service.
> +
> +Copyright (c) 2019, 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.
> +
> +**/
> +
> +#include 
> +#include 
> +
> +/**
> +  The constructor function installs variable arch protocol and variable
> +  write arch protocol to StandaloneMM runtime variable service
> +
> +  @param  ImageHandle   The firmware allocated handle for the EFI image.
> +  @param  SystemTable   A pointer to the Management mode System Table.
> +
> +  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +VariableMmDependencyLibConstructor (
> +  IN EFI_HANDLE   ImageHandle,
> +  IN EFI_SYSTEM_TABLE *SystemTable
> +  )
> +{
> +  EFI_STATUSStatus;
> +  EFI_HANDLEHandle;
> +
> +  Handle = NULL;
> +  Status = gBS->InstallMultipleProtocolInterfaces (
> +  ,
> +  ,
> +  NULL,
> +  ,
> +  NULL,
> +  NULL
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +  return EFI_SUCCESS;
> +}
> +
> diff --git 
> a/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf 
> b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
> new file mode 100644
> index 000..e71c44d
> --- /dev/null
> +++ b/StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
> @@ -0,0 +1,46 @@
> +## @file
> +#  Runtime DXE part corresponding to StanaloneMM variable module.
> +#
> +#  This module installs variable arch protocol and variable write arch 
> protocol
> +#  to StandaloneMM runtime variable service.
> +#
> +# Copyright (c) 2019, ARM Ltd. All right

Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

2019-03-01 Thread Ard Biesheuvel
On Fri, 1 Mar 2019 at 15:59, Laszlo Ersek  wrote:
>
> +Peter
>
> On 03/01/19 13:24, Heyi Guo wrote:
> > On 2019/2/28 21:39, Laszlo Ersek wrote:
>
> >> (4) What's most worrying is that this change would lead to an unexpected
> >> sharing of the PL011 device between the OS and the firmware. I don't
> >> think that's a great idea, especially if QEMU's ACPI payload explicitly
> >> advertises the port to the OS.
> > That's true, so I propose to disable the feature by default. It is only
> > used for UEFI runtime code debug. It is always painful when we don't a
> > handy debug tool for runtime services code.
>
> I think this is the only problem that we have at the design level.
>
> What I'd like to understand is whether it is safe to drive the PL011
> serial port from both the firmware and the kernel. Consider a situation
> where one VCPU in the guest executes a runtime service call, and writes
> to PL011 from firmware code. Meanwhile a different VCPU in the guest
> executes some kernel code that produces a log message directly on the
> serial console. (Because, I don't think that a runtime service call on
> one CPU stops the world for *all* CPUs, in the Linux kernel.) For
> starters, the serial output could be garbled, as a consequence, but will
> the PL011 register state be messed up irrevocably as well? I don't know.
>

This is fundamentally broken. The OS will drive the PL011 in interrupt
mode, while the firmware will poll the FIFO registers directly.

> This is why I'm not a big fan of this approach. Using separate devices
> for kernel and firmware would be a lot better.
>

+1

> I remember that Peter did some work to enable two PL011 devices on the
> "virt" board. IIRC the issue was that the PL011 enumeration order /
> numbering in edk2, and in the Linux (guest) kernel, was exactly the
> opposite. And that caused both logs to go to different devices; you
> couldn't have a single log file that started with the firmware log, and
> continued (after a definite switch-over) with the kernel log.
>
> But in this case, where the firmware could produce log messages on
> serial during OS runtime, that's actually the setup I would recommend. A
> clean separation between the serial devices used by the firmware and the OS.
>
> The rest of the issues in this series should be more simple to clean up
> (rework some commit messages, remove stale code etc).
>
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems

2019-03-01 Thread Ard Biesheuvel
On Fri, 1 Mar 2019 at 11:54, Cohen, Eugene  wrote:
>
> Ard,
>
> > So before these changes, we were in the exact same situation, but since PC
> > platforms never enable DMA above 4 GB in the first place, nobody ever
> > noticed until we started running this code on arm64 platforms that have no
> > 32-bit addressable DRAM to begin with.
>
> Interesting - I did not realize that there were designs that were crazy 
> enough to have no addressable DRAM below 4G.
>

You must be new here :-)

But seriously, it does make sense for an implementation to, say, put
all peripherals, PCIe resource windows etc in the bottom half and all
DRAM in the top half of a 40-bit address space, which is how the AMD
Seattle SoC ended with its system memory at address 0x80__.
Note that on this platform, we can still use 32-bit DMA if we want to
with the help of the SMMUs, but we haven't wired those up in UEFI (and
the generic host bridge driver did not have the IOMMU hooks at the
time)

> > The obvious conclusion is that the driver should not set the
> > EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the device does
> > not support it, or, which seems to be our case, if the driver does not
> > implement the 64-bit DMA mode that the driver does support. However,
> > since there are platforms for which bounce buffering is not an option (since
> > there is no 32-bit addressable memory to bounce to), this is not just a
> > performance optimization, and so it would be useful to fix the code so it 
> > can
> > drive all 64-bit DMA capable hardware.
>
> Okay, that's a great reason - let's get V3 64b ADMA2 in!
>
> Any objection to committing the original patch in the short term?
>

not at all

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


Re: [edk2] [PATCH v2] MdePkg/Library: Install dummy variable arch protocol

2019-03-01 Thread Ard Biesheuvel
On Fri, 1 Mar 2019 at 12:14, Jagadeesh Ujja  wrote:
>
> In a system implementing the variable store in MM, there are no variable
> arch protocol and variable write arch protocol installed into the
> DXE_SMM protocol database. On such systems, it is not required to
> locate these protocols by the DXE runtime variable drivers because
> it can be assumed that these protocols are already installed in the MM
> context. But then such an implementation will deviate from the existing
> traditional MM based variable driver implementation.
>
> So in order to maintain consistency with the traditional MM variable
> driver implementation, allow platforms to install dummy versions of
> these protocols into the DXE protocol database but these protocol will
> not be consumed by non-secure variable service runtime driver.
>
> The Platform which uses StandaloneMM based secure variable storage
> have to include this library as below.
>
>   ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
> 
>   NULL|MdePkg/Library/VariableMmDependency/VariableMmDependency.inf
>   }
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja 
> ---
> Changes since v1:
> - This is a next version of patch
>“MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch 
> Protocol”.
>[https://lists.01.org/pipermail/edk2-devel/2019-February/036885.html]
> - Addressed the comments from Ard Biesheuvel and Zeng Star
> - Can this library be placed in MdePkg rather then the StandaloneMmPkg?
>

This does not belong in MdePkg. What is wrong with keeping it in
StandaloneMmPkg?

>  MdePkg/Library/VariableMmDependency/VariableMmDependency.c   | 85 
> 
>  MdePkg/Library/VariableMmDependency/VariableMmDependency.inf | 48 +++
>  2 files changed, 133 insertions(+)
>
> diff --git a/MdePkg/Library/VariableMmDependency/VariableMmDependency.c 
> b/MdePkg/Library/VariableMmDependency/VariableMmDependency.c
> new file mode 100644
> index 000..6e5117e
> --- /dev/null
> +++ b/MdePkg/Library/VariableMmDependency/VariableMmDependency.c
> @@ -0,0 +1,85 @@
> +/** @file
> +  Runtime DXE part corresponding to StanaloneMM variable module.
> +
> +This module installs dummy variable arch protocol and dummy variable write 
> arch protocol
> +to StandaloneMM runtime variable service.
> +

I think 'dummy' is a misnomer here. They are NULL protocols in the
sense that only their presence is signifcant, and the protocol does
not have an implementation. But this is true for traditional MM as
well.

> +Copyright (c) 2019, 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.
> +
> +**/
> +
> +#include 
> +#include 
> +
> +/**
> +  Notify the system that the SMM variable driver is ready.
> +**/
> +VOID
> +VariableNotifySmmReady (
> +  VOID
> +  )
> +{
> +  EFI_STATUSStatus;
> +  EFI_HANDLEHandle;
> +
> +  Handle = NULL;
> +  Status = gBS->InstallProtocolInterface (
> +  ,
> +  ,
> +  EFI_NATIVE_INTERFACE,
> +  NULL
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +}
> +
> +/**
> +  Notify the system that the SMM variable write driver is ready.
> +**/
> +VOID
> +VariableNotifySmmWriteReady (
> +  VOID
> +  )
> +{
> +  EFI_STATUSStatus;
> +  EFI_HANDLEHandle;
> +
> +  Handle = NULL;
> +  Status = gBS->InstallProtocolInterface (
> +  ,
> +  ,
> +  EFI_NATIVE_INTERFACE,
> +  NULL
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +}
> +
> +/**
> +  The constructor function calls and installs dummy variable arch protocol 
> and
> +  dummy variable write arch protocol to StandaloneMM runtime variable service
> +
> +  @param  ImageHandle   The firmware allocated handle for the EFI image.
> +  @param  SystemTable   A pointer to the Management mode System Table.
> +
> +  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +VariableMmDependencyLibConstructor (
> +  IN EFI_HANDLE   ImageHandle,
> +  IN EFI_SYSTEM_TABLE *Syst

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems

2019-03-01 Thread Ard Biesheuvel
On Fri, 1 Mar 2019 at 11:32, Ard Biesheuvel  wrote:
>
> On Fri, 1 Mar 2019 at 01:19, Ashish Singhal  wrote:
> >
> > Eugene,
> >
> > Small question. Did the issue appear after the V4 patch went in? Looking at 
> > the code before that patch, we were enabling 64b dma in pci based on 
> > capability register already despite of driver supporting only 32b dma.
> >
>
> I think this may have been an oversight on my part when I originally
> added the DUAL_ADDRESS_CYCLE handling.
>
> The following commit added EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE to the
> host bridge driver
>
> commit e58a71d9c50ba641b5ab19f5ce2cbf772187de4d
> Author: Ard Biesheuvel 
> Date:   Mon Sep 5 09:55:16 2016 +0100
>
> MdeModulePkg/PciHostBridgeDxe: restrict 64-bit DMA to devices that
> support it
>
> Currently, the EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is 
> completely
> ignored by the PCI host bridge driver, which means that, on an
> implementation
> that supports DMA above 4 GB, allocations above 4 GB may be provided to
> devices that have not expressed support for it.
>
> and the SDHCI driver was fixed accordingly in
>
> Author: Ard Biesheuvel 
> Date:   Mon Sep 5 09:51:48 2016 +0100
>
> MdeModulePkg/SdMmcPciHcDxe: enable 64-bit PCI DMA
>
> PCI controller drivers must set the 
> EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE
> attribute if the controller supports 64-bit DMA addressing.
>
> So before these changes, we were in the exact same situation, but
> since PC platforms never enable DMA above 4 GB in the first place,
> nobody ever noticed until we started running this code on arm64
> platforms that have no 32-bit addressable DRAM to begin with.
>
> The obvious conclusion is that the driver should not set the
> EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the device does
> not support it, or, which seems to be our case, if the driver does not
> implement the 64-bit DMA mode that the driver does support.

Correction: that the *device* does support.

> However,
> since there are platforms for which bounce buffering is not an option
> (since there is no 32-bit addressable memory to bounce to), this is
> not just a performance optimization, and so it would be useful to fix
> the code so it can drive all 64-bit DMA capable hardware.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems

2019-03-01 Thread Ard Biesheuvel
On Fri, 1 Mar 2019 at 01:19, Ashish Singhal  wrote:
>
> Eugene,
>
> Small question. Did the issue appear after the V4 patch went in? Looking at 
> the code before that patch, we were enabling 64b dma in pci based on 
> capability register already despite of driver supporting only 32b dma.
>

I think this may have been an oversight on my part when I originally
added the DUAL_ADDRESS_CYCLE handling.

The following commit added EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE to the
host bridge driver

commit e58a71d9c50ba641b5ab19f5ce2cbf772187de4d
Author: Ard Biesheuvel 
Date:   Mon Sep 5 09:55:16 2016 +0100

MdeModulePkg/PciHostBridgeDxe: restrict 64-bit DMA to devices that
support it

Currently, the EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is completely
ignored by the PCI host bridge driver, which means that, on an
implementation
that supports DMA above 4 GB, allocations above 4 GB may be provided to
devices that have not expressed support for it.

and the SDHCI driver was fixed accordingly in

Author: Ard Biesheuvel 
Date:   Mon Sep 5 09:51:48 2016 +0100

MdeModulePkg/SdMmcPciHcDxe: enable 64-bit PCI DMA

PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE
attribute if the controller supports 64-bit DMA addressing.

So before these changes, we were in the exact same situation, but
since PC platforms never enable DMA above 4 GB in the first place,
nobody ever noticed until we started running this code on arm64
platforms that have no 32-bit addressable DRAM to begin with.

The obvious conclusion is that the driver should not set the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the device does
not support it, or, which seems to be our case, if the driver does not
implement the 64-bit DMA mode that the driver does support. However,
since there are platforms for which bounce buffering is not an option
(since there is no 32-bit addressable memory to bounce to), this is
not just a performance optimization, and so it would be useful to fix
the code so it can drive all 64-bit DMA capable hardware.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 0/4] Various Packages: add MM_STANDALONE support

2019-02-28 Thread Ard Biesheuvel
On Mon, 21 Jan 2019 at 15:34, Ard Biesheuvel  wrote:
>
> On Mon, 21 Jan 2019 at 13:49, Gao, Liming  wrote:
> >
> > Ard:
> >   The patches created by you recently is to support the standalone MM 
> > authenticated variable stack. This is likely a new feature.
> >
> >   Could you help submit BZ for this new feature or reuse the existing BZ? 
> > And, update 
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
> >  to include it for edk2-stable201903 tag.
> >
>
> I will add a bugzilla entry for the remaining standalone MM work, but
> could someone please add StandaloneMmPkg to the bugzilla packages
> list? Thanks.

Mike,

Could you please make this change to bugzilla? We need it to log work
for StandaloneMmPkg.

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


Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

2019-02-28 Thread Ard Biesheuvel
On Thu, 28 Feb 2019 at 09:06, Heyi Guo  wrote:
>
> Serial port output is useful when debugging UEFI runtime services in OS 
> runtime.
> The patches are trying to provide a handy method to enable runtime serial port
> debug for ArmVirtQemu.
>
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Julien Grall 
>
> Heyi Guo (3):
>   MdeModulePkg/StatusCode: Add PCD to enable runtime serial debug
>   ArmVirtPkg: add runtime instance of FdtPL011SerialPortLib
>   ArmVirtQemu: enable runtime debug by build flag
>

Hello Heyi,

We have had this discussion before, and IIRC, the proposed solution
was to use status codes.

I'm not sure how that is supposed to work though - hopefully Laszlo or
one of the MdeModulePkg maintainers can elaborate.



>  ArmVirtPkg/ArmVirt.dsc.inc   
>|   6 ++
>  ArmVirtPkg/ArmVirtQemu.dsc   
>|  13 +++
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
>|   5 +
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c 
>|  29 --
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.h 
>|  27 +
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.inf   
>|   3 +
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLibCommon.c   
>|  27 +
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLibRuntime.c  
>| 104 
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLibRuntime.inf
>|  58 +++
>  MdeModulePkg/MdeModulePkg.dec
>|   6 ++
>  MdeModulePkg/MdeModulePkg.uni
>|   6 ++
>  
> MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.c
>|   2 +-
>  
> MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
>  |   7 +-
>  13 files changed, 279 insertions(+), 14 deletions(-)
>  create mode 100644 
> ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.h
>  create mode 100644 
> ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLibCommon.c
>  create mode 100644 
> ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLibRuntime.c
>  create mode 100644 
> ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLibRuntime.inf
>
> --
> 1.8.3.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch] BaseTools: Add python3-distutils Ubuntu package checking

2019-02-27 Thread Ard Biesheuvel
On Tue, 26 Feb 2019 at 02:05, Feng, Bob C  wrote:
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=1509
>
> Add python3-distutils Ubuntu package checking.
>

Hi Bob,

This assumes that all Linux systems are Ubuntu based, which is not
true. The apt tool is specific to Debian/Ubuntu, Fedora/Redhat and
Suse all use something else.

In general, I don't think we should validate the Python environment to
this extent, since we cannot fix the problem for the user anyway, only
flag it, and since python explodes rather loudly in this case, I think
we should be able to leave it up to developers that are savvy enough
to build EDK2 to also find the python distutils package for their
platform.

Note that that doesn't mean we shouldn't document this, and not just
for Ubuntu. But I think putting it in the script is overkill.

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> ---
>  BaseTools/Tests/RunTests.py | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/BaseTools/Tests/RunTests.py b/BaseTools/Tests/RunTests.py
> index 0dd65632d0..64778db981 100644
> --- a/BaseTools/Tests/RunTests.py
> +++ b/BaseTools/Tests/RunTests.py
> @@ -17,10 +17,24 @@
>  #
>  import os
>  import sys
>  import unittest
>
> +distutils_exist = True
> +try:
> +import distutils.util
> +except:
> +distutils_exist = False
> +
> +if not distutils_exist:
> +print("""
> +python3-distutil packages is missing. Please install it with the following 
> command:
> +
> +bash$ sudo apt-get install python3-distutil
> +""")
> +sys.exit(-1)
> +
>  import TestTools
>
>  def GetCTestSuite():
>  import CToolsTests
>  return CToolsTests.TheTestSuite()
> --
> 2.20.1.windows.1
>
> ___
> 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 v2 edk2-platforms 6/8] SgiClark.Ares: AcpiTables: Add entry for virtio network device

2019-02-26 Thread Ard Biesheuvel
On Tue, 26 Feb 2019 at 14:17, Vijayenthiran Subramaniam
 wrote:
>
> Hi Ard,
>
> This patch is part of the patch series "Platform/ARM/Sgi: Add support for 
> virtio network device". While other seven patches are merged upstream, this 
> patch is not yet merged. Please let me know if you have any comments on this 
> patch.
>

Apologies for that, this wasn't intentional.

Reviewed-by: Ard Biesheuvel 

Pushed as 54f98cb1789a..c63c3f071271


> On Fri, Dec 14, 2018 at 11:28 PM Vijayenthiran Subramaniam 
>  wrote:
>>
>> SgiClark Ares include an instance of the virtio network device. Add
>> a representation for it in the ACPI tables.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Vijayenthiran Subramaniam 
>> ---
>>  Platform/ARM/SgiPkg/AcpiTables/SgiClarkAresAcpiTables.inf |  3 +++
>>  Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Dsdt.asl  | 17 
>> +
>>  2 files changed, 20 insertions(+)
>>
>> diff --git a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAresAcpiTables.inf 
>> b/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAresAcpiTables.inf
>> index 10a805e07fd1..d4bacdbc8c85 100644
>> --- a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAresAcpiTables.inf
>> +++ b/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAresAcpiTables.inf
>> @@ -58,5 +58,8 @@ [FixedPcd]
>>gArmSgiTokenSpaceGuid.PcdVirtioBlkBaseAddress
>>gArmSgiTokenSpaceGuid.PcdVirtioBlkSize
>>gArmSgiTokenSpaceGuid.PcdVirtioBlkInterrupt
>> +  gArmSgiTokenSpaceGuid.PcdVirtioNetBaseAddress
>> +  gArmSgiTokenSpaceGuid.PcdVirtioNetSize
>> +  gArmSgiTokenSpaceGuid.PcdVirtioNetInterrupt
>>
>>gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
>> diff --git a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Dsdt.asl 
>> b/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Dsdt.asl
>> index af4dc424a77c..69dc33c06b4d 100644
>> --- a/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Dsdt.asl
>> +++ b/Platform/ARM/SgiPkg/AcpiTables/SgiClarkAres/Dsdt.asl
>> @@ -118,5 +118,22 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", 
>> "ARMSGI",
>>  }
>>})
>>  }
>> +
>> +// VIRTIO NET
>> +Device (VR01) {
>> +  Name (_HID, "LNRO0005")
>> +  Name (_UID, 1)
>> +  Name (_CCA, 1)// mark the device coherent
>> +
>> +  Name (_CRS, ResourceTemplate() {
>> +Memory32Fixed (ReadWrite,
>> +  FixedPcdGet32 (PcdVirtioNetBaseAddress),
>> +  FixedPcdGet32 (PcdVirtioNetSize)
>> +)
>> +Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) {
>> +  FixedPcdGet32 (PcdVirtioNetInterrupt)
>> +}
>> +  })
>> +}
>>} // Scope(_SB)
>>  }
>> --
>> 2.7.4
>>
>> ___
>> 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 1/1] ArmPkg: Fix writes to GICv3 GICD_IROUTER reg

2019-02-25 Thread Ard Biesheuvel
On Fri, 22 Feb 2019 at 20:43, Sami Mujawar  wrote:
>
> According to ARM Generic Interrupt Controller Architecture
> Specification, GIC architecture version 3.0 and version 4.0,
> GICD_IROUTER is a 64-bit register.
>
> Fixed code to use 64 bit MMIO write operations so that the
> Aff3 value (bits [39:32]) is written to GICD_IROUTER.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sami Mujawar 
> Reported-by: Carl van Schaik 

Thanks Sami

Reviewed-by: Ard Biesheuvel 

Pushed as 1342d7679e10..1bb76029eff4


> ---
>
> The changes can be seen at 
> https://github.com/samimujawar/edk2/tree/352_fix_gicv3_GICD_IROUTERn_v1
>
>
>  ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
> b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
> index 
> 1558db31713a828f324a807583076b21dd3302d0..67c74f79654586f8b6e47795d3c7400b88172d6e
>  100644
> --- a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
> +++ b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
> @@ -1,6 +1,6 @@
>  /** @file
>  *
> -*  Copyright (c) 2011-2017, ARM Limited. All rights reserved.
> +*  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
> @@ -467,7 +467,7 @@ GicV3DxeInitialize (
>
>  // Route the SPIs to the primary CPU. SPIs start at the INTID 32
>  for (Index = 0; Index < (mGicNumInterrupts - 32); Index++) {
> -  MmioWrite32 (
> +  MmioWrite64 (
>  mGicDistributorBase + ARM_GICD_IROUTER + (Index * 8),
>  CpuTarget
>  );
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 1/1] EmbeddedPkg: Fix multiple Virtual RTC issues

2019-02-25 Thread Ard Biesheuvel
On Tue, 26 Feb 2019 at 00:52, Pete Batard  wrote:
>
> LibGetTime():
> - Two variables were used for the epoch, where only one should have been.
> - Also harmonize variable name to match the one used in LibSetTime.
> LiBSetTime():
> - Address possible underflows if time is set to start of epoch.
> - Ensure that time being read does actually match time that was manually
>   set (plus the time elapsed since), by subtracting number of seconds
>   since reset.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pete Batard 

Thanks Pete

Reviewed-by: Ard Biesheuvel 

Pushed as 9ab4ec518882..1342d7679e10
> ---
>  EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c | 34 
> ++--
>  1 file changed, 25 insertions(+), 9 deletions(-)
>
> diff --git 
> a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c 
> b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> index 4c354730d02b..5559106b696f 100644
> --- a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> @@ -54,13 +54,12 @@ LibGetTime (
>)
>  {
>EFI_STATUS  Status;
> -  UINT32  EpochSeconds;
>INT16   TimeZone;
>UINT8   Daylight;
>UINT64  Freq;
>UINT64  Counter;
>UINT64  Remainder;
> -  UINTN   ElapsedSeconds;
> +  UINTN   EpochSeconds;
>UINTN   Size;
>
>if (Time == NULL) {
> @@ -75,13 +74,13 @@ LibGetTime (
>
>// Get the epoch time from non-volatile storage
>Size = sizeof (UINTN);
> -  ElapsedSeconds = 0;
> +  EpochSeconds = 0;
>Status = EfiGetVariable (
>   (CHAR16 *)mEpochVariableName,
>   ,
>   NULL,
>   ,
> - (VOID *)
> + (VOID *)
>   );
>// Fall back to compilation-time epoch if not set
>if (EFI_ERROR (Status)) {
> @@ -93,7 +92,7 @@ LibGetTime (
>  // If you are attempting to use this library on such an environment, 
> please
>  // contact the edk2 mailing list, so we can try to add support for it.
>  //
> -ElapsedSeconds = BUILD_EPOCH;
> +EpochSeconds = BUILD_EPOCH;
>  DEBUG ((
>DEBUG_INFO,
>"LibGetTime: %s non volatile variable was not found - Using 
> compilation time epoch.\n",
> @@ -101,7 +100,7 @@ LibGetTime (
>));
>}
>Counter = GetPerformanceCounter ();
> -  ElapsedSeconds += DivU64x64Remainder (Counter, Freq, );
> +  EpochSeconds += DivU64x64Remainder (Counter, Freq, );
>
>// Get the current time zone information from non-volatile storage
>Size = sizeof (TimeZone);
> @@ -204,7 +203,7 @@ LibGetTime (
>  }
>}
>
> -  EpochToEfiTime (ElapsedSeconds, Time);
> +  EpochToEfiTime (EpochSeconds, Time);
>
>// Because we use the performance counter, we can fill the Nanosecond 
> attribute
>// provided that the remainder doesn't overflow 64-bit during 
> multiplication.
> @@ -240,6 +239,9 @@ LibSetTime (
>)
>  {
>EFI_STATUS  Status;
> +  UINT64  Freq;
> +  UINT64  Counter;
> +  UINT64  Remainder;
>UINTN   EpochSeconds;
>
>if (!IsTimeValid (Time)) {
> @@ -249,16 +251,30 @@ LibSetTime (
>EpochSeconds = EfiTimeToEpoch (Time);
>
>// Adjust for the correct time zone, i.e. convert to UTC time zone
> -  if (Time->TimeZone != EFI_UNSPECIFIED_TIMEZONE) {
> +  if ((Time->TimeZone != EFI_UNSPECIFIED_TIMEZONE)
> +  && (EpochSeconds > Time->TimeZone * SEC_PER_MIN)) {
>  EpochSeconds -= Time->TimeZone * SEC_PER_MIN;
>}
>
>// Adjust for the correct period
> -  if ((Time->Daylight & EFI_TIME_IN_DAYLIGHT) == EFI_TIME_IN_DAYLIGHT) {
> +  if (((Time->Daylight & EFI_TIME_IN_DAYLIGHT) == EFI_TIME_IN_DAYLIGHT)
> +  && (EpochSeconds > SEC_PER_HOUR)) {
>  // Convert to un-adjusted time, i.e. fall back one hour
>  EpochSeconds -= SEC_PER_HOUR;
>}
>
> +  // Use the performance counter to substract the number of seconds
> +  // since platform reset. Without this, setting time from the shell
> +  // and immediately reading it back would result in a forward time
> +  // offset, of the duration during which the platform has been up.
> +  Freq = GetPerformanceCounterProperties (NULL, NULL);
> +  if (Freq != 0) {
> +Counter = GetPerformanceCounter ();
> +if (EpochSeconds > DivU64x64Remainder (Counter, Freq, )) {
> +  EpochSeconds -= DivU64x64Remainder (Counter, Freq, );
> +}
> +  }
> +
>// Save the current time zone information into non-volatile storage
>Status = EfiSetVariable (
>   (CHAR16 *)mTimeZoneVariableName,
> --
> 2.17.0.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch V2] BaseTool: Fixed incremental rebuild issue.

2019-02-23 Thread Ard Biesheuvel
On Sat, 23 Feb 2019 at 11:14, Marcin Wojtas  wrote:
>
> Hi Laszlo,
>
> pt., 22 lut 2019 o 21:08 Laszlo Ersek  napisał(a):
> >
> > On 02/22/19 20:21, Ard Biesheuvel wrote:
> > > On Fri, 22 Feb 2019 at 08:26, Gao, Liming  wrote:
> > >>
> > >> Reviewed-by: Liming Gao 
> > >>
> > >
> > > Incremental builds are still broken for me, even with this patch. Is
> > > anyone else seeing the same?
> >
> > I am not; but I've been using Python3.4 for a while now (it is needed by
> > another package on my system, and then the build tools find it too).
> >
> > The regression is attributed to commit d943b0c339fe ("BaseTools: Handle
> > the bytes and str difference", 2019-02-01), which I believe is related
> > to the python2/3 conversion. So I assume python3.4 masks the problem.
> >
>
> In my setup with the latest BaseTools update this problem is gone. I'm
> using Python 3.5.2.
>

Thanks for confirming.

I did a full clean of my workspace, and now things are working for me
again as well.

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


Re: [edk2] [Patch V2] BaseTool: Fixed incremental rebuild issue.

2019-02-22 Thread Ard Biesheuvel
On Fri, 22 Feb 2019 at 08:26, Gao, Liming  wrote:
>
> Reviewed-by: Liming Gao 
>

Incremental builds are still broken for me, even with this patch. Is
anyone else seeing the same?


> >-Original Message-
> >From: Feng, Bob C
> >Sent: Wednesday, February 20, 2019 11:22 PM
> >To: edk2-devel@lists.01.org
> >Cc: Feng, Bob C ; Gao, Liming 
> >Subject: [Patch V2] BaseTool: Fixed incremental rebuild issue.
> >
> >BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1540
> >
> >This issue in introduced by commit
> >d943b0c339fe3d35ffdf9f580ccb7a55915c6854
> >
> >To convert bytes to string, we need to use bytes.decode()
> >instead of using str(bytes).
> >
> >If the source file is not a txt file, ignore that file.
> >
> >Contributed-under: TianoCore Contribution Agreement 1.1
> >Signed-off-by: Bob Feng 
> >Cc: Liming Gao 
> >---
> > BaseTools/Source/Python/AutoGen/GenMake.py  | 16 
> > .../Source/Python/Workspace/DscBuildData.py | 17 -
> > 2 files changed, 16 insertions(+), 17 deletions(-)
> >
> >diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py
> >b/BaseTools/Source/Python/AutoGen/GenMake.py
> >index 53c5b8577d..b441817b52 100644
> >--- a/BaseTools/Source/Python/AutoGen/GenMake.py
> >+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
> >@@ -1043,18 +1043,18 @@ cleanlib:
> > Fd.close()
> > except BaseException as X:
> > EdkLogger.error("build", FILE_OPEN_FAILURE, 
> > ExtraData=F.Path +
> >"\n\t" + str(X))
> > if len(FileContent) == 0:
> > continue
> >-
> >-if FileContent[0] == 0xff or FileContent[0] == 0xfe:
> >-FileContent = FileContent.decode('utf-16')
> >-else:
> >-try:
> >-FileContent = str(FileContent)
> >-except:
> >-pass
> >+try:
> >+if FileContent[0] == 0xff or FileContent[0] == 0xfe:
> >+FileContent = FileContent.decode('utf-16')
> >+else:
> >+FileContent = FileContent.decode()
> >+except:
> >+# The file is not txt file. for example .mcb file
> >+continue
> > IncludedFileList = gIncludePattern.findall(FileContent)
> >
> > for Inc in IncludedFileList:
> > Inc = Inc.strip()
> > # if there's macro used to reference header file, 
> > expand it
> >diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> >b/BaseTools/Source/Python/Workspace/DscBuildData.py
> >index 1ffefe6e7e..7221946062 100644
> >--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> >+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> >@@ -153,19 +153,18 @@ def GetDependencyList(FileStack, SearchPathList):
> > Fd.close()
> >
> > if len(FileContent) == 0:
> > continue
> >
> >-if FileContent[0] == 0xff or FileContent[0] == 0xfe:
> >-FileContent = FileContent.decode('utf-16')
> >-IncludedFileList = gIncludePattern.findall(FileContent)
> >-else:
> >-try:
> >-FileContent = str(FileContent)
> >-IncludedFileList = gIncludePattern.findall(FileContent)
> >-except:
> >-pass
> >+try:
> >+if FileContent[0] == 0xff or FileContent[0] == 0xfe:
> >+FileContent = FileContent.decode('utf-16')
> >+else:
> >+FileContent = FileContent.decode()
> >+except:
> >+# The file is not txt file. for example .mcb file
> >+continue
> > IncludedFileList = gIncludePattern.findall(FileContent)
> >
> > for Inc in IncludedFileList:
> > Inc = Inc.strip()
> > Inc = os.path.normpath(Inc)
> >--
> >2.18.0.windows.1
>
> ___
> 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] Maintainers.txt: Update e-mail address for Julien Grall

2019-02-21 Thread Ard Biesheuvel
On Thu, 21 Feb 2019 at 16:29, Julien Grall  wrote:
>
> I don't watch much my Linaro e-mail anymore. So update my e-mail address
> from Linaro to the Arm one.
>
> Contributed-under: Tianocore Contribution Agreement 1.1
> Signed-off-by: Julien Grall 

Acked-by: Ard Biesheuvel 

> ---
>  Maintainers.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 3b2676bc32..1e3fdc1de9 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -80,7 +80,7 @@ ArmVirtPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
> -R: Julien Grall 
> +R: Julien Grall 
>
>  BaseTools
>  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
> @@ -217,7 +217,7 @@ M: Jordan Justen 
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
>  R: Anthony Perard 
> -R: Julien Grall 
> +R: Julien Grall 
>  S: Maintained
>
>  PcAtChipsetPkg
> --
> 2.11.0
>
> ___
> 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 v2 0/2] Maintainers: updates for ArmVirtPkg and OvmfPkg

2019-02-21 Thread Ard Biesheuvel
On Thu, 21 Feb 2019 at 13:28, Laszlo Ersek  wrote:
>
> Previous version:
>   [edk2] [PATCH] Maintainers: add TPM2 reviewers for OvmfPkg
>   https://lists.01.org/pipermail/edk2-devel/2019-February/036495.html
>
> Patch #1 in v2 is an iteration of the above. Patch #2 in v2 is new.
>
> Cc: Andrew Fish 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Leif Lindholm 
> Cc: Marc-André Lureau 
> Cc: Michael D Kinney 
> Cc: Stefan Berger 
>
> Thanks,
> Laszlo
>
> Laszlo Ersek (2):
>   Maintainers: add TPM2 reviewers for OvmfPkg
>   Maintainers: specify the scope for OvmfPkg/ArmVirtPkg Xen module
> reviewers
>

Acked-by: Ard Biesheuvel 
  (for the series)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol

2019-02-21 Thread Ard Biesheuvel
On Thu, 21 Feb 2019 at 10:33, Zeng, Star  wrote:
>
> On 2019/2/21 17:11, Ard Biesheuvel wrote:
> > On Thu, 21 Feb 2019 at 10:04, Laszlo Ersek  wrote:
> >>
> >> On 02/20/19 13:23, Ard Biesheuvel wrote:
> >>> On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja  
> >>> wrote:
> >>>>
> >>>> hi Ard,
> >>>> On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel
> >>>>  wrote:
> >>>>>
> >>>>> Hello Jagadeesh,
> >>>>>
> >>>>> On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja  
> >>>>> wrote:
> >>>>>>
> >>>>>> In preparation for providing a standalone MM based non-secure variable
> >>>>>> runtime driver, factor out some portions that are specific to the
> >>>>>> traditional driver, mainly related to locating variable arch protocol
> >>>>>> and variable write arch protocol, which are not required to be located
> >>>>>> when using standalone MM based secure variable implementation.
> >>>>>>
> >>>>>
> >>>>> While i think this change is correct from a technical perspective, I
> >>>>> don't think this is the right approach.
> >>>>>
> >>>> these changes are mandatory, this is one of the possible solution.
> >>>>
> >>>>> It was a deliberate decision to expose the MM services in a way that
> >>>>> only the producer of the communication protocol is aware of the
> >>>>> implementation details, i.e., whether it is backed by tradtional MM or
> >>>>> standalone MM.
> >>>>>
> >>>> can you please provide more details on how "exposing the MM services"
> >>>> will help to resolve the issue here. if this helps, definitely i will 
> >>>> use that.
> >>>>
> >>>
> >>> Let me rephrase this for the benefit of the MdeModulePkg maintainers,
> >>> and ask them their opinion.
> >>>
> >>> Currently, the DXE runtime driver that produces the architectural
> >>> varstore protocols that are based on communication with MM components
> >>> living elsewhere, rely on the EFI protocol database for sequencing.
> >>> I.e., after dispatch, they wait for certain protocols to be installed
> >>> into the DXE protocol database by the SMM drivers before proceeding to
> >>> install the variable arch protocols.
> >>>
> >>> This does not work for standalone MM, since it has no access to the
> >>> DXE protocol database, nor is it needed, since it may be assumed that
> >>> the MM execution context is fully configured by the time the DXE phase
> >>> starts.
> >>>
> >>> Jagadeesh's proposal is to factor this out, and create two different
> >>> .INFs to build the same DXE runtime driver in two different ways. This
> >>> defeats the purpose of having an abstract MM communication protocol,
> >>> so it is something I would like to avoid. On the other hand, is it not
> >>> obvious how to parameterize this requirement in another way.
> >>>
> >>> For the moment, I could live with putting this into a library, and
> >>> leave it up to the platform to ensure the combination of the library
> >>> resolution with the driver that produces the MM communicate protocol
> >>> is a sane one.
> >>>
> >>> Any thoughts?
> >>
> >> I think I'm missing the gist of the library approach; still, would it be
> >> possible for affected platforms (i.e. those that depend on standalone
> >> MM) to procude the necessary DXE protocols (for unblocking the variable
> >> runtime driver) in a platform DXE driver?
> >>
> >
> > Yes, that is the other option: we could create a library that
> > unconditionally produces those protocols and hook it into the MM
> > communication driver via NULL library class resolution.
> >
>
> I am not familiar with standalone MM, either ARM. So may have no much
> valuable opinion.
>
> For this case, standalone MM could not install DXE protocols into DXE
> protocol database to notify the wrapper (VariableSmmRuntimeDxe), so need
> another way to install the DXE protocols, right?

Yes

> Could standalone MM assume the MM handler for variable is ready when MM
> communication driver runs?

Yes

> If yes, a NULL library instance should work (as a stub to install the
> DXE protocols in its constructor). :)
>

Yes, that was my suggestion.

So Jagadeesh, could you please take this approach instead?

- Create a library in StandaloneMmPkg with LIBRARY_CLASS = NULL and a
constructor that installs the two protocols.
- Update your platform so that the MM communication driver is included as

ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
  
NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
}

I don't think this will violate any ordering constraints, given that
the drivers that have a dependency on these protocols also have a
dependency on the MM communicate driver itself.

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


Re: [edk2] [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol

2019-02-21 Thread Ard Biesheuvel
On Thu, 21 Feb 2019 at 10:04, Laszlo Ersek  wrote:
>
> On 02/20/19 13:23, Ard Biesheuvel wrote:
> > On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja  wrote:
> >>
> >> hi Ard,
> >> On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel
> >>  wrote:
> >>>
> >>> Hello Jagadeesh,
> >>>
> >>> On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja  
> >>> wrote:
> >>>>
> >>>> In preparation for providing a standalone MM based non-secure variable
> >>>> runtime driver, factor out some portions that are specific to the
> >>>> traditional driver, mainly related to locating variable arch protocol
> >>>> and variable write arch protocol, which are not required to be located
> >>>> when using standalone MM based secure variable implementation.
> >>>>
> >>>
> >>> While i think this change is correct from a technical perspective, I
> >>> don't think this is the right approach.
> >>>
> >> these changes are mandatory, this is one of the possible solution.
> >>
> >>> It was a deliberate decision to expose the MM services in a way that
> >>> only the producer of the communication protocol is aware of the
> >>> implementation details, i.e., whether it is backed by tradtional MM or
> >>> standalone MM.
> >>>
> >> can you please provide more details on how "exposing the MM services"
> >> will help to resolve the issue here. if this helps, definitely i will use 
> >> that.
> >>
> >
> > Let me rephrase this for the benefit of the MdeModulePkg maintainers,
> > and ask them their opinion.
> >
> > Currently, the DXE runtime driver that produces the architectural
> > varstore protocols that are based on communication with MM components
> > living elsewhere, rely on the EFI protocol database for sequencing.
> > I.e., after dispatch, they wait for certain protocols to be installed
> > into the DXE protocol database by the SMM drivers before proceeding to
> > install the variable arch protocols.
> >
> > This does not work for standalone MM, since it has no access to the
> > DXE protocol database, nor is it needed, since it may be assumed that
> > the MM execution context is fully configured by the time the DXE phase
> > starts.
> >
> > Jagadeesh's proposal is to factor this out, and create two different
> > .INFs to build the same DXE runtime driver in two different ways. This
> > defeats the purpose of having an abstract MM communication protocol,
> > so it is something I would like to avoid. On the other hand, is it not
> > obvious how to parameterize this requirement in another way.
> >
> > For the moment, I could live with putting this into a library, and
> > leave it up to the platform to ensure the combination of the library
> > resolution with the driver that produces the MM communicate protocol
> > is a sane one.
> >
> > Any thoughts?
>
> I think I'm missing the gist of the library approach; still, would it be
> possible for affected platforms (i.e. those that depend on standalone
> MM) to procude the necessary DXE protocols (for unblocking the variable
> runtime driver) in a platform DXE driver?
>

Yes, that is the other option: we could create a library that
unconditionally produces those protocols and hook it into the MM
communication driver via NULL library class resolution.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms] Silicon/AMD/Styx/Drivers/AcpiPlatformDxe: use correct object ref in DBG2

2019-02-20 Thread Ard Biesheuvel
On Wed, 20 Feb 2019 at 15:38, Leif Lindholm  wrote:
>
> On Wed, Feb 20, 2019 at 03:27:41PM +0100, Ard Biesheuvel wrote:
> > The NamespaceString[] field in the DBG2 table should contain a fully
> > qualified ACPI namespace object reference. This was found by fwts.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
>
> Reviewed-by: Leif Lindholm 
>

Thanks.

Pushed as 76d9e9a5da9e..54f98cb1789a

> > ---
> >  Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc 
> > b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> > index 07635aa9dd8e..e55119258bac 100644
> > --- a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> > +++ b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> > @@ -25,7 +25,7 @@
> >  #define EFI_ACPI_DBG2_REVISION 0
> >  #define DBG2_NUM_DEBUG_PORTS   1
> >  #define DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS   1
> > -#define DBG2_NAMESPACESTRING_FIELD_SIZE8
> > +#define DBG2_NAMESPACESTRING_FIELD_SIZE9
> >  #define DBG2_OEM_DATA_FIELD_SIZE   0
> >  #define DBG2_OEM_DATA_FIELD_OFFSET 0
> >
> > @@ -33,7 +33,7 @@
> >  #define DBG2_DEBUG_PORT_SUBTYPE_UEFI   0x0007// Sub 
> > type for UEFI Debug Port
> >  #define PL011_UART_LENGTH  0x1000
> >
> > -#define NAME_STR_UART1 {'C', 'O', 'M', '1', '\0', '\0', '\0', '\0'}
> > +#define NAME_STR_UART1 "\\SB.COM1"
> >  #define NAME_STR_UEFI  {'U', 'E', 'F', 'I', '\0', '\0', '\0', '\0'}
> >
> >
> > --
> > 2.20.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH edk2-platforms] Silicon/AMD/Styx/Drivers/AcpiPlatformDxe: use correct object ref in DBG2

2019-02-20 Thread Ard Biesheuvel
The NamespaceString[] field in the DBG2 table should contain a fully
qualified ACPI namespace object reference. This was found by fwts.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc 
b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
index 07635aa9dd8e..e55119258bac 100644
--- a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
+++ b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
@@ -25,7 +25,7 @@
 #define EFI_ACPI_DBG2_REVISION 0
 #define DBG2_NUM_DEBUG_PORTS   1
 #define DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS   1
-#define DBG2_NAMESPACESTRING_FIELD_SIZE8
+#define DBG2_NAMESPACESTRING_FIELD_SIZE9
 #define DBG2_OEM_DATA_FIELD_SIZE   0
 #define DBG2_OEM_DATA_FIELD_OFFSET 0
 
@@ -33,7 +33,7 @@
 #define DBG2_DEBUG_PORT_SUBTYPE_UEFI   0x0007// Sub type 
for UEFI Debug Port
 #define PL011_UART_LENGTH  0x1000
 
-#define NAME_STR_UART1 {'C', 'O', 'M', '1', '\0', '\0', '\0', '\0'}
+#define NAME_STR_UART1 "\\SB.COM1"
 #define NAME_STR_UEFI  {'U', 'E', 'F', 'I', '\0', '\0', '\0', '\0'}
 
 
-- 
2.20.1

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


Re: [edk2] [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol

2019-02-20 Thread Ard Biesheuvel
On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja  wrote:
>
> hi Ard,
> On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel
>  wrote:
> >
> > Hello Jagadeesh,
> >
> > On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja  wrote:
> > >
> > > In preparation for providing a standalone MM based non-secure variable
> > > runtime driver, factor out some portions that are specific to the
> > > traditional driver, mainly related to locating variable arch protocol
> > > and variable write arch protocol, which are not required to be located
> > > when using standalone MM based secure variable implementation.
> > >
> >
> > While i think this change is correct from a technical perspective, I
> > don't think this is the right approach.
> >
> these changes are mandatory, this is one of the possible solution.
>
> > It was a deliberate decision to expose the MM services in a way that
> > only the producer of the communication protocol is aware of the
> > implementation details, i.e., whether it is backed by tradtional MM or
> > standalone MM.
> >
> can you please provide more details on how "exposing the MM services"
> will help to resolve the issue here. if this helps, definitely i will use 
> that.
>

Let me rephrase this for the benefit of the MdeModulePkg maintainers,
and ask them their opinion.

Currently, the DXE runtime driver that produces the architectural
varstore protocols that are based on communication with MM components
living elsewhere, rely on the EFI protocol database for sequencing.
I.e., after dispatch, they wait for certain protocols to be installed
into the DXE protocol database by the SMM drivers before proceeding to
install the variable arch protocols.

This does not work for standalone MM, since it has no access to the
DXE protocol database, nor is it needed, since it may be assumed that
the MM execution context is fully configured by the time the DXE phase
starts.

Jagadeesh's proposal is to factor this out, and create two different
.INFs to build the same DXE runtime driver in two different ways. This
defeats the purpose of having an abstract MM communication protocol,
so it is something I would like to avoid. On the other hand, is it not
obvious how to parameterize this requirement in another way.

For the moment, I could live with putting this into a library, and
leave it up to the platform to ensure the combination of the library
resolution with the driver that produces the MM communicate protocol
is a sane one.

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


Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths

2019-02-20 Thread Ard Biesheuvel
On Wed, 20 Feb 2019 at 02:19, Wu, Hao A  wrote:
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Sunday, February 03, 2019 8:39 PM
> > To: Wu, Hao A
> > Cc: Jeff Brasen; edk2-devel@lists.01.org; Edgar Handal; Marcin Wojtas
> > Subject: Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit
> > IO widths
> >
> > On Fri, 1 Feb 2019 at 06:55, Wu, Hao A  wrote:
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Jeff
> > > > Brasen
> > > > Sent: Thursday, January 31, 2019 7:59 AM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Edgar Handal; Jeff Brasen
> > > > Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit
> > IO
> > > > widths
> > > >
> > > > From: Edgar Handal 
> > > >
> > > > Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> > > > accesses from being split up into 8-bit accesses.
> > > >
> > > > The SDHCI specification states that the registers shall be accessable in
> > > > byte, word, and double word accesses.
> > >
> >
> > Acked-by: Ard Biesheuvel 
>
> Ard,
>
> Really sorry for missing your 'Acked-by' tag.
> It came to me after I pushed the commit.
>
> Sorry again for this.
>

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


Re: [edk2] [PATCH v2 2/5] OvmfPkg: add library to track boot option loading/starting on the console

2019-02-20 Thread Ard Biesheuvel
On Wed, 20 Feb 2019 at 11:04, Laszlo Ersek  wrote:
>
> On 02/20/19 09:16, Laszlo Ersek wrote:
> > Introduce the Platform Boot Manager Print Status Code Library (for short,
> > PlatformBmPrintScLib) class for catching and printing the LoadImage() /
> > StartImage() preparations, and return statuses, that are reported by
> > UefiBootManagerLib.
> >
> > In the primary library instance, catch only such status codes that
> > UefiBootManagerLib reports from the same module that contains
> > PlatformBmPrintScLib. The intent is to establish a reporting-printing
> > channel within BdsDxe, between UefiBootManagerLib and
> > PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
> > from UiApp's copy of UefiBootManagerLib.
> >
> > Cc: Anthony Perard 
> > Cc: Ard Biesheuvel 
> > Cc: Jordan Justen 
> > Cc: Julien Grall 
> > Cc: Ray Ni 
> > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Laszlo Ersek 
> > ---
> >
> > Notes:
> > v2:
> >
> > - Split the status code handling to a separate library, so that it's
> >   easy to reuse in ArmVirtPkg.
> >
> > - Rework the logic based on
> >   <https://bugzilla.tianocore.org/show_bug.cgi?id=1398> and
> >   <https://mantis.uefi.org/mantis/view.php?id=1885>, and follow Ray's
> >   advice in
> >   
> > <http://mid.mail-archive.com/734D49CCEBEEF84792F5B80ED585239D5BACE29B@SHSMSX104.ccr.corp.intel.com>:
> >
> >   - The boot option details are fetched via BootCurrent.
> >
> >   - For reporting LoadImage() and StartImage() preparations, replace the
> > originally proposed PcdDebugCodeOsLoaderDetail status code with the
> > existent (edk2-specific) PcdProgressCodeOsLoaderLoad and
> > PcdProgressCodeOsLoaderStart status codes.
> >
> >   - For reporting LoadImage() and StartImage() return values, replace
> > the originally proposed PcdDebugCodeOsLoaderDetail status code with
> > the standard EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
> > EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status codes.
> >
> >   - For all four kinds of reports, replace the originally proposed "OS
> > Loader Detail" structure (and GUID) with the recently standardized
> > EFI_RETURN_STATUS_EXTENDED_DATA structure.
> >
> >  OvmfPkg/OvmfPkg.dec   |   5 +
> >  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
> >  OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
> >  OvmfPkg/OvmfPkgX64.dsc|   1 +
> >  OvmfPkg/Include/Library/PlatformBmPrintScLib.h|  41 +++
> >  OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf |  66 +
> >  OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c  | 310 
> > 
> >  7 files changed, 425 insertions(+)
> >
> > diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> > index 7666297cf8f1..e50c6179a249 100644
> > --- a/OvmfPkg/OvmfPkg.dec
> > +++ b/OvmfPkg/OvmfPkg.dec
> > @@ -45,6 +45,11 @@ [LibraryClasses]
> >#  access.
> >PciCapPciSegmentLib|Include/Library/PciCapPciSegmentLib.h
> >
> > +  ##  @libraryclass  Register a status code handler for printing the Boot
> > +  #  Manager's LoadImage() and StartImage() preparations, 
> > and
> > +  #  return codes, to the UEFI console.
> > +  PlatformBmPrintScLib|Include/Library/PlatformBmPrintScLib.h
> > +
> >##  @libraryclass  Access QEMU's firmware configuration interface
> >#
> >QemuFwCfgLib|Include/Library/QemuFwCfgLib.h
> > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> > index f9216af479f4..5b885590b275 100644
> > --- a/OvmfPkg/OvmfPkgIa32.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32.dsc
> > @@ -348,6 +348,7 @@ [LibraryClasses.common.DXE_DRIVER]
> >UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
> >DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
> >
> > PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> > +  
> > PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
> >QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> >
> > CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib

Re: [edk2] [PATCH v2 2/5] OvmfPkg: add library to track boot option loading/starting on the console

2019-02-20 Thread Ard Biesheuvel
On Wed, 20 Feb 2019 at 09:16, Laszlo Ersek  wrote:
>
> Introduce the Platform Boot Manager Print Status Code Library (for short,
> PlatformBmPrintScLib) class for catching and printing the LoadImage() /
> StartImage() preparations, and return statuses, that are reported by
> UefiBootManagerLib.
>
> In the primary library instance, catch only such status codes that
> UefiBootManagerLib reports from the same module that contains
> PlatformBmPrintScLib. The intent is to establish a reporting-printing
> channel within BdsDxe, between UefiBootManagerLib and
> PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
> from UiApp's copy of UefiBootManagerLib.
>
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Ray Ni 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
>
> Notes:
> v2:
>
> - Split the status code handling to a separate library, so that it's
>   easy to reuse in ArmVirtPkg.
>
> - Rework the logic based on
>   <https://bugzilla.tianocore.org/show_bug.cgi?id=1398> and
>   <https://mantis.uefi.org/mantis/view.php?id=1885>, and follow Ray's
>   advice in
>   
> <http://mid.mail-archive.com/734D49CCEBEEF84792F5B80ED585239D5BACE29B@SHSMSX104.ccr.corp.intel.com>:
>
>   - The boot option details are fetched via BootCurrent.
>
>   - For reporting LoadImage() and StartImage() preparations, replace the
> originally proposed PcdDebugCodeOsLoaderDetail status code with the
> existent (edk2-specific) PcdProgressCodeOsLoaderLoad and
> PcdProgressCodeOsLoaderStart status codes.
>
>   - For reporting LoadImage() and StartImage() return values, replace
> the originally proposed PcdDebugCodeOsLoaderDetail status code with
> the standard EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
> EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status codes.
>
>   - For all four kinds of reports, replace the originally proposed "OS
> Loader Detail" structure (and GUID) with the recently standardized
> EFI_RETURN_STATUS_EXTENDED_DATA structure.
>
>  OvmfPkg/OvmfPkg.dec   |   5 +
>  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
>  OvmfPkg/OvmfPkgX64.dsc|   1 +
>  OvmfPkg/Include/Library/PlatformBmPrintScLib.h|  41 +++
>  OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf |  66 +
>  OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c  | 310 
> 
>  7 files changed, 425 insertions(+)
>
...
> diff --git a/OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c 
> b/OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c
> new file mode 100644
> index ..9806d3c7411e
> --- /dev/null
> +++ b/OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c
> @@ -0,0 +1,310 @@
> +/** @file
> +  Register a status code handler for printing the Boot Manager's LoadImage()
> +  and StartImage() preparations, and return codes, to the UEFI console.
> +
> +  This feature enables users that are not accustomed to analyzing the 
> firmware
> +  log to glean some information about UEFI boot option processing (loading 
> and
> +  starting).
> +
> +  This library instance filters out (ignores) status codes that are not
> +  reported by the containing firmware module. The intent is to link this
> +  library instance into BdsDxe via PlatformBootManagerLib (which BdsDxe 
> depends
> +  upon), then catch only those status codes that BdsDxe reports (which 
> happens
> +  via UefiBootManagerLib). Status codes reported by other modules (such as
> +  UiApp), via UefiBootManagerLib or otherwise, are meant to be ignored.
> +
> +  Copyright (C) 2019, Red Hat, Inc.
> +
> +  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 
> +
> +#include 
> +#include 
> +

Re: [edk2] [PATCH 06/10] OvmfPkg/Sec: Disable optimizations for TemporaryRamMigration

2019-02-20 Thread Ard Biesheuvel
On Wed, 20 Feb 2019 at 09:52, Jordan Justen  wrote:
>
> On 2019-02-18 01:32:53, Ard Biesheuvel wrote:
> > On Mon, 18 Feb 2019 at 10:08, Jordan Justen  
> > wrote:
> > >
> > > On 2019-02-17 23:53:01, Ard Biesheuvel wrote:
> > > > On Mon, 18 Feb 2019 at 05:12, Jordan Justen  
> > > > wrote:
> > > > >
> > > >
> > > > This needs an explanation why optimization needs to be disabled.
> > >
> > > I'm not sure this is required. The reason I added these patches is to
> > > hopefully prevent the compiler from removing the frame pointer. We
> > > adjust the frame pointer in the code, and that is a little sketchy if
> > > the frame pointer isn't being used.
> > >
> > > Unfortunately, it can reasonably be argued that the
> > > TemporaryRamSupport PPI definition ultimately makes it unsafe to write
> > > the migration code in C.
> > >
> > > I tried reverting both the EmulatorPkg and OvmfPkg patches for
> > > disabling the optimizations, and with my setup there was no impact. I
> > > think there is a good change that we'd be pretty safe to just drop
> > > these two patches to wait and see if someone encounters a situation
> > > that requires it.
> > >
> > > Ok, so based on this explanation, do you think I should add info to
> > > the commit message and keep the patches, or just drop them?
> > >
> >
> > I think 'little sketchy' is an understatement here (as is
> > setjmp/longjmp in general), but it is the reality we have to deal with
> > when writing startup code in C. Looking at the code, I agree that the
> > fact that [re]bp is assigned directly implies that we should not
> > permit it to be used as a general purpose register, especially when
> > you throw LTO into the mix, which could produce all kinds of
> > surprising results when it decides to inline functions being called
> > from here.
> >
> > For GCC/Clang, I don't think it is correct to assume that changing the
> > optimization level will result in -fno-omit-frame-pointer to be set,
> > so I'd prefer setting that option directly, either via the pragma, or
> > for the whole file.
>
> Based on: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>
> It appears that -O0 will not have -fomit-frame-pointer, since that is
> added in -O1.
>

For current versions of GCC, perhaps. But what about older versions?
What about future versions? What about Clang?

> For both gcc and MSVC, I think we could be more targeted:
>
>  #ifdef __GNUC__
>  #pragma GCC push_options
>  #pragma GCC optimize ("no-omit-frame-pointer")
>  #else
>  #pragma optimize ("y", off)
>  #endif
>
> Do you prefer this version?
>

Assuming that "y" affects frame pointer generation, yes.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 1/1] EmbeddedPkg/Library: Add VirtualRealTimeClockLib

2019-02-19 Thread Ard Biesheuvel
On Fri, 15 Feb 2019 at 15:57, Pete Batard  wrote:
>
> On 2019-02-15 14:39, Ard Biesheuvel wrote:
> > On Fri, 15 Feb 2019 at 11:07, Ard Biesheuvel  
> > wrote:
> >>
> >> On Tue, 12 Feb 2019 at 19:14, Leif Lindholm  
> >> wrote:
> >>>
> >>> On Mon, Feb 04, 2019 at 12:47:36PM +, Pete Batard wrote:
> >>>> This is designed to be used on platforms where a a real RTC is not
> >>>> available and relies on an RtcEpochSeconds variable having been set or,
> >>>> if that is not the case, falls back to using the epoch embedded at
> >>>> compilation time.
> >>>>
> >>>> Note that, in order to keep things simple for the setting of the
> >>>> compilation time variable, only GCC environments with UNIX-like shells
> >>>> and where a 'date' command is available are meant to be supported for
> >>>> now.
> >>>>
> >>>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>>> Signed-off-by: Pete Batard 
> >>>
> >>> On the whole, this looks good to me.
> >>> One addition we'll need, so that we can build this library standalone
> >>> is an entry in EmbeddedPkg.dsc:
> >>>
> >>> diff --git a/EmbeddedPkg/EmbeddedPkg.dsc b/EmbeddedPkg/EmbeddedPkg.dsc
> >>> index 4d9e6399d5..dc5040e611 100644
> >>> --- a/EmbeddedPkg/EmbeddedPkg.dsc
> >>> +++ b/EmbeddedPkg/EmbeddedPkg.dsc
> >>> @@ -218,6 +218,7 @@ [Components.common]
> >>> EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.inf
> >>> EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.inf
> >>> 
> >>> EmbeddedPkg/Library/DxeDtPlatformDtbLoaderLibDefault/DxeDtPlatformDtbLoaderLibDefault.inf
> >>> +  EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
> >>> EmbeddedPkg/EmbeddedMonotonicCounter/EmbeddedMonotonicCounter.inf
> >>> EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
> >>>
> >>> I don't have any strong opinions on either of Phil's suggestions, but
> >>> if you could give some feedback on those and fold the above in, this
> >>> could go in.
> >>>
> >>
> >> WIth this addition
> >>
> >> Reviewed-by: Ard Biesheuvel 
> >>
> >> Pushed as 1b261a705f94..64a17fadcb79
> >
> > OK, there is a problem with this code:
> >
> > +EFI_STATUS
> > +EFIAPI
> > +LibGetTime (
> > +  OUT EFI_TIME   *Time,
> > +  OUT EFI_TIME_CAPABILITIES  *Capabilities
> > +  )
> > +{
> > +  EFI_STATUS  Status;
> > +  UINT32  EpochSeconds;
> >
> > EpochSeconds is declared here, and updated depending on time zone and
> > DST settings. However, the resulting value is never used anywhere.
>
> You're right.
>
> Looks like I forgot to merge all the use of EpochSeconds into
> ElapsedSeconds, from the code I copy/pasted.
>
> I'm very sorry about this, as it's something I should have picked up
> before sending this patch for review.
> > It is not clear to me what the correct fix is, so Pete, could you
> > please look into this?
>
> I'll send a fix for this as soon as I have a chance. Thanks for pointing
> the mistake.
>

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


Re: [edk2] [PATCH 2/2] ArmPlatformPkg/NorFlash: Allow reusability as a MM driver

2019-02-19 Thread Ard Biesheuvel
Hello Jagadeesh,

On Tue, 19 Feb 2019 at 11:32, Jagadeesh Ujja  wrote:
>
> Adapt the NorFlash driver to be used as a MM_STANDALONE driver to
> allow access to NOR flash for code executing in MM_STANDALONE mode.
> This allows storing of EFI variables on NOR flash which is accessible
> only via the MM STANDALONE mode software.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja 
> ---
>  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.c   | 267 
> 
>  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf |  77 ++
>  2 files changed, 344 insertions(+)
>
> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.c 
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.c
> new file mode 100644
> index 000..1e3603c
> --- /dev/null
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.c
> @@ -0,0 +1,267 @@
> +/*++ @file  NorFlashStandaloneMm.c
> +
> + Copyright (c) 2019, 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.
> +
> + --*/
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Please sort alphabetically - I know this originates in existing code,
but it is a brand new file so let's make it clean from the start.

> +
> +#include 
> +#include 
> +#include 

I don't think we need this - please see below.

> +#include "NorFlash.h"
> +
> +//
> +// Global variable declarations
> +//
> +NOR_FLASH_INSTANCE **mNorFlashInstances;
> +UINT32   mNorFlashDeviceCount;
> +

These are definitions, not declarations. Could they be moved to a
shared .c file instead?

> +extern NOR_FLASH_INSTANCE  mNorFlashInstanceTemplate;

Move this to a header?

> +
> +EFI_STATUS
> +EFIAPI
> +NorFlashFvbInitialize (
> +  IN NOR_FLASH_INSTANCE* Instance
> +  )
> +{
> +  EFI_STATUS  Status;
> +  UINT32  FvbNumLba;
> +  EFI_BOOT_MODE BootMode;
> +
> +  DEBUG((DEBUG_BLKIO,"NorFlashFvbInitialize\n"));
> +  ASSERT((Instance != NULL));
> +
> +  mFlashNvStorageVariableBase = FixedPcdGet32 
> (PcdFlashNvStorageVariableBase);
> +
> +  // Set the index of the first LBA for the FVB
> +  Instance->StartLba = (PcdGet32 (PcdFlashNvStorageVariableBase) - 
> Instance->RegionBaseAddress) / Instance->Media.BlockSize;
> +

Please wrap to 80 columns

> +  BootMode = GetBootModeHob ();

Where does the boot mode HOB come from in standalone MM?

> +  if (BootMode == BOOT_WITH_DEFAULT_SETTINGS) {
> +Status = EFI_INVALID_PARAMETER;
> +  } else {
> +// Determine if there is a valid header at the beginning of the NorFlash
> +Status = ValidateFvHeader (Instance);
> +  }
> +


> +  // Install the Default FVB header if required
> +  if (EFI_ERROR(Status)) {
> +// There is no valid header, so time to install one.
> +DEBUG ((EFI_D_INFO, "%a: The FVB Header is not valid.\n", __FUNCTION__));
> +DEBUG ((EFI_D_INFO, "%a: Installing a correct one for this volume.\n",
> +  __FUNCTION__));
> +

Please use DEBUG_INFO not EFI_D_INFO (the latter form is deprecated)

> +// Erase all the NorFlash that is reserved for variable storage
> +FvbNumLba = (PcdGet32(PcdFlashNvStorageVariableSize) + 
> PcdGet32(PcdFlashNvStorageFtwWorkingSize) + 
> PcdGet32(PcdFlashNvStorageFtwSpareSize)) / Instance->Media.BlockSize;
> +

Please wrap to 80 columns

> +Status = FvbEraseBlocks (>FvbProtocol, (EFI_LBA)0, FvbNumLba, 
> EFI_LBA_LIST_TERMINATOR);
> +if (EFI_ERROR(Status)) {
> +  return Status;
> +}
> +
> +// Install all appropriate headers
> +Status = InitializeFvAndVariableStoreHeaders (Instance);
> +if (EFI_ERROR(Status)) {
> +  return Status;
> +}

This if {} is redundant since we will be returning Status anyway.

> +  }
> +
> +  return Status;
> +}
> +
> +VOID
> +EFIAPI
> +NorFlashLock (
> +  NOR_FLASH_LOCK_CONTEXT*Context
> +  )
> +{
> +}
> +
> +VOID
> +EFIAPI
> +NorFlashUnlock (
> +  NOR_FLASH_LOCK_CONTEXT*Context
> +  )
> +{
> +}
> +
> +EFI_STATUS
> +NorFlashCreateInstance (
> +  IN UINTN  NorFlashDeviceBase,
> +  IN UINTN  NorFlashRegionBase,
> +  IN UINTN  NorFlashSize,
> +  IN UINT32 Index,
> +  IN UINT32 BlockSize,
> +  IN BOOLEANSupportFvb,
> +  OUT NOR_FLASH_INSTANCE**  NorFlashInstance
> +  )
> +{
> +  EFI_STATUS Status;
> +  NOR_FLASH_INSTANCE* Instance;
> +
> +  ASSERT(NorFlashInstance != NULL);
> +
> +  Instance = AllocateRuntimeCopyPool 
> (sizeof(NOR_FLASH_INSTANCE),);

Why runtime?

  1   2   3   4   5   6   7   8   9   10   >