Re: [edk2] [PATCH v4 1/9] MdeModulePkg/PlatformBootManager: Add PlatformBootManagerUnableToBoot

[Wang, Sunny (HPS SW)]

Looks good to me. 
Reviewed-by: Sunny Wang 

-Original Message-
From: Ruiyu Ni [mailto:ruiyu...@intel.com] 
Sent: Wednesday, July 04, 2018 9:51 AM
To: edk2-devel@lists.01.org
Cc: Sean Brogan ; Michael Turner 
; Wang, Sunny (HPS SW) 
Subject: [PATCH v4 1/9] MdeModulePkg/PlatformBootManager: Add 
PlatformBootManagerUnableToBoot

The patch adds a new API PlatformBootManagerUnableToBoot() to 
PlatformBootManagerLib.
The new API is provided by platform bds library and is called when no boot 
option could be launched.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Sean Brogan 
Cc: Michael Turner 
Reviewed-by: Laszlo Ersek 
Cc: Sunny Wang 
---
 MdeModulePkg/Include/Library/PlatformBootManagerLib.h | 13 +  
.../PlatformBootManagerLibNull/PlatformBootManager.c  | 19 ++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Include/Library/PlatformBootManagerLib.h 
b/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
index 65630ce2bb..6e26329043 100644
--- a/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
+++ b/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
@@ -59,4 +59,17 @@ PlatformBootManagerWaitCallback (
   UINT16  TimeoutRemain
   );
 
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to 
+applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  );
+
 #endif
diff --git 
a/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c 
b/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
index 1390e19097..5a4455ef23 100644
--- a/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
+++ b/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManage
+++ r.c
@@ -2,7 +2,7 @@
   This file include all platform action which can be customized
   by IBV/OEM.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -65,3 +65,20 @@ 
PlatformBootManagerWaitCallback (  {
   return;
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to 
+applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  return;
+}
+
--
2.16.1.windows.1

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

Re: [edk2] [PATCH v4 9/9] MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()

[Wang, Sunny (HPS SW)]

Looks good to me. This is clearer. 
Reviewed-by: Sunny Wang 

-Original Message-
From: Ruiyu Ni [mailto:ruiyu...@intel.com] 
Sent: Wednesday, July 04, 2018 9:51 AM
To: edk2-devel@lists.01.org
Cc: Sean Brogan ; Michael Turner 
; Wang, Sunny (HPS SW) 
Subject: [PATCH v4 9/9] MdeModulePkg/BdsDxe: Call 
PlatformBootManagerUnableToBoot()

When no boot option can be launched, BDS core calls
PlatformBootManagerUnableToBoot() to let platform BdsDxe handle it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Reviewed-by: Laszlo Ersek 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Sunny Wang 
---
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
index 39b643c77a..a25663ea43 100644
--- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -1043,6 +1043,7 @@ BdsEntry (
   }
 
   DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
+  PlatformBootManagerUnableToBoot ();
   CpuDeadLoop ();
 }
 
-- 
2.16.1.windows.1

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

Re: [edk2] [PATCH v4 8/9] MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"

[Wang, Sunny (HPS SW)]

Looks good to me. This is clearer. 
Reviewed-by: Sunny Wang 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Wednesday, July 04, 2018 9:51 AM
To: edk2-devel@lists.01.org
Cc: Eric Dong 
Subject: [edk2] [PATCH v4 8/9] MdeModulePkg/BdsDxe: Revert "fall back to UI 
loop before hanging"

Commit d1de487dd2e77f4741abcbd71d19a8c93971fda0
"MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before  hanging"
changed BDS core to fall back to UI loop when no bootable option can be 
launched.
Now since PlatformBootManagerUnableToBoot() is added, the commit can be 
reverted.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Eric Dong 
Reviewed-by: Laszlo Ersek 
---
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 60 +++-
 1 file changed, 4 insertions(+), 56 deletions(-)

diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
index 49e403e181..39b643c77a 100644
--- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -634,55 +634,6 @@ BdsFormalizeEfiGlobalVariable (
   BdsFormalizeOSIndicationVariable ();
 }
 
