Re: [edk2] [Patch 08/11] MdeModulePkg: Add missing PrintLib to BdsDxe.inf

This patch looks good to me. Reviewed by: Sunny Wang Regards, Sunny Wang -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni Sent: Monday, November 02, 2015 7:34 PM To: edk2-devel@lists.01.org Cc: Ruiyu Ni; Eric Dong

Re: [edk2] [Patch 11/11] MdeModulePkg: Enable PlatformRecovery in BdsDxe driver

Hi Ray, The places for launching PlatformRecovery options and boot menu option (for Successful boot) in this code change look good to me. I think this patch can solve problem I mentioned in our previous discussion for PlatformBootManagerDefaultBootFail related patch. Thanks for making

Re: [edk2] PCI: "rejected due to resource confliction"

On 11/03/15 02:56, Ni, Ruiyu wrote: > Shell doesn't depend on PciIo protocol to find all PCI devices. I didn't know that, thank you for the info! Laszlo > > Thanks, > Ray > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek >

Re: [edk2] [PATCH] MdeModulePkg: Fix memory leak issues

Hi Jordan, Yes, you are right! It could make commit message subject clearer. I saw the related information mentioned in https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format This is my mistake. Thanks for the reminder. I will do that next time. Regards,

[edk2] [PATCH] NetworkPkg/HttpDxe: Missing CloseEvent() in HttpResponseWorker

Two additional scenarios in which CloseEvent() needs to be called: We sent a Request to HTTP server, following which we did a Response() call, with the intent of capturing only the headers. In this case, we execute an if condition in HttpResponseWorker do a goto Exit. HttpDxe will cache the body

Re: [edk2] [Patch 09/11] MdeModulePkg: Use UefiSpec.h defined macro to replace L"xxx" string

Hi Ray, This patch overall looks good to me. I just made a minor comment in this patch. You can search "[Sunny]" to find it out. Regards, Sunny Wang -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni Sent: Monday, November 02, 2015

Re: [edk2] [PATCH 1/2] ShellPkg/UefiDpLib: Fix a DP cumulative data issue

> -Original Message- > From: Zeng, Star > Sent: Monday, November 02, 2015 7:13 PM > To: Carsey, Jaben ; Cinnamon Shia > ; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH 1/2] ShellPkg/UefiDpLib: Fix a DP cumulative data > issue >

Re: [edk2] [PATCH] ShellPkg UefiDpLib: Use correct string length for the input UnicodeBuffer

Reviewed-by: Jaben Carsey > -Original Message- > From: Zeng, Star > Sent: Monday, November 02, 2015 8:02 PM > To: edk2-devel@lists.01.org > Cc: Carsey, Jaben > Subject: [PATCH] ShellPkg UefiDpLib: Use correct string length for the input >

Re: [edk2] [PATCH 03/10] ArmPkg/ArmLib: remove unused ARM9 support

On 3 November 2015 at 12:56, Leif Lindholm wrote: > On Tue, Nov 03, 2015 at 11:16:28AM +0100, Ard Biesheuvel wrote: >> The ARM9 ArmLib implementation is not referenced anywhere in the >> tree, and unlikely to be useful going forward, considering that >> ARM9 outdates

Re: [edk2] [PATCH 2/2] ShellPkg/UefiDpLib: Support dumping cumulative data

Stat, Thanks for your feedback and review. Will submit the v2 patch for addressing your comments. And submit another patch for PerformancePkg\Dp_App Thanks, Cinnamon Shia -Original Message- From: Zeng, Star [mailto:star.z...@intel.com] Sent: Tuesday, November 3, 2015 11:16 AM To: Shia,

[edk2] [PATCH v2 2/2] ShellPkg/UefiDpLib: Support dumping cumulative data

Add a new option -c to dump cumulative data. For example: shell> dp -c ==[ Cumulative ] (Times in microsec.) Cumulative Average ShortestLongest Name CountDurationDurationDurationDuration LoadImage: 200 1007000 0

Re: [edk2] [PATCH v3] ArmPlatformPkg/ArmJunoPkg: Add the correct SPI interrupt numbers for the MSI range

Thanks Jeremy. On 2 November 2015 at 20:54, Jeremy Linton wrote: > The JunoR1 has a GICv2m which is a GICv2 with a little piece of hardware > that has some memory mapped locations that can trigger traditional SPI > interrupts. This allows some basic PCIe MSI capabilities.

Re: [edk2] [PATCH 04/10] ArmPkg/ArmLib: remove unused ArmCleanDataCacheToPoU()

On Tue, Nov 03, 2015 at 11:16:29AM +0100, Ard Biesheuvel wrote: > The function ArmCleanDataCacheToPoU() has no users, and its purpose > is unclear, since it uses cache maintenance by set/way to perform > the clean to PoU, which is a dubious practice to begin with. So > remove the declaration and

Re: [edk2] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug

Hi guys, I never saw a response to this feedback I sent on the revised patch set, but I see it has now been committed. Could you let me know why my feedback was ignored? Regards, Leif On 30 October 2015 at 18:02, Leif Lindholm wrote: > Hi Ray, > > Many thanks for

Re: [edk2] [PATCH 03/10] ArmPkg/ArmLib: remove unused ARM9 support

On Tue, Nov 03, 2015 at 11:16:28AM +0100, Ard Biesheuvel wrote: > The ARM9 ArmLib implementation is not referenced anywhere in the > tree, and unlikely to be useful going forward, considering that > ARM9 outdates even ARMv6. So remove it. While I agree in principle, I don't think we can safely

[edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

The ARM architecture provides no reliable way to clean or invalidate the entire data cache at runtime. The reason is that such maintenance requires the use of set/way maintenance operations, which are suitable only for the kind of maintenance that is carried out when the cache is taken offline

[edk2] [PATCH 10/10] ArmPlatformPkg: do not invalidate the entire data cache at startup

Drop the call to ArmInvalidateDataCache () from the PrePi and PrePeiCore startup sequences. This kind of data cache maintenance should not be performed at the UEFI firmware level. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 01/10] ArmPkg/ArmLib: fix barriers in AArch64 ArmEnableMmu

From: Mark Rutland The ARM architecture requires a DSB to complete TLB maintenance, with a subsequent ISB being required to synchronize subsequent items in the current instruction stream against the completed TLB maintenance. The ArmEnableMmu function is currently missing

[edk2] [PATCH 04/10] ArmPkg/ArmLib: remove unused ArmCleanDataCacheToPoU()

The function ArmCleanDataCacheToPoU() has no users, and its purpose is unclear, since it uses cache maintenance by set/way to perform the clean to PoU, which is a dubious practice to begin with. So remove the declaration and all definitions. Contributed-under: TianoCore Contribution Agreement 1.0

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

On 03/11/2015 15:35, Xiao Guangrong wrote: > > -if ((cr0 ^ old_cr0) & X86_CR0_CD) > +if (!kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED) && > +(cr0 ^ old_cr0) & X86_CR0_CD) > kvm_zap_gfn_range(vcpu->kvm, 0, ~0ULL); > >

Re: [edk2] [PATCH 09/10] ArmVirtPkg/PrePi: do not invalidate the entire data cache at startup

On Tue, Nov 03, 2015 at 11:16:34AM +0100, Ard Biesheuvel wrote: > Drop the call to ArmInvalidateDataCache () from the PrePi startup > sequence. This kind of data cache maintenance should not be performed > at the UEFI firmware level. > > Contributed-under: TianoCore Contribution Agreement 1.0 >

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

On 11/03/15 15:58, Janusz Mocek wrote: > W dniu 03.11.2015 o 14:31, Laszlo Ersek pisze: >> On 11/03/15 13:34, Paolo Bonzini wrote: >>> >>> On 03/11/2015 02:14, Laszlo Ersek wrote: Anyway, with the following host kernel change, the AP startup problem goes away (tested on top of v4.3):

Re: [edk2] [Patch v2 1/1] AppPkg/Python remove improper characters from pyconfig.h

Reviewed-by: Erik Bjorge -Original Message- From: Daryl McDaniel [mailto:edk2-li...@mc2research.org] Sent: Tuesday, November 3, 2015 10:37 AM To: edk2-devel@lists.01.org; Carsey, Jaben ; Bjorge, Erik C ;

Re: [edk2] [Patch v2 1/1] AppPkg/Python remove improper characters from pyconfig.h

Reviewed-by: Jaben Carsey > -Original Message- > From: Daryl McDaniel [mailto:edk2-li...@mc2research.org] > Sent: Tuesday, November 03, 2015 10:37 AM > To: edk2-devel@lists.01.org; Carsey, Jaben ; > Bjorge, Erik C ;

[edk2] [PATCH v3 1/2] ShellPkg/UefiDpLib: Fix a DP cumulative data issue

The value of PERF_CUM_DATA.Count and PERF_CUM_DATA.Duration field keep cumulating on every execution of dp. Initialize the CumData at dp's entry point. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia --- ShellPkg/Library/UefiDpLib/Dp.c

[edk2] [Patch v2 1/1] AppPkg/Python remove improper characters from pyconfig.h

AppPkg: Within the Ia32 and X64 pyconfig.h files, there are 178 occurrences of an accent character, `, being used instead of a regular single quote, ', within comments. Replace all occurrences of ` within comments with '. Example: OLD: `foobar' NEW: 'foobar' The same changes are

Re: [edk2] [Patch 1/1] AppPkg/Python remove improper characters from pyconfig.h

Reviewed-by: Jaben Carsey > -Original Message- > From: Bjorge, Erik C > Sent: Tuesday, November 03, 2015 10:43 AM > To: Daryl McDaniel ; edk2-devel@lists.01.org; > Carsey, Jaben ; Rosenbaum, Lee G >

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

Ard, This is probably a reflection of my lack of deep understanding of ARM cache maintenance on more complex systems. The "entire cache" operations exist to allow transitions across major environments (initialization of non-self initializing caches, changing phases of boot, etc) to

[edk2] RELEASE_DDK3790_X64_DLINK_FLAGS has machine:AMD64

The Link flags are as below in the latest UDK2015 (and in 2014 too). Is the machine type good or should be changed to X64? RELEASE_DDK3790_X64_DLINK_FLAGS = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /IGNORE:4078 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D */Machine:AMD64*

[edk2] [PATCH v4 29/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 v4 28/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 v4 30/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 v4 35/41] 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: -

[edk2] [PATCH v4 26/41] OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRE

At this point we can enable building PiSmmCpuDxeSmm. CPU specific features, like SMRR detection, and functions that are used to initialize SMM and process SMIs, are abstracted through the SmmCpuFeaturesLib class for the PiSmmCpuDxeSmm module. Resolve it to our own implementation under OvmfPkg --

[edk2] [PATCH v4 37/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: add DXE_SMM_DRIVER build

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Reviewed-by: Jordan Justen --- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf | 89

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

> On Nov 3, 2015, at 11:42 AM, Jordan Justen wrote: > > On 2015-11-03 05:45:52, Paolo Bonzini wrote: >> >> >> On 03/11/2015 14:25, Laszlo Ersek wrote: >>> - Agreement between Paolo, Jordan and Mike about implementing >>>broadcast SMIs. I am willing to

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

On 03/11/2015 20:42, Jordan Justen wrote: > On 2015-11-03 05:45:52, Paolo Bonzini wrote: >> >> >> On 03/11/2015 14:25, Laszlo Ersek wrote: >>> - Agreement between Paolo, Jordan and Mike about implementing >>> broadcast SMIs. I am willing to code up whatever design is >>>

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

On 11/03/15 14:25, Laszlo Ersek wrote: > (6) In closing: > > - The LZMA decompression slowdown has been quirked in the upstream > kernel. A KVM ioctl() has been introduced that allows QEMU > userspace to *disable* any quirks, but as far as I can see in > QEMU, this is not

[edk2] [PATCH v4 02/41] 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

[edk2] [PATCH v4 17/41] 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

[edk2] [PATCH v4 01/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 v4 15/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 v4 12/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

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

On 2015-11-03 05:45:52, Paolo Bonzini wrote: > > > On 03/11/2015 14:25, Laszlo Ersek wrote: > > - Agreement between Paolo, Jordan and Mike about implementing > > broadcast SMIs. I am willing to code up whatever design is > > agreed upon. Can everyone involved please

[edk2] [PATCH v4 22/41] 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

[edk2] [PATCH v4 06/41] 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

[edk2] [PATCH v4 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] [PATCH v4 36/41] 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

[edk2] [PATCH v4 41/41] OvmfPkg: README: document SMM status

Cc: Paolo Bonzini Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- Notes: v4: - update to current test results v3: - this documentation is not accurate any longer, but since Paolo and

[edk2] [PATCH v4 23/41] 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

[edk2] [PATCH v4 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 v4 04/41] 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 v4 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 v4 27/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 v4 25/41] OvmfPkg: any AP in SMM should not wait for the BSP for more than 100 ms

This patch complements the previous one, "OvmfPkg: use relaxed AP SMM synchronization mode". While that patch focuses on the case when the SMI is raised synchronously by the BSP, on the BSP: BSPHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c] SmmWaitForApArrival()

[edk2] [PATCH v4 21/41] 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

[edk2] [PATCH v4 19/41] 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

[edk2] [PATCH v4 13/41] 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,

[edk2] [PATCH v4 31/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 v4 08/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 v4 14/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 v4 10/41] 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), -

[edk2] [PATCH v4 09/41] 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 v4 05/41] 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.

[edk2] [PATCH v4 11/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 v4 16/41] 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:

[edk2] [Patch] BaseTools: Print PACKAGES_PATH build environment if it is set.

Print the optional build environment PACKAGES_PATH and EDK_TOOLS_BIN. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao --- BaseTools/Source/Python/build/build.py | 4 1 file changed, 4 insertions(+) diff --git

[edk2] [Patch] BaseTools: Don't require ECP pkg in WORKSPACE when PACKAGES_PATH is set

When PACKAGES_PATH is set, ECP pkg may be in another directory, not exist in WORKSPACE. So, keep this check in single WORKSPACE. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao --- BaseTools/Source/Python/build/build.py | 22

Re: [edk2] [PATCH v3 2/2] ShellPkg/UefiDpLib: Support dumping cumulative data

On 2015/11/4 0:55, Cinnamon Shia wrote: Add a new option -c to dump cumulative data. For example: shell> dp -c ==[ Cumulative ] (Times in microsec.) Cumulative Average ShortestLongest Name CountDurationDurationDurationDuration LoadImage:

Re: [edk2] [PATCH v3 1/2] ShellPkg/UefiDpLib: Fix a DP cumulative data issue

On 2015/11/4 0:55, Cinnamon Shia wrote: The value of PERF_CUM_DATA.Count and PERF_CUM_DATA.Duration field keep cumulating on every execution of dp. Initialize the CumData at dp's entry point. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia

Re: [edk2] [Patch] CryptoPkg: Add one new API (Pkcs7GetCertificatesList) for certs retrieving.

Suggest to add a note that this new API is for signed PE/COFF image only. Other parts are good to me. Reviewed-by: Ye Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Qin Long Sent: Tuesday, November 03, 2015 2:38 PM To:

Re: [edk2] RELEASE_DDK3790_X64_DLINK_FLAGS has machine:AMD64

Sathya: DDK3790 tool chain matches Microsoft WINDDK version 3790.1830. For this version WINDDK, AMD64 is used for X64 Machine type. Thanks Liming -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew Fish Sent: Wednesday, November 04, 2015

Re: [edk2] C Coding Standards Specification disappeared

On 11/3/15 8:12 PM, Sheng, Cecil (HPS SW) wrote: The "EDK II C Coding Standards Specification v2" listed on http://tianocore.sourceforge.net/wiki/EDK_II_User_Documentation cannot be found. Is it moved to another place or ? It may have been removed because it's fairly ancient (2008) and

[edk2] C Coding Standards Specification disappeared

Hi, The "EDK II C Coding Standards Specification v2" listed on http://tianocore.sourceforge.net/wiki/EDK_II_User_Documentation cannot be found. Is it moved to another place or ? Sincerely, Cecil Sheng ISS Firmware Development HP Servers ___

[edk2] [Patch] Add BIOS Item "RTC Battery Present"

Signed-off-by: lushifex --- Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl | 5 +++-- Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl| 14 -- Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c | 3 ++-

Re: [edk2] [Patch] Add BIOS Item "RTC Battery Present"

Reviewed-by: Tim He -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of lushifex Sent: Wednesday, November 04, 2015 1:05 PM To: edk2-devel@lists.01.org Subject: [edk2] [Patch] Add BIOS Item "RTC Battery Present" Signed-off-by:

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

On 03/11/2015 14:25, Laszlo Ersek wrote: > - Agreement between Paolo, Jordan and Mike about implementing > broadcast SMIs. I am willing to code up whatever design is > agreed upon. Can everyone involved please prioritize this > discussion a little? Actually, I was

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

Please don't remove this functionality. At times we do want to use this library to turn off the cache in preparation for going to another environment (say, loading an OS) and this is useful. Eugene -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

On 11/03/15 14:45, Paolo Bonzini wrote: > > > On 03/11/2015 14:25, Laszlo Ersek wrote: >> - Agreement between Paolo, Jordan and Mike about implementing >> broadcast SMIs. I am willing to code up whatever design is >> agreed upon. Can everyone involved please prioritize this

Re: [edk2] [PATCH v2 2/2] ShellPkg/UefiDpLib: Support dumping cumulative data

On 2015/11/3 21:26, Cinnamon Shia wrote: Add a new option -c to dump cumulative data. For example: shell> dp -c ==[ Cumulative ] (Times in microsec.) Cumulative Average ShortestLongest Name CountDurationDurationDurationDuration LoadImage:

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

On 3 November 2015 at 14:51, Cohen, Eugene wrote: > Please don't remove this functionality. At times we do want to use this > library to turn off the cache in preparation for going to another environment > (say, loading an OS) and this is useful. > Note that this is not about

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

W dniu 03.11.2015 o 14:31, Laszlo Ersek pisze: > On 11/03/15 13:34, Paolo Bonzini wrote: >> >> On 03/11/2015 02:14, Laszlo Ersek wrote: >>> Anyway, with the following host kernel change, the AP startup problem >>> goes away (tested on top of v4.3): >>> > diff --git a/arch/x86/kvm/x86.c

Re: [edk2] [PATCH 06/10] ArmPkg/ArmLib: retrieve cache line length from CTR not CCSIDR

Hi, On Tue, Nov 03, 2015 at 11:16:31AM +0100, Ard Biesheuvel wrote: > The stride used by the cache maintenance by MVA instructions should > be retrieved from CTR_EL0.DminLine and CTR_EL0.IminLine, whose values > reflect the actual geometry of the caches. Using CCSIDR for this purpose > violates

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

On Tue, Nov 03, 2015 at 01:51:46PM +, Cohen, Eugene wrote: > Please don't remove this functionality. At times we do want to use > this library to turn off the cache in preparation for going to another > environment (say, loading an OS) and this is useful. Could you elaborate on your

Re: [edk2] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug

Leif, I saw your feedbacks as your opinion if you create patches. I don't think your opinion is the *only* right solution. I can also split 3/4 in your patch serials to two patches: one is to just change DumpBridgeResource(), the other is for the remaining changes. So I think my splitting way is

Re: [edk2] [PATCH 05/10] ArmPkg/ArmLib: remove CCSIDR based cache info routines

On Tue, Nov 03, 2015 at 11:16:30AM +0100, Ard Biesheuvel wrote: > The ARM architecture does not allow the actual geometries of the caches > to be inferred from the CCSIDR cache info system register, since the > geometry it reports is intended for performing cache maintenance by > set/way and

Re: [edk2] [PATCH 07/10] ArmPkg/ArmLib: move cache maintenance sync barriers out of loop

On Tue, Nov 03, 2015 at 11:16:32AM +0100, Ard Biesheuvel wrote: > There is no need to issue a full data synchronization barrier and an > instruction synchronization barrier after each and every set/way or > MVA cache maintenance operation. For the set/way case, we can simply > remove them, since

Re: [edk2] [PATCH v2 2/2] ShellPkg/UefiDpLib: Support dumping cumulative data

Hi Star, Thanks for your feedback. Will address your comments in patch v3. Thanks, Cinnamon Shia -Original Message- From: Zeng, Star [mailto:star.z...@intel.com] Sent: Tuesday, November 3, 2015 10:06 PM To: Shia, Cinnamon; edk2-devel@lists.01.org Subject: Re: [edk2] [PATCH v2 2/2]