[edk2-devel] [PATCH V3 1/3] MdeModulePkg: Extend the support keyboard type of Terminal console

[Gao, Zhichao]

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

A common terminal console software Putty support various types of
keyboard type, such as normal mode, Linux mode, Xterm R6, Vt400,
VT100+ and SCO. Refer to the link:
https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
---
 MdeModulePkg/Include/Guid/TtyTerm.h | 13 +
 MdeModulePkg/MdeModulePkg.dec   |  4 
 2 files changed, 17 insertions(+)

diff --git a/MdeModulePkg/Include/Guid/TtyTerm.h 
b/MdeModulePkg/Include/Guid/TtyTerm.h
index 844b9d..471a651d4d 100644
--- a/MdeModulePkg/Include/Guid/TtyTerm.h
+++ b/MdeModulePkg/Include/Guid/TtyTerm.h
@@ -4,6 +4,7 @@ provide support for modern *nix terminals.
 
 
 Copyright (c) 2015  Linaro Ltd.
+Copyright (c) 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -14,6 +15,18 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #define EFI_TTY_TERM_GUID\
 {0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 
0x94 } }
 
+#define EDKII_LINUX_TERM_GUID   \
+{0xe4364a7f, 0xf825, 0x430e, {0x9d, 0x3a, 0x9c, 0x9b, 0xe6, 0x81, 0x7c, 
0xa5 } }
+
+#define EDKII_XTERM_R6_GUID \
+{0xfbfca56b, 0xbb36, 0x4b78, {0xaa, 0xab, 0xbe, 0x1b, 0x97, 0xec, 0x7c, 
0xcb } }
+
+#define EDKII_VT400_GUID\
+{0x8e46, 0x3d49, 0x4a9d, {0xb8, 0x75, 0x3c, 0x08, 0x6f, 0x6a, 0xa2, 
0xbd } }
+
+#define EDKII_SCO_TERM_GUID \
+{0xfc7dd6e0, 0x813c, 0x434d, {0xb4, 0xda, 0x3b, 0xd6, 0x49, 0xe9, 0xe1, 
0x5a } }
+
 extern EFI_GUID gEfiTtyTermGuid;
 
 #endif
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 17beb45235..7f72c122fc 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -342,6 +342,10 @@
 
   ## Include/Guid/TtyTerm.h
   gEfiTtyTermGuid= { 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 
0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 }}
+  gEdkiiLinuxTermGuid= { 0xe4364a7f, 0xf825, 0x430e, {0x9d, 0x3a, 
0x9c, 0x9b, 0xe6, 0x81, 0x7c, 0xa5 }}
+  gEdkiiXtermR6Guid  = { 0xfbfca56b, 0xbb36, 0x4b78, {0xaa, 0xab, 
0xbe, 0x1b, 0x97, 0xec, 0x7c, 0xcb }}
+  gEdkiiVT400Guid= { 0x8e46, 0x3d49, 0x4a9d, {0xb8, 0x75, 
0x3c, 0x08, 0x6f, 0x6a, 0xa2, 0xbd }}
+  gEdkiiSCOTermGuid  = { 0xfc7dd6e0, 0x813c, 0x434d, {0xb4, 0xda, 
0x3b, 0xd6, 0x49, 0xe9, 0xe1, 0x5a }}
 
   ## Include/Guid/HiiBootMaintenanceFormset.h
   gEfiIfrBootMaintenanceGuid  = { 0xb2dedc91, 0xd59f, 0x48d2, { 0x89, 
0x8a, 0x12, 0x49, 0xc, 0x74, 0xa4, 0xe0 }}
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47456): https://edk2.groups.io/g/devel/message/47456
Mute This Topic: https://groups.io/mt/34184916/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 3/3] MdeModulePkg/BM_UI: Add the new terminal types to related menu

[Gao, Zhichao]

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

Add the new introduced terminal types to related setup menu to change
the terminal type from setup. Most platforms would have its own
configure setup menu and they need to change it to support these.
The new introduced terminal types are Linux, XtermR6, VT400 and SCO.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
---
 .../BootMaintenanceManager.h  | 12 ---
 .../BootMaintenanceManagerStrings.uni | 10 +-
 .../ConsoleOption.c   | 35 ++-
 .../BootMaintenanceManagerUiLib/Data.c| 16 ++---
 4 files changed, 39 insertions(+), 34 deletions(-)

diff --git 
a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
index ea3cdce794..67847d8bf3 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
@@ -1,7 +1,7 @@
 /** @file
 Header file for boot maintenance module.
 
-Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -92,7 +92,11 @@ typedef enum _TYPE_OF_TERMINAL {
   TerminalTypeVt100,
   TerminalTypeVt100Plus,
   TerminalTypeVtUtf8,
-  TerminalTypeTtyTerm
+  TerminalTypeTtyTerm,
+  TerminalTypeLinux,
+  TerminalTypeXtermR6,
+  TerminalTypeVt400,
+  TerminalTypeSCO
 } TYPE_OF_TERMINAL;
 
 //
@@ -1301,12 +1305,12 @@ extern BM_MENU_OPTION ConsoleOutMenu;
 extern BM_MENU_OPTION ConsoleErrMenu;
 extern BM_MENU_OPTION DriverMenu;
 extern BM_MENU_OPTION TerminalMenu;
-extern UINT16 TerminalType[5];
+extern UINT16 TerminalType[9];
 extern COM_ATTR   BaudRateList[19];
 extern COM_ATTR   DataBitsList[4];
 extern COM_ATTR   ParityList[5];
 extern COM_ATTR   StopBitsList[3];
-extern EFI_GUID   TerminalTypeGuid[5];
+extern EFI_GUID   TerminalTypeGuid[9];
 extern EFI_DEVICE_PATH_PROTOCOL   EndDevicePath[];
 extern UINT16 mFlowControlType[2];
 extern UINT32 mFlowControlValue[2];
diff --git 
a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerStrings.uni
 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerStrings.uni
index 2e67d27bd0..3d47473e6c 100644
--- 
a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerStrings.uni
+++ 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerStrings.uni
@@ -1,7 +1,7 @@
 ///** @file
 //  String definitions for Boot Maintenance Utility.
 //
-//  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
+//  Copyright (c) 2004 - 2019, Intel Corporation. All rights reserved.
 //  SPDX-License-Identifier: BSD-2-Clause-Patent
 //
 //**/
@@ -233,6 +233,14 @@
#language fr-FR  "VT_UTF8"
 #string STR_COM_TYPE_4 #language en-US  "TTY_TERM"
#language fr-FR  "TTY_TERM"
+#string STR_COM_TYPE_5 #language en-US  "LINUX"
+   #language fr-FR  "LINUX"
+#string STR_COM_TYPE_6 #language en-US  "XTERM_R6"
+   #language fr-FR  "XTERM_R6"
+#string STR_COM_TYPE_7 #language en-US  "VT_400"
+   #language fr-FR  "VT_400"
+#string STR_COM_TYPE_8 #language en-US  "SCO"
+   #language fr-FR  "SCO"
 #string STR_RESET  #language en-US  "Reset System"
#language fr-FR  "Reset System"
 #string STR_FORM_GOTO_MAIN #language en-US  "Go Back To Main Page"
diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c
index 7a53b58771..b0641c5ee9 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/ConsoleOption.c
@@ -897,6 +897,7 @@ IsTerminalDevicePath (
   VENDOR_DEVICE_PATH*Vendor;
   UART_DEVICE_PATH  *Uart;
   ACPI_HID_DEVICE_PATH  *Acpi;
+  UINTN Index;
 
   IsTerminal = FALSE;
 
@@ -929,37 +930,21 @@ IsTerminalDevicePath (
   }
 
   //
-  // There are four kinds of Terminal types
+  // There are 9 kinds of Terminal types
   // check to see whether this devicepath
   // is one of that type
   //
-  if (CompareGuid (>Guid, [0])) {
-*Termi  = TerminalTypePcAnsi;
-IsTerminal  = TRUE;
-  } else {
-if (CompareGuid 

[edk2-devel] [PATCH V3 2/3] MdeModulePkg/TerminalDxe: Extend the terminal console support types

[Gao, Zhichao]

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

Extend the support types of terminal console driver. New added types
are Linux, XtermR6, VT400 and SCO.

Refer to
https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys

Add the missing VT100+ function keys map.

Add F1-F12 function keys map for Linux, XtermR6, VT400 and SCO.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Liming Gao 
Signed-off-by: Zhichao Gao 
---
 .../Universal/Console/TerminalDxe/Terminal.c  |  17 +-
 .../Universal/Console/TerminalDxe/Terminal.h  |  37 ++-
 .../Console/TerminalDxe/TerminalConIn.c   | 282 --
 .../Console/TerminalDxe/TerminalConOut.c  |   4 +
 .../Console/TerminalDxe/TerminalDxe.inf   |   6 +-
 5 files changed, 320 insertions(+), 26 deletions(-)

diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c 
b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
index c76b2c5100..fd26e4dafe 100644
--- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
+++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
@@ -2,7 +2,7 @@
   Produces Simple Text Input Protocol, Simple Text Input Extended Protocol and
   Simple Text Output Protocol upon Serial IO Protocol.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -28,7 +28,11 @@ EFI_GUID  *mTerminalType[] = {
   ,
   ,
   ,
-  
+  ,
+  ,
+  ,
+  ,
+  
 };
 
 
@@ -37,7 +41,11 @@ CHAR16 *mSerialConsoleNames[] = {
   L"VT-100 Serial Console",
   L"VT-100+ Serial Console",
   L"VT-UTF8 Serial Console",
-  L"Tty Terminal Serial Console"
+  L"Tty Terminal Serial Console",
+  L"Linux Terminal Serial Console",
+  L"Xterm R6 Serial Console",
+  L"VT-400 Serial Console",
+  L"SCO Terminal Serial Console"
 };
 
 TERMINAL_DEV  mTerminalDevTemplate = {
@@ -187,7 +195,8 @@ TerminalDriverBindingSupported (
 
   }
   //
-  // only supports PC ANSI, VT100, VT100+, VT-UTF8, and TtyTerm terminal 
types
+  // only supports PC ANSI, VT100, VT100+, VT-UTF8, TtyTerm
+  // Linux, XtermR6, VT400 and SCO terminal types
   //
   if (TerminalTypeFromGuid (>Guid) == ARRAY_SIZE (mTerminalType)) {
 return EFI_UNSUPPORTED;
diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h 
b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
index b2f0901fc1..d683aa792f 100644
--- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
+++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for Terminal driver.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 Copyright (C) 2016 Silicon Graphics, Inc. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -81,7 +81,11 @@ typedef enum {
   TerminalTypeVt100,
   TerminalTypeVt100Plus,
   TerminalTypeVtUtf8,
-  TerminalTypeTtyTerm
+  TerminalTypeTtyTerm,
+  TerminalTypeLinux,
+  TerminalTypeXtermR6,
+  TerminalTypeVt400,
+  TerminalTypeSCO
 } TERMINAL_TYPE;
 
 typedef struct {
@@ -126,7 +130,9 @@ typedef struct {
 #define INPUT_STATE_LEFTOPENBRACKET   0x04
 #define INPUT_STATE_O 0x08
 #define INPUT_STATE_2 0x10
-#define INPUT_STATE_LEFTOPENBRACKET_2 0x20
+#define INPUT_STATE_LEFTOPENBRACKET_TTY   0x20
+#define INPUT_STATE_1 0x40
+#define INPUT_STATE_LEFTOPENBRACKET_2ND   0x80
 
 #define RESET_STATE_DEFAULT   0x00
 #define RESET_STATE_ESC_R 0x01
@@ -848,7 +854,8 @@ TerminalRemoveConsoleDevVariable (
 /**
   Build termial device path according to terminal type.
 
-  @param  TerminalType   The terminal type is PC ANSI, VT100, VT100+ 
or VT-UTF8.
+  @param  TerminalType   The terminal type is PC ANSI, VT100, VT100+, 
VT-UTF8, TTY-Term,
+ Linux, XtermR6, VT400 and SCO.
   @param  ParentDevicePath   Parent device path.
   @param  TerminalDevicePath Returned terminal device path, if building 
successfully.
 
@@ -1209,6 +1216,28 @@ AnsiRawDataToUnicode (
   | F12 | 0x16 |   | ESC @|  |
   +=+==+===+==+==+
 
+Putty function key map:
+  
+=+==+===+=+=+=+=+
+  | | EFI  |   | | | | 
|
+  | | Scan |   | |  Normal | | 
|
+  |   KEY   | Code |  VT100+   | Xterm R6|  VT400  | Linux   | SCO 
|
+  
+=+==+===+=+=+=+=+
+  | F1  | 0x0B | ESC O P   | ESC O P | ESC [ 1 1 ~ | ESC [ [ A   | ESC 
[ M |
+  | F2  | 0x0C | ESC O Q   | ESC O Q | ESC [ 1 2 ~ | ESC [ [ B   | ESC 
[ N |
+  | F3  | 0x0D | ESC O R   | 

[edk2-devel] [PATCH V3 0/3] MdeModulePkg/TerminalConsole: Extend the support terminal types

[Gao, Zhichao]

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

Putty is a very popular terminal tool in windows. So add the whole support
terminal keyboard type for it. The new introduced type is Linux, XtermR6,
VT400 and SCO. And enhance the support for VT100+.
This patch set only add the support of function key. Refer to the link:
https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys

V2:
Fix typo.
Merge the type guid defination into TtyTerm.h.

V3:
Fix incorrect removal of Ttyterm parse.
Change the guid name of terminal type linux and SCO to clear ones:
LinuxTerm and SCOTerm.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
Cc: Liming Gao 
Signed-of-by: Zhichao Gao 

Zhichao Gao (3):
  MdeModulePkg: Extend the support keyboard type of Terminal console
  MdeModulePkg/TerminalDxe: Extend the terminal console support types
  MdeModulePkg/BM_UI: Add the new terminal types to related menu

 MdeModulePkg/Include/Guid/TtyTerm.h   |  13 +
 .../BootMaintenanceManager.h  |  12 +-
 .../BootMaintenanceManagerStrings.uni |  10 +-
 .../ConsoleOption.c   |  35 +--
 .../BootMaintenanceManagerUiLib/Data.c|  16 +-
 MdeModulePkg/MdeModulePkg.dec |   4 +
 .../Universal/Console/TerminalDxe/Terminal.c  |  17 +-
 .../Universal/Console/TerminalDxe/Terminal.h  |  37 ++-
 .../Console/TerminalDxe/TerminalConIn.c   | 282 --
 .../Console/TerminalDxe/TerminalConOut.c  |   4 +
 .../Console/TerminalDxe/TerminalDxe.inf   |   6 +-
 11 files changed, 376 insertions(+), 60 deletions(-)

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47455): https://edk2.groups.io/g/devel/message/47455
Mute This Topic: https://groups.io/mt/34184915/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [patch v2 3/5] MdeModulePkg/UefiBootManager: Unload image on EFI_SECURITY_VIOLATION

[Gao, Zhichao]

Reviewed-by: Zhichao Gao 

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Dandan Bi
> Sent: Wednesday, September 18, 2019 11:06 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Gao, Zhichao ; Gao,
> Liming ; Laszlo Ersek 
> Subject: [edk2-devel] [patch v2 3/5] MdeModulePkg/UefiBootManager:
> Unload image on EFI_SECURITY_VIOLATION
> 
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval, the
> Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer the
> execution of an image, we can not treat EFI_SECURITY_VIOLATION like any
> other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly for
> the callers in UefiBootManagerLib which don't have the policy to defer the
> execution of the image.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Cc: Liming Gao 
> Cc: Laszlo Ersek 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> Signed-off-by: Dandan Bi 
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c  |  9 +
>  .../Library/UefiBootManagerLib/BmLoadOption.c | 11 ++-
>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c  | 11
> ++-
>  3 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> index 952033fc82..760d7647b8 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> @@ -1859,10 +1859,19 @@ EfiBootManagerBoot (
>  if (FilePath != NULL) {
>FreePool (FilePath);
>  }
> 
>  if (EFI_ERROR (Status)) {
> +  //
> +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an
> ImageHandle was created
> +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not
> be started right now.
> +  // If the caller doesn't have the option to defer the execution of an
> image, we should
> +  // unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +  //
> +  if (Status == EFI_SECURITY_VIOLATION) {
> +gBS->UnloadImage (ImageHandle);
> +  }
>//
>// Report Status Code with the failure status to indicate that the 
> failure to
> load boot option
>//
>BmReportLoadFailure
> (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
>BootOption->Status = Status;
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> index 07592f8ebd..af47b787d1 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> @@ -1,9 +1,9 @@
>  /** @file
>Load option library functions which relate with creating and processing 
> load
> options.
> 
> -Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
>  (C) Copyright 2015-2018 Hewlett Packard Enterprise Development LP
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> 
> @@ -1409,10 +1409,19 @@ EfiBootManagerProcessLoadOption (
>  FileSize,
>  
>  );
>  FreePool (FileBuffer);
> 
> +//
> +// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an
> ImageHandle was created
> +// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be
> started right now.
> +// If the caller doesn't have the option to defer the execution of an 
> image,
> we should
> +// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +//
> +if (Status == EFI_SECURITY_VIOLATION) {
> +  gBS->UnloadImage (ImageHandle);
> +}
>  if (!EFI_ERROR (Status)) {
>Status = gBS->HandleProtocol (ImageHandle,
> , (VOID **));
>ASSERT_EFI_ERROR (Status);
> 
>ImageInfo->LoadOptionsSize = LoadOption->OptionalDataSize; diff --git
> a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> index 6b8fb4d924..833e38c6fe 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> @@ -1,9 +1,9 @@
>  /** @file
>Misc library functions.
> 
> -Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
>  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> 
> @@ -491,10 +491,19 @@ EfiBootManagerDispatchDeferredImages 

Re: [edk2-devel] [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast

[Liming Gao]

Reviewed-by: Liming Gao 

>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Laszlo Ersek
>Sent: Wednesday, September 18, 2019 3:49 AM
>To: edk2-devel-groups-io 
>Cc: Gao, Liming ; Kinney, Michael D
>
>Subject: [edk2-devel] [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus
>cast
>
>The HandleProtocol() boot service takes an EFI_HANDLE, not an
>(EFI_HANDLE*). Remove the bogus cast in the
>InternalImageHandleToFvHandle() function.
>
>This is a semantic cleanup; there is no change in behavior.
>
>Cc: Liming Gao 
>Cc: Michael D Kinney 
>Signed-off-by: Laszlo Ersek 
>---
>
>Notes:
>lightly tested, most probably: it's practically impossible to build a
>platform without consuming DxeServicesLib
>
> MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>index c416b2dd8c65..0735b2f80400 100644
>--- a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>+++ b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
>@@ -49,7 +49,7 @@ InternalImageHandleToFvHandle (
>   ASSERT (ImageHandle != NULL);
>
>   Status = gBS->HandleProtocol (
>- (EFI_HANDLE *) ImageHandle,
>+ ImageHandle,
>  ,
>  (VOID **) 
>  );
>--
>2.19.1.3.g30247aa5d201
>
>
>
>-=-=-=-=-=-=
>Groups.io Links: You receive all messages sent to this group.
>
>View/Reply Online (#47404): https://edk2.groups.io/g/devel/message/47404
>Mute This Topic: https://groups.io/mt/34180218/1759384
>Group Owner: devel+ow...@edk2.groups.io
>Unsubscribe: https://edk2.groups.io/g/devel/unsub  [liming@intel.com]
>-=-=-=-=-=-=


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47453): https://edk2.groups.io/g/devel/message/47453
Mute This Topic: https://groups.io/mt/34180218/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [patch v2 4/5] MdeModulePkg/PlatformDriOverride: Unload image on EFI_SECURITY_VIOLATION

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Dandan Bi
> Sent: Wednesday, September 18, 2019 11:06 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Gao, Liming; Laszlo Ersek
> Subject: [edk2-devel] [patch v2 4/5] MdeModulePkg/PlatformDriOverride:
> Unload image on EFI_SECURITY_VIOLATION
> 
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer
> the execution of an image, we can not treat EFI_SECURITY_VIOLATION
> like any other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
> for the caller in PlatformDriOverrideDxe which don't have the policy to
> defer the execution of the image.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Liming Gao 
> Cc: Laszlo Ersek 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> Signed-off-by: Dandan Bi 
> ---
>  .../PlatformDriOverrideDxe/PlatDriOverrideLib.c   | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git
> a/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
> b/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
> index 2d3736b468..f91f038b7a 100644
> ---
> a/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
> +++
> b/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
> @@ -1,9 +1,9 @@
>  /** @file
>Implementation of the shared functions to do the platform driver vverride
> mapping.
> 
> -  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> 
>  #include "InternalPlatDriOverrideDxe.h"
> @@ -1484,10 +1484,19 @@ GetDriverFromMapping (
> );
>  ASSERT (DriverBinding != NULL);
>  DriverImageInfo->ImageHandle = ImageHandle;
>}
>  } else {
> +  //
> +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and
> an ImageHandle was created
> +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can
> not be started right now.
> +  // If the caller doesn't have the option to defer the 
> execution of an
> image, we should
> +  // unload image for the EFI_SECURITY_VIOLATION to avoid 
> resource
> leak.
> +  //
> +  if (Status == EFI_SECURITY_VIOLATION) {
> +gBS->UnloadImage (ImageHandle);
> +  }


Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu


>DriverImageInfo->UnLoadable = TRUE;
>DriverImageInfo->ImageHandle = NULL;
>  }
>}
>  }
> --
> 2.18.0.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47452): https://edk2.groups.io/g/devel/message/47452
Mute This Topic: https://groups.io/mt/34184009/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [patch v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: Unload image on EFI_SECURITY_VIOLATION

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Dandan Bi
> Sent: Wednesday, September 18, 2019 11:06 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Gao, Liming; Laszlo Ersek
> Subject: [edk2-devel] [patch v2 2/5] MdeModulePkg/DxeCapsuleLibFmp:
> Unload image on EFI_SECURITY_VIOLATION
> 
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer
> the execution of an image, we can not treat EFI_SECURITY_VIOLATION
> like any other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
> for the callers in DxeCapsuleLibFmp which don't have the policy to defer
> the execution of the image.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Liming Gao 
> Cc: Laszlo Ersek 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> Signed-off-by: Dandan Bi 
> ---
>  MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> index 95aa9de087..5dda561a04 100644
> --- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> +++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> @@ -1028,10 +1028,19 @@ StartFmpImage (
>ImageSize,
>
>);
>DEBUG((DEBUG_INFO, "FmpCapsule: LoadImage - %r\n", Status));
>if (EFI_ERROR(Status)) {
> +//
> +// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an
> ImageHandle was created
> +// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be
> started right now.
> +// If the caller doesn't have the option to defer the execution of an
> image, we should
> +// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +//
> +if (Status == EFI_SECURITY_VIOLATION) {
> +  gBS->UnloadImage (ImageHandle);
> +}


Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu


>  FreePool(DriverDevicePath);
>  return Status;
>}
> 
>DEBUG((DEBUG_INFO, "FmpCapsule: StartImage ...\n"));
> --
> 2.18.0.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47451): https://edk2.groups.io/g/devel/message/47451
Mute This Topic: https://groups.io/mt/34184007/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 0/1] BaseTools: Add more parameter checking for CopyFileOnChange()

[Steven Shi]

This patch is to add directory input parameter type checking and error message 
output
for method CopyFileOnChange.

V2:
Remove the redundant os.path.exists checking for better performance

V1:
Initial patch

Steven Shi (1):
  BaseTools: Add more parameter checking for CopyFileOnChange()

 BaseTools/Source/Python/Common/Misc.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.17.1.windows.2


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47449): https://edk2.groups.io/g/devel/message/47449
Mute This Topic: https://groups.io/mt/34184104/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 1/1] BaseTools: Add more parameter checking for CopyFileOnChange()

[Steven Shi]

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

The current CopyFileOnChange() method in Misc.py does not
accept the input SrcFile parameter as a dir, but the method
does not check the SrcFile is dir or not. This patch is to
add more input parameter type checking and error message output
for method CopyFileOnChange.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/Common/Misc.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index 714eb840ea..a488536cb4 100755
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -536,7 +536,8 @@ def CopyFileOnChange(SrcFile, Dst, FileLock=None):
 SrcFile = LongFilePath(SrcFile)
 Dst = LongFilePath(Dst)
 
-if not os.path.exists(SrcFile):
+if os.path.isdir(SrcFile):
+EdkLogger.error(None, FILE_COPY_FAILURE, ExtraData='CopyFileOnChange 
SrcFile is a dir, not a file: %s' % SrcFile)
 return False
 
 if os.path.isdir(Dst):
-- 
2.17.1.windows.2


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47450): https://edk2.groups.io/g/devel/message/47450
Mute This Topic: https://groups.io/mt/34184105/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [patch v2 5/5] ShellPkg: Unload image on EFI_SECURITY_VIOLATION

[Dandan Bi]

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in ShellPkg which don't have the policy to defer the
execution of the image.

Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Laszlo Ersek 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi 
Reviewed-by: Zhichao Gao 
---
 ShellPkg/Application/Shell/ShellManParser.c   |  9 +
 .../Library/UefiShellDebug1CommandsLib/LoadPciRom.c   | 11 ++-
 ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c| 11 ++-
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Application/Shell/ShellManParser.c 
b/ShellPkg/Application/Shell/ShellManParser.c
index 6909f29441..4d5a5668aa 100644
--- a/ShellPkg/Application/Shell/ShellManParser.c
+++ b/ShellPkg/Application/Shell/ShellManParser.c
@@ -643,10 +643,19 @@ ProcessManFile(
   goto Done;
 }
 DevPath = 
ShellInfoObject.NewEfiShellProtocol->GetDevicePathFromFilePath(CmdFilePathName);
 Status  = gBS->LoadImage(FALSE, gImageHandle, DevPath, NULL, 0, 
);
 if(EFI_ERROR(Status)) {
+  //
+  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+  // If the caller doesn't have the option to defer the execution of an 
image, we should
+  // unload image for the EFI_SECURITY_VIOLATION to avoid the resource 
leak.
+  //
+  if (Status == EFI_SECURITY_VIOLATION) {
+gBS->UnloadImage (CmdFileImgHandle);
+  }
   *HelpText = NULL;
   goto Done;
 }
 Status = gBS->OpenProtocol(
 CmdFileImgHandle,
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
index 1b169d0d3c..5b6cba17f3 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
@@ -1,10 +1,10 @@
 /** @file
   Main file for LoadPciRom shell Debug1 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 #include "UefiShellDebug1CommandsLib.h"
@@ -332,10 +332,19 @@ LoadEfiDriversFromRomImage (
 ImageBuffer,
 ImageLength,
 
);
   if (EFI_ERROR (Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not 
be started right now.
+// If the caller doesn't have the option to defer the execution of 
an image, we should
+// unload image for the EFI_SECURITY_VIOLATION to avoid resource 
leak.
+//
+if (Status == EFI_SECURITY_VIOLATION) {
+  gBS->UnloadImage (ImageHandle);
+}
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN 
(STR_LOADPCIROM_LOAD_FAIL), gShellDebug1HiiHandle, L"loadpcirom", FileName, 
ImageIndex);
 //PrintToken (STRING_TOKEN (STR_LOADPCIROM_LOAD_IMAGE_ERROR), 
HiiHandle, ImageIndex, Status);
   } else {
 Status = gBS->StartImage (ImageHandle, NULL, NULL);
 if (EFI_ERROR (Status)) {
diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
index 6a94b48c86..b6e7c952fa 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c
@@ -1,10 +1,10 @@
 /** @file
   Main file for attrib shell level 2 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 #include "UefiShellLevel2CommandsLib.h"
@@ -110,10 +110,19 @@ LoadDriver(
 NULL,
 0,
 );
 
   if (EFI_ERROR(Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+// If the caller doesn't have the option to defer 

[edk2-devel] [patch v2 3/5] MdeModulePkg/UefiBootManager: Unload image on EFI_SECURITY_VIOLATION

[Dandan Bi]

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in UefiBootManagerLib which don't have the policy to defer
the execution of the image.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Liming Gao 
Cc: Laszlo Ersek 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c  |  9 +
 .../Library/UefiBootManagerLib/BmLoadOption.c | 11 ++-
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c  | 11 ++-
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 952033fc82..760d7647b8 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -1859,10 +1859,19 @@ EfiBootManagerBoot (
 if (FilePath != NULL) {
   FreePool (FilePath);
 }
 
 if (EFI_ERROR (Status)) {
+  //
+  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+  // If the caller doesn't have the option to defer the execution of an 
image, we should
+  // unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+  //
+  if (Status == EFI_SECURITY_VIOLATION) {
+gBS->UnloadImage (ImageHandle);
+  }
   //
   // Report Status Code with the failure status to indicate that the 
failure to load boot option
   //
   BmReportLoadFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
   BootOption->Status = Status;
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 07592f8ebd..af47b787d1 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1,9 +1,9 @@
 /** @file
   Load option library functions which relate with creating and processing load 
options.
 
-Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
 (C) Copyright 2015-2018 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
@@ -1409,10 +1409,19 @@ EfiBootManagerProcessLoadOption (
 FileSize,
 
 );
 FreePool (FileBuffer);
 
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+// If the caller doesn't have the option to defer the execution of an 
image, we should
+// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+//
+if (Status == EFI_SECURITY_VIOLATION) {
+  gBS->UnloadImage (ImageHandle);
+}
 if (!EFI_ERROR (Status)) {
   Status = gBS->HandleProtocol (ImageHandle, , 
(VOID **));
   ASSERT_EFI_ERROR (Status);
 
   ImageInfo->LoadOptionsSize = LoadOption->OptionalDataSize;
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
index 6b8fb4d924..833e38c6fe 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
@@ -1,9 +1,9 @@
 /** @file
   Misc library functions.
 
-Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
@@ -491,10 +491,19 @@ EfiBootManagerDispatchDeferredImages (
 ImageDevicePath,
 NULL,
 0,
 
   );
+  //
+  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+  // If the caller doesn't have the option to defer the execution of an 
image, we should
+  // unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+  //
+  if (Status == EFI_SECURITY_VIOLATION) {
+gBS->UnloadImage (ImageHandle);
+  }
   if (!EFI_ERROR (Status)) {
 LoadCount++;
 //
 // Before calling 

[edk2-devel] [patch v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: Unload image on EFI_SECURITY_VIOLATION

[Dandan Bi]

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in DxeCapsuleLibFmp which don't have the policy to defer
the execution of the image.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 
Cc: Laszlo Ersek 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c 
b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
index 95aa9de087..5dda561a04 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
@@ -1028,10 +1028,19 @@ StartFmpImage (
   ImageSize,
   
   );
   DEBUG((DEBUG_INFO, "FmpCapsule: LoadImage - %r\n", Status));
   if (EFI_ERROR(Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+// If the caller doesn't have the option to defer the execution of an 
image, we should
+// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+//
+if (Status == EFI_SECURITY_VIOLATION) {
+  gBS->UnloadImage (ImageHandle);
+}
 FreePool(DriverDevicePath);
 return Status;
   }
 
   DEBUG((DEBUG_INFO, "FmpCapsule: StartImage ...\n"));
-- 
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47445): https://edk2.groups.io/g/devel/message/47445
Mute This Topic: https://groups.io/mt/34184007/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [patch v2 0/5] Unload image on EFI_SECURITY_VIOLATION

[Dandan Bi]

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

v2:
(1) Just separate the patch in MdeModulePkg into module level, the changes in 
EmbeddedPkg and ShellPkg are the same with V1.
(2) Drop the update in PciBusDxe module in MdeModulePkg since with 
EFI_SECURITY_VIOLATION returned, the image may be used later.


For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in edk2 which don't have the policy to defer the
execution of the image.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Zhichao Gao 
Cc: Laszlo Ersek 
Dandan Bi (3):
  EmbeddedPkg: Unload image on EFI_SECURITY_VIOLATION
  MdeModulePkg/DxeCapsuleLibFmp: Unload image on EFI_SECURITY_VIOLATION
  MdeModulePkg/UefiBootManager: Unload image on EFI_SECURITY_VIOLATION
  MdeModulePkg/PlatformDriOverride: Unload image on
EFI_SECURITY_VIOLATION
  ShellPkg: Unload image on EFI_SECURITY_VIOLATION

 .../AndroidFastboot/Arm/BootAndroidBootImg.c |  9 +
 .../Library/AndroidBootImgLib/AndroidBootImgLib.c| 12 
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c |  9 +
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c |  9 +
 .../Library/UefiBootManagerLib/BmLoadOption.c| 11 ++-
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 11 ++-
 .../PlatformDriOverrideDxe/PlatDriOverrideLib.c  | 11 ++-
 ShellPkg/Application/Shell/ShellManParser.c  |  9 +
 .../Library/UefiShellDebug1CommandsLib/LoadPciRom.c  | 11 ++-
 ShellPkg/Library/UefiShellLevel2CommandsLib/Load.c   | 11 ++-
 10 files changed, 98 insertions(+), 5 deletions(-)

-- 
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47443): https://edk2.groups.io/g/devel/message/47443
Mute This Topic: https://groups.io/mt/34184002/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [patch v2 4/5] MdeModulePkg/PlatformDriOverride: Unload image on EFI_SECURITY_VIOLATION

[Dandan Bi]

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the caller in PlatformDriOverrideDxe which don't have the policy to
defer the execution of the image.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 
Cc: Laszlo Ersek 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi 
---
 .../PlatformDriOverrideDxe/PlatDriOverrideLib.c   | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c 
b/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
index 2d3736b468..f91f038b7a 100644
--- a/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
+++ b/MdeModulePkg/Universal/PlatformDriOverrideDxe/PlatDriOverrideLib.c
@@ -1,9 +1,9 @@
 /** @file
   Implementation of the shared functions to do the platform driver vverride 
mapping.
 
-  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 #include "InternalPlatDriOverrideDxe.h"
@@ -1484,10 +1484,19 @@ GetDriverFromMapping (
);
 ASSERT (DriverBinding != NULL);
 DriverImageInfo->ImageHandle = ImageHandle;
   }
 } else {
+  //
+  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and 
an ImageHandle was created
+  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not 
be started right now.
+  // If the caller doesn't have the option to defer the execution 
of an image, we should
+  // unload image for the EFI_SECURITY_VIOLATION to avoid resource 
leak.
+  //
+  if (Status == EFI_SECURITY_VIOLATION) {
+gBS->UnloadImage (ImageHandle);
+  }
   DriverImageInfo->UnLoadable = TRUE;
   DriverImageInfo->ImageHandle = NULL;
 }
   }
 }
-- 
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47447): https://edk2.groups.io/g/devel/message/47447
Mute This Topic: https://groups.io/mt/34184009/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [patch v2 1/5] EmbeddedPkg: Unload image on EFI_SECURITY_VIOLATION

[Dandan Bi]

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.

But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.

This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in EmbeddedPkg which don't have the policy to defer the
execution of the image.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi 
Acked-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
---
 .../AndroidFastboot/Arm/BootAndroidBootImg.c |  9 +
 .../Library/AndroidBootImgLib/AndroidBootImgLib.c| 12 
 2 files changed, 21 insertions(+)

diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c 
b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
index 591afbe7cc..fe05878b4b 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
+++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
@@ -71,10 +71,19 @@ StartEfiApplication (
 
   // Load the image from the device path with Boot Services function
   Status = gBS->LoadImage (TRUE, ParentImageHandle, DevicePath, NULL, 0,
   );
   if (EFI_ERROR (Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+// If the caller doesn't have the option to defer the execution of an 
image, we should
+// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+//
+if (Status == EFI_SECURITY_VIOLATION) {
+  gBS->UnloadImage (ImageHandle);
+}
 return Status;
   }
 
   // Passed LoadOptions to the EFI Application
   if (LoadOptionsSize != 0) {
diff --git a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c 
b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
index d9e7aa7d2b..e1036954ee 100644
--- a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
+++ b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
@@ -439,10 +439,22 @@ AndroidBootImgBoot (
+ KernelSize;
 
   Status = gBS->LoadImage (TRUE, gImageHandle,
(EFI_DEVICE_PATH *),
(VOID*)(UINTN)Kernel, KernelSize, );
+  if (EFI_ERROR (Status)) {
+//
+// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
ImageHandle was created
+// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
started right now.
+// If the caller doesn't have the option to defer the execution of an 
image, we should
+// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
+//
+if (Status == EFI_SECURITY_VIOLATION) {
+  gBS->UnloadImage (ImageHandle);
+}
+return Status;
+  }
 
   // Set kernel arguments
   Status = gBS->HandleProtocol (ImageHandle, ,
 (VOID **) );
   ImageInfo->LoadOptions = NewKernelArg;
-- 
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47444): https://edk2.groups.io/g/devel/message/47444
Mute This Topic: https://groups.io/mt/34184004/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, September 18, 2019 3:49 AM
> To: edk2-devel-groups-io 
> Cc: Dong, Eric ; Wu, Hao A ;
> Wang, Jian J ; Ni, Ray 
> Subject: [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning
> consistent
> 
> The SmiHandlerRegister() function explicitly casts "SmiHandler" (of type
> (SMI_HANDLER*)) to EFI_HANDLE, when outputting "DispatchHandle".
> 
> Apply the same cast in the counterpart function SmiHandlerUnRegister(),
> which compares multiple "SmiHandler"s against the input "DispatchHandle".
> 
> This is a semantic cleanup; there is no functional change.
> 
> Cc: Eric Dong 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Cc: Ray Ni 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> build-tested only, most likely -- I'm unaware of any code paths in OVMF
> that would lead to SmiHandlerUnRegister()
> 
>  MdeModulePkg/Core/PiSmmCore/Smi.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
> b/MdeModulePkg/Core/PiSmmCore/Smi.c
> index f8bd9f49ee3c..488af6754faf 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
> @@ -282,7 +282,7 @@ SmiHandlerUnRegister (
>//
>SmiHandler = NULL;
>for ( HandlerLink = GetFirstNode ()
> -  ; !IsNull (, HandlerLink) && (SmiHandler !=
> DispatchHandle)
> +  ; !IsNull (, HandlerLink) &&
> + ((EFI_HANDLE) SmiHandler != DispatchHandle)
>; HandlerLink = GetNextNode (, HandlerLink)
>) {
>  SmiHandler = CR (HandlerLink, SMI_HANDLER, Link,
> SMI_HANDLER_SIGNATURE); @@ -292,19 +292,19 @@
> SmiHandlerUnRegister (
>// Look for it in non-root SMI handlers
>//
>for ( EntryLink = GetFirstNode ()
> -  ; !IsNull (, EntryLink) && (SmiHandler != DispatchHandle)
> +  ; !IsNull (, EntryLink) && ((EFI_HANDLE) SmiHandler
> + != DispatchHandle)
>; EntryLink = GetNextNode (, EntryLink)
>) {
>  SmiEntry = CR (EntryLink, SMI_ENTRY, AllEntries, SMI_ENTRY_SIGNATURE);
>  for ( HandlerLink = GetFirstNode (>SmiHandlers)
> -; !IsNull (>SmiHandlers, HandlerLink) && (SmiHandler !=
> DispatchHandle)
> +; !IsNull (>SmiHandlers, HandlerLink) &&
> + ((EFI_HANDLE) SmiHandler != DispatchHandle)
>  ; HandlerLink = GetNextNode (>SmiHandlers, HandlerLink)
>  ) {
>SmiHandler = CR (HandlerLink, SMI_HANDLER, Link,
> SMI_HANDLER_SIGNATURE);
>  }
>}
> 
> -  if (SmiHandler != DispatchHandle) {
> +  if ((EFI_HANDLE) SmiHandler != DispatchHandle) {
>  return EFI_INVALID_PARAMETER;
>}
> 
> --
> 2.19.1.3.g30247aa5d201
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47442): https://edk2.groups.io/g/devel/message/47442
Mute This Topic: https://groups.io/mt/34180216/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3] MinPlatformPkg/TestPointCheckLib: Add check for pointers

[Zhang, Shenglei]

In DxeCheckBootVariable.c, add check for BootOrder and Variable
that return EFI_NOT_FOUND when they are NULL.
In DxeCheckGcd.c, add check for GcdIoMap to ensure it not NULL
when allocating memory to what it points to.

Cc: Michael Kubacki 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Shenglei Zhang 
---

v2: Update copyright

v3: Fix the coding style.

 .../Test/Library/TestPointCheckLib/DxeCheckBootVariable.c | 8 +++-
 .../Test/Library/TestPointCheckLib/DxeCheckGcd.c  | 8 +---
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCheckBootVariable.c
 
b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCheckBootVariable.c
index 85bd5b3d..f658beb7 100644
--- 
a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCheckBootVariable.c
+++ 
b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCheckBootVariable.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2017-2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -130,6 +130,9 @@ TestPointCheckLoadOptionVariable (
   for (ListIndex = 0; ListIndex < 
sizeof(mLoadOptionVariableList)/sizeof(mLoadOptionVariableList[0]); 
ListIndex++) {
 UnicodeSPrint (BootOrderName, sizeof(BootOrderName), L"%sOrder", 
mLoadOptionVariableList[ListIndex]);
 Status = GetVariable2 (BootOrderName, , (VOID 
**), );
+if(BootOrder == NULL) {
+  return EFI_NOT_FOUND;
+}
 if (EFI_ERROR(Status)) {
   continue;
 }
@@ -222,6 +225,9 @@ TestPointCheckKeyOptionVariable (
 for (Index = 0; ; Index++) {
   UnicodeSPrint (KeyOptionName, sizeof(KeyOptionName), L"%s%04x", 
mKeyOptionVariableList[ListIndex], Index);
   Status = GetVariable2 (KeyOptionName, , 
, );
+  if(Variable == NULL) {
+return EFI_NOT_FOUND;
+  }
   if (!EFI_ERROR(Status)) {
 DumpKeyOption (KeyOptionName, Variable, Size);
   } else {
diff --git 
a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCheckGcd.c 
b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCheckGcd.c
index 82709d44..28ca8382 100644
--- a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCheckGcd.c
+++ b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCheckGcd.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2017-2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -241,11 +241,13 @@ TestPointDumpGcd (
   }
 }
 if (GcdMemoryMap != NULL) {
-  *GcdIoMap = AllocateCopyPool (NumberOfDescriptors * 
sizeof(EFI_GCD_IO_SPACE_DESCRIPTOR), IoMap);
+  if (GcdIoMap != NULL) {
+*GcdIoMap = AllocateCopyPool (NumberOfDescriptors * 
sizeof(EFI_GCD_IO_SPACE_DESCRIPTOR), IoMap);
+  }
   *GcdIoMapNumberOfDescriptors = NumberOfDescriptors;
 }
   }
-  
+
   if (DumpPrint) {
 DEBUG ((DEBUG_INFO, " TestPointDumpGcd - Exit\n"));
   }
-- 
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47441): https://edk2.groups.io/g/devel/message/47441
Mute This Topic: https://groups.io/mt/34183382/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/2] *** Add VS2019 Support ***

[Cheng, Ching JenX]

Hi Liming,

The VS2017 is still working fine with this changes,
I have verified it with VS2019, VS2017 and VS2015 build,

Thanks,
Allen

> -Original Message-
> From: Gao, Liming
> Sent: Tuesday, September 17, 2019 10:57 PM
> To: devel@edk2.groups.io; Cheng, Ching JenX
> 
> Subject: RE: [edk2-devel] [PATCH v2 0/2] *** Add VS2019 Support ***
> 
> Ching:
>   The change is good. With this change, have you verified VS2017 tool chain?
>   I want to make sure there is no impact on VS2017.
> 
> Thanks
> Liming
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Cheng, Ching JenX
> > Sent: Tuesday, September 17, 2019 11:23 AM
> > To: devel@edk2.groups.io; Cheng, Ching JenX
> > 
> > Subject: Re: [edk2-devel] [PATCH v2 0/2] *** Add VS2019 Support ***
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2182
> >
> > In order to support VS2019 on EDK2, the following patches was modified
> > def and batch files 1. Add VS2019 x86/64 definitions on tools_def.template
> 2. Add VS2019 support on toolsetup batches, and add version check with
> command vswhere
> >  Because VS2019 and VS2017 using the same vswhere to get the
> > InstallationPath
> >
> > v2: In 01/02, add ARM/AARCH64/EBC Definitions, Combine VS2017_HOST
> and
> > VS2019_HOST to VS_HOST
> >
> > Ching JenX Cheng (2):
> >   Add VS2019 Toolchain def
> >   Add VS2019 Support on ToolSetup Batches
> >
> >  BaseTools/Conf/tools_def.template | 220
> >
> ++
> ++
> ++
> >
> ++
> +---
> >  BaseTools/get_vsvars.bat  |  37
> ++---
> >  BaseTools/set_vsprefix_envs.bat   |  70
> ++
> +++-
> >  BaseTools/toolsetup.bat   |  16 +---
> >  edksetup.bat  |   6 --
> >  5 files changed, 313 insertions(+), 36 deletions(-)
> >
> > --
> > 2.21.0.windows.1
> >
> >
> >
> >
> >
> > 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47440): https://edk2.groups.io/g/devel/message/47440
Mute This Topic: https://groups.io/mt/34172665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs for Admin commands

[Wu, Hao A]

Hello Tyler,

I agree that the UEFI spec can be refined to explicitly mention the below 2 
fields:

* Input parameter 'NamespaceId' for the PassThru() service
* The 'Nsid' field of the EFI_NVM_EXPRESS_COMMAND

should match for the ‘PassThru’ service.

Best Regards,
Hao Wu

From: Tyler J Erickson [mailto:tyler.j.erick...@seagate.com]
Sent: Wednesday, September 18, 2019 12:50 AM
To: Wu, Hao A
Cc: devel@edk2.groups.io; Ni, Ray
Subject: Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow 
other NSIDs for Admin commands

Hi Hao,

Sorry for the late reply.
I tested and can confirm that if the NSID of the command and the provided 
NamespaceID as an input match, the commands do go through on the EDK2 driver. 
This is not the case with a driver built into a motherboard that I have here, 
as it only accepts values for the current NSID and nothing else. This is ok 
since I can load the EDK2 driver in place instead.

Since this is unclear in the documentation for the passthru function, can we 
make a documentation change instead?

Thanks,
-Tyler


On Wed, Sep 4, 2019 at 8:07 PM Wu, Hao A 
mailto:hao.a...@intel.com>> wrote:
Hello Tyler,

Some inline comments below.

Best Regards,
Hao Wu

From: Tyler J Erickson 
[mailto:tyler.j.erick...@seagate.com]
Sent: Wednesday, September 04, 2019 11:07 PM
To: Wu, Hao A
Cc: devel@edk2.groups.io; Ni, Ray
Subject: Re: [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs for 
Admin commands

Hi Hao,

I tried making both the NamespaceID and NSID values the same when calling the 
passthru function for these admin commands and it didn't work. I think that is 
due to another place in the passthru code filtering the NamespaceId input 
values on line 517-520.
The NamespaceId parameter is being checked to make sure it isn't greater than 
the number of supported namespaces by the controller and it makes sure it isn't 
set to (UINT32)-1 (All F's).


[Hao]: I think the check on line 517-520 blocks ‘NamespaceId’ with value 
greater than the number of namespace. But it allows the value to be MAX_UINT32, 
which means the command takes effect on all namespaces.


I think this is correct since the NamespaceId input is what is discovered when 
calling the EFI_NVM_EXPRESS_PASS_THRU_GET_NEXT_NAMESPACE function. This is what 
I used to get the available namespaces available in the system.

In my case I'm sending some commands in my application with the NSID set to 
UINT32_MAX in order to request controller wide SMART/Health log data among 
other things. There are some commands where setting the NSID to another value 
may also be useful. For example, DST can use the NSID in the command to change 
between testing only the controller (0), testing all namespaces (UINT32_MAX), 
and a specific namespace.


[Hao]: Yes. Just as you said, commands like DST or Get Log Page will have 
different target when different Namespace values are provided.
I think for your case, you can:

1.   Set both the 'NamespaceId' parameter and 'Nsid' field to 0 if the 
target is the controller;

2.   Set both of them MAX_UINT32 if the target is all the namespaces;

3.   Set both of them to a corresponding ID if the target is a specific 
namespace.

As you can see from the current implementation of NvmExpressPassThru() 
function, the 'NamespaceId' parameter does not affect the construct of the 
submission queue item.
The 'NamespaceId' parameter only serves as a valid check for the 'Nsid' field 
in the EFI_NVM_EXPRESS_COMMAND structure.


The modification I made was done where the passthru command's NSID was actually 
being checked, which seemed like the best place to add this exception for admin 
commands.

-Tyler


On Tue, Sep 3, 2019 at 9:39 PM Wu, Hao A 
mailto:hao.a...@intel.com>> wrote:
> -Original Message-
> From: Wu, Hao A
> Sent: Wednesday, September 04, 2019 11:39 AM
> To: devel@edk2.groups.io; Tyler Erickson
> Cc: Wu, Hao A; Ni, Ray
> Subject: [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs
> for Admin commands
>
> Repost the mail to the list.
>
> Best Regards,
> Hao Wu
>
> -Original Message-
> From: Tyler Erickson 
> [mailto:tyler.j.erick...@seagate.com]
> Sent: Tuesday, September 03, 2019 9:55 PM
> To: edk2-de...@lists.01.org
> Cc: Wu, Hao A; Ni, Ray
> Subject: [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs
> for Admin commands
>
> Cc: Hao A Wu mailto:hao.a...@intel.com>>
> Cc: Ray Ni mailto:ray...@intel.com>>
> Signed-off-by: Tyler Erickson 
> mailto:tyler.j.erick...@seagate.com>>
> ---
>  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
> index 8e721379466a..78a3c663ded4 100644
> --- 

[edk2-devel] [Patch V3] UefiCpuPkg/CpuExceptionHandlerLib: Fix split lock

[John E Lofgren]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2150
V3 changes:
change to mov instruction (non locking instuction) instead
of xchg to simplify design.

V2 changes:
Add xchg 16 bit instructions to handle sgdt and sidt base
63:48 bits and 47:32 bits.
Add comment to explain why xchg 64bit isnt being used

Split lock happens when a locking instruction is used on mis-aligned data
that crosses two cachelines. If close source platform enables Alignment Check
Exception(#AC), They can hit a double fault due to split lock being in
CpuExceptionHandlerLib.

sigt and sgdt saves 10 bytes to memory, 8 bytes is base and 2 bytes is limit.
The data is mis-aligned, can cross two cacheline, and a xchg
instruction(locking instuction) is being utilize.

Signed-off-by: John E Lofgren 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm | 20 
++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
index 4db1a09f28..7b7642b290 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
@@ -180,21 +180,29 @@ HasErrorCode:
 pushqword [rbp + 24]
 
 ;; UINT64  Gdtr[2], Idtr[2];
+; sidt and sgdt saves 10 bytes to memory, 8 bytes = base and 2 bytes = 
limit.
+; To avoid #AC split lock when separating base and limit into their
+; own separate 64 bit memory, we can’t use 64 bit xchg since base [63:48] 
bits
+; may cross the cache line.
 xor rax, rax
 pushrax
 pushrax
 sidt[rsp]
-xchgrax, [rsp + 2]
-xchgrax, [rsp]
-xchgrax, [rsp + 8]
+xchgeax, [rsp + 2]
+xchgeax, [rsp]
+xchgeax, [rsp + 8]
+xchg ax, [rsp + 6]
+xchg ax, [rsp + 4]
 
 xor rax, rax
 pushrax
 pushrax
 sgdt[rsp]
-xchgrax, [rsp + 2]
-xchgrax, [rsp]
-xchgrax, [rsp + 8]
+xchgeax, [rsp + 2]
+xchgeax, [rsp]
+xchgeax, [rsp + 8]
+xchg ax, [rsp + 6]
+xchg ax, [rsp + 4]
 
 ;; UINT64  Ldtr, Tr;
 xor rax, rax
-- 
2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47438): https://edk2.groups.io/g/devel/message/47438
Mute This Topic: https://groups.io/mt/34181976/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Updated Event: TianoCore Design Meeting - APAC/NAMO #cal-invite

[devel@edk2.groups.io Calendar]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:calendar.14...@groups.io
DTSTAMP:20190917T214934Z
ORGANIZER;CN=Stephano Cetola:mailto:stephano.cet...@intel.com
DTSTART;TZID=America/Los_Angeles:20190404T183000
DTEND;TZID=America/Los_Angeles:20190404T193000
RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=TH
SUMMARY:TianoCore Design Meeting - APAC/NAMO
DESCRIPTION:For more info, see here:\n\nhttps://www.tianocore.org/design-meeting/\n\nTo join the meeting on a computer or mobile phone:\n\nhttps://bluejeans.com/889357567?src=calendarLink ( https://bluejeans.com/889357567?src=calendarLink )\n\nPhone Dial-in\n\n+1.408.740.7256 (US (San Jose))\n\n+1.408.317.9253 (US (Primary, San Jose))\n\nGlobal Numbers: https://www.bluejeans.com/numbers ( https://www.bluejeans.com/numbers )\n\nMeeting ID: 889 357 567\n\nRoom System\n\n199.48.152.152 or bjn.vc\n\nMeeting ID: 889 357 567\n\nWant to test your video connection?\n\nhttps://bluejeans.com/111 ( https://bluejeans.com/111 )
LOCATION:BlueJeans Meeting
BEGIN:VALARM
ACTION:DISPLAY
CREATED:20190917T214934Z
DESCRIPTION:TianoCore Design Meeting - APAC/NAMO
TRIGGER:-PT5D
END:VALARM
BEGIN:VALARM
ACTION:DISPLAY
CREATED:20190917T214934Z
DESCRIPTION:TianoCore Design Meeting - APAC/NAMO
TRIGGER:-PT15M
END:VALARM
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] [PATCH v2] MinPlatformPkg/TestPointCheckLib: Add return value when OutTable is NULL

[Nate DeSimone]

Hi Shenglei,

Your explanation makes sense.

Reviewed-by: Nate DeSimone 

Thanks,
Nate

-Original Message-
From: Zhang, Shenglei  
Sent: Monday, September 16, 2019 7:48 PM
To: Desimone, Nathaniel L ; devel@edk2.groups.io
Cc: Kubacki, Michael A ; Chiu, Chasel 
; Gao, Liming 
Subject: RE: [PATCH v2] MinPlatformPkg/TestPointCheckLib: Add return value when 
OutTable is NULL

Hi Nathaniel,

Thanks for your comments and below is my response.

> -Original Message-
> From: Desimone, Nathaniel L
> Sent: Tuesday, September 17, 2019 3:25 AM
> To: Zhang, Shenglei ; devel@edk2.groups.io
> Cc: Kubacki, Michael A ; Chiu, Chasel 
> ; Gao, Liming 
> Subject: RE: [PATCH v2] MinPlatformPkg/TestPointCheckLib: Add return 
> value when OutTable is NULL
> 
> Hi Shenglei,
> 
> I don't see how this patch is at all related to the previous version of this 
> patch.

What is different from the previous version is that this patch update the 
copyright year and the "if...else" coding style.

> Also, you are introducing yet another new bug with this patch. 
> Moreover, this bug is unrelated to the previous bug.
> 
> Please take a look at the function TestPointGetAcpi(). With your 
> change added, this function is now broken since Table is a stack 
> variable and it is not being initialized to zero. This function 
> assumes that
> DumpAcpiXsdt()/DumpAcpiRsdt() will do the initialization to zero on 
> it's behalf, you have broken this assumption with your change.

I have taken a look at the function TestPointGetAcpi(). The variable Table is 
first initialized to NULL by DumpAcpiXsdt()/DumpAcpiRsdt(). The reference code 
is "*OutTable = NULL"(line 667). And it will be assigned a value next. The 
reference code is "*OutTable = Table"(line 689).

And with my changes, the stack variable Table(equivalent  to *OutTable in 
DumpAcpiXsdt/ DumpAcpiRsdt) can still be initialized to NULL or assigned a 
value. What I did is intended to check the address of "Table", since there is 
no point to perform operations to "Table" if its address is NULL.

Thanks,
Shenglei

> 
> Both this patch and the previous patch have been made carelessly and I 
> am not impressed.
> 
> Thanks,
> Nate
> 
> -Original Message-
> From: Zhang, Shenglei 
> Sent: Sunday, September 15, 2019 6:09 PM
> To: devel@edk2.groups.io
> Cc: Kubacki, Michael A ; Chiu, Chasel 
> ; Desimone, Nathaniel L 
> ; Gao, Liming 
> Subject: [PATCH v2] MinPlatformPkg/TestPointCheckLib: Add return value 
> when OutTable is NULL
> 
> Currently there is no check for the parameter OutTable.
> So add the logic that return value EFI_INVALID_PARAMETER when the 
> OutTable is NULL.
> 
> Cc: Michael Kubacki 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Signed-off-by: Shenglei Zhang 
> ---
> 
> v2:Update the copyright and the if...else statement coding style.
> 
>  .../Test/Library/TestPointCheckLib/DxeCheckAcpi.c   | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeChec
> k
> Acpi.c
> b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeChec
> k
> Acpi.c
> index 263781a2..83736bf3 100644
> ---
> a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeChec
> k
> Acpi.c
> +++
> b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCh
> +++ eckAcpi.c
> @@ -1,6 +1,6 @@
>  /** @file
> 
> -Copyright (c) 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2017 - 2019, Intel Corporation. All rights 
> +reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -610,6 +610,8 @@ DumpAcpiRsdt (
> 
>if (OutTable != NULL) {
>  *OutTable = NULL;
> +  } else{
> +return EFI_INVALID_PARAMETER;
>}
> 
>ReturnStatus = EFI_SUCCESS;
> @@ -663,6 +665,8 @@ DumpAcpiXsdt (
> 
>if (OutTable != NULL) {
>  *OutTable = NULL;
> +  } else{
> +return EFI_INVALID_PARAMETER;
>}
> 
>ReturnStatus = EFI_SUCCESS;
> --
> 2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47436): https://edk2.groups.io/g/devel/message/47436
Mute This Topic: https://groups.io/mt/34159564/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Updated Event: TianoCore Bug Triage - APAC / NAMO #cal-invite

[devel@edk2.groups.io Calendar]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:calendar.14...@groups.io
DTSTAMP:20190917T214615Z
ORGANIZER;CN=Stephano Cetola:mailto:stephano.cet...@intel.com
DTSTART;TZID=America/Los_Angeles:20190404T17
DTEND;TZID=America/Los_Angeles:20190404T173000
RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=TH
SUMMARY:TianoCore Bug Triage - APAC / NAMO
DESCRIPTION:For more info please see:\n\nhttps://www.tianocore.org/bug-triage\n\nTo join the meeting on a computer or mobile phone:\n\nhttps://bluejeans.com/889357567?src=calendarLink ( https://bluejeans.com/889357567?src=calendarLink )\n\nPhone Dial-in\n\n+1.408.740.7256 (US (San Jose))\n\n+1.408.317.9253 (US (Primary, San Jose))\n\nGlobal Numbers: https://www.bluejeans.com/numbers ( https://www.bluejeans.com/numbers )\n\nMeeting ID: 889 357 567\n\nRoom System\n\n199.48.152.152 or bjn.vc\n\nMeeting ID: 889 357 567\n\nWant to test your video connection?\n\nhttps://bluejeans.com/111 ( https://bluejeans.com/111 )
LOCATION:BlueJeans Meeting
BEGIN:VALARM
ACTION:DISPLAY
CREATED:20190917T214615Z
DESCRIPTION:TianoCore Bug Triage - APAC / NAMO
TRIGGER:-PT5D
END:VALARM
BEGIN:VALARM
ACTION:DISPLAY
CREATED:20190917T214615Z
DESCRIPTION:TianoCore Bug Triage - APAC / NAMO
TRIGGER:-PT15M
END:VALARM
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

[edk2-devel] Cancelled Event: TianoCore Design / Bug Triage - EMEA - Wednesday, 18 September 2019 #cal-cancelled

[devel@edk2.groups.io Calendar]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCEL
CALSCALE:GREGORIAN
BEGIN:VEVENT
STATUS:CANCELLED
UID:calendar.15...@groups.io
DTSTAMP:20190917T214523Z
ORGANIZER;CN=Stephano Cetola:mailto:stephano.cet...@linux.intel.com
DTSTART;TZID=America/Los_Angeles:20190918T08
DTEND;TZID=America/Los_Angeles:20190918T09
SUMMARY:TianoCore Design / Bug Triage - EMEA
DESCRIPTION:Join Zoom Meeting\n\nhttps://zoom.us/j/695893389\n\nOne tap mobile\n\n+17207072699,,695893389# US\n\n+16465588656,,695893389# US (New York)\n\nDial by your location\n\n+1 720 707 2699 US\n\n+1 646 558 8656 US (New York)\n\nMeeting ID: 695 893 389\n\nFind your local number: https://zoom.us/u/abOtdJckxL
LOCATION:https://zoom.us/j/695893389
RECURRENCE-ID;TZID=America/Los_Angeles:20190918T08
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] [PATCH] MinPlatformPkg/TestPointCheckLib: Add check for pointers

[Nate DeSimone]

Hi Shenglei,

You are right, *GcdIoMap will always be NULL but GcdIoMap may not be as the 
function does not exit early in the case of GcdIoMap being == NULL, sorry I 
misread. Please make sure you put a space between your closing parenthesis and 
your opening curly:

if (GcdIoMap != NULL) {

not...

if (GcdIoMap != NULL){

Also, please fix the double semicolon and if statement whitespace:

If (BootOrder == NULL) {
  return EFI_NOT_FOUND;
}

not...

if(BootOrder == NULL) {
  return EFI_NOT_FOUND;;
}

Then you will get a reviewed-by.

Thanks,
Nate

-Original Message-
From: Zhang, Shenglei  
Sent: Monday, September 16, 2019 8:36 PM
To: devel@edk2.groups.io; Desimone, Nathaniel L 
Cc: Kubacki, Michael A ; Chiu, Chasel 
; Gao, Liming 
Subject: RE: [edk2-devel] [PATCH] MinPlatformPkg/TestPointCheckLib: Add check 
for pointers

Hi Nathaniel,

> -Original Message-
> From: Desimone, Nathaniel L
> Sent: Saturday, September 14, 2019 6:31 AM
> To: Zhang, Shenglei ; devel@edk2.groups.io
> Cc: Kubacki, Michael A ; Chiu, Chasel 
> ; Gao, Liming 
> Subject: Re: [edk2-devel] [PATCH] MinPlatformPkg/TestPointCheckLib: 
> Add check for pointers
> 
> Hi Shenglei,
> 
> Looking at this patch more closely. There appear to be bugs... please 
> see below. Please fix this along with your poor use of semi-colons and 
> white-space.
> 
> Thanks,
> 
> Nate
> 
> On 9/12/2019 11:54 AM, Nate DeSimone wrote:
> > Your whitespace doesn't quite match the edk2 coding style 
> > guidelines, but
> we can fix that during commit.
> >
> > Reviewed-by: Nate DeSimone 
> >
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Wednesday, September 11, 2019 7:55 PM
> > To: devel@edk2.groups.io
> > Cc: Kubacki, Michael A ; Chiu, Chasel
> ; Desimone, Nathaniel L 
> ; Gao, Liming 
> > Subject: [PATCH] MinPlatformPkg/TestPointCheckLib: Add check for
> pointers
> >
> > In DxeCheckBootVariable.c, add check for BootOrder and Variable that
> return EFI_NOT_FOUND when they are NULL.
> > In DxeCheckGcd.c, add check for GcdIoMap to ensure it not NULL when
> allocating memory to what it points to.
> >
> > Cc: Michael Kubacki 
> > Cc: Chasel Chiu 
> > Cc: Nate DeSimone 
> > Cc: Liming Gao 
> > Signed-off-by: Shenglei Zhang 
> > ---
> >
> > v2: Update copyright
> >
> >   .../Test/Library/TestPointCheckLib/DxeCheckBootVariable.c | 8 +++-
> >   .../Test/Library/TestPointCheckLib/DxeCheckGcd.c  | 6 --
> >   2 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git
> a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeChec
> k
> BootVariable.c
> b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeChec
> k
> BootVariable.c
> > index 85bd5b3d..98130683 100644
> > ---
> a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeChec
> k
> BootVariable.c
> > +++
> b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCh
> > +++ eckBootVariable.c
> > @@ -1,6 +1,6 @@
> >   /** @file
> >
> > -Copyright (c) 2017, Intel Corporation. All rights reserved.
> > +Copyright (c) 2017-2019, Intel Corporation. All rights 
> > +reserved.
> >   SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >   **/
> > @@ -130,6 +130,9 @@ TestPointCheckLoadOptionVariable (
> > for (ListIndex = 0; ListIndex <
> sizeof(mLoadOptionVariableList)/sizeof(mLoadOptionVariableList[0]);
> ListIndex++) {
> >   UnicodeSPrint (BootOrderName, sizeof(BootOrderName), 
> > L"%sOrder",
> mLoadOptionVariableList[ListIndex]);
> >   Status = GetVariable2 (BootOrderName, ,
> (VOID **), );
> > +if(BootOrder == NULL) {
> > +  return EFI_NOT_FOUND;;
> > +}
> >   if (EFI_ERROR(Status)) {
> > continue;
> >   }
> > @@ -222,6 +225,9 @@ TestPointCheckKeyOptionVariable (
> >   for (Index = 0; ; Index++) {
> > UnicodeSPrint (KeyOptionName, sizeof(KeyOptionName), 
> > L"%s%04x",
> mKeyOptionVariableList[ListIndex], Index);
> > Status = GetVariable2 (KeyOptionName, 
> > ,
> , );
> > +  if(Variable == NULL) {
> > +return EFI_NOT_FOUND;;
> > +  }
> > if (!EFI_ERROR(Status)) {
> >   DumpKeyOption (KeyOptionName, Variable, Size);
> > } else {
> > diff --git
> a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeChec
> k
> Gcd.c
> b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeChec
> k
> Gcd.c
> > index 82709d44..c90b37f2 100644
> > ---
> a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeChec
> k
> Gcd.c
> > +++
> b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeCh
> > +++ eckGcd.c
> > @@ -1,6 +1,6 @@
> >   /** @file
> >
> > -Copyright (c) 2017, Intel Corporation. All rights reserved.
> > +Copyright (c) 2017-2019, Intel Corporation. All rights 
> > +reserved.
> >   SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >   **/
> > @@ -241,7 +241,9 @@ TestPointDumpGcd (
> > }
> >   }
> >   if (GcdMemoryMap != NULL) {
> > -  *GcdIoMap = 

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

[Michael D Kinney]

Andrew,

Perhaps we want strict type checking as default, and platforms
Or packages that can not build with strict type checking set
the define for the relaxed type checking in their DSC files.

Mike


> -Original Message-
> From: devel@edk2.groups.io  On
> Behalf Of Andrew Fish via Groups.Io
> Sent: Tuesday, September 17, 2019 2:07 PM
> To: devel@edk2.groups.io; Ni, Ray 
> Cc: ler...@redhat.com; Achin Gupta
> ; Anthony Perard
> ; Ard Biesheuvel
> ; You, Benjamin
> ; Zhang, Chao B
> ; Bi, Dandan
> ; David Woodhouse
> ; Dong, Eric
> ; Dong, Guo ;
> Wu, Hao A ; Carsey, Jaben
> ; Wang, Jian J
> ; Wu, Jiaxin
> ; Yao, Jiewen
> ; Justen, Jordan L
> ; Julien Grall
> ; Leif Lindholm
> ; Gao, Liming
> ; Ma, Maurice
> ; Kinney, Michael D
> ; Fu, Siyuan
> ; Supreeth Venkatesh
> ; Gao, Zhichao
> 
> Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY:
> edk2: turn standard handle types into pointers to non-
> VOID
> 
> 
> 
> > On Sep 17, 2019, at 1:28 PM, Ni, Ray
>  wrote:
> >
> > Andrew,
> > I agree. Your solution is like "use strict;" in Perl
> language.
> > (https://perldoc.perl.org/strict.html)
> > Maybe "STRICT_UEFI_TYPES" without "ER". I don't see
> any strict in
> > today's code. 
> >
> 
> Ray,
> 
> I'm flexible on the name, I was just trying to give a
> good example of what I was suggesting.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks,
> > Ray
> >
> >> -Original Message-
> >> From: devel@edk2.groups.io  On
> Behalf Of Andrew
> >> Fish via Groups.Io
> >> Sent: Tuesday, September 17, 2019 1:22 PM
> >> To: Ni, Ray 
> >> Cc: devel@edk2.groups.io; ler...@redhat.com; Achin
> Gupta
> >> ; Anthony Perard
> ;
> >> Ard Biesheuvel ; You,
> Benjamin
> >> ; Zhang, Chao B
> ; Bi,
> >> Dandan ; David Woodhouse
> ;
> >> Dong, Eric ; Dong, Guo
> ; Wu,
> >> Hao A ; Carsey, Jaben
> ;
> >> Wang, Jian J ; Wu, Jiaxin
> >> ; Yao, Jiewen
> ; Justen,
> >> Jordan L ; Julien Grall
> >> ; Leif Lindholm
> ;
> >> Gao, Liming ; Ma, Maurice
> >> ; Kinney, Michael D
> >> ; Fu, Siyuan
> ;
> >> Supreeth Venkatesh ;
> Gao, Zhichao
> >> 
> >> Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT
> APPLY: edk2: turn
> >> standard handle types into pointers to non-VOID
> >>
> >>
> >>
> >>> On Sep 17, 2019, at 1:06 PM, Ni, Ray
>  wrote:
> >>>
> >>> Laszlo,
> >>> Thank you very much for this work.
> >>> They are quite helpful to detect potential issues.
> >>>
> >>> But without this specific patch being checked in,
> future break will still happen.
> >>> I don't want it to be checked in ASAP because I
> know that there are
> >>> quite a lot of close source code that may get build
> >> break due to this change.
> >>> Besides that, what prevent you make the decision to
> check in the changes?
> >>>
> >>
> >> Ray,
> >>
> >> I was thinking the same thing. Could we make this an
> optional feature
> >> via a #define? We could always default to the Spec
> Behavior, and new projects could opt into the stricter
> version.
> >>
> >> #ifndef STRICTER_UEFI_TYPES
> >> typedef VOID*EFI_PEI_FV_HANDLE;
> >> #else
> >> struct EFI_PEI_FV_OBJECT;
> >> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
> #endif
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >>> Thanks,
> >>> Ray
> >>>
> >>>
>  -Original Message-
>  From: devel@edk2.groups.io 
> On Behalf Of
>  Laszlo Ersek
>  Sent: Tuesday, September 17, 2019 12:49 PM
>  To: edk2-devel-groups-io 
>  Cc: Achin Gupta ; Andrew Fish
>  ; Anthony Perard
> >> ;
>  Ard Biesheuvel ; You,
> Benjamin
>  ; Zhang, Chao B
> ;
>  Bi, Dandan ; David Woodhouse
>  ; Dong,
> >> Eric
>  ; Dong, Guo
> ; Wu, Hao A
>  ; Carsey, Jaben
> ; Wang,
>  Jian J ; Wu, Jiaxin
> ;
>  Yao, Jiewen ; Justen, Jordan
> L
>  ; Julien Grall
> ;
>  Leif
> >> Lindholm
>  ; Gao, Liming
> ; Ma,
>  Maurice ; Kinney,
> >> Michael
>  D ; Ni, Ray
> ; Fu,
>  Siyuan ; Supreeth Venkatesh
>  ; Gao, Zhichao
> 
>  Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY:
> edk2: turn
>  standard handle types into pointers to non-VOID
> 
>  Unfortunately, the UEFI / PI / Shell specs define
> a number of
>  handle types as pointers to VOID. This is a design
> mistake; those
>  types should have been pointers to incomplete
> union or structure
>  types. Any pointer-to-object type converts
> implicitly to, and from,
>  pointer-to-void, which prevents compilers from
> catching at least
>  the following two types of
>  mistakes:
> 
>  - mixing up one handle type with another (for
> example, EFI_HANDLE
>  with EFI_EVENT),
> 
>  - getting the depth of indirection wrong (for
> example, mixing up
>  (EFI_HANDLE*) with EFI_HANDLE).
> 
>  In order to root out such mistakes in the edk2
> codebase, introduce
>  incomplete structure types with unique tags, such
> as:
> 
>  struct EFI_FOOBAR_OBJECT;
>  typedef struct EFI_FOOBAR_OBJECT
> *EFI_FOOBAR_HANDLE;
> 
>  replacing the spec mandated
> 

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

[Andrew Fish via Groups.Io]

> On Sep 17, 2019, at 1:28 PM, Ni, Ray  wrote:
> 
> Andrew,
> I agree. Your solution is like "use strict;" in Perl language. 
> (https://perldoc.perl.org/strict.html)
> Maybe "STRICT_UEFI_TYPES" without "ER". I don't see any strict in today's 
> code. 
> 

Ray,

I'm flexible on the name, I was just trying to give a good example of what I 
was suggesting. 

Thanks,

Andrew Fish

> Thanks,
> Ray
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Andrew Fish 
>> via Groups.Io
>> Sent: Tuesday, September 17, 2019 1:22 PM
>> To: Ni, Ray 
>> Cc: devel@edk2.groups.io; ler...@redhat.com; Achin Gupta 
>> ; Anthony Perard
>> ; Ard Biesheuvel ; 
>> You, Benjamin ;
>> Zhang, Chao B ; Bi, Dandan ; 
>> David Woodhouse
>> ; Dong, Eric ; Dong, Guo 
>> ; Wu, Hao A
>> ; Carsey, Jaben ; Wang, Jian J 
>> ; Wu, Jiaxin
>> ; Yao, Jiewen ; Justen, Jordan L 
>> ; Julien Grall
>> ; Leif Lindholm ; Gao, 
>> Liming ; Ma, Maurice
>> ; Kinney, Michael D ; Fu, 
>> Siyuan ; Supreeth
>> Venkatesh ; Gao, Zhichao 
>> Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard 
>> handle types into pointers to non-VOID
>> 
>> 
>> 
>>> On Sep 17, 2019, at 1:06 PM, Ni, Ray  wrote:
>>> 
>>> Laszlo,
>>> Thank you very much for this work.
>>> They are quite helpful to detect potential issues.
>>> 
>>> But without this specific patch being checked in, future break will still 
>>> happen.
>>> I don't want it to be checked in ASAP because I know that there are quite a 
>>> lot of close source code that may get build
>> break due to this change.
>>> Besides that, what prevent you make the decision to check in the changes?
>>> 
>> 
>> Ray,
>> 
>> I was thinking the same thing. Could we make this an optional feature via a 
>> #define? We could always default to the Spec
>> Behavior, and new projects could opt into the stricter version.
>> 
>> #ifndef STRICTER_UEFI_TYPES
>> typedef VOID*EFI_PEI_FV_HANDLE;
>> #else
>> struct EFI_PEI_FV_OBJECT;
>> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
>> #endif
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> Thanks,
>>> Ray
>>> 
>>> 
 -Original Message-
 From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
 Sent: Tuesday, September 17, 2019 12:49 PM
 To: edk2-devel-groups-io 
 Cc: Achin Gupta ; Andrew Fish ; 
 Anthony Perard
>> ;
 Ard Biesheuvel ; You, Benjamin 
 ; Zhang, Chao B
 ; Bi, Dandan ; David 
 Woodhouse ; Dong,
>> Eric
 ; Dong, Guo ; Wu, Hao A 
 ; Carsey, Jaben
 ; Wang, Jian J ; Wu, Jiaxin 
 ; Yao, Jiewen
 ; Justen, Jordan L ; 
 Julien Grall ; Leif
>> Lindholm
 ; Gao, Liming ; Ma, 
 Maurice ; Kinney,
>> Michael
 D ; Ni, Ray ; Fu, Siyuan 
 ; Supreeth Venkatesh
 ; Gao, Zhichao 
 Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard 
 handle types into pointers to non-VOID
 
 Unfortunately, the UEFI / PI / Shell specs define a number of handle types
 as pointers to VOID. This is a design mistake; those types should have
 been pointers to incomplete union or structure types. Any
 pointer-to-object type converts implicitly to, and from, pointer-to-void,
 which prevents compilers from catching at least the following two types of
 mistakes:
 
 - mixing up one handle type with another (for example, EFI_HANDLE with
 EFI_EVENT),
 
 - getting the depth of indirection wrong (for example, mixing up
 (EFI_HANDLE*) with EFI_HANDLE).
 
 In order to root out such mistakes in the edk2 codebase, introduce
 incomplete structure types with unique tags, such as:
 
 struct EFI_FOOBAR_OBJECT;
 typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;
 
 replacing the spec mandated
 
 typedef VOID *EFI_FOOBAR_HANDLE;
 
 (For some types, such as:
 
 - EFI_ACPI_HANDLE,
 - EFI_EVENT,
 - EFI_FONT_HANDLE,
 - EFI_HANDLE,
 - EFI_HII_HANDLE,
 - EFI_S3_BOOT_SCRIPT_POSITION,
 - SHELL_FILE_HANDLE,
 
 we connect the actual complete type (the internal, implementation-specific
 type) to the typedef. Some of these also demonstrate how the code could
 have looked in practice if the specs had used proper opaque (=incomplete)
 types.)
 
 Then, unleash "build" on the package DSC files. This causes the compiler
 to warn about incompatible pointer assignments, and to stop the build.
 
 The rest of the series addresses the resultant warnings. Each patch
 belongs in one of two categories:
 
 - semantic cleanups (no functional / behavioral changes),
 - actual bugfixes.
 
 As the subject line of this patch states, this specific patch is *not*
 meant to be applied. It is just a "what if" patch that temporarily
 isolates the standard types from each other, the way the specs should
 have, so that the compiler have more information to work with.
 
 Cc: Achin Gupta 
 Cc: Andrew Fish 

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

[Ni, Ray]

Andrew,
I agree. Your solution is like "use strict;" in Perl language. 
(https://perldoc.perl.org/strict.html)
Maybe "STRICT_UEFI_TYPES" without "ER". I don't see any strict in today's code. 


Thanks,
Ray

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Andrew Fish 
> via Groups.Io
> Sent: Tuesday, September 17, 2019 1:22 PM
> To: Ni, Ray 
> Cc: devel@edk2.groups.io; ler...@redhat.com; Achin Gupta 
> ; Anthony Perard
> ; Ard Biesheuvel ; You, 
> Benjamin ;
> Zhang, Chao B ; Bi, Dandan ; 
> David Woodhouse
> ; Dong, Eric ; Dong, Guo 
> ; Wu, Hao A
> ; Carsey, Jaben ; Wang, Jian J 
> ; Wu, Jiaxin
> ; Yao, Jiewen ; Justen, Jordan L 
> ; Julien Grall
> ; Leif Lindholm ; Gao, Liming 
> ; Ma, Maurice
> ; Kinney, Michael D ; Fu, 
> Siyuan ; Supreeth
> Venkatesh ; Gao, Zhichao 
> Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard 
> handle types into pointers to non-VOID
> 
> 
> 
> > On Sep 17, 2019, at 1:06 PM, Ni, Ray  wrote:
> >
> > Laszlo,
> > Thank you very much for this work.
> > They are quite helpful to detect potential issues.
> >
> > But without this specific patch being checked in, future break will still 
> > happen.
> > I don't want it to be checked in ASAP because I know that there are quite a 
> > lot of close source code that may get build
> break due to this change.
> > Besides that, what prevent you make the decision to check in the changes?
> >
> 
> Ray,
> 
> I was thinking the same thing. Could we make this an optional feature via a 
> #define? We could always default to the Spec
> Behavior, and new projects could opt into the stricter version.
> 
> #ifndef STRICTER_UEFI_TYPES
> typedef VOID*EFI_PEI_FV_HANDLE;
> #else
> struct EFI_PEI_FV_OBJECT;
> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
> #endif
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks,
> > Ray
> >
> >
> >> -Original Message-
> >> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> >> Sent: Tuesday, September 17, 2019 12:49 PM
> >> To: edk2-devel-groups-io 
> >> Cc: Achin Gupta ; Andrew Fish ; 
> >> Anthony Perard
> ;
> >> Ard Biesheuvel ; You, Benjamin 
> >> ; Zhang, Chao B
> >> ; Bi, Dandan ; David 
> >> Woodhouse ; Dong,
> Eric
> >> ; Dong, Guo ; Wu, Hao A 
> >> ; Carsey, Jaben
> >> ; Wang, Jian J ; Wu, Jiaxin 
> >> ; Yao, Jiewen
> >> ; Justen, Jordan L ; 
> >> Julien Grall ; Leif
> Lindholm
> >> ; Gao, Liming ; Ma, 
> >> Maurice ; Kinney,
> Michael
> >> D ; Ni, Ray ; Fu, Siyuan 
> >> ; Supreeth Venkatesh
> >> ; Gao, Zhichao 
> >> Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard 
> >> handle types into pointers to non-VOID
> >>
> >> Unfortunately, the UEFI / PI / Shell specs define a number of handle types
> >> as pointers to VOID. This is a design mistake; those types should have
> >> been pointers to incomplete union or structure types. Any
> >> pointer-to-object type converts implicitly to, and from, pointer-to-void,
> >> which prevents compilers from catching at least the following two types of
> >> mistakes:
> >>
> >> - mixing up one handle type with another (for example, EFI_HANDLE with
> >>  EFI_EVENT),
> >>
> >> - getting the depth of indirection wrong (for example, mixing up
> >>  (EFI_HANDLE*) with EFI_HANDLE).
> >>
> >> In order to root out such mistakes in the edk2 codebase, introduce
> >> incomplete structure types with unique tags, such as:
> >>
> >>  struct EFI_FOOBAR_OBJECT;
> >>  typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;
> >>
> >> replacing the spec mandated
> >>
> >>  typedef VOID *EFI_FOOBAR_HANDLE;
> >>
> >> (For some types, such as:
> >>
> >> - EFI_ACPI_HANDLE,
> >> - EFI_EVENT,
> >> - EFI_FONT_HANDLE,
> >> - EFI_HANDLE,
> >> - EFI_HII_HANDLE,
> >> - EFI_S3_BOOT_SCRIPT_POSITION,
> >> - SHELL_FILE_HANDLE,
> >>
> >> we connect the actual complete type (the internal, implementation-specific
> >> type) to the typedef. Some of these also demonstrate how the code could
> >> have looked in practice if the specs had used proper opaque (=incomplete)
> >> types.)
> >>
> >> Then, unleash "build" on the package DSC files. This causes the compiler
> >> to warn about incompatible pointer assignments, and to stop the build.
> >>
> >> The rest of the series addresses the resultant warnings. Each patch
> >> belongs in one of two categories:
> >>
> >> - semantic cleanups (no functional / behavioral changes),
> >> - actual bugfixes.
> >>
> >> As the subject line of this patch states, this specific patch is *not*
> >> meant to be applied. It is just a "what if" patch that temporarily
> >> isolates the standard types from each other, the way the specs should
> >> have, so that the compiler have more information to work with.
> >>
> >> Cc: Achin Gupta 
> >> Cc: Andrew Fish 
> >> Cc: Anthony Perard 
> >> Cc: Ard Biesheuvel 
> >> Cc: Benjamin You 
> >> Cc: Chao Zhang 
> >> Cc: Dandan Bi 
> >> Cc: David Woodhouse 
> >> Cc: Eric Dong 
> >> Cc: Guo Dong 
> >> Cc: Hao A Wu 
> >> Cc: Jaben Carsey 
> >> Cc: Jian J Wang 
> >> Cc: Jian Wang 

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

[Andrew Fish via Groups.Io]

> On Sep 17, 2019, at 1:06 PM, Ni, Ray  wrote:
> 
> Laszlo,
> Thank you very much for this work.
> They are quite helpful to detect potential issues.
> 
> But without this specific patch being checked in, future break will still 
> happen.
> I don't want it to be checked in ASAP because I know that there are quite a 
> lot of close source code that may get build break due to this change.
> Besides that, what prevent you make the decision to check in the changes?
> 

Ray,

I was thinking the same thing. Could we make this an optional feature via a 
#define? We could always default to the Spec Behavior, and new projects could 
opt into the stricter version. 

#ifndef STRICTER_UEFI_TYPES
typedef VOID*EFI_PEI_FV_HANDLE;
#else
struct EFI_PEI_FV_OBJECT;
typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
#endif

Thanks,

Andrew Fish

> Thanks,
> Ray
> 
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
>> Sent: Tuesday, September 17, 2019 12:49 PM
>> To: edk2-devel-groups-io 
>> Cc: Achin Gupta ; Andrew Fish ; 
>> Anthony Perard ;
>> Ard Biesheuvel ; You, Benjamin 
>> ; Zhang, Chao B
>> ; Bi, Dandan ; David Woodhouse 
>> ; Dong, Eric
>> ; Dong, Guo ; Wu, Hao A 
>> ; Carsey, Jaben
>> ; Wang, Jian J ; Wu, Jiaxin 
>> ; Yao, Jiewen
>> ; Justen, Jordan L ; Julien 
>> Grall ; Leif Lindholm
>> ; Gao, Liming ; Ma, Maurice 
>> ; Kinney, Michael
>> D ; Ni, Ray ; Fu, Siyuan 
>> ; Supreeth Venkatesh
>> ; Gao, Zhichao 
>> Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle 
>> types into pointers to non-VOID
>> 
>> Unfortunately, the UEFI / PI / Shell specs define a number of handle types
>> as pointers to VOID. This is a design mistake; those types should have
>> been pointers to incomplete union or structure types. Any
>> pointer-to-object type converts implicitly to, and from, pointer-to-void,
>> which prevents compilers from catching at least the following two types of
>> mistakes:
>> 
>> - mixing up one handle type with another (for example, EFI_HANDLE with
>>  EFI_EVENT),
>> 
>> - getting the depth of indirection wrong (for example, mixing up
>>  (EFI_HANDLE*) with EFI_HANDLE).
>> 
>> In order to root out such mistakes in the edk2 codebase, introduce
>> incomplete structure types with unique tags, such as:
>> 
>>  struct EFI_FOOBAR_OBJECT;
>>  typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;
>> 
>> replacing the spec mandated
>> 
>>  typedef VOID *EFI_FOOBAR_HANDLE;
>> 
>> (For some types, such as:
>> 
>> - EFI_ACPI_HANDLE,
>> - EFI_EVENT,
>> - EFI_FONT_HANDLE,
>> - EFI_HANDLE,
>> - EFI_HII_HANDLE,
>> - EFI_S3_BOOT_SCRIPT_POSITION,
>> - SHELL_FILE_HANDLE,
>> 
>> we connect the actual complete type (the internal, implementation-specific
>> type) to the typedef. Some of these also demonstrate how the code could
>> have looked in practice if the specs had used proper opaque (=incomplete)
>> types.)
>> 
>> Then, unleash "build" on the package DSC files. This causes the compiler
>> to warn about incompatible pointer assignments, and to stop the build.
>> 
>> The rest of the series addresses the resultant warnings. Each patch
>> belongs in one of two categories:
>> 
>> - semantic cleanups (no functional / behavioral changes),
>> - actual bugfixes.
>> 
>> As the subject line of this patch states, this specific patch is *not*
>> meant to be applied. It is just a "what if" patch that temporarily
>> isolates the standard types from each other, the way the specs should
>> have, so that the compiler have more information to work with.
>> 
>> Cc: Achin Gupta 
>> Cc: Andrew Fish 
>> Cc: Anthony Perard 
>> Cc: Ard Biesheuvel 
>> Cc: Benjamin You 
>> Cc: Chao Zhang 
>> Cc: Dandan Bi 
>> Cc: David Woodhouse 
>> Cc: Eric Dong 
>> Cc: Guo Dong 
>> Cc: Hao A Wu 
>> Cc: Jaben Carsey 
>> Cc: Jian J Wang 
>> Cc: Jian Wang 
>> Cc: Jiaxin Wu 
>> Cc: Jiewen Yao 
>> Cc: Jordan Justen 
>> Cc: Julien Grall 
>> Cc: Leif Lindholm 
>> Cc: Liming Gao 
>> Cc: Maurice Ma 
>> Cc: Michael D Kinney 
>> Cc: Ray Ni 
>> Cc: Siyuan Fu 
>> Cc: Supreeth Venkatesh 
>> Cc: Zhichao Gao 
>> Signed-off-by: Laszlo Ersek 
>> ---
>> MdePkg/Include/Pi/PiPeiCis.h | 6 --
>> MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 ++-
>> MdePkg/Include/Protocol/Bis.h| 3 ++-
>> MdePkg/Include/Protocol/Eap.h| 3 ++-
>> MdePkg/Include/Protocol/HiiFont.h| 3 +--
>> MdePkg/Include/Protocol/MmMp.h   | 3 ++-
>> MdePkg/Include/Protocol/S3SaveState.h| 2 +-
>> MdePkg/Include/Protocol/Shell.h  | 3 ++-
>> MdePkg/Include/Protocol/UserManager.h| 9 ++---
>> MdePkg/Include/Uefi/UefiBaseType.h   | 6 --
>> MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 ++-
>> MdeModulePkg/Core/Dxe/Event/Event.h  | 2 +-
>> MdeModulePkg/Core/Dxe/Hand/Handle.h  | 2 +-
>> 

Re: [edk2-devel] [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io 
> Cc: Wu, Hao A ; Wang, Jian J ; 
> Gao, Liming ; Ni, Ray
> ; Gao, Zhichao 
> Subject: [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol 
> notify registration
> 
> EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
> similarly to gBS->RegisterProtocolNotify(). We should pass the address of
> an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
> just happens to be specified as (VOID*), and has nothing to do with the
> registration.
> 
> The same applies to gMmst->MmRegisterProtocolNotify().
> 
> "mFtwRegistration", "mFvRegistration", and "mFvbRegistration" are used for
> nothing else.
> 
> This change is a no-op in practice; it's a semantic improvement.
> 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> lightly tested, as these modules (except LoadFileOnFv2) are part of the
> ArmVirt and/or OVMF platforms
> 
>  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c | 2 +-
>  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c | 2 +-
>  MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 2 +-
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git 
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> index ae8f117905cd..de38ea028af1 100644
> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
> @@ -47,7 +47,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #include 
>  #include "FaultTolerantWrite.h"
> -EFI_EVENT mFvbRegistration = NULL;
> +VOID  *mFvbRegistration = NULL;
> 
> 
>  /**
> diff --git 
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> index e8e935a85b5b..9612b394865b 100644
> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> @@ -56,7 +56,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include "FaultTolerantWriteSmmCommon.h"
>  #include 
> 
> -EFI_EVENT mFvbRegistration = NULL;
> +VOID  *mFvbRegistration = NULL;
>  EFI_FTW_DEVICE*mFtwDevice  = NULL;
> 
>  ///
> diff --git a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> index 4af2da05e145..43fa6ce12875 100644
> --- a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> +++ b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
> @@ -36,7 +36,7 @@ typedef struct {
>  #define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_THIS(a) CR (a, 
> LOAD_FILE_ON_FV2_PRIVATE_DATA, LoadFile,
> LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
>  #define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_LINK(a) CR (a, 
> LOAD_FILE_ON_FV2_PRIVATE_DATA, Link,
> LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
> 
> -EFI_EVENT  mFvRegistration;
> +VOID   *mFvRegistration;
>  LIST_ENTRY mPrivateDataList;
> 
>  /**
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> index 3d232bb36cb4..7d2b6c8e1fad 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> @@ -13,7 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  EFI_HANDLE  mHandle= NULL;
>  EFI_EVENT   mVirtualAddressChangeEvent = NULL;
> -EFI_EVENT   mFtwRegistration   = NULL;
> +VOID*mFtwRegistration  = NULL;
>  VOID***mVarCheckAddressPointer = NULL;
>  UINTN   mVarCheckAddressPointerCount = 0;
>  EDKII_VARIABLE_LOCK_PROTOCOLmVariableLock  = { 
> VariableLockRequestToLock };
> --
> 2.19.1.3.g30247aa5d201
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47428): https://edk2.groups.io/g/devel/message/47428
Mute This Topic: https://groups.io/mt/34180210/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io 
> Cc: Bi, Dandan ; Dong, Eric ; Wu, 
> Hao A ; Wang, Jian J
> ; Ni, Ray ; Gao, Zhichao 
> 
> Subject: [edk2-devel] [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for 
> keystroke notify registration
> 
> EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
> the notification handle to have type (VOID*). The notification handle has
> nothing to do with the EFI_HANDLE type.
> 
> This change is a semantic fix; functionally, it's a no-op.
> 
> Cc: Dandan Bi 
> Cc: Eric Dong 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> lightly tested: ConSplitterDxe is part of the ArmVirt and OVMF platforms
> 
>  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c | 2 +-
>  MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c   | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> index 63c814ae1816..9c38271b65f9 100644
> --- a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> +++ b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
> @@ -4026,7 +4026,7 @@ ConSplitterTextInRegisterKeyNotify (
>if (NewNotify == NULL) {
>  return EFI_OUT_OF_RESOURCES;
>}
> -  NewNotify->NotifyHandleList = (EFI_HANDLE *) AllocateZeroPool (sizeof 
> (EFI_HANDLE) *  Private->TextInExListCount);
> +  NewNotify->NotifyHandleList = (VOID **) AllocateZeroPool (sizeof (VOID *) 
> *  Private->TextInExListCount);
>if (NewNotify->NotifyHandleList == NULL) {
>  gBS->FreePool (NewNotify);
>  return EFI_OUT_OF_RESOURCES;
> diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> index 7cfd5c178861..f98797225b63 100644
> --- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> +++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> @@ -143,7 +143,7 @@ InternalStartMonitor(
>EFI_HANDLE*Handles;
>UINTN HandleCount;
>UINTN HandleIndex;
> -  EFI_HANDLENotifyHandle;
> +  VOID  *NotifyHandle;
> 
>Status = gBS->LocateHandleBuffer (
>ByProtocol,
> @@ -202,7 +202,7 @@ InternalStopMonitor(
>EFI_KEY_DATA  KeyData;
>UINTN HandleCount;
>UINTN HandleIndex;
> -  EFI_HANDLENotifyHandle;
> +  VOID  *NotifyHandle;
> 
>Status = gBS->LocateHandleBuffer (
>  ByProtocol,
> --
> 2.19.1.3.g30247aa5d201
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> 
> View/Reply Online (#47399): https://edk2.groups.io/g/devel/message/47399
> Mute This Topic: https://groups.io/mt/34180213/1712937
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub  [ray...@intel.com]
> -=-=-=-=-=-=


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47427): https://edk2.groups.io/g/devel/message/47427
Mute This Topic: https://groups.io/mt/34180213/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io 
> Cc: Wu, Hao A ; Wang, Jian J ; Ni, 
> Ray 
> Subject: [PATCH 14/35] MdeModulePkg: fix 
> UninstallMultipleProtocolInterfaces() calls
> 
> Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
> an (EFI_HANDLE*) as first parameter, the
> UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
> first parameter.
> 
> These are actual bugs. They must have remained hidden until now because
> they are on error paths. Fix the UninstallMultipleProtocolInterfaces()
> calls.
> 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Cc: Ray Ni 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> build-tested only
> 
>  MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c | 2 +-
>  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c  | 2 +-
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c| 6 +++---
>  MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c| 2 +-
>  MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c| 2 +-
>  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c   | 2 +-
>  MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c | 2 +-
>  7 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c 
> b/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
> index 2b54ec51dca0..ed33a51da252 100644
> --- a/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
> +++ b/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
> @@ -720,7 +720,7 @@ Error:
> 
>  if (I2cBusContext != NULL) {
>Status = gBS->UninstallMultipleProtocolInterfaces (
> -  ,
> +  Controller,
>gEfiCallerIdGuid,
>I2cBusContext,
>NULL
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> index c6e401176a4b..3bde96bc9576 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> @@ -244,7 +244,7 @@ EnumerateNvmeDevNamespace (
>);
>if(EFI_ERROR(Status)) {
>  gBS->UninstallMultipleProtocolInterfaces (
> -   >DeviceHandle,
> +   Device->DeviceHandle,
> ,
> Device->DevicePath,
> ,
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> index b7832c6970ad..292dd25da817 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> @@ -313,7 +313,7 @@ RegisterPciDevice (
>  );
>  if (EFI_ERROR (Status)) {
>gBS->UninstallMultipleProtocolInterfaces (
> - >Handle,
> + PciIoDevice->Handle,
>   ,
>   PciIoDevice->DevicePath,
>   ,
> @@ -351,7 +351,7 @@ RegisterPciDevice (
>  );
>  if (EFI_ERROR (Status)) {
>gBS->UninstallMultipleProtocolInterfaces (
> - >Handle,
> + PciIoDevice->Handle,
>   ,
>   PciIoDevice->DevicePath,
>   ,
> @@ -360,7 +360,7 @@ RegisterPciDevice (
>   );
>if (HasEfiImage) {
>  gBS->UninstallMultipleProtocolInterfaces (
> -   >Handle,
> +   PciIoDevice->Handle,
> ,
> >LoadFile2,
> NULL
> diff --git a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c 
> b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
> index 82db93a8b117..9fe8a482e067 100644
> --- a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
> +++ b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
> @@ -665,7 +665,7 @@ CreateSerialDevice (
> 
>if (EFI_ERROR (Status)) {
>  gBS->UninstallMultipleProtocolInterfaces (
> -   >Handle,
> +   SerialDevice->Handle,
> , SerialDevice->DevicePath,
> , >SerialIo,
> NULL
> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c 
> b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
> index 62f18d1878bd..e2ae56c5058a 100644
> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
> +++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
> @@ -475,7 +475,7 @@ InstallProtocolOnPartition (
>  );
>  if (EFI_ERROR (Status)) {
>gBS->UninstallMultipleProtocolInterfaces (
> - >Handle,
> + Partition->Handle,
>   ,
>   Partition->DevicePath,
>   ,
> diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c 
> b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> index eaa0d70024bb..cc0de52de411 100644
> --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> @@ -159,7 +159,7 @@ UsbCreateInterface (
> 
>if (EFI_ERROR (Status)) {
>  

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

[Ni, Ray]

Laszlo,
Thank you very much for this work.
They are quite helpful to detect potential issues.

But without this specific patch being checked in, future break will still 
happen.
I don't want it to be checked in ASAP because I know that there are quite a lot 
of close source code that may get build break due to this change.
Besides that, what prevent you make the decision to check in the changes?

Thanks,
Ray


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io 
> Cc: Achin Gupta ; Andrew Fish ; Anthony 
> Perard ;
> Ard Biesheuvel ; You, Benjamin 
> ; Zhang, Chao B
> ; Bi, Dandan ; David Woodhouse 
> ; Dong, Eric
> ; Dong, Guo ; Wu, Hao A 
> ; Carsey, Jaben
> ; Wang, Jian J ; Wu, Jiaxin 
> ; Yao, Jiewen
> ; Justen, Jordan L ; Julien 
> Grall ; Leif Lindholm
> ; Gao, Liming ; Ma, Maurice 
> ; Kinney, Michael
> D ; Ni, Ray ; Fu, Siyuan 
> ; Supreeth Venkatesh
> ; Gao, Zhichao 
> Subject: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle 
> types into pointers to non-VOID
> 
> Unfortunately, the UEFI / PI / Shell specs define a number of handle types
> as pointers to VOID. This is a design mistake; those types should have
> been pointers to incomplete union or structure types. Any
> pointer-to-object type converts implicitly to, and from, pointer-to-void,
> which prevents compilers from catching at least the following two types of
> mistakes:
> 
> - mixing up one handle type with another (for example, EFI_HANDLE with
>   EFI_EVENT),
> 
> - getting the depth of indirection wrong (for example, mixing up
>   (EFI_HANDLE*) with EFI_HANDLE).
> 
> In order to root out such mistakes in the edk2 codebase, introduce
> incomplete structure types with unique tags, such as:
> 
>   struct EFI_FOOBAR_OBJECT;
>   typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;
> 
> replacing the spec mandated
> 
>   typedef VOID *EFI_FOOBAR_HANDLE;
> 
> (For some types, such as:
> 
> - EFI_ACPI_HANDLE,
> - EFI_EVENT,
> - EFI_FONT_HANDLE,
> - EFI_HANDLE,
> - EFI_HII_HANDLE,
> - EFI_S3_BOOT_SCRIPT_POSITION,
> - SHELL_FILE_HANDLE,
> 
> we connect the actual complete type (the internal, implementation-specific
> type) to the typedef. Some of these also demonstrate how the code could
> have looked in practice if the specs had used proper opaque (=incomplete)
> types.)
> 
> Then, unleash "build" on the package DSC files. This causes the compiler
> to warn about incompatible pointer assignments, and to stop the build.
> 
> The rest of the series addresses the resultant warnings. Each patch
> belongs in one of two categories:
> 
> - semantic cleanups (no functional / behavioral changes),
> - actual bugfixes.
> 
> As the subject line of this patch states, this specific patch is *not*
> meant to be applied. It is just a "what if" patch that temporarily
> isolates the standard types from each other, the way the specs should
> have, so that the compiler have more information to work with.
> 
> Cc: Achin Gupta 
> Cc: Andrew Fish 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Benjamin You 
> Cc: Chao Zhang 
> Cc: Dandan Bi 
> Cc: David Woodhouse 
> Cc: Eric Dong 
> Cc: Guo Dong 
> Cc: Hao A Wu 
> Cc: Jaben Carsey 
> Cc: Jian J Wang 
> Cc: Jian Wang 
> Cc: Jiaxin Wu 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Leif Lindholm 
> Cc: Liming Gao 
> Cc: Maurice Ma 
> Cc: Michael D Kinney 
> Cc: Ray Ni 
> Cc: Siyuan Fu 
> Cc: Supreeth Venkatesh 
> Cc: Zhichao Gao 
> Signed-off-by: Laszlo Ersek 
> ---
>  MdePkg/Include/Pi/PiPeiCis.h | 6 --
>  MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 ++-
>  MdePkg/Include/Protocol/Bis.h| 3 ++-
>  MdePkg/Include/Protocol/Eap.h| 3 ++-
>  MdePkg/Include/Protocol/HiiFont.h| 3 +--
>  MdePkg/Include/Protocol/MmMp.h   | 3 ++-
>  MdePkg/Include/Protocol/S3SaveState.h| 2 +-
>  MdePkg/Include/Protocol/Shell.h  | 3 ++-
>  MdePkg/Include/Protocol/UserManager.h| 9 ++---
>  MdePkg/Include/Uefi/UefiBaseType.h   | 6 --
>  MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 ++-
>  MdeModulePkg/Core/Dxe/Event/Event.h  | 2 +-
>  MdeModulePkg/Core/Dxe/Hand/Handle.h  | 2 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h  | 2 +-
>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h   | 2 +-
>  MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h  | 2 +-
>  StandaloneMmPkg/Core/StandaloneMmCore.h  | 2 +-
>  17 files changed, 34 insertions(+), 22 deletions(-)
> 
> diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
> index d9d4ed7d413a..3e9e82b62ae9 100644
> --- a/MdePkg/Include/Pi/PiPeiCis.h
> +++ b/MdePkg/Include/Pi/PiPeiCis.h
> @@ -18,12 +18,14 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  ///
>  /// The handles 

Re: [edk2-devel] [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io 
> Cc: Andrew Fish ; Justen, Jordan L 
> ; Ni, Ray 
> Subject: [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast
> 
> "gTimerEvent" has type EFI_EVENT already, drop the superfluous cast.
> 
> Cc: Andrew Fish 
> Cc: Jordan Justen 
> Cc: Ray Ni 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> build-tested only
> 
>  EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c 
> b/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
> index 14cae4214c66..6fb5d8f3aaea 100644
> --- a/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
> +++ b/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
> @@ -40,7 +40,7 @@ RegisterTimerArchProtocol (
>  gTimerPeriod = MultU64x32 (gTimerPeriod, 100);
> 
>  if (gTimerEvent == NULL) {
> -  Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, (VOID 
> **));
> +  Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, );
>ASSERT_EFI_ERROR (Status);
>  }
>}
> --
> 2.19.1.3.g30247aa5d201
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47424): https://edk2.groups.io/g/devel/message/47424
Mute This Topic: https://groups.io/mt/34180204/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, September 17, 2019 12:49 PM
> To: edk2-devel-groups-io 
> Cc: Andrew Fish ; Justen, Jordan L 
> ; Ni, Ray 
> Subject: [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke 
> notify registration
> 
> EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
> the notification handle to have type (VOID*). The notification handle has
> nothing to do with the EFI_HANDLE type.
> 
> This change is a semantic fix; functionally, it's a no-op.
> 
> Cc: Andrew Fish 
> Cc: Jordan Justen 
> Cc: Ray Ni 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> build-tested only
> 
>  EmulatorPkg/EmuGopDxe/GopInput.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/EmulatorPkg/EmuGopDxe/GopInput.c 
> b/EmulatorPkg/EmuGopDxe/GopInput.c
> index fdd0b4911555..2a23564a2173 100644
> --- a/EmulatorPkg/EmuGopDxe/GopInput.c
> +++ b/EmulatorPkg/EmuGopDxe/GopInput.c
> @@ -517,7 +517,7 @@ EmuGopSimpleTextInExRegisterKeyNotify (
>IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL  *This,
>IN EFI_KEY_DATA   *KeyData,
>IN EFI_KEY_NOTIFY_FUNCTIONKeyNotificationFunction,
> -  OUT EFI_HANDLE*NotifyHandle
> +  OUT VOID  **NotifyHandle
>)
>  {
>EFI_STATUS  Status;
> @@ -600,7 +600,7 @@ EFI_STATUS
>  EFIAPI
>  EmuGopSimpleTextInExUnregisterKeyNotify (
>IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL  *This,
> -  IN EFI_HANDLE NotificationHandle
> +  IN VOID   *NotificationHandle
>)
>  /*++
> 
> --
> 2.19.1.3.g30247aa5d201
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47423): https://edk2.groups.io/g/devel/message/47423
Mute This Topic: https://groups.io/mt/34180205/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT

[Laszlo Ersek]

(This patch is unrelated to the rest of this series; its purpose is to
enable building the UefiPayloadPkg DSC files with GCC.)

When building "UefiPayloadPkg/UefiPayloadPkgIa32.dsc" with GCC48 for the
DEBUG target, the compiler reports that "Entry32" may be used
uninitialized in ParseAcpiInfo(), in the XSDT branch.

Code inspection proves the compiler right. In the XSDT branch, the code
from the RSDT branch must have been duplicated, and "Entry32" references
were replaced with "Entry64" -- except where "MmCfgHdr" is assigned.

Fix this bug by introducing a helper variable called "Signature", so that
we have to refer to "Entry32" or "Entry64" only once per loop body.

Cc: Benjamin You 
Cc: Guo Dong 
Cc: Maurice Ma 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 UefiPayloadPkg/BlSupportPei/BlSupportPei.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c 
b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
index 90433b609f22..22972453117a 100644
--- a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
+++ b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
@@ -164,6 +164,7 @@ ParseAcpiInfo (
   UINT64*Entry64;
   UINTN Entry64Num;
   UINTN Idx;
+  UINT32*Signature;
   EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *MmCfgHdr;
   
EFI_ACPI_MEMORY_MAPPED_ENHANCED_CONFIGURATION_SPACE_BASE_ADDRESS_ALLOCATION_STRUCTURE
 *MmCfgBase;
 
@@ -181,13 +182,14 @@ ParseAcpiInfo (
 Entry32  = (UINT32 *)(Rsdt + 1);
 Entry32Num = (Rsdt->Length - sizeof(EFI_ACPI_DESCRIPTION_HEADER)) >> 2;
 for (Idx = 0; Idx < Entry32Num; Idx++) {
-  if (*(UINT32 *)(UINTN)(Entry32[Idx]) == 
EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
-Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE 
*)(UINTN)(Entry32[Idx]);
+  Signature = (UINT32 *)(UINTN)Entry32[Idx];
+  if (*Signature == EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
+Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)Signature;
 DEBUG ((DEBUG_INFO, "Found Fadt in Rsdt\n"));
   }
 
-  if (*(UINT32 *)(UINTN)(Entry32[Idx]) == 
EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE)
 {
-MmCfgHdr = 
(EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER 
*)(UINTN)(Entry32[Idx]);
+  if (*Signature == 
EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE)
 {
+MmCfgHdr = 
(EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *)Signature;
 DEBUG ((DEBUG_INFO, "Found MM config address in Rsdt\n"));
   }
 
@@ -205,13 +207,14 @@ ParseAcpiInfo (
 Entry64  = (UINT64 *)(Xsdt + 1);
 Entry64Num = (Xsdt->Length - sizeof(EFI_ACPI_DESCRIPTION_HEADER)) >> 3;
 for (Idx = 0; Idx < Entry64Num; Idx++) {
-  if (*(UINT32 *)(UINTN)(Entry64[Idx]) == 
EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
-Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE 
*)(UINTN)(Entry64[Idx]);
+  Signature = (UINT32 *)(UINTN)Entry64[Idx];
+  if (*Signature == EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) {
+Fadt = (EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)Signature;
 DEBUG ((DEBUG_INFO, "Found Fadt in Xsdt\n"));
   }
 
-  if (*(UINT32 *)(UINTN)(Entry64[Idx]) == 
EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE)
 {
-MmCfgHdr = 
(EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER 
*)(UINTN)(Entry32[Idx]);
+  if (*Signature == 
EFI_ACPI_5_0_PCI_EXPRESS_MEMORY_MAPPED_CONFIGURATION_SPACE_BASE_ADDRESS_DESCRIPTION_TABLE_SIGNATURE)
 {
+MmCfgHdr = 
(EFI_ACPI_MEMORY_MAPPED_CONFIGURATION_BASE_ADDRESS_TABLE_HEADER *)Signature;
 DEBUG ((DEBUG_INFO, "Found MM config address in Xsdt\n"));
   }
 
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47421): https://edk2.groups.io/g/devel/message/47421
Mute This Topic: https://groups.io/mt/34180239/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug

[Laszlo Ersek]

The EDK 1 Shell (available at )
has a bug in its EFI_SHELL_ENVIRONMENT2.Execute() implementation that
edk2's UefiShellLib has no choice but to work around.

Improve the explanation in the code. Also, document the implicit
EFI_HANDLE -> (EFI_HANDLE*) conversion, which happens implicitly after
dereferencing ParentHandle, with an explicit cast.

In practice, this patch is a no-op.

Cc: Jaben Carsey 
Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 22 ++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 835d0f88ca74..9f07a58eb23d 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -1291,9 +1291,27 @@ ShellExecute (
   if (mEfiShellEnvironment2 != NULL) {
 //
 // Call EFI Shell version.
-// Due to oddity in the EFI shell we want to dereference the ParentHandle 
here
 //
-CmdStatus = (mEfiShellEnvironment2->Execute(*ParentHandle,
+// Due to an unfixable bug in the EdkShell implementation, we must
+// dereference "ParentHandle" here:
+//
+// 1. The EFI shell installs the EFI_SHELL_ENVIRONMENT2 protocol,
+//identified by gEfiShellEnvironment2Guid.
+// 2. The Execute() member function takes "ParentImageHandle" as first
+//parameter, with type (EFI_HANDLE*).
+// 3. In the EdkShell implementation, SEnvExecute() implements the
+//Execute() member function. It passes "ParentImageHandle" correctly to
+//SEnvDoExecute().
+// 4. SEnvDoExecute() takes the (EFI_HANDLE*), and passes it directly --
+//without de-referencing -- to the HandleProtocol() boot service.
+// 5. But HandleProtocol() takes an EFI_HANDLE.
+//
+// Therefore we must
+// - de-reference "ParentHandle" here, to mask the bug in
+//   SEnvDoExecute(), and
+// - pass the resultant EFI_HANDLE as an (EFI_HANDLE*).
+//
+CmdStatus = (mEfiShellEnvironment2->Execute((EFI_HANDLE *)*ParentHandle,
   CommandLine,
   Output));
 //
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47419): https://edk2.groups.io/g/devel/message/47419
Mute This Topic: https://groups.io/mt/34180236/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast

[Laszlo Ersek]

The HandleProtocol() boot service takes an EFI_HANDLE, not an
(EFI_HANDLE*). Remove the bogus cast in the
InternalImageHandleToFvHandle() function.

This is a semantic cleanup; there is no change in behavior.

Cc: Liming Gao 
Cc: Michael D Kinney 
Signed-off-by: Laszlo Ersek 
---

Notes:
lightly tested, most probably: it's practically impossible to build a
platform without consuming DxeServicesLib

 MdePkg/Library/DxeServicesLib/DxeServicesLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c 
b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
index c416b2dd8c65..0735b2f80400 100644
--- a/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
+++ b/MdePkg/Library/DxeServicesLib/DxeServicesLib.c
@@ -49,7 +49,7 @@ InternalImageHandleToFvHandle (
   ASSERT (ImageHandle != NULL);
 
   Status = gBS->HandleProtocol (
- (EFI_HANDLE *) ImageHandle,
+ ImageHandle,
  ,
  (VOID **) 
  );
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47404): https://edk2.groups.io/g/devel/message/47404
Mute This Topic: https://groups.io/mt/34180218/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list

[Laszlo Ersek]

The SockFreeFoo() callback function for NetbufFromExt() has to match the
NET_VECTOR_EXT_FREE prototype, which takes a (VOID*) as callback argument
(Arg). EFI_EVENT has nothing to do with NET_VECTOR_EXT_FREE. Fix the
SockFreeFoo() parameter list.

This change is a no-op in practice.

Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 NetworkPkg/TcpDxe/SockImpl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/NetworkPkg/TcpDxe/SockImpl.c b/NetworkPkg/TcpDxe/SockImpl.c
index f5e01771e2a8..fb28e2ed40d3 100644
--- a/NetworkPkg/TcpDxe/SockImpl.c
+++ b/NetworkPkg/TcpDxe/SockImpl.c
@@ -67,13 +67,13 @@ SockBufNext (
 /**
   User provided callback function for NetbufFromExt.
 
-  @param[in] EventThe Event this notify function registered to, ignored.
+  @param[in] Arg  The Arg parameter forwarded by NetbufFromExt(). Ignored.
 
 **/
 VOID
 EFIAPI
 SockFreeFoo (
-  IN EFI_EVENT Event
+  IN VOID  *Arg
   )
 {
   return;
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47408): https://edk2.groups.io/g/devel/message/47408
Mute This Topic: https://groups.io/mt/34180222/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls

[Laszlo Ersek]

The last parameter of ReserveResourceInGcd() is "ImageHandle", forwarded
in turn to gDS->AllocateMemorySpace() or gDS->AllocateIoSpace() as "owner"
image handle.

But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle".

Compilers have not flagged it because EFI_HANDLE (the type of
"ImageHandle") is unfortunately specified as (VOID*), and
(EFI_SYSTEM_TABLE*) converts to (VOID*) silently.

Hand the entry point function's "ImageHandle" parameter to
ReserveResourceInGcd(). This fixes an actual bug.

Cc: Benjamin You 
Cc: Guo Dong 
Cc: Maurice Ma 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c 
b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
index bcee4cd9bc41..28dfc8fc5545 100644
--- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
+++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
@@ -106,10 +106,10 @@ BlDxeEntryPoint (
   //
   // Report MMIO/IO Resources
   //
-  Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 
0xFEC0, SIZE_4KB, 0, SystemTable); // IOAPIC
+  Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 
0xFEC0, SIZE_4KB, 0, ImageHandle); // IOAPIC
   ASSERT_EFI_ERROR (Status);
 
-  Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 
0xFED0, SIZE_1KB, 0, SystemTable); // HPET
+  Status = ReserveResourceInGcd (TRUE, EfiGcdMemoryTypeMemoryMappedIo, 
0xFED0, SIZE_1KB, 0, ImageHandle); // HPET
   ASSERT_EFI_ERROR (Status);
 
   //
-- 
2.19.1.3.g30247aa5d201


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47422): https://edk2.groups.io/g/devel/message/47422
Mute This Topic: https://groups.io/mt/34180240/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE

[Laszlo Ersek]

The UefiShell*CommandsLib instances have constructor functions that do
something like:

  gHiiHandle = HiiAddPackages (...);
  ...
  ShellCommandRegisterCommandName (..., gHiiHandle, ...);

and destructor functions that implement the following pattern:

  HiiRemovePackages (gHiiHandle);

The -- semantic, not functional -- problem is that "gHiiHandle" is
declared with type EFI_HANDLE, and not EFI_HII_HANDLE, in all of these
library instances, even though HiiAddPackages() correctly returns
EFI_HII_HANDLE, and HiiRemovePackages() takes EFI_HII_HANDLE.

Once we fix the type of "gHiiHandle", it causes sort of a butterfly
effect, because it is passed around widely. Track down and update all of
those locations.

The DynamicCommand lib instances use a similar pattern, so they are
affected too.

NOTE: in practice, this patch is a no-op, as both EFI_HII_HANDLE and
EFI_HANDLE are typedefs to (VOID*). However, we shouldn't use EFI_HANDLE
where semantically EFI_HII_HANDLE is passed around.

Cc: Jaben Carsey 
Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Laszlo Ersek 
---

Notes:
tested with:
- level 1: stall, exit
- level 2: ls
- level 3: pause
- dynamic command: tftp
- handle parsing: drivers, devices, dh

 ShellPkg/Include/Library/ShellCommandLib.h   | 
2 +-
 ShellPkg/Include/Library/ShellLib.h  | 
4 ++--
 ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h| 
4 ++--
 ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h| 
4 ++--
 ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h   | 
2 +-
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h | 
2 +-
 ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.h   | 
2 +-
 ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h | 
2 +-
 ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h | 
2 +-
 ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h | 
2 +-
 ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.h | 
2 +-
 ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.h | 
2 +-
 ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c| 
6 +++---
 ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c| 
6 +++---
 ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c | 
2 +-
 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c   | 
2 +-
 ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c   | 
2 +-
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c | 
2 +-
 ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.c   | 
2 +-
 ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c | 
2 +-
 ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c | 
2 +-
 ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c | 
2 +-
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 
4 ++--
 ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.c | 
2 +-
 ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.c | 
2 +-
 25 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/ShellPkg/Include/Library/ShellCommandLib.h 
b/ShellPkg/Include/Library/ShellCommandLib.h
index 287bc0eba7f9..63fcac82a2de 100644
--- a/ShellPkg/Include/Library/ShellCommandLib.h
+++ b/ShellPkg/Include/Library/ShellCommandLib.h
@@ -136,7 +136,7 @@ ShellCommandRegisterCommandName (
   INUINT32  ShellMinSupportLevel,
   IN CONST  CHAR16  *ProfileName,
   IN CONST  BOOLEAN CanAffectLE,
-  IN CONST  EFI_HANDLE  HiiHandle,
+  IN CONST  EFI_HII_HANDLE  HiiHandle,
   IN CONST  EFI_STRING_ID   ManFormatHelp
   );
 
diff --git a/ShellPkg/Include/Library/ShellLib.h 
b/ShellPkg/Include/Library/ShellLib.h
index 31594796cd21..1dc41f2cc11b 100644
--- a/ShellPkg/Include/Library/ShellLib.h
+++ b/ShellPkg/Include/Library/ShellLib.h
@@ -965,7 +965,7 @@ ShellPrintHiiEx(
   IN INT32Row OPTIONAL,
   IN CONST CHAR8  *Language OPTIONAL,
   IN CONST EFI_STRING_ID  HiiFormatStringId,
-  IN CONST EFI_HANDLE HiiFormatHandle,
+  IN CONST EFI_HII_HANDLE HiiFormatHandle,
   ...
   );
 
@@ -1260,7 +1260,7 @@ EFIAPI
 ShellPromptForResponseHii (
   IN SHELL_PROMPT_REQUEST_TYPE Type,
   IN CONST EFI_STRING_ID  HiiFormatStringId,
-  IN CONST EFI_HANDLE HiiFormatHandle,
+  IN CONST EFI_HII_HANDLE HiiFormatHandle,
   IN OUT VOID **Response
   );
 
diff --git a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h 
b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
index 

[edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration

[Laszlo Ersek]

EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
similarly to gBS->RegisterProtocolNotify(). We should pass the address of
an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
just happens to be specified as (VOID*), and has nothing to do with the
registration.

This change is a no-op in practice; it's a semantic improvement.

Cc: Chao Zhang 
Cc: Jian Wang 
Cc: Jiewen Yao 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 SecurityPkg/HddPassword/HddPasswordDxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.c 
b/SecurityPkg/HddPassword/HddPasswordDxe.c
index b0d795b6597f..051e64091d7f 100644
--- a/SecurityPkg/HddPassword/HddPasswordDxe.c
+++ b/SecurityPkg/HddPassword/HddPasswordDxe.c
@@ -2770,7 +2770,7 @@ HddPasswordDxeInit (
 {
   EFI_STATUS Status;
   HDD_PASSWORD_DXE_PRIVATE_DATA  *Private;
-  EFI_EVENT  Registration;
+  VOID   *Registration;
   EFI_EVENT  EndOfDxeEvent;
   EDKII_VARIABLE_LOCK_PROTOCOL   *VariableLock;
 
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47414): https://edk2.groups.io/g/devel/message/47414
Mute This Topic: https://groups.io/mt/34180229/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call

[Laszlo Ersek]

In the FileBufferSave() function, we invoke ShellCloseFile() if "Directory
Can Not Be Saved".

The ShellCloseFile() function takes a (SHELL_FILE_HANDLE*) parameter
called "FileHandle", and correctly passes the de-referenced (*FileHandle)
to EFI_SHELL_CLOSE_FILE, which takes a SHELL_FILE_HANDLE.

However, FileBufferSave() passes SHELL_FILE_HANDLE to ShellCloseFile(),
not the expected (SHELL_FILE_HANDLE*). Correct it.

This fixes an actual bug that has remained hidden for two reasons:

- pointer-to-VOID converts from/to any pointer-to-object type silently,
- the bug is on an error path which has likely never fired in practice.

Cc: Jaben Carsey 
Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Laszlo Ersek 
---

Notes:
tested: edit (saving a file)

 ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
index 464f9de38e52..fd324cc4a861 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
@@ -1462,7 +1462,7 @@ FileBufferSave (
 
 if (Info != NULL && Info->Attribute & EFI_FILE_DIRECTORY) {
   StatusBarSetStatusString (L"Directory Can Not Be Saved");
-  ShellCloseFile(FileHandle);
+  ShellCloseFile ();
   FreePool(Info);
   return EFI_LOAD_ERROR;
 }
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47418): https://edk2.groups.io/g/devel/message/47418
Mute This Topic: https://groups.io/mt/34180234/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call

[Laszlo Ersek]

According to the UEFI spec -- and to the edk2 header
"MdePkg/Include/Protocol/EdidOverride.h" too --,
EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID takes an (EFI_HANDLE*), and not an
EFI_HANDLE, as second parameter ("ChildHandle").

This is probably [*] a bug in the UEFI spec. Given that this CSM module
(VideoDxe) had been used for a long time on physical platforms before it
was moved to OvmfPkg, keep the current "ChildHandle" argument, just cast
it explicitly.

[*] The edk2 tree contains no other GetEdid() call, and also no GetEdid()
implementation.

The edk2-platforms tree contains two GetEdid() calls, at commit
022c212167e0, in files
- "Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c",
- "Drivers/OptionRomPkg/CirrusLogic5430Dxe/Edid.c".

From these, the first passes an (EFI_HANDLE*) as "ChildHandle", the
second passes an EFI_HANDLE. It's difficult to draw a conclusion. :/

No functional changes.

(I've also requested a non-normative (informative) clarification for the
UEFI spec: , in the
direction that matches this patch.)

Cc: Ard Biesheuvel 
Cc: David Woodhouse 
Cc: Jordan Justen 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c 
b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
index 0640656dba14..995136adee27 100644
--- a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
+++ b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c
@@ -1402,9 +1402,13 @@ BiosVideoCheckForVbe (
   goto Done;
 }
 
+//
+// Cast "ChildHandle" to (EFI_HANDLE*) in order to work around the spec bug
+// in UEFI v2.8, reported as Mantis#2018.
+//
 Status = EdidOverride->GetEdid (
  EdidOverride,
- BiosVideoPrivate->Handle,
+ (EFI_HANDLE *) BiosVideoPrivate->Handle,
  ,
  ,
  (UINT8 **) 
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47412): https://edk2.groups.io/g/devel/message/47412
Mute This Topic: https://groups.io/mt/34180226/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking

[Laszlo Ersek]

The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
that every firmware volume is processed only once (every driver in every
firmware volume should be discovered only once). For this, the functions
use a linked list.

In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
those firmware volumes that have been processed is the EFI_HANDLE on which
the DXE or SMM firmware volume protocol is installed. In the
StandaloneMmPkg core however, the key is the address of the firmware
volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).

(EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
EFI_HANDLE just happens to be specified as (VOID*), and therefore the
conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.

(The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
conversion.)

We should not exploit this circumstance. Represent the key type faithfully
instead.

This is a semantic fix; there is no change in operation.

Cc: Achin Gupta 
Cc: Jiewen Yao 
Cc: Supreeth Venkatesh 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 StandaloneMmPkg/Core/StandaloneMmCore.h |  2 +-
 StandaloneMmPkg/Core/Dispatcher.c   | 80 +++-
 StandaloneMmPkg/Core/FwVol.c| 16 ++--
 3 files changed, 52 insertions(+), 46 deletions(-)

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h 
b/StandaloneMmPkg/Core/StandaloneMmCore.h
index dcf91bc5e916..23ddbe169faf 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.h
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
@@ -67,7 +67,7 @@ typedef struct {
 
   LIST_ENTRY  ScheduledLink;// mScheduledQueue
 
-  EFI_HANDLE  FvHandle;
+  EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader;
   EFI_GUIDFileName;
   VOID*Pe32Data;
   UINTN   Pe32DataSize;
diff --git a/StandaloneMmPkg/Core/Dispatcher.c 
b/StandaloneMmPkg/Core/Dispatcher.c
index 3788389f95ed..9853445a64a1 100644
--- a/StandaloneMmPkg/Core/Dispatcher.c
+++ b/StandaloneMmPkg/Core/Dispatcher.c
@@ -5,7 +5,7 @@
 is added to the mDiscoveredList. The Before, and After Depex are
 pre-processed as drivers are added to the mDiscoveredList. If an 
Apriori
 file exists in the FV those drivers are addeded to the
-mScheduledQueue. The mFvHandleList is used to make sure a
+mScheduledQueue. The mFwVolList is used to make sure a
 FV is only processed once.
 
   Step #2 - Dispatch. Remove driver from the mScheduledQueue and load and
@@ -40,13 +40,13 @@
 //
 // MM Dispatcher Data structures
 //
-#define KNOWN_HANDLE_SIGNATURE  SIGNATURE_32('k','n','o','w')
+#define KNOWN_FWVOL_SIGNATURE  SIGNATURE_32('k','n','o','w')
 
 typedef struct {
-  UINTN   Signature;
-  LIST_ENTRY  Link; // mFvHandleList
-  EFI_HANDLE  Handle;
-} KNOWN_HANDLE;
+  UINTN  Signature;
+  LIST_ENTRY Link; // mFwVolList
+  EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
+} KNOWN_FWVOL;
 
 //
 // Function Prototypes
@@ -86,9 +86,10 @@ LIST_ENTRY  mDiscoveredList = INITIALIZE_LIST_HEAD_VARIABLE 
(mDiscoveredList);
 LIST_ENTRY  mScheduledQueue = INITIALIZE_LIST_HEAD_VARIABLE (mScheduledQueue);
 
 //
-// List of handles who's Fv's have been parsed and added to the mFwDriverList.
+// List of firmware volume headers whose containing firmware volumes have been
+// parsed and added to the mFwDriverList.
 //
-LIST_ENTRY  mFvHandleList = INITIALIZE_LIST_HEAD_VARIABLE (mFvHandleList);
+LIST_ENTRY  mFwVolList = INITIALIZE_LIST_HEAD_VARIABLE (mFwVolList);
 
 //
 // Flag for the MM Dispacher.  TRUE if dispatcher is execuing.
@@ -769,26 +770,30 @@ MmInsertOnScheduledQueueWhileProcessingBeforeAndAfter (
 }
 
 /**
-  Return TRUE if the Fv has been processed, FALSE if not.
+  Return TRUE if the firmware volume has been processed, FALSE if not.
 
-  @param  FvHandle  The handle of a FV that's being tested
+  @param  FwVolHeader   The header of the firmware volume that's being
+tested.
 
-  @retval TRUE  Fv protocol on FvHandle has been processed
-  @retval FALSE Fv protocol on FvHandle has not yet been
-processed
+  @retval TRUE  The firmware volume denoted by FwVolHeader has
+been processed
+  @retval FALSE The firmware volume denoted by FwVolHeader has
+not yet been processed
 
 **/
 BOOLEAN
 FvHasBeenProcessed (
-  IN EFI_HANDLE  FvHandle
+  IN EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader
   )
 {
   LIST_ENTRY

[edk2-devel] [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls

[Laszlo Ersek]

Both the "ControllerHandle" parameter of CloseProtocol() and the "Handle"
parameter of UninstallMultipleProtocolInterfaces() have type EFI_HANDLE,
not (EFI_HANDLE*).

This patch fixes actual bugs. The issues have been dormant likely because
they are on error paths. (Or, in case of TlsAuthConfigDxe, because the
driver is unloaded likely very infrequently.)

Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 NetworkPkg/DnsDxe/DnsDriver.c  | 4 ++--
 NetworkPkg/IScsiDxe/IScsiConfig.c  | 2 +-
 NetworkPkg/Ip4Dxe/Ip4Driver.c  | 2 +-
 NetworkPkg/Ip6Dxe/Ip6Driver.c  | 2 +-
 NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c| 2 +-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/NetworkPkg/DnsDxe/DnsDriver.c b/NetworkPkg/DnsDxe/DnsDriver.c
index 94d072159a4d..ad007da8b7d6 100644
--- a/NetworkPkg/DnsDxe/DnsDriver.c
+++ b/NetworkPkg/DnsDxe/DnsDriver.c
@@ -1145,7 +1145,7 @@ Dns4ServiceBindingCreateChild (
DnsSb->ConnectUdp->UdpHandle,
,
gDns4DriverBinding.DriverBindingHandle,
-   ChildHandle
+   *ChildHandle
);
 
  gBS->UninstallMultipleProtocolInterfaces (
@@ -1388,7 +1388,7 @@ Dns6ServiceBindingCreateChild (
DnsSb->ConnectUdp->UdpHandle,
,
gDns6DriverBinding.DriverBindingHandle,
-   ChildHandle
+   *ChildHandle
);
 
  gBS->UninstallMultipleProtocolInterfaces (
diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c 
b/NetworkPkg/IScsiDxe/IScsiConfig.c
index b876da7f5ccd..d773849fd3b0 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfig.c
+++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
@@ -3852,7 +3852,7 @@ IScsiConfigFormInit (
  );
   if (CallbackInfo->RegisteredHandle == NULL) {
 gBS->UninstallMultipleProtocolInterfaces (
-   >DriverHandle,
+   CallbackInfo->DriverHandle,
,
,
,
diff --git a/NetworkPkg/Ip4Dxe/Ip4Driver.c b/NetworkPkg/Ip4Dxe/Ip4Driver.c
index ebd4dec1dfe4..62be8b681a18 100644
--- a/NetworkPkg/Ip4Dxe/Ip4Driver.c
+++ b/NetworkPkg/Ip4Dxe/Ip4Driver.c
@@ -891,7 +891,7 @@ Ip4ServiceBindingCreateChild (
   );
   if (EFI_ERROR (Status)) {
 gBS->UninstallMultipleProtocolInterfaces (
-   ChildHandle,
+   *ChildHandle,
,
>Ip4Proto,
NULL
diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c b/NetworkPkg/Ip6Dxe/Ip6Driver.c
index 7dc9e45af7b6..63d8428dbced 100644
--- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
+++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
@@ -888,7 +888,7 @@ Ip6ServiceBindingCreateChild (
   );
   if (EFI_ERROR (Status)) {
 gBS->UninstallMultipleProtocolInterfaces (
-   ChildHandle,
+   *ChildHandle,
,
>Ip6Proto,
NULL
diff --git a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c 
b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
index ae9e65544a86..06c4e202d3ef 100644
--- a/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
+++ b/NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c
@@ -592,7 +592,7 @@ Mtftp4ServiceBindingCreateChild (
MtftpSb->ConnectUdp->UdpHandle,
,
gMtftp4DriverBinding.DriverBindingHandle,
-   ChildHandle
+   *ChildHandle
);
 goto ON_ERROR;
   }
diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c 
b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
index 18ee763002b4..c0870ab9979c 100644
--- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
+++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c
@@ -39,7 +39,7 @@ TlsAuthConfigDxeUnload (
   ASSERT (PrivateData->Signature == TLS_AUTH_CONFIG_PRIVATE_DATA_SIGNATURE);
 
   gBS->UninstallMultipleProtocolInterfaces (
- ,
+ ImageHandle,
  ,
  PrivateData,
  NULL
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47406): https://edk2.groups.io/g/devel/message/47406
Mute This Topic: https://groups.io/mt/34180220/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call

[Laszlo Ersek]

The SignalEvent() boot service takes an EFI_EVENT, not an (EFI_EVENT*).
Fix the call in the notification function of
"EFI_SIMPLE_NETWORK_PROTOCOL.WaitForPacket".

This is an actual bug. The reason it's never been triggered is likely that
the "SNP.WaitForPacket" event is rarely waited for by applications -- edk2
itself has zero instances of that, for example.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 OvmfPkg/VirtioNetDxe/Events.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/VirtioNetDxe/Events.c b/OvmfPkg/VirtioNetDxe/Events.c
index 620910774bc5..83e96e5e5d91 100644
--- a/OvmfPkg/VirtioNetDxe/Events.c
+++ b/OvmfPkg/VirtioNetDxe/Events.c
@@ -58,7 +58,7 @@ VirtioNetIsPacketAvailable (
   MemoryFence ();
 
   if (Dev->RxLastUsed != RxCurUsed) {
-gBS->SignalEvent (>Snp.WaitForPacket);
+gBS->SignalEvent (Dev->Snp.WaitForPacket);
   }
 }
 
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47410): https://edk2.groups.io/g/devel/message/47410
Mute This Topic: https://groups.io/mt/34180224/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo

[Laszlo Ersek]

The ShellCommandRunConnect() function passes EFI_HANDLE -- (VOID*) --
objects to ConvertAndConnectControllers(), and
ConvertAndConnectControllers() passes those to gBS->OpenProtocol().

Accordingly, ConvertAndConnectControllers() should specify EFI_HANDLE
parameter types, not (EFI_HANDLE*) -- (VOID**) -- types.

This typo is masked because (VOID*) converts to and from any
pointer-to-object type silently.

Note that functionally speaking there is no problem, so this patch does
not change beavior, only cleans up the code.

Cc: Jaben Carsey 
Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Laszlo Ersek 
---

Notes:
tested with "connect -r"

 ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c 
b/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
index 359394dfd291..3f4e132674ea 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c
@@ -346,8 +346,8 @@ ShellConnectFromDevPaths (
 **/
 EFI_STATUS
 ConvertAndConnectControllers (
-  IN EFI_HANDLE *Handle1 OPTIONAL,
-  IN EFI_HANDLE *Handle2 OPTIONAL,
+  IN EFI_HANDLE Handle1 OPTIONAL,
+  IN EFI_HANDLE Handle2 OPTIONAL,
   IN CONST BOOLEAN  Recursive,
   IN CONST BOOLEAN  Output
   )
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47415): https://edk2.groups.io/g/devel/message/47415
Mute This Topic: https://groups.io/mt/34180231/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls

[Laszlo Ersek]

Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.

These are actual bugs. They must have remained hidden until now because
they are all in Unload() functions, which are probably exercised
infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.

Cc: Chao Zhang 
Cc: Jian Wang 
Cc: Jiewen Yao 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c  
| 2 +-
 SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c 
| 2 +-
 SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c 
| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c 
b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
index 54155a338100..9052eced757d 100644
--- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
+++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
@@ -443,7 +443,7 @@ Tcg2ConfigDriverUnload (
   ASSERT (PrivateData->Signature == TCG2_CONFIG_PRIVATE_DATA_SIGNATURE);
 
   gBS->UninstallMultipleProtocolInterfaces (
- ,
+ ImageHandle,
  ,
  PrivateData,
  NULL
diff --git a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c 
b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
index 341879e4c4ba..fb06624fdb8f 100644
--- a/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
+++ b/SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c
@@ -138,7 +138,7 @@ TcgConfigDriverUnload (
   ASSERT (PrivateData->Signature == TCG_CONFIG_PRIVATE_DATA_SIGNATURE);
 
   gBS->UninstallMultipleProtocolInterfaces (
- ,
+ ImageHandle,
  ,
  PrivateData,
  NULL
diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
index 798ef9cfbc01..6c0294151e6c 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
+++ 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDriver.c
@@ -115,7 +115,7 @@ SecureBootConfigDriverUnload (
   ASSERT (PrivateData->Signature == SECUREBOOT_CONFIG_PRIVATE_DATA_SIGNATURE);
 
   gBS->UninstallMultipleProtocolInterfaces (
- ,
+ ImageHandle,
  ,
  PrivateData,
  NULL
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47413): https://edk2.groups.io/g/devel/message/47413
Mute This Topic: https://groups.io/mt/34180228/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE

[Laszlo Ersek]

The TouchFileByHandle() and IsDirectoryEmpty() functions are passed
SHELL_FILE_HANDLE parameters, and they use those parameters correctly.
However, their parameter lists say EFI_HANDLE.

Spell out the right type in the parameter lists.

In practice, this change is a no-op (because, quite regrettably, both
EFI_HANDLE and SHELL_FILE_HANDLE are specified to be typedefs of (VOID*)).

Cc: Jaben Carsey 
Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Laszlo Ersek 
---

Notes:
tested: rm, touch

 ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c| 2 +-
 ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
index 3a1196f1529e..59f7eec376f2 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c
@@ -24,7 +24,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
 **/
 BOOLEAN
 IsDirectoryEmpty (
-  IN EFI_HANDLE   FileHandle
+  IN SHELL_FILE_HANDLE   FileHandle
   )
 {
   EFI_STATUS  Status;
diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c 
b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
index 0f00344c815e..a215f5774c69 100644
--- a/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
+++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c
@@ -21,7 +21,7 @@
 **/
 EFI_STATUS
 TouchFileByHandle (
-  IN EFI_HANDLE Handle
+  IN SHELL_FILE_HANDLE Handle
   )
 {
   EFI_STATUSStatus;
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47417): https://edk2.groups.io/g/devel/message/47417
Mute This Topic: https://groups.io/mt/34180233/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call

[Laszlo Ersek]

Both NetLibDestroyServiceChild() and EFI_SERVICE_BINDING_DESTROY_CHILD
take an EFI_HANDLE for the "ChildHandle" parameter, not an (EFI_HANDLE*).

This patch fixes a real bug.

Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Signed-off-by: Laszlo Ersek 
---

Notes:
possibly only build-tested

 NetworkPkg/Ip4Dxe/Ip4If.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/NetworkPkg/Ip4Dxe/Ip4If.c b/NetworkPkg/Ip4Dxe/Ip4If.c
index 44b8d9fc8faf..53a333037f94 100644
--- a/NetworkPkg/Ip4Dxe/Ip4If.c
+++ b/NetworkPkg/Ip4Dxe/Ip4If.c
@@ -592,7 +592,7 @@ Ip4SetAddress (
   Interface->Controller,
   Interface->Image,
   ,
-  >ArpHandle
+  Interface->ArpHandle
   );
 
 Interface->ArpHandle = NULL;
@@ -657,7 +657,7 @@ ON_ERROR:
 Interface->Controller,
 Interface->Image,
 ,
->ArpHandle
+Interface->ArpHandle
 );
 
   return Status;
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47407): https://edk2.groups.io/g/devel/message/47407
Mute This Topic: https://groups.io/mt/34180221/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions

[Laszlo Ersek]

In the following call tree:

 PlatformInit ()
   mInstalledPackages = HiiAddPackages ()
 GopInstalled ()
PopulateForm (PackageList = mInstalledPackages)
  CreateResolutionOptions (PackageList)
HiiSetString (PackageList
  HiiUpdateForm (PackageList)

PlatformDxe passes around an EFI_HII_HANDLE that (a) originates from
HiiAddPackages() and (b) is ultimately passed to HiiSetString() and
HiiUpdateForm(). The intermediate functions PopulateForm() and
CreateResolutionOptions() however take that parameter as an
(EFI_HII_HANDLE*).

There is no bug in practice (because the affected functions never try to
de-reference the "PackageList" parameter, they just pass it on), but the
function prototypes are semantically wrong. Fix that.

This could remain hidden so long because pointer-to-VOID silently converts
to/from any pointer-to-object type, and the UEFI spec mandates that
EFI_HII_HANDLE be a typedef to (VOID*).

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Signed-off-by: Laszlo Ersek 
---

Notes:
tested in UiApp

 OvmfPkg/PlatformDxe/Platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/PlatformDxe/Platform.c b/OvmfPkg/PlatformDxe/Platform.c
index 09181769babf..23ad43901f66 100644
--- a/OvmfPkg/PlatformDxe/Platform.c
+++ b/OvmfPkg/PlatformDxe/Platform.c
@@ -486,7 +486,7 @@ STATIC
 EFI_STATUS
 EFIAPI
 CreateResolutionOptions (
-  IN  EFI_HII_HANDLE  *PackageList,
+  IN  EFI_HII_HANDLE  PackageList,
   OUT VOID**OpCodeBuffer,
   IN  UINTN   NumGopModes,
   IN  GOP_MODE*GopModes
@@ -547,7 +547,7 @@ STATIC
 EFI_STATUS
 EFIAPI
 PopulateForm (
-  IN  EFI_HII_HANDLE  *PackageList,
+  IN  EFI_HII_HANDLE  PackageList,
   IN  EFI_GUID*FormSetGuid,
   IN  EFI_FORM_ID FormId,
   IN  UINTN   NumGopModes,
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47411): https://edk2.groups.io/g/devel/message/47411
Mute This Topic: https://groups.io/mt/34180225/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()

[Laszlo Ersek]

NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
NULL-check. Fix the type of "SnpHandle".

This patch is a no-op.

Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Signed-off-by: Laszlo Ersek 
---

Notes:
lightly tested: MAC strings are displayed in UiApp

 NetworkPkg/Library/DxeNetLib/DxeNetLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c 
b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
index 8e2f720666ea..a39c20be3d34 100644
--- a/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
+++ b/NetworkPkg/Library/DxeNetLib/DxeNetLib.c
@@ -2182,7 +2182,7 @@ NetLibGetMacAddress (
   EFI_SIMPLE_NETWORK_MODE  SnpModeData;
   EFI_MANAGED_NETWORK_PROTOCOL *Mnp;
   EFI_SERVICE_BINDING_PROTOCOL *MnpSb;
-  EFI_HANDLE   *SnpHandle;
+  EFI_HANDLE   SnpHandle;
   EFI_HANDLE   MnpChildHandle;
 
   ASSERT (MacAddress != NULL);
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47405): https://edk2.groups.io/g/devel/message/47405
Mute This Topic: https://groups.io/mt/34180219/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call

[Laszlo Ersek]

Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.

This is an actual bug. It must have remained hidden until now because it's
on an error path. Fix the UninstallMultipleProtocolInterfaces() call.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 OvmfPkg/XenBusDxe/XenBus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/XenBusDxe/XenBus.c b/OvmfPkg/XenBusDxe/XenBus.c
index bb8ddbc4d44d..2451e58a5961 100644
--- a/OvmfPkg/XenBusDxe/XenBus.c
+++ b/OvmfPkg/XenBusDxe/XenBus.c
@@ -210,7 +210,7 @@ XenBusAddDevice (
 
 ErrorOpenProtocolByChild:
   gBS->UninstallMultipleProtocolInterfaces (
->Handle,
+Private->Handle,
 , Private->DevicePath,
 , >XenBusIo,
 NULL);
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47409): https://edk2.groups.io/g/devel/message/47409
Mute This Topic: https://groups.io/mt/34180223/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration

[Laszlo Ersek]

EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
the notification handle to have type (VOID*). The notification handle has
nothing to do with the EFI_HANDLE type.

This change is a semantic fix; functionally, it's a no-op.

Cc: Dandan Bi 
Cc: Eric Dong 
Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Laszlo Ersek 
---

Notes:
lightly tested: ConSplitterDxe is part of the ArmVirt and OVMF platforms

 MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c | 2 +-
 MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c 
b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
index 63c814ae1816..9c38271b65f9 100644
--- a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
+++ b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
@@ -4026,7 +4026,7 @@ ConSplitterTextInRegisterKeyNotify (
   if (NewNotify == NULL) {
 return EFI_OUT_OF_RESOURCES;
   }
-  NewNotify->NotifyHandleList = (EFI_HANDLE *) AllocateZeroPool (sizeof 
(EFI_HANDLE) *  Private->TextInExListCount);
+  NewNotify->NotifyHandleList = (VOID **) AllocateZeroPool (sizeof (VOID *) *  
Private->TextInExListCount);
   if (NewNotify->NotifyHandleList == NULL) {
 gBS->FreePool (NewNotify);
 return EFI_OUT_OF_RESOURCES;
diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c 
b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
index 7cfd5c178861..f98797225b63 100644
--- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
+++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
@@ -143,7 +143,7 @@ InternalStartMonitor(
   EFI_HANDLE*Handles;
   UINTN HandleCount;
   UINTN HandleIndex;
-  EFI_HANDLENotifyHandle;
+  VOID  *NotifyHandle;
 
   Status = gBS->LocateHandleBuffer (
   ByProtocol,
@@ -202,7 +202,7 @@ InternalStopMonitor(
   EFI_KEY_DATA  KeyData;
   UINTN HandleCount;
   UINTN HandleIndex;
-  EFI_HANDLENotifyHandle;
+  VOID  *NotifyHandle;
 
   Status = gBS->LocateHandleBuffer (
 ByProtocol,
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47399): https://edk2.groups.io/g/devel/message/47399
Mute This Topic: https://groups.io/mt/34180213/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx()

[Laszlo Ersek]

Clean up two issues around FindFileEx():

- The "AprioriFile" parameter's type differs between the function
  declaration and the function definition. The correct type is
  (EFI_PEI_FILE_HANDLE*).

- "FfsFileHeader" has type (EFI_FFS_FILE_HEADER*); for clarity, we should
  cast it explicitly to EFI_PEI_FILE_HANDLE when assigning it to
  (*AprioriFile).

This is a semantic cleanup, there is no functional change.

Cc: Dandan Bi 
Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Liming Gao 
Signed-off-by: Laszlo Ersek 
---

Notes:
lightly tested: OVMF uses APRIORI PEI in the FDF files

 MdeModulePkg/Core/Pei/FwVol/FwVol.h | 2 +-
 MdeModulePkg/Core/Pei/FwVol/FwVol.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.h 
b/MdeModulePkg/Core/Pei/FwVol/FwVol.h
index 4082cfbec1f8..ca80e84e0fcb 100644
--- a/MdeModulePkg/Core/Pei/FwVol/FwVol.h
+++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.h
@@ -299,7 +299,7 @@ FindFileEx (
   IN  CONST EFI_GUID *FileName,   OPTIONAL
   INEFI_FV_FILETYPE  SearchType,
   IN OUTEFI_PEI_FILE_HANDLE  *FileHandle,
-  IN OUTEFI_PEI_FV_HANDLE*AprioriFile  OPTIONAL
+  IN OUTEFI_PEI_FILE_HANDLE  *AprioriFile  OPTIONAL
   );
 
 /**
diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.c 
b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
index 709db00694c2..f4642c47c13a 100644
--- a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
+++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
@@ -407,7 +407,7 @@ FindFileEx (
 } else if (AprioriFile != NULL) {
   if (FfsFileHeader->Type == EFI_FV_FILETYPE_FREEFORM) {
 if (CompareGuid (>Name, )) {
-  *AprioriFile = FfsFileHeader;
+  *AprioriFile = (EFI_PEI_FILE_HANDLE)FfsFileHeader;
 }
   }
 }
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47400): https://edk2.groups.io/g/devel/message/47400
Mute This Topic: https://groups.io/mt/34180214/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent

[Laszlo Ersek]

The SmiHandlerRegister() function explicitly casts "SmiHandler" (of type
(SMI_HANDLER*)) to EFI_HANDLE, when outputting "DispatchHandle".

Apply the same cast in the counterpart function SmiHandlerUnRegister(),
which compares multiple "SmiHandler"s against the input "DispatchHandle".

This is a semantic cleanup; there is no functional change.

Cc: Eric Dong 
Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Ray Ni 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only, most likely -- I'm unaware of any code paths in OVMF
that would lead to SmiHandlerUnRegister()

 MdeModulePkg/Core/PiSmmCore/Smi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c 
b/MdeModulePkg/Core/PiSmmCore/Smi.c
index f8bd9f49ee3c..488af6754faf 100644
--- a/MdeModulePkg/Core/PiSmmCore/Smi.c
+++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
@@ -282,7 +282,7 @@ SmiHandlerUnRegister (
   //
   SmiHandler = NULL;
   for ( HandlerLink = GetFirstNode ()
-  ; !IsNull (, HandlerLink) && (SmiHandler != 
DispatchHandle)
+  ; !IsNull (, HandlerLink) && ((EFI_HANDLE) 
SmiHandler != DispatchHandle)
   ; HandlerLink = GetNextNode (, HandlerLink)
   ) {
 SmiHandler = CR (HandlerLink, SMI_HANDLER, Link, SMI_HANDLER_SIGNATURE);
@@ -292,19 +292,19 @@ SmiHandlerUnRegister (
   // Look for it in non-root SMI handlers
   //
   for ( EntryLink = GetFirstNode ()
-  ; !IsNull (, EntryLink) && (SmiHandler != DispatchHandle)
+  ; !IsNull (, EntryLink) && ((EFI_HANDLE) SmiHandler != 
DispatchHandle)
   ; EntryLink = GetNextNode (, EntryLink)
   ) {
 SmiEntry = CR (EntryLink, SMI_ENTRY, AllEntries, SMI_ENTRY_SIGNATURE);
 for ( HandlerLink = GetFirstNode (>SmiHandlers)
-; !IsNull (>SmiHandlers, HandlerLink) && (SmiHandler != 
DispatchHandle)
+; !IsNull (>SmiHandlers, HandlerLink) && ((EFI_HANDLE) 
SmiHandler != DispatchHandle)
 ; HandlerLink = GetNextNode (>SmiHandlers, HandlerLink)
 ) {
   SmiHandler = CR (HandlerLink, SMI_HANDLER, Link, SMI_HANDLER_SIGNATURE);
 }
   }
 
-  if (SmiHandler != DispatchHandle) {
+  if ((EFI_HANDLE) SmiHandler != DispatchHandle) {
 return EFI_INVALID_PARAMETER;
   }
 
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47402): https://edk2.groups.io/g/devel/message/47402
Mute This Topic: https://groups.io/mt/34180216/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE

[Laszlo Ersek]

HiiGetHiiHandles() returns an array of EFI_HII_HANDLEs, not EFI_HANDLEs.
HiiGetString() takes an EFI_HII_HANDLE, not an EFI_HANDLE.

This change is a no-op in practice; it's a semantic improvement.

Cc: Dandan Bi 
Cc: Eric Dong 
Cc: Hao A Wu 
Cc: Jian J Wang 
Signed-off-by: Laszlo Ersek 
---

Notes:
lightly tested, as UefiHiiLib is used by both ArmVirt and OVMF

 MdeModulePkg/Library/UefiHiiLib/HiiString.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiString.c 
b/MdeModulePkg/Library/UefiHiiLib/HiiString.c
index 498f245dce1f..95229f8a8c9f 100644
--- a/MdeModulePkg/Library/UefiHiiLib/HiiString.c
+++ b/MdeModulePkg/Library/UefiHiiLib/HiiString.c
@@ -173,8 +173,8 @@ HiiGetPackageString (
   IN CONST CHAR8 *Language  OPTIONAL
   )
 {
-  EFI_HANDLE  *HiiHandleBuffer;
-  EFI_HANDLE  HiiHandle;
+  EFI_HII_HANDLE  *HiiHandleBuffer;
+  EFI_HII_HANDLE  HiiHandle;
 
   ASSERT (PackageListGuid != NULL);
 
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47395): https://edk2.groups.io/g/devel/message/47395
Mute This Topic: https://groups.io/mt/34180208/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls

[Laszlo Ersek]

Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.

These are actual bugs. They must have remained hidden until now because
they are on error paths. Fix the UninstallMultipleProtocolInterfaces()
calls.

Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Ray Ni 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c | 2 +-
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c  | 2 +-
 MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c| 6 +++---
 MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c| 2 +-
 MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c| 2 +-
 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c   | 2 +-
 MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c | 2 +-
 7 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c 
b/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
index 2b54ec51dca0..ed33a51da252 100644
--- a/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
+++ b/MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c
@@ -720,7 +720,7 @@ Error:
 
 if (I2cBusContext != NULL) {
   Status = gBS->UninstallMultipleProtocolInterfaces (
-  ,
+  Controller,
   gEfiCallerIdGuid,
   I2cBusContext,
   NULL
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
index c6e401176a4b..3bde96bc9576 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
@@ -244,7 +244,7 @@ EnumerateNvmeDevNamespace (
   );
   if(EFI_ERROR(Status)) {
 gBS->UninstallMultipleProtocolInterfaces (
-   >DeviceHandle,
+   Device->DeviceHandle,
,
Device->DevicePath,
,
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
index b7832c6970ad..292dd25da817 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
@@ -313,7 +313,7 @@ RegisterPciDevice (
 );
 if (EFI_ERROR (Status)) {
   gBS->UninstallMultipleProtocolInterfaces (
- >Handle,
+ PciIoDevice->Handle,
  ,
  PciIoDevice->DevicePath,
  ,
@@ -351,7 +351,7 @@ RegisterPciDevice (
 );
 if (EFI_ERROR (Status)) {
   gBS->UninstallMultipleProtocolInterfaces (
- >Handle,
+ PciIoDevice->Handle,
  ,
  PciIoDevice->DevicePath,
  ,
@@ -360,7 +360,7 @@ RegisterPciDevice (
  );
   if (HasEfiImage) {
 gBS->UninstallMultipleProtocolInterfaces (
-   >Handle,
+   PciIoDevice->Handle,
,
>LoadFile2,
NULL
diff --git a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c 
b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
index 82db93a8b117..9fe8a482e067 100644
--- a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
+++ b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c
@@ -665,7 +665,7 @@ CreateSerialDevice (
 
   if (EFI_ERROR (Status)) {
 gBS->UninstallMultipleProtocolInterfaces (
-   >Handle,
+   SerialDevice->Handle,
, SerialDevice->DevicePath,
, >SerialIo,
NULL
diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c 
b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
index 62f18d1878bd..e2ae56c5058a 100644
--- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
+++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
@@ -475,7 +475,7 @@ InstallProtocolOnPartition (
 );
 if (EFI_ERROR (Status)) {
   gBS->UninstallMultipleProtocolInterfaces (
- >Handle,
+ Partition->Handle,
  ,
  Partition->DevicePath,
  ,
diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c 
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
index eaa0d70024bb..cc0de52de411 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
@@ -159,7 +159,7 @@ UsbCreateInterface (
 
   if (EFI_ERROR (Status)) {
 gBS->UninstallMultipleProtocolInterfaces (
-   >Handle,
+   UsbIf->Handle,
,
UsbIf->DevicePath,
,
diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c 
b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
index 8c27e18cdb87..0dcbc5da2cb8 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c
@@ -575,7 +575,7 @@ UsbMassInitMultiLun (
 if (EFI_ERROR (Status)) {
   DEBUG ((EFI_D_ERROR, "UsbMassInitMultiLun: 

[edk2-devel] [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration

[Laszlo Ersek]

EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
the notification handle to have type (VOID*). The notification handle has
nothing to do with the EFI_HANDLE type.

This change is a semantic fix; functionally, it's a no-op.

Cc: Andrew Fish 
Cc: Jordan Justen 
Cc: Ray Ni 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 EmulatorPkg/EmuGopDxe/GopInput.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/EmulatorPkg/EmuGopDxe/GopInput.c b/EmulatorPkg/EmuGopDxe/GopInput.c
index fdd0b4911555..2a23564a2173 100644
--- a/EmulatorPkg/EmuGopDxe/GopInput.c
+++ b/EmulatorPkg/EmuGopDxe/GopInput.c
@@ -517,7 +517,7 @@ EmuGopSimpleTextInExRegisterKeyNotify (
   IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL  *This,
   IN EFI_KEY_DATA   *KeyData,
   IN EFI_KEY_NOTIFY_FUNCTIONKeyNotificationFunction,
-  OUT EFI_HANDLE*NotifyHandle
+  OUT VOID  **NotifyHandle
   )
 {
   EFI_STATUS  Status;
@@ -600,7 +600,7 @@ EFI_STATUS
 EFIAPI
 EmuGopSimpleTextInExUnregisterKeyNotify (
   IN EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL  *This,
-  IN EFI_HANDLE NotificationHandle
+  IN VOID   *NotificationHandle
   )
 /*++
 
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47393): https://edk2.groups.io/g/devel/message/47393
Mute This Topic: https://groups.io/mt/34180205/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call

[Laszlo Ersek]

The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in
order to fetch the device path from it, and then turn the device path into
PATH routing information.

The HiiConstructConfigHdr() function is called from
VariableCleanupHiiExtractConfig(), which is only installed when "Type" is
"VarCleanupManually" in PlatformVarCleanup().

In that case, we create "Private->DriverHandle" as a new handle, and
install "mVarCleanupHiiVendorDevicePath" on it. Then we pass
"Private->DriverHandle" to HiiAddPackages(), which consumes the device
path for routing purposes.

It follows that the "DriverHandle" argument pased to
HiiConstructConfigHdr() should be the same driver handle, for matching
routing.

Currently we pass "Private->HiiHandle", which is clearly a typo, because
it is the return value of HiiAddPackages(), and stands for the published
HII package list.

Therefore this patch addresses an actual bug.

The typo has not been flagged by compilers because the UEFI spec
regrettably defines both EFI_HANDLE and EFI_HII_HANDLE as (VOID*).

Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Liming Gao 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c 
b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
index 968c044a316a..3875d614bb41 100644
--- a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
+++ b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
@@ -609,7 +609,11 @@ VariableCleanupHiiExtractConfig (
 // Allocate and fill a buffer large enough to hold the  template
 // followed by "=0=" followed by a 
Null-terminator.
 //
-ConfigRequestHdr = HiiConstructConfigHdr (, 
mVarStoreName, Private->HiiHandle);
+ConfigRequestHdr = HiiConstructConfigHdr (
+ ,
+ mVarStoreName,
+ Private->DriverHandle
+ );
 Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
 ConfigRequest = AllocateZeroPool (Size);
 ASSERT (ConfigRequest != NULL);
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47397): https://edk2.groups.io/g/devel/message/47397
Mute This Topic: https://groups.io/mt/34180211/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 16/35] MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly

[Laszlo Ersek]

The BootScriptInsert() and BootScriptLabel() functions take the in/out
parameter "Position" as (EFI_S3_BOOT_SCRIPT_POSITION*), and pass it to
S3BootScriptMoveLastOpcode() and S3BootScriptLabel(), respectively.

The callees take the in/out parameter "Position" as (VOID**). Add explicit
casts for clarity.

There is no change in functionality.

Cc: Dandan Bi 
Cc: Eric Dong 
Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Ray Ni 
Signed-off-by: Laszlo Ersek 
---

Notes:
lightly tested: multiple drivers in OVMF write S3 boot script fragments

 MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c| 4 ++--
 MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c 
b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
index e94d15772d78..cfa8ebbd2f5d 100644
--- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
@@ -810,7 +810,7 @@ BootScriptInsert (
   }
 
   if (!EFI_ERROR (Status)) {
-   Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, Position);
+   Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, (VOID **)Position);
   }
   return Status;
 }
@@ -851,7 +851,7 @@ BootScriptLabel (
   IN CONST CHAR8*Label
   )
 {
-  return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, Position, Label);
+  return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, (VOID 
**)Position, Label);
 }
 /**
   Compare two positions in the boot script table and return their relative 
position.
diff --git a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c 
b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
index 9637df4fb82a..fc6d29e48ba9 100644
--- a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
@@ -808,7 +808,7 @@ BootScriptInsert (
   }
 
   if (!EFI_ERROR (Status)) {
-   Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, Position);
+   Status = S3BootScriptMoveLastOpcode (BeforeOrAfter, (VOID **)Position);
   }
   return Status;
 }
@@ -849,7 +849,7 @@ BootScriptLabel (
   IN CONST CHAR8*Label
   )
 {
-  return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, Position, Label);
+  return S3BootScriptLabel (BeforeOrAfter, CreateIfNotFound, (VOID 
**)Position, Label);
 }
 /**
   Compare two positions in the boot script table and return their relative 
position.
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47403): https://edk2.groups.io/g/devel/message/47403
Mute This Topic: https://groups.io/mt/34180217/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 04/35] EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in BindingStop()

[Laszlo Ersek]

The 3rd and 4th parameters of the CloseProtocol() call are wrong.

Given that we're not dissociating a child controller from a parent
controller (= closing a BY_CHILD_CONTROLLER open), but closing a BY_DRIVER
open, the 4th parameter (ControllerHandle) should equal the 1st parameter
(Handle).

It's unclear why this code hasn't crashed before.

Note that the patch doesn't fix the underlying driver model bug. I don't
understand what the loop in MmcDriverBindingStop() attempts to do. Is this
driver supposed to be a bus driver? It seems to create new handles, and to
append device path nodes. But it doesn't set up proper parent/child
protocol opens, and it doesn't close them.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 EmbeddedPkg/Universal/MmcDxe/Mmc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/EmbeddedPkg/Universal/MmcDxe/Mmc.c 
b/EmbeddedPkg/Universal/MmcDxe/Mmc.c
index 2f9ec9c7e7c1..c6170880debd 100644
--- a/EmbeddedPkg/Universal/MmcDxe/Mmc.c
+++ b/EmbeddedPkg/Universal/MmcDxe/Mmc.c
@@ -329,8 +329,9 @@ MmcDriverBindingStop (
 // Close gEfiMmcHostProtocolGuid
 Status = gBS->CloseProtocol (
 Controller,
-,(VOID **) >MmcHost,
-This->DriverBindingHandle
+,
+This->DriverBindingHandle,
+Controller
 );
 
 // Remove MMC Host Instance from the pool
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47391): https://edk2.groups.io/g/devel/message/47391
Mute This Topic: https://groups.io/mt/34180203/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 11/35] MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bug

[Laszlo Ersek]

The PI spec (v1.7) correctly specifies "EFI_RUNTIME_EVENT_ENTRY.Event" in
natural language, but the field type in the structure definition itself is
wrong -- it should be EFI_EVENT, not (EFI_EVENT*).

This spec bug is likely unfixable for compatibility reasons, and so edk2
works it around already. We should clearly document the workaround.

Functionally, this patch is a no-op.

(I've also requested a non-normative (informative) clarification for the
PI spec: .)

Cc: Dandan Bi 
Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Liming Gao 
Signed-off-by: Laszlo Ersek 
---

Notes:
lightly tested, as these modules are part of the ArmVirt and/or OVMF
platforms

 MdeModulePkg/Core/Dxe/Event/Event.c|  8 
 MdeModulePkg/Core/RuntimeDxe/Runtime.c | 10 +-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Core/Dxe/Event/Event.c 
b/MdeModulePkg/Core/Dxe/Event/Event.c
index 21db38aaf037..c83c572c8f84 100644
--- a/MdeModulePkg/Core/Dxe/Event/Event.c
+++ b/MdeModulePkg/Core/Dxe/Event/Event.c
@@ -485,6 +485,14 @@ CoreCreateEventInternal (
 IEvent->RuntimeData.NotifyTpl  = NotifyTpl;
 IEvent->RuntimeData.NotifyFunction = NotifyFunction;
 IEvent->RuntimeData.NotifyContext  = (VOID *) NotifyContext;
+//
+// Work around the bug in the Platform Init specification (v1.7), reported
+// as Mantis#2017: "EFI_RUNTIME_EVENT_ENTRY.Event" should have type
+// EFI_EVENT, not (EFI_EVENT*). The PI spec documents the field correctly
+// as "The EFI_EVENT returned by CreateEvent()", but the type of the field
+// doesn't match the natural language description. Therefore we need an
+// explicit cast here.
+//
 IEvent->RuntimeData.Event  = (EFI_EVENT *) IEvent;
 InsertTailList (>EventHead, >RuntimeData.Link);
   }
diff --git a/MdeModulePkg/Core/RuntimeDxe/Runtime.c 
b/MdeModulePkg/Core/RuntimeDxe/Runtime.c
index c52b2b7ecf68..f7220a205d1e 100644
--- a/MdeModulePkg/Core/RuntimeDxe/Runtime.c
+++ b/MdeModulePkg/Core/RuntimeDxe/Runtime.c
@@ -285,8 +285,16 @@ RuntimeDriverSetVirtualAddressMap (
   for (Link = mRuntime.EventHead.ForwardLink; Link !=  
Link = Link->ForwardLink) {
 RuntimeEvent = BASE_CR (Link, EFI_RUNTIME_EVENT_ENTRY, Link);
 if ((RuntimeEvent->Type & EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE) == 
EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE) {
+  //
+  // Work around the bug in the Platform Init specification (v1.7),
+  // reported as Mantis#2017: "EFI_RUNTIME_EVENT_ENTRY.Event" should have
+  // type EFI_EVENT, not (EFI_EVENT*). The PI spec documents the field
+  // correctly as "The EFI_EVENT returned by CreateEvent()", but the type
+  // of the field doesn't match the natural language description. Therefore
+  // we need an explicit cast here.
+  //
   RuntimeEvent->NotifyFunction (
-  RuntimeEvent->Event,
+  (EFI_EVENT) RuntimeEvent->Event,
   RuntimeEvent->NotifyContext
   );
 }
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47398): https://edk2.groups.io/g/devel/message/47398
Mute This Topic: https://groups.io/mt/34180212/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast

[Laszlo Ersek]

"gTimerEvent" has type EFI_EVENT already, drop the superfluous cast.

Cc: Andrew Fish 
Cc: Jordan Justen 
Cc: Ray Ni 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c 
b/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
index 14cae4214c66..6fb5d8f3aaea 100644
--- a/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
+++ b/EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c
@@ -40,7 +40,7 @@ RegisterTimerArchProtocol (
 gTimerPeriod = MultU64x32 (gTimerPeriod, 100);
 
 if (gTimerEvent == NULL) {
-  Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, (VOID 
**));
+  Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, );
   ASSERT_EFI_ERROR (Status);
 }
   }
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47392): https://edk2.groups.io/g/devel/message/47392
Mute This Topic: https://groups.io/mt/34180204/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls

[Laszlo Ersek]

GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first
parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**).
(VOID**) converts silently to (VOID*), which is why the wrong cast is
masked.

Note that the *value* that is passed is alright -- therefore this patch
does not change behavior --, it's just semantically wrong to pass an
(EFI_HANDLE*) where an EFI_HANDLE is expected.

Cc: Dandan Bi 
Cc: Eric Dong 
Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Ray Ni 
Signed-off-by: Laszlo Ersek 
---

Notes:
lightly tested, as DxeCorePerformanceLib is linked into ArmVirtQemu's
DxeCore

 MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 12 
++--
 MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c |  8 

 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c 
b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
index 0d507c445210..f500e20b320b 100644
--- a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
+++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
@@ -998,7 +998,7 @@ InsertFpdtRecord (
   switch (PerfId) {
   case MODULE_START_ID:
   case MODULE_END_ID:
-GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
sizeof (ModuleName), );
+GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof 
(ModuleName), );
 StringPtr = ModuleName;
 //
 // Cache the offset of start image start record and use to update the 
start image end record if needed.
@@ -1031,7 +1031,7 @@ InsertFpdtRecord (
 
   case MODULE_LOADIMAGE_START_ID:
   case MODULE_LOADIMAGE_END_ID:
-GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
sizeof (ModuleName), );
+GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof 
(ModuleName), );
 StringPtr = ModuleName;
 if (PerfId == MODULE_LOADIMAGE_START_ID) {
   mLoadImageCount ++;
@@ -1071,7 +1071,7 @@ InsertFpdtRecord (
   case MODULE_DB_SUPPORT_END_ID:
   case MODULE_DB_STOP_START_ID:
   case MODULE_DB_STOP_END_ID:
-GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
sizeof (ModuleName), );
+GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof 
(ModuleName), );
 StringPtr = ModuleName;
 if (!PcdGetBool (PcdEdkiiFpdtStringRecordEnableOnly)) {
   FpdtRecordPtr.GuidQwordEvent->Header.Type   = 
FPDT_GUID_QWORD_EVENT_TYPE;
@@ -1085,7 +1085,7 @@ InsertFpdtRecord (
 break;
 
   case MODULE_DB_END_ID:
-GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
sizeof (ModuleName), );
+GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof 
(ModuleName), );
 StringPtr = ModuleName;
 if (!PcdGetBool (PcdEdkiiFpdtStringRecordEnableOnly)) {
   FpdtRecordPtr.GuidQwordStringEvent->Header.Type = 
FPDT_GUID_QWORD_STRING_EVENT_TYPE;
@@ -1131,7 +1131,7 @@ InsertFpdtRecord (
   case PERF_INMODULE_END_ID:
   case PERF_CROSSMODULE_START_ID:
   case PERF_CROSSMODULE_END_ID:
-GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
sizeof (ModuleName), );
+GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof 
(ModuleName), );
 if (String != NULL) {
   StringPtr = String;
 } else {
@@ -1153,7 +1153,7 @@ InsertFpdtRecord (
 
   default:
 if (Attribute != PerfEntry) {
-  GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
sizeof (ModuleName), );
+  GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, 
sizeof (ModuleName), );
   if (String != NULL) {
 StringPtr = String;
   } else {
diff --git a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c 
b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
index 5f07464c4ec7..b4f22c14ae73 100644
--- a/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
+++ b/MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c
@@ -587,7 +587,7 @@ InsertFpdtRecord (
   switch (PerfId) {
   case MODULE_START_ID:
   case MODULE_END_ID:
-GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
sizeof (ModuleName), );
+GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof 
(ModuleName), );
 StringPtr = ModuleName;
 //
 // Cache the offset of start image start record and use to update the 
start image end record if needed.
@@ -612,7 +612,7 @@ InsertFpdtRecord (
 
   case MODULE_LOADIMAGE_START_ID:
   case MODULE_LOADIMAGE_END_ID:
-GetModuleInfoFromHandle ((EFI_HANDLE *)CallerIdentifier, ModuleName, 
sizeof (ModuleName), );
+GetModuleInfoFromHandle ((EFI_HANDLE)CallerIdentifier, ModuleName, sizeof 
(ModuleName), );
 StringPtr = ModuleName;
 if (PerfId == MODULE_LOADIMAGE_START_ID) {
   mLoadImageCount++;
@@ -669,7 

[edk2-devel] [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration

[Laszlo Ersek]

EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
similarly to gBS->RegisterProtocolNotify(). We should pass the address of
an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
just happens to be specified as (VOID*), and has nothing to do with the
registration.

The same applies to gMmst->MmRegisterProtocolNotify().

"mFtwRegistration", "mFvRegistration", and "mFvbRegistration" are used for
nothing else.

This change is a no-op in practice; it's a semantic improvement.

Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Laszlo Ersek 
---

Notes:
lightly tested, as these modules (except LoadFileOnFv2) are part of the
ArmVirt and/or OVMF platforms

 MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c | 2 +-
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c | 2 +-
 MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 2 +-
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
index ae8f117905cd..de38ea028af1 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
@@ -47,7 +47,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 #include 
 #include "FaultTolerantWrite.h"
-EFI_EVENT mFvbRegistration = NULL;
+VOID  *mFvbRegistration = NULL;
 
 
 /**
diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
index e8e935a85b5b..9612b394865b 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
@@ -56,7 +56,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include "FaultTolerantWriteSmmCommon.h"
 #include 
 
-EFI_EVENT mFvbRegistration = NULL;
+VOID  *mFvbRegistration = NULL;
 EFI_FTW_DEVICE*mFtwDevice  = NULL;
 
 ///
diff --git a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c 
b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
index 4af2da05e145..43fa6ce12875 100644
--- a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
+++ b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
@@ -36,7 +36,7 @@ typedef struct {
 #define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_THIS(a) CR (a, 
LOAD_FILE_ON_FV2_PRIVATE_DATA, LoadFile, 
LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
 #define LOAD_FILE_ON_FV2_PRIVATE_DATA_FROM_LINK(a) CR (a, 
LOAD_FILE_ON_FV2_PRIVATE_DATA, Link, LOAD_FILE_ON_FV2_PRIVATE_DATA_SIGNATURE)
 
-EFI_EVENT  mFvRegistration;
+VOID   *mFvRegistration;
 LIST_ENTRY mPrivateDataList;
 
 /**
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
index 3d232bb36cb4..7d2b6c8e1fad 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
@@ -13,7 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 EFI_HANDLE  mHandle= NULL;
 EFI_EVENT   mVirtualAddressChangeEvent = NULL;
-EFI_EVENT   mFtwRegistration   = NULL;
+VOID*mFtwRegistration  = NULL;
 VOID***mVarCheckAddressPointer = NULL;
 UINTN   mVarCheckAddressPointerCount = 0;
 EDKII_VARIABLE_LOCK_PROTOCOLmVariableLock  = { 
VariableLockRequestToLock };
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47396): https://edk2.groups.io/g/devel/message/47396
Mute This Topic: https://groups.io/mt/34180210/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call

[Laszlo Ersek]

- The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is:

  IN OUT EFI_HANDLE *ChildHandle

- The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is:

  IN EFI_HANDLE ChildHandle

Fix the DestroyChild() call in TcpFastbootTransportStop().

This is an actual bugfix; I don't know why the current code doesn't crash.
Perhaps the function is never reached in practice? (It could be tied to an
error path.)

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c | 2 
+-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c 
b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
index 29f23a82c75f..34f9ba74e4db 100644
--- a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
+++ b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c
@@ -503,7 +503,7 @@ TcpFastbootTransportStop (
   Status = mTcpListener->Configure (mTcpListener, NULL);
   ASSERT_EFI_ERROR (Status);
 
-  Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, );
+  Status = mTcpServiceBinding->DestroyChild (mTcpServiceBinding, mTcpHandle);
 
   // Free any data the user didn't pick up
   Entry = (FASTBOOT_TCP_PACKET_LIST *) GetFirstNode ();
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47390): https://edk2.groups.io/g/devel/message/47390
Mute This Topic: https://groups.io/mt/34180202/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

[Laszlo Ersek]

Unfortunately, the UEFI / PI / Shell specs define a number of handle types
as pointers to VOID. This is a design mistake; those types should have
been pointers to incomplete union or structure types. Any
pointer-to-object type converts implicitly to, and from, pointer-to-void,
which prevents compilers from catching at least the following two types of
mistakes:

- mixing up one handle type with another (for example, EFI_HANDLE with
  EFI_EVENT),

- getting the depth of indirection wrong (for example, mixing up
  (EFI_HANDLE*) with EFI_HANDLE).

In order to root out such mistakes in the edk2 codebase, introduce
incomplete structure types with unique tags, such as:

  struct EFI_FOOBAR_OBJECT;
  typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;

replacing the spec mandated

  typedef VOID *EFI_FOOBAR_HANDLE;

(For some types, such as:

- EFI_ACPI_HANDLE,
- EFI_EVENT,
- EFI_FONT_HANDLE,
- EFI_HANDLE,
- EFI_HII_HANDLE,
- EFI_S3_BOOT_SCRIPT_POSITION,
- SHELL_FILE_HANDLE,

we connect the actual complete type (the internal, implementation-specific
type) to the typedef. Some of these also demonstrate how the code could
have looked in practice if the specs had used proper opaque (=incomplete)
types.)

Then, unleash "build" on the package DSC files. This causes the compiler
to warn about incompatible pointer assignments, and to stop the build.

The rest of the series addresses the resultant warnings. Each patch
belongs in one of two categories:

- semantic cleanups (no functional / behavioral changes),
- actual bugfixes.

As the subject line of this patch states, this specific patch is *not*
meant to be applied. It is just a "what if" patch that temporarily
isolates the standard types from each other, the way the specs should
have, so that the compiler have more information to work with.

Cc: Achin Gupta 
Cc: Andrew Fish 
Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Benjamin You 
Cc: Chao Zhang 
Cc: Dandan Bi 
Cc: David Woodhouse 
Cc: Eric Dong 
Cc: Guo Dong 
Cc: Hao A Wu 
Cc: Jaben Carsey 
Cc: Jian J Wang 
Cc: Jian Wang 
Cc: Jiaxin Wu 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Leif Lindholm 
Cc: Liming Gao 
Cc: Maurice Ma 
Cc: Michael D Kinney 
Cc: Ray Ni 
Cc: Siyuan Fu 
Cc: Supreeth Venkatesh 
Cc: Zhichao Gao 
Signed-off-by: Laszlo Ersek 
---
 MdePkg/Include/Pi/PiPeiCis.h | 6 --
 MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 ++-
 MdePkg/Include/Protocol/Bis.h| 3 ++-
 MdePkg/Include/Protocol/Eap.h| 3 ++-
 MdePkg/Include/Protocol/HiiFont.h| 3 +--
 MdePkg/Include/Protocol/MmMp.h   | 3 ++-
 MdePkg/Include/Protocol/S3SaveState.h| 2 +-
 MdePkg/Include/Protocol/Shell.h  | 3 ++-
 MdePkg/Include/Protocol/UserManager.h| 9 ++---
 MdePkg/Include/Uefi/UefiBaseType.h   | 6 --
 MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 ++-
 MdeModulePkg/Core/Dxe/Event/Event.h  | 2 +-
 MdeModulePkg/Core/Dxe/Hand/Handle.h  | 2 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h  | 2 +-
 MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h   | 2 +-
 MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h  | 2 +-
 StandaloneMmPkg/Core/StandaloneMmCore.h  | 2 +-
 17 files changed, 34 insertions(+), 22 deletions(-)

diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
index d9d4ed7d413a..3e9e82b62ae9 100644
--- a/MdePkg/Include/Pi/PiPeiCis.h
+++ b/MdePkg/Include/Pi/PiPeiCis.h
@@ -18,12 +18,14 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 ///
 /// The handles of EFI FV.
 ///
-typedef VOID*EFI_PEI_FV_HANDLE;
+struct EFI_PEI_FV_OBJECT;
+typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
 
 ///
 /// The handles of EFI FFS.
 ///
-typedef VOID*EFI_PEI_FILE_HANDLE;
+struct EFI_PEI_FILE_OBJECT;
+typedef struct EFI_PEI_FILE_OBJECT *EFI_PEI_FILE_HANDLE;
 
 ///
 /// Declare the forward reference data structure for EFI_PEI_SERVICE.
diff --git a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h 
b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
index a8e0b24c6c8d..8a1863f3e03d 100644
--- a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
+++ b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
@@ -16,7 +16,8 @@
   { 0xeb97088e, 0xcfdf, 0x49c6, { 0xbe, 0x4b, 0xd9, 0x6, 0xa5, 0xb2, 0xe, 0x86 
}}
 
 typedef UINT32  EFI_ACPI_TABLE_VERSION;
-typedef VOID*EFI_ACPI_HANDLE;
+struct EFI_ACPI_OBJECT;
+typedef struct EFI_ACPI_OBJECT *EFI_ACPI_HANDLE;
 
 #define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
 #define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
diff --git a/MdePkg/Include/Protocol/Bis.h b/MdePkg/Include/Protocol/Bis.h
index 2be6718f4bc2..8eca94512d03 100644
--- a/MdePkg/Include/Protocol/Bis.h
+++ b/MdePkg/Include/Protocol/Bis.h
@@ -37,7 +37,8 @@ typedef struct _EFI_BIS_PROTOCOL  EFI_BIS_PROTOCOL;
 //
 // Basic types
 //
-typedef VOID

[edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs

[Laszlo Ersek]

Repository: https://github.com/lersek/edk2.git
Branch: voidptr

The UEFI / PI / Shell specifications define a number of standard types
as pointers to VOID. This is arguably a design mistake; those types
should have been pointers to distinct incomplete union or structure
types. Here's why:

Roughly paraphrasing the constraints from ISO C99 "6.5.16.1 Simple
assignment" and "6.5.4 Cast operators", any pointer-to-object type
converts implicitly to, and from, pointer-to-void, provided const /
volatile qualifications are not relaxed. Such implicit conversions
prevent compilers from catching at least the following two kinds of
coding mistakes:

- mixing up one type with another (for example, EFI_HANDLE with
  EFI_EVENT),

- getting the depth of indirection wrong (for example, mixing up
  (EFI_HANDLE*) with EFI_HANDLE).

This series first separates these standard types from each other, in the
first patch, which is *not* being proposed for merging. This unmasks a
number of warts (semantic issues, or actual bugs) in the source code, in
the form of build breakages. The rest of the series works through those
breakages, cleaning and fixing the code.

Every DSC file in the edk2 tree was built for at least one of the NOOPT,
DEBUG, RELEASE targets (NOOPT being preferred), with the GCC48 toolchain
(for IA32 / X64) and the GCC5 toolchain (for ARM / AARCH64). Of course,
the build arches were restricted to the SUPPORTED_ARCHITECTURES stated
in the individual DSC files.

There were two exceptions to the above rule: DynamicTablesPkg was only
build-tested with AARCH64 (despite its SUPPORTED_ARCHITECTURES), given
that 32-bit ARM has no ACPI bindings. StandaloneMmPkg too was only
build-tested with AARCH64; it doesn't actually support IA32/X64 yet.

Regarding boot & runtime tests, ArmVirtQemu on AARCH64 was tested with
booting to the OS (RHEL7). Furthermore, I exercised OVMF with my usual
boot and S3 tests, covering IA32, IA32X64, and X64. Finally, some other
individual tests (noted per patch) were done with OVMF.

Cc: Achin Gupta 
Cc: Andrew Fish 
Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Benjamin You 
Cc: Chao Zhang 
Cc: Dandan Bi 
Cc: David Woodhouse 
Cc: Eric Dong 
Cc: Guo Dong 
Cc: Hao A Wu 
Cc: Jaben Carsey 
Cc: Jian J Wang 
Cc: Jian Wang 
Cc: Jiaxin Wu 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Leif Lindholm 
Cc: Liming Gao 
Cc: Maurice Ma 
Cc: Michael D Kinney 
Cc: Ray Ni 
Cc: Siyuan Fu 
Cc: Supreeth Venkatesh 
Cc: Zhichao Gao 

Thanks
Laszlo

Laszlo Ersek (35):
  DO NOT APPLY: edk2: turn standard handle types into pointers to
non-VOID
  EmbeddedPkg: add missing EFIAPI calling convention specifiers
  EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call
  EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in
BindingStop()
  EmulatorPkg/DxeTimerLib: drop superfluous cast
  EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration
  MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls
  MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of
EFI_HII_HANDLE
  MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
  MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call
  MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec
bug
  MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify
registration
  MdeModulePkg: PEI Core: clean up "AprioriFile" handling in
FindFileEx()
  MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls
  MdeModulePkg/PiSmmCore: make type punning consistent
  MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly
  MdePkg/DxeServicesLib: remove bogus cast
  NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
  NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces
calls
  NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call
  NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list
  OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call
  OvmfPkg/VirtioNetDxe: fix SignalEvent() call
  OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal
functions
  OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
  SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
  SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
  ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo
  ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE
  ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
  ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
  ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug
  StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
  UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT
  UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls

 EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.c  
|  2 +-
 

[edk2-devel] [PATCH 02/35] EmbeddedPkg: add missing EFIAPI calling convention specifiers

[Laszlo Ersek]

This patch is unrelated to the rest of the series; it just makes sure that
"EmbeddedPkg/EmbeddedPkg.dsc" builds for all platforms advertised in
SUPPORTED_ARCHITECTURES (in particular, X64).

No functional changes.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Laszlo Ersek 
---

Notes:
build-tested only

 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h| 32 
+++-
 EmbeddedPkg/GdbStub/GdbStubInternal.h   |  9 ++
 EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c |  1 +
 EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c |  1 +
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c |  8 +
 EmbeddedPkg/MetronomeDxe/Metronome.c|  1 +
 6 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
index e3db0821c38f..20636574c271 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
@@ -205,7 +205,9 @@ SataSiI3132DriverBindingStop (
   IN EFI_HANDLE  *ChildHandleBuffer
   );
 
-EFI_STATUS SiI3132AtaPassThruCommand (
+EFI_STATUS
+EFIAPI
+SiI3132AtaPassThruCommand (
   IN SATA_SI3132_INSTANCE *pSataSiI3132Instance,
   IN SATA_SI3132_PORT *pSataPort,
   IN UINT16   PortMultiplierPort,
@@ -216,7 +218,9 @@ EFI_STATUS SiI3132AtaPassThruCommand (
 /**
  * EFI ATA Pass Thru Protocol
  */
-EFI_STATUS SiI3132AtaPassThru (
+EFI_STATUS
+EFIAPI
+SiI3132AtaPassThru (
   IN EFI_ATA_PASS_THRU_PROTOCOL   *This,
   IN UINT16   Port,
   IN UINT16   PortMultiplierPort,
@@ -224,37 +228,49 @@ EFI_STATUS SiI3132AtaPassThru (
   IN EFI_EVENTEvent OPTIONAL
   );
 
-EFI_STATUS SiI3132GetNextPort (
+EFI_STATUS
+EFIAPI
+SiI3132GetNextPort (
   IN EFI_ATA_PASS_THRU_PROTOCOL *This,
   IN OUT UINT16 *Port
   );
 
-EFI_STATUS SiI3132GetNextDevice (
+EFI_STATUS
+EFIAPI
+SiI3132GetNextDevice (
   IN EFI_ATA_PASS_THRU_PROTOCOL *This,
   IN UINT16 Port,
   IN OUT UINT16 *PortMultiplierPort
   );
 
-EFI_STATUS SiI3132BuildDevicePath (
+EFI_STATUS
+EFIAPI
+SiI3132BuildDevicePath (
   IN EFI_ATA_PASS_THRU_PROTOCOL *This,
   IN UINT16 Port,
   IN UINT16 PortMultiplierPort,
   IN OUT EFI_DEVICE_PATH_PROTOCOL   **DevicePath
   );
 
-EFI_STATUS SiI3132GetDevice (
+EFI_STATUS
+EFIAPI
+SiI3132GetDevice (
   IN  EFI_ATA_PASS_THRU_PROTOCOL *This,
   IN  EFI_DEVICE_PATH_PROTOCOL   *DevicePath,
   OUT UINT16 *Port,
   OUT UINT16 *PortMultiplierPort
   );
 
-EFI_STATUS SiI3132ResetPort (
+EFI_STATUS
+EFIAPI
+SiI3132ResetPort (
   IN EFI_ATA_PASS_THRU_PROTOCOL *This,
   IN UINT16 Port
   );
 
-EFI_STATUS SiI3132ResetDevice (
+EFI_STATUS
+EFIAPI
+SiI3132ResetDevice (
   IN EFI_ATA_PASS_THRU_PROTOCOL *This,
   IN UINT16 Port,
   IN UINT16 PortMultiplierPort
diff --git a/EmbeddedPkg/GdbStub/GdbStubInternal.h 
b/EmbeddedPkg/GdbStub/GdbStubInternal.h
index b8346d7a545f..b08159302cfa 100644
--- a/EmbeddedPkg/GdbStub/GdbStubInternal.h
+++ b/EmbeddedPkg/GdbStub/GdbStubInternal.h
@@ -323,6 +323,7 @@ SendError (
  Send 'OK' when the function is done executing successfully.
  **/
 VOID
+EFIAPI
 SendSuccess (
   VOID
   );
@@ -332,6 +333,7 @@ SendSuccess (
  Send empty packet to specify that particular command/functionality is not 
supported.
  **/
 VOID
+EFIAPI
 SendNotSupported (
   VOID
   );
@@ -353,6 +355,7 @@ ReadNthRegister (
  @param SystemContext   Register content at time of the exception
  **/
 VOID
+EFIAPI
 ReadGeneralRegisters (
   INEFI_SYSTEM_CONTEXT  SystemContext
   );
@@ -364,6 +367,7 @@ ReadGeneralRegisters (
  @param InBufferThis is the input buffer received from gdb 
server
  **/
 VOID
+EFIAPI
 WriteNthRegister (
   INEFI_SYSTEM_CONTEXT  SystemContext,
   INCHAR8   *InBuffer
@@ -377,6 +381,7 @@ WriteNthRegister (
  **/
 
 VOID
+EFIAPI
 WriteGeneralRegisters (
   INEFI_SYSTEM_CONTEXT  SystemContext,
   INCHAR8   *InBuffer
@@ -391,6 +396,7 @@ WriteGeneralRegisters (
  @param  *PacketData  Pointer to Payload data for the packet
  **/
 VOID
+EFIAPI
 ReadFromMemory (
   IN  CHAR8  *PacketData
   );
@@ -404,6 +410,7 @@ ReadFromMemory (
  @param   PacketData Pointer to Payload data for the packet
  **/
 VOID
+EFIAPI
 WriteToMemory (
   IN CHAR8 *PacketData
   );
@@ -418,6 +425,7 @@ WriteToMemory (
  **/
 
 VOID
+EFIAPI
 ContinueAtAddress (
   IN  EFI_SYSTEM_CONTEXT   SystemContext,
   IN  CHAR8*PacketData
@@ -432,6 +440,7 @@ ContinueAtAddress (
  @param PacketData  Pointer to Payload data for the packet
  **/
 VOID
+EFIAPI
 SingleStep (
   IN 

Re: [edk2-devel] [PATCH 0/2] q35: mch: allow to lock down 128K RAM at default SMBASE address

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190917130708.10281-1-imamm...@redhat.com/



Hi,

This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

./tests/docker/docker.py --engine auto build qemu:fedora 
tests/docker/dockerfiles/fedora.docker   --add-current-user  
Image is up to date.
  LD  docker-test-de...@fedora.mo
cc: fatal error: no input files
compilation terminated.
make: *** [docker-test-de...@fedora.mo] Error 4



The full log is available at
http://patchew.org/logs/20190917130708.10281-1-imamm...@redhat.com/testing.asan/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47386): https://edk2.groups.io/g/devel/message/47386
Mute This Topic: https://groups.io/mt/34175725/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/2] q35: mch: allow to lock down 128K RAM at default SMBASE address

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190917130708.10281-1-imamm...@redhat.com/



Hi,

This series failed the docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#! /bin/bash
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===

./tests/docker/docker.py --engine auto build qemu:fedora 
tests/docker/dockerfiles/fedora.docker   --add-current-user  
Image is up to date.
  LD  docker-test-mi...@fedora.mo
cc: fatal error: no input files
compilation terminated.
make: *** [docker-test-mi...@fedora.mo] Error 4



The full log is available at
http://patchew.org/logs/20190917130708.10281-1-imamm...@redhat.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47385): https://edk2.groups.io/g/devel/message/47385
Mute This Topic: https://groups.io/mt/34175725/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-CCSS 0/3] Coding Standards: add rule for documenting spurious variable assignments

[Michael D Kinney]

Series Reviewed-by: Michael D Kinney 

I also agree that the macros would be cleaner, easy to review, and
and fewer lines of code without the comment block.  If I objected
previously, then I have also changed my mind.  I agree we can go
ahead and push the series in its current form and continue the
discussion on the macros.

Mike

> -Original Message-
> From: Laszlo Ersek 
> Sent: Wednesday, September 11, 2019 10:51 AM
> To: devel@edk2.groups.io; ryszard.k...@linux.intel.com;
> leif.lindh...@linaro.org
> Cc: Andrew Fish ; Kinney, Michael D
> ; Rebecca Cran
> ; Philippe Mathieu-Daude
> 
> Subject: Re: [edk2-devel] [PATCH edk2-CCSS 0/3] Coding
> Standards: add rule for documenting spurious variable
> assignments
> 
> On 09/10/19 17:44, Ryszard Knop wrote:
> > On Tue, 2019-09-10 at 16:33 +0100, Leif Lindholm
> wrote:
> >> On Mon, Sep 09, 2019 at 02:35:15PM +0200, Laszlo
> Ersek wrote:
> >>> On 09/06/19 14:26, Leif Lindholm wrote:
>  On Thu, Sep 05, 2019 at 08:38:17PM +0200, Laszlo
> Ersek wrote:
> > Repo:
> > https://github.com/lersek/edk2-
> CCodingStandardsSpecification.git
> > Branch: spurious_assign_bz_607
> >
> > HTML-rendered views of the modified pages:
> > -
> > https://lersek.gitbooks.io/laszlo-s-fork-of-the-
> edk-ii-c-coding-st
> > andards-sp/content/v/spurious_assign_bz_607
> > -
> > https://lersek.gitbooks.io/laszlo-s-fork-of-the-
> edk-ii-c-coding-st
> > andards-
> sp/content/v/spurious_assign_bz_607/6_documenting_softw
> are
> > /62_comments.html
> > -
> > https://lersek.gitbooks.io/laszlo-s-fork-of-the-
> edk-ii-c-coding-st
> > andards-
> sp/content/v/spurious_assign_bz_607/6_documenting_softw
> are
> > /64_what_you_must_comment.html
> >
> > The first two patches are cleanups for things
> that popped up in
> > the discussion in <
> >
> https://bugzilla.tianocore.org/show_bug.cgi?id=607>;.
> >
> > The third patch is the one fixing the BZ.
> 
>  For 1 and 2,
>  Reviewed-by: Leif Lindholm
> 
> 
>  For 3, I see no issue with it, but I do feel
> tempted by Phil's
>  input of using explicit macros (obviating the need
> for specific
>  comment).
>  I seem to recall back in the mists of time we
> considered something
>  similar.
> >>>
> >>> Yes, I remember similarly.
> >>>
>  Vaguely. Am I misremembering, or did we disount
> that option?
> >>>
> >>> Phil's current recommendation is what I would have
> preferred back
> >>> then, but it was rejected, as far as I recall. If I
> remember
> >>> correctly, most developers preferred naked NULLs /
> zeroes. I
> >>> insisted on the comment as a fallback / compromise,
> so that we'd
> >>> have at least some visual cue.
> >>
> >> I'm not even sure I wasn't one of the people opposed
> to it then.
> >> But if I was, I would appear to have changed my
> mind.
> >>
> >>> I could be mis-remembering; we can restart that
> discussion if now
> >>> the macros are preferred.
> >>
> >> I would be all for that.
> >
> > If my 2 cents are worth anything, that'd be preferred
> by some folks in
> > my team too. Although something shorter like
> "UNINITIALIZED_INT/PTR"
> > would be nicer, IMO. Both work of course.
> 
> Thanks everyone for the feedback thus far on this
> series. It looks like I could go ahead and push the
> patches, minimally for bringing the CCSS in closer sync
> with reality -- and then we could improve
> incrementally, for example with macros.
> 
> But, before I push the set, I'd really like hear Mike's
> opinion too -- I vaguely recall he was active in the
> original discussion. I wouldn't like to back out the
> patches in case Mike rejected them retroactively.
> 
> I believe Mike will have a bit of an email backlog to
> process ;) so I'll wait some more in this thread.
> 
> Thanks!
> Laszlo
> 
> >> However, I see no reason why we shouldn't document
> the current
> >> process in the meantime, so for 3/3 also:
> >> Reviewed-by: Leif Lindholm
> 
> >>
> >> Best Regards,
> >>
> >> Leif
> >>
> >>> Thanks,
> >>> Laszlo
> >>>
>  Regards,
> 
>  Leif
> 
> > Thanks,
> > Laszlo
> >
> > Cc: Andrew Fish 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > Cc: Rebecca Cran 
> >
> > Laszlo Ersek (3):
> >   comments: remove "Horror Vacui" rule
> >   comments: restrict and clarify applicability of
> "/*" comments
> >   must comment: add rule for documenting spurious
> variable
> > assignments
> >
> >  6_documenting_software/62_comments.md
> | 20 +-
> > 
> >
> 6_documenting_software/64_what_you_must_comment.md | 39
> > 
> >  README.md
> |  1 +
> >  3 files changed, 42 insertions(+), 18
> deletions(-)
> >
> > --
> > 2.19.1.3.g30247aa5d201
> >
> >>
> >>
> >>
> >
> >
> > 
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47384): 

Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs for Admin commands

[Tyler J Erickson via Groups.Io]

Hi Hao,

Sorry for the late reply.
I tested and can confirm that if the NSID of the command and the provided
NamespaceID as an input match, the commands do go through on the EDK2
driver. This is not the case with a driver built into a motherboard that I
have here, as it only accepts values for the current NSID and nothing else.
This is ok since I can load the EDK2 driver in place instead.

Since this is unclear in the documentation for the passthru function, can
we make a documentation change instead?

Thanks,
-Tyler


On Wed, Sep 4, 2019 at 8:07 PM Wu, Hao A  wrote:

> Hello Tyler,
>
>
>
> Some inline comments below.
>
>
>
> Best Regards,
>
> Hao Wu
>
>
>
> *From:* Tyler J Erickson [mailto:tyler.j.erick...@seagate.com]
> *Sent:* Wednesday, September 04, 2019 11:07 PM
> *To:* Wu, Hao A
> *Cc:* devel@edk2.groups.io; Ni, Ray
> *Subject:* Re: [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other
> NSIDs for Admin commands
>
>
>
> Hi Hao,
>
>
>
> I tried making both the NamespaceID and NSID values the same when calling
> the passthru function for these admin commands and it didn't work. I
> think that is due to another place in the passthru code filtering the
> NamespaceId input values on line 517-520.
>
> The NamespaceId parameter is being checked to make sure it isn't greater
> than the number of supported namespaces by the controller and it makes sure
> it isn't set to (UINT32)-1 (All F's).
>
>
>
>
>
> [Hao]: I think the check on line 517-520 blocks ‘NamespaceId’ with value
> greater than the number of namespace. But it allows the value to be
> MAX_UINT32, which means the command takes effect on all namespaces.
>
>
>
>
>
> I think this is correct since the NamespaceId input is what is discovered
> when calling the EFI_NVM_EXPRESS_PASS_THRU_GET_NEXT_NAMESPACE function.
> This is what I used to get the available namespaces available in the system.
>
>
>
> In my case I'm sending some commands in my application with the NSID set
> to UINT32_MAX in order to request controller wide SMART/Health log data
> among other things. There are some commands where setting the NSID to
> another value may also be useful. For example, DST can use the NSID in the
> command to change between testing only the controller (0), testing all
> namespaces (UINT32_MAX), and a specific namespace.
>
>
>
>
>
> [Hao]: Yes. Just as you said, commands like DST or Get Log Page will have
> different target when different Namespace values are provided.
>
> I think for your case, you can:
>
> 1.   Set both the 'NamespaceId' parameter and 'Nsid' field to 0 if
> the target is the controller;
>
> 2.   Set both of them MAX_UINT32 if the target is all the namespaces;
>
> 3.   Set both of them to a corresponding ID if the target is a
> specific namespace.
>
>
>
> As you can see from the current implementation of NvmExpressPassThru()
> function, the 'NamespaceId' parameter does not affect the construct of
> the submission queue item.
>
> The 'NamespaceId' parameter only serves as a valid check for the 'Nsid'
> field in the EFI_NVM_EXPRESS_COMMAND structure.
>
>
>
>
>
> The modification I made was done where the passthru command's NSID was
> actually being checked, which seemed like the best place to add this
> exception for admin commands.
>
>
> -Tyler
>
>
>
>
>
> On Tue, Sep 3, 2019 at 9:39 PM Wu, Hao A  wrote:
>
> > -Original Message-
> > From: Wu, Hao A
> > Sent: Wednesday, September 04, 2019 11:39 AM
> > To: devel@edk2.groups.io; Tyler Erickson
> > Cc: Wu, Hao A; Ni, Ray
> > Subject: [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs
> > for Admin commands
> >
> > Repost the mail to the list.
> >
> > Best Regards,
> > Hao Wu
> >
> > -Original Message-
> > From: Tyler Erickson [mailto:tyler.j.erick...@seagate.com]
> > Sent: Tuesday, September 03, 2019 9:55 PM
> > To: edk2-de...@lists.01.org
> > Cc: Wu, Hao A; Ni, Ray
> > Subject: [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs
> > for Admin commands
> >
> > Cc: Hao A Wu 
> > Cc: Ray Ni 
> > Signed-off-by: Tyler Erickson 
> > ---
> >  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
> > b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
> > index 8e721379466a..78a3c663ded4 100644
> > --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
> > +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
> > @@ -561,7 +561,7 @@ NvmExpressPassThru (
> >Sq  = Private->SqBuffer[QueueId] + Private->SqTdbl[QueueId].Sqt;
> >Cq  = Private->CqBuffer[QueueId] + Private->CqHdbl[QueueId].Cqh;
> >
> > -  if (Packet->NvmeCmd->Nsid != NamespaceId) {
> > +  if (Packet->QueueType != NVME_ADMIN_QUEUE && Packet->NvmeCmd-
> > >Nsid != NamespaceId) {
>
>
> Hello,
>
> Per my understanding to the codes, I think the:
>
> * Input parameter 'NamespaceId' for the PassThru() service
> * The 'Nsid' field of the 

Re: [edk2-devel] [External] Re: [PATCH v1 1/1] Drivers/DisplayLink/DisplayLinkPkg DisplayLinkGop

[Andy Hayes]

That's right, the only (current) request was index 0 - that is why it didn't 
show up. It was a refactoring error.

It was picked up when we ported some of the changes back into our "closed 
source" version of the driver and the unit tests failed.

Thanks for pushing this.

From: Leif Lindholm 
Sent: 17 September 2019 16:28
To: Andy Hayes 
Cc: devel@edk2.groups.io; Ard Biesheuvel 
Subject: [External] Re: [PATCH v1 1/1] Drivers/DisplayLink/DisplayLinkPkg 
DisplayLinkGop

On Wed, Sep 11, 2019 at 07:42:03AM +, Andy Hayes wrote:
> Corrected initialisation of one of data structures used to transmit USB
> control messages. Mistake had no practical effects but fixing to be on safe
> side.

So, was the only request used index 0? Or why didn't this cause an
issue? Nevertheless, a clear fix.

> Cc: Leif Lindholm mailto:leif.lindh...@linaro.org>>
> Cc: Ard Biesheuvel 
> mailto:ard.biesheu...@linaro.org>>
> Signed-off-by: Andy Hayes 
> mailto:andy.ha...@displaylink.com>>

Reviewed-by: Leif Lindholm 
mailto:leif.lindh...@linaro.org>>
Pushed as 958aaf600728.

/
Leif

> ---
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c 
> b/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> index 252293da39d4..9871ab0378ce 100644
> --- a/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> +++ b/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> @@ -107,7 +107,7 @@ DlUsbSendControlWriteMessage (
> UINT32 UsbStatus;
> EFI_USB_DEVICE_REQUEST UsbRequest;
>
> - ZeroMem (, sizeof (Request));
> + ZeroMem (, sizeof (UsbRequest));
> UsbRequest.RequestType = USB_REQ_TYPE_VENDOR | USB_TARGET_INTERFACE;
> UsbRequest.Index = Device->InterfaceDescriptor.InterfaceNumber;
> UsbRequest.Request = Request;
> --
> 1.8.3.1
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47382): https://edk2.groups.io/g/devel/message/47382
Mute This Topic: https://groups.io/mt/34177235/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] Drivers/DisplayLink/DisplayLinkPkg DisplayLinkGop

[Leif Lindholm]

On Wed, Sep 11, 2019 at 07:42:03AM +, Andy Hayes wrote:
> Corrected initialisation of one of data structures used to transmit USB
> control messages. Mistake had no practical effects but fixing to be on safe
> side.

So, was the only request used index 0? Or why didn't this cause an
issue? Nevertheless, a clear fix.

> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Signed-off-by: Andy Hayes 

Reviewed-by: Leif Lindholm 
Pushed as 958aaf600728.

/
Leif

> ---
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c 
> b/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> index 252293da39d4..9871ab0378ce 100644
> --- a/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> +++ b/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> @@ -107,7 +107,7 @@ DlUsbSendControlWriteMessage (
>UINT32 UsbStatus;
>EFI_USB_DEVICE_REQUEST UsbRequest;
>  
> -  ZeroMem (, sizeof (Request));
> +  ZeroMem (, sizeof (UsbRequest));
>UsbRequest.RequestType = USB_REQ_TYPE_VENDOR | USB_TARGET_INTERFACE;
>UsbRequest.Index = Device->InterfaceDescriptor.InterfaceNumber;
>UsbRequest.Request = Request;
> -- 
> 1.8.3.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47381): https://edk2.groups.io/g/devel/message/47381
Mute This Topic: https://groups.io/mt/34092678/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Upcoming Event: TianoCore Design / Bug Triage - EMEA - Wed, 09/18/2019 8:00am-9:00am #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Design / Bug Triage - EMEA

*When:* Wednesday, 18 September 2019, 8:00am to 9:00am, (GMT-07:00) America/Los 
Angeles

*Where:* https://zoom.us/j/695893389

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=503242 )

*Organizer:* Stephano Cetola stephano.cet...@linux.intel.com ( 
stephano.cet...@linux.intel.com?subject=Re:%20Event:%20TianoCore%20Design%20%2F%20Bug%20Triage%20-%20EMEA
 )

*Description:*

Join Zoom Meeting

https://zoom.us/j/695893389

One tap mobile

+17207072699,,695893389# US

+16465588656,,695893389# US (New York)

Dial by your location

+1 720 707 2699 US

+1 646 558 8656 US (New York)

Meeting ID: 695 893 389

Find your local number: https://zoom.us/u/abOtdJckxL

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47380): https://edk2.groups.io/g/devel/message/47380
Mute This Topic: https://groups.io/mt/34176853/21656
Mute #cal-reminder: https://groups.io/mk?hashtag=cal-reminder=3846945
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/2] *** Add VS2019 Support ***

[Liming Gao]

Ching:
  The change is good. With this change, have you verified VS2017 tool chain? 
  I want to make sure there is no impact on VS2017. 

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Cheng, 
> Ching JenX
> Sent: Tuesday, September 17, 2019 11:23 AM
> To: devel@edk2.groups.io; Cheng, Ching JenX 
> Subject: Re: [edk2-devel] [PATCH v2 0/2] *** Add VS2019 Support ***
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2182
> 
> In order to support VS2019 on EDK2, the following patches was modified def 
> and batch files 1. Add VS2019 x86/64 definitions on
> tools_def.template 2. Add VS2019 support on toolsetup batches, and add 
> version check with command vswhere
>  Because VS2019 and VS2017 using the same vswhere to get the 
> InstallationPath
> 
> v2: In 01/02, add ARM/AARCH64/EBC Definitions, Combine VS2017_HOST and 
> VS2019_HOST to VS_HOST
> 
> Ching JenX Cheng (2):
>   Add VS2019 Toolchain def
>   Add VS2019 Support on ToolSetup Batches
> 
>  BaseTools/Conf/tools_def.template | 220
> ++
> +++---
>  BaseTools/get_vsvars.bat  |  37 ++---
>  BaseTools/set_vsprefix_envs.bat   |  70 
> +-
>  BaseTools/toolsetup.bat   |  16 +---
>  edksetup.bat  |   6 --
>  5 files changed, 313 insertions(+), 36 deletions(-)
> 
> --
> 2.21.0.windows.1
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47379): https://edk2.groups.io/g/devel/message/47379
Mute This Topic: https://groups.io/mt/34172665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdePkg:Include: Update SmBios header file

[Liming Gao]

Abner:
  I add my comments. 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif 
> Lindholm
> Sent: Tuesday, September 17, 2019 9:34 PM
> To: Abner Chang 
> Cc: devel@edk2.groups.io; Kinney, Michael D ; 
> Gao, Liming ; Gilbert Chen
> 
> Subject: Re: [edk2-devel] [PATCH] MdePkg:Include: Update SmBios header file
> 
> On Tue, Sep 17, 2019 at 02:24:30PM +0800, Abner Chang wrote:
> > Update SmBios header file to conform with SMBIOS v3.3.0.
> 
> Ah, I note SMBIOS 3.3 has not yet been released - so this can not be
> merged in edk2 master at this point. I did not realise this when I
> requested you send the patch.

Please submit BZ https://bugzilla.tianocore.org/ for this update. This is a new 
feature. 
> 
> However, you can carry this in your edk2-staging branch, and once the
> specification gets released we can take it into edk2.
> 
> (After code review, a couple of minor comments below.)
> 
> > The major update is to add definitions of SMBIOS Type 44h record.
> >
> > Signed-off-by: Abner Chang 
> >
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Leif Lindholm 
> > Cc: Gilbert Chen 
> >
> > ---
> >  MdePkg/Include/IndustryStandard/SmBios.h | 74 
> > +++-
> >  1 file changed, 72 insertions(+), 2 deletions(-)
> >
> > diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
> > b/MdePkg/Include/IndustryStandard/SmBios.h
> > index f3b6f18..ebf0ceb 100644
> > --- a/MdePkg/Include/IndustryStandard/SmBios.h
> > +++ b/MdePkg/Include/IndustryStandard/SmBios.h
> > @@ -3,6 +3,7 @@
> >
> >  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> >  (C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP
> > +(C) Copyright 2015 - 2019 Hewlett Packard Enterprise Development LP
> >  SPDX-License-Identifier: BSD-2-Clause-Patent

File header should be updated.

  Industry Standard Definitions of SMBIOS Table Specification v3.2.0.
==>
  Industry Standard Definitions of SMBIOS Table Specification v3.3.0.

And, please refer to https://bugzilla.tianocore.org/show_bug.cgi?id=1099 for 
3.2 update,
prepare all changes for SmBios 3.3 update.

Thanks
Liming
> >
> >  **/
> > @@ -46,7 +47,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #define SMBIOS_3_0_TABLE_MAX_LENGTH 0x
> >
> >  //
> > -// SMBIOS type macros which is according to SMBIOS 2.7 specification.
> > +// SMBIOS type macros which is according to SMBIOS 3.3.0 specification.
> >  //
> >  #define SMBIOS_TYPE_BIOS_INFORMATION 0
> >  #define SMBIOS_TYPE_SYSTEM_INFORMATION   1
> > @@ -92,6 +93,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #define SMBIOS_TYPE_ONBOARD_DEVICES_EXTENDED_INFORMATION 41
> >  #define SMBIOS_TYPE_MANAGEMENT_CONTROLLER_HOST_INTERFACE 42
> >  #define SMBIOS_TYPE_TPM_DEVICE   43
> > +#define SMBIOS_TYPE_PROCESSOR_ADDITIONAL_INFORMATION 44
> >
> >  ///
> >  /// Inactive type is added from SMBIOS 2.2. Reference SMBIOS 2.6, chapter 
> > 3.3.43.
> > @@ -727,7 +729,10 @@ typedef enum {
> >ProcessorFamilyMII   = 0x012E,
> >ProcessorFamilyWinChip   = 0x0140,
> >ProcessorFamilyDSP   = 0x015E,
> > -  ProcessorFamilyVideoProcessor= 0x01F4
> > +  ProcessorFamilyVideoProcessor= 0x01F4,
> > +  ProcessorFamilyRiscvRV32 = 0x0200,  ///< SMBIOS spec 3.3.0 
> > added
> 
> Please drop the "///< SMBIOS spec 3.3.0 added" comment. Here and below.
> 
> > +  ProcessorFamilyRiscVRV64 = 0x0201,  ///< SMBIOS spec 3.3.0 
> > added
> > +  ProcessorFamilyRiscVRV128= 0x0202   ///< SMBIOS spec 3.3.0 
> > added
> 
> No further comments from me (MdePkg maintainers may have some).
> 
> /
> Leif
> 
> >  } PROCESSOR_FAMILY2_DATA;
> >
> >  ///
> > @@ -857,6 +862,19 @@ typedef struct {
> >  } PROCESSOR_FEATURE_FLAGS;
> >
> >  typedef struct {
> > +  UINT32  ProcessorReserved1 :1;
> > +  UINT32  ProcessorUnknown   :1;
> > +  UINT32  Processor64BitCapble   :1;
> > +  UINT32  ProcessorMultiCore :1;
> > +  UINT32  ProcessorHardwareThread:1;
> > +  UINT32  ProcessorExecuteProtection :1;
> > +  UINT32  ProcessorEnhancedVirtulization :1;
> > +  UINT32  ProcessorPowerPerformanceCtrl  :1;
> > +  UINT32  Processor128bitCapble  :1;
> > +  UINT32  ProcessorReserved2 :7;
> > +} PROCESSOR_CHARACTERISTIC_FLAGS;
> > +
> > +typedef struct {
> >PROCESSOR_SIGNATURE Signature;
> >PROCESSOR_FEATURE_FLAGS FeatureFlags;
> >  } PROCESSOR_ID_DATA;
> > @@ -2508,6 +2526,57 @@ typedef struct {
> >UINT8 InterfaceTypeSpecificData[4];   ///< 
> > This field has a minimum of four bytes
> >  } SMBIOS_TABLE_TYPE42;
> >
> > +
> > +///
> > +/// Processor Specific Block - Processor Architecture Type
> > +///
> > +typedef enum{
> > +  ProcessorSpecificBlockArchTypeReserved   = 0x00,
> > +  

[edk2-devel] [staging/branch]: CdePkg - C Development Environment Package

[Minnow Ware]

Hi UEFI community,

I’d like to introduce the CdePkg to edk2-staging.

The package is not yet completed but ready to demonstrate it’s power, probably 
also for modernFW.


A couple of years ago, after an UEFI BIOS project on AMD platform I decided to 
write my own ANSI C Library for UEFI Shell and POST.



My design goals were:

  1.  to rewrite the whole thing from scratch, without using any public source 
code from GNU, BSD, Watcom or Intel EDK2 / tiano core
  2.  completeness: full blown C90 + C95 support, no C99, no non-specified 
extensions at all , e.g. itoa(), stricmp()...
  3.  small code size, for UEFI-POST-driver uses a C-Library-Driver, that 
contains core/worker functions for realloc() ==  malloc() and free(),

entire printf-family, entire scanf-family.

UEFI-POST-driver just uses small wrapper functions to run the C-Library-Driver 
code.

  1.  stable, exact, chipset independent (w/o ACPI timer) "clock()” with 
CLOCKS_PER_SEC == 1000
  2.  complete set of the Microsoft C-compiler intrinsic functions
  3.  ROM-able! Runs with stack but w/o any static storage duration in .data 
segment, e.g. for rand(), strtok(), tmpfile()

This is required for early PEI before memory sizing, when PEI-images run 
directly out of flash.

  1.  Microsoft bug compatible (as far as possible)

 *   to save my lifetime writing a documentation  
https://github.com/JoaquinConoBolillo/torito-C-Library/blob/master/implemented.md
 *   use original Microsoft header files for UEFI Shell Apps created in 
VS2017/19
 *   “debug”-mode for UEFI Shell executable in VS2017/19, that truly runs 
on Windows (that works

when using library functions only, no HW access, not UEFI-API use) to debug the 
library

itself – but this just links the same .OBJ module with the WinNT-EntryPoint 
instead of UEFI-EntryPoint

(The entry point module pulls in the appropriate OS-interface branch dispatcher)

  1.  all that in one single C-Library CdeLib.lib


The Readme.MD is here: https://github.com/MinnowWare/CdePkg#cdepkg

CdePkg shall be adjusted to other compilers/tool chains too, once it is feature 
complete and accepted by the UEFI community,
as long as it is for Microsoft VS2017/19 only.

The CdePkg is integrated into the “vUDK2018”-EDK2, which in turn runs in a 
MinnowBoard build.
It can be emulated in the Nt32Pkg, since EmulatorPkg in “vUDK2018” doesn’t 
support Windows…

I would like to move the “vUDK2018”-EDK2 to the edk2-staging branch CdePkg, but 
need to have access granted.

Can anyone kindly grant access rights to me?

Best Regards,
Kilian



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47377): https://edk2.groups.io/g/devel/message/47377
Mute This Topic: https://groups.io/mt/34176618/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 0/3] MdeModulePkg/TerminalConsole: Extend the support terminal types

[Liming Gao]

Leif:

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, September 17, 2019 5:15 PM
> To: devel@edk2.groups.io; Zhang, Shenglei 
> Cc: ard.biesheu...@linaro.org; Wang, Jian J ; Wu, Hao 
> A ; Ni, Ray ;
> Laszlo Ersek ; Gao, Liming ; Gao, 
> Zhichao 
> Subject: Re: [edk2-devel] [PATCH V2 0/3] MdeModulePkg/TerminalConsole: Extend 
> the support terminal types
> 
> On Tue, Sep 17, 2019 at 07:17:27AM +, Zhang, Shenglei wrote:
> > That's my mistake to push the broken 
> > patch(0d85e67714e31e0dbe4241ab2ebb7c423aba174d).
> > This patch only updates the file guid, which I thought has no risk. So I 
> > didn’t check the build result.
> > I should double check the new guid used in the file.
> 
> Determining what affects build and not is something humans are very
> bad at and computers are very good at.
> 
> So you should build check every patch you submit to the list, no
> matter how trivial.
> 
> In normal circumstances, so should the maintainers before pushing the
> patch.

I push this change. I should double confirm its test result. I will improve my 
rule.

> 
> We now have a commit in the tree known to break the build of pretty
> much all ARM/AARCH64 platforms. This will be very unpleasant for
> future bisect.

I agree the build break is the big impact. I expect we can speed up to enable 
EDK II Continuous Integration. 
If so, we can avoid such break again. 

Thanks
Liming
> 
> Best Regards,
> 
> Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47376): https://edk2.groups.io/g/devel/message/47376
Mute This Topic: https://groups.io/mt/34173528/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 11/22]: BaseTools: BaseTools changes for RISC-V platform.

[Leif Lindholm]

On Tue, Sep 17, 2019 at 02:08:53PM +0100, Leif Lindholm wrote:
> > > Please add the requisite support to the GCC5 profile instead. (Which
> > > is not actually for gcc 5, but is effectively GCC5+ - we are still
> > > successfully using it with gcc 9.)
> > 
> > I can try to use GCC5 profile but the toolchain still has to be
> > stick on https://github.com/riscv/riscv-gnu-toolchain @64879b24. We
> > got problem on the version higher than this, system hangs at SEC to
> > PEI transition if use GCC version higher than @64879b24.
> >
> > We will figure it out later.
> 
> I suppose this is fine as long as this is specifically on the
> edk2-staging branch. We will need to resolve it before we bring the
> port to edk2 master.
> 
> I would still like this support to be tweaked to the point where I can
> build with either the Fedora or the Debian packaged cross compiler.
> 
> > So how can I mention this restrictions in tool_def?
> 
> I would suggest the following:
> - The above information in the top-level Readme.md on the staging branch.
> - A single line in the "GCC5 RISCV64 definitions" comment block.
> - Adding the above to the commit message.

Oh, and please add information to that Readme.md on which toolchains
have successfully built this toolchain. Debian's gcc8 fails.

Best Regards,

Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47375): https://edk2.groups.io/g/devel/message/47375
Mute This Topic: https://groups.io/mt/33137137/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 13/22]: MdePkg/Include: Update SmBios header file.

[Leif Lindholm]

On Mon, Sep 16, 2019 at 07:01:50AM +, Chang, Abner (HPS SW/FW Technologist) 
wrote:
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Friday, September 6, 2019 12:17 AM
> > To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> > 
> > Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 13/22]:
> > MdePkg/Include: Update SmBios header file.
> > 
> > On Wed, Sep 04, 2019 at 06:43:08PM +0800, Abner Chang wrote:
> > > Update SmBios header file to conform with SMBIOS v3.3.0.
> > > The major update is to add definitions of SMBIOS Type 44h record.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Abner Chang 
> > 
> > This would be really useful to get straight into edk2 - could you submit it
> > straight for inclusion in edk2 master? We can then cherry-pick that back to
> > the edk2-staging branch.
>
> Forgive me that I don't want to increase the complexity to RISC-V
> edk2 submittal. We can send SMBIOS patch apart from RISC-V patches
> with specific subject for SMBIOS change.

Yes, sorry, that was exactly what I meant :)
Thank you for doing that.

Best Regards,

Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47374): https://edk2.groups.io/g/devel/message/47374
Mute This Topic: https://groups.io/mt/33137139/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 07/22]: MdePkg/BaseIoLibIntrinsic: RISC-V I/O intrinsic functions.

[Leif Lindholm]

On Mon, Sep 16, 2019 at 05:37:51AM +, Chang, Abner (HPS SW/FW Technologist) 
wrote:
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Thursday, September 5, 2019 10:28 PM
> > To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> > 
> > Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 07/22]:
> > MdePkg/BaseIoLibIntrinsic: RISC-V I/O intrinsic functions.
> > 
> > On Wed, Sep 04, 2019 at 06:43:02PM +0800, Abner Chang wrote:
> > > RISC-V MMIO library instance.  RISC-V only supports memory map I/O.
> > > However the first implementation of RISC-V EDK2 port uses PC/AT as the
> > > RISC-V platform spec. We have to keep the I/O functions as the temporary
> > solution.
> > 
> > Can you expand on the I/O port situation?
> > Since the architecture doesn't support it, what do these functions do?
> > 
> > For the pure MMIO ops using compliant C, we really don't need yet another
> > implementation pretending it's architecture specific. We should just have a
> > single IoLibMmio.c and an IoLibMmioNonCompliant.c if the x86 folks want to
> > keep their current one.
> 
> Hmm. That was for the old RISC-V PC/AT QEUM version back to 2016. We
> pulled in some X86 peripherals to build up RISC-V PC/AT like
> platform . will remove this.

Excellent, thanks.

/
Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47373): https://edk2.groups.io/g/devel/message/47373
Mute This Topic: https://groups.io/mt/33137129/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 04/22]: MdePkg/Include: RISC-V definitions.

[Leif Lindholm]

On Mon, Sep 16, 2019 at 05:31:40AM +, Chang, Abner (HPS SW/FW Technologist) 
wrote:
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Thursday, September 5, 2019 4:40 AM
> > To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> > 
> > Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 04/22]:
> > MdePkg/Include: RISC-V definitions.
> > 
> > On Wed, Sep 04, 2019 at 06:42:59PM +0800, Abner Chang wrote:
> > > Add RISC-V processor related definitions.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Abner Chang 
> > > ---
> > >  MdePkg/Include/IndustryStandard/PeImage.h |  14 +-
> > >  MdePkg/Include/Library/BaseLib.h  |  67 ++
> > >  MdePkg/Include/Protocol/DebugSupport.h|  55 +
> > >  MdePkg/Include/Protocol/PxeBaseCode.h |   8 +
> > >  MdePkg/Include/RiscV64/ProcessorBind.h| 336
> > ++
> > >  MdePkg/Include/Uefi/UefiBaseType.h|  25 +++
> > >  MdePkg/Include/Uefi/UefiSpec.h|  11 +
> > >  7 files changed, 513 insertions(+), 3 deletions(-)  create mode
> > > 100644 MdePkg/Include/RiscV64/ProcessorBind.h
> > >
> > > diff --git a/MdePkg/Include/IndustryStandard/PeImage.h
> > > b/MdePkg/Include/IndustryStandard/PeImage.h
> > > index 720bb08..47796b2 100644
> > > --- a/MdePkg/Include/IndustryStandard/PeImage.h
> > > +++ b/MdePkg/Include/IndustryStandard/PeImage.h
> > > @@ -9,6 +9,8 @@
> > >
> > >  Copyright (c) 2006 - 2018, Intel Corporation. All rights
> > > reserved.  Portions copyright (c) 2008 - 2009, Apple Inc. All
> > > rights reserved.
> > > +Portions Copyright (c) 2016, Hewlett Packard Enterprise Development
> > > +LP. All rights reserved.
> > > +
> > >  SPDX-License-Identifier: BSD-2-Clause-Patent
> > >
> > >  **/
> > > @@ -34,6 +36,9 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > >  #define IMAGE_FILE_MACHINE_X64 0x8664
> > >  #define IMAGE_FILE_MACHINE_ARMTHUMB_MIXED  0x01c2
> > >  #define IMAGE_FILE_MACHINE_ARM64   0xAA64
> > > +#define IMAGE_FILE_MACHINE_RISCV32 0x5032
> > > +#define IMAGE_FILE_MACHINE_RISCV64 0x5064
> > > +#define IMAGE_FILE_MACHINE_RISCV1280x5128
> > >
> > >  //
> > >  // EXE file formats
> > > @@ -478,9 +483,9 @@ typedef struct {
> > >  ///
> > >  #define EFI_IMAGE_SIZEOF_BASE_RELOCATION  8
> > >
> > > -//
> > > -// Based relocation types.
> > > -//
> > > +///
> > > +/// Based relocation types.
> > > +///
> > 
> > I don't know if this change to the comment block is a wonky rebase or
> > whatever, but please drop it.
>
> No, I revised it to three back slash because most of comment block
> use three back slash.

It is always appreciated when people provide style fixes, but they
should be provided as separate patches.

In this case I don't see the value in doing that however, since // is
the comment format specified by the coding standars.

A separate patch fixing the existing incorrect ones would be
preferable (but not important).

Best Regards,

Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47372): https://edk2.groups.io/g/devel/message/47372
Mute This Topic: https://groups.io/mt/33137122/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdePkg:Include: Update SmBios header file

[Leif Lindholm]

On Tue, Sep 17, 2019 at 02:24:30PM +0800, Abner Chang wrote:
> Update SmBios header file to conform with SMBIOS v3.3.0.

Ah, I note SMBIOS 3.3 has not yet been released - so this can not be
merged in edk2 master at this point. I did not realise this when I
requested you send the patch.

However, you can carry this in your edk2-staging branch, and once the
specification gets released we can take it into edk2.

(After code review, a couple of minor comments below.)

> The major update is to add definitions of SMBIOS Type 44h record.
> 
> Signed-off-by: Abner Chang 
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Leif Lindholm 
> Cc: Gilbert Chen 
> 
> ---
>  MdePkg/Include/IndustryStandard/SmBios.h | 74 
> +++-
>  1 file changed, 72 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
> b/MdePkg/Include/IndustryStandard/SmBios.h
> index f3b6f18..ebf0ceb 100644
> --- a/MdePkg/Include/IndustryStandard/SmBios.h
> +++ b/MdePkg/Include/IndustryStandard/SmBios.h
> @@ -3,6 +3,7 @@
>  
>  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>  (C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP
> +(C) Copyright 2015 - 2019 Hewlett Packard Enterprise Development LP
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
> @@ -46,7 +47,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #define SMBIOS_3_0_TABLE_MAX_LENGTH 0x
>  
>  //
> -// SMBIOS type macros which is according to SMBIOS 2.7 specification.
> +// SMBIOS type macros which is according to SMBIOS 3.3.0 specification.
>  //
>  #define SMBIOS_TYPE_BIOS_INFORMATION 0
>  #define SMBIOS_TYPE_SYSTEM_INFORMATION   1
> @@ -92,6 +93,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #define SMBIOS_TYPE_ONBOARD_DEVICES_EXTENDED_INFORMATION 41
>  #define SMBIOS_TYPE_MANAGEMENT_CONTROLLER_HOST_INTERFACE 42
>  #define SMBIOS_TYPE_TPM_DEVICE   43
> +#define SMBIOS_TYPE_PROCESSOR_ADDITIONAL_INFORMATION 44
>  
>  ///
>  /// Inactive type is added from SMBIOS 2.2. Reference SMBIOS 2.6, chapter 
> 3.3.43.
> @@ -727,7 +729,10 @@ typedef enum {
>ProcessorFamilyMII   = 0x012E,
>ProcessorFamilyWinChip   = 0x0140,
>ProcessorFamilyDSP   = 0x015E,
> -  ProcessorFamilyVideoProcessor= 0x01F4
> +  ProcessorFamilyVideoProcessor= 0x01F4,
> +  ProcessorFamilyRiscvRV32 = 0x0200,  ///< SMBIOS spec 3.3.0 
> added

Please drop the "///< SMBIOS spec 3.3.0 added" comment. Here and below.

> +  ProcessorFamilyRiscVRV64 = 0x0201,  ///< SMBIOS spec 3.3.0 
> added
> +  ProcessorFamilyRiscVRV128= 0x0202   ///< SMBIOS spec 3.3.0 
> added

No further comments from me (MdePkg maintainers may have some).

/
Leif

>  } PROCESSOR_FAMILY2_DATA;
>  
>  ///
> @@ -857,6 +862,19 @@ typedef struct {
>  } PROCESSOR_FEATURE_FLAGS;
>  
>  typedef struct {
> +  UINT32  ProcessorReserved1 :1;
> +  UINT32  ProcessorUnknown   :1;
> +  UINT32  Processor64BitCapble   :1;
> +  UINT32  ProcessorMultiCore :1;
> +  UINT32  ProcessorHardwareThread:1;
> +  UINT32  ProcessorExecuteProtection :1;
> +  UINT32  ProcessorEnhancedVirtulization :1;
> +  UINT32  ProcessorPowerPerformanceCtrl  :1;
> +  UINT32  Processor128bitCapble  :1;
> +  UINT32  ProcessorReserved2 :7;
> +} PROCESSOR_CHARACTERISTIC_FLAGS;
> +
> +typedef struct {
>PROCESSOR_SIGNATURE Signature;
>PROCESSOR_FEATURE_FLAGS FeatureFlags;
>  } PROCESSOR_ID_DATA;
> @@ -2508,6 +2526,57 @@ typedef struct {
>UINT8 InterfaceTypeSpecificData[4];   ///< 
> This field has a minimum of four bytes
>  } SMBIOS_TABLE_TYPE42;
>  
> +
> +///
> +/// Processor Specific Block - Processor Architecture Type
> +///
> +typedef enum{
> +  ProcessorSpecificBlockArchTypeReserved   = 0x00,
> +  ProcessorSpecificBlockArchTypeIa32   = 0x01,
> +  ProcessorSpecificBlockArchTypeX64= 0x02,
> +  ProcessorSpecificBlockArchTypeItanium= 0x03,
> +  ProcessorSpecificBlockArchTypeAarch32= 0x04,
> +  ProcessorSpecificBlockArchTypeAarch64= 0x05,
> +  ProcessorSpecificBlockArchTypeRiscVRV32  = 0x06,
> +  ProcessorSpecificBlockArchTypeRiscVRV64  = 0x07,
> +  ProcessorSpecificBlockArchTypeRiscVRV128 = 0x08
> +} PROCESSOR_SPECIFIC_BLOCK_ARCH_TYPE;
> +
> +///
> +/// Processor Specific Block is the standard container of processor-specific 
> data.
> +///
> +typedef struct {
> +  UINT8  Length;
> +  UINT8  ProcessorArchType;
> +  ///
> +  /// Below followed by Processor-specific data
> +  ///
> +  ///
> +} PROCESSOR_SPECIFIC_BLOCK;
> +
> +///
> +/// Processor Additional Information(Type 44).
> +///
> +/// The information in this structure defines the processor additional 
> information in case
> +/// SMBIOS type 4 is not sufficient to 

[edk2-devel] [PATCH 2/2] tests: q35: MCH: add default SMBASE SMRAM lock test

[Igor Mammedov]

test lockable SMRAM at default SMBASE feature introduced by
commit "q35: implement 128K SMRAM at default SMBASE address"

Signed-off-by: Igor Mammedov 
---
 tests/q35-test.c | 105 +++
 1 file changed, 105 insertions(+)

diff --git a/tests/q35-test.c b/tests/q35-test.c
index a68183d513..dd02660303 100644
--- a/tests/q35-test.c
+++ b/tests/q35-test.c
@@ -186,6 +186,109 @@ static void test_tseg_size(const void *data)
 qtest_quit(qts);
 }
 
+#define SMBASE 0x3
+#define SMRAM_TEST_PATTERN 0x32
+#define SMRAM_TEST_RESET_PATTERN 0x23
+
+static void test_smram_smbase_lock(void)
+{
+QPCIBus *pcibus;
+QPCIDevice *pcidev;
+QDict *response;
+QTestState *qts;
+int i;
+
+qts = qtest_init("-M q35");
+
+pcibus = qpci_new_pc(qts, NULL);
+g_assert(pcibus != NULL);
+
+pcidev = qpci_device_find(pcibus, 0);
+g_assert(pcidev != NULL);
+
+/* check that SMRAM is not enabled by default */
+g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == 0);
+qtest_writeb(qts, SMBASE, SMRAM_TEST_PATTERN);
+g_assert_cmpint(qtest_readb(qts, SMBASE), ==, SMRAM_TEST_PATTERN);
+
+/* check that writinng junk to 0x9c before before negotiating is ignorred 
*/
+for (i = 0; i < 0xff; i++) {
+qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, i);
+g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == 0);
+}
+
+/* enable SMRAM at SMBASE */
+qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, 0xff);
+g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == 0x01);
+/* lock SMRAM at SMBASE */
+qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, 0x02);
+g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == 0x02);
+
+/* check that SMRAM at SMBASE is locked and can't be unlocked */
+g_assert_cmpint(qtest_readb(qts, SMBASE), ==, 0xff);
+for (i = 0; i <= 0xff; i++) {
+/* make sure register is immutable */
+qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, i);
+g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == 0x02);
+
+/* RAM access should go inot black hole */
+qtest_writeb(qts, SMBASE, SMRAM_TEST_PATTERN);
+g_assert_cmpint(qtest_readb(qts, SMBASE), ==, 0xff);
+}
+
+/* reset */
+response = qtest_qmp(qts, "{'execute': 'system_reset', 'arguments': {} }");
+g_assert(response);
+g_assert(!qdict_haskey(response, "error"));
+qobject_unref(response);
+
+/* check RAM at SMBASE is available after reset */
+g_assert_cmpint(qtest_readb(qts, SMBASE), ==, SMRAM_TEST_PATTERN);
+g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == 0);
+qtest_writeb(qts, SMBASE, SMRAM_TEST_RESET_PATTERN);
+g_assert_cmpint(qtest_readb(qts, SMBASE), ==, SMRAM_TEST_RESET_PATTERN);
+
+g_free(pcidev);
+qpci_free_pc(pcibus);
+
+qtest_quit(qts);
+}
+
+static void test_without_smram_base(void)
+{
+QPCIBus *pcibus;
+QPCIDevice *pcidev;
+QTestState *qts;
+int i;
+
+qts = qtest_init("-M pc-q35-4.1");
+
+pcibus = qpci_new_pc(qts, NULL);
+g_assert(pcibus != NULL);
+
+pcidev = qpci_device_find(pcibus, 0);
+g_assert(pcidev != NULL);
+
+/* check that RAM accessible */
+qtest_writeb(qts, SMBASE, SMRAM_TEST_PATTERN);
+g_assert_cmpint(qtest_readb(qts, SMBASE), ==, SMRAM_TEST_PATTERN);
+
+/* check that writing to 0x9c succeeds */
+for (i = 0; i <= 0xff; i++) {
+qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, i);
+g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) == i);
+}
+
+/* check that RAM is still accessible */
+qtest_writeb(qts, SMBASE, SMRAM_TEST_PATTERN + 1);
+g_assert_cmpint(qtest_readb(qts, SMBASE), ==, (SMRAM_TEST_PATTERN + 1));
+
+g_free(pcidev);
+qpci_free_pc(pcibus);
+
+qtest_quit(qts);
+}
+
 int main(int argc, char **argv)
 {
 g_test_init(, , NULL);
@@ -197,5 +300,7 @@ int main(int argc, char **argv)
 qtest_add_data_func("/q35/tseg-size/8mb", _8mb, test_tseg_size);
 qtest_add_data_func("/q35/tseg-size/ext/16mb", _ext_16mb,
 test_tseg_size);
+qtest_add_func("/q35/smram/smbase_lock", test_smram_smbase_lock);
+qtest_add_func("/q35/smram/legacy_smbase", test_without_smram_base);
 return g_test_run();
 }
-- 
2.18.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47366): https://edk2.groups.io/g/devel/message/47366
Mute This Topic: https://groups.io/mt/34175730/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 0/2] q35: mch: allow to lock down 128K RAM at default SMBASE address

[Igor Mammedov]

Try #2 using PCI config space of MCH to negotiate/lock SMRAM
at 0x3.

CC: yingwen.c...@intel.com
CC: devel@edk2.groups.io
CC: phillip.go...@oracle.com
CC: alex.william...@redhat.com
CC: jiewen@intel.com
CC: jun.nakaj...@intel.com
CC: michael.d.kin...@intel.com
CC: pbonz...@redhat.com
CC: boris.ostrov...@oracle.com
CC: r...@edk2.groups.io
CC: joao.m.mart...@oracle.com
CC: ler...@redhat.com


Igor Mammedov (2):
  q35: implement 128K SMRAM at default SMBASE address
  tests: q35: MCH: add default SMBASE SMRAM lock test

 include/hw/pci-host/q35.h |  10 
 hw/i386/pc.c  |   4 +-
 hw/pci-host/q35.c |  80 ++---
 tests/q35-test.c  | 105 ++
 4 files changed, 191 insertions(+), 8 deletions(-)

-- 
2.18.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47364): https://edk2.groups.io/g/devel/message/47364
Mute This Topic: https://groups.io/mt/34175725/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/2] q35: implement 128K SMRAM at default SMBASE address

[Igor Mammedov]

Use commit (2f295167e0 q35/mch: implement extended TSEG sizes) for
inspiration and (ab)use reserved register in config space at 0x9c
offset [*] to extend q35 pci-host with ability to use 128K at
0x3 as SMRAM and hide it (like TSEG) from non-SMM context.

Usage:
  1: write 0xff in the register
  2: if the feature is supported, follow up read from the register
 should return 0x01. At this point RAM at 0x3 is still
 available for SMI handler configuration from non-SMM context
  3: writing 0x02 in the register, locks SMBASE area, making its contents
 available only from SMM context. In non-SMM context, reads return
 0xff and writes are ignored. Further writes into the register are
 ignored until the system reset.

*) https://www.mail-archive.com/qemu-devel@nongnu.org/msg455991.html

Signed-off-by: Igor Mammedov 
---
 include/hw/pci-host/q35.h | 10 +
 hw/i386/pc.c  |  4 +-
 hw/pci-host/q35.c | 80 +++
 3 files changed, 86 insertions(+), 8 deletions(-)

diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index b3bcf2e632..976fbae599 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -32,6 +32,7 @@
 #include "hw/acpi/ich9.h"
 #include "hw/pci-host/pam.h"
 #include "hw/i386/intel_iommu.h"
+#include "qemu/units.h"
 
 #define TYPE_Q35_HOST_DEVICE "q35-pcihost"
 #define Q35_HOST_DEVICE(obj) \
@@ -54,6 +55,8 @@ typedef struct MCHPCIState {
 MemoryRegion smram_region, open_high_smram;
 MemoryRegion smram, low_smram, high_smram;
 MemoryRegion tseg_blackhole, tseg_window;
+MemoryRegion smbase_blackhole, smbase_window;
+bool has_smram_at_smbase;
 Range pci_hole;
 uint64_t below_4g_mem_size;
 uint64_t above_4g_mem_size;
@@ -97,6 +100,13 @@ typedef struct Q35PCIHost {
 #define MCH_HOST_BRIDGE_EXT_TSEG_MBYTES_QUERY  0x
 #define MCH_HOST_BRIDGE_EXT_TSEG_MBYTES_MAX0xfff
 
+#define MCH_HOST_BRIDGE_SMBASE_SIZE(128 * KiB)
+#define MCH_HOST_BRIDGE_SMBASE_ADDR0x3
+#define MCH_HOST_BRIDGE_F_SMBASE   0x9c
+#define MCH_HOST_BRIDGE_F_SMBASE_QUERY 0xff
+#define MCH_HOST_BRIDGE_F_SMBASE_IN_RAM0x01
+#define MCH_HOST_BRIDGE_F_SMBASE_LCK   0x02
+
 #define MCH_HOST_BRIDGE_PCIEXBAR   0x60/* 64bit register */
 #define MCH_HOST_BRIDGE_PCIEXBAR_SIZE  8   /* 64bit register */
 #define MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT   0xb000
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index bad866fe44..288d28358a 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -119,7 +119,9 @@ struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
 /* Physical Address of PVH entry point read from kernel ELF NOTE */
 static size_t pvh_start_addr;
 
-GlobalProperty pc_compat_4_1[] = {};
+GlobalProperty pc_compat_4_1[] = {
+{ "mch", "smbase-smram", "off" },
+};
 const size_t pc_compat_4_1_len = G_N_ELEMENTS(pc_compat_4_1);
 
 GlobalProperty pc_compat_4_0[] = {};
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 158d270b9f..c1bd9f78ae 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -275,20 +275,20 @@ static const TypeInfo q35_host_info = {
  * MCH D0:F0
  */
 
-static uint64_t tseg_blackhole_read(void *ptr, hwaddr reg, unsigned size)
+static uint64_t blackhole_read(void *ptr, hwaddr reg, unsigned size)
 {
 return 0x;
 }
 
-static void tseg_blackhole_write(void *opaque, hwaddr addr, uint64_t val,
- unsigned width)
+static void blackhole_write(void *opaque, hwaddr addr, uint64_t val,
+unsigned width)
 {
 /* nothing */
 }
 
-static const MemoryRegionOps tseg_blackhole_ops = {
-.read = tseg_blackhole_read,
-.write = tseg_blackhole_write,
+static const MemoryRegionOps blackhole_ops = {
+.read = blackhole_read,
+.write = blackhole_write,
 .endianness = DEVICE_NATIVE_ENDIAN,
 .valid.min_access_size = 1,
 .valid.max_access_size = 4,
@@ -430,6 +430,46 @@ static void mch_update_ext_tseg_mbytes(MCHPCIState *mch)
 }
 }
 
+static void mch_update_smbase_smram(MCHPCIState *mch)
+{
+PCIDevice *pd = PCI_DEVICE(mch);
+uint8_t *reg = pd->config + MCH_HOST_BRIDGE_F_SMBASE;
+bool lck;
+
+if (!mch->has_smram_at_smbase) {
+return;
+}
+
+if (*reg == MCH_HOST_BRIDGE_F_SMBASE_QUERY) {
+pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] =
+MCH_HOST_BRIDGE_F_SMBASE_LCK;
+*reg = MCH_HOST_BRIDGE_F_SMBASE_IN_RAM;
+return;
+}
+
+/*
+ * default/reset state, discard written value
+ * which will disable SMRAM balackhole at SMBASE
+ */
+if (pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] == 0xff) {
+*reg = 0x00;
+}
+
+memory_region_transaction_begin();
+if (*reg & MCH_HOST_BRIDGE_F_SMBASE_LCK) {
+/* disable all writes */
+pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] &=
+~MCH_HOST_BRIDGE_F_SMBASE_LCK;
+*reg = 

Re: [edk2-devel] [edk2] DxeIpl : create page table, occupied too much memory range

[Laszlo Ersek]

On 09/17/19 13:08, Tiger Liu(BJ-RD) wrote:
> Hi, Expert:
> I have a question about creating page table.
> If a CPU support 48bit physical address line, then creating page tables(Page 
> size=2MB) will occupy too much memory region.
> 
> Now, developer could only use PcdUse1GPageTable to avoid occupy too much 
> memory region?

Not only. See .

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47362): https://edk2.groups.io/g/devel/message/47362
Mute This Topic: https://groups.io/mt/34174701/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2] DxeIpl : create page table, occupied too much memory range

[Tiger Liu(BJ-RD)]

Hi, Expert:
I have a question about creating page table.
If a CPU support 48bit physical address line, then creating page tables(Page 
size=2MB) will occupy too much memory region.

Now, developer could only use PcdUse1GPageTable to avoid occupy too much memory 
region?

Thanks

Best wishes,


?
?
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47361): https://edk2.groups.io/g/devel/message/47361
Mute This Topic: https://groups.io/mt/34174701/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 1/3] MdeModulePkg: Extend the support keyboard type of Terminal console

[Laszlo Ersek]

On 09/17/19 08:19, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2186
> 
> A common terminal console software Putty support various types of
> keyboard type, such as normal mode, Linux mode, Xterm R6, Vt400,
> VT100+ and SCO. Refer to the link:
> https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 
> Cc: Liming Gao 
> Signed-off-by: Zhichao Gao 
> ---
>  MdeModulePkg/Include/Guid/TtyTerm.h | 13 +
>  MdeModulePkg/MdeModulePkg.dec   |  4 
>  2 files changed, 17 insertions(+)
> 
> diff --git a/MdeModulePkg/Include/Guid/TtyTerm.h 
> b/MdeModulePkg/Include/Guid/TtyTerm.h
> index 844b9d..19e0faa8bc 100644
> --- a/MdeModulePkg/Include/Guid/TtyTerm.h
> +++ b/MdeModulePkg/Include/Guid/TtyTerm.h
> @@ -4,6 +4,7 @@ provide support for modern *nix terminals.
>  
>  
>  Copyright (c) 2015  Linaro Ltd.
> +Copyright (c) 2019, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
> @@ -14,6 +15,18 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #define EFI_TTY_TERM_GUID\
>  {0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 
> 0x94 } }
>  
> +#define EDKII_LINUX_MODE_GUID   \
> +{0xe4364a7f, 0xf825, 0x430e, {0x9d, 0x3a, 0x9c, 0x9b, 0xe6, 0x81, 0x7c, 
> 0xa5 } }
> +
> +#define EDKII_XTERM_R6_GUID \
> +{0xfbfca56b, 0xbb36, 0x4b78, {0xaa, 0xab, 0xbe, 0x1b, 0x97, 0xec, 0x7c, 
> 0xcb } }
> +
> +#define EDKII_VT400_GUID\
> +{0x8e46, 0x3d49, 0x4a9d, {0xb8, 0x75, 0x3c, 0x08, 0x6f, 0x6a, 0xa2, 
> 0xbd } }
> +
> +#define EDKII_SCO_GUID  \
> +{0xfc7dd6e0, 0x813c, 0x434d, {0xb4, 0xda, 0x3b, 0xd6, 0x49, 0xe9, 0xe1, 
> 0x5a } }
> +
>  extern EFI_GUID gEfiTtyTermGuid;
>  
>  #endif
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index 17beb45235..67b7bbd83d 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -342,6 +342,10 @@
>  
>## Include/Guid/TtyTerm.h
>gEfiTtyTermGuid= { 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 
> 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 }}
> +  gEdkiiLinuxModeGuid= { 0xe4364a7f, 0xf825, 0x430e, {0x9d, 
> 0x3a, 0x9c, 0x9b, 0xe6, 0x81, 0x7c, 0xa5 }}
> +  gEdkiiXtermR6Guid  = { 0xfbfca56b, 0xbb36, 0x4b78, {0xaa, 
> 0xab, 0xbe, 0x1b, 0x97, 0xec, 0x7c, 0xcb }}
> +  gEdkiiVT400Guid= { 0x8e46, 0x3d49, 0x4a9d, {0xb8, 
> 0x75, 0x3c, 0x08, 0x6f, 0x6a, 0xa2, 0xbd }}
> +  gEdkiiSCOGuid  = { 0xfc7dd6e0, 0x813c, 0x434d, {0xb4, 
> 0xda, 0x3b, 0xd6, 0x49, 0xe9, 0xe1, 0x5a }}
>  
>## Include/Guid/HiiBootMaintenanceFormset.h
>gEfiIfrBootMaintenanceGuid  = { 0xb2dedc91, 0xd59f, 0x48d2, { 0x89, 
> 0x8a, 0x12, 0x49, 0xc, 0x74, 0xa4, 0xe0 }}
> 

Shouldn't we put "Tty" or "Term" or "Terminal" somewhere in the symbolic
names of the GUIDs? "Xterm" and "VT400" are OK already, but "LinuxMode"
and "SCO" are too general, in my opinion.

Just a random comment, I defer to the MdeModulePkg maintainers.

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47360): https://edk2.groups.io/g/devel/message/47360
Mute This Topic: https://groups.io/mt/34173529/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 0/3] MdeModulePkg/TerminalConsole: Extend the support terminal types

[Leif Lindholm]

On Tue, Sep 17, 2019 at 07:17:27AM +, Zhang, Shenglei wrote:
> That's my mistake to push the broken 
> patch(0d85e67714e31e0dbe4241ab2ebb7c423aba174d).
> This patch only updates the file guid, which I thought has no risk. So I 
> didn’t check the build result. 
> I should double check the new guid used in the file.

Determining what affects build and not is something humans are very
bad at and computers are very good at.

So you should build check every patch you submit to the list, no
matter how trivial.

In normal circumstances, so should the maintainers before pushing the
patch.

We now have a commit in the tree known to break the build of pretty
much all ARM/AARCH64 platforms. This will be very unpleasant for
future bisect.

Best Regards,

Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47359): https://edk2.groups.io/g/devel/message/47359
Mute This Topic: https://groups.io/mt/34173528/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] StandaloneMmPkg: make package .DSC file build again

[Ard Biesheuvel]

On Mon, 16 Sep 2019 at 19:26, Laszlo Ersek  wrote:
>
> On 09/16/19 17:06, Yao, Jiewen wrote:
> > That is correct.
> >
> > Current trunk only supports ARM system.
> >
> > I have branch to support x86 - 
> > https://github.com/jyao1/edk2/tree/StandaloneSmmX86Poc
> > But that is not merged into trunk yet.
>
> In that case, for this patch:
>
> Build-tested-by: Laszlo Ersek 
>
> (apologies, my prior R-b was a typo; I pressed the wrong hotkey for
> inserting the tag in the email)
>
> I still think the IA32/X64 part should be removed from
> SUPPORTED_ARCHITECTURES (and their addition should be a part of Jiewen's
> topic branch). But, I agree such a cleanup is out of scope for this
> patch; the patch does fix the AARCH64 regression.
>
> Thank you, Ard!
> Laszlo
>

Pushed as 9790f62be1aa..82c1a2120855

Thanks all.

> >> -Original Message-
> >> From: Ard Biesheuvel 
> >> Sent: Monday, September 16, 2019 1:18 PM
> >> To: Laszlo Ersek 
> >> Cc: edk2-devel-groups-io ; Achin Gupta
> >> ; Yao, Jiewen 
> >> Subject: Re: [PATCH] StandaloneMmPkg: make package .DSC file build again
> >>
> >> On Mon, 16 Sep 2019 at 12:13, Laszlo Ersek  wrote:
> >>>
> >>> Hi Ard,
> >>>
> >>> On 09/13/19 21:04, Ard Biesheuvel wrote:
>  The StandaloneMmPkg .DSC file went out of sync with the changes
>  applied to the package when I enabled this code on the Synquacer
>  platform in edk2-platforms. So apply the necessary changes to make
>  this package build in isolation.
> 
>  Signed-off-by: Ard Biesheuvel 
>  ---
>   StandaloneMmPkg/StandaloneMmPkg.dsc | 19 +++
>   1 file changed, 11 insertions(+), 8 deletions(-)
> 
>  diff --git a/StandaloneMmPkg/StandaloneMmPkg.dsc
> >> b/StandaloneMmPkg/StandaloneMmPkg.dsc
>  index 8c5b9b3a3d47..8a68d397469b 100644
>  --- a/StandaloneMmPkg/StandaloneMmPkg.dsc
>  +++ b/StandaloneMmPkg/StandaloneMmPkg.dsc
>  @@ -39,29 +39,32 @@
> BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
> 
> >> DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDe
> >> bugPrintErrorLevelLib.inf
>  +
> >> ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/P
> >> rePiExtractGuidedSectionLib.inf
> FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf
>  -
> >> HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmC
> >> oreHobLib.inf
>  +
> >> HobLib|StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLi
> >> b.inf
> IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> 
> >> MemLib|StandaloneMmPkg/Library/StandaloneMmMemLib/StandaloneMmMe
> >> mLib.inf
> 
> >> MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmCoreMemoryAl
> >> locationLib/StandaloneMmCoreMemoryAllocationLib.inf
>  +
> >> MmServicesTableLib|MdePkg/Library/StandaloneMmServicesTableLib/Standalo
> >> neMmServicesTableLib.inf
> PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
>  +
> >> PeCoffExtraActionLib|StandaloneMmPkg/Library/StandaloneMmPeCoffExtraAct
> >> ionLib/StandaloneMmPeCoffExtraActionLib.inf
> PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
> PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> 
> >> ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseRepo
> >> rtStatusCodeLibNull.inf
>  -
>  -  #
>  -  # Entry point
>  -  #
>  -
> >> StandaloneMmDriverEntryPoint|StandaloneMmPkg/Library/StandaloneMmDriv
> >> erEntryPoint/StandaloneMmDriverEntryPoint.inf
>  +
> >> StandaloneMmCoreEntryPoint|StandaloneMmPkg/Library/StandaloneMmCoreE
> >> ntryPoint/StandaloneMmCoreEntryPoint.inf
>  +
> >> StandaloneMmDriverEntryPoint|MdePkg/Library/StandaloneMmDriverEntryPoin
> >> t/StandaloneMmDriverEntryPoint.inf
> 
>   [LibraryClasses.AARCH64]
> ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> 
> >> StandaloneMmMmuLib|ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStand
> >> aloneMmLib.inf
> ArmSvcLib|ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf
> 
> >> CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMa
> >> intenanceLib.inf
>  -
> >> PeCoffExtraActionLib|StandaloneMmPkg/Library/StandaloneMmPeCoffExtraAct
> >> ionLib/StandaloneMmPeCoffExtraActionLib.inf
> 
>  -
> >> StandaloneMmCoreEntryPoint|StandaloneMmPkg/Library/StandaloneMmCoreE
> >> ntryPoint/StandaloneMmCoreEntryPoint.inf
>  +  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
>  +  NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
>  +
>  +[LibraryClasses.common.MM_CORE_STANDALONE]
>  +
> >> HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmC
> >> oreHobLib.inf
> 
> 
> >> #
> >> ###
>   #
> 
> >>>
> >>> With this patch applied on top of 

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 04/22]: MdePkg/Include: RISC-V definitions.

[Abner Chang]

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, September 5, 2019 4:40 AM
> To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> 
> Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 04/22]:
> MdePkg/Include: RISC-V definitions.
> 
> On Wed, Sep 04, 2019 at 06:42:59PM +0800, Abner Chang wrote:
> > Add RISC-V processor related definitions.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Abner Chang 
> > ---
> >  MdePkg/Include/IndustryStandard/PeImage.h |  14 +-
> >  MdePkg/Include/Library/BaseLib.h  |  67 ++
> >  MdePkg/Include/Protocol/DebugSupport.h|  55 +
> >  MdePkg/Include/Protocol/PxeBaseCode.h |   8 +
> >  MdePkg/Include/RiscV64/ProcessorBind.h| 336
> ++
> >  MdePkg/Include/Uefi/UefiBaseType.h|  25 +++
> >  MdePkg/Include/Uefi/UefiSpec.h|  11 +
> >  7 files changed, 513 insertions(+), 3 deletions(-)  create mode
> > 100644 MdePkg/Include/RiscV64/ProcessorBind.h
> >
> > diff --git a/MdePkg/Include/IndustryStandard/PeImage.h
> > b/MdePkg/Include/IndustryStandard/PeImage.h
> > index 720bb08..47796b2 100644
> > --- a/MdePkg/Include/IndustryStandard/PeImage.h
> > +++ b/MdePkg/Include/IndustryStandard/PeImage.h
> > @@ -9,6 +9,8 @@
> >
> >  Copyright (c) 2006 - 2018, Intel Corporation. All rights
> > reserved.  Portions copyright (c) 2008 - 2009, Apple Inc. All
> > rights reserved.
> > +Portions Copyright (c) 2016, Hewlett Packard Enterprise Development
> > +LP. All rights reserved.
> > +
> >  SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -34,6 +36,9 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #define IMAGE_FILE_MACHINE_X64 0x8664
> >  #define IMAGE_FILE_MACHINE_ARMTHUMB_MIXED  0x01c2
> >  #define IMAGE_FILE_MACHINE_ARM64   0xAA64
> > +#define IMAGE_FILE_MACHINE_RISCV32 0x5032
> > +#define IMAGE_FILE_MACHINE_RISCV64 0x5064
> > +#define IMAGE_FILE_MACHINE_RISCV1280x5128
> >
> >  //
> >  // EXE file formats
> > @@ -478,9 +483,9 @@ typedef struct {
> >  ///
> >  #define EFI_IMAGE_SIZEOF_BASE_RELOCATION  8
> >
> > -//
> > -// Based relocation types.
> > -//
> > +///
> > +/// Based relocation types.
> > +///
> 
> I don't know if this change to the comment block is a wonky rebase or
> whatever, but please drop it.
> 
> >  #define EFI_IMAGE_REL_BASED_ABSOLUTE0
> >  #define EFI_IMAGE_REL_BASED_HIGH1
> >  #define EFI_IMAGE_REL_BASED_LOW 2
> > @@ -488,7 +493,10 @@ typedef struct {
> >  #define EFI_IMAGE_REL_BASED_HIGHADJ 4
> >  #define EFI_IMAGE_REL_BASED_MIPS_JMPADDR5
> >  #define EFI_IMAGE_REL_BASED_ARM_MOV32A  5
> > +#define EFI_IMAGE_REL_BASED_RISCV_HI20  5
> >  #define EFI_IMAGE_REL_BASED_ARM_MOV32T  7
> > +#define EFI_IMAGE_REL_BASED_RISCV_LOW12I7
> > +#define EFI_IMAGE_REL_BASED_RISCV_LOW12S8
> 
> I agree this is following the existing pattern, but the existing pattern looks
> bonkers. Sorting relocation types by numeric value rather than grouping the
> architecture-specific ones by architecture...
> 
> Could you group the RISC-V ones together and put them after a single blank
> line below the current defines? I'll try to come back and fix the others once
> this set has been merged.
> 
> >  #define EFI_IMAGE_REL_BASED_IA64_IMM64  9
> >  #define EFI_IMAGE_REL_BASED_MIPS_JMPADDR16  9
> >  #define EFI_IMAGE_REL_BASED_DIR64   10
> > diff --git a/MdePkg/Include/Library/BaseLib.h
> > b/MdePkg/Include/Library/BaseLib.h
> > index 2a75bc0..5f0ee8d 100644
> > --- a/MdePkg/Include/Library/BaseLib.h
> > +++ b/MdePkg/Include/Library/BaseLib.h
> > @@ -4,6 +4,8 @@
> >
> >  Copyright (c) 2006 - 2019, Intel Corporation. All rights
> > reserved.  Portions copyright (c) 2008 - 2009, Apple Inc. All
> > rights reserved.
> > +Portions Copyright (c) 2016, Hewlett Packard Enterprise Development
> > +LP. All rights reserved.
> > +
> >  SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -124,6 +126,71 @@ typedef struct {
> >
> >  #endif  // defined (MDE_CPU_AARCH64)
> >
> > +#if defined (MDE_CPU_RISCV64)
> > +///
> > +/// The RISC-V architecture context buffer used by SetJump() and
> LongJump().
> > +///
> > +typedef struct {
> > +  UINT64RA;
> > +  UINT64S0;
> > +  UINT64S1;
> > +  UINT64S2;
> > +  UINT64S3;
> > +  UINT64S4;
> > +  UINT64S5;
> > +  UINT64S6;
> > +  UINT64S7;
> > +  UINT64S8;
> > +  UINT64S9;
> > +  UINT64S10;
> > +  UINT64S11;
> > +  UINT64SP;
> > +} BASE_LIBRARY_JUMP_BUFFER;
> > +
> > 

Re: [edk2-devel] [PATCH V2 0/3] MdeModulePkg/TerminalConsole: Extend the support terminal types

[Ard Biesheuvel]

On Tue, 17 Sep 2019 at 08:17, Zhang, Shenglei  wrote:
>
> Hi Ard,
>
> That's my mistake to push the broken 
> patch(0d85e67714e31e0dbe4241ab2ebb7c423aba174d).
> This patch only updates the file guid, which I thought has no risk. So I 
> didn’t check the build result.
> I should double check the new guid used in the file. Liming has help send a 
> patch to fix this issue.
>

I understand.

Please don't push changes without making sure they actually build.

Thanks,
Ard.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47356): https://edk2.groups.io/g/devel/message/47356
Mute This Topic: https://groups.io/mt/34173528/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 2/3] MdeModulePkg/TerminalDxe: Extend the terminal console support types

[Gao, Zhichao]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Gao, Zhichao
> Sent: Tuesday, September 17, 2019 2:19 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Gao, Liming 
> Subject: [edk2-devel] [PATCH V2 2/3] MdeModulePkg/TerminalDxe: Extend
> the terminal console support types
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2186
> 
> Extend the support types of terminal console driver. New added types are
> Linux, XtermR6, VT400 and SCO.
> 
> Refer to
> https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-
> funkeys
> 
> Add the missing VT100+ function keys map.
> 
> Add F1-F12 function keys map for Linux, XtermR6, VT400 and SCO.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Cc: Liming Gao 
> Signed-off-by: Zhichao Gao 
> ---
>  .../Universal/Console/TerminalDxe/Terminal.c  |  17 +-
>   .../Universal/Console/TerminalDxe/Terminal.h  |  37 ++-
>  .../Console/TerminalDxe/TerminalConIn.c   | 281 --
>  .../Console/TerminalDxe/TerminalConOut.c  |   4 +
>  .../Console/TerminalDxe/TerminalDxe.inf   |   6 +-
>  5 files changed, 319 insertions(+), 26 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> index c76b2c5100..526067d023 100644
> --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> @@ -2,7 +2,7 @@
>Produces Simple Text Input Protocol, Simple Text Input Extended Protocol
> and
>Simple Text Output Protocol upon Serial IO Protocol.
> 
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -28,7 +28,11 @@ EFI_GUID  *mTerminalType[] = {
>,
>,
>,
> -  
> +  ,
> +  ,
> +  ,
> +  ,
> +  
>  };
> 
> 
> @@ -37,7 +41,11 @@ CHAR16 *mSerialConsoleNames[] = {
>L"VT-100 Serial Console",
>L"VT-100+ Serial Console",
>L"VT-UTF8 Serial Console",
> -  L"Tty Terminal Serial Console"
> +  L"Tty Terminal Serial Console",
> +  L"Linux Mode Terminal Serial Console",  L"Xterm R6 Terminal Serial
> + Console",
> +  L"VT400 Terminal Serial Console",
> +  L"SCO Terminal Serial Console"
>  };
> 
>  TERMINAL_DEV  mTerminalDevTemplate = {
> @@ -187,7 +195,8 @@ TerminalDriverBindingSupported (
> 
>}
>//
> -  // only supports PC ANSI, VT100, VT100+, VT-UTF8, and TtyTerm terminal
> types
> +  // only supports PC ANSI, VT100, VT100+, VT-UTF8, TtyTerm
> +  // Linux, XtermR6, VT400 and SCO terminal types
>//
>if (TerminalTypeFromGuid (>Guid) == ARRAY_SIZE
> (mTerminalType)) {
>  return EFI_UNSUPPORTED;
> diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
> b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
> index b2f0901fc1..d683aa792f 100644
> --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
> +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
> @@ -1,7 +1,7 @@
>  /** @file
>Header file for Terminal driver.
> 
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  Copyright (C) 2016 Silicon Graphics, Inc. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> @@ -81,7 +81,11 @@ typedef enum {
>TerminalTypeVt100,
>TerminalTypeVt100Plus,
>TerminalTypeVtUtf8,
> -  TerminalTypeTtyTerm
> +  TerminalTypeTtyTerm,
> +  TerminalTypeLinux,
> +  TerminalTypeXtermR6,
> +  TerminalTypeVt400,
> +  TerminalTypeSCO
>  } TERMINAL_TYPE;
> 
>  typedef struct {
> @@ -126,7 +130,9 @@ typedef struct {
>  #define INPUT_STATE_LEFTOPENBRACKET   0x04
>  #define INPUT_STATE_O 0x08
>  #define INPUT_STATE_2 0x10
> -#define INPUT_STATE_LEFTOPENBRACKET_2 0x20
> +#define INPUT_STATE_LEFTOPENBRACKET_TTY   0x20
> +#define INPUT_STATE_1 0x40
> +#define INPUT_STATE_LEFTOPENBRACKET_2ND   0x80
> 
>  #define RESET_STATE_DEFAULT   0x00
>  #define RESET_STATE_ESC_R 0x01
> @@ -848,7 +854,8 @@ TerminalRemoveConsoleDevVariable (
>  /**
>Build termial device path according to terminal type.
> 
> -  @param  TerminalType   The terminal type is PC ANSI, VT100, VT100+ 
> or
> VT-UTF8.
> +  @param  TerminalType   The terminal type is PC ANSI, VT100, VT100+,
> VT-UTF8, TTY-Term,
> + Linux, XtermR6 or VT400.
>@param  ParentDevicePath   Parent device path.
>@param  TerminalDevicePath Returned terminal device path, if building
> successfully.
> 
> @@ -1209,6 +1216,28 @@ AnsiRawDataToUnicode (
>| F12 | 0x16 |   | ESC @|  |
>+=+==+===+==+==+
> 
> +Putty function key map:
> +
> 

Re: [edk2-devel] [Patch] MdeModulePkg SerialDxe.inf: Fix wrong FILE_GUID format

[Liming Gao]

Push @9790f62be1aa5ee9460d4c4ec8c720919523bb62

>-Original Message-
>From: Wu, Hao A
>Sent: Tuesday, September 17, 2019 2:49 PM
>To: Gao, Liming ; devel@edk2.groups.io
>Cc: Ni, Ray 
>Subject: RE: [Patch] MdeModulePkg SerialDxe.inf: Fix wrong FILE_GUID
>format
>
>> -Original Message-
>> From: Gao, Liming
>> Sent: Tuesday, September 17, 2019 2:47 PM
>> To: devel@edk2.groups.io
>> Cc: Wu, Hao A; Ni, Ray
>> Subject: [Patch] MdeModulePkg SerialDxe.inf: Fix wrong FILE_GUID format
>>
>> Fix regression issue caused by
>> 0d85e67714e31e0dbe4241ab2ebb7c423aba174d
>>
>> Cc: Hao A Wu 
>> Cc: Ray Ni 
>> Signed-off-by: Liming Gao 
>> ---
>>  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>> b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>> index ab5e045ead..9337440c73 100644
>> --- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>> @@ -11,7 +11,7 @@
>>INF_VERSION= 0x00010005
>>BASE_NAME  = SerialDxe
>>MODULE_UNI_FILE= SerialDxe.uni
>> -  FILE_GUID  = 3bd86846-4ad0-4e94-81e6-9ea34cd34cxb
>> +  FILE_GUID  = 9A5163E7-5C29-453F-825C-837A46A81E15
>
>
>Reviewed-by: Hao A Wu 
>
>Best Regards,
>Hao Wu
>
>
>>MODULE_TYPE= DXE_DRIVER
>>VERSION_STRING = 1.0
>>
>> --
>> 2.13.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47354): https://edk2.groups.io/g/devel/message/47354
Mute This Topic: https://groups.io/mt/34173632/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-