[edk2] Memory Profile question.

[Andrew Fish]

I've done some experimentation on the memory logging and if possible it is very 
useful to have 4 stack frames (non-LTO)  as it is common for the 
MemoryAllocationLib to to call a sequence of Internal functions, so to find the 
calling spot in the driver you need 4 entries. 
For example:
FunctionThatAllocatePool()
AllocateZeroPool()
InternalAllocateZeroPool()
InternalAllocatePool()

I see that only RETURN_ADDRESS (0) is logged. 

MdeModulePkg/Core/Dxe/Mem/Page.c:1338:CoreUpdateProfile 
((EFI_PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS (0), 
MemoryProfileActionAllocatePages, MemoryType, EFI_PAGES_TO_SIZE 
(NumberOfPages), (VOID *) (UINTN) *Memory);
MdeModulePkg/Core/Dxe/Mem/Page.c:1447:CoreUpdateProfile 
((EFI_PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS (0), 
MemoryProfileActionFreePages, MemoryType, EFI_PAGES_TO_SIZE (NumberOfPages), 
(VOID *) (UINTN) Memory);
MdeModulePkg/Core/Dxe/Mem/Pool.c:279:CoreUpdateProfile 
((EFI_PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS (0), 
MemoryProfileActionAllocatePool, PoolType, Size, *Buffer);
MdeModulePkg/Core/Dxe/Mem/Pool.c:508:CoreUpdateProfile 
((EFI_PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS (0), 
MemoryProfileActionFreePool, PoolType, 0, Buffer);

On platforms that emit frame pointers you can do RETURN_ADDRESS (0), 
RETURN_ADDRESS (1), RETURN_ADDRESS (2), and RETURN_ADDRESS (3) and it is very 
useful to find the location of the allocation. Is it possible to log more data 
on platforms that can support it? Is there some alternate scheme that is planed 
to find the driver code calling the MemoryAllocationLib function?

Thanks,

Andrew Fish


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

Re: [edk2] [Patch] IntelFrameworkModulePkg StatusCode RuntimeDxe: Remove duplicated structure.

[Shia, Cinnamon]

Reviewed-by: Cinnamon Shia 

-Original Message-
From: Liming Gao [mailto:liming@intel.com] 
Sent: Thursday, June 30, 2016 10:38 AM
To: edk2-devel@lists.01.org
Cc: Shia, Cinnamon 
Subject: [Patch] IntelFrameworkModulePkg StatusCode RuntimeDxe: Remove 
duplicated structure.

RUNTIME_MEMORY_STATUSCODE_HEADER has been moved into MdeModulePkg public header 
file Include/Guid/MemoryStatusCodeRecord.h. It should be removed from the 
driver.

Cc: Cinnamon Shia 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 .../Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h   | 9 -
 1 file changed, 9 deletions(-)

diff --git 
a/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h
 
b/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h
index 9d0ed19..ae20f5b 100644
--- 
a/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h
+++ b/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCode
+++ RuntimeDxe.h
@@ -53,15 +53,6 @@ typedef struct {
 } DATAHUB_STATUSCODE_RECORD;
 
 
-//
-// Runtime memory status code worker definition -// -typedef struct {
-  UINT32   RecordIndex;
-  UINT32   NumberOfRecords;
-  UINT32   MaxRecordsNumber;
-} RUNTIME_MEMORY_STATUSCODE_HEADER;
-
 extern RUNTIME_MEMORY_STATUSCODE_HEADER  *mRtMemoryStatusCodeTable;
 
 /**
--
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 0/3] Add FrameBufferBltLib and GraphicsOutputDxe to MdeModulePkg

[Ni, Ruiyu]

Jordan,
Thanks for the suggestions.
I agree with both of your suggestions.

What's your plan about BltLib in OptionRomPkg?

Thanks,
Ray

> -Original Message-
> From: Justen, Jordan L
> Sent: Thursday, June 30, 2016 1:54 PM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v3 0/3] Add FrameBufferBltLib and
> GraphicsOutputDxe to MdeModulePkg
> 
> I have two suggestions:
> 
> 1. Split "MdeModulePkg: Add FrameBufferBltLib" into two patches. I
>prefer to add the library "interface" first (.dec and library .h
>files fist), and then add the library implementation second. I like
>to think about the interface as separate from the implementation.
> 
>I don't think this is a strict requirement, but just my suggestion.
> 
> 2. Re-add "OvmfPkg: QemuVideoDxe uses MdeModulePkg/FrameBufferLib"
> 
>I did want you to update OVMF's GOP driver to use the new
>interface.
> 
>But, please also modify the IA32 and X64 .dsc files in that patch.
> 
> This series, with the OVMF patch:
> 
> Reviewed-by: Jordan Justen 
> 
> On 2016-06-29 22:09:29, Ruiyu Ni wrote:
> > The patch serials add FrameBufferBltLib and GraphicsOutputDxe driver
> > to MdeModulePkg.
> > FrameBufferBltLib provides interfaces to perform UEFI Graphics Output
> > Protocol Video BLT operations GraphicsOutputDxe uses the GraphicsInfo
> > HOB and GraphicsDeviceInfo HOB passed from PEI to find the graphics
> > controller to manage and produce the GraphicsOutput protocol.
> >
> > GraphicsInfo HOB and GraphicsDeviceInfo HOB are created by a PEIM
> > which initializes the graphics controller hardware in PEI phase.
> >
> > https://github.com/niruiyu/edk2/commits/Gop3
> >
> > Ruiyu Ni (3):
> >   MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo HOB GUID and
> structure
> >   MdeModulePkg: Add FrameBufferBltLib
> >   MdeModulePkg: Add GraphicsOutputDxe driver.
> >
> >  MdeModulePkg/Include/Library/FrameBufferBltLib.h   |  94 +++
> >  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 704
> 
> >  .../FrameBufferBltLib/FrameBufferBltLib.inf|  34 +
> >  MdeModulePkg/MdeModulePkg.dec  |   4 +
> >  MdeModulePkg/MdeModulePkg.dsc  |   3 +
> >  .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
> >  .../Console/GraphicsOutputDxe/GraphicsOutput.c | 735
> +
> >  .../Console/GraphicsOutputDxe/GraphicsOutput.h |  59 ++
> >  .../GraphicsOutputDxe/GraphicsOutputDxe.inf|  58 ++
> >  MdePkg/Include/Guid/GraphicsInfoHob.h  |  17 +-
> >  MdePkg/MdePkg.dec  |   1 +
> >  11 files changed, 1898 insertions(+), 1 deletion(-)  create mode
> > 100644 MdeModulePkg/Include/Library/FrameBufferBltLib.h
> >  create mode 100644
> > MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> >  create mode 100644
> > MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
> >  create mode 100644
> >
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
> >  create mode 100644
> > MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
> >  create mode 100644
> > MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
> >  create mode 100644
> >
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDx
> e.inf
> >
> > --
> > 2.8.3.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V2 00/11] Enhance memory profile for memory leak detection

[Yao, Jiewen]

The v2 delta is reviewed by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, June 30, 2016 1:34 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Gao, Liming
> ; Zhu, Yonghong 
> Subject: [PATCH V2 00/11] Enhance memory profile for memory leak
> detection
> 
> Current memory profile feature:
> 1. Shows which line of code calls gBS->AllocateXXX(). But most entries
> are from MemoryAllocationLib.
> 2. Records at the start.
> 3. Records all modules.
> 
> Enhanced memory profile feature:
> 1. User can know which line of code calls AllocateXXX() API instead of
> gBS->Allocate().
> 2. User can know which line of code calls a specific API that will call
> AllocateXXX().
> 3. User can know total memory allocated by a specific line of code.
> 4. User can configure to record single module.
> 5. User can configure when to enable recording.
> 6. User can know RVA<->Symbol (Function, Source, Line).
> 
> V2:
> 1. Add [03/11] to add lock to pretect memory profile AllocInfo list.
> 2. Update [09/11] and [10/11] to use seperated inf to support both
> MemoryAllocateLib and MemoryProfileLib.
> 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> 
> Star Zeng (11):
>   MdeModulePkg: Extend memory profile definitions for memory leak
> detection
>   MdeModulePkg DxeCore: Enhance memory profile for memory leak
> detection
>   MdeModulePkg DxeCore: Add lock to pretect memory profile AllocInfo
> list
>   MdeModulePkg PiSmmCore: Enhance memory profile for memory leak
> detection
>   MdeModulePkg MemoryProfileInfo: Enhance output info for memory leak
> detection
>   MdeModulePkg: Introduce new library class MemoryProfileLib
>   MdeModulePkg: Implement new library instance
> UefiMemoryAllocationProfileLib
>   MdeModulePkg: Implement new library instance
> SmmMemoryAllocationProfileLib
>   MdeModulePkg DxeCoreMemoryAllocationLib: Extend to support
> MemoryProfileLib
>   MdeModulePkg PiSmmCoreMemoryAllocLib:  Extend to support
> MemoryProfileLib
>   BaseTools Scripts: Add MemoryProfileSymbolGen.py
> 
>  BaseTools/Scripts/MemoryProfileSymbolGen.py|  281 +
>  .../MemoryProfileInfo/MemoryProfileInfo.c  |  884
> ++---
>  .../MemoryProfileInfo/MemoryProfileInfo.inf|3 +-
>  MdeModulePkg/Core/Dxe/DxeMain.h|   35 +-
>  MdeModulePkg/Core/Dxe/DxeMain.inf  |1 +
>  MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c|  844
> +
>  MdeModulePkg/Core/Dxe/Mem/Page.c   |   18 +-
>  MdeModulePkg/Core/Dxe/Mem/Pool.c   |   18 +-
>  MdeModulePkg/Core/PiSmmCore/Page.c |   20 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.c|3 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h|   57 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf  |6 +-
>  MdeModulePkg/Core/PiSmmCore/Pool.c |   20 +-
>  MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c   | 1319
> +++-
>  MdeModulePkg/Include/Guid/MemoryProfile.h  |  189 ++-
>  MdeModulePkg/Include/Library/MemoryProfileLib.h|   53 +
>  .../DxeCoreMemoryAllocationLib.inf |   13 +-
>  .../DxeCoreMemoryAllocationLib.uni |4 +-
>  ...b.inf => DxeCoreMemoryAllocationProfileLib.inf} |   24 +-
>  .../DxeCoreMemoryAllocationProfileLib.uni  |   23 +
>  .../DxeCoreMemoryProfileLib.c  |   57 +
>  .../DxeCoreMemoryProfileLibNull.c  |   55 +
>  .../DxeCoreMemoryProfileServices.h |   54 +
>  .../MemoryAllocationLib.c  |  277 +++-
>  .../MemoryAllocationLib.c  |  188 ++-
>  .../PiSmmCoreMemoryAllocationLib.inf   |   11 +-
>  .../PiSmmCoreMemoryAllocationLib.uni   |4 +-
>  ...inf => PiSmmCoreMemoryAllocationProfileLib.inf} |   26 +-
>  .../PiSmmCoreMemoryAllocationProfileLib.uni|   23 +
>  .../PiSmmCoreMemoryProfileLib.c|  123 ++
>  .../PiSmmCoreMemoryProfileLibNull.c|   54 +
>  .../PiSmmCoreMemoryProfileServices.h   |   54 +
>  .../MemoryAllocationLib.c  |  613
> ++---
>  .../SmmMemoryAllocationProfileLib.inf  |   62 +
>  .../SmmMemoryAllocationProfileLib.uni  |   23 +
>  .../SmmMemoryProfileLib.c  |  143 +++
>  .../DxeMemoryProfileLib.c  |  102 ++
>  .../MemoryAllocationLib.c  |  312 -
>  .../UefiMemoryAllocationProfileLib.inf |   53 +
>  .../UefiMemoryAllocationProfileLib.uni |   23 +
>  MdeModulePkg/MdeModulePkg.dec  |   20 +
>  MdeModulePkg/MdeModulePkg.dsc  |5 +
>  MdeModulePkg/MdeModulePkg.uni  |   17 +-
>  43 files changed, 5081 insertions(+), 1033 deletions(-)
>  create mode 100644 BaseTools/Scripts/MemoryProf

Re: [edk2] [PATCH v3 0/3] Add FrameBufferBltLib and GraphicsOutputDxe to MdeModulePkg

[Jordan Justen]

I have two suggestions:

1. Split "MdeModulePkg: Add FrameBufferBltLib" into two patches. I
   prefer to add the library "interface" first (.dec and library .h
   files fist), and then add the library implementation second. I like
   to think about the interface as separate from the implementation.

   I don't think this is a strict requirement, but just my suggestion.

2. Re-add "OvmfPkg: QemuVideoDxe uses MdeModulePkg/FrameBufferLib"

   I did want you to update OVMF's GOP driver to use the new
   interface.

   But, please also modify the IA32 and X64 .dsc files in that patch.

This series, with the OVMF patch:

Reviewed-by: Jordan Justen 

On 2016-06-29 22:09:29, Ruiyu Ni wrote:
> The patch serials add FrameBufferBltLib and GraphicsOutputDxe driver to
> MdeModulePkg.
> FrameBufferBltLib provides interfaces to perform UEFI Graphics
> Output Protocol Video BLT operations
> GraphicsOutputDxe uses the GraphicsInfo HOB and GraphicsDeviceInfo HOB
> passed from PEI to find the graphics controller to manage and
> produce the GraphicsOutput protocol.
> 
> GraphicsInfo HOB and GraphicsDeviceInfo HOB are created by
> a PEIM which initializes the graphics controller hardware in
> PEI phase.
> 
> https://github.com/niruiyu/edk2/commits/Gop3
> 
> Ruiyu Ni (3):
>   MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo HOB GUID and structure
>   MdeModulePkg: Add FrameBufferBltLib
>   MdeModulePkg: Add GraphicsOutputDxe driver.
> 
>  MdeModulePkg/Include/Library/FrameBufferBltLib.h   |  94 +++
>  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 704 
>  .../FrameBufferBltLib/FrameBufferBltLib.inf|  34 +
>  MdeModulePkg/MdeModulePkg.dec  |   4 +
>  MdeModulePkg/MdeModulePkg.dsc  |   3 +
>  .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
>  .../Console/GraphicsOutputDxe/GraphicsOutput.c | 735 
> +
>  .../Console/GraphicsOutputDxe/GraphicsOutput.h |  59 ++
>  .../GraphicsOutputDxe/GraphicsOutputDxe.inf|  58 ++
>  MdePkg/Include/Guid/GraphicsInfoHob.h  |  17 +-
>  MdePkg/MdePkg.dec  |   1 +
>  11 files changed, 1898 insertions(+), 1 deletion(-)
>  create mode 100644 MdeModulePkg/Include/Library/FrameBufferBltLib.h
>  create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
>  create mode 100644 
> MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>  create mode 100644 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
>  create mode 100644 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
>  create mode 100644 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
>  create mode 100644 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf
> 
> -- 
> 2.8.3.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] [PATCH V2 11/11] BaseTools Scripts: Add MemoryProfileSymbolGen.py

[Star Zeng]

This tool depends on DIA2Dump.exe (VS) or nm (gcc) to parse debug entry.

Usage: MemoryProfileSymbolGen.py [--version] [-h] [--help] [-i inputfile
[-o outputfile]]

Copyright (c) 2016, Intel Corporation. All rights reserved.

Options:
  --version show program's version number and exit
  -h, --helpshow this help message and exit
  -i INPUTFILENAME, --inputfile=INPUTFILENAME
The input memory profile info file output from
MemoryProfileInfo application in MdeModulePkg
  -o OUTPUTFILENAME, --outputfile=OUTPUTFILENAME
The output memory profile info file with symbol,
MemoryProfileInfoSymbol.txt will be used if it is not

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
---
 BaseTools/Scripts/MemoryProfileSymbolGen.py | 281 
 1 file changed, 281 insertions(+)
 create mode 100644 BaseTools/Scripts/MemoryProfileSymbolGen.py

diff --git a/BaseTools/Scripts/MemoryProfileSymbolGen.py 
b/BaseTools/Scripts/MemoryProfileSymbolGen.py
new file mode 100644
index ..a9790d8883c8
--- /dev/null
+++ b/BaseTools/Scripts/MemoryProfileSymbolGen.py
@@ -0,0 +1,281 @@
+##
+# Generate symbal for memory profile info.
+#
+# This tool depends on DIA2Dump.exe (VS) or nm (gcc) to parse debug entry.
+#
+# Copyright (c) 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 that accompanies this 
distribution.
+# The full text of the license may be found at
+# http://opensource.org/licenses/bsd-license.php.
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+##
+
+import os
+import re
+import sys
+from optparse import OptionParser
+
+versionNumber = "1.0"
+__copyright__ = "Copyright (c) 2016, Intel Corporation. All rights reserved."
+
+class Symbols:
+def __init__(self):
+self.listLineAddress = []
+self.pdbName = ""
+# Cache for function
+self.functionName = ""
+# Cache for line
+self.sourceName = ""
+
+
+def getSymbol (self, rva):
+index = 0
+lineName  = 0
+sourceName = "??"
+while index + 1 < self.lineCount :
+if self.listLineAddress[index][0] <= rva and 
self.listLineAddress[index + 1][0] > rva :
+offset = rva - self.listLineAddress[index][0]
+functionName = self.listLineAddress[index][1]
+lineName = self.listLineAddress[index][2]
+sourceName = self.listLineAddress[index][3]
+if lineName == 0 :
+  return " (" + self.listLineAddress[index][1] + "() - " + ")"
+else :
+  return " (" + self.listLineAddress[index][1] + "() - " + 
sourceName + ":" + str(lineName) + ")"
+index += 1
+
+return " (unknown)"
+
+def parse_debug_file(self, driverName, pdbName):
+if cmp (pdbName, "") == 0 :
+return
+self.pdbName = pdbName;
+
+try:
+nmCommand = "nm"
+nmLineOption = "-l"
+print "parsing (debug) - " + pdbName
+os.system ('%s %s %s > nmDump.line.log' % (nmCommand, 
nmLineOption, pdbName))
+except :
+print 'ERROR: nm command not available.  Please verify PATH'
+return
+
+#
+# parse line
+#
+linefile = open("nmDump.line.log")
+reportLines = linefile.readlines()
+linefile.close()
+
+# 000113ca T AllocatePool  
c:\home\edk-ii\MdePkg\Library\UefiMemoryAllocationLib\MemoryAllocationLib.c:399
+patchLineFileMatchString = 
"([0-9a-fA-F]{8})\s+[T|D|t|d]\s+(\w+)\s*((?:[a-zA-Z]:)?[\w+\-./_a-zA-Z0-9]*):?([0-9]*)"
+
+for reportLine in reportLines:
+#print "check - " + reportLine
+match = re.match(patchLineFileMatchString, reportLine)
+if match is not None:
+#print "match - " + reportLine[:-1]
+#print "0 - " + match.group(0)
+#print "1 - " + match.group(1)
+#print "2 - " + match.group(2)
+#print "3 - " + match.group(3)
+#print "4 - " + match.group(4)
+
+rva = int (match.group(1), 16)
+functionName = match.group(2)
+sourceName = match.group(3)
+if cmp (match.group(4), "") != 0 :
+lineName = int (match.group(4))
+else :
+lineName = 0
+self.listLineAddress.append ([rva, functionName, lineName, 
sourceName])
+
+self.lineCount = len (self.listLineAddress)
+
+self.listL

[edk2] [PATCH V2 07/11] MdeModulePkg: Implement new library instance UefiMemoryAllocationProfileLib

[Star Zeng]

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
---
 .../DxeMemoryProfileLib.c  |  102 ++
 .../MemoryAllocationLib.c  | 1057 
 .../UefiMemoryAllocationProfileLib.inf |   53 +
 .../UefiMemoryAllocationProfileLib.uni |   23 +
 MdeModulePkg/MdeModulePkg.dsc  |1 +
 5 files changed, 1236 insertions(+)
 create mode 100644 
MdeModulePkg/Library/UefiMemoryAllocationProfileLib/DxeMemoryProfileLib.c
 create mode 100644 
MdeModulePkg/Library/UefiMemoryAllocationProfileLib/MemoryAllocationLib.c
 create mode 100644 
MdeModulePkg/Library/UefiMemoryAllocationProfileLib/UefiMemoryAllocationProfileLib.inf
 create mode 100644 
MdeModulePkg/Library/UefiMemoryAllocationProfileLib/UefiMemoryAllocationProfileLib.uni

diff --git 
a/MdeModulePkg/Library/UefiMemoryAllocationProfileLib/DxeMemoryProfileLib.c 
b/MdeModulePkg/Library/UefiMemoryAllocationProfileLib/DxeMemoryProfileLib.c
new file mode 100644
index ..78c75fbc730b
--- /dev/null
+++ b/MdeModulePkg/Library/UefiMemoryAllocationProfileLib/DxeMemoryProfileLib.c
@@ -0,0 +1,102 @@
+/** @file
+  Support routines for memory profile for Dxe phase drivers.
+
+  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  This program and the accompanying materials  
+  are licensed and made available under the terms and conditions of the BSD 
License 
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php.  
  
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
 
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED. 
+
+**/
+
+
+#include 
+
+
+#include 
+#include 
+
+#include 
+
+EDKII_MEMORY_PROFILE_PROTOCOL *mLibProfileProtocol;
+
+/**
+  The constructor function initializes memory profile for DXE phase.
+
+  @param ImageHandleThe firmware allocated handle for the EFI image.
+  @param SystemTableA pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+MemoryProfileLibConstructor (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS   Status;
+
+  Status = gBS->LocateProtocol (
+  &gEdkiiMemoryProfileGuid,
+  NULL,
+  (VOID **) &mLibProfileProtocol
+  );
+  if (EFI_ERROR (Status)) {
+mLibProfileProtocol = NULL;
+  }
+
+  return EFI_SUCCESS;
+}
+
+/**
+  Record memory profile of multilevel caller.
+
+  @param[in] CallerAddress  Address of caller.
+  @param[in] Action Memory profile action.
+  @param[in] MemoryType Memory type.
+EfiMaxMemoryType means the MemoryType is 
unknown.
+  @param[in] Buffer Buffer address.
+  @param[in] Size   Buffer size.
+  @param[in] ActionString   String for memory profile action.
+Only needed for user defined allocate action.
+
+  @return EFI_SUCCESS   Memory profile is updated.
+  @return EFI_UNSUPPORTED   Memory profile is unsupported,
+or memory profile for the image is not 
required,
+or memory profile for the memory type is not 
required.
+  @return EFI_ACCESS_DENIED It is during memory profile data getting.
+  @return EFI_ABORTED   Memory profile recording is not enabled.
+  @return EFI_OUT_OF_RESOURCES  No enough resource to update memory profile 
for allocate action.
+  @return EFI_NOT_FOUND No matched allocate info found for free action.
+
+**/
+EFI_STATUS
+EFIAPI
+MemoryProfileLibRecord (
+  IN PHYSICAL_ADDRESS   CallerAddress,
+  IN MEMORY_PROFILE_ACTION  Action,
+  IN EFI_MEMORY_TYPEMemoryType,
+  IN VOID   *Buffer,
+  IN UINTN  Size,
+  IN CHAR8  *ActionString OPTIONAL
+  )
+{
+  if (mLibProfileProtocol == NULL) {
+return EFI_UNSUPPORTED;
+  }
+  return mLibProfileProtocol->Record (
+mLibProfileProtocol,
+CallerAddress,
+Action,
+MemoryType,
+Buffer,
+Size,
+ActionString
+);
+}
+
diff --git 
a/MdeModulePkg/Library/UefiMemoryAllocationProfileLib/MemoryAllocationLib.c 
b/MdeModulePkg/Library/UefiMemoryAllocationProfileLib/MemoryAllocationLib.c
new file mode 100644
index ..370827ddde33
--- /dev/null
+++ b/MdeModulePkg/Library/UefiMemoryAllocat

[edk2] [PATCH V2 08/11] MdeModulePkg: Implement new library instance SmmMemoryAllocationProfileLib

[Star Zeng]

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
---
 .../MemoryAllocationLib.c  | 1140 
 .../SmmMemoryAllocationProfileLib.inf  |   62 ++
 .../SmmMemoryAllocationProfileLib.uni  |   23 +
 .../SmmMemoryProfileLib.c  |  143 +++
 MdeModulePkg/MdeModulePkg.dsc  |1 +
 5 files changed, 1369 insertions(+)
 create mode 100644 
MdeModulePkg/Library/SmmMemoryAllocationProfileLib/MemoryAllocationLib.c
 create mode 100644 
MdeModulePkg/Library/SmmMemoryAllocationProfileLib/SmmMemoryAllocationProfileLib.inf
 create mode 100644 
MdeModulePkg/Library/SmmMemoryAllocationProfileLib/SmmMemoryAllocationProfileLib.uni
 create mode 100644 
MdeModulePkg/Library/SmmMemoryAllocationProfileLib/SmmMemoryProfileLib.c

diff --git 
a/MdeModulePkg/Library/SmmMemoryAllocationProfileLib/MemoryAllocationLib.c 
b/MdeModulePkg/Library/SmmMemoryAllocationProfileLib/MemoryAllocationLib.c
new file mode 100644
index ..34ff120f4164
--- /dev/null
+++ b/MdeModulePkg/Library/SmmMemoryAllocationProfileLib/MemoryAllocationLib.c
@@ -0,0 +1,1140 @@
+/** @file
+  Support routines for memory allocation routines based 
+  on SMM Services Table services for SMM phase drivers, with memory profile 
support.
+  
+  The PI System Management Mode Core Interface Specification only allows the 
use
+  of EfiRuntimeServicesCode and EfiRuntimeServicesData memory types for memory 
+  allocations through the SMM Services Table as the SMRAM space should be 
+  reserved after BDS phase.  The functions in the Memory Allocation Library use
+  EfiBootServicesData as the default memory allocation type.  For this SMM 
+  specific instance of the Memory Allocation Library, EfiRuntimeServicesData 
+  is used as the default memory type for all allocations. In addition, 
+  allocation for the Reserved memory types are not supported and will always 
+  return NULL.
+
+  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+  This program and the accompanying materials  
+  are licensed and made available under the terms and conditions of the BSD 
License 
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php.  
  
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
 
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED. 
+
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+EFI_SMRAM_DESCRIPTOR  *mSmramRanges;
+UINTN mSmramRangeCount;
+
+/**
+  The constructor function caches SMRAM ranges that are present in the system.
+
+  It will ASSERT() if SMM Access2 Protocol doesn't exist.
+  It will ASSERT() if SMRAM ranges can't be got.
+  It will ASSERT() if Resource can't be allocated for cache SMRAM range. 
+  It will always return EFI_SUCCESS.
+
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+SmmMemoryAllocationLibConstructor (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUSStatus;
+  EFI_SMM_ACCESS2_PROTOCOL  *SmmAccess;
+  UINTN Size;
+
+  //
+  // Locate SMM Access2 Protocol
+  //
+  Status = gBS->LocateProtocol (
+  &gEfiSmmAccess2ProtocolGuid, 
+  NULL, 
+  (VOID **)&SmmAccess
+  );
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Get SMRAM range information
+  //
+  Size = 0;
+  Status = SmmAccess->GetCapabilities (SmmAccess, &Size, NULL);
+  ASSERT (Status == EFI_BUFFER_TOO_SMALL);
+
+  mSmramRanges = (EFI_SMRAM_DESCRIPTOR *) AllocatePool (Size);
+  ASSERT (mSmramRanges != NULL);
+
+  Status = SmmAccess->GetCapabilities (SmmAccess, &Size, mSmramRanges);
+  ASSERT_EFI_ERROR (Status);
+
+  mSmramRangeCount = Size / sizeof (EFI_SMRAM_DESCRIPTOR);
+
+  return EFI_SUCCESS;
+}
+
+/**
+  If SMM driver exits with an error, it must call this routine 
+  to free the allocated resource before the exiting.
+
+  @param[in]  ImageHandle   The firmware allocated handle for the EFI image.
+  @param[in]  SystemTable   A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The deconstructor always returns EFI_SUCCESS.
+**/
+EFI_STATUS
+EFIAPI
+SmmMemoryAllocationLibDestructor (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  FreePool (mSmramRanges);
+
+  return EFI_SUCCESS;
+}
+
+/**
+  Check whether the start address of buffer is within any of the SMRAM ranges.
+
+  @param[in]  Buffer   The pointer to 

[edk2] [PATCH V2 09/11] MdeModulePkg DxeCoreMemoryAllocationLib: Extend to support MemoryProfileLib

[Star Zeng]

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 .../DxeCoreMemoryAllocationLib.inf |  13 +-
 .../DxeCoreMemoryAllocationLib.uni |   4 +-
 ...b.inf => DxeCoreMemoryAllocationProfileLib.inf} |  24 +-
 .../DxeCoreMemoryAllocationProfileLib.uni  |  23 ++
 .../DxeCoreMemoryProfileLib.c  |  57 +
 .../DxeCoreMemoryProfileLibNull.c  |  55 
 .../DxeCoreMemoryProfileServices.h |  54 
 .../MemoryAllocationLib.c  | 277 +++--
 MdeModulePkg/MdeModulePkg.dsc  |   1 +
 9 files changed, 468 insertions(+), 40 deletions(-)
 copy 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/{DxeCoreMemoryAllocationLib.inf 
=> DxeCoreMemoryAllocationProfileLib.inf} (56%)
 create mode 100644 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationProfileLib.uni
 create mode 100644 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryProfileLib.c
 create mode 100644 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryProfileLibNull.c
 create mode 100644 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryProfileServices.h

diff --git 
a/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
 
b/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
index 0747f6e69759..caba8cd4a429 100644
--- 
a/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
+++ 
b/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
@@ -1,10 +1,10 @@
 ## @file
 # Memory Allocation Library instance dedicated to DXE Core.
 # The implementation borrows the DxeCore Memory Allocation services as the 
primitive
-# for memory allocation instead of using UEFI boot servces in an indirect way.
-# It is assumed that this library instance must be linked with DxeCore in this 
package. 
+# for memory allocation instead of using UEFI boot services in an indirect way.
+# It is assumed that this library instance must be linked with DxeCore in this 
package.
 #
-# Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2008 - 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
@@ -24,7 +24,7 @@ [Defines]
   MODULE_TYPE= DXE_CORE
   VERSION_STRING = 1.0
   LIBRARY_CLASS  = MemoryAllocationLib|DXE_CORE
-  
+
 #
 # The following information is for reference only and not required by the 
build tools.
 #
@@ -34,13 +34,12 @@ [Defines]
 [Sources]
   MemoryAllocationLib.c
   DxeCoreMemoryAllocationServices.h
+  DxeCoreMemoryProfileLibNull.c
 
 [Packages]
   MdePkg/MdePkg.dec
-
+  MdeModulePkg/MdeModulePkg.dec
 
 [LibraryClasses]
   DebugLib
   BaseMemoryLib
-
-
diff --git 
a/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.uni
 
b/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.uni
index 85f8c7ec27ca..aa67c8baf182 100644
--- 
a/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.uni
+++ 
b/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.uni
@@ -2,10 +2,10 @@
 // Memory Allocation Library instance dedicated to DXE Core.
 //
 // The implementation borrows the DxeCore Memory Allocation services as the 
primitive
-// for memory allocation instead of using UEFI boot servces in an indirect way.
+// for memory allocation instead of using UEFI boot services in an indirect 
way.
 // It is assumed that this library instance must be linked with DxeCore in 
this package.
 //
-// Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.
+// Copyright (c) 2008 - 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
diff --git 
a/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
 
b/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationProfileLib.inf
similarity index 56%
copy from 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
copy to 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationProfileLib.inf
index 0747f6e69759..a2b5f8c1025d 100644
--- 
a/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
+++ 
b/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationProfileLib.inf
@@ -1,10 +1,10 @@
 ## @file
-# Memory Allocation Library instance dedicated to DXE Core.
-# The implementation borrows the DxeCore Memory Allocation services as the 
primitive
-# for memory allocation instead of using UEFI boot servces in an indirect way.
-# It is assumed that this library instance

[edk2] [PATCH V2 00/11] Enhance memory profile for memory leak detection

[Star Zeng]

Current memory profile feature:
1. Shows which line of code calls gBS->AllocateXXX(). But most entries
are from MemoryAllocationLib.
2. Records at the start.
3. Records all modules.

Enhanced memory profile feature:
1. User can know which line of code calls AllocateXXX() API instead of
gBS->Allocate().
2. User can know which line of code calls a specific API that will call
AllocateXXX().
3. User can know total memory allocated by a specific line of code.
4. User can configure to record single module.
5. User can configure when to enable recording.
6. User can know RVA<->Symbol (Function, Source, Line).

V2:
1. Add [03/11] to add lock to pretect memory profile AllocInfo list.
2. Update [09/11] and [10/11] to use seperated inf to support both
MemoryAllocateLib and MemoryProfileLib.

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Yonghong Zhu 

Star Zeng (11):
  MdeModulePkg: Extend memory profile definitions for memory leak
detection
  MdeModulePkg DxeCore: Enhance memory profile for memory leak detection
  MdeModulePkg DxeCore: Add lock to pretect memory profile AllocInfo
list
  MdeModulePkg PiSmmCore: Enhance memory profile for memory leak
detection
  MdeModulePkg MemoryProfileInfo: Enhance output info for memory leak
detection
  MdeModulePkg: Introduce new library class MemoryProfileLib
  MdeModulePkg: Implement new library instance
UefiMemoryAllocationProfileLib
  MdeModulePkg: Implement new library instance
SmmMemoryAllocationProfileLib
  MdeModulePkg DxeCoreMemoryAllocationLib: Extend to support
MemoryProfileLib
  MdeModulePkg PiSmmCoreMemoryAllocLib:  Extend to support
MemoryProfileLib
  BaseTools Scripts: Add MemoryProfileSymbolGen.py

 BaseTools/Scripts/MemoryProfileSymbolGen.py|  281 +
 .../MemoryProfileInfo/MemoryProfileInfo.c  |  884 ++---
 .../MemoryProfileInfo/MemoryProfileInfo.inf|3 +-
 MdeModulePkg/Core/Dxe/DxeMain.h|   35 +-
 MdeModulePkg/Core/Dxe/DxeMain.inf  |1 +
 MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c|  844 +
 MdeModulePkg/Core/Dxe/Mem/Page.c   |   18 +-
 MdeModulePkg/Core/Dxe/Mem/Pool.c   |   18 +-
 MdeModulePkg/Core/PiSmmCore/Page.c |   20 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c|3 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h|   57 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf  |6 +-
 MdeModulePkg/Core/PiSmmCore/Pool.c |   20 +-
 MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c   | 1319 +++-
 MdeModulePkg/Include/Guid/MemoryProfile.h  |  189 ++-
 MdeModulePkg/Include/Library/MemoryProfileLib.h|   53 +
 .../DxeCoreMemoryAllocationLib.inf |   13 +-
 .../DxeCoreMemoryAllocationLib.uni |4 +-
 ...b.inf => DxeCoreMemoryAllocationProfileLib.inf} |   24 +-
 .../DxeCoreMemoryAllocationProfileLib.uni  |   23 +
 .../DxeCoreMemoryProfileLib.c  |   57 +
 .../DxeCoreMemoryProfileLibNull.c  |   55 +
 .../DxeCoreMemoryProfileServices.h |   54 +
 .../MemoryAllocationLib.c  |  277 +++-
 .../MemoryAllocationLib.c  |  188 ++-
 .../PiSmmCoreMemoryAllocationLib.inf   |   11 +-
 .../PiSmmCoreMemoryAllocationLib.uni   |4 +-
 ...inf => PiSmmCoreMemoryAllocationProfileLib.inf} |   26 +-
 .../PiSmmCoreMemoryAllocationProfileLib.uni|   23 +
 .../PiSmmCoreMemoryProfileLib.c|  123 ++
 .../PiSmmCoreMemoryProfileLibNull.c|   54 +
 .../PiSmmCoreMemoryProfileServices.h   |   54 +
 .../MemoryAllocationLib.c  |  613 ++---
 .../SmmMemoryAllocationProfileLib.inf  |   62 +
 .../SmmMemoryAllocationProfileLib.uni  |   23 +
 .../SmmMemoryProfileLib.c  |  143 +++
 .../DxeMemoryProfileLib.c  |  102 ++
 .../MemoryAllocationLib.c  |  312 -
 .../UefiMemoryAllocationProfileLib.inf |   53 +
 .../UefiMemoryAllocationProfileLib.uni |   23 +
 MdeModulePkg/MdeModulePkg.dec  |   20 +
 MdeModulePkg/MdeModulePkg.dsc  |5 +
 MdeModulePkg/MdeModulePkg.uni  |   17 +-
 43 files changed, 5081 insertions(+), 1033 deletions(-)
 create mode 100644 BaseTools/Scripts/MemoryProfileSymbolGen.py
 create mode 100644 MdeModulePkg/Include/Library/MemoryProfileLib.h
 copy 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/{DxeCoreMemoryAllocationLib.inf 
=> DxeCoreMemoryAllocationProfileLib.inf} (56%)
 create mode 100644 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationProfileLib.uni
 create mode 100644 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryProfileLib.c
 create mode 100644 
MdeModulePkg/Library/DxeCoreMemoryAllocationLib/Dxe

[edk2] [PATCH V2 01/11] MdeModulePkg: Extend memory profile definitions for memory leak detection

[Star Zeng]

Current memory profile feature:
1. Shows which line of code calls gBS->AllocateXXX(). But most entries
are from MemoryAllocationLib.
2. Records at the start.
3. Records all modules.

Enhanced memory profile feature:
1. User can know which line of code calls AllocateXXX() API instead of
gBS->Allocate().
2. User can know which line of code calls a specific API that will call
AllocateXXX().
3. User can know total memory allocated by a specific line of code.
4. User can configure to record single module.
5. User can configure when to enable recording.
6. User can know RVA<->Symbol (Function, Source, Line).

For the enhanced memory profile feature,
1. Extend MEMORY_PROFILE_DRIVER_INFO to include PdbString.
2. Extend MEMORY_PROFILE_ALLOC_INFO to include ActionString.
3. Extend MEMORY_PROFILE_ACTION to indicate action in memory allocation
lib and user defined action.
4. Extend memory profile protocol to include GetRecordingState/
SetRecordingState/Record.
5. Define SMM memory profile protocol.
6. Extend PcdMemoryProfilePropertyMask to support disable recording at
the start.
7. Introduce new PCD PcdMemoryProfileDriverPath to control which drivers
need memory profile data.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
---
 MdeModulePkg/Include/Guid/MemoryProfile.h | 189 --
 MdeModulePkg/MdeModulePkg.dec |  16 +++
 MdeModulePkg/MdeModulePkg.uni |  17 ++-
 3 files changed, 212 insertions(+), 10 deletions(-)

diff --git a/MdeModulePkg/Include/Guid/MemoryProfile.h 
b/MdeModulePkg/Include/Guid/MemoryProfile.h
index 9c70b9df3924..38a64945e368 100644
--- a/MdeModulePkg/Include/Guid/MemoryProfile.h
+++ b/MdeModulePkg/Include/Guid/MemoryProfile.h
@@ -15,6 +15,8 @@
 #ifndef _MEMORY_PROFILE_H_
 #define _MEMORY_PROFILE_H_
 
+#include 
+
 //
 // For BIOS MemoryType (0 ~ EfiMaxMemoryType - 1), it is recorded in 
UsageByType[MemoryType]. (Each valid entry has one entry)
 // For OS MemoryType (0x8000 ~ 0x), it is recorded in 
UsageByType[EfiMaxMemoryType]. (All types are combined into one entry)
@@ -42,7 +44,7 @@ typedef struct {
 } MEMORY_PROFILE_CONTEXT;
 
 #define MEMORY_PROFILE_DRIVER_INFO_SIGNATURE SIGNATURE_32 ('M','P','D','I')
-#define MEMORY_PROFILE_DRIVER_INFO_REVISION 0x0002
+#define MEMORY_PROFILE_DRIVER_INFO_REVISION 0x0003
 
 typedef struct {
   MEMORY_PROFILE_COMMON_HEADER  Header;
@@ -58,6 +60,9 @@ typedef struct {
   UINT64PeakUsage;
   UINT64CurrentUsageByType[EfiMaxMemoryType + 2];
   UINT64PeakUsageByType[EfiMaxMemoryType + 2];
+  UINT16PdbStringOffset;
+  UINT8 Reserved2[6];
+//CHAR8 PdbString[];
 } MEMORY_PROFILE_DRIVER_INFO;
 
 typedef enum {
@@ -67,8 +72,75 @@ typedef enum {
   MemoryProfileActionFreePool = 4,
 } MEMORY_PROFILE_ACTION;
 
+//
+// Below is the detailed MEMORY_PROFILE_ACTION definition.
+//
+//  31   15  9  8  8 7  7 6   6 5-4  3 - 0
+// +--+
+// |User |  |Lib|   |Re|Copy|Zero|Align|Type|Basic|
+// +--+
+//
+
+//
+// Basic Action
+//  1 : AllocatePages
+//  2 : FreePages
+//  3 : AllocatePool
+//  4 : FreePool
+//
+#define MEMORY_PROFILE_ACTION_BASIC_MASK 0xF
+
+//
+// Extension
+//
+#define MEMORY_PROFILE_ACTION_EXTENSION_MASK   0xFFF0
+#define MEMORY_PROFILE_ACTION_EXTENSION_LIB_MASK   0x8000
+#define MEMORY_PROFILE_ACTION_EXTENSION_REALLOC_MASK   0x0200
+#define MEMORY_PROFILE_ACTION_EXTENSION_COPY_MASK  0x0100
+#define MEMORY_PROFILE_ACTION_EXTENSION_ZERO_MASK  0x0080
+#define MEMORY_PROFILE_ACTION_EXTENSION_ALIGN_MASK 0x0040
+#define MEMORY_PROFILE_ACTION_EXTENSION_MEM_TYPE_MASK  0x0030
+#define MEMORY_PROFILE_ACTION_EXTENSION_MEM_TYPE_BASIC 0x
+#define MEMORY_PROFILE_ACTION_EXTENSION_MEM_TYPE_RUNTIME   0x0010
+#define MEMORY_PROFILE_ACTION_EXTENSION_MEM_TYPE_RESERVED  0x0020
+
+//
+// Extension (used by memory allocation lib)
+//
+#define MEMORY_PROFILE_ACTION_LIB_ALLOCATE_PAGES0x8001
+#define MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RUNTIME_PAGES0x8011
+#define MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RESERVED_PAGES   0x8021
+#define MEMORY_PROFILE_ACTION_LIB_FREE_PAGES0x8002
+#define MEMORY_PROFILE_ACTION_LIB_ALLOCATE_ALIGNED_PAGES0x8041
+#define MEMORY_PROFILE_ACTION_LIB_ALLOCATE_ALIGNED_RUNTIME_PAGES0x8051
+#define MEMORY_PROFILE_ACTION_LIB_ALLOCATE_ALIGNED_RESERVED_PAGES   0x8061
+#define MEMORY_PROFILE_ACTION_LIB_FREE_ALIGNED_PAGES0x8042
+#define MEMORY_PROFILE_ACTION_LIB_ALLOCATE_POOL 0x8003
+#define MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RUNTIME_POOL 0x8013
+#define MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RESERVED_POOL

[edk2] [PATCH V2 10/11] MdeModulePkg PiSmmCoreMemoryAllocLib: Extend to support MemoryProfileLib

[Star Zeng]

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 .../MemoryAllocationLib.c  | 188 +++--
 .../PiSmmCoreMemoryAllocationLib.inf   |  11 +-
 .../PiSmmCoreMemoryAllocationLib.uni   |   4 +-
 ...inf => PiSmmCoreMemoryAllocationProfileLib.inf} |  26 +--
 .../PiSmmCoreMemoryAllocationProfileLib.uni|  23 +++
 .../PiSmmCoreMemoryProfileLib.c| 123 ++
 .../PiSmmCoreMemoryProfileLibNull.c|  54 ++
 .../PiSmmCoreMemoryProfileServices.h   |  54 ++
 MdeModulePkg/MdeModulePkg.dsc  |   2 +
 9 files changed, 452 insertions(+), 33 deletions(-)
 copy 
MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/{PiSmmCoreMemoryAllocationLib.inf
 => PiSmmCoreMemoryAllocationProfileLib.inf} (54%)
 create mode 100644 
MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationProfileLib.uni
 create mode 100644 
MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryProfileLib.c
 create mode 100644 
MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryProfileLibNull.c
 create mode 100644 
MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryProfileServices.h

diff --git 
a/MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/MemoryAllocationLib.c 
b/MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/MemoryAllocationLib.c
index 5e13a3eda203..08dd17ba693f 100644
--- a/MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/MemoryAllocationLib.c
+++ b/MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/MemoryAllocationLib.c
@@ -1,5 +1,6 @@
 /** @file
-  Support routines for memory allocation routines based on SMM Core internal 
functions.
+  Support routines for memory allocation routines based on SMM Core internal 
functions,
+  with memory profile support.
   
   The PI System Management Mode Core Interface Specification only allows the 
use
   of EfiRuntimeServicesCode and EfiRuntimeServicesData memory types for memory 
@@ -10,7 +11,7 @@
   In addition, allocation for the Reserved memory types are not supported and 
will 
   always return NULL.
 
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
   This program and the accompanying materials  
   are licensed and made available under the terms and conditions of the BSD 
License 
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -23,13 +24,14 @@
 
 #include 
 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include "PiSmmCoreMemoryAllocationServices.h"
 
+#include 
+
 EFI_SMRAM_DESCRIPTOR  *mSmmCoreMemoryAllocLibSmramRanges= NULL;
 UINTN mSmmCoreMemoryAllocLibSmramRangeCount = 0;
 
@@ -111,7 +113,20 @@ AllocatePages (
   IN UINTN  Pages
   )
 {
-  return InternalAllocatePages (EfiRuntimeServicesData, Pages);
+  VOID  *Buffer;
+
+  Buffer = InternalAllocatePages (EfiRuntimeServicesData, Pages);
+  if (Buffer != NULL) {
+MemoryProfileLibRecord (
+  (PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS(0),
+  MEMORY_PROFILE_ACTION_LIB_ALLOCATE_PAGES,
+  EfiRuntimeServicesData,
+  Buffer,
+  EFI_PAGES_TO_SIZE(Pages),
+  NULL
+  );
+  }
+  return Buffer;
 }
 
 /**
@@ -133,7 +148,20 @@ AllocateRuntimePages (
   IN UINTN  Pages
   )
 {
-  return InternalAllocatePages (EfiRuntimeServicesData, Pages);
+  VOID  *Buffer;
+
+  Buffer = InternalAllocatePages (EfiRuntimeServicesData, Pages);
+  if (Buffer != NULL) {
+MemoryProfileLibRecord (
+  (PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS(0),
+  MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RUNTIME_PAGES,
+  EfiRuntimeServicesData,
+  Buffer,
+  EFI_PAGES_TO_SIZE(Pages),
+  NULL
+  );
+  }
+  return Buffer;
 }
 
 /**
@@ -312,7 +340,20 @@ AllocateAlignedPages (
   IN UINTN  Alignment
   )
 {
-  return InternalAllocateAlignedPages (EfiRuntimeServicesData, Pages, 
Alignment);
+  VOID  *Buffer;
+
+  Buffer = InternalAllocateAlignedPages (EfiRuntimeServicesData, Pages, 
Alignment);
+  if (Buffer != NULL) {
+MemoryProfileLibRecord (
+  (PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS(0),
+  MEMORY_PROFILE_ACTION_LIB_ALLOCATE_ALIGNED_PAGES,
+  EfiRuntimeServicesData,
+  Buffer,
+  EFI_PAGES_TO_SIZE(Pages),
+  NULL
+  );
+  }
+  return Buffer;
 }
 
 /**
@@ -340,7 +381,20 @@ AllocateAlignedRuntimePages (
   IN UINTN  Alignment
   )
 {
-  return InternalAllocateAlignedPages (EfiRuntimeServicesData, Pages, 
Alignment);
+  VOID  *Buffer;
+
+  Buffer = InternalAllocateAlignedPages (EfiRuntimeServicesData, Pages, 
Alignment);
+  if (Buffer != NULL) {
+MemoryProfileLibRecord (
+  (PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS(0),
+  MEMORY_PROFILE_ACTION_LIB_ALLOCATE_ALIGNED_RUNTIME_PAGES,
+  EfiRuntimeServicesData,
+  Buffer,
+  EFI_PAGES_TO_SIZE(

[edk2] [PATCH V2 02/11] MdeModulePkg DxeCore: Enhance memory profile for memory leak detection

[Star Zeng]

1. Implement include GetRecordingState/SetRecordingState/Record for
memory profile protocol.
2. Consume PcdMemoryProfilePropertyMask to support disable recording
at the start.
3. Consume PcdMemoryProfileDriverPath to control which drivers need
memory profile data.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
---
 MdeModulePkg/Core/Dxe/DxeMain.h |  35 +-
 MdeModulePkg/Core/Dxe/DxeMain.inf   |   1 +
 MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c | 818 +---
 MdeModulePkg/Core/Dxe/Mem/Page.c|  18 +-
 MdeModulePkg/Core/Dxe/Mem/Pool.c|  18 +-
 5 files changed, 657 insertions(+), 233 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h b/MdeModulePkg/Core/Dxe/DxeMain.h
index e6b9114d2ee5..743221f6755e 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.h
+++ b/MdeModulePkg/Core/Dxe/DxeMain.h
@@ -2780,11 +2780,13 @@ MemoryProfileInstallProtocol (
   @param DriverEntryImage info.
   @param FileType   Image file type.
 
-  @retval TRUE  Register success.
-  @retval FALSE Register fail.
+  @return EFI_SUCCESS   Register successfully.
+  @return EFI_UNSUPPORTED   Memory profile unsupported,
+or memory profile for the image is not 
required.
+  @return EFI_OUT_OF_RESOURCES  No enough resource for this register.
 
 **/
-BOOLEAN
+EFI_STATUS
 RegisterMemoryProfileImage (
   IN LOADED_IMAGE_PRIVATE_DATA  *DriverEntry,
   IN EFI_FV_FILETYPEFileType
@@ -2795,11 +2797,13 @@ RegisterMemoryProfileImage (
 
   @param DriverEntryImage info.
 
-  @retval TRUE  Unregister success.
-  @retval FALSE Unregister fail.
+  @return EFI_SUCCESS   Unregister successfully.
+  @return EFI_UNSUPPORTED   Memory profile unsupported,
+or memory profile for the image is not 
required.
+  @return EFI_NOT_FOUND The image is not found.
 
 **/
-BOOLEAN
+EFI_STATUS
 UnregisterMemoryProfileImage (
   IN LOADED_IMAGE_PRIVATE_DATA  *DriverEntry
   );
@@ -2810,20 +2814,31 @@ UnregisterMemoryProfileImage (
   @param CallerAddress  Address of caller who call Allocate or Free.
   @param Action This Allocate or Free action.
   @param MemoryType Memory type.
+EfiMaxMemoryType means the MemoryType is unknown.
   @param Size   Buffer size.
   @param Buffer Buffer address.
+  @param ActionString   String for memory profile action.
+Only needed for user defined allocate action.
 
-  @retval TRUE  Profile udpate success.
-  @retval FALSE Profile update fail.
+  @return EFI_SUCCESS   Memory profile is updated.
+  @return EFI_UNSUPPORTED   Memory profile is unsupported,
+or memory profile for the image is not 
required,
+or memory profile for the memory type is not 
required.
+  @return EFI_ACCESS_DENIED It is during memory profile data getting.
+  @return EFI_ABORTED   Memory profile recording is not enabled.
+  @return EFI_OUT_OF_RESOURCES  No enough resource to update memory profile 
for allocate action.
+  @return EFI_NOT_FOUND No matched allocate info found for free action.
 
 **/
-BOOLEAN
+EFI_STATUS
+EFIAPI
 CoreUpdateProfile (
   IN EFI_PHYSICAL_ADDRESS   CallerAddress,
   IN MEMORY_PROFILE_ACTION  Action,
   IN EFI_MEMORY_TYPEMemoryType,
   IN UINTN  Size,   // Valid for 
AllocatePages/FreePages/AllocatePool
-  IN VOID   *Buffer
+  IN VOID   *Buffer,
+  IN CHAR8  *ActionString OPTIONAL
   );
 
 /**
diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index e3e4d036dbea..450da579e0fc 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -187,6 +187,7 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxEfiSystemTablePointerAddress ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdMemoryProfileMemoryType ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdMemoryProfilePropertyMask   ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdMemoryProfileDriverPath ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable   ## 
CONSUMES
 
 # [Hob]
diff --git a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c 
b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
index 6626e101592e..1ba8488a0e04 100644
--- a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
+++ b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
@@ -17,6 +17,9 @@
 
 #define IS_UEFI_MEMORY_PROFILE_ENABLED ((PcdGet8 
(PcdMemoryProfilePropertyMask) & BIT0) != 0)
 
+#define GET_OCCUPIED_SIZE(ActualSize, Alignment) \
+  ((ActualSize) + (((Alignment) - ((ActualSize) & ((Alignment) - 1))) & 
((Alignment) - 1)))
+
 typ

[edk2] [PATCH V2 06/11] MdeModulePkg: Introduce new library class MemoryProfileLib

[Star Zeng]

Provides services to record memory profile of multilevel caller.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
---
 MdeModulePkg/Include/Library/MemoryProfileLib.h | 53 +
 MdeModulePkg/MdeModulePkg.dec   |  4 ++
 2 files changed, 57 insertions(+)
 create mode 100644 MdeModulePkg/Include/Library/MemoryProfileLib.h

diff --git a/MdeModulePkg/Include/Library/MemoryProfileLib.h 
b/MdeModulePkg/Include/Library/MemoryProfileLib.h
new file mode 100644
index ..8543801391eb
--- /dev/null
+++ b/MdeModulePkg/Include/Library/MemoryProfileLib.h
@@ -0,0 +1,53 @@
+/** @file
+  Provides services to record memory profile of multilevel caller.
+
+  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  This program and the accompanying materials  
+  are licensed and made available under the terms and conditions of the BSD 
License 
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php.  
  
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
 
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED. 
+
+**/
+
+#ifndef _MEMORY_PROFILE_LIB_H_
+#define _MEMORY_PROFILE_LIB_H_
+
+#include 
+
+/**
+  Record memory profile of multilevel caller.
+
+  @param[in] CallerAddress  Address of caller.
+  @param[in] Action Memory profile action.
+  @param[in] MemoryType Memory type.
+EfiMaxMemoryType means the MemoryType is 
unknown.
+  @param[in] Buffer Buffer address.
+  @param[in] Size   Buffer size.
+  @param[in] ActionString   String for memory profile action.
+Only needed for user defined allocate action.
+
+  @return EFI_SUCCESS   Memory profile is updated.
+  @return EFI_UNSUPPORTED   Memory profile is unsupported,
+or memory profile for the image is not 
required,
+or memory profile for the memory type is not 
required.
+  @return EFI_ACCESS_DENIED It is during memory profile data getting.
+  @return EFI_ABORTED   Memory profile recording is not enabled.
+  @return EFI_OUT_OF_RESOURCES  No enough resource to update memory profile 
for allocate action.
+  @return EFI_NOT_FOUND No matched allocate info found for free action.
+
+**/
+EFI_STATUS
+EFIAPI
+MemoryProfileLibRecord (
+  IN PHYSICAL_ADDRESS   CallerAddress,
+  IN MEMORY_PROFILE_ACTION  Action,
+  IN EFI_MEMORY_TYPEMemoryType,
+  IN VOID   *Buffer,
+  IN UINTN  Size,
+  IN CHAR8  *ActionString OPTIONAL
+  );
+
+#endif
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 4c1ac7b2a226..be6ad1fd0dcf 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -153,6 +153,10 @@ [LibraryClasses]
   #
   PciHostBridgeLib|Include/Library/PciHostBridgeLib.h
 
+  ## @libraryclass  Provides services to record memory profile of multilevel 
caller.
+  #
+  MemoryProfileLib|Include/Library/MemoryProfileLib.h
+
 [Guids]
   ## MdeModule package token space guid
   # Include/Guid/MdeModulePkgTokenSpace.h
-- 
2.7.0.windows.1

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

[edk2] [PATCH V2 05/11] MdeModulePkg MemoryProfileInfo: Enhance output info for memory leak detection

[Star Zeng]

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
---
 .../MemoryProfileInfo/MemoryProfileInfo.c  | 884 +
 .../MemoryProfileInfo/MemoryProfileInfo.inf|   3 +-
 2 files changed, 725 insertions(+), 162 deletions(-)

diff --git a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c 
b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
index ea2a00bd8340..48d8f4657ba6 100644
--- a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
+++ b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
@@ -1,17 +1,16 @@
 /** @file
-  
+
   Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
-  This program and the accompanying materials  
-  are licensed and made available under the terms and conditions of the BSD 
License 
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php   
 
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
 
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
 
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED. 
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
 **/
 
-#include 
 #include 
 #include 
 #include 
@@ -23,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -33,126 +31,202 @@
 #include 
 #include 
 
-CHAR16 *mActionString[] = {
-  L"Unknown",
-  L"AllocatePages",
-  L"FreePages",
-  L"AllocatePool",
-  L"FreePool",
+CHAR8 *mActionString[] = {
+  "Unknown",
+  "gBS->AllocatePages",
+  "gBS->FreePages",
+  "gBS->AllocatePool",
+  "gBS->FreePool",
+};
+
+CHAR8 *mSmmActionString[] = {
+  "SmmUnknown",
+  "gSmst->SmmAllocatePages",
+  "gSmst->SmmFreePages",
+  "gSmst->SmmAllocatePool",
+  "gSmst->SmmFreePool",
+};
+
+typedef struct {
+  MEMORY_PROFILE_ACTION  Action;
+  CHAR8 *String;
+} ACTION_STRING;
+
+ACTION_STRING mExtActionString[] = {
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_PAGES,
"Lib:AllocatePages"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RUNTIME_PAGES,
"Lib:AllocateRuntimePages"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RESERVED_PAGES,   
"Lib:AllocateReservedPages"},
+  {MEMORY_PROFILE_ACTION_LIB_FREE_PAGES,
"Lib:FreePages"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_ALIGNED_PAGES,
"Lib:AllocateAlignedPages"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_ALIGNED_RUNTIME_PAGES,
"Lib:AllocateAlignedRuntimePages"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_ALIGNED_RESERVED_PAGES,   
"Lib:AllocateAlignedReservedPages"},
+  {MEMORY_PROFILE_ACTION_LIB_FREE_ALIGNED_PAGES,
"Lib:FreeAlignedPages"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_POOL, 
"Lib:AllocatePool"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RUNTIME_POOL, 
"Lib:AllocateRuntimePool"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RESERVED_POOL,
"Lib:AllocateReservedPool"},
+  {MEMORY_PROFILE_ACTION_LIB_FREE_POOL, 
"Lib:FreePool"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_ZERO_POOL,
"Lib:AllocateZeroPool"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RUNTIME_ZERO_POOL,
"Lib:AllocateRuntimeZeroPool"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RESERVED_ZERO_POOL,   
"Lib:AllocateReservedZeroPool"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_COPY_POOL,
"Lib:AllocateCopyPool"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RUNTIME_COPY_POOL,
"Lib:AllocateRuntimeCopyPool"},
+  {MEMORY_PROFILE_ACTION_LIB_ALLOCATE_RESERVED_COPY_POOL,   
"Lib:AllocateReservedCopyPool"},
+  {MEMORY_PROFILE_ACTION_LIB_REALLOCATE_POOL,   
"Lib:ReallocatePool"},
+  {MEMORY_PROFILE_ACTION_LIB_REALLOCATE_RUNTIME_POOL,   
"Lib:ReallocateRuntimePool"},
+  {MEMORY_PROFILE_ACTION_LIB_REALLOCATE_RESERVED_POOL,  
"Lib:ReallocateReservedPool"},
 };
 
-CHAR16 *mMemoryTypeString[] = {
-  L"EfiReservedMemoryType",
-  L"EfiLoaderCode",
-  L"EfiLoaderData",
-  L"EfiBootServicesCode",
-  L"EfiBootServicesData",
-  L"EfiRuntimeServicesCode",
-  L"EfiRuntimeServicesData",
-  L"EfiConventionalMemory",
-  L"EfiUnusableMemory",
-  L"EfiACPIReclaimMemory",
-  L"EfiACPIMemoryNVS",
-  L"EfiMemoryMappedIO",
-  L"EfiMemoryMappedIOPortSpace",
-  L"EfiPalCode",
-  L"EfiPersistentMemory",
-  L"EfiOSReserved",
-  L"EfiOemReserved",
+CHAR8 mUserDefinedActionString[] = {"UserDefined-0x8000"};
+
+CHAR8 *mMemor

[edk2] [PATCH V2 04/11] MdeModulePkg PiSmmCore: Enhance memory profile for memory leak detection

[Star Zeng]

1. Produce SMM memory profile protocol.
2. Consume PcdMemoryProfilePropertyMask to support disable recording
at the start.
3. Consume PcdMemoryProfileDriverPath to control which drivers need
memory profile data.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
---
 MdeModulePkg/Core/PiSmmCore/Page.c   |   20 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c  |3 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h  |   57 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf|6 +-
 MdeModulePkg/Core/PiSmmCore/Pool.c   |   20 +-
 MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c | 1319 +-
 6 files changed, 1110 insertions(+), 315 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/Page.c 
b/MdeModulePkg/Core/PiSmmCore/Page.c
index 9cc2a4cabc6e..5c04e8c8bf4d 100644
--- a/MdeModulePkg/Core/PiSmmCore/Page.c
+++ b/MdeModulePkg/Core/PiSmmCore/Page.c
@@ -1,7 +1,7 @@
 /** @file
   SMM Memory page management functions.
 
-  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
@@ -226,7 +226,14 @@ SmmAllocatePages (
 
   Status = SmmInternalAllocatePages (Type, MemoryType, NumberOfPages, Memory);
   if (!EFI_ERROR (Status)) {
-SmmCoreUpdateProfile ((EFI_PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS (0), 
MemoryProfileActionAllocatePages, MemoryType, EFI_PAGES_TO_SIZE 
(NumberOfPages), (VOID *) (UINTN) *Memory);
+SmmCoreUpdateProfile (
+  (EFI_PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS (0),
+  MemoryProfileActionAllocatePages,
+  MemoryType,
+  EFI_PAGES_TO_SIZE (NumberOfPages),
+  (VOID *) (UINTN) *Memory,
+  NULL
+  );
   }
   return Status;
 }
@@ -344,7 +351,14 @@ SmmFreePages (
 
   Status = SmmInternalFreePages (Memory, NumberOfPages);
   if (!EFI_ERROR (Status)) {
-SmmCoreUpdateProfile ((EFI_PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS (0), 
MemoryProfileActionFreePages, 0, EFI_PAGES_TO_SIZE (NumberOfPages), (VOID *) 
(UINTN) Memory);
+SmmCoreUpdateProfile (
+  (EFI_PHYSICAL_ADDRESS) (UINTN) RETURN_ADDRESS (0),
+  MemoryProfileActionFreePages,
+  EfiMaxMemoryType,
+  EFI_PAGES_TO_SIZE (NumberOfPages),
+  (VOID *) (UINTN) Memory,
+  NULL
+  );
   }
   return Status;
 }
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index 7245f201fbdf..551560b1fce1 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -1,7 +1,7 @@
 /** @file
   SMM Core Main Entry Point
 
-  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
@@ -632,6 +632,7 @@ SmmMain (
   }
 
   RegisterSmramProfileHandler ();
+  SmramProfileInstallProtocol ();
 
   SmmCoreInstallLoadedImage ();
 
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index 0e9c92abef9a..000864d3aab0 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -2,7 +2,7 @@
   The internal header file includes the common header files, defines
   internal structure and functions used by SmmCore module.
 
-  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
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -885,16 +886,27 @@ SmramProfileInit (
   );
 
 /**
+  Install SMRAM profile protocol.
+
+**/
+VOID
+SmramProfileInstallProtocol (
+  VOID
+  );
+
+/**
   Register SMM image to SMRAM profile.
 
   @param DriverEntrySMM image info.
   @param RegisterToDxe  Register image to DXE.
 
-  @retval TRUE  Register success.
-  @retval FALSE Register fail.
+  @return EFI_SUCCESS   Register successfully.
+  @return EFI_UNSUPPORTED   Memory profile unsupported,
+or memory profile for the image is not 
required.
+  @return EFI_OUT_OF_RESOURCES  No enough resource for this register.
 
 **/
-BOOLEAN
+EFI_STATUS
 RegisterSmramProfileImage (
   IN EFI_SMM_DRIVER_ENTRY   *DriverEntry,
   IN BOOLEAN   

[edk2] [PATCH V2 03/11] MdeModulePkg DxeCore: Add lock to pretect memory profile AllocInfo list

[Star Zeng]

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c | 26 +
 1 file changed, 26 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c 
b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
index 1ba8488a0e04..14c4959f9fe2 100644
--- a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
+++ b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
@@ -63,6 +63,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED MEMORY_PROFILE_CONTEXT_DATA 
mMemoryProfileContext
 };
 GLOBAL_REMOVE_IF_UNREFERENCED MEMORY_PROFILE_CONTEXT_DATA 
*mMemoryProfileContextPtr = NULL;
 
+EFI_LOCK mMemoryProfileLock = EFI_INITIALIZE_LOCK_VARIABLE (TPL_NOTIFY);
 BOOLEAN mMemoryProfileGettingStatus = FALSE;
 BOOLEAN mMemoryProfileRecordingEnable = MEMORY_PROFILE_RECORDING_DISABLE;
 EFI_DEVICE_PATH_PROTOCOL *mMemoryProfileDriverPath;
@@ -218,6 +219,28 @@ EDKII_MEMORY_PROFILE_PROTOCOL mProfileProtocol = {
 };
 
 /**
+  Acquire lock on mMemoryProfileLock.
+**/
+VOID
+CoreAcquireMemoryProfileLock (
+  VOID
+  )
+{
+  CoreAcquireLock (&mMemoryProfileLock);
+}
+
+/**
+  Release lock on mMemoryProfileLock.
+**/
+VOID
+CoreReleaseMemoryProfileLock (
+  VOID
+  )
+{
+  CoreReleaseLock (&mMemoryProfileLock);
+}
+
+/**
   Return memory profile context.
 
   @return Memory profile context.
@@ -1383,6 +1406,7 @@ CoreUpdateProfile (
 return EFI_UNSUPPORTED;
   }
 
+  CoreAcquireMemoryProfileLock ();
   switch (BasicAction) {
 case MemoryProfileActionAllocatePages:
   Status = CoreUpdateProfileAllocate (CallerAddress, Action, MemoryType, 
Size, Buffer, ActionString);
@@ -1401,6 +1425,8 @@ CoreUpdateProfile (
   Status = EFI_UNSUPPORTED;
   break;
   }
+  CoreReleaseMemoryProfileLock ();
+
   return Status;
 }
 
-- 
2.7.0.windows.1

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

Re: [edk2] [PATCH 2/6] NetworkPkg: fix ASSERT_EFI_ERROR() typos

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wu, Jiaxin
> Sent: Wednesday, June 29, 2016 2:35 AM
> To: Laszlo Ersek ; edk2-devel-01  de...@ml01.01.org>
> Cc: Fu, Siyuan 
> Subject: Re: [edk2] [PATCH 2/6] NetworkPkg: fix ASSERT_EFI_ERROR() typos
> 
> Reviewed-By: Wu Jiaxin 
> 
> Best Regards!
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Laszlo Ersek
> > Sent: Tuesday, June 28, 2016 9:26 PM
> > To: edk2-devel-01 
> > Cc: Fu, Siyuan ; Wu, Jiaxin 
> > Subject: [edk2] [PATCH 2/6] NetworkPkg: fix ASSERT_EFI_ERROR() typos
> >
> > A number of code locations use
> >
> >   ASSERT_EFI_ERROR (BooleanExpression)
> >
> > instead of
> >
> >   ASSERT (BooleanExpression)
> >
> > Fix them.
> >
> > Cc: Siyuan Fu 
> > Cc: Jiaxin Wu 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Laszlo Ersek 
> > ---
> >
> > Notes:
> > build tested only
> >
> >  NetworkPkg/IpSecDxe/Ikev2/Sa.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/NetworkPkg/IpSecDxe/Ikev2/Sa.c
> > b/NetworkPkg/IpSecDxe/Ikev2/Sa.c index 74ef79c23719..4cbfac33b134
> > 100644
> > --- a/NetworkPkg/IpSecDxe/Ikev2/Sa.c
> > +++ b/NetworkPkg/IpSecDxe/Ikev2/Sa.c
> > @@ -384,7 +384,7 @@ Ikev2InitPskParser (
> >  // 5. Generate Nr_b
> >  //
> >  IkeSaSession->NrBlock   = IkeGenerateNonce (IKE_NONCE_SIZE);
> > -ASSERT_EFI_ERROR (IkeSaSession->NrBlock != NULL);
> > +ASSERT (IkeSaSession->NrBlock != NULL);
> >  IkeSaSession->NrBlkSize = IKE_NONCE_SIZE;
> >
> >  //
> > --
> > 1.8.3.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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 5/6] UefiCpuPkg: fix ASSERT_EFI_ERROR() typos

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Kinney, Michael D
> Sent: Wednesday, June 29, 2016 2:26 PM
> To: Laszlo Ersek ; edk2-devel-01  de...@ml01.01.org>; Kinney, Michael D 
> Cc: Fan, Jeff 
> Subject: Re: [edk2] [PATCH 5/6] UefiCpuPkg: fix ASSERT_EFI_ERROR() typos
> 
> Reviewed-by: Michael Kinney 
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> > Sent: Tuesday, June 28, 2016 6:26 AM
> > To: edk2-devel-01 
> > Cc: Fan, Jeff 
> > Subject: [edk2] [PATCH 5/6] UefiCpuPkg: fix ASSERT_EFI_ERROR() typos
> >
> > A number of code locations use
> >
> >   ASSERT_EFI_ERROR (BooleanExpression)
> >
> > instead of
> >
> >   ASSERT (BooleanExpression)
> >
> > Fix them.
> >
> > Cc: Jeff Fan 
> > Reported-by: Gerd Hoffmann 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Laszlo Ersek 
> > ---
> >  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> > index 79e23ef6476e..065fb2c24c7d 100644
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> > @@ -78,7 +78,7 @@ InitPagesForPFHandler (
> >//
> >Address = NULL;
> >Address = AllocatePages (MAX_PF_PAGE_COUNT);
> > -  ASSERT_EFI_ERROR (Address != NULL);
> > +  ASSERT (Address != NULL);
> >
> >mPFPageBuffer =  (UINT64)(UINTN) Address;
> >mPFPageIndex = 0;
> > --
> > 1.8.3.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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/6] QuarkPlatformPkg: fix ASSERT_EFI_ERROR() typos

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Kinney, Michael D
> Sent: Wednesday, June 29, 2016 2:27 PM
> To: Laszlo Ersek ; edk2-devel-01  de...@ml01.01.org>; Kinney, Michael D 
> Subject: Re: [edk2] [PATCH 3/6] QuarkPlatformPkg: fix ASSERT_EFI_ERROR()
> typos
> 
> Reviewed-by: Michael Kinney 
> 
> Mike
> 
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Tuesday, June 28, 2016 6:26 AM
> > To: edk2-devel-01 
> > Cc: Kinney, Michael D ; Steele, Kelly
> > 
> > Subject: [PATCH 3/6] QuarkPlatformPkg: fix ASSERT_EFI_ERROR() typos
> >
> > A number of code locations use
> >
> >   ASSERT_EFI_ERROR (BooleanExpression)
> >
> > instead of
> >
> >   ASSERT (BooleanExpression)
> >
> > Fix them.
> >
> > Cc: Michael D Kinney 
> > Cc: Kelly Steele 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Laszlo Ersek 
> > ---
> >
> > Notes:
> > not even build tested
> >
> >  QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c  | 2 +-
> >  QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c  | 2 +-
> >  QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c | 2 +-
> >  QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c| 2 +-
> >  4 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> > b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> > index 309eb041ee92..36300efd3146 100644
> > --- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> > +++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> > @@ -680,7 +680,7 @@ AcpiPlatformEntryPoint (
> >// Init Pci Device PRT PRW information structure from PCD
> >//
> >mConfigData = (PCI_DEVICE_SETTING *)AllocateZeroPool (sizeof
> (PCI_DEVICE_SETTING));
> > -  ASSERT_EFI_ERROR (mConfigData);
> > +  ASSERT (mConfigData != NULL);
> >InitPciDeviceInfoStructure (mConfigData);
> >//
> >// Get the Acpi SDT protocol for manipulation on acpi table
> > diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> > b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> > index 11781e03f4c5..98035bedd58f 100644
> > --- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> > +++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> > @@ -218,7 +218,7 @@ MadtTableInitialize (
> >//ASSERT (NumberOfCPUs <= 2 && NumberOfCPUs > 0);
> >MadtSize = GetAcutalMadtTableSize (&MadtConfigData,
> NumberOfCPUs);
> >Madt = (EFI_ACPI_2_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER
> *)AllocateZeroPool
> > (MadtSize);
> > -  ASSERT_EFI_ERROR (Madt);
> > +  ASSERT (Madt != NULL);
> >//
> >// Initialize MADT Header information
> >//
> > diff --git
> a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> > b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> > index 441f7609a536..39185bc0d5ff 100644
> > --- a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> > +++ b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> > @@ -174,7 +174,7 @@ PlatformFlashLockConfig (
> >//
> >
> >SpiProtocol = LocateSpiProtocol (NULL);  // This routine will not be 
> > called
> in SMM.
> > -  ASSERT_EFI_ERROR (SpiProtocol != NULL);
> > +  ASSERT (SpiProtocol != NULL);
> >if (SpiProtocol != NULL) {
> >  Status = SpiProtocol->Lock (SpiProtocol);
> >
> > diff --git a/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> > b/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> > index df6c1cc23240..6b07d7829328 100644
> > --- a/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> > +++ b/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> > @@ -1034,7 +1034,7 @@ InstallS3Memory (
> >// memory above 1MB. So Memory Callback can set cache for the system
> memory
> >// correctly on S3 boot path, just like it does on Normal boot path.
> >//
> > -  ASSERT_EFI_ERROR ((S3MemoryRangeData->SystemMemoryLength -
> 0x10) > 0);
> > +  ASSERT ((S3MemoryRangeData->SystemMemoryLength - 0x10) >
> 0);
> >BuildResourceDescriptorHob (
> >  EFI_RESOURCE_SYSTEM_MEMORY,
> >  (
> > --
> > 1.8.3.1
> >
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/3] Add FrameBufferBltLib and GraphicsOutputDxe to MdeModulePkg

[Ni, Ruiyu]

All,
I forgot to mention the differences between last version and this version.
This version doesn't remove the BltLib in OptionRomPkg so in all, it doesn't 
touch OptionRomPkg
and OvmfPkg which depends on BltLib.
This version also adopts Laszlo's suggestion to use opaque struct style to hide 
the internal data
structure but also provides meaningful type.

Thanks,
Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Thursday, June 30, 2016 1:09 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v3 0/3] Add FrameBufferBltLib and
> GraphicsOutputDxe to MdeModulePkg
> 
> The patch serials add FrameBufferBltLib and GraphicsOutputDxe driver to
> MdeModulePkg.
> FrameBufferBltLib provides interfaces to perform UEFI Graphics Output
> Protocol Video BLT operations GraphicsOutputDxe uses the GraphicsInfo
> HOB and GraphicsDeviceInfo HOB passed from PEI to find the graphics
> controller to manage and produce the GraphicsOutput protocol.
> 
> GraphicsInfo HOB and GraphicsDeviceInfo HOB are created by a PEIM which
> initializes the graphics controller hardware in PEI phase.
> 
> https://github.com/niruiyu/edk2/commits/Gop3
> 
> Ruiyu Ni (3):
>   MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo HOB GUID and
> structure
>   MdeModulePkg: Add FrameBufferBltLib
>   MdeModulePkg: Add GraphicsOutputDxe driver.
> 
>  MdeModulePkg/Include/Library/FrameBufferBltLib.h   |  94 +++
>  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 704
> 
>  .../FrameBufferBltLib/FrameBufferBltLib.inf|  34 +
>  MdeModulePkg/MdeModulePkg.dec  |   4 +
>  MdeModulePkg/MdeModulePkg.dsc  |   3 +
>  .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
>  .../Console/GraphicsOutputDxe/GraphicsOutput.c | 735
> +
>  .../Console/GraphicsOutputDxe/GraphicsOutput.h |  59 ++
>  .../GraphicsOutputDxe/GraphicsOutputDxe.inf|  58 ++
>  MdePkg/Include/Guid/GraphicsInfoHob.h  |  17 +-
>  MdePkg/MdePkg.dec  |   1 +
>  11 files changed, 1898 insertions(+), 1 deletion(-)  create mode 100644
> MdeModulePkg/Include/Library/FrameBufferBltLib.h
>  create mode 100644
> MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
>  create mode 100644
> MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>  create mode 100644
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
>  create mode 100644
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
>  create mode 100644
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
>  create mode 100644
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDx
> e.inf
> 
> --
> 2.8.3.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] IntelFsp2WrapperPkg: Add error handling for possible NULL ptr dereference

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Hao Wu
> Sent: Wednesday, June 29, 2016 6:57 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen 
> Subject: [edk2] [PATCH v2] IntelFsp2WrapperPkg: Add error handling for
> possible NULL ptr dereference
> 
> Possible NULL pointer dereference for FspmHeaderPtr/FspsHeaderPtr in
> module FspmWrapperPeim/FspsWrapperPeim.
> 
> Add error handling codes to avoid this issue.
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c | 5 +
>  IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c | 5 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> index 6144ad7..c98513e 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> @@ -68,6 +68,11 @@ PeiFspMemoryInit (
>// Copy default FSP-M UPD data from Flash
>//
>FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32
> (PcdFspmBaseAddress));
> +  DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
> +  if (FspmHeaderPtr == NULL) {
> +return EFI_DEVICE_ERROR;
> +  }
> +
>FspmUpdDataPtr = (FSPM_UPD_COMMON *)AllocateZeroPool
> ((UINTN)FspmHeaderPtr->CfgRegionSize);
>ASSERT (FspmUpdDataPtr != NULL);
>SourceData = (UINTN *)((UINTN)FspmHeaderPtr->ImageBase +
> (UINTN)FspmHeaderPtr->CfgRegionOffset);
> diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> index 7a65ad7..c923690 100644
> --- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> @@ -241,6 +241,11 @@ PeiMemoryDiscoveredNotify (
>// Copy default FSP-S UPD data from Flash
>//
>FspsHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32
> (PcdFspsBaseAddress));
> +  DEBUG ((DEBUG_INFO, "FspsHeaderPtr - 0x%x\n", FspsHeaderPtr));
> +  if (FspsHeaderPtr == NULL) {
> +return EFI_DEVICE_ERROR;
> +  }
> +
>FspsUpdDataPtr = (FSPS_UPD_COMMON *)AllocateZeroPool
> ((UINTN)FspsHeaderPtr->CfgRegionSize);
>ASSERT (FspsUpdDataPtr != NULL);
>SourceData = (UINTN *)((UINTN)FspsHeaderPtr->ImageBase +
> (UINTN)FspsHeaderPtr->CfgRegionOffset);
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 3/3] MdeModulePkg: Add GraphicsOutputDxe driver.

[Ruiyu Ni]

The driver uses the GraphicsInfo HOB and GraphicsDeviceInfo HOB
passed from PEI to find the graphics controller to manage and
produce the GraphicsOutput protocol.

GraphicsInfo HOB and GraphicsDeviceInfo HOB are created by
a PEIM which initializes the graphics controller hardware in
PEI phase.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
---
 MdeModulePkg/MdeModulePkg.dsc  |   2 +
 .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
 .../Console/GraphicsOutputDxe/GraphicsOutput.c | 735 +
 .../Console/GraphicsOutputDxe/GraphicsOutput.h |  59 ++
 .../GraphicsOutputDxe/GraphicsOutputDxe.inf|  58 ++
 5 files changed, 1044 insertions(+)
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 63e1f91..186711d 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -82,6 +82,7 @@ [LibraryClasses]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   PalLib|MdePkg/Library/BasePalLibNull/BasePalLibNull.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+  
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   #
   # Misc
   #
@@ -323,6 +324,7 @@ [Components]
   MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
   MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
   MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
+  MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf
   MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
   MdeModulePkg/Universal/DebugPortDxe/DebugPortDxe.inf
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
diff --git a/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c 
b/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
new file mode 100644
index 000..aa19263
--- /dev/null
+++ b/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
@@ -0,0 +1,190 @@
+/** @file
+  UEFI Component Name(2) protocol implementation for the generic GOP driver.
+
+Copyright (c) 2016, Intel Corporation. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+
+**/
+
+#include 
+#include 
+
+extern EFI_COMPONENT_NAME_PROTOCOL  mGraphicsOutputComponentName;
+extern EFI_COMPONENT_NAME2_PROTOCOL mGraphicsOutputComponentName2;
+
+//
+// Driver name table for GraphicsOutput module.
+// It is shared by the implementation of ComponentName & ComponentName2 
Protocol.
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE 
mGraphicsOutputDriverNameTable[] = {
+  {
+"eng;en",
+L"Generic Graphics Output Driver"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+/**
+  Retrieves a Unicode string that is the user readable name of the driver.
+
+  This function retrieves the user readable name of a driver in the form of a
+  Unicode string. If the driver specified by This has a user readable name in
+  the language specified by Language, then a pointer to the driver name is
+  returned in DriverName, and EFI_SUCCESS is returned. If the driver specified
+  by This does not support the language specified by Language,
+  then EFI_UNSUPPORTED is returned.
+
+  @param  This[in]  A pointer to the EFI_COMPONENT_NAME2_PROTOCOL 
or
+EFI_COMPONENT_NAME_PROTOCOL instance.
+
+  @param  Language[in]  A pointer to a Null-terminated ASCII string
+array indicating the language. This is the
+language of the driver name that the caller is
+requesting, and it must match one of the
+languages specified in SupportedLanguages. The
+number of languages supported by a driver is up
+to the driver writer. Language is specified
+in RFC 4646 or ISO 639-2 language code format.
+
+  @param  DriverName[out]   A pointer to the Unicode string to return.
+This Unicode string is the name of the
+driver specified by This in the la

Re: [edk2] [PATCH] IntelFsp2WrapperPkg: Add NULL pointer check by using ASSERT()

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Hao Wu
> Sent: Wednesday, June 29, 2016 6:22 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen 
> Subject: [edk2] [PATCH] IntelFsp2WrapperPkg: Add NULL pointer check by
> using ASSERT()
> 
> Possible NULL pointer dereference for FspmHeaderPtr/FspsHeaderPtr in
> module FspmWrapperPeim/FspsWrapperPeim.
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c | 1 +
>  IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> index 6144ad7..71157c3 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> @@ -68,6 +68,7 @@ PeiFspMemoryInit (
>// Copy default FSP-M UPD data from Flash
>//
>FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32
> (PcdFspmBaseAddress));
> +  ASSERT (FspmHeaderPtr != NULL);
>FspmUpdDataPtr = (FSPM_UPD_COMMON *)AllocateZeroPool
> ((UINTN)FspmHeaderPtr->CfgRegionSize);
>ASSERT (FspmUpdDataPtr != NULL);
>SourceData = (UINTN *)((UINTN)FspmHeaderPtr->ImageBase +
> (UINTN)FspmHeaderPtr->CfgRegionOffset);
> diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> index 7a65ad7..3415629 100644
> --- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> @@ -241,6 +241,7 @@ PeiMemoryDiscoveredNotify (
>// Copy default FSP-S UPD data from Flash
>//
>FspsHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32
> (PcdFspsBaseAddress));
> +  ASSERT (FspsHeaderPtr != NULL);
>FspsUpdDataPtr = (FSPS_UPD_COMMON *)AllocateZeroPool
> ((UINTN)FspsHeaderPtr->CfgRegionSize);
>ASSERT (FspsUpdDataPtr != NULL);
>SourceData = (UINTN *)((UINTN)FspsHeaderPtr->ImageBase +
> (UINTN)FspsHeaderPtr->CfgRegionOffset);
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 0/3] Add FrameBufferBltLib and GraphicsOutputDxe to MdeModulePkg

[Ruiyu Ni]

The patch serials add FrameBufferBltLib and GraphicsOutputDxe driver to
MdeModulePkg.
FrameBufferBltLib provides interfaces to perform UEFI Graphics
Output Protocol Video BLT operations
GraphicsOutputDxe uses the GraphicsInfo HOB and GraphicsDeviceInfo HOB
passed from PEI to find the graphics controller to manage and
produce the GraphicsOutput protocol.

GraphicsInfo HOB and GraphicsDeviceInfo HOB are created by
a PEIM which initializes the graphics controller hardware in
PEI phase.

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

Ruiyu Ni (3):
  MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo HOB GUID and structure
  MdeModulePkg: Add FrameBufferBltLib
  MdeModulePkg: Add GraphicsOutputDxe driver.

 MdeModulePkg/Include/Library/FrameBufferBltLib.h   |  94 +++
 .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 704 
 .../FrameBufferBltLib/FrameBufferBltLib.inf|  34 +
 MdeModulePkg/MdeModulePkg.dec  |   4 +
 MdeModulePkg/MdeModulePkg.dsc  |   3 +
 .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
 .../Console/GraphicsOutputDxe/GraphicsOutput.c | 735 +
 .../Console/GraphicsOutputDxe/GraphicsOutput.h |  59 ++
 .../GraphicsOutputDxe/GraphicsOutputDxe.inf|  58 ++
 MdePkg/Include/Guid/GraphicsInfoHob.h  |  17 +-
 MdePkg/MdePkg.dec  |   1 +
 11 files changed, 1898 insertions(+), 1 deletion(-)
 create mode 100644 MdeModulePkg/Include/Library/FrameBufferBltLib.h
 create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
 create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
 create mode 100644 
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf

-- 
2.8.3.windows.1

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

[edk2] [PATCH v3 2/3] MdeModulePkg: Add FrameBufferBltLib

[Ruiyu Ni]

This library provides interfaces to perform UEFI Graphics
Output Protocol Video BLT operations.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
Cc: Justen Jordan 
Cc: Laszlo Ersek 
---
 MdeModulePkg/Include/Library/FrameBufferBltLib.h   |  94 +++
 .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 704 +
 .../FrameBufferBltLib/FrameBufferBltLib.inf|  34 +
 MdeModulePkg/MdeModulePkg.dec  |   4 +
 MdeModulePkg/MdeModulePkg.dsc  |   1 +
 5 files changed, 837 insertions(+)
 create mode 100644 MdeModulePkg/Include/Library/FrameBufferBltLib.h
 create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
 create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf

diff --git a/MdeModulePkg/Include/Library/FrameBufferBltLib.h 
b/MdeModulePkg/Include/Library/FrameBufferBltLib.h
new file mode 100644
index 000..c92eb94
--- /dev/null
+++ b/MdeModulePkg/Include/Library/FrameBufferBltLib.h
@@ -0,0 +1,94 @@
+/** @file
+  Library for performing UEFI GOP Blt operations on a framebuffer
+
+  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
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+  IMPLIED.
+
+**/
+
+#ifndef __FRAMEBUFFER_BLT_LIB__
+#define __FRAMEBUFFER_BLT_LIB__
+
+#include 
+
+//
+// Opaque structure for the frame buffer configure.
+//
+typedef struct FRAME_BUFFER_CONFIGURE FRAME_BUFFER_CONFIGURE;
+
+/**
+  Create the configuration for a video frame buffer.
+
+  The configuration is returned in the caller provided buffer.
+
+  @param[in] FrameBuffer   Pointer to the start of the frame buffer.
+  @param[in] FrameBufferInfo   Describes the frame buffer characteristics.
+  @param[in,out] Configure The created configuration information.
+  @param[in,out] ConfigureSize Size of the configuration information.
+
+  @retval RETURN_SUCCESSThe configuration was successful created.
+  @retval RETURN_BUFFER_TOO_SMALL   The Configure is to too small. The required
+size is returned in ConfigureSize.
+  @retval RETURN_UNSUPPORTEDThe requested mode is not supported by
+this implementaion.
+**/
+RETURN_STATUS
+EFIAPI
+FrameBufferBltConfigure (
+  IN  VOID  *FrameBuffer,
+  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *FrameBufferInfo,
+  IN OUT  FRAME_BUFFER_CONFIGURE*Configure,
+  IN OUT  UINTN *ConfigureSize
+  );
+
+/**
+  Performs a UEFI Graphics Output Protocol Blt operation.
+
+  @param[in] ConfigurePointer to a configuration which was successfully
+  created by FrameBufferBltConfigure ().
+  @param[in,out] BltBufferThe data to transfer to screen.
+  @param[in] BltOperation The operation to perform.
+  @param[in] SourceX  The X coordinate of the source for BltOperation.
+  @param[in] SourceY  The Y coordinate of the source for BltOperation.
+  @param[in] DestinationX The X coordinate of the destination for
+  BltOperation.
+  @param[in] DestinationY The Y coordinate of the destination for
+  BltOperation.
+  @param[in] WidthThe width of a rectangle in the blt rectangle
+  in pixels.
+  @param[in] Height   The height of a rectangle in the blt rectangle
+  in pixels.
+  @param[in] DeltaNot used for EfiBltVideoFill and
+  EfiBltVideoToVideo operation. If a Delta of 0
+  is used, the entire BltBuffer will be operated
+  on. If a subrectangle of the BltBuffer is
+  used, then Delta represents the number of
+  bytes in a row of the BltBuffer.
+
+  @retval RETURN_INVALID_PARAMETER Invalid parameter were passed in.
+  @retval RETURN_SUCCESS   The Blt operation was performed 
successfully.
+**/
+RETURN_STATUS
+EFIAPI
+FrameBufferBlt (
+  IN FRAME_BUFFER_CONFIGURE *Configure,
+  IN OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL  *BltBuffer, OPTIONAL
+  IN EFI_GRAPHICS_OUTPUT_BLT_OPERATION  BltOperation,
+  IN UINTN  SourceX,
+  IN UINTN  SourceY,
+  IN UINTN  DestinationX,
+  IN UINTN  DestinationY,
+  IN UINTN  

[edk2] [PATCH v3 1/3] MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo HOB GUID and structure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Liming Gao 
---
 MdePkg/Include/Guid/GraphicsInfoHob.h | 17 -
 MdePkg/MdePkg.dec |  1 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Guid/GraphicsInfoHob.h 
b/MdePkg/Include/Guid/GraphicsInfoHob.h
index 3bcead0..b807213 100644
--- a/MdePkg/Include/Guid/GraphicsInfoHob.h
+++ b/MdePkg/Include/Guid/GraphicsInfoHob.h
@@ -1,7 +1,7 @@
 /** @file
   Hob guid for Information about the graphics mode.
 
-  Copyright (c) 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 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
@@ -25,12 +25,27 @@
 0x39f62cce, 0x6825, 0x4669, { 0xbb, 0x56, 0x54, 0x1a, 0xba, 0x75, 0x3a, 
0x07 } \
   }
 
+#define EFI_PEI_GRAPHICS_DEVICE_INFO_HOB_GUID \
+  { \
+0xe5cb2ac9, 0xd35d, 0x4430, { 0x93, 0x6e, 0x1d, 0xe3, 0x32, 0x47, 0x8d, 
0xe7 } \
+  }
+
 typedef struct {
   EFI_PHYSICAL_ADDRESS  FrameBufferBase;
   UINT32FrameBufferSize;
   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  GraphicsMode;
 } EFI_PEI_GRAPHICS_INFO_HOB;
 
+typedef struct {
+  UINT16VendorId;   ///< Ignore if the 
value is 0x.
+  UINT16DeviceId;   ///< Ignore if the 
value is 0x.
+  UINT16SubsystemVendorId;  ///< Ignore if the 
value is 0x.
+  UINT16SubsystemId;///< Ignore if the 
value is 0x.
+  UINT8 RevisionId; ///< Ignore if the 
value is 0xFF.
+  UINT8 BarIndex;   ///< Ignore if the 
value is 0xFF.
+} EFI_PEI_GRAPHICS_DEVICE_INFO_HOB;
+
 extern EFI_GUID gEfiGraphicsInfoHobGuid;
+extern EFI_GUID gEfiGraphicsDeviceInfoHobGuid;
 
 #endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 458d568..46573a1 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -727,6 +727,7 @@ [Guids]
   #
   ## Include/Guid/GraphicsInfoHob.h
   gEfiGraphicsInfoHobGuid   = { 0x39f62cce, 0x6825, 0x4669, { 0xbb, 
0x56, 0x54, 0x1a, 0xba, 0x75, 0x3a, 0x07 }}
+  gEfiGraphicsDeviceInfoHobGuid = { 0xe5cb2ac9, 0xd35d, 0x4430, { 0x93, 
0x6e, 0x1d, 0xe3, 0x32, 0x47, 0x8d, 0xe7 }}
 
   ## Guid for EFI_DISK_INFO_PROTOCOL.Interface to specify UFS interface.
   ## Include/Protocol/DiskInfo.h
-- 
2.8.3.windows.1

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

Re: [edk2] [Patch 0/2] Update-PXE-driver-to-follow-edk2-coding-standards

[Samer El Haj Mahmoud]

Series Reviewed-by: Samer El-Haj-Mahmoud 



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu Siyuan
Sent: Wednesday, June 29, 2016 10:08 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 0/2] Update-PXE-driver-to-follow-edk2-coding-standards


Fu Siyuan (2):
  MdeModulePkg: Update PXE driver to follow edk2 coding standards.
  NetworkPkg: Update PXE driver to follow edk2 coding standards.

 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c | 4 ++--  
MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h | 4 ++--
 NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c | 6 +++---
 NetworkPkg/UefiPxeBcDxe/PxeBcSupport.h | 4 ++--
 4 files changed, 9 insertions(+), 9 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

Re: [edk2] [Patch] IntelFrameworkModulePkg StatusCode RuntimeDxe: Remove duplicated structure.

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Fan, Jeff
> Sent: Wednesday, June 29, 2016 8:21 PM
> To: Gao, Liming ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch] IntelFrameworkModulePkg StatusCode
> RuntimeDxe: Remove duplicated structure.
> 
> Reviewed-by: Jeff Fan 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Liming Gao
> Sent: Thursday, June 30, 2016 10:38 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch] IntelFrameworkModulePkg StatusCode RuntimeDxe:
> Remove duplicated structure.
> 
> RUNTIME_MEMORY_STATUSCODE_HEADER has been moved into
> MdeModulePkg public header file
> Include/Guid/MemoryStatusCodeRecord.h. It should be removed from the
> driver.
> 
> Cc: Cinnamon Shia 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  .../Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h   | 9 -
> 
>  1 file changed, 9 deletions(-)
> 
> diff --git
> a/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCod
> eRuntimeDxe.h
> b/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCo
> deRuntimeDxe.h
> index 9d0ed19..ae20f5b 100644
> ---
> a/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCod
> eRuntimeDxe.h
> +++
> b/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCo
> de
> +++ RuntimeDxe.h
> @@ -53,15 +53,6 @@ typedef struct {
>  } DATAHUB_STATUSCODE_RECORD;
> 
> 
> -//
> -// Runtime memory status code worker definition -// -typedef struct {
> -  UINT32   RecordIndex;
> -  UINT32   NumberOfRecords;
> -  UINT32   MaxRecordsNumber;
> -} RUNTIME_MEMORY_STATUSCODE_HEADER;
> -
>  extern RUNTIME_MEMORY_STATUSCODE_HEADER
> *mRtMemoryStatusCodeTable;
> 
>  /**
> --
> 2.8.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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/6] EdkCompatibilityPkg: fix ASSERT_EFI_ERROR() typos

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Gao, Liming
> Sent: Tuesday, June 28, 2016 11:37 PM
> To: Laszlo Ersek ; edk2-devel-01  de...@ml01.01.org>
> Subject: Re: [edk2] [PATCH 1/6] EdkCompatibilityPkg: fix
> ASSERT_EFI_ERROR() typos
> 
> Reviewed-by: Liming Gao 
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, June 28, 2016 9:26 PM
> To: edk2-devel-01 
> Cc: Gao, Liming 
> Subject: [PATCH 1/6] EdkCompatibilityPkg: fix ASSERT_EFI_ERROR() typos
> 
> A number of code locations use
> 
>   ASSERT_EFI_ERROR (BooleanExpression)
> 
> instead of
> 
>   ASSERT (BooleanExpression)
> 
> Fix them.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> build tested only
> 
> 
> EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatabas
> e.c | 2 +-
>  EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
> | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git
> a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatab
> ase.c
> b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatab
> ase.c
> index 386ff327f81b..2d456da30353 100644
> ---
> a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatab
> ase.c
> +++
> b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/HiiDatab
> ase.c
> @@ -494,7 +494,7 @@ HiiGetSecondaryLanguages (
>UnicodeStrToAsciiStr (PrimaryLanguage, PrimaryLang639);
> 
>PrimaryLang4646 = ConvertLanguagesIso639ToRfc4646 (PrimaryLang639);
> -  ASSERT_EFI_ERROR (PrimaryLang4646 != NULL);
> +  ASSERT (PrimaryLang4646 != NULL);
> 
>SecLangCodes4646 = HiiGetSupportedSecondaryLanguages (UefiHiiHandle,
> PrimaryLang4646);
> 
> diff --git
> a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
> b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
> index f6d97f63444f..d269b8e4d6ba 100644
> ---
> a/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
> +++
> b/EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c
> @@ -153,7 +153,7 @@ ExportPackageLists (
> &Size,
> PackageListHdr
> );
> -  ASSERT_EFI_ERROR (Status != EFI_BUFFER_TOO_SMALL);
> +  ASSERT (Status != EFI_BUFFER_TOO_SMALL);
> 
>if (Status == EFI_BUFFER_TOO_SMALL) {
>  PackageListHdr = AllocateZeroPool (Size);
> --
> 1.8.3.1
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiewen Yao
> Sent: Tuesday, June 28, 2016 7:30 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Fan, Jeff
> 
> Subject: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB
> with MAX_ADDRESS check.
> 
> PI specification Vol 4 - SMM does not have any limitation of BASE_4GB for
> SMM.
> So we should replace BASE_4GB check with MAX_ADDRESS check to make
> sure
> the SMM memory is accessible by SMM Core.
> 
> Cc: Jeff Fan 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 2 +-
>  MdeModulePkg/Core/PiSmmCore/Pool.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> index acfcc83..3788bd5 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> @@ -1556,7 +1556,7 @@ SmmIplEntry (
>  }
> 
>  if (gSmmCorePrivate->SmramRanges[Index].CpuStart >= BASE_1MB) {
> -  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart +
> gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= BASE_4GB) {
> +  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart +
> gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= MAX_ADDRESS) {
>  if (gSmmCorePrivate->SmramRanges[Index].PhysicalSize >= MaxSize) {
>MaxSize = gSmmCorePrivate->SmramRanges[Index].PhysicalSize;
>mCurrentSmramRange = &gSmmCorePrivate->SmramRanges[Index];
> diff --git a/MdeModulePkg/Core/PiSmmCore/Pool.c
> b/MdeModulePkg/Core/PiSmmCore/Pool.c
> index 761988e..e493fd2 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Pool.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Pool.c
> @@ -67,7 +67,7 @@ SmmInitializeMemoryServices (
>}
> 
>if (SmramRanges[Index].CpuStart >= BASE_1MB) {
> -if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize)
> <= BASE_4GB) {
> +if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize)
> <= MAX_ADDRESS) {
>if (SmramRanges[Index].PhysicalSize >= MaxSize) {
>  MaxSize = SmramRanges[Index].PhysicalSize;
>  CurrentSmramRangesIndex = Index;
> --
> 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

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Andrew Fish]

> On Jun 29, 2016, at 8:14 PM, Gao, Liming  wrote:
> 
> Andrew:
>   Thanks for your detail information.
> 1)  We did the test to disable header file dependency, and find there is 
> no obvious performance improvement.

It seemed like doing build on a target that had just built the slowest 
operation in the profile was regex that was called a large number of times. 
There could be bugs like tools_def.txt file being parsed 47 time, and maybe 
that explains the long time period doing the prebuild phase (printing the ...). 
Maybe someone could profile all the classes that parse text files and make sure 
they are not reparsing the files?

> 2)  Build tool has genc and genmake target. Have you tried them?

No as there is no top level make file that I can call with make -j8, since the 
Python does the thread dispatch of the lower level makefiles. It would great if 
this step also generated a top level makefile that was enabled for parallelism. 
That way would could test if doing the parallel build in make is faster than 
Python. 

> 3)  We are evaluating to enable multiple thread in GenFd phase. For 
> example, each FV generation will take one thread. Then, FV image generation 
> can be Parallel.

It still might go a lot faster if it did not have to do all the file IO, and 
FVs tend to depend on FVs (compression and/or dispatch delay) so I don't know 
how much speed up you will get? 

> 4)   We have not fully tuning build performance. We will do it.

Thank you!

> 5)   You mean prebuild/postbuild script? They are actually single thread.
>  

Yes lots of the platforms just have BAT or BASH scripts that do work, if that 
work was in a makefile things could be made parallel via make syntax. 

>   Last, EDK and EDK2 has the different build system and code base. They both 
> impact build performance. I am not sure whether edk2 build system causes the 
> big gap between EDK and EDK2 build performance. 
>  

There were still DSC, FDF, and INF files in EDK. Adding PCD and AutoGen did not 
create almost 2 times the work. Also on the EDK ProcessDSC was a monolithic C 
program so it was efficient and did not generation a lot of intermediate files 
and did not have a lot of process overhead execing C tools out of Python, it 
just parsed data, placed it in memory, and acted on it. 

Thanks,

Andrew Fish

> Thanks
> Liming
> From: af...@apple.com  [mailto:af...@apple.com 
> ] 
> Sent: Thursday, June 30, 2016 7:06 AM
> To: Kinney, Michael D  >
> Cc: Justen, Jordan L  >; Shi, Steven  >; edk2-devel@lists.01.org 
> ; Gao, Liming  >
> Subject: Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type 
> for LTO build
>  
> 
> > On Jun 29, 2016, at 3:06 PM, Kinney, Michael D wrote:
> > 
> > Why can't we simply use the target.txt TOOL_CHAIN_CONF define
> > in target.txt as it works today? You could split tools_def.txt
> > into several versions, with the default one being the maintained
> > one and developers can opt into community or deprecated ones.
> > 
> > I do want to make sure we are focused on the right problem here
> > 
> > 1) # lines in tools_def.txt
> > 2) maintenance of tools_def.txt
> > 3) build performance
> 
> Mike,
> 
> If parsing the file 47 times was enough to make a function stand out in the 
> Python performance log I would guess the parsing it 1 time is not that 
> efficient. 
> 
> In general the built tools seems architected to "go slow", well to make it 
> easier to debug the build system and performance was not important. 
> 1) I saw regex was getting called 1,000,000 times in a Python performance 
> log. I think most of it is scanning all the C code to build the dependencies 
> for the makefile
> a) Likely make + compiler is better performance optimized for this, and is 
> continuously getting improved. 
> b) A build option to do this the normal way would be nice. 
> c) I'm guessing a lot of the early ... time in the build is this step. 
> 2) Parallel builds are done from Python threads vs make -j 
> a) See #1
> b) It would be nice to have a build phase that just generated the makefiles 
> including a top level makefile was constructed to enable parallel build. Then 
> the top level makefile could call the generated makefile. After that build 
> can be called to construct the FDs. 
> c) When we build DEBUG and RELEASE in parallel, or multiple platforms it 
> seems like the Python is fighting the make -j. If it was all make -j then 
> make could load balance. 
> 3) The FV construction seems slow and it generates multiple text files per 
> section per file and there is lots of calling out between Python and C tools. 
> a) Maybe combining all the FD construction into a single C program would 
> allow all the data to be in memory vs. on disk. 
> 4) It does not seem that the Python co

Re: [edk2] [Patch] IntelFrameworkModulePkg StatusCode RuntimeDxe: Remove duplicated structure.

[Fan, Jeff]

Reviewed-by: Jeff Fan 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Thursday, June 30, 2016 10:38 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] IntelFrameworkModulePkg StatusCode RuntimeDxe: Remove 
duplicated structure.

RUNTIME_MEMORY_STATUSCODE_HEADER has been moved into MdeModulePkg public header 
file Include/Guid/MemoryStatusCodeRecord.h. It should be removed from the 
driver.

Cc: Cinnamon Shia 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 .../Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h   | 9 -
 1 file changed, 9 deletions(-)

diff --git 
a/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h
 
b/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h
index 9d0ed19..ae20f5b 100644
--- 
a/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h
+++ b/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCode
+++ RuntimeDxe.h
@@ -53,15 +53,6 @@ typedef struct {
 } DATAHUB_STATUSCODE_RECORD;
 
 
-//
-// Runtime memory status code worker definition -// -typedef struct {
-  UINT32   RecordIndex;
-  UINT32   NumberOfRecords;
-  UINT32   MaxRecordsNumber;
-} RUNTIME_MEMORY_STATUSCODE_HEADER;
-
 extern RUNTIME_MEMORY_STATUSCODE_HEADER  *mRtMemoryStatusCodeTable;
 
 /**
--
2.8.0.windows.1

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

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Gao, Liming]

Andrew:
  Thanks for your detail information.

1)  We did the test to disable header file dependency, and find there is no 
obvious performance improvement.

2)  Build tool has genc and genmake target. Have you tried them?

3)  We are evaluating to enable multiple thread in GenFd phase. For 
example, each FV generation will take one thread. Then, FV image generation can 
be Parallel.

4)   We have not fully tuning build performance. We will do it.

5)   You mean prebuild/postbuild script? They are actually single thread.

  Last, EDK and EDK2 has the different build system and code base. They both 
impact build performance. I am not sure whether edk2 build system causes the 
big gap between EDK and EDK2 build performance.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Thursday, June 30, 2016 7:06 AM
To: Kinney, Michael D 
Cc: Justen, Jordan L ; Shi, Steven 
; edk2-devel@lists.01.org; Gao, Liming 

Subject: Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for 
LTO build


> On Jun 29, 2016, at 3:06 PM, Kinney, Michael D wrote:
>
> Why can't we simply use the target.txt TOOL_CHAIN_CONF define
> in target.txt as it works today? You could split tools_def.txt
> into several versions, with the default one being the maintained
> one and developers can opt into community or deprecated ones.
>
> I do want to make sure we are focused on the right problem here
>
> 1) # lines in tools_def.txt
> 2) maintenance of tools_def.txt
> 3) build performance

Mike,

If parsing the file 47 times was enough to make a function stand out in the 
Python performance log I would guess the parsing it 1 time is not that 
efficient.

In general the built tools seems architected to "go slow", well to make it 
easier to debug the build system and performance was not important.
1) I saw regex was getting called 1,000,000 times in a Python performance log. 
I think most of it is scanning all the C code to build the dependencies for the 
makefile
a) Likely make + compiler is better performance optimized for this, and is 
continuously getting improved.
b) A build option to do this the normal way would be nice.
c) I'm guessing a lot of the early ... time in the build is this step.
2) Parallel builds are done from Python threads vs make -j
a) See #1
b) It would be nice to have a build phase that just generated the makefiles 
including a top level makefile was constructed to enable parallel build. Then 
the top level makefile could call the generated makefile. After that build can 
be called to construct the FDs.
c) When we build DEBUG and RELEASE in parallel, or multiple platforms it seems 
like the Python is fighting the make -j. If it was all make -j then make could 
load balance.
3) The FV construction seems slow and it generates multiple text files per 
section per file and there is lots of calling out between Python and C tools.
a) Maybe combining all the FD construction into a single C program would allow 
all the data to be in memory vs. on disk.
4) It does not seem that the Python code has really been performance tuned. A 
large file was getting parsed 47 time, regex getting called a 1,000,000 times 
etc.
5) Most of the build targets use scripts.
a) A top level makefile, and moving some of the work to makefiles could help 
with parallelism.
b) I've got this working on our proprietary tree.
1) Had to make Conf/ part of the Buid/ output. I made a small mod to the tool 
to copy the Conf over if the alternate Conf location passed to build did not 
exit.
2) I had to add .NOTPARALLEL: to some of the BaseTools GNUmakefiles since they 
break for a parallel build.
3) Then you port the build.sh (or build.bat) to be a makefile.

Our old parallelized EDK builds took about 2m10s to do a DEBUG build for a 
target, and with the edk2 it is 3m52s.

Thanks,

Andrew Fish

PS As we know from performance tuning the ROM the most important thing to do is 
profile, and not listen to the old grumpy guy :).
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Vlv2TbltDevicePkg: Change value for Winboard W25QXX and change register value in DetermineTurbotBoard ()

[Wei, David]

Hi,

I have two comments for this patch:

(1)  Could you describe what's the purpose of below change? If it's for another 
bug fix, we need to submit it in a separate patch.  
-  MmioWrite32 (MmioConf0, 0x2003CC00);
+  MmioWrite32 (MmioConf0, 0x2003CD00);

(2) For SF_DEVICE_ID0_W25QXX, we do have a flash with ID 0x40. So we need to 
keep 0x40. The proper way is to add another definition and more code for 0x60.  



Thanks,
David  Wei   
  
Intel SSG BIOS Team


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Anteja 
Vuk Macek
Sent: Thursday, June 23, 2016 1:50 PM
To: edk2-devel(email list) 
Subject: [edk2] [PATCH] Vlv2TbltDevicePkg: Change value for Winboard W25QXX and 
change register value in DetermineTurbotBoard ()

Hi,

Working with MinnowBoard Max, I run on errors.  There is patch with correct
values.



Index: Vlv2TbltDevicePkg/Include/Library/SpiFlash.H
===
--- Vlv2TbltDevicePkg/Include/Library/SpiFlash.H (revision 1319)
+++ Vlv2TbltDevicePkg/Include/Library/SpiFlash.H (working copy)
@@ -75,7 +75,7 @@
 #define SF_DEVICE_ID0_W25XXX0x30
 #define SF_DEVICE_ID1_W25X320x16
 #define SF_DEVICE_ID1_W25X640x17
-#define SF_DEVICE_ID0_W25QXX0x40
+#define SF_DEVICE_ID0_W25QXX0x60//0x40
 #define SF_DEVICE_ID1_W25Q160x15
 #define SF_DEVICE_ID1_W25Q320x16
 #define SF_DEVICE_ID1_W25Q640x17
Index: Vlv2TbltDevicePkg/Library/PchPlatformLib/PchPlatformLibrary.c
===
--- Vlv2TbltDevicePkg/Library/PchPlatformLib/PchPlatformLibrary.c (revision
1319)
+++ Vlv2TbltDevicePkg/Library/PchPlatformLib/PchPlatformLibrary.c (working
copy)
@@ -168,7 +168,7 @@
   UINT32 SSUSOffset = 0x2000;
   UINT32 IoBase = 0;

-  DEBUG ((EFI_D_ERROR, "DetermineTurbotBoard() Entry\n"));
+  DEBUG ((EFI_D_ERROR, "DetectTurbotBoard() Entry\n"));
   PciD31F0RegBase = MmPciAddress (0,
   0,
   PCI_DEVICE_NUMBER_PCH_LPC,
@@ -182,7 +182,7 @@
   //0xFED0E200/0xFED0E208 is pad_Conf/pad_val register address of GPIO_S5_4
   DEBUG ((EFI_D_ERROR, "MmioConf0[0x%x], MmioPadval[0x%x]\n", MmioConf0,
MmioPadval));

-  MmioWrite32 (MmioConf0, 0x2003CC00);
+  MmioWrite32 (MmioConf0, 0x2003CD00);

   TmpVal = MmioRead32 (MmioPadval);
   TmpVal &= ~0x6; //Clear bit 1:2
Index: Vlv2TbltDevicePkg/PlatformPei/Platform.c
===
--- Vlv2TbltDevicePkg/PlatformPei/Platform.c (revision 1319)
+++ Vlv2TbltDevicePkg/PlatformPei/Platform.c (working copy)
@@ -238,7 +238,7 @@
   //0xFED0E200/0xFED0E208 is pad_Conf/pad_val register address of GPIO_S5_4
   DEBUG ((EFI_D_ERROR, "MmioConf0[0x%x], MmioPadval[0x%x]\n", MmioConf0,
MmioPadval));

-  MmioWrite32 (MmioConf0, 0x2003CC00);
+  MmioWrite32 (MmioConf0, 0x2003CD00);

   TmpVal = MmioRead32 (MmioPadval);
   TmpVal &= ~0x6; //Clear bit 1:2


Best regards,

AntejaVM
___
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] Vlv2TbltDevicePkg:Add PiSmmCommunication&PiSmmCpuDxeSmm of UefiCpuPkg.

[Wei, David]

Reviewed-by: David Wei  

Thanks,
David  Wei   
  
Intel SSG BIOS Team


-Original Message-
From: Lu, ShifeiX A 
Sent: Tuesday, June 21, 2016 3:42 PM
To: edk2-devel@lists.01.org
Cc: Wei; Wei, David 
Subject: [Patch] Vlv2TbltDevicePkg:Add PiSmmCommunication&PiSmmCpuDxeSmm of 
UefiCpuPkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 Vlv2TbltDevicePkg/PlatformPkg.fdf   | 5 ++---
 Vlv2TbltDevicePkg/PlatformPkgGcc.fdf| 5 ++---
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 6 --
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 6 --
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 6 --
 5 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformPkg.fdf 
b/Vlv2TbltDevicePkg/PlatformPkg.fdf
index a499006..93b4d2d 100644
--- a/Vlv2TbltDevicePkg/PlatformPkg.fdf
+++ b/Vlv2TbltDevicePkg/PlatformPkg.fdf
@@ -540,18 +540,17 @@ INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET
   #
   # SMM
   #
 INF MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
-INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/PiSmmCpuDxeSmm.inf
+INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
 
 INF UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 INF MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
-INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/PiSmmCommunicationSmm.inf
+INF UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf
 INF 
$(PLATFORM_PACKAGE)/SmmSwDispatch2OnSmmSwDispatchThunk/SmmSwDispatch2OnSmmSwDispatchThunk.inf
 INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/PowerManagement2.inf
-# INF Vlv2DeviceRefCodePkg/ValleyView2Soc/CPU/Dts/Smm/DigitalThermalSensor.inf
 INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/DigitalThermalSensor.inf
   #
   # ACPI
   #
 INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf 
b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
index 72a0d2b..e9292ca 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
+++ b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
@@ -497,18 +497,17 @@ INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET
   #
   # SMM
   #
 INF MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
-INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/PiSmmCpuDxeSmm.inf
+INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
 
 INF UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 INF MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
-INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/PiSmmCommunicationSmm.inf
+INF UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf
 INF 
$(PLATFORM_PACKAGE)/SmmSwDispatch2OnSmmSwDispatchThunk/SmmSwDispatch2OnSmmSwDispatchThunk.inf
 INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/PowerManagement2.inf
-# INF Vlv2DeviceRefCodePkg/ValleyView2Soc/CPU/Dts/Smm/DigitalThermalSensor.inf
 INF RuleOverride = BINARY 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/DigitalThermalSensor.inf
   #
   # ACPI
   #
 INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index 466de88..9865785 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -398,10 +398,12 @@
   
ReportStatusCodeLib|MdeModulePkg/Library/SmmReportStatusCodeLib/SmmReportStatusCodeLib.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
   
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
+  
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
+  SmmCpuFeaturesLib|UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
 
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
   !if $(TARGET) != RELEASE
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   !endif
@@ -1328,14 +1330,14 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
 

DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf

SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
  !endif
   }
-  
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/$(DXE_ARCHITECTURE)/PiSmmCpuDxeSmm.inf
+  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
   UefiCpuPkg/CpuIo2Smm/C

Re: [edk2] [Patch 1/2] MdeModulePkg: Update PXE driver to follow edk2 coding standards.

[Zhang, Lubo]

Series Reviewed-by: Zhang Lubo 

-Original Message-
From: Fu, Siyuan 
Sent: Thursday, June 30, 2016 10:08 AM
To: edk2-devel@lists.01.org
Cc: Wu, Jiaxin ; Zhang, Lubo 
Subject: [Patch 1/2] MdeModulePkg: Update PXE driver to follow edk2 coding 
standards.

Cc: Wu Jiaxin 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c | 4 ++--  
MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c 
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c
index 79c9a67..a20fdb7 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c
@@ -42,7 +42,7 @@ PxeBcCommonNotify (
   @param  SubnetMask Pointer to the subnetmask of the station ip address.
   @param  GatewayPointer to the gateway ip address.
   @param  SrcPortPointer to the srouce port of the station.
-  @param  TTLThe time to live field of the IP header. 
+  @param  TtlThe time to live field of the IP header. 
   @param  ToSThe type of service field of the IP header.
 
   @retval EFI_SUCCESS   The configuration settings were set, changed, 
or reset successfully.
@@ -68,7 +68,7 @@ PxeBcConfigureUdpWriteInstance (
   IN EFI_IPv4_ADDRESS   *SubnetMask,
   IN EFI_IPv4_ADDRESS   *Gateway,
   IN OUT UINT16 *SrcPort,
-  IN UINT8  TTL,
+  IN UINT8  Ttl,
   IN UINT8  ToS
   )
 {
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h 
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h
index 1082b3a..16ac05e 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h
@@ -38,7 +38,7 @@ PxeBcCommonNotify (
   @param  SubnetMask Pointer to the subnetmask of the station ip address.
   @param  GatewayPointer to the gateway ip address.
   @param  SrcPortPointer to the srouce port of the station.
-  @param  TTLThe time to live field of the IP header. 
+  @param  TtlThe time to live field of the IP header. 
   @param  ToSThe type of service field of the IP header.
 
   @retval EFI_SUCCESS   The configuration settings were set, changed, 
or reset successfully.
@@ -64,7 +64,7 @@ PxeBcConfigureUdpWriteInstance (
   IN EFI_IPv4_ADDRESS   *SubnetMask,
   IN EFI_IPv4_ADDRESS   *Gateway,
   IN OUT UINT16 *SrcPort,
-  IN UINT8  TTL,
+  IN UINT8  Ttl,
   IN UINT8  ToS
   );
 /**
--
2.7.4.windows.1

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

Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.

[Gao, Liming]

Laszlo:
  I have sent the patch to fix it. Besides, I suggest to update Ovmf DSC/FDF to 
use StatusCode Router and Handler from MdeModulePkg instead of 
IntelFrameworkModulePkg. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Gao, Liming
> Sent: Thursday, June 30, 2016 9:02 AM
> To: Laszlo Ersek ; Bruce Cran ;
> Cinnamon Shia ; edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Zeng, Star 
> Subject: Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose
> the DXE memory status code table.
> 
> Yes. I will make one patch to fix it. Thanks for your report.
> 
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, June 30, 2016 1:40 AM
> To: Bruce Cran ; Cinnamon Shia
> ; edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Gao, Liming ;
> Zeng, Star 
> Subject: Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose
> the DXE memory status code table.
> 
> On 06/29/16 16:47, Bruce Cran wrote:
> > On 6/27/2016 1:25 AM, Cinnamon Shia wrote:
> >> Let data of DXE memory status code can be used by other modules.
> >> 1. Save the address of DXE memory status code table to
> >> DxeConfigurationTable.
> >> 2. Save the address of SMM memory status code table to
> >> SmmConfigurationTable.
> >> 3. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public header
> file.
> >
> > I'm getting an error building OVMF today, which appears related:
> >
> > In file included from
> >
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
> sCode/RuntimeDxe/SerialStatusCodeWorker.c:15:0:
> >
> >
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
> sCode/RuntimeDxe/StatusCodeRuntimeDxe.h:63:3:
> > error: conflicting types for 'RUNTIME_MEMORY_STATUSCODE_HEADER'
> > } RUNTIME_MEMORY_STATUSCODE_HEADER;
> > ^~~~
> > In file included from
> >
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
> sCode/RuntimeDxe/StatusCodeRuntimeDxe.h:22:0,
> >
> > from
> >
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
> sCode/RuntimeDxe/SerialStatusCodeWorker.c:15:
> >
> >
> /home/bcran/workspace/edk2/MdeModulePkg/Include/Guid/MemoryStat
> usCodeRecord.h:76:3:
> > note: previous declaration of 'RUNTIME_MEMORY_STATUSCODE_HEADER'
> was here
> > } RUNTIME_MEMORY_STATUSCODE_HEADER;
> > ^~~~
> >
> 
> Yes, the file
> 
> IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCode
> RuntimeDxe.h
> 
> includes
> 
> MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h
> 
> but also defines the RUNTIME_MEMORY_STATUSCODE_HEADER type, which
> has
> now become redundant.
> 
> As far as I can see, it should be fixable by removing the
> RUNTIME_MEMORY_STATUSCODE_HEADER typedef from
> "IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCod
> eRuntimeDxe.h".
> 
> Thanks
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] IntelFrameworkModulePkg StatusCode RuntimeDxe: Remove duplicated structure.

[Liming Gao]

RUNTIME_MEMORY_STATUSCODE_HEADER has been moved into MdeModulePkg public header
file Include/Guid/MemoryStatusCodeRecord.h. It should be removed from the 
driver.

Cc: Cinnamon Shia 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 .../Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h   | 9 -
 1 file changed, 9 deletions(-)

diff --git 
a/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h
 
b/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h
index 9d0ed19..ae20f5b 100644
--- 
a/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h
+++ 
b/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h
@@ -53,15 +53,6 @@ typedef struct {
 } DATAHUB_STATUSCODE_RECORD;
 
 
-//
-// Runtime memory status code worker definition
-//
-typedef struct {
-  UINT32   RecordIndex;
-  UINT32   NumberOfRecords;
-  UINT32   MaxRecordsNumber;
-} RUNTIME_MEMORY_STATUSCODE_HEADER;
-
 extern RUNTIME_MEMORY_STATUSCODE_HEADER  *mRtMemoryStatusCodeTable;
 
 /**
-- 
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] Vlv2TbltDevicePkg: Enable PCIE port 2 by default to support dual Ethernet.

[Wei, David]

Reviewed-by: David Wei 


Thanks,
David  Wei   
  
Intel SSG BIOS Team


-Original Message-
From: Guo, Mang 
Sent: Wednesday, June 29, 2016 1:13 PM
To: edk2-devel@lists.01.org
Cc: Wei, David 
Subject: [PATCH] Vlv2TbltDevicePkg: Enable PCIE port 2 by default to support 
dual Ethernet.

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi 
b/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi
index 258bd6f..f83d083 100644
--- a/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi
+++ b/Vlv2TbltDevicePkg/PlatformSetupDxe/SouthClusterConfig.vfi
@@ -130,8 +130,8 @@ form formid = PCIE_DEVICE_OPTIONS_FORM_ID,
 oneof varid= Setup.IchPciExp[1],
   prompt   = STRING_TOKEN(STR_ICH_PCIERP2_PROMPT),
   help = STRING_TOKEN(STR_ICH_PCIERP_HELP),
-  option text = STRING_TOKEN(STR_ENABLE), value=1, flags= RESET_REQUIRED;
-  option text = STRING_TOKEN(STR_DISABLE), value=0, flags= DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+  option text = STRING_TOKEN(STR_ENABLE), value=1, flags= DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+  option text = STRING_TOKEN(STR_DISABLE), value=0, flags= 0 | 
RESET_REQUIRED;
 endoneof;
   endif;
 
-- 
2.8.1.windows.1

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

Re: [edk2] [PATCH 0/9] Add FrameBufferBltLib and generic GOP driver to MdeModulePkg.

[Ni, Ruiyu]

Jordan,
I misunderstood your option.
I am fine to add a new library class FrameBufferBltLib and leave BltLib as is.

Thanks,
Ray

-Original Message-
From: Justen, Jordan L 
Sent: Thursday, June 30, 2016 4:42 AM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/9] Add FrameBufferBltLib and generic GOP driver to 
MdeModulePkg.

On 2016-06-29 06:24:31, Ruiyu Ni wrote:
> The patch serials refine the FrameBufferBltLib in OptionRomPkg and 
> move it to MdeModulePkg. Based on the library, a generic GOP driver 
> GraphicsOutputDxe is developed and added to MdeModulePkg.
> 
> Ruiyu Ni (9):
>   OptionRomPkg: Refine FrameBufferBltLib to use UINT8* instead of VOID*
>   OptionRomPkg: Add video move test case to BltLibSample application
>   OptionRomPkg/BltLib: Fix a bug in BltVideoToVideo operation
>   OptionRomPkg: Remove GopBltLib instance
>   OptionRomPkg: Refine BltLib to FrameBufferBltLib
>   MdeModulePkg: Move OptionRomPkg/FrameBufferBltLib to MdeModulePkg

When we last discussed this, the plan was to add the FrameBufferBltLib 
interface, but leave BltLib as it is for now.

I recommend adding the library interface and implementations in separate 
commits.

Can you make that change, and make a branch available with the changes?

-Jordan

>   OvmfPkg: QemuVideoDxe uses MdeModulePkg/FrameBufferLib
>   MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo HOB GUID and structure
>   MdeModulePkg: Add GraphicsOutputDxe driver.
> 
>  MdeModulePkg/Include/Library/FrameBufferBltLib.h   |  90 +++
>  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 709 +++
>  .../FrameBufferBltLib/FrameBufferBltLib.inf|   5 +-
>  MdeModulePkg/MdeModulePkg.dec  |   4 +
>  MdeModulePkg/MdeModulePkg.dsc  |   3 +
>  .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
>  .../Console/GraphicsOutputDxe/GraphicsOutput.c | 732 
>  .../Console/GraphicsOutputDxe/GraphicsOutput.h |  59 ++
>  .../GraphicsOutputDxe/GraphicsOutputDxe.inf|  55 +-
>  MdePkg/Include/Guid/GraphicsInfoHob.h  |  17 +-
>  MdePkg/MdePkg.dec  |   1 +
>  .../Application/BltLibSample/BltLibSample.c| 145 ++--
>  .../Application/BltLibSample/BltLibSample.inf  |   5 +-
>  OptionRomPkg/Include/Library/BltLib.h  | 259 ---
>  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 750 
> -
>  OptionRomPkg/Library/GopBltLib/GopBltLib.c | 455 -
>  OptionRomPkg/Library/GopBltLib/GopBltLib.inf   |  37 -
>  OptionRomPkg/OptionRomPkg.dec  |  11 +-
>  OptionRomPkg/OptionRomPkg.dsc  |   7 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc |   6 +-
>  OvmfPkg/QemuVideoDxe/Gop.c |  38 +-
>  OvmfPkg/QemuVideoDxe/Qemu.h|   4 +-
>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |   5 +-
>  23 files changed, 1969 insertions(+), 1618 deletions(-)  create mode 
> 100644 MdeModulePkg/Include/Library/FrameBufferBltLib.h
>  create mode 100644 
> MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
>  rename {OptionRomPkg => 
> MdeModulePkg}/Library/FrameBufferBltLib/FrameBufferBltLib.inf (87%)  
> create mode 100644 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
>  create mode 100644 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
>  create mode 100644 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
>  copy OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf => 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf 
> (53%)  delete mode 100644 OptionRomPkg/Include/Library/BltLib.h
>  delete mode 100644 
> OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
>  delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.c
>  delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.inf
> 
> --
> 2.8.3.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] [Patch 1/2] MdeModulePkg: Update PXE driver to follow edk2 coding standards.

[Fu Siyuan]

Cc: Wu Jiaxin 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c | 4 ++--
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c 
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c
index 79c9a67..a20fdb7 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c
@@ -42,7 +42,7 @@ PxeBcCommonNotify (
   @param  SubnetMask Pointer to the subnetmask of the station ip address.
   @param  GatewayPointer to the gateway ip address.
   @param  SrcPortPointer to the srouce port of the station.
-  @param  TTLThe time to live field of the IP header. 
+  @param  TtlThe time to live field of the IP header. 
   @param  ToSThe type of service field of the IP header.
 
   @retval EFI_SUCCESS   The configuration settings were set, changed, 
or reset successfully.
@@ -68,7 +68,7 @@ PxeBcConfigureUdpWriteInstance (
   IN EFI_IPv4_ADDRESS   *SubnetMask,
   IN EFI_IPv4_ADDRESS   *Gateway,
   IN OUT UINT16 *SrcPort,
-  IN UINT8  TTL,
+  IN UINT8  Ttl,
   IN UINT8  ToS
   )
 {
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h 
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h
index 1082b3a..16ac05e 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h
@@ -38,7 +38,7 @@ PxeBcCommonNotify (
   @param  SubnetMask Pointer to the subnetmask of the station ip address.
   @param  GatewayPointer to the gateway ip address.
   @param  SrcPortPointer to the srouce port of the station.
-  @param  TTLThe time to live field of the IP header. 
+  @param  TtlThe time to live field of the IP header. 
   @param  ToSThe type of service field of the IP header.
 
   @retval EFI_SUCCESS   The configuration settings were set, changed, 
or reset successfully.
@@ -64,7 +64,7 @@ PxeBcConfigureUdpWriteInstance (
   IN EFI_IPv4_ADDRESS   *SubnetMask,
   IN EFI_IPv4_ADDRESS   *Gateway,
   IN OUT UINT16 *SrcPort,
-  IN UINT8  TTL,
+  IN UINT8  Ttl,
   IN UINT8  ToS
   );
 /**
-- 
2.7.4.windows.1

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

[edk2] [Patch 0/2] Update-PXE-driver-to-follow-edk2-coding-standards

[Fu Siyuan]

Fu Siyuan (2):
  MdeModulePkg: Update PXE driver to follow edk2 coding standards.
  NetworkPkg: Update PXE driver to follow edk2 coding standards.

 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c | 4 ++--
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h | 4 ++--
 NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c | 6 +++---
 NetworkPkg/UefiPxeBcDxe/PxeBcSupport.h | 4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

-- 
2.7.4.windows.1

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

[edk2] [Patch 2/2] NetworkPkg: Update PXE driver to follow edk2 coding standards.

[Fu Siyuan]

Cc: Wu Jiaxin 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c | 6 +++---
 NetworkPkg/UefiPxeBcDxe/PxeBcSupport.h | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c 
b/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
index eb0f395..3ea9518 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
@@ -489,7 +489,7 @@ PxeBcIcmp6ErrorUpdate (
   @param[in, out]  SrcPort  The pointer to the source port.
   @param[in]   DoNotFragmentIf TRUE, fragment is not enabled.
 Otherwise, fragment is enabled.
-  @param[in]   TTL  The time to live field of the IP 
header. 
+  @param[in]   Ttl  The time to live field of the IP 
header. 
   @param[in]   ToS  The type of service field of the IP 
header.
 
   @retval  EFI_SUCCESS  Successfully configured this instance.
@@ -504,7 +504,7 @@ PxeBcConfigUdp4Write (
   IN EFI_IPv4_ADDRESS   *Gateway,
   IN OUT UINT16 *SrcPort,
   IN BOOLEANDoNotFragment,
-  IN UINT8  TTL,
+  IN UINT8  Ttl,
   IN UINT8  ToS
   )
 {
@@ -516,7 +516,7 @@ PxeBcConfigUdp4Write (
   Udp4CfgData.TransmitTimeout= PXEBC_DEFAULT_LIFETIME;
   Udp4CfgData.ReceiveTimeout = PXEBC_DEFAULT_LIFETIME;
   Udp4CfgData.TypeOfService  = ToS;
-  Udp4CfgData.TimeToLive = TTL;
+  Udp4CfgData.TimeToLive = Ttl;
   Udp4CfgData.AllowDuplicatePort = TRUE;
   Udp4CfgData.DoNotFragment  = DoNotFragment;
 
diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.h 
b/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.h
index 5d611b5..b8519ae 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.h
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.h
@@ -135,7 +135,7 @@ PxeBcIcmp6ErrorUpdate (
   @param[in, out]  SrcPort  The pointer to the source port.
   @param[in]   DoNotFragmentIf TRUE, fragment is not enabled.
 Otherwise, fragment is enabled.
-  @param[in]   TTL  The time to live field of the IP 
header. 
+  @param[in]   Ttl  The time to live field of the IP 
header. 
   @param[in]   ToS  The type of service field of the IP 
header.
 
   @retval  EFI_SUCCESS  Successfully configured this instance.
@@ -150,7 +150,7 @@ PxeBcConfigUdp4Write (
   IN EFI_IPv4_ADDRESS   *Gateway,
   IN OUT UINT16 *SrcPort,
   IN BOOLEANDoNotFragment,
-  IN UINT8  TTL,
+  IN UINT8  Ttl,
   IN UINT8  ToS
   );
 
-- 
2.7.4.windows.1

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

Re: [edk2] [PATCH v2] IntelFsp2WrapperPkg: Add error handling for possible NULL ptr dereference

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, June 30, 2016 9:57 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen 
> Subject: [PATCH v2] IntelFsp2WrapperPkg: Add error handling for possible
> NULL ptr dereference
> 
> Possible NULL pointer dereference for FspmHeaderPtr/FspsHeaderPtr in
> module FspmWrapperPeim/FspsWrapperPeim.
> 
> Add error handling codes to avoid this issue.
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c | 5 +
>  IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c | 5 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> index 6144ad7..c98513e 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> @@ -68,6 +68,11 @@ PeiFspMemoryInit (
>// Copy default FSP-M UPD data from Flash
>//
>FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32
> (PcdFspmBaseAddress));
> +  DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
> +  if (FspmHeaderPtr == NULL) {
> +return EFI_DEVICE_ERROR;
> +  }
> +
>FspmUpdDataPtr = (FSPM_UPD_COMMON *)AllocateZeroPool
> ((UINTN)FspmHeaderPtr->CfgRegionSize);
>ASSERT (FspmUpdDataPtr != NULL);
>SourceData = (UINTN *)((UINTN)FspmHeaderPtr->ImageBase +
> (UINTN)FspmHeaderPtr->CfgRegionOffset);
> diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> index 7a65ad7..c923690 100644
> --- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> @@ -241,6 +241,11 @@ PeiMemoryDiscoveredNotify (
>// Copy default FSP-S UPD data from Flash
>//
>FspsHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32
> (PcdFspsBaseAddress));
> +  DEBUG ((DEBUG_INFO, "FspsHeaderPtr - 0x%x\n", FspsHeaderPtr));
> +  if (FspsHeaderPtr == NULL) {
> +return EFI_DEVICE_ERROR;
> +  }
> +
>FspsUpdDataPtr = (FSPS_UPD_COMMON *)AllocateZeroPool
> ((UINTN)FspsHeaderPtr->CfgRegionSize);
>ASSERT (FspsUpdDataPtr != NULL);
>SourceData = (UINTN *)((UINTN)FspsHeaderPtr->ImageBase +
> (UINTN)FspsHeaderPtr->CfgRegionOffset);
> --
> 1.9.5.msysgit.0

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

[edk2] [PATCH v2] IntelFsp2WrapperPkg: Add error handling for possible NULL ptr dereference

[Hao Wu]

Possible NULL pointer dereference for FspmHeaderPtr/FspsHeaderPtr in
module FspmWrapperPeim/FspsWrapperPeim.

Add error handling codes to avoid this issue.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c | 5 +
 IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c | 5 +
 2 files changed, 10 insertions(+)

diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
index 6144ad7..c98513e 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
@@ -68,6 +68,11 @@ PeiFspMemoryInit (
   // Copy default FSP-M UPD data from Flash
   //
   FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32 
(PcdFspmBaseAddress));
+  DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
+  if (FspmHeaderPtr == NULL) {
+return EFI_DEVICE_ERROR;
+  }
+
   FspmUpdDataPtr = (FSPM_UPD_COMMON *)AllocateZeroPool 
((UINTN)FspmHeaderPtr->CfgRegionSize);
   ASSERT (FspmUpdDataPtr != NULL);
   SourceData = (UINTN *)((UINTN)FspmHeaderPtr->ImageBase + 
(UINTN)FspmHeaderPtr->CfgRegionOffset);
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
index 7a65ad7..c923690 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
@@ -241,6 +241,11 @@ PeiMemoryDiscoveredNotify (
   // Copy default FSP-S UPD data from Flash
   //
   FspsHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32 
(PcdFspsBaseAddress));
+  DEBUG ((DEBUG_INFO, "FspsHeaderPtr - 0x%x\n", FspsHeaderPtr));
+  if (FspsHeaderPtr == NULL) {
+return EFI_DEVICE_ERROR;
+  }
+
   FspsUpdDataPtr = (FSPS_UPD_COMMON *)AllocateZeroPool 
((UINTN)FspsHeaderPtr->CfgRegionSize);
   ASSERT (FspsUpdDataPtr != NULL);
   SourceData = (UINTN *)((UINTN)FspsHeaderPtr->ImageBase + 
(UINTN)FspsHeaderPtr->CfgRegionOffset);
-- 
1.9.5.msysgit.0

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

[edk2] [PATCH] IntelFsp2WrapperPkg: Add NULL pointer check by using ASSERT()

[Hao Wu]

Possible NULL pointer dereference for FspmHeaderPtr/FspsHeaderPtr in
module FspmWrapperPeim/FspsWrapperPeim.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c | 1 +
 IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
index 6144ad7..71157c3 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
@@ -68,6 +68,7 @@ PeiFspMemoryInit (
   // Copy default FSP-M UPD data from Flash
   //
   FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32 
(PcdFspmBaseAddress));
+  ASSERT (FspmHeaderPtr != NULL);
   FspmUpdDataPtr = (FSPM_UPD_COMMON *)AllocateZeroPool 
((UINTN)FspmHeaderPtr->CfgRegionSize);
   ASSERT (FspmUpdDataPtr != NULL);
   SourceData = (UINTN *)((UINTN)FspmHeaderPtr->ImageBase + 
(UINTN)FspmHeaderPtr->CfgRegionOffset);
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
index 7a65ad7..3415629 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
@@ -241,6 +241,7 @@ PeiMemoryDiscoveredNotify (
   // Copy default FSP-S UPD data from Flash
   //
   FspsHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32 
(PcdFspsBaseAddress));
+  ASSERT (FspsHeaderPtr != NULL);
   FspsUpdDataPtr = (FSPS_UPD_COMMON *)AllocateZeroPool 
((UINTN)FspsHeaderPtr->CfgRegionSize);
   ASSERT (FspsUpdDataPtr != NULL);
   SourceData = (UINTN *)((UINTN)FspsHeaderPtr->ImageBase + 
(UINTN)FspsHeaderPtr->CfgRegionOffset);
-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.

[Gao, Liming]

Yes. I will make one patch to fix it. Thanks for your report.

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Thursday, June 30, 2016 1:40 AM
To: Bruce Cran ; Cinnamon Shia ; 
edk2-de...@ml01.01.org
Cc: Tian, Feng ; Gao, Liming ; Zeng, 
Star 
Subject: Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE 
memory status code table.

On 06/29/16 16:47, Bruce Cran wrote:
> On 6/27/2016 1:25 AM, Cinnamon Shia wrote:
>> Let data of DXE memory status code can be used by other modules.
>> 1. Save the address of DXE memory status code table to
>> DxeConfigurationTable.
>> 2. Save the address of SMM memory status code table to
>> SmmConfigurationTable.
>> 3. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public header file.
>
> I'm getting an error building OVMF today, which appears related:
>
> In file included from
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/SerialStatusCodeWorker.c:15:0:
>
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h:63:3:
> error: conflicting types for 'RUNTIME_MEMORY_STATUSCODE_HEADER'
> } RUNTIME_MEMORY_STATUSCODE_HEADER;
> ^~~~
> In file included from
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h:22:0,
>
> from
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/SerialStatusCodeWorker.c:15:
>
> /home/bcran/workspace/edk2/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h:76:3:
> note: previous declaration of 'RUNTIME_MEMORY_STATUSCODE_HEADER' was here
> } RUNTIME_MEMORY_STATUSCODE_HEADER;
> ^~~~
>

Yes, the file

IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h

includes

MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h

but also defines the RUNTIME_MEMORY_STATUSCODE_HEADER type, which has
now become redundant.

As far as I can see, it should be fixable by removing the
RUNTIME_MEMORY_STATUSCODE_HEADER typedef from
"IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h".

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

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Andrew Fish]

> On Jun 29, 2016, at 3:06 PM, Kinney, Michael D  
> wrote:
> 
> Why can't we simply use the target.txt TOOL_CHAIN_CONF define
> in target.txt as it works today?  You could split tools_def.txt
> into several versions, with the default one being the maintained
> one and developers can opt into community or deprecated ones.
> 
> I do want to make sure we are focused on the right problem here
> 
> 1) # lines in tools_def.txt
> 2) maintenance of tools_def.txt
> 3) build performance

Mike,

If parsing the file 47 times was enough to make a function stand out in the 
Python performance log I would guess the parsing it 1 time is not that 
efficient. 

In general the built tools seems architected to "go slow", well to make it 
easier to debug the build system and performance was not important. 
1) I saw regex was getting called 1,000,000 times in a Python performance log. 
I think most of it is scanning all the C code to build the dependencies for the 
makefile
   a) Likely make + compiler is better performance optimized for this, and is 
continuously getting improved. 
   b) A build option to do this the normal way would be nice. 
   c) I'm guessing a lot of the early ... time in the build is this step. 
2) Parallel builds are done from Python threads vs make -j 
  a) See #1
  b) It would be nice to have a build phase that just generated the makefiles 
including a top level makefile was constructed to enable parallel build. Then 
the top level makefile could call the generated makefile. After that build can 
be called to construct the FDs. 
  c) When we build DEBUG and RELEASE in parallel, or multiple platforms it 
seems like the Python is fighting the make -j. If it was all make -j then make 
could load balance. 
3) The FV construction seems slow and it generates multiple text files per 
section per file and there is lots of calling out between Python and C tools. 
  a) Maybe combining all the FD construction into a single C program would 
allow all the data to be in memory vs. on disk. 
4) It does not seem that the Python code has really been performance tuned. A 
large file was getting parsed 47 time, regex getting called a 1,000,000 times 
etc.
5) Most of the build targets use scripts. 
  a) A top level makefile, and moving some of the work to makefiles could help 
with parallelism. 
  b) I've got this working on our proprietary tree.
1) Had to make Conf/ part of the Buid/ output. I made a small mod to the 
tool to copy the Conf over if the alternate Conf location passed to build did 
not exit. 
2) I had to add .NOTPARALLEL: to some of the BaseTools GNUmakefiles since 
they break for a parallel build. 
3) Then you port the build.sh (or build.bat) to be a makefile. 

Our old parallelized EDK builds took about 2m10s to do a DEBUG build for a 
target, and with the edk2 it is 3m52s.

Thanks,

Andrew Fish

PS As we know from performance tuning the ROM the most important thing to do is 
profile, and not listen to the old grumpy guy :). 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 000/351] Convert EDK II core packages to NASM for IA32/X64

[Andrew Fish]

> On Jun 29, 2016, at 3:19 PM, Kinney, Michael D  
> wrote:
> 
> Liming,
> 
> Thank you Liming and Jordan for all the effort on the conversion 
> tool and patches to update all packages with NASM support and the
> work done to verify that the NASM files produced the same object 
> code as MASM.
> 
> A follow up question I have for the EDK II community is if there
> is interest in retiring the MASM/GAS source files from packages
> and how soon we would like to see those MASM/GAS source files 
> removed.  If there are any known compatibility issues or symbolic 
> debug limitations in using NASM as the only assembler, please let 
> us know so we can start working through those issues.
> 

Mike,

We still don't have support for dead stripping and source level debugging with 
NASM and Xcode clang. So keeping the old GAS around especially for the MdePkg 
library would be an ask for us. 

Thanks,

Andrew Fish

> Thanks,
> 
> Mike
> 
>> -Original Message-
>> From: Gao, Liming
>> Sent: Monday, June 27, 2016 7:03 PM
>> To: Gao, Liming ; Laszlo Ersek ; 
>> Kinney,
>> Michael D ; Justen, Jordan L 
>> 
>> Cc: edk2-de...@ml01.01.org
>> Subject: RE: [edk2] [Patch 000/351] Convert EDK II core packages to NASM for 
>> IA32/X64
>> 
>> Hi, all
>>  I pushed all patches. If you meet with any issues, please raise it to me.
>> 
>> Thanks
>> Liming
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>> Gao, Liming
>>> Sent: Thursday, June 23, 2016 2:23 PM
>>> To: Laszlo Ersek ; Kinney, Michael D
>>> ; Justen, Jordan L 
>>> Cc: edk2-de...@ml01.01.org
>>> Subject: Re: [edk2] [Patch 000/351] Convert EDK II core packages to NASM
>>> for IA32/X64
>>> 
>>> Laszlo:
>>>   Thanks!  If no more comments, I plan to push those patches early next
>>> week.
>>> 
>>> Thanks
>>> Liming
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com]
 Sent: Thursday, June 23, 2016 2:44 AM
 To: Gao, Liming ; Kinney, Michael D
 ; Justen, Jordan L
>>> 
 Cc: edk2-de...@ml01.01.org
 Subject: Re: [edk2] [Patch 000/351] Convert EDK II core packages to NASM
 for IA32/X64
 
 On 06/22/16 05:15, Gao, Liming wrote:
> Laszlo:
> I don't find any other case. I have integrated your patches into
> https://github.com/lgao4/edk2.git branch nasm-v2. Please help check.
 
 I retested the SMM_REQUIRE + S3 cases (Ia32 Fedora, Ia32X64 Fedora,
 Ia32X64 Windows 8.1), with your nasm-v2 branch (at commit
 7c10e13e7c36c593bb102ddc5ae27a747457097f). Everything seems to work
 fine.
 
 I also checked the UefiCpuPkg/PiSmmCpuDxeSmm/*/MpFuncs.nasm files;
 they
 look good.
 
 The commit messages on
 
 9bdcbb94016c3 UefiCpuPkg PiSmmCpuDxeSmm: Update
 Ia32/MpFuncs.nasm
 f6083bde349ce UefiCpuPkg PiSmmCpuDxeSmm: Update
>>> X64/MpFuncs.nasm
 
 seem fine as well.
 
 Thanks!
 Laszlo
 
> 
> Thanks
> Liming
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, June 21, 2016 10:37 AM
> To: Gao, Liming ; Kinney, Michael D
 ; Justen, Jordan L
>>> 
> Cc: edk2-de...@ml01.01.org
> Subject: Re: [edk2] [Patch 000/351] Convert EDK II core packages to
>>> NASM
 for IA32/X64
> 
> On 06/21/16 03:54, Gao, Liming wrote:
>> Laszlo:
>> Thanks for your test and finding. I notice this difference between
>> asm and nasm output file. I read IA32 manual to try understanding 66
>> and 67 prefix operand. I wrongly think 66 has the same functionality
>> to 66 67. So, I think they are same. I will go through all patches to
>> make sure there is no other 67 missing.
>> 
>> ASM dump:
>> 0032: 66 67 EA 00 00 00 jmp _RendezvousFunnelProc
>> 00
>> NASM dump:
>> 0032: 66 EA 00 00 00 00 jmp _RendezvousFunnelProc
> 
> Right, that's the pattern.
> 
> 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

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

Re: [edk2] [Patch 000/351] Convert EDK II core packages to NASM for IA32/X64

[Kinney, Michael D]

Liming,

Thank you Liming and Jordan for all the effort on the conversion 
tool and patches to update all packages with NASM support and the
work done to verify that the NASM files produced the same object 
code as MASM.

A follow up question I have for the EDK II community is if there
is interest in retiring the MASM/GAS source files from packages
and how soon we would like to see those MASM/GAS source files 
removed.  If there are any known compatibility issues or symbolic 
debug limitations in using NASM as the only assembler, please let 
us know so we can start working through those issues.

Thanks,

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Monday, June 27, 2016 7:03 PM
> To: Gao, Liming ; Laszlo Ersek ; 
> Kinney,
> Michael D ; Justen, Jordan L 
> 
> Cc: edk2-de...@ml01.01.org
> Subject: RE: [edk2] [Patch 000/351] Convert EDK II core packages to NASM for 
> IA32/X64
> 
> Hi, all
>   I pushed all patches. If you meet with any issues, please raise it to me.
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Gao, Liming
> > Sent: Thursday, June 23, 2016 2:23 PM
> > To: Laszlo Ersek ; Kinney, Michael D
> > ; Justen, Jordan L 
> > Cc: edk2-de...@ml01.01.org
> > Subject: Re: [edk2] [Patch 000/351] Convert EDK II core packages to NASM
> > for IA32/X64
> >
> > Laszlo:
> >Thanks!  If no more comments, I plan to push those patches early next
> > week.
> >
> > Thanks
> > Liming
> > > -Original Message-
> > > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > > Sent: Thursday, June 23, 2016 2:44 AM
> > > To: Gao, Liming ; Kinney, Michael D
> > > ; Justen, Jordan L
> > 
> > > Cc: edk2-de...@ml01.01.org
> > > Subject: Re: [edk2] [Patch 000/351] Convert EDK II core packages to NASM
> > > for IA32/X64
> > >
> > > On 06/22/16 05:15, Gao, Liming wrote:
> > > > Laszlo:
> > > > I don't find any other case. I have integrated your patches into
> > > > https://github.com/lgao4/edk2.git branch nasm-v2. Please help check.
> > >
> > > I retested the SMM_REQUIRE + S3 cases (Ia32 Fedora, Ia32X64 Fedora,
> > > Ia32X64 Windows 8.1), with your nasm-v2 branch (at commit
> > > 7c10e13e7c36c593bb102ddc5ae27a747457097f). Everything seems to work
> > > fine.
> > >
> > > I also checked the UefiCpuPkg/PiSmmCpuDxeSmm/*/MpFuncs.nasm files;
> > > they
> > > look good.
> > >
> > > The commit messages on
> > >
> > > 9bdcbb94016c3 UefiCpuPkg PiSmmCpuDxeSmm: Update
> > > Ia32/MpFuncs.nasm
> > > f6083bde349ce UefiCpuPkg PiSmmCpuDxeSmm: Update
> > X64/MpFuncs.nasm
> > >
> > > seem fine as well.
> > >
> > > Thanks!
> > > Laszlo
> > >
> > > >
> > > > Thanks
> > > > Liming
> > > > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > > > Sent: Tuesday, June 21, 2016 10:37 AM
> > > > To: Gao, Liming ; Kinney, Michael D
> > > ; Justen, Jordan L
> > 
> > > > Cc: edk2-de...@ml01.01.org
> > > > Subject: Re: [edk2] [Patch 000/351] Convert EDK II core packages to
> > NASM
> > > for IA32/X64
> > > >
> > > > On 06/21/16 03:54, Gao, Liming wrote:
> > > >> Laszlo:
> > > >> Thanks for your test and finding. I notice this difference between
> > > >> asm and nasm output file. I read IA32 manual to try understanding 66
> > > >> and 67 prefix operand. I wrongly think 66 has the same functionality
> > > >> to 66 67. So, I think they are same. I will go through all patches to
> > > >> make sure there is no other 67 missing.
> > > >>
> > > >> ASM dump:
> > > >> 0032: 66 67 EA 00 00 00 jmp _RendezvousFunnelProc
> > > >> 00
> > > >> NASM dump:
> > > >> 0032: 66 EA 00 00 00 00 jmp _RendezvousFunnelProc
> > > >
> > > > Right, that's the pattern.
> > > >
> > > > 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 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Andrew Fish]

> On Jun 29, 2016, at 2:55 PM, Jordan Justen  wrote:
> 
> On 2016-06-29 14:43:30, Andrew Fish wrote:
>> 
>>> On Jun 29, 2016, at 2:40 PM, Jordan Justen  
>>> wrote:
>>> 
>>> Second, didn't Andrew find that parsing tools_def.txt was taking a
>>> significant amount of time during each build invocation?
>> 
>> It was getting parsed 47 times, when it should only get parsed one
>> time. I thought that bug got fixed.
>> 
> 
> Can we close this with a reference to the commit?
> 
> https://github.com/tianocore/edk2/issues/56
> 

Done!

commit 213ae07750fc7532e8ba62a234e958388d1f0359
Author: Yonghong Zhu 
Date:   Tue Mar 29 12:59:43 2016 +0800

BaseTools: cache the defined Guid tool to improve the performance

Current GenFds Tool class GuidSection() is parsing the tools_def.txt for
every GUID'ed section that has a GUID defined tool, it cause a bad
performance. so this patch cache the defined Guid tool to improve the
performance.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

Thanks,

Andrew Fish


> -Jordan
> 
>> If you want to test the time impact just prune you
>> Conf/tools_def.txt to the toolchain you are using and compare the
>> build time against the tools_def.template.
>> 
>> Thanks,
>> 
>> Andrew Fish

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

Re: [edk2] [PATCH V2] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

[Kinney, Michael D]

Reviewed-by: Michael Kinney 

Mike

> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, June 29, 2016 2:46 PM
> To: edk2-devel@lists.01.org
> Cc: Fan, Jeff ; Kinney, Michael D 
> ;
> Laszlo Ersek 
> Subject: [PATCH V2] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS 
> check.
> 
> PI specification Vol 4 - SMM does not have any limitation of BASE_4GB for SMM.
> So we should replace BASE_4GB check with MAX_ADDRESS check to make sure
> the SMM memory is accessible by SMM Core.
> 
> Cc: Jeff Fan 
> Cc: Michael D Kinney 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 2 +-
>  MdeModulePkg/Core/PiSmmCore/Pool.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> index acfcc83..3788bd5 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> @@ -1556,7 +1556,7 @@ SmmIplEntry (
>  }
> 
>  if (gSmmCorePrivate->SmramRanges[Index].CpuStart >= BASE_1MB) {
> -  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + gSmmCorePrivate-
> >SmramRanges[Index].PhysicalSize) <= BASE_4GB) {
> +  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + gSmmCorePrivate-
> >SmramRanges[Index].PhysicalSize - 1) <= MAX_ADDRESS) {
>  if (gSmmCorePrivate->SmramRanges[Index].PhysicalSize >= MaxSize) {
>MaxSize = gSmmCorePrivate->SmramRanges[Index].PhysicalSize;
>mCurrentSmramRange = &gSmmCorePrivate->SmramRanges[Index];
> diff --git a/MdeModulePkg/Core/PiSmmCore/Pool.c 
> b/MdeModulePkg/Core/PiSmmCore/Pool.c
> index 761988e..e493fd2 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Pool.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Pool.c
> @@ -67,7 +67,7 @@ SmmInitializeMemoryServices (
>}
> 
>if (SmramRanges[Index].CpuStart >= BASE_1MB) {
> -if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize) 
> <=
> BASE_4GB) {
> +if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize - 
> 1) <=
> MAX_ADDRESS) {
>if (SmramRanges[Index].PhysicalSize >= MaxSize) {
>  MaxSize = SmramRanges[Index].PhysicalSize;
>  CurrentSmramRangesIndex = Index;
> --
> 2.7.4.windows.1

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

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Kinney, Michael D]

Jordan,

My mistake.  I responded to the wrong email.  

Additional responses below.

Mike


> -Original Message-
> From: Justen, Jordan L
> Sent: Wednesday, June 29, 2016 2:40 PM
> To: Kinney, Michael D ; Shi, Steven 
> ;
> edk2-devel@lists.01.org; Gao, Liming ; Kinney, Michael D
> 
> Cc: af...@apple.com
> Subject: RE: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type 
> for LTO
> build
> 
> Why didn't you reply to my message where I made the related comments?
> It kind of confuses the email threading this way...
> 
> On 2016-06-29 14:04:49, Kinney, Michael D wrote:
> > Jordan,
> >
> > Steven has been maintaining a public branch of this work at:
> >
> > https://github.com/shijunjing/edk2/tree
> >
> > The latest patch series appears to be in the following branch:
> >
> > https://github.com/shijunjing/edk2/tree/review4
> >
> 
> Thanks. Maybe Steven can name them as something like linux-lto-v1, and
> mention the branch in the cover letter in the future.

These are not linux.  They are GCC and CLANG.  I agree the branch names need
to be more descriptive, and that adding the branch name to the patch series
summary is always a good idea if a public branch is available.

> 
> > Why do you think we do not need a new tool chain tag for CLANG based static 
> > analysis?
> > I think it is very valuable to have static analysis for EDK II builds.  We 
> > do not
> > want to run static analysis as part of a normal FW build, so we need a way 
> > to run
> > that type of build.
> >
> 
> First, I don't think we should readily add new toolchains so long as
> we cannot deprecate old useless toolchains. I'll admit that my
> frustration about old toolchains is more of a concern to me than
> adding a new toolchain.
> 
> Second, didn't Andrew find that parsing tools_def.txt was taking a
> significant amount of time during each build invocation?

That was fixed.  The issue was parsing that file more than once.

> 
> One idea I have is: Can we get BaseTools to allow target.txt to have
> $(TOOLCHAIN) in TOOL_CHAIN_CONF? Then we could set:
> 
> TOOL_CHAIN_CONF = BaseTools/Conf/tools_def.$(TOOLCHAIN)
> 
> This would let us split each toolchain into a separate file. I would
> recommend we then add at the top of each file a comment with the
> support status. Something like:
> 
> # Support Status: Maintained
> 
> # Support Status: Community
> 
> # Support Status: Deprecated

I agree there are many ways to reduce size of tools_def.txt.  
Removing tool chain tags that are no longer viable at all is 
a good idea.  But it seems every time I see that type of 
discussion, someone jumps in and says they are still using it :)
I do like the deprecated idea.

Why can't we simply use the target.txt TOOL_CHAIN_CONF define
in target.txt as it works today?  You could split tools_def.txt
into several versions, with the default one being the maintained
one and developers can opt into community or deprecated ones.

I do want to make sure we are focused on the right problem here

1) # lines in tools_def.txt
2) maintenance of tools_def.txt
3) build performance

I think the build performance issues have been addressed.  If someone
is aware of build performance issues for the length of tools_def.txt
please let us know and we can work on that.

One aspect of tools_def.txt syntax that has always bothered me is that
tool chains that are closely related require lots of almost duplicate
lines.  I have been considering the concept of being able to declare
that one tool chain is related to another tool chain and we only need
to describe the deltas.  That would reduce lines and simplify maintenance
and may reduce the need to split out tool chains into categories.


> 
> -Jordan
> 
> >
> > > -Original Message-
> > > From: Justen, Jordan L
> > > Sent: Wednesday, June 29, 2016 1:57 PM
> > > To: Shi, Steven ; edk2-devel@lists.01.org; Gao, 
> > > Liming
> > > 
> > > Cc: Kinney, Michael D ; af...@apple.com
> > > Subject: Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation 
> > > type for LTO
> > > build
> > >
> > > The subject prefix should be: "BaseTools/GenFw"
> > >
> > > Should this patch move before 1/7?
> > >
> > > -Jordan
> > >
> > > On 2016-06-28 08:18:56, Shi, Steven wrote:
> > > > Add support to convert missing Elf relocation types
> > > > (R_X86_64_PLT32, R_X86_64_GOTPCREL, R_X86_64_REX_GOTPCRELX)
> > > > to PeCoff, which are required by LTO image.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > > Signed-off-by: Steven Shi 
> > > > ---
> > > >  BaseTools/Source/C/GenFw/Elf64Convert.c | 98 
> > > > -
> > > >  BaseTools/Source/C/GenFw/elf_common.h   |  2 +-
> > > >  2 files changed, 86 insertions(+), 14 deletions(-)
> > > >  mode change 100644 => 100755 BaseTools/Source/C/GenFw/Elf64Convert.c
> > > >  mode change 100644 => 100755 BaseTools/Source/C/GenFw/elf_common.h
> > > >
> > > > diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
> > > b/BaseTools/Source/C/Gen

Re: [edk2] [PATCH] OvmfPkg/build.sh: update gcc detection

[Jordan Justen]

On 2016-06-29 12:30:35, Olaf Hering wrote:
> Adjust the code to look forward instead of backwards.
> Existing gcc releases are known to work or break. Upcoming gcc releases
> are assumed to work like the last handled gcc version does.
> Doing it that way will reduce the burden to update the script for each
> upcoming gcc variant.
> 
> This fixes issue #99.

Fixes: https://github.com/tianocore/edk2/issues/99

> Signed-off-by: Olaf Hering 

Missing Contributed-under. (See OvmfPkg/Contributions.txt)

> ---
>  OvmfPkg/build.sh | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index eb5eb73..b40e561 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -83,6 +83,13 @@ case `uname` in
>Linux*)
>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>  case $gcc_version in
> +  4.[3210].*|3.*|2.*)
> +echo "gcc version $gcc_version is unsupported"
> +exit 1
> +;;
> +  4.4.*)
> +TARGET_TOOLS=GCC44
> +;;
>4.5.*)
>  TARGET_TOOLS=GCC45
>  ;;
> @@ -99,7 +106,8 @@ case `uname` in
>  TARGET_TOOLS=GCC49
>  ;;
>*)
> -TARGET_TOOLS=GCC44
> +# assume the latest, we cant keep up with gcc releases

I think we should not add this comment.

-Jordan

> +TARGET_TOOLS=GCC49
>  ;;
>  esac
>  esac
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Jordan Justen]

On 2016-06-29 14:43:30, Andrew Fish wrote:
> 
> > On Jun 29, 2016, at 2:40 PM, Jordan Justen  
> > wrote:
> > 
> > Second, didn't Andrew find that parsing tools_def.txt was taking a
> > significant amount of time during each build invocation?
> 
> It was getting parsed 47 times, when it should only get parsed one
> time. I thought that bug got fixed.
> 

Can we close this with a reference to the commit?

https://github.com/tianocore/edk2/issues/56

-Jordan

> If you want to test the time impact just prune you
> Conf/tools_def.txt to the toolchain you are using and compare the
> build time against the tools_def.template.
> 
> Thanks,
> 
> Andrew Fish
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V2] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

[Laszlo Ersek]

On 06/29/16 23:45, Jiewen Yao wrote:
> PI specification Vol 4 - SMM does not have any limitation of BASE_4GB for SMM.
> So we should replace BASE_4GB check with MAX_ADDRESS check to make sure
> the SMM memory is accessible by SMM Core.
> 
> Cc: Jeff Fan 
> Cc: Michael D Kinney 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 2 +-
>  MdeModulePkg/Core/PiSmmCore/Pool.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
> b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> index acfcc83..3788bd5 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> @@ -1556,7 +1556,7 @@ SmmIplEntry (
>  }
>  
>  if (gSmmCorePrivate->SmramRanges[Index].CpuStart >= BASE_1MB) {
> -  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
> gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= BASE_4GB) {
> +  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
> gSmmCorePrivate->SmramRanges[Index].PhysicalSize - 1) <= MAX_ADDRESS) {
>  if (gSmmCorePrivate->SmramRanges[Index].PhysicalSize >= MaxSize) {
>MaxSize = gSmmCorePrivate->SmramRanges[Index].PhysicalSize;
>mCurrentSmramRange = &gSmmCorePrivate->SmramRanges[Index];
> diff --git a/MdeModulePkg/Core/PiSmmCore/Pool.c 
> b/MdeModulePkg/Core/PiSmmCore/Pool.c
> index 761988e..e493fd2 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Pool.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Pool.c
> @@ -67,7 +67,7 @@ SmmInitializeMemoryServices (
>}
>  
>if (SmramRanges[Index].CpuStart >= BASE_1MB) {
> -if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize) 
> <= BASE_4GB) {
> +if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize - 
> 1) <= MAX_ADDRESS) {
>if (SmramRanges[Index].PhysicalSize >= MaxSize) {
>  MaxSize = SmramRanges[Index].PhysicalSize;
>  CurrentSmramRangesIndex = Index;
> 

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

Re: [edk2] [PATCH 3/7] MdePkg: Enable new MS VA intrinsics for GNUC 64bits build

[Jordan Justen]

On 2016-06-29 14:31:49, Andrew Fish wrote:
> 
> > On Jun 29, 2016, at 2:02 PM, Jordan Justen  
> > wrote:
> > 
> > On 2016-06-28 08:18:57, Shi, Steven wrote:
> >> Both GCC and LLVM 3.8 64bits support new variable argument (VA)
> > 
> > Which versions of GCC? Maybe we should define MS_VA_LIST on the
> > command line for toolchains that can support this?
> > 
> 
> Maybe I'm backwards but VA_LIST is by definition MS_VA_LIST. What
> you lose access to is UNIX_VA_LIST?
> 
> Thus for a compiler that uses the EFIAPI __builtin_va_arg is EFIABI.
> For a compiler that produces Sys V ABI __builtin_va_arg is the Unix
> ABI. I verified this assertion with the clang maintainers.
> 
> VA_LIST always points to EFIAPI and that is why you have to decorate
> var arg functions with EFIAPI to match VA_LIST.
> 
> We could add a NATIVE_VA_LIST but for an compiler that natively does
> EFIAPI it would be the same a VA_LIST. Thus it would be hard to
> enforce, but it would let some one that knew what they are doing get
> access to __builtin_va_arg. The problem is if you know what you are
> doing you can decorate with EFIAPI so is adding NATIVE_VA_LIST
> really solving any problem?
> 

My concern was more about if this patch would work on GCC44. I think
Steven has been testing with GCC5+, so I thought it might be better to
selectively enable usage of __builtin_ms_va_list for each toolchain.

-Jordan

> > 
> >> 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 conversion
> >> as MS, so we don’t need change them.
> >> 
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Steven Shi 
> >> ---
> >> MdePkg/Include/Base.h | 27 +--
> >> 1 file changed, 25 insertions(+), 2 deletions(-)
> >> mode change 100644 => 100755 MdePkg/Include/Base.h
> >> 
> >> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> >> old mode 100644
> >> new mode 100755
> >> index cbd9e55..05fccf3
> >> --- a/MdePkg/Include/Base.h
> >> +++ b/MdePkg/Include/Base.h
> >> @@ -588,9 +588,32 @@ struct _LIST_ENTRY {
> >> 
> >> #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
> >> 
> >> -#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
> >> +
> >> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && !defined 
> >> (EFI32)
> >> +//
> >> +// 64bits build only. Use GCC built-in macros for variable argument lists.
> >> +//
> >> +///
> >> +/// Both GCC and LLVM 3.8 64bits 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)
> >> +
> >> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && defined 
> >> (EFI32)
> >> //
> >> -// Use GCC built-in macros for variable argument lists.
> >> +// 32bits build only. Use GCC built-in macros for variable argument lists.
> >> //
> >> 
> >> ///
> >> -- 
> >> 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
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH V2] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

[Jiewen Yao]

PI specification Vol 4 - SMM does not have any limitation of BASE_4GB for SMM.
So we should replace BASE_4GB check with MAX_ADDRESS check to make sure
the SMM memory is accessible by SMM Core.

Cc: Jeff Fan 
Cc: Michael D Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 2 +-
 MdeModulePkg/Core/PiSmmCore/Pool.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index acfcc83..3788bd5 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -1556,7 +1556,7 @@ SmmIplEntry (
 }
 
 if (gSmmCorePrivate->SmramRanges[Index].CpuStart >= BASE_1MB) {
-  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= BASE_4GB) {
+  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
gSmmCorePrivate->SmramRanges[Index].PhysicalSize - 1) <= MAX_ADDRESS) {
 if (gSmmCorePrivate->SmramRanges[Index].PhysicalSize >= MaxSize) {
   MaxSize = gSmmCorePrivate->SmramRanges[Index].PhysicalSize;
   mCurrentSmramRange = &gSmmCorePrivate->SmramRanges[Index];
diff --git a/MdeModulePkg/Core/PiSmmCore/Pool.c 
b/MdeModulePkg/Core/PiSmmCore/Pool.c
index 761988e..e493fd2 100644
--- a/MdeModulePkg/Core/PiSmmCore/Pool.c
+++ b/MdeModulePkg/Core/PiSmmCore/Pool.c
@@ -67,7 +67,7 @@ SmmInitializeMemoryServices (
   }
 
   if (SmramRanges[Index].CpuStart >= BASE_1MB) {
-if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize) <= 
BASE_4GB) {
+if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize - 
1) <= MAX_ADDRESS) {
   if (SmramRanges[Index].PhysicalSize >= MaxSize) {
 MaxSize = SmramRanges[Index].PhysicalSize;
 CurrentSmramRangesIndex = Index;
-- 
2.7.4.windows.1

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

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Andrew Fish]

> On Jun 29, 2016, at 2:40 PM, Jordan Justen  wrote:
> 
> Second, didn't Andrew find that parsing tools_def.txt was taking a
> significant amount of time during each build invocation?

It was getting parsed 47 times, when it should only get parsed one time. I 
thought that bug got fixed. 

If you want to test the time impact just prune you Conf/tools_def.txt to the 
toolchain you are using and compare the build time against the 
tools_def.template.

Thanks,

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

[edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

[Jiewen Yao]

PI specification Vol 4 - SMM does not have any limitation of BASE_4GB for SMM.
So we should replace BASE_4GB check with MAX_ADDRESS check to make sure
the SMM memory is accessible by SMM Core.

Cc: Jeff Fan 
Cc: Michael D Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 2 +-
 MdeModulePkg/Core/PiSmmCore/Pool.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index acfcc83..3788bd5 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -1556,7 +1556,7 @@ SmmIplEntry (
 }
 
 if (gSmmCorePrivate->SmramRanges[Index].CpuStart >= BASE_1MB) {
-  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= BASE_4GB) {
+  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
gSmmCorePrivate->SmramRanges[Index].PhysicalSize - 1) <= MAX_ADDRESS) {
 if (gSmmCorePrivate->SmramRanges[Index].PhysicalSize >= MaxSize) {
   MaxSize = gSmmCorePrivate->SmramRanges[Index].PhysicalSize;
   mCurrentSmramRange = &gSmmCorePrivate->SmramRanges[Index];
diff --git a/MdeModulePkg/Core/PiSmmCore/Pool.c 
b/MdeModulePkg/Core/PiSmmCore/Pool.c
index 761988e..e493fd2 100644
--- a/MdeModulePkg/Core/PiSmmCore/Pool.c
+++ b/MdeModulePkg/Core/PiSmmCore/Pool.c
@@ -67,7 +67,7 @@ SmmInitializeMemoryServices (
   }
 
   if (SmramRanges[Index].CpuStart >= BASE_1MB) {
-if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize) <= 
BASE_4GB) {
+if ((SmramRanges[Index].CpuStart + SmramRanges[Index].PhysicalSize - 
1) <= MAX_ADDRESS) {
   if (SmramRanges[Index].PhysicalSize >= MaxSize) {
 MaxSize = SmramRanges[Index].PhysicalSize;
 CurrentSmramRangesIndex = Index;
-- 
2.7.4.windows.1

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

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Jordan Justen]

Why didn't you reply to my message where I made the related comments?
It kind of confuses the email threading this way...

On 2016-06-29 14:04:49, Kinney, Michael D wrote:
> Jordan,
> 
> Steven has been maintaining a public branch of this work at:
> 
> https://github.com/shijunjing/edk2/tree
> 
> The latest patch series appears to be in the following branch:
> 
> https://github.com/shijunjing/edk2/tree/review4
> 

Thanks. Maybe Steven can name them as something like linux-lto-v1, and
mention the branch in the cover letter in the future.

> Why do you think we do not need a new tool chain tag for CLANG based static 
> analysis?
> I think it is very valuable to have static analysis for EDK II builds.  We do 
> not
> want to run static analysis as part of a normal FW build, so we need a way to 
> run
> that type of build.
> 

First, I don't think we should readily add new toolchains so long as
we cannot deprecate old useless toolchains. I'll admit that my
frustration about old toolchains is more of a concern to me than
adding a new toolchain.

Second, didn't Andrew find that parsing tools_def.txt was taking a
significant amount of time during each build invocation?

One idea I have is: Can we get BaseTools to allow target.txt to have
$(TOOLCHAIN) in TOOL_CHAIN_CONF? Then we could set:

TOOL_CHAIN_CONF = BaseTools/Conf/tools_def.$(TOOLCHAIN)

This would let us split each toolchain into a separate file. I would
recommend we then add at the top of each file a comment with the
support status. Something like:

# Support Status: Maintained

# Support Status: Community

# Support Status: Deprecated

-Jordan

> 
> > -Original Message-
> > From: Justen, Jordan L
> > Sent: Wednesday, June 29, 2016 1:57 PM
> > To: Shi, Steven ; edk2-devel@lists.01.org; Gao, Liming
> > 
> > Cc: Kinney, Michael D ; af...@apple.com
> > Subject: Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type 
> > for LTO
> > build
> > 
> > The subject prefix should be: "BaseTools/GenFw"
> > 
> > Should this patch move before 1/7?
> > 
> > -Jordan
> > 
> > On 2016-06-28 08:18:56, Shi, Steven wrote:
> > > Add support to convert missing Elf relocation types
> > > (R_X86_64_PLT32, R_X86_64_GOTPCREL, R_X86_64_REX_GOTPCRELX)
> > > to PeCoff, which are required by LTO image.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Steven Shi 
> > > ---
> > >  BaseTools/Source/C/GenFw/Elf64Convert.c | 98 
> > > -
> > >  BaseTools/Source/C/GenFw/elf_common.h   |  2 +-
> > >  2 files changed, 86 insertions(+), 14 deletions(-)
> > >  mode change 100644 => 100755 BaseTools/Source/C/GenFw/Elf64Convert.c
> > >  mode change 100644 => 100755 BaseTools/Source/C/GenFw/elf_common.h
> > >
> > > diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
> > b/BaseTools/Source/C/GenFw/Elf64Convert.c
> > > old mode 100644
> > > new mode 100755
> > > index 024a2a0..205360c
> > > --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> > > +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> > > @@ -75,7 +75,7 @@ CleanUp64 (
> > >);
> > >
> > >  //
> > > -// Rename ELF32 strucutres to common names to help when porting to ELF64.
> > > +// Rename ELF32 structures to common names to help when porting to ELF64.
> > >  //
> > >  typedef Elf64_Shdr Elf_Shdr;
> > >  typedef Elf64_Ehdr Elf_Ehdr;
> > > @@ -233,7 +233,7 @@ IsTextShdr (
> > >Elf_Shdr *Shdr
> > >)
> > >  {
> > > -  return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == 
> > > SHF_ALLOC);
> > > +  return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | 
> > > SHF_ALLOC)) ==
> > (SHF_EXECINSTR | SHF_ALLOC));
> > >  }
> > >
> > >  STATIC
> > > @@ -256,7 +256,7 @@ IsDataShdr (
> > >if (IsHiiRsrcShdr(Shdr)) {
> > >  return FALSE;
> > >}
> > > -  return (BOOLEAN) (Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == 
> > > (SHF_ALLOC |
> > SHF_WRITE);
> > > +  return (BOOLEAN) (Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | 
> > > SHF_ALLOC)) ==
> > (SHF_ALLOC | SHF_WRITE);
> > >  }
> > >
> > >  STATIC
> > > @@ -661,9 +661,9 @@ WriteSections64 (
> > >
> > >default:
> > >  //
> > > -//  Ignore for unkown section type.
> > > +//  Ignore for unknown section type.
> > >  //
> > > -VerboseMsg ("%s unknown section type %x. We directly copy this 
> > > section into
> > Coff file", mInImageName, (unsigned)Shdr->sh_type);
> > > +VerboseMsg ("%s unknown section type %x. We directly ignore this 
> > > section and
> > NOT copy into Coff file", mInImageName, (unsigned)Shdr->sh_type);
> > >  break;
> > >}
> > >  }
> > > @@ -763,24 +763,24 @@ WriteSections64 (
> > >  // Absolute relocation.
> > >  //
> > >  VerboseMsg ("R_X86_64_64");
> > > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
> > > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> > > +VerboseMsg ("Offset: 0x%08X, Addend: 0x

Re: [edk2] [PATCH 3/7] MdePkg: Enable new MS VA intrinsics for GNUC 64bits build

[Andrew Fish]

> On Jun 29, 2016, at 2:02 PM, Jordan Justen  wrote:
> 
> On 2016-06-28 08:18:57, Shi, Steven wrote:
>> Both GCC and LLVM 3.8 64bits support new variable argument (VA)
> 
> Which versions of GCC? Maybe we should define MS_VA_LIST on the
> command line for toolchains that can support this?
> 

Maybe I'm backwards but VA_LIST is by definition MS_VA_LIST. What you lose 
access to is UNIX_VA_LIST?

Thus for a compiler that uses the EFIAPI __builtin_va_arg is EFIABI. For a 
compiler that produces Sys V ABI __builtin_va_arg is the Unix ABI. I verified 
this assertion with the clang maintainers. 

VA_LIST always points to EFIAPI and that is why you have to decorate var arg 
functions with EFIAPI to match VA_LIST. 

We could add a NATIVE_VA_LIST but for an compiler that natively does EFIAPI it 
would be the same a VA_LIST. Thus it would be hard to enforce, but it would let 
some one that knew what they are doing get access to __builtin_va_arg. The 
problem is if you know what you are doing you can decorate with EFIAPI so is 
adding NATIVE_VA_LIST really solving any problem?

Thanks,

Andrew Fish

> -Jordan
> 
>> 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 conversion
>> as MS, so we don’t need change them.
>> 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Steven Shi 
>> ---
>> MdePkg/Include/Base.h | 27 +--
>> 1 file changed, 25 insertions(+), 2 deletions(-)
>> mode change 100644 => 100755 MdePkg/Include/Base.h
>> 
>> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
>> old mode 100644
>> new mode 100755
>> index cbd9e55..05fccf3
>> --- a/MdePkg/Include/Base.h
>> +++ b/MdePkg/Include/Base.h
>> @@ -588,9 +588,32 @@ struct _LIST_ENTRY {
>> 
>> #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
>> 
>> -#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
>> +
>> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && !defined (EFI32)
>> +//
>> +// 64bits build only. Use GCC built-in macros for variable argument lists.
>> +//
>> +///
>> +/// Both GCC and LLVM 3.8 64bits 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)
>> +
>> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && defined (EFI32)
>> //
>> -// Use GCC built-in macros for variable argument lists.
>> +// 32bits build only. Use GCC built-in macros for variable argument lists.
>> //
>> 
>> ///
>> -- 
>> 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

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

Re: [edk2] iPXE invalidates the OVMF network device options

[Laszlo Ersek]

On 06/29/16 22:42, Gerd Hoffmann wrote:
>   Hi,
> 
>> ... Hm, actually, I have one suspect. In your report, you said the
>> boot option called "UEFI PXEv4" worked fine. "EFI Network" didn't, and
>> it was higher up in the boot order.
>>
>> I think "EFI Network" could be a left-over boot option (from the old
>> IntelFrameworkModulePkg BDS) that doesn't work any longer.
> 
> Could very well be.  Those virtual machines exist for a while already.
> 
>> And, due to how the boot option ("bootorder" fw_cfg) matching works in
>> OVMF, both "EFI Network" and "UEFI PXEv4" may have device paths
>> associated with them that match the QEMU boot order specification.
>> Since "EFI Network" is already in your varstore, at the top of the
>> boot order, that one is tried. (I think "UEFI PXEv4" is even dropped
>> by OVMF's filtering, it's just that when you enter the UI application
>> in OVMF, a bunch of boot options are regenerated at the end of the
>> list again).
> 
> Very plausible.  /me goes delete the old varstore.  Trying again ...
> 
> Yep, "EFI Network" is gone now.  "UEFI PXEv4" is first in the list.
> Everything working fine.

Awesome! :)

>> edk2 sometimes undergoes non-compatible changes where manual massaging
>> of the varstore is required. Recently there was another example when
>> even the UEFI spec changed incompatibily; see
>>
>> https://github.com/tianocore/edk2/commit/d5aee61bfaaa
>> https://github.com/tianocore/edk2/commit/1da761664949
>>
>> I don't have a good automated solution for this kind of change, 
>> unfortunately.
> 
> Hmm.  How is this handled on physical hardware?
> 
> I suspect it'll be to not release that kind of firmware update in the
> first place.  Or a paragraph in the release notes.

I think so, yes.

I believe most proprietary / phys firmware vendors base their stuff on
"stable / validated" releases of edk2, called UDK-. For example,

http://www.tianocore.org/udk/udk2015/

And rebasing their closed forks on a new UDK-xxx release is always a big
deal for them -- there have been cases when vendors complained or asked
for info on edk2-devel, after encountering incompatible changes between
UDK releases. (UDK releases do have relnotes.)

OvmfPkg is not among the packages that UDK comprises.

Thanks!
Laszlo

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

Re: [edk2] [PATCH 3/6] QuarkPlatformPkg: fix ASSERT_EFI_ERROR() typos

[Kinney, Michael D]

Reviewed-by: Michael Kinney 

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, June 28, 2016 6:26 AM
> To: edk2-devel-01 
> Cc: Kinney, Michael D ; Steele, Kelly
> 
> Subject: [PATCH 3/6] QuarkPlatformPkg: fix ASSERT_EFI_ERROR() typos
> 
> A number of code locations use
> 
>   ASSERT_EFI_ERROR (BooleanExpression)
> 
> instead of
> 
>   ASSERT (BooleanExpression)
> 
> Fix them.
> 
> Cc: Michael D Kinney 
> Cc: Kelly Steele 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> not even build tested
> 
>  QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c  | 2 +-
>  QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c  | 2 +-
>  QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c | 2 +-
>  QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c| 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> index 309eb041ee92..36300efd3146 100644
> --- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> +++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.c
> @@ -680,7 +680,7 @@ AcpiPlatformEntryPoint (
>// Init Pci Device PRT PRW information structure from PCD
>//
>mConfigData = (PCI_DEVICE_SETTING *)AllocateZeroPool (sizeof 
> (PCI_DEVICE_SETTING));
> -  ASSERT_EFI_ERROR (mConfigData);
> +  ASSERT (mConfigData != NULL);
>InitPciDeviceInfoStructure (mConfigData);
>//
>// Get the Acpi SDT protocol for manipulation on acpi table
> diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> index 11781e03f4c5..98035bedd58f 100644
> --- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> +++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/MadtPlatform.c
> @@ -218,7 +218,7 @@ MadtTableInitialize (
>//ASSERT (NumberOfCPUs <= 2 && NumberOfCPUs > 0);
>MadtSize = GetAcutalMadtTableSize (&MadtConfigData, NumberOfCPUs);
>Madt = (EFI_ACPI_2_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER 
> *)AllocateZeroPool
> (MadtSize);
> -  ASSERT_EFI_ERROR (Madt);
> +  ASSERT (Madt != NULL);
>//
>// Initialize MADT Header information
>//
> diff --git a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> index 441f7609a536..39185bc0d5ff 100644
> --- a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> +++ b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperDxe.c
> @@ -174,7 +174,7 @@ PlatformFlashLockConfig (
>//
> 
>SpiProtocol = LocateSpiProtocol (NULL);  // This routine will not be 
> called in SMM.
> -  ASSERT_EFI_ERROR (SpiProtocol != NULL);
> +  ASSERT (SpiProtocol != NULL);
>if (SpiProtocol != NULL) {
>  Status = SpiProtocol->Lock (SpiProtocol);
> 
> diff --git a/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> b/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> index df6c1cc23240..6b07d7829328 100644
> --- a/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> +++ b/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c
> @@ -1034,7 +1034,7 @@ InstallS3Memory (
>// memory above 1MB. So Memory Callback can set cache for the system memory
>// correctly on S3 boot path, just like it does on Normal boot path.
>//
> -  ASSERT_EFI_ERROR ((S3MemoryRangeData->SystemMemoryLength - 0x10) > 0);
> +  ASSERT ((S3MemoryRangeData->SystemMemoryLength - 0x10) > 0);
>BuildResourceDescriptorHob (
>  EFI_RESOURCE_SYSTEM_MEMORY,
>  (
> --
> 1.8.3.1
> 

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

Re: [edk2] [PATCH 5/6] UefiCpuPkg: fix ASSERT_EFI_ERROR() typos

[Kinney, Michael D]

Reviewed-by: Michael Kinney 

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Tuesday, June 28, 2016 6:26 AM
> To: edk2-devel-01 
> Cc: Fan, Jeff 
> Subject: [edk2] [PATCH 5/6] UefiCpuPkg: fix ASSERT_EFI_ERROR() typos
> 
> A number of code locations use
> 
>   ASSERT_EFI_ERROR (BooleanExpression)
> 
> instead of
> 
>   ASSERT (BooleanExpression)
> 
> Fix them.
> 
> Cc: Jeff Fan 
> Reported-by: Gerd Hoffmann 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> index 79e23ef6476e..065fb2c24c7d 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c
> @@ -78,7 +78,7 @@ InitPagesForPFHandler (
>//
>Address = NULL;
>Address = AllocatePages (MAX_PF_PAGE_COUNT);
> -  ASSERT_EFI_ERROR (Address != NULL);
> +  ASSERT (Address != NULL);
> 
>mPFPageBuffer =  (UINT64)(UINTN) Address;
>mPFPageIndex = 0;
> --
> 1.8.3.1
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 6/7] QuarkSocPkg-OhicPei: Fix wrong operator

[Andrew Fish]

> On Jun 29, 2016, at 2:23 PM, Kinney, Michael D  
> wrote:
> 
> Reviewed-by: Michael Kinney 
> 
Reviewed-by: Andrew Fish 

>> -Original Message-
>> From: Shi, Steven
>> Sent: Tuesday, June 28, 2016 8:19 AM
>> To: edk2-devel@lists.01.org; Gao, Liming 
>> Cc: Kinney, Michael D ; af...@apple.com; Shi, 
>> Steven
>> 
>> Subject: [PATCH 6/7] QuarkSocPkg-OhicPei: Fix wrong operator
>> 
>> LANG38 find a bug and give a warning that Ohci silicon code wrongly
>> use '||' as '|'.
>> 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Steven Shi 
>> ---
>> QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> mode change 100644 => 100755 
>> QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
>> 
>> diff --git a/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
>> b/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
>> old mode 100644
>> new mode 100755
>> index bb33989..65116c8
>> --- a/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
>> +++ b/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
>> @@ -1042,7 +1042,7 @@ OhciSetRootHubDescriptor (
>>   HcRH_DESC_B DescriptorB;
>> 
>> 
>> -  if (Field & (RH_DEV_REMOVABLE || RH_PORT_PWR_CTRL_MASK)) {
>> +  if (Field & (RH_DEV_REMOVABLE | RH_PORT_PWR_CTRL_MASK)) {
>> *(UINT32 *) &DescriptorB = OhciGetOperationalReg (Ohc, HC_RH_DESC_B);
>> 
>> if(Field & RH_DEV_REMOVABLE) {
>> --
>> 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] [PATCH 6/7] QuarkSocPkg-OhicPei: Fix wrong operator

[Kinney, Michael D]

Reviewed-by: Michael Kinney 

> -Original Message-
> From: Shi, Steven
> Sent: Tuesday, June 28, 2016 8:19 AM
> To: edk2-devel@lists.01.org; Gao, Liming 
> Cc: Kinney, Michael D ; af...@apple.com; Shi, 
> Steven
> 
> Subject: [PATCH 6/7] QuarkSocPkg-OhicPei: Fix wrong operator
> 
> LANG38 find a bug and give a warning that Ohci silicon code wrongly
> use '||' as '|'.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Steven Shi 
> ---
>  QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  mode change 100644 => 100755 
> QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
> 
> diff --git a/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
> b/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
> old mode 100644
> new mode 100755
> index bb33989..65116c8
> --- a/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
> +++ b/QuarkSocPkg/QuarkSouthCluster/Usb/Ohci/Pei/OhciReg.c
> @@ -1042,7 +1042,7 @@ OhciSetRootHubDescriptor (
>HcRH_DESC_B DescriptorB;
> 
> 
> -  if (Field & (RH_DEV_REMOVABLE || RH_PORT_PWR_CTRL_MASK)) {
> +  if (Field & (RH_DEV_REMOVABLE | RH_PORT_PWR_CTRL_MASK)) {
>  *(UINT32 *) &DescriptorB = OhciGetOperationalReg (Ohc, HC_RH_DESC_B);
> 
>  if(Field & RH_DEV_REMOVABLE) {
> --
> 2.7.4

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

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Kinney, Michael D]

Jordan,

Steven has been maintaining a public branch of this work at:

https://github.com/shijunjing/edk2/tree

The latest patch series appears to be in the following branch:

https://github.com/shijunjing/edk2/tree/review4

Why do you think we do not need a new tool chain tag for CLANG based static 
analysis?
I think it is very valuable to have static analysis for EDK II builds.  We do 
not
want to run static analysis as part of a normal FW build, so we need a way to 
run
that type of build.

Thanks,

Mike


> -Original Message-
> From: Justen, Jordan L
> Sent: Wednesday, June 29, 2016 1:57 PM
> To: Shi, Steven ; edk2-devel@lists.01.org; Gao, Liming
> 
> Cc: Kinney, Michael D ; af...@apple.com
> Subject: Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type 
> for LTO
> build
> 
> The subject prefix should be: "BaseTools/GenFw"
> 
> Should this patch move before 1/7?
> 
> -Jordan
> 
> On 2016-06-28 08:18:56, Shi, Steven wrote:
> > Add support to convert missing Elf relocation types
> > (R_X86_64_PLT32, R_X86_64_GOTPCREL, R_X86_64_REX_GOTPCRELX)
> > to PeCoff, which are required by LTO image.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Steven Shi 
> > ---
> >  BaseTools/Source/C/GenFw/Elf64Convert.c | 98 
> > -
> >  BaseTools/Source/C/GenFw/elf_common.h   |  2 +-
> >  2 files changed, 86 insertions(+), 14 deletions(-)
> >  mode change 100644 => 100755 BaseTools/Source/C/GenFw/Elf64Convert.c
> >  mode change 100644 => 100755 BaseTools/Source/C/GenFw/elf_common.h
> >
> > diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
> b/BaseTools/Source/C/GenFw/Elf64Convert.c
> > old mode 100644
> > new mode 100755
> > index 024a2a0..205360c
> > --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> > +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> > @@ -75,7 +75,7 @@ CleanUp64 (
> >);
> >
> >  //
> > -// Rename ELF32 strucutres to common names to help when porting to ELF64.
> > +// Rename ELF32 structures to common names to help when porting to ELF64.
> >  //
> >  typedef Elf64_Shdr Elf_Shdr;
> >  typedef Elf64_Ehdr Elf_Ehdr;
> > @@ -233,7 +233,7 @@ IsTextShdr (
> >Elf_Shdr *Shdr
> >)
> >  {
> > -  return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == 
> > SHF_ALLOC);
> > +  return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | 
> > SHF_ALLOC)) ==
> (SHF_EXECINSTR | SHF_ALLOC));
> >  }
> >
> >  STATIC
> > @@ -256,7 +256,7 @@ IsDataShdr (
> >if (IsHiiRsrcShdr(Shdr)) {
> >  return FALSE;
> >}
> > -  return (BOOLEAN) (Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == 
> > (SHF_ALLOC |
> SHF_WRITE);
> > +  return (BOOLEAN) (Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | 
> > SHF_ALLOC)) ==
> (SHF_ALLOC | SHF_WRITE);
> >  }
> >
> >  STATIC
> > @@ -661,9 +661,9 @@ WriteSections64 (
> >
> >default:
> >  //
> > -//  Ignore for unkown section type.
> > +//  Ignore for unknown section type.
> >  //
> > -VerboseMsg ("%s unknown section type %x. We directly copy this 
> > section into
> Coff file", mInImageName, (unsigned)Shdr->sh_type);
> > +VerboseMsg ("%s unknown section type %x. We directly ignore this 
> > section and
> NOT copy into Coff file", mInImageName, (unsigned)Shdr->sh_type);
> >  break;
> >}
> >  }
> > @@ -763,24 +763,24 @@ WriteSections64 (
> >  // Absolute relocation.
> >  //
> >  VerboseMsg ("R_X86_64_64");
> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
> > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> > +VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
> > +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> >*(UINT64 *)Targ);
> >  *(UINT64 *)Targ = *(UINT64 *)Targ - SymShdr->sh_addr +
> mCoffSectionsOffset[Sym->st_shndx];
> >  VerboseMsg ("Relocation:  0x%016LX", *(UINT64*)Targ);
> >  break;
> >case R_X86_64_32:
> >  VerboseMsg ("R_X86_64_32");
> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> > +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> > +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> >*(UINT32 *)Targ);
> >  *(UINT32 *)Targ = (UINT32)((UINT64)(*(UINT32 *)Targ) - 
> > SymShdr->sh_addr
> + mCoffSectionsOffset[Sym->st_shndx]);
> >  VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
> >  break;
> >case R_X86_64_32S:
> >  VerboseMsg ("R_X86_64_32S");
> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> > +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> > +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_a

Re: [edk2] [PATCH 3/7] MdePkg: Enable new MS VA intrinsics for GNUC 64bits build

[Jordan Justen]

On 2016-06-28 08:18:57, Shi, Steven wrote:
> Both GCC and LLVM 3.8 64bits support new variable argument (VA)

Which versions of GCC? Maybe we should define MS_VA_LIST on the
command line for toolchains that can support this?

-Jordan

> 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 conversion
> as MS, so we don’t need change them.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Steven Shi 
> ---
>  MdePkg/Include/Base.h | 27 +--
>  1 file changed, 25 insertions(+), 2 deletions(-)
>  mode change 100644 => 100755 MdePkg/Include/Base.h
> 
> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> old mode 100644
> new mode 100755
> index cbd9e55..05fccf3
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -588,9 +588,32 @@ struct _LIST_ENTRY {
>  
>  #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
>  
> -#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
> +
> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && !defined (EFI32)
> +//
> +// 64bits build only. Use GCC built-in macros for variable argument lists.
> +//
> +///
> +/// Both GCC and LLVM 3.8 64bits 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)
> +
> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && defined (EFI32)
>  //
> -// Use GCC built-in macros for variable argument lists.
> +// 32bits build only. Use GCC built-in macros for variable argument lists.
>  //
>  
>  ///
> -- 
> 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] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Jordan Justen]

The subject prefix should be: "BaseTools/GenFw"

Should this patch move before 1/7?

-Jordan

On 2016-06-28 08:18:56, Shi, Steven wrote:
> Add support to convert missing Elf relocation types
> (R_X86_64_PLT32, R_X86_64_GOTPCREL, R_X86_64_REX_GOTPCRELX)
> to PeCoff, which are required by LTO image.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Steven Shi 
> ---
>  BaseTools/Source/C/GenFw/Elf64Convert.c | 98 
> -
>  BaseTools/Source/C/GenFw/elf_common.h   |  2 +-
>  2 files changed, 86 insertions(+), 14 deletions(-)
>  mode change 100644 => 100755 BaseTools/Source/C/GenFw/Elf64Convert.c
>  mode change 100644 => 100755 BaseTools/Source/C/GenFw/elf_common.h
> 
> diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
> b/BaseTools/Source/C/GenFw/Elf64Convert.c
> old mode 100644
> new mode 100755
> index 024a2a0..205360c
> --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> @@ -75,7 +75,7 @@ CleanUp64 (
>);
>  
>  //
> -// Rename ELF32 strucutres to common names to help when porting to ELF64.
> +// Rename ELF32 structures to common names to help when porting to ELF64.
>  //
>  typedef Elf64_Shdr Elf_Shdr;
>  typedef Elf64_Ehdr Elf_Ehdr;
> @@ -233,7 +233,7 @@ IsTextShdr (
>Elf_Shdr *Shdr
>)
>  {
> -  return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == SHF_ALLOC);
> +  return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | 
> SHF_ALLOC)) == (SHF_EXECINSTR | SHF_ALLOC));
>  }
>  
>  STATIC
> @@ -256,7 +256,7 @@ IsDataShdr (
>if (IsHiiRsrcShdr(Shdr)) {
>  return FALSE;
>}
> -  return (BOOLEAN) (Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == (SHF_ALLOC 
> | SHF_WRITE);
> +  return (BOOLEAN) (Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | 
> SHF_ALLOC)) == (SHF_ALLOC | SHF_WRITE);
>  }
>  
>  STATIC
> @@ -661,9 +661,9 @@ WriteSections64 (
>  
>default:
>  //
> -//  Ignore for unkown section type.
> +//  Ignore for unknown section type.
>  //
> -VerboseMsg ("%s unknown section type %x. We directly copy this 
> section into Coff file", mInImageName, (unsigned)Shdr->sh_type);
> +VerboseMsg ("%s unknown section type %x. We directly ignore this 
> section and NOT copy into Coff file", mInImageName, (unsigned)Shdr->sh_type);
>  break;
>}
>  }
> @@ -763,24 +763,24 @@ WriteSections64 (
>  // Absolute relocation.
>  //
>  VerboseMsg ("R_X86_64_64");
> -VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX", 
> -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)), 
> +VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
> +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>*(UINT64 *)Targ);
>  *(UINT64 *)Targ = *(UINT64 *)Targ - SymShdr->sh_addr + 
> mCoffSectionsOffset[Sym->st_shndx];
>  VerboseMsg ("Relocation:  0x%016LX", *(UINT64*)Targ);
>  break;
>case R_X86_64_32:
>  VerboseMsg ("R_X86_64_32");
> -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X", 
> -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)), 
> +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>*(UINT32 *)Targ);
>  *(UINT32 *)Targ = (UINT32)((UINT64)(*(UINT32 *)Targ) - 
> SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
>  VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
>  break;
>case R_X86_64_32S:
>  VerboseMsg ("R_X86_64_32S");
> -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X", 
> -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)), 
> +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>*(UINT32 *)Targ);
>  *(INT32 *)Targ = (INT32)((INT64)(*(INT32 *)Targ) - 
> SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
>  VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
> @@ -790,14 +790,34 @@ WriteSections64 (
>  // Relative relocation: Symbol - Ip + Addend
>  //
>  VerboseMsg ("R_X86_64_PC32");
> -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X", 
> -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)), 
> +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>*(UINT32 *)Targ);
>  *(UINT32 *)Targ = (UINT32) (*(UINT32 *)Targ
>+ (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr)
>- (SecOffset - SecShdr->sh_addr));
>  VerboseMsg ("Relocation:  0x%08X", *(UINT32 *)Targ);
>  break;
> +  case R_X86_64

Re: [edk2] [PATCH 4/7] QuarkPlatformPkg-AcpiPlatform: Downgrade the optimization to O1

[Kinney, Michael D]

Andrew,

I agree that we need to root cause and fix this code issue.

I also like idea of doing RELEASE/DEBUG/NOOPT builds to make sure code changes 
do not introduce build failures.

Mike

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, June 29, 2016 11:31 AM
> To: Shi, Steven 
> Cc: edk2-devel ; Gao, Liming ; 
> Kinney,
> Michael D ; Zimmer, Vincent 
> ;
> Doran, Mark ; Mudusuru, Giri P 
> 
> Subject: Re: [edk2] [PATCH 4/7] QuarkPlatformPkg-AcpiPlatform: Downgrade the
> optimization to O1
> 
> 
> > On Jun 28, 2016, at 8:18 AM, Shi, Steven  wrote:
> >
> > Quark AcpiPlatform module cannot link successfully by CLANG38
> > with Oz optimization level. Add a work around to downgrade the
> > optimization to O1.
> >
> 
> We should fix the code too. These bugs are usually structure assignments in 
> the scope
> of a function that should be global, static, or done via CopyMem.
> 
> I really think they should get fixed as I see a lot of Si code that fails to 
> link when
> you compile with optimizations disabled, -O0, with Xcode clang as the 
> compiler falls
> back to memset/memcpy and we were just getting lucky the optimizer removed it.
> 
> Actually it would be nice if packages also got built NOOPT to help catch 
> these classes
> of errors.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Steven Shi 
> > ---
> > QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf | 4 
> > 1 file changed, 4 insertions(+)
> > mode change 100644 => 100755 
> > QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> >
> > diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > old mode 100644
> > new mode 100755
> > index dcf2b4a..f1bcfa1
> > --- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > +++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > @@ -200,3 +200,7 @@
> >
> > [Depex]
> >   gEfiMpServiceProtocolGuid AND gEfiAcpiTableProtocolGuid
> > +
> > +[BuildOptions]
> > +  GCC:*_CLANG38_IA32_DLINK_FLAGS  = -O1
> > +  GCC:*_CLANGSCAN38_IA32_DLINK_FLAGS  = -O1
> > --
> > 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] [PATCH 1/7] BaseTools: Enable three new toolchains

[Jordan Justen]

This should be 3 separate commits. It should be obvious in the commit
subject line what toolchain is being added.

Can you post a public branch with your commits? Maybe on a personal
github fork of the edk2 repo.

On 2016-06-28 08:18:55, Shi, Steven wrote:
> Enable three new toolchains: CLANG38, CLANGSCAN38 and GCC53.
> (1)CLANG38 uses Clang3.8.0, enable LLVM Link Time Optimization (LTO)
> and code size optimization flag (-Oz) by default for aggressive code
> size improvement. CLANG38 X64 code is small code model + PIE.
> (2)CLANGSCAN38 is based on CLANG38 to seamlessly integrate Clang
> scan-build analyzer infrastructure into edk2 build infrastructure.

I'm not sure we should add a separate toolchain for this.

> (3)GCC53 use gcc 5.3, enable GCC Link Time Optimization (LTO) and
> code size optimization (–Os) for aggressive code size improvement.
> GCC53 X64 code is also small + PIE.

As of GCC 5.0, the minor releases have been bumped left. Essentially,
GCC51, GCC52, etc don't make sense, and GCC5 or GCC6 should be used
now.

https://gcc.gnu.org/releases.html

So, will this work with all versions of GCC 5.*? If not, I suggest we
consider starting this support at GCC6.

-Jordan

> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Steven Shi 
> ---
>  BaseTools/Conf/build_rule.template |  17 ++-
>  BaseTools/Conf/tools_def.template  | 267 
> +
>  2 files changed, 283 insertions(+), 1 deletion(-)
>  mode change 100644 => 100755 BaseTools/Conf/build_rule.template
>  mode change 100644 => 100755 BaseTools/Conf/tools_def.template
> 
> diff --git a/BaseTools/Conf/build_rule.template 
> b/BaseTools/Conf/build_rule.template
> old mode 100644
> new mode 100755
> index 91bcc18..7f21813
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -137,6 +137,9 @@
>  
>  "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
>  
> +
> +"$(SCAN)" $(SCAN_FLAGS) -o $(SCAN_DST) "$(CC)" $(CC_FLAGS) -o ${dst} 
> $(INC) ${src}
> +
>  [C-Code-File.COMMON.IPF]
>  
>  ?.c
> @@ -267,7 +270,10 @@
>  
>  
>  "$(SLINK)" -cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
> -
> +
> +
> +"$(SLINK)" cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
> +
>  
>  "$(SLINK)" $(SLINK_FLAGS) ${dst} --via $(OBJECT_FILES_LIST)
>  
> @@ -295,6 +301,10 @@
>  "$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
> @$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
>  "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
>  
> +
> +"$(DLINK)" -o ${dst} $(DLINK_FLAGS) 
> -Wl,--start-group,$(DLINK_SPATH),@$(STATIC_LIBRARY_FILES_LIST) 
> -Wl,--end-group $(DLINK2_FLAGS)
> +"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
> +
>  
>  "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via 
> $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
>  
> @@ -448,6 +458,11 @@
>  "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
>  "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
> $(GENFW_FLAGS)
>  
> +
> +"$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj 
> $(ASLCC_FLAGS) $(INC) ${src}
> +"$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> +"$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
> $(GENFW_FLAGS)
> +
>  
>  "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj  
> $(ASLCC_FLAGS) $(INC) ${src}
>  "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> old mode 100644
> new mode 100755
> index 2065fa3..d401031
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -366,12 +366,30 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
> Files/CodeSourcery/Sourcery G
>  # Required to build platforms or ACPI tables:
>  #   Intel(r) ACPI Compiler from
>  #   https://acpica.org/downloads
> +#   GCC53-Linux-  Requires:
> +# GCC 5.3 targeting x86_64-linux-gnu
> +#Optional:
> +# Required to build platforms or ACPI tables:
> +#   Intel(r) ACPI Compiler from
> +#   https://acpica.org/downloads
>  #   CLANG35 -Linux,Windows-  Requires:
>  # Clang v3.5 or later, and GNU binutils 
> targeting aarch64-linux-gnu or arm-linux-gnueabi
>  #Optional:
>  # Required to build platforms or ACPI tables:
>  #   Intel(r) ACPI C

Re: [edk2] iPXE invalidates the OVMF network device options

[Gerd Hoffmann]

  Hi,

> ... Hm, actually, I have one suspect. In your report, you said the
> boot option called "UEFI PXEv4" worked fine. "EFI Network" didn't, and
> it was higher up in the boot order.
> 
> I think "EFI Network" could be a left-over boot option (from the old
> IntelFrameworkModulePkg BDS) that doesn't work any longer.

Could very well be.  Those virtual machines exist for a while already.

> And, due to how the boot option ("bootorder" fw_cfg) matching works in
> OVMF, both "EFI Network" and "UEFI PXEv4" may have device paths
> associated with them that match the QEMU boot order specification.
> Since "EFI Network" is already in your varstore, at the top of the
> boot order, that one is tried. (I think "UEFI PXEv4" is even dropped
> by OVMF's filtering, it's just that when you enter the UI application
> in OVMF, a bunch of boot options are regenerated at the end of the
> list again).

Very plausible.  /me goes delete the old varstore.  Trying again ...

Yep, "EFI Network" is gone now.  "UEFI PXEv4" is first in the list.
Everything working fine.

> edk2 sometimes undergoes non-compatible changes where manual massaging
> of the varstore is required. Recently there was another example when
> even the UEFI spec changed incompatibily; see
> 
> https://github.com/tianocore/edk2/commit/d5aee61bfaaa
> https://github.com/tianocore/edk2/commit/1da761664949
> 
> I don't have a good automated solution for this kind of change, unfortunately.

Hmm.  How is this handled on physical hardware?

I suspect it'll be to not release that kind of firmware update in the
first place.  Or a paragraph in the release notes.

cheers,
  Gerd


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

Re: [edk2] [PATCH 0/9] Add FrameBufferBltLib and generic GOP driver to MdeModulePkg.

[Jordan Justen]

On 2016-06-29 06:24:31, Ruiyu Ni wrote:
> The patch serials refine the FrameBufferBltLib in OptionRomPkg and move it to
> MdeModulePkg. Based on the library, a generic GOP driver GraphicsOutputDxe
> is developed and added to MdeModulePkg.
> 
> Ruiyu Ni (9):
>   OptionRomPkg: Refine FrameBufferBltLib to use UINT8* instead of VOID*
>   OptionRomPkg: Add video move test case to BltLibSample application
>   OptionRomPkg/BltLib: Fix a bug in BltVideoToVideo operation
>   OptionRomPkg: Remove GopBltLib instance
>   OptionRomPkg: Refine BltLib to FrameBufferBltLib
>   MdeModulePkg: Move OptionRomPkg/FrameBufferBltLib to MdeModulePkg

When we last discussed this, the plan was to add the FrameBufferBltLib
interface, but leave BltLib as it is for now.

I recommend adding the library interface and implementations in
separate commits.

Can you make that change, and make a branch available with the
changes?

-Jordan

>   OvmfPkg: QemuVideoDxe uses MdeModulePkg/FrameBufferLib
>   MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo HOB GUID and structure
>   MdeModulePkg: Add GraphicsOutputDxe driver.
> 
>  MdeModulePkg/Include/Library/FrameBufferBltLib.h   |  90 +++
>  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 709 +++
>  .../FrameBufferBltLib/FrameBufferBltLib.inf|   5 +-
>  MdeModulePkg/MdeModulePkg.dec  |   4 +
>  MdeModulePkg/MdeModulePkg.dsc  |   3 +
>  .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
>  .../Console/GraphicsOutputDxe/GraphicsOutput.c | 732 
>  .../Console/GraphicsOutputDxe/GraphicsOutput.h |  59 ++
>  .../GraphicsOutputDxe/GraphicsOutputDxe.inf|  55 +-
>  MdePkg/Include/Guid/GraphicsInfoHob.h  |  17 +-
>  MdePkg/MdePkg.dec  |   1 +
>  .../Application/BltLibSample/BltLibSample.c| 145 ++--
>  .../Application/BltLibSample/BltLibSample.inf  |   5 +-
>  OptionRomPkg/Include/Library/BltLib.h  | 259 ---
>  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 750 
> -
>  OptionRomPkg/Library/GopBltLib/GopBltLib.c | 455 -
>  OptionRomPkg/Library/GopBltLib/GopBltLib.inf   |  37 -
>  OptionRomPkg/OptionRomPkg.dec  |  11 +-
>  OptionRomPkg/OptionRomPkg.dsc  |   7 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc |   6 +-
>  OvmfPkg/QemuVideoDxe/Gop.c |  38 +-
>  OvmfPkg/QemuVideoDxe/Qemu.h|   4 +-
>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |   5 +-
>  23 files changed, 1969 insertions(+), 1618 deletions(-)
>  create mode 100644 MdeModulePkg/Include/Library/FrameBufferBltLib.h
>  create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
>  rename {OptionRomPkg => 
> MdeModulePkg}/Library/FrameBufferBltLib/FrameBufferBltLib.inf (87%)
>  create mode 100644 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
>  create mode 100644 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
>  create mode 100644 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
>  copy OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf => 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf (53%)
>  delete mode 100644 OptionRomPkg/Include/Library/BltLib.h
>  delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
>  delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.c
>  delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.inf
> 
> -- 
> 2.8.3.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg/build.sh: update gcc detection

[Laszlo Ersek]

On 06/29/16 21:30, Olaf Hering wrote:
> Adjust the code to look forward instead of backwards.
> Existing gcc releases are known to work or break. Upcoming gcc releases
> are assumed to work like the last handled gcc version does.
> Doing it that way will reduce the burden to update the script for each
> upcoming gcc variant.
> 
> This fixes issue #99.

(I think Jordan prefers tags of the form

Fixes: https://github.com/tianocore/edk2/issues/99

because they auto-close the github issues.

This can be updated at commit time.)

> 
> Signed-off-by: Olaf Hering 
> ---
>  OvmfPkg/build.sh | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index eb5eb73..b40e561 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -83,6 +83,13 @@ case `uname` in
>Linux*)
>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>  case $gcc_version in
> +  4.[3210].*|3.*|2.*)
> +echo "gcc version $gcc_version is unsupported"
> +exit 1
> +;;
> +  4.4.*)
> +TARGET_TOOLS=GCC44
> +;;
>4.5.*)
>  TARGET_TOOLS=GCC45
>  ;;
> @@ -99,7 +106,8 @@ case `uname` in
>  TARGET_TOOLS=GCC49
>  ;;
>*)
> -TARGET_TOOLS=GCC44
> +# assume the latest, we cant keep up with gcc releases

"can't" -- can be fixed up at commit time

With those addressed (no need for a v2):

Reviewed-by: Laszlo Ersek 

I'll defer to Jordan on this, like I said in #99.

Thanks!
Laszlo

> +TARGET_TOOLS=GCC49
>  ;;
>  esac
>  esac
> 

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

Re: [edk2] [PATCH 1/7] BaseTools: Enable three new toolchains

[Andrew Fish]

> On Jun 28, 2016, at 8:18 AM, Shi, Steven  wrote:
> 
> Enable three new toolchains: CLANG38, CLANGSCAN38 and GCC53.
> (1)CLANG38 uses Clang3.8.0, enable LLVM Link Time Optimization (LTO)
> and code size optimization flag (-Oz) by default for aggressive code
> size improvement. CLANG38 X64 code is small code model + PIE.
> (2)CLANGSCAN38 is based on CLANG38 to seamlessly integrate Clang
> scan-build analyzer infrastructure into edk2 build infrastructure.
> (3)GCC53 use gcc 5.3, enable GCC Link Time Optimization (LTO) and
> code size optimization (–Os) for aggressive code size improvement.
> GCC53 X64 code is also small + PIE.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Steven Shi 
> ---
> BaseTools/Conf/build_rule.template |  17 ++-
> BaseTools/Conf/tools_def.template  | 267 +
> 2 files changed, 283 insertions(+), 1 deletion(-)
> mode change 100644 => 100755 BaseTools/Conf/build_rule.template
> mode change 100644 => 100755 BaseTools/Conf/tools_def.template
> 
> diff --git a/BaseTools/Conf/build_rule.template 
> b/BaseTools/Conf/build_rule.template
> old mode 100644
> new mode 100755
> index 91bcc18..7f21813
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -137,6 +137,9 @@
> 
> "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
> 
> +
> +"$(SCAN)" $(SCAN_FLAGS) -o $(SCAN_DST) "$(CC)" $(CC_FLAGS) -o ${dst} 
> $(INC) ${src}
> +
> [C-Code-File.COMMON.IPF]
> 
> ?.c
> @@ -267,7 +270,10 @@
> 
> 
> "$(SLINK)" -cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
> -
> +
> +
> +"$(SLINK)" cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
> +
> 
> "$(SLINK)" $(SLINK_FLAGS) ${dst} --via $(OBJECT_FILES_LIST)
> 
> @@ -295,6 +301,10 @@
> "$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
> @$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
> "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
> 
> +
> +"$(DLINK)" -o ${dst} $(DLINK_FLAGS) 
> -Wl,--start-group,$(DLINK_SPATH),@$(STATIC_LIBRARY_FILES_LIST) 
> -Wl,--end-group $(DLINK2_FLAGS)
> +"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
> +
> 
> "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via 
> $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
> 
> @@ -448,6 +458,11 @@
> "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
> $(GENFW_FLAGS)
> 
> +
> +"$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj 
> $(ASLCC_FLAGS) $(INC) ${src}
> +"$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> +"$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
> $(GENFW_FLAGS)
> +
> 
> "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj  
> $(ASLCC_FLAGS) $(INC) ${src}
> "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> old mode 100644
> new mode 100755
> index 2065fa3..d401031
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -366,12 +366,30 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
> Files/CodeSourcery/Sourcery G
> # Required to build platforms or ACPI tables:
> #   Intel(r) ACPI Compiler from
> #   https://acpica.org/downloads
> +#   GCC53-Linux-  Requires:
> +# GCC 5.3 targeting x86_64-linux-gnu
> +#Optional:
> +# Required to build platforms or ACPI tables:
> +#   Intel(r) ACPI Compiler from
> +#   https://acpica.org/downloads
> #   CLANG35 -Linux,Windows-  Requires:
> # Clang v3.5 or later, and GNU binutils targeting 
> aarch64-linux-gnu or arm-linux-gnueabi
> #Optional:
> # Required to build platforms or ACPI tables:
> #   Intel(r) ACPI Compiler from
> #   https://acpica.org/downloads
> +#   CLANG38  -Linux-  Requires:
> +# Clang v3.8 or later, LLVMgold plugin and GNU 
> binutils 2.26 targeting x86_64-linux-gnu
> +#Optional:
> +# Required to build platforms or ACPI tables:
> +#   Intel(r) ACPI Compiler from
> +#   https://acpica.org/downloads
> +#   CLANGSCAN38 -Linux-  Requires:
> +# Clang v3.8 or later, and GNU binutils 2.26 
> targeting x86_64-linux

Re: [edk2] [PATCH 4/7] QuarkPlatformPkg-AcpiPlatform: Downgrade the optimization to O1

[Andrew Fish]

> On Jun 28, 2016, at 8:18 AM, Shi, Steven  wrote:
> 
> Quark AcpiPlatform module cannot link successfully by CLANG38
> with Oz optimization level. Add a work around to downgrade the
> optimization to O1.
> 

We should fix the code too. These bugs are usually structure assignments in the 
scope of a function that should be global, static, or done via CopyMem. 

I really think they should get fixed as I see a lot of Si code that fails to 
link when you compile with optimizations disabled, -O0, with Xcode clang as the 
compiler falls back to memset/memcpy and we were just getting lucky the 
optimizer removed it. 

Actually it would be nice if packages also got built NOOPT to help catch these 
classes of errors. 

Thanks,

Andrew Fish

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Steven Shi 
> ---
> QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf | 4 
> 1 file changed, 4 insertions(+)
> mode change 100644 => 100755 
> QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> 
> diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf 
> b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> old mode 100644
> new mode 100755
> index dcf2b4a..f1bcfa1
> --- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> +++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> @@ -200,3 +200,7 @@
> 
> [Depex]
>   gEfiMpServiceProtocolGuid AND gEfiAcpiTableProtocolGuid
> +
> +[BuildOptions]
> +  GCC:*_CLANG38_IA32_DLINK_FLAGS  = -O1
> +  GCC:*_CLANGSCAN38_IA32_DLINK_FLAGS  = -O1
> -- 
> 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] [PATCH 0/9] Add FrameBufferBltLib and generic GOP driver to MdeModulePkg.

[Laszlo Ersek]

On 06/29/16 15:24, Ruiyu Ni wrote:
> The patch serials refine the FrameBufferBltLib in OptionRomPkg and move it to
> MdeModulePkg. Based on the library, a generic GOP driver GraphicsOutputDxe
> is developed and added to MdeModulePkg.
> 
> Ruiyu Ni (9):
>   OptionRomPkg: Refine FrameBufferBltLib to use UINT8* instead of VOID*
>   OptionRomPkg: Add video move test case to BltLibSample application
>   OptionRomPkg/BltLib: Fix a bug in BltVideoToVideo operation
>   OptionRomPkg: Remove GopBltLib instance
>   OptionRomPkg: Refine BltLib to FrameBufferBltLib
>   MdeModulePkg: Move OptionRomPkg/FrameBufferBltLib to MdeModulePkg
>   OvmfPkg: QemuVideoDxe uses MdeModulePkg/FrameBufferLib
>   MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo HOB GUID and structure
>   MdeModulePkg: Add GraphicsOutputDxe driver.

I don't have much of an opinion about (nor expertise in)
FrameBufferBltLib. I remember however that you guys (Jordan and Ray)
discussed it in-depth a few months (years? :)) ago -- is that right?

So, assuming the new library interface is acceptable to everyone, I'm
happy to review patch 7/9 (the OvmfPkg adaptation). But perhaps the
interface will be revised due to Jordan's feedback, for v2, so it might
not be best for me to rush reviewing 7/9.

Jordan, can you review patch 5/9 first, for the interface changes?

Hmmm... Actually, I do have some comments already.

(1) First, for patch #5: I think the "Configure" parameter of
FrameBufferBltConfigure should not have type VOID*. Instead, the
FRAMEBUFFER_CONFIGURE type name (not the actual definition of the type!)
should be exposed in a public header. This is called "incomplete type"
in C. It's also called "opaque struct" more commonly.

The point is that clients of the library will be able to use pointers to
FRAMEBUFFER_CONFIGURE, but they won't know the fields and the size of
FRAMEBUFFER_CONFIGURE. This is a very big improvement above VOID,
because for VOID*, the compiler can do no type-checking. For
FRAMEBUFFER_CONFIGURE*, it can.

An example can be seen in
"MdePkg/Include/Library/OrderedCollectionLib.h": the type is called
ORDERED_COLLECTION.

(2) Second, in patch #7 I don't think Configure and ConfigureSize are
good names for the new fields in QEMU_VIDEO_PRIVATE_DATA.
"BltLibConfiguration" sounds better to me.

(3) For patch #6, I think FrameBufferBltLib.inf should get a new FILE_GUID.

(4) Again for patch #7: only "OvmfPkgIa32X64.dsc" was modified. I think
the other two DSC files were not added with "git add" before commit?

(5) In patch #7: the way "Private->Configure" is allocated in
QemuVideoGraphicsOutputSetMode() is not correct. It is correct for the
very first call, but for every further call, it has potential to leak
memory. Namely, if RETURN_BUFFER_TOO_SMALL is returned, that doesn't
guarantee that Private->Configure is currently NULL -- maybe a buffer
exists there (from an earlier allocation), it's just too small. So
instead of AllocatePool(), the area should be reallocated.

Admittedly, this doesn't make a lot of sense if the config buffer has a
fixed (opaque) type, FRAMEBUFFER_CONFIGURE -- the client cannot know the
actual size of that struct, but whatever the size, it never changes.

So, ultimately, I think one of the following two should be done:

- either consolidate on a public, opaque (but fixed size)
FRAMEBUFFER_CONFIGURE configuration buffer type, and then preallocate it
once, *outside* of QemuVideoGraphicsOutputSetMode(),

- or shoot for maximum flexibility, where the config buffer size *can*
change from mode to mode. In this case stick with the (VOID*) indeed,
but then also call FreePool() -- conditionally -- before AllocatePool().

(6) As much as I dislike saying this, I'll say it: if we want to remain
bisection-clean, then the series should be reworked a bit. First, the
new library class and instance should be created independently, as a
customized copy of the current library. Then all clients should be
flipped over to the new library. Finally the old (now unused) library
(class and instance) should be removed.

As-is, this series breaks the OVMF build when checking out the tree at
patch #5 or patch #6, I think.

Furthermore, the patch that creates the customized copy of the library
should be formatted with "--find-copies-harder", so that the new code is
expressed in terms of copy commands + diffs, not as brand new code.
(OTOH, this is not strictly necessary if you push the series to github
-- we can then fetch it and pass "--find-copies-harder" locally.)

Thanks
Laszlo

>  MdeModulePkg/Include/Library/FrameBufferBltLib.h   |  90 +++
>  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 709 +++
>  .../FrameBufferBltLib/FrameBufferBltLib.inf|   5 +-
>  MdeModulePkg/MdeModulePkg.dec  |   4 +
>  MdeModulePkg/MdeModulePkg.dsc  |   3 +
>  .../Console/GraphicsOutputDxe/ComponentName.c  | 190 ++
>  .../Console/GraphicsOutputDxe/GraphicsOutput.c | 732 +++

Re: [edk2] [PATCH 5/7] QuarkSocPkg-MemoryInitPei: Enable compiler builtin and disable CLANG LTO

[Kinney, Michael D]

Andrew,

I agree.  I will work with Steven on this module to improve its compiler 
compatibility.

Mike

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, June 29, 2016 10:57 AM
> To: Shi, Steven 
> Cc: edk2-devel ; Gao, Liming ; 
> Kinney,
> Michael D ; Zimmer, Vincent 
> ;
> Doran, Mark ; Mudusuru, Giri P 
> 
> Subject: Re: [PATCH 5/7] QuarkSocPkg-MemoryInitPei: Enable compiler builtin 
> and disable
> CLANG LTO
> 
> 
> > On Jun 28, 2016, at 8:18 AM, Shi, Steven  wrote:
> >
> > The MRC use the memset() in the code and assume the compiler to offer
> > such builtin fuctions. Add work around to permit compiler add builtin
> > functions in this module. Also MRC mix some inline assembly,
> > e.g. asm("rdtsc":"=a"(tscL),"=d"(tscH)),in the C code, and CLANG38
> > could wrongly remove them if enable LTO with high optimization level.
> > Add work around to simply disable the LTO in this module.
> >
> 
> Steven,
> 
> If this code is in the edk2 it should follow the edk2 coding rules and we 
> should clean
> it up and not propagate the workarounds to new compilers. Not following the 
> rules in
> the 1st place is what made this code harder to port. Actually if you look at 
> the code
> it started off using VC++ compiler intrinsics and inline assembler syntax, 
> and then it
> had to add some hacky #ifdefs to compile with GCC. If the code just used 
> BaseLib and
> BaseMemoryLib it would not require compiler specific hacks.
> 
> Why not fix the code to NOT depend on compiler intrinsics and use ZeroMem()?
> /work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git grep 
> memcpy
> Pei/meminit_utils.h:94:void *memcpy(void *d, const void *s, size_t n);
> ~/work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git grep 
> memset
> Pei/MemoryInitPei.inf:79:  # /Oi option to use the intrinsic memset function 
> in source
> code.
> Pei/meminit.c::  memset((void *) (final_delay), 0x00, (size_t)
> sizeof(final_delay));
> Pei/meminit.c:1396:  memset((void *) (final_delay), 0x00, (size_t)
> sizeof(final_delay));
> Pei/meminit.c:1650:  memset((void *) (final_delay), 0x00, (size_t)
> sizeof(final_delay));
> Pei/meminit.c:1972:  memset((void *) (final_delay), 0x00, (size_t)
> sizeof(final_delay));
> Pei/meminit_utils.h:93:void *memset(void *d, int c, size_t n);
> 
> All the inline assembly code is duplicating BaseLib functionality so why not 
> fix it?
> ~/work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git grep -W  
> asm
> Pei/meminit.c:2240:static void asm_wbinvd(void)
> Pei/meminit.c-2241-{
> Pei/meminit.c-2242-#if defined (SIM) || defined (GCC)
> Pei/meminit.c:2243:  asm(
> Pei/meminit.c-2244-"wbinvd;"
> Pei/meminit.c-2245-  );
> Pei/meminit.c-2246-#else
> Pei/meminit.c:2247:  __asm wbinvd;
> Pei/meminit.c-2248-#endif
> Pei/meminit.c-2249-}
> Pei/meminit.c-2250-
> Pei/meminit.c-2251-// cache invalidate
> Pei/meminit.c:2252:static void asm_invd(void)
> Pei/meminit.c-2253-{
> Pei/meminit.c-2254-#if defined (SIM) || defined (GCC)
> Pei/meminit.c:2255:  asm(
> Pei/meminit.c-2256-  "invd;"
> Pei/meminit.c-2257-  );
> Pei/meminit.c-2258-#else
> Pei/meminit.c:2259:  __asm invd;
> Pei/meminit.c-2260-#endif
> Pei/meminit.c-2261-}
> Pei/meminit.c-2262-
> Pei/meminit.c-2263-
> Pei/meminit.c=2264=static void cpu_read(void)
> Pei/meminit.c-2265-{
> Pei/meminit.c-2266-  uint32_t adr, dat, limit;
> Pei/meminit.c-2267-
> Pei/meminit.c:2268:  asm_invd();
> Pei/meminit.c-2269-
> Pei/meminit.c-2270-  limit = 8 * 1024;
> Pei/meminit.c-2271-  for (adr = 0; adr < limit; adr += 4)
> Pei/meminit.c-2272-  {
> Pei/meminit.c-2273-dat = *(uint32_t*) adr;
> Pei/meminit.c-2274-if ((adr & 0x0F) == 0)
> Pei/meminit.c-2275-{
> Pei/meminit.c-2276-  DPF(D_INFO, "\n%x : ", adr);
> Pei/meminit.c-2277-}
> Pei/meminit.c-2278-DPF(D_INFO, "%x ", dat);
> Pei/meminit.c-2279-  }
> Pei/meminit.c-2280-  DPF(D_INFO, "\n");
> Pei/meminit.c-2281-
> Pei/meminit.c-2282-  DPF(D_INFO, "CPU read done\n");
> Pei/meminit.c-2283-}
> Pei/meminit.c-2284-
> Pei/meminit.c-2285-
> Pei/meminit.c=2286=static void cpu_write(void)
> Pei/meminit.c-2287-{
> Pei/meminit.c-2288-  uint32_t adr, limit;
> Pei/meminit.c-2289-
> Pei/meminit.c-2290-  limit = 8 * 1024;
> Pei/meminit.c-2291-  for (adr = 0; adr < limit; adr += 4)
> Pei/meminit.c-2292-  {
> Pei/meminit.c-2293-*(uint32_t*) adr = 0xDEAD + adr;
> Pei/meminit.c-2294-  }
> Pei/meminit.c-2295-
> Pei/meminit.c:2296:  asm_wbinvd();
> Pei/meminit.c-2297-
> Pei/meminit.c-2298-  DPF(D_INFO, "CPU write done\n");
> Pei/meminit.c-2299-}
> Pei/meminit.c-2300-
> Pei/meminit.c-2301-
> Pei/meminit.c=2302=static void cpu_memory_test(
> Pei/meminit.c-2303-MRCParams_t *mrc_params)
> Pei/meminit.c-2304-{
> Pei/meminit.c-2305-  uint32_t result = 0;
> Pei/meminit.c-2306-  uint32_t val, dat, adr, adr0, step, limit;
> Pei/meminit.c-2307-  uint64_t my_tsc;
> Pei/meminit.c-2308-
> Pei/meminit.c-2309-  ENTERFN();
> Pei/meminit.c-2310-
> P

Re: [edk2] [PATCH 5/7] QuarkSocPkg-MemoryInitPei: Enable compiler builtin and disable CLANG LTO

[Andrew Fish]

> On Jun 28, 2016, at 8:18 AM, Shi, Steven  wrote:
> 
> The MRC use the memset() in the code and assume the compiler to offer
> such builtin fuctions. Add work around to permit compiler add builtin
> functions in this module. Also MRC mix some inline assembly,
> e.g. asm("rdtsc":"=a"(tscL),"=d"(tscH)),in the C code, and CLANG38
> could wrongly remove them if enable LTO with high optimization level.
> Add work around to simply disable the LTO in this module.
> 

Steven,

If this code is in the edk2 it should follow the edk2 coding rules and we 
should clean it up and not propagate the workarounds to new compilers. Not 
following the rules in the 1st place is what made this code harder to port. 
Actually if you look at the code it started off using VC++ compiler intrinsics 
and inline assembler syntax, and then it had to add some hacky #ifdefs to 
compile with GCC. If the code just used BaseLib and BaseMemoryLib it would not 
require compiler specific hacks. 

Why not fix the code to NOT depend on compiler intrinsics and use ZeroMem()?
/work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git grep memcpy
Pei/meminit_utils.h:94:void *memcpy(void *d, const void *s, size_t n);
~/work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git grep memset
Pei/MemoryInitPei.inf:79:  # /Oi option to use the intrinsic memset function in 
source code.
Pei/meminit.c::  memset((void *) (final_delay), 0x00, (size_t) 
sizeof(final_delay));
Pei/meminit.c:1396:  memset((void *) (final_delay), 0x00, (size_t) 
sizeof(final_delay));
Pei/meminit.c:1650:  memset((void *) (final_delay), 0x00, (size_t) 
sizeof(final_delay));
Pei/meminit.c:1972:  memset((void *) (final_delay), 0x00, (size_t) 
sizeof(final_delay));
Pei/meminit_utils.h:93:void *memset(void *d, int c, size_t n);

All the inline assembly code is duplicating BaseLib functionality so why not 
fix it? 
~/work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git grep -W  
asm
Pei/meminit.c:2240:static void asm_wbinvd(void)
Pei/meminit.c-2241-{
Pei/meminit.c-2242-#if defined (SIM) || defined (GCC)
Pei/meminit.c:2243:  asm(
Pei/meminit.c-2244-"wbinvd;"
Pei/meminit.c-2245-  );
Pei/meminit.c-2246-#else
Pei/meminit.c:2247:  __asm wbinvd;
Pei/meminit.c-2248-#endif
Pei/meminit.c-2249-}
Pei/meminit.c-2250-
Pei/meminit.c-2251-// cache invalidate
Pei/meminit.c:2252:static void asm_invd(void)
Pei/meminit.c-2253-{
Pei/meminit.c-2254-#if defined (SIM) || defined (GCC)
Pei/meminit.c:2255:  asm(
Pei/meminit.c-2256-  "invd;"
Pei/meminit.c-2257-  );
Pei/meminit.c-2258-#else
Pei/meminit.c:2259:  __asm invd;
Pei/meminit.c-2260-#endif
Pei/meminit.c-2261-}
Pei/meminit.c-2262-
Pei/meminit.c-2263-
Pei/meminit.c=2264=static void cpu_read(void)
Pei/meminit.c-2265-{
Pei/meminit.c-2266-  uint32_t adr, dat, limit;
Pei/meminit.c-2267-
Pei/meminit.c:2268:  asm_invd();
Pei/meminit.c-2269-
Pei/meminit.c-2270-  limit = 8 * 1024;
Pei/meminit.c-2271-  for (adr = 0; adr < limit; adr += 4)
Pei/meminit.c-2272-  {
Pei/meminit.c-2273-dat = *(uint32_t*) adr;
Pei/meminit.c-2274-if ((adr & 0x0F) == 0)
Pei/meminit.c-2275-{
Pei/meminit.c-2276-  DPF(D_INFO, "\n%x : ", adr);
Pei/meminit.c-2277-}
Pei/meminit.c-2278-DPF(D_INFO, "%x ", dat);
Pei/meminit.c-2279-  }
Pei/meminit.c-2280-  DPF(D_INFO, "\n");
Pei/meminit.c-2281-
Pei/meminit.c-2282-  DPF(D_INFO, "CPU read done\n");
Pei/meminit.c-2283-}
Pei/meminit.c-2284-
Pei/meminit.c-2285-
Pei/meminit.c=2286=static void cpu_write(void)
Pei/meminit.c-2287-{
Pei/meminit.c-2288-  uint32_t adr, limit;
Pei/meminit.c-2289-
Pei/meminit.c-2290-  limit = 8 * 1024;
Pei/meminit.c-2291-  for (adr = 0; adr < limit; adr += 4)
Pei/meminit.c-2292-  {
Pei/meminit.c-2293-*(uint32_t*) adr = 0xDEAD + adr;
Pei/meminit.c-2294-  }
Pei/meminit.c-2295-
Pei/meminit.c:2296:  asm_wbinvd();
Pei/meminit.c-2297-
Pei/meminit.c-2298-  DPF(D_INFO, "CPU write done\n");
Pei/meminit.c-2299-}
Pei/meminit.c-2300-
Pei/meminit.c-2301-
Pei/meminit.c=2302=static void cpu_memory_test(
Pei/meminit.c-2303-MRCParams_t *mrc_params)
Pei/meminit.c-2304-{
Pei/meminit.c-2305-  uint32_t result = 0;
Pei/meminit.c-2306-  uint32_t val, dat, adr, adr0, step, limit;
Pei/meminit.c-2307-  uint64_t my_tsc;
Pei/meminit.c-2308-
Pei/meminit.c-2309-  ENTERFN();
Pei/meminit.c-2310-
Pei/meminit.c:2311:  asm_invd();
Pei/meminit.c-2312-
Pei/meminit.c-2313-  adr0 = 1 * 1024 * 1024;
Pei/meminit.c-2314-  limit = 256 * 1024 * 1024;
Pei/meminit.c-2315-
Pei/meminit.c-2316-  for (step = 0; step <= 4; step++)
Pei/meminit.c-2317-  {
Pei/meminit.c-2318-DPF(D_INFO, "Mem test step %d starting from %xh\n", 
step, adr0);
Pei/meminit.c-2319-
Pei/meminit.c-2320-my_tsc = read_tsc();
Pei/meminit.c-2321-for (adr = adr0; adr < limit; adr += sizeof(uint32_t))
Pei/meminit.c-2322-{
Pei/meminit.c-2323-  if (step == 0)  dat = adr;
Pei/meminit.c-2324-  else if (step == 1) dat = (1 << ((adr >> 2) & 0x1f));
Pei/meminit.c-2325-  else if (step == 2) dat = ~(1 << ((adr >> 

Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.

[Laszlo Ersek]

On 06/29/16 16:47, Bruce Cran wrote:
> On 6/27/2016 1:25 AM, Cinnamon Shia wrote:
>> Let data of DXE memory status code can be used by other modules.
>> 1. Save the address of DXE memory status code table to
>> DxeConfigurationTable.
>> 2. Save the address of SMM memory status code table to
>> SmmConfigurationTable.
>> 3. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public header file.
> 
> I'm getting an error building OVMF today, which appears related:
> 
> In file included from
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/SerialStatusCodeWorker.c:15:0:
> 
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h:63:3:
> error: conflicting types for ‘RUNTIME_MEMORY_STATUSCODE_HEADER’
>  } RUNTIME_MEMORY_STATUSCODE_HEADER;
>^~~~
> In file included from
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h:22:0,
> 
>  from
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/SerialStatusCodeWorker.c:15:
> 
> /home/bcran/workspace/edk2/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h:76:3:
> note: previous declaration of ‘RUNTIME_MEMORY_STATUSCODE_HEADER’ was here
>  } RUNTIME_MEMORY_STATUSCODE_HEADER;
>^~~~
> 

Yes, the file

IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h

includes

MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h

but also defines the RUNTIME_MEMORY_STATUSCODE_HEADER type, which has
now become redundant.

As far as I can see, it should be fixable by removing the
RUNTIME_MEMORY_STATUSCODE_HEADER typedef from
"IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h".

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

Re: [edk2] iPXE invalidates the OVMF network device options

[Laszlo Ersek]

On 06/29/16 16:30, Michael Brown wrote:
> On 29/06/16 02:52, Gary Lin wrote:
>> On Tue, Jun 28, 2016 at 01:43:31PM +0100, Michael Brown wrote:
>>> diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
>>> index 0ea970e..506fc88 100644
>>> --- a/src/interface/efi/efi_hii.c
>>> +++ b/src/interface/efi/efi_hii.c
>>> @@ -117,6 +117,7 @@ static void * efi_ifr_op ( struct efi_ifr_builder
>>> *ifr,
>>> unsigned int opcode,
>>>   ifr->ops_len = new_ops_len;
>>>
>>>   /* Fill in opcode header */
>>> +memset ( op, 0, len );
>>>   op->OpCode = opcode;
>>>   op->Length = len;
>>>
>>> Please let me know if this works.
>>>
>> This patch works quite well. Tried 10 times and got no crash. Without
>> the patch, my OVMF crashed at the first try. I would say it's fixed :)
> 
> Awesome.  Have pushed to iPXE master:
> 
>   http://git.ipxe.org/ipxe.git/commitdiff/c9f6a86

Thank you!

Gerd, I think you can go ahead with the bundling now (assuming you can
confirm my hunch about the "EFI Network" issue discussed elsewhere in
the thread).

Cheers
Laszlo

> Thanks for all the debugging!


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

Re: [edk2] [PATCH] MdeModulePkg VariableInfo: Fix GCC build failure

[Mudusuru, Giri P]

Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Star Zeng
> Sent: Wednesday, June 29, 2016 7:24 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [edk2] [PATCH] MdeModulePkg VariableInfo: Fix GCC build failure
> 
> GCC build failure: 'RealCommSize' may be used uninitialized
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Application/VariableInfo/VariableInfo.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdeModulePkg/Application/VariableInfo/VariableInfo.c
> b/MdeModulePkg/Application/VariableInfo/VariableInfo.c
> index df91c1451c19..a88b7f1ec42c 100644
> --- a/MdeModulePkg/Application/VariableInfo/VariableInfo.c
> +++ b/MdeModulePkg/Application/VariableInfo/VariableInfo.c
> @@ -104,6 +104,7 @@ PrintInfoFromSmm (
>}
> 
>CommBuffer = NULL;
> +  RealCommSize = 0;
>Status = EfiGetSystemConfigurationTable (
>   &gEdkiiPiSmmCommunicationRegionTableGuid,
>   (VOID **) &PiSmmCommunicationRegionTable
> --
> 2.7.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.

[Bruce Cran]

On 6/27/2016 1:25 AM, Cinnamon Shia wrote:

Let data of DXE memory status code can be used by other modules.
1. Save the address of DXE memory status code table to DxeConfigurationTable.
2. Save the address of SMM memory status code table to SmmConfigurationTable.
3. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public header file.


I'm getting an error building OVMF today, which appears related:

In file included from 
/home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/SerialStatusCodeWorker.c:15:0:
/home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h:63:3: 
error: conflicting types for ‘RUNTIME_MEMORY_STATUSCODE_HEADER’

 } RUNTIME_MEMORY_STATUSCODE_HEADER;
   ^~~~
In file included from 
/home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h:22:0,
 from 
/home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/SerialStatusCodeWorker.c:15:
/home/bcran/workspace/edk2/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h:76:3: 
note: previous declaration of ‘RUNTIME_MEMORY_STATUSCODE_HEADER’ was here

 } RUNTIME_MEMORY_STATUSCODE_HEADER;
   ^~~~

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

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Shi, Steven]

Yes. It should related to PIC/PIE code. I will correct my commit log later. 
Thank you let me know it.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, June 29, 2016 10:42 PM
> To: Shi, Steven 
> Cc: edk2-devel-01 ; Gao, Liming
> ; Kinney, Michael D ;
> af...@apple.com
> Subject: Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type
> for LTO build
> 
> On 29 June 2016 at 15:59, Shi, Steven  wrote:
> > Ok, will separate it. Thank you to let me know it.
> >
> 
> 
> BTW, your commit log suggests that these relocation types are somehow
> related to LTO, but I think they are more related to PIC/PIE code,
> right? So even if you disable LTO, you may encounter these relocation
> types when using the new toolchain definitions?
> 
> 
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Wednesday, June 29, 2016 9:30 PM
> >> To: Shi, Steven 
> >> Cc: edk2-devel-01 ; Gao, Liming
> >> ; Kinney, Michael D
> ;
> >> af...@apple.com
> >> Subject: Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation
> type
> >> for LTO build
> >>
> >> On 28 June 2016 at 17:18, Shi, Steven  wrote:
> >> > Add support to convert missing Elf relocation types
> >> > (R_X86_64_PLT32, R_X86_64_GOTPCREL, R_X86_64_REX_GOTPCRELX)
> >> > to PeCoff, which are required by LTO image.
> >> >
> >>
> >> Could you please put the changes that affect other architectures in a
> >> separate patch?
> >> The commit log suggests that only X64 is affected, but the patch
> >> touches other things as well.
> >>
> >> > Contributed-under: TianoCore Contribution Agreement 1.0
> >> > Signed-off-by: Steven Shi 
> >> > ---
> >> >  BaseTools/Source/C/GenFw/Elf64Convert.c | 98
> >> -
> >> >  BaseTools/Source/C/GenFw/elf_common.h   |  2 +-
> >> >  2 files changed, 86 insertions(+), 14 deletions(-)
> >> >  mode change 100644 => 100755
> >> BaseTools/Source/C/GenFw/Elf64Convert.c
> >> >  mode change 100644 => 100755
> >> BaseTools/Source/C/GenFw/elf_common.h
> >> >
> >> > diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
> >> b/BaseTools/Source/C/GenFw/Elf64Convert.c
> >> > old mode 100644
> >> > new mode 100755
> >> > index 024a2a0..205360c
> >> > --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> >> > +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> >> > @@ -75,7 +75,7 @@ CleanUp64 (
> >> >);
> >> >
> >> >  //
> >> > -// Rename ELF32 strucutres to common names to help when porting to
> >> ELF64.
> >> > +// Rename ELF32 structures to common names to help when porting to
> >> ELF64.
> >> >  //
> >> >  typedef Elf64_Shdr Elf_Shdr;
> >> >  typedef Elf64_Ehdr Elf_Ehdr;
> >> > @@ -233,7 +233,7 @@ IsTextShdr (
> >> >Elf_Shdr *Shdr
> >> >)
> >> >  {
> >> > -  return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) ==
> >> SHF_ALLOC);
> >> > +  return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE |
> >> SHF_ALLOC)) == (SHF_EXECINSTR | SHF_ALLOC));
> >> >  }
> >> >
> >> >  STATIC
> >> > @@ -256,7 +256,7 @@ IsDataShdr (
> >> >if (IsHiiRsrcShdr(Shdr)) {
> >> >  return FALSE;
> >> >}
> >> > -  return (BOOLEAN) (Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) ==
> >> (SHF_ALLOC | SHF_WRITE);
> >> > +  return (BOOLEAN) (Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE |
> >> SHF_ALLOC)) == (SHF_ALLOC | SHF_WRITE);
> >> >  }
> >> >
> >> >  STATIC
> >> > @@ -661,9 +661,9 @@ WriteSections64 (
> >> >
> >> >default:
> >> >  //
> >> > -//  Ignore for unkown section type.
> >> > +//  Ignore for unknown section type.
> >> >  //
> >> > -VerboseMsg ("%s unknown section type %x. We directly copy this
> >> section into Coff file", mInImageName, (unsigned)Shdr->sh_type);
> >> > +VerboseMsg ("%s unknown section type %x. We directly ignore
> this
> >> section and NOT copy into Coff file", mInImageName, (unsigned)Shdr-
> >> >sh_type);
> >> >  break;
> >> >}
> >> >  }
> >> > @@ -763,24 +763,24 @@ WriteSections64 (
> >> >  // Absolute relocation.
> >> >  //
> >> >  VerboseMsg ("R_X86_64_64");
> >> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
> >> > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> >> > +VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
> >> > +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> >> >*(UINT64 *)Targ);
> >> >  *(UINT64 *)Targ = *(UINT64 *)Targ - SymShdr->sh_addr +
> >> mCoffSectionsOffset[Sym->st_shndx];
> >> >  VerboseMsg ("Relocation:  0x%016LX", *(UINT64*)Targ);
> >> >  break;
> >> >case R_X86_64_32:
> >> >  VerboseMsg ("R_X86_64_32");
> >> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> >> > -  (UINT32)(SecOffset + (Rel->r_off

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Ard Biesheuvel]

On 29 June 2016 at 15:59, Shi, Steven  wrote:
> Ok, will separate it. Thank you to let me know it.
>


BTW, your commit log suggests that these relocation types are somehow
related to LTO, but I think they are more related to PIC/PIE code,
right? So even if you disable LTO, you may encounter these relocation
types when using the new toolchain definitions?


>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Wednesday, June 29, 2016 9:30 PM
>> To: Shi, Steven 
>> Cc: edk2-devel-01 ; Gao, Liming
>> ; Kinney, Michael D ;
>> af...@apple.com
>> Subject: Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type
>> for LTO build
>>
>> On 28 June 2016 at 17:18, Shi, Steven  wrote:
>> > Add support to convert missing Elf relocation types
>> > (R_X86_64_PLT32, R_X86_64_GOTPCREL, R_X86_64_REX_GOTPCRELX)
>> > to PeCoff, which are required by LTO image.
>> >
>>
>> Could you please put the changes that affect other architectures in a
>> separate patch?
>> The commit log suggests that only X64 is affected, but the patch
>> touches other things as well.
>>
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signed-off-by: Steven Shi 
>> > ---
>> >  BaseTools/Source/C/GenFw/Elf64Convert.c | 98
>> -
>> >  BaseTools/Source/C/GenFw/elf_common.h   |  2 +-
>> >  2 files changed, 86 insertions(+), 14 deletions(-)
>> >  mode change 100644 => 100755
>> BaseTools/Source/C/GenFw/Elf64Convert.c
>> >  mode change 100644 => 100755
>> BaseTools/Source/C/GenFw/elf_common.h
>> >
>> > diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
>> b/BaseTools/Source/C/GenFw/Elf64Convert.c
>> > old mode 100644
>> > new mode 100755
>> > index 024a2a0..205360c
>> > --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
>> > +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
>> > @@ -75,7 +75,7 @@ CleanUp64 (
>> >);
>> >
>> >  //
>> > -// Rename ELF32 strucutres to common names to help when porting to
>> ELF64.
>> > +// Rename ELF32 structures to common names to help when porting to
>> ELF64.
>> >  //
>> >  typedef Elf64_Shdr Elf_Shdr;
>> >  typedef Elf64_Ehdr Elf_Ehdr;
>> > @@ -233,7 +233,7 @@ IsTextShdr (
>> >Elf_Shdr *Shdr
>> >)
>> >  {
>> > -  return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) ==
>> SHF_ALLOC);
>> > +  return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE |
>> SHF_ALLOC)) == (SHF_EXECINSTR | SHF_ALLOC));
>> >  }
>> >
>> >  STATIC
>> > @@ -256,7 +256,7 @@ IsDataShdr (
>> >if (IsHiiRsrcShdr(Shdr)) {
>> >  return FALSE;
>> >}
>> > -  return (BOOLEAN) (Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) ==
>> (SHF_ALLOC | SHF_WRITE);
>> > +  return (BOOLEAN) (Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE |
>> SHF_ALLOC)) == (SHF_ALLOC | SHF_WRITE);
>> >  }
>> >
>> >  STATIC
>> > @@ -661,9 +661,9 @@ WriteSections64 (
>> >
>> >default:
>> >  //
>> > -//  Ignore for unkown section type.
>> > +//  Ignore for unknown section type.
>> >  //
>> > -VerboseMsg ("%s unknown section type %x. We directly copy this
>> section into Coff file", mInImageName, (unsigned)Shdr->sh_type);
>> > +VerboseMsg ("%s unknown section type %x. We directly ignore this
>> section and NOT copy into Coff file", mInImageName, (unsigned)Shdr-
>> >sh_type);
>> >  break;
>> >}
>> >  }
>> > @@ -763,24 +763,24 @@ WriteSections64 (
>> >  // Absolute relocation.
>> >  //
>> >  VerboseMsg ("R_X86_64_64");
>> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
>> > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>> > +VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
>> > +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>> >*(UINT64 *)Targ);
>> >  *(UINT64 *)Targ = *(UINT64 *)Targ - SymShdr->sh_addr +
>> mCoffSectionsOffset[Sym->st_shndx];
>> >  VerboseMsg ("Relocation:  0x%016LX", *(UINT64*)Targ);
>> >  break;
>> >case R_X86_64_32:
>> >  VerboseMsg ("R_X86_64_32");
>> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
>> > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>> > +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
>> > +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>> >*(UINT32 *)Targ);
>> >  *(UINT32 *)Targ = (UINT32)((UINT64)(*(UINT32 *)Targ) - 
>> > SymShdr-
>> >sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
>> >  VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
>> >  break;
>> >case R_X86_64_32S:
>> >  VerboseMsg ("R_X86_64_32S");
>> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
>> > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>> > +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
>> > +

Re: [edk2] iPXE invalidates the OVMF network device options

[Michael Brown]

On 29/06/16 02:52, Gary Lin wrote:

On Tue, Jun 28, 2016 at 01:43:31PM +0100, Michael Brown wrote:

diff --git a/src/interface/efi/efi_hii.c b/src/interface/efi/efi_hii.c
index 0ea970e..506fc88 100644
--- a/src/interface/efi/efi_hii.c
+++ b/src/interface/efi/efi_hii.c
@@ -117,6 +117,7 @@ static void * efi_ifr_op ( struct efi_ifr_builder *ifr,
unsigned int opcode,
ifr->ops_len = new_ops_len;

/* Fill in opcode header */
+   memset ( op, 0, len );
op->OpCode = opcode;
op->Length = len;

Please let me know if this works.


This patch works quite well. Tried 10 times and got no crash. Without
the patch, my OVMF crashed at the first try. I would say it's fixed :)


Awesome.  Have pushed to iPXE master:

  http://git.ipxe.org/ipxe.git/commitdiff/c9f6a86

Thanks for all the debugging!

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

[edk2] [PATCH] MdeModulePkg VariableInfo: Fix GCC build failure

[Star Zeng]

GCC build failure: 'RealCommSize' may be used uninitialized

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Application/VariableInfo/VariableInfo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Application/VariableInfo/VariableInfo.c 
b/MdeModulePkg/Application/VariableInfo/VariableInfo.c
index df91c1451c19..a88b7f1ec42c 100644
--- a/MdeModulePkg/Application/VariableInfo/VariableInfo.c
+++ b/MdeModulePkg/Application/VariableInfo/VariableInfo.c
@@ -104,6 +104,7 @@ PrintInfoFromSmm (
   }
 
   CommBuffer = NULL;
+  RealCommSize = 0;
   Status = EfiGetSystemConfigurationTable (
  &gEdkiiPiSmmCommunicationRegionTableGuid,
  (VOID **) &PiSmmCommunicationRegionTable
-- 
2.7.0.windows.1

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

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Shi, Steven]

Ok, will separate it. Thank you to let me know it.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, June 29, 2016 9:30 PM
> To: Shi, Steven 
> Cc: edk2-devel-01 ; Gao, Liming
> ; Kinney, Michael D ;
> af...@apple.com
> Subject: Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type
> for LTO build
> 
> On 28 June 2016 at 17:18, Shi, Steven  wrote:
> > Add support to convert missing Elf relocation types
> > (R_X86_64_PLT32, R_X86_64_GOTPCREL, R_X86_64_REX_GOTPCRELX)
> > to PeCoff, which are required by LTO image.
> >
> 
> Could you please put the changes that affect other architectures in a
> separate patch?
> The commit log suggests that only X64 is affected, but the patch
> touches other things as well.
> 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Steven Shi 
> > ---
> >  BaseTools/Source/C/GenFw/Elf64Convert.c | 98
> -
> >  BaseTools/Source/C/GenFw/elf_common.h   |  2 +-
> >  2 files changed, 86 insertions(+), 14 deletions(-)
> >  mode change 100644 => 100755
> BaseTools/Source/C/GenFw/Elf64Convert.c
> >  mode change 100644 => 100755
> BaseTools/Source/C/GenFw/elf_common.h
> >
> > diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
> b/BaseTools/Source/C/GenFw/Elf64Convert.c
> > old mode 100644
> > new mode 100755
> > index 024a2a0..205360c
> > --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> > +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> > @@ -75,7 +75,7 @@ CleanUp64 (
> >);
> >
> >  //
> > -// Rename ELF32 strucutres to common names to help when porting to
> ELF64.
> > +// Rename ELF32 structures to common names to help when porting to
> ELF64.
> >  //
> >  typedef Elf64_Shdr Elf_Shdr;
> >  typedef Elf64_Ehdr Elf_Ehdr;
> > @@ -233,7 +233,7 @@ IsTextShdr (
> >Elf_Shdr *Shdr
> >)
> >  {
> > -  return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) ==
> SHF_ALLOC);
> > +  return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE |
> SHF_ALLOC)) == (SHF_EXECINSTR | SHF_ALLOC));
> >  }
> >
> >  STATIC
> > @@ -256,7 +256,7 @@ IsDataShdr (
> >if (IsHiiRsrcShdr(Shdr)) {
> >  return FALSE;
> >}
> > -  return (BOOLEAN) (Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) ==
> (SHF_ALLOC | SHF_WRITE);
> > +  return (BOOLEAN) (Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE |
> SHF_ALLOC)) == (SHF_ALLOC | SHF_WRITE);
> >  }
> >
> >  STATIC
> > @@ -661,9 +661,9 @@ WriteSections64 (
> >
> >default:
> >  //
> > -//  Ignore for unkown section type.
> > +//  Ignore for unknown section type.
> >  //
> > -VerboseMsg ("%s unknown section type %x. We directly copy this
> section into Coff file", mInImageName, (unsigned)Shdr->sh_type);
> > +VerboseMsg ("%s unknown section type %x. We directly ignore this
> section and NOT copy into Coff file", mInImageName, (unsigned)Shdr-
> >sh_type);
> >  break;
> >}
> >  }
> > @@ -763,24 +763,24 @@ WriteSections64 (
> >  // Absolute relocation.
> >  //
> >  VerboseMsg ("R_X86_64_64");
> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
> > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> > +VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
> > +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> >*(UINT64 *)Targ);
> >  *(UINT64 *)Targ = *(UINT64 *)Targ - SymShdr->sh_addr +
> mCoffSectionsOffset[Sym->st_shndx];
> >  VerboseMsg ("Relocation:  0x%016LX", *(UINT64*)Targ);
> >  break;
> >case R_X86_64_32:
> >  VerboseMsg ("R_X86_64_32");
> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> > +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> > +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> >*(UINT32 *)Targ);
> >  *(UINT32 *)Targ = (UINT32)((UINT64)(*(UINT32 *)Targ) - SymShdr-
> >sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
> >  VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
> >  break;
> >case R_X86_64_32S:
> >  VerboseMsg ("R_X86_64_32S");
> > -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> > -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> > +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> > +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> >*(UINT32 *)Targ);
> >  *(INT32 *)Targ = (INT32)((INT64)(*(INT32 *)Targ) - SymShdr-
> >sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
> >  VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
> > @@ -790,14 +790,34 @@ WriteSections64 (
> > 

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

[Yao, Jiewen]

Thanks Laszlo.

You have sharp eyes to catch the minus 1 issue. :)

Thank you
Yao Jiewen

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, June 29, 2016 9:47 PM
To: Yao, Jiewen ; edk2-de...@ml01.01.org
Cc: Kinney, Michael D ; Fan, Jeff 

Subject: Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with 
MAX_ADDRESS check.

On 06/29/16 15:28, Yao, Jiewen wrote:
> I forget to mention:
>
> I agree with you on #2 -
> (2) The comparison is not appropriate here (after the patch); it is toostrict.
>
> BASE_4GB is an exclusive limit, hence the pre-patch status is good. But
> MAX_ADDRESS is an inclusive limit, so the condition should be
>
>   CpuStart + PhysicalSize - 1 <= MAX_ADDRESS
>
> Because CpuStart and PhysicalSize are UINT64, it may cause problem when
> the source is CpuStart+PhysicalSize==0x1, theoretically.
>
> So I think we should update DxeCore and PeiCore as well - to use
> Start+Size - 1 <= MAX_ADDRESS.

Sorry, I missed this second email of yours a minute ago. It answers my
question.

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

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

[Laszlo Ersek]

On 06/29/16 15:28, Yao, Jiewen wrote:
> I forget to mention:
> 
> I agree with you on #2 -
> (2) The comparison is not appropriate here (after the patch); it is toostrict.
> 
> BASE_4GB is an exclusive limit, hence the pre-patch status is good. But
> MAX_ADDRESS is an inclusive limit, so the condition should be
> 
>   CpuStart + PhysicalSize - 1 <= MAX_ADDRESS
> 
> Because CpuStart and PhysicalSize are UINT64, it may cause problem when
> the source is CpuStart+PhysicalSize==0x1, theoretically.
> 
> So I think we should update DxeCore and PeiCore as well – to use
> Start+Size – 1 <= MAX_ADDRESS.

Sorry, I missed this second email of yours a minute ago. It answers my
question.

Thanks!
Laszlo

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

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

[Laszlo Ersek]

On 06/29/16 15:02, Yao, Jiewen wrote:
> HI Laszlo
> 
> I appreciate your careful review.
> 
> I would like to clarify why we did not consider adding check for integer
> overflow.
> 
> The EDKII security model is that:
> 
> 1)  We trust any internal data communication before EndOfDxe. We
> have to, because the SMM core has to trust the component runs before
> SMM, and construct SMM.
> 
> 2)  We do not trust any external data communication after EndOfDxe.
> We should not, external data might be from an untrusted source. That is
> why we need lots of check in PE/COFF library, SMM communication buffer,
> UEFI authenticated variable, etc.

