Date   

Re: [Patch 0/2] Add missed character in copyright.

Wu, Jiaxin <jiaxin.wu@...>
 

Series Reviewed-By: Wu Jiaxin <jiaxin.wu@intel.com>

Best Regards!
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Fu
Siyuan
Sent: Monday, August 1, 2016 10:16 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 0/2] Add missed character in copyright.

Fu Siyuan (2):
MdeModulePkg: Add missed character in copyright.
NetworkPkg: Add missed character in copyright.

MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Impl.c | 2 +-
NetworkPkg/Dhcp6Dxe/Dhcp6Io.c | 2 +-
NetworkPkg/TcpDxe/TcpInput.c | 2 +-
NetworkPkg/Udp6Dxe/Udp6Impl.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)

--
2.7.4.windows.1

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


Re: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

Tian, Feng <feng.tian@...>
 

Add Leif's commit log here for better understanding my concern:)

"Import the AArch64 EBC implementation from https://source.codeaurora.org/external/server/edk2-blue/
1/2 does not contain a "Contributed-under:" due to my interpretation of section 4 of the Tianocore Contribution license."

Thanks
Feng

-----Original Message-----
From: Tian, Feng
Sent: Monday, August 1, 2016 10:12 AM
To: Marvin H?user <Marvin.Haeuser@outlook.com>; edk2-devel@lists.01.org; Justen, Jordan L <jordan.l.justen@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Tian, Feng <feng.tian@intel.com>
Subject: RE: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

I may not speak it clear. Sorry for that.

I saw the patch with commit log "Submitted on behalf of a third-party: xxxx". But this is part of "TianoCore Contribution Agreement 1.0 section 4".

And the Contributions.txt clearly says "the commit message must include your "Signed-off-by" signature, and "Contributed-under" message". But the commit log hasn't.

So I am total confused how to solve this case. What's the correct format for this?

I add Jordan & Mike for further comments.

Thanks
Feng

-----Original Message-----
From: Marvin H?user [mailto:Marvin.Haeuser@outlook.com]
Sent: Monday, August 1, 2016 9:58 AM
To: edk2-devel@lists.01.org
Cc: Tian, Feng <feng.tian@intel.com>
Subject: RE: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

Hey Feng,

According to the Contributions document, BSD 2-clause is one of the licenses that can be accepted, if the parent license cannot be used:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Contributions.txt#L25

