[edk2] [PATCH v1] ShellPkg: Also accept gEfiUnicodeCollation2ProtocolGuid for parsing.

[Marvin Häuser]

The EFI_UNICODE_COLLATION_PROTOCOL can have two different GUIDs. Look
for both to support more UEFI implementations.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Application/Shell/Shell.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Application/Shell/Shell.c 
b/ShellPkg/Application/Shell/Shell.c
index 47b3118ea701..2c564090721d 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -904,12 +904,19 @@ ProcessCommandLine(
   // like a shell option (which is assumed to be `file-name`).
 
   Status = gBS->LocateProtocol (
-  &gEfiUnicodeCollationProtocolGuid,
+  &gEfiUnicodeCollation2ProtocolGuid,
   NULL,
   (VOID **) &UnicodeCollation
   );
   if (EFI_ERROR (Status)) {
-return Status;
+Status = gBS->LocateProtocol (
+&gEfiUnicodeCollationProtocolGuid,
+NULL,
+(VOID **) &UnicodeCollation
+);
+if (EFI_ERROR (Status)) {
+  return Status;
+}
   }
 
   // Set default options
-- 
2.7.4.windows.1

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

[edk2] [PATCH v1] ShellPkg/Bcfg: Add support for 'addp' command.

[Marvin Häuser]

Until now the 'addp' command has been handled in the same way as 'add'.
Just copy the DevicePath starting from the Hard Drive node when 'addp'
is used.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 18 
+-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index b407608d3154..bf35a35b985d 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -310,6 +310,7 @@ BcfgAdd(
 {
   EFI_STATUSStatus;
   EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
+  EFI_DEVICE_PATH_PROTOCOL  *DevPath;
   EFI_DEVICE_PATH_PROTOCOL  *FilePath;
   CHAR16*Str;
   UINT8 *TempByteBuffer;
@@ -462,9 +463,9 @@ BcfgAdd(
   ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_BCFG_FILE_DP), 
gShellBcfgHiiHandle, L"bcfg", Arg->FullName);  
   ShellStatus = SHELL_UNSUPPORTED;
 } else {
-/*
   if (UsePath) {
-DevPath = DevicePath;
+DevPath = DevicePath;
+ShellStatus = SHELL_INVALID_PARAMETER;
 while (!IsDevicePathEnd(DevPath)) {
   if ((DevicePathType(DevPath) == MEDIA_DEVICE_PATH) &&
 (DevicePathSubType(DevPath) == MEDIA_HARDDRIVE_DP)) {
@@ -472,24 +473,15 @@ BcfgAdd(
 //
 // If we find it use it instead
 //
-DevicePath = DevPath;
+ShellStatus = SHELL_SUCCESS;
+FilePath= DuplicateDevicePath (DevPath);
 break;
   }
   DevPath = NextDevicePathNode(DevPath);
 }
-//
-// append the file
-//
-for(StringWalker=Arg->FullName; *StringWalker != CHAR_NULL && 
*StringWalker != ':'; StringWalker++);
-FileNode = FileDevicePath(NULL, StringWalker+1);
-FilePath = AppendDevicePath(DevicePath, FileNode);
-FreePool(FileNode);
   } else {
-*/
 FilePath = DuplicateDevicePath(DevicePath);
-/*
   }
-*/
   FreePool(DevicePath);
 }
   }
-- 
2.7.4.windows.1

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

[edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save resources.

[Marvin Häuser]

1) RunSplitCommand() allocates the initial SplitStdOut via
   CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix
   the memory leak.

2) In RunSplitCommand(), SplitStdOut is checked for equality with
   StdIn. This cannot happen due to the if-check within the swap.
   Hence remove it.

3) UefiMain() doesn't free SplitList. Delete all list entries and
   reinitialize the list when in DEBUG. This does not include the
   CreateFileInterfaceMem()-allocated SplitStd mentioned in 1), so
   keep the ASSERT() until resolved.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Application/Shell/Shell.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Application/Shell/Shell.c 
b/ShellPkg/Application/Shell/Shell.c
index 47b3118ea701..a562c9a2c0bc 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -342,6 +342,7 @@ UefiMain (
   UINTN   Size;
   EFI_HANDLE  ConInHandle;
   EFI_SIMPLE_TEXT_INPUT_PROTOCOL  *OldConIn;
+  SPLIT_LIST  *Split;
 
   if (PcdGet8(PcdShellSupportLevel) > 3) {
 return (EFI_UNSUPPORTED);
@@ -675,7 +676,17 @@ FreeResources:
   }
 
   if (!IsListEmpty(&ShellInfoObject.SplitList.Link)){
-ASSERT(FALSE); ///@todo finish this de-allocation.
+ASSERT(FALSE); ///@todo finish this de-allocation (free SplitStdIn/Out 
when needed).
+
+for ( Split = (SPLIT_LIST*)GetFirstNode (&ShellInfoObject.SplitList.Link)
+; !IsNull (&ShellInfoObject.SplitList.Link, &Split->Link)
+; Split = (SPLIT_LIST *)GetNextNode (&ShellInfoObject.SplitList.Link, 
&Split->Link)
+ ) {
+  RemoveEntryList (&Split->Link);
+  FreePool (Split);
+}
+
+DEBUG_CODE (InitializeListHead (&ShellInfoObject.SplitList.Link););
   }
 
   if (ShellInfoObject.ShellInitSettings.FileName != NULL) {
@@ -1736,11 +1747,12 @@ RunSplitCommand(
   //
   // Note that the original StdIn is now the StdOut...
   //
-  if (Split->SplitStdOut != NULL && Split->SplitStdOut != StdIn) {
+  if (Split->SplitStdOut != NULL) {
 
ShellInfoObject.NewEfiShellProtocol->CloseFile(ConvertShellHandleToEfiFileProtocol(Split->SplitStdOut));
   }
   if (Split->SplitStdIn != NULL) {
 
ShellInfoObject.NewEfiShellProtocol->CloseFile(ConvertShellHandleToEfiFileProtocol(Split->SplitStdIn));
+FreePool (Split->SplitStdIn);
   }
 
   FreePool(Split);
-- 
2.7.4.windows.1

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

[edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save resources.

[Marvin Häuser]

1) RunSplitCommand() allocates the initial SplitStdOut via
   CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix
   the memory leak.

2) In RunSplitCommand(), SplitStdOut is checked for equality with
   StdIn. This cannot happen due to the if-check within the swap.
   Hence remove it.

3) UefiMain() doesn't free SplitList. Delete all list entries and
   reinitialize the list when in DEBUG. This does not include the
   CreateFileInterfaceMem()-allocated SplitStd mentioned in 1), so
   keep the ASSERT() until resolved.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Application/Shell/Shell.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Application/Shell/Shell.c 
b/ShellPkg/Application/Shell/Shell.c
index 47b3118ea701..a562c9a2c0bc 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -342,6 +342,7 @@ UefiMain (
   UINTN   Size;
   EFI_HANDLE  ConInHandle;
   EFI_SIMPLE_TEXT_INPUT_PROTOCOL  *OldConIn;
+  SPLIT_LIST  *Split;
 
   if (PcdGet8(PcdShellSupportLevel) > 3) {
 return (EFI_UNSUPPORTED);
@@ -675,7 +676,17 @@ FreeResources:
   }
 
   if (!IsListEmpty(&ShellInfoObject.SplitList.Link)){
-ASSERT(FALSE); ///@todo finish this de-allocation.
+ASSERT(FALSE); ///@todo finish this de-allocation (free SplitStdIn/Out 
when needed).
+
+for ( Split = (SPLIT_LIST*)GetFirstNode (&ShellInfoObject.SplitList.Link)
+; !IsNull (&ShellInfoObject.SplitList.Link, &Split->Link)
+; Split = (SPLIT_LIST *)GetNextNode (&ShellInfoObject.SplitList.Link, 
&Split->Link)
+ ) {
+  RemoveEntryList (&Split->Link);
+  FreePool (Split);
+}
+
+DEBUG_CODE (InitializeListHead (&ShellInfoObject.SplitList.Link););
   }
 
   if (ShellInfoObject.ShellInitSettings.FileName != NULL) {
@@ -1736,11 +1747,12 @@ RunSplitCommand(
   //
   // Note that the original StdIn is now the StdOut...
   //
-  if (Split->SplitStdOut != NULL && Split->SplitStdOut != StdIn) {
+  if (Split->SplitStdOut != NULL) {
 
ShellInfoObject.NewEfiShellProtocol->CloseFile(ConvertShellHandleToEfiFileProtocol(Split->SplitStdOut));
   }
   if (Split->SplitStdIn != NULL) {
 
ShellInfoObject.NewEfiShellProtocol->CloseFile(ConvertShellHandleToEfiFileProtocol(Split->SplitStdIn));
+FreePool (Split->SplitStdIn);
   }
 
   FreePool(Split);
-- 
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 v1 1/1] ShellPkg/App: Fix memory leak and save resources.

[Marvin Häuser]

Hello,

Please excuse this E-Mail, I accidentially CC'd the maintainers of the wrong 
package.
The patch has been re-sent with the correct CCs.

Regards,
Marvin.


Von: edk2-devel  im Auftrag von Marvin Häuser 

Gesendet: Donnerstag, 19. Mai 2016 21:02
An: edk2-devel@lists.01.org
Cc: liming@intel.com
Betreff: [edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save   
resources.

1) RunSplitCommand() allocates the initial SplitStdOut via
   CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix
   the memory leak.

2) In RunSplitCommand(), SplitStdOut is checked for equality with
   StdIn. This cannot happen due to the if-check within the swap.
   Hence remove it.

3) UefiMain() doesn't free SplitList. Delete all list entries and
   reinitialize the list when in DEBUG. This does not include the
   CreateFileInterfaceMem()-allocated SplitStd mentioned in 1), so
   keep the ASSERT() until resolved.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Application/Shell/Shell.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Application/Shell/Shell.c 
