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

[Long, Qin]

I agree those changes really make sense for better alignment, under both 
1.0.2xx and 1.1 HEAD. The final out-of-box support will be wonderful. 
The updates (http://git.infradead.org/users/dwmw2/edk2.git) looks good to me. 
And I will follow more validations, and start the next integration 
step-by-step. 

Yeah, also will do more follow-ups about the remaining opens...


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> David Woodhouse
> Sent: Friday, February 19, 2016 7:01 AM
> To: Long, Qin; Laszlo Ersek
> Cc: Ye, Ting; edk2-de...@ml01.01.org
> Subject: Re: [edk2] [Patch] CryptoPkg/OpensslLib: Upgrade OpenSSL version
> to 1.0.2f
> 
> On Thu, 2016-02-18 at 17:36 +, Long, Qin wrote:
> > I think I also need to apologize, that it's my decision to pending
> > some part of Dave's patch series posted in last year (with simple
> > sync-up with Dave), which includes some changes for include path,
> > build process, etc.
> 
> I agreed with that then, and in retrospect it looks like the right decision. 
> It
> turns out that from 1.0.2e onwards, the symlinks are no longer present in the
> include/openssl/ directory of the release tarballs. So if you had actually
> merged my patch to use the OpenSSL include directory, back in the 1.0.2d
> days, it would have broken with the update to 1.0.2e.
> 
> I've revamped that patch so that we retain Install.sh even on POSIX
> platforms. Basically we just copy the files to where OpenSSL normally has
> them, instead of copying them to our *own* CryptoPkg/Include/ directory.
> 
> I've also rebuilt my OpenSSL_1_0_2-stable branch at
> http://git.infradead.org/users/dwmw2/openssl.git with freshly cherry-
> picked patches from HEAD... now that fairly much every change we had
> *is* committed to OpenSSL HEAD.
> 
> My main motivation for doing this right now is because we need to ensure
> that OpenSSL 1.1, when it comes out, *does* do everything we need out of
> the box.
> 
> I won't send another patchbomb to the list right now, but I've updated the
> tree at http://git.infradead.org/users/dwmw2/edk2.git
> 
> Again, up to and including the 'Automatically configure OpenSSL and
> generate file list' patch are applicable even while we stick with 1.0.2. The 
> final
> two commits need more work (and I'm hoping you follow through on the
> discussion about the HMAC APIs), but are mostly useful for ensuring that
> OpenSSL HEAD *stays* working as it approaches release.
> 
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation

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

Re: [edk2] [Patch v2] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Fan, Jeff]

Reviewed-by: Jeff Fan 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Kinney
Sent: Friday, February 19, 2016 9:54 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Laszlo Ersek; Fan, Jeff
Subject: [edk2] [Patch v2] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to 
CheckFeatureSupported()

The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE in the MP 
Services Protocol service StartAllAPs().  Any function used as an 
EFI_AP_PROCEDURE must use EFIAPI calling convention.

Cc: Laszlo Ersek 
Cc: Jeff Fan 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 9 +  
UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 5 +++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index ec4ec9b..9c4f387 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1,7 +1,7 @@
 /** @file
 Enable SMM profile.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -930,8 +930,9 @@ 
InitSmmProfileInternal (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
-  VOID
+  IN OUT VOID   *Buffer
   )
 {
   UINT32 RegEax;
@@ -1001,7 +1002,7 @@ CheckProcessorFeature (
   //
   // Check if XD and BTS are supported on all processors.
   //
-  CheckFeatureSupported ();
+  CheckFeatureSupported (NULL);
 
   //
   //Check on other processors if BSP supports this @@ -1009,7 +1010,7 @@ 
CheckProcessorFeature (
   if (mXdSupported || mBtsSupported) {
 MpServices->StartupAllAPs (
   MpServices,
-  (EFI_AP_PROCEDURE) CheckFeatureSupported,
+  CheckFeatureSupported,
   TRUE,
   NULL,
   0,
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
index 4548467..d65048e 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
@@ -1,7 +1,7 @@
 /** @file
 SMM profile header file.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -97,8 +97,9 @@ 
PageFaultIdtHandlerSmmProfile (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
-  VOID
+  IN OUT VOID   *Buffer
   );
 
 /**
--
2.6.3.windows.1

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

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Enable/Restore XD in SMM

[Fan, Jeff]

Reviewed-by: Jeff Fan 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Kinney
Sent: Friday, February 19, 2016 10:36 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Fan, Jeff
Subject: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Enable/Restore XD in SMM

If XD is supported, then SMM enables it.  The non-SMM execution environment can 
choose to enable or disable XD, so the state of XD must be detected in each SMI 
and be enabled/restored.

Cc: Jeff Fan 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 18 +++---  
UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h |  3 ++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index 79b7c90..185cb3d 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -1,7 +1,7 @@
 /** @file
 SMM MP service implementation
 
-Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -1019,6 +1019,7 
@@ SmiRendezvous (
   BOOLEAN   BspInProgress;
   UINTN Index;
   UINTN Cr2;
+  BOOLEAN   XdDisableFlag;
 
   //
   // Save Cr2 because Page Fault exception in SMM may override its value @@ 
-1078,9 +1079,14 @@ SmiRendezvous (
 }
 
 //
-// Try to enable NX
+// Try to enable XD
 //
+XdDisableFlag = FALSE;
 if (mXdSupported) {
+  if ((AsmReadMsr64 (MSR_IA32_MISC_ENABLE) & B_XD_DISABLE_BIT) != 0) {
+XdDisableFlag = TRUE;
+AsmMsrAnd64 (MSR_IA32_MISC_ENABLE, ~B_XD_DISABLE_BIT);
+  }
   ActivateXd ();
 }
 
@@ -1152,7 +1158,6 @@ SmiRendezvous (
 // BSP Handler is always called with a ValidSmi == TRUE
 //
 BSPHandler (CpuIndex, mSmmMpSyncData->EffectiveSyncMode);
-
   } else {
 APHandler (CpuIndex, ValidSmi, mSmmMpSyncData->EffectiveSyncMode);
   }
@@ -1165,6 +1170,13 @@ SmiRendezvous (
 //
 while (mSmmMpSyncData->AllCpusInSync) {
   CpuPause ();
+ }
+
+//
+// Restore XD
+//
+if (XdDisableFlag) {
+  AsmMsrOr64 (MSR_IA32_MISC_ENABLE, B_XD_DISABLE_BIT);
 }
   }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
index 4548467..f91c104 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
@@ -1,7 +1,7 @@
 /** @file
 SMM profile header file.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -21,6 +21,7 @@ 
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 /// MSR Register Index
 ///
 #define MSR_IA32_MISC_ENABLE  0x1A0
+#define   B_XD_DISABLE_BITBIT34
 
 //
 // External functions
--
2.6.3.windows.1

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

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

[Ard Biesheuvel]

On 19 February 2016 at 01:43, Yao, Jiewen  wrote:
> Thanks. It seems my misunderstanding.
>
> Just want to double confirm: It is expected to see memory attribute table 
> like below. Right?
>

Correct.

>   0x00013c0e-0x00013c0e [Runtime Code   |RUN|  |XP|  |  |  ]
>   0x00013c0f-0x00013c0f [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013c10-0x00013c12 [Runtime Code   |RUN|  |XP|  |  |  ]
>   0x00013c13-0x00013c13 [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013c14-0x00013c15 [Runtime Code   |RUN|  |XP|  |  |  ]
>
>   0x00013c16-0x00013c17 [Runtime Data   |RUN|  |XP|  |  |  ]
>
>   0x00013c1a-0x00013c1a [Runtime Code   |RUN|  |XP|  |  |  ]
>   0x00013c1b-0x00013c1b [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013c1c-0x00013c1d [Runtime Code   |RUN|  |XP|  |  |  ]
>
>   0x00013c1e-0x00013c27 [Runtime Data   |RUN|  |XP|  |  |  ]
>
>   0x00013c28-0x00013c28 [Runtime Code   |RUN|  |XP|  |  |  ]
>   0x00013c29-0x00013c29 [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013c2a-0x00013c2c [Runtime Code   |RUN|  |XP|  |  |  ]
>
>   0x00013c2d-0x00013c31 [Runtime Data   |RUN|  |XP|  |  |  ]
>
>   0x00013c32-0x00013c32 [Runtime Code   |RUN|  |XP|  |  |  ]
>   0x00013c33-0x00013c33 [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013c34-0x00013c36 [Runtime Code   |RUN|  |XP|  |  |  ]
>
>   0x00013f65-0x00013f65 [Runtime Code   |RUN|  |XP|  |  |  ]
>   0x00013f66-0x00013f66 [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013f67-0x00013f69 [Runtime Code   |RUN|  |XP|  |  |  ]
>   0x00013f6a-0x00013f6a [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013f6b-0x00013f6d [Runtime Code   |RUN|  |XP|  |  |  ]
>
>   0x00013f6f-0x00013f80 [Runtime Data   |RUN|  |XP|  |  |  ]
>
>
>
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, February 19, 2016 1:44 AM
> To: Yao, Jiewen
> Cc: Laszlo Ersek; edk2-de...@ml01.01.org; Gao, Liming
> Subject: Re: [edk2] [patch 0/7] Add UEFI2.6 MemoryAttributesTable support.
>
> On 14 February 2016 at 06:44, Yao, Jiewen  wrote:
>> HI
>> Thanks to discuss this properties table issue.
>> The purpose of this patch is to *add* UEFI2.6 memory attributes table. This 
>> patch does not handle any UEFI2.5 properties table.
>> If we want to change EDKII code for properties table, I suggest we separate 
>> it from this patch.
>>
>> Is there any comment for adding UEFI2.6 memory attributes table?
>>
>
> I am running into a problem with these patches. According to the spec, each 
> entry in the Memory Attributes table shall have the same type as the region 
> it was carved out of in the UEFI memory map. However, when I dump the table 
> from Linux, it looks something like
>
> UEFI memory map:
>   0x00013c0e-0x00013c15 [Runtime Code   |RUN|  |  |  |  |  ]
>
>   0x00013c16-0x00013c17 [Runtime Data   |RUN|  |  |  |  |  ]
>
>   0x00013c1a-0x00013c1d [Runtime Code   |RUN|  |  |  |  |  ]
>
>   0x00013c1e-0x00013c27 [Runtime Data   |RUN|  |  |  |  |  ]
>
>   0x00013c28-0x00013c2c [Runtime Code   |RUN|  |  |  |  |  ]
>
>   0x00013c2d-0x00013c31 [Runtime Data   |RUN|  |  |  |  |  ]
>
>   0x00013c32-0x00013c36 [Runtime Code   |RUN|  |  |  |  |  ]
>
>   0x00013f65-0x00013f6d [Runtime Code   |RUN|  |  |  |  |  ]
>
>   0x00013f6f-0x00013f80 [Runtime Data   |RUN|  |  |  |  |  ]
>
>
> Memory Attributes Table:
>   0x00013c0e-0x00013c0e [Runtime Data   |RUN|  |XP|  |  |  ]
>   0x00013c0f-0x00013c0f [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013c10-0x00013c12 [Runtime Data   |RUN|  |XP|  |  |  ]
>   0x00013c13-0x00013c13 [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013c14-0x00013c15 [Runtime Data   |RUN|  |XP|  |  |  ]
>
>   0x00013c16-0x00013c17 [Runtime Data   |RUN|  |XP|  |  |  ]
>
>   0x00013c1a-0x00013c1a [Runtime Data   |RUN|  |XP|  |  |  ]
>   0x00013c1b-0x00013c1b [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013c1c-0x00013c1d [Runtime Data   |RUN|  |XP|  |  |  ]
>
>   0x00013c1e-0x00013c27 [Runtime Data   |RUN|  |XP|  |  |  ]
>
>   0x00013c28-0x00013c28 [Runtime Data   |RUN|  |XP|  |  |  ]
>   0x00013c29-0x00013c29 [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013c2a-0x00013c2c [Runtime Data   |RUN|  |XP|  |  |  ]
>
>   0x00013c2d-0x00013c31 [Runtime Data   |RUN|  |XP|  |  |  ]
>
>   0x00013c32-0x00013c32 [Runtime Data   |RUN|  |XP|  |  |  ]
>   0x00013c33-0x00013c33 [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013c34-0x00013c36 [Runtime Data   |RUN|  |XP|  |  |  ]
>
>   0x00013f65-0x00013f65 [Runtime Data   |RUN|  |XP|  |  |  ]
>   0x00013f66-0x00013f66 [Runtime Code   |RUN|  |  |  |  |RO]
>   0x00013f67-0x00013f69 [Runtime Data 

Re: [edk2] [Patch] BaseTools/Trim: Fix the bug for stripping when no line directive in file

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yonghong 
Zhu
Sent: Wednesday, February 17, 2016 6:33 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] BaseTools/Trim: Fix the bug for stripping when no line 
directive in file

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

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

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

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

[edk2] [patch] MdeModulePkg: Should not overwrite the BltX

[Dandan Bi]

when has next line to draw, should not overwrite the BltX
to 0, instead should keep the BltX value that pass into
StringToImage function.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Universal/HiiDatabaseDxe/Font.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Font.c 
b/MdeModulePkg/Universal/HiiDatabaseDxe/Font.c
index 4b70b99..56b30ff 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/Font.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/Font.c
@@ -1,10 +1,10 @@
 /** @file
 Implementation for EFI_HII_FONT_PROTOCOL.
 
 
-Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
 http://opensource.org/licenses/bsd-license.php
 
@@ -2154,13 +2154,12 @@ HiiStringToImage (
   }
 }
 
 NextLine:
 //
-// Recalculate the start point of X/Y axis to draw multi-lines with the 
order of top-to-down
+// Recalculate the start point of Y axis to draw multi-lines with the 
order of top-to-down
 //
-BltX = 0;
 BltY += RowInfo[RowIndex].LineHeight;
 
 RowIndex++;
 Index = NextIndex;
 
-- 
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] IntelFrameworkModulePkg/Bds: Correct the total RAM calculation

[Zeng, Star]

Jeremy,

On 2016/2/19 5:07, Jeremy Linton wrote:

Update the BDS frontpage to pull the RAM ranges from the
smbios extended size fields when applicable. The RAM calculation
also needs to take into account all the RAM ranges being provided
as many machines have multiple physical address ranges.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
  .../Universal/BdsDxe/FrontPage.c   | 45 +++---
  1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c 
b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
index 0a9238c..451eeac 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
@@ -720,7 +720,6 @@ UpdateFrontPageStrings (
  {
UINT8 StrIndex;
CHAR16*NewString;
-  BOOLEAN   Find[5];
EFI_STATUSStatus;
EFI_STRING_ID TokenToUpdate;
EFI_SMBIOS_HANDLE SmbiosHandle;
@@ -730,8 +729,9 @@ UpdateFrontPageStrings (
SMBIOS_TABLE_TYPE4*Type4Record;
SMBIOS_TABLE_TYPE19   *Type19Record;
EFI_SMBIOS_TABLE_HEADER   *Record;
-
-  ZeroMem (Find, sizeof (Find));
+  UINT64InstalledMemory;
+
+  InstalledMemory=0;

//
// Update Front Page strings
@@ -743,12 +743,8 @@ UpdateFrontPageStrings (
);
if (!EFI_ERROR (Status)) {
  SmbiosHandle = SMBIOS_HANDLE_PI_RESERVED;
-do {
-  Status = Smbios->GetNext (Smbios, , NULL, , NULL);
-  if (EFI_ERROR(Status)) {
-break;
-  }
-
+Status = Smbios->GetNext (Smbios, , NULL, , NULL);
+while (!EFI_ERROR(Status)) {
if (Record->Type == EFI_SMBIOS_TYPE_BIOS_INFORMATION) {
  Type0Record = (SMBIOS_TABLE_TYPE0 *) Record;
  StrIndex = Type0Record->BiosVersion;
@@ -756,7 +752,6 @@ UpdateFrontPageStrings (
  TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_BIOS_VERSION);
  HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, 
NULL);
  FreePool (NewString);
-Find[0] = TRUE;
}

if (Record->Type == EFI_SMBIOS_TYPE_SYSTEM_INFORMATION) {
@@ -766,7 +761,6 @@ UpdateFrontPageStrings (
  TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_COMPUTER_MODEL);
  HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, 
NULL);
  FreePool (NewString);
-Find[1] = TRUE;
}

if (Record->Type == EFI_SMBIOS_TYPE_PROCESSOR_INFORMATION) {
@@ -776,7 +770,6 @@ UpdateFrontPageStrings (
  TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_CPU_MODEL);
  HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, 
NULL);
  FreePool (NewString);
-Find[2] = TRUE;
}

if (Record->Type == EFI_SMBIOS_TYPE_PROCESSOR_INFORMATION) {
@@ -785,22 +778,30 @@ UpdateFrontPageStrings (
  TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_CPU_SPEED);
  HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, 
NULL);
  FreePool (NewString);
-Find[3] = TRUE;
}

if ( Record->Type == EFI_SMBIOS_TYPE_MEMORY_ARRAY_MAPPED_ADDRESS ) {
  Type19Record = (SMBIOS_TABLE_TYPE19 *) Record;
-ConvertMemorySizeToString (
-  (UINT32)(RShiftU64((Type19Record->EndingAddress - 
Type19Record->StartingAddress + 1), 10)),
-  
-  );
-TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_MEMORY_SIZE);
-HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, 
NULL);
-FreePool (NewString);
-Find[4] = TRUE;
+if (Type19Record->StartingAddress != 0x ) {
+  InstalledMemory += Type19Record->EndingAddress -
+Type19Record->StartingAddress;


According to SMBIOS spec, the EndingAddress is Physical ending address 
of the *last kilobyte*, and the unit is kilobyte. So the code should be
  InstalledMemory += RShiftU64((Type19Record->EndingAddress - 
Type19Record->StartingAddress + 1), 10);



+} else {
+  InstalledMemory += Type19Record->ExtendedEndingAddress -
+  Type19Record->ExtendedStartingAddress;


According to SMBIOS spec, the ExtendedEndingAddress is Physical ending 
address, in bytes. So similar with above, the code should be
  InstalledMemory += 
RShiftU64((Type19Record->ExtendedEndingAddress - 
Type19Record->ExtendedStartingAddress + 1), 20);



+}
}
-} while ( !(Find[0] && Find[1] && Find[2] && Find[3] && Find[4]));
+
+  Status = Smbios->GetNext (Smbios, , NULL, , NULL);
+}
+
+// now update the total installed RAM size
+InstalledMemory >>= 20;


Remove this code line and comments since the installed 

[edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Enable/Restore XD in SMM

[Michael Kinney]

If XD is supported, then SMM enables it.  The non-SMM execution
environment can choose to enable or disable XD, so the state of
XD must be detected in each SMI and be enabled/restored.

Cc: Jeff Fan 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 18 +++---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h |  3 ++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index 79b7c90..185cb3d 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -1,7 +1,7 @@
 /** @file
 SMM MP service implementation
 
-Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -1019,6 +1019,7 @@ SmiRendezvous (
   BOOLEAN   BspInProgress;
   UINTN Index;
   UINTN Cr2;
+  BOOLEAN   XdDisableFlag;
 
   //
   // Save Cr2 because Page Fault exception in SMM may override its value
@@ -1078,9 +1079,14 @@ SmiRendezvous (
 }
 
 //
-// Try to enable NX
+// Try to enable XD
 //
+XdDisableFlag = FALSE;
 if (mXdSupported) {
+  if ((AsmReadMsr64 (MSR_IA32_MISC_ENABLE) & B_XD_DISABLE_BIT) != 0) {
+XdDisableFlag = TRUE;
+AsmMsrAnd64 (MSR_IA32_MISC_ENABLE, ~B_XD_DISABLE_BIT);
+  }
   ActivateXd ();
 }
 
@@ -1152,7 +1158,6 @@ SmiRendezvous (
 // BSP Handler is always called with a ValidSmi == TRUE
 //
 BSPHandler (CpuIndex, mSmmMpSyncData->EffectiveSyncMode);
-
   } else {
 APHandler (CpuIndex, ValidSmi, mSmmMpSyncData->EffectiveSyncMode);
   }
@@ -1165,6 +1170,13 @@ SmiRendezvous (
 //
 while (mSmmMpSyncData->AllCpusInSync) {
   CpuPause ();
+ }
+
+//
+// Restore XD
+//
+if (XdDisableFlag) {
+  AsmMsrOr64 (MSR_IA32_MISC_ENABLE, B_XD_DISABLE_BIT);
 }
   }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
index 4548467..f91c104 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
@@ -1,7 +1,7 @@
 /** @file
 SMM profile header file.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 /// MSR Register Index
 ///
 #define MSR_IA32_MISC_ENABLE  0x1A0
+#define   B_XD_DISABLE_BITBIT34
 
 //
 // External functions
-- 
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] MdePkg: Fix incorrect PCIe Extended Capabilities definition

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Samer El-Haj-Mahmoud
> Sent: Friday, February 19, 2016 8:01 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Samer
> El-Haj-Mahmoud ; Gao, Liming 
> Subject: [edk2] [PATCH] MdePkg: Fix incorrect PCIe Extended Capabilities
> definition
> 
> The HeaderLog field of the PCIe Extended Capabilities Advanced Error
> Reporting structure was incorrectly defined as a 32-bit field. The PCIe
> 2.1 Base Specification, section 7.10, lists this as 16 bytes, or 4
> DWORDs.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Samer El-Haj-Mahmoud 
> ---
>  MdePkg/Include/IndustryStandard/PciExpress21.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> b/MdePkg/Include/IndustryStandard/PciExpress21.h
> index a9915e0..57cfab2 100644
> --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> @@ -2,6 +2,7 @@
>Support for the latest PCI standard.
> 
>Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
> +  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the
> BSD License
>which accompanies this distribution.  The full text of the license may be
> found at
> @@ -90,7 +91,7 @@ typedef struct {
>UINT32
> CorrectableErrorStatus;
>UINT32
> CorrectableErrorMask;
>UINT32
> AdvancedErrorCapabilitiesAndControl;
> -  UINT32HeaderLog;
> +  UINT32HeaderLog[4];
>UINT32RootErrorCommand;
>UINT32RootErrorStatus;
>UINT16
> ErrorSourceIdentification;
> --
> 2.6.3.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Fu, Siyuan]

Yes I'm also investigating this approach, it will bring a lot of code changes, 
we need to check whether it will bring other unexpected problem.

From: Kinney, Michael D
Sent: Friday, February 19, 2016 10:19 AM
To: Fu, Siyuan ; Kinney, Michael D 

Cc: Subramanian, Sriram (EG Servers Platform SW) ; 
El-Haj-Mahmoud, Samer ; Wu, Jiaxin 
; Hegde, Nagaraj P ; Zimmer, 
Vincent ; Li, Ruth ; Ye, Ting 
; edk2-devel@lists.01.org
Subject: RE: Using PCD to set default policy for IPv4/IPv6

Siyuan,

>From the flow chart, it looks like a design issue in the current 
>implementation.  The UEFI Spec defines config protocols, but there is a use 
>case for a newly added NIC that does not allow the platform to use the config 
>protocols before the configuration information is used to start higher layers 
>in the network stack (i.e. DHCP).

Can we adjust the design, so the config protocols are produced earlier, so the 
platform can have the option to set config information before the config 
information is used?

Thanks,

Mike

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

Correct a typo
If a PCD should NOT be used from the UEFI compliance point of view,

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


Hi, Mike



Seems HP have some special use case that couldn't apply the fast boot, so let's 
just put it aside and let me describe more clearly why the problem couldn't be 
solved by a platform driver/PCD or a platform HII configuration.



First, the "default policy" here we are talking about, means the policy for a 
newly detected NIC by the IP driver. When IP driver recognized a NIC which 
hasn't been managed by itself before, it will set the "default policy" to this 
NIC, and save it in NV variable. Once the policy is changed by anyone using the 
IP4/6 Config protocol, the NV setting will be overridden by the new setting, 
and keep effect over platform reset.

Second, when IP/DHCP driver is started, it will send out the DHCP Discover(for 
IPv4)/Solicit(v6) message immediately if the policy for this NIC is 
"DHCP(v4)/Auto(v6)".



The IP driver binding start flow chart is shown in the attached picture. We can 
see that if a platform driver is used to override the policy setting, it could 
only be started after the IP driver, because it need to consume the IP Config 
protocol, which is produced in the IP driver binding start function. But that 
time point is too late to override the policy to 'static'-the first DHCP 
message has already been sent out, which is the problem we want to solved.



And there are 2 points I want to highlight:

1.  The "default policy" only impact a new detected NIC device, any new 
configured policy will be saved and override the old one. So if a platform 
driver is used to set the policy to "static", it will only fail to prevent the 
DHCP message send out in the first boot. In all subsequent boot/reset flow, the 
policy is already "static" so the problem doesn't exist.

2.  The "default policy" only impact the IP4/6 driver, any 3rd 
driver/application shouldn't depend on the default policy setting. In fact, any 
3rd driver/application can't depend on the default policy setting to implement 
their functionality. The reason is also simple: the default policy only take 
effect on the first boot or on the new plug-in device, and may be override by 

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

[Kinney, Michael D]

Siyuan,

>From the flow chart, it looks like a design issue in the current 
>implementation.  The UEFI Spec defines config protocols, but there is a use 
>case for a newly added NIC that does not allow the platform to use the config 
>protocols before the configuration information is used to start higher layers 
>in the network stack (i.e. DHCP).

Can we adjust the design, so the config protocols are produced earlier, so the 
platform can have the option to set config information before the config 
information is used?

Thanks,

Mike

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

Correct a typo
If a PCD should NOT be used from the UEFI compliance point of view,

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


Hi, Mike



Seems HP have some special use case that couldn't apply the fast boot, so let's 
just put it aside and let me describe more clearly why the problem couldn't be 
solved by a platform driver/PCD or a platform HII configuration.



First, the "default policy" here we are talking about, means the policy for a 
newly detected NIC by the IP driver. When IP driver recognized a NIC which 
hasn't been managed by itself before, it will set the "default policy" to this 
NIC, and save it in NV variable. Once the policy is changed by anyone using the 
IP4/6 Config protocol, the NV setting will be overridden by the new setting, 
and keep effect over platform reset.

Second, when IP/DHCP driver is started, it will send out the DHCP Discover(for 
IPv4)/Solicit(v6) message immediately if the policy for this NIC is 
"DHCP(v4)/Auto(v6)".



The IP driver binding start flow chart is shown in the attached picture. We can 
see that if a platform driver is used to override the policy setting, it could 
only be started after the IP driver, because it need to consume the IP Config 
protocol, which is produced in the IP driver binding start function. But that 
time point is too late to override the policy to 'static'-the first DHCP 
message has already been sent out, which is the problem we want to solved.



And there are 2 points I want to highlight:

1.   The "default policy" only impact a new detected NIC device, any new 
configured policy will be saved and override the old one. So if a platform 
driver is used to set the policy to "static", it will only fail to prevent the 
DHCP message send out in the first boot. In all subsequent boot/reset flow, the 
policy is already "static" so the problem doesn't exist.

2.   The "default policy" only impact the IP4/6 driver, any 3rd 
driver/application shouldn't depend on the default policy setting. In fact, any 
3rd driver/application can't depend on the default policy setting to implement 
their functionality. The reason is also simple: the default policy only take 
effect on the first boot or on the new plug-in device, and may be override by 
any other code once the IP Config protocol is produced, as a result if any 
modules other than the IP4/6 driver have the assumption that the policy is 
always the "default policy", it will definitely fall into error. The only 
correct way is first to Get the current policy setting, and Set it if needed.



Above is the detail reason why we need a method, like a PCD we proposed, to set 
the "default policy". A platform driver could use IP Config protocol to set the 
policy, but it has no method to prevent the DHCP message on a new detected 
device, that's the problem we want to solve.



If a PCD should NOT be used from the UEFI compliance point of view, we need to 
consider other method to give a chance to the platform driver to override the 
setting and prevent the DHCP message even on the first boot, if the product 
really need it.



Best Regards

Siyuan



> -Original Message-

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On 

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

[Ruiyu Ni]

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

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

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

-- 
2.7.0.windows.1

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

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

[Ruiyu Ni]

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

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

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
index 50ed866..55c9ce2 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
@@ -1744,6 +1744,53 @@ PciIoAttributes (
 }
 
 /**
+  Retrieve the AddrTranslationOffset from RootBridgeIo for the
+  specified range.
+
+  @param RootBridgeIoRoot Bridge IO instance.
+  @param AddrRangeMinThe base address of the MMIO.
+  @param AddrLen The length of the MMIO.
+
+  @retval The AddrTranslationOffset from RootBridgeIo for the 
+  specified range, or (UINT64) -1 if the range is not
+  found in RootBridgeIo.
+**/
+UINT64
+GetMmioAddressTranslationOffset (
+  EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL   *RootBridgeIo,
+  UINT64AddrRangeMin,
+  UINT64AddrLen
+  )
+{
+  EFI_STATUSStatus;
+  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Configuration;
+
+  Status = RootBridgeIo->Configuration (
+   RootBridgeIo,
+   (VOID **) 
+   );
+  if (EFI_ERROR (Status)) {
+return (UINT64) -1;
+  }
+
+  while (Configuration->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR) {
+if ((Configuration->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) &&
+(Configuration->AddrRangeMin <= AddrRangeMin) &&
+(Configuration->AddrRangeMin + Configuration->AddrLen >= AddrRangeMin 
+ AddrLen)
+) {
+  return Configuration->AddrTranslationOffset;
+}
+Configuration++;
+  }
+
+  //
+  // The resource occupied by BAR should be in the range reported by 
RootBridge.
+  //
+  ASSERT (Configuration->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR);
+  return (UINT64) -1;
+}
+
+/**
   Gets the attributes that this PCI controller supports setting on a BAR using
   SetBarAttributes(), and retrieves the list of resource descriptors for a BAR.
 
@@ -1863,6 +1910,21 @@ PciIoGetBarAttributes (
 End   = (EFI_ACPI_END_TAG_DESCRIPTOR *) (Descriptor + 1);
 End->Desc = ACPI_END_TAG_DESCRIPTOR;
 End->Checksum = 0;
+
+//
+// Get the Address Translation Offset
+//
+if (Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) {
+  Descriptor->AddrTranslationOffset = GetMmioAddressTranslationOffset (
+PciIoDevice->PciRootBridgeIo,
+Descriptor->AddrRangeMin,
+Descriptor->AddrLen
+);
+  if (Descriptor->AddrTranslationOffset == (UINT64) -1) {
+FreePool (Descriptor);
+return EFI_UNSUPPORTED;
+  }
+}
   }
 
   return EFI_SUCCESS;
-- 
2.7.0.windows.1

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

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

[Ruiyu Ni]

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

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

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

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: Bi, Dandan
> Sent: Wednesday, February 17, 2016 6:15 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; Dong, Eric
> Subject: [patch] MdeModulePkg: Refine the code in BootMaintenanceManagerUiLib
> 
> Refine the code in function Var_UpdateDriverOption and Var_UpdateBootOption,
> use the existed API(EfiBootManagerInitializeLoadOption and
> EfiBootManagerAddLoadOptionVariable) supplied by UefiBootManagerLib
> to replace the same logic in the two functions. And remove the useless
> code.
> 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  .../BootMaintenanceManager.h   |  11 +-
>  .../BootMaintenanceManagerUiLib/BootOption.c   |  21 +-
>  .../Library/BootMaintenanceManagerUiLib/Variable.c | 226 
> ++---
>  3 files changed, 71 insertions(+), 187 deletions(-)
> 
> diff --git 
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
> index 24526e1..b482bf2 100644
> --- 
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
> +++ 
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
> @@ -1,9 +1,9 @@
>  /** @file
>  Header file for boot maintenance module.
> 
> -Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD 
> License
>  which accompanies this distribution.  The full text of the license may be 
> found at
>  http://opensource.org/licenses/bsd-license.php
> 
> @@ -266,28 +266,19 @@ typedef struct {
>EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
>  } BM_TERMINAL_CONTEXT;
> 
>  typedef struct {
>BOOLEAN   IsBootNext;
> -  BOOLEAN   LoadOptionModified;
>BOOLEAN   Deleted;
> 
>BOOLEAN   IsLegacy;
> -  BOOLEAN   IsActive;
> -  BOOLEAN   ForceReconnect;
> -  UINTN OptionalDataSize;
> -
> -  UINTN LoadOptionSize;
> -  UINT8 *LoadOption;
> 
>UINT32Attributes;
>UINT16FilePathListLength;
>UINT16*Description;
>EFI_DEVICE_PATH_PROTOCOL  *FilePathList;
>UINT8 *OptionalData;
> -
> -  UINT16BbsIndex;
>  } BM_LOAD_CONTEXT;
> 
>  typedef struct {
> 
>BOOLEAN   IsActive;
> diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> index a375d61..5665d04 100644
> --- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> +++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> @@ -3,11 +3,11 @@
> 
>Include file system navigation, system handle selection
> 
>Boot option manipulation
> 
> -Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD 
> License
>  which accompanies this distribution.  The full text of the license may be 
> found at
>  http://opensource.org/licenses/bsd-license.php
> 
> @@ -114,11 +114,10 @@ BOpt_DestroyMenuEntry (
>//
>switch (MenuEntry->ContextSelection) {
>case BM_LOAD_CONTEXT_SELECT:
>  LoadContext = (BM_LOAD_CONTEXT *) MenuEntry->VariableContext;
>  FreePool (LoadContext->FilePathList);
> -FreePool (LoadContext->LoadOption);
>  if (LoadContext->OptionalData != NULL) {
>FreePool (LoadContext->OptionalData);
>  }
>  FreePool (LoadContext);
>  break;
> @@ -334,11 +333,10 @@ BOpt_GetBootOptions (
> 
>  LoadOptionPtr   = LoadOption;
>  LoadOptionEnd   = LoadOption + BootOptionSize;
> 
>  NewMenuEntry->OptionNumber  = BootOrderList[Index];
> -NewLoadContext->LoadOptionModified  = FALSE;
>  NewLoadContext->Deleted = FALSE;
>  NewLoadContext->IsBootNext  = BootNextFlag;
> 
>  //
>  // Is a Legacy Device?
> @@ -372,17 +370,12 @@ BOpt_GetBootOptions (
>  //
>  // LoadOption is a pointer type of UINT8
>  // for easy use with following LOAD_OPTION
>  // embedded in this struct
>  //
> -NewLoadContext->LoadOption  = LoadOption;
> -NewLoadContext->LoadOptionSize  = BootOptionSize;
> 
>  NewLoadContext->Attributes  = *(UINT32 *) LoadOptionPtr;
> -NewLoadContext->IsActive= (BOOLEAN) 

[edk2] [Patch v2] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Michael Kinney]

The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE
in the MP Services Protocol service StartAllAPs().  Any function
used as an EFI_AP_PROCEDURE must use EFIAPI calling convention.

Cc: Laszlo Ersek 
Cc: Jeff Fan 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 9 +
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 5 +++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index ec4ec9b..9c4f387 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1,7 +1,7 @@
 /** @file
 Enable SMM profile.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -930,8 +930,9 @@ InitSmmProfileInternal (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
-  VOID
+  IN OUT VOID   *Buffer
   )
 {
   UINT32 RegEax;
@@ -1001,7 +1002,7 @@ CheckProcessorFeature (
   //
   // Check if XD and BTS are supported on all processors.
   //
-  CheckFeatureSupported ();
+  CheckFeatureSupported (NULL);
 
   //
   //Check on other processors if BSP supports this
@@ -1009,7 +1010,7 @@ CheckProcessorFeature (
   if (mXdSupported || mBtsSupported) {
 MpServices->StartupAllAPs (
   MpServices,
-  (EFI_AP_PROCEDURE) CheckFeatureSupported,
+  CheckFeatureSupported,
   TRUE,
   NULL,
   0,
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
index 4548467..d65048e 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
@@ -1,7 +1,7 @@
 /** @file
 SMM profile header file.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -97,8 +97,9 @@ PageFaultIdtHandlerSmmProfile (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
-  VOID
+  IN OUT VOID   *Buffer
   );
 
 /**
-- 
2.6.3.windows.1

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

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

[Fu, Siyuan]

Correct a typo
If a PCD should NOT be used from the UEFI compliance point of view,

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


Hi, Mike



Seems HP have some special use case that couldn't apply the fast boot, so let's 
just put it aside and let me describe more clearly why the problem couldn't be 
solved by a platform driver/PCD or a platform HII configuration.



First, the "default policy" here we are talking about, means the policy for a 
newly detected NIC by the IP driver. When IP driver recognized a NIC which 
hasn't been managed by itself before, it will set the "default policy" to this 
NIC, and save it in NV variable. Once the policy is changed by anyone using the 
IP4/6 Config protocol, the NV setting will be overridden by the new setting, 
and keep effect over platform reset.

Second, when IP/DHCP driver is started, it will send out the DHCP Discover(for 
IPv4)/Solicit(v6) message immediately if the policy for this NIC is 
"DHCP(v4)/Auto(v6)".



The IP driver binding start flow chart is shown in the attached picture. We can 
see that if a platform driver is used to override the policy setting, it could 
only be started after the IP driver, because it need to consume the IP Config 
protocol, which is produced in the IP driver binding start function. But that 
time point is too late to override the policy to 'static'-the first DHCP 
message has already been sent out, which is the problem we want to solved.



And there are 2 points I want to highlight:

1.  The "default policy" only impact a new detected NIC device, any new 
configured policy will be saved and override the old one. So if a platform 
driver is used to set the policy to "static", it will only fail to prevent the 
DHCP message send out in the first boot. In all subsequent boot/reset flow, the 
policy is already "static" so the problem doesn't exist.

2.  The "default policy" only impact the IP4/6 driver, any 3rd 
driver/application shouldn't depend on the default policy setting. In fact, any 
3rd driver/application can't depend on the default policy setting to implement 
their functionality. The reason is also simple: the default policy only take 
effect on the first boot or on the new plug-in device, and may be override by 
any other code once the IP Config protocol is produced, as a result if any 
modules other than the IP4/6 driver have the assumption that the policy is 
always the "default policy", it will definitely fall into error. The only 
correct way is first to Get the current policy setting, and Set it if needed.



Above is the detail reason why we need a method, like a PCD we proposed, to set 
the "default policy". A platform driver could use IP Config protocol to set the 
policy, but it has no method to prevent the DHCP message on a new detected 
device, that's the problem we want to solve.



If a PCD should NOT be used from the UEFI compliance point of view, we need to 
consider other method to give a chance to the platform driver to override the 
setting and prevent the DHCP message even on the first boot, if the product 
really need it.



Best Regards

Siyuan



> -Original Message-

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of

> Subramanian, Sriram (EG Servers Platform SW)

> Sent: Thursday, February 18, 2016 3:32 PM

> To: Kinney, Michael D 
> >; 
> El-Haj-Mahmoud,

> Samer >; 
> Wu, Jiaxin

> >; Hegde, Nagaraj P 
> >;

> Zimmer, Vincent >; 
> Li, Ruth >;

> Ye, Ting >; Fu, Siyuan 
> >; edk2-

> de...@lists.01.org

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

>

> The IP4_CONFIG2 and IP6_CONFIG protocols need to know the current policy

> to decide if they need to do something during their DBStart (such as 
> initiating

> a DHCPv4/v6 if policy is set so). It is not necessary for the platform to 
> have a

> per-NIC interface policy, or the platform may choose to set policies only on

> specific NICs. For others, and in general the protocol needs to have a policy

> to apply, for which NetworkPkg could have PCDs that are consumed by these

> 

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

[Kinney, Michael D]

Jiaxin,

The UEFI network stack is produces by UEFI Drivers that follow the UEFI Driver 
Model.  The IPv4 and IPv6 stack can be produced by UEFI drivers loaded from 
system FLASH or loaded from Drivers Options or loaded from Shell or loaded from 
PCI Option ROMs.

Since the UEFI Spec 2.6 was updated to not specify a specific policy, and the 
UEFI spec allows different versions of UEFI IPv4/6 drivers to be active in a 
platform at the same time and selected based on UEFI Driver Model rules, a 
platform that wants a specific policy is now required to set the policy on 
every NIC.  The platform must not assume the UEFI IPv4/6 drivers in system 
FLASH are the drivers that are always used.

The means adding the PCD does not provide any value, so PCDs should not be 
added.

Thanks,

Mike

> -Original Message-
> From: Wu, Jiaxin
> Sent: Thursday, February 18, 2016 5:25 PM
> To: Subramanian, Sriram (EG Servers Platform SW) ; Kinney, 
> Michael D
> ; El-Haj-Mahmoud, Samer 
> ;
> Hegde, Nagaraj P ; Zimmer, Vincent 
> ;
> Li, Ruth ; Ye, Ting ; Fu, Siyuan
> ; edk2-devel@lists.01.org
> Subject: RE: Using PCD to set default policy for IPv4/IPv6
> 
> The immediate advantage of using these PCDs is that the platform can change 
> the default
> behavior for all started NICs, that will not be limited to the additional 
> setting.
> 
> Thanks.
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Subramanian, Sriram (EG Servers Platform SW)
> > Sent: Thursday, February 18, 2016 3:32 PM
> > To: Kinney, Michael D ; El-Haj-Mahmoud,
> > Samer ; Wu, Jiaxin
> > ; Hegde, Nagaraj P ;
> > Zimmer, Vincent ; Li, Ruth ;
> > Ye, Ting ; Fu, Siyuan ; edk2-
> > de...@lists.01.org
> > Subject: Re: [edk2] Using PCD to set default policy for IPv4/IPv6
> >
> > The IP4_CONFIG2 and IP6_CONFIG protocols need to know the current
> > policy to decide if they need to do something during their DBStart (such as
> > initiating a DHCPv4/v6 if policy is set so). It is not necessary for the 
> > platform
> > to have a per-NIC interface policy, or the platform may choose to set 
> > policies
> > only on specific NICs. For others, and in general the protocol needs to 
> > have a
> > policy to apply, for which NetworkPkg could have PCDs that are consumed by
> > these protocols. With this approach, platform code can set the PCD to what
> > policy the platform wants for _all_ its NICs, and it can selectively change 
> > it by
> > calling the set policy API.
> >
> > Thanks,
> > Sriram.
> >
> > -Original Message-
> > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > Sent: Thursday, February 18, 2016 5:48 AM
> > To: El-Haj-Mahmoud, Samer; Wu, Jiaxin; Subramanian, Sriram (EG Servers
> > Platform SW); Hegde, Nagaraj P; Zimmer, Vincent; Li, Ruth; Ye, Ting; Fu,
> > Siyuan; edk2-devel@lists.01.org; Kinney, Michael D
> > Subject: RE: Using PCD to set default policy for IPv4/IPv6
> >
> > Samer,
> >
> > A platform driver can be implemented to set the policy without defining
> > PCDs in the MdeModulePkg or NetworkPkg.
> >
> > Instead, a platform package can choose to define PCDs and potentially use
> > those PCD values to set policy in calls to the EFI_IP4_CONFIG2_POLICY or
> > EFI_IP6_CONFIG_POLICY.  Or it could be an algorithm or HII forms in platform
> > driver to set policy.
> >
> > Mike
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > > El-Haj-Mahmoud, Samer
> > > Sent: Wednesday, February 17, 2016 3:20 PM
> > > To: Kinney, Michael D ; Wu, Jiaxin
> > > ; Subramanian, Sriram (EG Servers Platform SW)
> > > ; Hegde, Nagaraj P ;
> > > Zimmer, Vincent ; Li, Ruth
> > > ; Ye, Ting ; Fu, Siyuan
> > > ; edk2-devel@lists.01.org
> > > Subject: Re: [edk2] Using PCD to set default policy for IPv4/IPv6
> > >
> > > 1) Yes you could... that is one implementation choice. There are cases
> > > where you need to start multiple adapters, just for inventory/other
> > > management tasks, and you do not want all of them to default to
> > > DHCP/automatic
> > >
> > > 2) Yes a platform driver can set the policy through the PCDs. I
> > > thought this was the intention of introducing the PCDs. Previously,
> > > the policy was hard-coded to DHCP/auto in the EDK2 drivers.
> > >
> > >
> > >
> > > -Original Message-
> > > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > 

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

[Fu, Siyuan]

Hi, Mike



Seems HP have some special use case that couldn't apply the fast boot, so let's 
just put it aside and let me describe more clearly why the problem couldn't be 
solved by a platform driver/PCD or a platform HII configuration.



First, the "default policy" here we are talking about, means the policy for a 
newly detected NIC by the IP driver. When IP driver recognized a NIC which 
hasn't been managed by itself before, it will set the "default policy" to this 
NIC, and save it in NV variable. Once the policy is changed by anyone using the 
IP4/6 Config protocol, the NV setting will be overridden by the new setting, 
and keep effect over platform reset.

Second, when IP/DHCP driver is started, it will send out the DHCP Discover(for 
IPv4)/Solicit(v6) message immediately if the policy for this NIC is 
"DHCP(v4)/Auto(v6)".



The IP driver binding start flow chart is shown in the attached picture. We can 
see that if a platform driver is used to override the policy setting, it could 
only be started after the IP driver, because it need to consume the IP Config 
protocol, which is produced in the IP driver binding start function. But that 
time point is too late to override the policy to 'static'-the first DHCP 
message has already been sent out, which is the problem we want to solved.



And there are 2 points I want to highlight:

1.  The "default policy" only impact a new detected NIC device, any new 
configured policy will be saved and override the old one. So if a platform 
driver is used to set the policy to "static", it will only fail to prevent the 
DHCP message send out in the first boot. In all subsequent boot/reset flow, the 
policy is already "static" so the problem doesn't exist.

2.  The "default policy" only impact the IP4/6 driver, any 3rd 
driver/application shouldn't depend on the default policy setting. In fact, any 
3rd driver/application can't depend on the default policy setting to implement 
their functionality. The reason is also simple: the default policy only take 
effect on the first boot or on the new plug-in device, and may be override by 
any other code once the IP Config protocol is produced, as a result if any 
modules other than the IP4/6 driver have the assumption that the policy is 
always the "default policy", it will definitely fall into error. The only 
correct way is first to Get the current policy setting, and Set it if needed.



Above is the detail reason why we need a method, like a PCD we proposed, to set 
the "default policy". A platform driver could use IP Config protocol to set the 
policy, but it has no method to prevent the DHCP message on a new detected 
device, that's the problem we want to solve.



If a PCD should be used from the UEFI compliance point of view, we need to 
consider other method to give a chance to the platform driver to override the 
setting and prevent the DHCP message even on the first boot, if the product 
really need it.



Best Regards

Siyuan



> -Original Message-

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of

> Subramanian, Sriram (EG Servers Platform SW)

> Sent: Thursday, February 18, 2016 3:32 PM

> To: Kinney, Michael D ; El-Haj-Mahmoud,

> Samer ; Wu, Jiaxin

> ; Hegde, Nagaraj P ;

> Zimmer, Vincent ; Li, Ruth ;

> Ye, Ting ; Fu, Siyuan ; edk2-

> de...@lists.01.org

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

>

> The IP4_CONFIG2 and IP6_CONFIG protocols need to know the current policy

> to decide if they need to do something during their DBStart (such as 
> initiating

> a DHCPv4/v6 if policy is set so). It is not necessary for the platform to 
> have a

> per-NIC interface policy, or the platform may choose to set policies only on

> specific NICs. For others, and in general the protocol needs to have a policy

> to apply, for which NetworkPkg could have PCDs that are consumed by these

> protocols. With this approach, platform code can set the PCD to what policy

> the platform wants for _all_ its NICs, and it can selectively change it by 
> calling

> the set policy API.

>

> Thanks,

> Sriram.

>

> -Original Message-

> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]

> Sent: Thursday, February 18, 2016 5:48 AM

> To: El-Haj-Mahmoud, Samer; Wu, Jiaxin; Subramanian, Sriram (EG Servers

> Platform SW); Hegde, Nagaraj P; Zimmer, Vincent; Li, Ruth; Ye, Ting; Fu,

> Siyuan; edk2-devel@lists.01.org; Kinney, 
> Michael D

> Subject: RE: Using PCD to set default policy for IPv4/IPv6

>

> Samer,

>

> A platform driver can be implemented to set the policy without defining PCDs

> in the MdeModulePkg or NetworkPkg.

>

> Instead, a platform package can choose to define PCDs and potentially use

> those PCD 

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

[Wu, Jiaxin]

The immediate advantage of using these PCDs is that the platform can change the 
default behavior for all started NICs, that will not be limited to the 
additional setting.  

Thanks.
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Subramanian, Sriram (EG Servers Platform SW)
> Sent: Thursday, February 18, 2016 3:32 PM
> To: Kinney, Michael D ; El-Haj-Mahmoud,
> Samer ; Wu, Jiaxin
> ; Hegde, Nagaraj P ;
> Zimmer, Vincent ; Li, Ruth ;
> Ye, Ting ; Fu, Siyuan ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] Using PCD to set default policy for IPv4/IPv6
> 
> The IP4_CONFIG2 and IP6_CONFIG protocols need to know the current
> policy to decide if they need to do something during their DBStart (such as
> initiating a DHCPv4/v6 if policy is set so). It is not necessary for the 
> platform
> to have a per-NIC interface policy, or the platform may choose to set policies
> only on specific NICs. For others, and in general the protocol needs to have a
> policy to apply, for which NetworkPkg could have PCDs that are consumed by
> these protocols. With this approach, platform code can set the PCD to what
> policy the platform wants for _all_ its NICs, and it can selectively change 
> it by
> calling the set policy API.
> 
> Thanks,
> Sriram.
> 
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Thursday, February 18, 2016 5:48 AM
> To: El-Haj-Mahmoud, Samer; Wu, Jiaxin; Subramanian, Sriram (EG Servers
> Platform SW); Hegde, Nagaraj P; Zimmer, Vincent; Li, Ruth; Ye, Ting; Fu,
> Siyuan; edk2-devel@lists.01.org; Kinney, Michael D
> Subject: RE: Using PCD to set default policy for IPv4/IPv6
> 
> Samer,
> 
> A platform driver can be implemented to set the policy without defining
> PCDs in the MdeModulePkg or NetworkPkg.
> 
> Instead, a platform package can choose to define PCDs and potentially use
> those PCD values to set policy in calls to the EFI_IP4_CONFIG2_POLICY or
> EFI_IP6_CONFIG_POLICY.  Or it could be an algorithm or HII forms in platform
> driver to set policy.
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > El-Haj-Mahmoud, Samer
> > Sent: Wednesday, February 17, 2016 3:20 PM
> > To: Kinney, Michael D ; Wu, Jiaxin
> > ; Subramanian, Sriram (EG Servers Platform SW)
> > ; Hegde, Nagaraj P ;
> > Zimmer, Vincent ; Li, Ruth
> > ; Ye, Ting ; Fu, Siyuan
> > ; edk2-devel@lists.01.org
> > Subject: Re: [edk2] Using PCD to set default policy for IPv4/IPv6
> >
> > 1) Yes you could... that is one implementation choice. There are cases
> > where you need to start multiple adapters, just for inventory/other
> > management tasks, and you do not want all of them to default to
> > DHCP/automatic
> >
> > 2) Yes a platform driver can set the policy through the PCDs. I
> > thought this was the intention of introducing the PCDs. Previously,
> > the policy was hard-coded to DHCP/auto in the EDK2 drivers.
> >
> >
> >
> > -Original Message-
> > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > Sent: Wednesday, February 17, 2016 3:00 PM
> > To: El-Haj-Mahmoud, Samer ; Wu,
> Jiaxin
> > ; Subramanian, Sriram (EG Servers Platform SW)
> > ; Hegde, Nagaraj P ;
> > Zimmer, Vincent ; Li, Ruth
> > ; Ye, Ting ; Fu, Siyuan
> > ; edk2-devel@lists.01.org; Kinney, Michael D
> > 
> > Subject: RE: Using PCD to set default policy for IPv4/IPv6
> >
> > Hi Samer,
> >
> > 1) If there are a large number of adapters, can you choose to only
> > start the ones needed to boot?
> >
> > 2) Can't a platform driver set the policy needed for each NIC that is
> required to boot?
> >
> > Mike
> >
> >
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of El-Haj-Mahmoud, Samer
> > > Sent: Wednesday, February 17, 2016 12:53 PM
> > > To: Kinney, Michael D ; Wu, Jiaxin
> > > ; Subramanian, Sriram (EG Servers Platform SW)
> > > ; Hegde, Nagaraj P ;
> > > Zimmer, Vincent ; Li, Ruth
> > > ; Ye, Ting ; Fu, Siyuan
> > > ; edk2-devel@lists.01.org
> > > Subject: Re: [edk2] Using PCD to set default policy for IPv4/IPv6
> > >
> > > I believe the PCDs are just to let the core 

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Fan, Jeff]

Laszlo,

Good catch. I agree it should be

VOID
EFIAPI
CheckFeatureSupported (
  IN OUT VOID  *Buffer
  );

Jeff
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, February 19, 2016 4:09 AM
To: Kinney, Michael D; edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Fan, Jeff
Subject: Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to 
CheckFeatureSupported()

On 02/18/16 20:41, Michael Kinney wrote:
> The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE in 
> the MP Services Protocol service StartAllAPs().  Any function used as 
> an EFI_AP_SERVICE must use EFIAPI calling convention.

I think "EFI_AP_SERVICE" should be "EFI_AP_PROCEDURE" here.

> 
> Cc: Jeff Fan 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 3 ++-  
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)

EFI_AP_PROCEDURE is defined, in "MdePkg/Include/Pi/PiMultiPhase.h", as:

typedef
VOID
(EFIAPI *EFI_AP_PROCEDURE)(
  IN OUT VOID  *Buffer
  );

Let's compare the prototype of CheckFeatureSupported()
[UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h]:

VOID
CheckFeatureSupported (
  VOID
  );

The lack of EFIAPI is just one (I'd say: the smaller) problem; the parameter 
list is incorrect regardless of calling convention. Therefore:

> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> index ec4ec9b..0279f89 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> @@ -1,7 +1,7 @@
>  /** @file
>  Enable SMM profile.
>  
> -Copyright (c) 2012 - 2015, Intel Corporation. All rights 
> reserved.
> +Copyright (c) 2012 - 2016, Intel Corporation. All rights 
> +reserved.
>  This program and the accompanying materials  are licensed and made 
> available under the terms and conditions of the BSD License  which 
> accompanies this distribution.  The full text of the license may be 
> found at @@ -930,6 +930,7 @@ InitSmmProfileInternal (
>  
>  **/
>  VOID
> +EFIAPI
>  CheckFeatureSupported (
>VOID
>)

