Re: [edk2] [Patch] MdeModulePkg/Partition: Use proper partition number for MBR

[Laszlo Ersek]

On 02/18/16 07:42, Ruiyu Ni wrote:
> UEFI Spec 2.3.1.D Section 9.3.5.1 says Partitions are numbered
> according to their entry in their respective partition table,
> starting with 1.
> Update the code for MBR partition to follow this rule.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Feng Tian 
> ---
>  MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)

Can you please add the following line to the end of the commit message:

Ref: https://github.com/tianocore/edk2/issues/50

(no need to repost, can be done before pushing)

Also, a general note: I think it's catastrophic that the email address
of the bug reporter (on github) is not immediately available to us. I
can see that you pasted the patch into the issue report as well. I agree
this is a good goal, but if github's issue tracker wasn't utterly
broken, you could instead snarf the reporter's email address from the
report, and CC him or her *directly on the patch*.

Then he or she could also respond with a Tested-by, if appropriate.
(Well, not publicly, because the mailing list doesn't allow posting
without subscription. Which is *also* broken, by the way.)

Anyway, my point specifically for the patch is only the Ref: line.

Thanks
Laszlo


> diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c 
> b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
> index 4b0159c..1946334 100644
> --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
> +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
> @@ -12,7 +12,7 @@
>  the legacy boot strap code.
>  
>  Copyright (c) 2014, Hewlett-Packard Development Company, L.P.
> -Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD 
> License
>  which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -136,7 +136,6 @@ PartitionInstallMbrChildHandles (
>HARDDRIVE_DEVICE_PATH HdDev;
>HARDDRIVE_DEVICE_PATH ParentHdDev;
>EFI_STATUSFound;
> -  UINT32PartitionNumber;
>EFI_DEVICE_PATH_PROTOCOL  *DevicePathNode;
>EFI_DEVICE_PATH_PROTOCOL  *LastDevicePathNode;
>UINT32BlockSize;
> @@ -192,8 +191,6 @@ PartitionInstallMbrChildHandles (
>  }
>}
>  
> -  PartitionNumber = 1;
> -
>ZeroMem (, sizeof (HdDev));
>HdDev.Header.Type = MEDIA_DEVICE_PATH;
>HdDev.Header.SubType  = MEDIA_HARDDRIVE_DP;
> @@ -223,7 +220,7 @@ PartitionInstallMbrChildHandles (
>  continue;
>}
>  
> -  HdDev.PartitionNumber = PartitionNumber ++;
> +  HdDev.PartitionNumber = Index + 1;
>HdDev.PartitionStart  = UNPACK_UINT32 
> (Mbr->Partition[Index].StartingLBA);
>HdDev.PartitionSize   = UNPACK_UINT32 
> (Mbr->Partition[Index].SizeInLBA);
>CopyMem (HdDev.Signature, &(Mbr->UniqueMbrSignature[0]), sizeof 
> (Mbr->UniqueMbrSignature));
> @@ -252,6 +249,7 @@ PartitionInstallMbrChildHandles (
>  // It's an extended partition. Follow the extended partition
>  // chain to get all the logical drives
>  //
> +Index = 0;
>  ExtMbrStartingLba = 0;
>  
>  do {
> @@ -277,7 +275,7 @@ PartitionInstallMbrChildHandles (
>  ExtMbrStartingLba = UNPACK_UINT32 (Mbr->Partition[0].StartingLBA);
>  continue;
>}
> -  HdDev.PartitionNumber = PartitionNumber ++;
> +  HdDev.PartitionNumber = ++Index;
>HdDev.PartitionStart  = UNPACK_UINT32 (Mbr->Partition[0].StartingLBA) 
> + ExtMbrStartingLba + ParentHdDev.PartitionStart;
>HdDev.PartitionSize   = UNPACK_UINT32 (Mbr->Partition[0].SizeInLBA);
>if ((HdDev.PartitionStart + HdDev.PartitionSize - 1 >= 
> ParentHdDev.PartitionStart + ParentHdDev.PartitionSize) ||
> 

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

Re: [edk2] Using PCD to set default policy for IPv4/IPv6

[Subramanian, Sriram (EG Servers Platform SW)]

The IP4_CONFIG2 and IP6_CONFIG protocols need to know the current policy to 
decide if they need to do something during their DBStart (such as initiating a 
DHCPv4/v6 if policy is set so). It is not necessary for the platform to have a 
per-NIC interface policy, or the platform may choose to set policies only on 
specific NICs. For others, and in general the protocol needs to have a policy 
to apply, for which NetworkPkg could have PCDs that are consumed by these 
protocols. With this approach, platform code can set the PCD to what policy the 
platform wants for _all_ its NICs, and it can selectively change it by calling 
the set policy API.

Thanks,
Sriram.

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Thursday, February 18, 2016 5:48 AM
To: El-Haj-Mahmoud, Samer; Wu, Jiaxin; Subramanian, Sriram (EG Servers Platform 
SW); Hegde, Nagaraj P; Zimmer, Vincent; Li, Ruth; Ye, Ting; Fu, Siyuan; 
edk2-devel@lists.01.org; Kinney, Michael D
Subject: RE: Using PCD to set default policy for IPv4/IPv6

Samer,

A platform driver can be implemented to set the policy without defining PCDs in 
the MdeModulePkg or NetworkPkg.

Instead, a platform package can choose to define PCDs and potentially use those 
PCD values to set policy in calls to the
EFI_IP4_CONFIG2_POLICY or EFI_IP6_CONFIG_POLICY.  Or it could be an algorithm 
or HII forms in platform driver to set policy.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> El-Haj-Mahmoud,
> Samer
> Sent: Wednesday, February 17, 2016 3:20 PM
> To: Kinney, Michael D ; Wu, Jiaxin 
> ;
> Subramanian, Sriram (EG Servers Platform SW) ; Hegde, 
> Nagaraj P
> ; Zimmer, Vincent ; Li, 
> Ruth
> ; Ye, Ting ; Fu, Siyuan 
> ;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] Using PCD to set default policy for IPv4/IPv6
> 
> 1) Yes you could... that is one implementation choice. There are cases where 
> you need
> to start multiple adapters, just for inventory/other management tasks, and 
> you do not
> want all of them to default to DHCP/automatic
> 
> 2) Yes a platform driver can set the policy through the PCDs. I thought this 
> was the
> intention of introducing the PCDs. Previously, the policy was hard-coded to 
> DHCP/auto
> in the EDK2 drivers.
> 
> 
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, February 17, 2016 3:00 PM
> To: El-Haj-Mahmoud, Samer ; Wu, Jiaxin
> ; Subramanian, Sriram (EG Servers Platform SW) 
> ;
> Hegde, Nagaraj P ; Zimmer, Vincent 
> ;
> Li, Ruth ; Ye, Ting ; Fu, Siyuan
> ; edk2-devel@lists.01.org; Kinney, Michael D
> 
> Subject: RE: Using PCD to set default policy for IPv4/IPv6
> 
> Hi Samer,
> 
> 1) If there are a large number of adapters, can you choose to only start the 
> ones
> needed to boot?
> 
> 2) Can't a platform driver set the policy needed for each NIC that is 
> required to boot?
> 
> Mike
> 
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > El-Haj-Mahmoud, Samer
> > Sent: Wednesday, February 17, 2016 12:53 PM
> > To: Kinney, Michael D ; Wu, Jiaxin
> > ; Subramanian, Sriram (EG Servers Platform SW)
> > ; Hegde, Nagaraj P ;
> > Zimmer, Vincent ; Li, Ruth
> > ; Ye, Ting ; Fu, Siyuan
> > ; edk2-devel@lists.01.org
> > Subject: Re: [edk2] Using PCD to set default policy for IPv4/IPv6
> >
> > I believe the PCDs are just to let the core drivers select the default
> > behavior (not full configuration) of automatic/DHCP vs. Static. Today,
> > the core drivers hard-code the default behavior to DHCP/automatic, and
> > that is not ideal in server platforms that may have a large number of 
> > adapters.
> >
> >
> >
> > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > Sent: Wednesday, February 17, 2016 11:34 AM
> > To: Wu, Jiaxin ; Subramanian, Sriram (EG Servers
> > Platform SW) ; El-Haj-Mahmoud, Samer
> > ; Hegde, Nagaraj P
> > ; Zimmer, Vincent ;
> > Li, Ruth ; Ye, Ting ; Fu, Siyuan
> > ; edk2-devel@lists.01.org; Kinney, Michael D
> > 
> > Subject: RE: Using PCD to set default policy for IPv4/IPv6
> >
> > Jiaxin,
> >
> > If a platform module can set the 

Re: [edk2] [Patch 2/2] MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes

[Ni, Ruiyu]

Ben,
I just had a look at your changes. Nice feeling that our codes are quite 
similar, except yours are in a separate function.
I thought about separating it to a sub function but later didn't do that 
because this sub function is only called once
and the logic after all is quite simple:)

Can you give a rb for this patch? or you think a sub function is better? I can 
make that change if you insist.

Regards,
Ray

-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] 
Sent: Thursday, February 18, 2016 11:21 AM
To: Ni, Ruiyu ; edk2-de...@ml01.01.org
Cc: Andrew Fish ; Fan, Jeff 
Subject: Re: [Patch 2/2] MdeModuelPkg/PciBus: Return AddrTranslationOffset in 
GetBarAttributes

On Thu, 2016-02-18 at 10:33 +0800, Ruiyu Ni wrote:
> Some platform doesn't use CPU(HOST)/Device 1:1 mapping for PCI Bus.
> But PCI IO doesn't have interface to tell caller (device driver)
> whether the address returned by GetBarAttributes() is HOST address
> or device address.
> UEFI Spec 2.6 addresses this issue by clarifying the address returned
> is HOST address and caller can use AddrTranslationOffset to calculate
> the device address.

Hi !

I had implemented that a bit differently mostly for code clarity
(see below pasted from github)

Ie, make it a sub function. Otherwise I think the principle is ok.

Note that I haven't been able to work on my EDK2 port for a while now
due to other commitments. I will eventually get back to it and test
your patch.

You can browse my monster-patch on github, I need to split/clean it
into a proper patch series, it also contains some updates of a couple
of drivers to actually use that offset properly

https://github.com/ozbenh/edk2/commits/master

 +  Finds the root bridge resource corresponding to the BAR whose address
 +  space descritpor is passes as an argument and copy the translation offset
 +  over from it into the BAR descriptor
 +
 +  @param  RootBridgeA pointer to the 
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL instance.
 +  @param  BarAddressSpace   A pointer to the ACPI 2.0 resource 
descriptors that describe the current
 +configuration of this BAR of the PCI 
controller that is to be updated.
 +
 +  @retval EFI_SUCCESS   The descriptor was successfully updated.
 +  @retval EFI_UNSUPPORTED   No resource in the root bridge matches the 
BAR region
 +  @retval EFI_OUT_OF_RESOURCES  There are not enough resources available to 
allocate
 +Resources.
 +
 +**/
 +STATIC
 +EFI_STATUS
 +PciBarUpdateTranslationOffset(
 +  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL   *RootBridge,
 +  IN OUT EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *BarAddressSpace)
 +{
 +  EFI_STATUS Status;
 +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  *RootDescriptors;
 +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  *Desc;
 +  UINT8  *Temp;
 +
 +  Status = RootBridge->Configuration (RootBridge, (VOID **) );
 +  if (EFI_ERROR (Status)) {
 +return Status;
 +  }
 +
 +  Temp = (UINT8 *) RootDescriptors;
 +  while (*Temp == ACPI_ADDRESS_SPACE_DESCRIPTOR) {
 +Desc = (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *) Temp;
 +
 +//
 +// Do we have the right type of descriptor ?
 +//
 +if (Desc->ResType == BarAddressSpace->ResType) {
 +  //
 +  // Check if the BAR base fits
 +  //
 +  if (BarAddressSpace->AddrRangeMin >= Desc->AddrRangeMin &&
 +  BarAddressSpace->AddrRangeMin < (Desc->AddrRangeMin + 
Desc->AddrLen)) {
 +//
 +// Found it, update offset and return
 +//
 +BarAddressSpace->AddrTranslationOffset = Desc->AddrTranslationOffset;
 +return EFI_SUCCESS;
 +  }
 +}
 +Temp += sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR);
 +  }
 +  return EFI_UNSUPPORTED;
 +}
 +
 +/**
Gets the attributes that this PCI controller supports setting on a BAR using
SetBarAttributes(), and retrieves the list of resource descriptors for a 
BAR.
  
 @@ -1778,6 +1834,7 @@ PciIoGetBarAttributes (
PCI_IO_DEVICE *PciIoDevice;
EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *AddressSpace;
EFI_ACPI_END_TAG_DESCRIPTOR   *End;
 +  EFI_STATUSStatus;
  
PciIoDevice = PCI_IO_DEVICE_FROM_PCI_IO_THIS (This);
  
 @@ -1878,6 +1935,15 @@ PciIoGetBarAttributes (
  }
  
  //
 +// Update the AddrTranslationOffset field
 +//
 +Status = PciBarUpdateTranslationOffset(PciIoDevice->PciRootBridgeIo, 
AddressSpace);
 +if (EFI_ERROR (Status)) {
 +  FreePool(AddressSpace);
 +  return Status;
 +}
 +
 +//
  // put the checksum
  //
  End   = (EFI_ACPI_END_TAG_DESCRIPTOR *) (AddressSpace + 1);
View

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Benjamin Herrenschmidt 
> Cc: Andrew Fish 
> Cc: Jeff 

Re: [edk2] [Patch] MdeModulePkg/Partition: Use proper partition number for MBR

[Tian, Feng]

Reviewed-by: Feng Tian 

-Original Message-
From: Ni, Ruiyu 
Sent: Thursday, February 18, 2016 14:43
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Tian, Feng
Subject: [Patch] MdeModulePkg/Partition: Use proper partition number for MBR

UEFI Spec 2.3.1.D Section 9.3.5.1 says Partitions are numbered according to 
their entry in their respective partition table, starting with 1.
Update the code for MBR partition to follow this rule.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
---
 MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
index 4b0159c..1946334 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
@@ -12,7 +12,7 @@
 the legacy boot strap code.
 
 Copyright (c) 2014, Hewlett-Packard Development Company, L.P. -Copyright 
(c) 2006 - 2013, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -136,7 +136,6 @@ 
PartitionInstallMbrChildHandles (
   HARDDRIVE_DEVICE_PATH HdDev;
   HARDDRIVE_DEVICE_PATH ParentHdDev;
   EFI_STATUSFound;
-  UINT32PartitionNumber;
   EFI_DEVICE_PATH_PROTOCOL  *DevicePathNode;
   EFI_DEVICE_PATH_PROTOCOL  *LastDevicePathNode;
   UINT32BlockSize;
@@ -192,8 +191,6 @@ PartitionInstallMbrChildHandles (
 }
   }
 
-  PartitionNumber = 1;
-
   ZeroMem (, sizeof (HdDev));
   HdDev.Header.Type = MEDIA_DEVICE_PATH;
   HdDev.Header.SubType  = MEDIA_HARDDRIVE_DP; @@ -223,7 +220,7 @@ 
PartitionInstallMbrChildHandles (
 continue;
   }
 
-  HdDev.PartitionNumber = PartitionNumber ++;
+  HdDev.PartitionNumber = Index + 1;
   HdDev.PartitionStart  = UNPACK_UINT32 
(Mbr->Partition[Index].StartingLBA);
   HdDev.PartitionSize   = UNPACK_UINT32 (Mbr->Partition[Index].SizeInLBA);
   CopyMem (HdDev.Signature, &(Mbr->UniqueMbrSignature[0]), sizeof 
(Mbr->UniqueMbrSignature)); @@ -252,6 +249,7 @@ PartitionInstallMbrChildHandles 
(
 // It's an extended partition. Follow the extended partition
 // chain to get all the logical drives
 //
+Index = 0;
 ExtMbrStartingLba = 0;
 
 do {
@@ -277,7 +275,7 @@ PartitionInstallMbrChildHandles (
 ExtMbrStartingLba = UNPACK_UINT32 (Mbr->Partition[0].StartingLBA);
 continue;
   }
-  HdDev.PartitionNumber = PartitionNumber ++;
+  HdDev.PartitionNumber = ++Index;
   HdDev.PartitionStart  = UNPACK_UINT32 (Mbr->Partition[0].StartingLBA) + 
ExtMbrStartingLba + ParentHdDev.PartitionStart;
   HdDev.PartitionSize   = UNPACK_UINT32 (Mbr->Partition[0].SizeInLBA);
   if ((HdDev.PartitionStart + HdDev.PartitionSize - 1 >= 
ParentHdDev.PartitionStart + ParentHdDev.PartitionSize) ||
--
2.7.0.windows.1

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

[edk2] [Patch] MdeModulePkg/Partition: Use proper partition number for MBR

[Ruiyu Ni]

UEFI Spec 2.3.1.D Section 9.3.5.1 says Partitions are numbered
according to their entry in their respective partition table,
starting with 1.
Update the code for MBR partition to follow this rule.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
---
 MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
index 4b0159c..1946334 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
@@ -12,7 +12,7 @@
 the legacy boot strap code.
 
 Copyright (c) 2014, Hewlett-Packard Development Company, L.P.
-Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -136,7 +136,6 @@ PartitionInstallMbrChildHandles (
   HARDDRIVE_DEVICE_PATH HdDev;
   HARDDRIVE_DEVICE_PATH ParentHdDev;
   EFI_STATUSFound;
-  UINT32PartitionNumber;
   EFI_DEVICE_PATH_PROTOCOL  *DevicePathNode;
   EFI_DEVICE_PATH_PROTOCOL  *LastDevicePathNode;
   UINT32BlockSize;
@@ -192,8 +191,6 @@ PartitionInstallMbrChildHandles (
 }
   }
 
-  PartitionNumber = 1;
-
   ZeroMem (, sizeof (HdDev));
   HdDev.Header.Type = MEDIA_DEVICE_PATH;
   HdDev.Header.SubType  = MEDIA_HARDDRIVE_DP;
@@ -223,7 +220,7 @@ PartitionInstallMbrChildHandles (
 continue;
   }
 
-  HdDev.PartitionNumber = PartitionNumber ++;
+  HdDev.PartitionNumber = Index + 1;
   HdDev.PartitionStart  = UNPACK_UINT32 
(Mbr->Partition[Index].StartingLBA);
   HdDev.PartitionSize   = UNPACK_UINT32 (Mbr->Partition[Index].SizeInLBA);
   CopyMem (HdDev.Signature, &(Mbr->UniqueMbrSignature[0]), sizeof 
(Mbr->UniqueMbrSignature));
@@ -252,6 +249,7 @@ PartitionInstallMbrChildHandles (
 // It's an extended partition. Follow the extended partition
 // chain to get all the logical drives
 //
+Index = 0;
 ExtMbrStartingLba = 0;
 
 do {
@@ -277,7 +275,7 @@ PartitionInstallMbrChildHandles (
 ExtMbrStartingLba = UNPACK_UINT32 (Mbr->Partition[0].StartingLBA);
 continue;
   }
-  HdDev.PartitionNumber = PartitionNumber ++;
+  HdDev.PartitionNumber = ++Index;
   HdDev.PartitionStart  = UNPACK_UINT32 (Mbr->Partition[0].StartingLBA) + 
ExtMbrStartingLba + ParentHdDev.PartitionStart;
   HdDev.PartitionSize   = UNPACK_UINT32 (Mbr->Partition[0].SizeInLBA);
   if ((HdDev.PartitionStart + HdDev.PartitionSize - 1 >= 
ParentHdDev.PartitionStart + ParentHdDev.PartitionSize) ||
-- 
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] CryptoPkg/OpensslLib: Upgrade OpenSSL version to 1.0.2f

[Ye, Ting]

Looks good to me.

Reviewed-by: Ye Ting  

-Original Message-
From: Long, Qin 
Sent: Thursday, February 18, 2016 12:33 AM
To: edk2-devel@lists.01.org; Ye, Ting
Subject: [Patch] CryptoPkg/OpensslLib: Upgrade OpenSSL version to 1.0.2f

OpenSSL has released version 1.0.2f with two security fixes
(http://www.openssl.org/news/secadv/20160128.txt) at 28-Jan-2016.
Upgrade the supported OpenSSL version in CryptoPkg/OpensslLib to catch the 
latest release 1.0.2f.
(NOTE: The patch file was just re-generated, and no new source
   changes was introduced for 1.0.2f enabling)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
CC: Ting Ye 
---
 ...ssl-1.0.2e.patch => EDKII_openssl-1.0.2f.patch} | 63 +++---
 CryptoPkg/Library/OpensslLib/Install.cmd   |  2 +-
 CryptoPkg/Library/OpensslLib/Install.sh|  2 +-
 CryptoPkg/Library/OpensslLib/OpensslLib.inf|  4 +-
 CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt   | 26 -
 5 files changed, 48 insertions(+), 49 deletions(-)  rename 
CryptoPkg/Library/OpensslLib/{EDKII_openssl-1.0.2e.patch => 
EDKII_openssl-1.0.2f.patch} (89%)

diff --git a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch 
b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
similarity index 89%
rename from CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch
rename to CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
index e4eaff6..c42b776 100644
--- a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch
+++ b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
@@ -1,7 +1,7 @@
 diff U3 crypto/bio/bio.h crypto/bio/bio.h
 crypto/bio/bio.h   Thu Jun 11 21:50:12 2015
-+++ crypto/bio/bio.h   Fri Jun 12 11:00:52 2015
-@@ -646,10 +646,10 @@
+--- crypto/bio/bio.h   Thu Jan 28 21:56:08 2016
 crypto/bio/bio.h   Wed Feb 17 16:43:40 2016
+@@ -650,10 +650,10 @@
  int BIO_asn1_get_suffix(BIO *b, asn1_ps_func **psuffix,
  asn1_ps_func **psuffix_free);
  
@@ -14,8 +14,8 @@ diff U3 crypto/bio/bio.h crypto/bio/bio.h
  # endif
  BIO *BIO_new(BIO_METHOD *type);
 diff U3 crypto/bio/bss_file.c crypto/bio/bss_file.c
 crypto/bio/bss_file.c  Thu Jun 11 21:01:06 2015
-+++ crypto/bio/bss_file.c  Fri Jun 12 11:01:28 2015
+--- crypto/bio/bss_file.c  Thu Jan 28 21:38:30 2016
 crypto/bio/bss_file.c  Wed Feb 17 16:01:02 2016
 @@ -467,6 +467,23 @@
  return (ret);
  }
@@ -41,8 +41,8 @@ diff U3 crypto/bio/bss_file.c crypto/bio/bss_file.c
  
  #endif  /* HEADER_BSS_FILE_C */
 diff U3 crypto/dh/dh_pmeth.c crypto/dh/dh_pmeth.c
 crypto/dh/dh_pmeth.c   Thu Jun 11 21:50:12 2015
-+++ crypto/dh/dh_pmeth.c   Fri Jun 12 11:08:48 2015
+--- crypto/dh/dh_pmeth.c   Thu Jan 28 21:56:08 2016
 crypto/dh/dh_pmeth.c   Wed Feb 17 16:15:58 2016
 @@ -449,6 +449,9 @@
  *keylen = ret;
  return 1;
@@ -62,8 +62,8 @@ diff U3 crypto/dh/dh_pmeth.c crypto/dh/dh_pmeth.c
  return 1;
  }
 diff U3 crypto/pem/pem.h crypto/pem/pem.h
 crypto/pem/pem.h   Thu Jun 11 21:50:12 2015
-+++ crypto/pem/pem.h   Fri Jun 12 10:58:18 2015
+--- crypto/pem/pem.h   Thu Jan 28 21:56:08 2016
 crypto/pem/pem.h   Wed Feb 17 15:56:26 2016
 @@ -324,6 +324,7 @@
  
  #  define DECLARE_PEM_read_fp(name, type) /**/ @@ -73,8 +73,8 @@ diff U3 
crypto/pem/pem.h crypto/pem/pem.h
  # else
  
 diff U3 crypto/pkcs7/pk7_smime.c crypto/pkcs7/pk7_smime.c
 crypto/pkcs7/pk7_smime.c   Thu Jun 11 21:01:06 2015
-+++ crypto/pkcs7/pk7_smime.c   Fri Jun 12 11:23:38 2015
+--- crypto/pkcs7/pk7_smime.c   Thu Jan 28 21:56:08 2016
 crypto/pkcs7/pk7_smime.c   Wed Feb 17 16:22:45 2016
 @@ -254,7 +254,8 @@
  STACK_OF(PKCS7_SIGNER_INFO) *sinfos;
  PKCS7_SIGNER_INFO *si;
@@ -114,20 +114,19 @@ diff U3 crypto/pkcs7/pk7_smime.c crypto/pkcs7/pk7_smime.c
  if (i <= 0)
  break;
  if (tmpout)
-@@ -394,6 +394,10 @@
+@@ -394,6 +394,9 @@
  }
  BIO_free_all(p7bio);
  sk_X509_free(signers);
-+
 +if (buf != NULL) {
-+  OPENSSL_free(buf);
++OPENSSL_free(buf);
 +}
  return ret;
  }
  
 diff U3 crypto/rand/rand_unix.c crypto/rand/rand_unix.c
 crypto/rand/rand_unix.cThu Jun 11 21:01:06 2015
-+++ crypto/rand/rand_unix.cFri Jun 12 10:51:21 2015
+--- crypto/rand/rand_unix.cThu Jan 28 21:38:32 2016
 crypto/rand/rand_unix.cWed Feb 17 15:40:02 2016
 @@ -116,7 +116,7 @@
  #include 
  #include "rand_lcl.h"