Ah, thanks. This makes a lot of sense. I'll try to remember this.

It's just that I'm so much aware of integer overflows that I routinely
formulate all my arithmetics and comparisons with them in mind,
regardless of the origin of the data :)

> Based upon above assumption, SmramRanges is from a trusted source. There
> is **no need** to add security check, we just need add function check.

Understood.

[snip]

> Go back to your suggestion. I have no problem to adopt you suggestion on
> using below format. It is not harmful.
> 
>   if (PhysicalSize <= MAX_ADDRESS &&
> CpuStart - 1 <= MAX_ADDRESS - PhysicalSize) {
> 
>  
> 
> But one thing I have to mention is that: If we do not trust CpuStart and
> PhysicalSize, we will have big problem, because CPU driver need use
> these data to set SMRR, which is the basic of SMM security.
> 
> We have assume CpuStart and PhysicalSize is set correctly.

In that case, I think the awkward rearrangement is not necessary, and
should be avoided for clarity's sake.

However, the "minus one" does remain necessary, because the (pre-patch)
4GB limit is an exclusive one, while the (post-patch) MAX_ADDRESS limit
is an inclusive one. So my point (2) remains valid, in my opinion:

  CpuStart + PhysicalSize - 1 <= MAX_ADDRESS

Do you agree?

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

Re: [edk2] iPXE invalidates the OVMF network device options

[Laszlo Ersek]

On 06/29/16 14:25, Gerd Hoffmann wrote:
>   Hi,
> 
>>> bootindex not working is still there, with both old and new ipxe rom
>>> builds.
>>
>> Hrmph. That is strange. Can you please give me a bit more info?
>>
>> I'm asking because I tested the following configuration last night:
>> - I350-T2V2 virtual function assigned to the Q35 guest
>> - assigned device decorated with bootindex=1 (through libvirt domain
>>   XML)
>> - SNP driver provided by the UEFI + CONFIG=qemu build of iPXE's "igbvf"
>>   driver (combined oprom)
>> - used iPXE master at commit 04186319181298083ef28695a8309028b26fe83c
>> - OVMF built from fresh edk2 master also
>>
>> A small QEMU cmdline reproducer would be appreciated.
> 
> Attached is my libvirt config.
> 
> ovmf is latest package from kraxel.org (which is a few days old due to
> the gcc6 update build failures).

(Fixes for those are on edk2-devel, waiting for reviews. But, I guess I should 
install F24 / gcc-6 in a guest and see for myself as well...)

> /home/kraxel/projects/qemu is a qemu checkout.  Doesn't matter whenever
> I use master (old ipxe) or updated ipxe branch[1], issue is present in
> both cases.

So, I virsh-defined your domain XML, with the following (minimal) modification:

> --- efi-pxe-el7-e1000-ipxe.xml2016-06-29 14:45:24.168333074 +0200
> +++ modified.xml  2016-06-29 15:11:52.438706662 +0200
> @@ -1,4 +1,4 @@
> -
> +
>efi-pxe-el7-e1000-ipxe
>40f3cda2-ab55-4a3e-8331-c2d74896b77f
>1048576
> @@ -27,9 +27,10 @@
>  
>  
>
> -  
> +  
>
>
> +  
> function='0x0'/>
>  
>  
> @@ -49,9 +50,5 @@
>  
>  
>
> -  
> -
> - value='device.net0.romfile=/home/kraxel/projects/qemu/pc-bios/efi-e1000.rom'/>
> -  
>  
>  

As you can see, the only real change is the network being flipped from 
"efi-x64" to "default".

The ROM BAR file for e1000 is specified differently (libvirt has direct support 
for this, no need for ). The "efi-e1000.rom" binary corresponds to 
the one in the QEMU source tree, from current master, dating back to commit 
f4798320144245da66128edb840bd940fd287d28.

I tested this setup and PXE boot works perfectly fine for me. OVMF loads shim 
loads grub2 loads kernel + initrd.

Some more versions, if they matter:
- qemu: qemu-kvm-rhev-2.6.0-10.el7.x86_64
- OVMF: edk2.git-ovmf-x64-0-20160622.b1914.g9252d67.noarch
- libvirt: libvirt-daemon-1.2.17-13.el7_2.5.x86_64
- host kernel: 3.10.0-446.el7.x86_64

Here's the libvirt XML for my "default" network:

> 
>   default
>   4ae8659d-38be-4f65-93b2-fd2758bfdc61
>   
> 
>   
> 
>   
>   
>   
>   
> 
>   nfsserver
> 
>   
>   
> 
> 
>   
>   
> 
>   
> 

... Hm, actually, I have one suspect. In your report, you said the boot option 
called "UEFI PXEv4" worked fine. "EFI Network" didn't, and it was higher up in 
the boot order.

I think "EFI Network" could be a left-over boot option (from the old 
IntelFrameworkModulePkg BDS) that doesn't work any longer. And, due to how the 
boot option ("bootorder" fw_cfg) matching works in OVMF, both "EFI Network" and 
"UEFI PXEv4" may have device paths associated with them that match the QEMU 
boot order specification. Since "EFI Network" is already in your varstore, at 
the top of the boot order, that one is tried. (I think "UEFI PXEv4" is even 
dropped by OVMF's filtering, it's just that when you enter the UI application 
in OVMF, a bunch of boot options are regenerated at the end of the list again).

What happens if you delete "EFI Network" manually, and retry?

  Boot Maintenance Manager
Boot Options
  Delete Boot Option
- mark "EFI Network" with space
Commit Changes and Exit
  press ESC a few times, then select Reset

You didn't attach your varstore file, so for my test, I first removed the 
actual pathname of the varstore in the domain XML (I kept the template). This 
way libvirt creates a fresh varstore at first guest startup. Which is why I 
didn't have your "EFI Network" leftover option. (The pathname is filled in as 
well at first startup, which is why that part of the domain XML doesn't differ 
above.)