Here I propose to fix up the parameter list as well,


> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> index 4548467..5cb8d7c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> @@ -1,7 +1,7 @@
>  /** @file
>  SMM profile header file.
>  
> -Copyright (c) 2012 - 2015, Intel Corporation. All rights 
> reserved.
> +Copyright (c) 2012 - 2016, Intel Corporation. All rights 
> +reserved.
>  This program and the accompanying materials  are licensed and made 
> available under the terms and conditions of the BSD License  which 
> accompanies this distribution.  The full text of the license may be 
> found at @@ -97,6 +97,7 @@ PageFaultIdtHandlerSmmProfile (
>  
>  **/
>  VOID
> +EFIAPI
>  CheckFeatureSupported (
>VOID
>);
> 

here too; *plus* drop the (now unnecessary) cast from:

MpServices->StartupAllAPs (
  MpServices,
  (EFI_AP_PROCEDURE) CheckFeatureSupported,
  TRUE,
  NULL,
  0,
  NULL,
  NULL
  );

in CheckProcessorFeature().

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

Re: [edk2] [PATCH 1/2] ShellPkg: Support finding help message embedded in resource section.

[Gao, Liming]

Shumin:
  Could you use HiiLib HiiGetString() API to get string value instead of parse 
HII string package？

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Qiu 
Shumin
Sent: Saturday, February 6, 2016 3:22 PM
To: edk2-devel@lists.01.org
Cc: Carsey, Jaben ; Ni, Ruiyu ; 
Qiu, Shumin ; Gao, Liming 
Subject: [edk2] [PATCH 1/2] ShellPkg: Support finding help message embedded in 
resource section.

UEFI Shell scandalizes the help message in spec level so that a standalone UEFI 
shell application can never get "-?" switch,
instead the Shell core (interpreter) detects the "-?" and finds .MAN file for 
that shell application in certain spec defined paths,
then show the help extracted from that .MAN file.

But it means distributing a UEFI shell application not only means distributing 
a .EFI file but also distributing a .MAN file.
If the text formatted .MAN file is corrupted (edited by user by mistake), or is 
missing (deleted by user by mistake),
no help will be shown to user.

So this patch enhance the Shell to make it support finding help message 
imbedded in resource section of application image.

Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
---
 ShellPkg/Application/Shell/Shell.h  |   3 +-
 ShellPkg/Application/Shell/ShellManParser.c | 739 +++-
 2 files changed, 726 insertions(+), 16 deletions(-)

diff --git a/ShellPkg/Application/Shell/Shell.h 
b/ShellPkg/Application/Shell/Shell.h
index 351b941..df7199b 100644
--- a/ShellPkg/Application/Shell/Shell.h
+++ b/ShellPkg/Application/Shell/Shell.h
@@ -2,7 +2,7 @@
   function definitions for internal to shell functions.
 
   (C) Copyright 2014 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/ShellPkg/Application/Shell/ShellManParser.c 
b/ShellPkg/Application/Shell/ShellManParser.c
index 222cdaf..cb91582 100644
--- a/ShellPkg/Application/Shell/ShellManParser.c
+++ b/ShellPkg/Application/Shell/ShellManParser.c
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to shell MAN file parser.
 
-  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
   Copyright 2015 Dell Inc.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -37,6 +37,58 @@ InternalShellCharToUpper (
   );
 
 /**
+  Verifies that the filename has .EFI on the end.
+
+  allocates a new buffer and copies the name (appending .EFI if necessary). 
+  Caller to free the buffer.
+
+  @param[in] NameStringoriginal name string
+
+  @return  the new filename with .efi as the extension.
+**/
+CHAR16 *
+EFIAPI
+GetExecuatableFileName (
+  IN CONST CHAR16*NameString
+  )
+{
+  CHAR16  *Buffer; 
+  CHAR16  *SuffixStr;
+  if (NameString == NULL) {
+return (NULL);
+  }
+
+  //
+  // Fix the file name
+  //
+  if (StrnCmp(NameString+StrLen(NameString)-StrLen(L".efi"), L".efi", 
StrLen(L".efi"))==0) {
+Buffer = AllocateCopyPool(StrSize(NameString), NameString);
+  } else if (StrnCmp(NameString+StrLen(NameString)-StrLen(L".man"), L".man", 
StrLen(L".man"))==0) {
+Buffer = AllocateCopyPool(StrSize(NameString), NameString);
+if (Buffer != NULL) {
+  SuffixStr = Buffer+StrLen(Buffer)-StrLen(L".man");
+  StrnCpyS (SuffixStr, StrSize(L".man")/sizeof(CHAR16), L".efi", 
StrLen(L".efi"));
+}
+  } else {
+Buffer = AllocateZeroPool(StrSize(NameString) + 
StrLen(L".efi")*sizeof(CHAR16));
+if (Buffer != NULL) {
+  StrnCpyS( Buffer, 
+(StrSize(NameString) + 
StrLen(L".efi")*sizeof(CHAR16))/sizeof(CHAR16), 
+NameString, 
+StrLen(NameString)
+);
+  StrnCatS( Buffer, 
+(StrSize(NameString) + 
StrLen(L".efi")*sizeof(CHAR16))/sizeof(CHAR16),
+L".efi", 
+StrLen(L".efi")
+);
+}
+  }
+  return (Buffer);
+  
+}
+
+/**
   Verifies that the filename has .MAN on the end.
 
   allocates a new buffer and copies the name (appending .MAN if necessary)
@@ -381,7 +433,7 @@ ManFileFindSections(
 
   Upon a sucessful return the caller is responsible to free the memory in 
*BriefDesc
 
-  

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Yao, Jiewen]

Thanks Laszlo. I agree with you. We had better drop unnecessary cast and fix 
parameter mismatch.

Reviewed-by: jiewen@intel.com


-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, February 19, 2016 4:09 AM
To: Kinney, Michael D; edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Fan, Jeff
Subject: Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to 
CheckFeatureSupported()

On 02/18/16 20:41, Michael Kinney wrote:
> The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE in 
> the MP Services Protocol service StartAllAPs().  Any function used as 
> an EFI_AP_SERVICE must use EFIAPI calling convention.

I think "EFI_AP_SERVICE" should be "EFI_AP_PROCEDURE" here.

> 
> Cc: Jeff Fan 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 3 ++-  
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)

EFI_AP_PROCEDURE is defined, in "MdePkg/Include/Pi/PiMultiPhase.h", as:

typedef
VOID
(EFIAPI *EFI_AP_PROCEDURE)(
  IN OUT VOID  *Buffer
  );

Let's compare the prototype of CheckFeatureSupported()
[UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h]:

VOID
CheckFeatureSupported (
  VOID
  );

The lack of EFIAPI is just one (I'd say: the smaller) problem; the parameter 
list is incorrect regardless of calling convention. Therefore:

> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> index ec4ec9b..0279f89 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> @@ -1,7 +1,7 @@
>  /** @file
>  Enable SMM profile.
>  
> -Copyright (c) 2012 - 2015, Intel Corporation. All rights 
> reserved.
> +Copyright (c) 2012 - 2016, Intel Corporation. All rights 
> +reserved.
>  This program and the accompanying materials  are licensed and made 
> available under the terms and conditions of the BSD License  which 
> accompanies this distribution.  The full text of the license may be 
> found at @@ -930,6 +930,7 @@ InitSmmProfileInternal (
>  
>  **/
>  VOID
> +EFIAPI
>  CheckFeatureSupported (
>VOID
>)

Here I propose to fix up the parameter list as well,


> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> index 4548467..5cb8d7c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> @@ -1,7 +1,7 @@
>  /** @file
>  SMM profile header file.
>  
> -Copyright (c) 2012 - 2015, Intel Corporation. All rights 
> reserved.
> +Copyright (c) 2012 - 2016, Intel Corporation. All rights 
> +reserved.
>  This program and the accompanying materials  are licensed and made 
> available under the terms and conditions of the BSD License  which 
> accompanies this distribution.  The full text of the license may be 
> found at @@ -97,6 +97,7 @@ PageFaultIdtHandlerSmmProfile (
>  
>  **/
>  VOID
> +EFIAPI
>  CheckFeatureSupported (
>VOID
>);
> 

here too; *plus* drop the (now unnecessary) cast from:

MpServices->StartupAllAPs (
  MpServices,
  (EFI_AP_PROCEDURE) CheckFeatureSupported,
  TRUE,
  NULL,
  0,
  NULL,
  NULL
  );

in CheckProcessorFeature().

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

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Fan, Jeff]

Reviewed-by: Jeff Fan 

