[edk2] [PATCH] Nt32Pkg: Use Shell source code directly

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
---
 Nt32Pkg/Nt32Pkg.dsc | 20 +++-
 Nt32Pkg/Nt32Pkg.fdf |  2 +-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc
index 8927dcd..fa3446b 100644
--- a/Nt32Pkg/Nt32Pkg.dsc
+++ b/Nt32Pkg/Nt32Pkg.dsc
@@ -115,7 +115,7 @@ [LibraryClasses]
   
CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
   PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
-  SortLib|MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
+  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
   #
   # UEFI & PI
   #
@@ -522,6 +522,24 @@ [Components]
   
NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
   }
   MdeModulePkg/Logo/LogoDxe.inf
+  ShellPkg/Application/Shell/Shell.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+
+  
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
+  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
+  
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
+  
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
+  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
+  }
 
 
###
 #
diff --git a/Nt32Pkg/Nt32Pkg.fdf b/Nt32Pkg/Nt32Pkg.fdf
index 282e59c..ffa4b0a 100644
--- a/Nt32Pkg/Nt32Pkg.fdf
+++ b/Nt32Pkg/Nt32Pkg.fdf
@@ -289,7 +289,7 @@ [FV.FvRecovery]
 #
 

 !ifndef $(USE_OLD_SHELL)
-INF  ShellBinPkg/UefiShell/UefiShell.inf
+INF  ShellPkg/Application/Shell/Shell.inf
 !else
 INF  EdkShellBinPkg/FullShell/FullShell.inf
 !endif
-- 
2.9.0.windows.1

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

[edk2] [PATCH v2] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for Ip4Config2

[Jiaxin Wu]

v2:
* Add the check in Ip4Config2SetDefaultIf to avoid the DHCP configuration
case.

Ip4config2 doesn't check the validity of Ip/Netmask pair, which
leads to the invalid combination of Ip and Netmask setting.
This patch is to resolve the issue.

Cc: Hegde Nagaraj P 
Cc: Subramanian Sriram 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c  | 62 +-
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h  | 21 +++-
 .../Universal/Network/Ip4Dxe/Ip4Config2Impl.c  | 12 -
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4If.c  |  8 +--
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c| 62 +-
 5 files changed, 94 insertions(+), 71 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
index 004a8bc..7c7d182 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
@@ -1,8 +1,8 @@
 /** @file
 
-Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
 http://opensource.org/licenses/bsd-license.php
 
@@ -265,5 +265,65 @@ Ip4NtohHead (
   Head->Src   = NTOHL (Head->Src);
   Head->Dst   = NTOHL (Head->Dst);
 
   return Head;
 }
+
+
+/**
+  Validate that Ip/Netmask pair is OK to be used as station
+  address. Only continuous netmasks are supported. and check
+  that StationAddress is a unicast address on the newtwork.
+
+  @param[in]  Ip The IP address to validate.
+  @param[in]  NetmaskThe netmaks of the IP.
+
+  @retval TRUE   The Ip/Netmask pair is valid.
+  @retval FALSE  The Ip/Netmask pair is invalid.
+
+**/
+BOOLEAN
+Ip4StationAddressValid (
+  IN IP4_ADDR   Ip,
+  IN IP4_ADDR   Netmask
+  )
+{
+  IP4_ADDR  NetBrdcastMask;
+  INTN  Len;
+  INTN  Type;
+
+  //
+  // Only support the station address with 0.0.0.0/0 to enable DHCP client.
+  //
+  if (Netmask == IP4_ALLZERO_ADDRESS) {
+return (BOOLEAN) (Ip == IP4_ALLZERO_ADDRESS);
+  }
+
+  //
+  // Only support the continuous net masks
+  //
+  if ((Len = NetGetMaskLength (Netmask)) == (IP4_MASK_MAX + 1)) {
+return FALSE;
+  }
+
+  //
+  // Station address can't be class D or class E address
+  //
+  if ((Type = NetGetIpClass (Ip)) > IP4_ADDR_CLASSC) {
+return FALSE;
+  }
+
+  //
+  // Station address can't be subnet broadcast/net broadcast address
+  //
+  if ((Ip == (Ip & Netmask)) || (Ip == (Ip | ~Netmask))) {
+return FALSE;
+  }
+
+  NetBrdcastMask = gIp4AllMasks[MIN (Len, Type << 3)];
+
+  if (Ip == (Ip | ~NetBrdcastMask)) {
+return FALSE;
+  }
+
+  return TRUE;
+}
\ No newline at end of file
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
index d38857c..9689f37 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
@@ -1,9 +1,9 @@
 /** @file
   Common definition for IP4.
   
-Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
 http://opensource.org/licenses/bsd-license.php
 
@@ -199,6 +199,25 @@ Ip4GetMulticastMac (
 IP4_HEAD *
 Ip4NtohHead (
   IN IP4_HEAD   *Head
   );
 
+
+/**
+  Validate that Ip/Netmask pair is OK to be used as station
+  address. Only continuous netmasks are supported. and check
+  that StationAddress is a unicast address on the newtwork.
+
+  @param[in]  Ip The IP address to validate.
+  @param[in]  NetmaskThe netmaks of the IP.
+
+  @retval TRUE   The Ip/Netmask pair is valid.
+  @retval FALSE  The Ip/Netmask pair is invalid.
+
+**/
+BOOLEAN
+Ip4StationAddressValid (
+  IN IP4_ADDR   Ip,
+  IN IP4_ADDR   Netmask
+  );
+
 #endif
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index 6c7ac68..f4dfbb6 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -607,10 +607,17 @@ Ip4Config2SetDefaultIf (
   EFI_STATUS

Re: [edk2] [PATCH V2] MdeModulePkg: Fix service binding issue in TCP4 and Ip4 dxe.

[Zhang, Lubo]

Go it, thanks for your comments

Best Regards
Lubo 

-Original Message-
From: Ye, Ting 
Sent: Thursday, March 16, 2017 1:31 PM
To: Zhang, Lubo ; edk2-devel@lists.01.org
Cc: Wu, Jiaxin ; Fu, Siyuan 
Subject: RE: [PATCH V2] MdeModulePkg: Fix service binding issue in TCP4 and Ip4 
dxe.

Hi Lubo,

Please update the comment for IP4_STATE_DESTROY in Ip4Impl.h and other possible 
places, since the patch removed the value. 
Also update CopyRight year in SockImpl.h before check-in. Others are good to me.

Reviewed-by: Ye Ting 

Best Regards,
Ting


-Original Message-
From: Zhang, Lubo 
Sent: Wednesday, March 15, 2017 10:28 AM
To: edk2-devel@lists.01.org
Cc: Wu, Jiaxin ; Ye, Ting ; Fu, Siyuan 

Subject: [PATCH V2] MdeModulePkg: Fix service binding issue in TCP4 and Ip4 dxe.

v2: Handle error case in SockCreateChild and fix typo issue

when we destroy the socket Sock and its associated protocol control block, we 
need to first close the parent protocol, then remove the protocol from 
childHandle and last to free any data structures that allocated in CreateChild. 
But currently, we free the socket data (Socket ConfigureState) before removing 
the protocol form  the childhandle. So if the up layer want to send the tcp 
reset packet in it's driver binding stop function, it will failed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Fu Siyuan 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c  | 10 +--
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c|  3 +-
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h|  5 +-
 MdeModulePkg/Universal/Network/Tcp4Dxe/SockImpl.c  | 48 +---  
MdeModulePkg/Universal/Network/Tcp4Dxe/SockImpl.h  |  3 +-
 .../Universal/Network/Tcp4Dxe/SockInterface.c  | 88 --
 .../Universal/Network/Tcp4Dxe/Tcp4Dispatcher.c | 12 +--
 7 files changed, 95 insertions(+), 74 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
index 642e453..792db5c 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
@@ -1,9 +1,9 @@
 /** @file
   The driver binding and service binding protocol for IP4 driver.
 
-Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
 
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -920,11 +920,10 
@@ Ip4ServiceBindingDestroyChild (
   EFI_STATUSStatus;
   IP4_SERVICE   *IpSb;
   IP4_PROTOCOL  *IpInstance;
   EFI_IP4_PROTOCOL  *Ip4;
   EFI_TPL   OldTpl;
-  INTN  State;
 
   if ((This == NULL) || (ChildHandle == NULL)) {
 return EFI_INVALID_PARAMETER;
   }
 
@@ -958,17 +957,16 @@ Ip4ServiceBindingDestroyChild (
   // A child can be destroyed more than once. For example,
   // Ip4DriverBindingStop will destroy all of its children.
   // when UDP driver is being stopped, it will destroy all
   // the IP child it opens.
   //
-  if (IpInstance->State == IP4_STATE_DESTROY) {
+  if (IpInstance->InDestroy) {
 gBS->RestoreTPL (OldTpl);
 return EFI_SUCCESS;
   }
 
-  State = IpInstance->State;
-  IpInstance->State = IP4_STATE_DESTROY;
+  IpInstance->InDestroy = TRUE;
 
   //
   // Close the Managed Network protocol.
   //
   gBS->CloseProtocol (
@@ -1007,10 +1005,11 @@ Ip4ServiceBindingDestroyChild (
   ,
   >Ip4Proto
   );
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
   if (EFI_ERROR (Status)) {
+IpInstance->InDestroy = FALSE;
 goto ON_ERROR;
   }
 
   Status = Ip4CleanProtocol (IpInstance);
   if (EFI_ERROR (Status)) {
@@ -1031,10 +1030,9 @@ Ip4ServiceBindingDestroyChild (
 
   FreePool (IpInstance);
   return EFI_SUCCESS;
 
 ON_ERROR:
-  IpInstance->State = State;
   gBS->RestoreTPL (OldTpl);
 
   return Status;
 }
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
index 91f1a67..23690ff 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
@@ -1,8 +1,8 @@
 /** @file
 
-Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD 

Re: [edk2] [PATCH v2] ShellPkg/HandleParsingLib: Correct format specifier for LoadedImage

[Ni, Ruiyu]

I will do that.

Thanks/Ray

> -Original Message-
> From: Carsey, Jaben
> Sent: Thursday, March 16, 2017 6:28 AM
> To: Jeff Westfahl 
> Cc: edk2-devel@lists.01.org; Ni, Ruiyu ; Carsey, Jaben
> 
> Subject: RE: [PATCH v2] ShellPkg/HandleParsingLib: Correct format specifier
> for LoadedImage
> 
> I was unsure if printing the hex address of the load options was useful
> (useful enough?).
> 
> I know for some images it was nice to get the load options printed as a string
> since they are command line parameters. I guess that might be more focused
> on learning about the shell itself and how it was launched than other images.
> Hence my question.
> 
> I am good with this patch.
> 
> Ray can you review and push it if you agree?
> 
> -Jaben
> 
> > -Original Message-
> > From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
> > Sent: Wednesday, March 15, 2017 2:09 PM
> > To: Carsey, Jaben 
> > Cc: Jeff Westfahl ; edk2-devel@lists.01.org; Ni,
> > Ruiyu 
> > Subject: RE: [PATCH v2] ShellPkg/HandleParsingLib: Correct format
> > specifier for LoadedImage
> > Importance: High
> >
> > Jaben,
> >
> > I think the output looks good with the udpated format. All of the
> > output values are aligned, and it prints the hex address of the load
> > options, just like it prints the hex address of the image address right 
> > below.
> >
> > Regards,
> > Jeff
> >
> > On Wed, 15 Mar 2017, Carsey, Jaben wrote:
> >
> > > Does the print call need to be updated to print this out properly?
> > >
> > > -Jaben
> > >
> > >> -Original Message-
> > >> From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
> > >> Sent: Tuesday, March 14, 2017 2:02 PM
> > >> To: edk2-devel@lists.01.org
> > >> Cc: Jeff Westfahl ; Ni, Ruiyu
> > ;
> > >> Carsey, Jaben 
> > >> Subject: [PATCH v2] ShellPkg/HandleParsingLib: Correct format
> > >> specifier
> > for
> > >> LoadedImage
> > >> Importance: High
> > >>
> > >> The format specifier for the LoadOptions field of the LoadedImage
> > protocol
> > >> is "%s". However, the data in LoadOptions is often generic binary
> > >> data. A format specifier of "%x" is more appropriate for this field.
> > >>
> > >> Using "dh -v" with format specifier "%s" on BIOS images based on
> > >> EDK II source before commit 891d844 can cause a crash.
> > >>
> > >> Cc: Ruiyu Ni 
> > >> Cc: Jaben Carsey 
> > >> Contributed-under: TianoCore Contribution Agreement 1.0
> > >> Signed-off-by: Jeff Westfahl 
> > >> ---
> > >>  ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni | 2
> > >> +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git
> > a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> > >> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> > >> index 0d51627..273a420 100644
> > >> ---
> > >> a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> > >> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.un
> > >> +++ i
> > >> @@ -354,7 +354,7 @@
> > >>" DeviceHandle..: 
> > >> %%H%x%%N\r\n"
> > >>" FilePath..: 
> > >> %%H%x%%N\r\n"
> > >>" OptionsSize...: 
> > >> %%H%x%%N\r\n"
> > >> -  " LoadOptions...: 
> > >> %%H%s%%N\r\n"
> > >> +  " LoadOptions...: 
> > >> %%H%x%%N\r\n"
> > >>" ImageBase.: 
> > >> %%H%x%%N\r\n"
> > >>" ImageSize.: 
> > >> %%H%Lx%%N\r\n"
> > >>" CodeType..: 
> > >> %%H%s%%N\r\n"
> > >> --
> > >> 2.7.4
> > >
> > >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V2] MdeModulePkg: Fix service binding issue in TCP4 and Ip4 dxe.

[Ye, Ting]

Hi Lubo,

Please update the comment for IP4_STATE_DESTROY in Ip4Impl.h and other possible 
places, since the patch removed the value. 
Also update CopyRight year in SockImpl.h before check-in. Others are good to me.

Reviewed-by: Ye Ting 

Best Regards,
Ting


-Original Message-
From: Zhang, Lubo 
Sent: Wednesday, March 15, 2017 10:28 AM
To: edk2-devel@lists.01.org
Cc: Wu, Jiaxin ; Ye, Ting ; Fu, Siyuan 

Subject: [PATCH V2] MdeModulePkg: Fix service binding issue in TCP4 and Ip4 dxe.

v2: Handle error case in SockCreateChild and fix typo issue

when we destroy the socket Sock and its associated protocol control block, we 
need to first close the parent protocol, then remove the protocol from 
childHandle and last to free any data structures that allocated in CreateChild. 
But currently, we free the socket data (Socket ConfigureState) before removing 
the protocol form  the childhandle. So if the up layer want to send the tcp 
reset packet in it's driver binding stop function, it will failed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Fu Siyuan 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c  | 10 +--
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c|  3 +-
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h|  5 +-
 MdeModulePkg/Universal/Network/Tcp4Dxe/SockImpl.c  | 48 +---  
MdeModulePkg/Universal/Network/Tcp4Dxe/SockImpl.h  |  3 +-
 .../Universal/Network/Tcp4Dxe/SockInterface.c  | 88 --
 .../Universal/Network/Tcp4Dxe/Tcp4Dispatcher.c | 12 +--
 7 files changed, 95 insertions(+), 74 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
index 642e453..792db5c 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
@@ -1,9 +1,9 @@
 /** @file
   The driver binding and service binding protocol for IP4 driver.
 
-Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
 
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -920,11 +920,10 
@@ Ip4ServiceBindingDestroyChild (
   EFI_STATUSStatus;
   IP4_SERVICE   *IpSb;
   IP4_PROTOCOL  *IpInstance;
   EFI_IP4_PROTOCOL  *Ip4;
   EFI_TPL   OldTpl;
-  INTN  State;
 
   if ((This == NULL) || (ChildHandle == NULL)) {
 return EFI_INVALID_PARAMETER;
   }
 
@@ -958,17 +957,16 @@ Ip4ServiceBindingDestroyChild (
   // A child can be destroyed more than once. For example,
   // Ip4DriverBindingStop will destroy all of its children.
   // when UDP driver is being stopped, it will destroy all
   // the IP child it opens.
   //
-  if (IpInstance->State == IP4_STATE_DESTROY) {
+  if (IpInstance->InDestroy) {
 gBS->RestoreTPL (OldTpl);
 return EFI_SUCCESS;
   }
 
-  State = IpInstance->State;
-  IpInstance->State = IP4_STATE_DESTROY;
+  IpInstance->InDestroy = TRUE;
 
   //
   // Close the Managed Network protocol.
   //
   gBS->CloseProtocol (
@@ -1007,10 +1005,11 @@ Ip4ServiceBindingDestroyChild (
   ,
   >Ip4Proto
   );
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
   if (EFI_ERROR (Status)) {
+IpInstance->InDestroy = FALSE;
 goto ON_ERROR;
   }
 
   Status = Ip4CleanProtocol (IpInstance);
   if (EFI_ERROR (Status)) {
@@ -1031,10 +1030,9 @@ Ip4ServiceBindingDestroyChild (
 
   FreePool (IpInstance);
   return EFI_SUCCESS;
 
 ON_ERROR:
-  IpInstance->State = State;
   gBS->RestoreTPL (OldTpl);
 
   return Status;
 }
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
index 91f1a67..23690ff 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
@@ -1,8 +1,8 @@
 /** @file
 
-Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at  
http://opensource.org/licenses/bsd-license.php
 
@@ -548,10 +548,11 @@ Ip4InitProtocol (
   ZeroMem (IpInstance, sizeof (IP4_PROTOCOL));
 
   IpInstance->Signature = IP4_PROTOCOL_SIGNATURE;
   CopyMem (>Ip4Proto, , sizeof 
(IpInstance->Ip4Proto));
   

Re: [edk2] [PATCH V2] NetworkPkg: Fix service binding issue in TCP dxe.

[Ye, Ting]

Reviewed-by: Ye Ting  


-Original Message-
From: Zhang, Lubo 
Sent: Wednesday, March 15, 2017 10:28 AM
To: edk2-devel@lists.01.org
Cc: Wu, Jiaxin ; Ye, Ting ; Fu, Siyuan 

Subject: [PATCH V2] NetworkPkg: Fix service binding issue in TCP dxe.

v2: Handle error case in SockCreateChild and fix typo issue

when we destroy the socket Sock and its associated protocol control block, we 
need to first close the parent protocol, then remove the protocol from 
childHandle and last to free any data structures that allocated in CreateChild. 
But currently, we free the socket data (Socket ConfigureState) before removing 
the protocol form  the childhandle. So if the up layer perform the driverbing 
stop to abort tcp session and send the tcp reset packet, it will failed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Fu Siyuan 
---
 NetworkPkg/TcpDxe/SockImpl.c  |  56 +---
 NetworkPkg/TcpDxe/SockImpl.h  |   3 +-
 NetworkPkg/TcpDxe/SockInterface.c | 108 +++---
 NetworkPkg/TcpDxe/TcpDispatcher.c |  19 +--
 4 files changed, 104 insertions(+), 82 deletions(-)

diff --git a/NetworkPkg/TcpDxe/SockImpl.c b/NetworkPkg/TcpDxe/SockImpl.c index 
4eb42fb..c5fb176 100644
--- a/NetworkPkg/TcpDxe/SockImpl.c
+++ b/NetworkPkg/TcpDxe/SockImpl.c
@@ -1,9 +1,9 @@
 /** @file
   Implementation of the Socket.
 
-  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2017, Intel Corporation. All rights 
+ reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
   http://opensource.org/licenses/bsd-license.php.
@@ -826,20 +826,12 @@ OnError:
 VOID
 SockDestroy (
   IN OUT SOCKET *Sock
   )
 {
-  VOID*SockProtocol;
-  EFI_GUID*TcpProtocolGuid;
-  EFI_STATUS  Status;
-
   ASSERT (SockStream == Sock->Type);
 
-  if (Sock->DestroyCallback != NULL) {
-Sock->DestroyCallback (Sock, Sock->Context);
-  }
-
   //
   // Flush the completion token buffered
   // by sock and rcv, snd buffer
   //
   if (!SOCK_IS_UNCONFIGURED (Sock)) {
@@ -870,56 +862,10 @@ SockDestroy (
   );
 
 Sock->Parent = NULL;
   }
 
-  //
-  // Set the protocol guid and driver binding handle
-  // in the light of Sock->SockType
-  //
-  if (Sock->IpVersion == IP_VERSION_4) {
-TcpProtocolGuid = 
-  } else {
-TcpProtocolGuid = 
-  }
-
-  //
-  // Retrieve the protocol installed on this sock
-  //
-  Status = gBS->OpenProtocol (
-  Sock->SockHandle,
-  TcpProtocolGuid,
-  ,
-  Sock->DriverBinding,
-  Sock->SockHandle,
-  EFI_OPEN_PROTOCOL_GET_PROTOCOL
-  );
-
-  if (EFI_ERROR (Status)) {
-
-DEBUG (
-  (EFI_D_ERROR,
-  "SockDestroy: Open protocol installed on socket failed with %r\n",
-  Status)
-  );
-
-goto FreeSock;
-  }
-
-  //
-  // Uninstall the protocol installed on this sock
-  // in the light of Sock->SockType
-  //
-  gBS->UninstallMultipleProtocolInterfaces (
-Sock->SockHandle,
-TcpProtocolGuid,
-SockProtocol,
-NULL
-);
-
-FreeSock:
-
   FreePool (Sock);
 }
 
 /**
   Flush the sndBuffer and rcvBuffer of socket.
diff --git a/NetworkPkg/TcpDxe/SockImpl.h b/NetworkPkg/TcpDxe/SockImpl.h index 
5a067de..80692b1 100644
--- a/NetworkPkg/TcpDxe/SockImpl.h
+++ b/NetworkPkg/TcpDxe/SockImpl.h
@@ -1,9 +1,9 @@
 /** @file
   The function declaration that provided for Socket Interface.
 
-  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2017, Intel Corporation. All rights 
+ reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
   http://opensource.org/licenses/bsd-license.php.
@@ -15,10 +15,11 @@
 
 #ifndef _SOCK_IMPL_H_
 #define _SOCK_IMPL_H_
 
 #include "Socket.h"
+#include "TcpMain.h"
 
 /**
   Signal a event with the given status.
 
   @param[in] TokenThe token's event is to be signaled.
diff --git a/NetworkPkg/TcpDxe/SockInterface.c 
b/NetworkPkg/TcpDxe/SockInterface.c
index 21ce643..b4ba40a 100644
--- a/NetworkPkg/TcpDxe/SockInterface.c
+++ b/NetworkPkg/TcpDxe/SockInterface.c
@@ -1,9 +1,9 @@
 /** @file
   Interface function of the Socket.
 
-  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2017, Intel Corporation. All rights 
+ reserved.
 
   This program and the accompanying materials
   are licensed and 

Re: [edk2] [Patch] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for Ip4Config2

[Wu, Jiaxin]

Nagaraj,

You are right, but I'd like to update the patch to check it in 
Ip4Config2SetDefaultIf instead of Ip4SetAddress to avoid the previous interface 
free operation. After that, the  check in Ip4SetAddress is needless. 

Thanks,
Jiaxin


> -Original Message-
> From: Hegde, Nagaraj P [mailto:nagaraj-p.he...@hpe.com]
> Sent: Thursday, March 16, 2017 12:40 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan 
> Subject: RE: [Patch] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for
> Ip4Config2
> 
> We need to handle the case of DHCP server serving with a subnet of  0.0.0.0.
> When we set the Policy to Dhcp, we enter into Ip4Config2OnPolicyChanged,
> which calls Ip4StartAutoConfig. Here we configure DHCP and we queue up
> Ip4Config2OnDhcp4Complete to be called once DHCP is complete. In
> Ip4Config2OnDhcp4Complete, we call Ip4Config2SetDefaultIf, which calls
> Ip4Config2SetDefaultAddr, where we call Ip4SetAddress. Ip4SetAddress has
> a similar check as Ip4Config2SetMaunualAddress:
> 
>   Len = NetGetMaskLength (SubnetMask);
>   if (Len == IP4_MASK_NUM) {
> return EFI_INVALID_PARAMETER;
>   }
> 
> Shouldn't this also be updated?
> 
> Regards,
> Nagaraj.
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Hegde, Nagaraj P
> Sent: Thursday, March 16, 2017 8:43 AM
> To: Jiaxin Wu ; edk2-devel@lists.01.org
> Cc: Ye Ting ; Fu Siyuan 
> Subject: Re: [edk2] [Patch] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair
> check for Ip4Config2
> 
> Reviewed-by: Hegde, Nagaraj P 
> 
> -Original Message-
> From: Jiaxin Wu [mailto:jiaxin...@intel.com]
> Sent: Thursday, March 16, 2017 7:11 AM
> To: edk2-devel@lists.01.org
> Cc: Hegde, Nagaraj P ; Subramanian, Sriram
> ; Ye Ting ; Fu Siyuan
> ; Wu Jiaxin 
> Subject: [Patch] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for
> Ip4Config2
> 
> Ip4config2 manual address setting doesn't check the validity of Ip/Netmask
> pair, which leads to the invalid combination of Ip and Netmask setting. This
> patch is to resolve this issue.
> 
> Cc: Hegde Nagaraj P 
> Cc: Subramanian Sriram 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wu Jiaxin 
> ---
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c  | 62
> +-
> MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h  | 21 +++-
>  .../Universal/Network/Ip4Dxe/Ip4Config2Impl.c  |  5 +-
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c| 62 +-
> 
>  4 files changed, 86 insertions(+), 64 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
> index 004a8bc..7c7d182 100644
> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
> @@ -1,8 +1,8 @@
>  /** @file
> 
> -Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
> +Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials  are licensed and made
> available under the terms and conditions of the BSD License  which
> accompanies this distribution.  The full text of the license may be found at
> http://opensource.org/licenses/bsd-license.php
> 
> @@ -265,5 +265,65 @@ Ip4NtohHead (
>Head->Src   = NTOHL (Head->Src);
>Head->Dst   = NTOHL (Head->Dst);
> 
>return Head;
>  }
> +
> +
> +/**
> +  Validate that Ip/Netmask pair is OK to be used as station
> +  address. Only continuous netmasks are supported. and check
> +  that StationAddress is a unicast address on the newtwork.
> +
> +  @param[in]  Ip The IP address to validate.
> +  @param[in]  NetmaskThe netmaks of the IP.
> +
> +  @retval TRUE   The Ip/Netmask pair is valid.
> +  @retval FALSE  The Ip/Netmask pair is invalid.
> +
> +**/
> +BOOLEAN
> +Ip4StationAddressValid (
> +  IN IP4_ADDR   Ip,
> +  IN IP4_ADDR   Netmask
> +  )
> +{
> +  IP4_ADDR  NetBrdcastMask;
> +  INTN  Len;
> +  INTN  Type;
> +
> +  //
> +  // Only support the station address with 0.0.0.0/0 to enable DHCP client.
> +  //
> +  if (Netmask == IP4_ALLZERO_ADDRESS) {
> +return (BOOLEAN) (Ip == IP4_ALLZERO_ADDRESS);  }
> +
> +  //
> +  // Only support the continuous net masks  //  if ((Len =
> + NetGetMaskLength (Netmask)) == (IP4_MASK_MAX + 1)) {
> +return FALSE;
> +  }
> +
> +  //
> +  // Station address can't be class D or class E address  //  if ((Type
> + = 

