Date   

Re: [PATCH] OvmfPkg/Bhyve: clean up TPM_ENABLE remnants

Laszlo Ersek
 

On 06/12/21 22:43, Rebecca Cran wrote:
TPM support hasn't been tested and any lines in the .dsc and .fdf files
that appear to show support are bogus. Remove them.

This fixes https://bugzilla.tianocore.org/show_bug.cgi?id=3354 .

Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
---
OvmfPkg/Bhyve/BhyveX64.dsc | 64 --------------------
OvmfPkg/Bhyve/BhyveX64.fdf | 15 -----
2 files changed, 79 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index d8792812ab..cbf896e89b 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -31,8 +31,6 @@
DEFINE SECURE_BOOT_ENABLE = FALSE
DEFINE SMM_REQUIRE = FALSE
DEFINE SOURCE_DEBUG_ENABLE = FALSE
- DEFINE TPM_ENABLE = FALSE
- DEFINE TPM_CONFIG_ENABLE = FALSE

#
# Network definition
@@ -221,16 +219,8 @@
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf

-
-!if $(TPM_ENABLE) == TRUE
- Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
- Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
- Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
- TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
-!else
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
-!endif

[LibraryClasses.common]
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -292,11 +282,6 @@
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf

-!if $(TPM_ENABLE) == TRUE
- BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
- Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
-!endif
-
MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf

[LibraryClasses.common.DXE_CORE]
@@ -366,9 +351,6 @@
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
MpInitLib|UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.inf
-!if $(TPM_ENABLE) == TRUE
- Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
-!endif

[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -563,22 +545,12 @@

gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00

-!if $(TPM_ENABLE) == TRUE
- gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
-!endif
-
# MdeModulePkg resolution sets up the system display resolution
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|0
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|0
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow|0
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn|0

-[PcdsDynamicHii]
-!if $(TPM_ENABLE) == TRUE && $(TPM_CONFIG_ENABLE) == TRUE
- gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer|L"TCG2_VERSION"|gTcg2ConfigFormSetGuid|0x0|"1.3"|NV,BS
- gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev|L"TCG2_VERSION"|gTcg2ConfigFormSetGuid|0x8|3|NV,BS
-!endif
-
################################################################################
#
# Components Section - list of all EDK II Modules needed by this Platform.
@@ -618,19 +590,6 @@
<LibraryClasses>
}

-!if $(TPM_ENABLE) == TRUE
- OvmfPkg/Bhyve/Tcg/Tcg2Config/Tcg2ConfigPei.inf
- SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf {
- <LibraryClasses>
- HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
- NULL|SecurityPkg/Library/HashInstanceLibSm3/HashInstanceLibSm3.inf
- }
-!endif
-
#
# DXE Phase modules
#
@@ -653,9 +612,6 @@
<LibraryClasses>
!if $(SECURE_BOOT_ENABLE) == TRUE
NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
-!endif
-!if $(TPM_ENABLE) == TRUE
- NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf
!endif
}

@@ -841,23 +797,3 @@
NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
}

-
- #
- # TPM support
- #
-!if $(TPM_ENABLE) == TRUE
- SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
- <LibraryClasses>
- Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
- NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf
- HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
- NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
- NULL|SecurityPkg/Library/HashInstanceLibSm3/HashInstanceLibSm3.inf
- }
-!if $(TPM_CONFIG_ENABLE) == TRUE
- SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
-!endif
-!endif
diff --git a/OvmfPkg/Bhyve/BhyveX64.fdf b/OvmfPkg/Bhyve/BhyveX64.fdf
index 3eff36dac1..fbd63a395a 100644
--- a/OvmfPkg/Bhyve/BhyveX64.fdf
+++ b/OvmfPkg/Bhyve/BhyveX64.fdf
@@ -158,11 +158,6 @@ INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
INF OvmfPkg/Bhyve/SmmAccess/SmmAccessPei.inf
!endif

-!if $(TPM_ENABLE) == TRUE
-INF OvmfPkg/Bhyve/Tcg/Tcg2Config/Tcg2ConfigPei.inf
-INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
-!endif
-
################################################################################

[FV.DXEFV]
@@ -333,16 +328,6 @@ INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
!endif

-#
-# TPM support
-#
-!if $(TPM_ENABLE) == TRUE
-INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
-!if $(TPM_CONFIG_ENABLE) == TRUE
-INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
-!endif
-!endif
-
################################################################################

[FV.FVMAIN_COMPACT]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>


Re: [PATCH] OvmfPkg/Bhyve: clean up TPM_ENABLE remnants

Michael D Kinney
 

Hi,

I have checked in a new Mergify configuration file into edk2-codereview. Have not had a chance to
test it yet, but I think it has all the updates that have been discussed:

1) Allows non EDK II Maintainers to open a PR and for an EDK II Maintainers to set labels.
2) Removed status check names from Mergify config and use the status checks listed in branch protections
3) Simplify the number of rules in Mergify config
4) Add support for 'main' branch.
5) Optional support for auto-rebase using 'auto-rebase' label.

https://github.com/tianocore/edk2-codereview/blob/master/.mergify/config.yml

Please try doing some additional tests to see if it behaves as expected.

I will get back to this on Monday or Tuesday next week and will start preparing a
few code reviews to update the edk2 repo with these changes.

Thanks,

Mike

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Wednesday, June 23, 2021 6:21 PM
To: devel@edk2.groups.io; gaoliming@byosoft.com.cn; lersek@redhat.com; spbrogan@outlook.com; ardb@kernel.org; Kinney,
Michael D <michael.d.kinney@intel.com>
Cc: 'Peter Grehan' <grehan@freebsd.org>; 'Ard Biesheuvel' <ardb+tianocore@kernel.org>; Justen, Jordan L
<jordan.l.justen@intel.com>; 'Sean Brogan' <sean.brogan@microsoft.com>; 'Rebecca Cran' <rebecca@bsdio.com>
Subject: RE: [edk2-devel] [PATCH] OvmfPkg/Bhyve: clean up TPM_ENABLE remnants

Liming,

Yes. I am working on a configuration with will keep the current 'push' behavior
and add the 'auto-rebase' option.

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of gaoliming
Sent: Wednesday, June 23, 2021 6:10 PM
To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>; lersek@redhat.com; spbrogan@outlook.com;
ardb@kernel.org
Cc: 'Peter Grehan' <grehan@freebsd.org>; 'Ard Biesheuvel' <ardb+tianocore@kernel.org>; Justen, Jordan L
<jordan.l.justen@intel.com>; 'Sean Brogan' <sean.brogan@microsoft.com>; 'Rebecca Cran' <rebecca@bsdio.com>
Subject: 回复: [edk2-devel] [PATCH] OvmfPkg/Bhyve: clean up TPM_ENABLE remnants

Mike:
If 'auto-rebase' label is not set, the behavior is still same to current one. Right?
If yes, I agree this proposal. The maintainer can optionally set 'auto-rebase'.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Michael D
Kinney
发送时间: 2021年6月24日 6:08
收件人: devel@edk2.groups.io; lersek@redhat.com; spbrogan@outlook.com;
ardb@kernel.org; Kinney, Michael D <michael.d.kinney@intel.com>
抄送: Peter Grehan <grehan@freebsd.org>; Ard Biesheuvel
<ardb+tianocore@kernel.org>; Justen, Jordan L <jordan.l.justen@intel.com>;
Sean Brogan <sean.brogan@microsoft.com>; Rebecca Cran
<rebecca@bsdio.com>
主题: Re: [edk2-devel] [PATCH] OvmfPkg/Bhyve: clean up TPM_ENABLE
remnants

Hi Laszlo,

I understand your point.

I am trying to balance the ease of use for developers, reducing overhead for
maintainers, and
prevent bad commits.

I think you are saying that you want to make sure a maintainer carefully
reviews changes
across multiple PRs that are in the same area of code. The CI checks will of
course make
sure the code builds and passes the basic boot tests, but those tests do not
have full
coverage so an interaction issue between two PRs that pass build and boot
but have
unintended behavior side effects are what require detailed manual review.

I am going to remove the auto-rebase by default and add a optional label that
can
be set by a maintainer to enable auto-rebase. If a maintainer is confident
that
a set of PRs being submitted at the same time with the 'push' label are
independent,
then the maintainer can also set 'auto-rebase'. If they are not confident,
then
they can send PRs one at a time with only 'push' label and manually rebase
each
additional PR and review the manual rebase to make sure there are no
unintended
side effects.

Any objections to this direction?

Thanks,

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Wednesday, June 23, 2021 12:45 PM
To: Kinney, Michael D <michael.d.kinney@intel.com>;
devel@edk2.groups.io; spbrogan@outlook.com; ardb@kernel.org
Cc: Peter Grehan <grehan@freebsd.org>; Ard Biesheuvel
<ardb+tianocore@kernel.org>; Justen, Jordan L
<jordan.l.justen@intel.com>; Sean Brogan <sean.brogan@microsoft.com>;
Rebecca Cran <rebecca@bsdio.com>
Subject: Re: [edk2-devel] [PATCH] OvmfPkg/Bhyve: clean up TPM_ENABLE
remnants

On 06/23/21 20:44, Kinney, Michael D wrote:

Hi Laszlo,

Thank you for the test case.

I created 2 PRs against edk2-codereview using your patches.
I made minor update to commit messages to pass patch check.

https://github.com/tianocore/edk2-codereview/pull/18
https://github.com/tianocore/edk2-codereview/pull/19

Found another issue with PatchCheck for the Mergify merge commit and
fixed that.

Mergify did process #18 and merged it in after passing all CI. Mergify
rebased #19 successfully and merged it after passing all CI. I do not
think this was your expected result.
Indeed, my "desired" result at least would have been for mergify to
reject the rebase.

I looked more closely at the patches you provided. They were not
overlapping in the lines of Readme.rst. This is why no merge conflict
was detected.
More precisely, a contextual conflict *was* determined between the
patches, but that conflict was auto-resolved.

This is risky when done in an automated fashion. It is an extremely
convenient feature of git, when used interactively; that is, when the
auto-merge (automatic conflict resolution) is semantically verified by a
human. Git takes away the chore of conflict resolution, presents a
"likely good" end result, and a human only needs to *look* at the end
result, not *implement* it.

But that "human look" is exactly what's missing from mergify.

Basically what I'd like for mergify is to turn off automatic conflict
resolution.

More or less, speaking in terms of the stand-alone "patch" utility
<https://man7.org/linux/man-pages/man1/patch.1.html>, my preference is
to set the "fuzz factor" to zero.