-Original Message-
From: Kinney, Michael D 
Sent: Friday, February 19, 2016 3:42 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Yao, Jiewen
Subject: [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to 
CheckFeatureSupported()

The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE in the MP 
Services Protocol service StartAllAPs().  Any function used as an 
EFI_AP_SERVICE must use EFIAPI calling convention.

Cc: Jeff Fan 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 3 ++-  
UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index ec4ec9b..0279f89 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1,7 +1,7 @@
 /** @file
 Enable SMM profile.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -930,6 +930,7 @@ 
InitSmmProfileInternal (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
   VOID
   )
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
index 4548467..5cb8d7c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
@@ -1,7 +1,7 @@
 /** @file
 SMM profile header file.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -97,6 +97,7 @@ 
PageFaultIdtHandlerSmmProfile (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
   VOID
   );
--
2.6.3.windows.1

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

[edk2] [PATCH] MdeModulePkg : Fix a bug in BmpImageDecoderLib

[Samer El-Haj-Mahmoud]

Fix a bug in BmpHeader parameter check

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c 
b/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c
index 6445c06..4102de8 100644
--- a/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c
+++ b/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c
@@ -2,6 +2,7 @@
   This library provides BMP image decoding capability.
 
 Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials are licensed and made available 
under
 the terms and conditions of the BSD License that accompanies this distribution.
 The full text of the license may be found at
@@ -105,7 +106,7 @@ BmpImageDecoderLibConvertBmpToGopBlt (
 
   if ((BmpHeader->Size != BmpImageSize) || 
   (BmpHeader->Size < BmpHeader->ImageOffset) ||
-  (BmpHeader->Size - BmpHeader->ImageOffset !=  BmpHeader->PixelHeight * 
DataSizePerLine)) {
+  (BmpHeader->Size - BmpHeader->ImageOffset !=  BmpHeader->ImageSize)) {
 return EFI_INVALID_PARAMETER;
   }
 
-- 
2.6.3.windows.1

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

Re: [edk2] BaseTools build number after transition to git

[Bjorge, Erik C]

> From: Felix Poludov [mailto:fel...@ami.com]
> Sent: Thursday, February 18, 2016 1:11 PM
> To: Bjorge, Erik C ; edk2-devel@lists.01.org
> Subject: RE: BaseTools build number after transition to git
> 
> Eric,
> 
> Using git commit hash or a truncated version of hash, as proposed by
> Laszlo, is mostly fine.
> The only inconvenience of git hashes is that they cannot be compared.
> Unlike SVN revision, it's impossible to tell which commit is newer, by
> just looking at git hash.
> I suggest using git hash plus commit date/time.
> Something similar to the output of the following command:
> git show -s --format="%H %ci" 

I am fine with including the date along with the hash.  I will add that to my 
list of changes.

Thanks,
-Erik

> 
> 
> -Original Message-
> From: Bjorge, Erik C [mailto:erik.c.bjo...@intel.com]
> Sent: Friday, February 12, 2016 6:41 PM
> To: Felix Poludov; edk2-devel@lists.01.org
> Subject: RE: BaseTools build number after transition to git
> 
> Sorry for the late reply.  Currently I am planning to use the SHA1 as
> the version.  This seems like a reasonable approach.
> 
> Thanks,
> -Erik
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Felix Poludov
> > Sent: Wednesday, February 10, 2016 11:09 AM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] BaseTools build number after transition to git
> >
> > Most of the EDKII tools support --version switch that returns tool
> > version and build number.
> > We've been using SVN revision ID as a build number for all the tools.
> > Have there been any discussions on what should be used as a build
> number
> > in the new (and hopefully merrier)  EDKII Git world?
> >
> > Felix
> >
> >
> > The information contained in this message may be confidential and
> > proprietary to American Megatrends, Inc.  This communication is
> intended
> > to be read only by the individual or entity to whom it is addressed or
> > by their designee. If the reader of this message is not the intended
> > recipient, you are on notice that any distribution of this message, in
> > any form, is strictly prohibited.  Please promptly notify the sender
> by
> > reply e-mail or by telephone at 770-246-8600, and then delete or
> destroy
> > all copies of the transmission.
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> The information contained in this message may be confidential and
> proprietary to American Megatrends, Inc.  This communication is intended
> to be read only by the individual or entity to whom it is addressed or
> by their designee. If the reader of this message is not the intended
> recipient, you are on notice that any distribution of this message, in
> any form, is strictly prohibited.  Please promptly notify the sender by
> reply e-mail or by telephone at 770-246-8600, and then delete or destroy
> all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg: Add HttpUtilLib

[Samer El-Haj-Mahmoud]

Add new HttpUtilLib that contains helper functions for HTTP
Request/Response processing.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdeModulePkg/Include/Library/HttpUtilLib.h | 140 ++
 .../Library/DxeHttpUtilLib/DxeHttpUtilLib.c| 525 +
 .../Library/DxeHttpUtilLib/DxeHttpUtilLib.h|  34 ++
 .../Library/DxeHttpUtilLib/DxeHttpUtilLib.inf  |  48 ++
 MdeModulePkg/MdeModulePkg.dec  |   6 +
 5 files changed, 753 insertions(+)
 create mode 100644 MdeModulePkg/Include/Library/HttpUtilLib.h
 create mode 100644 MdeModulePkg/Library/DxeHttpUtilLib/DxeHttpUtilLib.c
 create mode 100644 MdeModulePkg/Library/DxeHttpUtilLib/DxeHttpUtilLib.h
 create mode 100644 MdeModulePkg/Library/DxeHttpUtilLib/DxeHttpUtilLib.inf

diff --git a/MdeModulePkg/Include/Library/HttpUtilLib.h 
b/MdeModulePkg/Include/Library/HttpUtilLib.h
new file mode 100644
index 000..db3166d
--- /dev/null
+++ b/MdeModulePkg/Include/Library/HttpUtilLib.h
@@ -0,0 +1,140 @@
+/** @file
+  Header file for HTTP helper functions for Messages request/responses.
+
+ (C) Copyright 2016 Hewlett Packard Enterprise Development LP
+ Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD 
License
+ which accompanies this distribution.  The full text of the license may be 
found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __HTTP_UTIL_LIB_H__
+#define __HTTP_UTIL_LIB_H__
+
+#include 
+
+///
+/// Local Host IP address
+///
+#define LOCAL_HOST "127.0.0.1"
+
+///
+/// HTTP Request Format Strings
+///
+
+#define HTTP_EOL   "\r\n"
+
+#define HTTP_REQUEST_LINE_FORMAT  "%a %a %a"HTTP_EOL
+
+#define HTTP_HEADER_FIELD_FORMAT  "%a: %a"HTTP_EOL
+
+
+/**
+  Find a specified header field according to the field name.
+
+  @param[in]   HeaderCount  Number of HTTP header structures in Headers 
list.
+  @param[in]   Headers  Array containing list of HTTP headers.
+  @param[in]   FieldNameNull terminated string which describes a field 
name.
+
+  @returnPointer to the found header or NULL.
+
+**/
+EFI_HTTP_HEADER *
+HttpFindHeader (
+  IN  UINTNHeaderCount,
+  IN  EFI_HTTP_HEADER  *Headers,
+  IN  CHAR8*FieldName
+  );
+
+/**
+  Set FieldName and FieldValue into specified HttpHeader.
+
+  @param[in,out]  HttpHeader  Specified HttpHeader.
+  @param[in]  FieldName   FieldName of this HttpHeader, a NULL 
terminated ASCII string.
+  @param[in]  FieldValue  FieldValue of this HttpHeader, a NULL 
terminated ASCII string.
+
+
+  @retval EFI_SUCCESS The FieldName and FieldValue are set into 
HttpHeader successfully.
+  @retval EFI_OUT_OF_RESOURCESFailed to allocate resources.
+
+**/
+EFI_STATUS
+SetFieldNameAndValue (
+   IN  OUT   EFI_HTTP_HEADER   *HttpHeader,
+   IN  CONST CHAR8 *FieldName,
+   IN  CONST CHAR8 *FieldValue
+  );
+
+/**
+  Get one key/value header pair from the raw string.
+
+  @param[in]  String Pointer to the raw string.
+  @param[out] FieldName  Points directly to field name within 
'HttpHeader'.
+  @param[out] FieldValue Points directly to field value within 
'HttpHeader'.
+
+  @return Pointer to the next raw string.
+  @return NULL if no key/value header pair from this raw string.
+
+**/
+CHAR8 *
+GetFieldNameAndValue (
+  IN  CHAR8   *String,
+  OUT CHAR8   **FieldName,
+  OUT CHAR8   **FieldValue
+  );
+
+/**
+  Free existing HeaderFields.
+
+  @param[in]  HeaderFields   Pointer to array of key/value header pairs 
waiting for free.
+  @param[in]  FieldCount The number of header pairs in HeaderFields.
+
+**/
+VOID
+FreeHeaderFields (
+  IN  EFI_HTTP_HEADER  *HeaderFields,
+  IN  UINTNFieldCount
+  );
+
+/**
+  Generate HTTP request string.
+
+  @param[in]   MessagePointer to storage containing HTTP message 
data.
+  @param[in]   UrlThe URL of a remote host.
+  @param[out]  RequestString  Pointer to the created HTTP request string.
+  NULL if any error occured.
+
+  @return EFI_SUCCESS If HTTP request string was created 
successfully
+  @retval EFI_OUT_OF_RESOURCESFailed to allocate resources.
+  @retval EFI_INVALID_PARAMETER   The input arguments are invalid
+
+**/
+EFI_STATUS
+EFIAPI
+HttpGenRequestString (
+  IN  CONST EFI_HTTP_MESSAGE*Message,
+  IN  CONST CHAR8   *Url,
+  OUT CHAR8 **RequestString
+  );
+
+/**
+  Translate the status code in HTTP message to EFI_HTTP_STATUS_CODE 

Re: [edk2] [PATCH] SecurityPkg: Change TPM MMIO range attribute

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Anbazhagan, Baraneedharan
Sent: Friday, February 19, 2016 6:15 AM
To: edk2-devel@lists.01.org
Cc: Zhang, Chao B
Subject: [edk2] [PATCH] SecurityPkg: Change TPM MMIO range attribute

Changes made to TrEE SMM module is not ported to TCG2 SMM module

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Baraneedharan Anbazhagan 
---
SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl 
index 776f43e..37012bd 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
@@ -3,6 +3,7 @@
   and MemoryClear.
 Copyright (c) 2015, Intel Corporation. All rights reserved.
+(c) Copyright 2016 HP Development Company, L.P.
This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -40,7 +41,7 @@ 
DefinitionBlock (
   // Return the resource consumed by TPM device
   //
   Name (_CRS, ResourceTemplate () {
-Memory32Fixed (ReadOnly, 0xfed4, 0x5000)
+Memory32Fixed (ReadWrite, 0xfed4, 0x5000)
   })
   //
--
2.7.1.windows.1

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

Re: [edk2] [PATCH] Ax88772b: Fixing compilation error variable set but not used

[Wu, Jiaxin]

Yes, below set but not used local variable will cause GCC build error. I agree 
this change.


Reviewed-by: Jiaxin Wu >



Thanks.

Jiaxin


From: Shivamurthy Shastri [mailto:shivamurthy.shas...@linaro.org]
Sent: Thursday, February 18, 2016 7:18 PM
To: Leahy, Leroy P ; fr...@asix.com.tw; Wu, Jiaxin 

Cc: edk2-devel@lists.01.org
Subject: Fwd: [edk2] [PATCH] Ax88772b: Fixing compilation error variable set 
but not used

Hi All,

Please let me know your opinion about this patch.

--
Thanks and Regards,
Shivamurthy Shastri,
M: +919742508553, IRC: shiva_murthy,
Linaro.org |Open Source Software for ARM SOCs

-- Forwarded message --
From: Shivamurthy Shastri 
>
Date: 10 February 2016 at 19:37
Subject: [edk2] [PATCH] Ax88772b: Fixing compilation error variable set but not 
used
To: edk2-devel@lists.01.org
Cc: fathi.bou...@linaro.org, Shivamurthy 
Shastri >


error: pNicDevice variable set but not used

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shivamurthy Shastri 
>
---
 OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c 
b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
index 9eeb61f..c061a6b 100644
--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
@@ -700,10 +700,8 @@ SN_ReceiveFilters (
   EFI_SIMPLE_NETWORK_MODE * pMode;
   EFI_STATUS Status = EFI_SUCCESS;
   EFI_TPL TplPrevious;
-  NIC_DEVICE * pNicDevice;

   TplPrevious = gBS->RaiseTPL(TPL_CALLBACK);
-  pNicDevice = DEV_FROM_SIMPLE_NETWORK ( pSimpleNetwork );
   pMode = pSimpleNetwork->Mode;

   if (pSimpleNetwork == NULL) {
--
1.9.1

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

[edk2] [PATCH] MdePkg: Fix incorrect PCIe Extended Capabilities definition

[Samer El-Haj-Mahmoud]

The HeaderLog field of the PCIe Extended Capabilities Advanced Error
Reporting structure was incorrectly defined as a 32-bit field. The PCIe
2.1 Base Specification, section 7.10, lists this as 16 bytes, or 4
DWORDs.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdePkg/Include/IndustryStandard/PciExpress21.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h 
b/MdePkg/Include/IndustryStandard/PciExpress21.h
index a9915e0..57cfab2 100644
--- a/MdePkg/Include/IndustryStandard/PciExpress21.h
+++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
@@ -2,6 +2,7 @@
   Support for the latest PCI standard.
 
   Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP  
   This program and the accompanying materials  
   are licensed and made available under the terms and conditions of the BSD 
License 
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -90,7 +91,7 @@ typedef struct {
   UINT32CorrectableErrorStatus;
   UINT32CorrectableErrorMask;
   UINT32
AdvancedErrorCapabilitiesAndControl;
-  UINT32HeaderLog;
+  UINT32HeaderLog[4];
   UINT32RootErrorCommand;
   UINT32RootErrorStatus;
   UINT16ErrorSourceIdentification;
-- 
2.6.3.windows.1

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

[edk2] [PATCH] MdePkg: Fix CPER GUID definitions to match UEFI spec

[Samer El-Haj-Mahmoud]

Rename gEfiProcessorSpecificErrorSectionGuid to
gEfiIa32X64ErrorSectionGuid and introduce gEfiArmErrorSectionGuid to
match the definition in the UEFI 2.6 specification Table 249.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdePkg/Include/Guid/Cper.h | 13 +++--
 MdePkg/MdePkg.dec  |  5 -
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/Guid/Cper.h b/MdePkg/Include/Guid/Cper.h
index 62493ef..5b3dcef 100644
--- a/MdePkg/Include/Guid/Cper.h
+++ b/MdePkg/Include/Guid/Cper.h
@@ -2,6 +2,7 @@
   GUIDs and definitions used for Common Platform Error Record.
 
   Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved.
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP  
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -23,6 +24,8 @@
 #define EFI_ERROR_RECORD_SIGNATURE_START   SIGNATURE_32('C', 'P', 'E', 'R')
 #define EFI_ERROR_RECORD_SIGNATURE_END 0x
 
+#define EFI_ERROR_RECORD_REVISION  0x0101
+
 ///
 /// Error Severity in Error Record Header and Error Section Descriptor
 ///@{
@@ -137,6 +140,7 @@ typedef struct {
   ///
 } EFI_COMMON_ERROR_RECORD_HEADER;
 
+#define EFI_ERROR_SECTION_REVISION  0x0100
 ///
 /// Validity Fields in Error Section Descriptor.
 ///
@@ -161,10 +165,14 @@ typedef struct {
   { \
 0x9876ccad, 0x47b4, 0x4bdb, { 0xb6, 0x5e, 0x16, 0xf1, 0x93, 0xc4, 0xf3, 
0xdb } \
   }
-#define EFI_ERROR_SECTION_PROCESSOR_SPECIFIC_GUID \
+#define EFI_ERROR_SECTION_PROCESSOR_SPECIFIC_IA32X64_GUID \
   { \
 0xdc3ea0b0, 0xa144, 0x4797, { 0xb9, 0x5b, 0x53, 0xfa, 0x24, 0x2b, 0x6e, 
0x1d } \
   }
+#define EFI_ERROR_SECTION_PROCESSOR_SPECIFIC_ARM_GUID \
+  { \
+0xe19e3d16, 0xbc11, 0x11e4, { 0x9c, 0xaa, 0xc2, 0x05, 0x1d, 0x5d, 0x46, 
0xb0 } \
+  }
 #define EFI_ERROR_SECTION_PLATFORM_MEMORY_GUID \
   { \
 0xa5bc1114, 0x6f64, 0x4ede, { 0xb8, 0x63, 0x3e, 0x83, 0xed, 0x7c, 0x83, 
0xb1 } \
@@ -1177,7 +1185,8 @@ extern EFI_GUID gEfiEventNotificationTypeBootGuid;
 extern EFI_GUID gEfiEventNotificationTypeDmarGuid;
 
 extern EFI_GUID gEfiProcessorGenericErrorSectionGuid;
-extern EFI_GUID gEfiProcessorSpecificErrorSectionGuid;
+extern EFI_GUID gEfiIa32X64ErrorSectionGuid;
+extern EFI_GUID gEfiArmErrorSectionGuid;
 extern EFI_GUID gEfiPlatformMemoryErrorSectionGuid;
 extern EFI_GUID gEfiPlatformMemory2ErrorSectionGuid;
 extern EFI_GUID gEfiPcieErrorSectionGuid;
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index c49f1ce..3c1c8e9 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -6,6 +6,7 @@
 #
 # Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
 # Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
+# (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 #
 # This program and the accompanying materials are licensed and made available 
under
 # the terms and conditions of the BSD License which accompanies this 
distribution.
@@ -427,9 +428,11 @@
   gEfiProcessorGenericErrorSectionGuid  = { 0x9876ccad, 0x47b4, 0x4bdb, { 
0xb6, 0x5e, 0x16, 0xf1, 0x93, 0xc4, 0xf3, 0xdb }}
 
   ## Include/Guid/Cper.h
-  gEfiProcessorSpecificErrorSectionGuid = { 0xdc3ea0b0, 0xa144, 0x4797, { 
0xb9, 0x5b, 0x53, 0xfa, 0x24, 0x2b, 0x6e, 0x1d }}
+  gEfiIa32X64ErrorSectionGuid= { 0xdc3ea0b0, 0xa144, 0x4797, { 0xb9, 
0x5b, 0x53, 0xfa, 0x24, 0x2b, 0x6e, 0x1d }}
 
   ## Include/Guid/Cper.h
+  gEfiArmErrorSectionGuid= { 0xe19e3d16, 0xbc11, 0x11e4, { 0x9c, 
0xaa, 0xc2, 0x05, 0x1d, 0x5d, 0x46, 0xb0 }}
+  ## Include/Guid/Cper.h
   gEfiPlatformMemoryErrorSectionGuid = { 0xa5bc1114, 0x6f64, 0x4ede, { 0xb8, 
0x63, 0x3e, 0x83, 0xed, 0x7c, 0x83, 0xb1 }}
 
   ## Include/Guid/Cper.h
-- 
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] CryptoPkg/OpensslLib: Upgrade OpenSSL version to 1.0.2f

[David Woodhouse]

On Thu, 2016-02-18 at 17:36 +, Long, Qin wrote:
> I think I also need to apologize, that it's my decision to pending
> some part of Dave's patch series posted in last year (with simple
> sync-up with Dave), which includes some changes for include path,
> build process, etc.

I agreed with that then, and in retrospect it looks like the right
decision. It turns out that from 1.0.2e onwards, the symlinks are no
longer present in the include/openssl/ directory of the release
tarballs. So if you had actually merged my patch to use the OpenSSL
include directory, back in the 1.0.2d days, it would have broken with
the update to 1.0.2e.

I've revamped that patch so that we retain Install.sh even on POSIX
platforms. Basically we just copy the files to where OpenSSL normally
has them, instead of copying them to our *own* CryptoPkg/Include/
directory.

I've also rebuilt my OpenSSL_1_0_2-stable branch at
http://git.infradead.org/users/dwmw2/openssl.git with freshly cherry-
picked patches from HEAD... now that fairly much every change we had
*is* committed to OpenSSL HEAD.

My main motivation for doing this right now is because we need to
ensure that OpenSSL 1.1, when it comes out, *does* do everything we
need out of the box.

I won't send another patchbomb to the list right now, but I've updated
the tree at http://git.infradead.org/users/dwmw2/edk2.git

Again, up to and including the 'Automatically configure OpenSSL and
generate file list' patch are applicable even while we stick with
1.0.2. The final two commits need more work (and I'm hoping you follow
through on the discussion about the HMAC APIs), but are mostly useful
for ensuring that OpenSSL HEAD *stays* working as it approaches
release.

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



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

[edk2] [PATCH v2 2/2] NetworkPkg: Use Http11 definitions in HttpDxe and HttpBootDxe

[Samer El-Haj-Mahmoud]

Change HttpDxe and HttpBootDxe to use the standard definitions from
Http11.h instead of private duplicate definitions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 NetworkPkg/HttpBootDxe/HttpBootClient.c |  7 ---
 NetworkPkg/HttpBootDxe/HttpBootClient.h |  4 +---
 NetworkPkg/HttpBootDxe/HttpBootDxe.h|  3 +++
 NetworkPkg/HttpDxe/HttpDriver.h |  2 ++
 NetworkPkg/HttpDxe/HttpImpl.h   | 10 ++
 NetworkPkg/HttpDxe/HttpProto.c  | 16 ++--
 6 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.c 
b/NetworkPkg/HttpBootDxe/HttpBootClient.c
index dd835c4..2ccac8c 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.c
@@ -2,6 +2,7 @@
   Implementation of the boot file download function.
 
 Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials are licensed and made available 
under 
 the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at
@@ -807,7 +808,7 @@ HttpBootGetBootFile (
   }
   Status = HttpBootSetHeader (
  HttpIoHeader,
- HTTP_FIELD_NAME_HOST,
+ HTTP_HEADER_HOST,
  HostName
  );
   FreePool (HostName);
@@ -820,7 +821,7 @@ HttpBootGetBootFile (
   //
   Status = HttpBootSetHeader (
  HttpIoHeader,
- HTTP_FIELD_NAME_ACCEPT,
+ HTTP_HEADER_ACCEPT,
  "*/*"
  );
   if (EFI_ERROR (Status)) {
@@ -832,7 +833,7 @@ HttpBootGetBootFile (
   //
   Status = HttpBootSetHeader (
  HttpIoHeader,
- HTTP_FIELD_NAME_USER_AGENT,
+ HTTP_HEADER_USER_AGENT,
  HTTP_USER_AGENT_EFI_HTTP_BOOT
  );
   if (EFI_ERROR (Status)) {
diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.h 
b/NetworkPkg/HttpBootDxe/HttpBootClient.h
index e618316..b929fa7 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.h
@@ -2,6 +2,7 @@
   Declaration of the boot file download function.
 
 Copyright (c) 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials are licensed and made available 
under 
 the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at
@@ -18,9 +19,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define HTTP_BOOT_REQUEST_TIMEOUT5000  // 5 seconds in uints 
of millisecond.
 #define HTTP_BOOT_BLOCK_SIZE 1500
 
-#define HTTP_FIELD_NAME_USER_AGENT   "User-Agent"
-#define HTTP_FIELD_NAME_HOST "Host"
-#define HTTP_FIELD_NAME_ACCEPT   "Accept"
 
 
 #define HTTP_USER_AGENT_EFI_HTTP_BOOT"UefiHttpBoot/1.0"
diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.h 
b/NetworkPkg/HttpBootDxe/HttpBootDxe.h
index 452c8f4..08f88c5 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDxe.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.h
@@ -2,6 +2,7 @@
   UEFI HTTP boot driver's private data structure and interfaces declaration.
 
 Copyright (c) 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials are licensed and made available 
under 
 the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at
@@ -17,6 +18,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include 
 
+#include 
+
 //
 // Libraries
 //
diff --git a/NetworkPkg/HttpDxe/HttpDriver.h b/NetworkPkg/HttpDxe/HttpDriver.h
index 138f56c..9c0002a 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -2,6 +2,7 @@
   The header files of the driver binding and service binding protocol for 
HttpDxe driver.
 
   Copyright (c) 2015, Intel Corporation. All rights reserved.
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -17,6 +18,7 @@
 #define __EFI_HTTP_DRIVER_H__
 
 #include 
+#include 
 
 //
 // Libraries
diff --git a/NetworkPkg/HttpDxe/HttpImpl.h b/NetworkPkg/HttpDxe/HttpImpl.h
index 3822842..415b5e5 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.h
+++ b/NetworkPkg/HttpDxe/HttpImpl.h
@@ -2,6 +2,7 @@
   The header files of implementation of EFI_HTTP_PROTOCOL protocol interfaces.
 
   Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP  
 
   This program and the 

[edk2] [PATCH v2 1/2] MdePkg: Update Http11 with additional useful definitions

[Samer El-Haj-Mahmoud]

Add additional HTTP 1.1 definitions that are useful in HTTP
applications, such as User-Agent, Location, and x-Auth-Token

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdePkg/Include/IndustryStandard/Http11.h | 54 +---
 1 file changed, 43 insertions(+), 11 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Http11.h 
b/MdePkg/Include/IndustryStandard/Http11.h
index 6c22f94..8a09f96 100644
--- a/MdePkg/Include/IndustryStandard/Http11.h
+++ b/MdePkg/Include/IndustryStandard/Http11.h
@@ -3,7 +3,7 @@
 
   This file contains common HTTP 1.1 definitions from RFC 2616 

-  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -26,7 +26,6 @@
 ///
 #define HTTP_VERSION"HTTP/1.1"
 
-
 ///
 /// HTTP Request Method definitions
 /// 
@@ -43,7 +42,11 @@
 #define HTTP_METHOD_CONNECT "CONNECT"
 #define HTTP_METHOD_PATCH   "PATCH"
 
-#define HTTP_METHOD_MAXIMUM_LEN  sizeof ("CONNECT")
+///
+/// Connect method has maximum length according to EFI_HTTP_METHOD defined in
+/// UEFI2.5 spec so use this.
+///
+#define HTTP_METHOD_MAXIMUM_LEN  sizeof (HTTP_METHOD_CONNECT)
 
 ///
 /// Accept Request Header
@@ -106,7 +109,7 @@
 #define HTTP_CONTENT_ENCODING_GZIP "gzip"  /// Content-Encoding: GNU 
zip format (described in RFC 1952).
 #define HTTP_CONTENT_ENCODING_COMPRESS "compress"  /// encoding format 
produced by the common UNIX file compression program "compress". 
 #define HTTP_CONTENT_ENCODING_DEFLATE  "deflate"   /// The "zlib" format 
defined in RFC 1950 in combination with the "deflate" 
-/// compression mechanism 
described in RFC 1951.
+   /// compression mechanism 
described in RFC 1951.
 
 
 ///
@@ -152,13 +155,37 @@
 
 
 ///
+/// User Agent Request Header
+/// 
+/// The User-Agent request-header field contains information about the user 
agent originating 
+/// the request. This is for statistical purposes, the tracing of protocol 
violations, and 
+/// automated recognition of user agents for the sake of tailoring responses 
to avoid 
+/// particular user agent limitations. User agents SHOULD include this field 
with requests. 
+/// The field can contain multiple product tokens and comments identifying the 
agent and any 
+/// subproducts which form a significant part of the user agent. 
+/// By convention, the product tokens are listed in order of their 
significance for 
+/// identifying the application.
+///
+#define HTTP_HEADER_USER_AGENT "User-Agent"
+
+///
 /// Host Request Header
 ///
 /// The Host request-header field specifies the Internet host and port number 
of the resource 
 /// being requested, as obtained from the original URI given by the user or 
referring resource 
 ///
-#define  HTTP_HEADER_HOST  "Host"
+#define HTTP_HEADER_HOST  "Host"
 
+///
+/// Location Response Header
+/// 
+/// The Location response-header field is used to redirect the recipient to a 
location other than 
+/// the Request-URI for completion of the request or identification of a new 
resource. 
+/// For 201 (Created) responses, the Location is that of the new resource 
which was created by 
+/// the request. For 3xx responses, the location SHOULD indicate the server's 
preferred URI for 
+/// automatic redirection to the resource. The field value consists of a 
single absolute URI.
+///
+#define HTTP_HEADER_LOCATION   "Location"
 
 ///
 /// The If-Match request-header field is used with a method to make it 
conditional.
@@ -170,7 +197,7 @@
 /// to prevent inadvertent modification of the wrong version of a resource. 
 /// As a special case, the value "*" matches any current entity of the 
resource.
 ///
-#define  HTTP_HEADER_IF_MATCH  "If-Match"
+#define HTTP_HEADER_IF_MATCH  "If-Match"
 
 
 ///
@@ -182,7 +209,7 @@
 /// to prevent a method (e.g. PUT) from inadvertently modifying an existing 
resource when the 
 /// client believes that the resource does not exist.
 ///
-#define  HTTP_HEADER_IF_NONE_MATCH "If-None-Match"
+#define HTTP_HEADER_IF_NONE_MATCH "If-None-Match"
 
 
 
@@ -192,17 +219,22 @@
 /// containing the authentication information of the user agent for
 /// the realm of the resource being requested.
 ///
-#define  HTTP_HEADER_AUTHORIZATION "Authorization"
+#define HTTP_HEADER_AUTHORIZATION "Authorization"
 
 ///
 /// ETAG Response Header
 /// The ETag response-header field provides the current value of the entity 
tag 
 /// for the requested variant. 
 ///
-#define  HTTP_HEADER_ETAG  "ETag"
-
-
+#define HTTP_HEADER_ETAG

[edk2] [PATCH] SecurityPkg: Change TPM MMIO range attribute

[Anbazhagan, Baraneedharan]

Changes made to TrEE SMM module is not ported to TCG2 SMM module

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Baraneedharan Anbazhagan 
---
SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
index 776f43e..37012bd 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
@@ -3,6 +3,7 @@
   and MemoryClear.
 Copyright (c) 2015, Intel Corporation. All rights reserved.
+(c) Copyright 2016 HP Development Company, L.P.
This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -40,7 +41,7 @@ DefinitionBlock (
   // Return the resource consumed by TPM device
   //
   Name (_CRS, ResourceTemplate () {
-Memory32Fixed (ReadOnly, 0xfed4, 0x5000)
+Memory32Fixed (ReadWrite, 0xfed4, 0x5000)
   })
   //
--
2.7.1.windows.1

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

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

[Benjamin Herrenschmidt]

On Thu, 2016-02-18 at 18:02 +0100, Laszlo Ersek wrote:
> I briefly skimmed your enormous patch in your github repo -- I see that
> there are several changes to OvmfPkg/QemuVideoDxe. Some of them seem to
> relate directly to the PciIo change (= address translation), while other
> changes in the driver are presumably related to some new feature or
> platform. Assuming the latter kind of change can be easily postponed,
> I'm now only going to ask this:

Right don't worry too much about that giant patch. I'm hoping to find
time some time maybe next month to split it up in small logical units
and rebase to a more recent EDK2.

Cheers,
Ben.

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

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

[Benjamin Herrenschmidt]

On Thu, 2016-02-18 at 18:02 +0100, Laszlo Ersek wrote:
> 
> with Ray's change in the generic PCI bus driver, *must* all PciIo-based
> device drivers be updated? Is this a (bug-)compatible change, or does it
> regress existing drivers (perhaps by triggering their hidden bugs)?

I wouldn't expect existing drivers to break no, as I don't expect them
to look at the AddressTranslation field and it's 0 anyway on existing
platforms.

Of course they have to be updated to work on non-1:1 platforms.

> If this PciIo change has potential to expose bugs or invalid silent
> assumptions in other drivers, then I think the patch should not be
> committed in isolation. It should be part of a series that addresses
> said assumptions in all dependent drivers that are present in the open
> source edk2 tree.

I am not aware of such bugs or silent assumptions. I had the
opportunity to look at a couple of vendor drivers as well and they also
don't seem to make such problematic assumptions either.

> I believe, for QemuVideoDxe, running on
> - qemu-system-(i386|x86_64), i440fx and q35 machine types, or
> - qemu-system-(arm|aarch64), "virt" machine type,
> 
> the translation offset between CPU and device MMIO is, in practice,
> zero, so I guess in practice QemuVideoDxe won't break.
> 
> But, it would be nice to see confirmation (plus in the long term,
> QemuVideoDxe should be updated nonetheless)

I agree but overall I think this is pretty safe.

Cheers,
Ben.

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

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

[Brian J. Johnson]

On 02/17/2016 10:25 PM, Andrew Fish wrote:



On Feb 17, 2016, at 6:50 PM, Dong, Eric  wrote:

Hi All,

Thanks for your comments. I add my explanation below:

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



Eric,

Could you enable your HII exporting callbacks in a ReadyToBoot event? 
Then you wouldn't needlessly pay the export cost each time a HII element 
is added or changed as drivers are loaded.



This feature is described in UEFI spec 2.6 chapter 31.2.11.1. It required to 
export all HiiDatabae data and current configuration data.


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



Agreed.  And section 31.2.1.10 says:

=
When it is desired that the forms data be used in the presence of an 
O/S, this specification describes
a means by which to support this capability. By being able to 
encapsulate the data and export it
through standard means such that an O/S agent (e.g. forms 
browser/processor) can retrieve it, O/S-
present usage models can be made available for further value-add 
implementations.

=

The wording implies that exporting is not always desired, and that 
O/S-present usage of forms data is a value-add feature, which a platform 
may choose to support or not.



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



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

Thanks,

Andrew Fish


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

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

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

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

Thanks,
Eric



My particular concern involves a simulator (far slower than hardware) 
for an extremely large, complex server platform with a large amount of 
HII data.  On this platform, we end up disabling the largest but least 
used setup screens when running on the simulator, simply to avoid the 
time overhead of processing the HII data.  This saves many minutes of 
execution time.



-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
Sent: Wednesday, February 17, 2016 2:14 AM
To: Andrew Fish; Brian J. Johnson
Cc: Bi, Dandan; edk2-devel@lists.01.org; Dong, Eric; Gao, Liming
Subject: RE: [edk2] [patch] MdeModulePkg: Make HII configuration settings 
available to OS runtime

+1

I also would add there may be some HII strings that are hidden from user 
interfaces, and reflect settings for field service or
troubleshooting, and that a mass export to the OS may expose these settings to 
OS runtime code and possibly applications.



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Tuesday, February 16, 2016 10:37 AM
To: Brian J. Johnson 
Cc: Dandan Bi ; edk2-devel@lists.01.org; Eric Dong 
; Liming Gao 
Subject: Re: [edk2] [patch] MdeModulePkg: Make HII configuration settings 
available to OS runtime



On Feb 16, 2016, at 8:33 AM, Brian J. Johnson  wrote:

On 02/16/2016 12:58 AM, Dandan Bi wrote:

This feature is aimed to allow OS make use of the HII database during
runtime. In this case, the contents of the HII Database is exported
to a buffer. The pointer to the buffer is placed in the EFI System
Configuration Table, where it can be retrieved by an OS application.

Export the configuration data and contents of HiiDatabase when driver
add package, update package and remove package.
For string and image may also need to update the contents of
HiiDatabase when NewString/SetString, NewImage/SetImage.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 

Re: [edk2] BaseTools build number after transition to git

[Felix Poludov]

Eric,

Using git commit hash or a truncated version of hash, as proposed by Laszlo, is 
mostly fine.
The only inconvenience of git hashes is that they cannot be compared.
Unlike SVN revision, it's impossible to tell which commit is newer, by  just 
looking at git hash.
I suggest using git hash plus commit date/time.
Something similar to the output of the following command:
git show -s --format="%H %ci" 


-Original Message-
From: Bjorge, Erik C [mailto:erik.c.bjo...@intel.com] 
Sent: Friday, February 12, 2016 6:41 PM
To: Felix Poludov; edk2-devel@lists.01.org
Subject: RE: BaseTools build number after transition to git

Sorry for the late reply.  Currently I am planning to use the SHA1 as the 
version.  This seems like a reasonable approach.

Thanks,
-Erik

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Felix Poludov
> Sent: Wednesday, February 10, 2016 11:09 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] BaseTools build number after transition to git
> 
> Most of the EDKII tools support --version switch that returns tool
> version and build number.
> We've been using SVN revision ID as a build number for all the tools.
> Have there been any discussions on what should be used as a build number
> in the new (and hopefully merrier)  EDKII Git world?
> 
> Felix
> 
> 
> The information contained in this message may be confidential and
> proprietary to American Megatrends, Inc.  This communication is intended
> to be read only by the individual or entity to whom it is addressed or
> by their designee. If the reader of this message is not the intended
> recipient, you are on notice that any distribution of this message, in
> any form, is strictly prohibited.  Please promptly notify the sender by
> reply e-mail or by telephone at 770-246-8600, and then delete or destroy
> all copies of the transmission.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc.  This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] IntelFrameworkModulePkg/Bds: Correct the total RAM calculation

[Jeremy Linton]

Update the BDS frontpage to pull the RAM ranges from the
smbios extended size fields when applicable. The RAM calculation
also needs to take into account all the RAM ranges being provided
as many machines have multiple physical address ranges.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton 
---
 .../Universal/BdsDxe/FrontPage.c   | 45 +++---
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c 
b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
index 0a9238c..451eeac 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
@@ -720,7 +720,6 @@ UpdateFrontPageStrings (
 {
   UINT8 StrIndex;
   CHAR16*NewString;
-  BOOLEAN   Find[5];
   EFI_STATUSStatus;
   EFI_STRING_ID TokenToUpdate;
   EFI_SMBIOS_HANDLE SmbiosHandle;
@@ -730,8 +729,9 @@ UpdateFrontPageStrings (
   SMBIOS_TABLE_TYPE4*Type4Record;
   SMBIOS_TABLE_TYPE19   *Type19Record;
   EFI_SMBIOS_TABLE_HEADER   *Record;
-
-  ZeroMem (Find, sizeof (Find));
+  UINT64InstalledMemory;
+  
+  InstalledMemory=0;
 
   //
   // Update Front Page strings
@@ -743,12 +743,8 @@ UpdateFrontPageStrings (
   );
   if (!EFI_ERROR (Status)) {
 SmbiosHandle = SMBIOS_HANDLE_PI_RESERVED;
-do {
-  Status = Smbios->GetNext (Smbios, , NULL, , NULL);
-  if (EFI_ERROR(Status)) {
-break;
-  }
-
+Status = Smbios->GetNext (Smbios, , NULL, , NULL);
+while (!EFI_ERROR(Status)) {
   if (Record->Type == EFI_SMBIOS_TYPE_BIOS_INFORMATION) {
 Type0Record = (SMBIOS_TABLE_TYPE0 *) Record;
 StrIndex = Type0Record->BiosVersion;
@@ -756,7 +752,6 @@ UpdateFrontPageStrings (
 TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_BIOS_VERSION);
 HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, 
NULL);
 FreePool (NewString);
-Find[0] = TRUE;
   }
 
   if (Record->Type == EFI_SMBIOS_TYPE_SYSTEM_INFORMATION) {
@@ -766,7 +761,6 @@ UpdateFrontPageStrings (
 TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_COMPUTER_MODEL);
 HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, 
NULL);
 FreePool (NewString);
-Find[1] = TRUE;
   }
 
   if (Record->Type == EFI_SMBIOS_TYPE_PROCESSOR_INFORMATION) {
@@ -776,7 +770,6 @@ UpdateFrontPageStrings (
 TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_CPU_MODEL);
 HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, 
NULL);
 FreePool (NewString);
-Find[2] = TRUE;
   }
 
   if (Record->Type == EFI_SMBIOS_TYPE_PROCESSOR_INFORMATION) {
@@ -785,22 +778,30 @@ UpdateFrontPageStrings (
 TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_CPU_SPEED);
 HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, 
NULL);
 FreePool (NewString);
-Find[3] = TRUE;
   }
 
   if ( Record->Type == EFI_SMBIOS_TYPE_MEMORY_ARRAY_MAPPED_ADDRESS ) {
 Type19Record = (SMBIOS_TABLE_TYPE19 *) Record;
-ConvertMemorySizeToString (
-  (UINT32)(RShiftU64((Type19Record->EndingAddress - 
Type19Record->StartingAddress + 1), 10)),
-  
-  );
-TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_MEMORY_SIZE);
-HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, 
NULL);
-FreePool (NewString);
-Find[4] = TRUE;
+if (Type19Record->StartingAddress != 0x ) {
+  InstalledMemory += Type19Record->EndingAddress -
+Type19Record->StartingAddress;
+} else {
+  InstalledMemory += Type19Record->ExtendedEndingAddress -
+  Type19Record->ExtendedStartingAddress;
+}
   }
-} while ( !(Find[0] && Find[1] && Find[2] && Find[3] && Find[4]));
+  
+  Status = Smbios->GetNext (Smbios, , NULL, , NULL);
+}
+
+// now update the total installed RAM size
+InstalledMemory >>= 20; 
+ConvertMemorySizeToString ((UINT32)InstalledMemory,  );
+TokenToUpdate = STRING_TOKEN (STR_FRONT_PAGE_MEMORY_SIZE);
+HiiSetString (gFrontPagePrivate.HiiHandle, TokenToUpdate, NewString, NULL);
+FreePool (NewString);
   }