@@ -147,8 +146,8 @@ diff U3 crypto/rand/rand_unix.c crypto/rand/rand_unix.c
  {
  return 0;
 diff U3 crypto/rsa/rsa_ameth.c crypto/rsa/rsa_ameth.c
 crypto/rsa/rsa_ameth.c Thu Jun 11 21:50:12 2015
-+++ crypto/rsa/rsa_ameth.c Fri Jun 12 10:45:38 2015
+--- crypto/rsa/rsa_ameth.c Thu Jan 28 21:56:08 2016
 crypto/rsa/rsa_ameth.c Wed Feb 17 15:09:46 2016
 @@ -68,10 +68,12 @@
  #endif
  #include "asn1_locl.h"
@@ -221,8 +220,8 

[edk2] [PATCH] ShellPkg: Fix the last command in a script doesn't work.

[Qiu Shumin]

When the last line in a script file is not an empty line the Shell
will not execute the command in the last line. The patch refine the
logic in function 'ShellFileHandleReturnLine' and fix the issue.

Cc: Qiu Shumin 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey 
Reviewed-by: Qiu Shumin 
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index abff0d3..70852a9 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -2,7 +2,7 @@
   Provides interface to shell functionality for shell commands and 
applications.
 
   Copyright 2016 Dell Inc.
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -4071,6 +4071,9 @@ ShellFileHandleReturnLine(
 Status = ShellFileHandleReadLine(Handle, RetVal, , FALSE, Ascii);
 
   }
+  if (Status == EFI_END_OF_FILE && *RetVal != CHAR_NULL) {
+Status = EFI_SUCCESS;
+  }
   if (EFI_ERROR(Status) && (RetVal != NULL)) {
 FreePool(RetVal);
 RetVal = NULL;
-- 
1.9.5.msysgit.1

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

Re: [edk2] [PATCH v2] BaseTools: LzmaCompress: fix gcc-6 warning "misleading-indentation"

[Laszlo Ersek]

On 02/18/16 02:22, Gao, Liming wrote:
> Reviewed-by: Liming Gao 

Thanks guys; commit 6cc7ada465a7.

Laszlo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Thursday, February 18, 2016 3:18 AM
> To: edk2-devel-01 
> Cc: Justen, Jordan L ; Cole Robinson 
> ; Gao, Liming ; Zhu, Yonghong 
> 
> Subject: [PATCH v2] BaseTools: LzmaCompress: fix gcc-6 warning 
> "misleading-indentation"
> 
> The way the first use of the "_maxMode" variable is commented out (i.e.,
> together with the enclosing "if" statement) in GetOptimum() triggers the
> "misleading-indentation" warning that is new in gcc-6.0, for the block of
> code that originally depended on the "if" statement. Gcc believes
> (mistakenly) that the programmer believes (mistakenly) that the block
> depends on (repIndex == 0) higher up.
> 
> Restore the if statement, with a controlling expression that comprises the
> constant 1 and "_maxMode" commented out.
> 
> Cc: Jordan Justen 
> Cc: Cole Robinson 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Reported-by: Cole Robinson 
> Suggested-by: Jordan Justen 
> Build-tested-by: Cole Robinson 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1307439
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c 
> b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
> index 9b2dd16ffa48..c6717eeea3a0 100644
> --- a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
> +++ b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
> @@ -1367,7 +1367,7 @@ static UInt32 GetOptimum(CLzmaEnc *p, UInt32 position, 
> UInt32 *backRes)
>if (repIndex == 0)
>  startLen = lenTest + 1;
>  
> -  /* if (_maxMode) */
> +  if (1 /* _maxMode */)
>  {
>UInt32 lenTest2 = lenTest + 1;
>UInt32 limit = lenTest2 + p->numFastBytes;
> 

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

Re: [edk2] [patch] MdeModulePkg: Make HII configuration settings available to OS runtime

[Andrew Fish]

> On Feb 17, 2016, at 6:50 PM, Dong, Eric  wrote:
> 
> Hi All,
> 
> Thanks for your comments. I add my explanation below:
> 
> Only hook ReadyToBoot event is not enough. Different drivers may hook this 
> event and some may update string package in their callback function. The 
> order to call these callback functions is random, so only hook this event may 
> miss some changes.
> 
> This feature is described in UEFI spec 2.6 chapter 31.2.11.1. It required to 
> export all HiiDatabae data and current configuration data.

I don't see any language in that section that makes it required. It seems to 
just describe how to do it. 

> We add this feature because we strongly encourage the export of config data 
> to support manageability of platform config both for pre-OS and OS runtime 
> operations. 
> 

Generally the UEFI spec and the edk2 don't try to force platform policy. For 
example exposing some configuration information could be considered a security 
vulnerability on some platforms, so it should not be forced on a platform.

Thanks,

Andrew Fish

> Also we collect the performance data from our reference platform(Detail see 
> below). The boot performance is small and we can ignore it. This feature cost 
> extra 869KB, but we think the size cost is not care because current we use 
> 16M size of bios flash.  
> 
> HiiDatabase driver data size cost(This feature add in HiiDatabase driver):
>   Without this feature: 
>   Used data size: 151KB
>   With this feature
>   Used data size: 1020 KB   
>   PS: This extra size cost mainly depend on how much Hii packages in your 
> platform.
> 
> Boot Time cost:
>   Without this feature:
>   Boot Time cost:1st:3.353s   2nd: 3.035s
>   With this feature:
>   Boot Time cost:1st: 3.125s  2nd: 3.126s
> 
> Base on the above analysis, we provide this design and prefer to always 
> enable this feature instead of use a PCD to control it.
> 
> Thanks,
> Eric
> 
>> -Original Message-
>> From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
>> Sent: Wednesday, February 17, 2016 2:14 AM
>> To: Andrew Fish; Brian J. Johnson
>> Cc: Bi, Dandan; edk2-devel@lists.01.org; Dong, Eric; Gao, Liming
>> Subject: RE: [edk2] [patch] MdeModulePkg: Make HII configuration settings 
>> available to OS runtime
>> 
>> +1
>> 
>> I also would add there may be some HII strings that are hidden from user 
>> interfaces, and reflect settings for field service or
>> troubleshooting, and that a mass export to the OS may expose these settings 
>> to OS runtime code and possibly applications.
>> 
>> 
>> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Andrew Fish
>> Sent: Tuesday, February 16, 2016 10:37 AM
>> To: Brian J. Johnson 
>> Cc: Dandan Bi ; edk2-devel@lists.01.org; Eric Dong 
>> ; Liming Gao 
>> Subject: Re: [edk2] [patch] MdeModulePkg: Make HII configuration settings 
>> available to OS runtime
>> 
>> 
>>> On Feb 16, 2016, at 8:33 AM, Brian J. Johnson  wrote:
>>> 
>>> On 02/16/2016 12:58 AM, Dandan Bi wrote:
 This feature is aimed to allow OS make use of the HII database during
 runtime. In this case, the contents of the HII Database is exported
 to a buffer. The pointer to the buffer is placed in the EFI System
 Configuration Table, where it can be retrieved by an OS application.
 
 Export the configuration data and contents of HiiDatabase when driver
 add package, update package and remove package.
 For string and image may also need to update the contents of
 HiiDatabase when NewString/SetString, NewImage/SetImage.
 
 Cc: Liming Gao 
 Cc: Eric Dong 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Dandan Bi  ...
>>> 
>>> Please make this behavior selectable via a PCD.  HII operations are very 
>>> expensive, especially on simulators.  I don't want to pay the
>> export time every time a package is added or string is changed.  Also, 
>> platforms should be able to decide if they want to offer this data to
>> the OS.
>>> 
>> 
>> +1
>> 
>> I would want to opt out to NOT take the memory away from the OS if the 
>> platform did not care about the feature.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> Why not just export the data once, using a "ready to boot" event hook?
>>> 
>>> Thanks,
>>> --
>>> 
>>> Brian J. Johnson
>>> 
>>> 
>>> 
>>> My statements are my own, are not authorized by SGI, and do not
>>> necessarily represent SGI's positions.
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>> 
>> 

Re: [edk2] [Patch 2/2] MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes

[Benjamin Herrenschmidt]

On Thu, 2016-02-18 at 10:33 +0800, Ruiyu Ni wrote:
> Some platform doesn't use CPU(HOST)/Device 1:1 mapping for PCI Bus.
> But PCI IO doesn't have interface to tell caller (device driver)
> whether the address returned by GetBarAttributes() is HOST address
> or device address.
> UEFI Spec 2.6 addresses this issue by clarifying the address returned
> is HOST address and caller can use AddrTranslationOffset to calculate
> the device address.

Hi !

I had implemented that a bit differently mostly for code clarity
(see below pasted from github)

Ie, make it a sub function. Otherwise I think the principle is ok.

Note that I haven't been able to work on my EDK2 port for a while now
due to other commitments. I will eventually get back to it and test
your patch.

You can browse my monster-patch on github, I need to split/clean it
into a proper patch series, it also contains some updates of a couple
of drivers to actually use that offset properly

https://github.com/ozbenh/edk2/commits/master

 +  Finds the root bridge resource corresponding to the BAR whose address
 +  space descritpor is passes as an argument and copy the translation offset
 +  over from it into the BAR descriptor
 +
 +  @param  RootBridgeA pointer to the 
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL instance.
 +  @param  BarAddressSpace   A pointer to the ACPI 2.0 resource 
descriptors that describe the current
 +configuration of this BAR of the PCI 
controller that is to be updated.
 +
 +  @retval EFI_SUCCESS   The descriptor was successfully updated.
 +  @retval EFI_UNSUPPORTED   No resource in the root bridge matches the 
BAR region
 +  @retval EFI_OUT_OF_RESOURCES  There are not enough resources available to 
allocate
 +Resources.
 +
 +**/
 +STATIC
 +EFI_STATUS
 +PciBarUpdateTranslationOffset(
 +  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL   *RootBridge,
 +  IN OUT EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *BarAddressSpace)
 +{
 +  EFI_STATUS Status;
 +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  *RootDescriptors;
 +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  *Desc;
 +  UINT8  *Temp;
 +
 +  Status = RootBridge->Configuration (RootBridge, (VOID **) );
 +  if (EFI_ERROR (Status)) {
 +return Status;
 +  }
 +
 +  Temp = (UINT8 *) RootDescriptors;
 +  while (*Temp == ACPI_ADDRESS_SPACE_DESCRIPTOR) {
 +Desc = (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *) Temp;
 +
 +//
 +// Do we have the right type of descriptor ?
 +//
 +if (Desc->ResType == BarAddressSpace->ResType) {
 +  //
 +  // Check if the BAR base fits
 +  //
 +  if (BarAddressSpace->AddrRangeMin >= Desc->AddrRangeMin &&
 +  BarAddressSpace->AddrRangeMin < (Desc->AddrRangeMin + 
Desc->AddrLen)) {
 +//
 +// Found it, update offset and return
 +//
 +BarAddressSpace->AddrTranslationOffset = Desc->AddrTranslationOffset;
 +return EFI_SUCCESS;
 +  }
 +}
 +Temp += sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR);
 +  }
 +  return EFI_UNSUPPORTED;
 +}
 +
 +/**
Gets the attributes that this PCI controller supports setting on a BAR using
SetBarAttributes(), and retrieves the list of resource descriptors for a 
BAR.
  
 @@ -1778,6 +1834,7 @@ PciIoGetBarAttributes (
PCI_IO_DEVICE *PciIoDevice;
EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *AddressSpace;
EFI_ACPI_END_TAG_DESCRIPTOR   *End;
 +  EFI_STATUSStatus;
  
PciIoDevice = PCI_IO_DEVICE_FROM_PCI_IO_THIS (This);
  
 @@ -1878,6 +1935,15 @@ PciIoGetBarAttributes (
  }
  
  //
 +// Update the AddrTranslationOffset field
 +//
 +Status = PciBarUpdateTranslationOffset(PciIoDevice->PciRootBridgeIo, 
AddressSpace);
 +if (EFI_ERROR (Status)) {
 +  FreePool(AddressSpace);
 +  return Status;
 +}
 +
 +//
  // put the checksum
  //
  End   = (EFI_ACPI_END_TAG_DESCRIPTOR *) (AddressSpace + 1);
View

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Benjamin Herrenschmidt 
> Cc: Andrew Fish 
> Cc: Jeff Fan 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 37
> ++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> index 50ed866..5cee8ca 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> @@ -1774,8 +1774,10 @@ PciIoGetBarAttributes (
>    OUT VOID   **Resources OPTIONAL
>    )
>  {
> +  EFI_STATUSStatus;
>    PCI_IO_DEVICE *PciIoDevice;
>    EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor;
> +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Configuration;
>    EFI_ACPI_END_TAG_DESCRIPTOR   *End;
>  
>    PciIoDevice = 

Re: [edk2] PCD Local Token Numbers in PEI/DXE

[Tim Lewis]

Star --

I think that would work. The copy would have to be by GUID/token number/SKU 
(for DynamicEx) and token number/SKU (for Dynamic)

The downside would be that the PEI copy would have priority, even if the DXE 
copy were newer.

Tim

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com] 
Sent: Wednesday, February 17, 2016 6:48 PM
To: Kinney, Michael D ; Tim Lewis 
; edk2-devel@lists.01.org
Subject: RE: PCD Local Token Numbers in PEI/DXE

Could we let PEI PCD database includes all PCDs' information used in PEI phase 
and DXE PCD database includes all PCDs' information (include PCDs used by both 
PEI and DXE) used in DXE phase.
DXE PCD driver is to sync the value of PCDs used by both PEI and DXE.

Thanks,
Star
-Original Message-
From: Kinney, Michael D
Sent: Thursday, February 18, 2016 1:21 AM
To: Zeng, Star; Tim Lewis; edk2-devel@lists.01.org; Kinney, Michael D
Subject: RE: PCD Local Token Numbers in PEI/DXE

Star,

I agree if PCDs are added to PEI Database that are also present in DXE 
Database, there could be a conflict.

There are several cases we need to consider to support separate update of PEI 
and DXE databases:

1) Add one or more PCDs to PEI Database that are not used in DXE Phase
2) Add one or more PCDs to PEI Database that are used in DXE Phase
3) Remove one or more PCDs from PEI Database that are not used in DXE Phase
4) Remove one or more PCDs from PEI Database that are used in DXE Phase
5) Add one or more PCDs to DXE Database that are not used in PEI Phase
6) Add one or more PCDs to DXE Database that are used in PEI Phase
7) Remove one or more PCDs from DXE Database that are not used in PEI Phase
8) Remove one or more PCDs from DXE Database that are used in PEI Phase

Case (1), (3), (5), (6), (7), and (8) should be relatively easy to support

Case (2) is the one you raised, where there could a conflict in the Default 
Value, Storage Type, and size.

Case (4) is even harder, because DXE Phase depends on PCDs passed up from PEI 
that are no longer there.  This should be an ASSERT()/failure.

I also want to emphasis that the PCD database needs to support 3 types of 
platform builds for PCD types:

A) 100% Dynamic PCDs (Usually used for source builds)
B) A mix of Dynamic and DynamicEx PCDs (Usually used for source builds with a 
few pre-built binary modules mixed in)
C) 100% DynamicEx PCDs (Used for 100% pre-built binary modules)

If we detect case (C), I think we can build the PEI and DXE databases so they 
do not use local tokens at all and avoid the local token number issue raised by 
Tim.  For (A) and (C), we might consider using 2 different ranges of local 
token numbers, so the number of local token numbers allocated to PEI and DXE 
database can change without token number overlaps.

Thanks,

Mike


> -Original Message-
> From: Zeng, Star
> Sent: Sunday, February 14, 2016 9:33 PM
> To: Kinney, Michael D ; Tim Lewis 
> ; edk2-devel@lists.01.org
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Mike,
> 
> Could one PCD be accessed using both methods Dynamic and DynamicEx in one 
> build?
> As I know, it could not.
> 
> Another problem is about where the default PCD value stores. 
> Currently, PEI and PEI+DXE phase consumed PCDs are stored in PEI PCD 
> database, and only DXE phase consumed PCDs are stored in DXE PCD database.
> If the new PEI consumes 4+ PCDs, the 4+ PCDs will be stored in PEI 
> database, and if DXE also consumes them, the new DXE would not work 
> with old PEI. And is it a valid case to only update DXE FV?
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael D
> Sent: Thursday, February 11, 2016 2:21 AM
> To: Tim Lewis; edk2-devel@lists.01.org; Kinney, Michael D
> Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE
> 
> Tim,
> 
> All good ideas to evaluate.
> 
> We did design in the Dynamic PCDs with generated local tokens to 
> minimize the size overhead of the PCD database for source builds.  We 
> can do some size impact analysis of these ideas to see which one makes the 
> most sense.
> 
> The database is currently optimized for Dynamic PCDs.  When a 
> DynamicEx PCD is used it is internally translated to a Dynamic 
> request.  I think all of the ideas here require this concept to be 
> reversed.  We need to optimized the database for DynamicEx and never 
> reference Dynamic part of database to process a DynamicEx request.  If 
> Dynamic is used, it can either be internally translated to a DynamicEx 
> request with a fixed token space guid or be processed as a local 
> token.  In mixed Dynamic/DynamicEx environments, the same PCD may be accessed 
> using both methods.  Current design supports this mixed env, so we need to 
> make sure that aspect is not broken if we change internal code/database.
> 
> Best regards,
> 
> Mike
> 
> > 

Re: [edk2] [patch] MdeModulePkg: Make HII configuration settings available to OS runtime

[Dong, Eric]

Correct one error in former mail, the extra data size cost is the runtime 
memory cost instead of bios flash data cost.

Thanks,
Eric

> -Original Message-
> From: Dong, Eric
> Sent: Thursday, February 18, 2016 10:51 AM
> To: El-Haj-Mahmoud, Samer; Andrew Fish; Brian J. Johnson
> Cc: Bi, Dandan; edk2-devel@lists.01.org; Gao, Liming; Dong, Eric; Rothman, 
> Michael A; Hale, Robert P; Kinney, Michael D
> Subject: RE: [edk2] [patch] MdeModulePkg: Make HII configuration settings 
> available to OS runtime
> 
> Hi All,
> 
> Thanks for your comments. I add my explanation below:
> 
> Only hook ReadyToBoot event is not enough. Different drivers may hook this 
> event and some may update string package in their callback
> function. The order to call these callback functions is random, so only hook 
> this event may miss some changes.
> 
> This feature is described in UEFI spec 2.6 chapter 31.2.11.1. It required to 
> export all HiiDatabae data and current configuration data. We
> add this feature because we strongly encourage the export of config data to 
> support manageability of platform config both for pre-OS and
> OS runtime operations.
> 
> Also we collect the performance data from our reference platform(Detail see 
> below). The boot performance is small and we can ignore it.
> This feature cost extra 869KB, but we think the size cost is not care because 
> current we use 16M size of bios flash.
> 
> HiiDatabase driver data size cost(This feature add in HiiDatabase driver):
>   Without this feature:
>   Used data size: 151KB
>   With this feature
>   Used data size: 1020 KB
>   PS: This extra size cost mainly depend on how much Hii packages in your 
> platform.
> 
> Boot Time cost:
>   Without this feature:
>   Boot Time cost:1st:3.353s   2nd: 3.035s
>   With this feature:
>   Boot Time cost:1st: 3.125s  2nd: 3.126s
> 
> Base on the above analysis, we provide this design and prefer to always 
> enable this feature instead of use a PCD to control it.
> 
> Thanks,
> Eric
> 
> > -Original Message-
> > From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
> > Sent: Wednesday, February 17, 2016 2:14 AM
> > To: Andrew Fish; Brian J. Johnson
> > Cc: Bi, Dandan; edk2-devel@lists.01.org; Dong, Eric; Gao, Liming
> > Subject: RE: [edk2] [patch] MdeModulePkg: Make HII configuration settings 
> > available to OS runtime
> >
> > +1
> >
> > I also would add there may be some HII strings that are hidden from user 
> > interfaces, and reflect settings for field service or
> > troubleshooting, and that a mass export to the OS may expose these settings 
> > to OS runtime code and possibly applications.
> >
> >
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > Andrew Fish
> > Sent: Tuesday, February 16, 2016 10:37 AM
> > To: Brian J. Johnson 
> > Cc: Dandan Bi ; edk2-devel@lists.01.org; Eric Dong 
> > ; Liming Gao 
> > Subject: Re: [edk2] [patch] MdeModulePkg: Make HII configuration settings 
> > available to OS runtime
> >
> >
> > > On Feb 16, 2016, at 8:33 AM, Brian J. Johnson  wrote:
> > >
> > > On 02/16/2016 12:58 AM, Dandan Bi wrote:
> > >> This feature is aimed to allow OS make use of the HII database during
> > >> runtime. In this case, the contents of the HII Database is exported
> > >> to a buffer. The pointer to the buffer is placed in the EFI System
> > >> Configuration Table, where it can be retrieved by an OS application.
> > >>
> > >> Export the configuration data and contents of HiiDatabase when driver
> > >> add package, update package and remove package.
> > >> For string and image may also need to update the contents of
> > >> HiiDatabase when NewString/SetString, NewImage/SetImage.
> > >>
> > >> Cc: Liming Gao 
> > >> Cc: Eric Dong 
> > >> Contributed-under: TianoCore Contribution Agreement 1.0
> > >> Signed-off-by: Dandan Bi  ...
> > >
> > > Please make this behavior selectable via a PCD.  HII operations are very 
> > > expensive, especially on simulators.  I don't want to pay the
> > export time every time a package is added or string is changed.  Also, 
> > platforms should be able to decide if they want to offer this data
> to
> > the OS.
> > >
> >
> > +1
> >
> > I would want to opt out to NOT take the memory away from the OS if the 
> > platform did not care about the feature.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> > > Why not just export the data once, using a "ready to boot" event hook?
> > >
> > > Thanks,
> > > --
> > >
> > > Brian J. Johnson
> > >
> > > 
> > >
> > >  My statements are my own, are not authorized by SGI, and do not
> > > necessarily represent SGI's positions.
> > > 

Re: [edk2] [patch] MdeModulePkg: Make HII configuration settings available to OS runtime

[Dong, Eric]

Hi All,

Thanks for your comments. I add my explanation below:

Only hook ReadyToBoot event is not enough. Different drivers may hook this 
event and some may update string package in their callback function. The order 
to call these callback functions is random, so only hook this event may miss 
some changes.

This feature is described in UEFI spec 2.6 chapter 31.2.11.1. It required to 
export all HiiDatabae data and current configuration data. We add this feature 
because we strongly encourage the export of config data to support 
manageability of platform config both for pre-OS and OS runtime operations. 

Also we collect the performance data from our reference platform(Detail see 
below). The boot performance is small and we can ignore it. This feature cost 
extra 869KB, but we think the size cost is not care because current we use 16M 
size of bios flash.  

HiiDatabase driver data size cost(This feature add in HiiDatabase driver):
Without this feature: 
Used data size: 151KB
With this feature
Used data size: 1020 KB   
PS: This extra size cost mainly depend on how much Hii packages in your 
platform.

Boot Time cost:
Without this feature:
Boot Time cost:1st:3.353s   2nd: 3.035s
With this feature:
Boot Time cost:1st: 3.125s  2nd: 3.126s

Base on the above analysis, we provide this design and prefer to always enable 
this feature instead of use a PCD to control it.

Thanks,
Eric

> -Original Message-
> From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
> Sent: Wednesday, February 17, 2016 2:14 AM
> To: Andrew Fish; Brian J. Johnson
> Cc: Bi, Dandan; edk2-devel@lists.01.org; Dong, Eric; Gao, Liming
> Subject: RE: [edk2] [patch] MdeModulePkg: Make HII configuration settings 
> available to OS runtime
> 
> +1
> 
> I also would add there may be some HII strings that are hidden from user 
> interfaces, and reflect settings for field service or
> troubleshooting, and that a mass export to the OS may expose these settings 
> to OS runtime code and possibly applications.
> 
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
> Fish
> Sent: Tuesday, February 16, 2016 10:37 AM
> To: Brian J. Johnson 
> Cc: Dandan Bi ; edk2-devel@lists.01.org; Eric Dong 
> ; Liming Gao 
> Subject: Re: [edk2] [patch] MdeModulePkg: Make HII configuration settings 
> available to OS runtime
> 
> 
> > On Feb 16, 2016, at 8:33 AM, Brian J. Johnson  wrote:
> >
> > On 02/16/2016 12:58 AM, Dandan Bi wrote:
> >> This feature is aimed to allow OS make use of the HII database during
> >> runtime. In this case, the contents of the HII Database is exported
> >> to a buffer. The pointer to the buffer is placed in the EFI System
> >> Configuration Table, where it can be retrieved by an OS application.
> >>
> >> Export the configuration data and contents of HiiDatabase when driver
> >> add package, update package and remove package.
> >> For string and image may also need to update the contents of
> >> HiiDatabase when NewString/SetString, NewImage/SetImage.
> >>
> >> Cc: Liming Gao 
> >> Cc: Eric Dong 
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Dandan Bi  ...
> >
> > Please make this behavior selectable via a PCD.  HII operations are very 
> > expensive, especially on simulators.  I don't want to pay the
> export time every time a package is added or string is changed.  Also, 
> platforms should be able to decide if they want to offer this data to
> the OS.
> >
> 
> +1
> 
> I would want to opt out to NOT take the memory away from the OS if the 
> platform did not care about the feature.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Why not just export the data once, using a "ready to boot" event hook?
> >
> > Thanks,
> > --
> >
> > Brian J. Johnson
> >
> > 
> >
> >  My statements are my own, are not authorized by SGI, and do not
> > necessarily represent SGI's positions.
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

[edk2] [Patch 2/2] MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes

[Ruiyu Ni]

Some platform doesn't use CPU(HOST)/Device 1:1 mapping for PCI Bus.
But PCI IO doesn't have interface to tell caller (device driver)
whether the address returned by GetBarAttributes() is HOST address
or device address.
UEFI Spec 2.6 addresses this issue by clarifying the address returned
is HOST address and caller can use AddrTranslationOffset to calculate
the device address.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Benjamin Herrenschmidt 
Cc: Andrew Fish 
Cc: Jeff Fan 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 37 ++
 1 file changed, 37 insertions(+)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
index 50ed866..5cee8ca 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
@@ -1774,8 +1774,10 @@ PciIoGetBarAttributes (
   OUT VOID   **Resources OPTIONAL
   )
 {
+  EFI_STATUSStatus;
   PCI_IO_DEVICE *PciIoDevice;
   EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor;
+  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Configuration;
   EFI_ACPI_END_TAG_DESCRIPTOR   *End;
 
   PciIoDevice = PCI_IO_DEVICE_FROM_PCI_IO_THIS (This);
@@ -1863,6 +1865,41 @@ PciIoGetBarAttributes (
 End   = (EFI_ACPI_END_TAG_DESCRIPTOR *) (Descriptor + 1);
 End->Desc = ACPI_END_TAG_DESCRIPTOR;
 End->Checksum = 0;
+
+//
+// Get the Address Translation Offset
+//
+if (Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) {
+  Status = PciIoDevice->PciRootBridgeIo->Configuration (
+   PciIoDevice->PciRootBridgeIo,
+   (VOID **) 
+   );
+  if (!EFI_ERROR (Status)) {
+while (Configuration->Desc == Descriptor->Desc) {
+  if ((Configuration->ResType == Descriptor->ResType) &&
+  (Configuration->AddrRangeMin <= Descriptor->AddrRangeMin) &&
+  (Configuration->AddrRangeMin + Configuration->AddrLen >= 
Descriptor->AddrRangeMin + Descriptor->AddrLen)
+  ) {
+Descriptor->AddrTranslationOffset = 
Configuration->AddrTranslationOffset;
+break;
+  }
+  Configuration++;
+}
+
+//
+// The resource occupied by BAR should be in the range reported by 
RootBridge.
+//
+ASSERT (Configuration->Desc == Descriptor->Desc);
+if (Configuration->Desc != Descriptor->Desc) {
+  Status = EFI_UNSUPPORTED;
+}
+  }
+
+  if (EFI_ERROR (Status)) {
+FreePool (Descriptor);
+return Status;
+  }
+}
   }
 
   return EFI_SUCCESS;
-- 
2.7.0.windows.1

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

[edk2] [Patch 0/2] Return AddrTranslationOffset in GetBarAttributes

[Ruiyu Ni]

Some platform doesn't use CPU(HOST)/Device 1:1 mapping for PCI Bus.
But PCI IO doesn't have interface to tell caller (device driver)
whether the address returned by GetBarAttributes() is HOST address
or device address.
UEFI Spec 2.6 addresses this issue by clarifying the address returned
is HOST address and caller can use AddrTranslationOffset to calculate
the device address.


Ruiyu Ni (2):
  MdeModulePkg/PciBus: Refine to reduce code lines.
  MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes

 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 105 +++--
 1 file changed, 60 insertions(+), 45 deletions(-)

-- 
2.7.0.windows.1

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

[edk2] [Patch 1/2] MdeModulePkg/PciBus: Refine to reduce code lines.

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
Cc: Jeff Fan 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 70 --
 1 file changed, 24 insertions(+), 46 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
index 4160632..50ed866 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
@@ -1,7 +1,7 @@
 /** @file
   EFI PCI IO protocol functions implementation for PCI Bus module.
 
-Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -1774,9 +1774,8 @@ PciIoGetBarAttributes (
   OUT VOID   **Resources OPTIONAL
   )
 {
-  UINT8 *Configuration;
   PCI_IO_DEVICE *PciIoDevice;
-  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *AddressSpace;
+  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor;
   EFI_ACPI_END_TAG_DESCRIPTOR   *End;
 
   PciIoDevice = PCI_IO_DEVICE_FROM_PCI_IO_THIS (This);
@@ -1798,19 +1797,18 @@ PciIoGetBarAttributes (
   }
 
   if (Resources != NULL) {
-Configuration = AllocateZeroPool (sizeof 
(EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) + sizeof (EFI_ACPI_END_TAG_DESCRIPTOR));
-if (Configuration == NULL) {
+Descriptor = AllocateZeroPool (sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) 
+ sizeof (EFI_ACPI_END_TAG_DESCRIPTOR));
+if (Descriptor == NULL) {
   return EFI_OUT_OF_RESOURCES;
 }
 
-AddressSpace = (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *) Configuration;
+*Resources   = Descriptor;
 
-AddressSpace->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
-AddressSpace->Len  = (UINT16) (sizeof 
(EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3);
-
-AddressSpace->AddrRangeMin = PciIoDevice->PciBar[BarIndex].BaseAddress;
-AddressSpace->AddrLen  = PciIoDevice->PciBar[BarIndex].Length;
-AddressSpace->AddrRangeMax = PciIoDevice->PciBar[BarIndex].Alignment;
+Descriptor->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
+Descriptor->Len  = (UINT16) (sizeof 
(EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3);
+Descriptor->AddrRangeMin = PciIoDevice->PciBar[BarIndex].BaseAddress;
+Descriptor->AddrLen  = PciIoDevice->PciBar[BarIndex].Length;
+Descriptor->AddrRangeMax = PciIoDevice->PciBar[BarIndex].Alignment;
 
 switch (PciIoDevice->PciBar[BarIndex].BarType) {
 case PciBarTypeIo16:
@@ -1818,59 +1816,41 @@ PciIoGetBarAttributes (
   //
   // Io
   //
-  AddressSpace->ResType = ACPI_ADDRESS_SPACE_TYPE_IO;
-  break;
-
-case PciBarTypeMem32:
-  //
-  // Mem
-  //
-  AddressSpace->ResType = ACPI_ADDRESS_SPACE_TYPE_MEM;
-  //
-  // 32 bit
-  //
-  AddressSpace->AddrSpaceGranularity = 32;
+  Descriptor->ResType = ACPI_ADDRESS_SPACE_TYPE_IO;
   break;
 
 case PciBarTypePMem32:
   //
-  // Mem
-  //
-  AddressSpace->ResType = ACPI_ADDRESS_SPACE_TYPE_MEM;
-  //
   // prefechable
   //
-  AddressSpace->SpecificFlag = 0x6;
-  //
-  // 32 bit
-  //
-  AddressSpace->AddrSpaceGranularity = 32;
-  break;
+  Descriptor->SpecificFlag = 
EFI_ACPI_MEMORY_RESOURCE_SPECIFIC_FLAG_CACHEABLE_PREFETCHABLE;
 
-case PciBarTypeMem64:
+case PciBarTypeMem32:
   //
   // Mem
   //
-  AddressSpace->ResType = ACPI_ADDRESS_SPACE_TYPE_MEM;
+  Descriptor->ResType = ACPI_ADDRESS_SPACE_TYPE_MEM;
   //
-  // 64 bit
+  // 32 bit
   //
-  AddressSpace->AddrSpaceGranularity = 64;
+  Descriptor->AddrSpaceGranularity = 32;
   break;
 
 case PciBarTypePMem64:
   //
-  // Mem
+  // prefechable
   //
-  AddressSpace->ResType = ACPI_ADDRESS_SPACE_TYPE_MEM;
+  Descriptor->SpecificFlag = 
EFI_ACPI_MEMORY_RESOURCE_SPECIFIC_FLAG_CACHEABLE_PREFETCHABLE;
+
+case PciBarTypeMem64:
   //
-  // prefechable
+  // Mem
   //
-  AddressSpace->SpecificFlag = 0x6;
+  Descriptor->ResType = ACPI_ADDRESS_SPACE_TYPE_MEM;
   //
   // 64 bit
   //
-  AddressSpace->AddrSpaceGranularity = 64;
+  Descriptor->AddrSpaceGranularity = 64;
   break;
 
 default:
@@ -1880,11 +1860,9 @@ PciIoGetBarAttributes (
 //
 // put the checksum
 //
-End   = (EFI_ACPI_END_TAG_DESCRIPTOR *) (AddressSpace + 1);
+End   = (EFI_ACPI_END_TAG_DESCRIPTOR *) (Descriptor + 1);
 End->Desc = ACPI_END_TAG_DESCRIPTOR;
 End->Checksum = 0;
-
-*Resources= Configuration;
   }
 
   return EFI_SUCCESS;
-- 
2.7.0.windows.1

Re: [edk2] [Patch] BaseTools/VolInfo: add some generic options

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yonghong 
Zhu
Sent: Wednesday, February 17, 2016 6:33 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] BaseTools/VolInfo: add some generic options

The Help information provided by VolInfo does not follow the EDK II Tools
Design doc, so this patch update the help text and add the generic
options: -d, -v, -q, -s.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/C/VolInfo/VolInfo.c | 141 +++
 1 file changed, 94 insertions(+), 47 deletions(-)

diff --git a/BaseTools/Source/C/VolInfo/VolInfo.c 
b/BaseTools/Source/C/VolInfo/VolInfo.c
index 4fa87d4..ba26042 100644
--- a/BaseTools/Source/C/VolInfo/VolInfo.c
+++ b/BaseTools/Source/C/VolInfo/VolInfo.c
@@ -37,10 +37,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include "EfiUtilityMsgs.h"
 #include "FirmwareVolumeBufferLib.h"
 #include "OsPath.h"
 #include "ParseGuidedSectionTools.h"
 #include "StringFuncs.h"
+#include "ParseInf.h"
 
 //
 // Utility global variables
 //
 
@@ -161,10 +162,11 @@ Returns:
   EFI_FIRMWARE_VOLUME_HEADER  *FvImage;
   UINT32  FvSize;
   EFI_STATUS  Status;
   int Offset;
   BOOLEAN ErasePolarity;
+  UINT64  LogLevel;
 
   SetUtilityName (UTILITY_NAME);
   //
   // Print utility header
   //
@@ -173,32 +175,50 @@ Returns:
 UTILITY_MAJOR_VERSION,
 UTILITY_MINOR_VERSION,
 __BUILD_VERSION
 );
 
-  //
-  // Save, and then skip filename arg
-  //
-  mUtilityFilename = argv[0];
+  if (argc == 1) {
+Usage ();
+return -1;
+  }
+
   argc--;
   argv++;
-
+  LogLevel = 0;
   Offset = 0;
 
   //
+  // Look for help options
+  //
+  if ((strcmp(argv[0], "-h") == 0) || (strcmp(argv[0], "--help") == 0) ||
+  (strcmp(argv[0], "-?") == 0) || (strcmp(argv[0], "/?") == 0)) {
+Usage();
+return  STATUS_SUCCESS;
+  }
+  //
+  // Version has already be printed, so just return success
+  //
+  if (strcmp(argv[0], "--version") == 0) {
+return  STATUS_SUCCESS;
+  }
+
+  //
   // If they specified -x xref guid/basename cross-reference files, process it.
   // This will print the basename beside each file guid. To use it, specify
   // -x xref_filename to processdsc, then use xref_filename as a parameter
   // here.
   //
-  while (argc > 2) {
+  while (argc > 0) {
 if ((strcmp(argv[0], "-x") == 0) || (strcmp(argv[0], "--xref") == 0)) {
   ParseGuidBaseNameFile (argv[1]);
   printf("ParseGuidBaseNameFile: %s\n", argv[1]);
   argc -= 2;
   argv += 2;
-} else if (strcmp(argv[0], "--offset") == 0) {
+  continue;
+}
+if (strcmp(argv[0], "--offset") == 0) {
   //
   // Hex or decimal?
   //
   if ((argv[1][0] == '0') && (tolower ((int)argv[1][1]) == 'x')) {
 if (sscanf (argv[1], "%x", ) != 1) {
@@ -218,42 +238,59 @@ Returns:
 }
   }
 
   argc -= 2;
   argv += 2;
-} else {
-  Usage ();
-  return -1;
+  continue;
 }
+
+if ((stricmp (argv[0], "-v") == 0) || (stricmp (argv[0], "--verbose") == 
0)) {
+  SetPrintLevel (VERBOSE_LOG_LEVEL);
+  argc --;
+  argv ++;
+  continue;
+}
+
+if ((stricmp (argv[0], "-q") == 0) || (stricmp (argv[0], "--quiet") == 0)) 
{
+  SetPrintLevel (KEY_LOG_LEVEL);
+  argc --;
+  argv ++;
+  continue;
+}
+
+if ((stricmp (argv[0], "-d") == 0) || (stricmp (argv[0], "--debug") == 0)) 
{
+  Status = AsciiStringToUint64 (argv[1], FALSE, );
+  if (EFI_ERROR (Status)) {
+Error (NULL, 0, 1003, "Invalid option value", "%s = %s", argv[0], 
argv[1]);
+return -1;
+  }
+  if (LogLevel > 9) {
+Error (NULL, 0, 1003, "Invalid option value", "Debug Level range is 
0-9, current input level is %d", (int) LogLevel);
+return -1;
+  }
+  SetPrintLevel (LogLevel);
+  DebugMsg (NULL, 0, 9, "Debug Mode Set", "Debug Output Mode Level %s is 
set!", argv[1]);
+  argc -= 2;
+  argv += 2;
+  continue;
+}
+
+mUtilityFilename = argv[0];
+argc --;
+argv ++;
   }
-  //
-  // Check for proper number of arguments
-  //
-  if (argc != 1) {
-Usage ();
-return STATUS_ERROR;
-  }
-  //
-  // Look for help options
-  //
-  if ((strcmp(argv[0], "-h") == 0) || (strcmp(argv[0], "--help") == 0) || 
-  (strcmp(argv[0], "-?") == 0) || (strcmp(argv[0], "/?") == 0)) {
-Usage();
-return STATUS_SUCCESS;
-  }
-  //
-  // Version has already been printed, return success.
-  //
-  if (strcmp(argv[0], "--version") == 0) {
-return STATUS_SUCCESS;
-  }
+
   //
   // Open the file containing the FV
   //
-  InputFile = fopen (LongFilePath (argv[0]), "rb");
+  if (mUtilityFilename == NULL) {
+Error (NULL, 0, 

Re: [edk2] [PATCH v2 1/2] ShellPkg/UefiDpLib: Refine the code of locating all handles in DpTrace.c.

[Zeng, Star]

On 2016/2/15 17:49, Zeng, Star wrote:

On 2016/2/15 17:07, Cinnamon Shia wrote:

Replace gBS->LocateHandle with gBS->LocateHandleBuffer

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
---
  ShellPkg/Library/UefiDpLib/DpTrace.c | 40

  1 file changed, 9 insertions(+), 31 deletions(-)


Reviewed-by: Star Zeng 


Committed at 64c51ed181545f2c9914ad49c8dcbabe2f9a32e2.





diff --git a/ShellPkg/Library/UefiDpLib/DpTrace.c
b/ShellPkg/Library/UefiDpLib/DpTrace.c
index d17d514..22b83d0 100644
--- a/ShellPkg/Library/UefiDpLib/DpTrace.c
+++ b/ShellPkg/Library/UefiDpLib/DpTrace.c
@@ -2,7 +2,7 @@
Trace reporting for the Dp utility.

Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved.
-  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
This program and the accompanying materials
are licensed and made available under the terms and conditions of
the BSD License
which accompanies this distribution.  The full text of the license
may be found at
@@ -153,8 +153,7 @@ DumpAllTrace(
UINTN TIndex;

EFI_HANDLE*HandleBuffer;
-  UINTN Size;
-  EFI_HANDLETempHandle;
+  UINTN HandleCount;
EFI_STATUSStatus;
EFI_STRINGStringPtrUnknown;

@@ -166,17 +165,7 @@ DumpAllTrace(

// Get Handle information
//
-  Size = 0;
-  HandleBuffer = 
-  Status  = gBS->LocateHandle (AllHandles, NULL, NULL, ,
);
-  if (Status == EFI_BUFFER_TOO_SMALL) {
-HandleBuffer = AllocatePool (Size);
-ASSERT (HandleBuffer != NULL);
-if (HandleBuffer == NULL) {
-  return;
-}
-Status  = gBS->LocateHandle (AllHandles, NULL, NULL, ,
HandleBuffer);
-  }
+  Status  = gBS->LocateHandleBuffer (AllHandles, NULL, NULL,
, );
if (EFI_ERROR (Status)) {
  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
(STR_DP_HANDLES_ERROR), gDpHiiHandle, Status);
}
@@ -232,7 +221,7 @@ DumpAllTrace(
AsciiStrToUnicodeStr (Measurement.Token, mUnicodeToken);
if (Measurement.Handle != NULL) {
  // See if the Handle is in the HandleBuffer
-for (TIndex = 0; TIndex < (Size / sizeof(HandleBuffer[0]));
TIndex++) {
+for (TIndex = 0; TIndex < HandleCount; TIndex++) {
if (Measurement.Handle == HandleBuffer[TIndex]) {
  DpGetNameFromHandle (HandleBuffer[TIndex]);
  break;
@@ -270,7 +259,7 @@ DumpAllTrace(
}
  }
}
-  if (HandleBuffer != ) {
+  if (HandleBuffer != NULL) {
  FreePool (HandleBuffer);
}
SHELL_FREE_NON_NULL (IncFlag);
@@ -536,8 +525,7 @@ ProcessHandles(
UINTN Index;
UINTN LogEntryKey;
UINTN Count;
-  UINTN Size;
-  EFI_HANDLETempHandle;
+  UINTN HandleCount;
EFI_STATUSStatus;
EFI_STRINGStringPtrUnknown;

@@ -548,17 +536,7 @@ ProcessHandles(
FreePool (StringPtr);
FreePool (StringPtrUnknown);

-  Size = 0;
-  HandleBuffer = 
-  Status  = gBS->LocateHandle (AllHandles, NULL, NULL, ,
);
-  if (Status == EFI_BUFFER_TOO_SMALL) {
-HandleBuffer = AllocatePool (Size);
-ASSERT (HandleBuffer != NULL);
-if (HandleBuffer == NULL) {
-  return Status;
-}
-Status  = gBS->LocateHandle (AllHandles, NULL, NULL, ,
HandleBuffer);
-  }
+  Status = gBS->LocateHandleBuffer (AllHandles, NULL, NULL,
, );
if (EFI_ERROR (Status)) {
  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
(STR_DP_HANDLES_ERROR), gDpHiiHandle, Status);
}
@@ -598,7 +576,7 @@ ProcessHandles(
mGaugeString[0] = 0;// Empty driver name by default
AsciiStrToUnicodeStr (Measurement.Token, mUnicodeToken);
// See if the Handle is in the HandleBuffer
-  for (Index = 0; Index < (Size / sizeof(HandleBuffer[0]));
Index++) {
+  for (Index = 0; Index < HandleCount; Index++) {
  if (Measurement.Handle == HandleBuffer[Index]) {
DpGetNameFromHandle (HandleBuffer[Index]); // Name is put
into mGaugeString
break;
@@ -630,7 +608,7 @@ ProcessHandles(
}
  }
}
-  if (HandleBuffer != ) {
+  if (HandleBuffer != NULL) {
  FreePool (HandleBuffer);
}
return Status;



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

Re: [edk2] [PATCH v2 2/2] PerformancePkg/Dp_App: Refine the code of locating all handles in DpTrace.c.

[Zeng, Star]

On 2016/2/15 17:49, Zeng, Star wrote:

On 2016/2/15 17:07, Cinnamon Shia wrote:

Replace gBS->LocateHandle with gBS->LocateHandleBuffer

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
---
  PerformancePkg/Dp_App/DpTrace.c | 40
+---
  1 file changed, 9 insertions(+), 31 deletions(-)


Reviewed-by: Star Zeng 


Committed at aae1a87555ed4a433fdf980085aa6e73ae27c576.





diff --git a/PerformancePkg/Dp_App/DpTrace.c
b/PerformancePkg/Dp_App/DpTrace.c
index d3df30f..632904f 100644
--- a/PerformancePkg/Dp_App/DpTrace.c
+++ b/PerformancePkg/Dp_App/DpTrace.c
@@ -2,7 +2,7 @@
Trace reporting for the Dp utility.

Copyright (c) 2009 - 2012, Intel Corporation. All rights
reserved.
-  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
This program and the accompanying materials
are licensed and made available under the terms and conditions of
the BSD License
which accompanies this distribution.  The full text of the license
may be found at
@@ -153,8 +153,7 @@ DumpAllTrace(
UINTN TIndex;

EFI_HANDLE*HandleBuffer;
-  UINTN Size;
-  EFI_HANDLETempHandle;
+  UINTN HandleCount;
EFI_STATUSStatus;
EFI_STRINGStringPtrUnknown;

@@ -166,17 +165,7 @@ DumpAllTrace(

// Get Handle information
//
-  Size = 0;
-  HandleBuffer = 
-  Status  = gBS->LocateHandle (AllHandles, NULL, NULL, ,
);
-  if (Status == EFI_BUFFER_TOO_SMALL) {
-HandleBuffer = AllocatePool (Size);
-ASSERT (HandleBuffer != NULL);
-if (HandleBuffer == NULL) {
-  return;
-}
-Status  = gBS->LocateHandle (AllHandles, NULL, NULL, ,
HandleBuffer);
-  }
+  Status  = gBS->LocateHandleBuffer (AllHandles, NULL, NULL,
, );
if (EFI_ERROR (Status)) {
  PrintToken (STRING_TOKEN (STR_DP_HANDLES_ERROR), Status);
}
@@ -232,7 +221,7 @@ DumpAllTrace(
AsciiStrToUnicodeStr (Measurement.Token, mUnicodeToken);
if (Measurement.Handle != NULL) {
  // See if the Handle is in the HandleBuffer
-for (TIndex = 0; TIndex < (Size / sizeof(HandleBuffer[0]));
TIndex++) {
+for (TIndex = 0; TIndex < HandleCount; TIndex++) {
if (Measurement.Handle == HandleBuffer[TIndex]) {
  GetNameFromHandle (HandleBuffer[TIndex]);
  break;
@@ -270,7 +259,7 @@ DumpAllTrace(
}
  }
}
-  if (HandleBuffer != ) {
+  if (HandleBuffer != NULL) {
  FreePool (HandleBuffer);
}
SafeFreePool ((VOID *) IncFlag);
@@ -536,8 +525,7 @@ ProcessHandles(
UINTN Index;
UINTN LogEntryKey;
UINTN Count;
-  UINTN Size;
-  EFI_HANDLETempHandle;
+  UINTN HandleCount;
EFI_STATUSStatus;
EFI_STRINGStringPtrUnknown;

@@ -548,17 +536,7 @@ ProcessHandles(
FreePool (StringPtr);
FreePool (StringPtrUnknown);

-  Size = 0;
-  HandleBuffer = 
-  Status  = gBS->LocateHandle (AllHandles, NULL, NULL, ,
);
-  if (Status == EFI_BUFFER_TOO_SMALL) {
-HandleBuffer = AllocatePool (Size);
-ASSERT (HandleBuffer != NULL);
-if (HandleBuffer == NULL) {
-  return Status;
-}
-Status  = gBS->LocateHandle (AllHandles, NULL, NULL, ,
HandleBuffer);
-  }
+  Status = gBS->LocateHandleBuffer (AllHandles, NULL, NULL,
, );
if (EFI_ERROR (Status)) {
  PrintToken (STRING_TOKEN (STR_DP_HANDLES_ERROR), Status);
}
@@ -598,7 +576,7 @@ ProcessHandles(
mGaugeString[0] = 0;// Empty driver name by default
AsciiStrToUnicodeStr (Measurement.Token, mUnicodeToken);
// See if the Handle is in the HandleBuffer
-  for (Index = 0; Index < (Size / sizeof(HandleBuffer[0]));
Index++) {
+  for (Index = 0; Index < HandleCount; Index++) {
  if (Measurement.Handle == HandleBuffer[Index]) {
GetNameFromHandle (HandleBuffer[Index]); // Name is put
into mGaugeString
break;
@@ -632,7 +610,7 @@ ProcessHandles(
}
  }
}
-  if (HandleBuffer != ) {
+  if (HandleBuffer != NULL) {
  FreePool (HandleBuffer);
}
return Status;



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

Re: [edk2] Why is the tools_def.txt file parsed 47 times on my fds build?

[Gao, Liming]

Andrew:
  This is great information. I will take look LoadToolDefFile first, then check 
parsing logic in C #include file. 

Thanks
Liming
-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Thursday, February 18, 2016 12:03 AM
To: Gao, Liming 
Cc: edk2-devel@lists.01.org 
Subject: Re: [edk2] Why is the tools_def.txt file parsed 47 times on my fds 
build?


> On Feb 17, 2016, at 6:34 AM, Gao, Liming  wrote:
> 
> Andrew:
>  Thanks for this report. Tottime is second or microsecond? If LoadToolDefFile 
> is called only once, how much performance can be saved?
> 


Liming,

Python cProfile produces data in the pstats format and time is in seconds. So 
it looks like the parse of the file takes 0.19 seconds, but doing it 47 times 
is almost 9 seconds. 

If you look at 
https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template 
you can see the file is 463 KB, so you end up parsing 21 GB of data every 
build. Note it is going to depend on the layout of the FVs for the platform as 
you need GUIDed encapsulation sections to see the performance hit. Thus me 
pruning the Conf/tools_def.txt down to a 10K file saved ~8 seconds of build 
time.

My profile run was on a dirty build so none of the modules rebuilt.  If you 
profile a clean build the stats change as a lot of time is spent parsing the C 
code for the #include infrastructure, and this shows up as spending time in 
regex functions. I seem to remember there was a regex function that ran for 
about 4+ seconds for example. 

You can also do this:

Update RunToolFromSource:
python -m cProfile -o  edk2.profile "`dirname 
$0`/../../Source/Python"/`basename $0`/`basename $0`.py $*

>From the command line:
python -m pstats edk2.profile
Welcome to the profile statistics browser.
% help
 
Documented commands (type help ):

EOF  add  callees  callers  quit  read  reverse  sort  stats  strip
 
Undocumented commands:
==
help
%

This gives you an interactive prompt that lets you browse the stats, and track 
callees and callers. There are also optional packages that let you build call 
graphs, and do other interesting things on the pstats object. I've not tried 
those out. 

Thanks,

Andrew Fish

> Thanks
> Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
> Fish
> Sent: Tuesday, February 16, 2016 5:42 PM
> To: edk2-devel@lists.01.org 
> Subject: [edk2] Why is the tools_def.txt file parsed 47 times on my fds build?
> 
> 
> I turned on profiling in Python:
> BaseTools/BinWrappers/PosixLike/RunToolFromSource:
> #!/usr/bin/env bash
> #python `dirname $0`/RunToolFromSource.py `basename $0` $*
> PYTHONPATH="`dirname $0`/../../Source/Python" \
>python -m cProfile -s time "`dirname $0`/../../Source/Python"/`basename 
> $0`/`basename $0`.py $*
> 
> 
> The slowest item in the working thread was ToolDefClassObject. 
> LoadToolDefFile()
> 
>   Ordered by: internal time
> 
>   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>   478.9320.190   10.9860.234 
> ToolDefClassObject.py:60(LoadToolDefFile)
>  40674781.3370.0001.3370.000 {method 'split' of 'str' objects}
>285191.0640.0001.0640.000 {method 'execute' of 
> 'sqlite3.Cursor' objects}
>   7333780.8260.0001.1610.000 StringIO.py:208(write)
>   710.6130.0090.6130.009 {method 'items' of 'dict' 
> objects}
>   230.4990.022   11.9050.518 
> GuidSection.py:245(__FindExtendTool__)
> 
> 
> I see it gets called at the beginning of the build from InitBuild() and that 
> makes sense. If I do a genmake build LoadToolDefFile() only gets called a 
> single time. 
> 
> But it looks like __FindExtendTool__ is also making calls:
> ToolDefinition = 
> ToolDefClassObject.ToolDefDict(GenFdsGlobalVariable.ConfDir).ToolsDefTxtDictionary
> 
> So it looks to me like class GuidSection() is parsing the tools_def.txt for 
> every GUID'ed section that has a GUID defined tool? How come this information 
> is not cached? 
> 
> Does anyone see a quick fix?
> 
> Thanks,
> 
> Andrew Fish 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH v2] BaseTools: LzmaCompress: fix gcc-6 warning "misleading-indentation"

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, February 18, 2016 3:18 AM
To: edk2-devel-01 
Cc: Justen, Jordan L ; Cole Robinson 
; Gao, Liming ; Zhu, Yonghong 

Subject: [PATCH v2] BaseTools: LzmaCompress: fix gcc-6 warning 
"misleading-indentation"

The way the first use of the "_maxMode" variable is commented out (i.e.,
together with the enclosing "if" statement) in GetOptimum() triggers the
"misleading-indentation" warning that is new in gcc-6.0, for the block of
code that originally depended on the "if" statement. Gcc believes
(mistakenly) that the programmer believes (mistakenly) that the block
depends on (repIndex == 0) higher up.

Restore the if statement, with a controlling expression that comprises the
constant 1 and "_maxMode" commented out.

Cc: Jordan Justen 
Cc: Cole Robinson 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Reported-by: Cole Robinson 
Suggested-by: Jordan Justen 
Build-tested-by: Cole Robinson 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1307439
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c 
b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
index 9b2dd16ffa48..c6717eeea3a0 100644
--- a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
+++ b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
@@ -1367,7 +1367,7 @@ static UInt32 GetOptimum(CLzmaEnc *p, UInt32 position, 
UInt32 *backRes)
   if (repIndex == 0)
 startLen = lenTest + 1;
 
-  /* if (_maxMode) */
+  if (1 /* _maxMode */)
 {
   UInt32 lenTest2 = lenTest + 1;
   UInt32 limit = lenTest2 + p->numFastBytes;
-- 
1.8.3.1

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

[edk2] [PATCH 7/7] CryptoPkg: Abuse internal headers to make OpenSSL HEAD build work

[David Woodhouse]

More stuff got hidden. Some of this is tolerable. Other bits are
horrid, but given that we expose *requires* that we know the size
of the data structure, it's hard to see how we can avoid it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse 
---
 CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacMd5.c  | 7 ---
 CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacSha1.c | 6 --
 CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c  | 1 +
 CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 2 ++
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c   | 1 +
 5 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacMd5.c 
b/CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacMd5.c
index 693cd32..93c2bcb 100644
--- a/CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacMd5.c
+++ b/CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacMd5.c
@@ -14,7 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include "InternalCryptLib.h"
 #include 
-
+#include <../hmac/hmac_lcl.h>
 /**
   Retrieves the size, in bytes, of the context buffer required for HMAC-MD5 
operations.
 
@@ -65,7 +65,8 @@ HmacMd5Init (
   //
   // OpenSSL HMAC-MD5 Context Initialization
   //
-  HMAC_CTX_init (HmacMd5Context);
+  memset(HmacMd5Context, 0, sizeof(HMAC_CTX));
+  HMAC_CTX_reset (HmacMd5Context);
   HMAC_Init_ex (HmacMd5Context, Key, (UINT32) KeySize, EVP_md5(), NULL);
 
   return TRUE;
@@ -191,7 +192,7 @@ HmacMd5Final (
   // OpenSSL HMAC-MD5 digest finalization
   //
   HMAC_Final (HmacMd5Context, HmacValue, );
-  HMAC_CTX_cleanup (HmacMd5Context);
+  HMAC_CTX_reset (HmacMd5Context);
 
   return TRUE;
 }
diff --git a/CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacSha1.c 
b/CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacSha1.c
index 881d26c..5710f26 100644
--- a/CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacSha1.c
+++ b/CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacSha1.c
@@ -14,6 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include "InternalCryptLib.h"
 #include 
+#include <../hmac/hmac_lcl.h>
 
 /**
   Retrieves the size, in bytes, of the context buffer required for HMAC-SHA1 
operations.
@@ -65,7 +66,8 @@ HmacSha1Init (
   //
   // OpenSSL HMAC-SHA1 Context Initialization
   //
-  HMAC_CTX_init (HmacSha1Context);
+  memset(HmacSha1Context, 0, sizeof(HMAC_CTX));
+  HMAC_CTX_reset (HmacSha1Context);
   HMAC_Init_ex (HmacSha1Context, Key, (UINT32) KeySize, EVP_sha1(), NULL);
 
   return TRUE;
@@ -191,7 +193,7 @@ HmacSha1Final (
   // OpenSSL HMAC-SHA1 digest finalization
   //
   HMAC_Final (HmacSha1Context, HmacValue, );
-  HMAC_CTX_cleanup (HmacSha1Context);
+  HMAC_CTX_reset (HmacSha1Context);
 
   return TRUE;
 }
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c 
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c
index 704eb4e..8e0d896 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c
@@ -17,6 +17,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 
 
 /**
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c 
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
index d495812..c6799ae 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
@@ -23,6 +23,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include <../evp/evp_locl.h>
 
 //
 // OID ASN.1 Value for SPC_RFC3161_OBJID ("1.3.6.1.4.1.311.3.3.1")
@@ -285,6 +286,7 @@ CheckTSTInfo (
   if (HashedMsg == NULL) {
 goto _Exit;
   }
+  memset(, 0, sizeof(MdCtx));
   EVP_DigestInit (, Md);
   EVP_DigestUpdate (, TimestampedData, DataSize);
   EVP_DigestFinal (, HashedMsg, NULL);
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c 
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
index 7dc4596..d392bed 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
@@ -15,6 +15,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include "InternalCryptLib.h"
 #include 
 #include 
+#include 
 
 /**
   Construct a X509 object from DER-encoded certificate data.
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/7] CryptoPkg/OpensslLib: Include complete copy of opensslconf.h

[David Woodhouse]

This can be an auto-generated file, and it *isn't* in the OpenSSL git tree;
it's only in the generated tarballs. So rather than including it in our
OpenSSL patch, just have the user copy it into place.

This makes it easier to manage changes, and is a step towards better
integration.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse 
---
 CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch | 323 -
 CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt|   6 +-
 CryptoPkg/Library/OpensslLib/opensslconf.h  | 497 

 3 files changed, 501 insertions(+), 325 deletions(-)

diff --git a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch 
b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch
index e4eaff6..65d61e2 100644
--- a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch
+++ b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch
@@ -352,329 +352,6 @@ diff U3 crypto/crypto.h crypto/crypto.h
  "Low level API call to cipher " #alg " forbidden in FIPS 
mode!")
  
  # else
-diff U3 crypto/opensslconf.h crypto/opensslconf.h
 crypto/opensslconf.h   Thu Jun 11 21:55:38 2015
-+++ crypto/opensslconf.h   Fri Jun 12 10:28:27 2015
-@@ -5,15 +5,72 @@
- extern "C" {
- #endif
- /* OpenSSL was configured with the following options: */
-+#ifndef OPENSSL_SYSNAME_UEFI
-+# define OPENSSL_SYSNAME_UEFI
-+#endif
- #ifndef OPENSSL_DOING_MAKEDEPEND
- 
- 
-+#ifndef OPENSSL_NO_BF
-+# define OPENSSL_NO_BF
-+#endif
-+#ifndef OPENSSL_NO_CAMELLIA
-+# define OPENSSL_NO_CAMELLIA
-+#endif
-+#ifndef OPENSSL_NO_CAPIENG
-+# define OPENSSL_NO_CAPIENG
-+#endif
-+#ifndef OPENSSL_NO_CAST
-+# define OPENSSL_NO_CAST
-+#endif
-+#ifndef OPENSSL_NO_CMS
-+# define OPENSSL_NO_CMS
-+#endif
-+#ifndef OPENSSL_NO_DEPRECATED
-+# define OPENSSL_NO_DEPRECATED
-+#endif
-+#ifndef OPENSSL_NO_DGRAM
-+# define OPENSSL_NO_DGRAM
-+#endif
-+#ifndef OPENSSL_NO_DSA
-+# define OPENSSL_NO_DSA
-+#endif
-+#ifndef OPENSSL_NO_DYNAMIC_ENGINE
-+# define OPENSSL_NO_DYNAMIC_ENGINE
-+#endif
-+#ifndef OPENSSL_NO_EC
-+# define OPENSSL_NO_EC
-+#endif
- #ifndef OPENSSL_NO_EC_NISTP_64_GCC_128
- # define OPENSSL_NO_EC_NISTP_64_GCC_128
- #endif
-+#ifndef OPENSSL_NO_ECDH
-+# define OPENSSL_NO_ECDH
-+#endif
-+#ifndef OPENSSL_NO_ECDSA
-+# define OPENSSL_NO_ECDSA
-+#endif
-+#ifndef OPENSSL_NO_ENGINE
-+# define OPENSSL_NO_ENGINE
-+#endif
-+#ifndef OPENSSL_NO_ENGINES
-+# define OPENSSL_NO_ENGINES
-+#endif
-+#ifndef OPENSSL_NO_FILENAMES
-+# define OPENSSL_NO_FILENAMES
-+#endif
-+#ifndef OPENSSL_NO_FP_API
-+# define OPENSSL_NO_FP_API
-+#endif
- #ifndef OPENSSL_NO_GMP
- # define OPENSSL_NO_GMP
- #endif
-+#ifndef OPENSSL_NO_GOST
-+# define OPENSSL_NO_GOST
-+#endif
-+#ifndef OPENSSL_NO_IDEA
-+# define OPENSSL_NO_IDEA
-+#endif
- #ifndef OPENSSL_NO_JPAKE
- # define OPENSSL_NO_JPAKE
- #endif
-@@ -23,30 +80,90 @@
- #ifndef OPENSSL_NO_LIBUNBOUND
- # define OPENSSL_NO_LIBUNBOUND
- #endif
-+#ifndef OPENSSL_NO_LOCKING
-+# define OPENSSL_NO_LOCKING
-+#endif
- #ifndef OPENSSL_NO_MD2
- # define OPENSSL_NO_MD2
- #endif
-+#ifndef OPENSSL_NO_MDC2
-+# define OPENSSL_NO_MDC2
-+#endif
-+#ifndef OPENSSL_NO_POSIX_IO
-+# define OPENSSL_NO_POSIX_IO
-+#endif
-+#ifndef OPENSSL_NO_RC2
-+# define OPENSSL_NO_RC2
-+#endif
- #ifndef OPENSSL_NO_RC5
- # define OPENSSL_NO_RC5
- #endif
-+#ifndef OPENSSL_NO_RCS
-+# define OPENSSL_NO_RCS
-+#endif
- #ifndef OPENSSL_NO_RFC3779
- # define OPENSSL_NO_RFC3779
- #endif
-+#ifndef OPENSSL_NO_RIPEMD
-+# define OPENSSL_NO_RIPEMD
-+#endif
-+#ifndef OPENSSL_NO_SCRYPT
-+# define OPENSSL_NO_SCRYPT
-+#endif
-+#ifndef OPENSSL_NO_SCT
-+# define OPENSSL_NO_SCT
-+#endif
- #ifndef OPENSSL_NO_SCTP
- # define OPENSSL_NO_SCTP
- #endif
-+#ifndef OPENSSL_NO_SEED
-+# define OPENSSL_NO_SEED
-+#endif
-+#ifndef OPENSSL_NO_SHA0
-+# define OPENSSL_NO_SHA0
-+#endif
-+#ifndef OPENSSL_NO_SOCK
-+# define OPENSSL_NO_SOCK
-+#endif
-+#ifndef OPENSSL_NO_SRP
-+# define OPENSSL_NO_SRP
-+#endif
- #ifndef OPENSSL_NO_SSL_TRACE
- # define OPENSSL_NO_SSL_TRACE
- #endif
-+#ifndef OPENSSL_NO_SSL2
-+# define OPENSSL_NO_SSL2
-+#endif
-+#ifndef OPENSSL_NO_SSL3
-+# define OPENSSL_NO_SSL3
-+#endif
-+#ifndef OPENSSL_NO_STDIO
-+# define OPENSSL_NO_STDIO
-+#endif
- #ifndef OPENSSL_NO_STORE
- # define OPENSSL_NO_STORE
- #endif
-+#ifndef OPENSSL_NO_UI
-+# define OPENSSL_NO_UI
-+#endif
- #ifndef OPENSSL_NO_UNIT_TEST
- # define OPENSSL_NO_UNIT_TEST
- #endif
-+#ifndef OPENSSL_NO_WHIRLPOOL
-+# define OPENSSL_NO_WHIRLPOOL
-+#endif
- 
- #endif /* OPENSSL_DOING_MAKEDEPEND */
- 
-+#ifndef OPENSSL_NO_ASM
-+# define OPENSSL_NO_ASM
-+#endif
-+#ifndef OPENSSL_NO_ERR
-+# define OPENSSL_NO_ERR
-+#endif
-+#ifndef OPENSSL_NO_HW
-+# define OPENSSL_NO_HW
-+#endif
- #ifndef OPENSSL_NO_DYNAMIC_ENGINE
- # define OPENSSL_NO_DYNAMIC_ENGINE
- #endif
-@@ -56,12 +173,66 @@
-who haven't had the time to do the appropriate changes in their
-applications.  */
- #ifdef OPENSSL_ALGORITHM_DEFINES
-+# if 

[edk2] [PATCH 1/7] CryptoPkg: Use OpenSSL include directory directly

[David Woodhouse]

In OpenSSL 1.1, all the public header files will reside directly in the
include/openssl/ directory of the source tree, rather than being symbolic
links. So we can just add that directory to our include path and not have
to worry about copying files around.

In fact, that *already* works on POSIX-compliant systems, because the
existing source release tarballs contain the required symlinks — they're
not created by the configuration. So we can switch our own include setup
now and kill the Install.sh for Linux, and change the Windows Install.cmd
script to copy the files there too.

When we update to 1.1, we can just kill Install.cmd completely (as well
as the patching step too, hopefully.)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse 
---
 CryptoPkg/CryptoPkg.dec  |   1 +
 CryptoPkg/Include/openssl/README |   1 -
 CryptoPkg/Library/OpensslLib/Install.cmd | 150 ++--
 CryptoPkg/Library/OpensslLib/Install.sh  |  79 ---
 CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt |   8 +-
 5 files changed, 81 insertions(+), 158 deletions(-)

diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec
index 4561f3f..05aad24 100644
--- a/CryptoPkg/CryptoPkg.dec
+++ b/CryptoPkg/CryptoPkg.dec
@@ -24,6 +24,7 @@
 
 [Includes]
   Include
+  Library/OpensslLib/openssl-1.0.2e/include
 
 [LibraryClasses]
   ##  @libraryclass  Provides basic library functions for cryptographic 
primitives.
diff --git a/CryptoPkg/Include/openssl/README b/CryptoPkg/Include/openssl/README
deleted file mode 100644
index 1594010..000
--- a/CryptoPkg/Include/openssl/README
+++ /dev/null
@@ -1 +0,0 @@
-This directory contains all the public include files from the OpenSSL project.
diff --git a/CryptoPkg/Library/OpensslLib/Install.cmd 
b/CryptoPkg/Library/OpensslLib/Install.cmd
index b9b6fc6..e441ce5 100755
--- a/CryptoPkg/Library/OpensslLib/Install.cmd
+++ b/CryptoPkg/Library/OpensslLib/Install.cmd
@@ -1,77 +1,77 @@
 cd openssl-1.0.2e
-copy e_os2.h..\..\..\Include\openssl
-copy crypto\crypto.h..\..\..\Include\openssl
-copy crypto\opensslv.h  ..\..\..\Include\openssl
-copy crypto\opensslconf.h   ..\..\..\Include\openssl
-copy crypto\ebcdic.h..\..\..\Include\openssl
-copy crypto\symhacks.h  ..\..\..\Include\openssl
-copy crypto\ossl_typ.h  ..\..\..\Include\openssl
-copy crypto\objects\objects.h   ..\..\..\Include\openssl
-copy crypto\objects\obj_mac.h   ..\..\..\Include\openssl
-copy crypto\md4\md4.h   ..\..\..\Include\openssl
-copy crypto\md5\md5.h   ..\..\..\Include\openssl
-copy crypto\sha\sha.h   ..\..\..\Include\openssl
-copy crypto\mdc2\mdc2.h ..\..\..\Include\openssl
-copy crypto\hmac\hmac.h ..\..\..\Include\openssl
-copy crypto\ripemd\ripemd.h ..\..\..\Include\openssl
-copy crypto\whrlpool\whrlpool.h ..\..\..\Include\openssl
-copy crypto\des\des.h   ..\..\..\Include\openssl
-copy crypto\des\des_old.h   ..\..\..\Include\openssl
-copy crypto\aes\aes.h   ..\..\..\Include\openssl
-copy crypto\rc2\rc2.h   ..\..\..\Include\openssl
-copy crypto\rc4\rc4.h   ..\..\..\Include\openssl
-copy crypto\idea\idea.h ..\..\..\Include\openssl
-copy crypto\bf\blowfish.h   ..\..\..\Include\openssl
-copy crypto\cast\cast.h ..\..\..\Include\openssl
-copy crypto\camellia\camellia.h ..\..\..\Include\openssl
-copy crypto\seed\seed.h ..\..\..\Include\openssl
-copy crypto\modes\modes.h   ..\..\..\Include\openssl
-copy crypto\bn\bn.h ..\..\..\Include\openssl
-copy crypto\ec\ec.h ..\..\..\Include\openssl
-copy crypto\rsa\rsa.h   ..\..\..\Include\openssl
-copy crypto\dsa\dsa.h   ..\..\..\Include\openssl
-copy crypto\ecdsa\ecdsa.h   ..\..\..\Include\openssl
-copy crypto\dh\dh.h ..\..\..\Include\openssl
-copy crypto\ecdh\ecdh.h ..\..\..\Include\openssl
-copy crypto\dso\dso.h   ..\..\..\Include\openssl
-copy crypto\engine\engine.h ..\..\..\Include\openssl
-copy crypto\buffer\buffer.h ..\..\..\Include\openssl
-copy crypto\bio\bio.h   ..\..\..\Include\openssl
-copy crypto\stack\stack.h   ..\..\..\Include\openssl
-copy crypto\stack\safestack.h   ..\..\..\Include\openssl
-copy crypto\lhash\lhash.h   ..\..\..\Include\openssl
-copy crypto\rand\rand.h ..\..\..\Include\openssl
-copy crypto\err\err.h   ..\..\..\Include\openssl
-copy crypto\evp\evp.h   ..\..\..\Include\openssl
-copy crypto\asn1\asn1.h ..\..\..\Include\openssl
-copy crypto\asn1\asn1_mac.h ..\..\..\Include\openssl
-copy crypto\asn1\asn1t.h..\..\..\Include\openssl
-copy crypto\pem\pem.h   ..\..\..\Include\openssl
-copy crypto\pem\pem2.h  ..\..\..\Include\openssl
-copy crypto\x509\x509.h ..\..\..\Include\openssl
-copy crypto\x509\x509_vfy.h 

[edk2] EDK2 vs. OpenSSL HEAD update

[David Woodhouse]

As of today, there are only two remaining fixes that still need to be
merged into OpenSSL HEAD to allow building for EDK2 out of the box.

These are RT4309, a trivial one-liner to provide a correct definition
of the PRIu64 macro for the EDK2 environment, and RT4175 to fix the
regression (also introduced in 1.0.2e) with verifying Authenticode
PKCS#7 signatures.

Hopefully these will be merged shortly.

In the meantime, here's another dump of the patch series to clean up
the OpenSSL integration and then switch over. Patches 1-5 in this
sequence do *not* require switching to OpenSSL HEAD, and stand alone.

The last patch in the series stands alone for reasons which will be
obvious when you see it.

David Woodhouse (7):
  CryptoPkg: Use OpenSSL include directory directly
  CryptoPkg/OpensslLib: Include complete copy of opensslconf.h
  CryptoPkg/OpensslLib: Update OpenSSL patch
  CryptoPkg/OpensslLib: Automatically configure OpenSSL and generate file 
list
  CryptoPkg/OpensslLib: Update to OpenSSL 1.0.2f
  CryptoPkg: Support building with OpenSSL HEAD (1.1.0-devel)
  CryptoPkg: Abuse internal headers to make OpenSSL HEAD build work

 CryptoPkg/CryptoPkg.dec |   2 +
 CryptoPkg/Include/OpenSslSupport.h  |   4 +
 CryptoPkg/Include/openssl/README|   1 -
 CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacMd5.c  |   7 +-
 CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacSha1.c |   6 +-
 CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c  |   1 +
 CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c |   2 +
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c   |   1 +
 CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch | 707 

 CryptoPkg/Library/OpensslLib/Install.cmd|  77 ---
 CryptoPkg/Library/OpensslLib/Install.sh |  79 ---
 CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt  |  44 ++
 CryptoPkg/Library/OpensslLib/OpensslLib.inf | 466 ++---
 CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt|  61 --
 CryptoPkg/Library/OpensslLib/opensslconf.h  | 262 
 CryptoPkg/Library/OpensslLib/process_files.sh   |  75 +++
 16 files changed, 447 insertions(+), 1348 deletions(-)



-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using PCD to set default policy for IPv4/IPv6

[El-Haj-Mahmoud, Samer]

1) Yes you could... that is one implementation choice. There are cases where 
you need to start multiple adapters, just for inventory/other management tasks, 
and you do not want all of them to default to DHCP/automatic

2) Yes a platform driver can set the policy through the PCDs. I thought this 
was the intention of introducing the PCDs. Previously, the policy was 
hard-coded to DHCP/auto in the EDK2 drivers.



-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, February 17, 2016 3:00 PM
To: El-Haj-Mahmoud, Samer ; Wu, Jiaxin 
; Subramanian, Sriram (EG Servers Platform SW) 
; Hegde, Nagaraj P ; Zimmer, Vincent 
; Li, Ruth ; Ye, Ting 
; Fu, Siyuan ; edk2-devel@lists.01.org; 
Kinney, Michael D 
Subject: RE: Using PCD to set default policy for IPv4/IPv6

Hi Samer,

1) If there are a large number of adapters, can you choose to only start the 
ones needed to boot?

