Re: [edk2] [PATCH] UefiCpuPkg/CpuFeatures: Change CPU features name to follow IA32 SDM

[Tian, Feng]

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff Fan
Sent: Thursday, April 6, 2017 1:47 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Tian, Feng 

Subject: [edk2] [PATCH] UefiCpuPkg/CpuFeatures: Change CPU features name to 
follow IA32 SDM

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
index 4765bc3..4aa3529 100644
--- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
+++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
@@ -45,8 +45,8 @@
 #define CPU_FEATURE_C1E 16
 #define CPU_FEATURE_C1_AUTO_DEMOTION17
 #define CPU_FEATURE_C3_AUTO_DEMOTION18
-#define CPU_FEATURE_C1_AUTO_UNDEMOTION  19
-#define CPU_FEATURE_C3_AUTO_UNDEMOTION  20
+#define CPU_FEATURE_C1_UNDEMOTION   19
+#define CPU_FEATURE_C3_UNDEMOTION   20
 #define CPU_FEATURE_C_STATE 21
 #define CPU_FEATURE_TM  22
 #define CPU_FEATURE_TM2 23
-- 
2.9.3.windows.2

___
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] Pull in pre-built library during edk2 build?

[Peter Hornyack]

Thank you Laszlo and others for the suggestions! I'll try out that
patch with PACKAGES_PATH and it looks like I should be able to get
this working.

Thanks,
Peter

On Thu, Apr 6, 2017 at 4:16 PM, Laszlo Ersek  wrote:
> On 04/07/17 00:46, Laszlo Ersek wrote:
>
>> 0001-ExternalSslPkg-create-INF-files-for-OpensslLib-binar.patch
>>
>>
>> From 4672a027f54c54574129f9c9cc947c80f7bc4d9f Mon Sep 17 00:00:00 2001
>> From: Laszlo Ersek 
>> Date: Thu, 6 Apr 2017 22:56:04 +0200
>> Subject: [PATCH] ExternalSslPkg: create INF files for OpensslLib binaries
>>
>> Signed-off-by: Laszlo Ersek
>> ---
>>  .../Library/OpensslLib/OpensslLibBin.inf   | 33 
>> ++
>>  .../Library/OpensslLib/OpensslLibBinCrypto.inf | 33 
>> ++
>>  2 files changed, 66 insertions(+)
>>  create mode 100644 ExternalSslPkg/Library/OpensslLib/OpensslLibBin.inf
>>  create mode 100644 ExternalSslPkg/Library/OpensslLib/OpensslLibBinCrypto.inf
>>
>> diff --git a/ExternalSslPkg/Library/OpensslLib/OpensslLibBin.inf 
>> b/ExternalSslPkg/Library/OpensslLib/OpensslLibBin.inf
>> new file mode 100644
>> index ..703fddb47606
>> --- /dev/null
>> +++ b/ExternalSslPkg/Library/OpensslLib/OpensslLibBin.inf
>> @@ -0,0 +1,33 @@
>> +## @file
>> +#  This module provides binary OpenSSL Library implementation.
>> +#
>> +#  Copyright (C) 2017, Red Hat, Inc.
>> +#  Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
>> +#  This program and the accompanying materials are licensed and made 
>> available
>> +#  under the terms and conditions of the BSD License which accompanies this
>> +#  distribution.  The full text of the license may be found at
>> +#  http://opensource.org/licenses/bsd-license.php
>> +#
>> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
>> +#  IMPLIED.
>> +#
>> +##
>> +
>> +[Defines]
>> +  INF_VERSION= 1.25
>> +  BASE_NAME  = OpensslLibBin
>> +  FILE_GUID  = d0d4d4cf-460c-4752-9c9b-6d821b2ffe49
>> +  MODULE_TYPE= BASE
>> +  VERSION_STRING = 1.0
>> +  LIBRARY_CLASS  = OpensslLib
>> +
>> +[Binaries.IA32]
>> +  LIB|DEBUG/IA32/OpensslLib.lib|DEBUG
>> +  LIB|NOOPT/IA32/OpensslLib.lib|NOOPT
>> +  LIB|RELEASE/IA32/OpensslLib.lib|RELEASE
>> +
>> +[Binaries.X64]
>> +  LIB|DEBUG/X64/OpensslLib.lib|DEBUG
>> +  LIB|NOOPT/X64/OpensslLib.lib|NOOPT
>> +  LIB|RELEASE/X64/OpensslLib.lib|RELEASE
>
> I submitted , so
> that the next version of the INF spec
> 
> document the LIB file type as well, for the [Binaries] sections of INF
> files that belong to library instances.
>
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] ShellPkg/SetVar: Fix typo in comments

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

Thanks/Ray

> -Original Message-
> From: Bi, Dandan
> Sent: Friday, April 7, 2017 11:01 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu 
> Subject: [patch] ShellPkg/SetVar: Fix typo in comments
> 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
> index 7cbe0d9..8fb918d 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
> @@ -245,11 +245,11 @@ ParseParameterData (  }
> 
>  /**
>Function to get each data from parameters.
> 
> -  @param[in]Pacakge   The package of checked values.
> +  @param[in]Package   The package of checked values.
>@param[out]   BufferA pointer to a buffer to hold the 
> return data.
>@param[out]   BufferSizeIndicates the size of data in bytes 
> return in
> Buffer.
> 
>@retval   EFI_INVALID_PARAMETER Buffer or BufferSize is NULL.
>@retval   EFI_OUT_OF_RESOURCES  A memory allcation failed.
> --
> 1.9.5.msysgit.1

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

[edk2] [PATCH] ShellPkg: Fix Shell to not return without startup.nsh after timeout

[Ruiyu Ni]

When user doesn't press key to exit the timeout waiting in Shell,
and there is no startup.nsh, Shell exits with failure status.
aaf51f08ee104447207bba571649556095befc93 introduced this bug.
The patch fixes this issue.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Chen A Chen 
---
 ShellPkg/Application/Shell/Shell.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ShellPkg/Application/Shell/Shell.c 
b/ShellPkg/Application/Shell/Shell.c
index e91b964..4383298 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -1279,6 +1279,11 @@ DoStartupScript(
   if (FileStringPath != NULL) {
 Status = RunScriptFile (FileStringPath, NULL, L"", 
ShellInfoObject.NewShellParametersProtocol);
 FreePool (FileStringPath);
+  } else {
+//
+// we return success since startup script is not mandatory.
+//
+Status = EFI_SUCCESS;
   }
 
   return (Status);
-- 
2.9.0.windows.1

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

[edk2] [patch] ShellPkg/SetVar: Fix typo in comments

[Dandan Bi]

Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
index 7cbe0d9..8fb918d 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c
@@ -245,11 +245,11 @@ ParseParameterData (
 }
 
 /**
   Function to get each data from parameters.
 
-  @param[in]Pacakge   The package of checked values.
+  @param[in]Package   The package of checked values.
   @param[out]   BufferA pointer to a buffer to hold the return 
data.
   @param[out]   BufferSizeIndicates the size of data in bytes 
return in Buffer.
 
   @retval   EFI_INVALID_PARAMETER Buffer or BufferSize is NULL.
   @retval   EFI_OUT_OF_RESOURCES  A memory allcation failed.
-- 
1.9.5.msysgit.1

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

Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

[gengdongjiu]

Hi Laszlo,
  thanks.

On 2017/4/7 2:55, Laszlo Ersek wrote:
> On 04/06/17 14:35, gengdongjiu wrote:
>> Dear, Laszlo
>>Thanks for your detailed explanation.
>>
>> On 2017/3/29 19:58, Laszlo Ersek wrote:
>>> (This ought to be one of the longest address lists I've ever seen :)
>>> Thanks for the CC. I'm glad Shannon is already on the CC list. For good
>>> measure, I'm adding MST and Igor.)
>>>
>>> On 03/29/17 12:36, Achin Gupta wrote:
 Hi gengdongjiu,

 On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote:
>
> Hi Laszlo/Biesheuvel/Qemu developer,
>
>Now I encounter a issue and want to consult with you in ARM64 
> platform， as described below:
>
> when guest OS happen synchronous or asynchronous abort, kvm needs
> to send the error address to Qemu or UEFI through sigbus to
> dynamically generate APEI table. from my investigation, there are
> two ways:
>
> (1) Qemu get the error address, and generate the APEI table, then
> notify UEFI to know this generation, then inject abort error to
> guest OS, guest OS read the APEI table.
> (2) Qemu get the error address, and let UEFI to generate the APEI
> table, then inject abort error to guest OS, guest OS read the APEI
> table.

 Just being pedantic! I don't think we are talking about creating the APEI 
 table
 dynamically here. The issue is: Once KVM has received an error that is 
 destined
 for a guest it will raise a SIGBUS to Qemu. Now before Qemu can inject the 
 error
 into the guest OS, a CPER (Common Platform Error Record) has to be 
 generated
 corresponding to the error source (GHES corresponding to memory subsystem,
 processor etc) to allow the guest OS to do anything meaningful with the
 error. So who should create the CPER is the question.

 At the EL3/EL2 interface (Secure Firmware and OS/Hypervisor), an error 
 arrives
 at EL3 and secure firmware (at EL3 or a lower secure exception level) is
 responsible for creating the CPER. ARM is experimenting with using a 
 Standalone
 MM EDK2 image in the secure world to do the CPER creation. This will avoid
 adding the same code in ARM TF in EL3 (better for security). The error 
 will then
 be injected into the OS/Hypervisor (through SEA/SEI/SDEI) through ARM 
 Trusted
 Firmware.

 Qemu is essentially fulfilling the role of secure firmware at the EL2/EL1
 interface (as discussed with Christoffer below). So it should generate the 
 CPER
 before injecting the error.

 This is corresponds to (1) above apart from notifying UEFI (I am assuming 
 you
 mean guest UEFI). At this time, the guest OS already knows where to pick 
 up the
 CPER from through the HEST. Qemu has to create the CPER and populate its 
 address
 at the address exported in the HEST. Guest UEFI should not be involved in 
 this
 flow. Its job was to create the HEST at boot and that has been done by this
 stage.

 Qemu folk will be able to add but it looks like support for CPER 
 generation will
 need to be added to Qemu. We need to resolve this.

 Do shout if I am missing anything above.
>>>
>>> After reading this email, the use case looks *very* similar to what
>>> we've just done with VMGENID for QEMU 2.9.
>>>
>>> We have a facility between QEMU and the guest firmware, called "ACPI
>>> linker/loader", with which QEMU instructs the firmware to
>>>
>>> - allocate and download blobs into guest RAM (AcpiNVS type memory) --
>>> ALLOCATE command,
>>>
>>> - relocate pointers in those blobs, to fields in other (or the same)
>>> blobs -- ADD_POINTER command,
>>>
>>> - set ACPI table checksums -- ADD_CHECKSUM command,
>>>
>>> - and send GPAs of fields within such blobs back to QEMU --
>>> WRITE_POINTER command.
>>>
>>> This is how I imagine we can map the facility to the current use case
>>> (note that this is the first time I read about HEST / GHES / CPER):
>>>
>>> etc/acpi/tables etc/hardware_errors
>>>  ==
>>>  +---+
>>> +--+ | address   | +-> +--+
>>> |HEST  + | registers | |   | Error Status |
>>> + ++ | +-+ |   | Data Block 1 |
>>> | | GHES   | --> | | address | +   | ++
>>> | | GHES   | --> | | address | --+ | |  CPER  |
>>> | | GHES   | --> | | address | + | | |  CPER  |
>>> | | GHES   | --> | | address | -+  | | | |  CPER  |
>>> +-++ +-+-+  |  | | +-++
>>> |  | |
>>> |  | +---> +--+
>>> |  |   | Error 

Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: Enhance short-form expanding logic

[Tian, Feng]

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Ni, Ruiyu 
Sent: Thursday, April 6, 2017 5:45 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Dong, Eric ; Fan, 
Jeff 
Subject: [PATCH] MdeModulePkg/UefiBootManagerLib: Enhance short-form expanding 
logic

Old implementation only finds first matched full device path for a given 
short-form device path.
The patch adds internal function BmGetNextLoadOptionBuffer() to finds all 
matched full device path for a given short-form device path.
There are 6 kinds of device paths. Some of them match to multiple load options, 
some of them don't.

1. Media device path:
   Returns multiple load options: The media device path may point
   to a physical BlockIo which contains multiple logic partitions,
   each logic partitions contains \EFI\BOOT\BOOT${ARCH}.EFI.

2. Short-form hard-drive device path:
   Returns one load option because the partition signature is unique.

3. Short-form file-path device path:
   Returns multiple load options: There are multiple SimpleFileSystem
   instances and each contains the same file.

4. Short-form URI device path:
   Returns multiple load options: There are multiple LoadFile
   instances and each can boot.

5. Short-form USB device path:
   Returns multiple load options: There are multiple UsbIo instances
   and each contains the boot-able file.

6. FV device path, device path pointing to SimpleFileSystem, device
   path pointing to LoadFile
   Returns one load option.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
Cc: Eric Dong 
Cc: Jeff Fan 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   | 470 -
 .../Library/UefiBootManagerLib/BmLoadOption.c  | 173 ++--
 .../Library/UefiBootManagerLib/InternalBm.h| 100 +++--
 3 files changed, 475 insertions(+), 268 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 8a3a402..aa79c90 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -131,21 +131,16 @@ BmFindBootOptionInVariable (  }
 
 /**
-  Get the file buffer using a Memory Mapped Device Path.
-
+  Return the correct FV file path.
   FV address may change across reboot. This routine promises the FV file 
device path is right.
 
   @param  FilePath The Memory Mapped Device Path to get the file buffer.
-  @param  FullPath Receive the updated FV Device Path pointint to the file.
-  @param  FileSize Receive the file buffer size.
 
-  @return  The file buffer.
+  @return  The updated FV Device Path pointint to the file.
 **/