[edk2] [PATCH] MdeModulePkg/ConPlatform: Support GOP created as PCI's grandson

[Ruiyu Ni]

The original logic assumes GOP hande is son of PCI handle but it
is not always true.
Below wordings are from UEFI Spec:
If a graphics device supports multiple frame buffers, then
handles for the frame buffers must be created first, and then the
handles for the video output devices can be created as children of
the frame buffer handles.

So the GOP handle could be grandson of the PCI handle.

EfiBootManagerGetGopDevicePath(VideoController) is used to fix
this bug.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 .../Universal/Console/ConPlatformDxe/ConPlatform.c | 44 +++---
 .../Universal/Console/ConPlatformDxe/ConPlatform.h |  3 +-
 .../Console/ConPlatformDxe/ConPlatformDxe.inf  |  3 +-
 3 files changed, 9 insertions(+), 41 deletions(-)

diff --git a/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.c 
b/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.c
index 1ee8acf..6b53e8a 100644
--- a/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.c
+++ b/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.c
@@ -2,7 +2,7 @@
   Console Platform DXE Driver, install Console Device Guids and update Console
   Environment Variables.
 
-Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -1094,10 +1094,6 @@ ConPlatformUpdateGopCandidate (
   EFI_STATUS   Status;
   EFI_HANDLE   PciHandle;
   EFI_HANDLE   GopHandle;
-  EFI_OPEN_PROTOCOL_INFORMATION_ENTRY  *OpenInfoBuffer;
-  UINTNEntryCount;
-  UINTNIndex;
-  EFI_DEVICE_PATH_PROTOCOL *ChildDevicePath;
   EFI_DEVICE_PATH_PROTOCOL *TempDevicePath;
 
   //
@@ -1115,40 +,10 @@ ConPlatformUpdateGopCandidate (
   if (EFI_ERROR (Status)) {
 return FALSE;
   }
-
-  Status = gBS->OpenProtocolInformation (
-  PciHandle,
-  ,
-  ,
-  
-  );
-  if (EFI_ERROR (Status)) {
-return FALSE;
-  }
-
-  for (Index = 0; Index < EntryCount; Index++) {
-//
-// Query all the children created by the GOP driver
-//
-if ((OpenInfoBuffer[Index].Attributes & 
EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER) != 0) {
-  Status = gBS->OpenProtocol (
-  OpenInfoBuffer[Index].ControllerHandle,
-  ,
-  (VOID **) ,
-  NULL,
-  NULL,
-  EFI_OPEN_PROTOCOL_GET_PROTOCOL
-  );
-  if (!EFI_ERROR (Status)) {
-//
-// Append the device path to ConOutDev and ErrOutDev
-//
-ConPlatformUpdateDeviceVariable (L"ConOutDev", ChildDevicePath, 
Append);
-ConPlatformUpdateDeviceVariable (L"ErrOutDev", ChildDevicePath, 
Append);
-  }
-}
+  TempDevicePath = EfiBootManagerGetGopDevicePath (PciHandle);
+  if (TempDevicePath != NULL) {
+ConPlatformUpdateDeviceVariable (L"ConOutDev", TempDevicePath, Append);
+ConPlatformUpdateDeviceVariable (L"ErrOutDev", TempDevicePath, Append);
   }
-  FreePool (OpenInfoBuffer);
-
   return TRUE;
 }
diff --git a/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.h 
b/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.h
index 4b88e97..6d853c1 100644
--- a/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.h
+++ b/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for Console Platfrom DXE Driver.
 
-Copyright (c) 2006 - 2011, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -36,6 +36,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 
 //
 // Driver Binding Externs
diff --git a/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf 
b/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
index de66b46..1d404df 100644
--- a/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
+++ b/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
@@ -4,7 +4,7 @@
 # Console Platfrom DXE Driver that specifies whether device can be used as 
console
 # input/output device or error output device and update global variables 
accordingly.
 #
-# Copyright (c) 2006 - 

Re: [edk2] [patch] OvmfPkg/QemuFwCfgS3Lib: Fix VS tool chain build failure

[Jordan Justen]

Reviewed-by: Jordan Justen 

Pushed as 08bed3fbac. Thanks!

On 2017-03-15 18:25:52, Dandan Bi wrote:
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  OvmfPkg/Include/Library/QemuFwCfgS3Lib.h| 10 +-
>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c|  3 ++-
>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c |  8 
>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Dxe.c | 10 +-
>  OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Pei.c |  2 +-
>  5 files changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/OvmfPkg/Include/Library/QemuFwCfgS3Lib.h 
> b/OvmfPkg/Include/Library/QemuFwCfgS3Lib.h
> index 76c8554..432e3c9 100644
> --- a/OvmfPkg/Include/Library/QemuFwCfgS3Lib.h
> +++ b/OvmfPkg/Include/Library/QemuFwCfgS3Lib.h
> @@ -153,12 +153,12 @@ VOID (EFIAPI FW_CFG_BOOT_SCRIPT_CALLBACK_FUNCTION) (
> QemuFwCfgS3CallWhenBootScriptReady() 
> cannot
> be rolled back.
>  
>@return  Error codes from underlying functions.
>  **/
> -EFIAPI
>  RETURN_STATUS
> +EFIAPI
>  QemuFwCfgS3CallWhenBootScriptReady (
>IN FW_CFG_BOOT_SCRIPT_CALLBACK_FUNCTION *Callback,
>IN OUT VOID *Context,  OPTIONAL
>IN UINTNScratchBufferSize
>);
> @@ -202,12 +202,12 @@ QemuFwCfgS3CallWhenBootScriptReady (
>@retval RETURN_BAD_BUFFER_SIZENumberOfBytes is larger than
>  ScratchBufferSize.
>  
>@return   Error codes from underlying functions.
>  **/
> -EFIAPI
>  RETURN_STATUS
> +EFIAPI
>  QemuFwCfgS3ScriptWriteBytes (
>IN INT32 FirmwareConfigItem,
>IN UINTN NumberOfBytes
>);
>  
> @@ -249,12 +249,12 @@ QemuFwCfgS3ScriptWriteBytes (
>@retval RETURN_BAD_BUFFER_SIZENumberOfBytes is larger than
>  ScratchBufferSize.
>  
>@return   Error codes from underlying functions.
>  **/
> -EFIAPI
>  RETURN_STATUS
> +EFIAPI
>  QemuFwCfgS3ScriptReadBytes (
>IN INT32 FirmwareConfigItem,
>IN UINTN NumberOfBytes
>);
>  
> @@ -289,12 +289,12 @@ QemuFwCfgS3ScriptReadBytes (
>  
>@retval RETURN_BAD_BUFFER_SIZENumberOfBytes is too large.
>  
>@return   Error codes from underlying functions.
>  **/
> -EFIAPI
>  RETURN_STATUS
> +EFIAPI
>  QemuFwCfgS3ScriptSkipBytes (
>IN INT32 FirmwareConfigItem,
>IN UINTN NumberOfBytes
>);
>  
> @@ -347,12 +347,12 @@ QemuFwCfgS3ScriptSkipBytes (
>  wholly contained in the ScratchBufferSize
>  bytes at ScratchBuffer.
>  
>@return   Error codes from underlying functions.
>  **/
> -EFIAPI
>  RETURN_STATUS
> +EFIAPI
>  QemuFwCfgS3ScriptCheckValue (
>IN VOID   *ScratchData,
>IN UINT8  ValueSize,
>IN UINT64 ValueMask,
>IN UINT64 Value
> diff --git a/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c 
> b/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c
> index 7b71305..7fa1200 100644
> --- a/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c
> +++ b/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c
> @@ -95,12 +95,13 @@ QemuFwCfgS3Enabled (
> QemuFwCfgS3CallWhenBootScriptReady() 
> cannot
> be rolled back.
>  
>@return  Error codes from underlying functions.
>  **/
> -EFIAPI
> +
>  RETURN_STATUS
> +EFIAPI
>  QemuFwCfgS3CallWhenBootScriptReady (
>IN FW_CFG_BOOT_SCRIPT_CALLBACK_FUNCTION *Callback,
>IN OUT VOID *Context,  OPTIONAL
>IN UINTNScratchBufferSize
>)
> diff --git a/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c 
> b/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c
> index 674929e..bdad448 100644
> --- a/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c
> +++ b/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c
> @@ -54,12 +54,12 @@
>@retval RETURN_BAD_BUFFER_SIZENumberOfBytes is larger than
>  ScratchBufferSize.
>  
>@return   Error codes from underlying functions.
>  **/
> -EFIAPI
>  RETURN_STATUS
> +EFIAPI
>  QemuFwCfgS3ScriptWriteBytes (
>IN INT32 FirmwareConfigItem,
>IN UINTN NumberOfBytes
>)
>  {
> @@ -105,12 +105,12 @@ QemuFwCfgS3ScriptWriteBytes (
>@retval RETURN_BAD_BUFFER_SIZENumberOfBytes is larger than
>  ScratchBufferSize.
>  
>@return   Error codes from underlying functions.
>  **/
> -EFIAPI
>  RETURN_STATUS
> +EFIAPI
>  

Re: [edk2] [Patch] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for Ip4Config2

[Hegde, Nagaraj P]

We need to handle the case of DHCP server serving with a subnet of  0.0.0.0. 
When we set the Policy to Dhcp, we enter into Ip4Config2OnPolicyChanged, which 
calls Ip4StartAutoConfig. Here we configure DHCP and we queue up 
Ip4Config2OnDhcp4Complete to be called once DHCP is complete. In 
Ip4Config2OnDhcp4Complete, we call Ip4Config2SetDefaultIf, which calls 
Ip4Config2SetDefaultAddr, where we call Ip4SetAddress. Ip4SetAddress has a 
similar check as Ip4Config2SetMaunualAddress:

  Len = NetGetMaskLength (SubnetMask);
  if (Len == IP4_MASK_NUM) {
return EFI_INVALID_PARAMETER;
  }

Shouldn't this also be updated? 

Regards,
Nagaraj.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hegde, 
Nagaraj P
Sent: Thursday, March 16, 2017 8:43 AM
To: Jiaxin Wu ; edk2-devel@lists.01.org
Cc: Ye Ting ; Fu Siyuan 
Subject: Re: [edk2] [Patch] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for 
Ip4Config2

Reviewed-by: Hegde, Nagaraj P 

-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com]
Sent: Thursday, March 16, 2017 7:11 AM
To: edk2-devel@lists.01.org
Cc: Hegde, Nagaraj P ; Subramanian, Sriram 
; Ye Ting ; Fu Siyuan 
; Wu Jiaxin 
Subject: [Patch] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for Ip4Config2

Ip4config2 manual address setting doesn't check the validity of Ip/Netmask 
pair, which leads to the invalid combination of Ip and Netmask setting. This 
patch is to resolve this issue.

Cc: Hegde Nagaraj P 
Cc: Subramanian Sriram 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c  | 62 +- 
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h  | 21 +++-
 .../Universal/Network/Ip4Dxe/Ip4Config2Impl.c  |  5 +-
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c| 62 +-
 4 files changed, 86 insertions(+), 64 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
index 004a8bc..7c7d182 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
@@ -1,8 +1,8 @@
 /** @file
 
-Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at  
http://opensource.org/licenses/bsd-license.php
 
@@ -265,5 +265,65 @@ Ip4NtohHead (
   Head->Src   = NTOHL (Head->Src);
   Head->Dst   = NTOHL (Head->Dst);
 
   return Head;
 }
+
+
+/**
+  Validate that Ip/Netmask pair is OK to be used as station
+  address. Only continuous netmasks are supported. and check
+  that StationAddress is a unicast address on the newtwork.
+
+  @param[in]  Ip The IP address to validate.
+  @param[in]  NetmaskThe netmaks of the IP.
+
+  @retval TRUE   The Ip/Netmask pair is valid.
+  @retval FALSE  The Ip/Netmask pair is invalid.
+
+**/
+BOOLEAN
+Ip4StationAddressValid (
+  IN IP4_ADDR   Ip,
+  IN IP4_ADDR   Netmask
+  )
+{
+  IP4_ADDR  NetBrdcastMask;
+  INTN  Len;
+  INTN  Type;
+
+  //
+  // Only support the station address with 0.0.0.0/0 to enable DHCP client.
+  //
+  if (Netmask == IP4_ALLZERO_ADDRESS) {
+return (BOOLEAN) (Ip == IP4_ALLZERO_ADDRESS);  }
+
+  //
+  // Only support the continuous net masks  //  if ((Len = 
+ NetGetMaskLength (Netmask)) == (IP4_MASK_MAX + 1)) {
+return FALSE;
+  }
+
+  //
+  // Station address can't be class D or class E address  //  if ((Type 
+ = NetGetIpClass (Ip)) > IP4_ADDR_CLASSC) {
+return FALSE;
+  }
+
+  //
+  // Station address can't be subnet broadcast/net broadcast address //  
+ if ((Ip == (Ip & Netmask)) || (Ip == (Ip | ~Netmask))) {
+return FALSE;
+  }
+
+  NetBrdcastMask = gIp4AllMasks[MIN (Len, Type << 3)];
+
+  if (Ip == (Ip | ~NetBrdcastMask)) {
+return FALSE;
+  }
+
+  return TRUE;
+}
\ No newline at end of file
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
index d38857c..9689f37 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
@@ -1,9 +1,9 @@
 /** @file
   Common definition for IP4.
   
-Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 

Re: [edk2] [PATCH V2] MdeModulePkg: Fix service binding issue in TCP4 and Ip4 dxe.

[Wu, Jiaxin]

For this patch, my comments as below:

1. The commit log should better cover the changes of Ip4Dxe but currently it's 
not. 

2. Intel Copyright in SockImpl.h  should be 2017, not 2007.

Other looks to me.

Reviewed-by: Wu Jiaxin 

Thanks,
Jiaxin


> -Original Message-
> From: Zhang, Lubo
> Sent: Wednesday, March 15, 2017 10:28 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Ye, Ting ; Fu,
> Siyuan 
> Subject: [PATCH V2] MdeModulePkg: Fix service binding issue in TCP4 and
> Ip4 dxe.
> 
> v2: Handle error case in SockCreateChild and fix typo issue
> 
> when we destroy the socket Sock and its associated
> protocol control block, we need to first close the
> parent protocol, then remove the protocol from childHandle
> and last to free any data structures that allocated in
> CreateChild. But currently, we free the socket data
> (Socket ConfigureState) before removing the protocol
> form  the childhandle. So if the up layer want to send the
> tcp reset packet in it's driver binding stop function, it will failed.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> Cc: Wu Jiaxin 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> ---
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c  | 10 +--
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c|  3 +-
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h|  5 +-
>  MdeModulePkg/Universal/Network/Tcp4Dxe/SockImpl.c  | 48 +---
>  MdeModulePkg/Universal/Network/Tcp4Dxe/SockImpl.h  |  3 +-
>  .../Universal/Network/Tcp4Dxe/SockInterface.c  | 88
> --
>  .../Universal/Network/Tcp4Dxe/Tcp4Dispatcher.c | 12 +--
>  7 files changed, 95 insertions(+), 74 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
> index 642e453..792db5c 100644
> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
> @@ -1,9 +1,9 @@
>  /** @file
>The driver binding and service binding protocol for IP4 driver.
> 
> -Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
> +Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
>  (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
> 
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be
> found at
> @@ -920,11 +920,10 @@ Ip4ServiceBindingDestroyChild (
>EFI_STATUSStatus;
>IP4_SERVICE   *IpSb;
>IP4_PROTOCOL  *IpInstance;
>EFI_IP4_PROTOCOL  *Ip4;
>EFI_TPL   OldTpl;
> -  INTN  State;
> 
>if ((This == NULL) || (ChildHandle == NULL)) {
>  return EFI_INVALID_PARAMETER;
>}
> 
> @@ -958,17 +957,16 @@ Ip4ServiceBindingDestroyChild (
>// A child can be destroyed more than once. For example,
>// Ip4DriverBindingStop will destroy all of its children.
>// when UDP driver is being stopped, it will destroy all
>// the IP child it opens.
>//
> -  if (IpInstance->State == IP4_STATE_DESTROY) {
> +  if (IpInstance->InDestroy) {
>  gBS->RestoreTPL (OldTpl);
>  return EFI_SUCCESS;
>}
> 
> -  State = IpInstance->State;
> -  IpInstance->State = IP4_STATE_DESTROY;
> +  IpInstance->InDestroy = TRUE;
> 
>//
>// Close the Managed Network protocol.
>//
>gBS->CloseProtocol (
> @@ -1007,10 +1005,11 @@ Ip4ServiceBindingDestroyChild (
>,
>>Ip4Proto
>);
>OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
>if (EFI_ERROR (Status)) {
> +IpInstance->InDestroy = FALSE;
>  goto ON_ERROR;
>}
> 
>Status = Ip4CleanProtocol (IpInstance);
>if (EFI_ERROR (Status)) {
> @@ -1031,10 +1030,9 @@ Ip4ServiceBindingDestroyChild (
> 
>FreePool (IpInstance);
>return EFI_SUCCESS;
> 
>  ON_ERROR:
> -  IpInstance->State = State;
>gBS->RestoreTPL (OldTpl);
> 
>return Status;
>  }
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> index 91f1a67..23690ff 100644
> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> @@ -1,8 +1,8 @@
>  /** @file
> 
> -Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
> +Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be
> found at
>  http://opensource.org/licenses/bsd-license.php
> 
> 

Re: [edk2] [PATCH V2] NetworkPkg: Fix service binding issue in TCP dxe.

[Wu, Jiaxin]

Reviewed-by: Wu Jiaxin 

Thanks,
Jiaxin

> -Original Message-
> From: Zhang, Lubo
> Sent: Wednesday, March 15, 2017 10:28 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Ye, Ting ; Fu,
> Siyuan 
> Subject: [PATCH V2] NetworkPkg: Fix service binding issue in TCP dxe.
> 
> v2: Handle error case in SockCreateChild and fix typo issue
> 
> when we destroy the socket Sock and its associated
> protocol control block, we need to first close the
> parent protocol, then remove the protocol from childHandle
> and last to free any data structures that allocated in
> CreateChild. But currently, we free the socket data (Socket ConfigureState)
> before removing the protocol form  the childhandle. So if the up layer
> perform the driverbing stop to abort tcp session and send the tcp reset
> packet, it will failed.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> Cc: Wu Jiaxin 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> ---
>  NetworkPkg/TcpDxe/SockImpl.c  |  56 +---
>  NetworkPkg/TcpDxe/SockImpl.h  |   3 +-
>  NetworkPkg/TcpDxe/SockInterface.c | 108
> +++---
>  NetworkPkg/TcpDxe/TcpDispatcher.c |  19 +--
>  4 files changed, 104 insertions(+), 82 deletions(-)
> 
> diff --git a/NetworkPkg/TcpDxe/SockImpl.c
> b/NetworkPkg/TcpDxe/SockImpl.c
> index 4eb42fb..c5fb176 100644
> --- a/NetworkPkg/TcpDxe/SockImpl.c
> +++ b/NetworkPkg/TcpDxe/SockImpl.c
> @@ -1,9 +1,9 @@
>  /** @file
>Implementation of the Socket.
> 
> -  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
> 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at
>http://opensource.org/licenses/bsd-license.php.
> @@ -826,20 +826,12 @@ OnError:
>  VOID
>  SockDestroy (
>IN OUT SOCKET *Sock
>)
>  {
> -  VOID*SockProtocol;
> -  EFI_GUID*TcpProtocolGuid;
> -  EFI_STATUS  Status;
> -
>ASSERT (SockStream == Sock->Type);
> 
> -  if (Sock->DestroyCallback != NULL) {
> -Sock->DestroyCallback (Sock, Sock->Context);
> -  }
> -
>//
>// Flush the completion token buffered
>// by sock and rcv, snd buffer
>//
>if (!SOCK_IS_UNCONFIGURED (Sock)) {
> @@ -870,56 +862,10 @@ SockDestroy (
>);
> 
>  Sock->Parent = NULL;
>}
> 
> -  //
> -  // Set the protocol guid and driver binding handle
> -  // in the light of Sock->SockType
> -  //
> -  if (Sock->IpVersion == IP_VERSION_4) {
> -TcpProtocolGuid = 
> -  } else {
> -TcpProtocolGuid = 
> -  }
> -
> -  //
> -  // Retrieve the protocol installed on this sock
> -  //
> -  Status = gBS->OpenProtocol (
> -  Sock->SockHandle,
> -  TcpProtocolGuid,
> -  ,
> -  Sock->DriverBinding,
> -  Sock->SockHandle,
> -  EFI_OPEN_PROTOCOL_GET_PROTOCOL
> -  );
> -
> -  if (EFI_ERROR (Status)) {
> -
> -DEBUG (
> -  (EFI_D_ERROR,
> -  "SockDestroy: Open protocol installed on socket failed with %r\n",
> -  Status)
> -  );
> -
> -goto FreeSock;
> -  }
> -
> -  //
> -  // Uninstall the protocol installed on this sock
> -  // in the light of Sock->SockType
> -  //
> -  gBS->UninstallMultipleProtocolInterfaces (
> -Sock->SockHandle,
> -TcpProtocolGuid,
> -SockProtocol,
> -NULL
> -);
> -
> -FreeSock:
> -
>FreePool (Sock);
>  }
> 
>  /**
>Flush the sndBuffer and rcvBuffer of socket.
> diff --git a/NetworkPkg/TcpDxe/SockImpl.h
> b/NetworkPkg/TcpDxe/SockImpl.h
> index 5a067de..80692b1 100644
> --- a/NetworkPkg/TcpDxe/SockImpl.h
> +++ b/NetworkPkg/TcpDxe/SockImpl.h
> @@ -1,9 +1,9 @@
>  /** @file
>The function declaration that provided for Socket Interface.
> 
> -  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
> 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at
>http://opensource.org/licenses/bsd-license.php.
> @@ -15,10 +15,11 @@
> 
>  #ifndef _SOCK_IMPL_H_
>  #define _SOCK_IMPL_H_
> 
>  #include "Socket.h"
> +#include "TcpMain.h"
> 
>  /**
>Signal a event with the given status.
> 
>@param[in] TokenThe token's event is to be signaled.
> diff --git a/NetworkPkg/TcpDxe/SockInterface.c
> b/NetworkPkg/TcpDxe/SockInterface.c
> index 21ce643..b4ba40a 100644
> --- a/NetworkPkg/TcpDxe/SockInterface.c
> +++ 

Re: [edk2] [Patch] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for Ip4Config2

[Hegde, Nagaraj P]

Reviewed-by: Hegde, Nagaraj P 

-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com] 
Sent: Thursday, March 16, 2017 7:11 AM
To: edk2-devel@lists.01.org
Cc: Hegde, Nagaraj P ; Subramanian, Sriram 
; Ye Ting ; Fu Siyuan 
; Wu Jiaxin 
Subject: [Patch] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for Ip4Config2

Ip4config2 manual address setting doesn't check the validity of Ip/Netmask 
pair, which leads to the invalid combination of Ip and Netmask setting. This 
patch is to resolve this issue.

Cc: Hegde Nagaraj P 
Cc: Subramanian Sriram 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c  | 62 +- 
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h  | 21 +++-
 .../Universal/Network/Ip4Dxe/Ip4Config2Impl.c  |  5 +-
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c| 62 +-
 4 files changed, 86 insertions(+), 64 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
index 004a8bc..7c7d182 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
@@ -1,8 +1,8 @@
 /** @file
 
-Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at  
http://opensource.org/licenses/bsd-license.php
 
@@ -265,5 +265,65 @@ Ip4NtohHead (
   Head->Src   = NTOHL (Head->Src);
   Head->Dst   = NTOHL (Head->Dst);
 
   return Head;
 }
+
+
+/**
+  Validate that Ip/Netmask pair is OK to be used as station
+  address. Only continuous netmasks are supported. and check
+  that StationAddress is a unicast address on the newtwork.
+
+  @param[in]  Ip The IP address to validate.
+  @param[in]  NetmaskThe netmaks of the IP.
+
+  @retval TRUE   The Ip/Netmask pair is valid.
+  @retval FALSE  The Ip/Netmask pair is invalid.
+
+**/
+BOOLEAN
+Ip4StationAddressValid (
+  IN IP4_ADDR   Ip,
+  IN IP4_ADDR   Netmask
+  )
+{
+  IP4_ADDR  NetBrdcastMask;
+  INTN  Len;
+  INTN  Type;
+
+  //
+  // Only support the station address with 0.0.0.0/0 to enable DHCP client.
+  //
+  if (Netmask == IP4_ALLZERO_ADDRESS) {
+return (BOOLEAN) (Ip == IP4_ALLZERO_ADDRESS);  }
+
+  //
+  // Only support the continuous net masks  //  if ((Len = 
+ NetGetMaskLength (Netmask)) == (IP4_MASK_MAX + 1)) {
+return FALSE;
+  }
+
+  //
+  // Station address can't be class D or class E address  //  if ((Type 
+ = NetGetIpClass (Ip)) > IP4_ADDR_CLASSC) {
+return FALSE;
+  }
+
+  //
+  // Station address can't be subnet broadcast/net broadcast address  
+ //  if ((Ip == (Ip & Netmask)) || (Ip == (Ip | ~Netmask))) {
+return FALSE;
+  }
+
+  NetBrdcastMask = gIp4AllMasks[MIN (Len, Type << 3)];
+
+  if (Ip == (Ip | ~NetBrdcastMask)) {
+return FALSE;
+  }
+
+  return TRUE;
+}
\ No newline at end of file
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
index d38857c..9689f37 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
@@ -1,9 +1,9 @@
 /** @file
   Common definition for IP4.
   
-Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at  
http://opensource.org/licenses/bsd-license.php
 
@@ -199,6 +199,25 @@ Ip4GetMulticastMac (  IP4_HEAD *  Ip4NtohHead (
   IN IP4_HEAD   *Head
   );
 
+
+/**
+  Validate that Ip/Netmask pair is OK to be used as station
+  address. Only continuous netmasks are supported. and check
+  that StationAddress is a unicast address on the newtwork.
+
+  @param[in]  Ip The IP address to validate.
+  @param[in]  NetmaskThe netmaks of the IP.
+
+  @retval TRUE   The Ip/Netmask pair is valid.
+  @retval FALSE  The Ip/Netmask pair is invalid.
+
+**/
+BOOLEAN
+Ip4StationAddressValid (
+  IN IP4_ADDR   Ip,
+  IN IP4_ADDR   Netmask
+  );
+
 #endif
diff --git 

Re: [edk2] Testing NVMe async commands

[Tian, Feng]

Hi, Sharma

As far as I know, we have UEFI SCT test suite to cover NVME_PASS_THRU async 
test. But it's not complex as your case.

As you have sent 210720 cmds, it's more like memory leak issue. Could you 
please only send 1 cmds and compare the memory map change before and after? 
If there is big memory map change, then there should have memory leak. 

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Arka 
Sharma
Sent: Wednesday, March 15, 2017 10:32 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Testing NVMe async commands

We have developed an application to test the async flow in NvmExpressDxe. We 
have allocated a buffer of size 8 MB and in that buffer we are reading 128k 
chunks, which results in 64 commands as the async submission queue depth is 64, 
after calling passthru with the Event we increment a counter and inside the 
notification function we decrement the counter. After sending all the commands 
we wait till the counter becomes 0. After 64 reads are completed we issue 64 
write command passing the buffer we have just read. So after 8 MB is done we 
increment the lba and repeat the same. In the application we are putting the 
starting lba of each 8 mb operation, so it increments as 0x0, 0x4000, 0x8000 as 
lba size of the device is 512 bytes. We are observing a hang at lba 0x66E4000, 
after processing 210720 commands.
We are creating and closing the events after each 8 MB read and write.
This stuck is seen consistently. May be there is something wrong we are doing 
in the application.

Please let me know if there is any reference UEFI application to test async ?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] how to load drivers from additional FV's?