Regards,
Marvin.

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Tian, Feng
Sent: Monday, August 1, 2016 3:50 AM
To: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org
Cc: Tian, Feng <feng.tian@intel.com>; Daniil Egranov
<daniil.egranov@linaro.org>; Jeff Brasen <jbrasen@codeaurora.org>;
Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
<ard.biesheuvel@linaro.org>
Subject: Re: [edk2] [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM
support

Hi, Leif

If I understand correctly, EDKII doesn't allow such BSD license.

Correct me if anybody has different opinions.

Thanks
Feng

-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
Sent: Saturday, July 30, 2016 12:06 AM
To: edk2-devel@lists.01.org
Cc: Jeff Brasen <jbrasen@codeaurora.org>; Ard Biesheuvel
<ard.biesheuvel@linaro.org>; Daniil Egranov
<daniil.egranov@linaro.org>; Tian, Feng <feng.tian@intel.com>; Zeng,
Star <star.zeng@intel.com>
Subject: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

From: Jeff Brasen <jbrasen@codeaurora.org>

Adds support for the EBC VM for AARCH64 platforms

Submitted on behalf of a third-party: The Linux Foundation This
contribution is licensed under the BSD license as found at
http://opensource.org/licenses/bsd-license.php

[Taken from https://source.codeaurora.org/external/server/edk2-blue/]
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
---
.../Universal/EbcDxe/AArch64/EbcLowLevel.S | 135 +++++
MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c | 563
+++++++++++++++++++++
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf | 6 +-
3 files changed, 703 insertions(+), 1 deletion(-) create mode 100644
MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
create mode 100644
MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c

diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
new file mode 100644
index 0000000..e858227
--- /dev/null
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
@@ -0,0 +1,135 @@
+#/** @file
+#
+# This code provides low level routines that support the Virtual Machine
+# for option ROMs.
+#
+# Copyright (c) 2015, The Linux Foundation. All rights reserved.
+# Copyright (c) 2007 - 2014, Intel Corporation. All rights
+reserved.<BR> # 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.
+#
+#**/
+
+#--------------------------------------------------------------------
+--
+-----
+# Equate files needed.
+#--------------------------------------------------------------------
+--
+-----
+
+ASM_GLOBAL ASM_PFX(CopyMem);
+ASM_GLOBAL ASM_PFX(EbcInterpret);
+ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
+
+#********************************************************
**************
+******
+# EbcLLCALLEX
+#
+# This function is called to execute an EBC CALLEX instruction.
+# This instruction requires that we thunk out to external native #
+code. For AArch64, we copy the VM stack into the main stack and then
+pop # the first 8 arguments off according to the AArch64 Procedure
+Call Standard # On return, we restore the stack pointer to its original location.
+#
+#********************************************************
**************
+****** # UINTN EbcLLCALLEXNative(UINTN FuncAddr, UINTN
NewStackPointer,
+VOID *FramePtr) ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative);
+ASM_PFX(EbcLLCALLEXNative):
+ stp x19, x20, [sp, #-16]!
+ stp x29, x30, [sp, #-16]!
+
+ mov x19, x0
+ mov x20, sp
+ sub x2, x2, x1 // Length = NewStackPointer-FramePtr
+ sub sp, sp, x2
+ sub sp, sp, #64 // Make sure there is room for at least 8
+ args in the new
stack
+ mov x0, sp
+
+ bl CopyMem // Sp, NewStackPointer, Length
+
+ ldp x0, x1, [sp], #16
+ ldp x2, x3, [sp], #16
+ ldp x4, x5, [sp], #16
+ ldp x6, x7, [sp], #16
+
+ blr x19
+
+ mov sp, x20
+ ldp x29, x30, [sp], #16
+ ldp x19, x20, [sp], #16
+
+ ret
+
+#********************************************************
**************
+******
+# EbcLLEbcInterpret
+#
+# This function is called by the thunk code to handle an Native to
+EBC call # This can handle up to 16 arguments (1-8 on in x0-x7, 9-16
+are on the stack) # x9 contains the Entry point that will be the
+first argument when # EBCInterpret is called.
+#
+#********************************************************
**************
+******
+ASM_GLOBAL ASM_PFX(EbcLLEbcInterpret);
+ASM_PFX(EbcLLEbcInterpret):
+ stp x29, x30, [sp, #-16]!
+
+ // copy the current arguments 9-16 from old location and add arg
+ 7 to
stack
+ // keeping 16 byte stack alignment
+ sub sp, sp, #80
+ str x7, [sp]
+ ldr x11, [sp, #96]
+ str x11, [sp, #8]
+ ldr x11, [sp, #104]
+ str x11, [sp, #16]
+ ldr x11, [sp, #112]
+ str x11, [sp, #24]
+ ldr x11, [sp, #120]
+ str x11, [sp, #32]
+ ldr x11, [sp, #128]
+ str x11, [sp, #40]
+ ldr x11, [sp, #136]
+ str x11, [sp, #48]
+ ldr x11, [sp, #144]
+ str x11, [sp, #56]
+ ldr x11, [sp, #152]
+ str x11, [sp, #64]
+
+ // Shift arguments and add entry point and as argument 1
+ mov x7, x6
+ mov x6, x5
+ mov x5, x4
+ mov x4, x3
+ mov x3, x2
+ mov x2, x1
+ mov x1, x0
+ mov x0, x9
+
+ # call C-code
+ bl ASM_PFX(EbcInterpret)
+ add sp, sp, #80
+
+ ldp x29, x30, [sp], #16
+
+ ret
+
+#********************************************************
**************
+******
+# EbcLLExecuteEbcImageEntryPoint
+#
+# This function is called by the thunk code to handle the image entry
+point # x9 contains the Entry point that will be the first argument
+when # ExecuteEbcImageEntryPoint is called.
+#
+#********************************************************
**************
+****** ASM_GLOBAL ASM_PFX(EbcLLExecuteEbcImageEntryPoint);
+ASM_PFX(EbcLLExecuteEbcImageEntryPoint):
+ stp x29, x30, [sp, #-16]!
+ # build new paramater calling convention
+ mov x2, x1
+ mov x1, x0
+ mov x0, x9
+
+ # call C-code
+ bl ASM_PFX(ExecuteEbcImageEntryPoint)
+ ldp x29, x30, [sp], #16
+ ret
diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
new file mode 100644
index 0000000..23261a0
--- /dev/null
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
@@ -0,0 +1,563 @@
+/** @file
+ This module contains EBC support routines that are customized based
+on
+ the target AArch64 processor.
+
+Copyright (c) 2015, The Linux Foundation. All rights reserved.
+Copyright (c) 2006 - 2014, Intel Corporation. All rights
+reserved.<BR> 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 "EbcInt.h"
+#include "EbcExecute.h"
+
+//
+// Amount of space that is not used in the stack // #define
+STACK_REMAIN_SIZE (1024 * 4)
+
+//
+// This is instruction buffer used to create EBC thunk //
+#define EBC_MAGIC_SIGNATURE 0xCA112EBCCA112EBCull
+#define EBC_ENTRYPOINT_SIGNATURE 0xAFAFAFAFAFAFAFAFull
+#define EBC_LL_EBC_ENTRYPOINT_SIGNATURE 0xFAFAFAFAFAFAFAFAull
+UINT8 mInstructionBufferTemplate[] = {
+ 0x03, 0x00, 0x00, 0x14, //b pc+16
+ //
+ // Add a magic code here to help the VM recognize the thunk..
+ //
+ (UINT8)(EBC_MAGIC_SIGNATURE & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 56) & 0xFF),
+ 0x69, 0x00, 0x00, 0x58, //ldr x9, #32
+ 0x8A, 0x00, 0x00, 0x58, //ldr x10, #40
+ 0x05, 0x00, 0x00, 0x14, //b pc+32
+ (UINT8)(EBC_ENTRYPOINT_SIGNATURE & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 56) & 0xFF),
+ (UINT8)(EBC_LL_EBC_ENTRYPOINT_SIGNATURE & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 56) & 0xFF),
+ 0x40, 0x01, 0x1F, 0xD6 //br x10
+
+};
+
+/**
+ Begin executing an EBC image.
+ This is used for Ebc Thunk call.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcLLEbcInterpret (
+ VOID
+ );
+
+/**
+ Begin executing an EBC image.
+ This is used for Ebc image entrypoint.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcLLExecuteEbcImageEntryPoint (
+ VOID
+ );
+
+/**
+ Pushes a 64 bit unsigned value to the VM stack.
+
+ @param VmPtr The pointer to current VM context.
+ @param Arg The value to be pushed.
+
+**/
+VOID
+PushU64 (
+ IN VM_CONTEXT *VmPtr,
+ IN UINT64 Arg
+ )
+{
+ //
+ // Advance the VM stack down, and then copy the argument to the stack.
+ // Hope it's aligned.
+ //
+ VmPtr->Gpr[0] -= sizeof (UINT64);
+ *(UINT64 *) VmPtr->Gpr[0] = Arg;
+ return;
+}
+
+
+/**
+ Begin executing an EBC image.
+
+ This is a thunk function.
+
+ @param EntryPoint The entrypoint of EBC code.
+ @param Arg1 The 1st argument.
+ @param Arg2 The 2nd argument.
+ @param Arg3 The 3rd argument.
+ @param Arg4 The 4th argument.
+ @param Arg5 The 5th argument.
+ @param Arg6 The 6th argument.
+ @param Arg7 The 7th argument.
+ @param Arg8 The 8th argument.
+ @param Arg9 The 9th argument.
+ @param Arg10 The 10th argument.
+ @param Arg11 The 11th argument.
+ @param Arg12 The 12th argument.
+ @param Arg13 The 13th argument.
+ @param Arg14 The 14th argument.
+ @param Arg15 The 15th argument.
+ @param Arg16 The 16th argument.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcInterpret (
+ IN UINTN EntryPoint,
+ IN UINTN Arg1,
+ IN UINTN Arg2,
+ IN UINTN Arg3,
+ IN UINTN Arg4,
+ IN UINTN Arg5,
+ IN UINTN Arg6,
+ IN UINTN Arg7,
+ IN UINTN Arg8,
+ IN UINTN Arg9,
+ IN UINTN Arg10,
+ IN UINTN Arg11,
+ IN UINTN Arg12,
+ IN UINTN Arg13,
+ IN UINTN Arg14,
+ IN UINTN Arg15,
+ IN UINTN Arg16
+ )
+{
+ //
+ // Create a new VM context on the stack
+ //
+ VM_CONTEXT VmContext;
+ UINTN Addr;
+ EFI_STATUS Status;
+ UINTN StackIndex;
+
+ //
+ // Get the EBC entry point
+ //
+ Addr = EntryPoint;
+
+ //
+ // Now clear out our context
+ //
+ ZeroMem ((VOID *) &VmContext, sizeof (VM_CONTEXT));
+
+ //
+ // Set the VM instruction pointer to the correct location in memory.
+ //
+ VmContext.Ip = (VMIP) Addr;
+
+ //
+ // Initialize the stack pointer for the EBC. Get the current system
+ stack // pointer and adjust it down by the max needed for the interpreter.
+ //
+
+ //
+ // Adjust the VM's stack pointer down.
+ //
+
+ Status = GetEBCStack((EFI_HANDLE)(UINTN)-1, &VmContext.StackPool,
+ &StackIndex); if (EFI_ERROR(Status)) {
+ return Status;
+ }
+ VmContext.StackTop = (UINT8*)VmContext.StackPool +
+ (STACK_REMAIN_SIZE); VmContext.Gpr[0] = (UINT64)
+ ((UINT8*)VmContext.StackPool + STACK_POOL_SIZE);
+ VmContext.HighStackBottom = (UINTN) VmContext.Gpr[0];
VmContext.Gpr[0]
+ -= sizeof (UINTN);
+
+ //
+ // Align the stack on a natural boundary.
+ //
+ VmContext.Gpr[0] &= ~(VM_REGISTER)(sizeof (UINTN) - 1);
+
+ //
+ // Put a magic value in the stack gap, then adjust down again.
+ //
+ *(UINTN *) (UINTN) (VmContext.Gpr[0]) = (UINTN)
VM_STACK_KEY_VALUE;
+ VmContext.StackMagicPtr = (UINTN *) (UINTN) VmContext.Gpr[0];
+
+ //
+ // The stack upper to LowStackTop is belong to the VM.
+ //
+ VmContext.LowStackTop = (UINTN) VmContext.Gpr[0];
+
+ //
+ // For the worst case, assume there are 4 arguments passed in
+ registers, store // them to VM's stack.
+ //
+ PushU64 (&VmContext, (UINT64) Arg16);
+ PushU64 (&VmContext, (UINT64) Arg15);
+ PushU64 (&VmContext, (UINT64) Arg14);
+ PushU64 (&VmContext, (UINT64) Arg13);
+ PushU64 (&VmContext, (UINT64) Arg12);
+ PushU64 (&VmContext, (UINT64) Arg11);
+ PushU64 (&VmContext, (UINT64) Arg10);
+ PushU64 (&VmContext, (UINT64) Arg9);
+ PushU64 (&VmContext, (UINT64) Arg8);
+ PushU64 (&VmContext, (UINT64) Arg7);
+ PushU64 (&VmContext, (UINT64) Arg6);
+ PushU64 (&VmContext, (UINT64) Arg5);
+ PushU64 (&VmContext, (UINT64) Arg4);
+ PushU64 (&VmContext, (UINT64) Arg3);
+ PushU64 (&VmContext, (UINT64) Arg2);
+ PushU64 (&VmContext, (UINT64) Arg1);
+
+ //
+ // Interpreter assumes 64-bit return address is pushed on the stack.
+ // AArch64 does not do this so pad the stack accordingly.
+ //
+ PushU64 (&VmContext, (UINT64) 0);
+ PushU64 (&VmContext, (UINT64) 0x1234567887654321ULL);
+
+ //
+ // For AArch64, this is where we say our return address is //
+ VmContext.StackRetAddr = (UINT64) VmContext.Gpr[0];
+
+ //
+ // We need to keep track of where the EBC stack starts. This way,
+ if the EBC // accesses any stack variables above its initial stack
+ setting, then we know // it's accessing variables passed into it,
+ which means the data is on the // VM's stack.
+ // When we're called, on the stack (high to low) we have the
+ parameters, the // return address, then the saved ebp. Save the
+ pointer
to the return address.
+ // EBC code knows that's there, so should look above it for
+ function
parameters.
+ // The offset is the size of locals (VMContext + Addr + saved ebp).
+ // Note that the interpreter assumes there is a 16 bytes of return
+ address on // the stack too, so adjust accordingly.
+ // VmContext.HighStackBottom = (UINTN)(Addr + sizeof (VmContext) +
+ sizeof (Addr)); //
+
+ //
+ // Begin executing the EBC code
+ //
+ EbcExecute (&VmContext);
+
+ //
+ // Return the value in R[7] unless there was an error
+ //
+ ReturnEBCStack(StackIndex);
+ return (UINT64) VmContext.Gpr[7];
+}
+
+
+/**
+ Begin executing an EBC image.
+
+ @param EntryPoint The entrypoint of EBC code.
+ @param ImageHandle image handle for the EBC application we're
executing
+ @param SystemTable standard system table passed into an driver's
entry
+ point
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+ExecuteEbcImageEntryPoint (
+ IN UINTN EntryPoint,
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ //
+ // Create a new VM context on the stack
+ //
+ VM_CONTEXT VmContext;
+ UINTN Addr;
+ EFI_STATUS Status;
+ UINTN StackIndex;
+
+ //
+ // Get the EBC entry point
+ //
+ Addr = EntryPoint;
+
+ //
+ // Now clear out our context
+ //
+ ZeroMem ((VOID *) &VmContext, sizeof (VM_CONTEXT));
+
+ //
+ // Save the image handle so we can track the thunks created for
+ this image // VmContext.ImageHandle = ImageHandle;
VmContext.SystemTable
+ = SystemTable;
+
+ //
+ // Set the VM instruction pointer to the correct location in memory.
+ //
+ VmContext.Ip = (VMIP) Addr;
+
+ //
+ // Initialize the stack pointer for the EBC. Get the current system
+ stack // pointer and adjust it down by the max needed for the interpreter.
+ //
+
+ Status = GetEBCStack(ImageHandle, &VmContext.StackPool,
&StackIndex);
+ if (EFI_ERROR(Status)) {
+ return Status;
+ }
+ VmContext.StackTop = (UINT8*)VmContext.StackPool +
+ (STACK_REMAIN_SIZE); VmContext.Gpr[0] = (UINT64)
+ ((UINT8*)VmContext.StackPool + STACK_POOL_SIZE);
+ VmContext.HighStackBottom = (UINTN) VmContext.Gpr[0];
VmContext.Gpr[0]
+ -= sizeof (UINTN);
+
+
+ //
+ // Put a magic value in the stack gap, then adjust down again //
+ *(UINTN *) (UINTN) (VmContext.Gpr[0]) = (UINTN)
VM_STACK_KEY_VALUE;
+ VmContext.StackMagicPtr = (UINTN *) (UINTN) VmContext.Gpr[0];
+
+ //
+ // Align the stack on a natural boundary VmContext.Gpr[0] &=
+ ~(VM_REGISTER)(sizeof(UINTN) - 1); //
+ VmContext.LowStackTop = (UINTN) VmContext.Gpr[0];
+
+ //
+ // Simply copy the image handle and system table onto the EBC stack.
+ // Greatly simplifies things by not having to spill the args.
+ //
+ PushU64 (&VmContext, (UINT64) SystemTable);
+ PushU64 (&VmContext, (UINT64) ImageHandle);
+
+ //
+ // VM pushes 16-bytes for return address. Simulate that here.
+ //
+ PushU64 (&VmContext, (UINT64) 0);
+ PushU64 (&VmContext, (UINT64) 0x1234567887654321ULL);
+
+ //
+ // For AArch64, this is where we say our return address is //
+ VmContext.StackRetAddr = (UINT64) VmContext.Gpr[0];
+
+ //
+ // Entry function needn't access high stack context, simply // put
+ the stack pointer here.
+ //
+
+ //
+ // Begin executing the EBC code
+ //
+ EbcExecute (&VmContext);
+
+ //
+ // Return the value in R[7] unless there was an error
+ //
+ ReturnEBCStack(StackIndex);
+ return (UINT64) VmContext.Gpr[7];
+}
+
+
+/**
+ Create thunks for an EBC image entry point, or an EBC protocol service.
+
+ @param ImageHandle Image handle for the EBC image. If not null,
then
+ we're creating a thunk for an image entry point.
+ @param EbcEntryPoint Address of the EBC code that the thunk is to
call
+ @param Thunk Returned thunk we create here
+ @param Flags Flags indicating options for creating the thunk
+
+ @retval EFI_SUCCESS The thunk was created successfully.
+ @retval EFI_INVALID_PARAMETER The parameter of EbcEntryPoint is not
16-bit
+ aligned.
+ @retval EFI_OUT_OF_RESOURCES There is not enough memory to
created the EBC
+ Thunk.
+ @retval EFI_BUFFER_TOO_SMALL EBC_THUNK_SIZE is not larger enough.
+
+**/
+EFI_STATUS
+EbcCreateThunks (
+ IN EFI_HANDLE ImageHandle,
+ IN VOID *EbcEntryPoint,
+ OUT VOID **Thunk,
+ IN UINT32 Flags
+ )
+{
+ UINT8 *Ptr;
+ UINT8 *ThunkBase;
+ UINT32 Index;
+ INT32 ThunkSize;
+
+ //
+ // Check alignment of pointer to EBC code // if ((UINT32) (UINTN)
+ EbcEntryPoint & 0x01) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ ThunkSize = sizeof(mInstructionBufferTemplate);
+
+ Ptr = AllocatePool (sizeof(mInstructionBufferTemplate));
+
+ if (Ptr == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+ }
+ //
+ // Print(L"Allocate TH: 0x%X\n", (UINT32)Ptr); // // Save the
+ start address so we can add a pointer to it to a list later.
+ //
+ ThunkBase = Ptr;
+
+ //
+ // Give them the address of our buffer we're going to fix up //
+ *Thunk = (VOID *) Ptr;
+
+ //
+ // Copy whole thunk instruction buffer template // CopyMem (Ptr,
+ mInstructionBufferTemplate, sizeof(mInstructionBufferTemplate));
+
+ //
+ // Patch EbcEntryPoint and EbcLLEbcInterpret // for (Index = 0;
+ Index < sizeof(mInstructionBufferTemplate) - sizeof(UINTN); Index++) {
+ if (*(UINTN *)&Ptr[Index] == EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcEntryPoint;
+ }
+ if (*(UINTN *)&Ptr[Index] == EBC_LL_EBC_ENTRYPOINT_SIGNATURE) {
+ if ((Flags & FLAG_THUNK_ENTRY_POINT) != 0) {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcLLExecuteEbcImageEntryPoint;
+ } else {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcLLEbcInterpret;
+ }
+ }
+ }
+
+ //
+ // Add the thunk to the list for this image. Do this last since the
+ add // function flushes the cache for us.
+ //
+ EbcAddImageThunk (ImageHandle, (VOID *) ThunkBase, ThunkSize);
+
+ return EFI_SUCCESS;
+}
+
+
+/**
+ This function is called to execute an EBC CALLEX instruction.
+ The function check the callee's content to see whether it is common
+native
+ code or a thunk to another piece of EBC code.
+ If the callee is common native code, use EbcLLCAllEXASM to
+manipulate,
+ otherwise, set the VM->IP to target EBC code directly to avoid
+another VM
+ be startup which cost time and stack space.
+
+ @param VmPtr Pointer to a VM context.
+ @param FuncAddr Callee's address
+ @param NewStackPointer New stack pointer after the call
+ @param FramePtr New frame pointer after the call
+ @param Size The size of call instruction
+
+**/
+VOID
+EbcLLCALLEX (
+ IN VM_CONTEXT *VmPtr,
+ IN UINTN FuncAddr,
+ IN UINTN NewStackPointer,
+ IN VOID *FramePtr,
+ IN UINT8 Size
+ )
+{
+ UINTN IsThunk;
+ UINTN TargetEbcAddr;
+ UINT8 InstructionBuffer[sizeof(mInstructionBufferTemplate)];
+ UINTN Index;
+ UINTN IndexOfEbcEntrypoint;
+
+ IsThunk = 1;
+ TargetEbcAddr = 0;
+ IndexOfEbcEntrypoint = 0;
+
+ //
+ // Processor specific code to check whether the callee is a thunk to EBC.
+ //
+ CopyMem (InstructionBuffer, (VOID *)FuncAddr,
+ sizeof(InstructionBuffer)); // // Fill the signature according to
+ mInstructionBufferTemplate // for (Index = 0; Index <
+ sizeof(mInstructionBufferTemplate) - sizeof(UINTN); Index++) {
+ if (*(UINTN *)&mInstructionBufferTemplate[Index] ==
EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&InstructionBuffer[Index] = EBC_ENTRYPOINT_SIGNATURE;
+ IndexOfEbcEntrypoint = Index;
+ }
+ if (*(UINTN *)&mInstructionBufferTemplate[Index] ==
EBC_LL_EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&InstructionBuffer[Index] =
EBC_LL_EBC_ENTRYPOINT_SIGNATURE;
+ }
+ }
+ //
+ // Check if we need thunk to native // if (CompareMem
+ (InstructionBuffer, mInstructionBufferTemplate,
sizeof(mInstructionBufferTemplate)) != 0) {
+ IsThunk = 0;
+ }
+
+ if (IsThunk == 1){
+ //
+ // The callee is a thunk to EBC, adjust the stack pointer down 16 bytes and
+ // put our return address and frame pointer on the VM stack.
+ // Then set the VM's IP to new EBC code.
+ //
+ VmPtr->Gpr[0] -= 8;
+ VmWriteMemN (VmPtr, (UINTN) VmPtr->Gpr[0], (UINTN) FramePtr);
+ VmPtr->FramePtr = (VOID *) (UINTN) VmPtr->Gpr[0];
+ VmPtr->Gpr[0] -= 8;
+ VmWriteMem64 (VmPtr, (UINTN) VmPtr->Gpr[0], (UINT64) (UINTN)
+ (VmPtr->Ip + Size));
+
+ CopyMem (&TargetEbcAddr, (UINT8 *)FuncAddr +
+ IndexOfEbcEntrypoint,
sizeof(UINTN));
+ VmPtr->Ip = (VMIP) (UINTN) TargetEbcAddr; } else {
+ //
+ // The callee is not a thunk to EBC, call native code,
+ // and get return value.
+ //
+ VmPtr->Gpr[7] = EbcLLCALLEXNative (FuncAddr, NewStackPointer,
+ FramePtr);
+
+ //
+ // Advance the IP.
+ //
+ VmPtr->Ip += Size;
+ }
+}
+
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
b/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
index 15dc01c..e9a0b28 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
@@ -5,6 +5,7 @@
# platform and processor-independent mechanisms for loading and
executing EFI # device drivers.
#
+# Copyright (c) 2015, The Linux Foundation. All rights reserved.
# Copyright (c) 2006 - 2014, Intel Corporation. All rights
reserved.<BR> # This program and the accompanying materials # are
licensed and made available under the terms and conditions of the BSD
License @@ -28,7 +29,7 @@ [Defines] # # The following information is
for reference only and not required by the build tools.
#
-# VALID_ARCHITECTURES = IA32 X64 IPF
+# VALID_ARCHITECTURES = IA32 X64 IPF AARCH64
#

[Sources]
@@ -54,6 +55,9 @@ [Sources.IPF]
Ipf/EbcSupport.c
Ipf/EbcLowLevel.s

+[Sources.AARCH64]
+ AArch64/EbcSupport.c
+ AArch64/EbcLowLevel.S

[Packages]
MdePkg/MdePkg.dec
--
2.1.4

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


[Patch 2/2] NetworkPkg: Add missed character in copyright.

Siyuan, Fu
 

Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
---
NetworkPkg/Dhcp6Dxe/Dhcp6Io.c | 2 +-
NetworkPkg/TcpDxe/TcpInput.c | 2 +-
NetworkPkg/Udp6Dxe/Udp6Impl.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/NetworkPkg/Dhcp6Dxe/Dhcp6Io.c b/NetworkPkg/Dhcp6Dxe/Dhcp6Io.c
index d25b973..5cdeac6 100644
--- a/NetworkPkg/Dhcp6Dxe/Dhcp6Io.c
+++ b/NetworkPkg/Dhcp6Dxe/Dhcp6Io.c
@@ -2,7 +2,7 @@
Dhcp6 internal functions implementation.

(C) Copyright 2014 Hewlett-Packard Development Company, L.P.<BR>
- Copyright (c) 2009 - 2016 Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.<BR>

This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
diff --git a/NetworkPkg/TcpDxe/TcpInput.c b/NetworkPkg/TcpDxe/TcpInput.c
index 28bb021..3115c52 100644
--- a/NetworkPkg/TcpDxe/TcpInput.c
+++ b/NetworkPkg/TcpDxe/TcpInput.c
@@ -1,7 +1,7 @@
/** @file
TCP input process routines.

- Copyright (c) 2009 - 2016 Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.<BR>

This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
diff --git a/NetworkPkg/Udp6Dxe/Udp6Impl.c b/NetworkPkg/Udp6Dxe/Udp6Impl.c
index 5896a7a..edf2c23 100644
--- a/NetworkPkg/Udp6Dxe/Udp6Impl.c
+++ b/NetworkPkg/Udp6Dxe/Udp6Impl.c
@@ -1,7 +1,7 @@
/** @file
Udp6 driver's whole implementation.

- Copyright (c) 2009 - 2016 Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.<BR>

This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
--
2.7.4.windows.1


[Patch 1/2] MdeModulePkg: Add missed character in copyright.

Siyuan, Fu
 

Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
---
MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Impl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Impl.c b/MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Impl.c
index b258439..20dbeff 100644
--- a/MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Impl.c
+++ b/MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Impl.c
@@ -1,7 +1,7 @@
/** @file
The implementation of the Udp4 protocol.

-Copyright (c) 2006 - 2016 Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
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
--
2.7.4.windows.1


[Patch 0/2] Add missed character in copyright.

Siyuan, Fu
 

Fu Siyuan (2):
MdeModulePkg: Add missed character in copyright.
NetworkPkg: Add missed character in copyright.

MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Impl.c | 2 +-
NetworkPkg/Dhcp6Dxe/Dhcp6Io.c | 2 +-
NetworkPkg/TcpDxe/TcpInput.c | 2 +-
NetworkPkg/Udp6Dxe/Udp6Impl.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)

--
2.7.4.windows.1


Re: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

Tian, Feng <feng.tian@...>
 

I may not speak it clear. Sorry for that.

I saw the patch with commit log "Submitted on behalf of a third-party: xxxx". But this is part of "TianoCore Contribution Agreement 1.0 section 4".

And the Contributions.txt clearly says "the commit message must include your "Signed-off-by" signature, and "Contributed-under" message". But the commit log hasn't.

So I am total confused how to solve this case. What's the correct format for this?

I add Jordan & Mike for further comments.

Thanks
Feng

-----Original Message-----
From: Marvin H?user [mailto:Marvin.Haeuser@outlook.com]
Sent: Monday, August 1, 2016 9:58 AM
To: edk2-devel@lists.01.org
Cc: Tian, Feng <feng.tian@intel.com>
Subject: RE: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

Hey Feng,

According to the Contributions document, BSD 2-clause is one of the licenses that can be accepted, if the parent license cannot be used:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Contributions.txt#L25

Regards,
Marvin.

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Tian, Feng
Sent: Monday, August 1, 2016 3:50 AM
To: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org
Cc: Tian, Feng <feng.tian@intel.com>; Daniil Egranov
<daniil.egranov@linaro.org>; Jeff Brasen <jbrasen@codeaurora.org>;
Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
<ard.biesheuvel@linaro.org>
Subject: Re: [edk2] [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM
support

Hi, Leif

If I understand correctly, EDKII doesn't allow such BSD license.

Correct me if anybody has different opinions.

Thanks
Feng

-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
Sent: Saturday, July 30, 2016 12:06 AM
To: edk2-devel@lists.01.org
Cc: Jeff Brasen <jbrasen@codeaurora.org>; Ard Biesheuvel
<ard.biesheuvel@linaro.org>; Daniil Egranov
<daniil.egranov@linaro.org>; Tian, Feng <feng.tian@intel.com>; Zeng,
Star <star.zeng@intel.com>
Subject: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

From: Jeff Brasen <jbrasen@codeaurora.org>

Adds support for the EBC VM for AARCH64 platforms

Submitted on behalf of a third-party: The Linux Foundation This
contribution is licensed under the BSD license as found at
http://opensource.org/licenses/bsd-license.php

[Taken from https://source.codeaurora.org/external/server/edk2-blue/]
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
---
.../Universal/EbcDxe/AArch64/EbcLowLevel.S | 135 +++++
MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c | 563
+++++++++++++++++++++
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf | 6 +-
3 files changed, 703 insertions(+), 1 deletion(-) create mode 100644
MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
create mode 100644
MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c

diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
new file mode 100644
index 0000000..e858227
--- /dev/null
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
@@ -0,0 +1,135 @@
+#/** @file
+#
+# This code provides low level routines that support the Virtual Machine
+# for option ROMs.
+#
+# Copyright (c) 2015, The Linux Foundation. All rights reserved.
+# Copyright (c) 2007 - 2014, Intel Corporation. All rights
+reserved.<BR> # 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.
+#
+#**/
+
+#--------------------------------------------------------------------
+--
+-----
+# Equate files needed.
+#--------------------------------------------------------------------
+--
+-----
+
+ASM_GLOBAL ASM_PFX(CopyMem);
+ASM_GLOBAL ASM_PFX(EbcInterpret);
+ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
+
+#********************************************************
**************
+******
+# EbcLLCALLEX
+#
+# This function is called to execute an EBC CALLEX instruction.
+# This instruction requires that we thunk out to external native #
+code. For AArch64, we copy the VM stack into the main stack and then
+pop # the first 8 arguments off according to the AArch64 Procedure
+Call Standard # On return, we restore the stack pointer to its original location.
+#
+#********************************************************
**************
+****** # UINTN EbcLLCALLEXNative(UINTN FuncAddr, UINTN
NewStackPointer,
+VOID *FramePtr) ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative);
+ASM_PFX(EbcLLCALLEXNative):
+ stp x19, x20, [sp, #-16]!
+ stp x29, x30, [sp, #-16]!
+
+ mov x19, x0
+ mov x20, sp
+ sub x2, x2, x1 // Length = NewStackPointer-FramePtr
+ sub sp, sp, x2
+ sub sp, sp, #64 // Make sure there is room for at least 8
+ args in the new
stack
+ mov x0, sp
+
+ bl CopyMem // Sp, NewStackPointer, Length
+
+ ldp x0, x1, [sp], #16
+ ldp x2, x3, [sp], #16
+ ldp x4, x5, [sp], #16
+ ldp x6, x7, [sp], #16
+
+ blr x19
+
+ mov sp, x20
+ ldp x29, x30, [sp], #16
+ ldp x19, x20, [sp], #16
+
+ ret
+
+#********************************************************
**************
+******
+# EbcLLEbcInterpret
+#
+# This function is called by the thunk code to handle an Native to
+EBC call # This can handle up to 16 arguments (1-8 on in x0-x7, 9-16
+are on the stack) # x9 contains the Entry point that will be the
+first argument when # EBCInterpret is called.
+#
+#********************************************************
**************
+******
+ASM_GLOBAL ASM_PFX(EbcLLEbcInterpret);
+ASM_PFX(EbcLLEbcInterpret):
+ stp x29, x30, [sp, #-16]!
+
+ // copy the current arguments 9-16 from old location and add arg
+ 7 to
stack
+ // keeping 16 byte stack alignment
+ sub sp, sp, #80
+ str x7, [sp]
+ ldr x11, [sp, #96]
+ str x11, [sp, #8]
+ ldr x11, [sp, #104]
+ str x11, [sp, #16]
+ ldr x11, [sp, #112]
+ str x11, [sp, #24]
+ ldr x11, [sp, #120]
+ str x11, [sp, #32]
+ ldr x11, [sp, #128]
+ str x11, [sp, #40]
+ ldr x11, [sp, #136]
+ str x11, [sp, #48]
+ ldr x11, [sp, #144]
+ str x11, [sp, #56]
+ ldr x11, [sp, #152]
+ str x11, [sp, #64]
+
+ // Shift arguments and add entry point and as argument 1
+ mov x7, x6
+ mov x6, x5
+ mov x5, x4
+ mov x4, x3
+ mov x3, x2
+ mov x2, x1
+ mov x1, x0
+ mov x0, x9
+
+ # call C-code
+ bl ASM_PFX(EbcInterpret)
+ add sp, sp, #80
+
+ ldp x29, x30, [sp], #16
+
+ ret
+
+#********************************************************
**************
+******
+# EbcLLExecuteEbcImageEntryPoint
+#
+# This function is called by the thunk code to handle the image entry
+point # x9 contains the Entry point that will be the first argument
+when # ExecuteEbcImageEntryPoint is called.
+#
+#********************************************************
**************
+****** ASM_GLOBAL ASM_PFX(EbcLLExecuteEbcImageEntryPoint);
+ASM_PFX(EbcLLExecuteEbcImageEntryPoint):
+ stp x29, x30, [sp, #-16]!
+ # build new paramater calling convention
+ mov x2, x1
+ mov x1, x0
+ mov x0, x9
+
+ # call C-code
+ bl ASM_PFX(ExecuteEbcImageEntryPoint)
+ ldp x29, x30, [sp], #16
+ ret
diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
new file mode 100644
index 0000000..23261a0
--- /dev/null
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
@@ -0,0 +1,563 @@
+/** @file
+ This module contains EBC support routines that are customized based
+on
+ the target AArch64 processor.
+
+Copyright (c) 2015, The Linux Foundation. All rights reserved.
+Copyright (c) 2006 - 2014, Intel Corporation. All rights
+reserved.<BR> 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 "EbcInt.h"
+#include "EbcExecute.h"
+
+//
+// Amount of space that is not used in the stack // #define
+STACK_REMAIN_SIZE (1024 * 4)
+
+//
+// This is instruction buffer used to create EBC thunk //
+#define EBC_MAGIC_SIGNATURE 0xCA112EBCCA112EBCull
+#define EBC_ENTRYPOINT_SIGNATURE 0xAFAFAFAFAFAFAFAFull
+#define EBC_LL_EBC_ENTRYPOINT_SIGNATURE 0xFAFAFAFAFAFAFAFAull
+UINT8 mInstructionBufferTemplate[] = {
+ 0x03, 0x00, 0x00, 0x14, //b pc+16
+ //
+ // Add a magic code here to help the VM recognize the thunk..
+ //
+ (UINT8)(EBC_MAGIC_SIGNATURE & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 56) & 0xFF),
+ 0x69, 0x00, 0x00, 0x58, //ldr x9, #32
+ 0x8A, 0x00, 0x00, 0x58, //ldr x10, #40
+ 0x05, 0x00, 0x00, 0x14, //b pc+32
+ (UINT8)(EBC_ENTRYPOINT_SIGNATURE & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 56) & 0xFF),
+ (UINT8)(EBC_LL_EBC_ENTRYPOINT_SIGNATURE & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 56) & 0xFF),
+ 0x40, 0x01, 0x1F, 0xD6 //br x10
+
+};
+
+/**
+ Begin executing an EBC image.
+ This is used for Ebc Thunk call.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcLLEbcInterpret (
+ VOID
+ );
+
+/**
+ Begin executing an EBC image.
+ This is used for Ebc image entrypoint.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcLLExecuteEbcImageEntryPoint (
+ VOID
+ );
+
+/**
+ Pushes a 64 bit unsigned value to the VM stack.
+
+ @param VmPtr The pointer to current VM context.
+ @param Arg The value to be pushed.
+
+**/
+VOID
+PushU64 (
+ IN VM_CONTEXT *VmPtr,
+ IN UINT64 Arg
+ )
+{
+ //
+ // Advance the VM stack down, and then copy the argument to the stack.
+ // Hope it's aligned.
+ //
+ VmPtr->Gpr[0] -= sizeof (UINT64);
+ *(UINT64 *) VmPtr->Gpr[0] = Arg;
+ return;
+}
+
+
+/**
+ Begin executing an EBC image.
+
+ This is a thunk function.
+
+ @param EntryPoint The entrypoint of EBC code.
+ @param Arg1 The 1st argument.
+ @param Arg2 The 2nd argument.
+ @param Arg3 The 3rd argument.
+ @param Arg4 The 4th argument.
+ @param Arg5 The 5th argument.
+ @param Arg6 The 6th argument.
+ @param Arg7 The 7th argument.
+ @param Arg8 The 8th argument.
+ @param Arg9 The 9th argument.
+ @param Arg10 The 10th argument.
+ @param Arg11 The 11th argument.
+ @param Arg12 The 12th argument.
+ @param Arg13 The 13th argument.
+ @param Arg14 The 14th argument.
+ @param Arg15 The 15th argument.
+ @param Arg16 The 16th argument.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcInterpret (
+ IN UINTN EntryPoint,
+ IN UINTN Arg1,
+ IN UINTN Arg2,
+ IN UINTN Arg3,
+ IN UINTN Arg4,
+ IN UINTN Arg5,
+ IN UINTN Arg6,
+ IN UINTN Arg7,
+ IN UINTN Arg8,
+ IN UINTN Arg9,
+ IN UINTN Arg10,
+ IN UINTN Arg11,
+ IN UINTN Arg12,
+ IN UINTN Arg13,
+ IN UINTN Arg14,
+ IN UINTN Arg15,
+ IN UINTN Arg16
+ )
+{
+ //
+ // Create a new VM context on the stack
+ //
+ VM_CONTEXT VmContext;
+ UINTN Addr;
+ EFI_STATUS Status;
+ UINTN StackIndex;
+
+ //
+ // Get the EBC entry point
+ //
+ Addr = EntryPoint;
+
+ //
+ // Now clear out our context
+ //
+ ZeroMem ((VOID *) &VmContext, sizeof (VM_CONTEXT));
+
+ //
+ // Set the VM instruction pointer to the correct location in memory.
+ //
+ VmContext.Ip = (VMIP) Addr;
+
+ //
+ // Initialize the stack pointer for the EBC. Get the current system
+ stack // pointer and adjust it down by the max needed for the interpreter.
+ //
+
+ //
+ // Adjust the VM's stack pointer down.
+ //
+
+ Status = GetEBCStack((EFI_HANDLE)(UINTN)-1, &VmContext.StackPool,
+ &StackIndex); if (EFI_ERROR(Status)) {
+ return Status;
+ }
+ VmContext.StackTop = (UINT8*)VmContext.StackPool +
+ (STACK_REMAIN_SIZE); VmContext.Gpr[0] = (UINT64)
+ ((UINT8*)VmContext.StackPool + STACK_POOL_SIZE);
+ VmContext.HighStackBottom = (UINTN) VmContext.Gpr[0];
VmContext.Gpr[0]
+ -= sizeof (UINTN);
+
+ //
+ // Align the stack on a natural boundary.
+ //
+ VmContext.Gpr[0] &= ~(VM_REGISTER)(sizeof (UINTN) - 1);
+
+ //
+ // Put a magic value in the stack gap, then adjust down again.
+ //
+ *(UINTN *) (UINTN) (VmContext.Gpr[0]) = (UINTN)
VM_STACK_KEY_VALUE;
+ VmContext.StackMagicPtr = (UINTN *) (UINTN) VmContext.Gpr[0];
+
+ //
+ // The stack upper to LowStackTop is belong to the VM.
+ //
+ VmContext.LowStackTop = (UINTN) VmContext.Gpr[0];
+
+ //
+ // For the worst case, assume there are 4 arguments passed in
+ registers, store // them to VM's stack.
+ //
+ PushU64 (&VmContext, (UINT64) Arg16);
+ PushU64 (&VmContext, (UINT64) Arg15);
+ PushU64 (&VmContext, (UINT64) Arg14);
+ PushU64 (&VmContext, (UINT64) Arg13);
+ PushU64 (&VmContext, (UINT64) Arg12);
+ PushU64 (&VmContext, (UINT64) Arg11);
+ PushU64 (&VmContext, (UINT64) Arg10);
+ PushU64 (&VmContext, (UINT64) Arg9);
+ PushU64 (&VmContext, (UINT64) Arg8);
+ PushU64 (&VmContext, (UINT64) Arg7);
+ PushU64 (&VmContext, (UINT64) Arg6);
+ PushU64 (&VmContext, (UINT64) Arg5);
+ PushU64 (&VmContext, (UINT64) Arg4);
+ PushU64 (&VmContext, (UINT64) Arg3);
+ PushU64 (&VmContext, (UINT64) Arg2);
+ PushU64 (&VmContext, (UINT64) Arg1);
+
+ //
+ // Interpreter assumes 64-bit return address is pushed on the stack.
+ // AArch64 does not do this so pad the stack accordingly.
+ //
+ PushU64 (&VmContext, (UINT64) 0);
+ PushU64 (&VmContext, (UINT64) 0x1234567887654321ULL);
+
+ //
+ // For AArch64, this is where we say our return address is //
+ VmContext.StackRetAddr = (UINT64) VmContext.Gpr[0];
+
+ //
+ // We need to keep track of where the EBC stack starts. This way,
+ if the EBC // accesses any stack variables above its initial stack
+ setting, then we know // it's accessing variables passed into it,
+ which means the data is on the // VM's stack.
+ // When we're called, on the stack (high to low) we have the
+ parameters, the // return address, then the saved ebp. Save the
+ pointer
to the return address.
+ // EBC code knows that's there, so should look above it for
+ function
parameters.
+ // The offset is the size of locals (VMContext + Addr + saved ebp).
+ // Note that the interpreter assumes there is a 16 bytes of return
+ address on // the stack too, so adjust accordingly.
+ // VmContext.HighStackBottom = (UINTN)(Addr + sizeof (VmContext) +
+ sizeof (Addr)); //
+
+ //
+ // Begin executing the EBC code
+ //
+ EbcExecute (&VmContext);
+
+ //
+ // Return the value in R[7] unless there was an error
+ //
+ ReturnEBCStack(StackIndex);
+ return (UINT64) VmContext.Gpr[7];
+}
+
+
+/**
+ Begin executing an EBC image.
+
+ @param EntryPoint The entrypoint of EBC code.
+ @param ImageHandle image handle for the EBC application we're
executing
+ @param SystemTable standard system table passed into an driver's
entry
+ point
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+ExecuteEbcImageEntryPoint (
+ IN UINTN EntryPoint,
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ //
+ // Create a new VM context on the stack
+ //
+ VM_CONTEXT VmContext;
+ UINTN Addr;
+ EFI_STATUS Status;
+ UINTN StackIndex;
+
+ //
+ // Get the EBC entry point
+ //
+ Addr = EntryPoint;
+
+ //
+ // Now clear out our context
+ //
+ ZeroMem ((VOID *) &VmContext, sizeof (VM_CONTEXT));
+
+ //
+ // Save the image handle so we can track the thunks created for
+ this image // VmContext.ImageHandle = ImageHandle;
VmContext.SystemTable
+ = SystemTable;
+
+ //
+ // Set the VM instruction pointer to the correct location in memory.
+ //
+ VmContext.Ip = (VMIP) Addr;
+
+ //
+ // Initialize the stack pointer for the EBC. Get the current system
+ stack // pointer and adjust it down by the max needed for the interpreter.
+ //
+
+ Status = GetEBCStack(ImageHandle, &VmContext.StackPool,
&StackIndex);
+ if (EFI_ERROR(Status)) {
+ return Status;
+ }
+ VmContext.StackTop = (UINT8*)VmContext.StackPool +
+ (STACK_REMAIN_SIZE); VmContext.Gpr[0] = (UINT64)
+ ((UINT8*)VmContext.StackPool + STACK_POOL_SIZE);
+ VmContext.HighStackBottom = (UINTN) VmContext.Gpr[0];
VmContext.Gpr[0]
+ -= sizeof (UINTN);
+
+
+ //
+ // Put a magic value in the stack gap, then adjust down again //
+ *(UINTN *) (UINTN) (VmContext.Gpr[0]) = (UINTN)
VM_STACK_KEY_VALUE;
+ VmContext.StackMagicPtr = (UINTN *) (UINTN) VmContext.Gpr[0];
+
+ //
+ // Align the stack on a natural boundary VmContext.Gpr[0] &=
+ ~(VM_REGISTER)(sizeof(UINTN) - 1); //
+ VmContext.LowStackTop = (UINTN) VmContext.Gpr[0];
+
+ //
+ // Simply copy the image handle and system table onto the EBC stack.
+ // Greatly simplifies things by not having to spill the args.
+ //
+ PushU64 (&VmContext, (UINT64) SystemTable);
+ PushU64 (&VmContext, (UINT64) ImageHandle);
+
+ //
+ // VM pushes 16-bytes for return address. Simulate that here.
+ //
+ PushU64 (&VmContext, (UINT64) 0);
+ PushU64 (&VmContext, (UINT64) 0x1234567887654321ULL);
+
+ //
+ // For AArch64, this is where we say our return address is //
+ VmContext.StackRetAddr = (UINT64) VmContext.Gpr[0];
+
+ //
+ // Entry function needn't access high stack context, simply // put
+ the stack pointer here.
+ //
+
+ //
+ // Begin executing the EBC code
+ //
+ EbcExecute (&VmContext);
+
+ //
+ // Return the value in R[7] unless there was an error
+ //
+ ReturnEBCStack(StackIndex);
+ return (UINT64) VmContext.Gpr[7];
+}
+
+
+/**
+ Create thunks for an EBC image entry point, or an EBC protocol service.
+
+ @param ImageHandle Image handle for the EBC image. If not null,
then
+ we're creating a thunk for an image entry point.
+ @param EbcEntryPoint Address of the EBC code that the thunk is to
call
+ @param Thunk Returned thunk we create here
+ @param Flags Flags indicating options for creating the thunk
+
+ @retval EFI_SUCCESS The thunk was created successfully.
+ @retval EFI_INVALID_PARAMETER The parameter of EbcEntryPoint is not
16-bit
+ aligned.
+ @retval EFI_OUT_OF_RESOURCES There is not enough memory to
created the EBC
+ Thunk.
+ @retval EFI_BUFFER_TOO_SMALL EBC_THUNK_SIZE is not larger enough.
+
+**/
+EFI_STATUS
+EbcCreateThunks (
+ IN EFI_HANDLE ImageHandle,
+ IN VOID *EbcEntryPoint,
+ OUT VOID **Thunk,
+ IN UINT32 Flags
+ )
+{
+ UINT8 *Ptr;
+ UINT8 *ThunkBase;
+ UINT32 Index;
+ INT32 ThunkSize;
+
+ //
+ // Check alignment of pointer to EBC code // if ((UINT32) (UINTN)
+ EbcEntryPoint & 0x01) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ ThunkSize = sizeof(mInstructionBufferTemplate);
+
+ Ptr = AllocatePool (sizeof(mInstructionBufferTemplate));
+
+ if (Ptr == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+ }
+ //
+ // Print(L"Allocate TH: 0x%X\n", (UINT32)Ptr); // // Save the
+ start address so we can add a pointer to it to a list later.
+ //
+ ThunkBase = Ptr;
+
+ //
+ // Give them the address of our buffer we're going to fix up //
+ *Thunk = (VOID *) Ptr;
+
+ //
+ // Copy whole thunk instruction buffer template // CopyMem (Ptr,
+ mInstructionBufferTemplate, sizeof(mInstructionBufferTemplate));
+
+ //
+ // Patch EbcEntryPoint and EbcLLEbcInterpret // for (Index = 0;
+ Index < sizeof(mInstructionBufferTemplate) - sizeof(UINTN); Index++) {
+ if (*(UINTN *)&Ptr[Index] == EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcEntryPoint;
+ }
+ if (*(UINTN *)&Ptr[Index] == EBC_LL_EBC_ENTRYPOINT_SIGNATURE) {
+ if ((Flags & FLAG_THUNK_ENTRY_POINT) != 0) {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcLLExecuteEbcImageEntryPoint;
+ } else {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcLLEbcInterpret;
+ }
+ }
+ }
+
+ //
+ // Add the thunk to the list for this image. Do this last since the
+ add // function flushes the cache for us.
+ //
+ EbcAddImageThunk (ImageHandle, (VOID *) ThunkBase, ThunkSize);
+
+ return EFI_SUCCESS;
+}
+
+
+/**
+ This function is called to execute an EBC CALLEX instruction.
+ The function check the callee's content to see whether it is common
+native
+ code or a thunk to another piece of EBC code.
+ If the callee is common native code, use EbcLLCAllEXASM to
+manipulate,
+ otherwise, set the VM->IP to target EBC code directly to avoid
+another VM
+ be startup which cost time and stack space.
+
+ @param VmPtr Pointer to a VM context.
+ @param FuncAddr Callee's address
+ @param NewStackPointer New stack pointer after the call
+ @param FramePtr New frame pointer after the call
+ @param Size The size of call instruction
+
+**/
+VOID
+EbcLLCALLEX (
+ IN VM_CONTEXT *VmPtr,
+ IN UINTN FuncAddr,
+ IN UINTN NewStackPointer,
+ IN VOID *FramePtr,
+ IN UINT8 Size
+ )
+{
+ UINTN IsThunk;
+ UINTN TargetEbcAddr;
+ UINT8 InstructionBuffer[sizeof(mInstructionBufferTemplate)];
+ UINTN Index;
+ UINTN IndexOfEbcEntrypoint;
+
+ IsThunk = 1;
+ TargetEbcAddr = 0;
+ IndexOfEbcEntrypoint = 0;
+
+ //
+ // Processor specific code to check whether the callee is a thunk to EBC.
+ //
+ CopyMem (InstructionBuffer, (VOID *)FuncAddr,
+ sizeof(InstructionBuffer)); // // Fill the signature according to
+ mInstructionBufferTemplate // for (Index = 0; Index <
+ sizeof(mInstructionBufferTemplate) - sizeof(UINTN); Index++) {
+ if (*(UINTN *)&mInstructionBufferTemplate[Index] ==
EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&InstructionBuffer[Index] = EBC_ENTRYPOINT_SIGNATURE;
+ IndexOfEbcEntrypoint = Index;
+ }
+ if (*(UINTN *)&mInstructionBufferTemplate[Index] ==
EBC_LL_EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&InstructionBuffer[Index] =
EBC_LL_EBC_ENTRYPOINT_SIGNATURE;
+ }
+ }
+ //
+ // Check if we need thunk to native // if (CompareMem
+ (InstructionBuffer, mInstructionBufferTemplate,
sizeof(mInstructionBufferTemplate)) != 0) {
+ IsThunk = 0;
+ }
+
+ if (IsThunk == 1){
+ //
+ // The callee is a thunk to EBC, adjust the stack pointer down 16 bytes and
+ // put our return address and frame pointer on the VM stack.
+ // Then set the VM's IP to new EBC code.
+ //
+ VmPtr->Gpr[0] -= 8;
+ VmWriteMemN (VmPtr, (UINTN) VmPtr->Gpr[0], (UINTN) FramePtr);
+ VmPtr->FramePtr = (VOID *) (UINTN) VmPtr->Gpr[0];
+ VmPtr->Gpr[0] -= 8;
+ VmWriteMem64 (VmPtr, (UINTN) VmPtr->Gpr[0], (UINT64) (UINTN)
+ (VmPtr->Ip + Size));
+
+ CopyMem (&TargetEbcAddr, (UINT8 *)FuncAddr +
+ IndexOfEbcEntrypoint,
sizeof(UINTN));
+ VmPtr->Ip = (VMIP) (UINTN) TargetEbcAddr; } else {
+ //
+ // The callee is not a thunk to EBC, call native code,
+ // and get return value.
+ //
+ VmPtr->Gpr[7] = EbcLLCALLEXNative (FuncAddr, NewStackPointer,
+ FramePtr);
+
+ //
+ // Advance the IP.
+ //
+ VmPtr->Ip += Size;
+ }
+}
+
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
b/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
index 15dc01c..e9a0b28 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
@@ -5,6 +5,7 @@
# platform and processor-independent mechanisms for loading and
executing EFI # device drivers.
#
+# Copyright (c) 2015, The Linux Foundation. All rights reserved.
# Copyright (c) 2006 - 2014, Intel Corporation. All rights
reserved.<BR> # This program and the accompanying materials # are
licensed and made available under the terms and conditions of the BSD
License @@ -28,7 +29,7 @@ [Defines] # # The following information is
for reference only and not required by the build tools.
#
-# VALID_ARCHITECTURES = IA32 X64 IPF
+# VALID_ARCHITECTURES = IA32 X64 IPF AARCH64
#

[Sources]
@@ -54,6 +55,9 @@ [Sources.IPF]
Ipf/EbcSupport.c
Ipf/EbcLowLevel.s

+[Sources.AARCH64]
+ AArch64/EbcSupport.c
+ AArch64/EbcLowLevel.S

[Packages]
MdePkg/MdePkg.dec
--
2.1.4

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


Re: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

Marvin H?user <Marvin.Haeuser@...>
 

Hey Feng,

According to the Contributions document, BSD 2-clause is one of the licenses that can be accepted, if the parent license cannot be used:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Contributions.txt#L25

Regards,
Marvin.

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Tian, Feng
Sent: Monday, August 1, 2016 3:50 AM
To: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org
Cc: Tian, Feng <feng.tian@intel.com>; Daniil Egranov
<daniil.egranov@linaro.org>; Jeff Brasen <jbrasen@codeaurora.org>; Zeng,
Star <star.zeng@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2] [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC
VM support

Hi, Leif

If I understand correctly, EDKII doesn't allow such BSD license.

Correct me if anybody has different opinions.

Thanks
Feng

-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
Sent: Saturday, July 30, 2016 12:06 AM
To: edk2-devel@lists.01.org
Cc: Jeff Brasen <jbrasen@codeaurora.org>; Ard Biesheuvel
<ard.biesheuvel@linaro.org>; Daniil Egranov <daniil.egranov@linaro.org>;
Tian, Feng <feng.tian@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

From: Jeff Brasen <jbrasen@codeaurora.org>

Adds support for the EBC VM for AARCH64 platforms

Submitted on behalf of a third-party: The Linux Foundation This contribution
is licensed under the BSD license as found at
http://opensource.org/licenses/bsd-license.php

[Taken from https://source.codeaurora.org/external/server/edk2-blue/]
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
---
.../Universal/EbcDxe/AArch64/EbcLowLevel.S | 135 +++++
MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c | 563
+++++++++++++++++++++
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf | 6 +-
3 files changed, 703 insertions(+), 1 deletion(-) create mode 100644
MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
create mode 100644
MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c

diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
new file mode 100644
index 0000000..e858227
--- /dev/null
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
@@ -0,0 +1,135 @@
+#/** @file
+#
+# This code provides low level routines that support the Virtual Machine
+# for option ROMs.
+#
+# Copyright (c) 2015, The Linux Foundation. All rights reserved.
+# Copyright (c) 2007 - 2014, Intel Corporation. All rights
+reserved.<BR> # 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.
+#
+#**/
+
+#----------------------------------------------------------------------
+-----
+# Equate files needed.
+#----------------------------------------------------------------------
+-----
+
+ASM_GLOBAL ASM_PFX(CopyMem);
+ASM_GLOBAL ASM_PFX(EbcInterpret);
+ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
+
+#********************************************************
**************
+******
+# EbcLLCALLEX
+#
+# This function is called to execute an EBC CALLEX instruction.
+# This instruction requires that we thunk out to external native #
+code. For AArch64, we copy the VM stack into the main stack and then
+pop # the first 8 arguments off according to the AArch64 Procedure Call
+Standard # On return, we restore the stack pointer to its original location.
+#
+#********************************************************
**************
+****** # UINTN EbcLLCALLEXNative(UINTN FuncAddr, UINTN
NewStackPointer,
+VOID *FramePtr) ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative);
+ASM_PFX(EbcLLCALLEXNative):
+ stp x19, x20, [sp, #-16]!
+ stp x29, x30, [sp, #-16]!
+
+ mov x19, x0
+ mov x20, sp
+ sub x2, x2, x1 // Length = NewStackPointer-FramePtr
+ sub sp, sp, x2
+ sub sp, sp, #64 // Make sure there is room for at least 8 args in the new
stack
+ mov x0, sp
+
+ bl CopyMem // Sp, NewStackPointer, Length
+
+ ldp x0, x1, [sp], #16
+ ldp x2, x3, [sp], #16
+ ldp x4, x5, [sp], #16
+ ldp x6, x7, [sp], #16
+
+ blr x19
+
+ mov sp, x20
+ ldp x29, x30, [sp], #16
+ ldp x19, x20, [sp], #16
+
+ ret
+
+#********************************************************
**************
+******
+# EbcLLEbcInterpret
+#
+# This function is called by the thunk code to handle an Native to EBC
+call # This can handle up to 16 arguments (1-8 on in x0-x7, 9-16 are on
+the stack) # x9 contains the Entry point that will be the first
+argument when # EBCInterpret is called.
+#
+#********************************************************
**************
+******
+ASM_GLOBAL ASM_PFX(EbcLLEbcInterpret);
+ASM_PFX(EbcLLEbcInterpret):
+ stp x29, x30, [sp, #-16]!
+
+ // copy the current arguments 9-16 from old location and add arg 7 to
stack
+ // keeping 16 byte stack alignment
+ sub sp, sp, #80
+ str x7, [sp]
+ ldr x11, [sp, #96]
+ str x11, [sp, #8]
+ ldr x11, [sp, #104]
+ str x11, [sp, #16]
+ ldr x11, [sp, #112]
+ str x11, [sp, #24]
+ ldr x11, [sp, #120]
+ str x11, [sp, #32]
+ ldr x11, [sp, #128]
+ str x11, [sp, #40]
+ ldr x11, [sp, #136]
+ str x11, [sp, #48]
+ ldr x11, [sp, #144]
+ str x11, [sp, #56]
+ ldr x11, [sp, #152]
+ str x11, [sp, #64]
+
+ // Shift arguments and add entry point and as argument 1
+ mov x7, x6
+ mov x6, x5
+ mov x5, x4
+ mov x4, x3
+ mov x3, x2
+ mov x2, x1
+ mov x1, x0
+ mov x0, x9
+
+ # call C-code
+ bl ASM_PFX(EbcInterpret)
+ add sp, sp, #80
+
+ ldp x29, x30, [sp], #16
+
+ ret
+
+#********************************************************
**************
+******
+# EbcLLExecuteEbcImageEntryPoint
+#
+# This function is called by the thunk code to handle the image entry
+point # x9 contains the Entry point that will be the first argument
+when # ExecuteEbcImageEntryPoint is called.
+#
+#********************************************************
**************
+****** ASM_GLOBAL ASM_PFX(EbcLLExecuteEbcImageEntryPoint);
+ASM_PFX(EbcLLExecuteEbcImageEntryPoint):
+ stp x29, x30, [sp, #-16]!
+ # build new paramater calling convention
+ mov x2, x1
+ mov x1, x0
+ mov x0, x9
+
+ # call C-code
+ bl ASM_PFX(ExecuteEbcImageEntryPoint)
+ ldp x29, x30, [sp], #16
+ ret
diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
new file mode 100644
index 0000000..23261a0
--- /dev/null
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
@@ -0,0 +1,563 @@
+/** @file
+ This module contains EBC support routines that are customized based
+on
+ the target AArch64 processor.
+
+Copyright (c) 2015, The Linux Foundation. All rights reserved.
+Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
+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 "EbcInt.h"
+#include "EbcExecute.h"
+
+//
+// Amount of space that is not used in the stack // #define
+STACK_REMAIN_SIZE (1024 * 4)
+
+//
+// This is instruction buffer used to create EBC thunk //
+#define EBC_MAGIC_SIGNATURE 0xCA112EBCCA112EBCull
+#define EBC_ENTRYPOINT_SIGNATURE 0xAFAFAFAFAFAFAFAFull
+#define EBC_LL_EBC_ENTRYPOINT_SIGNATURE 0xFAFAFAFAFAFAFAFAull
+UINT8 mInstructionBufferTemplate[] = {
+ 0x03, 0x00, 0x00, 0x14, //b pc+16
+ //
+ // Add a magic code here to help the VM recognize the thunk..
+ //
+ (UINT8)(EBC_MAGIC_SIGNATURE & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 56) & 0xFF),
+ 0x69, 0x00, 0x00, 0x58, //ldr x9, #32
+ 0x8A, 0x00, 0x00, 0x58, //ldr x10, #40
+ 0x05, 0x00, 0x00, 0x14, //b pc+32
+ (UINT8)(EBC_ENTRYPOINT_SIGNATURE & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 56) & 0xFF),
+ (UINT8)(EBC_LL_EBC_ENTRYPOINT_SIGNATURE & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 56) & 0xFF),
+ 0x40, 0x01, 0x1F, 0xD6 //br x10
+
+};
+
+/**
+ Begin executing an EBC image.
+ This is used for Ebc Thunk call.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcLLEbcInterpret (
+ VOID
+ );
+
+/**
+ Begin executing an EBC image.
+ This is used for Ebc image entrypoint.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcLLExecuteEbcImageEntryPoint (
+ VOID
+ );
+
+/**
+ Pushes a 64 bit unsigned value to the VM stack.
+
+ @param VmPtr The pointer to current VM context.
+ @param Arg The value to be pushed.
+
+**/
+VOID
+PushU64 (
+ IN VM_CONTEXT *VmPtr,
+ IN UINT64 Arg
+ )
+{
+ //
+ // Advance the VM stack down, and then copy the argument to the stack.
+ // Hope it's aligned.
+ //
+ VmPtr->Gpr[0] -= sizeof (UINT64);
+ *(UINT64 *) VmPtr->Gpr[0] = Arg;
+ return;
+}
+
+
+/**
+ Begin executing an EBC image.
+
+ This is a thunk function.
+
+ @param EntryPoint The entrypoint of EBC code.
+ @param Arg1 The 1st argument.
+ @param Arg2 The 2nd argument.
+ @param Arg3 The 3rd argument.
+ @param Arg4 The 4th argument.
+ @param Arg5 The 5th argument.
+ @param Arg6 The 6th argument.
+ @param Arg7 The 7th argument.
+ @param Arg8 The 8th argument.
+ @param Arg9 The 9th argument.
+ @param Arg10 The 10th argument.
+ @param Arg11 The 11th argument.
+ @param Arg12 The 12th argument.
+ @param Arg13 The 13th argument.
+ @param Arg14 The 14th argument.
+ @param Arg15 The 15th argument.
+ @param Arg16 The 16th argument.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcInterpret (
+ IN UINTN EntryPoint,
+ IN UINTN Arg1,
+ IN UINTN Arg2,
+ IN UINTN Arg3,
+ IN UINTN Arg4,
+ IN UINTN Arg5,
+ IN UINTN Arg6,
+ IN UINTN Arg7,
+ IN UINTN Arg8,
+ IN UINTN Arg9,
+ IN UINTN Arg10,
+ IN UINTN Arg11,
+ IN UINTN Arg12,
+ IN UINTN Arg13,
+ IN UINTN Arg14,
+ IN UINTN Arg15,
+ IN UINTN Arg16
+ )
+{
+ //
+ // Create a new VM context on the stack
+ //
+ VM_CONTEXT VmContext;
+ UINTN Addr;
+ EFI_STATUS Status;
+ UINTN StackIndex;
+
+ //
+ // Get the EBC entry point
+ //
+ Addr = EntryPoint;
+
+ //
+ // Now clear out our context
+ //
+ ZeroMem ((VOID *) &VmContext, sizeof (VM_CONTEXT));
+
+ //
+ // Set the VM instruction pointer to the correct location in memory.
+ //
+ VmContext.Ip = (VMIP) Addr;
+
+ //
+ // Initialize the stack pointer for the EBC. Get the current system
+ stack // pointer and adjust it down by the max needed for the interpreter.
+ //
+
+ //
+ // Adjust the VM's stack pointer down.
+ //
+
+ Status = GetEBCStack((EFI_HANDLE)(UINTN)-1, &VmContext.StackPool,
+ &StackIndex); if (EFI_ERROR(Status)) {
+ return Status;
+ }
+ VmContext.StackTop = (UINT8*)VmContext.StackPool +
+ (STACK_REMAIN_SIZE); VmContext.Gpr[0] = (UINT64)
+ ((UINT8*)VmContext.StackPool + STACK_POOL_SIZE);
+ VmContext.HighStackBottom = (UINTN) VmContext.Gpr[0];
VmContext.Gpr[0]
+ -= sizeof (UINTN);
+
+ //
+ // Align the stack on a natural boundary.
+ //
+ VmContext.Gpr[0] &= ~(VM_REGISTER)(sizeof (UINTN) - 1);
+
+ //
+ // Put a magic value in the stack gap, then adjust down again.
+ //
+ *(UINTN *) (UINTN) (VmContext.Gpr[0]) = (UINTN)
VM_STACK_KEY_VALUE;
+ VmContext.StackMagicPtr = (UINTN *) (UINTN) VmContext.Gpr[0];
+
+ //
+ // The stack upper to LowStackTop is belong to the VM.
+ //
+ VmContext.LowStackTop = (UINTN) VmContext.Gpr[0];
+
+ //
+ // For the worst case, assume there are 4 arguments passed in
+ registers, store // them to VM's stack.
+ //
+ PushU64 (&VmContext, (UINT64) Arg16);
+ PushU64 (&VmContext, (UINT64) Arg15);
+ PushU64 (&VmContext, (UINT64) Arg14);
+ PushU64 (&VmContext, (UINT64) Arg13);
+ PushU64 (&VmContext, (UINT64) Arg12);
+ PushU64 (&VmContext, (UINT64) Arg11);
+ PushU64 (&VmContext, (UINT64) Arg10);
+ PushU64 (&VmContext, (UINT64) Arg9);
+ PushU64 (&VmContext, (UINT64) Arg8);
+ PushU64 (&VmContext, (UINT64) Arg7);
+ PushU64 (&VmContext, (UINT64) Arg6);
+ PushU64 (&VmContext, (UINT64) Arg5);
+ PushU64 (&VmContext, (UINT64) Arg4);
+ PushU64 (&VmContext, (UINT64) Arg3);
+ PushU64 (&VmContext, (UINT64) Arg2);
+ PushU64 (&VmContext, (UINT64) Arg1);
+
+ //
+ // Interpreter assumes 64-bit return address is pushed on the stack.
+ // AArch64 does not do this so pad the stack accordingly.
+ //
+ PushU64 (&VmContext, (UINT64) 0);
+ PushU64 (&VmContext, (UINT64) 0x1234567887654321ULL);
+
+ //
+ // For AArch64, this is where we say our return address is //
+ VmContext.StackRetAddr = (UINT64) VmContext.Gpr[0];
+
+ //
+ // We need to keep track of where the EBC stack starts. This way, if
+ the EBC // accesses any stack variables above its initial stack
+ setting, then we know // it's accessing variables passed into it,
+ which means the data is on the // VM's stack.
+ // When we're called, on the stack (high to low) we have the
+ parameters, the // return address, then the saved ebp. Save the pointer
to the return address.
+ // EBC code knows that's there, so should look above it for function
parameters.
+ // The offset is the size of locals (VMContext + Addr + saved ebp).
+ // Note that the interpreter assumes there is a 16 bytes of return
+ address on // the stack too, so adjust accordingly.
+ // VmContext.HighStackBottom = (UINTN)(Addr + sizeof (VmContext) +
+ sizeof (Addr)); //
+
+ //
+ // Begin executing the EBC code
+ //
+ EbcExecute (&VmContext);
+
+ //
+ // Return the value in R[7] unless there was an error
+ //
+ ReturnEBCStack(StackIndex);
+ return (UINT64) VmContext.Gpr[7];
+}
+
+
+/**
+ Begin executing an EBC image.
+
+ @param EntryPoint The entrypoint of EBC code.
+ @param ImageHandle image handle for the EBC application we're
executing
+ @param SystemTable standard system table passed into an driver's
entry
+ point
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+ExecuteEbcImageEntryPoint (
+ IN UINTN EntryPoint,
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ //
+ // Create a new VM context on the stack
+ //
+ VM_CONTEXT VmContext;
+ UINTN Addr;
+ EFI_STATUS Status;
+ UINTN StackIndex;
+
+ //
+ // Get the EBC entry point
+ //
+ Addr = EntryPoint;
+
+ //
+ // Now clear out our context
+ //
+ ZeroMem ((VOID *) &VmContext, sizeof (VM_CONTEXT));
+
+ //
+ // Save the image handle so we can track the thunks created for this
+ image // VmContext.ImageHandle = ImageHandle;
VmContext.SystemTable
+ = SystemTable;
+
+ //
+ // Set the VM instruction pointer to the correct location in memory.
+ //
+ VmContext.Ip = (VMIP) Addr;
+
+ //
+ // Initialize the stack pointer for the EBC. Get the current system
+ stack // pointer and adjust it down by the max needed for the interpreter.
+ //
+
+ Status = GetEBCStack(ImageHandle, &VmContext.StackPool,
&StackIndex);
+ if (EFI_ERROR(Status)) {
+ return Status;
+ }
+ VmContext.StackTop = (UINT8*)VmContext.StackPool +
+ (STACK_REMAIN_SIZE); VmContext.Gpr[0] = (UINT64)
+ ((UINT8*)VmContext.StackPool + STACK_POOL_SIZE);
+ VmContext.HighStackBottom = (UINTN) VmContext.Gpr[0];
VmContext.Gpr[0]
+ -= sizeof (UINTN);
+
+
+ //
+ // Put a magic value in the stack gap, then adjust down again //
+ *(UINTN *) (UINTN) (VmContext.Gpr[0]) = (UINTN)
VM_STACK_KEY_VALUE;
+ VmContext.StackMagicPtr = (UINTN *) (UINTN) VmContext.Gpr[0];
+
+ //
+ // Align the stack on a natural boundary VmContext.Gpr[0] &=
+ ~(VM_REGISTER)(sizeof(UINTN) - 1); //
+ VmContext.LowStackTop = (UINTN) VmContext.Gpr[0];
+
+ //
+ // Simply copy the image handle and system table onto the EBC stack.
+ // Greatly simplifies things by not having to spill the args.
+ //
+ PushU64 (&VmContext, (UINT64) SystemTable);
+ PushU64 (&VmContext, (UINT64) ImageHandle);
+
+ //
+ // VM pushes 16-bytes for return address. Simulate that here.
+ //
+ PushU64 (&VmContext, (UINT64) 0);
+ PushU64 (&VmContext, (UINT64) 0x1234567887654321ULL);
+
+ //
+ // For AArch64, this is where we say our return address is //
+ VmContext.StackRetAddr = (UINT64) VmContext.Gpr[0];
+
+ //
+ // Entry function needn't access high stack context, simply // put
+ the stack pointer here.
+ //
+
+ //
+ // Begin executing the EBC code
+ //
+ EbcExecute (&VmContext);
+
+ //
+ // Return the value in R[7] unless there was an error
+ //
+ ReturnEBCStack(StackIndex);
+ return (UINT64) VmContext.Gpr[7];
+}
+
+
+/**
+ Create thunks for an EBC image entry point, or an EBC protocol service.
+
+ @param ImageHandle Image handle for the EBC image. If not null,
then
+ we're creating a thunk for an image entry point.
+ @param EbcEntryPoint Address of the EBC code that the thunk is to
call
+ @param Thunk Returned thunk we create here
+ @param Flags Flags indicating options for creating the thunk
+
+ @retval EFI_SUCCESS The thunk was created successfully.
+ @retval EFI_INVALID_PARAMETER The parameter of EbcEntryPoint is not
16-bit
+ aligned.
+ @retval EFI_OUT_OF_RESOURCES There is not enough memory to
created the EBC
+ Thunk.
+ @retval EFI_BUFFER_TOO_SMALL EBC_THUNK_SIZE is not larger enough.
+
+**/
+EFI_STATUS
+EbcCreateThunks (
+ IN EFI_HANDLE ImageHandle,
+ IN VOID *EbcEntryPoint,
+ OUT VOID **Thunk,
+ IN UINT32 Flags
+ )
+{
+ UINT8 *Ptr;
+ UINT8 *ThunkBase;
+ UINT32 Index;
+ INT32 ThunkSize;
+
+ //
+ // Check alignment of pointer to EBC code // if ((UINT32) (UINTN)
+ EbcEntryPoint & 0x01) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ ThunkSize = sizeof(mInstructionBufferTemplate);
+
+ Ptr = AllocatePool (sizeof(mInstructionBufferTemplate));
+
+ if (Ptr == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+ }
+ //
+ // Print(L"Allocate TH: 0x%X\n", (UINT32)Ptr); // // Save the
+ start address so we can add a pointer to it to a list later.
+ //
+ ThunkBase = Ptr;
+
+ //
+ // Give them the address of our buffer we're going to fix up //
+ *Thunk = (VOID *) Ptr;
+
+ //
+ // Copy whole thunk instruction buffer template // CopyMem (Ptr,
+ mInstructionBufferTemplate, sizeof(mInstructionBufferTemplate));
+
+ //
+ // Patch EbcEntryPoint and EbcLLEbcInterpret // for (Index = 0;
+ Index < sizeof(mInstructionBufferTemplate) - sizeof(UINTN); Index++) {
+ if (*(UINTN *)&Ptr[Index] == EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcEntryPoint;
+ }
+ if (*(UINTN *)&Ptr[Index] == EBC_LL_EBC_ENTRYPOINT_SIGNATURE) {
+ if ((Flags & FLAG_THUNK_ENTRY_POINT) != 0) {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcLLExecuteEbcImageEntryPoint;
+ } else {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcLLEbcInterpret;
+ }
+ }
+ }
+
+ //
+ // Add the thunk to the list for this image. Do this last since the
+ add // function flushes the cache for us.
+ //
+ EbcAddImageThunk (ImageHandle, (VOID *) ThunkBase, ThunkSize);
+
+ return EFI_SUCCESS;
+}
+
+
+/**
+ This function is called to execute an EBC CALLEX instruction.
+ The function check the callee's content to see whether it is common
+native
+ code or a thunk to another piece of EBC code.
+ If the callee is common native code, use EbcLLCAllEXASM to
+manipulate,
+ otherwise, set the VM->IP to target EBC code directly to avoid
+another VM
+ be startup which cost time and stack space.
+
+ @param VmPtr Pointer to a VM context.
+ @param FuncAddr Callee's address
+ @param NewStackPointer New stack pointer after the call
+ @param FramePtr New frame pointer after the call
+ @param Size The size of call instruction
+
+**/
+VOID
+EbcLLCALLEX (
+ IN VM_CONTEXT *VmPtr,
+ IN UINTN FuncAddr,
+ IN UINTN NewStackPointer,
+ IN VOID *FramePtr,
+ IN UINT8 Size
+ )
+{
+ UINTN IsThunk;
+ UINTN TargetEbcAddr;
+ UINT8 InstructionBuffer[sizeof(mInstructionBufferTemplate)];
+ UINTN Index;
+ UINTN IndexOfEbcEntrypoint;
+
+ IsThunk = 1;
+ TargetEbcAddr = 0;
+ IndexOfEbcEntrypoint = 0;
+
+ //
+ // Processor specific code to check whether the callee is a thunk to EBC.
+ //
+ CopyMem (InstructionBuffer, (VOID *)FuncAddr,
+ sizeof(InstructionBuffer)); // // Fill the signature according to
+ mInstructionBufferTemplate // for (Index = 0; Index <
+ sizeof(mInstructionBufferTemplate) - sizeof(UINTN); Index++) {
+ if (*(UINTN *)&mInstructionBufferTemplate[Index] ==
EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&InstructionBuffer[Index] = EBC_ENTRYPOINT_SIGNATURE;
+ IndexOfEbcEntrypoint = Index;
+ }
+ if (*(UINTN *)&mInstructionBufferTemplate[Index] ==
EBC_LL_EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&InstructionBuffer[Index] =
EBC_LL_EBC_ENTRYPOINT_SIGNATURE;
+ }
+ }
+ //
+ // Check if we need thunk to native
+ //
+ if (CompareMem (InstructionBuffer, mInstructionBufferTemplate,
sizeof(mInstructionBufferTemplate)) != 0) {
+ IsThunk = 0;
+ }
+
+ if (IsThunk == 1){
+ //
+ // The callee is a thunk to EBC, adjust the stack pointer down 16 bytes and
+ // put our return address and frame pointer on the VM stack.
+ // Then set the VM's IP to new EBC code.
+ //
+ VmPtr->Gpr[0] -= 8;
+ VmWriteMemN (VmPtr, (UINTN) VmPtr->Gpr[0], (UINTN) FramePtr);
+ VmPtr->FramePtr = (VOID *) (UINTN) VmPtr->Gpr[0];
+ VmPtr->Gpr[0] -= 8;
+ VmWriteMem64 (VmPtr, (UINTN) VmPtr->Gpr[0], (UINT64) (UINTN)
+ (VmPtr->Ip + Size));
+
+ CopyMem (&TargetEbcAddr, (UINT8 *)FuncAddr + IndexOfEbcEntrypoint,
sizeof(UINTN));
+ VmPtr->Ip = (VMIP) (UINTN) TargetEbcAddr; } else {
+ //
+ // The callee is not a thunk to EBC, call native code,
+ // and get return value.
+ //
+ VmPtr->Gpr[7] = EbcLLCALLEXNative (FuncAddr, NewStackPointer,
+ FramePtr);
+
+ //
+ // Advance the IP.
+ //
+ VmPtr->Ip += Size;
+ }
+}
+
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
b/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
index 15dc01c..e9a0b28 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
@@ -5,6 +5,7 @@
# platform and processor-independent mechanisms for loading and
executing EFI # device drivers.
#
+# Copyright (c) 2015, The Linux Foundation. All rights reserved.
# Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR> #
This program and the accompanying materials # are licensed and made
available under the terms and conditions of the BSD License @@ -28,7 +29,7
@@ [Defines] # # The following information is for reference only and not
required by the build tools.
#
-# VALID_ARCHITECTURES = IA32 X64 IPF
+# VALID_ARCHITECTURES = IA32 X64 IPF AARCH64
#

[Sources]
@@ -54,6 +55,9 @@ [Sources.IPF]
Ipf/EbcSupport.c
Ipf/EbcLowLevel.s

+[Sources.AARCH64]
+ AArch64/EbcSupport.c
+ AArch64/EbcLowLevel.S

[Packages]
MdePkg/MdePkg.dec
--
2.1.4

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


Re: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

Tian, Feng <feng.tian@...>
 

Hi, Leif

If I understand correctly, EDKII doesn't allow such BSD license.

Correct me if anybody has different opinions.

Thanks
Feng

-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
Sent: Saturday, July 30, 2016 12:06 AM
To: edk2-devel@lists.01.org
Cc: Jeff Brasen <jbrasen@codeaurora.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; Daniil Egranov <daniil.egranov@linaro.org>; Tian, Feng <feng.tian@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

From: Jeff Brasen <jbrasen@codeaurora.org>

Adds support for the EBC VM for AARCH64 platforms

Submitted on behalf of a third-party: The Linux Foundation This contribution is licensed under the BSD license as found at http://opensource.org/licenses/bsd-license.php

[Taken from https://source.codeaurora.org/external/server/edk2-blue/]
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
---
.../Universal/EbcDxe/AArch64/EbcLowLevel.S | 135 +++++
MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c | 563 +++++++++++++++++++++
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf | 6 +-
3 files changed, 703 insertions(+), 1 deletion(-) create mode 100644 MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
create mode 100644 MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c

diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
new file mode 100644
index 0000000..e858227
--- /dev/null
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
@@ -0,0 +1,135 @@
+#/** @file
+#
+# This code provides low level routines that support the Virtual Machine
+# for option ROMs.
+#
+# Copyright (c) 2015, The Linux Foundation. All rights reserved.
+# Copyright (c) 2007 - 2014, Intel Corporation. All rights
+reserved.<BR> # 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.
+#
+#**/
+
+#----------------------------------------------------------------------
+-----
+# Equate files needed.
+#----------------------------------------------------------------------
+-----
+
+ASM_GLOBAL ASM_PFX(CopyMem);
+ASM_GLOBAL ASM_PFX(EbcInterpret);
+ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
+
+#**********************************************************************
+******
+# EbcLLCALLEX
+#
+# This function is called to execute an EBC CALLEX instruction.
+# This instruction requires that we thunk out to external native #
+code. For AArch64, we copy the VM stack into the main stack and then
+pop # the first 8 arguments off according to the AArch64 Procedure Call
+Standard # On return, we restore the stack pointer to its original location.
+#
+#**********************************************************************
+****** # UINTN EbcLLCALLEXNative(UINTN FuncAddr, UINTN NewStackPointer,
+VOID *FramePtr) ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative);
+ASM_PFX(EbcLLCALLEXNative):
+ stp x19, x20, [sp, #-16]!
+ stp x29, x30, [sp, #-16]!
+
+ mov x19, x0
+ mov x20, sp
+ sub x2, x2, x1 // Length = NewStackPointer-FramePtr
+ sub sp, sp, x2
+ sub sp, sp, #64 // Make sure there is room for at least 8 args in the new stack
+ mov x0, sp
+
+ bl CopyMem // Sp, NewStackPointer, Length
+
+ ldp x0, x1, [sp], #16
+ ldp x2, x3, [sp], #16
+ ldp x4, x5, [sp], #16
+ ldp x6, x7, [sp], #16
+
+ blr x19
+
+ mov sp, x20
+ ldp x29, x30, [sp], #16
+ ldp x19, x20, [sp], #16
+
+ ret
+
+#**********************************************************************
+******
+# EbcLLEbcInterpret
+#
+# This function is called by the thunk code to handle an Native to EBC
+call # This can handle up to 16 arguments (1-8 on in x0-x7, 9-16 are on
+the stack) # x9 contains the Entry point that will be the first
+argument when # EBCInterpret is called.
+#
+#**********************************************************************
+******
+ASM_GLOBAL ASM_PFX(EbcLLEbcInterpret);
+ASM_PFX(EbcLLEbcInterpret):
+ stp x29, x30, [sp, #-16]!
+
+ // copy the current arguments 9-16 from old location and add arg 7 to stack
+ // keeping 16 byte stack alignment
+ sub sp, sp, #80
+ str x7, [sp]
+ ldr x11, [sp, #96]
+ str x11, [sp, #8]
+ ldr x11, [sp, #104]
+ str x11, [sp, #16]
+ ldr x11, [sp, #112]
+ str x11, [sp, #24]
+ ldr x11, [sp, #120]
+ str x11, [sp, #32]
+ ldr x11, [sp, #128]
+ str x11, [sp, #40]
+ ldr x11, [sp, #136]
+ str x11, [sp, #48]
+ ldr x11, [sp, #144]
+ str x11, [sp, #56]
+ ldr x11, [sp, #152]
+ str x11, [sp, #64]
+
+ // Shift arguments and add entry point and as argument 1
+ mov x7, x6
+ mov x6, x5
+ mov x5, x4
+ mov x4, x3
+ mov x3, x2
+ mov x2, x1
+ mov x1, x0
+ mov x0, x9
+
+ # call C-code
+ bl ASM_PFX(EbcInterpret)
+ add sp, sp, #80
+
+ ldp x29, x30, [sp], #16
+
+ ret
+
+#**********************************************************************
+******
+# EbcLLExecuteEbcImageEntryPoint
+#
+# This function is called by the thunk code to handle the image entry
+point # x9 contains the Entry point that will be the first argument
+when # ExecuteEbcImageEntryPoint is called.
+#
+#**********************************************************************
+****** ASM_GLOBAL ASM_PFX(EbcLLExecuteEbcImageEntryPoint);
+ASM_PFX(EbcLLExecuteEbcImageEntryPoint):
+ stp x29, x30, [sp, #-16]!
+ # build new paramater calling convention
+ mov x2, x1
+ mov x1, x0
+ mov x0, x9
+
+ # call C-code
+ bl ASM_PFX(ExecuteEbcImageEntryPoint)
+ ldp x29, x30, [sp], #16
+ ret
diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
new file mode 100644
index 0000000..23261a0
--- /dev/null
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
@@ -0,0 +1,563 @@
+/** @file
+ This module contains EBC support routines that are customized based
+on
+ the target AArch64 processor.
+
+Copyright (c) 2015, The Linux Foundation. All rights reserved.
+Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
+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 "EbcInt.h"
+#include "EbcExecute.h"
+
+//
+// Amount of space that is not used in the stack // #define
+STACK_REMAIN_SIZE (1024 * 4)
+
+//
+// This is instruction buffer used to create EBC thunk //
+#define EBC_MAGIC_SIGNATURE 0xCA112EBCCA112EBCull
+#define EBC_ENTRYPOINT_SIGNATURE 0xAFAFAFAFAFAFAFAFull
+#define EBC_LL_EBC_ENTRYPOINT_SIGNATURE 0xFAFAFAFAFAFAFAFAull
+UINT8 mInstructionBufferTemplate[] = {
+ 0x03, 0x00, 0x00, 0x14, //b pc+16
+ //
+ // Add a magic code here to help the VM recognize the thunk..
+ //
+ (UINT8)(EBC_MAGIC_SIGNATURE & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_MAGIC_SIGNATURE >> 56) & 0xFF),
+ 0x69, 0x00, 0x00, 0x58, //ldr x9, #32
+ 0x8A, 0x00, 0x00, 0x58, //ldr x10, #40
+ 0x05, 0x00, 0x00, 0x14, //b pc+32
+ (UINT8)(EBC_ENTRYPOINT_SIGNATURE & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_ENTRYPOINT_SIGNATURE >> 56) & 0xFF),
+ (UINT8)(EBC_LL_EBC_ENTRYPOINT_SIGNATURE & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 8) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 16) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 24) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 32) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 40) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 48) & 0xFF),
+ (UINT8)((EBC_LL_EBC_ENTRYPOINT_SIGNATURE >> 56) & 0xFF),
+ 0x40, 0x01, 0x1F, 0xD6 //br x10
+
+};
+
+/**
+ Begin executing an EBC image.
+ This is used for Ebc Thunk call.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcLLEbcInterpret (
+ VOID
+ );
+
+/**
+ Begin executing an EBC image.
+ This is used for Ebc image entrypoint.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcLLExecuteEbcImageEntryPoint (
+ VOID
+ );
+
+/**
+ Pushes a 64 bit unsigned value to the VM stack.
+
+ @param VmPtr The pointer to current VM context.
+ @param Arg The value to be pushed.
+
+**/
+VOID
+PushU64 (
+ IN VM_CONTEXT *VmPtr,
+ IN UINT64 Arg
+ )
+{
+ //
+ // Advance the VM stack down, and then copy the argument to the stack.
+ // Hope it's aligned.
+ //
+ VmPtr->Gpr[0] -= sizeof (UINT64);
+ *(UINT64 *) VmPtr->Gpr[0] = Arg;
+ return;
+}
+
+
+/**
+ Begin executing an EBC image.
+
+ This is a thunk function.
+
+ @param EntryPoint The entrypoint of EBC code.
+ @param Arg1 The 1st argument.
+ @param Arg2 The 2nd argument.
+ @param Arg3 The 3rd argument.
+ @param Arg4 The 4th argument.
+ @param Arg5 The 5th argument.
+ @param Arg6 The 6th argument.
+ @param Arg7 The 7th argument.
+ @param Arg8 The 8th argument.
+ @param Arg9 The 9th argument.
+ @param Arg10 The 10th argument.
+ @param Arg11 The 11th argument.
+ @param Arg12 The 12th argument.
+ @param Arg13 The 13th argument.
+ @param Arg14 The 14th argument.
+ @param Arg15 The 15th argument.
+ @param Arg16 The 16th argument.
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+EbcInterpret (
+ IN UINTN EntryPoint,
+ IN UINTN Arg1,
+ IN UINTN Arg2,
+ IN UINTN Arg3,
+ IN UINTN Arg4,
+ IN UINTN Arg5,
+ IN UINTN Arg6,
+ IN UINTN Arg7,
+ IN UINTN Arg8,
+ IN UINTN Arg9,
+ IN UINTN Arg10,
+ IN UINTN Arg11,
+ IN UINTN Arg12,
+ IN UINTN Arg13,
+ IN UINTN Arg14,
+ IN UINTN Arg15,
+ IN UINTN Arg16
+ )
+{
+ //
+ // Create a new VM context on the stack
+ //
+ VM_CONTEXT VmContext;
+ UINTN Addr;
+ EFI_STATUS Status;
+ UINTN StackIndex;
+
+ //
+ // Get the EBC entry point
+ //
+ Addr = EntryPoint;
+
+ //
+ // Now clear out our context
+ //
+ ZeroMem ((VOID *) &VmContext, sizeof (VM_CONTEXT));
+
+ //
+ // Set the VM instruction pointer to the correct location in memory.
+ //
+ VmContext.Ip = (VMIP) Addr;
+
+ //
+ // Initialize the stack pointer for the EBC. Get the current system
+ stack // pointer and adjust it down by the max needed for the interpreter.
+ //
+
+ //
+ // Adjust the VM's stack pointer down.
+ //
+
+ Status = GetEBCStack((EFI_HANDLE)(UINTN)-1, &VmContext.StackPool,
+ &StackIndex); if (EFI_ERROR(Status)) {
+ return Status;
+ }
+ VmContext.StackTop = (UINT8*)VmContext.StackPool +
+ (STACK_REMAIN_SIZE); VmContext.Gpr[0] = (UINT64)
+ ((UINT8*)VmContext.StackPool + STACK_POOL_SIZE);
+ VmContext.HighStackBottom = (UINTN) VmContext.Gpr[0];
+ VmContext.Gpr[0] -= sizeof (UINTN);
+
+ //
+ // Align the stack on a natural boundary.
+ //
+ VmContext.Gpr[0] &= ~(VM_REGISTER)(sizeof (UINTN) - 1);
+
+ //
+ // Put a magic value in the stack gap, then adjust down again.
+ //
+ *(UINTN *) (UINTN) (VmContext.Gpr[0]) = (UINTN) VM_STACK_KEY_VALUE;
+ VmContext.StackMagicPtr = (UINTN *) (UINTN) VmContext.Gpr[0];
+
+ //
+ // The stack upper to LowStackTop is belong to the VM.
+ //
+ VmContext.LowStackTop = (UINTN) VmContext.Gpr[0];
+
+ //
+ // For the worst case, assume there are 4 arguments passed in
+ registers, store // them to VM's stack.
+ //
+ PushU64 (&VmContext, (UINT64) Arg16);
+ PushU64 (&VmContext, (UINT64) Arg15);
+ PushU64 (&VmContext, (UINT64) Arg14);
+ PushU64 (&VmContext, (UINT64) Arg13);
+ PushU64 (&VmContext, (UINT64) Arg12);
+ PushU64 (&VmContext, (UINT64) Arg11);
+ PushU64 (&VmContext, (UINT64) Arg10);
+ PushU64 (&VmContext, (UINT64) Arg9);
+ PushU64 (&VmContext, (UINT64) Arg8);
+ PushU64 (&VmContext, (UINT64) Arg7);
+ PushU64 (&VmContext, (UINT64) Arg6);
+ PushU64 (&VmContext, (UINT64) Arg5);
+ PushU64 (&VmContext, (UINT64) Arg4);
+ PushU64 (&VmContext, (UINT64) Arg3);
+ PushU64 (&VmContext, (UINT64) Arg2);
+ PushU64 (&VmContext, (UINT64) Arg1);
+
+ //
+ // Interpreter assumes 64-bit return address is pushed on the stack.
+ // AArch64 does not do this so pad the stack accordingly.
+ //
+ PushU64 (&VmContext, (UINT64) 0);
+ PushU64 (&VmContext, (UINT64) 0x1234567887654321ULL);
+
+ //
+ // For AArch64, this is where we say our return address is //
+ VmContext.StackRetAddr = (UINT64) VmContext.Gpr[0];
+
+ //
+ // We need to keep track of where the EBC stack starts. This way, if
+ the EBC // accesses any stack variables above its initial stack
+ setting, then we know // it's accessing variables passed into it,
+ which means the data is on the // VM's stack.
+ // When we're called, on the stack (high to low) we have the
+ parameters, the // return address, then the saved ebp. Save the pointer to the return address.
+ // EBC code knows that's there, so should look above it for function parameters.
+ // The offset is the size of locals (VMContext + Addr + saved ebp).
+ // Note that the interpreter assumes there is a 16 bytes of return
+ address on // the stack too, so adjust accordingly.
+ // VmContext.HighStackBottom = (UINTN)(Addr + sizeof (VmContext) +
+ sizeof (Addr)); //
+
+ //
+ // Begin executing the EBC code
+ //
+ EbcExecute (&VmContext);
+
+ //
+ // Return the value in R[7] unless there was an error
+ //
+ ReturnEBCStack(StackIndex);
+ return (UINT64) VmContext.Gpr[7];
+}
+
+
+/**
+ Begin executing an EBC image.
+
+ @param EntryPoint The entrypoint of EBC code.
+ @param ImageHandle image handle for the EBC application we're executing
+ @param SystemTable standard system table passed into an driver's entry
+ point
+
+ @return The value returned by the EBC application we're going to run.
+
+**/
+UINT64
+EFIAPI
+ExecuteEbcImageEntryPoint (
+ IN UINTN EntryPoint,
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ //
+ // Create a new VM context on the stack
+ //
+ VM_CONTEXT VmContext;
+ UINTN Addr;
+ EFI_STATUS Status;
+ UINTN StackIndex;
+
+ //
+ // Get the EBC entry point
+ //
+ Addr = EntryPoint;
+
+ //
+ // Now clear out our context
+ //
+ ZeroMem ((VOID *) &VmContext, sizeof (VM_CONTEXT));
+
+ //
+ // Save the image handle so we can track the thunks created for this
+ image // VmContext.ImageHandle = ImageHandle; VmContext.SystemTable
+ = SystemTable;
+
+ //
+ // Set the VM instruction pointer to the correct location in memory.
+ //
+ VmContext.Ip = (VMIP) Addr;
+
+ //
+ // Initialize the stack pointer for the EBC. Get the current system
+ stack // pointer and adjust it down by the max needed for the interpreter.
+ //
+
+ Status = GetEBCStack(ImageHandle, &VmContext.StackPool, &StackIndex);
+ if (EFI_ERROR(Status)) {
+ return Status;
+ }
+ VmContext.StackTop = (UINT8*)VmContext.StackPool +
+ (STACK_REMAIN_SIZE); VmContext.Gpr[0] = (UINT64)
+ ((UINT8*)VmContext.StackPool + STACK_POOL_SIZE);
+ VmContext.HighStackBottom = (UINTN) VmContext.Gpr[0];
+ VmContext.Gpr[0] -= sizeof (UINTN);
+
+
+ //
+ // Put a magic value in the stack gap, then adjust down again //
+ *(UINTN *) (UINTN) (VmContext.Gpr[0]) = (UINTN) VM_STACK_KEY_VALUE;
+ VmContext.StackMagicPtr = (UINTN *) (UINTN) VmContext.Gpr[0];
+
+ //
+ // Align the stack on a natural boundary VmContext.Gpr[0] &=
+ ~(VM_REGISTER)(sizeof(UINTN) - 1); //
+ VmContext.LowStackTop = (UINTN) VmContext.Gpr[0];
+
+ //
+ // Simply copy the image handle and system table onto the EBC stack.
+ // Greatly simplifies things by not having to spill the args.
+ //
+ PushU64 (&VmContext, (UINT64) SystemTable);
+ PushU64 (&VmContext, (UINT64) ImageHandle);
+
+ //
+ // VM pushes 16-bytes for return address. Simulate that here.
+ //
+ PushU64 (&VmContext, (UINT64) 0);
+ PushU64 (&VmContext, (UINT64) 0x1234567887654321ULL);
+
+ //
+ // For AArch64, this is where we say our return address is //
+ VmContext.StackRetAddr = (UINT64) VmContext.Gpr[0];
+
+ //
+ // Entry function needn't access high stack context, simply // put
+ the stack pointer here.
+ //
+
+ //
+ // Begin executing the EBC code
+ //
+ EbcExecute (&VmContext);
+
+ //
+ // Return the value in R[7] unless there was an error
+ //
+ ReturnEBCStack(StackIndex);
+ return (UINT64) VmContext.Gpr[7];
+}
+
+
+/**
+ Create thunks for an EBC image entry point, or an EBC protocol service.
+
+ @param ImageHandle Image handle for the EBC image. If not null, then
+ we're creating a thunk for an image entry point.
+ @param EbcEntryPoint Address of the EBC code that the thunk is to call
+ @param Thunk Returned thunk we create here
+ @param Flags Flags indicating options for creating the thunk
+
+ @retval EFI_SUCCESS The thunk was created successfully.
+ @retval EFI_INVALID_PARAMETER The parameter of EbcEntryPoint is not 16-bit
+ aligned.
+ @retval EFI_OUT_OF_RESOURCES There is not enough memory to created the EBC
+ Thunk.
+ @retval EFI_BUFFER_TOO_SMALL EBC_THUNK_SIZE is not larger enough.
+
+**/
+EFI_STATUS
+EbcCreateThunks (
+ IN EFI_HANDLE ImageHandle,
+ IN VOID *EbcEntryPoint,
+ OUT VOID **Thunk,
+ IN UINT32 Flags
+ )
+{
+ UINT8 *Ptr;
+ UINT8 *ThunkBase;
+ UINT32 Index;
+ INT32 ThunkSize;
+
+ //
+ // Check alignment of pointer to EBC code // if ((UINT32) (UINTN)
+ EbcEntryPoint & 0x01) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ ThunkSize = sizeof(mInstructionBufferTemplate);
+
+ Ptr = AllocatePool (sizeof(mInstructionBufferTemplate));
+
+ if (Ptr == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+ }
+ //
+ // Print(L"Allocate TH: 0x%X\n", (UINT32)Ptr); // // Save the
+ start address so we can add a pointer to it to a list later.
+ //
+ ThunkBase = Ptr;
+
+ //
+ // Give them the address of our buffer we're going to fix up //
+ *Thunk = (VOID *) Ptr;
+
+ //
+ // Copy whole thunk instruction buffer template // CopyMem (Ptr,
+ mInstructionBufferTemplate, sizeof(mInstructionBufferTemplate));
+
+ //
+ // Patch EbcEntryPoint and EbcLLEbcInterpret // for (Index = 0;
+ Index < sizeof(mInstructionBufferTemplate) - sizeof(UINTN); Index++) {
+ if (*(UINTN *)&Ptr[Index] == EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcEntryPoint;
+ }
+ if (*(UINTN *)&Ptr[Index] == EBC_LL_EBC_ENTRYPOINT_SIGNATURE) {
+ if ((Flags & FLAG_THUNK_ENTRY_POINT) != 0) {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcLLExecuteEbcImageEntryPoint;
+ } else {
+ *(UINTN *)&Ptr[Index] = (UINTN)EbcLLEbcInterpret;
+ }
+ }
+ }
+
+ //
+ // Add the thunk to the list for this image. Do this last since the
+ add // function flushes the cache for us.
+ //
+ EbcAddImageThunk (ImageHandle, (VOID *) ThunkBase, ThunkSize);
+
+ return EFI_SUCCESS;
+}
+
+
+/**
+ This function is called to execute an EBC CALLEX instruction.
+ The function check the callee's content to see whether it is common
+native
+ code or a thunk to another piece of EBC code.
+ If the callee is common native code, use EbcLLCAllEXASM to
+manipulate,
+ otherwise, set the VM->IP to target EBC code directly to avoid
+another VM
+ be startup which cost time and stack space.
+
+ @param VmPtr Pointer to a VM context.
+ @param FuncAddr Callee's address
+ @param NewStackPointer New stack pointer after the call
+ @param FramePtr New frame pointer after the call
+ @param Size The size of call instruction
+
+**/
+VOID
+EbcLLCALLEX (
+ IN VM_CONTEXT *VmPtr,
+ IN UINTN FuncAddr,
+ IN UINTN NewStackPointer,
+ IN VOID *FramePtr,
+ IN UINT8 Size
+ )
+{
+ UINTN IsThunk;
+ UINTN TargetEbcAddr;
+ UINT8 InstructionBuffer[sizeof(mInstructionBufferTemplate)];
+ UINTN Index;
+ UINTN IndexOfEbcEntrypoint;
+
+ IsThunk = 1;
+ TargetEbcAddr = 0;
+ IndexOfEbcEntrypoint = 0;
+
+ //
+ // Processor specific code to check whether the callee is a thunk to EBC.
+ //
+ CopyMem (InstructionBuffer, (VOID *)FuncAddr,
+ sizeof(InstructionBuffer)); // // Fill the signature according to
+ mInstructionBufferTemplate // for (Index = 0; Index <
+ sizeof(mInstructionBufferTemplate) - sizeof(UINTN); Index++) {
+ if (*(UINTN *)&mInstructionBufferTemplate[Index] == EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&InstructionBuffer[Index] = EBC_ENTRYPOINT_SIGNATURE;
+ IndexOfEbcEntrypoint = Index;
+ }
+ if (*(UINTN *)&mInstructionBufferTemplate[Index] == EBC_LL_EBC_ENTRYPOINT_SIGNATURE) {
+ *(UINTN *)&InstructionBuffer[Index] = EBC_LL_EBC_ENTRYPOINT_SIGNATURE;
+ }
+ }
+ //
+ // Check if we need thunk to native
+ //
+ if (CompareMem (InstructionBuffer, mInstructionBufferTemplate, sizeof(mInstructionBufferTemplate)) != 0) {
+ IsThunk = 0;
+ }
+
+ if (IsThunk == 1){
+ //
+ // The callee is a thunk to EBC, adjust the stack pointer down 16 bytes and
+ // put our return address and frame pointer on the VM stack.
+ // Then set the VM's IP to new EBC code.
+ //
+ VmPtr->Gpr[0] -= 8;
+ VmWriteMemN (VmPtr, (UINTN) VmPtr->Gpr[0], (UINTN) FramePtr);
+ VmPtr->FramePtr = (VOID *) (UINTN) VmPtr->Gpr[0];
+ VmPtr->Gpr[0] -= 8;
+ VmWriteMem64 (VmPtr, (UINTN) VmPtr->Gpr[0], (UINT64) (UINTN)
+ (VmPtr->Ip + Size));
+
+ CopyMem (&TargetEbcAddr, (UINT8 *)FuncAddr + IndexOfEbcEntrypoint, sizeof(UINTN));
+ VmPtr->Ip = (VMIP) (UINTN) TargetEbcAddr; } else {
+ //
+ // The callee is not a thunk to EBC, call native code,
+ // and get return value.
+ //
+ VmPtr->Gpr[7] = EbcLLCALLEXNative (FuncAddr, NewStackPointer,
+ FramePtr);
+
+ //
+ // Advance the IP.
+ //
+ VmPtr->Ip += Size;
+ }
+}
+
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf b/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
index 15dc01c..e9a0b28 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
@@ -5,6 +5,7 @@
# platform and processor-independent mechanisms for loading and executing EFI # device drivers.
#
+# Copyright (c) 2015, The Linux Foundation. All rights reserved.
# Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR> # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License @@ -28,7 +29,7 @@ [Defines] # # The following information is for reference only and not required by the build tools.
#
-# VALID_ARCHITECTURES = IA32 X64 IPF
+# VALID_ARCHITECTURES = IA32 X64 IPF AARCH64
#

[Sources]
@@ -54,6 +55,9 @@ [Sources.IPF]
Ipf/EbcSupport.c
Ipf/EbcLowLevel.s

+[Sources.AARCH64]
+ AArch64/EbcSupport.c
+ AArch64/EbcLowLevel.S

[Packages]
MdePkg/MdePkg.dec
--
2.1.4


Re: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Long, Qin <qin.long@...>
 

I personally prefer to keep the current supported cipher suite for our UEFI-TLS enabling. We can have the full RFC definitions, and platform specific cipher sets for validation now. It's better to maintain one minimal scope in this phase.

"enable-weak-ssl-ciphers" looks odd. Disabling weak ciphers is the recommendation for hardening SSL communications.
For other ciphers (idea, dsa, etc), we can enable them step-by-step depending on the real requirements.


Best Regards & Thanks,
LONG, Qin

-----Original Message-----
From: Wu, Jiaxin
Sent: Monday, August 01, 2016 9:23 AM
To: Palmer, Thomas; Long, Qin; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Gao, Liming
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with
the standardized one

Thomas,
I agree some of them are not supported due to the UEFI OpenSSL
configuration, but it doesn't affect those mapping relationship added in the
patch. So, I have no strong opinion whether to support it by modifying the
current OpenSSL configuration. Since Qin is the OpenSSL expert, I'd like to
hear his views.

Qin,
What's your opinion?

Thanks.
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Palmer, Thomas
Sent: Saturday, July 30, 2016 6:03 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>; Long, Qin <qin.long@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin,

UEFI's OpenSSL library does not support all the ciphers that were
added in your patch due to the UEFI configuration. We need to remove
"no- idea" and "no-dsa" from the process_files.sh and add
"enable-weak-ssl- ciphers"

While we are modifying process_files.sh, we can remove "no-
pqueue"
from process_files.sh so that OpensslLib.inf is in sync.

I can send out a patch to do so if you wish.

Thomas

-----Original Message-----
From: Jiaxin Wu [mailto:jiaxin.wu@intel.com]
Sent: Thursday, July 14, 2016 12:51 AM
To: edk2-devel@lists.01.org
Cc: Liming Gao <liming.gao@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; Long Qin <qin.long@intel.com>; Ye Ting
<ting.ye@intel.com>; Fu Siyuan <siyuan.fu@intel.com>; Wu Jiaxin
<jiaxin.wu@intel.com>
Subject: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions
with the standardized one

The series patches are used to replace the TLS definitions with the
standardized one. In addition, more TLS cipher suite mapping between
Cipher Suite definitions and OpenSSL-used Cipher Suite name are added.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Palmer Thomas <thomas.palmer@hpe.com>
Cc: Long Qin <qin.long@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>

Jiaxin Wu (4):
MdePkg: Add a header to standardize TLS definitions
CryptoPkg: Add more TLS cipher suite mapping
NetworkPkg/TlsDxe: Replace the definitions with the standardized one
NetworkPkg/HttpDxe: Replace the definitions with the standardized
one

CryptoPkg/Library/TlsLib/TlsLib.c | 3585 ++++++++++++++++--------------
--
MdePkg/Include/IndustryStandard/Tls1.h | 93 +
NetworkPkg/HttpDxe/HttpDriver.h | 2 +
NetworkPkg/HttpDxe/HttpProto.c | 12 +-
NetworkPkg/HttpDxe/HttpsSupport.c | 22 +-
NetworkPkg/HttpDxe/HttpsSupport.h | 44 -
NetworkPkg/TlsDxe/TlsImpl.c | 56 +-
NetworkPkg/TlsDxe/TlsImpl.h | 30 +-
NetworkPkg/TlsDxe/TlsProtocol.c | 2 +-
9 files changed, 1945 insertions(+), 1901 deletions(-) create mode
100644 MdePkg/Include/IndustryStandard/Tls1.h

--
1.9.5.msysgit.1

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


Re: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Wu, Jiaxin <jiaxin.wu@...>
 

Thomas,
I agree some of them are not supported due to the UEFI OpenSSL configuration, but it doesn't affect those mapping relationship added in the patch. So, I have no strong opinion whether to support it by modifying the current OpenSSL configuration. Since Qin is the OpenSSL expert, I'd like to hear his views.

Qin,
What's your opinion?

Thanks.
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Palmer, Thomas
Sent: Saturday, July 30, 2016 6:03 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Gao,
Liming <liming.gao@intel.com>; Long, Qin <qin.long@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin,

UEFI's OpenSSL library does not support all the ciphers that were
added in your patch due to the UEFI configuration. We need to remove "no-
idea" and "no-dsa" from the process_files.sh and add "enable-weak-ssl-
ciphers"

While we are modifying process_files.sh, we can remove "no-
pqueue" from process_files.sh so that OpensslLib.inf is in sync.

I can send out a patch to do so if you wish.

Thomas

-----Original Message-----
From: Jiaxin Wu [mailto:jiaxin.wu@intel.com]
Sent: Thursday, July 14, 2016 12:51 AM
To: edk2-devel@lists.01.org
Cc: Liming Gao <liming.gao@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; Long Qin <qin.long@intel.com>; Ye Ting
<ting.ye@intel.com>; Fu Siyuan <siyuan.fu@intel.com>; Wu Jiaxin
<jiaxin.wu@intel.com>
Subject: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the
standardized one

The series patches are used to replace the TLS definitions with the
standardized one. In addition, more TLS cipher suite mapping between
Cipher Suite definitions and OpenSSL-used Cipher Suite name are added.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Palmer Thomas <thomas.palmer@hpe.com>
Cc: Long Qin <qin.long@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>

Jiaxin Wu (4):
MdePkg: Add a header to standardize TLS definitions
CryptoPkg: Add more TLS cipher suite mapping
NetworkPkg/TlsDxe: Replace the definitions with the standardized one
NetworkPkg/HttpDxe: Replace the definitions with the standardized one

CryptoPkg/Library/TlsLib/TlsLib.c | 3585 ++++++++++++++++----------------
MdePkg/Include/IndustryStandard/Tls1.h | 93 +
NetworkPkg/HttpDxe/HttpDriver.h | 2 +
NetworkPkg/HttpDxe/HttpProto.c | 12 +-
NetworkPkg/HttpDxe/HttpsSupport.c | 22 +-
NetworkPkg/HttpDxe/HttpsSupport.h | 44 -
NetworkPkg/TlsDxe/TlsImpl.c | 56 +-
NetworkPkg/TlsDxe/TlsImpl.h | 30 +-
NetworkPkg/TlsDxe/TlsProtocol.c | 2 +-
9 files changed, 1945 insertions(+), 1901 deletions(-) create mode 100644
MdePkg/Include/IndustryStandard/Tls1.h

--
1.9.5.msysgit.1

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


Re: [PATCH] add top-level .gitattributes file, dealing with .depex

Michael D Kinney
 

Jordan,

UEFI Drivers distributed as binaries do not need depex sections.

PI modules distributed as binaries do require a .depex binary.

So I would recommend .depex binary files be treated the same as
binary .efi files by GIT. So it does sound like we need some
minor updates to GIT attributes.

If we have an example of a binary module that is providing more
binary leaf sections than are actually required and/or used, then
yes, the binary module should be cleaned up to remove the unused
content.

Thanks,

Mike

-----Original Message-----
From: Justen, Jordan L
Sent: Sunday, July 31, 2016 3:58 PM
To: Leif Lindholm <leif.lindholm@linaro.org>; Tim Lewis <tim.lewis@insyde.com>
Cc: Laszlo Ersek <lersek@redhat.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
edk2-devel@ml01.01.org <edk2-devel@lists.01.org>; Andrew Fish <afish@apple.com>
Subject: Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

On 2016-07-30 11:33:43, Leif Lindholm wrote:
Hi Tim,

Thanks for the warning, and investigation.

Does this mean that you think we should ban the inclusion of .depex
files in EDK2, including future platform trees?
I don't know about banning it, but at least we could wait for someone
to make a reasonable argument why they are needed.

Even for binary only modules, it looks like the fdf method outlined
below is preferable to a pre-built .depex.

If (at a future point) the reason for using a .depex is to support a
binary only module in a supposedly open platform under EDK II, then I
guess we can decide if that is a good idea at that point.

Should we delete this one unused .depex from the tree?

-Jordan

(If not, this patch is
still needed for git to work predictably with these files.)

Regards,

Leif

On Fri, Jul 29, 2016 at 05:12:49PM +0000, Tim Lewis wrote:
It appears that this file is not actually used. It is only
referenced in the [Rule.Common.UEFI_DRIVER.NATIVE_BINARY] rule in
PlatformPkg.fdf. A little further research shows that an alternate
method was used for the actual GOP binary (see below). A grep of the
entire tree shows that no one uses this rule NATIVE_BINARY. So it
looks like it can just be cut out.

BTW, the downside of the method used for the binary version of the
GOP driver, is that those drivers cannot use PCDs, since the PCD
database is created based on references in the .inf. GOP works
because it is pure UEFI and (therefore) doesn't use PCDs.

Tim

FILE DRIVER = FF0C8745-3270-4439-B74F-3E45F8C77064 {
SECTION DXE_DEPEX_EXP = {gPlatformGOPPolicyGuid}
SECTION PE32 =
Vlv2MiscBinariesPkg/GOP/7.2.1011/RELEASE_VS2008x86/$(DXE_ARCHITECTURE)/IntelGopDriver.e
fi
SECTION UI = "IntelGopDriver"
}

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Leif
Lindholm
Sent: Friday, July 29, 2016 9:45 AM
To: Laszlo Ersek <lersek@redhat.com>
Cc: michael.d.kinney@intel.com; Jordan Justen <jordan.l.justen@intel.com>; edk2-
devel@ml01.01.org; Andrew Fish <afish@apple.com>
Subject: Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

On Thu, Jul 07, 2016 at 05:03:13PM +0200, Laszlo Ersek wrote:
On 07/07/16 16:24, Leif Lindholm wrote:
Git tends to see .depex files as text, causing hideous patches being
generated (and breaking PatchCheck.py).

Add a .gitattributes file instructing git to treat them as binary.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
---
.gitattributes | 1 +
1 file changed, 1 insertion(+)
create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes new file mode 100644
index 0000000..2d8a45b
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+*.depex binary
What generates .depex files? I've never seen any.

Also, unless you add .depex files with "git add" to the set of tracked
files, no patches / diffs should cover them. What am I missing? :)

... Hm, after

$ find . -iname "*.depex"

I see .depex files in Build/ (which should be ignored altogether), and

./Vlv2TbltDevicePkg/IntelGopDepex/IntelGopDriver.depex

Why does that file exist in the tree? Let me see... git log says nothing relevant
(the file dates back to commit 3cbfba02fef9, "Upload BSD-licensed Vlv2TbltDevicePkg and
Vlv2DeviceRefCodePkg to").

Grepping the tree for the filename itself leads to:

Vlv2TbltDevicePkg/PlatformPkg.fdf: DXE_DEPEX DXE_DEPEX Optional
$(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex
Vlv2TbltDevicePkg/PlatformPkgGcc.fdf: DXE_DEPEX DXE_DEPEX Optional
$(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex

Do these rules exist to override the DEPEX sections of binary-only modules? If
so: that's horrible.

Anyway, given that edk2 contains at least one .depex file, and your patch is
correct according to <https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes>:

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks!

I had hoped for comments from someone else on cc, since we don't have any
Maintainers.txt entry for the top level directory :)

But if I don't hear anything before Monday, I'll push it then.

Regards,

Leif

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


Re: [PATCH] add top-level .gitattributes file, dealing with .depex

Jordan Justen
 

On 2016-07-30 11:33:43, Leif Lindholm wrote:
Hi Tim,

Thanks for the warning, and investigation.

Does this mean that you think we should ban the inclusion of .depex
files in EDK2, including future platform trees?
I don't know about banning it, but at least we could wait for someone
to make a reasonable argument why they are needed.

Even for binary only modules, it looks like the fdf method outlined
below is preferable to a pre-built .depex.

If (at a future point) the reason for using a .depex is to support a
binary only module in a supposedly open platform under EDK II, then I
guess we can decide if that is a good idea at that point.

Should we delete this one unused .depex from the tree?

-Jordan

(If not, this patch is
still needed for git to work predictably with these files.)

Regards,

Leif

On Fri, Jul 29, 2016 at 05:12:49PM +0000, Tim Lewis wrote:
It appears that this file is not actually used. It is only
referenced in the [Rule.Common.UEFI_DRIVER.NATIVE_BINARY] rule in
PlatformPkg.fdf. A little further research shows that an alternate
method was used for the actual GOP binary (see below). A grep of the
entire tree shows that no one uses this rule NATIVE_BINARY. So it
looks like it can just be cut out.

BTW, the downside of the method used for the binary version of the
GOP driver, is that those drivers cannot use PCDs, since the PCD
database is created based on references in the .inf. GOP works
because it is pure UEFI and (therefore) doesn't use PCDs.

Tim

FILE DRIVER = FF0C8745-3270-4439-B74F-3E45F8C77064 {
SECTION DXE_DEPEX_EXP = {gPlatformGOPPolicyGuid}
SECTION PE32 = Vlv2MiscBinariesPkg/GOP/7.2.1011/RELEASE_VS2008x86/$(DXE_ARCHITECTURE)/IntelGopDriver.efi
SECTION UI = "IntelGopDriver"
}

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Leif Lindholm
Sent: Friday, July 29, 2016 9:45 AM
To: Laszlo Ersek <lersek@redhat.com>
Cc: michael.d.kinney@intel.com; Jordan Justen <jordan.l.justen@intel.com>; edk2-devel@ml01.01.org; Andrew Fish <afish@apple.com>
Subject: Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

On Thu, Jul 07, 2016 at 05:03:13PM +0200, Laszlo Ersek wrote:
On 07/07/16 16:24, Leif Lindholm wrote:
Git tends to see .depex files as text, causing hideous patches being
generated (and breaking PatchCheck.py).

Add a .gitattributes file instructing git to treat them as binary.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
---
.gitattributes | 1 +
1 file changed, 1 insertion(+)
create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes new file mode 100644
index 0000000..2d8a45b
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+*.depex binary
What generates .depex files? I've never seen any.

Also, unless you add .depex files with "git add" to the set of tracked
files, no patches / diffs should cover them. What am I missing? :)

... Hm, after

$ find . -iname "*.depex"

I see .depex files in Build/ (which should be ignored altogether), and

./Vlv2TbltDevicePkg/IntelGopDepex/IntelGopDriver.depex

Why does that file exist in the tree? Let me see... git log says nothing relevant (the file dates back to commit 3cbfba02fef9, "Upload BSD-licensed Vlv2TbltDevicePkg and Vlv2DeviceRefCodePkg to").

Grepping the tree for the filename itself leads to:

Vlv2TbltDevicePkg/PlatformPkg.fdf: DXE_DEPEX DXE_DEPEX Optional $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex
Vlv2TbltDevicePkg/PlatformPkgGcc.fdf: DXE_DEPEX DXE_DEPEX Optional $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex

Do these rules exist to override the DEPEX sections of binary-only modules? If so: that's horrible.

Anyway, given that edk2 contains at least one .depex file, and your patch is correct according to <https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes>:

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks!

I had hoped for comments from someone else on cc, since we don't have any Maintainers.txt entry for the top level directory :)

But if I don't hear anything before Monday, I'll push it then.

Regards,

Leif

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


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

Ard Biesheuvel
 

On 31 July 2016 at 07:42, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
On 31 July 2016 at 05:08, Shi, Steven <steven.shi@intel.com> wrote:
OK. Could we do that in a separate patch?
[Steven]: Yes. We could separate it in a new patch.

Is this necessary? I would expect the GOT entry itself to be already
covered by a R_X86_64_64 relocation, so I don't think there is a need
to emit a EFI_IMAGE_REL_BASED_DIR64 PE/COFF reloc here.
[Steven]: Do you ask whether it is still necessary to support the
GOTPCREL/GOTPCRELX/REX_GOTPCRELX new relocation types? I think they
are nice to have now, since new type support has no impact to old ones, we
could just leave the code there for reference.

No. The question is whether it is necessary to emit the
EFI_IMAGE_REL_BASED_DIR64 fixup reloc here. The relocation place is
the instruction, not the GOT entry, and I would expect the GOT entry
to be covered by a R_X86_64_64 relocation already
[Steven]: Yes, it is necessary. Even the R_X86_64_64 relocation need to emit the EFI_IMAGE_REL_BASED_DIR64 fixup reloc like below in the original GenFw code. You can test it like this, remove the below CoffAddFixup() code and build the OVMF with GCC5, you will see the Ovmf boot failure with cpu exception.

case R_X86_64_64:
VerboseMsg ("EFI_IMAGE_REL_BASED_DIR64 Offset: 0x%08X",
mCoffSectionsOffset[RelShdr->sh_info] + (Rel->r_offset - SecShdr->sh_addr));
CoffAddFixup(
(UINT32) ((UINT64) mCoffSectionsOffset[RelShdr->sh_info]
+ (Rel->r_offset - SecShdr->sh_addr)),
EFI_IMAGE_REL_BASED_DIR64);
That was not my point. With your code, how many
EFI_IMAGE_REL_BASED_DIR64 fixups are added to the .reloc section for
the GOT entry of 'n'?

int n;
int f () { return n; }
int g () { return n; }
int h () { return n; }
I am also concerned about the GOTPCRELX/REX_GOTPCRELX relocations.
Reading the x86_64 ABI docs, it appears that these may refer to
instructions that have been modified by the linker. In that case, how
do we deal with the relocation? Also, according to the doc, mov
instructions may be emitted by the linker in some cases that are only
valid in the lowest 2 GB of the address space.

All in all, I think supporting GOT based relocations is a can of
worms, and I would prefer to get rid of them completely if we can
(i.e., using hidden visibility even for LTO, I have a fix for that I
will sent out separately)

Thanks,
Ard.


Re: [PATCH v4 0/7] BaseTools: add support for GCC5 in LTO mode

Ard Biesheuvel
 

On 30 July 2016 at 16:34, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
On 29 July 2016 at 17:18, Gao, Liming <liming.gao@intel.com> wrote:
Ard:

My gcc version 5.3.0 20151204 (Ubuntu 5.3.0-3ubuntu1~14.04). I will try
GCC54.
I cannot reproduce this with 5.3.1-14ubuntu2.1 either.
@Liming: is the issue still reproducible with this change?

"""
diff --git a/MdePkg/Include/X64/ProcessorBind.h
b/MdePkg/Include/X64/ProcessorBind.h
index a4aad3e..73cf799 100644
--- a/MdePkg/Include/X64/ProcessorBind.h
+++ b/MdePkg/Include/X64/ProcessorBind.h
@@ -34,7 +34,7 @@
// symbols directly using relative references rather than via the GOT, which
// contains absolute symbol addresses that are subject to runtime relocation.
//
-#pragma GCC visibility push (protected)
+#pragma GCC visibility push (hidden)
#endif

#if defined(__INTEL_COMPILER)
"""

Thanks,
Ard.


Re: Intel FSP Firmware Volume content

Yao, Jiewen
 

HI Marvin
I found you mention: “If one spends a few hours on FSP, I think it wouldn't be too hard to split the binary and integrate its PEIMs into the host Boot Loader directly, so that the isolated PEI would not be needed with UEFI PI-compatible firmware... just that the DXE modules, that FSP ships, will remain modded to be PEIMs.”

I would like to point out that, this is an undefined behavior. It might or might not work, depending on each PEIM module.

If the PEIM does not have FSP dependency, you may extract it and put to host boot loader.
If the PEIM has FSP dependency, such as FSP global information, you might get incorrect initialization or even system hang, if you put it to host boot loader directly.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Marvin H?user
Sent: Sunday, July 31, 2016 10:48 AM
To: edk2-devel@lists.01.org
Cc: rafaelrodrigues.machado@gmail.com
Subject: Re: [edk2] Intel FSP Firmware Volume content

Hey Rafael and Giri,

Thanks for your information. I really appreciate your answers and time, though the answers have been quite general.

But I think I finally got the hang of FSP. The following is how I understand it by looking at FSP binaries and IntelFspPkg and by now means a verified explaination:
As Intel FSP is based on the Intel Reference Code, it of course relies on UEFI and UEFI PI concepts. So, one's own SecCore is supposed to handle the reset vector and do anything you want to do with the exception of setting up CAR. When it's time for CAR to be set up, you pass control to FspSecCore, which does its internal checks and other magic...
When you, at a later point in time, call the API to set up the Silicon, FspSecCore starts its own PeiCore (it cannot know about the existing one as it is Boot Loader-independent) and this one executes all modules within the FSP binary, as they are within the FV of FSP's PeiCore. So, in this isolated PeiCore, everything is happening that would be happening on a platform that embeds the Intel Reference Code, from start to end. The Dxe modules seem to be Intel RC modules, that are usually executed in DXE phase but, as FSP is entirely 32-bit anyway, are simply called as part of the isolated PEI phase (probably modded for FSP usage) and a HOB list is built, as it would in 'normal PEI'. FspDxeIpl is actually returning the control back tot he host Boot Loader, returning the HOB list oft he isolated PEI - and as the HOB list is the only thing DXE gets from all stages before, all modules in the FSP bin have served their purpose, just isolated. The HOBs are returned to the host Boot Loader and it is the very same situation, as if it executed the PEIMs itself.

Summary: As far as I can see, FSP is launching an isolated PEI to execute all platform init modules and collect the HOBs.

If one spends a few hours on FSP, I think it wouldn't be too hard to split the binary and integrate its PEIMs into the host Boot Loader directly, so that the isolated PEI would not be needed with UEFI PI-compatible firmware... just that the DXE modules, that FSP ships, will remain modded to be PEIMs.

Thanks again for your time!

Best regards,
Marvin.

-----Original Message-----
From: Mudusuru, Giri P [mailto:giri.p.mudusuru@intel.com]
Sent: Friday, July 8, 2016 9:38 AM
To: Rafael Machado <rafaelrodrigues.machado@gmail.com<mailto:rafaelrodrigues.machado@gmail.com>>; Marvin H?user
<Marvin.Haeuser@outlook.com<mailto:Marvin.Haeuser@outlook.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Mudusuru, Giri P
<giri.p.mudusuru@intel.com<mailto:giri.p.mudusuru@intel.com>>
Subject: RE: [edk2] Intel FSP Firmware Volume content

Hi Marvin, Rafael,

Thank you for your studies on FSP.

FSP is a self-contained binary. Since the silicon code implementation is based
on edk2, some modules are redundant like PeiCore, DxeIpl as Rafael
explained below (Thanks Rafael).
While it is redundant, it is a small price to make FSP binary pluggable into
different bootloaders (EDK2, Coreboot etc...)

Also entire FSP is implemented in PEI phase and DXE code is built in Dual
mode (DXE and PEI for FSP) which is why you see *DxeFsp

Hope this clarifies your questions

Thanks and Regards,
-Giri

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Rafael Machado
Sent: Thursday, July 7, 2016 4:31 AM
To: Marvin H?user <Marvin.Haeuser@outlook.com<mailto:Marvin.Haeuser@outlook.com>>;
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>
Subject: Re: [edk2] Intel FSP Firmware Volume content

Hi Marvin

I'm also starting my studies on FSP, but I think I can help with at
least one of the questions.
About the two Sec cores.

The existence of two sec cores represents what is called "FSP Normal Boot"
There is the main sec core, and another sec core that is placed inside
the FspInitPei. They communicate to each other so the needed
information is passed correctly.

Each sec core has it's responsibilities, so they don't do the same thing.

Hope this can help you to find more information.

Thanks and Regards
Rafael R. Machado



Em qua, 6 de jul de 2016 às 20:40, Marvin H?user
<Marvin.Haeuser@outlook.com<mailto:Marvin.Haeuser@outlook.com>>
escreveu:

Dear EDK2 community members,

Recently, I have gained interest in the Intel FSP and have been
reading the Intel documents regarding its design and integration with
EDK2.
In the white paper 'A Tour Beyond BIOS Using the Intel(r) Firmware
Support Package with the EFI Developer Kit II', the chapter 'FSP Wrapper
Boot Flow'
mentions different ways of how SecCore and following can interact with
FSP.
This, in my opinion, implies that SecCore is present in source-form
(likely IntelFspWrapperPkg/FspWrapperSecCore), while the actual
silicon initialization is of course within the FSP binary. This is
how I understood it and thought it made sense.
However, when I opened a few of the FSP Firmware Volume files, I
discovered that it did not only have the FSP header and
initialization PEIMs/drivers, but also SecCore, PeiCore and
FspDxeIpl embedded. For what reason are these generic modules
embedded? Until discovering them within the image, I had assumed
these would be provided by the consumer package.
To better understand the creation and consumption of Intel FSP, I
have looked at Quark and Braswell Reference Codes provided within
the edk2-platforms tree. BraswellPlatformPkg, which consumes
BSWFSP.fd that
has
SecCore embedded, also consumes FspWrapperSecCore (seen here:
https://github.com/tianocore/edk2-platforms/blob/pentium-celeron-n-
udk2015/BraswellPlatformPkg/PlatformPkg.fdf#L387)
from the source tree. If I am not mistaken, building it would end up
having SecCore duplicated - once as part of the FSP volume (binary)
and once within the FVRECOVERY volume (source). As SecCore includes
the Reset Vector, wouldn't one of the two be obsolete as it would never
be invoked?
The same applies to PeiCore and a few other generic modules which
are part oft he chain.

Furthermore, a couple of modules that have 'Dxe' in their name are
declared as PEI module in their FFS header, for example
'PchInitDxeFsp'. I have observed this in all FSP version I have
looked at, including Braswell, Broadwell and Ivy Bridge. Is there
any special reason for that? Is it because the FSP initialization
code is what has them loaded and called, so it doesn't matter?

Please forgive me for my ignorance and thank you in advance for your
time!

Best regards,
Marvin.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

Ard Biesheuvel
 

On 31 July 2016 at 05:08, Shi, Steven <steven.shi@intel.com> wrote:
OK. Could we do that in a separate patch?
[Steven]: Yes. We could separate it in a new patch.

Is this necessary? I would expect the GOT entry itself to be already
covered by a R_X86_64_64 relocation, so I don't think there is a need
to emit a EFI_IMAGE_REL_BASED_DIR64 PE/COFF reloc here.
[Steven]: Do you ask whether it is still necessary to support the
GOTPCREL/GOTPCRELX/REX_GOTPCRELX new relocation types? I think they
are nice to have now, since new type support has no impact to old ones, we
could just leave the code there for reference.

No. The question is whether it is necessary to emit the
EFI_IMAGE_REL_BASED_DIR64 fixup reloc here. The relocation place is
the instruction, not the GOT entry, and I would expect the GOT entry
to be covered by a R_X86_64_64 relocation already
[Steven]: Yes, it is necessary. Even the R_X86_64_64 relocation need to emit the EFI_IMAGE_REL_BASED_DIR64 fixup reloc like below in the original GenFw code. You can test it like this, remove the below CoffAddFixup() code and build the OVMF with GCC5, you will see the Ovmf boot failure with cpu exception.

case R_X86_64_64:
VerboseMsg ("EFI_IMAGE_REL_BASED_DIR64 Offset: 0x%08X",
mCoffSectionsOffset[RelShdr->sh_info] + (Rel->r_offset - SecShdr->sh_addr));
CoffAddFixup(
(UINT32) ((UINT64) mCoffSectionsOffset[RelShdr->sh_info]
+ (Rel->r_offset - SecShdr->sh_addr)),
EFI_IMAGE_REL_BASED_DIR64);
That was not my point. With your code, how many
EFI_IMAGE_REL_BASED_DIR64 fixups are added to the .reloc section for
the GOT entry of 'n'?

int n;
int f () { return n; }
int g () { return n; }
int h () { return n; }


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

Shi, Steven <steven.shi@...>
 

OK. Could we do that in a separate patch?
[Steven]: Yes. We could separate it in a new patch.

Is this necessary? I would expect the GOT entry itself to be already
covered by a R_X86_64_64 relocation, so I don't think there is a need
to emit a EFI_IMAGE_REL_BASED_DIR64 PE/COFF reloc here.
[Steven]: Do you ask whether it is still necessary to support the
GOTPCREL/GOTPCRELX/REX_GOTPCRELX new relocation types? I think they
are nice to have now, since new type support has no impact to old ones, we
could just leave the code there for reference.

No. The question is whether it is necessary to emit the
EFI_IMAGE_REL_BASED_DIR64 fixup reloc here. The relocation place is
the instruction, not the GOT entry, and I would expect the GOT entry
to be covered by a R_X86_64_64 relocation already
[Steven]: Yes, it is necessary. Even the R_X86_64_64 relocation need to emit the EFI_IMAGE_REL_BASED_DIR64 fixup reloc like below in the original GenFw code. You can test it like this, remove the below CoffAddFixup() code and build the OVMF with GCC5, you will see the Ovmf boot failure with cpu exception.

case R_X86_64_64:
VerboseMsg ("EFI_IMAGE_REL_BASED_DIR64 Offset: 0x%08X",
mCoffSectionsOffset[RelShdr->sh_info] + (Rel->r_offset - SecShdr->sh_addr));
CoffAddFixup(
(UINT32) ((UINT64) mCoffSectionsOffset[RelShdr->sh_info]
+ (Rel->r_offset - SecShdr->sh_addr)),
EFI_IMAGE_REL_BASED_DIR64);

Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


Re: Intel FSP Firmware Volume content

Marvin Häuser <Marvin.Haeuser@...>
 

Hey Rafael and Giri,

Thanks for your information. I really appreciate your answers and time, though the answers have been quite general.

But I think I finally got the hang of FSP. The following is how I understand it by looking at FSP binaries and IntelFspPkg and by now means a verified explaination:
As Intel FSP is based on the Intel Reference Code, it of course relies on UEFI and UEFI PI concepts. So, one's own SecCore is supposed to handle the reset vector and do anything you want to do with the exception of setting up CAR. When it's time for CAR to be set up, you pass control to FspSecCore, which does its internal checks and other magic...
When you, at a later point in time, call the API to set up the Silicon, FspSecCore starts its own PeiCore (it cannot know about the existing one as it is Boot Loader-independent) and this one executes all modules within the FSP binary, as they are within the FV of FSP's PeiCore. So, in this isolated PeiCore, everything is happening that would be happening on a platform that embeds the Intel Reference Code, from start to end. The Dxe modules seem to be Intel RC modules, that are usually executed in DXE phase but, as FSP is entirely 32-bit anyway, are simply called as part of the isolated PEI phase (probably modded for FSP usage) and a HOB list is built, as it would in 'normal PEI'. FspDxeIpl is actually returning the control back tot he host Boot Loader, returning the HOB list oft he isolated PEI - and as the HOB list is the only thing DXE gets from all stages before, all modules in the FSP bin have served their purpose, just isolated. The HOBs are returned to the host Boot Loader and it is the very same situation, as if it executed the PEIMs itself.

Summary: As far as I can see, FSP is launching an isolated PEI to execute all platform init modules and collect the HOBs.

If one spends a few hours on FSP, I think it wouldn't be too hard to split the binary and integrate its PEIMs into the host Boot Loader directly, so that the isolated PEI would not be needed with UEFI PI-compatible firmware... just that the DXE modules, that FSP ships, will remain modded to be PEIMs.

Thanks again for your time!

Best regards,
Marvin.

-----Original Message-----
From: Mudusuru, Giri P [mailto:giri.p.mudusuru@intel.com]
Sent: Friday, July 8, 2016 9:38 AM
To: Rafael Machado <rafaelrodrigues.machado@gmail.com>; Marvin H?user
<Marvin.Haeuser@outlook.com>; edk2-devel@lists.01.org
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Mudusuru, Giri P
<giri.p.mudusuru@intel.com>
Subject: RE: [edk2] Intel FSP Firmware Volume content

Hi Marvin, Rafael,

Thank you for your studies on FSP.

FSP is a self-contained binary. Since the silicon code implementation is based
on edk2, some modules are redundant like PeiCore, DxeIpl as Rafael
explained below (Thanks Rafael).
While it is redundant, it is a small price to make FSP binary pluggable into
different bootloaders (EDK2, Coreboot etc...)

Also entire FSP is implemented in PEI phase and DXE code is built in Dual
mode (DXE and PEI for FSP) which is why you see *DxeFsp

Hope this clarifies your questions

Thanks and Regards,
-Giri

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Rafael Machado
Sent: Thursday, July 7, 2016 4:31 AM
To: Marvin H?user <Marvin.Haeuser@outlook.com>;
edk2-devel@lists.01.org
Cc: Yao, Jiewen <jiewen.yao@intel.com>
Subject: Re: [edk2] Intel FSP Firmware Volume content

Hi Marvin

I'm also starting my studies on FSP, but I think I can help with at
least one of the questions.
About the two Sec cores.

The existence of two sec cores represents what is called "FSP Normal Boot"
There is the main sec core, and another sec core that is placed inside
the FspInitPei. They communicate to each other so the needed
information is passed correctly.

Each sec core has it's responsibilities, so they don't do the same thing.

Hope this can help you to find more information.

Thanks and Regards
Rafael R. Machado



Em qua, 6 de jul de 2016 às 20:40, Marvin H?user
<Marvin.Haeuser@outlook.com>
escreveu:

Dear EDK2 community members,

Recently, I have gained interest in the Intel FSP and have been
reading the Intel documents regarding its design and integration with
EDK2.
In the white paper 'A Tour Beyond BIOS Using the Intel(r) Firmware
Support Package with the EFI Developer Kit II', the chapter 'FSP Wrapper
Boot Flow'
mentions different ways of how SecCore and following can interact with
FSP.
This, in my opinion, implies that SecCore is present in source-form
(likely IntelFspWrapperPkg/FspWrapperSecCore), while the actual
silicon initialization is of course within the FSP binary. This is
how I understood it and thought it made sense.
However, when I opened a few of the FSP Firmware Volume files, I
discovered that it did not only have the FSP header and
initialization PEIMs/drivers, but also SecCore, PeiCore and
FspDxeIpl embedded. For what reason are these generic modules
embedded? Until discovering them within the image, I had assumed
these would be provided by the consumer package.
To better understand the creation and consumption of Intel FSP, I
have looked at Quark and Braswell Reference Codes provided within
the edk2-platforms tree. BraswellPlatformPkg, which consumes
BSWFSP.fd that
has
SecCore embedded, also consumes FspWrapperSecCore (seen here:
https://github.com/tianocore/edk2-platforms/blob/pentium-celeron-n-
udk2015/BraswellPlatformPkg/PlatformPkg.fdf#L387)
from the source tree. If I am not mistaken, building it would end up
having SecCore duplicated - once as part of the FSP volume (binary)
and once within the FVRECOVERY volume (source). As SecCore includes
the Reset Vector, wouldn't one of the two be obsolete as it would never
be invoked?
The same applies to PeiCore and a few other generic modules which
are part oft he chain.

Furthermore, a couple of modules that have 'Dxe' in their name are
declared as PEI module in their FFS header, for example
'PchInitDxeFsp'. I have observed this in all FSP version I have
looked at, including Braswell, Broadwell and Ivy Bridge. Is there
any special reason for that? Is it because the FSP initialization
code is what has them loaded and called, so it doesn't matter?

Please forgive me for my ignorance and thank you in advance for your
time!

Best regards,
Marvin.
_______________________________________________
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: Ingebrigtsen: The End of Gmane?

Bruce Cran <bruce@...>
 

On 7/28/2016 1:19 PM, Andrew Fish wrote:

Seems he will send you the disks. What could go wrong?
I'm actually tempted to take him up on that offer.
Just today I went looking for information about UefiDebugLib to see if it was possible for a driver to print debug information to the serial port (or other sort of debug device) instead of the console, and came across the thread at
http://comments.gmane.org/gmane.comp.bios.tianocore.devel/3024 where thanks to Google's cache I learned that:

"The EDK used some Tiano and implementation defined protocols to support DEBUG and ASSERT macros. So DEBUG
and ASSERT from the EDK can only be reliably used if you compile all the EDK firmware together. As Liming
points out it is much safer to use a UEFI console based debug message for developing generic drivers and
applications."

It's a shame to lose information like that.

--
Bruce


Re: [PATCH] add top-level .gitattributes file, dealing with .depex

Leif Lindholm <leif.lindholm@...>
 

Hi Tim,

Thanks for the warning, and investigation.

Does this mean that you think we should ban the inclusion of .depex
files in EDK2, including future platform trees? (If not, this patch is
still needed for git to work predictably with these files.)

Regards,

Leif

On Fri, Jul 29, 2016 at 05:12:49PM +0000, Tim Lewis wrote:
It appears that this file is not actually used. It is only
referenced in the [Rule.Common.UEFI_DRIVER.NATIVE_BINARY] rule in
PlatformPkg.fdf. A little further research shows that an alternate
method was used for the actual GOP binary (see below). A grep of the
entire tree shows that no one uses this rule NATIVE_BINARY. So it
looks like it can just be cut out.

BTW, the downside of the method used for the binary version of the
GOP driver, is that those drivers cannot use PCDs, since the PCD
database is created based on references in the .inf. GOP works
because it is pure UEFI and (therefore) doesn't use PCDs.

Tim

FILE DRIVER = FF0C8745-3270-4439-B74F-3E45F8C77064 {
SECTION DXE_DEPEX_EXP = {gPlatformGOPPolicyGuid}
SECTION PE32 = Vlv2MiscBinariesPkg/GOP/7.2.1011/RELEASE_VS2008x86/$(DXE_ARCHITECTURE)/IntelGopDriver.efi
SECTION UI = "IntelGopDriver"
}

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Leif Lindholm
Sent: Friday, July 29, 2016 9:45 AM
To: Laszlo Ersek <lersek@redhat.com>
Cc: michael.d.kinney@intel.com; Jordan Justen <jordan.l.justen@intel.com>; edk2-devel@ml01.01.org; Andrew Fish <afish@apple.com>
Subject: Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

On Thu, Jul 07, 2016 at 05:03:13PM +0200, Laszlo Ersek wrote:
On 07/07/16 16:24, Leif Lindholm wrote:
Git tends to see .depex files as text, causing hideous patches being
generated (and breaking PatchCheck.py).

Add a .gitattributes file instructing git to treat them as binary.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
---
.gitattributes | 1 +
1 file changed, 1 insertion(+)
create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes new file mode 100644
index 0000000..2d8a45b
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+*.depex binary
What generates .depex files? I've never seen any.

Also, unless you add .depex files with "git add" to the set of tracked
files, no patches / diffs should cover them. What am I missing? :)

... Hm, after

$ find . -iname "*.depex"

I see .depex files in Build/ (which should be ignored altogether), and

./Vlv2TbltDevicePkg/IntelGopDepex/IntelGopDriver.depex

Why does that file exist in the tree? Let me see... git log says nothing relevant (the file dates back to commit 3cbfba02fef9, "Upload BSD-licensed Vlv2TbltDevicePkg and Vlv2DeviceRefCodePkg to").

Grepping the tree for the filename itself leads to:

Vlv2TbltDevicePkg/PlatformPkg.fdf: DXE_DEPEX DXE_DEPEX Optional $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex
Vlv2TbltDevicePkg/PlatformPkgGcc.fdf: DXE_DEPEX DXE_DEPEX Optional $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex

Do these rules exist to override the DEPEX sections of binary-only modules? If so: that's horrible.

Anyway, given that edk2 contains at least one .depex file, and your patch is correct according to <https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes>:

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks!

I had hoped for comments from someone else on cc, since we don't have any Maintainers.txt entry for the top level directory :)

But if I don't hear anything before Monday, I'll push it then.

Regards,

Leif

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