Re: [edk2] [PATCH v3 0/5] OvmfPkg: program MSR_IA32_FEATURE_CONTROL from fw_cfg on all processors

[Laszlo Ersek]

On 07/13/16 16:36, Laszlo Ersek wrote:
> v1: http://thread.gmane.org/gmane.comp.bios.edk2.devel/14214
> v2: http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471
> 
> Changes relative to v2:
> - Patches 2 and 3: pick up Jeff's R-b.
> - Patch 4: resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib
>   for all PEIMs (suggested by Jeff). Drop Jeff's earlier R-b.
> 
> Public branch:
> .
> 
> Cc: Jeff Fan 
> Cc: Jordan Justen 
> Cc: Michael Kinney 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (5):
>   OvmfPkg/PlatformPei: create one memory HOB at S3 resume too, for
> CpuMpPei
>   OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3
>   OvmfPkg: remove PcdS3AcpiReservedMemoryBase,
> PcdS3AcpiReservedMemorySize
>   OvmfPkg: include UefiCpuPkg/CpuMpPei
>   OvmfPkg/PlatformPei: program MSR_IA32_FEATURE_CONTROL from fw_cfg
> 
>  OvmfPkg/OvmfPkg.dec  |   1 -
>  OvmfPkg/OvmfPkgIa32.dsc  |   5 +
>  OvmfPkg/OvmfPkgIa32X64.dsc   |   5 +
>  OvmfPkg/OvmfPkgX64.dsc   |   5 +
>  OvmfPkg/OvmfPkgIa32.fdf  |   4 +-
>  OvmfPkg/OvmfPkgIa32X64.fdf   |   4 +-
>  OvmfPkg/OvmfPkgX64.fdf   |   4 +-
>  OvmfPkg/PlatformPei/PlatformPei.inf  |   5 +-
>  OvmfPkg/PlatformPei/Platform.h   |   5 +
>  OvmfPkg/PlatformPei/FeatureControl.c | 134 
>  OvmfPkg/PlatformPei/MemDetect.c  |  63 +++--
>  OvmfPkg/PlatformPei/Platform.c   |   1 +
>  12 files changed, 211 insertions(+), 25 deletions(-)
>  create mode 100644 OvmfPkg/PlatformPei/FeatureControl.c
> 

Thanks everyone for the (repeated) reviews; I pushed this series (with
the PcdCpuApStackSize update): commit range 51773d49de84..dbab994991c7.

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

Re: [edk2] [PATCH v3 2/5] OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3

[Laszlo Ersek]