One way a human reviews such context differences is with git-range-diff.
Continuing my previous example commands:

$ git range-diff --color master..b2 b1..b2-rebase

1: 02dc81e58bd6 ! 1: 2cf39d4b1790 world
@@ -6,8 +6,8 @@
--- a/ReadMe.rst
+++ b/ReadMe.rst
@@
-
A modern, feature-rich, cross-platform firmware development
+ HELLO
environment for the UEFI and PI specifications from www.uefi.org.
+ WORLD

This output shows that the "world" addition is the same (it is identical
between pre-rebase and post-rebase in the commit), but the context has
changed. During the rebase, the leading empty line of the context
disappeared, and a HELLO line in the middle of the leading context
appeared.

This result may or may not be semantically correct; it needs a human
decision. What if the original purpose of the "world" patch author was
to say WORLD but only without HELLO? When they looked at the code,
there
was no HELLO yet.

git-range-diff is very powerful, but reading its output takes some
getting used to. (Colorization with the "--color" option is basically
required for understanding; I can't reproduce it in this email, alas.)

I don't want to obsess about this forever, I just want us all to be
aware that this risk exists.

Thanks,
Laszlo


I then created 2 new PRs that added text to the same line # in
Readme.rst.

https://github.com/tianocore/edk2-codereview/pull/21
https://github.com/tianocore/edk2-codereview/pull/22

PR #21 passed all CI tests and was merged. Mergify then attempted to
rebase #22 and got a merge conflict and is still in the open state waiting
for the developer to manually handle the merge conflict.
This case is not worrisome; when there is a clear conflict that cannot be
auto-resolved, I'm not concerned.

My concern is the sneaky contextual conflict that *appears* auto-resolvable,
but is semantically broken. Those things
exist.

Thanks
Laszlo













[PATCH v2 2/2] OvmfPkg/Bhyve: use static PCI32Base address

Corvin Köhne
 

It's neccessary to allocate a Graphics Stolen Memory area to enable
GPU-Passthrough for integrated Intel GPUs. Therefore, use a new
memory layout with a static Pci32Baseaddress.

Old layout:
[... , lowmemlimit] RAM
[lowmemlimit, 0xE000 0000] PCI Space
New layout:
[... , lowmemlimit] RAM
[lowmemlimit, gsmbase ] Memory hole (may be absent)
[gsmbase , 0xC000 0000] GSM (may be absent)
[0xC000 0000, 0xE000 0000] PCI Space
---
OvmfPkg/Bhyve/BhyveX64.dsc | 4 ++--
OvmfPkg/Bhyve/PlatformPei/Platform.c | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index 22a6f11069..b678029b40 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -537,8 +537,8 @@
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId|0
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase|0x0
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize|0x0
- gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0
- gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0xC0000000
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x20000000
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x800000000

diff --git a/OvmfPkg/Bhyve/PlatformPei/Platform.c b/OvmfPkg/Bhyve/PlatformPei/Platform.c
index 3a414ffcb7..f38e74ccfc 100644
--- a/OvmfPkg/Bhyve/PlatformPei/Platform.c
+++ b/OvmfPkg/Bhyve/PlatformPei/Platform.c
@@ -191,7 +191,9 @@ MemMapInitialization (
ASSERT (PciExBarBase <= MAX_UINT32 - SIZE_256MB);
PciBase = (UINT32)(PciExBarBase + SIZE_256MB);
} else {
- PciBase = (TopOfLowRam < BASE_2GB) ? BASE_2GB : TopOfLowRam;
+ PciBase = PcdGet64(PcdPciMmio32Base);
+ if (PciBase == 0)
+ PciBase = (TopOfLowRam < BASE_2GB) ? BASE_2GB : TopOfLowRam;
}

//
--
2.11.0

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


[PATCH v2 1/2] OvmfPkg/Bhyve: add USB support

Corvin Köhne
 

An USB driver is required to use a keyboard or mouse while installing
an OS or while in a bootloader menu like grub when using GPU + USB
Passthrough.
---
OvmfPkg/Bhyve/BhyveX64.dsc | 11 +++++++++++
OvmfPkg/Bhyve/BhyveX64.fdf | 10 ++++++++++
2 files changed, 21 insertions(+)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index d8792812ab..22a6f11069 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -163,6 +163,7 @@
FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
+ UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibNull.inf
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
@@ -777,6 +778,16 @@
!endif
OvmfPkg/VirtioNetDxe/VirtioNet.inf

+ #
+ # Usb Support
+ #
+ MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
+ MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
+ MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
+ MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
+ MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+ MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
+
!ifdef $(CSM_ENABLE)
IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
<LibraryClasses>
diff --git a/OvmfPkg/Bhyve/BhyveX64.fdf b/OvmfPkg/Bhyve/BhyveX64.fdf
index 3eff36dac1..f081b82137 100644
--- a/OvmfPkg/Bhyve/BhyveX64.fdf
+++ b/OvmfPkg/Bhyve/BhyveX64.fdf
@@ -291,6 +291,16 @@ INF MdeModulePkg/Logo/LogoDxe.inf
!include NetworkPkg/Network.fdf.inc
INF OvmfPkg/VirtioNetDxe/VirtioNet.inf

+#
+# Usb Support
+#
+INF MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
+INF MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
+INF MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
+INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
+INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+INF MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
+
!ifdef $(CSM_ENABLE)
INF IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf
!endif
--
2.11.0

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


[PATCH v2 0/2] Prepare bhyve for GPU-Passthrough

Corvin Köhne
 

Hi,

these patches could be merged to improve GPU-Passthrough support.

If I get an agreement with Peter about BusEnumeration, I'll create a new patch series


Best Regards
Corvin


Corvin Köhne (2):
OvmfPkg/Bhyve: add USB support
OvmfPkg/Bhyve: use static PCI32Base address

OvmfPkg/Bhyve/BhyveX64.dsc | 15 +++++++++++++--
OvmfPkg/Bhyve/BhyveX64.fdf | 10 ++++++++++
OvmfPkg/Bhyve/PlatformPei/Platform.c | 4 +++-
3 files changed, 26 insertions(+), 3 deletions(-)

--
2.11.0

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


Re: 回复: Need help with CI/CD failure for the PR

Sunil V L
 

Thanks a lot Mike and Liming. This is very helpful.

Let me fix this issue and send the next version.

Thanks!
Sunil

On Thu, Jun 24, 2021 at 11:45:07AM +0800, gaoliming wrote:
Mike:
Thanks for your help. I can download build log and see the real issue.

Thanks
Liming
-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@intel.com>
发送时间: 2021年6月24日 11:16
收件人: gaoliming <gaoliming@byosoft.com.cn>; 'Sunil V L'
<sunilvl@ventanamicro.com>; devel@edk2.groups.io; 'Sean Brogan'
<sean.brogan@microsoft.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
抄送: 'Chang, Abner (HPS SW/FW Technologist)' <abner.chang@hpe.com>;
'Schaefer, Daniel' <daniel.schaefer@hpe.com>
主题: RE: Need help with CI/CD failure for the PR

Liming,

Looks like it failed to build BaseTools:

https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=24448&view
=logs&jobId=4a97f94c-8e1f-5e76-68ba-50872604dd63&j=2640d2b2-7c53-5a
2b-80c7-040377c664fd&t=9d40d6fd-f2ec-5369-fb67-2d935d8d6b47

This PR modified GenFw, so it is likely related.

You have to download artifact to see the detailed log. Select
"BASETOOLS_BUILD.txt from the following link:

https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=24448&view
=artifacts&pathAsName=false&type=publishedArtifacts


INFO - Microsoft (R) Program Maintenance Utility Version 14.29.30038.1
INFO - Copyright (C) Microsoft Corporation. All rights reserved.
INFO -
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I
D:\a\1\s\BaseTools\Source\C\Include -I
D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I
D:\a\1\s\BaseTools\Source\C\Common GenFw.c -FoGenFw.obj
INFO - GenFw.c
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I
D:\a\1\s\BaseTools\Source\C\Include -I
D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I
D:\a\1\s\BaseTools\Source\C\Common ElfConvert.c -FoElfConvert.obj
INFO - ElfConvert.c
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I
D:\a\1\s\BaseTools\Source\C\Include -I
D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I
D:\a\1\s\BaseTools\Source\C\Common Elf32Convert.c -FoElf32Convert.obj
INFO - Elf32Convert.c
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I
D:\a\1\s\BaseTools\Source\C\Include -I
D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I
D:\a\1\s\BaseTools\Source\C\Common Elf64Convert.c -FoElf64Convert.obj
INFO - Elf64Convert.c
INFO - Elf64Convert.c(540): error C2220: the following warning is treated as
an error
INFO - Elf64Convert.c(540): warning C4244: '=': conversion from 'Elf64_Addr'
to 'UINT32', possible loss of data
INFO - NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30037\bin\HostX86\x86\cl.ex
e"' : return code '0x2'
INFO - Stop.
INFO -
INFO - NMAKE : fatal error U1077: 'if' : return code '0x1'
INFO - Stop.
INFO - NMAKE : fatal error U1077: 'if' : return code '0x1'
INFO - Stop.
INFO - ------------------------------------------------
INFO - --------------Cmd Output Finished---------------
INFO - --------- Running Time (mm:ss): 00:29 ----------
INFO - ----------- Return Code: 0x00000002 ------------
INFO - ------------------------------------------------

Best regardm,

Mike


-----Original Message-----
From: gaoliming <gaoliming@byosoft.com.cn>
Sent: Wednesday, June 23, 2021 6:45 PM
To: 'Sunil V L' <sunilvl@ventanamicro.com>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@intel.com>; 'Sean
Brogan' <sean.brogan@microsoft.com>
Cc: 'Chang, Abner (HPS SW/FW Technologist)' <abner.chang@hpe.com>;
'Schaefer, Daniel' <daniel.schaefer@hpe.com>
Subject: 回复: Need help with CI/CD failure for the PR

Mike and Sean:
Have you any idea on how to find the error message in PR failure report?

For this PR https://github.com/tianocore/edk2/pull/1738, I don't find the
real error message.

Thanks
Liming
-----邮件原件-----
发件人: Sunil V L <sunilvl@ventanamicro.com>
发送时间: 2021年6月22日 18:53
收件人: devel@edk2.groups.io
抄送: gaoliming@byosoft.com.cn; Chang, Abner (HPS SW/FW
Technologist)
<abner.chang@hpe.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>
主题: Need help with CI/CD failure for the PR

Hi,

The PR https://github.com/tianocore/edk2/pull/1738 has hit error with
below
message.

"PR can not be merged due to a Windows VS2019 failure. Please resolve
and
resubmit"

Unfortunately, I am unable to gather any details why it is failing. Also, I
don't
have VS2019 build environment to try the build myself. Could some one
with
VS2019 or knowledge of this build environment help me what exactly is
the
issue with my patch?

Thanks in advance!

Sunil







Re: Proposing a new area of the edk2-test repository

Bret Barkelew
 

Fun fact! Mu also has a number of apps and things that we could work on moving to EDK2 if there were a suitable location. Right now, many of them are here:

mu_plus/UefiTestingPkg at release/202102 · microsoft/mu_plus (github.com)

 

- Bret

 

From: Nelson, Eric via groups.io
Sent: Wednesday, June 23, 2021 3:38 PM
To: Samer El-Haj-Mahmoud; G Edhaya Chandran; gaojie@...; devel@edk2.groups.io; Kinney, Michael D
Subject: [EXTERNAL] Re: [edk2-devel] Proposing a new area of the edk2-test repository

 

 

I have created a few other internal apps that build under WinTestPkg, although ResumeOK.efi is the only one I have received permissions to release sources for at this time.

And yes, they are primarily intended for validating Windows requirements.

I had some issues with my apps, needing to use different libraries than MdeModulePkg, and found it easier to create my own package, and use the libs I want.

 

__e

 

 

From: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Sent: Wednesday, June 23, 2021 1:56 PM
To: Nelson, Eric <eric.nelson@...>; G Edhaya Chandran <Edhaya.Chandran@...>; gaojie@...; devel@edk2.groups.io
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: RE: Proposing a new area of the edk2-test repository

 

+edk2 list

 

I am not against adding additional test tools to edk2-test. Just feel like there is a need to organize and have a strategy, rather than just use edk2-test as a dumping group of miscellaneous tools.

 

There is already a place for apps under https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Application

 

We also have a number of EDK2 misc applications that use edk2-libc in https://github.com/tianocore/edk2-libc/tree/master/AppPkg/Applications

 

A couple of questions:

  • Do you expect more apps from WinTestPkg to be contributed to TianoCore? And are they all around testing specific Windows requirements? If so, then having an edk2-test/WinTestPkg makes sense to me, as you will have a collection of useful testing app targeting specific area.
    • But what about other OSes?
  • If this is a one-off test app and other WinTestPkg apps are not going to be contributed, then does it make sense to put this under MdeModulePkg/Application ?

 

 

 

From: Nelson, Eric <eric.nelson@...>
Sent: Wednesday, June 23, 2021 3:10 PM
To: G Edhaya Chandran <Edhaya.Chandran@...>; gaojie@...
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: RE: Proposing a new area of the edk2-test repository

 

 

Hi Edhay,

 

Do you have any more questions?

What do you think of creating another directory in edk2-test, for other test apps, in addition to uefi-sct, such as ResumeOK.efi?

 

Thanks,

__e

 

 

From: Nelson, Eric
Sent: Tuesday, June 15, 2021 12:00 PM
To: G Edhaya Chandran <Edhaya.Chandran@...>; gaojie@...
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: RE: Proposing a new area of the edk2-test repository

 

 

Hi Edhay,

 

ResumeOK.efi is a tool I wrote from the HelloWorld example, that validates Windows resume from S4 requirements, specifically that the memory-map run-time memory regions don’t change, and secondly that PCI devices don’t disappear from the system, both conditions would cause Windows to fail to resume from S4.

 

You install the tool to the root of the ESP, and set it as the default/top entry in the boot manager, and launch it.  (Disable Secure Boot.)

 

It runs warm, cold, and 60s ACPI RTC wake cycles, infinitely looking for errors.

 

ResumeOK.efi writes a file to the root of the ESP, ResumeOK.map, which contains the ACPI Facs->HardwareSignature, a list of the PCI devices in the system, and a copy of its memory map, from the first time it runs.

 

During each test pass, it runs a barrage of tests:

 

  1. Free memory test – does the available memory match the memory map saved in ResumeOK.map
  2. HW signature check – does the system still have the same HW signature as saved in the ResumeOK.map
  3. Allocation test – all the available memory is allocated, and then the memory map is checked if the run-time regions match ResumeOK.map.

 

If any of the tests fail, then the new/missing PCI devices are listed (HW signature fail case), or the memory descriptor that changed, it’s location, and current and previous type and size.

 

I have received permission from Intel to *try* to release the source under Edk2-test.

 

I’ve included a 64-bit binary, if you want to give it a test drive.

 

Make sure Secure Boot is off.

Also, it is required to manually delete any ResumeOK.map on the ESP, before beginning a new test pass.

 

The tool also supports a host of EFI Shell commands:

 

Resumeok.efi MEMMAP – displays Windows coalesced view of the current memory map

ResumeOK.efi ROKMAP – displays Windows coalesced view of the memory saved in ResumeOK.map

ResumeOK.efi RTDATA – displays an analysis of RT_Data pool usage

ResumeOK.efi NORESET – run one test pass, but suppress automatic SX cycling

 

These are the files that build it:

 

Edk2\WinTestPkg\Application

Edk2\WinTestPkg\WinTestPkg.dec

Edk2\WinTestPkg\WinTestPkg.dsc

Edk2\WinTestPkg\Application\ResumeOK

Edk2\WinTestPkg\Application\ResumeOK\AcpiTbl.c

Edk2\WinTestPkg\Application\ResumeOK\AcpiTbl.h

Edk2\WinTestPkg\Application\ResumeOK\AppSupport.c

Edk2\WinTestPkg\Application\ResumeOK\BitMap.c

Edk2\WinTestPkg\Application\ResumeOK\BitMap.h

Edk2\WinTestPkg\Application\ResumeOK\EfiFileLib.c

Edk2\WinTestPkg\Application\ResumeOK\EfiFileLib.h

Edk2\WinTestPkg\Application\ResumeOK\pci.c

Edk2\WinTestPkg\Application\ResumeOK\Pci.h

Edk2\WinTestPkg\Application\ResumeOK\ResumeOK.c

Edk2\WinTestPkg\Application\ResumeOK\ResumeOK.h

Edk2\WinTestPkg\Application\ResumeOK\ResumeOK.inf

Edk2\WinTestPkg\Application\ResumeOK\ResumeOK.uni

Edk2\WinTestPkg\Application\ResumeOK\ResumeOKExtra.uni

Edk2\WinTestPkg\Application\ResumeOK\RtData.c

Edk2\WinTestPkg\Application\ResumeOK\TimeBaseLib.c

 

Thanks,

__e

 

 

From: G Edhaya Chandran <Edhaya.Chandran@...>
Sent: Monday, June 14, 2021 9:36 PM
To: Nelson, Eric <eric.nelson@...>; gaojie@...
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: RE: Proposing a new area of the edk2-test repository

 

Hi Eric,

 

    Thanks for reaching out to us.

Can we get more details of the tool?

 

Is this tool already open sourced or could you send us the basic documentation pertaining to it.

 

With Warm Regards,
Edhay

 

 

From: Nelson, Eric <eric.nelson@...>
Sent: 15 June 2021 04:23
To: gaojie@...; G Edhaya Chandran <Edhaya.Chandran@...>
Subject: Proposing a new area of the edk2-test repository

 

 

Hello SCT maintainers,

 

I’m looking to release source to a UEFI validation tool that has been a big hit with platform BIOS validation teams, so it can help other PC vendors.

 

My coworker Michael Kinney suggested I reach out to you directly about the idea of creating a new top level directory in the edk2-test repro for other test apps, and I could be maintainer.

 

What do you think of creating another directory in edk2-test, for other test apps, in addition to uefi-sct?

 

Thanks!

__e

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

 


Re: [Patch V2 2/2] UefiPayloadPkg: consume the BootManagerMenuFile HOB

Guo Dong
 

Reviewed-by: Guo Dong <guo.dong@intel.com>

-----Original Message-----
From: Tan, Dun <dun.tan@intel.com>
Sent: Tuesday, June 22, 2021 8:04 PM
To: devel@edk2.groups.io
Cc: Ma, Maurice <maurice.ma@intel.com>; Dong, Guo
<guo.dong@intel.com>; You, Benjamin <benjamin.you@intel.com>; Tan,
Dun <dun.tan@intel.com>
Subject: [Patch V2 2/2] UefiPayloadPkg: consume the BootManagerMenuFile
HOB

Consume the BootManagerMenuFile HOB in PlatformBootManagerLib
This Lib is in UefiPayloadPkg

Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>

Signed-off-by: DunTan <dun.tan@intel.com>
---
UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
| 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++

UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.i
nf | 5 ++++-
UefiPayloadPkg/UefiPayloadPkg.dsc | 2 +-
3 files changed, 57 insertions(+), 2 deletions(-)

diff --git
a/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
b/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index fce48d26a1..c4d317fa9e 100644
---
a/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++
b/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
@@ -10,6 +10,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include "PlatformBootManager.h"
#include "PlatformConsole.h"
#include <Protocol/PlatformBootManagerOverride.h>
+#include <Guid/BootManagerMenu.h>
+#include <Library/HobLib.h>


UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_PROTOCO
L *mUniversalPayloadPlatformBootManagerOverrideInstance = NULL;

@@ -286,3 +288,53 @@ PlatformBootManagerUnableToBoot (
return;
}

+/**
+ Get/update PcdBootManagerMenuFile from GUID HOB which will be
assigned in bootloader.
+
+ @param ImageHandle The firmware allocated handle for the EFI image.
+ @param SystemTable A pointer to the EFI System Table.
+
+ @retval EFI_SUCCESS The entry point is executed successfully.
+ @retval other Some error occurs.
+
+**/
+EFI_STATUS
+EFIAPI
+PlatformBootManagerLibConstructor (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+)
+{
+ EFI_STATUS Status;
+ UINTN Size;
+ VOID *GuidHob;
+ UNIVERSAL_PAYLOAD_GENERIC_HEADER *GenericHeader;
+ UNIVERSAL_PAYLOAD_BOOT_MANAGER_MENU
*BootManagerMenuFile;
+
+ GuidHob = GetFirstGuidHob (&gEdkiiBootManagerMenuFileGuid);
+
+ if (GuidHob == NULL) {
+ //
+ // If the HOB is not create, the default value of PcdBootManagerMenuFile
will be used.
+ //
+ return EFI_SUCCESS;
+ }
+
+ GenericHeader = (UNIVERSAL_PAYLOAD_GENERIC_HEADER *)
GET_GUID_HOB_DATA (GuidHob);
+ if ((sizeof (UNIVERSAL_PAYLOAD_GENERIC_HEADER) >
GET_GUID_HOB_DATA_SIZE (GuidHob)) || (GenericHeader->Length >
GET_GUID_HOB_DATA_SIZE (GuidHob))) {
+ return EFI_NOT_FOUND;
+ }
+ if (GenericHeader->Revision ==
UNIVERSAL_PAYLOAD_BOOT_MANAGER_MENU_REVISION) {
+ BootManagerMenuFile =
(UNIVERSAL_PAYLOAD_BOOT_MANAGER_MENU *) GET_GUID_HOB_DATA
(GuidHob);
+ if (BootManagerMenuFile->Header.Length <
UNIVERSAL_PAYLOAD_SIZEOF_THROUGH_FIELD
(UNIVERSAL_PAYLOAD_BOOT_MANAGER_MENU, FileName)) {
+ return EFI_NOT_FOUND;
+ }
+ Size = sizeof (BootManagerMenuFile->FileName);
+ Status = PcdSetPtrS (PcdBootManagerMenuFile, &Size,
&BootManagerMenuFile->FileName);
+ ASSERT_EFI_ERROR (Status);
+ } else {
+ return EFI_NOT_FOUND;
+ }
+
+ return EFI_SUCCESS;
+}
diff --git
a/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLi
b.inf
b/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLi
b.inf
index 600a535282..9c4a9da943 100644
---
a/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLi
b.inf
+++
b/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLi
b.inf
@@ -13,7 +13,7 @@
MODULE_TYPE = DXE_DRIVER
VERSION_STRING = 1.0
LIBRARY_CLASS = PlatformBootManagerLib|DXE_DRIVER
-
+ CONSTRUCTOR = PlatformBootManagerLibConstructor

#
# The following information is for reference only and not required by the
build tools.
@@ -46,9 +46,11 @@
HiiLib
PrintLib
PlatformHookLib
+ HobLib

[Guids]
gEfiEndOfDxeEventGroupGuid
+ gEdkiiBootManagerMenuFileGuid

[Protocols]
gEfiGenericMemTestProtocolGuid ## CONSUMES
@@ -70,3 +72,4 @@
gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity
gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits
+ gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile
diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 21b360256b..e46b867d30 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -289,7 +289,6 @@
!endif
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable|TRUE
- gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21,
0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66,
0x23, 0x31 }