-VOID *
-BmGetFileBufferByFvFilePath (
-  IN EFI_DEVICE_PATH_PROTOCOL  *FilePath,
-  OUT EFI_DEVICE_PATH_PROTOCOL **FullPath,
-  OUT UINTN*FileSize
+EFI_DEVICE_PATH_PROTOCOL *
+BmAdjustFvFilePath (
+  IN EFI_DEVICE_PATH_PROTOCOL  *FilePath
   )
 {
   EFI_STATUSStatus;
@@ -153,11 +148,10 @@ BmGetFileBufferByFvFilePath (
   EFI_DEVICE_PATH_PROTOCOL  *FvFileNode;
   EFI_HANDLEFvHandle;
   EFI_LOADED_IMAGE_PROTOCOL *LoadedImage;
-  UINT32AuthenticationStatus;
   UINTN FvHandleCount;
   EFI_HANDLE*FvHandles;
   EFI_DEVICE_PATH_PROTOCOL  *NewDevicePath;
-  VOID  *FileBuffer;
+  EFI_DEVICE_PATH_PROTOCOL  *FullPath;
 
   //
   // Get the file buffer by using the exactly FilePath.
@@ -165,11 +159,7 @@ BmGetFileBufferByFvFilePath (
   FvFileNode = FilePath;
   Status = gBS->LocateDevicePath (, 
, );
   if (!EFI_ERROR (Status)) {
-FileBuffer = GetFileBufferByFilePath (TRUE, FilePath, FileSize, 
);
-if (FileBuffer != NULL) {
-  *FullPath = DuplicateDevicePath (FilePath);
-}
-return FileBuffer;
+return DuplicateDevicePath (FilePath);
   }
 
   //
@@ -190,11 +180,10 @@ BmGetFileBufferByFvFilePath (
  (VOID **) 
  );
   NewDevicePath = AppendDevicePathNode (DevicePathFromHandle 
(LoadedImage->DeviceHandle), FvFileNode);
-  FileBuffer = BmGetFileBufferByFvFilePath (NewDevicePath, FullPath, FileSize);
+  FullPath = BmAdjustFvFilePath (NewDevicePath);
   FreePool (NewDevicePath);
-
-  if (FileBuffer != NULL) {
-return FileBuffer;
+  if (FullPath != NULL) {
+return FullPath;
   }
 
   //
@@ -207,22 +196,25 @@ BmGetFileBufferByFvFilePath (
  ,
  
  );
-  for (Index = 0; (Index < FvHandleCount) && (FileBuffer == NULL); Index++) {
+  for (Index = 0; Index < FvHandleCount; Index++) {
 if (FvHandles[Index] == LoadedImage->DeviceHandle) {
   //
-  // Skip current FV
+  // Skip current FV, it was handed in first step.
   //
   continue;
 }
  

[edk2] [PATCH] AppPkg/Applications/Python/PyMod-2.7.2: Replace non-ascii characters

[Hao Wu]

Cc: Daryl McDaniel 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Contributed-by: gray.wang 
Signed-off-by: Hao Wu 
---
 AppPkg/Applications/Python/PyMod-2.7.2/Python/marshal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/AppPkg/Applications/Python/PyMod-2.7.2/Python/marshal.c 
b/AppPkg/Applications/Python/PyMod-2.7.2/Python/marshal.c
index 153bc13a11..698ffb5734 100644
--- a/AppPkg/Applications/Python/PyMod-2.7.2/Python/marshal.c
+++ b/AppPkg/Applications/Python/PyMod-2.7.2/Python/marshal.c
@@ -1289,7 +1289,7 @@ The file must be an open file object such as sys.stdout 
or returned by\n\
 open() or os.popen(). It must be opened in binary mode ('wb' or 'w+b').\n\
 \n\
 If the value has (or contains an object that has) an unsupported type, a\n\
-ValueError exception is raised — but garbage data will also be written\n\
+ValueError exception is raised - but garbage data will also be written\n\
 to the file. The object will not be properly read back by load()\n\
 \n\
 New in version 2.4: The version argument indicates the data format that\n\
@@ -1317,7 +1317,7 @@ PyDoc_STRVAR(load_doc,
 "load(file)\n\
 \n\
 Read one value from the open file and return it. If no valid value is\n\
-read (e.g. because the data has a different Python version’s\n\
+read (e.g. because the data has a different Python version's\n\
 incompatible marshal format), raise EOFError, ValueError or TypeError.\n\
 The file must be an open file object opened in binary mode ('rb' or\n\
 'r+b').\n\
-- 
2.12.0.windows.1

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

Re: [edk2] [edk2-FdfSpecification PATCH] Add missing EBNF definition for

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Friday, April 7, 2017 7:22 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-FdfSpecification PATCH] Add missing EBNF definition for 


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

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 3_edk_ii_fdf_file_format/37_[capsule]_sections.md| 1 +
 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 3 ++-
 README.md| 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/3_edk_ii_fdf_file_format/37_[capsule]_sections.md 
b/3_edk_ii_fdf_file_format/37_[capsule]_sections.md
index c912b40..c2aedba 100644
--- a/3_edk_ii_fdf_file_format/37_[capsule]_sections.md
+++ b/3_edk_ii_fdf_file_format/37_[capsule]_sections.md
@@ -304,6 +304,7 @@ Conditional statements may be used anywhere within this 
section.
::= "SECTION"  [] "SMM_DEPEX_EXP"
  "{" []  "}" 
 ::=  "FMP_PAYLOAD"   
+ ::= 
   ::=  "FILE"  "DATA" ```
 
diff --git a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md 
b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
index 1c38f59..31e1166 100644
--- a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
+++ b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
@@ -37,9 +37,10 @@ Capsule files.
  Prototype
 
 ```c
-  ::= "[FmpPayload"  "]" 
+  ::= "[FmpPayload" "."  "]" 
   
   
+   ::= 
::= [ "IMAGE_HEADER_INIT_VERSION"   ]
"IMAGE_TYPE_ID"   
   [ "IMAGE_INDEX"   ] diff --git 
a/README.md b/README.md index 9a7f13a..1c9b315 100644
--- a/README.md
+++ b/README.md
@@ -196,3 +196,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || Clarified [UserExtensions] content in chapter 2 (to match 
implementation) 
 |   |
 | 1.28   | Convert to GitBooks 

   | March 2017|
 || [#426](https://bugzilla.tianocore.org/show_bug.cgi?id=426) 
IMAGE_TYPE_ID must be provided with value, FDF should mark it as required 
section   |   |
+|| [#249](https://bugzilla.tianocore.org/show_bug.cgi?id=249) FDF 
spec miss '' definition  
|   |
--
2.6.3.windows.1

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

Re: [edk2] [edk2-FdfSpecification PATCH] [FmpPayload] supports 1 or 2 FILE DATA statements

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Friday, April 7, 2017 4:00 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-FdfSpecification PATCH] [FmpPayload] supports 1 or 2 FILE DATA 
statements

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

Update the EBNF for [FmpPayload] in Section 3.8 to allow one or two FILE DATA 
statements.  The first for the update image.  The second for venddor code.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 9 -
 README.md| 1 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md 
b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
index 1c38f59..77ad2b7 100644
--- a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
+++ b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
@@ -34,12 +34,19 @@
 These are optional sections that describes the FMP payload content for FMP  
Capsule files.
 
+There must be at least one and at most two `` statements.  
+The `` statements start with `FILE DATA`.  The first 
+ statement provides the information for UpdateImage in an 
+`EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER`.  The second 
+ statement, if present, provides the information for 
+VendorCode in an `EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER`.
+
  Prototype
 
 ```c
   ::= "[FmpPayload"  "]" 
   
-  
+  {1,2}
::= [ "IMAGE_HEADER_INIT_VERSION"   ]
"IMAGE_TYPE_ID"   
   [ "IMAGE_INDEX"   ] diff --git 
a/README.md b/README.md index 9a7f13a..f7e1d1f 100644
--- a/README.md
+++ b/README.md
@@ -196,3 +196,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || Clarified [UserExtensions] content in chapter 2 (to match 
implementation) 
 |   |
 | 1.28   | Convert to GitBooks 

   | March 2017|
 || [#426](https://bugzilla.tianocore.org/show_bug.cgi?id=426) 
IMAGE_TYPE_ID must be provided with value, FDF should mark it as required 
section   |   |
+|| [#461](https://bugzilla.tianocore.org/show_bug.cgi?id=461) FDF 
Spec: add a super script number for the
|   |
--
2.6.3.windows.1

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

Re: [edk2] [edk2-FdfSpecification PATCH] Fix conditional statement examples

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Friday, April 7, 2017 5:56 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-FdfSpecification PATCH] Fix conditional statement examples

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

* Removge space between !if and else
* Add $() around BARFOO

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_fdf_design_discussion/22_flash_description_file_format.md | 4 ++--
 README.md   | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/2_fdf_design_discussion/22_flash_description_file_format.md 
b/2_fdf_design_discussion/22_flash_description_file_format.md
index 9c993f4..dfbd889 100644
--- a/2_fdf_design_discussion/22_flash_description_file_format.md
+++ b/2_fdf_design_discussion/22_flash_description_file_format.md
@@ -600,7 +600,7 @@ The following is an example of conditional statements.
 ```ini
 !if ("MSFT" in $(FAMILY)) or ("INTEL" in $(FAMILY))  ... statements -!else if 
$(FAMILY) == "GCC"
+!elseif $(FAMILY) == "GCC"
 ... statements
 !endif
 
@@ -610,7 +610,7 @@ The following is an example of conditional statements.
   !else
 # FOO defined, BAR is defined
   !endif
-!elseif BARFOO
+!elseif $(BARFOO)
   # FOO is not defined, BARFOO is defined as TRUE  !elseif $(BARFOO) == 
"FOOBAR"
   # FOO is not defined, BARFOO is defined as FOOBAR diff --git a/README.md 
b/README.md index 9a7f13a..74269dc 100644
--- a/README.md
+++ b/README.md
@@ -196,3 +196,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || Clarified [UserExtensions] content in chapter 2 (to match 
implementation) 
 |   |
 | 1.28   | Convert to GitBooks 

   | March 2017|
 || [#426](https://bugzilla.tianocore.org/show_bug.cgi?id=426) 
IMAGE_TYPE_ID must be provided with value, FDF should mark it as required 
section   |   |
+|| [#373](https://bugzilla.tianocore.org/show_bug.cgi?id=373) 
Conditional statement examples incorrect
|   |
--
2.6.3.windows.1

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

Re: [edk2] [PATCH v2 0/5] Export Dump CPU Context service

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Fan, Jeff
> Sent: Friday, April 7, 2017 9:18 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Kinney, Michael D
> ; Tian, Feng 
> Subject: [PATCH v2 0/5] Export Dump CPU Context service
> 
> This serial of patches are:
> 1. Export PeCoffSerachImageBase() that could serach PE/COFF image base.
> 2. Export DumpCpuContext that could dump CPU context when exception
> happened.
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=242
> 
> v2:
>   Combine v1's patch 3-6 to v2's patch 3.
>   Combine v1's patch 7, 8 to v2's patch 4.
> 
> Cc: Jiewen Yao 
> Cc: Michael Kinney 
> Cc: Feng Tian 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan 
> 
> Jeff Fan (5):
>   MdePkg/PeCoffGetEntryPointLib: Add PeCoffSerachImageBase()
>   MdeModulePkg/CpuExceptionHandlerLib: Add DumpCpuContext()
>   UefiCpuPkg/CpuExceptionHandlerLib: Add DumpCpuContext()
> implementation
>   UefiCpuPkg/PiSmmCpuDxeSmm: Consume new APIs
>   SourceLevelDebugPkg/DebugAgent.c: Consume PeCoffSerachImageBase()
> 
>  .../Include/Library/CpuExceptionHandlerLib.h   | 15 +++-
>  .../CpuExceptionHandlerLibNull.c   | 16 -
>  MdePkg/Include/Library/PeCoffGetEntryPointLib.h| 20 +-
>  .../PeCoffGetEntryPoint.c  | 72
> ++-
>  .../DebugAgent/DebugAgentCommon/DebugAgent.c   | 50 ++---
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.c| 82
> ++
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.h| 27 ---
>  .../Library/CpuExceptionHandlerLib/DxeException.c  |  7 +-
>  .../Ia32/ArchExceptionHandler.c| 65 ++---
>  .../CpuExceptionHandlerLib/PeiCpuException.c   |  6 +-
>  .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c |  4 +-
>  .../CpuExceptionHandlerLib/SecPeiCpuException.c|  8 +--
>  .../Library/CpuExceptionHandlerLib/SmmException.c  |  7 +-
>  .../X64/ArchExceptionHandler.c | 59 ++--
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 18 ++---
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 37 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  4 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h |  6 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 18 ++---
>  19 files changed, 268 insertions(+), 253 deletions(-)
> 
> --
> 2.9.3.windows.2

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

[edk2] [PATCH v2 4/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume new APIs

[Jeff Fan]

Consuming PeCoffSerachImageBase() from PeCoffGetEntrypointLib and consuming
DumpCpuContext() from CpuExceptionHandlerLib to replace its own implementation.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 18 +
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 37 +++---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  4 +--
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h |  6 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 18 +
 5 files changed, 18 insertions(+), 65 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index 119810a..32ce595 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -1,7 +1,7 @@
 /** @file
 Page table manipulation functions for IA-32 processors
 
-Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
 Copyright (c) 2017, AMD Incorporated. All rights reserved.
 
 This program and the accompanying materials
@@ -88,8 +88,8 @@ SmiDefaultPFHandler (
 VOID
 EFIAPI
 SmiPFHandler (
-IN EFI_EXCEPTION_TYPE   InterruptType,
-IN EFI_SYSTEM_CONTEXT   SystemContext
+  IN EFI_EXCEPTION_TYPE   InterruptType,
+  IN EFI_SYSTEM_CONTEXT   SystemContext
   )
 {
   UINTN PFAddress;
@@ -108,6 +108,7 @@ SmiPFHandler (
   //
   if ((PFAddress >= mCpuHotPlugData.SmrrBase) &&
   (PFAddress < (mCpuHotPlugData.SmrrBase + mCpuHotPlugData.SmrrSize))) {
+DumpCpuContext (InterruptType, SystemContext);
 CpuIndex = GetCpuIndex ();
 GuardPageAddress = (mSmmStackArrayBase + EFI_PAGE_SIZE + CpuIndex * 
mSmmStackSize);
 if ((FeaturePcdGet (PcdCpuSmmStackGuard)) &&
@@ -115,15 +116,6 @@ SmiPFHandler (
 (PFAddress < (GuardPageAddress + EFI_PAGE_SIZE))) {
   DEBUG ((DEBUG_ERROR, "SMM stack overflow!\n"));
 } else {
-  DEBUG ((DEBUG_ERROR, "SMM exception data - 0x%x(", 
SystemContext.SystemContextIa32->ExceptionData));
-  DEBUG ((DEBUG_ERROR, "I:%x, R:%x, U:%x, W:%x, P:%x",
-(SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_ID) != 0,
-(SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_RSVD) != 
0,
-(SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_US) != 0,
-(SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_WR) != 0,
-(SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_P) != 0
-));
-  DEBUG ((DEBUG_ERROR, ")\n"));
   if ((SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_ID) != 
0) {
 DEBUG ((DEBUG_ERROR, "SMM exception at execution (0x%x)\n", 
PFAddress));
 DEBUG_CODE (
@@ -144,6 +136,7 @@ SmiPFHandler (
   //
   if ((PFAddress < mCpuHotPlugData.SmrrBase) ||
   (PFAddress >= mCpuHotPlugData.SmrrBase + mCpuHotPlugData.SmrrSize)) {
+DumpCpuContext (InterruptType, SystemContext);
 if ((SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_ID) != 0) 
{
   DEBUG ((DEBUG_ERROR, "Code executed on IP(0x%x) out of SMM range after 
SMM is locked!\n", PFAddress));
   DEBUG_CODE (
@@ -166,6 +159,7 @@ SmiPFHandler (
   SystemContext.SystemContextIa32->ExceptionData
   );
   } else {
+DumpCpuContext (InterruptType, SystemContext);
 SmiDefaultPFHandler ();
   }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index 47cba10..2cb0bbc 100755
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -173,48 +173,17 @@ DumpModuleInfoByIp (
   )
 {
   UINTNPe32Data;
-  EFI_IMAGE_DOS_HEADER *DosHdr;
-  EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION  Hdr;
   VOID *PdbPointer;
-  UINT64   DumpIpAddress;
 
   //
   // Find Image Base
   //
-  Pe32Data = CallerIpAddress & ~(SIZE_4KB - 1);
-  while (Pe32Data != 0) {
-DosHdr = (EFI_IMAGE_DOS_HEADER *) Pe32Data;
-if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
-  //
-  // DOS image header is present, so read the PE header after the DOS 
image header.
-  //
-  Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)(Pe32Data + (UINTN) 
((DosHdr->e_lfanew) & 0x0));
-  //
-  // Make sure PE header address does not overflow and is less than the 
initial address.
-  //
-  if (((UINTN)Hdr.Pe32 > Pe32Data) && ((UINTN)Hdr.Pe32 < CallerIpAddress)) 
{
-if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
-  //
-  // It's PE image.
-  //
-  break;
-}
-  }
-}
-
-//
-// Not found the image base, check the previous aligned address
-  

[edk2] [PATCH v2 0/5] Export Dump CPU Context service

[Jeff Fan]

This serial of patches are:
1. Export PeCoffSerachImageBase() that could serach PE/COFF image base.
2. Export DumpCpuContext that could dump CPU context when exception happened.

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

v2:
  Combine v1's patch 3-6 to v2's patch 3.
  Combine v1's patch 7, 8 to v2's patch 4.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 

Jeff Fan (5):
  MdePkg/PeCoffGetEntryPointLib: Add PeCoffSerachImageBase()
  MdeModulePkg/CpuExceptionHandlerLib: Add DumpCpuContext()
  UefiCpuPkg/CpuExceptionHandlerLib: Add DumpCpuContext() implementation
  UefiCpuPkg/PiSmmCpuDxeSmm: Consume new APIs
  SourceLevelDebugPkg/DebugAgent.c: Consume PeCoffSerachImageBase()

 .../Include/Library/CpuExceptionHandlerLib.h   | 15 +++-
 .../CpuExceptionHandlerLibNull.c   | 16 -
 MdePkg/Include/Library/PeCoffGetEntryPointLib.h| 20 +-
 .../PeCoffGetEntryPoint.c  | 72 ++-
 .../DebugAgent/DebugAgentCommon/DebugAgent.c   | 50 ++---
 .../CpuExceptionHandlerLib/CpuExceptionCommon.c| 82 ++
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h| 27 ---
 .../Library/CpuExceptionHandlerLib/DxeException.c  |  7 +-
 .../Ia32/ArchExceptionHandler.c| 65 ++---
 .../CpuExceptionHandlerLib/PeiCpuException.c   |  6 +-
 .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c |  4 +-
 .../CpuExceptionHandlerLib/SecPeiCpuException.c|  8 +--
 .../Library/CpuExceptionHandlerLib/SmmException.c  |  7 +-
 .../X64/ArchExceptionHandler.c | 59 ++--
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 18 ++---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 37 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h |  6 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 18 ++---
 19 files changed, 268 insertions(+), 253 deletions(-)

-- 
2.9.3.windows.2

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

[edk2] [PATCH v2 1/5] MdePkg/PeCoffGetEntryPointLib: Add PeCoffSerachImageBase()

[Jeff Fan]

This new API only works on DEBUG build. It will search the PE/COFF image base
forward the input address in this PE/COFF image and returns it.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 MdePkg/Include/Library/PeCoffGetEntryPointLib.h| 20 +-
 .../PeCoffGetEntryPoint.c  | 72 +-
 2 files changed, 90 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/Library/PeCoffGetEntryPointLib.h 
b/MdePkg/Include/Library/PeCoffGetEntryPointLib.h
index e517ca2..647503b 100644
--- a/MdePkg/Include/Library/PeCoffGetEntryPointLib.h
+++ b/MdePkg/Include/Library/PeCoffGetEntryPointLib.h
@@ -1,7 +1,7 @@
 /** @file
   Provides a service to retrieve the PE/COFF entry point from a PE/COFF image.
 
-Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under 
 the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at
@@ -101,4 +101,22 @@ PeCoffGetSizeOfHeaders (
   IN VOID *Pe32Data
   );
 
+/**
+  Returns PE/COFF image base specified by the address in this PE/COFF image.
+
+  On DEBUG build, searches the PE/COFF image base forward the address in this
+  PE/COFF image and returns it.
+
+  @param  AddressAddress located in one PE/COFF image.
+
+  @retval 0  RELEASE build or cannot find the PE/COFF image base.
+  @retval others PE/COFF image base found.
+
+**/
+UINTN
+EFIAPI
+PeCoffSerachImageBase (
+  IN UINTNAddress
+  );
+
 #endif
diff --git a/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c 
b/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c
index 0fb7e84..00f6d7d 100644
--- a/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c
+++ b/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c
@@ -2,7 +2,7 @@
   Provides the services to get the entry point to a PE/COFF image that has 
either been 
   loaded into memory or is executing at it's linked address.
 
-  Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
   Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -22,6 +22,8 @@
 
 #include 
 
+#define PE_COFF_IMAGE_ALIGN_SIZE4
+
 /**
   Retrieves and returns a pointer to the entry point to a PE/COFF image that 
has been loaded
   into system memory with the PE/COFF Loader Library functions.
@@ -316,3 +318,71 @@ PeCoffGetSizeOfHeaders (
   return (UINT32) SizeOfHeaders;
 }
 
+/**
+  Returns PE/COFF image base is loaded in system memory where the input 
address is in.
+
+  On DEBUG build, searches the PE/COFF image base forward the input address and
+  returns it.
+
+  @param  AddressAddress located in one PE/COFF image.
+
+  @retval 0  RELEASE build or cannot find the PE/COFF image base.
+  @retval others PE/COFF image base found.
+
+**/
+UINTN
+EFIAPI
+PeCoffSerachImageBase (
+  IN UINTNAddress
+  )
+{
+  UINTNPe32Data;
+
+  Pe32Data = 0;
+
+  DEBUG_CODE (
+EFI_IMAGE_DOS_HEADER *DosHdr;
+EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION  Hdr;
+
+//
+// Find Image Base
+//
+Pe32Data = Address & ~(PE_COFF_IMAGE_ALIGN_SIZE - 1);
+while (Pe32Data != 0) {
+  DosHdr = (EFI_IMAGE_DOS_HEADER *) Pe32Data;
+  if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
+//
+// DOS image header is present, so read the PE header after the DOS 
image header.
+//
+Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)(Pe32Data + (UINTN) 
((DosHdr->e_lfanew) & 0x0));
+//
+// Make sure PE header address does not overflow and is less than the 
initial address.
+//
+if (((UINTN)Hdr.Pe32 > Pe32Data) && ((UINTN)Hdr.Pe32 < Address)) {
+  if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
+break;
+  }
+}
+  } else {
+//
+// DOS image header is not present, TE header is at the image base.
+//
+Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
+if ((Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) &&
+((Hdr.Te->Machine == IMAGE_FILE_MACHINE_I386)  || (Hdr.Te->Machine 
== IMAGE_FILE_MACHINE_IA64) ||
+ (Hdr.Te->Machine == IMAGE_FILE_MACHINE_EBC)   || (Hdr.Te->Machine 
== IMAGE_FILE_MACHINE_X64)  ||
+ (Hdr.Te->Machine == IMAGE_FILE_MACHINE_ARM64) || (Hdr.Te->Machine 
== IMAGE_FILE_MACHINE_ARMTHUMB_MIXED))
+ ) {
+  

[edk2] [PATCH v2 2/5] MdeModulePkg/CpuExceptionHandlerLib: Add DumpCpuContext()

[Jeff Fan]

This API is used to display exception type and all processor context for debug
purpose.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h| 15 ++-
 .../CpuExceptionHandlerLibNull.c | 16 +++-
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h 
b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
index b3016ee..6cd8230 100644
--- a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
+++ b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
@@ -2,7 +2,7 @@
   CPU Exception library provides the default CPU interrupt/exception handler.
   It also provides capability to register user interrupt/exception handler.
 
-  Copyright (c) 2012 - 2013, Intel Corporation. All rights reserved.
+  Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -93,4 +93,17 @@ RegisterCpuInterruptHandler (
   IN EFI_CPU_INTERRUPT_HANDLER InterruptHandler
   );
 
+/**
+  Display processor context.
+
+  @param[in] ExceptionType  Exception type.
+  @param[in] SystemContext  Processor context to be display.
+**/
+VOID
+EFIAPI
+DumpCpuContext (
+  IN EFI_EXCEPTION_TYPE   ExceptionType,
+  IN EFI_SYSTEM_CONTEXT   SystemContext
+  );
+  
 #endif
diff --git 
a/MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.c 
b/MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.c
index 68ee9a9..cbe4768 100644
--- 
a/MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.c
+++ 
b/MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.c
@@ -1,7 +1,7 @@
 /** @file
   CPU Exception Handler library implementition with empty functions.
 
-  Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -97,3 +97,17 @@ RegisterCpuInterruptHandler (
   return EFI_UNSUPPORTED;
 }
 
+/**
+  Display processor context.
+
+  @param[in] ExceptionType  Exception type.
+  @param[in] SystemContext  Processor context to be display.
+**/
+VOID
+EFIAPI
+DumpCpuContext (
+  IN EFI_EXCEPTION_TYPE   ExceptionType,
+  IN EFI_SYSTEM_CONTEXT   SystemContext
+  )
+{
+}
-- 
2.9.3.windows.2

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

[edk2] [PATCH v2 5/5] SourceLevelDebugPkg/DebugAgent.c: Consume PeCoffSerachImageBase()

[Jeff Fan]

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 .../DebugAgent/DebugAgentCommon/DebugAgent.c   | 50 +++---
 1 file changed, 6 insertions(+), 44 deletions(-)

diff --git 
a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c 
b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c
index edd0de1..6f3c419 100644
--- a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c
+++ b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c
@@ -4,7 +4,7 @@
   read/write debug packet to communication with HOST based on transfer
   protocol.
 
-  Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -201,55 +201,17 @@ FindAndReportModuleImageInfo (
   )
 {
   UINTNPe32Data;
-  EFI_IMAGE_DOS_HEADER *DosHdr;
-  EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION  Hdr;
   PE_COFF_LOADER_IMAGE_CONTEXT ImageContext;
 
   //
   // Find Image Base
   //
-  Pe32Data = ((UINTN)mErrorMsgVersionAlert) & ~(AlignSize - 1);
-  while (Pe32Data != 0) {
-DosHdr = (EFI_IMAGE_DOS_HEADER *) Pe32Data;
-if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
-  //
-  // DOS image header is present, so read the PE header after the DOS 
image header.
-  //
-  Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)(Pe32Data + (UINTN) 
((DosHdr->e_lfanew) & 0x0));
-  //
-  // Make sure PE header address does not overflow and is less than the 
initial address.
-  //
-  if (((UINTN)Hdr.Pe32 > Pe32Data) && ((UINTN)Hdr.Pe32 < 
(UINTN)mErrorMsgVersionAlert)) {
-if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
-  //
-  // It's PE image.
-  //
-  break;
-}
-  }
-} else {
-  //
-  // DOS image header is not present, TE header is at the image base.
-  //
-  Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
-  if ((Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) &&
-  ((Hdr.Te->Machine == IMAGE_FILE_MACHINE_I386) || Hdr.Te->Machine == 
IMAGE_FILE_MACHINE_X64)) {
-//
-// It's TE image, it TE header and Machine type match
-//
-break;
-  }
-}
-
-//
-// Not found the image base, check the previous aligned address
-//
-Pe32Data -= AlignSize;
+  Pe32Data = PeCoffSerachImageBase ((UINTN) mErrorMsgVersionAlert);
+  if (Pe32Data != 0) {
+ImageContext.ImageAddress = Pe32Data;
+ImageContext.PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN) 
ImageContext.ImageAddress);
+PeCoffLoaderRelocateImageExtraAction ();
   }
-
-  ImageContext.ImageAddress = Pe32Data;
-  ImageContext.PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN) 
ImageContext.ImageAddress);
-  PeCoffLoaderRelocateImageExtraAction ();
 }
 
 /**
-- 
2.9.3.windows.2

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

[edk2] [PATCH v2 3/5] UefiCpuPkg/CpuExceptionHandlerLib: Add DumpCpuContext() implementation

[Jeff Fan]

Export DumpCpuCotext() to display CPU Context. We will invoke
PeCoffGetEntrypointLib's PeCoffSerachImageBase() to get PE/COFF image base.
Display exception data bit value for page fault exception.

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 .../CpuExceptionHandlerLib/CpuExceptionCommon.c| 82 ++
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h| 27 ---
 .../Library/CpuExceptionHandlerLib/DxeException.c  |  7 +-
 .../Ia32/ArchExceptionHandler.c| 65 ++---
 .../CpuExceptionHandlerLib/PeiCpuException.c   |  6 +-
 .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c |  4 +-
 .../CpuExceptionHandlerLib/SecPeiCpuException.c|  8 +--
 .../Library/CpuExceptionHandlerLib/SmmException.c  |  7 +-
 .../X64/ArchExceptionHandler.c | 59 ++--
 9 files changed, 125 insertions(+), 140 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
index 3d85b0c..0537208 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
@@ -106,82 +106,44 @@ InternalPrintMessage (
 
 /**
   Find and display image base address and return image base and its entry 
point.
-
+  
   @param CurrentEip  Current instruction pointer.
-  @param EntryPoint  Return module entry point if module header is found.
-
-  @return !0 Image base address.
-  @return 0  Image header cannot be found.
+  
 **/
-UINTN
-FindModuleImageBase (
-  IN  UINTN  CurrentEip,
-  OUT UINTN  *EntryPoint
+VOID 
+DumpModuleImageInfo (
+  IN  UINTN  CurrentEip
   )
 {
+  EFI_STATUS   Status;
   UINTNPe32Data;
-  EFI_IMAGE_DOS_HEADER *DosHdr;
-  EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION  Hdr;
   VOID *PdbPointer;
+  VOID *EntryPoint;
 
-  //
-  // Find Image Base
-  //
-  Pe32Data = CurrentEip & ~(mImageAlignSize - 1);
-  while (Pe32Data != 0) {
-DosHdr = (EFI_IMAGE_DOS_HEADER *) Pe32Data;
-if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
-  //
-  // DOS image header is present, so read the PE header after the DOS 
image header.
-  //
-  Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)(Pe32Data + (UINTN) 
((DosHdr->e_lfanew) & 0x0));
-  //
-  // Make sure PE header address does not overflow and is less than the 
initial address.
-  //
-  if (((UINTN)Hdr.Pe32 > Pe32Data) && ((UINTN)Hdr.Pe32 < CurrentEip)) {
-if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
-  //
-  // It's PE image.
-  //
-  InternalPrintMessage (" Find PE image ");
-  *EntryPoint = (UINTN)Pe32Data + 
(UINTN)(Hdr.Pe32->OptionalHeader.AddressOfEntryPoint & 0x0);
-  break;
-}
-  }
-} else {
-  //
-  // DOS image header is not present, TE header is at the image base.
-  //
-  Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
-  if ((Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) &&
-  ((Hdr.Te->Machine == IMAGE_FILE_MACHINE_I386) || Hdr.Te->Machine == 
IMAGE_FILE_MACHINE_X64)) {
-//
-// It's TE image, it TE header and Machine type match
-//
-InternalPrintMessage (" Find TE image ");
-*EntryPoint = (UINTN)Pe32Data + (UINTN)(Hdr.Te->AddressOfEntryPoint & 
0x0) + sizeof(EFI_TE_IMAGE_HEADER) - Hdr.Te->StrippedSize;
-break;
-  }
-}
-
+  Pe32Data = PeCoffSerachImageBase (CurrentEip);
+  if (Pe32Data == 0) {
+InternalPrintMessage (" Can't find image information. \n");
+  } else {
 //
-// Not found the image base, check the previous aligned address
+// Find Image Base entry point
 //
-Pe32Data -= mImageAlignSize;
-  }
-
-  if (Pe32Data != 0) {
+Status = PeCoffLoaderGetEntryPoint ((VOID *) Pe32Data, );
+if (EFI_ERROR (Status)) {
+  EntryPoint = NULL;
+}
+InternalPrintMessage (" Find image ");
 PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *) Pe32Data);
 if (PdbPointer != NULL) {
   InternalPrintMessage ("%a", PdbPointer);
 } else {
   InternalPrintMessage ("(No PDB) " );
 }
-  } else {
-InternalPrintMessage (" Can't find image information. \n");
+InternalPrintMessage (
+  " (ImageBase=%016lp, EntryPoint=%016p) \n",
+  (VOID *) Pe32Data,
+  EntryPoint
+  );
   }
-
-  return Pe32Data;
 }
 
 /**
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 4639ed2..e66a5df 

Re: [edk2] [PATCH 0/9] Export Dump CPU Context service

[Yao, Jiewen]

Thank you!

From: Fan, Jeff
Sent: Friday, April 7, 2017 8:46 AM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Tian, Feng 

Subject: RE: [PATCH 0/9] Export Dump CPU Context service

Jiewen,

That's fine. If you consider the patch based on module for this case is better 
your review, I will combine some of them soon.

Thanks!
Jeff

From: Yao, Jiewen
Sent: Friday, April 07, 2017 8:41 AM
To: Fan, Jeff; edk2-devel@lists.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: RE: [PATCH 0/9] Export Dump CPU Context service

Hi
I do not think it is necessary to split this simple patch to so many.

It brings burden to me to review the change. For example, there are 4 patches 
for CpuExceptionHandlerLib.

Can we combine the patch based upon the module?

Thank you
Yao Jiewen


> -Original Message-
> From: Fan, Jeff
> Sent: Saturday, April 1, 2017 9:25 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen >; Kinney, 
> Michael D
> >; Tian, Feng 
> >
> Subject: [PATCH 0/9] Export Dump CPU Context service
>
> This serial of patches are:
> 1. Export PeCoffSerachImageBase() that could serach PE/COFF image base.
> 2. Export DumpCpuContext that could dump CPU context when exception
> happened.
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=242
>
> Cc: Jiewen Yao >
> Cc: Michael Kinney 
> >
> Cc: Feng Tian >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan >
>
> Jeff Fan (9):
>   MdePkg/PeCoffGetEntryPointLib: Add PeCoffSerachImageBase()
>   MdeModulePkg/CpuExceptionHandlerLib: Add DumpCpuContext()
>   UefiCpuPkg/CpuExceptionHandlerLib: Rename internal DumpCpuContent()
>   UefiCpuPkg/CpuExceptionHandlerLib: Add DumpModuleImageInfo()
>   UefiCpuPkg/CpuExceptionHandlerLib: Add DumpCpuContext()
> implementation
>   UefiCpuPkg/CpuExceptionHandlerLib: Display PF Excption Data bit
>   UefiCpuPkg/PiSmmCpuDxeSmm: Consume PeCoffSerachImageBase()
>   UefiCpuPkg/PiSmmCpuDxeSmm: Consume DumpCpuContext()
>   SourceLevelDebugPkg/DebugAgent.c: Consume PeCoffSerachImageBase()
>
>  .../Include/Library/CpuExceptionHandlerLib.h   | 15 -
>  .../CpuExceptionHandlerLibNull.c   | 16 -
>  MdePkg/Include/Library/PeCoffGetEntryPointLib.h| 20 +-
>  .../PeCoffGetEntryPoint.c  | 72
> -
>  .../DebugAgent/DebugAgentCommon/DebugAgent.c   | 50 ++-
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.c| 75
> ++
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.h| 27 +---
>  .../Library/CpuExceptionHandlerLib/DxeException.c  |  7 +-
>  .../Ia32/ArchExceptionHandler.c| 65
> ---
>  .../CpuExceptionHandlerLib/PeiCpuException.c   |  6 +-
>  .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c |  4 +-
>  .../CpuExceptionHandlerLib/SecPeiCpuException.c|  8 +--
>  .../Library/CpuExceptionHandlerLib/SmmException.c  |  7 +-
>  .../X64/ArchExceptionHandler.c | 57 ++--
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 18 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 37 +--
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  4 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h |  6 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 18 ++
>  19 files changed, 265 insertions(+), 247 deletions(-)
>
> --
> 2.9.3.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/9] Export Dump CPU Context service

[Fan, Jeff]

Jiewen,

That's fine. If you consider the patch based on module for this case is better 
your review, I will combine some of them soon.

Thanks!
Jeff

From: Yao, Jiewen
Sent: Friday, April 07, 2017 8:41 AM
To: Fan, Jeff; edk2-devel@lists.01.org
Cc: Kinney, Michael D; Tian, Feng
Subject: RE: [PATCH 0/9] Export Dump CPU Context service

Hi
I do not think it is necessary to split this simple patch to so many.

It brings burden to me to review the change. For example, there are 4 patches 
for CpuExceptionHandlerLib.

Can we combine the patch based upon the module?

Thank you
Yao Jiewen


> -Original Message-
> From: Fan, Jeff
> Sent: Saturday, April 1, 2017 9:25 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen >; Kinney, 
> Michael D
> >; Tian, Feng 
> >
> Subject: [PATCH 0/9] Export Dump CPU Context service
>
> This serial of patches are:
> 1. Export PeCoffSerachImageBase() that could serach PE/COFF image base.
> 2. Export DumpCpuContext that could dump CPU context when exception
> happened.
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=242
>
> Cc: Jiewen Yao >
> Cc: Michael Kinney 
> >
> Cc: Feng Tian >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan >
>
> Jeff Fan (9):
>   MdePkg/PeCoffGetEntryPointLib: Add PeCoffSerachImageBase()
>   MdeModulePkg/CpuExceptionHandlerLib: Add DumpCpuContext()
>   UefiCpuPkg/CpuExceptionHandlerLib: Rename internal DumpCpuContent()
>   UefiCpuPkg/CpuExceptionHandlerLib: Add DumpModuleImageInfo()
>   UefiCpuPkg/CpuExceptionHandlerLib: Add DumpCpuContext()
> implementation
>   UefiCpuPkg/CpuExceptionHandlerLib: Display PF Excption Data bit
>   UefiCpuPkg/PiSmmCpuDxeSmm: Consume PeCoffSerachImageBase()
>   UefiCpuPkg/PiSmmCpuDxeSmm: Consume DumpCpuContext()
>   SourceLevelDebugPkg/DebugAgent.c: Consume PeCoffSerachImageBase()
>
>  .../Include/Library/CpuExceptionHandlerLib.h   | 15 -
>  .../CpuExceptionHandlerLibNull.c   | 16 -
>  MdePkg/Include/Library/PeCoffGetEntryPointLib.h| 20 +-
>  .../PeCoffGetEntryPoint.c  | 72
> -
>  .../DebugAgent/DebugAgentCommon/DebugAgent.c   | 50 ++-
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.c| 75
> ++
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.h| 27 +---
>  .../Library/CpuExceptionHandlerLib/DxeException.c  |  7 +-
>  .../Ia32/ArchExceptionHandler.c| 65
> ---
>  .../CpuExceptionHandlerLib/PeiCpuException.c   |  6 +-
>  .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c |  4 +-
>  .../CpuExceptionHandlerLib/SecPeiCpuException.c|  8 +--
>  .../Library/CpuExceptionHandlerLib/SmmException.c  |  7 +-
>  .../X64/ArchExceptionHandler.c | 57 ++--
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 18 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 37 +--
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  4 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h |  6 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 18 ++
>  19 files changed, 265 insertions(+), 247 deletions(-)
>
> --
> 2.9.3.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/9] Export Dump CPU Context service

[Yao, Jiewen]

Hi
I do not think it is necessary to split this simple patch to so many.

It brings burden to me to review the change. For example, there are 4 patches 
for CpuExceptionHandlerLib.

Can we combine the patch based upon the module?

Thank you
Yao Jiewen


> -Original Message-
> From: Fan, Jeff
> Sent: Saturday, April 1, 2017 9:25 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Kinney, Michael D
> ; Tian, Feng 
> Subject: [PATCH 0/9] Export Dump CPU Context service
>
> This serial of patches are:
> 1. Export PeCoffSerachImageBase() that could serach PE/COFF image base.
> 2. Export DumpCpuContext that could dump CPU context when exception
> happened.
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=242
>
> Cc: Jiewen Yao 
> Cc: Michael Kinney 
> Cc: Feng Tian 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan 
>
> Jeff Fan (9):
>   MdePkg/PeCoffGetEntryPointLib: Add PeCoffSerachImageBase()
>   MdeModulePkg/CpuExceptionHandlerLib: Add DumpCpuContext()
>   UefiCpuPkg/CpuExceptionHandlerLib: Rename internal DumpCpuContent()
>   UefiCpuPkg/CpuExceptionHandlerLib: Add DumpModuleImageInfo()
>   UefiCpuPkg/CpuExceptionHandlerLib: Add DumpCpuContext()
> implementation
>   UefiCpuPkg/CpuExceptionHandlerLib: Display PF Excption Data bit
>   UefiCpuPkg/PiSmmCpuDxeSmm: Consume PeCoffSerachImageBase()
>   UefiCpuPkg/PiSmmCpuDxeSmm: Consume DumpCpuContext()
>   SourceLevelDebugPkg/DebugAgent.c: Consume PeCoffSerachImageBase()
>
>  .../Include/Library/CpuExceptionHandlerLib.h   | 15 -
>  .../CpuExceptionHandlerLibNull.c   | 16 -
>  MdePkg/Include/Library/PeCoffGetEntryPointLib.h| 20 +-
>  .../PeCoffGetEntryPoint.c  | 72
> -
>  .../DebugAgent/DebugAgentCommon/DebugAgent.c   | 50 ++-
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.c| 75
> ++
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.h| 27 +---
>  .../Library/CpuExceptionHandlerLib/DxeException.c  |  7 +-
>  .../Ia32/ArchExceptionHandler.c| 65
> ---
>  .../CpuExceptionHandlerLib/PeiCpuException.c   |  6 +-
>  .../CpuExceptionHandlerLib/PeiDxeSmmCpuException.c |  4 +-
>  .../CpuExceptionHandlerLib/SecPeiCpuException.c|  8 +--
>  .../Library/CpuExceptionHandlerLib/SmmException.c  |  7 +-
>  .../X64/ArchExceptionHandler.c | 57 ++--
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 18 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 37 +--
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  4 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h |  6 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 18 ++
>  19 files changed, 265 insertions(+), 247 deletions(-)
>
> --
> 2.9.3.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] NetworkPkg: Fix bug related DAD issue in IP6 driver.

[Wu, Jiaxin]

Reviewed-by: Wu Jiaxin 


Thanks,
Jiaxin


> -Original Message-
> From: Zhang, Lubo
> Sent: Thursday, April 6, 2017 4:58 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Ye, Ting ; Fu,
> Siyuan 
> Subject: [patch] NetworkPkg: Fix bug related DAD issue in IP6 driver.
> 
> If we set PXEv6 as the first boot option and reboot immediately
> after the first successful boot, it will assert. the root cause is
> when we set the policy from manual to automatic in PXE driver,
> the ip6 Configure item size is already set to zero and other
> structures are also released, So it is not needed to perform DAD call
> back function which is invoked by Ip6ConfigSetMaunualAddress.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> Cc: Wu Jiaxin 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> ---
>  NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> index bde5982..7575b79 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> +++ b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
> @@ -782,10 +782,14 @@ Ip6ManualAddrDadCallback (
>Instance   = (IP6_CONFIG_INSTANCE *) Context;
>NET_CHECK_SIGNATURE (Instance, IP6_CONFIG_INSTANCE_SIGNATURE);
>Item   = >DataItem[Ip6ConfigDataTypeManualAddress];
>ManualAddr = NULL;
> 
> +  if (Item->DataSize == 0) {
> +return;
> +  }
> +
>for (Index = 0; Index < Item->DataSize / sizeof
> (EFI_IP6_CONFIG_MANUAL_ADDRESS); Index++) {
>  //
>  // Find the original tag used to place into the NET_MAP.
>  //
>  ManualAddr = Item->Data.ManualAddress + Index;
> --
> 1.9.5.msysgit.1

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

[edk2] [edk2-FdfSpecification PATCH] Add missing EBNF definition for

[Michael Kinney]

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

GitHub branch for review:

  
https://github.com/mdkinney/edk2-FdfSpecification/tree/Bugzilla_249_AddUiFmpName
  
GitHub branch compare against latest DRAFT for review:

  
https://github.com/tianocore-docs/edk2-FdfSpecification/compare/master...mdkinney:Bugzilla_249_AddUiFmpName?w=1

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  Add missing EBNF definition for 

 3_edk_ii_fdf_file_format/37_[capsule]_sections.md| 1 +
 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 3 ++-
 README.md| 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

-- 
2.6.3.windows.1

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

[edk2] [edk2-FdfSpecification PATCH] Add missing EBNF definition for

[Michael Kinney]

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

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 3_edk_ii_fdf_file_format/37_[capsule]_sections.md| 1 +
 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 3 ++-
 README.md| 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/3_edk_ii_fdf_file_format/37_[capsule]_sections.md 
b/3_edk_ii_fdf_file_format/37_[capsule]_sections.md
index c912b40..c2aedba 100644
--- a/3_edk_ii_fdf_file_format/37_[capsule]_sections.md
+++ b/3_edk_ii_fdf_file_format/37_[capsule]_sections.md
@@ -304,6 +304,7 @@ Conditional statements may be used anywhere within this 
section.
::= "SECTION"  [] "SMM_DEPEX_EXP"
  "{" []  "}" 
 ::=  "FMP_PAYLOAD"   
+ ::= 
   ::=  "FILE"  "DATA"   
 ```
 
diff --git a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md 
b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
index 1c38f59..31e1166 100644
--- a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
+++ b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
@@ -37,9 +37,10 @@ Capsule files.
  Prototype
 
 ```c
-  ::= "[FmpPayload"  "]" 
+  ::= "[FmpPayload" "."  "]" 
   
   
+   ::= 
::= [ "IMAGE_HEADER_INIT_VERSION"   ]
"IMAGE_TYPE_ID"   
   [ "IMAGE_INDEX"   ]
diff --git a/README.md b/README.md
index 9a7f13a..1c9b315 100644
--- a/README.md
+++ b/README.md
@@ -196,3 +196,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || Clarified [UserExtensions] content in chapter 2 (to match 
implementation) 
 |   |
 | 1.28   | Convert to GitBooks 

   | March 2017|
 || [#426](https://bugzilla.tianocore.org/show_bug.cgi?id=426) 
IMAGE_TYPE_ID must be provided with value, FDF should mark it as required 
section   |   |
+|| [#249](https://bugzilla.tianocore.org/show_bug.cgi?id=249) FDF 
spec miss '' definition  
|   |
-- 
2.6.3.windows.1

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

Re: [edk2] Pull in pre-built library during edk2 build?

[Laszlo Ersek]

On 04/07/17 00:46, Laszlo Ersek wrote:

> 0001-ExternalSslPkg-create-INF-files-for-OpensslLib-binar.patch
> 
> 
> From 4672a027f54c54574129f9c9cc947c80f7bc4d9f Mon Sep 17 00:00:00 2001
> From: Laszlo Ersek 
> Date: Thu, 6 Apr 2017 22:56:04 +0200
> Subject: [PATCH] ExternalSslPkg: create INF files for OpensslLib binaries
> 
> Signed-off-by: Laszlo Ersek
> ---
>  .../Library/OpensslLib/OpensslLibBin.inf   | 33 
> ++
>  .../Library/OpensslLib/OpensslLibBinCrypto.inf | 33 
> ++
>  2 files changed, 66 insertions(+)
>  create mode 100644 ExternalSslPkg/Library/OpensslLib/OpensslLibBin.inf
>  create mode 100644 ExternalSslPkg/Library/OpensslLib/OpensslLibBinCrypto.inf
> 
> diff --git a/ExternalSslPkg/Library/OpensslLib/OpensslLibBin.inf 
> b/ExternalSslPkg/Library/OpensslLib/OpensslLibBin.inf
> new file mode 100644
> index ..703fddb47606
> --- /dev/null
> +++ b/ExternalSslPkg/Library/OpensslLib/OpensslLibBin.inf
> @@ -0,0 +1,33 @@
> +## @file
> +#  This module provides binary OpenSSL Library implementation.
> +#
> +#  Copyright (C) 2017, Red Hat, Inc.
> +#  Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
> +#  This program and the accompanying materials are licensed and made 
> available
> +#  under the terms and conditions of the BSD License which accompanies this
> +#  distribution.  The full text of the license may be found at
> +#  http://opensource.org/licenses/bsd-license.php
> +#
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> +#  IMPLIED.
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 1.25
> +  BASE_NAME  = OpensslLibBin
> +  FILE_GUID  = d0d4d4cf-460c-4752-9c9b-6d821b2ffe49
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = OpensslLib
> +
> +[Binaries.IA32]
> +  LIB|DEBUG/IA32/OpensslLib.lib|DEBUG
> +  LIB|NOOPT/IA32/OpensslLib.lib|NOOPT
> +  LIB|RELEASE/IA32/OpensslLib.lib|RELEASE
> +
> +[Binaries.X64]
> +  LIB|DEBUG/X64/OpensslLib.lib|DEBUG
> +  LIB|NOOPT/X64/OpensslLib.lib|NOOPT
> +  LIB|RELEASE/X64/OpensslLib.lib|RELEASE

I submitted , so
that the next version of the INF spec

document the LIB file type as well, for the [Binaries] sections of INF
files that belong to library instances.

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

Re: [edk2] Pull in pre-built library during edk2 build?

[Laszlo Ersek]

On 04/06/17 20:07, Peter Hornyack wrote:
> I'd like to make an adjustment to the edk2 build (locally, not for
> upstream) and I'm hoping someone can offer some guidance.
> 
> My goal is to pre-build an edk2 library in a separate build process,
> then pull that library into the full build later on. Specifically I'm
> building my firmware image using OvmfPkgX64.dsc, but I want to build
> OpensslLib (CryptoPkg/Library/OpensslLib/OpensslLib.inf) in advance,
> then pull the resulting lib into the full build later. How can I
> achieve this?
> 
> In my build output I can see that when OpensslLib.inf is built, all of
> the openssl .c files are compiled into .obj files, then an ar command
> wraps those up into OpensslLib.lib. I want to pull those steps out and
> pre-build OpensslLib.lib, but I've been unable to find where/how the
> edk2 build grabs that .lib file and turns it into the final firmware
> image. I've reviewed the edk2 build documentation but still can't
> figure this out. Can anyone point me to the right place in the edk2
> build files where I can make this happen? Or perhaps is there an
> example of this already in the edk2 build that I can imitate?

(1) Apply the attached patch

  OvmfPkg: add USE_EXTERNAL_OPENSSL for external, binary OpenSSL

in your edk2 clone.

(Don't forget to pass --keep-cr to git-am.)

(2) Create a new directory somewhere, initialize it as a git repository,
and apply the attached patch

  ExternalSslPkg: create INF files for OpensslLib binaries

in it:

  export EXTERNAL_OPENSSL_DIR=...
  mkdir -pv -- "$EXTERNAL_OPENSSL_DIR"
  cd "$EXTERNAL_OPENSSL_DIR"
  git init
  git am --keep-cr ...

(3) Set another variable (customize as necessary):

  export TOOLCHAIN=GCC48

(4) Go to your normal edk2 clone, and run the following commands, for
initially building the OpenSSL binaries only, and installing them. This
assumes that OpenSSL has been embedded in the edk2 tree, as directed by

  CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt

This step has to be done only once.

  (
ARCH_ID=(IA32 X64)
ARCH_NAME=(Ia32 X64)

SSL_FLAVOR=("" Crypto)
SSL_TLS=(TRUE FALSE)

SSLD=CryptoPkg/Library/OpensslLib
source edksetup.sh
set -e -u -C -x
make -C "$EDK_TOOLS_PATH"

for TARGET in DEBUG NOOPT RELEASE; do
  for ((ARCH_IDX=0; ARCH_IDX < ${#ARCH_ID[@]}; ARCH_IDX++)); do
for ((SSL_IDX=0; SSL_IDX < ${#SSL_FLAVOR[@]}; SSL_IDX++)); do

  build \
--arch="${ARCH_ID[ARCH_IDX]}" \
--platform="OvmfPkg/OvmfPkg${ARCH_NAME[ARCH_IDX]}.dsc" \
--module="$SSLD/OpensslLib${SSL_FLAVOR[SSL_IDX]}.inf" \
--buildtarget="$TARGET" \
--tagname="$TOOLCHAIN" \
--define=TLS_ENABLE="${SSL_TLS[SSL_IDX]}"

  LIBF="Build/Ovmf${ARCH_NAME[ARCH_IDX]}/${TARGET}_${TOOLCHAIN}"
  LIBF="$LIBF/${ARCH_ID[ARCH_IDX]}"
  LIBF="$LIBF/$SSLD/OpensslLib${SSL_FLAVOR[SSL_IDX]}"
  LIBF="$LIBF/OUTPUT/OpensslLib${SSL_FLAVOR[SSL_IDX]}.lib"

  DSTF="$EXTERNAL_OPENSSL_DIR/ExternalSslPkg/Library/OpensslLib"
  DSTF="$DSTF/$TARGET/${ARCH_ID[ARCH_IDX]}"
  DSTF="$DSTF/OpensslLib${SSL_FLAVOR[SSL_IDX]}.lib"

  install -m 0644 -D -- "$LIBF" "$DSTF"
done
  done
done

rm -r Build
  )

At the end of this step, the binaries will be available under
$EXTERNAL_OPENSSL_DIR, in addition to the INF files from step (2):

  ExternalSslPkg/Library/OpensslLib/DEBUG/IA32/OpensslLib.lib
  ExternalSslPkg/Library/OpensslLib/DEBUG/IA32/OpensslLibCrypto.lib
  ExternalSslPkg/Library/OpensslLib/DEBUG/X64/OpensslLib.lib
  ExternalSslPkg/Library/OpensslLib/DEBUG/X64/OpensslLibCrypto.lib
  ExternalSslPkg/Library/OpensslLib/NOOPT/IA32/OpensslLib.lib
  ExternalSslPkg/Library/OpensslLib/NOOPT/IA32/OpensslLibCrypto.lib
  ExternalSslPkg/Library/OpensslLib/NOOPT/X64/OpensslLib.lib
  ExternalSslPkg/Library/OpensslLib/NOOPT/X64/OpensslLibCrypto.lib
  ExternalSslPkg/Library/OpensslLib/OpensslLibBin.inf
  ExternalSslPkg/Library/OpensslLib/OpensslLibBinCrypto.inf
  ExternalSslPkg/Library/OpensslLib/RELEASE/IA32/OpensslLib.lib
  ExternalSslPkg/Library/OpensslLib/RELEASE/IA32/OpensslLibCrypto.lib
  ExternalSslPkg/Library/OpensslLib/RELEASE/X64/OpensslLib.lib
  ExternalSslPkg/Library/OpensslLib/RELEASE/X64/OpensslLibCrypto.lib

If you wish, you can add and commit the lib files to the repository, or
save them for later by other means. Either case they have to stick
together with the INF files.

(5) Now build OVMF against the external libraries.

For this, we use PACKAGES_PATH (see
).

Also note -D USE_EXTERNAL_OPENSSL in COMMON_OPTS, which utilizes the
patch from step (1).

This step can be repeated as many times as necessary. Two builds are
included below as examples.

  (
export PACKAGES_PATH="$EXTERNAL_OPENSSL_DIR"
source edksetup.sh

COMMON_OPTS="-t GCC48 -n 12 -D USE_EXTERNAL_OPENSSL -D SMM_REQUIRE"

[edk2] [edk2-FdfSpecification PATCH] Fix conditional statement examples

[Michael Kinney]

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

* Removge space between !if and else
* Add $() around BARFOO

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_fdf_design_discussion/22_flash_description_file_format.md | 4 ++--
 README.md   | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/2_fdf_design_discussion/22_flash_description_file_format.md 
b/2_fdf_design_discussion/22_flash_description_file_format.md
index 9c993f4..dfbd889 100644
--- a/2_fdf_design_discussion/22_flash_description_file_format.md
+++ b/2_fdf_design_discussion/22_flash_description_file_format.md
@@ -600,7 +600,7 @@ The following is an example of conditional statements.
 ```ini
 !if ("MSFT" in $(FAMILY)) or ("INTEL" in $(FAMILY))
 ... statements
-!else if $(FAMILY) == "GCC"
+!elseif $(FAMILY) == "GCC"
 ... statements
 !endif
 
@@ -610,7 +610,7 @@ The following is an example of conditional statements.
   !else
 # FOO defined, BAR is defined
   !endif
-!elseif BARFOO
+!elseif $(BARFOO)
   # FOO is not defined, BARFOO is defined as TRUE
 !elseif $(BARFOO) == "FOOBAR"
   # FOO is not defined, BARFOO is defined as FOOBAR
diff --git a/README.md b/README.md
index 9a7f13a..74269dc 100644
--- a/README.md
+++ b/README.md
@@ -196,3 +196,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || Clarified [UserExtensions] content in chapter 2 (to match 
implementation) 
 |   |
 | 1.28   | Convert to GitBooks 

   | March 2017|
 || [#426](https://bugzilla.tianocore.org/show_bug.cgi?id=426) 
IMAGE_TYPE_ID must be provided with value, FDF should mark it as required 
section   |   |
+|| [#373](https://bugzilla.tianocore.org/show_bug.cgi?id=373) 
Conditional statement examples incorrect
|   |
-- 
2.6.3.windows.1

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

[edk2] [edk2-FdfSpecification PATCH] Fix conditional statement examples

[Michael Kinney]

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

* Removge space between !if and else
* Add $() around BARFOO

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

GitHub branch for review:

  
https://github.com/mdkinney/edk2-FdfSpecification/tree/Bugzilla_373_FixConditionExamples
  
GitHub branch compare against latest DRAFT for review:

  
https://github.com/tianocore-docs/edk2-FdfSpecification/compare/master...mdkinney:Bugzilla_373_FixConditionExamples?w=1

Michael Kinney (1):
  Fix conditional statement examples

 2_fdf_design_discussion/22_flash_description_file_format.md | 4 ++--
 README.md   | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

-- 
2.6.3.windows.1

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

Re: [edk2] How to get fs index from controller handle.

[Carsey, Jaben]

Andrew,

I was assuming not wanting ShellExecute()  might extend to the rest of the 
shell.

If the shell is in use, that can definitely help. While those 2 APIs do exist 
in theory, there is a single one that does all I think: 
GetDevicePathFromFilePath.

-Jaben


From: af...@apple.com [mailto:af...@apple.com]
Sent: Thursday, April 06, 2017 1:49 PM
To: Carsey, Jaben 
Cc: Amit kumar ; edk2-devel@lists.01.org
Subject: Re: [edk2] How to get fs index from controller handle.
Importance: High


On Apr 6, 2017, at 1:30 PM, Carsey, Jaben 
> wrote:

That's the way to do it.  the hard work is around finding the DevicePath for 
the application you want to run to pass to LoadImage.


Jaben,

It was easy in the old days.

DevPath  = gSE2->NameToPath (ShellPathName);
gSE2->GetFsName (DevPath, FALSE, & ShellPathName);

Maybe we should default EFI_SHELL_ENVIRONMENT2 to on :)? Half joking.

I used those 2 APIs in the past to glue in shell volume names to a really 
simplistic C lib.

Also if you have the File System Handle and path you can use the DevicePathLib.

/**
  Allocates a device path for a file and appends it to an existing device path.

  If Device is a valid device handle that contains a device path protocol, then 
a device path for
  the file specified by FileName  is allocated and appended to the device path 
associated with the
  handle Device.  The allocated device path is returned.  If Device is NULL or 
Device is a handle
  that does not support the device path protocol, then a device path containing 
a single device
  path node for the file specified by FileName is allocated and returned.
  The memory for the new device path is allocated from EFI boot services 
memory. It is the responsibility
  of the caller to free the memory allocated.

  If FileName is NULL, then ASSERT().
  If FileName is not aligned on a 16-bit boundary, then ASSERT().

  @param  Device A pointer to a device handle.  This 
parameter is optional and
 may be NULL.
  @param  FileName   A pointer to a Null-terminated Unicode 
string.

  @return The allocated device path.

**/
EFI_DEVICE_PATH_PROTOCOL *
EFIAPI
FileDevicePath (
  IN EFI_HANDLE  Device, OPTIONAL
  IN CONST CHAR16*FileName
  );


Thanks,

Andrew Fish


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Amit kumar
Sent: Thursday, April 06, 2017 9:45 AM
To: Andrew Fish >
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] How to get fs index from controller handle.
Importance: High

Hi,


Can i use gbs->loadimage() and gbs->startimage() to load an efi application
and execute it.

Suppose i have a app1.efi and from app1.efi i want to execute app2.efi.

Or is there some other way to do it ?

Not considering ShellExecute();

Amit


From: af...@apple.com 
> on behalf of Andrew Fish
>
Sent: Thursday, April 6, 2017 4:39:22 PM
To: Amit kumar
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] How to get fs index from controller handle.


On Apr 6, 2017, at 3:30 AM, Amit kumar
>
 wrote:

Hi,

I want to get the fs index from the controller handle.
e.g In map command i see my controller is mapped to fs10.
So i there any API i can use in my code to get the fs index( which is 10 as in
example) from the controller handle.


Amit,

It is important to remember that fs0:, and the other device names are a Shell
concept and not an EFI concept. So they only exist in the context of the shell.

I took a quick look and I did not see an easy way to do this with the current
Shell APIs.

In the older Shell you could use this  protocol  EfiShellEnvironment2 Protocol
has a function that converts a EFI_DEVICE_PATH_PROTOCOL (would be on
your controller handle) to a CHAR16. Thus you can get the volume name the
Shell would display to the user. I don't the index exists as a concept.  So
EFI_SHELL_ENVIRONMENT2.GetFsName() and
EFI_SHELL_ENVIRONMENT2.GetFsDevicepath() are the closest thing I can
think of.
https://github.com/tianocore/edk2/blob/master/ShellPkg/Include/Protocol/
EfiShellEnvironment2.h#L812

The only problem with that is EfiShellEnvironment2 is not produced by the
Shell by default.

 ## This flag is used to control the protocols produced by the shell
 #  If TRUE the shell will produce EFI_SHELL_ENVIRONMENT2 and
EFI_SHELL_INTERFACE

gEfiShellPkgTokenSpaceGuid.PcdShellSupportOldProtocols|FALSE|BOOLEAN
|0x0002

I've use the EFI_SHELL_ENVIRONMENT2 in the past to enable a non Shell
application to print out volume names that match 

Re: [edk2] How to get fs index from controller handle.

[Andrew Fish]

> On Apr 6, 2017, at 1:30 PM, Carsey, Jaben  wrote:
> 
> That's the way to do it.  the hard work is around finding the DevicePath for 
> the application you want to run to pass to LoadImage.
> 

Jaben,

It was easy in the old days.

DevPath  = gSE2->NameToPath (ShellPathName);
gSE2->GetFsName (DevPath, FALSE, & ShellPathName);

Maybe we should default EFI_SHELL_ENVIRONMENT2 to on :)? Half joking. 

I used those 2 APIs in the past to glue in shell volume names to a really 
simplistic C lib. 

Also if you have the File System Handle and path you can use the DevicePathLib.

/**
  Allocates a device path for a file and appends it to an existing device path.

  If Device is a valid device handle that contains a device path protocol, then 
a device path for
  the file specified by FileName  is allocated and appended to the device path 
associated with the
  handle Device.  The allocated device path is returned.  If Device is NULL or 
Device is a handle
  that does not support the device path protocol, then a device path containing 
a single device
  path node for the file specified by FileName is allocated and returned.
  The memory for the new device path is allocated from EFI boot services 
memory. It is the responsibility
  of the caller to free the memory allocated.
  
  If FileName is NULL, then ASSERT().
  If FileName is not aligned on a 16-bit boundary, then ASSERT().

  @param  Device A pointer to a device handle.  This 
parameter is optional and
 may be NULL.
  @param  FileName   A pointer to a Null-terminated Unicode 
string.

  @return The allocated device path.

**/
EFI_DEVICE_PATH_PROTOCOL *
EFIAPI
FileDevicePath (
  IN EFI_HANDLE  Device, OPTIONAL
  IN CONST CHAR16*FileName
  );


Thanks,

Andrew Fish

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org 
>> ] On Behalf Of
>> Amit kumar
>> Sent: Thursday, April 06, 2017 9:45 AM
>> To: Andrew Fish >
>> Cc: edk2-devel@lists.01.org 
>> Subject: Re: [edk2] How to get fs index from controller handle.
>> Importance: High
>> 
>> Hi,
>> 
>> 
>> Can i use gbs->loadimage() and gbs->startimage() to load an efi application
>> and execute it.
>> 
>> Suppose i have a app1.efi and from app1.efi i want to execute app2.efi.
>> 
>> Or is there some other way to do it ?
>> 
>> Not considering ShellExecute();
>> 
>> Amit
>> 
>> 
>> From: af...@apple.com  > > on behalf of Andrew Fish
>> >
>> Sent: Thursday, April 6, 2017 4:39:22 PM
>> To: Amit kumar
>> Cc: edk2-devel@lists.01.org 
>> Subject: Re: [edk2] How to get fs index from controller handle.
>> 
>> 
>> On Apr 6, 2017, at 3:30 AM, Amit kumar
>> > > >> wrote:
>> 
>> Hi,
>> 
>> I want to get the fs index from the controller handle.
>> e.g In map command i see my controller is mapped to fs10.
>> So i there any API i can use in my code to get the fs index( which is 10 as 
>> in
>> example) from the controller handle.
>> 
>> 
>> Amit,
>> 
>> It is important to remember that fs0:, and the other device names are a Shell
>> concept and not an EFI concept. So they only exist in the context of the 
>> shell.
>> 
>> I took a quick look and I did not see an easy way to do this with the current
>> Shell APIs.
>> 
>> In the older Shell you could use this  protocol  EfiShellEnvironment2 
>> Protocol
>> has a function that converts a EFI_DEVICE_PATH_PROTOCOL (would be on
>> your controller handle) to a CHAR16. Thus you can get the volume name the
>> Shell would display to the user. I don't the index exists as a concept.  So
>> EFI_SHELL_ENVIRONMENT2.GetFsName() and
>> EFI_SHELL_ENVIRONMENT2.GetFsDevicepath() are the closest thing I can
>> think of.
>> https://github.com/tianocore/edk2/blob/master/ShellPkg/Include/Protocol/ 
>> 
>> EfiShellEnvironment2.h#L812
>> 
>> The only problem with that is EfiShellEnvironment2 is not produced by the
>> Shell by default.
>> 
>>  ## This flag is used to control the protocols produced by the shell
>>  #  If TRUE the shell will produce EFI_SHELL_ENVIRONMENT2 and
>> EFI_SHELL_INTERFACE
>> 
>> gEfiShellPkgTokenSpaceGuid.PcdShellSupportOldProtocols|FALSE|BOOLEAN
>> |0x0002
>> 
>> I've use the EFI_SHELL_ENVIRONMENT2 in the past to enable a non Shell
>> application to print out volume names that match the map command of the
>> shell. Hopefully some one knows how to do this in the modern Shell?
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> Regards
>> Amit
>> 

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

[Ard Biesheuvel]

On 6 April 2017 at 19:29, Leif Lindholm  wrote:
> On Thu, Apr 06, 2017 at 02:15:46PM +0100, Ard Biesheuvel wrote:
>> As reported by Jeremy, the recently introduced accelerated memcpy/memset
>> routines are causing problems when used on framebuffer memory. While
>> framebuffers are arguably right on the blurry line between MMIO (with
>> side effects that are sensitive to ordering) and memory, mapping VRAM
>> as device memory is unnecessary to begin with, and so we can improve
>> our situation by using memory semantics for the VRAM mappings. (Whether
>> we end up reverting to the unaccelerated memcpy/memset routines is a
>> separate matter)
>>
>> So fix both the FVP case, which has a separate VRAM region, and TC2, which
>> allocates VRAM from normal memory and changes the mapping attributes.
>
> For 2-5/5:
> Reviewed-by: Leif Lindholm 
>

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

Re: [edk2] How to get fs index from controller handle.

[Carsey, Jaben]

That's the way to do it.  the hard work is around finding the DevicePath for 
the application you want to run to pass to LoadImage.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Amit kumar
> Sent: Thursday, April 06, 2017 9:45 AM
> To: Andrew Fish 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] How to get fs index from controller handle.
> Importance: High
> 
> Hi,
> 
> 
> Can i use gbs->loadimage() and gbs->startimage() to load an efi application
> and execute it.
> 
> Suppose i have a app1.efi and from app1.efi i want to execute app2.efi.
> 
> Or is there some other way to do it ?
> 
> Not considering ShellExecute();
> 
> Amit
> 
> 
> From: af...@apple.com  on behalf of Andrew Fish
> 
> Sent: Thursday, April 6, 2017 4:39:22 PM
> To: Amit kumar
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] How to get fs index from controller handle.
> 
> 
> On Apr 6, 2017, at 3:30 AM, Amit kumar
> > wrote:
> 
> Hi,
> 
> I want to get the fs index from the controller handle.
> e.g In map command i see my controller is mapped to fs10.
> So i there any API i can use in my code to get the fs index( which is 10 as in
> example) from the controller handle.
> 
> 
> Amit,
> 
> It is important to remember that fs0:, and the other device names are a Shell
> concept and not an EFI concept. So they only exist in the context of the 
> shell.
> 
> I took a quick look and I did not see an easy way to do this with the current
> Shell APIs.
> 
> In the older Shell you could use this  protocol  EfiShellEnvironment2 Protocol
> has a function that converts a EFI_DEVICE_PATH_PROTOCOL (would be on
> your controller handle) to a CHAR16. Thus you can get the volume name the
> Shell would display to the user. I don't the index exists as a concept.  So
> EFI_SHELL_ENVIRONMENT2.GetFsName() and
> EFI_SHELL_ENVIRONMENT2.GetFsDevicepath() are the closest thing I can
> think of.
> https://github.com/tianocore/edk2/blob/master/ShellPkg/Include/Protocol/
> EfiShellEnvironment2.h#L812
> 
> The only problem with that is EfiShellEnvironment2 is not produced by the
> Shell by default.
> 
>   ## This flag is used to control the protocols produced by the shell
>   #  If TRUE the shell will produce EFI_SHELL_ENVIRONMENT2 and
> EFI_SHELL_INTERFACE
> 
> gEfiShellPkgTokenSpaceGuid.PcdShellSupportOldProtocols|FALSE|BOOLEAN
> |0x0002
> 
> I've use the EFI_SHELL_ENVIRONMENT2 in the past to enable a non Shell
> application to print out volume names that match the map command of the
> shell. Hopefully some one knows how to do this in the modern Shell?
> 
> Thanks,
> 
> Andrew Fish
> 
> Regards
> Amit
> ___
> 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 v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

[Leif Lindholm]