On 07/15/16 02:26, Jordan Justen wrote:
> On 2016-07-13 07:36:56, Laszlo Ersek wrote:
>> Move the permanent PEI memory for the S3 resume boot path to the top of
>> the low RAM (just below TSEG if the SMM driver stack is included in the
>> build). The new size is derived from CpuMpPei's approximate memory demand.
>>
>> Save the base address and the size in new global variables, regardless of
>> the boot path. On the normal boot path, use these variables for covering
>> the area with EfiACPIMemoryNVS type memory.
>>
>> PcdS3AcpiReservedMemoryBase and PcdS3AcpiReservedMemorySize become unused
>> in PlatformPei; remove them.
>>
>> Cc: Jeff Fan 
>> Cc: Jordan Justen 
>> Cc: Michael Kinney 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> Reviewed-by: Jeff Fan 
>> ---
>>
>> Notes:
>> v2:
>> - new in v2 [Jordan, Jeff]
>>
>>  OvmfPkg/PlatformPei/PlatformPei.inf |  3 +-
>>  OvmfPkg/PlatformPei/MemDetect.c | 39 ++--
>>  2 files changed, 28 insertions(+), 14 deletions(-)
>>
>> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
>> b/OvmfPkg/PlatformPei/PlatformPei.inf
>> index 3556404017fc..229831b10da0 100644
>> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
>> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
>> @@ -65,7 +65,6 @@ [Pcd]
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
>> -  gUefiOvmfPkgTokenSpaceGuid.PcdS3AcpiReservedMemoryBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
>> @@ -82,7 +81,6 @@ [Pcd]
>>gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
>>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
>> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
>>gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
>>gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
>>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
>> @@ -95,6 +93,7 @@ [Pcd]
>>gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
>>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
>> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
>>  
>>  [FixedPcd]
>>gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
>> diff --git a/OvmfPkg/PlatformPei/MemDetect.c 
>> b/OvmfPkg/PlatformPei/MemDetect.c
>> index d59b461547c5..7129ed26fa3e 100644
>> --- a/OvmfPkg/PlatformPei/MemDetect.c
>> +++ b/OvmfPkg/PlatformPei/MemDetect.c
>> @@ -39,6 +39,9 @@ Module Name:
>>  
>>  UINT8 mPhysMemAddressWidth;
>>  
>> +STATIC UINT32 mS3AcpiReservedMemoryBase;
>> +STATIC UINT32 mS3AcpiReservedMemorySize;
>> +
>>  UINT32
>>  GetSystemMemorySizeBelow4gb (
>>VOID
>> @@ -335,18 +338,30 @@ PublishPeiMemory (
>>UINT64  LowerMemorySize;
>>UINT32  PeiMemoryCap;
>>  
>> +  LowerMemorySize = GetSystemMemorySizeBelow4gb ();
>> +  if (FeaturePcdGet (PcdSmmSmramRequire)) {
>> +//
>> +// TSEG is chipped from the end of low RAM
>> +//
>> +LowerMemorySize -= FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;
>> +  }
>> +
>> +  //
>> +  // If S3 is supported, then the S3 permanent PEI memory is placed next,
>> +  // downwards. Its size is primarily dictated by CpuMpPei. The formula 
>> below
>> +  // is an approximation.
>> +  //
>> +  if (mS3Supported) {
>> +mS3AcpiReservedMemorySize = SIZE_512KB +
>> +  PcdGet32 (PcdCpuMaxLogicalProcessorNumber) * SIZE_32KB;
> 
> Maybe use PcdCpuApStackSize rather than SIZE_32KB?

Good idea, I will update the patch on commit.

> Is there an chance that with OVMF's modest usage of PEI MP, perhaps we
> could get by with a smaller stack size per processor? 4 or 8 KB? This
> would reduce 8MB down to 1 or 2MB.
> 
> Maybe we could use a separate PcdPeiCpuApStackSize for PEI? What do
> think Jeff/Mike?

That also sounds reasonable to me. I've heard from Mike and Jeff that
they plan to extract and unify the internals of CpuMpPei and CpuDxe.
Perhaps it's best to delay the introduction of a separate PCD for the
PEI-phase AP stack size until that refactoring happens. (IOW, make the
new PCD part of that series.)

Just speculating, of course.

> I think OVMF is more sensitive to the size, since we try to support
> 255 processors.

Max number of processors is a hornet's nest. I filed
 earlier. I didn't provide
much background info on it, but it's related to:

  [PATCH v2 0/4] support booting more than 255 CPUs with QEMU
  http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10654

I'm not even thinking of *thinking* of that feature. :/ For now let's

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Ard Biesheuvel]

On 15 July 2016 at 03:28, Gao, Liming  wrote:
> I see Steven patch uses -Os after enables new MS VA intrinsics. So, -Os 
> should work. But, I am not sure whether -Os is better than -O2 for edk2.
>

-Os did not work for me with GCC49 or earlier. It complains about a
missing -maccumulate-outgoing-args, but adding that option results in
a broken binary.

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Friday, July 15, 2016 6:20 AM
>> To: Bruce Cran ; Ard Biesheuvel
>> ; Shi, Steven ; Zhu,
>> Yonghong ; Gao, Liming ;
>> Kinney, Michael D ; Justen, Jordan L
>> ; af...@apple.com; edk2-de...@ml01.01.org
>> Subject: Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64
>>
>> On 07/14/16 23:57, Bruce Cran wrote:
>> > On 7/14/2016 7:16 AM, Ard Biesheuvel wrote:
>> >
>> >> Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to
>> >> GCC44.
>> >
>> > I wonder if -Os might be a better default optimization? Or perhaps
>> > there's plenty of flash on devices nowadays and performance is more
>> > important than size?
>> >
>> > At least for our driver, I see a 33% size reduction with -O2 and 44%
>> > with -Os for the driver .efi file. Perhaps more importantly, the .rom
>> > file (i.e. efirom output) has no reduction with -O2 and a 14% reduction
>> > with -Os.
>> >
>>
>> Beware of -Os with GCC48:
>>
>> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10963
>>
>> 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 2/3] IntelFsp2WrapperPkg: Add missing modules in Package DSC

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru    

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, July 14, 2016 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Mudusuru, Giri P
> 
> Subject: [Patch 2/3] IntelFsp2WrapperPkg: Add missing modules in Package
> DSC
> 
> Package DSC is used to verify the module source build.
> 
> Cc: Jiewen Yao 
> Cc: Giri Mudusuru 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc
> b/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc
> index 70541c8..8292030 100644
> --- a/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc
> +++ b/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc
> @@ -75,10 +75,17 @@
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> 
>  [Components.Ia32]
> +
> IntelFsp2WrapperPkg/Library/BaseFspWrapperApiTestLibNull/BaseFspWrap
> perApiTestLibNull.inf
> +
> IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFsp
> WrapperPlatformSecLibSample.inf
> +
> IntelFsp2WrapperPkg/Library/PeiFspWrapperHobProcessLibSample/PeiFsp
> WrapperHobProcessLibSample.inf
> +
> IntelFsp2WrapperPkg/Library/PeiFspWrapperApiTestLib/PeiFspWrapperApiT
> estLib.inf
> +
>IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
>IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
> 
>  [Components.IA32, Components.X64]
> +
> IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/BaseFspWrapperApiLi
> b.inf
> +
> IntelFsp2WrapperPkg/Library/BaseFspWrapperPlatformLibSample/BaseFsp
> WrapperPlatformLibSample.inf
>IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
> 
>  [PcdsFixedAtBuild.common]
> --
> 2.8.0.windows.1

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

Re: [edk2] [Patch 3/3] IntelFsp2Pkg: Add missing modules in Package DSC

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru   

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, July 14, 2016 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Mudusuru, Giri P
> 
> Subject: [Patch 3/3] IntelFsp2Pkg: Add missing modules in Package DSC
> 
> Package DSC is used to verify the module source build.
> 
> Cc: Jiewen Yao 
> Cc: Giri Mudusuru 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  IntelFsp2Pkg/IntelFsp2Pkg.dsc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/IntelFsp2Pkg/IntelFsp2Pkg.dsc b/IntelFsp2Pkg/IntelFsp2Pkg.dsc
> index 3b50bbf..61eb6f1 100644
> --- a/IntelFsp2Pkg/IntelFsp2Pkg.dsc
> +++ b/IntelFsp2Pkg/IntelFsp2Pkg.dsc
> @@ -65,6 +65,8 @@
> 
> IntelFsp2Pkg/Library/BaseFspDebugLibSerialPort/BaseFspDebugLibSerialPort
> .inf
>IntelFsp2Pkg/Library/BaseFspPlatformLib/BaseFspPlatformLib.inf
>IntelFsp2Pkg/Library/BaseFspSwitchStackLib/BaseFspSwitchStackLib.inf
> +
> IntelFsp2Pkg/Library/BaseDebugDeviceLibNull/BaseDebugDeviceLibNull.inf
> +
> IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/SecFspSecPlatformLibNull.in
> f
> 
>IntelFsp2Pkg/FspSecCore/FspSecCoreT.inf
>IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf
> --
> 2.8.0.windows.1

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

Re: [edk2] [Patch 1/3] IntelFsp2WrapperPkg SecFspWrapperPlatformSecLibSample:Update code to pass build

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, July 14, 2016 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Mudusuru, Giri P
> 
> Subject: [Patch 1/3] IntelFsp2WrapperPkg
> SecFspWrapperPlatformSecLibSample:Update code to pass build
> 
> 1. Update its library class to PlatformSecLib
> 2. Update source code to refer to the matched header file
> 
> Cc: Jiewen Yao 
> Cc: Giri Mudusuru 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  .../FspWrapperPlatformSecLibSample.c|  2 ++
>  .../SecFspWrapperPlatformSecLibSample.inf   |  4 +++-
>  .../SecFspWrapperPlatformSecLibSample/SecTempRamDone.c  | 13
> +
>  3 files changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git
> a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/FspW
> rapperPlatformSecLibSample.c
> b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/Fsp
> WrapperPlatformSecLibSample.c
> index 19379c2..697381e 100644
> ---
> a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/FspW
> rapperPlatformSecLibSample.c
> +++
> b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/Fsp
> WrapperPlatformSecLibSample.c
> @@ -18,6 +18,8 @@
>  #include 
> 
>  #include 
> +#include 
> +#include 
> 
>  /**
>This interface conveys state information out of the Security (SEC) phase
> into PEI.
> diff --git
> a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFs
> pWrapperPlatformSecLibSample.inf
> b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecF
> spWrapperPlatformSecLibSample.inf
> index bcb76b8..dfa5c15 100644
> ---
> a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFs
> pWrapperPlatformSecLibSample.inf
> +++
> b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecF
> spWrapperPlatformSecLibSample.inf
> @@ -23,7 +23,7 @@
>FILE_GUID  = 8F1AC44A-CE7E-4E29-95BB-92E321BB1573
>MODULE_TYPE= SEC
>VERSION_STRING = 1.0
> -  LIBRARY_CLASS  = FspWrapperPlatformSecLib
> +  LIBRARY_CLASS  = PlatformSecLib
> 
>  #
>  # The following information is for reference only and not required by the
> build tools.
> @@ -68,6 +68,8 @@
>  [LibraryClasses]
>LocalApicLib
>SerialPortLib
> +  DebugLib
> +  BaseMemoryLib
> 
>  [Ppis]
>gEfiSecPlatformInformationPpiGuid   ## CONSUMES
> diff --git
> a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecT
> empRamDone.c
> b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecT
> empRamDone.c
> index 76d2f42..b7a6227 100644
> ---
> a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecT
> empRamDone.c
> +++
> b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecT
> empRamDone.c
> @@ -14,14 +14,11 @@
> 
>  #include 
> 
> -#include 
> -
> -#include 
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 
> +#include 
> +#include 
> +#include 
> 
>  /**
>  This interface disables temporary memory in SEC Phase.
> @@ -43,8 +40,8 @@ SecPlatformDisableTemporaryMemory (
> 
>DEBUG((DEBUG_INFO, "SecPlatformDisableTemporaryMemory enter\n"));
> 
> -  TempRamExitParam = GetTempRamExitParam ();
> -  Status = CallTempRamExit (FspHeader, TempRamExitParam);
> +  TempRamExitParam = UpdateTempRamExitParam ();
> +  Status = CallTempRamExit (TempRamExitParam);
>DEBUG((DEBUG_INFO, "TempRamExit status: 0x%x\n", Status));
>ASSERT_EFI_ERROR(Status);
> 
> --
> 2.8.0.windows.1

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

Re: [edk2] [PATCH v3 4/5] OvmfPkg: include UefiCpuPkg/CpuMpPei

[Laszlo Ersek]

On 07/15/16 02:12, Jordan Justen wrote:
> On 2016-07-13 07:36:58, Laszlo Ersek wrote:
>> In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use.
>>
>> CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond
>> those already used by CpuDxe:
>>
>> - PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these
>>   control whether CpuMpPei performs microcode update. If the region size
>>   is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the
>>   region size to zero by default, which is appropriate for OVMF.
>>
>> - PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how
>>   CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait
>>   (with PAUSE). The latter PCD is only relevant if the former PCD is 2
>>   (MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself,
>>   we choose HLT. That's the default set by UefiCpuPkg.dec.
>>
>> Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib
>> technically, it is supposed to consume PeiCpuExceptionHandlerLib. See:
>>
>> - http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703
>>
>> - git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import
>>   PeiCpuExceptionHandlerLib module"), part of the series linked above.
>>
>> Jeff recommended to resolve CpuExceptionHandlerLib to
>> PeiCpuExceptionHandlerLib for all PEIMs:
>>
>> - http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477
>>
>> Since at the moment we have no resolution in place that would cover this
>> for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]),
>> it's easy to do.
>>
>> Cc: Jeff Fan 
>> Cc: Jordan Justen 
>> Cc: Michael Kinney 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>> v3:
>> - resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib for all
>>   PEIMs [Jeff]
>> - drop Jeff's R-b from earlier
>>
>>  OvmfPkg/OvmfPkgIa32.dsc| 5 +
>>  OvmfPkg/OvmfPkgIa32X64.dsc | 5 +
>>  OvmfPkg/OvmfPkgX64.dsc | 5 +
>>  OvmfPkg/OvmfPkgIa32.fdf| 1 +
>>  OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
>>  OvmfPkg/OvmfPkgX64.fdf | 1 +
>>  6 files changed, 18 insertions(+)
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>> index 805650059e96..8af326778205 100644
>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>> @@ -212,6 +212,7 @@ [LibraryClasses.common.PEIM]
>>  !ifdef $(SOURCE_DEBUG_ENABLE)
>>
>> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
>>  !endif
>> +  
>> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
>>  
>>  [LibraryClasses.common.DXE_CORE]
>>HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
>> @@ -519,6 +520,10 @@ [Components]
>>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>>}
>>  !endif
>> +  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
>> +
>> +  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>> +  }
> 
> It looks like we have this (PcdLib) overridden in nearly every PEIM. I
> think we should update the default library mapping.

Before posting this version of the series, I actually started writing
that patch, but I abandoned it. I no longer remember why. I think the
patch didn't save as much room in the DSC file as I hoped it would.

I will post a follow-up patch so we can investigate this separately.

> With, or without that change:
> Reviewed-by: Jordan Justen 

Thanks!
Laszlo

>>  
>>#
>># DXE Phase modules
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>> index 7615ee96dff2..4bb38d0f7b3c 100644
>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>> @@ -217,6 +217,7 @@ [LibraryClasses.common.PEIM]
>>  !ifdef $(SOURCE_DEBUG_ENABLE)
>>
>> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
>>  !endif
>> +  
>> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
>>  
>>  [LibraryClasses.common.DXE_CORE]
>>HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
>> @@ -527,6 +528,10 @@ [Components.IA32]
>>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>>}
>>  !endif
>> +  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
>> +
>> +  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>> +  }
>>  
>>  [Components.X64]
>>#
>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>> index 7f8a5c25a5c0..be3aa1fc6c43 100644
>> --- a/OvmfPkg/OvmfPkgX64.dsc
>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>> @@ -217,6 +217,7 @@ [LibraryClasses.common.PEIM]
>>  !ifdef $(SOURCE_DEBUG_ENABLE)
>>
>> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
>>  !endif
>> +  
>> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
>>  
>> 

[edk2] [Patch 3/3] IntelFsp2Pkg: Add missing modules in Package DSC

[Liming Gao]

Package DSC is used to verify the module source build.

Cc: Jiewen Yao 
Cc: Giri Mudusuru 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 IntelFsp2Pkg/IntelFsp2Pkg.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/IntelFsp2Pkg/IntelFsp2Pkg.dsc b/IntelFsp2Pkg/IntelFsp2Pkg.dsc
index 3b50bbf..61eb6f1 100644
--- a/IntelFsp2Pkg/IntelFsp2Pkg.dsc
+++ b/IntelFsp2Pkg/IntelFsp2Pkg.dsc
@@ -65,6 +65,8 @@
   IntelFsp2Pkg/Library/BaseFspDebugLibSerialPort/BaseFspDebugLibSerialPort.inf
   IntelFsp2Pkg/Library/BaseFspPlatformLib/BaseFspPlatformLib.inf
   IntelFsp2Pkg/Library/BaseFspSwitchStackLib/BaseFspSwitchStackLib.inf
+  IntelFsp2Pkg/Library/BaseDebugDeviceLibNull/BaseDebugDeviceLibNull.inf
+  IntelFsp2Pkg/Library/SecFspSecPlatformLibNull/SecFspSecPlatformLibNull.inf
 
   IntelFsp2Pkg/FspSecCore/FspSecCoreT.inf
   IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf
-- 
2.8.0.windows.1

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

[edk2] [Patch 2/3] IntelFsp2WrapperPkg: Add missing modules in Package DSC

[Liming Gao]

Package DSC is used to verify the module source build.

Cc: Jiewen Yao 
Cc: Giri Mudusuru 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc 
b/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc
index 70541c8..8292030 100644
--- a/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc
+++ b/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc
@@ -75,10 +75,17 @@
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
 
 [Components.Ia32]
+  
IntelFsp2WrapperPkg/Library/BaseFspWrapperApiTestLibNull/BaseFspWrapperApiTestLibNull.inf
+  
IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
+  
IntelFsp2WrapperPkg/Library/PeiFspWrapperHobProcessLibSample/PeiFspWrapperHobProcessLibSample.inf
+  
IntelFsp2WrapperPkg/Library/PeiFspWrapperApiTestLib/PeiFspWrapperApiTestLib.inf
+
   IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
   IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
 
 [Components.IA32, Components.X64]
+  IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/BaseFspWrapperApiLib.inf
+  
IntelFsp2WrapperPkg/Library/BaseFspWrapperPlatformLibSample/BaseFspWrapperPlatformLibSample.inf
   IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
 
 [PcdsFixedAtBuild.common]
-- 
2.8.0.windows.1

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

[edk2] [Patch 0/3] IntelFsp2Pkg IntelFsp2WrapperPkg: Add the missing modules in DSC

[Liming Gao]

Package DSC is used to verify the module source build.

Liming Gao (3):
  IntelFsp2WrapperPkg SecFspWrapperPlatformSecLibSample:Update code to
pass build
  IntelFsp2WrapperPkg: Add missing modules in Package DSC
  IntelFsp2Pkg: Add missing modules in Package DSC

 IntelFsp2Pkg/IntelFsp2Pkg.dsc   |  2 ++
 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc |  7 +++
 .../FspWrapperPlatformSecLibSample.c|  2 ++
 .../SecFspWrapperPlatformSecLibSample.inf   |  4 +++-
 .../SecFspWrapperPlatformSecLibSample/SecTempRamDone.c  | 13 +
 5 files changed, 19 insertions(+), 9 deletions(-)

-- 
2.8.0.windows.1

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

[edk2] (no subject)

[Liming Gao]

Package DSC is used to verify the module source build.

Liming Gao (3):
  IntelFsp2WrapperPkg SecFspWrapperPlatformSecLibSample:Update code to
pass build
  IntelFsp2WrapperPkg: Add missing modules in Package DSC
  IntelFsp2Pkg: Add missing modules in Package DSC

 IntelFsp2Pkg/IntelFsp2Pkg.dsc   |  2 ++
 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc |  7 +++
 .../FspWrapperPlatformSecLibSample.c|  2 ++
 .../SecFspWrapperPlatformSecLibSample.inf   |  4 +++-
 .../SecFspWrapperPlatformSecLibSample/SecTempRamDone.c  | 13 +
 5 files changed, 19 insertions(+), 9 deletions(-)

-- 
2.8.0.windows.1

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

[edk2] [Patch 1/3] IntelFsp2WrapperPkg SecFspWrapperPlatformSecLibSample:Update code to pass build

[Liming Gao]

1. Update its library class to PlatformSecLib
2. Update source code to refer to the matched header file

Cc: Jiewen Yao 
Cc: Giri Mudusuru 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 .../FspWrapperPlatformSecLibSample.c|  2 ++
 .../SecFspWrapperPlatformSecLibSample.inf   |  4 +++-
 .../SecFspWrapperPlatformSecLibSample/SecTempRamDone.c  | 13 +
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git 
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/FspWrapperPlatformSecLibSample.c
 
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/FspWrapperPlatformSecLibSample.c
index 19379c2..697381e 100644
--- 
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/FspWrapperPlatformSecLibSample.c
+++ 
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/FspWrapperPlatformSecLibSample.c
@@ -18,6 +18,8 @@
 #include 
 
 #include 
+#include 
+#include 
 
 /**
   This interface conveys state information out of the Security (SEC) phase 
into PEI.
diff --git 
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
 
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
index bcb76b8..dfa5c15 100644
--- 
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
+++ 
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
@@ -23,7 +23,7 @@
   FILE_GUID  = 8F1AC44A-CE7E-4E29-95BB-92E321BB1573
   MODULE_TYPE= SEC
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = FspWrapperPlatformSecLib
+  LIBRARY_CLASS  = PlatformSecLib
 
 #
 # The following information is for reference only and not required by the 
build tools.
@@ -68,6 +68,8 @@
 [LibraryClasses]
   LocalApicLib
   SerialPortLib
+  DebugLib
+  BaseMemoryLib
 
 [Ppis]
   gEfiSecPlatformInformationPpiGuid   ## CONSUMES
diff --git 
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecTempRamDone.c
 
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecTempRamDone.c
index 76d2f42..b7a6227 100644
--- 
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecTempRamDone.c
+++ 
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecTempRamDone.c
@@ -14,14 +14,11 @@
 
 #include 
 
-#include 
-
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 
 /**
 This interface disables temporary memory in SEC Phase.
@@ -43,8 +40,8 @@ SecPlatformDisableTemporaryMemory (
 
   DEBUG((DEBUG_INFO, "SecPlatformDisableTemporaryMemory enter\n"));
 
-  TempRamExitParam = GetTempRamExitParam ();
-  Status = CallTempRamExit (FspHeader, TempRamExitParam);
+  TempRamExitParam = UpdateTempRamExitParam ();
+  Status = CallTempRamExit (TempRamExitParam);
   DEBUG((DEBUG_INFO, "TempRamExit status: 0x%x\n", Status));
   ASSERT_EFI_ERROR(Status);
 
-- 
2.8.0.windows.1

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

Re: [edk2] SATA AHCI issue

[Tian, Feng]

Hi, Mike

Thanks for providing such info.

I double checked WDK7600.16385.1 msahci driver. In P_Running_WaitOnFRE(), there 
is a statement: " Wait for confirmation is a 'nice to have' but isn't 
necessary. "

And in the code, it waits for 50ms for FR bit if it's not set to 1.

So the most safe way to follow windows & linux implementation is to add a 50ms 
delay whatever FR is set or not. But no spec speaks this 50ms delay.
 
I would prefer to leave it as is and we can fix it after we get real h/w issue 
report.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Mike 
Maslenkin
Sent: Friday, July 15, 2016 5:59 AM
To: Tian, Feng 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] SATA AHCI issue

BTW Windows waits for FR bit set for 50ms as opposed to Linux.

See P_Running_WaitOnFRE function of storahci from WDK.

So you can break Intel HBAs for example.
Could you ask iastor team about this issue?

Regards.

On Thu, 2016-07-14 at 06:25 +, Tian, Feng wrote:
> Hi, Shaveta
> 
> We have approved this fix. Do you miss it? 
> http://article.gmane.org/gmane.comp.bios.edk2.devel/13541
> 
> Thanks
> Feng
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Shaveta Leekha
> Sent: Thursday, July 14, 2016 2:04 PM
> To: edk2-devel@lists.01.org; Linaro UEFI Mailman List 
> ; Jan Dąbroś ; Ard 
> Biesheuvel 
> Cc: Ruchika Gupta 
> Subject: [edk2] SATA AHCI issue
> 
> Hi,
> 
> 
> 
> I have been working on support for AHCI controller for my ARMv8 platform.
> 
> For that I have integrated my PciEmulation code and SataControllerDxe driver 
> code with MdeModulePkg/Bus/Ata.
> 
> 
> 
> But facing one issue, this is same issue reported by Jan Dabros(in To list) 
> sometime back.
> 
> Setting PxCMD.FRE bit of command register doesn't cause PxCMD.FR to be set to 
> '1' even after "500msec" timeout.
> 
> 
> 
> (As per AHCI spec 1.3 : When PxCMD.FRE is set, it causes PxCMD.FR to be set 
> to '1' )
> 
> Is it correct to just comment out following code part from 
> "MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c" file, 
> "AhciModeInitialization" function:
> 
> 
> 
> As Initialization timeouts is occurring in below part of code:
> 
> 
> 
>   //
> 
>   // Enable FIS Receive DMA engine for the first D2H FIS.
> 
>   //
> 
>   Offset = EFI_AHCI_PORT_START + Port * EFI_AHCI_PORT_REG_WIDTH + 
> EFI_AHCI_PORT_CMD;
> 
>   AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE);
> 
>   Status = AhciWaitMmioSet (
> 
>  PciIo,
> 
>  Offset,
> 
>  EFI_AHCI_PORT_CMD_FR,
> 
>  EFI_AHCI_PORT_CMD_FR,
> 
>  EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT
> 
>  );
> 
>   if (EFI_ERROR (Status)) {
> 
> continue;
> 
>   }
> 
> 
> 
> And if above code is commented out, then SATA stack works completely fine.
> 
> 
> 
> What can be the problem?
> 
> 
> 
> Thank you in advance for your time!
> 
> 
> 
> Best regards,
> 
> Shaveta
> 
> ___
> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Fix a bug for FixedPcd value generation in AutoGen file

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Zhu, Yonghong
> Sent: Friday, July 15, 2016 10:22 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [Patch] BaseTools: Fix a bug for FixedPcd value generation in
> AutoGen file
> 
> If the library is listed in [Components] section for build only, its
> used FixedPcd Value is not generated into AutoGen code. This patch
> cover this case to generate the FixedPcd Value in AutoGen file.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/AutoGen/GenC.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/GenC.py
> b/BaseTools/Source/Python/AutoGen/GenC.py
> index d25d371..29951e3 100644
> --- a/BaseTools/Source/Python/AutoGen/GenC.py
> +++ b/BaseTools/Source/Python/AutoGen/GenC.py
> @@ -1222,11 +1222,11 @@ def CreateLibraryPcdCode(Info, AutoGenC,
> AutoGenH, Pcd):
>  DatumType = ['UINT8', 'UINT16'][Pcd.DefaultValue[0] == 'L']
>  AutoGenH.Append('extern const %s
> _gPcd_FixedAtBuild_%s%s;\n' %(DatumType, TokenCName, Array))
> 
> AutoGenH.Append('#define %s  %s_gPcd_FixedAtBuild_%s\n' %(GetModeN
> ame, Type, TokenCName))
>  AutoGenH.Append('//#define %s  ASSERT(FALSE)  // It is not allowed to
> set value for a FIXED_AT_BUILD PCD\n' % SetModeName)
> 
> -if PcdItemType == TAB_PCDS_FIXED_AT_BUILD and key in
> Info.ConstPcd:
> +if PcdItemType == TAB_PCDS_FIXED_AT_BUILD and (key in
> Info.ConstPcd or (Info.IsLibrary and not Info._ReferenceModules)):
>  AutoGenH.Append('#define _PCD_VALUE_%s %s\n' %(TokenCName,
> Pcd.DefaultValue))
> 
>  if PcdItemType == TAB_PCDS_FIXED_AT_BUILD:
>  PcdDataSize = GetPcdSize(Pcd)
>  AutoGenH.Append('#define %s %s\n' % (FixPcdSizeTokenName,
> PcdDataSize))
> --
> 2.6.1.windows.1

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

[edk2] [PATCH v2 07/27] ShellPkg/UefiShellBcfgCommandLib: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiShellBcfgCommandLib.c  | 49 +++---
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index bf35a35b..9baeecc 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -2,7 +2,7 @@
   Main file for BCFG command.
 
   (C) Copyright 2014-2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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
@@ -553,33 +553,34 @@ BcfgAdd(
 if (EFI_ERROR(Status)) {
   ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_BCFG_SET_VAR_FAIL), 
gShellBcfgHiiHandle, L"bcfg", OptionStr);  
 } else {
-  NewOrder = AllocateZeroPool((OrderCount+1)*sizeof(NewOrder[0]));
-  ASSERT(NewOrder != NULL);
-  CopyMem(NewOrder, CurrentOrder, (OrderCount)*sizeof(NewOrder[0]));
+  NewOrder = AllocateZeroPool ((OrderCount + 1) * sizeof (NewOrder[0]));
+  if (NewOrder != NULL) {
+CopyMem (NewOrder, CurrentOrder, (OrderCount) * sizeof (NewOrder[0]));
 
-  //
-  // Insert target into order list
-  //
-  for (Index=OrderCount; Index > Position; Index--) {
-NewOrder[Index] = NewOrder[Index-1];
-  }
+//
+// Insert target into order list
+//
+for (Index = OrderCount; Index > Position; Index--) {
+  NewOrder[Index] = NewOrder[Index - 1];
+}
 
-  NewOrder[Position] = (UINT16) TargetLocation;
-  Status = gRT->SetVariable (
-Target == BcfgTargetBootOrder?L"BootOrder":L"DriverOrder",
-,
-
EFI_VARIABLE_NON_VOLATILE|EFI_VARIABLE_BOOTSERVICE_ACCESS|EFI_VARIABLE_RUNTIME_ACCESS,
-(OrderCount+1) * sizeof(UINT16),
-NewOrder
-   );
+NewOrder[Position] = (UINT16) TargetLocation;
+Status = gRT->SetVariable (
+  Target == BcfgTargetBootOrder ? L"BootOrder" : L"DriverOrder",
+  ,
+  EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS,
+  (OrderCount + 1) * sizeof (UINT16),
+  NewOrder
+);
 
-  FreePool(NewOrder);
+FreePool (NewOrder);
 
-  if (EFI_ERROR(Status)) {
-ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_BCFG_WRITE_FAIL), 
gShellBcfgHiiHandle, L"bcfg", Target == 
BcfgTargetBootOrder?L"BootOrder":L"DriverOrder");  
-ShellStatus = SHELL_INVALID_PARAMETER;
-  } else {
-Print (L"bcfg: Add %s as %x\n", OptionStr, Position);
+if (EFI_ERROR (Status)) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_BCFG_WRITE_FAIL), 
gShellBcfgHiiHandle, L"bcfg", Target == BcfgTargetBootOrder ? L"BootOrder" : 
L"DriverOrder");
+  ShellStatus = SHELL_INVALID_PARAMETER;
+} else {
+  Print (L"bcfg: Add %s as %x\n", OptionStr, Position);
+}
   }
 }
   }
-- 
2.9.0.windows.1

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

[edk2] [PATCH v2 08/27] ShellPkg/ConsistMapping.c: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../Library/UefiShellCommandLib/ConsistMapping.c   | 499 +
 1 file changed, 320 insertions(+), 179 deletions(-)

diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c 
b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
index 41754dd..d157ebb 100644
--- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
+++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
@@ -1,7 +1,7 @@
 /** @file
   Main file for support of shell consist mapping.
 
-  Copyright (c) 2005 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2005 - 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
@@ -53,10 +53,12 @@ typedef struct {
   @param  MapInfo  The map info.
   @param  OrigDevPath  The original device path protocol.
 
+  @retval EFI_OUT_OF_RESOURCESOut of resources.
+  @retval EFI_SUCCESS The appending was successful.
 **/
 typedef 
-VOID 
-(EFIAPI *SERIAL_DECODE_FUNCTION) (
+EFI_STATUS 
+(*SERIAL_DECODE_FUNCTION) (
   EFI_DEVICE_PATH_PROTOCOL*DevPath, 
   DEVICE_CONSIST_MAPPING_INFO *MapInfo,
   EFI_DEVICE_PATH_PROTOCOL*OrigDevPath
@@ -78,13 +80,11 @@ typedef struct {
   @param  Fmt  The format string
   @param  ...  The data will be printed.
 
-  @return Allocated buffer with the formatted string printed in it.
-  The caller must free the allocated buffer.
-  The buffer allocation is not packed.
+  @retval EFI_SUCCESS  The string is concatenated successfully.
+  @retval EFI_OUT_OF_RESOURCES Out of resources.
 
 **/
-CHAR16 *
-EFIAPI
+EFI_STATUS
 CatPrint (
   IN OUT POOL_PRINT   *Str,
   IN CHAR16   *Fmt,
@@ -94,37 +94,40 @@ CatPrint (
   UINT16  *AppendStr;
   VA_LIST Args;
   UINTN   StringSize;
+  CHAR16  *NewStr;
 
   AppendStr = AllocateZeroPool (0x1000);
   if (AppendStr == NULL) {
-ASSERT(FALSE);
-return Str->Str;
+return EFI_OUT_OF_RESOURCES;
   }
 
   VA_START (Args, Fmt);
   UnicodeVSPrint (AppendStr, 0x1000, Fmt, Args);
   VA_END (Args);
   if (NULL == Str->Str) {
-StringSize   = StrSize (AppendStr);
-Str->Str  = AllocateZeroPool (StringSize);
-ASSERT (Str->Str != NULL);
+StringSize = StrSize (AppendStr);
+NewStr = AllocateZeroPool (StringSize);
   } else {
 StringSize = StrSize (AppendStr);
 StringSize += (StrSize (Str->Str) - sizeof (UINT16));
 
-Str->Str = ReallocatePool (
-StrSize (Str->Str),
-StringSize,
-Str->Str
+NewStr = ReallocatePool (
+   StrSize (Str->Str),
+   StringSize,
+   Str->Str
);
-ASSERT (Str->Str != NULL);
+  }
+  if (NewStr == NULL) {
+FreePool (AppendStr);
+return EFI_OUT_OF_RESOURCES;
   }
 
+  Str->Str = NewStr;
   StrCatS (Str->Str, StringSize/sizeof(CHAR16), AppendStr);
   Str->Len = StringSize;
 
   FreePool (AppendStr);
-  return Str->Str;
+  return EFI_SUCCESS;
 }
 
 MTD_NAME  mMTDName[] = {
@@ -156,30 +159,30 @@ MTD_NAME  mMTDName[] = {
   @param[in, out] Str  The string so append onto.
   @param[in]  Num  The number to divide and append.
 
-  @retval EFI_INVALID_PARAMETER   A parameter was NULL.
+  @retval EFI_OUT_OF_RESOURCESOut of resources.
   @retval EFI_SUCCESS The appending was successful.
 **/
 EFI_STATUS
-EFIAPI
 AppendCSDNum2 (
   IN OUT POOL_PRINT   *Str,
   IN UINT64   Num
   )
 {
-  UINT64  Result;
-  UINT32   Rem;
+  EFI_STATUS Status;
+  UINT64 Result;
+  UINT32 Rem;
 
-  if (Str == NULL) {
-return (EFI_INVALID_PARAMETER);
-  }
+  ASSERT (Str != NULL);
 
   Result = DivU64x32Remainder (Num, 25, );
   if (Result > 0) {
-AppendCSDNum2 (Str, Result);
+Status = AppendCSDNum2 (Str, Result);
+if (EFI_ERROR (Status)) {
+  return Status;
+}
   }
 
-  CatPrint (Str, L"%c", Rem + 'a');
-  return (EFI_SUCCESS);
+  return CatPrint (Str, L"%c", Rem + 'a');
 }
 
 /**
@@ -188,29 +191,30 @@ AppendCSDNum2 (
   @param[in, out] MappingItem  The mapping info object to append onto.
   @param[in]  Num  The info to append.
 
-  @retval EFI_INVALID_PARAMETER   A parameter was NULL.
+  @retval EFI_OUT_OF_RESOURCESOut of resources.
   @retval EFI_SUCCESS The appending was successful.
+
 **/
 EFI_STATUS
-EFIAPI
 AppendCSDNum (
   IN OUT DEVICE_CONSIST_MAPPING_INFO*MappingItem,
   IN UINT64 Num
   )
 {
-  if (MappingItem == NULL) {
-return EFI_INVALID_PARAMETER;
-  }
+  EFI_STATUS Status;
+  ASSERT (MappingItem != NULL);
 
   if (MappingItem->Digital) {
-CatPrint (>Csd, L"%ld", Num);
+   

[edk2] [PATCH v2 09/27] ShellPkg/UefiShellCommandLib.c: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiShellCommandLib/UefiShellCommandLib.c  | 36 +-
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c 
b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
index 48e4d4a..35e0611 100644
--- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
+++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to shell internal functions for shell commands.
 
-  Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
   (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 
@@ -546,9 +546,14 @@ ShellCommandRegisterCommandName (
   // allocate memory for new struct
   //
   Node = AllocateZeroPool(sizeof(SHELL_COMMAND_INTERNAL_LIST_ENTRY));
-  ASSERT(Node != NULL);
+  if (Node == NULL) {
+return RETURN_OUT_OF_RESOURCES;
+  }
   Node->CommandString = AllocateCopyPool(StrSize(CommandString), 
CommandString);
-  ASSERT(Node->CommandString != NULL);
+  if (Node->CommandString == NULL) {
+FreePool (Node);
+return RETURN_OUT_OF_RESOURCES;
+  }
 
   Node->GetManFileName  = GetManFileName;
   Node->CommandHandler  = CommandHandler;
@@ -807,11 +812,20 @@ ShellCommandRegisterAlias (
   // allocate memory for new struct
   //
   Node = AllocateZeroPool(sizeof(ALIAS_LIST));
-  ASSERT(Node != NULL);
+  if (Node == NULL) {
+return RETURN_OUT_OF_RESOURCES;
+  }
   Node->CommandString = AllocateCopyPool(StrSize(Command), Command);
+  if (Node->CommandString == NULL) {
+FreePool (Node);
+return RETURN_OUT_OF_RESOURCES;
+  }
   Node->Alias = AllocateCopyPool(StrSize(Alias), Alias);
-  ASSERT(Node->CommandString != NULL);
-  ASSERT(Node->Alias != NULL);
+  if (Node->Alias == NULL) {
+FreePool (Node->CommandString);
+FreePool (Node);
+return RETURN_OUT_OF_RESOURCES;
+  }
 
   InsertHeadList (, >Link);
 
@@ -1303,7 +1317,10 @@ ShellCommandCreateInitialMappingsAndPaths(
 // Get all Device Paths
 //
 DevicePathList = AllocateZeroPool(sizeof(EFI_DEVICE_PATH_PROTOCOL*) * 
Count);
-ASSERT(DevicePathList != NULL);
+if (DevicePathList == NULL) {
+  SHELL_FREE_NON_NULL (HandleList);
+  return EFI_OUT_OF_RESOURCES;
+}
 
 for (Count = 0 ; HandleList[Count] != NULL ; Count++) {
   DevicePathList[Count] = DevicePathFromHandle(HandleList[Count]);
@@ -1360,7 +1377,10 @@ ShellCommandCreateInitialMappingsAndPaths(
 // Get all Device Paths
 //
 DevicePathList = AllocateZeroPool(sizeof(EFI_DEVICE_PATH_PROTOCOL*) * 
Count);
-ASSERT(DevicePathList != NULL);
+if (DevicePathList == NULL) {
+  SHELL_FREE_NON_NULL (HandleList);
+  return EFI_OUT_OF_RESOURCES;
+}
 
 for (Count = 0 ; HandleList[Count] != NULL ; Count++) {
   DevicePathList[Count] = DevicePathFromHandle(HandleList[Count]);
-- 
2.9.0.windows.1

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

[edk2] [PATCH v2 11/27] ShellPkg/EfiCompress: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiShellDebug1CommandsLib/EfiCompress.c   | 30 +-
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiCompress.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiCompress.c
index 85ae732..d94acf4 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiCompress.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiCompress.c
@@ -2,7 +2,7 @@
   Main file for EfiCompress shell Debug1 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2005 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2005 - 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
@@ -116,20 +116,26 @@ ShellCommandRunEfiCompress (
   Status = gEfiShellProtocol->GetFileSize(InShellFileHandle, );
   ASSERT_EFI_ERROR(Status);
   InBuffer = AllocateZeroPool((UINTN)InSize);
-  ASSERT(InBuffer != NULL);
-  InSize2 = (UINTN)InSize;
-  Status = gEfiShellProtocol->ReadFile(InShellFileHandle, , 
InBuffer);
-  InSize = InSize2;
-  ASSERT_EFI_ERROR(Status);
-  Status = Compress(InBuffer, InSize, OutBuffer, );
-  if (Status == EFI_BUFFER_TOO_SMALL) {
-OutBuffer = AllocateZeroPool((UINTN)OutSize);
-ASSERT(OutBuffer != NULL);
-Status = Compress(InBuffer, InSize, OutBuffer, );
+  if (InBuffer == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+  } else {
+InSize2 = (UINTN) InSize;
+Status = gEfiShellProtocol->ReadFile (InShellFileHandle, , 
InBuffer);
+InSize = InSize2;
+ASSERT_EFI_ERROR (Status);
+Status = Compress (InBuffer, InSize, OutBuffer, );
+if (Status == EFI_BUFFER_TOO_SMALL) {
+  OutBuffer = AllocateZeroPool ((UINTN) OutSize);
+  if (OutBuffer == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+  } else {
+Status = Compress (InBuffer, InSize, OutBuffer, );
+  }
+}
   }
   if (EFI_ERROR(Status)) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN 
(STR_EFI_COMPRESS_FAIL), gShellDebug1HiiHandle, Status);
-ShellStatus = SHELL_DEVICE_ERROR;
+ShellStatus = ((Status == EFI_OUT_OF_RESOURCES) ? 
SHELL_OUT_OF_RESOURCES : SHELL_DEVICE_ERROR);
   } else {
 OutSize2 = (UINTN)OutSize;
 Status = gEfiShellProtocol->WriteFile(OutShellFileHandle, 
, OutBuffer);
-- 
2.9.0.windows.1

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

[edk2] [PATCH v2 13/27] ShellPkg/LoadPciRom: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
index 1b94746..1b284c2 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
@@ -2,7 +2,7 @@
   Main file for LoadPciRom shell Debug1 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2005 - 2012, Intel Corporation. All rights reserved.
+  Copyright (c) 2005 - 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
@@ -147,7 +147,11 @@ ShellCommandRunLoadPciRom (
   }
   SourceSize  = (UINTN) Node->Info->FileSize;
   File1Buffer = AllocateZeroPool (SourceSize);
-  ASSERT(File1Buffer != NULL);
+  if (File1Buffer == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellDebug1HiiHandle, L"loadpcirom");
+ShellStatus = SHELL_OUT_OF_RESOURCES;
+continue;
+  }
   Status = gEfiShellProtocol->ReadFile(Node->Handle, , 
File1Buffer);
   if (EFI_ERROR(Status)) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_FILE_READ_FAIL), 
gShellDebug1HiiHandle, L"loadpcirom", Node->FullName);  
-- 
2.9.0.windows.1

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

[edk2] [PATCH v2 00/27] ShellPkg: Handle memory allocation failure

[Ruiyu Ni]

The patch serials remove almost all assertions on memory allocation
result, replaces with the error handling code.

https://github.com/niruiyu/edk2/commits/shell_assert_v2

V2 adds "Status =" in patch #8, adds missing copy right year updates in
patch #7, #8, #9, #11, #13.

Ruiyu Ni (27):
  ShellPkg/Shell.c: Handle memory allocation failure
  ShellPkg/IsVolatileEnv: Handle memory allocation failure
  ShellPkg/ShellAddEnvVarToList: Handle memory allocation failure
  ShellPkg/ShellProtocol.c: Handle memory allocation failure
  ShellPkg/Dp: Handle memory allocation failure
  ShellPkg/UefiHandleParsingLib.c: Handle memory allocation failure
  ShellPkg/UefiShellBcfgCommandLib: Handle memory allocation failure
  ShellPkg/ConsistMapping.c: Handle memory allocation failure
  ShellPkg/UefiShellCommandLib.c: Handle memory allocation failure
  ShellPkg/DMem: Handle memory allocation failure
  ShellPkg/EfiCompress: Handle memory allocation failure
  ShellPkg/EfiDecompress: Handle memory allocation failure
  ShellPkg/LoadPciRom: Handle memory allocation failure
  ShellPkg/Edit: Handle memory allocation failure
  ShellPkg/DevTree: Handle memory allocation failure
  ShellPkg/DrvCfg: Handle memory allocation failure
  ShellPkg/DrvDiag: Handle memory allocation failure
  ShellPkg/For: Handle memory allocation failure
  ShellPkg/If: Handle memory allocation failure
  ShellPkg/Cd: Handle memory allocation failure
  ShellPkg/Cp: Handle memory allocation failure
  ShellPkg/Mv: Handle memory allocation failure
  ShellPkg/UefiShellLib: Handle memory allocation failure
  ShellPkg/IfConfig: Handle memory allocation failure
  ShellPkg/UefiShellLib.c: Handle memory allocation failure
  ShellPkg/Ifconfig6: Handle memory allocation failure
  ShellPkg/Ping6: Handle memory allocation failure

 ShellPkg/Application/Shell/FileHandleWrappers.c|  19 +-
 ShellPkg/Application/Shell/Shell.c |  27 +-
 ShellPkg/Application/Shell/ShellEnvVar.c   |  73 +--
 ShellPkg/Application/Shell/ShellEnvVar.h   |  22 +-
 .../Application/Shell/ShellParametersProtocol.c|   5 +-
 ShellPkg/Application/Shell/ShellProtocol.c | 142 +++---
 ShellPkg/Application/Shell/ShellProtocol.h |  17 +-
 ShellPkg/Library/UefiDpLib/Dp.c|   8 +-
 .../UefiHandleParsingLib/UefiHandleParsingLib.c|  55 ++-
 .../UefiShellBcfgCommandLib.c  |  49 +-
 .../Library/UefiShellCommandLib/ConsistMapping.c   | 499 +
 .../UefiShellCommandLib/UefiShellCommandLib.c  |  36 +-
 ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c |   6 +-
 .../UefiShellDebug1CommandsLib/Edit/FileBuffer.c   |  41 +-
 .../UefiShellDebug1CommandsLib/EfiCompress.c   |  30 +-
 .../UefiShellDebug1CommandsLib/EfiDecompress.c |  52 ++-
 .../UefiShellDebug1CommandsLib/LoadPciRom.c|   8 +-
 .../Library/UefiShellDriver1CommandsLib/DevTree.c  |  13 +-
 .../Library/UefiShellDriver1CommandsLib/DrvCfg.c   |  17 +-
 .../Library/UefiShellDriver1CommandsLib/DrvDiag.c  |  17 +-
 ShellPkg/Library/UefiShellLevel1CommandsLib/For.c  |  12 +-
 ShellPkg/Library/UefiShellLevel1CommandsLib/If.c   |  95 ++--
 ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c   |  34 +-
 ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c   |  19 +-
 ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c   |  14 +-
 ShellPkg/Library/UefiShellLib/UefiShellLib.c   |  23 +-
 .../UefiShellNetwork1CommandsLib/Ifconfig.c|  77 +++-
 .../UefiShellNetwork1CommandsLib.uni   |   1 +
 .../UefiShellNetwork2CommandsLib/Ifconfig6.c   |  75 +++-
 .../Library/UefiShellNetwork2CommandsLib/Ping6.c   |   6 +-
 .../UefiShellNetwork2CommandsLib.uni   |   2 +
 31 files changed, 959 insertions(+), 535 deletions(-)

-- 
2.9.0.windows.1

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

[edk2] [Patch] BaseTools: Fix a bug for FixedPcd value generation in AutoGen file

[Yonghong Zhu]

If the library is listed in [Components] section for build only, its
used FixedPcd Value is not generated into AutoGen code. This patch
cover this case to generate the FixedPcd Value in AutoGen file.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/AutoGen/GenC.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index d25d371..29951e3 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -1222,11 +1222,11 @@ def CreateLibraryPcdCode(Info, AutoGenC, AutoGenH, Pcd):
 DatumType = ['UINT8', 'UINT16'][Pcd.DefaultValue[0] == 'L']
 AutoGenH.Append('extern const %s _gPcd_FixedAtBuild_%s%s;\n' 
%(DatumType, TokenCName, Array))
 AutoGenH.Append('#define %s  %s_gPcd_FixedAtBuild_%s\n' %(GetModeName, 
Type, TokenCName))
 AutoGenH.Append('//#define %s  ASSERT(FALSE)  // It is not allowed to 
set value for a FIXED_AT_BUILD PCD\n' % SetModeName)
 
-if PcdItemType == TAB_PCDS_FIXED_AT_BUILD and key in Info.ConstPcd:
+if PcdItemType == TAB_PCDS_FIXED_AT_BUILD and (key in Info.ConstPcd or 
(Info.IsLibrary and not Info._ReferenceModules)):
 AutoGenH.Append('#define _PCD_VALUE_%s %s\n' %(TokenCName, 
Pcd.DefaultValue))
 
 if PcdItemType == TAB_PCDS_FIXED_AT_BUILD:
 PcdDataSize = GetPcdSize(Pcd)
 AutoGenH.Append('#define %s %s\n' % (FixPcdSizeTokenName, 
PcdDataSize))
-- 
2.6.1.windows.1

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

Re: [edk2] [PATCH 00/27] ShellPkg: Handle memory allocation failure

[Ni, Ruiyu]

Jaben,
If we want to promote FreeArgList to library API. The structure ARG_LIST will
also be in the library header file. Let's wait and see if there is more such 
usage
and abstract it then.

I will post a v2 for those that need update.

Regards,
Ray

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
>Jaben
>Sent: Friday, July 15, 2016 5:06 AM
>To: Ni, Ruiyu ; edk2-devel@lists.01.org
>Cc: Carsey, Jaben 
>Subject: Re: [edk2] [PATCH 00/27] ShellPkg: Handle memory allocation failure
>
>Please check copyright.  I notice that at minimum EfiCompress.c and LoadPciRom 
>need an update.
>
>I think #8 has an error.  Replied to that email separately.
>
>Is it worth moving "IfConfig6FreeArgList" to a shared library?  Looked like 
>there were 2 copies...
>
>Otherwise for the series
>Reviewed-By: Jaben Carsey 
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Ruiyu Ni
>> Sent: Thursday, July 14, 2016 2:30 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] [PATCH 00/27] ShellPkg: Handle memory allocation failure
>> Importance: High
>>
>> The patch serials remove almost all assertions on memory allocation
>> result, replaces with the error handling code.
>>
>> https://github.com/niruiyu/edk2/commits/shell_assert
>>
>> Ruiyu Ni (27):
>>   ShellPkg/Shell.c: Handle memory allocation failure
>>   ShellPkg/IsVolatileEnv: Handle memory allocation failure
>>   ShellPkg/ShellAddEnvVarToList: Handle memory allocation failure
>>   ShellPkg/ShellProtocol.c: Handle memory allocation failure
>>   ShellPkg/Dp: Handle memory allocation failure
>>   ShellPkg/UefiHandleParsingLib.c: Handle memory allocation failure
>>   ShellPkg/UefiShellBcfgCommandLib: Handle memory allocation failure
>>   ShellPkg/ConsistMapping.c: Handle memory allocation failure
>>   ShellPkg/UefiShellCommandLib.c: Handle memory allocation failure
>>   ShellPkg/DMem: Handle memory allocation failure
>>   ShellPkg/EfiCompress: Handle memory allocation failure
>>   ShellPkg/EfiDecompress: Handle memory allocation failure
>>   ShellPkg/LoadPciRom: Handle memory allocation failure
>>   ShellPkg/Edit: Handle memory allocation failure
>>   ShellPkg/DevTree: Handle memory allocation failure
>>   ShellPkg/DrvCfg: Handle memory allocation failure
>>   ShellPkg/DrvDiag: Handle memory allocation failure
>>   ShellPkg/For: Handle memory allocation failure
>>   ShellPkg/If: Handle memory allocation failure
>>   ShellPkg/Cd: Handle memory allocation failure
>>   ShellPkg/Cp: Handle memory allocation failure
>>   ShellPkg/Mv: Handle memory allocation failure
>>   ShellPkg/UefiShellLib: Handle memory allocation failure
>>   ShellPkg/IfConfig: Handle memory allocation failure
>>   ShellPkg/UefiShellLib.c: Handle memory allocation failure
>>   ShellPkg/Ifconfig6: Handle memory allocation failure
>>   ShellPkg/Ping6: Handle memory allocation failure
>>
>>  ShellPkg/Application/Shell/FileHandleWrappers.c|  19 +-
>>  ShellPkg/Application/Shell/Shell.c |  27 +-
>>  ShellPkg/Application/Shell/ShellEnvVar.c   |  73 +--
>>  ShellPkg/Application/Shell/ShellEnvVar.h   |  22 +-
>>  .../Application/Shell/ShellParametersProtocol.c|   5 +-
>>  ShellPkg/Application/Shell/ShellProtocol.c | 142 +++---
>>  ShellPkg/Application/Shell/ShellProtocol.h |  17 +-
>>  ShellPkg/Library/UefiDpLib/Dp.c|   8 +-
>>  .../UefiHandleParsingLib/UefiHandleParsingLib.c|  55 ++-
>>  .../UefiShellBcfgCommandLib.c  |  47 +-
>>  .../Library/UefiShellCommandLib/ConsistMapping.c   | 497 +-
>> ---
>>  .../UefiShellCommandLib/UefiShellCommandLib.c  |  34 +-
>>  ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c |   6 +-
>>  .../UefiShellDebug1CommandsLib/Edit/FileBuffer.c   |  41 +-
>>  .../UefiShellDebug1CommandsLib/EfiCompress.c   |  28 +-
>>  .../UefiShellDebug1CommandsLib/EfiDecompress.c |  52 ++-
>>  .../UefiShellDebug1CommandsLib/LoadPciRom.c|   6 +-
>>  .../Library/UefiShellDriver1CommandsLib/DevTree.c  |  13 +-
>>  .../Library/UefiShellDriver1CommandsLib/DrvCfg.c   |  17 +-
>>  .../Library/UefiShellDriver1CommandsLib/DrvDiag.c  |  17 +-
>>  ShellPkg/Library/UefiShellLevel1CommandsLib/For.c  |  12 +-
>>  ShellPkg/Library/UefiShellLevel1CommandsLib/If.c   |  95 ++--
>>  ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c   |  34 +-
>>  ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c   |  19 +-
>>  ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c   |  14 +-
>>  ShellPkg/Library/UefiShellLib/UefiShellLib.c   |  23 +-
>>  .../UefiShellNetwork1CommandsLib/Ifconfig.c|  77 +++-
>>  .../UefiShellNetwork1CommandsLib.uni   |   1 +
>>  .../UefiShellNetwork2CommandsLib/Ifconfig6.c   |  75 +++-
>>  .../Library/UefiShellNetwork2CommandsLib/Ping6.c   |   6 +-
>>  

[edk2] [Patch] BaseTools: Add build info for binary modules that only list in FDF file

[Yonghong Zhu]

If the binary module is list in the FDF file but not list in the DSC
file, current build report would not include these binary module's info
in the report "Module section". The patch fix this issue.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py   |  4 
 BaseTools/Source/Python/GenFds/FdfParser.py  | 12 +++-
 BaseTools/Source/Python/build/BuildReport.py | 18 +-
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 8da441f..836e0ae 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -1912,10 +1912,14 @@ class PlatformAutoGen(AutoGen):
 #   @param  Module  The module from which the library classes will be 
resolved
 #
 #   @retval library_listList of library instances sorted
 #
 def ApplyLibraryInstance(self, Module):
+# Cover the case that the binary INF file is list in the FDF file but 
not DSC file, return empty list directly
+if str(Module) not in self.Platform.Modules:
+return []
+
 ModuleType = Module.ModuleType
 
 # for overridding library instances with module specific setting
 PlatformModule = self.Platform.Modules[str(Module)]
 
diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py 
b/BaseTools/Source/Python/GenFds/FdfParser.py
index 39f951a..4e61b48 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -229,10 +229,11 @@ class FileProfile :
 EdkLogger.error("FdfParser", FILE_OPEN_FAILURE, ExtraData=FileName)
 
 
 self.PcdDict = {}
 self.InfList = []
+self.BinaryInfDict = {}
 # ECC will use this Dict and List information
 self.PcdFileLineDict = {}
 self.InfFileLineList = []
 
 self.FdDict = {}
@@ -2470,10 +2471,15 @@ class FdfParser:
 
 if not ffsInf.InfFileName in self.Profile.InfList:
 self.Profile.InfList.append(ffsInf.InfFileName)
 FileLineTuple = GetRealFileLine(self.FileName, 
self.CurrentLineNumber)
 self.Profile.InfFileLineList.append(FileLineTuple)
+if ffsInf.UseArch:
+if ffsInf.UseArch not in self.Profile.BinaryInfDict:
+self.Profile.BinaryInfDict[ffsInf.UseArch] = 
[ffsInf.InfFileName]
+else:
+
self.Profile.BinaryInfDict[ffsInf.UseArch].append(ffsInf.InfFileName)
 
 if self.__IsToken('|'):
 if self.__IsKeyword('RELOCS_STRIPPED'):
 ffsInf.KeepReloc = False
 elif self.__IsKeyword('RELOCS_RETAINED'):
@@ -4349,11 +4355,15 @@ class FdfParser:
 
 if not ffsInf.InfFileName in self.Profile.InfList:
 self.Profile.InfList.append(ffsInf.InfFileName)
 FileLineTuple = GetRealFileLine(self.FileName, 
self.CurrentLineNumber)
 self.Profile.InfFileLineList.append(FileLineTuple)
-
+if ffsInf.UseArch:
+if ffsInf.UseArch not in self.Profile.BinaryInfDict:
+self.Profile.BinaryInfDict[ffsInf.UseArch] = 
[ffsInf.InfFileName]
+else:
+
self.Profile.BinaryInfDict[ffsInf.UseArch].append(ffsInf.InfFileName)
 
 self.__GetOptRomOverrides (ffsInf)
 
 Obj.FfsList.append(ffsInf)
 return True
diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index ef99989..b0e7d1b 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -45,10 +45,13 @@ from Common.DataType import TAB_BRG_PCD
 from Common.DataType import TAB_BRG_LIBRARY
 from Common.DataType import TAB_BACK_SLASH
 from Common.LongFilePathSupport import OpenLongFilePath as open
 from Common.MultipleWorkspace import MultipleWorkspace as mws
 import Common.GlobalData as GlobalData
+from AutoGen.AutoGen import ModuleAutoGen
+from Common.Misc import PathClass
+from Common.String import NormPath
 
 ## Pattern to extract contents in EDK DXS files
 gDxsDependencyPattern = re.compile(r"DEPENDENCY_START(.+)DEPENDENCY_END", 
re.DOTALL)
 
 ## Pattern to find total FV total size, occupied size in flash report 
intermediate file
@@ -1645,12 +1648,25 @@ class PlatformReport(object):
 for Ma in MaList:
 self.ModuleReportList.append(ModuleReport(Ma, ReportType))
 else:
 self._IsModuleBuild = False
 for Pa in Wa.AutoGenObjectList:
+ModuleAutoGenList = []
 for ModuleKey in Pa.Platform.Modules:
-
self.ModuleReportList.append(ModuleReport(Pa.Platform.Modules[ModuleKey].M, 
ReportType))
+ 

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Gao, Liming]

I see Steven patch uses -Os after enables new MS VA intrinsics. So, -Os should 
work. But, I am not sure whether -Os is better than -O2 for edk2. 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Friday, July 15, 2016 6:20 AM
> To: Bruce Cran ; Ard Biesheuvel
> ; Shi, Steven ; Zhu,
> Yonghong ; Gao, Liming ;
> Kinney, Michael D ; Justen, Jordan L
> ; af...@apple.com; edk2-de...@ml01.01.org
> Subject: Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64
> 
> On 07/14/16 23:57, Bruce Cran wrote:
> > On 7/14/2016 7:16 AM, Ard Biesheuvel wrote:
> >
> >> Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to
> >> GCC44.
> >
> > I wonder if -Os might be a better default optimization? Or perhaps
> > there's plenty of flash on devices nowadays and performance is more
> > important than size?
> >
> > At least for our driver, I see a 33% size reduction with -O2 and 44%
> > with -Os for the driver .efi file. Perhaps more importantly, the .rom
> > file (i.e. efirom output) has no reduction with -O2 and a 14% reduction
> > with -Os.
> >
> 
> Beware of -Os with GCC48:
> 
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10963
> 
> 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 v3 2/5] OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3

[Jordan Justen]

On 2016-07-13 07:36:56, Laszlo Ersek wrote:
> Move the permanent PEI memory for the S3 resume boot path to the top of
> the low RAM (just below TSEG if the SMM driver stack is included in the
> build). The new size is derived from CpuMpPei's approximate memory demand.
> 
> Save the base address and the size in new global variables, regardless of
> the boot path. On the normal boot path, use these variables for covering
> the area with EfiACPIMemoryNVS type memory.
> 
> PcdS3AcpiReservedMemoryBase and PcdS3AcpiReservedMemorySize become unused
> in PlatformPei; remove them.
> 
> Cc: Jeff Fan 
> Cc: Jordan Justen 
> Cc: Michael Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> Reviewed-by: Jeff Fan 
> ---
> 
> Notes:
> v2:
> - new in v2 [Jordan, Jeff]
> 
>  OvmfPkg/PlatformPei/PlatformPei.inf |  3 +-
>  OvmfPkg/PlatformPei/MemDetect.c | 39 ++--
>  2 files changed, 28 insertions(+), 14 deletions(-)
> 
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index 3556404017fc..229831b10da0 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -65,7 +65,6 @@ [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> -  gUefiOvmfPkgTokenSpaceGuid.PcdS3AcpiReservedMemoryBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
> @@ -82,7 +81,6 @@ [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
>gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
>gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
> @@ -95,6 +93,7 @@ [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
>gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
>  
>  [FixedPcd]
>gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
> diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
> index d59b461547c5..7129ed26fa3e 100644
> --- a/OvmfPkg/PlatformPei/MemDetect.c
> +++ b/OvmfPkg/PlatformPei/MemDetect.c
> @@ -39,6 +39,9 @@ Module Name:
>  
>  UINT8 mPhysMemAddressWidth;
>  
> +STATIC UINT32 mS3AcpiReservedMemoryBase;
> +STATIC UINT32 mS3AcpiReservedMemorySize;
> +
>  UINT32
>  GetSystemMemorySizeBelow4gb (
>VOID
> @@ -335,18 +338,30 @@ PublishPeiMemory (
>UINT64  LowerMemorySize;
>UINT32  PeiMemoryCap;
>  
> +  LowerMemorySize = GetSystemMemorySizeBelow4gb ();
> +  if (FeaturePcdGet (PcdSmmSmramRequire)) {
> +//
> +// TSEG is chipped from the end of low RAM
> +//
> +LowerMemorySize -= FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;
> +  }
> +
> +  //
> +  // If S3 is supported, then the S3 permanent PEI memory is placed next,
> +  // downwards. Its size is primarily dictated by CpuMpPei. The formula below
> +  // is an approximation.
> +  //
> +  if (mS3Supported) {
> +mS3AcpiReservedMemorySize = SIZE_512KB +
> +  PcdGet32 (PcdCpuMaxLogicalProcessorNumber) * SIZE_32KB;

Maybe use PcdCpuApStackSize rather than SIZE_32KB?

Is there an chance that with OVMF's modest usage of PEI MP, perhaps we
could get by with a smaller stack size per processor? 4 or 8 KB? This
would reduce 8MB down to 1 or 2MB.

Maybe we could use a separate PcdPeiCpuApStackSize for PEI? What do
think Jeff/Mike?

I think OVMF is more sensitive to the size, since we try to support
255 processors.

Series Reviewed-by: Jordan Justen 

> +mS3AcpiReservedMemoryBase = LowerMemorySize - mS3AcpiReservedMemorySize;
> +LowerMemorySize = mS3AcpiReservedMemoryBase;
> +  }
> +
>if (mBootMode == BOOT_ON_S3_RESUME) {
> -MemoryBase = PcdGet32 (PcdS3AcpiReservedMemoryBase);
> -MemorySize = PcdGet32 (PcdS3AcpiReservedMemorySize);
> +MemoryBase = mS3AcpiReservedMemoryBase;
> +MemorySize = mS3AcpiReservedMemorySize;
>} else {
> -LowerMemorySize = GetSystemMemorySizeBelow4gb ();
> -if (FeaturePcdGet (PcdSmmSmramRequire)) {
> -  //
> -  // TSEG is chipped from the end of low RAM
> -  //
> -  LowerMemorySize -= FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;
> -}
> -
>  PeiMemoryCap = GetPeiMemoryCap ();
>  DEBUG ((EFI_D_INFO, "%a: mPhysMemAddressWidth=%d PeiMemoryCap=%u KB\n",
>__FUNCTION__, mPhysMemAddressWidth, 

Re: [edk2] [PATCH v3 4/5] OvmfPkg: include UefiCpuPkg/CpuMpPei

[Jordan Justen]

On 2016-07-13 07:36:58, Laszlo Ersek wrote:
> In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use.
> 
> CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond
> those already used by CpuDxe:
> 
> - PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these
>   control whether CpuMpPei performs microcode update. If the region size
>   is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the
>   region size to zero by default, which is appropriate for OVMF.
> 
> - PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how
>   CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait
>   (with PAUSE). The latter PCD is only relevant if the former PCD is 2
>   (MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself,
>   we choose HLT. That's the default set by UefiCpuPkg.dec.
> 
> Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib
> technically, it is supposed to consume PeiCpuExceptionHandlerLib. See:
> 
> - http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703
> 
> - git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import
>   PeiCpuExceptionHandlerLib module"), part of the series linked above.
> 
> Jeff recommended to resolve CpuExceptionHandlerLib to
> PeiCpuExceptionHandlerLib for all PEIMs:
> 
> - http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477
> 
> Since at the moment we have no resolution in place that would cover this
> for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]),
> it's easy to do.
> 
> Cc: Jeff Fan 
> Cc: Jordan Justen 
> Cc: Michael Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v3:
> - resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib for all
>   PEIMs [Jeff]
> - drop Jeff's R-b from earlier
> 
>  OvmfPkg/OvmfPkgIa32.dsc| 5 +
>  OvmfPkg/OvmfPkgIa32X64.dsc | 5 +
>  OvmfPkg/OvmfPkgX64.dsc | 5 +
>  OvmfPkg/OvmfPkgIa32.fdf| 1 +
>  OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
>  OvmfPkg/OvmfPkgX64.fdf | 1 +
>  6 files changed, 18 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 805650059e96..8af326778205 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -212,6 +212,7 @@ [LibraryClasses.common.PEIM]
>  !ifdef $(SOURCE_DEBUG_ENABLE)
>
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
>  !endif
> +  
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
>  
>  [LibraryClasses.common.DXE_CORE]
>HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
> @@ -519,6 +520,10 @@ [Components]
>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>}
>  !endif
> +  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
> +
> +  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> +  }

It looks like we have this (PcdLib) overridden in nearly every PEIM. I
think we should update the default library mapping.

With, or without that change:
Reviewed-by: Jordan Justen 

>  
>#
># DXE Phase modules
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 7615ee96dff2..4bb38d0f7b3c 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -217,6 +217,7 @@ [LibraryClasses.common.PEIM]
>  !ifdef $(SOURCE_DEBUG_ENABLE)
>
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
>  !endif
> +  
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
>  
>  [LibraryClasses.common.DXE_CORE]
>HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
> @@ -527,6 +528,10 @@ [Components.IA32]
>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>}
>  !endif
> +  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
> +
> +  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> +  }
>  
>  [Components.X64]
>#
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 7f8a5c25a5c0..be3aa1fc6c43 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -217,6 +217,7 @@ [LibraryClasses.common.PEIM]
>  !ifdef $(SOURCE_DEBUG_ENABLE)
>
> DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
>  !endif
> +  
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
>  
>  [LibraryClasses.common.DXE_CORE]
>HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
> @@ -526,6 +527,10 @@ [Components]
>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>}
>  !endif
> +  UefiCpuPkg/CpuMpPei/CpuMpPei.inf {
> +
> +  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> +  }
>  
>#
># DXE Phase modules
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index ccc3e1461d55..136973443755 

Re: [edk2] [patch] ShellPkg: Fix issue about Ifconfig6 -r command.

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Wu, Jiaxin
> Sent: Wednesday, July 13, 2016 9:32 PM
> To: Zhang, Lubo ; Carsey, Jaben
> ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan 
> Subject: RE: [edk2] [patch] ShellPkg: Fix issue about Ifconfig6 -r command.
> Importance: High
> 
> Reviewed-By: Wu Jiaxin 
> 
> Best Regards!
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Zhang Lubo
> > Sent: Thursday, July 14, 2016 10:32 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> > Jiaxin 
> > Subject: [edk2] [patch] ShellPkg: Fix issue about Ifconfig6 -r command.
> >
> > Follow the Shell Spec, when the interface name is Specified, we need to
> > refresh the Ipv6 configuration.
> >
> > Cc: Hegde Nagaraj P 
> > Cc: Ye Ting 
> > Cc: Fu Siyuan 
> > Cc: Wu Jiaxin 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Zhang Lubo 
> > ---
> >  .../UefiShellNetwork2CommandsLib/Ifconfig6.c   | 30
> > +++---
> >  .../UefiShellNetwork2CommandsLib.uni   |  2 ++
> >  2 files changed, 28 insertions(+), 4 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ifconfig6.c
> > b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ifconfig6.c
> > index 371b368..42c972e 100644
> > --- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ifconfig6.c
> > +++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ifconfig6.c
> > @@ -1055,58 +1055,80 @@ IfConfig6ShowInterfaceInfo (
> >
> >  Entry = Entry->ForwardLink;
> >}
> >
> >ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> > (STR_IFCONFIG6_INFO_BREAK), gShellNetwork2HiiHandle);
> > +  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> > + (STR_IFCONFIG6_INFO_NEWLINE), gShellNetwork2HiiHandle);
> >
> >return SHELL_SUCCESS;
> >  }
> >
> >  /**
> >The clean process of the IfConfig6 application.
> >
> >@param[in]   IfListThe pointer of IfList(interface list).
> > +  @param[in]   IfNameThe pointer of interface name.
> >
> >@retval SHELL_SUCCESS  The IfConfig6 clean processed successfully.
> >@retval others The IfConfig6 clean process failed.
> >
> >  **/
> >  SHELL_STATUS
> >  IfConfig6ClearInterfaceInfo (
> > -  IN LIST_ENTRY*IfList
> > +  IN LIST_ENTRY*IfList,
> > +  IN CHAR16*IfName
> >)
> >  {
> >EFI_STATUSStatus;
> >SHELL_STATUS  ShellStatus;
> >LIST_ENTRY*Entry;
> >IFCONFIG6_INTERFACE_CB*IfCb;
> >EFI_IP6_CONFIG_POLICY Policy;
> >
> > -  Policy = Ip6ConfigPolicyAutomatic;
> >Entry  = IfList->ForwardLink;
> >Status = EFI_SUCCESS;
> >ShellStatus = SHELL_SUCCESS;
> >
> >if (IsListEmpty (IfList)) {
> >  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> > (STR_IFCONFIG6_ERR_INVALID_INTERFACE), gShellNetwork2HiiHandle);
> >}
> >
> >//
> > -  // Go through the interface list.
> > +  // Go through the interface list.If the interface name is specified,
> > + then  // need to refresh the configuration.
> >//
> >while (Entry != IfList) {
> >
> >  IfCb = BASE_CR (Entry, IFCONFIG6_INTERFACE_CB, Link);
> >
> > +if ((IfName != NULL) && (StrCmp (IfName, IfCb->IfInfo->Name) == 0)) {
> > +  Policy = Ip6ConfigPolicyManual;
> > +
> > +  Status = IfCb->IfCfg->SetData (
> > +  IfCb->IfCfg,
> > +  Ip6ConfigDataTypePolicy,
> > +  sizeof (EFI_IP6_CONFIG_POLICY),
> > +  
> > +  );
> > +  if (EFI_ERROR (Status)) {
> > +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD),
> > gShellNetwork2HiiHandle, L"ifconfig6");
> > +ShellStatus = SHELL_ACCESS_DENIED;
> > +break;
> > +  }
> > +}
> > +
> > +Policy = Ip6ConfigPolicyAutomatic;
> > +
> >  Status = IfCb->IfCfg->SetData (
> >  IfCb->IfCfg,
> >  Ip6ConfigDataTypePolicy,
> >  sizeof (EFI_IP6_CONFIG_POLICY),
> >  
> >  );
> >
> >  if (EFI_ERROR (Status)) {
> > +  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD),
> > + gShellNetwork2HiiHandle, L"ifconfig6");
> >ShellStatus = SHELL_ACCESS_DENIED;
> >break;
> >  }
> >
> >  Entry  = Entry->ForwardLink;
> > @@ -1614,11 +1636,11 @@ IfConfig6 (
> >case IfConfig6OpList:
> >  ShellStatus = IfConfig6ShowInterfaceInfo (>IfList);
> >  break;
> >
> >case IfConfig6OpClear:
> > -

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Laszlo Ersek]

On 07/14/16 15:16, Ard Biesheuvel wrote:
> This series is not an attempt to steal Steven's thunder. I was merely
> inspired by some of the changes he is proposing for GCC 5 and Clang
> support, which I noticed would be applicable to older versions of GCC
> as well.
> 
> The first patch fixes the issue that __builtin_unreachable() is not
> implemented by GCC 4.4 or earlier.
> 
> Patch #2 is Steven's patch to switch to the flavor of VA_LIST that is
> explicitly modeled after the MS implementation. This by itself is an
> improvement, since the open coded implementation that performs arithmetic
> on the address of explicit arguments to obtain the variadic arguments is
> fragile and difficult to maintain, and should be best avoided.
> 
> Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to GCC44.
> I tested this change with both Ovmf and EmulatorPkg built in various ways
> and with various versions, with the caveat that I did not always use a 
> matching
> binutils (i.e., of the same era). Since the issues this series deal with are
> all code generation issues, I think this is reasonable, but more testing would
> be appreciated.
> 
> Patch #4 applies the visibility 'hidden' GCC pragma globally. Please refer to
> the commit log for the motivation.
> 
> Patch #5 switches GCC/X64 to the PIC small code model, which results in 
> smaller
> code.
> 
> Ard Biesheuvel (4):
>   MdePkg: avoid __builtin_unreachable() on GCC v4.4
>   BaseTools/tools_def: enable O2 optimization for GCC X64 builds
>   MdePkg X64: force 'hidden' visibility when building with -fpic
>   BaseTools/tools_def: switch GCC/X64 to the PIC small model
> 
> Shi, Steven (1):
>   MdePkg: Enable new MS VA intrinsics for GNUC x86 64bits build
> 
>  BaseTools/Conf/tools_def.template  | 18 +++-
>  MdePkg/Include/Base.h  | 29 +++-
>  MdePkg/Include/X64/ProcessorBind.h | 10 +++
>  3 files changed, 49 insertions(+), 8 deletions(-)
>  mode change 100644 => 100755 MdePkg/Include/Base.h
> 

So, I did some tests.

First, the build tests. I built OVMF 84 times, with the following settings:

* Dimension 1: whether your and Steven's patches were applied or not.
The basis was always:
- upstream 04147690b59b,
- plus my personal patches that I constantly rebase,
- plus my pending "feat_ctrl_issue97_v3" patches,
- plus my work-in-progress build fixes for GCCxx and VS2015x86 warnings,
- plus OpenSSL 1.0.2g.

These patches don't interfere with your and Steven's work. So on top of
this basis, your and Steven's patches were either applied (rebased) or
not. This is a multiplier of 2.

* Dimension 2: the GCC toolchain used. Ranging from GCC44 through GCC49,
plus gcc-6.1 at the end (using GCC49 settings). Multiplier of 7.

* Dimension 3: DEBUG versus RELEASE build target. Factor of 2.

* Dimension 4: the OVMF platform. I used the following command lines:

- build -a IA32-p OvmfPkg/OvmfPkgIa32.dsc-D SMM_REQUIRE \
-D SECURE_BOOT_ENABLE -D HTTP_BOOT_ENABLE
- build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -D SMM_REQUIRE \
-D SECURE_BOOT_ENABLE -D HTTP_BOOT_ENABLE
- build -a X64 -p OvmfPkg/OvmfPkgX64.dsc \
-D SECURE_BOOT_ENABLE -D HTTP_BOOT_ENABLE

As you can see, Ia32 and Ia32X64 are built with the SMM driver stack;
X64 is built without it. (This is because edk2 S3 doesn't support
X64+SMM at the moment, so I either have to build X64 without SMM, or
disable S3 support on the QEMU command line. I find the latter more
inconvenient, plus Ia32X64 is just fine for 64-bit OS + SMM + S3.)
Anyhow, this is a factor of 3.

For these builds, I collected the log files and the report files. Values
in dimension 3 are not separated into separate files, because you can
pass -b DEBUG -b RELEASE at once, and the build utility will do the
right thing -- it will build both targets in succession. However, the
log file and the report file each will contain both DEBUG and RELEASE
output.

For the builds I also collected the OVMF_CODE.fd firmware binaries.

The good news is that all of the builds succeeded. You can draw size
comparisons from the build log files: see SECFV, PEIFV and DXEFV for
uncompressed sizes, and FVMAIN_COMPACT for the compressed size of
PEIFV+DXEFV together. (Thanks Mike for the reminder!)

I'll send you the link to the results archive off-list. (I tend not to
post stuff publicly that I cannot review in detail, purely out of
privacy concerns, and this archive is just too big for that. For example
I dislike disclosing full pathnames from my system: in commit messages I
always edit them out.)

Clearly if you distill any numbers from the archive, you are going to
review those in detail (and hopefully you won't disclose the entire
archive), so it should suffice to constrain my privacy concerns to you
personally. :)

-o-

Second, the run test. I executed two test scenarios here. For these, the
following dimensions were fixed:

- Dimension 1: your and Steven's patches were always applied.
- Dimension 

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Kinney, Michael D]

Hi Bruce,

I think size is most important for the default settings.  This is why it
it important to measure the size changes for each set of flag options.
Size measurements are a bit complex due to the interaction with compressors.
I have found that measuring the used space in an FV with compression enabled
is the best way to determine if a compiler/linker flag has a positive or
negative influence on the size.  For efirom, I recommend enabling UEFI 
compression (-ec option).

If a specific module needs a flag a for performance optimization, that can 
be done in a  section of DSC or [BuildOptions] section of INF.

Mike

> -Original Message-
> From: Bruce Cran [mailto:br...@cran.org.uk]
> Sent: Thursday, July 14, 2016 2:57 PM
> To: Ard Biesheuvel ; Shi, Steven 
> ;
> Zhu, Yonghong ; Gao, Liming ; 
> Kinney,
> Michael D ; Justen, Jordan L 
> ;
> ler...@redhat.com; af...@apple.com; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64
> 
> On 7/14/2016 7:16 AM, Ard Biesheuvel wrote:
> 
> > Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to GCC44.
> 
> I wonder if -Os might be a better default optimization? Or perhaps
> there's plenty of flash on devices nowadays and performance is more
> important than size?
> 
> At least for our driver, I see a 33% size reduction with -O2 and 44%
> with -Os for the driver .efi file. Perhaps more importantly, the .rom
> file (i.e. efirom output) has no reduction with -O2 and a 14% reduction
> with -Os.
> 
> --
> Bruce
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Bruce Cran]

On 7/14/2016 4:20 PM, Laszlo Ersek wrote:


On 07/14/16 23:57, Bruce Cran wrote:


I wonder if -Os might be a better default optimization? Or perhaps
there's plenty of flash on devices nowadays and performance is more
important than size?

Beware of -Os with GCC48:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10963


Oh, good point. Also, at this point any optimization is a _huge_ 
improvement! :)


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

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Laszlo Ersek]

On 07/14/16 23:57, Bruce Cran wrote:
> On 7/14/2016 7:16 AM, Ard Biesheuvel wrote:
> 
>> Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to
>> GCC44.
> 
> I wonder if -Os might be a better default optimization? Or perhaps
> there's plenty of flash on devices nowadays and performance is more
> important than size?
> 
> At least for our driver, I see a 33% size reduction with -O2 and 44%
> with -Os for the driver .efi file. Perhaps more importantly, the .rom
> file (i.e. efirom output) has no reduction with -O2 and a 14% reduction
> with -Os.
> 

Beware of -Os with GCC48:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10963

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

Re: [edk2] SATA AHCI issue

[Mike Maslenkin]

BTW Windows waits for FR bit set for 50ms as opposed to Linux.

See P_Running_WaitOnFRE function of storahci from WDK.

So you can break Intel HBAs for example.
Could you ask iastor team about this issue?

Regards.

On Thu, 2016-07-14 at 06:25 +, Tian, Feng wrote:
> Hi, Shaveta
> 
> We have approved this fix. Do you miss it? 
> http://article.gmane.org/gmane.comp.bios.edk2.devel/13541
> 
> Thanks
> Feng
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Shaveta Leekha
> Sent: Thursday, July 14, 2016 2:04 PM
> To: edk2-devel@lists.01.org; Linaro UEFI Mailman List 
> ; Jan Dąbroś ; Ard 
> Biesheuvel 
> Cc: Ruchika Gupta 
> Subject: [edk2] SATA AHCI issue
> 
> Hi,
> 
> 
> 
> I have been working on support for AHCI controller for my ARMv8 platform.
> 
> For that I have integrated my PciEmulation code and SataControllerDxe driver 
> code with MdeModulePkg/Bus/Ata.
> 
> 
> 
> But facing one issue, this is same issue reported by Jan Dabros(in To list) 
> sometime back.
> 
> Setting PxCMD.FRE bit of command register doesn't cause PxCMD.FR to be set to 
> '1' even after "500msec" timeout.
> 
> 
> 
> (As per AHCI spec 1.3 : When PxCMD.FRE is set, it causes PxCMD.FR to be set 
> to '1' )
> 
> Is it correct to just comment out following code part from 
> "MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c" file, 
> "AhciModeInitialization" function:
> 
> 
> 
> As Initialization timeouts is occurring in below part of code:
> 
> 
> 
>   //
> 
>   // Enable FIS Receive DMA engine for the first D2H FIS.
> 
>   //
> 
>   Offset = EFI_AHCI_PORT_START + Port * EFI_AHCI_PORT_REG_WIDTH + 
> EFI_AHCI_PORT_CMD;
> 
>   AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE);
> 
>   Status = AhciWaitMmioSet (
> 
>  PciIo,
> 
>  Offset,
> 
>  EFI_AHCI_PORT_CMD_FR,
> 
>  EFI_AHCI_PORT_CMD_FR,
> 
>  EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT
> 
>  );
> 
>   if (EFI_ERROR (Status)) {
> 
> continue;
> 
>   }
> 
> 
> 
> And if above code is commented out, then SATA stack works completely fine.
> 
> 
> 
> What can be the problem?
> 
> 
> 
> Thank you in advance for your time!
> 
> 
> 
> Best regards,
> 
> Shaveta
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


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

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Bruce Cran]

On 7/14/2016 7:16 AM, Ard Biesheuvel wrote:


Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to GCC44.


I wonder if -Os might be a better default optimization? Or perhaps 
there's plenty of flash on devices nowadays and performance is more 
important than size?


At least for our driver, I see a 33% size reduction with -O2 and 44% 
with -Os for the driver .efi file. Perhaps more importantly, the .rom 
file (i.e. efirom output) has no reduction with -O2 and a 14% reduction 
with -Os.


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

Re: [edk2] [PATCH 08/27] ShellPkg/ConsistMapping.c: Handle memory allocation failure

[Carsey, Jaben]

> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, July 14, 2016 2:30 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: [PATCH 08/27] ShellPkg/ConsistMapping.c: Handle memory
> allocation failure
> Importance: High
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Jaben Carsey 
> ---
>  .../Library/UefiShellCommandLib/ConsistMapping.c   | 497 +-
> ---
>  1 file changed, 319 insertions(+), 178 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> index 41754dd..82d4f1f 100644
> --- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> +++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> @@ -53,10 +53,12 @@ typedef struct {
>@param  MapInfo  The map info.
>@param  OrigDevPath  The original device path protocol.
> 
> +  @retval EFI_OUT_OF_RESOURCESOut of resources.
> +  @retval EFI_SUCCESS The appending was successful.
>  **/
>  typedef
> -VOID
> -(EFIAPI *SERIAL_DECODE_FUNCTION) (
> +EFI_STATUS
> +(*SERIAL_DECODE_FUNCTION) (
>EFI_DEVICE_PATH_PROTOCOL*DevPath,
>DEVICE_CONSIST_MAPPING_INFO *MapInfo,
>EFI_DEVICE_PATH_PROTOCOL*OrigDevPath
> @@ -78,13 +80,11 @@ typedef struct {
>@param  Fmt  The format string
>@param  ...  The data will be printed.
> 
> -  @return Allocated buffer with the formatted string printed in it.
> -  The caller must free the allocated buffer.
> -  The buffer allocation is not packed.
> +  @retval EFI_SUCCESS  The string is concatenated successfully.
> +  @retval EFI_OUT_OF_RESOURCES Out of resources.
> 
>  **/
> -CHAR16 *
> -EFIAPI
> +EFI_STATUS
>  CatPrint (
>IN OUT POOL_PRINT   *Str,
>IN CHAR16   *Fmt,
> @@ -94,37 +94,40 @@ CatPrint (
>UINT16  *AppendStr;
>VA_LIST Args;
>UINTN   StringSize;
> +  CHAR16  *NewStr;
> 
>AppendStr = AllocateZeroPool (0x1000);
>if (AppendStr == NULL) {
> -ASSERT(FALSE);
> -return Str->Str;
> +return EFI_OUT_OF_RESOURCES;
>}
> 
>VA_START (Args, Fmt);
>UnicodeVSPrint (AppendStr, 0x1000, Fmt, Args);
>VA_END (Args);
>if (NULL == Str->Str) {
> -StringSize   = StrSize (AppendStr);
> -Str->Str  = AllocateZeroPool (StringSize);
> -ASSERT (Str->Str != NULL);
> +StringSize = StrSize (AppendStr);
> +NewStr = AllocateZeroPool (StringSize);
>} else {
>  StringSize = StrSize (AppendStr);
>  StringSize += (StrSize (Str->Str) - sizeof (UINT16));
> 
> -Str->Str = ReallocatePool (
> -StrSize (Str->Str),
> -StringSize,
> -Str->Str
> +NewStr = ReallocatePool (
> +   StrSize (Str->Str),
> +   StringSize,
> +   Str->Str
> );
> -ASSERT (Str->Str != NULL);
> +  }
> +  if (NewStr == NULL) {
> +FreePool (AppendStr);
> +return EFI_OUT_OF_RESOURCES;
>}
> 
> +  Str->Str = NewStr;
>StrCatS (Str->Str, StringSize/sizeof(CHAR16), AppendStr);
>Str->Len = StringSize;
> 
>FreePool (AppendStr);
> -  return Str->Str;
> +  return EFI_SUCCESS;
>  }
> 
>  MTD_NAME  mMTDName[] = {
> @@ -156,30 +159,30 @@ MTD_NAME  mMTDName[] = {
>@param[in, out] Str  The string so append onto.
>@param[in]  Num  The number to divide and append.
> 
> -  @retval EFI_INVALID_PARAMETER   A parameter was NULL.
> +  @retval EFI_OUT_OF_RESOURCESOut of resources.
>@retval EFI_SUCCESS The appending was successful.
>  **/
>  EFI_STATUS
> -EFIAPI
>  AppendCSDNum2 (
>IN OUT POOL_PRINT   *Str,
>IN UINT64   Num
>)
>  {
> -  UINT64  Result;
> -  UINT32   Rem;
> +  EFI_STATUS Status;
> +  UINT64 Result;
> +  UINT32 Rem;
> 
> -  if (Str == NULL) {
> -return (EFI_INVALID_PARAMETER);
> -  }
> +  ASSERT (Str != NULL);
> 
>Result = DivU64x32Remainder (Num, 25, );
>if (Result > 0) {
> -AppendCSDNum2 (Str, Result);
> +Status = AppendCSDNum2 (Str, Result);
> +if (EFI_ERROR (Status)) {
> +  return Status;
> +}
>}
> 
> -  CatPrint (Str, L"%c", Rem + 'a');
> -  return (EFI_SUCCESS);
> +  return CatPrint (Str, L"%c", Rem + 'a');
>  }
> 
>  /**
> @@ -188,29 +191,30 @@ AppendCSDNum2 (
>@param[in, out] MappingItem  The mapping info object to append onto.
>@param[in]  Num  The info to append.
> 
> -  @retval EFI_INVALID_PARAMETER   A parameter was NULL.
> +  @retval EFI_OUT_OF_RESOURCESOut of resources.
>@retval EFI_SUCCESS The appending was successful.
> +
>  **/
>  EFI_STATUS
> -EFIAPI
>  AppendCSDNum (
>IN OUT DEVICE_CONSIST_MAPPING_INFO*MappingItem,
>IN UINT64 Num
>)
>  {
> -  if (MappingItem == NULL) {
> -return EFI_INVALID_PARAMETER;
> -  

Re: [edk2] [PATCH 00/27] ShellPkg: Handle memory allocation failure

[Carsey, Jaben]

Please check copyright.  I notice that at minimum EfiCompress.c and LoadPciRom 
need an update.

I think #8 has an error.  Replied to that email separately.

Is it worth moving "IfConfig6FreeArgList" to a shared library?  Looked like 
there were 2 copies...

Otherwise for the series
Reviewed-By: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Thursday, July 14, 2016 2:30 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH 00/27] ShellPkg: Handle memory allocation failure
> Importance: High
> 
> The patch serials remove almost all assertions on memory allocation
> result, replaces with the error handling code.
> 
> https://github.com/niruiyu/edk2/commits/shell_assert
> 
> Ruiyu Ni (27):
>   ShellPkg/Shell.c: Handle memory allocation failure
>   ShellPkg/IsVolatileEnv: Handle memory allocation failure
>   ShellPkg/ShellAddEnvVarToList: Handle memory allocation failure
>   ShellPkg/ShellProtocol.c: Handle memory allocation failure
>   ShellPkg/Dp: Handle memory allocation failure
>   ShellPkg/UefiHandleParsingLib.c: Handle memory allocation failure
>   ShellPkg/UefiShellBcfgCommandLib: Handle memory allocation failure
>   ShellPkg/ConsistMapping.c: Handle memory allocation failure
>   ShellPkg/UefiShellCommandLib.c: Handle memory allocation failure
>   ShellPkg/DMem: Handle memory allocation failure
>   ShellPkg/EfiCompress: Handle memory allocation failure
>   ShellPkg/EfiDecompress: Handle memory allocation failure
>   ShellPkg/LoadPciRom: Handle memory allocation failure
>   ShellPkg/Edit: Handle memory allocation failure
>   ShellPkg/DevTree: Handle memory allocation failure
>   ShellPkg/DrvCfg: Handle memory allocation failure
>   ShellPkg/DrvDiag: Handle memory allocation failure
>   ShellPkg/For: Handle memory allocation failure
>   ShellPkg/If: Handle memory allocation failure
>   ShellPkg/Cd: Handle memory allocation failure
>   ShellPkg/Cp: Handle memory allocation failure
>   ShellPkg/Mv: Handle memory allocation failure
>   ShellPkg/UefiShellLib: Handle memory allocation failure
>   ShellPkg/IfConfig: Handle memory allocation failure
>   ShellPkg/UefiShellLib.c: Handle memory allocation failure
>   ShellPkg/Ifconfig6: Handle memory allocation failure
>   ShellPkg/Ping6: Handle memory allocation failure
> 
>  ShellPkg/Application/Shell/FileHandleWrappers.c|  19 +-
>  ShellPkg/Application/Shell/Shell.c |  27 +-
>  ShellPkg/Application/Shell/ShellEnvVar.c   |  73 +--
>  ShellPkg/Application/Shell/ShellEnvVar.h   |  22 +-
>  .../Application/Shell/ShellParametersProtocol.c|   5 +-
>  ShellPkg/Application/Shell/ShellProtocol.c | 142 +++---
>  ShellPkg/Application/Shell/ShellProtocol.h |  17 +-
>  ShellPkg/Library/UefiDpLib/Dp.c|   8 +-
>  .../UefiHandleParsingLib/UefiHandleParsingLib.c|  55 ++-
>  .../UefiShellBcfgCommandLib.c  |  47 +-
>  .../Library/UefiShellCommandLib/ConsistMapping.c   | 497 +-
> ---
>  .../UefiShellCommandLib/UefiShellCommandLib.c  |  34 +-
>  ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c |   6 +-
>  .../UefiShellDebug1CommandsLib/Edit/FileBuffer.c   |  41 +-
>  .../UefiShellDebug1CommandsLib/EfiCompress.c   |  28 +-
>  .../UefiShellDebug1CommandsLib/EfiDecompress.c |  52 ++-
>  .../UefiShellDebug1CommandsLib/LoadPciRom.c|   6 +-
>  .../Library/UefiShellDriver1CommandsLib/DevTree.c  |  13 +-
>  .../Library/UefiShellDriver1CommandsLib/DrvCfg.c   |  17 +-
>  .../Library/UefiShellDriver1CommandsLib/DrvDiag.c  |  17 +-
>  ShellPkg/Library/UefiShellLevel1CommandsLib/For.c  |  12 +-
>  ShellPkg/Library/UefiShellLevel1CommandsLib/If.c   |  95 ++--
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c   |  34 +-
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c   |  19 +-
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c   |  14 +-
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c   |  23 +-
>  .../UefiShellNetwork1CommandsLib/Ifconfig.c|  77 +++-
>  .../UefiShellNetwork1CommandsLib.uni   |   1 +
>  .../UefiShellNetwork2CommandsLib/Ifconfig6.c   |  75 +++-
>  .../Library/UefiShellNetwork2CommandsLib/Ping6.c   |   6 +-
>  .../UefiShellNetwork2CommandsLib.uni   |   2 +
>  31 files changed, 954 insertions(+), 530 deletions(-)
> 
> --
> 2.9.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] minimum NASM version

[Paolo Bonzini]

On 14/07/2016 19:25, Laszlo Ersek wrote:
>> > Ugh, this is so wrong. :)  I guess you could also use a macro that
>> > expands to
>> > 
>> >bits 32
>> >mov  src, dst
>> >bits 64
>> > 
>> > because the encoding is the same in 32-bit and 64-bit.
> Nice trick :), but the point of using NASM would be to avoid such hacks,
> and to say what we mean, on Windows and Linux build hosts identically.

Sure---though in this case something like

movseg  ds, ax

would obey two of three requirements (say what you mean, and treat
Windows+Linux equally).

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

Re: [edk2] minimum NASM version

[Laszlo Ersek]

On 07/14/16 19:16, Kinney, Michael D wrote:
> Laszlo,
> 
> It may be possible to update NASM source to be compatible with both older and 
> latest
> version of NASM.

I claim that it's not possible in this case, as long as we'd like to
avoid DBs and other coding tricks (i.e., as long as we'd like to write
what we mean). Of course if I'm proved wrong, I'll welcome it :)

> We would have to evaluate the current build breaks to see if that is
> possible or not.

It should be possible to reproduce in Windows build environments as
well, by removing the currently installed NASM package, and installing
the one from .

> For VS20xx tool chains, I prefer to specify the min at 2.12.01.

I will update my patch to state this.

> I think support for 
> source level debug is a requirement for actively supported tool chains.  

It may be a requirement for actively supported *non-GCCxx* toolchains.
It's definitely not satisfied for GCCxx toolchains. (I'd love if it were!)

I will update my patch to say that 2.10 is required for the GCC
toolchain family, and 2.12.01 is required for all other tooolchain families.

Thanks!
Laszlo


>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Laszlo Ersek
>> Sent: Thursday, July 14, 2016 9:19 AM
>> To: Kinney, Michael D ; Michael Zimmermann
>> ; Gao, Liming 
>> Cc: Justen, Jordan L ; edk2-devel-01 > de...@ml01.01.org>
>> Subject: Re: [edk2] minimum NASM version
>>
>> On 07/14/16 17:47, Kinney, Michael D wrote:
>>> Laszlo,
>>>
>>> We may have to specify a different min version based on the toolchain used.
>>>
>>> For VS20xx toolchains, we must have 2.12.01 as the minimum to support 
>>> source level
>> debug.
>>>
>>> If GCCxx toolchains are compatible with NASM 2.07, then I see no reason to 
>>> not
>> document it that way.
>>
>> The problem with NASM 2.07 is not compatibility with any GCCxx toolchain.
>>
>> The problem with NASM 2.07 is that it is unable to build NASM source code 
>> already
>> committed to the tree.
>>
>> This is the patch I currently have:
>>
>>> diff --git a/BaseTools/Conf/tools_def.template 
>>> b/BaseTools/Conf/tools_def.template
>>> index 2065fa34998f..fca4319b7cfa 100644
>>> --- a/BaseTools/Conf/tools_def.template
>>> +++ b/BaseTools/Conf/tools_def.template
>>> @@ -708,7 +708,10 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program
>> Files/CodeSourcery/Sourcery G
>>>  #
>>>  # Other Supported Tools
>>>  # =
>>> -#   NASM 2.07 or later http://www.nasm.us/
>>> +#   NASM -- http://www.nasm.us/
>>> +#   - NASM 2.10 or later for assembling *.nasm and *.nasmb source files
>>> +#   - NASM 2.12.01 or later if, in addition, source level debug information
>>> +# should be produced for the MSFT toolchain family
>>>  #
>>>  
>>> 
>>>  
>>> 
>>
>> I presume NASM 2.10 will work just fine with VS20xx toolchains, as long as 
>> one is not
>> interested in source level debugging. Is that correct?
>>
>> Thanks
>> Laszlo
>>
>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
 Laszlo Ersek
 Sent: Thursday, July 14, 2016 8:25 AM
 To: Michael Zimmermann ; Gao, Liming
>> 
 Cc: Kinney, Michael D ; Justen, Jordan L
 ; edk2-devel-01 
 Subject: Re: [edk2] minimum NASM version

 On 07/14/16 16:51, Michael Zimmermann wrote:
> Hi,
>
> if it would be very important to support that old version of NASM you
> could just write "raw" assembler by putting the needed instructions as
> word's within the executable code.

 Edk2 has prided itself on supporting several versions of several
 toolchains. For the MSFT toolchain family, this seems to go back to
 VS2003. For the GCC toolchain family, it goes back to GCC44.

 NASM 2.07 is exactly from the era that GCC44 belongs to. If we bump the
 NASM requirement to 2.10, that would actually suggest to drop support
 for GCC toolchains up to and including GCC46. The era to which NASM 2.10
 belongs also provides GCC47, so on a GNU/Linux distro where you find
 NASM 2.10, you should also find GCC47.

 Now, if we raise the NASM requirement to 2.10, but don't drop GCC44,
 GCC45, and GCC46, that might render these three GCC toolchains
 "un-utilizable" in practice, but that's not a problem in fact. The
 reason is that all GNU/Linux distros that are still supported will offer
 you GCC47 + NASM 2.10 (or later), so you won't *need* GCC44, GCC45,
 

Re: [edk2] minimum NASM version

[Laszlo Ersek]

On 07/14/16 19:14, Paolo Bonzini wrote:
> 
> 
> On 14/07/2016 19:11, Laszlo Ersek wrote:
>> * I didn't say, but I also tried "mov ax, ds". The SDM writes, "The
>>   upper 56 bits or 48 bits (respectively) of the destination
>>   general-purpose register are not modified by the operation". In this
>>   context, those bits were known to be zero, and I hoped that NASM 2.07
>>   might support a 16->16 MOV.
>>
>> I vaguely recall that I tried "mov eax, ds" too (it may have been my
>> very first try, I don't remember any longer). I think "mov ax, ds" was
>> my second try, and "movzx eax, ds" the third?...
>>
>> However, none of these work, because NASM 2.07 (apparently) lacks the
>> *general* ability to MOV from/to segment registers in 64-bit mode.
> 
> Ugh, this is so wrong. :)  I guess you could also use a macro that
> expands to
> 
>   bits 32
>   mov  src, dst
>   bits 64
> 
> because the encoding is the same in 32-bit and 64-bit.

Nice trick :), but the point of using NASM would be to avoid such hacks,
and to say what we mean, on Windows and Linux build hosts identically.

Thanks!
Laszlo

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

Re: [edk2] minimum NASM version

[Kinney, Michael D]

Laszlo,

It may be possible to update NASM source to be compatible with both older and 
latest
version of NASM.  We would have to evaluate the current build breaks to see if 
that is
possible or not.

For VS20xx tool chains, I prefer to specify the min at 2.12.01.  I think 
support for 
source level debug is a requirement for actively supported tool chains.  

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Thursday, July 14, 2016 9:19 AM
> To: Kinney, Michael D ; Michael Zimmermann
> ; Gao, Liming 
> Cc: Justen, Jordan L ; edk2-devel-01  de...@ml01.01.org>
> Subject: Re: [edk2] minimum NASM version
> 
> On 07/14/16 17:47, Kinney, Michael D wrote:
> > Laszlo,
> >
> > We may have to specify a different min version based on the toolchain used.
> >
> > For VS20xx toolchains, we must have 2.12.01 as the minimum to support 
> > source level
> debug.
> >
> > If GCCxx toolchains are compatible with NASM 2.07, then I see no reason to 
> > not
> document it that way.
> 
> The problem with NASM 2.07 is not compatibility with any GCCxx toolchain.
> 
> The problem with NASM 2.07 is that it is unable to build NASM source code 
> already
> committed to the tree.
> 
> This is the patch I currently have:
> 
> > diff --git a/BaseTools/Conf/tools_def.template 
> > b/BaseTools/Conf/tools_def.template
> > index 2065fa34998f..fca4319b7cfa 100644
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -708,7 +708,10 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program
> Files/CodeSourcery/Sourcery G
> >  #
> >  # Other Supported Tools
> >  # =
> > -#   NASM 2.07 or later http://www.nasm.us/
> > +#   NASM -- http://www.nasm.us/
> > +#   - NASM 2.10 or later for assembling *.nasm and *.nasmb source files
> > +#   - NASM 2.12.01 or later if, in addition, source level debug information
> > +# should be produced for the MSFT toolchain family
> >  #
> >  
> > 
> >  
> > 
> 
> I presume NASM 2.10 will work just fine with VS20xx toolchains, as long as 
> one is not
> interested in source level debugging. Is that correct?
> 
> Thanks
> Laszlo
> 
> 
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >> Laszlo Ersek
> >> Sent: Thursday, July 14, 2016 8:25 AM
> >> To: Michael Zimmermann ; Gao, Liming
> 
> >> Cc: Kinney, Michael D ; Justen, Jordan L
> >> ; edk2-devel-01 
> >> Subject: Re: [edk2] minimum NASM version
> >>
> >> On 07/14/16 16:51, Michael Zimmermann wrote:
> >>> Hi,
> >>>
> >>> if it would be very important to support that old version of NASM you
> >>> could just write "raw" assembler by putting the needed instructions as
> >>> word's within the executable code.
> >>
> >> Edk2 has prided itself on supporting several versions of several
> >> toolchains. For the MSFT toolchain family, this seems to go back to
> >> VS2003. For the GCC toolchain family, it goes back to GCC44.
> >>
> >> NASM 2.07 is exactly from the era that GCC44 belongs to. If we bump the
> >> NASM requirement to 2.10, that would actually suggest to drop support
> >> for GCC toolchains up to and including GCC46. The era to which NASM 2.10
> >> belongs also provides GCC47, so on a GNU/Linux distro where you find
> >> NASM 2.10, you should also find GCC47.
> >>
> >> Now, if we raise the NASM requirement to 2.10, but don't drop GCC44,
> >> GCC45, and GCC46, that might render these three GCC toolchains
> >> "un-utilizable" in practice, but that's not a problem in fact. The
> >> reason is that all GNU/Linux distros that are still supported will offer
> >> you GCC47 + NASM 2.10 (or later), so you won't *need* GCC44, GCC45,
> >> GCC46. We can remove them any time we like.
> >>
> >> (Actually, I'm lying a bit: dropping support for NASM 2.07 and GCC44
> >> renders RHEL-6 (still alive) unsupported as an edk2 build host, but
> >> that's just a reality check: the NASM source code in the tree won't
> >> build on RHEL-6 *anyway*.)
> >>
> >> Bumping the requirement from NASM 2.10 to something higher would be very
> >> bad. For example, RHEL-7 and Debian oldstable (both alive) would be
> >> rendered unsupported as build systems. This would be akin to dropping
> >> GCC47 and GCC48 -- catastrophic. There's no reason for doing this, given
> >> that NASM 2.10 can build the NASM assembly code in the tree just fine
> >> (without open-coded DBs).
> >>
> >>> changing the min requirement seems more proper though :)
> >>
> >> I'd like to raise the requirement to 2.10, because 

Re: [edk2] minimum NASM version

[Paolo Bonzini]

On 14/07/2016 19:11, Laszlo Ersek wrote:
> * I didn't say, but I also tried "mov ax, ds". The SDM writes, "The
>   upper 56 bits or 48 bits (respectively) of the destination
>   general-purpose register are not modified by the operation". In this
>   context, those bits were known to be zero, and I hoped that NASM 2.07
>   might support a 16->16 MOV.
> 
> I vaguely recall that I tried "mov eax, ds" too (it may have been my
> very first try, I don't remember any longer). I think "mov ax, ds" was
> my second try, and "movzx eax, ds" the third?...
> 
> However, none of these work, because NASM 2.07 (apparently) lacks the
> *general* ability to MOV from/to segment registers in 64-bit mode.

Ugh, this is so wrong. :)  I guess you could also use a macro that
expands to

bits 32
mov  src, dst
bits 64

because the encoding is the same in 32-bit and 64-bit.

>> In fact if you check the SDM only movsx supports 64-bit destinations,
>> while for movzx you just use a 32-bit destination.
> 
> MOV seems to support 16-bit segment register --> 64 bit register or memory:
> 
> Opcode InstructionOp/  64-Bit  Compat/
>   En   ModeLeg Mode
> -     ---  --  
> REX.W + 8C /r  MOV r/m64,Sreg**   AValid   Valid
> 
> Description: Move zero extended 16-bit segment register to r/m64.

Right, but for 64-bit registers it's pointless.

Paolo

> ** In 32-bit mode, the assembler may insert the 16-bit operand-size
>prefix with this instruction (see the following “Description”
>section for further information).
> 
> (I.e., I believe that the original NASM source code is correct.)
> 
> Thanks
> Laszlo
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] minimum NASM version

[Laszlo Ersek]

On 07/14/16 18:33, Paolo Bonzini wrote:
> 
> 
> On 14/07/2016 13:19, Laszlo Ersek wrote:
>> The problem is that NASM wouldn't support segment register MOVs in
>> 64-bit mode until the following commit:
>>
>>   http://repo.or.cz/nasm.git/commitdiff/21d4ccc3c338
>>
>>   Wed, 25 Aug 2010 02:28:00 +0200 (24 17:28 -0700)
>>
>> However, that change was first released in NASM 2.10:
>>
>>   http://repo.or.cz/nasm.git/commitdiff/ff62f33da0a2
>>
>>   Mon, 12 Mar 2012 21:36:02 +0100 (12 13:36 -0700)
>>
>> I tried to work around this; for example by using
>>
>>   movzx   eax, ds
> 
> You can just say "mov eax, ds" (and "mov ds, eax").  The reason is that
> 32-bit destination operands are automatically zero-extended to 64-bit.

* The "zx" in the above was not about zero extending from 32 to 64 (I
  read in the SDM or maybe on StackOverflow that that would happen
  automatically, when writing eax and then reading rax). Instead, the
  "zx" was for zero extending  from 16 (ds) to 32 (eax).

* I didn't say, but I also tried "mov ax, ds". The SDM writes, "The
  upper 56 bits or 48 bits (respectively) of the destination
  general-purpose register are not modified by the operation". In this
  context, those bits were known to be zero, and I hoped that NASM 2.07
  might support a 16->16 MOV.

I vaguely recall that I tried "mov eax, ds" too (it may have been my
very first try, I don't remember any longer). I think "mov ax, ds" was
my second try, and "movzx eax, ds" the third?...

However, none of these work, because NASM 2.07 (apparently) lacks the
*general* ability to MOV from/to segment registers in 64-bit mode.

> In fact if you check the SDM only movsx supports 64-bit destinations,
> while for movzx you just use a 32-bit destination.

MOV seems to support 16-bit segment register --> 64 bit register or memory:

Opcode InstructionOp/  64-Bit  Compat/
  En   ModeLeg Mode
-     ---  --  
REX.W + 8C /r  MOV r/m64,Sreg**   AValid   Valid

Description: Move zero extended 16-bit segment register to r/m64.

** In 32-bit mode, the assembler may insert the 16-bit operand-size
   prefix with this instruction (see the following “Description”
   section for further information).

(I.e., I believe that the original NASM source code is correct.)

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

Re: [edk2] minimum NASM version

[Paolo Bonzini]

On 14/07/2016 13:19, Laszlo Ersek wrote:
> The problem is that NASM wouldn't support segment register MOVs in
> 64-bit mode until the following commit:
> 
>   http://repo.or.cz/nasm.git/commitdiff/21d4ccc3c338
> 
>   Wed, 25 Aug 2010 02:28:00 +0200 (24 17:28 -0700)
> 
> However, that change was first released in NASM 2.10:
> 
>   http://repo.or.cz/nasm.git/commitdiff/ff62f33da0a2
> 
>   Mon, 12 Mar 2012 21:36:02 +0100 (12 13:36 -0700)
> 
> I tried to work around this; for example by using
> 
>   movzx   eax, ds

You can just say "mov eax, ds" (and "mov ds, eax").  The reason is that
32-bit destination operands are automatically zero-extended to 64-bit.
In fact if you check the SDM only movsx supports 64-bit destinations,
while for movzx you just use a 32-bit destination.

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

Re: [edk2] minimum NASM version

[Laszlo Ersek]

On 07/14/16 18:00, Andrew Fish wrote:
> 
>> On Jul 14, 2016, at 8:47 AM, Kinney, Michael D  
>> wrote:
>>
>> Laszlo,
>>
>> We may have to specify a different min version based on the toolchain used.
>>
>> For VS20xx toolchains, we must have 2.12.01 as the minimum to support source 
>> level debug.
>>
>> If GCCxx toolchains are compatible with NASM 2.07, then I see no reason to 
>> not document it that way.
>>
> 
> And the Xcode/clang is going to need a future version of NASM to support 
> debugging, so I agree per toolchain mins seems reasonable. 

I would like to distinguish plain building from source level debug info.
An end-user or packager / distributor might well want to build some edk2
platform only, without any interest in source level debugging. This
should apply to RELEASE builds especially.

For these cases (when only the building of a firmware binary matters), a
universal minimum version for NASM should exist. One that is as
conservative as possible. This version should be dictated by the needs
of the *.nasm and *.nasmb source files in the tree, and only for the
purposes of assembling (not debugging) them.

Thanks
Laszlo

>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>>> Laszlo Ersek
>>> Sent: Thursday, July 14, 2016 8:25 AM
>>> To: Michael Zimmermann ; Gao, Liming 
>>> 
>>> Cc: Kinney, Michael D ; Justen, Jordan L
>>> ; edk2-devel-01 
>>> Subject: Re: [edk2] minimum NASM version
>>>
>>> On 07/14/16 16:51, Michael Zimmermann wrote:
 Hi,

 if it would be very important to support that old version of NASM you
 could just write "raw" assembler by putting the needed instructions as
 word's within the executable code.
>>>
>>> Edk2 has prided itself on supporting several versions of several
>>> toolchains. For the MSFT toolchain family, this seems to go back to
>>> VS2003. For the GCC toolchain family, it goes back to GCC44.
>>>
>>> NASM 2.07 is exactly from the era that GCC44 belongs to. If we bump the
>>> NASM requirement to 2.10, that would actually suggest to drop support
>>> for GCC toolchains up to and including GCC46. The era to which NASM 2.10
>>> belongs also provides GCC47, so on a GNU/Linux distro where you find
>>> NASM 2.10, you should also find GCC47.
>>>
>>> Now, if we raise the NASM requirement to 2.10, but don't drop GCC44,
>>> GCC45, and GCC46, that might render these three GCC toolchains
>>> "un-utilizable" in practice, but that's not a problem in fact. The
>>> reason is that all GNU/Linux distros that are still supported will offer
>>> you GCC47 + NASM 2.10 (or later), so you won't *need* GCC44, GCC45,
>>> GCC46. We can remove them any time we like.
>>>
>>> (Actually, I'm lying a bit: dropping support for NASM 2.07 and GCC44
>>> renders RHEL-6 (still alive) unsupported as an edk2 build host, but
>>> that's just a reality check: the NASM source code in the tree won't
>>> build on RHEL-6 *anyway*.)
>>>
>>> Bumping the requirement from NASM 2.10 to something higher would be very
>>> bad. For example, RHEL-7 and Debian oldstable (both alive) would be
>>> rendered unsupported as build systems. This would be akin to dropping
>>> GCC47 and GCC48 -- catastrophic. There's no reason for doing this, given
>>> that NASM 2.10 can build the NASM assembly code in the tree just fine
>>> (without open-coded DBs).
>>>
 changing the min requirement seems more proper though :)
>>>
>>> I'd like to raise the requirement to 2.10, because that is both
>>> justified by the source code in the tree, and satisfied by most
>>> GNU/Linux distros that are still alive.
>>>
>>> I disgree with raising the requirement above 2.10. It wouldn't provide
>>> universally useful features, but render distros that are still alive
>>> (and fully capable of building edk2) unsupported as edk2 build platforms.
>>>
>>> Thanks
>>> Laszlo
>>>
 On Thu, Jul 14, 2016 at 4:28 PM, Gao, Liming > wrote:

   Laszlo:
 Sorry. I didn't mention my version. I use 2.12.01 to verify all
   changes. In 2.12, it adds support of Codeview version 8 (cv8) debug
   format for win32 and win64 formats in the COFF backend. We need this
   feature to get cv8 debug.  But, this version will report the error
   message: nasm: fatal: assertion !"relocation for unregistered
   symbol" failed at output/codeview.c:420. So, I suggest to update
   comments to NASM 2.12.01.

   Thanks
   Liming
   From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org
   ] On Behalf Of Laszlo Ersek
   Sent: Thursday, July 14, 2016 8:04 PM
   To: Gao, Liming >; Justen, Jordan L
   

Re: [edk2] minimum NASM version

[Laszlo Ersek]

On 07/14/16 17:47, Kinney, Michael D wrote:
> Laszlo,
> 
> We may have to specify a different min version based on the toolchain used.
> 
> For VS20xx toolchains, we must have 2.12.01 as the minimum to support source 
> level debug.
> 
> If GCCxx toolchains are compatible with NASM 2.07, then I see no reason to 
> not document it that way.

The problem with NASM 2.07 is not compatibility with any GCCxx toolchain.

The problem with NASM 2.07 is that it is unable to build NASM source code 
already committed to the tree.

This is the patch I currently have:

> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 2065fa34998f..fca4319b7cfa 100644
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -708,7 +708,10 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
> Files/CodeSourcery/Sourcery G
>  #
>  # Other Supported Tools
>  # =
> -#   NASM 2.07 or later http://www.nasm.us/
> +#   NASM -- http://www.nasm.us/
> +#   - NASM 2.10 or later for assembling *.nasm and *.nasmb source files
> +#   - NASM 2.12.01 or later if, in addition, source level debug information
> +# should be produced for the MSFT toolchain family
>  #
>  
> 
>  
> 

I presume NASM 2.10 will work just fine with VS20xx toolchains, as long as one 
is not interested in source level debugging. Is that correct?

Thanks
Laszlo


>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Laszlo Ersek
>> Sent: Thursday, July 14, 2016 8:25 AM
>> To: Michael Zimmermann ; Gao, Liming 
>> 
>> Cc: Kinney, Michael D ; Justen, Jordan L
>> ; edk2-devel-01 
>> Subject: Re: [edk2] minimum NASM version
>>
>> On 07/14/16 16:51, Michael Zimmermann wrote:
>>> Hi,
>>>
>>> if it would be very important to support that old version of NASM you
>>> could just write "raw" assembler by putting the needed instructions as
>>> word's within the executable code.
>>
>> Edk2 has prided itself on supporting several versions of several
>> toolchains. For the MSFT toolchain family, this seems to go back to
>> VS2003. For the GCC toolchain family, it goes back to GCC44.
>>
>> NASM 2.07 is exactly from the era that GCC44 belongs to. If we bump the
>> NASM requirement to 2.10, that would actually suggest to drop support
>> for GCC toolchains up to and including GCC46. The era to which NASM 2.10
>> belongs also provides GCC47, so on a GNU/Linux distro where you find
>> NASM 2.10, you should also find GCC47.
>>
>> Now, if we raise the NASM requirement to 2.10, but don't drop GCC44,
>> GCC45, and GCC46, that might render these three GCC toolchains
>> "un-utilizable" in practice, but that's not a problem in fact. The
>> reason is that all GNU/Linux distros that are still supported will offer
>> you GCC47 + NASM 2.10 (or later), so you won't *need* GCC44, GCC45,
>> GCC46. We can remove them any time we like.
>>
>> (Actually, I'm lying a bit: dropping support for NASM 2.07 and GCC44
>> renders RHEL-6 (still alive) unsupported as an edk2 build host, but
>> that's just a reality check: the NASM source code in the tree won't
>> build on RHEL-6 *anyway*.)
>>
>> Bumping the requirement from NASM 2.10 to something higher would be very
>> bad. For example, RHEL-7 and Debian oldstable (both alive) would be
>> rendered unsupported as build systems. This would be akin to dropping
>> GCC47 and GCC48 -- catastrophic. There's no reason for doing this, given
>> that NASM 2.10 can build the NASM assembly code in the tree just fine
>> (without open-coded DBs).
>>
>>> changing the min requirement seems more proper though :)
>>
>> I'd like to raise the requirement to 2.10, because that is both
>> justified by the source code in the tree, and satisfied by most
>> GNU/Linux distros that are still alive.
>>
>> I disgree with raising the requirement above 2.10. It wouldn't provide
>> universally useful features, but render distros that are still alive
>> (and fully capable of building edk2) unsupported as edk2 build platforms.
>>
>> Thanks
>> Laszlo
>>
>>> On Thu, Jul 14, 2016 at 4:28 PM, Gao, Liming >> > wrote:
>>>
>>> Laszlo:
>>>   Sorry. I didn't mention my version. I use 2.12.01 to verify all
>>> changes. In 2.12, it adds support of Codeview version 8 (cv8) debug
>>> format for win32 and win64 formats in the COFF backend. We need this
>>> feature to get cv8 debug.  But, this version will report the error
>>> message: nasm: fatal: assertion !"relocation for unregistered
>>> symbol" failed at output/codeview.c:420. So, I suggest to update
>>> comments to NASM 2.12.01.