+
   return ;
 }
 
-- 
2.4.3

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

Re: [edk2] [PATCH v2 3/3] ArmVirtPkg/ArmVirtQemu: limit ACPI support to v5.0 and higher

[Laszlo Ersek]

On 02/18/16 21:16, Ard Biesheuvel wrote:
> On 18 February 2016 at 21:14, Laszlo Ersek  wrote:
>> On 02/18/16 21:03, Ard Biesheuvel wrote:
>>> The ACPI spec predates the AARCH64 architecture by 5 versions, so there
>>> is no point in supporting anything below v5.0. So set the PCD that
>>> controls the ACPI table generation to the appropriate value.
>>>
>>> Note that the current consumers of this PCD only check whether bit 1
>>> is set or not (i.e., ACPI v1.0b), but this may change in the future,
>>> so let's choose a meaningful value right away.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>  ArmVirtPkg/ArmVirtQemu.dsc | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>>> index cece70dd97b9..d0e9a6f7ea33 100644
>>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>>> @@ -174,6 +174,9 @@ [PcdsFixedAtBuild.common]
>>># arm64 or ARM Linux, and enabling it here is pointless.
>>>gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
>>>
>>> +  # we only target OSes that support ACPI v5.0 or later
>>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
>>> +
>>>  [PcdsFixedAtBuild.AARCH64]
>>>gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
>>>
>>>
>>
>> You mention AARCH64 in the commit message, but the PCD is set in the
>> [PcdsFixedAtBuild.common] section, hence it will affect the ARM build
>> too. Is that intentional?
>>
> 
> No, it is not intentional, but ACPI on ARM is non-existent in practice

I wasn't aware of this, so...

> (and I am not even sure if the spec actually covers it). I can move it
> if you like

please move it for the sake of the uninitiated, like me.

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

Re: [edk2] [PATCH v2 3/3] ArmVirtPkg/ArmVirtQemu: limit ACPI support to v5.0 and higher

[Ard Biesheuvel]

On 18 February 2016 at 21:16, Ard Biesheuvel  wrote:
> On 18 February 2016 at 21:14, Laszlo Ersek  wrote:
>> On 02/18/16 21:03, Ard Biesheuvel wrote:
>>> The ACPI spec predates the AARCH64 architecture by 5 versions, so there
>>> is no point in supporting anything below v5.0. So set the PCD that
>>> controls the ACPI table generation to the appropriate value.
>>>
>>> Note that the current consumers of this PCD only check whether bit 1
>>> is set or not (i.e., ACPI v1.0b), but this may change in the future,
>>> so let's choose a meaningful value right away.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>  ArmVirtPkg/ArmVirtQemu.dsc | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>>> index cece70dd97b9..d0e9a6f7ea33 100644
>>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>>> @@ -174,6 +174,9 @@ [PcdsFixedAtBuild.common]
>>># arm64 or ARM Linux, and enabling it here is pointless.
>>>gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
>>>
>>> +  # we only target OSes that support ACPI v5.0 or later
>>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
>>> +
>>>  [PcdsFixedAtBuild.AARCH64]
>>>gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
>>>
>>>
>>
>> You mention AARCH64 in the commit message, but the PCD is set in the
>> [PcdsFixedAtBuild.common] section, hence it will affect the ARM build
>> too. Is that intentional?
>>
>
> No, it is not intentional, but ACPI on ARM is non-existent in practice
> (and I am not even sure if the spec actually covers it). I can move it
> if you like

Actually, I may be quite wrong there. Presumably, Windows on ARM uses
ACPI as well.

I will move it to the AARCH64 section just to be sure
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 3/3] ArmVirtPkg/ArmVirtQemu: limit ACPI support to v5.0 and higher

[Ard Biesheuvel]

On 18 February 2016 at 21:14, Laszlo Ersek  wrote:
> On 02/18/16 21:03, Ard Biesheuvel wrote:
>> The ACPI spec predates the AARCH64 architecture by 5 versions, so there
>> is no point in supporting anything below v5.0. So set the PCD that
>> controls the ACPI table generation to the appropriate value.
>>
>> Note that the current consumers of this PCD only check whether bit 1
>> is set or not (i.e., ACPI v1.0b), but this may change in the future,
>> so let's choose a meaningful value right away.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmVirtPkg/ArmVirtQemu.dsc | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index cece70dd97b9..d0e9a6f7ea33 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -174,6 +174,9 @@ [PcdsFixedAtBuild.common]
>># arm64 or ARM Linux, and enabling it here is pointless.
>>gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
>>
>> +  # we only target OSes that support ACPI v5.0 or later
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
>> +
>>  [PcdsFixedAtBuild.AARCH64]
>>gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
>>
>>
>
> You mention AARCH64 in the commit message, but the PCD is set in the
> [PcdsFixedAtBuild.common] section, hence it will affect the ARM build
> too. Is that intentional?
>

No, it is not intentional, but ACPI on ARM is non-existent in practice
(and I am not even sure if the spec actually covers it). I can move it
if you like
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 3/3] ArmVirtPkg/ArmVirtQemu: limit ACPI support to v5.0 and higher

[Laszlo Ersek]

On 02/18/16 21:03, Ard Biesheuvel wrote:
> The ACPI spec predates the AARCH64 architecture by 5 versions, so there
> is no point in supporting anything below v5.0. So set the PCD that
> controls the ACPI table generation to the appropriate value.
> 
> Note that the current consumers of this PCD only check whether bit 1
> is set or not (i.e., ACPI v1.0b), but this may change in the future,
> so let's choose a meaningful value right away.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirtQemu.dsc | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index cece70dd97b9..d0e9a6f7ea33 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -174,6 +174,9 @@ [PcdsFixedAtBuild.common]
># arm64 or ARM Linux, and enabling it here is pointless.
>gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
>  
> +  # we only target OSes that support ACPI v5.0 or later
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
> +
>  [PcdsFixedAtBuild.AARCH64]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
>  
> 

You mention AARCH64 in the commit message, but the PCD is set in the
[PcdsFixedAtBuild.common] section, hence it will affect the ARM build
too. Is that intentional?

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

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Laszlo Ersek]

On 02/18/16 20:41, Michael Kinney wrote:
> The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE
> in the MP Services Protocol service StartAllAPs().  Any function
> used as an EFI_AP_SERVICE must use EFIAPI calling convention.

I think "EFI_AP_SERVICE" should be "EFI_AP_PROCEDURE" here.

> 
> Cc: Jeff Fan 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 3 ++-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)

EFI_AP_PROCEDURE is defined, in "MdePkg/Include/Pi/PiMultiPhase.h", as:

typedef
VOID
(EFIAPI *EFI_AP_PROCEDURE)(
  IN OUT VOID  *Buffer
  );

Let's compare the prototype of CheckFeatureSupported()
[UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h]:

VOID
CheckFeatureSupported (
  VOID
  );

The lack of EFIAPI is just one (I'd say: the smaller) problem; the
parameter list is incorrect regardless of calling convention. Therefore:

> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> index ec4ec9b..0279f89 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> @@ -1,7 +1,7 @@
>  /** @file
>  Enable SMM profile.
>  
> -Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD 
> License
>  which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -930,6 +930,7 @@ InitSmmProfileInternal (
>  
>  **/
>  VOID
> +EFIAPI
>  CheckFeatureSupported (
>VOID
>)

Here I propose to fix up the parameter list as well,


> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> index 4548467..5cb8d7c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
> @@ -1,7 +1,7 @@
>  /** @file
>  SMM profile header file.
>  
> -Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD 
> License
>  which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -97,6 +97,7 @@ PageFaultIdtHandlerSmmProfile (
>  
>  **/
>  VOID
> +EFIAPI
>  CheckFeatureSupported (
>VOID
>);
> 

here too; *plus* drop the (now unnecessary) cast from:

MpServices->StartupAllAPs (
  MpServices,
  (EFI_AP_PROCEDURE) CheckFeatureSupported,
  TRUE,
  NULL,
  0,
  NULL,
  NULL
  );

in CheckProcessorFeature().

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

[edk2] [PATCH v2 0/3] lift AARCH64 ACPI 4GB allocation restriction

[Ard Biesheuvel]

On AARCH64, there is no requirement to support OSes that can only access
ACPI tables in low memory (i.e., below 4 GB), and there are reasons to
prefer allocations higher up. First of all, so DMA capable devices may
only be able to access 32-bit addressable memory. Additionally, keeping
memory reservations close together makes it easier for the OS to map
system RAM efficiently (with as few levels of translation as possible)

So introduce a PCD that inhibits the generation of ACPI tables that require
them to be allocated in memory below 4 GB, and wire it up to the allocation
of performance data memory as well. Finally, set the PCD for ArmVirtQemu.

Ard Biesheuvel (3):
  MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional
  IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB on ACPI 1.0
  ArmVirtPkg/ArmVirtQemu: limit ACPI support to v5.0 and higher

 ArmVirtPkg/ArmVirtQemu.dsc   |   3 +
 IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf  |   1 +
 IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c  |  11 +-
 MdeModulePkg/MdeModulePkg.dec|  11 +
 MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   2 +
 MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 448 

 6 files changed, 289 insertions(+), 187 deletions(-)

-- 
2.5.0

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

[edk2] [PATCH v2 3/3] ArmVirtPkg/ArmVirtQemu: limit ACPI support to v5.0 and higher

[Ard Biesheuvel]

The ACPI spec predates the AARCH64 architecture by 5 versions, so there
is no point in supporting anything below v5.0. So set the PCD that
controls the ACPI table generation to the appropriate value.

Note that the current consumers of this PCD only check whether bit 1
is set or not (i.e., ACPI v1.0b), but this may change in the future,
so let's choose a meaningful value right away.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirtQemu.dsc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index cece70dd97b9..d0e9a6f7ea33 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -174,6 +174,9 @@ [PcdsFixedAtBuild.common]
   # arm64 or ARM Linux, and enabling it here is pointless.
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
 
+  # we only target OSes that support ACPI v5.0 or later
+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
+
 [PcdsFixedAtBuild.AARCH64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
 
-- 
2.5.0

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

[edk2] [PATCH v2 2/3] IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB on ACPI 1.0

[Ard Biesheuvel]

It is not entirely clear from the code why, but the reserved region
for storing performance data is allocated below 4 GB, and the variable
to hold the address of the allocation is called 'AcpiLowMemoryBase'
(which is the only mention of ACPI in the entire file).

Let's make this allocation dependent on PcdAcpiExposedTableVersions as
well, since systems that can deal with ACPI table in high memory are
also just as likely to be able to deal with performance data in high
memory. This prevents memory fragmentation on systems that don't care
about the 4 GB limit.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf |  1 +
 IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c | 11 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf 
b/IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
index 6afb8a09df9c..38172780fb49 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
@@ -215,6 +215,7 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution
## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution  
## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdErrorCodeSetVariable  
## CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions  
## CONSUMES
 
 [Depex]
   TRUE
diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c 
b/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c
index ae7ad2153c51..bf5bd6524a90 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -22,6 +22,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include "Hotkey.h"
 #include "HwErrRecSupport.h"
 
+#include 
+
 ///
 /// BDS arch protocol instance initial value.
 ///
@@ -474,14 +476,21 @@ BdsAllocateMemoryForPerformanceData (
   EFI_STATUSStatus;
   EFI_PHYSICAL_ADDRESS  AcpiLowMemoryBase;
   EDKII_VARIABLE_LOCK_PROTOCOL  *VariableLock;
+  EFI_ALLOCATE_TYPE AcpiTableAllocType;
 
   AcpiLowMemoryBase = 0x0ULL;
 
+  if ((PcdGet32 (PcdAcpiExposedTableVersions) & EFI_ACPI_TABLE_VERSION_1_0B) 
!= 0) {
+AcpiTableAllocType = AllocateMaxAddress;
+  } else {
+AcpiTableAllocType = AllocateAnyPages;
+  }
+
   //
   // Allocate a block of memory that will contain performance data to OS.
   //
   Status = gBS->AllocatePages (
-  AllocateMaxAddress,
+  AcpiTableAllocType,
   EfiReservedMemoryType,
   EFI_SIZE_TO_PAGES (PERF_DATA_MAX_LENGTH),
   
-- 
2.5.0

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

[edk2] [PATCH v2 1/3] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

[Ard Biesheuvel]

AARCH64 systems never require compatibility with legacy ACPI OSes, and
may not have any 32-bit addressable system RAM. To support ACPI on these
systems, we need to be able to relax the 4 GB allocation restriction.
Since systems that do have 32-bit addressable RAM may prefer to reserve it
for DMA buffer for 32-bit peripherals, and since it is generally preferred
to keep firmware reserved regions close together (to reduce memory
fragmentation affecting TLB footprint), we should not fall back to high
allocations only if low allocations fail.

So add a PCD PcdAcpiExposedTableVersions containing a bitmask describing
which ACPI versions are targeted, and wire it up it up to the memory
allocation calls in AcpiTableDxe/AcpiTableProtocol.c. I.e., if ACPI v1.0b
is not among the supported versions, the memory allocations are not limited
to 4 GB, and only table types that carry 64-bit addresses are emitted.

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

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

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

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 5c5a9ee13138..febfc7d28046 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -4,6 +4,7 @@
 # and libraries instances, which are used for those modules.
 #
 # Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
+# Copyright (c) 2016, Linaro Ltd. All rights reserved.
 # This program and the accompanying materials are licensed and made available 
under
 # the terms and conditions of the BSD License that accompanies this 
distribution.
 # The full text of the license may be found at
@@ -1049,6 +1050,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
   # @Prompt Driver guid array of VFR drivers for VarCheckHiiBin generation.
   gEfiMdeModulePkgTokenSpaceGuid.PcdVarCheckVfrDriverGuidArray|{ 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00 }|VOID*|0x3000103A
 
+  ## Indicates which ACPI versions are targeted by the ACPI tables exposed to 
the OS
+  #  These values are aligned with the definitions in 
MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
+  #   BIT 1 - EFI_ACPI_TABLE_VERSION_1_0B.
+  #   BIT 2 - EFI_ACPI_TABLE_VERSION_2_0.
+  #   BIT 3 - EFI_ACPI_TABLE_VERSION_3_0.
+  #   BIT 4 - EFI_ACPI_TABLE_VERSION_4_0.
+  #   BIT 5 - EFI_ACPI_TABLE_VERSION_5_0.
+  # @Prompt Exposed ACPI table versions.
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x3E|UINT32|0x0001004c
+
 [PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
   ## This PCD defines the Console output row. The default value is 25 
according to UEFI spec.
   #  This PCD could be set to 0 then console output would be at max column and 
max row.
diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf 
b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
index e9cd728dbfb6..0fb2c9cfb52e 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
@@ -2,6 +2,7 @@
 #  ACPI Table Protocol Driver
 #
 #  Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+#  Copyright (c) 2016, Linaro Ltd. All rights reserved.
 #  This program and the accompanying materials are
 #  licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
@@ -67,6 +68,7 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultOemRevision  ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision  ## CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions## CONSUMES
 
 [Protocols]
   gEfiAcpiTableProtocolGuid ## PRODUCES
diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c 
b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
index c6abf1bf0c52..cadc4f0daccb 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
+++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
@@ -2,6 +2,7 @@
   ACPI Table Protocol Implementation
 
   Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2016, Linaro Ltd. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -21,6 +22,12 @@

[edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to CheckFeatureSupported()

[Michael Kinney]

The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE
in the MP Services Protocol service StartAllAPs().  Any function
used as an EFI_AP_SERVICE must use EFIAPI calling convention.

Cc: Jeff Fan 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 3 ++-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index ec4ec9b..0279f89 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1,7 +1,7 @@
 /** @file
 Enable SMM profile.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -930,6 +930,7 @@ InitSmmProfileInternal (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
   VOID
   )
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
index 4548467..5cb8d7c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h
@@ -1,7 +1,7 @@
 /** @file
 SMM profile header file.
 
-Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -97,6 +97,7 @@ PageFaultIdtHandlerSmmProfile (
 
 **/
 VOID
+EFIAPI
 CheckFeatureSupported (
   VOID
   );
-- 
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 0/7] Add UEFI2.6 MemoryAttributesTable support.

[Ard Biesheuvel]

On 14 February 2016 at 06:44, Yao, Jiewen  wrote:
> HI
> Thanks to discuss this properties table issue.
> The purpose of this patch is to *add* UEFI2.6 memory attributes table. This 
> patch does not handle any UEFI2.5 properties table.
> If we want to change EDKII code for properties table, I suggest we separate 
> it from this patch.
>
> Is there any comment for adding UEFI2.6 memory attributes table?
>

I am running into a problem with these patches. According to the spec,
each entry in the Memory Attributes table shall have the same type as
the region it was carved out of in the UEFI memory map. However, when
I dump the table from Linux, it looks something like

UEFI memory map:
  0x00013c0e-0x00013c15 [Runtime Code   |RUN|  |  |  |  |  ]

  0x00013c16-0x00013c17 [Runtime Data   |RUN|  |  |  |  |  ]

  0x00013c1a-0x00013c1d [Runtime Code   |RUN|  |  |  |  |  ]

  0x00013c1e-0x00013c27 [Runtime Data   |RUN|  |  |  |  |  ]

  0x00013c28-0x00013c2c [Runtime Code   |RUN|  |  |  |  |  ]

  0x00013c2d-0x00013c31 [Runtime Data   |RUN|  |  |  |  |  ]

  0x00013c32-0x00013c36 [Runtime Code   |RUN|  |  |  |  |  ]

  0x00013f65-0x00013f6d [Runtime Code   |RUN|  |  |  |  |  ]

  0x00013f6f-0x00013f80 [Runtime Data   |RUN|  |  |  |  |  ]


Memory Attributes Table:
  0x00013c0e-0x00013c0e [Runtime Data   |RUN|  |XP|  |  |  ]
  0x00013c0f-0x00013c0f [Runtime Code   |RUN|  |  |  |  |RO]
  0x00013c10-0x00013c12 [Runtime Data   |RUN|  |XP|  |  |  ]
  0x00013c13-0x00013c13 [Runtime Code   |RUN|  |  |  |  |RO]
  0x00013c14-0x00013c15 [Runtime Data   |RUN|  |XP|  |  |  ]

  0x00013c16-0x00013c17 [Runtime Data   |RUN|  |XP|  |  |  ]

  0x00013c1a-0x00013c1a [Runtime Data   |RUN|  |XP|  |  |  ]
  0x00013c1b-0x00013c1b [Runtime Code   |RUN|  |  |  |  |RO]
  0x00013c1c-0x00013c1d [Runtime Data   |RUN|  |XP|  |  |  ]

  0x00013c1e-0x00013c27 [Runtime Data   |RUN|  |XP|  |  |  ]

  0x00013c28-0x00013c28 [Runtime Data   |RUN|  |XP|  |  |  ]
  0x00013c29-0x00013c29 [Runtime Code   |RUN|  |  |  |  |RO]
  0x00013c2a-0x00013c2c [Runtime Data   |RUN|  |XP|  |  |  ]

  0x00013c2d-0x00013c31 [Runtime Data   |RUN|  |XP|  |  |  ]

  0x00013c32-0x00013c32 [Runtime Data   |RUN|  |XP|  |  |  ]
  0x00013c33-0x00013c33 [Runtime Code   |RUN|  |  |  |  |RO]
  0x00013c34-0x00013c36 [Runtime Data   |RUN|  |XP|  |  |  ]

  0x00013f65-0x00013f65 [Runtime Data   |RUN|  |XP|  |  |  ]
  0x00013f66-0x00013f66 [Runtime Code   |RUN|  |  |  |  |RO]
  0x00013f67-0x00013f69 [Runtime Data   |RUN|  |XP|  |  |  ]
  0x00013f6a-0x00013f6a [Runtime Code   |RUN|  |  |  |  |RO]
  0x00013f6b-0x00013f6d [Runtime Data   |RUN|  |XP|  |  |  ]

  0x00013f6f-0x00013f80 [Runtime Data   |RUN|  |XP|  |  |  ]

So what you see here is that the entry types in the Memory Attribute
table are set according to the RO/XP attribute, and not according to
the original region in the UEFI memory map.
In other words, what I would expect here is that the first five
entries are all 'Runtime Code', with the same permissions as are
listed currently.

Literally, the spec describes this requirement as follows:
"""
Irrespective of the memory protections implied by Attribute, the
EFI_MEMORY_DESCRIPTOR.Type field should match the type of the memory
in enclosing SetMemoryMap() entry.
"""



>
> For UEFI2.5 properties table, let me summarize. Currently, we have several 
> options:
> 0) Keep it as is. Current setting is PcdPropertiesTableEnable TRUE in 
> MdeModulePkg.DEC.
> 1) Update PcdPropertiesTableEnable to FALSE in XXXPlatform.DSC file. 
> (Platform choice. It can be static PCD or dynamic PCD.)
> 2) Update PcdPropertiesTableEnable to FALSE in MdeModulePkg.DEC file. 
> (Disable Default. BIOS will not publish this table by default. If platform 
> wants this table, it can set PCD to true.)
> 3) Remove PcdPropertiesTableEnable, and remove PropertiesTable support code 
> in DxeCore. (PropertiesTable support is removed.)
>
> Personally, I do not suggest we choose 3), because this table is still 
> defined in UEFI specification. We can remove it after UEFI spec removes it 
> later.
> I do not have strong opinion for other options.
>
> Thank you
> Yao Jiewen
>
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, February 01, 2016 2:28 PM
> To: Laszlo Ersek
> Cc: Yao, Jiewen; edk2-de...@ml01.01.org; Gao, Liming
> Subject: Re: [edk2] [patch 0/7] Add UEFI2.6 MemoryAttributesTable support.
>
> On 31 January 2016 at 21:36, Laszlo Ersek  wrote:
>> On 01/30/16 11:25, Ard Biesheuvel wrote:
>>> On 30 January 2016 at 04:17, Yao, Jiewen  wrote:
 Thanks for the clarification. I think you are right.

 I said "This table is used to retire old 

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

[Long, Qin]

Wow, I just noticed these were so many discussion against this, with so many 
tech scopes. :-), Thanks for them, Dave & Laszlo.
I think I also need to apologize, that it's my decision to pending some part of 
Dave's patch series posted in last year (with simple sync-up with Dave), which 
includes some changes for include path, build process, etc. My original plan is 
to have one overall updates based on 1.1 formal release (which should be 
scheduled at the end of April, 2016), since we still cannot remove all patches 
under 1.0.x branch. 

Looks it is really better and valuable to bring them earlier. I may fasten this 
validation and integration. 
This simple 1.0.2f upgrade may still be handled firstly to align some 
requirement, after double-checking those hunk issues.  

Thanks again for Dave to bridge EDKII and OpenSSL dev team to make all those 
RTs happened.  And leave me in the rooms. :-)


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Friday, February 19, 2016 1:08 AM
> To: David Woodhouse ; Long, Qin 
> Cc: Ye, Ting ; edk2-de...@ml01.01.org
> Subject: Re: [edk2] [Patch] CryptoPkg/OpensslLib: Upgrade OpenSSL version to 
> 1.0.2f
> 
> On 02/18/16 16:45, David Woodhouse wrote:
> > On Thu, 2016-02-18 at 14:27 +, David Woodhouse wrote:
> >> On Thu, 2016-02-18 at 14:58 +0100, Laszlo Ersek wrote:
> >>>
> >>> Then I gave my R-b to this patch, admitting that I couldn't verify the
> >>> edk2-only customizations against the 1.0.2f release.
> >>>
> >>> Turns out those customizations are indeed no longer correct, so my R-b
> >>> was in error.
> >>
> >> Er, aren't they? Are you referring to my comment about the RT#3955 fix?
> >>
> >> That isn't actually *less* correct than it ever was.
> >
> > And, embarrassingly, it looks like OpenSSL 1.1 has a fix which looks
> > much more like the one in EDKII_openssl-1.0.2f.patch, than the one in
> > my own tree.
> >
> > Is there room for me to come and crawl under that rock *with* you...?
> >
> 
> I pretty much made myself convenient and used up all the room here, in
> my shame. If you want to join me, you're going to have to transgress way
> harder than this! ;)
> 
> I'll be in my bunk ^W^W^W under my rock.
> 
> 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] CryptoPkg/OpensslLib: Upgrade OpenSSL version to 1.0.2f

[Laszlo Ersek]

On 02/18/16 16:45, David Woodhouse wrote:
> On Thu, 2016-02-18 at 14:27 +, David Woodhouse wrote:
>> On Thu, 2016-02-18 at 14:58 +0100, Laszlo Ersek wrote:
>>>  
>>> Then I gave my R-b to this patch, admitting that I couldn't verify the
>>> edk2-only customizations against the 1.0.2f release.
>>>  
>>> Turns out those customizations are indeed no longer correct, so my R-b
>>> was in error.
>>
>> Er, aren't they? Are you referring to my comment about the RT#3955 fix?
>>
>> That isn't actually *less* correct than it ever was.
> 
> And, embarrassingly, it looks like OpenSSL 1.1 has a fix which looks
> much more like the one in EDKII_openssl-1.0.2f.patch, than the one in
> my own tree.
> 
> Is there room for me to come and crawl under that rock *with* you...?
> 

I pretty much made myself convenient and used up all the room here, in
my shame. If you want to join me, you're going to have to transgress way
harder than this! ;)

I'll be in my bunk ^W^W^W under my rock.

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

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

[Laszlo Ersek]

On 02/18/16 15:27, David Woodhouse wrote:
> On Thu, 2016-02-18 at 14:58 +0100, Laszlo Ersek wrote:
>>
>> Then I gave my R-b to this patch, admitting that I couldn't verify the
>> edk2-only customizations against the 1.0.2f release.
>>
>> Turns out those customizations are indeed no longer correct, so my R-b
>> was in error.
> 
> Er, aren't they? Are you referring to my comment about the RT#3955 fix?

Yes, I am.

> That isn't actually *less* correct than it ever was.

Sigh. You just proved my point. I can't even participate in a discussion
about this module without getting confused / misunderstanding comments.

Honestly, I'm not following OpenSSL development, and I don't think I'll
find the cycles for it. I'll let you guys sort this out.

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

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

[Laszlo Ersek]

