Re: [edk2-devel] Getting Synchronous Exception while run avocado-vt tests
On Thu, 22 Aug 2019 at 10:40, Zhanghailiang wrote: > > Hi All, > > > > We caught an ‘Synchronous Exception’ error while booting VM with uefi > firmware in the avocado-vt tests. > > The Edk2 version we used is edk2-stable201905. The qemu version is qemu-4.0.0 > and kernel version is 4.19.0. > > Parts of the log we got from serial is bellow, you can get the full log from > attachment. > > We can easily reproduce this issue with running avocado-vt tests. Actually, > we tried the new edk2 from upstream, > > It is still can be reproduced. > > > > Reproduce command: > > # avocado run type_specific.io-github-autotest-qemu.qmp_event_notification > --vt-type qemu --vt-guest-os Guest.Linux.Fedora.29 > > > > Qemu command is : > .. > > It reports that this is a alignment fault from log, We analyzed the callstack > from log: > > VirtioScsiPassThru-> > VirtioFlush->virtio10SetQueueNotify->Virtio10Transfer->PciIoMemWrite-> > CpuMemoryServiceWrite-> MmioWrite32 <- here, the address is not align. > The faulting address ends in 0x16, so the access is to the QueueSelect field in VIRTIO_PCI_COMMON_CFG. This is a UINT16 field, so the access should be 16-bit not 32-bits wide. Could you dump the instructions leading up to the first Virtio10Transfer() call in Virtio10SetQueueNotify()? (from Build/ArmVirtQemu-AARCH64/DEBUG_GCC49/AARCH64/OvmfPkg/Virtio10Dxe/Virtio10/DEBUG/Virtio10.dll) 2280: aa0103e5mov x5, x1 2284: d2800044mov x4, #0x2// #2 2288: d28002c3mov x3, #0x16 // #22 228c: 5282mov w2, #0x0// #0 2290: aa0003e1mov x1, x0 2294: aa0603e0mov x0, x6 2298: 97fffcf3bl 1664 If the size is passed correctly here, we'll have to track down how the call gets routed to Mmio32Write instead of Mmio16Write(). Do you have any patches on top of edk2-stable-201905 ? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#46209): https://edk2.groups.io/g/devel/message/46209 Mute This Topic: https://groups.io/mt/32987799/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2] [PATCH v4 6/7] MdePkg/UefiBaseType.h: treat EBC as a non-native machine type
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
(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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