2) Can't a platform driver set the policy needed for each NIC that is required 
to boot?

Mike



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> El-Haj-Mahmoud, Samer
> Sent: Wednesday, February 17, 2016 12:53 PM
> To: Kinney, Michael D ; Wu, Jiaxin 
> ; Subramanian, Sriram (EG Servers Platform SW) 
> ; Hegde, Nagaraj P ; 
> Zimmer, Vincent ; Li, Ruth 
> ; Ye, Ting ; Fu, Siyuan 
> ; edk2-devel@lists.01.org
> Subject: Re: [edk2] Using PCD to set default policy for IPv4/IPv6
> 
> I believe the PCDs are just to let the core drivers select the default 
> behavior (not full configuration) of automatic/DHCP vs. Static. Today, 
> the core drivers hard-code the default behavior to DHCP/automatic, and 
> that is not ideal in server platforms that may have a large number of 
> adapters.
> 
> 
> 
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, February 17, 2016 11:34 AM
> To: Wu, Jiaxin ; Subramanian, Sriram (EG Servers 
> Platform SW) ; El-Haj-Mahmoud, Samer 
> ; Hegde, Nagaraj P 
> ; Zimmer, Vincent ; 
> Li, Ruth ; Ye, Ting ; Fu, Siyuan 
> ; edk2-devel@lists.01.org; Kinney, Michael D 
> 
> Subject: RE: Using PCD to set default policy for IPv4/IPv6
> 
> Jiaxin,
> 
> If a platform module can set the policy for each network interface, 
> then why do we need to add PCDs?
> 
> Thanks,
> 
> Mike
> 
> From: Wu, Jiaxin
> Sent: Tuesday, February 16, 2016 6:30 PM
> To: Kinney, Michael D 
> >;
> Subramanian, Sriram (EG Servers Platform SW) 
> >; El-Haj-Mahmoud, Samer 
>  mahm...@hpe.com>>; Hegde, Nagaraj P 
>  p.he...@hpe.com>>; Zimmer, Vincent
> >; Li, Ruth 
> >; Ye, Ting 
> >; Fu, Siyuan 
> >; 
> edk2-devel@lists.01.org de...@lists.01.org>
> Subject: RE: Using PCD to set default policy for IPv4/IPv6
> 
> Mike,
> Thanks your comments.
> First, I agree other platform modules can also change the police by 
> using the set operation.
> Second for the complete design, the proposed for the new PCDs will 
> only be consumed by Ip4Dxe/Ip6Dxe modules. The PCDs are used by these 
> two modules to determine the default policy, the current Ip4Dxe/Ip6Dxe 
> driver will  make decision which more configuration information needed 
> to be also configured. So, I think this a complete design to cover the 
> IPv4/Ipv6 configuration protocol.
> 
> Thanks.
> Jiaxin
> 
> From: Kinney, Michael D
> Sent: Wednesday, February 17, 2016 6:10 AM
> To: Wu, Jiaxin >; 
> Subramanian, Sriram (EG Servers Platform SW) 
> >; El-Haj-Mahmoud, Samer 
> >; 
> Hegde, Nagaraj P 
> >; Zimmer, 
> Vincent >; 
> Li, Ruth >; Ye, Ting 
> >; Fu, Siyuan 
> >; 
> 