On Thu, Apr 06, 2017 at 09:01:57PM +0100, Ard Biesheuvel wrote:
> On 6 April 2017 at 20:06, Leif Lindholm  wrote:
> > On Thu, Apr 06, 2017 at 07:46:50PM +0100, Ard Biesheuvel wrote:
> >> >> >> +  // VRAM
> >> >> >> +  VirtualMemoryTable[++Index].PhysicalBase = 
> >> >> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
> >> >> >> +  VirtualMemoryTable[Index].VirtualBase = 
> >> >> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
> >> >> >> +  VirtualMemoryTable[Index].Length = 
> >> >> >> PL111_CLCD_VRAM_MOTHERBOARD_SIZE;
> >> >> >> +  VirtualMemoryTable[Index].Attributes = 
> >> >> >> ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
> >> >> >
> >> >> > Hmm, looking at this made me a bit confused though. Normal uncached
> >> >> > memory is certainly bufferable (that's basically what write-combining
> >> >> > means).
> >> >> >
> >> >>
> >> >> It maps to MAIR attribute encoding 0x44, which translates as
> >> >>
> >> >> Normal Memory, Outer Non-Cacheable, Inner Non-Cacheable
> >> >
> >> > Exactly - which is definitely "buffered".
> >> >
> >> >> > This looks like a naming hangover from ARMv5 translation table format.
> >> >> > Is it about time we clean this up?
> >> >>
> >> >> The whole 'ARM_MEMORY_REGION_' intermediate namespace should be
> >> >> removed, I think.
> >> >
> >> > That sounds like a good idea to me.
> >> > There's also _NONSECURE crud in there.
> >> >
> >>
> >> Yes. But I hope you're not saying you want that to be done first
> >> before this patch can go in?
> >
> > No, but it may mean it makes sense to add a comment regarding the
> > Attributes line, since it looks like it's doing the opposite of what
> > is actually being done.
> >
> 
> Something like
> 
> --- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> +++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> @@ -134,6 +134,12 @@ ArmPlatformGetVirtualMemoryMap (
>VirtualMemoryTable[++Index].PhysicalBase = 
> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
>VirtualMemoryTable[Index].VirtualBase = PL111_CLCD_VRAM_MOTHERBOARD_BASE;
>VirtualMemoryTable[Index].Length = PL111_CLCD_VRAM_MOTHERBOARD_SIZE;
> +  //
> +  // Map the VRAM region as Normal Non-Cacheable memory and not device 
> memory,
> +  // so that we can use the accelerated string routines that may use 
> unaligned
> +  // accesses or DC ZVA instructions. The enum identifier is slightly awkward
> +  // here, but it maps to a memory type that allows buffering and reordering.
> +  //
>VirtualMemoryTable[Index].Attributes =
> ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
> 
>// Map sparse memory region if present
> 
> perhaps?

Yeah, that's spot on.
Reviewed-by: Leif Lindholm 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

[Ard Biesheuvel]

On 6 April 2017 at 20:06, Leif Lindholm  wrote:
> On Thu, Apr 06, 2017 at 07:46:50PM +0100, Ard Biesheuvel wrote:
>> >> >> +  // VRAM
>> >> >> +  VirtualMemoryTable[++Index].PhysicalBase = 
>> >> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
>> >> >> +  VirtualMemoryTable[Index].VirtualBase = 
>> >> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
>> >> >> +  VirtualMemoryTable[Index].Length = PL111_CLCD_VRAM_MOTHERBOARD_SIZE;
>> >> >> +  VirtualMemoryTable[Index].Attributes = 
>> >> >> ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
>> >> >
>> >> > Hmm, looking at this made me a bit confused though. Normal uncached
>> >> > memory is certainly bufferable (that's basically what write-combining
>> >> > means).
>> >> >
>> >>
>> >> It maps to MAIR attribute encoding 0x44, which translates as
>> >>
>> >> Normal Memory, Outer Non-Cacheable, Inner Non-Cacheable
>> >
>> > Exactly - which is definitely "buffered".
>> >
>> >> > This looks like a naming hangover from ARMv5 translation table format.
>> >> > Is it about time we clean this up?
>> >>
>> >> The whole 'ARM_MEMORY_REGION_' intermediate namespace should be
>> >> removed, I think.
>> >
>> > That sounds like a good idea to me.
>> > There's also _NONSECURE crud in there.
>> >
>>
>> Yes. But I hope you're not saying you want that to be done first
>> before this patch can go in?
>
> No, but it may mean it makes sense to add a comment regarding the
> Attributes line, since it looks like it's doing the opposite of what
> is actually being done.
>

Something like

--- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
@@ -134,6 +134,12 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryTable[++Index].PhysicalBase = PL111_CLCD_VRAM_MOTHERBOARD_BASE;
   VirtualMemoryTable[Index].VirtualBase = PL111_CLCD_VRAM_MOTHERBOARD_BASE;
   VirtualMemoryTable[Index].Length = PL111_CLCD_VRAM_MOTHERBOARD_SIZE;
+  //
+  // Map the VRAM region as Normal Non-Cacheable memory and not device memory,
+  // so that we can use the accelerated string routines that may use unaligned
+  // accesses or DC ZVA instructions. The enum identifier is slightly awkward
+  // here, but it maps to a memory type that allows buffering and reordering.
+  //
   VirtualMemoryTable[Index].Attributes =
ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;

   // Map sparse memory region if present

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

[edk2] [edk2-FdfSpecification PATCH] [FmpPayload] supports 1 or 2 FILE DATA statements

[Michael Kinney]

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

Update the EBNF for [FmpPayload] in Section 3.8 to
allow one or two FILE DATA statements.  The first
for the update image.  The second for venddor code.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 9 -
 README.md| 1 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md 
b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
index 1c38f59..77ad2b7 100644
--- a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
+++ b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
@@ -34,12 +34,19 @@
 These are optional sections that describes the FMP payload content for FMP
 Capsule files.
 
+There must be at least one and at most two `` statements.  The
+`` statements start with `FILE DATA`.  The first 
+statement provides the information for UpdateImage in an
+`EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER`.  The second 
+statement, if present, provides the information for VendorCode in an
+`EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER`.
+
  Prototype
 
 ```c
   ::= "[FmpPayload"  "]" 
   
-  
+  {1,2}
::= [ "IMAGE_HEADER_INIT_VERSION"   ]
"IMAGE_TYPE_ID"   
   [ "IMAGE_INDEX"   ]
diff --git a/README.md b/README.md
index 9a7f13a..f7e1d1f 100644
--- a/README.md
+++ b/README.md
@@ -196,3 +196,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || Clarified [UserExtensions] content in chapter 2 (to match 
implementation) 
 |   |
 | 1.28   | Convert to GitBooks 

   | March 2017|
 || [#426](https://bugzilla.tianocore.org/show_bug.cgi?id=426) 
IMAGE_TYPE_ID must be provided with value, FDF should mark it as required 
section   |   |
+|| [#461](https://bugzilla.tianocore.org/show_bug.cgi?id=461) FDF 
Spec: add a super script number for the
|   |
-- 
2.6.3.windows.1

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

[edk2] [edk2-FdfSpecification PATCH] [edk2-FdfSpecification PATCH] [FmpPayload] supports 1 or 2 FILE DATA statements

[Michael Kinney]

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

Update the EBNF for [FmpPayload] in Section 3.8 to
allow one or two FILE DATA statements.  The first
for the update image.  The second for venddor code.

GitHub branch for review:

  
https://github.com/mdkinney/edk2-FdfSpecification/tree/Bugzilla_461_FmpFileData_2_Files

GitHub branch compare against latest DRAFT for review:

  
https://github.com/tianocore-docs/edk2-FdfSpecification/compare/master...mdkinney:Bugzilla_461_FmpFileData_2_Files?w=1
  
  
Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  [FmpPayload] supports 1 or 2 FILE DATA statements

 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 9 -
 README.md| 1 +
 2 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.6.3.windows.1

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

Re: [edk2] Pull in pre-built library during edk2 build?

[Michael Zimmermann]

I'm doing the same in one of my projects where I link against a
prebuilt gcc lib.
Adding support for that is quite easy actually:

https://github.com/efidroid/edk2/commit/841473c1c86823521dfad5eb3d74461557302e42

On Thu, Apr 6, 2017 at 8:57 PM, Andrew Fish  wrote:
>
>> On Apr 6, 2017, at 11:07 AM, Peter Hornyack  wrote:
>>
>> I'd like to make an adjustment to the edk2 build (locally, not for
>> upstream) and I'm hoping someone can offer some guidance.
>>
>> My goal is to pre-build an edk2 library in a separate build process,
>> then pull that library into the full build later on. Specifically I'm
>> building my firmware image using OvmfPkgX64.dsc, but I want to build
>> OpensslLib (CryptoPkg/Library/OpensslLib/OpensslLib.inf) in advance,
>> then pull the resulting lib into the full build later. How can I
>> achieve this?
>>
>> In my build output I can see that when OpensslLib.inf is built, all of
>> the openssl .c files are compiled into .obj files, then an ar command
>> wraps those up into OpensslLib.lib. I want to pull those steps out and
>> pre-build OpensslLib.lib, but I've been unable to find where/how the
>> edk2 build grabs that .lib file and turns it into the final firmware
>> image. I've reviewed the edk2 build documentation but still can't
>> figure this out. Can anyone point me to the right place in the edk2
>> build files where I can make this happen? Or perhaps is there an
>> example of this already in the edk2 build that I can imitate?
>>
>
> Peter,
>
> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template
>  
> 
>  gets copied to Cont/build_rule.txt and these are the rules use to build the 
> makefiles.
>
> In your INF file you can add a [BuildOptions] section and use that to modify 
> the compiler, linker flags, etc for your module.
>
> This is the horrific example of what is possible:
> https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.inf#L118
>  
> 
>
> You can prune by compiler type, architecture, and which FLAG you want to use. 
> I seem to remember = is append and == is replace.
>
> Thanks,
>
> Andrew Fish
>
>> Thanks,
>> Peter
>> ___
>> 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 v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

[Leif Lindholm]

On Thu, Apr 06, 2017 at 07:46:50PM +0100, Ard Biesheuvel wrote:
> >> >> +  // VRAM
> >> >> +  VirtualMemoryTable[++Index].PhysicalBase = 
> >> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
> >> >> +  VirtualMemoryTable[Index].VirtualBase = 
> >> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
> >> >> +  VirtualMemoryTable[Index].Length = PL111_CLCD_VRAM_MOTHERBOARD_SIZE;
> >> >> +  VirtualMemoryTable[Index].Attributes = 
> >> >> ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
> >> >
> >> > Hmm, looking at this made me a bit confused though. Normal uncached
> >> > memory is certainly bufferable (that's basically what write-combining
> >> > means).
> >> >
> >>
> >> It maps to MAIR attribute encoding 0x44, which translates as
> >>
> >> Normal Memory, Outer Non-Cacheable, Inner Non-Cacheable
> >
> > Exactly - which is definitely "buffered".
> >
> >> > This looks like a naming hangover from ARMv5 translation table format.
> >> > Is it about time we clean this up?
> >>
> >> The whole 'ARM_MEMORY_REGION_' intermediate namespace should be
> >> removed, I think.
> >
> > That sounds like a good idea to me.
> > There's also _NONSECURE crud in there.
> >
> 
> Yes. But I hope you're not saying you want that to be done first
> before this patch can go in?

No, but it may mean it makes sense to add a comment regarding the
Attributes line, since it looks like it's doing the opposite of what
is actually being done.

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

Re: [edk2] Pull in pre-built library during edk2 build?

[Andrew Fish]

> On Apr 6, 2017, at 11:07 AM, Peter Hornyack  wrote:
> 
> I'd like to make an adjustment to the edk2 build (locally, not for
> upstream) and I'm hoping someone can offer some guidance.
> 
> My goal is to pre-build an edk2 library in a separate build process,
> then pull that library into the full build later on. Specifically I'm
> building my firmware image using OvmfPkgX64.dsc, but I want to build
> OpensslLib (CryptoPkg/Library/OpensslLib/OpensslLib.inf) in advance,
> then pull the resulting lib into the full build later. How can I
> achieve this?
> 
> In my build output I can see that when OpensslLib.inf is built, all of
> the openssl .c files are compiled into .obj files, then an ar command
> wraps those up into OpensslLib.lib. I want to pull those steps out and
> pre-build OpensslLib.lib, but I've been unable to find where/how the
> edk2 build grabs that .lib file and turns it into the final firmware
> image. I've reviewed the edk2 build documentation but still can't
> figure this out. Can anyone point me to the right place in the edk2
> build files where I can make this happen? Or perhaps is there an
> example of this already in the edk2 build that I can imitate?
> 

Peter,

https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template
 

 gets copied to Cont/build_rule.txt and these are the rules use to build the 
makefiles. 

In your INF file you can add a [BuildOptions] section and use that to modify 
the compiler, linker flags, etc for your module. 

This is the horrific example of what is possible:
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.inf#L118
 


You can prune by compiler type, architecture, and which FLAG you want to use. I 
seem to remember = is append and == is replace. 

Thanks,

Andrew Fish

> Thanks,
> Peter
> ___
> 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] kvm: pass the virtual SEI syndrome to guest OS

[Laszlo Ersek]

On 04/06/17 14:35, gengdongjiu wrote:
> Dear, Laszlo
>Thanks for your detailed explanation.
> 
> On 2017/3/29 19:58, Laszlo Ersek wrote:
>> (This ought to be one of the longest address lists I've ever seen :)
>> Thanks for the CC. I'm glad Shannon is already on the CC list. For good
>> measure, I'm adding MST and Igor.)
>>
>> On 03/29/17 12:36, Achin Gupta wrote:
>>> Hi gengdongjiu,
>>>
>>> On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote:

 Hi Laszlo/Biesheuvel/Qemu developer,

Now I encounter a issue and want to consult with you in ARM64 platform， 
 as described below:

 when guest OS happen synchronous or asynchronous abort, kvm needs
 to send the error address to Qemu or UEFI through sigbus to
 dynamically generate APEI table. from my investigation, there are
 two ways:

 (1) Qemu get the error address, and generate the APEI table, then
 notify UEFI to know this generation, then inject abort error to
 guest OS, guest OS read the APEI table.
 (2) Qemu get the error address, and let UEFI to generate the APEI
 table, then inject abort error to guest OS, guest OS read the APEI
 table.
>>>
>>> Just being pedantic! I don't think we are talking about creating the APEI 
>>> table
>>> dynamically here. The issue is: Once KVM has received an error that is 
>>> destined
>>> for a guest it will raise a SIGBUS to Qemu. Now before Qemu can inject the 
>>> error
>>> into the guest OS, a CPER (Common Platform Error Record) has to be generated
>>> corresponding to the error source (GHES corresponding to memory subsystem,
>>> processor etc) to allow the guest OS to do anything meaningful with the
>>> error. So who should create the CPER is the question.
>>>
>>> At the EL3/EL2 interface (Secure Firmware and OS/Hypervisor), an error 
>>> arrives
>>> at EL3 and secure firmware (at EL3 or a lower secure exception level) is
>>> responsible for creating the CPER. ARM is experimenting with using a 
>>> Standalone
>>> MM EDK2 image in the secure world to do the CPER creation. This will avoid
>>> adding the same code in ARM TF in EL3 (better for security). The error will 
>>> then
>>> be injected into the OS/Hypervisor (through SEA/SEI/SDEI) through ARM 
>>> Trusted
>>> Firmware.
>>>
>>> Qemu is essentially fulfilling the role of secure firmware at the EL2/EL1
>>> interface (as discussed with Christoffer below). So it should generate the 
>>> CPER
>>> before injecting the error.
>>>
>>> This is corresponds to (1) above apart from notifying UEFI (I am assuming 
>>> you
>>> mean guest UEFI). At this time, the guest OS already knows where to pick up 
>>> the
>>> CPER from through the HEST. Qemu has to create the CPER and populate its 
>>> address
>>> at the address exported in the HEST. Guest UEFI should not be involved in 
>>> this
>>> flow. Its job was to create the HEST at boot and that has been done by this
>>> stage.
>>>
>>> Qemu folk will be able to add but it looks like support for CPER generation 
>>> will
>>> need to be added to Qemu. We need to resolve this.
>>>
>>> Do shout if I am missing anything above.
>>
>> After reading this email, the use case looks *very* similar to what
>> we've just done with VMGENID for QEMU 2.9.
>>
>> We have a facility between QEMU and the guest firmware, called "ACPI
>> linker/loader", with which QEMU instructs the firmware to
>>
>> - allocate and download blobs into guest RAM (AcpiNVS type memory) --
>> ALLOCATE command,
>>
>> - relocate pointers in those blobs, to fields in other (or the same)
>> blobs -- ADD_POINTER command,
>>
>> - set ACPI table checksums -- ADD_CHECKSUM command,
>>
>> - and send GPAs of fields within such blobs back to QEMU --
>> WRITE_POINTER command.
>>
>> This is how I imagine we can map the facility to the current use case
>> (note that this is the first time I read about HEST / GHES / CPER):
>>
>> etc/acpi/tables etc/hardware_errors
>>  ==
>>  +---+
>> +--+ | address   | +-> +--+
>> |HEST  + | registers | |   | Error Status |
>> + ++ | +-+ |   | Data Block 1 |
>> | | GHES   | --> | | address | +   | ++
>> | | GHES   | --> | | address | --+ | |  CPER  |
>> | | GHES   | --> | | address | + | | |  CPER  |
>> | | GHES   | --> | | address | -+  | | | |  CPER  |
>> +-++ +-+-+  |  | | +-++
>> |  | |
>> |  | +---> +--+
>> |  |   | Error Status |
>> |  |   | Data Block 2 |
>> |  |   | ++
>> 

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

[Ard Biesheuvel]

On 6 April 2017 at 19:45, Leif Lindholm  wrote:
> On Thu, Apr 06, 2017 at 07:31:13PM +0100, Ard Biesheuvel wrote:
>> On 6 April 2017 at 19:26, Leif Lindholm  wrote:
>> > On Thu, Apr 06, 2017 at 02:15:47PM +0100, Ard Biesheuvel wrote:
>> >> The VRAM of the PL111 on the FVP Base/Foundation models is described as
>> >> device memory rather than uncached memory, which is not an accurate
>> >> description of the nature of the region (i.e., a framebuffer), and may
>> >> result in problems when using accelerated string routines to access the
>> >> region, since this may legally involve unaligned accesses or DC ZVA
>> >> instructions, which are not allowed on device mappings.
>> >>
>> >> So split of the 8 MB VRAM region into a separate region, and map it using
>> >> memory attributes.
>> >
>> > "Normal memory attributes"?
>> >
>>
>> OK
>>
>> >>
>> >> Contributed-under: TianoCore Contribution Agreement 1.0
>> >> Signed-off-by: Ard Biesheuvel 
>> >> ---
>> >>  ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h  | 10 
>> >> ++
>> >>  ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c |  8 
>> >> +++-
>> >>  2 files changed, 13 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git 
>> >> a/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h 
>> >> b/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
>> >> index 06414e6e7208..4e17c800a34f 100644
>> >> --- a/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
>> >> +++ b/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
>> >> @@ -40,9 +40,11 @@
>> >>  #define ARM_VE_SMB_SRAM_BASE0x2E00
>> >>  #define ARM_VE_SMB_SRAM_SZ  SIZE_64KB
>> >>  // USB, Ethernet, VRAM
>> >> -#define ARM_VE_SMB_PERIPH_BASE  0x1800
>> >> -#define PL111_CLCD_VRAM_MOTHERBOARD_BASEARM_VE_SMB_PERIPH_BASE
>> >> -#define ARM_VE_SMB_PERIPH_SZSIZE_64MB
>> >> +#define ARM_VE_SMB_PERIPH_BASE  0x1880
>> >> +#define ARM_VE_SMB_PERIPH_SZ(SIZE_64MB - SIZE_8MB)
>> >> +
>> >> +#define PL111_CLCD_VRAM_MOTHERBOARD_BASE0x1800
>> >> +#define PL111_CLCD_VRAM_MOTHERBOARD_SIZESIZE_8MB
>> >>
>> >>  // DRAM
>> >>  #define ARM_VE_DRAM_BASEPcdGet64 
>> >> (PcdSystemMemoryBase)
>> >> @@ -75,6 +77,6 @@
>> >>  #define PL111_CLCD_CORE_TILE_VIDEO_MODE_OSC_ID  1
>> >>
>> >>  // VRAM offset for the PL111 Colour LCD Controller on the motherboard
>> >> -#define VRAM_MOTHERBOARD_BASE 
>> >> (ARM_VE_SMB_PERIPH_BASE   + 0x0)
>> >> +#define VRAM_MOTHERBOARD_BASE 
>> >> (PL111_CLCD_VRAM_MOTHERBOARD_BASE)
>> >>
>> >>  #endif
>> >> diff --git 
>> >> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c 
>> >> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
>> >> index 14c7e8e1d672..70c17ae70478 100644
>> >> --- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
>> >> +++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
>> >> @@ -21,7 +21,7 @@
>> >>  #include 
>> >>
>> >>  // Number of Virtual Memory Map Descriptors
>> >> -#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  8
>> >> +#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  9
>> >>
>> >>  // DDR attributes
>> >>  #define DDR_ATTRIBUTES_CACHED   ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK
>> >> @@ -130,6 +130,12 @@ ArmPlatformGetVirtualMemoryMap (
>> >>VirtualMemoryTable[Index].Length = 2 * ARM_VE_SMB_PERIPH_SZ;
>> >>VirtualMemoryTable[Index].Attributes = 
>> >> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
>> >>
>> >> +  // VRAM
>> >> +  VirtualMemoryTable[++Index].PhysicalBase = 
>> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
>> >> +  VirtualMemoryTable[Index].VirtualBase = 
>> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
>> >> +  VirtualMemoryTable[Index].Length = PL111_CLCD_VRAM_MOTHERBOARD_SIZE;
>> >> +  VirtualMemoryTable[Index].Attributes = 
>> >> ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
>> >
>> > Hmm, looking at this made me a bit confused though. Normal uncached
>> > memory is certainly bufferable (that's basically what write-combining
>> > means).
>> >
>>
>> It maps to MAIR attribute encoding 0x44, which translates as
>>
>> Normal Memory, Outer Non-Cacheable, Inner Non-Cacheable
>
> Exactly - which is definitely "buffered".
>
>> > This looks like a naming hangover from ARMv5 translation table format.
>> > Is it about time we clean this up?
>>
>> The whole 'ARM_MEMORY_REGION_' intermediate namespace should be
>> removed, I think.
>
> That sounds like a good idea to me.
> There's also _NONSECURE crud in there.
>

Yes. But I hope you're not saying you want that to be done first
before this patch can go in?
___
edk2-devel mailing list
edk2-devel@lists.01.org

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

[Leif Lindholm]

On Thu, Apr 06, 2017 at 07:31:13PM +0100, Ard Biesheuvel wrote:
> On 6 April 2017 at 19:26, Leif Lindholm  wrote:
> > On Thu, Apr 06, 2017 at 02:15:47PM +0100, Ard Biesheuvel wrote:
> >> The VRAM of the PL111 on the FVP Base/Foundation models is described as
> >> device memory rather than uncached memory, which is not an accurate
> >> description of the nature of the region (i.e., a framebuffer), and may
> >> result in problems when using accelerated string routines to access the
> >> region, since this may legally involve unaligned accesses or DC ZVA
> >> instructions, which are not allowed on device mappings.
> >>
> >> So split of the 8 MB VRAM region into a separate region, and map it using
> >> memory attributes.
> >
> > "Normal memory attributes"?
> >
> 
> OK
> 
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>  ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h  | 10 
> >> ++
> >>  ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c |  8 
> >> +++-
> >>  2 files changed, 13 insertions(+), 5 deletions(-)
> >>
> >> diff --git 
> >> a/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h 
> >> b/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
> >> index 06414e6e7208..4e17c800a34f 100644
> >> --- a/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
> >> +++ b/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
> >> @@ -40,9 +40,11 @@
> >>  #define ARM_VE_SMB_SRAM_BASE0x2E00
> >>  #define ARM_VE_SMB_SRAM_SZ  SIZE_64KB
> >>  // USB, Ethernet, VRAM
> >> -#define ARM_VE_SMB_PERIPH_BASE  0x1800
> >> -#define PL111_CLCD_VRAM_MOTHERBOARD_BASEARM_VE_SMB_PERIPH_BASE
> >> -#define ARM_VE_SMB_PERIPH_SZSIZE_64MB
> >> +#define ARM_VE_SMB_PERIPH_BASE  0x1880
> >> +#define ARM_VE_SMB_PERIPH_SZ(SIZE_64MB - SIZE_8MB)
> >> +
> >> +#define PL111_CLCD_VRAM_MOTHERBOARD_BASE0x1800
> >> +#define PL111_CLCD_VRAM_MOTHERBOARD_SIZESIZE_8MB
> >>
> >>  // DRAM
> >>  #define ARM_VE_DRAM_BASEPcdGet64 
> >> (PcdSystemMemoryBase)
> >> @@ -75,6 +77,6 @@
> >>  #define PL111_CLCD_CORE_TILE_VIDEO_MODE_OSC_ID  1
> >>
> >>  // VRAM offset for the PL111 Colour LCD Controller on the motherboard
> >> -#define VRAM_MOTHERBOARD_BASE (ARM_VE_SMB_PERIPH_BASE 
> >>   + 0x0)
> >> +#define VRAM_MOTHERBOARD_BASE 
> >> (PL111_CLCD_VRAM_MOTHERBOARD_BASE)
> >>
> >>  #endif
> >> diff --git 
> >> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c 
> >> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> >> index 14c7e8e1d672..70c17ae70478 100644
> >> --- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> >> +++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> >> @@ -21,7 +21,7 @@
> >>  #include 
> >>
> >>  // Number of Virtual Memory Map Descriptors
> >> -#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  8
> >> +#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  9
> >>
> >>  // DDR attributes
> >>  #define DDR_ATTRIBUTES_CACHED   ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK
> >> @@ -130,6 +130,12 @@ ArmPlatformGetVirtualMemoryMap (
> >>VirtualMemoryTable[Index].Length = 2 * ARM_VE_SMB_PERIPH_SZ;
> >>VirtualMemoryTable[Index].Attributes = 
> >> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> >>
> >> +  // VRAM
> >> +  VirtualMemoryTable[++Index].PhysicalBase = 
> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
> >> +  VirtualMemoryTable[Index].VirtualBase = 
> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
> >> +  VirtualMemoryTable[Index].Length = PL111_CLCD_VRAM_MOTHERBOARD_SIZE;
> >> +  VirtualMemoryTable[Index].Attributes = 
> >> ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
> >
> > Hmm, looking at this made me a bit confused though. Normal uncached
> > memory is certainly bufferable (that's basically what write-combining
> > means).
> >
> 
> It maps to MAIR attribute encoding 0x44, which translates as
> 
> Normal Memory, Outer Non-Cacheable, Inner Non-Cacheable

Exactly - which is definitely "buffered".

> > This looks like a naming hangover from ARMv5 translation table format.
> > Is it about time we clean this up?
> 
> The whole 'ARM_MEMORY_REGION_' intermediate namespace should be
> removed, I think.

That sounds like a good idea to me.
There's also _NONSECURE crud in there.

/
Leif

> > Or have I sprained my brain?
> >
> > /
> > Leif
> >
> >> +
> >>// Map sparse memory region if present
> >>if (HasSparseMemory) {
> >>  VirtualMemoryTable[++Index].PhysicalBase = SparseMemoryBase;
> >> --
> >> 2.9.3
> >>
___
edk2-devel mailing list
edk2-devel@lists.01.org

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

[Ard Biesheuvel]

On 6 April 2017 at 19:26, Leif Lindholm  wrote:
> On Thu, Apr 06, 2017 at 02:15:47PM +0100, Ard Biesheuvel wrote:
>> The VRAM of the PL111 on the FVP Base/Foundation models is described as
>> device memory rather than uncached memory, which is not an accurate
>> description of the nature of the region (i.e., a framebuffer), and may
>> result in problems when using accelerated string routines to access the
>> region, since this may legally involve unaligned accesses or DC ZVA
>> instructions, which are not allowed on device mappings.
>>
>> So split of the 8 MB VRAM region into a separate region, and map it using
>> memory attributes.
>
> "Normal memory attributes"?
>

OK

>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h  | 10 
>> ++
>>  ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c |  8 
>> +++-
>>  2 files changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git 
>> a/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h 
>> b/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
>> index 06414e6e7208..4e17c800a34f 100644
>> --- a/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
>> +++ b/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
>> @@ -40,9 +40,11 @@
>>  #define ARM_VE_SMB_SRAM_BASE0x2E00
>>  #define ARM_VE_SMB_SRAM_SZ  SIZE_64KB
>>  // USB, Ethernet, VRAM
>> -#define ARM_VE_SMB_PERIPH_BASE  0x1800
>> -#define PL111_CLCD_VRAM_MOTHERBOARD_BASEARM_VE_SMB_PERIPH_BASE
>> -#define ARM_VE_SMB_PERIPH_SZSIZE_64MB
>> +#define ARM_VE_SMB_PERIPH_BASE  0x1880
>> +#define ARM_VE_SMB_PERIPH_SZ(SIZE_64MB - SIZE_8MB)
>> +
>> +#define PL111_CLCD_VRAM_MOTHERBOARD_BASE0x1800
>> +#define PL111_CLCD_VRAM_MOTHERBOARD_SIZESIZE_8MB
>>
>>  // DRAM
>>  #define ARM_VE_DRAM_BASEPcdGet64 
>> (PcdSystemMemoryBase)
>> @@ -75,6 +77,6 @@
>>  #define PL111_CLCD_CORE_TILE_VIDEO_MODE_OSC_ID  1
>>
>>  // VRAM offset for the PL111 Colour LCD Controller on the motherboard
>> -#define VRAM_MOTHERBOARD_BASE (ARM_VE_SMB_PERIPH_BASE   
>> + 0x0)
>> +#define VRAM_MOTHERBOARD_BASE 
>> (PL111_CLCD_VRAM_MOTHERBOARD_BASE)
>>
>>  #endif
>> diff --git 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c 
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
>> index 14c7e8e1d672..70c17ae70478 100644
>> --- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
>> +++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
>> @@ -21,7 +21,7 @@
>>  #include 
>>
>>  // Number of Virtual Memory Map Descriptors
>> -#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  8
>> +#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  9
>>
>>  // DDR attributes
>>  #define DDR_ATTRIBUTES_CACHED   ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK
>> @@ -130,6 +130,12 @@ ArmPlatformGetVirtualMemoryMap (
>>VirtualMemoryTable[Index].Length = 2 * ARM_VE_SMB_PERIPH_SZ;
>>VirtualMemoryTable[Index].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
>>
>> +  // VRAM
>> +  VirtualMemoryTable[++Index].PhysicalBase = 
>> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
>> +  VirtualMemoryTable[Index].VirtualBase = PL111_CLCD_VRAM_MOTHERBOARD_BASE;
>> +  VirtualMemoryTable[Index].Length = PL111_CLCD_VRAM_MOTHERBOARD_SIZE;
>> +  VirtualMemoryTable[Index].Attributes = 
>> ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
>
> Hmm, looking at this made me a bit confused though. Normal uncached
> memory is certainly bufferable (that's basically what write-combining
> means).
>

It maps to MAIR attribute encoding 0x44, which translates as

Normal Memory, Outer Non-Cacheable, Inner Non-Cacheable

> This looks like a naming hangover from ARMv5 translation table format.
> Is it about time we clean this up?

The whole 'ARM_MEMORY_REGION_' intermediate namespace should be
removed, I think.

> Or have I sprained my brain?
>
> /
> Leif
>
>> +
>>// Map sparse memory region if present
>>if (HasSparseMemory) {
>>  VirtualMemoryTable[++Index].PhysicalBase = SparseMemoryBase;
>> --
>> 2.9.3
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

[Leif Lindholm]

On Thu, Apr 06, 2017 at 02:15:46PM +0100, Ard Biesheuvel wrote:
> As reported by Jeremy, the recently introduced accelerated memcpy/memset
> routines are causing problems when used on framebuffer memory. While
> framebuffers are arguably right on the blurry line between MMIO (with
> side effects that are sensitive to ordering) and memory, mapping VRAM
> as device memory is unnecessary to begin with, and so we can improve
> our situation by using memory semantics for the VRAM mappings. (Whether
> we end up reverting to the unaccelerated memcpy/memset routines is a
> separate matter)
> 
> So fix both the FVP case, which has a separate VRAM region, and TC2, which
> allocates VRAM from normal memory and changes the mapping attributes.

For 2-5/5:
Reviewed-by: Leif Lindholm 

> 
> Note to Ryan: this fixes FVP Base model for me, but not the Foundation model
> (whose PL111 support I never saw working to begin with, so I am not sure what
> is going on there)
> 
> Ard Biesheuvel (5):
>   ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory
>   ArmPlatformPkg/HdLcdArmVExpressLib: fix incorrect FreePool () call
>   ArmPlatformPkg/PL111LcdArmVExpressLib: fix incorrect FreePool () call
>   ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM
>   ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for
> VRAM
> 
>  ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
>| 10 ++
>  ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c   
>|  8 +++-
>  ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
>| 14 +-
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
>|  3 ++-
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>   | 14 +-
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
>  |  3 ++-
>  6 files changed, 27 insertions(+), 25 deletions(-)
> 
> -- 
> 2.9.3
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

[Leif Lindholm]

On Thu, Apr 06, 2017 at 02:15:47PM +0100, Ard Biesheuvel wrote:
> The VRAM of the PL111 on the FVP Base/Foundation models is described as
> device memory rather than uncached memory, which is not an accurate
> description of the nature of the region (i.e., a framebuffer), and may
> result in problems when using accelerated string routines to access the
> region, since this may legally involve unaligned accesses or DC ZVA
> instructions, which are not allowed on device mappings.
> 
> So split of the 8 MB VRAM region into a separate region, and map it using
> memory attributes.

"Normal memory attributes"?

> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h  | 10 
> ++
>  ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c |  8 
> +++-
>  2 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git 
> a/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h 
> b/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
> index 06414e6e7208..4e17c800a34f 100644
> --- a/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
> +++ b/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
> @@ -40,9 +40,11 @@
>  #define ARM_VE_SMB_SRAM_BASE0x2E00
>  #define ARM_VE_SMB_SRAM_SZ  SIZE_64KB
>  // USB, Ethernet, VRAM
> -#define ARM_VE_SMB_PERIPH_BASE  0x1800
> -#define PL111_CLCD_VRAM_MOTHERBOARD_BASEARM_VE_SMB_PERIPH_BASE
> -#define ARM_VE_SMB_PERIPH_SZSIZE_64MB
> +#define ARM_VE_SMB_PERIPH_BASE  0x1880
> +#define ARM_VE_SMB_PERIPH_SZ(SIZE_64MB - SIZE_8MB)
> +
> +#define PL111_CLCD_VRAM_MOTHERBOARD_BASE0x1800
> +#define PL111_CLCD_VRAM_MOTHERBOARD_SIZESIZE_8MB
>  
>  // DRAM
>  #define ARM_VE_DRAM_BASEPcdGet64 
> (PcdSystemMemoryBase)
> @@ -75,6 +77,6 @@
>  #define PL111_CLCD_CORE_TILE_VIDEO_MODE_OSC_ID  1
>  
>  // VRAM offset for the PL111 Colour LCD Controller on the motherboard
> -#define VRAM_MOTHERBOARD_BASE (ARM_VE_SMB_PERIPH_BASE   
> + 0x0)
> +#define VRAM_MOTHERBOARD_BASE 
> (PL111_CLCD_VRAM_MOTHERBOARD_BASE)
>  
>  #endif
> diff --git 
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c 
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> index 14c7e8e1d672..70c17ae70478 100644
> --- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> +++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> @@ -21,7 +21,7 @@
>  #include 
>  
>  // Number of Virtual Memory Map Descriptors
> -#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  8
> +#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  9
>  
>  // DDR attributes
>  #define DDR_ATTRIBUTES_CACHED   ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK
> @@ -130,6 +130,12 @@ ArmPlatformGetVirtualMemoryMap (
>VirtualMemoryTable[Index].Length = 2 * ARM_VE_SMB_PERIPH_SZ;
>VirtualMemoryTable[Index].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
>  
> +  // VRAM
> +  VirtualMemoryTable[++Index].PhysicalBase = 
> PL111_CLCD_VRAM_MOTHERBOARD_BASE;
> +  VirtualMemoryTable[Index].VirtualBase = PL111_CLCD_VRAM_MOTHERBOARD_BASE;
> +  VirtualMemoryTable[Index].Length = PL111_CLCD_VRAM_MOTHERBOARD_SIZE;
> +  VirtualMemoryTable[Index].Attributes = 
> ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;

Hmm, looking at this made me a bit confused though. Normal uncached
memory is certainly bufferable (that's basically what write-combining
means).

This looks like a naming hangover from ARMv5 translation table format.
Is it about time we clean this up?
Or have I sprained my brain?

/
Leif

> +
>// Map sparse memory region if present
>if (HasSparseMemory) {
>  VirtualMemoryTable[++Index].PhysicalBase = SparseMemoryBase;
> -- 
> 2.9.3
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

[Ryan Harkin]

On 6 April 2017 at 14:15, Ard Biesheuvel  wrote:
> As reported by Jeremy, the recently introduced accelerated memcpy/memset
> routines are causing problems when used on framebuffer memory. While
> framebuffers are arguably right on the blurry line between MMIO (with
> side effects that are sensitive to ordering) and memory, mapping VRAM
> as device memory is unnecessary to begin with, and so we can improve
> our situation by using memory semantics for the VRAM mappings. (Whether
> we end up reverting to the unaccelerated memcpy/memset routines is a
> separate matter)
>
> So fix both the FVP case, which has a separate VRAM region, and TC2, which
> allocates VRAM from normal memory and changes the mapping attributes.
>
> Note to Ryan: this fixes FVP Base model for me, but not the Foundation model
> (whose PL111 support I never saw working to begin with, so I am not sure what
> is going on there)
>

With the fix to remove the duplicate VRAM_MOTHERBOARD_BASE, this
series is tested on Juno R0/1/2 to make sure they didn't break for
inexplicable reasons, on TC2 and FVP Base AEMv8 models.

FVP Foundation has never been verified with CLCD and it doesn't work
with or without this change, so I'm happy with that.

Tested-by: Ryan Harkin 


> Ard Biesheuvel (5):
>   ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory
>   ArmPlatformPkg/HdLcdArmVExpressLib: fix incorrect FreePool () call
>   ArmPlatformPkg/PL111LcdArmVExpressLib: fix incorrect FreePool () call
>   ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM
>   ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for
> VRAM
>
>  ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
>| 10 ++
>  ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c   
>|  8 +++-
>  ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
>| 14 +-
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
>|  3 ++-
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>   | 14 +-
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
>  |  3 ++-
>  6 files changed, 27 insertions(+), 25 deletions(-)
>
> --
> 2.9.3
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Pull in pre-built library during edk2 build?

[Peter Hornyack]

I'd like to make an adjustment to the edk2 build (locally, not for
upstream) and I'm hoping someone can offer some guidance.

My goal is to pre-build an edk2 library in a separate build process,
then pull that library into the full build later on. Specifically I'm
building my firmware image using OvmfPkgX64.dsc, but I want to build
OpensslLib (CryptoPkg/Library/OpensslLib/OpensslLib.inf) in advance,
then pull the resulting lib into the full build later. How can I
achieve this?

In my build output I can see that when OpensslLib.inf is built, all of
the openssl .c files are compiled into .obj files, then an ar command
wraps those up into OpensslLib.lib. I want to pull those steps out and
pre-build OpensslLib.lib, but I've been unable to find where/how the
edk2 build grabs that .lib file and turns it into the final firmware
image. I've reviewed the edk2 build documentation but still can't
figure this out. Can anyone point me to the right place in the edk2
build files where I can make this happen? Or perhaps is there an
example of this already in the edk2 build that I can imitate?

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

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

[Ard Biesheuvel]

On 6 April 2017 at 17:29, Jeremy Linton  wrote:
> Hi,
>
> On 04/06/2017 08:15 AM, Ard Biesheuvel wrote:
>>
>> As reported by Jeremy, the recently introduced accelerated memcpy/memset
>> routines are causing problems when used on framebuffer memory. While
>> framebuffers are arguably right on the blurry line between MMIO (with
>> side effects that are sensitive to ordering) and memory, mapping VRAM
>> as device memory is unnecessary to begin with, and so we can improve
>> our situation by using memory semantics for the VRAM mappings. (Whether
>> we end up reverting to the unaccelerated memcpy/memset routines is a
>> separate matter)
>>
>> So fix both the FVP case, which has a separate VRAM region, and TC2, which
>> allocates VRAM from normal memory and changes the mapping attributes.
>>
>> Note to Ryan: this fixes FVP Base model for me, but not the Foundation
>> model
>> (whose PL111 support I never saw working to begin with, so I am not sure
>> what
>> is going on there)
>
>
> So, I applied a similar set of patches against the juno, and everything
> continues to work. The change also looks good.
>
> So,
>
> Reviewed-by: Jeremy Linton 
>

Thanks!

>
> But I'm still concerned in general, since the HDLCD frame buffer is odd in
> that its just system memory rather than being attached to an IO bus of some
> form. AKA its not actually a "VRAM" (cue discussion about GDDR not having
> multiple ports/etc)...
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues

[Laszlo Ersek]

On 04/06/17 16:17, Long, Qin wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, April 6, 2017 8:57 PM
>> To: Long, Qin ; edk2-devel@lists.01.org
>> Cc: Ye, Ting ; Wu, Hao A ; Tian,
>> Feng ; Dong, Eric 
>> Subject: Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues
>>
>> On 04/06/17 13:26, Long, Qin wrote:
>>> Thanks, Laszlo.
>>>
>>> And the last "workaround" patch can be dropped, since we introduced
>>> the new [Includes.Common.Private] setting in Package DEC file (from my
>>> last patch). This will help to eliminate the potential macro
>>> re-definition risk.
>>
>> Is the [Includes.Common.Private] section documented somewhere? I
>> checked the DEC spec v1.25, and it's not described there. Should I file a
>> documentation BZ about this?
> 
> The feature was introduced by the Commit 
> ("c28d2e1047816164ffec552e4a3375122cbcc6b6").

Oh, this looks very useful. Thanks!
Laszlo

> I will check the documentation status with the owner. 
> 
>>
>> Thanks
>> Laszlo
>>
>>> It's still valuable to refine openssl e_os2.h definition for
>>> consistence, which was submitted / approved by the PR
>>> (https://github.com/openssl/openssl/pull/3121)
>>>
>>>
>>> Best Regards & Thanks,
>>> LONG, Qin
>>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
 Of Laszlo Ersek
 Sent: Thursday, April 6, 2017 4:55 PM
 To: Long, Qin ; edk2-devel@lists.01.org
 Cc: Ye, Ting ; Wu, Hao A ;
 Tian, Feng ; Dong, Eric 
 Subject: Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build
 Issues

 On 04/01/17 07:38, Long Qin wrote:
> From: Qin Long 
>
> V2:
>   Updated the patches as the comments from Laszlo
>> (ler...@redhat.com).
>   And filed two TianoCore BZ (#455, #456) to track the further follow-ups
>   on openssl and EDKII-CryptoPkg:
> https://bugzilla.tianocore.org/show_bug.cgi?id=455
> https://bugzilla.tianocore.org/show_bug.cgi?id=456
>
> This patch series introduced some hotfixes and workaround to resolve
> the build issues under different toolchain, and from potential
> external consumers, including:
>   - build warning under GCC48 and VS2010 toolchain;
>   - Potential unresolved external symbol link issue;
>   - One bug fix of timer() wrapper in ConstantTimeClock.c;
>   - One workaround to resolve macro re-definitions issue from some
> external BaseCryptLib consumer.
>
>   (https://github.com/qloong/edk2/commits/dev-openssl-hotfix)
>
> Qin Long (4):
>   CryptoPkg/OpensslLib: Suppress extra build warnings in openssl source
>   CryptoPkg: Fix possible unresolved external symbol issue.
>   CryptoPkg/BaseCryptLib: Adding NULL checking in time() wrapper.
>   CryptoPkg: One workaround to resolve potential build issue.
>
>  CryptoPkg/Include/CrtLibSupport.h  |   1 +
>  CryptoPkg/Include/openssl/e_os2.h  | 321
 +
>  .../BaseCryptLib/SysCall/ConstantTimeClock.c   |   6 +-
>  CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c  |  10 +-
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf|  15 +-
>  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |  15 +-
>  6 files changed, 355 insertions(+), 13 deletions(-)  create mode
> 100644 CryptoPkg/Include/openssl/e_os2.h
>

 I can see the upstream OpenSSL pull req / issue report references in
 TianoCore BZs 455 and 456.

 series
 Reviewed-by: Laszlo Ersek 

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

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

Re: [edk2] How to get fs index from controller handle.

[Amit kumar]

Hi,


Can i use gbs->loadimage() and gbs->startimage() to load an efi application and 
execute it.

Suppose i have a app1.efi and from app1.efi i want to execute app2.efi.

Or is there some other way to do it ?

Not considering ShellExecute();

Amit


From: af...@apple.com  on behalf of Andrew Fish 

Sent: Thursday, April 6, 2017 4:39:22 PM
To: Amit kumar
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] How to get fs index from controller handle.


On Apr 6, 2017, at 3:30 AM, Amit kumar 
> wrote:

Hi,

I want to get the fs index from the controller handle.
e.g In map command i see my controller is mapped to fs10.
So i there any API i can use in my code to get the fs index( which is 10 as in 
example) from the controller handle.


Amit,

It is important to remember that fs0:, and the other device names are a Shell 
concept and not an EFI concept. So they only exist in the context of the shell.

I took a quick look and I did not see an easy way to do this with the current 
Shell APIs.

In the older Shell you could use this  protocol  EfiShellEnvironment2 Protocol 
has a function that converts a EFI_DEVICE_PATH_PROTOCOL (would be on your 
controller handle) to a CHAR16. Thus you can get the volume name the Shell 
would display to the user. I don't the index exists as a concept.  So  
EFI_SHELL_ENVIRONMENT2.GetFsName() and  
EFI_SHELL_ENVIRONMENT2.GetFsDevicepath() are the closest thing I can think of.
https://github.com/tianocore/edk2/blob/master/ShellPkg/Include/Protocol/EfiShellEnvironment2.h#L812

The only problem with that is EfiShellEnvironment2 is not produced by the Shell 
by default.

  ## This flag is used to control the protocols produced by the shell
  #  If TRUE the shell will produce EFI_SHELL_ENVIRONMENT2 and 
EFI_SHELL_INTERFACE
  
gEfiShellPkgTokenSpaceGuid.PcdShellSupportOldProtocols|FALSE|BOOLEAN|0x0002

I've use the EFI_SHELL_ENVIRONMENT2 in the past to enable a non Shell 
application to print out volume names that match the map command of the shell. 
Hopefully some one knows how to do this in the modern Shell?

Thanks,

Andrew Fish

Regards
Amit
___
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 0/5] ArmPlatformPkg: map VRAM using memory semantics

[Jeremy Linton]

Hi,

On 04/06/2017 08:15 AM, Ard Biesheuvel wrote:

As reported by Jeremy, the recently introduced accelerated memcpy/memset
routines are causing problems when used on framebuffer memory. While
framebuffers are arguably right on the blurry line between MMIO (with
side effects that are sensitive to ordering) and memory, mapping VRAM
as device memory is unnecessary to begin with, and so we can improve
our situation by using memory semantics for the VRAM mappings. (Whether
we end up reverting to the unaccelerated memcpy/memset routines is a
separate matter)

So fix both the FVP case, which has a separate VRAM region, and TC2, which
allocates VRAM from normal memory and changes the mapping attributes.

Note to Ryan: this fixes FVP Base model for me, but not the Foundation model
(whose PL111 support I never saw working to begin with, so I am not sure what
is going on there)


So, I applied a similar set of patches against the juno, and everything 
continues to work. The change also looks good.


So,

Reviewed-by: Jeremy Linton 


But I'm still concerned in general, since the HDLCD frame buffer is odd 
in that its just system memory rather than being attached to an IO bus 
of some form. AKA its not actually a "VRAM" (cue discussion about GDDR 
not having multiple ports/etc)...





Ard Biesheuvel (5):
  ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory
  ArmPlatformPkg/HdLcdArmVExpressLib: fix incorrect FreePool () call
  ArmPlatformPkg/PL111LcdArmVExpressLib: fix incorrect FreePool () call
  ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM
  ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for
VRAM

 ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h  
 | 10 ++
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c 
 |  8 +++-
 ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c   
 | 14 +-
 
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
   |  3 ++-
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
  | 14 +-
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 |  3 ++-
 6 files changed, 27 insertions(+), 25 deletions(-)



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

Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Fix unconditional window shrinking

[ate...@kraftway.ru]

Hello, Siyuan,

I experienced actual deadlock while sending huge amounts of data from uefi to 
some server (tried Apache and IIS). At some point of transmission server starts 
to reduce its window size all the way to zero window size. After window update 
on server (when window size restores back to non-zero value) client starts to 
drop all packets from server because of future ACK (Seg.Ack > Tcb.SndNxt). This 
supposedly happened because uefi client mistakenly moved SndNxt to the left one 
or multiple times. According to RFC 1122 (section 4.2.2.16), when server 
shrinks rcv buffer, usable window becomes negative.

Below is a part of wireshark's dump of tcp transmission (with non-important 
parts removed).
In frames 4490-4496 server reduces window size from 24576 to 5623, while ACKing 
relatively old packets (from 566378 to 585202). Client then sends packet with 
SEQ 589546 (frame 4496). In frame 4497 server ACKs segment from frame 4489 and 
in next frame it ACKs segment from frame 4496 with ACK=590994 (which means he 
accepted all 1448 data bytes from 4496 frame?). But on all zero window size 
packets (frames 4498-4515) client replies with SEQ 590754 and after window 
update (frame 4516) we have a deadlock starting from frame 4517.

---

Frame 4489: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
on interface 0
Transmission Control Protocol, Src Port: 1452 (1452), Dst Port: 80 (80), Seq: 
588098, Ack: 26, Len: 1448
Sequence number: 588098(relative sequence number)
[Next sequence number: 589546(relative sequence number)]
Acknowledgment number: 26(relative ack number)
Window size value: 32767
[Calculated window size: 2097088]
[Window size scaling factor: 64]
TCP segment data (1448 bytes)

Frame 4490: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on 
interface 0
Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1452 (1452), Seq: 
26, Ack: 566378, Len: 0
Sequence number: 26(relative sequence number)
Acknowledgment number: 566378(relative ack number)
Window size value: 96
[Calculated window size: 24576]
[Window size scaling factor: 256]

Frame 4491: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on 
interface 0
Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1452 (1452), Seq: 
26, Ack: 570722, Len: 0
Sequence number: 26(relative sequence number)
Acknowledgment number: 570722(relative ack number)
Window size value: 79
[Calculated window size: 20224]
[Window size scaling factor: 256]

Frame 4492: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on 
interface 0
Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1452 (1452), Seq: 
26, Ack: 573618, Len: 0
Sequence number: 26(relative sequence number)
Acknowledgment number: 573618(relative ack number)
Window size value: 67
[Calculated window size: 17152]
[Window size scaling factor: 256]

Frame 4493: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on 
interface 0
Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1452 (1452), Seq: 
26, Ack: 577962, Len: 0
Sequence number: 26(relative sequence number)
Acknowledgment number: 577962(relative ack number)
Window size value: 50
[Calculated window size: 12800]
[Window size scaling factor: 256]

Frame 4494: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on 
interface 0
Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1452 (1452), Seq: 
26, Ack: 582306, Len: 0
Sequence number: 26(relative sequence number)
Acknowledgment number: 582306(relative ack number)
Window size value: 33
[Calculated window size: 8448]
[Window size scaling factor: 256]

Frame 4495: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on 
interface 0
Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1452 (1452), Seq: 
26, Ack: 585202, Len: 0
Sequence number: 26(relative sequence number)
Acknowledgment number: 585202(relative ack number)
Window size value: 22
[Calculated window size: 5632]
[Window size scaling factor: 256]

Frame 4496: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
on interface 0
Transmission Control Protocol, Src Port: 1452 (1452), Dst Port: 80 (80), Seq: 
589546, Ack: 26, Len: 1448
Sequence number: 589546(relative sequence number)
[Next sequence number: 590994(relative sequence number)]
Acknowledgment number: 26(relative ack number)
Window size value: 32767
[Calculated window size: 2097088]
[Window size scaling factor: 64]
TCP segment data (1448 bytes)

Frame 4497: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on 
interface 0
Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1452 (1452), Seq: 
26, Ack: 589546, Len: 0
Sequence number: 26(relative sequence number)
Acknowledgment number: 589546

Re: [edk2] [PATCH v7] MdePkg: BaseIoLibIntrinsic (IoLib class) library

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Leo Duran [mailto:leo.du...@amd.com]
> Sent: Thursday, April 6, 2017 10:48 PM
> To: edk2-de...@ml01.01.org
> Cc: Leo Duran ; Kinney, Michael D 
> ; Gao, Liming ; Brijesh
> Singh 
> Subject: [PATCH v7] MdePkg: BaseIoLibIntrinsic (IoLib class) library
> 
> This patch adds an SEV-specific .INF and corresponding assembly
> files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines
> when the SEV feature is enabled under a hypervisor environment.
> 
> The new .INF only supports the IA32 and X64 architectures.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Leo Duran 
> ---
>  .../BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf   |  59 +
>  .../Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm | 293 
> +
>  .../Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm  | 282 
>  MdePkg/MdePkg.dsc  |   1 +
>  4 files changed, 635 insertions(+)
>  create mode 100644 
> MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
>  create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
>  create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf 
> b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
> new file mode 100644
> index 000..0eec896
> --- /dev/null
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
> @@ -0,0 +1,59 @@
> +## @file
> +#  Instance of I/O Library using compiler intrinsics.
> +#
> +#  I/O Library that uses compiler intrinsics to perform IN and OUT 
> instructions
> +#  for IA-32 and x64.
> +#
> +#  Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
> +#  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> +#  Copyright (c) 2017, AMD Incorporated. 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.
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = BaseIoLibIntrinsicSev
> +  MODULE_UNI_FILE= BaseIoLibIntrinsic.uni
> +  FILE_GUID  = 93742f95-6e71-4581-b600-8e1da443f95a
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = IoLib
> +
> +
> +#
> +#  VALID_ARCHITECTURES   = IA32 X64
> +#
> +
> +[Sources]
> +  IoLibMmioBuffer.c
> +  BaseIoLibIntrinsicInternal.h
> +  IoHighLevel.c
> +
> +[Sources.IA32]
> +  IoLibGcc.c| GCC
> +  IoLibMsc.c| MSFT
> +  IoLibIcc.c| INTEL
> +  IoLib.c
> +  Ia32/IoFifoSev.nasm
> +
> +[Sources.X64]
> +  IoLibGcc.c| GCC
> +  IoLibMsc.c| MSFT
> +  IoLibIcc.c| INTEL
> +  IoLib.c
> +  X64/IoFifoSev.nasm
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +
> +[LibraryClasses]
> +  DebugLib
> +  BaseLib
> +
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm 
> b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
> new file mode 100644
> index 000..9adb972
> --- /dev/null
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
> @@ -0,0 +1,293 @@
> +;--
> +;
> +; Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.
> +; Copyright (c) 2017, AMD Incorporated. 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.
> +;
> +;--
> +
> +SECTION .text
> +
> +;--
> +; Check whether we need to unroll the String I/O under SEV guest
> +;
> +; Return // eax   (1 - unroll, 0 - no unroll)
> +;--
> +global ASM_PFX(SevNoRepIo)
> 

[edk2] [PATCH v7] MdePkg: BaseIoLibIntrinsic (IoLib class) library

[Leo Duran]

This patch adds an SEV-specific .INF and corresponding assembly
files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines
when the SEV feature is enabled under a hypervisor environment.

The new .INF only supports the IA32 and X64 architectures.

This patch follows the series "[PATCH v3 00/10] IoLib class library",
which has already being pushed upstream.

Changes since v6:
- Add .INF entry into MdePkg.dsc

NOTE:
Please pardon the churn... Just had too many balls in the air.
(hopefuly this is it, promise!)

Leo Duran (1):
  MdePkg: BaseIoLibIntrinsic (IoLib class) library

 .../BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf   |  59 +
 .../Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm | 293 +
 .../Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm  | 282 
 MdePkg/MdePkg.dsc  |   1 +
 4 files changed, 635 insertions(+)
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm

-- 
2.7.4

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

[edk2] [PATCH v6] MdePkg: BaseIoLibIntrinsic (IoLib class) library

[Leo Duran]

This patch adds an SEV-specific .INF and corresponding assembly
files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines
when the SEV feature is enabled under a hypervisor environment.

The new .INF only supports the IA32 and X64 architectures.

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh 
Signed-off-by: Leo Duran 
---
 .../BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf   |  59 +
 .../Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm | 293 +
 .../Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm  | 282 
 3 files changed, 634 insertions(+)
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm

diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf 
b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
new file mode 100644
index 000..0eec896
--- /dev/null
+++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
@@ -0,0 +1,59 @@
+## @file
+#  Instance of I/O Library using compiler intrinsics.
+#
+#  I/O Library that uses compiler intrinsics to perform IN and OUT instructions
+#  for IA-32 and x64.
+#
+#  Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+#  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
+#  Copyright (c) 2017, AMD Incorporated. 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.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = BaseIoLibIntrinsicSev
+  MODULE_UNI_FILE= BaseIoLibIntrinsic.uni
+  FILE_GUID  = 93742f95-6e71-4581-b600-8e1da443f95a
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = IoLib 
+
+
+#
+#  VALID_ARCHITECTURES   = IA32 X64
+#
+
+[Sources]
+  IoLibMmioBuffer.c
+  BaseIoLibIntrinsicInternal.h
+  IoHighLevel.c
+
+[Sources.IA32]
+  IoLibGcc.c| GCC
+  IoLibMsc.c| MSFT
+  IoLibIcc.c| INTEL
+  IoLib.c
+  Ia32/IoFifoSev.nasm
+
+[Sources.X64]
+  IoLibGcc.c| GCC
+  IoLibMsc.c| MSFT
+  IoLibIcc.c| INTEL
+  IoLib.c
+  X64/IoFifoSev.nasm
+
+[Packages]
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  DebugLib
+  BaseLib
+
diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm 
b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
new file mode 100644
index 000..9adb972
--- /dev/null
+++ b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
@@ -0,0 +1,293 @@
+;--
+;
+; Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.
+; Copyright (c) 2017, AMD Incorporated. 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.
+;
+;--
+
+SECTION .text
+
+;--
+; Check whether we need to unroll the String I/O under SEV guest
+;
+; Return // eax   (1 - unroll, 0 - no unroll)
+;--
+global ASM_PFX(SevNoRepIo)
+ASM_PFX(SevNoRepIo):
+
+  ; CPUID clobbers ebx, ecx and edx
+  push  ebx
+  push  ecx
+  push  edx
+
+  ; Check if we are running under hypervisor
+  ; CPUID(1).ECX Bit 31
+  mov   eax, 1
+  cpuid
+  btecx, 31
+  jnc   @UseRepIo
+
+  ; Check if we have Memory encryption CPUID leaf
+  mov   eax, 0x8000
+  cpuid
+  cmp   eax, 0x801f
+  jl@UseRepIo
+
+  ; Check for memory encryption feature:
+  ;  CPUID  Fn8000_001F[EAX] - Bit 1
+  ;
+  mov   eax,  0x801f
+  cpuid
+  bteax, 1
+  jnc   @UseRepIo
+
+  ; Check if memory encryption is enabled
+  ;  MSR_0xC0010131 - Bit 0 (SEV enabled)
+  ;  MSR_0xC0010131 - Bit 1 (SEV-ES enabled)
+  mov   ecx, 0xc0010131
+  rdmsr
+
+  ; Check 

[edk2] [PATCH v6] MdePkg: BaseIoLibIntrinsic (IoLib class) library

[Leo Duran]

This patch adds an SEV-specific .INF and corresponding assembly
files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines
when the SEV feature is enabled under a hypervisor environment.

The new .INF only supports the IA32 and X64 architectures.

This patch follows the series "[PATCH v3 00/10] IoLib class library",
which has already being pushed upstream.

Changes since v5:
- Include missing .INF file

Leo Duran (1):
  MdePkg: BaseIoLibIntrinsic (IoLib class) library

 .../BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf   |  59 +
 .../Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm | 293 +
 .../Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm  | 282 
 3 files changed, 634 insertions(+)
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm

-- 
2.7.4

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

Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues

[Long, Qin]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, April 6, 2017 8:57 PM
> To: Long, Qin ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Hao A ; Tian,
> Feng ; Dong, Eric 
> Subject: Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues
> 
> On 04/06/17 13:26, Long, Qin wrote:
> > Thanks, Laszlo.
> >
> > And the last "workaround" patch can be dropped, since we introduced
> > the new [Includes.Common.Private] setting in Package DEC file (from my
> > last patch). This will help to eliminate the potential macro
> > re-definition risk.
> 
> Is the [Includes.Common.Private] section documented somewhere? I
> checked the DEC spec v1.25, and it's not described there. Should I file a
> documentation BZ about this?

The feature was introduced by the Commit 
("c28d2e1047816164ffec552e4a3375122cbcc6b6").
I will check the documentation status with the owner. 

> 
> Thanks
> Laszlo
> 
> > It's still valuable to refine openssl e_os2.h definition for
> > consistence, which was submitted / approved by the PR
> > (https://github.com/openssl/openssl/pull/3121)
> >
> >
> > Best Regards & Thanks,
> > LONG, Qin
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Laszlo Ersek
> >> Sent: Thursday, April 6, 2017 4:55 PM
> >> To: Long, Qin ; edk2-devel@lists.01.org
> >> Cc: Ye, Ting ; Wu, Hao A ;
> >> Tian, Feng ; Dong, Eric 
> >> Subject: Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build
> >> Issues
> >>
> >> On 04/01/17 07:38, Long Qin wrote:
> >>> From: Qin Long 
> >>>
> >>> V2:
> >>>   Updated the patches as the comments from Laszlo
> (ler...@redhat.com).
> >>>   And filed two TianoCore BZ (#455, #456) to track the further follow-ups
> >>>   on openssl and EDKII-CryptoPkg:
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=455
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=456
> >>>
> >>> This patch series introduced some hotfixes and workaround to resolve
> >>> the build issues under different toolchain, and from potential
> >>> external consumers, including:
> >>>   - build warning under GCC48 and VS2010 toolchain;
> >>>   - Potential unresolved external symbol link issue;
> >>>   - One bug fix of timer() wrapper in ConstantTimeClock.c;
> >>>   - One workaround to resolve macro re-definitions issue from some
> >>> external BaseCryptLib consumer.
> >>>
> >>>   (https://github.com/qloong/edk2/commits/dev-openssl-hotfix)
> >>>
> >>> Qin Long (4):
> >>>   CryptoPkg/OpensslLib: Suppress extra build warnings in openssl source
> >>>   CryptoPkg: Fix possible unresolved external symbol issue.
> >>>   CryptoPkg/BaseCryptLib: Adding NULL checking in time() wrapper.
> >>>   CryptoPkg: One workaround to resolve potential build issue.
> >>>
> >>>  CryptoPkg/Include/CrtLibSupport.h  |   1 +
> >>>  CryptoPkg/Include/openssl/e_os2.h  | 321
> >> +
> >>>  .../BaseCryptLib/SysCall/ConstantTimeClock.c   |   6 +-
> >>>  CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c  |  10 +-
> >>>  CryptoPkg/Library/OpensslLib/OpensslLib.inf|  15 +-
> >>>  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |  15 +-
> >>>  6 files changed, 355 insertions(+), 13 deletions(-)  create mode
> >>> 100644 CryptoPkg/Include/openssl/e_os2.h
> >>>
> >>
> >> I can see the upstream OpenSSL pull req / issue report references in
> >> TianoCore BZs 455 and 456.
> >>
> >> series
> >> Reviewed-by: Laszlo Ersek 
> >>
> >> 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] [PATCH v2 5/5] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

[Ard Biesheuvel]

Replace the uncached memory mapping of the framebuffer with a write-
combining one. This improves performance, and avoids issues with
unaligned accesses and DC ZVA instructions performed by the accelerated
memcpy/memset routines.

Instead of manipulating the memory attributes directly, use the
SetMemorySpaceAttributes() DXE services, which validates the attributes
against the capabilities of the region before making the actual change.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
  | 12 
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 |  3 ++-
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
index a8125e81daac..3f3ceb3d2fa8 100644
--- 
a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
+++ 
b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
@@ -17,10 +17,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
@@ -165,7 +165,6 @@ LcdPlatformGetVram (
   )
 {
   EFI_STATUS  Status;
-  EFI_CPU_ARCH_PROTOCOL  *Cpu;
 
   Status = EFI_SUCCESS;
 
@@ -187,12 +186,9 @@ LcdPlatformGetVram (
   return Status;
 }
 
-// Ensure the Cpu architectural protocol is already installed
-Status = gBS->LocateProtocol (, NULL, (VOID 
**));
-ASSERT_EFI_ERROR(Status);
-
-// Mark the VRAM as un-cachable. The VRAM is inside the DRAM, which is 
cachable.
-Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
EFI_MEMORY_UC);
+// Mark the VRAM as write-combining. The VRAM is inside the DRAM, which is 
cacheable.
+Status = gDS->SetMemorySpaceAttributes (*VramBaseAddress, *VramSize,
+EFI_MEMORY_WC);
 ASSERT_EFI_ERROR(Status);
 if (EFI_ERROR(Status)) {
   gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES(*VramSize));
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
index d1978e7110d5..658558ab1523 100644
--- 
a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
+++ 
b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
@@ -31,8 +31,9 @@ [Packages]
   ArmPlatformPkg/ArmPlatformPkg.dec
 
 [LibraryClasses]
-  BaseLib
   ArmPlatformSysConfigLib
+  BaseLib
+  DxeServicesTableLib
 
 [Protocols]
   gEfiEdidDiscoveredProtocolGuid# Produced
-- 
2.9.3

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

[edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

[Ard Biesheuvel]

As reported by Jeremy, the recently introduced accelerated memcpy/memset
routines are causing problems when used on framebuffer memory. While
framebuffers are arguably right on the blurry line between MMIO (with
side effects that are sensitive to ordering) and memory, mapping VRAM
as device memory is unnecessary to begin with, and so we can improve
our situation by using memory semantics for the VRAM mappings. (Whether
we end up reverting to the unaccelerated memcpy/memset routines is a
separate matter)

So fix both the FVP case, which has a separate VRAM region, and TC2, which
allocates VRAM from normal memory and changes the mapping attributes.

Note to Ryan: this fixes FVP Base model for me, but not the Foundation model
(whose PL111 support I never saw working to begin with, so I am not sure what
is going on there)

Ard Biesheuvel (5):
  ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory
  ArmPlatformPkg/HdLcdArmVExpressLib: fix incorrect FreePool () call
  ArmPlatformPkg/PL111LcdArmVExpressLib: fix incorrect FreePool () call
  ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM
  ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for
VRAM

 ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h  
 | 10 ++
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c 
 |  8 +++-
 ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c   
 | 14 +-
 
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
   |  3 ++-
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
  | 14 +-
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 |  3 ++-
 6 files changed, 27 insertions(+), 25 deletions(-)

-- 
2.9.3

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

[edk2] [PATCH v2 2/5] ArmPlatformPkg/HdLcdArmVExpressLib: fix incorrect FreePool () call

[Ard Biesheuvel]

When we fail to modify the memory attributes for the VRAM allocation,
the allocation - which was made using AllocatePages() - is freed using
FreePool(). This is incorrect by itself, but it masks a second bug, i.e.,
that the address of the allocation is not in VramBaseAddress but in
*VramBaseAddress. So fix both issues.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c | 
2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index a57846715ed7..67b2f14beee3 100644
--- 
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ 
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -146,7 +146,7 @@ LcdPlatformGetVram (
   Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
EFI_MEMORY_UC);
   ASSERT_EFI_ERROR(Status);
   if (EFI_ERROR(Status)) {
-gBS->FreePool (VramBaseAddress);
+gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES (*VramSize));
 return Status;
   }
 
-- 
2.9.3

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

[edk2] [PATCH v2 4/5] ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM

[Ard Biesheuvel]

Replace the uncached memory mapping of the framebuffer with a write-
combining one. This improves performance, and avoids issues with
unaligned accesses and DC ZVA instructions performed by the accelerated
memcpy/memset routines.

Instead of manipulating the memory attributes directly, use the
SetMemorySpaceAttributes() DXE services, which validates the attributes
against the capabilities of the region before making the actual change.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c   
   | 12 
 
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
 |  3 ++-
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index 67b2f14beee3..b1106ee19b98 100644
--- 
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ 
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -18,11 +18,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
@@ -119,7 +119,6 @@ LcdPlatformGetVram (
   )
 {
   EFI_STATUS  Status;
-  EFI_CPU_ARCH_PROTOCOL  *Cpu;
   EFI_ALLOCATE_TYPE   AllocationType;
 
   // Set the vram size
@@ -138,12 +137,9 @@ LcdPlatformGetVram (
 return Status;
   }
 
-  // Ensure the Cpu architectural protocol is already installed
-  Status = gBS->LocateProtocol (, NULL, (VOID **));
-  ASSERT_EFI_ERROR(Status);
-
-  // Mark the VRAM as un-cacheable. The VRAM is inside the DRAM, which is 
cacheable.
-  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
EFI_MEMORY_UC);
+  // Mark the VRAM as write-combining. The VRAM is inside the DRAM, which is 
cacheable.
+  Status = gDS->SetMemorySpaceAttributes (*VramBaseAddress, *VramSize,
+  EFI_MEMORY_WC);
   ASSERT_EFI_ERROR(Status);
   if (EFI_ERROR(Status)) {
 gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES (*VramSize));
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
index 780724737929..dff17e86fd3e 100644
--- 
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
+++ 
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
@@ -32,8 +32,9 @@ [Packages]
   ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec
 
 [LibraryClasses]
-  BaseLib
   ArmPlatformSysConfigLib
+  BaseLib
+  DxeServicesTableLib
 
 [Protocols]
   gEfiEdidDiscoveredProtocolGuid# Produced
-- 
2.9.3

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

[edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

[Ard Biesheuvel]

The VRAM of the PL111 on the FVP Base/Foundation models is described as
device memory rather than uncached memory, which is not an accurate
description of the nature of the region (i.e., a framebuffer), and may
result in problems when using accelerated string routines to access the
region, since this may legally involve unaligned accesses or DC ZVA
instructions, which are not allowed on device mappings.

So split of the 8 MB VRAM region into a separate region, and map it using
memory attributes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h  | 10 
++
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c |  8 
+++-
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h 
b/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
index 06414e6e7208..4e17c800a34f 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
+++ b/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
@@ -40,9 +40,11 @@
 #define ARM_VE_SMB_SRAM_BASE0x2E00
 #define ARM_VE_SMB_SRAM_SZ  SIZE_64KB
 // USB, Ethernet, VRAM
-#define ARM_VE_SMB_PERIPH_BASE  0x1800
-#define PL111_CLCD_VRAM_MOTHERBOARD_BASEARM_VE_SMB_PERIPH_BASE
-#define ARM_VE_SMB_PERIPH_SZSIZE_64MB
+#define ARM_VE_SMB_PERIPH_BASE  0x1880
+#define ARM_VE_SMB_PERIPH_SZ(SIZE_64MB - SIZE_8MB)
+
+#define PL111_CLCD_VRAM_MOTHERBOARD_BASE0x1800
+#define PL111_CLCD_VRAM_MOTHERBOARD_SIZESIZE_8MB
 
 // DRAM
 #define ARM_VE_DRAM_BASEPcdGet64 (PcdSystemMemoryBase)
@@ -75,6 +77,6 @@
 #define PL111_CLCD_CORE_TILE_VIDEO_MODE_OSC_ID  1
 
 // VRAM offset for the PL111 Colour LCD Controller on the motherboard
-#define VRAM_MOTHERBOARD_BASE (ARM_VE_SMB_PERIPH_BASE   + 
0x0)
+#define VRAM_MOTHERBOARD_BASE 
(PL111_CLCD_VRAM_MOTHERBOARD_BASE)
 
 #endif
diff --git a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
index 14c7e8e1d672..70c17ae70478 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
@@ -21,7 +21,7 @@
 #include 
 
 // Number of Virtual Memory Map Descriptors
-#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  8
+#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  9
 
 // DDR attributes
 #define DDR_ATTRIBUTES_CACHED   ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK
@@ -130,6 +130,12 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryTable[Index].Length = 2 * ARM_VE_SMB_PERIPH_SZ;
   VirtualMemoryTable[Index].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
 
+  // VRAM
+  VirtualMemoryTable[++Index].PhysicalBase = PL111_CLCD_VRAM_MOTHERBOARD_BASE;
+  VirtualMemoryTable[Index].VirtualBase = PL111_CLCD_VRAM_MOTHERBOARD_BASE;
+  VirtualMemoryTable[Index].Length = PL111_CLCD_VRAM_MOTHERBOARD_SIZE;
+  VirtualMemoryTable[Index].Attributes = 
ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
+
   // Map sparse memory region if present
   if (HasSparseMemory) {
 VirtualMemoryTable[++Index].PhysicalBase = SparseMemoryBase;
-- 
2.9.3

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

[edk2] [PATCH v2 3/5] ArmPlatformPkg/PL111LcdArmVExpressLib: fix incorrect FreePool () call

[Ard Biesheuvel]

When we fail to modify the memory attributes for the VRAM allocation,
the allocation - which was made using AllocatePages() - is freed using
FreePool(). This is incorrect by itself, but it masks a second bug, i.e.,
that the address of the allocation is not in VramBaseAddress but in
*VramBaseAddress. So fix both issues.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
index 2000c9bdf436..a8125e81daac 100644
--- 
a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
+++ 
b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
@@ -195,7 +195,7 @@ LcdPlatformGetVram (
 Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
EFI_MEMORY_UC);
 ASSERT_EFI_ERROR(Status);
 if (EFI_ERROR(Status)) {
-  gBS->FreePool(VramBaseAddress);
+  gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES(*VramSize));
   return Status;
 }
 break;
-- 
2.9.3

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

Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues

[Laszlo Ersek]

On 04/06/17 13:26, Long, Qin wrote:
> Thanks, Laszlo. 
> 
> And the last "workaround" patch can be dropped, since we introduced
> the new [Includes.Common.Private] setting in Package DEC file (from
> my last patch). This will help to eliminate the potential macro
> re-definition risk.

Is the [Includes.Common.Private] section documented somewhere? I checked
the DEC spec v1.25, and it's not described there. Should I file a
documentation BZ about this?

Thanks
Laszlo

> It's still valuable to refine openssl e_os2.h definition for
> consistence, which was submitted / approved by the PR
> (https://github.com/openssl/openssl/pull/3121)
> 
> 
> Best Regards & Thanks,
> LONG, Qin
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Thursday, April 6, 2017 4:55 PM
>> To: Long, Qin ; edk2-devel@lists.01.org
>> Cc: Ye, Ting ; Wu, Hao A ; Tian,
>> Feng ; Dong, Eric 
>> Subject: Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues
>>
>> On 04/01/17 07:38, Long Qin wrote:
>>> From: Qin Long 
>>>
>>> V2:
>>>   Updated the patches as the comments from Laszlo (ler...@redhat.com).
>>>   And filed two TianoCore BZ (#455, #456) to track the further follow-ups
>>>   on openssl and EDKII-CryptoPkg:
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=455
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=456
>>>
>>> This patch series introduced some hotfixes and workaround to resolve
>>> the build issues under different toolchain, and from potential
>>> external consumers, including:
>>>   - build warning under GCC48 and VS2010 toolchain;
>>>   - Potential unresolved external symbol link issue;
>>>   - One bug fix of timer() wrapper in ConstantTimeClock.c;
>>>   - One workaround to resolve macro re-definitions issue from some
>>> external BaseCryptLib consumer.
>>>
>>>   (https://github.com/qloong/edk2/commits/dev-openssl-hotfix)
>>>
>>> Qin Long (4):
>>>   CryptoPkg/OpensslLib: Suppress extra build warnings in openssl source
>>>   CryptoPkg: Fix possible unresolved external symbol issue.
>>>   CryptoPkg/BaseCryptLib: Adding NULL checking in time() wrapper.
>>>   CryptoPkg: One workaround to resolve potential build issue.
>>>
>>>  CryptoPkg/Include/CrtLibSupport.h  |   1 +
>>>  CryptoPkg/Include/openssl/e_os2.h  | 321
>> +
>>>  .../BaseCryptLib/SysCall/ConstantTimeClock.c   |   6 +-
>>>  CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c  |  10 +-
>>>  CryptoPkg/Library/OpensslLib/OpensslLib.inf|  15 +-
>>>  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |  15 +-
>>>  6 files changed, 355 insertions(+), 13 deletions(-)  create mode
>>> 100644 CryptoPkg/Include/openssl/e_os2.h
>>>
>>
>> I can see the upstream OpenSSL pull req / issue report references in
>> TianoCore BZs 455 and 456.
>>
>> series
>> Reviewed-by: Laszlo Ersek 
>>
>> 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] kvm: pass the virtual SEI syndrome to guest OS

[gengdongjiu]

Dear, Laszlo
   Thanks for your detailed explanation.

On 2017/3/29 19:58, Laszlo Ersek wrote:
> (This ought to be one of the longest address lists I've ever seen :)
> Thanks for the CC. I'm glad Shannon is already on the CC list. For good
> measure, I'm adding MST and Igor.)
> 
> On 03/29/17 12:36, Achin Gupta wrote:
>> Hi gengdongjiu,
>>
>> On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote:
>>>
>>> Hi Laszlo/Biesheuvel/Qemu developer,
>>>
>>>Now I encounter a issue and want to consult with you in ARM64 platform， 
>>> as described below:
>>>
>>> when guest OS happen synchronous or asynchronous abort, kvm needs
>>> to send the error address to Qemu or UEFI through sigbus to
>>> dynamically generate APEI table. from my investigation, there are
>>> two ways:
>>>
>>> (1) Qemu get the error address, and generate the APEI table, then
>>> notify UEFI to know this generation, then inject abort error to
>>> guest OS, guest OS read the APEI table.
>>> (2) Qemu get the error address, and let UEFI to generate the APEI
>>> table, then inject abort error to guest OS, guest OS read the APEI
>>> table.
>>
>> Just being pedantic! I don't think we are talking about creating the APEI 
>> table
>> dynamically here. The issue is: Once KVM has received an error that is 
>> destined
>> for a guest it will raise a SIGBUS to Qemu. Now before Qemu can inject the 
>> error
>> into the guest OS, a CPER (Common Platform Error Record) has to be generated
>> corresponding to the error source (GHES corresponding to memory subsystem,
>> processor etc) to allow the guest OS to do anything meaningful with the
>> error. So who should create the CPER is the question.
>>
>> At the EL3/EL2 interface (Secure Firmware and OS/Hypervisor), an error 
>> arrives
>> at EL3 and secure firmware (at EL3 or a lower secure exception level) is
>> responsible for creating the CPER. ARM is experimenting with using a 
>> Standalone
>> MM EDK2 image in the secure world to do the CPER creation. This will avoid
>> adding the same code in ARM TF in EL3 (better for security). The error will 
>> then
>> be injected into the OS/Hypervisor (through SEA/SEI/SDEI) through ARM Trusted
>> Firmware.
>>
>> Qemu is essentially fulfilling the role of secure firmware at the EL2/EL1
>> interface (as discussed with Christoffer below). So it should generate the 
>> CPER
>> before injecting the error.
>>
>> This is corresponds to (1) above apart from notifying UEFI (I am assuming you
>> mean guest UEFI). At this time, the guest OS already knows where to pick up 
>> the
>> CPER from through the HEST. Qemu has to create the CPER and populate its 
>> address
>> at the address exported in the HEST. Guest UEFI should not be involved in 
>> this
>> flow. Its job was to create the HEST at boot and that has been done by this
>> stage.
>>
>> Qemu folk will be able to add but it looks like support for CPER generation 
>> will
>> need to be added to Qemu. We need to resolve this.
>>
>> Do shout if I am missing anything above.
> 
> After reading this email, the use case looks *very* similar to what
> we've just done with VMGENID for QEMU 2.9.
> 
> We have a facility between QEMU and the guest firmware, called "ACPI
> linker/loader", with which QEMU instructs the firmware to
> 
> - allocate and download blobs into guest RAM (AcpiNVS type memory) --
> ALLOCATE command,
> 
> - relocate pointers in those blobs, to fields in other (or the same)
> blobs -- ADD_POINTER command,
> 
> - set ACPI table checksums -- ADD_CHECKSUM command,
> 
> - and send GPAs of fields within such blobs back to QEMU --
> WRITE_POINTER command.
> 
> This is how I imagine we can map the facility to the current use case
> (note that this is the first time I read about HEST / GHES / CPER):
> 
> etc/acpi/tables etc/hardware_errors
>  ==
>  +---+
> +--+ | address   | +-> +--+
> |HEST  + | registers | |   | Error Status |
> + ++ | +-+ |   | Data Block 1 |
> | | GHES   | --> | | address | +   | ++
> | | GHES   | --> | | address | --+ | |  CPER  |
> | | GHES   | --> | | address | + | | |  CPER  |
> | | GHES   | --> | | address | -+  | | | |  CPER  |
> +-++ +-+-+  |  | | +-++
> |  | |
> |  | +---> +--+
> |  |   | Error Status |
> |  |   | Data Block 2 |
> |  |   | ++
> |  |   | |  CPER  |
> |  |   | |  CPER  |
> 

Re: [edk2] [PATCH 2/2] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

[Ryan Harkin]

On 6 April 2017 at 12:32, Ard Biesheuvel  wrote:
> On 6 April 2017 at 12:14, Ryan Harkin  wrote:
>> On 5 April 2017 at 21:38, Ard Biesheuvel  wrote:
>>> Replace the uncached memory mapping of the framebuffer with a write-
>>> combining one. This improves performance, and avoids issues with
>>> unaligned accesses and DC ZVA instructions performed by the accelerated
>>> memcpy/memset routines.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>
>> Well, ... PL111 isn't usually enabled for me. And if I enable it,
>> neither Foundation nor AEMv8 models boot with or without this patch.
>>
>> So it's no worse than before
>>
>
> Not even foundation model? That is strange ...
>

The reason we created a config without PL111 was because Foundation
didn't originally have a PL111. And I wanted a single binary to run on
Foundation and AEMv8. But ARM added it to Foundation about a year ago
and I've never tried it.

I'm happy for you to submit the patch if it works for you.


>>
>>> ---
>>>  
>>> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>>  | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git 
>>> a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>>  
>>> b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>> index 2000c9bdf436..d18d6b3e1665 100644
>>> --- 
>>> a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>> +++ 
>>> b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>> @@ -192,7 +192,7 @@ LcdPlatformGetVram (
>>>  ASSERT_EFI_ERROR(Status);
>>>
>>>  // Mark the VRAM as un-cachable. The VRAM is inside the DRAM, which is 
>>> cachable.
>>> -Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
>>> EFI_MEMORY_UC);
>>> +Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
>>> EFI_MEMORY_WC);
>>>  ASSERT_EFI_ERROR(Status);
>>>  if (EFI_ERROR(Status)) {
>>>gBS->FreePool(VramBaseAddress);
>>> --
>>> 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/2] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

[Ard Biesheuvel]

On 6 April 2017 at 12:14, Ryan Harkin  wrote:
> On 5 April 2017 at 21:38, Ard Biesheuvel  wrote:
>> Replace the uncached memory mapping of the framebuffer with a write-
>> combining one. This improves performance, and avoids issues with
>> unaligned accesses and DC ZVA instructions performed by the accelerated
>> memcpy/memset routines.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>
> Well, ... PL111 isn't usually enabled for me. And if I enable it,
> neither Foundation nor AEMv8 models boot with or without this patch.
>
> So it's no worse than before
>

Not even foundation model? That is strange ...

>
>> ---
>>  
>> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>  | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>  
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>> index 2000c9bdf436..d18d6b3e1665 100644
>> --- 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>> +++ 
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>> @@ -192,7 +192,7 @@ LcdPlatformGetVram (
>>  ASSERT_EFI_ERROR(Status);
>>
>>  // Mark the VRAM as un-cachable. The VRAM is inside the DRAM, which is 
>> cachable.
>> -Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
>> EFI_MEMORY_UC);
>> +Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
>> EFI_MEMORY_WC);
>>  ASSERT_EFI_ERROR(Status);
>>  if (EFI_ERROR(Status)) {
>>gBS->FreePool(VramBaseAddress);
>> --
>> 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 v2 0/4] Resolving Some CryptoPkg Build Issues

[Long, Qin]

Thanks, Laszlo. 

And the last "workaround" patch can be dropped, since we introduced the new 
[Includes.Common.Private] setting in Package DEC file (from my last patch). 
This will help to eliminate the potential macro re-definition risk. 
It's still valuable to refine openssl e_os2.h definition for consistence, which 
was submitted / approved by the PR 
(https://github.com/openssl/openssl/pull/3121)


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, April 6, 2017 4:55 PM
> To: Long, Qin ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Hao A ; Tian,
> Feng ; Dong, Eric 
> Subject: Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues
> 
> On 04/01/17 07:38, Long Qin wrote:
> > From: Qin Long 
> >
> > V2:
> >   Updated the patches as the comments from Laszlo (ler...@redhat.com).
> >   And filed two TianoCore BZ (#455, #456) to track the further follow-ups
> >   on openssl and EDKII-CryptoPkg:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=455
> > https://bugzilla.tianocore.org/show_bug.cgi?id=456
> >
> > This patch series introduced some hotfixes and workaround to resolve
> > the build issues under different toolchain, and from potential
> > external consumers, including:
> >   - build warning under GCC48 and VS2010 toolchain;
> >   - Potential unresolved external symbol link issue;
> >   - One bug fix of timer() wrapper in ConstantTimeClock.c;
> >   - One workaround to resolve macro re-definitions issue from some
> > external BaseCryptLib consumer.
> >
> >   (https://github.com/qloong/edk2/commits/dev-openssl-hotfix)
> >
> > Qin Long (4):
> >   CryptoPkg/OpensslLib: Suppress extra build warnings in openssl source
> >   CryptoPkg: Fix possible unresolved external symbol issue.
> >   CryptoPkg/BaseCryptLib: Adding NULL checking in time() wrapper.
> >   CryptoPkg: One workaround to resolve potential build issue.
> >
> >  CryptoPkg/Include/CrtLibSupport.h  |   1 +
> >  CryptoPkg/Include/openssl/e_os2.h  | 321
> +
> >  .../BaseCryptLib/SysCall/ConstantTimeClock.c   |   6 +-
> >  CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c  |  10 +-
> >  CryptoPkg/Library/OpensslLib/OpensslLib.inf|  15 +-
> >  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |  15 +-
> >  6 files changed, 355 insertions(+), 13 deletions(-)  create mode
> > 100644 CryptoPkg/Include/openssl/e_os2.h
> >
> 
> I can see the upstream OpenSSL pull req / issue report references in
> TianoCore BZs 455 and 456.
> 
> series
> Reviewed-by: Laszlo Ersek 
> 
> Thanks!
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/2] ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM

[Ryan Harkin]

On 6 April 2017 at 11:40, Ard Biesheuvel  wrote:
> On 6 April 2017 at 10:37, Leif Lindholm  wrote:
>> On Wed, Apr 05, 2017 at 09:38:32PM +0100, Ard Biesheuvel wrote:
>>> Replace the uncached memory mapping of the framebuffer with a write-
>>> combining one. This improves performance, and avoids issues with
>>> unaligned accesses and DC ZVA instructions performed by the accelerated
>>> memcpy/memset routines.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>
>> If you can get a nod each from Ryan and Evan, for the series:
>> Reviewed-by: Leif Lindholm 
>>
>>> ---
>>>  
>>> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>>  | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git 
>>> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>>  
>>> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>> index a57846715ed7..d6d47545c824 100644
>>> --- 
>>> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>> +++ 
>>> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>> @@ -143,7 +143,7 @@ LcdPlatformGetVram (
>>>ASSERT_EFI_ERROR(Status);
>>>
>>>// Mark the VRAM as un-cacheable. The VRAM is inside the DRAM, which is 
>>> cacheable.
>>> -  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
>>> EFI_MEMORY_UC);
>>> +  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
>>> EFI_MEMORY_WC);
>>>ASSERT_EFI_ERROR(Status);
>>>if (EFI_ERROR(Status)) {
>>>  gBS->FreePool (VramBaseAddress);
>
> Actually, it would be more appropriate for this code to use DXE services, 
> i.e.,
>
> gDS->SetMemorySpaceAttributes (xxx)
>
> which internally calls Cpu->SetMemoryAttributes(), but also checks the
> validity of the request against the capabilities of the region

Ach! I've just tested this patch :-)

Anyway, it works fine on TC2.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

[Ryan Harkin]

On 5 April 2017 at 21:38, Ard Biesheuvel  wrote:
> Replace the uncached memory mapping of the framebuffer with a write-
> combining one. This improves performance, and avoids issues with
> unaligned accesses and DC ZVA instructions performed by the accelerated
> memcpy/memset routines.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Well, ... PL111 isn't usually enabled for me. And if I enable it,
neither Foundation nor AEMv8 models boot with or without this patch.

So it's no worse than before


> ---
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>  | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git 
> a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>  
> b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
> index 2000c9bdf436..d18d6b3e1665 100644
> --- 
> a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
> +++ 
> b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
> @@ -192,7 +192,7 @@ LcdPlatformGetVram (
>  ASSERT_EFI_ERROR(Status);
>
>  // Mark the VRAM as un-cachable. The VRAM is inside the DRAM, which is 
> cachable.
> -Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
> EFI_MEMORY_UC);
> +Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
> EFI_MEMORY_WC);
>  ASSERT_EFI_ERROR(Status);
>  if (EFI_ERROR(Status)) {
>gBS->FreePool(VramBaseAddress);
> --
> 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] How to get fs index from controller handle.

[Andrew Fish]

> On Apr 6, 2017, at 3:30 AM, Amit kumar  wrote:
> 
> Hi,
> 
> I want to get the fs index from the controller handle.
> e.g In map command i see my controller is mapped to fs10. 
> So i there any API i can use in my code to get the fs index( which is 10 as 
> in example) from the controller handle. 
> 

Amit,

It is important to remember that fs0:, and the other device names are a Shell 
concept and not an EFI concept. So they only exist in the context of the shell. 

I took a quick look and I did not see an easy way to do this with the current 
Shell APIs. 

In the older Shell you could use this  protocol  EfiShellEnvironment2 Protocol 
has a function that converts a EFI_DEVICE_PATH_PROTOCOL (would be on your 
controller handle) to a CHAR16. Thus you can get the volume name the Shell 
would display to the user. I don't the index exists as a concept.  So  
EFI_SHELL_ENVIRONMENT2.GetFsName() and  
EFI_SHELL_ENVIRONMENT2.GetFsDevicepath() are the closest thing I can think of. 
https://github.com/tianocore/edk2/blob/master/ShellPkg/Include/Protocol/EfiShellEnvironment2.h#L812
 


The only problem with that is EfiShellEnvironment2 is not produced by the Shell 
by default. 

  ## This flag is used to control the protocols produced by the shell
  #  If TRUE the shell will produce EFI_SHELL_ENVIRONMENT2 and 
EFI_SHELL_INTERFACE
  
gEfiShellPkgTokenSpaceGuid.PcdShellSupportOldProtocols|FALSE|BOOLEAN|0x0002

I've use the EFI_SHELL_ENVIRONMENT2 in the past to enable a non Shell 
application to print out volume names that match the map command of the shell. 
Hopefully some one knows how to do this in the modern Shell?

Thanks,

Andrew Fish

> Regards 
> Amit
> ___
> 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/2] ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM

[Ard Biesheuvel]

On 6 April 2017 at 10:37, Leif Lindholm  wrote:
> On Wed, Apr 05, 2017 at 09:38:32PM +0100, Ard Biesheuvel wrote:
>> Replace the uncached memory mapping of the framebuffer with a write-
>> combining one. This improves performance, and avoids issues with
>> unaligned accesses and DC ZVA instructions performed by the accelerated
>> memcpy/memset routines.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>
> If you can get a nod each from Ryan and Evan, for the series:
> Reviewed-by: Leif Lindholm 
>
>> ---
>>  
>> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
>> | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>  
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>> index a57846715ed7..d6d47545c824 100644
>> --- 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>> +++ 
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>> @@ -143,7 +143,7 @@ LcdPlatformGetVram (
>>ASSERT_EFI_ERROR(Status);
>>
>>// Mark the VRAM as un-cacheable. The VRAM is inside the DRAM, which is 
>> cacheable.
>> -  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
>> EFI_MEMORY_UC);
>> +  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
>> EFI_MEMORY_WC);
>>ASSERT_EFI_ERROR(Status);
>>if (EFI_ERROR(Status)) {
>>  gBS->FreePool (VramBaseAddress);

Actually, it would be more appropriate for this code to use DXE services, i.e.,

gDS->SetMemorySpaceAttributes (xxx)

which internally calls Cpu->SetMemoryAttributes(), but also checks the
validity of the request against the capabilities of the region
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] How to get fs index from controller handle.

[Amit kumar]

Hi,

I want to get the fs index from the controller handle.
e.g In map command i see my controller is mapped to fs10. 
So i there any API i can use in my code to get the fs index( which is 10 as in 
example) from the controller handle. 

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

Re: [edk2] [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases

[Leif Lindholm]

On Thu, Apr 06, 2017 at 10:43:57AM +0100, Ard Biesheuvel wrote:
> On 6 April 2017 at 10:35, Leif Lindholm  wrote:
> > On Wed, Apr 05, 2017 at 10:55:49PM +0100, Ard Biesheuvel wrote:
> >> >>> I think this is a problem because nowhere in the UEFI specs do I see 
> >> >>> such
> >> >>> restrictions on those memory operations.
> >> >>
> >> >> Using device attributes for memory is something we should ban for
> >> >> AArch64 in the spec.
> >
> > Yes, completely agree. And doing so is generally the result of
> > misinderstanding the memory model (i.e., it probably won't provide the
> > guarantee that was sought).
> > Charles/Dong? Something to add to list?
> 
> As an additional note, the UEFI spec mandates that unaligned accesses
> are enabled for AArch64, which clearly expresses the intent that
> routines operating on memory should be able to do so without going out
> of its way to avoid unaligned accesses.

It does - but only if you already understand the memory model.

> > Can we insert a test preventing device memory type to be set for
> > regions with _WB attribute? Or is that already only possible through
> > manual trickery?
> 
> We should simply remove the _UC attribute from all memory. I have
> already done so for many of the platforms I more or less maintain (and
> for virt, we removed _WT and _WC as well, because KVM only supports
> _WB)

Agreed.

> Note that this does not prevent the NOR and RTC drivers from creating
> _UC regions for their own MMIO registers, it just prevents them from
> being remapped _UC via the DXE services.

OK, good.

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

[edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: Enhance short-form expanding logic

[Ruiyu Ni]

Old implementation only finds first matched full device path for a
given short-form device path.
The patch adds internal function BmGetNextLoadOptionBuffer() to finds
all matched full device path for a given short-form device path.
There are 6 kinds of device paths. Some of them match to multiple
load options, some of them don't.

1. Media device path:
   Returns multiple load options: The media device path may point
   to a physical BlockIo which contains multiple logic partitions,
   each logic partitions contains \EFI\BOOT\BOOT${ARCH}.EFI.

2. Short-form hard-drive device path:
   Returns one load option because the partition signature is unique.

3. Short-form file-path device path:
   Returns multiple load options: There are multiple SimpleFileSystem
   instances and each contains the same file.

4. Short-form URI device path:
   Returns multiple load options: There are multiple LoadFile
   instances and each can boot.

5. Short-form USB device path:
   Returns multiple load options: There are multiple UsbIo instances
   and each contains the boot-able file.

6. FV device path, device path pointing to SimpleFileSystem, device
   path pointing to LoadFile
   Returns one load option.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
Cc: Eric Dong 
Cc: Jeff Fan 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   | 470 -
 .../Library/UefiBootManagerLib/BmLoadOption.c  | 173 ++--
 .../Library/UefiBootManagerLib/InternalBm.h| 100 +++--
 3 files changed, 475 insertions(+), 268 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 8a3a402..aa79c90 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -131,21 +131,16 @@ BmFindBootOptionInVariable (
 }
 
 /**
-  Get the file buffer using a Memory Mapped Device Path.
-
+  Return the correct FV file path.
   FV address may change across reboot. This routine promises the FV file 
device path is right.
 
   @param  FilePath The Memory Mapped Device Path to get the file buffer.
-  @param  FullPath Receive the updated FV Device Path pointint to the file.
-  @param  FileSize Receive the file buffer size.
 
-  @return  The file buffer.
+  @return  The updated FV Device Path pointint to the file.
 **/
-VOID *
-BmGetFileBufferByFvFilePath (
-  IN EFI_DEVICE_PATH_PROTOCOL  *FilePath,
-  OUT EFI_DEVICE_PATH_PROTOCOL **FullPath,
-  OUT UINTN*FileSize
+EFI_DEVICE_PATH_PROTOCOL *
+BmAdjustFvFilePath (
+  IN EFI_DEVICE_PATH_PROTOCOL  *FilePath
   )
 {
   EFI_STATUSStatus;
@@ -153,11 +148,10 @@ BmGetFileBufferByFvFilePath (
   EFI_DEVICE_PATH_PROTOCOL  *FvFileNode;
   EFI_HANDLEFvHandle;
   EFI_LOADED_IMAGE_PROTOCOL *LoadedImage;
-  UINT32AuthenticationStatus;
   UINTN FvHandleCount;
   EFI_HANDLE*FvHandles;
   EFI_DEVICE_PATH_PROTOCOL  *NewDevicePath;
-  VOID  *FileBuffer;
+  EFI_DEVICE_PATH_PROTOCOL  *FullPath;
 
   //
   // Get the file buffer by using the exactly FilePath.
@@ -165,11 +159,7 @@ BmGetFileBufferByFvFilePath (
   FvFileNode = FilePath;
   Status = gBS->LocateDevicePath (, 
, );
   if (!EFI_ERROR (Status)) {
-FileBuffer = GetFileBufferByFilePath (TRUE, FilePath, FileSize, 
);
-if (FileBuffer != NULL) {
-  *FullPath = DuplicateDevicePath (FilePath);
-}
-return FileBuffer;
+return DuplicateDevicePath (FilePath);
   }
 
   //
@@ -190,11 +180,10 @@ BmGetFileBufferByFvFilePath (
  (VOID **) 
  );
   NewDevicePath = AppendDevicePathNode (DevicePathFromHandle 
(LoadedImage->DeviceHandle), FvFileNode);
-  FileBuffer = BmGetFileBufferByFvFilePath (NewDevicePath, FullPath, FileSize);
+  FullPath = BmAdjustFvFilePath (NewDevicePath);
   FreePool (NewDevicePath);
-
-  if (FileBuffer != NULL) {
-return FileBuffer;
+  if (FullPath != NULL) {
+return FullPath;
   }
 
   //
@@ -207,22 +196,25 @@ BmGetFileBufferByFvFilePath (
  ,
  
  );
-  for (Index = 0; (Index < FvHandleCount) && (FileBuffer == NULL); Index++) {
+  for (Index = 0; Index < FvHandleCount; Index++) {
 if (FvHandles[Index] == LoadedImage->DeviceHandle) {
   //
-  // Skip current FV
+  // Skip current FV, it was handed in first step.
   //
   continue;
 }
 NewDevicePath = AppendDevicePathNode (DevicePathFromHandle 
(FvHandles[Index]), FvFileNode);
-FileBuffer = BmGetFileBufferByFvFilePath (NewDevicePath, FullPath, 
FileSize);
+FullPath = BmAdjustFvFilePath (NewDevicePath);
 FreePool (NewDevicePath);
+if (FullPath != NULL) {
+  break;
+}
   }
   
   if (FvHandles != NULL) {
 

Re: [edk2] [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases

[Ard Biesheuvel]

On 6 April 2017 at 10:35, Leif Lindholm  wrote:
> On Wed, Apr 05, 2017 at 10:55:49PM +0100, Ard Biesheuvel wrote:
>> >>> I think this is a problem because nowhere in the UEFI specs do I see such
>> >>> restrictions on those memory operations.
>> >>
>> >> Using device attributes for memory is something we should ban for
>> >> AArch64 in the spec.
>
> Yes, completely agree. And doing so is generally the result of
> misinderstanding the memory model (i.e., it probably won't provide the
> guarantee that was sought).
> Charles/Dong? Something to add to list?
>

As an additional note, the UEFI spec mandates that unaligned accesses
are enabled for AArch64, which clearly expresses the intent that
routines operating on memory should be able to do so without going out
of its way to avoid unaligned accesses.

> Can we insert a test preventing device memory type to be set for
> regions with _WB attribute? Or is that already only possible through
> manual trickery?
>

We should simply remove the _UC attribute from all memory. I have
already done so for many of the platforms I more or less maintain (and
for virt, we removed _WT and _WC as well, because KVM only supports
_WB)

Note that this does not prevent the NOR and RTC drivers from creating
_UC regions for their own MMIO registers, it just prevents them from
being remapped _UC via the DXE services.

>> >>> For a specific problematic example, the LcdGraphicsOutputBlt.c uses it
>> >>> for
>> >>> BltVideoFill() and the target of that is likely not regular cached video
>> >>> memory.
>> >>
>> >> Those drivers should be using EFI_MEMORY_WC not EFI_MEMORY_UC for the
>> >> VRAM mapping. Note that EFI_MEMORY_UC is nGnRnE which is unnecessarily
>> >> restrictive.
>> >>
>> >> I agree there is a general issue here which we should address by
>> >> tightening the spec. I don't see a lot of value in avoiding DC ZVA and
>> >> unaligned accesses altogether, I'd rather fix the code instead.
>> >
>> > While I agree with the general sentiment, I find the result brittle. If it
>> > were used as a DEBUG build way to locate sub-optmimal code I would be more
>> > on board. But shipping it like this, puts it into situations where the user
>> > inadvertently changes something (say making the background black and
>> > therefore triggering the DC) or some obscure option ROM (we will get there
>> > right??!!) triggers it in a place where it can't be debugged.
>> >
>> > Particularly since we are talking boot, where the few percent perf
>> > improvement on this operation is likely completely undetectable. The one
>> > place where I can think it might even be measurable is in routines to clear
>> > system memory, and those routines could be a special case anyway.
>>
>> I guess this depends on the use case. For server, it may not matter,
>> but the case is different for mobile, and the Broadcom engineers that
>> did some benchmarks on this code were very pleased with the result
>> (and the speedup was significant, although I don't know which routines
>> are the hotspots)
>>
>> As for option ROMs: those will link to their own BaseMemoryLib
>> implementation (assuming that they are EDK2 based) so the only way
>> they would have access to these routines is via the CopyMem() and
>> SetMem() boot services. Note that that does not dismiss the concern at
>> all, it is just a clarification.
>>
>> Leif, any thoughts?
>
> I would prefer if we could resolve this without waiting for a new spec
> version.
>
> My gut feeling is that the (end-user, I care a _lot_ less
> about development platforms) devices that _could_ be affected by this
> won't be releasing updated firmwares completely rebased onto a newer
> edk2 HEAD. Rather they're likely to be cherry-picking individual
> bugfixes and improvements.
>
> But certainly having some input from abovementioned Broadcom team,
> Evan & co, and others is important before we make a call.
>
> /
> Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/2] ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM

[Leif Lindholm]

On Wed, Apr 05, 2017 at 09:38:32PM +0100, Ard Biesheuvel wrote:
> Replace the uncached memory mapping of the framebuffer with a write-
> combining one. This improves performance, and avoids issues with
> unaligned accesses and DC ZVA instructions performed by the accelerated
> memcpy/memset routines.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

If you can get a nod each from Ryan and Evan, for the series:
Reviewed-by: Leif Lindholm 

> ---
>  ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
> | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>  
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
> index a57846715ed7..d6d47545c824 100644
> --- 
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
> +++ 
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
> @@ -143,7 +143,7 @@ LcdPlatformGetVram (
>ASSERT_EFI_ERROR(Status);
>  
>// Mark the VRAM as un-cacheable. The VRAM is inside the DRAM, which is 
> cacheable.
> -  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
> EFI_MEMORY_UC);
> +  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
> EFI_MEMORY_WC);
>ASSERT_EFI_ERROR(Status);
>if (EFI_ERROR(Status)) {
>  gBS->FreePool (VramBaseAddress);
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases

[Leif Lindholm]

On Wed, Apr 05, 2017 at 10:55:49PM +0100, Ard Biesheuvel wrote:
> >>> I think this is a problem because nowhere in the UEFI specs do I see such
> >>> restrictions on those memory operations.
> >>
> >> Using device attributes for memory is something we should ban for
> >> AArch64 in the spec.

Yes, completely agree. And doing so is generally the result of
misinderstanding the memory model (i.e., it probably won't provide the
guarantee that was sought).
Charles/Dong? Something to add to list?

Can we insert a test preventing device memory type to be set for
regions with _WB attribute? Or is that already only possible through
manual trickery?

> >>> For a specific problematic example, the LcdGraphicsOutputBlt.c uses it
> >>> for
> >>> BltVideoFill() and the target of that is likely not regular cached video
> >>> memory.
> >>
> >> Those drivers should be using EFI_MEMORY_WC not EFI_MEMORY_UC for the
> >> VRAM mapping. Note that EFI_MEMORY_UC is nGnRnE which is unnecessarily
> >> restrictive.
> >>
> >> I agree there is a general issue here which we should address by
> >> tightening the spec. I don't see a lot of value in avoiding DC ZVA and
> >> unaligned accesses altogether, I'd rather fix the code instead.
> >
> > While I agree with the general sentiment, I find the result brittle. If it
> > were used as a DEBUG build way to locate sub-optmimal code I would be more
> > on board. But shipping it like this, puts it into situations where the user
> > inadvertently changes something (say making the background black and
> > therefore triggering the DC) or some obscure option ROM (we will get there
> > right??!!) triggers it in a place where it can't be debugged.
> >
> > Particularly since we are talking boot, where the few percent perf
> > improvement on this operation is likely completely undetectable. The one
> > place where I can think it might even be measurable is in routines to clear
> > system memory, and those routines could be a special case anyway.
> 
> I guess this depends on the use case. For server, it may not matter,
> but the case is different for mobile, and the Broadcom engineers that
> did some benchmarks on this code were very pleased with the result
> (and the speedup was significant, although I don't know which routines
> are the hotspots)
> 
> As for option ROMs: those will link to their own BaseMemoryLib
> implementation (assuming that they are EDK2 based) so the only way
> they would have access to these routines is via the CopyMem() and
> SetMem() boot services. Note that that does not dismiss the concern at
> all, it is just a clarification.
>
> Leif, any thoughts?

I would prefer if we could resolve this without waiting for a new spec
version.

My gut feeling is that the (end-user, I care a _lot_ less
about development platforms) devices that _could_ be affected by this
won't be releasing updated firmwares completely rebased onto a newer
edk2 HEAD. Rather they're likely to be cherry-picking individual
bugfixes and improvements.

But certainly having some input from abovementioned Broadcom team,
Evan & co, and others is important before we make a call.

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

[edk2] [patch] NetworkPkg: Add check logic for iSCSI driver.

[Zhang Lubo]

Need to check variable of mPrivate whether is
null before used and redefine the array length
of target address for keyword.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Fu Siyuan 
---
 NetworkPkg/IScsiDxe/IScsiConfig.c| 30 ++--
 NetworkPkg/IScsiDxe/IScsiConfigNVDataStruc.h |  2 +-
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c 
b/NetworkPkg/IScsiDxe/IScsiConfig.c
index 56a8685..a588403 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfig.c
+++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
@@ -742,28 +742,28 @@ IScsiConvertAttemptConfigDataToIfrNvDataByKeyword (
   ISCSI_CHAP_SECRET_STORAGE
   );
   }
 }
 CopyMem(IfrNvData->ISCSIDisplayAttemptList, AttemptNameList, 
ATTEMPT_NAME_LIST_SIZE);
-  }
 
-  NET_LIST_FOR_EACH (Entry, >NicInfoList) {
-NicInfo = NET_LIST_USER_STRUCT (Entry, ISCSI_NIC_INFO, Link);
-IScsiMacAddrToStr (
->PermanentAddress,
-NicInfo->HwAddressSize,
-NicInfo->VlanId,
-MacString
-);
-CopyMem (
-  IfrNvData->ISCSIMacAddr + StrLen (IfrNvData->ISCSIMacAddr),
-  MacString,
-  StrLen (MacString) * sizeof (CHAR16)
+NET_LIST_FOR_EACH (Entry, >NicInfoList) {
+  NicInfo = NET_LIST_USER_STRUCT (Entry, ISCSI_NIC_INFO, Link);
+  IScsiMacAddrToStr (
+  >PermanentAddress,
+  NicInfo->HwAddressSize,
+  NicInfo->VlanId,
+  MacString
   );
+  CopyMem (
+IfrNvData->ISCSIMacAddr + StrLen (IfrNvData->ISCSIMacAddr),
+MacString,
+StrLen (MacString) * sizeof (CHAR16)
+);
 
-*(IfrNvData->ISCSIMacAddr + StrLen (IfrNvData->ISCSIMacAddr)) = L'/';
-   }
+  *(IfrNvData->ISCSIMacAddr + StrLen (IfrNvData->ISCSIMacAddr)) = L'/';
+ } 
+  }
 }
 
 /**
   Convert the IFR data to iSCSI configuration data.
 
diff --git a/NetworkPkg/IScsiDxe/IScsiConfigNVDataStruc.h 
b/NetworkPkg/IScsiDxe/IScsiConfigNVDataStruc.h
index f89f320..22119ad 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfigNVDataStruc.h
+++ b/NetworkPkg/IScsiDxe/IScsiConfigNVDataStruc.h
@@ -160,11 +160,11 @@ typedef struct {
   CHAR16  ISCSIIsId[ISID_CONFIGURABLE_STORAGE];
   CHAR16  ISCSIInitiatorIpAddress[IP4_STR_MAX_SIZE];
   CHAR16  ISCSIInitiatorNetmask[IP4_STR_MAX_SIZE];
   CHAR16  ISCSIInitiatorGateway[IP4_STR_MAX_SIZE];
   CHAR16  ISCSITargetName[ISCSI_NAME_MAX_SIZE];
-  CHAR16  ISCSITargetIpAddress[IP_STR_MAX_SIZE];
+  CHAR16  ISCSITargetIpAddress[ISCSI_TARGET_URI_MAX_SIZE];
   CHAR16  ISCSILun[ISCSI_LUN_STR_MAX_LEN];
   CHAR16  ISCSIChapUsername[ISCSI_CHAP_NAME_STORAGE];
   CHAR16  ISCSIChapSecret[ISCSI_CHAP_SECRET_STORAGE];
   CHAR16  ISCSIReverseChapUsername[ISCSI_CHAP_NAME_STORAGE];
   CHAR16  ISCSIReverseChapSecret[ISCSI_CHAP_SECRET_STORAGE];
-- 
1.9.5.msysgit.1

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

[edk2] [patch] NetworkPkg: Fix bug related DAD issue in IP6 driver.

[Zhang Lubo]

If we set PXEv6 as the first boot option and reboot immediately
after the first successful boot, it will assert. the root cause is
when we set the policy from manual to automatic in PXE driver,
the ip6 Configure item size is already set to zero and other
structures are also released, So it is not needed to perform DAD call
back function which is invoked by Ip6ConfigSetMaunualAddress.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Fu Siyuan 
---
 NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c 
b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
index bde5982..7575b79 100644
--- a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
+++ b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
@@ -782,10 +782,14 @@ Ip6ManualAddrDadCallback (
   Instance   = (IP6_CONFIG_INSTANCE *) Context;
   NET_CHECK_SIGNATURE (Instance, IP6_CONFIG_INSTANCE_SIGNATURE);
   Item   = >DataItem[Ip6ConfigDataTypeManualAddress];
   ManualAddr = NULL;
 
+  if (Item->DataSize == 0) {
+return;
+  }
+
   for (Index = 0; Index < Item->DataSize / sizeof 
(EFI_IP6_CONFIG_MANUAL_ADDRESS); Index++) {
 //
 // Find the original tag used to place into the NET_MAP.
 //
 ManualAddr = Item->Data.ManualAddress + Index;
-- 
1.9.5.msysgit.1

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

Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues

[Laszlo Ersek]

On 04/01/17 07:38, Long Qin wrote:
> From: Qin Long 
> 
> V2:
>   Updated the patches as the comments from Laszlo (ler...@redhat.com).
>   And filed two TianoCore BZ (#455, #456) to track the further follow-ups
>   on openssl and EDKII-CryptoPkg:
> https://bugzilla.tianocore.org/show_bug.cgi?id=455
> https://bugzilla.tianocore.org/show_bug.cgi?id=456
> 
> This patch series introduced some hotfixes and workaround to resolve
> the build issues under different toolchain, and from potential external
> consumers, including:
>   - build warning under GCC48 and VS2010 toolchain;
>   - Potential unresolved external symbol link issue;
>   - One bug fix of timer() wrapper in ConstantTimeClock.c;
>   - One workaround to resolve macro re-definitions issue from some
> external BaseCryptLib consumer.
> 
>   (https://github.com/qloong/edk2/commits/dev-openssl-hotfix)
> 
> Qin Long (4):
>   CryptoPkg/OpensslLib: Suppress extra build warnings in openssl source
>   CryptoPkg: Fix possible unresolved external symbol issue.
>   CryptoPkg/BaseCryptLib: Adding NULL checking in time() wrapper.
>   CryptoPkg: One workaround to resolve potential build issue.
> 
>  CryptoPkg/Include/CrtLibSupport.h  |   1 +
>  CryptoPkg/Include/openssl/e_os2.h  | 321 
> +
>  .../BaseCryptLib/SysCall/ConstantTimeClock.c   |   6 +-
>  CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c  |  10 +-
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf|  15 +-
>  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |  15 +-
>  6 files changed, 355 insertions(+), 13 deletions(-)
>  create mode 100644 CryptoPkg/Include/openssl/e_os2.h
> 

I can see the upstream OpenSSL pull req / issue report references in
TianoCore BZs 455 and 456.

series
Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC -fno-builtin option

[Zeng, Star]

With that, you can have my Reviewed-by: Star Zeng 

Thanks,
Star
-Original Message-
From: Gao, Liming 
Sent: Thursday, April 6, 2017 4:40 PM
To: Zeng, Star ; edk2-devel@lists.01.org
Subject: RE: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC 
-fno-builtin option

Good suggestion. I will update commit log. 

>-Original Message-
>From: Zeng, Star
>Sent: Thursday, April 06, 2017 4:22 PM
>To: Gao, Liming ; edk2-devel@lists.01.org
>Cc: Zeng, Star 
>Subject: RE: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove 
>GCC -fno-builtin option
>
>How about to indicate the SHA-1:
>90defe7198a42b3157ae5d9b93714f891cf06e57 in the commit log like below?
>
>GCC -fno-builtin option is added into tools_def.template at 
>90defe7198a42b3157ae5d9b93714f891cf06e57.
>So, there is no need to set it in module INF file.
>
>Thanks,
>Star
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>Liming Gao
>Sent: Thursday, April 6, 2017 4:15 PM
>To: edk2-devel@lists.01.org
>Cc: Zeng, Star 
>Subject: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC - 
>fno-builtin option
>
>GCC -fno-builtin option is added into tools_def.template. So, there is 
>no need to set it in module INF file.
>
>Cc: Star Zeng 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Liming Gao 
>---
> MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>| 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git
>a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.in
>f
>b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.in
>f
>index cfe42a6..d4d9a83 100644
>---
>a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.in
>f
>+++
>b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.i
>+++ nf
>@@ -81,7 +81,6 @@
>   MSFT:DEBUG_*_IPF_CC_FLAGS== /nologo /c /WX /GS- /W4 /EHs-c- /GR-
>/Gy /Os /FIAutoGen.h /QIPF_fr32 /Zi /X
>   MSFT:RELEASE_*_IPF_CC_FLAGS  == /nologo /c /WX /GS- /W4 /EHs-c- /GR- 
>/Gy /Os /FIAutoGen.h /QIPF_fr32 /X
>   INTEL:*_*_*_CC_FLAGS =  /Oi-
>-  GCC:*_*_*_CC_FLAGS   =  -fno-builtin
>
>   # Oniguruma: potentially uninitialized local variable used
>   MSFT:*_*_*_CC_FLAGS = /wd4701
>--
>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] CryptoPkg: Move openssl and CRT headers to private include section

[Ye, Ting]

Reviewed-by: Ye Ting  

-Original Message-
From: Long, Qin 
Sent: Thursday, April 6, 2017 1:56 PM
To: Gao, Liming ; Ye, Ting 
Cc: edk2-devel@lists.01.org; Long, Qin 
Subject: [Patch] CryptoPkg: Move openssl and CRT headers to private include 
section

Moving the header files for openssl and CRT wrappers to the private include 
section, since these files should be referenced by CryptoPkg internally. This 
update was supported by new [Includes.Common.Private] setting in Package DEC 
file.
The external consumer modules should only use the interfaces defined in 
BaseCryptLib.h to access crypto functions. This change will be helpful to 
immediately detect any illegal direct reference to internal openssl headers.
The Perl script "process_files.pl" was also updated to reflect the new private 
include path.

Cc: Gao Liming 
Cc: Ting Ye 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
Signed-off-by: Long Qin 
---
 CryptoPkg/CryptoPkg.dec   | 3 +++
 CryptoPkg/{ => Library}/Include/CrtLibSupport.h   | 0
 CryptoPkg/{ => Library}/Include/assert.h  | 0
 CryptoPkg/{ => Library}/Include/ctype.h   | 0
 CryptoPkg/{ => Library}/Include/errno.h   | 0
 CryptoPkg/{ => Library}/Include/internal/dso_conf.h   | 0
 CryptoPkg/{ => Library}/Include/limits.h  | 0
 CryptoPkg/{ => Library}/Include/memory.h  | 0
 CryptoPkg/{ => Library}/Include/openssl/opensslconf.h | 0
 CryptoPkg/{ => Library}/Include/stdarg.h  | 0
 CryptoPkg/{ => Library}/Include/stddef.h  | 0
 CryptoPkg/{ => Library}/Include/stdio.h   | 0
 CryptoPkg/{ => Library}/Include/stdlib.h  | 0
 CryptoPkg/{ => Library}/Include/string.h  | 0
 CryptoPkg/{ => Library}/Include/strings.h | 0
 CryptoPkg/{ => Library}/Include/sys/time.h| 0
 CryptoPkg/{ => Library}/Include/sys/types.h   | 0
 CryptoPkg/{ => Library}/Include/syslog.h  | 0
 CryptoPkg/{ => Library}/Include/time.h| 0
 CryptoPkg/{ => Library}/Include/unistd.h  | 0
 CryptoPkg/Library/OpensslLib/process_files.pl | 2 +-
 21 files changed, 4 insertions(+), 1 deletion(-)  rename CryptoPkg/{ => 
Library}/Include/CrtLibSupport.h (100%)  rename CryptoPkg/{ => 
Library}/Include/assert.h (100%)  rename CryptoPkg/{ => 
Library}/Include/ctype.h (100%)  rename CryptoPkg/{ => Library}/Include/errno.h 
(100%)  rename CryptoPkg/{ => Library}/Include/internal/dso_conf.h (100%)  
rename CryptoPkg/{ => Library}/Include/limits.h (100%)  rename CryptoPkg/{ => 
Library}/Include/memory.h (100%)  rename CryptoPkg/{ => 
Library}/Include/openssl/opensslconf.h (100%)  rename CryptoPkg/{ => 
Library}/Include/stdarg.h (100%)  rename CryptoPkg/{ => 
Library}/Include/stddef.h (100%)  rename CryptoPkg/{ => 
Library}/Include/stdio.h (100%)  rename CryptoPkg/{ => 
Library}/Include/stdlib.h (100%)  rename CryptoPkg/{ => 
Library}/Include/string.h (100%)  rename CryptoPkg/{ => 
Library}/Include/strings.h (100%)  rename CryptoPkg/{ => 
Library}/Include/sys/time.h (100%)  rename CryptoPkg/{ => 
Library}/Include/sys/types.h (100%)  rename CryptoPkg/
 { => Library}/Include/syslog.h (100%)  rename CryptoPkg/{ => 
Library}/Include/time.h (100%)  rename CryptoPkg/{ => Library}/Include/unistd.h 
(100%)

diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec index 
fdccbf06f7..b2fae6142a 100644
--- a/CryptoPkg/CryptoPkg.dec
+++ b/CryptoPkg/CryptoPkg.dec
@@ -24,6 +24,9 @@
 
 [Includes]
   Include
+
+[Includes.Common.Private]
+  Library/Include
   Library/OpensslLib/openssl/include
   Library/OpensslLib/openssl/crypto/include
 
diff --git a/CryptoPkg/Include/CrtLibSupport.h 
b/CryptoPkg/Library/Include/CrtLibSupport.h
similarity index 100%
rename from CryptoPkg/Include/CrtLibSupport.h rename to 
CryptoPkg/Library/Include/CrtLibSupport.h
diff --git a/CryptoPkg/Include/assert.h b/CryptoPkg/Library/Include/assert.h
similarity index 100%
rename from CryptoPkg/Include/assert.h
rename to CryptoPkg/Library/Include/assert.h
diff --git a/CryptoPkg/Include/ctype.h b/CryptoPkg/Library/Include/ctype.h
similarity index 100%
rename from CryptoPkg/Include/ctype.h
rename to CryptoPkg/Library/Include/ctype.h diff --git 
a/CryptoPkg/Include/errno.h b/CryptoPkg/Library/Include/errno.h
similarity index 100%
rename from CryptoPkg/Include/errno.h
rename to CryptoPkg/Library/Include/errno.h diff --git 
a/CryptoPkg/Include/internal/dso_conf.h 
b/CryptoPkg/Library/Include/internal/dso_conf.h
similarity index 100%
rename from CryptoPkg/Include/internal/dso_conf.h
rename to CryptoPkg/Library/Include/internal/dso_conf.h
diff --git a/CryptoPkg/Include/limits.h b/CryptoPkg/Library/Include/limits.h
similarity index 100%
rename from CryptoPkg/Include/limits.h
rename 

Re: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC -fno-builtin option

[Gao, Liming]

Good suggestion. I will update commit log. 

>-Original Message-
>From: Zeng, Star
>Sent: Thursday, April 06, 2017 4:22 PM
>To: Gao, Liming ; edk2-devel@lists.01.org
>Cc: Zeng, Star 
>Subject: RE: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove
>GCC -fno-builtin option
>
>How about to indicate the SHA-1:
>90defe7198a42b3157ae5d9b93714f891cf06e57 in the commit log like below?
>
>GCC -fno-builtin option is added into tools_def.template at
>90defe7198a42b3157ae5d9b93714f891cf06e57.
>So, there is no need to set it in module INF file.
>
>Thanks,
>Star
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Liming Gao
>Sent: Thursday, April 6, 2017 4:15 PM
>To: edk2-devel@lists.01.org
>Cc: Zeng, Star 
>Subject: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC -
>fno-builtin option
>
>GCC -fno-builtin option is added into tools_def.template. So, there is no need
>to set it in module INF file.
>
>Cc: Star Zeng 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Liming Gao 
>---
> MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>| 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git
>a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.in
>f
>b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.in
>f
>index cfe42a6..d4d9a83 100644
>---
>a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.in
>f
>+++
>b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.i
>+++ nf
>@@ -81,7 +81,6 @@
>   MSFT:DEBUG_*_IPF_CC_FLAGS== /nologo /c /WX /GS- /W4 /EHs-c- /GR-
>/Gy /Os /FIAutoGen.h /QIPF_fr32 /Zi /X
>   MSFT:RELEASE_*_IPF_CC_FLAGS  == /nologo /c /WX /GS- /W4 /EHs-c- /GR-
>/Gy /Os /FIAutoGen.h /QIPF_fr32 /X
>   INTEL:*_*_*_CC_FLAGS =  /Oi-
>-  GCC:*_*_*_CC_FLAGS   =  -fno-builtin
>
>   # Oniguruma: potentially uninitialized local variable used
>   MSFT:*_*_*_CC_FLAGS = /wd4701
>--
>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] CryptoPkg IntrinsicLib: Remove GCC -fno-builtin option

[Long, Qin]

Reviewed-by: Long Qin 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Liming Gao
> Sent: Thursday, April 06, 2017 4:16 PM
> To: edk2-devel@lists.01.org
> Cc: Long, Qin
> Subject: [edk2] [Patch] CryptoPkg IntrinsicLib: Remove GCC -fno-builtin
> option
> 
> GCC -fno-builtin option is added into tools_def.template. So, there is no
> need to set it in module INF file.
> 
> Cc: Qin Long 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> b/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> index cd09f53..91e5eb7 100644
> --- a/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> +++ b/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  Intrinsic Routines Wrapper Library Instance.
>  #
> -#  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2010 - 2017, Intel Corporation. All rights
> +reserved.
>  #  This program and the accompanying materials  #  are licensed and made
> available under the terms and conditions of the BSD License  #  which
> accompanies this distribution.  The full text of the license may be found at
> @@ -81,4 +81,3 @@
> MSFT:DEBUG_*_IPF_CC_FLAGS  == /nologo /c /WX /GS- /X /W4
> /EHs-c- /GR- /Gy /Os /FIAutoGen.h /QIPF_fr32 /Zi
> MSFT:RELEASE_*_IPF_CC_FLAGS== /nologo /c /WX /GS- /X /W4
> /EHs-c- /GR- /Gy /Os /FIAutoGen.h /QIPF_fr32
>INTEL:*_*_*_CC_FLAGS=  /Oi-
> -GCC:*_*_*_CC_FLAGS=  -fno-builtin
> \ No newline at end of file
> --
> 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] MdeModulePkg RegularExpressionDxe: Remove GCC -fno-builtin option

[Zeng, Star]

How about to indicate the SHA-1: 90defe7198a42b3157ae5d9b93714f891cf06e57 in 
the commit log like below?

GCC -fno-builtin option is added into tools_def.template at
90defe7198a42b3157ae5d9b93714f891cf06e57.
So, there is no need to set it in module INF file.

Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Thursday, April 6, 2017 4:15 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC 
-fno-builtin option

GCC -fno-builtin option is added into tools_def.template. So, there is no need 
to set it in module INF file.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf 
b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
index cfe42a6..d4d9a83 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.i
+++ nf
@@ -81,7 +81,6 @@
   MSFT:DEBUG_*_IPF_CC_FLAGS== /nologo /c /WX /GS- /W4 /EHs-c- /GR- /Gy /Os 
/FIAutoGen.h /QIPF_fr32 /Zi /X 
   MSFT:RELEASE_*_IPF_CC_FLAGS  == /nologo /c /WX /GS- /W4 /EHs-c- /GR- /Gy /Os 
/FIAutoGen.h /QIPF_fr32 /X 
   INTEL:*_*_*_CC_FLAGS =  /Oi-
-  GCC:*_*_*_CC_FLAGS   =  -fno-builtin
 
   # Oniguruma: potentially uninitialized local variable used
   MSFT:*_*_*_CC_FLAGS = /wd4701
--
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] CryptoPkg: Move openssl and CRT headers to private include section

[Gao, Liming]

Got it. Thanks for your clarification. 

>-Original Message-
>From: Long, Qin
>Sent: Thursday, April 06, 2017 2:25 PM
>To: Gao, Liming ; Ye, Ting 
>Cc: edk2-devel@lists.01.org
>Subject: RE: [Patch] CryptoPkg: Move openssl and CRT headers to private
>include section
>
>Yes, it's feasible.
>I still prefer to use "Library/Include" path setting for this, since only
>CryptoPkg/Library/*
>will refer to these internal header files.
>It may be cleaner to keep the current directory in root of CryptoPkg.
>
>
>Best Regards & Thanks,
>LONG, Qin
>
>> -Original Message-
>> From: Gao, Liming
>> Sent: Thursday, April 06, 2017 2:09 PM
>> To: Long, Qin; Ye, Ting
>> Cc: edk2-devel@lists.01.org
>> Subject: RE: [Patch] CryptoPkg: Move openssl and CRT headers to private
>> include section
>>
>> Qin:
>>   How about creating new Private directory in CryptoPkg, then move those
>> internal header files into it?
>>
>> Thanks
>> Liming
>> >-Original Message-
>> >From: Long, Qin
>> >Sent: Thursday, April 06, 2017 1:56 PM
>> >To: Gao, Liming ; Ye, Ting 
>> >Cc: edk2-devel@lists.01.org; Long, Qin 
>> >Subject: [Patch] CryptoPkg: Move openssl and CRT headers to private
>> >include section
>> >
>> >Moving the header files for openssl and CRT wrappers to the private
>> >include section, since these files should be referenced by CryptoPkg
>> >internally. This update was supported by new [Includes.Common.Private]
>> >setting in Package DEC file.
>> >The external consumer modules should only use the interfaces defined in
>> >BaseCryptLib.h to access crypto functions. This change will be helpful
>> >to immediately detect any illegal direct reference to internal openssl
>> >headers.
>> >The Perl script "process_files.pl" was also updated to reflect the new
>> >private include path.
>> >
>> >Cc: Gao Liming 
>> >Cc: Ting Ye 
>> >Contributed-under: TianoCore Contribution Agreement 1.0
>> >Signed-off-by: Qin Long 
>> >Signed-off-by: Long Qin 
>> >---
>> > CryptoPkg/CryptoPkg.dec   | 3 +++
>> > CryptoPkg/{ => Library}/Include/CrtLibSupport.h   | 0
>> > CryptoPkg/{ => Library}/Include/assert.h  | 0
>> > CryptoPkg/{ => Library}/Include/ctype.h   | 0
>> > CryptoPkg/{ => Library}/Include/errno.h   | 0
>> > CryptoPkg/{ => Library}/Include/internal/dso_conf.h   | 0
>> > CryptoPkg/{ => Library}/Include/limits.h  | 0
>> > CryptoPkg/{ => Library}/Include/memory.h  | 0
>> > CryptoPkg/{ => Library}/Include/openssl/opensslconf.h | 0
>> > CryptoPkg/{ => Library}/Include/stdarg.h  | 0
>> > CryptoPkg/{ => Library}/Include/stddef.h  | 0
>> > CryptoPkg/{ => Library}/Include/stdio.h   | 0
>> > CryptoPkg/{ => Library}/Include/stdlib.h  | 0
>> > CryptoPkg/{ => Library}/Include/string.h  | 0
>> > CryptoPkg/{ => Library}/Include/strings.h | 0
>> > CryptoPkg/{ => Library}/Include/sys/time.h| 0
>> > CryptoPkg/{ => Library}/Include/sys/types.h   | 0
>> > CryptoPkg/{ => Library}/Include/syslog.h  | 0
>> > CryptoPkg/{ => Library}/Include/time.h| 0
>> > CryptoPkg/{ => Library}/Include/unistd.h  | 0
>> > CryptoPkg/Library/OpensslLib/process_files.pl | 2 +-
>> > 21 files changed, 4 insertions(+), 1 deletion(-)  rename CryptoPkg/{
>> >=> Library}/Include/CrtLibSupport.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/assert.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/ctype.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/errno.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/internal/dso_conf.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/limits.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/memory.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/openssl/opensslconf.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/stdarg.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/stddef.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/stdio.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/stdlib.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/string.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/strings.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/sys/time.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/sys/types.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/syslog.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/time.h (100%)  rename CryptoPkg/{ =>
>> >Library}/Include/unistd.h (100%)
>> >
>> >diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec index
>> >fdccbf06f7..b2fae6142a 100644
>> >--- a/CryptoPkg/CryptoPkg.dec
>> >+++ b/CryptoPkg/CryptoPkg.dec
>> >@@ -24,6 +24,9 @@
>> >
>> > [Includes]
>> >   Include
>> >+
>> >+[Includes.Common.Private]
>> >+  

[edk2] [Patch] CryptoPkg IntrinsicLib: Remove GCC -fno-builtin option

[Liming Gao]

GCC -fno-builtin option is added into tools_def.template. So, there is
no need to set it in module INF file.

Cc: Qin Long 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf 
b/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
index cd09f53..91e5eb7 100644
--- a/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
+++ b/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Intrinsic Routines Wrapper Library Instance.
 #
-#  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
@@ -81,4 +81,3 @@
MSFT:DEBUG_*_IPF_CC_FLAGS  == /nologo /c /WX /GS- /X /W4 
/EHs-c- /GR- /Gy /Os /FIAutoGen.h /QIPF_fr32 /Zi
MSFT:RELEASE_*_IPF_CC_FLAGS== /nologo /c /WX /GS- /X /W4 
/EHs-c- /GR- /Gy /Os /FIAutoGen.h /QIPF_fr32
   INTEL:*_*_*_CC_FLAGS=  /Oi-
-GCC:*_*_*_CC_FLAGS=  -fno-builtin
\ No newline at end of file
-- 
2.8.0.windows.1

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

[edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC -fno-builtin option

[Liming Gao]

GCC -fno-builtin option is added into tools_def.template. So, there is
no need to set it in module INF file.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf 
b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
index cfe42a6..d4d9a83 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
@@ -81,7 +81,6 @@
   MSFT:DEBUG_*_IPF_CC_FLAGS== /nologo /c /WX /GS- /W4 /EHs-c- /GR- /Gy /Os 
/FIAutoGen.h /QIPF_fr32 /Zi /X 
   MSFT:RELEASE_*_IPF_CC_FLAGS  == /nologo /c /WX /GS- /W4 /EHs-c- /GR- /Gy /Os 
/FIAutoGen.h /QIPF_fr32 /X 
   INTEL:*_*_*_CC_FLAGS =  /Oi-
-  GCC:*_*_*_CC_FLAGS   =  -fno-builtin
 
   # Oniguruma: potentially uninitialized local variable used
   MSFT:*_*_*_CC_FLAGS = /wd4701
-- 
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] BaseTools: Update tools_def.template to add -fno-builtin in GCC tool chain

[Gao, Liming]

Thanks! I will update the commit message and push it. 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Thursday, April 06, 2017 3:39 PM
>To: Gao, Liming ; edk2-devel@lists.01.org
>Cc: Ard Biesheuvel 
>Subject: Re: [edk2] [Patch] BaseTools: Update tools_def.template to add -
>fno-builtin in GCC tool chain
>
>On 04/06/17 02:57, Laszlo Ersek wrote:
>> On 04/06/17 02:45, Liming Gao wrote:
>>> Now, -fno-builtin option is added for the specific GCC tool chain.
>>> It is a generic option. It can be moved to common GCC option to keep
>>> the consistent compiler option.
>>>
>>> Cc: Ard Biesheuvel 
>>> Cc: Yonghong Zhu 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Liming Gao 
>>> Signed-off-by: Laszlo Ersek 
>>
>> Please don't add "Signed-off-by" tags for other people. That tag should
>> only come from people with actual authorship on the patch.
>>
>> Instead, in this case,
>>
>> Suggested-by: Laszlo Ersek 
>>
>> would be appropriate (and welcome too :) ).
>>
>> I'll check this patch in more detail later.
>
>With the above commit message update:
>
>Reviewed-by: Laszlo Ersek 
>
>I also tested this, with OVMF (Ia32, Ia32X64, X64), using gcc-4.8 (GCC48
>toolchain), and with ArmVirtQemu (AARCH64), using gcc-6.1.1 (GCC5
>toolchain).
>
>Tested-by: Laszlo Ersek 
>
>Thanks!
>Laszlo
>
>>
>>> ---
>>>  BaseTools/Conf/tools_def.template | 14 +++---
>>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/BaseTools/Conf/tools_def.template
>b/BaseTools/Conf/tools_def.template
>>> index 2c5cd58089..14ecfedab1 100755
>>> --- a/BaseTools/Conf/tools_def.template
>>> +++ b/BaseTools/Conf/tools_def.template
>>> @@ -4335,13 +4335,13 @@ DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = --
>add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_N
>>>  RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
>>>  NOOPT_*_*_OBJCOPY_ADDDEBUGFLAG = --add-gnu-
>debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
>>>
>>> -DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-strict-
>aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h -fno-common
>>> +DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-builtin 
>>> -fno-
>strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h -fno-
>common
>>>  DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 -
>malign-double -freorder-blocks -freorder-blocks-and-partition -O2 -mno-
>stack-arg-probe
>>>  DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-
>zone -Wno-address -mno-stack-arg-probe
>>>  DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -minline-
>int-divide-min-latency
>>> -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-
>endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -
>fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -mthumb -
>mfloat-abi=soft
>>> +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-
>endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -
>fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
>>>  DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access
>>> -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -
>mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-
>sections -fdata-sections -fno-builtin -Wno-address -fno-asynchronous-
>unwind-tables -fno-pic
>>> +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -
>mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-
>sections -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -
>fno-pic
>>>  DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
>>>  DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
>>>  DEFINE GCC_DLINK2_FLAGS_COMMON = -Wl,--
>script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
>>> @@ -4368,7 +4368,7 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O
>elf64-ia64-little   -B ia64
>>>  DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B 
>>> arm
>--rename-section .data=.hii
>>>  DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B
>aarch64 --rename-section .data=.hii
>>>
>>> -DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar 
>>> -fno-strict-aliasing
>-Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include
>AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
>>> +DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-builtin -fno-
>strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-
>sections -include AutoGen.h -fno-common -
>DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
>>>  DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 -
>march=i586 -malign-double 

Re: [edk2] [Patch] BaseTools: Update tools_def.template to add -fno-builtin in GCC tool chain

[Laszlo Ersek]

On 04/06/17 02:57, Laszlo Ersek wrote:
> On 04/06/17 02:45, Liming Gao wrote:
>> Now, -fno-builtin option is added for the specific GCC tool chain.
>> It is a generic option. It can be moved to common GCC option to keep
>> the consistent compiler option.
>>
>> Cc: Ard Biesheuvel 
>> Cc: Yonghong Zhu 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Liming Gao 
>> Signed-off-by: Laszlo Ersek 
> 
> Please don't add "Signed-off-by" tags for other people. That tag should
> only come from people with actual authorship on the patch.
> 
> Instead, in this case,
> 
> Suggested-by: Laszlo Ersek 
> 
> would be appropriate (and welcome too :) ).
> 
> I'll check this patch in more detail later.

With the above commit message update:

Reviewed-by: Laszlo Ersek 

I also tested this, with OVMF (Ia32, Ia32X64, X64), using gcc-4.8 (GCC48
toolchain), and with ArmVirtQemu (AARCH64), using gcc-6.1.1 (GCC5
toolchain).

Tested-by: Laszlo Ersek 

Thanks!
Laszlo

> 
>> ---
>>  BaseTools/Conf/tools_def.template | 14 +++---
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/BaseTools/Conf/tools_def.template 
>> b/BaseTools/Conf/tools_def.template
>> index 2c5cd58089..14ecfedab1 100755
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -4335,13 +4335,13 @@ DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
>> --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_N
>>  RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
>>  NOOPT_*_*_OBJCOPY_ADDDEBUGFLAG = 
>> --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
>>  
>> -DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar 
>> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h 
>> -fno-common
>> +DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-builtin 
>> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h 
>> -fno-common
>>  DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 
>> -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
>> -mno-stack-arg-probe
>>  DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
>> -Wno-address -mno-stack-arg-probe
>>  DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
>> -minline-int-divide-min-latency
>> -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
>> -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
>> -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -mthumb 
>> -mfloat-abi=soft
>> +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
>> -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
>> -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
>>  DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access
>> -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
>> -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
>> -fdata-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables 
>> -fno-pic
>> +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
>> -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
>> -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic
>>  DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
>>  DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
>>  DEFINE GCC_DLINK2_FLAGS_COMMON = 
>> -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
>> @@ -4368,7 +4368,7 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O 
>> elf64-ia64-little   -B ia64
>>  DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B 
>> arm --rename-section .data=.hii
>>  DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B 
>> aarch64 --rename-section .data=.hii
>>  
>> -DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar 
>> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections 
>> -fdata-sections -include AutoGen.h -fno-common 
>> -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
>> +DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-builtin 
>> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections 
>> -fdata-sections -include AutoGen.h -fno-common 
>> -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
>>  DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
>> -march=i586 -malign-double -fno-stack-protector -D EFI32 
>> -fno-asynchronous-unwind-tables
>>  DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
>> -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" 
>> -maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie 
>> -fno-asynchronous-unwind-tables
>>  DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z 
>> common-page-size=0x20
>> @@ -4471,8 

[edk2] 答复: [DxeNetLib] Why do we restrict each field to have the same leading zero format?

[Guoheyi]

Many thanks. I missed to check the latest cod...

Regards,

Gary (Heyi Guo)

-邮件原件-
发件人: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
发送时间: 2017年4月6日 13:30
收件人: Guoheyi; edk2-devel@lists.01.org
抄送: Tian, Feng; Fu, Siyuan; Zeng, Star
主题: RE: [edk2] [DxeNetLib] Why do we restrict each field to have the same 
leading zero format?

Hi Gary,

The issue has been gone since the version of 
9f5ca5efbd0bb00c9d3577b95e6322e85cb0b118. Please check that.

Thanks,
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Guoheyi
> Sent: Wednesday, April 5, 2017 6:56 PM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng ; Wu, Jiaxin 
> ; Fu, Siyuan ; Zeng, Star 
> 
> Subject: [edk2] [DxeNetLib] Why do we restrict each field to have the 
> same leading zero format?
> 
> Hi folks,
> 
> We are using NetLibAsciiStrToIp6 function in DxeNetLib.c of 
> MdeModulePkg to convert string to IPv6 address. We found this function 
> will return invalid parameter with below input:
> 2001:3456:789a::f012:2:2003:2005
> 
> We trace the code and believe it is handled by the branch in line 2955:
> 
>   if ((Cnt != 0) && (Cnt < 4) && LeadZero) {
> return EFI_INVALID_PARAMETER;
>   }
> 
> I think the reason is that we have field 3 of "" which has leading 
> zero and causes LeadZero flag to be true, and it requires all the 
> following fields to have the same leading zero format, while field 5 of "2" 
> is not.
> 
> I checked RFC 4291 and only found below text; I didn't find any 
> restriction that requires each field to have the same leading zero format.
> 
>1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
>   four hexadecimal digits of the eight 16-bit pieces of the address.
>   Examples:
> 
>  ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
> 
>  2001:DB8:0:0:8:800:200C:417A
> 
>   Note that it is not necessary to write the leading zeros in an
>   individual field, but there must be at least one numeral in every
>   field (except for the case described in 2.).
> 
> Could you help to confirm whether it is a bug or there is some special 
> reason for this?
> 
> Thanks and regards,
> 
> Gary (Heyi Guo)
> ___
> 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] SecurityPkg: SecureBootConfigDxe: Update CloseEnrolledFile comment

[Bi, Dandan]

Reviewed-by: Dandan Bi 

-Original Message-
From: Zhang, Chao B 
Sent: Thursday, April 6, 2017 3:21 PM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan ; Zhang, Chao B 
Subject: [PATCH] SecurityPkg: SecureBootConfigDxe: Update CloseEnrolledFile 
comment

Update function CloseEnrolledFile comment introduced in 
4de754e15fec9c94ce7677904efd0022c211721b

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
---
 .../SecureBootConfigDxe/SecureBootConfigImpl.c| 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
index b124c21..2eaf246 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
+++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCo
+++ nfigImpl.c
@@ -98,15 +98,11 @@ SECUREBOOT_CONFIG_PRIVATE_DATA  *gSecureBootPrivateData = 
NULL;
 
 /**
   This code cleans up enrolled file by closing file & free related resources 
attached to
-  enrolled file
+  enrolled file.
 
-  @param[in] FileSuffixThe suffix of the input certificate file
-
-  @retvalTRUE   It's a DER-encoded certificate.
-  @retvalFALSE  It's NOT a DER-encoded certificate.
+  @param[in] FileContextFileContext cached in SecureBootConfig 
driver
 
 **/
-
 VOID
 CloseEnrolledFile(
   IN SECUREBOOT_FILE_CONTEXT *FileContext
--
1.9.5.msysgit.1

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

[edk2] [PATCH] SecurityPkg: SecureBootConfigDxe: Update CloseEnrolledFile comment

[Zhang, Chao B]

Update function CloseEnrolledFile comment introduced in
4de754e15fec9c94ce7677904efd0022c211721b

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
---
 .../SecureBootConfigDxe/SecureBootConfigImpl.c| 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
index b124c21..2eaf246 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
+++ 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
@@ -98,15 +98,11 @@ SECUREBOOT_CONFIG_PRIVATE_DATA  *gSecureBootPrivateData = 
NULL;
 
 /**
   This code cleans up enrolled file by closing file & free related resources 
attached to
-  enrolled file
+  enrolled file.
 
-  @param[in] FileSuffixThe suffix of the input certificate file
-
-  @retvalTRUE   It's a DER-encoded certificate.
-  @retvalFALSE  It's NOT a DER-encoded certificate.
+  @param[in] FileContextFileContext cached in SecureBootConfig 
driver
 
 **/
-
 VOID
 CloseEnrolledFile(
   IN SECUREBOOT_FILE_CONTEXT *FileContext
-- 
1.9.5.msysgit.1

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

Re: [edk2] [Patch] CryptoPkg: Move openssl and CRT headers to private include section

[Long, Qin]

Yes, it's feasible.
I still prefer to use "Library/Include" path setting for this, since only 
CryptoPkg/Library/*
will refer to these internal header files.
It may be cleaner to keep the current directory in root of CryptoPkg. 


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, April 06, 2017 2:09 PM
> To: Long, Qin; Ye, Ting
> Cc: edk2-devel@lists.01.org
> Subject: RE: [Patch] CryptoPkg: Move openssl and CRT headers to private
> include section
> 
> Qin:
>   How about creating new Private directory in CryptoPkg, then move those
> internal header files into it?
> 
> Thanks
> Liming
> >-Original Message-
> >From: Long, Qin
> >Sent: Thursday, April 06, 2017 1:56 PM
> >To: Gao, Liming ; Ye, Ting 
> >Cc: edk2-devel@lists.01.org; Long, Qin 
> >Subject: [Patch] CryptoPkg: Move openssl and CRT headers to private
> >include section
> >
> >Moving the header files for openssl and CRT wrappers to the private
> >include section, since these files should be referenced by CryptoPkg
> >internally. This update was supported by new [Includes.Common.Private]
> >setting in Package DEC file.
> >The external consumer modules should only use the interfaces defined in
> >BaseCryptLib.h to access crypto functions. This change will be helpful
> >to immediately detect any illegal direct reference to internal openssl
> >headers.
> >The Perl script "process_files.pl" was also updated to reflect the new
> >private include path.
> >
> >Cc: Gao Liming 
> >Cc: Ting Ye 
> >Contributed-under: TianoCore Contribution Agreement 1.0
> >Signed-off-by: Qin Long 
> >Signed-off-by: Long Qin 
> >---
> > CryptoPkg/CryptoPkg.dec   | 3 +++
> > CryptoPkg/{ => Library}/Include/CrtLibSupport.h   | 0
> > CryptoPkg/{ => Library}/Include/assert.h  | 0
> > CryptoPkg/{ => Library}/Include/ctype.h   | 0
> > CryptoPkg/{ => Library}/Include/errno.h   | 0
> > CryptoPkg/{ => Library}/Include/internal/dso_conf.h   | 0
> > CryptoPkg/{ => Library}/Include/limits.h  | 0
> > CryptoPkg/{ => Library}/Include/memory.h  | 0
> > CryptoPkg/{ => Library}/Include/openssl/opensslconf.h | 0
> > CryptoPkg/{ => Library}/Include/stdarg.h  | 0
> > CryptoPkg/{ => Library}/Include/stddef.h  | 0
> > CryptoPkg/{ => Library}/Include/stdio.h   | 0
> > CryptoPkg/{ => Library}/Include/stdlib.h  | 0
> > CryptoPkg/{ => Library}/Include/string.h  | 0
> > CryptoPkg/{ => Library}/Include/strings.h | 0
> > CryptoPkg/{ => Library}/Include/sys/time.h| 0
> > CryptoPkg/{ => Library}/Include/sys/types.h   | 0
> > CryptoPkg/{ => Library}/Include/syslog.h  | 0
> > CryptoPkg/{ => Library}/Include/time.h| 0
> > CryptoPkg/{ => Library}/Include/unistd.h  | 0
> > CryptoPkg/Library/OpensslLib/process_files.pl | 2 +-
> > 21 files changed, 4 insertions(+), 1 deletion(-)  rename CryptoPkg/{
> >=> Library}/Include/CrtLibSupport.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/assert.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/ctype.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/errno.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/internal/dso_conf.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/limits.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/memory.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/openssl/opensslconf.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/stdarg.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/stddef.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/stdio.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/stdlib.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/string.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/strings.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/sys/time.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/sys/types.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/syslog.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/time.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/unistd.h (100%)
> >
> >diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec index
> >fdccbf06f7..b2fae6142a 100644
> >--- a/CryptoPkg/CryptoPkg.dec
> >+++ b/CryptoPkg/CryptoPkg.dec
> >@@ -24,6 +24,9 @@
> >
> > [Includes]
> >   Include
> >+
> >+[Includes.Common.Private]
> >+  Library/Include
> >   Library/OpensslLib/openssl/include
> >   Library/OpensslLib/openssl/crypto/include
> >
> >diff --git a/CryptoPkg/Include/CrtLibSupport.h
> >b/CryptoPkg/Library/Include/CrtLibSupport.h
> >similarity index 100%
> >rename from CryptoPkg/Include/CrtLibSupport.h rename to
> >CryptoPkg/Library/Include/CrtLibSupport.h
> >diff --git a/CryptoPkg/Include/assert.h
> >b/CryptoPkg/Library/Include/assert.h
> 

Re: [edk2] [Patch] CryptoPkg: Move openssl and CRT headers to private include section

[Gao, Liming]

Qin:
  How about creating new Private directory in CryptoPkg, then move those 
internal header files into it? 

Thanks
Liming
>-Original Message-
>From: Long, Qin
>Sent: Thursday, April 06, 2017 1:56 PM
>To: Gao, Liming ; Ye, Ting 
>Cc: edk2-devel@lists.01.org; Long, Qin 
>Subject: [Patch] CryptoPkg: Move openssl and CRT headers to private include
>section
>
>Moving the header files for openssl and CRT wrappers to the private
>include section, since these files should be referenced by CryptoPkg
>internally. This update was supported by new [Includes.Common.Private]
>setting in Package DEC file.
>The external consumer modules should only use the interfaces defined
>in BaseCryptLib.h to access crypto functions. This change will be
>helpful to immediately detect any illegal direct reference to internal
>openssl headers.
>The Perl script "process_files.pl" was also updated to reflect the new
>private include path.
>
>Cc: Gao Liming 
>Cc: Ting Ye 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Qin Long 
>Signed-off-by: Long Qin 
>---
> CryptoPkg/CryptoPkg.dec   | 3 +++
> CryptoPkg/{ => Library}/Include/CrtLibSupport.h   | 0
> CryptoPkg/{ => Library}/Include/assert.h  | 0
> CryptoPkg/{ => Library}/Include/ctype.h   | 0
> CryptoPkg/{ => Library}/Include/errno.h   | 0
> CryptoPkg/{ => Library}/Include/internal/dso_conf.h   | 0
> CryptoPkg/{ => Library}/Include/limits.h  | 0
> CryptoPkg/{ => Library}/Include/memory.h  | 0
> CryptoPkg/{ => Library}/Include/openssl/opensslconf.h | 0
> CryptoPkg/{ => Library}/Include/stdarg.h  | 0
> CryptoPkg/{ => Library}/Include/stddef.h  | 0
> CryptoPkg/{ => Library}/Include/stdio.h   | 0
> CryptoPkg/{ => Library}/Include/stdlib.h  | 0
> CryptoPkg/{ => Library}/Include/string.h  | 0
> CryptoPkg/{ => Library}/Include/strings.h | 0
> CryptoPkg/{ => Library}/Include/sys/time.h| 0
> CryptoPkg/{ => Library}/Include/sys/types.h   | 0
> CryptoPkg/{ => Library}/Include/syslog.h  | 0
> CryptoPkg/{ => Library}/Include/time.h| 0
> CryptoPkg/{ => Library}/Include/unistd.h  | 0
> CryptoPkg/Library/OpensslLib/process_files.pl | 2 +-
> 21 files changed, 4 insertions(+), 1 deletion(-)
> rename CryptoPkg/{ => Library}/Include/CrtLibSupport.h (100%)
> rename CryptoPkg/{ => Library}/Include/assert.h (100%)
> rename CryptoPkg/{ => Library}/Include/ctype.h (100%)
> rename CryptoPkg/{ => Library}/Include/errno.h (100%)
> rename CryptoPkg/{ => Library}/Include/internal/dso_conf.h (100%)
> rename CryptoPkg/{ => Library}/Include/limits.h (100%)
> rename CryptoPkg/{ => Library}/Include/memory.h (100%)
> rename CryptoPkg/{ => Library}/Include/openssl/opensslconf.h (100%)
> rename CryptoPkg/{ => Library}/Include/stdarg.h (100%)
> rename CryptoPkg/{ => Library}/Include/stddef.h (100%)
> rename CryptoPkg/{ => Library}/Include/stdio.h (100%)
> rename CryptoPkg/{ => Library}/Include/stdlib.h (100%)
> rename CryptoPkg/{ => Library}/Include/string.h (100%)
> rename CryptoPkg/{ => Library}/Include/strings.h (100%)
> rename CryptoPkg/{ => Library}/Include/sys/time.h (100%)
> rename CryptoPkg/{ => Library}/Include/sys/types.h (100%)
> rename CryptoPkg/{ => Library}/Include/syslog.h (100%)
> rename CryptoPkg/{ => Library}/Include/time.h (100%)
> rename CryptoPkg/{ => Library}/Include/unistd.h (100%)
>
>diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec
>index fdccbf06f7..b2fae6142a 100644
>--- a/CryptoPkg/CryptoPkg.dec
>+++ b/CryptoPkg/CryptoPkg.dec
>@@ -24,6 +24,9 @@
>
> [Includes]
>   Include
>+
>+[Includes.Common.Private]
>+  Library/Include
>   Library/OpensslLib/openssl/include
>   Library/OpensslLib/openssl/crypto/include
>
>diff --git a/CryptoPkg/Include/CrtLibSupport.h
>b/CryptoPkg/Library/Include/CrtLibSupport.h
>similarity index 100%
>rename from CryptoPkg/Include/CrtLibSupport.h
>rename to CryptoPkg/Library/Include/CrtLibSupport.h
>diff --git a/CryptoPkg/Include/assert.h b/CryptoPkg/Library/Include/assert.h
>similarity index 100%
>rename from CryptoPkg/Include/assert.h
>rename to CryptoPkg/Library/Include/assert.h
>diff --git a/CryptoPkg/Include/ctype.h b/CryptoPkg/Library/Include/ctype.h
>similarity index 100%
>rename from CryptoPkg/Include/ctype.h
>rename to CryptoPkg/Library/Include/ctype.h
>diff --git a/CryptoPkg/Include/errno.h b/CryptoPkg/Library/Include/errno.h
>similarity index 100%
>rename from CryptoPkg/Include/errno.h
>rename to CryptoPkg/Library/Include/errno.h
>diff --git a/CryptoPkg/Include/internal/dso_conf.h
>b/CryptoPkg/Library/Include/internal/dso_conf.h
>similarity index 100%
>rename from CryptoPkg/Include/internal/dso_conf.h
>rename to