Re: [edk2] [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver

[Ni, Ruiyu]

Mike,
Please check the updated PciSioSerialDxe driver and verify whether it can 
replace the Quark version UART driver. Several changes were made:
1. Change the PCD structure layout
2. Change the SerialPortReadRegister function name to avoid linking error when 
using DebugLibSerialPort
3. Support up to 921600 baud rate, and use the actual baud rate (same algorithm 
as Quark version UART driver)
4. Flush Tx FIFO when reset or change the configuration of UART

Regards,
Ray


-Original Message-
From: Kinney, Michael D 
Sent: Friday, December 4, 2015 9:00 AM
To: Tian, Feng ; Ni, Ruiyu ; Kinney, 
Michael D 
Cc: edk2-devel@lists.01.org
Subject: RE: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver

Ray,

I tried to build this module into a platform, and I am getting function name 
collisions with BaseSerialPortLib16550 for the symbols:

SerialPortReadRegister
SerialPortWriteRegister

I recommend you change the names of these 2 functions.

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, December 3, 2015 4:00 PM
> To: Tian, Feng ; Ni, Ruiyu ; Kinney, 
> Michael D 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> 
> Hi Ray,
> 
> I agree a UINT64 Offset would be good for the Offset field.  It would also be 
> good to order the fields and pad the structure so they are
> naturally aligned.  Maybe like the following with some comment changes:
> 
> typedef struct {
>   UINT16  VendorId;   ///< Vendor ID to match the PCI device.  The value 
> 0x terminates the list of entries.
>   UINT16  DeviceId;   ///< Device ID to match the PCI device
>   UINT32  ClockRate;  ///< UART clock rate.  Set to 0 for default clock 
> rate of 1843200 Hz
>   UINT64  Offset; ///< The byte offset into to the BAR
>   UINT8   BarIndex;   ///< Which BAR to get the UART base address
>   UINT8   RegisterStride; ///< UART register stride in bytes.  Set to 0 for 
> default register stride of 1 byte.
>   UINT8  Reserved[6];
> } PCI_SERIAL_PARAMETER;
> 
> You need to add this module to the MdeModulePkg DSC file.
> 
> The code is currently limited to 115200 baud.  There are many UARTs that 
> support higher baud rates, so this restriction needs to be
> removed.
> 
> If a non-standard ClockRate is used, then the actual baud rate may not 
> exactly match the expected baud rate, but as long as we are
> within a few percent, the UART is stable.
> 
> I would like to use this driver as a replacement for the UART driver for 
> Quark that I have posted on GitHub at:
> 
>   
> https://github.com/mdkinney/edk2/tree/Quark/QuarkSocPkg/QuarkSouthCluster/Uart/Dxe
> 
> It has support for baud rate up to 921600 and closest baud rate match with a 
> few percent and support for larger Tx FIFOs and extra
> flushes of the Tx FIFO when doing a Reset or a UART config change.  Please 
> let me know if you want me to help merge in some of
> those features to your patch.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Tian, Feng
> > Sent: Wednesday, December 2, 2015 9:13 PM
> > To: Ni, Ruiyu ; Kinney, Michael D 
> > 
> > Cc: edk2-devel@lists.01.org; Tian, Feng 
> > Subject: RE: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> >
> > Suggest to use UINT64 for Offset field to be consistent with PciIo protocol 
> > definition.
> >
> > Others look good to me
> >
> > Reviewed-by: Feng Tian 
> >
> > Thanks
> > Feng
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, 
> > Ruiyu
> > Sent: Monday, November 30, 2015 10:12
> > To: Kinney, Michael D
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> >
> > Mike,
> > Could you please review whether the PCD structure defined as below is good?
> >
> > +#pragma pack(1)
> > +///
> > +/// PcdPciSerialParameters contains zero or more instances of the below 
> > structure.
> > +/// If a PCI device contains multiple UARTs, PcdPciSerialParameters needs 
> > to contain
> > +/// two instances of the below structure, with the VendorId and DeviceId 
> > equals to the
> > +/// device ID and vendor ID of the device. If the PCI device uses the 
> > first two BARs
> > +/// to support multiple UARTs, BarIndex of first instance equals to 0 and 
> > BarIndex of
> > +/// second one equals to 1; if the PCI device uses the first BAR to 
> > support multiple
> > +/// UARTs, BarIndex of both instance equals to 0 and Offset of first 
> > instance equals
> > +/// to 0 while Offset of second one equals to some value bigger or equal 
> > to 8.
> > +/// For certain UART whose register needs to be accessed in DWORD aligned 
> > address,
> > +/// RegisterStride equals 

[edk2] [Patch] MdePkg: Add Ipmi2.0 definitions head file.

[Daocheng Bu]

Add Ipmi2.0 definitions head file based on Ipmi category:
App, Storage and etc.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daocheng Bu 
CC: Jiewen Yao 
---
 MdePkg/Include/IndustryStandard/Ipmi.h |  29 +
 .../IndustryStandard/IpmiNetFnAppDefinitions.h | 647 +
 .../IndustryStandard/IpmiNetFnBridgeDefinitions.h  | 243 
 .../IndustryStandard/IpmiNetFnChassisDefinitions.h | 304 ++
 .../IpmiNetFnFirmwareDefinitions.h |  26 +
 .../IpmiNetFnGroupExtensionDefinitions.h   |  26 +
 .../IpmiNetFnSensorEventDefinitions.h  |  52 ++
 .../IndustryStandard/IpmiNetFnStorageDefinitions.h | 534 +
 .../IpmiNetFnTransportDefinitions.h| 556 ++
 9 files changed, 2417 insertions(+)
 create mode 100644 MdePkg/Include/IndustryStandard/Ipmi.h
 create mode 100644 MdePkg/Include/IndustryStandard/IpmiNetFnAppDefinitions.h
 create mode 100644 MdePkg/Include/IndustryStandard/IpmiNetFnBridgeDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnChassisDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnFirmwareDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnGroupExtensionDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnSensorEventDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnStorageDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnTransportDefinitions.h

diff --git a/MdePkg/Include/IndustryStandard/Ipmi.h 
b/MdePkg/Include/IndustryStandard/Ipmi.h
new file mode 100644
index 000..b9465a1
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Ipmi.h
@@ -0,0 +1,29 @@
+/** @file   
+  IPMI 2.0 definitions from the IPMI Specification Version 2.0, Revision 1.1.
+
+  See IPMI specification, Appendix G, Command Assignments
+  and Appendix H, Sub-function Assignments.
+
+  Copyright (c) 1999 - 2015, Intel Corporation. All rights reserved.
+  This program and the accompanying materials  
+  are licensed and made available under the terms and conditions of the BSD 
License 
+  which accompanies this distribution.  The full text of the license may be 
found at
+  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 _IPMIDEFINITIONS_H_
+#define _IPMIDEFINITIONS_H_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#endif
\ No newline at end of file
diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnAppDefinitions.h 
b/MdePkg/Include/IndustryStandard/IpmiNetFnAppDefinitions.h
new file mode 100644
index 000..760467d
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/IpmiNetFnAppDefinitions.h
@@ -0,0 +1,647 @@
+/** @file   
+  IPMI 2.0 definitions from the IPMI Specification Version 2.0, Revision 1.1.
+
+  This file contains all NetFn App commands, including:
+IPM Device "Global" Commands (Chapter 20)
+Firmware Firewall & Command Discovery Commands (Chapter 21)
+BMC Watchdog Timer Commands (Chapter 27)
+IPMI Messaging Support Commands (Chapter 22)
+RMCP+ Support and Payload Commands (Chapter 24)
+
+  See IPMI specification, Appendix G, Command Assignments
+  and Appendix H, Sub-function Assignments.
+
+  Copyright (c) 1999 - 2015, Intel Corporation. All rights reserved.
+  This program and the accompanying materials  
+  are licensed and made available under the terms and conditions of the BSD 
License 
+  which accompanies this distribution.  The full text of the license may be 
found at
+  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 _IPMINETFNAPPDEFINITIONS_H_
+#define _IPMINETFNAPPDEFINITIONS_H_
+
+#pragma pack(1)
+//
+// Net function definition for App command
+//
+#define IPMI_NETFN_APP  0x06
+
+//
+//  Below is Definitions for IPM Device "Global" Commands  (Chapter 20)
+//
+
+//
+//  Definitions for Get Device ID command   
+//
+#define IPMI_APP_GET_DEVICE_ID 0x1
+
+//
+//  Constants and Structure definitions for "Get Device ID" command to follow 
here
+//
+typedef struct {
+  UINT8   DeviceId;
+  UINT8   DeviceRevision : 4;
+  UINT8   Reserved : 3;
+  UINT8   DeviceSdr : 1;
+  UINT8   MajorFirmwareRev : 7;
+  UINT8   UpdateMode : 1;
+  UINT8   MinorFirmwareRev;
+  UINT8   SpecificationVersion;
+  UINT8   SensorDeviceSupport : 1;
+  UINT8   

Re: [edk2] [PATCH v2 0/4] Add BlockIO2 support for UFS

[Tian, Feng]

Looks good to me

Reviewed-by: Feng Tian 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao Wu
Sent: Thursday, December 3, 2015 3:41 PM
To: edk2-devel@lists.01.org; Tian, Feng
Cc: Wu, Hao A
Subject: [edk2] [PATCH v2 0/4] Add BlockIO2 support for UFS

Compared with v1, the following modifications have been made:
1. ScsiDiskDxe/ScsiDisk.c - In function ScsiDiskNotify(), fix typo passing 
'Request->InBuffer' to ScsiDiskAsyncWrite10/16(). It should be 
'Request->OutBuffer' instead.

2. UfsPassThruDxe/UfsPassThru.c - Close the timer event which polls the result 
of asynchronous I/O in UfsPassThruDriverBindingStop().

Hao Wu (4):
  MdePkg UefiScsiLib: Add non-blocking support for SCSI Read/Write
command
  MdeModulePkg ScsiDiskDxe: Add BlockIO2 Support
  MdeModulePkg UfsPassThruDxe: Add Non-blocking I/O Support
  MdeModulePkg ScsiBusDxe: Fix caller event may nerver be signaled

 MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c |   44 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c  |4 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c   | 1403 +++-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h   |  322 -
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf  |6 +-
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c  |   49 +-
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h  |   58 +-
 .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c|  288 +++-
 MdePkg/Include/Library/UefiScsiLib.h   |  360 +
 MdePkg/Library/UefiScsiLib/UefiScsiLib.c   |  776 +++
 MdePkg/Library/UefiScsiLib/UefiScsiLib.inf |4 +-
 11 files changed, 3247 insertions(+), 67 deletions(-)

--
1.9.5.msysgit.0

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

Re: [edk2] [PATCH V2 1/2] SecurityPkg: AuthVariableLib: Customized SecureBoot Mode transition. Implement Customized SecureBoot Mode transition logic according to Mantis 1263, including AuditMode/Deplo

[Zeng, Star]

Based on this V2 patch about AuthVariableLib update.

Seemingly, you have forgotten partial of previous 2) and 5) comments.
2. Remove IsPkExist fields from SECURE_BOOT_MODE
structure since only any place to use them.
5. Suggest to update  EFI_SECURE_MODE_NAME and gEfiSecureBootModeGuid
to like  EDKII_SECURE_BOOT_MODE_NAME and gEdkiiSecureBootModeGuid
to reduce confusion.

New minor comments below.
1. Move mSecureBootMode to AuthService.c.
2. Add return status check after InitSecureBootVariables().
3. Remove the trailing white space for "   // SetupMode is always RO. 
Skip IsSetupModeRO;  " in AuthServiceInternal.h.


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


Thanks,
Star

On 2015/12/3 15:55, Zhang, Chao B wrote:

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang, Chao 
---
  SecurityPkg/Library/AuthVariableLib/AuthService.c  | 1404 +---
  .../Library/AuthVariableLib/AuthServiceInternal.h  |   73 +
  .../Library/AuthVariableLib/AuthVariableLib.c  |  110 +-
  .../Library/AuthVariableLib/AuthVariableLib.inf|4 +
  .../DxeImageVerificationLib.c  |  670 +-
  5 files changed, 1935 insertions(+), 326 deletions(-)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
b/SecurityPkg/Library/AuthVariableLib/AuthService.c
index 1f9ba15..86ea04b 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
@@ -56,6 +56,56 @@ EFI_SIGNATURE_ITEM mSupportSigItem[] = {
{EFI_CERT_X509_SHA512_GUID, 0,   80   }
  };

+//
+// Secure Boot Mode state machine
+//
+SECURE_BOOT_MODE mSecureBootState[SecureBootModeTypeMax] = {
+  // USER MODE
+  {
+  TRUE,  // IsPkExist
+  AUDIT_MODE_DISABLE,// AuditMode
+  FALSE, // IsAuditModeRO, AuditMode 
is RW
+  DEPLOYED_MODE_DISABLE, // DeployedMode
+  FALSE, // IsDeployedModeRO, 
DeployedMode is RW
+  SETUP_MODE_DISABLE,// SetupMode
+ // SetupMode is always RO
+  SECURE_BOOT_MODE_ENABLE// SecureBoot
+  },
+  // SETUP MODE
+  {
+  FALSE, // IsPkExist
+  AUDIT_MODE_DISABLE,// AuditMode
+  FALSE, // IsAuditModeRO, AuditMode 
is RW
+  DEPLOYED_MODE_DISABLE, // DeployedMode
+  TRUE,  // IsDeployedModeRO, 
DeployedMode is RO
+  SETUP_MODE_ENABLE, // SetupMode
+ // SetupMode is always RO
+  SECURE_BOOT_MODE_DISABLE   // SecureBoot
+  },
+  // AUDIT MODE
+  {
+  FALSE, // IsPkExist
+  AUDIT_MODE_ENABLE, // AuditMode
+  TRUE,  // AuditModeValAttr RO, 
AuditMode is RO
+  DEPLOYED_MODE_DISABLE, // DeployedMode
+  TRUE,  // DeployedModeValAttr RO, 
DeployedMode is RO
+  SETUP_MODE_ENABLE, // SetupMode
+ // SetupMode is always RO
+  SECURE_BOOT_MODE_DISABLE   // SecureBoot
+  },
+  // DEPLOYED MODE
+  {
+  TRUE,  // IsPkExist
+  AUDIT_MODE_DISABLE,// AuditMode, AuditMode is RO
+  TRUE,  // AuditModeValAttr RO
+  DEPLOYED_MODE_ENABLE,  // DeployedMode
+  TRUE,  // DeployedModeValAttr RO, 
DeployedMode is RO
+  SETUP_MODE_DISABLE,// SetupMode
+ // SetupMode is always RO
+  SECURE_BOOT_MODE_ENABLE// SecureBoot
+  }
+};
+
  /**
Finds variable in storage blocks of volatile and non-volatile storage areas.

@@ -173,80 +223,988 @@ AuthServiceInternalUpdateVariableWithMonotonicCount (
AuthVariableInfo.PubKeyIndex = KeyIndex;
AuthVariableInfo.MonotonicCount = MonotonicCount;

-  return mAuthVarLibContextIn->UpdateVariable (
-   
-   );
+  return mAuthVarLibContextIn->UpdateVariable (
+   
+   );
+}
+
+/**
+  Update the variable region with Variable information.
+
+  @param[in] VariableName   Name of variable.
+  @param[in] VendorGuid Guid of variable.
+  @param[in] Data   Data pointer.
+  @param[in] DataSize   Size of Data.
+  @param[in] Attributes Attribute value of the variable.
+  @param[in] TimeStamp   

[edk2] [PATCH] CryptoPkg: remove global variable 'timeval' from OpenSslSupport.h

[Ard Biesheuvel]

The header file OpenSslSupport.h not only defines a type 'struct timeval'
but also defines a global variable 'timeval' of that type. The RVCT
compiler does not merge this definition into a common symbol, resulting
in duplicate definition errors in the final link. So remove the
variable definition.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 CryptoPkg/Include/OpenSslSupport.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CryptoPkg/Include/OpenSslSupport.h 
b/CryptoPkg/Include/OpenSslSupport.h
index 64bef42d0595..239ae8bd6f41 100644
--- a/CryptoPkg/Include/OpenSslSupport.h
+++ b/CryptoPkg/Include/OpenSslSupport.h
@@ -139,7 +139,7 @@ struct tm {
 struct timeval {
   long tv_sec;  /* time value, in seconds */
   long tv_usec; /* time value, in microseconds */
-} timeval;
+};
 
 struct dirent {
   UINT32  d_fileno; /* file number of entry */
-- 
1.9.1

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

Re: [edk2] [PATCH 3/4] CryptoPkg/OpensslLib: comment out unused code

[Ard Biesheuvel]

On 3 December 2015 at 12:44, David Woodhouse  wrote:
> On Thu, 2015-12-03 at 12:32 +0100, Ard Biesheuvel wrote:
>>
>>
>> ... or maybe not (I hit send too soon)
>>
>> It does not appear that there are any tests for those #defines
>> anywhere, and the pqueue and ts_* source files are built
>> unconditionally by the standard Makefiles.
>
> That might be OK. I think there's magic, and if your no-XXX matches a
> directory name crypto/XXX then that directory just gets dropped from
> the build. Nobody ever needs to check the resulting OPENSSL_NO_XXX
> define, as long as there isn't code that *references* things in those
> directories, which needs an #ifdef. And if there were, then I imagine
> your original patch would have broken...
>

OK, then I think we're good. I can still build my secure boot enabled
platform with those files removed from OpensslLib, so they are not
used. And in fact, the timestamp related functions are duplicated in
BaseCryptLib anyway, which is the reason I have to remove them here.
The reason to omit pqueue is that it calls printf() unconditionally,
which we don't supply.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools GCC: avoid the use of COMMON symbols

[Ard Biesheuvel]

The default behavior of the GCC compiler is to emit uninitialized
globals into a COMMON section, where duplicate definitions are merged.
This may result in unexpected behavior, since global variables appearing
by the same name in different C files typically do not refer to the same
conceptual data item.

For instance, the definitions of EFI_EVENT mVirtualAddressChangeEvent in
that appear in the following files:

  CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c
  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c

will be folded into a single instance of the variable when the latter
module includes the former library, which can lead to unexpected
results.

So prevent GCC from emitting variables into the COMMON section, by
passing -fno-common to the compiler, and discarding the COMMON section
in the GNU ld linker script.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---

NOTE: this patch will result in build failures until we fix the code to make
  at least some instances of mVirtualAddressChangeEvent STATIC

 BaseTools/Conf/tools_def.template | 2 +-
 BaseTools/Scripts/GccBase.lds | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 564d1336650c..2216e747c02d 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4318,7 +4318,7 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /LTCG /DLL /OPT:REF
 DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
--add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
 RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
 
-DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -c -include AutoGen.h
+DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -c -include AutoGen.h -fno-common
 DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double 
-freorder-blocks -freorder-blocks-and-partition -O2 -mno-stack-arg-probe
 DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
-Wno-address -mno-stack-arg-probe
 DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
-minline-int-divide-min-latency
diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 4ee6d998532c..32310bc75dcc 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -46,7 +46,7 @@ SECTIONS {
*/
   .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) {
 *(.data .data.* .gnu.linkonce.d.*)
-*(.bss .bss.* *COM*)
+*(.bss .bss.*)
   }
 
   .eh_frame ALIGN(CONSTANT(COMMONPAGESIZE)) : {
@@ -66,5 +66,6 @@ SECTIONS {
 *(.dynamic)
 *(.hash)
 *(.comment)
+*(COMMON)
   }
 }
-- 
1.9.1

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

Re: [edk2] [PATCH 3/4] CryptoPkg/OpensslLib: comment out unused code

[Ard Biesheuvel]

On 3 December 2015 at 12:19, David Woodhouse  wrote:
> On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
>> This comments out the pqueue and ts_* source files from the
>> OpensslLib build, since they have no users.
>
> These are going to be auto-generated from the OpenSSL build system (see
> the process_files.sh script in the patches I've been submitting).
>
> Is it just a case of adding 'no-pqueue no-ts' to the OpenSSL Configure
> invocation in process_files.sh, to make the generated result continue
> to match?
>

I think so. The following

./config no-pqueue no-ts

results in [among other things]

no-pqueue   [option]   OPENSSL_NO_PQUEUE (skip dir)
no-ts   [option]   OPENSSL_NO_TS (skip dir)

so that does look promising.

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

Re: [edk2] [PATCH] MdeModulePkg: allow DxeIpl to load without permanent memory to enable S3 resume from temporary memory

[Laszlo Ersek]

On 12/03/15 02:01, Zeng, Star wrote:
> On 2015/12/3 2:58, Cohen, Eugene wrote:
>> Star,
>>
>>> Do you have the patch tested on your real platforms (with and without
>>> InstallPeiMemory()?
>>
>> Yes, we've been running this way for a couple years.  I had it on my
>> list of changes to upstream and forgot about it until now.  The only
>> other requirement for this to work correctly is for the memory
>> intiialization driver to not call InstallPeiMemory on S3 resume.
> 
> Thanks for the information.
> 
>>
>>> Current code will install Decompress and Extraction PPI for both
>>> normal and
>>> S3 path in entry point, but Decompress and Extraction PPI need to use
>>> AllocatePages() that only works after memory discovered as PI spec
>>> describes.
>>> Then should the code be also updated to install Decompress and
>>> Extraction
>>> PPI in memory discovered ppi notify with
>>> EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH?
>>
>> This makes sense to me - don't publish a service that cannot be
>> handled.  So as long as S3 resume doesn't require section extraction
>> (which seems unlikely) then DXE IPL can just expose the reduced set of
>> PPIs.  Do you want to propose something or shall I?
> 
> S3 still need the PPIs in case platform have InstallPeiMemory() call and
> compressed PEIM even at S3 path. So the code can't to do not install the
> PPIs at S3 path.
> Please go to propose the code change.

I'll admit that I don't fully understand the details and the expected
implications of this change, but: OVMF does install permanent PEI RAM on
the S3 resume path, and it would be nice if that wouldn't break.

... If this is a very intrusive change, can it be made dependent on a
FeaturePCD perhaps?

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

Re: [edk2] [PATCH 3/4] CryptoPkg/OpensslLib: comment out unused code

[David Woodhouse]

On Thu, 2015-12-03 at 12:32 +0100, Ard Biesheuvel wrote:
> 
> 
> ... or maybe not (I hit send too soon)
> 
> It does not appear that there are any tests for those #defines
> anywhere, and the pqueue and ts_* source files are built
> unconditionally by the standard Makefiles.

That might be OK. I think there's magic, and if your no-XXX matches a
directory name crypto/XXX then that directory just gets dropped from
the build. Nobody ever needs to check the resulting OPENSSL_NO_XXX
define, as long as there isn't code that *references* things in those
directories, which needs an #ifdef. And if there were, then I imagine
your original patch would have broken...

-- 
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] [PATCH 2/2] ArmVirtPkg: Add memory space for the memory nodes except the lowest one

[Ard Biesheuvel]

On 3 December 2015 at 12:52, Laszlo Ersek  wrote:
> Ard,
>
> On 11/30/15 18:48, Laszlo Ersek wrote:
>> On 11/30/15 12:48, Ard Biesheuvel wrote:
>>> On 30 November 2015 at 12:09, Laszlo Ersek  wrote:
 On 11/30/15 11:03, Ard Biesheuvel wrote:
>>> [...]
>
> Couldn't we simply add EFI_RESOURCE_SYSTEM_MEMORY resource descriptor
> HOBs the first time we enumerate the nodes?

 I didn't suggest it for two reasons.

 (1) I recalled that last time we had had a very long discussion about how 
 the DXE core selects the initial range for memory allocations (for its own 
 purposes, primarily). I had trouble remembering all the details now. So 
 there were three options for me:

 - recommend the HOBs, and hope for the best, i.e., hope whatever the DXE 
 core picks will be good for us

 - recommend the HOBs, and actually review what the DXE core does (it was 
 modified a little bit last time)

 - recommend a single HOB (which implies the DXE core gets initialized 
 exactly the same as before, no thinking or code browsing needed), and 
 delay the installation of the addtional ranges until later.

 I picked the last option for simplicity.

 (2) The other reason is that I don't think that the HOB approach would 
 solve the question of caching attributes. I don't think the DXE core tries 
 to set any attributes on its own when the GCD is primed from the HOBs.

 Remember we have

 InitializeMemory()  
 [ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c]
   ArmPlatformInitializeSystemMemory()   
 [ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c]
 PcdSet64 (PcdSystemMemorySize, ...)
   MemoryPeim()  
 [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
 PcdGet64 (PcdSystemMemorySize)
 BuildResourceDescriptorHob()
 InitMmu()   
 [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
   ArmPlatformGetVirtualMemoryMap()  
 [ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c]
 PcdGet64 (PcdSystemMemorySize)
   ArmConfigureMmu() 
 [ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c]

 In other words, all of the following happens in the memory init PEIM 
 (which comes from ArmPlatformPkg, but it's plugged chock full of our 
 ArmVirtPkg library instances):
 - the in-DRAM DTB is initially parsed for the memory node
 - the size PCD is set
 - the base PCD is verified
 - a memory descriptor HOB is built, dependent on the PCDs
 - a virtual memory map is built, with caching attributes, dependent on the 
 PCDs
 - the MMU is configured

 Therefore we have a nice fast caching setting for the "base" memory node 
 only because you cover it explicitly in ArmPlatformGetVirtualMemoryMap() 
 -- dependent on the PCDs --, not because the DXE core covers it when it 
 processes the HOBs. So if you want to process several memory nodes *for 
 real* in the the memory init PEIM, then not only do you have to create the 
 HOBs there, but also extend the virtual memory map for the MMU similarly. 
 And a fixed count of PCDs won't be enough to carry the information from 
 the DTB to ArmPlatformGetVirtualMemoryMap() -- some loop would have to 
 exist that connects the DTB with the virtual memory map.

 This is what I meant in my original response by "having more flexibility 
 in DXE".

>>>
>>> Yes, that does sound like a lot of work for little gain. But I am not
>>> too crazy about adding more 'A PRIORI' modules, to avoid ending up in
>>> dependency hell later.
>>
>> I agree.
>>
>> Unfortunately, the only other possibility I can see is a separate driver
>> that has a DepEx on the CPU architectural protocol, iterates over the
>> FDT again, and installs the memory ranges (including setting the caching).
>>
>> (I also thought about delaying this logic within VirtFdtDxe: set up a
>> protocol notify callback on the CPU arch protocol, and do the same thing
>> in the callback. Unfortunately, this is exactly what the DXE core does
>> too, and the ordering between protocol notify callbacks is not
>> specified. So if ours ran first, there would be trouble.)
>>
>> Take your pick. If you opt for the separate driver / DepEx approach, I
>> can certainly agree with that as well. It would take a bit more
>> boilerplate (separate directory, separate INF file), but it would be
>> very clean, as far as dispatch order and driver responsibility go.
>
> What would be your preference here?
>
> Personally I'm leaning towards a separate driver, not dissimilar to
> VirtFdtDxe, that goes over the DTB, hunting for the memory nodes only,
> adding them and setting the caching attributes as well. (So it would
> have the depex.)
>
> We can think of 

Re: [edk2] [PATCH 3/4] CryptoPkg/OpensslLib: comment out unused code

[Ard Biesheuvel]

On 3 December 2015 at 13:46, David Woodhouse  wrote:
> On Thu, 2015-12-03 at 13:13 +0100, Ard Biesheuvel wrote:
>>
>> OK, then I think we're good. I can still build my secure boot enabled
>> platform with those files removed from OpensslLib, so they are not
>> used. And in fact, the timestamp related functions are duplicated in
>> BaseCryptLib anyway, which is the reason I have to remove them here.
>
> As discussed, we should work out why the OpenSSL TS functionality
> needed to be reimplemented in CryptoLib, and *fix* that.
>

I was hoping Qin was going to come back with his analysis on this topic.

>> The reason to omit pqueue is that it calls printf() unconditionally,
>> which we don't supply.
>
> That's a bug. Please file in OpenSSL RT.
>

OK, fair enough. But there is still no need to build it
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/4] CryptoPkg/OpensslLib: comment out unused code

[David Woodhouse]

On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
> This comments out the pqueue and ts_* source files from the
> OpensslLib build, since they have no users.

These are going to be auto-generated from the OpenSSL build system (see
the process_files.sh script in the patches I've been submitting).

Is it just a case of adding 'no-pqueue no-ts' to the OpenSSL Configure
invocation in process_files.sh, to make the generated result continue
to match?

-- 
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] [PATCH 4/4] CryptoPkg/OpensslLib: ignore more false positive warnings for RVCT

[David Woodhouse]

On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
> The RVCT compiler chokes on a couple of issues in upstream OpenSSL
> that
> can be confirmed to be non-issues by inspection. So just ignore these
> warnings entirely.

I still maintain this needs a reference to bug reports — either
*compiler* bugs, if the compiler is just being entirely stupid, or
OpenSSL RT tickets.

Or both, since it's possible to work around it compiler issues in the
source code even if it's actually the *compiler* at fault.

But in no circumstance is it acceptable for such a patch to reference
*neither* a compiler nor a source bug, surely?

-- 
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] [PATCH 2/4] CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC

[Ard Biesheuvel]

On 3 December 2015 at 11:50, Ard Biesheuvel  wrote:
> Make mVirtualAddressChangeEvent STATIC to prevent it from conflicting
> with other variables of the same name that may be defined in other
> libraries (e.g., MdeModulePkg/Universal/Variable/RuntimeDxe)
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c 
> b/CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c
> index 79bb0678e376..616ee7717e72 100644
> --- a/CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c
> +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c
> @@ -64,7 +64,7 @@ RT_MEMORY_PAGE_TABLE  *mRTPageTable = NULL;
>  //
>  // Event for Runtime Address Conversion.
>  //
> -EFI_EVENT mVirtualAddressChangeEvent;
> +STATIC EFI_EVENT  mVirtualAddressChangeEvent;
>
>

Actually, I wonder if an actual bug may be lurking here. if
mVirtualAddressChangeEvent gets classified as a COMMON symbol, there
will be only a single copy of it in the final module, which means
whoever comes last hijacks the event, and the handlers queued by the
earlier callers will never be invoked.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 6/6] OvmfPkg: Fix VS2015 warning C4459 in XenBusDxe

[Laszlo Ersek]

On 12/03/15 06:26, Liming Gao wrote:
> warning C4459: declaration of 'xs' hides global declaration.
> Update code to rename local variable xs to xsp to be different.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: Justen Jordan 
> ---
>  OvmfPkg/XenBusDxe/XenStore.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
> index 9850f1e..61976f9 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.c
> +++ b/OvmfPkg/XenBusDxe/XenStore.c
> @@ -992,9 +992,9 @@ NotifyEventChannelCheckForEvent (
>IN VOID *Context
>)
>  {
> -  XENSTORE_PRIVATE *xs;
> -  xs = (XENSTORE_PRIVATE *)Context;
> -  if (TestAndClearBit (xs->EventChannel, 
> xs->Dev->SharedInfo->evtchn_pending)) {
> +  XENSTORE_PRIVATE *xsp;
> +  xsp = (XENSTORE_PRIVATE *)Context;
> +  if (TestAndClearBit (xsp->EventChannel, 
> xsp->Dev->SharedInfo->evtchn_pending)) {
>  gBS->SignalEvent (Event);
>}
>  }
> @@ -1007,12 +1007,12 @@ NotifyEventChannelCheckForEvent (
>  STATIC
>  EFI_STATUS
>  XenStoreInitComms (
> -  XENSTORE_PRIVATE *xs
> +  XENSTORE_PRIVATE *xsp
>)
>  {
>EFI_STATUS Status;
>EFI_EVENT TimerEvent;
> -  struct xenstore_domain_interface *XenStore = xs->XenStore;
> +  struct xenstore_domain_interface *XenStore = xsp->XenStore;
>  
>Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, );
>Status = gBS->SetTimer (TimerEvent, TimerRelative,
> @@ -1029,8 +1029,8 @@ XenStoreInitComms (
>gBS->CloseEvent (TimerEvent);
>  
>Status = gBS->CreateEvent (EVT_NOTIFY_WAIT, TPL_NOTIFY,
> - NotifyEventChannelCheckForEvent, xs,
> - >EventChannelEvent);
> + NotifyEventChannelCheckForEvent, xsp,
> + >EventChannelEvent);
>ASSERT_EFI_ERROR (Status);
>  
>return Status;
> 

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

Re: [edk2] [PATCH 4/4] CryptoPkg/OpensslLib: ignore more false positive warnings for RVCT

[Ard Biesheuvel]

On 3 December 2015 at 12:17, David Woodhouse  wrote:
> On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
>> The RVCT compiler chokes on a couple of issues in upstream OpenSSL
>> that
>> can be confirmed to be non-issues by inspection. So just ignore these
>> warnings entirely.
>
> I still maintain this needs a reference to bug reports — either
> *compiler* bugs, if the compiler is just being entirely stupid, or
> OpenSSL RT tickets.
>
> Or both, since it's possible to work around it compiler issues in the
> source code even if it's actually the *compiler* at fault.
>
> But in no circumstance is it acceptable for such a patch to reference
> *neither* a compiler nor a source bug, surely?
>

I don't think OpenSSL upstream is at fault here in any of the cases,
and I definitely would not recommend obfuscating OpenSSL to make RVCT
happy even if some instances could be easily solved by adding a
redundant zero initializer, since such changes often do more evil than
good.

So that leaves reporting bugs to ARM regarding RVCT. I guess that
should be an option, perhaps Eugene can take this up, being an actual
paying ARM customer? Note than I work for Linaro, not for ARM (unlike
Leif, who is an ARM employee that is seconded to Linaro), so of the
people involved, I am definitely not in the best position to chase
this.

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

Re: [edk2] [PATCH 3/4] CryptoPkg/OpensslLib: comment out unused code

[Ard Biesheuvel]

On 3 December 2015 at 12:29, Ard Biesheuvel  wrote:
> On 3 December 2015 at 12:19, David Woodhouse  wrote:
>> On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
>>> This comments out the pqueue and ts_* source files from the
>>> OpensslLib build, since they have no users.
>>
>> These are going to be auto-generated from the OpenSSL build system (see
>> the process_files.sh script in the patches I've been submitting).
>>
>> Is it just a case of adding 'no-pqueue no-ts' to the OpenSSL Configure
>> invocation in process_files.sh, to make the generated result continue
>> to match?
>>
>
> I think so. The following
>
> ./config no-pqueue no-ts
>
> results in [among other things]
>
> no-pqueue   [option]   OPENSSL_NO_PQUEUE (skip dir)
> no-ts   [option]   OPENSSL_NO_TS (skip dir)
>
> so that does look promising.
>

... or maybe not (I hit send too soon)

It does not appear that there are any tests for those #defines
anywhere, and the pqueue and ts_* source files are built
unconditionally by the standard Makefiles.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] ArmVirtPkg: Add memory space for the memory nodes except the lowest one

[Laszlo Ersek]

Ard,

On 11/30/15 18:48, Laszlo Ersek wrote:
> On 11/30/15 12:48, Ard Biesheuvel wrote:
>> On 30 November 2015 at 12:09, Laszlo Ersek  wrote:
>>> On 11/30/15 11:03, Ard Biesheuvel wrote:
>> [...]

 Couldn't we simply add EFI_RESOURCE_SYSTEM_MEMORY resource descriptor
 HOBs the first time we enumerate the nodes?
>>>
>>> I didn't suggest it for two reasons.
>>>
>>> (1) I recalled that last time we had had a very long discussion about how 
>>> the DXE core selects the initial range for memory allocations (for its own 
>>> purposes, primarily). I had trouble remembering all the details now. So 
>>> there were three options for me:
>>>
>>> - recommend the HOBs, and hope for the best, i.e., hope whatever the DXE 
>>> core picks will be good for us
>>>
>>> - recommend the HOBs, and actually review what the DXE core does (it was 
>>> modified a little bit last time)
>>>
>>> - recommend a single HOB (which implies the DXE core gets initialized 
>>> exactly the same as before, no thinking or code browsing needed), and delay 
>>> the installation of the addtional ranges until later.
>>>
>>> I picked the last option for simplicity.
>>>
>>> (2) The other reason is that I don't think that the HOB approach would 
>>> solve the question of caching attributes. I don't think the DXE core tries 
>>> to set any attributes on its own when the GCD is primed from the HOBs.
>>>
>>> Remember we have
>>>
>>> InitializeMemory()  
>>> [ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c]
>>>   ArmPlatformInitializeSystemMemory()   
>>> [ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c]
>>> PcdSet64 (PcdSystemMemorySize, ...)
>>>   MemoryPeim()  
>>> [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
>>> PcdGet64 (PcdSystemMemorySize)
>>> BuildResourceDescriptorHob()
>>> InitMmu()   
>>> [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
>>>   ArmPlatformGetVirtualMemoryMap()  
>>> [ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c]
>>> PcdGet64 (PcdSystemMemorySize)
>>>   ArmConfigureMmu() 
>>> [ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c]
>>>
>>> In other words, all of the following happens in the memory init PEIM (which 
>>> comes from ArmPlatformPkg, but it's plugged chock full of our ArmVirtPkg 
>>> library instances):
>>> - the in-DRAM DTB is initially parsed for the memory node
>>> - the size PCD is set
>>> - the base PCD is verified
>>> - a memory descriptor HOB is built, dependent on the PCDs
>>> - a virtual memory map is built, with caching attributes, dependent on the 
>>> PCDs
>>> - the MMU is configured
>>>
>>> Therefore we have a nice fast caching setting for the "base" memory node 
>>> only because you cover it explicitly in ArmPlatformGetVirtualMemoryMap() -- 
>>> dependent on the PCDs --, not because the DXE core covers it when it 
>>> processes the HOBs. So if you want to process several memory nodes *for 
>>> real* in the the memory init PEIM, then not only do you have to create the 
>>> HOBs there, but also extend the virtual memory map for the MMU similarly. 
>>> And a fixed count of PCDs won't be enough to carry the information from the 
>>> DTB to ArmPlatformGetVirtualMemoryMap() -- some loop would have to exist 
>>> that connects the DTB with the virtual memory map.
>>>
>>> This is what I meant in my original response by "having more flexibility in 
>>> DXE".
>>>
>>
>> Yes, that does sound like a lot of work for little gain. But I am not
>> too crazy about adding more 'A PRIORI' modules, to avoid ending up in
>> dependency hell later.
> 
> I agree.
> 
> Unfortunately, the only other possibility I can see is a separate driver
> that has a DepEx on the CPU architectural protocol, iterates over the
> FDT again, and installs the memory ranges (including setting the caching).
> 
> (I also thought about delaying this logic within VirtFdtDxe: set up a
> protocol notify callback on the CPU arch protocol, and do the same thing
> in the callback. Unfortunately, this is exactly what the DXE core does
> too, and the ordering between protocol notify callbacks is not
> specified. So if ours ran first, there would be trouble.)
> 
> Take your pick. If you opt for the separate driver / DepEx approach, I
> can certainly agree with that as well. It would take a bit more
> boilerplate (separate directory, separate INF file), but it would be
> very clean, as far as dispatch order and driver responsibility go.

What would be your preference here?

Personally I'm leaning towards a separate driver, not dissimilar to
VirtFdtDxe, that goes over the DTB, hunting for the memory nodes only,
adding them and setting the caching attributes as well. (So it would
have the depex.)

We can think of this driver as a "memory controller driver", except the
only thing it'd have to do is look at the DTB.

Thanks
Laszlo
___
edk2-devel 

Re: [edk2] [PATCH 3/4] CryptoPkg/OpensslLib: comment out unused code

[David Woodhouse]

On Thu, 2015-12-03 at 13:13 +0100, Ard Biesheuvel wrote:
> 
> OK, then I think we're good. I can still build my secure boot enabled
> platform with those files removed from OpensslLib, so they are not
> used. And in fact, the timestamp related functions are duplicated in
> BaseCryptLib anyway, which is the reason I have to remove them here.

As discussed, we should work out why the OpenSSL TS functionality
needed to be reimplemented in CryptoLib, and *fix* that.

> The reason to omit pqueue is that it calls printf() unconditionally,
> which we don't supply.

That's a bug. Please file in OpenSSL RT.

-- 
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] [PATCH] ShellPkg: Refine the code to reduce time cost of 'map -r'

[Laszlo Ersek]

On 12/03/15 06:35, Qiu Shumin wrote:
> In some platform 'map -r' may cost more than 1 min. This patch filter the 
> target handles by
> BlockIO and SimpleFileSystem protocol to reduce the time cost.

Hijacking this thread and asking a more general question -- I noticed
recently that the "devices" and "drivers" commands can take quite long.
I guess there is a lot of processing to be done for those. But, has it
been considered to change the internal representation of the protocol
database to speed things up? (I'm asking this without knowing too much
about the current representation.)

I'm not suggesting that the current proto DB representation is slow; I'm
just curious if the perf consequences of the representation have been
considered before.

Thanks!
Laszlo

> 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin 
> ---
>  .../Library/UefiShellCommandLib/ConsistMapping.c   | 40 
> --
>  1 file changed, 30 insertions(+), 10 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c 
> b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> index 9bd7b2c..86e8dc5 100644
> --- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> +++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> @@ -16,6 +16,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +
> +
>  
>  typedef enum {
>MTDTypeUnknown,
> @@ -1349,20 +1353,22 @@ ShellCommandConsistMappingInitialize (
>OUT EFI_DEVICE_PATH_PROTOCOL   ***Table
>)
>  {
> -  EFI_HANDLE*HandleBuffer;
> -  UINTN HandleNum;
> -  UINTN HandleLoop;
> -  EFI_DEVICE_PATH_PROTOCOL  **TempTable;
> -  EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
> -  EFI_DEVICE_PATH_PROTOCOL  *HIDevicePath;
> -  UINTN Index;
> -  EFI_STATUSStatus;
> +  EFI_HANDLE  *HandleBuffer;
> +  UINTN   HandleNum;
> +  UINTN   HandleLoop;
> +  EFI_DEVICE_PATH_PROTOCOL**TempTable;
> +  EFI_DEVICE_PATH_PROTOCOL*DevicePath;
> +  EFI_DEVICE_PATH_PROTOCOL*HIDevicePath;
> +  EFI_BLOCK_IO_PROTOCOL   *BlockIo;
> +  EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *SimpleFileSystem;
> +  UINTN   Index;
> +  EFI_STATUS  Status;
>  
>HandleBuffer  = NULL;
>  
>Status = gBS->LocateHandleBuffer (
> -  AllHandles,
> -  NULL,
> +  ByProtocol,
> +  ,
>NULL,
>,
>
> @@ -1385,6 +1391,20 @@ ShellCommandConsistMappingInitialize (
>continue;
>  }
>  
> +Status = gBS->HandleProtocol( HandleBuffer[HandleLoop], 
> +  , 
> +  (VOID **)
> +  );
> +if (EFI_ERROR(Status)) {
> +  Status = gBS->HandleProtocol( HandleBuffer[HandleLoop], 
> +, 
> +(VOID **)
> +);
> +  if (EFI_ERROR(Status)) {
> +continue;
> +  }
> +}
> +
>  for (Index = 0; TempTable[Index] != NULL; Index++) {
>if (DevicePathCompare ([Index], ) == 0) {
>  FreePool (HIDevicePath);
> 

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

Re: [edk2] [PATCH 0/5] coding style/whitespace/cast fixes for RVCT

[Ard Biesheuvel]

On 2 December 2015 at 18:02, Ard Biesheuvel  wrote:
> This fixes a couple of coding style and white space issues and missing casts 
> that
> the RVCT warns about, which means they are breaking the build in 
> warnings-as-errors
> mode.
>

I have dropped patch #4 (against ShellPkg), and committed the
remaining patches as SVN r19105 ... r 19108

Thanks everyone!

-- 
Ard.


> Ard Biesheuvel (5):
>   IntelFrameworkModulePkg: remove unreachable code
>   MdeModulePkg: remove unreachable code
>   SecurityPkg: put missing empty lines at the end of some header files
>   ShellPkg: add missing SHELL_STATUS cast
>   ArmVirtPkg: use explicit KERNEL_BLOB_TYPE cast
>
>  ArmVirtPkg/Library/PlatformIntelBdsLib/QemuKernel.c  
>   | 4 +++-
>  IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConsole.c   
>   | 1 -
>  MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c   
>   | 3 ---
>  MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c 
>   | 1 -
>  MdeModulePkg/Universal/SetupBrowserDxe/Expression.c  
>   | 1 -
>  SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.h
>   | 2 +-
>  SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h 
>   | 2 +-
>  
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigNvData.h
>  | 2 +-
>  ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c 
>   | 2 +-
>  9 files changed, 7 insertions(+), 11 deletions(-)
>
> --
> 1.9.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/5] SecurityPkg: put missing empty lines at the end of some header files

[Ard Biesheuvel]

On 2 December 2015 at 18:02, Ard Biesheuvel  wrote:
> Some compilers (like RVCT) reject input files that do not end in a
> newline. So add missing newlines to some SecurityPkg header files.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Hello Chao,

Do you have any comments on this patch?

Thanks,
Ard.



> ---
>  SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.h
>   | 2 +-
>  SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h 
>   | 2 +-
>  
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigNvData.h
>  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git 
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.h 
> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.h
> index b09ef8afd3e1..cff6076368b5 100644
> --- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.h
> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.h
> @@ -204,4 +204,4 @@ typedef struct {
>HASH_FINAL   HashFinal;
>  } HASH_TABLE;
>
> -#endif
> \ No newline at end of file
> +#endif
> diff --git 
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h
>  
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h
> index 228f44bde814..bcb1c12e2314 100644
> --- 
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h
> +++ 
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h
> @@ -621,4 +621,4 @@ GuidToString (
>IN  UINTN BufferSize
>);
>
> -#endif
> \ No newline at end of file
> +#endif
> diff --git 
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigNvData.h
>  
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigNvData.h
> index b628bcb1f532..7aebc1f99e85 100644
> --- 
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigNvData.h
> +++ 
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigNvData.h
> @@ -133,4 +133,4 @@ typedef struct {
>EFI_HII_TIME RevocationTime; // The revocation time of the certificate
>  } SECUREBOOT_CONFIGURATION;
>
> -#endif
> \ No newline at end of file
> +#endif
> --
> 1.9.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] Vlv2DeviceRefCodePkg/Vlv2TbltDevicePkg: Reset BIOS Setup when Jumper is present on Turbot.

[lushifex]

Signed-off-by: lushifex 
---
 .../SouthCluster/Include/Library/PchPlatformLib.h  |   9 ++
 Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c  |  19 ++--
 .../MultiPlatformLib/BoardClkGens/BoardClkGens.c   |   6 +-
 .../MultiPlatformLib/BoardClkGens/BoardClkGens.h   |   2 +
 .../MultiPlatformLib/BoardGpios/BoardGpios.c   |  15 +++
 .../MultiPlatformLib/BoardGpios/BoardGpios.h   |   1 +
 .../Library/MultiPlatformLib/MultiPlatformLib.inf  |   1 +
 .../Library/PchPlatformLib/PchPlatformLibrary.c| 108 +
 .../Library/PlatformBdsLib/BdsPlatform.c   |  29 --
 .../Library/PlatformBdsLib/PlatformBdsLib.inf  |   1 +
 Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c|   8 +-
 Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf  |   1 +
 Vlv2TbltDevicePkg/PlatformDxe/ExI.c|   8 +-
 Vlv2TbltDevicePkg/PlatformDxe/Platform.c   |  51 +-
 .../PlatformGopPolicy/PlatformGopPolicy.c  |   9 +-
 .../PlatformGopPolicy/PlatformGopPolicy.inf|   3 +
 .../PlatformInfoDxe/PlatformInfoDxe.c  |   9 +-
 .../PlatformInfoDxe/PlatformInfoDxe.inf|   1 +
 Vlv2TbltDevicePkg/PlatformInitPei/BootMode.c   |   6 +-
 .../PlatformInitPei/PlatformEarlyInit.c|   7 +-
 Vlv2TbltDevicePkg/PlatformPei/BootMode.c   |  16 +++
 Vlv2TbltDevicePkg/PlatformPei/Platform.c   |   7 +-
 Vlv2TbltDevicePkg/PlatformPei/PlatformPei.inf  |   1 +
 .../PlatformSetupDxe/PlatformSetupDxe.inf  |   1 +
 .../PlatformSetupDxe/SetupInfoRecords.c|   7 +-
 Vlv2TbltDevicePkg/PlatformSmm/Platform.c   |  15 ++-
 26 files changed, 300 insertions(+), 41 deletions(-)

diff --git 
a/Vlv2DeviceRefCodePkg/ValleyView2Soc/SouthCluster/Include/Library/PchPlatformLib.h
 
b/Vlv2DeviceRefCodePkg/ValleyView2Soc/SouthCluster/Include/Library/PchPlatformLib.h
index 8f0ca02..9651f94 100644
--- 
a/Vlv2DeviceRefCodePkg/ValleyView2Soc/SouthCluster/Include/Library/PchPlatformLib.h
+++ 
b/Vlv2DeviceRefCodePkg/ValleyView2Soc/SouthCluster/Include/Library/PchPlatformLib.h
@@ -115,7 +115,16 @@ PchAlternateAccessMode (
 
   @retval NONE
 
 **/
 ;
+UINT32
+DetectTurbotBoard (
+VOID
+  );
+
+UINT32
+DetectGpioPinValue (
+VOID
+  );
 
 #endif
diff --git a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c 
b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
index 2ff14ec..a7e54e3 100644
--- a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
+++ b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
@@ -646,10 +646,11 @@ OnReadyToBoot (
   SYSTEM_CONFIGURATIONSetupVarBuffer;
   UINTN   VariableSize;
   EFI_PLATFORM_CPU_INFO   *PlatformCpuInfoPtr = NULL;
   EFI_PLATFORM_CPU_INFO   PlatformCpuInfo;
   EFI_PEI_HOB_POINTERS  GuidHob;
+  UINT32  DxeGpioValue;
 
   if (mFirstNotify) {
 return;
   }
 
@@ -684,10 +685,12 @@ OnReadyToBoot (
 
   if ((PlatformCpuInfoPtr != NULL)) {
 CopyMem(, PlatformCpuInfoPtr, 
sizeof(EFI_PLATFORM_CPU_INFO));
   }
 
+  DxeGpioValue = DetectGpioPinValue();
+
   //
   // Update the ACPI parameter blocks finally.
   //
   VariableSize = sizeof (SYSTEM_CONFIGURATION);
   Status = gRT->GetVariable (
@@ -695,12 +698,12 @@ OnReadyToBoot (
   ,
   NULL,
   ,
   
   );
-  if (EFI_ERROR (Status) || VariableSize != sizeof(SYSTEM_CONFIGURATION)) {
-//The setup variable is corrupted
+  if (EFI_ERROR (Status) || VariableSize != sizeof(SYSTEM_CONFIGURATION) || 
DxeGpioValue == 0) {
+//The setup variable is corrupted or detect GPIO_S5_17 Pin is low
 VariableSize = sizeof(SYSTEM_CONFIGURATION);
 Status = gRT->GetVariable(
   L"SetupRecovery",
   ,
   NULL,
@@ -794,10 +797,11 @@ AcpiPlatformEntryPoint (
   EFI_MP_SERVICES_PROTOCOL  *MpService;
   UINTN MaximumNumberOfCPUs;
   UINTN NumberOfEnabledCPUs;
   UINT32Data32;
   PCH_STEPPING  pchStepping;
+  UINT32DxeGpioValue;
 
   mFirstNotify  = FALSE;
 
   TableVersion  = EFI_ACPI_TABLE_VERSION_2_0;
   Instance  = 0;
@@ -813,11 +817,12 @@ AcpiPlatformEntryPoint (
   if (GuidHob.Raw != NULL) {
 if ((GuidHob.Raw = GetNextGuidHob (, GuidHob.Raw)) != 
NULL) {
   mPlatformInfo = GET_GUID_HOB_DATA (GuidHob.Guid);
 }
   }
-
+  
+  DxeGpioValue = DetectGpioPinValue();
   //
   // Search for the Memory Configuration GUID HOB.  If it is not present, then
   // there's nothing we can do. It may not exist on the update path.
   //
   VarSize = sizeof(SYSTEM_CONFIGURATION);
@@ -826,12 +831,12 @@ AcpiPlatformEntryPoint (
   ,
   NULL,
   ,
   
   );
-  if (EFI_ERROR (Status) || VarSize != sizeof(SYSTEM_CONFIGURATION)) {
-//The setup variable is corrupted
+  if 

Re: [edk2] [PATCH 4/5] ShellPkg: add missing SHELL_STATUS cast

[Ard Biesheuvel]

On 3 December 2015 at 02:01, Qiu, Shumin  wrote:
> Hi  Ard,
> If Status is not EFI_SUCCESS we cannot do the explicit cast. Please help to 
> check the definition of SHELL_STATUS and EFI_STATUS.

OK, i was not aware of that. I assumed it was similar to
RETURN_STATUS<->EFI_STATUS, since I spotted some straight casts to
SHELL_STATUS as well.
Note that my patch just removes the warning, so the code is already broken.

> Actually for this issue Jiaxin has submitted a patch(as attached) to fix. 
> Could you help to review.
>

The patch looks fine to me. I could not apply it from this email, but
I pulled it from the list instead. Note that I get lots of whitespace
errors when applying it, so please get rid of the trailing whitespace

Tested-by: Ard Biesheuvel 

With the whitespace errors cleaned up:
Reviewed-by: Ard Biesheuvel 

Thanks,
Ard.


> -- Forwarded message --
> From: "Wu, Jiaxin" 
> To: "edk2-devel@lists.01.org" 
> Cc: "Carsey, Jaben" , "Ye, Ting" , 
> "Cohen, Eugene" 
> Date: Wed, 2 Dec 2015 08:54:24 +
> Subject: [edk2] [Patch] ShellPkg: Fix wrong return status for Ifconfig.c
> The Ifconfig command handler tries to return an EFI_STATUS when
> the return type should be SHELL_STATUS.
>
> Cc: Cohen, Eugene 
> Cc: Carsey, Jaben 
> Cc: Ye Ting 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  .../UefiShellNetwork1CommandsLib/Ifconfig.c| 102 
> ++---
>  1 file changed, 69 insertions(+), 33 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c 
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> index e16d46a..fb6f575 100644
> --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> @@ -421,11 +421,11 @@ IfConfigGetInterfaceInfo (
>NULL,
>,
>
>   );
>if (EFI_ERROR (Status) || (HandleNum == 0)) {
> -return EFI_ABORTED;
> +return Status;
>}
>
>//
>// Enumerate all handles that installed with ip4 service binding protocol.
>//
> @@ -585,15 +585,15 @@ ON_ERROR:
>  /**
>The list process of the ifconfig command.
>
>@param[in]   IfListThe pointer of IfList(interface list).
>
> -  @retval EFI_SUCCESSThe ifconfig command list processed successfully.
> +  @retval SHELL_SUCCESS  The ifconfig command list processed successfully.
>@retval others The ifconfig command list process failed.
>
>  **/
> -EFI_STATUS
> +SHELL_STATUS
>  IfConfigShowInterfaceInfo (
>IN LIST_ENTRY*IfList
>)
>  {
>LIST_ENTRY   *Entry;
> @@ -781,35 +781,37 @@ IfConfigShowInterfaceInfo (
>  }
>}
>
>ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_IFCONFIG_INFO_BREAK), 
> gShellNetwork1HiiHandle);
>
> -  return EFI_SUCCESS;
> +  return SHELL_SUCCESS;
>  }
>
>  /**
>The clean process of the ifconfig command to clear interface info.
>
>@param[in]   IfListThe pointer of IfList(interface list).
>
> -  @retval EFI_SUCCESSThe ifconfig command clean processed successfully.
> +  @retval SHELL_SUCCESS  The ifconfig command clean processed successfully.
>@retval others The ifconfig command clean process failed.
>
>  **/
> -EFI_STATUS
> +SHELL_STATUS
>  IfConfigClearInterfaceInfo (
>IN LIST_ENTRY*IfList
>)
>  {
> -  EFI_STATUSStatus;
> +  EFI_STATUSStatus;
> +  SHELL_STATUS  ShellStatus;
>LIST_ENTRY*Entry;
>LIST_ENTRY*Next;
>IFCONFIG_INTERFACE_CB *IfCb;
>EFI_IP4_CONFIG2_POLICYPolicy;
>
>Policy = Ip4Config2PolicyDhcp;
>Status = EFI_SUCCESS;
> +  ShellStatus = SHELL_SUCCESS;
>
>if (IsListEmpty (IfList)) {
>  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
> (STR_IFCONFIG_INVALID_INTERFACE), gShellNetwork1HiiHandle);
>}
>
> @@ -823,37 +825,37 @@ IfConfigClearInterfaceInfo (
>  IfCb->IfCfg,
>  Ip4Config2DataTypePolicy,
>  sizeof (EFI_IP4_CONFIG2_POLICY),
>  
>  );
> -
>  if (EFI_ERROR (Status)) {
> +  ShellStatus = SHELL_ACCESS_DENIED;
>break;
>  }
>}
>
> -  return Status;
> +  return ShellStatus;
>  }
>
>  /**
>The set process of the ifconfig command.
>
>@param[in]   IfListThe pointer of IfList(interface list).
>@param[in]   VarArgThe pointer of ARG_LIST(Args with "-s" option).
>
> -  @retval EFI_SUCCESSThe ifconfig command set processed successfully.
> +  @retval SHELL_SUCCESS  The ifconfig command 

Re: [edk2] [PATCH 3/5] SecurityPkg: put missing empty lines at the end of some header files

[Zhang, Chao B]

Ard:
  It is good to me. Reviewed-by: Chao Zhang 





Thanks & Best regards
Chao Zhang


-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Thursday, December 03, 2015 4:38 PM
To: edk2-devel@lists.01.org; Zhang, Chao B
Cc: Gao, Liming
Subject: Re: [PATCH 3/5] SecurityPkg: put missing empty lines at the end of 
some header files

On 2 December 2015 at 18:02, Ard Biesheuvel  wrote:
> Some compilers (like RVCT) reject input files that do not end in a 
> newline. So add missing newlines to some SecurityPkg header files.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Hello Chao,

Do you have any comments on this patch?

Thanks,
Ard.



> ---
>  SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.h
>   | 2 +-
>  SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.h 
>   | 2 +-
>  
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig
> NvData.h | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git 
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
> h 
> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
> h index b09ef8afd3e1..cff6076368b5 100644
> --- 
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
> h
> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerification
> +++ Lib.h
> @@ -204,4 +204,4 @@ typedef struct {
>HASH_FINAL   HashFinal;
>  } HASH_TABLE;
>
> -#endif
> \ No newline at end of file
> +#endif
> diff --git 
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConf
> igImpl.h 
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConf
> igImpl.h index 228f44bde814..bcb1c12e2314 100644
> --- 
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConf
> igImpl.h
> +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBoot
> +++ ConfigImpl.h
> @@ -621,4 +621,4 @@ GuidToString (
>IN  UINTN BufferSize
>);
>
> -#endif
> \ No newline at end of file
> +#endif
> diff --git 
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConf
> igNvData.h 
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConf
> igNvData.h index b628bcb1f532..7aebc1f99e85 100644
> --- 
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConf
> igNvData.h
> +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBoot
> +++ ConfigNvData.h
> @@ -133,4 +133,4 @@ typedef struct {
>EFI_HII_TIME RevocationTime; // The revocation time of the 
> certificate  } SECUREBOOT_CONFIGURATION;
>
> -#endif
> \ No newline at end of file
> +#endif
> --
> 1.9.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 3/4] CryptoPkg/OpensslLib: comment out unused code

[Ard Biesheuvel]

This comments out the pqueue and ts_* source files from the OpensslLib
build, since they have no users.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 CryptoPkg/Library/OpensslLib/OpensslLib.inf | 24 ++--
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index 20200c33f621..383a828471b1 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -813,22 +813,22 @@ [Sources]
   #
   # PQUEUE
   #
-  $(OPENSSL_PATH)/crypto/pqueue/pqueue.c
+  #$(OPENSSL_PATH)/crypto/pqueue/pqueue.c
 
   #
   # TS
   #
-  $(OPENSSL_PATH)/crypto/ts/ts_err.c
-  $(OPENSSL_PATH)/crypto/ts/ts_req_utils.c
-  $(OPENSSL_PATH)/crypto/ts/ts_req_print.c
-  $(OPENSSL_PATH)/crypto/ts/ts_rsp_utils.c
-  $(OPENSSL_PATH)/crypto/ts/ts_rsp_print.c
-  $(OPENSSL_PATH)/crypto/ts/ts_rsp_sign.c
-  $(OPENSSL_PATH)/crypto/ts/ts_rsp_verify.c
-  $(OPENSSL_PATH)/crypto/ts/ts_verify_ctx.c
-  $(OPENSSL_PATH)/crypto/ts/ts_lib.c
-  $(OPENSSL_PATH)/crypto/ts/ts_conf.c
-  $(OPENSSL_PATH)/crypto/ts/ts_asn1.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_err.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_req_utils.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_req_print.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_rsp_utils.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_rsp_print.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_rsp_sign.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_rsp_verify.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_verify_ctx.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_lib.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_conf.c
+  #$(OPENSSL_PATH)/crypto/ts/ts_asn1.c
 
   #
   # SRP - Disabled by OPENSSL_NO_SRP
-- 
1.9.1

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

[edk2] [PATCH 2/4] CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC

[Ard Biesheuvel]

Make mVirtualAddressChangeEvent STATIC to prevent it from conflicting
with other variables of the same name that may be defined in other
libraries (e.g., MdeModulePkg/Universal/Variable/RuntimeDxe)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c 
b/CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c
index 79bb0678e376..616ee7717e72 100644
--- a/CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c
+++ b/CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c
@@ -64,7 +64,7 @@ RT_MEMORY_PAGE_TABLE  *mRTPageTable = NULL;
 //
 // Event for Runtime Address Conversion.
 //
-EFI_EVENT mVirtualAddressChangeEvent;
+STATIC EFI_EVENT  mVirtualAddressChangeEvent;
 
 
 /**
-- 
1.9.1

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

[edk2] [PATCH 0/4] CryptoPkg: fix ARM and RVCT issues

[Ard Biesheuvel]

These fixes some minor issues in CryptoPkg that prevent CryptoPkg.dsc and
OpensslLib from being built for ARM in general, and using RVCT in particular.

Note that I sent out a separate single patch that touches CryptoPkg as well,
before I realized that there were more issues to address. This series, combined
with the other patch, should supersede the combined patch sent out by Eugene on
the 24th of Nov.

Ard Biesheuvel (4):
  CryptoPkg ARM: add ArmSoftFloatLib resolution to CryptoPkg.dsc
  CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC
  CryptoPkg/OpensslLib: comment out unused code
  CryptoPkg/OpensslLib: ignore more false positive warnings for RVCT

 CryptoPkg/CryptoPkg.dsc   |  3 ++
 CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c |  2 +-
 CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 32 

 3 files changed, 23 insertions(+), 14 deletions(-)

-- 
1.9.1

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

[edk2] [PATCH 1/4] CryptoPkg ARM: add ArmSoftFloatLib resolution to CryptoPkg.dsc

[Ard Biesheuvel]

In order to build the ARM version of CryptoPkg from its own .DSC file,
it needs a resolution for the ArmSoftFloatLib dependency of OpensslLib.

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

diff --git a/CryptoPkg/CryptoPkg.dsc b/CryptoPkg/CryptoPkg.dsc
index 19a0fbcf4361..043704067a22 100644
--- a/CryptoPkg/CryptoPkg.dsc
+++ b/CryptoPkg/CryptoPkg.dsc
@@ -63,6 +63,9 @@ [LibraryClasses.ARM, LibraryClasses.AARCH64]
   # Add support for stack protector
   NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
 
+[LibraryClasses.ARM]
+  ArmSoftFloatLib|ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
+
 [LibraryClasses.common.PEIM]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
 
-- 
1.9.1

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

[edk2] [PATCH 4/4] CryptoPkg/OpensslLib: ignore more false positive warnings for RVCT

[Ard Biesheuvel]

The RVCT compiler chokes on a couple of issues in upstream OpenSSL that
can be confirmed to be non-issues by inspection. So just ignore these
warnings entirely.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 CryptoPkg/Library/OpensslLib/OpensslLib.inf | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index 383a828471b1..1b17c313fdf8 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -892,6 +892,12 @@ [BuildOptions]
   #  513: a value of type  cannot be assigned to an entity of type 
   #  188: enumerated type mixed with another type (i.e. passing an integer as 
an enum without a cast)
   # 1296: Extended constant initialiser used
-  RVCT:*_*_ARM_CC_FLAGS = $(OPENSSL_FLAGS) 
--library_interface=aeabi_clib99 
--diag_suppress=1296,1295,550,1293,111,68,177,223,144,513,188
+  #  128: loop is not reachable - may be emitted inappropriately if code 
follows a conditional return
+  #   from the function that evaluates to true at compile time
+  #  546: transfer of control bypasses initialization - may be emitted 
inappropriately if the uninitialized
+  #   variable is never referenced after the jump
+  # 4017:  may be used before being set - may be emitted inappropriately 
if  is set unconditionally
+  #   inside a loop that is guaranteed to execute at least once
+  RVCT:*_*_ARM_CC_FLAGS = $(OPENSSL_FLAGS) 
--library_interface=aeabi_clib99 
--diag_suppress=1296,1295,550,1293,111,68,177,223,144,513,188,128,546,4017
   XCODE:*_*_IA32_CC_FLAGS   = -mmmx -msse -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) -w
   XCODE:*_*_X64_CC_FLAGS= -mmmx -msse -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) -w
-- 
1.9.1

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

[edk2] HOB build/get and size changing

[Hamel, Lee M]

I have a strange issue with a block of code that is causing an ASSERT.  I call 
BuildGuidDataHob() with a size of 4, and somehow it is changing to 8.
When I add code after BuildGuidDataHob() to get the HOB and output the size, I 
see size of 8 as returned by GET_GUID_HOB_DATA_SIZE() macro.
I have debugged all the way into InternalMemCopyMem() and see a single DWORD 
being copied (ECX=1 before "rev movsd").  I'm starting to think
that there is some funny compiler bug.  I am building with Visual Studio 2010.  
Any thoughts?

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

Re: [edk2] HOB build/get and size changing

[Gao, Liming]

Lee:
  Per PI spec Volume 3 4.5.2 HOB Construction Rules, all HOBs must be multiples 
of 8 bytes in length. PEI CreateHob() service will adjust HOB length to meet 
this requirement. So, you find the hob data size becomes to 8 from 4. 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hamel, 
Lee M
Sent: Thursday, December 03, 2015 4:47 PM
To: edk2-devel@lists.01.org
Subject: [edk2] HOB build/get and size changing

I have a strange issue with a block of code that is causing an ASSERT.  I call 
BuildGuidDataHob() with a size of 4, and somehow it is changing to 8.
When I add code after BuildGuidDataHob() to get the HOB and output the size, I 
see size of 8 as returned by GET_GUID_HOB_DATA_SIZE() macro.
I have debugged all the way into InternalMemCopyMem() and see a single DWORD 
being copied (ECX=1 before "rev movsd").  I'm starting to think that there is 
some funny compiler bug.  I am building with Visual Studio 2010.  Any thoughts?

___
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 4/4] CryptoPkg/OpensslLib: ignore more false positive warnings for RVCT

[Ard Biesheuvel]

On 3 December 2015 at 12:26, Ard Biesheuvel  wrote:
> On 3 December 2015 at 12:17, David Woodhouse  wrote:
>> On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
>>> The RVCT compiler chokes on a couple of issues in upstream OpenSSL
>>> that
>>> can be confirmed to be non-issues by inspection. So just ignore these
>>> warnings entirely.
>>
>> I still maintain this needs a reference to bug reports — either
>> *compiler* bugs, if the compiler is just being entirely stupid, or
>> OpenSSL RT tickets.
>>
>> Or both, since it's possible to work around it compiler issues in the
>> source code even if it's actually the *compiler* at fault.
>>
>> But in no circumstance is it acceptable for such a patch to reference
>> *neither* a compiler nor a source bug, surely?
>>
>
> I don't think OpenSSL upstream is at fault here in any of the cases,
> and I definitely would not recommend obfuscating OpenSSL to make RVCT
> happy even if some instances could be easily solved by adding a
> redundant zero initializer, since such changes often do more evil than
> good.
>
> So that leaves reporting bugs to ARM regarding RVCT. I guess that
> should be an option, perhaps Eugene can take this up, being an actual
> paying ARM customer? Note than I work for Linaro, not for ARM (unlike
> Leif, who is an ARM employee that is seconded to Linaro), so of the
> people involved, I am definitely not in the best position to chase
> this.
>

... and by the way, I see the following list for MSFT compiler:

  # C4244: conversion from type1 to type2, possible loss of data
  # C4702: unreachable code
  # C4706: assignment within conditional expression
  # C4133: incompatible types - from type1 to type2
  # C4245: conversion from type1 to type2, signed/unsigned mismatch
  # C4267: conversion from size_t to type, possible loss of data
  # C4305: truncation from type1 to type2 of smaller size
  # C4306: conversion from type1 to type2 of greater size
  # C4702: Potentially uninitialized local variable name used

where at least two seem to overlap with the three I am adding here:
4702 and 4706 (which I think the second occurrence of C4702 is
supposed to refer to)

Are you saying that all of the issues have been reported to either
OpenSSL or Microsoft? Or does this apply to RVCT only?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 3/3] UefiCpuPkg/MtrrLib: Add MtrrSetMemoryAttributeInMtrrSettings()

[Jeff Fan]

Add new API MtrrSetMemoryAttributeInMtrrSettings() in MtrrLib. Platform could
use this API to set MTRR setting into local MTRR settings buffer instead of
MTRRs. At last, platform could use MtrrSetAllMtrrs() to set the MTRR settings
into MTRRs totally. It could improve MTRRs programming performance obviously,
specially when platform is going to program a set of MTRRs.

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

UefiCpuPkg/MtrrLib: Print MTRR settings when set fixed/variable MTRRs

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Include/Library/MtrrLib.h |  31 
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 140 ++-
 2 files changed, 151 insertions(+), 20 deletions(-)

diff --git a/UefiCpuPkg/Include/Library/MtrrLib.h 
b/UefiCpuPkg/Include/Library/MtrrLib.h
index 884c7bb..36cd2cd 100644
--- a/UefiCpuPkg/Include/Library/MtrrLib.h
+++ b/UefiCpuPkg/Include/Library/MtrrLib.h
@@ -352,4 +352,35 @@ MtrrGetDefaultMemoryType (
   VOID
   );
 
+/**
+  This function attempts to set the attributes into MTRR setting buffer for a 
memory range.
+
+  @param[in, out]  MtrrSetting  MTRR setting buffer to be set.
+  @param[in]   BaseAddress  The physical address that is the start address
+of a memory region.
+  @param[in]   Length   The size in bytes of the memory region.
+  @param[in]   AttributeThe bit mask of attributes to set for the
+memory region.
+
+  @retval RETURN_SUCCESSThe attributes were set for the memory 
region.
+  @retval RETURN_INVALID_PARAMETER  Length is zero.
+  @retval RETURN_UNSUPPORTEDThe processor does not support one or more 
bytes of the
+memory resource range specified by 
BaseAddress and Length.
+  @retval RETURN_UNSUPPORTEDThe bit mask of attributes is not support 
for the memory resource
+range specified by BaseAddress and Length.
+  @retval RETURN_ACCESS_DENIED  The attributes for the memory resource 
range specified by
+BaseAddress and Length cannot be modified.
+  @retval RETURN_OUT_OF_RESOURCES   There are not enough system resources to 
modify the attributes of
+the memory resource range.
+
+**/
+RETURN_STATUS
+EFIAPI
+MtrrSetMemoryAttributeInMtrrSettings (
+  IN OUT MTRR_SETTINGS   *MtrrSetting,
+  IN PHYSICAL_ADDRESSBaseAddress,
+  IN UINT64  Length,
+  IN MTRR_MEMORY_CACHE_TYPE  Attribute
+  );
+
 #endif // _MTRR_LIB_H_
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index a5bfa88..f5b3460 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -1424,6 +1424,11 @@ MtrrDebugPrintAllMtrrs (
 /**
   Worker function attempts to set the attributes for a memory range.
 
+  If MtrrSettings is not NULL, set the attributes into the input MTRR
+  settings buffer.
+  If MtrrSettings is NULL, set the attributes into MTRRs registers.
+
+  @param[in, out]  MtrrSetting   A buffer holding all MTRRs content.
   @param[in]   BaseAddress   The physical address that is the start
  address of a memory region.
   @param[in]   LengthThe size in bytes of the memory region.
@@ -1448,11 +1453,11 @@ MtrrDebugPrintAllMtrrs (
 
 **/
 RETURN_STATUS
-EFIAPI
-MtrrSetMemoryAttribute (
-  IN PHYSICAL_ADDRESSBaseAddress,
-  IN UINT64  Length,
-  IN MTRR_MEMORY_CACHE_TYPE  Attribute
+MtrrSetMemoryAttributeWorker (
+  IN OUT MTRR_SETTINGS   *MtrrSetting,
+  IN PHYSICAL_ADDRESSBaseAddress,
+  IN UINT64  Length,
+  IN MTRR_MEMORY_CACHE_TYPE  Attribute
   )
 {
   UINT64TempQword;
@@ -1484,7 +1489,6 @@ MtrrSetMemoryAttribute (
   UINT64NewValue;
   MTRR_VARIABLE_SETTINGS*VariableSettings;
 
-  DEBUG((DEBUG_CACHE, "MtrrSetMemoryAttribute() %a:%016lx-%016lx\n", 
mMtrrMemoryCacheTypeShortName[Attribute], BaseAddress, Length));
   MtrrContextValid = FALSE;
   for (Index = 0; Index < MTRR_NUMBER_OF_FIXED_MTRR; Index++) {
 FixedSettingsValid[Index]= FALSE;
@@ -1529,14 +1533,19 @@ MtrrSetMemoryAttribute (
   if (RETURN_ERROR (Status)) {
 goto Done;
   }
-  if (!FixedSettingsValid[MsrNum]) {
-WorkingFixedSettings.Mtrr[MsrNum] = AsmReadMsr64 
(mMtrrLibFixedMtrrTable[MsrNum].Msr);
-FixedSettingsValid[MsrNum] = TRUE;
-  }
-  NewValue = (WorkingFixedSettings.Mtrr[MsrNum] & ~ClearMask) | OrMask;
-  if 

[edk2] [Patch 8/8] UefiCpuPkg/MtrrLib: Print MTRR settings when set fixed/variable MTRRs

[Jeff Fan]

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 0e76e2f..d29aca2 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -1756,6 +1756,8 @@ MtrrSetVariableMtrr (
   PreMtrrChange ();
   MtrrSetVariableMtrrWorker (VariableSettings);
   PostMtrrChange ();
+  MtrrDebugPrintAllMtrrs ();
+
   return  VariableSettings;
 }
 
@@ -1804,6 +1806,7 @@ MtrrSetFixedMtrr (
   PreMtrrChange ();
   MtrrSetFixedMtrrWorker (FixedSettings);
   PostMtrrChange ();
+  MtrrDebugPrintAllMtrrs ();
 
   return FixedSettings;
 }
@@ -1888,9 +1891,12 @@ MtrrSetAllMtrrs (
 
   PostMtrrChangeEnableCache ();
 
+  MtrrDebugPrintAllMtrrs ();
+
   return MtrrSetting;
 }
 
+
 /**
   Checks if MTRR is supported.
 
-- 
1.9.5.msysgit.0

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

[edk2] [Patch 5/8] UefiCpuPkg/MtrrLib: Add MtrrGetMemoryAttributeInVariableMtrrWorker ()

[Jeff Fan]

Add function to shadow the content of variable MTRRs into an internal array:
VariableMtrr. And used MtrrGetMemoryAttributeInVariableMtrrWorker() in other
functions.

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 121 ---
 1 file changed, 82 insertions(+), 39 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 0358fff..697dc43 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -496,6 +496,50 @@ ProgramFixedMtrr (
 
 
 /**
+  Worker function gets the attribute of variable MTRRs.
+
+  This function shadows the content of variable MTRRs into an
+  internal array: VariableMtrr.
+
+  @param[in]   VariableSettings   The variable MTRR values to shadow
+  @param[in]   FirmwareVariableMtrrCount  The number of variable MTRRs 
available to firmware
+  @param[in]   MtrrValidBitsMask  The mask for the valid bit of the 
MTRR
+  @param[in]   MtrrValidAddressMask   The valid address mask for MTRR
+  @param[out]  VariableMtrr   The array to shadow variable MTRRs 
content
+
+  @return   The return value of this parameter indicates 
the
+number of MTRRs which has been used.
+
+**/
+UINT32
+MtrrGetMemoryAttributeInVariableMtrrWorker (
+  IN  MTRR_VARIABLE_SETTINGS  *VariableSettings,
+  IN  UINTN   FirmwareVariableMtrrCount,
+  IN  UINT64  MtrrValidBitsMask,
+  IN  UINT64  MtrrValidAddressMask,
+  OUT VARIABLE_MTRR   *VariableMtrr
+  )
+{
+  UINTN   Index;
+  UINT32  UsedMtrr;
+
+  ZeroMem (VariableMtrr, sizeof (VARIABLE_MTRR) * 
MTRR_NUMBER_OF_VARIABLE_MTRR);
+  for (Index = 0, UsedMtrr = 0; Index < FirmwareVariableMtrrCount; Index++) {
+if ((VariableSettings->Mtrr[Index].Mask & MTRR_LIB_CACHE_MTRR_ENABLED) != 
0) {
+  VariableMtrr[Index].Msr = (UINT32)Index;
+  VariableMtrr[Index].BaseAddress = (VariableSettings->Mtrr[Index].Base & 
MtrrValidAddressMask);
+  VariableMtrr[Index].Length  = ((~(VariableSettings->Mtrr[Index].Mask 
& MtrrValidAddressMask)) & MtrrValidBitsMask) + 1;
+  VariableMtrr[Index].Type= (VariableSettings->Mtrr[Index].Base & 
0x0ff);
+  VariableMtrr[Index].Valid   = TRUE;
+  VariableMtrr[Index].Used= TRUE;
+  UsedMtrr++;
+}
+  }
+  return UsedMtrr;
+}
+
+
+/**
   Gets the attribute of variable MTRRs.
 
   This function shadows the content of variable MTRRs into an
@@ -517,46 +561,24 @@ MtrrGetMemoryAttributeInVariableMtrr (
   OUT VARIABLE_MTRR *VariableMtrr
   )
 {
-  UINTN   Index;
-  UINT32  MsrNum;
-  UINT32  UsedMtrr;
-  UINT32  FirmwareVariableMtrrCount;
-  UINT32  VariableMtrrEnd;
+  MTRR_VARIABLE_SETTINGS  VariableSettings;
 
   if (!IsMtrrSupported ()) {
 return 0;
   }
 
-  FirmwareVariableMtrrCount = GetFirmwareVariableMtrrCountWorker ();
-  VariableMtrrEnd = MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (2 * 
GetVariableMtrrCount ()) - 1;
-
-  ZeroMem (VariableMtrr, sizeof (VARIABLE_MTRR) * 
MTRR_NUMBER_OF_VARIABLE_MTRR);
-  UsedMtrr = 0;
+  MtrrGetVariableMtrrWorker (
+GetVariableMtrrCountWorker (),
+
+);
 
-  for (MsrNum = MTRR_LIB_IA32_VARIABLE_MTRR_BASE, Index = 0;
-   (
- (MsrNum < VariableMtrrEnd) &&
- (Index < FirmwareVariableMtrrCount)
-   );
-   MsrNum += 2
-  ) {
-if ((AsmReadMsr64 (MsrNum + 1) & MTRR_LIB_CACHE_MTRR_ENABLED) != 0) {
-  VariableMtrr[Index].Msr  = MsrNum;
-  VariableMtrr[Index].BaseAddress  = (AsmReadMsr64 (MsrNum) &
-  MtrrValidAddressMask);
-  VariableMtrr[Index].Length   = ((~(AsmReadMsr64 (MsrNum + 1) &
- MtrrValidAddressMask)
-  ) &
-  MtrrValidBitsMask
- ) + 1;
-  VariableMtrr[Index].Type = (AsmReadMsr64 (MsrNum) & 0x0ff);
-  VariableMtrr[Index].Valid= TRUE;
-  VariableMtrr[Index].Used = TRUE;
-  UsedMtrr = UsedMtrr  + 1;
-  Index++;
-}
-  }
-  return UsedMtrr;
+  return MtrrGetMemoryAttributeInVariableMtrrWorker (
+   ,
+   GetFirmwareVariableMtrrCountWorker (),
+   MtrrValidBitsMask,
+   MtrrValidAddressMask,
+   VariableMtrr
+   );
 }
 
 
@@ -1092,6 +1114,7 @@ MtrrGetMemoryAttribute (
   UINT64  MtrrValidBitsMask;
   UINT64  MtrrValidAddressMask;
   UINTN   VariableMtrrCount;
+  MTRR_VARIABLE_SETTINGS  VariableSettings;
 
   if (!IsMtrrSupported ()) {
 return CacheUncacheable;
@@ -1133,12 +1156,20 @@ MtrrGetMemoryAttribute (
 

[edk2] [Patch 6/8] UefiCpuPkg/MtrrLib: Reduce hardware init when program fixed MTRRs

[Jeff Fan]

When MtrrSetMemoryAttribute() programs fixed MTRRs, it may disable/enable cache
and disable/enable MTRRs several times. This updating tries to do operation in
local variable and does the hardware initialization one time only.

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 90 
 1 file changed, 70 insertions(+), 20 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 697dc43..322f47b 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -415,6 +415,9 @@ MtrrGetVariableMtrr (
   @param[in]  MemoryCacheType  The memory type to set.
   @param[in, out] Base The base address of memory range.
   @param[in, out] Length   The length of memory range.
+  @param[out] ReturnMsrNum The index of the fixed MTRR MSR to program.
+  @param[out] ReturnClearMask  The bits to clear in the fixed MTRR MSR.
+  @param[out] ReturnOrMask The bits to set in the fixed MTRR MSR.
 
   @retval RETURN_SUCCESS  The cache type was updated successfully
   @retval RETURN_UNSUPPORTED  The requested range or cache type was invalid
@@ -423,9 +426,12 @@ MtrrGetVariableMtrr (
 **/
 RETURN_STATUS
 ProgramFixedMtrr (
-  IN UINT64 MemoryCacheType,
-  IN OUT UINT64 *Base,
-  IN OUT UINT64 *Length
+  IN UINT64   MemoryCacheType,
+  IN OUT UINT64   *Base,
+  IN OUT UINT64   *Length,
+  OUTUINT32   *ReturnMsrNum,
+  OUTUINT64   *ReturnClearMask,
+  OUTUINT64   *ReturnOrMask
   )
 {
   UINT32  MsrNum;
@@ -488,9 +494,10 @@ ProgramFixedMtrr (
 return RETURN_UNSUPPORTED;
   }
 
-  TempQword =
-(AsmReadMsr64 (mMtrrLibFixedMtrrTable[MsrNum].Msr) & ~ClearMask) | OrMask;
-  AsmWriteMsr64 (mMtrrLibFixedMtrrTable[MsrNum].Msr, TempQword);
+  *ReturnMsrNum= MsrNum;
+  *ReturnClearMask = ClearMask;
+  *ReturnOrMask= OrMask;
+
   return RETURN_SUCCESS;
 }
 
@@ -1388,12 +1395,25 @@ MtrrSetMemoryAttribute (
   UINT32FirmwareVariableMtrrCount;
   UINT32VariableMtrrEnd;
   MTRR_CONTEXT  MtrrContext;
+  BOOLEAN   MtrrContextValid;
+  BOOLEAN   FixedSettingsValid[MTRR_NUMBER_OF_FIXED_MTRR];
+  BOOLEAN   FixedSettingsModified[MTRR_NUMBER_OF_FIXED_MTRR];
+  MTRR_FIXED_SETTINGS   WorkingFixedSettings;
   UINT32VariableMtrrCount;
   MTRR_VARIABLE_SETTINGSOriginalVariableSettings;
   MTRR_VARIABLE_SETTINGSWorkingVariableSettings;
+  UINT32Index;
+  UINT64ClearMask;
+  UINT64OrMask;
+  UINT64NewValue;
   MTRR_VARIABLE_SETTINGS*VariableSettings;
 
   DEBUG((DEBUG_CACHE, "MtrrSetMemoryAttribute() %a:%016lx-%016lx\n", 
mMtrrMemoryCacheTypeShortName[Attribute], BaseAddress, Length));
+  MtrrContextValid = FALSE;
+  for (Index = 0; Index < MTRR_NUMBER_OF_FIXED_MTRR; Index++) {
+FixedSettingsValid[Index]= FALSE;
+FixedSettingsModified[Index] = FALSE;
+  }
 
   if (!IsMtrrSupported ()) {
 Status = RETURN_UNSUPPORTED;
@@ -1429,22 +1449,31 @@ MtrrSetMemoryAttribute (
   // Check if Fixed MTRR
   //
   Status = RETURN_SUCCESS;
-  while ((BaseAddress < BASE_1MB) && (Length > 0) && Status == RETURN_SUCCESS) 
{
-PreMtrrChange ();
-Status = ProgramFixedMtrr (MemoryType, , );
-PostMtrrChange ();
-if (RETURN_ERROR (Status)) {
-  goto Done;
+  if (BaseAddress < BASE_1MB) {
+while ((BaseAddress < BASE_1MB) && (Length > 0) && Status == 
RETURN_SUCCESS) {
+  Status = ProgramFixedMtrr (MemoryType, , , , 
, );
+  if (RETURN_ERROR (Status)) {
+goto Done;
+  }
+  if (!FixedSettingsValid[MsrNum]) {
+WorkingFixedSettings.Mtrr[MsrNum] = AsmReadMsr64 
(mMtrrLibFixedMtrrTable[MsrNum].Msr);
+FixedSettingsValid[MsrNum] = TRUE;
+  }
+  NewValue = (WorkingFixedSettings.Mtrr[MsrNum] & ~ClearMask) | OrMask;
+  if (WorkingFixedSettings.Mtrr[MsrNum] != NewValue) {
+WorkingFixedSettings.Mtrr[MsrNum] = NewValue;
+FixedSettingsModified[MsrNum] = TRUE;
+  }
 }
-  }
 
-  if (Length == 0) {
-//
-// A Length of 0 can only make sense for fixed MTTR ranges.
-// Since we just handled the fixed MTRRs, we can skip the
-// variable MTRR section.
-//
-goto Done;
+if (Length == 0) {
+  //
+  // A Length of 0 can only make sense for fixed MTTR ranges.
+  // Since we just handled the fixed MTRRs, we can skip the
+  // variable MTRR section.
+  //
+  goto Done;
+}
   }
 
   //
@@ -1634,6 +1663,27 @@ MtrrSetMemoryAttribute (
   } while (TempQword > 0);
 
 Done:
+
+  //
+  // 

[edk2] [Patch 4/8] UefiCpuPkg/MtrrLib: Make use of worker functions to get MTRRs count

[Jeff Fan]

Try to make use of worker functions to get MTRRs count. It could avoid invoking
IsMtrrSupported() for many times.

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 76 
 1 file changed, 51 insertions(+), 25 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index ea2b211..0358fff 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -367,13 +367,12 @@ MtrrGetFixedMtrr (
 **/
 MTRR_VARIABLE_SETTINGS*
 MtrrGetVariableMtrrWorker (
+  IN  UINT32  VariableMtrrCount,
   OUT MTRR_VARIABLE_SETTINGS  *VariableSettings
   )
 {
   UINT32  Index;
-  UINT32  VariableMtrrCount;
 
-  VariableMtrrCount = GetVariableMtrrCount ();
   ASSERT (VariableMtrrCount <= MTRR_NUMBER_OF_VARIABLE_MTRR);
 
   for (Index = 0; Index < VariableMtrrCount; Index++) {
@@ -405,6 +404,7 @@ MtrrGetVariableMtrr (
   }
 
   return MtrrGetVariableMtrrWorker (
+   GetVariableMtrrCountWorker (),
VariableSettings
);
 }
@@ -527,7 +527,7 @@ MtrrGetMemoryAttributeInVariableMtrr (
 return 0;
   }
 
-  FirmwareVariableMtrrCount = GetFirmwareVariableMtrrCount ();
+  FirmwareVariableMtrrCount = GetFirmwareVariableMtrrCountWorker ();
   VariableMtrrEnd = MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (2 * 
GetVariableMtrrCount ()) - 1;
 
   ZeroMem (VariableMtrr, sizeof (VARIABLE_MTRR) * 
MTRR_NUMBER_OF_VARIABLE_MTRR);
@@ -563,6 +563,8 @@ MtrrGetMemoryAttributeInVariableMtrr (
 /**
   Checks overlap between given memory range and MTRRs.
 
+  @param[in]  FirmwareVariableMtrrCount  The number of variable MTRRs available
+ to firmware.
   @param[in]  Start  The start address of memory range.
   @param[in]  EndThe end address of memory range.
   @param[in]  VariableMtrr   The array to shadow variable MTRRs 
content
@@ -573,14 +575,15 @@ MtrrGetMemoryAttributeInVariableMtrr (
 **/
 BOOLEAN
 CheckMemoryAttributeOverlap (
-  IN PHYSICAL_ADDRESS Start,
-  IN PHYSICAL_ADDRESS End,
-  IN VARIABLE_MTRR  *VariableMtrr
+  IN UINTN FirmwareVariableMtrrCount,
+  IN PHYSICAL_ADDRESS  Start,
+  IN PHYSICAL_ADDRESS  End,
+  IN VARIABLE_MTRR *VariableMtrr
   )
 {
   UINT32  Index;
 
-  for (Index = 0; Index < 6; Index++) {
+  for (Index = 0; Index < FirmwareVariableMtrrCount; Index++) {
 if (
  VariableMtrr[Index].Valid &&
  !(
@@ -623,6 +626,8 @@ InvalidateShadowMtrr (
 
   If overlap exists between given memory range and MTRRs, try to combine them.
 
+  @param[in]   FirmwareVariableMtrrCount  The number of variable MTRRs
+  available to firmware.
   @param[in]   Attributes The memory type to set.
   @param[in, out]  Base   The base address of memory range.
   @param[in, out]  Length The length of memory range.
@@ -636,6 +641,7 @@ InvalidateShadowMtrr (
 **/
 RETURN_STATUS
 CombineMemoryAttribute (
+  IN UINT32 FirmwareVariableMtrrCount,
   IN UINT64 Attributes,
   IN OUT UINT64 *Base,
   IN OUT UINT64 *Length,
@@ -649,11 +655,8 @@ CombineMemoryAttribute (
   UINT64  CombineEnd;
   UINT64  MtrrEnd;
   UINT64  EndAddress;
-  UINT32  FirmwareVariableMtrrCount;
   BOOLEAN CoveredByExistingMtrr;
 
-  FirmwareVariableMtrrCount = GetFirmwareVariableMtrrCount ();
-
   *OverwriteExistingMtrr = FALSE;
   CoveredByExistingMtrr = FALSE;
   EndAddress = *Base +*Length - 1;
@@ -851,21 +854,21 @@ GetMtrrNumberAndDirection (
   This function programs MTRRs according to the values specified
   in the shadow array.
 
+  @param[in]   VariableMtrrCount  Number of variable MTRRs
   @param[in, out]  VariableMtrr   Shadow of variable MTRR contents
 
 **/
 VOID
 InvalidateMtrr (
+  IN UINTN   VariableMtrrCount,
   IN OUT VARIABLE_MTRR   *VariableMtrr
   )
 {
   UINTN Index;
-  UINTN VariableMtrrCount;
   MTRR_CONTEXT  MtrrContext;
 
   PreMtrrChange ();
   Index = 0;
-  VariableMtrrCount = GetVariableMtrrCount ();
   while (Index < VariableMtrrCount) {
 if (!VariableMtrr[Index].Valid && VariableMtrr[Index].Used) {
AsmWriteMsr64 (VariableMtrr[Index].Msr, 0);
@@ -1139,7 +1142,7 @@ MtrrGetMemoryAttribute (
   //
   // Go through the variable MTRR
   //
-  VariableMtrrCount = GetVariableMtrrCount ();
+  VariableMtrrCount = GetVariableMtrrCountWorker ();
   ASSERT (VariableMtrrCount <= MTRR_NUMBER_OF_VARIABLE_MTRR);
 
   for (Index = 0; Index < VariableMtrrCount; Index++) {
@@ -1354,6 +1357,7 @@ MtrrSetMemoryAttribute (
   UINT32FirmwareVariableMtrrCount;
   UINT32   

[edk2] [Patch 2/3] UefiCpuPkg/MtrrLib: Add MtrrDebugPrintAllMtrrsWorker()

[Jeff Fan]

MtrrDebugPrintAllMtrrsWorker() provides the capability to dump the MTRR setting
from MTRRs or the input MTRR settings buffer.

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 60 ++--
 1 file changed, 43 insertions(+), 17 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 4c76abf..a5bfa88 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -1248,18 +1248,23 @@ MtrrGetMemoryAttribute (
   return MtrrGetMemoryAttributeByAddressWorker (NULL, Address);
 }
 
-
 /**
-  This function prints all MTRRs for debugging.
+  Worker function prints all MTRRs for debugging.
+
+  If MtrrSetting is not NULL, print MTRR settings from from input MTRR
+  settings buffer.
+  If MtrrSetting is NULL, print MTRR settings from MTRRs.
+
+  @param  MtrrSettingA buffer holding all MTRRs content.
 **/
 VOID
-EFIAPI
-MtrrDebugPrintAllMtrrs (
-  VOID
+MtrrDebugPrintAllMtrrsWorker (
+  IN MTRR_SETTINGS*MtrrSetting
   )
 {
   DEBUG_CODE (
-MTRR_SETTINGS  MtrrSettings;
+MTRR_SETTINGS  LocalMtrrs;
+MTRR_SETTINGS  *Mtrrs;
 UINTN  Index;
 UINTN  Index1;
 UINTN  VariableMtrrCount;
@@ -1283,18 +1288,24 @@ MtrrDebugPrintAllMtrrs (
 DEBUG((DEBUG_CACHE, "MTRR Settings\n"));
 DEBUG((DEBUG_CACHE, "=\n"));
 
-MtrrGetAllMtrrs ();
-DEBUG((DEBUG_CACHE, "MTRR Default Type: %016lx\n", 
MtrrSettings.MtrrDefType));
+if (MtrrSetting != NULL) {
+  Mtrrs = MtrrSetting;
+} else {
+  MtrrGetAllMtrrs ();
+  Mtrrs = 
+}
+
+DEBUG((DEBUG_CACHE, "MTRR Default Type: %016lx\n", Mtrrs->MtrrDefType));
 for (Index = 0; Index < MTRR_NUMBER_OF_FIXED_MTRR; Index++) {
-  DEBUG((DEBUG_CACHE, "Fixed MTRR[%02d]   : %016lx\n", Index, 
MtrrSettings.Fixed.Mtrr[Index]));
+  DEBUG((DEBUG_CACHE, "Fixed MTRR[%02d]   : %016lx\n", Index, 
Mtrrs->Fixed.Mtrr[Index]));
 }
 
 VariableMtrrCount = GetVariableMtrrCount ();
 for (Index = 0; Index < VariableMtrrCount; Index++) {
   DEBUG((DEBUG_CACHE, "Variable MTRR[%02d]: Base=%016lx Mask=%016lx\n",
 Index,
-MtrrSettings.Variables.Mtrr[Index].Base,
-MtrrSettings.Variables.Mtrr[Index].Mask
+Mtrrs->Variables.Mtrr[Index].Base,
+Mtrrs->Variables.Mtrr[Index].Mask
 ));
 }
 DEBUG((DEBUG_CACHE, "\n"));
@@ -1306,7 +1317,7 @@ MtrrDebugPrintAllMtrrs (
 for (Index = 0; Index < MTRR_NUMBER_OF_FIXED_MTRR; Index++) {
   Base = mMtrrLibFixedMtrrTable[Index].BaseAddress;
   for (Index1 = 0; Index1 < 8; Index1++) {
-  MemoryType = (UINTN)(RShiftU64 (MtrrSettings.Fixed.Mtrr[Index], Index1 * 
8) & 0xff);
+  MemoryType = (UINTN)(RShiftU64 (Mtrrs->Fixed.Mtrr[Index], Index1 * 8) & 
0xff);
 if (MemoryType > CacheWriteBack) {
   MemoryType = MTRR_CACHE_INVALID_TYPE;
 }
@@ -1333,7 +1344,7 @@ MtrrDebugPrintAllMtrrs (
 Base = BASE_1MB;
 PreviousMemoryType = MTRR_CACHE_INVALID_TYPE;
 do {
-  MemoryType = MtrrGetMemoryAttribute (Base);
+  MemoryType = MtrrGetMemoryAttributeByAddressWorker (Mtrrs, Base);
   if (MemoryType > CacheWriteBack) {
 MemoryType = MTRR_CACHE_INVALID_TYPE;
   }
@@ -1352,14 +1363,14 @@ MtrrDebugPrintAllMtrrs (
   NoRangeLimit = Limit;
 
   for (Index = 0, Found = FALSE; Index < VariableMtrrCount; Index++) {
-if ((MtrrSettings.Variables.Mtrr[Index].Mask & BIT11) == 0) {
+if ((Mtrrs->Variables.Mtrr[Index].Mask & BIT11) == 0) {
   //
   // If mask is not valid, then do not display range
   //
   continue;
 }
-MtrrBase  = (MtrrSettings.Variables.Mtrr[Index].Base & (~(SIZE_4KB - 
1)));
-MtrrLimit = MtrrBase + ((~(MtrrSettings.Variables.Mtrr[Index].Mask & 
(~(SIZE_4KB - 1 & Limit);
+MtrrBase  = (Mtrrs->Variables.Mtrr[Index].Base & (~(SIZE_4KB - 1)));
+MtrrLimit = MtrrBase + ((~(Mtrrs->Variables.Mtrr[Index].Mask & 
(~(SIZE_4KB - 1 & Limit);
 
 if (Base >= MtrrBase && Base < MtrrLimit) {
   Found = TRUE;
@@ -1395,8 +1406,23 @@ MtrrDebugPrintAllMtrrs (
 DEBUG((DEBUG_CACHE, "%016lx\n\n", Base - 1));
   );
 }
+
+
+/**
+  This function prints all MTRRs for debugging.
+**/
+VOID
+EFIAPI
+MtrrDebugPrintAllMtrrs (
+  VOID
+  )
+{
+  MtrrDebugPrintAllMtrrsWorker (NULL);
+}
+
+
 /**
-  This function attempts to set the attributes for a memory range.
+  Worker function attempts to set the attributes for a memory range.
 
   @param[in]   BaseAddress   The physical address that is the start
  address of a memory region.
-- 
1.9.5.msysgit.0

___
edk2-devel mailing list

[edk2] [Patch 0/8] Reduce hardware operations when program MTRR

[Jeff Fan]

Try to avoid access hardware when program MTRR. It could improve the performance
of MTRR programming.

Jeff Fan (8):
  UefiCpuPkg/MtrrLib: Fix some typo and clean up code format
  UefiCpuPkg/MtrrLib: Add worker functions not invoke IsMtrrSupported()
  UefiCpuPkg/MtrrLib: Adjust functions order
  UefiCpuPkg/MtrrLib: Make use of worker functions to get MTRRs count
  UefiCpuPkg/MtrrLib: Add MtrrGetMemoryAttributeInVariableMtrrWorker ()
  UefiCpuPkg/MtrrLib: Reduce hardware init when program fixed MTRRs
  UefiCpuPkg/MtrrLib: Reduce hardware init when program variable MTRRs
  UefiCpuPkg/MtrrLib: Print MTRR settings when set fixed/variable MTRRs

 UefiCpuPkg/Include/Library/MtrrLib.h |   70 +-
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 1278 --
 2 files changed, 785 insertions(+), 563 deletions(-)

-- 
1.9.5.msysgit.0

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

[edk2] [Patch 1/3] UefiCpuPkg/MtrrLib: Add worker functions to access MTRRs or variable

[Jeff Fan]

Add worker functions that could access MTRRs or MTRR settings in input buffer.

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 106 +++
 1 file changed, 83 insertions(+), 23 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index d29aca2..4c76abf 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -183,15 +183,25 @@ GetFirmwareVariableMtrrCount (
 /**
   Worker function returns the default MTRR cache type for the system.
 
+  If MtrrSetting is not NULL, returns the default MTRR cache type from input
+  MTRR settings buffer.
+  If MtrrSetting is NULL, returns the default MTRR cache type from MSR.
+
+  @param[in]  MtrrSettingA buffer holding all MTRRs content.
+
   @return  The default MTRR cache type.
 
 **/
 MTRR_MEMORY_CACHE_TYPE
 MtrrGetDefaultMemoryTypeWorker (
-  VOID
+  IN MTRR_SETTINGS  *MtrrSetting
   )
 {
-  return (MTRR_MEMORY_CACHE_TYPE) (AsmReadMsr64 (MTRR_LIB_IA32_MTRR_DEF_TYPE) 
& 0x7);
+  if (MtrrSetting == NULL) {
+return (MTRR_MEMORY_CACHE_TYPE) (AsmReadMsr64 
(MTRR_LIB_IA32_MTRR_DEF_TYPE) & 0x7);
+  } else {
+return (MTRR_MEMORY_CACHE_TYPE) (MtrrSetting->MtrrDefType & 0x7);
+  }
 }
 
 
@@ -210,7 +220,7 @@ MtrrGetDefaultMemoryType (
   if (!IsMtrrSupported ()) {
 return CacheUncacheable;
   }
-  return MtrrGetDefaultMemoryTypeWorker ();
+  return MtrrGetDefaultMemoryTypeWorker (NULL);
 }
 
 /**
@@ -360,6 +370,12 @@ MtrrGetFixedMtrr (
 /**
   Worker function will get the raw value in variable MTRRs
 
+  If MtrrSetting is not NULL, gets the variable MTRRs raw value from input
+  MTRR settings buffer.
+  If MtrrSetting is NULL, gets the variable MTRRs raw value from MTRRs.
+
+  @param[in]  MtrrSettingA buffer holding all MTRRs content.
+  @param[in]  VariableMtrrCount  Number of variable MTRRs.
   @param[out] VariableSettings   A buffer to hold variable MTRRs content.
 
   @return The VariableSettings input pointer
@@ -367,6 +383,7 @@ MtrrGetFixedMtrr (
 **/
 MTRR_VARIABLE_SETTINGS*
 MtrrGetVariableMtrrWorker (
+  IN  MTRR_SETTINGS   *MtrrSetting,
   IN  UINT32  VariableMtrrCount,
   OUT MTRR_VARIABLE_SETTINGS  *VariableSettings
   )
@@ -376,10 +393,15 @@ MtrrGetVariableMtrrWorker (
   ASSERT (VariableMtrrCount <= MTRR_NUMBER_OF_VARIABLE_MTRR);
 
   for (Index = 0; Index < VariableMtrrCount; Index++) {
-VariableSettings->Mtrr[Index].Base =
-  AsmReadMsr64 (MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (Index << 1));
-VariableSettings->Mtrr[Index].Mask =
-  AsmReadMsr64 (MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (Index << 1) + 1);
+if (MtrrSetting == NULL) {
+  VariableSettings->Mtrr[Index].Base =
+AsmReadMsr64 (MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (Index << 1));
+  VariableSettings->Mtrr[Index].Mask =
+AsmReadMsr64 (MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (Index << 1) + 1);
+} else {
+  VariableSettings->Mtrr[Index].Base = 
MtrrSetting->Variables.Mtrr[Index].Base;
+  VariableSettings->Mtrr[Index].Mask = 
MtrrSetting->Variables.Mtrr[Index].Mask;
+}
   }
 
   return  VariableSettings;
@@ -404,6 +426,7 @@ MtrrGetVariableMtrr (
   }
 
   return MtrrGetVariableMtrrWorker (
+   NULL,
GetVariableMtrrCountWorker (),
VariableSettings
);
@@ -575,6 +598,7 @@ MtrrGetMemoryAttributeInVariableMtrr (
   }
 
   MtrrGetVariableMtrrWorker (
+NULL,
 GetVariableMtrrCountWorker (),
 
 );
@@ -949,6 +973,11 @@ ProgramVariableMtrr (
 /**
   Converts the Memory attribute value to MTRR_MEMORY_CACHE_TYPE.
 
+  If MtrrSetting is not NULL, gets the default memory attribute from input
+  MTRR settings buffer.
+  If MtrrSetting is NULL, gets the default memory attribute from MSR.
+
+  @param[in]  MtrrSettingA buffer holding all MTRRs content.
   @param[in]  MtrrType   MTRR memory type
 
   @return The enum item in MTRR_MEMORY_CACHE_TYPE
@@ -956,6 +985,7 @@ ProgramVariableMtrr (
 **/
 MTRR_MEMORY_CACHE_TYPE
 GetMemoryCacheTypeFromMtrrType (
+  IN MTRR_SETTINGS *MtrrSetting,
   IN UINT64MtrrType
   )
 {
@@ -975,7 +1005,7 @@ GetMemoryCacheTypeFromMtrrType (
 // MtrrType is MTRR_CACHE_INVALID_TYPE, that means
 // no MTRR covers the range
 //
-return MtrrGetDefaultMemoryType ();
+return MtrrGetDefaultMemoryTypeWorker (MtrrSetting);
   }
 }
 
@@ -1084,21 +1114,22 @@ MtrrPrecedence (
   return MtrrType;
 }
 
-
-
 /**
-  This function will get the memory cache type of the specific address.
+  Worker function will get the memory cache type of the specific address.
 
-  This function is mainly for debug purpose.
+  If MtrrSetting is not NULL, gets the memory cache type from input
+  MTRR settings buffer.
+  If MtrrSetting is 

[edk2] [Patch 0/3] Add MtrrSetMemoryAttributeInMtrrSettings()

[Jeff Fan]

Add new API MtrrSetMemoryAttributeInMtrrSettings() in MtrrLib. Platform could
use this API to set MTRR setting into local MTRR settings buffer instead of
MTRRs. At last, platform could use MtrrSetAllMtrrs() to set the MTRR settings
into MTRRs totally. It could improve MTRRs programming performance obviously,
specially when platform is going to program a set of MTRRs.

Jeff Fan (3):
  UefiCpuPkg/MtrrLib: Add worker functions to access MTRRs or variable
  UefiCpuPkg/MtrrLib: Add MtrrDebugPrintAllMtrrsWorker()
  UefiCpuPkg/MtrrLib: Add MtrrSetMemoryAttributeInMtrrSettings()

 UefiCpuPkg/Include/Library/MtrrLib.h |  31 
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 302 ---
 2 files changed, 275 insertions(+), 58 deletions(-)

-- 
1.9.5.msysgit.0

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

[edk2] [Patch 7/8] UefiCpuPkg/MtrrLib: Reduce hardware init when program variable MTRRs

[Jeff Fan]

When MtrrSetMemoryAttribute() programs variable MTRRs, it may disable/enable
cache and disable/enable MTRRs several times. This updating tries to do
operation in local variable and does the hardware initialization one time only.

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 98 
 1 file changed, 55 insertions(+), 43 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 322f47b..0e76e2f 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -883,30 +883,27 @@ GetMtrrNumberAndDirection (
   This function programs MTRRs according to the values specified
   in the shadow array.
 
+  @param[in, out]  VariableSettings   Variable MTRR settings
   @param[in]   VariableMtrrCount  Number of variable MTRRs
   @param[in, out]  VariableMtrr   Shadow of variable MTRR contents
 
 **/
 VOID
 InvalidateMtrr (
+  IN OUT MTRR_VARIABLE_SETTINGS  *VariableSettings,
   IN UINTN   VariableMtrrCount,
   IN OUT VARIABLE_MTRR   *VariableMtrr
   )
 {
   UINTN Index;
-  MTRR_CONTEXT  MtrrContext;
 
-  PreMtrrChange ();
-  Index = 0;
-  while (Index < VariableMtrrCount) {
+  for (Index = 0; Index < VariableMtrrCount; Index++) {
 if (!VariableMtrr[Index].Valid && VariableMtrr[Index].Used) {
-   AsmWriteMsr64 (VariableMtrr[Index].Msr, 0);
-   AsmWriteMsr64 (VariableMtrr[Index].Msr + 1, 0);
+   VariableSettings->Mtrr[Index].Base = 0;
+   VariableSettings->Mtrr[Index].Mask = 0;
VariableMtrr[Index].Used = FALSE;
 }
-Index ++;
   }
-  PostMtrrChange ();
 }
 
 
@@ -915,6 +912,7 @@ InvalidateMtrr (
 
   This function programs variable MTRRs
 
+  @param[in, out]  VariableSettings  Variable MTRR settings.
   @param[in]   MtrrNumberIndex of MTRR to program.
   @param[in]   BaseAddress   Base address of memory region.
   @param[in]   LengthLength of memory region.
@@ -924,34 +922,27 @@ InvalidateMtrr (
 **/
 VOID
 ProgramVariableMtrr (
-  IN UINTNMtrrNumber,
-  IN PHYSICAL_ADDRESS BaseAddress,
-  IN UINT64   Length,
-  IN UINT64   MemoryCacheType,
-  IN UINT64   MtrrValidAddressMask
+  IN OUT MTRR_VARIABLE_SETTINGS  *VariableSettings,
+  IN UINTN   MtrrNumber,
+  IN PHYSICAL_ADDRESSBaseAddress,
+  IN UINT64  Length,
+  IN UINT64  MemoryCacheType,
+  IN UINT64  MtrrValidAddressMask
   )
 {
   UINT64TempQword;
-  MTRR_CONTEXT  MtrrContext;
-
-  PreMtrrChange ();
 
   //
   // MTRR Physical Base
   //
   TempQword = (BaseAddress & MtrrValidAddressMask) | MemoryCacheType;
-  AsmWriteMsr64 ((UINT32) MtrrNumber, TempQword);
+  VariableSettings->Mtrr[MtrrNumber].Base = TempQword;
 
   //
   // MTRR Physical Mask
   //
   TempQword = ~(Length - 1);
-  AsmWriteMsr64 (
-(UINT32) (MtrrNumber + 1),
-(TempQword & MtrrValidAddressMask) | MTRR_LIB_CACHE_MTRR_ENABLED
-);
-
-  PostMtrrChange ();
+  VariableSettings->Mtrr[MtrrNumber].Mask = (TempQword & MtrrValidAddressMask) 
| MTRR_LIB_CACHE_MTRR_ENABLED;
 }
 
 
@@ -1393,7 +1384,6 @@ MtrrSetMemoryAttribute (
   UINT64MtrrValidAddressMask;
   BOOLEAN   OverwriteExistingMtrr;
   UINT32FirmwareVariableMtrrCount;
-  UINT32VariableMtrrEnd;
   MTRR_CONTEXT  MtrrContext;
   BOOLEAN   MtrrContextValid;
   BOOLEAN   FixedSettingsValid[MTRR_NUMBER_OF_FIXED_MTRR];
@@ -1401,6 +1391,7 @@ MtrrSetMemoryAttribute (
   MTRR_FIXED_SETTINGS   WorkingFixedSettings;
   UINT32VariableMtrrCount;
   MTRR_VARIABLE_SETTINGSOriginalVariableSettings;
+  BOOLEAN   ProgramVariableSettings;
   MTRR_VARIABLE_SETTINGSWorkingVariableSettings;
   UINT32Index;
   UINT64ClearMask;
@@ -1414,16 +1405,14 @@ MtrrSetMemoryAttribute (
 FixedSettingsValid[Index]= FALSE;
 FixedSettingsModified[Index] = FALSE;
   }
+  ProgramVariableSettings = FALSE;
 
   if (!IsMtrrSupported ()) {
 Status = RETURN_UNSUPPORTED;
 goto Done;
   }
 
-  FirmwareVariableMtrrCount = GetFirmwareVariableMtrrCountWorker ();
-  VariableMtrrEnd = MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (2 * 
GetVariableMtrrCount ()) - 1;
-
-  MtrrLibInitializeMtrrMask(, );
+  MtrrLibInitializeMtrrMask (, );
 
   TempQword = 0;
   MemoryType = (UINT64)Attribute;
@@ -1489,8 +1478,10 @@ MtrrSetMemoryAttribute (
   // Read all variable MTRRs
   //
   VariableMtrrCount = GetVariableMtrrCountWorker ();
+  FirmwareVariableMtrrCount = 

[edk2] [Patch 3/8] UefiCpuPkg/MtrrLib: Adjust functions order

[Jeff Fan]

Only adjust functions order and there is no any real functionality impact.

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 956 +--
 1 file changed, 477 insertions(+), 479 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index b1c12aa..ea2b211 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -311,6 +311,103 @@ PostMtrrChange (
   PostMtrrChangeEnableCache (MtrrContext);
 }
 
+/**
+  Worker function gets the content in fixed MTRRs
+
+  @param[out]  FixedSettings  A buffer to hold fixed MTRRs content.
+
+  @retval The pointer of FixedSettings
+
+**/
+MTRR_FIXED_SETTINGS*
+MtrrGetFixedMtrrWorker (
+  OUT MTRR_FIXED_SETTINGS *FixedSettings
+  )
+{
+  UINT32  Index;
+
+  for (Index = 0; Index < MTRR_NUMBER_OF_FIXED_MTRR; Index++) {
+  FixedSettings->Mtrr[Index] =
+AsmReadMsr64 (mMtrrLibFixedMtrrTable[Index].Msr);
+  }
+
+  return FixedSettings;
+}
+
+
+/**
+  This function gets the content in fixed MTRRs
+
+  @param[out]  FixedSettings  A buffer to hold fixed MTRRs content.
+
+  @retval The pointer of FixedSettings
+
+**/
+MTRR_FIXED_SETTINGS*
+EFIAPI
+MtrrGetFixedMtrr (
+  OUT MTRR_FIXED_SETTINGS *FixedSettings
+  )
+{
+  if (!IsMtrrSupported ()) {
+return FixedSettings;
+  }
+
+  return MtrrGetFixedMtrrWorker (FixedSettings);
+}
+
+
+/**
+  Worker function will get the raw value in variable MTRRs
+
+  @param[out] VariableSettings   A buffer to hold variable MTRRs content.
+
+  @return The VariableSettings input pointer
+
+**/
+MTRR_VARIABLE_SETTINGS*
+MtrrGetVariableMtrrWorker (
+  OUT MTRR_VARIABLE_SETTINGS  *VariableSettings
+  )
+{
+  UINT32  Index;
+  UINT32  VariableMtrrCount;
+
+  VariableMtrrCount = GetVariableMtrrCount ();
+  ASSERT (VariableMtrrCount <= MTRR_NUMBER_OF_VARIABLE_MTRR);
+
+  for (Index = 0; Index < VariableMtrrCount; Index++) {
+VariableSettings->Mtrr[Index].Base =
+  AsmReadMsr64 (MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (Index << 1));
+VariableSettings->Mtrr[Index].Mask =
+  AsmReadMsr64 (MTRR_LIB_IA32_VARIABLE_MTRR_BASE + (Index << 1) + 1);
+  }
+
+  return  VariableSettings;
+}
+
+/**
+  This function will get the raw value in variable MTRRs
+
+  @param[out]  VariableSettings   A buffer to hold variable MTRRs content.
+
+  @return The VariableSettings input pointer
+
+**/
+MTRR_VARIABLE_SETTINGS*
+EFIAPI
+MtrrGetVariableMtrr (
+  OUT MTRR_VARIABLE_SETTINGS *VariableSettings
+  )
+{
+  if (!IsMtrrSupported ()) {
+return VariableSettings;
+  }
+
+  return MtrrGetVariableMtrrWorker (
+   VariableSettings
+   );
+}
 
 /**
   Programs fixed MTRRs registers.
@@ -965,126 +1062,368 @@ MtrrPrecedence (
 }
 
 
+
 /**
-  This function attempts to set the attributes for a memory range.
+  This function will get the memory cache type of the specific address.
 
-  @param[in]   BaseAddress   The physical address that is the start
- address of a memory region.
-  @param[in]   LengthThe size in bytes of the memory region.
-  @param[in]   Attribute The bit mask of attributes to set for the
- memory region.
+  This function is mainly for debug purpose.
 
-  @retval RETURN_SUCCESSThe attributes were set for the memory
-region.
-  @retval RETURN_INVALID_PARAMETER  Length is zero.
-  @retval RETURN_UNSUPPORTEDThe processor does not support one or
-more bytes of the memory resource range
-specified by BaseAddress and Length.
-  @retval RETURN_UNSUPPORTEDThe bit mask of attributes is not support
-for the memory resource range specified
-by BaseAddress and Length.
-  @retval RETURN_ACCESS_DENIED  The attributes for the memory resource
-range specified by BaseAddress and Length
-cannot be modified.
-  @retval RETURN_OUT_OF_RESOURCES   There are not enough system resources to
-modify the attributes of the memory
-resource range.
+  @param[in]  AddressThe specific address
+
+  @return Memory cache type of the specific address
 
 **/
-RETURN_STATUS
+MTRR_MEMORY_CACHE_TYPE
 EFIAPI
-MtrrSetMemoryAttribute (
-  IN PHYSICAL_ADDRESSBaseAddress,
-  IN UINT64  Length,
-  IN MTRR_MEMORY_CACHE_TYPE  Attribute
+MtrrGetMemoryAttribute (
+  IN PHYSICAL_ADDRESS   Address
   )
 {
-  UINT64TempQword;
-  RETURN_STATUS Status;

Re: [edk2] GICv3 support

[Ard Biesheuvel]

On 1 December 2015 at 19:39, Supreeth Venkatesh
 wrote:
> Meenakshi,
>
> Are you using any EL3 firmware with GICv3 support in it?
> Is "PcdArmGicV3WithV2Legacy" being used?
> Is the ARM Architectural Timer working for you? (If this works, keyboard 
> input work fine.)
>
> I think this is the same problem I ran into before, where the interrupt for 
> the arm architecture timer was not triggering.
>
> The Affinity needs to be set properly for GICv3 support to work properly.
>
> GICD_CTLR.ARE_S bit. This enables affinity routing for the secure and the 
> normal worlds. When secure world(EL3) is operating in the legacy mode, UEFI 
> is responsible for enabling affinity routing for the normal world. There is a 
> bug in the UEFI code that programs the GICD_CTLR.ARE_NS bit. The GICv3 
> specification clearly says that changing the ARE_NS from 1 to 0 is 
> UNPREDICATABLE. The patch is attached.
>
> Will be sending this patch out for Review to this list soon. Please let me 
> know whether this resolves this for you.
>
> diff --git a/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c 
> b/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c
> index 3157243..f90391b 100644
> --- a/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c
> +++ b/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c
> @@ -33,9 +33,9 @@ ArmGicEnableDistributor (
>  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x1);
>} else {
>  if (MmioRead32 (GicDistributorBase + ARM_GIC_ICDDCR) & 
> ARM_GIC_ICDDCR_ARE) {
> -  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x2);
> +  MmioOr32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x2);
>  } else {
> -  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x1);
> +  MmioOr32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x1);
>  }
>}
>  }
>

Hello Supreeth,

Thanks for reporting this. Your patch fixes the FVP foundation model
in GICv3 mode, i.e., I can finally disable the
PcdArmGicV3WithV2Legacy=TRUE setting from its .DSC (and we should
probably remove it altogether)

Could you submit this as a proper patch against Armpkg please?

Thanks,
Ard.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Meenakshi Aggarwal
> Sent: Sunday, November 29, 2015 9:53 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] GICv3 support
>
> Hi,
>
>
> I have added support of GICv3 in my board package by defining
>
>   gArmTokenSpaceGuid.PcdGicDistributorBase|0x600
>   gArmTokenSpaceGuid.PcdGicRedistributorsBase|0x610
>
>
> But still I am unable to take input from keyboard.
>
> Do I need to do some more settings for this.
>
> Kindly reply.
>
>
>
> Thanks & Regards,
> Meenakshi
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
>
> ___
> 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 0/3] remove v2 override for GICv3

[Ard Biesheuvel]

After I spotted Supreeth's message to edk2-devel regarding a bug in the
GICv3 distributor enable code, I figured that /that/ was the reason we were
running the GIC in v2 mode, and not that it is not correctly enabled by the
ARM trusted firmware. So apply the fix, and remove the legacy v2 override from
FVP-AArch64 (which is its only user)

Ard Biesheuvel (3):
  ArmPkg/ArmGic: fix bug in GICv3 distributor configuration
  ArmVExpressPkg/ArmVExpress-FVP-AArch64: run GICv3 in v3 mode
  ArmPkg/ArmGic: remove GICv3 legacy override

 ArmPkg/ArmPkg.dec |  3 --
 ArmPkg/Drivers/ArmGic/ArmGicDxe.inf   |  1 -
 ArmPkg/Drivers/ArmGic/ArmGicLib.c |  6 ++--
 ArmPkg/Drivers/ArmGic/ArmGicLib.inf   |  3 --
 ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c   |  4 +--
 ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf|  3 --
 ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 35 

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc |  6 
 8 files changed, 11 insertions(+), 50 deletions(-)

-- 
1.9.1

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

[edk2] [PATCH 3/3] ArmPkg/ArmGic: remove GICv3 legacy override

[Ard Biesheuvel]

The need for a v2 legacy override to drive a GICv3 in v2 mode is no
longer necessary, now that the code that enabled the GIC distributor no
longer inadvertently kicks a v2 capable GICv3 into v2 mode. So remove
the PCD and all references to it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec |  3 --
 ArmPkg/Drivers/ArmGic/ArmGicDxe.inf   |  1 -
 ArmPkg/Drivers/ArmGic/ArmGicLib.c |  6 ++--
 ArmPkg/Drivers/ArmGic/ArmGicLib.inf   |  3 --
 ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf|  3 --
 ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 35 
 6 files changed, 9 insertions(+), 42 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index ff4531e44106..e8021d20bc78 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -70,9 +70,6 @@ [PcdsFeatureFlag.common]
   # Linux (instead of PSCI)
   gArmTokenSpaceGuid.PcdArmLinuxSpinTable|FALSE|BOOLEAN|0x0033
 
-  # Define if the GICv3 controller should use the GICv2 legacy
-  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy|FALSE|BOOLEAN|0x0042
-
 [PcdsFeatureFlag.ARM]
   # Whether to map normal memory as non-shareable. FALSE is the safe choice, 
but
   # TRUE may be appropriate to fix performance problems if you don't care about
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf 
b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
index e554301c4b28..31d90a6d473d 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
+++ b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
@@ -54,7 +54,6 @@ [Pcd.common]
   gArmTokenSpaceGuid.PcdGicDistributorBase
   gArmTokenSpaceGuid.PcdGicRedistributorsBase
   gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
-  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
 
 [Depex]
   gEfiCpuArchProtocolGuid
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c 
b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
index 248e896c4b94..f218a8d7ef06 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
+++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
@@ -183,7 +183,7 @@ ArmGicEnableInterrupt (
   RegShift = Source % 32;
 
   Revision = ArmGicGetSupportedArchRevision ();
-  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
(PcdArmGicV3WithV2Legacy)) {
+  if (Revision == ARM_GIC_ARCH_REVISION_2) {
 // Write set-enable register
 MmioWrite32 (GicDistributorBase + ARM_GIC_ICDISER + (4 * RegOffset), 1 << 
RegShift);
   } else {
@@ -216,7 +216,7 @@ ArmGicDisableInterrupt (
   RegShift = Source % 32;
 
   Revision = ArmGicGetSupportedArchRevision ();
-  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
(PcdArmGicV3WithV2Legacy)) {
+  if (Revision == ARM_GIC_ARCH_REVISION_2) {
 // Write clear-enable register
 MmioWrite32 (GicDistributorBase + ARM_GIC_ICDICER + (4 * RegOffset), 1 << 
RegShift);
   } else {
@@ -249,7 +249,7 @@ ArmGicIsInterruptEnabled (
   RegShift = Source % 32;
 
   Revision = ArmGicGetSupportedArchRevision ();
-  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
(PcdArmGicV3WithV2Legacy)) {
+  if (Revision == ARM_GIC_ARCH_REVISION_2) {
 Interrupts = ((MmioRead32 (GicDistributorBase + ARM_GIC_ICDISER + (4 * 
RegOffset)) & (1 << RegShift)) != 0);
   } else {
 GicCpuRedistributorBase = GicGetCpuRedistributorBase 
(GicRedistributorBase, Revision);
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.inf 
b/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
index 047adac85ff4..62f20eb55294 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
+++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
@@ -46,6 +46,3 @@ [Packages]
 
 [Pcd]
   gArmPlatformTokenSpaceGuid.PcdCoreCount
-
-[FeaturePcd]
-  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf 
b/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
index fc2e1bc01efe..efea9c828170 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
+++ b/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
@@ -47,6 +47,3 @@ [LibraryClasses]
 
 [Pcd]
   gArmPlatformTokenSpaceGuid.PcdCoreCount
-
-[FeaturePcd]
-  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
index 4afa3d5a09c2..0a75850200bd 100644
--- a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
+++ b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
@@ -254,9 +254,7 @@ GicV3DxeInitialize (
   // We will be driving this GIC in native v3 mode, i.e., with Affinity
   // Routing enabled. So ensure that the ARE bit is set.
   //
-  if (!FeaturePcdGet (PcdArmGicV3WithV2Legacy)) {
-MmioOr32 (mGicDistributorBase + ARM_GIC_ICDDCR, ARM_GIC_ICDDCR_ARE);
-  }
+  MmioOr32 (mGicDistributorBase + ARM_GIC_ICDDCR, ARM_GIC_ICDDCR_ARE);
 
   for (Index = 0; Index < mGicNumInterrupts; Index++) {
 GicV3DisableInterruptSource (, Index);
@@ -274,33 +272,12 @@ GicV3DxeInitialize (
   //
   // Targets the interrupts to the Primary Cpu
   //
+  MpId = ArmReadMpidr ();
+  CpuTarget = MpId & (ARM_CORE_AFF0 | ARM_CORE_AFF1 | ARM_CORE_AFF2 | 
ARM_CORE_AFF3);
 
-  if (FeaturePcdGet 

[edk2] [Patch 1/8] UefiCpuPkg/MtrrLib: Fix some typo and clean up code format

[Jeff Fan]

Fixed some typo. Removed some trailing spaces and TAB key. Clean up code format.

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Include/Library/MtrrLib.h |  70 ---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 162 ++-
 2 files changed, 121 insertions(+), 111 deletions(-)

diff --git a/UefiCpuPkg/Include/Library/MtrrLib.h 
b/UefiCpuPkg/Include/Library/MtrrLib.h
index f9002e7..884c7bb 100644
--- a/UefiCpuPkg/Include/Library/MtrrLib.h
+++ b/UefiCpuPkg/Include/Library/MtrrLib.h
@@ -84,8 +84,8 @@ typedef struct {
 // Structure to hold base and mask pair for variable MTRR register
 //
 typedef struct _MTRR_VARIABLE_SETTING_ {
-   UINT64Base;
-   UINT64Mask;
+  UINT64Base;
+  UINT64Mask;
 } MTRR_VARIABLE_SETTING;
 
 //
@@ -115,11 +115,11 @@ typedef struct _MTRR_SETTINGS_ {
 // Memory cache types
 //
 typedef enum {
-   CacheUncacheable= 0,
-   CacheWriteCombining = 1,
-   CacheWriteThrough   = 4,
-   CacheWriteProtected = 5,
-   CacheWriteBack  = 6
+  CacheUncacheable= 0,
+  CacheWriteCombining = 1,
+  CacheWriteThrough   = 4,
+  CacheWriteProtected = 5,
+  CacheWriteBack  = 6
 } MTRR_MEMORY_CACHE_TYPE;
 
 #define  MTRR_CACHE_UNCACHEABLE  0
@@ -156,20 +156,27 @@ GetFirmwareVariableMtrrCount (
 /**
   This function attempts to set the attributes for a memory range.
 
-  @param  BaseAddressThe physical address that is the start 
address of a memory region.
-  @param  Length The size in bytes of the memory region.
-  @param  Attributes The bit mask of attributes to set for the 
memory region.
+  @param[in]   BaseAddress   The physical address that is the start
+ address of a memory region.
+  @param[in]   LengthThe size in bytes of the memory region.
+  @param[in]   Attribute The bit mask of attributes to set for the
+ memory region.
 
-  @retval RETURN_SUCCESSThe attributes were set for the memory 
region.
+  @retval RETURN_SUCCESSThe attributes were set for the memory
+region.
   @retval RETURN_INVALID_PARAMETER  Length is zero.
-  @retval RETURN_UNSUPPORTEDThe processor does not support one or more 
bytes of the
- memory resource range specified by 
BaseAddress and Length.
-  @retval RETURN_UNSUPPORTEDThe bit mask of attributes is not support 
for the memory resource
- range specified by BaseAddress and Length.
-  @retval RETURN_ACCESS_DENIED  The attributes for the memory resource 
range specified by
- BaseAddress and Length cannot be modified.
-  @retval RETURN_OUT_OF_RESOURCES   There are not enough system resources to 
modify the attributes of
- the memory resource range.
+  @retval RETURN_UNSUPPORTEDThe processor does not support one or
+more bytes of the memory resource range
+specified by BaseAddress and Length.
+  @retval RETURN_UNSUPPORTEDThe bit mask of attributes is not support
+for the memory resource range specified
+by BaseAddress and Length.
+  @retval RETURN_ACCESS_DENIED  The attributes for the memory resource
+range specified by BaseAddress and Length
+cannot be modified.
+  @retval RETURN_OUT_OF_RESOURCES   There are not enough system resources to
+modify the attributes of the memory
+resource range.
 
 **/
 RETURN_STATUS
@@ -185,7 +192,7 @@ MtrrSetMemoryAttribute (
   This function will get the memory cache type of the specific address.
   This function is mainly for debugging purposes.
 
-  @param  AddressThe specific address
+  @param[in]  AddressThe specific address
 
   @return The memory cache type of the specific address
 
@@ -200,7 +207,7 @@ MtrrGetMemoryAttribute (
 /**
   This function will get the raw value in variable MTRRs
 
-  @param  VariableSettings   A buffer to hold variable MTRRs content.
+  @param[out]  VariableSettings   A buffer to hold variable MTRRs content.
 
   @return The buffer point to MTRR_VARIABLE_SETTINGS in which holds the 
content of the variable mtrr
 
@@ -215,7 +222,7 @@ MtrrGetVariableMtrr (
 /**
   This function sets fixed MTRRs
 
-  @param  VariableSettings   A buffer to hold variable MTRRs content.
+  @param[in]  VariableSettings   A buffer to hold variable MTRRs content.
 
   @return The pointer of VariableSettings
 
@@ -230,7 

[edk2] [Patch 2/8] UefiCpuPkg/MtrrLib: Add worker functions not invoke IsMtrrSupported()

[Jeff Fan]

Abstract some worker functions not to invoke IsMtrrSupported(). They could be
used by other functions to reduce the number of invoking times on
IsMtrrSupported().

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 139 +++
 1 file changed, 108 insertions(+), 31 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 1584ae2..b1c12aa 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -104,6 +104,24 @@ GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 
*mMtrrMemoryCacheTypeShortName[] = {
 };
 
 /**
+  Worker function returns the variable MTRR count for the CPU.
+
+  @return Variable MTRR count
+
+**/
+UINT32
+GetVariableMtrrCountWorker (
+  VOID
+  )
+{
+  UINT32  VariableMtrrCount;
+
+  VariableMtrrCount = (UINT32)(AsmReadMsr64 (MTRR_LIB_IA32_MTRR_CAP) & 
MTRR_LIB_IA32_MTRR_CAP_VCNT_MASK);
+  ASSERT (VariableMtrrCount <= MTRR_NUMBER_OF_VARIABLE_MTRR);
+  return VariableMtrrCount;
+}
+
+/**
   Returns the variable MTRR count for the CPU.
 
   @return Variable MTRR count
@@ -115,34 +133,27 @@ GetVariableMtrrCount (
   VOID
   )
 {
-  UINT32  VariableMtrrCount;
-
   if (!IsMtrrSupported ()) {
 return 0;
   }
-
-  VariableMtrrCount = (UINT32)(AsmReadMsr64 (MTRR_LIB_IA32_MTRR_CAP) & 
MTRR_LIB_IA32_MTRR_CAP_VCNT_MASK);
-  ASSERT (VariableMtrrCount <= MTRR_NUMBER_OF_VARIABLE_MTRR);
-
-  return VariableMtrrCount;
+  return GetVariableMtrrCountWorker ();
 }
 
 /**
-  Returns the firmware usable variable MTRR count for the CPU.
+  Worker function returns the firmware usable variable MTRR count for the CPU.
 
   @return Firmware usable variable MTRR count
 
 **/
 UINT32
-EFIAPI
-GetFirmwareVariableMtrrCount (
+GetFirmwareVariableMtrrCountWorker (
   VOID
   )
 {
   UINT32  VariableMtrrCount;
   UINT32  ReservedMtrrNumber;
 
-  VariableMtrrCount = GetVariableMtrrCount ();
+  VariableMtrrCount = GetVariableMtrrCountWorker ();
   ReservedMtrrNumber = PcdGet32 (PcdCpuNumberOfReservedVariableMtrrs);
   if (VariableMtrrCount < ReservedMtrrNumber) {
 return 0;
@@ -152,6 +163,39 @@ GetFirmwareVariableMtrrCount (
 }
 
 /**
+  Returns the firmware usable variable MTRR count for the CPU.
+
+  @return Firmware usable variable MTRR count
+
+**/
+UINT32
+EFIAPI
+GetFirmwareVariableMtrrCount (
+  VOID
+  )
+{
+  if (!IsMtrrSupported ()) {
+return 0;
+  }
+  return GetFirmwareVariableMtrrCountWorker ();
+}
+
+/**
+  Worker function returns the default MTRR cache type for the system.
+
+  @return  The default MTRR cache type.
+
+**/
+MTRR_MEMORY_CACHE_TYPE
+MtrrGetDefaultMemoryTypeWorker (
+  VOID
+  )
+{
+  return (MTRR_MEMORY_CACHE_TYPE) (AsmReadMsr64 (MTRR_LIB_IA32_MTRR_DEF_TYPE) 
& 0x7);
+}
+
+
+/**
   Returns the default MTRR cache type for the system.
 
   @return  The default MTRR cache type.
@@ -166,8 +210,7 @@ MtrrGetDefaultMemoryType (
   if (!IsMtrrSupported ()) {
 return CacheUncacheable;
   }
-
-  return (MTRR_MEMORY_CACHE_TYPE) (AsmReadMsr64 (MTRR_LIB_IA32_MTRR_DEF_TYPE) 
& 0x7);
+  return MtrrGetDefaultMemoryTypeWorker ();
 }
 
 /**
@@ -1290,26 +1333,21 @@ MtrrGetMemoryAttribute (
 
 
 /**
-  This function will get the raw value in variable MTRRs
+  Worker function will get the raw value in variable MTRRs
 
-  @param[out]  FixedSettings  A buffer to hold fixed MTRRs content.
+  @param[out] VariableSettings   A buffer to hold variable MTRRs content.
 
   @return The VariableSettings input pointer
 
 **/
 MTRR_VARIABLE_SETTINGS*
-EFIAPI
-MtrrGetVariableMtrr (
-  OUT MTRR_VARIABLE_SETTINGS *VariableSettings
+MtrrGetVariableMtrrWorker (
+  OUT MTRR_VARIABLE_SETTINGS  *VariableSettings
   )
 {
   UINT32  Index;
   UINT32  VariableMtrrCount;
 
-  if (!IsMtrrSupported ()) {
-return VariableSettings;
-  }
-
   VariableMtrrCount = GetVariableMtrrCount ();
   ASSERT (VariableMtrrCount <= MTRR_NUMBER_OF_VARIABLE_MTRR);
 
@@ -1323,6 +1361,29 @@ MtrrGetVariableMtrr (
   return  VariableSettings;
 }
 
+/**
+  This function will get the raw value in variable MTRRs
+
+  @param[out]  VariableSettings   A buffer to hold variable MTRRs content.
+
+  @return The VariableSettings input pointer
+
+**/
+MTRR_VARIABLE_SETTINGS*
+EFIAPI
+MtrrGetVariableMtrr (
+  OUT MTRR_VARIABLE_SETTINGS *VariableSettings
+  )
+{
+  if (!IsMtrrSupported ()) {
+return VariableSettings;
+  }
+
+  return MtrrGetVariableMtrrWorker (
+   VariableSettings
+   );
+}
+
 
 /**
   Worker function setting variable MTRRs
@@ -1380,11 +1441,34 @@ MtrrSetVariableMtrr (
   return  VariableSettings;
 }
 
+/**
+  Worker function gets the content in fixed MTRRs
+
+  @param[out]  FixedSettings  A buffer to hold fixed MTRRs content.
+
+  @retval The pointer of FixedSettings
+
+**/
+MTRR_FIXED_SETTINGS*
+MtrrGetFixedMtrrWorker (

[edk2] [Patch] UefiCpuPkg/MtrrLib: Add PCD PcdCpuNumberOfReservedVariableMtrrs

[Jeff Fan]

Current MtrrLib reserves 2 variable MTRRs for some legacy OS boot (CSM boots)
may require some MTRRs to be reserved for OS use. But UEFI OS boot will not use
MTRRs.

Per Scott's suggestion in
link: http://article.gmane.org/gmane.comp.bios.edk2.devel/4099
Add one PCD PcdCpuNumberOfReservedVariableMtrrs to specify the number of
variable MTRRs reserved for OS use. Setting its default value to 2 is for
back-compatibility.

Cc: Scott Duplichan 
Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
Suggested-by: Scott Duplichan 
---
 UefiCpuPkg/Include/Library/MtrrLib.h   | 3 ++-
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c   | 6 --
 UefiCpuPkg/Library/MtrrLib/MtrrLib.inf | 5 -
 UefiCpuPkg/UefiCpuPkg.dec  | 5 +
 4 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/Include/Library/MtrrLib.h 
b/UefiCpuPkg/Include/Library/MtrrLib.h
index e06fff7..f9002e7 100644
--- a/UefiCpuPkg/Include/Library/MtrrLib.h
+++ b/UefiCpuPkg/Include/Library/MtrrLib.h
@@ -1,7 +1,7 @@
 /** @file
   MTRR setting library
 
-  Copyright (c) 2008 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2015, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -26,6 +26,7 @@
 #define  MTRR_NUMBER_OF_VARIABLE_MTRR  32
 //
 // Firmware need reserve 2 MTRR for OS
+// Note: It is replaced by PCD PcdCpuNumberOfReservedVariableMtrrs
 //
 #define  RESERVED_FIRMWARE_VARIABLE_MTRR_NUMBER  2
 
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index a655605..8222337 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -140,13 +140,15 @@ GetFirmwareVariableMtrrCount (
   )
 {
   UINT32  VariableMtrrCount;
+  UINT32  ReservedMtrrNumber;
 
   VariableMtrrCount = GetVariableMtrrCount ();
-  if (VariableMtrrCount < RESERVED_FIRMWARE_VARIABLE_MTRR_NUMBER) {
+  ReservedMtrrNumber = PcdGet32 (PcdCpuNumberOfReservedVariableMtrrs);
+  if (VariableMtrrCount < ReservedMtrrNumber) {
 return 0;
   }
 
-  return VariableMtrrCount - RESERVED_FIRMWARE_VARIABLE_MTRR_NUMBER;
+  return VariableMtrrCount - ReservedMtrrNumber;
 }
 
 /**
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.inf 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
index 64ec9bd..01a4d84 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  MTRR library provides APIs for MTRR operation.
 #
-#  Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
@@ -41,3 +41,6 @@
   CpuLib
   DebugLib
 
+[Pcd]
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuNumberOfReservedVariableMtrrs   ## 
SOMETIMES_CONSUMES
+
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index e783a7b..a694146 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -167,6 +167,11 @@
   # @Prompt SMM CPU Synchronization Method.
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x00|UINT8|0x6014
 
+  ## Specifies the number of variable MTRRs reserved for OS use. The default 
number of
+  #  MTRRs reserved for OS use is 2.
+  # @Prompt Number of reserved variable MTRRs.
+  
gUefiCpuPkgTokenSpaceGuid.PcdCpuNumberOfReservedVariableMtrrs|0x2|UINT32|0x0015
+
 [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
   ## Specifies timeout value in microseconds for the BSP to detect all APs for 
the first time.
   # @Prompt Timeout for the BSP to detect all APs for the first time.
-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH v2 2/2] ArmVirtPkg: Add memory space for the memory nodes except the lowest one

[Laszlo Ersek]

Shannon,

On 12/01/15 03:02, Shannon Zhao wrote:
> 
> On 2015/12/1 2:12, Laszlo Ersek wrote:
>> Thank you -- this looks better. Unfortunately the
>> SetMemorySpaceAttributes() question still has to be addressed, and we're
>> still discussing with Ard which way to go about that. Once we have an
>> agreement, I'll spell out the further requirements for this.
>>
>> The "do it all in PEI with HOBs" idea is out, now we're trying to decide
>> if (a) we should do it in VirtFdtDxe, and update the APRIORI DXE block
>> in the FDF file so that CpuDxe gets dispatched before VirtFdtDxe, or (b)
>> if we should move this code to a separate DXE driver that depends on the
>> CPU architectural protocol installed by CpuDxe. Whatever the agreement,
>> this patch will need to be further updated.
>>
>> I ask for your patience with this -- it's messier than I would like. I
>> hope your NUMA development can proceed even until we converge with the
>> help of these WIP patches.
>>
> It's fine since it doesn't block the NUMA patches. :)
> 
>> I'll admit that my secret (well, not so secret :)) agenda with this
>> series is to pull more people into edk2 development from the QEMU
>> community. Albeit somewhat messy, this feature isn't very large or
>> complex, so I find it appropriate to "train" you with it -- if you want
>> to play along, that is. :)
> 
> Laszlo, I think this is very cool. I'm interested in this kind of
> "training". :)
> 

Okay, so we seem to have reached an agreement with Ard in the other thread:

http://thread.gmane.org/gmane.comp.bios.edk2.devel/5054/focus=5309

Here's what I suggest for v3:

* Patch 1 is good, you can include it without any changes (you have my R-b).

* Patch 2 should implement what you are doing now (with my comments in
this thread addressed), but it should introduce that functionality as a
separate, new driver.

Namely, as first step please recursively copy the directory
"ArmVirtPkg/VirtFdtDxe" to "ArmVirtPkg/HighMemDxe". Please also replace
all occurrences of the "VirtFdtDxe" string in source code and in file
names within the copy.

Second, please generate a new FILE_GUID with the "uuidgen" utility for
the new "ArmVirtPkg/HighMemDxe/HighMemDxe.inf" file.

Third, add the subject functionality to HighMemDxe. (Addressing my
comments too.)

Fourth, remove everything else from HighMemDxe; so that its sole
responsibility remains processing the higher-than-lowest /memory nodes
in the DTB. This removal will make a number of libraries, PCDs, protcols
etc superfluous, so please remove the relevant #include directives and
[LibraryClasses] entries.

Fifth, in "ArmVirtPkg/HighMemDxe/HighMemDxe.inf", the TRUE expression
under [DepEx] should be replaced with gEfiCpuArchProtocolGuid.

Sixth, the new driver's INF file should be referenced in
"ArmVirtQemu.dsc" and "ArmVirtQemu.fdf". In the latter, it should *not*
be added to APRIORI DXE.

In short, patch #2 should add a small new driver that does nothing but
looks for memory nodes in the DTB, installs the ranges, and sets their
actual caching attributes to WB (which depends on the CPU arch protocol
internally).

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

[edk2] [PATCH 1/3] ArmPkg/ArmGic: fix bug in GICv3 distributor configuration

[Ard Biesheuvel]

In the function ArmGicEnableDistributor (), the Affinity Routing Enable
(ARE) bit, which essentially defines whether the GIC runs in v2 or v3
mode, is inadvertently cleared when enabling the GIC distributor if it
is running in v3 mode. So fix that.

Reported-by: Supreeth Venkatesh 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c 
b/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c
index 31572438d9a1..f90391b716b5 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c
+++ b/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c
@@ -33,9 +33,9 @@ ArmGicEnableDistributor (
 MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x1);
   } else {
 if (MmioRead32 (GicDistributorBase + ARM_GIC_ICDDCR) & ARM_GIC_ICDDCR_ARE) 
{
-  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x2);
+  MmioOr32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x2);
 } else {
-  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x1);
+  MmioOr32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x1);
 }
   }
 }
-- 
1.9.1

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

Re: [edk2] [PATCH] ShellPkg: Refine the code to reduce time cost of 'map -r'

[Carsey, Jaben]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, December 03, 2015 3:26 AM
> To: Qiu, Shumin ; edk2-de...@ml01.01.org
> Cc: Carsey, Jaben 
> Subject: Re: [edk2] [PATCH] ShellPkg: Refine the code to reduce time cost of
> 'map -r'
> Importance: High
> 
> On 12/03/15 06:35, Qiu Shumin wrote:
> > In some platform 'map -r' may cost more than 1 min. This patch filter the
> target handles by
> > BlockIO and SimpleFileSystem protocol to reduce the time cost.
> 
> Hijacking this thread and asking a more general question -- I noticed
> recently that the "devices" and "drivers" commands can take quite long.
> I guess there is a lot of processing to be done for those. But, has it
> been considered to change the internal representation of the protocol
> database to speed things up? (I'm asking this without knowing too much
> about the current representation.)
> 
> I'm not suggesting that the current proto DB representation is slow; I'm
> just curious if the perf consequences of the representation have been
> considered before.


not to my knowledge.  Curiosity - do you mean internal representation in the 
shell or in the platform?  The shell maintains almost no internal 
representation of anything.

> 
> Thanks!
> Laszlo
> 
> >
> > Cc: Jaben Carsey 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Qiu Shumin 
> > ---
> >  .../Library/UefiShellCommandLib/ConsistMapping.c   | 40
> --
> >  1 file changed, 30 insertions(+), 10 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> > index 9bd7b2c..86e8dc5 100644
> > --- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> > +++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> > @@ -16,6 +16,10 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +
> > +
> >
> >  typedef enum {
> >MTDTypeUnknown,
> > @@ -1349,20 +1353,22 @@ ShellCommandConsistMappingInitialize (
> >OUT EFI_DEVICE_PATH_PROTOCOL   ***Table
> >)
> >  {
> > -  EFI_HANDLE*HandleBuffer;
> > -  UINTN HandleNum;
> > -  UINTN HandleLoop;
> > -  EFI_DEVICE_PATH_PROTOCOL  **TempTable;
> > -  EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
> > -  EFI_DEVICE_PATH_PROTOCOL  *HIDevicePath;
> > -  UINTN Index;
> > -  EFI_STATUSStatus;
> > +  EFI_HANDLE  *HandleBuffer;
> > +  UINTN   HandleNum;
> > +  UINTN   HandleLoop;
> > +  EFI_DEVICE_PATH_PROTOCOL**TempTable;
> > +  EFI_DEVICE_PATH_PROTOCOL*DevicePath;
> > +  EFI_DEVICE_PATH_PROTOCOL*HIDevicePath;
> > +  EFI_BLOCK_IO_PROTOCOL   *BlockIo;
> > +  EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *SimpleFileSystem;
> > +  UINTN   Index;
> > +  EFI_STATUS  Status;
> >
> >HandleBuffer  = NULL;
> >
> >Status = gBS->LocateHandleBuffer (
> > -  AllHandles,
> > -  NULL,
> > +  ByProtocol,
> > +  ,
> >NULL,
> >,
> >
> > @@ -1385,6 +1391,20 @@ ShellCommandConsistMappingInitialize (
> >continue;
> >  }
> >
> > +Status = gBS->HandleProtocol( HandleBuffer[HandleLoop],
> > +  ,
> > +  (VOID **)
> > +  );
> > +if (EFI_ERROR(Status)) {
> > +  Status = gBS->HandleProtocol( HandleBuffer[HandleLoop],
> > +,
> > +(VOID **)
> > +);
> > +  if (EFI_ERROR(Status)) {
> > +continue;
> > +  }
> > +}
> > +
> >  for (Index = 0; TempTable[Index] != NULL; Index++) {
> >if (DevicePathCompare ([Index], ) == 0) {
> >  FreePool (HIDevicePath);
> >

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

Re: [edk2] [PATCH] ShellPkg: Refine the code to reduce time cost of 'map -r'

[Laszlo Ersek]

On 12/03/15 18:04, Carsey, Jaben wrote:
> 
> 
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, December 03, 2015 3:26 AM
>> To: Qiu, Shumin ; edk2-de...@ml01.01.org
>> Cc: Carsey, Jaben 
>> Subject: Re: [edk2] [PATCH] ShellPkg: Refine the code to reduce time cost of
>> 'map -r'
>> Importance: High
>>
>> On 12/03/15 06:35, Qiu Shumin wrote:
>>> In some platform 'map -r' may cost more than 1 min. This patch filter the
>> target handles by
>>> BlockIO and SimpleFileSystem protocol to reduce the time cost.
>>
>> Hijacking this thread and asking a more general question -- I noticed
>> recently that the "devices" and "drivers" commands can take quite long.
>> I guess there is a lot of processing to be done for those. But, has it
>> been considered to change the internal representation of the protocol
>> database to speed things up? (I'm asking this without knowing too much
>> about the current representation.)
>>
>> I'm not suggesting that the current proto DB representation is slow; I'm
>> just curious if the perf consequences of the representation have been
>> considered before.
> 
> 
> not to my knowledge.  Curiosity - do you mean internal representation in the 
> shell or in the platform?  The shell maintains almost no internal 
> representation of anything.

In the platform. The performance of some of the protocol boot services
could depend on that representation.

But, maybe the shell could be optimized too (I haven't looked at the
code). I can imagine that for cross-referencing various things it uses
O(n^2) nested loops or something similar, even if state is not
maintained longer than a command's execution.

Thanks
Laszlo

> 
>>
>> Thanks!
>> Laszlo
>>
>>>
>>> Cc: Jaben Carsey 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Qiu Shumin 
>>> ---
>>>  .../Library/UefiShellCommandLib/ConsistMapping.c   | 40
>> --
>>>  1 file changed, 30 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
>> b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
>>> index 9bd7b2c..86e8dc5 100644
>>> --- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
>>> +++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
>>> @@ -16,6 +16,10 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>> +
>>> +
>>>
>>>  typedef enum {
>>>MTDTypeUnknown,
>>> @@ -1349,20 +1353,22 @@ ShellCommandConsistMappingInitialize (
>>>OUT EFI_DEVICE_PATH_PROTOCOL   ***Table
>>>)
>>>  {
>>> -  EFI_HANDLE*HandleBuffer;
>>> -  UINTN HandleNum;
>>> -  UINTN HandleLoop;
>>> -  EFI_DEVICE_PATH_PROTOCOL  **TempTable;
>>> -  EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
>>> -  EFI_DEVICE_PATH_PROTOCOL  *HIDevicePath;
>>> -  UINTN Index;
>>> -  EFI_STATUSStatus;
>>> +  EFI_HANDLE  *HandleBuffer;
>>> +  UINTN   HandleNum;
>>> +  UINTN   HandleLoop;
>>> +  EFI_DEVICE_PATH_PROTOCOL**TempTable;
>>> +  EFI_DEVICE_PATH_PROTOCOL*DevicePath;
>>> +  EFI_DEVICE_PATH_PROTOCOL*HIDevicePath;
>>> +  EFI_BLOCK_IO_PROTOCOL   *BlockIo;
>>> +  EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *SimpleFileSystem;
>>> +  UINTN   Index;
>>> +  EFI_STATUS  Status;
>>>
>>>HandleBuffer  = NULL;
>>>
>>>Status = gBS->LocateHandleBuffer (
>>> -  AllHandles,
>>> -  NULL,
>>> +  ByProtocol,
>>> +  ,
>>>NULL,
>>>,
>>>
>>> @@ -1385,6 +1391,20 @@ ShellCommandConsistMappingInitialize (
>>>continue;
>>>  }
>>>
>>> +Status = gBS->HandleProtocol( HandleBuffer[HandleLoop],
>>> +  ,
>>> +  (VOID **)
>>> +  );
>>> +if (EFI_ERROR(Status)) {
>>> +  Status = gBS->HandleProtocol( HandleBuffer[HandleLoop],
>>> +,
>>> +(VOID **)
>>> +);
>>> +  if (EFI_ERROR(Status)) {
>>> +continue;
>>> +  }
>>> +}
>>> +
>>>  for (Index = 0; TempTable[Index] != NULL; Index++) {
>>>if (DevicePathCompare ([Index], ) == 0) {
>>>  FreePool (HIDevicePath);
>>>
> 

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

Re: [edk2] [PATCH 3/3] ArmPkg/ArmGic: remove GICv3 legacy override

[Supreeth Venkatesh]

Thanks Ard for getting this in.

Supreeth

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, December 03, 2015 7:59 AM
To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Supreeth Venkatesh
Cc: Ard Biesheuvel
Subject: [PATCH 3/3] ArmPkg/ArmGic: remove GICv3 legacy override

The need for a v2 legacy override to drive a GICv3 in v2 mode is no longer 
necessary, now that the code that enabled the GIC distributor no longer 
inadvertently kicks a v2 capable GICv3 into v2 mode. So remove the PCD and all 
references to it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec |  3 --
 ArmPkg/Drivers/ArmGic/ArmGicDxe.inf   |  1 -
 ArmPkg/Drivers/ArmGic/ArmGicLib.c |  6 ++--
 ArmPkg/Drivers/ArmGic/ArmGicLib.inf   |  3 --
 ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf|  3 --
 ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 35 
 6 files changed, 9 insertions(+), 42 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec index 
ff4531e44106..e8021d20bc78 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -70,9 +70,6 @@ [PcdsFeatureFlag.common]
   # Linux (instead of PSCI)
   gArmTokenSpaceGuid.PcdArmLinuxSpinTable|FALSE|BOOLEAN|0x0033

-  # Define if the GICv3 controller should use the GICv2 legacy
-  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy|FALSE|BOOLEAN|0x0042
-
 [PcdsFeatureFlag.ARM]
   # Whether to map normal memory as non-shareable. FALSE is the safe choice, 
but
   # TRUE may be appropriate to fix performance problems if you don't care 
about diff --git a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf 
b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
index e554301c4b28..31d90a6d473d 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
+++ b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
@@ -54,7 +54,6 @@ [Pcd.common]
   gArmTokenSpaceGuid.PcdGicDistributorBase
   gArmTokenSpaceGuid.PcdGicRedistributorsBase
   gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
-  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy

 [Depex]
   gEfiCpuArchProtocolGuid
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c 
b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
index 248e896c4b94..f218a8d7ef06 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
+++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
@@ -183,7 +183,7 @@ ArmGicEnableInterrupt (
   RegShift = Source % 32;

   Revision = ArmGicGetSupportedArchRevision ();
-  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
(PcdArmGicV3WithV2Legacy)) {
+  if (Revision == ARM_GIC_ARCH_REVISION_2) {
 // Write set-enable register
 MmioWrite32 (GicDistributorBase + ARM_GIC_ICDISER + (4 * RegOffset), 1 << 
RegShift);
   } else {
@@ -216,7 +216,7 @@ ArmGicDisableInterrupt (
   RegShift = Source % 32;

   Revision = ArmGicGetSupportedArchRevision ();
-  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
(PcdArmGicV3WithV2Legacy)) {
+  if (Revision == ARM_GIC_ARCH_REVISION_2) {
 // Write clear-enable register
 MmioWrite32 (GicDistributorBase + ARM_GIC_ICDICER + (4 * RegOffset), 1 << 
RegShift);
   } else {
@@ -249,7 +249,7 @@ ArmGicIsInterruptEnabled (
   RegShift = Source % 32;

   Revision = ArmGicGetSupportedArchRevision ();
-  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
(PcdArmGicV3WithV2Legacy)) {
+  if (Revision == ARM_GIC_ARCH_REVISION_2) {
 Interrupts = ((MmioRead32 (GicDistributorBase + ARM_GIC_ICDISER + (4 * 
RegOffset)) & (1 << RegShift)) != 0);
   } else {
 GicCpuRedistributorBase = GicGetCpuRedistributorBase 
(GicRedistributorBase, Revision); diff --git 
a/ArmPkg/Drivers/ArmGic/ArmGicLib.inf b/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
index 047adac85ff4..62f20eb55294 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
+++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
@@ -46,6 +46,3 @@ [Packages]

 [Pcd]
   gArmPlatformTokenSpaceGuid.PcdCoreCount
-
-[FeaturePcd]
-  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf 
b/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
index fc2e1bc01efe..efea9c828170 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
+++ b/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
@@ -47,6 +47,3 @@ [LibraryClasses]

 [Pcd]
   gArmPlatformTokenSpaceGuid.PcdCoreCount
-
-[FeaturePcd]
-  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
index 4afa3d5a09c2..0a75850200bd 100644
--- a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
+++ b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
@@ -254,9 +254,7 @@ GicV3DxeInitialize (
   // We will be driving this GIC in native v3 mode, i.e., with Affinity
   // Routing enabled. So ensure that the ARE bit is set.
   //
-  if (!FeaturePcdGet (PcdArmGicV3WithV2Legacy)) {
-MmioOr32 (mGicDistributorBase + ARM_GIC_ICDDCR, ARM_GIC_ICDDCR_ARE);
-  }
+  MmioOr32 (mGicDistributorBase + ARM_GIC_ICDDCR, ARM_GIC_ICDDCR_ARE);

   for (Index = 0; Index < 

Re: [edk2] [PATCH] ShellPkg: Refine the code to reduce time cost of 'map -r'

[Laszlo Ersek]

On 12/03/15 18:03, Carsey, Jaben wrote:
> Shumin,
> 
> Could we loop over a list of handles made by 
> 1) LocateHandleBuffer on BlockIO 
> 2) LocateHandleBuffer on SimpleFileSystem
> 3) Combine these lists (removing duplicates)

So this is exactly the use case that I had in mind (regardless of this
patch -- sorry again for hijacking the thread).

First, LocateHandleBuffer() with ByProtocol could be sped up if the
system maintained an "index by protocol GUID".

Second, combining two result sets (while removing or pinpointing
duplicates) is something I had to optimize occasionally in a previous
life (yes, I coded PL/SQL :)). Off the top of my head, I recall three
join methods that Oracle's execution plan generator used: hashing, sort
& merge, and nested loops.

If I recall correctly, in edk2 many joins are implemented with nested
loops (where the inner lookup is linear: O(n), resulting in O(n^2) time
for the join). I wonder if we could put the red-black tree library to
use somewhere (which rould result in O(logn) inner lookup time). Of
course the actual values of "n", and the constants inherent in that
library could defeat the whole idea.

So, as a first step, it would be nice to profile some shell commands,
and find the hot spots. Does edk2 support profiling in any form?

(Just musing...)

Thanks
Laszlo


> 
> Would that be faster?  Not sure if this would be worth it, but something I 
> thought of... Your change is still good.
> 
> Reviewed-by: Jaben Carsey 
> 
>> -Original Message-
>> From: Qiu, Shumin
>> Sent: Wednesday, December 02, 2015 9:36 PM
>> To: edk2-devel@lists.01.org
>> Cc: Qiu, Shumin ; Carsey, Jaben
>> 
>> Subject: [PATCH] ShellPkg: Refine the code to reduce time cost of 'map -r'
>> Importance: High
>>
>> In some platform 'map -r' may cost more than 1 min. This patch filter the
>> target handles by
>> BlockIO and SimpleFileSystem protocol to reduce the time cost.
>>
>> Cc: Jaben Carsey 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Qiu Shumin 
>> ---
>>  .../Library/UefiShellCommandLib/ConsistMapping.c   | 40
>> --
>>  1 file changed, 30 insertions(+), 10 deletions(-)
>>
>> diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
>> b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
>> index 9bd7b2c..86e8dc5 100644
>> --- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
>> +++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
>> @@ -16,6 +16,10 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>> +
>> +
>>
>>  typedef enum {
>>MTDTypeUnknown,
>> @@ -1349,20 +1353,22 @@ ShellCommandConsistMappingInitialize (
>>OUT EFI_DEVICE_PATH_PROTOCOL   ***Table
>>)
>>  {
>> -  EFI_HANDLE*HandleBuffer;
>> -  UINTN HandleNum;
>> -  UINTN HandleLoop;
>> -  EFI_DEVICE_PATH_PROTOCOL  **TempTable;
>> -  EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
>> -  EFI_DEVICE_PATH_PROTOCOL  *HIDevicePath;
>> -  UINTN Index;
>> -  EFI_STATUSStatus;
>> +  EFI_HANDLE  *HandleBuffer;
>> +  UINTN   HandleNum;
>> +  UINTN   HandleLoop;
>> +  EFI_DEVICE_PATH_PROTOCOL**TempTable;
>> +  EFI_DEVICE_PATH_PROTOCOL*DevicePath;
>> +  EFI_DEVICE_PATH_PROTOCOL*HIDevicePath;
>> +  EFI_BLOCK_IO_PROTOCOL   *BlockIo;
>> +  EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *SimpleFileSystem;
>> +  UINTN   Index;
>> +  EFI_STATUS  Status;
>>
>>HandleBuffer  = NULL;
>>
>>Status = gBS->LocateHandleBuffer (
>> -  AllHandles,
>> -  NULL,
>> +  ByProtocol,
>> +  ,
>>NULL,
>>,
>>
>> @@ -1385,6 +1391,20 @@ ShellCommandConsistMappingInitialize (
>>continue;
>>  }
>>
>> +Status = gBS->HandleProtocol( HandleBuffer[HandleLoop],
>> +  ,
>> +  (VOID **)
>> +  );
>> +if (EFI_ERROR(Status)) {
>> +  Status = gBS->HandleProtocol( HandleBuffer[HandleLoop],
>> +,
>> +(VOID **)
>> +);
>> +  if (EFI_ERROR(Status)) {
>> +continue;
>> +  }
>> +}
>> +
>>  for (Index = 0; TempTable[Index] != NULL; Index++) {
>>if (DevicePathCompare ([Index], ) == 0) {
>>  FreePool (HIDevicePath);
>> --
>> 1.9.5.msysgit.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

___
edk2-devel mailing list

Re: [edk2] MdeModulePkg: DebugAssert enhancement

[Anbazhagan, Baraneedharan]

Updated code based on your suggestion to use copy mem and ModuleNameSize 
calculation.


diff --git a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c 
b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
index f1d9827..c3010df 100644
--- a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
+++ b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
@@ -261,6 +261,7 @@ DebugAssert (
   UINTN  HeaderSize;
   UINTN  TotalSize;
   CHAR8  *Temp;
+  UINTN  ModuleNameSize;
   UINTN  FileNameSize;
   UINTN  DescriptionSize;
 
@@ -268,31 +269,40 @@ DebugAssert (
   // Get string size
   //
   HeaderSize   = sizeof (EFI_DEBUG_ASSERT_DATA);
+  //
+  // Compute string size of module name enclosed by []  
+  //
+  ModuleNameSize   = 2 + AsciiStrSize (gEfiCallerBaseName);
   FileNameSize = AsciiStrSize (FileName);
   DescriptionSize  = AsciiStrSize (Description);
 
   //
   // Make sure it will all fit in the passed in buffer.
   //
-  if (HeaderSize + FileNameSize + DescriptionSize > sizeof (Buffer)) {
+  if (HeaderSize + ModuleNameSize + FileNameSize + DescriptionSize > sizeof 
(Buffer)) {
 //
-// FileName + Description is too long to be filled into buffer. 
+// remove module name if it's too long to be filled into buffer
 //
-if (HeaderSize + FileNameSize < sizeof (Buffer)) {
-  //
-  // Description has enough buffer to be truncated. 
-  //
-  DescriptionSize = sizeof (Buffer) - HeaderSize - FileNameSize;
-} else {
+ModuleNameSize = 0;
+if (HeaderSize + FileNameSize + DescriptionSize > sizeof (Buffer)) {
   //
-  // FileName is too long to be filled into buffer.
-  // FileName will be truncated. Reserved one byte for Description NULL 
terminator.
+  // FileName + Description is too long to be filled into buffer. 
   //
-  DescriptionSize = 1;
-  FileNameSize= sizeof (Buffer) - HeaderSize - DescriptionSize;
+  if (HeaderSize + FileNameSize < sizeof (Buffer)) {
+//
+// Description has enough buffer to be truncated. 
+//
+DescriptionSize = sizeof (Buffer) - HeaderSize - FileNameSize;
+  } else {
+//
+// FileName is too long to be filled into buffer.
+// FileName will be truncated. Reserved one byte for Description NULL 
terminator.
+//
+DescriptionSize = 1;
+FileNameSize= sizeof (Buffer) - HeaderSize - DescriptionSize;
+  }
 }
   }
- 
   //
   // Fill in EFI_DEBUG_ASSERT_DATA
   //
@@ -300,12 +310,23 @@ DebugAssert (
   AssertData->LineNumber = (UINT32)LineNumber;
   TotalSize  = sizeof (EFI_DEBUG_ASSERT_DATA);
 
+  Temp = (CHAR8 *)(AssertData + 1);
+
+  //
+  // Copy Ascii [ModuleName].
+  //
+  if (ModuleNameSize != 0) {
+CopyMem(Temp, "[", 1);
+CopyMem(Temp + 1, gEfiCallerBaseName, ModuleNameSize - 3);
+CopyMem(Temp + ModuleNameSize - 2, "] ", 2);
+  }
+
   //
   // Copy Ascii FileName including NULL terminator.
   //
-  Temp = CopyMem (AssertData + 1, FileName, FileNameSize);
+  Temp = CopyMem (Temp + ModuleNameSize, FileName, FileNameSize);
   Temp[FileNameSize - 1] = 0;
-  TotalSize += FileNameSize;
+  TotalSize += (ModuleNameSize + FileNameSize);
 
   //
   // Copy Ascii Description include NULL terminator.
-- 
2.6.3.windows.1


> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, December 02, 2015 8:22 PM
> To: Gao, Liming; Anbazhagan, Baraneedharan; edk2-devel@lists.01.org; Kinney,
> Michael D
> Subject: RE: MdeModulePkg: DebugAssert enhancement
> 
> Baranee,
> 
> I also think the following line could be changed for smaller code gen from:
> 
> +  ModuleNameSize   = AsciiStrLen("[") + AsciiStrLen (gEfiCallerBaseName) +
> AsciiStrLen("] ");
> 
> To:
> 
> +  //
> +  // Compute string size of module name enclosed by []  //
> +  ModuleNameSize   = 2 + AsciiStrSize (gEfiCallerBaseName);
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Gao, Liming
> > Sent: Wednesday, December 2, 2015 6:07 PM
> > To: Anbazhagan, Baraneedharan ;
> > edk2-devel@lists.01.org
> > Subject: Re: [edk2] MdeModulePkg: DebugAssert enhancement
> >
> > Baranee:
> >   Could you use CopyMem() to fill gEfiCallerBaseName instead of
> > AsciiSPrint()? This library instance is for size optimization. So, it
> > uses
> > CopyMem() to fill FileName and Description.
> >
> > Thanks
> > Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Anbazhagan, Baraneedharan
> > Sent: Wednesday, December 02, 2015 11:42 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] MdeModulePkg: DebugAssert enhancement
> >
> > If the assert happens in a library, then it's hard to determine which 
> > module using
> that library 

Re: [edk2] [PATCH] ShellPkg: Refine the code to reduce time cost of 'map -r'

[Carsey, Jaben]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, December 03, 2015 9:16 AM
> To: Carsey, Jaben ; Qiu, Shumin
> ; edk2-de...@ml01.01.org
> Subject: Re: [edk2] [PATCH] ShellPkg: Refine the code to reduce time cost of
> 'map -r'
> Importance: High
> 
> On 12/03/15 18:04, Carsey, Jaben wrote:
> >
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Thursday, December 03, 2015 3:26 AM
> >> To: Qiu, Shumin ; edk2-de...@ml01.01.org
> >> Cc: Carsey, Jaben 
> >> Subject: Re: [edk2] [PATCH] ShellPkg: Refine the code to reduce time cost
> of
> >> 'map -r'
> >> Importance: High
> >>
> >> On 12/03/15 06:35, Qiu Shumin wrote:
> >>> In some platform 'map -r' may cost more than 1 min. This patch filter the
> >> target handles by
> >>> BlockIO and SimpleFileSystem protocol to reduce the time cost.
> >>
> >> Hijacking this thread and asking a more general question -- I noticed
> >> recently that the "devices" and "drivers" commands can take quite long.
> >> I guess there is a lot of processing to be done for those. But, has it
> >> been considered to change the internal representation of the protocol
> >> database to speed things up? (I'm asking this without knowing too much
> >> about the current representation.)
> >>
> >> I'm not suggesting that the current proto DB representation is slow; I'm
> >> just curious if the perf consequences of the representation have been
> >> considered before.
> >
> >
> > not to my knowledge.  Curiosity - do you mean internal representation in
> the shell or in the platform?  The shell maintains almost no internal
> representation of anything.
> 
> In the platform. The performance of some of the protocol boot services
> could depend on that representation.
> 
> But, maybe the shell could be optimized too (I haven't looked at the
> code). I can imagine that for cross-referencing various things it uses
> O(n^2) nested loops or something similar, even if state is not
> maintained longer than a command's execution.


Correct.  The data must be flushed after each command, but we could optimize 
the processing done within the commands.  I have looked and I can tell you that 
it could be better.  Heck I wrote most of that and I agree it could be better.

-Jaben

> 
> Thanks
> Laszlo
> 
> >
> >>
> >> Thanks!
> >> Laszlo
> >>
> >>>
> >>> Cc: Jaben Carsey 
> >>> Contributed-under: TianoCore Contribution Agreement 1.0
> >>> Signed-off-by: Qiu Shumin 
> >>> ---
> >>>  .../Library/UefiShellCommandLib/ConsistMapping.c   | 40
> >> --
> >>>  1 file changed, 30 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> >> b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> >>> index 9bd7b2c..86e8dc5 100644
> >>> --- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> >>> +++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
> >>> @@ -16,6 +16,10 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>> +#include 
> >>> +
> >>> +
> >>>
> >>>  typedef enum {
> >>>MTDTypeUnknown,
> >>> @@ -1349,20 +1353,22 @@ ShellCommandConsistMappingInitialize (
> >>>OUT EFI_DEVICE_PATH_PROTOCOL   ***Table
> >>>)
> >>>  {
> >>> -  EFI_HANDLE*HandleBuffer;
> >>> -  UINTN HandleNum;
> >>> -  UINTN HandleLoop;
> >>> -  EFI_DEVICE_PATH_PROTOCOL  **TempTable;
> >>> -  EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
> >>> -  EFI_DEVICE_PATH_PROTOCOL  *HIDevicePath;
> >>> -  UINTN Index;
> >>> -  EFI_STATUSStatus;
> >>> +  EFI_HANDLE  *HandleBuffer;
> >>> +  UINTN   HandleNum;
> >>> +  UINTN   HandleLoop;
> >>> +  EFI_DEVICE_PATH_PROTOCOL**TempTable;
> >>> +  EFI_DEVICE_PATH_PROTOCOL*DevicePath;
> >>> +  EFI_DEVICE_PATH_PROTOCOL*HIDevicePath;
> >>> +  EFI_BLOCK_IO_PROTOCOL   *BlockIo;
> >>> +  EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *SimpleFileSystem;
> >>> +  UINTN   Index;
> >>> +  EFI_STATUS  Status;
> >>>
> >>>HandleBuffer  = NULL;
> >>>
> >>>Status = gBS->LocateHandleBuffer (
> >>> -  AllHandles,
> >>> -  NULL,
> >>> +  ByProtocol,
> >>> +  ,
> >>>NULL,
> >>>,
> >>>
> >>> @@ -1385,6 +1391,20 @@ ShellCommandConsistMappingInitialize (
> >>>continue;
> >>>  }
> >>>
> >>> +Status = gBS->HandleProtocol( HandleBuffer[HandleLoop],
> >>> +  ,
> >>> +  (VOID **)
> >>> +  );
> >>> +if (EFI_ERROR(Status)) {
> >>> +  Status = 

Re: [edk2] [PATCH 0/4] CryptoPkg: fix ARM and RVCT issues

[Long, Qin]

Eugene,

As Ard's said, this patch series should cover / supersede your old fixes for 
RVCT build, which was pended by me. :-)
Could you please help to validate them? Since I have no RVCT environment. 


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, December 3, 2015 6:51 PM
> To: edk2-devel@lists.01.org; eug...@hp.com; Long, Qin; dw...@infradead.org
> Cc: Ard Biesheuvel
> Subject: [PATCH 0/4] CryptoPkg: fix ARM and RVCT issues
> 
> These fixes some minor issues in CryptoPkg that prevent CryptoPkg.dsc and
> OpensslLib from being built for ARM in general, and using RVCT in particular.
> 
> Note that I sent out a separate single patch that touches CryptoPkg as well,
> before I realized that there were more issues to address. This series, 
> combined
> with the other patch, should supersede the combined patch sent out by Eugene 
> on
> the 24th of Nov.
> 
> Ard Biesheuvel (4):
>   CryptoPkg ARM: add ArmSoftFloatLib resolution to CryptoPkg.dsc
>   CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC
>   CryptoPkg/OpensslLib: comment out unused code
>   CryptoPkg/OpensslLib: ignore more false positive warnings for RVCT
> 
>  CryptoPkg/CryptoPkg.dsc   |  3 ++
>  CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c |  2 +-
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 32 
> 
>  3 files changed, 23 insertions(+), 14 deletions(-)
> 
> --
> 1.9.1

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

Re: [edk2] [PATCH] MdeModulePkg: allow DxeIpl to load without permanent memory to enable S3 resume from temporary memory

[Tim Lewis]

Eugene --

Personally, I don't see this as a positive change. The PEI flow from the 
earliest days has said: at the end of PEI there is memory and there is a boot 
mode (see 11.2.1). You can see this assumption in 2.5 and 9.1 of the PI 
specification, where the result of the PEI Foundation (not the PEI phase) is 
"initialized permanent memory". 

The problem is that the specification is ambiguous, in that the PEI phase is 
sometimes said to end when the dispatcher stops and others (such as the 
end-of-PEI PPI) when it exits the S0/S3/Recovery boot paths (which would be in 
DXE IPL). 

The EDK2 implementation piggy-backs on DXE IPL (see 6.2.2) to divert to other 
boot flows (recovery and S3). But that is not a requirement. 

Making this change would change the contract between the PEI Foundation and the 
DXE IPL. As such, it would break existing implementations.

Tim




-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
Eugene
Sent: Thursday, December 03, 2015 7:34 AM
To: Laszlo Ersek ; Zeng, Star ; 
edk2-devel@lists.01.org ; Liming Gao 

Subject: Re: [edk2] [PATCH] MdeModulePkg: allow DxeIpl to load without 
permanent memory to enable S3 resume from temporary memory

> I'll admit that I don't fully understand the details and the expected 
> implications of this change, but: OVMF does install permanent PEI RAM 
> on the S3 resume path, and it would be nice if that wouldn't break.
> 
> ... If this is a very intrusive change, can it be made dependent on a 
> FeaturePCD perhaps?

This shouldn't be intrusive - at the time you call the IPL entry point 
permanent memory will be installed and the decompression and section extraction 
PPIs will be available.  So I would argue that the change should be fully 
transparent to existing implementations (if we do it right).  That being said 
I'd appreciate a test with the changes - wait for the updated patchset though, 
incorporating the feedback from Star.

Eugene
___
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 4/4] CryptoPkg/OpensslLib: ignore more false positive warnings for RVCT

[David Woodhouse]

On Thu, 2015-12-03 at 15:26 +0100, Ard Biesheuvel wrote:
> On 3 December 2015 at 12:26, Ard Biesheuvel  wrote:
> > On 3 December 2015 at 12:17, David Woodhouse  wrote:
> > > On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
> > > > The RVCT compiler chokes on a couple of issues in upstream OpenSSL
> > > > that
> > > > can be confirmed to be non-issues by inspection. So just ignore these
> > > > warnings entirely.
> > > 
> > > I still maintain this needs a reference to bug reports — either
> > > *compiler* bugs, if the compiler is just being entirely stupid, or
> > > OpenSSL RT tickets.
> > > 
> > > Or both, since it's possible to work around it compiler issues in the
> > > source code even if it's actually the *compiler* at fault.
> > > 
> > > But in no circumstance is it acceptable for such a patch to reference
> > > *neither* a compiler nor a source bug, surely?
> > > 
> > 
> > I don't think OpenSSL upstream is at fault here in any of the cases,
> > and I definitely would not recommend obfuscating OpenSSL to make RVCT
> > happy even if some instances could be easily solved by adding a
> > redundant zero initializer, since such changes often do more evil than
> > good.
> > 
> > So that leaves reporting bugs to ARM regarding RVCT. I guess that
> > should be an option, perhaps Eugene can take this up, being an actual
> > paying ARM customer? Note than I work for Linaro, not for ARM (unlike
> > Leif, who is an ARM employee that is seconded to Linaro), so of the
> > people involved, I am definitely not in the best position to chase
> > this.
> > 
> 
> ... and by the way, I see the following list for MSFT compiler:
> 
>   # C4244: conversion from type1 to type2, possible loss of data
>   # C4702: unreachable code
>   # C4706: assignment within conditional expression
>   # C4133: incompatible types - from type1 to type2
>   # C4245: conversion from type1 to type2, signed/unsigned mismatch
>   # C4267: conversion from size_t to type, possible loss of data
>   # C4305: truncation from type1 to type2 of smaller size
>   # C4306: conversion from type1 to type2 of greater size
>   # C4702: Potentially uninitialized local variable name used
> 
> where at least two seem to overlap with the three I am adding here:
> 4702 and 4706 (which I think the second occurrence of C4702 is
> supposed to refer to)
> 
> Are you saying that all of the issues have been reported to either
> OpenSSL or Microsoft? Or does this apply to RVCT only?

Those were done when I wasn't paying attention :)

On the other hand, there is perhaps scope for arguing that good
engineering practice doesn't apply to compilers that are basically
unmaintained. Hell, we're still stuck in the 20th century because the
Microsoft one hasn't even reached C99 levels of functionality yet.

If reporting bugs in RVCT is not feasible or if we don't expect fixes
even if we *do* work out how to report bugs, then perhaps we shouldn't
bother. But in that case I would wonder why we bother to support
building with it at all. It's not as if people can't already use GCC or
Clang, surely?

-- 
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] [PATCH] MdeModulePkg: allow DxeIpl to load without permanent memory to enable S3 resume from temporary memory

[Cohen, Eugene]

> I'll admit that I don't fully understand the details and the expected
> implications of this change, but: OVMF does install permanent PEI RAM on
> the S3 resume path, and it would be nice if that wouldn't break.
> 
> ... If this is a very intrusive change, can it be made dependent on a
> FeaturePCD perhaps?

This shouldn't be intrusive - at the time you call the IPL entry point 
permanent memory will be installed and the decompression and section extraction 
PPIs will be available.  So I would argue that the change should be fully 
transparent to existing implementations (if we do it right).  That being said 
I'd appreciate a test with the changes - wait for the updated patchset though, 
incorporating the feedback from Star.

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

Re: [edk2] [PATCH 4/4] CryptoPkg/OpensslLib: ignore more false positive warnings for RVCT

[Ard Biesheuvel]

On 3 December 2015 at 16:02, David Woodhouse  wrote:
> On Thu, 2015-12-03 at 15:26 +0100, Ard Biesheuvel wrote:
>> On 3 December 2015 at 12:26, Ard Biesheuvel  wrote:
>> > On 3 December 2015 at 12:17, David Woodhouse  wrote:
>> > > On Thu, 2015-12-03 at 11:50 +0100, Ard Biesheuvel wrote:
>> > > > The RVCT compiler chokes on a couple of issues in upstream OpenSSL
>> > > > that
>> > > > can be confirmed to be non-issues by inspection. So just ignore these
>> > > > warnings entirely.
>> > >
>> > > I still maintain this needs a reference to bug reports — either
>> > > *compiler* bugs, if the compiler is just being entirely stupid, or
>> > > OpenSSL RT tickets.
>> > >
>> > > Or both, since it's possible to work around it compiler issues in the
>> > > source code even if it's actually the *compiler* at fault.
>> > >
>> > > But in no circumstance is it acceptable for such a patch to reference
>> > > *neither* a compiler nor a source bug, surely?
>> > >
>> >
>> > I don't think OpenSSL upstream is at fault here in any of the cases,
>> > and I definitely would not recommend obfuscating OpenSSL to make RVCT
>> > happy even if some instances could be easily solved by adding a
>> > redundant zero initializer, since such changes often do more evil than
>> > good.
>> >
>> > So that leaves reporting bugs to ARM regarding RVCT. I guess that
>> > should be an option, perhaps Eugene can take this up, being an actual
>> > paying ARM customer? Note than I work for Linaro, not for ARM (unlike
>> > Leif, who is an ARM employee that is seconded to Linaro), so of the
>> > people involved, I am definitely not in the best position to chase
>> > this.
>> >
>>
>> ... and by the way, I see the following list for MSFT compiler:
>>
>>   # C4244: conversion from type1 to type2, possible loss of data
>>   # C4702: unreachable code
>>   # C4706: assignment within conditional expression
>>   # C4133: incompatible types - from type1 to type2
>>   # C4245: conversion from type1 to type2, signed/unsigned mismatch
>>   # C4267: conversion from size_t to type, possible loss of data
>>   # C4305: truncation from type1 to type2 of smaller size
>>   # C4306: conversion from type1 to type2 of greater size
>>   # C4702: Potentially uninitialized local variable name used
>>
>> where at least two seem to overlap with the three I am adding here:
>> 4702 and 4706 (which I think the second occurrence of C4702 is
>> supposed to refer to)
>>
>> Are you saying that all of the issues have been reported to either
>> OpenSSL or Microsoft? Or does this apply to RVCT only?
>
> Those were done when I wasn't paying attention :)
>

Yeah, I figured that :-)

> On the other hand, there is perhaps scope for arguing that good
> engineering practice doesn't apply to compilers that are basically
> unmaintained. Hell, we're still stuck in the 20th century because the
> Microsoft one hasn't even reached C99 levels of functionality yet.
>
> If reporting bugs in RVCT is not feasible or if we don't expect fixes
> even if we *do* work out how to report bugs, then perhaps we shouldn't
> bother. But in that case I would wonder why we bother to support
> building with it at all. It's not as if people can't already use GCC or
> Clang, surely?
>

As a (co-)maintainer of the ARM bits in EDK2, my life would be easier
if we had to support only the latest GCC, but sadly, that is not the
case. And RVCT does still outperform GCC in terms of code size, which
is a strong driver for its continued use, as far as I am aware.

But for me, the most important argument for just making these changes,
and not care about the underlying issues in /this/ particular case, is
that we don't develop OpenSSL. By the time a stable upstream release
hits the EDK2 code base, it is unlikely that RVCT is going to spot an
issue in the code that has not been spotted yet by all those
developers with all those compilers.

And as far as reporting bugs against the compiler goes; surely, you
know what talking to a compiler engineer is like: it is always /you/
that is doing something wrong :-)

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

[edk2] [PATCH v2] ArmPkg: update RVCT assembly functions to use new RVCT_ASM_EXPORT macro

[Cohen, Eugene]

This has the effect of splitting assembly functions into their own sections
so the linker can remove unused ones to save space.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen 
---
 .../ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm |   5 +-
 ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm   |  26 ++---
 ArmPkg/Library/ArmHvcLib/Arm/ArmHvc.asm|   5 +-
 ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm|  46 +++--
 .../Library/ArmLib/ArmV7/ArmV7ArchTimerSupport.asm |  64 +---
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   | 109 +++--
 ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm |  84 ++--
 ArmPkg/Library/ArmSmcLib/Arm/ArmSmc.asm|   5 +-
 ArmPkg/Library/ArmSmcLibNull/Arm/ArmSmcNull.asm|   5 +-
 ArmPkg/Library/BaseMemoryLibStm/Arm/CopyMem.asm|   5 +-
 ArmPkg/Library/BaseMemoryLibStm/Arm/SetMem.asm |   5 +-
 .../Library/BaseMemoryLibStm/BaseMemoryLibStm.inf  |   1 +
 ArmPkg/Library/BaseMemoryLibVstm/Arm/CopyMem.asm   |   5 +-
 ArmPkg/Library/BaseMemoryLibVstm/Arm/SetMem.asm|   5 +-
 .../BaseMemoryLibVstm/BaseMemoryLibVstm.inf|   1 +
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/lasr.asm  |   5 +-
 .../Library/CompilerIntrinsicsLib/Arm/ldivmod.asm  |   5 +-
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/llsl.asm  |   5 +-
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/llsr.asm  |   5 +-
 .../Library/CompilerIntrinsicsLib/Arm/memcpy.asm   |   5 +-
 .../Library/CompilerIntrinsicsLib/Arm/memcpy4.asm  |   5 +-
 .../Library/CompilerIntrinsicsLib/Arm/memmove.asm  |   5 +-
 .../Library/CompilerIntrinsicsLib/Arm/switch.asm   |   5 +-
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/uldiv.asm |   5 +-
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/uread.asm |   8 +-
 .../Library/CompilerIntrinsicsLib/Arm/uwrite.asm   |   8 +-
 .../CompilerIntrinsicsLib.inf  |   1 +
 27 files changed, 156 insertions(+), 277 deletions(-)

diff --git a/ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm 
b/ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm
index 7150834..1417c9a 100644
--- a/ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm
+++ b/ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm
@@ -15,16 +15,15 @@
 #include 
 #include 
 
+  INCLUDE AsmMacroExport.inc
   INCLUDE AsmMacroIoLib.inc
 
-  EXPORT  ArmGetScuBaseAddress
 
   PRESERVE8
-  AREAArmCortexA9Helper, CODE, READONLY
 
 // IN None
 // OUT r0 = SCU Base Address
-ArmGetScuBaseAddress
+ RVCT_ASM_EXPORT ArmGetScuBaseAddress
   // Read Configuration Base Address Register. ArmCBar cannot be called to get
   // the Configuration BAR as a stack is not necessary setup. The SCU is at the
   // offset 0x from the Private Memory Region.
diff --git a/ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm 
b/ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm
index 92c3236..4228fb5 100644
--- a/ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm
+++ b/ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm
@@ -13,23 +13,15 @@
 
 // For the moment we assume this will run in SVC mode on ARMv7
 
-EXPORT  ArmGicV3GetControlSystemRegisterEnable
-EXPORT  ArmGicV3SetControlSystemRegisterEnable
-EXPORT  ArmGicV3EnableInterruptInterface
-EXPORT  ArmGicV3DisableInterruptInterface
-EXPORT  ArmGicV3EndOfInterrupt
-EXPORT  ArmGicV3AcknowledgeInterrupt
-EXPORT  ArmGicV3SetPriorityMask
-EXPORT  ArmGicV3SetBinaryPointer
 
-AREA ArmGicV3, CODE, READONLY
+INCLUDE AsmMacroExport.inc
 
 //UINT32
 //EFIAPI
 //ArmGicGetControlSystemRegisterEnable (
 //  VOID
 //  );
-ArmGicV3GetControlSystemRegisterEnable
+ RVCT_ASM_EXPORT ArmGicV3GetControlSystemRegisterEnable
 mrc p15, 0, r0, c12, c12, 5 // ICC_SRE
 bx  lr
 
@@ -38,7 +30,7 @@ ArmGicV3GetControlSystemRegisterEnable
 //ArmGicSetControlSystemRegisterEnable (
 //  IN UINT32 ControlSystemRegisterEnable
 //  );
-ArmGicV3SetControlSystemRegisterEnable
+ RVCT_ASM_EXPORT ArmGicV3SetControlSystemRegisterEnable
 mcr p15, 0, r0, c12, c12, 5 // ICC_SRE
 isb
 bx  lr
@@ -47,7 +39,7 @@ ArmGicV3SetControlSystemRegisterEnable
 //ArmGicV3EnableInterruptInterface (
 //  VOID
 //  );
-ArmGicV3EnableInterruptInterface
+ RVCT_ASM_EXPORT ArmGicV3EnableInterruptInterface
 mov r0, #1
 mcr p15, 0, r0, c12, c12, 7 // ICC_IGRPEN1
 bx  lr
@@ -56,7 +48,7 @@ ArmGicV3EnableInterruptInterface
 //ArmGicV3DisableInterruptInterface (
 //  VOID
 //  );
-ArmGicV3DisableInterruptInterface
+ RVCT_ASM_EXPORT ArmGicV3DisableInterruptInterface
 mov r0, #0
 mcr p15, 0, r0, c12, c12, 7 // ICC_IGRPEN1
 bx  lr
@@ -65,7 +57,7 @@ ArmGicV3DisableInterruptInterface
 //ArmGicV3EndOfInterrupt (
 //  IN UINTN InterruptId
 //  );
-ArmGicV3EndOfInterrupt
+ RVCT_ASM_EXPORT ArmGicV3EndOfInterrupt
 mcr p15, 0, r0, c12, c12, 1 //ICC_EOIR1
 bx  lr
 
@@ 

[edk2] Git transition for EDK2

[Jarlstrom, Laurie]

To: EDK2 Community

This message is to notify you that near the end of January 2016 the active 
repository for EDK2 development will switch from using SourceForge to GitHub. 
The repository found at SourceForge will continue to be a read-only mirror of 
the master branch on GitHub.

A number of reasons have prompted us to switch to git most notably the 
communities request for us to make this change. Other reasons include the 
ability to have better commit logs and the use of branching to aid in reviewing 
larger changes and the addition of new features.

As part of this change a number of process changes will be adopted to support 
better use of git. This includes the method for sending out patches for review 
and other minor changes. Information regarding these changes will be found on 
http://tianocore.org  in the following weeks. In addition to the process 
changes documentation for users new to git will also be provided.

Please post any comments or questions related to this transition to the 
Edk2-devel mailing list or reply to the email message

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

Re: [edk2] [PATCH 3/3] ArmPkg: update RVCT assembly functions to use new RVCT_ASM_EXPORT macro

[Cohen, Eugene]

Ard,

To resume the conversation from before, there are a few files that my script 
was overly-aggressive in putting into their own section with the use of the 
macro.

These need to be backed out of the patch (I'd appreciate it if you could do 
update this locally):

These have code blocks that need to stick together:
ArmPkg\Drivers\CpuDxe\ArmV4\ExceptionSupport.asm
ArmPkg\Drivers\CpuDxe\ArmV6\ExceptionSupport.asm

These will have two different AREA directives for two labels that need to be 
the same:
ArmPkg\Library\CompilerIntrinsicsLib\Arm\div.asm

This has a "fall thru" function from memclr to memset that is totally broken by 
putting memset in its own section:
ArmPkg\Library\CompilerIntrinsicsLib\Arm\memset.asm
ArmPkg\Library\CompilerIntrinsicsLib\Arm\mullu.asm

I'll send an updated patch (with best efforts to get the text encoding and line 
wrap right).

Eugene

> -Original Message-
> From: Cohen, Eugene
> Sent: Wednesday, December 02, 2015 12:04 PM
> To: Ard Biesheuvel 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH 3/3] ArmPkg: update RVCT assembly
> functions to use new RVCT_ASM_EXPORT macro
> 
> Ard,
> 
> I just ran into this as well yesterday - I agree that the solution here is to
> back out the changes from the ExceptionSupport assembly or even the
> entire CpuDxe driver.  The benefit here is for libraries containing
> unrelated functions and this case is neither a library (it's a driver) nor
> unrelated functions (the exception handling is all used together).
> 
> The reason these files got hit was because my script was aggressively
> finding assembly in ArmPkg.  Although I reviewed the changes I didn't
> spot this one in time.
> 
> Eugene
> 
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Wednesday, December 02, 2015 9:42 AM
> > To: Cohen, Eugene 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [PATCH 3/3] ArmPkg: update RVCT assembly
> functions to
> > use new RVCT_ASM_EXPORT macro
> >
> > On 25 November 2015 at 20:11, Cohen, Eugene 
> wrote:
> > > This has the effect of splitting assembly functions into their own
> sections so
> > the linker can remove unused ones to save space.
> > >
> > > This has been tested to build with ArmPkg.dsc with RVCT 4.
> > >
> > > The majority of the conversion was performed with the attached
> python
> > script.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Eugene Cohen 
> >
> > This patch breaks ArmVirtQemu-ARM for me:
> >
> > ASSERT /home/ard/build/uefi-
> > next/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c(214): 0
> >
> > This is because you are removing the ALIGN=5 from the area .asm
> file that
> > contains the vector table, presumably this one:
> > ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.asm
> >
> > I also wonder if it makes sense in the first place to split the vector
> table into
> > discardable sections, so perhaps we should just drop those hunks?
> >
> >
> >
> >
> > > ---
> > >  .../ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm |   5 +-
> > >  ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm   |  26 ++---
> > >  ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.asm   |  14 +--
> > >  ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.asm   |  14 +--
> > >  ArmPkg/Library/ArmHvcLib/Arm/ArmHvc.asm|   5 +-
> > >  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm|  46 +++-
> -
> > >  .../Library/ArmLib/ArmV7/ArmV7ArchTimerSupport.asm |  64
> +---
> > >  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   | 109
> +++-
> > -
> > >  ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm |  84
> ++--
> > 
> > >  ArmPkg/Library/ArmSmcLib/Arm/ArmSmc.asm|   5 +-
> > >  ArmPkg/Library/ArmSmcLibNull/Arm/ArmSmcNull.asm|   5 +-
> > >  ArmPkg/Library/BaseMemoryLibStm/Arm/CopyMem.asm|   5 +-
> > >  ArmPkg/Library/BaseMemoryLibStm/Arm/SetMem.asm |   5 +-
> > >  .../Library/BaseMemoryLibStm/BaseMemoryLibStm.inf  |   1 +
> > >  ArmPkg/Library/BaseMemoryLibVstm/Arm/CopyMem.asm   |   5
> +-
> > >  ArmPkg/Library/BaseMemoryLibVstm/Arm/SetMem.asm|   5 +-
> > >  .../BaseMemoryLibVstm/BaseMemoryLibVstm.inf|   1 +
> > >  ArmPkg/Library/CompilerIntrinsicsLib/Arm/div.asm   |  14 +--
> > >  ArmPkg/Library/CompilerIntrinsicsLib/Arm/lasr.asm  |   5 +-
> > >  .../Library/CompilerIntrinsicsLib/Arm/ldivmod.asm  |   5 +-
> > >  ArmPkg/Library/CompilerIntrinsicsLib/Arm/llsl.asm  |   5 +-
> > >  ArmPkg/Library/CompilerIntrinsicsLib/Arm/llsr.asm  |   5 +-
> > >  .../Library/CompilerIntrinsicsLib/Arm/memcpy.asm   |   5 +-
> > >  .../Library/CompilerIntrinsicsLib/Arm/memcpy4.asm  |   5 +-
> > >  .../Library/CompilerIntrinsicsLib/Arm/memmove.asm  |   5 +-
> > >  .../Library/CompilerIntrinsicsLib/Arm/memset.asm   |  11 +--
> > >  ArmPkg/Library/CompilerIntrinsicsLib/Arm/mullu.asm |   8 +-
> > >  

Re: [edk2] [Patch 6/6] OvmfPkg: Fix VS2015 warning C4459 in XenBusDxe

[Kinney, Michael D]

Liming,

The source changes look good to me and I have verified that all 3 OVMF DSC 
files build with VS2015.  

Acked-by: Michael Kinney 

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Cc: Justen, Jordan L 
> Subject: [edk2] [Patch 6/6] OvmfPkg: Fix VS2015 warning C4459 in XenBusDxe
> 
> warning C4459: declaration of 'xs' hides global declaration.
> Update code to rename local variable xs to xsp to be different.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: Justen Jordan 
> ---
>  OvmfPkg/XenBusDxe/XenStore.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
> index 9850f1e..61976f9 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.c
> +++ b/OvmfPkg/XenBusDxe/XenStore.c
> @@ -992,9 +992,9 @@ NotifyEventChannelCheckForEvent (
>IN VOID *Context
>)
>  {
> -  XENSTORE_PRIVATE *xs;
> -  xs = (XENSTORE_PRIVATE *)Context;
> -  if (TestAndClearBit (xs->EventChannel, 
> xs->Dev->SharedInfo->evtchn_pending)) {
> +  XENSTORE_PRIVATE *xsp;
> +  xsp = (XENSTORE_PRIVATE *)Context;
> +  if (TestAndClearBit (xsp->EventChannel, 
> xsp->Dev->SharedInfo->evtchn_pending)) {
>  gBS->SignalEvent (Event);
>}
>  }
> @@ -1007,12 +1007,12 @@ NotifyEventChannelCheckForEvent (
>  STATIC
>  EFI_STATUS
>  XenStoreInitComms (
> -  XENSTORE_PRIVATE *xs
> +  XENSTORE_PRIVATE *xsp
>)
>  {
>EFI_STATUS Status;
>EFI_EVENT TimerEvent;
> -  struct xenstore_domain_interface *XenStore = xs->XenStore;
> +  struct xenstore_domain_interface *XenStore = xsp->XenStore;
> 
>Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, );
>Status = gBS->SetTimer (TimerEvent, TimerRelative,
> @@ -1029,8 +1029,8 @@ XenStoreInitComms (
>gBS->CloseEvent (TimerEvent);
> 
>Status = gBS->CreateEvent (EVT_NOTIFY_WAIT, TPL_NOTIFY,
> - NotifyEventChannelCheckForEvent, xs,
> - >EventChannelEvent);
> + NotifyEventChannelCheckForEvent, xsp,
> + >EventChannelEvent);
>ASSERT_EFI_ERROR (Status);
> 
>return Status;
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] InsertImageRecord and Section Alignment

[Hamel, Lee M]

Thanks for the solution.  Any idea why my code was fine before and now it's not 
(the design change reason, not that tools_def.txt changed)?  I'm trying to 
understand why a change was made that caused the problem.

-Original Message-
From: Kinney, Michael D 
Sent: Thursday, December 03, 2015 11:13 AM
To: Hamel, Lee M ; edk2-devel@lists.01.org; Kinney, 
Michael D 
Subject: RE: InsertImageRecord and Section Alignment

Lee,

You can fix this by adding the following to the DSC file to force modules of 
type DXE_RUNTIME_DRIVER to use 4KB alignment.

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
  MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hamel, 
> Lee M
> Sent: Thursday, December 3, 2015 10:57 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] InsertImageRecord and Section Alignment
> 
> I recently synced to a newer UDK 2015 and now get this serial output many 
> times for different images:
> 
>   InsertImageRecord - Section Alignment(0x20) is not 4K  
>   Image - \ReportStatusCodeRouterRuntimeDxe.pdb
> 
> Has anyone seen this problem when syncing to UDK 2015?  I am using Visual 
> Studio 2010 to build.
> 
> ___
> 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] InsertImageRecord and Section Alignment

[Hamel, Lee M]

I recently synced to a newer UDK 2015 and now get this serial output many times 
for different images:

  InsertImageRecord - Section Alignment(0x20) is not 4K  
  Image - \ReportStatusCodeRouterRuntimeDxe.pdb

Has anyone seen this problem when syncing to UDK 2015?  I am using Visual 
Studio 2010 to build.

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

Re: [edk2] [PATCH] MdeModulePkg: allow DxeIpl to load without permanent memory to enable S3 resume from temporary memory

[Cohen, Eugene]

Tim,

> Personally, I don't see this as a positive change. The PEI flow from the
> earliest days has said: at the end of PEI there is memory and there is a
> boot mode (see 11.2.1). You can see this assumption in 2.5 and 9.1 of
> the PI specification, where the result of the PEI Foundation (not the
> PEI phase) is "initialized permanent memory".

I think this reflects the history of PEI - it was developed first to initialize 
memory and then, "oh yeah, we need to find a place to do S3 resume".  As such 
2.5 makes no mention of S3 resume.  9.1 describes the handoff to the DXE 
Foundation and no one is arguing that you don't need permanent memory for that. 
 

> Making this change would change the contract between the PEI
> Foundation and the DXE IPL. As such, it would break existing
> implementations.

This is relaxing the contract so a DXE IPL with the requirement of permanent 
memory (depex) would continue to work on both old and new implementations.  
From what I can see, the contract here is really between the Memory Init driver 
and the updated DXE IPL with the removal of the permanent memory PPI 
dependency.  This change should be fully backwards compatible since existing 
Memory Init implementations that always publish permanent memory on S3 resume 
will continue to work.  Can you elaborate on what gets broken?

Thanks,

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

Re: [edk2] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Lee,

It is a feature from UEFI Specification 2.5 - Section 4.6 - EFI_PROPERTIES_TABLE

In order to set the 
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA bit, runtime 
drivers need to be built so their PE/COFF code and data sections do not share 
the same 4KB page.

The log message you are seeing is not an error.  It is a warning message that a 
runtime driver was loaded that does not meet the requirements to set this bit. 

Mike

> -Original Message-
> From: Hamel, Lee M
> Sent: Thursday, December 3, 2015 11:19 AM
> To: Kinney, Michael D ; edk2-devel@lists.01.org
> Subject: RE: InsertImageRecord and Section Alignment
> 
> Thanks for the solution.  Any idea why my code was fine before and now it's 
> not (the design change reason, not that tools_def.txt
> changed)?  I'm trying to understand why a change was made that caused the 
> problem.
> 
> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, December 03, 2015 11:13 AM
> To: Hamel, Lee M ; edk2-devel@lists.01.org; Kinney, 
> Michael D 
> Subject: RE: InsertImageRecord and Section Alignment
> 
> Lee,
> 
> You can fix this by adding the following to the DSC file to force modules of 
> type DXE_RUNTIME_DRIVER to use 4KB alignment.
> 
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > Hamel, Lee M
> > Sent: Thursday, December 3, 2015 10:57 AM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] InsertImageRecord and Section Alignment
> >
> > I recently synced to a newer UDK 2015 and now get this serial output many 
> > times for different images:
> >
> >   InsertImageRecord - Section Alignment(0x20) is not 4K  
> >   Image - \ReportStatusCodeRouterRuntimeDxe.pdb
> >
> > Has anyone seen this problem when syncing to UDK 2015?  I am using Visual 
> > Studio 2010 to build.
> >
> > ___
> > 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 4/6] MdeModulePkg: Fix VS2015 warning C4311 & C4312 in RegularExpressionDxe

[Kinney, Michael D]

Liming,

The source changes look good to me and I have verified that 
RegularExpressionDxe builds with VS2015.  I will let Samer do the review.

Acked-by: Michael Kinney 

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 4/6] MdeModulePkg: Fix VS2015 warning C4311 & C4312 in 
> RegularExpressionDxe
> 
> warning C4311: pointer truncation from 'void *' to 'unsigned long'
> warning C4312: conversion from 'unsigned long' to 'void *' of greater size
> Update code to convert type to UINTN first, then convert it to other type.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: El-Haj-Mahmoud Samer 
> ---
>  .../RegularExpressionDxe/Oniguruma/enc/unicode.c   | 22 ++---
>  .../RegularExpressionDxe/Oniguruma/regexec.c   | 36 
> +++---
>  .../RegularExpressionDxe/Oniguruma/regint.h|  4 +--
>  .../RegularExpressionDxe/Oniguruma/regparse.c  | 16 +-
>  4 files changed, 39 insertions(+), 39 deletions(-)
> 
> diff --git 
> a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> index 70a1a52..a906670 100644
> --- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> @@ -10920,12 +10920,12 @@ static int init_case_fold_table(void)
>if (ONIG_IS_NULL(FoldTable)) return ONIGERR_MEMORY;
>for (i = 0; i < (int )(sizeof(CaseFold)/sizeof(CaseFold_11_Type)); i++) {
>  p = [i];
> -st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t )&(p->to));
> +st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t 
> )(UINTN)&(p->to));
>}
>for (i = 0; i < (int )(sizeof(CaseFold_Locale)/sizeof(CaseFold_11_Type));
> i++) {
>  p = _Locale[i];
> -st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t )&(p->to));
> +st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t 
> )(UINTN)&(p->to));
>}
> 
>Unfold1Table = st_init_numtable_with_size(1000);
> @@ -10934,13 +10934,13 @@ static int init_case_fold_table(void)
>for (i = 0; i < (int )(sizeof(CaseUnfold_11)/sizeof(CaseUnfold_11_Type));
> i++) {
>  p1 = _11[i];
> -st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t )&(p1->to));
> +st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t 
> )(UINTN)&(p1->to));
>}
>for (i = 0;
> i < (int )(sizeof(CaseUnfold_11_Locale)/sizeof(CaseUnfold_11_Type));
> i++) {
>  p1 = _11_Locale[i];
> -st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t )&(p1->to));
> +st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t 
> )(UINTN)&(p1->to));
>}
> 
>Unfold2Table = st_init_table_with_size(_code2_hash, 200);
> @@ -10949,13 +10949,13 @@ static int init_case_fold_table(void)
>for (i = 0; i < (int )(sizeof(CaseUnfold_12)/sizeof(CaseUnfold_12_Type));
> i++) {
>  p2 = _12[i];
> -st_add_direct(Unfold2Table, (st_data_t )p2->from, (st_data_t )(>to));
> +st_add_direct(Unfold2Table, (st_data_t )(UINTN)p2->from, (st_data_t 
> )(UINTN)(>to));
>}
>for (i = 0;
> i < (int )(sizeof(CaseUnfold_12_Locale)/sizeof(CaseUnfold_12_Type));
> i++) {
>  p2 = _12_Locale[i];
> -st_add_direct(Unfold2Table, (st_data_t )p2->from, (st_data_t )(>to));
> +st_add_direct(Unfold2Table, (st_data_t )(UINTN)p2->from, (st_data_t 
> )(UINTN)(>to));
>}
> 
>Unfold3Table = st_init_table_with_size(_code3_hash, 30);
> @@ -10964,7 +10964,7 @@ static int init_case_fold_table(void)
>for (i = 0; i < (int )(sizeof(CaseUnfold_13)/sizeof(CaseUnfold_13_Type));
> i++) {
>  p3 = _13[i];
> -st_add_direct(Unfold3Table, (st_data_t )p3->from, (st_data_t )(>to));
> +st_add_direct(Unfold3Table, (st_data_t )(UINTN)p3->from, (st_data_t 
> )(UINTN)(>to));
>}
> 
> 
> @@ -11265,7 +11265,7 @@ 
> onigenc_unicode_get_case_fold_codes_by_str(OnigEncoding enc,
> }
>   }
> 
> - if (onig_st_lookup(Unfold2Table, (st_data_t )to->code,
> + if (onig_st_lookup(Unfold2Table, (st_data_t )(UINTN)to->code,
>  (void* )) != 0) {
> for (i = 0; i < z2->n; i++) {
>   if (z2->code[i] == code) continue;
> @@ -11291,7 +11291,7 @@ 
> onigenc_unicode_get_case_fold_codes_by_str(OnigEncoding enc,
> }
>   }
> 
> - if (onig_st_lookup(Unfold3Table, (st_data_t )to->code,
> + if (onig_st_lookup(Unfold3Table, (st_data_t )(UINTN)to->code,
>  (void* )) != 0) {
> for (i = 0; i < z2->n; i++) {
>   if (z2->code[i] == code) continue;
> @@ -11336,7 +11336,7 @@ 
> 

Re: [edk2] [PATCH v2] ArmPkg: update RVCT assembly functions to use new RVCT_ASM_EXPORT macro

[Ard Biesheuvel]

On 3 December 2015 at 20:22, Cohen, Eugene  wrote:
> This has the effect of splitting assembly functions into their own sections
> so the linker can remove unused ones to save space.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Eugene Cohen 

Reviewed-by: Ard Biesheuvel 

Committed as SVN r19109

Thanks Eugene!

> ---
>  .../ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm |   5 +-
>  ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm   |  26 ++---
>  ArmPkg/Library/ArmHvcLib/Arm/ArmHvc.asm|   5 +-
>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm|  46 +++--
>  .../Library/ArmLib/ArmV7/ArmV7ArchTimerSupport.asm |  64 +---
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   | 109 
> +++--
>  ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm |  84 ++--
>  ArmPkg/Library/ArmSmcLib/Arm/ArmSmc.asm|   5 +-
>  ArmPkg/Library/ArmSmcLibNull/Arm/ArmSmcNull.asm|   5 +-
>  ArmPkg/Library/BaseMemoryLibStm/Arm/CopyMem.asm|   5 +-
>  ArmPkg/Library/BaseMemoryLibStm/Arm/SetMem.asm |   5 +-
>  .../Library/BaseMemoryLibStm/BaseMemoryLibStm.inf  |   1 +
>  ArmPkg/Library/BaseMemoryLibVstm/Arm/CopyMem.asm   |   5 +-
>  ArmPkg/Library/BaseMemoryLibVstm/Arm/SetMem.asm|   5 +-
>  .../BaseMemoryLibVstm/BaseMemoryLibVstm.inf|   1 +
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/lasr.asm  |   5 +-
>  .../Library/CompilerIntrinsicsLib/Arm/ldivmod.asm  |   5 +-
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/llsl.asm  |   5 +-
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/llsr.asm  |   5 +-
>  .../Library/CompilerIntrinsicsLib/Arm/memcpy.asm   |   5 +-
>  .../Library/CompilerIntrinsicsLib/Arm/memcpy4.asm  |   5 +-
>  .../Library/CompilerIntrinsicsLib/Arm/memmove.asm  |   5 +-
>  .../Library/CompilerIntrinsicsLib/Arm/switch.asm   |   5 +-
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/uldiv.asm |   5 +-
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/uread.asm |   8 +-
>  .../Library/CompilerIntrinsicsLib/Arm/uwrite.asm   |   8 +-
>  .../CompilerIntrinsicsLib.inf  |   1 +
>  27 files changed, 156 insertions(+), 277 deletions(-)
>
> diff --git a/ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm 
> b/ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm
> index 7150834..1417c9a 100644
> --- a/ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm
> +++ b/ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm
> @@ -15,16 +15,15 @@
>  #include 
>  #include 
>
> +  INCLUDE AsmMacroExport.inc
>INCLUDE AsmMacroIoLib.inc
>
> -  EXPORT  ArmGetScuBaseAddress
>
>PRESERVE8
> -  AREAArmCortexA9Helper, CODE, READONLY
>
>  // IN None
>  // OUT r0 = SCU Base Address
> -ArmGetScuBaseAddress
> + RVCT_ASM_EXPORT ArmGetScuBaseAddress
>// Read Configuration Base Address Register. ArmCBar cannot be called to 
> get
>// the Configuration BAR as a stack is not necessary setup. The SCU is at 
> the
>// offset 0x from the Private Memory Region.
> diff --git a/ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm 
> b/ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm
> index 92c3236..4228fb5 100644
> --- a/ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm
> +++ b/ArmPkg/Drivers/ArmGic/GicV3/Arm/ArmGicV3.asm
> @@ -13,23 +13,15 @@
>
>  // For the moment we assume this will run in SVC mode on ARMv7
>
> -EXPORT  ArmGicV3GetControlSystemRegisterEnable
> -EXPORT  ArmGicV3SetControlSystemRegisterEnable
> -EXPORT  ArmGicV3EnableInterruptInterface
> -EXPORT  ArmGicV3DisableInterruptInterface
> -EXPORT  ArmGicV3EndOfInterrupt
> -EXPORT  ArmGicV3AcknowledgeInterrupt
> -EXPORT  ArmGicV3SetPriorityMask
> -EXPORT  ArmGicV3SetBinaryPointer
>
> -AREA ArmGicV3, CODE, READONLY
> +INCLUDE AsmMacroExport.inc
>
>  //UINT32
>  //EFIAPI
>  //ArmGicGetControlSystemRegisterEnable (
>  //  VOID
>  //  );
> -ArmGicV3GetControlSystemRegisterEnable
> + RVCT_ASM_EXPORT ArmGicV3GetControlSystemRegisterEnable
>  mrc p15, 0, r0, c12, c12, 5 // ICC_SRE
>  bx  lr
>
> @@ -38,7 +30,7 @@ ArmGicV3GetControlSystemRegisterEnable
>  //ArmGicSetControlSystemRegisterEnable (
>  //  IN UINT32 ControlSystemRegisterEnable
>  //  );
> -ArmGicV3SetControlSystemRegisterEnable
> + RVCT_ASM_EXPORT ArmGicV3SetControlSystemRegisterEnable
>  mcr p15, 0, r0, c12, c12, 5 // ICC_SRE
>  isb
>  bx  lr
> @@ -47,7 +39,7 @@ ArmGicV3SetControlSystemRegisterEnable
>  //ArmGicV3EnableInterruptInterface (
>  //  VOID
>  //  );
> -ArmGicV3EnableInterruptInterface
> + RVCT_ASM_EXPORT ArmGicV3EnableInterruptInterface
>  mov r0, #1
>  mcr p15, 0, r0, c12, c12, 7 // ICC_IGRPEN1
>  bx  lr
> @@ -56,7 +48,7 @@ ArmGicV3EnableInterruptInterface
>  //ArmGicV3DisableInterruptInterface (
>  //  VOID
>  //  );
> -ArmGicV3DisableInterruptInterface
> + RVCT_ASM_EXPORT 

Re: [edk2] Where do I find the system table address for an EFI app ?

[Shubha Ramani]

Thank you Michael - that helped a lot. I will let you know what happens...
Shubha Shubha D. ramanishubharam...@gmail.com
shubharam...@yahoo.com 


On Wednesday, December 2, 2015 6:59 PM, "Kinney, Michael D" 
 wrote:
 

 Shubha,

You can run the dmem command from the UEFI shell with no parameters, and it 
will show the UFI System Table address along with other standard table 
addresses.

Shell> dmem
Memory Address 0FD6E010 200 Bytes
  0FD6E010: 49 42 49 20 53 59 53 54-32 00 02 00 48 00 00 00  *IBI SYST2...H...*
. . .
  0FD6E200: AA AA 55 55 AA AA 55 55-55 55 AA AA 55 55 AA AA  *..UU....UU..*

Valid EFI Header at Address 0FD6E010
-
System: Table Structure size 0048 revision 00020032
ConIn (0F50A28C) ConOut (0F497054) StdErr (0F50A37C)
Runtime Services 0FD6EF90
Boot Services    0F89B5C0
SAL System Table 
ACPI Table      0FCEE000
ACPI 2.0 Table  0FCEE014
MPS Table        
SMBIOS Table    0FD63000

For a debugger, a platform can produce the EFI_DEBUG_IMAGE_INFO_TABLE.  UEFI 
Specification Section 17.4.2 describes how a debugger can find the UEFI System 
Table address from a structure that is on a 4MB boundary with a signature and a 
CRC.  This table also provides the list of LOADED_IMAGE_PROTOCOLs for PE/COFF 
images that have been loaded, so a debugger can load symbols.

Mike 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Carsey, Jaben
> Sent: Wednesday, December 2, 2015 9:42 AM
> To: Shubha Ramani ; edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: Re: [edk2] Where do I find the system table address for an EFI app ?
> 
> I am pretty sure it’s there in a shell app also.  What entry point lib are 
> you using to build your app?
> 
> -Jaben
> 
> From: Shubha Ramani [mailto:shubharam...@yahoo.com]
> Sent: Wednesday, December 02, 2015 9:11 AM
> To: Carsey, Jaben ; edk2-devel@lists.01.org
> Subject: Re: [edk2] Where do I find the system table address for an EFI app ?
> Importance: High
> 
> Not in a Shell App though. How do you answer to the debugger when it's asking 
> for the System Table address for a shell app ?
> 
> Thanks,
> 
> Shubha
> 
> Shubha D. Ramani
> shubharam...@gmail.com
> shubharam...@yahoo.com
> 
> 
> On Tuesday, December 1, 2015 8:39 AM, "Carsey, Jaben" 
> > wrote:
> 
> Its passed as a parameter to the "main" function when your app starts.
> 
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel 
> > [mailto:edk2-devel-boun...@lists.01.org]
> >  On Behalf Of
> > Shubha Ramani
> > Sent: Tuesday, December 01, 2015 8:35 AM
> > To: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Where do I find the system table address for an EFI app 
> > ?
> > Importance: High
> >
> >  I'm sorry but this was unclear. I meant where do I find the System Table
> > address for a UEFI Shell App ?The debugger is asking for it. I couldn't 
> > find it in
> > the generated *.map file.
> > Thanks
> > Shubha
> > Shubha D. ramanishubharam...@gmail.com
> > shubharam...@yahoo.com
> >
> >
> >    On Monday, November 30, 2015 3:00 PM, Shubha Ramani
> > > wrote:
> >
> >
> >  I'm trying to debug it using a debugger and the debugger is asking me this
> > question.
> > I looked at the *.map file which is generated and I could not locate the 
> > System
> > Table address.
> > Thanks,
> > Shubha Shubha D. 
> > ramanishubharam...@gmail.com
> > shubharam...@yahoo.com
> 
> >
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


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

Re: [edk2] [Patch 5/6] CryptoPkg: Disable VS2015 warning C4311 in OpensslLib

[Kinney, Michael D]

Liming,

Reviewed-by: Michael Kinney 

I have also verified that builds of the CryptoPkg complete with VS2015 for IA32 
and X64.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Cc: Long, Qin 
> Subject: [edk2] [Patch 5/6] CryptoPkg: Disable VS2015 warning C4311 in 
> OpensslLib
> 
> Warning C4311: pointer truncation from 'type' to 'type'.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: Long Qin 
> ---
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
> b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> index 20200c3..a6d511e 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> @@ -865,9 +865,10 @@
># C4305: truncation from type1 to type2 of smaller size
># C4306: conversion from type1 to type2 of greater size
># C4702: Potentially uninitialized local variable name used
> +  # C4311: pointer truncation from 'type' to 'type'
>#
>MSFT:*_*_IA32_CC_FLAGS= -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) 
> /wd4244 /wd4701 /wd4702 /wd4706
> -  MSFT:*_*_X64_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) 
> /wd4133 /wd4244 /wd4245 /wd4267 /wd4701
> /wd4305 /wd4306 /wd4702 /wd4706
> +  MSFT:*_*_X64_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) 
> /wd4133 /wd4244 /wd4245 /wd4267 /wd4701
> /wd4305 /wd4306 /wd4702 /wd4706 /wd4311
>MSFT:*_*_IPF_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) 
> /wd4133 /wd4244 /wd4245 /wd4267 /wd4701
> /wd4305 /wd4306 /wd4702 /wd4706
> 
>INTEL:*_*_IA32_CC_FLAGS   = -U_WIN32 -U_WIN64 -U_MSC_VER -U__ICC 
> $(OPENSSL_FLAGS) /w
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 3/6] MdeModulePkg: Fix VS2015 warning C4456 in RegularExpressionDxe

[Kinney, Michael D]

Liming,

The source changes look good to me and I have verified that 
RegularExpressionDxe builds with VS2015.  I will let Samer do the review.

Acked-by: Michael Kinney 

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 3/6] MdeModulePkg: Fix VS2015 warning C4456 in 
> RegularExpressionDxe
> 
> warning C4456: declaration of 'q' hides previous local declaration.
> Update code to use the different local variable name.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: El-Haj-Mahmoud Samer 
> ---
>  .../Universal/RegularExpressionDxe/Oniguruma/regexec.c   | 16 
> 
>  .../Universal/RegularExpressionDxe/Oniguruma/regint.h|  4 ++--
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regexec.c
> b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regexec.c
> index de5839a..5e3ffa1 100644
> --- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regexec.c
> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regexec.c
> @@ -1442,7 +1442,7 @@ match_at(regex_t* reg, const UChar* str, const UChar* 
> end,
>  case OP_EXACT1_IC:  MOP_IN(OP_EXACT1_IC);
>{
>   int len;
> - UChar *q, lowbuf[ONIGENC_MBC_CASE_FOLD_MAXLEN];
> + UChar *q1, lowbuf[ONIGENC_MBC_CASE_FOLD_MAXLEN];
> 
>   DATA_ENSURE(1);
>   len = ONIGENC_MBC_CASE_FOLD(encode,
> @@ -1450,12 +1450,12 @@ match_at(regex_t* reg, const UChar* str, const UChar* 
> end,
>   case_fold_flag,
>   , end, lowbuf);
>   DATA_ENSURE(0);
> - q = lowbuf;
> + q1 = lowbuf;
>   while (len-- > 0) {
> -   if (*p != *q) {
> +   if (*p != *q1) {
>  goto fail;
>}
> -   p++; q++;
> +   p++; q1++;
>   }
>}
>MOP_OUT;
> @@ -1531,7 +1531,7 @@ match_at(regex_t* reg, const UChar* str, const UChar* 
> end,
>  case OP_EXACTN_IC:  MOP_IN(OP_EXACTN_IC);
>{
>   int len;
> - UChar *q, *endp, lowbuf[ONIGENC_MBC_CASE_FOLD_MAXLEN];
> + UChar *qn, *endp, lowbuf[ONIGENC_MBC_CASE_FOLD_MAXLEN];
> 
>   GET_LENGTH_INC(tlen, p);
>   endp = p + tlen;
> @@ -1544,10 +1544,10 @@ match_at(regex_t* reg, const UChar* str, const UChar* 
> end,
> case_fold_flag,
> , end, lowbuf);
> DATA_ENSURE(0);
> -   q = lowbuf;
> +   qn = lowbuf;
> while (len-- > 0) {
> - if (*p != *q) goto fail;
> - p++; q++;
> + if (*p != *qn) goto fail;
> + p++; qn++;
> }
>   }
>}
> diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regint.h
> b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regint.h
> index 2db3b70..44589bf 100644
> --- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regint.h
> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regint.h
> @@ -329,8 +329,8 @@ typedef Bits*  BitSetRef;
>  #define SIZE_BITSETsizeof(BitSet)
> 
>  #define BITSET_CLEAR(bs) do {\
> -  int i;\
> -  for (i = 0; i < (int )BITSET_SIZE; i++) { (bs)[i] = 0; }   \
> +  int id;\
> +  for (id = 0; id < (int )BITSET_SIZE; id++) { (bs)[id] = 0; }   \
>  } while (0)
> 
>  #define BS_ROOM(bs,pos)(bs)[pos / BITS_IN_ROOM]
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Lee,

You can fix this by adding the following to the DSC file to force modules of 
type DXE_RUNTIME_DRIVER to use 4KB alignment.

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
  MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hamel, 
> Lee M
> Sent: Thursday, December 3, 2015 10:57 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] InsertImageRecord and Section Alignment
> 
> I recently synced to a newer UDK 2015 and now get this serial output many 
> times for different images:
> 
>   InsertImageRecord - Section Alignment(0x20) is not 4K  
>   Image - \ReportStatusCodeRouterRuntimeDxe.pdb
> 
> Has anyone seen this problem when syncing to UDK 2015?  I am using Visual 
> Studio 2010 to build.
> 
> ___
> 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] InsertImageRecord and Section Alignment

[Laszlo Ersek]

On 12/03/15 21:16, Kinney, Michael D wrote:
> Lee,
> 
> It is a feature from UEFI Specification 2.5 - Section 4.6 -
> EFI_PROPERTIES_TABLE
> 
> In order to set the
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA bit,
> runtime drivers need to be built so their PE/COFF code and data
> sections do not share the same 4KB page.
> 
> The log message you are seeing is not an error.  It is a warning
> message that a runtime driver was loaded that does not meet the
> requirements to set this bit.

Should the message be downgraded from EFI_D_ERROR to EFI_D_WARN
("MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c")?

Thanks
Laszlo

> 
> Mike
> 
>> -Original Message-
>> From: Hamel, Lee M
>> Sent: Thursday, December 3, 2015 11:19 AM
>> To: Kinney, Michael D ; edk2-devel@lists.01.org
>> Subject: RE: InsertImageRecord and Section Alignment
>>
>> Thanks for the solution.  Any idea why my code was fine before and now it's 
>> not (the design change reason, not that tools_def.txt
>> changed)?  I'm trying to understand why a change was made that caused the 
>> problem.
>>
>> -Original Message-
>> From: Kinney, Michael D
>> Sent: Thursday, December 03, 2015 11:13 AM
>> To: Hamel, Lee M ; edk2-devel@lists.01.org; Kinney, 
>> Michael D 
>> Subject: RE: InsertImageRecord and Section Alignment
>>
>> Lee,
>>
>> You can fix this by adding the following to the DSC file to force modules of 
>> type DXE_RUNTIME_DRIVER to use 4KB alignment.
>>
>> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>>   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
>>
>> Mike
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>>> Hamel, Lee M
>>> Sent: Thursday, December 3, 2015 10:57 AM
>>> To: edk2-devel@lists.01.org
>>> Subject: [edk2] InsertImageRecord and Section Alignment
>>>
>>> I recently synced to a newer UDK 2015 and now get this serial output many 
>>> times for different images:
>>>
>>>   InsertImageRecord - Section Alignment(0x20) is not 4K  
>>>   Image - \ReportStatusCodeRouterRuntimeDxe.pdb
>>>
>>> Has anyone seen this problem when syncing to UDK 2015?  I am using Visual 
>>> Studio 2010 to build.
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

Re: [edk2] Git transition for EDK2

[Laszlo Ersek]

On 12/03/15 21:05, Jarlstrom, Laurie wrote:
> To: EDK2 Community
> 
> This message is to notify you that near the end of January 2016 the
> active repository for EDK2 development will switch from using
> SourceForge to GitHub. The repository found at SourceForge will
> continue to be a read-only mirror of the master branch on GitHub.
> 
> A number of reasons have prompted us to switch to git most notably
> the communities request for us to make this change. Other reasons
> include the ability to have better commit logs and the use of
> branching to aid in reviewing larger changes and the addition of new
> features.
> 
> As part of this change a number of process changes will be adopted to
> support better use of git. This includes the method for sending out
> patches for review and other minor changes. Information regarding
> these changes will be found on http://tianocore.org  in the following
> weeks. In addition to the process changes documentation for users new
> to git will also be provided.
> 
> Please post any comments or questions related to this transition to
> the Edk2-devel mailing list or reply to the email message
> 
> Thanks, Tianocore.org Administration

Great news!

I'd like to ask for confirmation in two points:

(1) that the git repo will remain a unified one (I think this has been
made possible by the BaseTools support for external packages);

(2) that a purely email based setup will remain fully functional for
participation (posting and reviewing), regardless of whether additional
web based utilities will be developed.

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

Re: [edk2] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Laszlo,

That is a good question.  If a platform requires 
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA to be set, then 
it is an error condition.  That is why it is an error message and not a warning 
message.

We could consider changing this specific message to a warning, and add one 
error message from the \MdeModulePkg\Universal\PropertiesTableAttributesDxe 
module.  That way, only platforms that include this module will get an error 
message if any runtime modules for not use 4KB aligned.

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, December 3, 2015 3:36 PM
> To: Kinney, Michael D 
> Cc: Hamel, Lee M ; edk2-devel@lists.01.org 
> 
> Subject: Re: [edk2] InsertImageRecord and Section Alignment
> 
> On 12/03/15 21:16, Kinney, Michael D wrote:
> > Lee,
> >
> > It is a feature from UEFI Specification 2.5 - Section 4.6 -
> > EFI_PROPERTIES_TABLE
> >
> > In order to set the
> > EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA bit,
> > runtime drivers need to be built so their PE/COFF code and data
> > sections do not share the same 4KB page.
> >
> > The log message you are seeing is not an error.  It is a warning
> > message that a runtime driver was loaded that does not meet the
> > requirements to set this bit.
> 
> Should the message be downgraded from EFI_D_ERROR to EFI_D_WARN
> ("MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c")?
> 
> Thanks
> Laszlo
> 
> >
> > Mike
> >
> >> -Original Message-
> >> From: Hamel, Lee M
> >> Sent: Thursday, December 3, 2015 11:19 AM
> >> To: Kinney, Michael D ; edk2-devel@lists.01.org
> >> Subject: RE: InsertImageRecord and Section Alignment
> >>
> >> Thanks for the solution.  Any idea why my code was fine before and now 
> >> it's not (the design change reason, not that tools_def.txt
> >> changed)?  I'm trying to understand why a change was made that caused the 
> >> problem.
> >>
> >> -Original Message-
> >> From: Kinney, Michael D
> >> Sent: Thursday, December 03, 2015 11:13 AM
> >> To: Hamel, Lee M ; edk2-devel@lists.01.org; Kinney, 
> >> Michael D 
> >> Subject: RE: InsertImageRecord and Section Alignment
> >>
> >> Lee,
> >>
> >> You can fix this by adding the following to the DSC file to force modules 
> >> of type DXE_RUNTIME_DRIVER to use 4KB alignment.
> >>
> >> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> >>   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> >>
> >> Mike
> >>
> >>> -Original Message-
> >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >>> Hamel, Lee M
> >>> Sent: Thursday, December 3, 2015 10:57 AM
> >>> To: edk2-devel@lists.01.org
> >>> Subject: [edk2] InsertImageRecord and Section Alignment
> >>>
> >>> I recently synced to a newer UDK 2015 and now get this serial output many 
> >>> times for different images:
> >>>
> >>>   InsertImageRecord - Section Alignment(0x20) is not 4K  
> >>>   Image - \ReportStatusCodeRouterRuntimeDxe.pdb
> >>>
> >>> Has anyone seen this problem when syncing to UDK 2015?  I am using Visual 
> >>> Studio 2010 to build.
> >>>
> >>> ___
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>> https://lists.01.org/mailman/listinfo/edk2-devel
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> >

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

Re: [edk2] [PATCH] MdeModulePkg: allow DxeIpl to load without permanent memory to enable S3 resume from temporary memory

[Tim Lewis]

You're probably right. I'm very used to catching problems with PEI at that 
ASSERT() so I hate to see it go. But it could move to some well-defined place 
in DxeIpl.

I think that the language of the PEI spec needs some clean up in this regard. 
The PEI Core/PEI Foundation/PEI Dispatcher/PEI Phase terminology muddle makes 
it hard to be precise about this kind of thing.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
Eugene
Sent: Thursday, December 03, 2015 11:16 AM
To: Tim Lewis ; Laszlo Ersek ; Zeng, 
Star ; edk2-devel@lists.01.org ; 
Liming Gao 
Subject: Re: [edk2] [PATCH] MdeModulePkg: allow DxeIpl to load without 
permanent memory to enable S3 resume from temporary memory

Tim,

> Personally, I don't see this as a positive change. The PEI flow from 
> the earliest days has said: at the end of PEI there is memory and 
> there is a boot mode (see 11.2.1). You can see this assumption in 2.5 
> and 9.1 of the PI specification, where the result of the PEI 
> Foundation (not the PEI phase) is "initialized permanent memory".

I think this reflects the history of PEI - it was developed first to initialize 
memory and then, "oh yeah, we need to find a place to do S3 resume".  As such 
2.5 makes no mention of S3 resume.  9.1 describes the handoff to the DXE 
Foundation and no one is arguing that you don't need permanent memory for that. 
 

> Making this change would change the contract between the PEI 
> Foundation and the DXE IPL. As such, it would break existing 
> implementations.

This is relaxing the contract so a DXE IPL with the requirement of permanent 
memory (depex) would continue to work on both old and new implementations.  
From what I can see, the contract here is really between the Memory Init driver 
and the updated DXE IPL with the removal of the permanent memory PPI 
dependency.  This change should be fully backwards compatible since existing 
Memory Init implementations that always publish permanent memory on S3 resume 
will continue to work.  Can you elaborate on what gets broken?

Thanks,

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

Re: [edk2] [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver

[Kinney, Michael D]

Hi Ray,

I agree a UINT64 Offset would be good for the Offset field.  It would also be 
good to order the fields and pad the structure so they are naturally aligned.  
Maybe like the following with some comment changes:

typedef struct {
  UINT16  VendorId;   ///< Vendor ID to match the PCI device.  The value 
0x terminates the list of entries.
  UINT16  DeviceId;   ///< Device ID to match the PCI device
  UINT32  ClockRate;  ///< UART clock rate.  Set to 0 for default clock 
rate of 1843200 Hz
  UINT64  Offset; ///< The byte offset into to the BAR
  UINT8   BarIndex;   ///< Which BAR to get the UART base address
  UINT8   RegisterStride; ///< UART register stride in bytes.  Set to 0 for 
default register stride of 1 byte.
  UINT8  Reserved[6];
} PCI_SERIAL_PARAMETER;

You need to add this module to the MdeModulePkg DSC file.

The code is currently limited to 115200 baud.  There are many UARTs that 
support higher baud rates, so this restriction needs to be removed.

If a non-standard ClockRate is used, then the actual baud rate may not exactly 
match the expected baud rate, but as long as we are within a few percent, the 
UART is stable.

I would like to use this driver as a replacement for the UART driver for Quark 
that I have posted on GitHub at: 


https://github.com/mdkinney/edk2/tree/Quark/QuarkSocPkg/QuarkSouthCluster/Uart/Dxe

It has support for baud rate up to 921600 and closest baud rate match with a 
few percent and support for larger Tx FIFOs and extra flushes of the Tx FIFO 
when doing a Reset or a UART config change.  Please let me know if you want me 
to help merge in some of those features to your patch.

Thanks,

Mike

> -Original Message-
> From: Tian, Feng
> Sent: Wednesday, December 2, 2015 9:13 PM
> To: Ni, Ruiyu ; Kinney, Michael D 
> 
> Cc: edk2-devel@lists.01.org; Tian, Feng 
> Subject: RE: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> 
> Suggest to use UINT64 for Offset field to be consistent with PciIo protocol 
> definition.
> 
> Others look good to me
> 
> Reviewed-by: Feng Tian 
> 
> Thanks
> Feng
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, 
> Ruiyu
> Sent: Monday, November 30, 2015 10:12
> To: Kinney, Michael D
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> 
> Mike,
> Could you please review whether the PCD structure defined as below is good?
> 
> +#pragma pack(1)
> +///
> +/// PcdPciSerialParameters contains zero or more instances of the below 
> structure.
> +/// If a PCI device contains multiple UARTs, PcdPciSerialParameters needs to 
> contain
> +/// two instances of the below structure, with the VendorId and DeviceId 
> equals to the
> +/// device ID and vendor ID of the device. If the PCI device uses the first 
> two BARs
> +/// to support multiple UARTs, BarIndex of first instance equals to 0 and 
> BarIndex of
> +/// second one equals to 1; if the PCI device uses the first BAR to support 
> multiple
> +/// UARTs, BarIndex of both instance equals to 0 and Offset of first 
> instance equals
> +/// to 0 while Offset of second one equals to some value bigger or equal to 
> 8.
> +/// For certain UART whose register needs to be accessed in DWORD aligned 
> address,
> +/// RegisterStride equals to 4.
> +///
> +typedef struct {
> +  UINT16  VendorId;   ///< Vendor ID to match the PCI device, 0x 
> terminates the entries
> +  UINT16  DeviceId;   ///< Device ID to match the PCI device
> +  UINT8   BarIndex;   ///< Which BAR to get the UART base address
> +  UINT16  Offset; ///< The offset to the BAR
> +  UINT8   RegisterStride; ///< UART register stride, 0 to use 1 as register 
> stride
> +  UINT32  ClockRate;  ///< UART clock rate, 0 to use default clock rate 
> 1843200
> +} PCI_SERIAL_PARAMETER;> +#pragma pack()
> 
> Regards,
> Ray
> 
> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, November 25, 2015 10:30 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Tian, Feng ; Kinney, 
> Michael D 
> Subject: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> 
> PciSioSerialDxe driver can manages UARTs on a SIO chip or a PCI/PCIE
> card.
> It manages the SIO instance whose last device path node is a ACPI
> device path and the HID in the ACPI device path node equals to
> EISA_PNP_ID (0x501).
> It also manages the PCI IO instance whose class code is 7/0/2 (16550
> UART). But when proper value is set to PcdPciSerialParameters, the
> driver can also manage non-standard PCI serial cards by matching
> the Vendor ID and Device ID specified in PcdPciSerialParameters.
> The PCI BAR index, IO/MMIO offset, register stride, clock rate can
> also be specified through the same PCD.
> 
> Contributed-under: TianoCore 

Re: [edk2] [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver

[Kinney, Michael D]

Ray,

I tried to build this module into a platform, and I am getting function name 
collisions with BaseSerialPortLib16550 for the symbols:

SerialPortReadRegister
SerialPortWriteRegister

I recommend you change the names of these 2 functions.

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, December 3, 2015 4:00 PM
> To: Tian, Feng ; Ni, Ruiyu ; Kinney, 
> Michael D 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> 
> Hi Ray,
> 
> I agree a UINT64 Offset would be good for the Offset field.  It would also be 
> good to order the fields and pad the structure so they are
> naturally aligned.  Maybe like the following with some comment changes:
> 
> typedef struct {
>   UINT16  VendorId;   ///< Vendor ID to match the PCI device.  The value 
> 0x terminates the list of entries.
>   UINT16  DeviceId;   ///< Device ID to match the PCI device
>   UINT32  ClockRate;  ///< UART clock rate.  Set to 0 for default clock 
> rate of 1843200 Hz
>   UINT64  Offset; ///< The byte offset into to the BAR
>   UINT8   BarIndex;   ///< Which BAR to get the UART base address
>   UINT8   RegisterStride; ///< UART register stride in bytes.  Set to 0 for 
> default register stride of 1 byte.
>   UINT8  Reserved[6];
> } PCI_SERIAL_PARAMETER;
> 
> You need to add this module to the MdeModulePkg DSC file.
> 
> The code is currently limited to 115200 baud.  There are many UARTs that 
> support higher baud rates, so this restriction needs to be
> removed.
> 
> If a non-standard ClockRate is used, then the actual baud rate may not 
> exactly match the expected baud rate, but as long as we are
> within a few percent, the UART is stable.
> 
> I would like to use this driver as a replacement for the UART driver for 
> Quark that I have posted on GitHub at:
> 
>   
> https://github.com/mdkinney/edk2/tree/Quark/QuarkSocPkg/QuarkSouthCluster/Uart/Dxe
> 
> It has support for baud rate up to 921600 and closest baud rate match with a 
> few percent and support for larger Tx FIFOs and extra
> flushes of the Tx FIFO when doing a Reset or a UART config change.  Please 
> let me know if you want me to help merge in some of
> those features to your patch.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Tian, Feng
> > Sent: Wednesday, December 2, 2015 9:13 PM
> > To: Ni, Ruiyu ; Kinney, Michael D 
> > 
> > Cc: edk2-devel@lists.01.org; Tian, Feng 
> > Subject: RE: [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> >
> > Suggest to use UINT64 for Offset field to be consistent with PciIo protocol 
> > definition.
> >
> > Others look good to me
> >
> > Reviewed-by: Feng Tian 
> >
> > Thanks
> > Feng
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, 
> > Ruiyu
> > Sent: Monday, November 30, 2015 10:12
> > To: Kinney, Michael D
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [Patch 1/2] MdeModulePkg: Add PciSioSerialDxe driver
> >
> > Mike,
> > Could you please review whether the PCD structure defined as below is good?
> >
> > +#pragma pack(1)
> > +///
> > +/// PcdPciSerialParameters contains zero or more instances of the below 
> > structure.
> > +/// If a PCI device contains multiple UARTs, PcdPciSerialParameters needs 
> > to contain
> > +/// two instances of the below structure, with the VendorId and DeviceId 
> > equals to the
> > +/// device ID and vendor ID of the device. If the PCI device uses the 
> > first two BARs
> > +/// to support multiple UARTs, BarIndex of first instance equals to 0 and 
> > BarIndex of
> > +/// second one equals to 1; if the PCI device uses the first BAR to 
> > support multiple
> > +/// UARTs, BarIndex of both instance equals to 0 and Offset of first 
> > instance equals
> > +/// to 0 while Offset of second one equals to some value bigger or equal 
> > to 8.
> > +/// For certain UART whose register needs to be accessed in DWORD aligned 
> > address,
> > +/// RegisterStride equals to 4.
> > +///
> > +typedef struct {
> > +  UINT16  VendorId;   ///< Vendor ID to match the PCI device, 0x 
> > terminates the entries
> > +  UINT16  DeviceId;   ///< Device ID to match the PCI device
> > +  UINT8   BarIndex;   ///< Which BAR to get the UART base address
> > +  UINT16  Offset; ///< The offset to the BAR
> > +  UINT8   RegisterStride; ///< UART register stride, 0 to use 1 as 
> > register stride
> > +  UINT32  ClockRate;  ///< UART clock rate, 0 to use default clock 
> > rate 1843200
> > +} PCI_SERIAL_PARAMETER;> +#pragma pack()
> >
> > Regards,
> > Ray
> >
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Wednesday, November 25, 2015 10:30 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu ; 

Re: [edk2] [Patch 4/6] MdeModulePkg: Fix VS2015 warning C4311 & C4312 in RegularExpressionDxe

[El-Haj-Mahmoud, Samer]

Looks good:

Reviewed-By:  Samer El-Haj-Mahmoud 


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney, 
Michael D
Sent: Thursday, December 3, 2015 1:07 PM
To: Gao, Liming ; edk2-devel@lists.01.org; Kinney, 
Michael D 
Subject: Re: [edk2] [Patch 4/6] MdeModulePkg: Fix VS2015 warning C4311 & C4312 
in RegularExpressionDxe

Liming,

The source changes look good to me and I have verified that 
RegularExpressionDxe builds with VS2015.  I will let Samer do the review.

Acked-by: Michael Kinney 

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Liming Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 4/6] MdeModulePkg: Fix VS2015 warning C4311 & 
> C4312 in RegularExpressionDxe
> 
> warning C4311: pointer truncation from 'void *' to 'unsigned long'
> warning C4312: conversion from 'unsigned long' to 'void *' of greater 
> size Update code to convert type to UINTN first, then convert it to other 
> type.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: El-Haj-Mahmoud Samer 
> ---
>  .../RegularExpressionDxe/Oniguruma/enc/unicode.c   | 22 ++---
>  .../RegularExpressionDxe/Oniguruma/regexec.c   | 36 
> +++---
>  .../RegularExpressionDxe/Oniguruma/regint.h|  4 +--
>  .../RegularExpressionDxe/Oniguruma/regparse.c  | 16 +-
>  4 files changed, 39 insertions(+), 39 deletions(-)
> 
> diff --git 
> a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> index 70a1a52..a906670 100644
> --- 
> a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicod
> +++ e.c
> @@ -10920,12 +10920,12 @@ static int init_case_fold_table(void)
>if (ONIG_IS_NULL(FoldTable)) return ONIGERR_MEMORY;
>for (i = 0; i < (int )(sizeof(CaseFold)/sizeof(CaseFold_11_Type)); i++) {
>  p = [i];
> -st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t )&(p->to));
> +st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t 
> + )(UINTN)&(p->to));
>}
>for (i = 0; i < (int )(sizeof(CaseFold_Locale)/sizeof(CaseFold_11_Type));
> i++) {
>  p = _Locale[i];
> -st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t )&(p->to));
> +st_add_direct(FoldTable, (st_data_t )p->from, (st_data_t 
> + )(UINTN)&(p->to));
>}
> 
>Unfold1Table = st_init_numtable_with_size(1000); @@ -10934,13 
> +10934,13 @@ static int init_case_fold_table(void)
>for (i = 0; i < (int )(sizeof(CaseUnfold_11)/sizeof(CaseUnfold_11_Type));
> i++) {
>  p1 = _11[i];
> -st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t )&(p1->to));
> +st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t 
> + )(UINTN)&(p1->to));
>}
>for (i = 0;
> i < (int )(sizeof(CaseUnfold_11_Locale)/sizeof(CaseUnfold_11_Type));
> i++) {
>  p1 = _11_Locale[i];
> -st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t )&(p1->to));
> +st_add_direct(Unfold1Table, (st_data_t )p1->from, (st_data_t 
> + )(UINTN)&(p1->to));
>}
> 
>Unfold2Table = st_init_table_with_size(_code2_hash, 200); @@ 
> -10949,13 +10949,13 @@ static int init_case_fold_table(void)
>for (i = 0; i < (int )(sizeof(CaseUnfold_12)/sizeof(CaseUnfold_12_Type));
> i++) {
>  p2 = _12[i];
> -st_add_direct(Unfold2Table, (st_data_t )p2->from, (st_data_t )(>to));
> +st_add_direct(Unfold2Table, (st_data_t )(UINTN)p2->from, 
> + (st_data_t )(UINTN)(>to));
>}
>for (i = 0;
> i < (int )(sizeof(CaseUnfold_12_Locale)/sizeof(CaseUnfold_12_Type));
> i++) {
>  p2 = _12_Locale[i];
> -st_add_direct(Unfold2Table, (st_data_t )p2->from, (st_data_t )(>to));
> +st_add_direct(Unfold2Table, (st_data_t )(UINTN)p2->from, 
> + (st_data_t )(UINTN)(>to));
>}
> 
>Unfold3Table = st_init_table_with_size(_code3_hash, 30); @@ 
> -10964,7 +10964,7 @@ static int init_case_fold_table(void)
>for (i = 0; i < (int )(sizeof(CaseUnfold_13)/sizeof(CaseUnfold_13_Type));
> i++) {
>  p3 = _13[i];
> -st_add_direct(Unfold3Table, (st_data_t )p3->from, (st_data_t )(>to));
> +st_add_direct(Unfold3Table, (st_data_t )(UINTN)p3->from, 
> + (st_data_t )(UINTN)(>to));
>}
> 
> 
> @@ -11265,7 +11265,7 @@ 
> onigenc_unicode_get_case_fold_codes_by_str(OnigEncoding enc,
> }
>   }
> 
> - if (onig_st_lookup(Unfold2Table, (st_data_t )to->code,
> + if (onig_st_lookup(Unfold2Table, (st_data_t )(UINTN)to->code,
>  (void* )) != 0) {
> for (i = 0; i < z2->n; i++) 

Re: [edk2] Git transition for EDK2

[Jordan Justen]

On 2015-12-03 15:41:22, Laszlo Ersek wrote:
> On 12/03/15 21:05, Jarlstrom, Laurie wrote:
> > To: EDK2 Community
> > 
> > This message is to notify you that near the end of January 2016 the
> > active repository for EDK2 development will switch from using
> > SourceForge to GitHub. The repository found at SourceForge will
> > continue to be a read-only mirror of the master branch on GitHub.
> > 
> > A number of reasons have prompted us to switch to git most notably
> > the communities request for us to make this change. Other reasons
> > include the ability to have better commit logs and the use of
> > branching to aid in reviewing larger changes and the addition of new
> > features.
> > 
> > As part of this change a number of process changes will be adopted to
> > support better use of git. This includes the method for sending out
> > patches for review and other minor changes. Information regarding
> > these changes will be found on http://tianocore.org  in the following
> > weeks. In addition to the process changes documentation for users new
> > to git will also be provided.
> > 
> > Please post any comments or questions related to this transition to
> > the Edk2-devel mailing list or reply to the email message
> > 
> > Thanks, Tianocore.org Administration
> 
> Great news!
> 
> I'd like to ask for confirmation in two points:
> 
> (1) that the git repo will remain a unified one (I think this has been
> made possible by the BaseTools support for external packages);

I can confirm that it will remain unified. In fact, I plan to delete
the separate package based repos on github soon.

> (2) that a purely email based setup will remain fully functional for
> participation (posting and reviewing), regardless of whether additional
> web based utilities will be developed.

I agree with this. I have also expressed that I would like email based
code reviewed to remain fully supported.

I think some people want to investigate gerrit at some point, and I
don't know how that would be implemented. I hope it would not mean
that patches will be posted in gerrit, and no notice will appear on
the email list.

I strongly doubt that gerrit will be set up at the initial git
cut-over point, so at least initially email patches will be the only
option.

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

Re: [edk2] [Patch 2/6] MdeModulePkg: Fix VS2015 warning C4459 in DriverSampleDxe

[Kinney, Michael D]

Liming,

Reviewed-by: Michael Kinney 

I have also verified that builds of the MdeModulePkg/Universal/DriverSampleDxe 
complete with VS2015 for IA32 and X64.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, December 2, 2015 9:27 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 2/6] MdeModulePkg: Fix VS2015 warning C4459 in 
> DriverSampleDxe
> 
> warning C4459: declaration of 'PrivateData' hides global declaration.
> Update DriverSampleDxe to rename global variable name to be different.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  .../Universal/DriverSampleDxe/DriverSample.c   | 72 
> +++---
>  1 file changed, 36 insertions(+), 36 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> index 2f77d39..8ec1d4e 100644
> --- a/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> +++ b/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c
> @@ -21,7 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  CHAR16 VariableName[] = L"MyIfrNVData";
>  CHAR16 MyEfiVar[] = L"MyEfiVar";
>  EFI_HANDLE  DriverHandle[2] = {NULL, NULL};
> -DRIVER_SAMPLE_PRIVATE_DATA  *PrivateData = NULL;
> +DRIVER_SAMPLE_PRIVATE_DATA  *mPrivateData = NULL;
>  EFI_EVENT   mEvent;
> 
>  HII_VENDOR_DEVICE_PATH  mHiiVendorDevicePath0 = {
> @@ -1895,17 +1895,17 @@ DriverSampleInit (
>//
>// Initialize driver private data
>//
> -  PrivateData = AllocateZeroPool (sizeof (DRIVER_SAMPLE_PRIVATE_DATA));
> -  if (PrivateData == NULL) {
> +  mPrivateData = AllocateZeroPool (sizeof (DRIVER_SAMPLE_PRIVATE_DATA));
> +  if (mPrivateData == NULL) {
>  return EFI_OUT_OF_RESOURCES;
>}
> 
> -  PrivateData->Signature = DRIVER_SAMPLE_PRIVATE_SIGNATURE;
> +  mPrivateData->Signature = DRIVER_SAMPLE_PRIVATE_SIGNATURE;
> 
> -  PrivateData->ConfigAccess.ExtractConfig = ExtractConfig;
> -  PrivateData->ConfigAccess.RouteConfig = RouteConfig;
> -  PrivateData->ConfigAccess.Callback = DriverCallback;
> -  PrivateData->PasswordState = BROWSER_STATE_VALIDATE_PASSWORD;
> +  mPrivateData->ConfigAccess.ExtractConfig = ExtractConfig;
> +  mPrivateData->ConfigAccess.RouteConfig = RouteConfig;
> +  mPrivateData->ConfigAccess.Callback = DriverCallback;
> +  mPrivateData->PasswordState = BROWSER_STATE_VALIDATE_PASSWORD;
> 
>//
>// Locate Hii Database protocol
> @@ -1914,7 +1914,7 @@ DriverSampleInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> -  PrivateData->HiiDatabase = HiiDatabase;
> +  mPrivateData->HiiDatabase = HiiDatabase;
> 
>//
>// Locate HiiString protocol
> @@ -1923,7 +1923,7 @@ DriverSampleInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> -  PrivateData->HiiString = HiiString;
> +  mPrivateData->HiiString = HiiString;
> 
>//
>// Locate Formbrowser2 protocol
> @@ -1932,7 +1932,7 @@ DriverSampleInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> -  PrivateData->FormBrowser2 = FormBrowser2;
> +  mPrivateData->FormBrowser2 = FormBrowser2;
> 
>//
>// Locate ConfigRouting protocol
> @@ -1941,7 +1941,7 @@ DriverSampleInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> -  PrivateData->HiiConfigRouting = HiiConfigRouting;
> +  mPrivateData->HiiConfigRouting = HiiConfigRouting;
> 
>//
>// Locate keyword handler protocol
> @@ -1950,19 +1950,19 @@ DriverSampleInit (
>if (EFI_ERROR (Status)) {
>  return Status;
>}
> -  PrivateData->HiiKeywordHandler = HiiKeywordHandler;
> +  mPrivateData->HiiKeywordHandler = HiiKeywordHandler;
> 
>Status = gBS->InstallMultipleProtocolInterfaces (
>[0],
>,
>,
>,
> -  >ConfigAccess,
> +  >ConfigAccess,
>NULL
>);
>ASSERT_EFI_ERROR (Status);
> 
> -  PrivateData->DriverHandle[0] = DriverHandle[0];
> +  mPrivateData->DriverHandle[0] = DriverHandle[0];
> 
>//
>// Publish our HII data
> @@ -1978,7 +1978,7 @@ DriverSampleInit (
>  return EFI_OUT_OF_RESOURCES;
>}
> 
> -  PrivateData->HiiHandle[0] = HiiHandle[0];
> +  mPrivateData->HiiHandle[0] = HiiHandle[0];
> 
>//
>// Publish another Fromset
> @@ -1988,12 +1988,12 @@ DriverSampleInit (
>,
>,
>,
> -  >ConfigAccess,
> +  >ConfigAccess,
>NULL
>);
>ASSERT_EFI_ERROR (Status);
> 
> -  PrivateData->DriverHandle[1] = DriverHandle[1];
> +  mPrivateData->DriverHandle[1] = DriverHandle[1];
> 
>HiiHandle[1] = HiiAddPackages (
> 

Re: [edk2] [Patch 6/6] OvmfPkg: Fix VS2015 warning C4459 in XenBusDxe

[Jordan Justen]

Reviewed-by: Jordan Justen 

On 2015-12-02 21:26:46, Liming Gao wrote:
> warning C4459: declaration of 'xs' hides global declaration.
> Update code to rename local variable xs to xsp to be different.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Cc: Justen Jordan 
> ---
>  OvmfPkg/XenBusDxe/XenStore.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
> index 9850f1e..61976f9 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.c
> +++ b/OvmfPkg/XenBusDxe/XenStore.c
> @@ -992,9 +992,9 @@ NotifyEventChannelCheckForEvent (
>IN VOID *Context
>)
>  {
> -  XENSTORE_PRIVATE *xs;
> -  xs = (XENSTORE_PRIVATE *)Context;
> -  if (TestAndClearBit (xs->EventChannel, 
> xs->Dev->SharedInfo->evtchn_pending)) {
> +  XENSTORE_PRIVATE *xsp;
> +  xsp = (XENSTORE_PRIVATE *)Context;
> +  if (TestAndClearBit (xsp->EventChannel, 
> xsp->Dev->SharedInfo->evtchn_pending)) {
>  gBS->SignalEvent (Event);
>}
>  }
> @@ -1007,12 +1007,12 @@ NotifyEventChannelCheckForEvent (
>  STATIC
>  EFI_STATUS
>  XenStoreInitComms (
> -  XENSTORE_PRIVATE *xs
> +  XENSTORE_PRIVATE *xsp
>)
>  {
>EFI_STATUS Status;
>EFI_EVENT TimerEvent;
> -  struct xenstore_domain_interface *XenStore = xs->XenStore;
> +  struct xenstore_domain_interface *XenStore = xsp->XenStore;
>  
>Status = gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, );
>Status = gBS->SetTimer (TimerEvent, TimerRelative,
> @@ -1029,8 +1029,8 @@ XenStoreInitComms (
>gBS->CloseEvent (TimerEvent);
>  
>Status = gBS->CreateEvent (EVT_NOTIFY_WAIT, TPL_NOTIFY,
> - NotifyEventChannelCheckForEvent, xs,
> - >EventChannelEvent);
> + NotifyEventChannelCheckForEvent, xsp,
> + >EventChannelEvent);
>ASSERT_EFI_ERROR (Status);
>  
>return Status;
> -- 
> 1.9.5.msysgit.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] Vlv2DeviceRefCodePkg/Vlv2TbltDevicePkg: Reset BIOS Setup when Jumper is present on Turbot.

[He, Tim]

Reviewed-by: Tim He  

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of lushifex
Sent: Thursday, December 03, 2015 6:15 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] Vlv2DeviceRefCodePkg/Vlv2TbltDevicePkg: Reset BIOS 
Setup when Jumper is present on Turbot.

Signed-off-by: lushifex 
---
 .../SouthCluster/Include/Library/PchPlatformLib.h  |   9 ++
 Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c  |  19 ++--
 .../MultiPlatformLib/BoardClkGens/BoardClkGens.c   |   6 +-
 .../MultiPlatformLib/BoardClkGens/BoardClkGens.h   |   2 +
 .../MultiPlatformLib/BoardGpios/BoardGpios.c   |  15 +++
 .../MultiPlatformLib/BoardGpios/BoardGpios.h   |   1 +
 .../Library/MultiPlatformLib/MultiPlatformLib.inf  |   1 +
 .../Library/PchPlatformLib/PchPlatformLibrary.c| 108 +
 .../Library/PlatformBdsLib/BdsPlatform.c   |  29 --
 .../Library/PlatformBdsLib/PlatformBdsLib.inf  |   1 +
 Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c|   8 +-
 Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf  |   1 +
 Vlv2TbltDevicePkg/PlatformDxe/ExI.c|   8 +-
 Vlv2TbltDevicePkg/PlatformDxe/Platform.c   |  51 +-
 .../PlatformGopPolicy/PlatformGopPolicy.c  |   9 +-
 .../PlatformGopPolicy/PlatformGopPolicy.inf|   3 +
 .../PlatformInfoDxe/PlatformInfoDxe.c  |   9 +-
 .../PlatformInfoDxe/PlatformInfoDxe.inf|   1 +
 Vlv2TbltDevicePkg/PlatformInitPei/BootMode.c   |   6 +-
 .../PlatformInitPei/PlatformEarlyInit.c|   7 +-
 Vlv2TbltDevicePkg/PlatformPei/BootMode.c   |  16 +++
 Vlv2TbltDevicePkg/PlatformPei/Platform.c   |   7 +-
 Vlv2TbltDevicePkg/PlatformPei/PlatformPei.inf  |   1 +
 .../PlatformSetupDxe/PlatformSetupDxe.inf  |   1 +
 .../PlatformSetupDxe/SetupInfoRecords.c|   7 +-
 Vlv2TbltDevicePkg/PlatformSmm/Platform.c   |  15 ++-
 26 files changed, 300 insertions(+), 41 deletions(-)

diff --git 
a/Vlv2DeviceRefCodePkg/ValleyView2Soc/SouthCluster/Include/Library/PchPlatformLib.h
 
b/Vlv2DeviceRefCodePkg/ValleyView2Soc/SouthCluster/Include/Library/PchPlatformLib.h
index 8f0ca02..9651f94 100644
--- 
a/Vlv2DeviceRefCodePkg/ValleyView2Soc/SouthCluster/Include/Library/PchPlatformLib.h
+++ b/Vlv2DeviceRefCodePkg/ValleyView2Soc/SouthCluster/Include/Library/P
+++ chPlatformLib.h
@@ -115,7 +115,16 @@ PchAlternateAccessMode (
 
   @retval NONE
 
 **/
 ;
+UINT32
+DetectTurbotBoard (
+VOID
+  );
+
+UINT32
+DetectGpioPinValue (
+VOID
+  );
 
 #endif
diff --git a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c 
b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
index 2ff14ec..a7e54e3 100644
--- a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
+++ b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
@@ -646,10 +646,11 @@ OnReadyToBoot (
   SYSTEM_CONFIGURATIONSetupVarBuffer;
   UINTN   VariableSize;
   EFI_PLATFORM_CPU_INFO   *PlatformCpuInfoPtr = NULL;
   EFI_PLATFORM_CPU_INFO   PlatformCpuInfo;
   EFI_PEI_HOB_POINTERS  GuidHob;
+  UINT32  DxeGpioValue;
 
   if (mFirstNotify) {
 return;
   }
 
@@ -684,10 +685,12 @@ OnReadyToBoot (
 
   if ((PlatformCpuInfoPtr != NULL)) {
 CopyMem(, PlatformCpuInfoPtr, 
sizeof(EFI_PLATFORM_CPU_INFO));
   }
 
+  DxeGpioValue = DetectGpioPinValue();
+
   //
   // Update the ACPI parameter blocks finally.
   //
   VariableSize = sizeof (SYSTEM_CONFIGURATION);
   Status = gRT->GetVariable (
@@ -695,12 +698,12 @@ OnReadyToBoot (
   ,
   NULL,
   ,
   
   );
-  if (EFI_ERROR (Status) || VariableSize != sizeof(SYSTEM_CONFIGURATION)) {
-//The setup variable is corrupted
+  if (EFI_ERROR (Status) || VariableSize != sizeof(SYSTEM_CONFIGURATION) || 
DxeGpioValue == 0) {
+//The setup variable is corrupted or detect GPIO_S5_17 Pin is low
 VariableSize = sizeof(SYSTEM_CONFIGURATION);
 Status = gRT->GetVariable(
   L"SetupRecovery",
   ,
   NULL,
@@ -794,10 +797,11 @@ AcpiPlatformEntryPoint (
   EFI_MP_SERVICES_PROTOCOL  *MpService;
   UINTN MaximumNumberOfCPUs;
   UINTN NumberOfEnabledCPUs;
   UINT32Data32;
   PCH_STEPPING  pchStepping;
+  UINT32DxeGpioValue;
 
   mFirstNotify  = FALSE;
 
   TableVersion  = EFI_ACPI_TABLE_VERSION_2_0;
   Instance  = 0;
@@ -813,11 +817,12 @@ AcpiPlatformEntryPoint (
   if (GuidHob.Raw != NULL) {
 if ((GuidHob.Raw = GetNextGuidHob (, GuidHob.Raw)) != 
NULL) {
   mPlatformInfo = GET_GUID_HOB_DATA (GuidHob.Guid);
 }
   }
-
+  
+  DxeGpioValue = DetectGpioPinValue();
   //
   // Search for the Memory Configuration GUID HOB.  If it is not present, then
   // there's nothing we can do. It may not exist on 

Re: [edk2] [PATCH v2 2/2] ArmVirtPkg: Add memory space for the memory nodes except the lowest one

[Shannon Zhao]

On 2015/12/3 21:25, Laszlo Ersek wrote:
> Shannon,
> 
> On 12/01/15 03:02, Shannon Zhao wrote:
>> > 
>> > On 2015/12/1 2:12, Laszlo Ersek wrote:
>>> >> Thank you -- this looks better. Unfortunately the
>>> >> SetMemorySpaceAttributes() question still has to be addressed, and we're
>>> >> still discussing with Ard which way to go about that. Once we have an
>>> >> agreement, I'll spell out the further requirements for this.
>>> >>
>>> >> The "do it all in PEI with HOBs" idea is out, now we're trying to decide
>>> >> if (a) we should do it in VirtFdtDxe, and update the APRIORI DXE block
>>> >> in the FDF file so that CpuDxe gets dispatched before VirtFdtDxe, or (b)
>>> >> if we should move this code to a separate DXE driver that depends on the
>>> >> CPU architectural protocol installed by CpuDxe. Whatever the agreement,
>>> >> this patch will need to be further updated.
>>> >>
>>> >> I ask for your patience with this -- it's messier than I would like. I
>>> >> hope your NUMA development can proceed even until we converge with the
>>> >> help of these WIP patches.
>>> >>
>> > It's fine since it doesn't block the NUMA patches. :)
>> > 
>>> >> I'll admit that my secret (well, not so secret :)) agenda with this
>>> >> series is to pull more people into edk2 development from the QEMU
>>> >> community. Albeit somewhat messy, this feature isn't very large or
>>> >> complex, so I find it appropriate to "train" you with it -- if you want
>>> >> to play along, that is. :)
>> > 
>> > Laszlo, I think this is very cool. I'm interested in this kind of
>> > "training". :)
>> > 
> Okay, so we seem to have reached an agreement with Ard in the other thread:
> 
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/5054/focus=5309
> 
> Here's what I suggest for v3:
> 
> * Patch 1 is good, you can include it without any changes (you have my R-b).
> 
> * Patch 2 should implement what you are doing now (with my comments in
> this thread addressed), but it should introduce that functionality as a
> separate, new driver.
> 
> Namely, as first step please recursively copy the directory
> "ArmVirtPkg/VirtFdtDxe" to "ArmVirtPkg/HighMemDxe". Please also replace
> all occurrences of the "VirtFdtDxe" string in source code and in file
> names within the copy.
> 
> Second, please generate a new FILE_GUID with the "uuidgen" utility for
> the new "ArmVirtPkg/HighMemDxe/HighMemDxe.inf" file.
> 
> Third, add the subject functionality to HighMemDxe. (Addressing my
> comments too.)
> 
> Fourth, remove everything else from HighMemDxe; so that its sole
> responsibility remains processing the higher-than-lowest /memory nodes
> in the DTB. This removal will make a number of libraries, PCDs, protcols
> etc superfluous, so please remove the relevant #include directives and
> [LibraryClasses] entries.
> 
> Fifth, in "ArmVirtPkg/HighMemDxe/HighMemDxe.inf", the TRUE expression
> under [DepEx] should be replaced with gEfiCpuArchProtocolGuid.
> 
> Sixth, the new driver's INF file should be referenced in
> "ArmVirtQemu.dsc" and "ArmVirtQemu.fdf". In the latter, it should *not*
> be added to APRIORI DXE.
> 
> In short, patch #2 should add a small new driver that does nothing but
> looks for memory nodes in the DTB, installs the ranges, and sets their
> actual caching attributes to WB (which depends on the CPU arch protocol
> internally).

Ok, will update this patch. :)

Thanks,
-- 
Shannon

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

Re: [edk2] Git transition for EDK2

[Bjorge, Erik C]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
> Justen
> Sent: Thursday, December 3, 2015 4:37 PM
> To: Laszlo Ersek ; Jarlstrom, Laurie 
> 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Git transition for EDK2
> 
> On 2015-12-03 15:41:22, Laszlo Ersek wrote:
> > On 12/03/15 21:05, Jarlstrom, Laurie wrote:
> > > To: EDK2 Community
> > >
> > > This message is to notify you that near the end of January 2016 the
> > > active repository for EDK2 development will switch from using
> > > SourceForge to GitHub. The repository found at SourceForge will
> > > continue to be a read-only mirror of the master branch on GitHub.
> > >
> > > A number of reasons have prompted us to switch to git most notably
> > > the communities request for us to make this change. Other reasons
> > > include the ability to have better commit logs and the use of
> > > branching to aid in reviewing larger changes and the addition of new
> > > features.
> > >
> > > As part of this change a number of process changes will be adopted to
> > > support better use of git. This includes the method for sending out
> > > patches for review and other minor changes. Information regarding
> > > these changes will be found on http://tianocore.org  in the following
> > > weeks. In addition to the process changes documentation for users new
> > > to git will also be provided.
> > >
> > > Please post any comments or questions related to this transition to
> > > the Edk2-devel mailing list or reply to the email message
> > >
> > > Thanks, Tianocore.org Administration
> >
> > Great news!
> >
> > I'd like to ask for confirmation in two points:
> >
> > (1) that the git repo will remain a unified one (I think this has been
> > made possible by the BaseTools support for external packages);
> 
> I can confirm that it will remain unified. In fact, I plan to delete
> the separate package based repos on github soon.
> 
> > (2) that a purely email based setup will remain fully functional for
> > participation (posting and reviewing), regardless of whether additional
> > web based utilities will be developed.
> 

The email review process will continue as is.  We may discuss the addition of 
other tools in the future if the community feels they would be valuable.

Thanks,
-Erik

> I agree with this. I have also expressed that I would like email based
> code reviewed to remain fully supported.
> 
> I think some people want to investigate gerrit at some point, and I
> don't know how that would be implemented. I hope it would not mean
> that patches will be posted in gerrit, and no notice will appear on
> the email list.
> 
> I strongly doubt that gerrit will be set up at the initial git
> cut-over point, so at least initially email patches will be the only
> option.
> 
> -Jordan
> ___
> 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] ShellPkg: Fix ifconfig hang issue with incomplete parameters

[Jiaxin Wu]

This patch is used to fix ifconfig hang issue with incomplete
parameters. In addition, some error related output information
is added to increase the interactivity.

Cc: Leekha Shaveta 
Cc: Carsey Jaben 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 .../UefiShellNetwork1CommandsLib/Ifconfig.c|  61 -
 .../UefiShellNetwork1CommandsLib.uni   | Bin 21094 -> 21256 bytes
 2 files changed, 47 insertions(+), 14 deletions(-)

diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c 
b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
index fb6f575..f8dbc88 100644
--- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
+++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
@@ -826,10 +826,11 @@ IfConfigClearInterfaceInfo (
 Ip4Config2DataTypePolicy,
 sizeof (EFI_IP4_CONFIG2_POLICY),
 
 );
 if (EFI_ERROR (Status)) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD), 
gShellNetwork1HiiHandle, L"ifconfig");
   ShellStatus = SHELL_ACCESS_DENIED;
   break;
 }
   }
 
@@ -902,10 +903,11 @@ IfConfigSetInterfaceInfo (
   NULL,
   NULL,
   
   );
   if (EFI_ERROR (Status)) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD), 
gShellNetwork1HiiHandle, L"ifconfig");
 ShellStatus = SHELL_ACCESS_DENIED;
 goto ON_EXIT;
   }
 
   Status = gBS->CreateEvent (
@@ -914,10 +916,11 @@ IfConfigSetInterfaceInfo (
   IfConfigManualAddressNotify,
   ,
   
   );
   if (EFI_ERROR (Status)) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD), 
gShellNetwork1HiiHandle, L"ifconfig");
 ShellStatus = SHELL_ACCESS_DENIED;
 goto ON_EXIT;
   }
 
   //
@@ -972,10 +975,11 @@ IfConfigSetInterfaceInfo (
 //
 if (StrCmp(VarArg->Arg, L"dhcp") == 0) {
   if (IfCb->Policy == Ip4Config2PolicyDhcp) {
 Status = IfConfigStartIp4 (IfCb->NicHandle, gImageHandle);
 if (EFI_ERROR(Status)) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD), 
gShellNetwork1HiiHandle, L"ifconfig");
   ShellStatus = SHELL_ACCESS_DENIED;
   goto ON_EXIT;
 }
   } else {
 //
@@ -987,74 +991,100 @@ IfConfigSetInterfaceInfo (
 Ip4Config2DataTypePolicy,
 sizeof (EFI_IP4_CONFIG2_POLICY),
 
 );
 if (EFI_ERROR(Status)) {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD), 
gShellNetwork1HiiHandle, L"ifconfig");
   ShellStatus = SHELL_ACCESS_DENIED;
   goto ON_EXIT;
 }
   }
   
   VarArg= VarArg->Next;
 
 } else if (StrCmp (VarArg->Arg, L"static") == 0) {
-  //
-  // Set manual config policy.
-  //
-  Policy = Ip4Config2PolicyStatic;
-  Status = IfCb->IfCfg->SetData (
-  IfCb->IfCfg,
-  Ip4Config2DataTypePolicy,
-  sizeof (EFI_IP4_CONFIG2_POLICY),
-  
-  );
-  if (EFI_ERROR(Status)) {
-ShellStatus = SHELL_ACCESS_DENIED;
+  VarArg= VarArg->Next;
+  if (VarArg == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_IFCONFIG_LACK_COMMAND), gShellNetwork1HiiHandle);
+ShellStatus = SHELL_INVALID_PARAMETER;
 goto ON_EXIT;
   }
 
-  VarArg= VarArg->Next;   
-
   ZeroMem (, sizeof (ManualAddress));
 
   //
   // Get manual IP address.
   //
   Status = NetLibStrToIp4 (VarArg->Arg, );
   if (EFI_ERROR(Status)) {
+ShellPrintHiiEx(-1, -1, NULL,STRING_TOKEN 
(STR_IFCONFIG_INVALID_IPADDRESS), gShellNetwork1HiiHandle, VarArg->Arg);
 ShellStatus = SHELL_INVALID_PARAMETER;
 goto ON_EXIT;
   }
 
   //
   // Get subnetmask.
   //
   VarArg = VarArg->Next;
+  if (VarArg == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_IFCONFIG_LACK_COMMAND), gShellNetwork1HiiHandle);
+ShellStatus = SHELL_INVALID_PARAMETER;
+goto ON_EXIT;
+  }
+  
   Status = NetLibStrToIp4 (VarArg->Arg, );
   if (EFI_ERROR(Status)) {
+ShellPrintHiiEx(-1, -1, NULL,STRING_TOKEN 
(STR_IFCONFIG_INVALID_IPADDRESS), gShellNetwork1HiiHandle, VarArg->Arg);
 ShellStatus = SHELL_INVALID_PARAMETER;
 goto ON_EXIT;
   }
 
   //
   // Get gateway.
   //
   VarArg = VarArg->Next;
+  if (VarArg == NULL) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 

Re: [edk2] Git transition for EDK2

[Bruce Cran]

On 12/3/15 5:37 PM, Jordan Justen wrote:


I think some people want to investigate gerrit at some point, and I
don't know how that would be implemented. I hope it would not mean
that patches will be posted in gerrit, and no notice will appear on
the email list.


I hope not too, since everyone I've talked to has said that Gerrit's UI 
is rather ugly :)


--
BRuce

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

Re: [edk2] [Patch] MdePkg: Add Ipmi2.0 definitions head file.

[Gao, Liming]

Daocheng:
  I try including this header file and compile them, and find the following 
issues. Pease fix them. 
1) IndustryStandard/IpmiNetFnSensorDefinitions.h can't be found
2) There are two IPMI_LAN_DEST_TYPE definitions in 
MdePkg\Include\IndustryStandard\IpmiNetFnTransportDefinitions.h.

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Daocheng 
Bu
Sent: Wednesday, December 02, 2015 4:01 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen
Subject: [edk2] [Patch] MdePkg: Add Ipmi2.0 definitions head file.

Add Ipmi2.0 definitions head file based on Ipmi category:
App, Storage and etc.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daocheng Bu 
CC: Jiewen Yao 
---
 MdePkg/Include/IndustryStandard/Ipmi.h |  29 +
 .../IndustryStandard/IpmiNetFnAppDefinitions.h | 647 +
 .../IndustryStandard/IpmiNetFnBridgeDefinitions.h  | 243 
 .../IndustryStandard/IpmiNetFnChassisDefinitions.h | 304 ++
 .../IpmiNetFnFirmwareDefinitions.h |  26 +
 .../IpmiNetFnGroupExtensionDefinitions.h   |  26 +
 .../IpmiNetFnSensorEventDefinitions.h  |  52 ++
 .../IndustryStandard/IpmiNetFnStorageDefinitions.h | 534 +
 .../IpmiNetFnTransportDefinitions.h| 556 ++
 9 files changed, 2417 insertions(+)
 create mode 100644 MdePkg/Include/IndustryStandard/Ipmi.h
 create mode 100644 MdePkg/Include/IndustryStandard/IpmiNetFnAppDefinitions.h
 create mode 100644 MdePkg/Include/IndustryStandard/IpmiNetFnBridgeDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnChassisDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnFirmwareDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnGroupExtensionDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnSensorEventDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnStorageDefinitions.h
 create mode 100644 
MdePkg/Include/IndustryStandard/IpmiNetFnTransportDefinitions.h

diff --git a/MdePkg/Include/IndustryStandard/Ipmi.h 
b/MdePkg/Include/IndustryStandard/Ipmi.h
new file mode 100644
index 000..04e6807
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Ipmi.h
@@ -0,0 +1,29 @@
+/** @file   
+  IPMI 2.0 definitions from the IPMI Specification Version 2.0, Revision 1.1.
+
+  See IPMI specification, Appendix G, Command Assignments
+  and Appendix H, Sub-function Assignments.
+
+  Copyright (c) 1999 - 2015, Intel Corporation. All rights reserved.
+  This program and the accompanying materials  
+  are licensed and made available under the terms and conditions of the BSD 
License 
+  which accompanies this distribution.  The full text of the license may be 
found at
+  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 _IPMIDEFINITIONS_H_
+#define _IPMIDEFINITIONS_H_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#endif
diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnAppDefinitions.h 
b/MdePkg/Include/IndustryStandard/IpmiNetFnAppDefinitions.h
new file mode 100644
index 000..3e31b10
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/IpmiNetFnAppDefinitions.h
@@ -0,0 +1,647 @@
+/** @file   
+  IPMI 2.0 definitions from the IPMI Specification Version 2.0, Revision 1.1.
+
+  This file contains all NetFn App commands, including:
+IPM Device "Global" Commands (Chapter 20)
+Firmware Firewall & Command Discovery Commands (Chapter 21)
+BMC Watchdog Timer Commands (Chapter 27)
+IPMI Messaging Support Commands (Chapter 22)
+RMCP+ Support and Payload Commands (Chapter 24)
+
+  See IPMI specification, Appendix G, Command Assignments
+  and Appendix H, Sub-function Assignments.
+
+  Copyright (c) 1999 - 2015, Intel Corporation. All rights reserved.
+  This program and the accompanying materials  
+  are licensed and made available under the terms and conditions of the BSD 
License 
+  which accompanies this distribution.  The full text of the license may be 
found at
+  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 _IPMINETFNAPPDEFINITIONS_H_
+#define _IPMINETFNAPPDEFINITIONS_H_
+
+#pragma pack(1)
+//
+// Net function definition for App command
+//
+#define IPMI_NETFN_APP  0x06
+
+//
+//  Below is