date:20181106



On Wed, Nov 07, 2018 at 03:12:47PM +0800, Jian J Wang wrote:
> > v3: fixed one more memory leak in the same function and updated
> > commit message accordingly.

No objection to the content, but comments not intended to be committed
should go in the cover letter or below the ---.

A changelog between revisions is best kept in the cover letter,
including all changes in reverse chronological order, like:

Changes since v2:
- ...

Changes since v1:
- ...

I expect whoever pushes the patches will edit the history out of the
commit message, but putting it in the cover-letter means less work for
them.

(I won't give a reviewed-by since I have only been commenting on
style, not functionality.)

/
Leif

> At the end of of MemoryProtectionCpuArchProtocolNotify there's cleanup
> code to free resource. But at line 978, 994, 1005 the function returns
> directly. This patch use "goto" to replace "return" to make sure the
> resource is freed before exit.
> 
> 1029:  CoreCloseEvent (Event);
> 1030:  return;
> 
> There's another memory leak after calling gBS->LocateHandleBuffer() in
> the same function:
> 
>   Status = gBS->LocateHandleBuffer (
>   ByProtocol,
>   ,
>   NULL,
>   ,
>   
>   );
> 
> HandleBuffer is allocated in above call but never freed. This patch
> will also add code to free it.
> 
> Cc: Star Zeng 
> Cc: Jiewen Yao 
> Cc: Ruiyu Ni 
> Cc: Leif Lindholm 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> index 6298b67db1..8a93c5362a 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> @@ -975,7 +975,7 @@ MemoryProtectionCpuArchProtocolNotify (
>DEBUG ((DEBUG_INFO, "MemoryProtectionCpuArchProtocolNotify:\n"));
>Status = CoreLocateProtocol (, NULL, (VOID 
> **));
>if (EFI_ERROR (Status)) {
> -return;
> +goto Done;
>}
>  
>//
> @@ -991,7 +991,7 @@ MemoryProtectionCpuArchProtocolNotify (
>HeapGuardCpuArchProtocolNotify ();
>  
>if (mImageProtectionPolicy == 0) {
> -return;
> +goto Done;
>}
>  
>Status = gBS->LocateHandleBuffer (
> @@ -1002,7 +1002,7 @@ MemoryProtectionCpuArchProtocolNotify (
>
>);
>if (EFI_ERROR (Status) && (NoHandles == 0)) {
> -return ;
> +goto Done;
>}
>  
>for (Index = 0; Index < NoHandles; Index++) {
> @@ -1025,9 +1025,10 @@ MemoryProtectionCpuArchProtocolNotify (
>  
>  ProtectUefiImage (LoadedImage, LoadedImageDevicePath);
>}
> +  FreePool (HandleBuffer);
>  
> +Done:
>CoreCloseEvent (Event);
> -  return;
>  }
>  
>  /**
> -- 
> 2.16.2.windows.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/2] fix ineffective guard page issue

2018-11-06 Thread Zeng, Star

Reviewed-by: Star Zeng 

-Original Message-
From: Wang, Jian J 
Sent: Wednesday, November 7, 2018 3:13 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Yao, Jiewen ; Ni, 
Ruiyu ; Leif Lindholm 
Subject: [PATCH v3 0/2] fix ineffective guard page issue

>v3: found and fixed another memory leak

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

Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 

Jian J Wang (2):
  MdeModulePkg/Core: fill logic hole in
MemoryProtectionCpuArchProtocolNotify
  MdeModulePkg/Core: fix ineffective guard page issue

 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 45 +--
 1 file changed, 22 insertions(+), 23 deletions(-)

-- 
2.16.2.windows.1

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

Re: [edk2] [edk2-test][Patch v2] uefi-sct/SctPkg:Add checkpoint of ReadKeyStrokeEx Toggle state

2018-11-06 Thread Jin, Eric

It is  the patch v2 below. 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric Jin
Sent: Wednesday, November 7, 2018 2:48 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [edk2-test][Patch] uefi-sct/SctPkg:Add checkpoint of 
ReadKeyStrokeEx Toggle state

UEFI drivers which implement the EFI_SIMPLE_TEXT_INPUT_EX protocol are required 
to return KeyData.Key and KeyData.KeyState values.
These drivers must always return the most current state of 
KeyData.KeyState.KeyShiftState and KeyData.KeyState.KeyToggleState.

The change in spec is "EFI_NOT_READY - There was no keystroke data available. 
Current KeyData.KeyState values are exposed."

Cc: Supreeth Venkatesh 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
 .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c |   7 +-
 .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h |  12 +-  
.../BlackBoxTest/SimpleTextInputExBBTestFunction.c | 211 
 .../BlackBoxTest/SimpleTextInputExBBTestMain.c |  13 +-
 .../BlackBoxTest/SimpleTextInputExBBTestMain.h |  22 ++-
 .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c |   7 +-
 .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h |  12 +-  
.../BlackBoxTest/SimpleTextInputExBBTestFunction.c | 213 -
 .../BlackBoxTest/SimpleTextInputExBBTestMain.c |  11 +-
 .../BlackBoxTest/SimpleTextInputExBBTestMain.h |  20 +-
 10 files changed, 515 insertions(+), 13 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c
index 9cb19f4..ff2d50f 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/Black
+++ BoxTest/Guid.c
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2012 Unified EFI, Inc.
-  Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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 @@ -63,3 +63,8 @@ EFI_GUID 
gSimpleTextInputExBBTestFunctionAssertionGuid007 = EFI_TEST_SIMPLETEXTI  
EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid008 = 
EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_008_GUID;
 
 EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid009 = 
EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_009_GUID;
+
+EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid010 = 
+EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_010_GUID;
+
+EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid011 = 
+EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_011_GUID;
+
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h
index 6c90fca..2a6be48 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/Black
+++ BoxTest/Guid.h
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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 @@ -119,3 +119,13 @@ extern EFI_GUID 
gSimpleTextInputExBBTestFunctionAssertionGuid008;
 { 0x534369f7, 0x8399, 0x4353, { 0x94, 0xad, 0xc4, 0x48, 0xfa, 0xda, 0xeb, 0x84 
} }
 
 extern EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid009;
+
+#define EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_010_GUID \ { 
+0xcf4d54eb, 0x6696, 0x4794, { 0x91, 0x74, 0x59, 0xd, 0x1c, 0x22, 0xa8, 
+0x67 } }
+
+extern EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid010;
+
+#define EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_011_GUID \ { 
+0xf8e8f879, 0xa6d4, 0x4fd3, { 0x8b, 0x8e, 0xba, 0x1d, 0x18, 0xf1, 0x40, 
+0x71 } }
+
+extern EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid011;
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
index 153ade0..4850627 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/Black
+++ BoxTest/SimpleTextInputExBBTestFunction.c
@@ -456,6 +456,78 @@ BBTestUnregisterKeyNotifyFunctionManualTest (  }
 
 
+EFI_STATUS
+BBTestReadKeyStrokeExFunctionAutoTest (
+  IN EFI_BB_TEST_PROTOCOL   *This,
+  IN VOID   *ClientInterface,

[edk2] [PATCH v3 1/2] MdeModulePkg/Core: fill logic hole in MemoryProtectionCpuArchProtocolNotify

> v3: fixed one more memory leak in the same function and updated
> commit message accordingly.

At the end of of MemoryProtectionCpuArchProtocolNotify there's cleanup
code to free resource. But at line 978, 994, 1005 the function returns
directly. This patch use "goto" to replace "return" to make sure the
resource is freed before exit.

1029:  CoreCloseEvent (Event);
1030:  return;

There's another memory leak after calling gBS->LocateHandleBuffer() in
the same function:

  Status = gBS->LocateHandleBuffer (
  ByProtocol,
  ,
  NULL,
  ,
  
  );

HandleBuffer is allocated in above call but never freed. This patch
will also add code to free it.

Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
index 6298b67db1..8a93c5362a 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
@@ -975,7 +975,7 @@ MemoryProtectionCpuArchProtocolNotify (
   DEBUG ((DEBUG_INFO, "MemoryProtectionCpuArchProtocolNotify:\n"));
   Status = CoreLocateProtocol (, NULL, (VOID **));
   if (EFI_ERROR (Status)) {
-return;
+goto Done;
   }
 
   //
@@ -991,7 +991,7 @@ MemoryProtectionCpuArchProtocolNotify (
   HeapGuardCpuArchProtocolNotify ();
 
   if (mImageProtectionPolicy == 0) {
-return;
+goto Done;
   }
 
   Status = gBS->LocateHandleBuffer (
@@ -1002,7 +1002,7 @@ MemoryProtectionCpuArchProtocolNotify (
   
   );
   if (EFI_ERROR (Status) && (NoHandles == 0)) {
-return ;
+goto Done;
   }
 
   for (Index = 0; Index < NoHandles; Index++) {
@@ -1025,9 +1025,10 @@ MemoryProtectionCpuArchProtocolNotify (
 
 ProtectUefiImage (LoadedImage, LoadedImageDevicePath);
   }
+  FreePool (HandleBuffer);
 
+Done:
   CoreCloseEvent (Event);
-  return;
 }
 
 /**
-- 
2.16.2.windows.1

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

[edk2] [PATCH v3 2/2] MdeModulePkg/Core: fix ineffective guard page issue

>v3: no change

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

This issue originates from following patch which allows to enable
paging if PcdImageProtectionPolicy and PcdDxeNxMemoryProtectionPolicy
(in addition to PcdSetNxForStack) are set to enable related features.

  5267926134d17e86672b84fd57b438f05ffa68e1

Due to above change, PcdImageProtectionPolicy will be set to 0 by
default in many platforms, which, in turn, cause following code in
MdeModulePkg\Core\Dxe\Misc\MemoryProtection.c fail the creation of
notify event of CpuArchProtocol.

1138:  if (mImageProtectionPolicy != 0 ||
   PcdGet64 (PcdDxeNxMemoryProtectionPolicy) != 0) {
1139:  Status = CoreCreateEvent (
...
1142: MemoryProtectionCpuArchProtocolNotify,
...
1145: );

Then following call flow won't be done and Guard pages will not be
set as not-present in SetAllGuardPages() eventually.

   MemoryProtectionCpuArchProtocolNotify()
=> HeapGuardCpuArchProtocolNotify()
=> SetAllGuardPages()

The solution is removing the if(...) statement so that the notify
event will always be created and registered. This won't cause
unnecessary code execution because, in the notify event handler,
the related PCDs like

PcdImageProtectionPolicy and
PcdDxeNxMemoryProtectionPolicy

will be checked again before doing related jobs.

Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 36 +--
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
index 8a93c5362a..c43e0d08ae 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
@@ -1136,26 +1136,24 @@ CoreInitializeMemoryProtection (
   ASSERT (GetPermissionAttributeForMemoryType (EfiBootServicesData) ==
   GetPermissionAttributeForMemoryType (EfiConventionalMemory));
 
-  if (mImageProtectionPolicy != 0 || PcdGet64 (PcdDxeNxMemoryProtectionPolicy) 
!= 0) {
-Status = CoreCreateEvent (
-   EVT_NOTIFY_SIGNAL,
-   TPL_CALLBACK,
-   MemoryProtectionCpuArchProtocolNotify,
-   NULL,
-   
-   );
-ASSERT_EFI_ERROR(Status);
+  Status = CoreCreateEvent (
+ EVT_NOTIFY_SIGNAL,
+ TPL_CALLBACK,
+ MemoryProtectionCpuArchProtocolNotify,
+ NULL,
+ 
+ );
+  ASSERT_EFI_ERROR(Status);
 
-//
-// Register for protocol notifactions on this event
-//
-Status = CoreRegisterProtocolNotify (
-   ,
-   Event,
-   
-   );
-ASSERT_EFI_ERROR(Status);
-  }
+  //
+  // Register for protocol notifactions on this event
+  //
+  Status = CoreRegisterProtocolNotify (
+ ,
+ Event,
+ 
+ );
+  ASSERT_EFI_ERROR(Status);
 
   //
   // Register a callback to disable NULL pointer detection at EndOfDxe
-- 
2.16.2.windows.1

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

[edk2] [PATCH v3 0/2] fix ineffective guard page issue

>v3: found and fixed another memory leak

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

Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 

Jian J Wang (2):
  MdeModulePkg/Core: fill logic hole in
MemoryProtectionCpuArchProtocolNotify
  MdeModulePkg/Core: fix ineffective guard page issue

 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 45 +--
 1 file changed, 22 insertions(+), 23 deletions(-)

-- 
2.16.2.windows.1

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

Re: [edk2] OVMF compile error


On 2018-11-07 12:39, Chen, Farrah wrote:

Hi,

When we build OVMF with the latest commit:
328409ce8de7f318ee9c929b64302bd361cd1dbd, we met below error:

OvmfPkg/build.sh -a X64 -n 8

...

OK
make[1]: Leaving directory `/home/fan/edk2/BaseTools/Tests'
make: Leaving directory `/home/fan/edk2/BaseTools'
Running edk2 build for OvmfPkgX64
Build environment: 
Linux-3.10.0-862.el7.x86_64-x86_64-with-redhat-7.5-Maipo

Build start time: 12:13:50, Nov.07 2018

WORKSPACE= /home/fan/edk2
ECP_SOURCE   = /home/fan/edk2/EdkCompatibilityPkg
EDK_SOURCE   = /home/fan/edk2/EdkCompatibilityPkg
EFI_SOURCE   = /home/fan/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH   = /home/fan/edk2/BaseTools
CONF_PATH= /home/fan/edk2/Conf


Architecture(s)  = X64
Build target = DEBUG
Toolchain= GCC48

Active Platform  = /home/fan/edk2/OvmfPkg/OvmfPkgX64.dsc
Flash Image Definition   = /home/fan/edk2/OvmfPkg/OvmfPkgX64.fdf

Processing meta-data ...

build.py...
/home/fan/edk2/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf(31):
error 000E: File/directory not found in workspace
/home/fan/edk2/CryptoPkg/Library/OpensslLib/openssl/e_os.h


- Failed -
Build end time: 12:13:59, Nov.07 2018
Build total time: 00:00:09




Thanks,
Fan

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



Hi,

Try:

git submodule init
git submodule update --recursive

And build it again.

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

[edk2] OVMF compile error

2018-11-06 Thread Chen, Farrah

Hi,

When we build OVMF with the latest commit: 
328409ce8de7f318ee9c929b64302bd361cd1dbd, we met below error:

OvmfPkg/build.sh -a X64 -n 8

...

OK
make[1]: Leaving directory `/home/fan/edk2/BaseTools/Tests'
make: Leaving directory `/home/fan/edk2/BaseTools'
Running edk2 build for OvmfPkgX64
Build environment: Linux-3.10.0-862.el7.x86_64-x86_64-with-redhat-7.5-Maipo
Build start time: 12:13:50, Nov.07 2018

WORKSPACE= /home/fan/edk2
ECP_SOURCE   = /home/fan/edk2/EdkCompatibilityPkg
EDK_SOURCE   = /home/fan/edk2/EdkCompatibilityPkg
EFI_SOURCE   = /home/fan/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH   = /home/fan/edk2/BaseTools
CONF_PATH= /home/fan/edk2/Conf


Architecture(s)  = X64
Build target = DEBUG
Toolchain= GCC48

Active Platform  = /home/fan/edk2/OvmfPkg/OvmfPkgX64.dsc
Flash Image Definition   = /home/fan/edk2/OvmfPkg/OvmfPkgX64.fdf

Processing meta-data ...

build.py...
/home/fan/edk2/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf(31): error 
000E: File/directory not found in workspace
/home/fan/edk2/CryptoPkg/Library/OpensslLib/openssl/e_os.h


- Failed -
Build end time: 12:13:59, Nov.07 2018
Build total time: 00:00:09




Thanks,
Fan

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

Re: [edk2] [PATCH] SourceLevelDebugPkg/Readme.txt: Update UDK Debugger Tool & manual URL

2018-11-06 Thread Ni, Ruiyu

Reviewed-by: Ruiyu Ni 

Thanks/Ray

> -Original Message-
> From: Wu, Hao A 
> Sent: Wednesday, November 7, 2018 10:31 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ni, Ruiyu 
> Subject: [PATCH] SourceLevelDebugPkg/Readme.txt: Update UDK Debugger
> Tool & manual URL
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1289
> 
> The commit updates the link to get access to the Intel(R) UDK Debugger Tool
> and its detailed user manual.
> 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  SourceLevelDebugPkg/Readme.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/SourceLevelDebugPkg/Readme.txt
> b/SourceLevelDebugPkg/Readme.txt index cb5d976d77..765207a7db 100644
> --- a/SourceLevelDebugPkg/Readme.txt
> +++ b/SourceLevelDebugPkg/Readme.txt
> @@ -3,4 +3,4 @@ SourceLevelDebugPkg in conjunction with Intel(R) UEFI
> Development Kit Debugger  Tool (Intel (R) UDK Debugger Tool).
> 
>  The Intel(R) UDK Debugger Tool and its detailed user manual can be
> obtained
> -from: http://www.uefidk.com/develop.
> +from: https://firmware.intel.com/develop/intel-uefi-tools-and-
> utilities/intel-uefi-development-kit-debugger-tool.
> --
> 2.12.0.windows.1

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

[edk2] [PATCH] MdePkg/BaseSynchronizationLib XCODE: fix InternalSync[De|In]crement

2018-11-06 Thread Ruiyu Ni

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

XCODE disassembly code of InternalSyncDecrement with today's code is:

  __asm__ __volatile__ (
"movl$1, %%eax  \n\t"
"lock   \n\t"
"xadd%%eax, %1  \n\t"
"inc %%eax  \n\t"
: "=a" (Result),  // %0
  "+m" (*Value)   // %1
: // no inputs that aren't also outputs
: "memory",
  "cc"
);

 0:   55  pushl   %ebp
 1:   89 e5   movl%esp, %ebp
 3:   8b 45 08movl8(%ebp), %eax
 6:   b8 01 00 00 00  movl$1, %eax
 b:   f0  lock
 c:   0f c1 00xaddl   %eax, _InternalSyncIncrement(%eax)
 f:   40  incl%eax
10:   5d  popl%ebp
11:   c3  retl

%EAX value retrieved in line #3 is overwritten in line #6.

The patch uses the clobber list to tell GCC that EAX is used in ASM.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Liming Gao 
Cc: Michael Kinney 
Cc: Laszlo Ersek 
Cc: Philippe Mathieu-Daudé 
---
 MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c 
b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
index af39bdeb51..0a985529fd 100644
--- a/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
+++ b/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
@@ -40,11 +40,13 @@ InternalSyncIncrement (
 "lock   \n\t"
 "xadd%%eax, %1  \n\t"
 "inc %%eax  \n\t"
-: "=a" (Result),  // %0
+"mov %%eax, %0  \n\t"
+: "=r" (Result),  // %0
   "+m" (*Value)   // %1
 : // no inputs that aren't also outputs
 : "memory",
-  "cc"
+  "cc",
+  "eax"
 );
 
   return Result;
@@ -76,11 +78,13 @@ InternalSyncDecrement (
 "lock\n\t"
 "xadd%%eax, %1   \n\t"
 "dec %%eax   \n\t"
-: "=a" (Result),   // %0
+"mov %%eax, %0  \n\t"
+: "=r" (Result),   // %0
   "+m" (*Value)// %1
 :  // no inputs that aren't also outputs
 : "memory",
-  "cc"
+  "cc",
+  "eax"
 );
 
   return Result;
-- 
2.16.1.windows.1

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

[edk2] [PATCH v3] OvmfPkg: simply use the Bochs interface for vmsvga

From: yuchenlin 

BAR  |std vga |  vmsvga
-
0|   Framebuffer  | I/O space
1|   Reserved | Framebuffer
2|   MMIO | FIFO

- We cannot recognize VMW SVGA as BOCHS because that would confuse the
  IsQxl setting in QemuVideoControllerDriverStart(),

- We cannot recognize VMW SVGA as BOCHS_MMIO because BAR2 on VMW SVGA is
  not the BOCHS MMIO BAR (we can only use port IO).

Therefore the list of reasons for which we should introduce
QEMU_VIDEO_VMWARE_SVGA should name three reasons:

 (1) Get framebuffer from correct PCI BAR
 (2) Prevent using BAR2 for MMIO
 (3) Prevent mis-recognizing VMW SVGA as QXL

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin 
---
Changelog:

v1 -> v2
* use 'else' clause (Thanks Philippe).
* add more comment in revert patches (Thanks Philippe).
* reorder the revert patches, we should revert the last commit first.
* use correct framebuffer to ClearScreen.
* revert VMWare svga definitions.

v2 -> v3
* Update commit message (Thanks Laszlo)
* Treat QEMU_VIDEO_VMWARE_SVGA as QEMU_VIDEO_BOCHS (Thanks Laszlo)

---
 OvmfPkg/QemuVideoDxe/Driver.c | 16 +++-
 OvmfPkg/QemuVideoDxe/Gop.c|  2 +-
 OvmfPkg/QemuVideoDxe/Qemu.h   |  2 ++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index 2304afd1e6..8e02700d39 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -69,6 +69,12 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
 0x1050,
 QEMU_VIDEO_BOCHS_MMIO,
 L"QEMU VirtIO VGA"
+},{
+PCI_CLASS_DISPLAY_VGA,
+0x15ad,
+0x0405,
+QEMU_VIDEO_VMWARE_SVGA,
+L"QEMU VMWare SVGA"
 },{
 0 /* end of list */
 }
@@ -316,6 +322,14 @@ QemuVideoControllerDriverStart (
 }
   }
 
+  //
+  // VMWare SVGA is handled like Bochs (with port IO only).
+  //
+  if (Private->Variant == QEMU_VIDEO_VMWARE_SVGA) {
+Private->Variant = QEMU_VIDEO_BOCHS;
+Private->FrameBufferVramBarIndex = PCI_BAR_IDX1;
+  }
+
   //
   // Check if accessing the bochs interface works.
   //
@@ -764,7 +778,7 @@ ClearScreen (
   Private->PciIo->Mem.Write (
 Private->PciIo,
 EfiPciIoWidthFillUint32,
-0,
+Private->FrameBufferVramBarIndex,
 0,
 0x40 >> 2,
 
diff --git a/OvmfPkg/QemuVideoDxe/Gop.c b/OvmfPkg/QemuVideoDxe/Gop.c
index d490fa7a2e..6f542d9eac 100644
--- a/OvmfPkg/QemuVideoDxe/Gop.c
+++ b/OvmfPkg/QemuVideoDxe/Gop.c
@@ -60,7 +60,7 @@ QemuVideoCompleteModeData (
 
   Private->PciIo->GetBarAttributes (
 Private->PciIo,
-0,
+Private->FrameBufferVramBarIndex,
 NULL,
 (VOID**) 
 );
diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
index d7da761705..3aac9eeca6 100644
--- a/OvmfPkg/QemuVideoDxe/Qemu.h
+++ b/OvmfPkg/QemuVideoDxe/Qemu.h
@@ -92,6 +92,7 @@ typedef enum {
   QEMU_VIDEO_CIRRUS_5446,
   QEMU_VIDEO_BOCHS,
   QEMU_VIDEO_BOCHS_MMIO,
+  QEMU_VIDEO_VMWARE_SVGA,
 } QEMU_VIDEO_VARIANT;
 
 typedef struct {
@@ -120,6 +121,7 @@ typedef struct {
   QEMU_VIDEO_VARIANTVariant;
   FRAME_BUFFER_CONFIGURE*FrameBufferBltConfigure;
   UINTN FrameBufferBltConfigureSize;
+  UINT8 FrameBufferVramBarIndex;
 } QEMU_VIDEO_PRIVATE_DATA;
 
 ///
-- 
2.18.0

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

Re: [edk2] [PATCH v2 0/2] *fix ineffective guard page issue

2018-11-06 Thread Zeng, Star


On 2018/11/7 8:53, Jian J Wang wrote:

v2: re-generate the patch per Leif's comments


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

Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 


Reviewed-by: Star Zeng 



Jian J Wang (2):
   MdeModulePkg/Core: fill logic hole in
 MemoryProtectionCpuArchProtocolNotify
   MdeModulePkg/Core: fix ineffective guard page issue

  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 44 +--
  1 file changed, 21 insertions(+), 23 deletions(-)



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

Re: [edk2] [PATCH v2 5/5] OvmfPkg: simply use the Bochs interface for vmsvga


On 2018-11-06 21:44, Philippe Mathieu-Daudé wrote:

On 6/11/18 14:36, Laszlo Ersek wrote:

On 11/06/18 12:47, Laszlo Ersek wrote:


... While we discuss this, I'll go ahead and push the first four
patches. The code being reverted is dead anyway. I'll report back 
about

the commit hashes.


Before pushing the first four patches, I regression-tested them as 
well.

Using: Cirrus, stdvga, and QXL. My QEMU version was
v3.0.0-1763-gb2f7a038bb4c. The machine type was "pc-q35-3.0".

For the first four patches:
- Regression-tested-by: Laszlo Ersek ,
- pushed them as commit range 62ea70e31285..328409ce8de7.


Thanks Laszlo!
A bit late, but 1-4 reviewed too.



Thanks
Laszlo



Thank you for your effort on this series!

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

Re: [edk2] [PATCH v2 5/5] OvmfPkg: simply use the Bochs interface for vmsvga


On 2018-11-06 19:47, Laszlo Ersek wrote:

I suggest the following:

On 11/02/18 04:24, yuchenlin via edk2-devel wrote:

From: yuchenlin 

BAR  |std vga |  vmsvga
-
0|   Framebuffer  | I/O space
1|   Reserved | Framebuffer
2|   MMIO | FIFO

Because of the PCI BARs difference between std vga and
vmsvga, we can not simply recognize the "QEMU VMWare SVGA"
as the QEMU_VIDEO_BOCHS_MMIO variant.

Instead, we remain variant QEMU_VIDEO_VMWARE_SVGA, and use
it for:

(1) Get framebuffer from correct PCI BAR
(2) Prevent using BAR2 for MMIO


[a] The commit message should be udpated as follows:

- We cannot recognize VMW SVGA as BOCHS because that would confuse the
  IsQxl setting in QemuVideoControllerDriverStart(),

- We cannot recognize VMW SVGA as BOCHS_MMIO because BAR2 on VMW SVGA 
is

  not the BOCHS MMIO BAR (we can only use port IO).

Therefore the list of reasons for which we should introduce
QEMU_VIDEO_VMWARE_SVGA should name three reasons: both of the currently
listed reasons, plus "prevent mis-recognizing VMW SVGA as QXL" as the
third one.



Will do.

Thanks,
yuchenlin



Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin 
---
 OvmfPkg/QemuVideoDxe/Driver.c | 18 --
 OvmfPkg/QemuVideoDxe/Gop.c|  3 ++-
 OvmfPkg/QemuVideoDxe/Qemu.h   |  2 ++
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c 
b/OvmfPkg/QemuVideoDxe/Driver.c

index 2304afd1e6..76d4a2d27e 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -69,6 +69,12 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
 0x1050,
 QEMU_VIDEO_BOCHS_MMIO,
 L"QEMU VirtIO VGA"
+},{
+PCI_CLASS_DISPLAY_VGA,
+0x15ad,
+0x0405,
+QEMU_VIDEO_VMWARE_SVGA,
+L"QEMU VMWare SVGA"
 },{
 0 /* end of list */
 }
@@ -256,6 +262,12 @@ QemuVideoControllerDriverStart (
 goto ClosePciIo;
   }
   Private->Variant = Card->Variant;
+  if (Private->Variant == QEMU_VIDEO_VMWARE_SVGA) {
+Private->FrameBufferVramBarIndex = PCI_BAR_IDX1;
+  } else {
+Private->FrameBufferVramBarIndex = PCI_BAR_IDX0;
+  }
+

   //
   // IsQxl is based on the detected Card->Variant, which at a later 
point might

@@ -320,7 +332,8 @@ QemuVideoControllerDriverStart (
   // Check if accessing the bochs interface works.
   //
   if (Private->Variant == QEMU_VIDEO_BOCHS_MMIO ||
-  Private->Variant == QEMU_VIDEO_BOCHS) {
+  Private->Variant == QEMU_VIDEO_BOCHS ||
+  Private->Variant == QEMU_VIDEO_VMWARE_SVGA) {
 UINT16 BochsId;
 BochsId = BochsRead(Private, VBE_DISPI_INDEX_ID);
 if ((BochsId & 0xFFF0) != VBE_DISPI_ID0) {
@@ -383,6 +396,7 @@ QemuVideoControllerDriverStart (
 break;
   case QEMU_VIDEO_BOCHS_MMIO:
   case QEMU_VIDEO_BOCHS:
+  case QEMU_VIDEO_VMWARE_SVGA:
 Status = QemuVideoBochsModeSetup (Private, IsQxl);
 break;
   default:
@@ -764,7 +778,7 @@ ClearScreen (
   Private->PciIo->Mem.Write (
 Private->PciIo,
 EfiPciIoWidthFillUint32,
-0,
+Private->FrameBufferVramBarIndex,
 0,
 0x40 >> 2,
 
diff --git a/OvmfPkg/QemuVideoDxe/Gop.c b/OvmfPkg/QemuVideoDxe/Gop.c
index d490fa7a2e..3abc5eeb36 100644
--- a/OvmfPkg/QemuVideoDxe/Gop.c
+++ b/OvmfPkg/QemuVideoDxe/Gop.c
@@ -60,7 +60,7 @@ QemuVideoCompleteModeData (

   Private->PciIo->GetBarAttributes (
 Private->PciIo,
-0,
+Private->FrameBufferVramBarIndex,
 NULL,
 (VOID**) 
 );
@@ -177,6 +177,7 @@ Routine Description:
 break;
   case QEMU_VIDEO_BOCHS_MMIO:
   case QEMU_VIDEO_BOCHS:
+  case QEMU_VIDEO_VMWARE_SVGA:
 InitializeBochsGraphicsMode (Private, 
[ModeData->InternalModeIndex]);

 break;
   default:
diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
index d7da761705..3aac9eeca6 100644
--- a/OvmfPkg/QemuVideoDxe/Qemu.h
+++ b/OvmfPkg/QemuVideoDxe/Qemu.h
@@ -92,6 +92,7 @@ typedef enum {
   QEMU_VIDEO_CIRRUS_5446,
   QEMU_VIDEO_BOCHS,
   QEMU_VIDEO_BOCHS_MMIO,
+  QEMU_VIDEO_VMWARE_SVGA,
 } QEMU_VIDEO_VARIANT;

 typedef struct {
@@ -120,6 +121,7 @@ typedef struct {
   QEMU_VIDEO_VARIANTVariant;
   FRAME_BUFFER_CONFIGURE*FrameBufferBltConfigure;
   UINTN FrameBufferBltConfigureSize;
+  UINT8 FrameBufferVramBarIndex;
 } QEMU_VIDEO_PRIVATE_DATA;

 ///



[b] How about the following -- incremental, to be squashed -- patch:

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c 
b/OvmfPkg/QemuVideoDxe/Driver.c

index 76d4a2d27e7e..8e02700d3960 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -262,12

Re: [edk2] [PATCH v2] IntelFsp2WrapperPkg: Support FSP Dispatch mode

2018-11-06 Thread Yao, Jiewen

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Chiu, Chasel
> Sent: Wednesday, November 7, 2018 10:25 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Desimone, Nathaniel L
> ; Chiu, Chasel 
> Subject: [PATCH v2] IntelFsp2WrapperPkg: Support FSP Dispatch mode
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1300
> 
> Provides PCD selection for FSP Wrapper to support Dispatch
> mode. Also PcdFspmBaseAddress should support Dynamic for
> recovery scenario (multiple FSP-M binary in flash)
> 
> Test: Verified on internal platform and both API and
>   DISPATCH modes booted successfully.
> 
> Cc: Jiewen Yao 
> Cc: Desimone Nathaniel L 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu 
> ---
>  IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c   | 20
> 
>  IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c   | 14
> --
>  IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf |  3 ++-
>  IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf |  3 ++-
>  IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec | 13
> +++--
>  5 files changed, 43 insertions(+), 10 deletions(-)
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> index 7b7c5f5d86..fa0441ce6c 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> @@ -3,7 +3,7 @@
>register TemporaryRamDonePpi to call TempRamExit API, and register
> MemoryDiscoveredPpi
>notify to call FspSiliconInit API.
> 
> -  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the
> BSD License
>which accompanies this distribution.  The full text of the license may be
> found at
> @@ -65,7 +65,7 @@ PeiFspMemoryInit (
>FspHobListPtr = NULL;
>FspmUpdDataPtr = NULL;
> 
> -  FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32
> (PcdFspmBaseAddress));
> +  FspmHeaderPtr = (FSP_INFO_HEADER *) FspFindFspHeader (PcdGet32
> (PcdFspmBaseAddress));
>DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
>if (FspmHeaderPtr == NULL) {
>  return EFI_DEVICE_ERROR;
> @@ -155,8 +155,20 @@ FspmWrapperInit (
>  {
>EFI_STATUS   Status;
> 
> -  Status = PeiFspMemoryInit ();
> -  ASSERT_EFI_ERROR (Status);
> +  Status = EFI_SUCCESS;
> +
> +  if (FixedPcdGet8 (PcdFspModeSelection) == 1) {
> +Status = PeiFspMemoryInit ();
> +ASSERT_EFI_ERROR (Status);
> +  } else {
> +PeiServicesInstallFvInfoPpi (
> +  NULL,
> +  (VOID *)(UINTN) PcdGet32 (PcdFspmBaseAddress),
> +  (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32
> (PcdFspmBaseAddress))->FvLength,
> +  NULL,
> +  NULL
> +  );
> +  }
> 
>return Status;
>  }
> diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> index 70dac7a414..87dd61e5c5 100644
> --- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> @@ -3,7 +3,7 @@
>register TemporaryRamDonePpi to call TempRamExit API, and register
> MemoryDiscoveredPpi
>notify to call FspSiliconInit API.
> 
> -  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 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
> @@ -349,7 +349,17 @@ FspsWrapperPeimEntryPoint (
>  {
>DEBUG ((DEBUG_INFO, "FspsWrapperPeimEntryPoint\n"));
> 
> -  FspsWrapperInit ();
> +  if (FixedPcdGet8 (PcdFspModeSelection) == 1) {
> +FspsWrapperInit ();
> +  } else {
> +PeiServicesInstallFvInfoPpi (
> +  NULL,
> +  (VOID *)(UINTN) PcdGet32 (PcdFspsBaseAddress),
> +  (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32
> (PcdFspsBaseAddress))->FvLength,
> +  NULL,
> +  NULL
> +  );
> +  }
> 
>return EFI_SUCCESS;
>  }
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> index 542356b582..b3776a80f3 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> @@ -6,7 +6,7 @@
>  # register TemporaryRamDonePpi to call TempRamExit API, and register
> MemoryDiscoveredPpi
>  # notify to call FspSiliconInit API.
>  #
> -#  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
>  #
>  #

[edk2] [PATCH v2] IntelFsp2WrapperPkg: Support FSP Dispatch mode

2018-11-06 Thread Chasel, Chiu

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

Provides PCD selection for FSP Wrapper to support Dispatch
mode. Also PcdFspmBaseAddress should support Dynamic for
recovery scenario (multiple FSP-M binary in flash)

Test: Verified on internal platform and both API and
  DISPATCH modes booted successfully.

Cc: Jiewen Yao 
Cc: Desimone Nathaniel L 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chasel Chiu 
---
 IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c   | 20 

 IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c   | 14 --
 IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf |  3 ++-
 IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf |  3 ++-
 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec | 13 +++--
 5 files changed, 43 insertions(+), 10 deletions(-)

diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
index 7b7c5f5d86..fa0441ce6c 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
@@ -3,7 +3,7 @@
   register TemporaryRamDonePpi to call TempRamExit API, and register 
MemoryDiscoveredPpi
   notify to call FspSiliconInit API.
 
-  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -65,7 +65,7 @@ PeiFspMemoryInit (
   FspHobListPtr = NULL;
   FspmUpdDataPtr = NULL;
 
-  FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32 
(PcdFspmBaseAddress));
+  FspmHeaderPtr = (FSP_INFO_HEADER *) FspFindFspHeader (PcdGet32 
(PcdFspmBaseAddress));
   DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
   if (FspmHeaderPtr == NULL) {
 return EFI_DEVICE_ERROR;
@@ -155,8 +155,20 @@ FspmWrapperInit (
 {
   EFI_STATUS   Status;
 
-  Status = PeiFspMemoryInit ();
-  ASSERT_EFI_ERROR (Status);
+  Status = EFI_SUCCESS;
+
+  if (FixedPcdGet8 (PcdFspModeSelection) == 1) {
+Status = PeiFspMemoryInit ();
+ASSERT_EFI_ERROR (Status);
+  } else {
+PeiServicesInstallFvInfoPpi (
+  NULL,
+  (VOID *)(UINTN) PcdGet32 (PcdFspmBaseAddress),
+  (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32 
(PcdFspmBaseAddress))->FvLength,
+  NULL,
+  NULL
+  );
+  }
 
   return Status;
 }
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
index 70dac7a414..87dd61e5c5 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
@@ -3,7 +3,7 @@
   register TemporaryRamDonePpi to call TempRamExit API, and register 
MemoryDiscoveredPpi
   notify to call FspSiliconInit API.
 
-  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 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
@@ -349,7 +349,17 @@ FspsWrapperPeimEntryPoint (
 {
   DEBUG ((DEBUG_INFO, "FspsWrapperPeimEntryPoint\n"));
 
-  FspsWrapperInit ();
+  if (FixedPcdGet8 (PcdFspModeSelection) == 1) {
+FspsWrapperInit ();
+  } else {
+PeiServicesInstallFvInfoPpi (
+  NULL,
+  (VOID *)(UINTN) PcdGet32 (PcdFspsBaseAddress),
+  (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32 
(PcdFspsBaseAddress))->FvLength,
+  NULL,
+  NULL
+  );
+  }
 
   return EFI_SUCCESS;
 }
diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
index 542356b582..b3776a80f3 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
@@ -6,7 +6,7 @@
 # register TemporaryRamDonePpi to call TempRamExit API, and register 
MemoryDiscoveredPpi
 # notify to call FspSiliconInit API.
 #
-#  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
+#  Copyright (c) 2014 - 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
@@ -61,6 +61,7 @@
 [Pcd]
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress ## CONSUMES
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspmUpdDataAddress  ## CONSUMES
+  gIntelFsp2WrapperTokenSpaceGuid.PcdFspModeSelection## CONSUMES
 
 [Sources]
   FspmWrapperPeim.c
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf

Re: [edk2] [PATCH] UefiCpuPkg/CommonFeature: Skip locking when the feature is disabled

2018-11-06 Thread Dong, Eric

Hi Ray,

I think we should add comments to mention that if the Lock bit is already set, 
driver can't disable it. So driver can directly return success if state is 
FALSE.

With that comments, Reviewed-by: Eric Dong 

Thanks,
Eric

> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, November 6, 2018 5:06 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Laszlo Ersek 
> Subject: [PATCH] UefiCpuPkg/CommonFeature: Skip locking when the
> feature is disabled
> 
> Today's code unconditionally sets the IA32_FEATURE_CONTROL.Lock to 1 no
> matter the feature is enabled or not.
> 
> The patch fixes this issue by only setting the Lock bit to 1 when the feature 
> is
> enabled.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> ---
>  UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c | 10
> +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
> b/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
> index 8c1eb5eb4f..0b85f25f90 100644
> --- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
> +++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
> @@ -1,7 +1,7 @@
>  /** @file
>Features in MSR_IA32_FEATURE_CONTROL register.
> 
> -  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 @@ -184,6 +184,14 @@ LockFeatureControlRegisterInitialize (  {
>MSR_IA32_FEATURE_CONTROL_REGISTER*MsrRegister;
> 
> +  //
> +  // When Lock Feature Control Register feature is disabled,  // just
> + skip the MSR lock bit setting.
> +  //
> +  if (!State) {
> +return RETURN_SUCCESS;
> +  }
> +
>//
>// The scope of Lock bit in the MSR_IA32_FEATURE_CONTROL is core for
>// below processor type, only program MSR_IA32_FEATURE_CONTROL for
> thread 0 in each
> --
> 2.16.1.windows.1

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

[edk2] Soft Feature Freeze has started since Nov.1 for dk2-stable201811

2018-11-06 Thread Gao, Liming

Hi, all
  https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning 
lists edk2-stable201811 tag planning. Now, we enter into Soft Feature Freeze 
phase. In this phase, the feature under review will not be allowed to be 
pushed. The patch review can continue without break. Here is edk2-stable201811 
tag planning.
2018-08-15 Beginning of development
2018-11-01 Soft Feature Freeze
2018-11-08 Hard Feature Freeze
2018-11-15 Release

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

Re: [edk2] [PATCH v3 1/1] ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF.

2018-11-06 Thread Fu, Siyuan

Hi, Arb

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, November 7, 2018 12:39 AM
> To: Laszlo Ersek 
> Cc: Fu, Siyuan ; edk2-devel@lists.01.org; Julien
> Grall 
> Subject: Re: [PATCH v3 1/1] ArmVirtPkg: Replace obsoleted network drivers
> from platform DSC/FDF.
> 
> On 6 November 2018 at 16:24, Laszlo Ersek  wrote:
> > On 11/06/18 13:32, Ard Biesheuvel wrote:
> >> On 6 November 2018 at 02:24, Fu Siyuan  wrote:
> >>> V3:
> >>> Remove duplicate library added in v2 patch, since ArmVirtPkg.dsc.inc
> >>> already have them. Just remove the if...end there is enough.
> >>>
> >>> V2:
> >>> Add missing library instance for NetworkPkg iSCSI driver.
> >>>
> >>
> >> Please don't put the patch revision history in the commit log. Put it
> >> below the ---
> >>
> >>> This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with
> those
> >>> ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being
> actively
> >>> maintained and will be removed from edk2 master soon.
> >>>
> >>> Cc: Laszlo Ersek 
> >>> Cc: Ard Biesheuvel 
> >>> Cc: Julien Grall 
> >>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>> Signed-off-by: Fu Siyuan 
> >>> ---
> >>
> >> ... here ...
> >>
> >> The patch looks fine to me
> >>
> >> Reviewed-by: Ard Biesheuvel 
> >>
> >> but please don't merge it until after the next stable tag has been
> created
> >
> > This is not a bad idea (see also your discussion with Leif); however it
> > does create a bit of inconsistency with how the other platform DSC/FDF
> > files have been handled. (The changes have been pushed for those.)
> >
> > Again, I don't disagree, and I don't mind if ArmVirt is handled
> > differently. It's just that we should have handled this more uniformly,
> > I believe.
> >
> 
> Yes - as I replied to Leif, I am not going to obsess about this. But
> the point of stable tags is not to rush things in at the last minute.

OK I will not commit this change to ArmVirt until the stable tag is made.
Sorry for the last minute notification of this change, and I can fully
understand your concern, that's why we accepted Leif that still keep
these MdeModulePkg drivers in this stable tag.

Thanks for review.
Siyuan

> 
> >
> > In retrospect, I would have also appreciated if the patches had
> > referenced , even
> > though they only implement "prep" work for now, on the platform DSC/FDF
> > level, and not the actual driver removal.
> >
> > For example, the important explanation about MdeModulePkg's iSCSI driver
> > implementing its own MD5 algo cannot be connected to the OVMF commit now
> > (d2f1f6423bd1). I have copied the most relevant passage from the cover
> > letter of this series into TianoCore BZ#1278, but the commit in question
> > doesn't reference any BZ, so the link cannot be established.
> >
> > Thanks
> > Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 2/2] MdeModulePkg/Core: fix ineffective guard page issue

> v2: re-generate this patch per Leif's comments. No logic changes.

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

This issue originates from following patch which allows to enable
paging if PcdImageProtectionPolicy and PcdDxeNxMemoryProtectionPolicy
(in addition to PcdSetNxForStack) are set to enable related features.

  5267926134d17e86672b84fd57b438f05ffa68e1

Due to above change, PcdImageProtectionPolicy will be set to 0 by
default in many platforms, which, in turn, cause following code in
MdeModulePkg\Core\Dxe\Misc\MemoryProtection.c fail the creation of
notify event of CpuArchProtocol.

1138:  if (mImageProtectionPolicy != 0 ||
   PcdGet64 (PcdDxeNxMemoryProtectionPolicy) != 0) {
1139:  Status = CoreCreateEvent (
...
1142: MemoryProtectionCpuArchProtocolNotify,
...
1145: );

Then following call flow won't be done and Guard pages will not be
set as not-present in SetAllGuardPages() eventually.

   MemoryProtectionCpuArchProtocolNotify()
=> HeapGuardCpuArchProtocolNotify()
=> SetAllGuardPages()

The solution is removing the if(...) statement so that the notify
event will always be created and registered. This won't cause
unnecessary code execution because, in the notify event handler,
the related PCDs like

PcdImageProtectionPolicy and
PcdDxeNxMemoryProtectionPolicy

will be checked again before doing related jobs.

Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 36 +--
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
index 98fdc2c618..30798b05b9 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
@@ -1135,26 +1135,24 @@ CoreInitializeMemoryProtection (
   ASSERT (GetPermissionAttributeForMemoryType (EfiBootServicesData) ==
   GetPermissionAttributeForMemoryType (EfiConventionalMemory));
 
-  if (mImageProtectionPolicy != 0 || PcdGet64 (PcdDxeNxMemoryProtectionPolicy) 
!= 0) {
-Status = CoreCreateEvent (
-   EVT_NOTIFY_SIGNAL,
-   TPL_CALLBACK,
-   MemoryProtectionCpuArchProtocolNotify,
-   NULL,
-   
-   );
-ASSERT_EFI_ERROR(Status);
+  Status = CoreCreateEvent (
+ EVT_NOTIFY_SIGNAL,
+ TPL_CALLBACK,
+ MemoryProtectionCpuArchProtocolNotify,
+ NULL,
+ 
+ );
+  ASSERT_EFI_ERROR(Status);
 
-//
-// Register for protocol notifactions on this event
-//
-Status = CoreRegisterProtocolNotify (
-   ,
-   Event,
-   
-   );
-ASSERT_EFI_ERROR(Status);
-  }
+  //
+  // Register for protocol notifactions on this event
+  //
+  Status = CoreRegisterProtocolNotify (
+ ,
+ Event,
+ 
+ );
+  ASSERT_EFI_ERROR(Status);
 
   //
   // Register a callback to disable NULL pointer detection at EndOfDxe
-- 
2.16.2.windows.1

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

[edk2] [PATCH v2 1/2] MdeModulePkg/Core: fill logic hole in MemoryProtectionCpuArchProtocolNotify

> v2: re-generate this patch per Leif's comments. No logic changes.

At the end of of MemoryProtectionCpuArchProtocolNotify there's cleanup
code to free resource. But at line 978, 994, 1005 the function returns
directly. This patch use "goto" to replace "return" to make sure the
resource is freed before exit.

1029:  CoreCloseEvent (Event);
1030:  return;

Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
index 6298b67db1..98fdc2c618 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
@@ -975,7 +975,7 @@ MemoryProtectionCpuArchProtocolNotify (
   DEBUG ((DEBUG_INFO, "MemoryProtectionCpuArchProtocolNotify:\n"));
   Status = CoreLocateProtocol (, NULL, (VOID **));
   if (EFI_ERROR (Status)) {
-return;
+goto Done;
   }
 
   //
@@ -991,7 +991,7 @@ MemoryProtectionCpuArchProtocolNotify (
   HeapGuardCpuArchProtocolNotify ();
 
   if (mImageProtectionPolicy == 0) {
-return;
+goto Done;
   }
 
   Status = gBS->LocateHandleBuffer (
@@ -1002,7 +1002,7 @@ MemoryProtectionCpuArchProtocolNotify (
   
   );
   if (EFI_ERROR (Status) && (NoHandles == 0)) {
-return ;
+goto Done;
   }
 
   for (Index = 0; Index < NoHandles; Index++) {
@@ -1026,8 +1026,8 @@ MemoryProtectionCpuArchProtocolNotify (
 ProtectUefiImage (LoadedImage, LoadedImageDevicePath);
   }
 
+Done:
   CoreCloseEvent (Event);
-  return;
 }
 
 /**
-- 
2.16.2.windows.1

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

[edk2] [PATCH v2 0/2] *fix ineffective guard page issue

>v2: re-generate the patch per Leif's comments

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

Cc: Star Zeng 
Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Cc: Leif Lindholm 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 

Jian J Wang (2):
  MdeModulePkg/Core: fill logic hole in
MemoryProtectionCpuArchProtocolNotify
  MdeModulePkg/Core: fix ineffective guard page issue

 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 44 +--
 1 file changed, 21 insertions(+), 23 deletions(-)

-- 
2.16.2.windows.1

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

Re: [edk2] [PATCH] IntelFsp2WrapperPkg: Support FSP Dispatch mode

2018-11-06 Thread Chiu, Chasel

Hi Jiewen,

No special reason in this patch. I'm verifying the change for switching to "if" 
instead of "#if", and will re-send a new patch later.

Thanks!
Chasel


-Original Message-
From: Yao, Jiewen 
Sent: Tuesday, November 6, 2018 7:38 PM
To: Chiu, Chasel 
Cc: edk2-devel@lists.01.org; Desimone, Nathaniel L 

Subject: Re: [PATCH] IntelFsp2WrapperPkg: Support FSP Dispatch mode

hi chasel
I think our guide is not to use #if, but use if()

Is there any special reason in this patch?


thank you!
Yao, Jiewen


> 在 2018年11月6日，下午5:22，Chiu, Chasel  写道：
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1300
> 
> Provides PCD selection for FSP Wrapper to support Dispatch mode. Also 
> PcdFspmBaseAddress should support Dynamic for recovery scenario 
> (multiple FSP-M binary in flash)
> 
> Test: Verified on internal platform and both API and
>  DISPATCH modes booted successfully.
> 
> Cc: Jiewen Yao 
> Cc: Desimone Nathaniel L 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu 
> ---
> IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c   | 16 ++--
> IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c   | 14 --
> IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf |  3 ++- 
> IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf |  3 ++-
> IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec | 13 +++--
> 5 files changed, 41 insertions(+), 8 deletions(-)
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c 
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> index 7b7c5f5d86..8128a26873 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> @@ -3,7 +3,7 @@
>   register TemporaryRamDonePpi to call TempRamExit API, and register 
> MemoryDiscoveredPpi
>   notify to call FspSiliconInit API.
> 
> -  Copyright (c) 2014 - 2017, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2014 - 2018, Intel Corporation. All rights 
> + reserved.
>   This program and the accompanying materials
>   are licensed and made available under the terms and conditions of the BSD 
> License
>   which accompanies this distribution.  The full text of the license 
> may be found at @@ -65,7 +65,7 @@ PeiFspMemoryInit (
>   FspHobListPtr = NULL;
>   FspmUpdDataPtr = NULL;
> 
> -  FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32 
> (PcdFspmBaseAddress));
> +  FspmHeaderPtr = (FSP_INFO_HEADER *) FspFindFspHeader (PcdGet32 
> + (PcdFspmBaseAddress));
>   DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
>   if (FspmHeaderPtr == NULL) {
> return EFI_DEVICE_ERROR;
> @@ -155,8 +155,20 @@ FspmWrapperInit ( {
>   EFI_STATUS   Status;
> 
> +  Status = EFI_SUCCESS;
> +
> +#if FixedPcdGet8 (PcdFspModeSelection) == 1
>   Status = PeiFspMemoryInit ();
>   ASSERT_EFI_ERROR (Status);
> +#else
> +  PeiServicesInstallFvInfoPpi (
> +NULL,
> +(VOID *)(UINTN) PcdGet32 (PcdFspmBaseAddress),
> +(UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32 
> (PcdFspmBaseAddress))->FvLength,
> +NULL,
> +NULL
> +);
> +#endif
> 
>   return Status;
> }
> diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c 
> b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> index 70dac7a414..d11655df89 100644
> --- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> @@ -3,7 +3,7 @@
>   register TemporaryRamDonePpi to call TempRamExit API, and register 
> MemoryDiscoveredPpi
>   notify to call FspSiliconInit API.
> 
> -  Copyright (c) 2014 - 2017, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2014 - 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 @@ -349,7 +349,17 @@ FspsWrapperPeimEntryPoint ( {
>   DEBUG ((DEBUG_INFO, "FspsWrapperPeimEntryPoint\n"));
> 
> -  FspsWrapperInit ();
> +#if FixedPcdGet8 (PcdFspModeSelection) == 1
> +FspsWrapperInit ();
> +#else
> +PeiServicesInstallFvInfoPpi (
> +  NULL,
> +  (VOID *)(UINTN) PcdGet32 (PcdFspsBaseAddress),
> +  (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32 
> (PcdFspsBaseAddress))->FvLength,
> +  NULL,
> +  NULL
> +  );
> +#endif
> 
>   return EFI_SUCCESS;
> }
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf 
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> index 542356b582..b3776a80f3 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> @@ -6,7 +6,7 @@
> # register TemporaryRamDonePpi to call TempRamExit API, and register 
> MemoryDiscoveredPpi # notify to call FspSiliconInit API.
> #
>

Re: [edk2] [PATCH 2/2] MdeModulePkg/Core: fix ineffective guard page issue

2018-11-06 Thread Wang, Jian J

Leif,

Thanks for catching that. I'll re-generate the patch files.

Regards,
Jian

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, November 06, 2018 8:10 PM
> To: Wang, Jian J 
> Cc: edk2-devel@lists.01.org; Ni, Ruiyu ; Yao, Jiewen
> ; Zeng, Star 
> Subject: Re: [edk2] [PATCH 2/2] MdeModulePkg/Core: fix ineffective guard page
> issue
> 
> On Sat, Nov 03, 2018 at 02:42:21PM +0800, Jian J Wang wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1295
> >
> > This issue originates from following patch which allows to enable
> > paging if PcdImageProtectionPolicy and PcdDxeNxMemoryProtectionPolicy
> > (in addition to PcdSetNxForStack) are set to enable related features.
> >
> >   5267926134d17e86672b84fd57b438f05ffa68e1
> >
> > Due to above change, PcdImageProtectionPolicy will be set to 0 by
> > default in many platforms, which, in turn, cause following code in
> > MdeModulePkg\Core\Dxe\Misc\MemoryProtection.c fail the creation of
> > notify event of CpuArchProtocol.
> >
> > 1138:  if (mImageProtectionPolicy != 0 ||
> >PcdGet64 (PcdDxeNxMemoryProtectionPolicy) != 0) {
> > 1139:  Status = CoreCreateEvent (
> > ...
> > 1142: MemoryProtectionCpuArchProtocolNotify,
> > ...
> > 1145: );
> >
> > Then following call flow won't be done and Guard pages will not be
> > set as not-present in SetAllGuardPages() eventually.
> >
> >MemoryProtectionCpuArchProtocolNotify()
> > => HeapGuardCpuArchProtocolNotify()
> > => SetAllGuardPages()
> >
> > The solution is removing the if(...) statement so that the notify
> > event will always be created and handler be registered. This won't
> > cause unnecessary code execution because, in the notify event handler,
> > the related PCDs like
> >
> > PcdImageProtectionPolicy and
> > PcdDxeNxMemoryProtectionPolicy
> >
> > will be checked again to do its job.
> >
> > Cc: Star Zeng 
> > Cc: Jiewen Yao 
> > Cc: Ruiyu Ni 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > index 30e5c5153c..30798b05b9 100644
> > --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > @@ -1135,7 +1135,6 @@ CoreInitializeMemoryProtection (
> >ASSERT (GetPermissionAttributeForMemoryType (EfiBootServicesData) ==
> >GetPermissionAttributeForMemoryType (EfiConventionalMemory));
> >
> > -  if (mImageProtectionPolicy != 0 || PcdGet64
> (PcdDxeNxMemoryProtectionPolicy) != 0) {
> >Status = CoreCreateEvent (
> >   EVT_NOTIFY_SIGNAL,
> >   TPL_CALLBACK,
> > @@ -1154,7 +1153,6 @@ CoreInitializeMemoryProtection (
> >   
> >   );
> >ASSERT_EFI_ERROR(Status);
> > -  }
> 
> And here we see why.
> The indentation changes need to be part of this patch, not 1/2.
> 
> /
> Leif
> 
> >
> >//
> >// Register a callback to disable NULL pointer detection at EndOfDxe
> > --
> > 2.16.2.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 edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

On 6 November 2018 at 23:10, Kinney, Michael D
 wrote:
> Hi Ard,
>
> Can you please add CC lines to the commit message
> for the developers that have contributed to the
> edk2-staging/Intel_UNDI branch?
>
> This would include:
>
> Cc: Maciej Rabeda 

Maciej was already on cc. I hope he can forward the emails to his
colleagues, if they can't find them in the archives.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/SmmCpu: Block SMM read-out only when static paging is used

2018-11-06 Thread Yao, Jiewen

Good suggestion Laszlo. 
Current static paging will force:
1) only valid smm comm buffer is present. The OS memory is not present.
2) non smram is NX (no matter static or dynamic paging)
3) code region in Smm is RO (if pe image is page aligned)
4) data region in Smm is NX (if pe image is page aligned)

thank you!
Yao, Jiewen


> 在 2018年11月7日，上午12:13，Laszlo Ersek  写道：
> 
>> On 11/06/18 03:59, Ruiyu Ni wrote:
>> From: Jiewen Yao 
>> 
>> Today's implementation blocks SMM read-out no matter static paging
>> is enabled or not. But certain platform may need to read non-SMM
>> content from SMM code. These platforms don't have a way to disable
>> the read-out blocking.
>> 
>> The patch updates the policy to only block SMM read-out when static
>> paging is enabled. So that the static paging can be disabled for
>> those platforms that want SMM read-out.
>> 
>> Setting PcdCpuSmmStaticPageTable to FALSE can disable the static
>> paging.
>> 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Jiewen Yao 
>> Signed-off-by: Ruiyu Ni 
>> Cc: Eric Dong 
>> Cc: Jiewen Yao 
>> Cc: Laszlo Ersek 
>> ---
>> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
>> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
>> index 5bb7d57238..117502dafa 100644
>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
>> @@ -1,7 +1,7 @@
>> /** @file
>> Page Fault (#PF) handler for X64 processors
>> 
>> -Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
>> +Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
>> Copyright (c) 2017, AMD Incorporated. All rights reserved.
>> 
>> This program and the accompanying materials
>> @@ -890,7 +890,7 @@ SmiPFHandler (
>>   CpuDeadLoop ();
>> }
>> 
>> -if (IsSmmCommBufferForbiddenAddress (PFAddress)) {
>> +if (mCpuSmmStaticPageTable && IsSmmCommBufferForbiddenAddress 
>> (PFAddress)) {
>>   DumpCpuContext (InterruptType, SystemContext);
>>   DEBUG ((DEBUG_ERROR, "Access SMM communication forbidden address 
>> (0x%lx)!\n", PFAddress));
>>   DEBUG_CODE (
>> 
> 
> OVMF inherits the default TRUE value for PcdCpuSmmStaticPageTable, from
> "UefiCpuPkg.dec", and that's intentional. Therefore this patch should be
> a no-op from OVMF's perspective.
> 
> Acked-by: Laszlo Ersek 
> 
> More generally, is the use of PcdCpuSmmStaticPageTable for controlling
> this kind of read-out just a convenience / simplification (in which case
> I don't think it's great!), or are these topics inherently connected
> somehow?
> 
> I remember that Jiewen said earlier that with "static paging" enabled
> (i.e., building the page tables used in SMM all in advance), we provide
> more page protection.
> 
> Also, I see that PcdCpuSmmProfileEnable can only be enabled with
> PcdCpuSmmStaticPageTable set to FALSE.
> 
> So it seems that with PcdCpuSmmStaticPageTable set to TRUE, our page
> fault handling in SMM is generally strict(er). This patch looks
> consistent with that, but it would be nice if the commit message spelled
> out why *exactly* it makes sense to use PcdCpuSmmStaticPageTable for
> this new purpose as well.
> 
> (I hope my question makes sense. :) )
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

2018-11-06 Thread Kinney, Michael D

Hi Ard,

Can you please add CC lines to the commit message
for the developers that have contributed to the
edk2-staging/Intel_UNDI branch?

This would include:

Cc: Maciej Rabeda 
Cc: Kamil Kacperski 
Cc: Pawel Orlowski 

Thanks,

Mike


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, November 6, 2018 9:58 AM
> To: edk2-devel@lists.01.org
> Cc: Rabeda, Maciej ; Kinney,
> Michael D ; Jin, Eric
> ; leif.lindh...@linaro.org; Ard
> Biesheuvel 
> Subject: [PATCH edk2-staging 00/19]
> IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC
> 
> This series fixes the GigUndiDxe in the edk2-
> staging/Intel_UNDI branch
> at github.com/tianocore so it can be built with GCC on
> Linux for ARM
> and AARCH64 (as well as X64)
> 
> Ard Biesheuvel (19):
>   IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to
> supported
> architectures
>   IntelUndiPkg: remove EOF markers
>   IntelUndiPkg/GigUndiDxe: consistently use lowercase
> for e1000 in
> filenames
>   IntelUndiPkg/GigUndiDxe: consistently use forward
> slashes as path
> separators
>   IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration
> after type
> definition
>   IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts
> for pointers
>   IntelUndiPkg/GigUndiDxe: create GCC alternatives for
> MSFT build
> options
>   IntelUndiPkg/GigUndiDxe: add missing VOID** cast
>   IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
>   IntelUndiPkg/GigUndiDxe: add missing braces to GUID
> literals
>   IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP
> token pasting
>   IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to
> correct pointer
> type
>   IntelUndiPkg/GigUndiDxe: don't take address of cast
> expression
>   IntelUndiPkg/GigUndiDxe: redefine
> UNREFERENCED_nPARAMETER macros for
> GCC
>   IntelUndiPkg/GigUndiDxe: remove forward declaration of
> non-existent
> function
>   IntelUndiPkg/GigUndiDxe: fix incorrect indentation
>   IntelUndiPkg/GigUndiDxe: move MSFT warning overrides
> to INF file
>   IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers
>   IntelUndiPkg/GigUndiDxe: remove or reorganize unused
> variables
> 
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  |  6 ++-
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/Brand.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/ComponentName.c   |  5 ++-
>  IntelUndiPkg/GigUndiDxe/ComponentName.h   |  2 +-
>  IntelUndiPkg/GigUndiDxe/Decode.c  |  5 +--
>  IntelUndiPkg/GigUndiDxe/Decode.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   |  9 ++--
> -
>  IntelUndiPkg/GigUndiDxe/Dma.c | 11 +++-
> --
>  IntelUndiPkg/GigUndiDxe/Dma.h |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c |  6 ++-
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 12 +++-
> --
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverHealth.c|  5 ++-
>  IntelUndiPkg/GigUndiDxe/EepromConfig.c|  1 -
>  IntelUndiPkg/GigUndiDxe/EepromConfig.h|  3 +-
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 39
> +--
>  IntelUndiPkg/GigUndiDxe/Hii.c | 11 +++-
> --
>  IntelUndiPkg/GigUndiDxe/Hii.h |  1 -
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  |  3 --
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/Init.c| 11 +++-
> --
>  IntelUndiPkg/GigUndiDxe/Init.h|  1 -
>  IntelUndiPkg/GigUndiDxe/Inventory.vfr |  1 -
>  IntelUndiPkg/GigUndiDxe/NVDataStruc.h |  7 ++--
>  IntelUndiPkg/GigUndiDxe/StartStop.c   |  5 ++-
>  IntelUndiPkg/GigUndiDxe/StartStop.h   |  7 ++--
>  IntelUndiPkg/GigUndiDxe/Version.h |  1 -
>  IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c}  | 37
> --
>  IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h}  |  5 +--
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.c |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.h |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.c |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.h |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 10
> -
>  IntelUndiPkg/GigUndiDxe/e1000_hw.h|  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_i210.c  |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_i210.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c   | 18
> -
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_mac.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_mac.h   |  1 -
>

Re: [edk2] [PATCH edk2-staging 16/19] IntelUndiPkg/GigUndiDxe: fix incorrect indentation


On 6/11/18 18:58, Ard Biesheuvel wrote:

Silence a 'misleading indentation' GCC warning by fixing the
incorrect indentation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 


Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 


---
  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c 
b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
index e9fc5394ab28..6ce9ac3c5195 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
@@ -1102,13 +1102,13 @@ STATIC s32 e1000_check_for_copper_link_ich8lan(struct 
e1000_hw *hw)
if (!mac->get_link_status)
return E1000_SUCCESS;
  
-		/* First we want to see if the MII Status Register reports

-* link.  If so, then we want to get the current speed/duplex
-* of the PHY.
-*/
-   ret_val = e1000_phy_has_link_generic(hw, 1, 0, );
-   if (ret_val)
-   return ret_val;
+   /* First we want to see if the MII Status Register reports
+* link.  If so, then we want to get the current speed/duplex
+* of the PHY.
+*/
+   ret_val = e1000_phy_has_link_generic(hw, 1, 0, );
+   if (ret_val)
+   return ret_val;
  
  	if (hw->mac.type == e1000_pchlan) {

ret_val = e1000_k1_gig_workaround_hv(hw, link);


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

Re: [edk2] [PATCH edk2-staging 13/19] IntelUndiPkg/GigUndiDxe: don't take address of cast expression


On 6/11/18 18:58, Ard Biesheuvel wrote:

Taking the address of a cast expression is not permitted in C. Instead,
take the address of the variable, and cast the pointer to the desired
pointer type.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 


Reviewed-by: Philippe Mathieu-Daudé 


---
  IntelUndiPkg/GigUndiDxe/e1000.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c b/IntelUndiPkg/GigUndiDxe/e1000.c
index 4c9a06b8cf73..28c900e3ad63 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000.c
@@ -1107,7 +1107,7 @@ E1000TxRxConfigure (
// Set the MemPtr to the high dword of the rx_ring so we can store it in 
RDBAH0.
// Right shifts do not seem to work with the EFI compiler so we do it like 
this for now.
MemAddr = (UINT64) (UINTN) GigAdapter->RxRing.PhysicalAddress;
-  MemPtr  = &((UINT32) MemAddr);
+  MemPtr  = (UINT32 *)
MemPtr++;
E1000_WRITE_REG (>Hw, E1000_RDBAH (0), *MemPtr);
  
@@ -1185,7 +1185,7 @@ E1000TxRxConfigure (
  
E1000_WRITE_REG (>Hw, E1000_TDBAL (0), (UINT32) (UINTN) (GigAdapter->TxRing.PhysicalAddress));

MemAddr = (UINT64) (UINTN) GigAdapter->TxRing.PhysicalAddress;
-  MemPtr  = &((UINT32) MemAddr);
+  MemPtr  = (UINT32 *)
MemPtr++;
E1000_WRITE_REG (>Hw, E1000_TDBAH (0), *MemPtr);
DEBUGPRINT (E1000, ("TdBah0 %X\n", *MemPtr));


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

Re: [edk2] [PATCH edk2-staging 12/19] IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct pointer type


On 6/11/18 18:58, Ard Biesheuvel wrote:

E1000MemCopy () takes UINT8 pointers not INT8 pointers, so cast the
arguments to the correct type.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 


Reviewed-by: Philippe Mathieu-Daudé 


---
  IntelUndiPkg/GigUndiDxe/e1000.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c b/IntelUndiPkg/GigUndiDxe/e1000.c
index 1f08a5d67b2d..4c9a06b8cf73 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000.c
@@ -674,8 +674,8 @@ E1000Receive (
  
// Copy the packet from our list to the EFI buffer.

E1000MemCopy (
-(INT8 *) (UINTN) CpbReceive->BufferAddr,
-(INT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
+(UINT8 *) (UINTN) CpbReceive->BufferAddr,
+(UINT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
  TempLen
);
  


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

Re: [edk2] [PATCH edk2-staging 09/19] IntelUndiPkg/GigUndiDxe: add missing UINT8* cast

On 6 November 2018 at 21:31, Philippe Mathieu-Daudé  wrote:
> Hi Ard,
>
> On 6/11/18 18:58, Ard Biesheuvel wrote:
>>
>> UINT8 and CHAR8 are not the same underlying type on all architectures,
>> so add an explicit cast where necessary.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>   IntelUndiPkg/GigUndiDxe/Hii.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c b/IntelUndiPkg/GigUndiDxe/Hii.c
>> index a5d8ae207819..737a59fbbbac 100644
>> --- a/IntelUndiPkg/GigUndiDxe/Hii.c
>> +++ b/IntelUndiPkg/GigUndiDxe/Hii.c
>> @@ -817,7 +817,7 @@ HiiSetMenuStrings (
>>   Status = ReadPbaString (
>>>NicInfo,
>> - PBAString8,
>> + (UINT8 *)PBAString8,
>>MAX_PBA_STR_LENGTH
>>  );
>> if (Status == EFI_SUCCESS) {
>>
>
> I'm not sure why ReadPbaString() takes UINT8* instead of CHAR8*.
> Having the device part number stored into a CHAR8[] seems correct, what do
> you think?

I guess. But that just moves the bubble in the waterbed to elsewhere:

EFI_STATUS
ReadPbaString (
  IN GIG_DRIVER_DATA *GigAdapter,
  IN OUT UINT8 *  PbaNumber,
  IN UINT32   PbaNumberSize
  )
{
  if (e1000_read_pba_string (>Hw, PbaNumber,
PbaNumberSize) == E1000_SUCCESS) {
return EFI_SUCCESS;
  } else {
return EFI_DEVICE_ERROR;
  }
}

and

$ git grep e1000_read_pba_string
IntelUndiPkg/GigUndiDxe/e1000.c:  if (e1000_read_pba_string
(>Hw, PbaNumber, PbaNumberSize) == E1000_SUCCESS) {
IntelUndiPkg/GigUndiDxe/e1000_api.c: *  e1000_read_pba_string - Read
device part number string
IntelUndiPkg/GigUndiDxe/e1000_api.c:s32 e1000_read_pba_string(struct
e1000_hw *hw, u8 *pba_num, u32 pba_num_size)
IntelUndiPkg/GigUndiDxe/e1000_api.c:return
e1000_read_pba_string_generic(hw, pba_num, pba_num_size);
IntelUndiPkg/GigUndiDxe/e1000_api.h:s32 e1000_read_pba_string(struct
e1000_hw *hw, u8 *pba_num, u32 pba_num_size);
IntelUndiPkg/GigUndiDxe/e1000_nvm.c: *  e1000_read_pba_string_generic
- Read device part number
IntelUndiPkg/GigUndiDxe/e1000_nvm.c:s32
e1000_read_pba_string_generic(struct e1000_hw *hw, u8 *pba_num,
IntelUndiPkg/GigUndiDxe/e1000_nvm.c:
DEBUGFUNC("e1000_read_pba_string_generic");
IntelUndiPkg/GigUndiDxe/e1000_nvm.h:s32
e1000_read_pba_string_generic(struct e1000_hw *hw, u8 *pba_num,

(unless you want to add a cast in ReadPbaString() instead)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-staging 10/19] IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals


On 6/11/18 18:58, Ard Biesheuvel wrote:

The Data4 member of the GUID/EFI_GUID struct type is an array of
UINT8, so literals require two sets of { } braces. Add them where
missing.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 


Reviewed-by: Philippe Mathieu-Daudé 


---
  IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 4 ++--
  IntelUndiPkg/GigUndiDxe/StartStop.h   | 4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h 
b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
index bd7d4defc9a3..72f6a95ccb6d 100644
--- a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
+++ b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
@@ -34,12 +34,12 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
SUCH DAMAGE.
  
  #define E1000_HII_FORM_GUID \

{ \
-0x77f2ea2f, 0x4312, 0x4569, 0x85, 0xc4, 0x58, 0x3a, 0xcd, 0x8d, 0xb7, 0xe2 
\
+0x77f2ea2f, 0x4312, 0x4569, { 0x85, 0xc4, 0x58, 0x3a, 0xcd, 0x8d, 0xb7, 
0xe2 } \
}
  
  #define E1000_HII_DATA_GUID \

{ \
-0xa31abb16, 0xc627, 0x475b, 0x98, 0x8e, 0x7e, 0xe0, 0x77, 0x67, 0x40, 0xf3 
\
+0xa31abb16, 0xc627, 0x475b, { 0x98, 0x8e, 0x7e, 0xe0, 0x77, 0x67, 0x40, 
0xf3 } \
}
  
  
diff --git a/IntelUndiPkg/GigUndiDxe/StartStop.h b/IntelUndiPkg/GigUndiDxe/StartStop.h

index 255f17aabaa4..b29a5002bb8e 100644
--- a/IntelUndiPkg/GigUndiDxe/StartStop.h
+++ b/IntelUndiPkg/GigUndiDxe/StartStop.h
@@ -32,8 +32,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
  #include "e1000.h"
  
  #define EFI_DRIVER_STOP_PROTOCOL_GUID \

-{ 0x34d59603, 0x1428, 0x4429, 0xa4, 0x14, 0xe6, 0xb3, \
-0xb5, 0xfd, 0x7d, 0xc1 }
+{ 0x34d59603, 0x1428, 0x4429, { 0xa4, 0x14, 0xe6, 0xb3, \
+0xb5, 0xfd, 0x7d, 0xc1 } }
  
  typedef struct EFI_DRIVER_STOP_PROTOCOL_S  EFI_DRIVER_STOP_PROTOCOL;
  


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

Re: [edk2] [PATCH edk2-staging 09/19] IntelUndiPkg/GigUndiDxe: add missing UINT8* cast


Hi Ard,

On 6/11/18 18:58, Ard Biesheuvel wrote:

UINT8 and CHAR8 are not the same underlying type on all architectures,
so add an explicit cast where necessary.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
  IntelUndiPkg/GigUndiDxe/Hii.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c b/IntelUndiPkg/GigUndiDxe/Hii.c
index a5d8ae207819..737a59fbbbac 100644
--- a/IntelUndiPkg/GigUndiDxe/Hii.c
+++ b/IntelUndiPkg/GigUndiDxe/Hii.c
@@ -817,7 +817,7 @@ HiiSetMenuStrings (
  
Status = ReadPbaString (

   >NicInfo,
- PBAString8,
+ (UINT8 *)PBAString8,
   MAX_PBA_STR_LENGTH
 );
if (Status == EFI_SUCCESS) {



I'm not sure why ReadPbaString() takes UINT8* instead of CHAR8*.
Having the device part number stored into a CHAR8[] seems correct, what 
do you think?

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

Re: [edk2] [PATCH edk2-staging 04/19] IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path separators


On 6/11/18 18:58, Ard Biesheuvel wrote:

Replace backslashes in paths with forward slashes to be compatible with
non-Windows OSes.


I thought the Windows format expected escaped backslashes...



Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 


Reviewed-by: Philippe Mathieu-Daudé 


---
  IntelUndiPkg/GigUndiDxe/Decode.c   |  2 +-
  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf | 14 +++---
  IntelUndiPkg/GigUndiDxe/e1000_osdep.h  |  4 ++--
  3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/Decode.c b/IntelUndiPkg/GigUndiDxe/Decode.c
index 14060db0d050..9f8a5a8c1c81 100644
--- a/IntelUndiPkg/GigUndiDxe/Decode.c
+++ b/IntelUndiPkg/GigUndiDxe/Decode.c
@@ -27,7 +27,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
  
  ***/

  #include "e1000.h"
-#include 
+#include 
  
  /** This routine determines the operational state of the UNDI.  It updates the state flags in the

 Command Descriptor Block based on information derived from the GigAdapter 
instance data.
diff --git a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf 
b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
index 0e4462733df6..6c195872c00f 100644
--- a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
+++ b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
@@ -115,13 +115,13 @@ AdapterInformation.c
  AdapterInformation.h
  Version.h
  
-wol\wol.h

-wol\wol.c
-wol\wolimpl.h
-wol\wolimpl.c
-wol\wolfamily.c
-wol\wolinfo.c
-wol\wol_1G.c
+wol/wol.h
+wol/wol.c
+wol/wolimpl.h
+wol/wolimpl.c
+wol/wolfamily.c
+wol/wolinfo.c
+wol/wol_1G.c
  
  [sources.X64]

diff --git a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h

index 01c0843a2c9a..4408b409a445 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
+++ b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
@@ -31,8 +31,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
  
  #include 

  #include 
-#include 
-#include 
+#include 
+#include 
  
  #pragma warning(disable : 4244)

  #pragma warning(disable : 4206)


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

Re: [edk2] [PATCH edk2-staging 03/19] IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in filenames


On 6/11/18 18:58, Ard Biesheuvel wrote:

Rename E1000.[ch] and E1000_osdep.[ch] to all lowercase, and replace
all #include references with lowercase ones as well.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 


Reviewed-by: Philippe Mathieu-Daudé 


---
  IntelUndiPkg/GigUndiDxe/AdapterInformation.c | 2 +-
  IntelUndiPkg/GigUndiDxe/ComponentName.c  | 2 +-
  IntelUndiPkg/GigUndiDxe/Decode.c | 2 +-
  IntelUndiPkg/GigUndiDxe/DeviceSupport.h  | 2 +-
  IntelUndiPkg/GigUndiDxe/Dma.c| 2 +-
  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c| 2 +-
  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c  | 2 +-
  IntelUndiPkg/GigUndiDxe/DriverHealth.c   | 2 +-
  IntelUndiPkg/GigUndiDxe/EepromConfig.h   | 2 +-
  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf   | 8 
  IntelUndiPkg/GigUndiDxe/Init.c   | 2 +-
  IntelUndiPkg/GigUndiDxe/StartStop.c  | 2 +-
  IntelUndiPkg/GigUndiDxe/StartStop.h  | 2 +-
  IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c} | 2 +-
  IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h} | 0
  IntelUndiPkg/GigUndiDxe/{E1000_osdep.c => e1000_osdep.c} | 2 +-
  IntelUndiPkg/GigUndiDxe/{E1000_osdep.h => e1000_osdep.h} | 0
  IntelUndiPkg/GigUndiDxe/wol/wolimpl.h| 2 +-
  18 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c 
b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
index b0320b11839b..8918c538e447 100644
--- a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
+++ b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
@@ -28,7 +28,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
  ***/
  #include "Uefi.h"
  
-#include "E1000.h"

+#include "e1000.h"
  
  
  #include "AdapterInformation.h"

diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.c 
b/IntelUndiPkg/GigUndiDxe/ComponentName.c
index 1473bfbed0af..70baf00f4a5d 100644
--- a/IntelUndiPkg/GigUndiDxe/ComponentName.c
+++ b/IntelUndiPkg/GigUndiDxe/ComponentName.c
@@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY 
WAY OUT OF THE USE
  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
  ***/

-#include "E1000.h"
+#include "e1000.h"
  
  #include "ComponentName.h"

  #include "DeviceSupport.h"
diff --git a/IntelUndiPkg/GigUndiDxe/Decode.c b/IntelUndiPkg/GigUndiDxe/Decode.c
index 88e8be315bd1..14060db0d050 100644
--- a/IntelUndiPkg/GigUndiDxe/Decode.c
+++ b/IntelUndiPkg/GigUndiDxe/Decode.c
@@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY 
WAY OUT OF THE USE
  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
  ***/

-#include "E1000.h"
+#include "e1000.h"
  #include 
  
  /** This routine determines the operational state of the UNDI.  It updates the state flags in the

diff --git a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h 
b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
index f309044d9b9d..e156b587f6a7 100644
--- a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
+++ b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
@@ -29,7 +29,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
  #ifndef DEVICE_SUPPORT_H_
  #define DEVICE_SUPPORT_H_
  
-#include "E1000.h"

+#include "e1000.h"
  
  typedef struct BRAND_STRUCT_S BRAND_STRUCT;
  
diff --git a/IntelUndiPkg/GigUndiDxe/Dma.c b/IntelUndiPkg/GigUndiDxe/Dma.c

index 76a3fcf69601..bf94c1e2fd54 100644
--- a/IntelUndiPkg/GigUndiDxe/Dma.c
+++ b/IntelUndiPkg/GigUndiDxe/Dma.c
@@ -27,7 +27,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
  
  ***/
  
-#include "E1000.h"

+#include "e1000.h"
  
  #include "Dma.h"
  
diff --git a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c

index 118c1b2b9b04..20d40ab672ef 100644
--- a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
+++ b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
@@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY 
WAY OUT OF THE USE
  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
  ***/

-#include "E1000.h"
+#include "e1000.h"
  #include "DriverConfiguration.h"

  /* Protocol structure tentative definition */

diff --git a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c 
b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
index a9f176ce5324..559f2133281e 100644
--- a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
+++

Re: [edk2] [PATCH edk2-staging 02/19] IntelUndiPkg: remove EOF markers


On 6/11/18 18:58, Ard Biesheuvel wrote:

Remove the Ctrl-Z markers at the end of each file: these break the
GCC build on Linux.


Weird...



Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 


Reviewed-by: Philippe Mathieu-Daudé 


---
  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  | 1 -
  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  | 1 -
  IntelUndiPkg/GigUndiDxe/Brand.c   | 1 -
  IntelUndiPkg/GigUndiDxe/ComponentName.c   | 1 -
  IntelUndiPkg/GigUndiDxe/ComponentName.h   | 1 -
  IntelUndiPkg/GigUndiDxe/Decode.c  | 1 -
  IntelUndiPkg/GigUndiDxe/Decode.h  | 1 -
  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   | 1 -
  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   | 1 -
  IntelUndiPkg/GigUndiDxe/Dma.c | 1 -
  IntelUndiPkg/GigUndiDxe/Dma.h | 1 -
  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c | 1 -
  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h | 1 -
  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 1 -
  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   | 1 -
  IntelUndiPkg/GigUndiDxe/DriverHealth.c| 1 -
  IntelUndiPkg/GigUndiDxe/E1000.c   | 1 -
  IntelUndiPkg/GigUndiDxe/E1000.h   | 1 -
  IntelUndiPkg/GigUndiDxe/E1000_osdep.c | 1 -
  IntelUndiPkg/GigUndiDxe/E1000_osdep.h | 1 -
  IntelUndiPkg/GigUndiDxe/EepromConfig.c| 1 -
  IntelUndiPkg/GigUndiDxe/EepromConfig.h| 1 -
  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 1 -
  IntelUndiPkg/GigUndiDxe/Hii.c | 1 -
  IntelUndiPkg/GigUndiDxe/Hii.h | 1 -
  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  | 1 -
  IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  | 1 -
  IntelUndiPkg/GigUndiDxe/Init.c| 1 -
  IntelUndiPkg/GigUndiDxe/Init.h| 1 -
  IntelUndiPkg/GigUndiDxe/Inventory.vfr | 1 -
  IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 1 -
  IntelUndiPkg/GigUndiDxe/StartStop.c   | 1 -
  IntelUndiPkg/GigUndiDxe/StartStop.h   | 1 -
  IntelUndiPkg/GigUndiDxe/Version.h | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_82571.c | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_82571.h | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_82575.c | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_82575.h | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_api.c   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_api.h   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_hw.h| 1 -
  IntelUndiPkg/GigUndiDxe/e1000_i210.c  | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_i210.h  | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.h   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_mac.c   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_mac.h   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_manage.c| 1 -
  IntelUndiPkg/GigUndiDxe/e1000_manage.h| 1 -
  IntelUndiPkg/GigUndiDxe/e1000_nvm.c   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_nvm.h   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_phy.c   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_phy.h   | 1 -
  IntelUndiPkg/GigUndiDxe/e1000_regs.h  | 1 -
  IntelUndiPkg/GigUndiDxe/wol/wol.c | 1 -
  IntelUndiPkg/GigUndiDxe/wol/wol.h | 1 -
  IntelUndiPkg/GigUndiDxe/wol/wol_1G.c  | 1 -
  IntelUndiPkg/GigUndiDxe/wol/wolfamily.c   | 1 -
  IntelUndiPkg/GigUndiDxe/wol/wolimpl.c | 1 -
  IntelUndiPkg/GigUndiDxe/wol/wolimpl.h | 1 -
  IntelUndiPkg/GigUndiDxe/wol/wolinfo.c | 1 -
  IntelUndiPkg/I40eUndiDxe/AdapterInformation.c | 1 -
  IntelUndiPkg/I40eUndiDxe/AdapterInformation.h | 1 -
  IntelUndiPkg/I40eUndiDxe/Brand.c  | 1 -
  IntelUndiPkg/I40eUndiDxe/ComponentName.c  | 1 -
  IntelUndiPkg/I40eUndiDxe/ComponentName.h  | 1 -
  IntelUndiPkg/I40eUndiDxe/Decode.c | 1 -
  IntelUndiPkg/I40eUndiDxe/Decode.h | 1 -
  IntelUndiPkg/I40eUndiDxe/DeviceSupport.c  | 1 -
  IntelUndiPkg/I40eUndiDxe/DeviceSupport.h  | 1 -
  IntelUndiPkg/I40eUndiDxe/Dma.c| 1 -
  IntelUndiPkg/I40eUndiDxe/Dma.h| 1 -
  IntelUndiPkg/I40eUndiDxe/DriverDiagnostics.c  | 1 -
  IntelUndiPkg/I40eUndiDxe/DriverDiagnostics.h  | 1 -
  IntelUndiPkg/I40eUndiDxe/DriverHealth.c   | 1 -
  IntelUndiPkg/I40eUndiDxe/DriverHealthCommon.h | 1 -
  IntelUndiPkg/I40eUndiDxe/EepromConfig.c   | 1 -
  IntelUndiPkg/I40eUndiDxe/EepromConfig.h   | 1 -
  IntelUndiPkg/I40eUndiDxe/Hii.c| 1 -
  IntelUndiPkg/I40eUndiDxe/Hii.h| 1 -
  IntelUndiPkg/I40eUndiDxe/HiiInternalLib.c | 1 -
  IntelUndiPkg/I40eUndiDxe/HiiInternalLib.h | 1 -
  IntelUndiPkg/I40eUndiDxe/I40e.c   | 1 -
  IntelUndiPkg/I40eUndiDxe/I40e.h   | 1 -

[edk2] [PATCH edk2-staging 19/19] IntelUndiPkg/GigUndiDxe: remove or reorganize unused variables

Drop variables that are assigned but never used, or move them into
a conditional preprocessor block if the only references occur from
such code.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c |  2 --
 IntelUndiPkg/GigUndiDxe/HiiInternalLib.c|  2 --
 IntelUndiPkg/GigUndiDxe/e1000.c | 16 +++-
 3 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c 
b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
index f6152cd24c59..af8aaa797e68 100644
--- a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
+++ b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
@@ -1123,11 +1123,9 @@ GigUndiRunPhyLoopback (
   UINT64   FreeTxBuffer[DEFAULT_TX_DESCRIPTORS];
   UINT32   j;
   UINT32   i;
-  struct e1000_hw *Hw;
 
   Status  = EFI_SUCCESS;
   j   = 0;
-  Hw = >Hw;
 
   while (j < PHY_LOOPBACK_ITERATIONS) {
 Status = E1000Transmit (
diff --git a/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c 
b/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
index 2aacb63ca158..690d8314be74 100644
--- a/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
+++ b/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
@@ -197,7 +197,6 @@ GetNextRequestElement (
   )
 {
   EFI_STRING StringPtr;
-  EFI_STRING TmpPtr;
   EFI_STATUS Status;
   UINTN  Length;
   UINT8 *TmpBuffer;
@@ -227,7 +226,6 @@ GetNextRequestElement (
   }
 
   // Back up the header of one 
-  TmpPtr = StringPtr;
 
   StringPtr += StrLen (L"OFFSET=");
 
diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c b/IntelUndiPkg/GigUndiDxe/e1000.c
index 28c900e3ad63..3d4a21c62d77 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000.c
@@ -412,7 +412,6 @@ E1000Transmit (
   E1000_TRANSMIT_DESCRIPTOR  *TransmitDescriptor;
   UINT32  i;
   INT16   WaitMsec;
-  EFI_STATUS  Status;
   UNDI_DMA_MAPPING*TxBufMapping;
 
   TxBufMapping = >TxBufferMappings[GigAdapter->CurTxInd];
@@ -483,7 +482,7 @@ E1000Transmit (
 TxBufMapping->Size = TxBuffer->DataLen + TxBuffer->MediaheaderLen;
 
 // Make the Tx buffer accessible for adapter over DMA
-Status = UndiDmaMapMemoryRead (
+UndiDmaMapMemoryRead (
GigAdapter->PciIo,
TxBufMapping
);
@@ -594,20 +593,21 @@ E1000Receive (
   E1000_RECEIVE_DESCRIPTOR *ReceiveDescriptor;
   ETHER_HEADER *EtherHeader;
   PXE_STATCODE  StatCode;
-  UINT16i;
   UINT16TempLen;
+#if (DBG_LVL & RX)
+  UINT16i;
   UINT8 *   PacketPtr;
 #if (DBG_LVL & CRITICAL)
-#if (DBG_LVL & RX)
   UINT32 Rdh;
   UINT32 Rdt;
-#endif /* (DBG_LVL & RX) */
+
 #endif /* (DBG_LVL & CRITICAL) */
+  i   = 0;
+#endif /* (DBG_LVL & RX) */
 
 
   PacketType  = PXE_FRAME_TYPE_NONE;
   StatCode= PXE_STATCODE_NO_DATA;
-  i   = 0;
 
   // acknowledge the interrupts
   E1000_READ_REG (>Hw, E1000_ICR);
@@ -679,9 +679,9 @@ E1000Receive (
 TempLen
   );
 
+#if (DBG_LVL & RX)
   PacketPtr = (UINT8 *) (UINTN) CpbReceive->BufferAddr;
 
-#if (DBG_LVL & RX)
   DEBUGPRINT (RX, ("Packet Data \n"));
   for (i = 0; i < TempLen; i++) {
 DEBUGPRINT (RX, ("%x ", PacketPtr[i]));
@@ -1569,13 +1569,11 @@ E1000Inititialize (
   GIG_DRIVER_DATA *GigAdapter
   )
 {
-  UINT32 * TempBar;
   PXE_STATCODE PxeStatcode;
 
   DEBUGPRINT (E1000, ("E1000Inititialize\n"));
 
   PxeStatcode = PXE_STATCODE_SUCCESS;
-  TempBar = NULL;
 
   ZeroMem (
 (VOID *)(UINTN)GigAdapter->RxRing.UnmappedAddress,
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 18/19] IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/AdapterInformation.c  | 3 +++
 IntelUndiPkg/GigUndiDxe/ComponentName.c   | 2 ++
 IntelUndiPkg/GigUndiDxe/ComponentName.h   | 1 +
 IntelUndiPkg/GigUndiDxe/DriverConfiguration.c | 3 +++
 IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 1 +
 IntelUndiPkg/GigUndiDxe/DriverHealth.c| 2 ++
 IntelUndiPkg/GigUndiDxe/StartStop.c   | 2 ++
 7 files changed, 14 insertions(+)

diff --git a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c 
b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
index 8918c538e447..1cece79911b1 100644
--- a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
+++ b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
@@ -123,6 +123,7 @@ GetIpv6SupportInformationBlock (
 **/
 STATIC
 EFI_STATUS
+EFIAPI
 GetInformation (
   IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
   IN  EFI_GUID *InformationType,
@@ -188,6 +189,7 @@ GetInformation (
 **/
 STATIC
 EFI_STATUS
+EFIAPI
 SetInformation (
   IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
   IN  EFI_GUID *InformationType,
@@ -234,6 +236,7 @@ SetInformation (
 **/
 STATIC
 EFI_STATUS
+EFIAPI
 GetSupportedTypes (
   IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
   OUT EFI_GUID **   InfoTypesBuffer,
diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.c 
b/IntelUndiPkg/GigUndiDxe/ComponentName.c
index 70baf00f4a5d..2bf9bbfbe0e4 100644
--- a/IntelUndiPkg/GigUndiDxe/ComponentName.c
+++ b/IntelUndiPkg/GigUndiDxe/ComponentName.c
@@ -112,6 +112,7 @@ ComponentNameInitializeControllerName (
 language specified by Language.
 **/
 EFI_STATUS
+EFIAPI
 ComponentNameGetDriverName (
   IN  EFI_COMPONENT_NAME_PROTOCOL *This,
   IN  CHAR8 *  Language,
@@ -182,6 +183,7 @@ ComponentNameGetDriverName (
 language specified by Language.
 **/
 EFI_STATUS
+EFIAPI
 ComponentNameGetControllerName (
   IN  EFI_COMPONENT_NAME_PROTOCOL *   This,
   IN  EFI_HANDLE  
ControllerHandle,
diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.h 
b/IntelUndiPkg/GigUndiDxe/ComponentName.h
index 5a3d414c6970..0b93a5410fc0 100644
--- a/IntelUndiPkg/GigUndiDxe/ComponentName.h
+++ b/IntelUndiPkg/GigUndiDxe/ComponentName.h
@@ -65,6 +65,7 @@ ComponentNameInitializeControllerName (
 language specified by Language.
 **/
 EFI_STATUS
+EFIAPI
 ComponentNameGetDriverName (
   IN  EFI_COMPONENT_NAME_PROTOCOL *This,
   IN  CHAR8 *  Language,
diff --git a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c 
b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
index 20d40ab672ef..99e086d81044 100644
--- a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
+++ b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
@@ -310,6 +310,7 @@ GigUndiDriverConfigurationDisplayMenu (
@retval   EFI_SUCCESS   Configuration was successful
 **/
 EFI_STATUS
+EFIAPI
 GigUndiDriverConfigurationSetOptions (
   IN EFI_DRIVER_CONFIGURATION_PROTOCOL *  This,
   IN EFI_HANDLE   ControllerHandle,
@@ -418,6 +419,7 @@ GigUndiDriverConfigurationSetOptions (
@retval   EFI_SUCCESS   Always returned
 **/
 EFI_STATUS
+EFIAPI
 GigUndiDriverConfigurationOptionsValid (
   IN EFI_DRIVER_CONFIGURATION_PROTOCOL *   This,
   IN EFI_HANDLEControllerHandle,
@@ -442,6 +444,7 @@ GigUndiDriverConfigurationOptionsValid (
@retval   EFI_SUCCESS   Configuration was successful
 **/
 EFI_STATUS
+EFIAPI
 GigUndiDriverConfigurationForceDefaults (
   IN EFI_DRIVER_CONFIGURATION_PROTOCOL *   This,
   IN EFI_HANDLEControllerHandle,
diff --git a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c 
b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
index aceb015e480f..f6152cd24c59 100644
--- a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
+++ b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
@@ -1394,6 +1394,7 @@ Error:
 ChildHandle did not pass the diagnostic.
 **/
 EFI_STATUS
+EFIAPI
 GigUndiDriverDiagnosticsRunDiagnostics (
   IN EFI_DRIVER_DIAGNOSTICS_PROTOCOL *   This,
   IN EFI_HANDLE  ControllerHandle,
diff --git a/IntelUndiPkg/GigUndiDxe/DriverHealth.c 
b/IntelUndiPkg/GigUndiDxe/DriverHealth.c
index b5b7db5fd814..ea306843679a 100644
--- a/IntelUndiPkg/GigUndiDxe/DriverHealth.c
+++ b/IntelUndiPkg/GigUndiDxe/DriverHealth.c
@@ -44,6 +44,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
@retval  !EFI_SUCCESS  Failure to retrieve health status
 **/
 EFI_STATUS
+EFIAPI
 GetHealthStatus (
   IN  EFI_DRIVER_HEALTH_PROTOCOL * This,
   IN  EFI_HANDLE   ControllerHandle, OPTIONAL
@@ -119,6 +120,7 @@ GetHealthStatus (
@retval

[edk2] [PATCH edk2-staging 17/19] IntelUndiPkg/GigUndiDxe: move MSFT warning overrides to INF file

GCC chokes on the unknown MSVC specific #pragmas used for suppressing
warnings, so remove them and use the INF BuildOptions section instead.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf | 2 +-
 IntelUndiPkg/GigUndiDxe/e1000_osdep.h  | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf 
b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
index 19dae9a0987a..9159e826ec45 100644
--- a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
+++ b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
@@ -41,7 +41,7 @@ ENTRY_POINT  = InitializeGigUNDIDriver
 UNLOAD_IMAGE = GigUndiUnload
 
 [BuildOptions.common]
-  MSFT:*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG
+  MSFT:*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG /wd4244 /wd4206
   GCC:RELEASE_*_*_CC_FLAGS = -D MDEPKG_NDEBUG
 
 [BuildOptions.X64]
diff --git a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h 
b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
index 4408b409a445..70f33811dd04 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
+++ b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
@@ -34,9 +34,6 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
 #include 
 #include 
 
-#pragma warning(disable : 4244)
-#pragma warning(disable : 4206)
-
 #ifndef EFI_SPECIFICATION_VERSION
 #define EFI_SPECIFICATION_VERSION 0x0002
 #endif /* EFI_SPECIFICATION_VERSION */
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 14/19] IntelUndiPkg/GigUndiDxe: redefine UNREFERENCED_nPARAMETER macros for GCC

Use (VOID) casts to silence unreferenced parameter warnings on GCC. The
existing macros generate 'statement with no effect' warnings instead,
which does not really help.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/e1000_defines.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/IntelUndiPkg/GigUndiDxe/e1000_defines.h 
b/IntelUndiPkg/GigUndiDxe/e1000_defines.h
index 1d07d30aa18e..b9ce1e5e6339 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000_defines.h
+++ b/IntelUndiPkg/GigUndiDxe/e1000_defines.h
@@ -1622,12 +1622,19 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
SUCH DAMAGE.
 
 #endif /* NO_82575_SUPPORT */
 #ifndef UNREFERENCED_XPARAMETER
-#define UNREFERENCED_XPARAMETER
+#ifdef _MSC_VER
 #define UNREFERENCED_1PARAMETER(_p) (_p)
 #define UNREFERENCED_2PARAMETER(_p, _q) (_p); (_q);
 #define UNREFERENCED_3PARAMETER(_p, _q, _r) (_p); (_q); (_r);
 #define UNREFERENCED_4PARAMETER(_p, _q, _r, _s) (_p); (_q); (_r); (_s);
 #define UNREFERENCED_5PARAMETER(_p, _q, _r, _s, _t) (_p); (_q); (_r); (_s); 
(_t);
+#else
+#define UNREFERENCED_1PARAMETER(_p) (VOID)(_p)
+#define UNREFERENCED_2PARAMETER(_p, _q) (VOID)(_p); (VOID)(_q);
+#define UNREFERENCED_3PARAMETER(_p, _q, _r) (VOID)(_p); (VOID)(_q); (VOID)(_r);
+#define UNREFERENCED_4PARAMETER(_p, _q, _r, _s) (VOID)(_p); (VOID)(_q); 
(VOID)(_r); (VOID)(_s);
+#define UNREFERENCED_5PARAMETER(_p, _q, _r, _s, _t) (VOID)(_p); (VOID)(_q); 
(VOID)(_r); (VOID)(_s); (VOID)(_t);
+#endif
 #endif /* UNREFERENCED_XPARAMETER */
 #ifndef E1000_UNUSEDARG
 #define E1000_UNUSEDARG
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 13/19] IntelUndiPkg/GigUndiDxe: don't take address of cast expression

Taking the address of a cast expression is not permitted in C. Instead,
take the address of the variable, and cast the pointer to the desired
pointer type.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/e1000.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c b/IntelUndiPkg/GigUndiDxe/e1000.c
index 4c9a06b8cf73..28c900e3ad63 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000.c
@@ -1107,7 +1107,7 @@ E1000TxRxConfigure (
   // Set the MemPtr to the high dword of the rx_ring so we can store it in 
RDBAH0.
   // Right shifts do not seem to work with the EFI compiler so we do it like 
this for now.
   MemAddr = (UINT64) (UINTN) GigAdapter->RxRing.PhysicalAddress;
-  MemPtr  = &((UINT32) MemAddr);
+  MemPtr  = (UINT32 *)
   MemPtr++;
   E1000_WRITE_REG (>Hw, E1000_RDBAH (0), *MemPtr);
 
@@ -1185,7 +1185,7 @@ E1000TxRxConfigure (
 
   E1000_WRITE_REG (>Hw, E1000_TDBAL (0), (UINT32) (UINTN) 
(GigAdapter->TxRing.PhysicalAddress));
   MemAddr = (UINT64) (UINTN) GigAdapter->TxRing.PhysicalAddress;
-  MemPtr  = &((UINT32) MemAddr);
+  MemPtr  = (UINT32 *)
   MemPtr++;
   E1000_WRITE_REG (>Hw, E1000_TDBAH (0), *MemPtr);
   DEBUGPRINT (E1000, ("TdBah0 %X\n", *MemPtr));
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 15/19] IntelUndiPkg/GigUndiDxe: remove forward declaration of non-existent function

Remove the forward declaration of e1000_disable_ulp_lpt_lp (), which
is never defined anywhere in the code.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c 
b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
index 7669630a5c03..e9fc5394ab28 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
@@ -103,9 +103,6 @@ STATIC s32  e1000_reset_hw_ich8lan(struct e1000_hw *hw);
 STATIC s32  e1000_init_hw_ich8lan(struct e1000_hw *hw);
 STATIC s32  e1000_setup_link_ich8lan(struct e1000_hw *hw);
 STATIC s32  e1000_setup_copper_link_ich8lan(struct e1000_hw *hw);
-#if !defined(NO_ULP_IN_S5_SUPPORT) 
-STATIC s32 e1000_disable_ulp_lpt_lp(struct e1000_hw *hw, bool force);
-#endif /* !NO_ULP_IN_S5_SUPPORT && !ULP_IN_D0_SUPPORT */
 STATIC s32  e1000_setup_copper_link_pch_lpt(struct e1000_hw *hw);
 STATIC s32  e1000_get_link_up_info_ich8lan(struct e1000_hw *hw,
   u16 *speed, u16 *duplex);
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 16/19] IntelUndiPkg/GigUndiDxe: fix incorrect indentation

Silence a 'misleading indentation' GCC warning by fixing the
incorrect indentation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c 
b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
index e9fc5394ab28..6ce9ac3c5195 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
@@ -1102,13 +1102,13 @@ STATIC s32 e1000_check_for_copper_link_ich8lan(struct 
e1000_hw *hw)
if (!mac->get_link_status)
return E1000_SUCCESS;
 
-   /* First we want to see if the MII Status Register reports
-* link.  If so, then we want to get the current speed/duplex
-* of the PHY.
-*/
-   ret_val = e1000_phy_has_link_generic(hw, 1, 0, );
-   if (ret_val)
-   return ret_val;
+   /* First we want to see if the MII Status Register reports
+* link.  If so, then we want to get the current speed/duplex
+* of the PHY.
+*/
+   ret_val = e1000_phy_has_link_generic(hw, 1, 0, );
+   if (ret_val)
+   return ret_val;
 
if (hw->mac.type == e1000_pchlan) {
ret_val = e1000_k1_gig_workaround_hv(hw, link);
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 12/19] IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct pointer type

E1000MemCopy () takes UINT8 pointers not INT8 pointers, so cast the
arguments to the correct type.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/e1000.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c b/IntelUndiPkg/GigUndiDxe/e1000.c
index 1f08a5d67b2d..4c9a06b8cf73 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000.c
@@ -674,8 +674,8 @@ E1000Receive (
 
   // Copy the packet from our list to the EFI buffer.
   E1000MemCopy (
-(INT8 *) (UINTN) CpbReceive->BufferAddr,
-(INT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
+(UINT8 *) (UINTN) CpbReceive->BufferAddr,
+(UINT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
 TempLen
   );
 
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 04/19] IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path separators

Replace backslashes in paths with forward slashes to be compatible with
non-Windows OSes.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/Decode.c   |  2 +-
 IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf | 14 +++---
 IntelUndiPkg/GigUndiDxe/e1000_osdep.h  |  4 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/Decode.c b/IntelUndiPkg/GigUndiDxe/Decode.c
index 14060db0d050..9f8a5a8c1c81 100644
--- a/IntelUndiPkg/GigUndiDxe/Decode.c
+++ b/IntelUndiPkg/GigUndiDxe/Decode.c
@@ -27,7 +27,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
 
 ***/
 #include "e1000.h"
-#include 
+#include 
 
 /** This routine determines the operational state of the UNDI.  It updates the 
state flags in the
Command Descriptor Block based on information derived from the GigAdapter 
instance data.
diff --git a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf 
b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
index 0e4462733df6..6c195872c00f 100644
--- a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
+++ b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
@@ -115,13 +115,13 @@ AdapterInformation.c
 AdapterInformation.h
 Version.h
 
-wol\wol.h
-wol\wol.c
-wol\wolimpl.h
-wol\wolimpl.c
-wol\wolfamily.c
-wol\wolinfo.c
-wol\wol_1G.c
+wol/wol.h
+wol/wol.c
+wol/wolimpl.h
+wol/wolimpl.c
+wol/wolfamily.c
+wol/wolinfo.c
+wol/wol_1G.c
 
 [sources.X64]
   
diff --git a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h 
b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
index 01c0843a2c9a..4408b409a445 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
+++ b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
@@ -31,8 +31,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 
 #pragma warning(disable : 4244)
 #pragma warning(disable : 4206)
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 07/19] IntelUndiPkg/GigUndiDxe: create GCC alternatives for MSFT build options

Prefix the existing MSFT only build option overrides with MSFT: and
create the GCC: counterparts so we can build this code with GCC as
well.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf 
b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
index 6c195872c00f..19dae9a0987a 100644
--- a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
+++ b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
@@ -41,20 +41,20 @@ ENTRY_POINT  = InitializeGigUNDIDriver
 UNLOAD_IMAGE = GigUndiUnload
 
 [BuildOptions.common]
-
-*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG
+  MSFT:*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG
+  GCC:RELEASE_*_*_CC_FLAGS = -D MDEPKG_NDEBUG
 
 [BuildOptions.X64]
-
-*_*_*_CC_FLAGS = /D EFIX64 
+  MSFT:*_*_*_CC_FLAGS = /D EFIX64
+  GCC:*_*_*_CC_FLAGS = -D EFIX64
 
 [BuildOptions.IPF]
-
-*_*_*_CC_FLAGS = /D EFI64
+  MSFT:*_*_*_CC_FLAGS = /D EFI64
+  GCC:*_*_*_CC_FLAGS = -D EFI64
 
 [BuildOptions.IA32]
-
-*_*_*_CC_FLAGS = /D EFI32
+  MSFT:*_*_*_CC_FLAGS = /D EFI32
+  GCC:*_*_*_CC_FLAGS = -D EFI32
 
 [sources.common]
 InventoryStrings.uni
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 05/19] IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration after type definition

Move the extern declaration of mBrandingTable[] after the definition of
the type. This solves a build issue with GCC.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/DeviceSupport.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h 
b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
index e156b587f6a7..e2b730131f8e 100644
--- a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
+++ b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
@@ -33,9 +33,6 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
 
 typedef struct BRAND_STRUCT_S BRAND_STRUCT;
 
-extern BRAND_STRUCT mBrandingTable[];
-extern UINTNmBrandingTableSize;
-
 /* Defines */
 #define INVALID_VENDOR_ID 0x
 #define INVALID_SUBVENDOR_ID  0x
@@ -53,6 +50,9 @@ struct BRAND_STRUCT_S {
   CHAR16 *BrandString;
 };
 
+extern BRAND_STRUCT mBrandingTable[];
+extern UINTNmBrandingTableSize;
+
 /* Function declarations */
 
 /** Returns pointer to current device's branding string (looks for best match)
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 08/19] IntelUndiPkg/GigUndiDxe: add missing VOID** cast

Unlike Visual Studio, GCC does not permit implicit conversion between
a pointer-to-void-pointer and pointer to a typed pointer. So add the
explicit casts where necessary.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/Hii.c  | 8 
 IntelUndiPkg/GigUndiDxe/Init.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c b/IntelUndiPkg/GigUndiDxe/Hii.c
index 43c184cb03c8..a5d8ae207819 100644
--- a/IntelUndiPkg/GigUndiDxe/Hii.c
+++ b/IntelUndiPkg/GigUndiDxe/Hii.c
@@ -459,7 +459,7 @@ HiiOpenProtocol (
   Status = gBS->LocateProtocol (
   ,
   NULL,
-  >HiiDatabase
+  (VOID **)>HiiDatabase
 );
   if (EFI_ERROR (Status)) {
 DEBUGPRINT (CRITICAL, ("Error finding HII protocol: %r\n", Status));
@@ -472,7 +472,7 @@ HiiOpenProtocol (
   Status = gBS->LocateProtocol (
   ,
   NULL,
-  >HiiString
+  (VOID **)>HiiString
 );
   if (EFI_ERROR (Status)) {
 DEBUGPRINT (CRITICAL, ("Error finding HII String protocol: %r\n", Status));
@@ -485,7 +485,7 @@ HiiOpenProtocol (
   Status = gBS->LocateProtocol (
   ,
   NULL,
-  >FormBrowser2
+  (VOID **)>FormBrowser2
 );
   if (EFI_ERROR (Status)) {
 DEBUGPRINT (CRITICAL, ("Error finding HII form browser protocol: %r\n", 
Status));
@@ -498,7 +498,7 @@ HiiOpenProtocol (
   Status = gBS->LocateProtocol (
   ,
   NULL,
-  >HiiConfigRouting
+  (VOID **)>HiiConfigRouting
 );
   if (EFI_ERROR (Status)) {
 DEBUGPRINT (CRITICAL, ("Error finding HII ConfigRouting protocol: %r\n", 
Status));
diff --git a/IntelUndiPkg/GigUndiDxe/Init.c b/IntelUndiPkg/GigUndiDxe/Init.c
index f99734d72823..1de424c26fe2 100644
--- a/IntelUndiPkg/GigUndiDxe/Init.c
+++ b/IntelUndiPkg/GigUndiDxe/Init.c
@@ -177,7 +177,7 @@ GigAppendMac2DevPath (
   Status = gBS->AllocatePool (
   EfiBootServicesData, // EfiRuntimeServicesData,
   TotalPathLen,
-  
+  (VOID **)
 );
 
   if (Status != EFI_SUCCESS) {
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 11/19] IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP token pasting

The ## CPP token pasting operator is used to paste *tokens*, which
is not the same thing as pasting arbitrary macro arguments. Since a
token cannot contain . or ) characters in the first place, using
the ## operator here is wrong and unnecessary, so just remove it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h 
b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
index 72f6a95ccb6d..04f08b41c842 100644
--- a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
+++ b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
@@ -112,7 +112,7 @@ typedef struct {
 
@return   Width of given field is returned
 **/
-#define UNDI_CONFIG_WIDTH(Field) sizeof (UndiPrivateData->Configuration. ## 
Field ## )
+#define UNDI_CONFIG_WIDTH(Field) sizeof (UndiPrivateData->Configuration.Field)
 
 // General parameters
 #define QUESTION_ID_EFI_DRIVER_VER  0x1100
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 03/19] IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in filenames

Rename E1000.[ch] and E1000_osdep.[ch] to all lowercase, and replace
all #include references with lowercase ones as well.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/AdapterInformation.c | 2 +-
 IntelUndiPkg/GigUndiDxe/ComponentName.c  | 2 +-
 IntelUndiPkg/GigUndiDxe/Decode.c | 2 +-
 IntelUndiPkg/GigUndiDxe/DeviceSupport.h  | 2 +-
 IntelUndiPkg/GigUndiDxe/Dma.c| 2 +-
 IntelUndiPkg/GigUndiDxe/DriverConfiguration.c| 2 +-
 IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c  | 2 +-
 IntelUndiPkg/GigUndiDxe/DriverHealth.c   | 2 +-
 IntelUndiPkg/GigUndiDxe/EepromConfig.h   | 2 +-
 IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf   | 8 
 IntelUndiPkg/GigUndiDxe/Init.c   | 2 +-
 IntelUndiPkg/GigUndiDxe/StartStop.c  | 2 +-
 IntelUndiPkg/GigUndiDxe/StartStop.h  | 2 +-
 IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c} | 2 +-
 IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h} | 0
 IntelUndiPkg/GigUndiDxe/{E1000_osdep.c => e1000_osdep.c} | 2 +-
 IntelUndiPkg/GigUndiDxe/{E1000_osdep.h => e1000_osdep.h} | 0
 IntelUndiPkg/GigUndiDxe/wol/wolimpl.h| 2 +-
 18 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c 
b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
index b0320b11839b..8918c538e447 100644
--- a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
+++ b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
@@ -28,7 +28,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
 ***/
 #include "Uefi.h"
 
-#include "E1000.h"
+#include "e1000.h"
 
 
 #include "AdapterInformation.h"
diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.c 
b/IntelUndiPkg/GigUndiDxe/ComponentName.c
index 1473bfbed0af..70baf00f4a5d 100644
--- a/IntelUndiPkg/GigUndiDxe/ComponentName.c
+++ b/IntelUndiPkg/GigUndiDxe/ComponentName.c
@@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY 
WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 ***/
-#include "E1000.h"
+#include "e1000.h"
 
 #include "ComponentName.h"
 #include "DeviceSupport.h"
diff --git a/IntelUndiPkg/GigUndiDxe/Decode.c b/IntelUndiPkg/GigUndiDxe/Decode.c
index 88e8be315bd1..14060db0d050 100644
--- a/IntelUndiPkg/GigUndiDxe/Decode.c
+++ b/IntelUndiPkg/GigUndiDxe/Decode.c
@@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY 
WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 ***/
-#include "E1000.h"
+#include "e1000.h"
 #include 
 
 /** This routine determines the operational state of the UNDI.  It updates the 
state flags in the
diff --git a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h 
b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
index f309044d9b9d..e156b587f6a7 100644
--- a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
+++ b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
@@ -29,7 +29,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
 #ifndef DEVICE_SUPPORT_H_
 #define DEVICE_SUPPORT_H_
 
-#include "E1000.h"
+#include "e1000.h"
 
 typedef struct BRAND_STRUCT_S BRAND_STRUCT;
 
diff --git a/IntelUndiPkg/GigUndiDxe/Dma.c b/IntelUndiPkg/GigUndiDxe/Dma.c
index 76a3fcf69601..bf94c1e2fd54 100644
--- a/IntelUndiPkg/GigUndiDxe/Dma.c
+++ b/IntelUndiPkg/GigUndiDxe/Dma.c
@@ -27,7 +27,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
 
 ***/
 
-#include "E1000.h"
+#include "e1000.h"
 
 #include "Dma.h"
 
diff --git a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c 
b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
index 118c1b2b9b04..20d40ab672ef 100644
--- a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
+++ b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
@@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY 
WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 ***/
-#include "E1000.h"
+#include "e1000.h"
 #include "DriverConfiguration.h"
   
 /* Protocol structure tentative definition */  
diff --git a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c 
b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
index a9f176ce5324..559f2133281e 100644
--- a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
+++ b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
@@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY 
WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF

[edk2] [PATCH edk2-staging 09/19] IntelUndiPkg/GigUndiDxe: add missing UINT8* cast

UINT8 and CHAR8 are not the same underlying type on all architectures,
so add an explicit cast where necessary.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/Hii.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c b/IntelUndiPkg/GigUndiDxe/Hii.c
index a5d8ae207819..737a59fbbbac 100644
--- a/IntelUndiPkg/GigUndiDxe/Hii.c
+++ b/IntelUndiPkg/GigUndiDxe/Hii.c
@@ -817,7 +817,7 @@ HiiSetMenuStrings (
 
   Status = ReadPbaString (
  >NicInfo,
- PBAString8,
+ (UINT8 *)PBAString8,
  MAX_PBA_STR_LENGTH
);
   if (Status == EFI_SUCCESS) {
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 10/19] IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals

The Data4 member of the GUID/EFI_GUID struct type is an array of
UINT8, so literals require two sets of { } braces. Add them where
missing.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 4 ++--
 IntelUndiPkg/GigUndiDxe/StartStop.h   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h 
b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
index bd7d4defc9a3..72f6a95ccb6d 100644
--- a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
+++ b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
@@ -34,12 +34,12 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
SUCH DAMAGE.
 
 #define E1000_HII_FORM_GUID \
   { \
-0x77f2ea2f, 0x4312, 0x4569, 0x85, 0xc4, 0x58, 0x3a, 0xcd, 0x8d, 0xb7, 0xe2 
\
+0x77f2ea2f, 0x4312, 0x4569, { 0x85, 0xc4, 0x58, 0x3a, 0xcd, 0x8d, 0xb7, 
0xe2 } \
   }
 
 #define E1000_HII_DATA_GUID \
   { \
-0xa31abb16, 0xc627, 0x475b, 0x98, 0x8e, 0x7e, 0xe0, 0x77, 0x67, 0x40, 0xf3 
\
+0xa31abb16, 0xc627, 0x475b, { 0x98, 0x8e, 0x7e, 0xe0, 0x77, 0x67, 0x40, 
0xf3 } \
   }
 
 
diff --git a/IntelUndiPkg/GigUndiDxe/StartStop.h 
b/IntelUndiPkg/GigUndiDxe/StartStop.h
index 255f17aabaa4..b29a5002bb8e 100644
--- a/IntelUndiPkg/GigUndiDxe/StartStop.h
+++ b/IntelUndiPkg/GigUndiDxe/StartStop.h
@@ -32,8 +32,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
 #include "e1000.h"
 
 #define EFI_DRIVER_STOP_PROTOCOL_GUID \
-{ 0x34d59603, 0x1428, 0x4429, 0xa4, 0x14, 0xe6, 0xb3, \
-0xb5, 0xfd, 0x7d, 0xc1 }
+{ 0x34d59603, 0x1428, 0x4429, { 0xa4, 0x14, 0xe6, 0xb3, \
+0xb5, 0xfd, 0x7d, 0xc1 } }
 
 typedef struct EFI_DRIVER_STOP_PROTOCOL_S  EFI_DRIVER_STOP_PROTOCOL;
 
-- 
2.19.1

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

[edk2] [PATCH edk2-staging 02/19] IntelUndiPkg: remove EOF markers

Remove the Ctrl-Z markers at the end of each file: these break the
GCC build on Linux.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/GigUndiDxe/AdapterInformation.c  | 1 -
 IntelUndiPkg/GigUndiDxe/AdapterInformation.h  | 1 -
 IntelUndiPkg/GigUndiDxe/Brand.c   | 1 -
 IntelUndiPkg/GigUndiDxe/ComponentName.c   | 1 -
 IntelUndiPkg/GigUndiDxe/ComponentName.h   | 1 -
 IntelUndiPkg/GigUndiDxe/Decode.c  | 1 -
 IntelUndiPkg/GigUndiDxe/Decode.h  | 1 -
 IntelUndiPkg/GigUndiDxe/DeviceSupport.c   | 1 -
 IntelUndiPkg/GigUndiDxe/DeviceSupport.h   | 1 -
 IntelUndiPkg/GigUndiDxe/Dma.c | 1 -
 IntelUndiPkg/GigUndiDxe/Dma.h | 1 -
 IntelUndiPkg/GigUndiDxe/DriverConfiguration.c | 1 -
 IntelUndiPkg/GigUndiDxe/DriverConfiguration.h | 1 -
 IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 1 -
 IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   | 1 -
 IntelUndiPkg/GigUndiDxe/DriverHealth.c| 1 -
 IntelUndiPkg/GigUndiDxe/E1000.c   | 1 -
 IntelUndiPkg/GigUndiDxe/E1000.h   | 1 -
 IntelUndiPkg/GigUndiDxe/E1000_osdep.c | 1 -
 IntelUndiPkg/GigUndiDxe/E1000_osdep.h | 1 -
 IntelUndiPkg/GigUndiDxe/EepromConfig.c| 1 -
 IntelUndiPkg/GigUndiDxe/EepromConfig.h| 1 -
 IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 1 -
 IntelUndiPkg/GigUndiDxe/Hii.c | 1 -
 IntelUndiPkg/GigUndiDxe/Hii.h | 1 -
 IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  | 1 -
 IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  | 1 -
 IntelUndiPkg/GigUndiDxe/Init.c| 1 -
 IntelUndiPkg/GigUndiDxe/Init.h| 1 -
 IntelUndiPkg/GigUndiDxe/Inventory.vfr | 1 -
 IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 1 -
 IntelUndiPkg/GigUndiDxe/StartStop.c   | 1 -
 IntelUndiPkg/GigUndiDxe/StartStop.h   | 1 -
 IntelUndiPkg/GigUndiDxe/Version.h | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_82571.c | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_82571.h | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_82575.c | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_82575.h | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_api.c   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_api.h   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_hw.h| 1 -
 IntelUndiPkg/GigUndiDxe/e1000_i210.c  | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_i210.h  | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_ich8lan.h   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_mac.c   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_mac.h   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_manage.c| 1 -
 IntelUndiPkg/GigUndiDxe/e1000_manage.h| 1 -
 IntelUndiPkg/GigUndiDxe/e1000_nvm.c   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_nvm.h   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_phy.c   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_phy.h   | 1 -
 IntelUndiPkg/GigUndiDxe/e1000_regs.h  | 1 -
 IntelUndiPkg/GigUndiDxe/wol/wol.c | 1 -
 IntelUndiPkg/GigUndiDxe/wol/wol.h | 1 -
 IntelUndiPkg/GigUndiDxe/wol/wol_1G.c  | 1 -
 IntelUndiPkg/GigUndiDxe/wol/wolfamily.c   | 1 -
 IntelUndiPkg/GigUndiDxe/wol/wolimpl.c | 1 -
 IntelUndiPkg/GigUndiDxe/wol/wolimpl.h | 1 -
 IntelUndiPkg/GigUndiDxe/wol/wolinfo.c | 1 -
 IntelUndiPkg/I40eUndiDxe/AdapterInformation.c | 1 -
 IntelUndiPkg/I40eUndiDxe/AdapterInformation.h | 1 -
 IntelUndiPkg/I40eUndiDxe/Brand.c  | 1 -
 IntelUndiPkg/I40eUndiDxe/ComponentName.c  | 1 -
 IntelUndiPkg/I40eUndiDxe/ComponentName.h  | 1 -
 IntelUndiPkg/I40eUndiDxe/Decode.c | 1 -
 IntelUndiPkg/I40eUndiDxe/Decode.h | 1 -
 IntelUndiPkg/I40eUndiDxe/DeviceSupport.c  | 1 -
 IntelUndiPkg/I40eUndiDxe/DeviceSupport.h  | 1 -
 IntelUndiPkg/I40eUndiDxe/Dma.c| 1 -
 IntelUndiPkg/I40eUndiDxe/Dma.h| 1 -
 IntelUndiPkg/I40eUndiDxe/DriverDiagnostics.c  | 1 -
 IntelUndiPkg/I40eUndiDxe/DriverDiagnostics.h  | 1 -
 IntelUndiPkg/I40eUndiDxe/DriverHealth.c   | 1 -
 IntelUndiPkg/I40eUndiDxe/DriverHealthCommon.h | 1 -
 IntelUndiPkg/I40eUndiDxe/EepromConfig.c   | 1 -
 IntelUndiPkg/I40eUndiDxe/EepromConfig.h   | 1 -
 IntelUndiPkg/I40eUndiDxe/Hii.c| 1 -
 IntelUndiPkg/I40eUndiDxe/Hii.h| 1 -
 IntelUndiPkg/I40eUndiDxe/HiiInternalLib.c | 1 -
 IntelUndiPkg/I40eUndiDxe/HiiInternalLib.h | 1 -
 IntelUndiPkg/I40eUndiDxe/I40e.c   | 1 -
 IntelUndiPkg/I40eUndiDxe/I40e.h   | 1 -
 IntelUndiPkg/I40eUndiDxe/I40eUndiDxe.inf  | 1 -
 IntelUndiPkg/I40eUndiDxe/I40e_osdep.h | 1 -
 IntelUndiPkg/I40eUndiDxe/Init.c   | 1 -
 IntelUndiPkg/I40eUndiDxe/Init.h   |

[edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

This series fixes the GigUndiDxe in the edk2-staging/Intel_UNDI branch
at github.com/tianocore so it can be built with GCC on Linux for ARM
and AARCH64 (as well as X64)

Ard Biesheuvel (19):
  IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported
architectures
  IntelUndiPkg: remove EOF markers
  IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in
filenames
  IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path
separators
  IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration after type
definition
  IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts for pointers
  IntelUndiPkg/GigUndiDxe: create GCC alternatives for MSFT build
options
  IntelUndiPkg/GigUndiDxe: add missing VOID** cast
  IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
  IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals
  IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP token pasting
  IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct pointer
type
  IntelUndiPkg/GigUndiDxe: don't take address of cast expression
  IntelUndiPkg/GigUndiDxe: redefine UNREFERENCED_nPARAMETER macros for
GCC
  IntelUndiPkg/GigUndiDxe: remove forward declaration of non-existent
function
  IntelUndiPkg/GigUndiDxe: fix incorrect indentation
  IntelUndiPkg/GigUndiDxe: move MSFT warning overrides to INF file
  IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers
  IntelUndiPkg/GigUndiDxe: remove or reorganize unused variables

 IntelUndiPkg/GigUndiDxe/AdapterInformation.c  |  6 ++-
 IntelUndiPkg/GigUndiDxe/AdapterInformation.h  |  1 -
 IntelUndiPkg/GigUndiDxe/Brand.c   |  1 -
 IntelUndiPkg/GigUndiDxe/ComponentName.c   |  5 ++-
 IntelUndiPkg/GigUndiDxe/ComponentName.h   |  2 +-
 IntelUndiPkg/GigUndiDxe/Decode.c  |  5 +--
 IntelUndiPkg/GigUndiDxe/Decode.h  |  1 -
 IntelUndiPkg/GigUndiDxe/DeviceSupport.c   |  1 -
 IntelUndiPkg/GigUndiDxe/DeviceSupport.h   |  9 ++---
 IntelUndiPkg/GigUndiDxe/Dma.c | 11 +++---
 IntelUndiPkg/GigUndiDxe/Dma.h |  1 -
 IntelUndiPkg/GigUndiDxe/DriverConfiguration.c |  6 ++-
 IntelUndiPkg/GigUndiDxe/DriverConfiguration.h |  1 -
 IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 12 +++---
 IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   |  1 -
 IntelUndiPkg/GigUndiDxe/DriverHealth.c|  5 ++-
 IntelUndiPkg/GigUndiDxe/EepromConfig.c|  1 -
 IntelUndiPkg/GigUndiDxe/EepromConfig.h|  3 +-
 IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 39 +--
 IntelUndiPkg/GigUndiDxe/Hii.c | 11 +++---
 IntelUndiPkg/GigUndiDxe/Hii.h |  1 -
 IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  |  3 --
 IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  |  1 -
 IntelUndiPkg/GigUndiDxe/Init.c| 11 +++---
 IntelUndiPkg/GigUndiDxe/Init.h|  1 -
 IntelUndiPkg/GigUndiDxe/Inventory.vfr |  1 -
 IntelUndiPkg/GigUndiDxe/NVDataStruc.h |  7 ++--
 IntelUndiPkg/GigUndiDxe/StartStop.c   |  5 ++-
 IntelUndiPkg/GigUndiDxe/StartStop.h   |  7 ++--
 IntelUndiPkg/GigUndiDxe/Version.h |  1 -
 IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c}  | 37 --
 IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h}  |  5 +--
 IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_82571.c |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_82571.h |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_82575.c |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_82575.h |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_api.c   |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_api.h   |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 10 -
 IntelUndiPkg/GigUndiDxe/e1000_hw.h|  1 -
 IntelUndiPkg/GigUndiDxe/e1000_i210.c  |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_i210.h  |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c   | 18 -
 IntelUndiPkg/GigUndiDxe/e1000_ich8lan.h   |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_mac.c   |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_mac.h   |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_manage.c|  1 -
 IntelUndiPkg/GigUndiDxe/e1000_manage.h|  1 -
 IntelUndiPkg/GigUndiDxe/e1000_nvm.c   |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_nvm.h   |  1 -
 .../{E1000_osdep.c => e1000_osdep.c}  |  3 +-
 .../{E1000_osdep.h => e1000_osdep.h}  |  8 +---
 IntelUndiPkg/GigUndiDxe/e1000_phy.c   |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_phy.h   |  1 -
 IntelUndiPkg/GigUndiDxe/e1000_regs.h  |  1 -
 IntelUndiPkg/GigUndiDxe/wol/wol.c |  1 -
 IntelUndiPkg/GigUndiDxe/wol/wol.h |  1 -
 IntelUndiPkg/GigUndiDxe/wol/wol_1G.c  |  1 -
 IntelUndiPkg/GigUndiDxe/wol/wolfamily.c   |  1 -
 IntelUndiPkg/GigUndiDxe/wol/wolimpl.c |  1 -
 IntelUndiPkg/GigUndiDxe/wol/wolimpl.h |  3 +-

[edk2] [PATCH edk2-staging 01/19] IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported architectures

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 IntelUndiPkg/IntelOpenSourceUndiPkg.dsc | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc 
b/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
index 21b1fb27984e..ca440bde2cb4 100644
--- a/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
+++ b/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
@@ -29,7 +29,7 @@
   PLATFORM_VERSION   = 0.1
   DSC_SPECIFICATION  = 0x00010005
   OUTPUT_DIRECTORY   = Build/IntelUndiPkg
-  SUPPORTED_ARCHITECTURES= IA32|IPF|X64
+  SUPPORTED_ARCHITECTURES= IA32|IPF|X64|ARM|AARCH64
   BUILD_TARGETS  = DEBUG|RELEASE|DEV
   SKUID_IDENTIFIER   = DEFAULT
 
@@ -62,6 +62,17 @@
   
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
   
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
 
+[LibraryClasses.ARM, LibraryClasses.AARCH64]
+  #
+  # It is not possible to prevent the ARM compiler from inserting calls to
+  # intrinsic functions. This library provides the instrinsic functions such
+  # a compiler may generate calls to.
+  #
+  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
+
+  # Add support for GCC stack protector
+  NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
+
 

 #
 # Pcd Section - list of all EDK II PCD Entries defined by this Platform
-- 
2.19.1

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

Re: [edk2] [edk2-test][RFC PATCH 12/12] uefi-sct/SctPkg: sbbr: Modify SBBR description file to add missing dependencies.

On Tue, Nov 06, 2018 at 02:17:46PM +0530, Sakar Arora wrote:
> SBBR ImageServicesTest fails because it can't load its dependent
> drivers.
> Modify the description file to include all the dependecies and copy it
> over to the dependency folder.
> 
> Signed-off-by: Sakar Arora 
> Reported-by: Felix Poludov 

Again, this looks like something that could be folded in to initial
addition of SBBR_SCT.dsc.

> ---
>  uefi-sct/SctPkg/CommonGenFramework.sh |  3 ++
>  uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc | 81 
> +--
>  2 files changed, 80 insertions(+), 4 deletions(-)
> 
> diff --git a/uefi-sct/SctPkg/CommonGenFramework.sh 
> b/uefi-sct/SctPkg/CommonGenFramework.sh
> index 8e7c7ca..2d7083d 100755
> --- a/uefi-sct/SctPkg/CommonGenFramework.sh
> +++ b/uefi-sct/SctPkg/CommonGenFramework.sh
> @@ -396,4 +396,7 @@ then
>  # Copy the test dependency files
>  # *
>  
> +CopyDependency EfiCompliant
> +CopyDependency ProtocolHandlerServices
> +CopyDependency ImageServices
>  fi
> diff --git a/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc 
> b/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> index 7076d11..01754ba 100644
> --- a/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> +++ b/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> @@ -205,6 +205,44 @@ 
> SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTes
>  ## 12. EFI_IMAGE_UNLOAD
>  ## 13. EFI_EXIT_BOOT_SERVICES
>  
> SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.inf
> +##
> +## Dependency files for Image Services Test
> +##
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/LoadFile/LoadFile.inf

Oh, and the (lack of) indentation here does not look correct.

/
Leif

> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/Application1/Application1.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/Application2/Application2.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/Application3/Application3.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/Application4/Application4.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/BootServicesDriver1/BootServicesDriver1.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/BootServicesDriver2/BootServicesDriver2.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/BootServicesDriver3/BootServicesDriver3.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/BootServicesDriver4/BootServicesDriver4.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/BootServicesDriver5/BootServicesDriver5.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/BootServicesDriver6/BootServicesDriver6.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/RuntimeServicesDriver1/RuntimeServicesDriver1.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/RuntimeServicesDriver2/RuntimeServicesDriver2.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/RuntimeServicesDriver3/RuntimeServicesDriver3.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/RuntimeServicesDriver4/RuntimeServicesDriver4.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/RuntimeServicesDriver5/RuntimeServicesDriver5.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/RuntimeServicesDriver6/RuntimeServicesDriver6.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/CombinationImage1/CombinationImage1.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/CombinationImage2/CombinationImage2.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/CombinationImage3/CombinationImage3.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/CombinationImage4/CombinationImage4.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/CombinationImage5/CombinationImage5.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/CombinationImage6/CombinationImage6.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/CombinationImage7/CombinationImage7.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/CombinationImage8/CombinationImage8.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/CombinationImage9/CombinationImage9.inf
> +SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/Dependency/CombinationImage10/CombinationImage10.inf
>

Re: [edk2] [edk2-test][RFC PATCH 11/12] uefi-sct/SctPkg: sbbr: Bugfix for MemoryMap Check Test.

On Tue, Nov 06, 2018 at 02:17:45PM +0530, Sakar Arora wrote:
> As per SBBR specification, "A UEFI runtime environment compliant with
> SBBR must not be written with any assumption of an identity mapping
> between virtual and physical memory maps."
> 
> Test case implementation was failing the test, if it is not identity
> mapped, which is incorrect.
> 
> Corrected test case to warn the user that UEFI runtime environment is
> identity mapped, instead of failure.
> 
> Signed-off-by: Sakar Arora 
> Reported-by: Felix Poludov 
> ---
>  .../SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c  | 6 
> +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git 
> a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
>  
> b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
> index fb50702..c88d60b 100644
> --- 
> a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
> +++ 
> b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
> @@ -201,13 +201,13 @@ BBTestMemoryMapTest (
>  //
>  // Checking for identity mapping
>  //
> -if (MemoryMapDescriptor->PhysicalStart != 
> MemoryMapDescriptor->VirtualStart) {
> +if (MemoryMapDescriptor->PhysicalStart == 
> MemoryMapDescriptor->VirtualStart) {
>StandardLib->RecordAssertion (
>StandardLib,
> -  EFI_TEST_ASSERTION_FAILED,
> +  EFI_TEST_ASSERTION_WARNING,
>gSbbrBootServicesAssertion001Guid,
>L"MemoryMap",
> -  L"%a:%d - MemoryMap 0x%X Not Identity Mapped",
> +  L"%a:%d - MemoryMap 0x%X is Identity Mapped. UEFI runtime 
> environment must not be written with any assumption of an identity mapping 
> between virtual and physical memory maps.",
>__FILE__,
>__LINE__,
>MemoryMapDescriptor

This file was only added as part of this set - please fold this change
into the original patch adding it. Development history before
upstreaming is not something we need (or want) to track.

/
Leif

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

Re: [edk2] [edk2-test][RFC PATCH 10/12] uefi-sct/SctPkg: sbbr: Corrected path to ArmBaseLib.inf in SBBR_SCT.dsc

On Tue, Nov 06, 2018 at 02:17:44PM +0530, Sakar Arora wrote:
> From: Randy Jones 
> 
> Change-Id: I0fa236441ed8388d6c8a7fd185d46ec5a2dbe02d
> ---
>  uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc 
> b/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> index bf010c9..7076d11 100644
> --- a/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> +++ b/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> @@ -144,7 +144,7 @@
>  
>  [LibraryClasses.AARCH64]
>NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> -  ArmLib|ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
> +  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf

The modified line was added as part of this set.
But without this change, I seriously doubt any of the preceding
commits will have been possible to compile.
(ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf does not exist.)

Please fold this change into the original introduction of this line.

/
Leif

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

Re: [edk2] [edk2-test][RFC PATCH 08/12] uefi-sct/SctPkg: sbbr: UEFI Version Verification Test

On Tue, Nov 06, 2018 at 02:17:42PM +0530, Sakar Arora wrote:
> From: Randy Jones 
> 
> Check if EFI Specification Version is 2.5 or greater.
> 
> Change-Id: I7a602e52ac833f18dc791ca992f55e1f1996bc60
> Signed-off-by: Randy Jones 
> ---
>  uefi-sct/SctPkg/CommonGenFramework.sh  |   3 +
>  .../BlackBoxTest/EfiSpecVerLvlBBTest.inf   |  84 +
>  .../BlackBoxTest/EfiSpecVerLvlBBTestFunction.c | 130 +++
>  .../BlackBoxTest/EfiSpecVerLvlBBTestFunction.h |  71 
>  .../BlackBoxTest/EfiSpecVerLvlBBTestMain.c | 127 +++
>  .../BlackBoxTest/EfiSpecVerLvlBBTestMain.h |  84 +
>  .../Generic/SbbrEfiSpecVerLvl/BlackBoxTest/Guid.c  |  61 
>  .../Generic/SbbrEfiSpecVerLvl/BlackBoxTest/Guid.h  |  66 
>  uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc  | 402 
> +++--
>  9 files changed, 829 insertions(+), 199 deletions(-)
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrEfiSpecVerLvl/BlackBoxTest/EfiSpecVerLvlBBTest.inf
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrEfiSpecVerLvl/BlackBoxTest/EfiSpecVerLvlBBTestFunction.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrEfiSpecVerLvl/BlackBoxTest/EfiSpecVerLvlBBTestFunction.h
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrEfiSpecVerLvl/BlackBoxTest/EfiSpecVerLvlBBTestMain.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrEfiSpecVerLvl/BlackBoxTest/EfiSpecVerLvlBBTestMain.h
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrEfiSpecVerLvl/BlackBoxTest/Guid.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrEfiSpecVerLvl/BlackBoxTest/Guid.h
> 
> diff --git a/uefi-sct/SctPkg/CommonGenFramework.sh 
> b/uefi-sct/SctPkg/CommonGenFramework.sh
> index ab35c5a..7058111 100755
> --- a/uefi-sct/SctPkg/CommonGenFramework.sh
> +++ b/uefi-sct/SctPkg/CommonGenFramework.sh
> @@ -367,6 +367,9 @@ then
>  # UEFI Boot Services - SBBR v1.0 3.4
>  cp $ProcessorType/SbbrBootServicesBBTest.efi   
> $Framework/Test/ > NUL
>  
> +# Check if EFI Specification Version is 2.5 or greater
> +cp $ProcessorType/EfiSpecVerLvlBBTest.efi  
> $Framework/Test/ > NUL
> +
>  # Runtime Services Tests - SBBR v1.0 Appendix B
>  cp $ProcessorType/VariableServicesBBTest.efi   
> $Framework/Test/ > NUL
>  cp $ProcessorType/TimeServicesBBTest.efi   
> $Framework/Test/ > NUL
> diff --git 
> a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrEfiSpecVerLvl/BlackBoxTest/EfiSpecVerLvlBBTest.inf
>  
> b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrEfiSpecVerLvl/BlackBoxTest/EfiSpecVerLvlBBTest.inf
> new file mode 100644
> index 000..daa4d44
> --- /dev/null
> +++ 
> b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrEfiSpecVerLvl/BlackBoxTest/EfiSpecVerLvlBBTest.inf
> @@ -0,0 +1,84 @@
> +#
> +# The material contained herein is not a license, either
> +# expressly or impliedly, to any intellectual property owned
> +# or controlled by any of the authors or developers of this
> +# material or to any contribution thereto. The material
> +# contained herein is provided on an "AS IS" basis and, to the
> +# maximum extent permitted by applicable law, this information
> +# is provided AS IS AND WITH ALL FAULTS, and the authors and
> +# developers of this material hereby disclaim all other
> +# warranties and conditions, either express, implied or
> +# statutory, including, but not limited to, any (if any)
> +# implied warranties, duties or conditions of merchantability,
> +# of fitness for a particular purpose, of accuracy or
> +# completeness of responses, of results, of workmanlike
> +# effort, of lack of viruses and of lack of negligence, all
> +# with regard to this material and any contribution thereto.
> +# Designers must not rely on the absence or characteristics of
> +# any features or instructions marked "reserved" or
> +# "undefined." The Unified EFI Forum, Inc. reserves any
> +# features or instructions so marked for future definition and
> +# shall have no responsibility whatsoever for conflicts or
> +# incompatibilities arising from future changes to them. ALSO,
> +# THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT,
> +# QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR
> +# NON-INFRINGEMENT WITH REGARD TO THE TEST SUITE AND ANY
> +# CONTRIBUTION THERETO.
> +#
> +# IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR
> +# ANY CONTRIBUTION THERETO BE LIABLE TO ANY OTHER PARTY FOR
> +# THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST
> +# PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL,
> +# CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER
> +# UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY
> +# WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS
> +# DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF
> +# THE POSSIBILITY OF SUCH

Re: [edk2] [edk2-test][RFC PATCH 04/12] uefi-sct/SctPkg: sbbr: Add Required UEFI Runtime Services tests.

On Tue, Nov 06, 2018 at 02:17:38PM +0530, Sakar Arora wrote:
> Required UEFI Runtime Services Tests - SBBR v1.0 Appendix B
> 1. EFI_GET_TIME
> 2. EFI_SET_TIME
> 3. EFI_GET_WAKEUP_TIME
> 4. EFI_SET_WAKEUP_TIME
> 5. EFI_GET_VARIABLE
> 6. EFI_GET_NEXT_VARIABLE_NAME
> 7. EFI_SET_VARIABLE
> 8. EFI_QUERY_VARIABLE_INFO
> 9. EFI_QUERY_CAPSULE_CAPABILITIES
> 10. EFI_UPDATE_CAPSULE
> 11. EFI_RESET_SYSTEM
> 12. EFI_SET_VIRTUAL_ADDRESS_MAP
> 13. EFI_CONVERT_POINTER
> 
> Signed-off-by: Sakar Arora 
> ---
>  uefi-sct/SctPkg/CommonGenFramework.sh  |   6 +
>  uefi-sct/SctPkg/Config/Data/Category.ini   |  11 +-
>  .../SBBRRuntimeServices/BlackBoxTest/Guid.c|  61 ++
>  .../SBBRRuntimeServices/BlackBoxTest/Guid.h|  65 ++
>  .../BlackBoxTest/SBBRRuntimeServicesBBTest.inf |  81 
>  .../SBBRRuntimeServicesBBTestFunction.c| 218 
> +
>  .../SBBRRuntimeServicesBBTestFunction.h|  71 +++
>  .../BlackBoxTest/SBBRRuntimeServicesBBTestMain.c   | 131 +
>  .../BlackBoxTest/SBBRRuntimeServicesBBTestMain.h   |  86 
>  uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc  |  24 +++
>  10 files changed, 752 insertions(+), 2 deletions(-)
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/SBBRRuntimeServices/BlackBoxTest/Guid.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/SBBRRuntimeServices/BlackBoxTest/Guid.h
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/SBBRRuntimeServices/BlackBoxTest/SBBRRuntimeServicesBBTest.inf
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/SBBRRuntimeServices/BlackBoxTest/SBBRRuntimeServicesBBTestFunction.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/SBBRRuntimeServices/BlackBoxTest/SBBRRuntimeServicesBBTestFunction.h
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/SBBRRuntimeServices/BlackBoxTest/SBBRRuntimeServicesBBTestMain.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/SBBRRuntimeServices/BlackBoxTest/SBBRRuntimeServicesBBTestMain.h
> 
> diff --git a/uefi-sct/SctPkg/CommonGenFramework.sh 
> b/uefi-sct/SctPkg/CommonGenFramework.sh
> index c9b6ca9..bf94d8e 100755
> --- a/uefi-sct/SctPkg/CommonGenFramework.sh
> +++ b/uefi-sct/SctPkg/CommonGenFramework.sh
> @@ -364,6 +364,12 @@ then
>  # Tests SBBR sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4
>  cp $ProcessorType/SysEnvConfigBBTest.efi
> $Framework/Test/ > NUL
>  
> +# Runtime Services Tests - SBBR v1.0 Appendix B
> +cp $ProcessorType/VariableServicesBBTest.efi   
> $Framework/Test/ > NUL
> +cp $ProcessorType/TimeServicesBBTest.efi   
> $Framework/Test/ > NUL
> +cp $ProcessorType/MiscRuntimeServicesBBTest.efi
> $Framework/Test/ > NUL
> +cp $ProcessorType/SBBRRuntimeServicesBBTest.efi
> $Framework/Test/ > NUL
> +
>  # *
>  # Copy ENTS binary
>  # *
> diff --git a/uefi-sct/SctPkg/Config/Data/Category.ini 
> b/uefi-sct/SctPkg/Config/Data/Category.ini
> index 9a81c1d..a41cd0f 100644
> --- a/uefi-sct/SctPkg/Config/Data/Category.ini
> +++ b/uefi-sct/SctPkg/Config/Data/Category.ini
> @@ -173,8 +173,15 @@ Description   =
>  
>  [Category Data]
>  Revision  = 0x0001
> -CategoryGuid  = 5B1B31A1-9562-11D2-8E3F-00A0C969723B
> -InterfaceGuid = 5B1B31A1-9562-11D2-8E3F-00A0C969723B
> +CategoryGuid  = 52A69BBF-E19F-4e82-93D6-AAC46E2E1E06
> +InterfaceGuid = AFF115FB-387B-4c18-8C41-6AFC7F03BB90
> +Name  = RuntimeServicesTest\SBBRRuntimeServicesTest
> +Description   =
> +
> +[Category Data]
> +Revision  = 0x0001
> +CategoryGuid  = 5B1B31A1-9562-11d2-8E3F-00A0C969723B
> +InterfaceGuid = 5B1B31A1-9562-11d2-8E3F-00A0C969723B
>  Name  = LoadedImageProtocolTest
>  Description   =

Again, the actual change would be much more clear if
RuntimeServicesTest\SBBRRuntimeServicesTest was added after
LoadedImageProtocolTest.

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

Re: [edk2] [edk2-test][RFC PATCH 07/12] uefi-sct/SctPkg: sbbr: Add test cases for SBBR v1.0 boot services

On Tue, Nov 06, 2018 at 02:17:41PM +0530, Sakar Arora wrote:
> From: John Powell 
> 
> Tests SBBR requirements 3.4.1 and 3.4.4.
> 
> Change-Id: I0dd625851db65d04d2a7572a2d6838951c8f7c67
> Signed-off-by: John Powell 
> ---
>  uefi-sct/SctPkg/CommonGenFramework.sh  |   3 +
>  uefi-sct/SctPkg/Config/Data/Category.ini   |  11 +-
>  .../SbbrBootServices/BlackBoxTest/Guid.c   |  65 +++
>  .../SbbrBootServices/BlackBoxTest/Guid.h   |  76 +++
>  .../BlackBoxTest/SbbrBootServicesBBTest.inf|  85 
>  .../BlackBoxTest/SbbrBootServicesBBTestFunction.c  | 549 
> +
>  .../BlackBoxTest/SbbrBootServicesBBTestFunction.h  |  85 
>  .../BlackBoxTest/SbbrBootServicesBBTestMain.c  | 149 ++
>  .../BlackBoxTest/SbbrBootServicesBBTestMain.h  |  99 
>  uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc  |   7 +
>  10 files changed, 1127 insertions(+), 2 deletions(-)
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/Guid.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/Guid.h
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTest.inf
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.h
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestMain.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestMain.h
> 
> diff --git a/uefi-sct/SctPkg/CommonGenFramework.sh 
> b/uefi-sct/SctPkg/CommonGenFramework.sh
> index aecd21b..ab35c5a 100755
> --- a/uefi-sct/SctPkg/CommonGenFramework.sh
> +++ b/uefi-sct/SctPkg/CommonGenFramework.sh
> @@ -364,6 +364,9 @@ then
>  # Tests SBBR sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4
>  cp $ProcessorType/SysEnvConfigBBTest.efi   
> $Framework/Test/ > NUL
>  
> +# UEFI Boot Services - SBBR v1.0 3.4
> +cp $ProcessorType/SbbrBootServicesBBTest.efi   
> $Framework/Test/ > NUL
> +
>  # Runtime Services Tests - SBBR v1.0 Appendix B
>  cp $ProcessorType/VariableServicesBBTest.efi   
> $Framework/Test/ > NUL
>  cp $ProcessorType/TimeServicesBBTest.efi   
> $Framework/Test/ > NUL
> diff --git a/uefi-sct/SctPkg/Config/Data/Category.ini 
> b/uefi-sct/SctPkg/Config/Data/Category.ini
> index 9576971..17ca639 100644
> --- a/uefi-sct/SctPkg/Config/Data/Category.ini
> +++ b/uefi-sct/SctPkg/Config/Data/Category.ini
> @@ -145,8 +145,15 @@ Description   =
>  
>  [Category Data]
>  Revision  = 0x0001
> -CategoryGuid  = AFF115FB-387B-4C18-8C41-6AFC7F03BB90
> -InterfaceGuid = AFF115FB-387B-4C18-8C41-6AFC7F03BB90
> +CategoryGuid  = 8dafd7a7-44d0-4cf4-9d28-9f87080fc091
> +InterfaceGuid = E9EF7553-F833-4E56-96E8-38AE679523CC
> +Name  = BootServicesTest\SbbrBootServices
> +Description   = Tests SBBR boot services requirements.
> +
> +[Category Data]
> +Revision  = 0x0001
> +CategoryGuid  = AFF115FB-387B-4c18-8C41-6AFC7F03BB90
> +InterfaceGuid = AFF115FB-387B-4c18-8C41-6AFC7F03BB90
>  Name  = RuntimeServicesTest
>  Description   =

Diff would be more clear if added test was added after existing test.

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

Re: [edk2] [edk2-test][RFC PATCH 01/12] uefi-sct/SctPkg: sbbr: Add support to build SBBR v1.0 test cases.

2018-11-06 Thread Supreeth Venkatesh

On Tue, 2018-11-06 at 06:45 -0600, Leif Lindholm wrote:
> Hi Sakar,
> 
> Glad to see you guys already contributing to the newly(ish) open SCT.
Indeed.
> 
> I do have some comments on this patch - starting with: please cc the
> maintainers. I have added Eric/Supreeth to this reply.
We (me and Eric) have setup or in the process of setting up email
filters that has a subject line of "edk2-test". So, Its ok, but will be
more convenient if we are copied on CC. 
> 
> On Tue, Nov 06, 2018 at 02:17:35PM +0530, Sakar Arora wrote:
> > Provide a framework for building SBBR Test Cases using the existing
> > UEFI-SCT Framework. Separate out build-scripts/install scripts to
> > carve out SBBR test cases.
> > 
> > To build SBBR SCT,
> > 
> >./build_sbbr.sh AARCH64 GCC
> > 
> > Change-Id: I3d7612dbb42a4dc3bce40e4e9b351fd1f5f84dcd
> > Signed-off-by: Sakar Arora 
> > ---
> >  uefi-sct/SctPkg/CommonGenFramework.sh |  33 
> >  uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc | 205 ++
> >  uefi-sct/SctPkg/build_sbbr.sh | 312
> > ++
> >  3 files changed, 550 insertions(+)
> >  create mode 100644 uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> >  create mode 100755 uefi-sct/SctPkg/build_sbbr.sh
> > 
> > diff --git a/uefi-sct/SctPkg/CommonGenFramework.sh b/uefi-
> > sct/SctPkg/CommonGenFramework.sh
> > index 299f0d6..4bb68ce 100755
> > --- a/uefi-sct/SctPkg/CommonGenFramework.sh
> > +++ b/uefi-sct/SctPkg/CommonGenFramework.sh
> > @@ -335,4 +335,37 @@ then
> >CopyDependency Ebc
> >CopyDependency PxeBaseCode
> >  fi
> > +# *
> > +# For SBBR v1.0 SCT
> > +# *
> > +
> > +if [ $1 = "sbbr_sct" ]
> > +then
> > +# *
> > +# Copy the SBBR v1.0 Test Cases
> > +# *
> > +
> > +mkdir -p $Framework/SCRT
> > +cp
> > $ProcessorType/SCRTDRIVER.efi   $Framework/
> > SCRT  > NUL
> 
> This "> NUL" comes from someone cargo-culting when translating from a
> Windows .bat file. On any unix-like system, this means you end up
> with
> a file called NUL. (Read through the thread at
> https://twitter.com/Foone/status/1058676834940776450 for a recent
> hilarious twitter rant.)
> 
> So please don't add any new "> NUL" statements.
> I would argue since the unix cp is silent by default, it can be
> dropped completely.
> 
> Someone with some free time on their hands could go through and
> delete
> all of the Windows-isms from the original script.
I agree. Since this is a unix/linux shell script, there is no need for
windows related quirks.
> 
> > +cp
> > $ProcessorType/SCRTAPP.efi  $Framework/
> > SCRT  > NUL
> > +cp
> > ../../../SctPkg/Config/Data/SCRT.conf   $Framework/
> > SCRT  > NUL
> 
> 1) Is there no way of doing this without ../../..?
> 2) Which SctPkg is this? This file is already in SctPkg, yet this
>brings us 3 levels of hierarchy up?
> 
> > +
> > +# *
> > +# Copy your test cases here
> > +# *
> > +
> >  
> > +# *
> > +# Copy ENTS binary
> > +# *
> > +
> > +cp
> > $ProcessorType/SerialMonitor.efi$Framework/Ents/Sup
> > port/ > NUL
> > +cp
> > $ProcessorType/ManagedNetworkMonitor.efi$Framework/Ents/Sup
> > port/ > NUL
> > +cp
> > $ProcessorType/IP4NetworkMonitor.efi$Framework/Ents/Sup
> > port/ > NUL
> > +cp $ProcessorType/Eftp.efi $Framework/
> > Ents/Support/ > NUL
> > +
> > +# *
> > +# Copy the test dependency files
> > +# *
> > +
> > +fi
> > diff --git a/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc b/uefi-
> > sct/SctPkg/UEFI/SBBR_SCT.dsc
> > new file mode 100644
> > index 000..ff6abd9
> > --- /dev/null
> > +++ b/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> > @@ -0,0 +1,205 @@
> > +#
> > +# The material contained herein is not a license, either
> > +# expressly or impliedly, to any intellectual property owned
> > +# or controlled by any of the authors or developers of this
> > +# material or to any contribution thereto. The material
> > +# contained herein is provided on an "AS IS" basis and, to the
> > +# maximum extent permitted by applicable law, this information
> > +# is provided AS IS AND WITH ALL FAULTS, and the authors and
> > +# developers of this material hereby disclaim all other
> > +# warranties and conditions, either express, implied or
> > +# statutory, including, but not limited to, any (if any)
> > +# implied warranties, duties or conditions of merchantability,
> > +# of fitness for a particular purpose, of accuracy or
> > +# completeness of responses, of

Re: [edk2] [edk2-test][RFC PATCH 03/12] uefi-sct/SctPkg: sbbr: Add System Environment Configuration Test Cases

Hi Sakar,

On Tue, Nov 06, 2018 at 02:17:37PM +0530, Sakar Arora wrote:
> From: John Powell 
> 
> Add test cases for SBBR v1.0 requirements 3.3.1, 3.3.2, 3.3.3 and 3.3.4.
> 
> Change-Id: I3801314af1ffabaa2d71cee76417c4277f5f5521
> Signed-off-by: John Powell 
> ---
>  uefi-sct/SctPkg/CommonGenFramework.sh  |   3 +
>  uefi-sct/SctPkg/Config/Data/Category.ini   |  11 +-
>  .../Generic/SbbrSysEnvConfig/BlackBoxTest/Guid.c   |  67 +++
>  .../Generic/SbbrSysEnvConfig/BlackBoxTest/Guid.h   |  81 
>  .../BlackBoxTest/SysEnvConfigBBTest.inf|  84 
>  .../BlackBoxTest/SysEnvConfigBBTestFunction.c  | 527 
> +
>  .../BlackBoxTest/SysEnvConfigBBTestFunction.h  | 104 
>  .../BlackBoxTest/SysEnvConfigBBTestMain.c  | 157 ++
>  .../BlackBoxTest/SysEnvConfigBBTestMain.h  |  96 
>  uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc  |   7 +
>  10 files changed, 1135 insertions(+), 2 deletions(-)

Can you generate patches using the steps outlined in
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23
?

This has two major benefits to the reviewer (and can reduce the number
of revisions required for a set):
- full paths are displayed, instead of truncated ones (.../)
- interfaces (or changes to) get reviewed before their first use

>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrSysEnvConfig/BlackBoxTest/Guid.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrSysEnvConfig/BlackBoxTest/Guid.h
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrSysEnvConfig/BlackBoxTest/SysEnvConfigBBTest.inf
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrSysEnvConfig/BlackBoxTest/SysEnvConfigBBTestFunction.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrSysEnvConfig/BlackBoxTest/SysEnvConfigBBTestFunction.h
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrSysEnvConfig/BlackBoxTest/SysEnvConfigBBTestMain.c
>  create mode 100644 
> uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrSysEnvConfig/BlackBoxTest/SysEnvConfigBBTestMain.h
> 
> diff --git a/uefi-sct/SctPkg/CommonGenFramework.sh 
> b/uefi-sct/SctPkg/CommonGenFramework.sh
> index e0f9658..c9b6ca9 100755
> --- a/uefi-sct/SctPkg/CommonGenFramework.sh
> +++ b/uefi-sct/SctPkg/CommonGenFramework.sh
> @@ -361,6 +361,9 @@ then
>  cp $ProcessorType/MiscBootServicesBBTest.efi
> $Framework/Test/  > NUL
>  cp $ProcessorType/ProtocolHandlerServicesBBTest.efi 
> $Framework/Test/  > NUL
>  
> +# Tests SBBR sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4
> +cp $ProcessorType/SysEnvConfigBBTest.efi
> $Framework/Test/ > NUL
> +
>  # *
>  # Copy ENTS binary
>  # *
> diff --git a/uefi-sct/SctPkg/Config/Data/Category.ini 
> b/uefi-sct/SctPkg/Config/Data/Category.ini
> index 3e9f5e5..9a81c1d 100644
> --- a/uefi-sct/SctPkg/Config/Data/Category.ini
> +++ b/uefi-sct/SctPkg/Config/Data/Category.ini
> @@ -89,8 +89,15 @@ Description   =
>  
>  [Category Data]
>  Revision  = 0x0001
> -CategoryGuid  = E9EF7553-F833-4E56-96E8-38AE679523CC
> -InterfaceGuid = E9EF7553-F833-4E56-96E8-38AE679523CC
> +CategoryGuid  = D84A6430-99F5-4660-8454-6E4C896A7E51
> +InterfaceGuid = 71652D04-BF38-434a-BCB8-6547D7FD8384
> +Name  = GenericTest\SbbrSysEnvConfig
> +Description   =
> +
> +[Category Data]
> +Revision  = 0x0001
> +CategoryGuid  = E9EF7553-F833-4e56-96E8-38AE679523CC
> +InterfaceGuid = E9EF7553-F833-4e56-96E8-38AE679523CC
>  Name  = BootServicesTest
>  Description   =

This diff would be much more clear if GenericTest\SbbrSysEnvConfig was
introduced afer the existing BootServicesTest rather than before.

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

Re: [edk2] [edk2-test][RFC PATCH 02/12] uefi-sct/SctPkg: sbbr: Add boot services test cases for SBBR v1.0

Hi Sakar,

On Tue, Nov 06, 2018 at 02:17:36PM +0530, Sakar Arora wrote:
> 1. Implements boot services tests defined in Appendix A of
>
> http://infocenter.arm.com/help/topic/com.arm.doc.den0044b/DEN0044B_Server_Base_Boot_Requirements.pdf
> 
> 2. Fixes whitespace issues in SctPkg/CommonGenFramework.sh file.

Can you please break 2 out as a separate patch, preceding the changes
made by 1?

Combining whitespace-only changes with functional changes makes first
code-review and later the output of git blame (or bisect) ever so much
more painful.

/
Leif

> Change-Id: Idc7b6e471a4c4966d4ad55f39ea045775854c206
> Signed-off-by: Sakar Arora 
> ---
>  uefi-sct/SctPkg/CommonGenFramework.sh |  12 +-
>  uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc | 457 
> +++---
>  2 files changed, 261 insertions(+), 208 deletions(-)
> 
> diff --git a/uefi-sct/SctPkg/CommonGenFramework.sh 
> b/uefi-sct/SctPkg/CommonGenFramework.sh
> index 4bb68ce..e0f9658 100755
> --- a/uefi-sct/SctPkg/CommonGenFramework.sh
> +++ b/uefi-sct/SctPkg/CommonGenFramework.sh
> @@ -89,7 +89,7 @@ CopyDependencyFile()
>  
>  CopyDependency()
>  {
> -mkdir -p $Framework/Dependency/$1BBTest  
> +mkdir -p $Framework/Dependency/$1BBTest
>  ls -h $ProcessorType/$1_Invalid*   > temp.txt 2>NUL
>  ls -h $ProcessorType/$1_*.efi   >> temp.txt 2>NUL
>  ls -h $ProcessorType/$1_*.ini   >> temp.txt 2>NUL
> @@ -107,8 +107,8 @@ CopyDependency()
>  # For UEFI SCT
>  # *
>  
> -if [ $1 = "uefi_sct" ] 
> -then 
> +if [ $1 = "uefi_sct" ]
> +then
>  # *
>  # Copy the UEFI 2.1 Test Cases
>  # *
> @@ -354,6 +354,12 @@ then
>  # Copy your test cases here
>  # *
>  
> +# Boot Services Tests - SBBR v1.0 Appendix A
> +cp $ProcessorType/EventTimerTaskPriorityServicesBBTest.efi  
> $Framework/Test/  > NUL
> +cp $ProcessorType/ImageServicesBBTest.efi   
> $Framework/Test/  > NUL
> +cp $ProcessorType/MemoryAllocationServicesBBTest.efi
> $Framework/Test/  > NUL
> +cp $ProcessorType/MiscBootServicesBBTest.efi
> $Framework/Test/  > NUL
> +cp $ProcessorType/ProtocolHandlerServicesBBTest.efi 
> $Framework/Test/  > NUL
>  
>  # *
>  # Copy ENTS binary
> diff --git a/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc 
> b/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> index ff6abd9..7b5b4b0 100644
> --- a/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> +++ b/uefi-sct/SctPkg/UEFI/SBBR_SCT.dsc
> @@ -1,205 +1,252 @@
> -#
> -# The material contained herein is not a license, either
> -# expressly or impliedly, to any intellectual property owned
> -# or controlled by any of the authors or developers of this
> -# material or to any contribution thereto. The material
> -# contained herein is provided on an "AS IS" basis and, to the
> -# maximum extent permitted by applicable law, this information
> -# is provided AS IS AND WITH ALL FAULTS, and the authors and
> -# developers of this material hereby disclaim all other
> -# warranties and conditions, either express, implied or
> -# statutory, including, but not limited to, any (if any)
> -# implied warranties, duties or conditions of merchantability,
> -# of fitness for a particular purpose, of accuracy or
> -# completeness of responses, of results, of workmanlike
> -# effort, of lack of viruses and of lack of negligence, all
> -# with regard to this material and any contribution thereto.
> -# Designers must not rely on the absence or characteristics of
> -# any features or instructions marked "reserved" or
> -# "undefined." The Unified EFI Forum, Inc. reserves any
> -# features or instructions so marked for future definition and
> -# shall have no responsibility whatsoever for conflicts or
> -# incompatibilities arising from future changes to them. ALSO,
> -# THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT,
> -# QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR
> -# NON-INFRINGEMENT WITH REGARD TO THE TEST SUITE AND ANY
> -# CONTRIBUTION THERETO.
> -#
> -# IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR
> -# ANY CONTRIBUTION THERETO BE LIABLE TO ANY OTHER PARTY FOR
> -# THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST
> -# PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL,
> -# CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER
> -# UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY
> -# WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS
> -# DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF
> -# THE POSSIBILITY OF SUCH DAMAGES.
> -#
> -# Copyright 2006 - 2016 Unified EFI, Inc. All
> -# Rights Reserved, subject to all existing rights in all
> -# matters included within this Test Suite, to which United
> -# EFI, Inc. makes

Re: [edk2] [PATCH v3 1/1] ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF.

On 6 November 2018 at 16:24, Laszlo Ersek  wrote:
> On 11/06/18 13:32, Ard Biesheuvel wrote:
>> On 6 November 2018 at 02:24, Fu Siyuan  wrote:
>>> V3:
>>> Remove duplicate library added in v2 patch, since ArmVirtPkg.dsc.inc
>>> already have them. Just remove the if...end there is enough.
>>>
>>> V2:
>>> Add missing library instance for NetworkPkg iSCSI driver.
>>>
>>
>> Please don't put the patch revision history in the commit log. Put it
>> below the ---
>>
>>> This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those
>>> ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively
>>> maintained and will be removed from edk2 master soon.
>>>
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 
>>> Cc: Julien Grall 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Fu Siyuan 
>>> ---
>>
>> ... here ...
>>
>> The patch looks fine to me
>>
>> Reviewed-by: Ard Biesheuvel 
>>
>> but please don't merge it until after the next stable tag has been created
>
> This is not a bad idea (see also your discussion with Leif); however it
> does create a bit of inconsistency with how the other platform DSC/FDF
> files have been handled. (The changes have been pushed for those.)
>
> Again, I don't disagree, and I don't mind if ArmVirt is handled
> differently. It's just that we should have handled this more uniformly,
> I believe.
>

Yes - as I replied to Leif, I am not going to obsess about this. But
the point of stable tags is not to rush things in at the last minute.

>
> In retrospect, I would have also appreciated if the patches had
> referenced , even
> though they only implement "prep" work for now, on the platform DSC/FDF
> level, and not the actual driver removal.
>
> For example, the important explanation about MdeModulePkg's iSCSI driver
> implementing its own MD5 algo cannot be connected to the OVMF commit now
> (d2f1f6423bd1). I have copied the most relevant passage from the cover
> letter of this series into TianoCore BZ#1278, but the commit in question
> doesn't reference any BZ, so the link cannot be established.
>
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 5/5] OvmfPkg: simply use the Bochs interface for vmsvga

On 11/06/18 14:44, Philippe Mathieu-Daudé wrote:
> On 6/11/18 14:36, Laszlo Ersek wrote:
>> On 11/06/18 12:47, Laszlo Ersek wrote:
>>
>>> ... While we discuss this, I'll go ahead and push the first four
>>> patches. The code being reverted is dead anyway. I'll report back about
>>> the commit hashes.
>>
>> Before pushing the first four patches, I regression-tested them as well.
>> Using: Cirrus, stdvga, and QXL. My QEMU version was
>> v3.0.0-1763-gb2f7a038bb4c. The machine type was "pc-q35-3.0".
>>
>> For the first four patches:
>> - Regression-tested-by: Laszlo Ersek ,
>> - pushed them as commit range 62ea70e31285..328409ce8de7.
> 
> Thanks Laszlo!
> A bit late, but 1-4 reviewed too.

I apologize, I should have waited longer.

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

Re: [edk2] [PATCH] UefiCpuPkg/CommonFeature: Skip locking when the feature is disabled

On 11/06/18 10:06, Ruiyu Ni wrote:
> Today's code unconditionally sets the IA32_FEATURE_CONTROL.Lock to 1
> no matter the feature is enabled or not.
> 
> The patch fixes this issue by only setting the Lock bit to 1 when
> the feature is enabled.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> ---
>  UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c 
> b/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
> index 8c1eb5eb4f..0b85f25f90 100644
> --- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
> +++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
> @@ -1,7 +1,7 @@
>  /** @file
>Features in MSR_IA32_FEATURE_CONTROL register.
>  
> -  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
> @@ -184,6 +184,14 @@ LockFeatureControlRegisterInitialize (
>  {
>MSR_IA32_FEATURE_CONTROL_REGISTER*MsrRegister;
>  
> +  //
> +  // When Lock Feature Control Register feature is disabled,
> +  // just skip the MSR lock bit setting.
> +  //
> +  if (!State) {
> +return RETURN_SUCCESS;
> +  }
> +
>//
>// The scope of Lock bit in the MSR_IA32_FEATURE_CONTROL is core for
>// below processor type, only program MSR_IA32_FEATURE_CONTROL for thread 
> 0 in each
> 

I'll defer to Eric on this, as OVMF does not use this lib instance.

(In fact, no platform in the edk2 tree seems to.)

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

Re: [edk2] [PATCH] UefiCpuPkg/SmmCpu: Block SMM read-out only when static paging is used

On 11/06/18 03:59, Ruiyu Ni wrote:
> From: Jiewen Yao 
> 
> Today's implementation blocks SMM read-out no matter static paging
> is enabled or not. But certain platform may need to read non-SMM
> content from SMM code. These platforms don't have a way to disable
> the read-out blocking.
> 
> The patch updates the policy to only block SMM read-out when static
> paging is enabled. So that the static paging can be disabled for
> those platforms that want SMM read-out.
> 
> Setting PcdCpuSmmStaticPageTable to FALSE can disable the static
> paging.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jiewen Yao 
> Signed-off-by: Ruiyu Ni 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Laszlo Ersek 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 5bb7d57238..117502dafa 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -1,7 +1,7 @@
>  /** @file
>  Page Fault (#PF) handler for X64 processors
>  
> -Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
>  Copyright (c) 2017, AMD Incorporated. All rights reserved.
>  
>  This program and the accompanying materials
> @@ -890,7 +890,7 @@ SmiPFHandler (
>CpuDeadLoop ();
>  }
>  
> -if (IsSmmCommBufferForbiddenAddress (PFAddress)) {
> +if (mCpuSmmStaticPageTable && IsSmmCommBufferForbiddenAddress 
> (PFAddress)) {
>DumpCpuContext (InterruptType, SystemContext);
>DEBUG ((DEBUG_ERROR, "Access SMM communication forbidden address 
> (0x%lx)!\n", PFAddress));
>DEBUG_CODE (
> 

OVMF inherits the default TRUE value for PcdCpuSmmStaticPageTable, from
"UefiCpuPkg.dec", and that's intentional. Therefore this patch should be
a no-op from OVMF's perspective.

Acked-by: Laszlo Ersek 

More generally, is the use of PcdCpuSmmStaticPageTable for controlling
this kind of read-out just a convenience / simplification (in which case
I don't think it's great!), or are these topics inherently connected
somehow?

I remember that Jiewen said earlier that with "static paging" enabled
(i.e., building the page tables used in SMM all in advance), we provide
more page protection.

Also, I see that PcdCpuSmmProfileEnable can only be enabled with
PcdCpuSmmStaticPageTable set to FALSE.

So it seems that with PcdCpuSmmStaticPageTable set to TRUE, our page
fault handling in SMM is generally strict(er). This patch looks
consistent with that, but it would be nice if the commit message spelled
out why *exactly* it makes sense to use PcdCpuSmmStaticPageTable for
this new purpose as well.

(I hope my question makes sense. :) )

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

Re: [edk2] TimerLib - usable library on X64?

2018-11-06 Thread Andrew Fish

Ryszard,

The different libraries mix timers, and TSC (for x86). 

For some of the timer libs there may be some PCD settings that need to get 
mapped to your platform. You can look in the timer libs INF to see what it 
depends on.

PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf

[Pcd]
  gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPciBusNumber ## CONSUMES
  gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPciDeviceNumber  ## CONSUMES
  gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPciFunctionNumber## CONSUMES
  gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPciEnableRegisterOffset  ## CONSUMES
  gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoBarEnableMask## CONSUMES
  gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPciBarRegisterOffset ## CONSUMES
  gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPortBaseAddress  ## CONSUMES
  gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiPm1TmrOffset   ## CONSUMES
  gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPortBaseAddressMask  ## CONSUMES

Thanks,

Andrew Fish

> On Nov 6, 2018, at 6:13 AM, Knop, Ryszard  wrote:
> 
> Hi everyone,
> I'm trying to use TimerLib to precisely measure time elapsed between specific 
> functions, and I'm having some issues trying to get it to work. On X64 
> platforms all I get is (depending on the TimerLib impl I use) either zeroes 
> from QueryPerformanceCounter (QueryPerformanceCounterProperties returns 
> zeroes for all the counters, except the frequency which is always reported as 
> 100Hz), or the platform hangs. I've tried a few TimerLib implementations and 
> I'm a bit out of ideas by now. Am I doing something wrong in the code itself, 
> or is there any concrete implementation that is known to work well?
> 
> Sources I'm using: 
> https://gist.github.com/DragoonAethis/7df6d8fb35c4f1932ec42bacbcbf73a8
> 
> Thanks, Richard.
> 
> 
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII 
> Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 
> 957-07-52-316 | Kapital zakladowy 200.000 PLN.
> 
> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
> moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
> wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
> jakiekolwiek
> przegladanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the 
> sole use of the intended recipient(s). If you are not the intended recipient, 
> please contact the sender and delete all copies; any review or distribution by
> others is strictly prohibited.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH v3 1/1] ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF.

On 11/06/18 13:32, Ard Biesheuvel wrote:
> On 6 November 2018 at 02:24, Fu Siyuan  wrote:
>> V3:
>> Remove duplicate library added in v2 patch, since ArmVirtPkg.dsc.inc
>> already have them. Just remove the if...end there is enough.
>>
>> V2:
>> Add missing library instance for NetworkPkg iSCSI driver.
>>
> 
> Please don't put the patch revision history in the commit log. Put it
> below the ---
> 
>> This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those
>> ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively
>> maintained and will be removed from edk2 master soon.
>>
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Cc: Julien Grall 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Fu Siyuan 
>> ---
> 
> ... here ...
> 
> The patch looks fine to me
> 
> Reviewed-by: Ard Biesheuvel 
> 
> but please don't merge it until after the next stable tag has been created

This is not a bad idea (see also your discussion with Leif); however it
does create a bit of inconsistency with how the other platform DSC/FDF
files have been handled. (The changes have been pushed for those.)

Again, I don't disagree, and I don't mind if ArmVirt is handled
differently. It's just that we should have handled this more uniformly,
I believe.

In retrospect, I would have also appreciated if the patches had
referenced , even
though they only implement "prep" work for now, on the platform DSC/FDF
level, and not the actual driver removal.

For example, the important explanation about MdeModulePkg's iSCSI driver
implementing its own MD5 algo cannot be connected to the OVMF commit now
(d2f1f6423bd1). I have copied the most relevant passage from the cover
letter of this series into TianoCore BZ#1278, but the commit in question
doesn't reference any BZ, so the link cannot be established.

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

Re: [edk2] [PATCH v3 1/1] ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF.

On 11/06/18 02:24, Fu Siyuan wrote:
> V3:
> Remove duplicate library added in v2 patch, since ArmVirtPkg.dsc.inc
> already have them. Just remove the if...end there is enough.
> 
> V2:
> Add missing library instance for NetworkPkg iSCSI driver.
> 
> This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those
> ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively
> maintained and will be removed from edk2 master soon.
> 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Fu Siyuan 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc   |  2 --
>  ArmVirtPkg/ArmVirtQemu.dsc   | 10 +++---
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 10 +++---
>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 13 ++---
>  4 files changed, 12 insertions(+), 23 deletions(-)
> 
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index 70a0ac4d786c..ebabf3f47ec9 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -149,11 +149,9 @@ [LibraryClasses.common]
>#
># CryptoPkg libraries needed by multiple firmware features
>#
> -!if ($(SECURE_BOOT_ENABLE) == TRUE) || ($(NETWORK_IP6_ENABLE) == TRUE)
>IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
>OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> -!endif
>  
>#
># Secure Boot dependencies

This part looks good to me.

> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 885c6b14b844..b3f1b23e3890 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -346,18 +346,14 @@ [Components.common]
>MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
>MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
>MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
> +  NetworkPkg/TcpDxe/TcpDxe.inf
> +  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +  NetworkPkg/IScsiDxe/IScsiDxe.inf
>  !if $(NETWORK_IP6_ENABLE) == TRUE
>NetworkPkg/Ip6Dxe/Ip6Dxe.inf
> -  NetworkPkg/TcpDxe/TcpDxe.inf
>NetworkPkg/Udp6Dxe/Udp6Dxe.inf
>NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
>NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
> -  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> -  NetworkPkg/IScsiDxe/IScsiDxe.inf
> -!else
> -  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> -  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
> -  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
>  !endif
>  !if $(HTTP_BOOT_ENABLE) == TRUE
>NetworkPkg/DnsDxe/DnsDxe.inf

This looks fine as well.

> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
> b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> index a6390bd4b841..3316f982695f 100644
> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> @@ -126,18 +126,14 @@ [FV.FvMain]
>INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
>INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
>INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
> +  INF NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +  INF NetworkPkg/IScsiDxe/IScsiDxe.inf
> +  INF NetworkPkg/TcpDxe/TcpDxe.inf
>  !if $(NETWORK_IP6_ENABLE) == TRUE
>INF NetworkPkg/Ip6Dxe/Ip6Dxe.inf
> -  INF NetworkPkg/TcpDxe/TcpDxe.inf
>INF NetworkPkg/Udp6Dxe/Udp6Dxe.inf
>INF NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
>INF NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
> -  INF NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> -  INF NetworkPkg/IScsiDxe/IScsiDxe.inf
> -!else
> -  INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> -  INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
> -  INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
>  !endif
>  !if $(HTTP_BOOT_ENABLE) == TRUE
>INF NetworkPkg/DnsDxe/DnsDxe.inf

(1) Small wart: in the new (added) lines, we might want to stick with
the order TcpDxe, UefiPxeBcDxe, IScsiDxe. Functionally, this is totally
irrelevant, but it's easier to read (compare: (a) the DSC file above,
(b) the lines being removed).

> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index 434d6861a56f..4920a66f2fdb 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -67,6 +67,9 @@ [LibraryClasses.common]
>  
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
> +  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> +  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
>  
>  [BuildOptions.ARM.EDKII.SEC, BuildOptions.ARM.EDKII.BASE]
># Avoid MOVT/MOVW instruction pairs in code that may end up in the PIE

(2) I think this hunk should have been dropped, in the v3 iteration; the
lib class resolutions are now unconditional in the dsc.inc file. (And
those are also more correct, due to

Re: [edk2] [PATCH v2 3/3] OvmfPkg: Replace obsoleted network drivers from platform DSC/FDF.

On 6 November 2018 at 15:58, Laszlo Ersek  wrote:
> On 11/06/18 12:26, Ard Biesheuvel wrote:
>> On 5 November 2018 at 23:46, Laszlo Ersek  wrote:
>
>>> Assuming we consider "NetworkPkg/IScsiDxe/IScsiDxe.inf" an integral part
>>> of the edk2 networking stack, without which (and its OpenSSL dependency)
>>> noone would ever want to build OVMF, this patch is OK.
>>>
>>> I don't know what other OVMF users think about this; personally I'm ok
>>> with it.
>>>
>>> Reviewed-by: Laszlo Ersek 
>>>
>>
>> I think that is fine.
>>
>> Reviewed-by: Ard Biesheuvel 
>>
>> Since the delta between NETWORK_IP6_ENABLE on vs off is decreasing,
>> any chance we could drop it altogether at some point?
>
> I believe I'd prefer flipping the default value at the most. UEFI has
> been gaining new features like there's no tomorrow, and I find the
> parallel (?) growth of the OVMF binary (mainly DXEFV) uncomfortable.
>
> I'd like to continue offering knobs to keep the included features under
> control.
>

Fair enough. From a testing/coverage POV, flipping the default already
improves the situation significantly, so I can live with that.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/3] ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF.

On 11/06/18 01:54, Fu, Siyuan wrote:
> Hi, Laszlo
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek

>> I'm not asking for additional documentation regarding this fact, given
>> commit 0bcbdf9c7445 ("NetworkPkg/IScsiDxe: Add the clarification
>> compared to IScsiDxe in MdeModulePkg.", 2018-09-27). I'm just asking if
>> we've considered this and find it acceptable.
> 
> The MdeModulePkg iSCSI driver can be built without OpenSSL because it writes
> its own crypto functions in IScsiDxe/Md5.c, that's not allowed by
> current edk2 security development guide line. We should always use the
> crypto APIs provided by OpenSSL instead of reinvent a new implementation.

Ah, that makes a lot of sense. I've wondered about this difference in
dependencies for a long time.

[...]

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

Re: [edk2] [PATCH v2 3/3] OvmfPkg: Replace obsoleted network drivers from platform DSC/FDF.

On 11/06/18 12:26, Ard Biesheuvel wrote:
> On 5 November 2018 at 23:46, Laszlo Ersek  wrote:

>> Assuming we consider "NetworkPkg/IScsiDxe/IScsiDxe.inf" an integral part
>> of the edk2 networking stack, without which (and its OpenSSL dependency)
>> noone would ever want to build OVMF, this patch is OK.
>>
>> I don't know what other OVMF users think about this; personally I'm ok
>> with it.
>>
>> Reviewed-by: Laszlo Ersek 
>>
> 
> I think that is fine.
> 
> Reviewed-by: Ard Biesheuvel 
> 
> Since the delta between NETWORK_IP6_ENABLE on vs off is decreasing,
> any chance we could drop it altogether at some point?

I believe I'd prefer flipping the default value at the most. UEFI has
been gaining new features like there's no tomorrow, and I find the
parallel (?) growth of the OVMF binary (mainly DXEFV) uncomfortable.

I'd like to continue offering knobs to keep the included features under
control.

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

Re: [edk2] [PATCH v1 0/7] Delete TCP, PXE, iSCSI driver in MdeModulePkg.

On 11/06/18 01:59, Fu, Siyuan wrote:
> Hi, Leif and Laszlo
> 
> 
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, November 6, 2018 6:12 AM
>> To: Leif Lindholm ; Fu, Siyuan
>> 
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] [PATCH v1 0/7] Delete TCP, PXE, iSCSI driver in
>> MdeModulePkg.
>>
>> Hi Leif,
>>
>> On 10/31/18 11:59, Leif Lindholm wrote:
>>> Hi Fu Siyuan,
>>>
>>> Hmm, strange.
>>>
>>> Ming Huang (cc) has also had issues with this in his latest set (but
>>> not before). Can you guys work together to try to figure out what is
>>> going wrong?
>>>
>>> Can you start by testing with an older version of git?
>>
>> this is indeed a git regression. I ran into it myself recently, when I
>> upgraded git from v2.14.1 to v2.19.1. I dug a little into the git source
>> code, but couldn't spend much time on it. Ultimately I rolled back the
>> upgrade.
>>
>> The diffstats are still well-formed (not truncated) in the individual
>> patch emails, under v2.19.1, as long as the "recommended" options are
>> used on the cmdline. However, the cumulative diffstat is truncated
>> regardless. I couldn't convince git v2.19.1 to keep the previous
>> (desired) behavior.
> 
> So should I rollback my Git to v2.14.1, or the new truncated cumulative
> diffstat is also acceptable?

Leif identified the culprit git patch as commit 43662b23abbd
("format-patch: keep cover-letter diffstat wrapped in 72 columns",
2018-01-25), and that commit was part of release v2.17.0.

Therefore, if you could roll back to v2.16.5 (the latest stable release
of v2.16), that should mitigate this issue.

(I haven't checked whether running upstream v2.16.* binaries is
advisable from a security perspective.)

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

Re: [edk2] [PATCH V3 4/4] MdeModulePkg EhciDxe: Use common buffer for AsyncInterruptTransfer

2018-11-06 Thread Zeng, Star

On 2018/11/6 17:49, Ard Biesheuvel wrote:

On 31 October 2018 at 05:38, Zeng, Star wrote:

Good feedback.

On 2018/10/30 20:50, Leif Lindholm wrote:

On Tue, Oct 30, 2018 at 09:39:24AM -0300, Ard Biesheuvel wrote:

(add back the list)

Oi! Go back on holiday!

On 30 October 2018 at 09:07, Cohen, Eugene wrote:

Has this patch been tested on a system that does not have coherent DMA?

It's not clear that this change would actually be faster on a system of
that
type since using common buffers imply access to uncached memory.
Depending
on the access patterns the uncached memory access could be more time
consuming than cache maintenance operations.

The change/idea was based on the statement below.
///
/// Provides both read and write access to system memory by both the
processor and a
/// bus master. The buffer is coherent from both the processor's and the
bus master's point of view.
///
EfiPciIoOperationBusMasterCommonBuffer,

Thanks for raising case about uncached memory access. But after checking the
code, for Intel VTd case
https://github.com/tianocore/edk2/blob/master/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/BmDma.c#L460
(or no IOMMU case
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c#L1567),
the common buffer is just normal memory buffer.
If someone can help do some test/collect some data on a system using common
buffers imply access to uncached memory, that will be great.

OK, so first of all, can anyone explain to me under which
circumstances interrupt transfers are a bottleneck? I'd assume that
anything throughput bound would use bulk endpoints.

Also, since the Map/Unmap calls are only costly when using an IOMMU,
could we simply revert to the old behavior if mIoMmu == NULL?

I haven't had time to look at these patches yet.

I agree with Eugene's concern: the directional DMA routines are much
more performant on implementations with non-coherent DMA, and so
common buffers should be avoided unless we are dealing with data
structures that are truly shared between the CPU and the device.

Since this is obviously not the case here, could we please have some
numbers about the performance improvement we are talking about here?
Would it be possible to improve the IOMMU handling code instead?

We collected the data below on a platform with release image and Intel VTd
enabled.

The image size of EhciDxe or XhciDxe can reduce about 120+ bytes.

EHCI without the patch:
==[ Cumulative ]
(Times in microsec.) Cumulative Average ShortestLongest
Name Count DurationDurationDurationDuration
---
SB00D1DF04462150 4 2 963

EHCI with the patch:
==[ Cumulative ]
(Times in microsec.) Cumulative Average ShortestLongest
Name Count DurationDurationDurationDuration
---
SB00D1DF0270 742 2 2 41

XHCI without the patch:
==[ Cumulative ]
(Times in microsec.) Cumulative Average ShortestLongest
Name Count DurationDurationDurationDuration
---
SB00D14F0215 603 2 2 52

XHCI with the patch:
==[ Cumulative ]
(Times in microsec.) Cumulative Average ShortestLongest
Name Count DurationDurationDurationDuration
---
SB00D14F0 95 294 3 2 52

I believe the performance data really depends on
1. How many AsyncInterruptTransfer handlers (the number of USB keyboard
and/or USB bluetooth keyboard?)
2. Data size (for flushing data from PCI controller specific address to
mapped system memory address *in original code*)
3. The performance of IoMmu->SetAttribute (for example, the SetAttribute
operation on Intel VTd engine caused by the unmap and map for flushing data
*in original code*, the SetAttribute operation on IntelVTd engine will
involve FlushPageTableMemory, InvalidatePageEntry and etc)

OK, so there is room for improvement here: there is no reason the
IOMMU driver couldn't cache mappings, or do some other optimizations
that would make mapping the same memory repeatedly less costly.

The unmap/map with IOMMU will direct to SetAttribute that will
disallow/allow DMA memory access. The IOMMU driver is hard to predict
the sequence of unmap/map operations. Do you have more detail about the
optimizations?

Could you take a try with the patch on the platform for the case you and
Eugene mentioned?

Anyway, I am going to revert the patches (3/4 and 4/4, since 1/4 and 2/4
have no

[edk2] [PATCH 1/2] Revert "EhciDxe: Use common buffer for AsyncInterruptTransfer"

2018-11-06 Thread Star Zeng

There is concern at the thread
https://lists.01.org/pipermail/edk2-devel/2018-November/031951.html.
And the time point is a little sensitive as it is near edk2-stable201811.

This reverts commit 0cd645250306b244a5d6e0e293ed1786ec101641.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c  |  3 --
 MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c | 78 +++-
 MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c   | 38 ++--
 MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h   | 33 ++
 4 files changed, 95 insertions(+), 57 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c 
b/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c
index 764eeda58ba1..5569f4f9618b 100644
--- a/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c
+++ b/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c
@@ -763,7 +763,6 @@ EhcControlTransfer (
   Translator,
   EHC_CTRL_TRANSFER,
   Request,
-  FALSE,
   Data,
   *DataLength,
   NULL,
@@ -907,7 +906,6 @@ EhcBulkTransfer (
   Translator,
   EHC_BULK_TRANSFER,
   NULL,
-  FALSE,
   Data[0],
   *DataLength,
   NULL,
@@ -1165,7 +1163,6 @@ EhcSyncInterruptTransfer (
   Translator,
   EHC_INT_TRANSFER_SYNC,
   NULL,
-  FALSE,
   Data,
   *DataLength,
   NULL,
diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c 
b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
index b067fd02d1ce..ec8d796fab11 100644
--- a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
+++ b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
@@ -778,6 +778,7 @@ EhciDelAsyncIntTransfer (
   EhcUnlinkQhFromPeriod (Ehc, Urb->Qh);
   RemoveEntryList (>UrbList);
 
+  gBS->FreePool (Urb->Data);
   EhcFreeUrb (Ehc, Urb);
   return EFI_SUCCESS;
 }
@@ -808,6 +809,7 @@ EhciDelAllAsyncIntTransfers (
 EhcUnlinkQhFromPeriod (Ehc, Urb->Qh);
 RemoveEntryList (>UrbList);
 
+gBS->FreePool (Urb->Data);
 EhcFreeUrb (Ehc, Urb);
   }
 }
@@ -846,8 +848,16 @@ EhciInsertAsyncIntTransfer (
   IN UINTN  Interval
   )
 {
+  VOID  *Data;
   URB   *Urb;
 
+  Data = AllocatePool (DataLen);
+
+  if (Data == NULL) {
+DEBUG ((DEBUG_ERROR, "%a: failed to allocate buffer\n", __FUNCTION__));
+return NULL;
+  }
+
   Urb = EhcCreateUrb (
   Ehc,
   DevAddr,
@@ -858,8 +868,7 @@ EhciInsertAsyncIntTransfer (
   Hub,
   EHC_INT_TRANSFER_ASYNC,
   NULL,
-  TRUE,
-  NULL,
+  Data,
   DataLen,
   Callback,
   Context,
@@ -868,6 +877,7 @@ EhciInsertAsyncIntTransfer (
 
   if (Urb == NULL) {
 DEBUG ((DEBUG_ERROR, "%a: failed to create URB\n", __FUNCTION__));
+gBS->FreePool (Data);
 return NULL;
   }
 
@@ -882,6 +892,60 @@ EhciInsertAsyncIntTransfer (
 }
 
 /**
+  Flush data from PCI controller specific address to mapped system
+  memory address.
+
+  @param  EhcThe EHCI device.
+  @param  UrbThe URB to unmap.
+
+  @retval EFI_SUCCESSSuccess to flush data to mapped system memory.
+  @retval EFI_DEVICE_ERROR   Fail to flush data to mapped system memory.
+
+**/
+EFI_STATUS
+EhcFlushAsyncIntMap (
+  IN  USB2_HC_DEV *Ehc,
+  IN  URB *Urb
+  )
+{
+  EFI_STATUSStatus;
+  EFI_PHYSICAL_ADDRESS  PhyAddr;
+  EFI_PCI_IO_PROTOCOL_OPERATION MapOp;
+  EFI_PCI_IO_PROTOCOL   *PciIo;
+  UINTN Len;
+  VOID  *Map;
+
+  PciIo = Ehc->PciIo;
+  Len   = Urb->DataLen;
+
+  if (Urb->Ep.Direction == EfiUsbDataIn) {
+MapOp = EfiPciIoOperationBusMasterWrite;
+  } else {
+MapOp = EfiPciIoOperationBusMasterRead;
+  }
+
+  Status = PciIo->Unmap (PciIo, Urb->DataMap);
+  if (EFI_ERROR (Status)) {
+goto ON_ERROR;
+  }
+
+  Urb->DataMap = NULL;
+
+  Status = PciIo->Map (PciIo, MapOp, Urb->Data, , , );
+  if (EFI_ERROR (Status) || (Len != Urb->DataLen)) {
+goto ON_ERROR;
+  }
+
+  Urb->DataPhy  = (VOID *) ((UINTN) PhyAddr);
+  Urb->DataMap  = Map;
+  return EFI_SUCCESS;
+
+ON_ERROR:
+  return EFI_DEVICE_ERROR;
+}
+
+
+/**
   Update the queue head for next round of asynchronous transfer.
 
   @param  Ehc   The EHCI device.
@@ -986,6 +1050,7 @@ EhcMonitorAsyncRequests (
   BOOLEAN Finished;
   UINT8   *ProcBuf;
   URB *Urb;
+  EFI_STATUS  Status;
 
   OldTpl  = gBS->RaiseTPL (EHC_TPL);
   Ehc = (USB2_HC_DEV *) Context;
@@ -1004,6 +1069,15 @@ EhcMonitorAsyncRequests (
 }
 
 //
+// Flush any PCI posted write transactions from a PCI host
+// bridge to system memory.
+//
+Status = EhcFlushAsyncIntMap (Ehc, Urb);
+if (EFI_ERROR (Status)) {
+  DEBUG ((EFI_D_ERROR, "EhcMonitorAsyncRequests: Fail to Flush AsyncInt 
Mapped Memeory\n"));
+}
+
+//

Re: [edk2] [PATCH v1 0/7] Delete TCP, PXE, iSCSI driver in MdeModulePkg.

On 11/06/18 12:02, Leif Lindholm wrote:
> On Mon, Nov 05, 2018 at 11:12:20PM +0100, Laszlo Ersek wrote:
>>> Ming Huang (cc) has also had issues with this in his latest set (but
>>> not before). Can you guys work together to try to figure out what is
>>> going wrong?
>>>
>>> Can you start by testing with an older version of git?
>>
>> this is indeed a git regression. I ran into it myself recently, when I
>> upgraded git from v2.14.1 to v2.19.1. I dug a little into the git source
>> code, but couldn't spend much time on it. Ultimately I rolled back the
>> upgrade.
> 
> Argh.
> 
>> The diffstats are still well-formed (not truncated) in the individual
>> patch emails, under v2.19.1, as long as the "recommended" options are
>> used on the cmdline. However, the cumulative diffstat is truncated
>> regardless. I couldn't convince git v2.19.1 to keep the previous
>> (desired) behavior.
>>
>> "Documentation/RelNotes/2.17.0.txt" has some words on "diffstat".
> 
> Thanks for tracking this down. I've submitted a patch here:
> https://public-inbox.org/git/20181106104811.14625-1-leif.lindh...@linaro.org/T/#u

Awesome, I'll test it and report back on the git list.

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

[edk2] [PATCH 2/2] Revert "XhciDxe: Use common buffer for AsyncInterruptTransfer"

2018-11-06 Thread Star Zeng

There is concern at the thread
https://lists.01.org/pipermail/edk2-devel/2018-November/031951.html.
And the time point is a little sensitive as it is near edk2-stable201811.

This reverts commit 777920997152a2e68f664241f6080b64ff21edd6.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c  |   1 -
 MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 138 ---
 MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.h |  27 +++---
 3 files changed, 103 insertions(+), 63 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 64855a4c158c..7f64f9c7c982 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -769,7 +769,6 @@ XhcTransfer (
   MaximumPacketLength,
   Type,
   Request,
-  FALSE,
   Data,
   *DataLength,
   NULL,
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
index 9dd45e93a272..75959ae08363 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
@@ -118,18 +118,17 @@ ON_EXIT:
 /**
   Create a new URB for a new transaction.
 
-  @param  Xhc   The XHCI Instance
-  @param  BusAddr   The logical device address assigned by UsbBus 
driver
-  @param  EpAddrEndpoint addrress
-  @param  DevSpeed  The device speed
-  @param  MaxPacket The max packet length of the endpoint
-  @param  Type  The transaction type
-  @param  Request   The standard USB request for control transfer
-  @param  AllocateCommonBuffer  Indicate whether need to allocate common 
buffer for data transfer
-  @param  Data  The user data to transfer, NULL if 
AllocateCommonBuffer is TRUE
-  @param  DataLen   The length of data buffer
-  @param  Callback  The function to call when data is transferred
-  @param  Context   The context to the callback
+  @param  Xhc   The XHCI Instance
+  @param  BusAddr   The logical device address assigned by UsbBus driver
+  @param  EpAddrEndpoint addrress
+  @param  DevSpeed  The device speed
+  @param  MaxPacket The max packet length of the endpoint
+  @param  Type  The transaction type
+  @param  Request   The standard USB request for control transfer
+  @param  Data  The user data to transfer
+  @param  DataLen   The length of data buffer
+  @param  Callback  The function to call when data is transferred
+  @param  Context   The context to the callback
 
   @return Created URB or NULL
 
@@ -143,7 +142,6 @@ XhcCreateUrb (
   IN UINTN  MaxPacket,
   IN UINTN  Type,
   IN EFI_USB_DEVICE_REQUEST *Request,
-  IN BOOLEANAllocateCommonBuffer,
   IN VOID   *Data,
   IN UINTN  DataLen,
   IN EFI_ASYNC_USB_TRANSFER_CALLBACKCallback,
@@ -171,24 +169,8 @@ XhcCreateUrb (
   Ep->Type  = Type;
 
   Urb->Request  = Request;
-  if (AllocateCommonBuffer) {
-ASSERT (Data == NULL);
-Status = Xhc->PciIo->AllocateBuffer (
-   Xhc->PciIo,
-   AllocateAnyPages,
-   EfiBootServicesData,
-   EFI_SIZE_TO_PAGES (DataLen),
-   ,
-   0
-   );
-if (EFI_ERROR (Status) || (Data == NULL)) {
-  FreePool (Urb);
-  return NULL;
-}
-  }
   Urb->Data = Data;
   Urb->DataLen  = DataLen;
-  Urb->AllocateCommonBuffer = AllocateCommonBuffer;
   Urb->Callback = Callback;
   Urb->Context  = Context;
 
@@ -196,7 +178,7 @@ XhcCreateUrb (
   ASSERT_EFI_ERROR (Status);
   if (EFI_ERROR (Status)) {
 DEBUG ((EFI_D_ERROR, "XhcCreateUrb: XhcCreateTransferTrb Failed, Status = 
%r\n", Status));
-XhcFreeUrb (Xhc, Urb);
+FreePool (Urb);
 Urb = NULL;
   }
 
@@ -224,14 +206,6 @@ XhcFreeUrb (
 Xhc->PciIo->Unmap (Xhc->PciIo, Urb->DataMap);
   }
 
-  if (Urb->AllocateCommonBuffer) {
-Xhc->PciIo->FreeBuffer (
-  Xhc->PciIo,
-  EFI_SIZE_TO_PAGES (Urb->DataLen),
-  Urb->Data
-  );
-  }
-
   FreePool (Urb);
 }
 
@@ -290,14 +264,10 @@ XhcCreateTransferTrb (
   // No need to remap.
   //
   if ((Urb->Data != NULL) && (Urb->DataMap == NULL)) {
-if (Urb->AllocateCommonBuffer) {
-  MapOp = EfiPciIoOperationBusMasterCommonBuffer;
+if (((UINT8) (Urb->Ep.Direction)) == EfiUsbDataIn) {
+  MapOp = EfiPciIoOperationBusMasterWrite;
 } else {
-  if (((UINT8) (Urb->Ep.Direction)) == EfiUsbDataIn) {
-MapOp = EfiPciIoOperationBusMasterWrite;
-  } else {
-MapOp = EfiPciIoOperationBusMasterRead;
-  }
+  MapOp =

[edk2] [PATCH 0/2] Revert "EhciDxe/XhciDxe: Use common buffer for AsyncInterruptTransfer"

2018-11-06 Thread Star Zeng

There is concern at the thread
https://lists.01.org/pipermail/edk2-devel/2018-November/031951.html.
And the time point is a little sensitive as it is near edk2-stable201811.

Cc: Ruiyu Ni 
Cc: Hao Wu 
Cc: Jian J Wang 
Cc: Jiewen Yao 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 

Star Zeng (2):
  Revert "EhciDxe: Use common buffer for AsyncInterruptTransfer"
  Revert "XhciDxe: Use common buffer for AsyncInterruptTransfer"

 MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c  |   3 -
 MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c |  78 -
 MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c   |  38 +
 MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h   |  33 
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c  |   1 -
 MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 138 ---
 MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.h |  27 +++---
 7 files changed, 198 insertions(+), 120 deletions(-)

-- 
2.7.0.windows.1

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

Re: [edk2] [PATCH v1] NetworkPkg/TlsDxe: Fix failure to process multiple TLS records.

On 11/06/18 03:13, Wu, Jiaxin wrote:
> Already share the info @ https://bugzilla.tianocore.org/show_bug.cgi?id=1290

Awesome, thanks!
Laszlo

>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, November 6, 2018 2:33 AM
>> To: Wu, Jiaxin ; edk2-devel@lists.01.org
>> Cc: Ye, Ting ; Fu, Siyuan 
>> Subject: Re: [edk2] [PATCH v1] NetworkPkg/TlsDxe: Fix failure to process
>> multiple TLS records.
>>
>> On 10/31/18 06:42, Jiaxin Wu wrote:
>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1290.
>>>
>>> Current implementation failed to parse the multiple TLS record
>>> messages due to the incorrect pointer of TLS record header. This
>>> patch is to resolve that problem.
>>>
>>> Cc: Ye Ting 
>>> Cc: Fu Siyuan 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Wu Jiaxin 
>>> ---
>>>  NetworkPkg/TlsDxe/TlsImpl.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/NetworkPkg/TlsDxe/TlsImpl.c b/NetworkPkg/TlsDxe/TlsImpl.c
>>> index ea83dbd04f..2d4169b0a5 100644
>>> --- a/NetworkPkg/TlsDxe/TlsImpl.c
>>> +++ b/NetworkPkg/TlsDxe/TlsImpl.c
>>> @@ -142,11 +142,11 @@ TlsEncryptPacket (
>>>  }
>>>
>>>  BufferOutSize += ThisMessageSize;
>>>
>>>  BufferInPtr += TLS_RECORD_HEADER_LENGTH + ThisPlainMessageSize;
>>> -TempRecordHeader += ThisMessageSize;
>>> +TempRecordHeader = (TLS_RECORD_HEADER *)((UINT8
>> *)TempRecordHeader + ThisMessageSize);
>>>}
>>>
>>>FreePool (BufferIn);
>>>BufferIn = NULL;
>>>
>>> @@ -315,11 +315,11 @@ TlsDecryptPacket (
>>>  CopyMem (TempRecordHeader, RecordHeaderIn,
>> TLS_RECORD_HEADER_LENGTH);
>>>  TempRecordHeader->Length = ThisPlainMessageSize;
>>>  BufferOutSize += TLS_RECORD_HEADER_LENGTH +
>> ThisPlainMessageSize;
>>>
>>>  BufferInPtr += TLS_RECORD_HEADER_LENGTH + ThisCipherMessageSize;
>>> -TempRecordHeader += TLS_RECORD_HEADER_LENGTH +
>> ThisPlainMessageSize;
>>> +TempRecordHeader = (TLS_RECORD_HEADER *)((UINT8
>> *)TempRecordHeader + TLS_RECORD_HEADER_LENGTH +
>> ThisPlainMessageSize);
>>>}
>>>
>>>FreePool (BufferIn);
>>>BufferIn = NULL;
>>>
>>>
>>
>> What is the practical impact of this issue? In what scenario was it
>> encountered? What were the symptoms?
>>
>> I realize the patch may have been pushed by now -- please consider
>> adding the information to the BZ. (Or, please answer here, and then add
>> the message URL to the BZ.)
>>
>> Thanks
>> Laszlo

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

Re: [edk2] [PATCH v2 5/5] OvmfPkg: simply use the Bochs interface for vmsvga


On 6/11/18 14:36, Laszlo Ersek wrote:

On 11/06/18 12:47, Laszlo Ersek wrote:


... While we discuss this, I'll go ahead and push the first four
patches. The code being reverted is dead anyway. I'll report back about
the commit hashes.


Before pushing the first four patches, I regression-tested them as well.
Using: Cirrus, stdvga, and QXL. My QEMU version was
v3.0.0-1763-gb2f7a038bb4c. The machine type was "pc-q35-3.0".

For the first four patches:
- Regression-tested-by: Laszlo Ersek ,
- pushed them as commit range 62ea70e31285..328409ce8de7.


Thanks Laszlo!
A bit late, but 1-4 reviewed too.



Thanks
Laszlo


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

Re: [edk2] [PATCH v2 5/5] OvmfPkg: simply use the Bochs interface for vmsvga

On 11/06/18 12:47, Laszlo Ersek wrote:

> ... While we discuss this, I'll go ahead and push the first four
> patches. The code being reverted is dead anyway. I'll report back about
> the commit hashes.

Before pushing the first four patches, I regression-tested them as well.
Using: Cirrus, stdvga, and QXL. My QEMU version was
v3.0.0-1763-gb2f7a038bb4c. The machine type was "pc-q35-3.0".

For the first four patches:
- Regression-tested-by: Laszlo Ersek ,
- pushed them as commit range 62ea70e31285..328409ce8de7.

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

Re: [edk2] [PATCH v3 1/1] ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF.

On 6 November 2018 at 02:24, Fu Siyuan  wrote:
> V3:
> Remove duplicate library added in v2 patch, since ArmVirtPkg.dsc.inc
> already have them. Just remove the if...end there is enough.
>
> V2:
> Add missing library instance for NetworkPkg iSCSI driver.
>

Please don't put the patch revision history in the commit log. Put it
below the ---

> This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those
> ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively
> maintained and will be removed from edk2 master soon.
>
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Fu Siyuan 
> ---

... here ...

The patch looks fine to me

Reviewed-by: Ard Biesheuvel 

but please don't merge it until after the next stable tag has been created

>  ArmVirtPkg/ArmVirt.dsc.inc   |  2 --
>  ArmVirtPkg/ArmVirtQemu.dsc   | 10 +++---
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 10 +++---
>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 13 ++---
>  4 files changed, 12 insertions(+), 23 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index 70a0ac4d786c..ebabf3f47ec9 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -149,11 +149,9 @@ [LibraryClasses.common]
>#
># CryptoPkg libraries needed by multiple firmware features
>#
> -!if ($(SECURE_BOOT_ENABLE) == TRUE) || ($(NETWORK_IP6_ENABLE) == TRUE)
>IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
>OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> -!endif
>
>#
># Secure Boot dependencies
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 885c6b14b844..b3f1b23e3890 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -346,18 +346,14 @@ [Components.common]
>MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
>MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
>MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
> +  NetworkPkg/TcpDxe/TcpDxe.inf
> +  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +  NetworkPkg/IScsiDxe/IScsiDxe.inf
>  !if $(NETWORK_IP6_ENABLE) == TRUE
>NetworkPkg/Ip6Dxe/Ip6Dxe.inf
> -  NetworkPkg/TcpDxe/TcpDxe.inf
>NetworkPkg/Udp6Dxe/Udp6Dxe.inf
>NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
>NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
> -  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> -  NetworkPkg/IScsiDxe/IScsiDxe.inf
> -!else
> -  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> -  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
> -  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
>  !endif
>  !if $(HTTP_BOOT_ENABLE) == TRUE
>NetworkPkg/DnsDxe/DnsDxe.inf
> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
> b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> index a6390bd4b841..3316f982695f 100644
> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> @@ -126,18 +126,14 @@ [FV.FvMain]
>INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
>INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
>INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
> +  INF NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +  INF NetworkPkg/IScsiDxe/IScsiDxe.inf
> +  INF NetworkPkg/TcpDxe/TcpDxe.inf
>  !if $(NETWORK_IP6_ENABLE) == TRUE
>INF NetworkPkg/Ip6Dxe/Ip6Dxe.inf
> -  INF NetworkPkg/TcpDxe/TcpDxe.inf
>INF NetworkPkg/Udp6Dxe/Udp6Dxe.inf
>INF NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
>INF NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
> -  INF NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> -  INF NetworkPkg/IScsiDxe/IScsiDxe.inf
> -!else
> -  INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> -  INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
> -  INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
>  !endif
>  !if $(HTTP_BOOT_ENABLE) == TRUE
>INF NetworkPkg/DnsDxe/DnsDxe.inf
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index 434d6861a56f..4920a66f2fdb 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -67,6 +67,9 @@ [LibraryClasses.common]
>
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
> +  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> +  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
>
>  [BuildOptions.ARM.EDKII.SEC, BuildOptions.ARM.EDKII.BASE]
># Avoid MOVT/MOVW instruction pairs in code that may end up in the PIE
> @@ -335,18 +338,14 @@ [Components.common]
>MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
>MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
>MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
> +

Re: [edk2] How to build EDK2 project for ARM using LLVM tool chain

Hi Prem,

On Sat, Nov 03, 2018 at 02:11:32PM +0530, Prem Kumar wrote:
> Hi All,
>  Kindly provide your comments to build EDK2 project for ARM AARCH64/ARM
> using LLVM tools chain under Windows environment.
> 
> I've below tools,
>  - Visual Studio 2015

Visual Studio 2015 does not support AARCH64 (and possibly not ARM).
You need at least VS 2017 version 15.4. (This does not mean that all
versions of VS 2018 will work.)

Since this has not been a common way of building for ARM/AARCH64 in
the past, there are some aspects of the tree that may not build
cleanly (and some .asm files that are missing for AARCH64).

>  - LLVM 4.0

For LLVM on the whole, I would recommend building under WSL (Windows
Subsystem for Linux) rather than going down a more Windows-specific
route (of which I'm only aware of cygwin).

For building under WSL, you can follow the instructions at
https://github.com/tianocore/edk2-platforms#how-to-build-linux-environment

Regards,

Leif

> Any pointer is helpful to proceed further.
> 
> Note:
>  I'm able to build EDK2 project(Nt32Pkg) using Visual studio under Windows
> environment.
> 
> 
> --
> Thanks,
> Prem.
> ___
> 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] TimerLib - usable library on X64?

2018-11-06 Thread Knop, Ryszard

Hi everyone,
I'm trying to use TimerLib to precisely measure time elapsed between specific 
functions, and I'm having some issues trying to get it to work. On X64 
platforms all I get is (depending on the TimerLib impl I use) either zeroes 
from QueryPerformanceCounter (QueryPerformanceCounterProperties returns zeroes 
for all the counters, except the frequency which is always reported as 100Hz), 
or the platform hangs. I've tried a few TimerLib implementations and I'm a bit 
out of ideas by now. Am I doing something wrong in the code itself, or is there 
any concrete implementation that is known to work well?

Sources I'm using: 
https://gist.github.com/DragoonAethis/7df6d8fb35c4f1932ec42bacbcbf73a8

Thanks, Richard.


Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] MdeModulePkg/Core: fix ineffective guard page issue

On Sat, Nov 03, 2018 at 02:42:21PM +0800, Jian J Wang wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1295
> 
> This issue originates from following patch which allows to enable
> paging if PcdImageProtectionPolicy and PcdDxeNxMemoryProtectionPolicy
> (in addition to PcdSetNxForStack) are set to enable related features.
> 
>   5267926134d17e86672b84fd57b438f05ffa68e1
> 
> Due to above change, PcdImageProtectionPolicy will be set to 0 by
> default in many platforms, which, in turn, cause following code in
> MdeModulePkg\Core\Dxe\Misc\MemoryProtection.c fail the creation of
> notify event of CpuArchProtocol.
> 
> 1138:  if (mImageProtectionPolicy != 0 ||
>PcdGet64 (PcdDxeNxMemoryProtectionPolicy) != 0) {
> 1139:  Status = CoreCreateEvent (
> ...
> 1142: MemoryProtectionCpuArchProtocolNotify,
> ...
> 1145: );
> 
> Then following call flow won't be done and Guard pages will not be
> set as not-present in SetAllGuardPages() eventually.
> 
>MemoryProtectionCpuArchProtocolNotify()
> => HeapGuardCpuArchProtocolNotify()
> => SetAllGuardPages()
> 
> The solution is removing the if(...) statement so that the notify
> event will always be created and handler be registered. This won't
> cause unnecessary code execution because, in the notify event handler,
> the related PCDs like
> 
> PcdImageProtectionPolicy and
> PcdDxeNxMemoryProtectionPolicy
> 
> will be checked again to do its job.
> 
> Cc: Star Zeng 
> Cc: Jiewen Yao 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> index 30e5c5153c..30798b05b9 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> @@ -1135,7 +1135,6 @@ CoreInitializeMemoryProtection (
>ASSERT (GetPermissionAttributeForMemoryType (EfiBootServicesData) ==
>GetPermissionAttributeForMemoryType (EfiConventionalMemory));
>  
> -  if (mImageProtectionPolicy != 0 || PcdGet64 
> (PcdDxeNxMemoryProtectionPolicy) != 0) {
>Status = CoreCreateEvent (
>   EVT_NOTIFY_SIGNAL,
>   TPL_CALLBACK,
> @@ -1154,7 +1153,6 @@ CoreInitializeMemoryProtection (
>   
>   );
>ASSERT_EFI_ERROR(Status);
> -  }

And here we see why.
The indentation changes need to be part of this patch, not 1/2.

/
Leif

>  
>//
>// Register a callback to disable NULL pointer detection at EndOfDxe
> -- 
> 2.16.2.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 5/5] OvmfPkg: simply use the Bochs interface for vmsvga

I suggest the following:

On 11/02/18 04:24, yuchenlin via edk2-devel wrote:
> From: yuchenlin 
>
> BAR  |std vga |  vmsvga
> -
> 0|   Framebuffer  | I/O space
> 1|   Reserved | Framebuffer
> 2|   MMIO | FIFO
>
> Because of the PCI BARs difference between std vga and
> vmsvga, we can not simply recognize the "QEMU VMWare SVGA"
> as the QEMU_VIDEO_BOCHS_MMIO variant.
>
> Instead, we remain variant QEMU_VIDEO_VMWARE_SVGA, and use
> it for:
>
> (1) Get framebuffer from correct PCI BAR
> (2) Prevent using BAR2 for MMIO

[a] The commit message should be udpated as follows:

- We cannot recognize VMW SVGA as BOCHS because that would confuse the
  IsQxl setting in QemuVideoControllerDriverStart(),

- We cannot recognize VMW SVGA as BOCHS_MMIO because BAR2 on VMW SVGA is
  not the BOCHS MMIO BAR (we can only use port IO).

Therefore the list of reasons for which we should introduce
QEMU_VIDEO_VMWARE_SVGA should name three reasons: both of the currently
listed reasons, plus "prevent mis-recognizing VMW SVGA as QXL" as the
third one.

>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: yuchenlin 
> ---
>  OvmfPkg/QemuVideoDxe/Driver.c | 18 --
>  OvmfPkg/QemuVideoDxe/Gop.c|  3 ++-
>  OvmfPkg/QemuVideoDxe/Qemu.h   |  2 ++
>  3 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
> index 2304afd1e6..76d4a2d27e 100644
> --- a/OvmfPkg/QemuVideoDxe/Driver.c
> +++ b/OvmfPkg/QemuVideoDxe/Driver.c
> @@ -69,6 +69,12 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
>  0x1050,
>  QEMU_VIDEO_BOCHS_MMIO,
>  L"QEMU VirtIO VGA"
> +},{
> +PCI_CLASS_DISPLAY_VGA,
> +0x15ad,
> +0x0405,
> +QEMU_VIDEO_VMWARE_SVGA,
> +L"QEMU VMWare SVGA"
>  },{
>  0 /* end of list */
>  }
> @@ -256,6 +262,12 @@ QemuVideoControllerDriverStart (
>  goto ClosePciIo;
>}
>Private->Variant = Card->Variant;
> +  if (Private->Variant == QEMU_VIDEO_VMWARE_SVGA) {
> +Private->FrameBufferVramBarIndex = PCI_BAR_IDX1;
> +  } else {
> +Private->FrameBufferVramBarIndex = PCI_BAR_IDX0;
> +  }
> +
>
>//
>// IsQxl is based on the detected Card->Variant, which at a later point 
> might
> @@ -320,7 +332,8 @@ QemuVideoControllerDriverStart (
>// Check if accessing the bochs interface works.
>//
>if (Private->Variant == QEMU_VIDEO_BOCHS_MMIO ||
> -  Private->Variant == QEMU_VIDEO_BOCHS) {
> +  Private->Variant == QEMU_VIDEO_BOCHS ||
> +  Private->Variant == QEMU_VIDEO_VMWARE_SVGA) {
>  UINT16 BochsId;
>  BochsId = BochsRead(Private, VBE_DISPI_INDEX_ID);
>  if ((BochsId & 0xFFF0) != VBE_DISPI_ID0) {
> @@ -383,6 +396,7 @@ QemuVideoControllerDriverStart (
>  break;
>case QEMU_VIDEO_BOCHS_MMIO:
>case QEMU_VIDEO_BOCHS:
> +  case QEMU_VIDEO_VMWARE_SVGA:
>  Status = QemuVideoBochsModeSetup (Private, IsQxl);
>  break;
>default:
> @@ -764,7 +778,7 @@ ClearScreen (
>Private->PciIo->Mem.Write (
>  Private->PciIo,
>  EfiPciIoWidthFillUint32,
> -0,
> +Private->FrameBufferVramBarIndex,
>  0,
>  0x40 >> 2,
>  
> diff --git a/OvmfPkg/QemuVideoDxe/Gop.c b/OvmfPkg/QemuVideoDxe/Gop.c
> index d490fa7a2e..3abc5eeb36 100644
> --- a/OvmfPkg/QemuVideoDxe/Gop.c
> +++ b/OvmfPkg/QemuVideoDxe/Gop.c
> @@ -60,7 +60,7 @@ QemuVideoCompleteModeData (
>
>Private->PciIo->GetBarAttributes (
>  Private->PciIo,
> -0,
> +Private->FrameBufferVramBarIndex,
>  NULL,
>  (VOID**) 
>  );
> @@ -177,6 +177,7 @@ Routine Description:
>  break;
>case QEMU_VIDEO_BOCHS_MMIO:
>case QEMU_VIDEO_BOCHS:
> +  case QEMU_VIDEO_VMWARE_SVGA:
>  InitializeBochsGraphicsMode (Private, 
> [ModeData->InternalModeIndex]);
>  break;
>default:
> diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
> index d7da761705..3aac9eeca6 100644
> --- a/OvmfPkg/QemuVideoDxe/Qemu.h
> +++ b/OvmfPkg/QemuVideoDxe/Qemu.h
> @@ -92,6 +92,7 @@ typedef enum {
>QEMU_VIDEO_CIRRUS_5446,
>QEMU_VIDEO_BOCHS,
>QEMU_VIDEO_BOCHS_MMIO,
> +  QEMU_VIDEO_VMWARE_SVGA,
>  } QEMU_VIDEO_VARIANT;
>
>  typedef struct {
> @@ -120,6 +121,7 @@ typedef struct {
>QEMU_VIDEO_VARIANTVariant;
>FRAME_BUFFER_CONFIGURE*FrameBufferBltConfigure;
>UINTN FrameBufferBltConfigureSize;
> +  UINT8 FrameBufferVramBarIndex;
>  } QEMU_VIDEO_PRIVATE_DATA;
>
>  ///
>

[b] How about the following -- incremental, to be squashed -- patch:

> diff --git a/OvmfPkg/QemuVideoDxe/Driver.c

Re: [edk2] [PATCH] IntelFsp2WrapperPkg: Support FSP Dispatch mode

2018-11-06 Thread Yao, Jiewen

hi chasel
I think our guide is not to use #if, but use if()

Is there any special reason in this patch?


thank you!
Yao, Jiewen


> 在 2018年11月6日，下午5:22，Chiu, Chasel  写道：
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1300
> 
> Provides PCD selection for FSP Wrapper to support Dispatch
> mode. Also PcdFspmBaseAddress should support Dynamic for
> recovery scenario (multiple FSP-M binary in flash)
> 
> Test: Verified on internal platform and both API and
>  DISPATCH modes booted successfully.
> 
> Cc: Jiewen Yao 
> Cc: Desimone Nathaniel L 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu 
> ---
> IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c   | 16 ++--
> IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c   | 14 --
> IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf |  3 ++-
> IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf |  3 ++-
> IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec | 13 +++--
> 5 files changed, 41 insertions(+), 8 deletions(-)
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c 
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> index 7b7c5f5d86..8128a26873 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> @@ -3,7 +3,7 @@
>   register TemporaryRamDonePpi to call TempRamExit API, and register 
> MemoryDiscoveredPpi
>   notify to call FspSiliconInit API.
> 
> -  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
>   This program and the accompanying materials
>   are licensed and made available under the terms and conditions of the BSD 
> License
>   which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -65,7 +65,7 @@ PeiFspMemoryInit (
>   FspHobListPtr = NULL;
>   FspmUpdDataPtr = NULL;
> 
> -  FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32 
> (PcdFspmBaseAddress));
> +  FspmHeaderPtr = (FSP_INFO_HEADER *) FspFindFspHeader (PcdGet32 
> (PcdFspmBaseAddress));
>   DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
>   if (FspmHeaderPtr == NULL) {
> return EFI_DEVICE_ERROR;
> @@ -155,8 +155,20 @@ FspmWrapperInit (
> {
>   EFI_STATUS   Status;
> 
> +  Status = EFI_SUCCESS;
> +
> +#if FixedPcdGet8 (PcdFspModeSelection) == 1
>   Status = PeiFspMemoryInit ();
>   ASSERT_EFI_ERROR (Status);
> +#else
> +  PeiServicesInstallFvInfoPpi (
> +NULL,
> +(VOID *)(UINTN) PcdGet32 (PcdFspmBaseAddress),
> +(UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32 
> (PcdFspmBaseAddress))->FvLength,
> +NULL,
> +NULL
> +);
> +#endif
> 
>   return Status;
> }
> diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c 
> b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> index 70dac7a414..d11655df89 100644
> --- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> @@ -3,7 +3,7 @@
>   register TemporaryRamDonePpi to call TempRamExit API, and register 
> MemoryDiscoveredPpi
>   notify to call FspSiliconInit API.
> 
> -  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 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
> @@ -349,7 +349,17 @@ FspsWrapperPeimEntryPoint (
> {
>   DEBUG ((DEBUG_INFO, "FspsWrapperPeimEntryPoint\n"));
> 
> -  FspsWrapperInit ();
> +#if FixedPcdGet8 (PcdFspModeSelection) == 1
> +FspsWrapperInit ();
> +#else
> +PeiServicesInstallFvInfoPpi (
> +  NULL,
> +  (VOID *)(UINTN) PcdGet32 (PcdFspsBaseAddress),
> +  (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32 
> (PcdFspsBaseAddress))->FvLength,
> +  NULL,
> +  NULL
> +  );
> +#endif
> 
>   return EFI_SUCCESS;
> }
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf 
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> index 542356b582..b3776a80f3 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> @@ -6,7 +6,7 @@
> # register TemporaryRamDonePpi to call TempRamExit API, and register 
> MemoryDiscoveredPpi
> # notify to call FspSiliconInit API.
> #
> -#  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 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
> @@ -61,6 +61,7 @@
> [Pcd]
>   gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress ## CONSUMES
>

Re: [edk2] [PATCH v2 3/3] OvmfPkg: Replace obsoleted network drivers from platform DSC/FDF.

On 5 November 2018 at 23:46, Laszlo Ersek  wrote:
> On 11/05/18 11:49, Fu Siyuan wrote:
>> V2:
>> Add missed library instance for NetworkPkg iSCSI driver.
>>
>> This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those
>> ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively
>> maintained and will be removed from edk2 master soon.
>>
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Cc: Anthony Perard 
>> Cc: Julien Grall 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Fu Siyuan 
>> ---
>>  OvmfPkg/OvmfPkgIa32.dsc| 14 --
>>  OvmfPkg/OvmfPkgIa32.fdf| 10 +++---
>>  OvmfPkg/OvmfPkgIa32X64.dsc | 14 --
>>  OvmfPkg/OvmfPkgIa32X64.fdf | 10 +++---
>>  OvmfPkg/OvmfPkgX64.dsc | 14 --
>>  OvmfPkg/OvmfPkgX64.fdf | 10 +++---
>>  6 files changed, 21 insertions(+), 51 deletions(-)
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>> index 9f07e75050c0..7160e88eaee4 100644
>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>> @@ -189,9 +189,7 @@ [LibraryClasses]
>>  !endif
>>VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
>>
>> -!if $(NETWORK_IP6_ENABLE) == TRUE
>>TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
>> -!endif
>>
>>  !if $(HTTP_BOOT_ENABLE) == TRUE
>>HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
>> @@ -790,18 +788,14 @@ [Components]
>>MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
>>MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
>>MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
>> -!if $(NETWORK_IP6_ENABLE) == TRUE
>> -  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
>> +  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
>>NetworkPkg/TcpDxe/TcpDxe.inf
>> +  NetworkPkg/IScsiDxe/IScsiDxe.inf
>> +!if $(NETWORK_IP6_ENABLE) == TRUE
>> +  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
>>NetworkPkg/Udp6Dxe/Udp6Dxe.inf
>>NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
>>NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
>> -  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
>> -  NetworkPkg/IScsiDxe/IScsiDxe.inf
>> -!else
>> -  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
>> -  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
>> -  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
>>  !endif
>>  !if $(HTTP_BOOT_ENABLE) == TRUE
>>NetworkPkg/DnsDxe/DnsDxe.inf
>> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
>> index 52b8b1fea1fc..1bc2e73bde16 100644
>> --- a/OvmfPkg/OvmfPkgIa32.fdf
>> +++ b/OvmfPkg/OvmfPkgIa32.fdf
>> @@ -309,18 +309,14 @@ [FV.DXEFV]
>>INF  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
>>INF  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
>>INF  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
>> +  INF  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
>> +  INF  NetworkPkg/TcpDxe/TcpDxe.inf
>> +  INF  NetworkPkg/IScsiDxe/IScsiDxe.inf
>>  !if $(NETWORK_IP6_ENABLE) == TRUE
>>INF  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
>> -  INF  NetworkPkg/TcpDxe/TcpDxe.inf
>>INF  NetworkPkg/Udp6Dxe/Udp6Dxe.inf
>>INF  NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
>>INF  NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
>> -  INF  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
>> -  INF  NetworkPkg/IScsiDxe/IScsiDxe.inf
>> -!else
>> -  INF  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
>> -  INF  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
>> -  INF  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
>>  !endif
>>  !if $(HTTP_BOOT_ENABLE) == TRUE
>>INF  NetworkPkg/DnsDxe/DnsDxe.inf
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>> index a4eaeb808c6b..e83e7ffab5b5 100644
>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>> @@ -194,9 +194,7 @@ [LibraryClasses]
>>  !endif
>>VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
>>
>> -!if $(NETWORK_IP6_ENABLE) == TRUE
>>TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
>> -!endif
>>
>>  !if $(HTTP_BOOT_ENABLE) == TRUE
>>HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
>> @@ -799,18 +797,14 @@ [Components.X64]
>>MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
>>MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
>>MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
>> -!if $(NETWORK_IP6_ENABLE) == TRUE
>> -  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
>> +  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
>>NetworkPkg/TcpDxe/TcpDxe.inf
>> +  NetworkPkg/IScsiDxe/IScsiDxe.inf
>> +!if $(NETWORK_IP6_ENABLE) == TRUE
>> +  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
>>NetworkPkg/Udp6Dxe/Udp6Dxe.inf
>>NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
>>NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
>> -  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
>> -  NetworkPkg/IScsiDxe/IScsiDxe.inf
>> -!else
>> -  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
>> -  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
>> -  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
>>  !endif
>>  !if

Re: [edk2] [PATCH v1 0/7] Delete TCP, PXE, iSCSI driver in MdeModulePkg.

On Mon, Nov 05, 2018 at 11:12:20PM +0100, Laszlo Ersek wrote:
> > Ming Huang (cc) has also had issues with this in his latest set (but
> > not before). Can you guys work together to try to figure out what is
> > going wrong?
> > 
> > Can you start by testing with an older version of git?
> 
> this is indeed a git regression. I ran into it myself recently, when I
> upgraded git from v2.14.1 to v2.19.1. I dug a little into the git source
> code, but couldn't spend much time on it. Ultimately I rolled back the
> upgrade.

Argh.

> The diffstats are still well-formed (not truncated) in the individual
> patch emails, under v2.19.1, as long as the "recommended" options are
> used on the cmdline. However, the cumulative diffstat is truncated
> regardless. I couldn't convince git v2.19.1 to keep the previous
> (desired) behavior.
> 
> "Documentation/RelNotes/2.17.0.txt" has some words on "diffstat".

Thanks for tracking this down. I've submitted a patch here:
https://public-inbox.org/git/20181106104811.14625-1-leif.lindh...@linaro.org/T/#u
But I guess we'll just need to live with this for a while :/

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

Re: [edk2] [PATCH edk2-platforms 01/27] Platform/Microsoft: Add OpteeClientPkg dec

2018-11-06 Thread Sumit Garg

Hi Chris,

On Tue, 6 Nov 2018 at 07:23, Chris Co  wrote:
>
> Hi Sumit,
>
> > -Original Message-
> > From: Sumit Garg 
> >
> > Hi Chris,
> >
> > On Sat, 3 Nov 2018 at 05:25, Chris Co  wrote:
> > >
> > > Hi Sumit,
> > >
> > > > -Original Message-
> > > > From: Sumit Garg 
> > > >
> > > > + OP-TEE ML.
> > > >
> > > > On Fri, 2 Nov 2018 at 06:11, Chris Co 
> > wrote:
> > > > >
> > > > > Hi Sumit,
> > > > >
> > > > > Our full OpteeClientPkg has:
> > > > > - Our OpteeClientAPI implementation. I was monitoring the merge
> > > > > progress
> > > > on OpteeLib and will look into moving over now that it is available.
> > > > > - The fTPM and AuthVar TA binaries. In our current design, the TA
> > > > > binaries
> > > > are loaded at runtime. We could host the binaries themselves
> > > > elsewhere on the filesystem, but we do not want these binaries as
> > > > early/pseudo TAs. Is there a plan for OpteeLib to support loading full 
> > > > TAs?
> > > >
> > > > Early TAs [1] are basically full TAs only, running in Secure EL0 mode.
> > > > So instead of loading TA from normal world file-system, they are
> > > > linked into a special data section in the OP-TEE core blob.
> > > >
> > > > Also I don't think loading TAs dynamically especially during boot
> > > > makes much sense due to following reasons:
> > > > 1. Increased boot time.
> > > > 2. Fixed TAs like in your case which could be linked as early TAs as 
> > > > well.
> > > >
> > >
> > > We prefer to load TAs dynamically for a more flexible servicing story. My
> > understanding is that Early TAs are coupled with the OP-TEE binary itself, 
> > so
> > to update an Early TA, a new OP-TEE binary would need to be created and
> > pushed. We want to avoid rolling a new OP-TEE and only update the TA
> > binary in this scenario.
> > >
> >
> > Are you referring to run-time updates on the device in the field? If this 
> > is the
> > case then how do you think to update TAs, is it via some custom capsule
> > update method?
> >
>
> Yes, run-time TA updates. Currently, our fTPM and Authvar TAs get packaged 
> inside our UEFI binary. So an update to a TA means a UEFI update via firmware 
> capsule.
> The discussion of these TA binaries living on the filesystem were ideas we 
> were discussing internally but are not fully baked or committed to.
>

I would suggest you to keep TAs as part of firmware only (UEFI binary
in your case).

> > I do consider these TAs used during boot as essential secure services 
> > provided
> > by the secure firmware (OP-TEE in this case). So these TAs should be part of
> > firmware itself and updates for them should come through firmware capsule
> > updates only.
> >
>
> I agree in principle and I think I see where the misalignment is, mostly 
> coming from my end.
> The security guarantees (termed TCPS) we want to provide on the current 
> hardware we support (NXP i.MX6), mean OP-TEE becomes prohibitively difficult 
> to update. This is due to a hardware resource limitation (not enough fuse 
> space). If this limitation were not present, we could freely update OP-TEE 
> and package these TAs as EarlyTAs.
>

Now I understand where this requirement came from. It seems to be a
valid scenario where secure non-volatile memory is limited on a
particular platform.

> Info on TCPS (whitepaper at bottom of post) - 
> https://www.microsoft.com/en-us/microsoft-365/blog/2018/04/24/trusted-cyber-physical-systems-looks-to-protect-your-critical-infrastructure-from-modern-threats-in-the-world-of-iot/
>
> I'm not sure how you want to handle this from an OpteeLib vs custom platform 
> package perspective.
>

We could add this dynamic TA loading support in OpteeLib as optional,
enabled in a platform specific way.

Regards,
Sumit

> > > > And you mentioned filesystem, are you referring to root filesystem?
> > > >
> > >
> > > We have not implemented this yet, but we were thinking to have the TA
> > binaries present in the EFI partition.
> > >
> >
> > AFAIK, EFI partition is shared among Linux and UEFI. This provides Linux
> > access to secure firmware TAs that could be a security concern (denial of
> > service could be one of them).
> >
>
> Note - we are booting Windows, though your point here is still valid. The TAs 
> living in the filesystem is not what is implemented today. It was an idea we 
> were discussing internally.
>
> > > > > - We have two client drivers: a firmware TPM TA driver and an
> > > > authenticated variable TA driver. These talk through the
> > > > tee-supplicant to their respective TAs.
> > > > >
> > > >
> > > > Here from tee-supplicant apart from loading TAs, what other services
> > > > are you expecting? If you are looking for secure storage via RPMB,
> > > > that could be an enhancement to OpteeLib adding corresponding RPC
> > handling here [2].
> > > >
> > >
> > > For RPC handling, we are looking for the following callback support:
> > > - OPTEE_SMC_RPC_FUNC_ALLOC
> > > - OPTEE_SMC_RPC_FUNC_FREE
> > > - OPTEE_SMC_RPC_FUNC_CMD
> >

[edk2] [edk2-test][PATCH] uefi-sct/SctPkg: Framework: Enhanced Null Pointer Checks.

2018-11-06 Thread Sakar Arora

On some AARCH64 Platforms, after all the tests are completed there was a
synchronous exception and it was found to be NULL pointer access issue.

Add additional NULL Pointer checks to resolve the exception.

Signed-off-by: Sakar Arora 
Reported-by: Chandni Cherukuri 
---
 .../TestInfrastructure/SCT/Framework/Data/SkippedCase.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Data/SkippedCase.c 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Data/SkippedCase.c
index b0cb1e9..c4a16c0 100644
--- a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Data/SkippedCase.c
+++ b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Data/SkippedCase.c
@@ -99,7 +99,10 @@ Returns:
   EFI_STATUS  Status;
   UINT32  Order = 0;
 
-  if (ExecuteInfo == NULL) {
+  if ( (ExecuteInfo == NULL) ||
+   (ExecuteInfo->TestCase == NULL) ||
+   (ExecuteInfo->Category == NULL) ||
+   (ExecuteInfo->SkippedCase == NULL) ) {
 return EFI_INVALID_PARAMETER;
   }
 
@@ -302,10 +305,16 @@ Returns:
   //
   // Check parameters
   //
-  if ((DevicePath == NULL) || (FileName == NULL) || (ExecuteInfo == NULL)) {
+  if ( (DevicePath == NULL) || (FileName == NULL) ) {
 return EFI_INVALID_PARAMETER;
   }
 
+  if ( (ExecuteInfo == NULL) ||
+   (ExecuteInfo->TestCase == NULL) ||
+   (ExecuteInfo->Category == NULL) ||
+   (ExecuteInfo->SkippedCase == NULL) ) {
+return EFI_INVALID_PARAMETER;
+  }
   //
   // Debug information
   //
-- 
2.7.4

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

[edk2] [edk2-test][PATCH] uefi-sct/SctPkg: Add script to automatically generate test file structure.

2018-11-06 Thread Sakar Arora

From: John Powell 

When new_test.py is run with no options, it asks the user a series
of questions about the test they wish to create and then creates the test
file structure, files, shell functions, and entries in build system
configuration files.

When run with the option -g or --guid, it just generates a GUID in a form
that matches the format used in code.

Signed-off-by: John Powell 
---
 uefi-sct/SctPkg/TestCreationScript/data.xml|  23 ++
 uefi-sct/SctPkg/TestCreationScript/new_test.py | 398 +
 .../SctPkg/TestCreationScript/template_BBTest.inf  |  81 +
 .../TestCreationScript/template_BBTestFunction.c   | 123 +++
 .../TestCreationScript/template_BBTestFunction.h   |  69 
 .../TestCreationScript/template_BBTestMain.c   | 130 +++
 .../TestCreationScript/template_BBTestMain.h   |  88 +
 uefi-sct/SctPkg/TestCreationScript/template_Guid.c |  61 
 uefi-sct/SctPkg/TestCreationScript/template_Guid.h |  66 
 9 files changed, 1039 insertions(+)
 create mode 100644 uefi-sct/SctPkg/TestCreationScript/data.xml
 create mode 100755 uefi-sct/SctPkg/TestCreationScript/new_test.py
 create mode 100644 uefi-sct/SctPkg/TestCreationScript/template_BBTest.inf
 create mode 100644 uefi-sct/SctPkg/TestCreationScript/template_BBTestFunction.c
 create mode 100644 uefi-sct/SctPkg/TestCreationScript/template_BBTestFunction.h
 create mode 100644 uefi-sct/SctPkg/TestCreationScript/template_BBTestMain.c
 create mode 100644 uefi-sct/SctPkg/TestCreationScript/template_BBTestMain.h
 create mode 100644 uefi-sct/SctPkg/TestCreationScript/template_Guid.c
 create mode 100644 uefi-sct/SctPkg/TestCreationScript/template_Guid.h

diff --git a/uefi-sct/SctPkg/TestCreationScript/data.xml 
b/uefi-sct/SctPkg/TestCreationScript/data.xml
new file mode 100644
index 000..2824d10
--- /dev/null
+++ b/uefi-sct/SctPkg/TestCreationScript/data.xml
@@ -0,0 +1,23 @@
+
+
+
+GenericTest
+Generic
+71652D04-BF38-434A-BCB8-6547D7FD8384
+
+
+BootServicesTest
+BootServices
+E9EF7553-F833-4E56-96E8-38AE679523CC
+
+
+RuntimeServicesTest
+RuntimeServices
+AFF115FB-387B-4c18-8C41-6AFC7F03BB90
+
+
+ProtocolTest
+Protocol
+None
+
+
\ No newline at end of file
diff --git a/uefi-sct/SctPkg/TestCreationScript/new_test.py 
b/uefi-sct/SctPkg/TestCreationScript/new_test.py
new file mode 100755
index 000..3f2f43e
--- /dev/null
+++ b/uefi-sct/SctPkg/TestCreationScript/new_test.py
@@ -0,0 +1,398 @@
+#!/usr/bin/env python
+
+import os
+import sys
+import shutil
+import fileinput
+import datetime
+import uuid
+import xml.etree.ElementTree
+from collections import namedtuple
+import re
+import argparse
+
+# configuration file paths
+
+path_to_sctpkg = "../"
+path_to_efi_categories = "TestCase/UEFI/EFI/"
+path_to_xml = "data.xml"
+
+# test configuration variables
+
+ConfigCategory = ""
+ConfigFileGuid = ""
+ConfigTestName = ""
+ConfigTestDescription = ""
+ConfigTestGuid = ""
+ConfigTestCaseName = ""
+ConfigTestCaseGuid = ""
+ConfigTestCaseDescription = ""
+ConfigAssertionGuid = ""
+ConfigProtocolGuid = ""
+ConfigCGFWCategory = ""
+
+# checkpoint variables so the script can undo changes in the event of some 
failure
+CheckPointCreatedFileStructure = False
+CheckPointCreatedNewCategoryIni = False
+CheckPointCreatedNewCommonGenFrameworkSh = False
+
+#function declarations
+
+def isInt(s):
+try:
+int(s)
+return True
+except ValueError:
+return False
+
+def isHex(s):
+try:
+int(s, 16)
+return True
+except ValueError:
+return False
+
+def openFile(path, options):
+try:
+file = open(path, options)
+return file
+except IOError:
+return None
+
+def replaceTextPlaceholderInFile(inFilePath):
+now = datetime.datetime.now()
+
+renamedInFilePath = ("%s.old" % inFilePath)
+os.rename(inFilePath, renamedInFilePath)
+
+inFile = openFile(inFilePath, "w")
+if inFile == None:
+print "ERROR: Could not open \"%s\"" % inFilePath
+return 1
+
+renamedInFile = openFile(renamedInFilePath, "r")
+if inFile == None:
+print "ERROR: Could not open \"%s\"" % renamedInFilePath
+return 1
+
+for line in renamedInFile:
+line = line.replace("$$", ("%d" % now.year))
+line = line.replace("$$", getHyphenGuid(ConfigFileGuid))
+line = line.replace("$$", ConfigTestName)
+line = line.replace("$$", ConfigTestName.upper())
+line = line.replace("$$", ConfigTestDescription)
+line = line.replace("$$", ConfigTestCaseName)
+line = line.replace("$$", 
ConfigTestCaseName.upper())
+line = line.replace("$$", 
ConfigTestCaseDescription)
+line = line.replace("$$", 
getCodeGuid(ConfigTestCaseGuid))
+line = line.replace("$$", 
getCodeGuid(ConfigAssertionGuid))
+if ConfigCategory.name ==

[edk2] [edk2-test][PATCH] uefi-sct/SctPkg: Fix issues with EfiCompliant test

2018-11-06 Thread Sakar Arora

From: John Powell 

Fixed errors occurring when an unsupported protocol is under test, in
several places a call to LocateProtocol was assumed to be successful
and the results were used as such, which caused synchronous exceptions
when the calls failed and the code tried to use NULL pointers.

Change-Id: Iede062bc3da675dae72fa24ba167692914e7ded6
Signed-off-by: John Powell 
---
 .../BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c | 273 -
 1 file changed, 107 insertions(+), 166 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
index 17df564..fb8128e 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
@@ -1497,62 +1497,24 @@ CheckUefiNetworkApplication (
NULL,
(VOID **)
);
-  switch (Index) {
-case 0:
-  TempInterface->CreateChild(TempInterface, );
-  break;
-case 1:
-  TempInterface->CreateChild(TempInterface, );
-  break;
-case 2:
-  TempInterface->CreateChild(TempInterface, );
-  break;
-case 3:
-  TempInterface->CreateChild(TempInterface, );
-  break;
-case 4:
-  TempInterface->CreateChild(TempInterface, );
-  break;
-default:
-  TempInterface->CreateChild(TempInterface, );
-  }
-   
-  Status = gtBS->LocateProtocol (
-   [Index+7],
-   NULL,
-   (VOID **)
-   );
   if (!EFI_ERROR (Status)) {
-Value[Index+7] = TRUE;
+TempInterface->CreateChild (TempInterface, );
+
+Status = gtBS->LocateProtocol (
+ [Index+7],
+ NULL,
+ (VOID **)
+ );
+if (!EFI_ERROR (Status)) {
+  Value[Index+7] = TRUE;
+} else {
+  Value[Index+7] = FALSE;
+}
+ 
+TempInterface->DestroyChild (TempInterface, ChildHandle);
   } else {
 Value[Index+7] = FALSE;
   }
-   
-  switch (Index) {
-case 0:
-  TempInterface->DestroyChild(TempInterface, ChildHandle);
-  ChildHandle = NULL;
-  break;
-case 1:
-  TempInterface->DestroyChild(TempInterface, ChildHandle);
-  ChildHandle = NULL;
-  break;
-case 2:
-  TempInterface->DestroyChild(TempInterface, ChildHandle);
-  ChildHandle = NULL;
-  break;
-case 3:
-  TempInterface->DestroyChild(TempInterface, ChildHandle);
-  ChildHandle = NULL;
-  break;
-case 4:
-  TempInterface->DestroyChild(TempInterface, ChildHandle);
-  ChildHandle = NULL;
-  break;
-default:
-  TempInterface->DestroyChild(TempInterface, ChildHandle);
-  ChildHandle = NULL;
-  }
 } 
 
 AssertionType = NeedOrWarning (13, Value);
@@ -1695,55 +1657,24 @@ CheckUefiV6NetworkApplication (
NULL,
(VOID **) 
);
-  switch (Index) {
-case 0:
-  TempInterface->CreateChild(TempInterface, );
-  break;
-case 1:
-  TempInterface->CreateChild(TempInterface, );
-  break;
-case 2:
-  TempInterface->CreateChild(TempInterface, );
-  break;
-case 3:
-  TempInterface->CreateChild(TempInterface, );
-  break;
-default:
-  TempInterface->CreateChild(TempInterface, );
-  }
-
-  Status = gtBS->LocateProtocol (
-   [Index+5],
-   NULL,
-   (VOID **) 
-   );
   if (!EFI_ERROR (Status)) {
-Value[Index+5] = TRUE;
+TempInterface->CreateChild (TempInterface, );
+
+Status = gtBS->LocateProtocol (
+ [Index+5],
+ NULL,
+ (VOID **) 
+ );
+if (!EFI_ERROR (Status)) {
+  Value[Index+5] = TRUE;
+} else {
+  Value[Index+5] = FALSE;
+}
+
+TempInterface->DestroyChild (TempInterface, ChildHandle);
   } else {
 Value[Index+5] = FALSE;
   }
-  
-  switch (Index) {
-case 0:
-  TempInterface->DestroyChild(TempInterface, ChildHandle);
-  ChildHandle = NULL;
-  break;
-case 1:
-  TempInterface->DestroyChild(TempInterface, ChildHandle);
-  ChildHandle = NULL;
-  break;
-case 2:
-

Re: [edk2] [PATCH v2 4/5] Revert "OvmfPkg: VMWare SVGA display device register definitions"

On 11/02/18 04:24, yuchenlin via edk2-devel wrote:
> From: yuchenlin 
> 
> This reverts commit 9bcca53fe466cdff397578328d9d87d257aba493.
> 
> We reverted VMWare SVGA driver. We don't need these definitions too.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: yuchenlin 
> ---
>  OvmfPkg/Include/IndustryStandard/VmwareSvga.h | 104 --
>  1 file changed, 104 deletions(-)
>  delete mode 100644 OvmfPkg/Include/IndustryStandard/VmwareSvga.h

Verified similarly to the last two patches in the series.

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH v2 3/5] Revert "OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O."

On 11/02/18 04:24, yuchenlin via edk2-devel wrote:
> From: yuchenlin 
> 
> This reverts commit 05a5379458725234de8a05780fcb5da2c12680e4.
> 
> The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
> an I/O-type BAR which is laid out such that some register offsets are
> not aligned to the read/write width with which they are expected to be
> accessed. However, we reverted the initialization of VMWare SVGA device,
> we don't need such unaligned I/O.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: yuchenlin 
> ---
>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  6 --
>  OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c | 70 
>  OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c | 80 ---
>  OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h| 59 --
>  OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c | 78 --
>  OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c | 66 ---
>  6 files changed, 359 deletions(-)
>  delete mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c
>  delete mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c
>  delete mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h
>  delete mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c
>  delete mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c

Checked this the same way as patch v2 2/5.

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH v2 2/5] Revert "OvmfPkg/QemuVideoDxe: VMWare SVGA device support"

On 11/02/18 04:23, yuchenlin via edk2-devel wrote:
> From: yuchenlin 
> 
> This reverts commit c137d95081690d4877fbeb5f1856972e84ac32f2.
> 
> The VMWare SVGA model now -- since commit 104bd1dc70 in QEMU --
> falls back to stdvga (that is, Bochs) if we don't setup VMWare SVGA
> FIFO.
> 
> To simplify QemuVideoDxe, we don't intend to implement the VMWare SVGA
> FIFO setup feature. It means our current VMW SVGA driver code is
> basically dead. To simplify the problem, we will replace the old
> VMWare SVGA driver to Bochs interface. It should work on all QEMU
> version.
> 
> The first step for using Bochs interface is to revert old driver.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: yuchenlin 
> ---
>  OvmfPkg/QemuVideoDxe/Driver.c | 135 +
>  OvmfPkg/QemuVideoDxe/Gop.c|  65 +
>  OvmfPkg/QemuVideoDxe/Initialize.c | 157 --
>  OvmfPkg/QemuVideoDxe/Qemu.h   |  29 --
>  4 files changed, 7 insertions(+), 379 deletions(-)

I've reviewed this patch as follows:

- I determined that c137d95081690d4877fbeb5f1856972e84ac32f2 was indeed
the commit to revert at this point.

- I applied your series, on top of current master (@ 62ea70e31285),
using local branch name "yuchenlin_v2". Then I checked whether the state
just before c137d9508169 matched the state after this revert -- all
differences would have to be unrelated to the feature in question. My
command was:

  git diff --color \
c137d95081690d4877fbeb5f1856972e84ac32f2^..yuchenlin_v2~3 -- \
OvmfPkg/QemuVideoDxe/ \
OvmfPkg/Include/IndustryStandard/

The differences are indeed orthogonal, so this looks like a valid revert.

In addition, the patch itself looks good, plus OVMF continues to build
fine after this patch (for bisectability's sake).

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] IntelFsp2WrapperPkg: Support FSP Dispatch mode

2018-11-06 Thread Chasel, Chiu

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

Provides PCD selection for FSP Wrapper to support Dispatch
mode. Also PcdFspmBaseAddress should support Dynamic for
recovery scenario (multiple FSP-M binary in flash)

Test: Verified on internal platform and both API and
  DISPATCH modes booted successfully.

Cc: Jiewen Yao 
Cc: Desimone Nathaniel L 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chasel Chiu 
---
 IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c   | 16 ++--
 IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c   | 14 --
 IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf |  3 ++-
 IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf |  3 ++-
 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec | 13 +++--
 5 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
index 7b7c5f5d86..8128a26873 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
@@ -3,7 +3,7 @@
   register TemporaryRamDonePpi to call TempRamExit API, and register 
MemoryDiscoveredPpi
   notify to call FspSiliconInit API.
 
-  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -65,7 +65,7 @@ PeiFspMemoryInit (
   FspHobListPtr = NULL;
   FspmUpdDataPtr = NULL;
 
-  FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32 
(PcdFspmBaseAddress));
+  FspmHeaderPtr = (FSP_INFO_HEADER *) FspFindFspHeader (PcdGet32 
(PcdFspmBaseAddress));
   DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
   if (FspmHeaderPtr == NULL) {
 return EFI_DEVICE_ERROR;
@@ -155,8 +155,20 @@ FspmWrapperInit (
 {
   EFI_STATUS   Status;
 
+  Status = EFI_SUCCESS;
+
+#if FixedPcdGet8 (PcdFspModeSelection) == 1
   Status = PeiFspMemoryInit ();
   ASSERT_EFI_ERROR (Status);
+#else
+  PeiServicesInstallFvInfoPpi (
+NULL,
+(VOID *)(UINTN) PcdGet32 (PcdFspmBaseAddress),
+(UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32 
(PcdFspmBaseAddress))->FvLength,
+NULL,
+NULL
+);
+#endif
 
   return Status;
 }
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
index 70dac7a414..d11655df89 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
@@ -3,7 +3,7 @@
   register TemporaryRamDonePpi to call TempRamExit API, and register 
MemoryDiscoveredPpi
   notify to call FspSiliconInit API.
 
-  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 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
@@ -349,7 +349,17 @@ FspsWrapperPeimEntryPoint (
 {
   DEBUG ((DEBUG_INFO, "FspsWrapperPeimEntryPoint\n"));
 
-  FspsWrapperInit ();
+#if FixedPcdGet8 (PcdFspModeSelection) == 1
+FspsWrapperInit ();
+#else
+PeiServicesInstallFvInfoPpi (
+  NULL,
+  (VOID *)(UINTN) PcdGet32 (PcdFspsBaseAddress),
+  (UINT32)((EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PcdGet32 
(PcdFspsBaseAddress))->FvLength,
+  NULL,
+  NULL
+  );
+#endif
 
   return EFI_SUCCESS;
 }
diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
index 542356b582..b3776a80f3 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
@@ -6,7 +6,7 @@
 # register TemporaryRamDonePpi to call TempRamExit API, and register 
MemoryDiscoveredPpi
 # notify to call FspSiliconInit API.
 #
-#  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
+#  Copyright (c) 2014 - 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
@@ -61,6 +61,7 @@
 [Pcd]
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress ## CONSUMES
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspmUpdDataAddress  ## CONSUMES
+  gIntelFsp2WrapperTokenSpaceGuid.PcdFspModeSelection## CONSUMES
 
 [Sources]
   FspmWrapperPeim.c
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf 
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
index cd87a99c40..910286982b 100644
---

Re: [edk2] [PATCH V3 4/4] MdeModulePkg EhciDxe: Use common buffer for AsyncInterruptTransfer