Date   

Re: [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c

Gerd Hoffmann
 

Hi,

I can't see any support for Cloud-Hypervisor in OVMF.
Right that currently OVMF is not supported by Cloud-Hypervisor in Td guest. But we're
planning to support Cloud-Hypervisor to launch OVMF in Td guest and have done
some POC.
Also FreeBSD's bhyve doesn't support fw_cfg either and has its own ways to
detect memory. Cloud-Hypervisor can surely do that too.

So, why does this matter?
Yes, Cloud-Hypervisor has some POC to launch OVMF in Non-Td guest. In that POC
Cloud-Hypervisor leverage a 4k page in MEMFD and pass ACPI data to guest
Firmware in that memory.
https://github.com/cloud-hypervisor/edk2 "ch" branch
https://github.com/cloud-hypervisor/edk2/commit/52cb72a748ef70833100ca664f6c2a704c28a93f
Post the Cloud-Hypervisor patches to the list for review if you want
them included in OVMF. out-of-tree patches lingering in some random
branch @ github do not matter.

https://github.com/cloud-hypervisor/cloud-hypervisor
TD Hob list gives Cloud-Hypervisor a chance to pass information to guest
firmware.
For example, ACPI can be downloaded from QEMU via fw_cfg to firmware.
But Cloud-Hypervisor cannot pass ACPI via fw_cfg. In this situation,
TD Hob can resolve this problem.
Sure, but again, why does this matter? For qemu?
I don't quite understand the question here(For qumu?).
Well, each VMM has different interfaces for guest <-> host
communication. qemu/kvm uses fw_cfg. Xen and Bhyve have something
different, and Cloud-Hypervisor seems to have something different again.

What I mean in my last answer is that TD Hob can resolve the problem
when the host VMM doesn't support fw_cfg communication mechanism.
Sure. If Cloud-Hypervisor wants use that (for both TDX and non-TDX
probably), fine. Submit the patches and we can discuss details.

But why do you want switch qemu/kvm from fw_cfg to TD Hob?

I don't like the idea to have TDX take a completely different code
paths. That increases the code complexity and makes testing harder
for no good reason.
TD Hob is not a completely different code path. This is a useful
supplement to the fw_cfg which is not supported by some host VMM.
The code uses that unconditionally though and not only in case fw_cfg
is not available.

From another perspective TD Hob can be treated as a set of launch
parameter by host VMM. It provides the flexibility for the host VMM
to bring up the guest firmware with more parameters.
I'm wondering what you are running on the host? I assumed we are
discussing qemu/kvm as VMM, is that actually the case? Or do you
use Cloud Hypervisor?

qemu doesn't provide a TD Hob. So, when running qemu you probably have
some out-of-tree patches adding that. Have you submitted them upstream?
What is the status?

I suspect you need to come up with some *very* good arguments to get
that accepted. The need to bring parameters to the guest firmware is
the reason why fw_cfg exists in the first place ...

Another benefit is that TD Hob can be measured into some secure
register (for example, in TD guest it is RTMR registers, like the TPM
PCR) so that attestation can be done based on the measurement.
fw_cfg is measured too (according to one of the tdx pdfs, don't remember
which one).

take care,
Gerd


Re: [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c

Yao, Jiewen
 

HI Ard and Gerd
I am not sure if I fully understand the argument here.

In TDX architecture, the VMM provides a pointer to the TD guest as initial parameter. We define the detail information there to be TD Hob. This solution is generic to all hypervisor.

fw_cfg is just a KVM/QEMU specific way to pass some parameter, but not all parameter.
For example, OVMF today still get the memory size from CMOS.
https://github.com/tianocore/edk2/blob/master/OvmfPkg/PlatformPei/MemDetect.c#L278

In TDVF design, we choose the use TDX defined initial pointer to pass the initial memory information - TD_HOB, instead of CMOS region.
Please help me understand what is the real concern here.



I understand the QEMU specific fw_cfg (https://github.com/qemu/qemu/blob/master/docs/specs/fw_cfg.txt).
If you want to use fw_cfg to pass some QEMU specific parameter, it is still possible.
For security reason, any input from the IO device must be measured by the TD guest.

That means, if you get the same data twice from the fw_cfg, the TDVF must measure them twice. And TDVF may need handle the case that the data in first call is different with the data in second call.
I can see potential attack surface there from architecture perspective.

Using HOB in the initial pointer can be an alternative pattern to mitigate such risk. We just need measure them once then any component can use that. Also, it can help the people to evaluate the RTMR hash and TD event log data for the configuration in attestation flow, because the configuration is independent with the code execution flow.

Please be aware that confidential computing (TDX) changes the threat model completely, any input from VMM is considered as malicious. Current solution might be OK for normal OVMF. But it does not mean the same solution is still the best one for confidential computing use case.


Thank you
Yao Jiewen

-----Original Message-----
From: Ard Biesheuvel <ardb@...>
Sent: Tuesday, August 24, 2021 8:56 PM
To: Xu, Min M <min.m.xu@...>
Cc: Gerd Hoffmann <kraxel@...>; devel@edk2.groups.io; Ard
Biesheuvel <ardb+tianocore@...>; Justen, Jordan L
<jordan.l.justen@...>; Brijesh Singh <brijesh.singh@...>; Erdem
Aktas <erdemaktas@...>; James Bottomley <jejb@...>;
Yao, Jiewen <jiewen.yao@...>; Tom Lendacky
<thomas.lendacky@...>
Subject: Re: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c

On Tue, 24 Aug 2021 at 14:07, Xu, Min M <min.m.xu@...> wrote:

On August 20, 2021 3:23 PM, Gerd Hoffmann wrote:
On Thu, Aug 19, 2021 at 02:27:16PM +0000, Min Xu wrote:
On August 19, 2021 2:50 PM, Gerd Hoffmann wrote:
+/**
+ In Tdx guest, some information need to be passed from host VMM
+to
guest
+ firmware. For example, the memory resource, etc. These
+ information are prepared by host VMM and put in HobList which
+ is described in
TdxMetadata.

What kind of information is passed to the guest here?
Please see
https://software.intel.com/content/dam/develop/external/us/en/document
s/tdx-virtual-firmware-design-guide-rev-1.pdf
Section 4.2 TD Hand-Off Block (HOB)
So basically the physical memory map.
qemu has etc/e820 for that.

qemu has fw_cfg to pass information from the VMM to the guest
firmware.
What are the reasons to not use fw_cfg?
Not all the VMM support fw_cfg. Cloud-Hypervisor is the example.
I can't see any support for Cloud-Hypervisor in OVMF.
Right that currently OVMF is not supported by Cloud-Hypervisor in Td guest.
But we're
planning to support Cloud-Hypervisor to launch OVMF in Td guest and have
done
some POC.
If cloud hypervisor support is coming to OVMF, please contribute those
patches first, so they can be discussed in public. Adding special
facilities here to accommodate out of tree functionality that may look
completely differently after review is not the right way to approach
this.

--
Ard.



Also FreeBSD's bhyve doesn't support fw_cfg either and has its own ways to
detect memory. Cloud-Hypervisor can surely do that too.

So, why does this matter?
Yes, Cloud-Hypervisor has some POC to launch OVMF in Non-Td guest. In that
POC
Cloud-Hypervisor leverage a 4k page in MEMFD and pass ACPI data to guest
Firmware in that memory.
https://github.com/cloud-hypervisor/edk2 "ch" branch
https://github.com/cloud-
hypervisor/edk2/commit/52cb72a748ef70833100ca664f6c2a704c28a93f

https://github.com/cloud-hypervisor/cloud-hypervisor
TD Hob list gives Cloud-Hypervisor a chance to pass information to guest
firmware.
For example, ACPI can be downloaded from QEMU via fw_cfg to firmware.
But Cloud-Hypervisor cannot pass ACPI via fw_cfg. In this situation,
TD Hob can resolve this problem.
Sure, but again, why does this matter? For qemu?
I don't quite understand the question here(For qumu?).
What I mean in my last answer is that TD Hob can resolve the problem when
the host VMM
doesn't support fw_cfg communication mechanism.
For the host VMMs which doesn't support fw_cfg, when ACPI data need to be
passed to guest
firmware, a 4k page (to hold ACPI data) is added in MEMFD. Then when
SMBIOS is needed,
shall we add another page in MEMFD? If the ACPI data is too big to be held in a
4k page, then
the size of the reserved memory region in MEMFD is the restriction.

I don't like the idea to have TDX take a completely different code paths.
That increases the code complexity and makes testing harder for no good
reason.
TD Hob is not a completely different code path. This is a useful supplement to
the fw_cfg which
is not supported by some host VMM.
From another perspective TD Hob can be treated as a set of launch parameter
by host VMM.
It provides the flexibility for the host VMM to bring up the guest firmware with
more parameters.
Another benefit is that TD Hob can be measured into some secure register (for
example, in TD guest
it is RTMR registers, like the TPM PCR) so that attestation can be done based
on the measurement.

Thanks Gerd for the comments. I am not sure if my explanation addressed your
concern. Your comments
is always welcomed.
Thanks!
Min


Re: [PATCH 1/2] OvmfPkg/PlatformPei: ScanOrAdd64BitE820Ram improvements

Philippe Mathieu-Daudé <philmd@...>
 

On 8/19/21 10:11 AM, Gerd Hoffmann wrote:
Add a bool parameter to ScanOrAdd64BitE820Ram to explicitly specify
whenever ScanOrAdd64BitE820Ram should add HOBs for high memory (above
4G) or scan only.

Also add a lowmem parameter so ScanOrAdd64BitE820Ram
can report the memory size below 4G.

This allows a more flexible usage of ScanOrAdd64BitE820Ram,
a followup patch will use it for all memory detection.

No functional change.

Signed-off-by: Gerd Hoffmann <kraxel@...>
---
OvmfPkg/PlatformPei/MemDetect.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
Reviewed-by: Philippe Mathieu-Daude <philmd@...>


[PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Update mPatchCetSupported set condition

Wenxing Hou
 

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


Function AsmCpuid should frist check the
Value for Basic CPUID Information.The fix is to
update the mPatchCetSupported judgment statement.
=0D

Signed-off-by: Wenxing Hou <wenxing.hou@...>
Cc: Eric Dong <eric.dong@...>
Cc: Ray Ni <ray.ni@...>
Cc: Rahul Kumar <rahul1.kumar@...>
Cc: Sheng W <w.sheng@...>
Cc: Yao Jiewen <jiewen.yao@...>
---
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 11 +++++++----
UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 14 ++++++++------
2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c b/UefiCpuPkg/PiSmmC=
puDxeSmm/PiSmmCpuDxeSmm.c
index db68e1316e..e394da7095 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -729,10 +729,10 @@ PiCpuSmmEntry (
=0D
DEBUG ((DEBUG_INFO, "PcdControlFlowEnforcementPropertyMask =3D %d\n", Pc=
dGet32 (PcdControlFlowEnforcementPropertyMask)));=0D
if (PcdGet32 (PcdControlFlowEnforcementPropertyMask) !=3D 0) {=0D
- AsmCpuid (CPUID_EXTENDED_FUNCTION, &RegEax, NULL, NULL, NULL);=0D
- if (RegEax > CPUID_EXTENDED_FUNCTION) {=0D
+ AsmCpuid(CPUID_SIGNATURE, &RegEax, NULL, NULL, NULL);=0D
+ if (RegEax >=3D CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS) {=0D
AsmCpuidEx (CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS, CPUID_STRUCTURE=
D_EXTENDED_FEATURE_FLAGS_SUB_LEAF_INFO, NULL, NULL, &RegEcx, &RegEdx);=0D
- DEBUG ((DEBUG_INFO, "CPUID[7/0] ECX - 0x%08x\n", RegEcx));=0D
+ DEBUG ((DEBUG_INFO, " CPUID[7/0] ECX - 0x%08x\n", RegEcx));=0D
DEBUG ((DEBUG_INFO, " CET_SS - 0x%08x\n", RegEcx & CPUID_CET_SS));=
=0D
DEBUG ((DEBUG_INFO, " CET_IBT - 0x%08x\n", RegEdx & CPUID_CET_IBT))=
;=0D
if ((RegEcx & CPUID_CET_SS) =3D=3D 0) {=0D
@@ -747,7 +747,10 @@ PiCpuSmmEntry (
AsmCpuidEx(CPUID_EXTENDED_STATE, 12, &RegEax, NULL, &RegEcx, NULL)=
;=0D
DEBUG ((DEBUG_INFO, "CPUID[D/12] EAX - 0x%08x, ECX - 0x%08x\n", Re=
gEax, RegEcx));=0D
}=0D
- }=0D
+ } else {=0D
+ mCetSupported =3D FALSE;=0D
+ PatchInstructionX86(mPatchCetSupported, mCetSupported, 1);=0D
+ }=0D
} else {=0D
mCetSupported =3D FALSE;=0D
PatchInstructionX86 (mPatchCetSupported, mCetSupported, 1);=0D
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c b/UefiCpuPkg/PiSmmCpuDx=
eSmm/SmmProfile.c
index d7ed9ab7a7..f4d39c6967 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -985,13 +985,15 @@ CheckFeatureSupported (
MSR_IA32_MISC_ENABLE_REGISTER MiscEnableMsr;=0D
=0D
if ((PcdGet32 (PcdControlFlowEnforcementPropertyMask) !=3D 0) && mCetSup=
ported) {=0D
- AsmCpuid (CPUID_EXTENDED_FUNCTION, &RegEax, NULL, NULL, NULL);=0D
- if (RegEax <=3D CPUID_EXTENDED_FUNCTION) {=0D
- mCetSupported =3D FALSE;=0D
- PatchInstructionX86 (mPatchCetSupported, mCetSupported, 1);=0D
+ AsmCpuid(CPUID_SIGNATURE, &RegEax, NULL, NULL, NULL);=0D
+ if (RegEax >=3D CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS) {=0D
+ AsmCpuidEx(CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS, CPUID_STRUCTURED_=
EXTENDED_FEATURE_FLAGS_SUB_LEAF_INFO, NULL, NULL, &RegEcx, NULL);=0D
+ if ((RegEcx & CPUID_CET_SS) =3D=3D 0) {=0D
+ mCetSupported =3D FALSE;=0D
+ PatchInstructionX86(mPatchCetSupported, mCetSupported, 1);=0D
+ }=0D
}=0D
- AsmCpuidEx (CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS, CPUID_STRUCTURED_=
EXTENDED_FEATURE_FLAGS_SUB_LEAF_INFO, NULL, NULL, &RegEcx, NULL);=0D
- if ((RegEcx & CPUID_CET_SS) =3D=3D 0) {=0D
+ else {=0D
mCetSupported =3D FALSE;=0D
PatchInstructionX86 (mPatchCetSupported, mCetSupported, 1);=0D
}=0D
--=20
2.26.2.windows.1


Re: about raise patch in EDK2

Andrew Fish
 

You are not subscribed so all your posts have to be manually approved.


On Aug 24, 2021, at 8:25 PM, Hou, Wenxing <wenxing.hou@...> wrote:



Hi

              I raise a patch to EDK2. But, I get the message:    

“The following message to <devel@edk2.groups.io> was undeliverable.

The reason for the problem:   5.3.0 - Other mail system problem 500-'This message has been flagged as spam.'”

             

             So  I want to get the method  for this problem.

 

 

Thank you!


about raise patch in EDK2

Hou, Wenxing <wenxing.hou@...>
 

Hi

              I raise a patch to EDK2. But, I get the message:    

“The following message to <devel@edk2.groups.io> was undeliverable.

The reason for the problem:   5.3.0 - Other mail system problem 500-'This message has been flagged as spam.'”

             

             So  I want to get the method  for this problem.

 

 

Thank you!


Question regarding subscription and mailing list

jinjhuli
 

Hi,

 

Good Day!

May I know how can I subscribe and receive mailing list for this group?

 

Thanks.

Regards,

Jin Jhu

 


Event: TianoCore Bug Triage - APAC / NAMO - 08/24/2021 #cal-reminder

devel@edk2.groups.io Calendar <noreply@...>
 

Reminder: TianoCore Bug Triage - APAC / NAMO

When:
08/24/2021
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

Organizer: Liming Gao gaoliming@...

View Event

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,77463821#   United States, Sacramento

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


Re: [PATCH v3 1/4] UefiPayloadPkg: Add LINUXBOOT payload target

Ni, Ray
 

Can you describe how LINUXBOOT payload is supported in the commit message?
One line commit message is too simple for such a big feature😊

-----Original Message-----
From: Cheng-Chieh Huang <chengchieh@...>
Sent: Monday, August 23, 2021 2:33 PM
To: devel@edk2.groups.io
Cc: Cheng-Chieh Huang <chengchieh@...>; Schaefer, Daniel <daniel.schaefer@...>; Trammell Hudson
<hudson@...>; Ma, Maurice <maurice.ma@...>; Dong, Guo <guo.dong@...>; You, Benjamin
<benjamin.you@...>; Ni, Ray <ray.ni@...>
Subject: [PATCH v3 1/4] UefiPayloadPkg: Add LINUXBOOT payload target

Initial commit to support linuxboot payload.

Signed-off-by: Cheng-Chieh Huang <chengchieh@...>
Cc: Cheng-Chieh Huang <chengchieh@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
Cc: Trammell Hudson <hudson@...>
Cc: Maurice Ma <maurice.ma@...>
Cc: Guo Dong <guo.dong@...>
Cc: Benjamin You <benjamin.you@...>
Cc: Ray Ni <ray.ni@...>
---
UefiPayloadPkg/UefiPayloadPkg.dsc | 16 +-
.../Library/LbParseLib/LbParseLib.inf | 39 ++++
UefiPayloadPkg/Library/LbParseLib/Linuxboot.h | 47 +++++
.../Library/LbParseLib/LbParseLib.c | 187 ++++++++++++++++++
.../PciHostBridgeLib/PciHostBridgeSupport.c | 6 +-
5 files changed, 288 insertions(+), 7 deletions(-)
create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.inf
create mode 100644 UefiPayloadPkg/Library/LbParseLib/Linuxboot.h
create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.c

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc b/UefiPayloadPkg/UefiPayloadPkg.dsc
index bcedf1c746b4..54576ba485b7 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -33,6 +33,7 @@ [Defines]
#
# SBL: UEFI payload for Slim Bootloader
# COREBOOT: UEFI payload for coreboot
+ # LINUXBOOT: UEFI payload for linuxboot
#
DEFINE BOOTLOADER = SBL

@@ -93,6 +94,9 @@ [Defines]

[BuildOptions]
*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+!if $(BOOTLOADER) == "LINUXBOOT"
+ *_*_*_CC_FLAGS = -D LINUXBOOT_PAYLOAD
+!endif
GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
@@ -222,11 +226,13 @@ [LibraryClasses]
!endif
PlatformSupportLib|UefiPayloadPkg/Library/PlatformSupportLibNull/PlatformSupportLibNull.inf
!if $(UNIVERSAL_PAYLOAD) == FALSE
- !if $(BOOTLOADER) == "COREBOOT"
- BlParseLib|UefiPayloadPkg/Library/CbParseLib/CbParseLib.inf
- !else
- BlParseLib|UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf
- !endif
+ !if $(BOOTLOADER) == "COREBOOT"
+ BlParseLib|UefiPayloadPkg/Library/CbParseLib/CbParseLib.inf
+ !elseif $(BOOTLOADER) == "LINUXBOOT"
+ BlParseLib|UefiPayloadPkg/Library/LbParseLib/LbParseLib.inf
+ !else
+ BlParseLib|UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf
+ !endif
!endif

DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
diff --git a/UefiPayloadPkg/Library/LbParseLib/LbParseLib.inf b/UefiPayloadPkg/Library/LbParseLib/LbParseLib.inf
new file mode 100644
index 000000000000..d75ba8db8cf3
--- /dev/null
+++ b/UefiPayloadPkg/Library/LbParseLib/LbParseLib.inf
@@ -0,0 +1,39 @@
+## @file
+# Linuxboot Table Parse Library.
+#
+# Copyright (c) 2021, the u-root Authors. All rights reserved.<BR>
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION = 0x00010005
+ BASE_NAME = LbParseLib
+ FILE_GUID = DBA15E1E-4C16-47DF-93C0-AB5888ED14C3
+ MODULE_TYPE = BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = BlParseLib
+
+#
+# The following information is for reference only and not required by the build tools.
+#
+# VALID_ARCHITECTURES = IA32 X64
+#
+
+[Sources]
+ LbParseLib.c
+
+[Packages]
+ MdePkg/MdePkg.dec
+ MdeModulePkg/MdeModulePkg.dec
+ UefiPayloadPkg/UefiPayloadPkg.dec
+
+[LibraryClasses]
+ BaseLib
+ BaseMemoryLib
+ IoLib
+ DebugLib
+ PcdLib
+
+[Pcd]
+ gUefiPayloadPkgTokenSpaceGuid.PcdPayloadFdMemBase
diff --git a/UefiPayloadPkg/Library/LbParseLib/Linuxboot.h b/UefiPayloadPkg/Library/LbParseLib/Linuxboot.h
new file mode 100644
index 000000000000..b3b7e70a7ccb
--- /dev/null
+++ b/UefiPayloadPkg/Library/LbParseLib/Linuxboot.h
@@ -0,0 +1,47 @@
+/** @file
+ LinuxBoot PEI module include file.
+**/
+#ifndef __LINUXBOOT_PEI_H_INCLUDED__
+#define __LINUXBOOT_PEI_H_INCLUDED__
+
+#if defined(_MSC_VER)
+#pragma warning(disable : 4200)
+#endif
+
+#pragma pack(1)
+typedef struct SerialPortConfigStruct {
+ UINT32 Type;
+ UINT32 BaseAddr;
+ UINT32 Baud;
+ UINT32 RegWidth;
+ UINT32 InputHertz;
+ UINT32 UartPciAddr;
+} SerialPortConfig;
+
+typedef struct MemoryMapEntryStruct {
+ UINT64 Start;
+ UINT64 End;
+ UINT32 Type;
+} MemoryMapEntry;
+
+typedef struct UefiPayloadConfigStruct {
+ UINT64 Version;
+ UINT64 AcpiBase;
+ UINT64 AcpiSize;
+ UINT64 SmbiosBase;
+ UINT64 SmbiosSize;
+ SerialPortConfig SerialConfig;
+ UINT32 NumMemoryMapEntries;
+ MemoryMapEntry MemoryMapEntries[0];
+} UefiPayloadConfig;
+#pragma pack()
+
+#define UEFI_PAYLOAD_CONFIG_VERSION 1
+
+#define LINUXBOOT_MEM_RAM 1
+#define LINUXBOOT_MEM_DEFAULT 2
+#define LINUXBOOT_MEM_ACPI 3
+#define LINUXBOOT_MEM_NVS 4
+#define LINUXBOOT_MEM_RESERVED 5
+
+#endif // __LINUXBOOT_PEI_H_INCLUDED__
diff --git a/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c b/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
new file mode 100644
index 000000000000..48d174dfc078
--- /dev/null
+++ b/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
@@ -0,0 +1,187 @@
+/** @file
+ This library will parse the linuxboot table in memory and extract those required
+ information.
+
+ Copyright (c) 2021, the u-root Authors. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+
+#include <IndustryStandard/Acpi.h>
+#include <IndustryStandard/SmBios.h>
+#include <Library/BaseLib.h>
+#include <Library/BaseMemoryLib.h>
+#include <Library/BlParseLib.h>
+#include <Library/DebugLib.h>
+#include <Library/IoLib.h>
+#include <Library/PcdLib.h>
+#include <Linuxboot.h>
+#include <Uefi/UefiBaseType.h>
+
+// Retrieve UefiPayloadConfig from Linuxboot's uefiboot
+UefiPayloadConfig*
+GetUefiPayLoadConfig()
+{
+ UefiPayloadConfig *Config;
+ Config = (UefiPayloadConfig*)(UINTN)(PcdGet32(PcdPayloadFdMemBase) - SIZE_64KB);
+ if (Config->Version != UEFI_PAYLOAD_CONFIG_VERSION) {
+ DEBUG((DEBUG_ERROR, "Expect payload Config version: %d, but get %d\n",
+ UEFI_PAYLOAD_CONFIG_VERSION, Config->Version));
+ CpuDeadLoop ();
+ }
+ return Config;
+}
+
+// Align the address and add memory rang to MemInfoCallback
+VOID
+AddMemoryRange (
+ IN BL_MEM_INFO_CALLBACK MemInfoCallback,
+ IN UINTN start,
+ IN UINTN end,
+ IN int type
+ ) {
+ MEMROY_MAP_ENTRY MemoryMap;
+ UINTN AlignedStart;
+ UINTN AlignedEnd;
+ AlignedStart = ALIGN_VALUE(start, SIZE_4KB);
+ AlignedEnd = ALIGN_VALUE(end, SIZE_4KB);
+ // Conservative adjustment on Memory map. This should happen when booting from
+ // non UEFI bios and it may report a memory region less than 4KB.
+ if (AlignedStart > start && type != LINUXBOOT_MEM_RAM) {
+ AlignedStart -= SIZE_4KB;
+ }
+ if (AlignedEnd > end + 1 && type == LINUXBOOT_MEM_RAM) {
+ AlignedEnd -= SIZE_4KB;
+ }
+ MemoryMap.Base = AlignedStart;
+ MemoryMap.Size = AlignedEnd - AlignedStart;
+ MemoryMap.Type = type;
+ MemoryMap.Flag = 0;
+ MemInfoCallback(&MemoryMap, NULL);
+}
+
+/**
+ Acquire the memory information from the linuxboot table in memory.
+
+ @param MemInfoCallback The callback routine
+ @param Params Pointer to the callback routine parameter
+
+ @retval RETURN_SUCCESS Successfully find out the memory information.
+ @retval RETURN_NOT_FOUND Failed to find the memory information.
+
+**/
+RETURN_STATUS
+EFIAPI
+ParseMemoryInfo (
+ IN BL_MEM_INFO_CALLBACK MemInfoCallback,
+ IN VOID* Params
+ ) {
+ UefiPayloadConfig *Config;
+ MemoryMapEntry* entry;
+ int Index;
+
+ Config = GetUefiPayLoadConfig();
+
+ DEBUG((DEBUG_INFO, "MemoryMap #entries: %d\n", Config->NumMemoryMapEntries));
+
+ entry = &Config->MemoryMapEntries[0];
+ for (Index = 0; Index < Config->NumMemoryMapEntries; Index++) {
+ DEBUG((DEBUG_INFO, "Start: 0x%lx End: 0x%lx Type:%d\n", entry->Start,
+ entry->End, entry->Type));
+ AddMemoryRange(MemInfoCallback, entry->Start, entry->End, entry->Type);
+ entry++;
+ }
+ return RETURN_SUCCESS;
+}
+
+/**
+ Acquire acpi table and smbios table from linuxboot
+
+ @param SystemTableInfo Pointer to the system table info
+
+ @retval RETURN_SUCCESS Successfully find out the tables.
+ @retval RETURN_NOT_FOUND Failed to find the tables.
+
+**/
+RETURN_STATUS
+EFIAPI
+ParseSystemTable (
+ OUT SYSTEM_TABLE_INFO* SystemTableInfo
+ ) {
+ UefiPayloadConfig *Config;
+
+ Config = GetUefiPayLoadConfig();
+ SystemTableInfo->AcpiTableBase = Config->AcpiBase;
+ SystemTableInfo->AcpiTableSize = Config->AcpiSize;
+
+ SystemTableInfo->SmbiosTableBase = Config->SmbiosBase;
+ SystemTableInfo->SmbiosTableSize = Config->SmbiosSize;
+
+ return RETURN_SUCCESS;
+}
+
+/**
+ Find the serial port information
+
+ @param SERIAL_PORT_INFO Pointer to serial port info structure
+
+ @retval RETURN_SUCCESS Successfully find the serial port information.
+ @retval RETURN_NOT_FOUND Failed to find the serial port information .
+
+**/
+RETURN_STATUS
+EFIAPI
+ParseSerialInfo (
+ OUT SERIAL_PORT_INFO* SerialPortInfo
+ ) {
+ UefiPayloadConfig *Config;
+ Config = GetUefiPayLoadConfig();
+
+ SerialPortInfo->BaseAddr = Config->SerialConfig.BaseAddr;
+ SerialPortInfo->RegWidth = Config->SerialConfig.RegWidth;
+ SerialPortInfo->Type = Config->SerialConfig.Type;
+ SerialPortInfo->Baud = Config->SerialConfig.Baud;
+ SerialPortInfo->InputHertz = Config->SerialConfig.InputHertz;
+ SerialPortInfo->UartPciAddr = Config->SerialConfig.UartPciAddr;
+
+ return RETURN_SUCCESS;
+}
+
+/**
+ Find the video frame buffer information
+
+ @param GfxInfo Pointer to the EFI_PEI_GRAPHICS_INFO_HOB structure
+
+ @retval RETURN_SUCCESS Successfully find the video frame buffer
+information.
+ @retval RETURN_NOT_FOUND Failed to find the video frame buffer information .
+
+**/
+RETURN_STATUS
+EFIAPI
+ParseGfxInfo (
+ OUT EFI_PEI_GRAPHICS_INFO_HOB* GfxInfo
+ ) {
+ // Not supported
+ return RETURN_NOT_FOUND;
+}
+
+/**
+ Find the video frame buffer device information
+
+ @param GfxDeviceInfo Pointer to the EFI_PEI_GRAPHICS_DEVICE_INFO_HOB
+structure
+
+ @retval RETURN_SUCCESS Successfully find the video frame buffer
+information.
+ @retval RETURN_NOT_FOUND Failed to find the video frame buffer information.
+
+**/
+RETURN_STATUS
+EFIAPI
+ParseGfxDeviceInfo (
+ OUT EFI_PEI_GRAPHICS_DEVICE_INFO_HOB* GfxDeviceInfo
+ ) {
+ return RETURN_NOT_FOUND;
+}
diff --git a/UefiPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c
b/UefiPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c
index b0268f05069c..a4f714f765ea 100644
--- a/UefiPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c
+++ b/UefiPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c
@@ -40,8 +40,9 @@ AdjustRootBridgeResource (
IN PCI_ROOT_BRIDGE_APERTURE *PMemAbove4G
)
{
+#ifndef LINUXBOOT_PAYLOAD
UINT64 Mask;
-
+#endif
//
// For now try to downgrade everything into MEM32 since
// - coreboot does not assign resource above 4GB
@@ -80,7 +81,7 @@ AdjustRootBridgeResource (
PMemAbove4G->Base = MAX_UINT64;
PMemAbove4G->Limit = 0;
}
-
+#ifndef LINUXBOOT_PAYLOAD
//
// Align IO resource at 4K boundary
//
@@ -98,6 +99,7 @@ AdjustRootBridgeResource (
if (Mem->Base != MAX_UINT64) {
Mem->Base &= ~Mask;
}
+#endif
}

/**
--
2.33.0.rc2.250.ged5fa647cd-goog


Re: [PATCH v3 2/4] UefiPayloadPkg: Use legacy timer in Linuxboot payload

Ni, Ray
 

can you explain more in commit message why HPET may fail?

-----Original Message-----
From: Cheng-Chieh Huang <chengchieh@...>
Sent: Monday, August 23, 2021 2:33 PM
To: devel@edk2.groups.io
Cc: Cheng-Chieh Huang <chengchieh@...>; Dong, Guo <guo.dong@...>; Schaefer, Daniel
<daniel.schaefer@...>; Trammell Hudson <hudson@...>; Ma, Maurice <maurice.ma@...>; You, Benjamin
<benjamin.you@...>; Ni, Ray <ray.ni@...>
Subject: [PATCH v3 2/4] UefiPayloadPkg: Use legacy timer in Linuxboot payload

HPET timer may fail to init after prior linux taking over.

Signed-off-by: Cheng-Chieh Huang <chengchieh@...>
Reviewed-by: Guo Dong <guo.dong@...>
Cc: Cheng-Chieh Huang <chengchieh@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
Cc: Trammell Hudson <hudson@...>
Cc: Maurice Ma <maurice.ma@...>
Cc: Guo Dong <guo.dong@...>
Cc: Benjamin You <benjamin.you@...>
Cc: Ray Ni <ray.ni@...>
---
UefiPayloadPkg/UefiPayloadPkg.dsc | 6 ++++++
UefiPayloadPkg/UefiPayloadPkg.fdf | 5 +++++
2 files changed, 11 insertions(+)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 54576ba485b7..e56e6f4a5379 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -438,7 +438,13 @@ [Components.X64]
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
}

+!if $(BOOTLOADER) == "LINUXBOOT"
+ OvmfPkg/8254TimerDxe/8254Timer.inf
+ OvmfPkg/8259InterruptControllerDxe/8259.inf
+!else
PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.inf
+!endif
+
MdeModulePkg/Universal/Metronome/Metronome.inf
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf b/UefiPayloadPkg/UefiPayloadPkg.fdf
index 041fed842cd8..f57a8b4bf3d3 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.fdf
+++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
@@ -101,7 +101,12 @@ [FV.DXEFV]
INF UefiCpuPkg/CpuDxe/CpuDxe.inf
INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
INF MdeModulePkg/Application/UiApp/UiApp.inf
+!if $(BOOTLOADER) != "LINUXBOOT"
INF PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.inf
+!else
+INF OvmfPkg/8254TimerDxe/8254Timer.inf
+INF OvmfPkg/8259InterruptControllerDxe/8259.inf
+!endif
INF MdeModulePkg/Universal/Metronome/Metronome.inf
INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
--
2.33.0.rc2.250.ged5fa647cd-goog


Re: [PATCH] UefiPayloadPkg: Include TCG modules in UefiPayloadPkg.

Ni, Ray
 

The TCG modules need additional changes to include the hash/measure log created from bootloader phase.
Let's not add TCG modules for now until the additional changes to support bootloader are made.

Thanks,
Ray

-----Original Message-----
From: Sravanthi, K KavyaX <k.kavyax.sravanthi@...>
Sent: Tuesday, August 24, 2021 1:34 PM
To: devel@edk2.groups.io
Cc: Sravanthi, K KavyaX <k.kavyax.sravanthi@...>; Dong, Guo <guo.dong@...>; Ni, Ray <ray.ni@...>; Ma,
Maurice <maurice.ma@...>; You, Benjamin <benjamin.you@...>
Subject: [PATCH] UefiPayloadPkg: Include TCG modules in UefiPayloadPkg.

From: Sravanthi <k.kavyax.sravanthi@...>

Include TCG modules in UefiPayloadPkg.dsc and UefiPayloadPkg.fdf

Cc: Guo Dong <guo.dong@...>
Cc: Ray Ni <ray.ni@...>
Cc: Maurice Ma <maurice.ma@...>
Cc: Benjamin You <benjamin.you@...>
Signed-off-by: Sravanthi <k.kavyax.sravanthi@...>
---
UefiPayloadPkg/UefiPayloadPkg.dsc | 24 ++++++++++++++++++++++++
UefiPayloadPkg/UefiPayloadPkg.fdf | 13 +++++++++++--
2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 7f984a0b10..ff02ac6103 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -91,6 +91,7 @@
DEFINE EMU_VARIABLE_ENABLE = TRUE
DEFINE DISABLE_RESET_SYSTEM = FALSE
DEFINE SECURE_BOOT_ENABLE = TRUE
+ DEFINE ENABLE_TCG_SUPPORT = TRUE

# Dfine the maximum size of the capsule image without a reset flag that the platform can support.
DEFINE MAX_SIZE_NON_POPULATE_CAPSULE = 0xa00000
@@ -258,6 +259,14 @@
SecureBootVariableProvisionLib|SecurityPkg/Library/SecureBootVariableProvisionLib/SecureBootVariableProvisionLib.inf
!endif
S3BootScriptLib|MdePkg/Library/BaseS3BootScriptLibNull/BaseS3BootScriptLibNull.inf
+ MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
+ Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12DeviceLibDTpm.inf
+ Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
+ Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
+ Tcg2PhysicalPresenceLib|SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
+ Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
+ HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
+ Tpm12CommandLib|SecurityPkg/Library/Tpm12CommandLib/Tpm12CommandLib.inf

[LibraryClasses.common.SEC]
HobLib|UefiPayloadPkg/Library/PayloadEntryHobLib/HobLib.inf
@@ -582,6 +591,21 @@
!endif
UefiPayloadPkg/GraphicsOutputDxe/GraphicsOutputDxe.inf

+!if $(ENABLE_TCG_SUPPORT) == TRUE
+ SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
+ SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDxe.inf
+ SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf {
+ <LibraryClasses>
+ Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
+ }
+ SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
+ SecurityPkg/Tcg/TcgDxe/TcgDxe.inf
+ SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf {
+ <LibraryClasses>
+ Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
+ }
+!endif
+
#------------------------------
# Build the shell
#------------------------------
diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf b/UefiPayloadPkg/UefiPayloadPkg.fdf
index 647df997f5..afb57612f7 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.fdf
+++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
@@ -17,8 +17,8 @@ DEFINE FD_SIZE = 0x00850000
DEFINE NUM_BLOCKS = 0x850
!else

-DEFINE FD_SIZE = 0x00440000
-DEFINE NUM_BLOCKS = 0x440
+DEFINE FD_SIZE = 0x00470000
+DEFINE NUM_BLOCKS = 0x470
!endif

################################################################################
@@ -205,6 +205,15 @@ INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
INF MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.inf
INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf

+!if $(ENABLE_TCG_SUPPORT) == TRUE
+INF SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
+INF SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDxe.inf
+INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
+INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
+INF SecurityPkg/Tcg/TcgDxe/TcgDxe.inf
+INF SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
+!endif
+
#
# Shell
#
--
2.30.2.windows.1


Re: [PATCH] UefiPayloadPkg: Add FV Guid for DXEFV and PLDFV

Ni, Ray
 

Dun will investigate this issue. There might be some issue in coreboot implementation that doesn’t handle the existence of EFI_FIRMWARE_VOLUME_EXT_HEADER.

 

From: Dong, Guo <guo.dong@...>
Sent: Wednesday, August 25, 2021 2:53 AM
To: Ni, Ray <ray.ni@...>; devel@edk2.groups.io; kingsumos@...
Cc: Liu, Zhiguang <zhiguang.liu@...>; Tan, Dun <dun.tan@...>
Subject: RE: [edk2-devel] [PATCH] UefiPayloadPkg: Add FV Guid for DXEFV and PLDFV

 

 

Hi Zhiguang,

This patch just uses an actual FV GUID to replace the dummy FV GUID (all zero FV GUID) and no FV layout change, right?

If so, this change should not impact the coreboot FV parse to find the FV entrypoint.

https://github.com/coreboot/coreboot/blob/master/util/cbfstool/cbfs-mkpayload.c

 

Thanks,

Guo

 

From: Ni, Ray <ray.ni@...>
Sent: Tuesday, August 24, 2021 4:45 AM
To: devel@edk2.groups.io; kingsumos@...; Dong, Guo <guo.dong@...>
Cc: Liu, Zhiguang <zhiguang.liu@...>; Tan, Dun <dun.tan@...>
Subject: RE: [edk2-devel] [PATCH] UefiPayloadPkg: Add FV Guid for DXEFV and PLDFV

 

It seems like the coreboot cannot support FV that contains GUID in its header.

 

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of King Sumo
Sent: Tuesday, August 24, 2021 1:02 AM
To: devel@edk2.groups.io; Dong, Guo <guo.dong@...>
Cc: Liu, Zhiguang <zhiguang.liu@...>
Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg: Add FV Guid for DXEFV and PLDFV

 

Hi All,

 

This patch broke the coreboot payload loading. Tested with:

build -a IA32 -a X64 -p UefiPayloadPkg/UefiPayloadPkg.dsc -b RELEASE -t GCC5 -D BOOTLOADER=COREBOOT


Basically the coreboot cbfstool reports the following error when creating the CBFS / flash image:

"Not a usable UEFI firmware volume"

 

Trying to boot coreboot results in an exception and the following error message:

"Payload not loaded"


Probably it broke the interface.

 

commit 4bac086e8e007c7143e33f87bb96238326d1d6ba
Author: Zhiguang Liu <zhiguang.liu@...>
Date:   Wed Jul 14 14:24:45 2021 +0800

    UefiPayloadPkg: Add FV Guid for DXEFV and PLDFV

    Signed-off-by: Zhiguang Liu <zhiguang.liu@...>
    Reviewed-by: Ray Ni <ray.ni@...>
    Reviewed-by: Guo Dong <guo.dong@...>

 

 

Kind regards,

Sumo

 

On Wed, Jul 14, 2021 at 1:08 PM Guo Dong <guo.dong@...> wrote:


Signed-off-by: Guo Dong <guo.dong@...>

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> Zhiguang Liu
> Sent: Tuesday, July 13, 2021 11:25 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH] UefiPayloadPkg: Add FV Guid for DXEFV and
> PLDFV
>
> Signed-off-by: Zhiguang Liu <zhiguang.liu@...>
> ---
>  UefiPayloadPkg/UefiPayloadPkg.fdf | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf
> b/UefiPayloadPkg/UefiPayloadPkg.fdf
> index 2d51fdbacb..041fed842c 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.fdf
> +++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
> @@ -34,6 +34,7 @@ FV = PLDFV
>
>
>
> ##########################################################
> ######################
>
>  [FV.PLDFV]
>
> +FvNameGuid         = 96E75986-6FDD-491E-9FD5-35E21AC45B45
>
>  BlockSize          = $(FD_BLOCK_SIZE)
>
>  FvAlignment        = 16
>
>  ERASE_POLARITY     = 1
>
> @@ -62,6 +63,7 @@ FILE FV_IMAGE = 4E35FD93-9C72-4c15-8C4B-
> E77F1DB2D793 {
>
> ##########################################################
> ######################
>
>
>
>  [FV.DXEFV]
>
> +FvNameGuid         = 8063C21A-8E58-4576-95CE-089E87975D23
>
>  BlockSize          = $(FD_BLOCK_SIZE)
>
>  FvForceRebase      = FALSE
>
>  FvAlignment        = 16
>
> --
> 2.30.0.windows.2
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#77762): https://edk2.groups.io/g/devel/message/77762
> Mute This Topic: https://groups.io/mt/84196221/1781375
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [guo.dong@...]
> -=-=-=-=-=-=
>




Re: [PATCH] UefiPayloadPkg: Add FV Guid for DXEFV and PLDFV

Guo Dong
 

 

Hi Zhiguang,

This patch just uses an actual FV GUID to replace the dummy FV GUID (all zero FV GUID) and no FV layout change, right?

If so, this change should not impact the coreboot FV parse to find the FV entrypoint.

https://github.com/coreboot/coreboot/blob/master/util/cbfstool/cbfs-mkpayload.c

 

Thanks,

Guo

 

From: Ni, Ray <ray.ni@...>
Sent: Tuesday, August 24, 2021 4:45 AM
To: devel@edk2.groups.io; kingsumos@...; Dong, Guo <guo.dong@...>
Cc: Liu, Zhiguang <zhiguang.liu@...>; Tan, Dun <dun.tan@...>
Subject: RE: [edk2-devel] [PATCH] UefiPayloadPkg: Add FV Guid for DXEFV and PLDFV

 

It seems like the coreboot cannot support FV that contains GUID in its header.

 

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of King Sumo
Sent: Tuesday, August 24, 2021 1:02 AM
To: devel@edk2.groups.io; Dong, Guo <guo.dong@...>
Cc: Liu, Zhiguang <zhiguang.liu@...>
Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg: Add FV Guid for DXEFV and PLDFV

 

Hi All,

 

This patch broke the coreboot payload loading. Tested with:

build -a IA32 -a X64 -p UefiPayloadPkg/UefiPayloadPkg.dsc -b RELEASE -t GCC5 -D BOOTLOADER=COREBOOT


Basically the coreboot cbfstool reports the following error when creating the CBFS / flash image:

"Not a usable UEFI firmware volume"

 

Trying to boot coreboot results in an exception and the following error message:

"Payload not loaded"


Probably it broke the interface.

 

commit 4bac086e8e007c7143e33f87bb96238326d1d6ba
Author: Zhiguang Liu <zhiguang.liu@...>
Date:   Wed Jul 14 14:24:45 2021 +0800

    UefiPayloadPkg: Add FV Guid for DXEFV and PLDFV

    Signed-off-by: Zhiguang Liu <zhiguang.liu@...>
    Reviewed-by: Ray Ni <ray.ni@...>
    Reviewed-by: Guo Dong <guo.dong@...>

 

 

Kind regards,

Sumo

 

On Wed, Jul 14, 2021 at 1:08 PM Guo Dong <guo.dong@...> wrote:


Signed-off-by: Guo Dong <guo.dong@...>

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> Zhiguang Liu
> Sent: Tuesday, July 13, 2021 11:25 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH] UefiPayloadPkg: Add FV Guid for DXEFV and
> PLDFV
>
> Signed-off-by: Zhiguang Liu <zhiguang.liu@...>
> ---
>  UefiPayloadPkg/UefiPayloadPkg.fdf | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf
> b/UefiPayloadPkg/UefiPayloadPkg.fdf
> index 2d51fdbacb..041fed842c 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.fdf
> +++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
> @@ -34,6 +34,7 @@ FV = PLDFV
>
>
>
> ##########################################################
> ######################
>
>  [FV.PLDFV]
>
> +FvNameGuid         = 96E75986-6FDD-491E-9FD5-35E21AC45B45
>
>  BlockSize          = $(FD_BLOCK_SIZE)
>
>  FvAlignment        = 16
>
>  ERASE_POLARITY     = 1
>
> @@ -62,6 +63,7 @@ FILE FV_IMAGE = 4E35FD93-9C72-4c15-8C4B-
> E77F1DB2D793 {
>
> ##########################################################
> ######################
>
>
>
>  [FV.DXEFV]
>
> +FvNameGuid         = 8063C21A-8E58-4576-95CE-089E87975D23
>
>  BlockSize          = $(FD_BLOCK_SIZE)
>
>  FvForceRebase      = FALSE
>
>  FvAlignment        = 16
>
> --
> 2.30.0.windows.2
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#77762): https://edk2.groups.io/g/devel/message/77762
> Mute This Topic: https://groups.io/mt/84196221/1781375
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [guo.dong@...]
> -=-=-=-=-=-=
>





Re: [PATCH v3 0/4] Fix OvmfXen boot failure due to s3 support state

Jim Fehlig <jfehlig@...>
 

On 8/23/21 1:09 AM, Gary Lin wrote:
When using HVM Direct kernel boot with OvmfXen, it could fail at the
S3BootScript due to the inconsistency between QemuFwCfgS3Enabled()
and PcdAcpiS3Enable.
This patch series initializes PcdAcpiS3Enable in
. Besides, QemuFwCfgS3Enabled() is
replaced with PcdAcpiS3Enable in several OVMF libraries to avoid the
potential inconsistency.
Bugzilla links:
https://bugzilla.tianocore.org/show_bug.cgi?id=3573
v3:
- Update the description per Anthony's suggestion
- Add the bugzilla links
- Move the QemuKernelLoaderFsDxe patch out of this patch series
and make it an independent patch
v2:
- Amend the description and address "HVM Direct Kernel Boot"
- Add the comment for the conditional test of QemuFwCfgS3Enabled()
- Remove unused QemuFwCfgLib
- Update my email address
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jordan Justen <jordan.l.justen@...>
Cc: Anthony Perard <anthony.perard@...>
Cc: Julien Grall <julien@...>
Cc: Jim Fehlig <jfehlig@...>
Cc: Joey Li <jlee@...>
Gary Lin (4):
OvmfPkg/OvmfXen: set PcdAcpiS3Enable at initialization
OvmfPkg/LockBoxLib: use PcdAcpiS3Enable to detect S3 support
OvmfPkg/PlatformBootManagerLib: use PcdAcpiS3Enable to detect S3
support
OvmfPkg/SmmControl2Dxe: use PcdAcpiS3Enable to detect S3 support
OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf | 3 +--
.../PlatformBootManagerLib.inf | 1 +
OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf | 2 ++
OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 2 ++
OvmfPkg/Library/LockBoxLib/LockBoxDxe.c | 4 +---
.../Library/PlatformBootManagerLib/BdsPlatform.c | 2 +-
OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c | 4 +---
OvmfPkg/XenPlatformPei/Platform.c | 13 +++++++++++++
8 files changed, 22 insertions(+), 9 deletions(-)
Tested-by: Jim Fehlig <jfehlig@...>

Regards,
Jim


Re: [PATCH v3] OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe

Jim Fehlig <jfehlig@...>
 

On 8/23/21 1:08 AM, Gary Lin wrote:
https://bugzilla.tianocore.org/show_bug.cgi?id=3574
Without QemuKernelLoaderFsDxe, QemuLoadKernelImage() couldn't download
the kernel, initrd, and kernel command line from QEMU's fw_cfg.
v3:
Add the bugzilla link
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Jiewen Yao <jiewen.yao@...>
cc: Jordan Justen <jordan.l.justen@...>
Cc: Anthony Perard <anthony.perard@...>
Cc: Julien Grall <julien@...>
Cc: Jim Fehlig <jfehlig@...>
Cc: Joey Li <jlee@...>
Signed-off-by: Gary Lin <gary.lin@...>
Acked-by: Anthony PERARD <anthony.perard@...>
---
OvmfPkg/OvmfXen.dsc | 1 +
OvmfPkg/OvmfXen.fdf | 1 +
2 files changed, 2 insertions(+)
FWIW

Tested-by: Jim Fehlig <jfehlig@...>

Regards,
Jim

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 3c1ca6bfd493..1a9c06c164a8 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -587,6 +587,7 @@ [Components]
NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
!endif
}
+ OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index aeb9336fd5b7..8b5823555937 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -324,6 +324,7 @@ [FV.DXEFV]
INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
INF MdeModulePkg/Application/UiApp/UiApp.inf
+INF OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
INF MdeModulePkg/Universal/PrintDxe/PrintDxe.inf
INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf


Re: [PATCH] UefiPayloadPkg: Add FV Guid for DXEFV and PLDFV

King Sumo
 

I have filed a bug report:
https://bugzilla.tianocore.org/show_bug.cgi?id=3585


Re: UefiPayloadPkg build error

King Sumo
 


Re: Question Using edk2-UDK2018 and VS2017

Michael D Kinney
 

Seojin Kim,

Last week I made commits to the edk2-libc repo that resolved these issues so the edk2-libc repo can build with the latest edk2/master and support the VS2017 and VS2019 compilers.

Can you please try that latest code from edk2/master and edk2-libc/master and verify that all your issues are resolved?

Thanks,

Mike

 

 

From: Carsey, Jaben <jaben.carsey@...>
Sent: Tuesday, August 24, 2021 9:21 AM
To:
김서진 <canonicus@...>; edk2-lists@...; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>; Rebecca Cran <rebecca@...>
Subject: RE: Question Using edk2-UDK2018 and VS2017

 

Adding the new maintainers.

 

From: 김서진 <canonicus@...>
Sent: Sunday, August 22, 2021 10:52 PM
To: edk2-lists@...; Carsey, Jaben <jaben.carsey@...>
Cc: canonicus@...
Subject: Question Using edk2-UDK2018 and VS2017

 

Dear Daryl McDaniel and Jaben Carsey,

This is Seojin Kim from South Korea.

Currently, I am building a program using edk2-UDK2018 and Visual Studio 2017.

But it is impossible to use the program as it is without modifying it because of a few errors, so some parts were modified.

Below is a description of the parts I have modified.

1. Error : c:\edk2\StdLib\Include\sys/EfiCdefs.h(342): warning C4117

> I deleted the declaration of "__STDC_HOSTED__".

 

2. Error : warning C4459, warning C4456

> Warnings occurred because the local variables and the global variables had the same name, so I changed names of local variables.

(c:\edk2\StdLib\EfiSocketLib\Socket.c(2980): warning C4459: 'errno'

c:\edk2\StdLib\BsdSocketLib\getnetbyht.c(158): warning C4459: 'net'

c:\edk2\StdLib\BsdSocketLib\ns_print.c(214): warning C4456: 't')

 

3.  Error : unresolved external symbol "__fpclassifyd"

> I added "fpclassify.c" file to define __fpclassifyd referring to https://blog.csdn.net/humanof/article/details/118708586 (thanks to google translation).

> Also I modified LibC.inf file to add Main/fpclassify.c in [Source].

 

(Above description may contain some typos.. I apologize in advance.)

 

After these modifications, I succeeded to build my package.

However, I believe that your code is impeccable, so there must be something that I did wrong.

I would be very grateful if you could suggest a way to solve thr above problems.

 

Thank you,

 

Seojin Kim

 

 

 

 

 


Re: Question Using edk2-UDK2018 and VS2017

Carsey, Jaben
 

Adding the new maintainers.

 

From: 김서진 <canonicus@...>
Sent: Sunday, August 22, 2021 10:52 PM
To: edk2-lists@...; Carsey, Jaben <jaben.carsey@...>
Cc: canonicus@...
Subject: Question Using edk2-UDK2018 and VS2017

 

Dear Daryl McDaniel and Jaben Carsey,

This is Seojin Kim from South Korea.

Currently, I am building a program using edk2-UDK2018 and Visual Studio 2017.

But it is impossible to use the program as it is without modifying it because of a few errors, so some parts were modified.

Below is a description of the parts I have modified.

1. Error : c:\edk2\StdLib\Include\sys/EfiCdefs.h(342): warning C4117

> I deleted the declaration of "__STDC_HOSTED__".

 

2. Error : warning C4459, warning C4456

> Warnings occurred because the local variables and the global variables had the same name, so I changed names of local variables.

(c:\edk2\StdLib\EfiSocketLib\Socket.c(2980): warning C4459: 'errno'

c:\edk2\StdLib\BsdSocketLib\getnetbyht.c(158): warning C4459: 'net'

c:\edk2\StdLib\BsdSocketLib\ns_print.c(214): warning C4456: 't')

 

3.  Error : unresolved external symbol "__fpclassifyd"

> I added "fpclassify.c" file to define __fpclassifyd referring to https://blog.csdn.net/humanof/article/details/118708586 (thanks to google translation).

> Also I modified LibC.inf file to add Main/fpclassify.c in [Source].

 

(Above description may contain some typos.. I apologize in advance.)

 

After these modifications, I succeeded to build my package.

However, I believe that your code is impeccable, so there must be something that I did wrong.

I would be very grateful if you could suggest a way to solve thr above problems.

 

Thank you,

 

Seojin Kim

 

 

 

 

 


[PATCH] ShellPkg: Parse I/O APIC and x2APIC structure

Abdul Lateef Attar <AbdulLateef.Attar@...>
 

Parse and print the below interrupt structures
- I/O APIC Structure
- Interrupt Source Override Structure
- Processor Local x2APIC Structure
- Local x2APIC NMI Structure

Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@...>
---
.../Parsers/Madt/MadtParser.c | 99 +++++++++++++++++++
1 file changed, 99 insertions(+)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c
index 15aa2392b6..2ba8c9ae52 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c
@@ -181,6 +181,57 @@ STATIC CONST ACPI_PARSER GicITSParser[] = {
{L"Reserved", 4, 16, L"0x%x", NULL, NULL, NULL, NULL}
};

+/**
+ An ACPI_PARSER array describing the IO APIC Structure.
+**/
+STATIC CONST ACPI_PARSER IoApic[] = {
+ {L"Type", 1, 0, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Length", 1, 1, L"%d", NULL, NULL, NULL, NULL},
+ {L"I/O APIC ID", 1, 2, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Reserved", 1, 3, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"I/O APIC Address", 4, 4, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Global System Interrupt Base", 4, 8, L"0x%x", NULL, NULL, NULL, NULL}
+};
+
+/**
+ An ACPI_PARSER array describing the Interrupt Source Override Structure.
+**/
+STATIC CONST ACPI_PARSER InterruptSourceOverride[] = {
+ {L"Type", 1, 0, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Length", 1, 1, L"%d", NULL, NULL, NULL, NULL},
+ {L"Bus", 1, 2, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Source", 1, 3, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Global System Interrupt", 4, 4, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Flags", 2, 8, L"0x%x", NULL, NULL, NULL, NULL}
+};
+
+
+/**
+ An ACPI_PARSER array describing the Processor Local x2APIC Structure.
+**/
+STATIC CONST ACPI_PARSER ProcessorLocalX2Apic[] = {
+ {L"Type", 1, 0, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Length", 1, 1, L"%d", NULL, NULL, NULL, NULL},
+ {L"Reserved", 2, 2, L"0x%x", NULL, NULL, NULL, NULL},
+
+ {L"X2APIC ID", 4, 4, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Flags", 4, 8, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"ACPI Processor UID", 4, 12, L"0x%x", NULL, NULL, NULL, NULL}
+};
+
+/**
+ An ACPI_PARSER array describing the Local x2APIC NMI Structure.
+**/
+STATIC CONST ACPI_PARSER LocalX2ApicNmi[] = {
+ {L"Type", 1, 0, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Length", 1, 1, L"%d", NULL, NULL, NULL, NULL},
+ {L"Flags", 2, 2, L"0x%x", NULL, NULL, NULL, NULL},
+
+ {L"ACPI Processor UID", 4, 4, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Local x2APIC LINT#", 1, 8, L"0x%x", NULL, NULL, NULL, NULL},
+ {L"Reserved", 3, 9, L"0x%x%x%x", Dump3Chars, NULL, NULL, NULL}
+};
+
/**
An ACPI_PARSER array describing the ACPI MADT Table.
**/
@@ -357,6 +408,54 @@ ParseAcpiMadt (
break;
}

+ case EFI_ACPI_6_3_IO_APIC: {
+ ParseAcpi (
+ TRUE,
+ 2,
+ "IO APIC",
+ InterruptContollerPtr,
+ *MadtInterruptControllerLength,
+ PARSER_PARAMS (IoApic)
+ );
+ break;
+ }
+
+ case EFI_ACPI_6_3_INTERRUPT_SOURCE_OVERRIDE: {
+ ParseAcpi (
+ TRUE,
+ 2,
+ "INTERRUPT SOURCE OVERRIDE",
+ InterruptContollerPtr,
+ *MadtInterruptControllerLength,
+ PARSER_PARAMS (InterruptSourceOverride)
+ );
+ break;
+ }
+
+ case EFI_ACPI_6_3_PROCESSOR_LOCAL_X2APIC: {
+ ParseAcpi (
+ TRUE,
+ 2,
+ "PROCESSOR LOCAL X2APIC",
+ InterruptContollerPtr,
+ *MadtInterruptControllerLength,
+ PARSER_PARAMS (ProcessorLocalX2Apic)
+ );
+ break;
+ }
+
+ case EFI_ACPI_6_3_LOCAL_X2APIC_NMI: {
+ ParseAcpi (
+ TRUE,
+ 2,
+ "LOCAL x2APIC NMI",
+ InterruptContollerPtr,
+ *MadtInterruptControllerLength,
+ PARSER_PARAMS (LocalX2ApicNmi)
+ );
+ break;
+ }
+
default: {
IncrementErrorCount ();
Print (
--
2.25.1

14861 - 14880 of 94575