Re: [edk2] minimum NASM version

[Andrew Fish]

> On Jul 14, 2016, at 8:47 AM, Kinney, Michael D  
> wrote:
> 
> Laszlo,
> 
> We may have to specify a different min version based on the toolchain used.
> 
> For VS20xx toolchains, we must have 2.12.01 as the minimum to support source 
> level debug.
> 
> If GCCxx toolchains are compatible with NASM 2.07, then I see no reason to 
> not document it that way.
> 

And the Xcode/clang is going to need a future version of NASM to support 
debugging, so I agree per toolchain mins seems reasonable. 

Thanks,

Andrew Fish

> Mike
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Laszlo Ersek
>> Sent: Thursday, July 14, 2016 8:25 AM
>> To: Michael Zimmermann ; Gao, Liming 
>> 
>> Cc: Kinney, Michael D ; Justen, Jordan L
>> ; edk2-devel-01 
>> Subject: Re: [edk2] minimum NASM version
>> 
>> On 07/14/16 16:51, Michael Zimmermann wrote:
>>> Hi,
>>> 
>>> if it would be very important to support that old version of NASM you
>>> could just write "raw" assembler by putting the needed instructions as
>>> word's within the executable code.
>> 
>> Edk2 has prided itself on supporting several versions of several
>> toolchains. For the MSFT toolchain family, this seems to go back to
>> VS2003. For the GCC toolchain family, it goes back to GCC44.
>> 
>> NASM 2.07 is exactly from the era that GCC44 belongs to. If we bump the
>> NASM requirement to 2.10, that would actually suggest to drop support
>> for GCC toolchains up to and including GCC46. The era to which NASM 2.10
>> belongs also provides GCC47, so on a GNU/Linux distro where you find
>> NASM 2.10, you should also find GCC47.
>> 
>> Now, if we raise the NASM requirement to 2.10, but don't drop GCC44,
>> GCC45, and GCC46, that might render these three GCC toolchains
>> "un-utilizable" in practice, but that's not a problem in fact. The
>> reason is that all GNU/Linux distros that are still supported will offer
>> you GCC47 + NASM 2.10 (or later), so you won't *need* GCC44, GCC45,
>> GCC46. We can remove them any time we like.
>> 
>> (Actually, I'm lying a bit: dropping support for NASM 2.07 and GCC44
>> renders RHEL-6 (still alive) unsupported as an edk2 build host, but
>> that's just a reality check: the NASM source code in the tree won't
>> build on RHEL-6 *anyway*.)
>> 
>> Bumping the requirement from NASM 2.10 to something higher would be very
>> bad. For example, RHEL-7 and Debian oldstable (both alive) would be
>> rendered unsupported as build systems. This would be akin to dropping
>> GCC47 and GCC48 -- catastrophic. There's no reason for doing this, given
>> that NASM 2.10 can build the NASM assembly code in the tree just fine
>> (without open-coded DBs).
>> 
>>> changing the min requirement seems more proper though :)
>> 
>> I'd like to raise the requirement to 2.10, because that is both
>> justified by the source code in the tree, and satisfied by most
>> GNU/Linux distros that are still alive.
>> 
>> I disgree with raising the requirement above 2.10. It wouldn't provide
>> universally useful features, but render distros that are still alive
>> (and fully capable of building edk2) unsupported as edk2 build platforms.
>> 
>> Thanks
>> Laszlo
>> 
>>> On Thu, Jul 14, 2016 at 4:28 PM, Gao, Liming >> > wrote:
>>> 
>>>   Laszlo:
>>> Sorry. I didn't mention my version. I use 2.12.01 to verify all
>>>   changes. In 2.12, it adds support of Codeview version 8 (cv8) debug
>>>   format for win32 and win64 formats in the COFF backend. We need this
>>>   feature to get cv8 debug.  But, this version will report the error
>>>   message: nasm: fatal: assertion !"relocation for unregistered
>>>   symbol" failed at output/codeview.c:420. So, I suggest to update
>>>   comments to NASM 2.12.01.
>>> 
>>>   Thanks
>>>   Liming
>>>   From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org
>>>   ] On Behalf Of Laszlo Ersek
>>>   Sent: Thursday, July 14, 2016 8:04 PM
>>>   To: Gao, Liming >>   >; Justen, Jordan L
>>>   >;
>>>   Kinney, Michael D >>   >
>>>   Cc: edk2-devel-01 >>   >
>>>   Subject: Re: [edk2] minimum NASM version
>>> 
>>>   On 07/14/16 13:19, Laszlo Ersek wrote:
>>> 
 It seems that before NASM 2.10, there's simply no way to access