!if $(SOURCE_DEBUG_ENABLE)
@@ -297,6 +296,7 @@
!endif

[PcdsPatchableInModule.common]
+ gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21,
0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66,
0x23, 0x31 }
gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x7
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8000004F
!if $(SOURCE_DEBUG_ENABLE)
--
2.31.1.windows.1


Re: [Patch V2 1/2] UefiPayloadPkg: Add new structure for BootManagerMenuFile HOB

Guo Dong
 

Reviewed-by: Guo Dong <guo.dong@intel.com>

-----Original Message-----
From: Tan, Dun <dun.tan@intel.com>
Sent: Tuesday, June 22, 2021 8:04 PM
To: devel@edk2.groups.io
Cc: Ma, Maurice <maurice.ma@intel.com>; Dong, Guo
<guo.dong@intel.com>; You, Benjamin <benjamin.you@intel.com>; Tan,
Dun <dun.tan@intel.com>
Subject: [Patch V2 1/2] UefiPayloadPkg: Add new structure for
BootManagerMenuFile HOB

Add new structure for BootManagerMenuFile HOB in UefiPayloadPkg

Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>

Signed-off-by: DunTan <dun.tan@intel.com>
---
UefiPayloadPkg/Include/Guid/BootManagerMenu.h | 27
+++++++++++++++++++++++++++
UefiPayloadPkg/UefiPayloadPkg.dec | 3 +++
2 files changed, 30 insertions(+)

diff --git a/UefiPayloadPkg/Include/Guid/BootManagerMenu.h
b/UefiPayloadPkg/Include/Guid/BootManagerMenu.h
new file mode 100644
index 0000000000..d17cdf3084
--- /dev/null
+++ b/UefiPayloadPkg/Include/Guid/BootManagerMenu.h
@@ -0,0 +1,27 @@
+/** @file
+ Define the structure for the Boot Manager Menu File.
+
+Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef UNIVERSAL_PAYLOAD_BOOT_MANAGER_MENU_H_
+#define UNIVERSAL_PAYLOAD_BOOT_MANAGER_MENU_H_
+
+#include <Uefi.h>
+#include <UniversalPayload/UniversalPayload.h>
+
+#pragma pack (1)
+
+typedef struct {
+ UNIVERSAL_PAYLOAD_GENERIC_HEADER Header;
+ GUID FileName;
+} UNIVERSAL_PAYLOAD_BOOT_MANAGER_MENU;
+
+#pragma pack()
+
+#define UNIVERSAL_PAYLOAD_BOOT_MANAGER_MENU_REVISION 1
+
+extern GUID gEdkiiBootManagerMenuFileGuid;
+#endif
diff --git a/UefiPayloadPkg/UefiPayloadPkg.dec
b/UefiPayloadPkg/UefiPayloadPkg.dec
index 105e1f5a1c..d2b2dbeb25 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dec
+++ b/UefiPayloadPkg/UefiPayloadPkg.dec
@@ -29,6 +29,9 @@
#
gBmpImageGuid = { 0x878AC2CC, 0x5343, 0x46F2, { 0xB5, 0x63,
0x51, 0xF8, 0x9D, 0xAF, 0x56, 0xBA } }

+ ##include/Guid/BootManagerMenu.h
+ gEdkiiBootManagerMenuFileGuid = { 0xdf939333, 0x42fc, 0x4b2a, { 0xa5,
0x9e, 0xbb, 0xae, 0x82, 0x81, 0xfe, 0xef }}
+
gUefiSystemTableInfoGuid = {0x16c8a6d0, 0xfe8a, 0x4082, {0xa2, 0x8, 0xcf,
0x89, 0xc4, 0x29, 0x4, 0x33}}
gUefiAcpiBoardInfoGuid = {0xad3d31b, 0xb3d8, 0x4506, {0xae, 0x71, 0x2e,
0xf1, 0x10, 0x6, 0xd9, 0xf}}
gUefiSerialPortInfoGuid = { 0x6c6872fe, 0x56a9, 0x4403, { 0xbb, 0x98, 0x95,
0x8d, 0x62, 0xde, 0x87, 0xf1 } }
--
2.31.1.windows.1


回复: Need help with CI/CD failure for the PR

gaoliming
 

Mike:
Thanks for your help. I can download build log and see the real issue.

Thanks
Liming

-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@intel.com>
发送时间: 2021年6月24日 11:16
收件人: gaoliming <gaoliming@byosoft.com.cn>; 'Sunil V L'
<sunilvl@ventanamicro.com>; devel@edk2.groups.io; 'Sean Brogan'
<sean.brogan@microsoft.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
抄送: 'Chang, Abner (HPS SW/FW Technologist)' <abner.chang@hpe.com>;
'Schaefer, Daniel' <daniel.schaefer@hpe.com>
主题: RE: Need help with CI/CD failure for the PR

Liming,

Looks like it failed to build BaseTools:

https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=24448&view
=logs&jobId=4a97f94c-8e1f-5e76-68ba-50872604dd63&j=2640d2b2-7c53-5a
2b-80c7-040377c664fd&t=9d40d6fd-f2ec-5369-fb67-2d935d8d6b47

This PR modified GenFw, so it is likely related.

You have to download artifact to see the detailed log. Select
"BASETOOLS_BUILD.txt from the following link:

https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=24448&view
=artifacts&pathAsName=false&type=publishedArtifacts


INFO - Microsoft (R) Program Maintenance Utility Version 14.29.30038.1
INFO - Copyright (C) Microsoft Corporation. All rights reserved.
INFO -
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I
D:\a\1\s\BaseTools\Source\C\Include -I
D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I
D:\a\1\s\BaseTools\Source\C\Common GenFw.c -FoGenFw.obj
INFO - GenFw.c
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I
D:\a\1\s\BaseTools\Source\C\Include -I
D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I
D:\a\1\s\BaseTools\Source\C\Common ElfConvert.c -FoElfConvert.obj
INFO - ElfConvert.c
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I
D:\a\1\s\BaseTools\Source\C\Include -I
D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I
D:\a\1\s\BaseTools\Source\C\Common Elf32Convert.c -FoElf32Convert.obj
INFO - Elf32Convert.c
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I
D:\a\1\s\BaseTools\Source\C\Include -I
D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I
D:\a\1\s\BaseTools\Source\C\Common Elf64Convert.c -FoElf64Convert.obj
INFO - Elf64Convert.c
INFO - Elf64Convert.c(540): error C2220: the following warning is treated as
an error
INFO - Elf64Convert.c(540): warning C4244: '=': conversion from 'Elf64_Addr'
to 'UINT32', possible loss of data
INFO - NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30037\bin\HostX86\x86\cl.ex
e"' : return code '0x2'
INFO - Stop.
INFO -
INFO - NMAKE : fatal error U1077: 'if' : return code '0x1'
INFO - Stop.
INFO - NMAKE : fatal error U1077: 'if' : return code '0x1'
INFO - Stop.
INFO - ------------------------------------------------
INFO - --------------Cmd Output Finished---------------
INFO - --------- Running Time (mm:ss): 00:29 ----------
INFO - ----------- Return Code: 0x00000002 ------------
INFO - ------------------------------------------------

Best regardm,

Mike


-----Original Message-----
From: gaoliming <gaoliming@byosoft.com.cn>
Sent: Wednesday, June 23, 2021 6:45 PM
To: 'Sunil V L' <sunilvl@ventanamicro.com>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@intel.com>; 'Sean
Brogan' <sean.brogan@microsoft.com>
Cc: 'Chang, Abner (HPS SW/FW Technologist)' <abner.chang@hpe.com>;
'Schaefer, Daniel' <daniel.schaefer@hpe.com>
Subject: 回复: Need help with CI/CD failure for the PR

Mike and Sean:
Have you any idea on how to find the error message in PR failure report?

For this PR https://github.com/tianocore/edk2/pull/1738, I don't find the
real error message.

Thanks
Liming
-----邮件原件-----
发件人: Sunil V L <sunilvl@ventanamicro.com>
发送时间: 2021年6月22日 18:53
收件人: devel@edk2.groups.io
抄送: gaoliming@byosoft.com.cn; Chang, Abner (HPS SW/FW
Technologist)
<abner.chang@hpe.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>
主题: Need help with CI/CD failure for the PR

Hi,

The PR https://github.com/tianocore/edk2/pull/1738 has hit error with
below
message.

"PR can not be merged due to a Windows VS2019 failure. Please resolve
and
resubmit"

Unfortunately, I am unable to gather any details why it is failing. Also, I
don't
have VS2019 build environment to try the build myself. Could some one
with
VS2019 or knowledge of this build environment help me what exactly is
the
issue with my patch?

Thanks in advance!

Sunil


[PATCH v2 2/2] MdePkg: MmConfiguration: Added definition of MM Configuration PPI

Kun Qin
 

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

MM Configuration PPI was defined in PI Specification since v1.5. This
change added definition of such PPI and related GUIDs into MdePkg.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
---

Notes:
v2:
- Include PiMultiPhase.h instead of PiMmCis.h [Liming]

MdePkg/Include/Ppi/MmConfiguration.h | 62 ++++++++++++++++++++
MdePkg/MdePkg.dec | 3 +
2 files changed, 65 insertions(+)

diff --git a/MdePkg/Include/Ppi/MmConfiguration.h b/MdePkg/Include/Ppi/MmConfiguration.h
new file mode 100644
index 000000000000..862a80e372f8
--- /dev/null
+++ b/MdePkg/Include/Ppi/MmConfiguration.h
@@ -0,0 +1,62 @@
+/** @file
+ EFI MM Configuration PPI as defined in PI 1.5 specification.
+
+ This PPI is used to:
+ 1) report the portions of MMRAM regions which cannot be used for the MMRAM heap.
+ 2) register the MM Foundation entry point with the processor code. The entry
+ point will be invoked by the MM processor entry code.
+
+ Copyright (c) Microsoft Corporation.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef MM_CONFIGURATION_PPI_H_
+#define MM_CONFIGURATION_PPI_H_
+
+#include <Pi/PiMultiPhase.h>
+
+#define EFI_PEI_MM_CONFIGURATION_PPI_GUID \
+ { \
+ 0xc109319, 0xc149, 0x450e, { 0xa3, 0xe3, 0xb9, 0xba, 0xdd, 0x9d, 0xc3, 0xa4 } \
+ }
+
+typedef struct _EFI_PEI_MM_CONFIGURATION_PPI EFI_PEI_MM_CONFIGURATION_PPI;
+
+/**
+ This function registers the MM Foundation entry point with the processor code. This entry point will be
+ invoked by the MM Processor entry code as defined in PI specification.
+
+ @param[in] This The EFI_PEI_MM_CONFIGURATION_PPI instance.
+ @param[in] MmEntryPoint MM Foundation entry point.
+
+ @retval EFI_SUCCESS The entry-point was successfully registered.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_REGISTER_MM_ENTRY) (
+ IN CONST EFI_PEI_MM_CONFIGURATION_PPI *This,
+ IN EFI_MM_ENTRY_POINT MmEntryPoint
+ );
+
+///
+/// This PPI is a PPI published by a CPU PEIM to indicate which areas within MMRAM are reserved for use by
+/// the CPU for any purpose, such as stack, save state or MM entry point. If a platform chooses to let a CPU
+/// PEIM do MMRAM relocation, this PPI must be produced by this CPU PEIM.
+///
+/// The MmramReservedRegions points to an array of one or more EFI_MM_RESERVED_MMRAM_REGION structures, with
+/// the last structure having the MmramReservedSize set to 0. An empty array would contain only the last
+/// structure.
+///
+/// The RegisterMmEntry() function allows the MM IPL PEIM to register the MM Foundation entry point with the
+/// MM entry vector code.
+///
+struct _EFI_PEI_MM_CONFIGURATION_PPI {
+ EFI_MM_RESERVED_MMRAM_REGION *MmramReservedRegions;
+ EFI_PEI_MM_REGISTER_MM_ENTRY RegisterMmEntry;
+};
+
+extern EFI_GUID gEfiPeiMmConfigurationPpi;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index b49f88d8e18f..c5319fdd71ca 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -983,6 +983,9 @@ [Ppis]
## Include/Ppi/MmControl.h
gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e, 0x4f43, { 0x8d, 0xef, 0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}

+ ## Include/Ppi/MmConfiguration.h
+ gEfiPeiMmConfigurationPpi = { 0xc109319, 0xc149, 0x450e, { 0xa3, 0xe3, 0xb9, 0xba, 0xdd, 0x9d, 0xc3, 0xa4 } }
+
#
# PPIs defined in PI 1.7.
#
--
2.31.1.windows.1


[PATCH v2 1/2] MdePkg: MmConfiguration: Move definition of EFI_MM_RESERVED_MMRAM_REGION

Kun Qin
 

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

The definition of EFI_MM_RESERVED_MMRAM_REGION, according to PI Spec 1.5
is also referenced in EFI_PEI_MM_CONFIGURATION_PPI. Defining this
structure as is will enforce any potential usage of MM Configuration PPI
interface to include <Protocol/MmConfiguration.h>.

This change moves this structure definition to PiMultiPhase.h, which is
already included by Protocol/MmConfiguration.h through PiMmCis.h. It also
paves way for introducing Ppi/MmConfiguration.h with proper dependency.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
---

Notes:
v2:
- Changed definition from PiMmCis to PiMultiPhase [Liming]

MdePkg/Include/Pi/PiMultiPhase.h | 16 ++++++++++++++++
MdePkg/Include/Protocol/MmConfiguration.h | 16 ----------------
2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/MdePkg/Include/Pi/PiMultiPhase.h b/MdePkg/Include/Pi/PiMultiPhase.h
index a5056799e1dd..89280d9d3506 100644
--- a/MdePkg/Include/Pi/PiMultiPhase.h
+++ b/MdePkg/Include/Pi/PiMultiPhase.h
@@ -133,6 +133,22 @@ typedef struct {

typedef EFI_MMRAM_DESCRIPTOR EFI_SMRAM_DESCRIPTOR;

+///
+/// Structure describing a MMRAM region which cannot be used for the MMRAM heap.
+///
+typedef struct _EFI_MM_RESERVED_MMRAM_REGION {
+ ///
+ /// Starting address of the reserved MMRAM area, as it appears while MMRAM is open.
+ /// Ignored if MmramReservedSize is 0.
+ ///
+ EFI_PHYSICAL_ADDRESS MmramReservedStart;
+ ///
+ /// Number of bytes occupied by the reserved MMRAM area. A size of zero indicates the
+ /// last MMRAM area.
+ ///
+ UINT64 MmramReservedSize;
+} EFI_MM_RESERVED_MMRAM_REGION;
+
typedef enum {
EFI_PCD_TYPE_8,
EFI_PCD_TYPE_16,
diff --git a/MdePkg/Include/Protocol/MmConfiguration.h b/MdePkg/Include/Protocol/MmConfiguration.h
index eeb94f64bdf7..d2fb6a13d4af 100644
--- a/MdePkg/Include/Protocol/MmConfiguration.h
+++ b/MdePkg/Include/Protocol/MmConfiguration.h
@@ -21,22 +21,6 @@
0x26eeb3de, 0xb689, 0x492e, {0x80, 0xf0, 0xbe, 0x8b, 0xd7, 0xda, 0x4b, 0xa7 } \
}

-///
-/// Structure describing a MMRAM region which cannot be used for the MMRAM heap.
-///
-typedef struct _EFI_MM_RESERVED_MMRAM_REGION {
- ///
- /// Starting address of the reserved MMRAM area, as it appears while MMRAM is open.
- /// Ignored if MmramReservedSize is 0.
- ///
- EFI_PHYSICAL_ADDRESS MmramReservedStart;
- ///
- /// Number of bytes occupied by the reserved MMRAM area. A size of zero indicates the
- /// last MMRAM area.
- ///
- UINT64 MmramReservedSize;
-} EFI_MM_RESERVED_MMRAM_REGION;
-
typedef struct _EFI_MM_CONFIGURATION_PROTOCOL EFI_MM_CONFIGURATION_PROTOCOL;

/**
--
2.31.1.windows.1


[PATCH v2 0/2] Add MM Configuration PPI definition to MdePkg

Kun Qin
 

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

This patch series is a follow up of previous submission:
https://edk2.groups.io/g/devel/message/76748

v2 patches mainly focus on feedback for commits submitted in v1 patches:
a. Moved EFI_MM_RESERVED_MMRAM_REGION from PiMmCis to PiMultiPhase;
b. Updated inclusion in new file accordingly;

Patch v2 branch: https://github.com/kuqin12/edk2/tree/mm_config_ppi_v2

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>

Kun Qin (2):
MdePkg: MmConfiguration: Move definition of
EFI_MM_RESERVED_MMRAM_REGION
MdePkg: MmConfiguration: Added definition of MM Configuration PPI

MdePkg/Include/Pi/PiMultiPhase.h | 16 +++++
MdePkg/Include/Ppi/MmConfiguration.h | 62 ++++++++++++++++++++
MdePkg/Include/Protocol/MmConfiguration.h | 16 -----
MdePkg/MdePkg.dec | 3 +
4 files changed, 81 insertions(+), 16 deletions(-)
create mode 100644 MdePkg/Include/Ppi/MmConfiguration.h

--
2.31.1.windows.1


Re: [EXTERNAL] Re: [edk2-devel] [PATCH v1 1/5] EDK2 Code First: PI Specification: EFI_MM_COMMUNICATE_HEADER Update

Bret Barkelew
 

Yeah, the only other thought I had for moving forwards quickly (i.e. hackily) is to define a new GUID that just means “I use an updated header configuration” since the EFI_GUID field comes first and is a well-understood size.

 

I would prefer the “deprecate, break builds, fix code, move forward” approach.

 

- Bret

 

From: Kun Qin via groups.io
Sent: Wednesday, June 23, 2021 5:53 PM
To: Wu, Hao A; devel@edk2.groups.io
Cc: Kinney, Michael D; Liming Gao; Liu, Zhiguang; Andrew Fish; Laszlo Ersek; Lindholm, Leif; Bret Barkelew; Michael Kubacki
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v1 1/5] EDK2 Code First: PI Specification: EFI_MM_COMMUNICATE_HEADER Update

 

Hi Hao,

We have been circulating different ideas internally about how to enforce
a warning around this change.

There is an idea of deprecating the old structure and replacing it with
a newly defined EFI_MM_COMMUNICATE_HEADER_V2. That way all consumers
will be enforced to update their implementation and (hopefully) inspect
the compatibility accordingly. In addition, we could add other fields
such as signature and/or header version number for further extensibility.

If there are code instances that uses "sizeof(EFI_GUID) + sizeof(UINTN)"
in lieu of OFFSET_OF, this implementation is essentially decoupled from
the structure definition. So compiler might not be able to help. In that
case, runtime protections such as pool guard or stack guard might be useful.

Please let me know if you think header structure V2 is an idea worth to try.

Thanks,
Kun

On 06/15/2021 18:15, Wu, Hao A wrote:
> Thanks Kun,
>
> I am a little concerned on whether there will be other missing cases that are not covered by this patch series.
>
> I am also wondering is there any detection can be made to warn the cases that code modification should be made after this structure update.
> Otherwise, it will be the burden for the platform owners to review the platform codes following your guide mentioned in this patch.
>
> Hoping others can provide some inputs on this.
>
> Best Regards,
> Hao Wu
>
>> -----Original Message-----
>> From: Kun Qin <kuqin12@...>
>> Sent: Wednesday, June 16, 2021 4:51 AM
>> To: Wu, Hao A <hao.a.wu@...>; devel@edk2.groups.io
>> Cc: Kinney, Michael D <michael.d.kinney@...>; Liming Gao
>> <gaoliming@...>; Liu, Zhiguang <zhiguang.liu@...>;
>> Andrew Fish <afish@...>; Laszlo Ersek <lersek@...>; Leif
>> Lindholm <leif@...>
>> Subject: Re: [edk2-devel] [PATCH v1 1/5] EDK2 Code First: PI Specification:
>> EFI_MM_COMMUNICATE_HEADER Update
>>
>> Hi Hao,
>>
>> Sorry that I missed comments for this patch earlier. You are correct. I only
>> inspected SmmLockBoxPeiLib. The PEI instance handled mode switch with
>> ```OFFSET_OF ``` function. But DXE instance still have a few use cases that will
>> be impacted.
>>
>> I will update this read me file and add a code change patch for this library in
>> v2. Thanks for pointing this out.
>>
>> Regards,
>> Kun
>>
>> On 06/11/2021 00:46, Wu, Hao A wrote:
>>>> -----Original Message-----
>>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Kun
>>>> Qin
>>>> Sent: Thursday, June 10, 2021 9:43 AM
>>>> To: devel@edk2.groups.io
>>>> Cc: Kinney, Michael D <michael.d.kinney@...>; Liming Gao
>>>> <gaoliming@...>; Liu, Zhiguang <zhiguang.liu@...>;
>>>> Andrew Fish <afish@...>; Laszlo Ersek <lersek@...>; Leif
>>>> Lindholm <leif@...>
>>>> Subject: [edk2-devel] [PATCH v1 1/5] EDK2 Code First: PI Specification:
>>>> EFI_MM_COMMUNICATE_HEADER Update
>>>>
>>>> REF: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3430&amp;data=04%7C01%7CBret.Barkelew%40microsoft.com%7Ca480819ff5e84e12239f08d936aa7bc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637600928127681913%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=483mG24s%2Bp0xSF90Wf%2Fmh2TN1atrIQa5mOrLyEPCTuE%3D&amp;reserved=0
>>>>
>>>> This change includes specification update markdown file that
>>>> describes the proposed PI Specification v1.7 Errata A in detail and
>>>> potential impact to the existing codebase.
>>>>
>>>> Cc: Michael D Kinney <michael.d.kinney@...>
>>>> Cc: Liming Gao <gaoliming@...>
>>>> Cc: Zhiguang Liu <zhiguang.liu@...>
>>>> Cc: Andrew Fish <afish@...>
>>>> Cc: Laszlo Ersek <lersek@...>
>>>> Cc: Leif Lindholm <leif@...>
>>>>
>>>> Signed-off-by: Kun Qin <kuqin12@...>
>>>> ---
>>>>    BZ3430-SpecChange.md | 88 ++++++++++++++++++++
>>>>    1 file changed, 88 insertions(+)
>>>>
>>>> diff --git a/BZ3430-SpecChange.md b/BZ3430-SpecChange.md new file
>>>> mode
>>>> 100644 index 000000000000..33a1ffda447b
>>>> --- /dev/null
>>>> +++ b/BZ3430-SpecChange.md
>>>> @@ -0,0 +1,88 @@
>>>> +# Title: Change MessageLength Field of
>> EFI_MM_COMMUNICATE_HEADER
>>>> to
>>>> +UINT64
>>>> +
>>>> +## Status: Draft
>>>> +
>>>> +## Document: UEFI Platform Initialization Specification Version 1.7
>>>> +Errata A
>>>> +
>>>> +## License
>>>> +
>>>> +SPDX-License-Identifier: CC-BY-4.0
>>>> +
>>>> +## Submitter: [TianoCore Community](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tianocore.org%2F&amp;data=04%7C01%7CBret.Barkelew%40microsoft.com%7Ca480819ff5e84e12239f08d936aa7bc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637600928127681913%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=eRu4We7iSzuwrsS9MqIO2iqLxXHZ6CpUkInVpty554c%3D&amp;reserved=0)
>>>> +
>>>> +## Summary of the change
>>>> +
>>>> +Change the `MessageLength` Field of
>> `EFI_MM_COMMUNICATE_HEADER`
>>>> from UINTN to UINT64 to remove architecture dependency:
>>>> +
>>>> +```c
>>>> +typedef struct {
>>>> +  EFI_GUID  HeaderGuid;
>>>> +  UINT64    MessageLength;
>>>> +  UINT8     Data[ANYSIZE_ARRAY];
>>>> +} EFI_MM_COMMUNICATE_HEADER;
>>>> +```
>>>> +
>>>> +## Benefits of the change
>>>> +
>>>> +In PI Spec v1.7 Errata A, Vol.4, Sec 5.7 MM Communication Protocol,
>>>> +the
>>>> MessageLength field of `EFI_MM_COMMUNICATE_HEADER` (also
>> defined as
>>>> `EFI_SMM_COMMUNICATE_HEADER`) is defined as type UINTN.
>>>> +
>>>> +But this structure, as a generic definition, could be used for both
>>>> +PEI and
>>>> DXE MM communication. Thus for a system that supports PEI MM launch,
>>>> but operates PEI in 32bit mode and MM foundation in 64bit, the
>>>> current `EFI_MM_COMMUNICATE_HEADER` definition will cause
>> structure
>>>> parse error due to UINTN used.
>>>> +
>>>> +## Impact of the change
>>>> +
>>>> +This change will impact the known structure consumers including:
>>>> +
>>>> +```bash
>>>> +MdeModulePkg/Core/PiSmmCore/PiSmmIpl
>>>> +MdeModulePkg/Application/SmiHandlerProfileInfo
>>>> +MdeModulePkg/Application/MemoryProfileInfo
>>>> +```
>>>> +
>>>> +For consumers that are not using
>>>> `OFFSET_OF(EFI_MM_COMMUNICATE_HEADER, Data)`, but performing
>> explicit
>>>> addition such as the existing
>>>>
>> MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.
>>>> c, one will need to change code implementation to match new structure
>>>> definition. Otherwise, the code compiled on IA32 architecture will
>>>> experience structure field dereference error.
>>>> +
>>>> +User who currently uses UINTN local variables as place holder of
>>>> MessageLength will need to use caution to make cast from UINTN to
>>>> UINT64 and vice versa. It is recommended to use `SafeUint64ToUintn`
>>>> for such operations when the value is indeterministic.
>>>> +
>>>> +Note: MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib is
>> also
>>>> consuming this structure, but it handled this size discrepancy
>>>> internally. If this
>>>
>>>
>>> Hello Kun,
>>>
>>> Sorry for a question.
>>> I am not sure why the current codes in file SmmLockBoxDxeLib.c will work
>> properly after the UINTN -> UINT64 change.
>>>
>>> For example:
>>> LockBoxGetSmmCommBuffer():
>>>     MinimalSizeNeeded = sizeof (EFI_GUID) +
>>>                         sizeof (UINTN) +
>>>                         MAX (sizeof (EFI_SMM_LOCK_BOX_PARAMETER_SAVE),
>>>                              MAX (sizeof
>> (EFI_SMM_LOCK_BOX_PARAMETER_SET_ATTRIBUTES),
>>>                                   MAX (sizeof
>> (EFI_SMM_LOCK_BOX_PARAMETER_UPDATE),
>>>                                        MAX (sizeof
>> (EFI_SMM_LOCK_BOX_PARAMETER_RESTORE),
>>>                                             sizeof
>>> (EFI_SMM_LOCK_BOX_PARAMETER_RESTORE_ALL_IN_PLACE)))));
>>>
>>> SaveLockBox():
>>>     UINT8                           TempCommBuffer[sizeof(EFI_GUID) + sizeof(UINTN)
>> + sizeof(EFI_SMM_LOCK_BOX_PARAMETER_SAVE)];
>>>
>>> Is the series missed changes for SmmLockBoxDxeLib or I got something
>> wrong?
>>>
>>> Best Regards,
>>> Hao Wu
>>>
>>>
>>>> potential spec change is not applied, all applicable PEI MM
>>>> communicate callers will need to use the same routine as that of
>>>> SmmLockBoxPeiLib to invoke a properly populated
>>>> EFI_MM_COMMUNICATE_HEADER to be used in X64 MM foundation.
>>>> +
>>>> +## Detailed description of the change [normative updates]
>>>> +
>>>> +### Specification Changes
>>>> +
>>>> +1. In PI Specification v1.7 Errata A: Vol. 4 Page-91, the definition
>>>> +of
>>>> `EFI_MM_COMMUNICATE_HEADER` should be changed from current:
>>>> +
>>>> +```c
>>>> +typedef struct {
>>>> +  EFI_GUID  HeaderGuid;
>>>> +  UINTN     MessageLength;
>>>> +  UINT8     Data[ANYSIZE_ARRAY];
>>>> +} EFI_MM_COMMUNICATE_HEADER;
>>>> +```
>>>> +
>>>> +to:
>>>> +
>>>> +```c
>>>> +typedef struct {
>>>> +  EFI_GUID  HeaderGuid;
>>>> +  UINT64    MessageLength;
>>>> +  UINT8     Data[ANYSIZE_ARRAY];
>>>> +} EFI_MM_COMMUNICATE_HEADER;
>>>> +```
>>>> +
>>>> +### Code Changes
>>>> +
>>>> +1. Remove the explicit calculation of the offset of `Data` in
>>>> `EFI_MM_COMMUNICATE_HEADER`. Thus applicable calculations of
>>>> `sizeof(EFI_GUID) + sizeof(UINTN)` should be replaced with
>>>> `OFFSET_OF(EFI_MM_COMMUNICATE_HEADER, Data)` or similar
>> alternatives.
>>>> These calculations are identified in:
>>>> +
>>>> +```bash
>>>>
>> +MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.
>>>> c
>>>> +MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
>>>> +```
>>>> +
>>>> +1. Resolve potentially mismatched type between `UINTN` and `UINT64`.
>>>> This would occur when `MessageLength` or its derivitive are used for
>>>> local calculation with existing `UINTN` typed variables. Code change
>>>> regarding this perspective is per case evaluation: if the variables
>>>> involved are all deterministic values, and there is no overflow or
>>>> underflow risk, a cast operation (from `UINTN` to `UINT64`) can be
>>>> safely used. Otherwise, the calculation will be performed in `UINT64`
>>>> bitwidth and then convert to `UINTN` using `SafeUint64*` and
>>>> `SafeUint64ToUintn`, respectively. These operations are identified in:
>>>> +
>>>> +```bash
>>>> +MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
>>>>
>> +MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.
>>>> c
>>>> +MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
>>>> +```
>>>> +
>>>> +1. After all above changes applied and specification updated,
>>>> `MdePkg/Include/Protocol/MmCommunication.h` will need to be
>> updated
>>>> to match new definition that includes the field type update.
>>>> --
>>>> 2.31.1.windows.1
>>>>
>>>>
>>>>
>>>>
>>>>
>>>




 


Re: Need help with CI/CD failure for the PR

Michael D Kinney
 

Liming,

Looks like it failed to build BaseTools:

https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=24448&view=logs&jobId=4a97f94c-8e1f-5e76-68ba-50872604dd63&j=2640d2b2-7c53-5a2b-80c7-040377c664fd&t=9d40d6fd-f2ec-5369-fb67-2d935d8d6b47

This PR modified GenFw, so it is likely related.

You have to download artifact to see the detailed log. Select "BASETOOLS_BUILD.txt from the following link:

https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=24448&view=artifacts&pathAsName=false&type=publishedArtifacts


INFO - Microsoft (R) Program Maintenance Utility Version 14.29.30038.1
INFO - Copyright (C) Microsoft Corporation. All rights reserved.
INFO -
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D _CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I D:\a\1\s\BaseTools\Source\C\Include -I D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I D:\a\1\s\BaseTools\Source\C\Common GenFw.c -FoGenFw.obj
INFO - GenFw.c
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D _CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I D:\a\1\s\BaseTools\Source\C\Include -I D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I D:\a\1\s\BaseTools\Source\C\Common ElfConvert.c -FoElfConvert.obj
INFO - ElfConvert.c
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D _CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I D:\a\1\s\BaseTools\Source\C\Include -I D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I D:\a\1\s\BaseTools\Source\C\Common Elf32Convert.c -FoElf32Convert.obj
INFO - Elf32Convert.c
INFO - cl.exe -c /nologo /Zi /c /O2 /MT /W4 /WX /D _CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE -I . -I D:\a\1\s\BaseTools\Source\C\Include -I D:\a\1\s\BaseTools\Source\C\Include\Ia32 -I D:\a\1\s\BaseTools\Source\C\Common Elf64Convert.c -FoElf64Convert.obj
INFO - Elf64Convert.c
INFO - Elf64Convert.c(540): error C2220: the following warning is treated as an error
INFO - Elf64Convert.c(540): warning C4244: '=': conversion from 'Elf64_Addr' to 'UINT32', possible loss of data
INFO - NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30037\bin\HostX86\x86\cl.exe"' : return code '0x2'
INFO - Stop.
INFO -
INFO - NMAKE : fatal error U1077: 'if' : return code '0x1'
INFO - Stop.
INFO - NMAKE : fatal error U1077: 'if' : return code '0x1'
INFO - Stop.
INFO - ------------------------------------------------
INFO - --------------Cmd Output Finished---------------
INFO - --------- Running Time (mm:ss): 00:29 ----------
INFO - ----------- Return Code: 0x00000002 ------------
INFO - ------------------------------------------------

Best regardm,

Mike

-----Original Message-----
From: gaoliming <gaoliming@byosoft.com.cn>
Sent: Wednesday, June 23, 2021 6:45 PM
To: 'Sunil V L' <sunilvl@ventanamicro.com>; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>; 'Sean
Brogan' <sean.brogan@microsoft.com>
Cc: 'Chang, Abner (HPS SW/FW Technologist)' <abner.chang@hpe.com>; 'Schaefer, Daniel' <daniel.schaefer@hpe.com>
Subject: 回复: Need help with CI/CD failure for the PR

Mike and Sean:
Have you any idea on how to find the error message in PR failure report?

For this PR https://github.com/tianocore/edk2/pull/1738, I don't find the real error message.

Thanks
Liming
-----邮件原件-----
发件人: Sunil V L <sunilvl@ventanamicro.com>
发送时间: 2021年6月22日 18:53
收件人: devel@edk2.groups.io
抄送: gaoliming@byosoft.com.cn; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@hpe.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>
主题: Need help with CI/CD failure for the PR

Hi,

The PR https://github.com/tianocore/edk2/pull/1738 has hit error with below
message.

"PR can not be merged due to a Windows VS2019 failure. Please resolve and
resubmit"

Unfortunately, I am unable to gather any details why it is failing. Also, I don't
have VS2019 build environment to try the build myself. Could some one with
VS2019 or knowledge of this build environment help me what exactly is the
issue with my patch?

Thanks in advance!

Sunil


Re: [PATCHV2] CryptoPkg/BaseCryptLib: Enabled CryptSha512 for Smm/Runtime drivers

Wang, Jian J
 

Pushed at eba32695ee6979137c86c3d20d0711d49d5c3ba8

Regards,
Jian

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@intel.com>
Sent: Thursday, June 24, 2021 10:06 AM
To: devel@edk2.groups.io; gaoliming@byosoft.com.cn; Xue, Shengfeng
<xueshengfeng@byosoft.com.cn>; Wang, Jian J <jian.j.wang@intel.com>
Cc: Xue, ShengfengX <shengfengx.xue@intel.com>
Subject: RE: [edk2-devel] [PATCHV2] CryptoPkg/BaseCryptLib: Enabled
CryptSha512 for Smm/Runtime drivers

Ah. Yes. I think so.

Hi Jian
Can you help on that?

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of gaoliming
Sent: Thursday, June 24, 2021 9:30 AM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Xue,
Shengfeng <xueshengfeng@byosoft.com.cn>; Wang, Jian J
<jian.j.wang@intel.com>
Cc: Xue, ShengfengX <shengfengx.xue@intel.com>
Subject: 回复: [edk2-devel] [PATCHV2] CryptoPkg/BaseCryptLib: Enabled
CryptSha512 for Smm/Runtime drivers

So far, there is no objection for this patch. How about merge it?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Yao, Jiewen
发送时间: 2021年6月9日 11:08
收件人: Xue, Shengfeng <xueshengfeng@byosoft.com.cn>;
devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>
抄送: Xue, ShengfengX <shengfengx.xue@intel.com>
主题: Re: [edk2-devel] [PATCHV2] CryptoPkg/BaseCryptLib: Enabled
CryptSha512 for Smm/Runtime drivers

Thank you! Shengfeng

Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>

I recommend to wait for *1 week*, to see if anyone has concern on size
change.

Thank you
Yao Jiewen


-----Original Message-----
From: xueshengfeng <xueshengfeng@byosoft.com.cn>
Sent: Tuesday, June 8, 2021 12:31 PM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Wang,
Jian J
<jian.j.wang@intel.com>
Cc: Xue, ShengfengX <shengfengx.xue@intel.com>
Subject: [PATCHV2] CryptoPkg/BaseCryptLib: Enabled CryptSha512 for
Smm/Runtime drivers

Intel Platform utility Syscfg/sysfwupdt will trigger SMI
to enter BIOS interface. then BIOS invoke EncodePassword
in SMM mode to check password.
it's need sha384(in CryptSha512.c) in SMM mode.

the origin SmmCryptLib.lib size is 1389KB,
after changed, the size is 1391KB.

the origin RuntimeCryptLib.lib size is 911KB,
after changed,the size is 913KB.

in SmmCryptLib.inf and RuntimeCryptLib.inf,
change CryptSha512NULL.c to CryptSha512.c.

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

Signed-off-by: xueshengfeng <xueshengfeng@byosoft.com.cn>
---
CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf | 6 +++---
CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
index 3d3a6fb94a..fdbb6edfd2 100644
--- a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
@@ -11,8 +11,8 @@
# functions, PKCS#7 SignedData sign functions, Diffie-Hellman
functions,
and
# authenticode signature verification functions are not supported in
this
instance.
#
-# Copyright (c) 2009 - 2020, Intel Corporation. All rights
reserved.<BR>
-# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All
rights
reserved.<BR>
+# Copyright (c) 2009 - 2021, Intel Corporation. All rights
reserved.<BR>
+# Copyright (c) 2021, Hewlett Packard Enterprise Development LP. All
rights
reserved.<BR>
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
@@ -39,7 +39,7 @@
Hash/CryptSha1.c
Hash/CryptSha256.c
Hash/CryptSm3.c
- Hash/CryptSha512Null.c
+ Hash/CryptSha512.c
Hmac/CryptHmacSha256.c
Kdf/CryptHkdf.c
Cipher/CryptAes.c
diff --git a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
index 07c376ce04..e6470d7a21 100644
--- a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
@@ -10,7 +10,7 @@
# RSA external functions, PKCS#7 SignedData sign functions,
Diffie-Hellman
functions, and
# authenticode signature verification functions are not supported in
this
instance.
#
-# Copyright (c) 2010 - 2020, Intel Corporation. All rights
reserved.<BR>
+# Copyright (c) 2010 - 2021, Intel Corporation. All rights
reserved.<BR>
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
@@ -37,7 +37,7 @@
Hash/CryptSha1.c
Hash/CryptSha256.c
Hash/CryptSm3.c
- Hash/CryptSha512Null.c
+ Hash/CryptSha512.c
Hmac/CryptHmacSha256.c
Kdf/CryptHkdfNull.c
Cipher/CryptAes.c
--
2.31.1.windows.1









Re: [PATCHV2] CryptoPkg/BaseCryptLib: Enabled CryptSha512 for Smm/Runtime drivers

Yao, Jiewen
 

Ah. Yes. I think so.

Hi Jian
Can you help on that?

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of gaoliming
Sent: Thursday, June 24, 2021 9:30 AM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Xue,
Shengfeng <xueshengfeng@byosoft.com.cn>; Wang, Jian J
<jian.j.wang@intel.com>
Cc: Xue, ShengfengX <shengfengx.xue@intel.com>
Subject: 回复: [edk2-devel] [PATCHV2] CryptoPkg/BaseCryptLib: Enabled
CryptSha512 for Smm/Runtime drivers

So far, there is no objection for this patch. How about merge it?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Yao, Jiewen
发送时间: 2021年6月9日 11:08
收件人: Xue, Shengfeng <xueshengfeng@byosoft.com.cn>;
devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>
抄送: Xue, ShengfengX <shengfengx.xue@intel.com>
主题: Re: [edk2-devel] [PATCHV2] CryptoPkg/BaseCryptLib: Enabled
CryptSha512 for Smm/Runtime drivers

Thank you! Shengfeng

Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>

I recommend to wait for *1 week*, to see if anyone has concern on size
change.

Thank you
Yao Jiewen


-----Original Message-----
From: xueshengfeng <xueshengfeng@byosoft.com.cn>
Sent: Tuesday, June 8, 2021 12:31 PM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Wang,
Jian J
<jian.j.wang@intel.com>
Cc: Xue, ShengfengX <shengfengx.xue@intel.com>
Subject: [PATCHV2] CryptoPkg/BaseCryptLib: Enabled CryptSha512 for
Smm/Runtime drivers

Intel Platform utility Syscfg/sysfwupdt will trigger SMI
to enter BIOS interface. then BIOS invoke EncodePassword
in SMM mode to check password.
it's need sha384(in CryptSha512.c) in SMM mode.

the origin SmmCryptLib.lib size is 1389KB,
after changed, the size is 1391KB.

the origin RuntimeCryptLib.lib size is 911KB,
after changed,the size is 913KB.

in SmmCryptLib.inf and RuntimeCryptLib.inf,
change CryptSha512NULL.c to CryptSha512.c.

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

Signed-off-by: xueshengfeng <xueshengfeng@byosoft.com.cn>
---
CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf | 6 +++---
CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
index 3d3a6fb94a..fdbb6edfd2 100644
--- a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
@@ -11,8 +11,8 @@
# functions, PKCS#7 SignedData sign functions, Diffie-Hellman
functions,
and
# authenticode signature verification functions are not supported in
this
instance.
#
-# Copyright (c) 2009 - 2020, Intel Corporation. All rights
reserved.<BR>
-# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All
rights
reserved.<BR>
+# Copyright (c) 2009 - 2021, Intel Corporation. All rights
reserved.<BR>
+# Copyright (c) 2021, Hewlett Packard Enterprise Development LP. All
rights
reserved.<BR>
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
@@ -39,7 +39,7 @@
Hash/CryptSha1.c
Hash/CryptSha256.c
Hash/CryptSm3.c
- Hash/CryptSha512Null.c
+ Hash/CryptSha512.c
Hmac/CryptHmacSha256.c
Kdf/CryptHkdf.c
Cipher/CryptAes.c
diff --git a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
index 07c376ce04..e6470d7a21 100644
--- a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
@@ -10,7 +10,7 @@
# RSA external functions, PKCS#7 SignedData sign functions,
Diffie-Hellman
functions, and
# authenticode signature verification functions are not supported in
this
instance.
#
-# Copyright (c) 2010 - 2020, Intel Corporation. All rights
reserved.<BR>
+# Copyright (c) 2010 - 2021, Intel Corporation. All rights
reserved.<BR>
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
@@ -37,7 +37,7 @@
Hash/CryptSha1.c
Hash/CryptSha256.c
Hash/CryptSm3.c
- Hash/CryptSha512Null.c
+ Hash/CryptSha512.c
Hmac/CryptHmacSha256.c
Kdf/CryptHkdfNull.c
Cipher/CryptAes.c
--
2.31.1.windows.1









回复: [PATCH v1 4/4] .pytool/EccCheck: Set PACKAGES_PATH env var in Ecc

gaoliming
 

Pierre:

-----邮件原件-----
发件人: Pierre.Gondois@arm.com <Pierre.Gondois@arm.com>
发送时间: 2021年6月23日 15:23
收件人: devel@edk2.groups.io; Sean Brogan <sean.brogan@microsoft.com>;
Bret Barkelew <Bret.Barkelew@microsoft.com>; Michael D Kinney
<michael.d.kinney@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>;
Sami Mujawar <sami.mujawar@arm.com>
主题: [PATCH v1 4/4] .pytool/EccCheck: Set PACKAGES_PATH env var in Ecc

From: Pierre Gondois <Pierre.Gondois@arm.com>

When running Ecc on other repositories (e.g.: edk2-platforms with
edk2 as a submodule), edk2 modules are referenced.
E.g.: MdePkg/..
The PACKAGES_PATH env var can be used to reference other directories
containing packages. Set it so that Ecc can find these packages.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
---
.pytool/Plugin/EccCheck/EccCheck.py | 1 +
1 file changed, 1 insertion(+)

diff --git a/.pytool/Plugin/EccCheck/EccCheck.py
b/.pytool/Plugin/EccCheck/EccCheck.py
index 87f0e65a140f..49d143b32f91 100644
--- a/.pytool/Plugin/EccCheck/EccCheck.py
+++ b/.pytool/Plugin/EccCheck/EccCheck.py
@@ -67,6 +67,7 @@ class EccCheck(ICiBuildPlugin):
env = shell_environment.GetEnvironment()
env.set_shell_var('PYTHONPATH', python_path)
env.set_shell_var('WORKSPACE', workspace_path)
+ env.set_shell_var('PACKAGES_PATH',
":".join(Edk2pathObj.PackagePathList))
":" is Linux OS path separator. Windows OS path separator is ";".

Thanks
Liming
self.ECC_PASS = True
self.ApplyConfig(pkgconfig, workspace_path, basetools_path,
packagename)
modify_dir_list = self.GetModifyDir(packagename)
--
2.17.1


回复: Need help with CI/CD failure for the PR

gaoliming
 

Mike and Sean:
Have you any idea on how to find the error message in PR failure report?

For this PR https://github.com/tianocore/edk2/pull/1738, I don't find the real error message.

Thanks
Liming

-----邮件原件-----
发件人: Sunil V L <sunilvl@ventanamicro.com>
发送时间: 2021年6月22日 18:53
收件人: devel@edk2.groups.io
抄送: gaoliming@byosoft.com.cn; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@hpe.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>
主题: Need help with CI/CD failure for the PR

Hi,

The PR https://github.com/tianocore/edk2/pull/1738 has hit error with below
message.

"PR can not be merged due to a Windows VS2019 failure. Please resolve and
resubmit"

Unfortunately, I am unable to gather any details why it is failing. Also, I don't
have VS2019 build environment to try the build myself. Could some one with
VS2019 or knowledge of this build environment help me what exactly is the
issue with my patch?

Thanks in advance!

Sunil


回复: [edk2-devel] [PATCHV2] CryptoPkg/BaseCryptLib: Enabled CryptSha512 for Smm/Runtime drivers

gaoliming
 

So far, there is no objection for this patch. How about merge it?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Yao, Jiewen
发送时间: 2021年6月9日 11:08
收件人: Xue, Shengfeng <xueshengfeng@byosoft.com.cn>;
devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>
抄送: Xue, ShengfengX <shengfengx.xue@intel.com>
主题: Re: [edk2-devel] [PATCHV2] CryptoPkg/BaseCryptLib: Enabled
CryptSha512 for Smm/Runtime drivers

Thank you! Shengfeng

Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>

I recommend to wait for *1 week*, to see if anyone has concern on size
change.

Thank you
Yao Jiewen


-----Original Message-----
From: xueshengfeng <xueshengfeng@byosoft.com.cn>
Sent: Tuesday, June 8, 2021 12:31 PM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Wang,
Jian J
<jian.j.wang@intel.com>
Cc: Xue, ShengfengX <shengfengx.xue@intel.com>
Subject: [PATCHV2] CryptoPkg/BaseCryptLib: Enabled CryptSha512 for
Smm/Runtime drivers

Intel Platform utility Syscfg/sysfwupdt will trigger SMI
to enter BIOS interface. then BIOS invoke EncodePassword
in SMM mode to check password.
it's need sha384(in CryptSha512.c) in SMM mode.

the origin SmmCryptLib.lib size is 1389KB,
after changed, the size is 1391KB.

the origin RuntimeCryptLib.lib size is 911KB,
after changed,the size is 913KB.

in SmmCryptLib.inf and RuntimeCryptLib.inf,
change CryptSha512NULL.c to CryptSha512.c.

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

Signed-off-by: xueshengfeng <xueshengfeng@byosoft.com.cn>
---
CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf | 6 +++---
CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
index 3d3a6fb94a..fdbb6edfd2 100644
--- a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
@@ -11,8 +11,8 @@
# functions, PKCS#7 SignedData sign functions, Diffie-Hellman
functions,
and
# authenticode signature verification functions are not supported in
this
instance.
#
-# Copyright (c) 2009 - 2020, Intel Corporation. All rights
reserved.<BR>
-# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All
rights
reserved.<BR>
+# Copyright (c) 2009 - 2021, Intel Corporation. All rights
reserved.<BR>
+# Copyright (c) 2021, Hewlett Packard Enterprise Development LP. All
rights
reserved.<BR>
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
@@ -39,7 +39,7 @@
Hash/CryptSha1.c
Hash/CryptSha256.c
Hash/CryptSm3.c
- Hash/CryptSha512Null.c
+ Hash/CryptSha512.c
Hmac/CryptHmacSha256.c
Kdf/CryptHkdf.c
Cipher/CryptAes.c
diff --git a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
index 07c376ce04..e6470d7a21 100644
--- a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
@@ -10,7 +10,7 @@
# RSA external functions, PKCS#7 SignedData sign functions,
Diffie-Hellman
functions, and
# authenticode signature verification functions are not supported in
this
instance.
#
-# Copyright (c) 2010 - 2020, Intel Corporation. All rights
reserved.<BR>
+# Copyright (c) 2010 - 2021, Intel Corporation. All rights
reserved.<BR>
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
@@ -37,7 +37,7 @@
Hash/CryptSha1.c
Hash/CryptSha256.c
Hash/CryptSm3.c
- Hash/CryptSha512Null.c
+ Hash/CryptSha512.c
Hmac/CryptHmacSha256.c
Kdf/CryptHkdfNull.c
Cipher/CryptAes.c
--
2.31.1.windows.1



9141 - 9160 of 86113