-/**
-  Enter an infinite loop of calling the Boot Manager Menu.
-
-  This is a last resort alternative to BdsEntry() giving up for good. This
-  function never returns.
-
-  @param[in] BootManagerMenu  The EFI_BOOT_MANAGER_LOAD_OPTION located and/or
-  created by the EfiBootManagerGetBootManagerMenu()
-  call in BdsEntry().
-**/
-VOID
-BdsBootManagerMenuLoop (
-  IN EFI_BOOT_MANAGER_LOAD_OPTION *BootManagerMenu
-  )
-{
-  EFI_INPUT_KEY Key;
-
-  //
-  // Normally BdsDxe does not print anything to the system console, but this is
-  // a last resort -- the end-user will likely not see any DEBUG messages
-  // logged in this situation.
-  //
-  // AsciiPrint() will NULL-check gST->ConOut internally. We check gST->ConIn
-  // here to see if it makes sense to request and wait for a keypress.
-  //
-  if (gST->ConIn != NULL) {
-AsciiPrint (
-  "%a: No bootable option or device was found.\n"
-  "%a: Press any key to enter the Boot Manager Menu.\n",
-  gEfiCallerBaseName,
-  gEfiCallerBaseName
-  );
-BdsWaitForSingleEvent (gST->ConIn->WaitForKey, 0);
-
-//
-// Drain any queued keys.
-//
-while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
-  //
-  // just throw away Key
-  //
-}
-  }
-
-  for (;;) {
-EfiBootManagerBoot (BootManagerMenu);
-  }
-}
-
 /**
 
   Service routine for BdsInstance->Entry(). Devices are connected, the @@ 
-1081,19 +1032,16 @@ BdsEntry (
 } while (BootSuccess);
   }
 
+  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
+EfiBootManagerFreeLoadOption ();  }
+
   if (!BootSuccess) {
 LoadOptions = EfiBootManagerGetLoadOptions (, 
LoadOptionTypePlatformRecovery);
 ProcessLoadOptions (LoadOptions, LoadOptionCount);
 EfiBootManagerFreeLoadOptions (LoadOptions, LoadOptionCount);
   }
 
-  //
-  // If BootManagerMenu is available, fall back to it indefinitely.
-  //
-  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
-BdsBootManagerMenuLoop ();
-  }
-
   DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
   CpuDeadLoop ();
 }
--
2.16.1.windows.1

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

Re: [edk2] report an issue about edk2 iscsi

[Ye, Ting]

Hi Robin,

Since you configured the attempt as following:

   Set: Connection retry count: 5, connection establishing timeout to [5000]


iSCSI driver will try to connect to iSCSI target in 6 times, each time it uses 
5 seconds as the timeout value.
So you need hold > 30 seconds in your case.


Thanks,
Ting

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of xujiawu
Sent: Wednesday, July 4, 2018 10:25 AM
To: edk2-de...@ml01.01.org
Subject: [edk2] report an issue about edk2 iscsi

 

Hello, edk2-devel,

I want to report a issue about edk2 iscsi:

Set timeout to 5S and copy a big file from iscsi HDD,  disconnect Lan cable
>>5S then connect again, the big file still copy successfully.

 

BIOS: the latest EDK2

 

Test steps:

1.Power on and press Hotkey to bios setup, in Advanced menu->iscsi
configuration->mac address.

2.ISCSI initiator name: iqn.

3. Add an attempt: 

   set: iscsi attempt name: 1

   set: iscsi mode: enable/enable for mpio, internet protocol ipv4

   Set: Connection retry count: 5, connection establishing timeout to [5000]

   Set: enable DHCP, enable get target info via DHCP

   Set: authentication type: none

4. Saved and exit, reboot.

5. Boot to shell, type: fs2:(ISCSI HDD).

6. Plug USB 3.0 flash disk to board.

7. Copy a big file from ISCSI HDD to usb.

8. Plug out LAN cable and hold some time( >> timeout time 5s), then plug in 
again.

 

Actual result:

The copy file still can successful with ISCSI after timeout.

 

Expected result:

The copy file is copied fail with iSCSI after timeout.

 

 

Thanks,

Robin

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

Re: [edk2] [PATCH v2] MdePkg/BaseLib: Add bit field population calculating methods

[Gao, Liming]

Tom:
  There are two issues here. 
1) BitFieldHammingWeight32 should be replaced by BitFieldCountOnes32. 
2) edk2 coding style requires the local variable is declared first, then assign 
the value to it. Don't assign the value in its declaration. 

Thanks
Liming
>-Original Message-
>From: Tomas Pilar (tpilar) [mailto:tpi...@solarflare.com]
>Sent: Tuesday, July 03, 2018 10:50 PM
>To: edk2-devel@lists.01.org
>Cc: Kinney, Michael D ; Gao, Liming
>
>Subject: [PATCH v2] MdePkg/BaseLib: Add bit field population calculating
>methods
>
>Add 32-bit and 64-bit functions that count number of set bits in a bit field
>using a divide-and-count method.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Tomas Pilar 
>Cc: Liming Gao 
>Cc: Michael D Kinney 
>---
> MdePkg/Include/Library/BaseLib.h  | 56 +++
> MdePkg/Library/BaseLib/BitField.c | 79
>+++
> 2 files changed, 135 insertions(+)
>
>diff --git a/MdePkg/Include/Library/BaseLib.h
>b/MdePkg/Include/Library/BaseLib.h
>index 1db3a04..123ae19 100644
>--- a/MdePkg/Include/Library/BaseLib.h
>+++ b/MdePkg/Include/Library/BaseLib.h
>@@ -4609,6 +4609,62 @@ BitFieldAndThenOr64 (
>   IN  UINT64OrData
>   );
>
>+/**
>+  Reads a bit field from a 32-bit value, counts and returns
>+  the number of set bits.
>+
>+  Counts the number of set bits in the  bit field specified by
>+  StartBit and EndBit in Operand. The count is returned.
>+
>+  If StartBit is greater than 31, then ASSERT().
>+  If EndBit is greater than 31, then ASSERT().
>+  If EndBit is less than StartBit, then ASSERT().
>+
>+  @param  Operand   Operand on which to perform the bitfield operation.
>+  @param  StartBit  The ordinal of the least significant bit in the bit field.
>+Range 0..31.
>+  @param  EndBitThe ordinal of the most significant bit in the bit field.
>+Range 0..31.
>+
>+  @return The number of bits set between StartBit and EndBit.
>+
>+**/
>+UINT8
>+EFIAPI
>+BitFieldCountOnes32 (
>+  IN   UINT32   Operand,
>+  IN   UINTNStartBit,
>+  IN   UINTNEndBit
>+  );
>+
>+/**
>+   Reads a bit field from a 64-bit value, counts and returns
>+   the number of set bits.
>+
>+   Counts the number of set bits in the  bit field specified by
>+   StartBit and EndBit in Operand. The count is returned.
>+
>+   If StartBit is greater than 63, then ASSERT().
>+   If EndBit is greater than 63, then ASSERT().
>+   If EndBit is less than StartBit, then ASSERT().
>+
>+   @param  Operand   Operand on which to perform the bitfield operation.
>+   @param  StartBit  The ordinal of the least significant bit in the bit 
>field.
>+   Range 0..63.
>+   @param  EndBitThe ordinal of the most significant bit in the bit field.
>+   Range 0..63.
>+
>+   @return The number of bits set between StartBit and EndBit.
>+
>+**/
>+UINT8
>+EFIAPI
>+BitFieldCountOnes64 (
>+  IN   UINT64   Operand,
>+  IN   UINTNStartBit,
>+  IN   UINTNEndBit
>+  );
>+
> //
> // Base Library Checksum Functions
> //
>diff --git a/MdePkg/Library/BaseLib/BitField.c
>b/MdePkg/Library/BaseLib/BitField.c
>index d2d3150..56b8eb2 100644
>--- a/MdePkg/Library/BaseLib/BitField.c
>+++ b/MdePkg/Library/BaseLib/BitField.c
>@@ -920,3 +920,82 @@ BitFieldAndThenOr64 (
>OrData
>);
> }
>+
>+/**
>+  Reads a bit field from a 32-bit value, counts and returns
>+  the number of set bits.
>+
>+  Counts the number of set bits in the  bit field specified by
>+  StartBit and EndBit in Operand. The count is returned.
>+
>+  If StartBit is greater than 31, then ASSERT().
>+  If EndBit is greater than 31, then ASSERT().
>+  If EndBit is less than StartBit, then ASSERT().
>+
>+  @param  Operand   Operand on which to perform the bitfield operation.
>+  @param  StartBit  The ordinal of the least significant bit in the bit field.
>+Range 0..31.
>+  @param  EndBitThe ordinal of the most significant bit in the bit field.
>+Range 0..31.
>+
>+  @return The number of bits set between StartBit and EndBit.
>+
>+**/
>+UINT8
>+EFIAPI
>+BitFieldCountOnes32 (
>+  IN   UINT32   Operand,
>+  IN   UINTNStartBit,
>+  IN   UINTNEndBit
>+  )
>+{
>+  ASSERT (EndBit < 32);
>+  ASSERT (StartBit <= EndBit);
>+
>+  UINT32 Count = BitFieldRead32 (Operand, StartBit, EndBit);
>+  Count -= ((Count >> 1) & 0x);
>+  Count = (Count & 0x) + ((Count >> 2) & 0x);
>+  Count += Count >> 4;
>+  Count &= 0x0F0F0F0F;
>+  Count += Count >> 8;
>+  Count += Count >> 16;
>+
>+  return (UINT8) Count & 0x3F;
>+}
>+
>+/**
>+   Reads a bit field from a 64-bit value, counts and returns
>+   the number of set bits.
>+
>+   Counts the number of set bits in the  bit field specified by
>+   StartBit 

Re: [edk2] gRT->SetVariable ACCESS DENIED error

[Andrew Fish]

Toan,

gEfiGlobalVariableGuid means it is defined in section 3.3, Globally Defined 
Variables, in the UEFI Spec:
Identifies the level of hardware error record persistence support implemented 
by the platform. This variable is only modified by firmware and is read-only to 
the OS.

As you see it is defined as read only, so it is a special variable. Lets search 
the UDK2018 for it and look for it being special cased

/Volumes/Case/UDK2018(vUDK2018)>git grep EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME 
-- *.h
MdePkg/Include/Guid/GlobalVariable.h:121:#define 
EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAMEL"HwErrRecSupport"
/Volumes/Case/UDK2018(vUDK2018)>git grep EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME 
-- *.c
MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c:407:
EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME,
MdeModulePkg/Universal/BdsDxe/BdsEntry.c:48:  
EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME,
/Volumes/Case/UDK2018(vUDK2018)>git grep 'L"HwErrRecSupport"' -- *.c
IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:48:  L"HwErrRecSupport",
IntelFrameworkModulePkg/Universal/BdsDxe/HwErrRecSupport.c:37:// define 
same behavior between no value or 0 value for L"HwErrRecSupport".
IntelFrameworkModulePkg/Universal/BdsDxe/HwErrRecSupport.c:40:  
  L"HwErrRecSupport",
MdeModulePkg/Universal/BdsDxe/HwErrRecSupport.c:37:// define same behavior 
between no value or 0 value for L"HwErrRecSupport".
MdeModulePkg/Universal/BdsDxe/HwErrRecSupport.c:40:
L"HwErrRecSupport",

Yep looks like some locking happens in the BDS, so maybe you are writing after 
the lock event?

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L44

///
/// The read-only variables defined in UEFI Spec.
///
CHAR16  *mReadOnlyVariables[] = {
  EFI_PLATFORM_LANG_CODES_VARIABLE_NAME,
  EFI_LANG_CODES_VARIABLE_NAME,
  EFI_BOOT_OPTION_SUPPORT_VARIABLE_NAME,
  EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME,
  EFI_OS_INDICATIONS_SUPPORT_VARIABLE_NAME
  };


https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L754



  //
  // Mark the read-only variables if the Variable Lock protocol exists
  //
  Status = gBS->LocateProtocol (, NULL, (VOID 
**) );
  DEBUG ((EFI_D_INFO, "[BdsDxe] Locate Variable Lock protocol - %r\n", Status));
  if (!EFI_ERROR (Status)) {
for (Index = 0; Index < ARRAY_SIZE (mReadOnlyVariables); Index++) {
  Status = VariableLock->RequestToLock (VariableLock, 
mReadOnlyVariables[Index], );
  ASSERT_EFI_ERROR (Status);
}
  }


Maybe you missed it due the mixing of the #define and the architectural name 
from the UEFI Spec?

Thanks,

Andrew Fish

PS 

I really hate when folks take the architecturally defined strings in the 
gEfiGlobalVariableGuid name space and obfuscate them with #defines. Especially 
when it is not done in a non-consistent way. The #define solves nothing, and 
obfuscates reading the code. In general in the edk2 we follow the type system 
in the UEFI spec, and there is is only the Unicode string for variables, not a 
#define value. 

Lets be real if the UEFI spec ever changed the  L"HwErrRecSupport" it would 
have to be tied to spec version, so all the places that used that variable 
would need the spec revision check and the #define is still just obfuscation 
and the code is not constructed with a version check. 


> On Jul 3, 2018, at 6:21 PM, Toan Le manh  wrote:
> 
> Hi Andrew,
> 
> I'm trying to set some variables to NVRAM at the beginning of BDS phase.
> For example, this function returned EFI_ACCESS_DENIED
>Status = gRT->SetVariable (
>L"HwErrRecSupport",
>,
>EFI_VARIABLE_BOOTSERVICE_ACCESS |
> EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
>sizeof (UINT16),
>
>);
> 
> Thanks & BRs,
> Toan

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

[edk2] [Patch] BaseTools: enable FixedAtBuild (VOID*) PCD use in the [DEPEX] section

[Yonghong Zhu]

From: Yunhua Feng 

The PCD item used in INF [Depex] section must be defined as FixedAtBuild
type and VOID* datum type, and the size of the PCD must be 16 bytes.

Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=443
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng 
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py| 31 ---
 BaseTools/Source/Python/AutoGen/GenDepex.py   |  6 +
 BaseTools/Source/Python/Workspace/InfBuildData.py | 15 +++
 BaseTools/Source/Python/build/BuildReport.py  |  6 +
 4 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 6d76afd..7d4539e 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2745,10 +2745,14 @@ class ModuleAutoGen(AutoGen):
 ## Store the FixedAtBuild Pcds
 #  
 self._FixedAtBuildPcds = []
 self.ConstPcd  = {}
 
+##Store the VOID* type FixedAtBuild Pcds
+#
+self._FixedPcdVoidTypeDict = {}
+
 def __repr__(self):
 return "%s [%s]" % (self.MetaFile, self.Arch)
 
 # Get FixedAtBuild Pcds of this Module
 def _GetFixedAtBuildPcds(self):
@@ -2758,11 +2762,20 @@ class ModuleAutoGen(AutoGen):
 if Pcd.Type != TAB_PCDS_FIXED_AT_BUILD:
 continue
 if Pcd not in self._FixedAtBuildPcds:
 self._FixedAtBuildPcds.append(Pcd)
 
-return self._FixedAtBuildPcds
+return self._FixedAtBuildPcds
+
+def _GetFixedAtBuildVoidTypePcds(self):
+if self._FixedPcdVoidTypeDict:
+return self._FixedPcdVoidTypeDict
+for Pcd in self.ModulePcdList + self.LibraryPcdList:
+if Pcd.Type == TAB_PCDS_FIXED_AT_BUILD and Pcd.DatumType == 
TAB_VOID:
+if '{}.{}'.format(Pcd.TokenSpaceGuidCName, Pcd.TokenCName) not 
in self._FixedPcdVoidTypeDict:
+
self._FixedPcdVoidTypeDict['{}.{}'.format(Pcd.TokenSpaceGuidCName, 
Pcd.TokenCName)] = Pcd.DefaultValue
+return self._FixedPcdVoidTypeDict
 
 def _GetUniqueBaseName(self):
 BaseName = self.Name
 for Module in self.PlatformInfo.ModuleAutoGenList:
 if Module.MetaFile == self.MetaFile:
@@ -3029,11 +3042,11 @@ class ModuleAutoGen(AutoGen):
 self._DepexDict = {}
 if self.DxsFile or self.IsLibrary or 
TAB_DEPENDENCY_EXPRESSION_FILE in self.FileTypes:
 return self._DepexDict
 
 self._DepexDict[self.ModuleType] = []
-
+self._GetFixedAtBuildVoidTypePcds()
 for ModuleType in self._DepexDict:
 DepexList = self._DepexDict[ModuleType]
 #
 # Append depex from dependent libraries, if not "BEFORE", 
"AFTER" expresion
 #
@@ -3041,11 +3054,22 @@ class ModuleAutoGen(AutoGen):
 Inherited = False
 for D in M.Depex[self.Arch, ModuleType]:
 if DepexList != []:
 DepexList.append('AND')
 DepexList.append('(')
-DepexList.extend(D)
+#replace D with value if D is FixedAtBuild PCD
+NewList = []
+for item in D:
+if '.' not in item:
+NewList.append(item)
+else:
+if item not in self._FixedPcdVoidTypeDict:
+EdkLogger.error("build", FORMAT_INVALID, 
"{} used in [Depex] section should be FixedAtBuild type and VOID* datum type in 
the module or its dependent libraries.".format(item))
+else:
+Value = self._FixedPcdVoidTypeDict[item]
+NewList.append(Value)
+DepexList.extend(NewList)
 if DepexList[-1] == 'END':  # no need of a END at this 
time
 DepexList.pop()
 DepexList.append(')')
 Inherited = True
 if Inherited:
@@ -4409,10 +4433,11 @@ class ModuleAutoGen(AutoGen):
 BuildOptionIncPathList  = property(_GetBuildOptionIncPathList)
 BuildCommand= property(_GetBuildCommand)
 
 FixedAtBuildPcds = property(_GetFixedAtBuildPcds)
 UniqueBaseName  = property(_GetUniqueBaseName)
+FixedVoidTypePcds   = property(_GetFixedAtBuildVoidTypePcds)
 
 # This acts like the main() function for the script, unless it is 'import'ed 
into another script.
 if __name__ == '__main__':
 pass
 
diff --git 

Re: [edk2] [patch] MdeModulePkg/SmmCorePerformanceLib: Update mPerformanceLength

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Dandan Bi
>Sent: Monday, July 02, 2018 1:30 PM
>To: edk2-devel@lists.01.org
>Cc: Zeng, Star ; Gao, Liming 
>Subject: [edk2] [patch] MdeModulePkg/SmmCorePerformanceLib: Update
>mPerformanceLength
>
>In mSmmBootPerformanceTable there are two parts,
>one is the FPDT table header and the other is FPDT records.
>Currently:
>mPerformanceLength: The length of existing FPDT records.
>mMaxPerformanceLength: The maximum length allocated for
>mSmmBootPerformanceTable(including FPDT table header length
>and existing FPDT records length)
>But when compare mPerformanceLength with mMaxPerformanceLength
>to check whether need to allocate new buffer for new FPDT
>record, we miss to add mPerformanceLength with header length,
>which will cause pool allocation behavior is not correct.
>
>Now update the mPerformanceLength to fix this issue:
>updated mPerformanceLength = FPDT table header length
>+ existing FPDT records length.
>
>Cc: Liming Gao 
>Cc: Star Zeng 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Dandan Bi 
>---
> .../Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c | 8
>
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git
>a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceL
>ib.c
>b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceL
>ib.c
>index f18c3fb60d..e03d41ed37 100644
>---
>a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceL
>ib.c
>+++
>b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceL
>ib.c
>@@ -43,11 +43,11 @@ typedef struct {
> } HANDLE_GUID_MAP;
>
> HANDLE_GUID_MAP
>mCacheHandleGuidTable[CACHE_HANDLE_GUID_COUNT];
> UINTNmCachePairCount = 0;
>
>-UINT32   mPerformanceLength= 0;
>+UINT32   mPerformanceLength= sizeof
>(SMM_BOOT_PERFORMANCE_TABLE);
> UINT32   mMaxPerformanceLength = 0;
> UINT32   mLoadImageCount   = 0;
> BOOLEAN  mFpdtDataIsReported   = FALSE;
> BOOLEAN  mLackSpaceIsReport= FALSE;
> CHAR8*mPlatformLanguage= NULL;
>@@ -98,19 +98,19 @@ GetFpdtRecordPtr (
> // Check if pre-allocated buffer is full
> //
> if (mPerformanceLength + RecordSize > mMaxPerformanceLength) {
>   mSmmBootPerformanceTable = ReallocatePool (
>mPerformanceLength,
>-   mPerformanceLength + sizeof
>(SMM_BOOT_PERFORMANCE_TABLE) + RecordSize +
>FIRMWARE_RECORD_BUFFER,
>+   mPerformanceLength + RecordSize +
>FIRMWARE_RECORD_BUFFER,
>mSmmBootPerformanceTable
>   );
>
>   if (mSmmBootPerformanceTable == NULL) {
> return EFI_OUT_OF_RESOURCES;
>   }
>-  mSmmBootPerformanceTable->Header.Length = sizeof
>(SMM_BOOT_PERFORMANCE_TABLE) + mPerformanceLength;
>-  mMaxPerformanceLength = mPerformanceLength + sizeof
>(SMM_BOOT_PERFORMANCE_TABLE) + RecordSize +
>FIRMWARE_RECORD_BUFFER;
>+  mSmmBootPerformanceTable->Header.Length = mPerformanceLength;
>+  mMaxPerformanceLength = mPerformanceLength + RecordSize +
>FIRMWARE_RECORD_BUFFER;
> }
> //
> // Covert buffer to FPDT Ptr Union type.
> //
> FpdtRecordPtr->RecordHeader =
>(EFI_ACPI_5_0_FPDT_PERFORMANCE_RECORD_HEADER
>*)((UINT8*)mSmmBootPerformanceTable + mSmmBootPerformanceTable-
>>Header.Length);
>--
>2.14.3.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: Avoid calling PEI services from AP

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Monday, July 2, 2018 2:02 PM
> To: edk2-devel@lists.01.org
> Cc: Jeff Fan ; Dong, Eric ;
> Yao, Jiewen ; Fish Andrew ; Laszlo
> Ersek 
> Subject: [PATCH] UefiCpuPkg/MpInitLib: Avoid calling PEI services from AP
> 
> Today's MpInitLib PEI implementation directly calls
> PeiServices->GetHobList() from AP which may cause racing issue.
> 
> This patch fixes this issue by duplicating IDT for APs.
> Because CpuMpData structure is stored just after IDT, the CpuMPData
> address equals to IDTR.BASE + IDTR.LIMIT + 1.
> 
> v2:
>   1. Add ALIGN_VALUE() on BufferSize.
>   2. Add ASSERT() to make sure no memory usage outside of the allocated
> buffer.
>   3. Add more comments in InitConfig path when restoring
> CpuData[0].VolatileRegisters.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jeff Fan 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Fish Andrew 
> Cc: Laszlo Ersek 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c| 59
> +++--
>  UefiCpuPkg/Library/MpInitLib/PeiMpLib.c | 18 +++---
>  2 files changed, 63 insertions(+), 14 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index eb2765910c..108eea0a6f 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -615,7 +615,9 @@ ApWakeupFunction (
>//
>ApInitializeSync (CpuMpData);
>//
> -  // Sync BSP's Control registers to APs
> +  // CpuMpData->CpuData[0].VolatileRegisters is initialized based on BSP
> environment,
> +  //   to initialize AP in InitConfig path.
> +  // NOTE: IDTR.BASE stored in CpuMpData->CpuData[0].VolatileRegisters
> points to a different IDT shared by all APs.
>//
>RestoreVolatileRegisters (>CpuData[0].VolatileRegisters,
> FALSE);
>InitializeApData (CpuMpData, ProcessorNumber, BistData, ApTopOfStack);
> @@ -1506,6 +1508,7 @@ MpInitLibInitialize (
>UINT32   MaxLogicalProcessorNumber;
>UINT32   ApStackSize;
>MP_ASSEMBLY_ADDRESS_MAP  AddressMap;
> +  CPU_VOLATILE_REGISTERS   VolatileRegisters;
>UINTNBufferSize;
>UINT32   MonitorFilterSize;
>VOID *MpBuffer;
> @@ -1516,6 +1519,7 @@ MpInitLibInitialize (
>UINTNIndex;
>UINTNApResetVectorSize;
>UINTNBackupBufferAddr;
> +  UINTNApIdtBase;
> 
>OldCpuMpData = GetCpuMpDataFromGuidedHob ();
>if (OldCpuMpData == NULL) {
> @@ -1530,19 +1534,48 @@ MpInitLibInitialize (
>ApStackSize = PcdGet32(PcdCpuApStackSize);
>ApLoopMode  = GetApLoopMode ();
> 
> +  //
> +  // Save BSP's Control registers for APs
> +  //
> +  SaveVolatileRegisters ();
> +
>BufferSize  = ApStackSize * MaxLogicalProcessorNumber;
>BufferSize += MonitorFilterSize * MaxLogicalProcessorNumber;
> -  BufferSize += sizeof (CPU_MP_DATA);
>BufferSize += ApResetVectorSize;
> +  BufferSize  = ALIGN_VALUE (BufferSize, 8);
> +  BufferSize += VolatileRegisters.Idtr.Limit + 1;
> +  BufferSize += sizeof (CPU_MP_DATA);
>BufferSize += (sizeof (CPU_AP_DATA) + sizeof (CPU_INFO_IN_HOB))*
> MaxLogicalProcessorNumber;
>MpBuffer= AllocatePages (EFI_SIZE_TO_PAGES (BufferSize));
>ASSERT (MpBuffer != NULL);
>ZeroMem (MpBuffer, BufferSize);
>Buffer = (UINTN) MpBuffer;
> 
> +  //
> +  //  The layout of the Buffer is as below:
> +  //
> +  //++ <-- Buffer
> +  //AP Stacks (N)
> +  //++ <-- MonitorBuffer
> +  //AP Monitor Filters (N)
> +  //++ <-- BackupBufferAddr (CpuMpData->BackupBuffer)
> +  // Backup Buffer
> +  //++
> +  //   Padding
> +  //++ <-- ApIdtBase (8-byte boundary)
> +  //   AP IDT  All APs share one separate IDT. So AP can get 
> address
> of CPU_MP_DATA from IDT Base.
> +  //++ <-- CpuMpData
> +  // CPU_MP_DATA
> +  //++ <-- CpuMpData->CpuData
> +  //CPU_AP_DATA (N)
> +  //++ <-- CpuMpData->CpuInfoInHob
> +  //  CPU_INFO_IN_HOB (N)
> +  //++
> +  //
>MonitorBuffer= (UINT8 *) (Buffer + ApStackSize *
> MaxLogicalProcessorNumber);
>BackupBufferAddr = (UINTN) MonitorBuffer + MonitorFilterSize *
> MaxLogicalProcessorNumber;
> -  CpuMpData = (CPU_MP_DATA *) (BackupBufferAddr + ApResetVectorSize);
> +  ApIdtBase= ALIGN_VALUE (BackupBufferAddr + ApResetVectorSize, 8);
> +  CpuMpData= (CPU_MP_DATA *) (ApIdtBase +
> VolatileRegisters.Idtr.Limit + 1);
>CpuMpData->Buffer   = Buffer;
>CpuMpData->CpuApStackSize   = ApStackSize;
>CpuMpData->BackupBuffer = BackupBufferAddr;
> @@ 

[edk2] report an issue about edk2 iscsi

[xujiawu]

 

Hello, edk2-devel,

I want to report a issue about edk2 iscsi:

Set timeout to 5S and copy a big file from iscsi HDD,  disconnect Lan cable
>>5S then connect again, the big file still copy successfully.

 

BIOS: the latest EDK2

 

Test steps:

1.Power on and press Hotkey to bios setup, in Advanced menu->iscsi
configuration->mac address.

2.ISCSI initiator name: iqn.

3. Add an attempt: 

   set: iscsi attempt name: 1

   set: iscsi mode: enable/enable for mpio, internet protocol ipv4

   Set: Connection retry count: 5, connection establishing timeout to [5000]

   Set: enable DHCP, enable get target info via DHCP

   Set: authentication type: none

4. Saved and exit, reboot.

5. Boot to shell, type: fs2:(ISCSI HDD).

6. Plug USB 3.0 flash disk to board.

7. Copy a big file from ISCSI HDD to usb.

8. Plug out LAN cable and hold some time( >> timeout time 5s), then plug in
again.

 

Actual result:

The copy file still can successful with ISCSI after timeout.

 

Expected result:

The copy file is copied fail with iSCSI after timeout.

 

 

Thanks,

Robin

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

Re: [edk2] [Patch v3] NetworkPkg/HttpDxe: Fix the bug when parsing HTTP(S) message body.

[Wu, Jiaxin]

Great, thanks the verification. /Jiaxin


> -Original Message-
> From: Gary Lin [mailto:g...@suse.com]
> Sent: Wednesday, July 4, 2018 10:14 AM
> To: Wu, Jiaxin 
> Cc: edk2-devel@lists.01.org; Ye, Ting ; Fu, Siyuan
> 
> Subject: Re: [edk2] [Patch v3] NetworkPkg/HttpDxe: Fix the bug when
> parsing HTTP(S) message body.
> 
> On Wed, Jul 04, 2018 at 08:40:52AM +0800, Jiaxin Wu wrote:
> > *v2: Resolve the conflict commit.
> >
> > *v3: Fixed the failure if BodyLength in HTTP token is less than the received
> > size of HTTPS message.
> >
> > HttpBodyParserCallback function is to parse the HTTP(S) message body so
> as to
> > confirm whether there is the next message header. But it doesn't record
> the
> > parsing message data/length correctly.
> >
> > This patch is refine the parsing logic so as to fix the potential failure.
> >
> > Cc: Ye Ting 
> > Cc: Fu Siyuan 
> > Cc: Gary Lin 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Wu Jiaxin 
> 
> > Tested-by: Gary Lin 
> Thanks for the patch. I've tested this patch with shim and grub2 from
> SLE15 GM, and they worked as expected. A crash in grub2 https connection is
> also gone after applying this patch.
> 
> Thanks,
> 
> Gary Lin
> 
> > ---
> >  NetworkPkg/HttpDxe/HttpImpl.c  | 112 +---
> -
> >  NetworkPkg/HttpDxe/HttpProto.c |  10 +++
> >  NetworkPkg/HttpDxe/HttpProto.h |  10 +++
> >  3 files changed, 78 insertions(+), 54 deletions(-)
> >
> > diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c
> > index f70e116f38..17deceb395 100644
> > --- a/NetworkPkg/HttpDxe/HttpImpl.c
> > +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> > @@ -914,10 +914,11 @@ HttpBodyParserCallback (
> >IN CHAR8  *Data,
> >IN UINTN  Length,
> >IN VOID   *Context
> >)
> >  {
> > +  HTTP_CALLBACK_DATA*CallbackData;
> >HTTP_TOKEN_WRAP   *Wrap;
> >UINTN BodyLength;
> >CHAR8 *Body;
> >
> >if (EventType != BodyParseEventOnComplete) {
> > @@ -926,25 +927,22 @@ HttpBodyParserCallback (
> >
> >if (Data == NULL || Length != 0 || Context == NULL) {
> >  return EFI_SUCCESS;
> >}
> >
> > -  Wrap = (HTTP_TOKEN_WRAP *) Context;
> > -  Body = Wrap->HttpToken->Message->Body;
> > -  BodyLength = Wrap->HttpToken->Message->BodyLength;
> > +  CallbackData = (HTTP_CALLBACK_DATA *) Context;
> > +
> > +  Wrap   = (HTTP_TOKEN_WRAP *) (CallbackData->Wrap);
> > +  Body   = CallbackData->ParseData;
> > +  BodyLength = CallbackData->ParseDataLength;
> > +
> >if (Data < Body + BodyLength) {
> >  Wrap->HttpInstance->NextMsg = Data;
> >} else {
> >  Wrap->HttpInstance->NextMsg = NULL;
> >}
> >
> > -
> > -  //
> > -  // Free Tx4Token or Tx6Token since already received corrsponding HTTP
> response.
> > -  //
> > -  FreePool (Wrap);
> > -
> >return EFI_SUCCESS;
> >  }
> >
> >  /**
> >The work function of EfiHttpResponse().
> > @@ -1189,33 +1187,43 @@ HttpResponseWorker (
> >   HttpInstance->Method,
> >   HttpMsg->Data.Response->StatusCode,
> >   HttpMsg->HeaderCount,
> >   HttpMsg->Headers,
> >   HttpBodyParserCallback,
> > - (VOID *) ValueInItem,
> > + (VOID *) (>CallbackData),
> >   >MsgParser
> >   );
> >if (EFI_ERROR (Status)) {
> >  goto Error2;
> >}
> >
> >//
> >// Check whether we received a complete HTTP message.
> >//
> >if (HttpInstance->CacheBody != NULL) {
> > +//
> > +// Record the CallbackData data.
> > +//
> > +HttpInstance->CallbackData.Wrap = (VOID *) Wrap;
> > +HttpInstance->CallbackData.ParseData = (VOID *) HttpInstance-
> >CacheBody;
> > +HttpInstance->CallbackData.ParseDataLength = HttpInstance-
> >CacheLen;
> > +
> > +//
> > +// Parse message with CallbackData data.
> > +//
> >  Status = HttpParseMessageBody (HttpInstance->MsgParser,
> HttpInstance->CacheLen, HttpInstance->CacheBody);
> >  if (EFI_ERROR (Status)) {
> >goto Error2;
> >  }
> > +  }
> >
> > -if (HttpIsMessageComplete (HttpInstance->MsgParser)) {
> > -  //
> > -  // Free the MsgParse since we already have a full HTTP message.
> > -  //
> > -  HttpFreeMsgParser (HttpInstance->MsgParser);
> > -  HttpInstance->MsgParser = NULL;
> > -}
> > +  if (HttpIsMessageComplete (HttpInstance->MsgParser)) {
> > +//
> > +// Free the MsgParse since we already have a full HTTP message.
> > +//
> > +HttpFreeMsgParser (HttpInstance->MsgParser);
> > +HttpInstance->MsgParser = NULL;
> >}
> >  }
> >
> >  if ((HttpMsg->Body == NULL) || (HttpMsg->BodyLength 

Re: [edk2] [Patch v3] NetworkPkg/HttpDxe: Fix the bug when parsing HTTP(S) message body.

[Gary Lin]

On Wed, Jul 04, 2018 at 08:40:52AM +0800, Jiaxin Wu wrote:
> *v2: Resolve the conflict commit.
> 
> *v3: Fixed the failure if BodyLength in HTTP token is less than the received
> size of HTTPS message.
> 
> HttpBodyParserCallback function is to parse the HTTP(S) message body so as to
> confirm whether there is the next message header. But it doesn't record the
> parsing message data/length correctly.
> 
> This patch is refine the parsing logic so as to fix the potential failure.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Gary Lin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wu Jiaxin 

> Tested-by: Gary Lin 
Thanks for the patch. I've tested this patch with shim and grub2 from
SLE15 GM, and they worked as expected. A crash in grub2 https connection is
also gone after applying this patch.

Thanks,

Gary Lin

> ---
>  NetworkPkg/HttpDxe/HttpImpl.c  | 112 +
>  NetworkPkg/HttpDxe/HttpProto.c |  10 +++
>  NetworkPkg/HttpDxe/HttpProto.h |  10 +++
>  3 files changed, 78 insertions(+), 54 deletions(-)
> 
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
> index f70e116f38..17deceb395 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -914,10 +914,11 @@ HttpBodyParserCallback (
>IN CHAR8  *Data,
>IN UINTN  Length,
>IN VOID   *Context
>)
>  {
> +  HTTP_CALLBACK_DATA*CallbackData;
>HTTP_TOKEN_WRAP   *Wrap;
>UINTN BodyLength;
>CHAR8 *Body;
>  
>if (EventType != BodyParseEventOnComplete) {
> @@ -926,25 +927,22 @@ HttpBodyParserCallback (
>  
>if (Data == NULL || Length != 0 || Context == NULL) {
>  return EFI_SUCCESS;
>}
>  
> -  Wrap = (HTTP_TOKEN_WRAP *) Context;
> -  Body = Wrap->HttpToken->Message->Body;
> -  BodyLength = Wrap->HttpToken->Message->BodyLength;
> +  CallbackData = (HTTP_CALLBACK_DATA *) Context;
> +
> +  Wrap   = (HTTP_TOKEN_WRAP *) (CallbackData->Wrap);
> +  Body   = CallbackData->ParseData;
> +  BodyLength = CallbackData->ParseDataLength;
> +
>if (Data < Body + BodyLength) {
>  Wrap->HttpInstance->NextMsg = Data;
>} else {
>  Wrap->HttpInstance->NextMsg = NULL;
>}
>  
> -
> -  //
> -  // Free Tx4Token or Tx6Token since already received corrsponding HTTP 
> response.
> -  //
> -  FreePool (Wrap);
> -
>return EFI_SUCCESS;
>  }
>  
>  /**
>The work function of EfiHttpResponse().
> @@ -1189,33 +1187,43 @@ HttpResponseWorker (
>   HttpInstance->Method,
>   HttpMsg->Data.Response->StatusCode,
>   HttpMsg->HeaderCount,
>   HttpMsg->Headers,
>   HttpBodyParserCallback,
> - (VOID *) ValueInItem,
> + (VOID *) (>CallbackData),
>   >MsgParser
>   );
>if (EFI_ERROR (Status)) {
>  goto Error2;
>}
>  
>//
>// Check whether we received a complete HTTP message.
>//
>if (HttpInstance->CacheBody != NULL) {
> +//
> +// Record the CallbackData data.
> +//
> +HttpInstance->CallbackData.Wrap = (VOID *) Wrap;
> +HttpInstance->CallbackData.ParseData = (VOID *) 
> HttpInstance->CacheBody;
> +HttpInstance->CallbackData.ParseDataLength = HttpInstance->CacheLen;
> +
> +//
> +// Parse message with CallbackData data.
> +//
>  Status = HttpParseMessageBody (HttpInstance->MsgParser, 
> HttpInstance->CacheLen, HttpInstance->CacheBody);
>  if (EFI_ERROR (Status)) {
>goto Error2;
>  }
> +  }
>  
> -if (HttpIsMessageComplete (HttpInstance->MsgParser)) {
> -  //
> -  // Free the MsgParse since we already have a full HTTP message.
> -  //
> -  HttpFreeMsgParser (HttpInstance->MsgParser);
> -  HttpInstance->MsgParser = NULL;
> -}
> +  if (HttpIsMessageComplete (HttpInstance->MsgParser)) {
> +//
> +// Free the MsgParse since we already have a full HTTP message.
> +//
> +HttpFreeMsgParser (HttpInstance->MsgParser);
> +HttpInstance->MsgParser = NULL;
>}
>  }
>  
>  if ((HttpMsg->Body == NULL) || (HttpMsg->BodyLength == 0)) {
>Status = EFI_SUCCESS;
> @@ -1330,16 +1338,30 @@ HttpResponseWorker (
>  if (EFI_ERROR (Status)) {
>goto Error2;
>  }
>  
>  //
> -// Check whether we receive a complete HTTP message.
> +// Process the received the body packet.
> +//
> +HttpMsg->BodyLength = MIN (Fragment.Len, (UINT32) HttpMsg->BodyLength);
> +
> +CopyMem (HttpMsg->Body, Fragment.Bulk, HttpMsg->BodyLength);
> +
> +//
> +// Record the CallbackData data.
> +//
> +HttpInstance->CallbackData.Wrap = (VOID *) Wrap;
> +

Re: [edk2] reg: IP6 based Static IP Configuration in ISCSI

[Ye, Ting]

Hi Siva,

We don't have such plan as I known. For IPv6, we leave it to IP6 driver to 
perform source address selection to best match the iSCSI target address.
You could use ifconfig6 to set static IP6 address before you configure iSCSI.

Thanks,
Ting



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Sivaraman Nainar
Sent: Tuesday, July 3, 2018 6:44 PM
To: edk2-devel@lists.01.org
Subject: [edk2] reg: IP6 based Static IP Configuration in ISCSI

Hello,

At present in the ISCSI configuration we are able to specify the Static IP 
configuration for IP4 protocol. Is there any plan to support IP6 static IP 
configuration in ISCSI Configuration?

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

[edk2] [PATCH v2 1/1] MdeModulePkg/Variable: Check EFI_MEMORY_RUNTIME attribute before setting it

[Brijesh Singh]

Set the EFI_MEMORY_RUNTIME attribute in FtwNotificationEvent() only if
the attribute is not already present. This will ensure that the attributes
set by the platform drivers (e.g Ovmf pflash) is not lost.

Cc: Dong Eric 
Cc: Justen Jordan L 
Cc: Zeng Star 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Reviewed-by: Star Zeng 
Signed-off-by: Brijesh Singh 
---

Change since v1:
 - fix coding style

 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
index 6b04f4f7b394..23186176be75 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
@@ -412,13 +412,15 @@ FtwNotificationEvent (
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_WARN, "Variable driver failed to get flash memory 
attribute.\n"));
   } else {
-Status = gDS->SetMemorySpaceAttributes (
-BaseAddress,
-Length,
-GcdDescriptor.Attributes | EFI_MEMORY_RUNTIME
-);
-if (EFI_ERROR (Status)) {
-  DEBUG ((DEBUG_WARN, "Variable driver failed to add EFI_MEMORY_RUNTIME 
attribute to Flash.\n"));
+if ((GcdDescriptor.Attributes & EFI_MEMORY_RUNTIME) == 0) {
+  Status = gDS->SetMemorySpaceAttributes (
+  BaseAddress,
+  Length,
+  GcdDescriptor.Attributes | EFI_MEMORY_RUNTIME
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_WARN, "Variable driver failed to add EFI_MEMORY_RUNTIME 
attribute to Flash.\n"));
+  }
 }
   }
 
-- 
2.7.4

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

Re: [edk2] [PATCH v4 0/9] Add platform hook for ultimate boot failure.

[Ni, Ruiyu]

On 7/4/2018 9:50 AM, Ruiyu Ni wrote:

v4:
   1. adds missing PlatformBootManagerLib instances modification for
  platform ArmPkg and ArmVirtPkg.
   2. Remove single quote in #1/9
   3. Wrap the long comments in #3/9

Ruiyu Ni (9):
   MdeModulePkg/PlatformBootManager: Add PlatformBootManagerUnableToBoot
   CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot
   OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot
   Nt32Pkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
   QuarkPlatform/PlatformBDS: Implement PlatformBootManagerUnableToBoot
   ArmPkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
   ArmVirtPkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
   MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"
   MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()

  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 18 ++-
  .../Library/PlatformBootManagerLib/PlatformBm.c| 62 +-
  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
  .../Include/Library/PlatformBootManagerLib.h   | 13 +
  .../PlatformBootManager.c  | 19 ++-
  MdeModulePkg/Universal/BdsDxe/BdsEntry.c   | 61 ++---
  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
  .../Library/PlatformBootManagerLib/BdsPlatform.c   | 61 -
  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
  9 files changed, 228 insertions(+), 63 deletions(-)


I will take leave for 1.5 weeks and will not be back until next.next Monday.
Because there are still some internal platform codes that need 
PlatformBootManagerLib modifications which I will make after I am back, 
the open source check-ins will be deferred after the internal 
modification is done.


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

[edk2] [PATCH v4 8/9] MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"

[Ruiyu Ni]

Commit d1de487dd2e77f4741abcbd71d19a8c93971fda0
"MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before
 hanging"
changed BDS core to fall back to UI loop when no bootable option
can be launched.
Now since PlatformBootManagerUnableToBoot() is added, the commit
can be reverted.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Eric Dong 
Reviewed-by: Laszlo Ersek 
---
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 60 +++-
 1 file changed, 4 insertions(+), 56 deletions(-)

diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
index 49e403e181..39b643c77a 100644
--- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -634,55 +634,6 @@ BdsFormalizeEfiGlobalVariable (
   BdsFormalizeOSIndicationVariable ();
 }
 
-/**
-  Enter an infinite loop of calling the Boot Manager Menu.
-
-  This is a last resort alternative to BdsEntry() giving up for good. This
-  function never returns.
-
-  @param[in] BootManagerMenu  The EFI_BOOT_MANAGER_LOAD_OPTION located and/or
-  created by the EfiBootManagerGetBootManagerMenu()
-  call in BdsEntry().
-**/
-VOID
-BdsBootManagerMenuLoop (
-  IN EFI_BOOT_MANAGER_LOAD_OPTION *BootManagerMenu
-  )
-{
-  EFI_INPUT_KEY Key;
-
-  //
-  // Normally BdsDxe does not print anything to the system console, but this is
-  // a last resort -- the end-user will likely not see any DEBUG messages
-  // logged in this situation.
-  //
-  // AsciiPrint() will NULL-check gST->ConOut internally. We check gST->ConIn
-  // here to see if it makes sense to request and wait for a keypress.
-  //
-  if (gST->ConIn != NULL) {
-AsciiPrint (
-  "%a: No bootable option or device was found.\n"
-  "%a: Press any key to enter the Boot Manager Menu.\n",
-  gEfiCallerBaseName,
-  gEfiCallerBaseName
-  );
-BdsWaitForSingleEvent (gST->ConIn->WaitForKey, 0);
-
-//
-// Drain any queued keys.
-//
-while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
-  //
-  // just throw away Key
-  //
-}
-  }
-
-  for (;;) {
-EfiBootManagerBoot (BootManagerMenu);
-  }
-}
-
 /**
 
   Service routine for BdsInstance->Entry(). Devices are connected, the
@@ -1081,19 +1032,16 @@ BdsEntry (
 } while (BootSuccess);
   }
 
+  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
+EfiBootManagerFreeLoadOption ();
+  }
+
   if (!BootSuccess) {
 LoadOptions = EfiBootManagerGetLoadOptions (, 
LoadOptionTypePlatformRecovery);
 ProcessLoadOptions (LoadOptions, LoadOptionCount);
 EfiBootManagerFreeLoadOptions (LoadOptions, LoadOptionCount);
   }
 
-  //
-  // If BootManagerMenu is available, fall back to it indefinitely.
-  //
-  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
-BdsBootManagerMenuLoop ();
-  }
-
   DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
   CpuDeadLoop ();
 }
-- 
2.16.1.windows.1

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

[edk2] [PATCH v4 9/9] MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()

[Ruiyu Ni]

When no boot option can be launched, BDS core calls
PlatformBootManagerUnableToBoot() to let platform BdsDxe handle it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Reviewed-by: Laszlo Ersek 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Sunny Wang 
---
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
index 39b643c77a..a25663ea43 100644
--- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -1043,6 +1043,7 @@ BdsEntry (
   }
 
   DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
+  PlatformBootManagerUnableToBoot ();
   CpuDeadLoop ();
 }
 
-- 
2.16.1.windows.1

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

[edk2] [PATCH v4 6/9] ArmPkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 079f1552d5..f9c71d430c 100644
--- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -3,7 +3,7 @@
 
   Copyright (C) 2015-2016, Red Hat, Inc.
   Copyright (c) 2014, ARM Ltd. All rights reserved.
-  Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
   Copyright (c) 2016, Linaro Ltd. All rights reserved.
 
   This program and the accompanying materials are licensed and made available
@@ -766,3 +766,19 @@ PlatformBootManagerWaitCallback (
 Print (L".");
   }
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  return;
+}
-- 
2.16.1.windows.1

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

[edk2] [PATCH v4 7/9] ArmVirtPkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Julien Grall 
---
 .../Library/PlatformBootManagerLib/PlatformBm.c| 62 +-
 1 file changed, 61 insertions(+), 1 deletion(-)

diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 62cce6a01e..bb07f5e22b 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -3,7 +3,7 @@
 
   Copyright (C) 2015-2016, Red Hat, Inc.
   Copyright (c) 2014, ARM Ltd. All rights reserved.
-  Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -865,3 +865,63 @@ PlatformBootManagerWaitCallback (
 0
 );
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  EFI_STATUS   Status;
+  EFI_INPUT_KEYKey;
+  EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
+  UINTNIndex;
+
+  //
+  // BootManagerMenu doesn't contain the correct information when return status
+  // is EFI_NOT_FOUND.
+  //
+  Status = EfiBootManagerGetBootManagerMenu ();
+  if (EFI_ERROR (Status)) {
+return;
+  }
+  //
+  // Normally BdsDxe does not print anything to the system console, but this is
+  // a last resort -- the end-user will likely not see any DEBUG messages
+  // logged in this situation.
+  //
+  // AsciiPrint() will NULL-check gST->ConOut internally. We check gST->ConIn
+  // here to see if it makes sense to request and wait for a keypress.
+  //
+  if (gST->ConIn != NULL) {
+AsciiPrint (
+  "%a: No bootable option or device was found.\n"
+  "%a: Press any key to enter the Boot Manager Menu.\n",
+  gEfiCallerBaseName,
+  gEfiCallerBaseName
+  );
+Status = gBS->WaitForEvent (1, >ConIn->WaitForKey, );
+ASSERT_EFI_ERROR (Status);
+ASSERT (Index == 0);
+
+//
+// Drain any queued keys.
+//
+while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
+  //
+  // just throw away Key
+  //
+}
+  }
+
+  for (;;) {
+EfiBootManagerBoot ();
+  }
+}
-- 
2.16.1.windows.1

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

[edk2] [PATCH v4 1/9] MdeModulePkg/PlatformBootManager: Add PlatformBootManagerUnableToBoot

[Ruiyu Ni]

The patch adds a new API PlatformBootManagerUnableToBoot()
to PlatformBootManagerLib.
The new API is provided by platform bds library and is called when
no boot option could be launched.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Sean Brogan 
Cc: Michael Turner 
Reviewed-by: Laszlo Ersek 
Cc: Sunny Wang 
---
 MdeModulePkg/Include/Library/PlatformBootManagerLib.h | 13 +
 .../PlatformBootManagerLibNull/PlatformBootManager.c  | 19 ++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Include/Library/PlatformBootManagerLib.h 
b/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
index 65630ce2bb..6e26329043 100644
--- a/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
+++ b/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
@@ -59,4 +59,17 @@ PlatformBootManagerWaitCallback (
   UINT16  TimeoutRemain
   );
 
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  );
+
 #endif
diff --git 
a/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c 
b/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
index 1390e19097..5a4455ef23 100644
--- a/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
+++ b/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
@@ -2,7 +2,7 @@
   This file include all platform action which can be customized
   by IBV/OEM.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -65,3 +65,20 @@ PlatformBootManagerWaitCallback (
 {
   return;
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  return;
+}
+
-- 
2.16.1.windows.1

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

[edk2] [PATCH v4 2/9] CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Maurice Ma 
Cc: Prince Agyeman 
Reviewed-by: Benjamin You 
---
 .../PlatformBootManagerLib/PlatformBootManager.c  | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git 
a/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c 
b/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index 7e92441da1..368e89d586 100644
--- a/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++ b/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
@@ -2,7 +2,7 @@
   This file include all platform action which can be customized
   by IBV/OEM.
 
-Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -252,3 +252,20 @@ PlatformBootManagerWaitCallback (
 {
   return;
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  return;
+}
+
-- 
2.16.1.windows.1

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

[edk2] [PATCH v4 4/9] Nt32Pkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Reviewed-by: Hao A Wu 
---
 .../PlatformBootManagerLib/PlatformBootManager.c  | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c 
b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index 99f30f9ec2..cf8289faff 100644
--- a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++ b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
@@ -2,7 +2,7 @@
   This file include all platform action which can be customized
   by IBV/OEM.
 
-Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -403,3 +403,20 @@ PlatformBootManagerWaitCallback (
 0
 );
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  return;
+}
+
-- 
2.16.1.windows.1

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

[edk2] [PATCH v4 5/9] QuarkPlatform/PlatformBDS: Implement PlatformBootManagerUnableToBoot

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Michael D Kinney 
Cc: Kelly Steele 
---
 .../PlatformBootManagerLib/PlatformBootManager.c  | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git 
a/QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c 
b/QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index 53391c6077..8b25f55f1c 100644
--- a/QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++ b/QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
@@ -2,7 +2,7 @@
 This file include all platform action which can be customized
 by IBV/OEM.
 
-Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -459,3 +459,20 @@ PlatformBootManagerWaitCallback (
 {
   Print (L"\r%-2d seconds remained...", TimeoutRemain);
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  return;
+}
+
-- 
2.16.1.windows.1

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

[edk2] [PATCH v4 0/9] Add platform hook for ultimate boot failure.

[Ruiyu Ni]

v4:
  1. adds missing PlatformBootManagerLib instances modification for
 platform ArmPkg and ArmVirtPkg.
  2. Remove single quote in #1/9
  3. Wrap the long comments in #3/9

Ruiyu Ni (9):
  MdeModulePkg/PlatformBootManager: Add PlatformBootManagerUnableToBoot
  CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot
  OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot
  Nt32Pkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
  QuarkPlatform/PlatformBDS: Implement PlatformBootManagerUnableToBoot
  ArmPkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
  ArmVirtPkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
  MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"
  MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()

 ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 18 ++-
 .../Library/PlatformBootManagerLib/PlatformBm.c| 62 +-
 .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
 .../Include/Library/PlatformBootManagerLib.h   | 13 +
 .../PlatformBootManager.c  | 19 ++-
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c   | 61 ++---
 .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
 .../Library/PlatformBootManagerLib/BdsPlatform.c   | 61 -
 .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
 9 files changed, 228 insertions(+), 63 deletions(-)

-- 
2.16.1.windows.1

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

Re: [edk2] [PATCH v3 0/7] Add platform hook for ultimate boot failure.

[Ni, Ruiyu]

On 7/4/2018 9:08 AM, Ni, Ruiyu wrote:




-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, July 3, 2018 11:53 PM
To: Ni, Ruiyu 
Cc: edk2-devel@lists.01.org; Leif Lindholm (Linaro address)
; Ard Biesheuvel ; Wei,
David ; Guo, Mang 
Subject: Re: [edk2] [PATCH v3 0/7] Add platform hook for ultimate boot failure.

Hi Ray,

On 07/03/18 08:37, Ruiyu Ni wrote:

Ruiyu Ni (7):
   MdeModulePkg/PlatformBootManager: Add

PlatformBootManagerUnableToBoot

   CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot
   OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot
   Nt32Pkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
   QuarkPlatform/PlatformBDS: Implement

PlatformBootManagerUnableToBoot

   MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"
   MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()

  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
  .../Include/Library/PlatformBootManagerLib.h   | 13 +
  .../PlatformBootManager.c  | 19 ++-
  MdeModulePkg/Universal/BdsDxe/BdsEntry.c   | 61 ++
  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
  .../Library/PlatformBootManagerLib/BdsPlatform.c   | 61

+-

  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
  7 files changed, 150 insertions(+), 61 deletions(-)



thanks a lot for this version as well!

It seems we have the following PlatformBootManagerLib instances in the
edk2 tree:

   ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf

CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerL
ib.inf

MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManagerLi
bNull.inf
   Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf

QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.i
nf
   Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformBdsLib.inf

This series updates all but ArmPkg, ArmVirtPkg and Vlv2TbltDevicePkg. So I think
three more patches would be necessary, before patch #6.

I tried to search all PlatformBootManagerAfterConsole() to locate all instances
of PlatformBootManagerLib.
Now it seems I still missed three.
I will make an updated patch and send V4.



Originally, with the registration pattern, I offered to port the OvmfPkg update 
to
ArmVirtPkg myself, later. However, with the present pattern, these three
platforms would stop building, so I think they should be updated before we
commit patches #6 and #7.

For ArmPkg and Vlv2TbltDevicePkg, I *think* the Null implementation ("do
nothing") is appropriate. (I'm CC'ing those package maintainers). For 
ArmVirtPkg,
duplicating the OvmfPkg approach would be correct.

Vlv2TbltDevicePkg is still using old IntelFrameworkModulePkg/BdsDxe.
So I will just update ArmPkg and ArmVirtPkg.



Can you take on updating these three platforms as well? Or can I help somehow
with it? (It's tricky because the three platform patches that I could post 
should
go in the middle of the series, neither before nor
after.)

Thank you!
Laszlo

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




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

Re: [edk2] [PATCH v3 3/7] OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot

[Ni, Ruiyu]

On 7/3/2018 11:37 PM, Laszlo Ersek wrote:

On 07/03/18 08:37, Ruiyu Ni wrote:

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
---
  .../Library/PlatformBootManagerLib/BdsPlatform.c   | 61 +-
  1 file changed, 60 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 57870cb856..e56ffc141a 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1,7 +1,7 @@
  /** @file
Platform BDS customizations.
  
-  Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.

+  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
distribution.  The full text of the license may be found at
@@ -1676,3 +1676,62 @@ PlatformBootManagerWaitCallback (
  );
  }
  
+/**

+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  EFI_STATUS   Status;
+  EFI_INPUT_KEYKey;
+  EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
+  UINTNIndex;
+
+  //
+  // BootManagerMenu doesn't contain the correct information when return 
status is EFI_NOT_FOUND.
+  //


Before you commit this patch, can you please rewrap this long comment, like 
this:

   //
   // BootManagerMenu doesn't contain the correct information when return status
   // is EFI_NOT_FOUND.
   //

Sure.



With that:

Reviewed-by: Laszlo Ersek 

Thank you!
Laszlo


+  Status = EfiBootManagerGetBootManagerMenu ();
+  if (EFI_ERROR (Status)) {
+return;
+  }
+  //
+  // Normally BdsDxe does not print anything to the system console, but this is
+  // a last resort -- the end-user will likely not see any DEBUG messages
+  // logged in this situation.
+  //
+  // AsciiPrint() will NULL-check gST->ConOut internally. We check gST->ConIn
+  // here to see if it makes sense to request and wait for a keypress.
+  //
+  if (gST->ConIn != NULL) {
+AsciiPrint (
+  "%a: No bootable option or device was found.\n"
+  "%a: Press any key to enter the Boot Manager Menu.\n",
+  gEfiCallerBaseName,
+  gEfiCallerBaseName
+  );
+Status = gBS->WaitForEvent (1, >ConIn->WaitForKey, );
+ASSERT_EFI_ERROR (Status);
+ASSERT (Index == 0);
+
+//
+// Drain any queued keys.
+//
+while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
+  //
+  // just throw away Key
+  //
+}
+  }
+
+  for (;;) {
+EfiBootManagerBoot ();
+  }
+}
+






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

Re: [edk2] gRT->SetVariable ACCESS DENIED error

[Toan Le manh]

Hi Andrew,

I'm trying to set some variables to NVRAM at the beginning of BDS phase.
For example, this function returned EFI_ACCESS_DENIED
Status = gRT->SetVariable (
L"HwErrRecSupport",
,
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
sizeof (UINT16),

);

Thanks & BRs,
Toan

On Wed, Jul 4, 2018 at 12:12 AM Andrew Fish  wrote:

> Toan,
>
> What arguments did you pass to gRT->SetVariable()?
>
> What implementation did you test on?
>
> In general there are "wiggle words" in the UEFI Spec that make it legal to
> return other error codes. Back in the day when NOR FLASH was expensive and
> EFI was size constrained we did not want to have to filter every return
> value from a lower level to convert it to a spec required return code.
>
> Thanks,
>
> Andrew Fish
>
> > On Jul 3, 2018, at 2:10 AM, Toan Le manh  wrote:
> >
> > Dear all,
> >
> > I'm facing the Status EFI_ACCESS_DENIED when using gRT->SetVariable()
> > method.
> > There is no description of this returned status for SetVariable()  in
> UEFI
> > spec.
> > Have you ever faced this type of error? Could you please give me any idea
> > on how this happen?
> > Sorry for any inconvenience, I'm newbie in EDK2.
> >
> > Thanks & Best Regards,
> > Toan
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 4/7] Nt32Pkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot

[Wu, Hao A]

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, July 03, 2018 2:38 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [PATCH v3 4/7] Nt32Pkg/PlatformBDS: Implement
> PlatformBootManagerUnableToBoot
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Hao A Wu 
> ---
>  .../PlatformBootManagerLib/PlatformBootManager.c  | 19
> ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
> b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
> index 99f30f9ec2..cf8289faff 100644
> --- a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
> +++ b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
> @@ -2,7 +2,7 @@
>This file include all platform action which can be customized
>by IBV/OEM.
> 
> -Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
> +Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
>  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
> @@ -403,3 +403,20 @@ PlatformBootManagerWaitCallback (
>  0
>  );
>  }
> +
> +/**
> +  The function is called when no boot option could be launched,
> +  including platform recovery options and options pointing to applications
> +  built into firmware volumes.
> +
> +  If this function returns, BDS attempts to enter an infinite loop.
> +**/
> +VOID
> +EFIAPI
> +PlatformBootManagerUnableToBoot (
> +  VOID
> +  )
> +{
> +  return;
> +}
> +
> --
> 2.16.1.windows.1

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