>>>   segment
 registers in 64-bit mode. I propose that we upgrade the following
 comment in BaseTools:
 
> diff --git a/BaseTools/Conf/tools_def.template
>>>   b/BaseTools/Conf/tools_def.template
> index 2065fa34998f..db61a37b6afd 100644
> --- a/BaseTools/Conf/tools_def.template

Re: [edk2] minimum NASM version

[Kinney, Michael D]

Laszlo,

We may have to specify a different min version based on the toolchain used.

For VS20xx toolchains, we must have 2.12.01 as the minimum to support source 
level debug.

If GCCxx toolchains are compatible with NASM 2.07, then I see no reason to not 
document it that way.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Thursday, July 14, 2016 8:25 AM
> To: Michael Zimmermann ; Gao, Liming 
> 
> Cc: Kinney, Michael D ; Justen, Jordan L
> ; edk2-devel-01 
> Subject: Re: [edk2] minimum NASM version
> 
> On 07/14/16 16:51, Michael Zimmermann wrote:
> > Hi,
> >
> > if it would be very important to support that old version of NASM you
> > could just write "raw" assembler by putting the needed instructions as
> > word's within the executable code.
> 
> Edk2 has prided itself on supporting several versions of several
> toolchains. For the MSFT toolchain family, this seems to go back to
> VS2003. For the GCC toolchain family, it goes back to GCC44.
> 
> NASM 2.07 is exactly from the era that GCC44 belongs to. If we bump the
> NASM requirement to 2.10, that would actually suggest to drop support
> for GCC toolchains up to and including GCC46. The era to which NASM 2.10
> belongs also provides GCC47, so on a GNU/Linux distro where you find
> NASM 2.10, you should also find GCC47.
> 
> Now, if we raise the NASM requirement to 2.10, but don't drop GCC44,
> GCC45, and GCC46, that might render these three GCC toolchains
> "un-utilizable" in practice, but that's not a problem in fact. The
> reason is that all GNU/Linux distros that are still supported will offer
> you GCC47 + NASM 2.10 (or later), so you won't *need* GCC44, GCC45,
> GCC46. We can remove them any time we like.
> 
> (Actually, I'm lying a bit: dropping support for NASM 2.07 and GCC44
> renders RHEL-6 (still alive) unsupported as an edk2 build host, but
> that's just a reality check: the NASM source code in the tree won't
> build on RHEL-6 *anyway*.)
> 
> Bumping the requirement from NASM 2.10 to something higher would be very
> bad. For example, RHEL-7 and Debian oldstable (both alive) would be
> rendered unsupported as build systems. This would be akin to dropping
> GCC47 and GCC48 -- catastrophic. There's no reason for doing this, given
> that NASM 2.10 can build the NASM assembly code in the tree just fine
> (without open-coded DBs).
> 
> > changing the min requirement seems more proper though :)
> 
> I'd like to raise the requirement to 2.10, because that is both
> justified by the source code in the tree, and satisfied by most
> GNU/Linux distros that are still alive.
> 
> I disgree with raising the requirement above 2.10. It wouldn't provide
> universally useful features, but render distros that are still alive
> (and fully capable of building edk2) unsupported as edk2 build platforms.
> 
> Thanks
> Laszlo
> 
> > On Thu, Jul 14, 2016 at 4:28 PM, Gao, Liming  > > wrote:
> >
> > Laszlo:
> >   Sorry. I didn't mention my version. I use 2.12.01 to verify all
> > changes. In 2.12, it adds support of Codeview version 8 (cv8) debug
> > format for win32 and win64 formats in the COFF backend. We need this
> > feature to get cv8 debug.  But, this version will report the error
> > message: nasm: fatal: assertion !"relocation for unregistered
> > symbol" failed at output/codeview.c:420. So, I suggest to update
> > comments to NASM 2.12.01.
> >
> > Thanks
> > Liming
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org
> > ] On Behalf Of Laszlo Ersek
> > Sent: Thursday, July 14, 2016 8:04 PM
> > To: Gao, Liming  > >; Justen, Jordan L
> > >;
> > Kinney, Michael D  > >
> > Cc: edk2-devel-01  > >
> > Subject: Re: [edk2] minimum NASM version
> >
> > On 07/14/16 13:19, Laszlo Ersek wrote:
> >
> > > It seems that before NASM 2.10, there's simply no way to access
> > segment
> > > registers in 64-bit mode. I propose that we upgrade the following
> > > comment in BaseTools:
> > >
> > >> diff --git a/BaseTools/Conf/tools_def.template
> > b/BaseTools/Conf/tools_def.template
> > >> index 2065fa34998f..db61a37b6afd 100644
> > >> --- a/BaseTools/Conf/tools_def.template
> > >> +++ b/BaseTools/Conf/tools_def.template
> > >> @@ -708,7 +708,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS =
> > /cygdrive/c/Program Files/CodeSourcery/Sourcery G
> > >> #
> > >> # Other Supported Tools
> > >> # 