[Andrew Fish]

> On Mar 15, 2017, at 7:29 PM, Gao, Liming  wrote:
> 
> Michael:
>  I agree this is an issue in PeiCore and DxeCore, because PI spec has no 
> limitation to nest FV number. Could you help submit one tracker in bugzillar? 
> We will fix it. 
> 

Liming,

Thanks for double checking the spec, I did not have time to do that today.

Thanks,

Andrew Fish

> Thanks
> Liming
>> -Original Message-
>> From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
>> Sent: Thursday, March 16, 2017 12:08 AM
>> To: Andrew Fish 
>> Cc: Laszlo Ersek ; Tian, Feng ; Gao, 
>> Liming ;
>> edk2-devel@lists.01.org ; Zeng, Star 
>> 
>> Subject: Re: [edk2] how to load drivers from additional FV's?
>> 
>> Andrew, using a fallback with 1 as the fourth argument didn't seem to work.
>> 
>>> So one workaround would be to add a 2nd FV_IMAGE file that contains the 2nd 
>>> FV in the 1st FV_IMAGE Section.
>> I've actually tried that before and it didn't seem to work. BUt after
>> what you've said I tried using a uncompressed, nested FV like
>> this(inside [FV.FvMain]):
>> 
>> FILE FV_IMAGE = B67596E9-EA27-40E4-885C-5AE83D414BD4 {
>>  SECTION FV_IMAGE = FVMAINPLATFORM
>> }
>> 
>> And that actually worked! So is this a workaround or a clean solution?
>> 
>> Thanks a lot
>> Michael
>> 
>> 
>> On Wed, Mar 15, 2017 at 4:54 PM, Andrew Fish  wrote:
>>> 
>>> On Mar 15, 2017, at 8:38 AM, Laszlo Ersek  wrote:
>>> 
>>> On 03/15/17 16:13, Andrew Fish wrote:
>>> 
>>> 
>>> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek  wrote:
>>> 
>>> On 03/15/17 13:23, Michael Zimmermann wrote:
>>> 
>>> I'm trying to add another FV section FVMAIN_COMPACT so I can keep
>>> Platform specific drivers in a separate, included fdf.
>>> 
>>> I did this:
>>> FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>>>  SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
>>> PROCESSING_REQUIRED = TRUE {
>>>SECTION FV_IMAGE = FVMAIN
>>>SECTION FV_IMAGE = FVMAINPLATFORM
>>>  }
>>> }
>>> 
>>> The image builds file and using uefitool I can verify that the new FV
>>> is inside the compressed section.
>>> But none of the drivers gets discovered/loaded and I get 'Protocol not
>>> present!!' errors.
>>> 
>>> 
>>> The FVs need to be exposed to the DXE core via FV HOBs. See
>>> - 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5
>>> spec,
>>> - and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the
>>> same.
>>> 
>>> You can use the BuildFvHob() function for this.
>>> 
>>> If the firmware volume contains PEIMs (... as well), then it has to be
>>> exposed to the PEI core too, I think. I think the
>>> PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3
>>> "PEI" in Volume 3 of the PI spec.)
>>> 
>>> ... I used the PeiFvInitialization() function in
>>> OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above.
>>> 
>>> 
>>> Laszlo,
>>> 
>>> I think this case is an FV that is compressed and nested in another FV that
>>> is discovered. I think the issues is multiple FV Sections in an FV file are
>>> not currently supported.
>>> 
>>> 
>>> In OVMF we do the same:
>>> 
>>> FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>>>  SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED =
>>> TRUE {
>>>#
>>># These firmware volumes will have files placed in them uncompressed,
>>># and then both firmware volumes will be compressed in a single
>>># compression operation in order to achieve better overall compression.
>>>#
>>>SECTION FV_IMAGE = PEIFV
>>>SECTION FV_IMAGE = DXEFV
>>>  }
>>> }
>>> 
>>> "OvmfPkg/Sec/SecMain.c" decompresses the compressed FFS file into memory --
>>> which is special to OVMF, i.e. the fact that there is writeable memory in
>>> SEC --, then jumps to the PEI entry point. PlatformPei then exposes DXEFV to
>>> the PEI core (for loading the DXE core AIUI) and to the DXE core as well
>>> (for loading DXE modules).
>>> 
>>> The multiple FV sections in the FFS file are not discovered automatically.
>>> First, the OVMF build process saves the final (= decompressed) in-memory
>>> locations of the nested FVs into PCDs. Second, in DecompressMemFvs(), the
>>> SEC module decompresses the outer, compressed, FFS file, then locates the
>>> embedded FVs manually with FindFfsSectionInstance(), then moves the
>>> decompressed FVs individually to their pre-recorded locations.
>>> 
>>> In Michael's case, I think the same should be possible -- since FVMAIN is
>>> running for him, the outer, compressed file must already be decompressed (in
>>> full) to some temporary buffer in memory. If he can find, manually, the
>>> second section (with the embedded FVMAINPLATFORM firmware volume in it) in
>>> that area, then he can also expose it to the DXE core, I believe.
>>> 
>>> 
>>> Laszlo,
>>> 
>>> The DXE 

Re: [edk2] how to load drivers from additional FV's?

[Gao, Liming]

Michael:
  I agree this is an issue in PeiCore and DxeCore, because PI spec has no 
limitation to nest FV number. Could you help submit one tracker in bugzillar? 
We will fix it. 

Thanks
Liming
> -Original Message-
> From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
> Sent: Thursday, March 16, 2017 12:08 AM
> To: Andrew Fish 
> Cc: Laszlo Ersek ; Tian, Feng ; Gao, 
> Liming ;
> edk2-devel@lists.01.org ; Zeng, Star 
> 
> Subject: Re: [edk2] how to load drivers from additional FV's?
> 
> Andrew, using a fallback with 1 as the fourth argument didn't seem to work.
> 
> > So one workaround would be to add a 2nd FV_IMAGE file that contains the 2nd 
> > FV in the 1st FV_IMAGE Section.
> I've actually tried that before and it didn't seem to work. BUt after
> what you've said I tried using a uncompressed, nested FV like
> this(inside [FV.FvMain]):
> 
> FILE FV_IMAGE = B67596E9-EA27-40E4-885C-5AE83D414BD4 {
>   SECTION FV_IMAGE = FVMAINPLATFORM
> }
> 
> And that actually worked! So is this a workaround or a clean solution?
> 
> Thanks a lot
> Michael
> 
> 
> On Wed, Mar 15, 2017 at 4:54 PM, Andrew Fish  wrote:
> >
> > On Mar 15, 2017, at 8:38 AM, Laszlo Ersek  wrote:
> >
> > On 03/15/17 16:13, Andrew Fish wrote:
> >
> >
> > On Mar 15, 2017, at 8:07 AM, Laszlo Ersek  wrote:
> >
> > On 03/15/17 13:23, Michael Zimmermann wrote:
> >
> > I'm trying to add another FV section FVMAIN_COMPACT so I can keep
> > Platform specific drivers in a separate, included fdf.
> >
> > I did this:
> > FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
> >   SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
> > PROCESSING_REQUIRED = TRUE {
> > SECTION FV_IMAGE = FVMAIN
> > SECTION FV_IMAGE = FVMAINPLATFORM
> >   }
> > }
> >
> > The image builds file and using uefitool I can verify that the new FV
> > is inside the compressed section.
> > But none of the drivers gets discovered/loaded and I get 'Protocol not
> > present!!' errors.
> >
> >
> > The FVs need to be exposed to the DXE core via FV HOBs. See
> > - 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5
> > spec,
> > - and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the
> > same.
> >
> > You can use the BuildFvHob() function for this.
> >
> > If the firmware volume contains PEIMs (... as well), then it has to be
> > exposed to the PEI core too, I think. I think the
> > PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3
> > "PEI" in Volume 3 of the PI spec.)
> >
> > ... I used the PeiFvInitialization() function in
> > OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above.
> >
> >
> > Laszlo,
> >
> > I think this case is an FV that is compressed and nested in another FV that
> > is discovered. I think the issues is multiple FV Sections in an FV file are
> > not currently supported.
> >
> >
> > In OVMF we do the same:
> >
> > FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
> >   SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED =
> > TRUE {
> > #
> > # These firmware volumes will have files placed in them uncompressed,
> > # and then both firmware volumes will be compressed in a single
> > # compression operation in order to achieve better overall compression.
> > #
> > SECTION FV_IMAGE = PEIFV
> > SECTION FV_IMAGE = DXEFV
> >   }
> > }
> >
> > "OvmfPkg/Sec/SecMain.c" decompresses the compressed FFS file into memory --
> > which is special to OVMF, i.e. the fact that there is writeable memory in
> > SEC --, then jumps to the PEI entry point. PlatformPei then exposes DXEFV to
> > the PEI core (for loading the DXE core AIUI) and to the DXE core as well
> > (for loading DXE modules).
> >
> > The multiple FV sections in the FFS file are not discovered automatically.
> > First, the OVMF build process saves the final (= decompressed) in-memory
> > locations of the nested FVs into PCDs. Second, in DecompressMemFvs(), the
> > SEC module decompresses the outer, compressed, FFS file, then locates the
> > embedded FVs manually with FindFfsSectionInstance(), then moves the
> > decompressed FVs individually to their pre-recorded locations.
> >
> > In Michael's case, I think the same should be possible -- since FVMAIN is
> > running for him, the outer, compressed file must already be decompressed (in
> > full) to some temporary buffer in memory. If he can find, manually, the
> > second section (with the embedded FVMAINPLATFORM firmware volume in it) in
> > that area, then he can also expose it to the DXE core, I believe.
> >
> >
> > Laszlo,
> >
> > The DXE Core will dispatch FVs with Depex "automagically" but only one
> > FV_IMAGE Section per FV_IMAGE file.
> >
> > So one workaround would be to add a 2nd FV_IMAGE file that contains the 2nd
> > FV in the 1st FV_IMAGE Section.
> >
> > Also 

Re: [edk2] FDF dependency?

[Gao, Liming]

Matthew:
  One solution is to configure those PCDs as PatchablePcd and generate the 
binary image. Then, consume the binary image AsBuild INF file in the different 
FDF file. 
  AsBuild INF can be found in the source build output directory. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Foster, Matthew I
> Sent: Thursday, March 16, 2017 2:14 AM
> To: edk2-devel@lists.01.org 
> Subject: [edk2] FDF dependency?
> 
> Is there a compile time dependency on values provided in the FDF file? I am 
> facing a situation where I am using pre-built binaries for
> some modules when building. We had a need to create another FDF file to 
> create a separate flash image with different values, but
> finding that some of the prebuilt binaries must be dependent on values in the 
> FDF it was originally compiled against? Because the
> image is having issues booting. Does anyone have any ideas on what I am 
> missing? For example, perhaps I need to include 2 copies of
> something one for each FDF flavor? Thanks for any help.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V2] MdeModulePkg: Fix service binding issue in TCP4 and Ip4 dxe.

[Fu, Siyuan]

Looks good to me.
Reviewed-by: Fu Siyuan 

-Original Message-
From: Zhang, Lubo 
Sent: 2017年3月15日 10:28
To: edk2-devel@lists.01.org
Cc: Wu, Jiaxin ; Ye, Ting ; Fu, Siyuan 

Subject: [PATCH V2] MdeModulePkg: Fix service binding issue in TCP4 and Ip4 dxe.

v2: Handle error case in SockCreateChild and fix typo issue

when we destroy the socket Sock and its associated protocol control block, we 
need to first close the parent protocol, then remove the protocol from 
childHandle and last to free any data structures that allocated in CreateChild. 
But currently, we free the socket data (Socket ConfigureState) before removing 
the protocol form  the childhandle. So if the up layer want to send the tcp 
reset packet in it's driver binding stop function, it will failed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Fu Siyuan 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c  | 10 +--
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c|  3 +-
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h|  5 +-
 MdeModulePkg/Universal/Network/Tcp4Dxe/SockImpl.c  | 48 +---  
MdeModulePkg/Universal/Network/Tcp4Dxe/SockImpl.h  |  3 +-
 .../Universal/Network/Tcp4Dxe/SockInterface.c  | 88 --
 .../Universal/Network/Tcp4Dxe/Tcp4Dispatcher.c | 12 +--
 7 files changed, 95 insertions(+), 74 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
index 642e453..792db5c 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
@@ -1,9 +1,9 @@
 /** @file
   The driver binding and service binding protocol for IP4 driver.
 
-Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
 
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -920,11 +920,10 
@@ Ip4ServiceBindingDestroyChild (
   EFI_STATUSStatus;
   IP4_SERVICE   *IpSb;
   IP4_PROTOCOL  *IpInstance;
   EFI_IP4_PROTOCOL  *Ip4;
   EFI_TPL   OldTpl;
-  INTN  State;
 
   if ((This == NULL) || (ChildHandle == NULL)) {
 return EFI_INVALID_PARAMETER;
   }
 
@@ -958,17 +957,16 @@ Ip4ServiceBindingDestroyChild (
   // A child can be destroyed more than once. For example,
   // Ip4DriverBindingStop will destroy all of its children.
   // when UDP driver is being stopped, it will destroy all
   // the IP child it opens.
   //
-  if (IpInstance->State == IP4_STATE_DESTROY) {
+  if (IpInstance->InDestroy) {
 gBS->RestoreTPL (OldTpl);
 return EFI_SUCCESS;
   }
 
-  State = IpInstance->State;
-  IpInstance->State = IP4_STATE_DESTROY;
+  IpInstance->InDestroy = TRUE;
 
   //
   // Close the Managed Network protocol.
   //
   gBS->CloseProtocol (
@@ -1007,10 +1005,11 @@ Ip4ServiceBindingDestroyChild (
   ,
   >Ip4Proto
   );
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
   if (EFI_ERROR (Status)) {
+IpInstance->InDestroy = FALSE;
 goto ON_ERROR;
   }
 
   Status = Ip4CleanProtocol (IpInstance);
   if (EFI_ERROR (Status)) {
@@ -1031,10 +1030,9 @@ Ip4ServiceBindingDestroyChild (
 
   FreePool (IpInstance);
   return EFI_SUCCESS;
 
 ON_ERROR:
-  IpInstance->State = State;
   gBS->RestoreTPL (OldTpl);
 
   return Status;
 }
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
index 91f1a67..23690ff 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
@@ -1,8 +1,8 @@
 /** @file
 
-Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at  
http://opensource.org/licenses/bsd-license.php
 
@@ -548,10 +548,11 @@ Ip4InitProtocol (
   ZeroMem (IpInstance, sizeof (IP4_PROTOCOL));
 
   IpInstance->Signature = IP4_PROTOCOL_SIGNATURE;
   CopyMem (>Ip4Proto, , sizeof 
(IpInstance->Ip4Proto));
   IpInstance->State = IP4_STATE_UNCONFIGED;
+  IpInstance->InDestroy   = FALSE;
   IpInstance->Service   = IpSb;
 
   InitializeListHead (>Link);
   NetMapInit  (>RxTokens);
   NetMapInit  (>TxTokens);
diff --git 

Re: [edk2] [PATCH V2] NetworkPkg: Fix service binding issue in TCP dxe.

[Fu, Siyuan]

Looks good to me.
Reviewed-by: Fu Siyuan 


-Original Message-
From: Zhang, Lubo 
Sent: 2017年3月15日 10:28
To: edk2-devel@lists.01.org
Cc: Wu, Jiaxin ; Ye, Ting ; Fu, Siyuan 

Subject: [PATCH V2] NetworkPkg: Fix service binding issue in TCP dxe.

v2: Handle error case in SockCreateChild and fix typo issue

when we destroy the socket Sock and its associated protocol control block, we 
need to first close the parent protocol, then remove the protocol from 
childHandle and last to free any data structures that allocated in CreateChild. 
But currently, we free the socket data (Socket ConfigureState) before removing 
the protocol form  the childhandle. So if the up layer perform the driverbing 
stop to abort tcp session and send the tcp reset packet, it will failed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Fu Siyuan 
---
 NetworkPkg/TcpDxe/SockImpl.c  |  56 +---
 NetworkPkg/TcpDxe/SockImpl.h  |   3 +-
 NetworkPkg/TcpDxe/SockInterface.c | 108 +++---
 NetworkPkg/TcpDxe/TcpDispatcher.c |  19 +--
 4 files changed, 104 insertions(+), 82 deletions(-)

diff --git a/NetworkPkg/TcpDxe/SockImpl.c b/NetworkPkg/TcpDxe/SockImpl.c index 
4eb42fb..c5fb176 100644
--- a/NetworkPkg/TcpDxe/SockImpl.c
+++ b/NetworkPkg/TcpDxe/SockImpl.c
@@ -1,9 +1,9 @@
 /** @file
   Implementation of the Socket.
 
-  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2017, Intel Corporation. All rights 
+ reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
   http://opensource.org/licenses/bsd-license.php.
@@ -826,20 +826,12 @@ OnError:
 VOID
 SockDestroy (
   IN OUT SOCKET *Sock
   )
 {
-  VOID*SockProtocol;
-  EFI_GUID*TcpProtocolGuid;
-  EFI_STATUS  Status;
-
   ASSERT (SockStream == Sock->Type);
 
-  if (Sock->DestroyCallback != NULL) {
-Sock->DestroyCallback (Sock, Sock->Context);
-  }
-
   //
   // Flush the completion token buffered
   // by sock and rcv, snd buffer
   //
   if (!SOCK_IS_UNCONFIGURED (Sock)) {
@@ -870,56 +862,10 @@ SockDestroy (
   );
 
 Sock->Parent = NULL;
   }
 
-  //
-  // Set the protocol guid and driver binding handle
-  // in the light of Sock->SockType
-  //
-  if (Sock->IpVersion == IP_VERSION_4) {
-TcpProtocolGuid = 
-  } else {
-TcpProtocolGuid = 
-  }
-
-  //
-  // Retrieve the protocol installed on this sock
-  //
-  Status = gBS->OpenProtocol (
-  Sock->SockHandle,
-  TcpProtocolGuid,
-  ,
-  Sock->DriverBinding,
-  Sock->SockHandle,
-  EFI_OPEN_PROTOCOL_GET_PROTOCOL
-  );
-
-  if (EFI_ERROR (Status)) {
-
-DEBUG (
-  (EFI_D_ERROR,
-  "SockDestroy: Open protocol installed on socket failed with %r\n",
-  Status)
-  );
-
-goto FreeSock;
-  }
-
-  //
-  // Uninstall the protocol installed on this sock
-  // in the light of Sock->SockType
-  //
-  gBS->UninstallMultipleProtocolInterfaces (
-Sock->SockHandle,
-TcpProtocolGuid,
-SockProtocol,
-NULL
-);
-
-FreeSock:
-
   FreePool (Sock);
 }
 
 /**
   Flush the sndBuffer and rcvBuffer of socket.
diff --git a/NetworkPkg/TcpDxe/SockImpl.h b/NetworkPkg/TcpDxe/SockImpl.h index 
5a067de..80692b1 100644
--- a/NetworkPkg/TcpDxe/SockImpl.h
+++ b/NetworkPkg/TcpDxe/SockImpl.h
@@ -1,9 +1,9 @@
 /** @file
   The function declaration that provided for Socket Interface.
 
-  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2017, Intel Corporation. All rights 
+ reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
   http://opensource.org/licenses/bsd-license.php.
@@ -15,10 +15,11 @@
 
 #ifndef _SOCK_IMPL_H_
 #define _SOCK_IMPL_H_
 
 #include "Socket.h"
+#include "TcpMain.h"
 
 /**
   Signal a event with the given status.
 
   @param[in] TokenThe token's event is to be signaled.
diff --git a/NetworkPkg/TcpDxe/SockInterface.c 
b/NetworkPkg/TcpDxe/SockInterface.c
index 21ce643..b4ba40a 100644
--- a/NetworkPkg/TcpDxe/SockInterface.c
+++ b/NetworkPkg/TcpDxe/SockInterface.c
@@ -1,9 +1,9 @@
 /** @file
   Interface function of the Socket.
 
-  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2017, Intel Corporation. All rights 
+ reserved.
 
   This program and the accompanying materials
   are licensed 

[edk2] [Patch] MdeModulePkg/Ip4Dxe: Add Ip/Netmask pair check for Ip4Config2

[Jiaxin Wu]

Ip4config2 manual address setting doesn't check the validity
of Ip/Netmask pair, which leads to the invalid combination of
Ip and Netmask setting. This patch is to resolve this issue.

Cc: Hegde Nagaraj P 
Cc: Subramanian Sriram 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c  | 62 +-
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h  | 21 +++-
 .../Universal/Network/Ip4Dxe/Ip4Config2Impl.c  |  5 +-
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c| 62 +-
 4 files changed, 86 insertions(+), 64 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
index 004a8bc..7c7d182 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.c
@@ -1,8 +1,8 @@
 /** @file
 
-Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
 http://opensource.org/licenses/bsd-license.php
 
@@ -265,5 +265,65 @@ Ip4NtohHead (
   Head->Src   = NTOHL (Head->Src);
   Head->Dst   = NTOHL (Head->Dst);
 
   return Head;
 }
+
+
+/**
+  Validate that Ip/Netmask pair is OK to be used as station
+  address. Only continuous netmasks are supported. and check
+  that StationAddress is a unicast address on the newtwork.
+
+  @param[in]  Ip The IP address to validate.
+  @param[in]  NetmaskThe netmaks of the IP.
+
+  @retval TRUE   The Ip/Netmask pair is valid.
+  @retval FALSE  The Ip/Netmask pair is invalid.
+
+**/
+BOOLEAN
+Ip4StationAddressValid (
+  IN IP4_ADDR   Ip,
+  IN IP4_ADDR   Netmask
+  )
+{
+  IP4_ADDR  NetBrdcastMask;
+  INTN  Len;
+  INTN  Type;
+
+  //
+  // Only support the station address with 0.0.0.0/0 to enable DHCP client.
+  //
+  if (Netmask == IP4_ALLZERO_ADDRESS) {
+return (BOOLEAN) (Ip == IP4_ALLZERO_ADDRESS);
+  }
+
+  //
+  // Only support the continuous net masks
+  //
+  if ((Len = NetGetMaskLength (Netmask)) == (IP4_MASK_MAX + 1)) {
+return FALSE;
+  }
+
+  //
+  // Station address can't be class D or class E address
+  //
+  if ((Type = NetGetIpClass (Ip)) > IP4_ADDR_CLASSC) {
+return FALSE;
+  }
+
+  //
+  // Station address can't be subnet broadcast/net broadcast address
+  //
+  if ((Ip == (Ip & Netmask)) || (Ip == (Ip | ~Netmask))) {
+return FALSE;
+  }
+
+  NetBrdcastMask = gIp4AllMasks[MIN (Len, Type << 3)];
+
+  if (Ip == (Ip | ~NetBrdcastMask)) {
+return FALSE;
+  }
+
+  return TRUE;
+}
\ No newline at end of file
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
index d38857c..9689f37 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
@@ -1,9 +1,9 @@
 /** @file
   Common definition for IP4.
   
-Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
 http://opensource.org/licenses/bsd-license.php
 
@@ -199,6 +199,25 @@ Ip4GetMulticastMac (
 IP4_HEAD *
 Ip4NtohHead (
   IN IP4_HEAD   *Head
   );
 
+
+/**
+  Validate that Ip/Netmask pair is OK to be used as station
+  address. Only continuous netmasks are supported. and check
+  that StationAddress is a unicast address on the newtwork.
+
+  @param[in]  Ip The IP address to validate.
+  @param[in]  NetmaskThe netmaks of the IP.
+
+  @retval TRUE   The Ip/Netmask pair is valid.
+  @retval FALSE  The Ip/Netmask pair is invalid.
+
+**/
+BOOLEAN
+Ip4StationAddressValid (
+  IN IP4_ADDR   Ip,
+  IN IP4_ADDR   Netmask
+  );
+
 #endif
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index 6c7ac68..a5191d1 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -1250,11 +1250,14 @@ Ip4Config2SetMaunualAddress (
   NewAddress = *((EFI_IP4_CONFIG2_MANUAL_ADDRESS *) Data);
 
   StationAddress = EFI_NTOHL (NewAddress.Address);
   SubnetMask = EFI_NTOHL 

[edk2] [patch] OvmfPkg/QemuFwCfgS3Lib: Fix VS tool chain build failure

[Dandan Bi]

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 OvmfPkg/Include/Library/QemuFwCfgS3Lib.h| 10 +-
 OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c|  3 ++-
 OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c |  8 
 OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Dxe.c | 10 +-
 OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Pei.c |  2 +-
 5 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/OvmfPkg/Include/Library/QemuFwCfgS3Lib.h 
b/OvmfPkg/Include/Library/QemuFwCfgS3Lib.h
index 76c8554..432e3c9 100644
--- a/OvmfPkg/Include/Library/QemuFwCfgS3Lib.h
+++ b/OvmfPkg/Include/Library/QemuFwCfgS3Lib.h
@@ -153,12 +153,12 @@ VOID (EFIAPI FW_CFG_BOOT_SCRIPT_CALLBACK_FUNCTION) (
QemuFwCfgS3CallWhenBootScriptReady() cannot
be rolled back.
 
   @return  Error codes from underlying functions.
 **/
-EFIAPI
 RETURN_STATUS
+EFIAPI
 QemuFwCfgS3CallWhenBootScriptReady (
   IN FW_CFG_BOOT_SCRIPT_CALLBACK_FUNCTION *Callback,
   IN OUT VOID *Context,  OPTIONAL
   IN UINTNScratchBufferSize
   );
@@ -202,12 +202,12 @@ QemuFwCfgS3CallWhenBootScriptReady (
   @retval RETURN_BAD_BUFFER_SIZENumberOfBytes is larger than
 ScratchBufferSize.
 
   @return   Error codes from underlying functions.
 **/
-EFIAPI
 RETURN_STATUS
+EFIAPI
 QemuFwCfgS3ScriptWriteBytes (
   IN INT32 FirmwareConfigItem,
   IN UINTN NumberOfBytes
   );
 
@@ -249,12 +249,12 @@ QemuFwCfgS3ScriptWriteBytes (
   @retval RETURN_BAD_BUFFER_SIZENumberOfBytes is larger than
 ScratchBufferSize.
 
   @return   Error codes from underlying functions.
 **/
-EFIAPI
 RETURN_STATUS
+EFIAPI
 QemuFwCfgS3ScriptReadBytes (
   IN INT32 FirmwareConfigItem,
   IN UINTN NumberOfBytes
   );
 
@@ -289,12 +289,12 @@ QemuFwCfgS3ScriptReadBytes (
 
   @retval RETURN_BAD_BUFFER_SIZENumberOfBytes is too large.
 
   @return   Error codes from underlying functions.
 **/
-EFIAPI
 RETURN_STATUS
+EFIAPI
 QemuFwCfgS3ScriptSkipBytes (
   IN INT32 FirmwareConfigItem,
   IN UINTN NumberOfBytes
   );
 
@@ -347,12 +347,12 @@ QemuFwCfgS3ScriptSkipBytes (
 wholly contained in the ScratchBufferSize
 bytes at ScratchBuffer.
 
   @return   Error codes from underlying functions.
 **/
-EFIAPI
 RETURN_STATUS
+EFIAPI
 QemuFwCfgS3ScriptCheckValue (
   IN VOID   *ScratchData,
   IN UINT8  ValueSize,
   IN UINT64 ValueMask,
   IN UINT64 Value
diff --git a/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c 
b/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c
index 7b71305..7fa1200 100644
--- a/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c
+++ b/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c
@@ -95,12 +95,13 @@ QemuFwCfgS3Enabled (
QemuFwCfgS3CallWhenBootScriptReady() cannot
be rolled back.
 
   @return  Error codes from underlying functions.
 **/
-EFIAPI
+
 RETURN_STATUS
+EFIAPI
 QemuFwCfgS3CallWhenBootScriptReady (
   IN FW_CFG_BOOT_SCRIPT_CALLBACK_FUNCTION *Callback,
   IN OUT VOID *Context,  OPTIONAL
   IN UINTNScratchBufferSize
   )
diff --git a/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c 
b/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c
index 674929e..bdad448 100644
--- a/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c
+++ b/OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3BasePei.c
@@ -54,12 +54,12 @@
   @retval RETURN_BAD_BUFFER_SIZENumberOfBytes is larger than
 ScratchBufferSize.
 
   @return   Error codes from underlying functions.
 **/
-EFIAPI
 RETURN_STATUS
+EFIAPI
 QemuFwCfgS3ScriptWriteBytes (
   IN INT32 FirmwareConfigItem,
   IN UINTN NumberOfBytes
   )
 {
@@ -105,12 +105,12 @@ QemuFwCfgS3ScriptWriteBytes (
   @retval RETURN_BAD_BUFFER_SIZENumberOfBytes is larger than
 ScratchBufferSize.
 
   @return   Error codes from underlying functions.
 **/
-EFIAPI
 RETURN_STATUS
+EFIAPI
 QemuFwCfgS3ScriptReadBytes (
   IN INT32 FirmwareConfigItem,
   IN UINTN NumberOfBytes
   )
 {
@@ -149,12 +149,12 @@ QemuFwCfgS3ScriptReadBytes (
 
   @retval RETURN_BAD_BUFFER_SIZENumberOfBytes is too large.
 
   @return   Error codes from underlying functions.
 **/
-EFIAPI
 RETURN_STATUS
+EFIAPI
 QemuFwCfgS3ScriptSkipBytes (
   IN INT32 FirmwareConfigItem,
   IN UINTN NumberOfBytes
   

Re: [edk2] [PATCH v2] ShellPkg/HandleParsingLib: Correct format specifier for LoadedImage

[Carsey, Jaben]

I was unsure if printing the hex address of the load options was useful (useful 
enough?).

I know for some images it was nice to get the load options printed as a string 
since they are command line parameters. I guess that might be more focused on 
learning about the shell itself and how it was launched than other images.  
Hence my question.

I am good with this patch.

Ray can you review and push it if you agree?

-Jaben

> -Original Message-
> From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
> Sent: Wednesday, March 15, 2017 2:09 PM
> To: Carsey, Jaben 
> Cc: Jeff Westfahl ; edk2-devel@lists.01.org; Ni, Ruiyu
> 
> Subject: RE: [PATCH v2] ShellPkg/HandleParsingLib: Correct format specifier
> for LoadedImage
> Importance: High
> 
> Jaben,
> 
> I think the output looks good with the udpated format. All of the output
> values are aligned, and it prints the hex address of the load options,
> just like it prints the hex address of the image address right below.
> 
> Regards,
> Jeff
> 
> On Wed, 15 Mar 2017, Carsey, Jaben wrote:
> 
> > Does the print call need to be updated to print this out properly?
> >
> > -Jaben
> >
> >> -Original Message-
> >> From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
> >> Sent: Tuesday, March 14, 2017 2:02 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Jeff Westfahl ; Ni, Ruiyu
> ;
> >> Carsey, Jaben 
> >> Subject: [PATCH v2] ShellPkg/HandleParsingLib: Correct format specifier
> for
> >> LoadedImage
> >> Importance: High
> >>
> >> The format specifier for the LoadOptions field of the LoadedImage
> protocol
> >> is "%s". However, the data in LoadOptions is often generic binary data. A
> >> format specifier of "%x" is more appropriate for this field.
> >>
> >> Using "dh -v" with format specifier "%s" on BIOS images based on EDK II
> >> source before commit 891d844 can cause a crash.
> >>
> >> Cc: Ruiyu Ni 
> >> Cc: Jaben Carsey 
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Jeff Westfahl 
> >> ---
> >>  ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git
> a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> >> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> >> index 0d51627..273a420 100644
> >> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> >> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> >> @@ -354,7 +354,7 @@
> >>" DeviceHandle..: 
> >> %%H%x%%N\r\n"
> >>" FilePath..: 
> >> %%H%x%%N\r\n"
> >>" OptionsSize...: 
> >> %%H%x%%N\r\n"
> >> -  " LoadOptions...: 
> >> %%H%s%%N\r\n"
> >> +  " LoadOptions...: 
> >> %%H%x%%N\r\n"
> >>" ImageBase.: 
> >> %%H%x%%N\r\n"
> >>" ImageSize.: 
> >> %%H%Lx%%N\r\n"
> >>" CodeType..: 
> >> %%H%s%%N\r\n"
> >> --
> >> 2.7.4
> >
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] ShellPkg/HandleParsingLib: Correct format specifier for LoadedImage

[Jeff Westfahl]

Jaben,

I think the output looks good with the udpated format. All of the output 
values are aligned, and it prints the hex address of the load options, 
just like it prints the hex address of the image address right below.


Regards,
Jeff

On Wed, 15 Mar 2017, Carsey, Jaben wrote:


Does the print call need to be updated to print this out properly?

-Jaben


-Original Message-
From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
Sent: Tuesday, March 14, 2017 2:02 PM
To: edk2-devel@lists.01.org
Cc: Jeff Westfahl ; Ni, Ruiyu ;
Carsey, Jaben 
Subject: [PATCH v2] ShellPkg/HandleParsingLib: Correct format specifier for
LoadedImage
Importance: High

The format specifier for the LoadOptions field of the LoadedImage protocol
is "%s". However, the data in LoadOptions is often generic binary data. A
format specifier of "%x" is more appropriate for this field.

Using "dh -v" with format specifier "%s" on BIOS images based on EDK II
source before commit 891d844 can cause a crash.

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl 
---
 ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
index 0d51627..273a420 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
@@ -354,7 +354,7 @@
   " DeviceHandle..: 
%%H%x%%N\r\n"
   " FilePath..: 
%%H%x%%N\r\n"
   " OptionsSize...: 
%%H%x%%N\r\n"
-  " LoadOptions...: 
%%H%s%%N\r\n"
+  " LoadOptions...: 
%%H%x%%N\r\n"
   " ImageBase.: 
%%H%x%%N\r\n"
   " ImageSize.: 
%%H%Lx%%N\r\n"
   " CodeType..: 
%%H%s%%N\r\n"
--
2.7.4




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

Re: [edk2] [PATCH v2] ShellPkg/HandleParsingLib: Correct format specifier for LoadedImage

[Carsey, Jaben]

Does the print call need to be updated to print this out properly?

-Jaben

> -Original Message-
> From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
> Sent: Tuesday, March 14, 2017 2:02 PM
> To: edk2-devel@lists.01.org
> Cc: Jeff Westfahl ; Ni, Ruiyu ;
> Carsey, Jaben 
> Subject: [PATCH v2] ShellPkg/HandleParsingLib: Correct format specifier for
> LoadedImage
> Importance: High
> 
> The format specifier for the LoadOptions field of the LoadedImage protocol
> is "%s". However, the data in LoadOptions is often generic binary data. A
> format specifier of "%x" is more appropriate for this field.
> 
> Using "dh -v" with format specifier "%s" on BIOS images based on EDK II
> source before commit 891d844 can cause a crash.
> 
> Cc: Ruiyu Ni 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Westfahl 
> ---
>  ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> index 0d51627..273a420 100644
> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> @@ -354,7 +354,7 @@
>" DeviceHandle..: 
> %%H%x%%N\r\n"
>" FilePath..: 
> %%H%x%%N\r\n"
>" OptionsSize...: 
> %%H%x%%N\r\n"
> -  " LoadOptions...: 
> %%H%s%%N\r\n"
> +  " LoadOptions...: 
> %%H%x%%N\r\n"
>" ImageBase.: 
> %%H%x%%N\r\n"
>" ImageSize.: 
> %%H%Lx%%N\r\n"
>" CodeType..: 
> %%H%s%%N\r\n"
> --
> 2.7.4

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

Re: [edk2] [PATCH] ArmPkg/UncachedMemoryAllocationLib: set XP bit via CPU arch protocol

[Ard Biesheuvel]

On 15 March 2017 at 10:12, Ard Biesheuvel  wrote:
> On 15 March 2017 at 09:59, Ryan Harkin  wrote:
>> Hi Ard,
>>
>> Thanks for the quick turnaround as always.
>>
>> On 14 March 2017 at 20:20, Leif Lindholm  wrote:
>>> On Tue, Mar 14, 2017 at 07:58:15PM +, Ard Biesheuvel wrote:
 Commit e7b24ec9785d ("ArmPkg/UncachedMemoryAllocationLib: map uncached
 allocations non-executable") adds code that manipulates the GCD memory
 space attributes of a newly allocated uncached region without checking
 whether this region expose these attributes in its capabilities mask.

 Given that the intent is to remove executable permissions from the region,
 this is a fairly pointless exercise to begin with, regardless of whether
 it is correct or not. The reason is that RO/XP memory attributes in the
 GCD memory space map or the UEFI memory map are completely disconnected
 from the actual mapping permissions used in the page tables.

 So instead, invoke the CPU arch protocol directly, and add the non-exec
 attributes in the page tables directly.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel 
>>
>> Tested-by: Ryan Harkin 
>>
>> FVPs and TC2 worked before this change, Juno was hanging on boot as
>> per an earlier email thread.
>>
>> I tested this change on FVP Foundation & AEMv8, TC2 and Juno R0/1/2
>> and they all work fine after it's applied to the current HEAD of EDK2
>> (commit 8057622).
>>

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

[edk2] FDF dependency?

[Foster, Matthew I]

Is there a compile time dependency on values provided in the FDF file? I am 
facing a situation where I am using pre-built binaries for some modules when 
building. We had a need to create another FDF file to create a separate flash 
image with different values, but finding that some of the prebuilt binaries 
must be dependent on values in the FDF it was originally compiled against? 
Because the image is having issues booting. Does anyone have any ideas on what 
I am missing? For example, perhaps I need to include 2 copies of something one 
for each FDF flavor? Thanks for any help.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] how to load drivers from additional FV's?

[Michael Zimmermann]

Andrew, using a fallback with 1 as the fourth argument didn't seem to work.

> So one workaround would be to add a 2nd FV_IMAGE file that contains the 2nd 
> FV in the 1st FV_IMAGE Section.
I've actually tried that before and it didn't seem to work. BUt after
what you've said I tried using a uncompressed, nested FV like
this(inside [FV.FvMain]):

FILE FV_IMAGE = B67596E9-EA27-40E4-885C-5AE83D414BD4 {
  SECTION FV_IMAGE = FVMAINPLATFORM
}

And that actually worked! So is this a workaround or a clean solution?

Thanks a lot
Michael


On Wed, Mar 15, 2017 at 4:54 PM, Andrew Fish  wrote:
>
> On Mar 15, 2017, at 8:38 AM, Laszlo Ersek  wrote:
>
> On 03/15/17 16:13, Andrew Fish wrote:
>
>
> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek  wrote:
>
> On 03/15/17 13:23, Michael Zimmermann wrote:
>
> I'm trying to add another FV section FVMAIN_COMPACT so I can keep
> Platform specific drivers in a separate, included fdf.
>
> I did this:
> FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>   SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
> PROCESSING_REQUIRED = TRUE {
> SECTION FV_IMAGE = FVMAIN
> SECTION FV_IMAGE = FVMAINPLATFORM
>   }
> }
>
> The image builds file and using uefitool I can verify that the new FV
> is inside the compressed section.
> But none of the drivers gets discovered/loaded and I get 'Protocol not
> present!!' errors.
>
>
> The FVs need to be exposed to the DXE core via FV HOBs. See
> - 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5
> spec,
> - and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the
> same.
>
> You can use the BuildFvHob() function for this.
>
> If the firmware volume contains PEIMs (... as well), then it has to be
> exposed to the PEI core too, I think. I think the
> PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3
> "PEI" in Volume 3 of the PI spec.)
>
> ... I used the PeiFvInitialization() function in
> OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above.
>
>
> Laszlo,
>
> I think this case is an FV that is compressed and nested in another FV that
> is discovered. I think the issues is multiple FV Sections in an FV file are
> not currently supported.
>
>
> In OVMF we do the same:
>
> FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>   SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED =
> TRUE {
> #
> # These firmware volumes will have files placed in them uncompressed,
> # and then both firmware volumes will be compressed in a single
> # compression operation in order to achieve better overall compression.
> #
> SECTION FV_IMAGE = PEIFV
> SECTION FV_IMAGE = DXEFV
>   }
> }
>
> "OvmfPkg/Sec/SecMain.c" decompresses the compressed FFS file into memory --
> which is special to OVMF, i.e. the fact that there is writeable memory in
> SEC --, then jumps to the PEI entry point. PlatformPei then exposes DXEFV to
> the PEI core (for loading the DXE core AIUI) and to the DXE core as well
> (for loading DXE modules).
>
> The multiple FV sections in the FFS file are not discovered automatically.
> First, the OVMF build process saves the final (= decompressed) in-memory
> locations of the nested FVs into PCDs. Second, in DecompressMemFvs(), the
> SEC module decompresses the outer, compressed, FFS file, then locates the
> embedded FVs manually with FindFfsSectionInstance(), then moves the
> decompressed FVs individually to their pre-recorded locations.
>
> In Michael's case, I think the same should be possible -- since FVMAIN is
> running for him, the outer, compressed file must already be decompressed (in
> full) to some temporary buffer in memory. If he can find, manually, the
> second section (with the embedded FVMAINPLATFORM firmware volume in it) in
> that area, then he can also expose it to the DXE core, I believe.
>
>
> Laszlo,
>
> The DXE Core will dispatch FVs with Depex "automagically" but only one
> FV_IMAGE Section per FV_IMAGE file.
>
> So one workaround would be to add a 2nd FV_IMAGE file that contains the 2nd
> FV in the 1st FV_IMAGE Section.
>
> Also I'm not sure if the outer FV is compressed, but compressing compressed
> data usually does not end well as the algorithms leverage entropy. It is
> better to just compress the outer FV and have everything else uncompressed
> and let it all get compressed together. This also helps as there will be
> common dictionary entries so compressing as much data as possible in one
> shot usually works better. So for example if the outer FV is compressed it
> may have a dictionary entry that represents CopyMem, and it can represent
> that pattern with a small number of bits. Doing compression multiple times
> causes duplication as each compressed image has one copy of CopyMem (massive
> over simplification). Also if you compress a nested FV then the CopyMem
> pattern does not exist in the compressed data, and since the compressed data
> is more random it is 

Re: [edk2] how to load drivers from additional FV's?

[Andrew Fish]

> On Mar 15, 2017, at 8:38 AM, Laszlo Ersek  wrote:
> 
> On 03/15/17 16:13, Andrew Fish wrote:
>> 
>>> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek  wrote:
>>> 
>>> On 03/15/17 13:23, Michael Zimmermann wrote:
 I'm trying to add another FV section FVMAIN_COMPACT so I can keep
 Platform specific drivers in a separate, included fdf.
 
 I did this:
 FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
   SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
 PROCESSING_REQUIRED = TRUE {
 SECTION FV_IMAGE = FVMAIN
 SECTION FV_IMAGE = FVMAINPLATFORM
   }
 }
 
 The image builds file and using uefitool I can verify that the new FV
 is inside the compressed section.
 But none of the drivers gets discovered/loaded and I get 'Protocol not
 present!!' errors.
>>> 
>>> The FVs need to be exposed to the DXE core via FV HOBs. See
>>> - 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5
>>> spec,
>>> - and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the
>>> same.
>>> 
>>> You can use the BuildFvHob() function for this.
>>> 
>>> If the firmware volume contains PEIMs (... as well), then it has to be
>>> exposed to the PEI core too, I think. I think the
>>> PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3
>>> "PEI" in Volume 3 of the PI spec.)
>>> 
>>> ... I used the PeiFvInitialization() function in
>>> OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above.
>>> 
>> 
>> Laszlo,
>> 
>> I think this case is an FV that is compressed and nested in another FV that 
>> is discovered. I think the issues is multiple FV Sections in an FV file are 
>> not currently supported. 
> 
> In OVMF we do the same:
> 
> FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>   SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED = 
> TRUE {
> #
> # These firmware volumes will have files placed in them uncompressed,
> # and then both firmware volumes will be compressed in a single
> # compression operation in order to achieve better overall compression.
> #
> SECTION FV_IMAGE = PEIFV
> SECTION FV_IMAGE = DXEFV
>   }
> }
> 
> "OvmfPkg/Sec/SecMain.c" decompresses the compressed FFS file into memory -- 
> which is special to OVMF, i.e. the fact that there is writeable memory in SEC 
> --, then jumps to the PEI entry point. PlatformPei then exposes DXEFV to the 
> PEI core (for loading the DXE core AIUI) and to the DXE core as well (for 
> loading DXE modules).
> 
> The multiple FV sections in the FFS file are not discovered automatically. 
> First, the OVMF build process saves the final (= decompressed) in-memory 
> locations of the nested FVs into PCDs. Second, in DecompressMemFvs(), the SEC 
> module decompresses the outer, compressed, FFS file, then locates the 
> embedded FVs manually with FindFfsSectionInstance(), then moves the 
> decompressed FVs individually to their pre-recorded locations.
> 
> In Michael's case, I think the same should be possible -- since FVMAIN is 
> running for him, the outer, compressed file must already be decompressed (in 
> full) to some temporary buffer in memory. If he can find, manually, the 
> second section (with the embedded FVMAINPLATFORM firmware volume in it) in 
> that area, then he can also expose it to the DXE core, I believe.
> 

Laszlo,

The DXE Core will dispatch FVs with Depex "automagically" but only one FV_IMAGE 
Section per FV_IMAGE file. 

So one workaround would be to add a 2nd FV_IMAGE file that contains the 2nd FV 
in the 1st FV_IMAGE Section. 

Also I'm not sure if the outer FV is compressed, but compressing compressed 
data usually does not end well as the algorithms leverage entropy. It is better 
to just compress the outer FV and have everything else uncompressed and let it 
all get compressed together. This also helps as there will be common dictionary 
entries so compressing as much data as possible in one shot usually works 
better. So for example if the outer FV is compressed it may have a dictionary 
entry that represents CopyMem, and it can represent that pattern with a small 
number of bits. Doing compression multiple times causes duplication as each 
compressed image has one copy of CopyMem (massive over simplification). Also if 
you compress a nested FV then the CopyMem pattern does not exist in the 
compressed data, and since the compressed data is more random it is hard to 
find patterns to compress, so it hurts the compression of the outer FV. 

Thanks,

Andrew Fish

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

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Remove MSR_IA32_MISC_ENABLE check

[Anthony PERARD]

On Wed, Mar 15, 2017 at 09:54:30AM +0800, Jeff Fan wrote:
> The architectural MSR MSR_IA32_MISC_ENABLE is not supported by AMD processors.
> Because reading CPUID.8001H:EDK[20] is enough to check if XD feature is
> supported or not, we just remove checking MSR_IA32_MISC_ENABLE(0x1A0).
> 
> Cc: Anthony PERARD 
> Cc: Jiewen Yao 
> Cc: Feng Tian 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan 

Thanks, that works for me. I've tested on AMD and Intel machine, with
Xen.

Tested-by: Anthony PERARD 

> ---
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c 
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index 65f607a..ab664b4 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -193,12 +193,9 @@ GetCurrentPagingContext (
>  AsmCpuid (0x8001, NULL, NULL, NULL, );
>  if ((RegEdx & BIT20) != 0) {
>// XD supported
> -  if ((AsmReadMsr64 (0x01A0) & BIT34) == 0) {
> -// XD enabled
> -if ((AsmReadMsr64 (0xC080) & BIT11) != 0) {
> -  // XD activated
> -  PagingContext->ContextData.Ia32.Attributes |= 
> PAGE_TABLE_LIB_PAGING_CONTEXT_IA32_X64_ATTRIBUTES_XD_ACTIVATED;
> -}
> +  if ((AsmReadMsr64 (0xC080) & BIT11) != 0) {
> +// XD activated
> +PagingContext->ContextData.Ia32.Attributes |= 
> PAGE_TABLE_LIB_PAGING_CONTEXT_IA32_X64_ATTRIBUTES_XD_ACTIVATED;
>}
>  }
>  if ((RegEdx & BIT26) != 0) {
> -- 
> 2.9.3.windows.2
> 

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

Re: [edk2] how to load drivers from additional FV's?

[Andrew Fish]

> On Mar 15, 2017, at 8:28 AM, Michael Zimmermann  
> wrote:
> 
> Laszlo: As Andrew said, the problem is nesting FV's. I've also tried
> different ways and depths of nesting FV's in the main FV, but none of
> them worked. Also, I'm using PrePi,
> 
> Andrew: Yea that seems to be the problem, but how would I access other
> sections? ReadSection doesn't seem to take any section id or current
> section pointer.
> 

Michael,

The 4th arg that is hard coded to zero is the SectionInstance.

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/FirmwareVolume2.h#L409
  
  @param SectionInstance  Indicates which instance of sections
  with a type of SectionType to return.
  SectionType in conjunction with
  SectionInstance indicates which
  section to return. SectionInstance is
  zero based.

Thanks,

Andrew Fish

> Thanks
> Michael
> 
> On Wed, Mar 15, 2017 at 4:13 PM, Andrew Fish  wrote:
>> 
>>> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek  wrote:
>>> 
>>> On 03/15/17 13:23, Michael Zimmermann wrote:
 I'm trying to add another FV section FVMAIN_COMPACT so I can keep
 Platform specific drivers in a separate, included fdf.
 
 I did this:
 FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
   SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
 PROCESSING_REQUIRED = TRUE {
 SECTION FV_IMAGE = FVMAIN
 SECTION FV_IMAGE = FVMAINPLATFORM
   }
 }
 
 The image builds file and using uefitool I can verify that the new FV
 is inside the compressed section.
 But none of the drivers gets discovered/loaded and I get 'Protocol not
 present!!' errors.
>>> 
>>> The FVs need to be exposed to the DXE core via FV HOBs. See
>>> - 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5
>>> spec,
>>> - and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the
>>> same.
>>> 
>>> You can use the BuildFvHob() function for this.
>>> 
>>> If the firmware volume contains PEIMs (... as well), then it has to be
>>> exposed to the PEI core too, I think. I think the
>>> PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3
>>> "PEI" in Volume 3 of the PI spec.)
>>> 
>>> ... I used the PeiFvInitialization() function in
>>> OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above.
>>> 
>> 
>> Laszlo,
>> 
>> I think this case is an FV that is compressed and nested in another FV that 
>> is discovered. I think the issues is multiple FV Sections in an FV file are 
>> not currently supported.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>>> Thanks
>>> Laszlo
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] how to load drivers from additional FV's?

[Laszlo Ersek]

On 03/15/17 16:13, Andrew Fish wrote:
> 
>> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek  wrote:
>>
>> On 03/15/17 13:23, Michael Zimmermann wrote:
>>> I'm trying to add another FV section FVMAIN_COMPACT so I can keep
>>> Platform specific drivers in a separate, included fdf.
>>>
>>> I did this:
>>>  FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>>>SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
>>> PROCESSING_REQUIRED = TRUE {
>>>  SECTION FV_IMAGE = FVMAIN
>>>  SECTION FV_IMAGE = FVMAINPLATFORM
>>>}
>>>  }
>>>
>>> The image builds file and using uefitool I can verify that the new FV
>>> is inside the compressed section.
>>> But none of the drivers gets discovered/loaded and I get 'Protocol not
>>> present!!' errors.
>>
>> The FVs need to be exposed to the DXE core via FV HOBs. See
>> - 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5
>>  spec,
>> - and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the
>>  same.
>>
>> You can use the BuildFvHob() function for this.
>>
>> If the firmware volume contains PEIMs (... as well), then it has to be
>> exposed to the PEI core too, I think. I think the
>> PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3
>> "PEI" in Volume 3 of the PI spec.)
>>
>> ... I used the PeiFvInitialization() function in
>> OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above.
>>
> 
> Laszlo,
> 
> I think this case is an FV that is compressed and nested in another FV that 
> is discovered. I think the issues is multiple FV Sections in an FV file are 
> not currently supported. 

In OVMF we do the same:

FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
   SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED = 
TRUE {
 #
 # These firmware volumes will have files placed in them uncompressed,
 # and then both firmware volumes will be compressed in a single
 # compression operation in order to achieve better overall compression.
 #
 SECTION FV_IMAGE = PEIFV
 SECTION FV_IMAGE = DXEFV
   }
 }

"OvmfPkg/Sec/SecMain.c" decompresses the compressed FFS file into memory -- 
which is special to OVMF, i.e. the fact that there is writeable memory in SEC 
--, then jumps to the PEI entry point. PlatformPei then exposes DXEFV to the 
PEI core (for loading the DXE core AIUI) and to the DXE core as well (for 
loading DXE modules).

The multiple FV sections in the FFS file are not discovered automatically. 
First, the OVMF build process saves the final (= decompressed) in-memory 
locations of the nested FVs into PCDs. Second, in DecompressMemFvs(), the SEC 
module decompresses the outer, compressed, FFS file, then locates the embedded 
FVs manually with FindFfsSectionInstance(), then moves the decompressed FVs 
individually to their pre-recorded locations.

In Michael's case, I think the same should be possible -- since FVMAIN is 
running for him, the outer, compressed file must already be decompressed (in 
full) to some temporary buffer in memory. If he can find, manually, the second 
section (with the embedded FVMAINPLATFORM firmware volume in it) in that area, 
then he can also expose it to the DXE core, I believe.

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

Re: [edk2] how to load drivers from additional FV's?

[Michael Zimmermann]

Laszlo: As Andrew said, the problem is nesting FV's. I've also tried
different ways and depths of nesting FV's in the main FV, but none of
them worked. Also, I'm using PrePi,

Andrew: Yea that seems to be the problem, but how would I access other
sections? ReadSection doesn't seem to take any section id or current
section pointer.

Thanks
Michael

On Wed, Mar 15, 2017 at 4:13 PM, Andrew Fish  wrote:
>
>> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek  wrote:
>>
>> On 03/15/17 13:23, Michael Zimmermann wrote:
>>> I'm trying to add another FV section FVMAIN_COMPACT so I can keep
>>> Platform specific drivers in a separate, included fdf.
>>>
>>> I did this:
>>>  FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>>>SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
>>> PROCESSING_REQUIRED = TRUE {
>>>  SECTION FV_IMAGE = FVMAIN
>>>  SECTION FV_IMAGE = FVMAINPLATFORM
>>>}
>>>  }
>>>
>>> The image builds file and using uefitool I can verify that the new FV
>>> is inside the compressed section.
>>> But none of the drivers gets discovered/loaded and I get 'Protocol not
>>> present!!' errors.
>>
>> The FVs need to be exposed to the DXE core via FV HOBs. See
>> - 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5
>>  spec,
>> - and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the
>>  same.
>>
>> You can use the BuildFvHob() function for this.
>>
>> If the firmware volume contains PEIMs (... as well), then it has to be
>> exposed to the PEI core too, I think. I think the
>> PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3
>> "PEI" in Volume 3 of the PI spec.)
>>
>> ... I used the PeiFvInitialization() function in
>> OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above.
>>
>
> Laszlo,
>
> I think this case is an FV that is compressed and nested in another FV that 
> is discovered. I think the issues is multiple FV Sections in an FV file are 
> not currently supported.
>
> Thanks,
>
> Andrew Fish
>
>
>> Thanks
>> Laszlo
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] how to load drivers from additional FV's?

[Andrew Fish]

> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek  wrote:
> 
> On 03/15/17 13:23, Michael Zimmermann wrote:
>> I'm trying to add another FV section FVMAIN_COMPACT so I can keep
>> Platform specific drivers in a separate, included fdf.
>> 
>> I did this:
>>  FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>>SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
>> PROCESSING_REQUIRED = TRUE {
>>  SECTION FV_IMAGE = FVMAIN
>>  SECTION FV_IMAGE = FVMAINPLATFORM
>>}
>>  }
>> 
>> The image builds file and using uefitool I can verify that the new FV
>> is inside the compressed section.
>> But none of the drivers gets discovered/loaded and I get 'Protocol not
>> present!!' errors.
> 
> The FVs need to be exposed to the DXE core via FV HOBs. See
> - 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5
>  spec,
> - and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the
>  same.
> 
> You can use the BuildFvHob() function for this.
> 
> If the firmware volume contains PEIMs (... as well), then it has to be
> exposed to the PEI core too, I think. I think the
> PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3
> "PEI" in Volume 3 of the PI spec.)
> 
> ... I used the PeiFvInitialization() function in
> OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above.
> 

Laszlo,

I think this case is an FV that is compressed and nested in another FV that is 
discovered. I think the issues is multiple FV Sections in an FV file are not 
currently supported. 

Thanks,

Andrew Fish


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

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

Re: [edk2] how to load drivers from additional FV's?

[Andrew Fish]

> On Mar 15, 2017, at 5:23 AM, Michael Zimmermann  
> wrote:
> 
> I'm trying to add another FV section FVMAIN_COMPACT so I can keep
> Platform specific drivers in a separate, included fdf.
> 
> I did this:
>  FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
> PROCESSING_REQUIRED = TRUE {
>  SECTION FV_IMAGE = FVMAIN
>  SECTION FV_IMAGE = FVMAINPLATFORM
>}
>  }
> 
> The image builds file and using uefitool I can verify that the new FV
> is inside the compressed section.
> But none of the drivers gets discovered/loaded and I get 'Protocol not
> present!!' errors.
> 

Michael,

This looks like an implementation restriction. Please file a bug.

CoreProcessFvImageFile() will only grab the 1st instance (hard coded to 0) of 
EFI_SECTION_FIRMWARE_VOLUME_IMAGE and your example has 2 sections. 

Maybe the CoreProcessFvImageFile() should loop on instance. I assume the device 
path will be OK, but some one should check on that. 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c#L975


  //
  // Read the first (and only the first) firmware volume section
  //
  SectionType   = EFI_SECTION_FIRMWARE_VOLUME_IMAGE;
  FvHeader  = NULL;
  FvAlignment   = 0;
  Buffer= NULL;
  BufferSize= 0;
  AlignedBuffer = NULL;
  Status = Fv->ReadSection (
 Fv,
 DriverName,
 SectionType,
 0,
 ,
 ,
 
 );



Thanks,

Andrew Fish

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

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

Re: [edk2] [PATCH v2 2/2] MdeModulePkg/AcpiTableDxe: improve FADT.{DSDT, X_DSDT} mutual exclusion

[Laszlo Ersek]

On 03/15/17 02:22, Zeng, Star wrote:
> On 2017/3/14 21:13, Laszlo Ersek wrote:
>> On 03/14/17 09:33, Zeng, Star wrote:
>>> In original code for < 4G table,
>>> Dsdt and XDsdt will be both assigned if FADT is installed before
>>> DSDT, but
>>> Dsdt and XDsdt will have mutual exclusion if FADT is installed after
>>> DSDT.
>>>
>>> They are inconsistent.
>>
>> That's right. The revert would not solve this original problem.
>>
>>>
>>> Is there any negative impact found to assign both Dsdt and XDsdt for
>>> < 4G table except the spec volation?
>>
>> No, I don't think so; the spec violation is the only impact to my
>> knowledge.
>>
>> Are you suggesting that we:
>> - delete RequireDsdtXDsdtExclusion(),
>> - replace all invocations of RequireDsdtXDsdtExclusion() with FALSE,
>> - and then simplify the resultant code (that is, eliminate the
>>   always-FALSE branches, and un-indent the always-TRUE branches)?
>>
>> This would be [VARIANT A], regardless of ACPI spec version.
>>
>> I think that could work (as long as we don't mind breaking the ACPI spec
>> versions that require mutual exclusion).
> 
> Yes. Then the code could have maximum compatibility and the behavior
> could be consistent, sure more comments about code behavior and ACPI
> spec could be added.

Do you want me to submit the patch, or can one of you guys do it? I'm
happy to review the patch, but I would be slower to post it.

Thanks!
Laszlo

> 
> Thanks,
> Star
> 
>>
>> Thanks
>> Laszlo
>>
>>>
>>> Thanks,
>>> Star
>>> -Original Message-
>>> From: Fan, Jeff
>>> Sent: Tuesday, March 14, 2017 3:57 PM
>>> To: Laszlo Ersek ; edk2-devel-01
>>> 
>>> Cc: Tian, Feng ; Michael Tsirkin
>>> ; Ard Biesheuvel ;
>>> Phil Dennis-Jordan ; Leo Duran
>>> ; Yao, Jiewen ; Al Stone
>>> ; Zeng, Star 
>>> Subject: RE: [edk2] [PATCH v2 2/2] MdeModulePkg/AcpiTableDxe: improve
>>> FADT.{DSDT, X_DSDT} mutual exclusion
>>>
>>> Laszlo,
>>>
>>> Basically, I agree with this is OS assumption. I did not find better
>>> fix to handle such compatibility issue.
>>>
>>> I agree to revert this patch 2/2 to fix Windows 2012 R2 boot issue.
>>>
>>> I don't know if the other guys have other suggestions. :-)
>>>
>>> Thanks!
>>> Jeff
>>>
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Monday, March 13, 2017 10:44 PM
>>> To: Fan, Jeff; edk2-devel-01
>>> Cc: Tian, Feng; Michael Tsirkin; Ard Biesheuvel; Phil Dennis-Jordan;
>>> Leo Duran; Yao, Jiewen; Al Stone; Zeng, Star
>>> Subject: Re: [edk2] [PATCH v2 2/2] MdeModulePkg/AcpiTableDxe: improve
>>> FADT.{DSDT, X_DSDT} mutual exclusion
>>>
>>> On 03/13/17 04:07, Fan, Jeff wrote:
 Laszlo,

 We found one Windows Server 2012 R2 blue screen issue with ACPI 6.1
 FADT table.

 We did the following configuration test with DSDT under 4GB.
 .DSDT .X_DSDT Window Server 2012 R2
 --      ---
 setclear Failed// current
 implementation
 clear setSucceed
 setsetSucceed
>>>
>>> That looks like a Windows bug. The above configuration satisfies ACPI
>>> 6.1:
>>>
>>> DSDT -- Physical memory address of the DSDT. If the X_DSDT field
>>> contains a non-zero value then this field must be zero.
>>>
>>> X_DSDT -- Extended physical address of the DSDT. If the DSDT field
>>> contains a non-zero value then this field must be zero.
>>>
>>> Michael told me that "6.1 errata will specify X_DSDT takes preference
>>> over DSDT but both can be present legaly", however, here X_DSDT
>>> cannot take precedence because it is zero.
>>>
>>> Based on past experience, I don't expect that Microsoft will ever fix
>>> this ACPI bug in Windows Server 2012 R2. I don't even expect that
>>> they would share with us a list of ACPI spec versions that should be
>>> exempted from RequireDsdtXDsdtExclusion() -- despite the spec clearly
>>> requiring DSDT / X_DSDT exclusion --, for bug compatibility.
>>>
>>> That leaves us with trial and error, to see what works and what doesn't.
>>> Unfortunately, I don't have ACPI tables for several ACPI spec
>>> versions; I don't think I can experiment with this. If you find a
>>> workaround, that would be great, but if we can't, I guess the patch
>>> should be reverted.
>>> (Note however that the BSOD will remain possible to trigger, with the
>>> DSDT, FADT installation order.)
>>>
>>> Thanks
>>> Laszlo
>>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
 Laszlo Ersek
 Sent: Thursday, March 09, 2017 3:59 AM
 To: edk2-devel-01
 Cc: Tian, Feng; Michael Tsirkin; Ard Biesheuvel; Phil Dennis-Jordan;
 Leo Duran; Yao, Jiewen; Al Stone; Zeng, 

Re: [edk2] how to load drivers from additional FV's?

[Laszlo Ersek]

On 03/15/17 13:23, Michael Zimmermann wrote:
> I'm trying to add another FV section FVMAIN_COMPACT so I can keep
> Platform specific drivers in a separate, included fdf.
> 
> I did this:
>   FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
> SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
> PROCESSING_REQUIRED = TRUE {
>   SECTION FV_IMAGE = FVMAIN
>   SECTION FV_IMAGE = FVMAINPLATFORM
> }
>   }
> 
> The image builds file and using uefitool I can verify that the new FV
> is inside the compressed section.
> But none of the drivers gets discovered/loaded and I get 'Protocol not
> present!!' errors.

The FVs need to be exposed to the DXE core via FV HOBs. See
- 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5
  spec,
- and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the
  same.

You can use the BuildFvHob() function for this.

If the firmware volume contains PEIMs (... as well), then it has to be
exposed to the PEI core too, I think. I think the
PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3
"PEI" in Volume 3 of the PI spec.)

... I used the PeiFvInitialization() function in
OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above.

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

[edk2] Testing NVMe async commands

[Arka Sharma]

We have developed an application to test the async flow in
NvmExpressDxe. We have allocated a buffer of size 8 MB and in that
buffer we are reading 128k chunks, which results in 64 commands as the
async submission queue depth is 64, after calling passthru with the
Event we increment a counter and inside the notification function we
decrement the counter. After sending all the commands we wait till the
counter becomes 0. After 64 reads are completed we issue 64 write
command passing the buffer we have just read. So after 8 MB is done we
increment the lba and repeat the same. In the application we are
putting the starting lba of each 8 mb operation, so it increments as
0x0, 0x4000, 0x8000 as lba size of the device is 512 bytes. We are
observing a hang at lba 0x66E4000, after processing 210720 commands.
We are creating and closing the events after each 8 MB read and write.
This stuck is seen consistently. May be there is something wrong we
are doing in the application.

Please let me know if there is any reference UEFI application to test async ?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] how to load drivers from additional FV's?

[Michael Zimmermann]

I'm trying to add another FV section FVMAIN_COMPACT so I can keep
Platform specific drivers in a separate, included fdf.

I did this:
  FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
PROCESSING_REQUIRED = TRUE {
  SECTION FV_IMAGE = FVMAIN
  SECTION FV_IMAGE = FVMAINPLATFORM
}
  }

The image builds file and using uefitool I can verify that the new FV
is inside the compressed section.
But none of the drivers gets discovered/loaded and I get 'Protocol not
present!!' errors.

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

Re: [edk2] [PATCH] ArmPkg/UncachedMemoryAllocationLib: set XP bit via CPU arch protocol

[Ard Biesheuvel]

On 15 March 2017 at 09:59, Ryan Harkin  wrote:
> Hi Ard,
>
> Thanks for the quick turnaround as always.
>
> On 14 March 2017 at 20:20, Leif Lindholm  wrote:
>> On Tue, Mar 14, 2017 at 07:58:15PM +, Ard Biesheuvel wrote:
>>> Commit e7b24ec9785d ("ArmPkg/UncachedMemoryAllocationLib: map uncached
>>> allocations non-executable") adds code that manipulates the GCD memory
>>> space attributes of a newly allocated uncached region without checking
>>> whether this region expose these attributes in its capabilities mask.
>>>
>>> Given that the intent is to remove executable permissions from the region,
>>> this is a fairly pointless exercise to begin with, regardless of whether
>>> it is correct or not. The reason is that RO/XP memory attributes in the
>>> GCD memory space map or the UEFI memory map are completely disconnected
>>> from the actual mapping permissions used in the page tables.
>>>
>>> So instead, invoke the CPU arch protocol directly, and add the non-exec
>>> attributes in the page tables directly.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>
> Tested-by: Ryan Harkin 
>
> FVPs and TC2 worked before this change, Juno was hanging on boot as
> per an earlier email thread.
>
> I tested this change on FVP Foundation & AEMv8, TC2 and Juno R0/1/2
> and they all work fine after it's applied to the current HEAD of EDK2
> (commit 8057622).
>

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

Re: [edk2] [PATCH] ArmPkg/UncachedMemoryAllocationLib: set XP bit via CPU arch protocol

[Ryan Harkin]

Hi Ard,

Thanks for the quick turnaround as always.

On 14 March 2017 at 20:20, Leif Lindholm  wrote:
> On Tue, Mar 14, 2017 at 07:58:15PM +, Ard Biesheuvel wrote:
>> Commit e7b24ec9785d ("ArmPkg/UncachedMemoryAllocationLib: map uncached
>> allocations non-executable") adds code that manipulates the GCD memory
>> space attributes of a newly allocated uncached region without checking
>> whether this region expose these attributes in its capabilities mask.
>>
>> Given that the intent is to remove executable permissions from the region,
>> this is a fairly pointless exercise to begin with, regardless of whether
>> it is correct or not. The reason is that RO/XP memory attributes in the
>> GCD memory space map or the UEFI memory map are completely disconnected
>> from the actual mapping permissions used in the page tables.
>>
>> So instead, invoke the CPU arch protocol directly, and add the non-exec
>> attributes in the page tables directly.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 

Tested-by: Ryan Harkin 

FVPs and TC2 worked before this change, Juno was hanging on boot as
per an earlier email thread.

I tested this change on FVP Foundation & AEMv8, TC2 and Juno R0/1/2
and they all work fine after it's applied to the current HEAD of EDK2
(commit 8057622).


>> ---
>>  ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c   
>> | 36 
>>  ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf 
>> |  8 -
>>  2 files changed, 36 insertions(+), 8 deletions(-)
>>
>> diff --git 
>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c 
>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>> index b4fbfbcb362b..2530175bab7a 100644
>> --- 
>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>> +++ 
>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>> @@ -27,6 +27,10 @@
>>  #include 
>>  #include 
>>
>> +#include 
>> +
>> +STATIC EFI_CPU_ARCH_PROTOCOL*mCpu;
>> +
>>  VOID *
>>  UncachedInternalAllocatePages (
>>IN EFI_MEMORY_TYPE  MemoryType,
>> @@ -150,15 +154,19 @@ AllocatePagesFromList (
>>
>>Status = gDS->GetMemorySpaceDescriptor (Memory, );
>>if (EFI_ERROR (Status)) {
>> -gBS->FreePages (Memory, Pages);
>> -return Status;
>> +goto FreePages;
>>}
>>
>>Status = gDS->SetMemorySpaceAttributes (Memory, EFI_PAGES_TO_SIZE (Pages),
>> -  EFI_MEMORY_WC | EFI_MEMORY_XP);
>> +  EFI_MEMORY_WC);
>>if (EFI_ERROR (Status)) {
>> -gBS->FreePages (Memory, Pages);
>> -return Status;
>> +goto FreePages;
>> +  }
>> +
>> +  Status = mCpu->SetMemoryAttributes (mCpu, Memory, EFI_PAGES_TO_SIZE 
>> (Pages),
>> +   EFI_MEMORY_XP);
>
> So, all other changes here are straightforward, but this one relies on
> the fact that we don't care about EFI_MEMORY_RO being cleared when we
> flip to _XP. As discussed on irc, if you can add a small note on that
> (and wait for Ryan's Tested-by):
>
> Reviewed-by: Leif Lindholm 
>
>> +  if (EFI_ERROR (Status)) {
>> +goto FreePages;
>>}
>>
>>InvalidateDataCacheRange ((VOID *)(UINTN)Memory, EFI_PAGES_TO_SIZE 
>> (Pages));
>> @@ -166,8 +174,8 @@ AllocatePagesFromList (
>>NewNode = AllocatePool (sizeof (FREE_PAGE_NODE));
>>if (NewNode == NULL) {
>>  ASSERT (FALSE);
>> -gBS->FreePages (Memory, Pages);
>> -return EFI_OUT_OF_RESOURCES;
>> +Status = EFI_OUT_OF_RESOURCES;
>> +goto FreePages;
>>}
>>
>>NewNode->Base   = Memory;
>> @@ -181,6 +189,10 @@ AllocatePagesFromList (
>>
>>*Allocation = NewNode->Allocation;
>>return EFI_SUCCESS;
>> +
>> +FreePages:
>> +  gBS->FreePages (Memory, Pages);
>> +  return Status;
>>  }
>>
>>  /**
>> @@ -238,6 +250,16 @@ FreePagesFromList (
>>   */
>>  EFI_STATUS
>>  EFIAPI
>> +UncachedMemoryAllocationLibConstructor (
>> +  IN EFI_HANDLEImageHandle,
>> +  IN EFI_SYSTEM_TABLE  *SystemTable
>> +  )
>> +{
>> +  return gBS->LocateProtocol (, NULL, (VOID 
>> **));
>> +}
>> +
>> +EFI_STATUS
>> +EFIAPI
>>  UncachedMemoryAllocationLibDestructor (
>>IN EFI_HANDLEImageHandle,
>>IN EFI_SYSTEM_TABLE  *SystemTable
>> diff --git 
>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf 
>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
>> index d7a0f2f792a1..c637430c9020 100644
>> --- 
>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
>> +++ 
>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
>> @@ -22,7 +22,7 @@ [Defines]
>>MODULE_TYPE= DXE_DRIVER
>>VERSION_STRING = 1.0
>>LIBRARY_CLASS  = UncachedMemoryAllocationLib
>> -
>> +  

[edk2] [PATCH] IntelFsp2Pkg: Raise exception for invalid BSF option

[rthomaiy]

Raise exception for invalid BSF option in GenCfgOpt.py

Cc: Maurice Ma 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Richard Thomaiyar 
---
 IntelFsp2Pkg/Tools/GenCfgOpt.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/IntelFsp2Pkg/Tools/GenCfgOpt.py b/IntelFsp2Pkg/Tools/GenCfgOpt.py
index d8038e9..6dc1b10 100644
--- a/IntelFsp2Pkg/Tools/GenCfgOpt.py
+++ b/IntelFsp2Pkg/Tools/GenCfgOpt.py
@@ -1,6 +1,6 @@
 ## @ GenCfgOpt.py
 #
-# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
+# Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
 # This program and the accompanying materials are licensed and made available 
under
 # the terms and conditions of the BSD License that accompanies this 
distribution.
 # The full text of the license may be found at
@@ -1239,6 +1239,7 @@ EndList
 return 0
 
 def WriteBsfStruct  (self, BsfFd, Item):
+LogExpr = CLogicalExpression()
 if Item['type'] == "None":
 Space = "gPlatformFspPkgTokenSpaceGuid"
 else:
@@ -1260,6 +1261,9 @@ EndList
 for Option in OptList:
 Option = Option.strip()
 (OpVal, OpStr) = Option.split(':')
+test = LogExpr.getNumber (OpVal)
+if test is None:
+raise Exception("Selection Index '%s' is not a number" 
% OpVal)
 TmpList.append((OpVal, OpStr))
 return  TmpList
 
-- 
2.9.0.windows.1

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

Re: [edk2] [PATCH 2/3] ShellPkg UefiDpLib: Handle "/" separator in debug path for GCC build

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

Thanks/Ray

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, March 15, 2017 1:51 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Gao, Liming ;
> Ni, Ruiyu ; Carsey, Jaben 
> Subject: [PATCH 2/3] ShellPkg UefiDpLib: Handle "/" separator in debug path
> for GCC build
> 
> Cc: Liming Gao 
> Cc: Ruiyu Ni 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  ShellPkg/Library/UefiDpLib/DpUtilities.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/Library/UefiDpLib/DpUtilities.c
> b/ShellPkg/Library/UefiDpLib/DpUtilities.c
> index 64f1830fcc92..c60d27d8613f 100644
> --- a/ShellPkg/Library/UefiDpLib/DpUtilities.c
> +++ b/ShellPkg/Library/UefiDpLib/DpUtilities.c
> @@ -154,7 +154,7 @@ DpGetShortPdbFileName (
>  for (EndIndex = 0; PdbFileName[EndIndex] != 0; EndIndex++)
>;
>  for (IndexA = 0; PdbFileName[IndexA] != 0; IndexA++) {
> -  if (PdbFileName[IndexA] == '\\') {
> +  if ((PdbFileName[IndexA] == '\\') || (PdbFileName[IndexA] == '/')) {
>  StartIndex = IndexA + 1;
>}
> 
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH 3/3] MdeModulePkg BmPerf: Handle "/" separator in debug path for GCC build

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

Thanks/Ray

> -Original Message-
> From: Tian, Feng
> Sent: Wednesday, March 15, 2017 1:52 PM
> To: Zeng, Star ; edk2-devel@lists.01.org
> Cc: Gao, Liming ; Ni, Ruiyu ;
> Tian, Feng 
> Subject: RE: [PATCH 3/3] MdeModulePkg BmPerf: Handle "/" separator in
> debug path for GCC build
> 
> Reviewed-by: Feng Tian 
> 
> Thanks
> Feng
> 
> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, March 15, 2017 1:51 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Gao, Liming ;
> Ni, Ruiyu ; Tian, Feng 
> Subject: [PATCH 3/3] MdeModulePkg BmPerf: Handle "/" separator in debug
> path for GCC build
> 
> Cc: Liming Gao 
> Cc: Ruiyu Ni 
> Cc: Feng Tian 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/BmPerformance.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmPerformance.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmPerformance.c
> index 0abd0194409c..4d4495b2a826 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmPerformance.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmPerformance.c
> @@ -3,7 +3,7 @@
>performance, all the function will only include if the performance
>switch is set.
> 
> -Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials  are licensed and made
> available under the terms and conditions of the BSD License  which
> accompanies this distribution.  The full text of the license may be found at
> @@ -49,7 +49,7 @@ BmGetShortPdbFileName (
>;
> 
>  for (Index = 0; PdbFileName[Index] != 0; Index++) {
> -  if (PdbFileName[Index] == '\\') {
> +  if ((PdbFileName[Index] == '\\') || (PdbFileName[Index] == '/'))
> + {
>  StartIndex = Index + 1;
>}
> 
> --
> 2.7.0.windows.1

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

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

[Ard Biesheuvel]

On 15 March 2017 at 09:16, Zhu, Yonghong  wrote:
> Ard,
>
> Please help to review. Thanks.
>
> Best Regards,
> Zhu Yonghong
>
>
> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Sunday, March 05, 2017 9:59 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Zhu, Yonghong 
> Subject: [PATCH] BaseTools/tools_def: Use armv7-a for CLANG35 ARM 
> compilations.
>
> Define "-march=armv7-a" - which is used by the GCC toolchains - for ARM 
> CLAMNG35 builds to fix compilation of the MemoryFence ASM.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Marvin Haeuser 

Reviewed-by: Ard Biesheuvel 

> ---
>  BaseTools/Conf/tools_def.template | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 57455ac9f2f3..ab4f936e7a8b 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -5459,7 +5459,7 @@ DEFINE CLANG35_AARCH64_CC_FLAGS  = 
> DEF(GCC_AARCH64_CC_FLAGS) DEF(CLANG35_AARCH64
>  *_CLANG35_ARM_ASM_FLAGS  = DEF(GCC_ASM_FLAGS) 
> DEF(CLANG35_ARM_TARGET) $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) -Qunused-arguments
>  *_CLANG35_ARM_DLINK_FLAGS= DEF(CLANG35_ARM_TARGET) 
> DEF(GCC_ARM_DLINK_FLAGS)
>  *_CLANG35_ARM_DLINK2_FLAGS   = DEF(GCC_DLINK2_FLAGS_COMMON) 
> -Wl,--defsym=PECOFF_HEADER_SIZE=0x220
> -*_CLANG35_ARM_PLATFORM_FLAGS =
> +*_CLANG35_ARM_PLATFORM_FLAGS = -march=armv7-a
>  *_CLANG35_ARM_PP_FLAGS   = DEF(GCC_PP_FLAGS) DEF(CLANG35_ARM_TARGET) 
> $(ARCHCC_FLAGS) $(PLATFORM_FLAGS)
>  *_CLANG35_ARM_RC_FLAGS   = DEF(GCC_ARM_RC_FLAGS)
>  *_CLANG35_ARM_VFRPP_FLAGS= DEF(GCC_VFRPP_FLAGS) 
> DEF(CLANG35_ARM_TARGET) $(ARCHCC_FLAGS) $(PLATFORM_FLAGS)
> --
> 2.11.1.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Zhu, Yonghong]

Ard,

Please help to review. Thanks.

Best Regards,
Zhu Yonghong


-Original Message-
From: Marvin Häuser [mailto:marvin.haeu...@outlook.com] 
Sent: Sunday, March 05, 2017 9:59 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong 
Subject: [PATCH] BaseTools/tools_def: Use armv7-a for CLANG35 ARM compilations.

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

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

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

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

Re: [edk2] [PATCH] MdeModulePkg PiSmmCore: Remove unreferenced symbol for SMRAM profile

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, March 14, 2017 5:12 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen ; 
> Tian,
> Feng 
> Subject: [PATCH] MdeModulePkg PiSmmCore: Remove unreferenced symbol for
> SMRAM profile
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=370
> 
> Use GLOBAL_REMOVE_IF_UNREFERENCED for some SMRAM profile global
> variables,
> then their symbols could be removed when SMRAM profile is disabled.
> 
> Cc: Jiewen Yao 
> Cc: Feng Tian 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c | 18
> --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c
> b/MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c
> index dda9f12a7dcd..410e0836fd16 100644
> --- a/MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c
> +++ b/MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c
> @@ -1,7 +1,7 @@
>  /** @file
>Support routines for SMRAM profile.
> 
> -  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at
> @@ -77,11 +77,11 @@ GLOBAL_REMOVE_IF_UNREFERENCED
> MEMORY_PROFILE_CONTEXT_DATA mSmramProfileContext =
>  };
>  GLOBAL_REMOVE_IF_UNREFERENCED MEMORY_PROFILE_CONTEXT_DATA
> *mSmramProfileContextPtr = NULL;
> 
> -BOOLEAN mSmramReadyToLock;
> -BOOLEAN mSmramProfileGettingStatus = FALSE;
> -BOOLEAN mSmramProfileRecordingEnable =
> MEMORY_PROFILE_RECORDING_DISABLE;
> -EFI_DEVICE_PATH_PROTOCOL *mSmramProfileDriverPath;
> -UINTNmSmramProfileDriverPathSize;
> +GLOBAL_REMOVE_IF_UNREFERENCED BOOLEAN mSmramReadyToLock;
> +GLOBAL_REMOVE_IF_UNREFERENCED BOOLEAN mSmramProfileGettingStatus
> = FALSE;
> +GLOBAL_REMOVE_IF_UNREFERENCED BOOLEAN
> mSmramProfileRecordingEnable = MEMORY_PROFILE_RECORDING_DISABLE;
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_DEVICE_PATH_PROTOCOL
> *mSmramProfileDriverPath;
> +GLOBAL_REMOVE_IF_UNREFERENCED UINTN
> mSmramProfileDriverPathSize;
> 
>  /**
>Dump SMRAM infromation.
> @@ -232,7 +232,7 @@ SmramProfileProtocolRecord (
>IN CHAR8  *ActionString OPTIONAL
>);
> 
> -EDKII_SMM_MEMORY_PROFILE_PROTOCOL mSmmProfileProtocol = {
> +GLOBAL_REMOVE_IF_UNREFERENCED
> EDKII_SMM_MEMORY_PROFILE_PROTOCOL mSmmProfileProtocol = {
>SmramProfileProtocolGetData,
>SmramProfileProtocolRegisterImage,
>SmramProfileProtocolUnregisterImage,
> @@ -2630,7 +2630,7 @@ typedef struct {
>CHAR8 *String;
>  } ACTION_STRING;
> 
> -ACTION_STRING mExtActionString[] = {
> +GLOBAL_REMOVE_IF_UNREFERENCED ACTION_STRING mExtActionString[] = {
>{MEMORY_PROFILE_ACTION_LIB_ALLOCATE_PAGES,
> "Lib:AllocatePages"},
>{MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RUNTIME_PAGES,
> "Lib:AllocateRuntimePages"},
>{MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RESERVED_PAGES,
> "Lib:AllocateReservedPages"},
> @@ -2654,8 +2654,6 @@ ACTION_STRING mExtActionString[] = {
>{MEMORY_PROFILE_ACTION_LIB_REALLOCATE_RESERVED_POOL,
> "Lib:ReallocateReservedPool"},
>  };
> 
> -GLOBAL_REMOVE_IF_UNREFERENCED CHAR8 mUserDefinedActionString[] =
> {"UserDefined-0x8000"};
> -
>  typedef struct {
>EFI_MEMORY_TYPE   MemoryType;
>CHAR8 *MemoryTypeStr;
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH] MdeModulePkg DxeCore: Remove unreferenced symbol for memory profile

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, March 14, 2017 5:11 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen ; 
> Tian,
> Feng 
> Subject: [PATCH] MdeModulePkg DxeCore: Remove unreferenced symbol for
> memory profile
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=370
> 
> Use GLOBAL_REMOVE_IF_UNREFERENCED for some memory profile global
> variables,
> then their symbols could be removed when memory profile is disabled.
> 
> Cc: Jiewen Yao 
> Cc: Feng Tian 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
> b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
> index b67a17c86dff..a91a719b4de5 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
> @@ -63,11 +63,11 @@ GLOBAL_REMOVE_IF_UNREFERENCED
> MEMORY_PROFILE_CONTEXT_DATA mMemoryProfileContext
>  };
>  GLOBAL_REMOVE_IF_UNREFERENCED MEMORY_PROFILE_CONTEXT_DATA
> *mMemoryProfileContextPtr = NULL;
> 
> -EFI_LOCK mMemoryProfileLock = EFI_INITIALIZE_LOCK_VARIABLE
> (TPL_NOTIFY);
> -BOOLEAN mMemoryProfileGettingStatus = FALSE;
> -BOOLEAN mMemoryProfileRecordingEnable =
> MEMORY_PROFILE_RECORDING_DISABLE;
> -EFI_DEVICE_PATH_PROTOCOL *mMemoryProfileDriverPath;
> -UINTNmMemoryProfileDriverPathSize;
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_LOCK mMemoryProfileLock =
> EFI_INITIALIZE_LOCK_VARIABLE (TPL_NOTIFY);
> +GLOBAL_REMOVE_IF_UNREFERENCED BOOLEAN
> mMemoryProfileGettingStatus = FALSE;
> +GLOBAL_REMOVE_IF_UNREFERENCED BOOLEAN
> mMemoryProfileRecordingEnable = MEMORY_PROFILE_RECORDING_DISABLE;
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_DEVICE_PATH_PROTOCOL
> *mMemoryProfileDriverPath;
> +GLOBAL_REMOVE_IF_UNREFERENCED UINTN
> mMemoryProfileDriverPathSize;
> 
>  /**
>Get memory profile data.
> @@ -209,7 +209,7 @@ ProfileProtocolRecord (
>IN CHAR8  *ActionString OPTIONAL
>);
> 
> -EDKII_MEMORY_PROFILE_PROTOCOL mProfileProtocol = {
> +GLOBAL_REMOVE_IF_UNREFERENCED EDKII_MEMORY_PROFILE_PROTOCOL
> mProfileProtocol = {
>ProfileProtocolGetData,
>ProfileProtocolRegisterImage,
>ProfileProtocolUnregisterImage,
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH 0/3] DP: Handle "/" separator in debug path for GCC

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star 
> Zeng
> Sent: Wednesday, March 15, 2017 1:50 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star 
> Subject: [edk2] [PATCH 0/3] DP: Handle "/" separator in debug path for GCC
> 
> Star Zeng (3):
>   PerformancePkg Dp_App: Handle "/" separator in debug path for GCC
> build
>   ShellPkg UefiDpLib: Handle "/" separator in debug path for GCC build
>   MdeModulePkg BmPerf: Handle "/" separator in debug path for GCC build
> 
>  MdeModulePkg/Library/UefiBootManagerLib/BmPerformance.c | 4 ++--
>  PerformancePkg/Dp_App/DpUtilities.c | 2 +-
>  ShellPkg/Library/UefiDpLib/DpUtilities.c| 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> --
> 2.7.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdePkg/UefiDevicePathLib: Fix the wrong MAC address length

[Fu, Siyuan]

Reviewed-by: Fu Siyuan 


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: 2017年3月10日 14:47
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Ye, Ting ; Fu, Siyuan 
; Wu, Jiaxin ; Gao, Liming 

Subject: [edk2] [Patch] MdePkg/UefiDevicePathLib: Fix the wrong MAC address 
length

Network interface type should be checked before the conversion between text 
device path node and MAC device path. Otherwise, the MAC text string can't be 
converted to the representation of a device node, which leads to the series 
failure of network HII configuration(e.g. IP, VLAN, HTTP Boot configuration in 
Network Device List).

Cc: Liming Gao 
Cc: Ruiyu Ni 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c 
b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
index ae38859..a52cbef 100644
--- a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
+++ b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
@@ -1798,10 +1798,14 @@ DevPathFromTextMAC (
   );
 
   MACDevPath->IfType   = (UINT8) Strtoi (IfTypeStr);
 
   Length = sizeof (EFI_MAC_ADDRESS);
+  if (MACDevPath->IfType == 0x01 || MACDevPath->IfType == 0x00) {
+Length = 6;
+  }
+
   StrHexToBytes (AddressStr, Length * 2, MACDevPath->MacAddress.Addr, Length);
 
   return (EFI_DEVICE_PATH_PROTOCOL *) MACDevPath;  }
 
--
1.9.5.msysgit.1

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

Re: [edk2] [Patch] MdePkg/UefiDevicePathLib: Fix the wrong MAC address length

[Ye, Ting]

Reviewed-by: Ye Ting  

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Friday, March 10, 2017 2:47 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Ye, Ting ; Fu, Siyuan 
; Wu, Jiaxin ; Gao, Liming 

Subject: [edk2] [Patch] MdePkg/UefiDevicePathLib: Fix the wrong MAC address 
length

Network interface type should be checked before the conversion between text 
device path node and MAC device path. Otherwise, the MAC text string can't be 
converted to the representation of a device node, which leads to the series 
failure of network HII configuration(e.g. IP, VLAN, HTTP Boot configuration in 
Network Device List).

Cc: Liming Gao 
Cc: Ruiyu Ni 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c 
b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
index ae38859..a52cbef 100644
--- a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
+++ b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
@@ -1798,10 +1798,14 @@ DevPathFromTextMAC (
   );
 
   MACDevPath->IfType   = (UINT8) Strtoi (IfTypeStr);
 
   Length = sizeof (EFI_MAC_ADDRESS);
+  if (MACDevPath->IfType == 0x01 || MACDevPath->IfType == 0x00) {
+Length = 6;
+  }
+
   StrHexToBytes (AddressStr, Length * 2, MACDevPath->MacAddress.Addr, Length);
 
   return (EFI_DEVICE_PATH_PROTOCOL *) MACDevPath;  }
 
--
1.9.5.msysgit.1

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

[edk2] [Patch][edk2-platforms] Vlv2TbltDevicePkg: Disable LPC Serial IRQ.

[lushifex]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 Vlv2TbltDevicePkg/PlatformDxe/IchPlatformPolicy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformDxe/IchPlatformPolicy.c 
b/Vlv2TbltDevicePkg/PlatformDxe/IchPlatformPolicy.c
index 753eb54..5644a8b 100644
--- a/Vlv2TbltDevicePkg/PlatformDxe/IchPlatformPolicy.c
+++ b/Vlv2TbltDevicePkg/PlatformDxe/IchPlatformPolicy.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2004  - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 2017, Intel Corporation. All rights reserved.


 
   This program and the accompanying materials are licensed and made available 
under
@@ -406,7 +406,7 @@ InitPchPlatformPolicy (
   //
   // Enable / disable serial IRQ according to setup value.
   //
-  DxePlatformPchPolicy->SerialIrqConfig->SirqEnable = PCH_DEVICE_ENABLE;
+  DxePlatformPchPolicy->SerialIrqConfig->SirqEnable = PCH_DEVICE_DISABLE;
 
   //
   // Set Serial IRQ Mode Select according to setup value.
-- 
2.7.0.windows.1


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

Re: [edk2] [PATCH] MdeModulePkg/CapsuleLib: Fix runtime issue

[Zhang, Chao B]

Reviewed-by : Chao Zhang 

-Original Message-
From: Yao, Jiewen 
Sent: Wednesday, March 15, 2017 2:04 PM
To: edk2-devel@lists.01.org
Cc: Zhang, Chao B 
Subject: [PATCH] MdeModulePkg/CapsuleLib: Fix runtime issue

The previous patch has problem on handling capsule request at runtime.

This patch fixed the issue.

Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 53 
 1 file changed, 32 insertions(+), 21 deletions(-)

diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c 
b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
index 6344214..9ed0be3 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
@@ -1453,33 +1453,44 @@ IsNestedFmpCapsule (
   EFI_SYSTEM_RESOURCE_ENTRY  Entry;
 
   EsrtGuidFound = FALSE;
-
-  //
-  // Check ESRT protocol
-  //
-  Status = gBS->LocateProtocol(, NULL, (VOID 
**));
-  if (!EFI_ERROR(Status)) {
-Status = EsrtProtocol->GetEsrtEntry(>CapsuleGuid, );
-if (!EFI_ERROR(Status)) {
-  EsrtGuidFound = TRUE;
-}
-  }
-
-  //
-  // Check ESRT configuration table
-  //
-  if (!EsrtGuidFound) {
-Status = EfiGetSystemConfigurationTable(, 
(VOID **));
-if (!EFI_ERROR(Status)) {
-  ASSERT (Esrt != NULL);
-  EsrtEntry = (VOID *)(Esrt + 1);
-  for (Index = 0; Index < Esrt->FwResourceCount; Index++, EsrtEntry++) {
+  if (mIsVirtualAddrConverted) {
+if(mEsrtTable != NULL) {
+  EsrtEntry = (EFI_SYSTEM_RESOURCE_ENTRY *)(mEsrtTable + 1);
+  for (Index = 0; Index < mEsrtTable->FwResourceCount ; Index++, 
+ EsrtEntry++) {
 if (CompareGuid(>FwClass, >CapsuleGuid)) {
   EsrtGuidFound = TRUE;
   break;
 }
   }
 }
+  } else {
+//
+// Check ESRT protocol
+//
+Status = gBS->LocateProtocol(, NULL, (VOID 
**));
+if (!EFI_ERROR(Status)) {
+  Status = EsrtProtocol->GetEsrtEntry(>CapsuleGuid, );
+  if (!EFI_ERROR(Status)) {
+EsrtGuidFound = TRUE;
+  }
+}
+
+//
+// Check ESRT configuration table
+//
+if (!EsrtGuidFound) {
+  Status = EfiGetSystemConfigurationTable(, 
(VOID **));
+  if (!EFI_ERROR(Status)) {
+ASSERT (Esrt != NULL);
+EsrtEntry = (VOID *)(Esrt + 1);
+for (Index = 0; Index < Esrt->FwResourceCount; Index++, EsrtEntry++) {
+  if (CompareGuid(>FwClass, >CapsuleGuid)) {
+EsrtGuidFound = TRUE;
+break;
+  }
+}
+  }
+}
   }
   if (!EsrtGuidFound) {
 return FALSE;
--
2.7.4.windows.1

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

[edk2] [PATCH] MdeModulePkg/CapsuleLib: Fix runtime issue

[Jiewen Yao]

The previous patch has problem on handling capsule
request at runtime.

This patch fixed the issue.

Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 53 
 1 file changed, 32 insertions(+), 21 deletions(-)

diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c 
b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
index 6344214..9ed0be3 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
@@ -1453,33 +1453,44 @@ IsNestedFmpCapsule (
   EFI_SYSTEM_RESOURCE_ENTRY  Entry;
 
   EsrtGuidFound = FALSE;
-
-  //
-  // Check ESRT protocol
-  //
-  Status = gBS->LocateProtocol(, NULL, (VOID 
**));
-  if (!EFI_ERROR(Status)) {
-Status = EsrtProtocol->GetEsrtEntry(>CapsuleGuid, );
-if (!EFI_ERROR(Status)) {
-  EsrtGuidFound = TRUE;
-}
-  }
-
-  //
-  // Check ESRT configuration table
-  //
-  if (!EsrtGuidFound) {
-Status = EfiGetSystemConfigurationTable(, 
(VOID **));
-if (!EFI_ERROR(Status)) {
-  ASSERT (Esrt != NULL);
-  EsrtEntry = (VOID *)(Esrt + 1);
-  for (Index = 0; Index < Esrt->FwResourceCount; Index++, EsrtEntry++) {
+  if (mIsVirtualAddrConverted) {
+if(mEsrtTable != NULL) {
+  EsrtEntry = (EFI_SYSTEM_RESOURCE_ENTRY *)(mEsrtTable + 1);
+  for (Index = 0; Index < mEsrtTable->FwResourceCount ; Index++, 
EsrtEntry++) {
 if (CompareGuid(>FwClass, >CapsuleGuid)) {
   EsrtGuidFound = TRUE;
   break;
 }
   }
 }
+  } else {
+//
+// Check ESRT protocol
+//
+Status = gBS->LocateProtocol(, NULL, (VOID 
**));
+if (!EFI_ERROR(Status)) {
+  Status = EsrtProtocol->GetEsrtEntry(>CapsuleGuid, );
+  if (!EFI_ERROR(Status)) {
+EsrtGuidFound = TRUE;
+  }
+}
+
+//
+// Check ESRT configuration table
+//
+if (!EsrtGuidFound) {
+  Status = EfiGetSystemConfigurationTable(, 
(VOID **));
+  if (!EFI_ERROR(Status)) {
+ASSERT (Esrt != NULL);
+EsrtEntry = (VOID *)(Esrt + 1);
+for (Index = 0; Index < Esrt->FwResourceCount; Index++, EsrtEntry++) {
+  if (CompareGuid(>FwClass, >CapsuleGuid)) {
+EsrtGuidFound = TRUE;
+break;
+  }
+}
+  }
+}
   }
   if (!EsrtGuidFound) {
 return FALSE;
-- 
2.7.4.windows.1

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