Re: [edk2] Vlv2TbltDevicePkg: Fix the UEFI version reported in the Minnowboard MAX information screen
Sure, we'll apply the patch to change the string. Thank you Bruce. Best Regards, Tim -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Bruce Cran Sent: Wednesday, July 29, 2015 12:31 PM To: Wei, David; He, Tim Cc: edk2-devel@lists.01.org Subject: [edk2] Vlv2TbltDevicePkg: Fix the UEFI version reported in the Minnowboard MAX information screen Hi Tim and David, Could you apply the patch at https://github.com/bcran/edk2/commit/dfd96af00bf874a31fb16119ae1671f9f22da17c which changes the UEFI version reported in HII from 2.3.1 to 2.40 please? The patch makes the following changes: #string STR_CORE_VERSION_VALUE #language en-US "UEFI 2.3.1" to #string STR_CORE_VERSION_VALUE #language en-US "UEFI 2.40" This will make it match the output of the 'ver' command in the UEFI Shell, which reports: UEFI Interactive Shell v2.1 EDK II UEFI v2.40 (EDK II, 0x0001) Thanks. Bruce ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Vlv2TbltDevicePkg: Exclude CapsuleX64 from IA32 build
Reviewed-by: Tim He
-Original Message-
From: Zeng, Star
Sent: Tuesday, July 28, 2015 6:08 PM
To: edk2-devel@lists.01.org
Cc: Wei, David; He, Tim
Subject: [PATCH] Vlv2TbltDevicePkg: Exclude CapsuleX64 from IA32 build
CapsuleX64 is for 64bits capsule data access in PEI phase, it is only needed
for X64 DXE build.
Cc: David Wei
Cc: Tim He
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
Vlv2TbltDevicePkg/PlatformPkg.fdf | 2 ++
Vlv2TbltDevicePkg/PlatformPkgGcc.fdf | 2 ++
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 9 -
3 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/Vlv2TbltDevicePkg/PlatformPkg.fdf
b/Vlv2TbltDevicePkg/PlatformPkg.fdf
index 80ce20d..03cabb9 100644
--- a/Vlv2TbltDevicePkg/PlatformPkg.fdf
+++ b/Vlv2TbltDevicePkg/PlatformPkg.fdf
@@ -359,8 +359,10 @@ [FV.FVRECOVERY]
!if $(CAPSULE_ENABLE) == TRUE
INF MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
+!if $(DXE_ARCHITECTURE) == "X64"
INF MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf
!endif
+!endif
!if $(MINNOW2_FSP_BUILD) == FALSE
!if $(PCIESC_ENABLE) == TRUE
diff --git a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
index f556853..9ec4ce5 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
+++ b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
@@ -317,8 +317,10 @@ [FV.FVRECOVERY]
!if $(CAPSULE_ENABLE) == TRUE
INF MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
+!if $(DXE_ARCHITECTURE) == "X64"
INF MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf
!endif
+!endif
!if $(MINNOW2_FSP_BUILD) == FALSE
!if $(PCIESC_ENABLE) == TRUE
diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index 39054cf..2fa7a36 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -1100,15 +1100,6 @@ [Components.IA32] !endif
}
-!if $(CAPSULE_ENABLE) == TRUE
- MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf {
-
-PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
-HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
- }
-!endif
-
MdeModulePkg/Universal/ReportStatusCodeRouter/Smm/ReportStatusCodeRouterSmm.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf{
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Vlv2TbltDevicePkg: Fix the UEFI version reported in the Minnowboard MAX information screen
Hi Tim and David, Could you apply the patch at https://github.com/bcran/edk2/commit/dfd96af00bf874a31fb16119ae1671f9f22da17c which changes the UEFI version reported in HII from 2.3.1 to 2.40 please? The patch makes the following changes: #string STR_CORE_VERSION_VALUE #language en-US "UEFI 2.3.1" to #string STR_CORE_VERSION_VALUE #language en-US "UEFI 2.40" This will make it match the output of the 'ver' command in the UEFI Shell, which reports: UEFI Interactive Shell v2.1 EDK II UEFI v2.40 (EDK II, 0x0001) Thanks. Bruce ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch 1/2] MdeModulePkg/Variable: Fix VS2015 warning about uninitialized local var.
Reviewed-by: Star Zeng
-Original Message-
From: Tian, Feng
Sent: Wednesday, July 29, 2015 11:26 AM
To: Zeng, Star; Ni, Ruiyu
Cc: edk2-devel@lists.01.org; Kinney, Michael D
Subject: [patch 1/2] MdeModulePkg/Variable: Fix VS2015 warning about
uninitialized local var.
This fix is used to solve VS2015 warning "local variable is not initialized
before use"
Cc: Star Zeng
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney
Reviewed-by: Feng Tian
---
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
index 3c99367..834d2ff 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -4103,6 +4103,7 @@ VariableCommonInitialize (
//
// Init non-volatile variable store.
//
+ NvFvHeader = NULL;
Status = InitNonVolatileVariableStore (&NvFvHeader);
if (EFI_ERROR (Status)) {
FreePool (mVariableModuleGlobal);
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [patch 2/2] MdeModulePkg/PciBus: Simplify an complex if statement to pass VS2015
The logic in an if statement in PciIo is too complex and hard to understand
and make VS2015 build failure. The fix simplifies the logic.
Cc: Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney
Reviewed-by: Feng Tian
---
MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
index 15d6443..4160632 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
@@ -1,7 +1,7 @@
/** @file
EFI PCI IO protocol functions implementation for PCI Bus module.
-Copyright (c) 2006 - 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
@@ -1568,15 +1568,10 @@ PciIoAttributes (
//
// Check VGA and VGA16, they can not be set at the same time
//
- if (((Attributes & EFI_PCI_IO_ATTRIBUTE_VGA_IO) != 0 &&
- (Attributes & EFI_PCI_IO_ATTRIBUTE_VGA_IO_16) != 0) ||
- ((Attributes & EFI_PCI_IO_ATTRIBUTE_VGA_IO) != 0 &&
- (Attributes & EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO_16) != 0) ||
- ((Attributes & EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO) != 0 &&
- (Attributes & EFI_PCI_IO_ATTRIBUTE_VGA_IO_16) != 0) ||
- ((Attributes & EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO) != 0 &&
- (Attributes & EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO_16) != 0) ) {
-return EFI_UNSUPPORTED;
+ if ((Attributes & (EFI_PCI_IO_ATTRIBUTE_VGA_IO |
EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO)) != 0) {
+if ((Attributes & (EFI_PCI_IO_ATTRIBUTE_VGA_IO_16 |
EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO_16)) != 0) {
+ return EFI_UNSUPPORTED;
+}
}
//
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [patch 0/2] Fix two VS2015 build warnings in MdeModulePkg
1) VS 2015 think a local variable is not initialized before use in Variable driver. 2) The logic in an if statement in PciIo is too complex for VS 2015. This is a regression in VS. However, the current logic is complex and hard to understand. The fix simplified the logic and have the identical behavior. Tian Feng (2): MdeModulePkg/Variable: Fix VS2015 warning about uninitialized local var. MdeModulePkg/PciBus: Simplify an complex if statement to pass VS2015 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c| 15 +-- MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 1 + 2 files changed, 6 insertions(+), 10 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/2] MdeModulePkg/Variable: Fix VS2015 warning about uninitialized local var.
This fix is used to solve VS2015 warning "local variable is not initialized
before use"
Cc: Star Zeng
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney
Reviewed-by: Feng Tian
---
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
index 3c99367..834d2ff 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -4103,6 +4103,7 @@ VariableCommonInitialize (
//
// Init non-volatile variable store.
//
+ NvFvHeader = NULL;
Status = InitNonVolatileVariableStore (&NvFvHeader);
if (EFI_ERROR (Status)) {
FreePool (mVariableModuleGlobal);
--
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 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block
That's my point. Thanks! Jeff -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Wednesday, July 29, 2015 3:52 AM To: Fan, Jeff; Paolo Bonzini; edk2-de...@ml01.01.org Cc: Chen Fan; Justen, Jordan L Subject: Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block On 07/28/15 09:56, Fan, Jeff wrote: > Yes. I think BootServiceData is ok. Okay. At the moment I think I agree with the idea that BootServicesData should be sufficient. If that's what you'd like to see, I'll evaluate it in more depth, and try to update the code accordingly, for v2. For some more background: *other* data saved by CpuS3DataDxe into AcpiNVS, and then copied into SMRAM by PiSmmCpuDxeSmm, *must* actually reside in AcpiNVS originally. The point is not data integrity (the runtime OS could easily tamper with that data between normal boot and S3 suspend) -- the point is to inform a well-behaved runtime OS to stay away from that memory range. Namely, at S3 resume, PiSmmCpuDxeSmm restores *other* sensitive data from SMRAM to the original AcpiNVS area *first*, and uses (for whatever purposes) the data from AcpiNVS *second*. So whatever the OS wrote there will be overwritten -- which is good for the integrity of the firmware, but a well-behaved OS should not be corrupted by this (ie. the temporary restoral of data during S3 resume should not overwrite data owned by the OS). Therefore those *other* areas are allocated as AcpiNVS during normal boot, and then the OS knows from the UEFI memmap to stay away. As discussed, this temporary restoral to AcpiNVS at S3 resume does *not* apply to the MTRR settings; those are programmed into the processors directly from SMRAM. Which is why the BootServicesData idea makes sense. (In the Quark distribution the AcpiNVS allocation for this specific data could be an oversight.) Thanks! Laszlo > If OVMF is built without SMRAM support, it's ovmf platform's > responsibility to get it and save it into ACPI NVS. > > Jeff > -Original Message- > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of > Paolo Bonzini > Sent: Tuesday, July 28, 2015 3:34 PM > To: Fan, Jeff; Laszlo Ersek; edk2-de...@ml01.01.org > Cc: Chen Fan; Justen, Jordan L > Subject: Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save > MTRR settings to AcpiNVS memory block > > > > On 28/07/2015 09:09, Fan, Jeff wrote: >> I did not receive the patch 42. I have only gotten 38,39,40,41. >> >> OK, If this mtrr setting stored in ACPI NVS is for CpuS3DataDxe to >> store into SMRAM, that's fine. >> >> Then, another question, what's requirement to save MTRR setting into >> ACPI NVS on this case? And need one PCD to switch on/off it? > > Do you mean it could be BootServicesData? I'll let Laszlo answer this. > > The PCD is there to skip this code if OVMF is built without SMRAM support. > > Paolo > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools/Trim: Fixed a bug that cannot trim long values
Yingke:
Could you help update build_rule.txt for *.asm and *.asm16 with trimlong
option?
Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yingke
Liu
Sent: Wednesday, July 29, 2015 9:06 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] BaseTools/Trim: Fixed a bug that cannot trim long values
The long value substitution must move to the front of HEX substitution.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu
---
BaseTools/Source/Python/Trim/Trim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/BaseTools/Source/Python/Trim/Trim.py
b/BaseTools/Source/Python/Trim/Trim.py
index 7df8364..8fefa1b 100644
--- a/BaseTools/Source/Python/Trim/Trim.py
+++ b/BaseTools/Source/Python/Trim/Trim.py
@@ -177,13 +177,13 @@ def TrimPreprocessedFile(Source, Target, ConvertHex,
TrimLong):
EdkLogger.verbose("Found original file content starting from line
%d"
% (LineIndexOfOriginalFile + 1))
+if TrimLong:
+Line = gLongNumberPattern.sub(r"\1", Line)
# convert HEX number format if indicated
if ConvertHex:
Line = gHexNumberPattern.sub(r"0\2h", Line)
else:
Line = gHexNumberPattern.sub(r"\1\2", Line)
-if TrimLong:
-Line = gLongNumberPattern.sub(r"\1", Line)
# convert Decimal number format
Line = gDecNumberPattern.sub(r"\1", Line)
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] IntelFrameworkPkg FrameworkUefiLib: Fix ASSERT in CatVSPrint
The second parameter 'DestMax' of StrCpyS() should be the number of
unicode characters, not the size in bytes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu
---
IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
index 2570ff4..f0dcf9f 100644
--- a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
+++ b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
@@ -763,7 +763,7 @@ CatVSPrint (
}
if (String != NULL) {
-StrCpyS(BufferToReturn, SizeRequired, String);
+StrCpyS(BufferToReturn, SizeRequired / sizeof(CHAR16), String);
}
UnicodeVSPrint(BufferToReturn + StrLen(BufferToReturn),
(CharactersRequired+1) * sizeof(CHAR16), FormatString, Marker);
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] MdePkg UefiLib: Fix ASSERT in CatVSPrint
The second parameter 'DestMax' of StrCpyS() should be the number of
unicode characters, not the size in bytes.
Also, code is modified to keep align with the one in
IntelFrameworkPkg\Library\FrameworkUefiLib\UefiLibPrint.c.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu
---
MdePkg/Library/UefiLib/UefiLibPrint.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/MdePkg/Library/UefiLib/UefiLibPrint.c
b/MdePkg/Library/UefiLib/UefiLibPrint.c
index 91ce492..9f52e7d 100644
--- a/MdePkg/Library/UefiLib/UefiLibPrint.c
+++ b/MdePkg/Library/UefiLib/UefiLibPrint.c
@@ -754,14 +754,16 @@ CatVSPrint (
SizeRequired = sizeof(CHAR16) + (CharactersRequired * sizeof(CHAR16));
}
- BufferToReturn = AllocateZeroPool(SizeRequired);
+ BufferToReturn = AllocatePool(SizeRequired);
if (BufferToReturn == NULL) {
return NULL;
+ } else {
+BufferToReturn[0] = L'\0';
}
-
+
if (String != NULL) {
-StrCpyS(BufferToReturn, SizeRequired, String);
+StrCpyS(BufferToReturn, SizeRequired / sizeof(CHAR16), String);
}
UnicodeVSPrint(BufferToReturn + StrLen(BufferToReturn),
(CharactersRequired+1) * sizeof(CHAR16), FormatString, Marker);
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] BaseTools/Trim: Fixed a bug that cannot trim long values
The long value substitution must move to the front of
HEX substitution.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu
---
BaseTools/Source/Python/Trim/Trim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/BaseTools/Source/Python/Trim/Trim.py
b/BaseTools/Source/Python/Trim/Trim.py
index 7df8364..8fefa1b 100644
--- a/BaseTools/Source/Python/Trim/Trim.py
+++ b/BaseTools/Source/Python/Trim/Trim.py
@@ -177,13 +177,13 @@ def TrimPreprocessedFile(Source, Target, ConvertHex,
TrimLong):
EdkLogger.verbose("Found original file content starting from line
%d"
% (LineIndexOfOriginalFile + 1))
+if TrimLong:
+Line = gLongNumberPattern.sub(r"\1", Line)
# convert HEX number format if indicated
if ConvertHex:
Line = gHexNumberPattern.sub(r"0\2h", Line)
else:
Line = gHexNumberPattern.sub(r"\1\2", Line)
-if TrimLong:
-Line = gLongNumberPattern.sub(r"\1", Line)
# convert Decimal number format
Line = gDecNumberPattern.sub(r"\1", Line)
--
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] MdeModulePkg: Fix the issue cannot boot to UEFI Network
Reviewed-by: Jiaxin Wu
-Original Message-
From: Zhang, Lubo
Sent: Tuesday, July 28, 2015 4:47 PM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan; Ye, Ting; Wu, Jiaxin
Subject: [patch] MdeModulePkg: Fix the issue cannot boot to UEFI Network
DHCP4 service allows only one of its children to be configured in the active
state,If the DHCP4 D.O.R.A started by IP4 auto configuration and has not been
completed, the Dhcp4 state machine will not be in the right state for the PXE
to start a new round D.O.R.A.
so we need to switch it's policy to static.
Cc: Fu Siyuan
Cc: Ye Ting
CC: Wu Jiaxin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
.../Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c | 47 ++
.../Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h | 13 ++
.../Universal/Network/UefiPxeBcDxe/PxeBcDriver.c | 11 +
.../Universal/Network/UefiPxeBcDxe/PxeBcImpl.c | 11 +
.../Universal/Network/UefiPxeBcDxe/PxeBcImpl.h | 2 +
.../Network/UefiPxeBcDxe/UefiPxeBcDxe.inf | 1 +
6 files changed, 85 insertions(+)
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
index 1293f67..85155b1 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
@@ -645,10 +645,57 @@ PxeBcCacheDhcpOffer (
// Count the accepted offers.
//
Private->NumOffers++;
}
+/**
+ Switch the Ip4 policy to static.
+
+ @param[in] Private The pointer to PXEBC_PRIVATE_DATA.
+
+ @retval EFI_SUCCESS The policy is already configured to static.
+ @retval Others Other error as indicated..
+
+**/
+EFI_STATUS
+PxeBcSetIp4Policy (
+ IN PXEBC_PRIVATE_DATA*Private
+ )
+{
+ EFI_STATUS Status;
+ EFI_IP4_CONFIG2_PROTOCOL *Ip4Config2;
+ EFI_IP4_CONFIG2_POLICY Policy;
+ UINTNDataSize;
+
+ Ip4Config2 = Private->Ip4Config2;
+ DataSize = sizeof (EFI_IP4_CONFIG2_POLICY); Status =
+ Ip4Config2->GetData (
+ Ip4Config2,
+ Ip4Config2DataTypePolicy,
+ &DataSize,
+ &Policy
+ );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ if (Policy != Ip4Config2PolicyStatic) {
+Policy = Ip4Config2PolicyStatic;
+Status= Ip4Config2->SetData (
+ Ip4Config2,
+ Ip4Config2DataTypePolicy,
+ sizeof (EFI_IP4_CONFIG2_POLICY),
+ &Policy
+ );
+if (EFI_ERROR (Status)) {
+ return Status;
+}
+ }
+
+ return EFI_SUCCESS;
+}
+
/**
Select the specified proxy offer, such as BINL, DHCP_ONLY and so on.
If the proxy does not exist, try offers with bootfile.
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
index b56d10d..32a64df 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
@@ -378,10 +378,23 @@ PxeBcDhcpCallBack (
IN EFI_DHCP4_EVENT Dhcp4Event,
IN EFI_DHCP4_PACKET * Packet OPTIONAL,
OUT EFI_DHCP4_PACKET **NewPacket OPTIONAL
);
+/**
+ Switch the Ip4 policy to static.
+
+ @param[in] Private The pointer to PXEBC_PRIVATE_DATA.
+
+ @retval EFI_SUCCESS The policy is already configured to static.
+ @retval Others Other error as indicated..
+
+**/
+EFI_STATUS
+PxeBcSetIp4Policy (
+ IN PXEBC_PRIVATE_DATA*Private
+ );
/**
Discover the boot of service and initialize the vendor option if exists.
@param Private Pointer to PxeBc private data.
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
index 3c2437e..1b7577a 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
@@ -373,10 +373,21 @@ PxeBcDriverBindingStart (
NULL
);
if (EFI_ERROR (Status)) {
goto ON_ERROR;
}
+ //
+ // Locate Ip4->Ip4Config2 and store it for set IPv4 Policy.
+ //
+ Status = gBS->HandleProtocol (
+ ControllerHandle,
+ &gEfiIp4Config2ProtocolGuid,
+ (VOID **) &Private->Ip4Config2
+ );
+ if (EFI_ERROR (Status)) {
+goto ON_ERROR;
+ }
return EFI_SUCCESS;
ON_ERROR:
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
index 0c54f46..991a7be 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
+++ b/MdeModulePkg/Universa
Re: [edk2] [patch] NetworkPkg: Fix the issue cannot boot to UEFI Network
Reviewed-by: Jiaxin Wu
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wu,
Jiaxin
Sent: Tuesday, July 28, 2015 8:59 AM
To: Zhang, Lubo; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan
Subject: Re: [edk2] [patch] NetworkPkg: Fix the issue cannot boot to UEFI
Network
This patch only fixed the PXE driver in NetworkPkg, please double check the PXE
driver in MdeModulePkg whether has the same issue. If so, another patch is also
required.
Thanks.
Jiaxin
-Original Message-
From: Zhang, Lubo
Sent: Monday, July 27, 2015 4:52 PM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan; Ye, Ting; Wu, Jiaxin
Subject: [patch] NetworkPkg: Fix the issue cannot boot to UEFI Network
If the DHCP4 DORA process has not been completed by IP4 Driver, then the Dhcp4
state machine will not be the right state for the PXE to start D.O.R.A. process
successfully.
Cc: Fu Siyuan
Cc: Ye Ting
CC: Wu Jiaxin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c | 46
NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.h | 16 ++-
NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c| 12 +
NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c | 10 +++
NetworkPkg/UefiPxeBcDxe/PxeBcImpl.h | 2 ++
NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf | 1 +
6 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c
b/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c
index c027770..587566d 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c
@@ -1504,10 +1504,56 @@ PxeBcDhcp4Discover (
FreePool (Token.Packet);
return Status;
}
+/**
+ Switch the Ip4 policy to static.
+
+ @param[in] Private The pointer to PXEBC_PRIVATE_DATA.
+
+ @retval EFI_SUCCESS The policy is already configured to static.
+ @retval Others Other error as indicated..
+
+**/
+EFI_STATUS
+PxeBcSetIp4Policy (
+ IN PXEBC_PRIVATE_DATA*Private
+ )
+{
+ EFI_STATUS Status;
+ EFI_IP4_CONFIG2_PROTOCOL *Ip4Config2;
+ EFI_IP4_CONFIG2_POLICY Policy;
+ UINTNDataSize;
+
+ Ip4Config2 = Private->Ip4Config2;
+ DataSize = sizeof (EFI_IP4_CONFIG2_POLICY); Status =
+ Ip4Config2->GetData (
+ Ip4Config2,
+ Ip4Config2DataTypePolicy,
+ &DataSize,
+ &Policy
+ );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ if (Policy != Ip4Config2PolicyStatic) {
+Policy = Ip4Config2PolicyStatic;
+Status= Ip4Config2->SetData (
+ Ip4Config2,
+ Ip4Config2DataTypePolicy,
+ sizeof (EFI_IP4_CONFIG2_POLICY),
+ &Policy
+ );
+if (EFI_ERROR (Status)) {
+ return Status;
+}
+ }
+
+ return EFI_SUCCESS;
+}
/**
Start the D.O.R.A DHCPv4 process to acquire the IPv4 address and other PXE
boot information.
@param[in] Private Pointer to PxeBc private data.
diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.h
b/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.h
index 8e4e101..248dc60 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.h
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.h
@@ -1,9 +1,9 @@
/** @file
Functions declaration related with DHCPv4 for UefiPxeBc Driver.
- Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+ Copyright (c) 2009 - 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.
@@ -372,10 +372,24 @@ PxeBcDhcp4Discover (
IN EFI_IP_ADDRESS *DestIp,
IN UINT16 IpCount,
IN EFI_PXE_BASE_CODE_SRVLIST *SrvList
);
+/**
+ Switch the Ip4 policy to static.
+
+ @param[in] Private The pointer to PXEBC_PRIVATE_DATA.
+
+ @retval EFI_SUCCESS The policy is already configured to static.
+ @retval Others Other error as indicated..
+
+**/
+EFI_STATUS
+PxeBcSetIp4Policy (
+ IN PXEBC_PRIVATE_DATA*Private
+ );
+
/**
Start the D.O.R.A DHCPv4 process to acquire the IPv4 address and other PXE
boot information.
@param[in] Private Pointer to PxeBc private data.
diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c
b/NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c
index c2987b8..a6f6668 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c
@@ -740,10 +740,22 @@ PxeBcCreateIp4Children (
}
Private->Ip4Nic->Private = Private;
Private->Ip4Nic->Signature = PXEBC_VIRTUAL_N
Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block
HI Laszlo I like the diagram in GMANE. Good work! Will you consider the option to merge CpuS3DataDxe into CpuMpDxe? Then we can reduce the driver number. Or can we put CpuS3DataDxe to UefiCpuPkg? Same question for PiSmmCpuDxeSmm. Can we put it to UefiCpuPkg, if it is generic enough? I also found you say: that "ClearSmi() is a no-op on Q35." I am curious on why. Do you mean Q35 does not require EOS bit set??? Or my misunderstanding? Thank you Yao Jiewen -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek Sent: Wednesday, July 29, 2015 3:31 AM To: Paolo Bonzini; Fan, Jeff; edk2-de...@ml01.01.org Cc: Chen Fan; Justen, Jordan L Subject: Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block On 07/28/15 08:51, Paolo Bonzini wrote: > > > On 28/07/2015 08:05, Fan, Jeff wrote: >> Ersek, >> >> I have one comment for PCD PcdCpuSyncMtrrToAcpiNvs. >> >> I knew OvmfPkg implemented LockBox based on ACPI NVS. Saving MTRR setting in >> AcpiNVS is OK for OvmfPkg. > > If I understand correctly what you are saying, the AcpiNVS block is > only used for communication from CpuDxe to CpuS3DataDxe in patch 42. > CpuS3DataDxe saves the MTRR in SMRAM during > SmmReadyToLockEventNotify() and PiSmmCpuDxeSmm restores them during S3 > resume. So Laszlo's patches are doing exactly the "safe" thing, even though > they are not using LockBox. Yes, with minimal tweaks, this is correct. The minimal tweak is the following: while CpuS3DataDxe collects most *other* data for PiSmmCpuDxeSmm indeed as a "deep copy", right when it is notified about the installation of EFI_SMM_CONFIGURATION_PROTOCOL, the saving of MTRR configuration is delayed, and for that CpuS3DataDxe only saves the address of the AcpiNVS block -- that CpuDxe maintains -- for PiSmmCpuDxeSmm. This way other firmware code can continue massaging the MTRR settings. Normally this happens via EFI_DXE_SERVICES.SetMemorySpaceAttributes EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() call chains, ie. platform-independent firmware code decides "this memory range should be uncached", calls gDS->SetMemorySpaceAttributes(), which is ultimately implemented by the CpuDxe driver, in the form of massaging MTRR. Now, whenever this happens, the MTRR settings block in AcpiNVS will be updated by CpuDxe. When SMM-ready-to-lock is finally installed, then PiSmmCpuDxeSmm will copy the then-fresh MTRR settings to SMRAM. This is the reason for the extra indirection here -- in one sentence, most of the data can be saved by CpuS3DataDxe immediately when EFI_SMM_CONFIGURATION_PROTOCOL is installed, but the MTRR settings can validly change after that, so their saving is delayed until SMM-ready-to-lock. > >> But other platform may want to use more safe solution to save MTRR based on >> in SMM. >> >> I think that, for long term, saving MTRR setting by LockBox instead >> of using ACPI NVS memory directly. Then, different platforms could >> provide the different LockBox solutions. For short term, still saving >> MTRR setting in ACPI NVS in CpuDxe, and removing this PCD. That means >> we could CpuDxe implementation to use the long term solution in the >> future and needn't to remove one un-used PCD more. > > The PCD is consumed in CPUS3DataDxe. Correct. The dynamic PCD carries the address of the AcpiNVS block (containing the ever-fresh MTRR settings) from CpuDxe to CpuS3DataDxe, which CpuS3DataDxe then just passes on to PiSmmCpuDxeSmm, in the ACPI_CPU_DATA.MtrrTable field. Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/6] ArmPkg/ArmVirtPkg: GIC revision detection
On 28 July 2015 at 19:34, Leif Lindholm wrote: > Hi Ard, > > Sorry for delay. > > On Sun, Jul 26, 2015 at 02:50:24PM +0200, Ard Biesheuvel wrote: >> On 26 July 2015 at 13:46, Leif Lindholm wrote: >> > On Sun, Jul 26, 2015 at 01:08:20PM +0200, Ard Biesheuvel wrote: >> >> > So ... had a look through, looks sane, have a couple of minor comments >> >> > (will add inline). >> >> > But what I don't have at home is a useful hardware platform to test >> >> > this on. Has anyone else tested on 32-bit/64-bit hardware? >> >> >> >> Only under KVM, which is not very useful to you. >> > >> > Not sufficiently. >> > >> >> I tried it under FVP (after spotting and fixing a kernel bug, see >> separate email) and it works fine. >> >> >> I was kind of hoping you could push it through the CI Olivier always >> >> talked about. Or was that his personal setup? >> > >> > For all intents and purposes. >> > >> >> Do note that, even if they are non-trivial patches, the only actual >> >> change to non-virt platforms is that, for non-SEC modules, the result >> >> of the GIC detection is cached in a global. >> > >> > Sure. I'm just being paranoid. >> > >> > Well, I'll have a look tomorrow, while looking around for any hw >> > people might not miss... >> >> If you do mind the ArmGicArchSecLib clone and subsequent change of >> ArmGicArchLib, we could drop that, since the other patches still allow >> the virt platforms to use the GIC revision specified in the device >> tree (which is the primary motivation for this series) > > No issue with those. > > I've now tested on Juno r1 and TC2. So for where you need it: > Reviewed-by: Leif Lindholm > Tested-by: Leif Lindholm Thanks! Committed as SVN r18097 ... r18102 -- Ard. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/7] BaseTools: add unified GCC linker script for all archs and versions
On 2015-07-28 12:37:31, Ard Biesheuvel wrote:
> On 28 July 2015 at 20:48, Jordan Justen wrote:
> > On 2015-07-24 05:08:34, Ard Biesheuvel wrote:
> >> This unifies all GCC linker scripts into a single parametrised GCC
> >> linker script that can be used for all GCC versions and architectures.
> >>
> >> The two parameters that can be set on the linker command line are:
> >> - PECOFF_HEADER_SIZE, this is a build time property of GenFw, but
> >> its value is different between 32-bit and 64-bit;
> >> - common-page-size, this can be set using -z on the ld command line,
> >> and controls the value of the COMMONPAGESIZE constant when used in
> >> a linker script. This value is used for the minimum section alignment.
> >>
> >> Notable differences between the original versions:
> >> - .rodata has been moved into .text where it belongs;
> >> - the =90909090 NOP padding has been removed, since the only purpose it
> >> serves is making it easier for hackers to launch exploits, whereas
> >> correct code does not rely on these NOPs at all;
> >> - the .got contents have been moved into .text, but since we do not use
> >> PIC code, this input section should always be empty anyway.
> >
> > These all sound reasonable, but wouldn't it be better to start with
> > the current script and make each of these changes one at a time?
> >
>
> Perhaps, yes. But since this is a unification, some of these (the top
> two) are already present in gcc-aarch64-ld-script, on which this is
> mostly based.
Maybe first add each change to the linker scripts while they are
separate files, and in the end when they are all the same, you can
merge them into one script.
This might give us a chance to bisect, and it should help highlight
the various changes.
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Ard Biesheuvel
> >> ---
> >> BaseTools/Scripts/GCC/gcc-base.lds | 62
I don't think we need the GCC directory. Ugh. Now I'm forced to
suggest that maybe it should be GccBase.lds, even though I didn't
follow the file naming convention with gcc4.4-ld-script. :)
> >> 1 file changed, 62 insertions(+)
> >>
> >> diff --git a/BaseTools/Scripts/GCC/gcc-base.lds
> >> b/BaseTools/Scripts/GCC/gcc-base.lds
> >> new file mode 100644
> >> index ..e6109377ed38
> >> --- /dev/null
> >> +++ b/BaseTools/Scripts/GCC/gcc-base.lds
> >> @@ -0,0 +1,62 @@
> >> +/** @file
> >> +
> >> + Unified linker script for GCC based builds
> >> +
> >> + Copyright (c) 2015, Linaro Ltd. All rights reserved.
> >
> > Is this file based on BaseTools/Scripts/gcc4.9-ld-script?
> >
> > If so, could you add this?
> >
> > Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
> >
> > Or, if it is based on BaseTools/Scripts/gcc-4K-align-ld-script:
> >
> > Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
> >
>
> Since it is mostly a merge of all the different files, I will add the
> latter and retain the Linaro one, if that is ok with you.
Ok. Sounds good.
-Jordan
> >> +
> >> + This program and the accompanying materials are licensed and made
> >> available under
> >> + the terms and conditions of the BSD License that accompanies this
> >> distribution.
> >> + The full text of the license may be found at
> >> + http://opensource.org/licenses/bsd-license.php.
> >> +
> >> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> >> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> >> IMPLIED.
> >> +
> >> +**/
> >> +
> >> +SECTIONS {
> >> +
> >> + /*
> >> + * The PE/COFF binary consists of DOS and PE/COFF headers, and a
> >> sequence of
> >> + * section headers adding up to PECOFF_HEADER_SIZE bytes (which differs
> >> + * between 32-bit and 64-bit builds). The actual start of the .text
> >> section
> >> + * will be rounded up based on its actual alignment.
> >> + */
> >> + . = PECOFF_HEADER_SIZE;
> >> +
> >> + .text : ALIGN(CONSTANT(COMMONPAGESIZE)) {
> >> +*(.text .text.* .stub .gnu.linkonce.t.*)
> >> +*(.rodata .rodata.* .gnu.linkonce.r.*)
> >> +*(.got .got.*)
> >> + }
> >> +
> >> + /*
> >> + * The alignment of the .data section should be less than or equal to
> >> the
> >> + * alignment of the .text section. This ensures that the relative offset
> >> + * between these sections is the same in the ELF and the PE/COFF
> >> versions of
> >> + * this binary.
> >> + */
> >> + .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) {
> >> +*(.data .data.* .gnu.linkonce.d.*)
> >> +*(.bss .bss.* *COM*)
> >> + }
> >> +
> >> + .eh_frame ALIGN(CONSTANT(COMMONPAGESIZE)) : {
> >> +KEEP (*(.eh_frame))
> >> + }
> >> +
> >> + .rela ALIGN(CONSTANT(COMMONPAGESIZE)) : {
> >> +*(.rela .rela.*)
> >> + }
> >> +
> >> + /DISCARD/ : {
> >> +*(.note.GNU-stack)
> >> +*(.gnu_debuglink)
> >> +*(.interp)
> >> +*(.dynsym)
> >> +*(.dynstr)
> >> +*(.dynamic)
> >> +*(.ha
Re: [edk2] How could I allocate aligned memory?
On 07/28/15 07:14, winddy wrote: > Dear Experts, > Now I want to allocate some reserved memory which should be aligned > at 64MB. And if I use gBS->AllocatePages() it return OK(AllocateSize > = NeedSize + AlignSize, then use ALIGN_VALUE()). But I think in this > method I will waste much space for alignment. So I try to use > gDS->AllocateMemorySpace() which has a parameter "Alignment". But it > always return EFI_NOT_FOUND(GcdMemoryType = EfiGcdMemoryTypeReserved > or GcdMemoryType = EfiGcdMemoryTypeSystemMemory). > Does this API support allocate reserved memory? Anything should be > prepared before? The "memory *space* map" is a separate concept from the UEFI memory map. (Note the difference just in the code: gDS vs. gBS.) One is described in the platform init specs, the other is defined in the UEFI spec. The splitting headache I've been having for the past few hours prevents me from going into details (hopefully Andrew will inform you, and that's going to be better than what I could come up with anyway :)), but in short: - use gBS->AllocatePages() - find the alignment that you need - use gBS->FreePages() to free the *portion* of the initial allocation that you *don't* need, due to the alignment requirements. This might sound strange, but it is allowed by the UEFI spec, and supported by (and used in) edk2. The big "tell" that gives it away is that the gBS->FreePages() service takes the number of the pages the caller wants to free. If gBS->FreePages() was allowed to release earlier page allocations *only in full*, then it would only take a base address, and no number-of-pages parameter. (Contrast gBS->FreePool().) The other "tell" is that gBS->FreePages() can return EFI_NOT_FOUND. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block
On 07/28/15 09:56, Fan, Jeff wrote: > Yes. I think BootServiceData is ok. Okay. At the moment I think I agree with the idea that BootServicesData should be sufficient. If that's what you'd like to see, I'll evaluate it in more depth, and try to update the code accordingly, for v2. For some more background: *other* data saved by CpuS3DataDxe into AcpiNVS, and then copied into SMRAM by PiSmmCpuDxeSmm, *must* actually reside in AcpiNVS originally. The point is not data integrity (the runtime OS could easily tamper with that data between normal boot and S3 suspend) -- the point is to inform a well-behaved runtime OS to stay away from that memory range. Namely, at S3 resume, PiSmmCpuDxeSmm restores *other* sensitive data from SMRAM to the original AcpiNVS area *first*, and uses (for whatever purposes) the data from AcpiNVS *second*. So whatever the OS wrote there will be overwritten -- which is good for the integrity of the firmware, but a well-behaved OS should not be corrupted by this (ie. the temporary restoral of data during S3 resume should not overwrite data owned by the OS). Therefore those *other* areas are allocated as AcpiNVS during normal boot, and then the OS knows from the UEFI memmap to stay away. As discussed, this temporary restoral to AcpiNVS at S3 resume does *not* apply to the MTRR settings; those are programmed into the processors directly from SMRAM. Which is why the BootServicesData idea makes sense. (In the Quark distribution the AcpiNVS allocation for this specific data could be an oversight.) Thanks! Laszlo > If OVMF is built without SMRAM support, it's ovmf platform's > responsibility to get it and save it into ACPI NVS. > > Jeff > -Original Message- > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > Sent: Tuesday, July 28, 2015 3:34 PM > To: Fan, Jeff; Laszlo Ersek; edk2-de...@ml01.01.org > Cc: Chen Fan; Justen, Jordan L > Subject: Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR > settings to AcpiNVS memory block > > > > On 28/07/2015 09:09, Fan, Jeff wrote: >> I did not receive the patch 42. I have only gotten 38,39,40,41. >> >> OK, If this mtrr setting stored in ACPI NVS is for CpuS3DataDxe to >> store into SMRAM, that's fine. >> >> Then, another question, what's requirement to save MTRR setting into >> ACPI NVS on this case? And need one PCD to switch on/off it? > > Do you mean it could be BootServicesData? I'll let Laszlo answer this. > > The PCD is there to skip this code if OVMF is built without SMRAM support. > > Paolo > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block
On 07/28/15 09:33, Paolo Bonzini wrote: > > > On 28/07/2015 09:09, Fan, Jeff wrote: >> I did not receive the patch 42. I have only gotten 38,39,40,41. >> >> OK, If this mtrr setting stored in ACPI NVS is for CpuS3DataDxe to >> store into SMRAM, that's fine. >> >> Then, another question, what's requirement to save MTRR setting into >> ACPI NVS on this case? And need one PCD to switch on/off it? > > Do you mean it could be BootServicesData? I'll let Laszlo answer this. That is a good point, yes. I *think* it could be BootServicesData. However, the Quark distribution's equivalent CPU driver code uses AcpiNVS for this purpose, and I wanted the port to be as close as possible to the original (so that reviewers would face the least possible differences). > The PCD is there to skip this code if OVMF is built without SMRAM support. Yes, and for all other client platforms that include UefiCpuPkg/CpuDxe but do not include any SMM-related stuff. They would not consume the data allocated and maintained by UefiCpuPkg/CpuDxe. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 7/7] BaseTools/X86|IA32: move to unified GCC linker script
On 28 July 2015 at 20:51, Jordan Justen wrote:
> On 2015-07-24 05:08:40, Ard Biesheuvel wrote:
>> Drop the GCC 4.4/X86 and 4.9/X86 specific linker scripts and use
>> the new unified one instead.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel
>> ---
>> BaseTools/Conf/tools_def.template| 6 ++-
>> BaseTools/Scripts/gcc-4K-align-ld-script | 44
>> BaseTools/Scripts/gcc4.4-ld-script | 44
>> BaseTools/Scripts/gcc4.9-ld-script | 44
>> 4 files changed, 4 insertions(+), 134 deletions(-)
>>
>> diff --git a/BaseTools/Conf/tools_def.template
>> b/BaseTools/Conf/tools_def.template
>> index b29912c18e5b..84f1fda37661 100644
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -3813,6 +3813,8 @@ 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 =
>>
>> +*_*_IA32_DLINK2_FLAGS = --defsym=PECOFF_HEADER_SIZE=0x220
>> --script=$(EDK_TOOLS_PATH)/Scripts/GCC/gcc-base.lds
>> +*_*_X64_DLINK2_FLAGS = --defsym=PECOFF_HEADER_SIZE=0x228
>> --script=$(EDK_TOOLS_PATH)/Scripts/GCC/gcc-base.lds
>> *_*_AARCH64_DLINK2_FLAGS = --defsym=PECOFF_HEADER_SIZE=0x228
>> --script=$(EDK_TOOLS_PATH)/Scripts/GCC/gcc-base.lds
>>
>> DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar
>> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h
>> @@ -3848,7 +3850,7 @@ DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O
>> elf64-littleaarch64 -B aarch64
>> DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar
>> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections
>> -fdata-sections -c -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
>> DEFINE GCC44_IA32_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -m32
>> -malign-double -fno-stack-protector -D EFI32
>> DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64
>> -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))"
>> -DNO_BUILTIN_VA_FUNCS -mno-red-zone -Wno-address -mcmodel=large
>> -DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections
>> --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.4-ld-script
>> +DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections -z
>> common-page-size=0x20
>
> Any idea how old -z common-page-size is?
>
It was added to binutils 2.17 in 2006
--
Ard.
>> DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON)
>> --entry ReferenceAcpiTable -u ReferenceAcpiTable
>> DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON)
>> --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map
>> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>> DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS)
>> -melf_x86_64 --oformat=elf64-x86-64
>> @@ -3908,7 +3910,7 @@ DEFINE GCC48_AARCH64_ASLDLINK_FLAGS =
>> DEF(GCC47_AARCH64_ASLDLINK_FLAGS)
>>
>> DEFINE GCC49_IA32_CC_FLAGS = DEF(GCC48_IA32_CC_FLAGS)
>> DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS)
>> -DEFINE GCC49_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections
>> --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.9-ld-script
>> +DEFINE GCC49_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections -z
>> common-page-size=0x40
>> DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON)
>> --entry ReferenceAcpiTable -u ReferenceAcpiTable
>> DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC49_IA32_X64_DLINK_COMMON)
>> --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map
>> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>> DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS)
>> -melf_x86_64 --oformat=elf64-x86-64
>> diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script
>> b/BaseTools/Scripts/gcc-4K-align-ld-script
>> deleted file mode 100644
>> index 16cf623a3362..
>> --- a/BaseTools/Scripts/gcc-4K-align-ld-script
>> +++ /dev/null
>> @@ -1,44 +0,0 @@
>> -/* OUTPUT_FORMAT(efi-bsdrv-x86_64) */
>> -SECTIONS
>> -{
>> - /* . = 0 + SIZEOF_HEADERS; */
>> - . = 0x280;
>> - .text : ALIGN(0x1000)
>> - {
>> -*(.text .stub .text.* .gnu.linkonce.t.*)
>> -. = ALIGN(0x20);
>> - }
>> - .data : ALIGN(0x1000)
>> - {
>> -*(
>> - .rodata .rodata.* .gnu.linkonce.r.*
>> - .data .data.* .gnu.linkonce.d.*
>> - .bss .bss.*
>> - *COM*
>> -)
>> -. = ALIGN(0x20);
>> - }
>> - .eh_frame : ALIGN(0x1000)
>> - {
>> -KEEP (*(.eh_frame))
>> - }
>> - .got : ALIGN(0x1000)
>> - {
>> -*(.got .got.*)
>> -. = ALIGN(0x20);
>> - }
>> - .rela : ALIGN(0x1000)
>> - {
>> -*(.rela .rela.*)
>> - }
>> - /DISCARD/ : {
>> -*(.note.GNU-stack) *(.gnu_debuglink)
>> -*(.interp)
>> -*(.dynsym)
>> -*(.dynstr)
>> -*(.d
Re: [edk2] [PATCH v2 1/7] BaseTools: add unified GCC linker script for all archs and versions
On 28 July 2015 at 20:48, Jordan Justen wrote:
> On 2015-07-24 05:08:34, Ard Biesheuvel wrote:
>> This unifies all GCC linker scripts into a single parametrised GCC
>> linker script that can be used for all GCC versions and architectures.
>>
>> The two parameters that can be set on the linker command line are:
>> - PECOFF_HEADER_SIZE, this is a build time property of GenFw, but
>> its value is different between 32-bit and 64-bit;
>> - common-page-size, this can be set using -z on the ld command line,
>> and controls the value of the COMMONPAGESIZE constant when used in
>> a linker script. This value is used for the minimum section alignment.
>>
>> Notable differences between the original versions:
>> - .rodata has been moved into .text where it belongs;
>> - the =90909090 NOP padding has been removed, since the only purpose it
>> serves is making it easier for hackers to launch exploits, whereas
>> correct code does not rely on these NOPs at all;
>> - the .got contents have been moved into .text, but since we do not use
>> PIC code, this input section should always be empty anyway.
>
> These all sound reasonable, but wouldn't it be better to start with
> the current script and make each of these changes one at a time?
>
Perhaps, yes. But since this is a unification, some of these (the top
two) are already present in gcc-aarch64-ld-script, on which this is
mostly based.
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel
>> ---
>> BaseTools/Scripts/GCC/gcc-base.lds | 62
>> 1 file changed, 62 insertions(+)
>>
>> diff --git a/BaseTools/Scripts/GCC/gcc-base.lds
>> b/BaseTools/Scripts/GCC/gcc-base.lds
>> new file mode 100644
>> index ..e6109377ed38
>> --- /dev/null
>> +++ b/BaseTools/Scripts/GCC/gcc-base.lds
>> @@ -0,0 +1,62 @@
>> +/** @file
>> +
>> + Unified linker script for GCC based builds
>> +
>> + Copyright (c) 2015, Linaro Ltd. All rights reserved.
>
> Is this file based on BaseTools/Scripts/gcc4.9-ld-script?
>
> If so, could you add this?
>
> Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
>
> Or, if it is based on BaseTools/Scripts/gcc-4K-align-ld-script:
>
> Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
>
Since it is mostly a merge of all the different files, I will add the
latter and retain the Linaro one, if that is ok with you.
Thanks,
Ard.
>> +
>> + This program and the accompanying materials are licensed and made
>> available under
>> + the terms and conditions of the BSD License that accompanies this
>> distribution.
>> + The full text of the license may be found at
>> + http://opensource.org/licenses/bsd-license.php.
>> +
>> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
>> IMPLIED.
>> +
>> +**/
>> +
>> +SECTIONS {
>> +
>> + /*
>> + * The PE/COFF binary consists of DOS and PE/COFF headers, and a sequence
>> of
>> + * section headers adding up to PECOFF_HEADER_SIZE bytes (which differs
>> + * between 32-bit and 64-bit builds). The actual start of the .text
>> section
>> + * will be rounded up based on its actual alignment.
>> + */
>> + . = PECOFF_HEADER_SIZE;
>> +
>> + .text : ALIGN(CONSTANT(COMMONPAGESIZE)) {
>> +*(.text .text.* .stub .gnu.linkonce.t.*)
>> +*(.rodata .rodata.* .gnu.linkonce.r.*)
>> +*(.got .got.*)
>> + }
>> +
>> + /*
>> + * The alignment of the .data section should be less than or equal to the
>> + * alignment of the .text section. This ensures that the relative offset
>> + * between these sections is the same in the ELF and the PE/COFF versions
>> of
>> + * this binary.
>> + */
>> + .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) {
>> +*(.data .data.* .gnu.linkonce.d.*)
>> +*(.bss .bss.* *COM*)
>> + }
>> +
>> + .eh_frame ALIGN(CONSTANT(COMMONPAGESIZE)) : {
>> +KEEP (*(.eh_frame))
>> + }
>> +
>> + .rela ALIGN(CONSTANT(COMMONPAGESIZE)) : {
>> +*(.rela .rela.*)
>> + }
>> +
>> + /DISCARD/ : {
>> +*(.note.GNU-stack)
>> +*(.gnu_debuglink)
>> +*(.interp)
>> +*(.dynsym)
>> +*(.dynstr)
>> +*(.dynamic)
>> +*(.hash)
>> +*(.comment)
>> + }
>> +}
>> --
>> 1.9.1
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block
On 07/28/15 09:09, Fan, Jeff wrote: > I did not receive the patch 42. I have only gotten 38,39,40,41. I CC people on a given patch if I'd like to draw their personal, special attention to that patch. Therefore, a maintainer of a top-level package, affected by the patch, is always CC'd. However, it doesn't mean that a reviewer should ignore all other patches in a series. The full series is available on edk2-devel, which (I expect) you are subscribed to. If you'd like to locate the patches that you have been CC'd on among those patches that you have not been CC'd on, you can search for the former patches' message-ids on the list, or (much more simply) search for their subjects. > OK, If this mtrr setting stored in ACPI NVS is for CpuS3DataDxe to store into > SMRAM, that's fine. Thanks. > Then, another question, what's requirement to save MTRR setting into > ACPI NVS on this case? I explained this in my earlier email. The AcpiNVS block maintains an up-to-date copy of the MTRR settings, for whenever PiSmmCpuDxeSmm will need it. > And need one PCD to switch on/off it? That's a FeaturePCD. No client platform in edk2 other than OvmfPkg will need this functionality from UefiCpuPkg/CpuDxe for a while, so we should allow them *not* to take a hit, in code size and in AcpiNVS allocation. Thanks Laszlo > > Jeff > > -Original Message- > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > Sent: Tuesday, July 28, 2015 2:52 PM > To: Fan, Jeff; Laszlo Ersek; edk2-de...@ml01.01.org > Cc: Chen Fan; Justen, Jordan L > Subject: Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR > settings to AcpiNVS memory block > > > > On 28/07/2015 08:05, Fan, Jeff wrote: >> Ersek, >> >> I have one comment for PCD PcdCpuSyncMtrrToAcpiNvs. >> >> I knew OvmfPkg implemented LockBox based on ACPI NVS. Saving MTRR setting in >> AcpiNVS is OK for OvmfPkg. > > If I understand correctly what you are saying, the AcpiNVS block is only used > for communication from CpuDxe to CpuS3DataDxe in patch 42. > CpuS3DataDxe saves the MTRR in SMRAM during SmmReadyToLockEventNotify() and > PiSmmCpuDxeSmm restores them during S3 resume. So Laszlo's patches are doing > exactly the "safe" thing, even though they are not using LockBox. > >> But other platform may want to use more safe solution to save MTRR based on >> in SMM. >> >> I think that, for long term, saving MTRR setting by LockBox instead of >> using ACPI NVS memory directly. Then, different platforms could >> provide the different LockBox solutions. For short term, still saving >> MTRR setting in ACPI NVS in CpuDxe, and removing this PCD. That means >> we could CpuDxe implementation to use the long term solution in the >> future and needn't to remove one un-used PCD more. > > The PCD is consumed in CPUS3DataDxe. > > Paolo > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] CryptoPkg/OpensslLib: Undefine NO_BUILTIN_VA_FUNCS to fix varargs breakage
On Tue, 2015-07-28 at 20:26 +0200, Laszlo Ersek wrote: > - So maybe I was confused by "up to". Is that "up to and including" > or "up to and excluding"? In any case, I checked out the parent > commit: Sorry, yes. The 'OpenSSL HEAD WIP' commit adds support for, and *requires* OpenSSL HEAD. To test with 1.0.2d you indeed want the penultimate commit in the tree which is what you used. Thanks for testing! -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] ShellPkg: prevent Close call when Open failed
Tapan and Erik, Can you review this? ShellPkg: prevent Close call when Open failed Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jaben Carsey ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block
On 07/28/15 08:51, Paolo Bonzini wrote: > > > On 28/07/2015 08:05, Fan, Jeff wrote: >> Ersek, >> >> I have one comment for PCD PcdCpuSyncMtrrToAcpiNvs. >> >> I knew OvmfPkg implemented LockBox based on ACPI NVS. Saving MTRR setting in >> AcpiNVS is OK for OvmfPkg. > > If I understand correctly what you are saying, the AcpiNVS block is only > used for communication from CpuDxe to CpuS3DataDxe in patch 42. > CpuS3DataDxe saves the MTRR in SMRAM during SmmReadyToLockEventNotify() > and PiSmmCpuDxeSmm restores them during S3 resume. So Laszlo's patches > are doing exactly the "safe" thing, even though they are not using LockBox. Yes, with minimal tweaks, this is correct. The minimal tweak is the following: while CpuS3DataDxe collects most *other* data for PiSmmCpuDxeSmm indeed as a "deep copy", right when it is notified about the installation of EFI_SMM_CONFIGURATION_PROTOCOL, the saving of MTRR configuration is delayed, and for that CpuS3DataDxe only saves the address of the AcpiNVS block -- that CpuDxe maintains -- for PiSmmCpuDxeSmm. This way other firmware code can continue massaging the MTRR settings. Normally this happens via EFI_DXE_SERVICES.SetMemorySpaceAttributes EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() call chains, ie. platform-independent firmware code decides "this memory range should be uncached", calls gDS->SetMemorySpaceAttributes(), which is ultimately implemented by the CpuDxe driver, in the form of massaging MTRR. Now, whenever this happens, the MTRR settings block in AcpiNVS will be updated by CpuDxe. When SMM-ready-to-lock is finally installed, then PiSmmCpuDxeSmm will copy the then-fresh MTRR settings to SMRAM. This is the reason for the extra indirection here -- in one sentence, most of the data can be saved by CpuS3DataDxe immediately when EFI_SMM_CONFIGURATION_PROTOCOL is installed, but the MTRR settings can validly change after that, so their saving is delayed until SMM-ready-to-lock. > >> But other platform may want to use more safe solution to save MTRR based on >> in SMM. >> >> I think that, for long term, saving MTRR setting by LockBox instead >> of using ACPI NVS memory directly. Then, different platforms could >> provide the different LockBox solutions. For short term, still saving >> MTRR setting in ACPI NVS in CpuDxe, and removing this PCD. That means >> we could CpuDxe implementation to use the long term solution in the >> future and needn't to remove one un-used PCD more. > > The PCD is consumed in CPUS3DataDxe. Correct. The dynamic PCD carries the address of the AcpiNVS block (containing the ever-fresh MTRR settings) from CpuDxe to CpuS3DataDxe, which CpuS3DataDxe then just passes on to PiSmmCpuDxeSmm, in the ACPI_CPU_DATA.MtrrTable field. Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block
On 07/28/15 08:05, Fan, Jeff wrote: > Ersek, > > I have one comment for PCD PcdCpuSyncMtrrToAcpiNvs. > > I knew OvmfPkg implemented LockBox based on ACPI NVS. That is true for OVMF at the moment, but this series is exactly the one changing it. Going forward, if you build OVMF with -D SMM_REQUIRE, then the custom LockBox implementation will not be used; the edk2-standard SMRAM-based lockbox will be used instead. (Where SMRAM protection will be enforced by (virtual) hardware.) > Saving MTRR > setting in AcpiNVS is OK for OvmfPkg. > But other platform may want to use more safe solution to save MTRR > based on in SMM. MTRR settings are not saved in AcpiNVS for the long term (ie. AcpiNVS is not trusted to persist intact from normal boot to S3 suspend). These patches only ensure that the CPU driver maintains an up-to-date copy of the MTRR settings in AcpiNVS until SMM-ready-to-lock is installed. Please look at the diagram in: [edk2] [PATCH 33/58] OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=357 and also the commit message in: [edk2] [PATCH 42/58] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.MtrrTable http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=365 This is the process: - UefiCpuPkg/CpuDxe maintains an up-to-date copy of the MTRR settings in AcpiNVS, and stores the address in PcdCpuMtrrTableAddress. - OvmfPkg/QuarkPort/CpuS3DataDxe reads PcdCpuMtrrTableAddress, and passes the address to OvmfPkg/QuarkPort/PiSmmCpuDxeSmm via another structure. - When SMM-ready-to-lock is installed during normal boot, the OvmfPkg/QuarkPort/PiSmmCpuDxeSmm driver fetches the then-most-recent MTRR settings from the AcpiNVS block (which has been kept up-to-date by UefiCpuPkg/CpuDxe), and saves the contents in SMRAM. - The OS is booted. The AcpiNVS block can be overwritten (corrupted, tampered-with, etc) by the runtime OS. - S3 suspend and resume occurs. The S3Resume PEIM transfers control to OvmfPkg/QuarkPort/PiSmmCpuDxeSmm via direct stack switching. The latter programs the MTRRs directly from the data residing in SMRAM. - etc. > I think that, for long term, saving MTRR setting by LockBox instead > of using ACPI NVS memory directly. Then, different platforms could > provide the different LockBox solutions. That could be possible, yes, but in this instance I followed the Quark package as closely as possible (I extracted / ported the absolutely necessary parts of the drivers). The communication channels between the separate drivers are usually the most vulnerable points from a security POV -- indeed that's where I found, and reported, a security issue to Intel --, so I definitely did not want to redesign those channels; I just verified them as much as I could, and ported them as intact as I could. And, at the moment, the Quark package follows the above pattern; it saves the MTRR settings in a dedicated SMRAM allocation, not under a LockBox GUID. > For short term, still saving MTRR setting in ACPI NVS in CpuDxe, and > removing this PCD. That means we could CpuDxe implementation to use > the long term solution in the future and needn't to remove one > un-used PCD more. As I said, the AcpiNVS block carries live (= authoritative) data only during normal boot, *before* unprivileged / untrusted code is launched: from UefiPkg/CpuDxe to OvmfPkg/QuarkPort/PiSmmCpuDxeSmm. The AcpiNVS block ceases being sensitive when SMM-ready-to-lock is installed. So, we have two PCDs here: - PcdCpuMtrrTableAddress: this is dynamic, and it is necessary for the communication channel I described above. It carries the address of the AcpiNVS block. - PcdCpuSyncMtrrToAcpiNvs: this is a feature PCD. Given that at the moment, OvmfPkg is the only platform in the open source edk2 tree that puts this new UefiCpuPkg functionality to use, I thought it prudent to allow other platforms to compile *out* the relevant code of CpuDxe. Or, at least, to enable them to opt out of the AcpiNVS memory allocation (which would be pure waste for them). Therefore I intend these UefiCpuPkg patches as long-term. Thanks! Laszlo > > Thanks! > Jeff > > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Saturday, July 25, 2015 7:01 AM > To: edk2-de...@ml01.01.org > Cc: Fan, Jeff; Chen Fan; Justen, Jordan L > Subject: [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to > AcpiNVS memory block > > The > > Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuArchDxe > > driver provides the following capability in its implementation of > EFI_CPU_ARCH_PROTOCOL: whenever the SetMemoryAttributes() member is used > (directly, or indirectly via gDS->SetMemorySpaceAttributes()) to change MTRR > settings, the complete set of settings is immediately reflected to an AcpiNVS > memory block. > > (The address of said block is published via a dynamic PCD.) > > This feature is necessary for supporting SMM-c
Re: [edk2] [PATCH v2 7/7] BaseTools/X86|IA32: move to unified GCC linker script
On 2015-07-24 05:08:40, Ard Biesheuvel wrote:
> Drop the GCC 4.4/X86 and 4.9/X86 specific linker scripts and use
> the new unified one instead.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
> ---
> BaseTools/Conf/tools_def.template| 6 ++-
> BaseTools/Scripts/gcc-4K-align-ld-script | 44
> BaseTools/Scripts/gcc4.4-ld-script | 44
> BaseTools/Scripts/gcc4.9-ld-script | 44
> 4 files changed, 4 insertions(+), 134 deletions(-)
>
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index b29912c18e5b..84f1fda37661 100644
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -3813,6 +3813,8 @@ 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 =
>
> +*_*_IA32_DLINK2_FLAGS = --defsym=PECOFF_HEADER_SIZE=0x220
> --script=$(EDK_TOOLS_PATH)/Scripts/GCC/gcc-base.lds
> +*_*_X64_DLINK2_FLAGS = --defsym=PECOFF_HEADER_SIZE=0x228
> --script=$(EDK_TOOLS_PATH)/Scripts/GCC/gcc-base.lds
> *_*_AARCH64_DLINK2_FLAGS = --defsym=PECOFF_HEADER_SIZE=0x228
> --script=$(EDK_TOOLS_PATH)/Scripts/GCC/gcc-base.lds
>
> DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar
> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h
> @@ -3848,7 +3850,7 @@ DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O
> elf64-littleaarch64 -B aarch64
> DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing
> -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c
> -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
> DEFINE GCC44_IA32_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -m32
> -malign-double -fno-stack-protector -D EFI32
> DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64
> -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS
> -mno-red-zone -Wno-address -mcmodel=large
> -DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections
> --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.4-ld-script
> +DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections -z
> common-page-size=0x20
Any idea how old -z common-page-size is?
-Jordan
> DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON)
> --entry ReferenceAcpiTable -u ReferenceAcpiTable
> DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON)
> --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map
> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
> DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS)
> -melf_x86_64 --oformat=elf64-x86-64
> @@ -3908,7 +3910,7 @@ DEFINE GCC48_AARCH64_ASLDLINK_FLAGS =
> DEF(GCC47_AARCH64_ASLDLINK_FLAGS)
>
> DEFINE GCC49_IA32_CC_FLAGS = DEF(GCC48_IA32_CC_FLAGS)
> DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS)
> -DEFINE GCC49_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections
> --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.9-ld-script
> +DEFINE GCC49_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections -z
> common-page-size=0x40
> DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON)
> --entry ReferenceAcpiTable -u ReferenceAcpiTable
> DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC49_IA32_X64_DLINK_COMMON)
> --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map
> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
> DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS)
> -melf_x86_64 --oformat=elf64-x86-64
> diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script
> b/BaseTools/Scripts/gcc-4K-align-ld-script
> deleted file mode 100644
> index 16cf623a3362..
> --- a/BaseTools/Scripts/gcc-4K-align-ld-script
> +++ /dev/null
> @@ -1,44 +0,0 @@
> -/* OUTPUT_FORMAT(efi-bsdrv-x86_64) */
> -SECTIONS
> -{
> - /* . = 0 + SIZEOF_HEADERS; */
> - . = 0x280;
> - .text : ALIGN(0x1000)
> - {
> -*(.text .stub .text.* .gnu.linkonce.t.*)
> -. = ALIGN(0x20);
> - }
> - .data : ALIGN(0x1000)
> - {
> -*(
> - .rodata .rodata.* .gnu.linkonce.r.*
> - .data .data.* .gnu.linkonce.d.*
> - .bss .bss.*
> - *COM*
> -)
> -. = ALIGN(0x20);
> - }
> - .eh_frame : ALIGN(0x1000)
> - {
> -KEEP (*(.eh_frame))
> - }
> - .got : ALIGN(0x1000)
> - {
> -*(.got .got.*)
> -. = ALIGN(0x20);
> - }
> - .rela : ALIGN(0x1000)
> - {
> -*(.rela .rela.*)
> - }
> - /DISCARD/ : {
> -*(.note.GNU-stack) *(.gnu_debuglink)
> -*(.interp)
> -*(.dynsym)
> -*(.dynstr)
> -*(.dynamic)
> -*(.hash)
> -*(.comment)
> - }
> -}
> -
> diff --git a/BaseTools/Scripts/gcc4.4-ld-script
> b/BaseTools/Scripts/gcc4.4-ld-script
> deleted file mode 100644
> index 68b2767590ac..
Re: [edk2] [PATCH v2 1/7] BaseTools: add unified GCC linker script for all archs and versions
On 2015-07-24 05:08:34, Ard Biesheuvel wrote:
> This unifies all GCC linker scripts into a single parametrised GCC
> linker script that can be used for all GCC versions and architectures.
>
> The two parameters that can be set on the linker command line are:
> - PECOFF_HEADER_SIZE, this is a build time property of GenFw, but
> its value is different between 32-bit and 64-bit;
> - common-page-size, this can be set using -z on the ld command line,
> and controls the value of the COMMONPAGESIZE constant when used in
> a linker script. This value is used for the minimum section alignment.
>
> Notable differences between the original versions:
> - .rodata has been moved into .text where it belongs;
> - the =90909090 NOP padding has been removed, since the only purpose it
> serves is making it easier for hackers to launch exploits, whereas
> correct code does not rely on these NOPs at all;
> - the .got contents have been moved into .text, but since we do not use
> PIC code, this input section should always be empty anyway.
These all sound reasonable, but wouldn't it be better to start with
the current script and make each of these changes one at a time?
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
> ---
> BaseTools/Scripts/GCC/gcc-base.lds | 62
> 1 file changed, 62 insertions(+)
>
> diff --git a/BaseTools/Scripts/GCC/gcc-base.lds
> b/BaseTools/Scripts/GCC/gcc-base.lds
> new file mode 100644
> index ..e6109377ed38
> --- /dev/null
> +++ b/BaseTools/Scripts/GCC/gcc-base.lds
> @@ -0,0 +1,62 @@
> +/** @file
> +
> + Unified linker script for GCC based builds
> +
> + Copyright (c) 2015, Linaro Ltd. All rights reserved.
Is this file based on BaseTools/Scripts/gcc4.9-ld-script?
If so, could you add this?
Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
Or, if it is based on BaseTools/Scripts/gcc-4K-align-ld-script:
Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
-Jordan
> +
> + This program and the accompanying materials are licensed and made
> available under
> + the terms and conditions of the BSD License that accompanies this
> distribution.
> + The full text of the license may be found at
> + http://opensource.org/licenses/bsd-license.php.
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> +
> +**/
> +
> +SECTIONS {
> +
> + /*
> + * The PE/COFF binary consists of DOS and PE/COFF headers, and a sequence
> of
> + * section headers adding up to PECOFF_HEADER_SIZE bytes (which differs
> + * between 32-bit and 64-bit builds). The actual start of the .text section
> + * will be rounded up based on its actual alignment.
> + */
> + . = PECOFF_HEADER_SIZE;
> +
> + .text : ALIGN(CONSTANT(COMMONPAGESIZE)) {
> +*(.text .text.* .stub .gnu.linkonce.t.*)
> +*(.rodata .rodata.* .gnu.linkonce.r.*)
> +*(.got .got.*)
> + }
> +
> + /*
> + * The alignment of the .data section should be less than or equal to the
> + * alignment of the .text section. This ensures that the relative offset
> + * between these sections is the same in the ELF and the PE/COFF versions
> of
> + * this binary.
> + */
> + .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) {
> +*(.data .data.* .gnu.linkonce.d.*)
> +*(.bss .bss.* *COM*)
> + }
> +
> + .eh_frame ALIGN(CONSTANT(COMMONPAGESIZE)) : {
> +KEEP (*(.eh_frame))
> + }
> +
> + .rela ALIGN(CONSTANT(COMMONPAGESIZE)) : {
> +*(.rela .rela.*)
> + }
> +
> + /DISCARD/ : {
> +*(.note.GNU-stack)
> +*(.gnu_debuglink)
> +*(.interp)
> +*(.dynsym)
> +*(.dynstr)
> +*(.dynamic)
> +*(.hash)
> +*(.comment)
> + }
> +}
> --
> 1.9.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 11/58] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER
On 07/25/15 01:00, Laszlo Ersek wrote: > The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the > SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the > mSmmControl2->Trigger() call in the SmmCommunicationCommunicate() function > [MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c]. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek > --- > OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf | 63 ++ > OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c | 224 > OvmfPkg/OvmfPkgIa32.dsc | 1 + > OvmfPkg/OvmfPkgIa32.fdf | 1 + > OvmfPkg/OvmfPkgIa32X64.dsc| 1 + > OvmfPkg/OvmfPkgIa32X64.fdf| 1 + > OvmfPkg/OvmfPkgX64.dsc| 1 + > OvmfPkg/OvmfPkgX64.fdf| 1 + > 8 files changed, 293 insertions(+) I have a significant update for this patch. On S3 resume, the APMC_EN bit (and other bits) are cleared in SMI_EN (which is necessary, see qemu commit be66680e). For the trigger method to work right after S3 resume, the APMC_EN bit must be set again (otherwise a working-as-expected OS will not be able to use the variable services after S3 resume). I decided to put the S3 boot script to actual use this time, and I am now writing the necessary opcodes to the bootscript in the entry point (more precisely, in a protocol notify callback). This way chipset state is restored by the time the OS gets the control back. So that's going to be one change in v2. Clearly I'm not reposting the series just yet; this is just a heads-up. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] OvmfPkg: fix conversion specifiers in DEBUG format strings
On 07/28/15 06:53, Jordan Justen wrote: > On 2015-07-27 20:18:18, Scott Duplichan wrote: >> Laszlo Ersek [mailto:ler...@redhat.com] wrote: >> >> ]Sent: Monday, July 27, 2015 05:50 PM >> ]To: edk2-de...@ml01.01.org >> ]Cc: Jordan Justen ; Scott Duplichan >> >> ]Subject: [edk2] [PATCH] OvmfPkg: fix conversion specifiers in DEBUG format >> strings >> ] >> ]Cc: Scott Duplichan >> ]Cc: Jordan Justen >> ]Reported-by: Scott Duplichan >> ]Contributed-under: TianoCore Contribution Agreement 1.0 >> ]Signed-off-by: Laszlo Ersek >> ]--- >> ] >> ]Notes: >> ]Scott, can you please test-build with the attached patch, and see if any >> ]warnings continue to be emitted from under OvmfPkg? Thanks. >> >> Hello Laszlo, >> >> Thanks. The patch does indeed remove all warnings from code in the OvmfPkg >> directory. > > Cool. > > Reviewed-by: Jordan Justen Thank you. I also added Build-tested-by: Scott Duplichan in order to capture Scott's reply, and committed the patch as SVN r18095. Cheers Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] CryptoPkg/OpensslLib: Undefine NO_BUILTIN_VA_FUNCS to fix varargs breakage
On 07/28/15 11:32, David Woodhouse wrote: > On Tue, 2015-07-28 at 01:45 +, Long, Qin wrote: >> Reviewed-by: Qin Long >> >> And Ersek, could you kindly help to double-check it will not break >> any shim scenario? > > That would be very much appreciated; thanks. I have done *no* testing > other than build testing so far. > > It would also be useful to test with the clock set deliberately wrong, > after my 'Remove OpenSSL hack and manually ignore validity time range' > patch: > http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/9b89269c > > Note that all up to the final 'OpenSSL HEAD WIP' patch ought to work > with the existing 1.0.2d support too. Here's what I tried: - I fetched your repo and checked out your master branch: commit 94e3012b638f56d4c5c65b29815eeb36eeb399c5 Author: David Woodhouse Date: Mon Jul 27 12:10:58 2015 +0100 OpenSSL HEAD WIP (the most recent shared commit with upstream is 410952bf8bd071d5541dd82ac16069cd3b50e09b) - I executed "CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt" manually, as always - I ran: . edksetup.sh make -C "$EDK_TOOLS_PATH" build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -D SECURE_BOOT_ENABLE \ -t GCC48 -n 2 --report-file=.../build.ovmf.report \ --log=.../build.ovmf.log -b DEBUG - I got the following error: .../CryptoPkg/Library/OpensslLib/OpensslLib.inf(31): error 000E: File/directory not found in workspace .../CryptoPkg/Library/OpensslLib/openssl/e_os.h - So maybe I was confused by "up to". Is that "up to and including" or "up to and excluding"? In any case, I checked out the parent commit: commit 7efd575e4d2aa98a833f0691c9db99c0a23350fe Author: David Woodhouse Date: Mon Jul 27 17:15:09 2015 +0100 CryptoPkg: Remove OpenSSL hack and manually ignore validity time range and retried the build. This time it built okay. I booted two preexistent, Secure Boot-active guests; a Fedora one and a Windows Server 2012 R2 one. They both booted okay, and they both confirmed secure boot was active (dmesg in Fedora, Confirm-SecureBootUEFI in powershell in Windows). series (up to and including 3/2) Tested-by: Laszlo Ersek I didn't try to mess with the clock, so if you wish, we can restrict my Tested-by to the first two patches, and add Regression-tested-by for the third. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support
Hi Jordan, Sorry, (metaphorically) snowed under for a few days. On Fri, Jul 17, 2015 at 02:44:10PM -0700, Jordan Justen wrote: > > > Does this depend on ArmPkg / EmbeddedPkg, or is this just a generic > > > PCI based driver? > > > > > > It could be nice to have a generic place for such drivers, but I think > > > OptionRomPkg is the closest we have today. > > > > Well, I'm planning to add it to my OpenPlatformPkg tree. > > If that was to be merged into edk2, that would contain such a generic > > place. > > But, the name 'open platform' also sounds strange, assuming this a > plain PCI bus driver. Couldn't it live in a 'pci drivers' package? > > Personally, I think we should rename OptionRomPkg to DriversPkg, or > split it into UsbDriversPkg and PciDriversPkg. So, OpenPlatformPkg is my current way of dealing with the lack of a unified handling of platform/driver code in edk2. It is not something I mind giving up if this situation resolves itself another way. Or renaming to something more palatable :) I gave a presentation (more like lightning talk) at the spring plugfest in Seattle on this: http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Platforms_Tree_May_2015.pdf If we simply rename OptionRomPkg to DriversPkg (and restructure a bit in there), then that solves the drivers part of my problem. But I still need something for opensource platform support. / Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 17/58] OvmfPkg: import PiSmmCpuDxeSmm from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
Note: Cc: edk2-devel
Mike,
Can you *please* help out with this?? We've been discussing this since
April...
1. Why should we import all this code under the OVMF platform?
2. Why should we have a different license from the rest of EDK II if
this is all Intel code?
Last time we talked about this in early June, I thought you had a plan
for this. Any updates??
Thanks,
-Jordan
On 2015-07-24 16:00:23, Laszlo Ersek wrote:
> This mammoth DXE_SMM_DRIVER provides gEfiSmmConfigurationProtocolGuid
> (among many other things), which is a dependency of the SMM Initial
> Program Load module ("MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c"). It
> provides the mixed (assembly and C) language, lowest level SMM entry
> point.
>
> It is also responsible for populating the SMM_S3_RESUME_STATE object on
> normal boot that "OvmfPkg/SmmAccess/SmmAccessPei.c" sets aside in SMRAM
> and that "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c" uses on
> S3 resume.
>
> Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg can be found at
> , and comes under the
> 3-clause BSD License (which is allowed by OvmfPkg/Contributions.txt)
>
> We don't try to build the driver at the moment, just import it. The
> following patches will port it to, and slim it down for, OVMF.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek
> ---
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf| 156 ++
> OvmfPkg/QuarkPort/Include/AcpiCpuData.h| 53 +
> OvmfPkg/QuarkPort/Include/CpuHotPlugData.h | 52 +
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/CpuService.h | 213 +++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmmProfileArch.h | 116 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 782 +
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmFeatures.h | 191 +++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmProfile.h | 83 +
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmProfileInternal.h | 184 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/CpuS3.c | 454 +
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/CpuService.c | 500 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/PageTbl.c| 116 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/Semaphore.c | 78 +
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmmProfileArch.c | 84 +
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/MpService.c | 1813
>
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 1530
> +
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmFeatures.c | 380
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmProfile.c | 1376 +++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SyncTimer.c | 130 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/MpFuncs.S| 186 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/MpFuncs.asm | 190 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmiEntry.S | 171 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm | 176 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmiException.S | 1196 +
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmiException.asm | 883 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmmInit.S| 122 ++
> OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmmInit.asm | 132 ++
> 27 files changed, 11347 insertions(+)
>
> diff --git a/OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> b/OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> new file mode 100644
> index 000..b64db8f
> --- /dev/null
> +++ b/OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> @@ -0,0 +1,156 @@
> +## @file
> +#
> +# Agent Module to load other modules to deploy SMM Entry Vector for X86 CPU.
> +# Copyright (c) 2013-2015 Intel Corporation.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions
> +# are met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +# notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above copyright
> +# notice, this list of conditions and the following disclaimer in
> +# the documentation and/or other materials provided with the
> +# distribution.
> +# * Neither the name of Intel Corporation nor the names of its
> +# contributors may be used to endorse or promote products derived
> +# from this software without specific prior written permission.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> +# LIMITED TO, PROCUREME
Re: [edk2] [PATCH v2 0/6] ArmPkg/ArmVirtPkg: GIC revision detection
Hi Ard, Sorry for delay. On Sun, Jul 26, 2015 at 02:50:24PM +0200, Ard Biesheuvel wrote: > On 26 July 2015 at 13:46, Leif Lindholm wrote: > > On Sun, Jul 26, 2015 at 01:08:20PM +0200, Ard Biesheuvel wrote: > >> > So ... had a look through, looks sane, have a couple of minor comments > >> > (will add inline). > >> > But what I don't have at home is a useful hardware platform to test > >> > this on. Has anyone else tested on 32-bit/64-bit hardware? > >> > >> Only under KVM, which is not very useful to you. > > > > Not sufficiently. > > > > I tried it under FVP (after spotting and fixing a kernel bug, see > separate email) and it works fine. > > >> I was kind of hoping you could push it through the CI Olivier always > >> talked about. Or was that his personal setup? > > > > For all intents and purposes. > > > >> Do note that, even if they are non-trivial patches, the only actual > >> change to non-virt platforms is that, for non-SEC modules, the result > >> of the GIC detection is cached in a global. > > > > Sure. I'm just being paranoid. > > > > Well, I'll have a look tomorrow, while looking around for any hw > > people might not miss... > > If you do mind the ArmGicArchSecLib clone and subsequent change of > ArmGicArchLib, we could drop that, since the other patches still allow > the virt platforms to use the GIC revision specified in the device > tree (which is the primary motivation for this series) No issue with those. I've now tested on Juno r1 and TC2. So for where you need it: Reviewed-by: Leif Lindholm Tested-by: Leif Lindholm / Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 2/4] ArmVirtPkg: use 'auto' alignment and FIXED placement for XIP modules
Now that GenFw correctly propagates the minimum alignment of the ELF
input sections to the PE/COFF binary, we can simply select 'auto'
alignment in the FDF Rule section instead of tweaking it by hand.
Also add the FIXED FFS attribute to the module types that may execute
in place. This enables a newly added optimization in GenFfs that strips
redundant padding, preventing excessive waste of FV space if the section
alignment is considerable (i.e., 2 KB or 4 KB)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
ArmVirtPkg/ArmVirtQemu.fdf | 12 ++--
ArmVirtPkg/ArmVirtXen.fdf | 12 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 4ef0f8bb6aa4..3c0487cd95b6 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -309,20 +309,20 @@ [FV.FVMAIN_COMPACT]
[Rule.Common.SEC]
- FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
-TE TE Align = 128 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
+TE TE Align = Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
}
[Rule.Common.PEI_CORE]
- FILE PEI_CORE = $(NAMED_GUID) {
-TE TE Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ FILE PEI_CORE = $(NAMED_GUID) FIXED {
+TE TE Align = Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
UI STRING ="$(MODULE_NAME)" Optional
}
[Rule.Common.PEIM]
- FILE PEIM = $(NAMED_GUID) {
+ FILE PEIM = $(NAMED_GUID) FIXED {
PEI_DEPEX PEI_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
- TE TE Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ TE TE Align = Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
UI STRING="$(MODULE_NAME)" Optional
}
diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
index f98772b7191d..97cab4b058f2 100644
--- a/ArmVirtPkg/ArmVirtXen.fdf
+++ b/ArmVirtPkg/ArmVirtXen.fdf
@@ -220,20 +220,20 @@ [FV.FVMAIN_COMPACT]
[Rule.Common.SEC]
- FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
-TE TE Align = 4K $(INF_OUTPUT)/$(MODULE_NAME).efi
+ FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
+TE TE Align = Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
}
[Rule.Common.PEI_CORE]
- FILE PEI_CORE = $(NAMED_GUID) {
-TE TE Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ FILE PEI_CORE = $(NAMED_GUID) FIXED {
+TE TE Align = Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
UI STRING ="$(MODULE_NAME)" Optional
}
[Rule.Common.PEIM]
- FILE PEIM = $(NAMED_GUID) {
+ FILE PEIM = $(NAMED_GUID) FIXED {
PEI_DEPEX PEI_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
- TE TE Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ TE TE Align = Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
UI STRING="$(MODULE_NAME)" Optional
}
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/4] small model and clang support for AARCH64
This is another followup to the series 'small C model and LLVM/clang support for AARCH64' that I sent out on July 17th. Now that the FFS/FV optimization patches have been merged, this is what remains to allow the AARCH64 platforms to be built using clang, combined with the GNU binutils (cross-)toolchain. Note that this series depends on 'BaseTools: unify all GCC linker scripts' that I sent out on July 24th, and is still under review. Patch #1 is a simple fixup to allow clang to assemble the GICv3 support code. Patch #2 sets the correct TE alignment, needed for the 4 KB section aligned binaries that we built when using clang and its small code model. It supersedes 'ArmVirtPkg: use 'auto' alignment for XIP modules' sent out on July 17th and acked by Laszlo. This version also sets the 'FIXED' FFS attribute which is now required to enable the FFS/FV padding optimization logic. Patch #3 relaxes the relocation checks in GenFw to allow relative relocations for AARCH64, but only if they don't require recalculation. This is needed to work around an issue with GNU binutils 2.24 and older, which emits incorrect relocation information into fully linked ELF binaries (i.e., when using the --emit-relocs option). This patch superseded 'BaseTools/GenFw: allow AArch64 small model relocations' sent out July 17th. Patch #4 adds the tool definition for CLANG as a member of the GCC family. Build and boot tested with ArmVirtQemu and ArmVExpressPkg-FVP built in both DEBUG and RELEASE modes using: Ubuntu clang version 3.5.0-4ubuntu2 (tags/RELEASE_350/final) (based on LLVM 3.5.0) Target: aarch64 Ard Biesheuvel (4): ArmPkg: don't redefine GICv3 sysreg names to generic names ArmVirtPkg: use 'auto' alignment and FIXED placement for XIP modules BaseTools/GenFw: allow AArch64 tiny and small code model relocations BaseTools: add support for CLANG compiler to GCC family ArmPkg/Drivers/ArmGic/GicV3/AArch64/ArmGicV3.S | 4 + ArmVirtPkg/ArmVirtQemu.fdf | 12 +-- ArmVirtPkg/ArmVirtXen.fdf | 12 +-- BaseTools/Conf/tools_def.template | 49 +++ BaseTools/Source/C/GenFw/Elf64Convert.c| 92 +++- 5 files changed, 114 insertions(+), 55 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] ArmPkg: don't redefine GICv3 sysreg names to generic names
The GNU assembler supports a generic notation for sysregs, to allow the use of system registers defined by newer versions of the architecture by older versions of the toolchain. Clang does not support this generic notation, nor does it need to in the particular case of the GICv3 support code, since it knows the GICv3 registers by their architectural names. So only redefine their real names to their generic aliases if we are not using clang. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmPkg/Drivers/ArmGic/GicV3/AArch64/ArmGicV3.S | 4 1 file changed, 4 insertions(+) diff --git a/ArmPkg/Drivers/ArmGic/GicV3/AArch64/ArmGicV3.S b/ArmPkg/Drivers/ArmGic/GicV3/AArch64/ArmGicV3.S index c30ae76d9455..80205f8f2861 100644 --- a/ArmPkg/Drivers/ArmGic/GicV3/AArch64/ArmGicV3.S +++ b/ArmPkg/Drivers/ArmGic/GicV3/AArch64/ArmGicV3.S @@ -13,6 +13,8 @@ #include +#if !defined(__clang__) + #define ICC_SRE_EL1 S3_0_C12_C12_5 #define ICC_SRE_EL2 S3_4_C12_C9_5 #define ICC_SRE_EL3 S3_6_C12_C12_5 @@ -22,6 +24,8 @@ #define ICC_PMR_EL1 S3_0_C4_C6_0 #define ICC_BPR1_EL1S3_0_C12_C12_3 +#endif + .text .align 2 -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 4/4] BaseTools: add support for CLANG compiler to GCC family
This adds support for building the AARCH64 platforms using the Clang frontend combined with the GNU binutils (cross-)toolchain. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 49 1 file changed, 49 insertions(+) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 84f1fda37661..291a82c963ed 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -4617,6 +4617,55 @@ RELEASE_GCC49_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS) -Wno-unused-but-s # +# CLANG - This configuration is used to compile under Linux to produce +# PE/COFF binaries using the clang compiler and GNU assembler and linker +# + +*_CLANG_*_*_FAMILY = GCC + +*_CLANG_*_MAKE_PATH = make +*_CLANG_*_*_DLL = ENV(CLANG_DLL) +*_CLANG_*_ASL_PATH = DEF(UNIX_IASL_BIN) + +*_CLANG_*_PP_FLAGS = DEF(GCC_PP_FLAGS) +*_CLANG_*_ASLPP_FLAGS= DEF(GCC_ASLPP_FLAGS) +*_CLANG_*_ASLCC_FLAGS= DEF(GCC_ASLCC_FLAGS) +*_CLANG_*_VFRPP_FLAGS= DEF(GCC_VFRPP_FLAGS) +*_CLANG_*_APP_FLAGS = +*_CLANG_*_ASL_FLAGS = DEF(IASL_FLAGS) +*_CLANG_*_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS) + +*_CLANG_*_CC_PATH= ENV(CLANG_BIN)clang +*_CLANG_*_ASM_PATH = ENV(CLANG_BIN)clang +*_CLANG_*_PP_PATH= ENV(CLANG_BIN)clang +*_CLANG_*_VFRPP_PATH = ENV(CLANG_BIN)clang +*_CLANG_*_ASLCC_PATH = ENV(CLANG_BIN)clang +*_CLANG_*_ASLPP_PATH = ENV(CLANG_BIN)clang + +DEFINE CLANG_WARNING_OVERRIDES = -Wno-parentheses-equality -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare -Wno-empty-body + +## +# CLANG AARCH64 definitions +## +*_CLANG_AARCH64_SLINK_PATH = ENV(CLANG_AARCH64_PREFIX)ar +*_CLANG_AARCH64_DLINK_PATH = ENV(CLANG_AARCH64_PREFIX)ld +*_CLANG_AARCH64_ASLDLINK_PATH= ENV(CLANG_AARCH64_PREFIX)ld +*_CLANG_AARCH64_RC_PATH = ENV(CLANG_AARCH64_PREFIX)objcopy + +*_CLANG_AARCH64_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) +*_CLANG_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_ASLDLINK_FLAGS) +*_CLANG_AARCH64_ASM_FLAGS= DEF(GCC_ASM_FLAGS) $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) -target aarch64 +*_CLANG_AARCH64_DLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS) -z common-page-size=0x1000 +*_CLANG_AARCH64_PLATFORM_FLAGS = +*_CLANG_AARCH64_PP_FLAGS = DEF(GCC_PP_FLAGS) $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) +*_CLANG_AARCH64_RC_FLAGS = DEF(GCC_AARCH64_RC_FLAGS) +*_CLANG_AARCH64_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) + + DEBUG_CLANG_AARCH64_CC_FLAGS = DEF(GCC_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -target aarch64 -mcmodel=small -O0 DEF(CLANG_WARNING_OVERRIDES) +RELEASE_CLANG_AARCH64_CC_FLAGS = DEF(GCC_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -target aarch64 -mcmodel=small DEF(CLANG_WARNING_OVERRIDES) + + +# # Cygwin GCC And Intel ACPI Compiler # -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 3/4] BaseTools/GenFw: allow AArch64 tiny and small code model relocations
The AArch64 small C model makes extensive use of ADRP/ADD and
ADRP/{LDR,STR} pairs to emit PC-relative symbol references with
a +/- 4 GB range. Since the relocation pair splits the relative
offset into a relative page offset and an absolute offset into
a 4 KB page, we need to take extra care to ensure that the target
of the relocation preserves its alignment relative to a 4 KB
alignment boundary.
Also, due to a problem with the --emit-relocs GNU ld option, where
it does not recalculate the addends for section relative relocations,
the only way to guarantee correct code is by requiring the relative
section offset to be equal in the ELF and PE/COFF versions of the
binary. This affects both the 'tiny' and 'small' GCC code models.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
BaseTools/Source/C/GenFw/Elf64Convert.c | 92 +++-
1 file changed, 49 insertions(+), 43 deletions(-)
diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 1c0f4a4dc87c..c758ed9d64a6 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -740,53 +740,60 @@ WriteSections64 (
}
} else if (mEhdr->e_machine == EM_AARCH64) {
- // AARCH64 GCC uses RELA relocation, so all relocations have to be
fixed up.
- // As opposed to ARM32 using REL.
-
switch (ELF_R_TYPE(Rel->r_info)) {
- case R_AARCH64_ADR_PREL_LO21:
-if (Rel->r_addend != 0 ) { /* TODO */
- Error (NULL, 0, 3000, "Invalid", "AArch64:
R_AARCH64_ADR_PREL_LO21 Need to fixup with addend!.");
+ case R_AARCH64_ADR_PREL_PG_HI21:
+ case R_AARCH64_ADD_ABS_LO12_NC:
+ case R_AARCH64_LDST8_ABS_LO12_NC:
+ case R_AARCH64_LDST16_ABS_LO12_NC:
+ case R_AARCH64_LDST32_ABS_LO12_NC:
+ case R_AARCH64_LDST64_ABS_LO12_NC:
+ case R_AARCH64_LDST128_ABS_LO12_NC:
+//
+// AArch64 PG_H21 relocations are typically paired with ABS_LO12
+// relocations, where a PC-relative reference with +/- 4 GB range
is
+// split into a relative high part and an absolute low part. Since
+// the absolute low part represents the offset into a 4 KB page, we
+// have to make sure that the 4 KB relative offsets of both the
+// section containing the reference as well as the section to which
+// it refers have not been changed during PE/COFF conversion (i.e.,
+// in ScanSections64() above).
+//
+if (((SecShdr->sh_addr ^ SecOffset) & 0xfff) != 0 ||
+((SymShdr->sh_addr ^ mCoffSectionsOffset[Sym->st_shndx]) &
0xfff) != 0 ||
+mCoffAlignment < 0x1000) {
+ Error (NULL, 0, 3000, "Invalid", "WriteSections64(): %s AARCH64
small code model requires 4 KB section alignment.",
+mInImageName);
+ break;
}
-break;
+/* fall through */
+ case R_AARCH64_ADR_PREL_LO21:
case R_AARCH64_CONDBR19:
-if (Rel->r_addend != 0 ) { /* TODO */
- Error (NULL, 0, 3000, "Invalid", "AArch64: R_AARCH64_CONDBR19
Need to fixup with addend!.");
-}
-break;
-
case R_AARCH64_LD_PREL_LO19:
-if (Rel->r_addend != 0 ) { /* TODO */
- Error (NULL, 0, 3000, "Invalid", "AArch64:
R_AARCH64_LD_PREL_LO19 Need to fixup with addend!.");
-}
-break;
-
case R_AARCH64_CALL26:
case R_AARCH64_JUMP26:
-if (Rel->r_addend != 0 ) {
- // Some references to static functions sometime start at the
base of .text + addend.
- // It is safe to ignore these relocations because they patch a
`BL` instructions that
- // contains an offset from the instruction itself and there is
only a single .text section.
- // So we check if the symbol is a "section symbol"
- if (ELF64_ST_TYPE (Sym->st_info) == STT_SECTION) {
-break;
- }
- Error (NULL, 0, 3000, "Invalid", "AArch64: R_AARCH64_JUMP26 Need
to fixup with addend!.");
+//
+// The GCC toolchains (i.e., binutils) may corrupt section relative
+// relocations when emitting relocation sections into fully linked
+// binaries. More specifically, they tend to fail to take into
+// account the fact that a '.rodata + XXX' relocation needs to have
+// its addend recalculated once .rodata is merged into the .text
+// section, and the relocation emitted into the .rela.text section.
+//
+// We cannot really recover from this loss of information, so the
+// only workaround is to prevent having to recalculate any relative
+// relocatio
Re: [edk2] [PATCH] MdeModulePkg: Include CapsuleX64 in MdeModulePkg.dsc [Components.X64]
Reviewed-by: Feng Tian -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng Sent: Tuesday, July 28, 2015 4:56 PM To: edk2-devel@lists.01.org Cc: Tian, Feng Subject: [edk2] [PATCH] MdeModulePkg: Include CapsuleX64 in MdeModulePkg.dsc [Components.X64] It was forgotten to be included in MdeModulePkg.dsc when created. Cc: Feng Tian Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- MdeModulePkg/MdeModulePkg.dsc | 4 1 file changed, 4 insertions(+) diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc index 3537ca8..be67e9d 100644 --- a/MdeModulePkg/MdeModulePkg.dsc +++ b/MdeModulePkg/MdeModulePkg.dsc @@ -394,3 +394,7 @@ [Components.IA32, Components.X64] MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableSmm/FirmwarePerformanceSmm.inf MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.inf + +[Components.X64] + MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf + -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] Vlv2TbltDevicePkg: Exclude CapsuleX64 from IA32 build
CapsuleX64 is for 64bits capsule data access in PEI phase,
it is only needed for X64 DXE build.
Cc: David Wei
Cc: Tim He
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
Vlv2TbltDevicePkg/PlatformPkg.fdf | 2 ++
Vlv2TbltDevicePkg/PlatformPkgGcc.fdf | 2 ++
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 9 -
3 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/Vlv2TbltDevicePkg/PlatformPkg.fdf
b/Vlv2TbltDevicePkg/PlatformPkg.fdf
index 80ce20d..03cabb9 100644
--- a/Vlv2TbltDevicePkg/PlatformPkg.fdf
+++ b/Vlv2TbltDevicePkg/PlatformPkg.fdf
@@ -359,8 +359,10 @@ [FV.FVRECOVERY]
!if $(CAPSULE_ENABLE) == TRUE
INF MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
+!if $(DXE_ARCHITECTURE) == "X64"
INF MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf
!endif
+!endif
!if $(MINNOW2_FSP_BUILD) == FALSE
!if $(PCIESC_ENABLE) == TRUE
diff --git a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
index f556853..9ec4ce5 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
+++ b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
@@ -317,8 +317,10 @@ [FV.FVRECOVERY]
!if $(CAPSULE_ENABLE) == TRUE
INF MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
+!if $(DXE_ARCHITECTURE) == "X64"
INF MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf
!endif
+!endif
!if $(MINNOW2_FSP_BUILD) == FALSE
!if $(PCIESC_ENABLE) == TRUE
diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index 39054cf..2fa7a36 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -1100,15 +1100,6 @@ [Components.IA32]
!endif
}
-!if $(CAPSULE_ENABLE) == TRUE
- MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf {
-
-PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
-HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
- }
-!endif
-
MdeModulePkg/Universal/ReportStatusCodeRouter/Smm/ReportStatusCodeRouterSmm.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf{
--
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] ArmPkg: Move FDT offset higher in RAM
On 28 July 2015 at 11:41, Ryan Harkin wrote: > > > On 28 July 2015 at 10:26, Ard Biesheuvel wrote: >> >> On 28 July 2015 at 11:01, Ryan Harkin wrote: >> > [+ Tixy as he's interested in making sure UEFI follows the Linux >> > requirements] >> > >> > On 28 July 2015 at 07:39, Ard Biesheuvel >> > wrote: >> >> >> >> >> On 27 July 2015 at 22:42, Ryan Harkin wrote: >> >> > Device tree files in recent kernels (eg. Linux 4.2) can be >16KB. >> >> > >> >> > The max offset of 0x4000 meant that the device tree would be >> >> > allocated >> >> > at a "random address", which more often than not was above the >> >> > recommended 128MiB boundary. >> >> > >> >> >> >> From Documentation/arm/Booting: >> >> >> >> """ >> >> 4b. Setup the device tree >> >> ... >> >> A safe location is just above the 128MiB boundary from start of RAM. >> >> """ >> >> >> >> i.e., the documented protocol explicitly suggests using an address > >> >> 128 >> >> MB. >> >> So what exactly goes wrong if you load it at a random address? >> > >> > >> > For some reason, I've been reading this as "before" 128MiB. How strange >> > of >> > me. >> > >> > The advice I was following was from the bottom of the email thread where >> > Nicolas Mitre says: >> > >> > "You can therefore load everything (zImage, initrd, DTB) sequentially >> > from the 32MB mark in RAM and be safe." >> > >> > But mostly, I was trying to keep the bottom 32MB unused. >> > >> >> Yes, I think that is the primary requirement here. >> >> > We don't have the option to load sequentially from 32MB unless I change >> > the >> > code a lot more. I've already tried a hack that placed the 3 files >> > sequentially from 0x8200 on TC2 and it works well, although it's >> > technically wrong because I didn't explicity reserve memory in those >> > areas >> > to stop UEFI from using it. >> > >> > I'll try changing the max offsets to be all above 128MiB and see if it >> > still >> > works. As Tixy pointed out to me, the problem I had with the Linux >> > Loader's >> > "random address" for the DTB is that it was always in the same region >> > that >> > Linux reserves for CMA. And I think that starts before the DTB is >> > finished >> > with. >> > >> >> I think we could simply raise your max address limit to 132 MB: by the >> looks of it, that is the maximum size the current kernel code will >> ever be able to support since it uses two adjacent sections to map the >> FDT, and sections are 2 MB at most when using long descriptors. > > > I've tested it with a patch to change the max offsets to 0x8400 and it > works well. My hacked in debug shows: > > linux: address 0x87FD2000 > linux: length 0x42D248 Hmm, this doesn't look right. The zImage should be below 128 MB, since it infers the base of DRAM by rounding down its own address to a multiple of 128 MB. I seem to have missed the part before where the PCD in question also affects the placement of the zImage and not only the FDT. > fdt:address 0x87E6E000 > fdt:length 0x3FFC > initrd: address 0x87E73000 > initrd: length 0x15E600 > So the rules say: - zImage between 32 MB and 128 MB - FDT preferably at the next 128 MB boundary - initrd preferably right above the FDT I guess your v1 was best after all: even if the FDT and initrd end up below 128 MB, it is the best we can do with just this PCD -- Ard. > From this patch: > > diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec > index b30de91..d5b930a 100644 > --- a/ArmPkg/ArmPkg.dec > +++ b/ArmPkg/ArmPkg.dec > @@ -117,7 +117,7 @@ ># >gArmTokenSpaceGuid.PcdArmMachineType|0|UINT32|0x001E ># The compressed Linux kernel is expected to be under 128MB from the > beginning of the System Memory > - > gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0800|UINT32|0x001F > + > gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0840|UINT32|0x001F^M ># Maximum file size for TFTP servers that do not support 'tsize' > extension >gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x0100|UINT32|0x > > @@ -159,7 +159,7 @@ ># If the fixed FDT address is not available, then it should be loaded > below the kernel. ># The recommendation from the Linux kernel is to have the FDT below 16KB. ># (see the kernel doc: Documentation/arm/Booting) > - gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x0023 > + gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x0840|UINT32|0x0023^M ># The FDT blob must be loaded at a 64bit aligned address. >gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x0026 > > > Of course, the comments will have to change too: "under 128MB" => "above > 128MiB" and there is no recommendation for the device tree to be < 16KB. > > Unless I get further comment, I'll submit a v2 patch as above with the > comments updated. > > >> >> >> BTW it seems odd for the LinuxLoader - which is now a separate EFI >> application - to use fixed PCDs to parametrise its behavior. I think >> it would be justified to hardcode the reco
Re: [edk2] [PATCH] ArmPkg: Move FDT offset higher in RAM
Apologies for top-posting, I think this conversation should drop edk2-devel and move to linaro-uefi (added to cc), until there is consensus/conclusion. Could the next person replying to this thread delete edk2-devel from the recipient list please? / Leif On Tue, Jul 28, 2015 at 10:41:29AM +0100, Ryan Harkin wrote: > On 28 July 2015 at 10:26, Ard Biesheuvel wrote: > > > On 28 July 2015 at 11:01, Ryan Harkin wrote: > > > [+ Tixy as he's interested in making sure UEFI follows the Linux > > > requirements] > > > > > > On 28 July 2015 at 07:39, Ard Biesheuvel > > wrote: > > >> > > >> On 27 July 2015 at 22:42, Ryan Harkin wrote: > > >> > Device tree files in recent kernels (eg. Linux 4.2) can be >16KB. > > >> > > > >> > The max offset of 0x4000 meant that the device tree would be allocated > > >> > at a "random address", which more often than not was above the > > >> > recommended 128MiB boundary. > > >> > > > >> > > >> From Documentation/arm/Booting: > > >> > > >> """ > > >> 4b. Setup the device tree > > >> ... > > >> A safe location is just above the 128MiB boundary from start of RAM. > > >> """ > > >> > > >> i.e., the documented protocol explicitly suggests using an address > 128 > > >> MB. > > >> So what exactly goes wrong if you load it at a random address? > > > > > > > > > For some reason, I've been reading this as "before" 128MiB. How strange > > of > > > me. > > > > > > The advice I was following was from the bottom of the email thread where > > > Nicolas Mitre says: > > > > > > "You can therefore load everything (zImage, initrd, DTB) sequentially > > > from the 32MB mark in RAM and be safe." > > > > > > But mostly, I was trying to keep the bottom 32MB unused. > > > > > > > Yes, I think that is the primary requirement here. > > > > > We don't have the option to load sequentially from 32MB unless I change > > the > > > code a lot more. I've already tried a hack that placed the 3 files > > > sequentially from 0x8200 on TC2 and it works well, although it's > > > technically wrong because I didn't explicity reserve memory in those > > areas > > > to stop UEFI from using it. > > > > > > I'll try changing the max offsets to be all above 128MiB and see if it > > still > > > works. As Tixy pointed out to me, the problem I had with the Linux > > Loader's > > > "random address" for the DTB is that it was always in the same region > > that > > > Linux reserves for CMA. And I think that starts before the DTB is > > finished > > > with. > > > > > > > I think we could simply raise your max address limit to 132 MB: by the > > looks of it, that is the maximum size the current kernel code will > > ever be able to support since it uses two adjacent sections to map the > > FDT, and sections are 2 MB at most when using long descriptors. > > > > I've tested it with a patch to change the max offsets to 0x8400 and it > works well. My hacked in debug shows: > > linux: address 0x87FD2000 > linux: length 0x42D248 > fdt:address 0x87E6E000 > fdt:length 0x3FFC > initrd: address 0x87E73000 > initrd: length 0x15E600 > > From this patch: > > diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec > index b30de91..d5b930a 100644 > --- a/ArmPkg/ArmPkg.dec > +++ b/ArmPkg/ArmPkg.dec > @@ -117,7 +117,7 @@ ># >gArmTokenSpaceGuid.PcdArmMachineType|0|UINT32|0x001E ># The compressed Linux kernel is expected to be under 128MB from the > beginning of the System Memory > - > gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0800|UINT32|0x001F > + > gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0840|UINT32|0x001F^M ># Maximum file size for TFTP servers that do not support 'tsize' > extension >gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x0100|UINT32|0x > > @@ -159,7 +159,7 @@ ># If the fixed FDT address is not available, then it should be loaded > below the kernel. ># The recommendation from the Linux kernel is to have the FDT below 16KB. ># (see the kernel doc: Documentation/arm/Booting) > - gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x0023 > + gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x0840|UINT32|0x0023^M ># The FDT blob must be loaded at a 64bit aligned address. >gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x0026 > > > Of course, the comments will have to change too: "under 128MB" => "above > 128MiB" and there is no recommendation for the device tree to be < 16KB. > > Unless I get further comment, I'll submit a v2 patch as above with the > comments updated. > > > > > > > BTW it seems odd for the LinuxLoader - which is now a separate EFI > > application - to use fixed PCDs to parametrise its behavior. I think > > it would be justified to hardcode the recommended behavior as per the > > Linux/ARM boot protocol right into the LinuxLoader binary. > > > > -- > > Ard. > > > > > > > > > > >> > > >> -- > > >> Ard. > > >> > > >> > > >> > This email thread explains that the device tree should be placed
Re: [edk2] [PATCH] ArmPkg: Move FDT offset higher in RAM
On 28 July 2015 at 10:26, Ard Biesheuvel wrote: > On 28 July 2015 at 11:01, Ryan Harkin wrote: > > [+ Tixy as he's interested in making sure UEFI follows the Linux > > requirements] > > > > On 28 July 2015 at 07:39, Ard Biesheuvel > wrote: > >> > >> On 27 July 2015 at 22:42, Ryan Harkin wrote: > >> > Device tree files in recent kernels (eg. Linux 4.2) can be >16KB. > >> > > >> > The max offset of 0x4000 meant that the device tree would be allocated > >> > at a "random address", which more often than not was above the > >> > recommended 128MiB boundary. > >> > > >> > >> From Documentation/arm/Booting: > >> > >> """ > >> 4b. Setup the device tree > >> ... > >> A safe location is just above the 128MiB boundary from start of RAM. > >> """ > >> > >> i.e., the documented protocol explicitly suggests using an address > 128 > >> MB. > >> So what exactly goes wrong if you load it at a random address? > > > > > > For some reason, I've been reading this as "before" 128MiB. How strange > of > > me. > > > > The advice I was following was from the bottom of the email thread where > > Nicolas Mitre says: > > > > "You can therefore load everything (zImage, initrd, DTB) sequentially > > from the 32MB mark in RAM and be safe." > > > > But mostly, I was trying to keep the bottom 32MB unused. > > > > Yes, I think that is the primary requirement here. > > > We don't have the option to load sequentially from 32MB unless I change > the > > code a lot more. I've already tried a hack that placed the 3 files > > sequentially from 0x8200 on TC2 and it works well, although it's > > technically wrong because I didn't explicity reserve memory in those > areas > > to stop UEFI from using it. > > > > I'll try changing the max offsets to be all above 128MiB and see if it > still > > works. As Tixy pointed out to me, the problem I had with the Linux > Loader's > > "random address" for the DTB is that it was always in the same region > that > > Linux reserves for CMA. And I think that starts before the DTB is > finished > > with. > > > > I think we could simply raise your max address limit to 132 MB: by the > looks of it, that is the maximum size the current kernel code will > ever be able to support since it uses two adjacent sections to map the > FDT, and sections are 2 MB at most when using long descriptors. > I've tested it with a patch to change the max offsets to 0x8400 and it works well. My hacked in debug shows: linux: address 0x87FD2000 linux: length 0x42D248 fdt:address 0x87E6E000 fdt:length 0x3FFC initrd: address 0x87E73000 initrd: length 0x15E600 >From this patch: diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec index b30de91..d5b930a 100644 --- a/ArmPkg/ArmPkg.dec +++ b/ArmPkg/ArmPkg.dec @@ -117,7 +117,7 @@ # gArmTokenSpaceGuid.PcdArmMachineType|0|UINT32|0x001E # The compressed Linux kernel is expected to be under 128MB from the beginning of the System Memory - gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0800|UINT32|0x001F + gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0840|UINT32|0x001F^M # Maximum file size for TFTP servers that do not support 'tsize' extension gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x0100|UINT32|0x @@ -159,7 +159,7 @@ # If the fixed FDT address is not available, then it should be loaded below the kernel. # The recommendation from the Linux kernel is to have the FDT below 16KB. # (see the kernel doc: Documentation/arm/Booting) - gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x0023 + gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x0840|UINT32|0x0023^M # The FDT blob must be loaded at a 64bit aligned address. gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x0026 Of course, the comments will have to change too: "under 128MB" => "above 128MiB" and there is no recommendation for the device tree to be < 16KB. Unless I get further comment, I'll submit a v2 patch as above with the comments updated. > > BTW it seems odd for the LinuxLoader - which is now a separate EFI > application - to use fixed PCDs to parametrise its behavior. I think > it would be justified to hardcode the recommended behavior as per the > Linux/ARM boot protocol right into the LinuxLoader binary. > > -- > Ard. > > > > > > >> > >> -- > >> Ard. > >> > >> > >> > This email thread explains that the device tree should be placed > higher > >> > in RAM: > >> > > >> > > >> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/187476.html > >> > > >> > It also explaines that the kernel may use memory in the 16-32KB range > >> > and that a zImage will by default be uncompressed to an offset of > 32KB. > >> > > >> > Setting the FDT max offset at 128MiB will allow UEFI to place it > higher > >> > up in memory, thus avoiding the problems with it being loaded to a > >> > random address. > >> > > >> > With this patch, by using AllocateMaxAdress, where possible the Linux > >> > Loader will place the FDT,
Re: [edk2] [PATCH 2/2] CryptoPkg/OpensslLib: Undefine NO_BUILTIN_VA_FUNCS to fix varargs breakage
On Tue, 2015-07-28 at 01:45 +, Long, Qin wrote: > Reviewed-by: Qin Long > > And Ersek, could you kindly help to double-check it will not break > any shim scenario? That would be very much appreciated; thanks. I have done *no* testing other than build testing so far. It would also be useful to test with the clock set deliberately wrong, after my 'Remove OpenSSL hack and manually ignore validity time range' patch: http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/9b89269c Note that all up to the final 'OpenSSL HEAD WIP' patch ought to work with the existing 1.0.2d support too. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPkg: Move FDT offset higher in RAM
On 28 July 2015 at 11:01, Ryan Harkin wrote: > [+ Tixy as he's interested in making sure UEFI follows the Linux > requirements] > > On 28 July 2015 at 07:39, Ard Biesheuvel wrote: >> >> On 27 July 2015 at 22:42, Ryan Harkin wrote: >> > Device tree files in recent kernels (eg. Linux 4.2) can be >16KB. >> > >> > The max offset of 0x4000 meant that the device tree would be allocated >> > at a "random address", which more often than not was above the >> > recommended 128MiB boundary. >> > >> >> From Documentation/arm/Booting: >> >> """ >> 4b. Setup the device tree >> ... >> A safe location is just above the 128MiB boundary from start of RAM. >> """ >> >> i.e., the documented protocol explicitly suggests using an address > 128 >> MB. >> So what exactly goes wrong if you load it at a random address? > > > For some reason, I've been reading this as "before" 128MiB. How strange of > me. > > The advice I was following was from the bottom of the email thread where > Nicolas Mitre says: > > "You can therefore load everything (zImage, initrd, DTB) sequentially > from the 32MB mark in RAM and be safe." > > But mostly, I was trying to keep the bottom 32MB unused. > Yes, I think that is the primary requirement here. > We don't have the option to load sequentially from 32MB unless I change the > code a lot more. I've already tried a hack that placed the 3 files > sequentially from 0x8200 on TC2 and it works well, although it's > technically wrong because I didn't explicity reserve memory in those areas > to stop UEFI from using it. > > I'll try changing the max offsets to be all above 128MiB and see if it still > works. As Tixy pointed out to me, the problem I had with the Linux Loader's > "random address" for the DTB is that it was always in the same region that > Linux reserves for CMA. And I think that starts before the DTB is finished > with. > I think we could simply raise your max address limit to 132 MB: by the looks of it, that is the maximum size the current kernel code will ever be able to support since it uses two adjacent sections to map the FDT, and sections are 2 MB at most when using long descriptors. BTW it seems odd for the LinuxLoader - which is now a separate EFI application - to use fixed PCDs to parametrise its behavior. I think it would be justified to hardcode the recommended behavior as per the Linux/ARM boot protocol right into the LinuxLoader binary. -- Ard. > > >> >> -- >> Ard. >> >> >> > This email thread explains that the device tree should be placed higher >> > in RAM: >> > >> > >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/187476.html >> > >> > It also explaines that the kernel may use memory in the 16-32KB range >> > and that a zImage will by default be uncompressed to an offset of 32KB. >> > >> > Setting the FDT max offset at 128MiB will allow UEFI to place it higher >> > up in memory, thus avoiding the problems with it being loaded to a >> > random address. >> > >> > With this patch, by using AllocateMaxAdress, where possible the Linux >> > Loader will place the FDT, initrd and kernel at the top of the 128MiB >> > range, which also allows for more efficient zImage uncompression, as per >> > the above thread. >> > >> > Contributed-under: TianoCore Contribution Agreement 1.0 >> > Signed-off-by: Ryan Harkin >> > --- >> > ArmPkg/ArmPkg.dec | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec >> > index da0c8a9..67c8cc9 100644 >> > --- a/ArmPkg/ArmPkg.dec >> > +++ b/ArmPkg/ArmPkg.dec >> > @@ -158,7 +158,7 @@ >> ># If the fixed FDT address is not available, then it should be loaded >> > below the kernel. >> ># The recommendation from the Linux kernel is to have the FDT below >> > 16KB. >> ># (see the kernel doc: Documentation/arm/Booting) >> > - gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x0023 >> > + >> > gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x0800|UINT32|0x0023 >> ># The FDT blob must be loaded at a 64bit aligned address. >> >gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x0026 >> > >> > -- >> > 2.1.0 >> > > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] OpenSSL HEAD WIP
On Tue, 2015-07-28 at 08:55 +, Long, Qin wrote: > > The instructions will be: > > - extract tarball > > - copy opensslconf.h to $(OPENSSL_PATH)/include/openssl/opensslconf.h > > > > Unless you want to put it in CryptoPkg/Include/openssl/ and you're *sure* > > it'll always get included before the tarball's version in $(OPENSSL_PATH)? > > That would avoid the 'copy' step, but doesn't really fill me with joy... > > but I > > suppose we could add something in OpensslSupport.h to #error if the wrong > > one ever does get included? > > > > No. If the new OPENSSL release will put all header files in > $(OPENSSL_PATH)/include/openssl, > Then I prefer to remove our include path. It looks cleaner. Good. That is the correct answer :) Although we can't kill our own include path *entirely*. We have all those things like which include OpensslSupport.h for the benefit of OpenSSL. Now that we're properly using OPENSSL_SYS_UEFI instead of OPENSSL_SYS_UWIN, we can go through the OpenSSL code and eliminate a lot of those too. But let's get the first bits merged first. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPkg: Move FDT offset higher in RAM
[+ Tixy as he's interested in making sure UEFI follows the Linux requirements] On 28 July 2015 at 07:39, Ard Biesheuvel wrote: > > On 27 July 2015 at 22:42, Ryan Harkin wrote: > > Device tree files in recent kernels (eg. Linux 4.2) can be >16KB. > > > > The max offset of 0x4000 meant that the device tree would be allocated > > at a "random address", which more often than not was above the > > recommended 128MiB boundary. > > > > From Documentation/arm/Booting: > > """ > 4b. Setup the device tree > ... > A safe location is just above the 128MiB boundary from start of RAM. > """ > > i.e., the documented protocol explicitly suggests using an address > 128 MB. > So what exactly goes wrong if you load it at a random address? For some reason, I've been reading this as "before" 128MiB. How strange of me. The advice I was following was from the bottom of the email thread where Nicolas Mitre says: "You can therefore load everything (zImage, initrd, DTB) sequentially from the 32MB mark in RAM and be safe." But mostly, I was trying to keep the bottom 32MB unused. We don't have the option to load sequentially from 32MB unless I change the code a lot more. I've already tried a hack that placed the 3 files sequentially from 0x8200 on TC2 and it works well, although it's technically wrong because I didn't explicity reserve memory in those areas to stop UEFI from using it. I'll try changing the max offsets to be all above 128MiB and see if it still works. As Tixy pointed out to me, the problem I had with the Linux Loader's "random address" for the DTB is that it was always in the same region that Linux reserves for CMA. And I think that starts before the DTB is finished with. > -- > Ard. > > > > This email thread explains that the device tree should be placed higher > > in RAM: > > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/187476.html > > > > It also explaines that the kernel may use memory in the 16-32KB range > > and that a zImage will by default be uncompressed to an offset of 32KB. > > > > Setting the FDT max offset at 128MiB will allow UEFI to place it higher > > up in memory, thus avoiding the problems with it being loaded to a > > random address. > > > > With this patch, by using AllocateMaxAdress, where possible the Linux > > Loader will place the FDT, initrd and kernel at the top of the 128MiB > > range, which also allows for more efficient zImage uncompression, as per > > the above thread. > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Ryan Harkin > > --- > > ArmPkg/ArmPkg.dec | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec > > index da0c8a9..67c8cc9 100644 > > --- a/ArmPkg/ArmPkg.dec > > +++ b/ArmPkg/ArmPkg.dec > > @@ -158,7 +158,7 @@ > ># If the fixed FDT address is not available, then it should be loaded > below the kernel. > ># The recommendation from the Linux kernel is to have the FDT below > 16KB. > ># (see the kernel doc: Documentation/arm/Booting) > > - gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x0023 > > + > gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x0800|UINT32|0x0023 > ># The FDT blob must be loaded at a 64bit aligned address. > >gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x0026 > > > > -- > > 2.1.0 > > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] MdeModulePkg: Include CapsuleX64 in MdeModulePkg.dsc [Components.X64]
It was forgotten to be included in MdeModulePkg.dsc when created. Cc: Feng Tian Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- MdeModulePkg/MdeModulePkg.dsc | 4 1 file changed, 4 insertions(+) diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc index 3537ca8..be67e9d 100644 --- a/MdeModulePkg/MdeModulePkg.dsc +++ b/MdeModulePkg/MdeModulePkg.dsc @@ -394,3 +394,7 @@ [Components.IA32, Components.X64] MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableSmm/FirmwarePerformanceSmm.inf MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.inf + +[Components.X64] + MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf + -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] OpenSSL HEAD WIP
> -Original Message- > From: David Woodhouse [mailto:dw...@infradead.org] > Sent: Tuesday, July 28, 2015 4:23 PM > To: Long, Qin; Laszlo Ersek; edk2-de...@ml01.01.org > Subject: Re: [edk2] [RFC] OpenSSL HEAD WIP > > On Tue, 2015-07-28 at 08:08 +, Long, Qin wrote: > > This sounds good. > > Where this new-generated opensslconf.h will be placed? In > > /openssl/crypto/ or EDKII-package include path? We still need one > > script to install / replace this file? > > It looks like the tarball releases of OpenSSL contain a version of > opensslconf.h — which we were previously patching, for the 1.0.2d and > earlier tarballs. > > So I think it's best for us to drop our pre-prepared version over the > top of that one. It's actually in openssl/include/ now instead of > openssl/crypto/ — all the header files moved, remember. > > > > The instructions will be: > - extract tarball > - copy opensslconf.h to $(OPENSSL_PATH)/include/openssl/opensslconf.h > > Unless you want to put it in CryptoPkg/Include/openssl/ and you're *sure* > it'll always get included before the tarball's version in $(OPENSSL_PATH)? > That would avoid the 'copy' step, but doesn't really fill me with joy... but I > suppose we could add something in OpensslSupport.h to #error if the wrong > one ever does get included? > No. If the new OPENSSL release will put all header files in $(OPENSSL_PATH)/include/openssl, Then I prefer to remove our include path. It looks cleaner. > > > > > > Actually, aren't the only things in OPENSSL_FLAGS now MSFT > > > > > > -specific anyway? > > > > > > I'll leave that question hanging there. In fact I think there's some > > > scope for cleaning up all of the cflags definitions at the end of the > > > file. > > > > In fact, it's not MSFT-specific flags in OPENSSL_FLAGS. > > Isn't it? All we have left is: > > DEFINE OPENSSL_FLAGS = -D_CRT_SECURE_NO_DEPRECATE - > D_CRT_NONSTDC_NO_DEPRECATE > > Can that not be moved to the MSFT compiler flags? I'm fairly sure it > doesn't do anything in GCC! :) > > I'd also quite like to understand the various -U_WIN32 and similar that > we have, even for GCC. Was that because we might be building with a > MinGW toolchain? And because OpenSSL would do something different and > wrong if it saw _WIN32/_WIN32/_MSC_VER defined? > > I'd like to fix those *properly* in OpenSSL in the case that > OPENSSL_SYS_UEFI is defined, rather than having to undefine them on the > command line. > > But again, that's something that can wait until the first pass is done. > > I'd *also* like to see if we can eliminate some of those compiler > warnings. Isn't it rather scary that we have to build the crypto > package with various compiler warnings *disabled* because otherwise the > build breaks? Think about that for a moment... :) > The history is: we just enabled the Windows VS build in the beginning, and put almost all flags in the FALGS. When GCC was enabled after that, those flags were kept simply. :-) And for those usages (such as _WIN32), it's because we would like to leverage some OPENSSL_SYSNAME_UWIN's configurations, but we are using the source directly without any configuration steps. Then some flags were added directly. Yes, they are historical issues. It really needs some cleaning-ups. :-) > > -- > David WoodhouseOpen Source Technology Centre > david.woodho...@intel.com Intel Corporation ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch] MdeModulePkg: Fix the issue cannot boot to UEFI Network
I will update it ,thanks
-Original Message-
From: Fu, Siyuan
Sent: Tuesday, July 28, 2015 4:49 PM
To: Zhang, Lubo; edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin
Subject: RE: [patch] MdeModulePkg: Fix the issue cannot boot to UEFI Network
Patch is good, please remember to update the copyright year when commit it.
Reviewed-by: Fu Siyuan
-Original Message-
From: Zhang, Lubo
Sent: Tuesday, July 28, 2015 4:47 PM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan; Ye, Ting; Wu, Jiaxin
Subject: [patch] MdeModulePkg: Fix the issue cannot boot to UEFI Network
DHCP4 service allows only one of its children to be configured in the active
state,If the DHCP4 D.O.R.A started by IP4 auto configuration and has not been
completed, the Dhcp4 state machine will not be in the right state for the PXE
to start a new round D.O.R.A.
so we need to switch it's policy to static.
Cc: Fu Siyuan
Cc: Ye Ting
CC: Wu Jiaxin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
.../Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c | 47 ++
.../Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h | 13 ++
.../Universal/Network/UefiPxeBcDxe/PxeBcDriver.c | 11 +
.../Universal/Network/UefiPxeBcDxe/PxeBcImpl.c | 11 +
.../Universal/Network/UefiPxeBcDxe/PxeBcImpl.h | 2 +
.../Network/UefiPxeBcDxe/UefiPxeBcDxe.inf | 1 +
6 files changed, 85 insertions(+)
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
index 1293f67..85155b1 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
@@ -645,10 +645,57 @@ PxeBcCacheDhcpOffer (
// Count the accepted offers.
//
Private->NumOffers++;
}
+/**
+ Switch the Ip4 policy to static.
+
+ @param[in] Private The pointer to PXEBC_PRIVATE_DATA.
+
+ @retval EFI_SUCCESS The policy is already configured to static.
+ @retval Others Other error as indicated..
+
+**/
+EFI_STATUS
+PxeBcSetIp4Policy (
+ IN PXEBC_PRIVATE_DATA*Private
+ )
+{
+ EFI_STATUS Status;
+ EFI_IP4_CONFIG2_PROTOCOL *Ip4Config2;
+ EFI_IP4_CONFIG2_POLICY Policy;
+ UINTNDataSize;
+
+ Ip4Config2 = Private->Ip4Config2;
+ DataSize = sizeof (EFI_IP4_CONFIG2_POLICY); Status =
+ Ip4Config2->GetData (
+ Ip4Config2,
+ Ip4Config2DataTypePolicy,
+ &DataSize,
+ &Policy
+ );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ if (Policy != Ip4Config2PolicyStatic) {
+Policy = Ip4Config2PolicyStatic;
+Status= Ip4Config2->SetData (
+ Ip4Config2,
+ Ip4Config2DataTypePolicy,
+ sizeof (EFI_IP4_CONFIG2_POLICY),
+ &Policy
+ );
+if (EFI_ERROR (Status)) {
+ return Status;
+}
+ }
+
+ return EFI_SUCCESS;
+}
+
/**
Select the specified proxy offer, such as BINL, DHCP_ONLY and so on.
If the proxy does not exist, try offers with bootfile.
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
index b56d10d..32a64df 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
@@ -378,10 +378,23 @@ PxeBcDhcpCallBack (
IN EFI_DHCP4_EVENT Dhcp4Event,
IN EFI_DHCP4_PACKET * Packet OPTIONAL,
OUT EFI_DHCP4_PACKET **NewPacket OPTIONAL
);
+/**
+ Switch the Ip4 policy to static.
+
+ @param[in] Private The pointer to PXEBC_PRIVATE_DATA.
+
+ @retval EFI_SUCCESS The policy is already configured to static.
+ @retval Others Other error as indicated..
+
+**/
+EFI_STATUS
+PxeBcSetIp4Policy (
+ IN PXEBC_PRIVATE_DATA*Private
+ );
/**
Discover the boot of service and initialize the vendor option if exists.
@param Private Pointer to PxeBc private data.
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
index 3c2437e..1b7577a 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
@@ -373,10 +373,21 @@ PxeBcDriverBindingStart (
NULL
);
if (EFI_ERROR (Status)) {
goto ON_ERROR;
}
+ //
+ // Locate Ip4->Ip4Config2 and store it for set IPv4 Policy.
+ //
+ Status = gBS->HandleProtocol (
+ ControllerHandle,
+ &gEfiIp4Config2ProtocolGuid,
+ (VOID **) &Private->Ip4Config2
+ );
+ if (EFI_E
Re: [edk2] [patch] MdeModulePkg/Usb: Adjust TPL to not block async transfer during usb enum.
Reviewed-by: Star Zeng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tian Feng Sent: Tuesday, July 28, 2015 1:41 PM To: Zeng, Star Cc: edk2-devel@lists.01.org; Tian, Feng Subject: [edk2] [patch] MdeModulePkg/Usb: Adjust TPL to not block async transfer during usb enum. EDKII usb stack is using a TPL_CALLBACK timer to monitor async transfer request and signal event if it's done. As usb enumeration and usb mass storage block i/o read/write runs on TPL_CALLBACK and TPL_NOTIFY level respectively, It blocks usb async transfer requests, usually usb mouse /use kb, getting time to run. Without this change, user couldn't get usb mouse/kb state in time (will show a little lag from UI view) when there is other usb transactions, such as a new usb device inserted. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Feng Tian --- MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c | 2 +- MdeModulePkg/Bus/Pci/UhciDxe/Uhci.c | 2 +- MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 2 +- MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c | 8 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c b/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c index 315f2cb..4e9e05f 100644 --- a/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c +++ b/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c @@ -1615,7 +1615,7 @@ EhcCreateUsb2Hc ( // Status = gBS->CreateEvent ( EVT_TIMER | EVT_NOTIFY_SIGNAL, - TPL_CALLBACK, + TPL_NOTIFY, EhcMonitorAsyncRequests, Ehc, &Ehc->PollTimer diff --git a/MdeModulePkg/Bus/Pci/UhciDxe/Uhci.c b/MdeModulePkg/Bus/Pci/UhciDxe/Uhci.c index ad9c85c..179e36c 100644 --- a/MdeModulePkg/Bus/Pci/UhciDxe/Uhci.c +++ b/MdeModulePkg/Bus/Pci/UhciDxe/Uhci.c @@ -1482,7 +1482,7 @@ UhciAllocateDev ( Status = gBS->CreateEvent ( EVT_TIMER | EVT_NOTIFY_SIGNAL, - TPL_CALLBACK, + TPL_NOTIFY, UhciMonitorAsyncReqList, Uhc, &Uhc->AsyncIntMonitor diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c index 6143b20..390ca0a 100644 --- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c +++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c @@ -1822,7 +1822,7 @@ XhcCreateUsbHc ( // Status = gBS->CreateEvent ( EVT_TIMER | EVT_NOTIFY_SIGNAL, - TPL_CALLBACK, + TPL_NOTIFY, XhcMonitorAsyncRequests, Xhc, &Xhc->PollTimer diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c index be11cc7..9d1bb25 100644 --- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c +++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c @@ -1,7 +1,7 @@ /** @file USB Mass Storage Driver that manages USB Mass Storage Device and produces Block I/O Protocol. -Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved. +Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved. This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License which accompanies this distribution. The full text of the license may be found at @@ -63,7 +63,7 @@ UsbMassReset ( // Raise TPL to TPL_NOTIFY to serialize all its operations // to protect shared data structures. // - OldTpl = gBS->RaiseTPL (TPL_NOTIFY); + OldTpl = gBS->RaiseTPL (TPL_CALLBACK); UsbMass = USB_MASS_DEVICE_FROM_BLOCK_IO (This); Status = UsbMass->Transport->Reset (UsbMass->Context, ExtendedVerification); @@ -117,7 +117,7 @@ UsbMassReadBlocks ( // Raise TPL to TPL_NOTIFY to serialize all its operations // to protect shared data structures. // - OldTpl = gBS->RaiseTPL (TPL_NOTIFY); + OldTpl = gBS->RaiseTPL (TPL_CALLBACK); UsbMass = USB_MASS_DEVICE_FROM_BLOCK_IO (This); Media = &UsbMass->BlockIoMedia; @@ -233,7 +233,7 @@ UsbMassWriteBlocks ( // Raise TPL to TPL_NOTIFY to serialize all its operations // to protect shared data structures. // - OldTpl = gBS->RaiseTPL (TPL_NOTIFY); + OldTpl = gBS->RaiseTPL (TPL_CALLBACK); UsbMass = USB_MASS_DEVICE_FROM_BLOCK_IO (This); Media = &UsbMass->BlockIoMedia; -- 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] MdeModulePkg: Fix the issue cannot boot to UEFI Network
Patch is good, please remember to update the copyright year when commit it.
Reviewed-by: Fu Siyuan
-Original Message-
From: Zhang, Lubo
Sent: Tuesday, July 28, 2015 4:47 PM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan; Ye, Ting; Wu, Jiaxin
Subject: [patch] MdeModulePkg: Fix the issue cannot boot to UEFI Network
DHCP4 service allows only one of its children to be configured in the active
state,If the DHCP4 D.O.R.A started by IP4 auto configuration and has not been
completed, the Dhcp4 state machine will not be in the right state for the PXE
to start a new round D.O.R.A.
so we need to switch it's policy to static.
Cc: Fu Siyuan
Cc: Ye Ting
CC: Wu Jiaxin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
.../Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c | 47 ++
.../Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h | 13 ++
.../Universal/Network/UefiPxeBcDxe/PxeBcDriver.c | 11 +
.../Universal/Network/UefiPxeBcDxe/PxeBcImpl.c | 11 +
.../Universal/Network/UefiPxeBcDxe/PxeBcImpl.h | 2 +
.../Network/UefiPxeBcDxe/UefiPxeBcDxe.inf | 1 +
6 files changed, 85 insertions(+)
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
index 1293f67..85155b1 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
@@ -645,10 +645,57 @@ PxeBcCacheDhcpOffer (
// Count the accepted offers.
//
Private->NumOffers++;
}
+/**
+ Switch the Ip4 policy to static.
+
+ @param[in] Private The pointer to PXEBC_PRIVATE_DATA.
+
+ @retval EFI_SUCCESS The policy is already configured to static.
+ @retval Others Other error as indicated..
+
+**/
+EFI_STATUS
+PxeBcSetIp4Policy (
+ IN PXEBC_PRIVATE_DATA*Private
+ )
+{
+ EFI_STATUS Status;
+ EFI_IP4_CONFIG2_PROTOCOL *Ip4Config2;
+ EFI_IP4_CONFIG2_POLICY Policy;
+ UINTNDataSize;
+
+ Ip4Config2 = Private->Ip4Config2;
+ DataSize = sizeof (EFI_IP4_CONFIG2_POLICY); Status =
+ Ip4Config2->GetData (
+ Ip4Config2,
+ Ip4Config2DataTypePolicy,
+ &DataSize,
+ &Policy
+ );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ if (Policy != Ip4Config2PolicyStatic) {
+Policy = Ip4Config2PolicyStatic;
+Status= Ip4Config2->SetData (
+ Ip4Config2,
+ Ip4Config2DataTypePolicy,
+ sizeof (EFI_IP4_CONFIG2_POLICY),
+ &Policy
+ );
+if (EFI_ERROR (Status)) {
+ return Status;
+}
+ }
+
+ return EFI_SUCCESS;
+}
+
/**
Select the specified proxy offer, such as BINL, DHCP_ONLY and so on.
If the proxy does not exist, try offers with bootfile.
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
index b56d10d..32a64df 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
@@ -378,10 +378,23 @@ PxeBcDhcpCallBack (
IN EFI_DHCP4_EVENT Dhcp4Event,
IN EFI_DHCP4_PACKET * Packet OPTIONAL,
OUT EFI_DHCP4_PACKET **NewPacket OPTIONAL
);
+/**
+ Switch the Ip4 policy to static.
+
+ @param[in] Private The pointer to PXEBC_PRIVATE_DATA.
+
+ @retval EFI_SUCCESS The policy is already configured to static.
+ @retval Others Other error as indicated..
+
+**/
+EFI_STATUS
+PxeBcSetIp4Policy (
+ IN PXEBC_PRIVATE_DATA*Private
+ );
/**
Discover the boot of service and initialize the vendor option if exists.
@param Private Pointer to PxeBc private data.
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
index 3c2437e..1b7577a 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
@@ -373,10 +373,21 @@ PxeBcDriverBindingStart (
NULL
);
if (EFI_ERROR (Status)) {
goto ON_ERROR;
}
+ //
+ // Locate Ip4->Ip4Config2 and store it for set IPv4 Policy.
+ //
+ Status = gBS->HandleProtocol (
+ ControllerHandle,
+ &gEfiIp4Config2ProtocolGuid,
+ (VOID **) &Private->Ip4Config2
+ );
+ if (EFI_ERROR (Status)) {
+goto ON_ERROR;
+ }
return EFI_SUCCESS;
ON_ERROR:
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
index 0c54f46..991a7be 100644
--- a/MdeM
[edk2] [patch] MdeModulePkg: Fix the issue cannot boot to UEFI Network
DHCP4 service allows only one of its children to be configured
in the active state,If the DHCP4 D.O.R.A started by IP4 auto
configuration and has not been completed, the Dhcp4 state machine
will not be in the right state for the PXE to start a new round D.O.R.A.
so we need to switch it's policy to static.
Cc: Fu Siyuan
Cc: Ye Ting
CC: Wu Jiaxin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
.../Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c | 47 ++
.../Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h | 13 ++
.../Universal/Network/UefiPxeBcDxe/PxeBcDriver.c | 11 +
.../Universal/Network/UefiPxeBcDxe/PxeBcImpl.c | 11 +
.../Universal/Network/UefiPxeBcDxe/PxeBcImpl.h | 2 +
.../Network/UefiPxeBcDxe/UefiPxeBcDxe.inf | 1 +
6 files changed, 85 insertions(+)
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
index 1293f67..85155b1 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
@@ -645,10 +645,57 @@ PxeBcCacheDhcpOffer (
// Count the accepted offers.
//
Private->NumOffers++;
}
+/**
+ Switch the Ip4 policy to static.
+
+ @param[in] Private The pointer to PXEBC_PRIVATE_DATA.
+
+ @retval EFI_SUCCESS The policy is already configured to static.
+ @retval Others Other error as indicated..
+
+**/
+EFI_STATUS
+PxeBcSetIp4Policy (
+ IN PXEBC_PRIVATE_DATA*Private
+ )
+{
+ EFI_STATUS Status;
+ EFI_IP4_CONFIG2_PROTOCOL *Ip4Config2;
+ EFI_IP4_CONFIG2_POLICY Policy;
+ UINTNDataSize;
+
+ Ip4Config2 = Private->Ip4Config2;
+ DataSize = sizeof (EFI_IP4_CONFIG2_POLICY);
+ Status = Ip4Config2->GetData (
+ Ip4Config2,
+ Ip4Config2DataTypePolicy,
+ &DataSize,
+ &Policy
+ );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ if (Policy != Ip4Config2PolicyStatic) {
+Policy = Ip4Config2PolicyStatic;
+Status= Ip4Config2->SetData (
+ Ip4Config2,
+ Ip4Config2DataTypePolicy,
+ sizeof (EFI_IP4_CONFIG2_POLICY),
+ &Policy
+ );
+if (EFI_ERROR (Status)) {
+ return Status;
+}
+ }
+
+ return EFI_SUCCESS;
+}
+
/**
Select the specified proxy offer, such as BINL, DHCP_ONLY and so on.
If the proxy does not exist, try offers with bootfile.
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
index b56d10d..32a64df 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.h
@@ -378,10 +378,23 @@ PxeBcDhcpCallBack (
IN EFI_DHCP4_EVENT Dhcp4Event,
IN EFI_DHCP4_PACKET * Packet OPTIONAL,
OUT EFI_DHCP4_PACKET **NewPacket OPTIONAL
);
+/**
+ Switch the Ip4 policy to static.
+
+ @param[in] Private The pointer to PXEBC_PRIVATE_DATA.
+
+ @retval EFI_SUCCESS The policy is already configured to static.
+ @retval Others Other error as indicated..
+
+**/
+EFI_STATUS
+PxeBcSetIp4Policy (
+ IN PXEBC_PRIVATE_DATA*Private
+ );
/**
Discover the boot of service and initialize the vendor option if exists.
@param Private Pointer to PxeBc private data.
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
index 3c2437e..1b7577a 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
@@ -373,10 +373,21 @@ PxeBcDriverBindingStart (
NULL
);
if (EFI_ERROR (Status)) {
goto ON_ERROR;
}
+ //
+ // Locate Ip4->Ip4Config2 and store it for set IPv4 Policy.
+ //
+ Status = gBS->HandleProtocol (
+ ControllerHandle,
+ &gEfiIp4Config2ProtocolGuid,
+ (VOID **) &Private->Ip4Config2
+ );
+ if (EFI_ERROR (Status)) {
+goto ON_ERROR;
+ }
return EFI_SUCCESS;
ON_ERROR:
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
index 0c54f46..991a7be 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
@@ -408,10 +408,21 @@ EfiPxeBcStart (
);
if (EFI_ERROR (Status)) {
goto ON_EXIT;
}
+ //
+ //DHCP4 service allows only one of its children to be configured in
+ //the active state,
Re: [edk2] [RFC] OpenSSL HEAD WIP
On Tue, 2015-07-28 at 08:08 +, Long, Qin wrote: > This sounds good. > Where this new-generated opensslconf.h will be placed? In > /openssl/crypto/ or EDKII-package include path? We still need one > script to install / replace this file? It looks like the tarball releases of OpenSSL contain a version of opensslconf.h — which we were previously patching, for the 1.0.2d and earlier tarballs. So I think it's best for us to drop our pre-prepared version over the top of that one. It's actually in openssl/include/ now instead of openssl/crypto/ — all the header files moved, remember. The instructions will be: - extract tarball - copy opensslconf.h to $(OPENSSL_PATH)/include/openssl/opensslconf.h Unless you want to put it in CryptoPkg/Include/openssl/ and you're *sure* it'll always get included before the tarball's version in $(OPENSSL_PATH)? That would avoid the 'copy' step, but doesn't really fill me with joy... but I suppose we could add something in OpensslSupport.h to #error if the wrong one ever does get included? > > > > > Actually, aren't the only things in OPENSSL_FLAGS now MSFT > > > > > -specific anyway? > > > > I'll leave that question hanging there. In fact I think there's some > > scope for cleaning up all of the cflags definitions at the end of the > > file. > > In fact, it's not MSFT-specific flags in OPENSSL_FLAGS. Isn't it? All we have left is: DEFINE OPENSSL_FLAGS = -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE Can that not be moved to the MSFT compiler flags? I'm fairly sure it doesn't do anything in GCC! :) I'd also quite like to understand the various -U_WIN32 and similar that we have, even for GCC. Was that because we might be building with a MinGW toolchain? And because OpenSSL would do something different and wrong if it saw _WIN32/_WIN32/_MSC_VER defined? I'd like to fix those *properly* in OpenSSL in the case that OPENSSL_SYS_UEFI is defined, rather than having to undefine them on the command line. But again, that's something that can wait until the first pass is done. I'd *also* like to see if we can eliminate some of those compiler warnings. Isn't it rather scary that we have to build the crypto package with various compiler warnings *disabled* because otherwise the build breaks? Think about that for a moment... :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] OpenSSL HEAD WIP
> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Tuesday, July 28, 2015 3:42 PM
> To: Long, Qin; Laszlo Ersek; edk2-de...@ml01.01.org
> Subject: Re: [edk2] [RFC] OpenSSL HEAD WIP
>
> On Tue, 2015-07-28 at 01:44 +, Long, Qin wrote:
> > > > Automatically generate the file list from running 'make files', and
> > > > also configure OpenSSL normally using its Configure script (with all
> > > > the no-xxx arguments that we require).
> > > >
> >
> > David, this configuration requires PERL to be installed, right?
>
> Yes. But remember, not for everyone. This is *only* for updating
> OpenSSL. We commit the resulting file list and opensslconf.h to the
> repository, and the Windows users can just build it that way.
>
> Not everyone needs to update to a *new* release of OpenSSL for
> themselves.
This sounds good.
Where this new-generated opensslconf.h will be placed? In /openssl/crypto/ or
EDKII-package include path? We still need one script to install / replace this
file?
>
> > > > Actually, aren't the only things in OPENSSL_FLAGS now MSFT
> > > > -specific anyway?
>
> I'll leave that question hanging there. In fact I think there's some
> scope for cleaning up all of the cflags definitions at the end of the
> file.
In fact, it's not MSFT-specific flags in OPENSSL_FLAGS.
No specific design on OPENSSL_FLAGS and OPENSSL_EXFLAGS before. EXFLAGS was
just added to make the initial definitions more short. :-)
Yes, I also would like to clean-up these flags, such as OS-related, feature
flags.
>
> >(Laszlo wrote):
> > > I'd feel somewhat safer if tvp was evaluated only once, something
> > > like:
> > >
> > > do {
> > > struct timeval *tv = (tvp);
> > >
> > > tv->tv_sec = time(NULL);
> > > tv->tv_usec = 0;
> > > } while (0)
> > >
> > > but, this is really minor.
>
> Actually I think I'd prefer to eliminate it completely. If you look,
> the only place it's used is crypto/rand/md_rand.c, in the
> ssleay_rand_bytes() function. We already have some platform ifdefs
> there, and 'tv' can be any datatype we like. So I was thinking of
> hooking it up to use something like AsmReadTsc() where that exists
> or is there something more generic that EDK2 provides?
>
> Having a gettimeofday() which returns zero for the tv_usec field is
> *utterly* pointless in this case since we've already stirred the result
> of time() into the mix. We're adding no *more* entropy with the
> gettimeofday() result.
>
> But I think there are a lot of our 'support' functions/macros — and
> even whole header files — which can slowly be eliminated once we have
> taught OpenSSL that it's building for EDK2. I was deliberately leaving
> that whole thing for later, once we have the basics merged.
>
Agree.
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com Intel Corporation
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block
Yes. I think BootServiceData is ok. If OVMF is built without SMRAM support, it's ovmf platform's responsibility to get it and save it into ACPI NVS. Jeff -Original Message- From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini Sent: Tuesday, July 28, 2015 3:34 PM To: Fan, Jeff; Laszlo Ersek; edk2-de...@ml01.01.org Cc: Chen Fan; Justen, Jordan L Subject: Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block On 28/07/2015 09:09, Fan, Jeff wrote: > I did not receive the patch 42. I have only gotten 38,39,40,41. > > OK, If this mtrr setting stored in ACPI NVS is for CpuS3DataDxe to > store into SMRAM, that's fine. > > Then, another question, what's requirement to save MTRR setting into > ACPI NVS on this case? And need one PCD to switch on/off it? Do you mean it could be BootServicesData? I'll let Laszlo answer this. The PCD is there to skip this code if OVMF is built without SMRAM support. Paolo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] OpenSSL HEAD WIP
On Tue, 2015-07-28 at 01:44 +, Long, Qin wrote:
> > > Automatically generate the file list from running 'make files', and
> > > also configure OpenSSL normally using its Configure script (with all
> > > the no-xxx arguments that we require).
> > >
>
> David, this configuration requires PERL to be installed, right?
Yes. But remember, not for everyone. This is *only* for updating
OpenSSL. We commit the resulting file list and opensslconf.h to the
repository, and the Windows users can just build it that way.
Not everyone needs to update to a *new* release of OpenSSL for
themselves.
> > > Actually, aren't the only things in OPENSSL_FLAGS now MSFT
> > > -specific anyway?
I'll leave that question hanging there. In fact I think there's some
scope for cleaning up all of the cflags definitions at the end of the
file.
>(Laszlo wrote):
> > I'd feel somewhat safer if tvp was evaluated only once, something
> > like:
> >
> > do {
> > struct timeval *tv = (tvp);
> >
> > tv->tv_sec = time(NULL);
> > tv->tv_usec = 0;
> > } while (0)
> >
> > but, this is really minor.
Actually I think I'd prefer to eliminate it completely. If you look,
the only place it's used is crypto/rand/md_rand.c, in the
ssleay_rand_bytes() function. We already have some platform ifdefs
there, and 'tv' can be any datatype we like. So I was thinking of
hooking it up to use something like AsmReadTsc() where that exists
or is there something more generic that EDK2 provides?
Having a gettimeofday() which returns zero for the tv_usec field is
*utterly* pointless in this case since we've already stirred the result
of time() into the mix. We're adding no *more* entropy with the
gettimeofday() result.
But I think there are a lot of our 'support' functions/macros — and
even whole header files — which can slowly be eliminated once we have
taught OpenSSL that it's building for EDK2. I was deliberately leaving
that whole thing for later, once we have the basics merged.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block
I did not receive the patch 42. I have only gotten 38,39,40,41. OK, If this mtrr setting stored in ACPI NVS is for CpuS3DataDxe to store into SMRAM, that's fine. Then, another question, what's requirement to save MTRR setting into ACPI NVS on this case? And need one PCD to switch on/off it? Jeff -Original Message- From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini Sent: Tuesday, July 28, 2015 2:52 PM To: Fan, Jeff; Laszlo Ersek; edk2-de...@ml01.01.org Cc: Chen Fan; Justen, Jordan L Subject: Re: [edk2] [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block On 28/07/2015 08:05, Fan, Jeff wrote: > Ersek, > > I have one comment for PCD PcdCpuSyncMtrrToAcpiNvs. > > I knew OvmfPkg implemented LockBox based on ACPI NVS. Saving MTRR setting in > AcpiNVS is OK for OvmfPkg. If I understand correctly what you are saying, the AcpiNVS block is only used for communication from CpuDxe to CpuS3DataDxe in patch 42. CpuS3DataDxe saves the MTRR in SMRAM during SmmReadyToLockEventNotify() and PiSmmCpuDxeSmm restores them during S3 resume. So Laszlo's patches are doing exactly the "safe" thing, even though they are not using LockBox. > But other platform may want to use more safe solution to save MTRR based on > in SMM. > > I think that, for long term, saving MTRR setting by LockBox instead of > using ACPI NVS memory directly. Then, different platforms could > provide the different LockBox solutions. For short term, still saving > MTRR setting in ACPI NVS in CpuDxe, and removing this PCD. That means > we could CpuDxe implementation to use the long term solution in the > future and needn't to remove one un-used PCD more. The PCD is consumed in CPUS3DataDxe. Paolo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