Re: [edk2] minimum NASM version

[Laszlo Ersek]

On 07/14/16 16:51, Michael Zimmermann wrote:
> Hi,
> 
> if it would be very important to support that old version of NASM you
> could just write "raw" assembler by putting the needed instructions as
> word's within the executable code.

Edk2 has prided itself on supporting several versions of several
toolchains. For the MSFT toolchain family, this seems to go back to
VS2003. For the GCC toolchain family, it goes back to GCC44.

NASM 2.07 is exactly from the era that GCC44 belongs to. If we bump the
NASM requirement to 2.10, that would actually suggest to drop support
for GCC toolchains up to and including GCC46. The era to which NASM 2.10
belongs also provides GCC47, so on a GNU/Linux distro where you find
NASM 2.10, you should also find GCC47.

Now, if we raise the NASM requirement to 2.10, but don't drop GCC44,
GCC45, and GCC46, that might render these three GCC toolchains
"un-utilizable" in practice, but that's not a problem in fact. The
reason is that all GNU/Linux distros that are still supported will offer
you GCC47 + NASM 2.10 (or later), so you won't *need* GCC44, GCC45,
GCC46. We can remove them any time we like.

(Actually, I'm lying a bit: dropping support for NASM 2.07 and GCC44
renders RHEL-6 (still alive) unsupported as an edk2 build host, but
that's just a reality check: the NASM source code in the tree won't
build on RHEL-6 *anyway*.)

Bumping the requirement from NASM 2.10 to something higher would be very
bad. For example, RHEL-7 and Debian oldstable (both alive) would be
rendered unsupported as build systems. This would be akin to dropping
GCC47 and GCC48 -- catastrophic. There's no reason for doing this, given
that NASM 2.10 can build the NASM assembly code in the tree just fine
(without open-coded DBs).

> changing the min requirement seems more proper though :)

I'd like to raise the requirement to 2.10, because that is both
justified by the source code in the tree, and satisfied by most
GNU/Linux distros that are still alive.

I disgree with raising the requirement above 2.10. It wouldn't provide
universally useful features, but render distros that are still alive
(and fully capable of building edk2) unsupported as edk2 build platforms.

Thanks
Laszlo

> On Thu, Jul 14, 2016 at 4:28 PM, Gao, Liming  > wrote:
> 
> Laszlo:
>   Sorry. I didn't mention my version. I use 2.12.01 to verify all
> changes. In 2.12, it adds support of Codeview version 8 (cv8) debug
> format for win32 and win64 formats in the COFF backend. We need this
> feature to get cv8 debug.  But, this version will report the error
> message: nasm: fatal: assertion !"relocation for unregistered
> symbol" failed at output/codeview.c:420. So, I suggest to update
> comments to NASM 2.12.01.
> 
> Thanks
> Liming
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org
> ] On Behalf Of Laszlo Ersek
> Sent: Thursday, July 14, 2016 8:04 PM
> To: Gao, Liming  >; Justen, Jordan L
> >;
> Kinney, Michael D  >
> Cc: edk2-devel-01  >
> Subject: Re: [edk2] minimum NASM version
> 
> On 07/14/16 13:19, Laszlo Ersek wrote:
> 
> > It seems that before NASM 2.10, there's simply no way to access
> segment
> > registers in 64-bit mode. I propose that we upgrade the following
> > comment in BaseTools:
> >
> >> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> >> index 2065fa34998f..db61a37b6afd 100644
> >> --- a/BaseTools/Conf/tools_def.template
> >> +++ b/BaseTools/Conf/tools_def.template
> >> @@ -708,7 +708,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS =
> /cygdrive/c/Program Files/CodeSourcery/Sourcery G
> >> #
> >> # Other Supported Tools
> >> # =
> >> -# NASM 2.07 or later http://www.nasm.us/
> >> +# NASM 2.10 or later http://www.nasm.us/
> >> #
> >>
> 
> 
> >>
> 
> 
> >
> > plus wherever the minimum NASM version is documented on the Wiki.
> 
> * In support of the above suggestion: in my Fedora 13 guest (set up for
> GCC44 build testing), I could rebuild the following NASM package without
> any problems, from the source RPM:
> 
> nasm-2.10.09-1.fc21
> http://koji.fedoraproject.org/koji/buildinfo?buildID=463939
> 
> With this package installed, the build completed fine.
> 
> * Also in support: the "oldstable" Debian release (code name "wheezy")
> ships nasm 2.10 as well:
> 
> 

Re: [edk2] minimum NASM version

[Laszlo Ersek]

On 07/14/16 16:28, Gao, Liming wrote:
> Laszlo:
> 
>   Sorry. I didn’t mention my version. I use 2.12.01 to verify all
> changes. In 2.12, it adds support of Codeview version 8 (cv8) debug
> format for win32 and win64 formats in the COFF backend. We need this
> feature to get cv8 debug.

I understand.

> But, this version will report the error
> message: nasm: fatal: assertion !"relocation for unregistered symbol"
> failed at output/codeview.c:420.

Which version do you mean by "this version"?

Do you mean that NASM 2.10 does not support cv8 debug info generation?

> So, I suggest to update comments to
> NASM 2.12.01.

Hm, I disagree. NASM 2.10 is shipped with some stable operating system
that are still supported (among them: RHEL-7), and it wouldn't be nice
to drop edk2 building support on those
- despite NASM 2.10 working perfectly, and
- despite supporting GCC compilers that go back to GCC44
  (which is from the same era as NASM 2.07).

Bumping the requirement for NASM to 2.10 is already a bit inconsistent
-- GCC44 should actually be removed with that step (because no released
OS will provide GCC44 together with NASM 2.10). But, requiring NASM 2.10
is not a problem in practice, because no supported OS (to my knowledge)
ships NASM versions smaller than 2.10. So GCC44 would become a
"leftover", but wherever it matters, the tree would build.

However, requiring 2.12 would be much worse; it would render RHEL-7
unsupported as an edk2 build platform, and only because NASM 2.10
doesn't generate cv8 debug info. I have no use for cv8 debug info :)

In my opinion:

* "ability to work with segment registers in 64-bit mode" is a global
  requirement, and it justifies the bump from 2.07 to 2.10;

* "ability to generate cv8 debug info" is a local requirement, and it
   does not justify an unconditional bump from 2.10 to 2.12.

So we should make the directive conditional:
- require NASM 2.10 unconditionally (GNU/Linux distro releases that are
  still supported comply with this easily),
- add a hint that, only for the purposes of CodeView 8 debug info
  generation, NASM 2.12 is required.

Would this work for you?

Thanks!
Laszlo

> *From:*edk2-devel [mailto:edk2-devel-boun...@lists.01.org] *On Behalf Of
> *Laszlo Ersek
> *Sent:* Thursday, July 14, 2016 8:04 PM
> *To:* Gao, Liming ; Justen, Jordan L
> ; Kinney, Michael D 
> *Cc:* edk2-devel-01 
> *Subject:* Re: [edk2] minimum NASM version
> 
>  
> 
> On 07/14/16 13:19, Laszlo Ersek wrote:
> 
>> It seems that before NASM 2.10, there's simply no way to access segment
>> registers in 64-bit mode. I propose that we upgrade the following
>> comment in BaseTools:
>> 
>>> diff --git a/BaseTools/Conf/tools_def.template 
>>> b/BaseTools/Conf/tools_def.template
>>> index 2065fa34998f..db61a37b6afd 100644
>>> --- a/BaseTools/Conf/tools_def.template
>>> +++ b/BaseTools/Conf/tools_def.template
>>> @@ -708,7 +708,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
>>> Files/CodeSourcery/Sourcery G
>>> #
>>> # Other Supported Tools
>>> # =
>>> -# NASM 2.07 or later http://www.nasm.us/
>>> +# NASM 2.10 or later http://www.nasm.us/
>>> #
>>> 
>>> 
>> 
>> plus wherever the minimum NASM version is documented on the Wiki.
> 
> * In support of the above suggestion: in my Fedora 13 guest (set up for
> GCC44 build testing), I could rebuild the following NASM package without
> any problems, from the source RPM:
> 
> nasm-2.10.09-1.fc21
> http://koji.fedoraproject.org/koji/buildinfo?buildID=463939
> 
> With this package installed, the build completed fine.
> 
> * Also in support: the "oldstable" Debian release (code name "wheezy")
> ships nasm 2.10 as well:
> 
> https://packages.debian.org/search?keywords=nasm
> 
> 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/5] MdePkg BaseTools: GCC optimization for X64

[Ard Biesheuvel]

On 14 July 2016 at 16:42, Gao, Liming  wrote:
> Ard:
>   On patch 4, the visibility 'hidden' GCC pragma globally. Does it work 
> together with other mode, such as large? Or it only works with small and pic? 
> I want to clarify this change has no negative impact.

The #if checks for 'defined(__pic__)', which is only true if -fpic is
being passed on the command line. It works fine with other code
models, it only affects the compiler's decision whether to reference
symbols indirectly via the GOT.

>   On patch 5, I don't see any change for IA32 arch. is there no mode for IA32 
> arch? Here, small and pic must be enabled together, right? Otherwise, the 
> assumption is to load driver below 2G address. Have you collected size data 
> before and after this change?
>

To be honest, I know very little about the IA32 ABI, but I don't think
it has different code models, does it? Since the ELF relocations are
stripped by the PE/COFF conversion, I don't think it is necessary to
take into account that X64 and IA32 modules may interact with each
other when running on a X64 platform.

As far as the size is concerned, I get the following results building
DxeCore.efi with GCC47 (under OvmfPkgX64.dsc)

Before:

Section Headers:
  [Nr] Name  Type Address   Offset
   Size  EntSize  Flags  Link  Info  Align
  [ 0]   NULL   
        0 0 0
  [ 1] .text PROGBITS 0240  00c0
   0001e3d0    AX   0 0 32
  [ 2] .rela.textRELA   00029528
   f360  0018   I   6 1 8
  [ 3] .data PROGBITS 0001e620  0001e4a0
   3448    WA   0 0 32
  [ 4] .rela.dataRELA   0003
   1158  0018   I   6 3 8

After:

Section Headers:
  [Nr] Name  Type Address   Offset
   Size  EntSize  Flags  Link  Info  Align
  [ 0]   NULL   
        0 0 0
  [ 1] .text PROGBITS 0240  00c0
   0001a5a0    AX   0 0 32
  [ 2] .rela.textRELA   00025d48
   00010218  0018   I   6 1 8
  [ 3] .data PROGBITS 0001a7e0  0001a660
   3668    WA   0 0 32
  [ 4] .rela.dataRELA   00035f60
   1788  0018   I   6 3 8


So the text section shrinks by 16 KB (13%) in this case, and I got
similar results for other modules.

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

Re: [edk2] minimum NASM version

[Michael Zimmermann]

Hi,

if it would be very important to support that old version of NASM you could
just write "raw" assembler by putting the needed instructions as word's
within the executable code.

changing the min requirement seems more proper though :)

Thanks
Michael

On Thu, Jul 14, 2016 at 4:28 PM, Gao, Liming  wrote:

> Laszlo:
>   Sorry. I didn't mention my version. I use 2.12.01 to verify all changes.
> In 2.12, it adds support of Codeview version 8 (cv8) debug format for win32
> and win64 formats in the COFF backend. We need this feature to get cv8
> debug.  But, this version will report the error message: nasm: fatal:
> assertion !"relocation for unregistered symbol" failed at
> output/codeview.c:420. So, I suggest to update comments to NASM 2.12.01.
>
> Thanks
> Liming
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, July 14, 2016 8:04 PM
> To: Gao, Liming ; Justen, Jordan L <
> jordan.l.jus...@intel.com>; Kinney, Michael D 
> Cc: edk2-devel-01 
> Subject: Re: [edk2] minimum NASM version
>
> On 07/14/16 13:19, Laszlo Ersek wrote:
>
> > It seems that before NASM 2.10, there's simply no way to access segment
> > registers in 64-bit mode. I propose that we upgrade the following
> > comment in BaseTools:
> >
> >> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> >> index 2065fa34998f..db61a37b6afd 100644
> >> --- a/BaseTools/Conf/tools_def.template
> >> +++ b/BaseTools/Conf/tools_def.template
> >> @@ -708,7 +708,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program
> Files/CodeSourcery/Sourcery G
> >> #
> >> # Other Supported Tools
> >> # =
> >> -# NASM 2.07 or later http://www.nasm.us/
> >> +# NASM 2.10 or later http://www.nasm.us/
> >> #
> >>
> 
> >>
> 
> >
> > plus wherever the minimum NASM version is documented on the Wiki.
>
> * In support of the above suggestion: in my Fedora 13 guest (set up for
> GCC44 build testing), I could rebuild the following NASM package without
> any problems, from the source RPM:
>
> nasm-2.10.09-1.fc21
> http://koji.fedoraproject.org/koji/buildinfo?buildID=463939
>
> With this package installed, the build completed fine.
>
> * Also in support: the "oldstable" Debian release (code name "wheezy")
> ships nasm 2.10 as well:
>
> https://packages.debian.org/search?keywords=nasm
>
> Thanks
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Gao, Liming]

Ard:
  On patch 4, the visibility 'hidden' GCC pragma globally. Does it work 
together with other mode, such as large? Or it only works with small and pic? I 
want to clarify this change has no negative impact. 
  On patch 5, I don't see any change for IA32 arch. is there no mode for IA32 
arch? Here, small and pic must be enabled together, right? Otherwise, the 
assumption is to load driver below 2G address. Have you collected size data 
before and after this change?

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, July 14, 2016 9:16 PM
To: Shi, Steven ; Zhu, Yonghong ; 
Gao, Liming ; Kinney, Michael D 
; Justen, Jordan L ; 
ler...@redhat.com; af...@apple.com; edk2-devel@lists.01.org
Cc: Ard Biesheuvel 
Subject: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

This series is not an attempt to steal Steven's thunder. I was merely
inspired by some of the changes he is proposing for GCC 5 and Clang
support, which I noticed would be applicable to older versions of GCC
as well.

The first patch fixes the issue that __builtin_unreachable() is not
implemented by GCC 4.4 or earlier.

Patch #2 is Steven's patch to switch to the flavor of VA_LIST that is
explicitly modeled after the MS implementation. This by itself is an
improvement, since the open coded implementation that performs arithmetic
on the address of explicit arguments to obtain the variadic arguments is
fragile and difficult to maintain, and should be best avoided.

Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to GCC44.
I tested this change with both Ovmf and EmulatorPkg built in various ways
and with various versions, with the caveat that I did not always use a matching
binutils (i.e., of the same era). Since the issues this series deal with are
all code generation issues, I think this is reasonable, but more testing would
be appreciated.

Patch #4 applies the visibility 'hidden' GCC pragma globally. Please refer to
the commit log for the motivation.

Patch #5 switches GCC/X64 to the PIC small code model, which results in smaller
code.

Ard Biesheuvel (4):
  MdePkg: avoid __builtin_unreachable() on GCC v4.4
  BaseTools/tools_def: enable O2 optimization for GCC X64 builds
  MdePkg X64: force 'hidden' visibility when building with -fpic
  BaseTools/tools_def: switch GCC/X64 to the PIC small model

Shi, Steven (1):
  MdePkg: Enable new MS VA intrinsics for GNUC x86 64bits build

 BaseTools/Conf/tools_def.template  | 18 +++-
 MdePkg/Include/Base.h  | 29 +++-
 MdePkg/Include/X64/ProcessorBind.h | 10 +++
 3 files changed, 49 insertions(+), 8 deletions(-)
 mode change 100644 => 100755 MdePkg/Include/Base.h

-- 
2.7.4

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

Re: [edk2] [PATCHv4 2/2] ArmJuno: Correct AXI->PCIe translation comments

[Leif Lindholm]

On Thu, Jul 14, 2016 at 09:19:09AM -0500, Jeremy Linton wrote:
> On 07/14/2016 09:16 AM, Ard Biesheuvel wrote:
> >On 14 July 2016 at 15:58, Jeremy Linton  wrote:
> >>The AXI<->PCIe translation comments are out of date with
> >>respect to the code. In the first case the AXI master port
> >>is incorrectly called a slave. In the second case the the
> >>translation direction indicated for the slave port is the
> >>wrong direction.
> >>
> >>Correct both of these comments to reflect what the code is
> >>doing.
> >>
> >>Contributed-under: TianoCore Contribution Agreement 1.0
> >>Signed-off-by: Jeremy Linton 
> >>---
> >>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git 
> >>a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
> >>b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
> >>index 0c7881d..d134cc4 100644
> >>--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
> >>+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
> >>@@ -84,7 +84,7 @@ HWPciRbInit (
> >>PCIE_ROOTPORT_WRITE32 (PCIE_PCI_IDS + PCIE_PCI_IDS_CLASSCODE_OFFSET, 
> >> ((PLDA_BRIDGE_CCR << 8) | PCI_BRIDGE_REVISION_ID));
> >>
> >>//
> >>-  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
> >>+  // PCIE Window 0 -> AXI4 Master 0 Address Translations
> >>//
> >>TranslationTable = VEXPRESS_ATR_PCIE_WIN0;
> >>
> >>@@ -101,7 +101,7 @@ HWPciRbInit (
> >>ARM_JUNO_EXTRA_SYSTEM_MEMORY_SZ, PCI_ATR_TRSLID_AXIMEMORY);
> >>
> >>//
> >>-  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
> >>+  // AXI4 Slave 0 -> PCIE Window 0 Address Translations
> >>//
> >>TranslationTable = VEXPRESS_ATR_AXI4_SLV1;
> >>
> >
> >Slave 0 or slave 1?
> Slave 1,
> I actually was just talking to Leif about tweaking it before committing it.

Fixed and series pushed, thanks.

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

Re: [edk2] minimum NASM version

[Gao, Liming]

Laszlo:
  Sorry. I didn't mention my version. I use 2.12.01 to verify all changes. In 
2.12, it adds support of Codeview version 8 (cv8) debug format for win32 and 
win64 formats in the COFF backend. We need this feature to get cv8 debug.  But, 
this version will report the error message: nasm: fatal: assertion !"relocation 
for unregistered symbol" failed at output/codeview.c:420. So, I suggest to 
update comments to NASM 2.12.01.

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Thursday, July 14, 2016 8:04 PM
To: Gao, Liming ; Justen, Jordan L 
; Kinney, Michael D 
Cc: edk2-devel-01 
Subject: Re: [edk2] minimum NASM version

On 07/14/16 13:19, Laszlo Ersek wrote:

> It seems that before NASM 2.10, there's simply no way to access segment
> registers in 64-bit mode. I propose that we upgrade the following
> comment in BaseTools:
>
>> diff --git a/BaseTools/Conf/tools_def.template 
>> b/BaseTools/Conf/tools_def.template
>> index 2065fa34998f..db61a37b6afd 100644
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -708,7 +708,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
>> Files/CodeSourcery/Sourcery G
>> #
>> # Other Supported Tools
>> # =
>> -# NASM 2.07 or later http://www.nasm.us/
>> +# NASM 2.10 or later http://www.nasm.us/
>> #
>> 
>> 
>
> plus wherever the minimum NASM version is documented on the Wiki.

* In support of the above suggestion: in my Fedora 13 guest (set up for
GCC44 build testing), I could rebuild the following NASM package without
any problems, from the source RPM:

nasm-2.10.09-1.fc21
http://koji.fedoraproject.org/koji/buildinfo?buildID=463939

With this package installed, the build completed fine.

* Also in support: the "oldstable" Debian release (code name "wheezy")
ships nasm 2.10 as well:

https://packages.debian.org/search?keywords=nasm

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] [PATCHv4 2/2] ArmJuno: Correct AXI->PCIe translation comments

[Jeremy Linton]

On 07/14/2016 09:16 AM, Ard Biesheuvel wrote:

On 14 July 2016 at 15:58, Jeremy Linton  wrote:

The AXI<->PCIe translation comments are out of date with
respect to the code. In the first case the AXI master port
is incorrectly called a slave. In the second case the the
translation direction indicated for the slave port is the
wrong direction.

Correct both of these comments to reflect what the code is
doing.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
index 0c7881d..d134cc4 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
@@ -84,7 +84,7 @@ HWPciRbInit (
PCIE_ROOTPORT_WRITE32 (PCIE_PCI_IDS + PCIE_PCI_IDS_CLASSCODE_OFFSET, 
((PLDA_BRIDGE_CCR << 8) | PCI_BRIDGE_REVISION_ID));

//
-  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
+  // PCIE Window 0 -> AXI4 Master 0 Address Translations
//
TranslationTable = VEXPRESS_ATR_PCIE_WIN0;

@@ -101,7 +101,7 @@ HWPciRbInit (
ARM_JUNO_EXTRA_SYSTEM_MEMORY_SZ, PCI_ATR_TRSLID_AXIMEMORY);

//
-  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
+  // AXI4 Slave 0 -> PCIE Window 0 Address Translations
//
TranslationTable = VEXPRESS_ATR_AXI4_SLV1;



Slave 0 or slave 1?

Slave 1,
I actually was just talking to Leif about tweaking it before committing it.


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

Re: [edk2] [PATCHv4 2/2] ArmJuno: Correct AXI->PCIe translation comments

[Ard Biesheuvel]

On 14 July 2016 at 15:58, Jeremy Linton  wrote:
> The AXI<->PCIe translation comments are out of date with
> respect to the code. In the first case the AXI master port
> is incorrectly called a slave. In the second case the the
> translation direction indicated for the slave port is the
> wrong direction.
>
> Correct both of these comments to reflect what the code is
> doing.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeremy Linton 
> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
> index 0c7881d..d134cc4 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
> @@ -84,7 +84,7 @@ HWPciRbInit (
>PCIE_ROOTPORT_WRITE32 (PCIE_PCI_IDS + PCIE_PCI_IDS_CLASSCODE_OFFSET, 
> ((PLDA_BRIDGE_CCR << 8) | PCI_BRIDGE_REVISION_ID));
>
>//
> -  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
> +  // PCIE Window 0 -> AXI4 Master 0 Address Translations
>//
>TranslationTable = VEXPRESS_ATR_PCIE_WIN0;
>
> @@ -101,7 +101,7 @@ HWPciRbInit (
>ARM_JUNO_EXTRA_SYSTEM_MEMORY_SZ, PCI_ATR_TRSLID_AXIMEMORY);
>
>//
> -  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
> +  // AXI4 Slave 0 -> PCIE Window 0 Address Translations
>//
>TranslationTable = VEXPRESS_ATR_AXI4_SLV1;
>

Slave 0 or slave 1?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCHv4 0/2] ArmJuno: Correct AXI<->PCI translations

[Jeremy Linton]

The PCIe PIO translation is incorrect on the Juno, correct that.
While we are updating that module correct the comments to more
accurately reflect the code and what is actually happening.

Jeremy Linton (2):
  ArmJuno: fix Juno PIO host bridge mapping
  ArmJuno: Correct AXI->PCIe translation comments

 .../ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c   | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

-- 
2.4.11

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

Re: [edk2] PCI performance issue

[Cohen, Eugene]

I've been down this road before...

Network performance (on non-coherent DMA architectures) can be affected by:

1. Excessive double buffering caused by unaligned buffers (PCI BusMasterRead / 
BusMasterWrite cases)
2. Excessive accesses to uncached buffers (like PCI common buffer cases)
3. Packet loss due to the lack of interrupts in UEFI, I mean, due to a network 
polling rate that is too slow (look at the MNP poll and UEFI tick periods)

You should be able to get far better performance than 3MB/min!

Eugene

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Shaveta Leekha
> Sent: Thursday, July 14, 2016 7:45 AM
> To: Ard Biesheuvel 
> Cc: edk2-devel@lists.01.org; Linaro UEFI Mailman List  u...@lists.linaro.org>
> Subject: Re: [edk2] PCI performance issue
> 
> Ok, I can try that !!
> 
> Thanks and Regards,
> Shaveta
> 
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, July 14, 2016 7:11 PM
> To: Shaveta Leekha 
> Cc: edk2-devel@lists.01.org; Linaro UEFI Mailman List  u...@lists.linaro.org>
> Subject: Re: PCI performance issue
> 
> On 14 July 2016 at 15:29, Shaveta Leekha  wrote:
> > But I have not tested the code (software) on any other hardware/board.
> > As I have not yet ported PCI code on any other board yet.
> >
> 
> I would recommend to base your expectations not on U-Boot but on UEFI
> running on a different architecture using similar network hardware.
> ___
> 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] [PATCHv4 0/2] ArmJuno: Correct AXI<->PCI translations

[Ryan Harkin]

On 14 July 2016 at 15:09, Leif Lindholm  wrote:
> Thanks Jeremy.
>
> If Ryan's happy with this change, I'm happy to push it.
>

Yep, fine.  I tested v3 (I think) and it worked fine.


> Regards,
>
> Leif
>
> On 14 July 2016 at 14:58, Jeremy Linton  wrote:
>> The PCIe PIO translation is incorrect on the Juno, correct that.
>> While we are updating that module correct the comments to more
>> accurately reflect the code and what is actually happening.
>>
>> Jeremy Linton (2):
>>   ArmJuno: fix Juno PIO host bridge mapping
>>   ArmJuno: Correct AXI->PCIe translation comments
>>
>>  .../ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c   | 13 
>> -
>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> --
>> 2.4.11
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCHv4 0/2] ArmJuno: Correct AXI<->PCI translations

[Leif Lindholm]

Thanks Jeremy.

If Ryan's happy with this change, I'm happy to push it.

Regards,

Leif

On 14 July 2016 at 14:58, Jeremy Linton  wrote:
> The PCIe PIO translation is incorrect on the Juno, correct that.
> While we are updating that module correct the comments to more
> accurately reflect the code and what is actually happening.
>
> Jeremy Linton (2):
>   ArmJuno: fix Juno PIO host bridge mapping
>   ArmJuno: Correct AXI->PCIe translation comments
>
>  .../ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c   | 13 
> -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> --
> 2.4.11
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/2] Fix bug in TCP which not sending out ACK

[Cohen, Eugene]

Series Reviewed-By: Eugene Cohen 

Thank you for your ongoing help with our TCP issues, it is much appreciated.

Eugene

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wu, Jiaxin
> Sent: Tuesday, July 12, 2016 8:12 PM
> To: Fu, Siyuan ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch 0/2] Fix bug in TCP which not sending out ACK
> 
> Series Reviewed-By: Wu Jiaxin 
> 
> Best Regards!
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Fu Siyuan
> > Sent: Tuesday, July 12, 2016 9:50 AM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [Patch 0/2] Fix bug in TCP which not sending out ACK
> >
> > Consider the situation as shown in below chart. The last ACK message
> > has acknowledged the Tcb->RcvWl2, and all the segments until
> > Tcb->RcvNxt have been received by TCP driver. The Tcb->RcvNxt is not
> > acknowledged due to the delayed ACK. In this case an incoming segment
> > (Seg->Seq, Seg->End) should not be accepted by TCP driver, and an
> immediate ACK is required.
> >
> > Current TcpSeqAcceptable() thought it  s an acceptable segment
> > incorrectly, it continues the TcpInput() process instead of sending
> > out an ACK and droping the segment immediately.
> >
> > Tcb->RcvWl2   Tcb->RcvNxtTcb->RcvWl2 + 
> > Tcb->RcvWnd
> > Seg->Seq   Seg->End |  |
> > | |   | |  |
> >  
> > ---+-+---+-+--+---
> > 
> >
> > Fu Siyuan (2):
> >   NetworkPkg: Fix bug in TCP which not sending out ACK in certain
> > circumstance.
> >   MdeModulePkg: Fix bug in TCP which not sending out ACK in certain
> > circumstance.
> >
> >  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Input.c | 2 +-
> >  NetworkPkg/TcpDxe/TcpInput.c   | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > --
> > 2.7.4.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCHv4 2/2] ArmJuno: Correct AXI->PCIe translation comments

[Jeremy Linton]

The AXI<->PCIe translation comments are out of date with
respect to the code. In the first case the AXI master port
is incorrectly called a slave. In the second case the the
translation direction indicated for the slave port is the
wrong direction.

