Re: [edk2] [PATCH 2/2] MdePkg/PeCoffLoader: fix handling of ARM MOVW/MOVT instruction relocs

Reviewed-by: Liming Gao -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Friday, October 09, 2015 3:24 AM To: Leif Lindholm Cc: edk2-devel@lists.01.org; Gao, Liming; Zhu, Yonghong; Kinney, Michael D Subject: Re: [PATCH 2/2]

Re: [edk2] [PATCH v2 02/41] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

Reviewed-by: Jeff Fan -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Saturday, October 10, 2015 5:58 AM To: edk2-de...@ml01.01.org Cc: Fan, Jeff; Chen Fan; Justen, Jordan L; Kinney, Michael D Subject: [PATCH v2 02/41] UefiCpuPkg: CpuDxe:

Re: [edk2] Driver Health Protocol, UI interaction and Intel DQ77MK vs. OVMF

On 10/09/15 05:04, Ni, Ruiyu wrote: > On 2015-10-08 4:59, Bruce Cran wrote: >> I have a controller which implements the Driver Health Protocol. Under >> OVMF (built from latest edk2 master), when the controller isn't healthy >> I can go into the 'Device Manager' menu, click the 'Some drivers are

[edk2] [PATCH v2 01/41] UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU detected

From: Michael Kinney When only 1 CPU is detected and the max CPUs is greater than 1, an ASSERT() is generated because the pages associated with the AP stack have already been freed. Only do this FreePages() call if there is more than 1 CPU detected.

[edk2] [PATCH v2 13/41] OvmfPkg: pull in CpuIo2Smm driver

This driver provides EFI_SMM_CPU_IO2_PROTOCOL, which the SMM core depends on in its gEfiDxeSmmReadyToLockProtocolGuid callback (SmmReadyToLockHandler(), "MdeModulePkg/Core/PiSmmCore/PiSmmCore.c"). Approached on a higher level, this driver provides the SmmIo member of the EFI_SMM_SYSTEM_TABLE2

[edk2] [PATCH v2 05/41] OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer

The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more memory, temporarily, than what PEIFV and DXEFV will ultimately need. First, it uses an output buffer for decompression, second, the decompression itself needs a scratch buffer (and this scratch buffer is the highest area that SEC

[edk2] [PATCH v2 16/41] OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE

During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to

[edk2] [PATCH v2 02/41] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

The Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuArchDxe driver applies any MTRR changes to APs, if the EFI_MP_SERVICES_PROTOCOL is available. We should do the same. Additionally, the broadcast should occur at MP startup as well, not only when MTRR settings are changed. The inspiration is taken

[edk2] [PATCH v2 35/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: split out runtime DXE specifics

In preparation for introducing an SMM interface to this driver, move the following traits to separate files, so that we can replace them in the new SMM INF file: - Protocol installations. The SMM driver will install protocol interfaces in the SMM protocol database, using SMM services. -

[edk2] [PATCH v2 39/41] OvmfPkg: consolidate variable driver stack in DSC and FDF files

The following modules constitute the variable driver stack: - QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime alternatives for providing the Firmware Volume Block(2) Protocol, dependent on qemu pflash presence, - FaultTolerantWriteDxe, providing the Fault Tolerant Write

[edk2] [PATCH v2 23/41] OvmfPkg: QuarkPort/CpuS3DataDxe: handle IDT, GDT and MCE in ACPI_CPU_DATA

In this patch we incorporate code from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe that populates the following fields in ACPI_CPU_DATA for PiSmmCpuDxeSmm: - ACPI_CPU_DATA.GdtrProfile - ACPI_CPU_DATA.IdtrProfile - ACPI_CPU_DATA.ApMachineCheckHandlerBase -

[edk2] [PATCH v2 22/41] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.StartupVector

The StartupVector member of ACPI_CPU_DATA points to low level assembly code that starts out in real mode, and is the boot code that gets run on each AP in response to an INIT-Start-up-Start-up IPI sequence. Importantly, *each* one of PiSmmCpuDxeSmm and CpuMpDxe (from

[edk2] [PATCH v2 21/41] OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe

The PiSmmCpuDxeSmm driver depends on the ACPI_CPU_DATA structure, from a platform- and CPU-specific driver, in order to support S3. The address of this structure is communicated through the dynamic PCD PcdCpuS3DataAddress. The data and control flows are as follows (CpuMpDxe stands for the

[edk2] [PATCH v2 17/41] OvmfPkg: resolve ReportStatusCodeLib for DXE_SMM_DRIVER modules

PiSmmCpuDxeSmm depends on this library class, and it's okay to resolve it generally for all DXE_SMM_DRIVER modules. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- OvmfPkg/OvmfPkgIa32.dsc| 1 + OvmfPkg/OvmfPkgIa32X64.dsc | 1 +

[edk2] [PATCH v2 29/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: strip trailing whitespace

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 16 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c| 16

[edk2] [PATCH v2 25/41] OvmfPkg: import CpuConfigLib header from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg

The next patch added to CpuS3DataDxe will depend on this header file; import it. The typedefs for REGISTER_TYPE, CPU_REGISTER_TABLE_ENTRY, and CPU_REGISTER_TABLE are removed from the imported header file, because "UefiCpuPkg/Include/AcpiCpuData.h" already provides those. Instead, "CpuConfigLib.h"

[edk2] [PATCH v2 28/41] OvmfPkg: QuarkPort/CpuS3DataDxe: handle register tables in ACPI_CPU_DATA

Each one of the "PreSmmInitRegisterTable" and "RegisterTable" fields in ACPI_CPU_DATA is a pointer to an array of CPU_REGISTER_TABLE objects; one object per logical processor. Each table carries a variable number of CPU_REGISTER_TABLE_ENTRY objects; each entry prescribes a specific register

[edk2] [PATCH v2 14/41] OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRE

In SVN r15306 (git commit d4ba06df), "OvmfPkg: S3 Resume: fake LockBox protocol for BootScriptExecutorDxe", we installed a fake LockBox protocol in OVMF's AcpiS3SaveDxe clone. While our other AcpiS3SaveDxe customizations remain valid (or harmless), said change is invalid when OVMF is built with -D

[edk2] [PATCH v2 09/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the library instance that implements the LockBoxLib library class with SMRAM access for the PEI phase. Introduce a PEIM that produces the EFI_PEI_SMM_COMMUNICATION_PPI and PEI_SMM_ACCESS_PPI interfaces, enabling SmmLockBoxPeiLib to

[edk2] [PATCH v2 03/41] OvmfPkg: introduce -D SMM_REQUIRE and PcdSmmSmramRequire

This build time flag and corresponding Feature PCD will control whether OVMF supports (and, equivalently, requires) SMM/SMRAM support from QEMU. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Reviewed-by: Jordan Justen

[edk2] [PATCH v2 10/41] OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time DXE

The SMM core depends on EFI_SMM_ACCESS2_PROTOCOL. This small driver (which is a thin wrapper around "OvmfPkg/SmmAccess/SmramInternal.c" that was added in the previous patch) provides that protocol. Notably, EFI_SMM_ACCESS2_PROTOCOL is for boot time only, therefore our MODULE_TYPE is not

[edk2] [PATCH v2 24/41] OvmfPkg: QuarkPort/CpuS3DataDxe: handle StackAddress and StackSize

Continuing the pattern seen in the previous patches, we now incorporate code from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe that populates - ACPI_CPU_DATA.StackAddress, - ACPI_CPU_DATA.StackSize. During normal boot, CpuS3DataDxe allocates stack in the entry point for all the APs in AcpiNVS

[edk2] [PATCH v2 32/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbDevLock field

The EFI_FW_VOL_INSTANCE.FvbDevLock member is initialized and then never used. Remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 1 -

[edk2] [PATCH v2 31/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: fix VALID_ARCHITECTURES in INF

We build this driver for X64 as well -- the comment isn't overly important, but it shouldn't be misleading. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 2 +- 1 file

[edk2] [PATCH v2 34/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing needed

Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare the following entries as arrays, with two entries each: - EFI_FW_VOL_INSTANCE.FvBase[2] - ESAL_FWB_GLOBAL.FvInstance[2] In every case, the entry at subscript zero is meant as "physical address", while the entry at subscript

[edk2] [PATCH v2 40/41] OvmfPkg: pull in SMM-based variable driver stack

When -D SMM_REQUIRE is given, replace both - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf and - OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf with - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf. The outermost (= runtime DXE driver) VariableSmmRuntimeDxe enters SMM, and

[edk2] [PATCH v2 38/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: adhere to -D SMM_REQUIRE

When the user requires "security" by passing -D SMM_REQUIRE, and consequently by setting PcdSmmSmramRequire, enforce flash-based variables. Furthermore, add two ASSERT()s to catch if the wrong module were pulled into the build. Contributed-under: TianoCore Contribution Agreement 1.0

[edk2] [BaseTool][UPT][patch]Fix two wrong import for UPT

Hello Liming and all, Could you help review this patch? Thank you [Description] 1. Fix two wrong import for UPT Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hess Chen Best Regards, Chen, Hess Intel China Software Center Tel:

Re: [edk2] [BaseTool][UPT][patch]Fix two wrong import for UPT

Reviewed-by: Liming Gao -Original Message- From: Chen, Hesheng Sent: Saturday, October 10, 2015 1:43 PM To: Gao, Liming; edk2-devel@lists.01.org Subject: [BaseTool][UPT][patch]Fix two wrong import for UPT Hello Liming and all, Could you help review this patch?

Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

Laszlo, Thanks for the feedback. I agree I need to update UefiCpuPkg DSC file. Mike >-Original Message- >From: Laszlo Ersek [mailto:ler...@redhat.com] >Sent: Friday, October 09, 2015 6:57 AM >To: Kinney, Michael D >Cc: edk2-de...@ml01.01.org >Subject: Re: [edk2] [PATCH 6/7] UefiCpiPkg:

Re: [edk2] [PATCH] BaseTools/Scripts: Add PatchCheck.py script

On 10/09/15 19:13, Bjorge, Erik C wrote: > The patch has some trailing white spaces Apparently, Jordan forgot to run the script on the patch that adds the script! ;) Laszlo > but other than that it works fine. > > Reviewed-by: Erik Bjorge > > -Original

Re: [edk2] [PATCH] BaseTools/Scripts: Add PatchCheck.py script

On 2015-10-08 15:22:08, Laszlo Ersek wrote: > On 10/08/15 04:53, Jordan Justen wrote: > > This script can be used to check some expected rules for EDK II > > patches. It only works on git formatted patches. > > > > It checks both the commit message and the lines that are added in the > > patch