Re: [edk2] [PATCH v3 0/7] Add platform hook for ultimate boot failure.

[Ni, Ruiyu]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, July 3, 2018 11:53 PM
> To: Ni, Ruiyu 
> Cc: edk2-devel@lists.01.org; Leif Lindholm (Linaro address)
> ; Ard Biesheuvel ; Wei,
> David ; Guo, Mang 
> Subject: Re: [edk2] [PATCH v3 0/7] Add platform hook for ultimate boot 
> failure.
> 
> Hi Ray,
> 
> On 07/03/18 08:37, Ruiyu Ni wrote:
> > Ruiyu Ni (7):
> >   MdeModulePkg/PlatformBootManager: Add
> PlatformBootManagerUnableToBoot
> >   CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot
> >   OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot
> >   Nt32Pkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
> >   QuarkPlatform/PlatformBDS: Implement
> PlatformBootManagerUnableToBoot
> >   MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"
> >   MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()
> >
> >  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
> >  .../Include/Library/PlatformBootManagerLib.h   | 13 +
> >  .../PlatformBootManager.c  | 19 ++-
> >  MdeModulePkg/Universal/BdsDxe/BdsEntry.c   | 61 
> > ++
> >  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
> >  .../Library/PlatformBootManagerLib/BdsPlatform.c   | 61
> +-
> >  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
> >  7 files changed, 150 insertions(+), 61 deletions(-)
> >
> 
> thanks a lot for this version as well!
> 
> It seems we have the following PlatformBootManagerLib instances in the
> edk2 tree:
> 
>   ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>   ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> 
> CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerL
> ib.inf
> 
> MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManagerLi
> bNull.inf
>   Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>   OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> 
> QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.i
> nf
>   Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformBdsLib.inf
> 
> This series updates all but ArmPkg, ArmVirtPkg and Vlv2TbltDevicePkg. So I 
> think
> three more patches would be necessary, before patch #6.
I tried to search all PlatformBootManagerAfterConsole() to locate all instances
of PlatformBootManagerLib.
Now it seems I still missed three.
I will make an updated patch and send V4.

> 
> Originally, with the registration pattern, I offered to port the OvmfPkg 
> update to
> ArmVirtPkg myself, later. However, with the present pattern, these three
> platforms would stop building, so I think they should be updated before we
> commit patches #6 and #7.
> 
> For ArmPkg and Vlv2TbltDevicePkg, I *think* the Null implementation ("do
> nothing") is appropriate. (I'm CC'ing those package maintainers). For 
> ArmVirtPkg,
> duplicating the OvmfPkg approach would be correct.
> 
> Can you take on updating these three platforms as well? Or can I help somehow
> with it? (It's tricky because the three platform patches that I could post 
> should
> go in the middle of the series, neither before nor
> after.)
> 
> Thank you!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch v3] NetworkPkg/HttpDxe: Fix the bug when parsing HTTP(S) message body.

[Jiaxin Wu]

*v2: Resolve the conflict commit.

*v3: Fixed the failure if BodyLength in HTTP token is less than the received
size of HTTPS message.

HttpBodyParserCallback function is to parse the HTTP(S) message body so as to
confirm whether there is the next message header. But it doesn't record the
parsing message data/length correctly.

This patch is refine the parsing logic so as to fix the potential failure.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Gary Lin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Tested-by: Gary Lin 
---
 NetworkPkg/HttpDxe/HttpImpl.c  | 112 +
 NetworkPkg/HttpDxe/HttpProto.c |  10 +++
 NetworkPkg/HttpDxe/HttpProto.h |  10 +++
 3 files changed, 78 insertions(+), 54 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index f70e116f38..17deceb395 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -914,10 +914,11 @@ HttpBodyParserCallback (
   IN CHAR8  *Data,
   IN UINTN  Length,
   IN VOID   *Context
   )
 {
+  HTTP_CALLBACK_DATA*CallbackData;
   HTTP_TOKEN_WRAP   *Wrap;
   UINTN BodyLength;
   CHAR8 *Body;
 
   if (EventType != BodyParseEventOnComplete) {
@@ -926,25 +927,22 @@ HttpBodyParserCallback (
 
   if (Data == NULL || Length != 0 || Context == NULL) {
 return EFI_SUCCESS;
   }
 
-  Wrap = (HTTP_TOKEN_WRAP *) Context;
-  Body = Wrap->HttpToken->Message->Body;
-  BodyLength = Wrap->HttpToken->Message->BodyLength;
+  CallbackData = (HTTP_CALLBACK_DATA *) Context;
+
+  Wrap   = (HTTP_TOKEN_WRAP *) (CallbackData->Wrap);
+  Body   = CallbackData->ParseData;
+  BodyLength = CallbackData->ParseDataLength;
+
   if (Data < Body + BodyLength) {
 Wrap->HttpInstance->NextMsg = Data;
   } else {
 Wrap->HttpInstance->NextMsg = NULL;
   }
 
-
-  //
-  // Free Tx4Token or Tx6Token since already received corrsponding HTTP 
response.
-  //
-  FreePool (Wrap);
-
   return EFI_SUCCESS;
 }
 
 /**
   The work function of EfiHttpResponse().
@@ -1189,33 +1187,43 @@ HttpResponseWorker (
  HttpInstance->Method,
  HttpMsg->Data.Response->StatusCode,
  HttpMsg->HeaderCount,
  HttpMsg->Headers,
  HttpBodyParserCallback,
- (VOID *) ValueInItem,
+ (VOID *) (>CallbackData),
  >MsgParser
  );
   if (EFI_ERROR (Status)) {
 goto Error2;
   }
 
   //
   // Check whether we received a complete HTTP message.
   //
   if (HttpInstance->CacheBody != NULL) {
+//
+// Record the CallbackData data.
+//
+HttpInstance->CallbackData.Wrap = (VOID *) Wrap;
+HttpInstance->CallbackData.ParseData = (VOID *) 
HttpInstance->CacheBody;
+HttpInstance->CallbackData.ParseDataLength = HttpInstance->CacheLen;
+
+//
+// Parse message with CallbackData data.
+//
 Status = HttpParseMessageBody (HttpInstance->MsgParser, 
HttpInstance->CacheLen, HttpInstance->CacheBody);
 if (EFI_ERROR (Status)) {
   goto Error2;
 }
+  }
 
-if (HttpIsMessageComplete (HttpInstance->MsgParser)) {
-  //
-  // Free the MsgParse since we already have a full HTTP message.
-  //
-  HttpFreeMsgParser (HttpInstance->MsgParser);
-  HttpInstance->MsgParser = NULL;
-}
+  if (HttpIsMessageComplete (HttpInstance->MsgParser)) {
+//
+// Free the MsgParse since we already have a full HTTP message.
+//
+HttpFreeMsgParser (HttpInstance->MsgParser);
+HttpInstance->MsgParser = NULL;
   }
 }
 
 if ((HttpMsg->Body == NULL) || (HttpMsg->BodyLength == 0)) {
   Status = EFI_SUCCESS;
@@ -1330,16 +1338,30 @@ HttpResponseWorker (
 if (EFI_ERROR (Status)) {
   goto Error2;
 }
 
 //
-// Check whether we receive a complete HTTP message.
+// Process the received the body packet.
+//
+HttpMsg->BodyLength = MIN (Fragment.Len, (UINT32) HttpMsg->BodyLength);
+
+CopyMem (HttpMsg->Body, Fragment.Bulk, HttpMsg->BodyLength);
+
+//
+// Record the CallbackData data.
+//
+HttpInstance->CallbackData.Wrap = (VOID *) Wrap;
+HttpInstance->CallbackData.ParseData = HttpMsg->Body;
+HttpInstance->CallbackData.ParseDataLength = HttpMsg->BodyLength;
+
+//
+// Parse Body with CallbackData data.
 //
 Status = HttpParseMessageBody (
HttpInstance->MsgParser,
-   (UINTN) Fragment.Len,
-   (CHAR8 *) Fragment.Bulk
+   HttpMsg->BodyLength,
+   HttpMsg->Body
);
 if (EFI_ERROR (Status)) {
   goto Error2;
 }
 
@@ -1350,50 +1372,32 @@ HttpResponseWorker (
   HttpFreeMsgParser 

Re: [edk2] [patch V2 8/9] SecurityPkg: Use new added Perf macros

[Zhang, Chao B]

HI  Dandan :
   That patch is good to me. Reviewed-by: Chao Zhang 
-Original Message-
From: Bi, Dandan 
Sent: Friday, June 22, 2018 4:56 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhang, Chao B 
Subject: [patch V2 8/9] SecurityPkg: Use new added Perf macros

Replace old Perf macros with the new added ones.

Cc: Liming Gao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 .../DxeRsa2048Sha256GuidedSectionExtractLib.c| 16 
 .../PeiRsa2048Sha256GuidedSectionExtractLib.c| 16 
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git 
a/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
 
b/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
index 39768fbac22..d6f4207a506 100644
--- 
a/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
+++ b/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa
+++ 2048Sha256GuidedSectionExtractLib.c
@@ -161,13 +161,13 @@ Rsa2048Sha256GuidedSectionHandler (
 // Get the RSA 2048 SHA 256 information.
 //
 CertBlockRsa2048Sha256 = &((RSA_2048_SHA_256_SECTION2_HEADER *) 
InputSection)->CertBlockRsa2048Sha256;
 OutputBufferSize   = SECTION2_SIZE (InputSection) - sizeof 
(RSA_2048_SHA_256_SECTION2_HEADER);
 if EFI_GUID_DEFINED_SECTION *)InputSection)->Attributes & 
EFI_GUIDED_SECTION_PROCESSING_REQUIRED) != 0) {
-  PERF_START (NULL, "RsaCopy", "DXE", 0);
+  PERF_INMODULE_BEGIN ("DxeRsaCopy");
   CopyMem (*OutputBuffer, (UINT8 *)InputSection + sizeof 
(RSA_2048_SHA_256_SECTION2_HEADER), OutputBufferSize);
-  PERF_END (NULL, "RsaCopy", "DXE", 0);
+  PERF_INMODULE_END ("DxeRsaCopy");
 } else {
   *OutputBuffer = (UINT8 *)InputSection + sizeof 
(RSA_2048_SHA_256_SECTION2_HEADER);
 }
 
 //
@@ -189,13 +189,13 @@ Rsa2048Sha256GuidedSectionHandler (
 // Get the RSA 2048 SHA 256 information.
 //
 CertBlockRsa2048Sha256 = &((RSA_2048_SHA_256_SECTION_HEADER 
*)InputSection)->CertBlockRsa2048Sha256;
 OutputBufferSize   = SECTION_SIZE (InputSection) - sizeof 
(RSA_2048_SHA_256_SECTION_HEADER);
 if EFI_GUID_DEFINED_SECTION *)InputSection)->Attributes & 
EFI_GUIDED_SECTION_PROCESSING_REQUIRED) != 0) {
-  PERF_START (NULL, "RsaCopy", "DXE", 0);
+  PERF_INMODULE_BEGIN ("DxeRsaCopy");
   CopyMem (*OutputBuffer, (UINT8 *)InputSection + sizeof 
(RSA_2048_SHA_256_SECTION_HEADER), OutputBufferSize);
-  PERF_END (NULL, "RsaCopy", "DXE", 0);
+  PERF_INMODULE_END ("DxeRsaCopy");
 } else {
   *OutputBuffer = (UINT8 *)InputSection + sizeof 
(RSA_2048_SHA_256_SECTION_HEADER);
 }
 
 //
@@ -325,13 +325,13 @@ Rsa2048Sha256GuidedSectionHandler (
   if (!CryptoStatus) {
 DEBUG ((DEBUG_ERROR, "DxeRsa2048Sha256: Sha256Init() failed\n"));
 *AuthenticationStatus |= EFI_AUTH_STATUS_TEST_FAILED;
 goto Done;
   }
-  PERF_START (NULL, "RsaShaData", "DXE", 0);
+  PERF_INMODULE_BEGIN ("DxeRsaShaData");
   CryptoStatus = Sha256Update (HashContext, *OutputBuffer, OutputBufferSize);
-  PERF_END (NULL, "RsaShaData", "DXE", 0);
+  PERF_INMODULE_END ("DxeRsaShaData");
   if (!CryptoStatus) {
 DEBUG ((DEBUG_ERROR, "DxeRsa2048Sha256: Sha256Update() failed\n"));
 *AuthenticationStatus |= EFI_AUTH_STATUS_TEST_FAILED;
 goto Done;
   }
@@ -343,19 +343,19 @@ Rsa2048Sha256GuidedSectionHandler (
   }
 
   //
   // Verify the RSA 2048 SHA 256 signature.
   //
-  PERF_START (NULL, "RsaVerify", "DXE", 0);
+  PERF_INMODULE_BEGIN ("DxeRsaVerify");
   CryptoStatus = RsaPkcs1Verify (
Rsa, 
Digest, 
SHA256_DIGEST_SIZE, 
CertBlockRsa2048Sha256->Signature, 
sizeof (CertBlockRsa2048Sha256->Signature)
);
-  PERF_END (NULL, "RsaVerify", "DXE", 0);
+  PERF_INMODULE_END ("DxeRsaVerify");
   if (!CryptoStatus) {
 //
 // If RSA 2048 SHA 256 signature verification fails, AUTH tested failed 
bit is set.
 //
 DEBUG ((DEBUG_ERROR, "DxeRsa2048Sha256: RsaPkcs1Verify() failed\n")); diff 
--git 
a/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
 
b/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
index ba1c700ad03..2272308ddca 100644
--- 
a/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
+++ b/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa
+++ 2048Sha256GuidedSectionExtractLib.c
@@ -158,13 +158,13 @@ Rsa2048Sha256GuidedSectionHandler (
 // Get the RSA 2048 SHA 256 information.
 //
 CertBlockRsa2048Sha256 = &((RSA_2048_SHA_256_SECTION2_HEADER *) 
InputSection)->CertBlockRsa2048Sha256;
 

Re: [edk2] [Patch 2/2] SecurityPkg: Tpm2DeviceLib: Enable CapCRBIdleBypass support

[Zhang, Chao B]

Hi Gary:
   It is caused by code merge. Tks for notification. We have fixed it.

From: Gary Lin [mailto:g...@suse.com]
Sent: Wednesday, June 27, 2018 4:19 PM
To: Zhang, Chao B 
Cc: edk2-devel@lists.01.org; Yao, Jiewen ; Long, Qin 

Subject: Re: [edk2] [Patch 2/2] SecurityPkg: Tpm2DeviceLib: Enable 
CapCRBIdleBypass support

On Mon, Jun 25, 2018 at 12:44:21PM +0800, Zhang, Chao B wrote:
> Directly transition from CMD completion to CMD Ready state if device
> supports IdleByPass
>
> Cc: Long Qin mailto:qin.l...@intel.com>>
> Cc: Yao Jiewen mailto:jiewen@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chao Zhang 
> mailto:chao.b.zh...@intel.com>>
> Signed-off-by: Zhang, Chao B 
> mailto:chao.b.zh...@intel.com>>
> ---
>  .../Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.c  | 19 +
>  .../Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf|  1 +
>  .../Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c| 19 +
>  .../Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf  |  3 +-
>  SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c| 98 
> +++---
>  SecurityPkg/SecurityPkg.dec| 10 +++
>  SecurityPkg/SecurityPkg.uni| 10 ++-
>  7 files changed, 146 insertions(+), 14 deletions(-)
>
> diff --git a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.c 
> b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.c
> index 3feb64df7e..e6fe563b40 100644
> --- a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.c
> +++ b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.c
> @@ -29,10 +29,22 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  TPM2_PTP_INTERFACE_TYPE
>  Tpm2GetPtpInterface (
>IN VOID *Register
>);
>
> +/**
> +  Return PTP CRB interface IdleByPass state.
> +
> +  @param[in] RegisterPointer to PTP register.
> +
> +  @return PTP CRB interface IdleByPass state.
> +**/
> +UINT8
> +Tpm2GetIdleByPass (
> +  IN VOID *Register
> +  );
> +
>  /**
>This service enables the sending of commands to the TPM2.
>
>@param[in]  InputParameterBlockSize  Size of the TPM2 input parameter 
> block.
>@param[in]  InputParameterBlock  Pointer to the TPM2 input 
> parameter block.
> @@ -138,15 +150,22 @@ EFIAPI
>  Tpm2DeviceLibConstructor (
>VOID
>)
>  {
>TPM2_PTP_INTERFACE_TYPE  PtpInterface;
> +  UINT8IdleByPass;
>
>//
>// Cache current active TpmInterfaceType only when needed
>//
>if (PcdGet8(PcdActiveTpmInterfaceType) == 0xFF) {
>  PtpInterface = Tpm2GetPtpInterface ((VOID *) (UINTN) PcdGet64 
> (PcdTpmBaseAddress));
>  PcdSet8S(PcdActiveTpmInterfaceType, PtpInterface);
>}
> +
> +  if (PcdGet8(PcdActiveTpmInterfaceType) == PtpInterfaceCrb && 
> PcdGet8(PcdCRBIdleByPass) == 0xFF) {
I got a build error with PtpInterfaceCrb:

SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.c: In function 
‘Tpm2DeviceLibConstructor’:
SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.c:165:45: error: 
‘PtpInterfaceCrb’ undeclared (first use in this function); did you mean 
‘PtpInterface’?
   if (PcdGet8(PcdActiveTpmInterfaceType) == PtpInterfaceCrb && 
PcdGet8(PcdCRBIdleByPass) == 0xFF) {
 ^~~
 PtpInterface

I assume you mean Tpm2PtpInterfaceCrb?

Cheers,

Gary Lin

> +IdleByPass = Tpm2GetIdleByPass((VOID *) (UINTN) PcdGet64 
> (PcdTpmBaseAddress));
> +PcdSet8S(PcdCRBIdleByPass, IdleByPass);
> +  }
> +
>return EFI_SUCCESS;
>  }
> diff --git a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf 
> b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
> index 634bbae847..2e54a78cc0 100644
> --- a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
> +++ b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
> @@ -53,5 +53,6 @@
>PcdLib
>
>  [Pcd]
>gEfiSecurityPkgTokenSpaceGuid.PcdTpmBaseAddress## CONSUMES
>gEfiSecurityPkgTokenSpaceGuid.PcdActiveTpmInterfaceType## PRODUCES
> +  gEfiSecurityPkgTokenSpaceGuid.PcdCRBIdleByPass ## PRODUCES
> \ No newline at end of file
> diff --git a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c 
> b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c
> index 01f78bf0be..edcdb72a79 100644
> --- a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c
> +++ b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c
> @@ -32,10 +32,22 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  TPM2_PTP_INTERFACE_TYPE
>  Tpm2GetPtpInterface (
>IN VOID *Register
>);
>
> +/**
> +  Return PTP CRB interface IdleByPass state.
> +
> +  @param[in] RegisterPointer to PTP register.
> +
> +  @return PTP CRB interface IdleByPass state.
> +**/
> +UINT8
> +Tpm2GetIdleByPass (
> +  IN VOID *Register
> +  );
> +
>  /**

Re: [edk2] [PATCH v3 2/7] CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot

[You, Benjamin]

Reviewed-by: Benjamin You 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, July 3, 2018 2:38 PM
> To: edk2-devel@lists.01.org
> Cc: Ma, Maurice ; Agyeman, Prince
> ; You, Benjamin 
> Subject: [PATCH v3 2/7] CorebootPayload/PlatformBDS: Impl
> PlatformBootManagerUnableToBoot
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Maurice Ma 
> Cc: Prince Agyeman 
> Cc: Benjamin You 
> ---
>  .../PlatformBootManagerLib/PlatformBootManager.c  | 19
> ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git
> a/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManage
> r.c
> b/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManage
> r.c
> index 7e92441da1..368e89d586 100644
> ---
> a/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManage
> r.c
> +++
> b/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManage
> r.c
> @@ -2,7 +2,7 @@
>This file include all platform action which can be customized
>by IBV/OEM.
> 
> -Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -252,3 +252,20 @@ PlatformBootManagerWaitCallback (
>  {
>return;
>  }
> +
> +/**
> +  The function is called when no boot option could be launched,
> +  including platform recovery options and options pointing to applications
> +  built into firmware volumes.
> +
> +  If this function returns, BDS attempts to enter an infinite loop.
> +**/
> +VOID
> +EFIAPI
> +PlatformBootManagerUnableToBoot (
> +  VOID
> +  )
> +{
> +  return;
> +}
> +
> --
> 2.16.1.windows.1

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

Re: [edk2] GPT Partitions on RAID Disks

[Andrew Fish]

> On Jul 3, 2018, at 10:12 AM, Robinson, Herbie  
> wrote:
> 
> Background:
> 
> I have been tasked with implementing UEFI boot in our VOS operating system.  
> We've been using GPT partitions for more than 15 years, but only within our 
> own OS...  We haven't had to interact with any other software before this.  
> We have a fault tolerant OS; so, all disks are RAID1 (software supported).  
> We don't expose the GPT partitioning to our user interface:  We have just use 
> it as a wrapper for boot support to keep BIOS from being confused.  The 
> intent was to set it up to boot with either the legacy BIOS or UEFI.  At the 
> time, we only had a legacy BIOS to test with; so, we never finished the UEFI 
> boot.
> 
> I've reviewed our current implementation and found a few minor things wrong; 
> so, I have been working on a utility to fix them.  But the might be some more 
> issues.  I have three questions, but relating to RAID 1.
> 
> 
> 1.   We have historically paired entire disks when we do RAID1, not 
> partitions (we have never supported multiple file system partitions on one 
> disk, because it didn't make sense from a performance standpoint).  I believe 
> the current initialization uses the same DiskGUID in the GPT header for both 
> disks.  I'm assuming that is not going to work properly.  Is that correct?
> 

Herbie,

I'm not sure that a unique  DiskGUID is required for RAID1 given the disks are 
mirrors. I think the ask is that each unique GPT (some software has to create 
it) always gets a new GUID/UUID. 

> 2.   The spec also seems to say that the UniquePartitionGUID should also 
> be different for RAID 1 pairs.  Is that correct?
> 

Same as DiskGUID is it a true mirror or unique disk? In a practical sense if 
some one could bit copy a disk you could have duplicates. The hope is that any 
software that is GPT aware would fix up the Unique GUID/UUID values as part of 
the cloning operation. 

> 3.   We have learned over the years that one doesn't allocate an entire 
> disk for a RAID (because one may have to replace a drive and replacement may 
> not come with exactly the same ending LBA).  We are currently leaving off 
> some space at the end.  When we do that, we are not putting the backup GPT 
> header at the last LBA the devices.  By my reading of the spec, that is a 
> mistake.  I do believe the spec allows me to leave a large gap between the 
> LastUsableLBA in the backup GPT header with the backup table placed anywhere 
> within that gap.  Is that correct?
> 

There has been language added over the years to try to help people deal with 
issues like this. The ATA8-ACS language and this section:
"To avoid the need to determine the physical block size and the optimal 
transfer length granularity, software may align GPT partitions at significantly 
larger boundaries. For example, assuming logical block 0 is aligned, it may use 
LBAs that are multiples of 2,048 to align to 1,048,576 byte (1 MiB) boundaries, 
which supports most common physical block sizes and RAID stripe sizes."

I think the "software may align GPT partitions at significantly larger 
boundaries." in the section above grants you a lot of latitude about how you 
layout the disks. 

Caveat Emptor if you need to be interoperable with other chunks of software as 
there can be extra non-spec assumptions that leak into implementations. The 
last one that I got hit by was most of the EFI code in the world require a 
protective MBR, but the spec uses may (not required) when talking about if a 
protective MBR is required. 

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c#L265

  //
  // Verify that the Protective MBR is valid
  //
  for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) {
if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 &&
ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION &&
UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1
) {
  break;
}
  }
  if (Index == MAX_MBR_PARTITIONS) {
goto Done;
  }



Thanks,

Andrew Fish

> Thanks in advance for your guidance.
> Herbie Robinson
> Software Architect
> Stratus Technologies | www.stratus.com
> 5 Mill and Main Place, Suite 500 | Maynard, MA 01754
> T: +1-978-461-7531 | E: herbie.robin...@stratus.com
> [Stratus Technologies]
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH edk2-platforms v2 3/3] Readme.md: Add instructions to build in a Windows Environment

