Re: [edk2] [PATCH 04/11] MdePkg/BaseLib: Add StrToGuid/StrHexToBytes/StrToIpv[4/6]Address

[Ni, Ruiyu]

Jiewen,
If we returns Unsupported for "   1.2.3.4".
What shall we return for "1.2.3"?
If we need to return Invalid Parameter for "   1.2.3", the implementation has 
to check whether it's a valid IP address after spaces, or an invalid IP address.

Can you just return Invalid Parameter for all cases?

Thanks/Ray

> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, February 22, 2017 2:02 PM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Gao, Liming ; Fu, Siyuan 
> Subject: RE: [PATCH 04/11] MdePkg/BaseLib: Add
> StrToGuid/StrHexToBytes/StrToIpv[4/6]Address
> 
> Thanks.
> 
> I suggest we clearly say: This function does not support the leading pad 
> space ,
> which includes spaces or tab characters, before the first valid char.
> 
> For example, "1.2.3.4" is considered as invalid IPv4 address.
> And I suggest we return EFI_UNSUPPORTED.
> 
> The comment is applied to add [Ascii]StrToGuid/IpV4/IpV6.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Wednesday, February 22, 2017 12:51 PM
> > To: edk2-devel@lists.01.org
> > Cc: Gao, Liming ; Yao, Jiewen
> > ; Fu, Siyuan 
> > Subject: [PATCH 04/11] MdePkg/BaseLib: Add
> > StrToGuid/StrHexToBytes/StrToIpv[4/6]Address
> >
> > The patch adds 4 APIs to convert Unicode string to GUID, bytes buffer,
> > IP v4 address and IP v6 address.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni 
> > Cc: Liming Gao 
> > Cc: Jiewen Yao 
> > Cc: Siyuan Fu 
> > ---
> >  MdePkg/Include/Library/BaseLib.h| 241 ++
> >  MdePkg/Library/BaseLib/SafeString.c | 623
> > 
> >  2 files changed, 864 insertions(+)
> >
> > diff --git a/MdePkg/Include/Library/BaseLib.h
> > b/MdePkg/Include/Library/BaseLib.h
> > index d71ccb7..8aac4c8 100644
> > --- a/MdePkg/Include/Library/BaseLib.h
> > +++ b/MdePkg/Include/Library/BaseLib.h
> > @@ -1536,6 +1536,247 @@ StrHexToUint64 (
> >IN  CONST CHAR16 *String
> >);
> >
> > +/**
> > +  Convert a Null-terminated Unicode string to IPv6 address and prefix 
> > length.
> > +
> > +  This function outputs a value of type IPv6_ADDRESS and may output a
> > + value  of type UINT8 by interpreting the contents of the Unicode
> > + string specified  by String. The format of the input Unicode string 
> > String is as
> follows:
> > +
> > +  X:X:X:X:X:X:X:X[/P]
> > +
> > +  X contains one to four hexadecimal digit characters in the range
> > + [0-9], [a-f]
> > and
> > +  [A-F]. X is converted to a value of type UINT16, whose low byte is
> > + stored in
> > low
> > +  memory address and high byte is stored in high memory address. P
> > + contains
> > decimal
> > +  digit characters in the range [0-9]. The running zero in the
> > + beginning of P will  be ignored. /P is optional.
> > +
> > +  When /P is not in the String, the function stops at the first
> > + character that is  not a valid hexadecimal digit character after eight 
> > X's are
> converted.
> > +
> > +  When /P is in the String, the function stops at the first character
> > + that is not  a valid decimal digit character after P is converted.
> > +
> > +  "::" can be used to compress one or more groups of X when X contains only
> 0.
> > +  The "::" can only appear once in the String.
> > +
> > +  If String is NULL, then ASSERT().
> > +
> > +  If Address is NULL, then ASSERT().
> > +
> > +  If String is not aligned in a 16-bit boundary, then ASSERT().
> > +
> > +  If PcdMaximumUnicodeStringLength is not zero, and String contains
> > + more
> > than
> > +  PcdMaximumUnicodeStringLength Unicode characters, not including the
> > + Null-terminator, then ASSERT().
> > +
> > +  If EndPointer is not NULL and Address is translated from String, a
> > + pointer  to the character that stopped the scan is stored at the
> > + location pointed to  by EndPointer.
> > +
> > +  @param  String   Pointer to a Null-terminated Unicode
> > string.
> > +  @param  EndPointer   Pointer to character that stops scan.
> > +  @param  Address  Pointer to the converted IPv6
> > address.
> > +  @param  PrefixLength Pointer to the converted IPv6 address
> > prefix
> > +   length. MAX_UINT8 is returned when
> > /P is
> > +   not in the String.
> > +
> > +  @retval RETURN_SUCCESS   Address is translated from String.
> > +  @retval RETURN_INVALID_PARAMETER If String is NULL.
> > +   If Data is NULL.
> > +   If PcdMaximumUnicodeStringLength
> > + is
> > not
> > +zero, and String contains more than
> > +   

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Replace EFI_D_xxx with DEBUG_xxx in DEBUG()

[Tian, Feng]

Reviewed-by: Feng Tian

Thanks
Feng

-Original Message-
From: Fan, Jeff 
Sent: Wednesday, February 22, 2017 3:56 PM
To: edk2-de...@ml01.01.org
Cc: Laszlo Ersek ; Tian, Feng ; Kinney, 
Michael D 
Subject: [PATCH] UefiCpuPkg/CpuDxe: Replace EFI_D_xxx with DEBUG_xxx in DEBUG()

Cc: Laszlo Ersek 
Cc: Feng Tian 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/CpuDxe/CpuDxe.c | 8   UefiCpuPkg/CpuDxe/CpuMp.c  | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c index 
1a5a725..2fd2f31 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -403,7 +403,7 @@ CpuSetMemoryAttributes (
   // to avoid unnecessary computing.
   //
   if (mIsFlushingGCD) {
-DEBUG((EFI_D_INFO, "  Flushing GCD\n"));
+DEBUG((DEBUG_INFO, "  Flushing GCD\n"));
 return EFI_SUCCESS;
   }
 
@@ -979,13 +979,13 @@ IntersectMemoryDescriptor (
 IntersectionBase, IntersectionEnd - IntersectionBase,
 Capabilities);
 
-DEBUG ((EFI_ERROR (Status) ? EFI_D_ERROR : EFI_D_VERBOSE,
+DEBUG ((EFI_ERROR (Status) ? DEBUG_ERROR : DEBUG_VERBOSE,
   "%a: %a: add [%Lx, %Lx): %r\n", gEfiCallerBaseName, __FUNCTION__,
   IntersectionBase, IntersectionEnd, Status));
 return Status;
   }
 
-  DEBUG ((EFI_D_ERROR, "%a: %a: desc [%Lx, %Lx) type %u cap %Lx conflicts "
+  DEBUG ((DEBUG_ERROR, "%a: %a: desc [%Lx, %Lx) type %u cap %Lx conflicts "
 "with aperture [%Lx, %Lx) cap %Lx\n", gEfiCallerBaseName, __FUNCTION__,
 Descriptor->BaseAddress, Descriptor->BaseAddress + Descriptor->Length,
 (UINT32)Descriptor->GcdMemoryType, Descriptor->Capabilities, @@ -1018,7 
+1018,7 @@ AddMemoryMappedIoSpace (
 
   Status = gDS->GetMemorySpaceMap (, );
   if (EFI_ERROR (Status)) {
-DEBUG ((EFI_D_ERROR, "%a: %a: GetMemorySpaceMap(): %r\n",
+DEBUG ((DEBUG_ERROR, "%a: %a: GetMemorySpaceMap(): %r\n",
   gEfiCallerBaseName, __FUNCTION__, Status));
 return Status;
   }
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c index 
9659bd2..4456946 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1,7 +1,7 @@
 /** @file
   CPU DXE Module to produce CPU MP Protocol.
 
-  Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2017, 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 @@ -571,7 +571,7 @@ CollectBistDataFromHob (
   BspCpuInstance.InfoRecord.IA32HealthFlags.Uint32  = 
SecPlatformInformation->IA32HealthFlags.Uint32;
   CpuInstance = 
 } else {
-  DEBUG ((EFI_D_INFO, "Does not find any HOB stored CPU BIST 
information!\n"));
+  DEBUG ((DEBUG_INFO, "Does not find any HOB stored CPU BIST 
+ information!\n"));
   //
   // Does not find any HOB stored BIST information
   //
@@ -622,7 +622,7 @@ InitializeMpSupport (
 
   MpInitLibGetNumberOfProcessors (, 
);
   mNumberOfProcessors = NumberOfProcessors;
-  DEBUG ((EFI_D_ERROR, "Detect CPU count: %d\n", mNumberOfProcessors));
+  DEBUG ((DEBUG_ERROR, "Detect CPU count: %d\n", mNumberOfProcessors));
 
   //
   // Update CPU healthy information from Guided HOB
--
2.9.3.windows.2

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

[edk2] [PATCH] UefiCpuPkg/CpuDxe: Replace EFI_D_xxx with DEBUG_xxx in DEBUG()

[Jeff Fan]

Cc: Laszlo Ersek 
Cc: Feng Tian 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/CpuDxe/CpuDxe.c | 8 
 UefiCpuPkg/CpuDxe/CpuMp.c  | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
index 1a5a725..2fd2f31 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -403,7 +403,7 @@ CpuSetMemoryAttributes (
   // to avoid unnecessary computing.
   //
   if (mIsFlushingGCD) {
-DEBUG((EFI_D_INFO, "  Flushing GCD\n"));
+DEBUG((DEBUG_INFO, "  Flushing GCD\n"));
 return EFI_SUCCESS;
   }
 
@@ -979,13 +979,13 @@ IntersectMemoryDescriptor (
 IntersectionBase, IntersectionEnd - IntersectionBase,
 Capabilities);
 
-DEBUG ((EFI_ERROR (Status) ? EFI_D_ERROR : EFI_D_VERBOSE,
+DEBUG ((EFI_ERROR (Status) ? DEBUG_ERROR : DEBUG_VERBOSE,
   "%a: %a: add [%Lx, %Lx): %r\n", gEfiCallerBaseName, __FUNCTION__,
   IntersectionBase, IntersectionEnd, Status));
 return Status;
   }
 
-  DEBUG ((EFI_D_ERROR, "%a: %a: desc [%Lx, %Lx) type %u cap %Lx conflicts "
+  DEBUG ((DEBUG_ERROR, "%a: %a: desc [%Lx, %Lx) type %u cap %Lx conflicts "
 "with aperture [%Lx, %Lx) cap %Lx\n", gEfiCallerBaseName, __FUNCTION__,
 Descriptor->BaseAddress, Descriptor->BaseAddress + Descriptor->Length,
 (UINT32)Descriptor->GcdMemoryType, Descriptor->Capabilities,
@@ -1018,7 +1018,7 @@ AddMemoryMappedIoSpace (
 
   Status = gDS->GetMemorySpaceMap (, );
   if (EFI_ERROR (Status)) {
-DEBUG ((EFI_D_ERROR, "%a: %a: GetMemorySpaceMap(): %r\n",
+DEBUG ((DEBUG_ERROR, "%a: %a: GetMemorySpaceMap(): %r\n",
   gEfiCallerBaseName, __FUNCTION__, Status));
 return Status;
   }
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index 9659bd2..4456946 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1,7 +1,7 @@
 /** @file
   CPU DXE Module to produce CPU MP Protocol.
 
-  Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2017, 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
@@ -571,7 +571,7 @@ CollectBistDataFromHob (
   BspCpuInstance.InfoRecord.IA32HealthFlags.Uint32  = 
SecPlatformInformation->IA32HealthFlags.Uint32;
   CpuInstance = 
 } else {
-  DEBUG ((EFI_D_INFO, "Does not find any HOB stored CPU BIST 
information!\n"));
+  DEBUG ((DEBUG_INFO, "Does not find any HOB stored CPU BIST 
information!\n"));
   //
   // Does not find any HOB stored BIST information
   //
@@ -622,7 +622,7 @@ InitializeMpSupport (
 
   MpInitLibGetNumberOfProcessors (, 
);
   mNumberOfProcessors = NumberOfProcessors;
-  DEBUG ((EFI_D_ERROR, "Detect CPU count: %d\n", mNumberOfProcessors));
+  DEBUG ((DEBUG_ERROR, "Detect CPU count: %d\n", mNumberOfProcessors));
 
   //
   // Update CPU healthy information from Guided HOB
-- 
2.9.3.windows.2

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

[edk2] [PATCH 2/2] ShellPkg/comp: Add "-n "/"-s " support

[Ruiyu Ni]

From: Chen A Chen 

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen 
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c | 357 +
 .../UefiShellDebug1CommandsLib.uni |  27 +-
 2 files changed, 229 insertions(+), 155 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c
index 829c49a..62b59d7 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c
@@ -15,6 +15,71 @@
 
 #include "UefiShellDebug1CommandsLib.h"
 
+STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
+  {L"-n", TypeValue},
+  {L"-s", TypeValue},
+  {NULL,  TypeMax}
+  };
+
+typedef enum {
+  OutOfDiffPoint,
+  InDiffPoint,
+  InPrevDiffPoint
+} READ_STATUS;
+
+/**
+  Function to print differnt point data.
+
+  @param[in]  FileNameFile name
+  @param[in]  Buffer  Data buffer to be printed.
+  @param[in]  BufferSize  Size of the data to be printed.
+  @param[in]  Address Address of the differnt point.
+  @param[in]  DifferentBytes  Total size of the buffer.
+
+**/
+VOID
+PrintDifferentPoint(
+  CONST CHAR16  *FileName,
+  UINT8 *Buffer,
+  UINT64DataSize,
+  UINTN Address,
+  UINT64BufferSize
+  )
+{
+  UINTN Index;
+
+  ShellPrintEx (-1, -1, L"%s: %s\r\n  %08x:", L"File1", FileName, Address);
+
+  //
+  // Print data in hex-format.
+  //
+  for (Index = 0; Index < DataSize; Index++) {
+ShellPrintEx (-1, -1, L" %02x", Buffer[Index]);
+  }
+
+  if (DataSize < BufferSize) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_COMP_END_OF_FILE), 
gShellDebug1HiiHandle);
+  }
+
+  ShellPrintEx (-1, -1, L"*");
+
+  //
+  // Print data in char-format.
+  //
+  for (Index = 0; Index < DataSize; Index++) {
+if (Buffer[Index] >= 0x20 && Buffer[Index] <= 0x7E) {
+  ShellPrintEx (-1, -1, L"%c", Buffer[Index]);
+} else {
+  //
+  // Print dots for control characters
+  //
+  ShellPrintEx (-1, -1, L".");
+}
+  }
+
+  ShellPrintEx (-1, -1, L"*\r\n");
+}
+
 /**
   Function for 'comp' command.
 
@@ -35,32 +100,41 @@ ShellCommandRunComp (
   CHAR16  *FileName2;
   CONST CHAR16*TempParam;
   SHELL_STATUSShellStatus;
-  UINTN   LoopVar;
   SHELL_FILE_HANDLE   FileHandle1;
   SHELL_FILE_HANDLE   FileHandle2;
-  UINT8   DifferentCount;
   UINT64  Size1;
   UINT64  Size2;
-  UINT8   DataFromFile1;
-  UINT8   DataFromFile2;
-  UINT8   ADF_File11;
-  UINT8   ADF_File12;
-  UINT8   ADF_File13;
-  UINT8   ADF_File21;
-  UINT8   ADF_File22;
-  UINT8   ADF_File23;
+  UINT64  DifferentBytes;
+  UINT64  DifferentCount;
+  UINT8   DiffPointNumber;
+  UINT8   OneByteFromFile1;
+  UINT8   OneByteFromFile2;
+  UINT8   *DataFromFile1;
+  UINT8   *DataFromFile2;
+  UINTN   InsertPosition1;
+  UINTN   InsertPosition2;
   UINTN   DataSizeFromFile1;
   UINTN   DataSizeFromFile2;
+  UINTN   TempAddress;
+  UINTN   Index;
   UINTN   DiffPointAddress;
+  READ_STATUS ReadStatus;
 
-  DifferentCount  = 0;
   ShellStatus = SHELL_SUCCESS;
   Status  = EFI_SUCCESS;
   FileName1   = NULL;
   FileName2   = NULL;
   FileHandle1 = NULL;
   FileHandle2 = NULL;
-  Size1   = 0;
+  DataFromFile1   = NULL;
+  DataFromFile2   = NULL;
+  ReadStatus  = OutOfDiffPoint;
+  DifferentCount  = 10;
+  DifferentBytes  = 4;
+  DiffPointNumber = 0;
+  InsertPosition1 = 0;
+  InsertPosition2 = 0;
+  TempAddress = 0;
 
   //
   // initialize the shell lib (we must be in non-auto-init...)
@@ -74,7 +148,7 @@ ShellCommandRunComp (
   //
   // parse the command line
   //
-  Status = ShellCommandLineParse (EmptyParamList, , , 
TRUE);
+  Status = ShellCommandLineParse (ParamList, , , TRUE);
   if (EFI_ERROR(Status)) {
 if (Status == EFI_VOLUME_CORRUPTED && ProblemParam != NULL) {
   ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_PROBLEM), 
gShellDebug1HiiHandle, L"comp", ProblemParam);  
@@ -118,142 +192,165 @@ ShellCommandRunComp (
 }
   }
   if (ShellStatus == SHELL_SUCCESS) {
-ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_COMP_HEADER), 
gShellDebug1HiiHandle, FileName1, FileName2);
 Status = gEfiShellProtocol->GetFileSize(FileHandle1, );
 ASSERT_EFI_ERROR(Status);
 Status = gEfiShellProtocol->GetFileSize(FileHandle2, );
 ASSERT_EFI_ERROR(Status);
-

[edk2] [PATCH 0/2] Add "-n/-s" support to "comp" command

[Ruiyu Ni]

Chen A Chen (2):
  ShellPkg/comp: Rename variable names to proper ones
  ShellPkg/comp: Add "-n "/"-s " support

 ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c | 367 +
 .../UefiShellDebug1CommandsLib.uni |  27 +-
 2 files changed, 234 insertions(+), 160 deletions(-)

-- 
2.9.0.windows.1

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

[edk2] [PATCH 1/2] ShellPkg/comp: Rename variable names to proper ones

[Ruiyu Ni]

From: Chen A Chen 

The change doesn't impact the functionality.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c | 46 +++---
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c
index 2ab7dd3..829c49a 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Comp.c
@@ -2,7 +2,7 @@
   Main file for Comp shell Debug1 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2017, 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
@@ -31,11 +31,14 @@ ShellCommandRunComp (
   EFI_STATUS  Status;
   LIST_ENTRY  *Package;
   CHAR16  *ProblemParam;
+  CHAR16  *FileName1;
+  CHAR16  *FileName2;
+  CONST CHAR16*TempParam;
   SHELL_STATUSShellStatus;
   UINTN   LoopVar;
   SHELL_FILE_HANDLE   FileHandle1;
   SHELL_FILE_HANDLE   FileHandle2;
-  UINT8   ErrorCount;
+  UINT8   DifferentCount;
   UINT64  Size1;
   UINT64  Size2;
   UINT8   DataFromFile1;
@@ -48,12 +51,9 @@ ShellCommandRunComp (
   UINT8   ADF_File23;
   UINTN   DataSizeFromFile1;
   UINTN   DataSizeFromFile2;
-  CHAR16  *FileName1;
-  CHAR16  *FileName2;
-  CONST CHAR16*TempParam;
-  UINTN   ErrorAddress;
+  UINTN   DiffPointAddress;
 
-  ErrorCount  = 0;
+  DifferentCount  = 0;
   ShellStatus = SHELL_SUCCESS;
   Status  = EFI_SUCCESS;
   FileName1   = NULL;
@@ -125,12 +125,12 @@ ShellCommandRunComp (
 ASSERT_EFI_ERROR(Status);
 if (Size1 != Size2) {
   ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_COMP_SIZE_FAIL), 
gShellDebug1HiiHandle);
-  ErrorCount++;
+  DifferentCount++;
   ShellStatus = SHELL_NOT_EQUAL;
 }
   }
   if (ShellStatus == SHELL_SUCCESS) {
-for (LoopVar = 0 ; LoopVar < Size1 && ErrorCount <= 10 ; LoopVar++) {
+for (LoopVar = 0 ; LoopVar < Size1 && DifferentCount <= 10 ; 
LoopVar++) {
   DataSizeFromFile1 = 1;
   DataSizeFromFile2 = 1;
   Status = gEfiShellProtocol->ReadFile(FileHandle1, 
, );
@@ -138,7 +138,7 @@ ShellCommandRunComp (
   Status = gEfiShellProtocol->ReadFile(FileHandle2, 
, );
   ASSERT_EFI_ERROR(Status);
   if (DataFromFile1 != DataFromFile2) {
-ErrorAddress = LoopVar;
+DiffPointAddress = LoopVar;
 ADF_File11 = 0;
 ADF_File12 = 0;
 ADF_File13 = 0;
@@ -188,13 +188,13 @@ ShellCommandRunComp (
 NULL,
 STRING_TOKEN (STR_COMP_SPOT_FAIL4),
 gShellDebug1HiiHandle,
-++ErrorCount,
+++DifferentCount,
 FileName1,
-ErrorAddress,
+DiffPointAddress,
 DataFromFile1, ADF_File11, ADF_File12, ADF_File13,
 DataFromFile1, ADF_File11, ADF_File12, ADF_File13,
 FileName2,
-ErrorAddress,
+DiffPointAddress,
 DataFromFile2, ADF_File21, ADF_File22, ADF_File23,
 DataFromFile2, ADF_File21, ADF_File22, ADF_File23
);
@@ -205,13 +205,13 @@ ShellCommandRunComp (
 NULL,
 STRING_TOKEN (STR_COMP_SPOT_FAIL3),
 gShellDebug1HiiHandle,
-++ErrorCount,
+++DifferentCount,
 FileName1,
-ErrorAddress,
+DiffPointAddress,
 DataFromFile1, ADF_File11, ADF_File12,
 DataFromFile1, ADF_File11, ADF_File12,
 FileName2,
-ErrorAddress,
+DiffPointAddress,
 DataFromFile2, ADF_File21, ADF_File22,
 DataFromFile2, ADF_File21, ADF_File22
);
@@ -222,13 +222,13 @@ ShellCommandRunComp (
 NULL,
 STRING_TOKEN (STR_COMP_SPOT_FAIL2),
 gShellDebug1HiiHandle,
-++ErrorCount,
+++DifferentCount,
 FileName1,
-ErrorAddress,
+DiffPointAddress,
 DataFromFile1, ADF_File11,
 DataFromFile1, ADF_File11,
 

Re: [edk2] [PATCH 10/11] SignedCapsulePkg/IniParsingLib: Use AsciiStrToGuid in BaseLib

[Ni, Ruiyu]

Can we use EFI_STATUS variable to receive RETURN_STATUS type of value?

Thanks/Ray

From: Yao, Jiewen
Sent: Wednesday, February 22, 2017 1:28 PM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Subject: RE: [PATCH 10/11] SignedCapsulePkg/IniParsingLib: Use AsciiStrToGuid 
in BaseLib

Hi
I do not suggest we use below check.

  if (RETURN_ERROR (AsciiStrToGuid (Value, Guid))) {

I suggest we use below style, because it may help source level debug to see 
what Status is returned.

  Status = AsciiStrToGuid (Value, Guid);
  if (EFI_ERROR (Status)) {

The suggestion is applied to all patches, such as CapsuleApp


Thank you
Yao Jiewen

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, February 22, 2017 12:51 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen >
> Subject: [PATCH 10/11] SignedCapsulePkg/IniParsingLib: Use AsciiStrToGuid in
> BaseLib
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni >
> Cc: Jiewen Yao >
> ---
>  .../Library/IniParsingLib/IniParsingLib.c  | 141 
> +
>  1 file changed, 1 insertion(+), 140 deletions(-)
>
> diff --git a/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
> b/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
> index 16e1349..e9c2cc5 100644
> --- a/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
> +++ b/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
> @@ -862,144 +862,6 @@ UpdateGetProfileString (
>  }
>
>  /**
> -  Converts a list of string to a specified buffer.
> -
> -  @param[out] Buf The output buffer that contains the string.
> -  @param[in]  BufferLengthThe length of the buffer
> -  @param[in]  Str The input string that contains the hex number
> -
> -  @retval EFI_SUCCESSThe string was successfully converted to the buffer.
> -
> -**/
> -EFI_STATUS
> -AsciiStrToBuf (
> -  OUT UINT8*Buf,
> -  IN  UINTNBufferLength,
> -  IN  CHAR8*Str
> -  )
> -{
> -  UINTN   Index;
> -  UINTN   StrLength;
> -  UINT8   Digit;
> -  UINT8   Byte;
> -
> -  Digit = 0;
> -
> -  //
> -  // Two hex char make up one byte
> -  //
> -  StrLength = BufferLength * 2;
> -
> -  for(Index = 0; Index < StrLength; Index++, Str++) {
> -
> -if ((*Str >= 'a') && (*Str <= 'f')) {
> -  Digit = (UINT8) (*Str - 'a' + 0x0A);
> -} else if ((*Str >= 'A') && (*Str <= 'F')) {
> -  Digit = (UINT8) (*Str - 'A' + 0x0A);
> -} else if ((*Str >= '0') && (*Str <= '9')) {
> -  Digit = (UINT8) (*Str - '0');
> -} else {
> -  return EFI_INVALID_PARAMETER;
> -}
> -
> -//
> -// For odd characters, write the upper nibble for each buffer byte,
> -// and for even characters, the lower nibble.
> -//
> -if ((Index & 1) == 0) {
> -  Byte = (UINT8) (Digit << 4);
> -} else {
> -  Byte = Buf[Index / 2];
> -  Byte &= 0xF0;
> -  Byte = (UINT8) (Byte | Digit);
> -}
> -
> -Buf[Index / 2] = Byte;
> -  }
> -
> -  return EFI_SUCCESS;
> -}
> -
> -/**
> -  Converts a string to GUID value.
> -  Guid Format is ----
> -
> -  @param[in]  Str  The registry format GUID string that contains
> the GUID value.
> -  @param[out] Guid A pointer to the converted GUID value.
> -
> -  @retval EFI_SUCCESS The GUID string was successfully converted to the
> GUID value.
> -  @retval EFI_UNSUPPORTED The input string is not in registry format.
> -  @return others  Some error occurred when converting part of
> GUID value.
> -
> -**/
> -EFI_STATUS
> -IniAsciiStrToGuid (
> -  IN  CHAR8*Str,
> -  OUT EFI_GUID *Guid
> -  )
> -{
> -  //
> -  // Get the first UINT32 data
> -  //
> -  Guid->Data1 = (UINT32) AsciiStrHexToUint64  (Str);
> -  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
> -Str ++;
> -  }
> -
> -  if (IS_HYPHEN (*Str)) {
> -Str++;
> -  } else {
> -return EFI_UNSUPPORTED;
> -  }
> -
> -  //
> -  // Get the second UINT16 data
> -  //
> -  Guid->Data2 = (UINT16) AsciiStrHexToUint64  (Str);
> -  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
> -Str ++;
> -  }
> -
> -  if (IS_HYPHEN (*Str)) {
> -Str++;
> -  } else {
> -return EFI_UNSUPPORTED;
> -  }
> -
> -  //
> -  // Get the third UINT16 data
> -  //
> -  Guid->Data3 = (UINT16) AsciiStrHexToUint64  (Str);
> -  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
> -Str ++;
> -  }
> -
> -  if (IS_HYPHEN (*Str)) {
> -Str++;
> -  } else {
> -return EFI_UNSUPPORTED;
> -  }
> -
> -  //
> -  // Get the following 8 bytes data
> -  //
> -  AsciiStrToBuf (>Data4[0], 2, Str);
> -  //
> -  // Skip 2 byte hex chars
> -  //
> -  Str += 2 * 2;
> -
> -  if (IS_HYPHEN (*Str)) {
> -Str++;
> -  } else {
> -return EFI_UNSUPPORTED;
> -  }
> -  AsciiStrToBuf (>Data4[2], 6, Str);
> -
> -  

Re: [edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Gao, Liming]

Rebecca:
  Yes. It is good to enable multiple thread and update ReadMe.MD. On .cmd/.bat 
vs python, .cmd/.bat doesn't require to install Python in windows OS. 
edksetup.bat is just a case. 

Thanks
Liming
>-Original Message-
>From: Rebecca Cran [mailto:rebe...@bluestop.org]
>Sent: Wednesday, February 22, 2017 1:48 PM
>To: Gao, Liming ; edk2-devel@lists.01.org
>Cc: Lu, ShifeiX A ; Zimmer, Vincent
>; Wei, David ; Andrew
>Fish ; Gao, Liming 
>Subject: Re: [edk2] Improvements to build system etc. for edk2-platforms
>devel-MinnowBoard3?
>
>On 2/21/2017 9:50 PM, Gao, Liming wrote:
>
>>Could you introduce what change will be done for build improvement? I
>am also interested in this topic.
>
>The first change I'd make is to set 'buildthreads' in BuildBIOS to
>%NUMBER_OF_PROCESSORS% - that by itself reduces the build time from
>around 7 minutes to 2.5 on my system. I also have some changes to the
>ReadMe.MD file to convert it to be a MD file instead of plain text,
>which massively increases readability on GitHub.  I've also been
>wondering about allowing more parameters to be passed through to 'build'
>such as reducing the verbosity to make compiler warnings more apparent.
>Finally, and this is likely more controversial - I've been wondering if
>the build scripts like BuildBIOS should be in python instead of Windows
>.cmd/.bat since python is already used elsewhere and is more flexible.
>
>--
>Rebecca
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Fix hard code actual TimerPeriod value

[Tian, Feng]

Reviewed-by: Feng Tian 

-Original Message-
From: Fan, Jeff 
Sent: Monday, February 20, 2017 4:38 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Kinney, Michael D 

Subject: [PATCH] UefiCpuPkg/CpuDxe: Fix hard code actual TimerPeriod value

Current CpuGetTimerValue() implementation return hard code TimerPeriod value. 
We could calculate the actual TimerPeriod value over period of time (100us) at 
the first time invoking CpuGetTimerValue() and save the TimerPeriod value into 
one global variable to avoid delay at the next CpuGetTimerValue() invoking.

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

Cc: Feng Tian 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/CpuDxe/CpuDxe.c   | 26 +++---
 UefiCpuPkg/CpuDxe/CpuDxe.h   |  3 ++-
 UefiCpuPkg/CpuDxe/CpuDxe.inf |  3 ++-
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c index 
f6d0a67..9fb6d76 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -1,7 +1,7 @@
 /** @file
   CPU DXE Module to produce CPU ARCH Protocol.
 
-  Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2017, 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
@@ -23,6 +23,7 @@ EFI_HANDLEmCpuHandle = NULL;
 BOOLEAN   mIsFlushingGCD;
 UINT64mValidMtrrAddressMask = MTRR_LIB_CACHE_VALID_ADDRESS;
 UINT64mValidMtrrBitsMask= MTRR_LIB_MSR_VALID_MASK;
+UINT64mTimerPeriod = 0;
 
 FIXED_MTRRmFixedMtrrTable[] = {
   {
@@ -293,6 +294,9 @@ CpuGetTimerValue (
   OUT UINT64*TimerPeriod OPTIONAL
   )
 {
+  UINT64  BeginValue;
+  UINT64  EndValue;
+
   if (TimerValue == NULL) {
 return EFI_INVALID_PARAMETER;
   }
@@ -304,10 +308,26 @@ CpuGetTimerValue (
   *TimerValue = AsmReadTsc ();
 
   if (TimerPeriod != NULL) {
+if (mTimerPeriod == 0) {
+  //
+  // Read time stamp counter before and after delay of 100 
+ microseconds
   //
-  // BugBug: Hard coded. Don't know how to do this generically
+  BeginValue = AsmReadTsc ();
+  MicroSecondDelay (100);
+  EndValue   = AsmReadTsc ();
   //
-  *TimerPeriod = 10;
+  // Calculate the actual frequency
+  //
+  mTimerPeriod = DivU64x64Remainder (
+   MultU64x32 (
+ 1000 * 1000 * 1000,
+ 100
+ ),
+   EndValue - BeginValue,
+   NULL
+   );
+}
+*TimerPeriod = mTimerPeriod;
   }
 
   return EFI_SUCCESS;
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.h b/UefiCpuPkg/CpuDxe/CpuDxe.h index 
6dd0ad3..27ad45b 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.h
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.h
@@ -1,7 +1,7 @@
 /** @file
   CPU DXE Module to produce CPU ARCH Protocol and CPU MP Protocol.
 
-  Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2017, 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 @@ -39,6 +39,7 @@  #include   #include 
  #include 
+#include 
 
 #include 
 #include 
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf index 
bf389bb..3cedce1 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  CPU driver installs CPU Architecture Protocol and CPU MP protocol.
 #
-#  Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2008 - 2017, 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 @@ 
-44,6 +44,7 @@
   HobLib
   ReportStatusCodeLib
   MpInitLib
+  TimerLib
 
 [Sources]
   CpuDxe.c
--
2.9.3.windows.2

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

Re: [edk2] [PATCH 00/12] Add SmiHandlerProfile feature

[Zeng, Star]

Reviewed-by: Star Zeng  to MdeModulePkg changes.

Thanks,
Star
-Original Message-
From: Yao, Jiewen 
Sent: Thursday, February 9, 2017 12:30 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Gao, Liming 
; Tian, Feng ; Zeng, Star 
; Laszlo Ersek 
Subject: [PATCH 00/12] Add SmiHandlerProfile feature

This series patch add SMI handler profile.

The purpose of SMI handler profile is to add the capability to dump all SMI 
handlers produced by the firmware in a given boot.
The SMI handlers here include
1) Root SMI handlers registered with SMST->SmiHandlerRegister by SmmCore.
2) GUID SMI handlers registered with SMST->SmiHandlerRegister by SmmCore.
3) Hardware SMI handlers registered with SMM_XXX_DISPATCH_PROTOCOL->Register
by SmmChildDispatcher module.

The final log is an XML format log, including all SMM image name, all SMI 
handlers name, type, location (source file and line number), and the caller who 
registeres the handler.

We enabled Quark platform to show how to add support in SmmChildDispatcher.

NOTE: This SMI handler profile is a *DEBUG* feature only, to help platform 
developer or test engineer to audit the SMI handlers. Please do not include it 
in the final *RELEASE* image.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Feng Tian 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 

Jiewen Yao (12):
  MdePkg/Include: Add SmiHandlerProfileLib.h
  MdePkg/SmiHandlerProfileLibNull: Add NULL instance.
  MdePkg/dsc: add SmiHandlerProfileLib to dsc.
  MdeModulePkg/include: Add SmiHandlerProfile header file.
  MdeModulePkg/dec: Add PcdSmiHandlerProfilePropertyMask.
  MdeModulePkg/SmmSmiHandlerProfileLib: Add SMM instance.
  MdeModulePkg/PiSmmCore: Add SmiHandlerProfile support.
  MdeModulePkg/App: Add SmiHandlerProfile dump app.
  MdeModulePkg/dsc: add SmiHandlerProfile to dsc.
  BaseTool/Script: Add SmiHandleProfile OS tool to get symbol.
  QuarkSocPkg/SmmChildDispatch: Add SmiHandlerProfile support.
  QuarkPlatformPkg: enable SmiHandlerProfile.

 BaseTools/Scripts/SmiHandlerProfileSymbolGen.py
|  351 ++
 MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.c 
|  685 +++
 MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.inf   
|   65 +
 MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.uni   
|   22 +
 MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfoExtra.uni  
|   19 +
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
|4 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
|   89 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf  
|   17 +-
 MdeModulePkg/Core/PiSmmCore/Smi.c  
|   46 +-
 MdeModulePkg/Core/PiSmmCore/SmiHandlerProfile.c
| 1261 
 MdeModulePkg/Include/Guid/SmiHandlerProfile.h  
|  177 +++
 MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.c 
|  106 ++
 MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.inf   
|   46 +
 MdeModulePkg/Library/SmmSmiHandlerProfileLib/SmmSmiHandlerProfileLib.uni   
|   21 +
 MdeModulePkg/MdeModulePkg.dec  
|   11 +-
 MdeModulePkg/MdeModulePkg.dsc  
|2 +
 MdePkg/Include/Library/SmiHandlerProfileLib.h  
|   81 ++
 MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.c 
|   72 ++
 MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.inf   
|   36 +
 MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.uni   
|   21 +
 MdePkg/MdePkg.dec  
|5 +-
 MdePkg/MdePkg.dsc  
|3 +-
 QuarkPlatformPkg/Quark.dsc 
|   16 +-
 QuarkPlatformPkg/Quark.fdf 
|3 +-
 QuarkPlatformPkg/QuarkMin.dsc  
|5 +-
 QuarkPlatformPkg/Readme.md 
|   29 +-
 QuarkSocPkg/QuarkNorthCluster/Smm/DxeSmm/QncSmmDispatcher/QNCSmmCore.c 
|   19 +-
 QuarkSocPkg/QuarkNorthCluster/Smm/DxeSmm/QncSmmDispatcher/QNCSmmDispatcher.inf 
|3 +-
 28 files changed, 3159 insertions(+), 56 deletions(-)  create mode 100644 

Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3] Enable Secure Boot.

[Wei, David]

Reviewed-by: zwei4  

Thanks,
David  Wei 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of lushifex
Sent: Wednesday, February 22, 2017 2:35 PM
To: edk2-devel@lists.01.org
Cc: Wei, David 
Subject: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3] Enable Secure Boot.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 .../PlatformSecureDefaultsLib.c| 952 -
 .../PlatformSecureDefaultsLib.inf  |  69 --
 .../Common/PlatformSettings/PlatformDxe/Platform.c |  17 +-
 .../PlatformSettings/PlatformDxe/PlatformDxe.inf   |   3 +-
 .../PlatformSetupDxe/PlatformSetupDxe.c|  39 +-
 .../PlatformSetupDxe/PlatformSetupDxe.inf  |   3 +-
 .../PlatformSettings/PlatformSetupDxe/Security.vfi |  37 +-
 .../PlatformSetupDxe/SetupInfoRecords.c|  89 +-
 .../PlatformSetupDxe/VfrStrings.uni| Bin 315770 -> 311660 bytes
 .../BroxtonPlatformPkg/PlatformDsc/Components.dsc  |  18 +-
 .../PlatformDsc/LibraryClasses.dsc |   2 -
 Platform/BroxtonPlatformPkg/PlatformPkg.fdf|  11 +-
 12 files changed, 69 insertions(+), 1171 deletions(-)
 delete mode 100644 
Platform/BroxtonPlatformPkg/Common/Library/PlatformSecureDefaultsLib/PlatformSecureDefaultsLib.c
 delete mode 100644 
Platform/BroxtonPlatformPkg/Common/Library/PlatformSecureDefaultsLib/PlatformSecureDefaultsLib.inf

diff --git 
a/Platform/BroxtonPlatformPkg/Common/Library/PlatformSecureDefaultsLib/PlatformSecureDefaultsLib.c
 
b/Platform/BroxtonPlatformPkg/Common/Library/PlatformSecureDefaultsLib/PlatformSecureDefaultsLib.c
deleted file mode 100644
index 2cdd01d..000
--- 
a/Platform/BroxtonPlatformPkg/Common/Library/PlatformSecureDefaultsLib/PlatformSecureDefaultsLib.c
+++ /dev/null
@@ -1,952 +0,0 @@
-/** @file
-  IPC based PlatformFvbLib library instance.
-
-  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php.
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "Library/PlatformSecureDefaultsLib.h"
-#include 
-#include 
-
-EFI_GUID mUefiImageSecurityDBGuid= EFI_IMAGE_SECURITY_DATABASE_GUID;
-EFI_GUID mUefiCertTypeRsa2048Guid= EFI_CERT_RSA2048_GUID;
-
-#define WIN_CERT_UEFI_RSA2048_SIZE256
-#define EFI_SECURE_BOOT_ENABLE_NAME   L"SecureBootEnable"
-
-extern EFI_GUID mUefiCertTypeRsa2048Guid;
-extern EFI_GUID gEfiSecureBootEnableDisableGuid;
-
-EFI_GUID gOwnerSignatureGUID = {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 
0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}};
-static EFI_GUID  gDbxUpdateImageGuid = {0xa3d48bb3, 0x350f, 0x4bcd, 0xa4, 
0xad, 0x44, 0x5b, 0x93, 0x9f, 0x6d, 0x9c };
-
-/**
-  Create a time based data payload by concatenating the 
EFI_VARIABLE_AUTHENTICATION_2
-  descriptor with the input data. NO authentication is required in this 
function.
-
-  @param[in, out]   DataSize On input, the size of Data buffer 
in bytes.
- On output, the size of data 
returned in Data
- buffer in bytes.
-  @param[in, out]   Data On input, Pointer to data buffer 
to be wrapped or
- pointer to NULL to wrap an empty 
payload.
- On output, Pointer to the new 
payload date buffer allocated from pool,
- it's caller's responsibility to 
free the memory when finish using it.
-
-  @retval   EFI_SUCCESS  Create time based payload 
successfully.
-  @retval   EFI_OUT_OF_RESOURCES There are not enough memory 
resourses to create time based payload.
-  @retval   EFI_INVALID_PARAMETERThe parameter is invalid.
-  @retval   Others   Unexpected error happens.
-
-**/
-EFI_STATUS
-CreateTimeBasedPayload (
-  IN OUT UINTN*DataSize,
-  IN OUT UINT8**Data
-  )
-{
-  EFI_STATUS   Status;
-  UINT8*NewData;
-  UINT8*Payload;
-  UINTNPayloadSize;
-  EFI_VARIABLE_AUTHENTICATION_2*DescriptorData;
-  UINTNDescriptorSize;
-  EFI_TIME Time;
-
-  if (Data == NULL || DataSize == NULL) {
-return EFI_INVALID_PARAMETER;
-  }
-
-  //
-  // In Setup mode or Custom mode, the variable does not 

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3] Enable Secure Boot.

[lushifex]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 .../PlatformSecureDefaultsLib.c| 952 -
 .../PlatformSecureDefaultsLib.inf  |  69 --
 .../Common/PlatformSettings/PlatformDxe/Platform.c |  17 +-
 .../PlatformSettings/PlatformDxe/PlatformDxe.inf   |   3 +-
 .../PlatformSetupDxe/PlatformSetupDxe.c|  39 +-
 .../PlatformSetupDxe/PlatformSetupDxe.inf  |   3 +-
 .../PlatformSettings/PlatformSetupDxe/Security.vfi |  37 +-
 .../PlatformSetupDxe/SetupInfoRecords.c|  89 +-
 .../PlatformSetupDxe/VfrStrings.uni| Bin 315770 -> 311660 bytes
 .../BroxtonPlatformPkg/PlatformDsc/Components.dsc  |  18 +-
 .../PlatformDsc/LibraryClasses.dsc |   2 -
 Platform/BroxtonPlatformPkg/PlatformPkg.fdf|  11 +-
 12 files changed, 69 insertions(+), 1171 deletions(-)
 delete mode 100644 
Platform/BroxtonPlatformPkg/Common/Library/PlatformSecureDefaultsLib/PlatformSecureDefaultsLib.c
 delete mode 100644 
Platform/BroxtonPlatformPkg/Common/Library/PlatformSecureDefaultsLib/PlatformSecureDefaultsLib.inf

diff --git 
a/Platform/BroxtonPlatformPkg/Common/Library/PlatformSecureDefaultsLib/PlatformSecureDefaultsLib.c
 
b/Platform/BroxtonPlatformPkg/Common/Library/PlatformSecureDefaultsLib/PlatformSecureDefaultsLib.c
deleted file mode 100644
index 2cdd01d..000
--- 
a/Platform/BroxtonPlatformPkg/Common/Library/PlatformSecureDefaultsLib/PlatformSecureDefaultsLib.c
+++ /dev/null
@@ -1,952 +0,0 @@
-/** @file
-  IPC based PlatformFvbLib library instance.
-
-  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php.
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "Library/PlatformSecureDefaultsLib.h"
-#include 
-#include 
-
-EFI_GUID mUefiImageSecurityDBGuid= EFI_IMAGE_SECURITY_DATABASE_GUID;
-EFI_GUID mUefiCertTypeRsa2048Guid= EFI_CERT_RSA2048_GUID;
-
-#define WIN_CERT_UEFI_RSA2048_SIZE256
-#define EFI_SECURE_BOOT_ENABLE_NAME   L"SecureBootEnable"
-
-extern EFI_GUID mUefiCertTypeRsa2048Guid;
-extern EFI_GUID gEfiSecureBootEnableDisableGuid;
-
-EFI_GUID gOwnerSignatureGUID = {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 
0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}};
-static EFI_GUID  gDbxUpdateImageGuid = {0xa3d48bb3, 0x350f, 0x4bcd, 0xa4, 
0xad, 0x44, 0x5b, 0x93, 0x9f, 0x6d, 0x9c };
-
-/**
-  Create a time based data payload by concatenating the 
EFI_VARIABLE_AUTHENTICATION_2
-  descriptor with the input data. NO authentication is required in this 
function.
-
-  @param[in, out]   DataSize On input, the size of Data buffer 
in bytes.
- On output, the size of data 
returned in Data
- buffer in bytes.
-  @param[in, out]   Data On input, Pointer to data buffer 
to be wrapped or
- pointer to NULL to wrap an empty 
payload.
- On output, Pointer to the new 
payload date buffer allocated from pool,
- it's caller's responsibility to 
free the memory when finish using it.
-
-  @retval   EFI_SUCCESS  Create time based payload 
successfully.
-  @retval   EFI_OUT_OF_RESOURCES There are not enough memory 
resourses to create time based payload.
-  @retval   EFI_INVALID_PARAMETERThe parameter is invalid.
-  @retval   Others   Unexpected error happens.
-
-**/
-EFI_STATUS
-CreateTimeBasedPayload (
-  IN OUT UINTN*DataSize,
-  IN OUT UINT8**Data
-  )
-{
-  EFI_STATUS   Status;
-  UINT8*NewData;
-  UINT8*Payload;
-  UINTNPayloadSize;
-  EFI_VARIABLE_AUTHENTICATION_2*DescriptorData;
-  UINTNDescriptorSize;
-  EFI_TIME Time;
-
-  if (Data == NULL || DataSize == NULL) {
-return EFI_INVALID_PARAMETER;
-  }
-
-  //
-  // In Setup mode or Custom mode, the variable does not need to be signed but 
the
-  // parameters to the SetVariable() call still need to be prepared as 
authenticated
-  // variable. So we create EFI_VARIABLE_AUTHENTICATED_2 descriptor without 
certificate
-  // data in it.
-  //
-  Payload = *Data;
-  PayloadSize = *DataSize;
-
-  DescriptorSize= OFFSET_OF (EFI_VARIABLE_AUTHENTICATION_2, AuthInfo) + 
OFFSET_OF 

Re: [edk2] Intel raid EFI Shell driver wanted

[Rafael Machado]

Hi David.

Theo only UEFI RAID driver I know is for LSI controllers.
This is the link with the details:

https://www.broadcom.com/support/knowledgebase/1211161503938/lsi-preboot-efi-packages-for-flashing-lsi-products

Thanks
Rafael

Em ter, 21 de fev de 2017 23:16, david moheban 
escreveu:

> Hi,
>
> Was wondering if there exists an Intel Raid EFI driver that would allow one
> to view the contents of an Intel Raid array within a EFI shell?
>
> Thank you.
> ___
> 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 04/11] MdePkg/BaseLib: Add StrToGuid/StrHexToBytes/StrToIpv[4/6]Address

[Yao, Jiewen]

Thanks.

I suggest we clearly say: This function does not support the leading pad space 
, which includes spaces or tab characters, before the first valid char.

For example, "1.2.3.4" is considered as invalid IPv4 address.
And I suggest we return EFI_UNSUPPORTED.

The comment is applied to add [Ascii]StrToGuid/IpV4/IpV6.

Thank you
Yao Jiewen

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, February 22, 2017 12:51 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Yao, Jiewen ;
> Fu, Siyuan 
> Subject: [PATCH 04/11] MdePkg/BaseLib: Add
> StrToGuid/StrHexToBytes/StrToIpv[4/6]Address
> 
> The patch adds 4 APIs to convert Unicode string to GUID, bytes
> buffer, IP v4 address and IP v6 address.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Liming Gao 
> Cc: Jiewen Yao 
> Cc: Siyuan Fu 
> ---
>  MdePkg/Include/Library/BaseLib.h| 241 ++
>  MdePkg/Library/BaseLib/SafeString.c | 623
> 
>  2 files changed, 864 insertions(+)
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index d71ccb7..8aac4c8 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -1536,6 +1536,247 @@ StrHexToUint64 (
>IN  CONST CHAR16 *String
>);
> 
> +/**
> +  Convert a Null-terminated Unicode string to IPv6 address and prefix length.
> +
> +  This function outputs a value of type IPv6_ADDRESS and may output a value
> +  of type UINT8 by interpreting the contents of the Unicode string specified
> +  by String. The format of the input Unicode string String is as follows:
> +
> +  X:X:X:X:X:X:X:X[/P]
> +
> +  X contains one to four hexadecimal digit characters in the range [0-9], 
> [a-f]
> and
> +  [A-F]. X is converted to a value of type UINT16, whose low byte is stored 
> in
> low
> +  memory address and high byte is stored in high memory address. P contains
> decimal
> +  digit characters in the range [0-9]. The running zero in the beginning of 
> P will
> +  be ignored. /P is optional.
> +
> +  When /P is not in the String, the function stops at the first character 
> that is
> +  not a valid hexadecimal digit character after eight X's are converted.
> +
> +  When /P is in the String, the function stops at the first character that 
> is not
> +  a valid decimal digit character after P is converted.
> +
> +  "::" can be used to compress one or more groups of X when X contains only 
> 0.
> +  The "::" can only appear once in the String.
> +
> +  If String is NULL, then ASSERT().
> +
> +  If Address is NULL, then ASSERT().
> +
> +  If String is not aligned in a 16-bit boundary, then ASSERT().
> +
> +  If PcdMaximumUnicodeStringLength is not zero, and String contains more
> than
> +  PcdMaximumUnicodeStringLength Unicode characters, not including the
> +  Null-terminator, then ASSERT().
> +
> +  If EndPointer is not NULL and Address is translated from String, a pointer
> +  to the character that stopped the scan is stored at the location pointed to
> +  by EndPointer.
> +
> +  @param  String   Pointer to a Null-terminated Unicode
> string.
> +  @param  EndPointer   Pointer to character that stops scan.
> +  @param  Address  Pointer to the converted IPv6
> address.
> +  @param  PrefixLength Pointer to the converted IPv6 address
> prefix
> +   length. MAX_UINT8 is returned when
> /P is
> +   not in the String.
> +
> +  @retval RETURN_SUCCESS   Address is translated from String.
> +  @retval RETURN_INVALID_PARAMETER If String is NULL.
> +   If Data is NULL.
> +   If PcdMaximumUnicodeStringLength is
> not
> +zero, and String contains more than
> +PcdMaximumUnicodeStringLength
> Unicode
> +characters, not including the
> +Null-terminator.
> +   If X contains more than four
> hexadecimal
> +digit characters.
> +   If String contains "::" and number of X
> +is not less than 8.
> +   If P starts with character that is not a
> +valid decimal digit character.
> +   If the decimal number converted from
> P
> +exceeds 128.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +StrToIpv6Address (
> +  IN  CONST CHAR16   *String,
> +  OUT CHAR16 **EndPointer, OPTIONAL
> +  

Re: [edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Rebecca Cran]

On 2/21/2017 9:50 PM, Gao, Liming wrote:


   Could you introduce what change will be done for build improvement? I am 
also interested in this topic.


The first change I'd make is to set 'buildthreads' in BuildBIOS to 
%NUMBER_OF_PROCESSORS% - that by itself reduces the build time from 
around 7 minutes to 2.5 on my system. I also have some changes to the 
ReadMe.MD file to convert it to be a MD file instead of plain text, 
which massively increases readability on GitHub.  I've also been 
wondering about allowing more parameters to be passed through to 'build' 
such as reducing the verbosity to make compiler warnings more apparent. 
Finally, and this is likely more controversial - I've been wondering if 
the build scripts like BuildBIOS should be in python instead of Windows 
.cmd/.bat since python is already used elsewhere and is more flexible.


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

Re: [edk2] [PATCH 10/11] SignedCapsulePkg/IniParsingLib: Use AsciiStrToGuid in BaseLib

[Yao, Jiewen]

Hi
I do not suggest we use below check.

  if (RETURN_ERROR (AsciiStrToGuid (Value, Guid))) {

I suggest we use below style, because it may help source level debug to see 
what Status is returned.

  Status = AsciiStrToGuid (Value, Guid);
  if (EFI_ERROR (Status)) {

The suggestion is applied to all patches, such as CapsuleApp


Thank you
Yao Jiewen

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, February 22, 2017 12:51 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [PATCH 10/11] SignedCapsulePkg/IniParsingLib: Use AsciiStrToGuid in
> BaseLib
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Jiewen Yao 
> ---
>  .../Library/IniParsingLib/IniParsingLib.c  | 141 
> +
>  1 file changed, 1 insertion(+), 140 deletions(-)
>
> diff --git a/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
> b/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
> index 16e1349..e9c2cc5 100644
> --- a/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
> +++ b/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
> @@ -862,144 +862,6 @@ UpdateGetProfileString (
>  }
>
>  /**
> -  Converts a list of string to a specified buffer.
> -
> -  @param[out] Buf The output buffer that contains the string.
> -  @param[in]  BufferLengthThe length of the buffer
> -  @param[in]  Str The input string that contains the hex number
> -
> -  @retval EFI_SUCCESSThe string was successfully converted to the buffer.
> -
> -**/
> -EFI_STATUS
> -AsciiStrToBuf (
> -  OUT UINT8*Buf,
> -  IN  UINTNBufferLength,
> -  IN  CHAR8*Str
> -  )
> -{
> -  UINTN   Index;
> -  UINTN   StrLength;
> -  UINT8   Digit;
> -  UINT8   Byte;
> -
> -  Digit = 0;
> -
> -  //
> -  // Two hex char make up one byte
> -  //
> -  StrLength = BufferLength * 2;
> -
> -  for(Index = 0; Index < StrLength; Index++, Str++) {
> -
> -if ((*Str >= 'a') && (*Str <= 'f')) {
> -  Digit = (UINT8) (*Str - 'a' + 0x0A);
> -} else if ((*Str >= 'A') && (*Str <= 'F')) {
> -  Digit = (UINT8) (*Str - 'A' + 0x0A);
> -} else if ((*Str >= '0') && (*Str <= '9')) {
> -  Digit = (UINT8) (*Str - '0');
> -} else {
> -  return EFI_INVALID_PARAMETER;
> -}
> -
> -//
> -// For odd characters, write the upper nibble for each buffer byte,
> -// and for even characters, the lower nibble.
> -//
> -if ((Index & 1) == 0) {
> -  Byte = (UINT8) (Digit << 4);
> -} else {
> -  Byte = Buf[Index / 2];
> -  Byte &= 0xF0;
> -  Byte = (UINT8) (Byte | Digit);
> -}
> -
> -Buf[Index / 2] = Byte;
> -  }
> -
> -  return EFI_SUCCESS;
> -}
> -
> -/**
> -  Converts a string to GUID value.
> -  Guid Format is ----
> -
> -  @param[in]  Str  The registry format GUID string that contains
> the GUID value.
> -  @param[out] Guid A pointer to the converted GUID value.
> -
> -  @retval EFI_SUCCESS The GUID string was successfully converted to the
> GUID value.
> -  @retval EFI_UNSUPPORTED The input string is not in registry format.
> -  @return others  Some error occurred when converting part of
> GUID value.
> -
> -**/
> -EFI_STATUS
> -IniAsciiStrToGuid (
> -  IN  CHAR8*Str,
> -  OUT EFI_GUID *Guid
> -  )
> -{
> -  //
> -  // Get the first UINT32 data
> -  //
> -  Guid->Data1 = (UINT32) AsciiStrHexToUint64  (Str);
> -  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
> -Str ++;
> -  }
> -
> -  if (IS_HYPHEN (*Str)) {
> -Str++;
> -  } else {
> -return EFI_UNSUPPORTED;
> -  }
> -
> -  //
> -  // Get the second UINT16 data
> -  //
> -  Guid->Data2 = (UINT16) AsciiStrHexToUint64  (Str);
> -  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
> -Str ++;
> -  }
> -
> -  if (IS_HYPHEN (*Str)) {
> -Str++;
> -  } else {
> -return EFI_UNSUPPORTED;
> -  }
> -
> -  //
> -  // Get the third UINT16 data
> -  //
> -  Guid->Data3 = (UINT16) AsciiStrHexToUint64  (Str);
> -  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
> -Str ++;
> -  }
> -
> -  if (IS_HYPHEN (*Str)) {
> -Str++;
> -  } else {
> -return EFI_UNSUPPORTED;
> -  }
> -
> -  //
> -  // Get the following 8 bytes data
> -  //
> -  AsciiStrToBuf (>Data4[0], 2, Str);
> -  //
> -  // Skip 2 byte hex chars
> -  //
> -  Str += 2 * 2;
> -
> -  if (IS_HYPHEN (*Str)) {
> -Str++;
> -  } else {
> -return EFI_UNSUPPORTED;
> -  }
> -  AsciiStrToBuf (>Data4[2], 6, Str);
> -
> -  return EFI_SUCCESS;
> -}
> -
> -/**
>Pre process config data buffer into Section entry list and Comment entry 
> list.
>
>@param[in]  DataBuffer  Config raw file buffer.
> @@ -1261,8 +1123,7 @@ GetGuidFromDataFile (
>if (!IsValidGuid(Value, AsciiStrLen(Value))) {
>  return EFI_NOT_FOUND;
>}
> -  Status = IniAsciiStrToGuid(Value, Guid);
> -  if (EFI_ERROR (Status)) {
> +  if 

Re: [edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Andrew Fish]

> On Feb 21, 2017, at 8:50 PM, Gao, Liming  wrote:
> 
> Rebecca:
>  Could you introduce what change will be done for build improvement? I am 
> also interested in this topic. 
> 

Me too.

Thanks,

Andrew Fish

> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Rebecca Cran
>> Sent: Wednesday, February 22, 2017 9:21 AM
>> To: edk2-devel@lists.01.org
>> Cc: Lu, ShifeiX A ; Zimmer, Vincent
>> ; Wei, David 
>> Subject: [edk2] Improvements to build system etc. for edk2-platforms devel-
>> MinnowBoard3?
>> 
>> I'm a bit of a build system geek and noticed there are some improvements
>> (e.g. improving build speed) that could be made to the
>> devel-MinnowBoard3 branch in edk2-platforms.  I know it's still in heavy
>> development, so I'm wondering if my contributions might be welcome, or
>> if I should hold off for a few more months?
>> 
>> 
>> --
>> 
>> Rebecca
>> 
>> ___
>> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 08/11] SecurityPkg/SecureBootConfigDxe: Use StrToGuid in BaseLib

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
---
 .../SecureBootConfigDxe/SecureBootConfigImpl.c |  11 +-
 .../SecureBootConfigDxe/SecureBootConfigImpl.h |  22 +---
 .../SecureBootConfigDxe/SecureBootConfigMisc.c | 141 +
 3 files changed, 6 insertions(+), 168 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
index 0d96185..9b7d0c1 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
+++ 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
@@ -1,7 +1,7 @@
 /** @file
   HII Config Access protocol implementation of SecureBoot configuration module.
 
-Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2017, 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
@@ -3636,12 +3636,9 @@ SecureBootCallback (
 case KEY_SECURE_BOOT_SIGNATURE_GUID_DBX:
 case KEY_SECURE_BOOT_SIGNATURE_GUID_DBT:
   ASSERT (Private->SignatureGUID != NULL);
-  Status = StringToGuid (
- IfrNvData->SignatureGuid,
- StrLen (IfrNvData->SignatureGuid),
- Private->SignatureGUID
- );
-  if (EFI_ERROR (Status)) {
+  if (RETURN_ERROR (StrToGuid (IfrNvData->SignatureGuid, 
Private->SignatureGUID)) ||
+  (IfrNvData->SignatureGuid[GUID_STRING_LENGTH] != L'\0')) {
+Status = EFI_INVALID_PARAMETER;
 break;
   }
 
diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h
index 5055a9e..aa58c44 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h
+++ 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h
@@ -2,7 +2,7 @@
   The header file of HII Config Access protocol implementation of SecureBoot
   configuration module.
 
-Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2017, 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
@@ -479,26 +479,6 @@ Int2OctStr (
   IN UINTN OSSizeInBytes
   );
 
-
-/**
-  Convert a String to Guid Value.
-
-  @param[in]   StrSpecifies the String to be converted.
-  @param[in]   StrLen Number of Unicode Characters of String (exclusive \0)
-  @param[out]  Guid   Return the result Guid value.
-
-  @retvalEFI_SUCCESS   The operation is finished successfully.
-  @retvalEFI_NOT_FOUND Invalid string.
-
-**/
-EFI_STATUS
-StringToGuid (
-  IN   CHAR16   *Str,
-  IN   UINTNStrLen,
-  OUT  EFI_GUID *Guid
-  );
-
-
 /**
   Worker function that prints an EFI_GUID into specified Buffer.
 
diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigMisc.c 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigMisc.c
index a83504e..038707c 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigMisc.c
+++ 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigMisc.c
@@ -1,7 +1,7 @@
 /** @file
   Helper functions for SecureBoot configuration module.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2017, 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
@@ -152,145 +152,6 @@ Int2OctStr (
   return EFI_SUCCESS;
 }
 
-
-
-/**
-  Convert a String to Guid Value.
-
-  @param[in]   StrSpecifies the String to be converted.
-  @param[in]   StrLen Number of Unicode Characters of String (exclusive \0)
-  @param[out]  Guid   Return the result Guid value.
-
-  @retvalEFI_SUCCESS   The operation is finished successfully.
-  @retvalEFI_NOT_FOUND Invalid string.
-
-**/
-EFI_STATUS
-StringToGuid (
-  IN   CHAR16   *Str, 
-  IN   UINTNStrLen, 
-  OUT  EFI_GUID *Guid
-  )
-{
-  CHAR16 *PtrBuffer;
-  CHAR16 *PtrPosition;
-  UINT16 *Buffer;
-  UINTN  Data;
-  UINTN  Index;
-  UINT16 Digits[3];
-
-  Buffer = (CHAR16 *) AllocateZeroPool 

[edk2] [PATCH 09/11] ShellPkg/Debug1CommandLib: Use StrToGuid/StrHexToBytes in BaseLib

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../Library/UefiShellDebug1CommandsLib/DmpStore.c  |   5 +-
 .../Library/UefiShellDebug1CommandsLib/SetVar.c|  10 +-
 .../UefiShellDebug1CommandsLib.c   | 119 +
 .../UefiShellDebug1CommandsLib.h   |  32 +-
 4 files changed, 7 insertions(+), 159 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/DmpStore.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/DmpStore.c
index bb2c0b9..e5b91ef 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/DmpStore.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/DmpStore.c
@@ -2,7 +2,7 @@
   Main file for DmpStore shell Debug1 function.

   (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2005 - 2017, 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
@@ -728,8 +728,7 @@ ShellCommandRunDmpStore (
   if (!ShellCommandLineGetFlag(Package, L"-all")) {
 GuidStr = ShellCommandLineGetValue(Package, L"-guid");
 if (GuidStr != NULL) {
-  Status = ConvertStringToGuid(GuidStr, );
-  if (EFI_ERROR(Status)) {
+  if (RETURN_ERROR (StrToGuid (GuidStr, )) || 
(GuidStr[GUID_STRING_LENGTH] != L'\0')) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_PARAM_INV), 
gShellDebug1HiiHandle, L"dmpstore", GuidStr);  
 ShellStatus = SHELL_INVALID_PARAMETER;
   }
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
index d98a346..7bd7b0f 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
@@ -2,7 +2,7 @@
   Main file for SetVar shell Debug1 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2017, 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
@@ -120,8 +120,7 @@ ShellCommandRunSetVar (
 CopyGuid(, );
   } else {
 StringGuid = ShellCommandLineGetValue(Package, L"-guid");
-Status = ConvertStringToGuid(StringGuid, );
-if (EFI_ERROR(Status)) {
+if (RETURN_ERROR (StrToGuid (StringGuid, )) || 
(StringGuid[GUID_STRING_LENGTH] != L'\0')) {
   ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_PARAM_INV), 
gShellDebug1HiiHandle, L"setvar", StringGuid);  
   ShellStatus = SHELL_INVALID_PARAMETER;
 }
@@ -207,10 +206,7 @@ ShellCommandRunSetVar (
 if (Buffer == NULL) {
   Status = EFI_OUT_OF_RESOURCES;
 } else {
-  for (LoopVar = 0 ; LoopVar < (StrLen(Data) / 2) ; LoopVar++) {
-((UINT8*)Buffer)[LoopVar] = 
(UINT8)(HexCharToUintn(Data[LoopVar*2]) * 16);
-((UINT8*)Buffer)[LoopVar] = (UINT8)(((UINT8*)Buffer)[LoopVar] 
+ HexCharToUintn(Data[LoopVar*2+1]));
-  }
+  StrHexToBytes (Data, StrLen (Data), Buffer, StrLen (Data) / 2);
   Status = gRT->SetVariable((CHAR16*)VariableName, , 
Attributes, StrLen(Data) / 2, Buffer);
 }
 if (EFI_ERROR(Status)) {
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
index 6ebf002..8e2141b 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
@@ -1,7 +1,7 @@
 /** @file
   Main file for NULL named library for debug1 profile shell command functions.
 
-  Copyright (c) 2010 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2017, 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
@@ -172,123 +172,6 @@ GetSystemConfigurationTable (
 }
 
 /**
-  Convert a Unicode character to numerical value.
-
-  This internal function only deal with Unicode character
-  which maps to a valid hexadecimal ASII character, i.e.
-  L'0' to L'9', L'a' to L'f' or L'A' to L'F'. For other
-  Unicode character, the value returned does not make sense.
-
-  @param  Char  The 

Re: [edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Gao, Liming]

Rebecca:
  Could you introduce what change will be done for build improvement? I am also 
interested in this topic. 

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Rebecca Cran
>Sent: Wednesday, February 22, 2017 9:21 AM
>To: edk2-devel@lists.01.org
>Cc: Lu, ShifeiX A ; Zimmer, Vincent
>; Wei, David 
>Subject: [edk2] Improvements to build system etc. for edk2-platforms devel-
>MinnowBoard3?
>
>I'm a bit of a build system geek and noticed there are some improvements
>(e.g. improving build speed) that could be made to the
>devel-MinnowBoard3 branch in edk2-platforms.  I know it's still in heavy
>development, so I'm wondering if my contributions might be welcome, or
>if I should hold off for a few more months?
>
>
>--
>
>Rebecca
>
>___
>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 11/11] MdeModulePkg/NetLib: Use StrToIpv4/6Address in BaseLib

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Siyuan Fu 
---
 MdeModulePkg/Include/Library/NetLib.h  |   5 +-
 MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 382 +++--
 2 files changed, 32 insertions(+), 355 deletions(-)

diff --git a/MdeModulePkg/Include/Library/NetLib.h 
b/MdeModulePkg/Include/Library/NetLib.h
index 09ead09..6773ed5 100644
--- a/MdeModulePkg/Include/Library/NetLib.h
+++ b/MdeModulePkg/Include/Library/NetLib.h
@@ -2,7 +2,7 @@
   This library is only intended to be used by UEFI network stack modules.
   It provides basic functions for the UEFI network stack.
 
-Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, 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
@@ -1391,7 +1391,6 @@ NetLibAsciiStrToIp6 (
 
   @retval EFI_SUCCESSConverted to an IPv4 address successfully.
   @retval EFI_INVALID_PARAMETER  The string is mal-formatted or Ip4Address is 
NULL.
-  @retval EFI_OUT_OF_RESOURCES   Failed to perform the operation due to lack 
of resources.
 
 **/
 EFI_STATUS
@@ -1410,7 +1409,6 @@ NetLibStrToIp4 (
 
   @retval EFI_SUCCESSConverted to an IPv6 address successfully.
   @retval EFI_INVALID_PARAMETER  The string is malformatted or Ip6Address is 
NULL.
-  @retval EFI_OUT_OF_RESOURCES   Failed to perform the operation due to a lack 
of resources.
 
 **/
 EFI_STATUS
@@ -1431,7 +1429,6 @@ NetLibStrToIp6 (
 
   @retval EFI_SUCCESSConverted to an  IPv6 address successfully.
   @retval EFI_INVALID_PARAMETER  The string is malformatted, or Ip6Address is 
NULL.
-  @retval EFI_OUT_OF_RESOURCES   Failed to perform the operation due to a lack 
of resources.
 
 **/
 EFI_STATUS
diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c 
b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
index 0a7117c..37b89f5 100644
--- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
+++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
@@ -1,7 +1,7 @@
 /** @file
   Network library.
 
-Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 (C) Copyright 2015 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
@@ -2709,63 +2709,15 @@ NetLibAsciiStrToIp4 (
   OUT  EFI_IPv4_ADDRESS  *Ip4Address
   )
 {
-  UINT8  Index;
-  CHAR8  *Ip4Str;
-  CHAR8  *TempStr;
-  UINTN  NodeVal;
+  RETURN_STATUS  Status;
+  CHAR8  *EndPointer;
 
-  if ((String == NULL) || (Ip4Address == NULL)) {
+  Status = AsciiStrToIpv4Address (String, , Ip4Address, NULL);
+  if (RETURN_ERROR (Status) || (*EndPointer != '\0')) {
 return EFI_INVALID_PARAMETER;
+  } else {
+return EFI_SUCCESS;
   }
-
-  Ip4Str = (CHAR8 *) String;
-
-  for (Index = 0; Index < 4; Index++) {
-TempStr = Ip4Str;
-
-while ((*Ip4Str != '\0') && (*Ip4Str != '.')) {
-  if (Index != 3 && !NET_IS_DIGIT (*Ip4Str)) {
-return EFI_INVALID_PARAMETER;
-  }
-  
-  //
-  // Allow the IPv4 with prefix case, e.g. 192.168.10.10/24 
-  //
-  if (Index == 3 && !NET_IS_DIGIT (*Ip4Str) && *Ip4Str != '/') {
-return EFI_INVALID_PARAMETER;
-  }
-  
-  Ip4Str++;
-}
-
-//
-// The IPv4 address is X.X.X.X
-//
-if (*Ip4Str == '.') {
-  if (Index == 3) {
-return EFI_INVALID_PARAMETER;
-  }
-} else {
-  if (Index != 3) {
-return EFI_INVALID_PARAMETER;
-  }
-}
-
-//
-// Convert the string to IPv4 address. AsciiStrDecimalToUintn stops at the
-// first character that is not a valid decimal character, '.' or '\0' here.
-//
-NodeVal = AsciiStrDecimalToUintn (TempStr);
-if (NodeVal > 0xFF) {
-  return EFI_INVALID_PARAMETER;
-}
-
-Ip4Address->Addr[Index] = (UINT8) NodeVal;
-
-Ip4Str++;
-  }
-
-  return EFI_SUCCESS;
 }
 
 
@@ -2787,193 +2739,15 @@ NetLibAsciiStrToIp6 (
   OUT  EFI_IPv6_ADDRESS  *Ip6Address
   )
 {
-  UINT8  Index;
-  CHAR8  *Ip6Str;
-  CHAR8  *TempStr;
-  CHAR8  *TempStr2;
-  UINT8  NodeCnt;
-  UINT8  TailNodeCnt;
-  UINT8  AllowedCnt;
-  UINTN  NodeVal;
-  BOOLEANShort;
-  BOOLEANUpdate;
-  BOOLEANLeadZero;
-  UINT8  LeadZeroCnt;
-  UINT8  

[edk2] [PATCH 07/11] MdeModulePkg/CapsuleApp: Use StrToGuid in BaseLib

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
---
 MdeModulePkg/Application/CapsuleApp/AppSupport.c | 140 +--
 MdeModulePkg/Application/CapsuleApp/CapsuleApp.c |  25 +---
 2 files changed, 4 insertions(+), 161 deletions(-)

diff --git a/MdeModulePkg/Application/CapsuleApp/AppSupport.c 
b/MdeModulePkg/Application/CapsuleApp/AppSupport.c
index edc5f29..e39ab20 100644
--- a/MdeModulePkg/Application/CapsuleApp/AppSupport.c
+++ b/MdeModulePkg/Application/CapsuleApp/AppSupport.c
@@ -1,7 +1,7 @@
 /** @file
   A shell application that triggers capsule update process.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2017, 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
@@ -64,144 +64,6 @@ GetArg (
 }
 
 /**
-  Converts a list of string to a specified buffer.
-
-  @param[out] Buf The output buffer that contains the string.
-  @param[in]  BufferLengthThe length of the buffer
-  @param[in]  Str The input string that contains the hex number
-
-  @retval EFI_SUCCESSThe string was successfully converted to the buffer.
-
-**/
-EFI_STATUS
-InternalStrToBuf (
-  OUT UINT8*Buf,
-  IN  UINTNBufferLength,
-  IN  CHAR16   *Str
-  )
-{
-  UINTN   Index;
-  UINTN   StrLength;
-  UINT8   Digit;
-  UINT8   Byte;
-
-  Digit = 0;
-
-  //
-  // Two hex char make up one byte
-  //
-  StrLength = BufferLength * sizeof (CHAR16);
-
-  for(Index = 0; Index < StrLength; Index++, Str++) {
-
-if ((*Str >= L'a') && (*Str <= L'f')) {
-  Digit = (UINT8) (*Str - L'a' + 0x0A);
-} else if ((*Str >= L'A') && (*Str <= L'F')) {
-  Digit = (UINT8) (*Str - L'A' + 0x0A);
-} else if ((*Str >= L'0') && (*Str <= L'9')) {
-  Digit = (UINT8) (*Str - L'0');
-} else {
-  return EFI_INVALID_PARAMETER;
-}
-
-//
-// For odd characters, write the upper nibble for each buffer byte,
-// and for even characters, the lower nibble.
-//
-if ((Index & 1) == 0) {
-  Byte = (UINT8) (Digit << 4);
-} else {
-  Byte = Buf[Index / 2];
-  Byte &= 0xF0;
-  Byte = (UINT8) (Byte | Digit);
-}
-
-Buf[Index / 2] = Byte;
-  }
-
-  return EFI_SUCCESS;
-}
-
-/**
-  Converts a string to GUID value.
-  Guid Format is ----
-
-  @param[in]  Str  The registry format GUID string that contains 
the GUID value.
-  @param[out] Guid A pointer to the converted GUID value.
-
-  @retval EFI_SUCCESS The GUID string was successfully converted to the 
GUID value.
-  @retval EFI_UNSUPPORTED The input string is not in registry format.
-  @return others  Some error occurred when converting part of GUID 
value.
-
-**/
-EFI_STATUS
-InternalStrToGuid (
-  IN  CHAR16   *Str,
-  OUT EFI_GUID *Guid
-  )
-{
-  //
-  // Get the first UINT32 data
-  //
-  Guid->Data1 = (UINT32) StrHexToUint64  (Str);
-  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
-Str ++;
-  }
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-
-  //
-  // Get the second UINT16 data
-  //
-  Guid->Data2 = (UINT16) StrHexToUint64  (Str);
-  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
-Str ++;
-  }
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-
-  //
-  // Get the third UINT16 data
-  //
-  Guid->Data3 = (UINT16) StrHexToUint64  (Str);
-  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
-Str ++;
-  }
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-
-  //
-  // Get the following 8 bytes data
-  //
-  InternalStrToBuf (>Data4[0], 2, Str);
-  //
-  // Skip 2 byte hex chars
-  //
-  Str += 2 * 2;
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-  InternalStrToBuf (>Data4[2], 6, Str);
-
-  return EFI_SUCCESS;
-}
-
-/**
   Return File System Volume containing this shell application.
 
   @return File System Volume containing this shell application.
diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c 
b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
index 5b8c147..eea40b7 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
@@ -1,7 +1,7 @@
 /** @file
   A shell application that triggers capsule update process.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2017, 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 

[edk2] [PATCH 06/11] MdePkg/UefiDevicePathLib: Use BaseLib string conversion services

[Ruiyu Ni]

Update UefiDevicePathLib to use StrToGuid/StrHexToBytes
/StrToIpv4Address/StrToIpv6Address provided by BaseLib.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Liming Gao 
---
 .../Library/UefiDevicePathLib/DevicePathFromText.c | 221 ++---
 1 file changed, 17 insertions(+), 204 deletions(-)

diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c 
b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
index e2b06a2..ae38859 100644
--- a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
+++ b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
@@ -326,187 +326,6 @@ Strtoi64 (
 }
 
 /**
-  Converts a list of string to a specified buffer.
-
-  @param Buf The output buffer that contains the string.
-  @param BufferLengthThe length of the buffer
-  @param Str The input string that contains the hex number
-
-  @retval EFI_SUCCESSThe string was successfully converted to the buffer.
-
-**/
-EFI_STATUS
-StrToBuf (
-  OUT UINT8*Buf,
-  IN  UINTNBufferLength,
-  IN  CHAR16   *Str
-  )
-{
-  UINTN   Index;
-  UINTN   StrLength;
-  UINT8   Digit;
-  UINT8   Byte;
-
-  Digit = 0;
-
-  //
-  // Two hex char make up one byte
-  //
-  StrLength = BufferLength * sizeof (CHAR16);
-
-  for(Index = 0; Index < StrLength; Index++, Str++) {
-
-if ((*Str >= L'a') && (*Str <= L'f')) {
-  Digit = (UINT8) (*Str - L'a' + 0x0A);
-} else if ((*Str >= L'A') && (*Str <= L'F')) {
-  Digit = (UINT8) (*Str - L'A' + 0x0A);
-} else if ((*Str >= L'0') && (*Str <= L'9')) {
-  Digit = (UINT8) (*Str - L'0');
-} else {
-  return EFI_INVALID_PARAMETER;
-}
-
-//
-// For odd characters, write the upper nibble for each buffer byte,
-// and for even characters, the lower nibble.
-//
-if ((Index & 1) == 0) {
-  Byte = (UINT8) (Digit << 4);
-} else {
-  Byte = Buf[Index / 2];
-  Byte &= 0xF0;
-  Byte = (UINT8) (Byte | Digit);
-}
-
-Buf[Index / 2] = Byte;
-  }
-
-  return EFI_SUCCESS;
-}
-
-/**
-  Converts a string to GUID value.
-  Guid Format is ----
-
-  @param Str  The registry format GUID string that contains the 
GUID value.
-  @param Guid A pointer to the converted GUID value.
-
-  @retval EFI_SUCCESS The GUID string was successfully converted to the 
GUID value.
-  @retval EFI_UNSUPPORTED The input string is not in registry format.
-  @return others  Some error occurred when converting part of GUID 
value.
-
-**/
-EFI_STATUS
-DevicePathLibStrToGuid (
-  IN  CHAR16   *Str,
-  OUT EFI_GUID *Guid
-  )
-{
-  //
-  // Get the first UINT32 data
-  //
-  Guid->Data1 = (UINT32) StrHexToUint64  (Str);
-  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
-Str ++;
-  }
-  
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-  
-  //
-  // Get the second UINT16 data
-  //
-  Guid->Data2 = (UINT16) StrHexToUint64  (Str);
-  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
-Str ++;
-  }
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-  
-  //
-  // Get the third UINT16 data
-  //
-  Guid->Data3 = (UINT16) StrHexToUint64  (Str);
-  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
-Str ++;
-  }
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-
-  //
-  // Get the following 8 bytes data
-  //  
-  StrToBuf (>Data4[0], 2, Str);
-  //
-  // Skip 2 byte hex chars
-  //
-  Str += 2 * 2;
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-  StrToBuf (>Data4[2], 6, Str);
-
-  return EFI_SUCCESS;
-}
-
-/**
-  Converts a string to IPv4 address
-
-  @param Str A string representation of IPv4 address.
-  @param IPv4AddrA pointer to the converted IPv4 address.
-
-**/
-VOID
-StrToIPv4Addr (
-  IN OUT CHAR16   **Str,
-  OUTEFI_IPv4_ADDRESS *IPv4Addr
-  )
-{
-  UINTN  Index;
-
-  for (Index = 0; Index < 4; Index++) {
-IPv4Addr->Addr[Index] = (UINT8) Strtoi (SplitStr (Str, L'.'));
-  }
-}
-
-/**
-  Converts a string to IPv4 address
-
-  @param Str A string representation of IPv6 address.
-  @param IPv6AddrA pointer to the converted IPv6 address.
-
-**/
-VOID
-StrToIPv6Addr (
-  IN OUT CHAR16   **Str,
-  OUTEFI_IPv6_ADDRESS *IPv6Addr
-  )
-{
-  UINTN  Index;
-  UINT16 Data;
-
-  for (Index = 0; Index < 8; Index++) {
-Data = (UINT16) StrHexToUintn (SplitStr (Str, L':'));
-IPv6Addr->Addr[Index * 2] = (UINT8) (Data >> 8);
-IPv6Addr->Addr[Index * 2 + 1] = (UINT8) (Data & 0xff);
-  }
-}
-
-/**
   Converts a Unicode string to ASCII string.
 
   @param Str The equivalent Unicode string
@@ -567,9 +386,7 @@ DevPathFromTextGenericPath (
(UINT16) (sizeof (EFI_DEVICE_PATH_PROTOCOL) + DataLength)
);
 
-  if 

[edk2] [PATCH 10/11] SignedCapsulePkg/IniParsingLib: Use AsciiStrToGuid in BaseLib

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
---
 .../Library/IniParsingLib/IniParsingLib.c  | 141 +
 1 file changed, 1 insertion(+), 140 deletions(-)

diff --git a/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c 
b/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
index 16e1349..e9c2cc5 100644
--- a/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
+++ b/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
@@ -862,144 +862,6 @@ UpdateGetProfileString (
 }
 
 /**
-  Converts a list of string to a specified buffer.
-
-  @param[out] Buf The output buffer that contains the string.
-  @param[in]  BufferLengthThe length of the buffer
-  @param[in]  Str The input string that contains the hex number
-
-  @retval EFI_SUCCESSThe string was successfully converted to the buffer.
-
-**/
-EFI_STATUS
-AsciiStrToBuf (
-  OUT UINT8*Buf,
-  IN  UINTNBufferLength,
-  IN  CHAR8*Str
-  )
-{
-  UINTN   Index;
-  UINTN   StrLength;
-  UINT8   Digit;
-  UINT8   Byte;
-
-  Digit = 0;
-
-  //
-  // Two hex char make up one byte
-  //
-  StrLength = BufferLength * 2;
-
-  for(Index = 0; Index < StrLength; Index++, Str++) {
-
-if ((*Str >= 'a') && (*Str <= 'f')) {
-  Digit = (UINT8) (*Str - 'a' + 0x0A);
-} else if ((*Str >= 'A') && (*Str <= 'F')) {
-  Digit = (UINT8) (*Str - 'A' + 0x0A);
-} else if ((*Str >= '0') && (*Str <= '9')) {
-  Digit = (UINT8) (*Str - '0');
-} else {
-  return EFI_INVALID_PARAMETER;
-}
-
-//
-// For odd characters, write the upper nibble for each buffer byte,
-// and for even characters, the lower nibble.
-//
-if ((Index & 1) == 0) {
-  Byte = (UINT8) (Digit << 4);
-} else {
-  Byte = Buf[Index / 2];
-  Byte &= 0xF0;
-  Byte = (UINT8) (Byte | Digit);
-}
-
-Buf[Index / 2] = Byte;
-  }
-
-  return EFI_SUCCESS;
-}
-
-/**
-  Converts a string to GUID value.
-  Guid Format is ----
-
-  @param[in]  Str  The registry format GUID string that contains 
the GUID value.
-  @param[out] Guid A pointer to the converted GUID value.
-
-  @retval EFI_SUCCESS The GUID string was successfully converted to the 
GUID value.
-  @retval EFI_UNSUPPORTED The input string is not in registry format.
-  @return others  Some error occurred when converting part of GUID 
value.
-
-**/
-EFI_STATUS
-IniAsciiStrToGuid (
-  IN  CHAR8*Str,
-  OUT EFI_GUID *Guid
-  )
-{
-  //
-  // Get the first UINT32 data
-  //
-  Guid->Data1 = (UINT32) AsciiStrHexToUint64  (Str);
-  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
-Str ++;
-  }
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-
-  //
-  // Get the second UINT16 data
-  //
-  Guid->Data2 = (UINT16) AsciiStrHexToUint64  (Str);
-  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
-Str ++;
-  }
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-
-  //
-  // Get the third UINT16 data
-  //
-  Guid->Data3 = (UINT16) AsciiStrHexToUint64  (Str);
-  while (!IS_HYPHEN (*Str) && !IS_NULL (*Str)) {
-Str ++;
-  }
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-
-  //
-  // Get the following 8 bytes data
-  //
-  AsciiStrToBuf (>Data4[0], 2, Str);
-  //
-  // Skip 2 byte hex chars
-  //
-  Str += 2 * 2;
-
-  if (IS_HYPHEN (*Str)) {
-Str++;
-  } else {
-return EFI_UNSUPPORTED;
-  }
-  AsciiStrToBuf (>Data4[2], 6, Str);
-
-  return EFI_SUCCESS;
-}
-
-/**
   Pre process config data buffer into Section entry list and Comment entry 
list.
 
   @param[in]  DataBuffer  Config raw file buffer.
@@ -1261,8 +1123,7 @@ GetGuidFromDataFile (
   if (!IsValidGuid(Value, AsciiStrLen(Value))) {
 return EFI_NOT_FOUND;
   }
-  Status = IniAsciiStrToGuid(Value, Guid);
-  if (EFI_ERROR (Status)) {
+  if (RETURN_ERROR (AsciiStrToGuid (Value, Guid))) {
 return EFI_NOT_FOUND;
   }
   return EFI_SUCCESS;
-- 
2.9.0.windows.1

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

[edk2] [PATCH 03/11] SignedCapsulePkg/IniParsing: Rename StrToGuid to avoid link failure

[Ruiyu Ni]

Since the next patch will add AsciiStrToGuid in BaseLib, renaming
the internal function AsciiStrToGuid to IniAsciiStrToGuid to avoid
link failure.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
---
 SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c 
b/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
index 270380e..16e1349 100644
--- a/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
+++ b/SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.c
@@ -25,7 +25,7 @@
   OpenIniFile(), PreProcessDataFile(), ProfileGetSection(), ProfileGetEntry()
   will receive untrusted input and do basic validation.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions
@@ -933,7 +933,7 @@ AsciiStrToBuf (
 
 **/
 EFI_STATUS
-AsciiStrToGuid (
+IniAsciiStrToGuid (
   IN  CHAR8*Str,
   OUT EFI_GUID *Guid
   )
@@ -1261,7 +1261,7 @@ GetGuidFromDataFile (
   if (!IsValidGuid(Value, AsciiStrLen(Value))) {
 return EFI_NOT_FOUND;
   }
-  Status = AsciiStrToGuid(Value, Guid);
+  Status = IniAsciiStrToGuid(Value, Guid);
   if (EFI_ERROR (Status)) {
 return EFI_NOT_FOUND;
   }
-- 
2.9.0.windows.1

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

[edk2] [PATCH 05/11] MdePkg/BaseLib: Add AsciiStrToGuid/HexToBytes/ToIpv[4/6]Address

[Ruiyu Ni]

The patch adds 4 APIs to convert ASCII string to GUID, bytes
buffer, IP v4 address and IP v6 address.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Liming Gao 
Cc: Jiewen Yao 
Cc: Siyuan Fu 
---
 MdePkg/Include/Library/BaseLib.h| 214 +
 MdePkg/Library/BaseLib/SafeString.c | 591 
 2 files changed, 805 insertions(+)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 8aac4c8..2f3614d 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -2428,6 +2428,220 @@ AsciiStrHexToUint64 (
   IN  CONST CHAR8*String
   );
 
+/**
+  Convert a Null-terminated ASCII string to IPv6 address and prefix length.
+
+  This function outputs a value of type IPv6_ADDRESS and may output a value
+  of type UINT8 by interpreting the contents of the ASCII string specified
+  by String. The format of the input ASCII string String is as follows:
+
+  X:X:X:X:X:X:X:X[/P]
+
+  X contains one to four hexadecimal digit characters in the range [0-9], 
[a-f] and
+  [A-F]. X is converted to a value of type UINT16, whose low byte is stored in 
low
+  memory address and high byte is stored in high memory address. P contains 
decimal
+  digit characters in the range [0-9]. The running zero in the beginning of P 
will
+  be ignored. /P is optional.
+
+  When /P is not in the String, the function stops at the first character that 
is
+  not a valid hexadecimal digit character after eight X's are converted.
+
+  When /P is in the String, the function stops at the first character that is 
not
+  a valid decimal digit character after P is converted.
+
+  "::" can be used to compress one or more groups of X when X contains only 0.
+  The "::" can only appear once in the String.
+
+  If String is NULL, then ASSERT().
+
+  If Address is NULL, then ASSERT().
+
+  If EndPointer is not NULL and Address is translated from String, a pointer
+  to the character that stopped the scan is stored at the location pointed to
+  by EndPointer.
+
+  @param  String   Pointer to a Null-terminated ASCII string.
+  @param  EndPointer   Pointer to character that stops scan.
+  @param  Address  Pointer to the converted IPv6 address.
+  @param  PrefixLength Pointer to the converted IPv6 address prefix
+   length. MAX_UINT8 is returned when /P is
+   not in the String.
+
+  @retval RETURN_SUCCESS   Address is translated from String.
+  @retval RETURN_INVALID_PARAMETER If String is NULL.
+   If Data is NULL.
+   If X contains more than four hexadecimal
+digit characters.
+   If String contains "::" and number of X
+is not less than 8.
+   If P starts with character that is not a
+valid decimal digit character.
+   If the decimal number converted from P
+exceeds 128.
+
+**/
+RETURN_STATUS
+EFIAPI
+AsciiStrToIpv6Address (
+  IN  CONST CHAR8*String,
+  OUT CHAR8  **EndPointer, OPTIONAL
+  OUT IPv6_ADDRESS   *Address,
+  OUT UINT8  *PrefixLength OPTIONAL
+  );
+
+/**
+  Convert a Null-terminated ASCII string to IPv4 address and prefix length.
+
+  This function outputs a value of type IPv4_ADDRESS and may output a value
+  of type UINT8 by interpreting the contents of the ASCII string specified
+  by String. The format of the input ASCII string String is as follows:
+
+  D.D.D.D[/P]
+
+  D and P are decimal digit characters in the range [0-9]. The running zero in
+  the beginning of D and P will be ignored. /P is optional.
+
+  When /P is not in the String, the function stops at the first character that 
is
+  not a valid decimal digit character after four D's are converted.
+
+  When /P is in the String, the function stops at the first character that is 
not
+  a valid decimal digit character after P is converted.
+
+  If String is NULL, then ASSERT().
+
+  If Address is NULL, then ASSERT().
+
+  If EndPointer is not NULL and Address is translated from String, a pointer
+  to the character that stopped the scan is stored at the location pointed to
+  by EndPointer.
+
+  @param  String   Pointer to a Null-terminated ASCII string.
+  @param  EndPointer   Pointer to character that stops scan.
+  @param  Address  Pointer to the converted IPv4 address.
+  @param  PrefixLength Pointer to the converted IPv4 address prefix
+   length. MAX_UINT8 is 

[edk2] [PATCH 04/11] MdePkg/BaseLib: Add StrToGuid/StrHexToBytes/StrToIpv[4/6]Address

[Ruiyu Ni]

The patch adds 4 APIs to convert Unicode string to GUID, bytes
buffer, IP v4 address and IP v6 address.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Liming Gao 
Cc: Jiewen Yao 
Cc: Siyuan Fu 
---
 MdePkg/Include/Library/BaseLib.h| 241 ++
 MdePkg/Library/BaseLib/SafeString.c | 623 
 2 files changed, 864 insertions(+)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index d71ccb7..8aac4c8 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -1536,6 +1536,247 @@ StrHexToUint64 (
   IN  CONST CHAR16 *String
   );
 
+/**
+  Convert a Null-terminated Unicode string to IPv6 address and prefix length.
+
+  This function outputs a value of type IPv6_ADDRESS and may output a value
+  of type UINT8 by interpreting the contents of the Unicode string specified
+  by String. The format of the input Unicode string String is as follows:
+
+  X:X:X:X:X:X:X:X[/P]
+
+  X contains one to four hexadecimal digit characters in the range [0-9], 
[a-f] and
+  [A-F]. X is converted to a value of type UINT16, whose low byte is stored in 
low
+  memory address and high byte is stored in high memory address. P contains 
decimal
+  digit characters in the range [0-9]. The running zero in the beginning of P 
will
+  be ignored. /P is optional.
+
+  When /P is not in the String, the function stops at the first character that 
is
+  not a valid hexadecimal digit character after eight X's are converted.
+
+  When /P is in the String, the function stops at the first character that is 
not
+  a valid decimal digit character after P is converted.
+
+  "::" can be used to compress one or more groups of X when X contains only 0.
+  The "::" can only appear once in the String.
+
+  If String is NULL, then ASSERT().
+
+  If Address is NULL, then ASSERT().
+
+  If String is not aligned in a 16-bit boundary, then ASSERT().
+
+  If PcdMaximumUnicodeStringLength is not zero, and String contains more than
+  PcdMaximumUnicodeStringLength Unicode characters, not including the
+  Null-terminator, then ASSERT().
+
+  If EndPointer is not NULL and Address is translated from String, a pointer
+  to the character that stopped the scan is stored at the location pointed to
+  by EndPointer.
+
+  @param  String   Pointer to a Null-terminated Unicode string.
+  @param  EndPointer   Pointer to character that stops scan.
+  @param  Address  Pointer to the converted IPv6 address.
+  @param  PrefixLength Pointer to the converted IPv6 address prefix
+   length. MAX_UINT8 is returned when /P is
+   not in the String.
+
+  @retval RETURN_SUCCESS   Address is translated from String.
+  @retval RETURN_INVALID_PARAMETER If String is NULL.
+   If Data is NULL.
+   If PcdMaximumUnicodeStringLength is not
+zero, and String contains more than
+PcdMaximumUnicodeStringLength Unicode
+characters, not including the
+Null-terminator.
+   If X contains more than four hexadecimal
+digit characters.
+   If String contains "::" and number of X
+is not less than 8.
+   If P starts with character that is not a
+valid decimal digit character.
+   If the decimal number converted from P
+exceeds 128.
+
+**/
+RETURN_STATUS
+EFIAPI
+StrToIpv6Address (
+  IN  CONST CHAR16   *String,
+  OUT CHAR16 **EndPointer, OPTIONAL
+  OUT IPv6_ADDRESS   *Address,
+  OUT UINT8  *PrefixLength OPTIONAL
+  );
+
+/**
+  Convert a Null-terminated Unicode string to IPv4 address and prefix length.
+
+  This function outputs a value of type IPv4_ADDRESS and may output a value
+  of type UINT8 by interpreting the contents of the Unicode string specified
+  by String. The format of the input Unicode string String is as follows:
+
+  D.D.D.D[/P]
+
+  D and P are decimal digit characters in the range [0-9]. The running zero in
+  the beginning of D and P will be ignored. /P is optional.
+
+  When /P is not in the String, the function stops at the first character that 
is
+  not a valid decimal digit character after four D's are converted.
+
+  When /P is in the String, the function stops at the first character that is 
not
+  a valid decimal digit character after P is converted.
+
+  If String is 

[edk2] [PATCH 01/11] MdePkg: Define IPv4_ADDRESS and IPv6_ADDRESS in Base.h

[Ruiyu Ni]

Since the following patch needs to add API converting string
to IP address in BaseLib, define the IP address as base types
in Base.h.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Liming Gao 
---
 MdePkg/Include/Base.h  | 16 +++-
 MdePkg/Include/Uefi/UefiBaseType.h | 10 +++---
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index 8f5b919..5b311f6 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -6,7 +6,7 @@
   environment. There are a set of base libraries in the Mde Package that can
   be used to implement base modules.
 
-Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -265,6 +265,20 @@ typedef struct {
   UINT8   Data4[8];
 } GUID;
 
+///
+/// 4-byte buffer. An IPv4 internet protocol address.
+///
+typedef struct {
+  UINT8 Addr[4];
+} IPv4_ADDRESS;
+
+///
+/// 16-byte buffer. An IPv6 internet protocol address.
+///
+typedef struct {
+  UINT8 Addr[16];
+} IPv6_ADDRESS;
+
 //
 // 8-bytes unsigned value that represents a physical system address.
 //
diff --git a/MdePkg/Include/Uefi/UefiBaseType.h 
b/MdePkg/Include/Uefi/UefiBaseType.h
index 84e4dc6..728a047 100644
--- a/MdePkg/Include/Uefi/UefiBaseType.h
+++ b/MdePkg/Include/Uefi/UefiBaseType.h
@@ -1,7 +1,7 @@
 /** @file
   Defines data types and constants introduced in UEFI.
 
-Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 Portions copyright (c) 2011 - 2016, ARM Ltd. All rights reserved.
 
 This program and the accompanying materials are licensed and made available 
under 
@@ -87,16 +87,12 @@ typedef struct {
 ///
 /// 4-byte buffer. An IPv4 internet protocol address.
 ///
-typedef struct {
-  UINT8 Addr[4];
-} EFI_IPv4_ADDRESS;
+typedef IPv4_ADDRESS EFI_IPv4_ADDRESS;
 
 ///
 /// 16-byte buffer. An IPv6 internet protocol address.
 ///
-typedef struct {
-  UINT8 Addr[16];
-} EFI_IPv6_ADDRESS;
+typedef IPv6_ADDRESS EFI_IPv6_ADDRESS;
 
 ///
 /// 32-byte buffer containing a network Media Access Control address.
-- 
2.9.0.windows.1

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

[edk2] [PATCH 00/11] Add StrToGuid/HexToBytes/Ipv4/Ipv6 in BaseLib

[Ruiyu Ni]

The patch set adds StrToGuid/StrHexToBytes/StrToIPv4Address
/StrToIPv6Address and the accordingly ASCII versioins to BaseLib.
It also changes all existing consumers to use the new APIs.

Ruiyu Ni (11):
  MdePkg: Define IPv4_ADDRESS and IPv6_ADDRESS in Base.h
  MdePkg/UefiDevicePathLib: Rename StrToGuid to avoid link failure
  SignedCapsulePkg/IniParsing: Rename StrToGuid to avoid link failure
  MdePkg/BaseLib: Add StrToGuid/StrHexToBytes/StrToIpv[4/6]Address
  MdePkg/BaseLib: Add AsciiStrToGuid/HexToBytes/ToIpv[4/6]Address
  MdePkg/UefiDevicePathLib: Use BaseLib string conversion services
  MdeModulePkg/CapsuleApp: Use StrToGuid in BaseLib
  SecurityPkg/SecureBootConfigDxe: Use StrToGuid in BaseLib
  ShellPkg/Debug1CommandLib: Use StrToGuid/StrHexToBytes in BaseLib
  SignedCapsulePkg/IniParsingLib: Use AsciiStrToGuid in BaseLib
  MdeModulePkg/NetLib: Use StrToIpv4/6Address in BaseLib

 MdeModulePkg/Application/CapsuleApp/AppSupport.c   |  140 +--
 MdeModulePkg/Application/CapsuleApp/CapsuleApp.c   |   25 +-
 MdeModulePkg/Include/Library/NetLib.h  |5 +-
 MdeModulePkg/Library/DxeNetLib/DxeNetLib.c |  382 +-
 MdePkg/Include/Base.h  |   16 +-
 MdePkg/Include/Library/BaseLib.h   |  455 
 MdePkg/Include/Uefi/UefiBaseType.h |   10 +-
 MdePkg/Library/BaseLib/SafeString.c| 1214 
 .../Library/UefiDevicePathLib/DevicePathFromText.c |  213 +---
 .../SecureBootConfigDxe/SecureBootConfigImpl.c |   11 +-
 .../SecureBootConfigDxe/SecureBootConfigImpl.h |   22 +-
 .../SecureBootConfigDxe/SecureBootConfigMisc.c |  141 +--
 .../Library/UefiShellDebug1CommandsLib/DmpStore.c  |5 +-
 .../Library/UefiShellDebug1CommandsLib/SetVar.c|   10 +-
 .../UefiShellDebug1CommandsLib.c   |  119 +-
 .../UefiShellDebug1CommandsLib.h   |   32 +-
 .../Library/IniParsingLib/IniParsingLib.c  |  143 +--
 17 files changed, 1751 insertions(+), 1192 deletions(-)

-- 
2.9.0.windows.1

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

[edk2] [PATCH 02/11] MdePkg/UefiDevicePathLib: Rename StrToGuid to avoid link failure

[Ruiyu Ni]

Since the next patch will add StrToGuid in BaseLib, renaming the
internal function StrToGuid to DevicePathLibStrToGuid to avoid
link failure.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Liming Gao 
---
 MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c 
b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
index 8a3a470..e2b06a2 100644
--- a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
+++ b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
@@ -1,7 +1,7 @@
 /** @file
   DevicePathFromText protocol as defined in the UEFI 2.0 specification.
 
-Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2013 - 2017, 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
@@ -397,7 +397,7 @@ StrToBuf (
 
 **/
 EFI_STATUS
-StrToGuid (
+DevicePathLibStrToGuid (
   IN  CHAR16   *Str,
   OUT EFI_GUID *Guid
   )
@@ -740,7 +740,7 @@ ConvertFromTextVendor (
  (UINT16) (sizeof (VENDOR_DEVICE_PATH) + 
Length)
  );
 
-  StrToGuid (GuidStr, >Guid);
+  DevicePathLibStrToGuid (GuidStr, >Guid);
   StrToBuf (((UINT8 *) Vendor) + sizeof (VENDOR_DEVICE_PATH), Length, DataStr);
 
   return (EFI_DEVICE_PATH_PROTOCOL *) Vendor;
@@ -1453,7 +1453,7 @@ DevPathFromTextInfiniband (
 );
 
   InfiniBand->ResourceFlags = (UINT32) Strtoi (FlagsStr);
-  StrToGuid (GuidStr, );
+  DevicePathLibStrToGuid (GuidStr, );
   CopyMem (InfiniBand->PortGid, , sizeof (EFI_GUID));
   Strtoi64 (SidStr, >ServiceId);
   Strtoi64 (TidStr, >TargetPortId);
@@ -2976,7 +2976,7 @@ DevPathFromTextHD (
 Hd->SignatureType = SIGNATURE_TYPE_GUID;
 Hd->MBRType   = 0x02;
 
-StrToGuid (SignatureStr, );
+DevicePathLibStrToGuid (SignatureStr, );
 CopyMem (Hd->Signature, , sizeof (EFI_GUID));
   } else {
 Hd->SignatureType = (UINT8) Strtoi (TypeStr);
@@ -3091,7 +3091,7 @@ DevPathFromTextMedia (
  (UINT16) sizeof 
(MEDIA_PROTOCOL_DEVICE_PATH)
  );
 
-  StrToGuid (GuidStr, >Protocol);
+  DevicePathLibStrToGuid (GuidStr, >Protocol);
 
   return (EFI_DEVICE_PATH_PROTOCOL *) Media;
 }
@@ -3119,7 +3119,7 @@ DevPathFromTextFv (
(UINT16) sizeof 
(MEDIA_FW_VOL_DEVICE_PATH)
);
 
-  StrToGuid (GuidStr, >FvName);
+  DevicePathLibStrToGuid (GuidStr, >FvName);
 
   return (EFI_DEVICE_PATH_PROTOCOL *) Fv;
 }
@@ -3147,7 +3147,7 @@ DevPathFromTextFvFile (
 (UINT16) sizeof 
(MEDIA_FW_VOL_FILEPATH_DEVICE_PATH)
 );
 
-  StrToGuid (GuidStr, >FvFileName);
+  DevicePathLibStrToGuid (GuidStr, >FvFileName);
 
   return (EFI_DEVICE_PATH_PROTOCOL *) FvFile;
 }
@@ -3219,7 +3219,7 @@ DevPathFromTextRamDisk (
   Strtoi64 (EndingAddrStr, );
   WriteUnaligned64 ((UINT64 *) &(RamDisk->EndingAddr[0]), EndingAddr);
   RamDisk->Instance = (UINT16) Strtoi (InstanceStr);
-  StrToGuid (TypeGuidStr, >TypeGuid);
+  DevicePathLibStrToGuid (TypeGuidStr, >TypeGuid);
 
   return (EFI_DEVICE_PATH_PROTOCOL *) RamDisk;
 }
-- 
2.9.0.windows.1

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

Re: [edk2] memory type information HOB / UEFI memmap defrag

[Laszlo Ersek]

On 02/22/17 04:14, Laszlo Ersek wrote:
> Mike,
> 
> On 02/22/17 03:54, Jordan Justen wrote:
>> On 2017-02-21 18:46:01, Kinney, Michael D wrote:
>>> Laszlo,
>>>
>>> The only side effect of not producing the HOB when the variable does
>>> not exist is that the first boot of a platform has a fragmented
>>> memory map
> 
> We have a permanently fragmented map now :) (Although, I guess it could
> be even worse; the HOB that we produce now likely does help a bit.)
> 
>>> and you may get an extra reboot when the variable is set.
> 
> I think I could live with that.
> 
> In fact, if the reboot is *guaranteed* if the variable does not exist,
> that's likely best, because this way a fragmented memmap is never
> exposed to a guest OS.
> 
>>> A fragmented memory map will also be produced if the variable store 
>>> contents are corrupt or zeroed.
> 
> If that was hidden from the OS by a guaranteed reboot, I think I'd
> welcome that reboot. It's a very infrequent occurrence.
> 
> Jordan,
> 
>> Would it be possible to inhibit the reboot until we fully support S4?
> 
> I'm not very worried about the reboot; using pflash and longer-term
> guests, it should happen very rarely.
> 
> For one-off guests though... Hm, I guess it might be somewhat annoying,
> so if we can find a solution for avoiding the reboot even when the
> variable is missing, that would be more elegant.
> 
>> I think it'd be fine to have a fragmented map for one boot if it was
>> corrected on future boots of the machine.
> 
> Is this a trade-off we can control somehow?
> 
> I think you're starting to convince me that it's more user friendly to
> expose a fragmented map *once* than to auto-reboot *once*.
> 
>> I think we should consider continuing to produce the HOB in
>> PlatformPei if we can fairly easily reduce the fragmentation on the
>> first boot via the HOB.
> 
> Sure, we can bump the values in the HOB; however, the problem is with
> identifying "first boot" (= presence of the variable) in PlatformPei, to
> see if we should produce the default HOB. That opens the same can of
> worms :(
> 
> I mean we can install a PPI notify callback for the r/o variable PPI in
> PlatformPei, and then install the HOB in the callback if the variable is
> missing. It's just too much work.
> 
> Hm, wait, we already call PeiServicesNotifyPpi() in PlatformPei, for the
> MP Services PPI (which we use to program the Feature Control MSR on all
> VCPUs if instructed so by QEMU). Then I guess I'm out of arguments; we
> should at least try this. Sigh. :)
> 
> Do you want to reopen
> ? I just closed it
> because there didn't seem to be an actual use case for VariablePei, but
> now we may have found one, independently of the original reporter's
> (non-upstream) use case.

There's at least one big complication though. OVMF still supports a
RAM-emulated varstore, in addition to pflash. The pflash location is
known in advance (it is a set of constants from the build process), but
the area for the emulation is allocated dynamically during PEI. And, we
only really decide which one to use for variables in the DXE phase
(that's when we check for the presence of pflash).

This sort of throws a wrench into VariablePei's gears; we cannot tell it
where to look for the varstore. We could move the flash detection from
DXE to PEI, but that's again too much complication for this -- if we
could mitigate the fragmentation by bumping the constants in our current
HOB, that would look way more attractive to me.

If we removed the RAM-emulated varstore fully, and required pflash no
matter what, then I might feel differently, I think.

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

Re: [edk2] memory type information HOB / UEFI memmap defrag

[Kinney, Michael D]

Laszlo,

The following PCD controls the reset behavior for this case.

  ## Indicates if to reset system when memory type information changes.
  #   TRUE  - Resets system when memory type information changes.
  #   FALSE - Does not reset system when memory type information changes.
  # @Prompt Reset on memory type information change.
  
gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|TRUE|BOOLEAN|0x00010056

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Tuesday, February 21, 2017 7:15 PM
> To: Justen, Jordan L ; Kinney, Michael D
> ; Yao, Jiewen ; 
> edk2-devel-01
> 
> Cc: Ni, Ruiyu ; Andrew Fish ; Ard 
> Biesheuvel
> 
> Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag
> 
> Mike,
> 
> On 02/22/17 03:54, Jordan Justen wrote:
> > On 2017-02-21 18:46:01, Kinney, Michael D wrote:
> >> Laszlo,
> >>
> >> The only side effect of not producing the HOB when the variable does
> >> not exist is that the first boot of a platform has a fragmented
> >> memory map
> 
> We have a permanently fragmented map now :) (Although, I guess it could
> be even worse; the HOB that we produce now likely does help a bit.)
> 
> >> and you may get an extra reboot when the variable is set.
> 
> I think I could live with that.
> 
> In fact, if the reboot is *guaranteed* if the variable does not exist,
> that's likely best, because this way a fragmented memmap is never
> exposed to a guest OS.
> 
> >> A fragmented memory map will also be produced if the variable store
> >> contents are corrupt or zeroed.
> 
> If that was hidden from the OS by a guaranteed reboot, I think I'd
> welcome that reboot. It's a very infrequent occurrence.
> 
> Jordan,
> 
> > Would it be possible to inhibit the reboot until we fully support S4?
> 
> I'm not very worried about the reboot; using pflash and longer-term
> guests, it should happen very rarely.
> 
> For one-off guests though... Hm, I guess it might be somewhat annoying,
> so if we can find a solution for avoiding the reboot even when the
> variable is missing, that would be more elegant.
> 
> > I think it'd be fine to have a fragmented map for one boot if it was
> > corrected on future boots of the machine.
> 
> Is this a trade-off we can control somehow?
> 
> I think you're starting to convince me that it's more user friendly to
> expose a fragmented map *once* than to auto-reboot *once*.
> 
> > I think we should consider continuing to produce the HOB in
> > PlatformPei if we can fairly easily reduce the fragmentation on the
> > first boot via the HOB.
> 
> Sure, we can bump the values in the HOB; however, the problem is with
> identifying "first boot" (= presence of the variable) in PlatformPei, to
> see if we should produce the default HOB. That opens the same can of
> worms :(
> 
> I mean we can install a PPI notify callback for the r/o variable PPI in
> PlatformPei, and then install the HOB in the callback if the variable is
> missing. It's just too much work.
> 
> Hm, wait, we already call PeiServicesNotifyPpi() in PlatformPei, for the
> MP Services PPI (which we use to program the Feature Control MSR on all
> VCPUs if instructed so by QEMU). Then I guess I'm out of arguments; we
> should at least try this. Sigh. :)
> 
> Do you want to reopen
> ? I just closed it
> because there didn't seem to be an actual use case for VariablePei, but
> now we may have found one, independently of the original reporter's
> (non-upstream) use case.
> 
> Thanks!
> Laszlo
> 
> >
> > -Jordan
> >
> >>
> >>> -Original Message-
> >>> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >>> Sent: Tuesday, February 21, 2017 6:31 PM
> >>> To: Kinney, Michael D ; Justen, Jordan L
> >>> ; Yao, Jiewen ; 
> >>> edk2-devel-01
>  >>> de...@ml01.01.org>
> >>> Cc: Ni, Ruiyu ; Andrew Fish ; Ard 
> >>> Biesheuvel
> >>> 
> >>> Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag
> >>>
> >>> On 02/22/17 02:48, Kinney, Michael D wrote:
>  Jordan,
> 
>  The usage of EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData
>  may vary from boot to boot, especially if the shell or other applications
>  are run or different OSes are booted.  A change in the bin size causes
>  extra variable writes and potentially extra reboots.
> >>>
> >>> As I wrote elsewere, in a few days (or, well, weeks) I would like to
> >>> research the simpler-looking avenue of (a) simply not producing this HOB
> >>> in OVMF's PlatformPei at all, and (b) pulling in VariablePei. As far as
> >>> I understand the code in the DXE IPL PEIM and BDS DXE, 

Re: [edk2] memory type information HOB / UEFI memmap defrag

[Laszlo Ersek]

Mike,

On 02/22/17 03:54, Jordan Justen wrote:
> On 2017-02-21 18:46:01, Kinney, Michael D wrote:
>> Laszlo,
>>
>> The only side effect of not producing the HOB when the variable does
>> not exist is that the first boot of a platform has a fragmented
>> memory map

We have a permanently fragmented map now :) (Although, I guess it could
be even worse; the HOB that we produce now likely does help a bit.)

>> and you may get an extra reboot when the variable is set.

I think I could live with that.

In fact, if the reboot is *guaranteed* if the variable does not exist,
that's likely best, because this way a fragmented memmap is never
exposed to a guest OS.

>> A fragmented memory map will also be produced if the variable store 
>> contents are corrupt or zeroed.

If that was hidden from the OS by a guaranteed reboot, I think I'd
welcome that reboot. It's a very infrequent occurrence.

Jordan,

> Would it be possible to inhibit the reboot until we fully support S4?

I'm not very worried about the reboot; using pflash and longer-term
guests, it should happen very rarely.

For one-off guests though... Hm, I guess it might be somewhat annoying,
so if we can find a solution for avoiding the reboot even when the
variable is missing, that would be more elegant.

> I think it'd be fine to have a fragmented map for one boot if it was
> corrected on future boots of the machine.

Is this a trade-off we can control somehow?

I think you're starting to convince me that it's more user friendly to
expose a fragmented map *once* than to auto-reboot *once*.

> I think we should consider continuing to produce the HOB in
> PlatformPei if we can fairly easily reduce the fragmentation on the
> first boot via the HOB.

Sure, we can bump the values in the HOB; however, the problem is with
identifying "first boot" (= presence of the variable) in PlatformPei, to
see if we should produce the default HOB. That opens the same can of
worms :(

I mean we can install a PPI notify callback for the r/o variable PPI in
PlatformPei, and then install the HOB in the callback if the variable is
missing. It's just too much work.

Hm, wait, we already call PeiServicesNotifyPpi() in PlatformPei, for the
MP Services PPI (which we use to program the Feature Control MSR on all
VCPUs if instructed so by QEMU). Then I guess I'm out of arguments; we
should at least try this. Sigh. :)

Do you want to reopen
? I just closed it
because there didn't seem to be an actual use case for VariablePei, but
now we may have found one, independently of the original reporter's
(non-upstream) use case.

Thanks!
Laszlo

> 
> -Jordan
> 
>>
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Tuesday, February 21, 2017 6:31 PM
>>> To: Kinney, Michael D ; Justen, Jordan L
>>> ; Yao, Jiewen ; 
>>> edk2-devel-01 >> de...@ml01.01.org>
>>> Cc: Ni, Ruiyu ; Andrew Fish ; Ard 
>>> Biesheuvel
>>> 
>>> Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag
>>>
>>> On 02/22/17 02:48, Kinney, Michael D wrote:
 Jordan,

 The usage of EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData
 may vary from boot to boot, especially if the shell or other applications
 are run or different OSes are booted.  A change in the bin size causes
 extra variable writes and potentially extra reboots.
>>>
>>> As I wrote elsewere, in a few days (or, well, weeks) I would like to
>>> research the simpler-looking avenue of (a) simply not producing this HOB
>>> in OVMF's PlatformPei at all, and (b) pulling in VariablePei. As far as
>>> I understand the code in the DXE IPL PEIM and BDS DXE, this should
>>> enable those two modules to communicate with each other through the
>>> variable highlighted by Jordan, and to create the HOB automatically. The
>>> code seems to track / maintain the maximum memory usage seen during
>>> previous boots, which I believe is appropriate for OVMF.
>>>
>>> If this worked without any more platform cooperation than (a) and (b),
>>> that would be awesome & my preference.
>>>
>>> Thanks!
>>> Laszlo
>>>

 Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Jordan
>>> Justen
> Sent: Tuesday, February 21, 2017 5:32 PM
> To: Yao, Jiewen ; Laszlo Ersek ; 
> edk2-
>>> devel-
> 01 
> Cc: Ni, Ruiyu ; Andrew Fish ; Ard 
> Biesheuvel
> 
> Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag
>
> On 2017-02-21 16:46:40, Yao, Jiewen wrote:
>> HI Laszlo
>>
>> The purpose of this table to put OS consumed memory together to avoid S4 
>> resume
>> 

Re: [edk2] memory type information HOB / UEFI memmap defrag

[Jordan Justen]

On 2017-02-21 18:46:01, Kinney, Michael D wrote:
> Laszlo,
> 
> The only side effect of not producing the HOB when the variable does
> not exist is that the first boot of a platform has a fragmented
> memory map and you may get an extra reboot when the variable is set.
> A fragmented memory map will also be produced if the variable store 
> contents are corrupt or zeroed.
> 

Would it be possible to inhibit the reboot until we fully support S4?

I think it'd be fine to have a fragmented map for one boot if it was
corrected on future boots of the machine.

I think we should consider continuing to produce the HOB in
PlatformPei if we can fairly easily reduce the fragmentation on the
first boot via the HOB.

-Jordan

> 
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Tuesday, February 21, 2017 6:31 PM
> > To: Kinney, Michael D ; Justen, Jordan L
> > ; Yao, Jiewen ; 
> > edk2-devel-01  > de...@ml01.01.org>
> > Cc: Ni, Ruiyu ; Andrew Fish ; Ard 
> > Biesheuvel
> > 
> > Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag
> > 
> > On 02/22/17 02:48, Kinney, Michael D wrote:
> > > Jordan,
> > >
> > > The usage of EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData
> > > may vary from boot to boot, especially if the shell or other applications
> > > are run or different OSes are booted.  A change in the bin size causes
> > > extra variable writes and potentially extra reboots.
> > 
> > As I wrote elsewere, in a few days (or, well, weeks) I would like to
> > research the simpler-looking avenue of (a) simply not producing this HOB
> > in OVMF's PlatformPei at all, and (b) pulling in VariablePei. As far as
> > I understand the code in the DXE IPL PEIM and BDS DXE, this should
> > enable those two modules to communicate with each other through the
> > variable highlighted by Jordan, and to create the HOB automatically. The
> > code seems to track / maintain the maximum memory usage seen during
> > previous boots, which I believe is appropriate for OVMF.
> > 
> > If this worked without any more platform cooperation than (a) and (b),
> > that would be awesome & my preference.
> > 
> > Thanks!
> > Laszlo
> > 
> > >
> > > Mike
> > >
> > >> -Original Message-
> > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > >> Jordan
> > Justen
> > >> Sent: Tuesday, February 21, 2017 5:32 PM
> > >> To: Yao, Jiewen ; Laszlo Ersek 
> > >> ; edk2-
> > devel-
> > >> 01 
> > >> Cc: Ni, Ruiyu ; Andrew Fish ; Ard 
> > >> Biesheuvel
> > >> 
> > >> Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag
> > >>
> > >> On 2017-02-21 16:46:40, Yao, Jiewen wrote:
> > >>> HI Laszlo
> > >>>
> > >>> The purpose of this table to put OS consumed memory together to avoid 
> > >>> S4 resume
> > >>> issue. EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData are not 
> > >>> used by
> > >>> OS. There is no need to put them here.
> > >>>
> > >>> I suggest we remove EfiLoaderCode/ EfiBootServicesCode/ 
> > >>> EfiBootServicesData to
> > >>> avoid confusing.
> > >>>
> > >>
> > >> Is there any other advantage to removing them?
> > >>
> > >> I guess it would be easy enough to re-add them, but I don't think we
> > >> need to move away from supporting S4. While I agree that S4 should not
> > >> be a big priority, I'd prefer that we try to support it at some point.
> > >>
> > >> -Jordan
> > >>
> > >>>
> >  +  { EfiReservedMemoryType,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *   
> >  202) },
> >  +  { EfiLoaderCode,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  
> >  1439) },
> >  +  { EfiBootServicesCode,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  
> >  5980) },
> >  +  { EfiBootServicesData,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 
> >  41643) },
> >  +  { EfiRuntimeServicesCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  
> >  1025) },
> >  +  { EfiRuntimeServicesData, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  
> >  3629) },
> >  +  { EfiACPIReclaimMemory,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *
> >  36) },
> >  +  { EfiACPIMemoryNVS,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  
> >  1301) },
> >  +  { EfiMaxMemoryType,   0 
> >    }
> > >>>
> > >>>
> > >>>
> > >>> Thank you
> > >>>
> > >>> Yao Jiewen
> > >>>
> > >>>
> > >>>
> > >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > >>> Laszlo
> > >>> Ersek
> > >>> Sent: Tuesday, February 21, 2017 11:24 PM
> > >>> To: edk2-devel-01 
> > >>> Cc: Ni, Ruiyu ; Justen, Jordan L
> > >>> ; Andrew Fish ; Ard 
> > >>> 

Re: [edk2] memory type information HOB / UEFI memmap defrag

[Kinney, Michael D]

Laszlo,

The only side effect of not producing the HOB when the variable does
not exist is that the first boot of a platform has a fragmented
memory map and you may get an extra reboot when the variable is set.
A fragmented memory map will also be produced if the variable store 
contents are corrupt or zeroed.

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, February 21, 2017 6:31 PM
> To: Kinney, Michael D ; Justen, Jordan L
> ; Yao, Jiewen ; 
> edk2-devel-01  de...@ml01.01.org>
> Cc: Ni, Ruiyu ; Andrew Fish ; Ard 
> Biesheuvel
> 
> Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag
> 
> On 02/22/17 02:48, Kinney, Michael D wrote:
> > Jordan,
> >
> > The usage of EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData
> > may vary from boot to boot, especially if the shell or other applications
> > are run or different OSes are booted.  A change in the bin size causes
> > extra variable writes and potentially extra reboots.
> 
> As I wrote elsewere, in a few days (or, well, weeks) I would like to
> research the simpler-looking avenue of (a) simply not producing this HOB
> in OVMF's PlatformPei at all, and (b) pulling in VariablePei. As far as
> I understand the code in the DXE IPL PEIM and BDS DXE, this should
> enable those two modules to communicate with each other through the
> variable highlighted by Jordan, and to create the HOB automatically. The
> code seems to track / maintain the maximum memory usage seen during
> previous boots, which I believe is appropriate for OVMF.
> 
> If this worked without any more platform cooperation than (a) and (b),
> that would be awesome & my preference.
> 
> Thanks!
> Laszlo
> 
> >
> > Mike
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >> Jordan
> Justen
> >> Sent: Tuesday, February 21, 2017 5:32 PM
> >> To: Yao, Jiewen ; Laszlo Ersek ; 
> >> edk2-
> devel-
> >> 01 
> >> Cc: Ni, Ruiyu ; Andrew Fish ; Ard 
> >> Biesheuvel
> >> 
> >> Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag
> >>
> >> On 2017-02-21 16:46:40, Yao, Jiewen wrote:
> >>> HI Laszlo
> >>>
> >>> The purpose of this table to put OS consumed memory together to avoid S4 
> >>> resume
> >>> issue. EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData are not 
> >>> used by
> >>> OS. There is no need to put them here.
> >>>
> >>> I suggest we remove EfiLoaderCode/ EfiBootServicesCode/ 
> >>> EfiBootServicesData to
> >>> avoid confusing.
> >>>
> >>
> >> Is there any other advantage to removing them?
> >>
> >> I guess it would be easy enough to re-add them, but I don't think we
> >> need to move away from supporting S4. While I agree that S4 should not
> >> be a big priority, I'd prefer that we try to support it at some point.
> >>
> >> -Jordan
> >>
> >>>
>  +  { EfiReservedMemoryType,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *   202) 
>  },
>  +  { EfiLoaderCode,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1439) 
>  },
>  +  { EfiBootServicesCode,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  5980) 
>  },
>  +  { EfiBootServicesData,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 41643) 
>  },
>  +  { EfiRuntimeServicesCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1025) 
>  },
>  +  { EfiRuntimeServicesData, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  3629) 
>  },
>  +  { EfiACPIReclaimMemory,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *36) 
>  },
>  +  { EfiACPIMemoryNVS,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1301) 
>  },
>  +  { EfiMaxMemoryType,   0   
>  }
> >>>
> >>>
> >>>
> >>> Thank you
> >>>
> >>> Yao Jiewen
> >>>
> >>>
> >>>
> >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >>> Laszlo
> >>> Ersek
> >>> Sent: Tuesday, February 21, 2017 11:24 PM
> >>> To: edk2-devel-01 
> >>> Cc: Ni, Ruiyu ; Justen, Jordan L
> >>> ; Andrew Fish ; Ard Biesheuvel
> >>> 
> >>> Subject: [edk2] memory type information HOB / UEFI memmap defrag
> >>>
> >>>
> >>>
> >>> Hi,
> >>>
> >>> the UEFI memmap under OVMF is getting very fragmented, I'm now counting
> >>> ~80 entries in it, under various circumstances.
> >>>
> >>> I recall that a platform's PlatformPei can "prime" the DXE/UEFI memory
> >>> allocation system (not the GCD services) for various memory types, by
> >>> producing a memory type information HOB.
> >>>
> >>> My vague understanding is that BDS will in turn check if the actual
> >>> allocations fit in the allotments from the HOB, and if not, it will 

Re: [edk2] [PATCH 0/6] OvmfPkg: AcpiPlatformDxe, QemuFwCfg: small cleanups after WRITE_POINTER

[Laszlo Ersek]

On 02/22/17 02:58, Jordan Justen wrote:
> Good cleanups. Thanks for taking the extra time sort these out!

You made good points, so thanks for those :) Also, stale comments are
sometimes worse than no comments, so I wanted to clean up those too.

> Reviewed-by: Jordan Justen 

Ha! I for one welcome another one of our ultra fast reviewer overlords! :)

Series committed as b9d56d0b93ae..ed1a2d42d5d5.

> Unfortunately, https://bugzilla.tianocore.org/show_bug.cgi?id=394 may
> not be quite so 'fun'. :)

Stay tuned, I'm already working on that :)

Thanks!
Laszlo

> -Jordan
> 
> On 2017-02-21 07:38:06, Laszlo Ersek wrote:
>> Most of these were suggested by Jordan.
>>
>> Cc: Jordan Justen 
>>
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: write_pointer_followup
>>
>> Thanks!
>> Laszlo
>>
>> Laszlo Ersek (6):
>>   OvmfPkg/AcpiPlatformDxe: drop double right shift in ADD/WRITE POINTER
>> cmds
>>   OvmfPkg/AcpiPlatformDxe: update PointerValue comments in
>> "BootScript.c"
>>   OvmfPkg/QemuFwCfgLib: move types/macros from lib class to
>> IndustryStandard
>>   OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_SELECTOR, adapt the package
>>   OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_DATA, adapt the package
>>   OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_DMA_ADDRESS, adapt the package
>>
>>  OvmfPkg/Include/IndustryStandard/QemuFwCfg.h | 104 
>>  OvmfPkg/Include/Library/QemuFwCfgLib.h   |  70 +
>>  OvmfPkg/AcpiPlatformDxe/BootScript.c |  18 ++--
>>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c  |   8 +-
>>  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c  |  12 +--
>>  OvmfPkg/SmmControl2Dxe/SmiFeatures.c |   6 +-
>>  6 files changed, 128 insertions(+), 90 deletions(-)
>>  create mode 100644 OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
>>
>> -- 
>> 2.9.3
>>

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

Re: [edk2] memory type information HOB / UEFI memmap defrag

[Laszlo Ersek]

On 02/22/17 02:48, Kinney, Michael D wrote:
> Jordan,
> 
> The usage of EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData
> may vary from boot to boot, especially if the shell or other applications
> are run or different OSes are booted.  A change in the bin size causes
> extra variable writes and potentially extra reboots.

As I wrote elsewere, in a few days (or, well, weeks) I would like to
research the simpler-looking avenue of (a) simply not producing this HOB
in OVMF's PlatformPei at all, and (b) pulling in VariablePei. As far as
I understand the code in the DXE IPL PEIM and BDS DXE, this should
enable those two modules to communicate with each other through the
variable highlighted by Jordan, and to create the HOB automatically. The
code seems to track / maintain the maximum memory usage seen during
previous boots, which I believe is appropriate for OVMF.

If this worked without any more platform cooperation than (a) and (b),
that would be awesome & my preference.

Thanks!
Laszlo

> 
> Mike
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Jordan Justen
>> Sent: Tuesday, February 21, 2017 5:32 PM
>> To: Yao, Jiewen ; Laszlo Ersek ; 
>> edk2-devel-
>> 01 
>> Cc: Ni, Ruiyu ; Andrew Fish ; Ard 
>> Biesheuvel
>> 
>> Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag
>>
>> On 2017-02-21 16:46:40, Yao, Jiewen wrote:
>>> HI Laszlo
>>>
>>> The purpose of this table to put OS consumed memory together to avoid S4 
>>> resume
>>> issue. EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData are not used 
>>> by
>>> OS. There is no need to put them here.
>>>
>>> I suggest we remove EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData 
>>> to
>>> avoid confusing.
>>>
>>
>> Is there any other advantage to removing them?
>>
>> I guess it would be easy enough to re-add them, but I don't think we
>> need to move away from supporting S4. While I agree that S4 should not
>> be a big priority, I'd prefer that we try to support it at some point.
>>
>> -Jordan
>>
>>>
 +  { EfiReservedMemoryType,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *   202) },
 +  { EfiLoaderCode,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1439) },
 +  { EfiBootServicesCode,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  5980) },
 +  { EfiBootServicesData,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 41643) },
 +  { EfiRuntimeServicesCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1025) },
 +  { EfiRuntimeServicesData, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  3629) },
 +  { EfiACPIReclaimMemory,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *36) },
 +  { EfiACPIMemoryNVS,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1301) },
 +  { EfiMaxMemoryType,   0   }
>>>
>>>
>>>
>>> Thank you
>>>
>>> Yao Jiewen
>>>
>>>
>>>
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>>> Laszlo
>>> Ersek
>>> Sent: Tuesday, February 21, 2017 11:24 PM
>>> To: edk2-devel-01 
>>> Cc: Ni, Ruiyu ; Justen, Jordan L
>>> ; Andrew Fish ; Ard Biesheuvel
>>> 
>>> Subject: [edk2] memory type information HOB / UEFI memmap defrag
>>>
>>>
>>>
>>> Hi,
>>>
>>> the UEFI memmap under OVMF is getting very fragmented, I'm now counting
>>> ~80 entries in it, under various circumstances.
>>>
>>> I recall that a platform's PlatformPei can "prime" the DXE/UEFI memory
>>> allocation system (not the GCD services) for various memory types, by
>>> producing a memory type information HOB.
>>>
>>> My vague understanding is that BDS will in turn check if the actual
>>> allocations fit in the allotments from the HOB, and if not, it will try
>>> to feed back the increased amount to PEI, for the next boot.
>>>
>>> As far as I understand, this requires the VariablePei (read only driver)
>>> for a platform (so that its PlatformPei can read the info from BDS, and
>>> produce the HOB accordingly). Some questions:
>>>
>>> - how big is VariablePei in binary form?
>>> - does it depend on permanent RAM being installed / discovered?
>>> - If so, is that dependency implemented with a static DEPEX, or with a
>>>   callback?
>>>
>>> Further questions:
>>> - what is the variable (GUID and Name) that BDS uses for this
>>>   information?
>>> - What is the format of the variable?
>>> - Does the logic depend on particular boot modes? OVMF only supports two
>>>   boot modes, BOOT_WITH_FULL_CONFIGURATION and BOOT_ON_S3_RESUME.
>>>
>>> In OVMF we currently use a static array for populating the HOB (see
>>> "mDefaultMemoryTypeInformation" in "PlatformPei/Platform.c"). If making
>>> it all dynamic is easy, I think I'd like to do it (sometime later).
>>>
>>> If, however, it would require us to up-end OVMF's PlatformPei, 

[edk2] Intel raid EFI Shell driver wanted

[david moheban]

Hi,

Was wondering if there exists an Intel Raid EFI driver that would allow one
to view the contents of an Intel Raid array within a EFI shell?

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

Re: [edk2] [PATCH 3/7] Nt32Pkg: Replace [Ascii|Unicode]ValueToString

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao
> Wu
> Sent: Tuesday, February 21, 2017 7:36 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ni, Ruiyu ; Yao,
> Jiewen 
> Subject: [edk2] [PATCH 3/7] Nt32Pkg: Replace [Ascii|Unicode]ValueToString
> 
> It is the follow up of commits 51f0ceb..9e32e97 to replace
> AsciiValueToString/UnicodeValueToString with
> AsciiValueToStringS/UnicodeValueToStringS.
> 
> Cc: Jiewen Yao 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c
> b/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c
> index 93ecc7d..53e9ff4 100644
> --- a/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c
> +++ b/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c
> @@ -1,7 +1,7 @@
>  /** @file
>Perform the platform memory test
> 
> -Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 2017, 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 @@ -155,7 +155,7 
> @@
> PlatformBootManagerMemoryTest (
>TempData
>);
>if (TestPercent != PreviousValue) {
> -UnicodeValueToString (StrPercent, 0, TestPercent, 0);
> +UnicodeValueToStringS (StrPercent, sizeof (StrPercent), 0,
> + TestPercent, 0);
>  TmpStr = HiiGetString (gStringPackHandle, STRING_TOKEN
> (STR_MEMORY_TEST_PERCENT), NULL);
>  if (TmpStr != NULL) {
>//
> @@ -223,7 +223,7 @@ PlatformBootManagerMemoryTest (
> 
>  Done:
>if (!FeaturePcdGet(PcdBootlogoOnlyEnable)) {
> -UnicodeValueToString (StrTotalMemory, COMMA_TYPE, TotalMemorySize,
> 0);
> +UnicodeValueToStringS (StrTotalMemory, StrTotalMemorySize,
> + COMMA_TYPE, TotalMemorySize, 0);
>  if (StrTotalMemory[0] == L',') {
>StrTotalMemory++;
>StrTotalMemorySize -= sizeof (CHAR16);
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/6] OvmfPkg: AcpiPlatformDxe, QemuFwCfg: small cleanups after WRITE_POINTER

[Jordan Justen]

Good cleanups. Thanks for taking the extra time sort these out!

Reviewed-by: Jordan Justen 

Unfortunately, https://bugzilla.tianocore.org/show_bug.cgi?id=394 may
not be quite so 'fun'. :)

-Jordan

On 2017-02-21 07:38:06, Laszlo Ersek wrote:
> Most of these were suggested by Jordan.
> 
> Cc: Jordan Justen 
> 
> Repo:   https://github.com/lersek/edk2.git
> Branch: write_pointer_followup
> 
> Thanks!
> Laszlo
> 
> Laszlo Ersek (6):
>   OvmfPkg/AcpiPlatformDxe: drop double right shift in ADD/WRITE POINTER
> cmds
>   OvmfPkg/AcpiPlatformDxe: update PointerValue comments in
> "BootScript.c"
>   OvmfPkg/QemuFwCfgLib: move types/macros from lib class to
> IndustryStandard
>   OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_SELECTOR, adapt the package
>   OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_DATA, adapt the package
>   OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_DMA_ADDRESS, adapt the package
> 
>  OvmfPkg/Include/IndustryStandard/QemuFwCfg.h | 104 
>  OvmfPkg/Include/Library/QemuFwCfgLib.h   |  70 +
>  OvmfPkg/AcpiPlatformDxe/BootScript.c |  18 ++--
>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c  |   8 +-
>  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c  |  12 +--
>  OvmfPkg/SmmControl2Dxe/SmiFeatures.c |   6 +-
>  6 files changed, 128 insertions(+), 90 deletions(-)
>  create mode 100644 OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
> 
> -- 
> 2.9.3
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] 答复: Question for memory type: EfiReservedMemoryType

[Liu Pedroa]

According to ACPI 6.1  Spec :

Platform runtime firmware can use the AddressRangeReserved address range type 
to block out 
various addresses as not suitable for use by a programmable device. Some of the 
reasons a platform 
runtime firmware would do this are:
? The address range contains system ROM.
? The address range contains RAM in use by the ROM.
? The address range is in use by a memory-mapped system device.
? The address range is, for whatever reason, unsuitable for a standard device 
to use as a device 
memory space.
? The address range is within an NVRAM device where reads and writes to memory 
locations are 
no longer successful, that is, the device was worn out.








-邮件原件-
发件人: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] 代表 Kirkendall, Garrett
发送时间: 2017年2月17日 23:55
收件人: edk2-devel@lists.01.org
主题: [edk2] Question for memory type: EfiReservedMemoryType

The UEFI spec says:
EfiReservedMemoryType - Not usable.

Some people take this to mean that you should not use this memory type.  Some 
think it will mark the memory as unusable by UEFI or OS.

Could the spec be updated to be more precise as to the meaning?

As far as I can tell, the code will allocate memory of type 
EfiReservedMemoryType and will not use that memory.

Garrett Kirkendall
SMTS Firmware Engineer | CTE
7171 Southwest Parkway, Austin, TX 78735 USA
AMD   facebook  |  amd.com

___
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] memory type information HOB / UEFI memmap defrag

[Kinney, Michael D]

Jordan,

The usage of EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData
may vary from boot to boot, especially if the shell or other applications
are run or different OSes are booted.  A change in the bin size causes
extra variable writes and potentially extra reboots.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
> Justen
> Sent: Tuesday, February 21, 2017 5:32 PM
> To: Yao, Jiewen ; Laszlo Ersek ; 
> edk2-devel-
> 01 
> Cc: Ni, Ruiyu ; Andrew Fish ; Ard 
> Biesheuvel
> 
> Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag
> 
> On 2017-02-21 16:46:40, Yao, Jiewen wrote:
> > HI Laszlo
> >
> > The purpose of this table to put OS consumed memory together to avoid S4 
> > resume
> > issue. EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData are not used 
> > by
> > OS. There is no need to put them here.
> >
> > I suggest we remove EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData 
> > to
> > avoid confusing.
> >
> 
> Is there any other advantage to removing them?
> 
> I guess it would be easy enough to re-add them, but I don't think we
> need to move away from supporting S4. While I agree that S4 should not
> be a big priority, I'd prefer that we try to support it at some point.
> 
> -Jordan
> 
> >
> > > +  { EfiReservedMemoryType,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *   202) 
> > > },
> > > +  { EfiLoaderCode,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1439) 
> > > },
> > > +  { EfiBootServicesCode,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  5980) 
> > > },
> > > +  { EfiBootServicesData,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 41643) 
> > > },
> > > +  { EfiRuntimeServicesCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1025) 
> > > },
> > > +  { EfiRuntimeServicesData, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  3629) 
> > > },
> > > +  { EfiACPIReclaimMemory,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *36) 
> > > },
> > > +  { EfiACPIMemoryNVS,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1301) 
> > > },
> > > +  { EfiMaxMemoryType,   0   }
> >
> >
> >
> > Thank you
> >
> > Yao Jiewen
> >
> >
> >
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > Laszlo
> > Ersek
> > Sent: Tuesday, February 21, 2017 11:24 PM
> > To: edk2-devel-01 
> > Cc: Ni, Ruiyu ; Justen, Jordan L
> > ; Andrew Fish ; Ard Biesheuvel
> > 
> > Subject: [edk2] memory type information HOB / UEFI memmap defrag
> >
> >
> >
> > Hi,
> >
> > the UEFI memmap under OVMF is getting very fragmented, I'm now counting
> > ~80 entries in it, under various circumstances.
> >
> > I recall that a platform's PlatformPei can "prime" the DXE/UEFI memory
> > allocation system (not the GCD services) for various memory types, by
> > producing a memory type information HOB.
> >
> > My vague understanding is that BDS will in turn check if the actual
> > allocations fit in the allotments from the HOB, and if not, it will try
> > to feed back the increased amount to PEI, for the next boot.
> >
> > As far as I understand, this requires the VariablePei (read only driver)
> > for a platform (so that its PlatformPei can read the info from BDS, and
> > produce the HOB accordingly). Some questions:
> >
> > - how big is VariablePei in binary form?
> > - does it depend on permanent RAM being installed / discovered?
> > - If so, is that dependency implemented with a static DEPEX, or with a
> >   callback?
> >
> > Further questions:
> > - what is the variable (GUID and Name) that BDS uses for this
> >   information?
> > - What is the format of the variable?
> > - Does the logic depend on particular boot modes? OVMF only supports two
> >   boot modes, BOOT_WITH_FULL_CONFIGURATION and BOOT_ON_S3_RESUME.
> >
> > In OVMF we currently use a static array for populating the HOB (see
> > "mDefaultMemoryTypeInformation" in "PlatformPei/Platform.c"). If making
> > it all dynamic is easy, I think I'd like to do it (sometime later).
> >
> > If, however, it would require us to up-end OVMF's PlatformPei, then I
> > think it's not worth it; we can just bump the values in
> > "mDefaultMemoryTypeInformation" suitably.
> >
> > Some examples I consider as up-ending OVMF's PlatformPei:
> >
> > (1) If VariablePei needs permanent RAM with a hard DEPEX. In OVMF,
> > permanent RAM is installed by PlatformPei (thereby potentially
> > unblocking VariablePei's dispatch); however, it is also PlatformPei
> > that would require the r/o variable service to work, because
> > PlatformPei produces the memory type information HOB. So, such a
> > DEPEX in VariablePei would require splitting up PlatformPei, which
> > makes the dynamism totally not worth it.
> >
> > *Maybe* we 

Re: [edk2] memory type information HOB / UEFI memmap defrag

[Jordan Justen]

On 2017-02-21 16:46:40, Yao, Jiewen wrote:
> HI Laszlo
> 
> The purpose of this table to put OS consumed memory together to avoid S4 
> resume
> issue. EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData are not used by
> OS. There is no need to put them here.
> 
> I suggest we remove EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData to
> avoid confusing.
> 

Is there any other advantage to removing them?

I guess it would be easy enough to re-add them, but I don't think we
need to move away from supporting S4. While I agree that S4 should not
be a big priority, I'd prefer that we try to support it at some point.

-Jordan

> 
> > +  { EfiReservedMemoryType,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *   202) },
> > +  { EfiLoaderCode,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1439) },
> > +  { EfiBootServicesCode,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  5980) },
> > +  { EfiBootServicesData,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 41643) },
> > +  { EfiRuntimeServicesCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1025) },
> > +  { EfiRuntimeServicesData, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  3629) },
> > +  { EfiACPIReclaimMemory,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *36) },
> > +  { EfiACPIMemoryNVS,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1301) },
> > +  { EfiMaxMemoryType,   0   }
> 
>  
> 
> Thank you
> 
> Yao Jiewen
> 
>  
> 
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, February 21, 2017 11:24 PM
> To: edk2-devel-01 
> Cc: Ni, Ruiyu ; Justen, Jordan L
> ; Andrew Fish ; Ard Biesheuvel
> 
> Subject: [edk2] memory type information HOB / UEFI memmap defrag
> 
>  
> 
> Hi,
> 
> the UEFI memmap under OVMF is getting very fragmented, I'm now counting
> ~80 entries in it, under various circumstances.
> 
> I recall that a platform's PlatformPei can "prime" the DXE/UEFI memory
> allocation system (not the GCD services) for various memory types, by
> producing a memory type information HOB.
> 
> My vague understanding is that BDS will in turn check if the actual
> allocations fit in the allotments from the HOB, and if not, it will try
> to feed back the increased amount to PEI, for the next boot.
> 
> As far as I understand, this requires the VariablePei (read only driver)
> for a platform (so that its PlatformPei can read the info from BDS, and
> produce the HOB accordingly). Some questions:
> 
> - how big is VariablePei in binary form?
> - does it depend on permanent RAM being installed / discovered?
> - If so, is that dependency implemented with a static DEPEX, or with a
>   callback?
> 
> Further questions:
> - what is the variable (GUID and Name) that BDS uses for this
>   information?
> - What is the format of the variable?
> - Does the logic depend on particular boot modes? OVMF only supports two
>   boot modes, BOOT_WITH_FULL_CONFIGURATION and BOOT_ON_S3_RESUME.
> 
> In OVMF we currently use a static array for populating the HOB (see
> "mDefaultMemoryTypeInformation" in "PlatformPei/Platform.c"). If making
> it all dynamic is easy, I think I'd like to do it (sometime later).
> 
> If, however, it would require us to up-end OVMF's PlatformPei, then I
> think it's not worth it; we can just bump the values in
> "mDefaultMemoryTypeInformation" suitably.
> 
> Some examples I consider as up-ending OVMF's PlatformPei:
> 
> (1) If VariablePei needs permanent RAM with a hard DEPEX. In OVMF,
> permanent RAM is installed by PlatformPei (thereby potentially
> unblocking VariablePei's dispatch); however, it is also PlatformPei
> that would require the r/o variable service to work, because
> PlatformPei produces the memory type information HOB. So, such a
> DEPEX in VariablePei would require splitting up PlatformPei, which
> makes the dynamism totally not worth it.
> 
> *Maybe* we could add a callback for when the variable service PPI is
> installed. Dunno.
> 
> (2) Supporting a third boot mode beyond BOOT_WITH_FULL_CONFIGURATION and
> BOOT_ON_S3_RESUME. Not even worth the audit of current boot mode
> checks.
> 
> Further remarks:
> 
> - OVMF doesn't care about supporting S4 at the moment, and I personally
>   have no plans to work on that. (I'm saying this because I vaguely
>   recall that the memory type info HOB is related to S4 resume, so an
>   argument could perhaps be made, "this could enable S4 for OVMF".
>   Personally, I'm not interested. Still carrying the scars of S3.)
> 
> - I actually tried to bump the values in "mDefaultMemoryTypeInformation"
>   quite a few months back, but the benefits I saw were negligible. I was
>   left confused about the memory type info HOB, and that was the reason
>   I didn't ultimately post any patch (and why I stopped pursuing this
>   question). For reference, this was the patch:
> 
> > commit 

Re: [edk2] [PATCH v2 1/2] UefiCpuPkg/CpuDxe: Copy two functions from PciHostBridge

[Fan, Jeff]

Laszlo,

For 1), I will update this typo when pushing the serial of patches. Thanks!

For2), I will do clean up on EFI_D to DEBUG_ in CpuDxe driver after Jiewen & my 
patches pushed.

Thanks!
Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, February 21, 2017 6:57 PM
To: Fan, Jeff; edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Tian, Feng; Kinney, Michael D
Subject: Re: [PATCH v2 1/2] UefiCpuPkg/CpuDxe: Copy two functions from 
PciHostBridge

I have two suggestions for this patch:

On 02/21/17 04:08, Jeff Fan wrote:
> Copy AddMemoryMappedIoSpace() and AddMemoryMappedIoSpace() from 
> MdeModulePkg\Bus\Pci\PciHostBridgeDxe\PciHostBridge.c.

(1) One of the two "AddMemoryMappedIoSpace" strings should be replaced with 
"IntersectMemoryDescriptor".

This can be done when you commit / push the patch; no need to repost just 
because of it.

(2) This is more of a "followup" suggestion: since this is new code, I 
recommend that the EFI_D_ macros be replced with DEBUG_ macros.

However, I see value in keeping the first patch as a pristine copy from the 
PciHostBridgeDxe driver, so I don't recommend doing the above change in patch 
#1. I think it can be patch #3, or a completely separate patch (later).

Series
Reviewed-by: Laszlo Ersek 
Regression-tested-by: Laszlo Ersek 

Thanks!
Laszlo

> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=390
> 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Feng Tian 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan 
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.c | 148 
> +
>  1 file changed, 148 insertions(+)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c 
> index 9fb6d76..925c50f 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
> @@ -887,6 +887,154 @@ IdleLoopEventCallback (
>CpuSleep ();
>  }
>  
> +/**
> +  Ensure the compatibility of a memory space descriptor with the MMIO 
> aperture.
> +
> +  The memory space descriptor can come from the GCD memory space map, 
> + or it can  represent a gap between two neighboring memory space 
> + descriptors. In the  latter case, the GcdMemoryType field is 
> + expected to be  EfiGcdMemoryTypeNonExistent.
> +
> +  If the memory space descriptor already has type  
> + EfiGcdMemoryTypeMemoryMappedIo, and its capabilities are a superset 
> + of the  required capabilities, then no action is taken -- it is by 
> + definition  compatible with the aperture.
> +
> +  Otherwise, the intersection of the memory space descriptor is 
> + calculated with  the aperture. If the intersection is the empty set 
> + (no overlap), no action is  taken; the memory space descriptor is 
> compatible with the aperture.
> +
> +  Otherwise, the type of the descriptor is investigated again. If the 
> + type is  EfiGcdMemoryTypeNonExistent (representing a gap, or a 
> + genuine descriptor with  such a type), then an attempt is made to 
> + add the intersection as MMIO space  to the GCD memory space map, 
> + with the specified capabilities. This ensures  continuity for the 
> + aperture, and the descriptor is deemed compatible with the  aperture.
> +
> +  Otherwise, the memory space descriptor is incompatible with the 
> + MMIO  aperture.
> +
> +  @param[in] Base Base address of the aperture.
> +  @param[in] Length   Length of the aperture.
> +  @param[in] Capabilities Capabilities required by the aperture.
> +  @param[in] Descriptor   The descriptor to ensure compatibility with the
> +  aperture for.
> +
> +  @retval EFI_SUCCESSThe descriptor is compatible. The GCD memory
> + space map may have been updated, for
> + continuity within the aperture.
> +  @retval EFI_INVALID_PARAMETER  The descriptor is incompatible.
> +  @returnError codes from gDS->AddMemorySpace().
> +**/
> +EFI_STATUS
> +IntersectMemoryDescriptor (
> +  IN  UINT64Base,
> +  IN  UINT64Length,
> +  IN  UINT64Capabilities,
> +  IN  CONST EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Descriptor
> +  )
> +{
> +  UINT64IntersectionBase;
> +  UINT64IntersectionEnd;
> +  EFI_STATUSStatus;
> +
> +  if (Descriptor->GcdMemoryType == EfiGcdMemoryTypeMemoryMappedIo &&
> +  (Descriptor->Capabilities & Capabilities) == Capabilities) {
> +return EFI_SUCCESS;
> +  }
> +
> +  IntersectionBase = MAX (Base, Descriptor->BaseAddress);  
> + IntersectionEnd = MIN (Base + Length,
> +  Descriptor->BaseAddress + Descriptor->Length);  
> + if 

Re: [edk2] UefiCpuPkg: PiSmmCpuDxeSmm (MpServioce.c)

[Fan, Jeff]

I agree to remove it.

-Original Message-
From: Zeng, Star 
Sent: Wednesday, February 22, 2017 9:23 AM
To: Duran, Leo; Fan, Jeff; 'edk2-de...@ml01.01.org'; Tian, Feng
Cc: Yao, Jiewen; Zeng, Star
Subject: RE: UefiCpuPkg: PiSmmCpuDxeSmm (MpServioce.c)

Leo,

Seemingly, you are right that no one is using SetCacheability().

Jeff,

Could you confirm that?

Thanks,
Star

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Duran, 
Leo
Sent: Wednesday, February 22, 2017 5:44 AM
To: 'edk2-de...@ml01.01.org' ; Tian, Feng 

Cc: Zeng, Star 
Subject: [edk2] UefiCpuPkg: PiSmmCpuDxeSmm (MpServioce.c)

Hi Feng, et al,

I'm wondering if the SetCacheability() function has been deprecated from the 
build tree?
That is, the function is part of MpService.c, but it does not seem to be used 
by any other code.

Would be it be OK to remove SetCacheability() from MpService.c?
I ask because I'm preparing a patch for code that touches page-table entries, 
and I'd prefer to simply ignore/remove SetCacheability(), if it's not needed 
anymore.

Thanks,
Leo


___
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] UefiCpuPkg: PiSmmCpuDxeSmm (MpServioce.c)

[Zeng, Star]

Leo,

Seemingly, you are right that no one is using SetCacheability().

Jeff,

Could you confirm that?

Thanks,
Star

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Duran, 
Leo
Sent: Wednesday, February 22, 2017 5:44 AM
To: 'edk2-de...@ml01.01.org' ; Tian, Feng 

Cc: Zeng, Star 
Subject: [edk2] UefiCpuPkg: PiSmmCpuDxeSmm (MpServioce.c)

Hi Feng, et al,

I'm wondering if the SetCacheability() function has been deprecated from the 
build tree?
That is, the function is part of MpService.c, but it does not seem to be used 
by any other code.

Would be it be OK to remove SetCacheability() from MpService.c?
I ask because I'm preparing a patch for code that touches page-table entries, 
and I'd prefer to simply ignore/remove SetCacheability(), if it's not needed 
anymore.

Thanks,
Leo


___
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] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Rebecca Cran]

I'm a bit of a build system geek and noticed there are some improvements 
(e.g. improving build speed) that could be made to the 
devel-MinnowBoard3 branch in edk2-platforms.  I know it's still in heavy 
development, so I'm wondering if my contributions might be welcome, or 
if I should hold off for a few more months?



--

Rebecca

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

Re: [edk2] [PATCH v3 2/4] MdeModulePkg/Universal/CapsulePei: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

[Zeng, Star]

Shouldn't

((*PageFaultContext->PageFaultUplink[PageFaultContext->PageFaultIndex] & 
PageFaultContext->PhyMask) == Address)

be

(((*PageFaultContext->PageFaultUplink[PageFaultContext->PageFaultIndex] & 
~(AddressSetMask & PAGING_4K_ADDRESS_MASK_64)) & PageFaultContext->PhyMask) == 
Address)

like you did at other place?

Thanks,
Star

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Duran, 
Leo
Sent: Wednesday, February 22, 2017 12:43 AM
To: Zeng, Star ; edk2-de...@ml01.01.org
Cc: Singh, Brijesh ; Tian, Feng ; 
Laszlo Ersek 
Subject: Re: [edk2] [PATCH v3 2/4] MdeModulePkg/Universal/CapsulePei: Add 
support for PCD PcdPteMemoryEncryptionAddressOrMask

Hi Star, 

Please double-check the complete [PATCH v3 2/4].

Yes, there is a non-functional change where I did break a 'very long' line into 
2 lines as you noted (I can put that back as it was before if so required).
However the intended functional changes are applied in the rest of the patch in 
lines where I reference 'AddressSetMask'.

As for [PATCH v3 4/4]
The intended functional changes are applied... please confirm, or please let me 
know what seems to be missing.

Thanks,
Leo.

> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Monday, February 20, 2017 12:05 AM
> To: Duran, Leo ; edk2-de...@ml01.01.org
> Cc: Laszlo Ersek ; Feng Tian ; 
> Singh, Brijesh ; star.z...@intel.com
> Subject: Re: [edk2] [PATCH v3 2/4] MdeModulePkg/Universal/CapsulePei:
> Add support for PCD PcdPteMemoryEncryptionAddressOrMask
> 
> Leo,
> 
> Comments added inline.
> 
> On 2017/2/17 5:02, Leo Duran wrote:
> > This PCD holds the address mask for page table entries when memory 
> > encryption is enabled on AMD processors supporting the Secure 
> > Encrypted Virtualization (SEV) feature.
> >
> > The mask is applied when 4GB tables are created (UefiCapsule.c), and 
> > when the tables are expanded on-demand by page-faults above 4GB's
> (X64Entry.c).
> >
> > Cc: Feng Tian 
> > Cc: Star Zeng 
> > Cc: Laszlo Ersek 
> > Cc: Brijesh Singh 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Leo Duran 
> > Reviewed-by: Star Zeng 
> > ---
> >  MdeModulePkg/Universal/CapsulePei/CapsulePei.inf   |  2 ++
> >  .../Universal/CapsulePei/Common/CommonHeader.h |  7 +++
> >  MdeModulePkg/Universal/CapsulePei/UefiCapsule.c| 13 
> >  MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c   | 23
> +++---
> >  4 files changed, 34 insertions(+), 11 deletions(-)
> >
> 
> [snipped]
> 
> > diff --git a/MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c
> > b/MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c
> > index 5ad95d2..2197502 100644
> > --- a/MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c
> > +++ b/MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c
> > @@ -2,6 +2,8 @@
> >The X64 entrypoint is used to process capsule in long mode.
> >
> >  Copyright (c) 2011 - 2016, Intel Corporation. All rights 
> > reserved.
> > +Copyright (c) 2017, AMD Incorporated. 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 @@ -29,6 +31,7 @@ typedef struct _PAGE_FAULT_CONTEXT {
> >UINT64PhyMask;
> >UINTN PageFaultBuffer;
> >UINTN PageFaultIndex;
> > +  UINT64PteMemoryEncryptionAddressOrMask;
> >//
> >// Store the uplink information for each page being used.
> >//
> > @@ -114,6 +117,7 @@ AcquirePage (
> >)
> >  {
> >UINTN Address;
> > +  UINT64AddressSetMask;
> >
> >Address = PageFaultContext->PageFaultBuffer + EFI_PAGES_TO_SIZE
> (PageFaultContext->PageFaultIndex);
> >ZeroMem ((VOID *) Address, EFI_PAGES_TO_SIZE (1)); @@ -121,14
> > +125,16 @@ AcquirePage (
> >//
> >// Cut the previous uplink if it exists and wasn't overwritten.
> >//
> > -  if
> > 
> >((PageFaultContext->PageFaultUplink[PageFaultContext->PageFaultIndex]
> > != NULL) &&
> > ((*PageFaultContext->PageFaultUplink[PageFaultContext-
> >PageFaultIndex]
> > & PageFaultContext->PhyMask) == Address)) {
> > +  if ((PageFaultContext->PageFaultUplink[PageFaultContext-
> >PageFaultIndex] != NULL) &&
> > +
> > + ((*PageFaultContext->PageFaultUplink[PageFaultContext-
> >PageFaultInde
> > + x] & PageFaultContext->PhyMask) == Address)) {
> 
> No real change at here except the line feed added.
> You were going to update code at here, but forgot to do the real change?
> 

Re: [edk2] memory type information HOB / UEFI memmap defrag

[Yao, Jiewen]

HI Laszlo
The purpose of this table to put OS consumed memory together to avoid S4 resume 
issue. EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData are not used by 
OS. There is no need to put them here.

I suggest we remove EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData to 
avoid confusing.


> +  { EfiReservedMemoryType,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *   202) },
> +  { EfiLoaderCode,  EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1439) },
> +  { EfiBootServicesCode,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  5980) },
> +  { EfiBootServicesData,EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 41643) },
> +  { EfiRuntimeServicesCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1025) },
> +  { EfiRuntimeServicesData, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  3629) },
> +  { EfiACPIReclaimMemory,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *36) },
> +  { EfiACPIMemoryNVS,   EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB *  1301) },
> +  { EfiMaxMemoryType,   0   }

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Tuesday, February 21, 2017 11:24 PM
To: edk2-devel-01 
Cc: Ni, Ruiyu ; Justen, Jordan L 
; Andrew Fish ; Ard Biesheuvel 

Subject: [edk2] memory type information HOB / UEFI memmap defrag

Hi,

the UEFI memmap under OVMF is getting very fragmented, I'm now counting
~80 entries in it, under various circumstances.

I recall that a platform's PlatformPei can "prime" the DXE/UEFI memory
allocation system (not the GCD services) for various memory types, by
producing a memory type information HOB.

My vague understanding is that BDS will in turn check if the actual
allocations fit in the allotments from the HOB, and if not, it will try
to feed back the increased amount to PEI, for the next boot.

As far as I understand, this requires the VariablePei (read only driver)
for a platform (so that its PlatformPei can read the info from BDS, and
produce the HOB accordingly). Some questions:

- how big is VariablePei in binary form?
- does it depend on permanent RAM being installed / discovered?
- If so, is that dependency implemented with a static DEPEX, or with a
  callback?

Further questions:
- what is the variable (GUID and Name) that BDS uses for this
  information?
- What is the format of the variable?
- Does the logic depend on particular boot modes? OVMF only supports two
  boot modes, BOOT_WITH_FULL_CONFIGURATION and BOOT_ON_S3_RESUME.

In OVMF we currently use a static array for populating the HOB (see
"mDefaultMemoryTypeInformation" in "PlatformPei/Platform.c"). If making
it all dynamic is easy, I think I'd like to do it (sometime later).

If, however, it would require us to up-end OVMF's PlatformPei, then I
think it's not worth it; we can just bump the values in
"mDefaultMemoryTypeInformation" suitably.

Some examples I consider as up-ending OVMF's PlatformPei:

(1) If VariablePei needs permanent RAM with a hard DEPEX. In OVMF,
permanent RAM is installed by PlatformPei (thereby potentially
unblocking VariablePei's dispatch); however, it is also PlatformPei
that would require the r/o variable service to work, because
PlatformPei produces the memory type information HOB. So, such a
DEPEX in VariablePei would require splitting up PlatformPei, which
makes the dynamism totally not worth it.

*Maybe* we could add a callback for when the variable service PPI is
installed. Dunno.

(2) Supporting a third boot mode beyond BOOT_WITH_FULL_CONFIGURATION and
BOOT_ON_S3_RESUME. Not even worth the audit of current boot mode
checks.

Further remarks:

- OVMF doesn't care about supporting S4 at the moment, and I personally
  have no plans to work on that. (I'm saying this because I vaguely
  recall that the memory type info HOB is related to S4 resume, so an
  argument could perhaps be made, "this could enable S4 for OVMF".
  Personally, I'm not interested. Still carrying the scars of S3.)

- I actually tried to bump the values in "mDefaultMemoryTypeInformation"
  quite a few months back, but the benefits I saw were negligible. I was
  left confused about the memory type info HOB, and that was the reason
  I didn't ultimately post any patch (and why I stopped pursuing this
  question). For reference, this was the patch:

> commit b357e8d88c0304ea2b31aefafe53d06c9769fb78
> Author: Laszlo Ersek >
> Date:   Thu Sep 17 16:18:46 2015 +0200
>
> OvmfPkg: PlatformPei: decrease memmap fragmentation
>
> Inspired by ArmVirtPkg commit c199315 ("ArmVirtPkg: increase memory
> preallocations to reduce region count"), I checked the number of entries
> in the UEFI memory map, as dumped by the UEFI shell's MEMMAP command, and
> by the Linux kernel. The number of entries is quite high, about 50-55.
>
> I calculated the 

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Laszlo Ersek]

On 02/21/17 23:45, Jordan Justen wrote:
> On 2017-02-21 11:08:24, Rebecca Cran wrote:
>> On 2/21/2017 12:02 PM, Laszlo Ersek wrote:
>>
>>> But in this case, the full edk2 codebase has to be grepped for
>>> VA_LIST-taking functions, and all of them must be flipped to EFIAPI, if
>>> they currently aren't EFIAPI. Covering just XenStoreVSPrint() seems
>>> incomplete. (Note: CryptoPkg/Library/OpensslLib is an exception.)
>>
>> I think this was discussed previously but I can't remember: is there a 
>> reason for not just compiling everything with -mabi=ms ?
>>
> 
> Originally GCC didn't support -mabi=ms. Once it gained support, it
> then produced larger executables. Nowadays (and for quite some time),
> I think it generally results in smaller executables.
> 
> A benefit of not using -mabi=ms is that we are able to catch some
> cases of misused EFIAPI

I agree.

> with a compiler warning, or unfortunately in
> some cases with crashes or misbehaving code.
> 
> I think the benefit of helping keep EFIAPI clean means that we should
> continue to not use -mabi=ms for DEBUG builds.

I agree (also for NOOPT builds).

> But, I think it would
> be good to get the size advantages of -mabi=ms by enabling it for
> RELEASE builds.

That sounds useful too (even though it wouldn't make the current problem go 
away).

As one caveat, I believe -mabi=ms wouldn't be allowed for building OpensslLib 
even for RELEASE. See "-DNO_MSABI_VA_FUNCS" in "OpensslLib.inf":

commit b2dc04a87fab89307240dc0f30b9a23bb5726c81
Author: Ard Biesheuvel 
Date:   Sun Jul 17 11:57:45 2016 +0200

CryptoPkg: set new define to avoid MS ABI VA_LIST on GCC/X64

Set the #define NO_MSABI_VA_FUNCS that will be introduced in a subsequent
patch to avoid the use of the MS ABI in variadic functions. In EDK2, such
functions normally require the EFIAPI modifier to be used, but for external
libraries such as OpenSSL, which lack these annotations, it is easier to
simply revert to the default SysV style VA_LIST ABI.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jordan Justen 
Tested-by: Laszlo Ersek 
Tested-By: Liming Gao 
Reviewed-by: Liming Gao 

Thanks!
Laszlo

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

Re: [edk2] memory type information HOB / UEFI memmap defrag

[Laszlo Ersek]

On 02/21/17 23:35, Jordan Justen wrote:
> On 2017-02-21 07:24:11, Laszlo Ersek wrote:
>> Hi,
>>
>> the UEFI memmap under OVMF is getting very fragmented, I'm now counting
>> ~80 entries in it, under various circumstances.
>>
>> I recall that a platform's PlatformPei can "prime" the DXE/UEFI memory
>> allocation system (not the GCD services) for various memory types, by
>> producing a memory type information HOB.
>>
>> My vague understanding is that BDS will in turn check if the actual
>> allocations fit in the allotments from the HOB, and if not, it will try
>> to feed back the increased amount to PEI, for the next boot.
>>
>> As far as I understand, this requires the VariablePei (read only driver)
>> for a platform (so that its PlatformPei can read the info from BDS, and
>> produce the HOB accordingly). Some questions:
>>
>> - how big is VariablePei in binary form?
>> - does it depend on permanent RAM being installed / discovered?
>> - If so, is that dependency implemented with a static DEPEX, or with a
>>   callback?
>>
>> Further questions:
>> - what is the variable (GUID and Name) that BDS uses for this
>>   information?
> 
> I think grep for EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME.

Thanks, that looks very interesting:

* Apparently, if the PEI phase does not produce the info HOB, but it
includes the VariablePei driver, then the DXE IPL PEIM will itself build
the HOB, from the variable.

This seems to eliminate a lot of trouble: for example, if the platform
includes VariablePei, then that will surely be available by the time the
DXE IPL PEIM looks for it, in DxeLoadCore(). (No ordering or dependency
problems, that is!)

* BmSetMemoryTypeInformationVariable()
[MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c] seems to read the
variable (if it exists) under all boot modes different from
BOOT_WITH_DEFAULT_SETTINGS, and to set the variable if it doesn't exist,
or the page counts were changed.

For BOOT_WITH_FULL_CONFIGURATION, as a special case of the above, the
page counts never decrease, only increase, which looks good too.


Based on the above, solving the fragmentation could be as simple as: (a)
including VariablePei in OvmfPkg, (b) removing the HOB production from
OvmfPkg/PlatformPei.

I'll give it a whirl later on, and see how it affects the fragmentation.

Thank you Jordan, this was *really* helpful!
Laszlo

> 
> -Jordan
> 
>> - What is the format of the variable?
>> - Does the logic depend on particular boot modes? OVMF only supports two
>>   boot modes, BOOT_WITH_FULL_CONFIGURATION and BOOT_ON_S3_RESUME.
>>
>> In OVMF we currently use a static array for populating the HOB (see
>> "mDefaultMemoryTypeInformation" in "PlatformPei/Platform.c"). If making
>> it all dynamic is easy, I think I'd like to do it (sometime later).
>>
>> If, however, it would require us to up-end OVMF's PlatformPei, then I
>> think it's not worth it; we can just bump the values in
>> "mDefaultMemoryTypeInformation" suitably.
>>
>> Some examples I consider as up-ending OVMF's PlatformPei:
>>
>> (1) If VariablePei needs permanent RAM with a hard DEPEX. In OVMF,
>> permanent RAM is installed by PlatformPei (thereby potentially
>> unblocking VariablePei's dispatch); however, it is also PlatformPei
>> that would require the r/o variable service to work, because
>> PlatformPei produces the memory type information HOB. So, such a
>> DEPEX in VariablePei would require splitting up PlatformPei, which
>> makes the dynamism totally not worth it.
>>
>> *Maybe* we could add a callback for when the variable service PPI is
>> installed. Dunno.
>>
>> (2) Supporting a third boot mode beyond BOOT_WITH_FULL_CONFIGURATION and
>> BOOT_ON_S3_RESUME. Not even worth the audit of current boot mode
>> checks.
>>
>> Further remarks:
>>
>> - OVMF doesn't care about supporting S4 at the moment, and I personally
>>   have no plans to work on that. (I'm saying this because I vaguely
>>   recall that the memory type info HOB is related to S4 resume, so an
>>   argument could perhaps be made, "this could enable S4 for OVMF".
>>   Personally, I'm not interested. Still carrying the scars of S3.)
>>
>> - I actually tried to bump the values in "mDefaultMemoryTypeInformation"
>>   quite a few months back, but the benefits I saw were negligible. I was
>>   left confused about the memory type info HOB, and that was the reason
>>   I didn't ultimately post any patch (and why I stopped pursuing this
>>   question). For reference, this was the patch:
>>
>>> commit b357e8d88c0304ea2b31aefafe53d06c9769fb78
>>> Author: Laszlo Ersek 
>>> Date:   Thu Sep 17 16:18:46 2015 +0200
>>>
>>> OvmfPkg: PlatformPei: decrease memmap fragmentation
>>>
>>> Inspired by ArmVirtPkg commit c199315 ("ArmVirtPkg: increase memory
>>> preallocations to reduce region count"), I checked the number of entries
>>> in the UEFI memory map, as dumped by the UEFI shell's MEMMAP command, 
>>> and
>>> by the Linux kernel. 

Re: [edk2] Followup : EfiTestManagedDevice() issue in driver GetControllerName() function

[David A. Van Arnem]

On 02/21/2017 03:30 PM, Jeff Westfahl wrote:
> Hi David,
> 
> You would install the protocol in the start function of your driver.
> When the start function is called, it passes you an EFI_HANDLE. You
> install your protocol on this handle.

Great!  Thanks for your time.

Regards,
David

> 
> Regards,
> Jeff
> 
> On Tue, 21 Feb 2017, David A. Van Arnem wrote:
> 
>> Hi Jeff,
>>
>> On 02/21/2017 03:10 PM, Jeff Westfahl wrote:
>>> Hello David,
>>>
>>> It sounds like you are trying to get a list of handles to your specific
>>> devices, correct?
>>
>> Yes, exactly.
>>
>>>
>>> One way to do this is to create a new protocol for your devices and
>>> create an instance of this protocol when your driver attaches to a PCI
>>> device. Then you can just retrieve all handles that match your new
>>> protocol.
>>>
>>> Creating a new protocol for this use case could be as simple as just
>>> allocating a unique GUID, using uuidgen or something similar. You don't
>>> necessarily need to have data or functions associated with your protocol
>>> for this purpose, although that may prove useful.
>>
>> This sounds like a simple method to accomplish what I need, thanks.  I
>> assume I would install the custom protocol in the same place I install
>> the Driver Binding and Component Name(2) implementations?
>>
>> Regards,
>> David
>>
>>>
>>> I wouldn't consider myself an expert of any kind on UEFI drivers, so if
>>> others see problems with my suggestions or have better ideas, please
>>> chime in.
>>>
>>> Regards,
>>> Jeff
>>>
>>> On Tue, 21 Feb 2017, David A. Van Arnem wrote:
>>>
 Hello again,

 I think the problem lies in my application, as upon further
 investigation, all the handles that publish the Component Name 2
 protocol appear to be failing the EfiTestManagedDevice() check (they
 all
 return EFI_UNSUPPORTED).  My eventual goal is, given a buffer of
 handles
 that publish EFI_PCI_IO_PROTOCOL, I would like to locate my specific
 device.  I was going to do a string comparison of the ControllerName,
 but this doesn't seem to be the right approach.  Is there a recommended
 way to accomplish this?

 Regards,
 David

 On 02/21/2017 01:07 PM, David A. Van Arnem wrote:
> Hi all,
>
> I am developing a UEFI_DRIVER for a custom PCIe device.  I've followed
> the UEFI Driver Model, and implemented the Driver Binding, Component
> Name, and Component Name 2 protocols for my driver.  I'm trying to
> retrieve the Controller Name from this driver in a
> UEFI_APPLICATION, but
> I've run into an issue.
>
> In the driver's Start() function, I open the EFI_PCI_IO_PROTOCOL on
> ControllerHandle using the following:
>
> Status = gBS->OpenProtocol (
> ControllerHandle,
> ,
> (VOID **),
> This->DriverBindingHandle,
> ControllerHandle,
> EFI_OPEN_PROTOCOL_BY_DRIVER
> );
>
> And leave it open when Start() exits, unless some other part of the
> Start() function fails, which doesn't appear to be happening based
> on my
> debug messages.
>
> Following some of the examples in edk2, in my Component Name's
> GetControllerName() function, I used EfiTestManagedDevice() to check
> that the ControllerHandle opened EFI_PCI_IO_PROTOCOL:
>
> Status = EfiTestManagedDevice (
> ControllerHandle,
> gDriverBinding.DriverBindingHandle,
> 
> );
>
> Finally, to get the Controller Name in the application, I first get a
> buffer of handles that publish the ComponentName2 protocol, then walk
> through each and call GetControllerName().
>
> However, the EfiTestManagedDevice() check in my driver is returning
> EFI_UNSUPPORTED, indicating the protocol is not supported on the
> handle.
>  Furthermore, after using "load .efi" from the shell,
> openinfo on the handle returns:
>
> Handle 188 (6E16A798)
> ComponentName2
> ComponentName
> DriverBinding
>   Drv[01] Ctrl[ ] Cnt(200) HandProt  Image()
> ImageDevicePath
>   Drv[187] Ctrl[ ] Cnt(01) GetProt  Image()
> LoadedImage
>   Drv[01] Ctrl[ ] Cnt(09) HandProt  Image()
>
> I feel like maybe I'm missing a step here.  Should I see PciIo in
> openinfo?  Do I need to open a "child" instance of the
> ControllerHandle
> in my application to get EfiTestManagedDevice() to pass?  I'm not sure
> if that's the right terminology, I'm having a little difficulty
> understanding the "child" concept in this context.  Any tips
> appreciated.
>

 -- 
 Regards,
 David Van Arnem
 Development Engineer IV
 Computer Measurement Laboratory, LLC

 ___
 edk2-devel mailing list
 edk2-devel@lists.01.org
 

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Jordan Justen]

On 2017-02-21 11:08:24, Rebecca Cran wrote:
> On 2/21/2017 12:02 PM, Laszlo Ersek wrote:
> 
> > But in this case, the full edk2 codebase has to be grepped for
> > VA_LIST-taking functions, and all of them must be flipped to EFIAPI, if
> > they currently aren't EFIAPI. Covering just XenStoreVSPrint() seems
> > incomplete. (Note: CryptoPkg/Library/OpensslLib is an exception.)
> 
> I think this was discussed previously but I can't remember: is there a 
> reason for not just compiling everything with -mabi=ms ?
> 

Originally GCC didn't support -mabi=ms. Once it gained support, it
then produced larger executables. Nowadays (and for quite some time),
I think it generally results in smaller executables.

A benefit of not using -mabi=ms is that we are able to catch some
cases of misused EFIAPI with a compiler warning, or unfortunately in
some cases with crashes or misbehaving code.

I think the benefit of helping keep EFIAPI clean means that we should
continue to not use -mabi=ms for DEBUG builds. But, I think it would
be good to get the size advantages of -mabi=ms by enabling it for
RELEASE builds.

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

Re: [edk2] memory type information HOB / UEFI memmap defrag

[Jordan Justen]

On 2017-02-21 07:24:11, Laszlo Ersek wrote:
> Hi,
> 
> the UEFI memmap under OVMF is getting very fragmented, I'm now counting
> ~80 entries in it, under various circumstances.
> 
> I recall that a platform's PlatformPei can "prime" the DXE/UEFI memory
> allocation system (not the GCD services) for various memory types, by
> producing a memory type information HOB.
> 
> My vague understanding is that BDS will in turn check if the actual
> allocations fit in the allotments from the HOB, and if not, it will try
> to feed back the increased amount to PEI, for the next boot.
> 
> As far as I understand, this requires the VariablePei (read only driver)
> for a platform (so that its PlatformPei can read the info from BDS, and
> produce the HOB accordingly). Some questions:
> 
> - how big is VariablePei in binary form?
> - does it depend on permanent RAM being installed / discovered?
> - If so, is that dependency implemented with a static DEPEX, or with a
>   callback?
> 
> Further questions:
> - what is the variable (GUID and Name) that BDS uses for this
>   information?

I think grep for EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME.

-Jordan

> - What is the format of the variable?
> - Does the logic depend on particular boot modes? OVMF only supports two
>   boot modes, BOOT_WITH_FULL_CONFIGURATION and BOOT_ON_S3_RESUME.
> 
> In OVMF we currently use a static array for populating the HOB (see
> "mDefaultMemoryTypeInformation" in "PlatformPei/Platform.c"). If making
> it all dynamic is easy, I think I'd like to do it (sometime later).
> 
> If, however, it would require us to up-end OVMF's PlatformPei, then I
> think it's not worth it; we can just bump the values in
> "mDefaultMemoryTypeInformation" suitably.
> 
> Some examples I consider as up-ending OVMF's PlatformPei:
> 
> (1) If VariablePei needs permanent RAM with a hard DEPEX. In OVMF,
> permanent RAM is installed by PlatformPei (thereby potentially
> unblocking VariablePei's dispatch); however, it is also PlatformPei
> that would require the r/o variable service to work, because
> PlatformPei produces the memory type information HOB. So, such a
> DEPEX in VariablePei would require splitting up PlatformPei, which
> makes the dynamism totally not worth it.
> 
> *Maybe* we could add a callback for when the variable service PPI is
> installed. Dunno.
> 
> (2) Supporting a third boot mode beyond BOOT_WITH_FULL_CONFIGURATION and
> BOOT_ON_S3_RESUME. Not even worth the audit of current boot mode
> checks.
> 
> Further remarks:
> 
> - OVMF doesn't care about supporting S4 at the moment, and I personally
>   have no plans to work on that. (I'm saying this because I vaguely
>   recall that the memory type info HOB is related to S4 resume, so an
>   argument could perhaps be made, "this could enable S4 for OVMF".
>   Personally, I'm not interested. Still carrying the scars of S3.)
> 
> - I actually tried to bump the values in "mDefaultMemoryTypeInformation"
>   quite a few months back, but the benefits I saw were negligible. I was
>   left confused about the memory type info HOB, and that was the reason
>   I didn't ultimately post any patch (and why I stopped pursuing this
>   question). For reference, this was the patch:
> 
> > commit b357e8d88c0304ea2b31aefafe53d06c9769fb78
> > Author: Laszlo Ersek 
> > Date:   Thu Sep 17 16:18:46 2015 +0200
> >
> > OvmfPkg: PlatformPei: decrease memmap fragmentation
> >
> > Inspired by ArmVirtPkg commit c199315 ("ArmVirtPkg: increase memory
> > preallocations to reduce region count"), I checked the number of entries
> > in the UEFI memory map, as dumped by the UEFI shell's MEMMAP command, 
> > and
> > by the Linux kernel. The number of entries is quite high, about 50-55.
> >
> > I calculated the new preallocations as follows:
> > - added 15% to each byte count usage reported by the MEMMAP command, for
> >   some future-proofing,
> > - expressed the result in kilobytes (both pages and byte counts are hard
> >   to read),
> > - just for our information, I calculated the ratio between the new
> >   preallocation and the old one.
> >
> > For example, the UEFI shell reported 44 pages (180224 bytes) of reserved
> > memory usage. The new preallocation, expressed in kilobytes, is
> > trunc(180224 * 1.15 / 1024) = 202. This preallocation is approx. 12.62
> > times the previous preallocation (which was 4 pages, ie. 16384 bytes).
> >
> > Here's the full table:
> >
> >   memory type  pages from  bytes from  new KBfactor of former
> >MEMMAP cmd  MEMMAP cmd  prealloc  prealloc
> >   ---  --  --    
> >   Reserved 44  180224   202 12.62
> >   LoaderCode  313 1282048  1439   n/a
> >   BS_Code1300 5324800  5980  3.89
> >   BS_Data 

Re: [edk2] Followup : EfiTestManagedDevice() issue in driver GetControllerName() function

[Jeff Westfahl]

Hi David,

You would install the protocol in the start function of your driver. When 
the start function is called, it passes you an EFI_HANDLE. You install 
your protocol on this handle.


Regards,
Jeff

On Tue, 21 Feb 2017, David A. Van Arnem wrote:


Hi Jeff,

On 02/21/2017 03:10 PM, Jeff Westfahl wrote:

Hello David,

It sounds like you are trying to get a list of handles to your specific
devices, correct?


Yes, exactly.



One way to do this is to create a new protocol for your devices and
create an instance of this protocol when your driver attaches to a PCI
device. Then you can just retrieve all handles that match your new
protocol.

Creating a new protocol for this use case could be as simple as just
allocating a unique GUID, using uuidgen or something similar. You don't
necessarily need to have data or functions associated with your protocol
for this purpose, although that may prove useful.


This sounds like a simple method to accomplish what I need, thanks.  I
assume I would install the custom protocol in the same place I install
the Driver Binding and Component Name(2) implementations?

Regards,
David



I wouldn't consider myself an expert of any kind on UEFI drivers, so if
others see problems with my suggestions or have better ideas, please
chime in.

Regards,
Jeff

On Tue, 21 Feb 2017, David A. Van Arnem wrote:


Hello again,

I think the problem lies in my application, as upon further
investigation, all the handles that publish the Component Name 2
protocol appear to be failing the EfiTestManagedDevice() check (they all
return EFI_UNSUPPORTED).  My eventual goal is, given a buffer of handles
that publish EFI_PCI_IO_PROTOCOL, I would like to locate my specific
device.  I was going to do a string comparison of the ControllerName,
but this doesn't seem to be the right approach.  Is there a recommended
way to accomplish this?

Regards,
David

On 02/21/2017 01:07 PM, David A. Van Arnem wrote:

Hi all,

I am developing a UEFI_DRIVER for a custom PCIe device.  I've followed
the UEFI Driver Model, and implemented the Driver Binding, Component
Name, and Component Name 2 protocols for my driver.  I'm trying to
retrieve the Controller Name from this driver in a UEFI_APPLICATION, but
I've run into an issue.

In the driver's Start() function, I open the EFI_PCI_IO_PROTOCOL on
ControllerHandle using the following:

Status = gBS->OpenProtocol (
ControllerHandle,
,
(VOID **),
This->DriverBindingHandle,
ControllerHandle,
EFI_OPEN_PROTOCOL_BY_DRIVER
);

And leave it open when Start() exits, unless some other part of the
Start() function fails, which doesn't appear to be happening based on my
debug messages.

Following some of the examples in edk2, in my Component Name's
GetControllerName() function, I used EfiTestManagedDevice() to check
that the ControllerHandle opened EFI_PCI_IO_PROTOCOL:

Status = EfiTestManagedDevice (
ControllerHandle,
gDriverBinding.DriverBindingHandle,

);

Finally, to get the Controller Name in the application, I first get a
buffer of handles that publish the ComponentName2 protocol, then walk
through each and call GetControllerName().

However, the EfiTestManagedDevice() check in my driver is returning
EFI_UNSUPPORTED, indicating the protocol is not supported on the handle.
 Furthermore, after using "load .efi" from the shell,
openinfo on the handle returns:

Handle 188 (6E16A798)
ComponentName2
ComponentName
DriverBinding
  Drv[01] Ctrl[ ] Cnt(200) HandProt  Image()
ImageDevicePath
  Drv[187] Ctrl[ ] Cnt(01) GetProt  Image()
LoadedImage
  Drv[01] Ctrl[ ] Cnt(09) HandProt  Image()

I feel like maybe I'm missing a step here.  Should I see PciIo in
openinfo?  Do I need to open a "child" instance of the ControllerHandle
in my application to get EfiTestManagedDevice() to pass?  I'm not sure
if that's the right terminology, I'm having a little difficulty
understanding the "child" concept in this context.  Any tips
appreciated.



--
Regards,
David Van Arnem
Development Engineer IV
Computer Measurement Laboratory, LLC

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



--
Regards,
David Van Arnem
Development Engineer IV
Computer Measurement Laboratory, LLC



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

Re: [edk2] Followup : EfiTestManagedDevice() issue in driver GetControllerName() function

[David A. Van Arnem]

Hi Jeff,

On 02/21/2017 03:10 PM, Jeff Westfahl wrote:
> Hello David,
> 
> It sounds like you are trying to get a list of handles to your specific
> devices, correct?

Yes, exactly.

> 
> One way to do this is to create a new protocol for your devices and
> create an instance of this protocol when your driver attaches to a PCI
> device. Then you can just retrieve all handles that match your new
> protocol.
> 
> Creating a new protocol for this use case could be as simple as just
> allocating a unique GUID, using uuidgen or something similar. You don't
> necessarily need to have data or functions associated with your protocol
> for this purpose, although that may prove useful.

This sounds like a simple method to accomplish what I need, thanks.  I
assume I would install the custom protocol in the same place I install
the Driver Binding and Component Name(2) implementations?

Regards,
David

> 
> I wouldn't consider myself an expert of any kind on UEFI drivers, so if
> others see problems with my suggestions or have better ideas, please
> chime in.
> 
> Regards,
> Jeff
> 
> On Tue, 21 Feb 2017, David A. Van Arnem wrote:
> 
>> Hello again,
>>
>> I think the problem lies in my application, as upon further
>> investigation, all the handles that publish the Component Name 2
>> protocol appear to be failing the EfiTestManagedDevice() check (they all
>> return EFI_UNSUPPORTED).  My eventual goal is, given a buffer of handles
>> that publish EFI_PCI_IO_PROTOCOL, I would like to locate my specific
>> device.  I was going to do a string comparison of the ControllerName,
>> but this doesn't seem to be the right approach.  Is there a recommended
>> way to accomplish this?
>>
>> Regards,
>> David
>>
>> On 02/21/2017 01:07 PM, David A. Van Arnem wrote:
>>> Hi all,
>>>
>>> I am developing a UEFI_DRIVER for a custom PCIe device.  I've followed
>>> the UEFI Driver Model, and implemented the Driver Binding, Component
>>> Name, and Component Name 2 protocols for my driver.  I'm trying to
>>> retrieve the Controller Name from this driver in a UEFI_APPLICATION, but
>>> I've run into an issue.
>>>
>>> In the driver's Start() function, I open the EFI_PCI_IO_PROTOCOL on
>>> ControllerHandle using the following:
>>>
>>> Status = gBS->OpenProtocol (
>>> ControllerHandle,
>>> ,
>>> (VOID **),
>>> This->DriverBindingHandle,
>>> ControllerHandle,
>>> EFI_OPEN_PROTOCOL_BY_DRIVER
>>> );
>>>
>>> And leave it open when Start() exits, unless some other part of the
>>> Start() function fails, which doesn't appear to be happening based on my
>>> debug messages.
>>>
>>> Following some of the examples in edk2, in my Component Name's
>>> GetControllerName() function, I used EfiTestManagedDevice() to check
>>> that the ControllerHandle opened EFI_PCI_IO_PROTOCOL:
>>>
>>> Status = EfiTestManagedDevice (
>>> ControllerHandle,
>>> gDriverBinding.DriverBindingHandle,
>>> 
>>> );
>>>
>>> Finally, to get the Controller Name in the application, I first get a
>>> buffer of handles that publish the ComponentName2 protocol, then walk
>>> through each and call GetControllerName().
>>>
>>> However, the EfiTestManagedDevice() check in my driver is returning
>>> EFI_UNSUPPORTED, indicating the protocol is not supported on the handle.
>>>  Furthermore, after using "load .efi" from the shell,
>>> openinfo on the handle returns:
>>>
>>> Handle 188 (6E16A798)
>>> ComponentName2
>>> ComponentName
>>> DriverBinding
>>>   Drv[01] Ctrl[ ] Cnt(200) HandProt  Image()
>>> ImageDevicePath
>>>   Drv[187] Ctrl[ ] Cnt(01) GetProt  Image()
>>> LoadedImage
>>>   Drv[01] Ctrl[ ] Cnt(09) HandProt  Image()
>>>
>>> I feel like maybe I'm missing a step here.  Should I see PciIo in
>>> openinfo?  Do I need to open a "child" instance of the ControllerHandle
>>> in my application to get EfiTestManagedDevice() to pass?  I'm not sure
>>> if that's the right terminology, I'm having a little difficulty
>>> understanding the "child" concept in this context.  Any tips
>>> appreciated.
>>>
>>
>> -- 
>> Regards,
>> David Van Arnem
>> Development Engineer IV
>> Computer Measurement Laboratory, LLC
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>

-- 
Regards,
David Van Arnem
Development Engineer IV
Computer Measurement Laboratory, LLC

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

Re: [edk2] Followup : EfiTestManagedDevice() issue in driver GetControllerName() function

[Jeff Westfahl]

Hello David,

It sounds like you are trying to get a list of handles to your specific 
devices, correct?


One way to do this is to create a new protocol for your devices and create 
an instance of this protocol when your driver attaches to a PCI device. 
Then you can just retrieve all handles that match your new protocol.


Creating a new protocol for this use case could be as simple as just 
allocating a unique GUID, using uuidgen or something similar. You don't 
necessarily need to have data or functions associated with your protocol 
for this purpose, although that may prove useful.


I wouldn't consider myself an expert of any kind on UEFI drivers, so if 
others see problems with my suggestions or have better ideas, please chime 
in.


Regards,
Jeff

On Tue, 21 Feb 2017, David A. Van Arnem wrote:


Hello again,

I think the problem lies in my application, as upon further
investigation, all the handles that publish the Component Name 2
protocol appear to be failing the EfiTestManagedDevice() check (they all
return EFI_UNSUPPORTED).  My eventual goal is, given a buffer of handles
that publish EFI_PCI_IO_PROTOCOL, I would like to locate my specific
device.  I was going to do a string comparison of the ControllerName,
but this doesn't seem to be the right approach.  Is there a recommended
way to accomplish this?

Regards,
David

On 02/21/2017 01:07 PM, David A. Van Arnem wrote:

Hi all,

I am developing a UEFI_DRIVER for a custom PCIe device.  I've followed
the UEFI Driver Model, and implemented the Driver Binding, Component
Name, and Component Name 2 protocols for my driver.  I'm trying to
retrieve the Controller Name from this driver in a UEFI_APPLICATION, but
I've run into an issue.

In the driver's Start() function, I open the EFI_PCI_IO_PROTOCOL on
ControllerHandle using the following:

Status = gBS->OpenProtocol (
ControllerHandle,
,
(VOID **),
This->DriverBindingHandle,
ControllerHandle,
EFI_OPEN_PROTOCOL_BY_DRIVER
);

And leave it open when Start() exits, unless some other part of the
Start() function fails, which doesn't appear to be happening based on my
debug messages.

Following some of the examples in edk2, in my Component Name's
GetControllerName() function, I used EfiTestManagedDevice() to check
that the ControllerHandle opened EFI_PCI_IO_PROTOCOL:

Status = EfiTestManagedDevice (
ControllerHandle,
gDriverBinding.DriverBindingHandle,

);

Finally, to get the Controller Name in the application, I first get a
buffer of handles that publish the ComponentName2 protocol, then walk
through each and call GetControllerName().

However, the EfiTestManagedDevice() check in my driver is returning
EFI_UNSUPPORTED, indicating the protocol is not supported on the handle.
 Furthermore, after using "load .efi" from the shell,
openinfo on the handle returns:

Handle 188 (6E16A798)
ComponentName2
ComponentName
DriverBinding
  Drv[01] Ctrl[ ] Cnt(200) HandProt  Image()
ImageDevicePath
  Drv[187] Ctrl[ ] Cnt(01) GetProt  Image()
LoadedImage
  Drv[01] Ctrl[ ] Cnt(09) HandProt  Image()

I feel like maybe I'm missing a step here.  Should I see PciIo in
openinfo?  Do I need to open a "child" instance of the ControllerHandle
in my application to get EfiTestManagedDevice() to pass?  I'm not sure
if that's the right terminology, I'm having a little difficulty
understanding the "child" concept in this context.  Any tips appreciated.



--
Regards,
David Van Arnem
Development Engineer IV
Computer Measurement Laboratory, LLC

___
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] UefiCpuPkg: PiSmmCpuDxeSmm (MpServioce.c)

[Duran, Leo]

Hi Feng, et al,

I'm wondering if the SetCacheability() function has been deprecated from the 
build tree?
That is, the function is part of MpService.c, but it does not seem to be used 
by any other code.

Would be it be OK to remove SetCacheability() from MpService.c?
I ask because I'm preparing a patch for code that touches page-table entries, 
and I'd prefer to simply ignore/remove SetCacheability(), if it's not needed 
anymore.

Thanks,
Leo


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

Re: [edk2] Followup : EfiTestManagedDevice() issue in driver GetControllerName() function

[David A. Van Arnem]

Hello again,

I think the problem lies in my application, as upon further
investigation, all the handles that publish the Component Name 2
protocol appear to be failing the EfiTestManagedDevice() check (they all
return EFI_UNSUPPORTED).  My eventual goal is, given a buffer of handles
that publish EFI_PCI_IO_PROTOCOL, I would like to locate my specific
device.  I was going to do a string comparison of the ControllerName,
but this doesn't seem to be the right approach.  Is there a recommended
way to accomplish this?

Regards,
David

On 02/21/2017 01:07 PM, David A. Van Arnem wrote:
> Hi all,
> 
> I am developing a UEFI_DRIVER for a custom PCIe device.  I've followed
> the UEFI Driver Model, and implemented the Driver Binding, Component
> Name, and Component Name 2 protocols for my driver.  I'm trying to
> retrieve the Controller Name from this driver in a UEFI_APPLICATION, but
> I've run into an issue.
> 
> In the driver's Start() function, I open the EFI_PCI_IO_PROTOCOL on
> ControllerHandle using the following:
> 
> Status = gBS->OpenProtocol (
> ControllerHandle,
> ,
> (VOID **),
> This->DriverBindingHandle,
> ControllerHandle,
> EFI_OPEN_PROTOCOL_BY_DRIVER
>   );
> 
> And leave it open when Start() exits, unless some other part of the
> Start() function fails, which doesn't appear to be happening based on my
> debug messages.
> 
> Following some of the examples in edk2, in my Component Name's
> GetControllerName() function, I used EfiTestManagedDevice() to check
> that the ControllerHandle opened EFI_PCI_IO_PROTOCOL:
> 
> Status = EfiTestManagedDevice (
> ControllerHandle,
> gDriverBinding.DriverBindingHandle,
> 
>   );
> 
> Finally, to get the Controller Name in the application, I first get a
> buffer of handles that publish the ComponentName2 protocol, then walk
> through each and call GetControllerName().
> 
> However, the EfiTestManagedDevice() check in my driver is returning
> EFI_UNSUPPORTED, indicating the protocol is not supported on the handle.
>  Furthermore, after using "load .efi" from the shell,
> openinfo on the handle returns:
> 
> Handle 188 (6E16A798)
> ComponentName2
> ComponentName
> DriverBinding
>   Drv[01] Ctrl[ ] Cnt(200) HandProt  Image()
> ImageDevicePath
>   Drv[187] Ctrl[ ] Cnt(01) GetProt  Image()
> LoadedImage
>   Drv[01] Ctrl[ ] Cnt(09) HandProt  Image()
> 
> I feel like maybe I'm missing a step here.  Should I see PciIo in
> openinfo?  Do I need to open a "child" instance of the ControllerHandle
> in my application to get EfiTestManagedDevice() to pass?  I'm not sure
> if that's the right terminology, I'm having a little difficulty
> understanding the "child" concept in this context.  Any tips appreciated.
> 

-- 
Regards,
David Van Arnem
Development Engineer IV
Computer Measurement Laboratory, LLC

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

[edk2] EfiTestManagedDevice() issue in driver GetControllerName() function

[David A. Van Arnem]

Hi all,

I am developing a UEFI_DRIVER for a custom PCIe device.  I've followed
the UEFI Driver Model, and implemented the Driver Binding, Component
Name, and Component Name 2 protocols for my driver.  I'm trying to
retrieve the Controller Name from this driver in a UEFI_APPLICATION, but
I've run into an issue.

In the driver's Start() function, I open the EFI_PCI_IO_PROTOCOL on
ControllerHandle using the following:

Status = gBS->OpenProtocol (
ControllerHandle,
,
(VOID **),
This->DriverBindingHandle,
ControllerHandle,
EFI_OPEN_PROTOCOL_BY_DRIVER
);

And leave it open when Start() exits, unless some other part of the
Start() function fails, which doesn't appear to be happening based on my
debug messages.

Following some of the examples in edk2, in my Component Name's
GetControllerName() function, I used EfiTestManagedDevice() to check
that the ControllerHandle opened EFI_PCI_IO_PROTOCOL:

Status = EfiTestManagedDevice (
ControllerHandle,
gDriverBinding.DriverBindingHandle,

);

Finally, to get the Controller Name in the application, I first get a
buffer of handles that publish the ComponentName2 protocol, then walk
through each and call GetControllerName().

However, the EfiTestManagedDevice() check in my driver is returning
EFI_UNSUPPORTED, indicating the protocol is not supported on the handle.
 Furthermore, after using "load .efi" from the shell,
openinfo on the handle returns:

Handle 188 (6E16A798)
ComponentName2
ComponentName
DriverBinding
  Drv[01] Ctrl[ ] Cnt(200) HandProt  Image()
ImageDevicePath
  Drv[187] Ctrl[ ] Cnt(01) GetProt  Image()
LoadedImage
  Drv[01] Ctrl[ ] Cnt(09) HandProt  Image()

I feel like maybe I'm missing a step here.  Should I see PciIo in
openinfo?  Do I need to open a "child" instance of the ControllerHandle
in my application to get EfiTestManagedDevice() to pass?  I'm not sure
if that's the right terminology, I'm having a little difficulty
understanding the "child" concept in this context.  Any tips appreciated.

-- 
Regards,
David Van Arnem
Development Engineer IV
Computer Measurement Laboratory, LLC

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

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Rebecca Cran]

On 2/21/2017 12:02 PM, Laszlo Ersek wrote:


But in this case, the full edk2 codebase has to be grepped for
VA_LIST-taking functions, and all of them must be flipped to EFIAPI, if
they currently aren't EFIAPI. Covering just XenStoreVSPrint() seems
incomplete. (Note: CryptoPkg/Library/OpensslLib is an exception.)


I think this was discussed previously but I can't remember: is there a 
reason for not just compiling everything with -mabi=ms ?


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

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Laszlo Ersek]

On 02/21/17 18:53, Anthony PERARD wrote:
> On Tue, Feb 21, 2017 at 06:07:15PM +0100, Laszlo Ersek wrote:
>> CC Rebecca & Konrad
>>
>> On 02/21/17 17:39, Anthony PERARD wrote:

[snip]

>>> So, should I add EFIAPI to XenStoreVSPrint, as it is using VA_COPY?
>>>
>>
>> Hm, please help me jog my memory...
>>
>> If I remember correctly, this is still a GCC bug, one that we suppressed for 
>> gcc-6.2 with your patch as follows:
> 
> Yes.
> 
>>> commit 432f1d83f77acf92d52ef18d2cee6dbf7c5b9b86
>>> Author: Anthony PERARD 
>>> Date:   Tue Dec 6 12:03:25 2016 +
>>>
>>> OvmfPkg/build.sh: Use GCC49 toolchains with GCC 6.[0-2]
>>>
>>> The goal of the patch is to avoid using -flto with GCC 6.0 to 6.2.
>>>
>>> This is to workaround a GCC bug:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Anthony PERARD 
>>> Reviewed-by: Laszlo Ersek 
>>> Regression-tested-by: Laszlo Ersek 
>>>
>>> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
>>> index 95fe8fb07647..b6e936056ca0 100755
>>> --- a/OvmfPkg/build.sh
>>> +++ b/OvmfPkg/build.sh
>>> @@ -102,7 +102,7 @@ case `uname` in
>>>4.8.*)
>>>  TARGET_TOOLS=GCC48
>>>  ;;
>>> -  4.9.*)
>>> +  4.9.*|6.[0-2].*)
>>>  TARGET_TOOLS=GCC49
>>>  ;;
>>>*)
>>
>> Do I understand correctly that the gcc bug has not been fixed in
>> gcc-6.3, and -- because we don't suppress it for gcc-6.3 as the
>> above expression does not match -- it causes problems again?
> 
> The bug describe in the GCC bugzilla is probably fix, but the
> test-case does not make use of __builtin_ms_va_copy.

:/

> 
>> You also mention gcc-5.4 as problematic. I think we haven't
>> received such reports about gcc-5 versions up to and including
>> gcc-5.3 (that's why GCC5 is the default selection in
>> "OvmfPkg/build.sh"). Do you mean that the gcc bug has now been
>> "backported" from the gcc-6 series to the gcc-5 series (starting
>> with gcc-5.4)?

> 
> I don't know the state of gcc-5.0 to gcc-5.3, I have never tested -flto
> with gcc-5.x (until now), I would say they are also problematic until
> proven otherwise.

When we enabled GCC5, it definitely worked for at least one gcc release,
with -flto. (-flto is the default for DEBUG and RELEASE builds with
GCC5; NOOPT disables -Os and -flto.)

> 
>> If that's the case, then I suggest flipping "OvmfPkg/build.sh" from
>> black-listing gcc versions for -flto to white-listing. In other
>> words, assume that -flto is generally broken with GCC, except for a
>> few known versions: 5.0 through 5.3 inclusive. Those versions
>> should trigger the use of the GCC5 toolchain, and everything else
>> (5.4+, 6.*, 4.9.*) should use GCC49.
>>
>> I don't feel comfortable about adding EFIAPI to XenStoreVSPrint
>> just because it takes a VA_LIST parameter -- note: it is *not* a
>> varargs function itself! --; the same issue might hit elsewhere in
>> the edk2 tree at any time, outside of OvmfPkg too.
> 
> From the different tests I've done, I feel more like VA_COPY might be
> the issue, but I don't know how __builtin_ms_va_* are supposed to be
> used.

If I recall correctly, from the upstream GCC bug, the problem is that
__builtin_va_list does not track internally whether it was created in an
msabi or sysvabi function, and therefore the va_* functions cannot be
used transparently on it. Instead, when va_list is accessed, the
accessor builtins seem to apply the currently executing function's
calling convetion to va_list. (Even if the creation context of va_list
was different.)

> 
>> Would the gcc white-listing work for you?
>>
>> Note that the white-listing would practically undo Konrad's commit
>> 2667ad40919a ("OvmfPkg/build.sh: Make GCC5 the default toolchain,
>> catch GCC43 and earlier", 2016-11-23), but given the recent gcc
>> developments (gcc-6.3 has not fixed the gcc bug, and the bug has
>> even surfaced in gcc-5.4), I think it would be justified.
> 
> Do be honnest, I don't think the toolchain GCC5 has ever been tested
> with gcc-5.x and the module XenBusDxe. I think most people that want to
> start OVMF under Xen are likely to build it with gcc-4.9 or already had
> gcc-6.x when OVMF switch to the GCC5 toolchain by default.
> 

Okay... I'm equally fine if we just say "given that GCC is broken like
this, we hereby require all functions that take a variable argument
list, *or* a VA_LIST parameter, to be EFIAPI". (The first part of the
requirement already exists.)

But in this case, the full edk2 codebase has to be grepped for
VA_LIST-taking functions, and all of them must be flipped to EFIAPI, if
they currently aren't EFIAPI. Covering just XenStoreVSPrint() seems
incomplete. (Note: CryptoPkg/Library/OpensslLib is an exception.)

Also, in this case, your commit 432f1d83f77a should likely be reverted.
(Because we are ultimately 

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Anthony PERARD]

On Tue, Feb 21, 2017 at 06:07:15PM +0100, Laszlo Ersek wrote:
> CC Rebecca & Konrad
> 
> On 02/21/17 17:39, Anthony PERARD wrote:
> > On Sat, Dec 03, 2016 at 06:59:28PM +0100, Laszlo Ersek wrote:
> >> On 12/02/16 20:26, Laszlo Ersek wrote:
> >>> On 12/02/16 17:02, Anthony PERARD wrote:
>  On Thu, Dec 01, 2016 at 07:43:24PM +0100, Laszlo Ersek wrote:
> > On 12/01/16 16:28, Anthony PERARD wrote:
> >> Hi,
> >>
> >> That might be only with the Xen part of OVMF but now that the GCC5
> >> toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
> >> to boot in Xen guests.
> >>
>  [...]
> >>
> >> Removing the gcc option -flto in only the XenBusDxe module makes OVMF
> >> boot.
> >>
> >> While trying to debug that, I've added some debug prints (in this 
> >> module
> >> and in XenPvBlkDxe), and the exception could change and become a "page
> >> fault" instead, or even an assert failure in the PrintLib, that was the
> >> ASSERT(Buffer != NULL) at I think
> >> MdePkg/Library/BasePrintLib/PrintLibInternal.c:366
> >>
> >> Adding EFIAPI to internal functions in XenBusDxe makes things work
> >> again.  My guest is that gcc would bypass (optimise) an exported
> >> functions and call directly an internal one but without reordering the
> >> arguments (EFIAPI vs nothing).
> >>
> >> Does that make sense?
> >
> > If "-b NOOPT" works for you, I'd prefer that as a temporary solution
> > (until the root cause is found and addressed) to the XenBusDxe patches.
> 
>  That works, using GCC49 (with gcc 6.2.1) works as well.
> 
> > Hrpmf, wait a second, I do see something interesting: in this series you
> > *are* modifying APIs declared in a library class header (namely
> > "OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public
> > libraries) *are* required to specify EFIAPI.
> >
> > What happens if you apply patch #1 only?
> 
>  With only XenHypercallLib changes, the error is the same.
> 
>  But I did find the minimum change needed, it envolve a function with a
>  VA_LIST as argument.
> 
>  With only the following patch, OVMF works again.
> 
>  diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
>  index 1666c4b..85b0956 100644
>  --- a/OvmfPkg/XenBusDxe/XenStore.c
>  +++ b/OvmfPkg/XenBusDxe/XenStore.c
>  @@ -1307,6 +1307,7 @@ XenStoreTransactionEnd (
>   }
>   
>   XENSTORE_STATUS
>  +EFIAPI
>   XenStoreVSPrint (
> IN CONST XENSTORE_TRANSACTION *Transaction,
> IN CONST CHAR8   *DirectoryPath,
>  diff --git a/OvmfPkg/XenBusDxe/XenStore.h b/OvmfPkg/XenBusDxe/XenStore.h
>  index c9d4c65..33bb647 100644
>  --- a/OvmfPkg/XenBusDxe/XenStore.h
>  +++ b/OvmfPkg/XenBusDxe/XenStore.h
>  @@ -209,6 +209,7 @@ XenStoreSPrint (
>  indicating the type of write failure.
>   **/
>   XENSTORE_STATUS
>  +EFIAPI
>   XenStoreVSPrint (
> IN CONST XENSTORE_TRANSACTION *Transaction,
> IN CONST CHAR8   *DirectoryPath,
> IN CONST CHAR8   *Node,
> IN CONST CHAR8   *FormatString,
> IN VA_LIST   Marker
> );
> 
> 
>  I think the exception happen when this function is called via
>  XENBUS_PROTOCOL->XsPrintf() from XenPvBlockFrontInitialization() in
>  OvmfPkg/XenPvBlkDxe/BlockFront.c
> 
> >>>
> >>> It used to be a known requirement / limitation that all functions with
> >>> variable argument lists had to be EFIAPI, regardless of cross-module
> >>> use. However, commit 48d5f9a551a93acb45f272dda879b0ab5a504e36 changed
> >>> that, and varargs should "just work" now. I suspect this is a
> >>> __builtin_ms_va_* regression in gcc-6. Thank you for narrowing it down.
> >>> It might make sense to report a bug in the upstream gcc tracker.
> >>>
> >>> ... Oh wow, this is a known gcc bug! See:
> >>>
> >>> https://lists.01.org/pipermail/edk2-devel/2016-August/001018.html
> >>>
> >>> Upstream gcc BZ  was
> >>> apparently solved for "Target Milestone: 6.3" (your version is 6.2.1).
> >>> So we'll either need a GCC6 toolchain in BaseTools that drops -flto, in
> >>> order to work around this gcc issue, or we'll have to ask gcc-6 users to
> >>> use at least gcc-6.3.
> >>>
> >>> Oh wait, gcc-6.3 hasn't been released yet. We need the BaseTools
> >>> workaround then.
> >>
> >> I think I got confused in parts of the above; I got some details wrong.
> >> Namely, commit 48d5f9a551a9 did not remove the requirement/limitation
> >> that all varargs functions have to be EFIAPI. Said commit only changed
> >> how the VA_*() macros would be implemented.
> >>
> >> The two caller functions of XenStoreVSPrint(), namely XenStoreSPrint()
> >> and XenBusXenStoreSPrint(), are varargs functions, but they 

Re: [edk2] [PATCH V4 0/3] DXE Memory Protection

[Ard Biesheuvel]

On 21 February 2017 at 08:39, Yao, Jiewen  wrote:
> No problem. J
>

Pushed now. Thanks for you patience.



>
>
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, February 21, 2017 4:36 PM
> To: Yao, Jiewen ; Leif Lindholm
> 
> Cc: edk2-devel@lists.01.org; Fan, Jeff ; Kinney, Michael
> D ; Zeng, Star ; Tian, Feng
> 
> Subject: Re: [PATCH V4 0/3] DXE Memory Protection
>
>
>
> On 21 February 2017 at 06:57, Jiewen Yao  wrote:
>>  V4 
>> 1) Remove ARM patch. (Which was already submitted by Ard Biesheuvel in
>> another series)
>> 2) Unprotect RT image at ExitBootServices (feedback from Ard Biesheuvel)
>> 3) Round up the ImageSize on protection (feedback from Ard Biesheuvel)
>>
>
> Hello Jiewen,
>
> This works fine now on AARCH64.
>
> Tested-by: Ard Biesheuvel 
>
> Could you please wait a little bit before merging this? Leif and I
> need to get the AARCH64 prepatory patches merged first, but I am
> hoping to do that today.
>
> Thanks,
> Ard.
>
>>  V3 
>> 1) Add PCD for policy control (feedback from Ard Biesheuvel)
>> (Discussed with Mike Kinney)
>> +  #BIT0   - Image from unknown device. 
>> +  #BIT1   - Image from firmware volume.
>> +  # @Prompt Set image protection policy.
>> +  # @ValidRange 0x8002 | 0x - 0x001F
>> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy|0x0002|UINT32|0x1047
>>
>> 2) Remove unused function in CpuDxe.(feedback from Liming Gao)
>> 3) Add commit log on link option assumption (feedback from Feng Tian)
>> 4) Rename file PageTableLib.h/.c to CpuPageTable.h/.c file (from Jeff Fan)
>> 5) Remove multi-entrypoint usage (from Liming Gao/Mike Kinney)
>>
>>  V2 
>> 1) Clean up ArmPkg, (feedback from Leif Lindholm)
>>
>>  V1 
>> This series patch provides capability to protect PE/COFF image
>> in DXE memory.
>> If the UEFI image is page aligned, the image code section is set to read
>> only and the image data section is set to non-executable.
>>
>> The DxeCore calls CpuArchProtocol->SetMemoryAttributes() to protect
>> the image.
>>
>> Tested platform: NT32/Quark IA32/OVMF IA32/OVMF IA32X64/Intel internal
>> X64/
>> Tested OS: UEFI Win10, UEFI Ubuntu 16.04.
>>
>> Untested platform: ARM/AARCH64.
>> Can ARM/AARCH64 owner help to take a look and try the ARM platform?
>>
>>
>> Cc: Jeff Fan 
>> Cc: Michael Kinney 
>> Cc: Leif Lindholm 
>> Cc: Ard Biesheuvel 
>> Cc: Star Zeng 
>> Cc: Feng Tian 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Jiewen Yao 
>>
>>
>> Jiewen Yao (3):
>>   UefiCpuPkg/CpuDxe: Add memory attribute setting.
>>   MdeModulePkg/dec: add PcdImageProtectionPolicy.
>>   MdeModulePkg/DxeCore: Add UEFI image protection.
>>
>>  MdeModulePkg/Core/Dxe/DxeMain.h   |  61 ++
>>  MdeModulePkg/Core/Dxe/DxeMain.inf |   5 +-
>>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c   |   5 +-
>>  MdeModulePkg/Core/Dxe/Image/Image.c   |   7 +-
>>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 769 +++
>>  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c  |  24 +-
>>  MdeModulePkg/MdeModulePkg.dec |  10 +
>>  UefiCpuPkg/CpuDxe/CpuDxe.c| 141 ++--
>>  UefiCpuPkg/CpuDxe/CpuDxe.inf  |   5 +-
>>  UefiCpuPkg/CpuDxe/CpuPageTable.c  | 779 
>>  UefiCpuPkg/CpuDxe/CpuPageTable.h  | 113 +++
>>  11 files changed, 1832 insertions(+), 87 deletions(-)
>>  create mode 100644 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
>>  create mode 100644 UefiCpuPkg/CpuDxe/CpuPageTable.c
>>  create mode 100644 UefiCpuPkg/CpuDxe/CpuPageTable.h
>>
>> --
>> 2.7.4.windows.1
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Laszlo Ersek]

CC Rebecca & Konrad

On 02/21/17 17:39, Anthony PERARD wrote:
> On Sat, Dec 03, 2016 at 06:59:28PM +0100, Laszlo Ersek wrote:
>> On 12/02/16 20:26, Laszlo Ersek wrote:
>>> On 12/02/16 17:02, Anthony PERARD wrote:
 On Thu, Dec 01, 2016 at 07:43:24PM +0100, Laszlo Ersek wrote:
> On 12/01/16 16:28, Anthony PERARD wrote:
>> Hi,
>>
>> That might be only with the Xen part of OVMF but now that the GCC5
>> toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
>> to boot in Xen guests.
>>
 [...]
>>
>> Removing the gcc option -flto in only the XenBusDxe module makes OVMF
>> boot.
>>
>> While trying to debug that, I've added some debug prints (in this module
>> and in XenPvBlkDxe), and the exception could change and become a "page
>> fault" instead, or even an assert failure in the PrintLib, that was the
>> ASSERT(Buffer != NULL) at I think
>> MdePkg/Library/BasePrintLib/PrintLibInternal.c:366
>>
>> Adding EFIAPI to internal functions in XenBusDxe makes things work
>> again.  My guest is that gcc would bypass (optimise) an exported
>> functions and call directly an internal one but without reordering the
>> arguments (EFIAPI vs nothing).
>>
>> Does that make sense?
>
> If "-b NOOPT" works for you, I'd prefer that as a temporary solution
> (until the root cause is found and addressed) to the XenBusDxe patches.

 That works, using GCC49 (with gcc 6.2.1) works as well.

> Hrpmf, wait a second, I do see something interesting: in this series you
> *are* modifying APIs declared in a library class header (namely
> "OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public
> libraries) *are* required to specify EFIAPI.
>
> What happens if you apply patch #1 only?

 With only XenHypercallLib changes, the error is the same.

 But I did find the minimum change needed, it envolve a function with a
 VA_LIST as argument.

 With only the following patch, OVMF works again.

 diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
 index 1666c4b..85b0956 100644
 --- a/OvmfPkg/XenBusDxe/XenStore.c
 +++ b/OvmfPkg/XenBusDxe/XenStore.c
 @@ -1307,6 +1307,7 @@ XenStoreTransactionEnd (
  }
  
  XENSTORE_STATUS
 +EFIAPI
  XenStoreVSPrint (
IN CONST XENSTORE_TRANSACTION *Transaction,
IN CONST CHAR8   *DirectoryPath,
 diff --git a/OvmfPkg/XenBusDxe/XenStore.h b/OvmfPkg/XenBusDxe/XenStore.h
 index c9d4c65..33bb647 100644
 --- a/OvmfPkg/XenBusDxe/XenStore.h
 +++ b/OvmfPkg/XenBusDxe/XenStore.h
 @@ -209,6 +209,7 @@ XenStoreSPrint (
 indicating the type of write failure.
  **/
  XENSTORE_STATUS
 +EFIAPI
  XenStoreVSPrint (
IN CONST XENSTORE_TRANSACTION *Transaction,
IN CONST CHAR8   *DirectoryPath,
IN CONST CHAR8   *Node,
IN CONST CHAR8   *FormatString,
IN VA_LIST   Marker
);


 I think the exception happen when this function is called via
 XENBUS_PROTOCOL->XsPrintf() from XenPvBlockFrontInitialization() in
 OvmfPkg/XenPvBlkDxe/BlockFront.c

>>>
>>> It used to be a known requirement / limitation that all functions with
>>> variable argument lists had to be EFIAPI, regardless of cross-module
>>> use. However, commit 48d5f9a551a93acb45f272dda879b0ab5a504e36 changed
>>> that, and varargs should "just work" now. I suspect this is a
>>> __builtin_ms_va_* regression in gcc-6. Thank you for narrowing it down.
>>> It might make sense to report a bug in the upstream gcc tracker.
>>>
>>> ... Oh wow, this is a known gcc bug! See:
>>>
>>> https://lists.01.org/pipermail/edk2-devel/2016-August/001018.html
>>>
>>> Upstream gcc BZ  was
>>> apparently solved for "Target Milestone: 6.3" (your version is 6.2.1).
>>> So we'll either need a GCC6 toolchain in BaseTools that drops -flto, in
>>> order to work around this gcc issue, or we'll have to ask gcc-6 users to
>>> use at least gcc-6.3.
>>>
>>> Oh wait, gcc-6.3 hasn't been released yet. We need the BaseTools
>>> workaround then.
>>
>> I think I got confused in parts of the above; I got some details wrong.
>> Namely, commit 48d5f9a551a9 did not remove the requirement/limitation
>> that all varargs functions have to be EFIAPI. Said commit only changed
>> how the VA_*() macros would be implemented.
>>
>> The two caller functions of XenStoreVSPrint(), namely XenStoreSPrint()
>> and XenBusXenStoreSPrint(), are varargs functions, but they are already
>> EFIAPI. So the requirement/limitation (which was unaffected by
>> 48d5f9a551a9) is actually satisfied / considered in XenBusDxe.
>>
>> The XenStoreVSPrint() function, which you identified as the breaking
>> part, is *not* a varargs function itself, so it needn't be EFIAPI. It
>> 

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Anthony PERARD]

On Sat, Dec 03, 2016 at 06:59:28PM +0100, Laszlo Ersek wrote:
> On 12/02/16 20:26, Laszlo Ersek wrote:
> > On 12/02/16 17:02, Anthony PERARD wrote:
> >> On Thu, Dec 01, 2016 at 07:43:24PM +0100, Laszlo Ersek wrote:
> >>> On 12/01/16 16:28, Anthony PERARD wrote:
>  Hi,
> 
>  That might be only with the Xen part of OVMF but now that the GCC5
>  toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
>  to boot in Xen guests.
> 
> >> [...]
> 
>  Removing the gcc option -flto in only the XenBusDxe module makes OVMF
>  boot.
> 
>  While trying to debug that, I've added some debug prints (in this module
>  and in XenPvBlkDxe), and the exception could change and become a "page
>  fault" instead, or even an assert failure in the PrintLib, that was the
>  ASSERT(Buffer != NULL) at I think
>  MdePkg/Library/BasePrintLib/PrintLibInternal.c:366
> 
>  Adding EFIAPI to internal functions in XenBusDxe makes things work
>  again.  My guest is that gcc would bypass (optimise) an exported
>  functions and call directly an internal one but without reordering the
>  arguments (EFIAPI vs nothing).
> 
>  Does that make sense?
> >>>
> >>> If "-b NOOPT" works for you, I'd prefer that as a temporary solution
> >>> (until the root cause is found and addressed) to the XenBusDxe patches.
> >>
> >> That works, using GCC49 (with gcc 6.2.1) works as well.
> >>
> >>> Hrpmf, wait a second, I do see something interesting: in this series you
> >>> *are* modifying APIs declared in a library class header (namely
> >>> "OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public
> >>> libraries) *are* required to specify EFIAPI.
> >>>
> >>> What happens if you apply patch #1 only?
> >>
> >> With only XenHypercallLib changes, the error is the same.
> >>
> >> But I did find the minimum change needed, it envolve a function with a
> >> VA_LIST as argument.
> >>
> >> With only the following patch, OVMF works again.
> >>
> >> diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
> >> index 1666c4b..85b0956 100644
> >> --- a/OvmfPkg/XenBusDxe/XenStore.c
> >> +++ b/OvmfPkg/XenBusDxe/XenStore.c
> >> @@ -1307,6 +1307,7 @@ XenStoreTransactionEnd (
> >>  }
> >>  
> >>  XENSTORE_STATUS
> >> +EFIAPI
> >>  XenStoreVSPrint (
> >>IN CONST XENSTORE_TRANSACTION *Transaction,
> >>IN CONST CHAR8   *DirectoryPath,
> >> diff --git a/OvmfPkg/XenBusDxe/XenStore.h b/OvmfPkg/XenBusDxe/XenStore.h
> >> index c9d4c65..33bb647 100644
> >> --- a/OvmfPkg/XenBusDxe/XenStore.h
> >> +++ b/OvmfPkg/XenBusDxe/XenStore.h
> >> @@ -209,6 +209,7 @@ XenStoreSPrint (
> >> indicating the type of write failure.
> >>  **/
> >>  XENSTORE_STATUS
> >> +EFIAPI
> >>  XenStoreVSPrint (
> >>IN CONST XENSTORE_TRANSACTION *Transaction,
> >>IN CONST CHAR8   *DirectoryPath,
> >>IN CONST CHAR8   *Node,
> >>IN CONST CHAR8   *FormatString,
> >>IN VA_LIST   Marker
> >>);
> >>
> >>
> >> I think the exception happen when this function is called via
> >> XENBUS_PROTOCOL->XsPrintf() from XenPvBlockFrontInitialization() in
> >> OvmfPkg/XenPvBlkDxe/BlockFront.c
> >>
> > 
> > It used to be a known requirement / limitation that all functions with
> > variable argument lists had to be EFIAPI, regardless of cross-module
> > use. However, commit 48d5f9a551a93acb45f272dda879b0ab5a504e36 changed
> > that, and varargs should "just work" now. I suspect this is a
> > __builtin_ms_va_* regression in gcc-6. Thank you for narrowing it down.
> > It might make sense to report a bug in the upstream gcc tracker.
> > 
> > ... Oh wow, this is a known gcc bug! See:
> > 
> > https://lists.01.org/pipermail/edk2-devel/2016-August/001018.html
> > 
> > Upstream gcc BZ  was
> > apparently solved for "Target Milestone: 6.3" (your version is 6.2.1).
> > So we'll either need a GCC6 toolchain in BaseTools that drops -flto, in
> > order to work around this gcc issue, or we'll have to ask gcc-6 users to
> > use at least gcc-6.3.
> > 
> > Oh wait, gcc-6.3 hasn't been released yet. We need the BaseTools
> > workaround then.
> 
> I think I got confused in parts of the above; I got some details wrong.
> Namely, commit 48d5f9a551a9 did not remove the requirement/limitation
> that all varargs functions have to be EFIAPI. Said commit only changed
> how the VA_*() macros would be implemented.
> 
> The two caller functions of XenStoreVSPrint(), namely XenStoreSPrint()
> and XenBusXenStoreSPrint(), are varargs functions, but they are already
> EFIAPI. So the requirement/limitation (which was unaffected by
> 48d5f9a551a9) is actually satisfied / considered in XenBusDxe.
> 
> The XenStoreVSPrint() function, which you identified as the breaking
> part, is *not* a varargs function itself, so it needn't be EFIAPI. It
> simply receives a VA_LIST parameter (which is "__builtin_ms_va_list",
> 

Re: [edk2] [PATCH v3 2/4] MdeModulePkg/Universal/CapsulePei: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

[Duran, Leo]

Hi Star, 

Please double-check the complete [PATCH v3 2/4].

Yes, there is a non-functional change where I did break a 'very long' line into 
2 lines as you noted (I can put that back as it was before if so required).
However the intended functional changes are applied in the rest of the patch in 
lines where I reference 'AddressSetMask'.

As for [PATCH v3 4/4]
The intended functional changes are applied... please confirm, or please let me 
know what seems to be missing.

Thanks,
Leo.

> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Monday, February 20, 2017 12:05 AM
> To: Duran, Leo ; edk2-de...@ml01.01.org
> Cc: Laszlo Ersek ; Feng Tian ;
> Singh, Brijesh ; star.z...@intel.com
> Subject: Re: [edk2] [PATCH v3 2/4] MdeModulePkg/Universal/CapsulePei:
> Add support for PCD PcdPteMemoryEncryptionAddressOrMask
> 
> Leo,
> 
> Comments added inline.
> 
> On 2017/2/17 5:02, Leo Duran wrote:
> > This PCD holds the address mask for page table entries when memory
> > encryption is enabled on AMD processors supporting the Secure
> > Encrypted Virtualization (SEV) feature.
> >
> > The mask is applied when 4GB tables are created (UefiCapsule.c), and
> > when the tables are expanded on-demand by page-faults above 4GB's
> (X64Entry.c).
> >
> > Cc: Feng Tian 
> > Cc: Star Zeng 
> > Cc: Laszlo Ersek 
> > Cc: Brijesh Singh 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Leo Duran 
> > Reviewed-by: Star Zeng 
> > ---
> >  MdeModulePkg/Universal/CapsulePei/CapsulePei.inf   |  2 ++
> >  .../Universal/CapsulePei/Common/CommonHeader.h |  7 +++
> >  MdeModulePkg/Universal/CapsulePei/UefiCapsule.c| 13 
> >  MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c   | 23
> +++---
> >  4 files changed, 34 insertions(+), 11 deletions(-)
> >
> 
> [snipped]
> 
> > diff --git a/MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c
> > b/MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c
> > index 5ad95d2..2197502 100644
> > --- a/MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c
> > +++ b/MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c
> > @@ -2,6 +2,8 @@
> >The X64 entrypoint is used to process capsule in long mode.
> >
> >  Copyright (c) 2011 - 2016, Intel Corporation. All rights
> > reserved.
> > +Copyright (c) 2017, AMD Incorporated. 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 @@ -29,6 +31,7 @@ typedef struct _PAGE_FAULT_CONTEXT {
> >UINT64PhyMask;
> >UINTN PageFaultBuffer;
> >UINTN PageFaultIndex;
> > +  UINT64PteMemoryEncryptionAddressOrMask;
> >//
> >// Store the uplink information for each page being used.
> >//
> > @@ -114,6 +117,7 @@ AcquirePage (
> >)
> >  {
> >UINTN Address;
> > +  UINT64AddressSetMask;
> >
> >Address = PageFaultContext->PageFaultBuffer + EFI_PAGES_TO_SIZE
> (PageFaultContext->PageFaultIndex);
> >ZeroMem ((VOID *) Address, EFI_PAGES_TO_SIZE (1)); @@ -121,14
> > +125,16 @@ AcquirePage (
> >//
> >// Cut the previous uplink if it exists and wasn't overwritten.
> >//
> > -  if
> > ((PageFaultContext->PageFaultUplink[PageFaultContext->PageFaultIndex]
> > != NULL) &&
> > ((*PageFaultContext->PageFaultUplink[PageFaultContext-
> >PageFaultIndex]
> > & PageFaultContext->PhyMask) == Address)) {
> > +  if ((PageFaultContext->PageFaultUplink[PageFaultContext-
> >PageFaultIndex] != NULL) &&
> > +
> > + ((*PageFaultContext->PageFaultUplink[PageFaultContext-
> >PageFaultInde
> > + x] & PageFaultContext->PhyMask) == Address)) {
> 
> No real change at here except the line feed added.
> You were going to update code at here, but forgot to do the real change?
> 
> Will you do similar change for [PATCH v3 4/4]
> 
> Thanks,
> Star
> 
> >  *PageFaultContext->PageFaultUplink[PageFaultContext-
> >PageFaultIndex] = 0;
> >}
> >
> >//
> >// Link & Record the current uplink.
> >//
> > -  *Uplink = Address | IA32_PG_P | IA32_PG_RW;
> > +  AddressSetMask =
> > + PageFaultContext->PteMemoryEncryptionAddressOrMask;
> > +  *Uplink = Address | (AddressSetMask &
> PAGING_4K_ADDRESS_MASK_64) |
> > + IA32_PG_P | IA32_PG_RW;
> >PageFaultContext->PageFaultUplink[PageFaultContext->PageFaultIndex]
> > = Uplink;
> >
> >PageFaultContext->PageFaultIndex =
> > (PageFaultContext->PageFaultIndex + 1) % EXTRA_PAGE_TABLE_PAGES;
> @@ -153,6 +159,7 @@ PageFaultHandler (
> >UINT64*PageTable;
> >UINT64

[edk2] [PATCH 6/6] OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_DMA_ADDRESS, adapt the package

[Laszlo Ersek]

Introduce the FW_CFG_IO_DMA_ADDRESS macro for IO Ports 0x514 and 0x518
(most significant and least significant halves of the DMA Address
Register, respectively), and update all references in OvmfPkg.

Cc: Jordan Justen 
Suggested-by: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Include/IndustryStandard/QemuFwCfg.h | 1 +
 OvmfPkg/AcpiPlatformDxe/BootScript.c | 4 ++--
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c  | 4 ++--
 OvmfPkg/SmmControl2Dxe/SmiFeatures.c | 2 +-
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h 
b/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
index 5da6b456febe..8c32f83e8e16 100644
--- a/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
+++ b/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
@@ -48,6 +48,7 @@
 //
 #define FW_CFG_IO_SELECTOR0x510
 #define FW_CFG_IO_DATA0x511
+#define FW_CFG_IO_DMA_ADDRESS 0x514
 
 //
 // Numerically defined keys.
diff --git a/OvmfPkg/AcpiPlatformDxe/BootScript.c 
b/OvmfPkg/AcpiPlatformDxe/BootScript.c
index 1ad468e2f834..bff42ad8b9b0 100644
--- a/OvmfPkg/AcpiPlatformDxe/BootScript.c
+++ b/OvmfPkg/AcpiPlatformDxe/BootScript.c
@@ -317,7 +317,7 @@ TransferS3ContextToBootScript (
 S3SaveState, // This
 EFI_BOOT_SCRIPT_IO_WRITE_OPCODE, // OpCode
 EfiBootScriptWidthUint32,// Width
-(UINT64)0x514,   // Address
+(UINT64)FW_CFG_IO_DMA_ADDRESS,   // Address
 (UINTN)2,// Count
 // Buffer
 );
@@ -376,7 +376,7 @@ TransferS3ContextToBootScript (
 S3SaveState, // This
 EFI_BOOT_SCRIPT_IO_WRITE_OPCODE, // OpCode
 EfiBootScriptWidthUint32,// Width
-(UINT64)0x514,   // Address
+(UINT64)FW_CFG_IO_DMA_ADDRESS,   // Address
 (UINTN)2,// Count
 // Buffer
 );
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index d79d0a444ca7..3dd55ba5042e 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -94,8 +94,8 @@ InternalQemuFwCfgDmaBytes (
   //
   AccessHigh = (UINT32)RShiftU64 ((UINTN), 32);
   AccessLow  = (UINT32)(UINTN)
-  IoWrite32 (0x514, SwapBytes32 (AccessHigh));
-  IoWrite32 (0x518, SwapBytes32 (AccessLow));
+  IoWrite32 (FW_CFG_IO_DMA_ADDRESS, SwapBytes32 (AccessHigh));
+  IoWrite32 (FW_CFG_IO_DMA_ADDRESS + 4, SwapBytes32 (AccessLow));
 
   //
   // Don't look at Access.Control before starting the transfer.
diff --git a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c 
b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
index 73c29848b334..bd257f15d955 100644
--- a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
+++ b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
@@ -240,7 +240,7 @@ SaveSmiFeatures (
   S3SaveState, // This
   EFI_BOOT_SCRIPT_IO_WRITE_OPCODE, // OpCode
   EfiBootScriptWidthUint32,// Width
-  (UINT64)0x514,   // Address
+  (UINT64)FW_CFG_IO_DMA_ADDRESS,   // Address
   (UINTN)2,// Count
  // Buffer
   );
-- 
2.9.3

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

[edk2] [PATCH 5/6] OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_DATA, adapt the package

[Laszlo Ersek]

Introduce the FW_CFG_IO_DATA macro for IO Port 0x511 (the Data Register),
and update all references in OvmfPkg.

Cc: Jordan Justen 
Suggested-by: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Include/IndustryStandard/QemuFwCfg.h | 1 +
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c  | 6 +++---
 OvmfPkg/SmmControl2Dxe/SmiFeatures.c | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h 
b/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
index 776bfe88ae2b..5da6b456febe 100644
--- a/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
+++ b/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
@@ -47,6 +47,7 @@
 // platforms (Ia32 and X64).
 //
 #define FW_CFG_IO_SELECTOR0x510
+#define FW_CFG_IO_DATA0x511
 
 //
 // Numerically defined keys.
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index 1387ea85f3f0..d79d0a444ca7 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -135,7 +135,7 @@ InternalQemuFwCfgReadBytes (
 InternalQemuFwCfgDmaBytes ((UINT32)Size, Buffer, FW_CFG_DMA_CTL_READ);
 return;
   }
-  IoReadFifo8 (0x511, Size, Buffer);
+  IoReadFifo8 (FW_CFG_IO_DATA, Size, Buffer);
 }
 
 
@@ -187,7 +187,7 @@ QemuFwCfgWriteBytes (
   InternalQemuFwCfgDmaBytes ((UINT32)Size, Buffer, FW_CFG_DMA_CTL_WRITE);
   return;
 }
-IoWriteFifo8 (0x511, Size, Buffer);
+IoWriteFifo8 (FW_CFG_IO_DATA, Size, Buffer);
   }
 }
 
@@ -230,7 +230,7 @@ QemuFwCfgSkipBytes (
   //
   while (Size > 0) {
 ChunkSize = MIN (Size, sizeof SkipBuffer);
-IoReadFifo8 (0x511, ChunkSize, SkipBuffer);
+IoReadFifo8 (FW_CFG_IO_DATA, ChunkSize, SkipBuffer);
 Size -= ChunkSize;
   }
 }
diff --git a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c 
b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
index 352ffa017373..73c29848b334 100644
--- a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
+++ b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
@@ -303,7 +303,7 @@ SaveSmiFeatures (
  S3SaveState,// This
  EFI_BOOT_SCRIPT_IO_POLL_OPCODE, // OpCode
  EfiBootScriptWidthUint8,// Width
- (UINT64)(UINTN)0x511,   // Address
+ (UINT64)(UINTN)FW_CFG_IO_DATA,  // Address
  ,// Data
  ,// DataMask
  MAX_UINT64  // Delay
-- 
2.9.3


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

[edk2] [PATCH 0/6] OvmfPkg: AcpiPlatformDxe, QemuFwCfg: small cleanups after WRITE_POINTER

[Laszlo Ersek]

Most of these were suggested by Jordan.

Cc: Jordan Justen 

Repo:   https://github.com/lersek/edk2.git
Branch: write_pointer_followup

Thanks!
Laszlo

Laszlo Ersek (6):
  OvmfPkg/AcpiPlatformDxe: drop double right shift in ADD/WRITE POINTER
cmds
  OvmfPkg/AcpiPlatformDxe: update PointerValue comments in
"BootScript.c"
  OvmfPkg/QemuFwCfgLib: move types/macros from lib class to
IndustryStandard
  OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_SELECTOR, adapt the package
  OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_DATA, adapt the package
  OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_DMA_ADDRESS, adapt the package

 OvmfPkg/Include/IndustryStandard/QemuFwCfg.h | 104 
 OvmfPkg/Include/Library/QemuFwCfgLib.h   |  70 +
 OvmfPkg/AcpiPlatformDxe/BootScript.c |  18 ++--
 OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c  |   8 +-
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c  |  12 +--
 OvmfPkg/SmmControl2Dxe/SmiFeatures.c |   6 +-
 6 files changed, 128 insertions(+), 90 deletions(-)
 create mode 100644 OvmfPkg/Include/IndustryStandard/QemuFwCfg.h

-- 
2.9.3

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

[edk2] [PATCH 4/6] OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_SELECTOR, adapt the package

[Laszlo Ersek]

Introduce the FW_CFG_IO_SELECTOR macro for IO Port 0x510 (the Selector
Register), and update all references in OvmfPkg.

Cc: Jordan Justen 
Suggested-by: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Include/IndustryStandard/QemuFwCfg.h | 6 ++
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c  | 2 +-
 OvmfPkg/SmmControl2Dxe/SmiFeatures.c | 2 +-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h 
b/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
index c7e9b5c382a5..776bfe88ae2b 100644
--- a/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
+++ b/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
@@ -43,6 +43,12 @@
 #define FW_CFG_DMA_CTL_WRITE  BIT4
 
 //
+// The fw_cfg registers can be found at these IO Ports, on the IO-mapped
+// platforms (Ia32 and X64).
+//
+#define FW_CFG_IO_SELECTOR0x510
+
+//
 // Numerically defined keys.
 //
 typedef enum {
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index 7744873217fe..1387ea85f3f0 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -42,7 +42,7 @@ QemuFwCfgSelectItem (
   )
 {
   DEBUG ((EFI_D_INFO, "Select Item: 0x%x\n", (UINT16)(UINTN) QemuFwCfgItem));
-  IoWrite16 (0x510, (UINT16)(UINTN) QemuFwCfgItem);
+  IoWrite16 (FW_CFG_IO_SELECTOR, (UINT16)(UINTN) QemuFwCfgItem);
 }
 
 
diff --git a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c 
b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
index e070969065c0..352ffa017373 100644
--- a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
+++ b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
@@ -281,7 +281,7 @@ SaveSmiFeatures (
   S3SaveState, // This
   EFI_BOOT_SCRIPT_IO_WRITE_OPCODE, // OpCode
   EfiBootScriptWidthUint16,// Width
-  (UINT64)0x510,   // Address
+  (UINT64)FW_CFG_IO_SELECTOR,  // Address
   (UINTN)1,// Count
 // Buffer
   );
-- 
2.9.3


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

[edk2] [PATCH 1/6] OvmfPkg/AcpiPlatformDxe: drop double right shift in ADD/WRITE POINTER cmds

[Laszlo Ersek]

The Count parameter of RShiftU64() must be strictly smaller than 64.
ProcessCmdAddPointer() and ProcessCmdWritePointer() currently ensure this
by "cleverly" breaking the last bit of a potentially 8-byte right shift
out to a separate operation.

Instead, exclude the Count==64 case explicitly (in which case the
preexistent outer RShiftU64() would return 0), and keep only the inner
RShiftU64(), with the direct Count however.

This is not a functional change, just style improvement.

Cc: Jordan Justen 
Suggested-by: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c 
b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
index eadd690bef4e..6a0ecd1ad962 100644
--- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
+++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
@@ -277,8 +277,8 @@ ProcessCmdAddPointer (
   ASSERT ((UINTN)Blob2->Base <= MAX_ADDRESS - Blob2->Size);
 
   PointerValue += (UINT64)(UINTN)Blob2->Base;
-  if (RShiftU64 (
-RShiftU64 (PointerValue, AddPointer->PointerSize * 8 - 1), 1) != 0) {
+  if (AddPointer->PointerSize < 8 &&
+  RShiftU64 (PointerValue, AddPointer->PointerSize * 8) != 0) {
 DEBUG ((EFI_D_ERROR, "%a: relocated pointer value unrepresentable in "
   "\"%a\"\n", __FUNCTION__, AddPointer->PointerFile));
 return EFI_PROTOCOL_ERROR;
@@ -438,8 +438,8 @@ ProcessCmdWritePointer (
   ASSERT ((UINTN)PointeeBlob->Base <= MAX_ADDRESS - PointeeBlob->Size);
 
   PointerValue += (UINT64)(UINTN)PointeeBlob->Base;
-  if (RShiftU64 (
-RShiftU64 (PointerValue, WritePointer->PointerSize * 8 - 1), 1) != 0) {
+  if (WritePointer->PointerSize < 8 &&
+  RShiftU64 (PointerValue, WritePointer->PointerSize * 8) != 0) {
 DEBUG ((DEBUG_ERROR, "%a: pointer value unrepresentable in \"%a\"\n",
   __FUNCTION__, WritePointer->PointerFile));
 return EFI_PROTOCOL_ERROR;
-- 
2.9.3


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

[edk2] [PATCH 3/6] OvmfPkg/QemuFwCfgLib: move types/macros from lib class to IndustryStandard

[Laszlo Ersek]

Cc: Jordan Justen 
Suggested-by: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Include/IndustryStandard/QemuFwCfg.h | 96 
 OvmfPkg/Include/Library/QemuFwCfgLib.h   | 70 +-
 2 files changed, 97 insertions(+), 69 deletions(-)

diff --git a/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h 
b/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
new file mode 100644
index ..c7e9b5c382a5
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h
@@ -0,0 +1,96 @@
+/** @file
+  Macro and type definitions corresponding to the QEMU fw_cfg interface.
+
+  Refer to "docs/specs/fw_cfg.txt" in the QEMU source directory.
+
+  Copyright (c) 2011 - 2013, Intel Corporation. All rights reserved.
+  Copyright (C) 2013 - 2017, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution. The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#ifndef __FW_CFG_H__
+#define __FW_CFG_H__
+
+#include 
+
+//
+// The size, in bytes, of names of firmware configuration files, including at
+// least one terminating NUL byte.
+//
+#define QEMU_FW_CFG_FNAME_SIZE 56
+
+//
+// If the following bit is set in the UINT32 fw_cfg revision / feature bitmap
+// -- read from key 0x0001 with the basic IO Port or MMIO method --, then the
+// DMA interface is available.
+//
+#define FW_CFG_F_DMA BIT1
+
+//
+// Macros for the FW_CFG_DMA_ACCESS.Control bitmap (in native encoding).
+//
+#define FW_CFG_DMA_CTL_ERROR  BIT0
+#define FW_CFG_DMA_CTL_READ   BIT1
+#define FW_CFG_DMA_CTL_SKIP   BIT2
+#define FW_CFG_DMA_CTL_SELECT BIT3
+#define FW_CFG_DMA_CTL_WRITE  BIT4
+
+//
+// Numerically defined keys.
+//
+typedef enum {
+  QemuFwCfgItemSignature= 0x,
+  QemuFwCfgItemInterfaceVersion = 0x0001,
+  QemuFwCfgItemSystemUuid   = 0x0002,
+  QemuFwCfgItemRamSize  = 0x0003,
+  QemuFwCfgItemGraphicsEnabled  = 0x0004,
+  QemuFwCfgItemSmpCpuCount  = 0x0005,
+  QemuFwCfgItemMachineId= 0x0006,
+  QemuFwCfgItemKernelAddress= 0x0007,
+  QemuFwCfgItemKernelSize   = 0x0008,
+  QemuFwCfgItemKernelCommandLine= 0x0009,
+  QemuFwCfgItemInitrdAddress= 0x000a,
+  QemuFwCfgItemInitrdSize   = 0x000b,
+  QemuFwCfgItemBootDevice   = 0x000c,
+  QemuFwCfgItemNumaData = 0x000d,
+  QemuFwCfgItemBootMenu = 0x000e,
+  QemuFwCfgItemMaximumCpuCount  = 0x000f,
+  QemuFwCfgItemKernelEntry  = 0x0010,
+  QemuFwCfgItemKernelData   = 0x0011,
+  QemuFwCfgItemInitrdData   = 0x0012,
+  QemuFwCfgItemCommandLineAddress   = 0x0013,
+  QemuFwCfgItemCommandLineSize  = 0x0014,
+  QemuFwCfgItemCommandLineData  = 0x0015,
+  QemuFwCfgItemKernelSetupAddress   = 0x0016,
+  QemuFwCfgItemKernelSetupSize  = 0x0017,
+  QemuFwCfgItemKernelSetupData  = 0x0018,
+  QemuFwCfgItemFileDir  = 0x0019,
+
+  QemuFwCfgItemX86AcpiTables= 0x8000,
+  QemuFwCfgItemX86SmbiosTables  = 0x8001,
+  QemuFwCfgItemX86Irq0Override  = 0x8002,
+  QemuFwCfgItemX86E820Table = 0x8003,
+  QemuFwCfgItemX86HpetData  = 0x8004,
+
+} FIRMWARE_CONFIG_ITEM;
+
+//
+// Communication structure for the DMA access method. All fields are encoded in
+// big endian.
+//
+#pragma pack (1)
+typedef struct {
+  UINT32 Control;
+  UINT32 Length;
+  UINT64 Address;
+} FW_CFG_DMA_ACCESS;
+#pragma pack ()
+
+#endif
diff --git a/OvmfPkg/Include/Library/QemuFwCfgLib.h 
b/OvmfPkg/Include/Library/QemuFwCfgLib.h
index 41c3817470a2..2a1261327b01 100644
--- a/OvmfPkg/Include/Library/QemuFwCfgLib.h
+++ b/OvmfPkg/Include/Library/QemuFwCfgLib.h
@@ -17,75 +17,7 @@
 #ifndef __FW_CFG_LIB__
 #define __FW_CFG_LIB__
 
-//
-// The size, in bytes, of names of firmware configuration files, including at
-// least one terminating NUL byte.
-//
-#define QEMU_FW_CFG_FNAME_SIZE 56
-
-//
-// If the following bit is set in the UINT32 fw_cfg revision / feature bitmap
-// -- read from key 0x0001 with the basic IO Port or MMIO method --, then the
-// DMA interface is available.
-//
-#define FW_CFG_F_DMA BIT1
-
-//
-// Macros for the FW_CFG_DMA_ACCESS.Control bitmap (in native encoding).
-//
-#define FW_CFG_DMA_CTL_ERROR  BIT0
-#define FW_CFG_DMA_CTL_READ   BIT1
-#define FW_CFG_DMA_CTL_SKIP   BIT2
-#define FW_CFG_DMA_CTL_SELECT BIT3
-#define FW_CFG_DMA_CTL_WRITE  BIT4
-
-typedef enum {
-  QemuFwCfgItemSignature= 0x,
-  QemuFwCfgItemInterfaceVersion = 0x0001,
-  QemuFwCfgItemSystemUuid   = 0x0002,
-  QemuFwCfgItemRamSize  = 0x0003,
-  

[edk2] [PATCH 2/6] OvmfPkg/AcpiPlatformDxe: update PointerValue comments in "BootScript.c"

[Laszlo Ersek]

Commit df73df138d9d ("OvmfPkg/AcpiPlatformDxe: replay
QEMU_LOADER_WRITE_POINTER commands at S3", 2017-02-09) added
"BootScript.c" with such comments on the PointerValue field of
CONDENSED_WRITE_POINTER, and on the corresponding PointerValue parameter
of SaveCondensedWritePointerToS3Context(), that did not consider the
then-latest update of the QEMU_LOADER_WRITE_POINTER structure. (Namely,
the introduction of the PointeeOffset field.)

The code is fine as-is -- ProcessCmdWritePointer() already calls
SaveCondensedWritePointerToS3Context() correctly, and "BootScript.c"
itself is indifferent to the exact values --, but the comments in
"BootScript.c" should match reality too. Update them.

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/AcpiPlatformDxe/BootScript.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/OvmfPkg/AcpiPlatformDxe/BootScript.c 
b/OvmfPkg/AcpiPlatformDxe/BootScript.c
index b7a7f270f223..1ad468e2f834 100644
--- a/OvmfPkg/AcpiPlatformDxe/BootScript.c
+++ b/OvmfPkg/AcpiPlatformDxe/BootScript.c
@@ -29,6 +29,7 @@ typedef struct {
   UINT8  PointerSize;   // copied as-is from QEMU_LOADER_WRITE_POINTER
   UINT32 PointerOffset; // copied as-is from QEMU_LOADER_WRITE_POINTER
   UINT64 PointerValue;  // resolved from QEMU_LOADER_WRITE_POINTER.PointeeFile
+//   and QEMU_LOADER_WRITE_POINTER.PointeeOffset
 } CONDENSED_WRITE_POINTER;
 
 
@@ -159,7 +160,8 @@ ReleaseS3Context (
 
   @param[in] PointerValue   The base address of the allocated / downloaded
 fw_cfg blob that is identified by
-QEMU_LOADER_WRITE_POINTER.PointeeFile.
+QEMU_LOADER_WRITE_POINTER.PointeeFile, plus
+QEMU_LOADER_WRITE_POINTER.PointeeOffset.
 
   @retval EFI_SUCCESS   The information derived from
 QEMU_LOADER_WRITE_POINTER has been successfully
@@ -271,9 +273,9 @@ TransferS3ContextToBootScript (
   // (2) call QEMU with the FW_CFG_DMA_ACCESS object,
   // (3) wait for the select+skip to finish,
   // (4) restore a SCRATCH_BUFFER object in reserved memory that writes
-  // PointerValue (base address of the allocated / downloaded PointeeFile),
-  // of size PointerSize, into the fw_cfg file selected in (1), at the
-  // offset sought to in (1),
+  // PointerValue (base address of the allocated / downloaded PointeeFile,
+  // plus PointeeOffset), of size PointerSize, into the fw_cfg file
+  // selected in (1), at the offset sought to in (1),
   // (5) call QEMU with the FW_CFG_DMA_ACCESS object,
   // (6) wait for the write to finish.
   //
@@ -346,8 +348,8 @@ TransferS3ContextToBootScript (
 //
 // (4) restore a SCRATCH_BUFFER object in reserved memory that writes
 // PointerValue (base address of the allocated / downloaded
-// PointeeFile), of size PointerSize, into the fw_cfg file selected in
-// (1), at the offset sought to in (1),
+// PointeeFile, plus PointeeOffset), of size PointerSize, into the
+// fw_cfg file selected in (1), at the offset sought to in (1),
 //
 Access->Control = SwapBytes32 (FW_CFG_DMA_CTL_WRITE);
 Access->Length = SwapBytes32 (Condensed->PointerSize);
-- 
2.9.3


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

[edk2] memory type information HOB / UEFI memmap defrag

[Laszlo Ersek]

Hi,

the UEFI memmap under OVMF is getting very fragmented, I'm now counting
~80 entries in it, under various circumstances.

I recall that a platform's PlatformPei can "prime" the DXE/UEFI memory
allocation system (not the GCD services) for various memory types, by
producing a memory type information HOB.

My vague understanding is that BDS will in turn check if the actual
allocations fit in the allotments from the HOB, and if not, it will try
to feed back the increased amount to PEI, for the next boot.

As far as I understand, this requires the VariablePei (read only driver)
for a platform (so that its PlatformPei can read the info from BDS, and
produce the HOB accordingly). Some questions:

- how big is VariablePei in binary form?
- does it depend on permanent RAM being installed / discovered?
- If so, is that dependency implemented with a static DEPEX, or with a
  callback?

Further questions:
- what is the variable (GUID and Name) that BDS uses for this
  information?
- What is the format of the variable?
- Does the logic depend on particular boot modes? OVMF only supports two
  boot modes, BOOT_WITH_FULL_CONFIGURATION and BOOT_ON_S3_RESUME.

In OVMF we currently use a static array for populating the HOB (see
"mDefaultMemoryTypeInformation" in "PlatformPei/Platform.c"). If making
it all dynamic is easy, I think I'd like to do it (sometime later).

If, however, it would require us to up-end OVMF's PlatformPei, then I
think it's not worth it; we can just bump the values in
"mDefaultMemoryTypeInformation" suitably.

Some examples I consider as up-ending OVMF's PlatformPei:

(1) If VariablePei needs permanent RAM with a hard DEPEX. In OVMF,
permanent RAM is installed by PlatformPei (thereby potentially
unblocking VariablePei's dispatch); however, it is also PlatformPei
that would require the r/o variable service to work, because
PlatformPei produces the memory type information HOB. So, such a
DEPEX in VariablePei would require splitting up PlatformPei, which
makes the dynamism totally not worth it.

*Maybe* we could add a callback for when the variable service PPI is
installed. Dunno.

(2) Supporting a third boot mode beyond BOOT_WITH_FULL_CONFIGURATION and
BOOT_ON_S3_RESUME. Not even worth the audit of current boot mode
checks.

Further remarks:

- OVMF doesn't care about supporting S4 at the moment, and I personally
  have no plans to work on that. (I'm saying this because I vaguely
  recall that the memory type info HOB is related to S4 resume, so an
  argument could perhaps be made, "this could enable S4 for OVMF".
  Personally, I'm not interested. Still carrying the scars of S3.)

- I actually tried to bump the values in "mDefaultMemoryTypeInformation"
  quite a few months back, but the benefits I saw were negligible. I was
  left confused about the memory type info HOB, and that was the reason
  I didn't ultimately post any patch (and why I stopped pursuing this
  question). For reference, this was the patch:

> commit b357e8d88c0304ea2b31aefafe53d06c9769fb78
> Author: Laszlo Ersek 
> Date:   Thu Sep 17 16:18:46 2015 +0200
>
> OvmfPkg: PlatformPei: decrease memmap fragmentation
>
> Inspired by ArmVirtPkg commit c199315 ("ArmVirtPkg: increase memory
> preallocations to reduce region count"), I checked the number of entries
> in the UEFI memory map, as dumped by the UEFI shell's MEMMAP command, and
> by the Linux kernel. The number of entries is quite high, about 50-55.
>
> I calculated the new preallocations as follows:
> - added 15% to each byte count usage reported by the MEMMAP command, for
>   some future-proofing,
> - expressed the result in kilobytes (both pages and byte counts are hard
>   to read),
> - just for our information, I calculated the ratio between the new
>   preallocation and the old one.
>
> For example, the UEFI shell reported 44 pages (180224 bytes) of reserved
> memory usage. The new preallocation, expressed in kilobytes, is
> trunc(180224 * 1.15 / 1024) = 202. This preallocation is approx. 12.62
> times the previous preallocation (which was 4 pages, ie. 16384 bytes).
>
> Here's the full table:
>
>   memory type  pages from  bytes from  new KBfactor of former
>MEMMAP cmd  MEMMAP cmd  prealloc  prealloc
>   ---  --  --    
>   Reserved 44  180224   202 12.62
>   LoaderCode  313 1282048  1439   n/a
>   BS_Code1300 5324800  5980  3.89
>   BS_Data905337081088 41643  2.71
>   RT_Code 223  913408  1025  5.33
>   RT_Data 789 3231744  3629 25.20
>   ACPI_Recl 8   3276836  1.12
>   ACPI_NVS283 1159168  1301 

Re: [edk2] [PATCH v2 4/4] ArmPkg/ArmMmuLib: AARCH64: add support for modifying only permissions

[Leif Lindholm]

On Wed, Feb 15, 2017 at 05:11:56PM +, Ard Biesheuvel wrote:
> Since the new DXE page protection for PE/COFF images may invoke
> EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() with only permission
> attributes set, add support for this in the AARCH64 MMU code.
> 
> Move the EFI_MEMORY_CACHETYPE_MASK macro to a shared location between
> CpuDxe and ArmMmuLib so we don't have to introduce yet another
> definition.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

(This diff is also a lot less confusing :)

> ---
>  ArmPkg/Drivers/CpuDxe/CpuDxe.h   |  8 --
>  ArmPkg/Include/Library/ArmLib.h  |  4 +
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 91 ++--
>  3 files changed, 67 insertions(+), 36 deletions(-)
> 
> diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.h b/ArmPkg/Drivers/CpuDxe/CpuDxe.h
> index d16abe400ef3..80c305d53dd1 100644
> --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.h
> +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.h
> @@ -39,14 +39,6 @@
>  #include 
>  
>  
> -#define EFI_MEMORY_CACHETYPE_MASK (EFI_MEMORY_UC  | \
> -   EFI_MEMORY_WC  | \
> -   EFI_MEMORY_WT  | \
> -   EFI_MEMORY_WB  | \
> -   EFI_MEMORY_UCE   \
> -   )
> -
> -
>  /**
>This function registers and enables the handler specified by 
> InterruptHandler for a processor
>interrupt or exception type specified by InterruptType. If 
> InterruptHandler is NULL, then the
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index 19501efa991f..24ffe9f1aaa7 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -26,6 +26,10 @@
>   #error "Unknown chipset."
>  #endif
>  
> +#define EFI_MEMORY_CACHETYPE_MASK   (EFI_MEMORY_UC | EFI_MEMORY_WC | \
> + EFI_MEMORY_WT | EFI_MEMORY_WB | \
> + EFI_MEMORY_UCE)
> +
>  /**
>   * The UEFI firmware must not use the 
> ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_* attributes.
>   *
> diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c 
> b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
> index 6aa970bc0514..9e0593ce598b 100644
> --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
> +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
> @@ -101,27 +101,6 @@ PageAttributeToGcdAttribute (
>return GcdAttributes;
>  }
>  
> -ARM_MEMORY_REGION_ATTRIBUTES
> -GcdAttributeToArmAttribute (
> -  IN UINT64 GcdAttributes
> -  )
> -{
> -  switch (GcdAttributes & 0xFF) {
> -  case EFI_MEMORY_UC:
> -return ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> -  case EFI_MEMORY_WC:
> -return ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
> -  case EFI_MEMORY_WT:
> -return ARM_MEMORY_REGION_ATTRIBUTE_WRITE_THROUGH;
> -  case EFI_MEMORY_WB:
> -return ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> -  default:
> -DEBUG ((EFI_D_ERROR, "GcdAttributeToArmAttribute: 0x%lX attributes is 
> not supported.\n", GcdAttributes));
> -ASSERT (0);
> -return ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> -  }
> -}
> -
>  #define MIN_T0SZ16
>  #define BITS_PER_LEVEL  9
>  
> @@ -425,6 +404,48 @@ FillTranslationTable (
> );
>  }
>  
> +STATIC
> +UINT64
> +GcdAttributeToPageAttribute (
> +  IN UINT64 GcdAttributes
> +  )
> +{
> +  UINT64 PageAttributes;
> +
> +  switch (GcdAttributes & EFI_MEMORY_CACHETYPE_MASK) {
> +  case EFI_MEMORY_UC:
> +PageAttributes = TT_ATTR_INDX_DEVICE_MEMORY;
> +break;
> +  case EFI_MEMORY_WC:
> +PageAttributes = TT_ATTR_INDX_MEMORY_NON_CACHEABLE;
> +break;
> +  case EFI_MEMORY_WT:
> +PageAttributes = TT_ATTR_INDX_MEMORY_WRITE_THROUGH | 
> TT_SH_INNER_SHAREABLE;
> +break;
> +  case EFI_MEMORY_WB:
> +PageAttributes = TT_ATTR_INDX_MEMORY_WRITE_BACK | TT_SH_INNER_SHAREABLE;
> +break;
> +  default:
> +PageAttributes = TT_ATTR_INDX_MASK;
> +break;
> +  }
> +
> +  if ((GcdAttributes & EFI_MEMORY_XP) != 0 ||
> +  (GcdAttributes & EFI_MEMORY_CACHETYPE_MASK) == EFI_MEMORY_UC) {
> +if (ArmReadCurrentEL () == AARCH64_EL2) {
> +  PageAttributes |= TT_XN_MASK;
> +} else {
> +  PageAttributes |= TT_UXN_MASK | TT_PXN_MASK;
> +}
> +  }
> +
> +  if ((GcdAttributes & EFI_MEMORY_RO) != 0) {
> +PageAttributes |= TT_AP_RO_RO;
> +  }
> +
> +  return PageAttributes | TT_AF;
> +}
> +
>  RETURN_STATUS
>  SetMemoryAttributes (
>IN EFI_PHYSICAL_ADDRESS  BaseAddress,
> @@ -434,17 +455,31 @@ SetMemoryAttributes (
>)
>  {
>RETURN_STATUSStatus;
> -  ARM_MEMORY_REGION_DESCRIPTOR MemoryRegion;
>UINT64  *TranslationTable;
> -
> -  MemoryRegion.PhysicalBase = BaseAddress;
> -  MemoryRegion.VirtualBase = BaseAddress;
> - 

Re: [edk2] [PATCH v2 2/4] ArmPkg/CpuDxe: translate invalid memory types in EfiAttributeToArmAttribute

[Leif Lindholm]

On Wed, Feb 15, 2017 at 05:11:54PM +, Ard Biesheuvel wrote:
> The single user of EfiAttributeToArmAttribute () is the protocol
> method EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes(), which uses the
> return value to compare against the ARM attributes of an existing mapping,
> to infer whether it is actually necessary to change anything, or whether
> the requested update is redundant. This saves some cache and TLB
> maintenance on 32-bit ARM systems that use uncached translation tables.
> 
> However, EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() may be invoked with
> only permission bits set, in which case the implied requested action is to
> update the permissions of the region without modifying the cacheability
> attributes. This is currently not possible, because
> EfiAttributeToArmAttribute () ASSERT()s [on AArch64] on Attributes arguments
> that lack a cacheability bit.
> 
> So let's simply return TT_ATTR_INDX_MASK (AArch64) or
> TT_DESCRIPTOR_SECTION_TYPE_FAULT (ARM) in these cases (or'ed with the
> appropriate permission bits). This way, the return value is equally
> suitable for checking whether the attributes need to be modified, but
> in a way that accommodates the use without a cacheability bit set.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

With this updated commit message:
Reviewed-by: Leif Lindholm 

> ---
>  ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c | 4 +---
>  ArmPkg/Drivers/CpuDxe/Arm/Mmu.c | 3 ---
>  2 files changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c 
> b/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c
> index 15d5a8173233..7688846e70cb 100644
> --- a/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c
> +++ b/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c
> @@ -216,9 +216,7 @@ EfiAttributeToArmAttribute (
>  ArmAttributes = TT_ATTR_INDX_MEMORY_WRITE_BACK;
>  break;
>default:
> -DEBUG ((EFI_D_ERROR, "EfiAttributeToArmAttribute: 0x%lX attributes is 
> not supported.\n", EfiAttributes));
> -ASSERT (0);
> -ArmAttributes = TT_ATTR_INDX_DEVICE_MEMORY;
> +ArmAttributes = TT_ATTR_INDX_MASK;
>}
>  
>// Set the access flag to match the block attributes
> diff --git a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
> index 6dcfba69e879..b6ba975b353a 100644
> --- a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
> +++ b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
> @@ -733,10 +733,7 @@ EfiAttributeToArmAttribute (
>  
>  case EFI_MEMORY_UCE:
>  default:
> -  // Cannot be implemented UEFI definition unclear for ARM
> -  // Cause a page fault if these ranges are accessed.
>ArmAttributes = TT_DESCRIPTOR_SECTION_TYPE_FAULT;
> -  DEBUG ((EFI_D_PAGE, "SetMemoryAttributes(): Unsupported attribute %x 
> will page fault on access\n", EfiAttributes));
>break;
>}
>  
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 5/5] OvmfPkg/AcpiPlatformDxe: replay QEMU_LOADER_WRITE_POINTER commands at S3

[Laszlo Ersek]

On 02/21/17 01:17, Jordan Justen wrote:
> On 2017-02-17 14:48:52, Laszlo Ersek wrote:
>> On 02/17/17 23:41, Laszlo Ersek wrote:
>>
>> [snip]
>>
>>> I briefly considered a QemuFwCfgLib API that lets the caller inquire
>>> about DMA enablement, but it just doesn't feel right, and (considering
>>> the above) it's not even useful. Later I would like to abstract away
>>> this S3 boot script munging, from both this driver and SmmControl2Dxe,
>>> but the interface is a hard nut:
>>>
>>> - SEC lib instance (exists only for x86): must return EFI_UNSUPPORTED
>>> - PEI/DXE instance (exists only for x86): must be split into
>>>   - PEI only: returns EFI_UNSUPPORTED
>>>   - DXE only:
>>> - returns EFI_UNSUPPORTED if S3 is disabled
>>> - works if the protocol is available
>>> - what does it do if the protocol is not available *yet*?
>>>   - can't use a DEPEX (whole client module won't load with S3
>>> disabled!)
>>>   - register protocol notify in constructor? then what?
>>> - collect operations and write them to boot script at EndOfDxe?
>>>   - that always turns out to be a bad idea, due to unspecified
>>> callback invocation order
>>
>> One thing I can imagine here is: simply push the dependency handling to
>> the client module. If the protocol is not found, just return
>> EFI_NOT_STARTED, and let the client module deal with that. The client
>> can set its own DEPEX, or register a protocol notify as necessary. So I
>> guess this could be solved after all, hopefully.
> 
> Yeah, I figured the S3 depex is the tricky part. Also, adding an S3
> specific interface doesn't fit well in QemuFwCfgLib, which I think
> should focus on just the raw fw-cfg interface. Based on that, I'm not
> particularly enthused about QemuFwCfgS3Enabled.
> 
> Maybe we could add a new S3+fw-cfg library interface? Maybe
> QemuS3FwCfgLib? I'm not sure it makes sense, or solves all the
> requirements anyhow...

I think it would make sense, yes; I actually thought of that too, but
didn't dare suggest it, remembering how opposed you had been to a
separate IoFifoLib recently :)

> 
> ...so, let's figure that out later. :)

I filed   for this.

> 
> Reviewed-by: Jordan Justen 

Series committed in range 85520606ad45..df73df138d9d.

I plan to post an "easy" followup series, but that won't change
functionality, and there's no similar time pressure for it.

Thank you very much for the prompt review!
Laszlo

> 
>>> - DXE only instance (exists for arm/aarch64 only): very different from
>>>   the x86 impl already (uses chunked MMIO at the bottom, not REP IO),
>>>   so unification with the above is hard
>>>
>>> While writing this patch, I was racking my brain for hours about this. I
>>> think I must have restarted this patch three or four times just because
>>> of that.
>>>
>>> Ultimately, it's the second driver where we use a meaningful boot script
>>> fragment, and usually the third occurrence of a pattern is where the
>>> generics start to emerge, and (hopefully) become a candidate for
>>> factoring out. I dislike the repetitive and hard-to-read nature of the
>>> opcode additions (hence the profuse comments above), but from the two
>>> instances we can look at (SmmControl2Dxe and this patch), I couldn't
>>> really abstract away a natural interface.
>>>
>>> I think it is a relatively big task anyway, deserving its own BZ (not to
>>> be confused with the also separate BZ that I proposed for residual /
>>> cleanup patches on top of this series, should you recommend such.) If
>>> you felt inclined to research / prototype that, that would be huge...
>>>
>>> Thanks!
>>> Laszlo
>>>

 -Jordan
>>
>>

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

[edk2] [PATCH 4/7] SignedCapsulePkg: Replace [Ascii|Unicode]ValueToString

[Hao Wu]

It is the follow up of commits 51f0ceb..9e32e97 to replace
AsciiValueToString/UnicodeValueToString with
AsciiValueToStringS/UnicodeValueToStringS.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 SignedCapsulePkg/Universal/RecoveryModuleLoadPei/ParseConfigProfile.c | 10 
--
 SignedCapsulePkg/Universal/SystemFirmwareUpdate/ParseConfigProfile.c  | 10 
--
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git 
a/SignedCapsulePkg/Universal/RecoveryModuleLoadPei/ParseConfigProfile.c 
b/SignedCapsulePkg/Universal/RecoveryModuleLoadPei/ParseConfigProfile.c
index fef1daf..204fd53 100644
--- a/SignedCapsulePkg/Universal/RecoveryModuleLoadPei/ParseConfigProfile.c
+++ b/SignedCapsulePkg/Universal/RecoveryModuleLoadPei/ParseConfigProfile.c
@@ -2,7 +2,7 @@
   Parse the INI configuration file and pass the information to the recovery 
driver
   so that the driver can perform recovery accordingly.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions
@@ -85,7 +85,13 @@ ParseRecoveryDataFile (
 // Get the section name of each update
 //
 AsciiStrCpyS (Entry, MAX_LINE_LENGTH, "Recovery");
-AsciiValueToString(Entry + AsciiStrLen(Entry), 0, Index, 0);
+AsciiValueToStringS (
+  Entry + AsciiStrnLenS (Entry, MAX_LINE_LENGTH),
+  MAX_LINE_LENGTH - AsciiStrnLenS (Entry, MAX_LINE_LENGTH),
+  0,
+  Index,
+  0
+  );
 Status = GetStringFromDataFile(
Context,
"Head",
diff --git 
a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/ParseConfigProfile.c 
b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/ParseConfigProfile.c
index dcad762..67584c6 100644
--- a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/ParseConfigProfile.c
+++ b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/ParseConfigProfile.c
@@ -2,7 +2,7 @@
   Parse the INI configuration file and pass the information to the update 
driver
   so that the driver can perform update accordingly.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions
@@ -86,7 +86,13 @@ ParseUpdateDataFile (
 // Get the section name of each update
 //
 AsciiStrCpyS (Entry, MAX_LINE_LENGTH, "Update");
-AsciiValueToString(Entry + AsciiStrLen(Entry), 0, Index, 0);
+AsciiValueToStringS (
+  Entry + AsciiStrnLenS (Entry, MAX_LINE_LENGTH),
+  MAX_LINE_LENGTH - AsciiStrnLenS (Entry, MAX_LINE_LENGTH),
+  0,
+  Index,
+  0
+  );
 Status = GetStringFromDataFile(
Context,
"Head",
-- 
1.9.5.msysgit.0

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

[edk2] [PATCH 3/7] Nt32Pkg: Replace [Ascii|Unicode]ValueToString

[Hao Wu]

It is the follow up of commits 51f0ceb..9e32e97 to replace
AsciiValueToString/UnicodeValueToString with
AsciiValueToStringS/UnicodeValueToStringS.

Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c 
b/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c
index 93ecc7d..53e9ff4 100644
--- a/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c
+++ b/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c
@@ -1,7 +1,7 @@
 /** @file
   Perform the platform memory test
 
-Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2017, 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
@@ -155,7 +155,7 @@ PlatformBootManagerMemoryTest (
   TempData
   );
   if (TestPercent != PreviousValue) {
-UnicodeValueToString (StrPercent, 0, TestPercent, 0);
+UnicodeValueToStringS (StrPercent, sizeof (StrPercent), 0, 
TestPercent, 0);
 TmpStr = HiiGetString (gStringPackHandle, STRING_TOKEN 
(STR_MEMORY_TEST_PERCENT), NULL);
 if (TmpStr != NULL) {
   //
@@ -223,7 +223,7 @@ PlatformBootManagerMemoryTest (
 
 Done:
   if (!FeaturePcdGet(PcdBootlogoOnlyEnable)) {
-UnicodeValueToString (StrTotalMemory, COMMA_TYPE, TotalMemorySize, 0);
+UnicodeValueToStringS (StrTotalMemory, StrTotalMemorySize, COMMA_TYPE, 
TotalMemorySize, 0);
 if (StrTotalMemory[0] == L',') {
   StrTotalMemory++;
   StrTotalMemorySize -= sizeof (CHAR16);
-- 
1.9.5.msysgit.0

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

[edk2] [PATCH 2/7] MdeModulePkg: Replace [Ascii|Unicode]ValueToString

[Hao Wu]

It is the follow up of commits 51f0ceb..9e32e97 to replace
AsciiValueToString/UnicodeValueToString with
AsciiValueToStringS/UnicodeValueToStringS.

Cc: Jiewen Yao 
Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Application/UiApp/FrontPage.c| 15 +--
 MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c | 12 +++--
 MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c   | 20 +++--
 MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c   | 10 -
 MdeModulePkg/Library/DxeNetLib/DxeNetLib.c| 24 --
 MdeModulePkg/Library/UefiHiiLib/HiiLib.c  | 29 ++--
 MdeModulePkg/Universal/CapsulePei/UefiCapsule.c   | 18 ++--
 MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c | 10 -
 MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c | 37 
+--
 MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c  | 29 ++--
 MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c | 47 
+---
 MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigImpl.c | 14 --
 MdeModulePkg/Universal/SetupBrowserDxe/Expression.c   | 11 -
 MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c |  4 +-
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.c| 38 
+---
 15 files changed, 258 insertions(+), 60 deletions(-)

diff --git a/MdeModulePkg/Application/UiApp/FrontPage.c 
b/MdeModulePkg/Application/UiApp/FrontPage.c
index bda5ff9..ad5af2c 100644
--- a/MdeModulePkg/Application/UiApp/FrontPage.c
+++ b/MdeModulePkg/Application/UiApp/FrontPage.c
@@ -1,7 +1,7 @@
 /** @file
   FrontPage routines to handle the callbacks and browser calls
 
-Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2017, 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
@@ -408,9 +408,16 @@ ConvertProcessorToString (
   DestMax = 0x20 / sizeof (CHAR16);
   StringBuffer = AllocateZeroPool (0x20);
   ASSERT (StringBuffer != NULL);
-  Index = UnicodeValueToString (StringBuffer, LEFT_JUSTIFY, FreqMhz / 1000, 3);
+  UnicodeValueToStringS (StringBuffer, sizeof (CHAR16) * DestMax, 
LEFT_JUSTIFY, FreqMhz / 1000, 3);
+  Index = StrnLenS (StringBuffer, DestMax);
   StrCatS (StringBuffer, DestMax, L".");
-  UnicodeValueToString (StringBuffer + Index + 1, PREFIX_ZERO, (FreqMhz % 
1000) / 10, 2);
+  UnicodeValueToStringS (
+StringBuffer + Index + 1,
+sizeof (CHAR16) * (DestMax - (Index + 1)),
+PREFIX_ZERO,
+(FreqMhz % 1000) / 10,
+2
+);
   StrCatS (StringBuffer, DestMax, L" GHz");
   *String = (CHAR16 *) StringBuffer;
   return ;
@@ -434,7 +441,7 @@ ConvertMemorySizeToString (
 
   StringBuffer = AllocateZeroPool (0x24);
   ASSERT (StringBuffer != NULL);
-  UnicodeValueToString (StringBuffer, LEFT_JUSTIFY, MemorySize, 10);
+  UnicodeValueToStringS (StringBuffer, 0x24, LEFT_JUSTIFY, MemorySize, 10);
   StrCatS (StringBuffer, 0x24 / sizeof (CHAR16), L" MB RAM");
 
   *String = (CHAR16 *) StringBuffer;
diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c
index dede4b3..b3cc3c8 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c
@@ -1,7 +1,7 @@
 /** @file
 Dynamically update the pages.
 
-Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2017, 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
@@ -734,11 +734,17 @@ UpdateConModePage (
 //
 // Build mode string Column x Row
 //
-UnicodeValueToString (ModeString, 0, Col, 0);
+UnicodeValueToStringS (ModeString, sizeof (ModeString), 0, Col, 0);
 PStr = [0];
 StrnCatS (PStr, ARRAY_SIZE (ModeString), L" x ", StrLen(L" x ") + 1);
 PStr = PStr + StrLen (PStr);
-UnicodeValueToString (PStr , 0, Row, 0);
+UnicodeValueToStringS (
+  PStr,
+  sizeof (ModeString) - ((UINTN)PStr - (UINTN)[0]),
+  0,
+  Row,
+  0
+  );
 
 ModeToken[Index] = HiiSetString (CallbackData->BmmHiiHandle, 0, 
ModeString, NULL);
 
diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c 
b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
index 0de4e3c..5098b70 100644
--- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
+++ 

[edk2] [PATCH 5/7] MdeModulePkg/PrintDxe: Handle the deprecation of [A|U]ValueToString

[Hao Wu]

To handle the deprecation of PrintLib APIs UnicodeValueToString and
AsciiValueToString by subsequent commits, the commit refines the logic for
the implemetation of the UnicodeValueToString and AsciiValueToString
services in EFI_PRINT2_PROTOCOL.

When the macro DISABLE_NEW_DEPRECATED_INTERFACES is defined (indicating
the deprecation of the PrintLib APIs), the above two services will ASSERT
and will return zero to reflect not being supported.

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Universal/PrintDxe/Print.c | 92 +++-
 1 file changed, 90 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/PrintDxe/Print.c 
b/MdeModulePkg/Universal/PrintDxe/Print.c
index 85bc724..8029836 100644
--- a/MdeModulePkg/Universal/PrintDxe/Print.c
+++ b/MdeModulePkg/Universal/PrintDxe/Print.c
@@ -20,6 +20,94 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 
+/**
+  Implementaion of the UnicodeValueToString service in EFI_PRINT2_PROTOCOL.
+
+  If the macro DISABLE_NEW_DEPRECATED_INTERFACES is defined, then ASSERT().
+
+  @param  Buffer  The pointer to the output buffer for the produced
+  Null-terminated Unicode string.
+  @param  Flags   The bitmask of flags that specify left justification, zero
+  pad, and commas.
+  @param  Value   The 64-bit signed value to convert to a string.
+  @param  Width   The maximum number of Unicode characters to place in Buffer,
+  not including the Null-terminator.
+
+  @return If the macro DISABLE_NEW_DEPRECATED_INTERFACES is defined, return 0.
+  Otherwise, return the number of Unicode characters in Buffer not
+  including the Null-terminator.
+
+**/
+UINTN
+EFIAPI
+PrintDxeUnicodeValueToString (
+  IN OUT CHAR16  *Buffer,
+  IN UINTN   Flags,
+  IN INT64   Value,
+  IN UINTN   Width
+  )
+{
+#ifdef DISABLE_NEW_DEPRECATED_INTERFACES
+  //
+  // If the macro DISABLE_NEW_DEPRECATED_INTERFACES is defined, then the
+  // PrintLib API UnicodeValueToString is already deprecated.
+  // In this case, ASSERT will be triggered and zero will be returned for the
+  // implementation of the UnicodeValueToString service in EFI_PRINT2_PROTOCOL
+  // to indicate that the service is no longer supported.
+  //
+  DEBUG ((DEBUG_ERROR, "PrintDxe: The UnicodeValueToString service in 
EFI_PRINT2_PROTOCOL is no longer supported for security reason.\n"));
+  DEBUG ((DEBUG_ERROR, "PrintDxe: Please consider using the 
UnicodeValueToStringS service in EFI_PRINT2S_PROTOCOL.\n"));
+  ASSERT (FALSE);
+  return 0;
+#else
+  return UnicodeValueToString (Buffer, Flags, Value, Width);
+#endif
+}
+
+/**
+  Implementaion of the AsciiValueToString service in EFI_PRINT2_PROTOCOL.
+
+  If the macro DISABLE_NEW_DEPRECATED_INTERFACES is defined, then ASSERT().
+
+  @param  Buffer  A pointer to the output buffer for the produced
+  Null-terminated ASCII string.
+  @param  Flags   The bitmask of flags that specify left justification, zero
+  pad, and commas.
+  @param  Value   The 64-bit signed value to convert to a string.
+  @param  Width   The maximum number of ASCII characters to place in Buffer,
+  not including the Null-terminator.
+
+  @return If the macro DISABLE_NEW_DEPRECATED_INTERFACES is defined, return 0.
+  Otherwise, return the number of ASCII characters in Buffer not
+  including the Null-terminator.
+
+**/
+UINTN
+EFIAPI
+PrintDxeAsciiValueToString (
+  OUT CHAR8  *Buffer,
+  IN  UINTN  Flags,
+  IN  INT64  Value,
+  IN  UINTN  Width
+  )
+{
+#ifdef DISABLE_NEW_DEPRECATED_INTERFACES
+  //
+  // If the macro DISABLE_NEW_DEPRECATED_INTERFACES is defined, then the
+  // PrintLib API AsciiValueToString is already deprecated.
+  // In this case, ASSERT will be triggered and zero will be returned for the
+  // implementation of the AsciiValueToString service in EFI_PRINT2_PROTOCOL
+  // to indicate that the service is no longer supported.
+  //
+  DEBUG ((DEBUG_ERROR, "PrintDxe: The AsciiValueToString service in 
EFI_PRINT2_PROTOCOL is no longer supported for security reason.\n"));
+  DEBUG ((DEBUG_ERROR, "PrintDxe: Please consider using the 
AsciiValueToStringS service in EFI_PRINT2S_PROTOCOL.\n"));
+  ASSERT (FALSE);
+  return 0;
+#else
+  return AsciiValueToString (Buffer, Flags, Value, Width);
+#endif
+}
+
 EFI_HANDLE  mPrintThunkHandle = NULL;
 
 CONST EFI_PRINT2_PROTOCOL mPrint2Protocol = {
@@ -27,12 +115,12 @@ CONST EFI_PRINT2_PROTOCOL mPrint2Protocol = {
   UnicodeSPrint,
   UnicodeBSPrintAsciiFormat,
   UnicodeSPrintAsciiFormat,
-  UnicodeValueToString,
+  PrintDxeUnicodeValueToString,
   AsciiBSPrint,
   AsciiSPrint,
   AsciiBSPrintUnicodeFormat,
   AsciiSPrintUnicodeFormat,
-  

[edk2] [PATCH 7/7] MdePkg/BasePrintLib: Add deprecated flag for APIs [A|U]ValueToString

[Hao Wu]

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdePkg/Include/Library/PrintLib.h  | 12 
 MdePkg/Library/BasePrintLib/PrintLib.c | 12 
 2 files changed, 24 insertions(+)

diff --git a/MdePkg/Include/Library/PrintLib.h 
b/MdePkg/Include/Library/PrintLib.h
index 8c11dab..9fe3609 100644
--- a/MdePkg/Include/Library/PrintLib.h
+++ b/MdePkg/Include/Library/PrintLib.h
@@ -491,7 +491,11 @@ UnicodeSPrintAsciiFormat (
   ...
   );
 
+#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
+
 /**
+  [ATTENTION] This function is deprecated for security reason.
+
   Converts a decimal value to a Null-terminated Unicode string.
   
   Converts the decimal number specified by Value to a Null-terminated Unicode 
@@ -541,6 +545,8 @@ UnicodeValueToString (
   IN UINTN   Width
   );
 
+#endif
+
 /**
   Converts a decimal value to a Null-terminated Unicode string.
 
@@ -882,7 +888,11 @@ AsciiSPrintUnicodeFormat (
   ...
   );
 
+#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
+
 /**
+  [ATTENTION] This function is deprecated for security reason.
+
   Converts a decimal value to a Null-terminated ASCII string.
   
   Converts the decimal number specified by Value to a Null-terminated ASCII 
string 
@@ -931,6 +941,8 @@ AsciiValueToString (
   IN  UINTN  Width
   );
 
+#endif
+
 /**
   Converts a decimal value to a Null-terminated Ascii string.
 
diff --git a/MdePkg/Library/BasePrintLib/PrintLib.c 
b/MdePkg/Library/BasePrintLib/PrintLib.c
index 221b52e..7453e95 100644
--- a/MdePkg/Library/BasePrintLib/PrintLib.c
+++ b/MdePkg/Library/BasePrintLib/PrintLib.c
@@ -349,7 +349,11 @@ UnicodeSPrintAsciiFormat (
   return NumberOfPrinted;
 }
 
+#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
+
 /**
+  [ATTENTION] This function is deprecated for security reason.
+
   Converts a decimal value to a Null-terminated Unicode string.
   
   Converts the decimal number specified by Value to a Null-terminated Unicode 
@@ -403,6 +407,8 @@ UnicodeValueToString (
   return BasePrintLibConvertValueToString ((CHAR8 *)Buffer, Flags, Value, 
Width, 2);
 }
 
+#endif
+
 /**
   Converts a decimal value to a Null-terminated Unicode string.
 
@@ -781,7 +787,11 @@ AsciiSPrintUnicodeFormat (
 }
 
 
+#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
+
 /**
+  [ATTENTION] This function is deprecated for security reason.
+
   Converts a decimal value to a Null-terminated ASCII string.
   
   Converts the decimal number specified by Value to a Null-terminated ASCII 
string 
@@ -833,6 +843,8 @@ AsciiValueToString (
   return BasePrintLibConvertValueToString (Buffer, Flags, Value, Width, 1);
 }
 
+#endif
+
 /**
   Converts a decimal value to a Null-terminated Ascii string.
 
-- 
1.9.5.msysgit.0

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

[edk2] [PATCH 6/7] MdeModulePkg/PrintLib: Add deprecated flag for APIs [A|U]ValueToString

[Hao Wu]

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c 
b/MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c
index 589d4db..434736f 100644
--- a/MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c
+++ b/MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c
@@ -598,7 +598,11 @@ UnicodeSPrintAsciiFormat (
   return NumberOfPrinted;
 }
 
+#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
+
 /**
+  [ATTENTION] This function is deprecated for security reason.
+
   Converts a decimal value to a Null-terminated Unicode string.
   
   Converts the decimal number specified by Value to a Null-terminated Unicode 
@@ -665,6 +669,8 @@ UnicodeValueToString (
   return StrnLenS (Buffer, BufferSize / sizeof (CHAR16));
 }
 
+#endif
+
 /**
   Converts a decimal value to a Null-terminated Unicode string.
 
@@ -1071,7 +1077,11 @@ AsciiSPrintUnicodeFormat (
 }
 
 
+#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
+
 /**
+  [ATTENTION] This function is deprecated for security reason.
+
   Converts a decimal value to a Null-terminated ASCII string.
   
   Converts the decimal number specified by Value to a Null-terminated ASCII 
string 
@@ -1137,6 +1147,8 @@ AsciiValueToString (
   return AsciiStrnLenS (Buffer, BufferSize / sizeof (CHAR8));
 }
 
+#endif
+
 /**
   Converts a decimal value to a Null-terminated Ascii string.
 
-- 
1.9.5.msysgit.0

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

[edk2] [PATCH 1/7] IntelFrameworkModulePkg: Replace [Ascii|Unicode]ValueToString

[Hao Wu]

It is the follow up of commits 51f0ceb..9e32e97 to replace
AsciiValueToString/UnicodeValueToString with
AsciiValueToStringS/UnicodeValueToStringS.

Cc: Jiewen Yao 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c | 12 
+---
 IntelFrameworkModulePkg/Universal/BdsDxe/DeviceMngr/DeviceManager.c | 20 
+---
 IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c| 15 
+++
 IntelFrameworkModulePkg/Universal/BdsDxe/MemoryTest.c   |  6 +++---
 4 files changed, 40 insertions(+), 13 deletions(-)

diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c 
b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c
index a2e38d2..bdf2614 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c
@@ -1,7 +1,7 @@
 /** @file
 Dynamically update the pages.
 
-Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2017, 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
@@ -844,11 +844,17 @@ UpdateConModePage (
 //
 // Build mode string Column x Row
 //
-UnicodeValueToString (ModeString, 0, Col, 0);
+UnicodeValueToStringS (ModeString, sizeof (ModeString), 0, Col, 0);
 PStr = [0];
 StrCatS (PStr, ARRAY_SIZE (ModeString), L" x ");
 PStr = PStr + StrLen (PStr);
-UnicodeValueToString (PStr , 0, Row, 0);
+UnicodeValueToStringS (
+  PStr,
+  sizeof (ModeString) - ((UINTN)PStr - (UINTN)[0]),
+  0,
+  Row,
+  0
+  );
 
 ModeToken[Index] = HiiSetString (CallbackData->BmmHiiHandle, 0, 
ModeString, NULL);
 
diff --git 
a/IntelFrameworkModulePkg/Universal/BdsDxe/DeviceMngr/DeviceManager.c 
b/IntelFrameworkModulePkg/Universal/BdsDxe/DeviceMngr/DeviceManager.c
index af2b18a..125c49d 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/DeviceMngr/DeviceManager.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/DeviceMngr/DeviceManager.c
@@ -1,7 +1,7 @@
 /** @file
   The platform device manager reference implementation
 
-Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2017, 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
@@ -388,7 +388,14 @@ GetMacAddressString(
   //
   HwAddress = >MacAddress.Addr[0];
   for (Index = 0; Index < HwAddressSize; Index++) {
-String += UnicodeValueToString (String, PREFIX_ZERO | RADIX_HEX, 
*(HwAddress++), 2);
+UnicodeValueToStringS (
+  String,
+  BufferLen - ((UINTN)String - (UINTN)*PBuffer),
+  PREFIX_ZERO | RADIX_HEX,
+  *(HwAddress++),
+  2
+  );
+String += StrnLenS (String, (BufferLen - ((UINTN)String - 
(UINTN)*PBuffer)) / sizeof (CHAR16));
 if (Index < HwAddressSize - 1) {
   *String++ = L':';
 }
@@ -408,7 +415,14 @@ GetMacAddressString(
 
   if (VlanId != 0) {
 *String++ = L'\\';
-String += UnicodeValueToString (String, PREFIX_ZERO | RADIX_HEX, VlanId, 
4);
+UnicodeValueToStringS (
+  String,
+  BufferLen - ((UINTN)String - (UINTN)*PBuffer),
+  PREFIX_ZERO | RADIX_HEX,
+  VlanId,
+  4
+  );
+String += StrnLenS (String, (BufferLen - ((UINTN)String - 
(UINTN)*PBuffer)) / sizeof (CHAR16));
   }
 
   //
diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c 
b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
index c771974..ec91422 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
@@ -1,7 +1,7 @@
 /** @file
   FrontPage routines to handle the callbacks and browser calls
 
-Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2017, 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
@@ -629,9 +629,16 @@ ConvertProcessorToString (
 
   StringBuffer = AllocateZeroPool (0x20);
   ASSERT (StringBuffer != NULL);
-  Index = UnicodeValueToString (StringBuffer, LEFT_JUSTIFY, FreqMhz / 1000, 3);
+  UnicodeValueToStringS (StringBuffer, 0x20, LEFT_JUSTIFY, FreqMhz / 1000, 3);
+  Index = StrnLenS (StringBuffer, 0x20 / sizeof (CHAR16));
   StrCatS (StringBuffer, 0x20 / sizeof (CHAR16), L".");
-  UnicodeValueToString 

[edk2] [PATCH 0/7] Mark [Ascii|Unicode]ValueToString as deprecated

[Hao Wu]

This patch series cleans up the usage of the following 2 PrintLib APIs:
UnicodeValueToString & AsciiValueToString

and replaces them with:
UnicodeValueToStringS & AsciiValueToStringS

The series also marks [Ascii|Unicode]ValueToString with the macro
'DISABLE_NEW_DEPRECATED_INTERFACES', indicating they are deprecated.

Cc: Jiewen Yao 

Hao Wu (7):
  IntelFrameworkModulePkg: Replace [Ascii|Unicode]ValueToString
  MdeModulePkg: Replace [Ascii|Unicode]ValueToString
  Nt32Pkg: Replace [Ascii|Unicode]ValueToString
  SignedCapsulePkg: Replace [Ascii|Unicode]ValueToString
  MdeModulePkg/PrintDxe: Handle the deprecation of [A|U]ValueToString
  MdeModulePkg/PrintLib: Add deprecated flag for APIs [A|U]ValueToString
  MdePkg/BasePrintLib: Add deprecated flag for APIs [A|U]ValueToString

 IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/UpdatePage.c   | 12 ++-
 IntelFrameworkModulePkg/Universal/BdsDxe/DeviceMngr/DeviceManager.c   | 20 
-
 IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c  | 15 +++-
 IntelFrameworkModulePkg/Universal/BdsDxe/MemoryTest.c |  6 +-
 MdeModulePkg/Application/UiApp/FrontPage.c| 15 +++-
 MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c | 12 ++-
 MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c   | 20 
-
 MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleReportLib.c   | 10 ++-
 MdeModulePkg/Library/DxeNetLib/DxeNetLib.c| 24 
-
 MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c | 12 +++
 MdeModulePkg/Library/UefiHiiLib/HiiLib.c  | 29 
+-
 MdeModulePkg/Universal/CapsulePei/UefiCapsule.c   | 18 +++-
 MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c | 10 ++-
 MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c | 37 
+---
 MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c  | 29 
+-
 MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c | 47 
--
 MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigImpl.c | 14 ++-
 MdeModulePkg/Universal/PrintDxe/Print.c   | 92 
+++-
 MdeModulePkg/Universal/SetupBrowserDxe/Expression.c   | 11 ++-
 MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c |  4 +-
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.c| 38 
++--
 MdePkg/Include/Library/PrintLib.h | 12 +++
 MdePkg/Library/BasePrintLib/PrintLib.c| 12 +++
 Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c   |  6 +-
 SignedCapsulePkg/Universal/RecoveryModuleLoadPei/ParseConfigProfile.c | 10 ++-
 SignedCapsulePkg/Universal/SystemFirmwareUpdate/ParseConfigProfile.c  | 10 ++-
 26 files changed, 443 insertions(+), 82 deletions(-)

-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH v2 1/2] UefiCpuPkg/CpuDxe: Copy two functions from PciHostBridge

[Laszlo Ersek]

I have two suggestions for this patch:

On 02/21/17 04:08, Jeff Fan wrote:
> Copy AddMemoryMappedIoSpace() and AddMemoryMappedIoSpace() from
> MdeModulePkg\Bus\Pci\PciHostBridgeDxe\PciHostBridge.c.

(1) One of the two "AddMemoryMappedIoSpace" strings should be replaced
with "IntersectMemoryDescriptor".

This can be done when you commit / push the patch; no need to repost
just because of it.

(2) This is more of a "followup" suggestion: since this is new code, I
recommend that the EFI_D_ macros be replced with DEBUG_ macros.

However, I see value in keeping the first patch as a pristine copy from
the PciHostBridgeDxe driver, so I don't recommend doing the above change
in patch #1. I think it can be patch #3, or a completely separate patch
(later).

Series
Reviewed-by: Laszlo Ersek 
Regression-tested-by: Laszlo Ersek 

Thanks!
Laszlo

> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=390
> 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Feng Tian 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan 
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.c | 148 
> +
>  1 file changed, 148 insertions(+)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
> index 9fb6d76..925c50f 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
> @@ -887,6 +887,154 @@ IdleLoopEventCallback (
>CpuSleep ();
>  }
>  
> +/**
> +  Ensure the compatibility of a memory space descriptor with the MMIO 
> aperture.
> +
> +  The memory space descriptor can come from the GCD memory space map, or it 
> can
> +  represent a gap between two neighboring memory space descriptors. In the
> +  latter case, the GcdMemoryType field is expected to be
> +  EfiGcdMemoryTypeNonExistent.
> +
> +  If the memory space descriptor already has type
> +  EfiGcdMemoryTypeMemoryMappedIo, and its capabilities are a superset of the
> +  required capabilities, then no action is taken -- it is by definition
> +  compatible with the aperture.
> +
> +  Otherwise, the intersection of the memory space descriptor is calculated 
> with
> +  the aperture. If the intersection is the empty set (no overlap), no action 
> is
> +  taken; the memory space descriptor is compatible with the aperture.
> +
> +  Otherwise, the type of the descriptor is investigated again. If the type is
> +  EfiGcdMemoryTypeNonExistent (representing a gap, or a genuine descriptor 
> with
> +  such a type), then an attempt is made to add the intersection as MMIO space
> +  to the GCD memory space map, with the specified capabilities. This ensures
> +  continuity for the aperture, and the descriptor is deemed compatible with 
> the
> +  aperture.
> +
> +  Otherwise, the memory space descriptor is incompatible with the MMIO
> +  aperture.
> +
> +  @param[in] Base Base address of the aperture.
> +  @param[in] Length   Length of the aperture.
> +  @param[in] Capabilities Capabilities required by the aperture.
> +  @param[in] Descriptor   The descriptor to ensure compatibility with the
> +  aperture for.
> +
> +  @retval EFI_SUCCESSThe descriptor is compatible. The GCD memory
> + space map may have been updated, for
> + continuity within the aperture.
> +  @retval EFI_INVALID_PARAMETER  The descriptor is incompatible.
> +  @returnError codes from gDS->AddMemorySpace().
> +**/
> +EFI_STATUS
> +IntersectMemoryDescriptor (
> +  IN  UINT64Base,
> +  IN  UINT64Length,
> +  IN  UINT64Capabilities,
> +  IN  CONST EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Descriptor
> +  )
> +{
> +  UINT64IntersectionBase;
> +  UINT64IntersectionEnd;
> +  EFI_STATUSStatus;
> +
> +  if (Descriptor->GcdMemoryType == EfiGcdMemoryTypeMemoryMappedIo &&
> +  (Descriptor->Capabilities & Capabilities) == Capabilities) {
> +return EFI_SUCCESS;
> +  }
> +
> +  IntersectionBase = MAX (Base, Descriptor->BaseAddress);
> +  IntersectionEnd = MIN (Base + Length,
> +  Descriptor->BaseAddress + Descriptor->Length);
> +  if (IntersectionBase >= IntersectionEnd) {
> +//
> +// The descriptor and the aperture don't overlap.
> +//
> +return EFI_SUCCESS;
> +  }
> +
> +  if (Descriptor->GcdMemoryType == EfiGcdMemoryTypeNonExistent) {
> +Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo,
> +IntersectionBase, IntersectionEnd - IntersectionBase,
> +Capabilities);
> +
> +DEBUG ((EFI_ERROR (Status) ? EFI_D_ERROR : EFI_D_VERBOSE,
> +  "%a: %a: add [%Lx, 

Re: [edk2] Testing SMM with QEMU, KVM and libvirt

[Laszlo Ersek]

On 02/21/17 10:22, Shi, Steven wrote:
> Hi Laszlo,
> I wonder if you could offer a Ubuntu version wiki for the
> Testing-SMM-with-QEMU,-KVM-and-libvirt?

Sorry, I can't do that.

To give you a retrospective on the current article (which targets
Fedora), writing and testing that article took ~14 hours, on an
operating system that I'm both familiar with and can readily install in
our internal server farm (called "Beaker").

My method was to start with a wiped-clean physical machine, install a
fresh, clean Fedora system, and build it all up from there. I wanted to
make sure that all missing dependencies would be thrown in my face, so I
could explicitly document them for readers.

This approach paid off very well (it caught a whole lot of dependencies
that I "thought" would be available by default, but weren't!), but it
was also the *primary* time sink while writing the article.

"Porting" the article to another Linux distribution would mean an almost
complete rewrite. The package names are different, the package contents
are different, the package inter-dependencies are different, the
virtualization tools may have different versions available, the generic
tools may be different, and so on.

> I'm trying to port your
> steps to my Ubuntu 16.04, but meet lots of troubles. The Ubuntu
> apt-get virsh version is too old to support smm feature in your
> ovmf.fedora.q35.template,

That's *exactly* my point.

> and I have to build the new version libvirt
> by myself. I meet lots of failures when configure the new version
> virsh, and wonder if you could help.

Sorry, I don't have time for that. I don't know Ubuntu at all, have no
contact to Ubuntu developers, and cannot even auto-install Ubuntu easily
on a headless server in our internal server pool.

Frankly, one goal of using Fedora 25 for the host operating system was
*exactly* that the user could avoid this kind of struggle with the
virtualization toolstack, and they could focus on rebuilding *only* what
was unavoidable.

(It is bad enough that at the moment I must have instructions in there
for building QEMU from source -- once QEMU 2.9 is released and Fedora 25
picks it up, I think I will go ahead and replace that section of the
article, with a simple package installation command. I'll also update
references elsewhere, such as in the domain templates.)

So, unfortunately, what you are asking for is a complete rewrite of the
article, for Ubuntu, which I don't know and have no access to, in the
isolated server environment that is necessary for writing and testing
such an article.

I'm not trying to "push" Fedora with this -- a fresh Ubuntu release
should be entirely suitable for this I *guess*, but the devil is in the
details, and you'll need an Ubuntu person, with a corporate(-like)
Ubuntu environment, to write that article for you.

I do confirm that I intend to support the Fedora setup with high
priority, so if you have questions about that, I'll do my best to answer.

Thanks,
Laszlo


> 
> 
> 
> Steven Shi
> Intel\SSG\STO\UEFI Firmware
> 
> Tel: +86 021-61166522
> iNet: 821-6522
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Tuesday, February 7, 2017 9:07 PM
>> To: edk2-devel-01 
>> Cc: Tian, Feng ; Justen, Jordan L
>> ; Yao, Jiewen ; Kinney,
>> Michael D ; Fan, Jeff ; Zeng,
>> Star 
>> Subject: [edk2] Testing SMM with QEMU, KVM and libvirt
>>
>> Hi,
>>
>> I've added the following article to the TianoCore wiki:
>>
>> https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-
>> QEMU,-KVM-and-libvirt
>>
>> It should help both Windows and Linux desktop users build a KVM test
>> machine / environment that closely resembles mine. Such an environment
>> is useful for testing and regression-testing new MP and SMM features and
>> bugfixes.
>>
>> The initial setup is not short, but once you got it up and running, it's
>> very simple to rebuild OVMF with the edk2 changes, install the firmware
>> binary in the right place (see the article) and then click the Play
>> button on the Fedora 25 and Windows 10 guests, to see the changes in action.
>>
>> If you have smaller updates or structural reorgs for the document,
>> there's no need to ask me, just go ahead and do them.
>>
>> If some significant information is missing that you'd like me to add, I
>> think I'd prefer new TianoCore BZs at this time (Product: Tianocore
>> Feature Requests, Component: Web Content, Assignee: yours truly). I
>> don't know when I'll have time again to dig into this.
>>
>> Sorry if I forgot someone off the CC list.
>>
>> Thanks!
>> Laszlo
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: add error check for Macro usage in the INF file

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Zhu, Yonghong 
Sent: Tuesday, February 21, 2017 9:18 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: [Patch] BaseTools: add error check for Macro usage in the INF file

Use of MACRO statements in the EDK II INF files is limited to local
usage only; global or external macros are not permitted. This patch
add the check for not defined macros.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Workspace/MetaFileParser.py| 9 -
 BaseTools/Source/Python/Workspace/WorkspaceDatabase.py | 4 +++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/MetaFileParser.py 
b/BaseTools/Source/Python/Workspace/MetaFileParser.py
index 1a5fdf5..37a7f5d 100644
--- a/BaseTools/Source/Python/Workspace/MetaFileParser.py
+++ b/BaseTools/Source/Python/Workspace/MetaFileParser.py
@@ -1,9 +1,9 @@
 ## @file
 # This file is used to parse meta files
 #
-# Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
+# Copyright (c) 2008 - 2017, Intel Corporation. All rights reserved.
 # (C) Copyright 2015-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
 # which accompanies this distribution.  The full text of the license may be 
found at
 # http://opensource.org/licenses/bsd-license.php
@@ -349,10 +349,17 @@ class MetaFileParser(object):
 EdkLogger.error('Parser', FORMAT_INVALID, "No value specified",
 ExtraData=self._CurrentLine, File=self.MetaFile, 
Line=self._LineIndex + 1)
 
 self._ValueList = [ReplaceMacro(Value, self._Macros) for Value in 
self._ValueList]
 Name, Value = self._ValueList[1], self._ValueList[2]
+MacroUsed = GlobalData.gMacroRefPattern.findall(Value)
+if len(MacroUsed) != 0:
+for Macro in MacroUsed:
+if Macro in GlobalData.gGlobalDefines:
+EdkLogger.error("Parser", FORMAT_INVALID, "Global macro %s 
is not permitted." % (Macro), ExtraData=self._CurrentLine, File=self.MetaFile, 
Line=self._LineIndex + 1)
+else:
+EdkLogger.error("Parser", FORMAT_INVALID, "%s not defined" % 
(Macro), ExtraData=self._CurrentLine, File=self.MetaFile, Line=self._LineIndex 
+ 1)
 # Sometimes, we need to make differences between EDK and EDK2 modules 
 if Name == 'INF_VERSION':
 if re.match(r'0[xX][\da-f-A-F]{5,8}', Value):
 self._Version = int(Value, 0)   
 elif re.match(r'\d+\.\d+', Value):
diff --git a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py 
b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
index e7bc87d..0686721 100644
--- a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
+++ b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
@@ -1,9 +1,9 @@
 ## @file
 # This file is used to create a database used by build tool
 #
-# Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
+# Copyright (c) 2008 - 2017, 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
 # which accompanies this distribution.  The full text of the license may be 
found at
 # http://opensource.org/licenses/bsd-license.php
@@ -1828,10 +1828,12 @@ class InfBuildData(ModuleBuildClassObject):
 self.__Macros = {}
 # EDK_GLOBAL defined macros can be applied to EDK module
 if self.AutoGenVersion < 0x00010005:
 self.__Macros.update(GlobalData.gEdkGlobal)
 self.__Macros.update(GlobalData.gGlobalDefines)
+else:
+self.__Macros.update(self.Defines)
 return self.__Macros
 
 ## Get architecture
 def _GetArch(self):
 return self._Arch
-- 
2.6.1.windows.1

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

Re: [edk2] Testing SMM with QEMU, KVM and libvirt

[Shi, Steven]

Hi Laszlo,
I wonder if you could offer a Ubuntu version wiki for the 
Testing-SMM-with-QEMU,-KVM-and-libvirt?  I'm trying to port your steps to my 
Ubuntu 16.04, but meet lots of troubles. The Ubuntu apt-get virsh version is 
too old to support smm feature in your ovmf.fedora.q35.template, and I have to 
build the new version libvirt by myself. I meet lots of failures when configure 
the new version virsh, and wonder if you could help. 



Steven Shi
Intel\SSG\STO\UEFI Firmware

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


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Tuesday, February 7, 2017 9:07 PM
> To: edk2-devel-01 
> Cc: Tian, Feng ; Justen, Jordan L
> ; Yao, Jiewen ; Kinney,
> Michael D ; Fan, Jeff ; Zeng,
> Star 
> Subject: [edk2] Testing SMM with QEMU, KVM and libvirt
> 
> Hi,
> 
> I've added the following article to the TianoCore wiki:
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-
> QEMU,-KVM-and-libvirt
> 
> It should help both Windows and Linux desktop users build a KVM test
> machine / environment that closely resembles mine. Such an environment
> is useful for testing and regression-testing new MP and SMM features and
> bugfixes.
> 
> The initial setup is not short, but once you got it up and running, it's
> very simple to rebuild OVMF with the edk2 changes, install the firmware
> binary in the right place (see the article) and then click the Play
> button on the Fedora 25 and Windows 10 guests, to see the changes in action.
> 
> If you have smaller updates or structural reorgs for the document,
> there's no need to ask me, just go ahead and do them.
> 
> If some significant information is missing that you'd like me to add, I
> think I'd prefer new TianoCore BZs at this time (Product: Tianocore
> Feature Requests, Component: Web Content, Assignee: yours truly). I
> don't know when I'll have time again to dig into this.
> 
> Sorry if I forgot someone off the CC list.
> 
> Thanks!
> Laszlo
> ___
> 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 V4 0/3] DXE Memory Protection

[Yao, Jiewen]

No problem. ☺

I appreciate your help to confirm it working on AARCH64.

Thank you
Yao Jiewen

From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Tuesday, February 21, 2017 4:36 PM
To: Yao, Jiewen ; Leif Lindholm 
Cc: edk2-devel@lists.01.org; Fan, Jeff ; Kinney, Michael D 
; Zeng, Star ; Tian, Feng 

Subject: Re: [PATCH V4 0/3] DXE Memory Protection

On 21 February 2017 at 06:57, Jiewen Yao 
> wrote:
>  V4 
> 1) Remove ARM patch. (Which was already submitted by Ard Biesheuvel in 
> another series)
> 2) Unprotect RT image at ExitBootServices (feedback from Ard Biesheuvel)
> 3) Round up the ImageSize on protection (feedback from Ard Biesheuvel)
>

Hello Jiewen,

This works fine now on AARCH64.

Tested-by: Ard Biesheuvel 
>

Could you please wait a little bit before merging this? Leif and I
need to get the AARCH64 prepatory patches merged first, but I am
hoping to do that today.

Thanks,
Ard.

>  V3 
> 1) Add PCD for policy control (feedback from Ard Biesheuvel)
> (Discussed with Mike Kinney)
> +  #BIT0   - Image from unknown device. 
> +  #BIT1   - Image from firmware volume.
> +  # @Prompt Set image protection policy.
> +  # @ValidRange 0x8002 | 0x - 0x001F
> +  
> gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy|0x0002|UINT32|0x1047
>
> 2) Remove unused function in CpuDxe.(feedback from Liming Gao)
> 3) Add commit log on link option assumption (feedback from Feng Tian)
> 4) Rename file PageTableLib.h/.c to CpuPageTable.h/.c file (from Jeff Fan)
> 5) Remove multi-entrypoint usage (from Liming Gao/Mike Kinney)
>
>  V2 
> 1) Clean up ArmPkg, (feedback from Leif Lindholm)
>
>  V1 
> This series patch provides capability to protect PE/COFF image
> in DXE memory.
> If the UEFI image is page aligned, the image code section is set to read
> only and the image data section is set to non-executable.
>
> The DxeCore calls CpuArchProtocol->SetMemoryAttributes() to protect
> the image.
>
> Tested platform: NT32/Quark IA32/OVMF IA32/OVMF IA32X64/Intel internal X64/
> Tested OS: UEFI Win10, UEFI Ubuntu 16.04.
>
> Untested platform: ARM/AARCH64.
> Can ARM/AARCH64 owner help to take a look and try the ARM platform?
>
>
> Cc: Jeff Fan >
> Cc: Michael Kinney 
> >
> Cc: Leif Lindholm >
> Cc: Ard Biesheuvel 
> >
> Cc: Star Zeng >
> Cc: Feng Tian >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao >
>
>
> Jiewen Yao (3):
>   UefiCpuPkg/CpuDxe: Add memory attribute setting.
>   MdeModulePkg/dec: add PcdImageProtectionPolicy.
>   MdeModulePkg/DxeCore: Add UEFI image protection.
>
>  MdeModulePkg/Core/Dxe/DxeMain.h   |  61 ++
>  MdeModulePkg/Core/Dxe/DxeMain.inf |   5 +-
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c   |   5 +-
>  MdeModulePkg/Core/Dxe/Image/Image.c   |   7 +-
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 769 +++
>  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c  |  24 +-
>  MdeModulePkg/MdeModulePkg.dec |  10 +
>  UefiCpuPkg/CpuDxe/CpuDxe.c| 141 ++--
>  UefiCpuPkg/CpuDxe/CpuDxe.inf  |   5 +-
>  UefiCpuPkg/CpuDxe/CpuPageTable.c  | 779 
>  UefiCpuPkg/CpuDxe/CpuPageTable.h  | 113 +++
>  11 files changed, 1832 insertions(+), 87 deletions(-)
>  create mode 100644 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
>  create mode 100644 UefiCpuPkg/CpuDxe/CpuPageTable.c
>  create mode 100644 UefiCpuPkg/CpuDxe/CpuPageTable.h
>
> --
> 2.7.4.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V4 0/3] DXE Memory Protection

[Ard Biesheuvel]

On 21 February 2017 at 06:57, Jiewen Yao  wrote:
>  V4 
> 1) Remove ARM patch. (Which was already submitted by Ard Biesheuvel in 
> another series)
> 2) Unprotect RT image at ExitBootServices (feedback from Ard Biesheuvel)
> 3) Round up the ImageSize on protection (feedback from Ard Biesheuvel)
>

Hello Jiewen,

This works fine now on AARCH64.

Tested-by: Ard Biesheuvel 

Could you please wait a little bit before merging this? Leif and I
need to get the AARCH64 prepatory patches merged first, but I am
hoping to do that today.

Thanks,
Ard.

>  V3 
> 1) Add PCD for policy control (feedback from Ard Biesheuvel)
> (Discussed with Mike Kinney)
> +  #BIT0   - Image from unknown device. 
> +  #BIT1   - Image from firmware volume.
> +  # @Prompt Set image protection policy.
> +  # @ValidRange 0x8002 | 0x - 0x001F
> +  
> gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy|0x0002|UINT32|0x1047
>
> 2) Remove unused function in CpuDxe.(feedback from Liming Gao)
> 3) Add commit log on link option assumption (feedback from Feng Tian)
> 4) Rename file PageTableLib.h/.c to CpuPageTable.h/.c file (from Jeff Fan)
> 5) Remove multi-entrypoint usage (from Liming Gao/Mike Kinney)
>
>  V2 
> 1) Clean up ArmPkg, (feedback from Leif Lindholm)
>
>  V1 
> This series patch provides capability to protect PE/COFF image
> in DXE memory.
> If the UEFI image is page aligned, the image code section is set to read
> only and the image data section is set to non-executable.
>
> The DxeCore calls CpuArchProtocol->SetMemoryAttributes() to protect
> the image.
>
> Tested platform: NT32/Quark IA32/OVMF IA32/OVMF IA32X64/Intel internal X64/
> Tested OS: UEFI Win10, UEFI Ubuntu 16.04.
>
> Untested platform: ARM/AARCH64.
> Can ARM/AARCH64 owner help to take a look and try the ARM platform?
>
>
> Cc: Jeff Fan 
> Cc: Michael Kinney 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Star Zeng 
> Cc: Feng Tian 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
>
>
> Jiewen Yao (3):
>   UefiCpuPkg/CpuDxe: Add memory attribute setting.
>   MdeModulePkg/dec: add PcdImageProtectionPolicy.
>   MdeModulePkg/DxeCore: Add UEFI image protection.
>
>  MdeModulePkg/Core/Dxe/DxeMain.h   |  61 ++
>  MdeModulePkg/Core/Dxe/DxeMain.inf |   5 +-
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c   |   5 +-
>  MdeModulePkg/Core/Dxe/Image/Image.c   |   7 +-
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 769 +++
>  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c  |  24 +-
>  MdeModulePkg/MdeModulePkg.dec |  10 +
>  UefiCpuPkg/CpuDxe/CpuDxe.c| 141 ++--
>  UefiCpuPkg/CpuDxe/CpuDxe.inf  |   5 +-
>  UefiCpuPkg/CpuDxe/CpuPageTable.c  | 779 
>  UefiCpuPkg/CpuDxe/CpuPageTable.h  | 113 +++
>  11 files changed, 1832 insertions(+), 87 deletions(-)
>  create mode 100644 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
>  create mode 100644 UefiCpuPkg/CpuDxe/CpuPageTable.c
>  create mode 100644 UefiCpuPkg/CpuDxe/CpuPageTable.h
>
> --
> 2.7.4.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Add Local APIC memory mapped space in gDS

[Laszlo Ersek]

On 02/21/17 02:33, Fan, Jeff wrote:
> Laszlo,
> 
> I added my feedback as below. Thanks!
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Monday, February 20, 2017 5:11 PM
> To: Fan, Jeff; edk2-de...@ml01.01.org
> Cc: Kinney, Michael D; Tian, Feng; Yao, Jiewen
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Add Local APIC memory mapped 
> space in gDS
> 
> Hi Jeff,
> 
> On 02/20/17 09:40, Jeff Fan wrote:
>> Local APIC memory mapped space should be added into gDS and be allocated.
>> Otherwise, UEFI firmware cannot get correct memory map for it. For 
>> example, SMM profile feature needs to get the completed MMIO map to protect 
>> them.
>>
>> https://bugzilla.tianocore.org/show_bug.cgi?id=390
>>
>> Cc: Jiewen Yao 
>> Cc: Feng Tian 
>> Cc: Michael D Kinney 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Jeff Fan 
>> ---
>>  UefiCpuPkg/CpuDxe/CpuDxe.c | 39 
>> +++
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c 
>> index 9fb6d76..71a08cd 100644
>> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
>> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
>> @@ -887,6 +887,40 @@ IdleLoopEventCallback (
>>CpuSleep ();
>>  }
>>  
>> +/**
>> +  Add and allocate CPU local APIC memory mapped space. 
>> +
>> +  @param[in]ImageHandle Image handle this driver.
>> +
>> +**/
>> +VOID
>> +AddLocalApicMemorySpace (
>> +  IN EFI_HANDLE   ImageHandle
>> +  )
>> +{
>> +  EFI_STATUS  Status;
>> +  EFI_PHYSICAL_ADDRESSBaseAddress;
>> +
>> +  BaseAddress = (EFI_PHYSICAL_ADDRESS) GetLocalApicBaseAddress ();  
>> + Status = gDS->AddMemorySpace (
>> +  EfiGcdMemoryTypeMemoryMappedIo, 
>> +  BaseAddress,
>> +  SIZE_4KB,
>> +  EFI_MEMORY_UC
>> +  );
>> +  ASSERT_EFI_ERROR (Status);
> 
> (1) This would break OVMF:
> 
>> Loading driver at 0x0007F51 EntryPoint=0x0007F51027B CpuDxe.efi
>> InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 7EE08498
>> InstallProtocolInterface: [EfiCpuArchProtocol] 7F522480
>>   Flushing GCD
>>   Flushing GCD
>>   Flushing GCD
>>   Flushing GCD
>>   Flushing GCD
>>   Flushing GCD
>>   Flushing GCD
>>   Flushing GCD
>>   Flushing GCD
>>   Flushing GCD
>>   Flushing GCD
>>   Flushing GCD
>>
>> ASSERT_EFI_ERROR (Status = Access Denied) ASSERT 
>> .../UefiCpuPkg/CpuDxe/CpuDxe.c(891): !EFI_ERROR (Status)
> 
> The reason for the assertion failure is that we add an uncacheable MMIO 
> resource descriptor HOB for the LAPIC range earlier, in OvmfPkg/PlatformPei. 
> When DXE starts up, it initializes the GCD memory space accordingly, hence 
> the above addition failure.
> 
> There was a similar issue in PciHostBridgeDxe: originally it tried to add 
> uncacheable MMIO space for the PCI bridges' apertures, unconditionally. The 
> solution was to check the GCD memory space map, and:
> - for any existing, overlapping entries, check if their attributes were 
> compatible with UC,
> - missing gaps were filled with new additions.
> 
> Please see commit 6474f1f156ee ("MdeModulePkg/PciHostBridge: Don't assume 
> resources are fully NonExistent", 2016-02-25).
> [Jeff] I agree. Platform Pei could use resource HOB to declare this range. I 
> may sync the code from 6474f1f156ee to CpuDxe.

Thanks for considering that!

> (2) After the memory space addition, the allocation should be attempted, I 
> agree. But for that too, if it fails, that shouldn't be a fatal error.
> [Jeff] Actually, I don't think there is other module(except for Cpu Driver) 
> allocating such range. If other module does it, we need to think if it does 
> make sense and how to fix it.

I wonder if it makes sense for CpuDxe to "own" the LAPIC address range.
If CpuDxe can be said to "own" the LAPIC, then allocating the range in
CpuDxe certainly makes sense. However, given that LocalApicLib is a
widely usable (and widely used) library class, I wonder if such an
"ownership" can be established.

... Either way, I think enforcing success for the MMIO range allocation
is much less problematic than enforcing success for the MMIO range
addition. So, from an OVMF platform perspective at least, I guess the
second ASSERT_EFI_ERROR() might even stay as-is.

Thank you!
Laszlo

> 
>> +
>> +  Status = gDS->AllocateMemorySpace (
>> +  EfiGcdAllocateAddress,
>> +  EfiGcdMemoryTypeMemoryMappedIo,
>> +  0,
>> +  SIZE_4KB,
>> +  ,
>> +  ImageHandle,
>> +  NULL
>> +  );
>> +  ASSERT_EFI_ERROR (Status);
>> +}
>>  
>>  /**
>>Initialize the state information for the CPU Architectural Protocol.
>> @@ -947,6 +981,11 @@ InitializeCpu (
>>RefreshGcdMemoryAttributes ();
>>  
>>//
>> +  // Add and 

Re: [edk2] [PATCH] SecurityPkg/TpmCommandLib: Add Tpm2ReadPublic.

[Zhang, Chao B]

Reviewed-by: Chao Zhang 

-Original Message-
From: Yao, Jiewen 
Sent: Thursday, February 9, 2017 11:52 PM
To: edk2-devel@lists.01.org
Cc: Zhang, Chao B ; Long, Qin ; 
Yao, Jiewen 
Subject: [PATCH] SecurityPkg/TpmCommandLib: Add Tpm2ReadPublic.

Cc: Chao Zhang 
Cc: Long Qin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao Jiewen 
---
 SecurityPkg/Include/Library/Tpm2CommandLib.h  |  22 +-
 SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf |   3 +-
 SecurityPkg/Library/Tpm2CommandLib/Tpm2Object.c   | 346 

 3 files changed, 369 insertions(+), 2 deletions(-)

diff --git a/SecurityPkg/Include/Library/Tpm2CommandLib.h 
b/SecurityPkg/Include/Library/Tpm2CommandLib.h
index f7a04f2..80ada73 100644
--- a/SecurityPkg/Include/Library/Tpm2CommandLib.h
+++ b/SecurityPkg/Include/Library/Tpm2CommandLib.h
@@ -1,7 +1,7 @@
 /** @file
   This library is used by other modules to send TPM2 command.
 
-Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved. 
+Copyright (c) 2013 - 2017, 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 @@ -959,6 +959,26 
@@ Tpm2PolicyGetDigest (
  OUT  TPM2B_DIGEST  *PolicyHash
   );
 
+/**
+  This command allows access to the public area of a loaded object.
+
+  @param[in]  ObjectHandleTPM handle of an object
+  @param[out] OutPublic   Structure containing the public area of 
an object
+  @param[out] NameName of the object
+  @param[out] QualifiedName   The Qualified Name of the object
+
+  @retval EFI_SUCCESS  Operation completed successfully.
+  @retval EFI_DEVICE_ERROR Unexpected device behavior.
+**/
+EFI_STATUS
+EFIAPI
+Tpm2ReadPublic (
+  IN  TPMI_DH_OBJECTObjectHandle,
+  OUT TPM2B_PUBLIC  *OutPublic,
+  OUT TPM2B_NAME*Name,
+  OUT TPM2B_NAME*QualifiedName
+  );
+
 //
 // Help function
 //
diff --git a/SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf 
b/SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
index 740af3f..481a878 100644
--- a/SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
+++ b/SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
@@ -3,7 +3,7 @@
 #
 #  This library is used by other modules to send TPM 2.0 command.
 #
-# Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2013 - 2017, 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 @@ 
-40,6 +40,7 @@
   Tpm2EnhancedAuthorization.c
   Tpm2Test.c
   Tpm2DictionaryAttack.c
+  Tpm2Object.c
   Tpm2Miscellaneous.c
   Tpm2Help.c
 
diff --git a/SecurityPkg/Library/Tpm2CommandLib/Tpm2Object.c 
b/SecurityPkg/Library/Tpm2CommandLib/Tpm2Object.c
new file mode 100644
index 000..e070ff2
--- /dev/null
+++ b/SecurityPkg/Library/Tpm2CommandLib/Tpm2Object.c
@@ -0,0 +1,346 @@
+/** @file
+  Implement TPM2 Object related command.
+
+Copyright (c) 2017, Intel Corporation. All rights reserved.  This 
+program and the accompanying materials are licensed and made available 
+under the terms and conditions of the BSD License which accompanies 
+this distribution.  The full text of the license may be found at 
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#pragma pack(1)
+
+typedef struct {
+  TPM2_COMMAND_HEADER   Header;
+  TPMI_DH_OBJECTObjectHandle;
+} TPM2_READ_PUBLIC_COMMAND;
+
+typedef struct {
+  TPM2_RESPONSE_HEADER   Header;
+  TPM2B_PUBLIC   OutPublic;
+  TPM2B_NAME Name;
+  TPM2B_NAME QualifiedName;
+} TPM2_READ_PUBLIC_RESPONSE;
+
+#pragma pack()
+
+/**
+  This command allows access to the public area of a loaded object.
+
+  @param[in]  ObjectHandleTPM handle of an object
+  @param[out] OutPublic   Structure containing the public area of 
an object
+  @param[out] NameName of the object
+  @param[out] QualifiedName   The Qualified Name of the object
+
+  @retval EFI_SUCCESS  Operation completed successfully.
+  @retval EFI_DEVICE_ERROR Unexpected device behavior.
+**/
+EFI_STATUS
+EFIAPI
+Tpm2ReadPublic (
+  IN  TPMI_DH_OBJECTObjectHandle,
+  OUT TPM2B_PUBLIC

Re: [edk2] [PATCH v2] MdeModulePkg/HiiDatabase: clean the value before setting default string

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: Bi, Dandan
> Sent: Tuesday, February 21, 2017 10:26 AM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric; Gao, Liming
> Subject: [PATCH v2] MdeModulePkg/HiiDatabase: clean the value before setting 
> default string
> 
> For string op-code, the default string may not reach the
> maximum size, so when generating  string, we should
> clean the value before setting the default string.
> 
> V2: Add check for default string size.
> 
> Cc: Eric Dong 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c 
> b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
> index d547f42..ccf4b5a 100644
> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
> @@ -1,9 +1,9 @@
>  /** @file
>  Implementation of interfaces function for EFI_HII_CONFIG_ROUTING_PROTOCOL.
> 
> -Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
> +Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD 
> License
>  which accompanies this distribution.  The full text of the license may be 
> found at
>  http://opensource.org/licenses/bsd-license.php
> 
> @@ -3579,10 +3579,11 @@ GenerateAltConfigResp (
>IFR_DEFAULT_DATA  *DefaultId;
>IFR_DEFAULT_DATA  *DefaultValueData;
>UINTN Width;
>UINT8 *TmpBuffer;
>CHAR16*DefaultString;
> +  UINTN StrSize;
> 
>BlockData = NULL;
>DataExist = FALSE;
>DefaultString = NULL;
>//
> @@ -3696,21 +3697,33 @@ GenerateAltConfigResp (
>  // Convert Value to a hex string in "%x" format
>  // NOTE: This is in the opposite byte that GUID and PATH use
>  //
>  if (BlockData->OpCode == EFI_IFR_STRING_OP){
>DefaultString   = InternalGetString(HiiHandle, 
> DefaultValueData->Value.string);
> -  TmpBuffer = (UINT8 *) DefaultString;
> +  TmpBuffer = AllocateZeroPool (Width);
> +  ASSERT (TmpBuffer != NULL);
> +  if (DefaultString != NULL) {
> +StrSize = StrLen(DefaultString)* sizeof (CHAR16);
> +if (StrSize > Width) {
> +  StrSize = Width;
> +}
> +CopyMem (TmpBuffer, (UINT8 *) DefaultString, StrSize);
> +  }
>  } else {
>TmpBuffer = (UINT8 *) &(DefaultValueData->Value);
>  }
>  for (; Width > 0 && (TmpBuffer != NULL); Width--) {
>StringPtr += UnicodeValueToString (StringPtr, PREFIX_ZERO | 
> RADIX_HEX, TmpBuffer[Width - 1], 2);
>  }
>  if (DefaultString != NULL){
>FreePool(DefaultString);
>DefaultString = NULL;
>  }
> +if (BlockData->OpCode == EFI_IFR_STRING_OP && TmpBuffer != NULL) {
> +  FreePool(TmpBuffer);
> +  TmpBuffer  = NULL;
> +}
>}
>  }
>}
> 
>HiiToLower (*DefaultAltCfgResp);
> --
> 1.9.5.msysgit.1

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