Reviewed-by: Yuwei Chen
> -Original Message-
> From: Feng, Bob C
> Sent: Tuesday, May 25, 2021 2:20 PM
> To: devel@edk2.groups.io
> Cc: Liming Gao ; Chen, Christine
>
> Subject: [Patch] [edk2-staging] BaseTools: Add checkpoint for that there is
> no fv ext_header
>
> FMMT will crash if
Hi Laszlo,
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, May 19, 2021 2:26 PM
> To: devel@edk2.groups.io; Jianyong Wu ;
> ardb+tianoc...@kernel.org; Sami Mujawar
> Cc: hao.a...@intel.com; Justin He
> Subject: Re: [edk2-devel] [PATCH v2 3/5] ArmVirtPkg: enable ACPI for
Hi Sami,
Thanks for lots of great comments here, I will fix it one by one.
Thanks
Jianyong
From: Sami Mujawar
Sent: Wednesday, May 19, 2021 4:26 AM
To: Jianyong Wu ; devel@edk2.groups.io; ler...@redhat.com;
ardb+tianoc...@kernel.org
Cc: hao.a...@intel.com; Justin He ; nd
Subject: Re: [PATCH
Add queued invalidation interface support for VTd core driver.
For software to invalidate the various caching structures, the architecture
supports the following two types of invalidation interfaces.
1. Register-based invalidation interface
2. Queued invalidation interface.
BIOS shall check
Hi Laszlo,
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, May 19, 2021 2:17 PM
> To: devel@edk2.groups.io; Jianyong Wu ;
> ardb+tianoc...@kernel.org; Sami Mujawar
> Cc: hao.a...@intel.com; Justin He ; Jian J Wang
>
> Subject: Re: [edk2-devel] [PATCH v2 2/5] MdeMoudlePkg:
If no objection, I will merge this patch today. Then, tomorrow, I will create
stable tag 202105.
Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io 代表 gaoliming
> 发送时间: 2021年5月26日 10:22
> 收件人: devel@edk2.groups.io; ler...@redhat.com;
> sami.muja...@arm.com
> 抄送: a...@kernel.org;
Hi Sami,
> -Original Message-
> From: Sami Mujawar
> Sent: Wednesday, May 19, 2021 4:26 AM
> To: Jianyong Wu ; devel@edk2.groups.io;
> ler...@redhat.com; ardb+tianoc...@kernel.org
> Cc: hao.a...@intel.com; Justin He ; Jian J Wang
> ; nd
> Subject: Re: [PATCH v2 2/5] MdeMoudlePkg:
Hi Sami,
> -Original Message-
> From: Sami Mujawar
> Sent: Wednesday, May 19, 2021 4:21 AM
> To: Jianyong Wu ; devel@edk2.groups.io;
> ler...@redhat.com; ardb+tianoc...@kernel.org
> Cc: hao.a...@intel.com; Justin He ; Leif Lindholm
> ; nd
> Subject: Re: [PATCH v2 1/5] ArmVirtPkg:
Some inline comments below:
> -Original Message-
> From: Liu, Zhiguang
> Sent: Monday, May 24, 2021 3:13 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A ;
> Bi, Dandan ; Liming Gao
> ; Ni, Ray
> Subject: [PATCH 8/9] MdeModulePkg/ACPI: Install ACPI table from HOB.
>
> If
Hi Michael,
I have been thinking about this more from a long-term maintainability
standpoint. The IFWI region enum FLASH_REGION_TYPE looks pretty ripe for
causing issues years from now. We should probably convert each member of that
enum into a EFI_GUID so that regions can be added/removed as
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Now that OvmfPkg supports version 2 of the GHCB specification, bump the
protocol version.
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
Cc: Ard Biesheuvel
Cc: Laszlo Ersek
Cc: Erdem Aktas
The SetMemoryEncDec() is used by the higher level routines to set or clear
the page encryption mask for system RAM and Mmio address. When SEV-SNP is
active, in addition to set/clear page mask it also updates the RMP table.
The RMP table updates are required for the system RAM address and not
the
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Now that both the secrets and cpuid pages are reserved in the HOB,
extract the location details through fixed PCD and make it available
to the guest OS through the configuration table.
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The MemEncryptSev{Set,Clear}PageEncMask() functions are used to set or
clear the memory encryption attribute in the page table. When SEV-SNP
is active, we also need to change the page state in the RMP table so that
it is in sync with the
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
When SEV-SNP is active, a memory region mapped encrypted in the page
table must be validated before access. There are two approaches that
can be taken to validate the system RAM detected during the PEI phase:
1) Validate on-demand
OR
2)
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The VMM launch sequence should have pre-validated all the data pages used
in the Reset vector. The range does not cover the data pages used during
the SEC phase (mainly PEI and DXE firmware volume decompression memory).
When SEV-SNP is
From: Tom Lendacky
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Use the SEV-SNP AP Creation NAE event to create and launch APs under
SEV-SNP. This capability will be advertised in the SEV Hypervisor
Feature Support PCD (PcdSevEsHypervisorFeatures).
Cc: Eric Dong
Cc: Ray Ni
Cc:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The initial page built during the SEC phase is used by the
MemEncryptSevSnpValidateSystemRam() for the system RAM validation. The
page validation process requires using the PVALIDATE instruction; the
instruction accepts a virtual address of
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The MemEncryptSevSnpPreValidateSystemRam() is used for pre-validating the
system RAM. As the boot progress, each phase validates a fixed region of
the RAM. In the PEI phase, the PlatformPei detects all the available RAM
and calls to
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Commit 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803 added support to ensure
that MMIO is only performed against the un-encrypted memory. If MMIO
is performed against encrypted memory, a #GP is raised.
The AmdSevDxe uses the functions provided
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
An SEV-SNP guest us required to perform GHCB GPA registration before
using a GHCB. See the GHCB spec section 2.5.2 for more details.
Add a library that can be called to perform the GHCB GPA registration.
Cc: James Bottomley
Cc: Min Xu
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
When SEV-SNP is active, the GHCB page is mapped un-encrypted in the
initial page table built by the reset vector code. Just clearing the
encryption attribute from the page table is not enough. The page also
needs to be added as shared in the
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Many of the integrity guarantees of SEV-SNP are enforced through the
Reverse Map Table (RMP). Each RMP entry contains the GPA at which a
particular page of DRAM should be mapped. The guest can request the
hypervisor to add pages in the RMP
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
During the SEV-SNP guest launch sequence, two special pages need to be
inserted, the secrets and CPUID. The secrets page, contain the VM
platform communication keys. The guest BIOS and/or OS can use this key
to communicate with the SEV
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The GHCB Version 2 introduces advertisement of features that are supported
by the hypervisor. The features value is saved in the SevEs workarea. Save
the value in the PCD for the later use.
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
An SEV-SNP guest requires that the physical address of the GHCB must
be registered with the hypervisor before using it. See the GHCB
specification for the futher detail.
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Extend the workarea to include the SEV-SNP enabled fields. This will be set
when SEV-SNP is active in the guest VM.
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
Cc: Ard Biesheuvel
Cc: Laszlo Ersek
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
The SEV-SNP guest requires that GHCB GPA must be registered before using.
The GHCB GPA can be registred using the GhcbGPARegister().
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
Cc: Ard Biesheuvel
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Create a function that can be used to determine if VM is running as an
SEV-SNP guest.
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
Cc: Ard Biesheuvel
Cc: Laszlo Ersek
Cc: Erdem Aktas
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
An SEV-SNP guest requires that private memory (aka pages mapped encrypted)
must be validated before being accessed.
The validation process consist of the following sequence:
1) Set the memory encryption attribute in the page table (aka
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
When AMD SEV is enabled in the guest VM, a hypervisor need to insert a
secrets page.
When SEV-SNP is enabled, the secrets page contains the VM platform
communication keys. The guest BIOS and OS can use this key to communicate
with the SEV
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
Define the PCDs used by the MpLib while creating the AP when SEV-SNP is
active in the guest VMs.
Cc: James Bottomley
Cc: Min Xu
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Jordan Justen
Cc: Ard Biesheuvel
Cc: Laszlo Ersek
Cc: Erdem Aktas
(I missed adding devel@edk2.groups.io, resending the series)
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
SEV-SNP builds upon existing SEV and SEV-ES functionality while adding
new hardware-based memory protections. SEV-SNP adds strong memory integrity
protection to help prevent
On 5/26/21 2:14 PM, Laszlo Ersek wrote:
Switch the Bhyve platform from the "OvmfPkg/PciHostBridgeLib" instance to
the "OvmfPkg/PciHostBridgeLibScan" instance. Currently this is a no-op
functionally; we'll customize the "PciHostBridgeLibScan" instance later.
Cc: Ard Biesheuvel
Cc: Jordan Justen
The "OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf"
library instance is used in the following platform DSC files in edk2:
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
OvmfPkg/OvmfXen.dsc
The Xen customizations are very light-weight in this
Remove the SmbiosTablePublishEntry() function from "SmbiosPlatformDxe.c".
"SmbiosPlatformDxe.c" becomes hypervisor-agnostic.
Add SmbiosTablePublishEntry() back, simplified for QEMU, to the existent
file "Qemu.c". The GetQemuSmbiosTables() function no longer needs to be
declared in
"OvmfPkg/SmbiosPlatformDxe" is structured somewhat differently from the
drivers duplicated and trimmed thus far in this series. The final QEMU and
Xen versions will share a relatively significant amount of code, therefore
duplicating the whole driver is less useful, even temporarily. Instead,
Add an extern declaration for the InstallAllStructures() function to the
"SmbiosPlatformDxe.h" header file. (The leading comment block and the
prototype are simply copied from "SmbiosPlatformDxe.c".)
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Philippe Mathieu-Daudé
Ref:
Move the declaration of the GetXenSmbiosTables() function to a new header
file called "XenSmbiosPlatformDxe.h". (The only declaration that remains
in "SmbiosPlatformDxe.h" for now is that of GetQemuSmbiosTables().)
Modify the pattern in "Maintainers.txt" so that the new file be covered in
the
Locate the SMBIOS protocol internally to the InstallAllStructures()
function. This has no performance impact (InstallAllStructures() is only
called once), but moving the code from the entry point function makes the
latter smaller. And that will be useful when we split the entry point
function to
According to the function-top comment, SmbiosTablePublishEntry() is
supposed to return an error code if no SMBIOS data is found, from either
GetXenSmbiosTables() or GetQemuSmbiosTables(). Currently the function
returns EFI_SUCCESS in this case however (propagated from
gBS->LocateProtocol()). Make
- Sort all sections in the INF file.
- Remove unused packages (MdeModulePkg) and lib classes (BaseMemoryLib)
from the INF file.
- Restrict some lib classes (BaseLib, HobLib) and GUIDs (gEfiXenInfoGuid)
to IA32 and X64, in the INF file; only the IA32/X64 Xen implementation
requires these.
Rename "XenSupport.c" to "ScanForRootBridges.c", after the main function
in it.
Update the file-top comments; refer to both Bhyve and Xen.
Cc: Anthony Perard
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Julien Grall
Cc: Peter Grehan
Cc: Philippe Mathieu-Daudé
Cc: Rebecca Cran
Ref:
The "OvmfPkg/Library/PciHostBridgeLibScan/PciHostBridgeLibScan.inf"
instance is used in the following platforms in edk2:
OvmfPkg/Bhyve/BhyveX64.dsc
OvmfPkg/OvmfXen.dsc
Neither Bhyve nor Xen provide a Q35 board, therefore the expression
PcdGet16 (PcdOvmfHostBridgePciDevId) !=
The "OvmfPkg/Library/PciHostBridgeLibScan/PciHostBridgeLibScan.inf"
instance is used in the following platforms in edk2:
OvmfPkg/Bhyve/BhyveX64.dsc
OvmfPkg/OvmfXen.dsc
Both platforms define "PcdPciDisableBusEnumeration" with Fixed-at-Build
access method, and TRUE value. Remove the PCD from
The "OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf" instance is
used by the following platforms in edk2:
OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
All these platforms statically inherit PcdPciDisableBusEnumeration=FALSE
Switch the OvmfXen platform from the "OvmfPkg/PciHostBridgeLib" instance
to the "OvmfPkg/PciHostBridgeLibScan" instance. Currently this is a no-op
functionally; we'll customize the "PciHostBridgeLibScan" instance later.
Cc: Anthony Perard
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Julien Grall
Switch the Bhyve platform from the "OvmfPkg/PciHostBridgeLib" instance to
the "OvmfPkg/PciHostBridgeLibScan" instance. Currently this is a no-op
functionally; we'll customize the "PciHostBridgeLibScan" instance later.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Peter Grehan
Cc: Philippe
Create an almost verbatim copy of the
"OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf" library instance.
The new PciHostBridgeLibScan instance will ultimately duplicate a
negligible amount of code from the original, and will be used by the Bhyve
and OvmfXen platforms.
List the new driver
- In every C file, list every necessary public #include individually, with
an example identifier that's actually consumed.
- Place all public #includes first, all module-private #includes second.
Separate them with a single empty line. Keep each section sorted in
itself.
- Sort all
At this point, the IncompatiblePciDeviceSupportDxe driver is included in
the following platforms in edk2:
OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
All those platforms inherit FALSE for "PcdPciDisableBusEnumeration" from
The entry point function of "OvmfPkg/IncompatiblePciDeviceSupportDxe",
namely DriverInitialize()
[OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c],
bails out immediately if "PcdPciDisableBusEnumeration" is TRUE.
The Bhyve platform statically assigns this PCD TRUE. Thus,
On 5/26/21 2:14 PM, Laszlo Ersek wrote:
The Bhyve platform specifies the dynamic access method for
"PcdPciDisableBusEnumeration" needlessly.
After the DSC file sets the PCD to TRUE by default, the PCD is never
written again. In particular, the
"OvmfPkg/Bhyve/PlatformPei/PlatformPei.inf" file
The entry point function of "OvmfPkg/IncompatiblePciDeviceSupportDxe",
namely DriverInitialize()
[OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c],
bails out immediately if "PcdPciDisableBusEnumeration" is TRUE.
The OvmfXen platform statically assigns this PCD TRUE. Thus,
On 5/26/21 2:14 PM, Laszlo Ersek wrote:
The built-in ACPI tables for Bhyve are located in the
"OvmfPkg/Bhyve/AcpiTables" module, not in the "OvmfPkg/AcpiTables" module.
Correct the typo in a code comment.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Peter Grehan
Cc: Philippe Mathieu-Daudé
Cc:
The Bhyve platform specifies the dynamic access method for
"PcdPciDisableBusEnumeration" needlessly.
After the DSC file sets the PCD to TRUE by default, the PCD is never
written again. In particular, the
"OvmfPkg/Bhyve/PlatformPei/PlatformPei.inf" file references the PCD
superfluously.
Make the
With the Xen-dependent PcdSetBoolS() call removed from
OvmfPkg/PlatformPei, the "AmdSevX64.dsc" platform never writes
"PcdPciDisableBusEnumeration". This means we don't need a dynamic default
for the PCD in the DSC file; it could be declared Fixed-at-Build.
However, because the PCD's default
With the Xen-dependent PcdSetBoolS() call removed from
OvmfPkg/PlatformPei, the "OvmfPkgIa32.dsc", "OvmfPkgIa32X64.dsc",
"OvmfPkgX64.dsc" platforms never write "PcdPciDisableBusEnumeration". This
means we don't need a dynamic default for the PCD in the DSC files; it
could be declared
The "OvmfPkg/PlatformPei/PlatformPei.inf" module is used by the following
platform DSCs:
OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
Remove Xen support from "OvmfPkg/PlatformPei", including any dependencies
that now become
Because "PcdPciDisableBusEnumeration" is always TRUE in the OvmfXen
platform, we can remove the delayed ACPI table installation from
XenAcpiPlatformDxe. A number of dependencies become useless this way;
remove them too.
(Note that, conversely, in the QemuFwCfgAcpiPlatformDxe driver, we
*cannot*
The OvmfXen platform specifies the dynamic access method for
"PcdPciDisableBusEnumeration" needlessly.
After the DSC file sets the PCD to TRUE by default, the InitializeXen()
function in XenPlatformPei superfluously sets the PCD to TRUE again. There
are no other writes to the PCD in the platform.
The "OvmfPkg/AcpiTables/AcpiTables.inf" module is no longer used by any
module in edk2; remove it.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Philippe Mathieu-Daudé
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek
---
OvmfPkg/AcpiTables/AcpiTables.inf | 38
The built-in ACPI tables for Bhyve are located in the
"OvmfPkg/Bhyve/AcpiTables" module, not in the "OvmfPkg/AcpiTables" module.
Correct the typo in a code comment.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Peter Grehan
Cc: Philippe Mathieu-Daudé
Cc: Rebecca Cran
Ref:
Xen is an advanced hypervisor; no Xen guest can function correctly without
the hypervisor's dynamically provided ACPI tables. Remove the built-in
(fallback) tables from XenAcpiPlatformDxe -- and the OvmfXen platform.
Remove any dependencies from XenAcpiPlatformDxe that are no longer needed.
Cc:
The InstallAcpiTable() helper function buys us nothing. Reduce code
complexity by removing the function.
This patch is best viewed with "git show -b".
Cc: Anthony Perard
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Julien Grall
Cc: Philippe Mathieu-Daudé
Ref:
The QemuDetected() function wraps QemuFwCfgIsAvailable(); it always fails
on Xen. Because of that, we can eliminate the QemuDetected() call itself
from the Xen ACPI platform driver, and then the rest of "Qemu.c" becomes
useless -- the workhorse function of that source file is
The root of the QEMU ACPI linker/loader client in XenAcpiPlatformDxe is
the InstallQemuFwCfgTables() function. This function always fails on Xen,
due to its top-most QemuFwCfgFindFile() call.
Remove the InstallQemuFwCfgTables() function call from XenAcpiPlatformDxe,
along with all dependencies
The "OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf" module is no longer
referenced in any platform DSC file; remove it.
That orphans the "AcpiPlatform.c", "Qemu.c" and "Xen.c" files in the
"OvmfPkg/AcpiPlatformDxe/" directory; remove them.
That in turn removes the only definitions of the
Create an almost verbatim copy of the
"OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf" driver for the OvmfXen
platform. We're going to trim the driver in subsequent patches.
Ultimately, the XenAcpiPlatformDxe driver will duplicate a negligible
amount of code that is currently present in the
- #include only such public headers in "AcpiPlatform.h" that are required
by the function declarations and type definitions introduced in
"AcpiPlatform.h". Don't use "AcpiPlatform.h" as a convenience #include
file.
- In every file, list every necessary public #include individually, with
Turn the "QemuLoader.h" header into a public (IndustryStandard) one. The
QEMU ACPI linker-loader interface is stable between QEMU and multiple
guest firmwares.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Philippe Mathieu-Daudé
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
"QemuLoader.h" needs the QEMU_FW_CFG_FNAME_SIZE macro. This macro used to
live in the QemuFwCfgLib class header, but we moved it to the more
foundational IndustryStandard include file called "QemuFwCfg.h" in commit
5583a8a4ffd0 ("OvmfPkg/QemuFwCfgLib: move types/macros from lib class to
Place all public #includes first, all module-private #includes second.
Separate them with a single empty line. Keep each section sorted in
itself.
Sort all sections in both INF files.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Philippe Mathieu-Daudé
Ref:
- Remove the leading underscores from the #include guard macro names;
clean up the names in general.
- Remove the useless "Include/" directory prefix from the public header
pathnames.
- Fix incorrect file-top comment.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Philippe Mathieu-Daudé
Ref:
Due to switching to the QemuFwCfgAcpiPlatformDxe driver earlier in this
series, require QEMU version 1.7.1 in the "OvmfPkg/README" file, and
require 1.7 or later machine types too.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Philippe Mathieu-Daudé
Ref:
For consistency with the historical OvmfPkg* platforms, switch the
remotely attested, QEMU/KVM-only, AmdSev platform from the AcpiPlatformDxe
driver to the QemuFwCfgAcpiPlatformDxe driver.
No module remains dependent on XenPlatformLib, so remove the
XenPlatformLib class resolution too, from the
Switch the historical OvmfPkg* platforms from the AcpiPlatformDxe driver
to the QemuFwCfgAcpiPlatformDxe driver. (The latter is used by the
ArmVirtQemu* platforms as well.)
The change effectively replaces the following call tree:
InstallAcpiTables[AcpiPlatform.c]
For symmetry with the historical OvmfPkg* platforms, remove the three Xen
drivers from the remotely attested, QEMU/KVM-only, AmdSev platform. Xen
(HVM and PVH) guests are supported by the dedicated OvmfXen platform.
No module remains dependent on XenHypercallLib, so remove the
XenHypercallLib
Remove the three Xen drivers as the first step for removing Xen support
from the historical OvmfPkg* platforms. Xen (HVM and PVH) guests are
supported by the dedicated OvmfXen platform.
No module remains dependent on XenHypercallLib, so remove the
XenHypercallLib class resolutions too, from the
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Repo: https://pagure.io/lersek/edk2.git
Branch: xen_split_bz_2122
This patch set removes dynamic Xen enlightenment from the following
platforms:
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
In
Hi Sayanta,
Thanks for confirming.
With that.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
From: Sayanta Pattanayak
Date: Wednesday, 26 May 2021 at 19:15
To: Sami Mujawar , devel@edk2.groups.io
Cc: Ard Biesheuvel , nd
Subject: RE: [edk2-platforms][PATCH V1 3/3] Platform/Sgi: enable
Hi Sami,
Thanks for the review and suggestion. Please find my reply inline.
>
> Hi Sayanta,
>
> Thank you for this patch.
>
> Please find my response inline marked [SAMI].
>
> Regards,
>
> Sami Mujawar
>
> On 24/05/2021 06:23 PM, Sayanta Pattanayak wrote:
> > Enable the use of UEFI secure
Currently, the largest volume size for building OVMF images is 4MB. With
the growth of the Linuxboot project, maintainers have had to maintain a
fork containing this patch which allows larger image sizes in order for
Linuxboot developers/users to have enough space to experiment with
and test
Hi,
Are there any known bugs with [edk2-stable202002] when using the
FtdiUsbSerialDxe driver? I am seeing errors during initialization when
TerminalDriverBindingStart() tries to reset the FTDI device and gets
EFI_DEVICE_ERROR.
Thanks,
Jack
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You
Hi Ray,
Can we work through these phases in the edk2-staging repo and avoid making temp
changes to the edk2 repo?
Thanks,
Mike
> -Original Message-
> From: Ni, Ray
> Sent: Tuesday, May 25, 2021 7:03 PM
> To: Kinney, Michael D ; devel@edk2.groups.io;
> Liu, Zhiguang
> Cc: Liming Gao
On Mon, May 24, 2021 at 9:13 AM Zhiguang Liu wrote:
> From SysTableInfo Hob, get ACPI table address, and creat gPldAcpiTableGuid
> Hob
> to store it. Remove diretly adding ACPI table to ConfigurationTable.
> Dxe ACPI driver will parse it and install ACPI table from Guid Hob.
>
> Cc: Maurice Ma
On Mon, May 24, 2021 at 9:13 AM Zhiguang Liu wrote:
> V1:
> The default EfiSmbiosProtocol operates on an empty SMBIOS table.
> The SMBIOS tables are provided by the bootloader on UefiPayloadPkg.
> Scan for existing tables in SmbiosDxe and load them if they seem valid.
>
> This fixes the settings
Similar comment, s/SecBoot/SecureBoot/g
> -Original Message-
> From: Grzegorz Bernacki
> Sent: Wednesday, May 26, 2021 5:42 PM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer.El-Haj-
> mahm...@arm.com; sunny.w...@arm.com; g...@semihalf.com;
>
Hi
I think the naming SecBootVariableLib Is confusing.
"Sec" usually means SEC phase. If it is about UEFI secure boot, you may just
name it SecureBootVariableLib.
Also don't use SecBootXXX as function name, please use SecureBootXXX.
Please done use CheckSetupMode(). The "Check" is bad naming
Hi
I have not reviewed all patches.
Just a quick comment: I don't think we allow ShellPkg dependency in
SecuritytPkg.
You may refer to
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf
Thank you
Yao Jiewen
> -Original Message-
> From:
My fault, please ignore this patch.
Thanks,
Nhi
From: devel@edk2.groups.io on behalf of Nhi Pham via
groups.io
Sent: Wednesday, May 26, 2021 5:06 PM
To: devel@edk2.groups.io
Cc: Nhi Pham OS
Subject: [edk2-devel] [PATCH 1/1] UsbCdcNetDxe: Remove reading
This patchset adds support for initialization of default
Secure Boot variables based on keys content embedded in
flash binary. This feature is active only if Secure Boot
is enabled and DEFAULT_KEY is defined. The patchset
consist also application to enroll keys from default
variables and secure
This commits add library, which consist functions related
creation/removal Secure Boot variables. Some of the functions
was moved from SecureBootConfigImpl.c file.
Signed-off-by: Grzegorz Bernacki
---
SecurityPkg/SecurityPkg.dsc
| 1 +
This commit allows to initialize Secure Boot default key
and databases from data embedded in firmware binary.
Signed-off-by: Grzegorz Bernacki
---
Platform/RaspberryPi/RPi4/RPi4.dsc | 5 -
Platform/RaspberryPi/RPi4/RPi4.fdf | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git
This application allows user to force key enrollment from
Secure Boot default variables.
Signed-off-by: Grzegorz Bernacki
---
SecurityPkg/SecEnrollDefaultKeysApp/SecEnrollDefaultKeysApp.inf | 48 +
SecurityPkg/SecEnrollDefaultKeysApp/SecEnrollDefaultKeysApp.c | 108
This commit add option which allows reset content of Secure Boot
keys and databases to default variables.
Signed-off-by: Grzegorz Bernacki
---
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
| 1 +
This driver initializes default Secure Boot keys and databases
based on keys embedded in flash.
Signed-off-by: Grzegorz Bernacki
---
SecurityPkg/VariableAuthenticated/SecBootDefaultKeysDxe/SecBootDefaultKeysDxe.inf
| 46 +
This commits add file which can be included by platform Flash
Description File. It allows to specify certificate files, which
will be embedded into binary file. The content of these files
can be used to initialize Secure Boot default keys and databases.
Signed-off-by: Grzegorz Bernacki
---
This commits adds modules related to initialization and
usage of default Secure Boot key variables to SecurityPkg.
Signed-off-by: Grzegorz Bernacki
---
SecurityPkg/SecurityPkg.dec | 14 ++
SecurityPkg/SecurityPkg.dsc | 4
2 files changed, 18 insertions(+)
diff --git
On 05/26/21 11:41, Grzegorz Bernacki wrote:
> This patchset adds support for initialization of default
> Secure Boot variables based on keys content embedded in
> flash binary. This feature is active only if Secure Boot
> is enabled and DEFAULT_KEY is defined. The patchset
> consist also
1 - 100 of 150 matches
Mail list logo