Correct both of these comments to reflect what the code is
doing.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
index 0c7881d..d134cc4 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
@@ -84,7 +84,7 @@ HWPciRbInit (
   PCIE_ROOTPORT_WRITE32 (PCIE_PCI_IDS + PCIE_PCI_IDS_CLASSCODE_OFFSET, 
((PLDA_BRIDGE_CCR << 8) | PCI_BRIDGE_REVISION_ID));
 
   //
-  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
+  // PCIE Window 0 -> AXI4 Master 0 Address Translations
   //
   TranslationTable = VEXPRESS_ATR_PCIE_WIN0;
 
@@ -101,7 +101,7 @@ HWPciRbInit (
   ARM_JUNO_EXTRA_SYSTEM_MEMORY_SZ, PCI_ATR_TRSLID_AXIMEMORY);
 
   //
-  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
+  // AXI4 Slave 0 -> PCIE Window 0 Address Translations
   //
   TranslationTable = VEXPRESS_ATR_AXI4_SLV1;
 
-- 
2.4.11

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

[edk2] [PATCHv4 1/2] ArmJuno: fix Juno PIO host bridge mapping

[Jeremy Linton]

The Juno PIO mapping is 8M, so it should be using a 32-bit
PIO address translation. Further, PIO addresses should start
at 0 and be translated to/from the ARM MMIO region.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
Reviewed-by: Leif Lindholm 
---
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
index 06de6d5..0c7881d 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
@@ -72,7 +72,9 @@ HWPciRbInit (
 
   PCI_TRACE ("PCIe Setting up Address Translation");
 
-  PCIE_ROOTPORT_WRITE32 (PCIE_BAR_WIN, PCIE_BAR_WIN_SUPPORT_IO | 
PCIE_BAR_WIN_SUPPORT_MEM | PCIE_BAR_WIN_SUPPORT_MEM64);
+  // The Juno PIO window is 8M, so we need full 32-bit PIO decoding.
+  PCIE_ROOTPORT_WRITE32 (PCIE_BAR_WIN, PCIE_BAR_WIN_SUPPORT_IO | 
PCIE_BAR_WIN_SUPPORT_IO32 |
+ PCIE_BAR_WIN_SUPPORT_MEM | 
PCIE_BAR_WIN_SUPPORT_MEM64);
 
   // Setup the PCI Configuration Registers
   // Offset 0a: SubClass   04 PCI-PCI Bridge
@@ -107,8 +109,9 @@ HWPciRbInit (
   SetTranslationAddressEntry (CpuIo, TranslationTable, PCI_ECAM_BASE, 
PCI_ECAM_BASE, PCI_ECAM_SIZE, PCI_ATR_TRSLID_PCIE_CONF);
   TranslationTable += PCI_ATR_ENTRY_SIZE;
 
-  // PCI IO Support
-  SetTranslationAddressEntry (CpuIo, TranslationTable, PCI_IO_BASE, 
PCI_IO_BASE, PCI_IO_SIZE, PCI_ATR_TRSLID_PCIE_IO);
+  // PCI IO Support, the PIO space is translated from the arm MMIO PCI_IO_BASE 
address to the PIO base address of 0
+  // AKA, PIO addresses used by endpoints are generally in the range of 0-64K. 
+  SetTranslationAddressEntry (CpuIo, TranslationTable, PCI_IO_BASE, 0, 
PCI_IO_SIZE, PCI_ATR_TRSLID_PCIE_IO);
   TranslationTable += PCI_ATR_ENTRY_SIZE;
 
   // PCI MEM32 Support
-- 
2.4.11

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

Re: [edk2] PCI performance issue

[Shaveta Leekha]

Ok, I can try that !!

Thanks and Regards,
Shaveta

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Thursday, July 14, 2016 7:11 PM
To: Shaveta Leekha 
Cc: edk2-devel@lists.01.org; Linaro UEFI Mailman List 

Subject: Re: PCI performance issue

On 14 July 2016 at 15:29, Shaveta Leekha  wrote:
> But I have not tested the code (software) on any other hardware/board.
> As I have not yet ported PCI code on any other board yet.
>

I would recommend to base your expectations not on U-Boot but on UEFI running 
on a different architecture using similar network hardware.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] PCI performance issue

[Ard Biesheuvel]

On 14 July 2016 at 15:29, Shaveta Leekha  wrote:
> But I have not tested the code (software) on any other hardware/board.
> As I have not yet ported PCI code on any other board yet.
>

I would recommend to base your expectations not on U-Boot but on UEFI
running on a different architecture using similar network hardware.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] PCI performance issue

[Shaveta Leekha]

But I have not tested the code (software) on any other hardware/board.
As I have not yet ported PCI code on any other board yet.

Regards,
Shaveta


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Shaveta 
Leekha
Sent: Thursday, July 14, 2016 6:57 PM
To: Ard Biesheuvel 
Cc: edk2-devel@lists.01.org; Linaro UEFI Mailman List 

Subject: Re: [edk2] PCI performance issue

Hi Ard,

Tftp have been tested on u-boot and Linux on same platform/board (the hardware 
on which tftp is tested on UEFI)

And it takes around 1 min(or even lesser) in getting this big file (initrd 
image : around 30MB) over PCI using Tftp.

So the issue is not with hardware, its somewhere in (PCI + Network stack over 
it + E1000 card driver + Tftp implementation) in UEFI.

So not yet able to figure out !! 

Thanks and Regards,
Shaveta

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, July 14, 2016 6:52 PM
To: Shaveta Leekha 
Cc: edk2-devel@lists.01.org; Linaro UEFI Mailman List 

Subject: Re: PCI performance issue

On 14 July 2016 at 15:05, Shaveta Leekha  wrote:
> Hi,
>
>
>
>
>
> I have been working on PCI controller driver performance (Root Bridge) 
> for my ARMv8 platform. I had integrated my PciHostBridgeDxe code with 
> MdeModulePkg/Bus/Pci/PciBusDxe. Have followed PCI Host bridge resource 
> allocation and Root bridge IO protocol, as used in some other existing 
> PCI root bridge driver.
>
>
>
> My concern here is that:
>
>
>
> Tftp using PCI interface is painfully slow. It takes around 10 mins to 
> transfer a 30MB file over PCI NIC card using Tftp
>

How much time does it take on other hardware? Did you try it on your PC?
___
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] PCI performance issue

[Shaveta Leekha]

Hi Ard,

Tftp have been tested on u-boot and Linux on same platform/board (the hardware 
on which tftp is tested on UEFI)

And it takes around 1 min(or even lesser) in getting this big file (initrd 
image : around 30MB) over PCI using Tftp.

So the issue is not with hardware, its somewhere in (PCI + Network stack over 
it + E1000 card driver + Tftp implementation) in UEFI.

So not yet able to figure out !! 

Thanks and Regards,
Shaveta

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Thursday, July 14, 2016 6:52 PM
To: Shaveta Leekha 
Cc: edk2-devel@lists.01.org; Linaro UEFI Mailman List 

Subject: Re: PCI performance issue

On 14 July 2016 at 15:05, Shaveta Leekha  wrote:
> Hi,
>
>
>
>
>
> I have been working on PCI controller driver performance (Root Bridge) 
> for my ARMv8 platform. I had integrated my PciHostBridgeDxe code with 
> MdeModulePkg/Bus/Pci/PciBusDxe. Have followed PCI Host bridge resource 
> allocation and Root bridge IO protocol, as used in some other existing 
> PCI root bridge driver.
>
>
>
> My concern here is that:
>
>
>
> Tftp using PCI interface is painfully slow. It takes around 10 mins to 
> transfer a 30MB file over PCI NIC card using Tftp
>

How much time does it take on other hardware? Did you try it on your PC?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/5] MdePkg: Enable new MS VA intrinsics for GNUC x86 64bits build

[Ard Biesheuvel]

From: "Shi, Steven" 

Both GCC and LLVM 3.8 64bits support new variable argument (VA)
intrinsics for Microsoft ABI, enable these new VA intrinsics for
GNUC family 64bits code build. These VA intrinsics are only
permitted use in 64bits code, so not use them in 32bits code build.
The original 32bits GNU VA intrinsics has the same calling convention
as MS, so we don't need change them.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi 

[ardb: update CPP logic so that the change only applies to X64]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 MdePkg/Include/Base.h | 26 
 1 file changed, 26 insertions(+)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
old mode 100644
new mode 100755
index 7dbf9386b6b4..876d4a34262e
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -590,6 +590,30 @@ struct _LIST_ENTRY {
 #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
 
 #elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
+
+#ifdef MDE_CPU_X64
+//
+// X64 only. Use MS ABI version of GCC built-in macros for variable argument 
lists.
+//
+///
+/// Both GCC and LLVM 3.8 for X64 support new variable argument intrinsics for 
Microsoft ABI
+///
+
+///
+/// Variable used to traverse the list of arguments. This type can vary by
+/// implementation and could be an array or structure.
+///
+typedef __builtin_ms_va_list VA_LIST;
+
+#define VA_START(Marker, Parameter)  __builtin_ms_va_start (Marker, Parameter)
+
+#define VA_ARG(Marker, TYPE) ((sizeof (TYPE) < sizeof (UINTN)) ? 
(TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg (Marker, 
TYPE)))
+
+#define VA_END(Marker)   __builtin_ms_va_end (Marker)
+
+#define VA_COPY(Dest, Start) __builtin_ms_va_copy (Dest, Start)
+
+#else
 //
 // Use GCC built-in macros for variable argument lists.
 //
@@ -608,6 +632,8 @@ typedef __builtin_va_list VA_LIST;
 
 #define VA_COPY(Dest, Start) __builtin_va_copy (Dest, Start)
 
+#endif
+
 #else
 ///
 /// Variable used to traverse the list of arguments. This type can vary by
-- 
2.7.4

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

Re: [edk2] PCI performance issue

[Ard Biesheuvel]

On 14 July 2016 at 15:05, Shaveta Leekha  wrote:
> Hi,
>
>
>
>
>
> I have been working on PCI controller driver performance (Root Bridge) for
> my ARMv8 platform. I had integrated my PciHostBridgeDxe code with
> MdeModulePkg/Bus/Pci/PciBusDxe. Have followed PCI Host bridge resource
> allocation and Root bridge IO protocol, as used in some other existing PCI
> root bridge driver.
>
>
>
> My concern here is that:
>
>
>
> Tftp using PCI interface is painfully slow. It takes around 10 mins to
> transfer a 30MB file over PCI NIC card using Tftp
>

How much time does it take on other hardware? Did you try it on your PC?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Ard Biesheuvel]

On 14 July 2016 at 15:16, Ard Biesheuvel  wrote:
> This series is not an attempt to steal Steven's thunder. I was merely
> inspired by some of the changes he is proposing for GCC 5 and Clang
> support, which I noticed would be applicable to older versions of GCC
> as well.
>
> The first patch fixes the issue that __builtin_unreachable() is not
> implemented by GCC 4.4 or earlier.
>
> Patch #2 is Steven's patch to switch to the flavor of VA_LIST that is
> explicitly modeled after the MS implementation. This by itself is an
> improvement, since the open coded implementation that performs arithmetic
> on the address of explicit arguments to obtain the variadic arguments is
> fragile and difficult to maintain, and should be best avoided.
>
> Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to GCC44.
> I tested this change with both Ovmf and EmulatorPkg built in various ways
> and with various versions, with the caveat that I did not always use a 
> matching
> binutils (i.e., of the same era). Since the issues this series deal with are
> all code generation issues, I think this is reasonable, but more testing would
> be appreciated.
>
> Patch #4 applies the visibility 'hidden' GCC pragma globally. Please refer to
> the commit log for the motivation.
>
> Patch #5 switches GCC/X64 to the PIC small code model, which results in 
> smaller
> code.
>

Code can be found here
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/gcc-x64-opt
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/5] MdePkg: avoid __builtin_unreachable() on GCC v4.4

[Ard Biesheuvel]

GCC v4.4 does not implement __builtin_unreachable(), so avoid using
it when building with this version or earlier.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 MdePkg/Include/Base.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index 858385828d93..7dbf9386b6b4 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -89,10 +89,11 @@ VERIFY_SIZE_OF (CHAR16, 2);
 // warnings.
 //
 #ifndef UNREACHABLE
-  #ifdef __GNUC__
+  #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4)
 ///
 /// Signal compilers and analyzers that this call is not reachable.  It is
 /// up to the compiler to remove any code past that point.
+/// Not implemented by GCC 4.4 or earlier.
 ///
 #define UNREACHABLE()  __builtin_unreachable ()
   #elif defined (__has_feature)
-- 
2.7.4

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

[edk2] [PATCH 5/5] BaseTools/tools_def: switch GCC/X64 to the PIC small model

[Ard Biesheuvel]

The ordinary small code model for x86_64 cannot be used in UEFI, since
it assumes the executable is loaded in the first 2 GB of memory.
Therefore, we use the large model instead, which can execute anywhere,
but uses absolute 64-bit wide quantities for all symbol references,
which is costly in terms of code size.

So switch to the PIC small code model, this uses 32-bit relative
references where possible, but does not make any assumptions about the
load address (i.e., all absolute symbol references are 64-bits wide).
Note that, due to the 'hidden' visibility pragma introduced in an
earlier patch, there is no need for the EDK2 build system to deal with
GOT related ELF relocation types.

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

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 3bff65b862a2..529a29402968 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4353,7 +4353,7 @@ DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O 
elf64-littleaarch64 -B aarch64
 
 DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c -include 
AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
-march=i586 -malign-double -fno-stack-protector -D EFI32 
-fno-asynchronous-unwind-tables
-DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone 
-Wno-address -mcmodel=large -fno-asynchronous-unwind-tables
+DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone 
-Wno-address -mcmodel=small -fpic -fno-asynchronous-unwind-tables
 DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
common-page-size=0x20
 DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
--entry ReferenceAcpiTable -u ReferenceAcpiTable
 DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
--entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
-- 
2.7.4

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

[edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Ard Biesheuvel]

This series is not an attempt to steal Steven's thunder. I was merely
inspired by some of the changes he is proposing for GCC 5 and Clang
support, which I noticed would be applicable to older versions of GCC
as well.

The first patch fixes the issue that __builtin_unreachable() is not
implemented by GCC 4.4 or earlier.

Patch #2 is Steven's patch to switch to the flavor of VA_LIST that is
explicitly modeled after the MS implementation. This by itself is an
improvement, since the open coded implementation that performs arithmetic
on the address of explicit arguments to obtain the variadic arguments is
fragile and difficult to maintain, and should be best avoided.

Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to GCC44.
I tested this change with both Ovmf and EmulatorPkg built in various ways
and with various versions, with the caveat that I did not always use a matching
binutils (i.e., of the same era). Since the issues this series deal with are
all code generation issues, I think this is reasonable, but more testing would
be appreciated.

Patch #4 applies the visibility 'hidden' GCC pragma globally. Please refer to
the commit log for the motivation.

Patch #5 switches GCC/X64 to the PIC small code model, which results in smaller
code.

Ard Biesheuvel (4):
  MdePkg: avoid __builtin_unreachable() on GCC v4.4
  BaseTools/tools_def: enable O2 optimization for GCC X64 builds
  MdePkg X64: force 'hidden' visibility when building with -fpic
  BaseTools/tools_def: switch GCC/X64 to the PIC small model

Shi, Steven (1):
  MdePkg: Enable new MS VA intrinsics for GNUC x86 64bits build

 BaseTools/Conf/tools_def.template  | 18 +++-
 MdePkg/Include/Base.h  | 29 +++-
 MdePkg/Include/X64/ProcessorBind.h | 10 +++
 3 files changed, 49 insertions(+), 8 deletions(-)
 mode change 100644 => 100755 MdePkg/Include/Base.h

-- 
2.7.4

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

[edk2] [PATCH 3/5] BaseTools/tools_def: enable O2 optimization for GCC X64 builds

[Ard Biesheuvel]

Now that we switched to the __builtin_ms_va_list VA_LIST type for
GCC/X64, we can trust the compiler to do the right thing even under
optimization, and so we can enable -O2 optimization all the way back
to GCC44.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 BaseTools/Conf/tools_def.template | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 2065fa34998f..3bff65b862a2 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4353,7 +4353,7 @@ DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O 
elf64-littleaarch64 -B aarch64
 
 DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c -include 
AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
-march=i586 -malign-double -fno-stack-protector -D EFI32 
-fno-asynchronous-unwind-tables
-DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS 
-mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables
+DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone 
-Wno-address -mcmodel=large -fno-asynchronous-unwind-tables
 DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
common-page-size=0x20
 DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
--entry ReferenceAcpiTable -u ReferenceAcpiTable
 DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
--entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
@@ -4601,13 +4601,15 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = 
DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 *_GCC44_X64_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m64
 *_GCC44_X64_ASLDLINK_FLAGS   = DEF(GCC44_IA32_X64_ASLDLINK_FLAGS) -m 
elf_x86_64
 *_GCC44_X64_ASM_FLAGS= DEF(GCC44_ASM_FLAGS) -m64 --64 -melf_x86_64
-*_GCC44_X64_CC_FLAGS = DEF(GCC44_X64_CC_FLAGS)
 *_GCC44_X64_DLINK_FLAGS  = DEF(GCC44_X64_DLINK_FLAGS)
 *_GCC44_X64_DLINK2_FLAGS = DEF(GCC44_X64_DLINK2_FLAGS)
 *_GCC44_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS)
 *_GCC44_X64_OBJCOPY_FLAGS= 
 *_GCC44_X64_NASM_FLAGS   = -f elf64
 
+  DEBUG_GCC44_X64_CC_FLAGS   = DEF(GCC44_X64_CC_FLAGS)
+RELEASE_GCC44_X64_CC_FLAGS   = DEF(GCC44_X64_CC_FLAGS) -O2
+
 

 #
 # GCC 4.5 - This configuration is used to compile under Linux to produce
@@ -4671,13 +4673,15 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = 
DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 *_GCC45_X64_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m64
 *_GCC45_X64_ASLDLINK_FLAGS   = DEF(GCC45_IA32_X64_ASLDLINK_FLAGS) -m 
elf_x86_64
 *_GCC45_X64_ASM_FLAGS= DEF(GCC45_ASM_FLAGS) -m64 --64 -melf_x86_64
-*_GCC45_X64_CC_FLAGS = DEF(GCC45_X64_CC_FLAGS)
 *_GCC45_X64_DLINK_FLAGS  = DEF(GCC45_X64_DLINK_FLAGS)
 *_GCC45_X64_DLINK2_FLAGS = DEF(GCC45_X64_DLINK2_FLAGS)
 *_GCC45_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS)
 *_GCC45_X64_OBJCOPY_FLAGS= 
 *_GCC45_X64_NASM_FLAGS   = -f elf64
 
+  DEBUG_GCC45_X64_CC_FLAGS   = DEF(GCC45_X64_CC_FLAGS)
+RELEASE_GCC45_X64_CC_FLAGS   = DEF(GCC45_X64_CC_FLAGS) -O2
+
 

 #
 # GCC 4.6 - This configuration is used to compile under Linux to produce
@@ -4750,7 +4754,7 @@ RELEASE_GCC46_IA32_CC_FLAGS   = 
DEF(GCC46_IA32_CC_FLAGS) -Os -Wno-unused-but
 *_GCC46_X64_NASM_FLAGS   = -f elf64
 
   DEBUG_GCC46_X64_CC_FLAGS   = DEF(GCC46_X64_CC_FLAGS)
-RELEASE_GCC46_X64_CC_FLAGS   = DEF(GCC46_X64_CC_FLAGS) 
-Wno-unused-but-set-variable
+RELEASE_GCC46_X64_CC_FLAGS   = DEF(GCC46_X64_CC_FLAGS) -O2 
-Wno-unused-but-set-variable
 
 ##
 # GCC46 ARM definitions
@@ -4855,7 +4859,7 @@ RELEASE_GCC47_IA32_CC_FLAGS   = 
DEF(GCC47_IA32_CC_FLAGS) -Os -Wno-unused-but
 *_GCC47_X64_NASM_FLAGS   = -f elf64
 
   DEBUG_GCC47_X64_CC_FLAGS   = DEF(GCC47_X64_CC_FLAGS)
-RELEASE_GCC47_X64_CC_FLAGS   = DEF(GCC47_X64_CC_FLAGS) 
-Wno-unused-but-set-variable
+RELEASE_GCC47_X64_CC_FLAGS   = DEF(GCC47_X64_CC_FLAGS) -O2 
-Wno-unused-but-set-variable
 
 ##
 # GCC47 ARM definitions
@@ -4987,7 +4991,7 @@ RELEASE_GCC48_IA32_CC_FLAGS   = 
DEF(GCC48_IA32_CC_FLAGS) -Os -Wno-unused-but
 *_GCC48_X64_NASM_FLAGS   = -f elf64
 
   DEBUG_GCC48_X64_CC_FLAGS   = DEF(GCC48_X64_CC_FLAGS)
-RELEASE_GCC48_X64_CC_FLAGS   = DEF(GCC48_X64_CC_FLAGS) 

[edk2] PCI performance issue

[Shaveta Leekha]

Hi,





I have been working on PCI controller driver performance (Root Bridge) for my 
ARMv8 platform. I had integrated my PciHostBridgeDxe code with 
MdeModulePkg/Bus/Pci/PciBusDxe. Have followed PCI Host bridge resource 
allocation and Root bridge IO protocol, as used in some other existing PCI root 
bridge driver.



My concern here is that:



Tftp using PCI interface is painfully slow. It takes around 10 mins to transfer 
a 30MB file over PCI NIC card using Tftp



Has anyone observed the slowness in network transfer using PCI interface?



I couldn't figure out any bottlenecks in PCI root bridge driver( it uses 
ArmDmaLib for Allocate, Free, Map and UnMap) nor does PCIBUS driver seems to 
have.



Can the slowness be Network stack (like SNP, MNP and other protocols) or E1000 
driver code or TFTP command code?



Any pointer for the same would be really helpful!!





Thanks in advance for your time!





Best regards,



Shaveta

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

Re: [edk2] minimum NASM version

[Laszlo Ersek]

On 07/14/16 13:19, Laszlo Ersek wrote:

> It seems that before NASM 2.10, there's simply no way to access segment
> registers in 64-bit mode. I propose that we upgrade the following
> comment in BaseTools:
> 
>> diff --git a/BaseTools/Conf/tools_def.template 
>> b/BaseTools/Conf/tools_def.template
>> index 2065fa34998f..db61a37b6afd 100644
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -708,7 +708,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
>> Files/CodeSourcery/Sourcery G
>>  #
>>  # Other Supported Tools
>>  # =
>> -#   NASM 2.07 or later http://www.nasm.us/
>> +#   NASM 2.10 or later http://www.nasm.us/
>>  #
>>  
>> 
>>  
>> 
> 
> plus wherever the minimum NASM version is documented on the Wiki.

* In support of the above suggestion: in my Fedora 13 guest (set up for
GCC44 build testing), I could rebuild the following NASM package without
any problems, from the source RPM:

  nasm-2.10.09-1.fc21
  http://koji.fedoraproject.org/koji/buildinfo?buildID=463939

With this package installed, the build completed fine.

* Also in support: the "oldstable" Debian release (code name "wheezy")
ships nasm 2.10 as well:

  https://packages.debian.org/search?keywords=nasm

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

[edk2] minimum NASM version

[Laszlo Ersek]

Hi,

yesterday I set up a VS2015x86 toolchain for test-building OVMF. I also
resurrected my Fedora virtual machines that are dedicated to
test-building OVMF with GCC44-GCC49 toolchains.

I've found some C language build errors already, and I'm progressing
through them slowly. However, one "killer" problem is the following NASM
failure (emitted by nasm-2.07-4.fc13.x86_64; that is, in my Fedora 13
guest):

> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:173:
>  error: invalid combination of opcode and operands
> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:175:
>  error: invalid combination of opcode and operands
> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:177:
>  error: invalid combination of opcode and operands
> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:179:
>  error: invalid combination of opcode and operands
> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:313:
>  error: invalid combination of opcode and operands
> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:315:
>  error: invalid combination of opcode and operands

This is the code in question:

   168  ;; UINT64  Gs, Fs, Es, Ds, Cs, Ss;  insure high 16 bits of each is zero
   169  movzx   rax, word [rbp + 56]
   170  pushrax  ; for ss
   171  movzx   rax, word [rbp + 32]
   172  pushrax  ; for cs
   173  mov rax, ds
   174  pushrax
   175  mov rax, es
   176  pushrax
   177  mov rax, fs
   178  pushrax
   179  mov rax, gs
   180  pushrax
   181
   182  mov [rbp + 8], rcx   ; save vector number

and

   306  ;; UINT64  Gs, Fs, Es, Ds, Cs, Ss;
   307  pop rax
   308  ; mov gs, rax ; not for gs
   309  pop rax
   310  ; mov fs, rax ; not for fs
   311  ; (X64 will not use fs and gs, so we do not restore it)
   312  pop rax
   313  mov es, rax
   314  pop rax
   315  mov ds, rax
   316  pop qword [rbp + 32]  ; for cs
   317  pop qword [rbp + 56]  ; for ss

The problem is that NASM wouldn't support segment register MOVs in
64-bit mode until the following commit:

  http://repo.or.cz/nasm.git/commitdiff/21d4ccc3c338

  Wed, 25 Aug 2010 02:28:00 +0200 (24 17:28 -0700)

However, that change was first released in NASM 2.10:

  http://repo.or.cz/nasm.git/commitdiff/ff62f33da0a2

  Mon, 12 Mar 2012 21:36:02 +0100 (12 13:36 -0700)

I tried to work around this; for example by using

  movzx   eax, ds

with the idea that:
- the upper 16 bits of EAX would be cleared by MOVZX, and
- the upper 32-bits of RAX would be automatically cleared by any write
  to EAX.

Unfortunately, this fails the exact same way.

Now, I checked out the nasm source tree at tag "nasm-2.07" exactly, and
checked the "insns.dat" file (the file that the above commit,
21d4ccc3c338, extends), searching it for "reg_sreg". I wanted to see if
there was any other (i.e., non-MOV) way, supported by nasm-2.07, for
accessing segment registers.