On 02/18/16 15:18, Benjamin Herrenschmidt wrote:
> On Thu, 2016-02-18 at 06:55 +, Ni, Ruiyu wrote:
>> Ben,
>> I just had a look at your changes. Nice feeling that our codes are
>> quite similar, except yours are in a separate function.
>> I thought about separating it to a sub function but later didn't do
>> that because this sub function is only called once
>> and the logic after all is quite simple:)
> 
> The logic is simple yes but I dislike large functions, I find it makes
> the overall code flow harder to follow ;-) Just a matter of personal
> taste.
> 
>> Can you give a rb for this patch? or you think a sub function is
>> better? I can make that change if you insist.
> 
> I'd prefer testing before rb'ing but I won't be able to do that for a
> couple of weeks at least (travelling). Did you manage to find a
> platform to test your changes ? I'll give it a closer look tomorrow and
> send a rb based on pure code review. (Ping me if I forget).

I briefly skimmed your enormous patch in your github repo -- I see that
there are several changes to OvmfPkg/QemuVideoDxe. Some of them seem to
relate directly to the PciIo change (= address translation), while other
changes in the driver are presumably related to some new feature or
platform. Assuming the latter kind of change can be easily postponed,
I'm now only going to ask this:

with Ray's change in the generic PCI bus driver, *must* all PciIo-based
device drivers be updated? Is this a (bug-)compatible change, or does it
regress existing drivers (perhaps by triggering their hidden bugs)?

If this PciIo change has potential to expose bugs or invalid silent
assumptions in other drivers, then I think the patch should not be
committed in isolation. It should be part of a series that addresses
said assumptions in all dependent drivers that are present in the open
source edk2 tree.

I believe, for QemuVideoDxe, running on
- qemu-system-(i386|x86_64), i440fx and q35 machine types, or
- qemu-system-(arm|aarch64), "virt" machine type,

the translation offset between CPU and device MMIO is, in practice,
zero, so I guess in practice QemuVideoDxe won't break.

But, it would be nice to see confirmation (plus in the long term,
QemuVideoDxe should be updated nonetheless).

Thanks
Laszlo

> 
> Cheers,
> Ben.
> 
>> Regards,
>> Ray
>>
>> -Original Message-
>> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] 
>> Sent: Thursday, February 18, 2016 11:21 AM
>> To: Ni, Ruiyu ; edk2-de...@ml01.01.org
>> Cc: Andrew Fish ; Fan, Jeff 
>> Subject: Re: [Patch 2/2] MdeModuelPkg/PciBus: Return
>> AddrTranslationOffset in GetBarAttributes
>>
>> On Thu, 2016-02-18 at 10:33 +0800, Ruiyu Ni wrote:
>>> Some platform doesn't use CPU(HOST)/Device 1:1 mapping for PCI Bus.
>>> But PCI IO doesn't have interface to tell caller (device driver)
>>> whether the address returned by GetBarAttributes() is HOST address
>>> or device address.
>>> UEFI Spec 2.6 addresses this issue by clarifying the address
>>> returned
>>> is HOST address and caller can use AddrTranslationOffset to
>>> calculate
>>> the device address.
>>
>> Hi !
>>
>> I had implemented that a bit differently mostly for code clarity
>> (see below pasted from github)
>>
>> Ie, make it a sub function. Otherwise I think the principle is ok.
>>
>> Note that I haven't been able to work on my EDK2 port for a while now
>> due to other commitments. I will eventually get back to it and test
>> your patch.
>>
>> You can browse my monster-patch on github, I need to split/clean it
>> into a proper patch series, it also contains some updates of a couple
>> of drivers to actually use that offset properly
>>
>> https://github.com/ozbenh/edk2/commits/master
>>
>>  +  Finds the root bridge resource corresponding to the BAR whose
>> address
>>  +  space descritpor is passes as an argument and copy the
>> translation offset
>>  +  over from it into the BAR descriptor
>>  +
>>  +  @param  RootBridgeA pointer to the
>> EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL instance.
>>  +  @param  BarAddressSpace   A pointer to the ACPI 2.0 resource
>> descriptors that describe the current
>>  +configuration of this BAR of the
>> PCI controller that is to be updated.
>>  +
>>  +  @retval EFI_SUCCESS   The descriptor was successfully
>> updated.
>>  +  @retval EFI_UNSUPPORTED   No resource in the root bridge
>> matches the BAR region
>>  +  @retval EFI_OUT_OF_RESOURCES  There are not enough resources
>> available to allocate
>>  +Resources.
>>  +
>>  +**/
>>  +STATIC
>>  +EFI_STATUS
>>  +PciBarUpdateTranslationOffset(
>>  +  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL   *RootBridge,
>>  +  IN OUT EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *BarAddressSpace)
>>  +{
>>  +  EFI_STATUS Status;
>>  +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  *RootDescriptors;
>>  +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  *Desc;
>>  +  

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

[Laszlo Ersek]

On 02/18/16 15:20, Yao, Jiewen wrote:
> Hi
> Thanks to bring this 4G issue again. I have several thought for your 
> consideration.
> 
> 1) At 12/16/2015, Samer El-Haj-Mahmoud  
> submitted a patch:
> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get 
> installed above 4GB
> 
> Some ARM systems do not have available memory below 4GB, and still support 
> ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
> below 4GB fails.
> 
> I have given comments that:
> -- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.
> 
> -- Can we create a new function to allocate <4G at first, if fail, allocate 
> any memory?
> Then we can update all caller to consume this new function.
> We can avoid adding ERROR check anywhere. I also suggest we need add some 
> debug message there, we can add into one place.
> 
> It is just another option to resolve ARM issue. Currently, we only add PCD 
> when necessary, because we got complain that we defined too many PCDs. 
> If there is a way to avoid introducing a new one. It worth considering.

I agree it's a good idea to consider solutions that avoid adding new PCDs.

... Ard mentioned that in some cases, even if it's possible to allocate
under 4GB, it is detrimental to performance. (Please see the first link
below for more information.) So "always start low" is probably not a
bullet-proof strategy.

> 2) I believe 4G table issue not only exist in ACPI table, but also exist in 
> others. For example, Smbios table.
> SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G 
> limitation.
> 
> I know ACPI table and SMBIOS table are different. Some platforms care only 
> one of them.
> Personally, I hope we can have a consistent way to resolve this generic 4G 
> issue.
> 
> I have seems SMBIOS table is using the way Samer submitted in last year. 
> (Allocate <4G at first, if fail, allocate at any place)
> Do you see any limitation on this algorithm?

The universal SMBIOS driver already allows the platform to control this
through an existent PCD. Please see these patches / comments:

http://thread.gmane.org/gmane.comp.bios.edk2.devel/7752
http://thread.gmane.org/gmane.comp.bios.edk2.devel/7759

> I am not insist on some solutions. I just want to bring the other way for 
> discussion.