Re: [edk2] PCD Local Token Numbers in PEI/DXE

[Tim Lewis]

I would point out that in systems where PEI FVs are updated independently of 
DXE FVs, we use 100% DynamicEx, because we try to make no assumptions. 
Basically, the PEIMs in the PEI FV are considered "binary builds" per Mike's 
classification.

Tim

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Wednesday, February 17, 2016 9:00 AM
To: Gao, Liming ; Tim Lewis ; Zeng, 
Star ; edk2-devel@lists.01.org; Kinney, Michael D 

Subject: RE: PCD Local Token Numbers in PEI/DXE

Liming,

Adding error message/assert when PEI and DXE databases are not compatible is a 
good idea.

But I also think we should do everything we can to prevent PEI and DXE 
databases from ever being incompatible.  Especially if 100% of the PCDs used 
are accessed as DynamixEx.

Thanks,

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, February 17, 2016 7:07 AM
> To: Tim Lewis ; Zeng, Star 
> ; Kinney, Michael D ; 
> edk2-devel@lists.01.org
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Tim:
>   I think we can enhance PCD driver and Build tool to do this check. 
> If the mismatch happens, PcdDxe driver will report error message, and not 
> install PCD protocol.
> 
> Thanks
> Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tim Lewis
> Sent: Monday, February 15, 2016 1:59 PM
> To: Zeng, Star ; Kinney, Michael D 
> ; edk2-devel@lists.01.org
> Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE
> 
> Star --
> 
> There are many cases where the PEI FV is not updated because it 
> resides in a portion of the flash that is specially protected, often 
> by a pin on the motherboard. In many platforms, this recovery firmware 
> in PEI is never updated throughout the life of the platform. But DXE might be 
> updated many times.
> 
> We handle the mismatch case often, for HOBs, etc. We design the HOBs, 
> UEFI variables, etc. in such a way that the detection can be detected or 
> worked-around.
> 
> But with PCDs, we cannot detect the mismatch without special 
> knowledge, because the PCD driver will return the wrong PCD value.
> 
> Tim
> 
> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Sunday, February 14, 2016 9:54 PM
> To: Tim Lewis ; Kinney, Michael D 
> ; edk2-devel@lists.01.org
> Cc: Zeng, Star 
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Tim,
> 
> Basically, I aware PEI as the high-reliability, high-security portion of the 
> BIOS.
> I mean for this case, should PEI FV be also updated?
> 
> And the mismatch seems not a special case for PCD. Consider one 
> situation that new DXE wants to consume a HOB produced by new PEI, the 
> new DXE could also not work with old PEI.
> 
> Thanks,
> Star
> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Monday, February 15, 2016 1:45 PM
> To: Zeng, Star; Kinney, Michael D; edk2-devel@lists.01.org
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Star --
> 
> Consider the case where PEI FV is inside the flash boot block, but DXE 
> FV is outside of the flash boot block. This case is very common, using 
> PEI as the high-reliability, high-security portion of the BIOS.
> 
> You are correct, there is another case which is:
> 
> Build #1: PEI database A does not have PCD X, DXE database A has PCD X 
> Build #2: PEI database A has PCD X, DXE database A does not have PCD X
> 
> If the PEI from #2 is combined with the DXE from #1, there will be two 
> copies of the PCD (one in PEI, one in DXE). In our work-around, we 
> searched PEI before DXE. The better method might be to timestamp (rather than 
> assume PEI before DXE).
> 
> Tim
> 
> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Sunday, February 14, 2016 9:33 PM
> To: Kinney, Michael D ; Tim Lewis 
> ; edk2-devel@lists.01.org
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Mike,
> 
> Could one PCD be accessed using both methods Dynamic and DynamicEx in one 
> build?
> As I know, it could not.
> 
> Another problem is about where the default PCD value stores. 
> Currently, PEI and PEI+DXE phase consumed PCDs are stored in PEI PCD 
> database, and only DXE phase consumed PCDs are stored in DXE PCD database.
> If the new PEI consumes 4+ PCDs, the 4+ PCDs will be stored in PEI 
> database, and if DXE also consumes them, the new DXE would not work 
> with old PEI. And is it a valid case to only update DXE FV?
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael D
> Sent: Thursday, 

Re: [edk2] Using PCD to set default policy for IPv4/IPv6

[Kinney, Michael D]

Hi Samer,

1) If there are a large number of adapters, can you choose to only start the 
ones needed to boot?

2) Can't a platform driver set the policy needed for each NIC that is required 
to boot?

Mike



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> El-Haj-Mahmoud,
> Samer
> Sent: Wednesday, February 17, 2016 12:53 PM
> To: Kinney, Michael D ; Wu, Jiaxin 
> ;
> Subramanian, Sriram (EG Servers Platform SW) ; Hegde, 
> Nagaraj P
> ; Zimmer, Vincent ; Li, 
> Ruth
> ; Ye, Ting ; Fu, Siyuan 
> ;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] Using PCD to set default policy for IPv4/IPv6
> 
> I believe the PCDs are just to let the core drivers select the default 
> behavior (not
> full configuration) of automatic/DHCP vs. Static. Today, the core drivers 
> hard-code the
> default behavior to DHCP/automatic, and that is not ideal in server platforms 
> that may
> have a large number of adapters.
> 
> 
> 
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, February 17, 2016 11:34 AM
> To: Wu, Jiaxin ; Subramanian, Sriram (EG Servers 
> Platform SW)
> ; El-Haj-Mahmoud, Samer ; 
> Hegde,
> Nagaraj P ; Zimmer, Vincent 
> ; Li,
> Ruth ; Ye, Ting ; Fu, Siyuan
> ; edk2-devel@lists.01.org; Kinney, Michael D
> 
> Subject: RE: Using PCD to set default policy for IPv4/IPv6
> 
> Jiaxin,
> 
> If a platform module can set the policy for each network interface, then why 
> do we need
> to add PCDs?
> 
> Thanks,
> 
> Mike
> 
> From: Wu, Jiaxin
> Sent: Tuesday, February 16, 2016 6:30 PM
> To: Kinney, Michael D 
> >;
> Subramanian, Sriram (EG Servers Platform SW)  s...@hpe.com>>; El-Haj-Mahmoud, Samer 
>  mahm...@hpe.com>>; Hegde, Nagaraj P  p.he...@hpe.com>>; Zimmer, Vincent
> >; Li, Ruth
> >; Ye, Ting
> >; Fu, Siyuan
> >; 
> edk2-devel@lists.01.org de...@lists.01.org>
> Subject: RE: Using PCD to set default policy for IPv4/IPv6
> 
> Mike,
> Thanks your comments.
> First, I agree other platform modules can also change the police by using the 
> set
> operation.
> Second for the complete design, the proposed for the new PCDs will only be 
> consumed by
> Ip4Dxe/Ip6Dxe modules. The PCDs are used by these two modules to determine 
> the default
> policy, the current Ip4Dxe/Ip6Dxe driver will  make decision which more 
> configuration
> information needed to be also configured. So, I think this a complete design 
> to cover
> the IPv4/Ipv6 configuration protocol.
> 
> Thanks.
> Jiaxin
> 
> From: Kinney, Michael D
> Sent: Wednesday, February 17, 2016 6:10 AM
> To: Wu, Jiaxin >; 
> Subramanian, Sriram
> (EG Servers Platform SW) >; 
> El-Haj-Mahmoud,
> Samer >; 
> Hegde,
> Nagaraj P >; Zimmer, 
> Vincent
> >; Li, Ruth
> >; Ye, Ting
> >; Fu, Siyuan
> >; 
> edk2-devel@lists.01.org de...@lists.01.org>; Kinney, Michael D
> >
> Subject: RE: Using PCD to set default policy for IPv4/IPv6
> 
> Jiaxin,
> 
> This proposal looks incomplete to me.  If the configuration policy is set to
> Ip4Config2PolicyStatic or Ip6ConfigPolicyManual, then it seems like a lot more
> configuration information would be required for the static or manual policies.
> 
> Can you also provide details on the complete design.  What modules are you 
> proposing
> would use these new PCDs?  These configuration protocols provide get/set 
> operations.
> Why can't a platform module use the set operation to set static/manual policy 
> along
> with the additional set operations to completely configure static/manual 
> policy?
> 
> Thanks,
> 
> Mike
> 
> From: Wu, Jiaxin
> Sent: Monday, February 15, 2016 7:37 PM
> To: Subramanian, Sriram (EG Servers Platform SW) 
>  s...@hpe.com>>; El-Haj-Mahmoud, Samer 
> 

Re: [edk2] [PATCH] MdeModulePkg, AtaBusDxe: Bounce buffer IO operations if unaligned

[Leif Lindholm]

On Tue, Feb 16, 2016 at 06:51:45PM +0100, Laszlo Ersek wrote:
> On 02/16/16 17:36, Jeremy Linton wrote:
> > |Not wishing to influence the discussion, just out of curiosity: Jeremy
> > |mentions "numerous other BlockIo protocol providers in edk2 bounce IO
> > |operations rather than simply allowing them to fail" -- can we see some
> > |examples? I wonder if, upon seeing that code, we could use "git blame"
> > |to find out *why* those workarounds had been introduced.
> > 
> > It's the same case, grub2 fails to honor the alignment requirements.
> > 
> > OvmfPkg/XenPvBlkDxe/BlockIo.c
> > 
> > I thought when I originally posted that I had found a couple more
> > cases, but then when talking to Leif about it a while back, that was
> > the one case I found.
> 
> //
> // Grub2 does not appear to respect IoAlign of 512, so reallocate the
> // buffer here.
> //
> 
> That's not an example that makes me especially happy. In fact, now that
> I know about it, I think I'll only tolerate it in OvmfPkg because it's
> related to Xen. (And because it's already there.)
> 
> I'm actually pretty disappointed. The above XenPvBlkDxe code was
> committed to edk2 in October 2014 (5de8a35c62406), but grub2 has the bug
> to *this day*. If you grep the grub2 code at 25492a0f047c for
> "io_align", the only hit is in the structure definition, in
> "include/grub/efi/api.h".
> 
> Apparently, noone has bothered in the past ~1.5 years to report and fix
> the bug in grub2, despite the bugfix looking quite manageable.

https://lists.gnu.org/archive/html/grub-devel/2016-02/msg00166.html

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

Re: [edk2] [PATCH v2] BaseTools: LzmaCompress: fix gcc-6 warning "misleading-indentation"

[Jordan Justen]

Reviewed-by: Jordan Justen 

On 2016-02-17 11:17:35, Laszlo Ersek wrote:
> The way the first use of the "_maxMode" variable is commented out (i.e.,
> together with the enclosing "if" statement) in GetOptimum() triggers the
> "misleading-indentation" warning that is new in gcc-6.0, for the block of
> code that originally depended on the "if" statement. Gcc believes
> (mistakenly) that the programmer believes (mistakenly) that the block
> depends on (repIndex == 0) higher up.
> 
> Restore the if statement, with a controlling expression that comprises the
> constant 1 and "_maxMode" commented out.
> 
> Cc: Jordan Justen 
> Cc: Cole Robinson 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Reported-by: Cole Robinson 
> Suggested-by: Jordan Justen 
> Build-tested-by: Cole Robinson 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1307439
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c 
> b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
> index 9b2dd16ffa48..c6717eeea3a0 100644
> --- a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
> +++ b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
> @@ -1367,7 +1367,7 @@ static UInt32 GetOptimum(CLzmaEnc *p, UInt32 position, 
> UInt32 *backRes)
>if (repIndex == 0)
>  startLen = lenTest + 1;
>  
> -  /* if (_maxMode) */
> +  if (1 /* _maxMode */)
>  {
>UInt32 lenTest2 = lenTest + 1;
>UInt32 limit = lenTest2 + p->numFastBytes;
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] BaseTools: LzmaCompress: fix gcc-6 warning "misleading-indentation"

[Laszlo Ersek]

The way the first use of the "_maxMode" variable is commented out (i.e.,
together with the enclosing "if" statement) in GetOptimum() triggers the
"misleading-indentation" warning that is new in gcc-6.0, for the block of
code that originally depended on the "if" statement. Gcc believes
(mistakenly) that the programmer believes (mistakenly) that the block
depends on (repIndex == 0) higher up.

Restore the if statement, with a controlling expression that comprises the
constant 1 and "_maxMode" commented out.

Cc: Jordan Justen 
Cc: Cole Robinson 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Reported-by: Cole Robinson 
Suggested-by: Jordan Justen 
Build-tested-by: Cole Robinson 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1307439
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c 
b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
index 9b2dd16ffa48..c6717eeea3a0 100644
--- a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
+++ b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
@@ -1367,7 +1367,7 @@ static UInt32 GetOptimum(CLzmaEnc *p, UInt32 position, 
UInt32 *backRes)
   if (repIndex == 0)
 startLen = lenTest + 1;
 
-  /* if (_maxMode) */
+  if (1 /* _maxMode */)
 {
   UInt32 lenTest2 = lenTest + 1;
   UInt32 limit = lenTest2 + p->numFastBytes;
-- 
1.8.3.1

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

Re: [edk2] [PATCH v1 1/1] StdLib/BsdSocketLib: Fix minor memory leak.

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Daryl McDaniel
> Sent: Tuesday, February 16, 2016 12:09 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Colin King
> 
> Subject: [edk2] [PATCH v1 1/1] StdLib/BsdSocketLib: Fix minor memory leak.
> Importance: High
> 
> Fixes a minor memory leak in function res_mkupdrec() by
> freeing rrecp on error return.
> 
> The error return is triggered by one of two conditions:
>   1.  rrecp is NULL (calloc failed)
>   2.  strdup(dname) returns NULL
> 
> Previously, the function just returned NULL.  This patch adds a call to
> free rrecp before returning NULL.  Since the free() function will properly
> do nothing when called with a NULL parameter, it is not necessary to
> separate the two tests into separate if clauses.
> 
> Reported-by: Colin King 
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Daryl McDaniel 
> ---
>  StdLib/BsdSocketLib/res_mkupdate.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/StdLib/BsdSocketLib/res_mkupdate.c
> b/StdLib/BsdSocketLib/res_mkupdate.c
> index d81d7d6f1518..db8540ab4b85 100644
> --- a/StdLib/BsdSocketLib/res_mkupdate.c
> +++ b/StdLib/BsdSocketLib/res_mkupdate.c
> @@ -438,8 +438,10 @@ res_mkupdrec(int section, const char *dname,
>   u_int class, u_int type, u_long ttl) {
>  ns_updrec *rrecp = (ns_updrec *)calloc(1, sizeof(ns_updrec));
> 
> -if (!rrecp || !(rrecp->r_dname = strdup(dname)))
> +if (!rrecp || !(rrecp->r_dname = strdup(dname))) {
> +free(rrecp);
>  return (NULL);
> +}
>  rrecp->r_class = (u_int16_t)class;
>  rrecp->r_type = (u_int16_t)type;
>  rrecp->r_ttl = (u_int32_t)ttl;
> --
> 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] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

[Ard Biesheuvel]

On 17 February 2016 at 18:40, Laszlo Ersek  wrote:
> On 02/17/16 18:23, Ard Biesheuvel wrote:
>> On 17 February 2016 at 18:07, Graeme Gregory  
>> wrote:
>>>
>>>
>>> On 17/02/2016 16:04, Laszlo Ersek wrote:

 On 02/17/16 16:34, Ard Biesheuvel wrote:
>
> On 17 February 2016 at 16:11, Laszlo Ersek  wrote:
>>
>> On 02/17/16 15:48, Ard Biesheuvel wrote:
>>>
>>> AARCH64 systems never require compatibility with legacy ACPI OSes, and
>>> may not have any 32-bit addressable system RAM. To support ACPI on
>>> these
>>> systems, we need to be able to relax the 4 GB allocation restriction.
>>>
>>> So add a PCD PcdAcpiAllocateTablesBelow4GB defaulting to TRUE, and wire
>>> it up to the memory allocation calls in
>>> AcpiTableDxe/AcpiTableProtocol.c
>>>
>>> Note that this will inhibit the publishing of any tables that carry
>>> only
>>> 32-bit addresses, i.e., RSDPv1, RSDTv1 and RSDTv3.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>   MdeModulePkg/MdeModulePkg.dec|   7 +
>>>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   2 +
>>>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 447
>>> 
>>>   3 files changed, 270 insertions(+), 186 deletions(-)
>>
>> Somewhat independently of your patch, I agree 100% that the interface
>> exposed by EFI_ACPI_TABLE_PROTOCOL is seriously lacking. It doesn't
>> allow the caller to control the allocation limit (--> see your patch),
>> nor the UEFI memory type that the copy of the table being installed will
>> be placed into (it would be valid for the caller to choose between
>> AcpiReclaim vs. AcpiNVS), nor the question whether the table being
>> installed should be linked into the RSDT, XSDT, or both.
>>
>> I don't find this an implementation problem; this is a problem with the
>> specification. In particular, in October last year I cross-posted an
>> email to the USWG and ASWG lists, entitled
>>
>>LoadTable vs. EFI_ACPI_TABLE_PROTOCOL
>>
>> In that email, I pointed out that the current edk2 implementation of
>> EFI_ACPI_TABLE_PROTOCOL makes it impossible to support the LoadTable
>> ACPI operator. Namely, the LoadTable operator requires the definition
>> block (= AML code) being loaded dynamically to come *from* AcpiNVS type
>> memory, but edk2's implementation doesn't allow the caller to install
>> tables into AcpiNVS type memory, *except* those with the signature
>> "UEFI" -- those however are *data* tables, not definition blocks (= AML
>> code, like SSDT or DSDT).
>>
>> For this reason, I proposed EFI_ACPI_TABLE2_PROTOCOL:
>>
>>> - same set of member functions
>>> - UninstallAcpiTable() works the same
>>> - InstallAcpiTable() gets a new parameter called MemoryType:
>>>
>>> typedef
>>> EFI_STATUS
>>> (EFIAPI *EFI_ACPI_TABLE2_INSTALL_ACPI_TABLE) (
>>>IN EFI_ACPI_TABLE2_PROTOCOL *This,
>>>IN VOID *AcpiTableBuffer,
>>>IN UINTNAcpiTableBufferSize,
>>>IN EFI_MEMORY_TYPE  *MemoryType OPTIONAL,
>>>OUT UINTN   *TableKey
>>> );
>>>
>>> - If MemoryType is NULL, then the new interface works identically to
>>>the preexistent one.
>>> - Otherwise, if EFI_ACPI_TABLE2_PROTOCOL can prove that *MemoryType is
>>>invalid for the signature detected in AcpiTableBuffer, then
>>>EFI_INVALID_PARAMETER is returned.
>>> - Otherwise, the copy of AcpiTableBuffer is allocated from *MemoryType
>>>memory.
>>>
>>> This would allow tables with any (non-standard) signatures to be
>>> placed in reserved or AcpiNVS memory, regardless of contents.
>>
>> My query to the USWG & ASWG garnered exactly *zero* replies. I guess
>> nobody cared about (or understood) my problem.
>>
>> Now I absolutely view your use case as a further parameter that
>> "EFI_ACPI_TABLE2_PROTOCOL" should expose. From that POV, I support your
>> use case.
>>
>> Regarding the implementation, I guess you are not enthusiastic about
>> turning this question into a standardization effort. (I tried and
>> failed.) So, whatever works for you -- I won't review the code, but as
>> long as it can remain compatible with current clients, given the right
>> PCD settings, I absolutely support the idea.
>>
> You may be right about the lacking EFI_ACPI_PROTOCOL interface, but
> the hardcoded 4 GB limit is simply an implementation detail, and
> should be treated as such imo.

 Hm, maybe, maybe not.

 Namely, RSDT cannot reference 

Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

[Laszlo Ersek]

On 02/17/16 18:23, Ard Biesheuvel wrote:
> On 17 February 2016 at 18:07, Graeme Gregory  
> wrote:
>>
>>
>> On 17/02/2016 16:04, Laszlo Ersek wrote:
>>>
>>> On 02/17/16 16:34, Ard Biesheuvel wrote:

 On 17 February 2016 at 16:11, Laszlo Ersek  wrote:
>
> On 02/17/16 15:48, Ard Biesheuvel wrote:
>>
>> AARCH64 systems never require compatibility with legacy ACPI OSes, and
>> may not have any 32-bit addressable system RAM. To support ACPI on
>> these
>> systems, we need to be able to relax the 4 GB allocation restriction.
>>
>> So add a PCD PcdAcpiAllocateTablesBelow4GB defaulting to TRUE, and wire
>> it up to the memory allocation calls in
>> AcpiTableDxe/AcpiTableProtocol.c
>>
>> Note that this will inhibit the publishing of any tables that carry
>> only
>> 32-bit addresses, i.e., RSDPv1, RSDTv1 and RSDTv3.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>   MdeModulePkg/MdeModulePkg.dec|   7 +
>>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   2 +
>>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 447
>> 
>>   3 files changed, 270 insertions(+), 186 deletions(-)
>
> Somewhat independently of your patch, I agree 100% that the interface
> exposed by EFI_ACPI_TABLE_PROTOCOL is seriously lacking. It doesn't
> allow the caller to control the allocation limit (--> see your patch),
> nor the UEFI memory type that the copy of the table being installed will
> be placed into (it would be valid for the caller to choose between
> AcpiReclaim vs. AcpiNVS), nor the question whether the table being
> installed should be linked into the RSDT, XSDT, or both.
>
> I don't find this an implementation problem; this is a problem with the
> specification. In particular, in October last year I cross-posted an
> email to the USWG and ASWG lists, entitled
>
>LoadTable vs. EFI_ACPI_TABLE_PROTOCOL
>
> In that email, I pointed out that the current edk2 implementation of
> EFI_ACPI_TABLE_PROTOCOL makes it impossible to support the LoadTable
> ACPI operator. Namely, the LoadTable operator requires the definition
> block (= AML code) being loaded dynamically to come *from* AcpiNVS type
> memory, but edk2's implementation doesn't allow the caller to install
> tables into AcpiNVS type memory, *except* those with the signature
> "UEFI" -- those however are *data* tables, not definition blocks (= AML
> code, like SSDT or DSDT).
>
> For this reason, I proposed EFI_ACPI_TABLE2_PROTOCOL:
>
>> - same set of member functions
>> - UninstallAcpiTable() works the same
>> - InstallAcpiTable() gets a new parameter called MemoryType:
>>
>> typedef
>> EFI_STATUS
>> (EFIAPI *EFI_ACPI_TABLE2_INSTALL_ACPI_TABLE) (
>>IN EFI_ACPI_TABLE2_PROTOCOL *This,
>>IN VOID *AcpiTableBuffer,
>>IN UINTNAcpiTableBufferSize,
>>IN EFI_MEMORY_TYPE  *MemoryType OPTIONAL,
>>OUT UINTN   *TableKey
>> );
>>
>> - If MemoryType is NULL, then the new interface works identically to
>>the preexistent one.
>> - Otherwise, if EFI_ACPI_TABLE2_PROTOCOL can prove that *MemoryType is
>>invalid for the signature detected in AcpiTableBuffer, then
>>EFI_INVALID_PARAMETER is returned.
>> - Otherwise, the copy of AcpiTableBuffer is allocated from *MemoryType
>>memory.
>>
>> This would allow tables with any (non-standard) signatures to be
>> placed in reserved or AcpiNVS memory, regardless of contents.
>
> My query to the USWG & ASWG garnered exactly *zero* replies. I guess
> nobody cared about (or understood) my problem.
>
> Now I absolutely view your use case as a further parameter that
> "EFI_ACPI_TABLE2_PROTOCOL" should expose. From that POV, I support your
> use case.
>
> Regarding the implementation, I guess you are not enthusiastic about
> turning this question into a standardization effort. (I tried and
> failed.) So, whatever works for you -- I won't review the code, but as
> long as it can remain compatible with current clients, given the right
> PCD settings, I absolutely support the idea.
>
 You may be right about the lacking EFI_ACPI_PROTOCOL interface, but
 the hardcoded 4 GB limit is simply an implementation detail, and
 should be treated as such imo.
>>>
>>> Hm, maybe, maybe not.
>>>
>>> Namely, RSDT cannot reference tables that are located above 4GB, and the
>>> UEFI spec says, quote,
>>>
>>>  EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable()
>>>
>>>  [...]
>>>
>>>  The 

Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

[Laszlo Ersek]

On 02/17/16 18:07, Graeme Gregory wrote:
> 
> 
> On 17/02/2016 16:04, Laszlo Ersek wrote:
>> On 02/17/16 16:34, Ard Biesheuvel wrote:
>>> On 17 February 2016 at 16:11, Laszlo Ersek  wrote:
 On 02/17/16 15:48, Ard Biesheuvel wrote:
> AARCH64 systems never require compatibility with legacy ACPI OSes, and
> may not have any 32-bit addressable system RAM. To support ACPI on
> these
> systems, we need to be able to relax the 4 GB allocation restriction.
>
> So add a PCD PcdAcpiAllocateTablesBelow4GB defaulting to TRUE, and
> wire
> it up to the memory allocation calls in
> AcpiTableDxe/AcpiTableProtocol.c
>
> Note that this will inhibit the publishing of any tables that carry
> only
> 32-bit addresses, i.e., RSDPv1, RSDTv1 and RSDTv3.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>   MdeModulePkg/MdeModulePkg.dec|   7 +
>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   2 +
>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c |
> 447 
>   3 files changed, 270 insertions(+), 186 deletions(-)
 Somewhat independently of your patch, I agree 100% that the interface
 exposed by EFI_ACPI_TABLE_PROTOCOL is seriously lacking. It doesn't
 allow the caller to control the allocation limit (--> see your patch),
 nor the UEFI memory type that the copy of the table being installed
 will
 be placed into (it would be valid for the caller to choose between
 AcpiReclaim vs. AcpiNVS), nor the question whether the table being
 installed should be linked into the RSDT, XSDT, or both.

 I don't find this an implementation problem; this is a problem with the
 specification. In particular, in October last year I cross-posted an
 email to the USWG and ASWG lists, entitled

LoadTable vs. EFI_ACPI_TABLE_PROTOCOL

 In that email, I pointed out that the current edk2 implementation of
 EFI_ACPI_TABLE_PROTOCOL makes it impossible to support the LoadTable
 ACPI operator. Namely, the LoadTable operator requires the definition
 block (= AML code) being loaded dynamically to come *from* AcpiNVS type
 memory, but edk2's implementation doesn't allow the caller to install
 tables into AcpiNVS type memory, *except* those with the signature
 "UEFI" -- those however are *data* tables, not definition blocks (= AML
 code, like SSDT or DSDT).

 For this reason, I proposed EFI_ACPI_TABLE2_PROTOCOL:

> - same set of member functions
> - UninstallAcpiTable() works the same
> - InstallAcpiTable() gets a new parameter called MemoryType:
>
> typedef
> EFI_STATUS
> (EFIAPI *EFI_ACPI_TABLE2_INSTALL_ACPI_TABLE) (
>IN EFI_ACPI_TABLE2_PROTOCOL *This,
>IN VOID *AcpiTableBuffer,
>IN UINTNAcpiTableBufferSize,
>IN EFI_MEMORY_TYPE  *MemoryType OPTIONAL,
>OUT UINTN   *TableKey
> );
>
> - If MemoryType is NULL, then the new interface works identically to
>the preexistent one.
> - Otherwise, if EFI_ACPI_TABLE2_PROTOCOL can prove that *MemoryType is
>invalid for the signature detected in AcpiTableBuffer, then
>EFI_INVALID_PARAMETER is returned.
> - Otherwise, the copy of AcpiTableBuffer is allocated from *MemoryType
>memory.
>
> This would allow tables with any (non-standard) signatures to be
> placed in reserved or AcpiNVS memory, regardless of contents.
 My query to the USWG & ASWG garnered exactly *zero* replies. I guess
 nobody cared about (or understood) my problem.

 Now I absolutely view your use case as a further parameter that
 "EFI_ACPI_TABLE2_PROTOCOL" should expose. From that POV, I support your
 use case.

 Regarding the implementation, I guess you are not enthusiastic about
 turning this question into a standardization effort. (I tried and
 failed.) So, whatever works for you -- I won't review the code, but as
 long as it can remain compatible with current clients, given the right
 PCD settings, I absolutely support the idea.

>>> You may be right about the lacking EFI_ACPI_PROTOCOL interface, but
>>> the hardcoded 4 GB limit is simply an implementation detail, and
>>> should be treated as such imo.
>> Hm, maybe, maybe not.
>>
>> Namely, RSDT cannot reference tables that are located above 4GB, and the
>> UEFI spec says, quote,
>>
>>  EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable()
>>
>>  [...]
>>
>>  The InstallAcpiTable() function allows a caller to install an ACPI
>>  table. The ACPI table may either by a System Description Table or
>>  the FACS. For all tables except for the DSDT and FACS, a copy of
>>  the table 

Re: [edk2] Using PCD to set default policy for IPv4/IPv6

[Kinney, Michael D]

Jiaxin,

If a platform module can set the policy for each network interface, then why do 
we need to add PCDs?

Thanks,

Mike

From: Wu, Jiaxin
Sent: Tuesday, February 16, 2016 6:30 PM
To: Kinney, Michael D ; Subramanian, Sriram (EG 
Servers Platform SW) ; El-Haj-Mahmoud, Samer 
; Hegde, Nagaraj P ; 
Zimmer, Vincent ; Li, Ruth ; Ye, 
Ting ; Fu, Siyuan ; 
edk2-devel@lists.01.org
Subject: RE: Using PCD to set default policy for IPv4/IPv6

Mike,
Thanks your comments.
First, I agree other platform modules can also change the police by using the 
set operation.
Second for the complete design, the proposed for the new PCDs will only be 
consumed by Ip4Dxe/Ip6Dxe modules. The PCDs are used by these two modules to 
determine the default policy, the current Ip4Dxe/Ip6Dxe driver will  make 
decision which more configuration information needed to be also configured. So, 
I think this a complete design to cover the IPv4/Ipv6 configuration protocol.

Thanks.
Jiaxin

From: Kinney, Michael D
Sent: Wednesday, February 17, 2016 6:10 AM
To: Wu, Jiaxin >; Subramanian, 
Sriram (EG Servers Platform SW) >; 
El-Haj-Mahmoud, Samer 
>; Hegde, 
Nagaraj P >; Zimmer, 
Vincent >; Li, Ruth 
>; Ye, Ting 
>; Fu, Siyuan 
>; 
edk2-devel@lists.01.org; Kinney, Michael D 
>
Subject: RE: Using PCD to set default policy for IPv4/IPv6

Jiaxin,

This proposal looks incomplete to me.  If the configuration policy is set to 
Ip4Config2PolicyStatic or Ip6ConfigPolicyManual, then it seems like a lot more 
configuration information would be required for the static or manual policies.

Can you also provide details on the complete design.  What modules are you 
proposing would use these new PCDs?  These configuration protocols provide 
get/set operations.  Why can't a platform module use the set operation to set 
static/manual policy along with the additional set operations to completely 
configure static/manual policy?

Thanks,

Mike

From: Wu, Jiaxin
Sent: Monday, February 15, 2016 7:37 PM
To: Subramanian, Sriram (EG Servers Platform SW) 
>; El-Haj-Mahmoud, Samer 
>; Hegde, 
Nagaraj P >; Zimmer, 
Vincent >; Kinney, 
Michael D >; Li, 
Ruth >; Ye, Ting 
>; Fu, Siyuan 
>; 
edk2-devel@lists.01.org
Subject: Using PCD to set default policy for IPv4/IPv6

Hi all,

Below is the descriptions about the default policy for IPv4/IPv6 in latest UEFI 
Spec (Version 2.6).

<< P1472: The EFI_IP4_CONFIG2_POLICY defines the general configuration policy 
the EFI IPv4 Configuration II Protocol supports. The default policy for a newly 
detected communication device is beyond the scope of this document. An 
implementation might leave it to platform to choose the default policy.>>

<< P1510: The EFI_IP6_CONFIG_POLICY defines the general configuration policy 
the EFI IPv6 Configuration Protocol supports. The default policy for a newly 
detected communication device is beyond the scope of this document. An 
implementation might leave it to platform to choose the default policy.>>

So, I propose to introduce PCD to leave it to platform to choose the default 
policy. That's meaningful to make the source code consistent with UEFI Spec. 
Detailed see below:

## Ip4Config2 Policy Type configuration.
# 01 = The configuration policy is Ip4Config2PolicyStatic
# 02 = The configuration policy is Ip4Config2PolicyDhcp
# @Prompt Type Value of Ip4Config2 Policy.
gEfiMdeModulePkgTokenSpaceGuid.PcdIp4Config2PolicyType|2|UINT8|0x1002

## Ip6Config Policy Type configuration.
# 01 = The configuration policy is Ip6ConfigPolicyManual
# 02 = The configuration policy is Ip6ConfigPolicyAutomatic
# @Prompt Type Value of Ip6Config Policy.
gEfiNetworkPkgTokenSpaceGuid.PcdIp6ConfigPolicyType|2|UINT8|0x1002

Do you have any opinion? If there is no objection, I will create the 
corresponding patches to fix it.

Thanks.
Jiaxin
___

Re: [edk2] Allocating Aligned Pages

[Kinney, Michael D]

Bhupesh,

Yes, this API internally does an allocation larger than requested to guarantee 
that a buffer of the requested size and alignment is guaranteed to be in the 
allocated buffer.  It then frees the extra pages, so upon a successful 
allocation, the memory map only shows the actually aligned allocation.

There are no core services to do aligned allocation, so we are using the 
general purpose allocation service to provide aligned allocations.

For very large allocations or very large alignments, another option is to use 
GetMemoryMap() to get the current memory map and look for a range of memory 
that meets the requirement and use gBS->AllocatePages() using type 
AllocateAddress for a specific address from the memory map.  Just make sure the 
return status is checked because between the calls to GetMemoryMap() and 
AllocatePages() returning, the memory map may have changed and the fixed 
address allocation may fail.

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Bhupesh Sharma
> Sent: Tuesday, February 16, 2016 11:52 PM
> To: edk2-devel@lists.01.org 
> Cc: Jose Rivera 
> Subject: [edk2] Allocating Aligned Pages
> 
> Hi Experts,
> 
> We are using the 'AllocateAlignedPages' function (inside
> 'MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c')
> to allocate 512MB aligned memory chunk in a DXE driver.
> 
> However the memory chunk which gets allocated by this API is around 1GB.
> 
> I understand that this might be  because of the memory fragmentation, as a 
> result of
> which allocating
> the 512MB aligned buffer might result in memory chunk being allocated be 
> greater in
> size than 512MB.
> 
> Are we using the right API for the purpose - is there another API available 
> which
> allows alignment to specified
> more granularly?
> 
> Here is the 'AllocateAlignedPages' function which calls 
> 'InternalAllocateAlignedPages'
> internally.
> 
> /**
>   Allocates one or more 4KB pages of type EfiBootServicesData at a specified 
> alignment.
> 
>   Allocates the number of 4KB pages specified by Pages of type 
> EfiBootServicesData with
> an
>   alignment specified by Alignment.  The allocated buffer is returned.  If 
> Pages is 0,
> then NULL is
>   returned.  If there is not enough memory at the specified alignment 
> remaining to
> satisfy the
>   request, then NULL is returned.
> 
>   If Alignment is not a power of two and Alignment is not zero, then ASSERT().
>   If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().
> 
>   @param  Pages The number of 4 KB pages to allocate.
>   @param  Alignment The requested alignment of the allocation.  
> Must be a
> power of two.
> If Alignment is zero, then byte alignment is 
> used.
> 
>   @return A pointer to the allocated buffer or NULL if allocation fails.
> 
> **/
> VOID *
> EFIAPI
> AllocateAlignedPages (
>   IN UINTN  Pages,
>   IN UINTN  Alignment
>   )
> {
>   return InternalAllocateAlignedPages (EfiBootServicesData, Pages, Alignment);
> }
> 
> ...
> 
> /**
>   Allocates one or more 4KB pages of a certain memory type at a specified 
> alignment.
> 
>   Allocates the number of 4KB pages specified by Pages of a certain memory 
> type with an
> alignment
>   specified by Alignment.  The allocated buffer is returned.  If Pages is 0, 
> then NULL
> is returned.
>   If there is not enough memory at the specified alignment remaining to 
> satisfy the
> request, then
>   NULL is returned.
>   If Alignment is not a power of two and Alignment is not zero, then ASSERT().
>   If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().
> 
>   @param  MemoryTypeThe type of memory to allocate.
>   @param  Pages The number of 4 KB pages to allocate.
>   @param  Alignment The requested alignment of the allocation.  
> Must be a
> power of two.
> If Alignment is zero, then byte alignment is 
> used.
> 
>   @return A pointer to the allocated buffer or NULL if allocation fails.
> 
> **/
> VOID *
> InternalAllocateAlignedPages (
>   IN EFI_MEMORY_TYPE  MemoryType,
>   IN UINTNPages,
>   IN UINTNAlignment
>   )
> 
> ...
> 
> Thanks for the help.
> 
> Regards,
> Bhupesh
> ___
> 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] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

[Ard Biesheuvel]

On 17 February 2016 at 18:07, Graeme Gregory  wrote:
>
>
> On 17/02/2016 16:04, Laszlo Ersek wrote:
>>
>> On 02/17/16 16:34, Ard Biesheuvel wrote:
>>>
>>> On 17 February 2016 at 16:11, Laszlo Ersek  wrote:

 On 02/17/16 15:48, Ard Biesheuvel wrote:
>
> AARCH64 systems never require compatibility with legacy ACPI OSes, and
> may not have any 32-bit addressable system RAM. To support ACPI on
> these
> systems, we need to be able to relax the 4 GB allocation restriction.
>
> So add a PCD PcdAcpiAllocateTablesBelow4GB defaulting to TRUE, and wire
> it up to the memory allocation calls in
> AcpiTableDxe/AcpiTableProtocol.c
>
> Note that this will inhibit the publishing of any tables that carry
> only
> 32-bit addresses, i.e., RSDPv1, RSDTv1 and RSDTv3.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>   MdeModulePkg/MdeModulePkg.dec|   7 +
>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   2 +
>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 447
> 
>   3 files changed, 270 insertions(+), 186 deletions(-)

 Somewhat independently of your patch, I agree 100% that the interface
 exposed by EFI_ACPI_TABLE_PROTOCOL is seriously lacking. It doesn't
 allow the caller to control the allocation limit (--> see your patch),
 nor the UEFI memory type that the copy of the table being installed will
 be placed into (it would be valid for the caller to choose between
 AcpiReclaim vs. AcpiNVS), nor the question whether the table being
 installed should be linked into the RSDT, XSDT, or both.

 I don't find this an implementation problem; this is a problem with the
 specification. In particular, in October last year I cross-posted an
 email to the USWG and ASWG lists, entitled

LoadTable vs. EFI_ACPI_TABLE_PROTOCOL

 In that email, I pointed out that the current edk2 implementation of
 EFI_ACPI_TABLE_PROTOCOL makes it impossible to support the LoadTable
 ACPI operator. Namely, the LoadTable operator requires the definition
 block (= AML code) being loaded dynamically to come *from* AcpiNVS type
 memory, but edk2's implementation doesn't allow the caller to install
 tables into AcpiNVS type memory, *except* those with the signature
 "UEFI" -- those however are *data* tables, not definition blocks (= AML
 code, like SSDT or DSDT).

 For this reason, I proposed EFI_ACPI_TABLE2_PROTOCOL:

> - same set of member functions
> - UninstallAcpiTable() works the same
> - InstallAcpiTable() gets a new parameter called MemoryType:
>
> typedef
> EFI_STATUS
> (EFIAPI *EFI_ACPI_TABLE2_INSTALL_ACPI_TABLE) (
>IN EFI_ACPI_TABLE2_PROTOCOL *This,
>IN VOID *AcpiTableBuffer,
>IN UINTNAcpiTableBufferSize,
>IN EFI_MEMORY_TYPE  *MemoryType OPTIONAL,
>OUT UINTN   *TableKey
> );
>
> - If MemoryType is NULL, then the new interface works identically to
>the preexistent one.
> - Otherwise, if EFI_ACPI_TABLE2_PROTOCOL can prove that *MemoryType is
>invalid for the signature detected in AcpiTableBuffer, then
>EFI_INVALID_PARAMETER is returned.
> - Otherwise, the copy of AcpiTableBuffer is allocated from *MemoryType
>memory.
>
> This would allow tables with any (non-standard) signatures to be
> placed in reserved or AcpiNVS memory, regardless of contents.

 My query to the USWG & ASWG garnered exactly *zero* replies. I guess
 nobody cared about (or understood) my problem.

 Now I absolutely view your use case as a further parameter that
 "EFI_ACPI_TABLE2_PROTOCOL" should expose. From that POV, I support your
 use case.

 Regarding the implementation, I guess you are not enthusiastic about
 turning this question into a standardization effort. (I tried and
 failed.) So, whatever works for you -- I won't review the code, but as
 long as it can remain compatible with current clients, given the right
 PCD settings, I absolutely support the idea.

>>> You may be right about the lacking EFI_ACPI_PROTOCOL interface, but
>>> the hardcoded 4 GB limit is simply an implementation detail, and
>>> should be treated as such imo.
>>
>> Hm, maybe, maybe not.
>>
>> Namely, RSDT cannot reference tables that are located above 4GB, and the
>> UEFI spec says, quote,
>>
>>  EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable()
>>
>>  [...]
>>
>>  The InstallAcpiTable() function allows a caller to install an ACPI
>>  table. The ACPI table may either by a System Description Table or
>>  the FACS. For all tables 

Re: [edk2] PCD Local Token Numbers in PEI/DXE

[Kinney, Michael D]

Star,

I agree if PCDs are added to PEI Database that are also present in DXE 
Database, there could be a conflict.

There are several cases we need to consider to support separate update of PEI 
and DXE databases:

1) Add one or more PCDs to PEI Database that are not used in DXE Phase
2) Add one or more PCDs to PEI Database that are used in DXE Phase
3) Remove one or more PCDs from PEI Database that are not used in DXE Phase
4) Remove one or more PCDs from PEI Database that are used in DXE Phase
5) Add one or more PCDs to DXE Database that are not used in PEI Phase
6) Add one or more PCDs to DXE Database that are used in PEI Phase
7) Remove one or more PCDs from DXE Database that are not used in PEI Phase
8) Remove one or more PCDs from DXE Database that are used in PEI Phase