edk2 sometimes undergoes non-compatible changes where manual massaging of the 
varstore is required. Recently there was another example when even the UEFI 
spec changed incompatibily; see

https://github.com/tianocore/edk2/commit/d5aee61bfaaa
https://github.com/tianocore/edk2/commit/1da761664949

I don't have a good automated solution for this kind of change, unfortunately.

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

[edk2] [PATCH 8/9] MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo HOB GUID and structure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Liming Gao 
---
 MdePkg/Include/Guid/GraphicsInfoHob.h | 17 -
 MdePkg/MdePkg.dec |  1 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Guid/GraphicsInfoHob.h 
b/MdePkg/Include/Guid/GraphicsInfoHob.h
index 3bcead0..b807213 100644
--- a/MdePkg/Include/Guid/GraphicsInfoHob.h
+++ b/MdePkg/Include/Guid/GraphicsInfoHob.h
@@ -1,7 +1,7 @@
 /** @file
   Hob guid for Information about the graphics mode.
 
-  Copyright (c) 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 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
@@ -25,12 +25,27 @@
 0x39f62cce, 0x6825, 0x4669, { 0xbb, 0x56, 0x54, 0x1a, 0xba, 0x75, 0x3a, 
0x07 } \
   }
 
+#define EFI_PEI_GRAPHICS_DEVICE_INFO_HOB_GUID \
+  { \
+0xe5cb2ac9, 0xd35d, 0x4430, { 0x93, 0x6e, 0x1d, 0xe3, 0x32, 0x47, 0x8d, 
0xe7 } \
+  }
+
 typedef struct {
   EFI_PHYSICAL_ADDRESS  FrameBufferBase;
   UINT32FrameBufferSize;
   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  GraphicsMode;
 } EFI_PEI_GRAPHICS_INFO_HOB;
 
+typedef struct {
+  UINT16VendorId;   ///< Ignore if the 
value is 0x.
+  UINT16DeviceId;   ///< Ignore if the 
value is 0x.
+  UINT16SubsystemVendorId;  ///< Ignore if the 
value is 0x.
+  UINT16SubsystemId;///< Ignore if the 
value is 0x.
+  UINT8 RevisionId; ///< Ignore if the 
value is 0xFF.
+  UINT8 BarIndex;   ///< Ignore if the 
value is 0xFF.
+} EFI_PEI_GRAPHICS_DEVICE_INFO_HOB;
+
 extern EFI_GUID gEfiGraphicsInfoHobGuid;
+extern EFI_GUID gEfiGraphicsDeviceInfoHobGuid;
 
 #endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 458d568..46573a1 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -727,6 +727,7 @@ [Guids]
   #
   ## Include/Guid/GraphicsInfoHob.h
   gEfiGraphicsInfoHobGuid   = { 0x39f62cce, 0x6825, 0x4669, { 0xbb, 
0x56, 0x54, 0x1a, 0xba, 0x75, 0x3a, 0x07 }}
+  gEfiGraphicsDeviceInfoHobGuid = { 0xe5cb2ac9, 0xd35d, 0x4430, { 0x93, 
0x6e, 0x1d, 0xe3, 0x32, 0x47, 0x8d, 0xe7 }}
 
   ## Guid for EFI_DISK_INFO_PROTOCOL.Interface to specify UFS interface.
   ## Include/Protocol/DiskInfo.h
-- 
2.8.3.windows.1

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

Re: [edk2] [PATCH 4/6] ShellPkg: don't call functions with side effects in ASSERT_EFI_ERROR()

[Ni, Ruiyu]

Laszlo,
Thank you for the sharing. Your patches really help to improve the EDKII code 
quality.

Regards,
Ray

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Wednesday, June 29, 2016 7:50 PM
>To: Ni, Ruiyu ; edk2-devel-01 
>Cc: Carsey, Jaben ; Qiu, Shumin 
>Subject: Re: [edk2] [PATCH 4/6] ShellPkg: don't call functions with side 
>effects in ASSERT_EFI_ERROR()
>
>On 06/29/16 08:36, Ni, Ruiyu wrote:
>> Laszlo,
>> Thanks for fixing such a big bug.
>>
>> I am curious how you detect such buggy code? By code review?
>
>Yes.
>
>I described this in the 0/6 message
>, but I'm
>happy to elaborate. :)
>
>So, Gerd has a Jenkins Continuous Integration environment that regularly
>fetches new edk2 commits and build OvmfPkg and ArmVirtPkg platforms.
>Gerd has recently updated his Jenkins instance to gcc-6, and gcc-6 flags
>some C language constructs -- with new warnings -- that used to "stay
>under the radar" with earlier gcc releases.
>
>So, one of the erroneous constructs that gcc-6 finds is:
>
>  ASSERT_EFI_ERROR (BooleanExpression)
>
>Clearly, in this case the programmer meant
>
>  ASSERT (BooleanExpression)
>
>and ASSERT_EFI_ERROR() is just a typo.
>
>gcc-6 finds this issue because:
>- ASSERT_EFI_ERROR() expands to EFI_ERROR(),
>- EFI_ERROR() expands to RETURN_ERROR(),
>- and RETURN_ERROR() checks if the argument, first converted to
>  RETURN_STATUS (== UINTN), then converted to INTN, is negative,
>- when a boolean expression is converted to UINTN, then INTN, the
>  result is always 0 or 1 -- it can never be negative.
>
>Therefore the incorrect form
>
>  ASSERT_EFI_ERROR (BooleanExpression)
>
>never fires, and gcc-6 finds it with the "-Wbool-compare".
>
>Now, Gerd's build stopped with the first such error, and because I
>hadn't set up gcc-6 yet, I decided to audit all ASSERT_EFI_ERROR()
>applications in edk2. I used the following command as first step:
>
>  git grep -Enw ASSERT_EFI_ERROR \
>  | grep -E -v 'ASSERT_EFI_ERROR( )?\(Status\)'
>
>because I wanted to see all invocations of this macro, *except* the
>following two form:
>
>  ASSERT_EFI_ERROR(Status)
>  ASSERT_EFI_ERROR (Status)
>
>Those two are by far the most frequent ones, and I trusted that a
>variable called "Status" would always have type RETURN_STATUS or EFI_STATUS.
>
>The rest of the macro invocations I audited one by one. Most of the
>errors that I found were of the kind
>
>  ASSERT_EFI_ERROR (BooleanExpression)
>
>which I simply fixed by removing the "_EFI_ERROR" part.
>
>The code fixed by this patch had a different kind of error, but the way
>I found those locations was the same: just looking at ASSERT_EFI_ERROR
>macro invocations.
>
>Thanks!
>Laszlo
>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>>> Laszlo Ersek
>>> Sent: Tuesday, June 28, 2016 9:26 PM
>>> To: edk2-devel-01 
>>> Cc: Carsey, Jaben ; Qiu, Shumin 
>>> 
>>> Subject: [edk2] [PATCH 4/6] ShellPkg: don't call functions with side 
>>> effects in ASSERT_EFI_ERROR()
>>>
>>> When ASSERT_EFI_ERROR() is compiled out, dependent on build flags, only
>>> the status checking should be removed; the function calls should stay.
>>>
>>> Cc: Jaben Carsey 
>>> Cc: Shumin Qiu 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Laszlo Ersek 
>>> ---
>>>
>>> Notes:
>>>build tested
>>>
>>> ShellPkg/Library/UefiShellLevel1CommandsLib/If.c | 10 --
>>> ShellPkg/Library/UefiShellLib/UefiShellLib.c |  5 -
>>> 2 files changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c 
>>> b/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
>>> index 7abfd8944b92..dc96bffde7d3 100644
>>> --- a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
>>> +++ b/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
>>> @@ -991,8 +991,11 @@ ShellCommandRunElse (
>>>   IN EFI_SYSTEM_TABLE  *SystemTable
>>>   )
>>> {
>>> +  EFI_STATUS  Status;
>>>   SCRIPT_FILE *CurrentScriptFile;
>>> -  ASSERT_EFI_ERROR(CommandInit());
>>> +
>>> +  Status = CommandInit ();
>>> +  ASSERT_EFI_ERROR (Status);
>>>
>>>   if (gEfiShellParametersProtocol->Argc > 1) {
>>> ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_TOO_MANY), 
>>> gShellLevel1HiiHandle, L"if");
>>> @@ -1066,8 +1069,11 @@ ShellCommandRunEndIf (
>>>   IN EFI_SYSTEM_TABLE  *SystemTable
>>>   )
>>> {
>>> +  EFI_STATUS  Status;
>>>   SCRIPT_FILE *CurrentScriptFile;
>>> -  ASSERT_EFI_ERROR(CommandInit());
>>> +
>>> +  Status = CommandInit ();
>>> +  ASSERT_EFI_ERROR (Status);
>>>
>>>   if (gEfiShellParametersProtocol->Argc > 1) {
>>> ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_TOO_MANY), 
>>> gShellLevel1HiiHandle, L"if");
>>> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
>>> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
>>> index cf89a4ac87ed..35a1a7169c8b 100644
>>> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.

Re: [edk2] [PATCH 2/7] BaseTools: Add missing Elf relocation type for LTO build

[Ard Biesheuvel]

On 28 June 2016 at 17:18, Shi, Steven  wrote:
> Add support to convert missing Elf relocation types
> (R_X86_64_PLT32, R_X86_64_GOTPCREL, R_X86_64_REX_GOTPCRELX)
> to PeCoff, which are required by LTO image.
>

Could you please put the changes that affect other architectures in a
separate patch?
The commit log suggests that only X64 is affected, but the patch
touches other things as well.

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Steven Shi 
> ---
>  BaseTools/Source/C/GenFw/Elf64Convert.c | 98 
> -
>  BaseTools/Source/C/GenFw/elf_common.h   |  2 +-
>  2 files changed, 86 insertions(+), 14 deletions(-)
>  mode change 100644 => 100755 BaseTools/Source/C/GenFw/Elf64Convert.c
>  mode change 100644 => 100755 BaseTools/Source/C/GenFw/elf_common.h
>
> diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
> b/BaseTools/Source/C/GenFw/Elf64Convert.c
> old mode 100644
> new mode 100755
> index 024a2a0..205360c
> --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> @@ -75,7 +75,7 @@ CleanUp64 (
>);
>
>  //
> -// Rename ELF32 strucutres to common names to help when porting to ELF64.
> +// Rename ELF32 structures to common names to help when porting to ELF64.
>  //
>  typedef Elf64_Shdr Elf_Shdr;
>  typedef Elf64_Ehdr Elf_Ehdr;
> @@ -233,7 +233,7 @@ IsTextShdr (
>Elf_Shdr *Shdr
>)
>  {
> -  return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == SHF_ALLOC);
> +  return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | 
> SHF_ALLOC)) == (SHF_EXECINSTR | SHF_ALLOC));
>  }
>
>  STATIC
> @@ -256,7 +256,7 @@ IsDataShdr (
>if (IsHiiRsrcShdr(Shdr)) {
>  return FALSE;
>}
> -  return (BOOLEAN) (Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == (SHF_ALLOC 
> | SHF_WRITE);
> +  return (BOOLEAN) (Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | 
> SHF_ALLOC)) == (SHF_ALLOC | SHF_WRITE);
>  }
>
>  STATIC
> @@ -661,9 +661,9 @@ WriteSections64 (
>
>default:
>  //
> -//  Ignore for unkown section type.
> +//  Ignore for unknown section type.
>  //
> -VerboseMsg ("%s unknown section type %x. We directly copy this 
> section into Coff file", mInImageName, (unsigned)Shdr->sh_type);
> +VerboseMsg ("%s unknown section type %x. We directly ignore this 
> section and NOT copy into Coff file", mInImageName, (unsigned)Shdr->sh_type);
>  break;
>}
>  }
> @@ -763,24 +763,24 @@ WriteSections64 (
>  // Absolute relocation.
>  //
>  VerboseMsg ("R_X86_64_64");
> -VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
> -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> +VerboseMsg ("Offset: 0x%08X, Addend: 0x%016LX",
> +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>*(UINT64 *)Targ);
>  *(UINT64 *)Targ = *(UINT64 *)Targ - SymShdr->sh_addr + 
> mCoffSectionsOffset[Sym->st_shndx];
>  VerboseMsg ("Relocation:  0x%016LX", *(UINT64*)Targ);
>  break;
>case R_X86_64_32:
>  VerboseMsg ("R_X86_64_32");
> -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>*(UINT32 *)Targ);
>  *(UINT32 *)Targ = (UINT32)((UINT64)(*(UINT32 *)Targ) - 
> SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
>  VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
>  break;
>case R_X86_64_32S:
>  VerboseMsg ("R_X86_64_32S");
> -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>*(UINT32 *)Targ);
>  *(INT32 *)Targ = (INT32)((INT64)(*(INT32 *)Targ) - 
> SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
>  VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
> @@ -790,14 +790,34 @@ WriteSections64 (
>  // Relative relocation: Symbol - Ip + Addend
>  //
>  VerboseMsg ("R_X86_64_PC32");
> -VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> -  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
> +VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",
> +  (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),
>*(UINT32 *)Targ);
>  *(UINT32 *)Targ = (UINT32) (*(UINT32 *)Targ
>+ (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr)
>- (SecOffset - SecShdr->sh_addr));
>  VerboseMsg ("Relocation:  0

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with MAX_ADDRESS check.

[Yao, Jiewen]

I forget to mention:

I agree with you on #2 - (2) The comparison is not appropriate here (after the 
patch); it is too strict.

BASE_4GB is an exclusive limit, hence the pre-patch status is good. But 
MAX_ADDRESS is an inclusive limit, so the condition should be
  CpuStart + PhysicalSize - 1 <= MAX_ADDRESS

Because CpuStart and PhysicalSize are UINT64, it may cause problem when the 
source is CpuStart+PhysicalSize==0x1, theoretically.



So I think we should update DxeCore and PeiCore as well - to use Start+Size - 1 
<= MAX_ADDRESS.

Thank you
Yao Jiewen

From: Yao, Jiewen
Sent: Wednesday, June 29, 2016 9:02 PM
To: Laszlo Ersek ; edk2-de...@ml01.01.org
Cc: Kinney, Michael D ; Fan, Jeff 
; Yao, Jiewen 
Subject: RE: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with 
MAX_ADDRESS check.

HI Laszlo
I appreciate your careful review.

I would like to clarify why we did not consider adding check for integer 
overflow.

The EDKII security model is that:

1)  We trust any internal data communication before EndOfDxe. We have to, 
because the SMM core has to trust the component runs before SMM, and construct 
SMM.

2)  We do not trust any external data communication after EndOfDxe. We 
should not, external data might be from an untrusted source. That is why we 
need lots of check in PE/COFF library, SMM communication buffer, UEFI 
authenticated variable, etc.

Based upon above assumption, SmramRanges is from a trusted source. There is *no 
need* to add security check, we just need add function check.

You can refer to how DxeCore parse resource description hob:
if (PhitHob->EfiFreeMemoryTop > (ResourceHob->PhysicalStart + 
ResourceHob->ResourceLength)) {
  continue;
}
  if ((ResourceHob->PhysicalStart + ResourceHob->ResourceLength) > 
(EFI_PHYSICAL_ADDRESS)MAX_ADDRESS) {
continue;
  }

You can refer to how PeiCore parse the resource description hob:
  if (ResourceHob->ResourceType != EFI_RESOURCE_SYSTEM_MEMORY ||
  ResourceHob->PhysicalStart + ResourceHob->ResourceLength > 
MAX_ADDRESS)   {
continue;
  }
  if (NextResourceHob->ResourceType != EFI_RESOURCE_SYSTEM_MEMORY || 
NextResourceHob->PhysicalStart + NextResourceHob->ResourceLength > MAX_ADDRESS) 
{
continue;
  }

if (ResourceHob->ResourceType == EFI_RESOURCE_SYSTEM_MEMORY &&
ResourceHob->PhysicalStart + ResourceHob->ResourceLength <= 
MAX_ADDRESS &&
ResourceHob->ResourceLength > TotalReservedMemorySize && 
PeiLoadFixAddressIsMemoryRangeAvailable(PrivateData, ResourceHob)) {


Go back to your suggestion. I have no problem to adopt you suggestion on using 
below format. It is not harmful.
  if (PhysicalSize <= MAX_ADDRESS && CpuStart - 1 <= MAX_ADDRESS - 
PhysicalSize) {

But one thing I have to mention is that: If we do not trust CpuStart and 
PhysicalSize, we will have big problem, because CPU driver need use these data 
to set SMRR, which is the basic of SMM security.
We have assume CpuStart and PhysicalSize is set correctly.


Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Wednesday, June 29, 2016 8:30 PM
To: Yao, Jiewen mailto:jiewen@intel.com>>; 
edk2-de...@ml01.01.org
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Fan, Jeff 
mailto:jeff@intel.com>>
Subject: Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Replace BASE_4GB with 
MAX_ADDRESS check.

On 06/29/16 04:29, Jiewen Yao wrote:
> PI specification Vol 4 - SMM does not have any limitation of BASE_4GB for SMM.
> So we should replace BASE_4GB check with MAX_ADDRESS check to make sure
> the SMM memory is accessible by SMM Core.
>
> Cc: Jeff Fan mailto:jeff@intel.com>>
> Cc: Michael D Kinney 
> mailto:michael.d.kin...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao mailto:jiewen@intel.com>>
> ---
>  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 2 +-
>  MdeModulePkg/Core/PiSmmCore/Pool.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
> b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> index acfcc83..3788bd5 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
> @@ -1556,7 +1556,7 @@ SmmIplEntry (
>  }
>
>  if (gSmmCorePrivate->SmramRanges[Index].CpuStart >= BASE_1MB) {
> -  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
> gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= BASE_4GB) {
> +  if ((gSmmCorePrivate->SmramRanges[Index].CpuStart + 
> gSmmCorePrivate->SmramRanges[Index].PhysicalSize) <= MAX_ADDRESS) {
>  if (gSmmCorePrivate->SmramRanges[Index].PhysicalSize >= MaxSize) {
>MaxSize = gSmmCorePrivate->SmramRanges[Index].PhysicalSize;
>mCurrentSmramRange = &gSmmCorePrivate->SmramRanges[Index];
> diff --git a/MdeModulePkg/Core/PiSmm

[edk2] [PATCH 1/9] OptionRomPkg: Refine FrameBufferBltLib to use UINT8* instead of VOID*

[Ruiyu Ni]

Using UINT8* can remove the unnecessary VOID* type cast.
The patch also rename the BltMemSrc/BltMemDest to Source/Destination.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Laszlo Ersek 
Cc: Jordan Justen 
---
 .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 131 +
 1 file changed, 58 insertions(+), 73 deletions(-)

diff --git a/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c 
b/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
index 955ae3d..7fd8196 100644
--- a/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
+++ b/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
@@ -1,7 +1,7 @@
 /** @file
   FrameBufferBltLib - Library to perform blt operations on a frame buffer.
 
-  Copyright (c) 2007 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2015, 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
@@ -12,11 +12,12 @@
 
 **/
 