[Evan Lloyd]

Reviewed-by: Evan Lloyd 

Leif - would it make sense/be acceptable to add a GNU make.exe image to 
edk2-non-osi?

Evan


> -Original Message-
> From: Leif Lindholm 
> Sent: 03 July 2018 11:24
> To: Chris Co 
> Cc: edk2-devel@lists.01.org; Ard Biesheuvel ;
> Michael D Kinney ; Evan Lloyd
> 
> Subject: Re: [PATCH edk2-platforms v2 3/3] Readme.md: Add instructions to
> build in a Windows Environment
>
> Hi Christopher,
>
> Patches 1-2 Reviewed-by: Leif Lindholm  Pushed
> as 5ed298efba..df5cbc93b8 - thanks!
>
> In general, I'm happy enough with the below that I might just push that as
> well, but I will give others a chance to pipe up.
> (Adding Evan to cc.)
>
> I have one comment below.
>
> On Tue, Jul 03, 2018 at 02:29:38AM +, Chris Co wrote:
> > These instructions explain how to setup a Windows build environment
> > with extra instructions to build for ARM platforms using the GCC
> > cross-compiler toolchain.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Christopher Co 
> > Cc: Ard Biesheuvel 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > ---
> >  Readme.md | 249 +++-
> >  1 file changed, 248 insertions(+), 1 deletion(-)
> >
> > diff --git a/Readme.md b/Readme.md
> > index 6ad5953093d6..9916db7f3a1f 100644
> > --- a/Readme.md
> > +++ b/Readme.md
> > @@ -190,8 +190,255 @@ $ ./uefi-tools/edk2-build.sh -b DEBUG -b
> RELEASE
> >
> >  # How To Build (Windows Environment)
> >
> > -(I genuinely have no idea. Please help!)
> > +These instructions will be a summary of the [Windows Systems wiki
> > +entry](https://github.com/tianocore/tianocore.github.io/wiki/Windows-
> systems).
> > +The wiki entry is targeted towards using the Visual Studio compiler.
> > +The instructions below will have some extra steps if you are cross-
> compiling with GCC.
> >
> > +## Prerequisites
> > +You will need Git for Windows and Visual Studio installed to build EDK2
> from source.
> > +If you wish to build the build tools, you will also need Python 2.7
> > +for Windows and cx_Freeze.
> > +
> > +## If cross compiling
> > +If building EDK2 for a different architecture than the build machine,
> > +you need to obtain an appropriate cross-compiler. X64 (x86_64)
> > +compilers also support IA32, but the reverse may not always be true.
> > +
> > +Target architecture | Cross compilation prefix
> > +|-
> > +ARM | arm-eabi-
> > +
> > +### GCC
> > +Linaro provides a Windows-compatible GCC toolchain for
> > +[arm-eabi](https://releases.linaro.org/components/toolchain/binaries/
> > +latest/arm-eabi/) compiled to run on x86_64/i686 Windows.  Select the
> > +i686 mingw32 variant.
> > +
> > +To use the GCC toolchain, you will also need a Windows-compatible GNU
> > +Make.  These instructions will use [MinGW](http://mingw.org/) but any
> > +Windows-compatible GNU Make tool will work.
> > +
> > +## Obtaining source code
>
> Ideally, we would have a single section for this, regardless of build 
> platform.
> You're adding info about submodule handling here that we'd otherwise need
> to duplicate to the Linux section, and keep in sync.
>
> /
> Leif
>
> > +1. Create a new folder (directory) on your local development machine
> > +   for use as your workspace. This example uses `C:\git\tianocore`, modify
> as
> > +   appropriate for your needs.
> > +
> > +1. In a Windows command prompt:
> > +   ```
> > +   > set WORKSPACE=C:\git\tianocore
> > +   > mkdir %WORKSPACE%
> > +   > cd %WORKSPACE%
> > +   ```
> > +
> > +1. Into that folder, clone:
> > +   1. [edk2](https://github.com/tianocore/edk2)
> > +   1. [edk2-platforms](https://github.com/tianocore/edk2-platforms)
> > +   1. [edk2-non-osi](https://github.com/tianocore/edk2-non-osi) (if
> building
> > +  platforms that need it)
> > +   ```
> > +   > git clone https://github.com/tianocore/edk2.git
> > +   ...
> > +   > git clone https://github.com/tianocore/edk2-platforms.git
> > +   ...
> > +   > git clone https://github.com/tianocore/edk2-non-osi.git
> > +   ```
> > +
> > +1. Clone submodules
> > +   ```
> > +   > pushd edk2
> > +   > git submodule update --init --recursive
> > +   > popd
> > +   ```
> > +
> > +1. Set up a **PACKAGES_PATH** to point to the locations of these three
> > +   repositories.
> > +
> > +   Note: only set the path with valid locations.  If you don't use 
> > edk2-non-
> osi,
> > +   do not add it to your **PACKAGES_PATH**. Otherwise, you will get
> errors during build.
> > +
> > +   `> set
> > + PACKAGES_PATH=%WORKSPACE%\edk2;%WORKSPACE%\edk2-
> platforms;%WORKSPACE
> > + %\edk2-non-osi`
> > +
> > +### If cross-compiling with GCC
> > + GNU Make
> > +These instructions will walk through getting and setting up
> > +mingw32-make.exe. You are free to use other GNU make tools if those
> > +are more comfortable for you. Just make sure the GNU make is Windows-
> compatible and in your PATH.
> > +
> > +1. Download the latest [MinGW setup
> 

[edk2] GPT Partitions on RAID Disks

[Robinson, Herbie]

Background:

I have been tasked with implementing UEFI boot in our VOS operating system.  
We've been using GPT partitions for more than 15 years, but only within our own 
OS...  We haven't had to interact with any other software before this.  We have 
a fault tolerant OS; so, all disks are RAID1 (software supported).  We don't 
expose the GPT partitioning to our user interface:  We have just use it as a 
wrapper for boot support to keep BIOS from being confused.  The intent was to 
set it up to boot with either the legacy BIOS or UEFI.  At the time, we only 
had a legacy BIOS to test with; so, we never finished the UEFI boot.

I've reviewed our current implementation and found a few minor things wrong; 
so, I have been working on a utility to fix them.  But the might be some more 
issues.  I have three questions, but relating to RAID 1.


1.   We have historically paired entire disks when we do RAID1, not 
partitions (we have never supported multiple file system partitions on one 
disk, because it didn't make sense from a performance standpoint).  I believe 
the current initialization uses the same DiskGUID in the GPT header for both 
disks.  I'm assuming that is not going to work properly.  Is that correct?

2.   The spec also seems to say that the UniquePartitionGUID should also be 
different for RAID 1 pairs.  Is that correct?

3.   We have learned over the years that one doesn't allocate an entire 
disk for a RAID (because one may have to replace a drive and replacement may 
not come with exactly the same ending LBA).  We are currently leaving off some 
space at the end.  When we do that, we are not putting the backup GPT header at 
the last LBA the devices.  By my reading of the spec, that is a mistake.  I do 
believe the spec allows me to leave a large gap between the LastUsableLBA in 
the backup GPT header with the backup table placed anywhere within that gap.  
Is that correct?

Thanks in advance for your guidance.
Herbie Robinson
Software Architect
Stratus Technologies | www.stratus.com
5 Mill and Main Place, Suite 500 | Maynard, MA 01754
T: +1-978-461-7531 | E: herbie.robin...@stratus.com
[Stratus Technologies]

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

Re: [edk2] gRT->SetVariable ACCESS DENIED error

[Andrew Fish]

Toan,

What arguments did you pass to gRT->SetVariable()?

What implementation did you test on? 

In general there are "wiggle words" in the UEFI Spec that make it legal to 
return other error codes. Back in the day when NOR FLASH was expensive and EFI 
was size constrained we did not want to have to filter every return value from 
a lower level to convert it to a spec required return code. 

Thanks,

Andrew Fish

> On Jul 3, 2018, at 2:10 AM, Toan Le manh  wrote:
> 
> Dear all,
> 
> I'm facing the Status EFI_ACCESS_DENIED when using gRT->SetVariable()
> method.
> There is no description of this returned status for SetVariable()  in UEFI
> spec.
> Have you ever faced this type of error? Could you please give me any idea
> on how this happen?
> Sorry for any inconvenience, I'm newbie in EDK2.
> 
> Thanks & Best Regards,
> Toan
> ___
> 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

[edk2] [PATCH 1/1] MdeModulePkg/DisplayEngineDxe: Fix small InitializeDisplayEngine leak

[Thomas Palmer]

After calling RegisterHotKey, the allocated memory in NewString should
be freed.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Thomas Palmer 
---
 MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c 
b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
index f2eac4d3fece..7390f954b67f 100644
--- a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
+++ b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
@@ -4221,11 +4221,13 @@ InitializeDisplayEngine (
 NewString = HiiGetString (gHiiHandle, STRING_TOKEN 
(FUNCTION_TEN_STRING), NULL);
 ASSERT (NewString != NULL);
 FormBrowserEx2->RegisterHotKey (, BROWSER_ACTION_SUBMIT, 0, 
NewString);
+FreePool (NewString);
 
 HotKey.ScanCode   = SCAN_F9;
 NewString = HiiGetString (gHiiHandle, STRING_TOKEN 
(FUNCTION_NINE_STRING), NULL);
 ASSERT (NewString != NULL);
 FormBrowserEx2->RegisterHotKey (, BROWSER_ACTION_DEFAULT, 
EFI_HII_DEFAULT_CLASS_STANDARD, NewString);
+FreePool (NewString);
   }
 
   return EFI_SUCCESS;
-- 
2.7.4

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

[edk2] [PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Fix small LoadOptionToVariable leak

[Thomas Palmer]

After calling SetVariable, the allocated memory in Variable should be
freed.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Thomas Palmer 
---
 .../Library/UefiBootManagerLib/BmLoadOption.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index ff0c65a2efc6..7bf96646c690 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -2,7 +2,7 @@
   Load option library functions which relate with creating and processing load 
options.
 
 Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
-(C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
+(C) Copyright 2015-2018 Hewlett Packard Enterprise Development LP
 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
@@ -250,13 +250,16 @@ structure.
 VariableAttributes = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS;
   }
 
-  return gRT->SetVariable (
-OptionName,
-,
-VariableAttributes,
-VariableSize,
-Variable
-);
+  Status = gRT->SetVariable (
+  OptionName,
+  ,
+  VariableAttributes,
+  VariableSize,
+  Variable
+  );
+  FreePool (Variable);
+
+  return Status;
 }
 
 /**
-- 
2.7.4

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

Re: [edk2] [PATCH v3 0/7] Add platform hook for ultimate boot failure.

[Laszlo Ersek]

Hi Ray,

On 07/03/18 08:37, Ruiyu Ni wrote:
> Ruiyu Ni (7):
>   MdeModulePkg/PlatformBootManager: Add PlatformBootManagerUnableToBoot
>   CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot
>   OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot
>   Nt32Pkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
>   QuarkPlatform/PlatformBDS: Implement PlatformBootManagerUnableToBoot
>   MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"
>   MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()
>
>  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
>  .../Include/Library/PlatformBootManagerLib.h   | 13 +
>  .../PlatformBootManager.c  | 19 ++-
>  MdeModulePkg/Universal/BdsDxe/BdsEntry.c   | 61 
> ++
>  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
>  .../Library/PlatformBootManagerLib/BdsPlatform.c   | 61 
> +-
>  .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
>  7 files changed, 150 insertions(+), 61 deletions(-)
>

thanks a lot for this version as well!

It seems we have the following PlatformBootManagerLib instances in the
edk2 tree:

  ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
  CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
  MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManagerLibNull.inf
  Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
  QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
  Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformBdsLib.inf

This series updates all but ArmPkg, ArmVirtPkg and Vlv2TbltDevicePkg. So
I think three more patches would be necessary, before patch #6.

Originally, with the registration pattern, I offered to port the OvmfPkg
update to ArmVirtPkg myself, later. However, with the present pattern,
these three platforms would stop building, so I think they should be
updated before we commit patches #6 and #7.

For ArmPkg and Vlv2TbltDevicePkg, I *think* the Null implementation ("do
nothing") is appropriate. (I'm CC'ing those package maintainers). For
ArmVirtPkg, duplicating the OvmfPkg approach would be correct.

Can you take on updating these three platforms as well? Or can I help
somehow with it? (It's tricky because the three platform patches that I
could post should go in the middle of the series, neither before nor
after.)

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

Re: [edk2] [PATCH v3 3/7] OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot

[Laszlo Ersek]

On 07/03/18 08:37, Ruiyu Ni wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> ---
>  .../Library/PlatformBootManagerLib/BdsPlatform.c   | 61 
> +-
>  1 file changed, 60 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> index 57870cb856..e56ffc141a 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -1,7 +1,7 @@
>  /** @file
>Platform BDS customizations.
>  
> -  Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
>distribution.  The full text of the license may be found at
> @@ -1676,3 +1676,62 @@ PlatformBootManagerWaitCallback (
>  );
>  }
>  
> +/**
> +  The function is called when no boot option could be launched,
> +  including platform recovery options and options pointing to applications
> +  built into firmware volumes.
> +
> +  If this function returns, BDS attempts to enter an infinite loop.
> +**/
> +VOID
> +EFIAPI
> +PlatformBootManagerUnableToBoot (
> +  VOID
> +  )
> +{
> +  EFI_STATUS   Status;
> +  EFI_INPUT_KEYKey;
> +  EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
> +  UINTNIndex;
> +
> +  //
> +  // BootManagerMenu doesn't contain the correct information when return 
> status is EFI_NOT_FOUND.
> +  //

Before you commit this patch, can you please rewrap this long comment, like 
this:

  //
  // BootManagerMenu doesn't contain the correct information when return status
  // is EFI_NOT_FOUND.
  //

With that:

Reviewed-by: Laszlo Ersek 

Thank you!
Laszlo

> +  Status = EfiBootManagerGetBootManagerMenu ();
> +  if (EFI_ERROR (Status)) {
> +return;
> +  }
> +  //
> +  // Normally BdsDxe does not print anything to the system console, but this 
> is
> +  // a last resort -- the end-user will likely not see any DEBUG messages
> +  // logged in this situation.
> +  //
> +  // AsciiPrint() will NULL-check gST->ConOut internally. We check gST->ConIn
> +  // here to see if it makes sense to request and wait for a keypress.
> +  //
> +  if (gST->ConIn != NULL) {
> +AsciiPrint (
> +  "%a: No bootable option or device was found.\n"
> +  "%a: Press any key to enter the Boot Manager Menu.\n",
> +  gEfiCallerBaseName,
> +  gEfiCallerBaseName
> +  );
> +Status = gBS->WaitForEvent (1, >ConIn->WaitForKey, );
> +ASSERT_EFI_ERROR (Status);
> +ASSERT (Index == 0);
> +
> +//
> +// Drain any queued keys.
> +//
> +while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
> +  //
> +  // just throw away Key
> +  //
> +}
> +  }
> +
> +  for (;;) {
> +EfiBootManagerBoot ();
> +  }
> +}
> +
> 

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

[edk2] [PATCH 1/1] MdeModulePkg/PciBusDxe: Fix small memory leak in FreePciDevice

[Thomas Palmer]

When cleaning the PciIoDevice, also free the BusNumberRange

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Thomas Palmer 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
index ad7a2337f578..48cf57a24f8f 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
@@ -2,6 +2,7 @@
   Supporting functions implementaion for PCI devices management.
 
 Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+(C) Copyright 2018 Hewlett Packard Enterprise Development LP
 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
@@ -105,6 +106,10 @@ FreePciDevice (
 FreePool (PciIoDevice->DevicePath);
   }
 
+  if (PciIoDevice->BusNumberRanges != NULL) {
+FreePool (PciIoDevice->BusNumberRanges);
+  }
+
   FreePool (PciIoDevice);
 }
 
-- 
2.7.4

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

Re: [edk2] [PATCH v3 7/7] MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()

[Laszlo Ersek]

On 07/03/18 08:37, Ruiyu Ni wrote:
> When no boot option can be launched, BDS core calls
> PlatformBootManagerUnableToBoot() to let platform BdsDxe handle it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Laszlo Ersek 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Sunny Wang 
> ---
>  MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
> b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> index 39b643c77a..a25663ea43 100644
> --- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> +++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> @@ -1043,6 +1043,7 @@ BdsEntry (
>}
>  
>DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
> +  PlatformBootManagerUnableToBoot ();
>CpuDeadLoop ();
>  }
>  
> 

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH v3 6/7] MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"

[Laszlo Ersek]

On 07/03/18 08:37, Ruiyu Ni wrote:
> Commit d1de487dd2e77f4741abcbd71d19a8c93971fda0
> "MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before
>  hanging"
> changed BDS core to fall back to UI loop when no bootable option
> can be launched.
> Now since PlatformBootManagerUnableToBoot() is added, the commit
> can be reverted.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> ---
>  MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 60 
> +++-
>  1 file changed, 4 insertions(+), 56 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
> b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> index 49e403e181..39b643c77a 100644
> --- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> +++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> @@ -634,55 +634,6 @@ BdsFormalizeEfiGlobalVariable (
>BdsFormalizeOSIndicationVariable ();
>  }
>  
> -/**
> -  Enter an infinite loop of calling the Boot Manager Menu.
> -
> -  This is a last resort alternative to BdsEntry() giving up for good. This
> -  function never returns.
> -
> -  @param[in] BootManagerMenu  The EFI_BOOT_MANAGER_LOAD_OPTION located and/or
> -  created by the 
> EfiBootManagerGetBootManagerMenu()
> -  call in BdsEntry().
> -**/
> -VOID
> -BdsBootManagerMenuLoop (
> -  IN EFI_BOOT_MANAGER_LOAD_OPTION *BootManagerMenu
> -  )
> -{
> -  EFI_INPUT_KEY Key;
> -
> -  //
> -  // Normally BdsDxe does not print anything to the system console, but this 
> is
> -  // a last resort -- the end-user will likely not see any DEBUG messages
> -  // logged in this situation.
> -  //
> -  // AsciiPrint() will NULL-check gST->ConOut internally. We check gST->ConIn
> -  // here to see if it makes sense to request and wait for a keypress.
> -  //
> -  if (gST->ConIn != NULL) {
> -AsciiPrint (
> -  "%a: No bootable option or device was found.\n"
> -  "%a: Press any key to enter the Boot Manager Menu.\n",
> -  gEfiCallerBaseName,
> -  gEfiCallerBaseName
> -  );
> -BdsWaitForSingleEvent (gST->ConIn->WaitForKey, 0);
> -
> -//
> -// Drain any queued keys.
> -//
> -while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
> -  //
> -  // just throw away Key
> -  //
> -}
> -  }
> -
> -  for (;;) {
> -EfiBootManagerBoot (BootManagerMenu);
> -  }
> -}
> -
>  /**
>  
>Service routine for BdsInstance->Entry(). Devices are connected, the
> @@ -1081,19 +1032,16 @@ BdsEntry (
>  } while (BootSuccess);
>}
>  
> +  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
> +EfiBootManagerFreeLoadOption ();
> +  }
> +
>if (!BootSuccess) {
>  LoadOptions = EfiBootManagerGetLoadOptions (, 
> LoadOptionTypePlatformRecovery);
>  ProcessLoadOptions (LoadOptions, LoadOptionCount);
>  EfiBootManagerFreeLoadOptions (LoadOptions, LoadOptionCount);
>}
>  
> -  //
> -  // If BootManagerMenu is available, fall back to it indefinitely.
> -  //
> -  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
> -BdsBootManagerMenuLoop ();
> -  }
> -
>DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
>CpuDeadLoop ();
>  }
> 

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

Re: [edk2] [PATCH v3 1/7] MdeModulePkg/PlatformBootManager: Add PlatformBootManagerUnableToBoot

[Laszlo Ersek]

On 07/03/18 08:37, Ruiyu Ni wrote:
> The patch adds a new API PlatformBootManagerUnableToBoot()'

(1) Unbalanced single quote (').

> to PlatformBootManagerLib.
> The new API is provided by platform bds library and is called when
> no boot option could be launched.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Laszlo Ersek 
> Cc: Sunny Wang 
> ---
>  MdeModulePkg/Include/Library/PlatformBootManagerLib.h | 13 +
>  .../PlatformBootManagerLibNull/PlatformBootManager.c  | 19 
> ++-
>  2 files changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Include/Library/PlatformBootManagerLib.h 
> b/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
> index 65630ce2bb..6e26329043 100644
> --- a/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
> +++ b/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
> @@ -59,4 +59,17 @@ PlatformBootManagerWaitCallback (
>UINT16  TimeoutRemain
>);
>  
> +/**
> +  The function is called when no boot option could be launched,
> +  including platform recovery options and options pointing to applications
> +  built into firmware volumes.
> +
> +  If this function returns, BDS attempts to enter an infinite loop.
> +**/
> +VOID
> +EFIAPI
> +PlatformBootManagerUnableToBoot (
> +  VOID
> +  );
> +
>  #endif
> diff --git 
> a/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c 
> b/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
> index 1390e19097..5a4455ef23 100644
> --- a/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
> +++ b/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
> @@ -2,7 +2,7 @@
>This file include all platform action which can be customized
>by IBV/OEM.
>  
> -Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD 
> License
>  which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -65,3 +65,20 @@ PlatformBootManagerWaitCallback (
>  {
>return;
>  }
> +
> +/**
> +  The function is called when no boot option could be launched,
> +  including platform recovery options and options pointing to applications
> +  built into firmware volumes.
> +
> +  If this function returns, BDS attempts to enter an infinite loop.
> +**/
> +VOID
> +EFIAPI
> +PlatformBootManagerUnableToBoot (
> +  VOID
> +  )
> +{
> +  return;
> +}
> +
> 

(2) Do we intentionally add such "return" statements? An empty function
body (possibly with a comment) would work as well.

I'm fine either way, I'd just like to highlight that there is a
TianoCore BZ:

https://bugzilla.tianocore.org/show_bug.cgi?id=843

about removing useless "return" statements.

I believe we should decide whether such return statements are a good
thing for edk2. If they are, we should close #843 as NOTEBUG. If they
aren't a good thing, we shouldn't add more of them.

Anyway, whatever the decision for (1) and (2) above, I don't think
reposting would be necessary just because of them; it should be OK to
update the patch before pushing.

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH 2/2] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: mark Runtime Data as MMIO when SEV is active