b/ShellPkg/Application/Shell/Shell.c
index 47b3118ea701..a562c9a2c0bc 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -342,6 +342,7 @@ UefiMain (
   UINTN   Size;
   EFI_HANDLE  ConInHandle;
   EFI_SIMPLE_TEXT_INPUT_PROTOCOL  *OldConIn;
+  SPLIT_LIST  *Split;

   if (PcdGet8(PcdShellSupportLevel) > 3) {
 return (EFI_UNSUPPORTED);
@@ -675,7 +676,17 @@ FreeResources:
   }

   if (!IsListEmpty(&ShellInfoObject.SplitList.Link)){
-ASSERT(FALSE); ///@todo finish this de-allocation.
+ASSERT(FALSE); ///@todo finish this de-allocation (free SplitStdIn/Out 
when needed).
+
+for ( Split = (SPLIT_LIST*)GetFirstNode (&ShellInfoObject.SplitList.Link)
+; !IsNull (&ShellInfoObject.SplitList.Link, &Split->Link)
+; Split = (SPLIT_LIST *)GetNextNode (&ShellInfoObject.SplitList.Link, 
&Split->Link)
+ ) {
+  RemoveEntryList (&Split->Link);
+  FreePool (Split);
+}
+
+DEBUG_CODE (InitializeListHead (&ShellInfoObject.SplitList.Link););
   }

   if (ShellInfoObject.ShellInitSettings.FileName != NULL) {
@@ -1736,11 +1747,12 @@ RunSplitCommand(
   //
   // Note that the original StdIn is now the StdOut...
   //
-  if (Split->SplitStdOut != NULL && Split->SplitStdOut != StdIn) {
+  if (Split->SplitStdOut != NULL) {
 
ShellInfoObject.NewEfiShellProtocol->CloseFile(ConvertShellHandleToEfiFileProtocol(Split->SplitStdOut));
   }
   if (Split->SplitStdIn != NULL) {
 
ShellInfoObject.NewEfiShellProtocol->CloseFile(ConvertShellHandleToEfiFileProtocol(Split->SplitStdIn));
+FreePool (Split->SplitStdIn);
   }

   FreePool(Split);
--
2.7.4.windows.1

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

Re: [edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save resources.

[Marvin Häuser]

Hey Jaben,

As I mentioned in 3), there is still the CreateFileInterfaceMem() resource leak 
if the list is not empty, so this is definitely still a todo, I do not know how 
to solve (yet?). I only kept the ASSERT() because it was present before, I 
don't really see the point in stopping execution there to be honest.

By the way, if you have time, please review my other two patches as well:
[PATCH v1] ShellPkg: Also accept gEfiUnicodeCollation2ProtocolGuid for parsing.
[PATCH v1] ShellPkg/Bcfg: Add support for 'addp' command.

Thank you for your time!

Regards,
Marvin.

> -Original Message-
> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> Sent: Thursday, May 19, 2016 10:09 PM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: Qiu, Shumin ; Carsey, Jaben
> 
> Subject: RE: [edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save
> resources.
> 
> Can we safely remove the ASSERt now?
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin Häuser
> > Sent: Thursday, May 19, 2016 12:04 PM
> > To: edk2-devel@lists.01.org
> > Cc: Carsey, Jaben ; Qiu, Shumin
> > 
> > Subject: [edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save
> > resources.
> > Importance: High
> >
> > 1) RunSplitCommand() allocates the initial SplitStdOut via
> >CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix
> >the memory leak.
> >
> > 2) In RunSplitCommand(), SplitStdOut is checked for equality with
> >StdIn. This cannot happen due to the if-check within the swap.
> >Hence remove it.
> >
> > 3) UefiMain() doesn't free SplitList. Delete all list entries and
> >reinitialize the list when in DEBUG. This does not include the
> >CreateFileInterfaceMem()-allocated SplitStd mentioned in 1), so
> >keep the ASSERT() until resolved.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  ShellPkg/Application/Shell/Shell.c | 16 ++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/ShellPkg/Application/Shell/Shell.c
> > b/ShellPkg/Application/Shell/Shell.c
> > index 47b3118ea701..a562c9a2c0bc 100644
> > --- a/ShellPkg/Application/Shell/Shell.c
> > +++ b/ShellPkg/Application/Shell/Shell.c
> > @@ -342,6 +342,7 @@ UefiMain (
> >UINTN   Size;
> >EFI_HANDLE  ConInHandle;
> >EFI_SIMPLE_TEXT_INPUT_PROTOCOL  *OldConIn;
> > +  SPLIT_LIST  *Split;
> >
> >if (PcdGet8(PcdShellSupportLevel) > 3) {
> >  return (EFI_UNSUPPORTED);
> > @@ -675,7 +676,17 @@ FreeResources:
> >}
> >
> >if (!IsListEmpty(&ShellInfoObject.SplitList.Link)){
> > -ASSERT(FALSE); ///@todo finish this de-allocation.
> > +ASSERT(FALSE); ///@todo finish this de-allocation (free
> > + SplitStdIn/Out
> > when needed).
> > +
> > +for ( Split = (SPLIT_LIST*)GetFirstNode 
> > (&ShellInfoObject.SplitList.Link)
> > +; !IsNull (&ShellInfoObject.SplitList.Link, &Split->Link)
> > +; Split = (SPLIT_LIST *)GetNextNode
> > + (&ShellInfoObject.SplitList.Link,
> > &Split->Link)
> > + ) {
> > +  RemoveEntryList (&Split->Link);
> > +  FreePool (Split);
> > +}
> > +
> > +DEBUG_CODE (InitializeListHead
> > + (&ShellInfoObject.SplitList.Link););
> >}
> >
> >if (ShellInfoObject.ShellInitSettings.FileName != NULL) { @@
> > -1736,11 +1747,12 @@ RunSplitCommand(
> >//
> >// Note that the original StdIn is now the StdOut...
> >//
> > -  if (Split->SplitStdOut != NULL && Split->SplitStdOut != StdIn) {
> > +  if (Split->SplitStdOut != NULL) {
> >  ShellInfoObject.NewEfiShellProtocol-
> > >CloseFile(ConvertShellHandleToEfiFileProtocol(Split->SplitStdOut));
> >}
> >if (Split->SplitStdIn != NULL) {
> >  ShellInfoObject.NewEfiShellProtocol-
> > >CloseFile(ConvertShellHandleToEfiFileProtocol(Split->SplitStdIn));
> > +FreePool (Split->SplitStdIn);
> >}
> >
> >FreePool(Split);
> > --
> > 2.7.4.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1 1/1] MdePkg/DebugLib: Ignore DEBUG variables in RELEASE builds.

[Marvin Häuser]

When the only point of use of a variable is a DEBUG() or ASSERT()
expression, most compilers will issue a warning when targeting
RELEASE. Cast the parameters to VOID to silence these warnings.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Library/DebugLib.h | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/MdePkg/Include/Library/DebugLib.h 
b/MdePkg/Include/Library/DebugLib.h
index 93b6f8df34ae..25c8ebb95740 100644
--- a/MdePkg/Include/Library/DebugLib.h
+++ b/MdePkg/Include/Library/DebugLib.h
@@ -270,7 +270,7 @@ DebugPrintLevelEnabled (
 } while (FALSE)
   #define _DEBUG(Expression)   _DEBUG_PRINT Expression
 #else
-#define _DEBUG(Expression)   DebugPrint Expression
+  #define _DEBUG(Expression)   DebugPrint Expression
 #endif
 
 /**  
@@ -288,6 +288,8 @@ DebugPrintLevelEnabled (
 #if !defined(MDEPKG_NDEBUG)   
   #define ASSERT(Expression)\
 do {\
+  (VOID)(Expression);   \
+\
   if (DebugAssertEnabled ()) {  \
 if (!(Expression)) {\
   _ASSERT (Expression); \
@@ -295,7 +297,7 @@ DebugPrintLevelEnabled (
   } \
 } while (FALSE)
 #else
-  #define ASSERT(Expression)
+  #define ASSERT(Expression) (VOID)(Expression)
 #endif
 
 /**  
@@ -312,13 +314,15 @@ DebugPrintLevelEnabled (
 **/
 #if !defined(MDEPKG_NDEBUG)  
   #define DEBUG(Expression)\
+(VOID)(Expression);\
+   \
 do {   \
   if (DebugPrintEnabled ()) {  \
 _DEBUG (Expression);   \
   }\
 } while (FALSE)
 #else
-  #define DEBUG(Expression)
+  #define DEBUG(Expression) (VOID)(Expression)
 #endif
 
 /**  
@@ -336,6 +340,8 @@ DebugPrintLevelEnabled (
 #if !defined(MDEPKG_NDEBUG)
   #define ASSERT_EFI_ERROR(StatusParameter)
  \
 do {   
  \
+  (VOID)(StatusParameter); 
  \
+   
  \
   if (DebugAssertEnabled ()) { 
  \
 if (EFI_ERROR (StatusParameter)) { 
  \
   DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n", 
StatusParameter));  \
@@ -344,7 +350,7 @@ DebugPrintLevelEnabled (
   }
  \
 } while (FALSE)
 #else
-  #define ASSERT_EFI_ERROR(StatusParameter)
+  #define ASSERT_EFI_ERROR(StatusParameter) (VOID)(StatusParameter)
 #endif
 
 /**  
@@ -372,6 +378,9 @@ DebugPrintLevelEnabled (
 #if !defined(MDEPKG_NDEBUG)
   #define ASSERT_PROTOCOL_ALREADY_INSTALLED(Handle, Guid)  
 \
 do {   
 \
+  (VOID)(Handle);  
 \
+  (VOID)(Guid);
 \
+   
 \
   if (DebugAssertEnabled ()) { 
 \
 VOID  *Instance;   
 \
 ASSERT (Guid != NULL); 
 \
@@ -387,7 +396,7 @@ DebugPrintLevelEnabled (
   }
 \
 } while (FALSE)
 #else
-  #define ASSERT_PROTOCOL_ALREADY_INSTALLED(Handle, Guid)
+  #define ASSERT_PROTOCOL_ALREADY_INSTALLED(Handle, Guid) (VOID)(Handle)
 #endif
 
 /**
-- 
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 v1 1/1] MdePkg/DebugLib: Ignore DEBUG variables in RELEASE builds.

[Marvin Häuser]

Hey Laszlo,

Thanks for your comment. To be honest, I was not aware of any side effects when 
casting to VOID - that's what I have been used to in the past and also saw it 
in several sources, including Microsoft (yes, not a good example for good src 
:) ). But as the issue is obviously known already, which I didn't know either, 
I will just wait it out.
Though, if only DEBUG builds are checked for unused variables, might be an 
issue for those who only build RELEASE.

Regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, May 30, 2016 6:03 PM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org 
> Cc: michael.d.kin...@intel.com; liming@intel.com; Ard Biesheuvel
> 
> Subject: Re: [edk2] [PATCH v1 1/1] MdePkg/DebugLib: Ignore DEBUG
> variables in RELEASE builds.
> 
> On 05/30/16 15:22, Marvin Häuser wrote:
> > When the only point of use of a variable is a DEBUG() or ASSERT()
> > expression, most compilers will issue a warning when targeting
> > RELEASE. Cast the parameters to VOID to silence these warnings.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  MdePkg/Include/Library/DebugLib.h | 19 ++-
> >  1 file changed, 14 insertions(+), 5 deletions(-)
> 
> This seems incorrect to me. The patch doesn't only cast existing expressions
> to VOID, it evaluates expressions for one more time. If the expressions have
> side effects (which may or may not be a smart thing, but it depends on the
> caller of DEBUG()), this patch will cause problems.
> 
> Instead, the compiler flags should be changed for RELEASE builds not to warn
> about such variables. Please see the following messages:
> 
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/9184/focus=9454
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/9702/focus=9735
> 
> In brief, we converted the tree to be "clean" with regard to gcc's "-Wunused-
> but-set-variable", but only for DEBUG builds.
> 
> Thanks
> Laszlo
> 
> > diff --git a/MdePkg/Include/Library/DebugLib.h
> > b/MdePkg/Include/Library/DebugLib.h
> > index 93b6f8df34ae..25c8ebb95740 100644
> > --- a/MdePkg/Include/Library/DebugLib.h
> > +++ b/MdePkg/Include/Library/DebugLib.h
> > @@ -270,7 +270,7 @@ DebugPrintLevelEnabled (
> >  } while (FALSE)
> >#define _DEBUG(Expression)   _DEBUG_PRINT Expression
> >  #else
> > -#define _DEBUG(Expression)   DebugPrint Expression
> > +  #define _DEBUG(Expression)   DebugPrint Expression
> >  #endif
> >
> >  /**
> > @@ -288,6 +288,8 @@ DebugPrintLevelEnabled (
> >  #if !defined(MDEPKG_NDEBUG)
> >#define ASSERT(Expression)\
> >  do {\
> > +  (VOID)(Expression);   \
> > +\
> >if (DebugAssertEnabled ()) {  \
> >  if (!(Expression)) {\
> >_ASSERT (Expression); \
> > @@ -295,7 +297,7 @@ DebugPrintLevelEnabled (
> >} \
> >  } while (FALSE)
> >  #else
> > -  #define ASSERT(Expression)
> > +  #define ASSERT(Expression) (VOID)(Expression)
> >  #endif
> >
> >  /**
> > @@ -312,13 +314,15 @@ DebugPrintLevelEnabled (  **/
> >  #if !defined(MDEPKG_NDEBUG)
> >#define DEBUG(Expression)\
> > +(VOID)(Expression);\
> > +   \
> >  do {   \
> >if (DebugPrintEnabled ()) {  \
> >  _DEBUG (Expression);   \
> >}\
> >  } while (FALSE)
> >  #else
> > -  #define DEBUG(Expression)
> > +  #define DEBUG(Expression) (VOID)(Expression)
> >  #endif
> >
> >  /**
> > @@ -336,6 +340,8 @@ DebugPrintLevelEnabled (  #if
> > !defined(MDEPKG_NDEBUG)
> >#define ASSERT_EFI_ERROR(StatusParameter)
> >   \
> >  do {   
> >   \
> > +  (VOID)(StatusParameter); 
> >   \
> > +
> > + \
> >if (DebugAssertEnabled ()) { 
> >   \
> >  if (EFI_ERROR (StatusParameter)) { 
> >   \
> >DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n",
> > StatusParameter));  \ @@ -344,7 +350,7 @@ DebugPr

Re: [edk2] Q: Which module type fits my library?

[Marvin Häuser]

Sorry, I forgot to add edk2-devel to the sender list. :)

> -Original Message-
> From: Marvin Häuser
> Sent: Wednesday, June 1, 2016 6:39 PM
> To: 'Peter Kirmeier' 
> Subject: RE: [edk2] Q: Which module type fits my library?
> 
> Hey Peter,
> 
> UEFI Drivers are pretty much (not literally) DXE Drivers, though 1) they are
> executed only after all architectural protocols have been installed and 2) 
> they
> usually expose a Driver Binding protocol (for hardware drivers). 'DXE' is, if 
> I
> remember correctly, a term from the UEFI PI spec and hence the note that
> UEFI drivers are drivers compliant to the UEFI spec (both are independent).
> And yes, they both are terminated with ExitBootServices().
> 
> Regards,
> Marvin.
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Peter Kirmeier
> > Sent: Wednesday, June 1, 2016 6:09 PM
> > To: edk2-de...@ml01.01.org
> > Subject: [edk2] Q: Which module type fits my library?
> >
> > Hi there,
> >
> >
> >
> > today I wasn't sure which module types my (DXE) library actually supports,
> so
> > I had a look at the modules writers guide here:
> >
> > https://github.com/tianocore-
> > docs/Docs/raw/master/User_Docs/EDK_II%20Module%
> > 20Writer_s%20Guide_0_7.pdf
> >
> > At section 3.1.1 there is a list of module types with a brief introduction.
> >
> > So I was looking for suitable types.
> >
> >
> >
> > DXE_DRIVER is for DXE phase and gets destroyed after ExitBootServices.
> >
> > Okay.
> >
> >
> >
> > DXE_RUNTIME_DRIVER doesn't get destroyed but have to make sure the
> > pointer will not break on SetVirtualAddressMap().
> >
> > Got it.
> >
> >
> >
> > UEFI_DRIVER is used for drivers that are "compliant with UEFI
> Specification".
> > What does that actually mean?
> >
> > I mean: Are they alive until ExitBootServices() or longer with the need to
> take
> > care of SetVirtualAddressMap()?
> >
> > Haven't found any information about that yet, maybe someone can help
> > here?
> >
> >
> >
> > UEFI_APPLICATION is used by applications which are "compliant with UEFI
> > Specification".
> >
> > Afaik this could be a bootloader, a shell oder a shell application, right?
> >
> > So I think the lifetime of this module starts and ends before
> > ExitBootServices() like a DXE_DRIVER.
> >
> > However, at least until the application is going to call ExitBootServices() 
> > by
> > itself or uses SetVirtualAddressMap().
> >
> > Oh, and thinking of CTRL+C at shell it should be able to release all 
> > resourses
> > at any time, correct?
> >
> >
> >
> > Thank you,
> >
> >   Peter
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/1] MdePkg/DebugLib: Ignore DEBUG variables in RELEASE builds.

[Marvin Häuser]

Thank you in advance for your comprehensive example, I understood it now. I 
just haven't considered that the macros need to ensure var-changing 
instructions may only be ran once. :)

Regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, May 30, 2016 8:54 PM
> To: Marvin Häuser 
> Cc: edk2-devel@lists.01.org 
> Subject: Re: [edk2] [PATCH v1 1/1] MdePkg/DebugLib: Ignore DEBUG
> variables in RELEASE builds.
> 
> On 05/30/16 20:13, Marvin Häuser wrote:
> > Hey Laszlo,
> >
> > Thanks for your comment. To be honest, I was not aware of any side
> > effects when casting to VOID - that's what I have been used to in the
> > past and also saw it in several sources, including Microsoft (yes, not
> > a good example for good src :) ).
> 
> No, that's not what I meant. It is fine to cast an expression that you already
> have in place to VOID. For example, if you have the (statement-)expression
> 
>   fprintf(stdout, "hello world\n");
> 
> and you expressly don't care about the return value (an "int", for printf()),
> you can write
> 
>   (void)fprintf(stdout, "hello world\n");
> 
> But that's not *all* your patch does. Instead, your patch adds brand new
> instances (evaluations) of the debug expression that have been there
> before.
> 
> For example:
> 
> >>> @@ -288,6 +288,8 @@ DebugPrintLevelEnabled (  #if
> >>> !defined(MDEPKG_NDEBUG)
> >>>#define ASSERT(Expression)\
> >>>  do {\
> >>> +  (VOID)(Expression);   \
> >>> +\
> >>>if (DebugAssertEnabled ()) {  \
> >>>  if (!(Expression)) {\
> >>>_ASSERT (Expression); \
> >>> @@ -295,7 +297,7 @@ DebugPrintLevelEnabled (
> >>>} \
> >>>  } while (FALSE)
> >>>  #else
> >>> -  #define ASSERT(Expression)
> >>> +  #define ASSERT(Expression) (VOID)(Expression)
> >>>  #endif
> 
> First, some background:
> 
> * On a toolchain that supports link time optimization (here: elimination of
> dead code at linking), the MDEPKG_NDEBUG macro is not supposed to be
> defined. Instead, the DebugAssertEnabled() function is called. That function
> is usually based on PcdDebugPropertyMask. If the latter PCD is a fixed PCD,
> then the condition can be evaluated at build time, and if it is false, then an
> LTO-capable toolchain can remove the entire code block dependent on the
> condition. This is what the first branch of the outermost #if is for.
> 
> * The second branch is for toolchains that don't support LTO. For them, the
> only way to remove code that is dead, due to building for RELEASE (as
> opposed to DEBUG), is to #define MDEPKG_NDEBUG in the RELEASE build
> flags. In this case, the compiler doesn't even see the code (it doesn't 
> survive
> into linking) because the preprocessor removes it.
> 
> But, *either way*, the end result is, if you build for RELEASE, the Expression
> passed to ASSERT() is not evaluated. It doesn't matter if it's the
> DebugAssertEnabled() function call or the MDEPKG_NDEBUG macro that
> prevents the evaluation, the point is, the evaluation doesn't occur.
> 
> And that's what your patch breaks. Consider the following example:
> 
>   STATIC UINT32 CheckCounter;
> 
>   BOOLEAN
>   CheckIfStuffIsOkay (
> VOID
> )
>   {
> BOOLEAN Okay;
> 
> Print (L"Checking (%u)...\n", CheckCounter++);
> //
> // Okay = ...
> //
> return Okay;
>   }
> ...
> 
>   TYPE
>   SomeOtherFunction (
> ...
> )
>   {
> ...
> ASSERT (CheckIfStuffIsOkay ());
> ...
>   }
> 
> Without your patch:
> - in a RELEASE build, the CheckCounter variable will not be incremented, and
> the string will not appear on the console
> - in a DEBUG build, the CheckCounter variable will be incremented once, and
> the string will appear once, on the console.
> 
> With your patch:
> - In a RELEASE build with a toolchain that supports LTO (i.e., one that 
> doesn't
> define MDEPKG_NDEBUG), the variable will be incremented, and the
> message will be printed.
> - In a DEBUG build with the same toolchain, the increment and the
> corresponding Print() will be executed twice.
> 
> In short, your patch changes behavior for when Expression, passed to
> ASSERT(), has side effects, and the toolchain supports LTO (i.e.,
> MDEPKG_NDEBUG is never

[edk2] [PATCH v1 1/2] MdePkg: Add NORETURN attribute and UNREACHABLE() macro.

[Marvin Häuser]

The NORETURN attribute informs compilers and analyzers that the flagged
function cannot return. This may improve the quality of the optimizations.

The UNREACHABLE() macro informs compilers and analyzers that its position
cannot be reached, for example eliminating implicit returns.
It is recommended to be used together with the NORETURN attribute to prevent
warnings regarding the function flagged as 'noreturn' returning.

The ANALYZER-prefixed versions have the same effects, but exclude compilers.
They may be used to surpress warnings of static analyzers, such as possible
dereferencing of a NULL pointer when dereferencing it after having checked it
via ASSERT().

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Base.h | 103 
 1 file changed, 103 insertions(+)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index 89b2aed07229..9dfafb282177 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -85,6 +85,109 @@ VERIFY_SIZE_OF (CHAR16, 2);
 #endif
 
 //
+// Should be used in combination with NORETURN to avoid 'noreturn' returns
+// warnings.
+//
+#ifndef UNREACHABLE
+  #ifdef __GNUC__
+///
+/// Signal compilers and analyzers that this call is not reachable.  It is
+/// up to the compiler to remove any code past that point.
+///
+#define UNREACHABLE()  __builtin_unreachable()
+  #elif defined (__has_feature)
+#if __has_builtin (__builtin_unreachable)
+  ///
+  /// Signal compilers and analyzers that this call is not reachable.  It 
is
+  /// up to the compiler to remove any code past that point.
+  ///
+  #define UNREACHABLE()  __builtin_unreachable()
+#endif
+  #endif
+
+  #ifndef UNREACHABLE
+///
+/// Signal compilers and analyzers that this call is not reachable.  It is
+/// up to the compiler to remove any code past that point.
+///
+#define UNREACHABLE()
+  #endif
+#endif
+
+//
+// Signaling compilers and analyzers that a certain function cannot return may
+// remove all following code and thus lead to better optimization and less
+// false positives.
+//
+#ifndef NORETURN
+  #ifdef __GNUC__
+///
+/// Signal compilers and analyzers that the function cannot return.
+/// It is up to the compiler to remove any code past a call to functions
+/// flagged with this attribute.
+///
+#define NORETURN  __attribute__ ((noreturn))
+  #else
+///
+/// Signal compilers and analyzers that the function cannot return.
+/// It is up to the compiler to remove any code past a call to functions
+/// flagged with this attribute.
+///
+#define NORETURN
+  #endif
+#endif
+
+//
+// Should be used in combination with ANALYZER_NORETURN to avoid 'noreturn'
+// returns warnings.
+//
+#ifndef ANALYZER_UNREACHABLE
+  #ifdef __clang_analyzer__
+#if __has_builtin (__builtin_unreachable)
+  ///
+  /// Signal the analyzer that this call is not reachable.
+  /// This excludes compilers.
+  ///
+  #define ANALYZER_UNREACHABLE()  __builtin_unreachable()
+#endif
+  #endif
+
+  #ifndef ANALYZER_UNREACHABLE
+///
+/// Signal the analyzer that this call is not reachable.
+/// This excludes compilers.
+///
+#define ANALYZER_UNREACHABLE()
+  #endif
+#endif
+
+//
+// Static Analyzers may issue errors about potential NULL-dereferences when
+// dereferencing a pointer, that has been checked before, outside of a
+// NULL-check.  This may lead to false positives, such as when using ASSERT()
+// for verification.
+//
+#ifndef ANALYZER_NORETURN
+  #ifdef __has_feature
+#if __has_feature (attribute_analyzer_noreturn)
+  ///
+  /// Signal analyzers that the function cannot return.
+  /// This excludes compilers.
+  ///
+  #define ANALYZER_NORETURN  __attribute__ ((analyzer_noreturn))
+#endif
+  #endif
+
+  #ifndef ANALYZER_NORETURN
+///
+/// Signal the analyzer that the function cannot return.
+/// This excludes compilers.
+///
+#define ANALYZER_NORETURN
+  #endif
+#endif
+
+//
 // For symbol name in assembly code, an extra "_" is sometimes necessary
 //
 
-- 
2.7.4.windows.1

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

[edk2] [PATCH v1 2/2] MdePkg/BaseLib: Flag CpuDeadLoop() and CpuBreakpoint() as ANALYZER_NORETURN.

[Marvin Häuser]

Add the ANALYZER_NORETURN attribute to CpuDeadLoop() and CpuBreakpoint() to
avoid false 'possible NULL-dereference' warnings when dereferencing pointers
after having validated them with ASSERT(). As the ANALYZER-prefixed versions
are being used, the code following the calls will not be optimized away.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/BaseLib/CpuDeadLoop.c   | 3 +++
 MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c | 3 +++
 MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c| 3 +++
 MdePkg/Library/BaseLib/Ipf/CpuBreakpoint.c | 3 +++
 MdePkg/Library/BaseLib/Ipf/CpuBreakpointMsc.c  | 3 +++
 MdePkg/Library/BaseLib/X64/CpuBreakpoint.c | 3 +++
 MdePkg/Library/BaseLib/X64/GccInline.c | 3 +++
 MdePkg/Include/Library/BaseLib.h   | 2 ++
 MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S | 1 +
 MdePkg/Library/BaseLib/Arm/CpuBreakpoint.S | 1 +
 MdePkg/Library/BaseLib/Arm/CpuBreakpoint.asm   | 1 +
 MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.asm  | 1 +
 MdePkg/Library/BaseLib/X64/CpuBreakpoint.asm   | 1 +
 13 files changed, 28 insertions(+)

diff --git a/MdePkg/Library/BaseLib/CpuDeadLoop.c 
b/MdePkg/Library/BaseLib/CpuDeadLoop.c
index 3f9440547d4d..7e386eab61a3 100644
--- a/MdePkg/Library/BaseLib/CpuDeadLoop.c
+++ b/MdePkg/Library/BaseLib/CpuDeadLoop.c
@@ -28,6 +28,7 @@
 **/
 VOID
 EFIAPI
+ANALYZER_NORETURN
 CpuDeadLoop (
   VOID
   )
@@ -35,4 +36,6 @@ CpuDeadLoop (
   volatile UINTN  Index;
 
   for (Index = 0; Index == 0;);
+
+  ANALYZER_UNREACHABLE ();
 }
diff --git a/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c 
b/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c
index 9b7d875664bd..bd8da8a671d1 100644
--- a/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c
+++ b/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c
@@ -29,11 +29,14 @@ _break (
 **/
 VOID
 EFIAPI
+ANALYZER_NORETURN
 CpuBreakpoint (
   VOID
   )
 {
   _break (3);
+
+  ANALYZER_UNREACHABLE ();
 }
 
 /**
diff --git a/MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c 
b/MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c
index f5df7f2883c6..d68fd770ce3d 100644
--- a/MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c
+++ b/MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c
@@ -32,10 +32,13 @@ void __debugbreak ();
 **/
 VOID
 EFIAPI
+ANALYZER_NORETURN
 CpuBreakpoint (
   VOID
   )
 {
   __debugbreak ();
+
+  ANALYZER_UNREACHABLE ();
 }
 
diff --git a/MdePkg/Library/BaseLib/Ipf/CpuBreakpoint.c 
b/MdePkg/Library/BaseLib/Ipf/CpuBreakpoint.c
index 302974bd5c98..29456b5f867d 100644
--- a/MdePkg/Library/BaseLib/Ipf/CpuBreakpoint.c
+++ b/MdePkg/Library/BaseLib/Ipf/CpuBreakpoint.c
@@ -24,11 +24,14 @@
 **/
 VOID
 EFIAPI
+ANALYZER_NORETURN
 CpuBreakpoint (
   VOID
   )
 {
   __break (0);
+
+  ANALYZER_UNREACHABLE ();
 }
 
 /**
diff --git a/MdePkg/Library/BaseLib/Ipf/CpuBreakpointMsc.c 
b/MdePkg/Library/BaseLib/Ipf/CpuBreakpointMsc.c
index 89b0acfd801b..2b098d462bee 100644
--- a/MdePkg/Library/BaseLib/Ipf/CpuBreakpointMsc.c
+++ b/MdePkg/Library/BaseLib/Ipf/CpuBreakpointMsc.c
@@ -29,11 +29,14 @@
 **/
 VOID
 EFIAPI
+ANALYZER_NORETURN
 CpuBreakpoint (
   VOID
   )
 {
   __break (0);
+
+  ANALYZER_UNREACHABLE ();
 }
 
 /**
diff --git a/MdePkg/Library/BaseLib/X64/CpuBreakpoint.c 
b/MdePkg/Library/BaseLib/X64/CpuBreakpoint.c
index d654f845716f..72055c2acfaa 100644
--- a/MdePkg/Library/BaseLib/X64/CpuBreakpoint.c
+++ b/MdePkg/Library/BaseLib/X64/CpuBreakpoint.c
@@ -30,10 +30,13 @@ void __debugbreak ();
 **/
 VOID
 EFIAPI
+ANALYZER_NORETURN
 CpuBreakpoint (
   VOID
   )
 {
   __debugbreak ();
+
+  ANALYZER_UNREACHABLE ();
 }
 
diff --git a/MdePkg/Library/BaseLib/X64/GccInline.c 
b/MdePkg/Library/BaseLib/X64/GccInline.c
index 3d175ee9314e..b3443c55cb27 100644
--- a/MdePkg/Library/BaseLib/X64/GccInline.c
+++ b/MdePkg/Library/BaseLib/X64/GccInline.c
@@ -99,11 +99,14 @@ CpuPause (
 **/
 VOID
 EFIAPI
+ANALYZER_NORETURN
 CpuBreakpoint (
   VOID
   )
 {
   __asm__ __volatile__ ("int $3");
+
+  ANALYZER_UNREACHABLE ();
 }
 
 
diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 79f421a97111..87f1e39d61db 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -3960,6 +3960,7 @@ SwitchStack (
 **/
 VOID
 EFIAPI
+ANALYZER_NORETURN
 CpuBreakpoint (
   VOID
   );
@@ -3976,6 +3977,7 @@ CpuBreakpoint (
 **/
 VOID
 EFIAPI
+ANALYZER_NORETURN
 CpuDeadLoop (
   VOID
   );
diff --git a/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S 
b/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S
index 6323cffaa981..e4008ec1d3fd 100644
--- a/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S
+++ b/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S
@@ -28,6 +28,7 @@ GCC_ASM_EXPORT(CpuBreakpoint)
 #**/
 #VOID
 #EFIAPI
+#ANALYZER_NORETURN
 #CpuBreakpoint (
 #  VOID
 #  );
diff --git a/MdePkg/Library/BaseLib/Arm/CpuBreakpoint.S 
b/MdePkg/Library/BaseLib/Arm/CpuBreakpoint.S
index b6b80a1326d0..accb6f1b3287 100644
--- a/MdePkg/Library/BaseLib/Arm/CpuBreakpoint.S
+++ b/MdePkg/Library/BaseLib/Arm/CpuBreakpoi

Re: [edk2] [PATCH v1 1/2] MdePkg: Add NORETURN attribute and UNREACHABLE() macro.

[Marvin Häuser]

Hey Andrew, hey Liming,

First, the more important patch is probably the Patch 2/2, which flags 
CpuBreakpoint() and CpuDeadLoop() as ANALYZER_NORETURN to pretend to the 
analyzer the functions can't exit for the sake of surpressing warnings.
I personally don't understand why the patch should be separated, as the two 
pairs of macro and attribute have the very same purpose, just that one pair is 
restricted to Analyzers. Also, the patch is quite small already in its current 
state.

Though I just thought about Patch 2/2 and it could actually be that someone 
uses CpuBreakpoint() and CpuDeadLoop() outside of the ASSERT() macro and, if it 
is not the last function call in a function, the Static Analyzer may issue a 
warning about unreachable code. I have not thought about this before, to be 
honest, and I am not certain on how to prevent this from happening. I would 
value any kind of input from anyone!

Thanks,
Marvin.

> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Sunday, June 12, 2016 5:22 AM
> To: af...@apple.com
> Cc: Marvin Häuser ; edk2-
> de...@lists.01.org; Kinney, Michael D 
> Subject: RE: [edk2] [PATCH v1 1/2] MdePkg: Add NORETURN attribute and
> UNREACHABLE() macro.
> 
> Andrew:
>   Thanks for your explanation. So, they are the different topics. I suggest to
> separate this patch.
> 1. NORETURN attribute and UNREACHABLE() macro will be used for the really
> NORETURN case, like phase change.
> 2. ANALYZER_UNREACHABLE and ANALYZER_NORETURN are for static code
> analyzer, like clang compiler analyzer.
> 
> Thanks
> Liming
> > -Original Message-
> > From: af...@apple.com [mailto:af...@apple.com]
> > Sent: Sunday, June 12, 2016 11:11 AM
> > To: Gao, Liming 
> > Cc: Marvin Häuser ; edk2-
> > de...@lists.01.org; Kinney, Michael D 
> > Subject: Re: [edk2] [PATCH v1 1/2] MdePkg: Add NORETURN attribute and
> > UNREACHABLE() macro.
> >
> >
> > > On Jun 11, 2016, at 7:58 PM, Gao, Liming  wrote:
> > >
> > > Hi,
> > >  I don't see the usage on NORETURN attribute and UNREACHABLE()
> macro.
> > Why we need to add them also?
> > >
> >
> > When you factor in debugging I think the only thing we have that are
> > really NORETURN would be phase changes. SEC calling PEI Core. DXE IPL
> > PEIM loading DXE Core, DXE Core entry point. I debug across and
> > ASSERT(), CpuBreakpoint(), or CpuDeadloop() all the time so turn that
> > compiler feature on would break stuff. For the mode transitions we
> > could save a few unreachable stack cleanup instructions? Thus I guess
> > things like the PEI Core entry point function are kind of NORETURN,
> > and I guess the UNREACHABLE would be like  __builtin_unreachable() and
> > end up after the call to the PEI Core entry point. Given things like
> > the PEI Core entry point are defined in the PI spec, it would probably be
> better to define UNREACHABLE().
> >
> > But I'm still not sure what problem we are trying to solve.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> > > Thanks
> > > Liming
> > >> -Original Message-
> > >> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > >> Sent: Saturday, June 11, 2016 5:02 AM
> > >> To: edk2-devel@lists.01.org
> > >> Cc: Gao, Liming ; Kinney, Michael D
> > >> 
> > >> Subject: [PATCH v1 1/2] MdePkg: Add NORETURN attribute and
> > >> UNREACHABLE() macro.
> > >>
> > >> The NORETURN attribute informs compilers and analyzers that the
> > >> flagged function cannot return. This may improve the quality of the
> optimizations.
> > >>
> > >> The UNREACHABLE() macro informs compilers and analyzers that its
> > position
> > >> cannot be reached, for example eliminating implicit returns.
> > >> It is recommended to be used together with the NORETURN attribute
> > >> to prevent warnings regarding the function flagged as 'noreturn'
> > >> returning.
> > >>
> > >> The ANALYZER-prefixed versions have the same effects, but exclude
> > >> compilers.
> > >> They may be used to surpress warnings of static analyzers, such as
> > possible
> > >> dereferencing of a NULL pointer when dereferencing it after having
> > checked
> > >> it
> > >> via ASSERT().
> > >>
> > >> Contributed-under: TianoCore Contribution Agreement 1.0
> > >> Signed-off-by: Marvin Haeuser 
> > >> ---
> > >> MdePkg/Include/B

Re: [edk2] [PATCH v1 1/2] MdePkg: Add NORETURN attribute and UNREACHABLE() macro.

[Marvin Häuser]

Hello Andrew,

Yes, I agree with you, these should have the attribute/macro call added in a 
separate patch once this one has been approved. As you mentioned yourself, it 
will hopefully eliminate unnecessary stack cleanups and maybe point out 
developer mistakes in case code is placed at the wrong position.

In my opinion, this patch 1/2 is alright. I can split it into two patches if 
really desired, but personally I don't a reason for it. Patch 2/2 should be 
revision, so I will add a mail note about it in a few moments.

Thanks,
Marvin.

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Sunday, June 12, 2016 7:45 PM
> To: Marvin Häuser 
> Cc: edk2-devel@lists.01.org; Gao, Liming 
> Subject: Re: [edk2] [PATCH v1 1/2] MdePkg: Add NORETURN attribute and
> UNREACHABLE() macro.
> 
> 
> > On Jun 12, 2016, at 6:40 AM, Marvin Häuser
>  wrote:
> >
> > Hey Andrew, hey Liming,
> >
> > First, the more important patch is probably the Patch 2/2, which flags
> CpuBreakpoint() and CpuDeadLoop() as ANALYZER_NORETURN to pretend
> to the analyzer the functions can't exit for the sake of surpressing warnings.
> > I personally don't understand why the patch should be separated, as the
> two pairs of macro and attribute have the very same purpose, just that one
> pair is restricted to Analyzers. Also, the patch is quite small already in its
> current state.
> >
> > Though I just thought about Patch 2/2 and it could actually be that
> someone uses CpuBreakpoint() and CpuDeadLoop() outside of the ASSERT()
> macro and, if it is not the last function call in a function, the Static 
> Analyzer
> may issue a warning about unreachable code. I have not thought about this
> before, to be honest, and I am not certain on how to prevent this from
> happening. I would value any kind of input from anyone!
> >
> 
> Marvin,
> 
> I'm not sure what the right answer is but it feels like decorating the 
> locations
> that do not return with something like UNREACHABLE() makes the most
> sense.
> 
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Sec
> Main.c#L253
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/
> PeiMain/PeiMain.c#L469
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe
> IplPeim/DxeLoad.c#L432
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe
> /DxeMain/DxeMain.c#L525
> 
> I don't think we have done it in the past as all these no return points are 
> calls
> from one statically linked module to another statically linked module, so all
> the compiler knows is a C function is being called. So module A is calling
> module B. Thus A has the call from A to B, and B has the function but never
> calls it.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks,
> > Marvin.
> >
> >> -Original Message-
> >> From: Gao, Liming [mailto:liming@intel.com]
> >> Sent: Sunday, June 12, 2016 5:22 AM
> >> To: af...@apple.com
> >> Cc: Marvin Häuser ; edk2-
> >> de...@lists.01.org; Kinney, Michael D 
> >> Subject: RE: [edk2] [PATCH v1 1/2] MdePkg: Add NORETURN attribute and
> >> UNREACHABLE() macro.
> >>
> >> Andrew:
> >>  Thanks for your explanation. So, they are the different topics. I
> >> suggest to separate this patch.
> >> 1. NORETURN attribute and UNREACHABLE() macro will be used for the
> >> really NORETURN case, like phase change.
> >> 2. ANALYZER_UNREACHABLE and ANALYZER_NORETURN are for static
> code
> >> analyzer, like clang compiler analyzer.
> >>
> >> Thanks
> >> Liming
> >>> -Original Message-
> >>> From: af...@apple.com [mailto:af...@apple.com]
> >>> Sent: Sunday, June 12, 2016 11:11 AM
> >>> To: Gao, Liming 
> >>> Cc: Marvin Häuser ; edk2-
> >>> de...@lists.01.org; Kinney, Michael D 
> >>> Subject: Re: [edk2] [PATCH v1 1/2] MdePkg: Add NORETURN attribute
> >>> and
> >>> UNREACHABLE() macro.
> >>>
> >>>
> >>>> On Jun 11, 2016, at 7:58 PM, Gao, Liming 
> wrote:
> >>>>
> >>>> Hi,
> >>>> I don't see the usage on NORETURN attribute and UNREACHABLE()
> >> macro.
> >>> Why we need to add them also?
> >>>>
> >>>
> >>> When you factor in debugging I think the only thing we have that are
> >>> really NORETURN would be phase changes. SEC calling PEI Core. DXE
> >>> IPL PEIM loading DXE Core, DXE Core entry point. I deb

Re: [edk2] [PATCH v1 2/2] MdePkg/BaseLib: Flag CpuDeadLoop() and CpuBreakpoint() as ANALYZER_NORETURN.

[Marvin Häuser]

Dear package maintainers and reviewers,

Please do not approve this patch yet. I have thought further about the 
consequences of decorating CpuDeadLoop() and CpuBreakpoint() with the 
ANALYZER_NORETURN attribute and fear that the Analyzer, against the original 
intention, could issue incorrect warnings when they are used in the middle of 
code. All code following could probably be classified as unreachable (as the 
Analyzer will rightfully assume the Cpu* functions won't return).

I do not know if there is a way to limit this behavior to ASSERT. Maybe this 
patch should be gotten rid of and UNREACHABLE() should be added within the 
ASSERT() macro itself? This would make more sense than what I have done in this 
patch, looking back.

If you have thoughts, please be kind enough to share them.

Regards,
Marvin.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Marvin Häuser
> Sent: Friday, June 10, 2016 11:02 PM
> To: edk2-devel@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: [edk2] [PATCH v1 2/2] MdePkg/BaseLib: Flag CpuDeadLoop() and
> CpuBreakpoint() as ANALYZER_NORETURN.
> 
> Add the ANALYZER_NORETURN attribute to CpuDeadLoop() and
> CpuBreakpoint() to avoid false 'possible NULL-dereference' warnings when
> dereferencing pointers after having validated them with ASSERT(). As the
> ANALYZER-prefixed versions are being used, the code following the calls will
> not be optimized away.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Marvin Haeuser 
> ---
>  MdePkg/Library/BaseLib/CpuDeadLoop.c   | 3 +++
>  MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c | 3 +++
>  MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c| 3 +++
>  MdePkg/Library/BaseLib/Ipf/CpuBreakpoint.c | 3 +++
>  MdePkg/Library/BaseLib/Ipf/CpuBreakpointMsc.c  | 3 +++
>  MdePkg/Library/BaseLib/X64/CpuBreakpoint.c | 3 +++
>  MdePkg/Library/BaseLib/X64/GccInline.c | 3 +++
>  MdePkg/Include/Library/BaseLib.h   | 2 ++
>  MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S | 1 +
>  MdePkg/Library/BaseLib/Arm/CpuBreakpoint.S | 1 +
>  MdePkg/Library/BaseLib/Arm/CpuBreakpoint.asm   | 1 +
>  MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.asm  | 1 +
>  MdePkg/Library/BaseLib/X64/CpuBreakpoint.asm   | 1 +
>  13 files changed, 28 insertions(+)
> 
> diff --git a/MdePkg/Library/BaseLib/CpuDeadLoop.c
> b/MdePkg/Library/BaseLib/CpuDeadLoop.c
> index 3f9440547d4d..7e386eab61a3 100644
> --- a/MdePkg/Library/BaseLib/CpuDeadLoop.c
> +++ b/MdePkg/Library/BaseLib/CpuDeadLoop.c
> @@ -28,6 +28,7 @@
>  **/
>  VOID
>  EFIAPI
> +ANALYZER_NORETURN
>  CpuDeadLoop (
>VOID
>)
> @@ -35,4 +36,6 @@ CpuDeadLoop (
>volatile UINTN  Index;
> 
>for (Index = 0; Index == 0;);
> +
> +  ANALYZER_UNREACHABLE ();
>  }
> diff --git a/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c
> b/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c
> index 9b7d875664bd..bd8da8a671d1 100644
> --- a/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c
> +++ b/MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c
> @@ -29,11 +29,14 @@ _break (
>  **/
>  VOID
>  EFIAPI
> +ANALYZER_NORETURN
>  CpuBreakpoint (
>VOID
>)
>  {
>_break (3);
> +
> +  ANALYZER_UNREACHABLE ();
>  }
> 
>  /**
> diff --git a/MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c
> b/MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c
> index f5df7f2883c6..d68fd770ce3d 100644
> --- a/MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c
> +++ b/MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c
> @@ -32,10 +32,13 @@ void __debugbreak ();  **/  VOID  EFIAPI
> +ANALYZER_NORETURN
>  CpuBreakpoint (
>VOID
>)
>  {
>__debugbreak ();
> +
> +  ANALYZER_UNREACHABLE ();
>  }
> 
> diff --git a/MdePkg/Library/BaseLib/Ipf/CpuBreakpoint.c
> b/MdePkg/Library/BaseLib/Ipf/CpuBreakpoint.c
> index 302974bd5c98..29456b5f867d 100644
> --- a/MdePkg/Library/BaseLib/Ipf/CpuBreakpoint.c
> +++ b/MdePkg/Library/BaseLib/Ipf/CpuBreakpoint.c
> @@ -24,11 +24,14 @@
>  **/
>  VOID
>  EFIAPI
> +ANALYZER_NORETURN
>  CpuBreakpoint (
>VOID
>)
>  {
>__break (0);
> +
> +  ANALYZER_UNREACHABLE ();
>  }
> 
>  /**
> diff --git a/MdePkg/Library/BaseLib/Ipf/CpuBreakpointMsc.c
> b/MdePkg/Library/BaseLib/Ipf/CpuBreakpointMsc.c
> index 89b0acfd801b..2b098d462bee 100644
> --- a/MdePkg/Library/BaseLib/Ipf/CpuBreakpointMsc.c
> +++ b/MdePkg/Library/BaseLib/Ipf/CpuBreakpointMsc.c
> @@ -29,11 +29,14 @@
>  **/
>  VOID
>  EFIAPI
> +ANALYZER_NORETURN
>  CpuBreakpoint (
>VOID
>)
>  {
>__break (0);
> +
> +  ANALYZER_UNREACHABLE ();
>  }
> 

Re: [edk2] [PATCH v1 2/2] MdePkg/BaseLib: Flag CpuDeadLoop() and CpuBreakpoint() as ANALYZER_NORETURN.

[Marvin Häuser]

Liming,

UNREACHABLE() in fact may have an impact as it is a signal that the code flow 
cannot reach that position. Thus a compiler or analyzer may classify everything 
following as unreachable and issue warnings about it or optimize it away. For 
stack cleanups, as Andrew suggested, this is a good thing, not-so for code 
following that instruction though - hence this patch was a bad idea.

I believe the defines are better off in Base.h, as other compiler-specific 
things (UEFI type defines, GLOBAL_REMOVE_IF_UNREFERENCED, ...) are there as 
well in contrast to BaseLib.h, which is basically an unrelated library. These 
macros may not only be used for ASSERT() but, as Andrew suggested, also in the 
handoff functions of all phase modules and these would all need to include 
BaseLib.h to get the necessary defines according to your suggestion.

In the end, it is up to you whether the defines will be in Base.h or BaseLib.h 
- or if regular and ANALYZER_ macros are one or separate patches -, but for 
both cases I do not understand the intention and consider one patch adding the 
defines to Base.h (as already submitted and still backed by myself), another 
patch adding the ANALYZER_UNREACHABLE() decoration to the end of the ASSERT 
if-branch (which will arrive once my concerns regarding the first patch have 
been addressed) and finally a third patch to add the decorations to the phase 
transition functions as pointed out by Andrew as the best solution.

Thanks for your time,
Marvin.

> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Monday, June 13, 2016 4:33 AM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D 
> Subject: RE: [PATCH v1 2/2] MdePkg/BaseLib: Flag CpuDeadLoop() and
> CpuBreakpoint() as ANALYZER_NORETURN.
> 
> Marvin:
>   This is a better. I suggest to create two patch sets. I think you focuses 
> on the
> first. For the second, UNREACHABLE is a decorator, and has no real impact.
> 1. For static code analyzer, add ANALYZER_UNREACHABLE macro in
> BaseLib.h, and use it in _ASSERT() macro in DebugLib.h 2. For un reachable
> case, add UNREACHABLE macro in BaseLib.h, and apply it in code pointed by
> Andrew.
> 
> Thanks
> Liming
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Monday, June 13, 2016 2:46 AM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Gao, Liming
> > 
> > Subject: RE: [PATCH v1 2/2] MdePkg/BaseLib: Flag CpuDeadLoop() and
> > CpuBreakpoint() as ANALYZER_NORETURN.
> >
> > Dear package maintainers and reviewers,
> >
> > Please do not approve this patch yet. I have thought further about the
> > consequences of decorating CpuDeadLoop() and CpuBreakpoint() with the
> > ANALYZER_NORETURN attribute and fear that the Analyzer, against the
> > original intention, could issue incorrect warnings when they are used
> > in the middle of code. All code following could probably be classified
> > as unreachable (as the Analyzer will rightfully assume the Cpu* functions
> won't return).
> >
> > I do not know if there is a way to limit this behavior to ASSERT.
> > Maybe this patch should be gotten rid of and UNREACHABLE() should be
> > added within the ASSERT() macro itself? This would make more sense
> > than what I have done in this patch, looking back.
> >
> > If you have thoughts, please be kind enough to share them.
> >
> > Regards,
> > Marvin.
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Marvin Häuser
> > > Sent: Friday, June 10, 2016 11:02 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: michael.d.kin...@intel.com; liming@intel.com
> > > Subject: [edk2] [PATCH v1 2/2] MdePkg/BaseLib: Flag CpuDeadLoop()
> > > and
> > > CpuBreakpoint() as ANALYZER_NORETURN.
> > >
> > > Add the ANALYZER_NORETURN attribute to CpuDeadLoop() and
> > > CpuBreakpoint() to avoid false 'possible NULL-dereference' warnings
> > > when dereferencing pointers after having validated them with
> > > ASSERT(). As the ANALYZER-prefixed versions are being used, the code
> > > following the calls
> > will
> > > not be optimized away.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Marvin Haeuser 
> > > ---
> > >  MdePkg/Library/BaseLib/CpuDeadLoop.c   | 3 +++
> > >  MdePkg/Library/BaseLib/Ebc/CpuBreakpoint.c | 3 +++
> > >  MdePkg/Library/BaseLib/Ia32/CpuBreakpoint.c| 3 +++
> > >  MdePkg/Library/BaseLib/Ipf/CpuBreak

[edk2] [PATCH v2 1/4] MdePkg: Add NORETURN attribute and UNREACHABLE() macro.

[Marvin Häuser]

The NORETURN attribute informs compilers and analyzers that the flagged
function cannot return. This may improve the quality of the optimizations.

The UNREACHABLE() macro informs compilers and analyzers that its position
cannot be reached, for example eliminating implicit returns.
It is recommended to be used together with the NORETURN attribute to prevent
warnings regarding the function flagged as 'noreturn' returning.

The ANALYZER-prefixed versions have the same effects, but exclude compilers.
They may be used to surpress warnings of static analyzers, such as possible
dereferencing of a NULL pointer when dereferencing it after having checked it
via ASSERT().

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Base.h | 110 
 1 file changed, 110 insertions(+)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index 89b2aed07229..aa31f8c9e4ea 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -85,6 +85,116 @@ VERIFY_SIZE_OF (CHAR16, 2);
 #endif
 
 //
+// Should be used in combination with NORETURN to avoid 'noreturn' returns
+// warnings.
+//
+#ifndef UNREACHABLE
+  #ifdef __GNUC__
+///
+/// Signal compilers and analyzers that this call is not reachable.  It is
+/// up to the compiler to remove any code past that point.
+///
+#define UNREACHABLE()  __builtin_unreachable ()
+  #elif defined (__has_feature)
+#if __has_builtin (__builtin_unreachable)
+  ///
+  /// Signal compilers and analyzers that this call is not reachable.  It 
is
+  /// up to the compiler to remove any code past that point.
+  ///
+  #define UNREACHABLE()  __builtin_unreachable ()
+#endif
+  #endif
+
+  #ifndef UNREACHABLE
+///
+/// Signal compilers and analyzers that this call is not reachable.  It is
+/// up to the compiler to remove any code past that point.
+///
+#define UNREACHABLE()
+  #endif
+#endif
+
+//
+// Signaling compilers and analyzers that a certain function cannot return may
+// remove all following code and thus lead to better optimization and less
+// false positives.
+//
+#ifndef NORETURN
+  #if defined (__GNUC__) || defined (__clang__)
+///
+/// Signal compilers and analyzers that the function cannot return.
+/// It is up to the compiler to remove any code past a call to functions
+/// flagged with this attribute.
+///
+#define NORETURN  __attribute__((noreturn))
+  #elif defined(_MSC_EXTENSIONS) && !defined(MDE_CPU_EBC)
+///
+/// Signal compilers and analyzers that the function cannot return.
+/// It is up to the compiler to remove any code past a call to functions
+/// flagged with this attribute.
+///
+#define NORETURN  __declspec(noreturn)
+  #else
+///
+/// Signal compilers and analyzers that the function cannot return.
+/// It is up to the compiler to remove any code past a call to functions
+/// flagged with this attribute.
+///
+#define NORETURN
+  #endif
+#endif
+
+//
+// Should be used in combination with ANALYZER_NORETURN to avoid 'noreturn'
+// returns warnings.
+//
+#ifndef ANALYZER_UNREACHABLE
+  #ifdef __clang_analyzer__
+#if __has_builtin (__builtin_unreachable)
+  ///
+  /// Signal the analyzer that this call is not reachable.
+  /// This excludes compilers.
+  ///
+  #define ANALYZER_UNREACHABLE()  __builtin_unreachable ()
+#endif
+  #endif
+
+  #ifndef ANALYZER_UNREACHABLE
+///
+/// Signal the analyzer that this call is not reachable.
+/// This excludes compilers.
+///
+#define ANALYZER_UNREACHABLE()
+  #endif
+#endif
+
+//
+// Static Analyzers may issue errors about potential NULL-dereferences when
+// dereferencing a pointer, that has been checked before, outside of a
+// NULL-check.  This may lead to false positives, such as when using ASSERT()
+// for verification.
+//
+#ifndef ANALYZER_NORETURN
+  #ifdef __has_feature
+#if __has_feature (attribute_analyzer_noreturn)
+  ///
+  /// Signal analyzers that the function cannot return.
+  /// This excludes compilers.
+  ///
+  #define ANALYZER_NORETURN  __attribute__((analyzer_noreturn))
+#endif
+  #endif
+
+  #ifndef ANALYZER_NORETURN
+///
+/// Signal the analyzer that the function cannot return.
+/// This excludes compilers.
+///
+#define ANALYZER_NORETURN
+  #endif
+#endif
+
+//
 // For symbol name in assembly code, an extra "_" is sometimes necessary
 //
 
-- 
2.9.0.windows.1

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

[edk2] [PATCH v2 2/4] MdePkg/DebugLib: Flag post-_ASSERT() as unreachable for analyzers.

[Marvin Häuser]

When a variable is compared to NULL as part of an ASSERT() call, the
code implies that the variable may be NULL. Certain Static Analyzers,
such as the Clang Static Analyzer, then issue false warnings for any
untested access of that pointer, even though that defeats the
intention behind ASSERT(). This patch flags the position after
_ASSERT() as unreachable for Static Analyzers to indicate that if the
variable is NULL, execution cannot pass.
As the ANALYZER-prefixed version is used, the executables will not
have any code stripped during compilation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Library/DebugLib.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdePkg/Include/Library/DebugLib.h 
b/MdePkg/Include/Library/DebugLib.h
index 93b6f8df34ae..803872cf3b32 100644
--- a/MdePkg/Include/Library/DebugLib.h
+++ b/MdePkg/Include/Library/DebugLib.h
@@ -291,6 +291,7 @@ DebugPrintLevelEnabled (
   if (DebugAssertEnabled ()) {  \
 if (!(Expression)) {\
   _ASSERT (Expression); \
+  ANALYZER_UNREACHABLE ();  \
 }   \
   } \
 } while (FALSE)
-- 
2.9.0.windows.1

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

[edk2] [PATCH v2 3/4] MdeModulePkg/Core: Decorate phase-transition functions with NORETURN.

[Marvin Häuser]

This patch adds the NORETURN attribute to functions that transfer to
other phases, along with an UNREACHABLE() call at the end to avoid
false warnings.
DxeIpl has been excluded as its main function returns a status.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 3 +++
 MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 5 +
 MdeModulePkg/Core/Pei/PeiMain.h | 1 +
 3 files changed, 9 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c 
b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
index c34067e11845..8380fd78bed8 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
+++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
@@ -235,6 +235,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED 
EFI_LOAD_FIXED_ADDRESS_CONFIGURATION_TABLEgLoa
 
 **/
 VOID
+NORETURN
 EFIAPI
 DxeMain (
   IN  VOID *HobStart
@@ -524,6 +525,8 @@ DxeMain (
   //
   ASSERT (FALSE);
   CpuDeadLoop ();
+
+  UNREACHABLE ();
 }
 
 
diff --git a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c 
b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
index 10db496140ad..59fdd2614b14 100644
--- a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
+++ b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
@@ -136,6 +136,7 @@ ShadowPeiCore (
 
 **/
 VOID
+NORETURN
 EFIAPI
 PeiCore (
   IN CONST EFI_SEC_PEI_HAND_OFF*SecCoreDataPtr,
@@ -275,6 +276,8 @@ PeiCore (
   //
   ASSERT (FALSE);
   CpuDeadLoop();
+
+  UNREACHABLE ();
 }
 
 //
@@ -468,4 +471,6 @@ PeiCore (
   //
   ASSERT_EFI_ERROR (Status);
   CpuDeadLoop();
+
+  UNREACHABLE ();
 }
diff --git a/MdeModulePkg/Core/Pei/PeiMain.h b/MdeModulePkg/Core/Pei/PeiMain.h
index 24983201d023..54331dabd844 100644
--- a/MdeModulePkg/Core/Pei/PeiMain.h
+++ b/MdeModulePkg/Core/Pei/PeiMain.h
@@ -315,6 +315,7 @@ typedef struct {
 
 **/
 VOID
+NORETURN
 EFIAPI
 PeiCore (
   IN CONST EFI_SEC_PEI_HAND_OFF*SecCoreData,
-- 
2.9.0.windows.1

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

[edk2] [PATCH v2 4/4] UefiCpuPkg/SecMain: Decorate phase-transition function with NORETURN.

[Marvin Häuser]

This patch adds the NORETURN attribute to the function that transfers
to the PEI phase, along with an UNREACHABLE() call at the end to
avoid false warnings.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 UefiCpuPkg/SecCore/SecMain.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/SecCore/SecMain.c b/UefiCpuPkg/SecCore/SecMain.c
index ec252cf719f5..5e5d543e1934 100644
--- a/UefiCpuPkg/SecCore/SecMain.c
+++ b/UefiCpuPkg/SecCore/SecMain.c
@@ -49,6 +49,7 @@ UINT64  mIdtEntryTemplate = 0x8e10ffe4ULL;
 
 **/
 VOID
+NORETURN
 EFIAPI
 SecStartupPhase2(
   IN VOID *Context
@@ -167,6 +168,7 @@ SecStartup (
 
 **/
 VOID
+NORETURN
 EFIAPI
 SecStartupPhase2(
   IN VOID *Context
@@ -252,7 +254,7 @@ SecStartupPhase2(
   //
   // Should not come here.
   //
-  return;
+  UNREACHABLE ();
 }
 
 /**
-- 
2.9.0.windows.1

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

[edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

[Marvin Häuser]

During exiting Boot Services, there should be no changes made to the
Memory Map. This patch eliminates calls to FreePool() and
CloseEvent() (which calls FreePool()) and instead zero's the memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c |  2 +-
 MdeModulePkg/Core/PiSmmCore/Smi.c   | 41 +---
 MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c |  6 ++-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 17 
 4 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index 7245f201fbdf..96e8da02bbc6 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -204,7 +204,7 @@ SmmExitBootServicesHandler (
  NULL
  );
 
-  SmiHandlerUnRegister (DispatchHandle);
+  SmiHandlerUnRegisterWorker (DispatchHandle, TRUE);
 
   return Status;
 }
diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c 
b/MdeModulePkg/Core/PiSmmCore/Smi.c
index 816d0f519360..a22606517f37 100644
--- a/MdeModulePkg/Core/PiSmmCore/Smi.c
+++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
@@ -280,9 +280,10 @@ SmiHandlerRegister (
 }
 
 /**
-  Unregister a handler in SMM.
+  Internal worker function to unregister a handler in SMM.
 
-  @param  DispatchHandle  The handle that was specified when the handler was 
registered.
+  @param  DispatchHandleThe handle that was specified when the handler was 
registered.
+  @param  ExitBootServices  Indicates whether or not ExitBootServices() is in 
progress.
 
   @retval EFI_SUCCESS   Handler function was successfully unregistered.
   @retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a valid 
handle.
@@ -290,8 +291,9 @@ SmiHandlerRegister (
 **/
 EFI_STATUS
 EFIAPI
-SmiHandlerUnRegister (
-  IN EFI_HANDLE  DispatchHandle
+SmiHandlerUnRegisterWorker (
+  IN  EFI_HANDLE  DispatchHandle,
+  IN  BOOLEAN ExitBootServices
   )
 {
   SMI_HANDLER  *SmiHandler;
@@ -310,7 +312,12 @@ SmiHandlerUnRegister (
   SmiEntry = SmiHandler->SmiEntry;
 
   RemoveEntryList (&SmiHandler->Link);
-  FreePool (SmiHandler);
+
+  if (!ExitBootServices) {
+FreePool (SmiHandler);
+  } else {
+ZeroMem (SmiHandler, sizeof (*SmiHandler));
+  }
 
   if (SmiEntry == NULL) {
 //
@@ -325,8 +332,30 @@ SmiHandlerUnRegister (
 //
 RemoveEntryList (&SmiEntry->AllEntries);
 
-FreePool (SmiEntry);
+if (!ExitBootServices) {
+  FreePool (SmiEntry);
+} else {
+  ZeroMem (SmiEntry, sizeof (*SmiEntry));
+}
   }
 
   return EFI_SUCCESS;
 }
+
+/**
+  Unregister a handler in SMM.
+
+  @param  DispatchHandle  The handle that was specified when the handler was 
registered.
+
+  @retval EFI_SUCCESS   Handler function was successfully unregistered.
+  @retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a valid 
handle.
+
+**/
+EFI_STATUS
+EFIAPI
+SmiHandlerUnRegister (
+  IN EFI_HANDLE  DispatchHandle
+  )
+{
+  return SmiHandlerUnRegisterWorker (DispatchHandle, FALSE);
+}
diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c 
b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
index ae202c3fe24a..a5a7368c8d39 100644
--- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
+++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
@@ -872,9 +872,11 @@ IScsiOnExitBootService (
   ISCSI_DRIVER_DATA *Private;
 
   Private = (ISCSI_DRIVER_DATA *) Context;
-  gBS->CloseEvent (Private->ExitBootServiceEvent);
 
-  IScsiSessionAbort (&Private->Session);
+  if (Private->Session.Signature != 0) {
+IScsiSessionAbort (&Private->Session);
+ZeroMem (&Private->Session, sizeof (Private->Session));
+  }
 }
 
 /**
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index 0e9c92abef9a..787786bfba9f 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -593,6 +593,23 @@ SmiHandlerRegister (
   );
 
 /**
+  Internal worker function to unregister a handler in SMM.
+
+  @param  DispatchHandleThe handle that was specified when the handler was 
registered.
+  @param  ExitBootServices  Indicates whether or not ExitBootServices() is in 
progress.
+
+  @retval EFI_SUCCESS   Handler function was successfully unregistered.
+  @retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a valid 
handle.
+
+**/
+EFI_STATUS
+EFIAPI
+SmiHandlerUnRegisterWorker (
+  IN  EFI_HANDLE  DispatchHandle,
+  IN  BOOLEAN ExitBootServices
+  );
+
+/**
   Unregister a handler in SMM.
 
   @param  DispatchHandle  The handle that was specified when the handler was 
registered.
-- 
2.9.0.windows.1

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

[edk2] [PATCH v1 2/2] NetworkPkg: Minimize usage of FreePool() during ExitBS().

[Marvin Häuser]

During exiting Boot Services, there should be no changes made to the
Memory Map. This patch eliminates calls to FreePool() and
CloseEvent() (which calls FreePool()) and instead zero's the memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 NetworkPkg/IScsiDxe/IScsiMisc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.c b/NetworkPkg/IScsiDxe/IScsiMisc.c
index a1f2672f3709..3d5e1d291cfd 100644
--- a/NetworkPkg/IScsiDxe/IScsiMisc.c
+++ b/NetworkPkg/IScsiDxe/IScsiMisc.c
@@ -1483,10 +1483,12 @@ IScsiOnExitBootService (
   ISCSI_DRIVER_DATA *Private;
 
   Private = (ISCSI_DRIVER_DATA *) Context;
-  gBS->CloseEvent (Private->ExitBootServiceEvent);
 
   if (Private->Session != NULL) {
 IScsiSessionAbort (Private->Session);
+ZeroMem (Private->Session, sizeof (*Private->Session));
+
+Private->Session = NULL;
   }
 }
 
-- 
2.9.0.windows.1

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

Re: [edk2] [PATCH v2 2/4] MdePkg/DebugLib: Flag post-_ASSERT() as unreachable for analyzers.

[Marvin Häuser]

Hey Liming,

Thanks for your comment! That is actually how my first local change looked 
like, though I noticed that this breaks the 'CR' macro in DebugLib.h, which 
uses _ASSERT() 'inline'.
Furthermore, I cannot think of any usage case where it would be beneficial 
other than NULL-checks.

Thanks,
Marvin.

> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Monday, June 20, 2016 10:20 AM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D 
> Subject: RE: [PATCH v2 2/4] MdePkg/DebugLib: Flag post-_ASSERT() as
> unreachable for analyzers.
> 
> Marvin:
>   I prefer to update _ASSERT macro like below. If so, ASSERT,
> ASSERT_EFI_ERROR and ASSERT_PROTOCOL_ALREADY_INSTALLED can all be
> hooked.
> 
> +#define _ASSERT(Expression)  \
> +do { \
> +  DebugAssert (__FILE__, __LINE__, #Expression); \
> +  ANALYZER_UNREACHABLE ();   \
> +} while (FALSE)
> 
> Thanks
> Liming
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Sunday, June 19, 2016 9:30 AM
> > To: edk2-devel@lists.01.org
> > Cc: Gao, Liming ; Kinney, Michael D
> > 
> > Subject: [PATCH v2 2/4] MdePkg/DebugLib: Flag post-_ASSERT() as
> > unreachable for analyzers.
> >
> > When a variable is compared to NULL as part of an ASSERT() call, the
> > code implies that the variable may be NULL. Certain Static Analyzers,
> > such as the Clang Static Analyzer, then issue false warnings for any
> > untested access of that pointer, even though that defeats the
> > intention behind ASSERT(). This patch flags the position after
> > _ASSERT() as unreachable for Static Analyzers to indicate that if the
> > variable is NULL, execution cannot pass.
> > As the ANALYZER-prefixed version is used, the executables will not
> > have any code stripped during compilation.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  MdePkg/Include/Library/DebugLib.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/MdePkg/Include/Library/DebugLib.h
> > b/MdePkg/Include/Library/DebugLib.h
> > index 93b6f8df34ae..803872cf3b32 100644
> > --- a/MdePkg/Include/Library/DebugLib.h
> > +++ b/MdePkg/Include/Library/DebugLib.h
> > @@ -291,6 +291,7 @@ DebugPrintLevelEnabled (
> >if (DebugAssertEnabled ()) {  \
> >  if (!(Expression)) {\
> >_ASSERT (Expression); \
> > +  ANALYZER_UNREACHABLE ();  \
> >  }   \
> >} \
> >  } while (FALSE)
> > --
> > 2.9.0.windows.1

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

Re: [edk2] [PATCH v2 3/4] MdeModulePkg/Core: Decorate phase-transition functions with NORETURN.

[Marvin Häuser]

Hey Liming,

As said in the commit message: 'DxeIpl has been excluded as its main function 
returns a status.'
The function has a return value, so, when we add the UNREACHABLE() call, the 
supported compilers will complain about a return statement past unreachable 
code - or about a function with a return value not always returning.

Thanks,
Marvin.

> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Monday, June 20, 2016 10:22 AM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: Tian, Feng ; Zeng, Star 
> Subject: RE: [PATCH v2 3/4] MdeModulePkg/Core: Decorate phase-transition
> functions with NORETURN.
> 
> Marvin:
>   One is missing. Could you add it?
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe
> IplPeim/DxeLoad.c#L432
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin Häuser
> > Sent: Sunday, June 19, 2016 9:31 AM
> > To: edk2-devel@lists.01.org
> > Cc: Tian, Feng ; Zeng, Star 
> > Subject: [edk2] [PATCH v2 3/4] MdeModulePkg/Core: Decorate phase-
> > transition functions with NORETURN.
> >
> > This patch adds the NORETURN attribute to functions that transfer to
> > other phases, along with an UNREACHABLE() call at the end to avoid
> > false warnings.
> > DxeIpl has been excluded as its main function returns a status.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 3 +++
> > MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 5 +
> >  MdeModulePkg/Core/Pei/PeiMain.h | 1 +
> >  3 files changed, 9 insertions(+)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> > b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> > index c34067e11845..8380fd78bed8 100644
> > --- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> > +++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> > @@ -235,6 +235,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED
> > EFI_LOAD_FIXED_ADDRESS_CONFIGURATION_TABLEgLoa
> >
> >  **/
> >  VOID
> > +NORETURN
> >  EFIAPI
> >  DxeMain (
> >IN  VOID *HobStart
> > @@ -524,6 +525,8 @@ DxeMain (
> >//
> >ASSERT (FALSE);
> >CpuDeadLoop ();
> > +
> > +  UNREACHABLE ();
> >  }
> >
> >
> > diff --git a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> > b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> > index 10db496140ad..59fdd2614b14 100644
> > --- a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> > +++ b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> > @@ -136,6 +136,7 @@ ShadowPeiCore (
> >
> >  **/
> >  VOID
> > +NORETURN
> >  EFIAPI
> >  PeiCore (
> >IN CONST EFI_SEC_PEI_HAND_OFF*SecCoreDataPtr,
> > @@ -275,6 +276,8 @@ PeiCore (
> >//
> >ASSERT (FALSE);
> >CpuDeadLoop();
> > +
> > +  UNREACHABLE ();
> >  }
> >
> >  //
> > @@ -468,4 +471,6 @@ PeiCore (
> >//
> >ASSERT_EFI_ERROR (Status);
> >CpuDeadLoop();
> > +
> > +  UNREACHABLE ();
> >  }
> > diff --git a/MdeModulePkg/Core/Pei/PeiMain.h
> > b/MdeModulePkg/Core/Pei/PeiMain.h index
> 24983201d023..54331dabd844
> > 100644
> > --- a/MdeModulePkg/Core/Pei/PeiMain.h
> > +++ b/MdeModulePkg/Core/Pei/PeiMain.h
> > @@ -315,6 +315,7 @@ typedef struct {
> >
> >  **/
> >  VOID
> > +NORETURN
> >  EFIAPI
> >  PeiCore (
> >IN CONST EFI_SEC_PEI_HAND_OFF*SecCoreData,
> > --
> > 2.9.0.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

[Marvin Häuser]

Hey Star,

Thanks for your input! I agree, this has been a plain oversight by me.
Would you be fine with a V2 of this patch lacking the modifications to the SMM 
code? There has  been another place this change has been applied to - 
IScsiMisc.c.

Thanks,
Marvin.

> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Monday, June 20, 2016 5:22 AM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Tian, Feng ; Zeng, Star 
> Subject: RE: [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool()
> during ExitBS().
> 
> Hi Marvin,
> 
> 1. The memory allocate and free in PiSmmCore are SMRAM that is not
> related to UEFI memory map.
> 2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader should have
> got the memory map before ExitBootServices.
> That means the memory free should not impact the memory map *got by
> UEFI OS loader*, it will only impact the memory map if the UEFI OS loader will
> call GetMemoryMap() again.
> 
> "A UEFI OS loader must ensure that it has the system's current memory map
> at the time it calls ExitBootServices(). This is done by passing in the 
> current
> memory map's MapKey value as returned by
> EFI_BOOT_SERVICES.GetMemoryMap()."
> 
> Thanks,
> Star
> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Monday, June 20, 2016 1:08 AM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng ; Zeng, Star 
> Subject: [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool()
> during ExitBS().
> 
> During exiting Boot Services, there should be no changes made to the
> Memory Map. This patch eliminates calls to FreePool() and
> CloseEvent() (which calls FreePool()) and instead zero's the memory.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Marvin Haeuser 
> ---
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.c |  2 +-
>  MdeModulePkg/Core/PiSmmCore/Smi.c   | 41
> +---
>  MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c |  6 ++-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 17 
>  4 files changed, 57 insertions(+), 9 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> index 7245f201fbdf..96e8da02bbc6 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> @@ -204,7 +204,7 @@ SmmExitBootServicesHandler (
>   NULL
>   );
> 
> -  SmiHandlerUnRegister (DispatchHandle);
> +  SmiHandlerUnRegisterWorker (DispatchHandle, TRUE);
> 
>return Status;
>  }
> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
> b/MdeModulePkg/Core/PiSmmCore/Smi.c
> index 816d0f519360..a22606517f37 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
> @@ -280,9 +280,10 @@ SmiHandlerRegister (  }
> 
>  /**
> -  Unregister a handler in SMM.
> +  Internal worker function to unregister a handler in SMM.
> 
> -  @param  DispatchHandle  The handle that was specified when the handler
> was registered.
> +  @param  DispatchHandleThe handle that was specified when the
> handler was registered.
> +  @param  ExitBootServices  Indicates whether or not ExitBootServices() is in
> progress.
> 
>@retval EFI_SUCCESS   Handler function was successfully 
> unregistered.
>@retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a valid
> handle.
> @@ -290,8 +291,9 @@ SmiHandlerRegister (  **/  EFI_STATUS  EFIAPI -
> SmiHandlerUnRegister (
> -  IN EFI_HANDLE  DispatchHandle
> +SmiHandlerUnRegisterWorker (
> +  IN  EFI_HANDLE  DispatchHandle,
> +  IN  BOOLEAN ExitBootServices
>)
>  {
>SMI_HANDLER  *SmiHandler;
> @@ -310,7 +312,12 @@ SmiHandlerUnRegister (
>SmiEntry = SmiHandler->SmiEntry;
> 
>RemoveEntryList (&SmiHandler->Link);
> -  FreePool (SmiHandler);
> +
> +  if (!ExitBootServices) {
> +FreePool (SmiHandler);
> +  } else {
> +ZeroMem (SmiHandler, sizeof (*SmiHandler));  }
> 
>if (SmiEntry == NULL) {
>  //
> @@ -325,8 +332,30 @@ SmiHandlerUnRegister (
>  //
>  RemoveEntryList (&SmiEntry->AllEntries);
> 
> -FreePool (SmiEntry);
> +if (!ExitBootServices) {
> +  FreePool (SmiEntry);
> +} else {
> +  ZeroMem (SmiEntry, sizeof (*SmiEntry));
> +}
>}
> 
>return EFI_SUCCESS;
>  }
> +
> +/**
> +  Unregister a handler in SMM.
> +
> +  @param  DispatchHandle  The handle that was specified when the handler
> was registered.
> +
> +  @retval EFI_SUCCESS   Handler functio

Re: [edk2] StdLib usage for drivers?

[Marvin Häuser]

Hey Michael,

Thank you for your input! This looks interesting.
Maybe it would be a good idea to provide the libraries that depend on Shell (in 
master) with functions that call ASSERT (FALSE); for drivers? I do not need 
file I/O, so I think your modifications might work out well for me. Would be 
very nice of course if such changes found their way upstream. :)

And thank you very much for your comment as well, Andrew! It makes sense that 
StdLib is primarily targeted at porting console applications to UEFI Shell.

Regards,
Marvin.

From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
Sent: Wednesday, June 22, 2016 10:28 PM
To: Marvin H?user 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] StdLib usage for drivers?

In my fork of edk2 I've added support for using StdLib without the Shell.
It's quite hacky(setenv/getenv are stubs, no File IO and maybe other things 
hidden by linker GC and me not using all features).

But depending on which StdLib features you need this can work pretty good.

here's the commit that does the magic:
https://github.com/efidroid/edk2/commit/bf7a296718486bafaf774ea8bcf187c162c3c167

and this is how you convert a Shell project to a NonShell one:
https://github.com/efidroid/uefi_apps_EFIDroidUi/commit/23f0fa08108b8f852564fae733c6a7bce62e2070

as you can see it works by using StdLib with different libraries/cflags so you 
have to compile your driver separately if there are other modules which need 
the normal StdLib.

Thanks
Michael

On Wed, Jun 22, 2016 at 9:38 PM, Marvin H?user 
mailto:marvin.haeu...@outlook.com>> wrote:
Dear EDK2 developers,

For an experimental project, I'm currently attempting to write a library 
wrapper for the disassembler library 'Capstone' in a similar manner to 
CryptoPkg's OpensslLib. As most C libraries, it also depends on the standard 
headers, which are not provided by 'stock' EDK2. My first guess has been to use 
StdLib, though its description states:
'Due to the execution environment built by the StdLib component, execution as a 
UEFI driver can cause system stability issues.'

Inspecting OpensslLib I discovered that CryptoPkg deploys its own include files 
for StdLib. Though, from your experience, what are the issues with using 
StdLibPkg with DXE/UEFI drivers? It might be nice to reduce duplicate code, 
though I honestly don't know anything about StdLibPkg and its implementation 
and would be thankful for some insight on that manner.

Thank you in advance for your time!

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

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

Re: [edk2] StdLib usage for drivers?

[Marvin Häuser]

Daryl, Jaben,

As you are the package maintainers of StdLib, could you please comment on the 
situation?
If modifications to have StdLib working for drivers are welcome, I would offer 
my help in cleaning up the existing stuff and/or write my own patches, though 
of course there is little point if there is no reaction from the reviewers.
If it is of any interest, I want to write a shim library for Capstone and would 
prefer not to have three copies of Std functions in my tree (StdLib, CryptoPkg 
(SSL) and Capstone), but rather an improved StdLib that works for all.

Thanks to those who have offered alternative solutions, but I prefer to keep it 
‚clean‘ and have the libraries shipping with EDK2 work. :)

Regards,
Marvin.

From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
Sent: Thursday, June 23, 2016 5:32 AM
To: Marvin Häuser 
Cc: edk2-devel@lists.01.org; af...@apple.com
Subject: Re: [edk2] StdLib usage for drivers?

well for the patch to go upstream it would have to get improved a lot.
I've tried to implement this in a way that doesn't need a different dsc but the 
problem is that ShellLib's constructor ASSERT's if it can't find the shell 
protocol and removing that would probably be against the spec's.

Also it appears that the StdLib maintainers are kinda busy because most of the 
StdLib patches I've sent to this mailing list didn't get reviewed.

Thanks
Michael

On Wed, Jun 22, 2016 at 10:37 PM, Marvin Häuser 
mailto:marvin.haeu...@outlook.com>> wrote:
Hey Michael,

Thank you for your input! This looks interesting.
Maybe it would be a good idea to provide the libraries that depend on Shell (in 
master) with functions that call ASSERT (FALSE); for drivers? I do not need 
file I/O, so I think your modifications might work out well for me. Would be 
very nice of course if such changes found their way upstream. :)

And thank you very much for your comment as well, Andrew! It makes sense that 
StdLib is primarily targeted at porting console applications to UEFI Shell.

Regards,
Marvin.

From: Michael Zimmermann 
[mailto:sigmaepsilo...@gmail.com<mailto:sigmaepsilo...@gmail.com>]
Sent: Wednesday, June 22, 2016 10:28 PM
To: Marvin H?user 
mailto:marvin.haeu...@outlook.com>>
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Subject: Re: [edk2] StdLib usage for drivers?

In my fork of edk2 I've added support for using StdLib without the Shell.
It's quite hacky(setenv/getenv are stubs, no File IO and maybe other things 
hidden by linker GC and me not using all features).

But depending on which StdLib features you need this can work pretty good.

here's the commit that does the magic:
https://github.com/efidroid/edk2/commit/bf7a296718486bafaf774ea8bcf187c162c3c167

and this is how you convert a Shell project to a NonShell one:
https://github.com/efidroid/uefi_apps_EFIDroidUi/commit/23f0fa08108b8f852564fae733c6a7bce62e2070

as you can see it works by using StdLib with different libraries/cflags so you 
have to compile your driver separately if there are other modules which need 
the normal StdLib.

Thanks
Michael

On Wed, Jun 22, 2016 at 9:38 PM, Marvin H?user 
mailto:marvin.haeu...@outlook.com><mailto:marvin.haeu...@outlook.com<mailto:marvin.haeu...@outlook.com>>>
 wrote:
Dear EDK2 developers,

For an experimental project, I'm currently attempting to write a library 
wrapper for the disassembler library 'Capstone' in a similar manner to 
CryptoPkg's OpensslLib. As most C libraries, it also depends on the standard 
headers, which are not provided by 'stock' EDK2. My first guess has been to use 
StdLib, though its description states:
'Due to the execution environment built by the StdLib component, execution as a 
UEFI driver can cause system stability issues.'

Inspecting OpensslLib I discovered that CryptoPkg deploys its own include files 
for StdLib. Though, from your experience, what are the issues with using 
StdLibPkg with DXE/UEFI drivers? It might be nice to reduce duplicate code, 
though I honestly don't know anything about StdLibPkg and its implementation 
and would be thankful for some insight on that manner.

Thank you in advance for your time!

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

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

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

[edk2] [PATCH v1 1/1] BaseTools/toolsetup: Do not set CONF_PATH when already set.

[Marvin Häuser]

When CONF_PATH is already set, toolsetup.bat overwrites its value.
This is not the case on Linux platforms (BuildEnv) and
contra-productive when using the same Workspace across multiple
Operating Systems.
With this patch, a check is performed prior to setting the variable.
Furthermore, it will not be scanned for Conf directories in
PACKAGES_PATH directories to respect the user's choice.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 BaseTools/toolsetup.bat | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/BaseTools/toolsetup.bat b/BaseTools/toolsetup.bat
index 76fd8bb6ef9e..c1ab9bcc8d33 100755
--- a/BaseTools/toolsetup.bat
+++ b/BaseTools/toolsetup.bat
@@ -160,13 +160,16 @@ if not defined WORKSPACE (
goto skip_reconfig
 )
 
-set CONF_PATH=%WORKSPACE%\Conf
-if NOT exist %CONF_PATH% (
-  if defined PACKAGES_PATH (
-for %%i IN (%PACKAGES_PATH%) DO (
-  if exist %%~fi\Conf (
-set CONF_PATH=%%i\Conf
-goto CopyConf
+if not defined CONF_PATH (
+  set CONF_PATH=%WORKSPACE%\Conf
+
+  if NOT exist %CONF_PATH% (
+if defined PACKAGES_PATH (
+  for %%i IN (%PACKAGES_PATH%) DO (
+if exist %%~fi\Conf (
+  set CONF_PATH=%%i\Conf
+  goto CopyConf
+)
   )
 )
   )
-- 
2.9.0.windows.1

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

Re: [edk2] Intel FSP Firmware Volume content

[Marvin Häuser]

Hey Rafael and Giri,

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

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

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

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

Thanks again for your time!

Best regards,
Marvin.

> -Original Message-
> From: Mudusuru, Giri P [mailto:giri.p.mudus...@intel.com]
> Sent: Friday, July 8, 2016 9:38 AM
> To: Rafael Machado ; Marvin H?user
> ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Mudusuru, Giri P
> 
> Subject: RE: [edk2] Intel FSP Firmware Volume content
> 
> Hi Marvin, Rafael,
> 
> Thank you for your studies on FSP.
> 
> FSP is a self-contained binary. Since the silicon code implementation is based
> on edk2, some modules are redundant like PeiCore, DxeIpl as Rafael
> explained below (Thanks Rafael).
> While it is redundant, it is a small price to make FSP binary pluggable into
> different bootloaders (EDK2, Coreboot etc...)
> 
> Also entire FSP is implemented in PEI phase and DXE code is built in Dual
> mode (DXE and PEI for FSP) which is why you see *DxeFsp
> 
> Hope this clarifies your questions
> 
> Thanks and Regards,
> -Giri
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Rafael Machado
> > Sent: Thursday, July 7, 2016 4:31 AM
> > To: Marvin H?user ;
> > edk2-devel@lists.01.org
> > Cc: Yao, Jiewen 
> > Subject: Re: [edk2] Intel FSP Firmware Volume content
> >
> > Hi Marvin
> >
> > I'm also starting my studies on FSP, but I think I can help with at
> > least one of the questions.
> > About the two Sec cores.
> >
> > The existence of two sec cores represents what is called "FSP Normal Boot"
> > There is the main sec core, and another sec core that is placed inside
> > the FspInitPei. They communicate to each other so the needed
> > information is passed correctly.
> >
> > Each sec core has it's responsibilities, so they don't do the same thing.
> >
> > Hope this can help you to find more information.
> >
> > Thanks and Regards
> > Rafael R. Machado
> >
> >
> >
> > Em qua, 6 de jul de 2016 às 20:40, Marvin H?user
> > 
> > escreveu:
> >
> > > Dear EDK2 community members,
> > >
> > > Recently, I have gained interest in the Intel FSP and have been
> > > reading the Intel documents regarding its design and integration with
> EDK2.
> > > In the white paper 'A Tour Beyond BIOS Using the Intel(r) Firmware
> > > Support Package with the EFI Developer Kit II', the chapter 'FSP Wrapper
> Boot Flow'
> > > mentions different ways of how SecCore and following can interact with
> FSP.
> > > This, in my opinion, implies that SecCore is present in source-form
> > > (likely IntelFspWrapperPkg/FspWrapperSecCore), while the actual
> > > silicon initialization is of course within the FSP binary. This is
> > > how I understood it and thought it made sense.
> > > However, when I opened a few of the FSP Firmware Volume files, I
> > > discovered that it did not only have the FSP header and
> > > initialization PEIMs/drivers, but also SecCore, PeiCore 

[edk2] [PATCH v1 1/1] MdeModulePkg/PeiCore: Fix ConverSinglePpiPointer () typo.

[Marvin Häuser]

Rename ConverSinglePpiPointer () to ConvertSinglePpiPointer ().

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Core/Pei/Ppi/Ppi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/Ppi/Ppi.c b/MdeModulePkg/Core/Pei/Ppi/Ppi.c
index 706e835a7091..db6eded6d6ed 100644
--- a/MdeModulePkg/Core/Pei/Ppi/Ppi.c
+++ b/MdeModulePkg/Core/Pei/Ppi/Ppi.c
@@ -48,7 +48,7 @@ InitializePpiServices (
 
 **/
 VOID
-ConverSinglePpiPointer (
+ConvertSinglePpiPointer (
   IN PEI_PPI_LIST_POINTERS *PpiPointer,
   IN UINTN TempBottom,
   IN UINTN TempTop,
@@ -124,7 +124,7 @@ ConvertPpiPointers (
   //
   // Convert PPI pointer in old Heap
   //
-  ConverSinglePpiPointer (
+  ConvertSinglePpiPointer (
 &PrivateData->PpiData.PpiListPtrs[Index],
 (UINTN)SecCoreData->PeiTemporaryRamBase,
 (UINTN)SecCoreData->PeiTemporaryRamBase + 
SecCoreData->PeiTemporaryRamSize,
@@ -135,7 +135,7 @@ ConvertPpiPointers (
   //
   // Convert PPI pointer in old Stack
   //
-  ConverSinglePpiPointer (
+  ConvertSinglePpiPointer (
 &PrivateData->PpiData.PpiListPtrs[Index],
 (UINTN)SecCoreData->StackBase,
 (UINTN)SecCoreData->StackBase + SecCoreData->StackSize,
@@ -151,7 +151,7 @@ ConvertPpiPointers (
   continue;
 }
 
-ConverSinglePpiPointer (
+ConvertSinglePpiPointer (
   &PrivateData->PpiData.PpiListPtrs[Index],
   (UINTN)PrivateData->HoleData[IndexHole].Base,
   (UINTN)PrivateData->HoleData[IndexHole].Base + 
PrivateData->HoleData[IndexHole].Size,
-- 
2.9.0.windows.1

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

[edk2] [PATCH] BaseTools/tools_def: Use armv7-a for CLANG35 ARM compilations.

[Marvin Häuser]

Define "-march=armv7-a" - which is used by the GCC toolchains - for
ARM CLAMNG35 builds to fix compilation of the MemoryFence ASM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Conf/tools_def.template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 57455ac9f2f3..ab4f936e7a8b 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -5459,7 +5459,7 @@ DEFINE CLANG35_AARCH64_CC_FLAGS  = 
DEF(GCC_AARCH64_CC_FLAGS) DEF(CLANG35_AARCH64
 *_CLANG35_ARM_ASM_FLAGS  = DEF(GCC_ASM_FLAGS) DEF(CLANG35_ARM_TARGET) 
$(ARCHASM_FLAGS) $(PLATFORM_FLAGS) -Qunused-arguments
 *_CLANG35_ARM_DLINK_FLAGS= DEF(CLANG35_ARM_TARGET) 
DEF(GCC_ARM_DLINK_FLAGS)
 *_CLANG35_ARM_DLINK2_FLAGS   = DEF(GCC_DLINK2_FLAGS_COMMON) 
-Wl,--defsym=PECOFF_HEADER_SIZE=0x220
-*_CLANG35_ARM_PLATFORM_FLAGS =
+*_CLANG35_ARM_PLATFORM_FLAGS = -march=armv7-a
 *_CLANG35_ARM_PP_FLAGS   = DEF(GCC_PP_FLAGS) DEF(CLANG35_ARM_TARGET) 
$(ARCHCC_FLAGS) $(PLATFORM_FLAGS)
 *_CLANG35_ARM_RC_FLAGS   = DEF(GCC_ARM_RC_FLAGS)
 *_CLANG35_ARM_VFRPP_FLAGS= DEF(GCC_VFRPP_FLAGS) 
DEF(CLANG35_ARM_TARGET) $(ARCHCC_FLAGS) $(PLATFORM_FLAGS)
-- 
2.11.1.windows.1

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

[edk2] [PATCH] BaseTools/CLANG: set -Wno-unused-but-set-variable on RELEASE builds

[Marvin Häuser]

Set -Wno-unused-but-set-variable on RELEASE builds so variables only
verified in DEBUG code (e.g. ASSERT()) do not trigger build errors.
This is done to align with GCC compilation:
https://github.com/tianocore/edk2/commit/20d00edf21d2f2144921622891d8b59a1553cd83

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Conf/tools_def.template | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index ab4f936e7a8b..b9a063215354 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -5467,7 +5467,7 @@ DEFINE CLANG35_AARCH64_CC_FLAGS  = 
DEF(GCC_AARCH64_CC_FLAGS) DEF(CLANG35_AARCH64
 *_CLANG35_ARM_CC_XIPFLAGS= DEF(GCC_ARM_CC_XIPFLAGS)
 
   DEBUG_CLANG35_ARM_CC_FLAGS = DEF(CLANG35_ARM_CC_FLAGS) $(ARCHCC_FLAGS) 
$(PLATFORM_FLAGS) -O0
-RELEASE_CLANG35_ARM_CC_FLAGS = DEF(CLANG35_ARM_CC_FLAGS) $(ARCHCC_FLAGS) 
$(PLATFORM_FLAGS) -Oz
+RELEASE_CLANG35_ARM_CC_FLAGS = DEF(CLANG35_ARM_CC_FLAGS) $(ARCHCC_FLAGS) 
$(PLATFORM_FLAGS) -Oz -Wno-unused-but-set-variable
 
 ##
 # CLANG35 AARCH64 definitions
@@ -5489,7 +5489,7 @@ RELEASE_CLANG35_ARM_CC_FLAGS = 
DEF(CLANG35_ARM_CC_FLAGS) $(ARCHCC_FLAGS) $(P
 *_CLANG35_AARCH64_CC_XIPFLAGS= DEF(GCC_AARCH64_CC_XIPFLAGS)
 
   DEBUG_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) 
$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -O0
-RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) 
$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -Oz -fomit-frame-pointer
+RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) 
$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -Oz -fomit-frame-pointer 
-Wno-unused-but-set-variable
 
 

 #
@@ -5543,7 +5543,7 @@ DEBUG_CLANG38_IA32_CC_FLAGS = 
DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -
 DEBUG_CLANG38_IA32_DLINK_FLAGS  = DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto 
-Wl,-Oz -Wl,-melf_i386 -Wl,--oformat=elf32-i386
 DEBUG_CLANG38_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS) -O3
 
-RELEASE_CLANG38_IA32_CC_FLAGS   = DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto 
-march=i586 DEF(CLANG38_IA32_TARGET)
+RELEASE_CLANG38_IA32_CC_FLAGS   = DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto 
-march=i586 DEF(CLANG38_IA32_TARGET) -Wno-unused-but-set-variable
 RELEASE_CLANG38_IA32_DLINK_FLAGS= DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto 
-Wl,-Oz -Wl,-melf_i386 -Wl,--oformat=elf32-i386
 RELEASE_CLANG38_IA32_DLINK2_FLAGS   = DEF(GCC5_IA32_DLINK2_FLAGS) -O3
 
@@ -5580,7 +5580,7 @@ DEBUG_CLANG38_X64_CC_FLAGS = 
DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__
 DEBUG_CLANG38_X64_DLINK_FLAGS  = DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto 
-Wl,-Oz -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,-pie -mcmodel=small
 DEBUG_CLANG38_X64_DLINK2_FLAGS = DEF(GCC5_X64_DLINK2_FLAGS) -O3
 
-RELEASE_CLANG38_X64_CC_FLAGS   = DEF(CLANG38_ALL_CC_FLAGS) -m64 
"-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto 
DEF(CLANG38_X64_TARGET)
+RELEASE_CLANG38_X64_CC_FLAGS   = DEF(CLANG38_ALL_CC_FLAGS) -m64 
"-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto 
DEF(CLANG38_X64_TARGET) -Wno-unused-but-set-variable
 RELEASE_CLANG38_X64_DLINK_FLAGS= DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto 
-Wl,-Oz -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,-pie -mcmodel=small
 RELEASE_CLANG38_X64_DLINK2_FLAGS   = DEF(GCC5_X64_DLINK2_FLAGS) -O3
 
-- 
2.11.1.windows.1

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

Re: [edk2] [PATCH] BaseTools/CLANG: set -Wno-unused-but-set-variable on RELEASE builds

[Marvin Häuser]

Please do not push this commit, I just bumped into a compilation error which I 
did not see before.
I'll post a V2 once I figured out what happened.

Thanks,
Marvin.

> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Monday, March 6, 2017 3:27 AM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Zhu, Yonghong 
> Subject: RE: [PATCH] BaseTools/CLANG: set -Wno-unused-but-set-variable
> on RELEASE builds
> 
> Reviewed-by: Liming Gao 
> 
> >-----Original Message-
> >From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> >Sent: Sunday, March 05, 2017 11:00 AM
> >To: edk2-devel@lists.01.org
> >Cc: Gao, Liming ; Zhu, Yonghong
> >
> >Subject: [PATCH] BaseTools/CLANG: set -Wno-unused-but-set-variable on
> >RELEASE builds
> >
> >Set -Wno-unused-but-set-variable on RELEASE builds so variables only
> >verified in DEBUG code (e.g. ASSERT()) do not trigger build errors.
> >This is done to align with GCC compilation:
> >https://github.com/tianocore/edk2/commit/20d00edf21d2f2144921622891
> d8
> >b59a1553cd83
> >
> >Contributed-under: TianoCore Contribution Agreement 1.0
> >Signed-off-by: Marvin Haeuser 
> >---
> > BaseTools/Conf/tools_def.template | 8 
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> >diff --git a/BaseTools/Conf/tools_def.template
> >b/BaseTools/Conf/tools_def.template
> >index ab4f936e7a8b..b9a063215354 100755
> >--- a/BaseTools/Conf/tools_def.template
> >+++ b/BaseTools/Conf/tools_def.template
> >@@ -5467,7 +5467,7 @@ DEFINE CLANG35_AARCH64_CC_FLAGS  =
> >DEF(GCC_AARCH64_CC_FLAGS) DEF(CLANG35_AARCH64
> > *_CLANG35_ARM_CC_XIPFLAGS= DEF(GCC_ARM_CC_XIPFLAGS)
> >
> >   DEBUG_CLANG35_ARM_CC_FLAGS = DEF(CLANG35_ARM_CC_FLAGS)
> >$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -O0
> >-RELEASE_CLANG35_ARM_CC_FLAGS = DEF(CLANG35_ARM_CC_FLAGS)
> >$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -Oz
> >+RELEASE_CLANG35_ARM_CC_FLAGS = DEF(CLANG35_ARM_CC_FLAGS)
> >$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -Oz -Wno-unused-but-set-
> variable
> >
> > ##
> > # CLANG35 AARCH64 definitions
> >@@ -5489,7 +5489,7 @@ RELEASE_CLANG35_ARM_CC_FLAGS =
> >DEF(CLANG35_ARM_CC_FLAGS) $(ARCHCC_FLAGS) $(P
> > *_CLANG35_AARCH64_CC_XIPFLAGS=
> DEF(GCC_AARCH64_CC_XIPFLAGS)
> >
> >   DEBUG_CLANG35_AARCH64_CC_FLAGS =
> >DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
> $(PLATFORM_FLAGS)
> >-O0
> >-RELEASE_CLANG35_AARCH64_CC_FLAGS =
> >DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
> $(PLATFORM_FLAGS) -Oz
> >-fomit-frame-pointer
> >+RELEASE_CLANG35_AARCH64_CC_FLAGS =
> >DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
> $(PLATFORM_FLAGS) -Oz
> >-fomit-frame-pointer -Wno-unused-but-set-variable
> >
> >
> >#
> ##
> >#
> > #
> >@@ -5543,7 +5543,7 @@ DEBUG_CLANG38_IA32_CC_FLAGS =
> >DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -
> > DEBUG_CLANG38_IA32_DLINK_FLAGS  =
> >DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto -Wl,-Oz -Wl,-melf_i386 -Wl,--
> >oformat=elf32-i386
> > DEBUG_CLANG38_IA32_DLINK2_FLAGS =
> DEF(GCC5_IA32_DLINK2_FLAGS)
> >-O3
> >
> >-RELEASE_CLANG38_IA32_CC_FLAGS   = DEF(CLANG38_ALL_CC_FLAGS) -
> >m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET)
> >+RELEASE_CLANG38_IA32_CC_FLAGS   = DEF(CLANG38_ALL_CC_FLAGS) -
> >m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET) -Wno-unused-but-
> >set-variable
> > RELEASE_CLANG38_IA32_DLINK_FLAGS=
> >DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto -Wl,-Oz -Wl,-melf_i386 -Wl,--
> >oformat=elf32-i386
> > RELEASE_CLANG38_IA32_DLINK2_FLAGS   =
> DEF(GCC5_IA32_DLINK2_FLAGS)
> >-O3
> >
> >@@ -5580,7 +5580,7 @@ DEBUG_CLANG38_X64_CC_FLAGS =
> >DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__
> > DEBUG_CLANG38_X64_DLINK_FLAGS  =
> >DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto -Wl,-Oz -Wl,-melf_x86_64 -Wl,--
> >oformat=elf64-x86-64 -Wl,-pie -mcmodel=small
> > DEBUG_CLANG38_X64_DLINK2_FLAGS = DEF(GCC5_X64_DLINK2_FLAGS)
> -
> >O3
> >
> >-RELEASE_CLANG38_X64_CC_FLAGS   = DEF(CLANG38_ALL_CC_FLAGS) -
> >m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -
> >fpie -Oz -flto DEF(CLANG38_X64_TARGET)
> >+RELEASE_CLANG38_X64_CC_FLAGS   = DEF(CLANG38_ALL_CC_FLAGS) -
> >m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -
> >fpie -Oz -flto DEF(CLANG38_X64_TARGET) -Wno-unused-but-set-variable
> > RELEASE_CLANG38_X64_DLINK_FLAGS=
> >DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto -Wl,-Oz -Wl,-melf_x86_64 -Wl,--
> >oformat=elf64-x86-64 -Wl,-pie -mcmodel=small
> > RELEASE_CLANG38_X64_DLINK2_FLAGS   =
> DEF(GCC5_X64_DLINK2_FLAGS) -
> >O3
> >
> >--
> >2.11.1.windows.1

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

Re: [edk2] [PATCH] BaseTools/CLANG: set -Wno-unused-but-set-variable on RELEASE builds

[Marvin Häuser]

Sorry, the reason for the commit was caused by a misconfiguration of my 
workspace.
The commit can be discarded, no V2 needed. Sorry for any inconvenience.

Regards,
Marvin.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Marvin Häuser
> Sent: Tuesday, March 7, 2017 2:56 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: Re: [edk2] [PATCH] BaseTools/CLANG: set -Wno-unused-but-set-
> variable on RELEASE builds
> 
> Please do not push this commit, I just bumped into a compilation error which
> I did not see before.
> I'll post a V2 once I figured out what happened.
> 
> Thanks,
> Marvin.
> 
> > -Original Message-
> > From: Gao, Liming [mailto:liming@intel.com]
> > Sent: Monday, March 6, 2017 3:27 AM
> > To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > Cc: Zhu, Yonghong 
> > Subject: RE: [PATCH] BaseTools/CLANG: set -Wno-unused-but-set-variable
> > on RELEASE builds
> >
> > Reviewed-by: Liming Gao 
> >
> > >-Original Message-
> > >From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > >Sent: Sunday, March 05, 2017 11:00 AM
> > >To: edk2-devel@lists.01.org
> > >Cc: Gao, Liming ; Zhu, Yonghong
> > >
> > >Subject: [PATCH] BaseTools/CLANG: set -Wno-unused-but-set-variable
> on
> > >RELEASE builds
> > >
> > >Set -Wno-unused-but-set-variable on RELEASE builds so variables only
> > >verified in DEBUG code (e.g. ASSERT()) do not trigger build errors.
> > >This is done to align with GCC compilation:
> >
> >https://github.com/tianocore/edk2/commit/20d00edf21d2f2144921622891
> > d8
> > >b59a1553cd83
> > >
> > >Contributed-under: TianoCore Contribution Agreement 1.0
> > >Signed-off-by: Marvin Haeuser 
> > >---
> > > BaseTools/Conf/tools_def.template | 8 
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > >diff --git a/BaseTools/Conf/tools_def.template
> > >b/BaseTools/Conf/tools_def.template
> > >index ab4f936e7a8b..b9a063215354 100755
> > >--- a/BaseTools/Conf/tools_def.template
> > >+++ b/BaseTools/Conf/tools_def.template
> > >@@ -5467,7 +5467,7 @@ DEFINE CLANG35_AARCH64_CC_FLAGS  =
> > >DEF(GCC_AARCH64_CC_FLAGS) DEF(CLANG35_AARCH64
> > > *_CLANG35_ARM_CC_XIPFLAGS= DEF(GCC_ARM_CC_XIPFLAGS)
> > >
> > >   DEBUG_CLANG35_ARM_CC_FLAGS =
> DEF(CLANG35_ARM_CC_FLAGS)
> > >$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -O0
> > >-RELEASE_CLANG35_ARM_CC_FLAGS =
> DEF(CLANG35_ARM_CC_FLAGS)
> > >$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -Oz
> > >+RELEASE_CLANG35_ARM_CC_FLAGS =
> DEF(CLANG35_ARM_CC_FLAGS)
> > >$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -Oz -Wno-unused-but-set-
> > variable
> > >
> > > ##
> > > # CLANG35 AARCH64 definitions
> > >@@ -5489,7 +5489,7 @@ RELEASE_CLANG35_ARM_CC_FLAGS =
> > >DEF(CLANG35_ARM_CC_FLAGS) $(ARCHCC_FLAGS) $(P
> > > *_CLANG35_AARCH64_CC_XIPFLAGS=
> > DEF(GCC_AARCH64_CC_XIPFLAGS)
> > >
> > >   DEBUG_CLANG35_AARCH64_CC_FLAGS =
> > >DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
> > $(PLATFORM_FLAGS)
> > >-O0
> > >-RELEASE_CLANG35_AARCH64_CC_FLAGS =
> > >DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
> > $(PLATFORM_FLAGS) -Oz
> > >-fomit-frame-pointer
> > >+RELEASE_CLANG35_AARCH64_CC_FLAGS =
> > >DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
> > $(PLATFORM_FLAGS) -Oz
> > >-fomit-frame-pointer -Wno-unused-but-set-variable
> > >
> > >
> >
> >#
> > ##
> > >#
> > > #
> > >@@ -5543,7 +5543,7 @@ DEBUG_CLANG38_IA32_CC_FLAGS =
> > >DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -
> > > DEBUG_CLANG38_IA32_DLINK_FLAGS  =
> > >DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto -Wl,-Oz -Wl,-melf_i386 -Wl,--
> > >oformat=elf32-i386
> > > DEBUG_CLANG38_IA32_DLINK2_FLAGS =
> > DEF(GCC5_IA32_DLINK2_FLAGS)
> > >-O3
> > >
> > >-RELEASE_CLANG38_IA32_CC_FLAGS   = DEF(CLANG38_ALL_CC_FLAGS)
> -
> > >m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET)
> > >+RELEASE_CLANG38_IA32_CC_FLAGS   =
> DEF(CLANG38_ALL_CC_FLAGS) -
> > >m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET) -Wno-unused-
> but-
> > >set-variable
> > > RELEASE_CLANG38_IA32_DLINK_FLAGS=
> > >DEF(GCC5_IA32_X64_

[edk2] [PATCH] ArmPkg: Fix modsi3.S compilation across toolchains.

[Marvin Häuser]

modsi3.S references the symbol '__divsi3' by '___divsi3' which assumes
the prefix is always required and supported.  Use ASM_PFX() instead
to support all compilers.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/modsi3.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/modsi3.S 
b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/modsi3.S
index 29e2df92b02f..d5624b90f9d5 100644
--- a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/modsi3.S
+++ b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/modsi3.S
@@ -19,7 +19,7 @@ ASM_FUNC(__modsi3)
   add  r7, sp, #8
   mov  r5, r0
   mov  r4, r1
-  bl  ___divsi3
+  bl  ASM_PFX(__divsi3)
   mul  r0, r4, r0
   rsb  r0, r0, r5
   ldmfd  sp!, {r4, r5, r7, pc}
-- 
2.12.0.windows.1

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

[edk2] [PATCH v1 1/1] OvmfPkg/ResetVector: Depend on PCD values of the page tables.

[Marvin Häuser]

Currently, the values of the page tables' address and size are
hard-coded in the ResetVector. This patch replaces this with a PCD
dependency for the NASM Reset Vector. The ASM Reset Vector remains
using a hard-coded value due to the lack of C preprocessing.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 21 +---
 OvmfPkg/ResetVector/ResetVector.inf   |  5 +
 OvmfPkg/ResetVector/ResetVector.nasmb |  6 ++
 OvmfPkg/ResetVector/ResetVectorCode.asm   |  9 +
 4 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index b5a4cf8..8410553 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -46,31 +46,28 @@ SetCr3ForPageTables64:
 ;
 ; For OVMF, build some initial page tables at 0x80-0x806000.
 ;
-; This range should match with PcdOvmfSecPageTablesBase and
-; PcdOvmfSecPageTablesSize which are declared in the FDF files.
-;
 ; At the end of PEI, the pages tables will be rebuilt into a
 ; more permanent location by DxeIpl.
 ;
 
-mov ecx, 6 * 0x1000 / 4
+mov ecx, OVMF_SEC_PAGE_TABLES_SIZE / 4
 xor eax, eax
 clearPageTablesMemoryLoop:
-mov dword[ecx * 4 + 0x80 - 4], eax
+mov dword[ecx * 4 + OVMF_SEC_PAGE_TABLES_BASE - 4], eax
 loopclearPageTablesMemoryLoop
 
 ;
 ; Top level Page Directory Pointers (1 * 512GB entry)
 ;
-mov dword[0x80], 0x801000 + PAGE_PDP_ATTR
+mov dword[OVMF_SEC_PAGE_TABLES_BASE], OVMF_SEC_PAGE_TABLES_BASE + 
0x1000 + PAGE_PDP_ATTR
 
 ;
 ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
 ;
-mov dword[0x801000], 0x802000 + PAGE_PDP_ATTR
-mov dword[0x801008], 0x803000 + PAGE_PDP_ATTR
-mov dword[0x801010], 0x804000 + PAGE_PDP_ATTR
-mov dword[0x801018], 0x805000 + PAGE_PDP_ATTR
+mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1000], 
OVMF_SEC_PAGE_TABLES_BASE + 0x2000 + PAGE_PDP_ATTR
+mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1008], 
OVMF_SEC_PAGE_TABLES_BASE + 0x3000 + PAGE_PDP_ATTR
+mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1010], 
OVMF_SEC_PAGE_TABLES_BASE + 0x4000 + PAGE_PDP_ATTR
+mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1018], 
OVMF_SEC_PAGE_TABLES_BASE + 0x5000 + PAGE_PDP_ATTR
 
 ;
 ; Page Table Entries (2048 * 2MB entries => 4GB)
@@ -81,13 +78,13 @@ pageTableEntriesLoop:
 dec eax
 shl eax, 21
 add eax, PAGE_2M_PDE_ATTR
-mov [ecx * 8 + 0x802000 - 8], eax
+mov [ecx * 8 + OVMF_SEC_PAGE_TABLES_BASE + 0x2000 - 8], eax
 looppageTableEntriesLoop
 
 ;
 ; Set CR3 now that the paging structures are available
 ;
-mov eax, 0x80
+mov eax, OVMF_SEC_PAGE_TABLES_BASE
 mov cr3, eax
 
 OneTimeCallRet SetCr3ForPageTables64
diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf
index 46610d2..d1e5d4d 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -29,9 +29,14 @@
   ResetVector.nasmb
 
 [Packages]
+  OvmfPkg/OvmfPkg.dec
   MdePkg/MdePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
 
 [BuildOptions]
*_*_IA32_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
*_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
+
+[Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 31ac06a..b47f647 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -53,6 +53,12 @@
 %include "Ia32/SearchForSecEntry.asm"
 
 %ifdef ARCH_X64
+  %ifndef OVMF_SEC_PAGE_TABLES_BASE
+#include 
+%define OVMF_SEC_PAGE_TABLES_BASE FixedPcdGet32 (PcdOvmfSecPageTablesBase)
+%define OVMF_SEC_PAGE_TABLES_SIZE FixedPcdGet32 (PcdOvmfSecPageTablesSize)
+  %endif
+
 %include "Ia32/Flat32ToFlat64.asm"
 %include "Ia32/PageTables64.asm"
 %endif
diff --git a/OvmfPkg/ResetVector/ResetVectorCode.asm 
b/OvmfPkg/ResetVector/ResetVectorCode.asm
index 052c821..5b49387 100644
--- a/OvmfPkg/ResetVector/ResetVectorCode.asm
+++ b/OvmfPkg/ResetVector/ResetVectorCode.asm
@@ -40,6 +40,15 @@
 %include "Ia32/SearchForSecEntry.asm"
 
 %ifdef ARCH_X64
+  %ifndef OVMF_SEC_PAGE_TABLES_BASE
+;
+; This range should match with PcdOvmfSecPageTablesBase and
+; PcdOvmfSecPageTablesSize which are declared in the FDF files.
+   ;
+%define OVMF_SEC_PAGE_TABLES_BASE 0x80
+%define OVMF_SEC_PAGE_TABLES_SIZE 6 * 0x1000
+  %endif
+
 %include "Ia32/Flat32ToFlat64.asm"
 %include "Ia32/PageTables64.asm"
 %endif
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@list

Re: [edk2] [PATCH v1 1/1] OvmfPkg/ResetVector: Depend on PCD values of the page tables.

[Marvin Häuser]

Hey Jordan,

1) I have used git send-mail, but due to a corruption of my edk2 clone I did 
some 'funky' stuff to get it working. I expect stuff to be better with the next 
patch.
2) Will submit a V2 with line-breaks hopefully today, though might be tomorrow.
3) As said in the commit message, as far as I am aware, C preprocessing is not 
available for ASM (non-NASM), hence the values are hard-coded there still. Is 
there a way to use PCDs in ASM?
4) Can't the ASM file actually be removed? I don't see it referenced anywhere 
anymore. Is it kept for the case external packages expect it to be present? 
Should I clarify the commit message, such as using 'NASM ResetVector'?

Thanks for your input!

Regards,
Marvin.

> -Original Message-
> From: Jordan Justen [mailto:jordan.l.jus...@intel.com]
> Sent: Wednesday, November 2, 2016 11:31 PM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: ler...@redhat.com
> Subject: Re: [PATCH v1 1/1] OvmfPkg/ResetVector: Depend on PCD values of
> the page tables.
> 
> The "v1 1/1" isn't needed in the subject. For the first version of a single 
> patch
> series, I would expect to just see [PATCH]. (Obviously this is not too
> important.)
> 
> Email headers seem to indicate that you aren't using git send-email.
> This will cause troubles if someday you have a multi-patch series.
> 
> On 2016-11-02 11:00:34, Marvin Häuser wrote:
> >
> > diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> > b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> >
> >  ;
> >  ; Top level Page Directory Pointers (1 * 512GB entry)
> >  ;
> > -mov dword[0x80], 0x801000 + PAGE_PDP_ATTR
> > +mov dword[OVMF_SEC_PAGE_TABLES_BASE],
> OVMF_SEC_PAGE_TABLES_BASE + 0x1000 + PAGE_PDP_ATTR
> >
> >  ;
> >  ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
> >  ;
> > -mov dword[0x801000], 0x802000 + PAGE_PDP_ATTR
> > -mov dword[0x801008], 0x803000 + PAGE_PDP_ATTR
> > -mov dword[0x801010], 0x804000 + PAGE_PDP_ATTR
> > -mov dword[0x801018], 0x805000 + PAGE_PDP_ATTR
> > +mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1000],
> OVMF_SEC_PAGE_TABLES_BASE + 0x2000 + PAGE_PDP_ATTR
> > +mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1008],
> OVMF_SEC_PAGE_TABLES_BASE + 0x3000 + PAGE_PDP_ATTR
> > +mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1010],
> OVMF_SEC_PAGE_TABLES_BASE + 0x4000 + PAGE_PDP_ATTR
> > +mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1018],
> OVMF_SEC_PAGE_TABLES_BASE + 0x5000 + PAGE_PDP_ATTR
> 
> These line are too long. I guess you can use '\' at the end of a line to 
> continue
> it, or maybe add a PT_ADDR() macro that adds in
> OVMF_SEC_PAGE_TABLES_BASE.
> 
> > diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb
> > b/OvmfPkg/ResetVector/ResetVector.nasmb
> > index 31ac06a..b47f647 100644
> > --- a/OvmfPkg/ResetVector/ResetVector.nasmb
> > +++ b/OvmfPkg/ResetVector/ResetVector.nasmb
> > @@ -53,6 +53,12 @@
> >  %include "Ia32/SearchForSecEntry.asm"
> >
> >  %ifdef ARCH_X64
> > +  %ifndef OVMF_SEC_PAGE_TABLES_BASE
> > +#include 
> > +%define OVMF_SEC_PAGE_TABLES_BASE FixedPcdGet32
> (PcdOvmfSecPageTablesBase)
> > +%define OVMF_SEC_PAGE_TABLES_SIZE FixedPcdGet32
> > + (PcdOvmfSecPageTablesSize)  %endif
> > +
> >  %include "Ia32/Flat32ToFlat64.asm"
> >  %include "Ia32/PageTables64.asm"
> >  %endif
> > diff --git a/OvmfPkg/ResetVector/ResetVectorCode.asm
> > b/OvmfPkg/ResetVector/ResetVectorCode.asm
> > index 052c821..5b49387 100644
> > --- a/OvmfPkg/ResetVector/ResetVectorCode.asm
> > +++ b/OvmfPkg/ResetVector/ResetVectorCode.asm
> > @@ -40,6 +40,15 @@
> >  %include "Ia32/SearchForSecEntry.asm"
> >
> >  %ifdef ARCH_X64
> > +  %ifndef OVMF_SEC_PAGE_TABLES_BASE
> > +;
> > +; This range should match with PcdOvmfSecPageTablesBase and
> > +; PcdOvmfSecPageTablesSize which are declared in the FDF files.
> > +   ;
> > +%define OVMF_SEC_PAGE_TABLES_BASE 0x80
> > +%define OVMF_SEC_PAGE_TABLES_SIZE 6 * 0x1000
> 
> I thought we were using the PCDs?
> 
> -Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] OvmfPkg/ResetVector: Depend on PCD values of the page tables.

[Marvin Häuser]

Currently, the values of the page tables' address and size are
hard-coded in the ResetVector. This patch replaces this with a PCD
dependency for the NASM Reset Vector. The ASM Reset Vector remains
using a hard-coded value due to the lack of C preprocessing.

Checks for the size have been added to alert the developer to rewrite
the ASM according to the new size, if it has been changed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 23 ++--
 OvmfPkg/ResetVector/ResetVector.inf   |  5 +
 OvmfPkg/ResetVector/ResetVector.nasmb |  7 ++
 OvmfPkg/ResetVector/ResetVectorCode.asm   | 16 ++
 4 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index b5a4cf8d7187..7ff394b1afc3 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -37,6 +37,8 @@ BITS32
PAGE_READ_WRITE + \
PAGE_PRESENT)
 
+%define PT_ADDR(Offset) (OVMF_SEC_PAGE_TABLES_BASE + (Offset))
+
 
 ;
 ; Modified:  EAX, ECX
@@ -46,31 +48,28 @@ SetCr3ForPageTables64:
 ;
 ; For OVMF, build some initial page tables at 0x80-0x806000.
 ;
-; This range should match with PcdOvmfSecPageTablesBase and
-; PcdOvmfSecPageTablesSize which are declared in the FDF files.
-;
 ; At the end of PEI, the pages tables will be rebuilt into a
 ; more permanent location by DxeIpl.
 ;
 
-mov ecx, 6 * 0x1000 / 4
+mov ecx, OVMF_SEC_PAGE_TABLES_SIZE / 4
 xor eax, eax
 clearPageTablesMemoryLoop:
-mov dword[ecx * 4 + 0x80 - 4], eax
+mov dword[ecx * 4 + PT_ADDR (0) - 4], eax
 loopclearPageTablesMemoryLoop
 
 ;
 ; Top level Page Directory Pointers (1 * 512GB entry)
 ;
-mov dword[0x80], 0x801000 + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDP_ATTR
 
 ;
 ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
 ;
-mov dword[0x801000], 0x802000 + PAGE_PDP_ATTR
-mov dword[0x801008], 0x803000 + PAGE_PDP_ATTR
-mov dword[0x801010], 0x804000 + PAGE_PDP_ATTR
-mov dword[0x801018], 0x805000 + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) + PAGE_PDP_ATTR
 
 ;
 ; Page Table Entries (2048 * 2MB entries => 4GB)
@@ -81,13 +80,13 @@ pageTableEntriesLoop:
 dec eax
 shl eax, 21
 add eax, PAGE_2M_PDE_ATTR
-mov [ecx * 8 + 0x802000 - 8], eax
+mov [ecx * 8 + PT_ADDR (0x2000) - 8], eax
 looppageTableEntriesLoop
 
 ;
 ; Set CR3 now that the paging structures are available
 ;
-mov eax, 0x80
+mov eax, OVMF_SEC_PAGE_TABLES_BASE
 mov cr3, eax
 
 OneTimeCallRet SetCr3ForPageTables64
diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf
index 46610d243ecf..d1e5d4d9bdea 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -29,9 +29,14 @@ [Sources]
   ResetVector.nasmb
 
 [Packages]
+  OvmfPkg/OvmfPkg.dec
   MdePkg/MdePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
 
 [BuildOptions]
*_*_IA32_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
*_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
+
+[Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 31ac06ae4a8c..62597ea95cf5 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -53,6 +53,13 @@
 %include "Ia32/SearchForSecEntry.asm"
 
 %ifdef ARCH_X64
+  #include 
+  %define OVMF_SEC_PAGE_TABLES_BASE FixedPcdGet32 (PcdOvmfSecPageTablesBase)
+  %define OVMF_SEC_PAGE_TABLES_SIZE FixedPcdGet32 (PcdOvmfSecPageTablesSize)
+
+  %if (FixedPcdGet32 (PcdOvmfSecPageTablesSize) != 0x006000)
+%error "This implementation inherently depends on PcdOvmfSecPageTablesSize"
+  %endif
 %include "Ia32/Flat32ToFlat64.asm"
 %include "Ia32/PageTables64.asm"
 %endif
diff --git a/OvmfPkg/ResetVector/ResetVectorCode.asm 
b/OvmfPkg/ResetVector/ResetVectorCode.asm
index 052c821f212c..1a1d92fb1415 100644
--- a/OvmfPkg/ResetVector/ResetVectorCode.asm
+++ b/OvmfPkg/ResetVector/ResetVectorCode.asm
@@ -40,6 +40,22 @@
 %include "Ia32/SearchForSecEntry.asm"
 
 %ifdef ARCH_X64
+  ;
+  ; These values should match with PcdOvmfSecPageTablesBase and
+  ; PcdOvmfSecPageTablesSize which are declared in the FDF files.
+  ;
+
+  %ifndef OVMF_SEC_PAGE_TABLES_BASE
+%define O

Re: [edk2] [PATCH v1 1/1] OvmfPkg/ResetVector: Depend on PCD values of the page tables.

[Marvin Häuser]

Hey Laszlo,
Hey Jordan,

I sent a V2 of the patch. Changes:
* fixed the title to get rid of the numbering
* Introduced PT_ADDR() as proposed by Jordan
* introduced the size check proposed by Laszlo
* removed the 'ifndef' for the NASM ResetVector as only the PCD value should be 
allowed
* separated the 'ifndef' checks for the ASM ResetVector, so developers can 
change the base without needed to set a size

Thanks for your input!

Regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, November 3, 2016 12:40 AM
> To: Jordan Justen ; Marvin Häuser
> 
> Cc: edk2-devel@lists.01.org 
> Subject: Re: [edk2] [PATCH v1 1/1] OvmfPkg/ResetVector: Depend on PCD
> values of the page tables.
> 
> On 11/03/16 00:26, Laszlo Ersek wrote:
> > On 11/02/16 23:31, Jordan Justen wrote:
> >> The "v1 1/1" isn't needed in the subject. For the first version of a
> >> single patch series, I would expect to just see [PATCH]. (Obviously
> >> this is not too important.)
> >
> > (I think the "v1" implies that Marvin expects to send a v2.)
> >
> >> Email headers seem to indicate that you aren't using git send-email.
> >> This will cause troubles if someday you have a multi-patch series.
> >>
> >> On 2016-11-02 11:00:34, Marvin Häuser wrote:
> >>>
> >>> diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> >>> b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> >>>
> >>>  ;
> >>>  ; Top level Page Directory Pointers (1 * 512GB entry)
> >>>  ;
> >>> -mov dword[0x80], 0x801000 + PAGE_PDP_ATTR
> >>> +mov dword[OVMF_SEC_PAGE_TABLES_BASE],
> OVMF_SEC_PAGE_TABLES_BASE + 0x1000 + PAGE_PDP_ATTR
> >>>
> >>>  ;
> >>>  ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
> >>>  ;
> >>> -mov dword[0x801000], 0x802000 + PAGE_PDP_ATTR
> >>> -mov dword[0x801008], 0x803000 + PAGE_PDP_ATTR
> >>> -mov dword[0x801010], 0x804000 + PAGE_PDP_ATTR
> >>> -mov dword[0x801018], 0x805000 + PAGE_PDP_ATTR
> >>> +mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1000],
> OVMF_SEC_PAGE_TABLES_BASE + 0x2000 + PAGE_PDP_ATTR
> >>> +mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1008],
> OVMF_SEC_PAGE_TABLES_BASE + 0x3000 + PAGE_PDP_ATTR
> >>> +mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1010],
> OVMF_SEC_PAGE_TABLES_BASE + 0x4000 + PAGE_PDP_ATTR
> >>> +mov dword[OVMF_SEC_PAGE_TABLES_BASE + 0x1018],
> OVMF_SEC_PAGE_TABLES_BASE + 0x5000 + PAGE_PDP_ATTR
> >>
> >> These line are too long. I guess you can use '\' at the end of a line
> >> to continue it, or maybe add a PT_ADDR() macro that adds in
> >> OVMF_SEC_PAGE_TABLES_BASE.
> >>
> >>> diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb
> >>> b/OvmfPkg/ResetVector/ResetVector.nasmb
> >>> index 31ac06a..b47f647 100644
> >>> --- a/OvmfPkg/ResetVector/ResetVector.nasmb
> >>> +++ b/OvmfPkg/ResetVector/ResetVector.nasmb
> >>> @@ -53,6 +53,12 @@
> >>>  %include "Ia32/SearchForSecEntry.asm"
> >>>
> >>>  %ifdef ARCH_X64
> >>> +  %ifndef OVMF_SEC_PAGE_TABLES_BASE
> >>> +#include 
> >>> +%define OVMF_SEC_PAGE_TABLES_BASE FixedPcdGet32
> (PcdOvmfSecPageTablesBase)
> >>> +%define OVMF_SEC_PAGE_TABLES_SIZE FixedPcdGet32
> >>> + (PcdOvmfSecPageTablesSize)  %endif
> >>> +
> >>>  %include "Ia32/Flat32ToFlat64.asm"
> >>>  %include "Ia32/PageTables64.asm"
> >>>  %endif
> >>> diff --git a/OvmfPkg/ResetVector/ResetVectorCode.asm
> >>> b/OvmfPkg/ResetVector/ResetVectorCode.asm
> >>> index 052c821..5b49387 100644
> >>> --- a/OvmfPkg/ResetVector/ResetVectorCode.asm
> >>> +++ b/OvmfPkg/ResetVector/ResetVectorCode.asm
> >>> @@ -40,6 +40,15 @@
> >>>  %include "Ia32/SearchForSecEntry.asm"
> >>>
> >>>  %ifdef ARCH_X64
> >>> +  %ifndef OVMF_SEC_PAGE_TABLES_BASE
> >>> +;
> >>> +; This range should match with PcdOvmfSecPageTablesBase and
> >>> +; PcdOvmfSecPageTablesSize which are declared in the FDF files.
> >>> +   ;
> >>> +%define OVMF_SEC_PAGE_TABLES_BASE 0x80
> >>> +%define OVMF_SEC_PAGE_TABLES_SIZE 6 * 0x1000
> >>
> >&g

[edk2] [PATCH] OvmfPkg/ResetVector: Remove the unused ASM ResetVector.

[Marvin Häuser]

Remove the ResetVector.asm file as it is no longer referenced since
the switch to ResetVector.nasmb.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 OvmfPkg/ResetVector/ResetVectorCode.asm | 53 
 1 file changed, 53 deletions(-)

diff --git a/OvmfPkg/ResetVector/ResetVectorCode.asm 
b/OvmfPkg/ResetVector/ResetVectorCode.asm
deleted file mode 100644
index 052c821f212c..
--- a/OvmfPkg/ResetVector/ResetVectorCode.asm
+++ /dev/null
@@ -1,53 +0,0 @@
-;--
-; @file
-; This file includes all other code files to assemble the reset vector code
-;
-; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.
-; This program and the accompanying materials
-; are licensed and made available under the terms and conditions of the BSD 
License
-; which accompanies this distribution.  The full text of the license may be 
found at
-; http://opensource.org/licenses/bsd-license.php
-;
-; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-;
-;--
-
-%ifdef ARCH_IA32
-  %ifdef ARCH_X64
-%error "Only one of ARCH_IA32 or ARCH_X64 can be defined."
-  %endif
-%elifdef ARCH_X64
-%else
-  %error "Either ARCH_IA32 or ARCH_X64 must be defined."
-%endif
-
-%include "CommonMacros.inc"
-
-%include "PostCodes.inc"
-
-%ifdef DEBUG_NONE
-  %include "DebugDisabled.asm"
-%elifdef DEBUG_PORT80
-  %include "Port80Debug.asm"
-%elifdef DEBUG_SERIAL
-  %include "SerialDebug.asm"
-%else
-  %error "No debug type was specified."
-%endif
-
-%include "Ia32/SearchForBfvBase.asm"
-%include "Ia32/SearchForSecEntry.asm"
-
-%ifdef ARCH_X64
-%include "Ia32/Flat32ToFlat64.asm"
-%include "Ia32/PageTables64.asm"
-%endif
-
-%include "Ia16/Real16ToFlat32.asm"
-%include "Ia16/Init16.asm"
-
-%include "Main.asm"
-
-%include "Ia16/ResetVectorVtf0.asm"
-
-- 
2.10.1.windows.1

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

[edk2] [PATCH v3] OvmfPkg/ResetVector: Depend on PCD values of the page tables.

[Marvin Häuser]

Currently, the value of the page tables' address is hard-coded in the
ResetVector. This patch replaces these values with a PCD dependency.

A check for the size has been added to alert the developer to rewrite
the ASM according to the new size, if it has been changed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 23 ++--
 OvmfPkg/ResetVector/ResetVector.inf   |  5 +
 OvmfPkg/ResetVector/ResetVector.nasmb |  6 +
 3 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index b5a4cf8d7187..0b95a7fa9a86 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -44,10 +44,11 @@ BITS32
 SetCr3ForPageTables64:
 
 ;
-; For OVMF, build some initial page tables at 0x80-0x806000.
+; For OVMF, build some initial page tables at
+; PcdOvmfSecPageTablesBase - (PcdOvmfSecPageTablesBase + 0x6000).
 ;
-; This range should match with PcdOvmfSecPageTablesBase and
-; PcdOvmfSecPageTablesSize which are declared in the FDF files.
+; This range should match with PcdOvmfSecPageTablesSize which is
+; declared in the FDF files.
 ;
 ; At the end of PEI, the pages tables will be rebuilt into a
 ; more permanent location by DxeIpl.
@@ -56,21 +57,21 @@ SetCr3ForPageTables64:
 mov ecx, 6 * 0x1000 / 4
 xor eax, eax
 clearPageTablesMemoryLoop:
-mov dword[ecx * 4 + 0x80 - 4], eax
+mov dword[ecx * 4 + PT_ADDR (0 - 4)], eax
 loopclearPageTablesMemoryLoop
 
 ;
 ; Top level Page Directory Pointers (1 * 512GB entry)
 ;
-mov dword[0x80], 0x801000 + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDP_ATTR
 
 ;
 ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
 ;
-mov dword[0x801000], 0x802000 + PAGE_PDP_ATTR
-mov dword[0x801008], 0x803000 + PAGE_PDP_ATTR
-mov dword[0x801010], 0x804000 + PAGE_PDP_ATTR
-mov dword[0x801018], 0x805000 + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) + PAGE_PDP_ATTR
 
 ;
 ; Page Table Entries (2048 * 2MB entries => 4GB)
@@ -81,13 +82,13 @@ pageTableEntriesLoop:
 dec eax
 shl eax, 21
 add eax, PAGE_2M_PDE_ATTR
-mov [ecx * 8 + 0x802000 - 8], eax
+mov [ecx * 8 + PT_ADDR (0x2000 - 8)], eax
 looppageTableEntriesLoop
 
 ;
 ; Set CR3 now that the paging structures are available
 ;
-mov eax, 0x80
+mov eax, PT_ADDR (0)
 mov cr3, eax
 
 OneTimeCallRet SetCr3ForPageTables64
diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf
index 46610d243ecf..d1e5d4d9bdea 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -29,9 +29,14 @@ [Sources]
   ResetVector.nasmb
 
 [Packages]
+  OvmfPkg/OvmfPkg.dec
   MdePkg/MdePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
 
 [BuildOptions]
*_*_IA32_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
*_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
+
+[Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 31ac06ae4a8c..4bf8c97d8158 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -53,6 +53,12 @@
 %include "Ia32/SearchForSecEntry.asm"
 
 %ifdef ARCH_X64
+  %if (FixedPcdGet32 (PcdOvmfSecPageTablesSize) != 0x6000)
+%error "This implementation inherently depends on PcdOvmfSecPageTablesSize"
+  %endif
+
+  #include 
+  %define PT_ADDR(Offset) FixedPcdGet32 (PcdOvmfSecPageTablesBase)
 %include "Ia32/Flat32ToFlat64.asm"
 %include "Ia32/PageTables64.asm"
 %endif
-- 
2.10.1.windows.1

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

Re: [edk2] [PATCH v2] OvmfPkg/ResetVector: Depend on PCD values of the page tables.

[Marvin Häuser]

Hey Jordan,
Hey Laszlo,

I just pushed a v3. Changes:
* Pushed a patch to remove ResetVector.asm. As this is not really connected to 
the change after, I made it a separate patch rather than a series.

* Don't abstract or use the PCD size as, as Laszlo pointed out, it makes little 
sense, because the rest of the ASM needs to be adapter to the size change 
anyway, if one changes it. Do you see a way to make this dynamic too? Maybe 
calculate the offsets by division?
* Make clear in the comment that the PCD value is used for the address.
* Move PT_ADDR() to the ResetVector file so there is no need to abstract the 
Address PCD for the PageTables file.
* Include addition/subtractions after PT_ADDR() into the brackets, as suggested 
by Jordan.

Regards,
Marvin.

> -Original Message-
> From: Jordan Justen [mailto:jordan.l.jus...@intel.com]
> Sent: Thursday, November 3, 2016 9:59 PM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: ler...@redhat.com
> Subject: Re: [PATCH v2] OvmfPkg/ResetVector: Depend on PCD values of the
> page tables.
> 
> On 2016-11-03 12:18:56, Marvin Häuser wrote:
> > Currently, the values of the page tables' address and size are
> > hard-coded in the ResetVector. This patch replaces this with a PCD
> > dependency for the NASM Reset Vector. The ASM Reset Vector remains
> > using a hard-coded value due to the lack of C preprocessing.
> >
> > Checks for the size have been added to alert the developer to rewrite
> > the ASM according to the new size, if it has been changed.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 23 ++--
> >  OvmfPkg/ResetVector/ResetVector.inf   |  5 +
> >  OvmfPkg/ResetVector/ResetVector.nasmb |  7 ++
> >  OvmfPkg/ResetVector/ResetVectorCode.asm   | 16 ++
> >  4 files changed, 39 insertions(+), 12 deletions(-)
> >
> > diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> > b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> > index b5a4cf8d7187..7ff394b1afc3 100644
> > --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> > +++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> > @@ -37,6 +37,8 @@ BITS32
> > PAGE_READ_WRITE + \
> > PAGE_PRESENT)
> >
> > +%define PT_ADDR(Offset) (OVMF_SEC_PAGE_TABLES_BASE + (Offset))
> > +
> >
> >  ;
> >  ; Modified:  EAX, ECX
> > @@ -46,31 +48,28 @@ SetCr3ForPageTables64:
> >  ;
> >  ; For OVMF, build some initial page tables at 0x80-0x806000.
> >  ;
> > -; This range should match with PcdOvmfSecPageTablesBase and
> > -; PcdOvmfSecPageTablesSize which are declared in the FDF files.
> > -;
> >  ; At the end of PEI, the pages tables will be rebuilt into a
> >  ; more permanent location by DxeIpl.
> >  ;
> >
> > -mov ecx, 6 * 0x1000 / 4
> > +mov ecx, OVMF_SEC_PAGE_TABLES_SIZE / 4
> >  xor eax, eax
> >  clearPageTablesMemoryLoop:
> > -mov dword[ecx * 4 + 0x80 - 4], eax
> > +mov dword[ecx * 4 + PT_ADDR (0) - 4], eax
> >  loopclearPageTablesMemoryLoop
> >
> >  ;
> >  ; Top level Page Directory Pointers (1 * 512GB entry)
> >  ;
> > -mov dword[0x80], 0x801000 + PAGE_PDP_ATTR
> > +mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDP_ATTR
> >
> >  ;
> >  ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
> >  ;
> > -mov dword[0x801000], 0x802000 + PAGE_PDP_ATTR
> > -mov dword[0x801008], 0x803000 + PAGE_PDP_ATTR
> > -mov dword[0x801010], 0x804000 + PAGE_PDP_ATTR
> > -mov dword[0x801018], 0x805000 + PAGE_PDP_ATTR
> > +mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) +
> PAGE_PDP_ATTR
> > +mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) +
> PAGE_PDP_ATTR
> > +mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) +
> PAGE_PDP_ATTR
> > +mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) +
> PAGE_PDP_ATTR
> >
> >  ;
> >  ; Page Table Entries (2048 * 2MB entries => 4GB) @@ -81,13 +80,13
> > @@ pageTableEntriesLoop:
> >  dec eax
> >  shl eax, 21
> >  add eax, PAGE_2M_PDE_ATTR
> > -mov [ecx * 8 + 0x802000 - 8], eax
> > +mov [ecx * 8 + PT_ADDR (0x2000) - 8], eax
> 
> I think the '- 8' should be in the PT_ADDR.
> 
> This patch is basically
> 
> Reviewed-by: Jorda

[edk2] [PATCH v2 1/2] MdeModulePkg: Do not free memory during ExitBootServices ().

[Marvin Häuser]

During exiting Boot Services, there should be no changes made to the
Memory Map. This patch eliminates explicit and implicit calls to the
Memory Allocation Services and, where applicable, zeros the memory
instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c | 11 +--
 MdeModulePkg/Universal/Network/SnpDxe/Snp.c | 12 
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c 
b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
index ae202c3fe24a..b5e36b8bec06 100644
--- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
+++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
@@ -872,9 +872,16 @@ IScsiOnExitBootService (
   ISCSI_DRIVER_DATA *Private;
 
   Private = (ISCSI_DRIVER_DATA *) Context;
-  gBS->CloseEvent (Private->ExitBootServiceEvent);
 
-  IScsiSessionAbort (&Private->Session);
+  if (Private->Session.Signature != 0) {
+IScsiSessionAbort (&Private->Session);
+
+//
+// Empty Session as it will not be freed.
+// This will also prevent this code from being re-run.
+//
+ZeroMem (&Private->Session, sizeof (Private->Session));
+  }
 }
 
 /**
diff --git a/MdeModulePkg/Universal/Network/SnpDxe/Snp.c 
b/MdeModulePkg/Universal/Network/SnpDxe/Snp.c
index 9f61aee05773..e15e79c7065f 100644
--- a/MdeModulePkg/Universal/Network/SnpDxe/Snp.c
+++ b/MdeModulePkg/Universal/Network/SnpDxe/Snp.c
@@ -32,6 +32,18 @@ SnpNotifyExitBootServices (
 
   Snp  = (SNP_DRIVER *)Context;
 
+  if (Snp->TxRxBuffer != NULL) {
+//
+// Empty TxRxBuffer as it will not be freed.
+//
+ZeroMem (Snp->TxRxBuffer, Snp->TxRxBufferSize);
+
+//
+// Set TxRxBuffer to NULL so FreeBuffer () will not be called.
+//
+Snp->TxRxBuffer = NULL;
+  }
+
   //
   // Shutdown and stop UNDI driver
   //
-- 
2.10.1.windows.1

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

[edk2] [PATCH v2 2/2] NetworkPkg: Do not free memory during ExitBootServices ().

[Marvin Häuser]

During exiting Boot Services, there should be no changes made to the
Memory Map. This patch eliminates explicit and implicit calls to the
Memory Allocation Services and, where applicable, zeros the memory
instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 NetworkPkg/IScsiDxe/IScsiMisc.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.c b/NetworkPkg/IScsiDxe/IScsiMisc.c
index deebf5d9a387..0825e2a5e944 100644
--- a/NetworkPkg/IScsiDxe/IScsiMisc.c
+++ b/NetworkPkg/IScsiDxe/IScsiMisc.c
@@ -1486,10 +1486,19 @@ IScsiOnExitBootService (
   ISCSI_DRIVER_DATA *Private;
 
   Private = (ISCSI_DRIVER_DATA *) Context;
-  gBS->CloseEvent (Private->ExitBootServiceEvent);
 
   if (Private->Session != NULL) {
 IScsiSessionAbort (Private->Session);
+
+//
+// Empty Session as it will not be freed.
+//
+ZeroMem (Private->Session, sizeof (*Private->Session));
+
+//
+// Set Session to NULL so this code is not re-run.
+//
+Private->Session = NULL;
   }
 }
 
-- 
2.10.1.windows.1

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

Re: [edk2] [PATCH v2] OvmfPkg/ResetVector: Depend on PCD values of the page tables.

[Marvin Häuser]

Hey Laszlo,

I'm quoting Jordan's mail because, for some reason, I didn't receive yours.
Sure, I'm fine with you re-posting the patches, though I thought I considered 
everything you had said in v3 (not abstracting the size and adding the error 
message).
Sorry if I didn't consider something, in that case I must have overread it.

Thanks for 'fixing' the patches!

Regards,
Marvin.

> -Original Message-
> From: Jordan Justen [mailto:jordan.l.jus...@intel.com]
> Sent: Friday, November 4, 2016 12:10 AM
> To: Laszlo Ersek ; Marvin Häuser
> 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v2] OvmfPkg/ResetVector: Depend on PCD
> values of the page tables.
> 
> On 2016-11-03 15:55:10, Laszlo Ersek wrote:
> > Hi Marvin,
> >
> > On 11/03/16 20:18, Marvin Häuser wrote:
> > > Currently, the values of the page tables' address and size are
> > > hard-coded in the ResetVector. This patch replaces this with a PCD
> > > dependency for the NASM Reset Vector. The ASM Reset Vector remains
> > > using a hard-coded value due to the lack of C preprocessing.
> > >
> > > Checks for the size have been added to alert the developer to
> > > rewrite the ASM according to the new size, if it has been changed.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Marvin Haeuser 
> > > ---
> > >  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 23 ++-
> -
> > >  OvmfPkg/ResetVector/ResetVector.inf   |  5 +
> > >  OvmfPkg/ResetVector/ResetVector.nasmb |  7 ++
> > >  OvmfPkg/ResetVector/ResetVectorCode.asm   | 16 ++
> > >  4 files changed, 39 insertions(+), 12 deletions(-)
> >
> > I'll soon send a modified / simplified version of your patch (keeping
> > your authorship and S-o-b in the first place of course). I find that
> > simpler than struggling with an explanation :) I hope you're fine with this.
> >
> 
> Marvin's v3 seemed okay, but of course, it should be a series, together with
> his separate patch that removes the unused ResetVectorCode.asm file.
> 
> If your tweaks are minor, you can add my
> 
> Reviewed-by: Jordan Justen 
> 
> to both of his patches.
> 
> Thanks,
> 
> -Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4] OvmfPkg/ResetVector: Depend on PCD values of the page tables.

[Marvin Häuser]

Currently, the value of the page tables' address is hard-coded in the
ResetVector. This patch replaces these values with a PCD dependency.

A check for the size has been added to alert the developer to rewrite
the ASM according to the new size, if it has been changed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 23 ++--
 OvmfPkg/ResetVector/ResetVector.inf   |  5 +
 OvmfPkg/ResetVector/ResetVector.nasmb |  7 ++
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index b5a4cf8d7187..6201cad1f5dc 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -44,10 +44,11 @@ BITS32
 SetCr3ForPageTables64:
 
 ;
-; For OVMF, build some initial page tables at 0x80-0x806000.
+; For OVMF, build some initial page tables at
+; PcdOvmfSecPageTablesBase - (PcdOvmfSecPageTablesBase + 0x6000).
 ;
-; This range should match with PcdOvmfSecPageTablesBase and
-; PcdOvmfSecPageTablesSize which are declared in the FDF files.
+; This range should match with PcdOvmfSecPageTablesSize which is
+; declared in the FDF files.
 ;
 ; At the end of PEI, the pages tables will be rebuilt into a
 ; more permanent location by DxeIpl.
@@ -56,21 +57,21 @@ SetCr3ForPageTables64:
 mov ecx, 6 * 0x1000 / 4
 xor eax, eax
 clearPageTablesMemoryLoop:
-mov dword[ecx * 4 + 0x80 - 4], eax
+mov dword[ecx * 4 + PT_ADDR (0) - 4], eax
 loopclearPageTablesMemoryLoop
 
 ;
 ; Top level Page Directory Pointers (1 * 512GB entry)
 ;
-mov dword[0x80], 0x801000 + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDP_ATTR
 
 ;
 ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
 ;
-mov dword[0x801000], 0x802000 + PAGE_PDP_ATTR
-mov dword[0x801008], 0x803000 + PAGE_PDP_ATTR
-mov dword[0x801010], 0x804000 + PAGE_PDP_ATTR
-mov dword[0x801018], 0x805000 + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) + PAGE_PDP_ATTR
 
 ;
 ; Page Table Entries (2048 * 2MB entries => 4GB)
@@ -81,13 +82,13 @@ pageTableEntriesLoop:
 dec eax
 shl eax, 21
 add eax, PAGE_2M_PDE_ATTR
-mov [ecx * 8 + 0x802000 - 8], eax
+mov [ecx * 8 + PT_ADDR (0x2000 - 8)], eax
 looppageTableEntriesLoop
 
 ;
 ; Set CR3 now that the paging structures are available
 ;
-mov eax, 0x80
+mov eax, PT_ADDR (0)
 mov cr3, eax
 
 OneTimeCallRet SetCr3ForPageTables64
diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf
index 46610d243ecf..d1e5d4d9bdea 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -29,9 +29,14 @@ [Sources]
   ResetVector.nasmb
 
 [Packages]
+  OvmfPkg/OvmfPkg.dec
   MdePkg/MdePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
 
 [BuildOptions]
*_*_IA32_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
*_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
+
+[Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 31ac06ae4a8c..29cbad367711 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -53,6 +53,13 @@
 %include "Ia32/SearchForSecEntry.asm"
 
 %ifdef ARCH_X64
+  #include 
+
+  %if (FixedPcdGet32 (PcdOvmfSecPageTablesSize) != 0x6000)
+%error "This implementation inherently depends on PcdOvmfSecPageTablesSize"
+  %endif
+
+  %define PT_ADDR(Offset) (FixedPcdGet32 (PcdOvmfSecPageTablesBase) + (Offset))
 %include "Ia32/Flat32ToFlat64.asm"
 %include "Ia32/PageTables64.asm"
 %endif
-- 
2.10.1.windows.1

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

Re: [edk2] [PATCH v3] OvmfPkg/ResetVector: Depend on PCD values of the page tables.

[Marvin Häuser]

Hey Laszlo,

I'm terribly sorry for the mistakes in v3, I made it in a hurry because it was 
late - should have postponded for today.
Because I didn't see 'your v3' (or didn't you post it yet?), I posted a v4 as 
you said, which should have fixed the three comments you had.

Thank you very much for your input!

Regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, November 4, 2016 12:56 AM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org 
> Cc: jordan.l.jus...@intel.com
> Subject: Re: [PATCH v3] OvmfPkg/ResetVector: Depend on PCD values of the
> page tables.
> 
> Three comments:
> 
> On 11/03/16 22:41, Marvin Häuser wrote:
> > Currently, the value of the page tables' address is hard-coded in the
> > ResetVector. This patch replaces these values with a PCD dependency.
> >
> > A check for the size has been added to alert the developer to rewrite
> > the ASM according to the new size, if it has been changed.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 23 ++--
> >  OvmfPkg/ResetVector/ResetVector.inf   |  5 +
> >  OvmfPkg/ResetVector/ResetVector.nasmb |  6 +
> >  3 files changed, 23 insertions(+), 11 deletions(-)
> >
> > diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> > b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> > index b5a4cf8d7187..0b95a7fa9a86 100644
> > --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> > +++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> > @@ -44,10 +44,11 @@ BITS32
> >  SetCr3ForPageTables64:
> >
> >  ;
> > -; For OVMF, build some initial page tables at 0x80-0x806000.
> > +; For OVMF, build some initial page tables at
> > +; PcdOvmfSecPageTablesBase - (PcdOvmfSecPageTablesBase + 0x6000).
> >  ;
> > -; This range should match with PcdOvmfSecPageTablesBase and
> > -; PcdOvmfSecPageTablesSize which are declared in the FDF files.
> > +; This range should match with PcdOvmfSecPageTablesSize which is
> > +; declared in the FDF files.
> >  ;
> >  ; At the end of PEI, the pages tables will be rebuilt into a
> >  ; more permanent location by DxeIpl.
> > @@ -56,21 +57,21 @@ SetCr3ForPageTables64:
> >  mov ecx, 6 * 0x1000 / 4
> >  xor eax, eax
> >  clearPageTablesMemoryLoop:
> > -mov dword[ecx * 4 + 0x80 - 4], eax
> > +mov dword[ecx * 4 + PT_ADDR (0 - 4)], eax
> 
> I think this is incorrect (or dubious at least); the NASM-level replacement 
> text
> for this will be
> 
>   (0x80 + (0 - 4))
> 
> and I strongly dislike the (0 - 4) subexpression. The type in which NASM
> evaluates (0 - 4) is not specified, and I'd rather not risk it being UINT64, 
> for
> example.
> 
> >  loopclearPageTablesMemoryLoop
> >
> >  ;
> >  ; Top level Page Directory Pointers (1 * 512GB entry)
> >  ;
> > -mov dword[0x80], 0x801000 + PAGE_PDP_ATTR
> > +mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDP_ATTR
> >
> >  ;
> >  ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
> >  ;
> > -mov dword[0x801000], 0x802000 + PAGE_PDP_ATTR
> > -mov dword[0x801008], 0x803000 + PAGE_PDP_ATTR
> > -mov dword[0x801010], 0x804000 + PAGE_PDP_ATTR
> > -mov dword[0x801018], 0x805000 + PAGE_PDP_ATTR
> > +mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) +
> PAGE_PDP_ATTR
> > +mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) +
> PAGE_PDP_ATTR
> > +mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) +
> PAGE_PDP_ATTR
> > +mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) +
> PAGE_PDP_ATTR
> >
> >  ;
> >  ; Page Table Entries (2048 * 2MB entries => 4GB) @@ -81,13 +82,13
> > @@ pageTableEntriesLoop:
> >  dec eax
> >  shl eax, 21
> >  add eax, PAGE_2M_PDE_ATTR
> > -mov [ecx * 8 + 0x802000 - 8], eax
> > +mov [ecx * 8 + PT_ADDR (0x2000 - 8)], eax
> >  looppageTableEntriesLoop
> >
> >  ;
> >  ; Set CR3 now that the paging structures are available
> >  ;
> > -mov eax, 0x80
> > +mov eax, PT_ADDR (0)
> >  mov cr3, eax
> >
> >  OneTimeCallRet SetCr3ForPageTables64 diff --git
> > a/OvmfPkg/ResetVector/ResetVector.

Re: [edk2] [PATCH v2 1/2] MdeModulePkg: Do not free memory during ExitBootServices ().

[Marvin Häuser]

I forgot to note that this patch is  not everything needed to not call the 
Memory Allocation Services.
The event also calls a function which calls Tcp4IoDestroySocket() and 
NetbufQueFlush().
This should not be needed, should it? The first one calls the Memory Allocation 
Services.
Unfortunately I can't test not calling the function, hence I didn't include the 
change and hope you know the answer.

Regards,
Marvin.

> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Friday, November 4, 2016 2:34 AM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Tian, Feng ; Zeng, Star 
> Subject: RE: [PATCH v2 1/2] MdeModulePkg: Do not free memory during
> ExitBootServices ().
> 
> Reviewed-by: Star Zeng 
> 
> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Friday, November 4, 2016 7:10 AM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng ; Zeng, Star 
> Subject: [PATCH v2 1/2] MdeModulePkg: Do not free memory during
> ExitBootServices ().
> 
> During exiting Boot Services, there should be no changes made to the
> Memory Map. This patch eliminates explicit and implicit calls to the Memory
> Allocation Services and, where applicable, zeros the memory instead.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Marvin Haeuser 
> ---
>  MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c | 11 +--
>  MdeModulePkg/Universal/Network/SnpDxe/Snp.c | 12 
>  2 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
> b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
> index ae202c3fe24a..b5e36b8bec06 100644
> --- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
> +++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
> @@ -872,9 +872,16 @@ IScsiOnExitBootService (
>ISCSI_DRIVER_DATA *Private;
> 
>Private = (ISCSI_DRIVER_DATA *) Context;
> -  gBS->CloseEvent (Private->ExitBootServiceEvent);
> 
> -  IScsiSessionAbort (&Private->Session);
> +  if (Private->Session.Signature != 0) {
> +IScsiSessionAbort (&Private->Session);
> +
> +//
> +// Empty Session as it will not be freed.
> +// This will also prevent this code from being re-run.
> +//
> +ZeroMem (&Private->Session, sizeof (Private->Session));  }
>  }
> 
>  /**
> diff --git a/MdeModulePkg/Universal/Network/SnpDxe/Snp.c
> b/MdeModulePkg/Universal/Network/SnpDxe/Snp.c
> index 9f61aee05773..e15e79c7065f 100644
> --- a/MdeModulePkg/Universal/Network/SnpDxe/Snp.c
> +++ b/MdeModulePkg/Universal/Network/SnpDxe/Snp.c
> @@ -32,6 +32,18 @@ SnpNotifyExitBootServices (
> 
>Snp  = (SNP_DRIVER *)Context;
> 
> +  if (Snp->TxRxBuffer != NULL) {
> +//
> +// Empty TxRxBuffer as it will not be freed.
> +//
> +ZeroMem (Snp->TxRxBuffer, Snp->TxRxBufferSize);
> +
> +//
> +// Set TxRxBuffer to NULL so FreeBuffer () will not be called.
> +//
> +Snp->TxRxBuffer = NULL;
> +  }
> +
>//
>// Shutdown and stop UNDI driver
>//
> --
> 2.10.1.windows.1

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

Re: [edk2] TianoCore UEFI Development Kit build: how to cause the build process to correctly recognize the build platform (Linux)?

[Marvin Häuser]

Hey,

As you have found out, Nt32Pkg is for Windows and shouldn't be built on Linux.
You can specify the platform descriptor file to build via the "-p " 
parameter.

Regards,
Marvin.

> -Ursprüngliche Nachricht-
> Von: edk2-devel  Im Auftrag von Aleksey
> Shevandin
> Gesendet: Sonntag, 15. April 2018 17:23
> An: edk2-devel@lists.01.org
> Betreff: [edk2] TianoCore UEFI Development Kit build: how to cause the
> build process to correctly recognize the build platform (Linux)?
> 
> Dear members,
> 
> I'm trying to build *UDK2018* on *Ubuntu 17*. After studying the
> documentation, I had impressed that the platform setup script
> (*sedksetup.sh*) shall configure the build framework to target the correct
> build platform, the tool chain etc. Unfortunately this is not what actually
> happens.
> 
> The platform build process (the Build base tool) unexpectedly tries to build
> some *MS Windows* oriented stuff and fails. How this can be fixed?
> 
> Following the documented recommendations, at the first stage I build the
> "Base Tools":
> 
> |/make all -C ${EDK_TOOLS_PATH}/|
> 
> Then I run the setup script:
> 
> |/edksetup.sh BaseTools/|
> 
> This stages are finished with success, also the setup script runs some tests
> that successfully pass.
> 
> On the next stage I'm trying to build the platform:
> 
> |build all -a X64 -t GCC5|
> 
> This last stage fails with the follow error:
> 
> Nt32Pkg/Include/WinNtPeim.h:27:10: fatal error: Common/WinNtInclude.h:
> No such file or directory
> 
> 
> Regards,
> 
> Aleksey
> 
> ___
> 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] FW: [PATCH] UefiCpuPkg/SecMain: Add NORETURN decorator to SecStartup().

[Marvin Häuser]

Hey Eric and Laszlo,

If I am not mistaken, this patch has neither been reviewed by Eric, nor was it 
pushed.
Just forwarding it in case it was forgotten about.

Thank you very much!

Best regards,
Marvin.

> -Ursprüngliche Nachricht-
> Von: Laszlo Ersek 
> Gesendet: Dienstag, 27. Februar 2018 18:41
> An: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: eric.d...@intel.com
> Betreff: Re: [PATCH] UefiCpuPkg/SecMain: Add NORETURN decorator to
> SecStartup().
> 
> On 02/27/18 17:50, Marvin Häuser wrote:
> > The function SecStartup() is not supposed to return. Hence, add the
> > NORETURN decorator.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  UefiCpuPkg/SecCore/SecMain.c | 6 ++
> UefiCpuPkg/SecCore/SecMain.h
> > | 1 +
> >  2 files changed, 7 insertions(+)
> >
> > diff --git a/UefiCpuPkg/SecCore/SecMain.c
> > b/UefiCpuPkg/SecCore/SecMain.c index c241d3704af7..6f9db0584ce1
> 100644
> > --- a/UefiCpuPkg/SecCore/SecMain.c
> > +++ b/UefiCpuPkg/SecCore/SecMain.c
> > @@ -113,6 +113,7 @@ SecPerformancePpiCallBack (
> >@param BootFirmwareVolume  Base address of the Boot Firmware
> Volume.
> >  **/
> >  VOID
> > +NORETURN
> >  EFIAPI
> >  SecStartup (
> >IN UINT32   SizeOfRam,
> > @@ -201,6 +202,11 @@ SecStartup (
> >// Initialize Debug Agent to support source level debug in SEC/PEI phases
> before memory ready.
> >//
> >InitializeDebugAgent (DEBUG_AGENT_INIT_PREMEM_SEC,
> &SecCoreData,
> > SecStartupPhase2);
> > +
> > +  //
> > +  // Should not come here.
> > +  //
> > +  UNREACHABLE ();
> >  }
> >
> >  /**
> > diff --git a/UefiCpuPkg/SecCore/SecMain.h
> > b/UefiCpuPkg/SecCore/SecMain.h index 46c7d41c6e3e..42a5718cfdd5
> 100644
> > --- a/UefiCpuPkg/SecCore/SecMain.h
> > +++ b/UefiCpuPkg/SecCore/SecMain.h
> > @@ -76,6 +76,7 @@ SecTemporaryRamDone (
> >@param BootFirmwareVolume  Base address of the Boot Firmware
> Volume.
> >  **/
> >  VOID
> > +NORETURN
> >  EFIAPI
> >  SecStartup (
> >IN UINT32   SizeOfRam,
> >
> 
> I checked the NORETURN and UNREACHABLE() macros in
> "MdePkg/Include/Base.h", and also the InitializeDebugAgent() API. I think
> the patch is correct.
> 
> Reviewed-by: Laszlo Ersek 
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 2/2] IntelFrameworkPkg/FrameworkUefiLib: Add 'OUT' decorator where necessary.

[Marvin Häuser]

The functions AddUnicodeString() and AddUnicodeString2() might return
a new value into their parameter UnicodeStringTable, hence add the
appropiate 'OUT' decorator.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c 
b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c
index 895ff39fc140..61a32e297606 100644
--- a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c
+++ b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c
@@ -865,11 +865,10 @@ LookupUnicodeString2 (
 **/
 EFI_STATUS
 EFIAPI
-AddUnicodeString (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString
   )
 {
   UINTN NumberOfEntries;
@@ -1043,11 +1042,11 @@ AddUnicodeString (
 EFI_STATUS
 EFIAPI
 AddUnicodeString2 (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString,
-  IN BOOLEAN   Iso639Language
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString,
+  IN BOOLEAN   Iso639Language
   )
 {
   UINTN NumberOfEntries;
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2 1/2] MdePkg/UefiLib: Add 'OUT' decorator where necessary.

[Marvin Häuser]

The functions AddUnicodeString() and AddUnicodeString2() might return
a new value into their parameter UnicodeStringTable, hence add the
appropiate 'OUT' decorator.

V2: Update FrameworkUefiLib as well.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiLib/UefiLib.c | 18 +-
 MdePkg/Include/Library/UefiLib.h | 18 +-
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/MdePkg/Library/UefiLib/UefiLib.c b/MdePkg/Library/UefiLib/UefiLib.c
index f1a3f1c7af05..ba449a1c34ce 100644
--- a/MdePkg/Library/UefiLib/UefiLib.c
+++ b/MdePkg/Library/UefiLib/UefiLib.c
@@ -888,10 +888,10 @@ LookupUnicodeString2 (
 EFI_STATUS
 EFIAPI
 AddUnicodeString (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString
   )
 {
   UINTN NumberOfEntries;
@@ -1065,11 +1065,11 @@ AddUnicodeString (
 EFI_STATUS
 EFIAPI
 AddUnicodeString2 (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString,
-  IN BOOLEAN   Iso639Language
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString,
+  IN BOOLEAN   Iso639Language
   )
 {
   UINTN NumberOfEntries;
diff --git a/MdePkg/Include/Library/UefiLib.h b/MdePkg/Include/Library/UefiLib.h
index 54bc2cc5a334..256498e3fd8d 100644
--- a/MdePkg/Include/Library/UefiLib.h
+++ b/MdePkg/Include/Library/UefiLib.h
@@ -587,10 +587,10 @@ LookupUnicodeString2 (
 EFI_STATUS
 EFIAPI
 AddUnicodeString (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString
   );
 
 /**
@@ -638,11 +638,11 @@ AddUnicodeString (
 EFI_STATUS
 EFIAPI
 AddUnicodeString2 (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString,
-  IN BOOLEAN   Iso639Language
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString,
+  IN BOOLEAN   Iso639Language
   );
 
 /**
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Marvin Häuser]

Initially added for GCC build support, this patch includes the
function for all compilers and all architectures. This is done as
huge variables on the stack may cause the generation of calls to this
intrinsic function for Microsoft compilers, even for the IA32
architecture, too.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/BaseLib/{ChkStkGcc.c => ChkStk.c} | 48 ++--
 MdePkg/Library/BaseLib/BaseLib.inf   |  4 +-
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/MdePkg/Library/BaseLib/ChkStkGcc.c 
b/MdePkg/Library/BaseLib/ChkStk.c
similarity index 74%
rename from MdePkg/Library/BaseLib/ChkStkGcc.c
rename to MdePkg/Library/BaseLib/ChkStk.c
index ecba3853b159..59e6d73f9331 100644
--- a/MdePkg/Library/BaseLib/ChkStkGcc.c
+++ b/MdePkg/Library/BaseLib/ChkStk.c
@@ -1,24 +1,24 @@
-/** @file
-  Provides hack function for passng GCC build.
-
-  Copyright (c) 2006 - 2008, 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 "BaseLibInternals.h"
-
-/**
-  Hack function for passing GCC build.
-**/
-VOID 
-__chkstk() 
-{
-}
-
+/** @file
+  Provides hack function for passing build.
+
+  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  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 "BaseLibInternals.h"
+
+/**
+  Hack function for passing build.
+**/
+VOID 
+__chkstk() 
+{
+}
+
diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index 5fbbd02a94b6..d23a6db2581a 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Base Library implementation.
 #
-#  Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
 #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
 #  Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
 #
@@ -64,6 +64,7 @@ [Sources]
   SafeString.c
   String.c
   FilePaths.c
+  ChkStk.c
   BaseLibInternals.h
 
 [Sources.Ia32]
@@ -781,7 +782,6 @@ [Sources.X64]
   X64/DisableCache.S | GCC
   X64/RdRand.nasm| GCC
   X64/RdRand.S | GCC
-  ChkStkGcc.c  | GCC 
 
 [Sources.IPF]
   Ipf/AccessGp.s
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdePkg/PeiServicesLib: Decorate 'PpiDescriptor' as OPTIONAL for LocatePpi().

[Marvin Häuser]

The UEFI PI specification defines PpiDescriptor to be OPTIONAL for
the LocatePpi PEI Service. This patch reflects this in the function
declaration and definition of the corresponding PeiServices library
function.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/PeiServicesLib/PeiServicesLib.c | 4 ++--
 MdePkg/Include/Library/PeiServicesLib.h| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Library/PeiServicesLib/PeiServicesLib.c 
b/MdePkg/Library/PeiServicesLib/PeiServicesLib.c
index d0838ed709f6..881b9cd52e1a 100644
--- a/MdePkg/Library/PeiServicesLib/PeiServicesLib.c
+++ b/MdePkg/Library/PeiServicesLib/PeiServicesLib.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation for PEI Services Library.
 
-  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -95,7 +95,7 @@ EFIAPI
 PeiServicesLocatePpi (
   IN CONST EFI_GUID   *Guid,
   IN UINTN  Instance,
-  IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor,
+  IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor, OPTIONAL
   IN OUT VOID   **Ppi
   )
 {
diff --git a/MdePkg/Include/Library/PeiServicesLib.h 
b/MdePkg/Include/Library/PeiServicesLib.h
index 0be72237f290..7cea34000c2f 100644
--- a/MdePkg/Include/Library/PeiServicesLib.h
+++ b/MdePkg/Include/Library/PeiServicesLib.h
@@ -1,7 +1,7 @@
 /** @file
   Provides library functions for all PEI Services.
 
-Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -73,7 +73,7 @@ EFIAPI
 PeiServicesLocatePpi (
   IN CONST EFI_GUID   *Guid,
   IN UINTN  Instance,
-  IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor,
+  IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor, OPTIONAL
   IN OUT VOID   **Ppi
   );
 
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdeModulePkg/AcpiPlatformDxe: Unload after execution.

[Marvin Häuser]

AcpiPlatformDxe solely performs one-time tasks and does not expose
any services or create any events. Hence it can safely be unloaded
after the Entry Point execution by returning an error code.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c 
b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
index 44bdd94fa8db..8772961bfd31 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
+++ b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
@@ -1,7 +1,7 @@
 /** @file
   Sample ACPI Platform Driver
 
-  Copyright (c) 2008 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -255,6 +255,9 @@ AcpiPlatformEntryPoint (
 }
   }
 
-  return EFI_SUCCESS;
+  //
+  // Return an error code so that the driver is unloaded.
+  //
+  return EFI_ALREADY_STARTED;
 }
 
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdePkg/UefiFileHandleLib: Fix potential NULL dereference.

[Marvin Häuser]

Move the NULL-check in FileHandleGetInfo() to directly after the
allocation to prevent potential NULL dereferences.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 30 +++-
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index 57aad77bc135..bcf3a328b82d 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to EFI_FILE_HANDLE functionality.
 
-  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. 
+  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -74,19 +74,21 @@ FileHandleGetInfo (
 // error is expected.  getting size to allocate
 //
 FileInfo = AllocateZeroPool(FileInfoSize);
-//
-// now get the information
-//
-Status = FileHandle->GetInfo(FileHandle,
- &gEfiFileInfoGuid,
- &FileInfoSize,
- FileInfo);
-//
-// if we got an error free the memory and return NULL
-//
-if (EFI_ERROR(Status) && (FileInfo != NULL)) {
-  FreePool(FileInfo);
-  FileInfo = NULL;
+if (FileInfo != NULL) {
+  //
+  // now get the information
+  //
+  Status = FileHandle->GetInfo(FileHandle,
+   &gEfiFileInfoGuid,
+   &FileInfoSize,
+   FileInfo);
+  //
+  // if we got an error free the memory and return NULL
+  //
+  if (EFI_ERROR(Status)) {
+FreePool(FileInfo);
+FileInfo = NULL;
+  }
 }
   }
   return (FileInfo);
-- 
2.17.0.windows.1

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

[edk2] [PATCH] ShellPkg/UefiShellLevel2CommandsLib: Support unspecified local Timezone.

[Marvin Häuser]

EFI_RUNTIME_SERVICES.GetTime() might return an unspecified Timezone,
such as when SetTime() has not been called after the PC-AT CMOS RTC
was cut off power. Consider this case by not attempting Timezone
translations for when it is invalid.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
index 7d2e15f5206b..73804b4516ba 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
@@ -2,7 +2,7 @@
   Main file for ls shell level 2 function.
 
   (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -506,7 +506,7 @@ PrintLsOutput(
   // Change the file time to local time.
   //
   Status = gRT->GetTime(&LocalTime, NULL);
-  if (!EFI_ERROR (Status)) {
+  if (!EFI_ERROR (Status) && (LocalTime.TimeZone != 
EFI_UNSPECIFIED_TIMEZONE)) {
 if ((Node->Info->CreateTime.TimeZone != EFI_UNSPECIFIED_TIMEZONE) &&
 (Node->Info->CreateTime.Month >= 1 && Node->Info->CreateTime.Month 
<= 12)) {
   //
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdePkg/UefiFileHandleLib: Fix the Root directory determination.

[Marvin Häuser]

The current implementation of the FileHandleGetFileName() function
assumes that the Root directory always has the FileName '\0'.
However, the only requirement the UEFI specification defines is that
a prepended '\\' must be supported to access files and folders
relative to the Root directory.
This patch removes this assumption and supports constructing valid
paths for any value of FileName for the Root Directory.

In practice, this fixes compatibility issues with File System drivers
that report '\\' as the FileName of the Root directory, which
currently is both generating an invalid path ("") and resulting
in an EFI_NOT_FOUND result from the CurrentHandle->Open() call.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 29 ++--
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index 57aad77bc135..820801422996 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to EFI_FILE_HANDLE functionality.
 
-  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. 
+  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -820,10 +820,25 @@ FileHandleGetFileName (
 Status = EFI_OUT_OF_RESOURCES;
 break;
   } else {
+//
+// Prepare to move to the parent directory.
+// Also determine whether CurrentHandle refers to the Root directory.
+//
+Status = CurrentHandle->Open (CurrentHandle, &NextHigherHandle, L"..", 
EFI_FILE_MODE_READ, 0);
 //
 // We got info... do we have a name? if yes precede the current path 
with it...
 //
-if (StrLen (FileInfo->FileName) == 0) {
+if ((StrLen (FileInfo->FileName) == 0) || EFI_ERROR (Status)) {
+  //
+  // Both FileInfo->FileName being '\0' and EFI_ERROR() suggest that
+  // CurrentHandle refers to the Root directory.  As this loop ensures
+  // FullFileName is starting with '\\' at all times, signal success
+  // and exit the loop.
+  // While FileInfo->FileName could theoretically be a value other than
+  // '\0' or '\\', '\\' is guaranteed to be supported by the
+  // specification and hence its value can safely be ignored.
+  //
+  Status = EFI_SUCCESS;
   if (*FullFileName == NULL) {
 ASSERT((*FullFileName == NULL && Size == 0) || (*FullFileName != 
NULL));
 *FullFileName = StrnCatGrowLeft(FullFileName, &Size, L"\\", 0);
@@ -841,15 +856,11 @@ FileHandleGetFileName (
   FreePool(FileInfo);
 }
   }
-  //
-  // Move to the parent directory
-  //
-  Status = CurrentHandle->Open (CurrentHandle, &NextHigherHandle, L"..", 
EFI_FILE_MODE_READ, 0);
-  if (EFI_ERROR (Status)) {
-break;
-  }
 
   FileHandleClose(CurrentHandle);
+  //
+  // Move to the parent directory
+  //
   CurrentHandle = NextHigherHandle;
 }
   } else if (Status == EFI_NOT_FOUND) {
-- 
2.17.0.windows.1

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

[edk2] [PATCH] ShellPkg/UefiShellCommandLib: Do not error-exit when PlatformLang is missing.

[Marvin Häuser]

Currently, when the PlatformLang variable is missing,
UefiShellCommandLib error-exits. To prevent the entire UEFI Shell
from failing to load over a missing variable, "en-US" is assumed when
the variable location fails.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c 
b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
index 0df252b42036..dfcfd2e0dd54 100644
--- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
+++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
@@ -81,9 +81,6 @@ CommandInit(
   CHAR8   *PlatformLang;
   
   GetEfiGlobalVariable2 (EFI_PLATFORM_LANG_VARIABLE_NAME, 
(VOID**)&PlatformLang, NULL);
-  if (PlatformLang == NULL) {
-return EFI_UNSUPPORTED;
-  }
 
   if (gUnicodeCollation == NULL) {
 Status = gBS->LocateHandleBuffer (
@@ -120,7 +117,7 @@ CommandInit(
   BestLanguage = GetBestLanguage (
Uc->SupportedLanguages,
FALSE,
-   PlatformLang,
+   ((PlatformLang != NULL) ? PlatformLang : "en-US"),
NULL
);
   if (BestLanguage != NULL) {
@@ -132,7 +129,9 @@ CommandInit(
 if (Handles != NULL) {
   FreePool (Handles);
 }
-FreePool (PlatformLang);
+if (PlatformLang != NULL) {
+  FreePool (PlatformLang);
+}
   }
 
   return (gUnicodeCollation == NULL) ? EFI_UNSUPPORTED : EFI_SUCCESS;
-- 
2.17.0.windows.1

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

[edk2] [PATCH] ShellPkg/UefiShellLevel2CommandsLib: Fix ls on entirely empty directories.

[Marvin Häuser]

Currently, when 'ls' is run on an entirely empty directory (this
includes not having '.' and '..'), the output is always 'File not
found'. For when not filtering its children, this patch rather
displays the usual header and footer.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 33 +---
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
index 7d2e15f5206b..324dcb6091c8 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
@@ -423,6 +423,8 @@ FileTimeToLocalTime (
   @param[in] Found  Set to TRUE, if anyone were found.
   @param[in] Count  The count of bits enabled in Attribs.
   @param[in] TimeZone   The current time zone offset.
+  @param[in] ListUnfiltered TRUE to request listing the directory contents
+unfiltered.
 
   @retval SHELL_SUCCESS the printing was sucessful.
 **/
@@ -435,7 +437,8 @@ PrintLsOutput(
   IN CONST CHAR16  *SearchString,
   IN   BOOLEAN *Found,
   IN CONST UINTN   Count,
-  IN CONST INT16   TimeZone
+  IN CONST INT16   TimeZone,
+  IN CONST BOOLEAN ListUnfiltered
   )
 {
   EFI_STATUSStatus;
@@ -561,7 +564,7 @@ PrintLsOutput(
   HeaderPrinted = TRUE;
 }
 
-if (!Sfo && ShellStatus != SHELL_ABORTED) {
+if (!Sfo && ShellStatus != SHELL_ABORTED && HeaderPrinted) {
   PrintNonSfoFooter(FileCount, FileSize, DirCount);
 }
   }
@@ -608,7 +611,8 @@ PrintLsOutput(
 SearchString,
 &FoundOne,
 Count,
-TimeZone);
+TimeZone,
+FALSE);
 
   //
   // Since it's running recursively, we have to break immediately when 
returned SHELL_ABORTED
@@ -625,7 +629,21 @@ PrintLsOutput(
   ShellCloseFileMetaArg(&ListHead);
 
   if (Found == NULL && !FoundOne) {
-return (SHELL_NOT_FOUND);
+if (ListUnfiltered) {
+  //
+  // When running "ls" without any filtering request, avoid outputing
+  // "File not found" when the directory is entirely empty, but print
+  // header and footer stating "0 File(s), 0 Dir(s)".
+  //
+  if (!Sfo) {
+PrintNonSfoHeader (RootPath);
+if (ShellStatus != SHELL_ABORTED) {
+  PrintNonSfoFooter (FileCount, FileSize, DirCount);
+}
+  }
+} else {
+  return (SHELL_NOT_FOUND);
+}
   }
 
   if (Found != NULL) {
@@ -668,6 +686,7 @@ ShellCommandRunLs (
   UINTN Size;
   EFI_TIME  TheTime;
   CHAR16*SearchString;
+  BOOLEAN   ListUnfiltered;
 
   Size= 0;
   FullPath= NULL;
@@ -679,6 +698,7 @@ ShellCommandRunLs (
   SearchString= NULL;
   CurDir  = NULL;
   Count   = 0;
+  ListUnfiltered  = FALSE;
 
   //
   // initialize the shell lib (we must be in non-auto-init...)
@@ -774,6 +794,7 @@ ShellCommandRunLs (
 ShellStatus = SHELL_NOT_FOUND;
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_NO_CWD), 
gShellLevel2HiiHandle, L"ls");  
   }
+  ListUnfiltered = TRUE;
   //
   // Copy to the 2 strings for starting path and file search string
   //
@@ -814,6 +835,7 @@ ShellCommandRunLs (
   //
   // is listing ends with a directory, then we list all files in 
that directory
   //
+  ListUnfiltered = TRUE;
   StrnCatGrow(&SearchString, NULL, L"*", 0);
 } else {
   //
@@ -845,7 +867,8 @@ ShellCommandRunLs (
 SearchString,
 NULL,
 Count,
-TheTime.TimeZone
+TheTime.TimeZone,
+ListUnfiltered
);
   if (ShellStatus == SHELL_NOT_FOUND) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN 
(STR_LS_FILE_NOT_FOUND), gShellLevel2HiiHandle, L"ls", FullPath);  
-- 
2.17.0.windows.1

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

Re: [edk2] [PATCH] MdeModulePkg/AcpiPlatformDxe: Unload after execution.

[Marvin Häuser]

Sorry, I did not realize that error code was a thing.
Sure, I will submit a V2 soon, thanks!

Best regards,
Marvin

> -Ursprüngliche Nachricht-
> Von: Zeng, Star 
> Gesendet: Montag, 7. Mai 2018 03:52
> An: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Ni, Ruiyu ; Zeng,
> Star 
> Betreff: RE: [PATCH] MdeModulePkg/AcpiPlatformDxe: Unload after
> execution.
> 
> It is a good change. :)
> 
> Only one minor comment. How about using EFI_REQUEST_UNLOAD_IMAGE
> instead?
> 
> 
> ///
> /// If this value is returned by an EFI image, then the image should be
> unloaded.
> ///
> #define EFI_REQUEST_UNLOAD_IMAGE  DXE_ERROR (1)
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Saturday, May 5, 2018 10:26 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Dong, Eric ; Ni,
> Ruiyu 
> Subject: [PATCH] MdeModulePkg/AcpiPlatformDxe: Unload after execution.
> 
> AcpiPlatformDxe solely performs one-time tasks and does not expose any
> services or create any events. Hence it can safely be unloaded after the Entry
> Point execution by returning an error code.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser 
> ---
>  MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c | 7 +-
> -
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
> b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
> index 44bdd94fa8db..8772961bfd31 100644
> --- a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
> +++ b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
> @@ -1,7 +1,7 @@
>  /** @file
>Sample ACPI Platform Driver
> 
> -  Copyright (c) 2008 - 2011, Intel Corporation. All rights reserved.
> +  Copyright (c) 2008 - 2018, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at @@ -255,6 +255,9 @@ AcpiPlatformEntryPoint (
>  }
>}
> 
> -  return EFI_SUCCESS;
> +  //
> +  // Return an error code so that the driver is unloaded.
> +  //
> +  return EFI_ALREADY_STARTED;
>  }
> 
> --
> 2.17.0.windows.1

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

[edk2] [PATCH v2] MdeModulePkg/AcpiPlatformDxe: Unload after execution.

[Marvin Häuser]

AcpiPlatformDxe solely performs one-time tasks and does not expose
any services or create any events. Hence it can safely be unloaded
after the Entry Point execution by returning an error code.

V2: Return EFI_REQUEST_UNLOAD_IMAGE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c 
b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
index 44bdd94fa8db..8f335bde0d46 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
+++ b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
@@ -1,7 +1,7 @@
 /** @file
   Sample ACPI Platform Driver
 
-  Copyright (c) 2008 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -255,6 +255,9 @@ AcpiPlatformEntryPoint (
 }
   }
 
-  return EFI_SUCCESS;
+  //
+  // The driver does not require to be kept loaded.
+  //
+  return EFI_REQUEST_UNLOAD_IMAGE;
 }
 
-- 
2.17.0.windows.1

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

[edk2] [PATCH 1/2] MdeModulePkg: Add PlatformAcpiLib LibraryClass.

[Marvin Häuser]

PlatformAcpiLib can be consumed by the generic ACPI Platform driver
to allow platform specific updates to the ACPI tables loaded from the
configured Firmware Volume. This allows for more platforms to
incorporate the generic ACPI Platform driver.

This commit also provides a NULL implementation of PlatformAcpiLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.c   | 36 

 MdeModulePkg/Include/Library/PlatformAcpiLib.h   | 36 

 MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.inf | 35 
+++
 MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.uni | 18 
++
 MdeModulePkg/MdeModulePkg.dec|  4 
+++
 MdeModulePkg/MdeModulePkg.dsc|  2 
++
 6 files changed, 131 insertions(+)

diff --git 
a/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.c 
b/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.c
new file mode 100644
index ..5d5d0d051e1b
--- /dev/null
+++ b/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.c
@@ -0,0 +1,36 @@
+/** @file
+  Null Platform ACPI Library instance.
+
+Copyright (c) 2018, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under 
+the terms and conditions of the BSD License that accompanies this 
distribution.  
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.

+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  
   
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+
+#include 
+
+/**
+  Performs platform specific updates to CurrentTable.
+
+  @param[in,out] CurrentTable  The table to perform updates on.
+
+  @retval RETURN_SUCCESS  The platform specific ACPI table updates were applied
+  successfully.
+  @retval other   The platform specific ACPI table updates could not be
+  applied.
+  
+**/
+RETURN_STATUS
+PlatformAcpiUpdateTable (
+  IN OUT EFI_ACPI_COMMON_HEADER  *CurrentTable
+  )
+{
+  return RETURN_SUCCESS;
+}
diff --git a/MdeModulePkg/Include/Library/PlatformAcpiLib.h 
b/MdeModulePkg/Include/Library/PlatformAcpiLib.h
new file mode 100644
index ..a3e367f3ab61
--- /dev/null
+++ b/MdeModulePkg/Include/Library/PlatformAcpiLib.h
@@ -0,0 +1,36 @@
+/** @file
+  Platform ACPI library. Platform can provide an implementation of this
+  library class to provide an ACPI table update routine that may be required
+  for some type of platform initialization.
+
+Copyright (c) 2018, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under 
+the terms and conditions of the BSD License that accompanies this 
distribution.  
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.

+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  
   
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __PLATFORM_ACPI_LIB__
+#define __PLATFORM_ACPI_LIB__
+
+/**
+  Performs platform specific updates to CurrentTable.
+
+  @param[in,out] CurrentTable  The table to perform updates on.
+
+  @retval RETURN_SUCCESS  The platform specific ACPI table updates were applied
+  successfully.
+  @retval other   The platform specific ACPI table updates could not be
+  applied.
+  
+**/
+RETURN_STATUS
+PlatformAcpiUpdateTable (
+  IN OUT EFI_ACPI_COMMON_HEADER  *CurrentTable
+  );
+
+#endif // __PLATFORM_ACPI_LIB__
diff --git 
a/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.inf 
b/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.inf
new file mode 100644
index ..a548ecdd91a7
--- /dev/null
+++ b/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.inf
@@ -0,0 +1,35 @@
+## @file
+#  Null Platform ACPI Library instance.
+#
+#  Copyright (c) 2018, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAM

[edk2] [PATCH 2/2] MdeModulePkg/AcpiPlatformDxe: Consume PlatformAcpiLib.

[Marvin Häuser]

This patch updates the generic ACPI Platform driver to consume
PlatformAcpiLib to allow platform specific updates to the ACPI tables
loaded from the configured Firmware Volume. This allows for more
platforms to incorporate the generic ACPI Platform driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c  | 55 

 MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf |  1 +
 2 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c 
b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
index 8f335bde0d46..f1243279faa2 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
+++ b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -180,6 +181,7 @@ AcpiPlatformEntryPoint (
   UINT32 FvStatus;
   UINTN  TableSize;
   UINTN  Size;
+  RETURN_STATUS  Return;
 
   Instance = 0;
   CurrentTable = NULL;
@@ -216,35 +218,42 @@ AcpiPlatformEntryPoint (
   );
 if (!EFI_ERROR(Status)) {
   //
-  // Add the table
+  // Perform any platform-specific table updates.
   //
-  TableHandle = 0;
+  Return = PlatformAcpiUpdateTable (CurrentTable);
 
-  TableSize = ((EFI_ACPI_DESCRIPTION_HEADER *) CurrentTable)->Length;
-  ASSERT (Size >= TableSize);
+  if (!RETURN_ERROR (Return)) {
+//
+// Add the table
+//
+TableHandle = 0;
 
-  //
-  // Checksum ACPI table
-  //
-  AcpiPlatformChecksum ((UINT8*)CurrentTable, TableSize);
+TableSize = ((EFI_ACPI_DESCRIPTION_HEADER *) CurrentTable)->Length;
+ASSERT (Size >= TableSize);
 
-  //
-  // Install ACPI table
-  //
-  Status = AcpiTable->InstallAcpiTable (
-AcpiTable,
-CurrentTable,
-TableSize,
-&TableHandle
-);
+//
+// Checksum ACPI table
+//
+AcpiPlatformChecksum ((UINT8*)CurrentTable, TableSize);
 
-  //
-  // Free memory allocated by ReadSection
-  //
-  gBS->FreePool (CurrentTable);
+//
+// Install ACPI table
+//
+Status = AcpiTable->InstallAcpiTable (
+  AcpiTable,
+  CurrentTable,
+  TableSize,
+  &TableHandle
+  );
+
+//
+// Free memory allocated by ReadSection
+//
+gBS->FreePool (CurrentTable);
 
-  if (EFI_ERROR(Status)) {
-return EFI_ABORTED;
+if (EFI_ERROR(Status)) {
+  return EFI_ABORTED;
+}
   }
 
   //
diff --git a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 34b1600171d5..114a12dc3396 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -40,6 +40,7 @@ [LibraryClasses]
   PcdLib
   BaseMemoryLib
   DebugLib
+  PlatformAcpiLib
   UefiBootServicesTableLib
   UefiDriverEntryPoint
 
-- 
2.17.0.windows.1

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

Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Marvin Häuser]

Hey Liming,

According to the MSDN documentation, the call will be inserted for a stack 
usage past a defined threshold - 4 KB for IA32, 8 KB for X64 (source: 
https://msdn.microsoft.com/en-us/library/ms648426(v=vs.85).aspx).

Thanks,
Marvin

> -Ursprüngliche Nachricht-
> Von: Gao, Liming 
> Gesendet: Montag, 7. Mai 2018 14:16
> An: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> Betreff: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> Marvin:
>   In VS compiler, what case will trig this intrinsic function?
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin H?user
> > Sent: Saturday, May 5, 2018 10:25 PM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Gao, Liming
> > 
> > Subject: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> >
> > Initially added for GCC build support, this patch includes the
> > function for all compilers and all architectures. This is done as huge
> > variables on the stack may cause the generation of calls to this
> > intrinsic function for Microsoft compilers, even for the IA32
> > architecture, too.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  MdePkg/Library/BaseLib/{ChkStkGcc.c => ChkStk.c} | 48 ++--
> 
> >  MdePkg/Library/BaseLib/BaseLib.inf   |  4 +-
> >  2 files changed, 26 insertions(+), 26 deletions(-)
> >
> > diff --git a/MdePkg/Library/BaseLib/ChkStkGcc.c
> > b/MdePkg/Library/BaseLib/ChkStk.c similarity index 74% rename from
> > MdePkg/Library/BaseLib/ChkStkGcc.c
> > rename to MdePkg/Library/BaseLib/ChkStk.c index
> > ecba3853b159..59e6d73f9331 100644
> > --- a/MdePkg/Library/BaseLib/ChkStkGcc.c
> > +++ b/MdePkg/Library/BaseLib/ChkStk.c
> > @@ -1,24 +1,24 @@
> > -/** @file
> > -  Provides hack function for passng GCC build.
> > -
> > -  Copyright (c) 2006 - 2008, 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 "BaseLibInternals.h"
> > -
> > -/**
> > -  Hack function for passing GCC build.
> > -**/
> > -VOID
> > -__chkstk()
> > -{
> > -}
> > -
> > +/** @file
> > +  Provides hack function for passing build.
> > +
> > +  Copyright (c) 2006 - 2018, Intel Corporation. All rights
> > + reserved.  This program and the accompanying materials  are
> > + licensed and made available under the terms and conditions of the
> > + BSD License  which accompanies this distribution.  The full text of
> > + the license may be found at  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 "BaseLibInternals.h"
> > +
> > +/**
> > +  Hack function for passing build.
> > +**/
> > +VOID
> > +__chkstk()
> > +{
> > +}
> > +
> > diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
> > b/MdePkg/Library/BaseLib/BaseLib.inf
> > index 5fbbd02a94b6..d23a6db2581a 100644
> > --- a/MdePkg/Library/BaseLib/BaseLib.inf
> > +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> > @@ -1,7 +1,7 @@
> >  ## @file
> >  #  Base Library implementation.
> >  #
> > -#  Copyright (c) 2007 - 2016, Intel Corporation. All rights
> > reserved.
> > +#  Copyright (c) 2007 - 2018, Intel Corporation. All rights
> > +reserved.
> >  #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights
> > reserved.  #  Portions copyright (c) 2011 - 2013, ARM Ltd. All
> > rights reserved.  # @@ -64,6 +64,7 @@ [Sources]
> >SafeString.c
> >String.c
> >FilePaths.c
> > +  ChkStk.c
> >BaseLibInternals.h
> >
> >  [Sources.Ia32]
> > @@ -781,7 +782,6 @@ [Sources.X64]
> >X64/DisableCache.S | GCC
> >X64/RdRand.nasm| GCC
> >X64/RdRand.S | GCC
> > -  ChkStkGcc.c  | GCC
> >
> >  [Sources.IPF]
> >Ipf/AccessGp.s
> > --
> > 2.17.0.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Marvin Häuser]

Hey Yao,

As far as I am aware, all __chkstk does is access the stack in 4 KB intervals 
from the current location to the maximum requested location to eventually hit 
the Windows Guard Page, which then triggers the stack increase.
Because I do not know of any equivalent concept in edk2 and the intrinsic was 
already disabled for GCC, I supposed it was a good idea to do so globally. Are 
the potential issues I am not aware of?

Thanks,
Marvin.

> -Original Message-
> From: Yao, Jiewen 
> Sent: Wednesday, May 9, 2018 1:52 AM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> HI Marvin
> Would you mind to share the information on how you test this update?
> 
> 
> Per my experience, chkstk not only does the check but also does the real
> work to allocate more stack.
> 
> /Gs can be used to indicate the size (/Gs[num] control stack checking calls)
> 
> We use /Gs32768 by default, see tools_def.txt.
> 
> Usually, we just increase this value to override the default one, if we hit 
> this
> issue.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin H?user
> > Sent: Tuesday, May 8, 2018 4:37 PM
> > To: edk2-devel@lists.01.org
> > Cc: Gao, Liming 
> > Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> >
> > Hey Liming,
> >
> > According to the MSDN documentation, the call will be inserted for a
> > stack usage past a defined threshold - 4 KB for IA32, 8 KB for X64 (source:
> > https://msdn.microsoft.com/en-us/library/ms648426(v=vs.85).aspx).
> >
> > Thanks,
> > Marvin
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Gao, Liming 
> > > Gesendet: Montag, 7. Mai 2018 14:16
> > > An: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D 
> > > Betreff: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > >
> > > Marvin:
> > >   In VS compiler, what case will trig this intrinsic function?
> > >
> > > Thanks
> > > Liming
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> > > > Behalf Of Marvin H?user
> > > > Sent: Saturday, May 5, 2018 10:25 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Kinney, Michael D ; Gao, Liming
> > > > 
> > > > Subject: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > > >
> > > > Initially added for GCC build support, this patch includes the
> > > > function for all compilers and all architectures. This is done as
> > > > huge variables on the stack may cause the generation of calls to
> > > > this intrinsic function for Microsoft compilers, even for the IA32
> > > > architecture, too.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Marvin Haeuser 
> > > > ---
> > > >  MdePkg/Library/BaseLib/{ChkStkGcc.c => ChkStk.c} | 48
> > > > ++--
> > > 
> > > >  MdePkg/Library/BaseLib/BaseLib.inf   |  4 +-
> > > >  2 files changed, 26 insertions(+), 26 deletions(-)
> > > >
> > > > diff --git a/MdePkg/Library/BaseLib/ChkStkGcc.c
> > > > b/MdePkg/Library/BaseLib/ChkStk.c similarity index 74% rename from
> > > > MdePkg/Library/BaseLib/ChkStkGcc.c
> > > > rename to MdePkg/Library/BaseLib/ChkStk.c index
> > > > ecba3853b159..59e6d73f9331 100644
> > > > --- a/MdePkg/Library/BaseLib/ChkStkGcc.c
> > > > +++ b/MdePkg/Library/BaseLib/ChkStk.c
> > > > @@ -1,24 +1,24 @@
> > > > -/** @file
> > > > -  Provides hack function for passng GCC build.
> > > > -
> > > > -  Copyright (c) 2006 - 2008, 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 "BaseLibInternals.h"
> > > > -
> > > > -/**
> > > > -  Hack function for passing GCC build.
> > > > -**/
> > > > -VOID
> > > > -__chkstk()
> > > > -{
> > > > -}
> > > > -
> > > > +/** @file
> > > > +  Provides hack function for passing build.
> > > > +
> > > > +  Copyright (c) 2006 - 2018, Intel Corporation. All rights
> > > > + reserved.  This program and the accompanying materials  are
> > > > + licensed and made available under the terms and conditions of
> > > > + the BSD License  which accompanies this distribution.  The full
> > > > + text of the license may be found at
> > > > + http://opensource.org/licenses/bsd-
> > > license.php.
> > > > +
> > > > +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS
> IS"
> > > > + BAS

Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Marvin Häuser]

Oh, if you are prefering a good implementation, I will be all for that. This 
was just a 'quick workaround', same as currently done for GCC.
I'm actually unsure whether a good implementation is possible with a flat 
memory model. It will likely be mere luck whether there is enough space free 
below the stack, except for maybe when it's located very high (preferably past 
the 32-bit space).
Has there been any prior discussion on this topic? Would be interested to 
follow up if there was.

Thanks,
Marvin

> -Original Message-
> From: Yao, Jiewen 
> Sent: Wednesday, May 9, 2018 2:13 AM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> There are some open source implementation:
> MSVC: https://github.com/ispc/ispc/issues/542
> GCC:
> https://android.googlesource.com/toolchain/gcc/+/b094d6c4bf572654a031e
> cc4afe675154c886dc5/gcc-4.4.3/gcc/config/i386/chkstk.asm
> 
> The compiler generated code assumes the stack is enlarged after we can
> chkstk.
> 
> I agree empty function can make build pass.
> But more important, we need make it work if there is a need to increase the
> stack.
> The potential issue is that the later code (after chkstk) assumes the stack is
> increased, but actually it is not.
> 
> That is why I ask how this is validated.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Tuesday, May 8, 2018 4:58 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen ; Gao, Liming
> > 
> > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> >
> > Hey Yao,
> >
> > As far as I am aware, all __chkstk does is access the stack in 4 KB
> > intervals from the current location to the maximum requested location
> > to eventually hit the Windows Guard Page, which then triggers the stack
> increase.
> > Because I do not know of any equivalent concept in edk2 and the
> > intrinsic was already disabled for GCC, I supposed it was a good idea
> > to do so globally. Are the potential issues I am not aware of?
> >
> > Thanks,
> > Marvin.
> >
> > > -Original Message-
> > > From: Yao, Jiewen 
> > > Sent: Wednesday, May 9, 2018 1:52 AM
> > > To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > > Cc: Gao, Liming 
> > > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > >
> > > HI Marvin
> > > Would you mind to share the information on how you test this update?
> > >
> > >
> > > Per my experience, chkstk not only does the check but also does the
> > > real work to allocate more stack.
> > >
> > > /Gs can be used to indicate the size (/Gs[num] control stack
> > > checking calls)
> > >
> > > We use /Gs32768 by default, see tools_def.txt.
> > >
> > > Usually, we just increase this value to override the default one, if
> > > we hit this issue.
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> > > > Behalf Of Marvin H?user
> > > > Sent: Tuesday, May 8, 2018 4:37 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Gao, Liming 
> > > > Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include
> > > > ChkStk.c
> > > >
> > > > Hey Liming,
> > > >
> > > > According to the MSDN documentation, the call will be inserted for
> > > > a stack usage past a defined threshold - 4 KB for IA32, 8 KB for X64
> (source:
> > > > https://msdn.microsoft.com/en-us/library/ms648426(v=vs.85).aspx).
> > > >
> > > > Thanks,
> > > > Marvin
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Gao, Liming 
> > > > > Gesendet: Montag, 7. Mai 2018 14:16
> > > > > An: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D 
> > > > > Betreff: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > > > >
> > > > > Marvin:
> > > > >   In VS compiler, what case will trig this intrinsic function?
> > > > >
> > > > > Thanks
> > > > > Liming
> > > > > > -Original Message-
> > > > > > From: e

Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Marvin Häuser]

Hey Tim,

The compiler has no information regarding the size of the stack and hence 
cannot determine an overflow.
This is basically a warning that stack of a single function is big enough to 
reach past the Guard Page and ensures it will be accessed.

Yao,

I just realized there already is Stack protection code in edk2, I was only 
aware of Heap protection.
Wouldn't a proper implementation make sense now to maybe not expand the stack, 
but at least runtime-error?

Regards,
Marvin

> -Original Message-
> From: Tim Lewis 
> Sent: Wednesday, May 9, 2018 3:28 AM
> To: 'Yao, Jiewen' ; marvin.haeu...@outlook.com;
> edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> I think that this is a fatal error in EDK2. It basically says, "we are out of 
> stack
> space." The alternative is: the system hangs in an unexpected way since the
> stack overflows into other pages.
> 
> Tim
> 
> -Original Message-
> From: edk2-devel  On Behalf Of Yao,
> Jiewen
> Sent: Tuesday, May 8, 2018 5:25 PM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> We discussed internally in Intel.
> 
> The quick workaround is: use /Gs65536. :-)
> 
> At the same time, our recommendation is to revisit the code which triggers
> this error. Why this function need such a big stack? And try to reduce the
> local stack usage.
> 
> What is why we still use /Gs32768 as default, instead of /Gs65536.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin H?user
> > Sent: Tuesday, May 8, 2018 5:21 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen 
> > Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> >
> > Oh, if you are prefering a good implementation, I will be all for
> > that. This was just a 'quick workaround', same as currently done for GCC.
> > I'm actually unsure whether a good implementation is possible with a
> > flat memory model. It will likely be mere luck whether there is enough
> > space free below the stack, except for maybe when it's located very
> > high (preferably past the 32-bit space).
> > Has there been any prior discussion on this topic? Would be interested
> > to follow up if there was.
> >
> > Thanks,
> > Marvin
> >
> > > -Original Message-
> > > From: Yao, Jiewen 
> > > Sent: Wednesday, May 9, 2018 2:13 AM
> > > To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > > Cc: Gao, Liming 
> > > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > >
> > > There are some open source implementation:
> > > MSVC: https://github.com/ispc/ispc/issues/542
> > > GCC:
> > >
> https://android.googlesource.com/toolchain/gcc/+/b094d6c4bf572654a03
> > > 1e cc4afe675154c886dc5/gcc-4.4.3/gcc/config/i386/chkstk.asm
> > >
> > > The compiler generated code assumes the stack is enlarged after we
> > > can chkstk.
> > >
> > > I agree empty function can make build pass.
> > > But more important, we need make it work if there is a need to
> > > increase the stack.
> > > The potential issue is that the later code (after chkstk) assumes
> > > the stack is increased, but actually it is not.
> > >
> > > That is why I ask how this is validated.
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > >
> > > > -Original Message-
> > > > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > > > Sent: Tuesday, May 8, 2018 4:58 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Yao, Jiewen ; Gao, Liming
> > > > 
> > > > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > > >
> > > > Hey Yao,
> > > >
> > > > As far as I am aware, all __chkstk does is access the stack in 4
> > > > KB intervals from the current location to the maximum requested
> > > > location to eventually hit the Windows Guard Page, which then
> > > > triggers the stack
> > > increase.
> > > > Because I do not know of any equivalent concept in edk2 and the
> > > > intrinsic was already disabled for GCC, I supposed it was a good
> > > > idea to do so globally. Are the potential issues I am not aware of?
> > > >
> > > > Thanks,
>

[edk2] [PATCH] MdePkg: Update MmSwDispatch.h's references to SmmSw2Dispatch.

[Marvin Häuser]

MmSwDispatch.h current refers to the deprecated SmmSw2Dispatch
protocol. Replace those references with the new MmSwDispatch name.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Protocol/MmSwDispatch.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/Protocol/MmSwDispatch.h 
b/MdePkg/Include/Protocol/MmSwDispatch.h
index d3acb64e6f3d..44ef69ed76c6 100644
--- a/MdePkg/Include/Protocol/MmSwDispatch.h
+++ b/MdePkg/Include/Protocol/MmSwDispatch.h
@@ -4,7 +4,7 @@
 
   This protocol provides the parent dispatch service for a given MMI source 
generator.
 
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -15,8 +15,8 @@
 
 **/
 
-#ifndef _MM_SW_DISPATCH2_H_
-#define _MM_SW_DISPATCH2_H_
+#ifndef _MM_SW_DISPATCH_H_
+#define _MM_SW_DISPATCH_H_
 
 #include 
 
@@ -117,7 +117,7 @@ EFI_STATUS
 ///
 /// Interface structure for the MM Software MMI Dispatch Protocol.
 ///
-/// The EFI_MM_SW_DISPATCH2_PROTOCOL provides the ability to install child 
handlers for the
+/// The EFI_MM_SW_DISPATCH_PROTOCOL provides the ability to install child 
handlers for the
 /// given software.  These handlers will respond to software interrupts, and 
the maximum software
 /// interrupt in the EFI_MM_SW_REGISTER_CONTEXT is denoted by MaximumSwiValue.
 ///
-- 
2.17.0.windows.1

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

[edk2] [PATCH] EmulatorPkg/SmbiosLib: Declare the correct library class.

[Marvin Häuser]

Currently, SmbiosLib declares the PcdLib library class. Update the
declaration to declare SmbiosLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf 
b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
index adcd7ef08e20..a688fe02f225 100644
--- a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
+++ b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
@@ -2,7 +2,7 @@
 # SMBIOS Library 
 #
 # Copyright (c) 2012, Apple Inc. All rights reserved. 
-# Portions copyright (c) 2006 - 2010, Intel Corporation. All rights 
reserved.
+# Portions copyright (c) 2006 - 2018, Intel Corporation. All rights 
reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -20,7 +20,7 @@ [Defines]
   FILE_GUID  = 881863A2-09FD-3E44-8D62-7AE038D03747
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = PcdLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_APPLICATION 
UEFI_DRIVER 
+  LIBRARY_CLASS  = SmbiosLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_APPLICATION 
UEFI_DRIVER 
 
   CONSTRUCTOR= SmbiosLibConstructor
 
-- 
2.17.0.windows.1

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

Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.

[Marvin Häuser]

Hi Laszlo, thanks for your feedback!
Comments are inline.

I also CC'd Jordan and Ard because of OVMF references in the third comment.
Thanks in advance for your time!

I have rewritten a few parts multiple times, so, if something doesn't make 
sense (because I forgot to rework it in the context), please feel free to ask 
for clarification.

Best regards,
Marvin

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, May 15, 2018 10:22 AM
> To: Marvin H?user ; edk2-
> de...@lists.01.org
> Cc: eric.d...@intel.com; star.z...@intel.com
> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> 
> On 05/14/18 21:00, Marvin H?user wrote:
> > Hey Star, Eric and everyone else,
> >
> > I have seen that some platforms add a Boot Option for the UEFI Shell
> > in "PlatformBootManagerBeforeConsole()", which is called as part of
> > the regular boot flow. This is surely beneficial for development
> > platforms that are supposed to boot to UEFI Shell by default when no
> > other option has been registered,
> 
> (Side point: I sure wish *all* platforms included the UEFI shell, one way or
> another. Debugging issues is the *default* state of any computing system
> (all software has bugs), so debug tools must be a first class citizen. Forums
> are full of end-users asking for the UEFI shell on their physical platforms;
> frequently because their platform firmware gives them an extremely limited
> interface to managing boot and driver options, and the shell is seen as a way
> out of that, justifiedly.)

Definitely, sadly capacity and OEM mentality are still issues.
My point is just that a common user should not land in UEFI Shell by accident, 
but it should be explicitly launched.

> 
> > however for retail platforms it usually makes more sense to show the
> > UEFI Boot Menu,
> 
> Note that this is already solved in BdsDxe (if I understand your point
> anyway); please refer to commit d1de487dd2e7 ("MdeModulePkg/BdsDxe:
> fall back to a Boot Manager Menu loop before hanging", 2017-11-27).

Oh interesting, thanks! That might resolve it, but I didn't check it out yet.

> 
> > which renders adding the Shell Boot Option as part of the regular boot
> > flow obsolete and just adds up to the boot time. Meanwhile, there is a
> > function in the UefiBootManagerLib, "BmEnumerateBootOptions()", which
> > is called prior to entering the Boot Menu and, in my opinion, would be
> > the perfect place to introduce another PlatformBootManagerLib hook,
> > which retrieves platform-specific boot options, such as an UEFI Shell
> > or other utilities like a Memory Test application.
> 
> Hmmm, I'm not sure. The only function that calls
> BmEnumerateBootOptions() is EfiBootManagerRefreshAllBootOption(). The
> latter is a public UefiBootManagerLib API that several
> PlatformBootManagerLib instances call, usually from
> PlatformBootManagerAfterConsole(). PlatformBootManagerAfterConsole()

I have misunderstood the current edk2 logic to be what I expected (partially), 
however I have just discovered that scanned boot options are added to NV and to 
BootOrder. Furthermore, I did not mention another usage case for the proposed 
hook as I thought it was practically irrelevant to the edk2 community: 
Supporting Apple's bless boot concept. (For those who wonder, virtualizing 
macOS on Apple hardware is perfectly legal). So, I will have to explain a bit 
more in detail, in two parts.

UEFI BOOT

What I imagined to be the boot flow, by the specification and by my personal 
taste, is the following:
1. Boot BootOrder[] one-by-one. This connects the referenced drive and attempts 
to start the specified file. This is the case today.
2. Boot *Recovery[]. This is the case today.
3. There are two alternatives here, based on platform preference.
3.1. Boot enumerated drives (via the algorithm defined in the UEFI spec). I 
think this is not the case today.
3.2. Enumerate the drives (via the algorithm defined in the UEFI spec) and show 
them in BootManagerMenuApp. I think this is done today and is what I would 
prefer too.

What I basically do not agree with in the list above are two nuances.
3.1 and 3.2: I would like to see support for a platform-defined logic of 
enumerating in addition to the one defined in the UEFI spec. This can be used 
for UEFI Shell, platform diagnostic apps and Apple bless.
3.2: I think adding them as volatile variables is the better approach, except 
for platform-specific code, which should be capable of adding NV options. The 
reasoning behind this is that usually the found volumes are removable volumes 
(such as USB Flash Drives) and will be cleaned away soon again anyway. "Extra 
wishes" for boot options should be added via the UEFI Setup menu or UEFI Shell.
The reason why I still wish for platform code to be able to add NV options as 
part of enumeration is that FV-embedded tools are indeed NV (Shell etc.) and 
will not need to be cleaned up, as well as that we're not in an utopia. 
Sometimes an unwanted purge of 

Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.

[Marvin Häuser]

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, May 15, 2018 3:53 PM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: eric.d...@intel.com; star.z...@intel.com; jordan.l.jus...@intel.com;
> ard.biesheu...@linaro.org; ruiyu...@intel.com; Gabriel L. Somlo (GMail)
> ; Gerd Hoffmann 
> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> 
> On 05/15/18 15:02, Marvin Häuser wrote:
> >> -Original Message-
> >> From: Laszlo Ersek 
> >> Sent: Tuesday, May 15, 2018 10:22 AM
> >> To: Marvin Häuser ; edk2-
> >> de...@lists.01.org
> >> Cc: eric.d...@intel.com; star.z...@intel.com
> >> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> >>
> >> On 05/14/18 21:00, Marvin Häuser wrote:
> >>> [...] there is a
> >>> function in the UefiBootManagerLib, "BmEnumerateBootOptions()",
> >>> which is called prior to entering the Boot Menu and, in my opinion,
> >>> would be the perfect place to introduce another
> >>> PlatformBootManagerLib hook, which retrieves platform-specific boot
> >>> options, such as an UEFI Shell or other utilities like a Memory Test
> >>> application.
> >>
> >> Hmmm, I'm not sure. The only function that calls
> >> BmEnumerateBootOptions() is EfiBootManagerRefreshAllBootOption().
> The
> >> latter is a public UefiBootManagerLib API that several
> >> PlatformBootManagerLib instances call, usually from
> >> PlatformBootManagerAfterConsole().
> PlatformBootManagerAfterConsole()
> >
> > I have misunderstood the current edk2 logic to be what I expected
> > (partially), however I have just discovered that scanned boot options
> > are added to NV and to BootOrder.
> 
> This is not a coincidence. That's what the
> EfiBootManagerRefreshAllBootOption() API does, by design, and that's the
> functionality for which platforms call the API.
> 
> > Furthermore, I did not mention another usage case for the proposed
> > hook as I thought it was practically irrelevant to the edk2 community:
> > Supporting Apple's bless boot concept. (For those who wonder,
> > virtualizing macOS on Apple hardware is perfectly legal). So, I will
> > have to explain a bit more in detail, in two parts.
> >
> > UEFI BOOT
> >
> > What I imagined to be the boot flow, by the specification and by my
> > personal taste, is the following:
> > 1. Boot BootOrder[] one-by-one. This connects the referenced drive and
> >attempts to start the specified file. This is the case today.
> > 2. Boot *Recovery[]. This is the case today.
> > 3. There are two alternatives here, based on platform preference.
> > 3.1. Boot enumerated drives (via the algorithm defined in the UEFI
> >  spec). I think this is not the case today.
> > 3.2. Enumerate the drives (via the algorithm defined in the UEFI spec)
> >  and show them in BootManagerMenuApp. I think this is done today
> >  and is what I would prefer too.
> >
> > What I basically do not agree with in the list above are two nuances.
> > 3.1 and 3.2: I would like to see support for a platform-defined logic
> > of enumerating in addition to the one defined in the UEFI spec. This
> > can be used for UEFI Shell, platform diagnostic apps and Apple bless.
> 
> I think platform-specific boot option generation -- enumeration of various
> protocols that stand for different kinds of devices, and generating boot
> options from them -- is already possible today.
> Platforms call EfiBootManagerRefreshAllBootOption() because (a) it's easy to
> call, (b) it generally does the right thing.

It surely is possible today, the proposition is more concerned about 
performance and "best practice".
I simply don't see a good reason to perform scanning and boot option writing 
when there is no code to read that (yet).
Of course this makes it come down to maintainer's preference because there is 
no significant demand.

> 
> (Note that this API does not connect devices; it just scans devices and turns
> whatever it finds into boot options.)
> 
> Nothing stops a platform from *not* calling
> EfiBootManagerRefreshAllBootOption() -- the platform can simply skip that
> and generate other options. Or the platform may generate options in
> addition to those that are generated by the API.

That is perfectly valid for the Status Quo, however if my NV vs volatile 
comment should be considered, it will not be because it relies on a proactive 
BootMenuApp call (which happens to be to EfiBootManagerRefreshAllBootOption()).

> 
> > 3.2: 

Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.

[Marvin Häuser]

Thanks for your feedback!
Comments inline

Regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, May 15, 2018 6:12 PM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: gso...@gmail.com; ard.biesheu...@linaro.org; ruiyu...@intel.com;
> eric.d...@intel.com; star.z...@intel.com; jordan.l.jus...@intel.com
> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> 
> On 05/15/18 17:38, Marvin Häuser wrote:
> >> -Original Message-
> >> From: Laszlo Ersek 
> >> Sent: Tuesday, May 15, 2018 3:53 PM
> >> To: Marvin Häuser ; edk2-
> >> de...@lists.01.org
> >> Cc: eric.d...@intel.com; star.z...@intel.com;
> >> jordan.l.jus...@intel.com; ard.biesheu...@linaro.org;
> >> ruiyu...@intel.com; Gabriel L. Somlo (GMail) ; Gerd
> >> Hoffmann 
> >> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> >>
> >> On 05/15/18 15:02, Marvin Häuser wrote:
> 
> >>> 3.2: I think adding them as volatile variables is the better
> >>> approach, except for platform-specific code, which should be capable
> >>> of adding NV options. The reasoning behind this is that usually the
> >>> found volumes are removable volumes (such as USB Flash Drives) and
> >>> will be cleaned away soon again anyway. "Extra wishes" for boot
> >>> options should be added via the UEFI Setup menu or UEFI Shell.
> >>
> >> I can't really comment on this -- the fact that Boot options are
> >> non- volatile comes from the UEFI spec. I'm not immediately sure what
> >> I think of their suggested volatility, but this is likely something for the
> USWG to discuss.
> >
> > I think I might have been unclear here, I was solely referring to the Boot
> options created by the enumeration process and not Boot in general.
> > I wouldn't know of anything restricting all Boot variables to be NV, do
> you happen to have a quote?
> 
> See "3.3 Globally Defined Variables" and "Table 10. Global Variables" in the
> UEFI-2.7 spec:
> 
>   [...] The variables with an attribute of NV are nonvolatile. [...]
> 
>   [...]
> 
>   Variable Name  Attribute   Description
>   -  -   ---
>   [...]
>   Boot   NV, BS, RT  [...]
>   [...]

I had hoped it was a recommendation, but indeed it seems to be mandatory.
What's your opinion on this fact and how do you think the chances are NV could 
be made optional?

> 
> >> Second, just because a boot option fails, it should not be removed.
> >> For example, a netboot option could fail, or a USB drive might not be
> >> connected (temporarily). I don't think that's grounds enough for
> >> summarily removing a boot option, in shared reference code.
> >
> > Oh, I was just talking about the possibility, because the current code does
> remove options under certain conditions.
> > However, for USB devices as you have mentioned, I do see this good
> practice so long as the option is volatile.
> > There is no point in exposing a boot option to a removable device that is
> not attached if not to prevent unnecessary Flash cycles as far as I can think.
> > Do you happen to have worries about a scenario I did not consider?
> 
> Sure; it's a simple scenario: the user might want the system to automatically
> boot off of a USB drive whenever they connect it, before powering on or
> rebooting the system, rather than boot from the hard drive.

Remember that point was made in the context of enumeration. What I was saying 
is that boot options created by the enum code, for removable drives, are fine 
to be gone (as they are volatile, or proactively removed when NV) after a 
reboot.
If a user wants to boot from such an USB device by default, in my opinion they 
should manually create a boot option for it. Otherwise, if I do not 
misunderstand your point, you are suggesting the firmware to keep track of 
every single bootable USB device ever attached.

> 
> (For USB devices, "USB WWID" and "USB Class" device path nodes are
> defined by the spec, so the user isn't even expected to plug the drive into
> the same USB port, for the drive to be found uniquely.)

Actually didn't know that, thanks for the fact!

> 
> >>> Primary partition: The so-called "Startup Volume" unfortunately is a
> >>> bit trickier. For it, a practically invalid Boot Option is added,
> >>> which is an expanded device path to the volume to be booted, however
> >>> without having a File Device Path Node appended.
> >>
> &

[edk2] [PATCH] MdePkg/Hpet: Add Event Timer Block ID definition.

[Marvin Häuser]

This patch adds the HPET Event Timer Block ID definition that can be
found in the IA-PC HPET Specification, section 3.2.4.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h | 18 
+-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h 
b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
index 0d83cd5335de..926445233944 100644
--- a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
+++ b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
@@ -2,7 +2,7 @@
   ACPI high precision event timer table definition, at www.intel.com
   Specification name is IA-PC HPET (High Precision Event Timers) Specification.
 
-  Copyright (c) 2007 - 2008, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials  
   are licensed and made available under the terms and conditions of the BSD 
License 
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -22,6 +22,22 @@
 //
 #pragma pack(1)
 
+///
+/// HPET Event Timer Block ID described in IA-PC HPET Specification, 3.2.4.
+///
+typedef union {
+  struct {
+UINT32 Revision   : 8;
+UINT32 NumberOfTimers : 5;
+UINT32 CounterSize: 1;
+UINT32 Reserved   : 1;
+UINT32 LegacyRoute: 1;
+UINT32 VendorId   : 16;
+  }  Bits;
+  UINT32 Uint32;
+} EFI_ACPI_HIGH_PRECISION_EVENT_TIMER_BLOCK_ID;
+
+
 ///
 /// High Precision Event Timer Table header definition.
 ///
-- 
2.17.0.windows.1

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

Re: [edk2] [PATCH] MdePkg/Hpet: Add Event Timer Block ID definition.

[Marvin Häuser]

Hey Jaben,

I'm used to keeping the copyright date updated and because both the 
specification where the definition originates from and the present header are 
published by Intel, this effectively is all Intel IP.
Was this an incorrect change nevertheless? I'm not an expert in OSS 
contribution law.

Thanks,
Marvin

> -Original Message-
> From: Carsey, Jaben 
> Sent: Tuesday, May 15, 2018 11:26 PM
> To: Marvin Häuser 
> Subject: RE: [PATCH] MdePkg/Hpet: Add Event Timer Block ID definition.
> 
> Marvin,
> 
> Non-technical question here, but why do you update intel copyright from a
> non-intel email address.  This seems odd to me...
> 
> Thanks
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin Häuser
> > Sent: Tuesday, May 15, 2018 12:35 PM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Gao, Liming
> > 
> > Subject: [edk2] [PATCH] MdePkg/Hpet: Add Event Timer Block ID
> definition.
> >
> > This patch adds the HPET Event Timer Block ID definition that can be
> > found in the IA-PC HPET Specification, section 3.2.4.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h | 18
> > +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > index 0d83cd5335de..926445233944 100644
> > --- a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > +++ b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > @@ -2,7 +2,7 @@
> >ACPI high precision event timer table definition, at www.intel.com
> >Specification name is IA-PC HPET (High Precision Event Timers)
> > Specification.
> >
> > -  Copyright (c) 2007 - 2008, Intel Corporation. All rights
> > reserved.
> > +  Copyright (c) 2007 - 2018, Intel Corporation. All rights
> > + reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of
> > the BSD License
> >which accompanies this distribution.  The full text of the license
> > may be found at @@ -22,6 +22,22 @@  //  #pragma pack(1)
> >
> > +///
> > +/// HPET Event Timer Block ID described in IA-PC HPET Specification, 3.2.4.
> > +///
> > +typedef union {
> > +  struct {
> > +UINT32 Revision   : 8;
> > +UINT32 NumberOfTimers : 5;
> > +UINT32 CounterSize: 1;
> > +UINT32 Reserved   : 1;
> > +UINT32 LegacyRoute: 1;
> > +UINT32 VendorId   : 16;
> > +  }  Bits;
> > +  UINT32 Uint32;
> > +} EFI_ACPI_HIGH_PRECISION_EVENT_TIMER_BLOCK_ID;
> > +
> > +
> >  ///
> >  /// High Precision Event Timer Table header definition.
> >  ///
> > --
> > 2.17.0.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.

[Marvin Häuser]

Thanks for your comment,
Comments are inline

Regards,
Marvin.

> -Original Message-
> From: Ni, Ruiyu 
> Sent: Thursday, May 17, 2018 9:58 AM
> To: Marvin Häuser ; Laszlo Ersek
> ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; ard.biesheu...@linaro.org; Justen,
> Jordan L ; gso...@gmail.com; Zeng, Star
> 
> Subject: RE: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> 
> 
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: edk2-devel  On Behalf Of Marvin
> > Häuser
> > Sent: Wednesday, May 16, 2018 1:15 AM
> > To: Laszlo Ersek ; edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu ; Dong, Eric ;
> > ard.biesheu...@linaro.org; Justen, Jordan L
> > ; gso...@gmail.com; Zeng, Star
> > 
> > Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> >
> > Thanks for your feedback!
> > Comments inline
> >
> > Regards,
> > Marvin.
> >
> > > -Original Message-
> > > From: Laszlo Ersek 
> > > Sent: Tuesday, May 15, 2018 6:12 PM
> > > To: Marvin Häuser ; edk2-
> > > de...@lists.01.org
> > > Cc: gso...@gmail.com; ard.biesheu...@linaro.org; ruiyu...@intel.com;
> > > eric.d...@intel.com; star.z...@intel.com; jordan.l.jus...@intel.com
> > > Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> > >
> > > On 05/15/18 17:38, Marvin Häuser wrote:
> > > >> -Original Message-
> > > >> From: Laszlo Ersek 
> > > >> Sent: Tuesday, May 15, 2018 3:53 PM
> > > >> To: Marvin Häuser ; edk2-
> > > >> de...@lists.01.org
> > > >> Cc: eric.d...@intel.com; star.z...@intel.com;
> > > >> jordan.l.jus...@intel.com; ard.biesheu...@linaro.org;
> > > >> ruiyu...@intel.com; Gabriel L. Somlo (GMail) ;
> > > >> Gerd Hoffmann 
> > > >> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions()
> hook.
> > > >>
> > > >> On 05/15/18 15:02, Marvin Häuser wrote:
> > >
> > > >>> 3.2: I think adding them as volatile variables is the better
> > > >>> approach, except for platform-specific code, which should be
> > > >>> capable of adding NV options. The reasoning behind this is that
> > > >>> usually the found volumes are removable volumes (such as USB
> > > >>> Flash
> > > >>> Drives) and will be cleaned away soon again anyway. "Extra wishes"
> > > >>> for boot options should be added via the UEFI Setup menu or UEFI
> > Shell.
> > > >>
> > > >> I can't really comment on this -- the fact that Boot options
> > > >> are
> > > >> non- volatile comes from the UEFI spec. I'm not immediately sure
> > > >> what I think of their suggested volatility, but this is likely
> > > >> something for the
> > > USWG to discuss.
> > > >
> > > > I think I might have been unclear here, I was solely referring to
> > > > the Boot
> > > options created by the enumeration process and not Boot in
> general.
> > > > I wouldn't know of anything restricting all Boot variables to
> > > > be NV, do
> > > you happen to have a quote?
> > >
> > > See "3.3 Globally Defined Variables" and "Table 10. Global Variables"
> > > in the
> > > UEFI-2.7 spec:
> > >
> > >   [...] The variables with an attribute of NV are nonvolatile. [...]
> > >
> > >   [...]
> > >
> > >   Variable Name  Attribute   Description
> > >   -  -   ---
> > >   [...]
> > >   Boot   NV, BS, RT  [...]
> > >   [...]
> >
> > I had hoped it was a recommendation, but indeed it seems to be
> mandatory.
> > What's your opinion on this fact and how do you think the chances are
> > NV could be made optional?
> >
> > >
> > > >> Second, just because a boot option fails, it should not be removed.
> > > >> For example, a netboot option could fail, or a USB drive might
> > > >> not be connected (temporarily). I don't think that's grounds
> > > >> enough for summarily removing a boot option, in shared reference
> code.
> > > >
> > > > Oh, I was just talking about the possibility, because the current
> > > > code does
> > > remove options under certain conditions.
> > > > 

[edk2] [PATCH v2] MdePkg/UefiFileHandleLib: Fix potential NULL dereference.

[Marvin Häuser]

Move the NULL-check in FileHandleGetInfo() to directly after the
allocation to prevent potential NULL dereferences.

V2:
  - Do not change the copyright date as requested.
  - Added R-bs from V1 as no functional changes have been made.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
Reviewed-by: Ruiyu Ni 
---
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index 57aad77bc135..5b3d39ef6103 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -74,19 +74,21 @@ FileHandleGetInfo (
 // error is expected.  getting size to allocate
 //
 FileInfo = AllocateZeroPool(FileInfoSize);
-//
-// now get the information
-//
-Status = FileHandle->GetInfo(FileHandle,
- &gEfiFileInfoGuid,
- &FileInfoSize,
- FileInfo);
-//
-// if we got an error free the memory and return NULL
-//
-if (EFI_ERROR(Status) && (FileInfo != NULL)) {
-  FreePool(FileInfo);
-  FileInfo = NULL;
+if (FileInfo != NULL) {
+  //
+  // now get the information
+  //
+  Status = FileHandle->GetInfo(FileHandle,
+   &gEfiFileInfoGuid,
+   &FileInfoSize,
+   FileInfo);
+  //
+  // if we got an error free the memory and return NULL
+  //
+  if (EFI_ERROR(Status)) {
+FreePool(FileInfo);
+FileInfo = NULL;
+  }
 }
   }
   return (FileInfo);
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2] MdePkg/Hpet: Add Event Timer Block ID definition.

[Marvin Häuser]

This patch adds the HPET Event Timer Block ID definition that can be
found in the IA-PC HPET Specification, section 3.2.4.

V2:
  - Do not change the copyright date as requested.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h | 16 

 1 file changed, 16 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h 
b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
index 0d83cd5335de..6218a77c543c 100644
--- a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
+++ b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
@@ -22,6 +22,22 @@
 //
 #pragma pack(1)
 
+///
+/// HPET Event Timer Block ID described in IA-PC HPET Specification, 3.2.4.
+///
+typedef union {
+  struct {
+UINT32 Revision   : 8;
+UINT32 NumberOfTimers : 5;
+UINT32 CounterSize: 1;
+UINT32 Reserved   : 1;
+UINT32 LegacyRoute: 1;
+UINT32 VendorId   : 16;
+  }  Bits;
+  UINT32 Uint32;
+} EFI_ACPI_HIGH_PRECISION_EVENT_TIMER_BLOCK_ID;
+
+
 ///
 /// High Precision Event Timer Table header definition.
 ///
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2] MdePkg/UefiFileHandleLib: Fix the Root directory determination.

[Marvin Häuser]

The current implementation of the FileHandleGetFileName() function
assumes that the Root directory always has the FileName '\0'.
However, the only requirement the UEFI specification defines is that
a prepended '\\' must be supported to access files and folders
relative to the Root directory.
This patch removes this assumption and supports constructing valid
paths for any value of FileName for the Root Directory.

In praxis, this fixes compatibility issues with File System drivers
that report '\\' as the FileName of the Root directory, which
currently is both generating an invalid path ("") and resulting
in an EFI_NOT_FOUND result from the CurrentHandle->Open() call.

V2:
  - Do not change the copyright date as requested.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 27 ++--
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index 57aad77bc135..251cbc55edb5 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -820,10 +820,25 @@ FileHandleGetFileName (
 Status = EFI_OUT_OF_RESOURCES;
 break;
   } else {
+//
+// Prepare to move to the parent directory.
+// Also determine whether CurrentHandle refers to the Root directory.
+//
+Status = CurrentHandle->Open (CurrentHandle, &NextHigherHandle, L"..", 
EFI_FILE_MODE_READ, 0);
 //
 // We got info... do we have a name? if yes precede the current path 
with it...
 //
-if (StrLen (FileInfo->FileName) == 0) {
+if ((StrLen (FileInfo->FileName) == 0) || EFI_ERROR (Status)) {
+  //
+  // Both FileInfo->FileName being '\0' and EFI_ERROR() suggest that
+  // CurrentHandle refers to the Root directory.  As this loop ensures
+  // FullFileName is starting with '\\' at all times, signal success
+  // and exit the loop.
+  // While FileInfo->FileName could theoretically be a value other than
+  // '\0' or '\\', '\\' is guaranteed to be supported by the
+  // specification and hence its value can safely be ignored.
+  //
+  Status = EFI_SUCCESS;
   if (*FullFileName == NULL) {
 ASSERT((*FullFileName == NULL && Size == 0) || (*FullFileName != 
NULL));
 *FullFileName = StrnCatGrowLeft(FullFileName, &Size, L"\\", 0);
@@ -841,15 +856,11 @@ FileHandleGetFileName (
   FreePool(FileInfo);
 }
   }
-  //
-  // Move to the parent directory
-  //
-  Status = CurrentHandle->Open (CurrentHandle, &NextHigherHandle, L"..", 
EFI_FILE_MODE_READ, 0);
-  if (EFI_ERROR (Status)) {
-break;
-  }
 
   FileHandleClose(CurrentHandle);
+  //
+  // Move to the parent directory
+  //
   CurrentHandle = NextHigherHandle;
 }
   } else if (Status == EFI_NOT_FOUND) {
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2] MdePkg: Update MmSwDispatch.h's references to SmmSw2Dispatch.

[Marvin Häuser]

MmSwDispatch.h current refers to the deprecated SmmSw2Dispatch
protocol. Replace those references with the new MmSwDispatch name.

V2:
  - Do not change the copyright date as requested.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Protocol/MmSwDispatch.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/Protocol/MmSwDispatch.h 
b/MdePkg/Include/Protocol/MmSwDispatch.h
index d3acb64e6f3d..e412bb2e66c0 100644
--- a/MdePkg/Include/Protocol/MmSwDispatch.h
+++ b/MdePkg/Include/Protocol/MmSwDispatch.h
@@ -15,8 +15,8 @@
 
 **/
 
-#ifndef _MM_SW_DISPATCH2_H_
-#define _MM_SW_DISPATCH2_H_
+#ifndef _MM_SW_DISPATCH_H_
+#define _MM_SW_DISPATCH_H_
 
 #include 
 
@@ -117,7 +117,7 @@ EFI_STATUS
 ///
 /// Interface structure for the MM Software MMI Dispatch Protocol.
 ///
-/// The EFI_MM_SW_DISPATCH2_PROTOCOL provides the ability to install child 
handlers for the
+/// The EFI_MM_SW_DISPATCH_PROTOCOL provides the ability to install child 
handlers for the
 /// given software.  These handlers will respond to software interrupts, and 
the maximum software
 /// interrupt in the EFI_MM_SW_REGISTER_CONTEXT is denoted by MaximumSwiValue.
 ///
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2] EmulatorPkg/SmbiosLib: Declare the correct library class.

[Marvin Häuser]

Currently, SmbiosLib declares the PcdLib library class. Update the
declaration to declare SmbiosLib.

V2:
  - Do not change the copyright date as requested.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf 
b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
index adcd7ef08e20..36d5c350f51a 100644
--- a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
+++ b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
@@ -20,7 +20,7 @@ [Defines]
   FILE_GUID  = 881863A2-09FD-3E44-8D62-7AE038D03747
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = PcdLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_APPLICATION 
UEFI_DRIVER 
+  LIBRARY_CLASS  = SmbiosLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_APPLICATION 
UEFI_DRIVER 
 
   CONSTRUCTOR= SmbiosLibConstructor
 
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2] ShellPkg/UefiShellLevel2CommandsLib: Support unspecified local Timezone.

[Marvin Häuser]

EFI_RUNTIME_SERVICES.GetTime() might return an unspecified Timezone,
such as when SetTime() has not been called after the PC-AT CMOS RTC
was cut off power. Consider this case by not attempting Timezone
translations for when it is invalid.

V2:
  - Do not change the copyright date as requested.
  - Added R-bs from V1 as no functional changes have been made.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
Reviewed-by: Jaben Carsey 
Reviewed-by: Ruiyu Ni 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
index 7d2e15f5206b..e502685a1dbb 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
@@ -506,7 +506,7 @@ PrintLsOutput(
   // Change the file time to local time.
   //
   Status = gRT->GetTime(&LocalTime, NULL);
-  if (!EFI_ERROR (Status)) {
+  if (!EFI_ERROR (Status) && (LocalTime.TimeZone != 
EFI_UNSPECIFIED_TIMEZONE)) {
 if ((Node->Info->CreateTime.TimeZone != EFI_UNSPECIFIED_TIMEZONE) &&
 (Node->Info->CreateTime.Month >= 1 && Node->Info->CreateTime.Month 
<= 12)) {
   //
-- 
2.17.0.windows.1

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

Re: [edk2] [PATCH] MdePkg/Hpet: Add Event Timer Block ID definition.

[Marvin Häuser]

Hey Jaben,

Done.

Regards,
Marvin.

> -Original Message-
> From: Carsey, Jaben 
> Sent: Thursday, May 17, 2018 12:32 AM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
> 
> Subject: RE: [PATCH] MdePkg/Hpet: Add Event Timer Block ID definition.
> 
> Marvin,
> 
> Can you resubmit your patch without the modification to the intel copyright?
> 
> Can you also do this for any other outstanding (not yet pushed) patches also?
> 
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin Häuser
> > Sent: Tuesday, May 15, 2018 12:35 PM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Gao, Liming
> > 
> > Subject: [edk2] [PATCH] MdePkg/Hpet: Add Event Timer Block ID
> definition.
> >
> > This patch adds the HPET Event Timer Block ID definition that can be
> > found in the IA-PC HPET Specification, section 3.2.4.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h | 18
> > +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > index 0d83cd5335de..926445233944 100644
> > --- a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > +++ b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > @@ -2,7 +2,7 @@
> >ACPI high precision event timer table definition, at www.intel.com
> >Specification name is IA-PC HPET (High Precision Event Timers)
> > Specification.
> >
> > -  Copyright (c) 2007 - 2008, Intel Corporation. All rights
> > reserved.
> > +  Copyright (c) 2007 - 2018, Intel Corporation. All rights
> > + reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of
> > the BSD License
> >which accompanies this distribution.  The full text of the license
> > may be found at @@ -22,6 +22,22 @@  //  #pragma pack(1)
> >
> > +///
> > +/// HPET Event Timer Block ID described in IA-PC HPET Specification, 3.2.4.
> > +///
> > +typedef union {
> > +  struct {
> > +UINT32 Revision   : 8;
> > +UINT32 NumberOfTimers : 5;
> > +UINT32 CounterSize: 1;
> > +UINT32 Reserved   : 1;
> > +UINT32 LegacyRoute: 1;
> > +UINT32 VendorId   : 16;
> > +  }  Bits;
> > +  UINT32 Uint32;
> > +} EFI_ACPI_HIGH_PRECISION_EVENT_TIMER_BLOCK_ID;
> > +
> > +
> >  ///
> >  /// High Precision Event Timer Table header definition.
> >  ///
> > --
> > 2.17.0.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools/Workspace: Fix ValueChain set

[Marvin Häuser]

Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain
from a dict to a set, but also changed the (former) key type from a
touple to two separate values, which was probably unintended and also
breaks build for packages involving Structured PCDs, because add()
only takes one argument.
This commit changes the values back to touples.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 8476543c5352..0262a91ed855 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
 nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
 stru_pcd.SkuOverrideValues[skuid] = 
copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not NoDefault else 
copy.deepcopy({defaultstorename: stru_pcd.DefaultValues for defaultstorename in 
DefaultStores} if DefaultStores else 
{TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
 if not NoDefault:
-stru_pcd.ValueChain.add(skuid,'')
+stru_pcd.ValueChain.add((skuid,''))
 if stru_pcd.Type in 
[self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII], 
self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
 for skuid in SkuIds:
 nextskuid = skuid
@@ -1366,7 +1366,7 @@ class DscBuildData(PlatformBuildClassObject):
 for defaultstoreid in DefaultStores:
 if defaultstoreid not in 
stru_pcd.SkuOverrideValues[skuid]:
 stru_pcd.SkuOverrideValues[skuid][defaultstoreid] 
= copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstorename])
-stru_pcd.ValueChain.add(skuid,defaultstoreid)
+stru_pcd.ValueChain.add((skuid,defaultstoreid))
 S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
 Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
 if Str_Pcd_Values:
-- 
2.17.0.windows.1

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

Re: [edk2] [PATCH] BaseTools/Workspace: Fix ValueChain set

[Marvin Häuser]

Sorry, it seems like my IDE did whitespace changes for the second change.
I will submit a V2 once the functionality has been reviewed.

> -Original Message-
> From: edk2-devel  On Behalf Of Marvin
> Häuser
> Sent: Saturday, May 19, 2018 12:43 AM
> To: edk2-devel@lists.01.org
> Cc: jaben.car...@intel.com; liming@intel.com
> Subject: [edk2] [PATCH] BaseTools/Workspace: Fix ValueChain set
> 
> Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain
> from a dict to a set, but also changed the (former) key type from a touple to
> two separate values, which was probably unintended and also breaks build
> for packages involving Structured PCDs, because add() only takes one
> argument.
> This commit changes the values back to touples.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser 
> ---
>  BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> b/BaseTools/Source/Python/Workspace/DscBuildData.py
> index 8476543c5352..0262a91ed855 100644
> --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> @@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
>  nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
>  stru_pcd.SkuOverrideValues[skuid] =
> copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not NoDefault
> else copy.deepcopy({defaultstorename: stru_pcd.DefaultValues for
> defaultstorename in DefaultStores} if DefaultStores else
> {TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
>  if not NoDefault:
> -stru_pcd.ValueChain.add(skuid,'')
> +stru_pcd.ValueChain.add((skuid,''))
>  if stru_pcd.Type in
> [self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII],
> self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
>  for skuid in SkuIds:
>  nextskuid = skuid
> @@ -1366,7 +1366,7 @@ class DscBuildData(PlatformBuildClassObject):
>  for defaultstoreid in DefaultStores:
>  if defaultstoreid not in 
> stru_pcd.SkuOverrideValues[skuid]:
>  
> stru_pcd.SkuOverrideValues[skuid][defaultstoreid] =
> copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstorena
> me])
> -stru_pcd.ValueChain.add(skuid,defaultstoreid)
> +
> + stru_pcd.ValueChain.add((skuid,defaultstoreid))
>  S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
>  Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
>  if Str_Pcd_Values:
> --
> 2.17.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools: Rename String to StringUtils.

[Marvin Häuser]

For case-insensitive file systems, edk2 String.py collides with the
Python string.py, which results in build errors. This,for example,
applies to building via the Windows Subsystem for Linux from a
DriveFS file system. This patch renames String to StringUtils to
prevent conflicts for case-insensitive file systems.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py| 2 +-
 BaseTools/Source/Python/AutoGen/BuildEngine.py| 2 +-
 BaseTools/Source/Python/AutoGen/GenC.py   | 2 +-
 BaseTools/Source/Python/AutoGen/GenMake.py| 2 +-
 BaseTools/Source/Python/AutoGen/GenPcdDb.py   | 2 +-
 BaseTools/Source/Python/AutoGen/IdfClassObject.py | 2 +-
 BaseTools/Source/Python/AutoGen/UniClassObject.py | 2 +-
 BaseTools/Source/Python/Common/Database.py| 2 +-
 BaseTools/Source/Python/Common/Parsing.py | 2 +-
 BaseTools/Source/Python/Common/{String.py => StringUtils.py}  | 0
 BaseTools/Source/Python/Common/ToolDefClassObject.py  | 2 +-
 BaseTools/Source/Python/Ecc/Configuration.py  | 2 +-
 BaseTools/Source/Python/Ecc/Ecc.py| 2 +-
 BaseTools/Source/Python/Ecc/MetaFileWorkspace/MetaFileParser.py   | 2 +-
 BaseTools/Source/Python/Eot/Eot.py| 2 +-
 BaseTools/Source/Python/Eot/InfParserLite.py  | 2 +-
 BaseTools/Source/Python/Eot/Parser.py | 4 ++--
 BaseTools/Source/Python/GenFds/AprioriSection.py  | 2 +-
 BaseTools/Source/Python/GenFds/FdfParser.py   | 4 ++--
 BaseTools/Source/Python/GenFds/FfsInfStatement.py | 2 +-
 BaseTools/Source/Python/GenFds/GenFds.py  | 2 +-
 BaseTools/Source/Python/GenFds/OptRomInfStatement.py  | 2 +-
 BaseTools/Source/Python/Makefile  | 4 ++--
 BaseTools/Source/Python/Table/TableDataModel.py   | 2 +-
 BaseTools/Source/Python/Table/TableDec.py | 2 +-
 BaseTools/Source/Python/Table/TableDsc.py | 2 +-
 BaseTools/Source/Python/Table/TableEotReport.py   | 2 +-
 BaseTools/Source/Python/Table/TableFdf.py | 2 +-
 BaseTools/Source/Python/Table/TableFile.py| 2 +-
 BaseTools/Source/Python/Table/TableFunction.py| 2 +-
 BaseTools/Source/Python/Table/TableIdentifier.py  | 2 +-
 BaseTools/Source/Python/Table/TableInf.py | 2 +-
 BaseTools/Source/Python/Table/TablePcd.py | 2 +-
 BaseTools/Source/Python/Table/TableQuery.py   | 2 +-
 BaseTools/Source/Python/Table/TableReport.py  | 2 +-
 BaseTools/Source/Python/UPT/Library/{String.py => StringUtils.py} | 0
 BaseTools/Source/Python/Workspace/DecBuildData.py | 2 +-
 BaseTools/Source/Python/Workspace/DscBuildData.py | 2 +-
 BaseTools/Source/Python/Workspace/InfBuildData.py | 2 +-
 BaseTools/Source/Python/Workspace/MetaFileParser.py   | 2 +-
 BaseTools/Source/Python/Workspace/WorkspaceDatabase.py| 2 +-
 BaseTools/Source/Python/build/BuildReport.py  | 2 +-
 42 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 1e6511cdb5d2..4304967aee42 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -33,7 +33,7 @@ from Common.LongFilePathSupport import CopyLongFilePath
 from Common.BuildToolError import *
 from Common.DataType import *
 from Common.Misc import *
-from Common.String import *
+from Common.StringUtils import *
 import Common.GlobalData as GlobalData
 from GenFds.FdfParser import *
 from CommonDataClass.CommonClass import SkuInfoClass
diff --git a/BaseTools/Source/Python/AutoGen/BuildEngine.py 
b/BaseTools/Source/Python/AutoGen/BuildEngine.py
index dd6301b01fce..ad1919442e6e 100644
--- a/BaseTools/Source/Python/AutoGen/BuildEngine.py
+++ b/BaseTools/Source/Python/AutoGen/BuildEngine.py
@@ -23,7 +23,7 @@ from Common.LongFilePathSupport import OpenLongFilePath as 
open
 from Common.GlobalData import *
 from Common.BuildToolError import *
 from Common.Misc import tdict, PathClass
-from Common.String import NormPath
+from Common.StringUtils import NormPath
 from Common.DataType import *
 
 import Common.EdkLogger as EdkLogger
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 40a343ca1057..1be27d2b89e0 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -

[edk2] [PATCH v2] BaseTools/Workspace: Fix ValueChain set

[Marvin Häuser]

Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain
from a dict to a set, but also changed the (former) key type from a
touple to two separate values, which was probably unintended and also
breaks build for packages involving Structured PCDs, because add()
only takes one argument.
This commit changes the values back to touples.

V2:
  - Removed a whitespace change.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 8476543c5352..0262a91ed855 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
 nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
 stru_pcd.SkuOverrideValues[skuid] = 
copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not NoDefault else 
copy.deepcopy({defaultstorename: stru_pcd.DefaultValues for defaultstorename in 
DefaultStores} if DefaultStores else 
{TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
 if not NoDefault:
-stru_pcd.ValueChain.add(skuid,'')
+stru_pcd.ValueChain.add((skuid,''))
 if stru_pcd.Type in 
[self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII], 
self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
 for skuid in SkuIds:
 nextskuid = skuid
@@ -1366,7 +1366,7 @@ class DscBuildData(PlatformBuildClassObject):
 for defaultstoreid in DefaultStores:
 if defaultstoreid not in 
stru_pcd.SkuOverrideValues[skuid]:
 stru_pcd.SkuOverrideValues[skuid][defaultstoreid] 
= copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstorename])
-stru_pcd.ValueChain.add(skuid,defaultstoreid)
+stru_pcd.ValueChain.add((skuid,defaultstoreid))
 S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
 Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
 if Str_Pcd_Values:
-- 
2.17.0.windows.1

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

Re: [edk2] [PATCH v2] BaseTools/Workspace: Fix ValueChain set

[Marvin Häuser]

This is odd. I generated another patch and checked for whitespace and CRLF/LF 
changes and found everything to be fine.
Now V2 has the exact same whitespace change as V1. Also, if I see it right, it 
failed to CC Yonghong even though the CMD clearly shows the cc.

Is there maybe some git expert around who has an idea what the issue could be?

Thanks,
Marvin

> -Original Message-
> From: edk2-devel  On Behalf Of Marvin
> Häuser
> Sent: Tuesday, May 22, 2018 1:48 PM
> To: edk2-devel@lists.01.org
> Cc: liming@intel.com
> Subject: [edk2] [PATCH v2] BaseTools/Workspace: Fix ValueChain set
> 
> Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain
> from a dict to a set, but also changed the (former) key type from a touple to
> two separate values, which was probably unintended and also breaks build
> for packages involving Structured PCDs, because add() only takes one
> argument.
> This commit changes the values back to touples.
> 
> V2:
>   - Removed a whitespace change.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser 
> ---
>  BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> b/BaseTools/Source/Python/Workspace/DscBuildData.py
> index 8476543c5352..0262a91ed855 100644
> --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> @@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
>  nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
>  stru_pcd.SkuOverrideValues[skuid] =
> copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not NoDefault
> else copy.deepcopy({defaultstorename: stru_pcd.DefaultValues for
> defaultstorename in DefaultStores} if DefaultStores else
> {TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
>  if not NoDefault:
> -stru_pcd.ValueChain.add(skuid,'')
> +stru_pcd.ValueChain.add((skuid,''))
>  if stru_pcd.Type in
> [self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII],
> self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
>  for skuid in SkuIds:
>  nextskuid = skuid
> @@ -1366,7 +1366,7 @@ class DscBuildData(PlatformBuildClassObject):
>  for defaultstoreid in DefaultStores:
>  if defaultstoreid not in 
> stru_pcd.SkuOverrideValues[skuid]:
>  
> stru_pcd.SkuOverrideValues[skuid][defaultstoreid] =
> copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstorena
> me])
> -stru_pcd.ValueChain.add(skuid,defaultstoreid)
> +
> + stru_pcd.ValueChain.add((skuid,defaultstoreid))
>  S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
>  Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
>  if Str_Pcd_Values:
> --
> 2.17.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] BaseTools/Workspace: Fix ValueChain set

[Marvin Häuser]

Thanks Liming!
Maybe this is an issue with my e-mail client or server, I just heard Exchange 
sometimes messes up.
If there really is no such change as I'm observing here, V1 should be fine too.

Regards,
Marvin.

> -Original Message-
> From: Gao, Liming 
> Sent: Tuesday, May 22, 2018 2:49 PM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Zhu, Yonghong 
> Subject: RE: [PATCH v2] BaseTools/Workspace: Fix ValueChain set
> 
> Marvin:
>   I don't see the whitespace in this patch. I also run
> BaseTools\Scripts\PatchCheck.py. There is no issue found.
> 
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Tuesday, May 22, 2018 7:52 PM
> > To: edk2-devel@lists.01.org
> > Cc: Gao, Liming ; Zhu, Yonghong
> > 
> > Subject: RE: [PATCH v2] BaseTools/Workspace: Fix ValueChain set
> >
> > This is odd. I generated another patch and checked for whitespace and
> CRLF/LF changes and found everything to be fine.
> > Now V2 has the exact same whitespace change as V1. Also, if I see it
> > right, it failed to CC Yonghong even though the CMD clearly shows the cc.
> >
> > Is there maybe some git expert around who has an idea what the issue
> could be?
> >
> > Thanks,
> > Marvin
> >
> > > -Original Message-
> > > From: edk2-devel  On Behalf Of
> > > Marvin Häuser
> > > Sent: Tuesday, May 22, 2018 1:48 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: liming@intel.com
> > > Subject: [edk2] [PATCH v2] BaseTools/Workspace: Fix ValueChain set
> > >
> > > Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed
> ValueChain
> > > from a dict to a set, but also changed the (former) key type from a
> > > touple to two separate values, which was probably unintended and
> > > also breaks build for packages involving Structured PCDs, because
> > > add() only takes one argument.
> > > This commit changes the values back to touples.
> > >
> > > V2:
> > >   - Removed a whitespace change.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Marvin Haeuser 
> > > ---
> > >  BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> > > b/BaseTools/Source/Python/Workspace/DscBuildData.py
> > > index 8476543c5352..0262a91ed855 100644
> > > --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> > > +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> > > @@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
> > >  nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
> > >  stru_pcd.SkuOverrideValues[skuid] =
> > > copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not
> > > NoDefault else copy.deepcopy({defaultstorename:
> > > stru_pcd.DefaultValues for defaultstorename in DefaultStores} if
> > > DefaultStores else
> > > {TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
> > >  if not NoDefault:
> > > -stru_pcd.ValueChain.add(skuid,'')
> > > +stru_pcd.ValueChain.add((skuid,''))
> > >  if stru_pcd.Type in
> > > [self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII],
> > > self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
> > >  for skuid in SkuIds:
> > >  nextskuid = skuid @@ -1366,7 +1366,7 @@ class
> > > DscBuildData(PlatformBuildClassObject):
> > >  for defaultstoreid in DefaultStores:
> > >  if defaultstoreid not in 
> > > stru_pcd.SkuOverrideValues[skuid]:
> > >
> > > stru_pcd.SkuOverrideValues[skuid][defaultstoreid] =
> > >
> copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstoren
> > > a
> > > me])
> > > -stru_pcd.ValueChain.add(skuid,defaultstoreid)
> > > +
> > > + stru_pcd.ValueChain.add((skuid,defaultstoreid))
> > >  S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
> > >  Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
> > >  if Str_Pcd_Values:
> > > --
> > > 2.17.0.windows.1
> > >
> > > ___
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] EmulatorPkg/SmbiosLib: Declare the correct library class.

[Marvin Häuser]

> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, May 24, 2018 10:51 PM
> To: Jordan Justen ; edk2-devel@lists.01.org;
> Marvin Häuser 
> Cc: af...@apple.com
> Subject: Re: [edk2] [PATCH v2] EmulatorPkg/SmbiosLib: Declare the correct
> library class.
> 
> On 05/24/18 22:36, Jordan Justen wrote:
> > Reviewed-by: Jordan Justen 
> >
> > Pushed as 7dc7c7435e.
> >
> > On 2018-05-17 05:43:30, Marvin Häuser wrote:
> >> Currently, SmbiosLib declares the PcdLib library class. Update the
> >> declaration to declare SmbiosLib.
> >>
> >> V2:
> >>   - Do not change the copyright date as requested.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Marvin Haeuser 
> >> ---
> >>  EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
> >> b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
> >> index adcd7ef08e20..36d5c350f51a 100644
> >> --- a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
> >> +++ b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
> >> @@ -20,7 +20,7 @@ [Defines]
> >>FILE_GUID  = 881863A2-09FD-3E44-8D62-7AE038D03747
> >>MODULE_TYPE= DXE_DRIVER
> >>VERSION_STRING = 1.0
> >> -  LIBRARY_CLASS  = PcdLib|DXE_CORE DXE_DRIVER
> DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE
> UEFI_APPLICATION UEFI_DRIVER
> >> +  LIBRARY_CLASS  = SmbiosLib|DXE_CORE DXE_DRIVER
> DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE
> UEFI_APPLICATION UEFI_DRIVER
> >>
> >>CONSTRUCTOR= SmbiosLibConstructor
> 
> (Just because I pondered the question a few days ago, independently, I'll
> voice it here:)
> 
> Should BaseTools catch this? "EmulatorPkg/EmulatorPkg.dsc" contains the
> following library resolution:
> 
>   SmbiosLib|EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
> 
> I think it should be possible to flag that the class of the lib instance 
> doesn't
> match the lib class that the platform DSC is resolving.

I think it definitely should, there is no case (known to me) where those two 
values diverging would be a supported or making any sense.

> 
> (Or is Marvin's patch the result of such an error message already?)

No, I was just checking the library for reference and noticed the mistake. I 
did not actually build EmulatorPkg though.

Regards,
Marvin

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

Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

[Marvin Häuser]

Hey Laszlo and thanks once again for your detailed response.
Comments are inline.

Regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek 
> Sent: Friday, May 25, 2018 1:41 PM
> To: Marvin Häuser 
> Cc: edk2-devel@lists.01.org; eric.d...@intel.com
> Subject: Re: CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.
> 
> On 05/25/18 12:54, Marvin H?user wrote:
> > Good day,
> >
> > While I was inspecting CpuS3DataDxe and the modules depending on its
> > PCD PcdCpuS3DataAddress,
> 
> (Side remark: see e.g. the commit message on 92b87f1c8c0b, "OvmfPkg:
> build CpuS3DataDxe for -D SMM_REQUIRE", 2015-11-30.)
> 
> > I noticed that DxeRegisterCpuFeaturesLib seemingly has an asserted
> > dependency on the PCD being ready when it its executed. I did neither
> > see a Depex entry, nor an event callback ensuring CpuS3DataDxe has
> > been loaded, neither exposed by CpuS3DataDxe, nor consumed by this
> > library.
> >
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/Regis
> > terCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c#L211
> 
> "DxeRegisterCpuFeaturesLib.inf" has a depex on
> "gEdkiiCpuFeaturesSetDoneGuid".
> 
> No module in the open source edk2 tree produces this protocol GUID, thus I
> think this library instance is unusable without other, out-of-tree, modules. I
> assume that one of those modules satisfies the dependency somehow.
>

While this of course can be used to control the dependency flow, this GUID is 
documented as follows:
"CPU Features Set Done PPI/Protocol should be installed after CPU features 
configuration are set."
If it is really supposed to ensure the ACPI CPU Data PCD availability too, I 
think it should be documented.
However I do not think that would be a great idea in the first place because 
other modules might depend on it as well.
I get your point is just that an out-of-tree module is needed, however if it 
exists and whatever it does, I don't think it should rely on this GUID for this 
purpose.

> Note that CpuS3DataDxe is a platform driver [1]; it is possible that the
> platform that includes DxeRegisterCpuFeaturesLib in a driver *also* includes
> such a CpuS3DataDxe variant that populates the PCD and then installs
> gEdkiiCpuFeaturesSetDoneGuid.

That was one of the reasons I asked whether a dedicated signal protocol dummy 
would be a good idea.
I don't think it is likely that this is the case, but it is not impossible and 
would need to be discussed internally, if it is the case, I guess.

> 
> [1] I suggest reviewing the message of commit bfec5efa56ca
> ("UefiCpuPkg/CpuS3DataDxe: Add module to initialize ACPI_CPU_DATA for
> S3", 2015-11-25).
> 
> In fact, the series that added "DxeRegisterCpuFeaturesLib.inf" (with the
> depex mentioned above) *also* modified CpuS3DataDxe: see [2] and [3].
> 
> [2] 8b371e93f206 ("UefiCpuPkg/CpuS3DataDxe: Consume the existing
> PcdCpuS3DataAddress", 2017-03-22)

This commit indicates to me that there is no proper dependency resolve, to be 
honest.
If the "main" PCD exposer has code to handle already present data, it means 
that every consumer not executing dependent code very late,
as you have shown PiSmmCpuDxeSmm does, has to have an allocation routine or 
some kind of implicit dependency.

> 
> [3] "[edk2] [PATCH 00/11] Add CPU features driver"
> https://bugzilla.tianocore.org/show_bug.cgi?id=421
> http://mid.mail-archive.com/20170309083553.6016-1-jeff.fan@intel.com
> 
> This suggests that there is an out-of-tree module that populates
> PcdCpuS3DataAddress before *both* CpuS3DataDxe and
> DxeRegisterCpuFeaturesLib access the PCD. For achieving this kind of
> ordering, it would be enough for a driver to first populate the PCD, and then
> install "gEfiMpServiceProtocolGuid", as both
> "DxeRegisterCpuFeaturesLib.inf" and "CpuS3DataDxe.inf" depend on that.

gEfiMpServiceProtocolGuid is populated by CpuDxe, so I hope this is not 
actually the case.
And yet again it would be only a dangerous implicit dependency.

> 
> > Is there anything I'm missing that ensures the execution of
> > CpuS3DataDxe prior to executing the dependent code? If not, should
> > there be a dummy protocol exposed? PiSmmCpuDxeSmm also retrieves
> this
> > PCD, however safely quits when it has not been set. However, this
> > could cause unexpected behavior when the PCD is set after this code
> > has been executed. I did not notice any dependency satisfaction
> > actions here either.
> 
> The ordering between CpuS3DataDxe and PiSmmCpuDxeSmm is safe; it's
> orchestrated by Platform BDS. See commit 92b87f1c8c0b above.

I only noticed PiSmmCpuDxeSmm whil

Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

[Marvin Häuser]

Hey Jeff,

Thanks for looking into it!

Maybe both should be implemented (PEI and additional DXE Depex) and leave it to 
the platform maintainer, as with CpuFeaturesPei vs CpuFeaturesDxe?
If the platform PEI happens to not consume PCD, PcdPei would need to be 
introduced just to support “CpuS3DataPei”.
On the other hand, when e.g. CpuFeaturesPei is used anyway, it makes good sense 
to choose CpuS3DataPei over CpuS3DataDxe and remove the PCD allocation code 
from CpuFeaturesPei.

Regards,
Marvin.

From: Fan Jeff 
Sent: Monday, May 28, 2018 11:51 AM
To: Laszlo Ersek ; Marvin Häuser 
Cc: edk2-devel@lists.01.org; eric.d...@intel.com
Subject: 答复: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.


Hi,



The current implementation assumes CpuS3DataDxe was dispatched before 
CpuFeaturesDxe. I do not remember clearly why I made this assumption before. 
(It maybe only due to CpuS3DataDxe was just dispatched firstly on all my 
validation platforms.),

I agree this is one bug.  Simply, we could implement one AllocateAcpiCpuData() 
in DXE instance as PEI instance.



Thanks!

Jeff




From: edk2-devel 
mailto:edk2-devel-boun...@lists.01.org>> on 
behalf of Laszlo Ersek mailto:ler...@redhat.com>>
Sent: Friday, May 25, 2018 7:40:32 PM
To: Marvin Häuser
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; 
eric.d...@intel.com<mailto:eric.d...@intel.com>
Subject: Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

On 05/25/18 12:54, Marvin H?user wrote:
> Good day,
>
> While I was inspecting CpuS3DataDxe and the modules depending on its
> PCD PcdCpuS3DataAddress,

(Side remark: see e.g. the commit message on 92b87f1c8c0b, "OvmfPkg:
build CpuS3DataDxe for -D SMM_REQUIRE", 2015-11-30.)

> I noticed that DxeRegisterCpuFeaturesLib seemingly has an asserted
> dependency on the PCD being ready when it its executed. I did neither
> see a Depex entry, nor an event callback ensuring CpuS3DataDxe has
> been loaded, neither exposed by CpuS3DataDxe, nor consumed by this
> library.
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c#L211

"DxeRegisterCpuFeaturesLib.inf" has a depex on
"gEdkiiCpuFeaturesSetDoneGuid".

No module in the open source edk2 tree produces this protocol GUID, thus
I think this library instance is unusable without other, out-of-tree,
modules. I assume that one of those modules satisfies the dependency
somehow.

Note that CpuS3DataDxe is a platform driver [1]; it is possible that the
platform that includes DxeRegisterCpuFeaturesLib in a driver *also*
includes such a CpuS3DataDxe variant that populates the PCD and then
installs gEdkiiCpuFeaturesSetDoneGuid.

[1] I suggest reviewing the message of commit bfec5efa56ca
("UefiCpuPkg/CpuS3DataDxe: Add module to initialize ACPI_CPU_DATA for
S3", 2015-11-25).

In fact, the series that added "DxeRegisterCpuFeaturesLib.inf" (with the
depex mentioned above) *also* modified CpuS3DataDxe: see [2] and [3].

[2] 8b371e93f206 ("UefiCpuPkg/CpuS3DataDxe: Consume the existing
PcdCpuS3DataAddress", 2017-03-22)

[3] "[edk2] [PATCH 00/11] Add CPU features driver"
https://bugzilla.tianocore.org/show_bug.cgi?id=421
http://mid.mail-archive.com/20170309083553.6016-1-jeff.fan@intel.com

This suggests that there is an out-of-tree module that populates
PcdCpuS3DataAddress before *both* CpuS3DataDxe and
DxeRegisterCpuFeaturesLib access the PCD. For achieving this kind of
ordering, it would be enough for a driver to first populate the PCD, and
then install "gEfiMpServiceProtocolGuid", as both
"DxeRegisterCpuFeaturesLib.inf" and "CpuS3DataDxe.inf" depend on that.

> Is there anything I'm missing that ensures the execution of
> CpuS3DataDxe prior to executing the dependent code? If not, should
> there be a dummy protocol exposed? PiSmmCpuDxeSmm also retrieves this
> PCD, however safely quits when it has not been set. However, this
> could cause unexpected behavior when the PCD is set after this code
> has been executed. I did not notice any dependency satisfaction
> actions here either.

The ordering between CpuS3DataDxe and PiSmmCpuDxeSmm is safe; it's
orchestrated by Platform BDS. See commit 92b87f1c8c0b above.

> Furthermore, not directly related to this dependency issue, the DXE
> code obviously does not implement AllocateAcpiCpuData() entirely.

More precisely, the DXE code expects AllocateAcpiCpuData() never to be
called; i.e., when the common "RegisterCpuFeaturesLib.c" source file is
executed in DXE, the expectation is that it never reaches the call to
AllocateAcpiCpuData().

> Hence, the if-branch following its call, will either add another layer
> of firing ASSERTs, or it will plainly do nothing. Maybe it could be
> moved into the current 

Re: [edk2] smm lock query

[Marvin Häuser]

Hello Andrew and Laszlo,

Thanks for your comments!
Of course I'm with you that it is the platform that signals the SmmReadyToLock 
event and therefor is aware.
However, they might rely on the protocol's description that the resources are 
about(!) to be locked and code accordingly, not considering the event 
characteristic of the handler in PiSmmIpl.
The code might be written by different people, not especially reviewed against 
edk2's actions, or additional code might be supplied by third parties that do 
not have tree code access (which, by integration, would be "platform binaries" 
by the definition applying here).

Therefor I would still ask everyone to consider figuring out a solution to this 
discrepancy from the specification, such as the internal "dummy event" I 
proposed.

Thanks,
Marvin.

> -Original Message-
> From: Laszlo Ersek 
> Sent: Monday, May 28, 2018 12:58 PM
> To: Andrew Fish ; Marvin H?user
> 
> Cc: edk2-devel@lists.01.org; Abhishek Singh ;
> ruiyu...@intel.com; eric.d...@intel.com; star.z...@intel.com
> Subject: Re: [edk2] smm lock query
> 
> On 05/27/18 22:44, Andrew Fish wrote:
> >
> >
> >> On May 27, 2018, at 9:47 AM, Marvin H?user
>  wrote:
> >>
> >> Good day Abhishek,
> >>
> >> I CC'd the MdeModulePkg maintainers, Ruiyu for the Platform BDS aspect
> (exposes the ReadyToLock protocol) and Laszlo for his high-quality answers.
> >>
> >> Strictly speaking you are, right, because of the description for the MM
> protocol:
> >> "Indicates that MM resources and services that should not be used by the
> third party code are about[Marvin: (!)] to be locked."
> >> Practically however, I don't see any issue with the current
> implementation. Code inside MMRAM is not affected directly by the lock, it is
> just notified.
> >> However, either the code or the specification should be slightly updated
> to be in sync. A code update might require review of the caller assumptions,
> just to be sure.
> >>
> >> I have a different concern though and hope I'm actually overlooking
> something.
> >> If I understand the code correctly, it is the Platform BDS that exposes the
> (S)MmReadyToLock protocol. PiSmmIpl seems to consume that event and
> lock SMM resources based on the event.
> >> Because of latter being an event however, I don't think it is, or can be,
> guaranteed to be the last event group member executing.
> >> When it is not the last, the "about to be locked" part is not true for any
> subsequent callbacks, that could actually be a risky break of the 
> specification
> - if it is.
> >> If it is a break of the specification, I can only think of letting 
> >> Platform BDS
> expose an "internal" event group, which is only caught by PiSmmIpl, which
> then drives the actual SmmReadyToLock flow.
> >> This would require updates to all platform trees and hence I would
> propose a temporary backwards-compatibility.
> >>
> >> Any comments? Did I overlook something (I hope)?
> >>
> >
> > Mavvin,
> >
> > You are correct there is no guarantee of order in events. Thanks for cc'ing
> the right folks, as I don't remember all the low level details...
> >
> > In general the idea behind the MM code is it only comes from the platform,
> then by definition that code should be aware when the platform was going
> to lock MM. In a practical sense any MM module that had a depex evaluate
> to true would have dispatched in DXE prior to BDS being launched. In general
> BDS is the code that enumerates PCI and connects devices, thus there is no
> chance for 3rd party software to run before that point in the boot. So in an
> abstract sense that lock represents the end of DXE dispatch.
> 
> This is my understanding as well. gEfiDxeSmmReadyToLockProtocolGuid is
> installed by Plaform BDS before any non-platform binaries get a chance to
> run. In terms of the current PlatformBootManagerLib interfaces, that means
> the protocol should be installed from
> PlatformBootManagerBeforeConsole() (as noted on the API declaration
> itself).
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

[Marvin Häuser]

Hey Jeff,

Of course I meant to introduce a “gEdkiiCpuS3DataAvailablePpiGuid” or similar 
to create a Depex on.

Thanks,
Marvin.

From: Fan Jeff 
Sent: Monday, May 28, 2018 4:19 PM
To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
Cc: ler...@redhat.com; eric.d...@intel.com
Subject: Re:RE: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

Marvin,

Thanks your reply. i have thought my mail hasn't sent out just now.

Adding CpuS3DataPei depends on wether we need to suppoert S3 without DXE, i 
think.

Even we add CpuS3DataPei, we cannot assume the dispatch order between 
CpuFeaturesPei and CpuS3DataPei from core code view. So,we cannot remove those 
code to produce PCD if it does not exist.

Thanks!
Jeff






发自我的小米手机
在 Marvin Häuser 
mailto:marvin.haeu...@outlook.com>>，2018年5月28日 
下午9:55写道：
Hey Jeff,

Thanks for looking into it!

Maybe both should be implemented (PEI and additional DXE Depex) and leave it to 
the platform maintainer, as with CpuFeaturesPei vs CpuFeaturesDxe?
If the platform PEI happens to not consume PCD, PcdPei would need to be 
introduced just to support “CpuS3DataPei”.
On the other hand, when e.g. CpuFeaturesPei is used anyway, it makes good sense 
to choose CpuS3DataPei over CpuS3DataDxe and remove the PCD allocation code 
from CpuFeaturesPei.

Regards,
Marvin.

From: Fan Jeff mailto:vanjeff_...@hotmail.com>>
Sent: Monday, May 28, 2018 11:51 AM
To: Laszlo Ersek mailto:ler...@redhat.com>>; Marvin Häuser 
mailto:marvin.haeu...@outlook.com>>
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; 
eric.d...@intel.com<mailto:eric.d...@intel.com>
Subject: 答复: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.


Hi,



The current implementation assumes CpuS3DataDxe was dispatched before 
CpuFeaturesDxe. I do not remember clearly why I made this assumption before. 
(It maybe only due to CpuS3DataDxe was just dispatched firstly on all my 
validation platforms.),

I agree this is one bug.  Simply, we could implement one AllocateAcpiCpuData() 
in DXE instance as PEI instance.



Thanks!

Jeff




From: edk2-devel 
mailto:edk2-devel-boun...@lists.01.org>> on 
behalf of Laszlo Ersek mailto:ler...@redhat.com>>
Sent: Friday, May 25, 2018 7:40:32 PM
To: Marvin Häuser
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; 
eric.d...@intel.com<mailto:eric.d...@intel.com>
Subject: Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

On 05/25/18 12:54, Marvin H?user wrote:
> Good day,
>
> While I was inspecting CpuS3DataDxe and the modules depending on its
> PCD PcdCpuS3DataAddress,

(Side remark: see e.g. the commit message on 92b87f1c8c0b, "OvmfPkg:
build CpuS3DataDxe for -D SMM_REQUIRE", 2015-11-30.)

> I noticed that DxeRegisterCpuFeaturesLib seemingly has an asserted
> dependency on the PCD being ready when it its executed. I did neither
> see a Depex entry, nor an event callback ensuring CpuS3DataDxe has
> been loaded, neither exposed by CpuS3DataDxe, nor consumed by this
> library.
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c#L211

"DxeRegisterCpuFeaturesLib.inf" has a depex on
"gEdkiiCpuFeaturesSetDoneGuid".

No module in the open source edk2 tree produces this protocol GUID, thus
I think this library instance is unusable without other, out-of-tree,
modules. I assume that one of those modules satisfies the dependency
somehow.

Note that CpuS3DataDxe is a platform driver [1]; it is possible that the
platform that includes DxeRegisterCpuFeaturesLib in a driver *also*
includes such a CpuS3DataDxe variant that populates the PCD and then
installs gEdkiiCpuFeaturesSetDoneGuid.

[1] I suggest reviewing the message of commit bfec5efa56ca
("UefiCpuPkg/CpuS3DataDxe: Add module to initialize ACPI_CPU_DATA for
S3", 2015-11-25).

In fact, the series that added "DxeRegisterCpuFeaturesLib.inf" (with the
depex mentioned above) *also* modified CpuS3DataDxe: see [2] and [3].

[2] 8b371e93f206 ("UefiCpuPkg/CpuS3DataDxe: Consume the existing
PcdCpuS3DataAddress", 2017-03-22)

[3] "[edk2] [PATCH 00/11] Add CPU features driver"
https://bugzilla.tianocore.org/show_bug.cgi?id=421
http://mid.mail-archive.com/20170309083553.6016-1-jeff.fan@intel.com

This suggests that there is an out-of-tree module that populates
PcdCpuS3DataAddress before *both* CpuS3DataDxe and
DxeRegisterCpuFeaturesLib access the PCD. For achieving this kind of
ordering, it would be enough for a driver to first populate the PCD, and
then install "gEfiMpServiceProtocolGuid", as both
"DxeRegisterCpuFeaturesLib.inf" and "CpuS3DataDxe.inf" depend on that.

> Is there anything I'm missing that ensures the execution of
> CpuS3DataDxe prior to executing the dependent code? If not, should
>

Re: [edk2] Regarding UefiDriverEntryPoint unload handler

[Marvin Häuser]

Hey Mike,

"if UnloadImage() is called and the Unload field is NULL, it returns an 
EFI_UNSUPPORTED."
This is the part I missed, my example is impossible in this case.

Thanks,
Marvin.

-Ursprüngliche Nachricht-
Von: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Gesendet: Donnerstag, 15. Juni 2017 04:51
An: Marvin H?user ; edk2-devel@lists.01.org; 
Kinney, Michael D 
Betreff: RE: Regarding UefiDriverEntryPoint unload handler

Hi Marvin,

Yes.  This is intentional.  If MODULE_UNLOAD is not provided, then the module 
can never be unloaded.  
The LoadImage() services initializes the Unload field to NULL, and if 
UnloadImage() is called and the Unload field is NULL, it returns an 
EFI_UNSUPPORTED.

I do not think the case you describer is possible.  If 
ProcessModuleUnloadList() returns an error, then 
ProcessLibraryDestructorList()is not called.

Since the module is not unloaded, it is still in allocated memory.  How would 
the protocol point to a freed buffer?

Mike

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marvin 
H?user
Sent: Wednesday, June 14, 2017 6:41 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Regarding UefiDriverEntryPoint unload handler

Dear developers,

While performing some research tasks, I noticed that when 
UefiDriverEntryPoint's _gDriverUnloadImageCount is 0 (only MODULE_UNLOAD 
entries are count, DESTRUCTOR as they are used with libraries are not, as far 
as I can see), EFI_LOADED_IMAGE_PROTOCOL.Unload is not set, even if libraries 
with destructors are included by the built module.
Is this intentional, so, is a module without a MODULE_UNLOAD property in its 
build file considered a module that does not support being unloaded? If so, why 
is EFI_LOADED_IMAGE_PROTOCOL.Unload not set to a dummy that returns an EFI 
error code?

For example, DxeDebugPrintErrorLevelLib installs a protocol interface in its 
CONSTRUCTOR function. When this library is included in a module without a 
MODULE_UNLOAD property and that module is unloaded, the 
DxeDebugPrintErrorLevelLib DESTRUCTOR function, which uninstalls the interface, 
is never called and hence the interface remains in the protocol database, 
despite it pointing to a memory location that is now free. If it is called, the 
behavior is obviously undefined.

Did I understand something incorrectly, are these modules not supposed to be 
unloadable or is this a bug?

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

Re: [edk2] writing EDK compatible application.

[Marvin Häuser]

Well, if EFI Shell 1.0 works, why not use it?
Mac EFI exposes the ConsoleControl protocol, which lets you switch between text 
and graphics mode.
That might be the reason your text outputs don't show, because graphics is the 
default mode on Mac EFI,
though I could never test this myself as I lack the hardware.

Regards,
Marvin.

> -Original Message-
> From: Amit kumar [mailto:akami...@hotmail.com]
> Sent: Tuesday, July 4, 2017 7:46 PM
> To: Marvin H?user 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] writing EDK compatible application.
> 
> Hi,
> Yes intact it’s MacBook, but is there another way to do it without UEFI shell.
> In edk2/shellpkgbin are 2.2+, even shell fails to execute on Mac.
> Although efi shell 1.0 works. Is there a to do it without shell ?
> Thanks
> Amit
> > On Jul 4, 2017, at 11:05 PM, Marvin H?user
>  wrote:
> >
> > Hey,
> >
> > The entry point declarations and the calling conventions have not changed
> since EFI 1.10, though X64 was not a supported platform for 1.10 if I
> remember correctly.
> > To be honest, I never saw an x64 EFI 1.10 implementation other than
> Apple's, though even if it still signals that version, it's actually more 
> UEFI by
> now.
> > I don't own a Mac, so if it's the platform you tested your app on, I can't 
> > tell
> you why it didn't work, but I would suggest you to run the app from an EFI
> Shell.
> >
> > Regards,
> > Marvin.
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Amit kumar
> >> Sent: Tuesday, July 4, 2017 7:21 PM
> >> To: edk2-devel@lists.01.org
> >> Subject: [edk2] writing EDK compatible application.
> >>
> >>
> >> HI,
> >>
> >> I have written a code (say helloworld program ) using edk2 framework,
> >> named the output efi file as BOOTx64.efi and placed it on a removable
> >> media in EFI/BOOT/ directory so that the application is listed in one time
> boot menu.
> >> When selected from boot menu it prints "Hello World".
> >> Which works as expected when tested on UEFI 2.3 and above platforms.
> >> But the same code fails to execute on EFI 1.10 platforms. Which i
> >> suppose is the problem with application entry point.
> >> Can somebody suggest me a way so that the application entry function
> >> can be compatible to both the platform. Even when written according
> >> to UEFI 2.5+ Spec ?
> >>
> >> Thanks
> >> Amit
> >> ___
> >> 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] QuarkSocPkg/QNCSmmDispatcher: Fix use after free issue #2

[Marvin Häuser]

As part of commit 5f82e02, ActiveRecordInDb was introduced as a copy
of RecordInDb as latter may be freed by the callback function. This
commit replaces an access of RecordInDb after the callback function
has been executed with an access to ActiveRecordInDb.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 QuarkSocPkg/QuarkNorthCluster/Smm/DxeSmm/QncSmmDispatcher/QNCSmmCore.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/QuarkSocPkg/QuarkNorthCluster/Smm/DxeSmm/QncSmmDispatcher/QNCSmmCore.c 
b/QuarkSocPkg/QuarkNorthCluster/Smm/DxeSmm/QncSmmDispatcher/QNCSmmCore.c
index c2f75f86647a..29ad5f493466 100644
--- a/QuarkSocPkg/QuarkNorthCluster/Smm/DxeSmm/QncSmmDispatcher/QNCSmmCore.c
+++ b/QuarkSocPkg/QuarkNorthCluster/Smm/DxeSmm/QncSmmDispatcher/QNCSmmCore.c
@@ -758,7 +758,7 @@ QNCSmmCoreDispatcher (
 }
   }
 
-  if (RecordInDb->ClearSource == NULL) {
+  if (ActiveRecordInDb.ClearSource == NULL) {
 //
 // Clear the SMI associated w/ the source using the default 
function
 //
-- 
2.12.2.windows.2

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

[edk2] [PATCH] UefiCpuPkg/CpuCommonFeaturesLib: Fix the documentation of PpinSupport().

[Marvin Häuser]

The documentation of PpinSupport() refers to 'Enhanced Intel
SpeedStep'. This patch fixes these referneces.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c  | 4 ++--
 UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c
index 438578a83230..58e303448507 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c
@@ -26,8 +26,8 @@
CPU_FEATURE_GET_CONFIG_DATA was not provided in
RegisterCpuFeature().
 
-  @retval TRUE Enhanced Intel SpeedStep feature is supported.
-  @retval FALSEEnhanced Intel SpeedStep feature is not supported.
+  @retval TRUE Protected Processor Inventory Number feature is supported.
+  @retval FALSEProtected Processor Inventory Number feature is not 
supported.
 
   @note This service could be called by BSP/APs.
 **/
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
index c03e5ab0183f..c5bc62b20728 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
@@ -866,8 +866,8 @@ FeatureControlGetConfigData (
CPU_FEATURE_GET_CONFIG_DATA was not provided in
RegisterCpuFeature().
 
-  @retval TRUE Enhanced Intel SpeedStep feature is supported.
-  @retval FALSEEnhanced Intel SpeedStep feature is not supported.
+  @retval TRUE Protected Processor Inventory Number feature is supported.
+  @retval FALSEProtected Processor Inventory Number feature is not 
supported.
 
   @note This service could be called by BSP/APs.
 **/
-- 
2.12.2.windows.2

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

[edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Cast the return value of GetPageTableBase().

[Marvin Häuser]

The value returned by GetPageTableBase() is of type UINT64, which is
implicitely casted to UINTN by the return statement. To purge the
'possible loss of data' warning on 32-bit platforms, with this patch,
the value is casted to UINTN before returning.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
index a535389c26ce..009d8eb01347 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2016, Intel Corporation. All rights reserved.
+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
@@ -39,7 +39,7 @@ GetPageTableBase (
   VOID
   )
 {
-  return (AsmReadCr3 () & PAGING_4K_ADDRESS_MASK_64);
+  return (UINTN)(AsmReadCr3 () & PAGING_4K_ADDRESS_MASK_64);
 }
 
 /**
-- 
2.12.2.windows.2

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

[edk2] [PATCH] UefiCpuPkg: Add BOOLEAN casts to return statements.

[Marvin Häuser]

Old versions of the Visual Studio C compiler return a value of type
'int' for comparisons, which is what the C99 standard defines in the
sections 6.5.8 and 6.5.9. When the result of a comparison is
returned, int is implicitely casted to BOOLEAN, which is smaller, and
hence a warning about a possible loss of data is generated. This
patch adds casts to BOOLEAN where necessary to silence these.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c | 8 
 UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c | 8 
 UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c| 2 +-
 UefiCpuPkg/Library/CpuCommonFeaturesLib/C1e.c  | 2 +-
 UefiCpuPkg/Library/CpuCommonFeaturesLib/ClockModulation.c  | 2 +-
 UefiCpuPkg/Library/CpuCommonFeaturesLib/Eist.c | 2 +-
 UefiCpuPkg/Library/CpuCommonFeaturesLib/ExecuteDisable.c   | 2 +-
 UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c   | 4 ++--
 UefiCpuPkg/Library/CpuCommonFeaturesLib/LimitCpuIdMaxval.c | 2 +-
 UefiCpuPkg/Library/CpuCommonFeaturesLib/MachineCheck.c | 6 +++---
 UefiCpuPkg/Library/CpuCommonFeaturesLib/MonitorMwait.c | 2 +-
 UefiCpuPkg/Library/CpuCommonFeaturesLib/PendingBreak.c | 2 +-
 UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c | 2 +-
 UefiCpuPkg/Library/CpuCommonFeaturesLib/X2Apic.c   | 2 +-
 UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c | 2 +-
 15 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c 
b/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c
index 2091e5e2d0dd..55aee6c607f7 100644
--- a/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c
+++ b/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c
@@ -3,7 +3,7 @@
 
   This local APIC library instance supports xAPIC mode only.
 
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
   Copyright (c) 2017, AMD Inc. All rights reserved.
 
   This program and the accompanying materials
@@ -49,9 +49,9 @@ StandardSignatureIsAuthenticAMD (
   UINT32  RegEdx;
 
   AsmCpuid(CPUID_SIGNATURE, NULL, &RegEbx, &RegEcx, &RegEdx);
-  return (RegEbx == CPUID_SIGNATURE_AUTHENTIC_AMD_EBX &&
-  RegEcx == CPUID_SIGNATURE_AUTHENTIC_AMD_ECX &&
-  RegEdx == CPUID_SIGNATURE_AUTHENTIC_AMD_EDX);
+  return (BOOLEAN)(RegEbx == CPUID_SIGNATURE_AUTHENTIC_AMD_EBX &&
+   RegEcx == CPUID_SIGNATURE_AUTHENTIC_AMD_ECX &&
+   RegEdx == CPUID_SIGNATURE_AUTHENTIC_AMD_EDX);
 }
 
 /**
diff --git a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c 
b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
index d5d4efaeb408..bfd5acceebfa 100644
--- a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
+++ b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
@@ -4,7 +4,7 @@
   This local APIC library instance supports x2APIC capable processors
   which have xAPIC and x2APIC modes.
 
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
   Copyright (c) 2017, AMD Inc. All rights reserved.
 
   This program and the accompanying materials
@@ -50,9 +50,9 @@ StandardSignatureIsAuthenticAMD (
   UINT32  RegEdx;
 
   AsmCpuid(CPUID_SIGNATURE, NULL, &RegEbx, &RegEcx, &RegEdx);
-  return (RegEbx == CPUID_SIGNATURE_AUTHENTIC_AMD_EBX &&
-  RegEcx == CPUID_SIGNATURE_AUTHENTIC_AMD_ECX &&
-  RegEdx == CPUID_SIGNATURE_AUTHENTIC_AMD_EDX);
+  return (BOOLEAN)(RegEbx == CPUID_SIGNATURE_AUTHENTIC_AMD_EBX &&
+   RegEcx == CPUID_SIGNATURE_AUTHENTIC_AMD_ECX &&
+   RegEdx == CPUID_SIGNATURE_AUTHENTIC_AMD_EDX);
 }
 
 /**
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c
index 178bfb50abcf..df0f56ab9d82 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c
@@ -69,7 +69,7 @@ AesniSupport (
   IS_XEON_PHI_PROCESSOR (CpuInfo->DisplayFamily, CpuInfo->DisplayModel)) {
 MsrFeatureConfig = (MSR_SANDY_BRIDGE_FEATURE_CONFIG_REGISTER *) ConfigData;
 MsrFeatureConfig[ProcessorNumber].Uint64 = AsmReadMsr64 
(MSR_SANDY_BRIDGE_FEATURE_CONFIG);
-return (CpuInfo->CpuIdVersionInfoEcx.Bits.AESNI == 1);
+return (BOOLEAN)(CpuInfo->CpuIdVersionInfoEcx.Bits.AESNI == 1);
   }
   return FALSE;
 }
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/C1e.c 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/C1e.c
index 47116355a8ff..00ebc5c9a19e 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/C1e.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/C1e.c
@@ -38,7 +38,7 @@ C1eSupport (
   IN VOID