One important difference I see between SMBIOS and ACPI is the following
(and please correct me if I'm wrong): it seems that the 32-bit vs.
64-bit entry points for SMBIOS are distinguished not only by the SMBIOS
spec(s), but also by UEFI itself -- they are associated with different
GUIDs in the system config table.

Whereas for ACPI, the same GUID is usable by platforms independently of
whether they will expose RSDT or XSDT. I feel that these cases should be
sharply distinguished from each other on the UEFI spec level -- maybe
not with different GUIDs (for the RSDP), but with a new interface or
protocol version that explicitly allows for more control from the platform.

Thanks
Laszlo

> BTW: I am not clear on memory map on >4G ARM platform. Can someone help me 
> understand where is runtime code/runtime data/ACPI NVS/Reserved memory? >4G 
> or <4G?
> 
> Thank you
> Yao Jiewen

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

Re: [edk2] [PATCH] Ax88772b: support for multiple dongles and chips

[Shivamurthy Shastri]

Adding Ruiyu Ni

--

Thanks and Regards,

Shivamurthy Shastri,

M: +919742508553, IRC: shivamurthy,
*Linaro.org* |Open Source Software for ARM SOCs


On 18 February 2016 at 16:50, Shivamurthy Shastri <
shivamurthy.shas...@linaro.org> wrote:

> Hi All,
>
> Please let me know your opinion about this patch.
>
> --
>
> Thanks and Regards,
>
> Shivamurthy Shastri,
>
> M: +919742508553, IRC: shiva_murthy,
> *Linaro.org* |Open Source Software for ARM SOCs
>
>
> -- Forwarded message --
> From: Shivamurthy Shastri 
> Date: 10 February 2016 at 19:40
> Subject: [edk2] [PATCH] Ax88772b: support for multiple dongles and chips
> To: edk2-devel@lists.01.org
> Cc: fathi.bou...@linaro.org, Shivamurthy Shastri <
> shivamurthy.shas...@linaro.org>
>
>
> Driver code is modified to support multiple ethernet dongles, which uses
> similar ASIX chips. Also, it can be used for multiple ASIX chips with
> similar register map.
>
> Enabled support for Apple Ethernet Adapter
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shivamurthy Shastri 
> ---
>  .../Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h   | 13 -
>  .../Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c | 33
> +-
>  2 files changed, 32 insertions(+), 14 deletions(-)
>
> diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
> b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
> index ab75ec2..816f2b2 100644
> --- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
> +++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
> @@ -297,12 +297,23 @@
>  #define AN_10_HDX   0x0020  ///<  1 = 10BASE-T support
>  #define AN_CSMA_CD  0x0001  ///<  1 = IEEE 802.3
> CSMA/CD support
>
> -
> +/* asix_flags defines */
> +#define FLAG_NONE   0
> +#define FLAG_TYPE_AX88172   (1U << 0)
> +#define FLAG_TYPE_AX88772   (1U << 1)
> +#define FLAG_TYPE_AX88772B  (1U << 2)
> +#define FLAG_EEPROM_MAC (1U << 3) /* initial mac address in
> eeprom */
>
>
>  
> //--
>  //  Data Types
>
>  
> //--
>
> +struct ASIX_DONGLE {
> +   UINT16  VendorId;
> +   UINT16  ProductId;
> +   INT32   Flags;
> +};
> +
>  /**
>Ethernet header layout
>
> diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
> b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
> index 3b73040..6a10cbf 100644
> --- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
> +++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
> @@ -14,6 +14,13 @@
>
>  #include "Ax88772.h"
>
> +struct ASIX_DONGLE ASIX_DONGLES[] = {
> +{ 0x05AC, 0x1402, FLAG_TYPE_AX88772 }, /* Apple USB Ethernet
> Adapter */
> +/* ASIX 88772B */
> +{ 0x0B95, 0x772B, FLAG_TYPE_AX88772B | FLAG_EEPROM_MAC },
> +{ 0x, 0x, FLAG_NONE }   /* END - Do not remove */
> +};
> +
>  /**
>Verify the controller type
>
> @@ -36,6 +43,8 @@ DriverSupported (
>EFI_USB_DEVICE_DESCRIPTOR Device;
>EFI_USB_IO_PROTOCOL * pUsbIo;
>EFI_STATUS Status;
> +  UINT32 i;
> +
>//
>//  Connect to the USB stack
>//
> @@ -60,19 +69,17 @@ DriverSupported (
>  else {
>//
>//  Validate the adapter
> -  //
> -  if ( VENDOR_ID == Device.IdVendor ) {
> -
> -if (PRODUCT_ID == Device.IdProduct) {
> -DEBUG ((EFI_D_INFO, "Found the AX88772B\r\n"));
> -}
> -   else  {
> -Status = EFI_UNSUPPORTED;
> -   }
> -  }
> -   else {
> - Status = EFI_UNSUPPORTED;
> -   }
> +  //
> +  for (i = 0; ASIX_DONGLES[i].VendorId != 0; i++) {
> +   if (ASIX_DONGLES[i].VendorId == Device.IdVendor &&
> +   ASIX_DONGLES[i].ProductId == Device.IdProduct) {
> + DEBUG ((EFI_D_INFO, "Found the AX88772B\r\n"));
> + break;
> +   }
> +   }
> +
> +   if (ASIX_DONGLES[i].VendorId == 0)
> +   Status = EFI_UNSUPPORTED;
>  }
>
>  //
> --
> 1.9.1
>
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Increase reallocation size for temp memory files

[Carsey, Jaben]

That sounds good to me.

> -Original Message-
> From: jim_dai...@dell.com [mailto:jim_dai...@dell.com]
> Sent: Thursday, February 18, 2016 8:26 AM
> To: Carsey, Jaben 
> Cc: Qiu, Shumin ; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH] ShellPkg: Increase reallocation size for temp
> memory files
> Importance: High
> 
> Dell - Internal Use - Confidential
> 
> >> +#define MEM_WRITE_REALLOC_SIZE 1024
> >
> > Could this name change to something more clear? This is not the
> > allocate size, this is more like the reallocated overhead that is
> > allocated extra in case we have a sequence of reallocates...
> 
> I have no problem with whatever name you think is better. Maybe something
> along the lines of MEM_WRITE_REALLOC_OVERHEAD?

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

Re: [edk2] [PATCH] ShellPkg: Increase reallocation size for temp memory files

[Jim_Dailey]

Dell - Internal Use - Confidential 

>> +#define MEM_WRITE_REALLOC_SIZE 1024
>
> Could this name change to something more clear? This is not the 
> allocate size, this is more like the reallocated overhead that is 
> allocated extra in case we have a sequence of reallocates...

I have no problem with whatever name you think is better. Maybe something along 
the lines of MEM_WRITE_REALLOC_OVERHEAD?

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

Re: [edk2] [PATCH] ShellPkg: Increase reallocation size for temp memory files

[Carsey, Jaben]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> jim_dai...@dell.com
> Sent: Thursday, February 18, 2016 7:52 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Qiu, Shumin
> 
> Subject: [edk2] [PATCH] ShellPkg: Increase reallocation size for temp memory
> files
> Importance: High
> 
> ShellPkg: Increase reallocation size for temp memory files
> 
> If data of any real size were to be piped from one command to another, an
> inordinate amount of time could be taken up by reallocating memory that is
> only 10 bytes bigger than what is currently needed. Also, this could cause
> unwelcome memory fragmentation.
> 
> Added a define to control how much memory is reallocated beyond that
> which is currently needed. Set it to 1K vs. the original 10 bytes.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jim Dailey
> ---
> ShellPkg/Application/Shell/FileHandleWrappers.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/ShellPkg/Application/Shell/FileHandleWrappers.c
> b/ShellPkg/Application/Shell/FileHandleWrappers.c
> index a9117be..1a61521 100644
> --- a/ShellPkg/Application/Shell/FileHandleWrappers.c
> +++ b/ShellPkg/Application/Shell/FileHandleWrappers.c
> @@ -18,6 +18,8 @@
> #include "Shell.h"
> #include "FileHandleInternal.h"
> 
> +#define MEM_WRITE_REALLOC_SIZE 1024

Could this name change to something more clear?  This is not the allocate size, 
this is more like the reallocated overhead that is allocated extra in case we 
have a sequence of reallocates...


> +
> /**
> File style interface for console (Open).
> 
> @@ -1398,8 +1400,8 @@ FileInterfaceMemWrite(
> // Unicode
> //
> if ((UINTN)(MemFile->Position + (*BufferSize)) > (UINTN)(MemFile-
> >BufferSize)) {
> - MemFile->Buffer = ReallocatePool((UINTN)(MemFile->BufferSize),
> (UINTN)(MemFile->BufferSize) + (*BufferSize) + 10, MemFile->Buffer);
> - MemFile->BufferSize += (*BufferSize) + 10;
> + MemFile->Buffer = ReallocatePool((UINTN)(MemFile->BufferSize),
> (UINTN)(MemFile->BufferSize) + (*BufferSize) + MEM_WRITE_REALLOC_SIZE,
> MemFile->Buffer);
> + MemFile->BufferSize += (*BufferSize) + MEM_WRITE_REALLOC_SIZE;
> }
> CopyMem(((UINT8*)MemFile->Buffer) + MemFile->Position, Buffer,
> *BufferSize);
> MemFile->Position += (*BufferSize); @@ -1415,8 +1417,8 @@
> FileInterfaceMemWrite(
> }
> AsciiSPrint(AsciiBuffer, *BufferSize, "%S", Buffer);
> if ((UINTN)(MemFile->Position + AsciiStrSize(AsciiBuffer)) > (UINTN)(MemFile-
> >BufferSize)) {
> - MemFile->Buffer = ReallocatePool((UINTN)(MemFile->BufferSize),
> (UINTN)(MemFile->BufferSize) + AsciiStrSize(AsciiBuffer) + 10, MemFile-
> >Buffer);
> - MemFile->BufferSize += AsciiStrSize(AsciiBuffer) + 10;
> + MemFile->Buffer = ReallocatePool((UINTN)(MemFile->BufferSize),
> (UINTN)(MemFile->BufferSize) + AsciiStrSize(AsciiBuffer) +
> MEM_WRITE_REALLOC_SIZE, MemFile->Buffer);
> + MemFile->BufferSize += AsciiStrSize(AsciiBuffer) +
> + MEM_WRITE_REALLOC_SIZE;
> }
> CopyMem(((UINT8*)MemFile->Buffer) + MemFile->Position, AsciiBuffer,
> AsciiStrSize(AsciiBuffer));
> MemFile->Position += (*BufferSize / sizeof(CHAR16));
> --
> 2.7.1.windows.1
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Yao, Jiewen]

I agree.
The version support is mess in this driver. There is some historic reason which 
makes code like this today.
Just differentiate 1_0B and other is good enough, it matched UEFI spec, too. 
UEFI spec only defines "ACPI1.0b" and "ACPI2.0+above" in configuration table.

Again, thanks for your contribution to fix this issue.

Thank you
Yao Jiewen

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, February 18, 2016 11:47 PM
To: Yao, Jiewen
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Laszlo Ersek; Zeng, Star
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

On 18 February 2016 at 16:44, Yao, Jiewen  wrote:
> I found PI spec vol 5 has below definition in EFI_ACPI_SDT_PROTOCOL. Maybe we 
> can define PcdAcpiTableVersion to match this.
>
> #define UINT32 EFI_ACPI_TABLE_VERSION; #define 
> EFI_ACPI_TABLE_VERSION_NONE (1 << 0) #define 
> EFI_ACPI_TABLE_VERSION_1_0B (1 << 1) #define 
> EFI_ACPI_TABLE_VERSION_2_0 (1 << 2) #define EFI_ACPI_TABLE_VERSION_3_0 
> (1 << 3) #define EFI_ACPI_TABLE_VERSION_4_0 (1 << 4) #define 
> EFI_ACPI_TABLE_VERSION_5_0 (1 << 5)
>

OK, that makes sense. But I will only implement the difference between 'all 
supported' and 'all except 1.0B supported'


> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, February 18, 2016 11:27 PM
> To: Ard Biesheuvel
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif 
> Lindholm; Gao, Liming; Laszlo Ersek; Zeng, Star; Yao, Jiewen
> Subject: RE: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB 
> table allocation limit optional
>
> XSDT is introduced in ACPI2.0.
> ACPI1.0/ACPI1.0b only defined 32bit address range. ACPI2.0 resolved 4G issue 
> immediately, but in order to keep compatibility, most platform produced both 
> DSDT and XSDT, and with FADT1.0 and FADT2.0, at that time.
>
> For now, I believe most OSes support ACPI2.0 and above. So it should be safe.
>
> Thank you
> Yao Jiewen
>
>
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, February 18, 2016 11:15 PM
> To: Yao, Jiewen
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif 
> Lindholm; Gao, Liming; Laszlo Ersek; Zeng, Star
> Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB 
> table allocation limit optional
>
> On 18 February 2016 at 16:07, Yao, Jiewen  wrote:
>> Or PcdAcpiSupportVersion, bit0 as ACPI1.0.
>> Bit0 set means allocation Below4G.
>> Bit0 clear means allocation from everywhere.
>>
>
> That is also fine with me. But I think it was ACPI 5.0 that introduced XSDT, 
> right? So if you clear this bit, you would expect a ACPI system compatible 
> with a version older than 5.0 to still work, but with allocations above 4 GB 
> and no RSDT, only XSDT, would that be ok?
>
> So perhaps it should define the lowest supported ACPI level, with legal 
> values of '1' and '5' for the moment, and we can always expand it later if we 
> need to.
>
>
>>
>> -Original Message-
>> From: Yao, Jiewen
>> Sent: Thursday, February 18, 2016 11:05 PM
>> To: Ard Biesheuvel
>> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif 
>> Lindholm; Gao, Liming; Laszlo Ersek; Zeng, Star; Yao, Jiewen
>> Subject: RE: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB 
>> table allocation limit optional
>>
>> Thanks to detail explain. I understand and I agree with you that 
>> fragmentation is problem.
>> So basically, I agree on PCD solution to choose preferred location of 
>> allocation.
>>
>> Maybe you can consider adding fragmentation issue as description to help 
>> more people on why we need this PCD.
>>
>> I also think the PCD name - do we consider PcdAcpi1Support, or similar? 
>> People need strong tech background to choose why and if he wants Below4GB or 
>> not. Using ACPI1.0 as PCD might be better, because if ACPI1.0 is not POR, it 
>> can be dropped. It is more clear.
>>
>> Just like SMBIOS table, we use PcdSmbiosEntryPointProvideMethod, instead of 
>> Below4GB.
>>
>> Thank you
>> Yao Jiewen
>>
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Ard Biesheuvel
>> Sent: Thursday, February 18, 2016 10:39 PM
>> To: Yao, Jiewen
>> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif 
>> Lindholm; Gao, Liming; Laszlo Ersek; Zeng, Star
>> Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB 
>> table allocation limit optional
>>
>> On 18 February 2016 at 15:20, Yao, Jiewen  wrote:
>>> Hi
>>> Thanks to bring this 4G issue again. I have several thought for your 
>>> consideration.
>>>
>>> 1) At 12/16/2015, Samer El-Haj-Mahmoud  
>>> submitted a patch:
>>> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get 

[edk2] [PATCH] ShellPkg: Increase reallocation size for temp memory files

[Jim_Dailey]

ShellPkg: Increase reallocation size for temp memory files

If data of any real size were to be piped from one command to another, an 
inordinate amount of time could be taken up by reallocating memory that is only 
10 bytes bigger than what is currently needed. Also, this could cause unwelcome 
memory fragmentation.

Added a define to control how much memory is reallocated beyond that which is 
currently needed. Set it to 1K vs. the original 10 bytes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey 
---
ShellPkg/Application/Shell/FileHandleWrappers.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/ShellPkg/Application/Shell/FileHandleWrappers.c 
b/ShellPkg/Application/Shell/FileHandleWrappers.c
index a9117be..1a61521 100644
--- a/ShellPkg/Application/Shell/FileHandleWrappers.c
+++ b/ShellPkg/Application/Shell/FileHandleWrappers.c
@@ -18,6 +18,8 @@
#include "Shell.h"
#include "FileHandleInternal.h"

+#define MEM_WRITE_REALLOC_SIZE 1024
+
/**
File style interface for console (Open). 

@@ -1398,8 +1400,8 @@ FileInterfaceMemWrite(
// Unicode
//
if ((UINTN)(MemFile->Position + (*BufferSize)) > (UINTN)(MemFile->BufferSize)) {
- MemFile->Buffer = ReallocatePool((UINTN)(MemFile->BufferSize), 
(UINTN)(MemFile->BufferSize) + (*BufferSize) + 10, MemFile->Buffer);
- MemFile->BufferSize += (*BufferSize) + 10;
+ MemFile->Buffer = ReallocatePool((UINTN)(MemFile->BufferSize), 
(UINTN)(MemFile->BufferSize) + (*BufferSize) + MEM_WRITE_REALLOC_SIZE, 
MemFile->Buffer);
+ MemFile->BufferSize += (*BufferSize) + MEM_WRITE_REALLOC_SIZE;
}
CopyMem(((UINT8*)MemFile->Buffer) + MemFile->Position, Buffer, *BufferSize);
MemFile->Position += (*BufferSize); @@ -1415,8 +1417,8 @@ FileInterfaceMemWrite(
}
AsciiSPrint(AsciiBuffer, *BufferSize, "%S", Buffer);
if ((UINTN)(MemFile->Position + AsciiStrSize(AsciiBuffer)) > 
(UINTN)(MemFile->BufferSize)) {
- MemFile->Buffer = ReallocatePool((UINTN)(MemFile->BufferSize), 
(UINTN)(MemFile->BufferSize) + AsciiStrSize(AsciiBuffer) + 10, MemFile->Buffer);
- MemFile->BufferSize += AsciiStrSize(AsciiBuffer) + 10;
+ MemFile->Buffer = ReallocatePool((UINTN)(MemFile->BufferSize), 
(UINTN)(MemFile->BufferSize) + AsciiStrSize(AsciiBuffer) + 
MEM_WRITE_REALLOC_SIZE, MemFile->Buffer);
+ MemFile->BufferSize += AsciiStrSize(AsciiBuffer) + 
+ MEM_WRITE_REALLOC_SIZE;
}
CopyMem(((UINT8*)MemFile->Buffer) + MemFile->Position, AsciiBuffer, 
AsciiStrSize(AsciiBuffer));
MemFile->Position += (*BufferSize / sizeof(CHAR16));
--
2.7.1.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Ard Biesheuvel]

On 18 February 2016 at 16:44, Yao, Jiewen  wrote:
> I found PI spec vol 5 has below definition in EFI_ACPI_SDT_PROTOCOL. Maybe we 
> can define PcdAcpiTableVersion to match this.
>
> #define UINT32 EFI_ACPI_TABLE_VERSION;
> #define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
> #define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
> #define EFI_ACPI_TABLE_VERSION_2_0 (1 << 2)
> #define EFI_ACPI_TABLE_VERSION_3_0 (1 << 3)
> #define EFI_ACPI_TABLE_VERSION_4_0 (1 << 4)
> #define EFI_ACPI_TABLE_VERSION_5_0 (1 << 5)
>

OK, that makes sense. But I will only implement the difference between
'all supported' and 'all except 1.0B supported'


> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, February 18, 2016 11:27 PM
> To: Ard Biesheuvel
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
> Liming; Laszlo Ersek; Zeng, Star; Yao, Jiewen
> Subject: RE: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
> allocation limit optional
>
> XSDT is introduced in ACPI2.0.
> ACPI1.0/ACPI1.0b only defined 32bit address range. ACPI2.0 resolved 4G issue 
> immediately, but in order to keep compatibility, most platform produced both 
> DSDT and XSDT, and with FADT1.0 and FADT2.0, at that time.
>
> For now, I believe most OSes support ACPI2.0 and above. So it should be safe.
>
> Thank you
> Yao Jiewen
>
>
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, February 18, 2016 11:15 PM
> To: Yao, Jiewen
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
> Liming; Laszlo Ersek; Zeng, Star
> Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
> allocation limit optional
>
> On 18 February 2016 at 16:07, Yao, Jiewen  wrote:
>> Or PcdAcpiSupportVersion, bit0 as ACPI1.0.
>> Bit0 set means allocation Below4G.
>> Bit0 clear means allocation from everywhere.
>>
>
> That is also fine with me. But I think it was ACPI 5.0 that introduced XSDT, 
> right? So if you clear this bit, you would expect a ACPI system compatible 
> with a version older than 5.0 to still work, but with allocations above 4 GB 
> and no RSDT, only XSDT, would that be ok?
>
> So perhaps it should define the lowest supported ACPI level, with legal 
> values of '1' and '5' for the moment, and we can always expand it later if we 
> need to.
>
>
>>
>> -Original Message-
>> From: Yao, Jiewen
>> Sent: Thursday, February 18, 2016 11:05 PM
>> To: Ard Biesheuvel
>> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif
>> Lindholm; Gao, Liming; Laszlo Ersek; Zeng, Star; Yao, Jiewen
>> Subject: RE: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB
>> table allocation limit optional
>>
>> Thanks to detail explain. I understand and I agree with you that 
>> fragmentation is problem.
>> So basically, I agree on PCD solution to choose preferred location of 
>> allocation.
>>
>> Maybe you can consider adding fragmentation issue as description to help 
>> more people on why we need this PCD.
>>
>> I also think the PCD name - do we consider PcdAcpi1Support, or similar? 
>> People need strong tech background to choose why and if he wants Below4GB or 
>> not. Using ACPI1.0 as PCD might be better, because if ACPI1.0 is not POR, it 
>> can be dropped. It is more clear.
>>
>> Just like SMBIOS table, we use PcdSmbiosEntryPointProvideMethod, instead of 
>> Below4GB.
>>
>> Thank you
>> Yao Jiewen
>>
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Ard Biesheuvel
>> Sent: Thursday, February 18, 2016 10:39 PM
>> To: Yao, Jiewen
>> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif
>> Lindholm; Gao, Liming; Laszlo Ersek; Zeng, Star
>> Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB
>> table allocation limit optional
>>
>> On 18 February 2016 at 15:20, Yao, Jiewen  wrote:
>>> Hi
>>> Thanks to bring this 4G issue again. I have several thought for your 
>>> consideration.
>>>
>>> 1) At 12/16/2015, Samer El-Haj-Mahmoud  
>>> submitted a patch:
>>> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
>>> installed above 4GB
>>>
>>> Some ARM systems do not have available memory below 4GB, and still support 
>>> ACPI. This patch allows the tables to get loaded above 4GB if the 
>>> allocation below 4GB fails.
>>>
>>> I have given comments that:
>>> -- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.
>>>
>>
>> Indeed :-)
>>
>>> -- Can we create a new function to allocate <4G at first, if fail, allocate 
>>> any memory?
>>> Then we can update all caller to consume this new function.
>>> We can avoid adding ERROR check anywhere. I also suggest we need add some 
>>> debug message there, we can add into one place.
>>>
>>> It is just another option to resolve ARM issue. Currently, we only add PCD 
>>> when 

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

[David Woodhouse]

On Thu, 2016-02-18 at 14:27 +, David Woodhouse wrote:
> On Thu, 2016-02-18 at 14:58 +0100, Laszlo Ersek wrote:
> > 
> > Then I gave my R-b to this patch, admitting that I couldn't verify the
> > edk2-only customizations against the 1.0.2f release.
> > 
> > Turns out those customizations are indeed no longer correct, so my R-b
> > was in error.
> 
> Er, aren't they? Are you referring to my comment about the RT#3955 fix?
> 
> That isn't actually *less* correct than it ever was.

And, embarrassingly, it looks like OpenSSL 1.1 has a fix which looks
much more like the one in EDKII_openssl-1.0.2f.patch, than the one in
my own tree.

Is there room for me to come and crawl under that rock *with* you...?

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



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

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

[Yao, Jiewen]

I found PI spec vol 5 has below definition in EFI_ACPI_SDT_PROTOCOL. Maybe we 
can define PcdAcpiTableVersion to match this.

#define UINT32 EFI_ACPI_TABLE_VERSION;
#define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
#define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
#define EFI_ACPI_TABLE_VERSION_2_0 (1 << 2)
#define EFI_ACPI_TABLE_VERSION_3_0 (1 << 3)
#define EFI_ACPI_TABLE_VERSION_4_0 (1 << 4)
#define EFI_ACPI_TABLE_VERSION_5_0 (1 << 5)

Thank you
Yao Jiewen

-Original Message-
From: Yao, Jiewen 
Sent: Thursday, February 18, 2016 11:27 PM
To: Ard Biesheuvel
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Laszlo Ersek; Zeng, Star; Yao, Jiewen
Subject: RE: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

XSDT is introduced in ACPI2.0.
ACPI1.0/ACPI1.0b only defined 32bit address range. ACPI2.0 resolved 4G issue 
immediately, but in order to keep compatibility, most platform produced both 
DSDT and XSDT, and with FADT1.0 and FADT2.0, at that time.

For now, I believe most OSes support ACPI2.0 and above. So it should be safe.

Thank you
Yao Jiewen


-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, February 18, 2016 11:15 PM
To: Yao, Jiewen
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Laszlo Ersek; Zeng, Star
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

On 18 February 2016 at 16:07, Yao, Jiewen  wrote:
> Or PcdAcpiSupportVersion, bit0 as ACPI1.0.
> Bit0 set means allocation Below4G.
> Bit0 clear means allocation from everywhere.
>

That is also fine with me. But I think it was ACPI 5.0 that introduced XSDT, 
right? So if you clear this bit, you would expect a ACPI system compatible with 
a version older than 5.0 to still work, but with allocations above 4 GB and no 
RSDT, only XSDT, would that be ok?

So perhaps it should define the lowest supported ACPI level, with legal values 
of '1' and '5' for the moment, and we can always expand it later if we need to.


>
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, February 18, 2016 11:05 PM
> To: Ard Biesheuvel
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif 
> Lindholm; Gao, Liming; Laszlo Ersek; Zeng, Star; Yao, Jiewen
> Subject: RE: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB 
> table allocation limit optional
>
> Thanks to detail explain. I understand and I agree with you that 
> fragmentation is problem.
> So basically, I agree on PCD solution to choose preferred location of 
> allocation.
>
> Maybe you can consider adding fragmentation issue as description to help more 
> people on why we need this PCD.
>
> I also think the PCD name - do we consider PcdAcpi1Support, or similar? 
> People need strong tech background to choose why and if he wants Below4GB or 
> not. Using ACPI1.0 as PCD might be better, because if ACPI1.0 is not POR, it 
> can be dropped. It is more clear.
>
> Just like SMBIOS table, we use PcdSmbiosEntryPointProvideMethod, instead of 
> Below4GB.
>
> Thank you
> Yao Jiewen
>
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Ard Biesheuvel
> Sent: Thursday, February 18, 2016 10:39 PM
> To: Yao, Jiewen
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif 
> Lindholm; Gao, Liming; Laszlo Ersek; Zeng, Star
> Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB 
> table allocation limit optional
>
> On 18 February 2016 at 15:20, Yao, Jiewen  wrote:
>> Hi
>> Thanks to bring this 4G issue again. I have several thought for your 
>> consideration.
>>
>> 1) At 12/16/2015, Samer El-Haj-Mahmoud  
>> submitted a patch:
>> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
>> installed above 4GB
>>
>> Some ARM systems do not have available memory below 4GB, and still support 
>> ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
>> below 4GB fails.
>>
>> I have given comments that:
>> -- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.
>>
>
> Indeed :-)
>
>> -- Can we create a new function to allocate <4G at first, if fail, allocate 
>> any memory?
>> Then we can update all caller to consume this new function.
>> We can avoid adding ERROR check anywhere. I also suggest we need add some 
>> debug message there, we can add into one place.
>>
>> It is just another option to resolve ARM issue. Currently, we only add PCD 
>> when necessary, because we got complain that we defined too many PCDs.
>> If there is a way to avoid introducing a new one. It worth considering.
>>
>
> No, this is not a good idea. This still assumes that allocating below
> 4 GB is preferred if possible, and that is simply not true on AArch64.
>
> Allocating below 4 GB if there is space there 

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

[Yao, Jiewen]

XSDT is introduced in ACPI2.0.
ACPI1.0/ACPI1.0b only defined 32bit address range. ACPI2.0 resolved 4G issue 
immediately, but in order to keep compatibility, most platform produced both 
DSDT and XSDT, and with FADT1.0 and FADT2.0, at that time.

For now, I believe most OSes support ACPI2.0 and above. So it should be safe.

Thank you
Yao Jiewen


-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Thursday, February 18, 2016 11:15 PM
To: Yao, Jiewen
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Laszlo Ersek; Zeng, Star
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

On 18 February 2016 at 16:07, Yao, Jiewen  wrote:
> Or PcdAcpiSupportVersion, bit0 as ACPI1.0.
> Bit0 set means allocation Below4G.
> Bit0 clear means allocation from everywhere.
>

That is also fine with me. But I think it was ACPI 5.0 that introduced XSDT, 
right? So if you clear this bit, you would expect a ACPI system compatible with 
a version older than 5.0 to still work, but with allocations above 4 GB and no 
RSDT, only XSDT, would that be ok?

So perhaps it should define the lowest supported ACPI level, with legal values 
of '1' and '5' for the moment, and we can always expand it later if we need to.


>
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, February 18, 2016 11:05 PM
> To: Ard Biesheuvel
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif 
> Lindholm; Gao, Liming; Laszlo Ersek; Zeng, Star; Yao, Jiewen
> Subject: RE: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB 
> table allocation limit optional
>
> Thanks to detail explain. I understand and I agree with you that 
> fragmentation is problem.
> So basically, I agree on PCD solution to choose preferred location of 
> allocation.
>
> Maybe you can consider adding fragmentation issue as description to help more 
> people on why we need this PCD.
>
> I also think the PCD name - do we consider PcdAcpi1Support, or similar? 
> People need strong tech background to choose why and if he wants Below4GB or 
> not. Using ACPI1.0 as PCD might be better, because if ACPI1.0 is not POR, it 
> can be dropped. It is more clear.
>
> Just like SMBIOS table, we use PcdSmbiosEntryPointProvideMethod, instead of 
> Below4GB.
>
> Thank you
> Yao Jiewen
>
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Ard Biesheuvel
> Sent: Thursday, February 18, 2016 10:39 PM
> To: Yao, Jiewen
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif 
> Lindholm; Gao, Liming; Laszlo Ersek; Zeng, Star
> Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB 
> table allocation limit optional
>
> On 18 February 2016 at 15:20, Yao, Jiewen  wrote:
>> Hi
>> Thanks to bring this 4G issue again. I have several thought for your 
>> consideration.
>>
>> 1) At 12/16/2015, Samer El-Haj-Mahmoud  
>> submitted a patch:
>> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
>> installed above 4GB
>>
>> Some ARM systems do not have available memory below 4GB, and still support 
>> ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
>> below 4GB fails.
>>
>> I have given comments that:
>> -- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.
>>
>
> Indeed :-)
>
>> -- Can we create a new function to allocate <4G at first, if fail, allocate 
>> any memory?
>> Then we can update all caller to consume this new function.
>> We can avoid adding ERROR check anywhere. I also suggest we need add some 
>> debug message there, we can add into one place.
>>
>> It is just another option to resolve ARM issue. Currently, we only add PCD 
>> when necessary, because we got complain that we defined too many PCDs.
>> If there is a way to avoid introducing a new one. It worth considering.
>>
>
> No, this is not a good idea. This still assumes that allocating below
> 4 GB is preferred if possible, and that is simply not true on AArch64.
>
> Allocating below 4 GB if there is space there will result in some UEFI 
> regions at the top of memory, and some regions below 4 GB. This needlessly 
> fragments the address space, and results in reduced TLB efficiency, since 
> ACPI tables are not mapped by default, and the [3 GB, 4 GB] interval can no 
> longer be mapped using a single 1 GB block entry. Also, memory below 4 GB 
> needs to be reserved for devices that can only do 32-bit DMA.
>
>> 2) I believe 4G table issue not only exist in ACPI table, but also exist in 
>> others. For example, Smbios table.
>> SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G 
>> limitation.
>>
>> I know ACPI table and SMBIOS table are different. Some platforms care only 
>> one of them.
>> Personally, I hope we can have a consistent way to resolve this generic 

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

[Ard Biesheuvel]

On 18 February 2016 at 16:07, Yao, Jiewen  wrote:
> Or PcdAcpiSupportVersion, bit0 as ACPI1.0.
> Bit0 set means allocation Below4G.
> Bit0 clear means allocation from everywhere.
>

That is also fine with me. But I think it was ACPI 5.0 that introduced
XSDT, right? So if you clear this bit, you would expect a ACPI system
compatible with a version older than 5.0 to still work, but with
allocations above 4 GB and no RSDT, only XSDT, would that be ok?

So perhaps it should define the lowest supported ACPI level, with
legal values of '1' and '5' for the moment, and we can always expand
it later if we need to.


>
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, February 18, 2016 11:05 PM
> To: Ard Biesheuvel
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
> Liming; Laszlo Ersek; Zeng, Star; Yao, Jiewen
> Subject: RE: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
> allocation limit optional
>
> Thanks to detail explain. I understand and I agree with you that 
> fragmentation is problem.
> So basically, I agree on PCD solution to choose preferred location of 
> allocation.
>
> Maybe you can consider adding fragmentation issue as description to help more 
> people on why we need this PCD.
>
> I also think the PCD name - do we consider PcdAcpi1Support, or similar? 
> People need strong tech background to choose why and if he wants Below4GB or 
> not. Using ACPI1.0 as PCD might be better, because if ACPI1.0 is not POR, it 
> can be dropped. It is more clear.
>
> Just like SMBIOS table, we use PcdSmbiosEntryPointProvideMethod, instead of 
> Below4GB.
>
> Thank you
> Yao Jiewen
>
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> Biesheuvel
> Sent: Thursday, February 18, 2016 10:39 PM
> To: Yao, Jiewen
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
> Liming; Laszlo Ersek; Zeng, Star
> Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
> allocation limit optional
>
> On 18 February 2016 at 15:20, Yao, Jiewen  wrote:
>> Hi
>> Thanks to bring this 4G issue again. I have several thought for your 
>> consideration.
>>
>> 1) At 12/16/2015, Samer El-Haj-Mahmoud  
>> submitted a patch:
>> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
>> installed above 4GB
>>
>> Some ARM systems do not have available memory below 4GB, and still support 
>> ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
>> below 4GB fails.
>>
>> I have given comments that:
>> -- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.
>>
>
> Indeed :-)
>
>> -- Can we create a new function to allocate <4G at first, if fail, allocate 
>> any memory?
>> Then we can update all caller to consume this new function.
>> We can avoid adding ERROR check anywhere. I also suggest we need add some 
>> debug message there, we can add into one place.
>>
>> It is just another option to resolve ARM issue. Currently, we only add PCD 
>> when necessary, because we got complain that we defined too many PCDs.
>> If there is a way to avoid introducing a new one. It worth considering.
>>
>
> No, this is not a good idea. This still assumes that allocating below
> 4 GB is preferred if possible, and that is simply not true on AArch64.
>
> Allocating below 4 GB if there is space there will result in some UEFI 
> regions at the top of memory, and some regions below 4 GB. This needlessly 
> fragments the address space, and results in reduced TLB efficiency, since 
> ACPI tables are not mapped by default, and the [3 GB, 4 GB] interval can no 
> longer be mapped using a single 1 GB block entry. Also, memory below 4 GB 
> needs to be reserved for devices that can only do 32-bit DMA.
>
>> 2) I believe 4G table issue not only exist in ACPI table, but also exist in 
>> others. For example, Smbios table.
>> SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G 
>> limitation.
>>
>> I know ACPI table and SMBIOS table are different. Some platforms care only 
>> one of them.
>> Personally, I hope we can have a consistent way to resolve this generic 4G 
>> issue.
>>
>> I have seems SMBIOS table is using the way Samer submitted in last
>> year. (Allocate <4G at first, if fail, allocate at any place) Do you see any 
>> limitation on this algorithm?
>>
>
> This only happens if you have lower than version 3.0 or the 
> PcdSmbiosEntryPointProvideMethod has bit 0 set. On AARCH64 systems, we 
> usually only enable the v3.0 entry point, and clear bit 0 in this PCD
>
>> I am not insist on some solutions. I just want to bring the other way for 
>> discussion.
>>
>> BTW: I am not clear on memory map on >4G ARM platform. Can someone help me 
>> understand where is runtime code/runtime data/ACPI NVS/Reserved memory? >4G 
>> or <4G?
>>
>
> Sorry to be pedantic, 

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

[Yao, Jiewen]

Or PcdAcpiSupportVersion, bit0 as ACPI1.0.
Bit0 set means allocation Below4G.
Bit0 clear means allocation from everywhere.


-Original Message-
From: Yao, Jiewen 
Sent: Thursday, February 18, 2016 11:05 PM
To: Ard Biesheuvel
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Laszlo Ersek; Zeng, Star; Yao, Jiewen
Subject: RE: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

Thanks to detail explain. I understand and I agree with you that fragmentation 
is problem.
So basically, I agree on PCD solution to choose preferred location of 
allocation.

Maybe you can consider adding fragmentation issue as description to help more 
people on why we need this PCD.

I also think the PCD name - do we consider PcdAcpi1Support, or similar? People 
need strong tech background to choose why and if he wants Below4GB or not. 
Using ACPI1.0 as PCD might be better, because if ACPI1.0 is not POR, it can be 
dropped. It is more clear.

Just like SMBIOS table, we use PcdSmbiosEntryPointProvideMethod, instead of 
Below4GB.

Thank you
Yao Jiewen


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, February 18, 2016 10:39 PM
To: Yao, Jiewen
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Laszlo Ersek; Zeng, Star
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

On 18 February 2016 at 15:20, Yao, Jiewen  wrote:
> Hi
> Thanks to bring this 4G issue again. I have several thought for your 
> consideration.
>
> 1) At 12/16/2015, Samer El-Haj-Mahmoud  
> submitted a patch:
> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
> installed above 4GB
>
> Some ARM systems do not have available memory below 4GB, and still support 
> ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
> below 4GB fails.
>
> I have given comments that:
> -- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.
>

Indeed :-)

> -- Can we create a new function to allocate <4G at first, if fail, allocate 
> any memory?
> Then we can update all caller to consume this new function.
> We can avoid adding ERROR check anywhere. I also suggest we need add some 
> debug message there, we can add into one place.
>
> It is just another option to resolve ARM issue. Currently, we only add PCD 
> when necessary, because we got complain that we defined too many PCDs.
> If there is a way to avoid introducing a new one. It worth considering.
>

No, this is not a good idea. This still assumes that allocating below
4 GB is preferred if possible, and that is simply not true on AArch64.

Allocating below 4 GB if there is space there will result in some UEFI regions 
at the top of memory, and some regions below 4 GB. This needlessly fragments 
the address space, and results in reduced TLB efficiency, since ACPI tables are 
not mapped by default, and the [3 GB, 4 GB] interval can no longer be mapped 
using a single 1 GB block entry. Also, memory below 4 GB needs to be reserved 
for devices that can only do 32-bit DMA.

> 2) I believe 4G table issue not only exist in ACPI table, but also exist in 
> others. For example, Smbios table.
> SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G 
> limitation.
>
> I know ACPI table and SMBIOS table are different. Some platforms care only 
> one of them.
> Personally, I hope we can have a consistent way to resolve this generic 4G 
> issue.
>
> I have seems SMBIOS table is using the way Samer submitted in last 
> year. (Allocate <4G at first, if fail, allocate at any place) Do you see any 
> limitation on this algorithm?
>

This only happens if you have lower than version 3.0 or the 
PcdSmbiosEntryPointProvideMethod has bit 0 set. On AARCH64 systems, we usually 
only enable the v3.0 entry point, and clear bit 0 in this PCD

> I am not insist on some solutions. I just want to bring the other way for 
> discussion.
>
> BTW: I am not clear on memory map on >4G ARM platform. Can someone help me 
> understand where is runtime code/runtime data/ACPI NVS/Reserved memory? >4G 
> or <4G?
>

Sorry to be pedantic, but AARCH64 is an architecture, not a platform.
Every AARCH64 platform has complete freedom as to where peripherals live and 
where system RAM lives, and some platforms have their RAM starting at 
0x80__ So every such region could be anywhere in the address space.


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Ard Biesheuvel
> Sent: Thursday, February 18, 2016 1:42 AM
> To: Laszlo Ersek
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif 
> Lindholm; Gao, Liming; Zeng, Star
> Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB 
> table allocation limit 

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

[Yao, Jiewen]

Thanks to detail explain. I understand and I agree with you that fragmentation 
is problem.
So basically, I agree on PCD solution to choose preferred location of 
allocation.

Maybe you can consider adding fragmentation issue as description to help more 
people on why we need this PCD.

I also think the PCD name - do we consider PcdAcpi1Support, or similar? People 
need strong tech background to choose why and if he wants Below4GB or not. 
Using ACPI1.0 as PCD might be better, because if ACPI1.0 is not POR, it can be 
dropped. It is more clear.

Just like SMBIOS table, we use PcdSmbiosEntryPointProvideMethod, instead of 
Below4GB.

Thank you
Yao Jiewen


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, February 18, 2016 10:39 PM
To: Yao, Jiewen
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Laszlo Ersek; Zeng, Star
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

On 18 February 2016 at 15:20, Yao, Jiewen  wrote:
> Hi
> Thanks to bring this 4G issue again. I have several thought for your 
> consideration.
>
> 1) At 12/16/2015, Samer El-Haj-Mahmoud  
> submitted a patch:
> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
> installed above 4GB
>
> Some ARM systems do not have available memory below 4GB, and still support 
> ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
> below 4GB fails.
>
> I have given comments that:
> -- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.
>

Indeed :-)

> -- Can we create a new function to allocate <4G at first, if fail, allocate 
> any memory?
> Then we can update all caller to consume this new function.
> We can avoid adding ERROR check anywhere. I also suggest we need add some 
> debug message there, we can add into one place.
>
> It is just another option to resolve ARM issue. Currently, we only add PCD 
> when necessary, because we got complain that we defined too many PCDs.
> If there is a way to avoid introducing a new one. It worth considering.
>

No, this is not a good idea. This still assumes that allocating below
4 GB is preferred if possible, and that is simply not true on AArch64.

Allocating below 4 GB if there is space there will result in some UEFI regions 
at the top of memory, and some regions below 4 GB. This needlessly fragments 
the address space, and results in reduced TLB efficiency, since ACPI tables are 
not mapped by default, and the [3 GB, 4 GB] interval can no longer be mapped 
using a single 1 GB block entry. Also, memory below 4 GB needs to be reserved 
for devices that can only do 32-bit DMA.

> 2) I believe 4G table issue not only exist in ACPI table, but also exist in 
> others. For example, Smbios table.
> SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G 
> limitation.
>
> I know ACPI table and SMBIOS table are different. Some platforms care only 
> one of them.
> Personally, I hope we can have a consistent way to resolve this generic 4G 
> issue.
>
> I have seems SMBIOS table is using the way Samer submitted in last 
> year. (Allocate <4G at first, if fail, allocate at any place) Do you see any 
> limitation on this algorithm?
>

This only happens if you have lower than version 3.0 or the 
PcdSmbiosEntryPointProvideMethod has bit 0 set. On AARCH64 systems, we usually 
only enable the v3.0 entry point, and clear bit 0 in this PCD

> I am not insist on some solutions. I just want to bring the other way for 
> discussion.
>
> BTW: I am not clear on memory map on >4G ARM platform. Can someone help me 
> understand where is runtime code/runtime data/ACPI NVS/Reserved memory? >4G 
> or <4G?
>

Sorry to be pedantic, but AARCH64 is an architecture, not a platform.
Every AARCH64 platform has complete freedom as to where peripherals live and 
where system RAM lives, and some platforms have their RAM starting at 
0x80__ So every such region could be anywhere in the address space.


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Ard Biesheuvel
> Sent: Thursday, February 18, 2016 1:42 AM
> To: Laszlo Ersek
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif 
> Lindholm; Gao, Liming; Zeng, Star
> Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB 
> table allocation limit optional
>
> On 17 February 2016 at 18:40, Laszlo Ersek  wrote:
>> On 02/17/16 18:23, Ard Biesheuvel wrote:
>>> On 17 February 2016 at 18:07, Graeme Gregory  
>>> wrote:


 On 17/02/2016 16:04, Laszlo Ersek wrote:
>
> On 02/17/16 16:34, Ard Biesheuvel wrote:
>>
>> On 17 February 2016 at 16:11, Laszlo Ersek  wrote:
>>>
>>> On 02/17/16 15:48, Ard Biesheuvel wrote:

[edk2] RESEND: [PATCH] ShellPkg: Do not write the UNICODE BOM on ConOut

[Jim_Dailey]

ShellPkg: Do not write the UNICODE BOM on ConOut.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey 
---
 ShellPkg/Application/Shell/FileHandleWrappers.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Application/Shell/FileHandleWrappers.c 
b/ShellPkg/Application/Shell/FileHandleWrappers.c
index f8306e2..ecad500 100644
--- a/ShellPkg/Application/Shell/FileHandleWrappers.c
+++ b/ShellPkg/Application/Shell/FileHandleWrappers.c
@@ -160,9 +160,11 @@ FileInterfaceStdOutWrite(
 {
   if (ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoConsoleOut) {
 return (EFI_UNSUPPORTED);
-  } else {
-return (gST->ConOut->OutputString(gST->ConOut, Buffer));
   }
+  if (*((CHAR16 *)Buffer) == gUnicodeFileTag) {
+return (gST->ConOut->OutputString(gST->ConOut, (CHAR16 *)Buffer + 1));
+  }
+  return (gST->ConOut->OutputString(gST->ConOut, Buffer));
 }
 
 /**
-- 
2.7.1.windows.1

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

[edk2] [PATCH] ShellPkg: Add FileSize member to shell memory file structure.

[Jim_Dailey]

ShellPkg: Add FileSize member to shell memory file structure.

The shell uses the memory file structure to manage temporary files in
memory that support piping of output from one command into the the
input of another command.  The BufferSize member is the size of the
internal buffer, not the size of the data that was written to the
file. So, it was possible to read beyond the EOF of these files as
reads used BufferSize. Now FileSize tracks the actual size of these
files (the number of bytes written, not the number of bytes available
in the buffer), and the reads use this member.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey 
---
 ShellPkg/Application/Shell/FileHandleWrappers.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Application/Shell/FileHandleWrappers.c 
b/ShellPkg/Application/Shell/FileHandleWrappers.c
index ecad500..a9117be 100644
--- a/ShellPkg/Application/Shell/FileHandleWrappers.c
+++ b/ShellPkg/Application/Shell/FileHandleWrappers.c
@@ -1325,6 +1325,7 @@ typedef struct {
   UINT64Position;
   UINT64BufferSize;
   BOOLEAN   Unicode;
+  UINT64FileSize;
 } EFI_FILE_PROTOCOL_MEM;
 
 /**
@@ -1343,7 +1344,7 @@ FileInterfaceMemSetPosition(
   OUT UINT64 Position
   )
 {
-  if (Position <= ((EFI_FILE_PROTOCOL_MEM*)This)->BufferSize) {
+  if (Position <= ((EFI_FILE_PROTOCOL_MEM*)This)->FileSize) {
 ((EFI_FILE_PROTOCOL_MEM*)This)->Position = Position;
 return (EFI_SUCCESS);
   } else {
@@ -1402,6 +1403,7 @@ FileInterfaceMemWrite(
 }
 CopyMem(((UINT8*)MemFile->Buffer) + MemFile->Position, Buffer, 
*BufferSize);
 MemFile->Position += (*BufferSize);
+MemFile->FileSize = MemFile->Position;
 return (EFI_SUCCESS);
   } else {
 //
@@ -1418,6 +1420,7 @@ FileInterfaceMemWrite(
 }
 CopyMem(((UINT8*)MemFile->Buffer) + MemFile->Position, AsciiBuffer, 
AsciiStrSize(AsciiBuffer));
 MemFile->Position += (*BufferSize / sizeof(CHAR16));
+MemFile->FileSize = MemFile->Position;
 FreePool(AsciiBuffer);
 return (EFI_SUCCESS);
   }
@@ -1443,8 +1446,8 @@ FileInterfaceMemRead(
   EFI_FILE_PROTOCOL_MEM  *MemFile;
 
   MemFile = (EFI_FILE_PROTOCOL_MEM *) This;
-  if (*BufferSize > (UINTN)((MemFile->BufferSize) - 
(UINTN)(MemFile->Position))) {
-(*BufferSize) = (UINTN)((MemFile->BufferSize) - 
(UINTN)(MemFile->Position));
+  if (*BufferSize > (UINTN)((MemFile->FileSize) - (UINTN)(MemFile->Position))) 
{
+(*BufferSize) = (UINTN)((MemFile->FileSize) - (UINTN)(MemFile->Position));
   }
   CopyMem(Buffer, ((UINT8*)MemFile->Buffer) + MemFile->Position, 
(*BufferSize));
   MemFile->Position = MemFile->Position + (*BufferSize);
-- 
2.7.1.windows.1

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

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

[El-Haj-Mahmoud, Samer]

Thanks Jiewen. On ARCH64 systems, it is possible not to have any memory below 
4GB at all.

Ard,

Are you OK with a solution that does not use a PCD?




-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com] 
Sent: Thursday, February 18, 2016 8:35 AM
To: El-Haj-Mahmoud, Samer ; Ard Biesheuvel 
; Laszlo Ersek 
Cc: Tian, Feng ; Graeme Gregory 
; edk2-devel@lists.01.org ; 
Leif Lindholm ; Gao, Liming ; 
Zeng, Star ; Yao, Jiewen 
Subject: RE: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

Yes. Good question: to PCD or not to PCD. :-)

If it is 2010, I will choose PCD, because I want the flexibility.
But now, when more and more people working on that, they start complaining the 
number of *possible* configuration. So we are trying to not add too much PCD, 
unless it is necessary.
That is why I changed my mind later.

However, if there is known limitation that we cannot use fail/allocate 
algorithm, and PCD is the only way to resolve it. I am OK to add this PCD.

And I want to be educated on >4G ARM platform, too.

Thank you
Yao Jiewen

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
El-Haj-Mahmoud, Samer
Sent: Thursday, February 18, 2016 10:27 PM
To: Yao, Jiewen; Ard Biesheuvel; Laszlo Ersek
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Zeng, Star
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

Jiewen,

I think ACPI and SMBIOS solutions could be the same, or could be different. The 
SMBIOS 3.0 spec allows SMBIOS table to be above 4GB, and some platforms may 
chose that even if they have memory below 4GB. 

For the ACPI patch, it looks like Ard's feedback and yours are contradictory. 
Ard suggested a PCD, while you suggested no PCD and use the method to try below 
4GB, and if it fails move to above 4GB. We have no issue submitting the patch 
one way or the other, but we need agreement on the preferred solution. 

So, to PCD or not to PCD... 






-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Thursday, February 18, 2016 8:20 AM
To: Ard Biesheuvel ; Laszlo Ersek 
Cc: Tian, Feng ; Graeme Gregory 
; edk2-devel@lists.01.org ; 
Leif Lindholm ; Yao, Jiewen ; 
Gao, Liming ; Zeng, Star 
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

Hi
Thanks to bring this 4G issue again. I have several thought for your 
consideration.

1) At 12/16/2015, Samer El-Haj-Mahmoud  submitted 
a patch:
[edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
installed above 4GB

Some ARM systems do not have available memory below 4GB, and still support 
ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
below 4GB fails.

I have given comments that:
-- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.

-- Can we create a new function to allocate <4G at first, if fail, allocate any 
memory?
Then we can update all caller to consume this new function.
We can avoid adding ERROR check anywhere. I also suggest we need add some debug 
message there, we can add into one place.

It is just another option to resolve ARM issue. Currently, we only add PCD when 
necessary, because we got complain that we defined too many PCDs. 
If there is a way to avoid introducing a new one. It worth considering.

2) I believe 4G table issue not only exist in ACPI table, but also exist in 
others. For example, Smbios table.
SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G 
limitation.

I know ACPI table and SMBIOS table are different. Some platforms care only one 
of them.
Personally, I hope we can have a consistent way to resolve this generic 4G 
issue.

I have seems SMBIOS table is using the way Samer submitted in last year. 
(Allocate <4G at first, if fail, allocate at any place) Do you see any 
limitation on this algorithm?

I am not insist on some solutions. I just want to bring the other way for 
discussion.

BTW: I am not clear on memory map on >4G ARM platform. Can someone help me 
understand where is runtime code/runtime data/ACPI NVS/Reserved memory? >4G or 
<4G?

Thank you
Yao Jiewen


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, February 18, 2016 1:42 AM
To: Laszlo Ersek
Cc: Tian, 

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

[Ard Biesheuvel]

On 18 February 2016 at 15:20, Yao, Jiewen  wrote:
> Hi
> Thanks to bring this 4G issue again. I have several thought for your 
> consideration.
>
> 1) At 12/16/2015, Samer El-Haj-Mahmoud  
> submitted a patch:
> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
> installed above 4GB
>
> Some ARM systems do not have available memory below 4GB, and still support 
> ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
> below 4GB fails.
>
> I have given comments that:
> -- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.
>

Indeed :-)

> -- Can we create a new function to allocate <4G at first, if fail, allocate 
> any memory?
> Then we can update all caller to consume this new function.
> We can avoid adding ERROR check anywhere. I also suggest we need add some 
> debug message there, we can add into one place.
>
> It is just another option to resolve ARM issue. Currently, we only add PCD 
> when necessary, because we got complain that we defined too many PCDs.
> If there is a way to avoid introducing a new one. It worth considering.
>

No, this is not a good idea. This still assumes that allocating below
4 GB is preferred if possible, and that is simply not true on AArch64.

Allocating below 4 GB if there is space there will result in some UEFI
regions at the top of memory, and some regions below 4 GB. This
needlessly fragments the address space, and results in reduced TLB
efficiency, since ACPI tables are not mapped by default, and the [3
GB, 4 GB] interval can no longer be mapped using a single 1 GB block
entry. Also, memory below 4 GB needs to be reserved for devices that
can only do 32-bit DMA.


> 2) I believe 4G table issue not only exist in ACPI table, but also exist in 
> others. For example, Smbios table.
> SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G 
> limitation.
>
> I know ACPI table and SMBIOS table are different. Some platforms care only 
> one of them.
> Personally, I hope we can have a consistent way to resolve this generic 4G 
> issue.
>
> I have seems SMBIOS table is using the way Samer submitted in last year. 
> (Allocate <4G at first, if fail, allocate at any place)
> Do you see any limitation on this algorithm?
>

This only happens if you have lower than version 3.0 or the
PcdSmbiosEntryPointProvideMethod has bit 0 set. On AARCH64 systems, we
usually only enable the v3.0 entry point, and clear bit 0 in this PCD

> I am not insist on some solutions. I just want to bring the other way for 
> discussion.
>
> BTW: I am not clear on memory map on >4G ARM platform. Can someone help me 
> understand where is runtime code/runtime data/ACPI NVS/Reserved memory? >4G 
> or <4G?
>

Sorry to be pedantic, but AARCH64 is an architecture, not a platform.
Every AARCH64 platform has complete freedom as to where peripherals
live and where system RAM lives, and some platforms have their RAM
starting at 0x80__
So every such region could be anywhere in the address space.


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> Biesheuvel
> Sent: Thursday, February 18, 2016 1:42 AM
> To: Laszlo Ersek
> Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
> Liming; Zeng, Star
> Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
> allocation limit optional
>
> On 17 February 2016 at 18:40, Laszlo Ersek  wrote:
>> On 02/17/16 18:23, Ard Biesheuvel wrote:
>>> On 17 February 2016 at 18:07, Graeme Gregory  
>>> wrote:


 On 17/02/2016 16:04, Laszlo Ersek wrote:
>
> On 02/17/16 16:34, Ard Biesheuvel wrote:
>>
>> On 17 February 2016 at 16:11, Laszlo Ersek  wrote:
>>>
>>> On 02/17/16 15:48, Ard Biesheuvel wrote:

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

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

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

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

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

[Yao, Jiewen]

Yes. Good question: to PCD or not to PCD. :-)

If it is 2010, I will choose PCD, because I want the flexibility.
But now, when more and more people working on that, they start complaining the 
number of *possible* configuration. So we are trying to not add too much PCD, 
unless it is necessary.
That is why I changed my mind later.

However, if there is known limitation that we cannot use fail/allocate 
algorithm, and PCD is the only way to resolve it. I am OK to add this PCD.

And I want to be educated on >4G ARM platform, too.

Thank you
Yao Jiewen

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
El-Haj-Mahmoud, Samer
Sent: Thursday, February 18, 2016 10:27 PM
To: Yao, Jiewen; Ard Biesheuvel; Laszlo Ersek
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Zeng, Star
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

Jiewen,

I think ACPI and SMBIOS solutions could be the same, or could be different. The 
SMBIOS 3.0 spec allows SMBIOS table to be above 4GB, and some platforms may 
chose that even if they have memory below 4GB. 

For the ACPI patch, it looks like Ard's feedback and yours are contradictory. 
Ard suggested a PCD, while you suggested no PCD and use the method to try below 
4GB, and if it fails move to above 4GB. We have no issue submitting the patch 
one way or the other, but we need agreement on the preferred solution. 

So, to PCD or not to PCD... 






-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Thursday, February 18, 2016 8:20 AM
To: Ard Biesheuvel ; Laszlo Ersek 
Cc: Tian, Feng ; Graeme Gregory 
; edk2-devel@lists.01.org ; 
Leif Lindholm ; Yao, Jiewen ; 
Gao, Liming ; Zeng, Star 
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

Hi
Thanks to bring this 4G issue again. I have several thought for your 
consideration.

1) At 12/16/2015, Samer El-Haj-Mahmoud  submitted 
a patch:
[edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
installed above 4GB

Some ARM systems do not have available memory below 4GB, and still support 
ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
below 4GB fails.

I have given comments that:
-- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.

-- Can we create a new function to allocate <4G at first, if fail, allocate any 
memory?
Then we can update all caller to consume this new function.
We can avoid adding ERROR check anywhere. I also suggest we need add some debug 
message there, we can add into one place.

It is just another option to resolve ARM issue. Currently, we only add PCD when 
necessary, because we got complain that we defined too many PCDs. 
If there is a way to avoid introducing a new one. It worth considering.

2) I believe 4G table issue not only exist in ACPI table, but also exist in 
others. For example, Smbios table.
SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G 
limitation.

I know ACPI table and SMBIOS table are different. Some platforms care only one 
of them.
Personally, I hope we can have a consistent way to resolve this generic 4G 
issue.

I have seems SMBIOS table is using the way Samer submitted in last year. 
(Allocate <4G at first, if fail, allocate at any place) Do you see any 
limitation on this algorithm?

I am not insist on some solutions. I just want to bring the other way for 
discussion.

BTW: I am not clear on memory map on >4G ARM platform. Can someone help me 
understand where is runtime code/runtime data/ACPI NVS/Reserved memory? >4G or 
<4G?

Thank you
Yao Jiewen


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, February 18, 2016 1:42 AM
To: Laszlo Ersek
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Zeng, Star
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

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

 On 02/17/16 16:34, Ard Biesheuvel wrote:
>
> On 17 February 2016 at 16:11, Laszlo Ersek  wrote:
>>
>> On 02/17/16 15:48, Ard Biesheuvel wrote:
>>>
>>> AARCH64 systems never require compatibility with legacy ACPI 
>>> OSes, and may not have any 32-bit addressable system RAM. To 
>>> support 

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

[David Woodhouse]

On Thu, 2016-02-18 at 14:58 +0100, Laszlo Ersek wrote:
> 
> Then I gave my R-b to this patch, admitting that I couldn't verify the
> edk2-only customizations against the 1.0.2f release.
> 
> Turns out those customizations are indeed no longer correct, so my R-b
> was in error.

Er, aren't they? Are you referring to my comment about the RT#3955 fix?

That isn't actually *less* correct than it ever was.

-- 
dwmw2



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

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

[El-Haj-Mahmoud, Samer]

Jiewen,

I think ACPI and SMBIOS solutions could be the same, or could be different. The 
SMBIOS 3.0 spec allows SMBIOS table to be above 4GB, and some platforms may 
chose that even if they have memory below 4GB. 

For the ACPI patch, it looks like Ard's feedback and yours are contradictory. 
Ard suggested a PCD, while you suggested no PCD and use the method to try below 
4GB, and if it fails move to above 4GB. We have no issue submitting the patch 
one way or the other, but we need agreement on the preferred solution. 

So, to PCD or not to PCD... 






-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Thursday, February 18, 2016 8:20 AM
To: Ard Biesheuvel ; Laszlo Ersek 
Cc: Tian, Feng ; Graeme Gregory 
; edk2-devel@lists.01.org ; 
Leif Lindholm ; Yao, Jiewen ; 
Gao, Liming ; Zeng, Star 
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

Hi
Thanks to bring this 4G issue again. I have several thought for your 
consideration.

1) At 12/16/2015, Samer El-Haj-Mahmoud  submitted 
a patch:
[edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
installed above 4GB

Some ARM systems do not have available memory below 4GB, and still support 
ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
below 4GB fails.

I have given comments that:
-- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.

-- Can we create a new function to allocate <4G at first, if fail, allocate any 
memory?
Then we can update all caller to consume this new function.
We can avoid adding ERROR check anywhere. I also suggest we need add some debug 
message there, we can add into one place.

It is just another option to resolve ARM issue. Currently, we only add PCD when 
necessary, because we got complain that we defined too many PCDs. 
If there is a way to avoid introducing a new one. It worth considering.

2) I believe 4G table issue not only exist in ACPI table, but also exist in 
others. For example, Smbios table.
SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G 
limitation.

I know ACPI table and SMBIOS table are different. Some platforms care only one 
of them.
Personally, I hope we can have a consistent way to resolve this generic 4G 
issue.

I have seems SMBIOS table is using the way Samer submitted in last year. 
(Allocate <4G at first, if fail, allocate at any place) Do you see any 
limitation on this algorithm?

I am not insist on some solutions. I just want to bring the other way for 
discussion.

BTW: I am not clear on memory map on >4G ARM platform. Can someone help me 
understand where is runtime code/runtime data/ACPI NVS/Reserved memory? >4G or 
<4G?

Thank you
Yao Jiewen


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, February 18, 2016 1:42 AM
To: Laszlo Ersek
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Zeng, Star
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

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

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

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

[Yao, Jiewen]

Hi
Thanks to bring this 4G issue again. I have several thought for your 
consideration.

1) At 12/16/2015, Samer El-Haj-Mahmoud  submitted 
a patch:
[edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get   
installed above 4GB

Some ARM systems do not have available memory below 4GB, and still support 
ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
below 4GB fails.

I have given comments that:
-- I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.

-- Can we create a new function to allocate <4G at first, if fail, allocate any 
memory?
Then we can update all caller to consume this new function.
We can avoid adding ERROR check anywhere. I also suggest we need add some debug 
message there, we can add into one place.

It is just another option to resolve ARM issue. Currently, we only add PCD when 
necessary, because we got complain that we defined too many PCDs. 
If there is a way to avoid introducing a new one. It worth considering.

2) I believe 4G table issue not only exist in ACPI table, but also exist in 
others. For example, Smbios table.
SMBIOS 3.0 spec allows table be loaded >4G memory, while SMBIOS 2.X has 4G 
limitation.

I know ACPI table and SMBIOS table are different. Some platforms care only one 
of them.
Personally, I hope we can have a consistent way to resolve this generic 4G 
issue.

I have seems SMBIOS table is using the way Samer submitted in last year. 
(Allocate <4G at first, if fail, allocate at any place)
Do you see any limitation on this algorithm?

I am not insist on some solutions. I just want to bring the other way for 
discussion.

BTW: I am not clear on memory map on >4G ARM platform. Can someone help me 
understand where is runtime code/runtime data/ACPI NVS/Reserved memory? >4G or 
<4G?

Thank you
Yao Jiewen


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, February 18, 2016 1:42 AM
To: Laszlo Ersek
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lindholm; Gao, 
Liming; Zeng, Star
Subject: Re: [edk2] [RFC PATCH] MdeModulePkg: AcpiTableDxe: make 4 GB table 
allocation limit optional

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

 On 02/17/16 16:34, Ard Biesheuvel wrote:
>
> On 17 February 2016 at 16:11, Laszlo Ersek  wrote:
>>
>> On 02/17/16 15:48, Ard Biesheuvel wrote:
>>>
>>> AARCH64 systems never require compatibility with legacy ACPI 
>>> OSes, and may not have any 32-bit addressable system RAM. To 
>>> support ACPI on these systems, we need to be able to relax the 4 
>>> GB allocation restriction.
>>>
>>> So add a PCD PcdAcpiAllocateTablesBelow4GB defaulting to TRUE, 
>>> and wire it up to the memory allocation calls in 
>>> AcpiTableDxe/AcpiTableProtocol.c
>>>
>>> Note that this will inhibit the publishing of any tables that 
>>> carry only 32-bit addresses, i.e., RSDPv1, RSDTv1 and RSDTv3.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>   MdeModulePkg/MdeModulePkg.dec|   7 +
>>>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   2 +
>>>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 
>>> 447
>>> 
>>>   3 files changed, 270 insertions(+), 186 deletions(-)
>>
>> Somewhat independently of your patch, I agree 100% that the 
>> interface exposed by EFI_ACPI_TABLE_PROTOCOL is seriously 
>> lacking. It doesn't allow the caller to control the allocation 
>> limit (--> see your patch), nor the UEFI memory type that the 
>> copy of the table being installed will be placed into (it would 
>> be valid for the caller to choose between AcpiReclaim vs. 
>> AcpiNVS), nor the question whether the table being installed should be 
>> linked into the RSDT, XSDT, or both.
>>
>> I don't find this an implementation problem; this is a problem 
>> with the specification. In particular, in October last year I 
>> cross-posted an email to the USWG and ASWG lists, entitled
>>
>>LoadTable vs. EFI_ACPI_TABLE_PROTOCOL
>>
>> In that email, I pointed out that the current edk2 implementation 
>> of EFI_ACPI_TABLE_PROTOCOL makes it impossible to support the 
>> LoadTable ACPI operator. Namely, the LoadTable operator requires 
>> the definition block (= AML code) being loaded dynamically to 
>> come *from* AcpiNVS type memory, but edk2's implementation 
>> doesn't allow the caller to install tables into AcpiNVS type 

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

[Benjamin Herrenschmidt]

On Thu, 2016-02-18 at 06:55 +, Ni, Ruiyu wrote:
> Ben,
> I just had a look at your changes. Nice feeling that our codes are
> quite similar, except yours are in a separate function.
> I thought about separating it to a sub function but later didn't do
> that because this sub function is only called once
> and the logic after all is quite simple:)

The logic is simple yes but I dislike large functions, I find it makes
the overall code flow harder to follow ;-) Just a matter of personal
taste.

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

I'd prefer testing before rb'ing but I won't be able to do that for a
couple of weeks at least (travelling). Did you manage to find a
platform to test your changes ? I'll give it a closer look tomorrow and
send a rb based on pure code review. (Ping me if I forget).

Cheers,
Ben.

> Regards,
> Ray
> 
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] 
> Sent: Thursday, February 18, 2016 11:21 AM
> To: Ni, Ruiyu ; edk2-de...@ml01.01.org
> Cc: Andrew Fish ; Fan, Jeff 
> Subject: Re: [Patch 2/2] MdeModuelPkg/PciBus: Return
> AddrTranslationOffset in GetBarAttributes
> 
> On Thu, 2016-02-18 at 10:33 +0800, Ruiyu Ni wrote:
> > Some platform doesn't use CPU(HOST)/Device 1:1 mapping for PCI Bus.
> > But PCI IO doesn't have interface to tell caller (device driver)
> > whether the address returned by GetBarAttributes() is HOST address
> > or device address.
> > UEFI Spec 2.6 addresses this issue by clarifying the address
> > returned
> > is HOST address and caller can use AddrTranslationOffset to
> > calculate
> > the device address.
> 
> Hi !
> 
> I had implemented that a bit differently mostly for code clarity
> (see below pasted from github)
> 
> Ie, make it a sub function. Otherwise I think the principle is ok.
> 
> Note that I haven't been able to work on my EDK2 port for a while now
> due to other commitments. I will eventually get back to it and test
> your patch.
> 
> You can browse my monster-patch on github, I need to split/clean it
> into a proper patch series, it also contains some updates of a couple
> of drivers to actually use that offset properly
> 
> https://github.com/ozbenh/edk2/commits/master
> 
>  +  Finds the root bridge resource corresponding to the BAR whose
> address
>  +  space descritpor is passes as an argument and copy the
> translation offset
>  +  over from it into the BAR descriptor
>  +
>  +  @param  RootBridgeA pointer to the
> EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL instance.
>  +  @param  BarAddressSpace   A pointer to the ACPI 2.0 resource
> descriptors that describe the current
>  +configuration of this BAR of the
> PCI controller that is to be updated.
>  +
>  +  @retval EFI_SUCCESS   The descriptor was successfully
> updated.
>  +  @retval EFI_UNSUPPORTED   No resource in the root bridge
> matches the BAR region
>  +  @retval EFI_OUT_OF_RESOURCES  There are not enough resources
> available to allocate
>  +Resources.
>  +
>  +**/
>  +STATIC
>  +EFI_STATUS
>  +PciBarUpdateTranslationOffset(
>  +  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL   *RootBridge,
>  +  IN OUT EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *BarAddressSpace)
>  +{
>  +  EFI_STATUS Status;
>  +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  *RootDescriptors;
>  +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  *Desc;
>  +  UINT8  *Temp;
>  +
>  +  Status = RootBridge->Configuration (RootBridge, (VOID **)
> );
>  +  if (EFI_ERROR (Status)) {
>  +return Status;
>  +  }
>  +
>  +  Temp = (UINT8 *) RootDescriptors;
>  +  while (*Temp == ACPI_ADDRESS_SPACE_DESCRIPTOR) {
>  +Desc = (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *) Temp;
>  +
>  +//
>  +// Do we have the right type of descriptor ?
>  +//
>  +if (Desc->ResType == BarAddressSpace->ResType) {
>  +  //
>  +  // Check if the BAR base fits
>  +  //
>  +  if (BarAddressSpace->AddrRangeMin >= Desc->AddrRangeMin &&
>  +  BarAddressSpace->AddrRangeMin < (Desc->AddrRangeMin +
> Desc->AddrLen)) {
>  +//
>  +// Found it, update offset and return
>  +//
>  +BarAddressSpace->AddrTranslationOffset = Desc-
> >AddrTranslationOffset;
>  +return EFI_SUCCESS;
>  +  }
>  +}
>  +Temp += sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR);
>  +  }
>  +  return EFI_UNSUPPORTED;
>  +}
>  +
>  +/**
> Gets the attributes that this PCI controller supports setting on
> a BAR using
> SetBarAttributes(), and retrieves the list of resource
> descriptors for a BAR.
>   
>  @@ -1778,6 +1834,7 @@ PciIoGetBarAttributes (
> PCI_IO_DEVICE *PciIoDevice;
> EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *AddressSpace;
> EFI_ACPI_END_TAG_DESCRIPTOR   *End;
>  +  EFI_STATUS

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

[David Woodhouse]

On Thu, 2016-02-18 at 14:43 +0100, Laszlo Ersek wrote:
> 
> > Actually, in practice is *isn't* so bad. Given that we don't update our
> > EDKII_openssl-1.0.2X.patch very often (if at all) between OpenSSL
> > releases, what happens is that your build tree ends up with *multiple*
> > CryptoPkg/Library/OpensslLib/openssl-1.0.2[def] directories.
> 
> Interesting! The OPENSSL_PATH define in
> "CryptoPkg/Library/OpensslLib/OpensslLib.inf" would change, and the
> untracked files under the separate openssl-* directories would co-exist.
> I'm not sure about the untracked files created by Install.sh though --
> they come from the different openssl source trees, but go into a common
> location. Maybe Install.sh should be reexecuted at each step of the
> bisection.

Ah, good point. But I *killed* Install.sh, even for the 1.0.2 build,
many months ago. It temporarily escaped my notice that that fix wasn't
actually merged into EDK2 upstream yet. It's one of the set I sent
yesterday. Once that's done, *then* what I said is true because we
actually use the OpenSSL headers from within the OpenSSL source tree,
and don't stupidly *copy* them to our own Include/ directory.

> Do you think it will be possible to add openssl as a git submodule to
> the upstream edk2 repo? (I'd rather not explore that myself down-stream...)

I don't see why not. But let's concentrate on getting the even *more*
basic and obvious "you are completely insane if you aren't using git
properly" things fixed first... like using LF in the stored files.

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



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

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

[Laszlo Ersek]

On 02/18/16 13:14, Laszlo Ersek wrote:

> Okay, I'm done ranting.
> 
> Reviewed-by: Laszlo Ersek 

So let me review how my comments have worked out for this posting.

First I nacked it, because I thought the fact was not sufficiently
appreciated that David had posted a conflicting / more comprehensive /
potentially more correct patch series.

Then I withdrew my NACK, after David said he was okay with this patch
going in first -- assuming it was correct.

Then I gave my R-b to this patch, admitting that I couldn't verify the
edk2-only customizations against the 1.0.2f release.

Turns out those customizations are indeed no longer correct, so my R-b
was in error.

Not exactly a spotless track record for me, in this thread. I think I
shall stay away from reviewing OpenSSL updates.

In parallel, I propose that David be added to the CryptoPkg maintainers
in "Maintainers.txt" (provided he wants it). Then he should get
automatically CC'd on such rebases.

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

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

[Laszlo Ersek]

On 02/18/16 14:19, David Woodhouse wrote:

> Doesn't git
> convert automatically if it finds LF in the files it checks out, on
> Windows?

No clue. Never used git on Windows.

> And if things do get checked out with LF-only line endings on
> Windows, isn't that *also* harmless?

I don't think so. I know NOTEPAD.EXE garbles (well, used to garble)
LF-only text files. Maybe other commonly used text editors do that as well.

Plus, I'm worried that *new* files would be created with CRLF, and that
would lead to inconsistency.

> Either way, such a change will be *very* quickly lost in the dim and
> distant past — rather than being a constant problem and a barrier to
> contributions.

I'm not the one in need of convincing! ;)

I didn't mean to "defend" the current status.

Laszlo

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

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

[Laszlo Ersek]

On 02/18/16 13:59, David Woodhouse wrote:

[snip ;)]

> Please trim citations. You didn't have to cite the *entire* patch just
> to say that it seems right!
> 
> You aren't one of the Outlook-afflicted. We need you to set an example
> of how email is actually *supposed* to be used :)

Some people think trimming is not helpful, others think it's (almost)
required. I do trim emails, at the latest when they get overlong -- but
when replying to a patch directly, I think I rarely do.

I guess in this case it would have been justified, yes.

>> I also tried to diff the "openssl-1.0.2e" and "openssl-1.0.2f" trees
>> against each other, to see if "no new source changes [...] introduced
>> for 1.0.2f enabling" is indeed the right thing to do.
>>
>> The result of that diffing is a 3000 line patch, with the following
>> diffstat:
>>
>>  144 files changed, 815 insertions(+), 476 deletions(-)
> 
> This is the 21st century. Nobody in their right mind deals with
> software management except through git. More edifying would be to run:
> 
>  git log OpenSSL_1_0_2e..OpenSSL_1_0_2f  --stat
> 
> and/or
> 
>  gitk OpenSSL_1_0_2e..OpenSSL_1_0_2f

Sure, but that requires one to clone the OpenSSL repo, recognize the tag
names (yes, not too hard :)), and it's not the view that will be
ultimately visible in edk2. (After embedding the exploded OpenSSL tree.)

I assume this would be more manageable if the upstream openssl repo was
a submodule for edk2.

[snip]

>> So, I hereby declare the OpenSSL updates practically un-review-able,
>> even just for *scope* -- i.e., in order to see how far those changes
>> extend. I also claim that the OpenSSL release strategy is not being
>> implemented in reality -- the "letter releases" actually seem to be
>> vulnerability-triggered *snapshots* of the 1.0.2 tree, where the code
>> influx, albeit low volume, definitely meanders outside of bug and
>> security fixes.
> 
> Yeah, there's a certain amount of truth in what you say. When a high-
> priority vulnerability comes up, we need a new release and people need
> to upgrade. If we fix a minor functionality issue which is fairly
> esoteric and *doesn't* have security implications, there *isn't* an
> immediate release the same day. We'd run out of letters very quickly if
> we did that! :)
> 
> So yes, when the high-visibility issues trigger a release, a bunch of
> less important fixes go along for the ride. I don't think that's a
> problem.
> 
> But trust me — as someone who has occasionally wanted to get
> improvements into a stable branch of OpenSSL when they have been
> considered "new features" — when I say that they aren't adding whole
> piles of exciting new stuff to the 1.0.2 branch :)

I can trust you alright. :)

[snip]

>> Now, one might ask why I care. I care because for some downstreams of
>> edk2 at least, the situation that openssl has to be patched in before a
>> secure boot enabled build is completely unacceptable. That makes it
>> super-unwieldy to bisect a secure boot enabled build for example. It
>> also requires all people who clone your tree to patch in OpenSSL
>> manually.
> 
> Actually, in practice is *isn't* so bad. Given that we don't update our
> EDKII_openssl-1.0.2X.patch very often (if at all) between OpenSSL
> releases, what happens is that your build tree ends up with *multiple*
> CryptoPkg/Library/OpensslLib/openssl-1.0.2[def] directories.

Interesting! The OPENSSL_PATH define in
"CryptoPkg/Library/OpensslLib/OpensslLib.inf" would change, and the
untracked files under the separate openssl-* directories would co-exist.
I'm not sure about the untracked files created by Install.sh though --
they come from the different openssl source trees, but go into a common
location. Maybe Install.sh should be reexecuted at each step of the
bisection.

> And as you
> flit back and forth between EDK2 commits in your bisect, you use the
> different OpenSSL directories, as appropriate.
> 
>> Importing openssl should be a run-of-the-mill *commit* in the git
>> history (and it is, for us).
> 
> Surely this is what git submodules are for?

Probably. :)

[snip]

>> Honestly, edk2 should either incorporate OpenSSL permanently, or build
>> it 100% from an external, unmodified upstream tarball (I think this is
>> what David has been working on, right?)
> 
> As noted yesterday, we're two trivial patches from being able to use
> the next OpenSSL 1.1.0 beta snapshot "out of the box" with EDK2.

Do you think it will be possible to add openssl as a git submodule to
the upstream edk2 repo? (I'd rather not explore that myself down-stream...)

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

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

[David Woodhouse]

On Thu, 2016-02-18 at 14:12 +0100, Laszlo Ersek wrote:
> 
> > And even if we've missed the chance to do it "in retrospect" for
> > historical commits in our canonical git repository, we could still make
> > a commit now which *changes* the line endings to what git expects, and
> > quite soon this whole nonsense would be a thing of the past.
> 
> Yes. I think that would take a commit that converted everything to
> LF-only. Then everybody on Windows would have to toggle some git knobs,
> correct? Would that be safe when moving between commits?

I'm not even sure if they'd have to toggle anything. Doesn't git
convert automatically if it finds LF in the files it checks out, on
Windows? And if things do get checked out with LF-only line endings on
Windows, isn't that *also* harmless?

I have fairly much reached my masochism quota for this week though; I'm
not about to attempt to boot a Windows machine and check :)

Either way, such a change will be *very* quickly lost in the dim and
distant past — rather than being a constant problem and a barrier to
contributions.

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



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

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

[Laszlo Ersek]

On 02/18/16 13:59, David Woodhouse wrote:
> On Thu, 2016-02-18 at 13:40 +0100, Laszlo Ersek wrote:
>>> We should not be carrying patches which *differ* from the fixes that
>>> went into OpenSSL upstream.
>>
>> So yeah, I guess the recent irrelevance of this edk2-only hunk should
>> have been "obvious" from the 3000-line diff between OpenSSL 1.0.2e and
>> 1.0.2f -- a diff that no person not involved in day-to-day OpenSSL
>> development can review.
> 
> Actually, that isn't fixed in OpenSSL 1.0.2f; it's fixed only in 1.1
> and I've backported the fix.
> 
>>> Can we *please* keep native line endings in the git tree
>>
>> No, we can't. This issue has been discussed with Junio C Hamano, the git
>> maintainer. Git can convert text files to platform-native line endings
>> on checkout, but only if the internal (object) representation of the
>> text files is LF only.
>>
>> And, because edk2 started out with SVN, and the (now primary) git repo
>> started out as a mirror of the SVN repo, the internal representation is
>> CRLF, not LF. So git's auto-conversion doesn't apply.
> 
> Apologies, I misspoke. I didn't mean "native line endings in the git
> tree", which is obviously impossible — I meant "sane line endings in
> the git tree", which means LF — so git's auto-conversion *would* apply.
> 
>> Everyone else did not start with a git mirror of an SVN repo of text
>> files that were created and edited exclusively on Windows. :(
> 
> A poor excuse. It wasn't hard to fix up the SVN->git mirror, and we
> knew we needed to do this *long* before git actually became the
> "primary" system.
> 
> And even if we've missed the chance to do it "in retrospect" for
> historical commits in our canonical git repository, we could still make
> a commit now which *changes* the line endings to what git expects, and
> quite soon this whole nonsense would be a thing of the past.

Yes. I think that would take a commit that converted everything to
LF-only. Then everybody on Windows would have to toggle some git knobs,
correct? Would that be safe when moving between commits?

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

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

[David Woodhouse]

On Thu, 2016-02-18 at 13:14 +0100, Laszlo Ersek wrote:
> This patch seems right.

Please trim citations. You didn't have to cite the *entire* patch just
to say that it seems right!

You aren't one of the Outlook-afflicted. We need you to set an example
of how email is actually *supposed* to be used :)

> I also tried to diff the "openssl-1.0.2e" and "openssl-1.0.2f" trees
> against each other, to see if "no new source changes [...] introduced
> for 1.0.2f enabling" is indeed the right thing to do.
> 
> The result of that diffing is a 3000 line patch, with the following
> diffstat:
> 
>  144 files changed, 815 insertions(+), 476 deletions(-)

This is the 21st century. Nobody in their right mind deals with
software management except through git. More edifying would be to run:

 git log OpenSSL_1_0_2e..OpenSSL_1_0_2f  --stat

and/or

 gitk OpenSSL_1_0_2e..OpenSSL_1_0_2f

There are 60 commits. Browsing through them with gitk, they do mostly
seem like sane, simple bug fixes. Some are cosmetic but basically risk-
free, such as the example you gave — that commit touched 74 files, but
*only* in the comments, with fairly much zero chance of causing
problems.

> While I'm absolutely no crypto expert, I have a hard time believing
> that fixing the two major issues listed by the release notes required
> touching *144 files*!

There were plenty more issues fixed other than the "headline" issues.

> So, I hereby declare the OpenSSL updates practically un-review-able,
> even just for *scope* -- i.e., in order to see how far those changes
> extend. I also claim that the OpenSSL release strategy is not being
> implemented in reality -- the "letter releases" actually seem to be
> vulnerability-triggered *snapshots* of the 1.0.2 tree, where the code
> influx, albeit low volume, definitely meanders outside of bug and
> security fixes.

Yeah, there's a certain amount of truth in what you say. When a high-
priority vulnerability comes up, we need a new release and people need
to upgrade. If we fix a minor functionality issue which is fairly
esoteric and *doesn't* have security implications, there *isn't* an
immediate release the same day. We'd run out of letters very quickly if
we did that! :)

So yes, when the high-visibility issues trigger a release, a bunch of
less important fixes go along for the ride. I don't think that's a
problem.

But trust me — as someone who has occasionally wanted to get
improvements into a stable branch of OpenSSL when they have been
considered "new features" — when I say that they aren't adding whole
piles of exciting new stuff to the 1.0.2 branch :)

Take a look at the discussion about fixing ECDH for engines, on the
openssl-dev list at the moment. It would be fairly trivial to expose
what's necessary there, but because it's a new feature (although some
would want to consider a bug fix), the OpenSSL team really don't want
to do it.

> Now, one might ask why I care. I care because for some downstreams of
> edk2 at least, the situation that openssl has to be patched in before a
> secure boot enabled build is completely unacceptable. That makes it
> super-unwieldy to bisect a secure boot enabled build for example. It
> also requires all people who clone your tree to patch in OpenSSL
> manually.

Actually, in practice is *isn't* so bad. Given that we don't update our
EDKII_openssl-1.0.2X.patch very often (if at all) between OpenSSL
releases, what happens is that your build tree ends up with *multiple*
CryptoPkg/Library/OpensslLib/openssl-1.0.2[def] directories. And as you
flit back and forth between EDK2 commits in your bisect, you use the
different OpenSSL directories, as appropriate.

> Importing openssl should be a run-of-the-mill *commit* in the git
> history (and it is, for us).

Surely this is what git submodules are for?

> Then you can understand why I care about actual OpenSSL differences --
> because when the OpenSSL addition is an actual commit in your repo, the
> upgrade looks like this:
> 
> - revert the commit that captured the execution of the previous
>   Patch-HOWTO.txt
> - perform the current Patch-HOWTO.txt, commit the results as a new
>   commit
> - *squash* these two commits (unless you are happy with two, several MB
>   long patches -- good luck to your mailing list!)
> - now you have an incremental patch in your history that takes you from
>   1.0.2e to 1.0.2f
> 
> Except, of course, that patch is fully unreviewable -- it is
> no better than a binary-only code drop.

Again, not if it's done properly as a git submodule.

> Honestly, edk2 should either incorporate OpenSSL permanently, or build
> it 100% from an external, unmodified upstream tarball (I think this is
> what David has been working on, right?)

As noted yesterday, we're two trivial patches from being able to use
the next OpenSSL 1.1.0 beta snapshot "out of the box" with EDK2.

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

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

[David Woodhouse]

On Thu, 2016-02-18 at 13:40 +0100, Laszlo Ersek wrote:
> > We should not be carrying patches which *differ* from the fixes that
> > went into OpenSSL upstream.
> 
> So yeah, I guess the recent irrelevance of this edk2-only hunk should
> have been "obvious" from the 3000-line diff between OpenSSL 1.0.2e and
> 1.0.2f -- a diff that no person not involved in day-to-day OpenSSL
> development can review.

Actually, that isn't fixed in OpenSSL 1.0.2f; it's fixed only in 1.1
and I've backported the fix.

> > Can we *please* keep native line endings in the git tree
>
> No, we can't. This issue has been discussed with Junio C Hamano, the git
> maintainer. Git can convert text files to platform-native line endings
> on checkout, but only if the internal (object) representation of the
> text files is LF only.
> 
> And, because edk2 started out with SVN, and the (now primary) git repo
> started out as a mirror of the SVN repo, the internal representation is
> CRLF, not LF. So git's auto-conversion doesn't apply.

Apologies, I misspoke. I didn't mean "native line endings in the git
tree", which is obviously impossible — I meant "sane line endings in
the git tree", which means LF — so git's auto-conversion *would* apply.

> Everyone else did not start with a git mirror of an SVN repo of text
> files that were created and edited exclusively on Windows. :(

A poor excuse. It wasn't hard to fix up the SVN->git mirror, and we
knew we needed to do this *long* before git actually became the
"primary" system.

And even if we've missed the chance to do it "in retrospect" for
historical commits in our canonical git repository, we could still make
a commit now which *changes* the line endings to what git expects, and
quite soon this whole nonsense would be a thing of the past.

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



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

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

[Laszlo Ersek]

tangent:

On 02/18/16 13:40, Laszlo Ersek wrote:

> https://github.com/lersek/edk2/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#maint-07

> https://github.com/lersek/edk2/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05

Sigh. Clearly I pasted the wrong link from my browser's history. The
correct link, into the tianocore wiki, is

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

Sorry about the noise.

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

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

[Laszlo Ersek]

On 02/18/16 12:40, David Woodhouse wrote:
> On Thu, 2016-02-18 at 00:33 +0800, Qin Long wrote:
>>
>>  crypto/pkcs7/pk7_smime.c   Thu Jun 11 21:01:06 2015
>> -+++ crypto/pkcs7/pk7_smime.c   Fri Jun 12 11:23:38 2015
>> +--- crypto/pkcs7/pk7_smime.c   Thu Jan 28 21:56:08 2016
>>  crypto/pkcs7/pk7_smime.c   Wed Feb 17 16:22:45 2016
>>  @@ -254,7 +254,8 @@
>>   STACK_OF(PKCS7_SIGNER_INFO) *sinfos;
>>   PKCS7_SIGNER_INFO *si;
>> @@ -114,20 +114,19 @@ diff U3 crypto/pkcs7/pk7_smime.c
>> crypto/pkcs7/pk7_smime.c
>>   if (i <= 0)
>>   break;
>>   if (tmpout)
>> -@@ -394,6 +394,10 @@
>> +@@ -394,6 +394,9 @@
>>   }
>>   BIO_free_all(p7bio);
>>   sk_X509_free(signers);
>> -+
>>  +if (buf != NULL) {
>> -+  OPENSSL_free(buf);
>> ++OPENSSL_free(buf);
>>  +}
>>   return ret;
>>   }
>>  
> 
> This bit of code addresses OpenSSL RT#3955, although you don't actually
> *mention* that fact anywhere. A different fix has been committed to
> OpenSSL to close that RT.
> 
> We should not be carrying patches which *differ* from the fixes that
> went into OpenSSL upstream.

So yeah, I guess the recent irrelevance of this edk2-only hunk should
have been "obvious" from the 3000-line diff between OpenSSL 1.0.2e and
1.0.2f -- a diff that no person not involved in day-to-day OpenSSL
development can review.

> 
> That's why part of my patch series (qv) actually *replaces* this whole
> EDKII_openssl-1.0.2X.patch with a cleanly generated one from a 1.0.2-
> based git tree, *with* its full changelog:
> 
> http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/cf8dd4aee409

Yes, it mentions

  RT3955: Reduce stack usage in PKCS7_verify() and PKCS7_decrypt()

> I mention this just to reinforce the need for that change, even before
> we make the switch to OpenSSL 1.1.
> 
> FWIW I was unable to apply the patch from your email; if there was ever
> a trick to managing the bogus line endings, I've forgotten it.

There are four tricks:
(a) use git-am with --keep-cr
(b) the above will not work if the patch email that you save from the
list uses plaintext content encoding, *and* creates or deletes files
-- in that case, /dev/null\r\n hunk headers will be present, and
those will trip up git. So, the second option is: patch git itself.
(c) as contributor, send the email with a non-plaintext content
encoding. Paolo got some patches for this into upstream git at some
point.
(d) As contributor, push your changes to a public repo, and include
the branch URL in the posting -- then reviewers can fetch the patch
intact.

See also

https://github.com/lersek/edk2/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#maint-07

(Note that the git-am command given there doesn't spell out --keep-cr --
because at that point it's been set permanently:
.)

> Can we
> *please* keep native line endings in the git tree

No, we can't. This issue has been discussed with Junio C Hamano, the git
maintainer. Git can convert text files to platform-native line endings
on checkout, but only if the internal (object) representation of the
text files is LF only.

And, because edk2 started out with SVN, and the (now primary) git repo
started out as a mirror of the SVN repo, the internal representation is
CRLF, not LF. So git's auto-conversion doesn't apply.

(This is also the reason for my

  core.whitespace = cr-at-eol

setting in

-- because otherwise git diff & friends will yell at you constantly, for
"\r" as line-trailing whitespace.)

> and let it be checked
> out into the native form — like everyone else does?

Everyone else did not start with a git mirror of an SVN repo of text
files that were created and edited exclusively on Windows. :(

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] ArmVirtPkg: ArmVirtQemu: disable PropertiesTable memory protection feature

[Ard Biesheuvel]

On 18 February 2016 at 13:17, Laszlo Ersek  wrote:
> On 02/18/16 12:56, Ard Biesheuvel wrote:
>> The PropertiesTable feature is poorly named, since the feature this PCD
>> controls is only a single bit in its MemoryProtectionAttribute member,
>> called EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA.
>>
>> This feature causes breakage on legacy OSes that assume that each memory
>> region in the UEFI memory map is completely independent, which is no longer
>> the case with this feature enabled. For this reason, the UEFI spec now
>> recommends not to use this feature, and use the MemoryAttributes table
>> instead. For this reason, support for the feature will not be implemented
>> in arm64 or ARM Linux, and enabling it here is pointless.
>>
>> So set PcdPropertiesTableEnable to FALSE.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmVirtPkg/ArmVirtQemu.dsc | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index e2641fd2c289..7ff1bd4074a8 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -162,6 +162,18 @@ [PcdsFixedAtBuild.common]
>>#
>>gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16
>>
>> +  # The PropertiesTable feature is poorly named, since the feature this PCD
>> +  # controls is only a single bit in its MemoryProtectionAttribute member,
>> +  # called EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA.
>> +  #
>> +  # This feature causes breakage on legacy OSes that assume that each memory
>> +  # region in the UEFI memory map is completely independent, which is no 
>> longer
>> +  # the case with this feature enabled. For this reason, the UEFI spec now
>> +  # recommends not to use this feature, and use the MemoryAttributes table
>> +  # instead. For this reason, support for the feature will not be 
>> implemented in
>> +  # arm64 or ARM Linux, and enabling it here is pointless.
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
>> +
>>  [PcdsFixedAtBuild.AARCH64]
>>gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
>>
>>
>
> You reviewed Jiewen's patch:
>
>   MdePkg: Change PcdPropertiesTableEnable default value to FALSE
>   http://thread.gmane.org/gmane.comp.bios.edk2.devel/7681
>
> So why is this necessary? Isn't it enough to inherit the FALSE default
> from "MdeModulePkg/MdeModulePkg.dec"?
>

Yes, it is. That completely slipped my mind, and I still noticed the
PROP= entry in the kernel boot log next to the MEMATTR= entry that I
am adding atm.

So indeed, please disregard.

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

Re: [edk2] [PATCH] ArmVirtPkg: ArmVirtQemu: disable PropertiesTable memory protection feature

[Laszlo Ersek]

On 02/18/16 12:56, Ard Biesheuvel wrote:
> The PropertiesTable feature is poorly named, since the feature this PCD
> controls is only a single bit in its MemoryProtectionAttribute member,
> called EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA.
> 
> This feature causes breakage on legacy OSes that assume that each memory
> region in the UEFI memory map is completely independent, which is no longer
> the case with this feature enabled. For this reason, the UEFI spec now
> recommends not to use this feature, and use the MemoryAttributes table
> instead. For this reason, support for the feature will not be implemented
> in arm64 or ARM Linux, and enabling it here is pointless.
> 
> So set PcdPropertiesTableEnable to FALSE.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirtQemu.dsc | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index e2641fd2c289..7ff1bd4074a8 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -162,6 +162,18 @@ [PcdsFixedAtBuild.common]
>#
>gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16
>  
> +  # The PropertiesTable feature is poorly named, since the feature this PCD
> +  # controls is only a single bit in its MemoryProtectionAttribute member,
> +  # called EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA.
> +  #
> +  # This feature causes breakage on legacy OSes that assume that each memory
> +  # region in the UEFI memory map is completely independent, which is no 
> longer
> +  # the case with this feature enabled. For this reason, the UEFI spec now
> +  # recommends not to use this feature, and use the MemoryAttributes table
> +  # instead. For this reason, support for the feature will not be 
> implemented in
> +  # arm64 or ARM Linux, and enabling it here is pointless.
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
> +
>  [PcdsFixedAtBuild.AARCH64]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
>  
> 

You reviewed Jiewen's patch:

  MdePkg: Change PcdPropertiesTableEnable default value to FALSE
  http://thread.gmane.org/gmane.comp.bios.edk2.devel/7681

So why is this necessary? Isn't it enough to inherit the FALSE default
from "MdeModulePkg/MdeModulePkg.dec"?

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

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

[Laszlo Ersek]

On 02/17/16 17:33, Qin Long wrote:
> OpenSSL has released version 1.0.2f with two security fixes
> (http://www.openssl.org/news/secadv/20160128.txt) at 28-Jan-2016.
> Upgrade the supported OpenSSL version in CryptoPkg/OpensslLib
> to catch the latest release 1.0.2f.
> (NOTE: The patch file was just re-generated, and no new source
>changes was introduced for 1.0.2f enabling)
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qin Long 
> CC: Ting Ye 
> ---
>  ...ssl-1.0.2e.patch => EDKII_openssl-1.0.2f.patch} | 63 
> +++---
>  CryptoPkg/Library/OpensslLib/Install.cmd   |  2 +-
>  CryptoPkg/Library/OpensslLib/Install.sh|  2 +-
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf|  4 +-
>  CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt   | 26 -
>  5 files changed, 48 insertions(+), 49 deletions(-)
>  rename CryptoPkg/Library/OpensslLib/{EDKII_openssl-1.0.2e.patch => 
> EDKII_openssl-1.0.2f.patch} (89%)
> 
> diff --git a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch 
> b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
> similarity index 89%
> rename from CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch
> rename to CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
> index e4eaff6..c42b776 100644
> --- a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2e.patch
> +++ b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
> @@ -1,7 +1,7 @@
>  diff U3 crypto/bio/bio.h crypto/bio/bio.h
>  crypto/bio/bio.h Thu Jun 11 21:50:12 2015
> -+++ crypto/bio/bio.h Fri Jun 12 11:00:52 2015
> -@@ -646,10 +646,10 @@
> +--- crypto/bio/bio.h Thu Jan 28 21:56:08 2016
>  crypto/bio/bio.h Wed Feb 17 16:43:40 2016
> +@@ -650,10 +650,10 @@
>   int BIO_asn1_get_suffix(BIO *b, asn1_ps_func **psuffix,
>   asn1_ps_func **psuffix_free);
>   
> @@ -14,8 +14,8 @@ diff U3 crypto/bio/bio.h crypto/bio/bio.h
>   # endif
>   BIO *BIO_new(BIO_METHOD *type);
>  diff U3 crypto/bio/bss_file.c crypto/bio/bss_file.c
>  crypto/bio/bss_file.cThu Jun 11 21:01:06 2015
> -+++ crypto/bio/bss_file.cFri Jun 12 11:01:28 2015
> +--- crypto/bio/bss_file.cThu Jan 28 21:38:30 2016
>  crypto/bio/bss_file.cWed Feb 17 16:01:02 2016
>  @@ -467,6 +467,23 @@
>   return (ret);
>   }
> @@ -41,8 +41,8 @@ diff U3 crypto/bio/bss_file.c crypto/bio/bss_file.c
>   
>   #endif  /* HEADER_BSS_FILE_C */
>  diff U3 crypto/dh/dh_pmeth.c crypto/dh/dh_pmeth.c
>  crypto/dh/dh_pmeth.c Thu Jun 11 21:50:12 2015
> -+++ crypto/dh/dh_pmeth.c Fri Jun 12 11:08:48 2015
> +--- crypto/dh/dh_pmeth.c Thu Jan 28 21:56:08 2016
>  crypto/dh/dh_pmeth.c Wed Feb 17 16:15:58 2016
>  @@ -449,6 +449,9 @@
>   *keylen = ret;
>   return 1;
> @@ -62,8 +62,8 @@ diff U3 crypto/dh/dh_pmeth.c crypto/dh/dh_pmeth.c
>   return 1;
>   }
>  diff U3 crypto/pem/pem.h crypto/pem/pem.h
>  crypto/pem/pem.h Thu Jun 11 21:50:12 2015
> -+++ crypto/pem/pem.h Fri Jun 12 10:58:18 2015
> +--- crypto/pem/pem.h Thu Jan 28 21:56:08 2016
>  crypto/pem/pem.h Wed Feb 17 15:56:26 2016
>  @@ -324,6 +324,7 @@
>   
>   #  define DECLARE_PEM_read_fp(name, type) /**/
> @@ -73,8 +73,8 @@ diff U3 crypto/pem/pem.h crypto/pem/pem.h
>   # else
>   
>  diff U3 crypto/pkcs7/pk7_smime.c crypto/pkcs7/pk7_smime.c
>  crypto/pkcs7/pk7_smime.c Thu Jun 11 21:01:06 2015
> -+++ crypto/pkcs7/pk7_smime.c Fri Jun 12 11:23:38 2015
> +--- crypto/pkcs7/pk7_smime.c Thu Jan 28 21:56:08 2016
>  crypto/pkcs7/pk7_smime.c Wed Feb 17 16:22:45 2016
>  @@ -254,7 +254,8 @@
>   STACK_OF(PKCS7_SIGNER_INFO) *sinfos;
>   PKCS7_SIGNER_INFO *si;
> @@ -114,20 +114,19 @@ diff U3 crypto/pkcs7/pk7_smime.c 
> crypto/pkcs7/pk7_smime.c
>   if (i <= 0)
>   break;
>   if (tmpout)
> -@@ -394,6 +394,10 @@
> +@@ -394,6 +394,9 @@
>   }
>   BIO_free_all(p7bio);
>   sk_X509_free(signers);
> -+
>  +if (buf != NULL) {
> -+  OPENSSL_free(buf);
> ++OPENSSL_free(buf);
>  +}
>   return ret;
>   }
>   
>  diff U3 crypto/rand/rand_unix.c crypto/rand/rand_unix.c
>  crypto/rand/rand_unix.c  Thu Jun 11 21:01:06 2015
> -+++ crypto/rand/rand_unix.c  Fri Jun 12 10:51:21 2015
> +--- crypto/rand/rand_unix.c  Thu Jan 28 21:38:32 2016
>  crypto/rand/rand_unix.c  Wed Feb 17 15:40:02 2016
>  @@ -116,7 +116,7 @@
>   #include 
>   #include "rand_lcl.h"
> @@ -147,8 +146,8 @@ diff U3 crypto/rand/rand_unix.c crypto/rand/rand_unix.c
>   {
>   return 0;
>  diff U3 crypto/rsa/rsa_ameth.c crypto/rsa/rsa_ameth.c
>  crypto/rsa/rsa_ameth.c   Thu Jun 11 21:50:12 2015
> -+++ crypto/rsa/rsa_ameth.c   Fri Jun 12 10:45:38 2015
> +--- crypto/rsa/rsa_ameth.c   Thu Jan 28 21:56:08 2016
>  crypto/rsa/rsa_ameth.c   Wed Feb 17 15:09:46 2016
>  @@ -68,10 +68,12 @@
>   #endif
>   #include "asn1_locl.h"
> @@ -221,8 +220,8 @@ diff U3 crypto/rsa/rsa_ameth.c 

Re: [edk2] [PATCH] Ax88772b: Fixing compilation error variable set but not used

[Ryan Harkin]

On 10 February 2016 at 14:07, Shivamurthy Shastri
 wrote:
> error: pNicDevice variable set but not used
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shivamurthy Shastri 

Whilst I don't use this, I can see the variable is indeed set but not used.

Reviewed-by: Ryan Harkin 

> ---
>  OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c 
> b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
> index 9eeb61f..c061a6b 100644
> --- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
> +++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
> @@ -700,10 +700,8 @@ SN_ReceiveFilters (
>EFI_SIMPLE_NETWORK_MODE * pMode;
>EFI_STATUS Status = EFI_SUCCESS;
>EFI_TPL TplPrevious;
> -  NIC_DEVICE * pNicDevice;
>
>TplPrevious = gBS->RaiseTPL(TPL_CALLBACK);
> -  pNicDevice = DEV_FROM_SIMPLE_NETWORK ( pSimpleNetwork );
>pMode = pSimpleNetwork->Mode;
>
>if (pSimpleNetwork == NULL) {
> --
> 1.9.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ArmVirtPkg: ArmVirtQemu: disable PropertiesTable memory protection feature

[Ard Biesheuvel]

The PropertiesTable feature is poorly named, since the feature this PCD
controls is only a single bit in its MemoryProtectionAttribute member,
called EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA.

This feature causes breakage on legacy OSes that assume that each memory
region in the UEFI memory map is completely independent, which is no longer
the case with this feature enabled. For this reason, the UEFI spec now
recommends not to use this feature, and use the MemoryAttributes table
instead. For this reason, support for the feature will not be implemented
in arm64 or ARM Linux, and enabling it here is pointless.

So set PcdPropertiesTableEnable to FALSE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirtQemu.dsc | 12 
 1 file changed, 12 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index e2641fd2c289..7ff1bd4074a8 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -162,6 +162,18 @@ [PcdsFixedAtBuild.common]
   #
   gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16
 
+  # The PropertiesTable feature is poorly named, since the feature this PCD
+  # controls is only a single bit in its MemoryProtectionAttribute member,
+  # called EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA.
+  #
+  # This feature causes breakage on legacy OSes that assume that each memory
+  # region in the UEFI memory map is completely independent, which is no longer
+  # the case with this feature enabled. For this reason, the UEFI spec now
+  # recommends not to use this feature, and use the MemoryAttributes table
+  # instead. For this reason, support for the feature will not be implemented 
in
+  # arm64 or ARM Linux, and enabling it here is pointless.
+  gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
+
 [PcdsFixedAtBuild.AARCH64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
 
-- 
2.5.0

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

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

[David Woodhouse]

On Thu, 2016-02-18 at 00:33 +0800, Qin Long wrote:
> 
>  crypto/pkcs7/pk7_smime.c   Thu Jun 11 21:01:06 2015
> -+++ crypto/pkcs7/pk7_smime.c   Fri Jun 12 11:23:38 2015
> +--- crypto/pkcs7/pk7_smime.c   Thu Jan 28 21:56:08 2016
>  crypto/pkcs7/pk7_smime.c   Wed Feb 17 16:22:45 2016
>  @@ -254,7 +254,8 @@
>   STACK_OF(PKCS7_SIGNER_INFO) *sinfos;
>   PKCS7_SIGNER_INFO *si;
> @@ -114,20 +114,19 @@ diff U3 crypto/pkcs7/pk7_smime.c
> crypto/pkcs7/pk7_smime.c
>   if (i <= 0)
>   break;
>   if (tmpout)
> -@@ -394,6 +394,10 @@
> +@@ -394,6 +394,9 @@
>   }
>   BIO_free_all(p7bio);
>   sk_X509_free(signers);
> -+
>  +    if (buf != NULL) {
> -+  OPENSSL_free(buf);
> ++    OPENSSL_free(buf);
>  +    }
>   return ret;
>   }
>  

This bit of code addresses OpenSSL RT#3955, although you don't actually
*mention* that fact anywhere. A different fix has been committed to
OpenSSL to close that RT.

We should not be carrying patches which *differ* from the fixes that
went into OpenSSL upstream.

That's why part of my patch series (qv) actually *replaces* this whole
EDKII_openssl-1.0.2X.patch with a cleanly generated one from a 1.0.2-
based git tree, *with* its full changelog:

http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/cf8dd4aee409

I mention this just to reinforce the need for that change, even before
we make the switch to OpenSSL 1.1.

FWIW I was unable to apply the patch from your email; if there was ever
a trick to managing the bogus line endings, I've forgotten it. Can we
*please* keep native line endings in the git tree and let it be checked
out into the native form — like everyone else does?

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





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

Re: [edk2] Fwd: [PATCH] Ax88772b: Workaround access to RXQTC register with Apple Ethernet Adapter

[Laszlo Ersek]

On 02/18/16 12:21, Shivamurthy Shastri wrote:
> Hi All,
> 
> Please let me know your opinion about this patch.

The subject of your patch doesn't identify the top-level package that
the patch touches: OptionRomPkg.

You also didn't CC the maintainer(s) of OptionRomPkg on your posting
(see "Maintainers.txt"):

OptionRomPkg
W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
M: Ruiyu Ni 

CC'ing Ray now.

Thanks
Laszlo

> 
> --
> 
> Thanks and Regards,
> 
> Shivamurthy Shastri,
> 
> M: +919742508553, IRC: shiva_murthy,
> *Linaro.org* |Open Source Software for ARM SOCs
> 
> 
> -- Forwarded message --
> From: Shivamurthy Shastri 
> Date: 10 February 2016 at 19:42
> Subject: [edk2] [PATCH] Ax88772b: Workaround access to RXQTC register with
> Apple Ethernet Adapter
> To: edk2-devel@lists.01.org
> Cc: fathi.bou...@linaro.org, Shivamurthy Shastri <
> shivamurthy.shas...@linaro.org>
> 
> 
> The USB command CMD_RXQTC ("RX Queue Cascade Threshold Control") tries
> to access the register and is always failing when using the Apple
> Ethernet adapter.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shivamurthy Shastri 
> ---
>  .../Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c   | 15 +
>  .../Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h   |  2 ++
>  .../Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c | 39
> ++
>  3 files changed, 50 insertions(+), 6 deletions(-)
> 
> diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c
> b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c
> index 45ba3e5..b3fefb1 100644
> --- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c
> +++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c
> @@ -625,15 +625,18 @@ Ax88772Reset (
> 
>if (EFI_ERROR(Status)) goto err;
> 
> -  SetupMsg.RequestType = USB_REQ_TYPE_VENDOR
> +  if (pNicDevice->Flags != FLAG_TYPE_AX88772) {
> +   SetupMsg.RequestType = USB_REQ_TYPE_VENDOR
>  | USB_TARGET_DEVICE;
> -  SetupMsg.Request = CMD_RXQTC;
> -  SetupMsg.Value = 0x8000;
> -  SetupMsg.Index = 0x8001;
> -  SetupMsg.Length = 0;
> -  Status = Ax88772UsbCommand ( pNicDevice,
> +   SetupMsg.Request = CMD_RXQTC;
> +   SetupMsg.Value = 0x8000;
> +   SetupMsg.Index = 0x8001;
> +   SetupMsg.Length = 0;
> +   Status = Ax88772UsbCommand ( pNicDevice,
>,
>NULL );
> +  }
> +
>  err:
>return Status;
>  }
> diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
> b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
> index 816f2b2..a85c998 100644
> --- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
> +++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
> @@ -407,6 +407,8 @@ typedef struct {
>RX_PKT * pFirstFill;
>UINTN   PktCntInQueue;
>UINT8 * pBulkInBuff;
> +
> +  INT32 Flags;
> 
>  } NIC_DEVICE;
> 
> diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
> b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
> index 6a10cbf..46a2ef9 100644
> --- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
> +++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
> @@ -124,6 +124,8 @@ DriverStart (
> UINTN
>  LengthInBytes;
> EFI_DEVICE_PATH_PROTOCOL*ParentDevicePath = NULL;
> MAC_ADDR_DEVICE_PATHMacDeviceNode;
> +   EFI_USB_DEVICE_DESCRIPTOR   Device;
> +   UINT32 i;
> 
>//
> //  Allocate the device structure
> @@ -178,6 +180,43 @@ DriverStart (
>   goto EXIT;
>}
> 
> +Status = pNicDevice->pUsbIo->UsbGetDeviceDescriptor (
> pNicDevice->pUsbIo,  );
> +if (EFI_ERROR ( Status )) {
> +gBS->CloseProtocol (
> +Controller,
> +,
> +pThis->DriverBindingHandle,
> +Controller
> +);
> +  gBS->FreePool ( pNicDevice );
> + goto EXIT;
> +}
> +else {
> +  //
> +  //  Validate the adapter
> +  //
> +  for (i = 0; ASIX_DONGLES[i].VendorId != 0; i++) {
> +   if (ASIX_DONGLES[i].VendorId == Device.IdVendor &&
> +   ASIX_DONGLES[i].ProductId == Device.IdProduct) {
> + break;
> +   }
> +   }
> +
> +   if (ASIX_DONGLES[i].VendorId == 0) {
> +gBS->CloseProtocol (
> +Controller,
> +,
> +pThis->DriverBindingHandle,
> +Controller
> +);
> +  

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

[Laszlo Ersek]

On 02/18/16 12:20, David Woodhouse wrote:
> On Thu, 2016-02-18 at 09:50 +0100, Laszlo Ersek wrote:
>> On 02/18/16 09:44, Long, Qin wrote:
>>> Thanks for raising this, Laszlo.
>>>  
>>> Exactly, the posted patch series from David also included one
>> 1.0.2f enabling. The patch series will bring one direct / smooth
>> supports for EDKII-CryptoPkg with some patch integration in both
>> EDKII and OpenSSL sides, and also introduce some source generation
>> mechanism for more native build support. 
>>>  
>>> I will work on more validations based on David's post, and also
>> work with David on other possible updates (e.g. include file issue).
>> This may need some extra times.
>>>  
>>> Before all patches were integrated, my plan is to have one 1.0.2f
>> upgrade firstly based on my last patch, which will not change any
>> build process, and just to catch the latest release for some
>> requirements. 
>>>  
>>> (David, apology for my late feedback to your patch post.)
>>>  
>>> Let me know if any concerns. 
>>
>> Works for me if it works for David.
> 
> Yeah, that's fine. I'm happy to rebase my tree and put the upgrade to
> 1.0.2f first.

Thank you for confirming -- consider my NACK rescinded.

> Although I *did* like having "it's easy now..." as the commit comment.
> 
> That exercise has highlighted one more potential improvement — the
> upgrade from 1.0.2e to 1.0.2f did require changing about 18 instances
> of the string "1.0.2e" to "1.0.2f". I'll see if I can cut that down.

Thanks!
Laszlo

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

[edk2] Fwd: [PATCH] Ax88772b: Workaround access to RXQTC register with Apple Ethernet Adapter

[Shivamurthy Shastri]

Hi All,

Please let me know your opinion about this patch.

--

Thanks and Regards,

Shivamurthy Shastri,

M: +919742508553, IRC: shiva_murthy,
*Linaro.org* |Open Source Software for ARM SOCs


-- Forwarded message --
From: Shivamurthy Shastri 
Date: 10 February 2016 at 19:42
Subject: [edk2] [PATCH] Ax88772b: Workaround access to RXQTC register with
Apple Ethernet Adapter
To: edk2-devel@lists.01.org
Cc: fathi.bou...@linaro.org, Shivamurthy Shastri <
shivamurthy.shas...@linaro.org>


The USB command CMD_RXQTC ("RX Queue Cascade Threshold Control") tries
to access the register and is always failing when using the Apple
Ethernet adapter.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shivamurthy Shastri 
---
 .../Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c   | 15 +
 .../Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h   |  2 ++
 .../Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c | 39
++
 3 files changed, 50 insertions(+), 6 deletions(-)

diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c
b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c
index 45ba3e5..b3fefb1 100644
--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c
+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.c
@@ -625,15 +625,18 @@ Ax88772Reset (

   if (EFI_ERROR(Status)) goto err;

-  SetupMsg.RequestType = USB_REQ_TYPE_VENDOR
+  if (pNicDevice->Flags != FLAG_TYPE_AX88772) {
+   SetupMsg.RequestType = USB_REQ_TYPE_VENDOR
 | USB_TARGET_DEVICE;
-  SetupMsg.Request = CMD_RXQTC;
-  SetupMsg.Value = 0x8000;
-  SetupMsg.Index = 0x8001;
-  SetupMsg.Length = 0;
-  Status = Ax88772UsbCommand ( pNicDevice,
+   SetupMsg.Request = CMD_RXQTC;
+   SetupMsg.Value = 0x8000;
+   SetupMsg.Index = 0x8001;
+   SetupMsg.Length = 0;
+   Status = Ax88772UsbCommand ( pNicDevice,
   ,
   NULL );
+  }
+
 err:
   return Status;
 }
diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
index 816f2b2..a85c998 100644
--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
@@ -407,6 +407,8 @@ typedef struct {
   RX_PKT * pFirstFill;
   UINTN   PktCntInQueue;
   UINT8 * pBulkInBuff;
+
+  INT32 Flags;

 } NIC_DEVICE;

diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
index 6a10cbf..46a2ef9 100644
--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
@@ -124,6 +124,8 @@ DriverStart (
UINTN
 LengthInBytes;
EFI_DEVICE_PATH_PROTOCOL*ParentDevicePath = NULL;
MAC_ADDR_DEVICE_PATHMacDeviceNode;
+   EFI_USB_DEVICE_DESCRIPTOR   Device;
+   UINT32 i;

   //
//  Allocate the device structure
@@ -178,6 +180,43 @@ DriverStart (
  goto EXIT;
   }

+Status = pNicDevice->pUsbIo->UsbGetDeviceDescriptor (
pNicDevice->pUsbIo,  );
+if (EFI_ERROR ( Status )) {
+gBS->CloseProtocol (
+Controller,
+,
+pThis->DriverBindingHandle,
+Controller
+);
+  gBS->FreePool ( pNicDevice );
+ goto EXIT;
+}
+else {
+  //
+  //  Validate the adapter
+  //
+  for (i = 0; ASIX_DONGLES[i].VendorId != 0; i++) {
+   if (ASIX_DONGLES[i].VendorId == Device.IdVendor &&
+   ASIX_DONGLES[i].ProductId == Device.IdProduct) {
+ break;
+   }
+   }
+
+   if (ASIX_DONGLES[i].VendorId == 0) {
+gBS->CloseProtocol (
+Controller,
+,
+pThis->DriverBindingHandle,
+Controller
+);
+  gBS->FreePool ( pNicDevice );
+ goto EXIT;
+   }
+
+   pNicDevice->Flags = ASIX_DONGLES[i].Flags;
+}
+
+
//
   // Set Device Path
   //
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[David Woodhouse]

On Thu, 2016-02-18 at 09:50 +0100, Laszlo Ersek wrote:
> On 02/18/16 09:44, Long, Qin wrote:
> > Thanks for raising this, Laszlo.
> > 
> > Exactly, the posted patch series from David also included one
> 1.0.2f enabling. The patch series will bring one direct / smooth
> supports for EDKII-CryptoPkg with some patch integration in both
> EDKII and OpenSSL sides, and also introduce some source generation
> mechanism for more native build support. 
> > 
> > I will work on more validations based on David's post, and also
> work with David on other possible updates (e.g. include file issue).
> This may need some extra times.
> > 
> > Before all patches were integrated, my plan is to have one 1.0.2f
> upgrade firstly based on my last patch, which will not change any
> build process, and just to catch the latest release for some
> requirements. 
> > 
> > (David, apology for my late feedback to your patch post.)
> > 
> > Let me know if any concerns. 
> 
> Works for me if it works for David.

Yeah, that's fine. I'm happy to rebase my tree and put the upgrade to
1.0.2f first.

Although I *did* like having "it's easy now..." as the commit comment.

That exercise has highlighted one more potential improvement — the
upgrade from 1.0.2e to 1.0.2f did require changing about 18 instances
of the string "1.0.2e" to "1.0.2f". I'll see if I can cut that down.

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



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

[edk2] Fwd: [PATCH] Ax88772b: support for multiple dongles and chips

[Shivamurthy Shastri]

Hi All,

Please let me know your opinion about this patch.

--

Thanks and Regards,

Shivamurthy Shastri,

M: +919742508553, IRC: shiva_murthy,
*Linaro.org* |Open Source Software for ARM SOCs


-- Forwarded message --
From: Shivamurthy Shastri 
Date: 10 February 2016 at 19:40
Subject: [edk2] [PATCH] Ax88772b: support for multiple dongles and chips
To: edk2-devel@lists.01.org
Cc: fathi.bou...@linaro.org, Shivamurthy Shastri <
shivamurthy.shas...@linaro.org>


Driver code is modified to support multiple ethernet dongles, which uses
similar ASIX chips. Also, it can be used for multiple ASIX chips with
similar register map.

Enabled support for Apple Ethernet Adapter

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shivamurthy Shastri 
---
 .../Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h   | 13 -
 .../Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c | 33
+-
 2 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
index ab75ec2..816f2b2 100644
--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
@@ -297,12 +297,23 @@
 #define AN_10_HDX   0x0020  ///<  1 = 10BASE-T support
 #define AN_CSMA_CD  0x0001  ///<  1 = IEEE 802.3
CSMA/CD support

-
+/* asix_flags defines */
+#define FLAG_NONE   0
+#define FLAG_TYPE_AX88172   (1U << 0)
+#define FLAG_TYPE_AX88772   (1U << 1)
+#define FLAG_TYPE_AX88772B  (1U << 2)
+#define FLAG_EEPROM_MAC (1U << 3) /* initial mac address in eeprom
*/

 
//--
 //  Data Types
 
//--

+struct ASIX_DONGLE {
+   UINT16  VendorId;
+   UINT16  ProductId;
+   INT32   Flags;
+};
+
 /**
   Ethernet header layout

diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
index 3b73040..6a10cbf 100644
--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
@@ -14,6 +14,13 @@

 #include "Ax88772.h"

+struct ASIX_DONGLE ASIX_DONGLES[] = {
+{ 0x05AC, 0x1402, FLAG_TYPE_AX88772 }, /* Apple USB Ethernet
Adapter */
+/* ASIX 88772B */
+{ 0x0B95, 0x772B, FLAG_TYPE_AX88772B | FLAG_EEPROM_MAC },
+{ 0x, 0x, FLAG_NONE }   /* END - Do not remove */
+};
+
 /**
   Verify the controller type

@@ -36,6 +43,8 @@ DriverSupported (
   EFI_USB_DEVICE_DESCRIPTOR Device;
   EFI_USB_IO_PROTOCOL * pUsbIo;
   EFI_STATUS Status;
+  UINT32 i;
+
   //
   //  Connect to the USB stack
   //
@@ -60,19 +69,17 @@ DriverSupported (
 else {
   //
   //  Validate the adapter
-  //
-  if ( VENDOR_ID == Device.IdVendor ) {
-
-if (PRODUCT_ID == Device.IdProduct) {
-DEBUG ((EFI_D_INFO, "Found the AX88772B\r\n"));
-}
-   else  {
-Status = EFI_UNSUPPORTED;
-   }
-  }
-   else {
- Status = EFI_UNSUPPORTED;
-   }
+  //
+  for (i = 0; ASIX_DONGLES[i].VendorId != 0; i++) {
+   if (ASIX_DONGLES[i].VendorId == Device.IdVendor &&
+   ASIX_DONGLES[i].ProductId == Device.IdProduct) {
+ DEBUG ((EFI_D_INFO, "Found the AX88772B\r\n"));
+ break;
+   }
+   }
+
+   if (ASIX_DONGLES[i].VendorId == 0)
+   Status = EFI_UNSUPPORTED;
 }

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

[edk2] Fwd: [PATCH] Ax88772b: Fixing compilation error variable set but not used

[Shivamurthy Shastri]

Hi All,

Please let me know your opinion about this patch.

--

Thanks and Regards,

Shivamurthy Shastri,

M: +919742508553, IRC: shiva_murthy,
*Linaro.org* |Open Source Software for ARM SOCs


-- Forwarded message --
From: Shivamurthy Shastri 
Date: 10 February 2016 at 19:37
Subject: [edk2] [PATCH] Ax88772b: Fixing compilation error variable set but
not used
To: edk2-devel@lists.01.org
Cc: fathi.bou...@linaro.org, Shivamurthy Shastri <
shivamurthy.shas...@linaro.org>


error: pNicDevice variable set but not used

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shivamurthy Shastri 
---
 OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
index 9eeb61f..c061a6b 100644
--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
@@ -700,10 +700,8 @@ SN_ReceiveFilters (
   EFI_SIMPLE_NETWORK_MODE * pMode;
   EFI_STATUS Status = EFI_SUCCESS;
   EFI_TPL TplPrevious;
-  NIC_DEVICE * pNicDevice;

   TplPrevious = gBS->RaiseTPL(TPL_CALLBACK);
-  pNicDevice = DEV_FROM_SIMPLE_NETWORK ( pSimpleNetwork );
   pMode = pSimpleNetwork->Mode;

   if (pSimpleNetwork == NULL) {
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel