Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

W dniu 15.10.2015 o 08:41, Xiao Guangrong pisze: > > > On 10/15/2015 02:19 PM, Janusz wrote: >> W dniu 15.10.2015 o 06:19, Xiao Guangrong pisze: >>> >>> >>> >>> Well, the bug may be not in KVM. When this bug happened, i saw OVMF >>> only checked 1 CPU out, there is the log from OVMF's debug input:

Re: [edk2] [Patch 2/2] MdeModulePkg: reset DHCP child when leaving PXE LoadFile.

Thanks Ting, I will update the words when commit the patch. -Original Message- From: Ye, Ting Sent: Thursday, October 15, 2015 2:27 PM To: Fu, Siyuan ; edk2-devel@lists.01.org Cc: srira...@hpe.com Subject: RE: [Patch 2/2] MdeModulePkg: reset DHCP child when leaving PXE LoadFile. Suggest

Re: [edk2] [Patch 2/2] MdeModulePkg: reset DHCP child when leaving PXE LoadFile.

Suggest to update the comments below: Other functionality of PXE Base Code protocol will not be stopped, when downloading is successfully. This is confusing since although we stopped DHCP instance when downloading is successfully in this patch, The PXEBC protocol still capable of providing full

Re: [edk2] [Patch] NetworkPkg: remove unnecessary timeout event when setting IPv6 address.

Reviewed-by: Jiaxin Wu -Original Message- From: Fu, Siyuan Sent: Thursday, October 15, 2015 1:50 PM To: edk2-devel@lists.01.org Cc: Ye, Ting; Wu, Jiaxin Subject: [Patch] NetworkPkg: remove unnecessary timeout event when setting IPv6 address. Use Ip6Cfg->SetData() to set IP6 manual addr

Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

W dniu 15.10.2015 o 06:19, Xiao Guangrong pisze: > > > > Well, the bug may be not in KVM. When this bug happened, i saw OVMF > only checked 1 CPU out, there is the log from OVMF's debug input: > > Flushing GCD > Flushing GCD > Flushing GCD > Flushing GCD > Flushing GCD > Flushing GCD >

Re: [edk2] [Patch] NetworkPkg: remove unnecessary timeout event when setting IPv6 address.

Reviewed-by: Ye Ting -Original Message- From: Fu, Siyuan Sent: Thursday, October 15, 2015 1:50 PM To: edk2-devel@lists.01.org Cc: Ye, Ting; Wu, Jiaxin Subject: [Patch] NetworkPkg: remove unnecessary timeout event when setting IPv6 address. Use Ip6Cfg->SetData() to set IP6 manual addre

[edk2] [Patch 1/2] NetworkPkg: reset DHCP child when leaving PXE LoadFile.

The DHCP4 can have only one configured child instance so we need to reset the DHCP4 child when leaving PXE driver's LoadFile() function, otherwise the other programs which also need to use DHCP4 (like HTTP boot) will be impacted. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-b

[edk2] [Patch 0/2] NetworkPkg: reset DHCP child when leaving PXE LoadFile.

The DHCP4 can have only one configured child instance so we need to reset the DHCP4 child when leaving PXE driver's LoadFile() function, otherwise the other programs which also need to use DHCP4 (like HTTP boot) will be impacted. Fu Siyuan (2): NetworkPkg: reset DHCP child when leaving PXE LoadF

[edk2] [Patch 2/2] MdeModulePkg: reset DHCP child when leaving PXE LoadFile.

The DHCP4 can have only one configured child instance so we need to reset the DHCP4 child when leaving PXE driver's LoadFile() function, otherwise the other programs which also need to use DHCP4 (like HTTP boot) will be impacted. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-b

[edk2] [Patch] NetworkPkg: remove unnecessary timeout event when setting IPv6 address.

Use Ip6Cfg->SetData() to set IP6 manual address is asynchronous process and the registered data notify event will be singled when process is done. So it's not necessary to create another timeout event for the address setting. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: F

Re: [edk2] [PATCH] SecurityPkg: fix Rsa2048Sha256GuidedSectionExtractLib issue causing section overruns and possible hangs due to bad output size calculation

Cohen: I agree it is a mismatch between sectionGetInfo & SectionHandler. Your patch always minus sizeof (RSA_2048_SHA_256_SECTION2_HEADER). It is not correct for SECTION1. Thanks & Best regards Chao Zhang -Original Message- From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Wed

Re: [edk2] [PATCH v3 00/52] OvmfPkg: support SMM for better security (steps towards MP and X64)

Laszlo, I have 32 VCPUs booting to UEFI Shell using Windows build of 32-bit QEMU. If more than 32, then we run out of SMRAM. I have made 2 changes from your branch to make this stable: 1) Force 32KB SMBASE alignment. Required for me because I am using pre-built QEMU binary. 2) Your patch to s

Re: [edk2] [PATCH] MdeModulePkg VariableRuntimeDxe: Add the missing gEfiImageSecurityDatabaseGuid

reviewed by jiewen@intel.com -Original Message- From: Zeng, Star Sent: Thursday, October 15, 2015 10:58 AM To: edk2-devel@lists.01.org Cc: Yao, Jiewen Subject: [PATCH] MdeModulePkg VariableRuntimeDxe: Add the missing gEfiImageSecurityDatabaseGuid Otherwise there will be build failur

Re: [edk2] [PATCH] SecurityPkg AuthVariableLib: Add the missing gEfiAuthenticatedVariableGuid

reviewed by jiewen@intel.com -Original Message- From: Zeng, Star Sent: Thursday, October 15, 2015 10:58 AM To: edk2-devel@lists.01.org Cc: Yao, Jiewen Subject: [PATCH] SecurityPkg AuthVariableLib: Add the missing gEfiAuthenticatedVariableGuid There is no real build failure, as AuthV

Re: [edk2] [PATCH] MdeModulepkg VarCheckLib: Return NULL when no property set

Looks good, reviewed by jiewen@intel.com -Original Message- From: Zeng, Star Sent: Thursday, October 15, 2015 10:58 AM To: edk2-devel@lists.01.org Cc: Yao, Jiewen Subject: [PATCH] MdeModulepkg VarCheckLib: Return NULL when no property set to variable with wildcard name. VarCheckLib

[edk2] [PATCH] MdeModulepkg VarCheckLib: Return NULL when no property set

to variable with wildcard name. VarCheckLib has zeroed property for variable with wildcard name and is waiting for property set. The code should return NULL when no property set to variable with wildcard name, but not return the zeroed property that will impact the functionality of SetVariableChec

[edk2] [PATCH] MdeModulePkg VariableRuntimeDxe: Add the missing gEfiImageSecurityDatabaseGuid

Otherwise there will be build failure if without VarCheckUefiLib linked. Cc: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf | 4 1 file changed, 4 insertions(+) diff --git a/

[edk2] [PATCH] SecurityPkg AuthVariableLib: Add the missing gEfiAuthenticatedVariableGuid

There is no real build failure, as AuthVariableLib always links to variable driver. But for code integrity, we should add it. Cc: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf | 4 1

[edk2] [Patch] BaseTools: Add MultipleWorkspace.py in the common dependency.

Add new added MultipleWorkspace.py in the common dependency to freeze python tools for Windows. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao --- BaseTools/Source/Python/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/BaseTools/Source/Python/Makef

Re: [edk2] [grub PATCH] efinet: disable MNP background polling

So the current problem is: GRUB wants to EXCLUSIVE open SNP, though if other application/driver already opens SNP with EXCLUSIVE attribute, the GRUB would fail. According to UEFI spec V2.5 page 182, If Attributes is BY_DRIVER , BY_DRIVER|EXCLUSIVE, or EXCLUSIVE, and there are any items

Re: [edk2] [PATCH] ShellPkg: Use safe string functions to refine Tftp.c code.

It was found through code review. Use safe string functions (StrCpyS, StrCatS...) can avoid potential buffer overflow. I will update the commit message. -Shumin -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif Lindholm Sent: Wednesday, Octob

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

Ersek & Bonzini, >From SDM 34.5.2, SMI Handler Operating Mode Switching. "Any required change to operating mode is performed by the RSM instruction; there is no need for the SMI handler to change modes explicitly prior to executing RSM." So, I don't think we need to go back to 32-bit PM before R

Re: [edk2] [Patch] IntelFrameworkModulePkg BdsDxe: Use PcdSet##S to replace PcdSet##

On 2015/10/14 13:35, Eric Dong wrote: PcdSet## has no error status returned, then the caller has no idea about whether the set operation is successful or not. PcdSet##S were added to return error status and PcdSet## APIs were put in ifndef DISABLE_NEW_DEPRECATED_INTERFACES condition. To adopt P

Re: [edk2] [Patch 1/2] BaseTools VfrCompiler: In order to keep consistent, add an optional "; " for condition op-code.

Leif, Got it, I will update the format to follow the BaseTools/Contributions.txt. Thanks for your comments. Thanks, Eric -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif Lindholm Sent: Wednesday, October 14, 2015 10:32 PM To: Dong, Eric Cc:

[edk2] [PATCH v2 16/16] UefiCpuPkg: Add PiSmmCpuDxeSmm module X64 files

Add module that initializes a CPU for the SMM environment and installs the first level SMI handler. This module along with the SMM IPL and SMM Core provide the services required for DXE_SMM_DRIVERS to register hardware and software SMI handlers. CPU specific features are abstracted through the Sm

[edk2] [PATCH v2 04/16] UefiCpuPkg: Add PlatformSecLib

Add PlatformSecLib class and PlatformSecLibNull instance that is used by the SecCore. PlatformSecLibNull should not be used in a platform build. Instead, it should be used as a template for implementing a platform specific instance of the PlatformSecLib library class. Contributed-under: TianoCor

[edk2] [PATCH v2 08/16] UefiCpuPkg: Add SmmCpuPlatformHookLib

Add SmmCpuPlatformHookLib that provides platform specific functions that are used to initialize SMM and process SMIs. A Null instance of this library is provided that should work for most platforms. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney --- UefiCp

[edk2] [PATCH v2 00/16] UefiCpuPkg: Add CPU SMM and SecCore

Public branch: Changes from PATCH v1 to PATCH v2: 1) Fix CRLF line ending issues reported by Laszlo 2) Break up into a larger set of smaller patches 3) Remove APState field from ACPI_CPU_DATA structure 4) Use module type specific CpuExce

[edk2] [PATCH v2 07/16] UefiCpuPkg: Add SmmCpuFeaturesLib

Add SmmCpuFeaturesLib that provides CPU specific functions that are used to initialize SMM and process SMIs. A functional implementation of this library class is provided that is based on the Intel(R) 64 and IA-32 Architectures Software Developer's Manual Contributed-under: TianoCore Contribution

[edk2] [PATCH v2 12/16] UefiCpuPkg: Add CPU Hot Plug Data include file

Add CpuHotPlugData.h that defines a data structure that is shared between modules and is required for to support hot plug CPUs. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney --- UefiCpuPkg/Include/CpuHotPlugData.h | 33 + 1

[edk2] [PATCH v2 13/16] UefiCpuPkg: Update DEC/DSC files for new includes and libraries

Add SmmCpuPlatformHookLib library class declaration Add SmmCpuFeaturesLib library class declaration Add gEfiSmmCpuServiceProtocolGuid protocol declaration Build SmmCpuPlatformHookLibNull library instance Build SmmCpuFeaturesLib library instance Changes between [PATCH v1] and [PATCH v2]: 1) Use mod

[edk2] [PATCH v2 10/16] UefiCpuPkg: Add SMRAM Save State include file

Add SmramSaveStateMap.h file that defines the 32-bit and 64-bit CPU SMRAM Save State Map. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney --- UefiCpuPkg/Include/Register/SmramSaveStateMap.h | 190 1 file changed, 190 insertions(+) c

[edk2] [PATCH v2 15/16] UefiCpuPkg: Add PiSmmCpuDxeSmm module IA32 files

Add module that initializes a CPU for the SMM environment and installs the first level SMI handler. This module along with the SMM IPL and SMM Core provide the services required for DXE_SMM_DRIVERS to register hardware and software SMI handlers. CPU specific features are abstracted through the Sm

[edk2] [PATCH v2 11/16] UefiCpuPkg: Add ACPI CPU Data include file

Add AcpuCpuData.h that defines a data structure that is shared between modules and is required for ACPI S3 support. APState field removed between V1 and V2 patch. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney Cc: Laszlo Ersek --- UefiCpuPkg/Include/AcpiCp

[edk2] [PATCH v2 02/16] UefiCpuPkg: Update CPU MP drivers to support single CPU configuration

Only perform AP detection if PcdCpuMaxLogicalProcessorNumber > 1 Only free AP related structures of they were allocated Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney --- UefiCpuPkg/CpuDxe/CpuMp.c | 49 -- UefiCp

[edk2] [PATCH v2 09/16] UefiCpuPkg: Add SMM CPU Service Protocol

Add definition of the SMM CPU Service Protocol that is produced by the PiSmmCpuDxeSmm module. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney --- UefiCpuPkg/Include/Protocol/SmmCpuService.h | 209 1 file changed, 209 insertions(+

[edk2] [PATCH v2 06/16] UefiCpuPkg: Add SecCore module and supporting library class and PCD

Add declaration of PlatformSecLib library class to DEC file Add declaration of PcdPeiTemporaryRamStackSize PCD to DEC/UNI file Add build of PlatformSecLibNull to DSC file Add build of SecCore to DSC file Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney --- Ue

[edk2] [PATCH v2 05/16] UefiCpuPkg: Add SecCore module

Add SecCore module that uses the PlatformSecLib class for platform specific actions. The SecCore module also uses a new PCD to configure the size of the stack used in the SEC phase. If the stack size PCD is set to 0, the stack is configured to use half of the available temporary RAM. Contributed

[edk2] [PATCH v2 01/16] UefiCpuPkg: Add Cpuid.h include files for CPUID related defines

Move CPUID related defines from LocalApic.h to Cpuid.h Update LocalApicLib instances to include Cpuid.h Update CpuMpPei module to include Cpuid.h Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney --- UefiCpuPkg/CpuMpPei/CpuMpPei.h | 1 + U

[edk2] [PATCH v2 03/16] UefiCpuPkg: Add SMM Communication PPI and Handler Modules

Add modules that produce the SMM Communications PPI and install a SW SMI handler for SMM Communication requests Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney --- .../PiSmmCommunication/PiSmmCommunicationPei.c | 425 + .../PiSmmCommu

[edk2] [PATCH v3 51/52] OvmfPkg: double the SMRAM (TSEG) size for the 64-bit DXE phase builds

When building OVMF with -D SMM_REQUIRE -D SECURE_BOOT_ENABLE, using gcc-4.8, for the DEBUG build target, and with DEBUG_VERBOSE enabled in PcdDebugPrintErrorLevel, the build report files report the following binary sizes for the SMM_CORE and SMM modules, in kilobytes: Driver

[edk2] [PATCH v3 45/52] 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. - Virtual

[edk2] [PATCH v3 50/52] 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 v3 35/52] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.MtrrTable

It has been deemed inappropriate, for general use, for UefiCpuPkg/CpuDxe to keep reflecting the most recent MTRR settings to an AcpiNVS buffer, for CpuS3DataDxe to pass through to PiSmmCpuDxeSmm. Instead, Michael Kinney suggested to fetch and save the MTRR settings in CpuS3DataDxe, in a similarly d

[edk2] [PATCH v3 37/52] OvmfPkg: port CpuS3DataDxe to X64

From: Paolo Bonzini The descriptor format is different and the assembly source is converted to nasm, but otherwise there is no difference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini --- Notes: v3: - new in v3 OvmfPkg/QuarkPort/CpuS3DataDxe/Cp

[edk2] [PATCH v3 47/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: add DXE_SMM_DRIVER build

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf | 89 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c | 66 +++ 2 files changed, 155 insertions(+) diff

[edk2] [PATCH v3 46/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: clean up includes and libraries

Before introducing the SMM driver interface, clean up #include directives and [LibraryClasses] by: - removing what's not directly used, - adding what's used but not spelled out, - sorting the result. This helps with seeing each source file's dependencies and with determining the library classes fo

[edk2] [PATCH v3 52/52] OvmfPkg: README: document SMM status

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- Notes: v3: - this documentation is not accurate any longer, but since Paolo and myself are getting different test results, I'm not bothering updating this until our results converge

[edk2] [PATCH v3 40/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: rewrap source code to 79 chars

Some of the line lengths in this driver are atrocious. While we have to put up with the status quo outside of OvmfPkg, we can at least rewrap this driver before refactoring it. In the FvbInitialize() function there's no way around introducing two local variables, just for the sake of sensibly rewr

[edk2] [PATCH v3 43/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbScratchSpace field

The ESAL_FWB_GLOBAL.FvbScratchSpace array is never initialized (it contains garbage from AllocateRuntimePool()). Its element at subscript one (=FVB_VIRTUAL), containing garbage as well, is converted to virtual mapping. Then the array is never used again. Remove it. Contributed-under: TianoCore Co

[edk2] [PATCH v3 44/52] 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 v3 42/52] 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 - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c

[edk2] [PATCH v3 48/52] 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 Signed-off-by

[edk2] [PATCH v3 49/52] 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 P

[edk2] [PATCH v3 36/52] 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 setting

[edk2] [PATCH v3 34/52] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.NumberOfCpus

Following the same method as before, we incorporate code from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe that sets "mCpuConfigConextBuffer.NumberOfProcessors" on the entry point's call stack, and ultimately stores it into ACPI_CPU_DATA.NumberOfCpus on SmmConfigurationEventNotify()'s call stac

[edk2] [PATCH v3 31/52] 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 - ACPI_CPU_DATA.ApMachineCheckHandlerSi

[edk2] [PATCH v3 41/52] 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 changed, 1 insertion

[edk2] [PATCH v3 38/52] OvmfPkg: build QuarkPort/CpuS3DataDxe for -D SMM_REQUIRE

Thanks to the previous patch, from Paolo, we can now build QuarkPort/CpuS3DataDxe for X64 as well. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- Notes: v3: - new in v3; split out from "OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe". OvmfPk

[edk2] [PATCH v3 33/52] 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 v3 39/52] 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 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServi

[edk2] [PATCH v3 32/52] 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 v3 29/52] 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 original

[edk2] [PATCH v3 28/52] OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRE

At this point we can enable building PiSmmCpuDxeSmm. The SmmLib dependency is resolved to MdePkg's SmmLibNull instance. First, this matches the resolution in "UefiCpuPkg/UefiCpuPkg.dsc". Second, from this library class, PiSmmCpuDxeSmm calls the ClearSmi() interface only, and that API is a no-op on

[edk2] [PATCH v3 17/52] OvmfPkg: LockBox: -D SMM_REQUIRE excludes our fake lockbox

When the user builds OVMF with -D SMM_REQUIRE, our LockBox implementation must not be used, since it doesn't actually protect data in the LockBox from the runtime guest OS. Add an according assert to LockBoxLibInitialize(). Furthermore, since our LockBox must not be selected with -D SMM_REQUIRE, i

[edk2] [PATCH v3 10/52] OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire set

PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations: - PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed so that it ends with the RAM below 4GB, - QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are created for the RAM below 4GB; plus M

[edk2] [PATCH v3 27/52] OvmfPkg: use relaxed AP SMM synchronization mode

From: Paolo Bonzini Port 0xb2 on QEMU only sends an SMI to the currently executing processor. The SMI handler, however, and in particular SmmWaitForApArrival, currently expects that SmmControl2DxeTrigger triggers an SMI IPI on all processors rather than just the BSP. Thus all SMM invocations loo

[edk2] [PATCH v3 04/52] 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 v3 08/52] OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set

If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is not trusted and we should defend against it tampering with the firmware's data. One such datum is the PEI firmware volume (PEIFV). Normally PEIFV is decompressed on the first boot by SEC, then the OS preserves it across S3

[edk2] [PATCH v3 22/52] OvmfPkg: set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection to FALSE

Explanation from Michael Kinney: This PCD allows a platform to provide PlatformSmmBspElection() in a platform specific SmmCpuPlatformHookLib instance to decide which CPU gets elected to be the BSP in each SMI. The SmmCpuPlatformHookLibNull [instance] always returns EFI_NOT_READY for tha

[edk2] [PATCH v3 16/52] 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 v3 24/52] OvmfPkg: SmmCpuFeaturesLib: remove unnecessary bits

From: Paolo Bonzini SMRR and MTRR support is not needed on a virtual platform. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini Acked-by: Laszlo Ersek [ler...@redhat.com: insert space between ASSERT and (), convert to CRLF] Cc: Paolo Bonzini Contributed-und

[edk2] [PATCH v3 20/52] OvmfPkg: resolve CpuExceptionHandlerLib for DXE_SMM_DRIVER modules

UefiCpuPkg/PiSmmCpuDxeSmm depends on this library (the RegisterCpuInterruptHandler() function specifically) to set up its specialized page fault handler (SmiPFHandler() -> DumpModuleInfoByIp()). It doesn't hurt to resolve this library class for all DXE_SMM_DRIVER modules. Contributed-under: TianoC

[edk2] [PATCH v3 21/52] OvmfPkg: resolve DebugAgentLib for DXE_SMM_DRIVER modules

From: Michael Kinney Add mappings to DebugAgentLib for SMM modules to prevent build breaks when SMM_REQUIRE and SOURCE_DEBUG_ENABLE are both set. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney [ler...@redhat.com: cover the X64 dsc, update commit msg, kudos

[edk2] [PATCH v3 13/52] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the mSmmControl2->Trigger() call in the SmmCommunicationCommunicate() function [MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c]. Contributed-under: TianoCore Contribution Agreement

[edk2] [PATCH v3 18/52] 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 fo

[edk2] [PATCH v3 19/52] 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 + OvmfPkg/OvmfPkgX64.dsc

[edk2] [PATCH v3 11/52] 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 work.

[edk2] [PATCH v3 26/52] OvmfPkg: SmmCpuFeaturesLib: customize state save map format

From: Paolo Bonzini This adjusts the previously introduced state save map access functions, to account for QEMU and KVM's 64-bit state save map following the AMD spec rather than the Intel one. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini [ler...@redhat.c

[edk2] [PATCH v3 15/52] 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 (SMS

[edk2] [PATCH v3 23/52] OvmfPkg: import SmmCpuFeaturesLib from UefiCpuPkg

From: Paolo Bonzini The next patches will customize the implementation, but let's start from the common version to better show the changes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini [ler...@redhat.com: drop UNI file, keep whitespace intact, generate ne

[edk2] [PATCH v3 25/52] OvmfPkg: SmmCpuFeaturesLib: implement SMRAM state save map access

From: Paolo Bonzini This implementation copies SMRAM state save map access from the PiSmmCpuDxeSmm module. The most notable change is: - dropping support for EFI_SMM_SAVE_STATE_REGISTER_IO - changing the implementation of EFI_SMM_SAVE_STATE_REGISTER_LMA to use the SMM revision id instead of

[edk2] [PATCH v3 06/52] OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib handler table

BaseExtractGuidedSectionLib uses a table at the static physical address PcdGuidedExtractHandlerTableAddress, and modules that are linked against BaseExtractGuidedSectionLib are expected to work together on that table. Namely, some modules can register handlers for GUIDed sections, some other module

[edk2] [PATCH v3 30/52] 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 Quark_EDKII_v1.1.0/IA32FamilyC

[edk2] [PATCH v3 05/52] 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 --- OvmfPkg/OvmfPkg.dec| 10 +++

[edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

From: Paolo Bonzini According to Intel this is invalid. Go back to 32-bit protected mode and clear EFER.LME before executing RSM. Cc: Michael Kinney Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini --- Notes: v3: - New in v3, but included only for

[edk2] [PATCH v3 14/52] OvmfPkg: pull in the SMM IPL and SMM core

"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" (a DXE_RUNTIME_DRIVER) implements the SMM Initial Program Loader. It produces EFI_SMM_BASE2_PROTOCOL and EFI_SMM_COMMUNICATION_PROTOCOL, relying on: - EFI_SMM_ACCESS2_PROTOCOL (provided by OvmfPkg/SmmAccess/SmmAccess2Dxe.inf), - EFI_SMM_CONTROL2_PROTOCOL

[edk2] [PATCH v3 12/52] 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 DXE_RUNTIM

[edk2] [PATCH v3 07/52] 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 v3 09/52] OvmfPkg: PlatformPei: allow caching in AddReservedMemoryBaseSizeHob()

AddReservedMemoryBaseSizeHob() should be able to set the same resource attributes for reserved memory as AddMemoryBaseSizeHob() sets for system memory. Add a new parameter called "Cacheable" to AddReservedMemoryBaseSizeHob(), and set it to FALSE in the only caller we have at the moment. Contribute

[edk2] [PATCH v3 02/52] UefiCpuPkg: PiSmmCpuDxeSmm: prepare PT in InitPaging before filling in PDE

From: Paolo Bonzini InitPaging() is setting a page directory entry before initializing the corresponding page table. This works on real hardware (including KVM), but the TLB of QEMU's emulation mode is different (possibly it has different associativity, I don't really know) so at some point exec

[edk2] [PATCH v3 00/52] OvmfPkg: support SMM for better security (steps towards MP and X64)

Public branch: . (Mike's v1 patches are again contained in this branch, but I have converted them to CRLF.) * Relative to v2, the following patches are new in v3 (also marked individually in the Notes sections): * PiSmmCpuDxeSmm fixes from

[edk2] [PATCH v3 01/52] 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. Contributed-under: TianoCore Contribution Agr

[edk2] [PATCH] OvmfPkg: Sec: Fix SOURCE_DEBUG_ENABLE ASSERT()

The update to the LocalApicLib instances to make sure the Local APIC is initialize before use generates an ASSERT() when SOURCE_DEBUG_ENABLE is enabled for OVMF. The fix is to initialize the Local APIC Timer and mask it before initialing the DebugAgent. Contributed-under: TianoCore Contribution A

Re: [edk2] [PATCH] ShellPkg: Use safe string functions to refine Tftp.c code.

Please put the 'if' statement on its own line. -Erik -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Qiu Shumin Sent: Tuesday, October 13, 2015 10:00 PM To: edk2-devel@lists.01.org Cc: Carsey, Jaben ; Qiu, Shumin Subject: [edk2] [PATCH] ShellPkg

Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

W dniu 14.10.2015 o 10:32, Xiao Guangrong pisze: > > > On 10/14/2015 04:24 PM, Xiao Guangrong wrote: >> >> >> On 10/14/2015 03:37 PM, Janusz wrote: >>> I was able to run my virtual machine with this, but had very high cpu >>> usage when something happen in it like booting system. once, my virtual >

Re: [edk2] [grub PATCH] efinet: disable MNP background polling

14.10.2015 11:00, Ye, Ting пишет: Could you please describe the details how does GRUB use UEFI network protocols? When efinet driver is loaded it enumerates handles with SNP; these handles represent network cards for grub. If driver is part of initial core.img (default for network boot image

Re: [edk2] [PATCH v2 1/8] ArmPlatformPkg: NorFlashDxe: mellow DEBUG messages about flash reinit

On Wed, Oct 14, 2015 at 02:30:21PM +0200, Laszlo Ersek wrote: > The ValidateFvHeader() function checks several conditions against the > firmware volume header. Failure of the first of these checks, reported as > "No Firmware Volume header present", is a common situation for unformatted > flash imag

[edk2] [PATCH] Correct ACPI tables on the Juno for recent linux versions

This set of patches updates the ACPI tables for the JunoR1 in keeping with recent changes to the linux kernel. These changes allow both the RHEL and mainline kernels to boot with a functional USB and network adapter. Given the previous PCIe change posted by Supreeth, and this one, the PCIe host b

[edk2] [PATCH] Update the ACPI device information for ARM Juno.

These patches correct a number of problems with the JUNO ACPI tables. First, put CCA attributes on the devices which can do DMA. This is because the linux kernel now requires ARM64 devices specify a coherency model. Without CCA the devices are unable to perform DMA. Update the EHCI window to a fu

  1   2   >