Case (1), (3), (5), (6), (7), and (8) should be relatively easy to support

Case (2) is the one you raised, where there could a conflict in the Default 
Value, Storage Type, and size.

Case (4) is even harder, because DXE Phase depends on PCDs passed up from PEI 
that are no longer there.  This should be an ASSERT()/failure.

I also want to emphasis that the PCD database needs to support 3 types of 
platform builds for PCD types:

A) 100% Dynamic PCDs (Usually used for source builds)
B) A mix of Dynamic and DynamicEx PCDs (Usually used for source builds with a 
few pre-built binary modules mixed in)
C) 100% DynamicEx PCDs (Used for 100% pre-built binary modules)

If we detect case (C), I think we can build the PEI and DXE databases so they 
do not use local tokens at all and avoid the local token number issue raised by 
Tim.  For (A) and (C), we might consider using 2 different ranges of local 
token numbers, so the number of local token numbers allocated to PEI and DXE 
database can change without token number overlaps.

Thanks,

Mike


> -Original Message-
> From: Zeng, Star
> Sent: Sunday, February 14, 2016 9:33 PM
> To: Kinney, Michael D ; Tim Lewis 
> ;
> edk2-devel@lists.01.org
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Mike,
> 
> Could one PCD be accessed using both methods Dynamic and DynamicEx in one 
> build?
> As I know, it could not.
> 
> Another problem is about where the default PCD value stores. Currently, PEI 
> and PEI+DXE
> phase consumed PCDs are stored in PEI PCD database, and only DXE phase 
> consumed PCDs
> are stored in DXE PCD database.
> If the new PEI consumes 4+ PCDs, the 4+ PCDs will be stored in PEI database, 
> and if DXE
> also consumes them, the new DXE would not work with old PEI. And is it a 
> valid case to
> only update DXE FV?
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael
> D
> Sent: Thursday, February 11, 2016 2:21 AM
> To: Tim Lewis; edk2-devel@lists.01.org; Kinney, Michael D
> Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE
> 
> Tim,
> 
> All good ideas to evaluate.
> 
> We did design in the Dynamic PCDs with generated local tokens to minimize the 
> size
> overhead of the PCD database for source builds.  We can do some size impact 
> analysis of
> these ideas to see which one makes the most sense.
> 
> The database is currently optimized for Dynamic PCDs.  When a DynamicEx PCD 
> is used it
> is internally translated to a Dynamic request.  I think all of the ideas here 
> require
> this concept to be reversed.  We need to optimized the database for DynamicEx 
> and never
> reference Dynamic part of database to process a DynamicEx request.  If 
> Dynamic is used,
> it can either be internally translated to a DynamicEx request with a fixed 
> token space
> guid or be processed as a local token.  In mixed Dynamic/DynamicEx 
> environments, the
> same PCD may be accessed using both methods.  Current design supports this 
> mixed env,
> so we need to make sure that aspect is not broken if we change internal 
> code/database.
> 
> Best regards,
> 
> Mike
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Wednesday, February 10, 2016 9:50 AM
> > To: Kinney, Michael D ;
> > edk2-devel@lists.01.org
> > Subject: RE: PCD Local Token Numbers in PEI/DXE
> >
> > Mike --
> >
> > Yes, we use all DynamicEx PCDs because we use a large number of binary
> > deliverables in certain segments.
> >
> > It would be a much simpler database design if the look up was purely a
> > GUID/token number/SkuId look-up (no local token numbers at all). The
> > existing Dynamic PCDs could be supported by assigning them a single
> > GUID. That is, Dynamic PCDs would be translated up to DynamicEx by
> > using gEfiDynamicPcdGuid.  Or we could deprecate Dynamic. Or make it 
> > auto-translate
> to DynamicEx.
> >
> > Tim
> >
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Kinney, Michael D
> > Sent: Wednesday, February 10, 

Re: [edk2] PCD Local Token Numbers in PEI/DXE

[Kinney, Michael D]

Liming,

Adding error message/assert when PEI and DXE databases are not compatible is a 
good idea.

But I also think we should do everything we can to prevent PEI and DXE 
databases from ever being incompatible.  Especially if 100% of the PCDs used 
are accessed as DynamixEx.

Thanks,

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, February 17, 2016 7:07 AM
> To: Tim Lewis ; Zeng, Star ; 
> Kinney, Michael
> D ; edk2-devel@lists.01.org
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Tim:
>   I think we can enhance PCD driver and Build tool to do this check. If the 
> mismatch
> happens, PcdDxe driver will report error message, and not install PCD 
> protocol.
> 
> Thanks
> Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim 
> Lewis
> Sent: Monday, February 15, 2016 1:59 PM
> To: Zeng, Star ; Kinney, Michael D 
> ;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE
> 
> Star --
> 
> There are many cases where the PEI FV is not updated because it resides in a 
> portion of
> the flash that is specially protected, often by a pin on the motherboard. In 
> many
> platforms, this recovery firmware in PEI is never updated throughout the life 
> of the
> platform. But DXE might be updated many times.
> 
> We handle the mismatch case often, for HOBs, etc. We design the HOBs, UEFI 
> variables,
> etc. in such a way that the detection can be detected or worked-around.
> 
> But with PCDs, we cannot detect the mismatch without special knowledge, 
> because the PCD
> driver will return the wrong PCD value.
> 
> Tim
> 
> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Sunday, February 14, 2016 9:54 PM
> To: Tim Lewis ; Kinney, Michael D 
> ;
> edk2-devel@lists.01.org
> Cc: Zeng, Star 
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Tim,
> 
> Basically, I aware PEI as the high-reliability, high-security portion of the 
> BIOS.
> I mean for this case, should PEI FV be also updated?
> 
> And the mismatch seems not a special case for PCD. Consider one situation 
> that new DXE
> wants to consume a HOB produced by new PEI, the new DXE could also not work 
> with old
> PEI.
> 
> Thanks,
> Star
> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Monday, February 15, 2016 1:45 PM
> To: Zeng, Star; Kinney, Michael D; edk2-devel@lists.01.org
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Star --
> 
> Consider the case where PEI FV is inside the flash boot block, but DXE FV is 
> outside of
> the flash boot block. This case is very common, using PEI as the 
> high-reliability,
> high-security portion of the BIOS.
> 
> You are correct, there is another case which is:
> 
> Build #1: PEI database A does not have PCD X, DXE database A has PCD X Build 
> #2: PEI
> database A has PCD X, DXE database A does not have PCD X
> 
> If the PEI from #2 is combined with the DXE from #1, there will be two copies 
> of the
> PCD (one in PEI, one in DXE). In our work-around, we searched PEI before DXE. 
> The
> better method might be to timestamp (rather than assume PEI before DXE).
> 
> Tim
> 
> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Sunday, February 14, 2016 9:33 PM
> To: Kinney, Michael D ; Tim Lewis 
> ;
> edk2-devel@lists.01.org
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Mike,
> 
> Could one PCD be accessed using both methods Dynamic and DynamicEx in one 
> build?
> As I know, it could not.
> 
> Another problem is about where the default PCD value stores. Currently, PEI 
> and PEI+DXE
> phase consumed PCDs are stored in PEI PCD database, and only DXE phase 
> consumed PCDs
> are stored in DXE PCD database.
> If the new PEI consumes 4+ PCDs, the 4+ PCDs will be stored in PEI database, 
> and if DXE
> also consumes them, the new DXE would not work with old PEI. And is it a 
> valid case to
> only update DXE FV?
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael
> D
> Sent: Thursday, February 11, 2016 2:21 AM
> To: Tim Lewis; edk2-devel@lists.01.org; Kinney, Michael D
> Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE
> 
> Tim,
> 
> All good ideas to evaluate.
> 
> We did design in the Dynamic PCDs with generated local tokens to minimize the 
> size
> overhead of the PCD database for source builds.  We can do some size impact 
> analysis of
> these ideas to see which one makes the most sense.
> 
> The database is currently optimized for Dynamic PCDs.  When a DynamicEx PCD 
> is used it
> is internally translated to a Dynamic request.  I think all of 

[edk2] [Patch] CryptoPkg/OpensslLib: Upgrade OpenSSL version to 1.0.2f

[Qin Long]

OpenSSL has released version 1.0.2f with two security fixes
(http://www.openssl.org/news/secadv/20160128.txt) at 28-Jan-2016.
Upgrade the supported OpenSSL version in CryptoPkg/OpensslLib
to catch the latest release 1.0.2f.
(NOTE: The patch file was just re-generated, and no new source
   changes was introduced for 1.0.2f enabling)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
CC: Ting Ye 
---
 ...ssl-1.0.2e.patch => EDKII_openssl-1.0.2f.patch} | 63 +++---
 CryptoPkg/Library/OpensslLib/Install.cmd   |  2 +-
 CryptoPkg/Library/OpensslLib/Install.sh|  2 +-
 CryptoPkg/Library/OpensslLib/OpensslLib.inf|  4 +-
 CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt   | 26 -
 5 files changed, 48 insertions(+), 49 deletions(-)
 rename CryptoPkg/Library/OpensslLib/{EDKII_openssl-1.0.2e.patch => 
EDKII_openssl-1.0.2f.patch} (89%)

diff --git a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch 
b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
similarity index 89%
rename from CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch
rename to CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
index e4eaff6..c42b776 100644
--- a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch
+++ b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
@@ -1,7 +1,7 @@
 diff U3 crypto/bio/bio.h crypto/bio/bio.h
 crypto/bio/bio.h   Thu Jun 11 21:50:12 2015
-+++ crypto/bio/bio.h   Fri Jun 12 11:00:52 2015
-@@ -646,10 +646,10 @@
+--- crypto/bio/bio.h   Thu Jan 28 21:56:08 2016
 crypto/bio/bio.h   Wed Feb 17 16:43:40 2016
+@@ -650,10 +650,10 @@
  int BIO_asn1_get_suffix(BIO *b, asn1_ps_func **psuffix,
  asn1_ps_func **psuffix_free);
  
@@ -14,8 +14,8 @@ diff U3 crypto/bio/bio.h crypto/bio/bio.h
  # endif
  BIO *BIO_new(BIO_METHOD *type);
 diff U3 crypto/bio/bss_file.c crypto/bio/bss_file.c
 crypto/bio/bss_file.c  Thu Jun 11 21:01:06 2015
-+++ crypto/bio/bss_file.c  Fri Jun 12 11:01:28 2015
+--- crypto/bio/bss_file.c  Thu Jan 28 21:38:30 2016
 crypto/bio/bss_file.c  Wed Feb 17 16:01:02 2016
 @@ -467,6 +467,23 @@
  return (ret);
  }
@@ -41,8 +41,8 @@ diff U3 crypto/bio/bss_file.c crypto/bio/bss_file.c
  
  #endif  /* HEADER_BSS_FILE_C */
 diff U3 crypto/dh/dh_pmeth.c crypto/dh/dh_pmeth.c
 crypto/dh/dh_pmeth.c   Thu Jun 11 21:50:12 2015
-+++ crypto/dh/dh_pmeth.c   Fri Jun 12 11:08:48 2015
+--- crypto/dh/dh_pmeth.c   Thu Jan 28 21:56:08 2016
 crypto/dh/dh_pmeth.c   Wed Feb 17 16:15:58 2016
 @@ -449,6 +449,9 @@
  *keylen = ret;
  return 1;
@@ -62,8 +62,8 @@ diff U3 crypto/dh/dh_pmeth.c crypto/dh/dh_pmeth.c
  return 1;
  }
 diff U3 crypto/pem/pem.h crypto/pem/pem.h
 crypto/pem/pem.h   Thu Jun 11 21:50:12 2015
-+++ crypto/pem/pem.h   Fri Jun 12 10:58:18 2015
+--- crypto/pem/pem.h   Thu Jan 28 21:56:08 2016
 crypto/pem/pem.h   Wed Feb 17 15:56:26 2016
 @@ -324,6 +324,7 @@
  
  #  define DECLARE_PEM_read_fp(name, type) /**/
@@ -73,8 +73,8 @@ diff U3 crypto/pem/pem.h crypto/pem/pem.h
  # else
  
 diff U3 crypto/pkcs7/pk7_smime.c crypto/pkcs7/pk7_smime.c
 crypto/pkcs7/pk7_smime.c   Thu Jun 11 21:01:06 2015
-+++ crypto/pkcs7/pk7_smime.c   Fri Jun 12 11:23:38 2015
+--- crypto/pkcs7/pk7_smime.c   Thu Jan 28 21:56:08 2016
 crypto/pkcs7/pk7_smime.c   Wed Feb 17 16:22:45 2016
 @@ -254,7 +254,8 @@
  STACK_OF(PKCS7_SIGNER_INFO) *sinfos;
  PKCS7_SIGNER_INFO *si;
@@ -114,20 +114,19 @@ diff U3 crypto/pkcs7/pk7_smime.c crypto/pkcs7/pk7_smime.c
  if (i <= 0)
  break;
  if (tmpout)
-@@ -394,6 +394,10 @@
+@@ -394,6 +394,9 @@
  }
  BIO_free_all(p7bio);
  sk_X509_free(signers);
-+
 +if (buf != NULL) {
-+  OPENSSL_free(buf);
++OPENSSL_free(buf);
 +}
  return ret;
  }
  
 diff U3 crypto/rand/rand_unix.c crypto/rand/rand_unix.c
 crypto/rand/rand_unix.cThu Jun 11 21:01:06 2015
-+++ crypto/rand/rand_unix.cFri Jun 12 10:51:21 2015
+--- crypto/rand/rand_unix.cThu Jan 28 21:38:32 2016
 crypto/rand/rand_unix.cWed Feb 17 15:40:02 2016
 @@ -116,7 +116,7 @@
  #include 
  #include "rand_lcl.h"