[Laszlo Ersek]

Hi Brijesh,

On 07/03/18 05:11, Brijesh Singh wrote:
> When SEV is active, the flash memory range is mapped as unencrypted by
> AmdSevDxe. Mark the flash memory range with EfiGcdMemoryTypeMemoryMappedIo
> so that OS maps this memory range as unencrypted.
> 
> Cc: Justen Jordan L 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
> 
> Hi Laszlo,
> 
> I have tried marking flash memory range as MMIO for non SEV guest, and
> everything seems to be working fine but I was not sure if we will break
> something else in non SEV case. Because of this I have created a new
> routine which marks the range as MMIO only when SEV is active.
> 
>  .../FvbServicesRuntimeDxe.inf  |  1 +
>  .../FwBlockService.c   | 69 
> +-
>  2 files changed, 69 insertions(+), 1 deletion(-)

Here's what I suggest:

(1) Please send the patch for MdeModulePkg/VariableDxe separately, with
the updates that Star requests. We should commit that patch first (and
separately), so that we can collaborate on the OvmfPkg patches without
disturbing Star with further reposts.

(2) For OvmfPkg, I'd like you to split this change in three parts:

(2a) In the first patch, please switch MarkMemoryRangeForRuntimeAccess()
from the runtime memory marking to the runtime MMIO marking. This should
extend up to and including the SetMemorySpaceAttributes() call.

Also, rename MarkMemoryRangeForRuntimeAccess() to
MarkIoMemoryRangeForRuntimeAccess().

In my opinion, this is something we should do regardless of SEV.

(2b) In the second patch, please declare
MarkIoMemoryRangeForRuntimeAccess() at the end of "FwBlockService.h",
and move the implementation to "FwBlockServiceDxe.c".

For the SMM build, add an empty stub to "FwBlockServiceSmm.c".

This is because the "MMIO+runtime" marking stands for "a runtime DXE
driver or service is using this address range". However, in the SMM
build, only an SMM driver is using the address range; I don't think we
need to expose the range in the UEFI memmap at all.

(2c) In the third patch, modify the implementation in
"FwBlockServiceDxe.c", so that the SEV case is handled at the end of
MarkIoMemoryRangeForRuntimeAccess(). (By clearing the C-bit again.)


The end result *should* be that:
- in the non-SMM build,
  - we expose the area as runtime MMIO in the UEFI memmap,
  - we handle SEV explicitly,
  - and the variable DXE driver leaves the attributes alone,

- in the SMM build,
  - we don't expose the area at all,
  - we clear the C-bit *earlier* (in QemuFlashBeforeProbe()),
  - the variable SMM driver leaves the GCD / UEFI maps alone.

Obviously we'll have to regression test both builds with a number of
guest OSes; I will help with that (I can test going back to RHEL-6 and
Windows-7).

I have two more comments below:

> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> index d7b4ec06c4e6..1af675852c86 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> @@ -58,6 +58,7 @@ [LibraryClasses]
>UefiBootServicesTableLib
>UefiDriverEntryPoint
>UefiRuntimeLib
> +  MemEncryptSevLib
>  
>  [Guids]
>gEfiEventVirtualAddressChangeGuid   # ALWAYS_CONSUMED
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
> index 558b395dff4a..3aa21466556a 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "FwBlockService.h"
>  #include "QemuFlash.h"
> @@ -867,6 +868,64 @@ MarkMemoryRangeForRuntimeAccess (
>  
>  STATIC
>  EFI_STATUS
> +SevMarkMemoryRangeForRuntimeAccess (
> +  EFI_PHYSICAL_ADDRESSBaseAddress,
> +  UINTN   Length
> +  )
> +{
> +  EFI_STATUS  Status;
> +  EFI_GCD_MEMORY_SPACE_DESCRIPTOR GcdDescriptor;
> +
> +  //
> +  // Mark flash region as runtime memory
> +  //
> +  Status = gDS->RemoveMemorySpace (
> +  BaseAddress,
> +  Length
> +  );
> +
> +  Status = gDS->AddMemorySpace (
> +  EfiGcdMemoryTypeMemoryMappedIo,
> +  BaseAddress,
> +  Length,
> +  EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  Status = gDS->AllocateMemorySpace (
> +  AllocateAddress,
> +  EfiGcdMemoryTypeMemoryMappedIo,
> +  0,
> +  EFI_SIZE_TO_PAGES (Length),

(3) This seems wrong; AllocateMemorySpace() takes a number of bytes.

(I realize you pasted this verbatim from an earlier suggestion 

[edk2] [PATCH v2] MdePkg/BaseLib: Add bit field population calculating methods

[Tomas Pilar (tpilar)]

Add 32-bit and 64-bit functions that count number of set bits in a bit field
using a divide-and-count method.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Tomas Pilar 
Cc: Liming Gao 
Cc: Michael D Kinney 
---
 MdePkg/Include/Library/BaseLib.h  | 56 +++
 MdePkg/Library/BaseLib/BitField.c | 79 +++
 2 files changed, 135 insertions(+)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 1db3a04..123ae19 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -4609,6 +4609,62 @@ BitFieldAndThenOr64 (
   IN  UINT64OrData
   );
 
+/**
+  Reads a bit field from a 32-bit value, counts and returns
+  the number of set bits.
+
+  Counts the number of set bits in the  bit field specified by
+  StartBit and EndBit in Operand. The count is returned.
+
+  If StartBit is greater than 31, then ASSERT().
+  If EndBit is greater than 31, then ASSERT().
+  If EndBit is less than StartBit, then ASSERT().
+
+  @param  Operand   Operand on which to perform the bitfield operation.
+  @param  StartBit  The ordinal of the least significant bit in the bit field.
+Range 0..31.
+  @param  EndBitThe ordinal of the most significant bit in the bit field.
+Range 0..31.
+
+  @return The number of bits set between StartBit and EndBit.
+
+**/
+UINT8
+EFIAPI
+BitFieldCountOnes32 (
+  IN   UINT32   Operand,
+  IN   UINTNStartBit,
+  IN   UINTNEndBit
+  );
+
+/**
+   Reads a bit field from a 64-bit value, counts and returns
+   the number of set bits.
+
+   Counts the number of set bits in the  bit field specified by
+   StartBit and EndBit in Operand. The count is returned.
+
+   If StartBit is greater than 63, then ASSERT().
+   If EndBit is greater than 63, then ASSERT().
+   If EndBit is less than StartBit, then ASSERT().
+
+   @param  Operand   Operand on which to perform the bitfield operation.
+   @param  StartBit  The ordinal of the least significant bit in the bit field.
+   Range 0..63.
+   @param  EndBitThe ordinal of the most significant bit in the bit field.
+   Range 0..63.
+
+   @return The number of bits set between StartBit and EndBit.
+
+**/
+UINT8
+EFIAPI
+BitFieldCountOnes64 (
+  IN   UINT64   Operand,
+  IN   UINTNStartBit,
+  IN   UINTNEndBit
+  );
+
 //
 // Base Library Checksum Functions
 //
diff --git a/MdePkg/Library/BaseLib/BitField.c 
b/MdePkg/Library/BaseLib/BitField.c
index d2d3150..56b8eb2 100644
--- a/MdePkg/Library/BaseLib/BitField.c
+++ b/MdePkg/Library/BaseLib/BitField.c
@@ -920,3 +920,82 @@ BitFieldAndThenOr64 (
OrData
);
 }
+
+/**
+  Reads a bit field from a 32-bit value, counts and returns
+  the number of set bits.
+
+  Counts the number of set bits in the  bit field specified by
+  StartBit and EndBit in Operand. The count is returned.
+
+  If StartBit is greater than 31, then ASSERT().
+  If EndBit is greater than 31, then ASSERT().
+  If EndBit is less than StartBit, then ASSERT().
+
+  @param  Operand   Operand on which to perform the bitfield operation.
+  @param  StartBit  The ordinal of the least significant bit in the bit field.
+Range 0..31.
+  @param  EndBitThe ordinal of the most significant bit in the bit field.
+Range 0..31.
+
+  @return The number of bits set between StartBit and EndBit.
+
+**/
+UINT8
+EFIAPI
+BitFieldCountOnes32 (
+  IN   UINT32   Operand,
+  IN   UINTNStartBit,
+  IN   UINTNEndBit
+  )
+{
+  ASSERT (EndBit < 32);
+  ASSERT (StartBit <= EndBit);
+
+  UINT32 Count = BitFieldRead32 (Operand, StartBit, EndBit);
+  Count -= ((Count >> 1) & 0x);
+  Count = (Count & 0x) + ((Count >> 2) & 0x);
+  Count += Count >> 4;
+  Count &= 0x0F0F0F0F;
+  Count += Count >> 8;
+  Count += Count >> 16;
+
+  return (UINT8) Count & 0x3F;
+}
+
+/**
+   Reads a bit field from a 64-bit value, counts and returns
+   the number of set bits.
+
+   Counts the number of set bits in the  bit field specified by
+   StartBit and EndBit in Operand. The count is returned.
+
+   If StartBit is greater than 63, then ASSERT().
+   If EndBit is greater than 63, then ASSERT().
+   If EndBit is less than StartBit, then ASSERT().
+
+   @param  Operand   Operand on which to perform the bitfield operation.
+   @param  StartBit  The ordinal of the least significant bit in the bit field.
+   Range 0..63.
+   @param  EndBitThe ordinal of the most significant bit in the bit field.
+   Range 0..63.
+
+   @return The number of bits set between StartBit and EndBit.
+
+**/
+UINT8
+EFIAPI
+BitFieldCountOnes64 (
+  IN   UINT64   Operand,
+  IN   UINTNStartBit,
+  IN   

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

[Leif Lindholm]

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

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

[Leif Lindholm]

On Tue, Jul 03, 2018 at 03:25:13PM +0530, Supreeth Venkatesh wrote:
> The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
> Platforms. Privileged firmware e.g. ARM Trusted Firmware sets up its
> architectural context including the initial translation tables for the
> S-EL1/EL0 translation regime. The MM environment will still request ARM
> TF to change the memory attributes of memory regions during
> initialization.
> 
> The Standalone MM image is a FV that encapsulates the MM foundation
> and drivers. These are PE-COFF images with data and text segments.
> To initialise the MM environment, Arm Trusted Firmware has to create
> translation tables with sane default attributes for the memory
> occupied by the FV. This library sends SVCs to ARM Trusted Firmware
> to request memory permissions change for data and text segments.
> 
> This patch adds a simple MMU library suitable for execution in S-EL0 and
> requesting memory permissions change operations from Arm Trusted Firmware.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> ---
>  .../ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c  | 195 
> +
>  1 file changed, 195 insertions(+)
>  create mode 100644 
> ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c
> 
> diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c 
> b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c
> new file mode 100644
> index 000..0f5e68d
> --- /dev/null
> +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c
> @@ -0,0 +1,195 @@
> +/** @file
> +*  File managing the MMU for ARMv8 architecture in S-EL0
> +*
> +*  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
> +*
> +*  This program and the accompanying materials
> +*  are licensed and made available under the terms and conditions of the BSD 
> License
> +*  which accompanies this distribution.  The full text of the license may be 
> found at
> +*  http://opensource.org/licenses/bsd-license.php
> +*
> +*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +*
> +**/
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +EFI_STATUS
> +GetMemoryPermissions (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  OUT UINT32*MemoryAttributes
> +  )
> +{
> +  ARM_SVC_ARGS  GetMemoryPermissionsSvcArgs = {0};
> +
> +  GetMemoryPermissionsSvcArgs.Arg0 = 
> ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64;
> +  GetMemoryPermissionsSvcArgs.Arg1 = BaseAddress;
> +  GetMemoryPermissionsSvcArgs.Arg2 = 0;
> +  GetMemoryPermissionsSvcArgs.Arg3 = 0;
> +
> +  ArmCallSvc ();
> +  if (GetMemoryPermissionsSvcArgs.Arg0 == ARM_SVC_SPM_RET_INVALID_PARAMS) {
> +*MemoryAttributes = 0;
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  *MemoryAttributes = GetMemoryPermissionsSvcArgs.Arg0;
> +  return EFI_SUCCESS;
> +}
> +
> +EFI_STATUS
> +RequestMemoryPermissionChange (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length,
> +  IN  UINTN Permissions
> +  )
> +{
> +  EFI_STATUSStatus;
> +  ARM_SVC_ARGS  ChangeMemoryPermissionsSvcArgs = {0};
> +
> +  ChangeMemoryPermissionsSvcArgs.Arg0 = 
> ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64;
> +  ChangeMemoryPermissionsSvcArgs.Arg1 = BaseAddress;
> +  ChangeMemoryPermissionsSvcArgs.Arg2 = (Length >= EFI_PAGE_SIZE) ? \
> + Length >> EFI_PAGE_SHIFT : 1;

Use EFI_SIZE_TO_PAGES?

> +  ChangeMemoryPermissionsSvcArgs.Arg3 = Permissions;
> +
> +  ArmCallSvc ();
> +
> +  Status = ChangeMemoryPermissionsSvcArgs.Arg0;
> +
> +  switch (Status) {
> +  case ARM_SVC_SPM_RET_SUCCESS:
> +Status = EFI_SUCCESS;
> +break;
> +
> +  case ARM_SVC_SPM_RET_NOT_SUPPORTED:
> +Status = EFI_UNSUPPORTED;
> +break;
> +
> +  case ARM_SVC_SPM_RET_INVALID_PARAMS:
> +Status = EFI_INVALID_PARAMETER;
> +break;
> +
> +  case ARM_SVC_SPM_RET_DENIED:
> +Status = EFI_ACCESS_DENIED;
> +break;
> +
> +  case ARM_SVC_SPM_RET_NO_MEMORY:
> +Status = EFI_BAD_BUFFER_SIZE;
> +break;
> +
> +  default:
> +Status = EFI_ACCESS_DENIED;
> +ASSERT (0);
> +  }
> +
> +  return Status;
> +}
> +
> +EFI_STATUS
> +ArmSetMemoryRegionNoExec (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  )
> +{
> +  EFI_STATUSStatus;
> +  UINT32 MemoryAttributes;
> +
> +  Status = GetMemoryPermissions (BaseAddress, );
> +  if (Status != EFI_INVALID_PARAMETER) {
> +return RequestMemoryPermissionChange (BaseAddress,
> +  Length,
> +  MemoryAttributes |
> +  

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

[Leif Lindholm]

On Tue, Jul 03, 2018 at 03:25:11PM +0530, Supreeth Venkatesh wrote:
> PI v1.5 Specification Volume 4 defines Management Mode Core Interface
> and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
> means of communicating between drivers outside of MM and MMI
> handlers inside of MM.
> 
> This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE runtime
> driver for AARCH64 platforms. It uses SMCs allocated from the standard
> SMC range defined in DEN0060A_ARM_MM_Interface_Specification.pdf

I would prefer the document to be referred to by its official name and
its document number:
ARM Management Mode Interface Specification (ARM DEN0060A)

> to communicate with the standalone MM environment in the secure world.
> 
> This patch also adds the MM Communication driver (.inf) file to
> define entry point for this driver and other compile
> related information the driver needs.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 

Oh, and only one Signed-off-by per patch please.
If authorship is to be indicated, ensure that's correct in git before
calling format-patch.

> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> ---
>  .../Drivers/MmCommunicationDxe/MmCommunication.c   | 408 
> +
>  .../Drivers/MmCommunicationDxe/MmCommunication.inf |  50 +++

And --stat/--stat-graph-width from
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23
would mean I wouldn't have to cross-reference below to see which files
are being added/deleted/modified.

Also, the diff order makes a difference.
So please look into the orderfile as described there - noting that
this can now be set permanently in newer revisions of git with
git config diff.orderFile 

>  2 files changed, 458 insertions(+)
>  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
>  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> 
> diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c 
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> new file mode 100644
> index 000..8ba1790
> --- /dev/null
> +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> @@ -0,0 +1,408 @@
> +/** @file
> +
> +  Copyright (c) 2016-2018, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +#define MM_MAJOR_VER_MASK0x

Should this not actually be 0xEFFF?

> +#define MM_MINOR_VER_MASK0x
> +#define MM_MAJOR_VER_SHIFT   16

Nothing wrong with this, but later code would be more easy to read if
these were exposed through macros rather than explicitly extracted:

#define MM_MAJOR_VER(x) (((x) & MM_MAJOR_VER_MASK) >> MM_MAJOR_VER_SHIFT)
#define MM_MINOR_VER(x) ((x) & MM_MINOR_VER_MASK)

> +
> +const UINT32 MM_MAJOR_VER = 1;
> +const UINT32 MM_MINOR_VER = 0;

Meanwhile, these
1) Don't need to be given explicit variables (#define would work fine)
2) Have too generic names. What we're really talking about is
   MM_CALLER_MAJOR_VER and MM_CALLER_MINOR_VER?

Finally please put these macros into a local .h file to be included.

> +
> +//
> +// Address, Length of the pre-allocated buffer for communication with the 
> secure
> +// world.
> +//
> +STATIC ARM_MEMORY_REGION_DESCRIPTOR  mNsCommBuffMemRegion;
> +
> +// Notification event when virtual address map is set.
> +STATIC EFI_EVENT  mSetVirtualAddressMapEvent;
> +
> +//
> +// Handle to install the MM Communication Protocol
> +//
> +STATIC EFI_HANDLE  mMmCommunicateHandle;
> +
> +/**
> +  Communicates with a registered handler.
> +
> +  This function provides an interface to send and receive messages to the
> +  Standalone MM environment on behalf of UEFI services.  This function is 
> part
> +  of the MM Communication Protocol that may be called in physical mode prior 
> to
> +  SetVirtualAddressMap() and in virtual mode after SetVirtualAddressMap().
> +
> +  @param[in]  ThisThe EFI_MM_COMMUNICATION_PROTOCOL
> +  instance.
> +  @param[in, out] CommBuffer  A pointer to the buffer to convey
> +  into MMRAM.
> +  @param[in, out] CommSizeThe size of the data buffer being
> +  passed in. This is optional.
> +
> +  @retval 

Re: [edk2] [PATCH] MdePkg/BaseLib: Add bit field Hamming weight calculation methods

[Gao, Liming]

Tom:
  I think CountOnes is easy to be understood. How about two APIs CountOnes32() 
and CountOnes64()?

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tomas 
> Pilar (tpilar)
> Sent: Tuesday, July 3, 2018 5:48 PM
> To: Evan Lloyd ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Add bit field Hamming weight 
> calculation methods
> 
> Thanks for suggestions. The answer to your comments is that I copied the look 
> and feel of the other bitfield functions.
> 
> The extra assert is mentioned in the documentation for the other bitfield 
> functions even though it just follows from the other two
> asserts - for clarity I suppose.
> 
> I agree that a pure function would be simpler and more elegant, but the rest 
> of the bitfield functions allow you to operate on a specific
> part of the operand (e.g. BitFieldAnd32(Operand, StartBit, EndBit, AndData)), 
> so I reasoned that the API should be kept similar.
> 
> I found two names for this functionality, population count and hamming weight 
> and both are used (Linux kernel uses hamming weight).
> I don't mind using PopCount if you think it's more clear.
> 
> The other issue seems a problem with line endings.
> 
> Cheers,
> Tom
> 
> 
> On 02/07/18 19:57, Evan Lloyd wrote:
> > Hi Tomas
> > I'm not a maintainer here, so my comments are just that and carry no weight 
> > beyond making suggestions that you may wish to
> consider.
> >
> >> -Original Message-
> >> From: edk2-devel  On Behalf Of Tomas
> >> Pilar (tpilar)
> >> Sent: 29 June 2018 10:42
> >> To: edk2-devel@lists.01.org
> >> Subject: [edk2] [PATCH] MdePkg/BaseLib: Add bit field Hamming weight
> >> calculation methods
> >>
> >> Add 32-bit and 64-bit functions that count number of set bits in a bitfield
> >> using the divide-and-count method.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Tomas Pilar 
> >> ---
> >>  MdePkg/Include/Library/BaseLib.h  | 56 +++
> >> MdePkg/Library/BaseLib/BitField.c | 79
> >> +++
> >>  2 files changed, 135 insertions(+)
> >>
> >> diff --git a/MdePkg/Include/Library/BaseLib.h
> >> b/MdePkg/Include/Library/BaseLib.h
> >> index 1db3a04..7eb0488 100644
> >> --- a/MdePkg/Include/Library/BaseLib.h
> >> +++ b/MdePkg/Include/Library/BaseLib.h
> >> @@ -4609,6 +4609,62 @@ BitFieldAndThenOr64 (
> >>IN  UINT64OrData
> >>);
> >>
> >> +/**
> >> +  Reads a bit field from a 32-bit value, counts and returns
> >> +  the number of set bits.
> >> +
> >> +  Counts the number of set bits in the  bit field specified by
> >> + StartBit and EndBit in Operand. The count is returned.
> >> +
> >> +  If StartBit is greater than 31, then ASSERT().
> >> +  If EndBit is greater than 31, then ASSERT().
> >> +  If EndBit is less than StartBit, then ASSERT().
> >> +
> >> +  @param  Operand   Operand on which to perform the bitfield operation.
> >> +  @param  StartBit  The ordinal of the least significant bit in the bit 
> >> field.
> >> +Range 0..31.
> >> +  @param  EndBitThe ordinal of the most significant bit in the bit 
> >> field.
> >> +Range 0..31.
> >> +
> >> +  @return The number of bits set between StartBit and EndBit.
> >> +
> >> +**/
> >> +UINT8
> >> +EFIAPI
> >> +BitFieldHammingWeight32 (
> >> +  IN   UINT32   Operand,
> >> +  IN   UINTNStartBit,
> >> +  IN   UINTNEndBit
> >> +  );
> >> +
> >  [[Evan Lloyd]] I can see the benefit of a "CountOnes" function, but why 
> > not call it that (or similar)?  (I had to look up
> "HammingWeight")
> > Also, why conflate BitField access and CountOnes in one function?  A "pure" 
> > function to count ones might be used in other ways,
> and it is fairly clear if you write:
> > CountOnes(BitFieldRead64 (Operand, StartBit, EndBit));
> >
> >
> >> +/**
> >> +   Reads a bit field from a 64-bit value, counts and returns
> >> +   the number of set bits.
> >> +
> >> +   Counts the number of set bits in the  bit field specified by
> >> +   StartBit and EndBit in Operand. The count is returned.
> >> +
> >> +   If StartBit is greater than 63, then ASSERT().
> >> +   If EndBit is greater than 63, then ASSERT().
> >> +   If EndBit is less than StartBit, then ASSERT().
> >> +
> >> +   @param  Operand   Operand on which to perform the bitfield operation.
> >> +   @param  StartBit  The ordinal of the least significant bit in the bit 
> >> field.
> >> +   Range 0..63.
> >> +   @param  EndBitThe ordinal of the most significant bit in the bit 
> >> field.
> >> +   Range 0..63.
> >> +
> >> +   @return The number of bits set between StartBit and EndBit.
> >> +
> >> +**/
> >> +UINT8
> >> +EFIAPI
> >> +BitFieldHammingWeight64 (
> >> +  IN   UINT64   Operand,
> >> +  IN   UINTNStartBit,
> >> +  IN  

Re: [edk2] [PATCH 1/6] ArmPkg: Add PCDs needed for MM communication driver.

[Leif Lindholm]

On Tue, Jul 03, 2018 at 03:25:10PM +0530, Supreeth Venkatesh wrote:
> This patch defines PCDs to describe the base address and size of
> communication buffer between normal world (uefi) and standalone MM
> environment in the secure world.

Please add a cover-letter when sending more than individual (or
completely trivial) patches. Is this set intended for the master
branch, and how would I exercise this new code?

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> ---
>  ArmPkg/ArmPkg.dec | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
> index 3aa229f..ce108f2 100644
> --- a/ArmPkg/ArmPkg.dec
> +++ b/ArmPkg/ArmPkg.dec
> @@ -239,6 +239,9 @@

Please follow the instructions in
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers
when submitting patches.

Here, following step 9 would have given us the section in the .dec
file without having to cross-reference the existing source.

Regards,

Leif

>gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029
>gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A
>  
> +  gArmTokenSpaceGuid.PcdMmBufferBase|0|UINT64|0x0045
> +  gArmTokenSpaceGuid.PcdMmBufferSize|0|UINT64|0x0046
> +
>  [PcdsFixedAtBuild.common, PcdsDynamic.common]
>#
># ARM Architectural Timer
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Supreeth Venkatesh
> Sent: Tuesday, July 3, 2018 6:01 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [edk2] [PATCH] BaseTools/AutoGen: Update header file for MM modules.
> 
> This patch corrects the Module Type Header file for Management Mode(MM)
> as specified in PI v1.6 Specification. Also, it updates parameter for
> auto generated template functions from EFI_SMM_SYSTEM_TABLE2 to
> EFI_MM_SYSTEM_TABLE.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Supreeth Venkatesh 
> Reviewed-by: Jiewen Yao 
> Cc: Jiewen Yao 
> ---
>  BaseTools/Source/Python/AutoGen/GenC.py | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
> b/BaseTools/Source/Python/AutoGen/GenC.py
> index 5c3552a..55bcaba 100644
> --- a/BaseTools/Source/Python/AutoGen/GenC.py
> +++ b/BaseTools/Source/Python/AutoGen/GenC.py
> @@ -265,7 +265,7 @@ EFI_STATUS
>  EFIAPI
>  ${Function} (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>);
>  ${END}
>  """)
> @@ -278,7 +278,7 @@ EFI_STATUS
>  EFIAPI
>  ProcessModuleEntryPointList (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>)
> 
>  {
> @@ -292,7 +292,7 @@ EFI_STATUS
>  EFIAPI
>  ProcessModuleEntryPointList (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>)
> 
>  {
> @@ -307,7 +307,7 @@ EFI_STATUS
>  EFIAPI
>  ProcessModuleEntryPointList (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>)
> 
>  {
> @@ -675,7 +675,7 @@ EFI_STATUS
>  EFIAPI
>  ${Function} (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2  *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>);${END}
>  """),
>  }
> @@ -755,7 +755,7 @@ VOID
>  EFIAPI
>  ProcessLibrary${Type}List (
>IN EFI_HANDLEImageHandle,
> -  IN EFI_SMM_SYSTEM_TABLE2  *MmSystemTable
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
>)
>  {
>  ${BEGIN}  EFI_STATUS  Status;
> @@ -779,8 +779,8 @@ gModuleTypeHeaderFile = {
>  SUP_MODULE_UEFI_DRIVER   :   ["Uefi.h",  "Library/BaseLib.h", 
> "Library/DebugLib.h",
> "Library/UefiBootServicesTableLib.h", "Library/UefiDriverEntryPoint.h"],
>  SUP_MODULE_UEFI_APPLICATION  :   ["Uefi.h",  "Library/BaseLib.h", 
> "Library/DebugLib.h",
> "Library/UefiBootServicesTableLib.h", "Library/UefiApplicationEntryPoint.h"],
>  SUP_MODULE_SMM_CORE  :   ["PiDxe.h", "Library/BaseLib.h", 
> "Library/DebugLib.h",
> "Library/UefiDriverEntryPoint.h"],
> -SUP_MODULE_MM_STANDALONE :   ["PiSmm.h", "Library/BaseLib.h", 
> "Library/DebugLib.h",
> "Library/SmmDriverStandaloneEntryPoint.h"],
> -SUP_MODULE_MM_CORE_STANDALONE :  ["PiSmm.h", "Library/BaseLib.h", 
> "Library/DebugLib.h",
> "Library/SmmCoreStandaloneEntryPoint.h"],
> +SUP_MODULE_MM_STANDALONE :   ["PiMm.h", "Library/BaseLib.h", 
> "Library/DebugLib.h",
> "Library/StandaloneMmDriverEntryPoint.h"],
> +SUP_MODULE_MM_CORE_STANDALONE :  ["PiMm.h", "Library/BaseLib.h", 
> "Library/DebugLib.h",
> "Library/StandaloneMmCoreEntryPoint.h"],
>  SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile]
>  }
> 
> --
> 2.7.4
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/6] ArmPkg/Include: Add MM interface SVC return codes.

[Leif Lindholm]

On Tue, Jul 03, 2018 at 03:25:12PM +0530, Supreeth Venkatesh wrote:
> This patch adds the Management Mode(MM) - Secure Partition
> Manager(SPM) SVC return codes.
> 
> Also, It corrects SVC ID for retrieving SPM version information.

That sounds unrelated. And looking at it, worthy of a longer
explanation, so probably worth breaking out as a separate patch.

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> ---
>  ArmPkg/Include/IndustryStandard/ArmMmSvc.h | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h 
> b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
> index 4c7b6c3..a64b9ec 100644
> --- a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
> +++ b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
> @@ -20,7 +20,7 @@
>   * delegated events and request the Secure partition manager to perform
>   * privileged operations on its behalf.
>   */
> -#define ARM_SVC_ID_SPM_VERSION_AARCH64 0xC460
> +#define ARM_SVC_ID_SPM_VERSION_AARCH32 0x8460

So, this isn't "correcting" a value - it's replacing a 64-bit call
with a 32-bit one. Which is potentially fine, but then it deserves a
separate patch and a commit message clearly describing why this is the
right thing to do.

Regards,

Leif

>  #define ARM_SVC_ID_SP_EVENT_COMPLETE_AARCH64   0xC461
>  #define ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64   0xC464
>  #define ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64   0xC465
> @@ -40,4 +40,11 @@
>  c_perm) & SET_MEM_ATTR_CODE_PERM_MASK) << 
> SET_MEM_ATTR_CODE_PERM_SHIFT) | \
>  (( (d_perm) & SET_MEM_ATTR_DATA_PERM_MASK) << 
> SET_MEM_ATTR_DATA_PERM_SHIFT))
>  
> +/* MM SVC Return error codes */
> +#define ARM_SVC_SPM_RET_SUCCESS   0
> +#define ARM_SVC_SPM_RET_NOT_SUPPORTED-1
> +#define ARM_SVC_SPM_RET_INVALID_PARAMS   -2
> +#define ARM_SVC_SPM_RET_DENIED   -3
> +#define ARM_SVC_SPM_RET_NO_MEMORY-5
> +
>  #endif
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] reg: IP6 based Static IP Configuration in ISCSI

[Sivaraman Nainar]

Hello,

At present in the ISCSI configuration we are able to specify the Static IP 
configuration for IP4 protocol. Is there any plan to support IP6 static IP 
configuration in ISCSI Configuration?

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

[edk2] [PATCH] BaseTools/AutoGen: Update header file for MM modules.

[Supreeth Venkatesh]

This patch corrects the Module Type Header file for Management Mode(MM)
as specified in PI v1.6 Specification. Also, it updates parameter for
auto generated template functions from EFI_SMM_SYSTEM_TABLE2 to
EFI_MM_SYSTEM_TABLE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
Reviewed-by: Jiewen Yao 
Cc: Jiewen Yao 
---
 BaseTools/Source/Python/AutoGen/GenC.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 5c3552a..55bcaba 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -265,7 +265,7 @@ EFI_STATUS
 EFIAPI
 ${Function} (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   );
 ${END}
 """)
@@ -278,7 +278,7 @@ EFI_STATUS
 EFIAPI
 ProcessModuleEntryPointList (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   )
 
 {
@@ -292,7 +292,7 @@ EFI_STATUS
 EFIAPI
 ProcessModuleEntryPointList (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   )
 
 {
@@ -307,7 +307,7 @@ EFI_STATUS
 EFIAPI
 ProcessModuleEntryPointList (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   )
 
 {
@@ -675,7 +675,7 @@ EFI_STATUS
 EFIAPI
 ${Function} (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2  *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   );${END}
 """),
 }