-#include "PiDxe.h"
+#include 
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
 
 #if 0
 #define VDEBUG DEBUG
@@ -38,7 +39,6 @@ EFI_PIXEL_BITMASK   mPixelBitMasks;
 INTNmPixelShl[4]; // R-G-B-Rsvd
 INTNmPixelShr[4]; // R-G-B-Rsvd
 
-
 VOID
 ConfigurePixelBitMaskFormat (
   IN EFI_PIXEL_BITMASK  *BitMask
@@ -73,7 +73,6 @@ ConfigurePixelBitMaskFormat (
   CopyMem (&mPixelBitMasks, BitMask, sizeof (*BitMask));
 }
 
-
 /**
   Configure the FrameBufferLib instance
 
@@ -126,7 +125,6 @@ BltLibConfigure (
   return EFI_SUCCESS;
 }
 
-
 /**
   Performs a UEFI Graphics Output Protocol Blt operation.
 
@@ -210,7 +208,6 @@ BltLibGopBlt (
   }
 }
 
-
 /**
   Performs a UEFI Graphics Output Protocol Blt Video Fill.
 
@@ -235,8 +232,8 @@ BltLibVideoFill (
   IN  UINTN Height
   )
 {
-  UINTN   DstY;
-  VOID*BltMemDst;
+  UINTN   Y;
+  UINT8   *Destination;
   UINTN   X;
   UINT8   Uint8;
   UINT32  Uint32;
@@ -300,7 +297,7 @@ BltLibVideoFill (
   }
 }
 if (UseWideFill) {
-  SetMem ((VOID*) &WideFill, sizeof (WideFill), Uint8);
+  SetMem (&WideFill, sizeof (WideFill), Uint8);
 }
   }
 
@@ -308,31 +305,31 @@ BltLibVideoFill (
 VDEBUG ((EFI_D_INFO, "VideoFill (wide, one-shot)\n"));
 Offset = DestinationY * mBltLibWidthInPixels;
 Offset = mBltLibBytesPerPixel * Offset;
-BltMemDst = (VOID*) (mBltLibFrameBuffer + Offset);
+Destination = mBltLibFrameBuffer + Offset;
 SizeInBytes = WidthInBytes * Height;
 if (SizeInBytes >= 8) {
-  SetMem32 (BltMemDst, SizeInBytes & ~3, (UINT32) WideFill);
-  SizeInBytes = SizeInBytes & 3;
+  SetMem32 (Destination, SizeInBytes & ~3, (UINT32) WideFill);
+  SizeInBytes &= 3;
 }
 if (SizeInBytes > 0) {
-  SetMem (BltMemDst, SizeInBytes, (UINT8)(UINTN) WideFill);
+  SetMem (Destination, SizeInBytes, (UINT8)(UINTN) WideFill);
 }
   } else {
 LineBufferReady = FALSE;
-for (DstY = DestinationY; DstY < (Height + DestinationY); DstY++) {
-  Offset = (DstY * mBltLibWidthInPixels) + DestinationX;
+for (Y = DestinationY; Y < (Height + DestinationY); Y++) {
+  Offset = (Y * mBltLibWidthInPixels) + DestinationX;
   Offset = mBltLibBytesPerPixel * Offset;
-  BltMemDst = (VOID*) (mBltLibFrameBuffer + Offset);
+  Destination = mBltLibFrameBuffer + Offset;
 
-  if (UseWideFill && (((UINTN) BltMemDst & 7) == 0)) {
+  if (UseWideFill && (((UINTN) Destination & 7) == 0)) {
 VDEBUG ((EFI_D_INFO, "VideoFill (wide)\n"));
 SizeInBytes = WidthInBytes;
 if (SizeInBytes >= 8) {
-  SetMem64 (BltMemDst, SizeInBytes & ~7, WideFill);
-  SizeInBytes = SizeInBytes & 7;
+  SetMem64 (Destination, SizeInBytes & ~7, WideFill);
+  SizeInBytes &= 7;
 }
 if (SizeInBytes > 0) {
-  CopyMem (BltMemDst, (VOID*) &WideFill, SizeInBytes);
+  CopyMem (Destination, &WideFill, SizeInBytes);
 }
   } else {
 VDEBUG ((EFI_D_INFO, "VideoFill (not wide)\n"));
@@ -344,11 +341,11 @@ BltLibVideoFill (
   mBltLibLineBuffer,
   MIN (X, Width - X) * mBltLibBytesPerPixel
   );
-X = X + MIN (X, Width - X);
+X += MIN (X, Width - X);
   }
   LineBufferReady = TRUE;
 }
-CopyMem (BltMemDst, mBltLibLineBuffer, WidthInBytes);
+CopyMem (Destination, mBltLibLineBuffer, WidthInBytes);
   }
 }
   }
@@ -356,7 +353,6 @@ BltLibVideoFill (
   return EFI_SUCCESS;
 }
 
-
 /**
   Performs a UEFI G

[edk2] [PATCH 3/9] OptionRomPkg/BltLib: Fix a bug in BltVideoToVideo operation

[Ruiyu Ni]

The bug can be reproduced by the BltLibSample application
TestMove1() test case. The old code cannot handle the case
when the source and destination video is overlapped.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Laszlo Ersek 
Cc: Jordan Justen 
---
 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c 
b/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
index 7fd8196..49ef568 100644
--- a/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
+++ b/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
@@ -694,6 +694,11 @@ BltLibVideoToVideo (
 
   LineStride = mBltLibWidthInBytes;
   if (Destination > Source) {
+//
+// Copy from last line to avoid source is corrupted by copying
+//
+Source += Height * LineStride;
+Destination += Height * LineStride;
 LineStride = -LineStride;
   }
 
-- 
2.8.3.windows.1

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