I only found RSDC ("Restore Register and Descriptor") and SVDC ("Save
Register and Descriptor"). Those instructions seem to be vendor
extensions; they are not in the Intel SDM.

It seems that before NASM 2.10, there's simply no way to access segment
registers in 64-bit mode. I propose that we upgrade the following
comment in BaseTools:

> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 2065fa34998f..db61a37b6afd 100644
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -708,7 +708,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
> Files/CodeSourcery/Sourcery G
>  #
>  # Other Supported Tools
>  # =
> -#   NASM 2.07 or later http://www.nasm.us/
> +#   NASM 2.10 or later http://www.nasm.us/
>  #
>  
> 
>  
> 

plus wherever the minimum NASM version is documented on the Wiki.

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

[edk2] [PATCH 23/27] ShellPkg/UefiShellLib: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 5e5e627..e4e7e3d 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -2021,6 +2021,7 @@ InternalCommandLineParse (
   UINTN Count;
   CONST CHAR16  *TempPointer;
   UINTN CurrentValueSize;
+  CHAR16*NewValue;
 
   CurrentItemPackage = NULL;
   GetItemValue = 0;
@@ -2119,8 +2120,15 @@ InternalCommandLineParse (
   // get the item VALUE for a previous flag
   //
   CurrentValueSize = ValueSize + StrSize(Argv[LoopCounter]) + 
sizeof(CHAR16);
-  CurrentItemPackage->Value = ReallocatePool(ValueSize, CurrentValueSize, 
CurrentItemPackage->Value);
-  ASSERT(CurrentItemPackage->Value != NULL);
+  NewValue = ReallocatePool(ValueSize, CurrentValueSize, 
CurrentItemPackage->Value);
+  if (NewValue == NULL) {
+SHELL_FREE_NON_NULL (CurrentItemPackage->Value);
+SHELL_FREE_NON_NULL (CurrentItemPackage);
+ShellCommandLineFreeVarList (*CheckPackage);
+*CheckPackage = NULL;
+return EFI_OUT_OF_RESOURCES;
+  }
+  CurrentItemPackage->Value = NewValue;
   if (ValueSize == 0) {
 StrCpyS( CurrentItemPackage->Value, 
   CurrentValueSize/sizeof(CHAR16), 
-- 
2.9.0.windows.1

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

[edk2] [PATCH 01/27] ShellPkg/Shell.c: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Application/Shell/Shell.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/ShellPkg/Application/Shell/Shell.c 
b/ShellPkg/Application/Shell/Shell.c
index 54ca76a..713c317 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -1319,7 +1319,7 @@ DoShellPrompt (
 **/
 VOID*
 EFIAPI
-AddBufferToFreeList(
+AddBufferToFreeList (
   VOID *Buffer
   )
 {
@@ -1329,10 +1329,13 @@ AddBufferToFreeList(
 return (NULL);
   }
 
-  BufferListEntry = AllocateZeroPool(sizeof(BUFFER_LIST));
-  ASSERT(BufferListEntry != NULL);
+  BufferListEntry = AllocateZeroPool (sizeof (BUFFER_LIST));
+  if (BufferListEntry == NULL) {
+return NULL;
+  }
+
   BufferListEntry->Buffer = Buffer;
-  InsertTailList(, 
>Link);
+  InsertTailList (, 
>Link);
   return (Buffer);
 }
 
@@ -1391,9 +1394,15 @@ AddLineToCommandHistory(
 
 
   Node = AllocateZeroPool(sizeof(BUFFER_LIST));
-  ASSERT(Node != NULL);
-  Node->Buffer = AllocateCopyPool(StrSize(Buffer), Buffer);
-  ASSERT(Node->Buffer != NULL);
+  if (Node == NULL) {
+return;
+  }
+
+  Node->Buffer = AllocateCopyPool (StrSize (Buffer), Buffer);
+  if (Node->Buffer == NULL) {
+FreePool (Node);
+return;
+  }
 
   for ( Walker = 
(BUFFER_LIST*)GetFirstNode()
   ; !IsNull(, 
>Link)
@@ -1721,7 +1730,9 @@ RunSplitCommand(
   // make a SPLIT_LIST item and add to list
   //
   Split = AllocateZeroPool(sizeof(SPLIT_LIST));
-  ASSERT(Split != NULL);
+  if (Split == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
   Split->SplitStdIn   = StdIn;
   Split->SplitStdOut  = 
ConvertEfiFileProtocolToShellHandle(CreateFileInterfaceMem(Unicode), NULL);
   ASSERT(Split->SplitStdOut != NULL);
-- 
2.9.0.windows.1

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

[edk2] [PATCH 21/27] ShellPkg/Cp: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c
index 5cfbc90..eb1f3b6 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c
@@ -2,7 +2,7 @@
   Main file for cp shell level 2 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 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
@@ -229,7 +229,10 @@ CopySingleFile(
   // copy data between files
   //
   Buffer = AllocateZeroPool(ReadSize);
-  ASSERT(Buffer != NULL);
+  if (Buffer == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellLevel2HiiHandle, CmdName);
+return SHELL_OUT_OF_RESOURCES;
+  }
   while (ReadSize == PcdGet32(PcdShellFileOperationSize) && 
!EFI_ERROR(Status)) {
 Status = ShellReadFile(SourceHandle, , Buffer);
 if (!EFI_ERROR(Status)) {
@@ -717,10 +720,14 @@ ShellCommandRunCp (
 ShellStatus = SHELL_NOT_FOUND;
   } else  {
 FullCwd = AllocateZeroPool(StrSize(Cwd) + sizeof(CHAR16));
-ASSERT (FullCwd != NULL);
-StrCpyS(FullCwd, StrSize(Cwd)/sizeof(CHAR16)+1, Cwd);
-ShellStatus = ProcessValidateAndCopyFiles(FileList, FullCwd, 
SilentMode, RecursiveMode);
-FreePool(FullCwd);
+if (FullCwd == NULL) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellLevel2HiiHandle, L"cp");
+  ShellStatus = SHELL_OUT_OF_RESOURCES;
+} else {
+  StrCpyS (FullCwd, StrSize (Cwd) / sizeof (CHAR16) + 1, Cwd);
+  ShellStatus = ProcessValidateAndCopyFiles (FileList, FullCwd, 
SilentMode, RecursiveMode);
+  FreePool (FullCwd);
+}
   }
 }
 
-- 
2.9.0.windows.1

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

[edk2] [PATCH 19/27] ShellPkg/If: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellLevel1CommandsLib/If.c | 95 +---
 1 file changed, 53 insertions(+), 42 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c 
b/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
index dc96bff..e4dbe01 100644
--- a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
+++ b/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
@@ -2,7 +2,7 @@
   Main file for If and else shell level 1 function.
 
   (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 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
@@ -42,15 +42,17 @@ typedef enum {
 
   @param[in, out] StatementThe current remaining statement.
   @param[in] Fragment  The current fragment.
+  @param[out] MatchTRUE when there is another Fragment in 
Statement,
+   FALSE otherwise.
 
-  @retval FALSE   There is not another fragment.
-  @retval TRUEThere is another fragment.
+  @retval EFI_SUCCESS  The match operation is performed successfully.
+  @retval EFI_OUT_OF_RESOURCES Out of resources.
 **/
-BOOLEAN
-EFIAPI
+EFI_STATUS
 IsNextFragment (
   IN OUT CONST CHAR16 **Statement,
-  IN CONST CHAR16 *Fragment
+  IN CONST CHAR16 *Fragment,
+  OUT BOOLEAN *Match
   )
 {
   CHAR16  *Tester;
@@ -58,7 +60,9 @@ IsNextFragment (
   Tester = NULL;
 
   Tester = StrnCatGrow(, NULL, *Statement, StrLen(Fragment));
-  ASSERT(Tester != NULL);
+  if (Tester == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
   Tester[StrLen(Fragment)] = CHAR_NULL;
   if (gUnicodeCollation->StriColl(
 gUnicodeCollation,
@@ -71,11 +75,12 @@ IsNextFragment (
 while (*Statement[0] == L' ') {
   (*Statement)++;
 }
-FreePool(Tester);
-return (TRUE);
+*Match = TRUE;
+  } else {
+*Match = FALSE;
   }
   FreePool(Tester);
-  return (FALSE);
+  return EFI_SUCCESS;
 }
 
 /**
@@ -365,6 +370,7 @@ ProcessStatement (
   CHAR16  *Compare2;
   CHAR16  HexString[20];
   CHAR16  *TempSpot;
+  BOOLEAN Match;
 
   ASSERT((END_TAG_TYPE)OperatorToUse != EndTagThen);
 
@@ -372,7 +378,7 @@ ProcessStatement (
   BinOp   = OperatorMax;
   OperationResult = FALSE;
   StatementWalker = gEfiShellParametersProtocol->Argv[StartParameterNumber];
-  if (IsNextFragment((CONST CHAR16**)(), L"not")) {
+  if (!EFI_ERROR (IsNextFragment((CONST CHAR16**)(), L"not", 
)) && Match) {
 NotPresent  = TRUE;
 StatementWalker = 
gEfiShellParametersProtocol->Argv[++StartParameterNumber];
   } else {
@@ -382,16 +388,19 @@ ProcessStatement (
   //
   // now check for 'boolfunc' operators
   //
-  if (IsNextFragment((CONST CHAR16**)(), L"isint")) {
-if (IsNextFragment((CONST CHAR16**)(), L"(") && 
StatementWalker[StrLen(StatementWalker)-1] == L')') {
+  if (!EFI_ERROR (IsNextFragment((CONST CHAR16**)(), L"isint", 
)) && Match) {
+if (!EFI_ERROR (IsNextFragment((CONST CHAR16**)(), L"(", 
)) && Match
+&& StatementWalker[StrLen(StatementWalker)-1] == L')') {
   StatementWalker[StrLen(StatementWalker)-1] = CHAR_NULL;
   OperationResult = ShellIsHexOrDecimalNumber(StatementWalker, FALSE, 
FALSE);
 } else {
   Status = EFI_INVALID_PARAMETER;
   ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_SYNTAX_IN), 
gShellLevel1HiiHandle, L"isint");
 }
-  } else if (IsNextFragment((CONST CHAR16**)(), L"exists") || 
IsNextFragment((CONST CHAR16**)(), L"exist")) {
-if (IsNextFragment((CONST CHAR16**)(), L"(") && 
StatementWalker[StrLen(StatementWalker)-1] == L')') {
+  } else if ((!EFI_ERROR (IsNextFragment((CONST CHAR16**)(), 
L"exists", )) && Match) ||
+ (!EFI_ERROR (IsNextFragment((CONST CHAR16**)(), 
L"exist", )) && Match)) {
+if (!EFI_ERROR (IsNextFragment((CONST CHAR16**)(), L"(", 
)) && Match &&
+StatementWalker[StrLen(StatementWalker)-1] == L')') {
   StatementWalker[StrLen(StatementWalker)-1] = CHAR_NULL;
   //
   // is what remains a file in CWD???
@@ -403,8 +412,9 @@ ProcessStatement (
   ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_SYNTAX_IN), 
gShellLevel1HiiHandle, L"exist(s)");
   Status = EFI_INVALID_PARAMETER;
 }
-  } else if (IsNextFragment((CONST CHAR16**)(), L"available")) 
{
-if (IsNextFragment((CONST CHAR16**)(), L"(") && 
StatementWalker[StrLen(StatementWalker)-1] == L')') {
+  } else if (!EFI_ERROR (IsNextFragment((CONST CHAR16**)(), 
L"available", )) && Match) {
+if (!EFI_ERROR 

[edk2] [PATCH 18/27] ShellPkg/For: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellLevel1CommandsLib/For.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/For.c 
b/ShellPkg/Library/UefiShellLevel1CommandsLib/For.c
index cbf0517..6cfe8a7 100644
--- a/ShellPkg/Library/UefiShellLevel1CommandsLib/For.c
+++ b/ShellPkg/Library/UefiShellLevel1CommandsLib/For.c
@@ -2,7 +2,7 @@
   Main file for endfor and for shell level 1 functions.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 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
@@ -414,7 +414,10 @@ ShellCommandRunFor (
 NewSize = StrSize(ArgSet);
 NewSize += 
sizeof(SHELL_FOR_INFO)+StrSize(gEfiShellParametersProtocol->Argv[1]);
 Info = AllocateZeroPool(NewSize);
-ASSERT(Info != NULL);
+if (Info == NULL) {
+  FreePool (ArgSet);
+  return SHELL_OUT_OF_RESOURCES;
+}
 Info->Signature = SHELL_FOR_INFO_SIGNATURE;
 CopyMem(Info->Set, ArgSet, StrSize(ArgSet));
 NewSize = StrSize(gEfiShellParametersProtocol->Argv[1]);
@@ -458,7 +461,10 @@ ShellCommandRunFor (
 // set up for a 'run' for loop
 //
 Info = 
AllocateZeroPool(sizeof(SHELL_FOR_INFO)+StrSize(gEfiShellParametersProtocol->Argv[1]));
-ASSERT(Info != NULL);
+if (Info == NULL) {
+  FreePool (ArgSet);
+  return SHELL_OUT_OF_RESOURCES;
+}
 Info->Signature = SHELL_FOR_INFO_SIGNATURE;
 CopyMem(Info->Set, gEfiShellParametersProtocol->Argv[1], 
StrSize(gEfiShellParametersProtocol->Argv[1]));
 Info->ReplacementName = Info->Set;
-- 
2.9.0.windows.1

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

[edk2] [PATCH 20/27] ShellPkg/Cd: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c | 34 +++-
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c
index 19e8e2f..2e51b4c 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c
@@ -2,7 +2,7 @@
   Main file for attrib shell level 2 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 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
@@ -125,12 +125,16 @@ ShellCommandRunCd (
   } else {
 CwdSize = StrSize(Directory) + sizeof(CHAR16);
 Cwd = AllocateZeroPool(CwdSize);
-ASSERT(Cwd!=NULL);
-StrCpyS(Cwd, StrSize(Directory)/sizeof(CHAR16)+1, Directory);
-StrCatS(Cwd, StrSize(Directory)/sizeof(CHAR16)+1, L"\\");
-Drive = GetFullyQualifiedPath(Cwd);
-PathRemoveLastItem(Drive);
-FreePool(Cwd);
+if (Cwd == NULL) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellLevel2HiiHandle, L"cd");
+  ShellStatus = SHELL_OUT_OF_RESOURCES;
+} else {
+  StrCpyS (Cwd, StrSize (Directory) / sizeof (CHAR16) + 1, 
Directory);
+  StrCatS (Cwd, StrSize (Directory) / sizeof (CHAR16) + 1, L"\\");
+  Drive = GetFullyQualifiedPath (Cwd);
+  PathRemoveLastItem (Drive);
+  FreePool (Cwd);
+}
   }
   if (ShellStatus == SHELL_SUCCESS && Drive != NULL) {
 //
@@ -153,12 +157,16 @@ ShellCommandRunCd (
   } else {
 CwdSize = StrSize(Directory) + sizeof(CHAR16);
 Cwd = AllocateZeroPool(CwdSize);
-ASSERT(Cwd!=NULL);
-StrCpyS(Cwd, StrSize(Directory)/sizeof(CHAR16)+1, Directory);
-StrCatS(Cwd, StrSize(Directory)/sizeof(CHAR16)+1, L"\\");
-Drive = GetFullyQualifiedPath(Cwd);
-while (PathRemoveLastItem(Drive));
-FreePool(Cwd);
+if (Cwd == NULL) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellLevel2HiiHandle, L"cd");
+  ShellStatus = SHELL_OUT_OF_RESOURCES;
+} else {
+  StrCpyS (Cwd, StrSize (Directory) / sizeof (CHAR16) + 1, 
Directory);
+  StrCatS (Cwd, StrSize (Directory) / sizeof (CHAR16) + 1, L"\\");
+  Drive = GetFullyQualifiedPath (Cwd);
+  while (PathRemoveLastItem (Drive));
+  FreePool (Cwd);
+}
   }
   if (ShellStatus == SHELL_SUCCESS && Drive != NULL) {
 //
-- 
2.9.0.windows.1

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

[edk2] [PATCH 00/27] ShellPkg: Handle memory allocation failure

[Ruiyu Ni]

The patch serials remove almost all assertions on memory allocation
result, replaces with the error handling code.

https://github.com/niruiyu/edk2/commits/shell_assert

Ruiyu Ni (27):
  ShellPkg/Shell.c: Handle memory allocation failure
  ShellPkg/IsVolatileEnv: Handle memory allocation failure
  ShellPkg/ShellAddEnvVarToList: Handle memory allocation failure
  ShellPkg/ShellProtocol.c: Handle memory allocation failure
  ShellPkg/Dp: Handle memory allocation failure
  ShellPkg/UefiHandleParsingLib.c: Handle memory allocation failure
  ShellPkg/UefiShellBcfgCommandLib: Handle memory allocation failure
  ShellPkg/ConsistMapping.c: Handle memory allocation failure
  ShellPkg/UefiShellCommandLib.c: Handle memory allocation failure
  ShellPkg/DMem: Handle memory allocation failure
  ShellPkg/EfiCompress: Handle memory allocation failure
  ShellPkg/EfiDecompress: Handle memory allocation failure
  ShellPkg/LoadPciRom: Handle memory allocation failure
  ShellPkg/Edit: Handle memory allocation failure
  ShellPkg/DevTree: Handle memory allocation failure
  ShellPkg/DrvCfg: Handle memory allocation failure
  ShellPkg/DrvDiag: Handle memory allocation failure
  ShellPkg/For: Handle memory allocation failure
  ShellPkg/If: Handle memory allocation failure
  ShellPkg/Cd: Handle memory allocation failure
  ShellPkg/Cp: Handle memory allocation failure
  ShellPkg/Mv: Handle memory allocation failure
  ShellPkg/UefiShellLib: Handle memory allocation failure
  ShellPkg/IfConfig: Handle memory allocation failure
  ShellPkg/UefiShellLib.c: Handle memory allocation failure
  ShellPkg/Ifconfig6: Handle memory allocation failure
  ShellPkg/Ping6: Handle memory allocation failure

 ShellPkg/Application/Shell/FileHandleWrappers.c|  19 +-
 ShellPkg/Application/Shell/Shell.c |  27 +-
 ShellPkg/Application/Shell/ShellEnvVar.c   |  73 +--
 ShellPkg/Application/Shell/ShellEnvVar.h   |  22 +-
 .../Application/Shell/ShellParametersProtocol.c|   5 +-
 ShellPkg/Application/Shell/ShellProtocol.c | 142 +++---
 ShellPkg/Application/Shell/ShellProtocol.h |  17 +-
 ShellPkg/Library/UefiDpLib/Dp.c|   8 +-
 .../UefiHandleParsingLib/UefiHandleParsingLib.c|  55 ++-
 .../UefiShellBcfgCommandLib.c  |  47 +-
 .../Library/UefiShellCommandLib/ConsistMapping.c   | 497 +
 .../UefiShellCommandLib/UefiShellCommandLib.c  |  34 +-
 ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c |   6 +-
 .../UefiShellDebug1CommandsLib/Edit/FileBuffer.c   |  41 +-
 .../UefiShellDebug1CommandsLib/EfiCompress.c   |  28 +-
 .../UefiShellDebug1CommandsLib/EfiDecompress.c |  52 ++-
 .../UefiShellDebug1CommandsLib/LoadPciRom.c|   6 +-
 .../Library/UefiShellDriver1CommandsLib/DevTree.c  |  13 +-
 .../Library/UefiShellDriver1CommandsLib/DrvCfg.c   |  17 +-
 .../Library/UefiShellDriver1CommandsLib/DrvDiag.c  |  17 +-
 ShellPkg/Library/UefiShellLevel1CommandsLib/For.c  |  12 +-
 ShellPkg/Library/UefiShellLevel1CommandsLib/If.c   |  95 ++--
 ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c   |  34 +-
 ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c   |  19 +-
 ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c   |  14 +-
 ShellPkg/Library/UefiShellLib/UefiShellLib.c   |  23 +-
 .../UefiShellNetwork1CommandsLib/Ifconfig.c|  77 +++-
 .../UefiShellNetwork1CommandsLib.uni   |   1 +
 .../UefiShellNetwork2CommandsLib/Ifconfig6.c   |  75 +++-
 .../Library/UefiShellNetwork2CommandsLib/Ping6.c   |   6 +-
 .../UefiShellNetwork2CommandsLib.uni   |   2 +
 31 files changed, 954 insertions(+), 530 deletions(-)

-- 
2.9.0.windows.1

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

[edk2] [PATCH 24/27] ShellPkg/IfConfig: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiShellNetwork1CommandsLib/Ifconfig.c| 77 --
 .../UefiShellNetwork1CommandsLib.uni   |  1 +
 2 files changed, 58 insertions(+), 20 deletions(-)

diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c 
b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
index 92108a1..5e243d5 100644
--- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
+++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
@@ -130,6 +130,26 @@ VAR_CHECK_ITEM  mSetCheckList[] = {
 STATIC CONST CHAR16 PermanentString[10] = L"PERMANENT";
 
 /**
+  Free the ARG_LIST.
+
+  @param List Pointer to ARG_LIST to free.
+**/
+VOID
+FreeArgList (
+  ARG_LIST   *List
+)
+{
+  ARG_LIST   *Next;
+  while (List->Next != NULL) {
+Next = List->Next;
+FreePool (List);
+List = Next;
+  }
+
+  FreePool (List);
+}
+
+/**
   Split a string with specified separator and save the substring to a list.
 
   @param[in]String   The pointer of the input string.
@@ -157,14 +177,18 @@ SplitStrToList (
   // Copy the CONST string to a local copy.
   //
   Str = AllocateCopyPool (StrSize (String), String);
-  ASSERT (Str != NULL);
+  if (Str == NULL) {
+return NULL;
+  }
   ArgStr  = Str;
 
   //
   // init a node for the list head.
   //
   ArgNode = (ARG_LIST *) AllocateZeroPool (sizeof (ARG_LIST));
-  ASSERT (ArgNode != NULL);
+  if (ArgNode == NULL) {
+return NULL;
+  }
   ArgList = ArgNode;
 
   //
@@ -176,7 +200,14 @@ SplitStrToList (
   ArgNode->Arg  = ArgStr;
   ArgStr= Str + 1;
   ArgNode->Next = (ARG_LIST *) AllocateZeroPool (sizeof (ARG_LIST));
-  ASSERT (ArgNode->Next != NULL);
+  if (ArgNode->Next == NULL) {
+//
+// Free the local copy of string stored in the first node
+//
+FreePool (ArgList->Arg);
+FreeArgList (ArgList);
+return NULL;
+  }
   ArgNode = ArgNode->Next;
 }
 
@@ -1083,7 +1114,11 @@ IfConfigSetInterfaceInfo (
   }
 
   Dns   = AllocatePool (Index * sizeof (EFI_IPv4_ADDRESS));
-  ASSERT(Dns != NULL);
+  if (Dns == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellNetwork1HiiHandle, L"ifconfig");
+ShellStatus = SHELL_OUT_OF_RESOURCES;
+goto ON_EXIT;
+  }
   Tmp   = VarArg;
   Index = 0;
   while (Tmp != NULL) {
@@ -1193,8 +1228,6 @@ IfConfigCleanup (
   LIST_ENTRY*Entry;
   LIST_ENTRY*NextEntry;
   IFCONFIG_INTERFACE_CB *IfCb;
-  ARG_LIST  *ArgNode;
-  ARG_LIST  *ArgHead;
 
   ASSERT (Private != NULL);
 
@@ -1202,15 +1235,7 @@ IfConfigCleanup (
   // Clean the list which save the set config Args.
   //
   if (Private->VarArg != NULL) {
-ArgHead = Private->VarArg;
-
-while (ArgHead->Next != NULL) {
-  ArgNode = ArgHead->Next;
-  FreePool (ArgHead);
-  ArgHead = ArgNode;
-}
-
-FreePool (ArgHead);
+FreeArgList (Private->VarArg);
   }
 
   if (Private->IfName != NULL) {
@@ -1325,11 +1350,15 @@ ShellCommandRunIfconfig (
 ValueStr = ShellCommandLineGetValue (ParamPackage, L"-l");
 if (ValueStr != NULL) {
   Str = AllocateCopyPool (StrSize (ValueStr), ValueStr);
-  ASSERT (Str != NULL);
+  if (Str == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellNetwork1HiiHandle, L"ifconfig");
+ShellStatus = SHELL_OUT_OF_RESOURCES;
+goto ON_EXIT;
+  }
   Private->IfName = Str;
 }
   }
-  
+
   //
   // To get interface name for the clear option.
   //
@@ -1338,7 +1367,11 @@ ShellCommandRunIfconfig (
 ValueStr = ShellCommandLineGetValue (ParamPackage, L"-r");
 if (ValueStr != NULL) {
   Str = AllocateCopyPool (StrSize (ValueStr), ValueStr);
-  ASSERT (Str != NULL);
+  if (Str == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellNetwork1HiiHandle, L"ifconfig");
+ShellStatus = SHELL_OUT_OF_RESOURCES;
+goto ON_EXIT;
+  }
   Private->IfName = Str;
 }
   }
@@ -1357,8 +1390,12 @@ ShellCommandRunIfconfig (
 //
 // To split the configuration into multi-section.
 //
-ArgList = SplitStrToList (ValueStr, L' ');
-ASSERT (ArgList != NULL);
+ArgList = SplitStrToList (ValueStr, L' ');
+if (ArgList == NULL) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellNetwork1HiiHandle, L"ifconfig");
+  ShellStatus = SHELL_OUT_OF_RESOURCES;
+  goto ON_EXIT;
+}
 
 Private->OpCode = IfConfigOpSet;
 Private->IfName = ArgList->Arg;
diff --git 
a/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.uni
 
b/ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.uni
index 

[edk2] [PATCH 22/27] ShellPkg/Mv: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c
index d02a6ae..f93772c 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c
@@ -736,11 +736,15 @@ ShellCommandRunMv (
 //
 CwdSize = StrSize(ShellGetCurrentDir(NULL)) + sizeof(CHAR16);
 Cwd = AllocateZeroPool(CwdSize);
-ASSERT (Cwd != NULL);
-StrCpyS(Cwd, CwdSize/sizeof(CHAR16), ShellGetCurrentDir(NULL));
-StrCatS(Cwd, CwdSize/sizeof(CHAR16), L"\\");
-ShellStatus = ValidateAndMoveFiles(FileList, , Cwd);
-FreePool(Cwd);
+if (Cwd == NULL) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellLevel2HiiHandle, L"mv");
+  ShellStatus = SHELL_OUT_OF_RESOURCES;
+} else {
+  StrCpyS (Cwd, CwdSize / sizeof (CHAR16), ShellGetCurrentDir 
(NULL));
+  StrCatS (Cwd, CwdSize / sizeof (CHAR16), L"\\");
+  ShellStatus = ValidateAndMoveFiles (FileList, , Cwd);
+  FreePool (Cwd);
+}
   }
 }
 
-- 
2.9.0.windows.1

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

[edk2] [PATCH 26/27] ShellPkg/Ifconfig6: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiShellNetwork2CommandsLib/Ifconfig6.c   | 75 --
 .../UefiShellNetwork2CommandsLib.uni   |  2 +
 2 files changed, 56 insertions(+), 21 deletions(-)

diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ifconfig6.c 
b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ifconfig6.c
index 371b368..af2e0bc 100644
--- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ifconfig6.c
+++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ifconfig6.c
@@ -155,6 +155,26 @@ VAR_CHECK_ITEM  mIfConfig6SetCheckList[] = {
 };
 
 /**
+  Free the ARG_LIST.
+
+  @param List Pointer to ARG_LIST to free.
+**/
+VOID
+IfConfig6FreeArgList (
+  ARG_LIST   *List
+)
+{
+  ARG_LIST   *Next;
+  while (List->Next != NULL) {
+Next = List->Next;
+FreePool (List);
+List = Next;
+  }
+
+  FreePool (List);
+}
+
+/**
   Split a string with specified separator and save the substring to a list.
 
   @param[in]String   The pointer of the input string.
@@ -181,15 +201,19 @@ IfConfig6SplitStrToList (
   //
   // Copy the CONST string to a local copy.
   //
-  Str = AllocateCopyPool (StrSize (String), String);
-  ASSERT (Str != NULL);
+  Str = AllocateCopyPool (StrSize (String), String);
+  if (Str == NULL) {
+return NULL;
+  }
   ArgStr  = Str;
 
   //
   // init a node for the list head.
   //
   ArgNode = (ARG_LIST *) AllocateZeroPool (sizeof (ARG_LIST));
-  ASSERT (ArgNode != NULL);
+  if (ArgNode == NULL) {
+return NULL;
+  }
   ArgList = ArgNode;
 
   //
@@ -201,7 +225,14 @@ IfConfig6SplitStrToList (
   ArgNode->Arg  = ArgStr;
   ArgStr= Str + 1;
   ArgNode->Next = (ARG_LIST *) AllocateZeroPool (sizeof (ARG_LIST));
-  ASSERT (ArgNode->Next != NULL);
+  if (ArgNode->Next == NULL) {
+//
+// Free the local copy of string stored in the first node
+//
+FreePool (ArgList->Arg);
+IfConfig6FreeArgList (ArgList);
+return NULL;
+  }
   ArgNode = ArgNode->Next;
 }
 
@@ -1646,8 +1677,6 @@ IfConfig6Cleanup (
   LIST_ENTRY*Entry;
   LIST_ENTRY*NextEntry;
   IFCONFIG6_INTERFACE_CB*IfCb;
-  ARG_LIST  *ArgNode;
-  ARG_LIST  *ArgHead;
 
   ASSERT (Private != NULL);
 
@@ -1655,15 +1684,7 @@ IfConfig6Cleanup (
   // Clean the list which save the set config Args.
   //
   if (Private->VarArg != NULL) {
-ArgHead = Private->VarArg;
-
-while (ArgHead->Next != NULL) {
-  ArgNode = ArgHead->Next;
-  FreePool (ArgHead);
-  ArgHead = ArgNode;
-}
-
-FreePool (ArgHead);
+IfConfig6FreeArgList (Private->VarArg);
   }
 
   if (Private->IfName != NULL)
@@ -1777,8 +1798,12 @@ ShellCommandRunIfconfig6 (
 Private->OpCode = IfConfig6OpList;
 ValueStr = ShellCommandLineGetValue (ParamPackage, L"-l");
 if (ValueStr != NULL) {
-  Str = AllocateCopyPool (StrSize (ValueStr), ValueStr);
-  ASSERT (Str != NULL);
+  Str = AllocateCopyPool (StrSize (ValueStr), ValueStr);
+  if (Str == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellNetwork2HiiHandle, L"ifconfig6");
+ShellStatus = SHELL_OUT_OF_RESOURCES;
+goto ON_EXIT;
+  }
   Private->IfName = Str;
 }
   }
@@ -1789,8 +1814,12 @@ ShellCommandRunIfconfig6 (
 Private->OpCode = IfConfig6OpClear;
 ValueStr = ShellCommandLineGetValue (ParamPackage, L"-r");
 if (ValueStr != NULL) {
-  Str = AllocateCopyPool (StrSize (ValueStr), ValueStr);
-  ASSERT (Str != NULL);
+  Str = AllocateCopyPool (StrSize (ValueStr), ValueStr);
+  if (Str == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellNetwork2HiiHandle, L"ifconfig6");
+ShellStatus = SHELL_OUT_OF_RESOURCES;
+goto ON_EXIT;
+  }
   Private->IfName = Str;
 }
   }
@@ -1808,8 +1837,12 @@ ShellCommandRunIfconfig6 (
 //
 // To split the configuration into multi-section.
 //
-ArgList = IfConfig6SplitStrToList (ValueStr, L' ');
-ASSERT (ArgList != NULL);
+ArgList = IfConfig6SplitStrToList (ValueStr, L' ');
+if (ArgList == NULL) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellNetwork2HiiHandle, L"ifconfig6");
+  ShellStatus = SHELL_OUT_OF_RESOURCES;
+  goto ON_EXIT;
+}
 
 Private->OpCode = IfConfig6OpSet;
 Private->IfName = ArgList->Arg;
diff --git 
a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.uni
 
b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.uni
index 40e0284..8cb2d15 100644
--- 
a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.uni
+++ 
b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.uni

[edk2] [PATCH 17/27] ShellPkg/DrvDiag: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellDriver1CommandsLib/DrvDiag.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvDiag.c 
b/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvDiag.c
index 973a995..1173f8d 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvDiag.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvDiag.c
@@ -2,7 +2,7 @@
   Main file for DrvDiag shell Driver1 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2010 - 2013, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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
@@ -94,7 +94,9 @@ DoDiagnostics (
 
   if (DriverHandle != NULL) {
 DriverHandleList = AllocateZeroPool(2*sizeof(EFI_HANDLE));
-ASSERT(DriverHandleList!=NULL);
+if (DriverHandleList == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
 DriverHandleList[0] = DriverHandle;
 DriverHandleListCount = 1;
   } else {
@@ -109,7 +111,10 @@ DoDiagnostics (
 
   if (ControllerHandle != NULL) {
 ControllerHandleList = AllocateZeroPool(2*sizeof(EFI_HANDLE));
-ASSERT(ControllerHandleList!=NULL);
+if (ControllerHandleList == NULL) {
+  SHELL_FREE_NON_NULL (DriverHandleList);
+  return EFI_OUT_OF_RESOURCES;
+}
 ControllerHandleList[0] = ControllerHandle;
 ControllerHandleListCount = 1;
   } else {
@@ -118,7 +123,11 @@ DoDiagnostics (
 
   if (ChildHandle != NULL) {
 ChildHandleList = AllocateZeroPool(2*sizeof(EFI_HANDLE));
-ASSERT(ChildHandleList!=NULL);
+if (ChildHandleList != NULL) {
+  SHELL_FREE_NON_NULL (ControllerHandleList);
+  SHELL_FREE_NON_NULL (DriverHandleList);
+  return EFI_OUT_OF_RESOURCES;
+}
 ChildHandleList[0] = ChildHandle;
 ChildHandleListCount = 1;
   } else if (AllChilds) {
-- 
2.9.0.windows.1

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

[edk2] [PATCH 27/27] ShellPkg/Ping6: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c 
b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
index 4496802..90a2604 100644
--- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
+++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
@@ -961,7 +961,11 @@ ShellPing6 (
   ShellStatus = SHELL_SUCCESS;
   Private = AllocateZeroPool (sizeof (PING6_PRIVATE_DATA));
 
-  ASSERT (Private != NULL);
+  if (Private == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellNetwork2HiiHandle, L"Ping6");
+ShellStatus = SHELL_OUT_OF_RESOURCES;
+goto ON_EXIT;
+  }
 
   Private->ImageHandle = ImageHandle;
   Private->SendNum = SendNumber;
-- 
2.9.0.windows.1

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

[edk2] [PATCH 13/27] ShellPkg/LoadPciRom: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
index 1b94746..721c466 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
@@ -147,7 +147,11 @@ ShellCommandRunLoadPciRom (
   }
   SourceSize  = (UINTN) Node->Info->FileSize;
   File1Buffer = AllocateZeroPool (SourceSize);
-  ASSERT(File1Buffer != NULL);
+  if (File1Buffer == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_OUT_MEM), 
gShellDebug1HiiHandle, L"loadpcirom");
+ShellStatus = SHELL_OUT_OF_RESOURCES;
+continue;
+  }
   Status = gEfiShellProtocol->ReadFile(Node->Handle, , 
File1Buffer);
   if (EFI_ERROR(Status)) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_FILE_READ_FAIL), 
gShellDebug1HiiHandle, L"loadpcirom", Node->FullName);  
-- 
2.9.0.windows.1

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

[edk2] [PATCH 15/27] ShellPkg/DevTree: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellDriver1CommandsLib/DevTree.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/DevTree.c 
b/ShellPkg/Library/UefiShellDriver1CommandsLib/DevTree.c
index fb9de10..237cb85 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/DevTree.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/DevTree.c
@@ -2,7 +2,7 @@
   Main file for DevTree shell Driver1 function.
 
   (C) Copyright 2014-2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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
@@ -57,7 +57,8 @@ DoDevTreeForHandle(
   ChildHandleBuffer   = NULL;
   ChildCount  = 0;
 
-  ASSERT(TheHandle!= NULL);
+  ASSERT (TheHandle != NULL);
+  ASSERT (HiiString != NULL);
   
   if (ShellGetExecutionBreakFlag()) {
 ShellStatus = SHELL_ABORTED;
@@ -91,10 +92,10 @@ DoDevTreeForHandle(
 return SHELL_SUCCESS;
   }
 
-  FormatString= AllocateZeroPool(StrSize(HiiString) + 
(10)*sizeof(FormatString[0]));
-
-  ASSERT(HiiString!= NULL);
-  ASSERT(FormatString != NULL);
+  FormatString = AllocateZeroPool(StrSize(HiiString) + 
(10)*sizeof(FormatString[0]));
+  if (FormatString == NULL) {
+return SHELL_OUT_OF_RESOURCES;
+  }
 
   //
   // we generate the format string on the fly so that we can control the
-- 
2.9.0.windows.1

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

[edk2] [PATCH 05/27] ShellPkg/Dp: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiDpLib/Dp.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiDpLib/Dp.c b/ShellPkg/Library/UefiDpLib/Dp.c
index 4bad3c2..75c7d11 100644
--- a/ShellPkg/Library/UefiDpLib/Dp.c
+++ b/ShellPkg/Library/UefiDpLib/Dp.c
@@ -259,13 +259,19 @@ ShellCommandRunDp (
   CustomCumulativeToken = ShellCommandLineGetValue (ParamPackage, L"-c");
   if (CustomCumulativeToken != NULL) {
 CustomCumulativeData = AllocateZeroPool (sizeof (PERF_CUM_DATA));
-ASSERT (CustomCumulativeData != NULL);
+if (CustomCumulativeData == NULL) {
+  return SHELL_OUT_OF_RESOURCES;
+}
 CustomCumulativeData->MinDur = 0;
 CustomCumulativeData->MaxDur = 0;
 CustomCumulativeData->Count  = 0;
 CustomCumulativeData->Duration = 0;
 NameSize = StrLen (CustomCumulativeToken) + 1;
 CustomCumulativeData->Name   = AllocateZeroPool (NameSize);
+if (CustomCumulativeData->Name == NULL) {
+  FreePool (CustomCumulativeData);
+  return SHELL_OUT_OF_RESOURCES;
+}
 UnicodeStrToAsciiStrS (CustomCumulativeToken, CustomCumulativeData->Name, 
NameSize);
   }
 
-- 
2.9.0.windows.1

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

[edk2] [PATCH 16/27] ShellPkg/DrvCfg: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c 
b/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c
index 609d076..0d12f01 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c
@@ -2,7 +2,7 @@
   Main file for DrvCfg shell Driver1 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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
@@ -57,8 +57,11 @@ FindHiiHandleViaDevPath(
   Status = HiiDb->ListPackageLists(HiiDb, EFI_HII_PACKAGE_DEVICE_PATH, NULL, 
, HandleBuffer);
   if (Status == EFI_BUFFER_TOO_SMALL) {
 HandleBuffer = AllocateZeroPool(HandleBufferSize);
-ASSERT (HandleBuffer != NULL);
-Status = HiiDb->ListPackageLists(HiiDb, EFI_HII_PACKAGE_DEVICE_PATH, NULL, 
, HandleBuffer);
+if (HandleBuffer == NULL) {
+  Status = EFI_OUT_OF_RESOURCES;
+} else {
+  Status = HiiDb->ListPackageLists (HiiDb, EFI_HII_PACKAGE_DEVICE_PATH, 
NULL, , HandleBuffer);
+}
   }
   if (EFI_ERROR(Status)) {
 SHELL_FREE_NON_NULL(HandleBuffer);
@@ -75,8 +78,12 @@ FindHiiHandleViaDevPath(
 Status = HiiDb->ExportPackageLists(HiiDb, HandleBuffer[LoopVariable], 
, MainBuffer);
 if (Status == EFI_BUFFER_TOO_SMALL) {
   MainBuffer = AllocateZeroPool(MainBufferSize);
-  ASSERT (MainBuffer != NULL);
-  Status = HiiDb->ExportPackageLists(HiiDb, HandleBuffer[LoopVariable], 
, MainBuffer);
+  if (MainBuffer != NULL) {
+Status = HiiDb->ExportPackageLists (HiiDb, HandleBuffer[LoopVariable], 
, MainBuffer);
+  }
+}
+if (EFI_ERROR (Status)) {
+  continue;
 }
 //
 // Enumerate through the block of returned memory.
-- 
2.9.0.windows.1

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

[edk2] [PATCH 12/27] ShellPkg/EfiDecompress: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiShellDebug1CommandsLib/EfiDecompress.c | 52 --
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c
index c145743..90eafe5 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c
@@ -2,7 +2,7 @@
   Main file for EfiDecompress shell Debug1 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2005 - 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
@@ -119,14 +119,18 @@ ShellCommandRunEfiDecompress (
   InSize = (UINTN)Temp64Bit;
   ASSERT_EFI_ERROR(Status);
   InBuffer = AllocateZeroPool(InSize);
-  ASSERT(InBuffer != NULL);
-  Status = gEfiShellProtocol->ReadFile(InFileHandle, , 
InBuffer);
-  ASSERT_EFI_ERROR(Status);
+  if (InBuffer == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+  } else {
+Status = gEfiShellProtocol->ReadFile (InFileHandle, , 
InBuffer);
+ASSERT_EFI_ERROR (Status);
 
-  Status = gBS->LocateProtocol(, NULL, 
(VOID**));
-  ASSERT_EFI_ERROR(Status);
+Status = gBS->LocateProtocol (, NULL, 
(VOID**) );
+ASSERT_EFI_ERROR (Status);
+
+Status = Decompress->GetInfo (Decompress, InBuffer, (UINT32) 
InSize, , );
+  }
 
-  Status = Decompress->GetInfo(Decompress, InBuffer, (UINT32)InSize, 
, );
   if (EFI_ERROR(Status) || OutSize == 0) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN 
(STR_EFI_DECOMPRESS_NOPE), gShellDebug1HiiHandle, InFileName);
 ShellStatus = SHELL_NOT_FOUND;
@@ -138,25 +142,25 @@ ShellCommandRunEfiDecompress (
 } else {
   OutBuffer = AllocateZeroPool(OutSize);
   ScratchBuffer = AllocateZeroPool(ScratchSize);
-  ASSERT(OutBuffer != NULL);
-  ASSERT(ScratchBuffer != NULL);
-
-  Status = Decompress->Decompress(Decompress, InBuffer, 
(UINT32)InSize, OutBuffer, OutSize, ScratchBuffer, ScratchSize);
-  ASSERT_EFI_ERROR(Status);
-
-  if (EFI_ERROR(Status)) {
-ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN 
(STR_EFI_DECOMPRESS_FAIL), gShellDebug1HiiHandle, Status);
-ShellStatus = SHELL_DEVICE_ERROR;
+  if (OutBuffer == NULL || ScratchBuffer == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
   } else {
-OutSizeTemp = OutSize;
-Status = gEfiShellProtocol->WriteFile(OutFileHandle, 
, OutBuffer);
-OutSize = (UINT32)OutSizeTemp;
-if (EFI_ERROR(Status)) {
-  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN 
(STR_FILE_WRITE_FAIL), gShellDebug1HiiHandle, L"efidecompress", OutFileName, 
Status);  
-  ShellStatus = SHELL_DEVICE_ERROR;
-}
+Status = Decompress->Decompress (Decompress, InBuffer, 
(UINT32) InSize, OutBuffer, OutSize, ScratchBuffer, ScratchSize);
   }
-} 
+}
+  }
+
+  if (EFI_ERROR (Status)) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_EFI_DECOMPRESS_FAIL), gShellDebug1HiiHandle, Status);
+ShellStatus = ((Status == EFI_OUT_OF_RESOURCES) ? 
SHELL_OUT_OF_RESOURCES : SHELL_DEVICE_ERROR);
+  } else {
+OutSizeTemp = OutSize;
+Status = gEfiShellProtocol->WriteFile (OutFileHandle, 
, OutBuffer);
+OutSize = (UINT32) OutSizeTemp;
+if (EFI_ERROR (Status)) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_FILE_WRITE_FAIL), gShellDebug1HiiHandle, L"efidecompress", OutFileName, 
Status);
+  ShellStatus = SHELL_DEVICE_ERROR;
+}
   }
 }
   }
-- 
2.9.0.windows.1

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

[edk2] [PATCH 11/27] ShellPkg/EfiCompress: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiShellDebug1CommandsLib/EfiCompress.c   | 28 +-
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiCompress.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiCompress.c
index 85ae732..1ffbd92 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiCompress.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiCompress.c
@@ -116,20 +116,26 @@ ShellCommandRunEfiCompress (
   Status = gEfiShellProtocol->GetFileSize(InShellFileHandle, );
   ASSERT_EFI_ERROR(Status);
   InBuffer = AllocateZeroPool((UINTN)InSize);
-  ASSERT(InBuffer != NULL);
-  InSize2 = (UINTN)InSize;
-  Status = gEfiShellProtocol->ReadFile(InShellFileHandle, , 
InBuffer);
-  InSize = InSize2;
-  ASSERT_EFI_ERROR(Status);
-  Status = Compress(InBuffer, InSize, OutBuffer, );
-  if (Status == EFI_BUFFER_TOO_SMALL) {
-OutBuffer = AllocateZeroPool((UINTN)OutSize);
-ASSERT(OutBuffer != NULL);
-Status = Compress(InBuffer, InSize, OutBuffer, );
+  if (InBuffer == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+  } else {
+InSize2 = (UINTN) InSize;
+Status = gEfiShellProtocol->ReadFile (InShellFileHandle, , 
InBuffer);
+InSize = InSize2;
+ASSERT_EFI_ERROR (Status);
+Status = Compress (InBuffer, InSize, OutBuffer, );
+if (Status == EFI_BUFFER_TOO_SMALL) {
+  OutBuffer = AllocateZeroPool ((UINTN) OutSize);
+  if (OutBuffer == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+  } else {
+Status = Compress (InBuffer, InSize, OutBuffer, );
+  }
+}
   }
   if (EFI_ERROR(Status)) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN 
(STR_EFI_COMPRESS_FAIL), gShellDebug1HiiHandle, Status);
-ShellStatus = SHELL_DEVICE_ERROR;
+ShellStatus = ((Status == EFI_OUT_OF_RESOURCES) ? 
SHELL_OUT_OF_RESOURCES : SHELL_DEVICE_ERROR);
   } else {
 OutSize2 = (UINTN)OutSize;
 Status = gEfiShellProtocol->WriteFile(OutShellFileHandle, 
, OutBuffer);
-- 
2.9.0.windows.1

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

[edk2] [PATCH 06/27] ShellPkg/UefiHandleParsingLib.c: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiHandleParsingLib/UefiHandleParsingLib.c| 55 --
 1 file changed, 31 insertions(+), 24 deletions(-)

diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c 
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
index 7665fd5..c909395 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
@@ -727,8 +727,9 @@ DriverEfiVersionProtocolDumpInformation(
   ASSERT_EFI_ERROR(Status);
 
   RetVal = AllocateZeroPool(VersionStringSize);
-  ASSERT(RetVal != NULL);
-  UnicodeSPrint(RetVal, VersionStringSize, L"0x%08x", 
DriverEfiVersion->FirmwareVersion);
+  if (RetVal != NULL) {
+UnicodeSPrint (RetVal, VersionStringSize, L"0x%08x", 
DriverEfiVersion->FirmwareVersion);
+  }
   return (RetVal);
 }
 /**
@@ -2217,10 +2218,11 @@ InternalShellInitHandleList(
   }
   for (mHandleList.NextIndex = 1 ; mHandleList.NextIndex <= HandleCount ; 
mHandleList.NextIndex++){
 ListWalker = AllocateZeroPool(sizeof(HANDLE_LIST));
-ASSERT(ListWalker != NULL);
-ListWalker->TheHandle = HandleBuffer[mHandleList.NextIndex-1];
-ListWalker->TheIndex  = mHandleList.NextIndex;
-InsertTailList(,>Link);
+if (ListWalker != NULL) {
+  ListWalker->TheHandle = HandleBuffer[mHandleList.NextIndex - 1];
+  ListWalker->TheIndex = mHandleList.NextIndex;
+  InsertTailList (, >Link);
+}
   }
   FreePool(HandleBuffer);
   return (EFI_SUCCESS);
@@ -2288,7 +2290,9 @@ ConvertHandleToHandleIndex(
   FreePool (ProtocolBuffer);
 
   ListWalker = AllocateZeroPool(sizeof(HANDLE_LIST));
-  ASSERT(ListWalker != NULL);
+  if (ListWalker == NULL) {
+return 0;
+  }
   ListWalker->TheHandle = TheHandle;
   ListWalker->TheIndex  = mHandleList.NextIndex++;
   InsertTailList(,>Link);
@@ -2415,7 +2419,10 @@ ParseHandleDatabaseByRelationshipWithType (
   }
 
   *HandleType = AllocateZeroPool (*HandleCount * sizeof (UINTN));
-  ASSERT(*HandleType != NULL);
+  if (*HandleType == NULL) {
+SHELL_FREE_NON_NULL (*HandleBuffer);
+return EFI_OUT_OF_RESOURCES;
+  }
 
   DriverBindingHandleIndex = -1;
   for (HandleIndex = 0; HandleIndex < *HandleCount; HandleIndex++) {
@@ -2671,26 +2678,26 @@ ParseHandleDatabaseByRelationship (
 // Allocate a handle buffer for the number of handles that matched the 
attributes in Mask
 //
 *MatchingHandleBuffer = AllocateZeroPool ((*MatchingHandleCount +1)* 
sizeof (EFI_HANDLE));
-ASSERT(*MatchingHandleBuffer != NULL);
+if (*MatchingHandleBuffer != NULL) {
+  for (HandleIndex = 0, *MatchingHandleCount = 0
+   ;  HandleIndex < HandleCount
+   ;  HandleIndex++
+   ) {
+//
+// Fill the allocated buffer with the handles that matched the 
attributes in Mask
+//
+if ((HandleType[HandleIndex] & Mask) == Mask) {
+  (*MatchingHandleBuffer)[(*MatchingHandleCount)++] = 
HandleBuffer[HandleIndex];
+}
+  }
 
-for (HandleIndex = 0,*MatchingHandleCount = 0
-  ;  HandleIndex < HandleCount
-  ;  HandleIndex++
- ){
   //
-  // Fill the allocated buffer with the handles that matched the 
attributes in Mask
+  // Make the last one NULL
   //
-  if ((HandleType[HandleIndex] & Mask) == Mask) {
-(*MatchingHandleBuffer)[(*MatchingHandleCount)++] = 
HandleBuffer[HandleIndex];
-  }
-}
+  (*MatchingHandleBuffer)[*MatchingHandleCount] = NULL;
 
-//
-// Make the last one NULL
-//
-(*MatchingHandleBuffer)[*MatchingHandleCount] = NULL;
-
-Status = EFI_SUCCESS;
+  Status = EFI_SUCCESS;
+} // *MatchingHandleBuffer != NULL (IF)
   } // MacthingHandleBuffer == NULL (ELSE)
 } // *MatchingHandleCount  == 0 (ELSE)
   } // no error on ParseHandleDatabaseByRelationshipWithType
-- 
2.9.0.windows.1

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

[edk2] [PATCH 09/27] ShellPkg/UefiShellCommandLib.c: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiShellCommandLib/UefiShellCommandLib.c  | 34 +-
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c 
b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
index 48e4d4a..a5e44f1 100644
--- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
+++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
@@ -546,9 +546,14 @@ ShellCommandRegisterCommandName (
   // allocate memory for new struct
   //
   Node = AllocateZeroPool(sizeof(SHELL_COMMAND_INTERNAL_LIST_ENTRY));
-  ASSERT(Node != NULL);
+  if (Node == NULL) {
+return RETURN_OUT_OF_RESOURCES;
+  }
   Node->CommandString = AllocateCopyPool(StrSize(CommandString), 
CommandString);
-  ASSERT(Node->CommandString != NULL);
+  if (Node->CommandString == NULL) {
+FreePool (Node);
+return RETURN_OUT_OF_RESOURCES;
+  }
 
   Node->GetManFileName  = GetManFileName;
   Node->CommandHandler  = CommandHandler;
@@ -807,11 +812,20 @@ ShellCommandRegisterAlias (
   // allocate memory for new struct
   //
   Node = AllocateZeroPool(sizeof(ALIAS_LIST));
-  ASSERT(Node != NULL);
+  if (Node == NULL) {
+return RETURN_OUT_OF_RESOURCES;
+  }
   Node->CommandString = AllocateCopyPool(StrSize(Command), Command);
+  if (Node->CommandString == NULL) {
+FreePool (Node);
+return RETURN_OUT_OF_RESOURCES;
+  }
   Node->Alias = AllocateCopyPool(StrSize(Alias), Alias);
-  ASSERT(Node->CommandString != NULL);
-  ASSERT(Node->Alias != NULL);
+  if (Node->Alias == NULL) {
+FreePool (Node->CommandString);
+FreePool (Node);
+return RETURN_OUT_OF_RESOURCES;
+  }
 
   InsertHeadList (, >Link);
 
@@ -1303,7 +1317,10 @@ ShellCommandCreateInitialMappingsAndPaths(
 // Get all Device Paths
 //
 DevicePathList = AllocateZeroPool(sizeof(EFI_DEVICE_PATH_PROTOCOL*) * 
Count);
-ASSERT(DevicePathList != NULL);
+if (DevicePathList == NULL) {
+  SHELL_FREE_NON_NULL (HandleList);
+  return EFI_OUT_OF_RESOURCES;
+}
 
 for (Count = 0 ; HandleList[Count] != NULL ; Count++) {
   DevicePathList[Count] = DevicePathFromHandle(HandleList[Count]);
@@ -1360,7 +1377,10 @@ ShellCommandCreateInitialMappingsAndPaths(
 // Get all Device Paths
 //
 DevicePathList = AllocateZeroPool(sizeof(EFI_DEVICE_PATH_PROTOCOL*) * 
Count);
-ASSERT(DevicePathList != NULL);
+if (DevicePathList == NULL) {
+  SHELL_FREE_NON_NULL (HandleList);
+  return EFI_OUT_OF_RESOURCES;
+}
 
 for (Count = 0 ; HandleList[Count] != NULL ; Count++) {
   DevicePathList[Count] = DevicePathFromHandle(HandleList[Count]);
-- 
2.9.0.windows.1

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

[edk2] [PATCH 03/27] ShellPkg/ShellAddEnvVarToList: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Application/Shell/ShellEnvVar.c   | 39 +-
 ShellPkg/Application/Shell/ShellEnvVar.h   |  7 --
 ShellPkg/Application/Shell/ShellProtocol.c | 30 +--
 3 files changed, 43 insertions(+), 33 deletions(-)

diff --git a/ShellPkg/Application/Shell/ShellEnvVar.c 
b/ShellPkg/Application/Shell/ShellEnvVar.c
index 9f87b90..77bf599 100644
--- a/ShellPkg/Application/Shell/ShellEnvVar.c
+++ b/ShellPkg/Application/Shell/ShellEnvVar.c
@@ -442,8 +442,11 @@ ShellFindEnvVarInList (
 including the tailing CHAR_NULL
   @param Atts   The attributes of the variable.
 
+  @retval EFI_SUCCESS  The environment variable was added to list successfully.
+  @retval others   Some errors happened.
+
 **/
-VOID
+EFI_STATUS
 ShellAddEnvVarToList (
   IN CONST CHAR16 *Key,
   IN CONST CHAR16 *Value,
@@ -452,9 +455,16 @@ ShellAddEnvVarToList (
   )
 {
   ENV_VAR_LIST  *Node;
+  CHAR16*LocalKey;
+  CHAR16*LocalValue;
   
   if (Key == NULL || Value == NULL || ValueSize == 0) {
-return;
+return EFI_INVALID_PARAMETER;
+  }
+
+  LocalValue = AllocateCopyPool (ValueSize, Value);
+  if (LocalValue == NULL) {
+return EFI_OUT_OF_RESOURCES;
   }
 
   //
@@ -467,10 +477,8 @@ ShellAddEnvVarToList (
 if (Node->Key != NULL && StrCmp(Key, Node->Key) == 0) {
   Node->Atts = Atts;
   SHELL_FREE_NON_NULL(Node->Val);
-  Node->Val  = AllocateZeroPool (ValueSize);
-  ASSERT (Node->Val != NULL);
-  CopyMem(Node->Val, Value, ValueSize);
-  return;
+  Node->Val  = LocalValue;
+  return EFI_SUCCESS;
 }
   }
 
@@ -478,16 +486,23 @@ ShellAddEnvVarToList (
   // If the environment varialbe key doesn't exist in list just insert
   // a new node.
   //
+  LocalKey = AllocateCopyPool (StrSize(Key), Key);
+  if (LocalKey == NULL) {
+FreePool (LocalValue);
+return EFI_OUT_OF_RESOURCES;
+  }
   Node = (ENV_VAR_LIST*)AllocateZeroPool (sizeof(ENV_VAR_LIST));
-  ASSERT (Node != NULL);
-  Node->Key = AllocateCopyPool(StrSize(Key), Key);
-  ASSERT (Node->Key != NULL);
-  Node->Val = AllocateCopyPool(ValueSize, Value);
-  ASSERT (Node->Val != NULL);
+  if (Node == NULL) {
+FreePool (LocalKey);
+FreePool (LocalValue);
+return EFI_OUT_OF_RESOURCES;
+  }
+  Node->Key = LocalKey;
+  Node->Val = LocalValue;
   Node->Atts = Atts;
   InsertTailList(, >Link);
 
-  return;
+  return EFI_SUCCESS;
 }
 
 /**
diff --git a/ShellPkg/Application/Shell/ShellEnvVar.h 
b/ShellPkg/Application/Shell/ShellEnvVar.h
index 5356580..f05ef2b 100644
--- a/ShellPkg/Application/Shell/ShellEnvVar.h
+++ b/ShellPkg/Application/Shell/ShellEnvVar.h
@@ -240,11 +240,14 @@ ShellFindEnvVarInList (
   @param KeyThe name of the environment variable.
   @param Value  The value of environment variable.
   @param ValueSize  The size in bytes of the environment variable
-including the tailing CHAR_NELL
+including the tailing CHAR_NULL
   @param Atts   The attributes of the variable.
 
+  @retval EFI_SUCCESS  The environment variable was added to list successfully.
+  @retval others   Some errors happened.
+
 **/
-VOID
+EFI_STATUS
 ShellAddEnvVarToList (
   IN CONST CHAR16 *Key,
   IN CONST CHAR16 *Value,
diff --git a/ShellPkg/Application/Shell/ShellProtocol.c 
b/ShellPkg/Application/Shell/ShellProtocol.c
index 39b0e78..a95da00 100644
--- a/ShellPkg/Application/Shell/ShellProtocol.c
+++ b/ShellPkg/Application/Shell/ShellProtocol.c
@@ -2852,36 +2852,28 @@ InternalEfiShellSetEnv(
   )
 {
   EFI_STATUS  Status;
-  UINT32  Atts;
 
-  Atts = 0x0;
-  
   if (Value == NULL || StrLen(Value) == 0) {
 Status = SHELL_DELETE_ENVIRONMENT_VARIABLE(Name);
 if (!EFI_ERROR(Status)) {
   ShellRemvoeEnvVarFromList(Name);
 }
-return Status;
   } else {
 SHELL_DELETE_ENVIRONMENT_VARIABLE(Name);
-if (Volatile) {
-  Status = SHELL_SET_ENVIRONMENT_VARIABLE_V(Name, StrSize(Value), Value);
-  if (!EFI_ERROR(Status)) {
-Atts   &= ~EFI_VARIABLE_NON_VOLATILE;
-Atts   |= EFI_VARIABLE_BOOTSERVICE_ACCESS;
-ShellAddEnvVarToList(Name, Value, StrSize(Value), Atts);
+Status = ShellAddEnvVarToList(
+   Name, Value, StrSize(Value),
+   EFI_VARIABLE_BOOTSERVICE_ACCESS | (Volatile ? 0 : 
EFI_VARIABLE_NON_VOLATILE)
+   );
+if (!EFI_ERROR (Status)) {
+  Status = Volatile
+ ? SHELL_SET_ENVIRONMENT_VARIABLE_V(Name, StrSize(Value), Value)
+ : SHELL_SET_ENVIRONMENT_VARIABLE_NV(Name, StrSize(Value), Value);
+  if (EFI_ERROR (Status)) {
+ShellRemvoeEnvVarFromList(Name);
   }
-  return Status;
-} else {
-  Status = SHELL_SET_ENVIRONMENT_VARIABLE_NV(Name, StrSize(Value), Value);
-  if 

[edk2] [PATCH 08/27] ShellPkg/ConsistMapping.c: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../Library/UefiShellCommandLib/ConsistMapping.c   | 497 +
 1 file changed, 319 insertions(+), 178 deletions(-)

diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c 
b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
index 41754dd..82d4f1f 100644
--- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
+++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
@@ -53,10 +53,12 @@ typedef struct {
   @param  MapInfo  The map info.
   @param  OrigDevPath  The original device path protocol.
 
+  @retval EFI_OUT_OF_RESOURCESOut of resources.
+  @retval EFI_SUCCESS The appending was successful.
 **/
 typedef 
-VOID 
-(EFIAPI *SERIAL_DECODE_FUNCTION) (
+EFI_STATUS 
+(*SERIAL_DECODE_FUNCTION) (
   EFI_DEVICE_PATH_PROTOCOL*DevPath, 
   DEVICE_CONSIST_MAPPING_INFO *MapInfo,
   EFI_DEVICE_PATH_PROTOCOL*OrigDevPath
@@ -78,13 +80,11 @@ typedef struct {
   @param  Fmt  The format string
   @param  ...  The data will be printed.
 
-  @return Allocated buffer with the formatted string printed in it.
-  The caller must free the allocated buffer.
-  The buffer allocation is not packed.
+  @retval EFI_SUCCESS  The string is concatenated successfully.
+  @retval EFI_OUT_OF_RESOURCES Out of resources.
 
 **/
-CHAR16 *
-EFIAPI
+EFI_STATUS
 CatPrint (
   IN OUT POOL_PRINT   *Str,
   IN CHAR16   *Fmt,
@@ -94,37 +94,40 @@ CatPrint (
   UINT16  *AppendStr;
   VA_LIST Args;
   UINTN   StringSize;
+  CHAR16  *NewStr;
 
   AppendStr = AllocateZeroPool (0x1000);
   if (AppendStr == NULL) {
-ASSERT(FALSE);
-return Str->Str;
+return EFI_OUT_OF_RESOURCES;
   }
 
   VA_START (Args, Fmt);
   UnicodeVSPrint (AppendStr, 0x1000, Fmt, Args);
   VA_END (Args);
   if (NULL == Str->Str) {
-StringSize   = StrSize (AppendStr);
-Str->Str  = AllocateZeroPool (StringSize);
-ASSERT (Str->Str != NULL);
+StringSize = StrSize (AppendStr);
+NewStr = AllocateZeroPool (StringSize);
   } else {
 StringSize = StrSize (AppendStr);
 StringSize += (StrSize (Str->Str) - sizeof (UINT16));
 
-Str->Str = ReallocatePool (
-StrSize (Str->Str),
-StringSize,
-Str->Str
+NewStr = ReallocatePool (
+   StrSize (Str->Str),
+   StringSize,
+   Str->Str
);
-ASSERT (Str->Str != NULL);
+  }
+  if (NewStr == NULL) {
+FreePool (AppendStr);
+return EFI_OUT_OF_RESOURCES;
   }
 
+  Str->Str = NewStr;
   StrCatS (Str->Str, StringSize/sizeof(CHAR16), AppendStr);
   Str->Len = StringSize;
 
   FreePool (AppendStr);
-  return Str->Str;
+  return EFI_SUCCESS;
 }
 
 MTD_NAME  mMTDName[] = {
@@ -156,30 +159,30 @@ MTD_NAME  mMTDName[] = {
   @param[in, out] Str  The string so append onto.
   @param[in]  Num  The number to divide and append.
 
-  @retval EFI_INVALID_PARAMETER   A parameter was NULL.
+  @retval EFI_OUT_OF_RESOURCESOut of resources.
   @retval EFI_SUCCESS The appending was successful.
 **/
 EFI_STATUS
-EFIAPI
 AppendCSDNum2 (
   IN OUT POOL_PRINT   *Str,
   IN UINT64   Num
   )
 {
-  UINT64  Result;
-  UINT32   Rem;
+  EFI_STATUS Status;
+  UINT64 Result;
+  UINT32 Rem;
 
-  if (Str == NULL) {
-return (EFI_INVALID_PARAMETER);
-  }
+  ASSERT (Str != NULL);
 
   Result = DivU64x32Remainder (Num, 25, );
   if (Result > 0) {
-AppendCSDNum2 (Str, Result);
+Status = AppendCSDNum2 (Str, Result);
+if (EFI_ERROR (Status)) {
+  return Status;
+}
   }
 
-  CatPrint (Str, L"%c", Rem + 'a');
-  return (EFI_SUCCESS);
+  return CatPrint (Str, L"%c", Rem + 'a');
 }
 
 /**
@@ -188,29 +191,30 @@ AppendCSDNum2 (
   @param[in, out] MappingItem  The mapping info object to append onto.
   @param[in]  Num  The info to append.
 
-  @retval EFI_INVALID_PARAMETER   A parameter was NULL.
+  @retval EFI_OUT_OF_RESOURCESOut of resources.
   @retval EFI_SUCCESS The appending was successful.
+
 **/
 EFI_STATUS
-EFIAPI
 AppendCSDNum (
   IN OUT DEVICE_CONSIST_MAPPING_INFO*MappingItem,
   IN UINT64 Num
   )
 {
-  if (MappingItem == NULL) {
-return EFI_INVALID_PARAMETER;
-  }
+  EFI_STATUS Status;
+  ASSERT (MappingItem != NULL);
 
   if (MappingItem->Digital) {
-CatPrint (>Csd, L"%ld", Num);
+Status = CatPrint (>Csd, L"%ld", Num);
   } else {
-AppendCSDNum2 (>Csd, Num);
+Status = AppendCSDNum2 (>Csd, Num);
   }
 
-  MappingItem->Digital = (BOOLEAN)!(MappingItem->Digital);
+  if (!EFI_ERROR (Status)) {
+MappingItem->Digital = (BOOLEAN) !(MappingItem->Digital);
+  }
 
-  return (EFI_SUCCESS);
+  return Status;
 }
 
 /**
@@ -219,21 +223,21 @@ AppendCSDNum (
   @param[in, out] MappingItem  The mapping info object 

[edk2] [PATCH 14/27] ShellPkg/Edit: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiShellDebug1CommandsLib/Edit/FileBuffer.c   | 41 +++---
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
index acd8512..efe0df0 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
@@ -1,7 +1,7 @@
 /** @file
   Implements filebuffer interface functions.
 
-  Copyright (c) 2005 - 2015, Intel Corporation. All rights reserved. 
+  Copyright (c) 2005 - 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
@@ -505,29 +505,28 @@ FileBufferPrintLine (
 
   BufLen = (MainEditor.ScreenSize.Column + 1) * sizeof (CHAR16);
   PrintLine = AllocatePool (BufLen);
-  ASSERT (PrintLine != NULL);
-
-  StrnCpyS (PrintLine, BufLen/sizeof(CHAR16), Buffer, MIN(Limit, 
MainEditor.ScreenSize.Column));
-  for (; Limit < MainEditor.ScreenSize.Column; Limit++) {
-PrintLine[Limit] = L' ';
-  }
-
-  PrintLine[MainEditor.ScreenSize.Column] = CHAR_NULL;
-
-  PrintLine2 = AllocatePool (BufLen * 2);
-  ASSERT (PrintLine2 != NULL);
+  if (PrintLine != NULL) {
+StrnCpyS (PrintLine, BufLen/sizeof(CHAR16), Buffer, MIN(Limit, 
MainEditor.ScreenSize.Column));
+for (; Limit < MainEditor.ScreenSize.Column; Limit++) {
+  PrintLine[Limit] = L' ';
+}
 
-  ShellCopySearchAndReplace(PrintLine, PrintLine2, BufLen * 2, L"%", L"^%", 
FALSE, FALSE);
+PrintLine[MainEditor.ScreenSize.Column] = CHAR_NULL;
 
-  ShellPrintEx (
-0,
-(INT32)Row - 1,
-L"%s",
-PrintLine2
-);
+PrintLine2 = AllocatePool (BufLen * 2);
+if (PrintLine2 != NULL) {
+  ShellCopySearchAndReplace(PrintLine, PrintLine2, BufLen * 2, L"%", 
L"^%", FALSE, FALSE);
 
-  FreePool (PrintLine);
-  FreePool (PrintLine2);
+  ShellPrintEx (
+0,
+(INT32)Row - 1,
+L"%s",
+PrintLine2
+);
+  FreePool (PrintLine2);
+}
+FreePool (PrintLine);
+  }
 
   return EFI_SUCCESS;
 }
-- 
2.9.0.windows.1

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

[edk2] [PATCH 10/27] ShellPkg/DMem: Handle memory allocation failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
index 7693835..5491f6d 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
@@ -1,7 +1,7 @@
 /** @file
   Main file for Dmem shell Debug1 function.
 
-  Copyright (c) 2010 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.  
   (C) Copyright 2015 Hewlett Packard Enterprise Development LP  
   This program and the accompanying materials
@@ -68,7 +68,9 @@ DisplayMmioMemory(
 return (SHELL_NOT_FOUND);
   }
   Buffer = AllocateZeroPool(Size);
-  ASSERT(Buffer != NULL);
+  if (Buffer == NULL) {
+return SHELL_OUT_OF_RESOURCES;
+  }
 
   Status = PciRbIo->Mem.Read(PciRbIo, EfiPciWidthUint8, 
(UINT64)(UINTN)Address, Size, Buffer);
   if (EFI_ERROR(Status)) {
-- 
2.9.0.windows.1

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