@@ -147,8 +146,8 @@ diff U3 crypto/rand/rand_unix.c crypto/rand/rand_unix.c
  {
  return 0;
 diff U3 crypto/rsa/rsa_ameth.c crypto/rsa/rsa_ameth.c
 crypto/rsa/rsa_ameth.c Thu Jun 11 21:50:12 2015
-+++ crypto/rsa/rsa_ameth.c Fri Jun 12 10:45:38 2015
+--- crypto/rsa/rsa_ameth.c Thu Jan 28 21:56:08 2016
 crypto/rsa/rsa_ameth.c Wed Feb 17 15:09:46 2016
 @@ -68,10 +68,12 @@
  #endif
  #include "asn1_locl.h"
@@ -221,8 +220,8 @@ diff U3 crypto/rsa/rsa_ameth.c crypto/rsa/rsa_ameth.c
  const EVP_PKEY_ASN1_METHOD rsa_asn1_meths[] = {
  {
 diff U3 crypto/x509/x509_vfy.c crypto/x509/x509_vfy.c
 crypto/x509/x509_vfy.c Thu Jun 11 21:52:58 2015
-+++ crypto/x509/x509_vfy.c Fri 

Re: [edk2] [PATCH] ShellPkg: Do NULL pointer check before the pointer is used.

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Qiu
> Shumin
> Sent: Monday, February 15, 2016 6:07 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Qiu, Shumin
> 
> Subject: [edk2] [PATCH] ShellPkg: Do NULL pointer check before the pointer
> is used.
> Importance: High
> 
> The pointer 'FileInterface->Buffer' returned from 'AllocateZeroPool' in
> function
> 'CreateFileInterfaceMem' may be NULL and will be dereferenced at the
> following code.
> 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin 
> ---
>  ShellPkg/Application/Shell/FileHandleWrappers.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/Application/Shell/FileHandleWrappers.c
> b/ShellPkg/Application/Shell/FileHandleWrappers.c
> index 168b78b..f8306e2 100644
> --- a/ShellPkg/Application/Shell/FileHandleWrappers.c
> +++ b/ShellPkg/Application/Shell/FileHandleWrappers.c
> @@ -3,7 +3,7 @@
>StdIn, StdOut, StdErr, etc...).
> 
>Copyright 2016 Dell Inc.
> -  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
>(C) Copyright 2013 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
> @@ -1516,6 +1516,10 @@ CreateFileInterfaceMem(
> 
>if (Unicode) {
>  FileInterface->Buffer = AllocateZeroPool(sizeof(gUnicodeFileTag));
> +if (FileInterface->Buffer == NULL) {
> +  FreePool (FileInterface);
> +  return NULL;
> +}
>  *((CHAR16 *) (FileInterface->Buffer)) = EFI_UNICODE_BYTE_ORDER_MARK;
>  FileInterface->BufferSize = 2;
>  FileInterface->Position = 2;
> --
> 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] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

[Laszlo Ersek]

On 02/17/16 16:34, Ard Biesheuvel wrote:
> On 17 February 2016 at 16:11, Laszlo Ersek  wrote:
>> On 02/17/16 15:48, Ard Biesheuvel wrote:
>>> AARCH64 systems never require compatibility with legacy ACPI OSes, and
>>> may not have any 32-bit addressable system RAM. To support ACPI on these
>>> systems, we need to be able to relax the 4 GB allocation restriction.
>>>
>>> So add a PCD PcdAcpiAllocateTablesBelow4GB defaulting to TRUE, and wire
>>> it up to the memory allocation calls in AcpiTableDxe/AcpiTableProtocol.c
>>>
>>> Note that this will inhibit the publishing of any tables that carry only
>>> 32-bit addresses, i.e., RSDPv1, RSDTv1 and RSDTv3.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>  MdeModulePkg/MdeModulePkg.dec|   7 +
>>>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   2 +
>>>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 447 
>>> 
>>>  3 files changed, 270 insertions(+), 186 deletions(-)
>>
>> Somewhat independently of your patch, I agree 100% that the interface
>> exposed by EFI_ACPI_TABLE_PROTOCOL is seriously lacking. It doesn't
>> allow the caller to control the allocation limit (--> see your patch),
>> nor the UEFI memory type that the copy of the table being installed will
>> be placed into (it would be valid for the caller to choose between
>> AcpiReclaim vs. AcpiNVS), nor the question whether the table being
>> installed should be linked into the RSDT, XSDT, or both.
>>
>> I don't find this an implementation problem; this is a problem with the
>> specification. In particular, in October last year I cross-posted an
>> email to the USWG and ASWG lists, entitled
>>
>>   LoadTable vs. EFI_ACPI_TABLE_PROTOCOL
>>
>> In that email, I pointed out that the current edk2 implementation of
>> EFI_ACPI_TABLE_PROTOCOL makes it impossible to support the LoadTable
>> ACPI operator. Namely, the LoadTable operator requires the definition
>> block (= AML code) being loaded dynamically to come *from* AcpiNVS type
>> memory, but edk2's implementation doesn't allow the caller to install
>> tables into AcpiNVS type memory, *except* those with the signature
>> "UEFI" -- those however are *data* tables, not definition blocks (= AML
>> code, like SSDT or DSDT).
>>
>> For this reason, I proposed EFI_ACPI_TABLE2_PROTOCOL:
>>
>>> - same set of member functions
>>> - UninstallAcpiTable() works the same
>>> - InstallAcpiTable() gets a new parameter called MemoryType:
>>>
>>> typedef
>>> EFI_STATUS
>>> (EFIAPI *EFI_ACPI_TABLE2_INSTALL_ACPI_TABLE) (
>>>   IN EFI_ACPI_TABLE2_PROTOCOL *This,
>>>   IN VOID *AcpiTableBuffer,
>>>   IN UINTNAcpiTableBufferSize,
>>>   IN EFI_MEMORY_TYPE  *MemoryType OPTIONAL,
>>>   OUT UINTN   *TableKey
>>> );
>>>
>>> - If MemoryType is NULL, then the new interface works identically to
>>>   the preexistent one.
>>> - Otherwise, if EFI_ACPI_TABLE2_PROTOCOL can prove that *MemoryType is
>>>   invalid for the signature detected in AcpiTableBuffer, then
>>>   EFI_INVALID_PARAMETER is returned.
>>> - Otherwise, the copy of AcpiTableBuffer is allocated from *MemoryType
>>>   memory.
>>>
>>> This would allow tables with any (non-standard) signatures to be
>>> placed in reserved or AcpiNVS memory, regardless of contents.
>>
>> My query to the USWG & ASWG garnered exactly *zero* replies. I guess
>> nobody cared about (or understood) my problem.
>>
>> Now I absolutely view your use case as a further parameter that
>> "EFI_ACPI_TABLE2_PROTOCOL" should expose. From that POV, I support your
>> use case.
>>
>> Regarding the implementation, I guess you are not enthusiastic about
>> turning this question into a standardization effort. (I tried and
>> failed.) So, whatever works for you -- I won't review the code, but as
>> long as it can remain compatible with current clients, given the right
>> PCD settings, I absolutely support the idea.
>>
> 
> You may be right about the lacking EFI_ACPI_PROTOCOL interface, but
> the hardcoded 4 GB limit is simply an implementation detail, and
> should be treated as such imo.

Hm, maybe, maybe not.

Namely, RSDT cannot reference tables that are located above 4GB, and the
UEFI spec says, quote,

EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable()

[...]

The InstallAcpiTable() function allows a caller to install an ACPI
table. The ACPI table may either by a System Description Table or
the FACS. For all tables except for the DSDT and FACS, a copy of
the table will be linked by the RSDT/XSDT. For the FACS and DSDT,
the pointer to a copy of the table will be updated in the FADT, if
present.

[...]

On successful output, the EFI_ACPI_TABLE_PROTOCOL will ensure that
the checksum field is correct for both the RSDT/XSDT table and the
copy of the table being installed that 

Re: [edk2] Why is the tools_def.txt file parsed 47 times on my fds build?

[Andrew Fish]

> On Feb 17, 2016, at 6:34 AM, Gao, Liming  wrote:
> 
> Andrew:
>  Thanks for this report. Tottime is second or microsecond? If LoadToolDefFile 
> is called only once, how much performance can be saved?
> 


Liming,

Python cProfile produces data in the pstats format and time is in seconds. So 
it looks like the parse of the file takes 0.19 seconds, but doing it 47 times 
is almost 9 seconds. 

If you look at 
https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template 
you can see the file is 463 KB, so you end up parsing 21 GB of data every 
build. Note it is going to depend on the layout of the FVs for the platform as 
you need GUIDed encapsulation sections to see the performance hit. Thus me 
pruning the Conf/tools_def.txt down to a 10K file saved ~8 seconds of build 
time.

My profile run was on a dirty build so none of the modules rebuilt.  If you 
profile a clean build the stats change as a lot of time is spent parsing the C 
code for the #include infrastructure, and this shows up as spending time in 
regex functions. I seem to remember there was a regex function that ran for 
about 4+ seconds for example. 

You can also do this:

Update RunToolFromSource:
python -m cProfile -o  edk2.profile "`dirname 
$0`/../../Source/Python"/`basename $0`/`basename $0`.py $*

>From the command line:
python -m pstats edk2.profile
Welcome to the profile statistics browser.
% help
 
Documented commands (type help ):

EOF  add  callees  callers  quit  read  reverse  sort  stats  strip
 
Undocumented commands:
==
help
%

This gives you an interactive prompt that lets you browse the stats, and track 
callees and callers. There are also optional packages that let you build call 
graphs, and do other interesting things on the pstats object. I've not tried 
those out. 

Thanks,

Andrew Fish

> Thanks
> Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
> Fish
> Sent: Tuesday, February 16, 2016 5:42 PM
> To: edk2-devel@lists.01.org 
> Subject: [edk2] Why is the tools_def.txt file parsed 47 times on my fds build?
> 
> 
> I turned on profiling in Python:
> BaseTools/BinWrappers/PosixLike/RunToolFromSource:
> #!/usr/bin/env bash
> #python `dirname $0`/RunToolFromSource.py `basename $0` $*
> PYTHONPATH="`dirname $0`/../../Source/Python" \
>python -m cProfile -s time "`dirname $0`/../../Source/Python"/`basename 
> $0`/`basename $0`.py $*
> 
> 
> The slowest item in the working thread was ToolDefClassObject. 
> LoadToolDefFile()
> 
>   Ordered by: internal time
> 
>   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>   478.9320.190   10.9860.234 
> ToolDefClassObject.py:60(LoadToolDefFile)
>  40674781.3370.0001.3370.000 {method 'split' of 'str' objects}
>285191.0640.0001.0640.000 {method 'execute' of 
> 'sqlite3.Cursor' objects}
>   7333780.8260.0001.1610.000 StringIO.py:208(write)
>   710.6130.0090.6130.009 {method 'items' of 'dict' 
> objects}
>   230.4990.022   11.9050.518 
> GuidSection.py:245(__FindExtendTool__)
> 
> 
> I see it gets called at the beginning of the build from InitBuild() and that 
> makes sense. If I do a genmake build LoadToolDefFile() only gets called a 
> single time. 
> 
> But it looks like __FindExtendTool__ is also making calls:
> ToolDefinition = 
> ToolDefClassObject.ToolDefDict(GenFdsGlobalVariable.ConfDir).ToolsDefTxtDictionary
> 
> So it looks to me like class GuidSection() is parsing the tools_def.txt for 
> every GUID'ed section that has a GUID defined tool? How come this information 
> is not cached? 
> 
> Does anyone see a quick fix?
> 
> Thanks,
> 
> Andrew Fish 
> ___
> 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] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

[Ard Biesheuvel]

On 17 February 2016 at 16:11, Laszlo Ersek  wrote:
> On 02/17/16 15:48, Ard Biesheuvel wrote:
>> AARCH64 systems never require compatibility with legacy ACPI OSes, and
>> may not have any 32-bit addressable system RAM. To support ACPI on these
>> systems, we need to be able to relax the 4 GB allocation restriction.
>>
>> So add a PCD PcdAcpiAllocateTablesBelow4GB defaulting to TRUE, and wire
>> it up to the memory allocation calls in AcpiTableDxe/AcpiTableProtocol.c
>>
>> Note that this will inhibit the publishing of any tables that carry only
>> 32-bit addresses, i.e., RSDPv1, RSDTv1 and RSDTv3.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  MdeModulePkg/MdeModulePkg.dec|   7 +
>>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   2 +
>>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 447 
>> 
>>  3 files changed, 270 insertions(+), 186 deletions(-)
>
> Somewhat independently of your patch, I agree 100% that the interface
> exposed by EFI_ACPI_TABLE_PROTOCOL is seriously lacking. It doesn't
> allow the caller to control the allocation limit (--> see your patch),
> nor the UEFI memory type that the copy of the table being installed will
> be placed into (it would be valid for the caller to choose between
> AcpiReclaim vs. AcpiNVS), nor the question whether the table being
> installed should be linked into the RSDT, XSDT, or both.
>
> I don't find this an implementation problem; this is a problem with the
> specification. In particular, in October last year I cross-posted an
> email to the USWG and ASWG lists, entitled
>
>   LoadTable vs. EFI_ACPI_TABLE_PROTOCOL
>
> In that email, I pointed out that the current edk2 implementation of
> EFI_ACPI_TABLE_PROTOCOL makes it impossible to support the LoadTable
> ACPI operator. Namely, the LoadTable operator requires the definition
> block (= AML code) being loaded dynamically to come *from* AcpiNVS type
> memory, but edk2's implementation doesn't allow the caller to install
> tables into AcpiNVS type memory, *except* those with the signature
> "UEFI" -- those however are *data* tables, not definition blocks (= AML
> code, like SSDT or DSDT).
>
> For this reason, I proposed EFI_ACPI_TABLE2_PROTOCOL:
>
>> - same set of member functions
>> - UninstallAcpiTable() works the same
>> - InstallAcpiTable() gets a new parameter called MemoryType:
>>
>> typedef
>> EFI_STATUS
>> (EFIAPI *EFI_ACPI_TABLE2_INSTALL_ACPI_TABLE) (
>>   IN EFI_ACPI_TABLE2_PROTOCOL *This,
>>   IN VOID *AcpiTableBuffer,
>>   IN UINTNAcpiTableBufferSize,
>>   IN EFI_MEMORY_TYPE  *MemoryType OPTIONAL,
>>   OUT UINTN   *TableKey
>> );
>>
>> - If MemoryType is NULL, then the new interface works identically to
>>   the preexistent one.
>> - Otherwise, if EFI_ACPI_TABLE2_PROTOCOL can prove that *MemoryType is
>>   invalid for the signature detected in AcpiTableBuffer, then
>>   EFI_INVALID_PARAMETER is returned.
>> - Otherwise, the copy of AcpiTableBuffer is allocated from *MemoryType
>>   memory.
>>
>> This would allow tables with any (non-standard) signatures to be
>> placed in reserved or AcpiNVS memory, regardless of contents.
>
> My query to the USWG & ASWG garnered exactly *zero* replies. I guess
> nobody cared about (or understood) my problem.
>
> Now I absolutely view your use case as a further parameter that
> "EFI_ACPI_TABLE2_PROTOCOL" should expose. From that POV, I support your
> use case.
>
> Regarding the implementation, I guess you are not enthusiastic about
> turning this question into a standardization effort. (I tried and
> failed.) So, whatever works for you -- I won't review the code, but as
> long as it can remain compatible with current clients, given the right
> PCD settings, I absolutely support the idea.
>

You may be right about the lacking EFI_ACPI_PROTOCOL interface, but
the hardcoded 4 GB limit is simply an implementation detail, and
should be treated as such imo.

> (QEMU currently depends on tables being allocated under 4GB, even for
> aarch64 guests, as far as I recall.)
>

Yes, I wondered about that. After the tables are installed, a 16 KB
reserved region remains in the UEFI memory map, Does that contain any
live payload?

> Digressing a bit, I'll also mention that I found out (and reported) the
> hard way that Microsoft's ACPI.SYS does not implement the
> DataTableRegion operator. (ACPI CA does.) That operator is supposed to
> be extremely powerful, it is not optional, and it dates back to the ACPI
> 2.0 specification -- which Microsoft co-authored.
>

I remember that thread :-)

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

Re: [edk2] [patch] MdePkg: Change PcdPropertiesTableEnable default value to FALSE

[Laszlo Ersek]

On 02/17/16 13:38, Jiewen Yao wrote:
> UEFI2.6 specification does not recommend to use BIT0
> attribute for PropertiesTable, so we change default
> value to FALSE.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: "Yao, Jiewen" 
> Cc: "Gao, Liming" 
> ---
>  MdeModulePkg/MdeModulePkg.dec | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index 5c5a9ee..2df8c19 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -1415,8 +1415,10 @@
># this PCD to be TURE if and only if all runtime driver has seperated 
> Code/Data
># section. If PE code/data sections are merged, the result is 
> unpredictable.
>#
> +  # UEFI 2.6 specification does not recommand to use this BIT0 attribute.

should be "recommend"

> +  #
># @Prompt Publish UEFI PropertiesTable.
> -  
> gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|TRUE|BOOLEAN|0x006e
> +  
> gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE|BOOLEAN|0x006e
>  
>## Default OEM ID for ACPI table creation, its length must be 0x6 bytes to 
> follow ACPI specification.
># @Prompt Default OEM ID for ACPI table creation.
> 

With the typo fixed:

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

[Laszlo Ersek]

On 02/17/16 15:48, Ard Biesheuvel wrote:
> AARCH64 systems never require compatibility with legacy ACPI OSes, and
> may not have any 32-bit addressable system RAM. To support ACPI on these
> systems, we need to be able to relax the 4 GB allocation restriction.
> 
> So add a PCD PcdAcpiAllocateTablesBelow4GB defaulting to TRUE, and wire
> it up to the memory allocation calls in AcpiTableDxe/AcpiTableProtocol.c
> 
> Note that this will inhibit the publishing of any tables that carry only
> 32-bit addresses, i.e., RSDPv1, RSDTv1 and RSDTv3.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  MdeModulePkg/MdeModulePkg.dec|   7 +
>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   2 +
>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 447 
> 
>  3 files changed, 270 insertions(+), 186 deletions(-)

Somewhat independently of your patch, I agree 100% that the interface
exposed by EFI_ACPI_TABLE_PROTOCOL is seriously lacking. It doesn't
allow the caller to control the allocation limit (--> see your patch),
nor the UEFI memory type that the copy of the table being installed will
be placed into (it would be valid for the caller to choose between
AcpiReclaim vs. AcpiNVS), nor the question whether the table being
installed should be linked into the RSDT, XSDT, or both.

I don't find this an implementation problem; this is a problem with the
specification. In particular, in October last year I cross-posted an
email to the USWG and ASWG lists, entitled

  LoadTable vs. EFI_ACPI_TABLE_PROTOCOL

In that email, I pointed out that the current edk2 implementation of
EFI_ACPI_TABLE_PROTOCOL makes it impossible to support the LoadTable
ACPI operator. Namely, the LoadTable operator requires the definition
block (= AML code) being loaded dynamically to come *from* AcpiNVS type
memory, but edk2's implementation doesn't allow the caller to install
tables into AcpiNVS type memory, *except* those with the signature
"UEFI" -- those however are *data* tables, not definition blocks (= AML
code, like SSDT or DSDT).

For this reason, I proposed EFI_ACPI_TABLE2_PROTOCOL:

> - same set of member functions
> - UninstallAcpiTable() works the same
> - InstallAcpiTable() gets a new parameter called MemoryType:
>
> typedef
> EFI_STATUS
> (EFIAPI *EFI_ACPI_TABLE2_INSTALL_ACPI_TABLE) (
>   IN EFI_ACPI_TABLE2_PROTOCOL *This,
>   IN VOID *AcpiTableBuffer,
>   IN UINTNAcpiTableBufferSize,
>   IN EFI_MEMORY_TYPE  *MemoryType OPTIONAL,
>   OUT UINTN   *TableKey
> );
>
> - If MemoryType is NULL, then the new interface works identically to
>   the preexistent one.
> - Otherwise, if EFI_ACPI_TABLE2_PROTOCOL can prove that *MemoryType is
>   invalid for the signature detected in AcpiTableBuffer, then
>   EFI_INVALID_PARAMETER is returned.
> - Otherwise, the copy of AcpiTableBuffer is allocated from *MemoryType
>   memory.
>
> This would allow tables with any (non-standard) signatures to be
> placed in reserved or AcpiNVS memory, regardless of contents.

My query to the USWG & ASWG garnered exactly *zero* replies. I guess
nobody cared about (or understood) my problem.

Now I absolutely view your use case as a further parameter that
"EFI_ACPI_TABLE2_PROTOCOL" should expose. From that POV, I support your
use case.

Regarding the implementation, I guess you are not enthusiastic about
turning this question into a standardization effort. (I tried and
failed.) So, whatever works for you -- I won't review the code, but as
long as it can remain compatible with current clients, given the right
PCD settings, I absolutely support the idea.

(QEMU currently depends on tables being allocated under 4GB, even for
aarch64 guests, as far as I recall.)

Digressing a bit, I'll also mention that I found out (and reported) the
hard way that Microsoft's ACPI.SYS does not implement the
DataTableRegion operator. (ACPI CA does.) That operator is supposed to
be extremely powerful, it is not optional, and it dates back to the ACPI
2.0 specification -- which Microsoft co-authored.

I'm sorry to say, but this makes the ACPI spec, and the ASWG, a joke.

Thanks
Laszlo

> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index 5c5a9ee13138..35da23c15eb5 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -4,6 +4,7 @@
>  # and libraries instances, which are used for those modules.
>  #
>  # Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
> +# Copyright (c) 2016, Linaro Ltd. 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
> @@ -652,6 +653,12 @@ [PcdsFeatureFlag]
># @Prompt 

Re: [edk2] PCD Local Token Numbers in PEI/DXE

[Gao, Liming]

Tim:
  I think we can enhance PCD driver and Build tool to do this check. If the 
mismatch happens, PcdDxe driver will report error message, and not install PCD 
protocol. 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Monday, February 15, 2016 1:59 PM
To: Zeng, Star ; Kinney, Michael D 
; edk2-devel@lists.01.org
Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE

Star --

There are many cases where the PEI FV is not updated because it resides in a 
portion of the flash that is specially protected, often by a pin on the 
motherboard. In many platforms, this recovery firmware in PEI is never updated 
throughout the life of the platform. But DXE might be updated many times. 

We handle the mismatch case often, for HOBs, etc. We design the HOBs, UEFI 
variables, etc. in such a way that the detection can be detected or 
worked-around.

But with PCDs, we cannot detect the mismatch without special knowledge, because 
the PCD driver will return the wrong PCD value.

Tim

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com] 
Sent: Sunday, February 14, 2016 9:54 PM
To: Tim Lewis ; Kinney, Michael D 
; edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: RE: PCD Local Token Numbers in PEI/DXE

Tim,

Basically, I aware PEI as the high-reliability, high-security portion of the 
BIOS.
I mean for this case, should PEI FV be also updated?

And the mismatch seems not a special case for PCD. Consider one situation that 
new DXE wants to consume a HOB produced by new PEI, the new DXE could also not 
work with old PEI.

Thanks,
Star
-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, February 15, 2016 1:45 PM
To: Zeng, Star; Kinney, Michael D; edk2-devel@lists.01.org
Subject: RE: PCD Local Token Numbers in PEI/DXE

Star --

Consider the case where PEI FV is inside the flash boot block, but DXE FV is 
outside of the flash boot block. This case is very common, using PEI as the 
high-reliability, high-security portion of the BIOS.

You are correct, there is another case which is: 

Build #1: PEI database A does not have PCD X, DXE database A has PCD X Build 
#2: PEI database A has PCD X, DXE database A does not have PCD X

If the PEI from #2 is combined with the DXE from #1, there will be two copies 
of the PCD (one in PEI, one in DXE). In our work-around, we searched PEI before 
DXE. The better method might be to timestamp (rather than assume PEI before 
DXE).

Tim

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Sunday, February 14, 2016 9:33 PM
To: Kinney, Michael D ; Tim Lewis 
; edk2-devel@lists.01.org
Subject: RE: PCD Local Token Numbers in PEI/DXE

Mike,

Could one PCD be accessed using both methods Dynamic and DynamicEx in one build?
As I know, it could not.

Another problem is about where the default PCD value stores. Currently, PEI and 
PEI+DXE phase consumed PCDs are stored in PEI PCD database, and only DXE phase 
consumed PCDs are stored in DXE PCD database.
If the new PEI consumes 4+ PCDs, the 4+ PCDs will be stored in PEI database, 
and if DXE also consumes them, the new DXE would not work with old PEI. And is 
it a valid case to only update DXE FV? 


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney, 
Michael D
Sent: Thursday, February 11, 2016 2:21 AM
To: Tim Lewis; edk2-devel@lists.01.org; Kinney, Michael D
Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE

Tim,

All good ideas to evaluate.

We did design in the Dynamic PCDs with generated local tokens to minimize the 
size overhead of the PCD database for source builds.  We can do some size 
impact analysis of these ideas to see which one makes the most sense.

The database is currently optimized for Dynamic PCDs.  When a DynamicEx PCD is 
used it is internally translated to a Dynamic request.  I think all of the 
ideas here require this concept to be reversed.  We need to optimized the 
database for DynamicEx and never reference Dynamic part of database to process 
a DynamicEx request.  If Dynamic is used, it can either be internally 
translated to a DynamicEx request with a fixed token space guid or be processed 
as a local token.  In mixed Dynamic/DynamicEx environments, the same PCD may be 
accessed using both methods.  Current design supports this mixed env, so we 
need to make sure that aspect is not broken if we change internal code/database.

Best regards,

Mike

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, February 10, 2016 9:50 AM
> To: Kinney, Michael D ; 
> edk2-devel@lists.01.org
> Subject: RE: PCD Local Token Numbers in PEI/DXE
> 
> Mike --
> 
> Yes, we use all 

[edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

[Ard Biesheuvel]

AARCH64 systems never require compatibility with legacy ACPI OSes, and
may not have any 32-bit addressable system RAM. To support ACPI on these
systems, we need to be able to relax the 4 GB allocation restriction.

So add a PCD PcdAcpiAllocateTablesBelow4GB defaulting to TRUE, and wire
it up to the memory allocation calls in AcpiTableDxe/AcpiTableProtocol.c

Note that this will inhibit the publishing of any tables that carry only
32-bit addresses, i.e., RSDPv1, RSDTv1 and RSDTv3.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/MdeModulePkg.dec|   7 +
 MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   2 +
 MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 447 

 3 files changed, 270 insertions(+), 186 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 5c5a9ee13138..35da23c15eb5 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -4,6 +4,7 @@
 # and libraries instances, which are used for those modules.
 #
 # Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
+# Copyright (c) 2016, Linaro Ltd. 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
@@ -652,6 +653,12 @@ [PcdsFeatureFlag]
   # @Prompt Enable ACPI SDT support.
   
gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|FALSE|BOOLEAN|0x0001004d
 
+  ## Indicates if ACPI table allocations should be below 4 GB.
+  #   TRUE  - Allocate ACPI tables below 4 GB.
+  #   FALSE - Allocate ACPI tables anywhere.
+  # @Prompt Allocate ACPI tables below 4 GB.
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiAllocateTablesBelow4GB|TRUE|BOOLEAN|0x0001004c
+
   ## Indicates if the unaligned I/O, MMIO, and PCI Configuration cycles 
through the PCI I/O Protocol are enabled.
   #  The default value for this PCD is false to disable support for unaligned 
PCI I/O Protocol requests.
   #   TRUE  - Enables the unaligned I/O, MMIO, and PCI Configuration cycles 
through the PCI I/O Protocol.
diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf 
b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
index e9cd728dbfb6..c5e6788186ce 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
@@ -2,6 +2,7 @@
 #  ACPI Table Protocol Driver
 #
 #  Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+#  Copyright (c) 2016, Linaro Ltd. 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
@@ -67,6 +68,7 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultOemRevision  ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision  ## CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiAllocateTablesBelow4GB  ## CONSUMES
 
 [Protocols]
   gEfiAcpiTableProtocolGuid ## PRODUCES
diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c 
b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
index c6abf1bf0c52..cb2b957989e2 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
+++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
@@ -2,6 +2,7 @@
   ACPI Table Protocol Implementation
 
   Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2016, Linaro Ltd. 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
@@ -21,6 +22,12 @@
 //
 UINTN mEfiAcpiMaxNumTables = EFI_ACPI_MAX_NUM_TABLES; 
 
+//
+// Allocation strategy to use for AllocatePages ().
+// Runtime value depends on PcdAcpiAllocateTablesBelow4GB.
+//
+STATIC EFI_ALLOCATE_TYPE  mAcpiTableAllocType;
+
 /**
   This function adds an ACPI table to the table list.  It will detect FACS and
   allocate the correct type of memory and properly align the table.
@@ -135,8 +142,10 @@ PublishTables (
 *CurrentRsdtEntry = (UINT32) (UINTN) AcpiTableInstance->Fadt1;
   }
   if ((Version & ACPI_TABLE_VERSION_GTE_2_0) != 0) {
-CurrentRsdtEntry  = (UINT32 *) ((UINT8 *) AcpiTableInstance->Rsdt3 + 
sizeof (EFI_ACPI_DESCRIPTION_HEADER));
-*CurrentRsdtEntry = (UINT32) (UINTN) AcpiTableInstance->Fadt3;
+if (FeaturePcdGet (PcdAcpiAllocateTablesBelow4GB)) {
+  CurrentRsdtEntry  = (UINT32 *) ((UINT8 *) 

Re: [edk2] Why is the tools_def.txt file parsed 47 times on my fds build?

[Gao, Liming]

Andrew:
  Thanks for this report. Tottime is second or microsecond? If LoadToolDefFile 
is called only once, how much performance can be saved?

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Tuesday, February 16, 2016 5:42 PM
To: edk2-devel@lists.01.org 
Subject: [edk2] Why is the tools_def.txt file parsed 47 times on my fds build?


I turned on profiling in Python:
BaseTools/BinWrappers/PosixLike/RunToolFromSource:
#!/usr/bin/env bash
#python `dirname $0`/RunToolFromSource.py `basename $0` $*
PYTHONPATH="`dirname $0`/../../Source/Python" \
python -m cProfile -s time "`dirname $0`/../../Source/Python"/`basename 
$0`/`basename $0`.py $*


The slowest item in the working thread was ToolDefClassObject. LoadToolDefFile()

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   478.9320.190   10.9860.234 
ToolDefClassObject.py:60(LoadToolDefFile)
  40674781.3370.0001.3370.000 {method 'split' of 'str' objects}
285191.0640.0001.0640.000 {method 'execute' of 
'sqlite3.Cursor' objects}
   7333780.8260.0001.1610.000 StringIO.py:208(write)
   710.6130.0090.6130.009 {method 'items' of 'dict' objects}
   230.4990.022   11.9050.518 
GuidSection.py:245(__FindExtendTool__)


I see it gets called at the beginning of the build from InitBuild() and that 
makes sense. If I do a genmake build LoadToolDefFile() only gets called a 
single time. 

But it looks like __FindExtendTool__ is also making calls:
 ToolDefinition = 
ToolDefClassObject.ToolDefDict(GenFdsGlobalVariable.ConfDir).ToolsDefTxtDictionary

So it looks to me like class GuidSection() is parsing the tools_def.txt for 
every GUID'ed section that has a GUID defined tool? How come this information 
is not cached? 

Does anyone see a quick fix?

Thanks,

Andrew Fish 
___
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: Change PcdPropertiesTableEnable default value to FALSE

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Yao, Jiewen 
Sent: Wednesday, February 17, 2016 8:39 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen ; Gao, Liming 
Subject: [patch] MdePkg: Change PcdPropertiesTableEnable default value to FALSE

UEFI2.6 specification does not recommend to use BIT0
attribute for PropertiesTable, so we change default
value to FALSE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Cc: "Gao, Liming" 
---
 MdeModulePkg/MdeModulePkg.dec | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 5c5a9ee..2df8c19 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -1415,8 +1415,10 @@
   # this PCD to be TURE if and only if all runtime driver has seperated 
Code/Data
   # section. If PE code/data sections are merged, the result is unpredictable.
   #
+  # UEFI 2.6 specification does not recommand to use this BIT0 attribute.
+  #
   # @Prompt Publish UEFI PropertiesTable.
-  
gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|TRUE|BOOLEAN|0x006e
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE|BOOLEAN|0x006e
 
   ## Default OEM ID for ACPI table creation, its length must be 0x6 bytes to 
follow ACPI specification.
   # @Prompt Default OEM ID for ACPI table creation.
-- 
1.9.5.msysgit.0

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

Re: [edk2] [Patch] BaseTools: report an error message when failed to start build command

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yonghong 
Zhu
Sent: Wednesday, February 17, 2016 6:33 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] BaseTools: report an error message when failed to start 
build command

when build.py was failing to build packages but was not providing any
error message except for “Failed to start command.” this patch provide
the error message.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/build/build.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index 3cd385d..5253cb4 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -1,10 +1,10 @@
 ## @file
 # build a platform or a module
 #
 #  Copyright (c) 2014, Hewlett-Packard Development Company, L.P.
-#  Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
 #  http://opensource.org/licenses/bsd-license.php
@@ -285,10 +285,11 @@ def LaunchCommand(Command, WorkingDir):
 
 # waiting for program exit
 Proc.wait()
 except: # in case of aborting
 # terminate the threads redirecting the program output
+EdkLogger.quiet("(Python %s on %s) " % (platform.python_version(), 
sys.platform) + traceback.format_exc())
 if EndOfProcedure != None:
 EndOfProcedure.set()
 if Proc == None:
 if type(Command) != type(""):
 Command = " ".join(Command)
-- 
2.6.1.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] BaseTools/GenFw: Fix a bug for GCC build

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yonghong 
Zhu
Sent: Wednesday, February 17, 2016 6:33 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] BaseTools/GenFw: Fix a bug for GCC build

current GCC build report error: 'for' loop initial declarations are only
allowed in C99 or C11 mode, the patch fix this failure.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/C/GenFw/Elf32Convert.c | 3 ++-
 BaseTools/Source/C/GenFw/Elf64Convert.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c 
b/BaseTools/Source/C/GenFw/Elf32Convert.c
index d115291..8fca7fb 100644
--- a/BaseTools/Source/C/GenFw/Elf32Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf32Convert.c
@@ -312,11 +312,12 @@ GetSymName (
   assert(Sym->st_name < StrtabShdr->sh_size);
 
   UINT8* StrtabContents = (UINT8*)mEhdr + StrtabShdr->sh_offset;
 
   bool foundEnd = false;
-  for (UINT32 i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) {
+  UINT32 i;
+  for (i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) {
 foundEnd = StrtabContents[i] == 0;
   }
   assert(foundEnd);
 
   return StrtabContents + Sym->st_name;
diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 3b5f630..024a2a0 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -304,11 +304,12 @@ GetSymName (
   assert(Sym->st_name < StrtabShdr->sh_size);
 
   UINT8* StrtabContents = (UINT8*)mEhdr + StrtabShdr->sh_offset;
 
   bool foundEnd = false;
-  for (UINT32 i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) {
+  UINT32 i;
+  for (i= Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) {
 foundEnd = StrtabContents[i] == 0;
   }
   assert(foundEnd);
 
   return StrtabContents + Sym->st_name;
-- 
2.6.1.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] MdeModulePkg: Update PeiCore dispatcher to handle PEIM and PEI_CORE only

[Cohen, Eugene]

> When PcdShadowPeimOnBoot is FALSE, they are not copied to
> memory and
> execute from their original locations. Here, this policy should only
> apply for PEIM and PEI_CORE, not for other file type, such as
> DXE_CORE.

Tested-by: Eugene Cohen 

Sorry for the delay in testing this - thanks for the reminder Liming!

Eugene

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

[edk2] [PATCH] BaseTools: Update ARM/AArch64 GenFv vector processing for encapsulated FVs

[Cohen, Eugene]

Instead of only handling SEC Core or PEI Core instances in the outer FV,
the GenFv tool will now recurse into FV image FFS files to look for instances
in encapsulated FVs so the vector area can be updated appropriately.

Tested on ARM and AArch64 platforms.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen 
---
 BaseTools/Source/C/GenFv/GenFvInternalLib.c | 587 +++-
 1 file changed, 400 insertions(+), 187 deletions(-)

diff --git a/BaseTools/Source/C/GenFv/GenFvInternalLib.c 
b/BaseTools/Source/C/GenFv/GenFvInternalLib.c
index 6ab8a24..845bd3c 100644
--- a/BaseTools/Source/C/GenFv/GenFvInternalLib.c
+++ b/BaseTools/Source/C/GenFv/GenFvInternalLib.c
@@ -3,6 +3,7 @@ This file contains the internal functions required to generate 
a Firmware Volume
 
 Copyright (c) 2004 - 2014, Intel Corporation. All rights reserved.
 Portions Copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
+Portions Copyright (c) 2016 HP 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
@@ -1803,6 +1804,244 @@ Returns:
   return EFI_SUCCESS;
 }
 
+EFI_STATUS
+FindCorePeSection(
+  IN VOID   *FvImageBuffer,
+  IN UINT64 FvSize,
+  IN EFI_FV_FILETYPEFileType,
+  OUT EFI_FILE_SECTION_POINTER  *Pe32Section
+  )
+/*++
+
+Routine Description:
+
+  Recursively searches the FV for the FFS file of specified type (typically
+  SEC or PEI core) and extracts the PE32 section for further processing.
+
+Arguments:
+
+  FvImageBuffer   Buffer containing FV data
+  FvSize  Size of the FV
+  FileTypeType of FFS file to search for
+  Pe32Section PE32 section pointer when FFS file is found.
+
+Returns:
+
+  EFI_SUCCESS Function Completed successfully.
+  EFI_ABORTED Error encountered.
+  EFI_INVALID_PARAMETER   A required parameter was NULL.
+  EFI_NOT_FOUND   Core file not found.
+
+--*/
+{
+  EFI_STATUS  Status;
+  EFI_FIRMWARE_VOLUME_HEADER  *OrigFvHeader;
+  UINT32  OrigFvLength;
+  EFI_FFS_FILE_HEADER *CoreFfsFile;
+  UINTN   FvImageFileCount;
+  EFI_FFS_FILE_HEADER *FvImageFile;
+  UINTN   EncapFvSectionCount;
+  EFI_FILE_SECTION_POINTEREncapFvSection;
+  EFI_FIRMWARE_VOLUME_HEADER  *EncapsulatedFvHeader;
+
+  if (Pe32Section == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  //
+  // Initialize FV library, saving previous values 
+  //
+  OrigFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)NULL;
+  GetFvHeader (, );
+  InitializeFvLib(FvImageBuffer, (UINT32)FvSize);
+
+  //
+  // First see if we can obtain the file directly in outer FV
+  //
+  Status = GetFileByType(FileType, 1, );
+  if (!EFI_ERROR(Status) && (CoreFfsFile != NULL) ) {
+
+//
+// Core found, now find PE32 or TE section
+//
+Status = GetSectionByType(CoreFfsFile, EFI_SECTION_PE32, 1, Pe32Section);
+if (EFI_ERROR(Status)) {
+  Status = GetSectionByType(CoreFfsFile, EFI_SECTION_TE, 1, Pe32Section);
+}
+
+if (EFI_ERROR(Status)) {
+  Error(NULL, 0, 3000, "Invalid", "could not find a PE32 section in the 
core file.");
+  return EFI_ABORTED;
+}
+
+//
+// Core PE/TE section, found, return
+//
+Status = EFI_SUCCESS;
+goto EarlyExit;
+  }
+
+  //
+  // File was not found, look for FV Image file
+  //
+
+  // iterate through all FV image files in outer FV
+  for (FvImageFileCount = 1;; FvImageFileCount++) {
+  
+Status = GetFileByType(EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE, 
FvImageFileCount, );
+
+if (EFI_ERROR(Status) || (FvImageFile == NULL) ) {
+  // exit FV image file loop, no more found
+  break;
+}
+
+// Found an fv image file, look for an FV image section.  The PI spec does 
not
+// preclude multiple FV image sections so we loop accordingly.
+for (EncapFvSectionCount = 1;; EncapFvSectionCount++) {
+  
+  // Look for the next FV image section.  The section search code will
+  // iterate into encapsulation sections.  For example, it will iterate
+  // into an EFI_SECTION_GUID_DEFINED encapsulation section to find the
+  // EFI_SECTION_FIRMWARE_VOLUME_IMAGE sections contained therein.
+  Status = GetSectionByType(FvImageFile, 
EFI_SECTION_FIRMWARE_VOLUME_IMAGE, EncapFvSectionCount, );
+
+  if (EFI_ERROR(Status)) {
+// exit section inner loop, no more found
+break;
+  }
+
+  EncapsulatedFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)((UINT8 
*)EncapFvSection.FVImageSection + 
GetSectionHeaderLength(EncapFvSection.FVImageSection));
+
+  // recurse to search the encapsulated FV for this core file type
+  Status = 

Re: [edk2] [patch] MdePkg: Change PcdPropertiesTableEnable default value to FALSE

[Ard Biesheuvel]

On 17 February 2016 at 13:38, Jiewen Yao  wrote:
> UEFI2.6 specification does not recommend to use BIT0
> attribute for PropertiesTable, so we change default
> value to FALSE.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: "Yao, Jiewen" 
> Cc: "Gao, Liming" 

Reviewed-by: Ard Biesheuvel 

> ---
>  MdeModulePkg/MdeModulePkg.dec | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index 5c5a9ee..2df8c19 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -1415,8 +1415,10 @@
># this PCD to be TURE if and only if all runtime driver has seperated 
> Code/Data
># section. If PE code/data sections are merged, the result is 
> unpredictable.
>#
> +  # UEFI 2.6 specification does not recommand to use this BIT0 attribute.
> +  #
># @Prompt Publish UEFI PropertiesTable.
> -  
> gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|TRUE|BOOLEAN|0x006e
> +  
> gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE|BOOLEAN|0x006e
>
>## Default OEM ID for ACPI table creation, its length must be 0x6 bytes to 
> follow ACPI specification.
># @Prompt Default OEM ID for ACPI table creation.
> --
> 1.9.5.msysgit.0
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [patch] MdePkg: Change PcdPropertiesTableEnable default value to FALSE

[Jiewen Yao]

UEFI2.6 specification does not recommend to use BIT0
attribute for PropertiesTable, so we change default
value to FALSE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Cc: "Gao, Liming" 
---
 MdeModulePkg/MdeModulePkg.dec | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 5c5a9ee..2df8c19 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -1415,8 +1415,10 @@
   # this PCD to be TURE if and only if all runtime driver has seperated 
Code/Data
   # section. If PE code/data sections are merged, the result is unpredictable.
   #
+  # UEFI 2.6 specification does not recommand to use this BIT0 attribute.
+  #
   # @Prompt Publish UEFI PropertiesTable.
-  
gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|TRUE|BOOLEAN|0x006e
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE|BOOLEAN|0x006e
 
   ## Default OEM ID for ACPI table creation, its length must be 0x6 bytes to 
follow ACPI specification.
   # @Prompt Default OEM ID for ACPI table creation.
-- 
1.9.5.msysgit.0

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

Re: [edk2] [patch 0/7] Add UEFI2.6 MemoryAttributesTable support.

[Ard Biesheuvel]

On 17 February 2016 at 13:22, Yao, Jiewen  wrote:
> I collected Intel internal feedback.
>
> 1) We observed the shipping production still using this Properties Table, and 
> UEFI 2.6 specification still keeps the text.  So we want to keep code to give 
> production a way to enable this feature.
> 2) Since UEFI specification marks this as "not recommended", we agree to 
> change default value to FALSE in DEC declaration.
>
> Intel vote #2, at current point of time.
> We vote #3 as long term plan, after UEFI 2.x specification removes the text 
> later.
>

OK, that is fine by me. As long as we agree that it is something that
is on its way to be removed, rather than a valid alternative for the
MemoryAttributes table.

Thanks,
Ard.


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
> Jiewen
> Sent: Tuesday, February 16, 2016 8:51 AM
> To: Laszlo Ersek; Ard Biesheuvel
> Cc: edk2-de...@ml01.01.org; Gao, Liming
> Subject: Re: [edk2] [patch 0/7] Add UEFI2.6 MemoryAttributesTable support.
>
> Thanks. I think it is easy to just choose 2).
> For 3), we need start evaluating if there is any impact to any production.
>
> Thank you
> Yao Jiewen
>
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Sunday, February 14, 2016 6:53 PM
> To: Ard Biesheuvel
> Cc: Yao, Jiewen; edk2-de...@ml01.01.org; Gao, Liming
> Subject: Re: [edk2] [patch 0/7] Add UEFI2.6 MemoryAttributesTable support.
>
> On 02/14/16 10:22, Ard Biesheuvel wrote:
>> On 14 February 2016 at 07:51, Laszlo Ersek  wrote:
>>> On 02/14/16 06:44, Yao, Jiewen wrote:
 HI
 Thanks to discuss this properties table issue.
 The purpose of this patch is to *add* UEFI2.6 memory attributes table. 
 This patch does not handle any UEFI2.5 properties table.
 If we want to change EDKII code for properties table, I suggest we 
 separate it from this patch.

 Is there any comment for adding UEFI2.6 memory attributes table?
>>>
>>> Not from my side, thanks.
>>>
 For UEFI2.5 properties table, let me summarize. Currently, we have several 
 options:
 0) Keep it as is. Current setting is PcdPropertiesTableEnable TRUE in 
 MdeModulePkg.DEC.
 1) Update PcdPropertiesTableEnable to FALSE in XXXPlatform.DSC file.
 (Platform choice. It can be static PCD or dynamic PCD.)
 2) Update PcdPropertiesTableEnable to FALSE in MdeModulePkg.DEC
 file. (Disable Default. BIOS will not publish this table by default.
 If platform wants this table, it can set PCD to true.)
 3) Remove PcdPropertiesTableEnable, and remove PropertiesTable
 support code in DxeCore. (PropertiesTable support is removed.)

 Personally, I do not suggest we choose 3), because this table is still 
 defined in UEFI specification. We can remove it after UEFI spec removes it 
 later.
 I do not have strong opinion for other options.
>>>
>>> I agree the implementation should follow the spec -- at least offer
>>> the feature as long as the spec defines it. My vote would be (2).
>>>
>>
>> I disagree. Not only was the PropertiesTable superseded by the
>> MemoryAttributes table in 2.6, the recommendation not to use the
>> PropertiesTable has also been added to 2.5 errata A, while it was
>> originally defined in 2.5 This means effectively that it has been
>> retracted, and so it does not matter if you claim to implement UEFI
>> 2.4, 2.5 or 2.6, in none of these cases should the PropertiesTable be
>> published.
>
> Well, why not drop the text from the spec completely then?
>
>> The reason that the definition remains in the text is for the OS side,
>> not for the reference implementation of the firmware side, which
>> should steer clear from it entirely.
>
> Okay, but in that case, I sort of think of the edk2 code as something that 
> would let you test an operating system's support for this (mis)feature.
>
> Anyway, I don't disagree with (3) either. If that is what gets implemented, 
> I'll be fine with it. As long as there's a way to disable the (mis)feature -- 
> by way of PCD or complete removal --, I'm okay.
>
> 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 0/7] Add UEFI2.6 MemoryAttributesTable support.

[Yao, Jiewen]

I collected Intel internal feedback.

1) We observed the shipping production still using this Properties Table, and 
UEFI 2.6 specification still keeps the text.  So we want to keep code to give 
production a way to enable this feature.
2) Since UEFI specification marks this as "not recommended", we agree to change 
default value to FALSE in DEC declaration.

Intel vote #2, at current point of time.
We vote #3 as long term plan, after UEFI 2.x specification removes the text 
later.

Thank you
Yao Jiewen

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Tuesday, February 16, 2016 8:51 AM
To: Laszlo Ersek; Ard Biesheuvel
Cc: edk2-de...@ml01.01.org; Gao, Liming
Subject: Re: [edk2] [patch 0/7] Add UEFI2.6 MemoryAttributesTable support.

Thanks. I think it is easy to just choose 2).
For 3), we need start evaluating if there is any impact to any production.

Thank you
Yao Jiewen

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Sunday, February 14, 2016 6:53 PM
To: Ard Biesheuvel
Cc: Yao, Jiewen; edk2-de...@ml01.01.org; Gao, Liming
Subject: Re: [edk2] [patch 0/7] Add UEFI2.6 MemoryAttributesTable support.

On 02/14/16 10:22, Ard Biesheuvel wrote:
> On 14 February 2016 at 07:51, Laszlo Ersek  wrote:
>> On 02/14/16 06:44, Yao, Jiewen wrote:
>>> HI
>>> Thanks to discuss this properties table issue.
>>> The purpose of this patch is to *add* UEFI2.6 memory attributes table. This 
>>> patch does not handle any UEFI2.5 properties table.
>>> If we want to change EDKII code for properties table, I suggest we separate 
>>> it from this patch.
>>>
>>> Is there any comment for adding UEFI2.6 memory attributes table?
>>
>> Not from my side, thanks.
>>
>>> For UEFI2.5 properties table, let me summarize. Currently, we have several 
>>> options:
>>> 0) Keep it as is. Current setting is PcdPropertiesTableEnable TRUE in 
>>> MdeModulePkg.DEC.
>>> 1) Update PcdPropertiesTableEnable to FALSE in XXXPlatform.DSC file. 
>>> (Platform choice. It can be static PCD or dynamic PCD.)
>>> 2) Update PcdPropertiesTableEnable to FALSE in MdeModulePkg.DEC 
>>> file. (Disable Default. BIOS will not publish this table by default.
>>> If platform wants this table, it can set PCD to true.)
>>> 3) Remove PcdPropertiesTableEnable, and remove PropertiesTable 
>>> support code in DxeCore. (PropertiesTable support is removed.)
>>>
>>> Personally, I do not suggest we choose 3), because this table is still 
>>> defined in UEFI specification. We can remove it after UEFI spec removes it 
>>> later.
>>> I do not have strong opinion for other options.
>>
>> I agree the implementation should follow the spec -- at least offer 
>> the feature as long as the spec defines it. My vote would be (2).
>>
> 
> I disagree. Not only was the PropertiesTable superseded by the 
> MemoryAttributes table in 2.6, the recommendation not to use the 
> PropertiesTable has also been added to 2.5 errata A, while it was 
> originally defined in 2.5 This means effectively that it has been 
> retracted, and so it does not matter if you claim to implement UEFI 
> 2.4, 2.5 or 2.6, in none of these cases should the PropertiesTable be 
> published.

Well, why not drop the text from the spec completely then?

> The reason that the definition remains in the text is for the OS side, 
> not for the reference implementation of the firmware side, which 
> should steer clear from it entirely.

Okay, but in that case, I sort of think of the edk2 code as something that 
would let you test an operating system's support for this (mis)feature.

Anyway, I don't disagree with (3) either. If that is what gets implemented, 
I'll be fine with it. As long as there's a way to disable the (mis)feature -- 
by way of PCD or complete removal --, I'm okay.

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] [Patch] BaseTools/Trim: Fix the bug for stripping when no line directive in file

[Yonghong Zhu]

when no line directive in file, the tool still need to strip the typedef
statement (eg: typedef struct, typedef union ..).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Trim/Trim.py | 37 +---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Source/Python/Trim/Trim.py 
b/BaseTools/Source/Python/Trim/Trim.py
index 8fefa1b..e5fe730 100644
--- a/BaseTools/Source/Python/Trim/Trim.py
+++ b/BaseTools/Source/Python/Trim/Trim.py
@@ -1,9 +1,9 @@
 ## @file
 # Trim files preprocessed by compiler
 #
-# Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution.  The full text of the license may be 
found at
 # http://opensource.org/licenses/bsd-license.php
 #
@@ -27,18 +27,22 @@ import Common.EdkLogger as EdkLogger
 from Common.LongFilePathSupport import OpenLongFilePath as open
 
 # Version and Copyright
 __version_number__ = ("0.10" + " " + gBUILD_VERSION)
 __version__ = "%prog Version " + __version_number__
-__copyright__ = "Copyright (c) 2007-2010, Intel Corporation. All rights 
reserved."
+__copyright__ = "Copyright (c) 2007-2016, Intel Corporation. All rights 
reserved."
 
 ## Regular expression for matching Line Control directive like "#line xxx"
 gLineControlDirective = re.compile('^\s*#(?:line)?\s+([0-9]+)\s+"*([^"]*)"')
 ## Regular expression for matching "typedef struct"
 gTypedefPattern = re.compile("^\s*typedef\s+struct(\s+\w+)?\s*[{]*$", 
re.MULTILINE)
 ## Regular expression for matching "#pragma pack"
 gPragmaPattern = re.compile("^\s*#pragma\s+pack", re.MULTILINE)
+## Regular expression for matching "typedef"
+gTypedef_SinglePattern = re.compile("^\s*typedef", re.MULTILINE)
+## Regular expression for matching "typedef struct, typedef union, struct, 
union"
+gTypedef_MulPattern = 
re.compile("^\s*(typedef)?\s+(struct|union)(\s+\w+)?\s*[{]*$", re.MULTILINE)
 
 #
 # The following number pattern match will only match if following criteria is 
met:
 # There is leading non-(alphanumeric or _) character, and no following 
alphanumeric or _
 # as the pattern is greedily match, so it is ok for the gDecNumberPattern or 
gHexNumberPattern to grab the maximum match
@@ -204,11 +208,38 @@ def TrimPreprocessedFile(Source, Target, ConvertHex, 
TrimLong):
 else:
 NewLines.append(Line)
 
 # in case there's no line directive or linemarker found
 if (not LineControlDirectiveFound) and NewLines == []:
-NewLines = Lines
+MulPatternFlag = False
+SinglePatternFlag = False
+Brace = 0
+for Index in range(len(Lines)):
+Line = Lines[Index]
+if MulPatternFlag == False and gTypedef_MulPattern.search(Line) == 
None:
+if SinglePatternFlag == False and 
gTypedef_SinglePattern.search(Line) == None:
+# remove "#pragram pack" directive
+if gPragmaPattern.search(Line) == None:
+NewLines.append(Line)
+continue
+elif SinglePatternFlag == False:
+SinglePatternFlag = True
+if Line.find(";") >= 0:
+SinglePatternFlag = False
+elif MulPatternFlag == False:
+# found "typedef struct, typedef union, union, struct", keep 
its position and set a flag
+MulPatternFlag = True
+
+# match { and } to find the end of typedef definition
+if Line.find("{") >= 0:
+Brace += 1
+elif Line.find("}") >= 0:
+Brace -= 1
+
+# "typedef struct, typedef union, union, struct" must end with a 
";"
+if Brace == 0 and Line.find(";") >= 0:
+MulPatternFlag = False
 
 # save to file
 try:
 f = open (Target, 'wb')
 except:
-- 
2.6.1.windows.1

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

[edk2] [Patch] BaseTools/VolInfo: add some generic options

[Yonghong Zhu]

The Help information provided by VolInfo does not follow the EDK II Tools
Design doc, so this patch update the help text and add the generic
options: -d, -v, -q, -s.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/C/VolInfo/VolInfo.c | 141 +++
 1 file changed, 94 insertions(+), 47 deletions(-)

diff --git a/BaseTools/Source/C/VolInfo/VolInfo.c 
b/BaseTools/Source/C/VolInfo/VolInfo.c
index 4fa87d4..ba26042 100644
--- a/BaseTools/Source/C/VolInfo/VolInfo.c
+++ b/BaseTools/Source/C/VolInfo/VolInfo.c
@@ -37,10 +37,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include "EfiUtilityMsgs.h"
 #include "FirmwareVolumeBufferLib.h"
 #include "OsPath.h"
 #include "ParseGuidedSectionTools.h"
 #include "StringFuncs.h"
+#include "ParseInf.h"
 
 //
 // Utility global variables
 //
 
@@ -161,10 +162,11 @@ Returns:
   EFI_FIRMWARE_VOLUME_HEADER  *FvImage;
   UINT32  FvSize;
   EFI_STATUS  Status;
   int Offset;
   BOOLEAN ErasePolarity;
+  UINT64  LogLevel;
 
   SetUtilityName (UTILITY_NAME);
   //
   // Print utility header
   //
@@ -173,32 +175,50 @@ Returns:
 UTILITY_MAJOR_VERSION,
 UTILITY_MINOR_VERSION,
 __BUILD_VERSION
 );
 
-  //
-  // Save, and then skip filename arg
-  //
-  mUtilityFilename = argv[0];
+  if (argc == 1) {
+Usage ();
+return -1;
+  }
+
   argc--;
   argv++;
-
+  LogLevel = 0;
   Offset = 0;
 
   //
+  // Look for help options
+  //
+  if ((strcmp(argv[0], "-h") == 0) || (strcmp(argv[0], "--help") == 0) ||
+  (strcmp(argv[0], "-?") == 0) || (strcmp(argv[0], "/?") == 0)) {
+Usage();
+return  STATUS_SUCCESS;
+  }
+  //
+  // Version has already be printed, so just return success
+  //
+  if (strcmp(argv[0], "--version") == 0) {
+return  STATUS_SUCCESS;
+  }
+
+  //
   // If they specified -x xref guid/basename cross-reference files, process it.
   // This will print the basename beside each file guid. To use it, specify
   // -x xref_filename to processdsc, then use xref_filename as a parameter
   // here.
   //
-  while (argc > 2) {
+  while (argc > 0) {
 if ((strcmp(argv[0], "-x") == 0) || (strcmp(argv[0], "--xref") == 0)) {
   ParseGuidBaseNameFile (argv[1]);
   printf("ParseGuidBaseNameFile: %s\n", argv[1]);
   argc -= 2;
   argv += 2;
-} else if (strcmp(argv[0], "--offset") == 0) {
+  continue;
+}
+if (strcmp(argv[0], "--offset") == 0) {
   //
   // Hex or decimal?
   //
   if ((argv[1][0] == '0') && (tolower ((int)argv[1][1]) == 'x')) {
 if (sscanf (argv[1], "%x", ) != 1) {
@@ -218,42 +238,59 @@ Returns:
 }
   }
 
   argc -= 2;
   argv += 2;
-} else {
-  Usage ();
-  return -1;
+  continue;
 }
+
+if ((stricmp (argv[0], "-v") == 0) || (stricmp (argv[0], "--verbose") == 
0)) {
+  SetPrintLevel (VERBOSE_LOG_LEVEL);
+  argc --;
+  argv ++;
+  continue;
+}
+
+if ((stricmp (argv[0], "-q") == 0) || (stricmp (argv[0], "--quiet") == 0)) 
{
+  SetPrintLevel (KEY_LOG_LEVEL);
+  argc --;
+  argv ++;
+  continue;
+}
+
+if ((stricmp (argv[0], "-d") == 0) || (stricmp (argv[0], "--debug") == 0)) 
{
+  Status = AsciiStringToUint64 (argv[1], FALSE, );
+  if (EFI_ERROR (Status)) {
+Error (NULL, 0, 1003, "Invalid option value", "%s = %s", argv[0], 
argv[1]);
+return -1;
+  }
+  if (LogLevel > 9) {
+Error (NULL, 0, 1003, "Invalid option value", "Debug Level range is 
0-9, current input level is %d", (int) LogLevel);
+return -1;
+  }
+  SetPrintLevel (LogLevel);
+  DebugMsg (NULL, 0, 9, "Debug Mode Set", "Debug Output Mode Level %s is 
set!", argv[1]);
+  argc -= 2;
+  argv += 2;
+  continue;
+}
+
+mUtilityFilename = argv[0];
+argc --;
+argv ++;
   }
-  //
-  // Check for proper number of arguments
-  //
-  if (argc != 1) {
-Usage ();
-return STATUS_ERROR;
-  }
-  //
-  // Look for help options
-  //
-  if ((strcmp(argv[0], "-h") == 0) || (strcmp(argv[0], "--help") == 0) || 
-  (strcmp(argv[0], "-?") == 0) || (strcmp(argv[0], "/?") == 0)) {
-Usage();
-return STATUS_SUCCESS;
-  }
-  //
-  // Version has already been printed, return success.
-  //
-  if (strcmp(argv[0], "--version") == 0) {
-return STATUS_SUCCESS;
-  }
+
   //
   // Open the file containing the FV
   //
-  InputFile = fopen (LongFilePath (argv[0]), "rb");
+  if (mUtilityFilename == NULL) {
+Error (NULL, 0, 1001, "Missing option", "Input files are not specified");
+return GetUtilityStatus ();
+  }
+  InputFile = fopen (LongFilePath (mUtilityFilename), "rb");
   if (InputFile == NULL) {
-Error (NULL, 0, 0001, "Error opening the input file", argv[0]);
+Error (NULL, 0, 0001, "Error opening 

[edk2] [Patch] BaseTools: report an error message when failed to start build command

[Yonghong Zhu]

when build.py was failing to build packages but was not providing any
error message except for “Failed to start command.” this patch provide
the error message.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/build/build.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index 3cd385d..5253cb4 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -1,10 +1,10 @@
 ## @file
 # build a platform or a module
 #
 #  Copyright (c) 2014, Hewlett-Packard Development Company, L.P.
-#  Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
 #  http://opensource.org/licenses/bsd-license.php
@@ -285,10 +285,11 @@ def LaunchCommand(Command, WorkingDir):
 
 # waiting for program exit
 Proc.wait()
 except: # in case of aborting
 # terminate the threads redirecting the program output
+EdkLogger.quiet("(Python %s on %s) " % (platform.python_version(), 
sys.platform) + traceback.format_exc())
 if EndOfProcedure != None:
 EndOfProcedure.set()
 if Proc == None:
 if type(Command) != type(""):
 Command = " ".join(Command)
-- 
2.6.1.windows.1

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

[edk2] [Patch] BaseTools/GenFw: Fix a bug for GCC build

[Yonghong Zhu]

current GCC build report error: 'for' loop initial declarations are only
allowed in C99 or C11 mode, the patch fix this failure.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/C/GenFw/Elf32Convert.c | 3 ++-
 BaseTools/Source/C/GenFw/Elf64Convert.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c 
b/BaseTools/Source/C/GenFw/Elf32Convert.c
index d115291..8fca7fb 100644
--- a/BaseTools/Source/C/GenFw/Elf32Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf32Convert.c
@@ -312,11 +312,12 @@ GetSymName (
   assert(Sym->st_name < StrtabShdr->sh_size);
 
   UINT8* StrtabContents = (UINT8*)mEhdr + StrtabShdr->sh_offset;
 
   bool foundEnd = false;
-  for (UINT32 i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) {
+  UINT32 i;
+  for (i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) {
 foundEnd = StrtabContents[i] == 0;
   }
   assert(foundEnd);
 
   return StrtabContents + Sym->st_name;
diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 3b5f630..024a2a0 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -304,11 +304,12 @@ GetSymName (
   assert(Sym->st_name < StrtabShdr->sh_size);
 
   UINT8* StrtabContents = (UINT8*)mEhdr + StrtabShdr->sh_offset;
 
   bool foundEnd = false;
-  for (UINT32 i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) {
+  UINT32 i;
+  for (i= Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) {
 foundEnd = StrtabContents[i] == 0;
   }
   assert(foundEnd);
 
   return StrtabContents + Sym->st_name;
-- 
2.6.1.windows.1

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

[edk2] [patch] MdeModulePkg: Refine the code in BootMaintenanceManagerUiLib

[Dandan Bi]

Refine the code in function Var_UpdateDriverOption and Var_UpdateBootOption,
use the existed API(EfiBootManagerInitializeLoadOption and
EfiBootManagerAddLoadOptionVariable) supplied by UefiBootManagerLib
to replace the same logic in the two functions. And remove the useless
code.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 .../BootMaintenanceManager.h   |  11 +-
 .../BootMaintenanceManagerUiLib/BootOption.c   |  21 +-
 .../Library/BootMaintenanceManagerUiLib/Variable.c | 226 ++---
 3 files changed, 71 insertions(+), 187 deletions(-)

diff --git 
a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
index 24526e1..b482bf2 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
@@ -1,9 +1,9 @@
 /** @file
 Header file for boot maintenance module.
 
-Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
 http://opensource.org/licenses/bsd-license.php
 
@@ -266,28 +266,19 @@ typedef struct {
   EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
 } BM_TERMINAL_CONTEXT;
 
 typedef struct {
   BOOLEAN   IsBootNext;
-  BOOLEAN   LoadOptionModified;
   BOOLEAN   Deleted;
 
   BOOLEAN   IsLegacy;
-  BOOLEAN   IsActive;
-  BOOLEAN   ForceReconnect;
-  UINTN OptionalDataSize;
-
-  UINTN LoadOptionSize;
-  UINT8 *LoadOption;
 
   UINT32Attributes;
   UINT16FilePathListLength;
   UINT16*Description;
   EFI_DEVICE_PATH_PROTOCOL  *FilePathList;
   UINT8 *OptionalData;
-
-  UINT16BbsIndex;
 } BM_LOAD_CONTEXT;
 
 typedef struct {
 
   BOOLEAN   IsActive;
diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
index a375d61..5665d04 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
@@ -3,11 +3,11 @@
 
   Include file system navigation, system handle selection
 
   Boot option manipulation
 
-Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
 http://opensource.org/licenses/bsd-license.php
 
@@ -114,11 +114,10 @@ BOpt_DestroyMenuEntry (
   //
   switch (MenuEntry->ContextSelection) {
   case BM_LOAD_CONTEXT_SELECT:
 LoadContext = (BM_LOAD_CONTEXT *) MenuEntry->VariableContext;
 FreePool (LoadContext->FilePathList);
-FreePool (LoadContext->LoadOption);
 if (LoadContext->OptionalData != NULL) {
   FreePool (LoadContext->OptionalData);
 }
 FreePool (LoadContext);
 break;
@@ -334,11 +333,10 @@ BOpt_GetBootOptions (
 
 LoadOptionPtr   = LoadOption;
 LoadOptionEnd   = LoadOption + BootOptionSize;
 
 NewMenuEntry->OptionNumber  = BootOrderList[Index];
-NewLoadContext->LoadOptionModified  = FALSE;
 NewLoadContext->Deleted = FALSE;
 NewLoadContext->IsBootNext  = BootNextFlag;
 
 //
 // Is a Legacy Device?
@@ -372,17 +370,12 @@ BOpt_GetBootOptions (
 //
 // LoadOption is a pointer type of UINT8
 // for easy use with following LOAD_OPTION
 // embedded in this struct
 //
-NewLoadContext->LoadOption  = LoadOption;
-NewLoadContext->LoadOptionSize  = BootOptionSize;
 
 NewLoadContext->Attributes  = *(UINT32 *) LoadOptionPtr;
-NewLoadContext->IsActive= (BOOLEAN) (NewLoadContext->Attributes & 
LOAD_OPTION_ACTIVE);
-
-NewLoadContext->ForceReconnect  = (BOOLEAN) (NewLoadContext->Attributes & 
LOAD_OPTION_FORCE_RECONNECT);
 
 LoadOptionPtr += sizeof (UINT32);
 
 NewLoadContext->FilePathListLength = *(UINT16 *) LoadOptionPtr;
 LoadOptionPtr += sizeof (UINT16);
@@ -424,12 +417,10 @@ BOpt_GetBootOptions (
   CopyMem (
 NewLoadContext->OptionalData,
 LoadOptionPtr,
 OptionalDataSize
 );
-
-  

Re: [edk2] [patch 0/2] Add new HII action type EFI_BROWSER_ACTION_SUBMITTED

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dandan 
> Bi
> Sent: Tuesday, February 16, 2016 7:55 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric; Gao, Liming
> Subject: [edk2] [patch 0/2] Add new HII action type 
> EFI_BROWSER_ACTION_SUBMITTED
> 
> The following two patches mainly add the new HII action
> type EFI_BROWSER_ACTION_SUBMITTED to notify HII driver
> when its question values are submitted.
> 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> 
> Dandan Bi (2):
>   MdePkg: Add new HII action type EFI_BROWSER_ACTION_SUBMITTED
>   MdeModulePkg: Add new HII action type EFI_BROWSER_ACTION_SUBMITTED
> 
>  MdeModulePkg/Universal/SetupBrowserDxe/Setup.c | 170 
> -
>  MdePkg/Include/Protocol/HiiConfigAccess.h  |   3 +-
>  2 files changed, 138 insertions(+), 35 deletions(-)
> 
> --
> 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] BaseTools: LzmaCompress: eliminate _maxMode and bogus indentation

[Laszlo Ersek]

On 02/16/16 21:47, Jordan Justen wrote:
> On 2016-02-15 10:47:28, Laszlo Ersek wrote:
>> The "_maxMode" variable doesn't exist in edk2's variant of LzmaCompress,
>> but the way one of the old uses of the variable is commented out (i.e.,
>> together with the enclosing "if" statement) triggers the
>> "misleading-indentation" warning that is new in gcc-6.0, for the block of
>> code that originally depended on the "if" statement. Gcc believes
>> (mistakenly) that the programmer believes (mistakenly) that the block
>> depends on (repIndex == 0) higher up.
>>
>> Remove the commented out uses of "_maxMode", and unindent the block in
>> question.
>>
>> This patch is best viewed with "git show -b".
>>
>> Cc: Cole Robinson 
>> Cc: Yonghong Zhu 
>> Cc: Liming Gao 
>> Reported-by: Cole Robinson 
>> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1307439
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c | 81 
>> -
>>  1 file changed, 40 insertions(+), 41 deletions(-)
>>
>> diff --git a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c 
>> b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
>> index 9b2dd16ffa48..1eb9898b5291 100644
>> --- a/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
>> +++ b/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
>> @@ -1367,52 +1367,51 @@ static UInt32 GetOptimum(CLzmaEnc *p, UInt32 
>> position, UInt32 *backRes)
>>if (repIndex == 0)
>>  startLen = lenTest + 1;
>>  
>> -  /* if (_maxMode) */
> 
> This also seems to exist as-is in the LZMA SDK code. So, it is not an
> EDK II deviation.
> 
> One of the things I tried to do with incorporating the LZMA SDK was
> minimize any changes to LZMA SDK files. This would hopefully make it
> easier to merge in newer versions of the SDK. (Which, of course, we've
> never done.)
> 
> Nevertheless, what about just making this change instead:
> 
> -  /* if (_maxMode) */
> +  if (1 /* _maxMode */)

Clearly, that was my first thought as well, but you never know when gcc
will have a bad day and warn about the above as "condition always
evaluates to true".

Cole, can you please try reverting the patch I sent you earlier (i.e.,
this patch) from the fedora tools build, and replace it with Jordan's
suggestion? If that too builds with gcc-6, then I'll submit it as
another normal patch, and once it's upstream, you can rebase the fedora
package (or just pick up the simpler replacement patch).

Thanks!
Laszlo

> 
> -Jordan
> 
>> +  {
>> +UInt32 lenTest2 = lenTest + 1;
>> +UInt32 limit = lenTest2 + p->numFastBytes;
>> +UInt32 nextRepMatchPrice;
>> +if (limit > numAvailFull)
>> +  limit = numAvailFull;
>> +for (; lenTest2 < limit && data[lenTest2] == data2[lenTest2]; 
>> lenTest2++);
>> +lenTest2 -= lenTest + 1;
>> +if (lenTest2 >= 2)
>>  {
>> -  UInt32 lenTest2 = lenTest + 1;
>> -  UInt32 limit = lenTest2 + p->numFastBytes;
>> -  UInt32 nextRepMatchPrice;
>> -  if (limit > numAvailFull)
>> -limit = numAvailFull;
>> -  for (; lenTest2 < limit && data[lenTest2] == data2[lenTest2]; 
>> lenTest2++);
>> -  lenTest2 -= lenTest + 1;
>> -  if (lenTest2 >= 2)
>> +  UInt32 state2 = kRepNextStates[state];
>> +  UInt32 posStateNext = (position + lenTest) & p->pbMask;
>> +  UInt32 curAndLenCharPrice =
>> +  price + p->repLenEnc.prices[posState][lenTest - 2] +
>> +  GET_PRICE_0(p->isMatch[state2][posStateNext]) +
>> +  LitEnc_GetPriceMatched(LIT_PROBS(position + lenTest, 
>> data[lenTest - 1]),
>> +  data[lenTest], data2[lenTest], p->ProbPrices);
>> +  state2 = kLiteralNextStates[state2];
>> +  posStateNext = (position + lenTest + 1) & p->pbMask;
>> +  nextRepMatchPrice = curAndLenCharPrice +
>> +  GET_PRICE_1(p->isMatch[state2][posStateNext]) +
>> +  GET_PRICE_1(p->isRep[state2]);
>> +
>> +  /* for (; lenTest2 >= 2; lenTest2--) */
>>{
>> -UInt32 state2 = kRepNextStates[state];
>> -UInt32 posStateNext = (position + lenTest) & p->pbMask;
>> -UInt32 curAndLenCharPrice =
>> -price + p->repLenEnc.prices[posState][lenTest - 2] +
>> -GET_PRICE_0(p->isMatch[state2][posStateNext]) +
>> -LitEnc_GetPriceMatched(LIT_PROBS(position + lenTest, 
>> data[lenTest - 1]),
>> -data[lenTest], data2[lenTest], p->ProbPrices);
>> -state2 = kLiteralNextStates[state2];
>> -posStateNext = (position + lenTest + 1) & p->pbMask;
>> -nextRepMatchPrice = curAndLenCharPrice +
>> -

Re: [edk2] [PATCH v3 1/2] MdeModulePkg: Define a general function to create DNS QName

[Ye, Ting]

Reviewed-by: Ye Ting 

Thanks,
Ting

-Original Message-
From: Wu, Jiaxin 
Sent: Wednesday, February 17, 2016 2:52 PM
To: edk2-devel@lists.01.org
Cc: Hegde Nagaraj P ; El-Haj-Mahmoud Samer 
; Ye, Ting ; Fu, Siyuan 

Subject: [PATCH v3 1/2] MdeModulePkg: Define a general function to create DNS 
QName

v3:
* Fix potential overflow issue.

This patch is used to define a general function to create DNS QName.
QName is a domain name represented as a sequence of labels, where each label 
consists of a length octet followed by that number of octets. The domain name 
terminates with the zero length octet for the null label of the root.

Cc: Hegde Nagaraj P 
Cc: El-Haj-Mahmoud Samer 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 MdeModulePkg/Include/Library/NetLib.h  | 22 ++
 MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 69 +-
 2 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Include/Library/NetLib.h 
b/MdeModulePkg/Include/Library/NetLib.h
index e4456fa..b871a85 100644
--- a/MdeModulePkg/Include/Library/NetLib.h
+++ b/MdeModulePkg/Include/Library/NetLib.h
@@ -35,10 +35,12 @@ typedef UINT16  TCP_PORTNO;
 #define  EFI_IP_PROTO_UDP  0x11
 #define  EFI_IP_PROTO_TCP  0x06
 #define  EFI_IP_PROTO_ICMP 0x01
 #define  IP4_PROTO_IGMP0x02
 #define  IP6_ICMP  58
+#define  DNS_MAX_NAME_SIZE 255
+#define  DNS_MAX_MESSAGE_SIZE  512
 
 //
 // The address classification
 //
 #define  IP4_ADDR_CLASSA   1
@@ -2154,6 +2156,26 @@ EFI_STATUS
 EFIAPI
 NetLibGetSystemGuid (
   OUT EFI_GUID  *SystemGuid
   );
 
+/**
+  Create Dns QName according the queried domain name. 
+  QName is a domain name represented as a sequence of labels,
+  where each label consists of a length octet followed by that
+  number of octets. The QName terminates with the zero
+  length octet for the null label of the root. Caller should
+  take responsibility to free the buffer in returned pointer.
+
+  @param  DomainNameThe pointer to the queried domain name string.  
+
+  @retval NULL  Failed to fill QName.
+  @return   QName filled successfully.
+  
+**/
+CHAR8 *
+EFIAPI
+NetLibCreateDnsQName (
+  IN  CHAR16  *DomainName
+  );
+
 #endif
diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c 
b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
index e112d45..ebc3e12 100644
--- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
+++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
@@ -1,9 +1,9 @@
 /** @file
   Network library.
 
-Copyright (c) 2005 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
 (C) Copyright 2015 Hewlett Packard Enterprise Development LP  This program 
and the accompanying materials  are licensed and made available under the terms 
and conditions of the BSD License  which accompanies this distribution.  The 
full text of the license may be found at  
http://opensource.org/licenses/bsd-license.php
@@ -3324,5 +3324,72 @@ NetLibGetSystemGuid (
   }
 } while (TRUE);
   } while (Smbios.Raw < SmbiosEnd.Raw);
   return EFI_NOT_FOUND;
 }
+
+/**
+  Create Dns QName according the queried domain name. 
+  QName is a domain name represented as a sequence of labels,
+  where each label consists of a length octet followed by that
+  number of octets. The QName terminates with the zero
+  length octet for the null label of the root. Caller should
+  take responsibility to free the buffer in returned pointer.
+
+  @param  DomainNameThe pointer to the queried domain name string.  
+
+  @retval NULL  Failed to fill QName.
+  @return   QName filled successfully.
+  
+**/
+CHAR8 *
+EFIAPI
+NetLibCreateDnsQName (
+  IN  CHAR16  *DomainName
+  )
+{
+  CHAR8 *QueryName;
+  UINTN QueryNameSize;
+  CHAR8 *Header;
+  CHAR8 *Tail;
+  UINTN Len;
+  UINTN Index;
+
+  QueryName = NULL;
+  QueryNameSize = 0;
+  Header= NULL;
+  Tail  = NULL;
+
+  //
+  // One byte for first label length, one byte for terminated length zero. 
+  //
+  QueryNameSize = StrLen (DomainName) + 2;
+  
+  if (QueryNameSize > DNS_MAX_NAME_SIZE) {
+return NULL;
+  }
+
+  QueryName = AllocateZeroPool (QueryNameSize);  if (QueryName == NULL) 
+ {
+return NULL;
+  }
+  
+  Header = QueryName;
+  Tail = Header + 1;
+  Len = 0;
+  for (Index = 0; DomainName[Index] != 0; Index++) {
+*Tail = (CHAR8) DomainName[Index];
+if (*Tail == '.') {
+  *Header = (CHAR8) Len;
+  Header = Tail;
+  Tail ++;
+  Len = 0;
+ 

Re: [edk2] [Patch 3/3] BaseTools/GenFw: Correct datatypes in diagnostic messages and check for string termination

[Zhu, Yonghong]

Thanks for report. I will fix it soon.

Best Regards,

Zhu Yonghong

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Wednesday, February 17, 2016 4:28 PM
To: Gao, Liming
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [Patch 3/3] BaseTools/GenFw: Correct datatypes in 
diagnostic messages and check for string termination

On 1 February 2016 at 03:10, Liming Gao  wrote:
> From: Michael LeMay 
>
> This patch revises multiple diagnostic messages to use correct 
> datatypes.  It also checks that a symbol name that is about to be used 
> in a diagnostic message is terminated by a null character within the 
> contents of the string table section so that the print routine does 
> not read past the end of the string table section contents when 
> reading the symbol name.
>
> Signed-off-by: Michael LeMay 

Hello Liming,

This patch is breaking the BaseTools build under GCC:

Elf32Convert.c: In function 'GetSymName':
Elf32Convert.c:317:3: error: 'for' loop initial declarations are only allowed 
in C99 or C11 mode
   for (UINT32 i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) {
   ^
Elf32Convert.c:317:3: note: use option -std=c99, -std=gnu99, -std=c11 or 
-std=gnu11 to compile your code

Regards,
Ard.

> ---
>  BaseTools/Source/C/GenFw/Elf32Convert.c | 15 ---  
> BaseTools/Source/C/GenFw/Elf64Convert.c | 15 ---
>  2 files changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c 
> b/BaseTools/Source/C/GenFw/Elf32Convert.c
> index a842ceb..d4258e5 100644
> --- a/BaseTools/Source/C/GenFw/Elf32Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf32Convert.c
> @@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  #include 
>  #endif
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -310,7 +311,15 @@ GetSymName (
>
>assert(Sym->st_name < StrtabShdr->sh_size);
>
> -  return (UINT8*)mEhdr + StrtabShdr->sh_offset + Sym->st_name;
> +  UINT8* StrtabContents = (UINT8*)mEhdr + StrtabShdr->sh_offset;
> +
> +  bool foundEnd = false;
> +  for (UINT32 i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) 
> {
> +foundEnd = StrtabContents[i] == 0;  }  assert(foundEnd);
> +
> +  return StrtabContents + Sym->st_name;
>  }
>
>  //
> @@ -539,7 +548,7 @@ ScanSections32 (
>  NtHdr->Pe32.OptionalHeader.Magic = EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC;
>  break;
>default:
> -VerboseMsg ("%s unknown e_machine type. Assume IA-32", 
> (UINTN)mEhdr->e_machine);
> +VerboseMsg ("%s unknown e_machine type %hu. Assume IA-32", 
> + mInImageName, mEhdr->e_machine);
>  NtHdr->Pe32.FileHeader.Machine = EFI_IMAGE_MACHINE_IA32;
>  NtHdr->Pe32.OptionalHeader.Magic = EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC;
>}
> @@ -725,7 +734,7 @@ WriteSections32 (
>}
>
>Error (NULL, 0, 3000, "Invalid",
> - "%s: Bad definition for symbol '%s'@%p or unsupported 
> symbol type.  "
> + "%s: Bad definition for symbol '%s'@%#x or unsupported 
> symbol type.  "
>   "For example, absolute and undefined symbols are not 
> supported.",
>   mInImageName, SymName, Sym->st_value);
>
> diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
> b/BaseTools/Source/C/GenFw/Elf64Convert.c
> index fad270c..7b7282b 100644
> --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> @@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  #include 
>  #endif
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -302,7 +303,15 @@ GetSymName (
>
>assert(Sym->st_name < StrtabShdr->sh_size);
>
> -  return (UINT8*)mEhdr + StrtabShdr->sh_offset + Sym->st_name;
> +  UINT8* StrtabContents = (UINT8*)mEhdr + StrtabShdr->sh_offset;
> +
> +  bool foundEnd = false;
> +  for (UINT32 i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) 
> {
> +foundEnd = StrtabContents[i] == 0;  }  assert(foundEnd);
> +
> +  return StrtabContents + Sym->st_name;
>  }
>
>  //
> @@ -337,7 +346,7 @@ ScanSections64 (
>  mCoffOffset += sizeof (EFI_IMAGE_NT_HEADERS64);
>break;
>default:
> -VerboseMsg ("%s unknown e_machine type. Assume X64", 
> (UINTN)mEhdr->e_machine);
> +VerboseMsg ("%s unknown e_machine type %hu. Assume X64", 
> + mInImageName, mEhdr->e_machine);
>  mCoffOffset += sizeof (EFI_IMAGE_NT_HEADERS64);
>break;
>}
> @@ -721,7 +730,7 @@ WriteSections64 (
>}
>
>Error (NULL, 0, 3000, "Invalid",
> - "%s: Bad definition for symbol '%s'@%p or unsupported 
> symbol type.  "
> + "%s: Bad definition for symbol '%s'@%#llx or unsupported 
> symbol type.  "
>   "For example, absolute and undefined symbols are not 

Re: [edk2] Allocating Aligned Pages

[Andrew Fish]

> On Feb 17, 2016, at 12:28 AM, Bhupesh Sharma  wrote:
> 
>> From: af...@apple.com [mailto:af...@apple.com]
>> Sent: Wednesday, February 17, 2016 1:34 PM
> 
>>> On Feb 16, 2016, at 11:52 PM, Bhupesh Sharma 
>> wrote:
>>> 
>>> Hi Experts,
>>> 
>>> We are using the 'AllocateAlignedPages' function (inside
>>> 'MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c')
>>> to allocate 512MB aligned memory chunk in a DXE driver.
>>> 
>>> However the memory chunk which gets allocated by this API is around
>> 1GB.
>>> 
>>> I understand that this might be  because of the memory fragmentation,
>>> as a result of which allocating the 512MB aligned buffer might result
>> in memory chunk being allocated be greater in size than 512MB.
>>> 
>>> Are we using the right API for the purpose - is there another API
>>> available which allows alignment to specified more granularly?
>>> 
>> 
>> What do you mean by more granularity? Something other than a power of 2?
>> How much memory does your system have? Have you looked at the memory map
>> in the shell to see how fragmented it is?
>> 
> 
> Yes, I mean something that would support allocating a page size of say 64K 
> rather
> than 4K, which is well supported on platforms like ARM and allow lesser 
> memory fragmentation
> (though it has its own demerits).
> 

I thought it did? 64K is a power of 2, so does not the current API work? 

FYI the EFI page size is not the size of the page tables, but just the quanta 
of memory you can allocate that is not byte aligned (like pool). 

Thanks,

Andrew Fish

> We currently have 2GB DDR on the board. It can be stacked up further by 
> adding more DDR DIMMs,
> but currently it is only 2GB.
> 
> So, if the memory allocation hunk consumes 1GB from the available 2GB, it's 
> quite restrictive
> at the moment.
> 
> I haven't checked at the Shell for memory allocation and corresponding 
> fragmentation.
> 
> I will try and do the same and post back the results.
> 
> Regards,
> Bhupesh
> 
>>> Here is the 'AllocateAlignedPages' function which calls
>> 'InternalAllocateAlignedPages' internally.
>>> 
>>> /**
>>> Allocates one or more 4KB pages of type EfiBootServicesData at a
>> specified alignment.
>>> 
>>> Allocates the number of 4KB pages specified by Pages of type
>>> EfiBootServicesData with an  alignment specified by Alignment.  The
>>> allocated buffer is returned.  If Pages is 0, then NULL is  returned.
>>> If there is not enough memory at the specified alignment remaining to
>> satisfy the  request, then NULL is returned.
>>> 
>>> If Alignment is not a power of two and Alignment is not zero, then
>> ASSERT().
>>> If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().
>>> 
>>> @param  Pages The number of 4 KB pages to allocate.
>>> @param  Alignment The requested alignment of the
>> allocation.  Must be a power of two.
>>>   If Alignment is zero, then byte
>> alignment is used.
>>> 
>>> @return A pointer to the allocated buffer or NULL if allocation fails.
>>> 
>>> **/
>>> VOID *
>>> EFIAPI
>>> AllocateAlignedPages (
>>> IN UINTN  Pages,
>>> IN UINTN  Alignment
>>> )
>>> {
>>> return InternalAllocateAlignedPages (EfiBootServicesData, Pages,
>>> Alignment); }
>>> 
>>> ...
>>> 
>>> /**
>>> Allocates one or more 4KB pages of a certain memory type at a
>> specified alignment.
>>> 
>>> Allocates the number of 4KB pages specified by Pages of a certain
>>> memory type with an alignment  specified by Alignment.  The allocated
>> buffer is returned.  If Pages is 0, then NULL is returned.
>>> If there is not enough memory at the specified alignment remaining to
>>> satisfy the request, then  NULL is returned.
>>> If Alignment is not a power of two and Alignment is not zero, then
>> ASSERT().
>>> If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().
>>> 
>>> @param  MemoryTypeThe type of memory to allocate.
>>> @param  Pages The number of 4 KB pages to allocate.
>>> @param  Alignment The requested alignment of the
>> allocation.  Must be a power of two.
>>>   If Alignment is zero, then byte
>> alignment is used.
>>> 
>>> @return A pointer to the allocated buffer or NULL if allocation fails.
>>> 
>>> **/
>>> VOID *
>>> InternalAllocateAlignedPages (
>>> IN EFI_MEMORY_TYPE  MemoryType,
>>> IN UINTNPages,
>>> IN UINTNAlignment
>>> )
>>> 
>>> ...
>>> 
>>> Thanks for the help.
>>> 
>>> Regards,
>>> Bhupesh
>>> ___
>>> 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 3/3] BaseTools/GenFw: Correct datatypes in diagnostic messages and check for string termination

[Ard Biesheuvel]

On 1 February 2016 at 03:10, Liming Gao  wrote:
> From: Michael LeMay 
>
> This patch revises multiple diagnostic messages to use correct
> datatypes.  It also checks that a symbol name that is about to be used
> in a diagnostic message is terminated by a null character within the
> contents of the string table section so that the print routine does
> not read past the end of the string table section contents when
> reading the symbol name.
>
> Signed-off-by: Michael LeMay 

Hello Liming,

This patch is breaking the BaseTools build under GCC:

Elf32Convert.c: In function 'GetSymName':
Elf32Convert.c:317:3: error: 'for' loop initial declarations are only
allowed in C99 or C11 mode
   for (UINT32 i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) {
   ^
Elf32Convert.c:317:3: note: use option -std=c99, -std=gnu99, -std=c11
or -std=gnu11 to compile your code

Regards,
Ard.

> ---
>  BaseTools/Source/C/GenFw/Elf32Convert.c | 15 ---
>  BaseTools/Source/C/GenFw/Elf64Convert.c | 15 ---
>  2 files changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c 
> b/BaseTools/Source/C/GenFw/Elf32Convert.c
> index a842ceb..d4258e5 100644
> --- a/BaseTools/Source/C/GenFw/Elf32Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf32Convert.c
> @@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  #include 
>  #endif
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -310,7 +311,15 @@ GetSymName (
>
>assert(Sym->st_name < StrtabShdr->sh_size);
>
> -  return (UINT8*)mEhdr + StrtabShdr->sh_offset + Sym->st_name;
> +  UINT8* StrtabContents = (UINT8*)mEhdr + StrtabShdr->sh_offset;
> +
> +  bool foundEnd = false;
> +  for (UINT32 i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) 
> {
> +foundEnd = StrtabContents[i] == 0;
> +  }
> +  assert(foundEnd);
> +
> +  return StrtabContents + Sym->st_name;
>  }
>
>  //
> @@ -539,7 +548,7 @@ ScanSections32 (
>  NtHdr->Pe32.OptionalHeader.Magic = EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC;
>  break;
>default:
> -VerboseMsg ("%s unknown e_machine type. Assume IA-32", 
> (UINTN)mEhdr->e_machine);
> +VerboseMsg ("%s unknown e_machine type %hu. Assume IA-32", mInImageName, 
> mEhdr->e_machine);
>  NtHdr->Pe32.FileHeader.Machine = EFI_IMAGE_MACHINE_IA32;
>  NtHdr->Pe32.OptionalHeader.Magic = EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC;
>}
> @@ -725,7 +734,7 @@ WriteSections32 (
>}
>
>Error (NULL, 0, 3000, "Invalid",
> - "%s: Bad definition for symbol '%s'@%p or unsupported 
> symbol type.  "
> + "%s: Bad definition for symbol '%s'@%#x or unsupported 
> symbol type.  "
>   "For example, absolute and undefined symbols are not 
> supported.",
>   mInImageName, SymName, Sym->st_value);
>
> diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
> b/BaseTools/Source/C/GenFw/Elf64Convert.c
> index fad270c..7b7282b 100644
> --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> @@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  #include 
>  #endif
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -302,7 +303,15 @@ GetSymName (
>
>assert(Sym->st_name < StrtabShdr->sh_size);
>
> -  return (UINT8*)mEhdr + StrtabShdr->sh_offset + Sym->st_name;
> +  UINT8* StrtabContents = (UINT8*)mEhdr + StrtabShdr->sh_offset;
> +
> +  bool foundEnd = false;
> +  for (UINT32 i = Sym->st_name; (i < StrtabShdr->sh_size) && !foundEnd; i++) 
> {
> +foundEnd = StrtabContents[i] == 0;
> +  }
> +  assert(foundEnd);
> +
> +  return StrtabContents + Sym->st_name;
>  }
>
>  //
> @@ -337,7 +346,7 @@ ScanSections64 (
>  mCoffOffset += sizeof (EFI_IMAGE_NT_HEADERS64);
>break;
>default:
> -VerboseMsg ("%s unknown e_machine type. Assume X64", 
> (UINTN)mEhdr->e_machine);
> +VerboseMsg ("%s unknown e_machine type %hu. Assume X64", mInImageName, 
> mEhdr->e_machine);
>  mCoffOffset += sizeof (EFI_IMAGE_NT_HEADERS64);
>break;
>}
> @@ -721,7 +730,7 @@ WriteSections64 (
>}
>
>Error (NULL, 0, 3000, "Invalid",
> - "%s: Bad definition for symbol '%s'@%p or unsupported 
> symbol type.  "
> + "%s: Bad definition for symbol '%s'@%#llx or unsupported 
> symbol type.  "
>   "For example, absolute and undefined symbols are not 
> supported.",
>   mInImageName, SymName, Sym->st_value);
>
> --
> 1.9.5.msysgit.0
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org

Re: [edk2] Allocating Aligned Pages

[Bhupesh Sharma]

> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, February 17, 2016 1:34 PM

> > On Feb 16, 2016, at 11:52 PM, Bhupesh Sharma 
> wrote:
> >
> > Hi Experts,
> >
> > We are using the 'AllocateAlignedPages' function (inside
> > 'MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c')
> > to allocate 512MB aligned memory chunk in a DXE driver.
> >
> > However the memory chunk which gets allocated by this API is around
> 1GB.
> >
> > I understand that this might be  because of the memory fragmentation,
> > as a result of which allocating the 512MB aligned buffer might result
> in memory chunk being allocated be greater in size than 512MB.
> >
> > Are we using the right API for the purpose - is there another API
> > available which allows alignment to specified more granularly?
> >
> 
> What do you mean by more granularity? Something other than a power of 2?
> How much memory does your system have? Have you looked at the memory map
> in the shell to see how fragmented it is?
> 

Yes, I mean something that would support allocating a page size of say 64K 
rather
than 4K, which is well supported on platforms like ARM and allow lesser memory 
fragmentation
(though it has its own demerits).

We currently have 2GB DDR on the board. It can be stacked up further by adding 
more DDR DIMMs,
but currently it is only 2GB.

So, if the memory allocation hunk consumes 1GB from the available 2GB, it's 
quite restrictive
at the moment.

I haven't checked at the Shell for memory allocation and corresponding 
fragmentation.

I will try and do the same and post back the results.

Regards,
Bhupesh
 
> > Here is the 'AllocateAlignedPages' function which calls
> 'InternalAllocateAlignedPages' internally.
> >
> > /**
> >  Allocates one or more 4KB pages of type EfiBootServicesData at a
> specified alignment.
> >
> >  Allocates the number of 4KB pages specified by Pages of type
> > EfiBootServicesData with an  alignment specified by Alignment.  The
> > allocated buffer is returned.  If Pages is 0, then NULL is  returned.
> > If there is not enough memory at the specified alignment remaining to
> satisfy the  request, then NULL is returned.
> >
> >  If Alignment is not a power of two and Alignment is not zero, then
> ASSERT().
> >  If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().
> >
> >  @param  Pages The number of 4 KB pages to allocate.
> >  @param  Alignment The requested alignment of the
> allocation.  Must be a power of two.
> >If Alignment is zero, then byte
> alignment is used.
> >
> >  @return A pointer to the allocated buffer or NULL if allocation fails.
> >
> > **/
> > VOID *
> > EFIAPI
> > AllocateAlignedPages (
> >  IN UINTN  Pages,
> >  IN UINTN  Alignment
> >  )
> > {
> >  return InternalAllocateAlignedPages (EfiBootServicesData, Pages,
> > Alignment); }
> >
> > ...
> >
> > /**
> >  Allocates one or more 4KB pages of a certain memory type at a
> specified alignment.
> >
> >  Allocates the number of 4KB pages specified by Pages of a certain
> > memory type with an alignment  specified by Alignment.  The allocated
> buffer is returned.  If Pages is 0, then NULL is returned.
> >  If there is not enough memory at the specified alignment remaining to
> > satisfy the request, then  NULL is returned.
> >  If Alignment is not a power of two and Alignment is not zero, then
> ASSERT().
> >  If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().
> >
> >  @param  MemoryTypeThe type of memory to allocate.
> >  @param  Pages The number of 4 KB pages to allocate.
> >  @param  Alignment The requested alignment of the
> allocation.  Must be a power of two.
> >If Alignment is zero, then byte
> alignment is used.
> >
> >  @return A pointer to the allocated buffer or NULL if allocation fails.
> >
> > **/
> > VOID *
> > InternalAllocateAlignedPages (
> >  IN EFI_MEMORY_TYPE  MemoryType,
> >  IN UINTNPages,
> >  IN UINTNAlignment
> >  )
> >
> > ...
> >
> > Thanks for the help.
> >
> > Regards,
> > Bhupesh
> > ___
> > 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] BaseTools/GenFw: skip relocation entry if there is an error

[Ronny Chevalier]

It is now obsolete with commit 621bb723a4e00cb93e8a94c6126de4976dde1d9e

On Mon, Feb 15, 2016 at 10:25 AM, Gao, Liming  wrote:
> Reviewed-by: Liming Gao 
>
> -Original Message-
> From: Ronny Chevalier [mailto:chevalier.ro...@gmail.com]
> Sent: Friday, February 12, 2016 10:26 PM
> To: edk2-de...@ml01.01.org
> Cc: Zhu, Yonghong; Gao, Liming
> Subject: [PATCH] BaseTools/GenFw: skip relocation entry if there is an error
>
> Otherwise a segfault occurs due to an out-of-bound access
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Cc: Yonghong Zhu 
> Cc: Liming Gao 
> Signed-off-by: Ronny Chevalier 
> ---
>  BaseTools/Source/C/GenFw/Elf32Convert.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c 
> b/BaseTools/Source/C/GenFw/Elf32Convert.c
> index 9bf5855..cdb3246 100644
> --- a/BaseTools/Source/C/GenFw/Elf32Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf32Convert.c
> @@ -670,6 +670,7 @@ WriteSections32 (
>  || Sym->st_shndx == SHN_ABS
>  || Sym->st_shndx > mEhdr->e_shnum) {
>Error (NULL, 0, 3000, "Invalid", "%s bad symbol definition.", 
> mInImageName);
> +  continue;
>  }
>  SymShdr = GetShdrByIndex(Sym->st_shndx);
>
> --
> 2.7.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Allocating Aligned Pages

[Andrew Fish]

> On Feb 16, 2016, at 11:52 PM, Bhupesh Sharma  wrote:
> 
> Hi Experts,
> 
> We are using the 'AllocateAlignedPages' function (inside 
> 'MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c')
> to allocate 512MB aligned memory chunk in a DXE driver.
> 
> However the memory chunk which gets allocated by this API is around 1GB.
> 
> I understand that this might be  because of the memory fragmentation, as a 
> result of which allocating
> the 512MB aligned buffer might result in memory chunk being allocated be 
> greater in size than 512MB.
> 
> Are we using the right API for the purpose - is there another API available 
> which allows alignment to specified
> more granularly? 
> 

What do you mean by more granularity? Something other than a power of 2? How 
much memory does your system have? Have you looked at the memory map in the 
shell to see how fragmented it is?

Thanks,

Andrew Fish

> Here is the 'AllocateAlignedPages' function which calls 
> 'InternalAllocateAlignedPages' internally.
> 
> /**
>  Allocates one or more 4KB pages of type EfiBootServicesData at a specified 
> alignment.
> 
>  Allocates the number of 4KB pages specified by Pages of type 
> EfiBootServicesData with an
>  alignment specified by Alignment.  The allocated buffer is returned.  If 
> Pages is 0, then NULL is
>  returned.  If there is not enough memory at the specified alignment 
> remaining to satisfy the
>  request, then NULL is returned.
> 
>  If Alignment is not a power of two and Alignment is not zero, then ASSERT().
>  If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().
> 
>  @param  Pages The number of 4 KB pages to allocate.
>  @param  Alignment The requested alignment of the allocation.  
> Must be a power of two.
>If Alignment is zero, then byte alignment is 
> used.
> 
>  @return A pointer to the allocated buffer or NULL if allocation fails.
> 
> **/
> VOID *
> EFIAPI
> AllocateAlignedPages (
>  IN UINTN  Pages,
>  IN UINTN  Alignment
>  )
> {
>  return InternalAllocateAlignedPages (EfiBootServicesData, Pages, Alignment);
> }
> 
> ...
> 
> /**
>  Allocates one or more 4KB pages of a certain memory type at a specified 
> alignment.
> 
>  Allocates the number of 4KB pages specified by Pages of a certain memory 
> type with an alignment
>  specified by Alignment.  The allocated buffer is returned.  If Pages is 0, 
> then NULL is returned.
>  If there is not enough memory at the specified alignment remaining to 
> satisfy the request, then
>  NULL is returned.
>  If Alignment is not a power of two and Alignment is not zero, then ASSERT().
>  If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().
> 
>  @param  MemoryTypeThe type of memory to allocate.
>  @param  Pages The number of 4 KB pages to allocate.
>  @param  Alignment The requested alignment of the allocation.  
> Must be a power of two.
>If Alignment is zero, then byte alignment is 
> used.
> 
>  @return A pointer to the allocated buffer or NULL if allocation fails.
> 
> **/
> VOID *
> InternalAllocateAlignedPages (
>  IN EFI_MEMORY_TYPE  MemoryType,  
>  IN UINTNPages,
>  IN UINTNAlignment
>  )
> 
> ...
> 
> Thanks for the help.
> 
> Regards,
> Bhupesh
> ___
> 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