@@ -755,7 +755,7 @@ VOID
 EFIAPI
 ProcessLibrary${Type}List (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2  *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   )
 {
 ${BEGIN}  EFI_STATUS  Status;
@@ -779,8 +779,8 @@ gModuleTypeHeaderFile = {
 SUP_MODULE_UEFI_DRIVER   :   ["Uefi.h",  "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiBootServicesTableLib.h", 
"Library/UefiDriverEntryPoint.h"],
 SUP_MODULE_UEFI_APPLICATION  :   ["Uefi.h",  "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiBootServicesTableLib.h", 
"Library/UefiApplicationEntryPoint.h"],
 SUP_MODULE_SMM_CORE  :   ["PiDxe.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiDriverEntryPoint.h"],
-SUP_MODULE_MM_STANDALONE :   ["PiSmm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/SmmDriverStandaloneEntryPoint.h"],
-SUP_MODULE_MM_CORE_STANDALONE :  ["PiSmm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/SmmCoreStandaloneEntryPoint.h"],
+SUP_MODULE_MM_STANDALONE :   ["PiMm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/StandaloneMmDriverEntryPoint.h"],
+SUP_MODULE_MM_CORE_STANDALONE :  ["PiMm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/StandaloneMmCoreEntryPoint.h"],
 SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile]
 }
 
-- 
2.7.4

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

[edk2] [PATCH 0/1] BaseTools changes for Management Mode modules

[Supreeth Venkatesh]

The following patch makes changes in AutoGen scripts for Management
Mode related code.

Note: This patch series needs to be applied after applying
Standalone Management Mode core interface support for aarch64
platforms[1] and ArmPkg related changes for StandaloneMM package[2]

[1] - https://lists.01.org/pipermail/edk2-devel/2018-July/026778.html
[2] - https://lists.01.org/pipermail/edk2-devel/2018-July/026791.html

Supreeth Venkatesh (1):
  BaseTools/AutoGen: Update header file for MM modules.

 BaseTools/Source/Python/AutoGen/GenC.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

-- 
2.7.4


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

[edk2] [PATCH 5/6] ArmPkg/ArmMmuLib: Add MMU library inf file suitable for use in S-EL0.

[Supreeth Venkatesh]

This patch adds the definitions, sources, packages and library classes
needed to compile and link MMU Library suitable for use in S-EL0.

Currently, this is used only during the Standalone MM Core
initialization and hence defined as MM_CORE_STANDALONE Module.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 .../ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf| 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf

diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf 
b/ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf
new file mode 100644
index 000..9f5593d
--- /dev/null
+++ b/ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf
@@ -0,0 +1,37 @@
+#/** @file
+#
+#  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+#**/
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = ArmMmuStandaloneMmCoreLib
+  FILE_GUID  = da8f0232-fb14-42f0-922c-63104d2c70bd
+  MODULE_TYPE= MM_CORE_STANDALONE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = ArmMmuStandaloneMmCoreLib|MM_CORE_STANDALONE
+  PI_SPECIFICATION_VERSION   = 0x00010032
+  CONSTRUCTOR= ArmMmuStandaloneMmCoreLibConstructor
+
+[Sources.AARCH64]
+  AArch64/ArmMmuStandaloneMmCoreLib.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  ArmLib
+  CacheMaintenanceLib
+  MemoryAllocationLib
+
+
-- 
2.7.4

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

[edk2] [PATCH 1/6] ArmPkg: Add PCDs needed for MM communication driver.

[Supreeth Venkatesh]

This patch defines PCDs to describe the base address and size of
communication buffer between normal world (uefi) and standalone MM
environment in the secure world.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 3aa229f..ce108f2 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -239,6 +239,9 @@
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029
   gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A
 
+  gArmTokenSpaceGuid.PcdMmBufferBase|0|UINT64|0x0045
+  gArmTokenSpaceGuid.PcdMmBufferSize|0|UINT64|0x0046
+
 [PcdsFixedAtBuild.common, PcdsDynamic.common]
   #
   # ARM Architectural Timer
-- 
2.7.4

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

[edk2] [PATCH 6/6] ArmPkg: Extra action to update permissions for S-ELO MM Image.

[Supreeth Venkatesh]

The Standalone MM drivers runs in S-EL0 in AArch64 on ARM Standard
Platforms and is deployed during SEC phase. The memory allocated to the
Standalone MM drivers should be marked as RO+X.

During PE/COFF Image section parsing, this patch implements extra action
"UpdatePeCoffPermissions" to request the privileged firmware in EL3 to
update the permissions.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 .../DebugPeCoffExtraActionLib.c| 185 +++--
 .../DebugPeCoffExtraActionLib.inf  |   7 +
 2 files changed, 181 insertions(+), 11 deletions(-)

diff --git 
a/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c 
b/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
index f298e58..c87aaf0 100644
--- a/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
+++ b/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
@@ -15,14 +15,165 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 **/
 
 #include 
-#include 
 
+#include 
 #include 
-#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 
+typedef RETURN_STATUS (*REGION_PERMISSION_UPDATE_FUNC) (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  );
+
+STATIC
+RETURN_STATUS
+UpdatePeCoffPermissions (
+  IN  CONST PE_COFF_LOADER_IMAGE_CONTEXT  *ImageContext,
+  IN  REGION_PERMISSION_UPDATE_FUNC   NoExecUpdater,
+  IN  REGION_PERMISSION_UPDATE_FUNC   ReadOnlyUpdater
+  )
+{
+  RETURN_STATUS Status;
+  EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION   Hdr;
+  EFI_IMAGE_OPTIONAL_HEADER_UNION   HdrData;
+  UINTN Size;
+  UINTN ReadSize;
+  UINT32SectionHeaderOffset;
+  UINTN NumberOfSections;
+  UINTN Index;
+  EFI_IMAGE_SECTION_HEADER  SectionHeader;
+  PE_COFF_LOADER_IMAGE_CONTEXT  TmpContext;
+  EFI_PHYSICAL_ADDRESS  Base;
+
+  //
+  // We need to copy ImageContext since PeCoffLoaderGetImageInfo ()
+  // will mangle the ImageAddress field
+  //
+  CopyMem (, ImageContext, sizeof (TmpContext));
+
+  if (TmpContext.PeCoffHeaderOffset == 0) {
+Status = PeCoffLoaderGetImageInfo ();
+if (RETURN_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR,
+"%a: PeCoffLoaderGetImageInfo () failed (Status = %r)\n",
+__FUNCTION__, Status));
+  return Status;
+}
+  }
+
+  if (TmpContext.IsTeImage &&
+  TmpContext.ImageAddress == ImageContext->ImageAddress) {
+DEBUG ((DEBUG_INFO, "%a: ignoring XIP TE image at 0x%lx\n", __FUNCTION__,
+  ImageContext->ImageAddress));
+return RETURN_SUCCESS;
+  }
+
+  if (TmpContext.SectionAlignment < EFI_PAGE_SIZE) {
+//
+// The sections need to be at least 4 KB aligned, since that is the
+// granularity at which we can tighten permissions. So just clear the
+// noexec permissions on the entire region.
+//
+if (!TmpContext.IsTeImage) {
+  DEBUG ((DEBUG_WARN,
+"%a: non-TE Image at 0x%lx has SectionAlignment < 4 KB (%lu)\n",
+__FUNCTION__, ImageContext->ImageAddress, 
TmpContext.SectionAlignment));
+}
+Base = ImageContext->ImageAddress & ~(EFI_PAGE_SIZE - 1);
+Size = ImageContext->ImageAddress - Base + ImageContext->ImageSize;
+return NoExecUpdater (Base, ALIGN_VALUE (Size, EFI_PAGE_SIZE));
+  }
+
+  //
+  // Read the PE/COFF Header. For PE32 (32-bit) this will read in too much
+  // data, but that should not hurt anything. Hdr.Pe32->OptionalHeader.Magic
+  // determines if this is a PE32 or PE32+ image. The magic is in the same
+  // location in both images.
+  //
+  Hdr.Union = 
+  Size = sizeof (EFI_IMAGE_OPTIONAL_HEADER_UNION);
+  ReadSize = Size;
+  Status = TmpContext.ImageRead (TmpContext.Handle,
+ TmpContext.PeCoffHeaderOffset, , Hdr.Pe32);
+  if (RETURN_ERROR (Status) || (Size != ReadSize)) {
+DEBUG ((DEBUG_ERROR,
+  "%a: TmpContext.ImageRead () failed (Status = %r)\n",
+  __FUNCTION__, Status));
+return Status;
+  }
+
+  ASSERT (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE);
+
+  SectionHeaderOffset = TmpContext.PeCoffHeaderOffset + sizeof (UINT32) +
+sizeof (EFI_IMAGE_FILE_HEADER);
+  NumberOfSections= (UINTN)(Hdr.Pe32->FileHeader.NumberOfSections);
+
+  switch (Hdr.Pe32->OptionalHeader.Magic) {
+case EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC:
+  SectionHeaderOffset += Hdr.Pe32->FileHeader.SizeOfOptionalHeader;
+  break;
+case EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC:
+  SectionHeaderOffset += Hdr.Pe32Plus->FileHeader.SizeOfOptionalHeader;
+  break;
+default:
+  ASSERT (FALSE);
+  }
+
+  //
+  // Iterate over the 

[edk2] [PATCH 4/6] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

[Supreeth Venkatesh]

The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
Platforms. Privileged firmware e.g. ARM Trusted Firmware sets up its
architectural context including the initial translation tables for the
S-EL1/EL0 translation regime. The MM environment will still request ARM
TF to change the memory attributes of memory regions during
initialization.

The Standalone MM image is a FV that encapsulates the MM foundation
and drivers. These are PE-COFF images with data and text segments.
To initialise the MM environment, Arm Trusted Firmware has to create
translation tables with sane default attributes for the memory
occupied by the FV. This library sends SVCs to ARM Trusted Firmware
to request memory permissions change for data and text segments.

This patch adds a simple MMU library suitable for execution in S-EL0 and
requesting memory permissions change operations from Arm Trusted Firmware.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 .../ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c  | 195 +
 1 file changed, 195 insertions(+)
 create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c

diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c 
b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c
new file mode 100644
index 000..0f5e68d
--- /dev/null
+++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c
@@ -0,0 +1,195 @@
+/** @file
+*  File managing the MMU for ARMv8 architecture in S-EL0
+*
+*  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+*
+*  This program and the accompanying materials
+*  are licensed and made available under the terms and conditions of the BSD 
License
+*  which accompanies this distribution.  The full text of the license may be 
found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+GetMemoryPermissions (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  OUT UINT32*MemoryAttributes
+  )
+{
+  ARM_SVC_ARGS  GetMemoryPermissionsSvcArgs = {0};
+
+  GetMemoryPermissionsSvcArgs.Arg0 = ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64;
+  GetMemoryPermissionsSvcArgs.Arg1 = BaseAddress;
+  GetMemoryPermissionsSvcArgs.Arg2 = 0;
+  GetMemoryPermissionsSvcArgs.Arg3 = 0;
+
+  ArmCallSvc ();
+  if (GetMemoryPermissionsSvcArgs.Arg0 == ARM_SVC_SPM_RET_INVALID_PARAMS) {
+*MemoryAttributes = 0;
+return EFI_INVALID_PARAMETER;
+  }
+
+  *MemoryAttributes = GetMemoryPermissionsSvcArgs.Arg0;
+  return EFI_SUCCESS;
+}
+
+EFI_STATUS
+RequestMemoryPermissionChange (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length,
+  IN  UINTN Permissions
+  )
+{
+  EFI_STATUSStatus;
+  ARM_SVC_ARGS  ChangeMemoryPermissionsSvcArgs = {0};
+
+  ChangeMemoryPermissionsSvcArgs.Arg0 = 
ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64;
+  ChangeMemoryPermissionsSvcArgs.Arg1 = BaseAddress;
+  ChangeMemoryPermissionsSvcArgs.Arg2 = (Length >= EFI_PAGE_SIZE) ? \
+ Length >> EFI_PAGE_SHIFT : 1;
+  ChangeMemoryPermissionsSvcArgs.Arg3 = Permissions;
+
+  ArmCallSvc ();
+
+  Status = ChangeMemoryPermissionsSvcArgs.Arg0;
+
+  switch (Status) {
+  case ARM_SVC_SPM_RET_SUCCESS:
+Status = EFI_SUCCESS;
+break;
+
+  case ARM_SVC_SPM_RET_NOT_SUPPORTED:
+Status = EFI_UNSUPPORTED;
+break;
+
+  case ARM_SVC_SPM_RET_INVALID_PARAMS:
+Status = EFI_INVALID_PARAMETER;
+break;
+
+  case ARM_SVC_SPM_RET_DENIED:
+Status = EFI_ACCESS_DENIED;
+break;
+
+  case ARM_SVC_SPM_RET_NO_MEMORY:
+Status = EFI_BAD_BUFFER_SIZE;
+break;
+
+  default:
+Status = EFI_ACCESS_DENIED;
+ASSERT (0);
+  }
+
+  return Status;
+}
+
+EFI_STATUS
+ArmSetMemoryRegionNoExec (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  )
+{
+  EFI_STATUSStatus;
+  UINT32 MemoryAttributes;
+
+  Status = GetMemoryPermissions (BaseAddress, );
+  if (Status != EFI_INVALID_PARAMETER) {
+return RequestMemoryPermissionChange (BaseAddress,
+  Length,
+  MemoryAttributes |
+  (SET_MEM_ATTR_CODE_PERM_XN << 
SET_MEM_ATTR_CODE_PERM_SHIFT));
+  }
+  return EFI_INVALID_PARAMETER;
+}
+
+EFI_STATUS
+ArmClearMemoryRegionNoExec (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  )
+{
+  EFI_STATUSStatus;
+  UINT32 MemoryAttributes;
+
+  Status = GetMemoryPermissions (BaseAddress, );
+  if (Status != EFI_INVALID_PARAMETER) {
+return 

[edk2] [PATCH 0/6] ArmPkg related changes for StandaloneMM package

[Supreeth Venkatesh]

The following patch series adds support for Management Mode related
changes for aarch64 based platforms.

Note: This patch series needs to be applied after applying
Standalone Management Mode core interface support for aarch64
platforms[1]

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

Supreeth Venkatesh (6):
  ArmPkg: Add PCDs needed for MM communication driver.
  ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
  ArmPkg/Include: Add MM interface SVC return codes.
  ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.
  ArmPkg/ArmMmuLib: Add MMU library inf file suitable for use in S-EL0.
  ArmPkg: Extra action to update permissions for S-ELO MM Image.

 ArmPkg/ArmPkg.dec  |   3 +
 .../Drivers/MmCommunicationDxe/MmCommunication.c   | 408 +
 .../Drivers/MmCommunicationDxe/MmCommunication.inf |  50 +++
 ArmPkg/Include/IndustryStandard/ArmMmSvc.h |   9 +-
 .../ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c  | 195 ++
 .../ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf|  37 ++
 .../DebugPeCoffExtraActionLib.c| 185 +-
 .../DebugPeCoffExtraActionLib.inf  |   7 +
 8 files changed, 882 insertions(+), 12 deletions(-)
 create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
 create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
 create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuStandaloneMmCoreLib.c
 create mode 100644 ArmPkg/Library/ArmMmuLib/ArmMmuStandaloneMmCoreLib.inf

-- 
2.7.4


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

[edk2] [PATCH 3/6] ArmPkg/Include: Add MM interface SVC return codes.

[Supreeth Venkatesh]

This patch adds the Management Mode(MM) - Secure Partition
Manager(SPM) SVC return codes.

Also, It corrects SVC ID for retrieving SPM version information.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 ArmPkg/Include/IndustryStandard/ArmMmSvc.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h 
b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
index 4c7b6c3..a64b9ec 100644
--- a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
+++ b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
@@ -20,7 +20,7 @@
  * delegated events and request the Secure partition manager to perform
  * privileged operations on its behalf.
  */
-#define ARM_SVC_ID_SPM_VERSION_AARCH64 0xC460
+#define ARM_SVC_ID_SPM_VERSION_AARCH32 0x8460
 #define ARM_SVC_ID_SP_EVENT_COMPLETE_AARCH64   0xC461
 #define ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64   0xC464
 #define ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64   0xC465
@@ -40,4 +40,11 @@
 c_perm) & SET_MEM_ATTR_CODE_PERM_MASK) << 
SET_MEM_ATTR_CODE_PERM_SHIFT) | \
 (( (d_perm) & SET_MEM_ATTR_DATA_PERM_MASK) << 
SET_MEM_ATTR_DATA_PERM_SHIFT))
 
+/* MM SVC Return error codes */
+#define ARM_SVC_SPM_RET_SUCCESS   0
+#define ARM_SVC_SPM_RET_NOT_SUPPORTED-1
+#define ARM_SVC_SPM_RET_INVALID_PARAMS   -2
+#define ARM_SVC_SPM_RET_DENIED   -3
+#define ARM_SVC_SPM_RET_NO_MEMORY-5
+
 #endif
-- 
2.7.4

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

[edk2] [PATCH 2/6] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.

[Supreeth Venkatesh]

PI v1.5 Specification Volume 4 defines Management Mode Core Interface
and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
means of communicating between drivers outside of MM and MMI
handlers inside of MM.

This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE runtime
driver for AARCH64 platforms. It uses SMCs allocated from the standard
SMC range defined in DEN0060A_ARM_MM_Interface_Specification.pdf
to communicate with the standalone MM environment in the secure world.

This patch also adds the MM Communication driver (.inf) file to
define entry point for this driver and other compile
related information the driver needs.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 .../Drivers/MmCommunicationDxe/MmCommunication.c   | 408 +
 .../Drivers/MmCommunicationDxe/MmCommunication.inf |  50 +++
 2 files changed, 458 insertions(+)
 create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
 create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf

diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c 
b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
new file mode 100644
index 000..8ba1790
--- /dev/null
+++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
@@ -0,0 +1,408 @@
+/** @file
+
+  Copyright (c) 2016-2018, ARM Limited. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#define MM_MAJOR_VER_MASK0x
+#define MM_MINOR_VER_MASK0x
+#define MM_MAJOR_VER_SHIFT   16
+
+const UINT32 MM_MAJOR_VER = 1;
+const UINT32 MM_MINOR_VER = 0;
+
+//
+// Address, Length of the pre-allocated buffer for communication with the 
secure
+// world.
+//
+STATIC ARM_MEMORY_REGION_DESCRIPTOR  mNsCommBuffMemRegion;
+
+// Notification event when virtual address map is set.
+STATIC EFI_EVENT  mSetVirtualAddressMapEvent;
+
+//
+// Handle to install the MM Communication Protocol
+//
+STATIC EFI_HANDLE  mMmCommunicateHandle;
+
+/**
+  Communicates with a registered handler.
+
+  This function provides an interface to send and receive messages to the
+  Standalone MM environment on behalf of UEFI services.  This function is part
+  of the MM Communication Protocol that may be called in physical mode prior to
+  SetVirtualAddressMap() and in virtual mode after SetVirtualAddressMap().
+
+  @param[in]  ThisThe EFI_MM_COMMUNICATION_PROTOCOL
+  instance.
+  @param[in, out] CommBuffer  A pointer to the buffer to convey
+  into MMRAM.
+  @param[in, out] CommSizeThe size of the data buffer being
+  passed in. This is optional.
+
+  @retval EFI_SUCCESS The message was successfully posted.
+  @retval EFI_INVALID_PARAMETER   The CommBuffer was NULL.
+  @retval EFI_BAD_BUFFER_SIZE The buffer size is incorrect for the MM
+  implementation. If this error is
+  returned, the MessageLength field in
+  the CommBuffer header or the integer
+  pointed by CommSize are updated to 
reflect
+  the maximum payload size the
+  implementation can accommodate.
+  @retval EFI_ACCESS_DENIED   The CommunicateBuffer parameter
+  or CommSize parameter, if not omitted,
+  are in address range that cannot be
+  accessed by the MM environment
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+MmCommunicationCommunicate (
+  IN CONST EFI_MM_COMMUNICATION_PROTOCOL  *This,
+  IN OUT VOID *CommBuffer,
+  IN OUT UINTN*CommSize OPTIONAL
+  )
+{
+  EFI_MM_COMMUNICATE_HEADER   *CommunicateHeader;
+  ARM_SMC_ARGSCommunicateSmcArgs;
+  EFI_STATUS  Status;
+  UINTN   BufferSize;
+
+  Status = EFI_ACCESS_DENIED;
+  BufferSize = 0;
+
+  ZeroMem (, sizeof (ARM_SMC_ARGS));
+
+  //
+  // Check parameters
+  //
+  if (CommBuffer == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  CommunicateHeader = CommBuffer;
+  // CommBuffer is a 

Re: [edk2] [PATCH edk2-platforms v1 1/6] Hisilicon/D0x: Fix invoke SetMemorySpaceAttributes error bug

[Ming]

在 27/06/2018 15:20, Ard Biesheuvel 写道:
> On 27 June 2018 at 09:04, Ming Huang  wrote:
>> The edk2 commit bacfd6e let CpuDxe running latter. CpuDxe should run early.
>> CpuDxe is needed by gDS->SetMemorySpaceAttributes, and
>> gDS->SetMemorySpaceAttributes is invoked by several drivers.
>>
>> Add several drives to APRIORI scope for implementing the ordering.
>>
> 
> Please solve this by adding DEPEXes on gEfiCpuArchProtocolGuid to the
> drivers in question.
> 

If solve this by adding depexes, there are many drivers which should add
depexes.

CpuDxe depend on ArmGicDxe
SfcDxeDriver and RealTimeClockRuntimeDxe depend on CpuDxe
VariableRuntimeDxe depend on SfcDxeDriver
and many other drivers depend on VariableRuntimeDxe
Should I add depexes to these drivers? Especially,RealTimeClockRuntimeDxe
is in edk2/EmbeddedPkg. Why does other platforms do not have this problem?

Thanks.

>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> Signed-off-by: Heyi Guo 
>> ---
>>  Platform/Hisilicon/D03/D03.fdf | 10 +-
>>  Platform/Hisilicon/D05/D05.fdf |  6 +-
>>  2 files changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/D03/D03.fdf b/Platform/Hisilicon/D03/D03.fdf
>> index 1383aa1091..027b53a6cf 100644
>> --- a/Platform/Hisilicon/D03/D03.fdf
>> +++ b/Platform/Hisilicon/D03/D03.fdf
>> @@ -146,6 +146,14 @@ READ_STATUS= TRUE
>>  READ_LOCK_CAP  = TRUE
>>  READ_LOCK_STATUS   = TRUE
>>
>> +  APRIORI DXE {
>> +INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>> +INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>> +INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
>> +INF Platform/Hisilicon/D05/Drivers/SFC/SfcDxeDriver.inf
>> +INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>> +  }
>> +
>>INF MdeModulePkg/Core/Dxe/DxeMain.inf
>>INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>>
>> @@ -153,6 +161,7 @@ READ_LOCK_STATUS   = TRUE
>>#
>># PI DXE Drivers producing Architectural Protocols (EFI Services)
>>#
>> +  INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>>INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
>>INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>>
>> @@ -186,7 +195,6 @@ READ_LOCK_STATUS   = TRUE
>>
>># Simple TextIn/TextOut for UEFI Terminal
>>
>> -  INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>>INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
>>
>>INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>> diff --git a/Platform/Hisilicon/D05/D05.fdf b/Platform/Hisilicon/D05/D05.fdf
>> index 4503776d63..37d9cc0c18 100644
>> --- a/Platform/Hisilicon/D05/D05.fdf
>> +++ b/Platform/Hisilicon/D05/D05.fdf
>> @@ -148,6 +148,10 @@ READ_LOCK_STATUS   = TRUE
>>
>>APRIORI DXE {
>>  INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>> +INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>> +INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
>> +INF Platform/Hisilicon/D05/Drivers/SFC/SfcDxeDriver.inf
>> +INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>>}
>>
>>INF MdeModulePkg/Core/Dxe/DxeMain.inf
>> @@ -157,6 +161,7 @@ READ_LOCK_STATUS   = TRUE
>>#
>># PI DXE Drivers producing Architectural Protocols (EFI Services)
>>#
>> +  INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>>INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
>>INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>>
>> @@ -190,7 +195,6 @@ READ_LOCK_STATUS   = TRUE
>>
>># Simple TextIn/TextOut for UEFI Terminal
>>
>> -  INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>>INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
>>
>>INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>> --
>> 2.17.0
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/BaseLib: Add bit field Hamming weight calculation methods

[Tomas Pilar (tpilar)]

Thanks for suggestions. The answer to your comments is that I copied the look 
and feel of the other bitfield functions.

The extra assert is mentioned in the documentation for the other bitfield 
functions even though it just follows from the other two asserts - for clarity 
I suppose.

I agree that a pure function would be simpler and more elegant, but the rest of 
the bitfield functions allow you to operate on a specific part of the operand 
(e.g. BitFieldAnd32(Operand, StartBit, EndBit, AndData)), so I reasoned that 
the API should be kept similar.

I found two names for this functionality, population count and hamming weight 
and both are used (Linux kernel uses hamming weight). I don't mind using 
PopCount if you think it's more clear.

The other issue seems a problem with line endings.

Cheers,
Tom


On 02/07/18 19:57, Evan Lloyd wrote:
> Hi Tomas
> I'm not a maintainer here, so my comments are just that and carry no weight 
> beyond making suggestions that you may wish to consider.
>
>> -Original Message-
>> From: edk2-devel  On Behalf Of Tomas
>> Pilar (tpilar)
>> Sent: 29 June 2018 10:42
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] [PATCH] MdePkg/BaseLib: Add bit field Hamming weight
>> calculation methods
>>
>> Add 32-bit and 64-bit functions that count number of set bits in a bitfield
>> using the divide-and-count method.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Tomas Pilar 
>> ---
>>  MdePkg/Include/Library/BaseLib.h  | 56 +++
>> MdePkg/Library/BaseLib/BitField.c | 79
>> +++
>>  2 files changed, 135 insertions(+)
>>
>> diff --git a/MdePkg/Include/Library/BaseLib.h
>> b/MdePkg/Include/Library/BaseLib.h
>> index 1db3a04..7eb0488 100644
>> --- a/MdePkg/Include/Library/BaseLib.h
>> +++ b/MdePkg/Include/Library/BaseLib.h
>> @@ -4609,6 +4609,62 @@ BitFieldAndThenOr64 (
>>IN  UINT64OrData
>>);
>>
>> +/**
>> +  Reads a bit field from a 32-bit value, counts and returns
>> +  the number of set bits.
>> +
>> +  Counts the number of set bits in the  bit field specified by
>> + StartBit and EndBit in Operand. The count is returned.
>> +
>> +  If StartBit is greater than 31, then ASSERT().
>> +  If EndBit is greater than 31, then ASSERT().
>> +  If EndBit is less than StartBit, then ASSERT().
>> +
>> +  @param  Operand   Operand on which to perform the bitfield operation.
>> +  @param  StartBit  The ordinal of the least significant bit in the bit 
>> field.
>> +Range 0..31.
>> +  @param  EndBitThe ordinal of the most significant bit in the bit 
>> field.
>> +Range 0..31.
>> +
>> +  @return The number of bits set between StartBit and EndBit.
>> +
>> +**/
>> +UINT8
>> +EFIAPI
>> +BitFieldHammingWeight32 (
>> +  IN   UINT32   Operand,
>> +  IN   UINTNStartBit,
>> +  IN   UINTNEndBit
>> +  );
>> +
>  [[Evan Lloyd]] I can see the benefit of a "CountOnes" function, but why not 
> call it that (or similar)?  (I had to look up "HammingWeight")
> Also, why conflate BitField access and CountOnes in one function?  A "pure" 
> function to count ones might be used in other ways, and it is fairly clear if 
> you write:
> CountOnes(BitFieldRead64 (Operand, StartBit, EndBit));
>
>
>> +/**
>> +   Reads a bit field from a 64-bit value, counts and returns
>> +   the number of set bits.
>> +
>> +   Counts the number of set bits in the  bit field specified by
>> +   StartBit and EndBit in Operand. The count is returned.
>> +
>> +   If StartBit is greater than 63, then ASSERT().
>> +   If EndBit is greater than 63, then ASSERT().
>> +   If EndBit is less than StartBit, then ASSERT().
>> +
>> +   @param  Operand   Operand on which to perform the bitfield operation.
>> +   @param  StartBit  The ordinal of the least significant bit in the bit 
>> field.
>> +   Range 0..63.
>> +   @param  EndBitThe ordinal of the most significant bit in the bit 
>> field.
>> +   Range 0..63.
>> +
>> +   @return The number of bits set between StartBit and EndBit.
>> +
>> +**/
>> +UINT8
>> +EFIAPI
>> +BitFieldHammingWeight64 (
>> +  IN   UINT64   Operand,
>> +  IN   UINTNStartBit,
>> +  IN   UINTNEndBit
>> +  );
>> +
>>  //
>>  // Base Library Checksum Functions
>>  //
>> diff --git a/MdePkg/Library/BaseLib/BitField.c
>> b/MdePkg/Library/BaseLib/BitField.c
>> index d2d3150..af06db8 100644
>> --- a/MdePkg/Library/BaseLib/BitField.c
>> +++ b/MdePkg/Library/BaseLib/BitField.c
>> @@ -920,3 +920,82 @@ BitFieldAndThenOr64 (
>> OrData
>> );
>>  }
>> +
>> +/**
>> +  Reads a bit field from a 32-bit value, counts and returns
>> +  the number of set bits.
>> +
>> +  Counts the number of set bits in the  bit field specified by
>> + StartBit and EndBit in Operand. The count is returned.
>> +
>> +  If StartBit 

[edk2] [PATCH 10/10] StandaloneMmPkg: Describe the declaration and definition files.

[Supreeth Venkatesh]

This patch describes the package declarations and definitions
for creating standalone management mode image with
core/foundation and drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
Reviewed-by: Achin Gupta 
Reviewed-by: Jiewen Yao 
Cc: Jiewen Yao 
Cc: Achin Gupta 
---
 StandaloneMmPkg/StandaloneMmPkg.dec |  47 +
 StandaloneMmPkg/StandaloneMmPkg.dsc | 130 
 2 files changed, 177 insertions(+)
 create mode 100644 StandaloneMmPkg/StandaloneMmPkg.dec
 create mode 100644 StandaloneMmPkg/StandaloneMmPkg.dsc

diff --git a/StandaloneMmPkg/StandaloneMmPkg.dec 
b/StandaloneMmPkg/StandaloneMmPkg.dec
new file mode 100644
index 000..3410837
--- /dev/null
+++ b/StandaloneMmPkg/StandaloneMmPkg.dec
@@ -0,0 +1,47 @@
+## @file
+# This package is a platform package that provide platform module/library
+# required by Standalone MM platform.
+#
+# Copyright (c) 2016-2018, ARM Ltd. All rights reserved.
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD 
License
+# which accompanies this distribution. The full text of the license may be 
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+#
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = StandaloneMmPkg
+  PACKAGE_GUID   = 2AE82968-7769-4A85-A5BC-A0954CE54A5C
+  PACKAGE_VERSION= 1.0
+
+[Includes]
+  Include
+
+[LibraryClasses]
+
+[Guids]
+  gStandaloneMmPkgTokenSpaceGuid   = { 0x18fe7632, 0xf5c8, 0x4e63, { 
0x8d, 0xe8, 0x17, 0xa5, 0x5c, 0x59, 0x13, 0xbd }}
+  gMpInformationHobGuid= { 0xba33f15d, 0x4000, 0x45c1, { 
0x8e, 0x88, 0xf9, 0x16, 0x92, 0xd4, 0x57, 0xe3 }}
+  gMmFvDispatchGuid= { 0xb65694cc, 0x09e3, 0x4c3b, { 
0xb5, 0xcd, 0x05, 0xf4, 0x4d, 0x3c, 0xdb, 0xff }}
+
+  ## Include/Guid/MmCoreData.h
+  gMmCoreDataHobGuid   = { 0xa160bf99, 0x2aa4, 0x4d7d, { 
0x99, 0x93, 0x89, 0x9c, 0xb1, 0x2d, 0xf3, 0x76 }}
+
+  ## Include/Guid/MmramMemoryReserve.h
+  gEfiMmPeiMmramMemoryReserveGuid  = { 0x0703f912, 0xbf8d, 0x4e2a, { 
0xbe, 0x07, 0xab, 0x27, 0x25, 0x25, 0xc5, 0x92 }}
+
+  gEfiStandaloneMmNonSecureBufferGuid  = { 0xf00497e3, 0xbfa2, 0x41a1, { 
0x9d, 0x29, 0x54, 0xc2, 0xe9, 0x37, 0x21, 0xc5 }}
+  gEfiArmTfCpuDriverEpDescriptorGuid   = { 0x6ecbd5a1, 0xc0f8, 0x4702, { 
0x83, 0x01, 0x4f, 0xc2, 0xc5, 0x47, 0x0a, 0x51 }}
+
+[PcdsFeatureFlag]
+  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|FALSE|BOOLEAN|0x0001
+
+[Protocols]
+  gEfiMmConfigurationProtocolGuid  = { 0xc109319, 0xc149, 0x450e,  { 
0xa3, 0xe3, 0xb9, 0xba, 0xdd, 0x9d, 0xc3, 0xa4 }}
+
diff --git a/StandaloneMmPkg/StandaloneMmPkg.dsc 
b/StandaloneMmPkg/StandaloneMmPkg.dsc
new file mode 100644
index 000..c6ddb35
--- /dev/null
+++ b/StandaloneMmPkg/StandaloneMmPkg.dsc
@@ -0,0 +1,130 @@
+## @file
+# Standalone MM Platform.
+#
+# Copyright (c) 2015, Intel Corporation. All rights reserved.
+# Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+#
+#This program and the accompanying materials
+#are licensed and made available under the terms and conditions of the BSD 
License
+#which accompanies this distribution. The full text of the license may be 
found at
+#http://opensource.org/licenses/bsd-license.php
+#
+#THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = StandaloneMm
+  PLATFORM_GUID  = 9A4BBA60-B4F9-47C7-9258-3BD77CAE9322
+  PLATFORM_VERSION   = 1.0
+  DSC_SPECIFICATION  = 0x00010011
+  OUTPUT_DIRECTORY   = Build/StandaloneMm
+  SUPPORTED_ARCHITECTURES= IA32|X64|AARCH64
+  BUILD_TARGETS  = DEBUG|RELEASE
+  SKUID_IDENTIFIER   = DEFAULT
+
+  # LzmaF86
+  DEFINE COMPRESSION_TOOL_GUID   = D42AE6BD-1352-4bfb-909A-CA72A6EAE889
+
+
+#
+# Library Class section - list of all Library Classes needed by this Platform.
+#
+
+[LibraryClasses]
+  #
+  # Basic
+  #
+  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+  

[edk2] [PATCH 06/10] StandaloneMmPkg: MM driver entry point library.

[Supreeth Venkatesh]

This patch implements module entry point library for Standalone
management mode (MM) Drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
Reviewed-by: Achin Gupta 
Reviewed-by: Jiewen Yao 
Cc: Jiewen Yao 
Cc: Achin Gupta 
---
 .../Include/Library/StandaloneMmDriverEntryPoint.h | 148 +
 .../StandaloneMmDriverEntryPoint.c |  99 ++
 .../StandaloneMmDriverEntryPoint.inf   |  41 ++
 3 files changed, 288 insertions(+)
 create mode 100644 
StandaloneMmPkg/Include/Library/StandaloneMmDriverEntryPoint.h
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf

diff --git a/StandaloneMmPkg/Include/Library/StandaloneMmDriverEntryPoint.h 
b/StandaloneMmPkg/Include/Library/StandaloneMmDriverEntryPoint.h
new file mode 100644
index 000..4c93c16
--- /dev/null
+++ b/StandaloneMmPkg/Include/Library/StandaloneMmDriverEntryPoint.h
@@ -0,0 +1,148 @@
+/** @file
+  Module entry point library for Standalone MM Drivers.
+
+Copyright (c) 2006 - 2008, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __MODULE_ENTRY_POINT_H__
+#define __MODULE_ENTRY_POINT_H__
+
+///
+///Declare the PI Specification Revision that this driver requires to execute 
correctly.
+///
+extern CONST UINT32   _gMmRevision;
+
+/**
+  The entry point of PE/COFF Image for a Standalone MM Driver.
+
+  This function is the entry point for a Standalone MM Driver.
+  This function must call ProcessLibraryConstructorList() and
+  ProcessModuleEntryPointList().
+  If the return status from ProcessModuleEntryPointList()
+  is an error status, then ProcessLibraryDestructorList() must be called.
+  The return value from ProcessModuleEntryPointList() is returned.
+  If _gDriverUnloadImageCount is greater
+  than zero, then an unload handler must be registered for this image and
+  the unload handler must invoke ProcessModuleUnloadList().
+  If _gUefiDriverRevision is not zero and SystemTable->Hdr.Revision is
+  less than _gUefiDriverRevison, then return EFI_INCOMPATIBLE_VERSION.
+
+  @param  ImageHandle  The image handle of the Standalone MM Driver.
+  @param  SystemTable  A pointer to the EFI System Table.
+
+  @retval  EFI_SUCCESS   The Standalone MM Driver exited normally.
+  @retval  EFI_INCOMPATIBLE_VERSION  _gUefiDriverRevision is greater than
+ SystemTable->Hdr.Revision.
+  @retval  Other Return value from
+ ProcessModuleEntryPointList().
+
+**/
+EFI_STATUS
+EFIAPI
+_ModuleEntryPoint (
+  IN EFI_HANDLE ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE*MmSystemTable
+  );
+
+
+/**
+  Required by the EBC compiler and identical in functionality to 
_ModuleEntryPoint().
+
+  This function is required to call _ModuleEntryPoint() passing in 
ImageHandle, and SystemTable.
+
+  @param  ImageHandle  The image handle of the Standalone MM Driver.
+  @param  SystemTable  A pointer to the EFI System Table.
+
+  @retval  EFI_SUCCESS   The Standalone MM Driver exited normally.
+  @retval  EFI_INCOMPATIBLE_VERSION  _gUefiDriverRevision is greater than
+ SystemTable->Hdr.Revision.
+  @retval  Other Return value from 
ProcessModuleEntryPointList().
+**/
+EFI_STATUS
+EFIAPI
+EfiMain (
+  IN EFI_HANDLE ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE*MmSystemTable
+  );
+
+/**
+  Auto generated function that calls the library constructors for all of the 
module's
+  dependent libraries.
+
+  This function must be called by _ModuleEntryPoint().
+  This function calls the set of library constructors for the set of library 
instances
+  that a module depends on.  This includes library instances that a module 
depends on
+  directly and library instances that a module depends on indirectly through 
other libraries.
+  This function is auto generated by build tools and those build tools are 
responsible
+  for collecting the set of library instances, determine which ones have 
constructors,
+  and calling the library constructors in the proper order based upon each of 
the library
+  instances own dependencies.
+
+  @param  ImageHandle  The image handle of the Standalone MM Driver.
+  @param  SystemTable  A pointer to the EFI System Table.
+
+**/
+VOID

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

[Supreeth Venkatesh]

The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
Platforms and is initialised during the SEC phase. ARM Trusted firmware
in EL3 is responsible for initialising the architectural context for
S-EL0 and loading the Standalone MM image. The memory allocated to this
image is marked as RO+X. Heap memory is marked as RW+XN.

Certain actions have to be completed prior to executing the generic code
in the Standalone MM Core module. These are:

1. Memory permission attributes for each section of the Standalone MM
   Core module need to be changed prior to accessing any RW data.

2. A Hob list has to be created with information that allows the MM
   environment to initialise and dispatch drivers.

Furthermore, this module is responsible for handing over runtime MM
events to the Standalone MM CPU driver and returning control to ARM
Trusted Firmware upon event completion. Hence it needs to know the CPU
driver entry point.

This patch implements an entry point module that ARM Trusted Firmware
jumps to in S-EL0. It then performs the above actions before calling the
Standalone MM Foundation entry point and handling subsequent MM events.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
Cc: Jiewen Yao 
Cc: Achin Gupta 
---
 .../Library/AArch64/StandaloneMmCoreEntryPoint.h   | 214 +++
 .../AArch64/CreateHobList.c| 200 ++
 .../AArch64/SetPermissions.c   | 275 
 .../AArch64/StandaloneMmCoreEntryPoint.c   | 287 +
 .../StandaloneMmCoreEntryPoint.inf |  55 
 5 files changed, 1031 insertions(+)
 create mode 100644 
StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/CreateHobList.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf

diff --git 
a/StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h 
b/StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h
new file mode 100644
index 000..6eb74af
--- /dev/null
+++ b/StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h
@@ -0,0 +1,214 @@
+/** @file
+  Entry point to the Standalone MM Foundation when initialized during the SEC
+  phase on ARM platforms
+
+Copyright (c) 2017 - 2018, ARM Ltd. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __STANDALONEMMCORE_ENTRY_POINT_H__
+#define __STANDALONEMMCORE_ENTRY_POINT_H__
+
+#include 
+#include 
+
+#define CPU_INFO_FLAG_PRIMARY_CPU  0x0001
+
+typedef struct {
+  UINT8  Type;   /* type of the structure */
+  UINT8  Version;/* version of this structure */
+  UINT16 Size;  /* size of this structure in bytes */
+  UINT32 Attr;  /* attributes: unused bits SBZ */
+} EFI_PARAM_HEADER;
+
+typedef struct {
+  UINT64 Mpidr;
+  UINT32 LinearId;
+  UINT32 Flags;
+} EFI_SECURE_PARTITION_CPU_INFO;
+
+typedef struct {
+  EFI_PARAM_HEADER  Header;
+  UINT64SpMemBase;
+  UINT64SpMemLimit;
+  UINT64SpImageBase;
+  UINT64SpStackBase;
+  UINT64SpHeapBase;
+  UINT64SpNsCommBufBase;
+  UINT64SpSharedBufBase;
+  UINT64SpImageSize;
+  UINT64SpPcpuStackSize;
+  UINT64SpHeapSize;
+  UINT64SpNsCommBufSize;
+  UINT64SpPcpuSharedBufSize;
+  UINT32NumSpMemRegions;
+  UINT32NumCpus;
+  EFI_SECURE_PARTITION_CPU_INFO *CpuInfo;
+} EFI_SECURE_PARTITION_BOOT_INFO;
+
+typedef
+EFI_STATUS
+(*PI_MM_ARM_TF_CPU_DRIVER_ENTRYPOINT) (
+  IN UINTN EventId,
+  IN UINTN CpuNumber,
+  IN UINTN NsCommBufferAddr
+  );
+
+typedef struct {
+  PI_MM_ARM_TF_CPU_DRIVER_ENTRYPOINT *ArmTfCpuDriverEpPtr;
+} ARM_TF_CPU_DRIVER_EP_DESCRIPTOR;
+
+typedef RETURN_STATUS (*REGION_PERMISSION_UPDATE_FUNC) (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  );
+
+/**
+  Privileged firmware assigns RO & Executable attributes to all memory occupied
+  by the Boot Firmware Volume. This 

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

[Supreeth Venkatesh]

This patch adds a simple CPU driver that exports the
EFI_MM_CONFIGURATION_PROTOCOL to allow registration of the Standalone
MM Foundation entry point. It preserves the existing notification
mechanism for the configuration protocol.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
Cc: Jiewen Yao 
Cc: Achin Gupta 
---
 .../Drivers/StandaloneMmCpu/AArch64/EventHandle.c  | 208 +++
 .../StandaloneMmCpu/AArch64/StandaloneMmCpu.c  | 219 +
 .../StandaloneMmCpu/AArch64/StandaloneMmCpu.h  |  64 ++
 .../StandaloneMmCpu/AArch64/StandaloneMmCpu.inf|  59 ++
 StandaloneMmPkg/Include/Guid/MpInformation.h   |  41 
 5 files changed, 591 insertions(+)
 create mode 100644 
StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c
 create mode 100644 
StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.c
 create mode 100644 
StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.h
 create mode 100644 
StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
 create mode 100644 StandaloneMmPkg/Include/Guid/MpInformation.h

diff --git a/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c 
b/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c
new file mode 100644
index 000..5f39216
--- /dev/null
+++ b/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/EventHandle.c
@@ -0,0 +1,208 @@
+/** @file
+
+  Copyright (c) 2016 HP Development Company, L.P.
+  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include  // for EFI_SYSTEM_CONTEXT
+
+#include 
+#include 
+
+#include 
+
+#include "StandaloneMmCpu.h"
+
+EFI_STATUS
+EFIAPI
+MmFoundationEntryRegister(
+  IN CONST EFI_MM_CONFIGURATION_PROTOCOL  *This,
+  IN EFI_MM_ENTRY_POINTMmEntryPoint
+  );
+
+//
+// On ARM platforms every event is expected to have a GUID associated with
+// it. It will be used by the MM Entry point to find the handler for the
+// event. It will either be populated in a EFI_MM_COMMUNICATE_HEADER by the
+// caller of the event (e.g. MM_COMMUNICATE SMC) or by the CPU driver
+// (e.g. during an asynchronous event). In either case, this context is
+// maintained in an array which has an entry for each CPU. The pointer to this
+// array is held in PerCpuGuidedEventContext. Memory is allocated once the
+// number of CPUs in the system are made known through the
+// MP_INFORMATION_HOB_DATA.
+//
+EFI_MM_COMMUNICATE_HEADER **PerCpuGuidedEventContext = NULL;
+
+// Descriptor with whereabouts of memory used for communication with the 
normal world
+EFI_MMRAM_DESCRIPTOR  mNsCommBuffer;
+
+MP_INFORMATION_HOB_DATA *mMpInformationHobData;
+
+EFI_MM_CONFIGURATION_PROTOCOL mMmConfig = {
+  0,
+  MmFoundationEntryRegister
+};
+
+static EFI_MM_ENTRY_POINT mMmEntryPoint = NULL;
+
+EFI_STATUS
+PiMmStandloneArmTfCpuDriverEntry (
+  IN UINTN EventId,
+  IN UINTN CpuNumber,
+  IN UINTN NsCommBufferAddr
+  )
+{
+  EFI_MM_COMMUNICATE_HEADER *GuidedEventContext = NULL;
+  EFI_MM_ENTRY_CONTEXTMmEntryPointContext = {0};
+  EFI_STATUS  Status;
+  UINTN   NsCommBufferSize;
+
+  DEBUG ((DEBUG_INFO, "Received event - 0x%x on cpu %d\n", EventId, 
CpuNumber));
+
+  Status = EFI_SUCCESS;
+  //
+  // ARM TF passes SMC FID of the MM_COMMUNICATE interface as the Event ID upon
+  // receipt of a synchronous MM request. Use the Event ID to distinguish
+  // between synchronous and asynchronous events.
+  //
+  if (ARM_SMC_ID_MM_COMMUNICATE_AARCH64 != EventId) {
+DEBUG ((DEBUG_INFO, "UnRecognized Event - 0x%x\n", EventId));
+return EFI_INVALID_PARAMETER;
+  } else {
+// Perform parameter validation of NsCommBufferAddr
+
+if (NsCommBufferAddr && (NsCommBufferAddr < mNsCommBuffer.PhysicalStart))
+  return EFI_ACCESS_DENIED;
+
+// Find out the size of the buffer passed
+NsCommBufferSize = ((EFI_MM_COMMUNICATE_HEADER *) 
NsCommBufferAddr)->MessageLength +
+sizeof(((EFI_MM_COMMUNICATE_HEADER 
*)NsCommBufferAddr)->MessageLength) +
+sizeof(((EFI_MM_COMMUNICATE_HEADER 
*)NsCommBufferAddr)->HeaderGuid);
+
+// perform bounds check.
+if (NsCommBufferAddr + NsCommBufferSize >=
+  mNsCommBuffer.PhysicalStart + mNsCommBuffer.PhysicalSize)
+return EFI_ACCESS_DENIED;
+
+
+// Now that the secure world can see the normal world buffer, allocate
+   

[edk2] [PATCH 05/10] StandaloneMmPkg/HobLib: Add HOB Library for management mode.

[Supreeth Venkatesh]

The Standalone MM environment is initialized during the SEC phase on ARM
Standard Platforms. The MM Core driver implements an entry point module
which is architecture specific and runs prior to the generic core driver
code. The former creates a Hob list that the latter consumes. This
happens in the same phase.

This patch implements a Hob library that can be used by the entry point
module to produce a Hob list and by the core driver code to consume it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
Reviewed-by: Jiewen Yao 
Cc: Jiewen Yao 
Cc: Achin Gupta 
---
 .../AArch64/StandaloneMmCoreHobLibInternal.c   |  64 +++
 .../StandaloneMmCoreHobLib.c   | 608 +
 .../StandaloneMmCoreHobLib.inf |  47 ++
 3 files changed, 719 insertions(+)
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreHobLib/AArch64/StandaloneMmCoreHobLibInternal.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf

diff --git 
a/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/AArch64/StandaloneMmCoreHobLibInternal.c
 
b/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/AArch64/StandaloneMmCoreHobLibInternal.c
new file mode 100644
index 000..ac5a1c0
--- /dev/null
+++ 
b/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/AArch64/StandaloneMmCoreHobLibInternal.c
@@ -0,0 +1,64 @@
+/** @file
+  HOB Library implementation for Standalone MM Core.
+
+Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+//
+// Cache copy of HobList pointer.
+//
+extern VOID *gHobList;
+
+EFI_HOB_HANDOFF_INFO_TABLE*
+HobConstructor (
+  IN VOID   *EfiMemoryBegin,
+  IN UINTN  EfiMemoryLength,
+  IN VOID   *EfiFreeMemoryBottom,
+  IN VOID   *EfiFreeMemoryTop
+  )
+{
+  EFI_HOB_HANDOFF_INFO_TABLE  *Hob;
+  EFI_HOB_GENERIC_HEADER  *HobEnd;
+
+  Hob= EfiFreeMemoryBottom;
+  HobEnd = (EFI_HOB_GENERIC_HEADER *)(Hob+1);
+
+  Hob->Header.HobType = EFI_HOB_TYPE_HANDOFF;
+  Hob->Header.HobLength   = sizeof(EFI_HOB_HANDOFF_INFO_TABLE);
+  Hob->Header.Reserved= 0;
+
+  HobEnd->HobType = EFI_HOB_TYPE_END_OF_HOB_LIST;
+  HobEnd->HobLength   = sizeof(EFI_HOB_GENERIC_HEADER);
+  HobEnd->Reserved= 0;
+
+  Hob->Version = EFI_HOB_HANDOFF_TABLE_VERSION;
+  Hob->BootMode= BOOT_WITH_FULL_CONFIGURATION;
+
+  Hob->EfiMemoryTop= (UINTN)EfiMemoryBegin + EfiMemoryLength;
+  Hob->EfiMemoryBottom = (UINTN)EfiMemoryBegin;
+  Hob->EfiFreeMemoryTop= (UINTN)EfiFreeMemoryTop;
+  Hob->EfiFreeMemoryBottom = (EFI_PHYSICAL_ADDRESS)(UINTN)(HobEnd+1);
+  Hob->EfiEndOfHobList = (EFI_PHYSICAL_ADDRESS)(UINTN)HobEnd;
+
+  gHobList = Hob;
+
+  return Hob;
+}
diff --git 
a/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.c 
b/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.c
new file mode 100644
index 000..e1ad257
--- /dev/null
+++ b/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.c
@@ -0,0 +1,608 @@
+/** @file
+  HOB Library implementation for Standalone MM Core.
+
+Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+//
+// Cache copy of HobList pointer.
+//
+VOID *gHobList = NULL;
+
+/**
+  Returns the pointer to the HOB list.
+
+  This function returns the pointer to first HOB in the list.
+  If the pointer to the HOB list is NULL, then ASSERT().
+
+  @return The pointer to the HOB list.
+
+**/
+VOID *
+EFIAPI
+GetHobList (
+  VOID
+  )
+{
+  ASSERT (gHobList != NULL);
+  return gHobList;
+}
+
+/**
+  Returns the next instance of a HOB type from the starting HOB.
+
+  This function searches the first instance of a HOB type from the starting 
HOB pointer.
+  If there does not exist such HOB type 

[edk2] [PATCH 04/10] StandaloneMmPkg/MemoryAllocationLib: Add MM memory allocation library.

[Supreeth Venkatesh]

This patch implements management mode memory allocation services.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
Reviewed-by: Achin Gupta 
Reviewed-by: Jiewen Yao 
Cc: Jiewen Yao 
Cc: Achin Gupta 
---
 StandaloneMmPkg/Include/Guid/MmCoreData.h  | 133 +++
 StandaloneMmPkg/Include/Guid/MmramMemoryReserve.h  |  62 ++
 .../StandaloneMmCoreMemoryAllocationLib.c  | 907 +
 .../StandaloneMmCoreMemoryAllocationLib.inf|  49 ++
 .../StandaloneMmCoreMemoryAllocationServices.h |  38 +
 5 files changed, 1189 insertions(+)
 create mode 100644 StandaloneMmPkg/Include/Guid/MmCoreData.h
 create mode 100644 StandaloneMmPkg/Include/Guid/MmramMemoryReserve.h
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationLib.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationLib.inf
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationServices.h

diff --git a/StandaloneMmPkg/Include/Guid/MmCoreData.h 
b/StandaloneMmPkg/Include/Guid/MmCoreData.h
new file mode 100644
index 000..a1168f9
--- /dev/null
+++ b/StandaloneMmPkg/Include/Guid/MmCoreData.h
@@ -0,0 +1,133 @@
+/** @file
+  MM Core data.
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2018, ARM Limited. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under
+the terms and conditions of the BSD License that accompanies this distribution.
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __MM_CORE_DATA_H__
+#define __MM_CORE_DATA_H__
+
+#define MM_CORE_DATA_HOB_GUID \
+  { 0xa160bf99, 0x2aa4, 0x4d7d, { 0x99, 0x93, 0x89, 0x9c, 0xb1, 0x2d, 0xf3, 
0x76 }}
+
+extern EFI_GUID gMmCoreDataHobGuid;
+
+typedef struct {
+  //
+  // Address pointer to MM_CORE_PRIVATE_DATA
+  //
+  EFI_PHYSICAL_ADDRESS   Address;
+} MM_CORE_DATA_HOB_DATA;
+
+
+///
+/// Define values for the communications buffer used when 
gEfiEventDxeDispatchGuid is
+/// event signaled.  This event is signaled by the DXE Core each time the DXE 
Core
+/// dispatcher has completed its work.  When this event is signaled, the MM 
Core
+/// if notified, so the MM Core can dispatch MM drivers.  If 
COMM_BUFFER_MM_DISPATCH_ERROR
+/// is returned in the communication buffer, then an error occurred 
dispatching MM
+/// Drivers.  If COMM_BUFFER_MM_DISPATCH_SUCCESS is returned, then the MM Core
+/// dispatched all the drivers it could.  If COMM_BUFFER_MM_DISPATCH_RESTART is
+/// returned, then the MM Core just dispatched the MM Driver that registered
+/// the MM Entry Point enabling the use of MM Mode.  In this case, the MM Core
+/// should be notified again to dispatch more MM Drivers using MM Mode.
+///
+#define COMM_BUFFER_MM_DISPATCH_ERROR0x00
+#define COMM_BUFFER_MM_DISPATCH_SUCCESS  0x01
+#define COMM_BUFFER_MM_DISPATCH_RESTART  0x02
+
+///
+/// Signature for the private structure shared between the MM IPL and the MM 
Core
+///
+#define MM_CORE_PRIVATE_DATA_SIGNATURE  SIGNATURE_32 ('m', 'm', 'i', 'c')
+
+///
+/// Private structure that is used to share information between the MM IPL and
+/// the MM Core.  This structure is allocated from memory of type 
EfiRuntimeServicesData.
+/// Since runtime memory types are converted to available memory when a legacy 
boot
+/// is performed, the MM Core must not access any fields of this structure if 
a legacy
+/// boot is performed.  As a result, the MM IPL must create an event 
notification
+/// for the Legacy Boot event and notify the MM Core that a legacy boot is 
being
+/// performed.  The MM Core can then use this information to filter accesses to
+/// thos structure.
+///
+typedef struct {
+  UINT64  Signature;
+
+  ///
+  /// The number of MMRAM ranges passed from the MM IPL to the MM Core.  The MM
+  /// Core uses these ranges of MMRAM to initialize the MM Core memory manager.
+  ///
+  UINT64  MmramRangeCount;
+
+  ///
+  /// A table of MMRAM ranges passed from the MM IPL to the MM Core.  The MM
+  /// Core uses these ranges of MMRAM to initialize the MM Core memory manager.
+  ///
+  EFI_PHYSICAL_ADDRESSMmramRanges;
+
+  ///
+  /// The MM Foundation Entry Point.  The MM Core fills in this field when the
+  /// MM Core is initialized.  The MM IPL is responsbile for registering this 
entry
+  /// point with the MM Configuration Protocol.  The MM Configuration Protocol 
may
+  /// not be available at the time the MM IPL and MM Core are started, so the 
MM IPL
+  /// sets up a protocol notification on the MM Configuration Protocol and 
registers
+  /// the MM 

[edk2] [PATCH 03/10] StandaloneMmPkg/MemLib: Add Standalone MM instance of memory check library.

[Supreeth Venkatesh]

MM memory check library library implementation. This library consumes
MM_ACCESS_PROTOCOL to get MMRAM information. In order to use this
library instance, the platform should produce all MMRAM range via
MM_ACCESS_PROTOCOL, including the range for firmware (like MM Core
and MM driver) and/or specific dedicated hardware.

This patch provides services for MM Memory Operation.
The management mode Mem Library provides function for checking if buffer
is outside MMRAM and valid. It also provides functions for copy data
from MMRAM to non-MMRAM, from non-MMRAM to MMRAM,
from non-MMRAM to non-MMRAM, or set data in non-MMRAM.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
Reviewed-by: Achin Gupta 
Reviewed-by: Jiewen Yao 
Cc: Jiewen Yao 
Cc: Achin Gupta 
---
 .../Include/Library/StandaloneMmMemLib.h   | 140 +++
 .../AArch64/StandaloneMmMemLibInternal.c   |  49 
 .../StandaloneMmMemLib/StandaloneMmMemLib.c| 265 +
 .../StandaloneMmMemLib/StandaloneMmMemLib.inf  |  50 
 4 files changed, 504 insertions(+)
 create mode 100644 StandaloneMmPkg/Include/Library/StandaloneMmMemLib.h
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmMemLib/AArch64/StandaloneMmMemLibInternal.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmMemLib/StandaloneMmMemLib.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmMemLib/StandaloneMmMemLib.inf

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

[edk2] [PATCH 01/10] StandaloneMmPkg: Delete StandaloneMmPkg file.

[Supreeth Venkatesh]

This patch deletes "StandaloneMmPkg" which was created as a file
intially. This patch enables creation of "StandaloneMmPkg" as a folder.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
Reviewed-by: Achin Gupta 
Reviewed-by: Jiewen Yao 
Cc: Jiewen Yao 
Cc: Achin Gupta 
---
 StandaloneMmPkg | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 StandaloneMmPkg

diff --git a/StandaloneMmPkg b/StandaloneMmPkg
deleted file mode 100644
index e69de29..000
-- 
2.7.4

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

[edk2] [PATCH 02/10] StandaloneMmPkg/FvLib: Add a common FV Library for management mode.

[Supreeth Venkatesh]

This patch implements a firmware volume library that can be used by the
Standalone management mode core module to parse the firmware volume.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
Reviewed-by: Achin Gupta 
Reviewed-by: Jiewen Yao 
Cc: Jiewen Yao 
Cc: Achin Gupta 
---
 StandaloneMmPkg/Include/Library/FvLib.h | 109 +
 StandaloneMmPkg/Library/FvLib/FvLib.c   | 386 
 StandaloneMmPkg/Library/FvLib/FvLib.inf |  57 +
 3 files changed, 552 insertions(+)
 create mode 100644 StandaloneMmPkg/Include/Library/FvLib.h
 create mode 100644 StandaloneMmPkg/Library/FvLib/FvLib.c
 create mode 100644 StandaloneMmPkg/Library/FvLib/FvLib.inf

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

[edk2] [PATCH 00/10] Standalone Management Mode Core Interface for AARCH64 Platforms

[Supreeth Venkatesh]

The following patch series adds StandaloneMM core interface for
aarch64 platforms. Following earlier comments from Jeiwen [1], the
patch series has been split into three parts and this series handles
StandaloneMMPkg related changes.

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

Supreeth Venkatesh (10):
  StandaloneMmPkg: Delete StandaloneMmPkg file.
  StandaloneMmPkg/FvLib: Add a common FV Library for management mode.
  StandaloneMmPkg/MemLib: Add Standalone MM instance of memory check
library.
  StandaloneMmPkg/MemoryAllocationLib: Add MM memory allocation library.
  StandaloneMmPkg/HobLib: Add HOB Library for management mode.
  StandaloneMmPkg: MM driver entry point library.
  StandaloneMmPkg/Core: Implementation of Standalone MM Core Module.
  StandaloneMmPkg: Add an AArch64 specific entry point library.
  StandaloneMmPkg: Add CPU driver suitable for ARM Platforms.
  StandaloneMmPkg: Describe the declaration and definition files.

 StandaloneMmPkg|0
 StandaloneMmPkg/Core/Dependency.c  |  389 +++
 StandaloneMmPkg/Core/Dispatcher.c  | 1071 
 StandaloneMmPkg/Core/FwVol.c   |  104 ++
 StandaloneMmPkg/Core/Handle.c  |  533 ++
 StandaloneMmPkg/Core/InstallConfigurationTable.c   |  178 
 StandaloneMmPkg/Core/Locate.c  |  496 +
 StandaloneMmPkg/Core/Mmi.c |  337 ++
 StandaloneMmPkg/Core/Notify.c  |  203 
 StandaloneMmPkg/Core/Page.c|  384 +++
 StandaloneMmPkg/Core/Pool.c|  287 ++
 StandaloneMmPkg/Core/StandaloneMmCore.c|  708 +
 StandaloneMmPkg/Core/StandaloneMmCore.h|  903 +
 StandaloneMmPkg/Core/StandaloneMmCore.inf  |   80 ++
 StandaloneMmPkg/Core/StandaloneMmCorePrivateData.h |   66 ++
 .../Drivers/StandaloneMmCpu/AArch64/EventHandle.c  |  208 
 .../StandaloneMmCpu/AArch64/StandaloneMmCpu.c  |  219 
 .../StandaloneMmCpu/AArch64/StandaloneMmCpu.h  |   64 ++
 .../StandaloneMmCpu/AArch64/StandaloneMmCpu.inf|   59 ++
 StandaloneMmPkg/Include/Guid/MmCoreData.h  |  133 +++
 StandaloneMmPkg/Include/Guid/MmFvDispatch.h|   38 +
 StandaloneMmPkg/Include/Guid/MmramMemoryReserve.h  |   62 ++
 StandaloneMmPkg/Include/Guid/MpInformation.h   |   41 +
 .../Library/AArch64/StandaloneMmCoreEntryPoint.h   |  214 
 StandaloneMmPkg/Include/Library/FvLib.h|  109 ++
 .../Include/Library/StandaloneMmCoreEntryPoint.h   |  101 ++
 .../Include/Library/StandaloneMmDriverEntryPoint.h |  148 +++
 .../Include/Library/StandaloneMmMemLib.h   |  140 +++
 StandaloneMmPkg/Include/StandaloneMm.h |   36 +
 StandaloneMmPkg/Library/FvLib/FvLib.c  |  386 +++
 StandaloneMmPkg/Library/FvLib/FvLib.inf|   57 ++
 .../AArch64/CreateHobList.c|  200 
 .../AArch64/SetPermissions.c   |  275 +
 .../AArch64/StandaloneMmCoreEntryPoint.c   |  287 ++
 .../StandaloneMmCoreEntryPoint.inf |   55 +
 .../AArch64/StandaloneMmCoreHobLibInternal.c   |   64 ++
 .../StandaloneMmCoreHobLib.c   |  608 +++
 .../StandaloneMmCoreHobLib.inf |   47 +
 .../StandaloneMmCoreMemoryAllocationLib.c  |  907 +
 .../StandaloneMmCoreMemoryAllocationLib.inf|   49 +
 .../StandaloneMmCoreMemoryAllocationServices.h |   38 +
 .../StandaloneMmDriverEntryPoint.c |   99 ++
 .../StandaloneMmDriverEntryPoint.inf   |   41 +
 .../AArch64/StandaloneMmMemLibInternal.c   |   49 +
 .../StandaloneMmMemLib/StandaloneMmMemLib.c|  265 +
 .../StandaloneMmMemLib/StandaloneMmMemLib.inf  |   50 +
 StandaloneMmPkg/StandaloneMmPkg.dec|   47 +
 StandaloneMmPkg/StandaloneMmPkg.dsc|  130 +++
 48 files changed, 10965 insertions(+)
 delete mode 100644 StandaloneMmPkg
 create mode 100644 StandaloneMmPkg/Core/Dependency.c
 create mode 100644 StandaloneMmPkg/Core/Dispatcher.c
 create mode 100644 StandaloneMmPkg/Core/FwVol.c
 create mode 100644 StandaloneMmPkg/Core/Handle.c
 create mode 100644 StandaloneMmPkg/Core/InstallConfigurationTable.c
 create mode 100644 StandaloneMmPkg/Core/Locate.c
 create mode 100644 StandaloneMmPkg/Core/Mmi.c
 create mode 100644 StandaloneMmPkg/Core/Notify.c
 create mode 100644 StandaloneMmPkg/Core/Page.c
 create mode 100644 StandaloneMmPkg/Core/Pool.c
 create mode 100644 StandaloneMmPkg/Core/StandaloneMmCore.c
 create mode 100644 StandaloneMmPkg/Core/StandaloneMmCore.h
 create mode 100644 StandaloneMmPkg/Core/StandaloneMmCore.inf
 create mode 100644 StandaloneMmPkg/Core/StandaloneMmCorePrivateData.h
 create mode 100644 

[edk2] gRT->SetVariable ACCESS DENIED error

[Toan Le manh]

Dear all,

I'm facing the Status EFI_ACCESS_DENIED when using gRT->SetVariable()
method.
There is no description of this returned status for SetVariable()  in UEFI
spec.
Have you ever faced this type of error? Could you please give me any idea
on how this happen?
Sorry for any inconvenience, I'm newbie in EDK2.

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

[edk2] [PATCH v3 2/7] CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Maurice Ma 
Cc: Prince Agyeman 
Cc: Benjamin You 
---
 .../PlatformBootManagerLib/PlatformBootManager.c  | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git 
a/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c 
b/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index 7e92441da1..368e89d586 100644
--- a/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++ b/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
@@ -2,7 +2,7 @@
   This file include all platform action which can be customized
   by IBV/OEM.
 
-Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -252,3 +252,20 @@ PlatformBootManagerWaitCallback (
 {
   return;
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  return;
+}
+
-- 
2.16.1.windows.1

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

[edk2] [PATCH v3 6/7] MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"

[Ruiyu Ni]

Commit d1de487dd2e77f4741abcbd71d19a8c93971fda0
"MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before
 hanging"
changed BDS core to fall back to UI loop when no bootable option
can be launched.
Now since PlatformBootManagerUnableToBoot() is added, the commit
can be reverted.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Eric Dong 
Cc: Laszlo Ersek 
---
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 60 +++-
 1 file changed, 4 insertions(+), 56 deletions(-)

diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
index 49e403e181..39b643c77a 100644
--- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -634,55 +634,6 @@ BdsFormalizeEfiGlobalVariable (
   BdsFormalizeOSIndicationVariable ();
 }
 
-/**
-  Enter an infinite loop of calling the Boot Manager Menu.
-
-  This is a last resort alternative to BdsEntry() giving up for good. This
-  function never returns.
-
-  @param[in] BootManagerMenu  The EFI_BOOT_MANAGER_LOAD_OPTION located and/or
-  created by the EfiBootManagerGetBootManagerMenu()
-  call in BdsEntry().
-**/
-VOID
-BdsBootManagerMenuLoop (
-  IN EFI_BOOT_MANAGER_LOAD_OPTION *BootManagerMenu
-  )
-{
-  EFI_INPUT_KEY Key;
-
-  //
-  // Normally BdsDxe does not print anything to the system console, but this is
-  // a last resort -- the end-user will likely not see any DEBUG messages
-  // logged in this situation.
-  //
-  // AsciiPrint() will NULL-check gST->ConOut internally. We check gST->ConIn
-  // here to see if it makes sense to request and wait for a keypress.
-  //
-  if (gST->ConIn != NULL) {
-AsciiPrint (
-  "%a: No bootable option or device was found.\n"
-  "%a: Press any key to enter the Boot Manager Menu.\n",
-  gEfiCallerBaseName,
-  gEfiCallerBaseName
-  );
-BdsWaitForSingleEvent (gST->ConIn->WaitForKey, 0);
-
-//
-// Drain any queued keys.
-//
-while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
-  //
-  // just throw away Key
-  //
-}
-  }
-
-  for (;;) {
-EfiBootManagerBoot (BootManagerMenu);
-  }
-}
-
 /**
 
   Service routine for BdsInstance->Entry(). Devices are connected, the
@@ -1081,19 +1032,16 @@ BdsEntry (
 } while (BootSuccess);
   }
 
+  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
+EfiBootManagerFreeLoadOption ();
+  }
+
   if (!BootSuccess) {
 LoadOptions = EfiBootManagerGetLoadOptions (, 
LoadOptionTypePlatformRecovery);
 ProcessLoadOptions (LoadOptions, LoadOptionCount);
 EfiBootManagerFreeLoadOptions (LoadOptions, LoadOptionCount);
   }
 
-  //
-  // If BootManagerMenu is available, fall back to it indefinitely.
-  //
-  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
-BdsBootManagerMenuLoop ();
-  }
-
   DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
   CpuDeadLoop ();
 }
-- 
2.16.1.windows.1

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

[edk2] [PATCH v3 5/7] QuarkPlatform/PlatformBDS: Implement PlatformBootManagerUnableToBoot

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Michael D Kinney 
Cc: Kelly Steele 
---
 .../PlatformBootManagerLib/PlatformBootManager.c  | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git 
a/QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c 
b/QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index 53391c6077..8b25f55f1c 100644
--- a/QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++ b/QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
@@ -2,7 +2,7 @@
 This file include all platform action which can be customized
 by IBV/OEM.
 
-Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -459,3 +459,20 @@ PlatformBootManagerWaitCallback (
 {
   Print (L"\r%-2d seconds remained...", TimeoutRemain);
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  return;
+}
+
-- 
2.16.1.windows.1

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

[edk2] [PATCH v3 7/7] MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()

[Ruiyu Ni]

When no boot option can be launched, BDS core calls
PlatformBootManagerUnableToBoot() to let platform BdsDxe handle it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Laszlo Ersek 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Sunny Wang 
---
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
index 39b643c77a..a25663ea43 100644
--- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -1043,6 +1043,7 @@ BdsEntry (
   }
 
   DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
+  PlatformBootManagerUnableToBoot ();
   CpuDeadLoop ();
 }
 
-- 
2.16.1.windows.1

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

[edk2] [PATCH v3 4/7] Nt32Pkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Hao A Wu 
---
 .../PlatformBootManagerLib/PlatformBootManager.c  | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c 
b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index 99f30f9ec2..cf8289faff 100644
--- a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++ b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
@@ -2,7 +2,7 @@
   This file include all platform action which can be customized
   by IBV/OEM.
 
-Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -403,3 +403,20 @@ PlatformBootManagerWaitCallback (
 0
 );
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  return;
+}
+
-- 
2.16.1.windows.1

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

[edk2] [PATCH v3 3/7] OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
---
 .../Library/PlatformBootManagerLib/BdsPlatform.c   | 61 +-
 1 file changed, 60 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 57870cb856..e56ffc141a 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1,7 +1,7 @@
 /** @file
   Platform BDS customizations.
 
-  Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
   distribution.  The full text of the license may be found at
@@ -1676,3 +1676,62 @@ PlatformBootManagerWaitCallback (
 );
 }
 
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  EFI_STATUS   Status;
+  EFI_INPUT_KEYKey;
+  EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
+  UINTNIndex;
+
+  //
+  // BootManagerMenu doesn't contain the correct information when return 
status is EFI_NOT_FOUND.
+  //
+  Status = EfiBootManagerGetBootManagerMenu ();
+  if (EFI_ERROR (Status)) {
+return;
+  }
+  //
+  // Normally BdsDxe does not print anything to the system console, but this is
+  // a last resort -- the end-user will likely not see any DEBUG messages
+  // logged in this situation.
+  //
+  // AsciiPrint() will NULL-check gST->ConOut internally. We check gST->ConIn
+  // here to see if it makes sense to request and wait for a keypress.
+  //
+  if (gST->ConIn != NULL) {
+AsciiPrint (
+  "%a: No bootable option or device was found.\n"
+  "%a: Press any key to enter the Boot Manager Menu.\n",
+  gEfiCallerBaseName,
+  gEfiCallerBaseName
+  );
+Status = gBS->WaitForEvent (1, >ConIn->WaitForKey, );
+ASSERT_EFI_ERROR (Status);
+ASSERT (Index == 0);
+
+//
+// Drain any queued keys.
+//
+while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
+  //
+  // just throw away Key
+  //
+}
+  }
+
+  for (;;) {
+EfiBootManagerBoot ();
+  }
+}
+
-- 
2.16.1.windows.1

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

[edk2] [PATCH v3 1/7] MdeModulePkg/PlatformBootManager: Add PlatformBootManagerUnableToBoot

[Ruiyu Ni]

The patch adds a new API PlatformBootManagerUnableToBoot()'
to PlatformBootManagerLib.
The new API is provided by platform bds library and is called when
no boot option could be launched.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Laszlo Ersek 
Cc: Sunny Wang 
---
 MdeModulePkg/Include/Library/PlatformBootManagerLib.h | 13 +
 .../PlatformBootManagerLibNull/PlatformBootManager.c  | 19 ++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Include/Library/PlatformBootManagerLib.h 
b/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
index 65630ce2bb..6e26329043 100644
--- a/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
+++ b/MdeModulePkg/Include/Library/PlatformBootManagerLib.h
@@ -59,4 +59,17 @@ PlatformBootManagerWaitCallback (
   UINT16  TimeoutRemain
   );
 
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  );
+
 #endif
diff --git 
a/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c 
b/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
index 1390e19097..5a4455ef23 100644
--- a/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
+++ b/MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManager.c
@@ -2,7 +2,7 @@
   This file include all platform action which can be customized
   by IBV/OEM.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -65,3 +65,20 @@ PlatformBootManagerWaitCallback (
 {
   return;
 }
+
+/**
+  The function is called when no boot option could be launched,
+  including platform recovery options and options pointing to applications
+  built into firmware volumes.
+
+  If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+  VOID
+  )
+{
+  return;
+}
+
-- 
2.16.1.windows.1

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

[edk2] [PATCH v3 0/7] Add platform hook for ultimate boot failure.

[Ruiyu Ni]

Ruiyu Ni (7):
  MdeModulePkg/PlatformBootManager: Add PlatformBootManagerUnableToBoot
  CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot
  OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot
  Nt32Pkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
  QuarkPlatform/PlatformBDS: Implement PlatformBootManagerUnableToBoot
  MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"
  MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()

 .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
 .../Include/Library/PlatformBootManagerLib.h   | 13 +
 .../PlatformBootManager.c  | 19 ++-
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c   | 61 ++
 .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
 .../Library/PlatformBootManagerLib/BdsPlatform.c   | 61 +-
 .../PlatformBootManagerLib/PlatformBootManager.c   | 19 ++-
 7 files changed, 150 insertions(+), 61 deletions(-)

-- 
2.16.1.windows.1

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