Re: [edk2] [PATCH 2/6] ArmLib/ArmV7Mmu: use 64-bit type for mapping region size

On Mon, Nov 23, 2015 at 05:56:29PM +0100, Ard Biesheuvel wrote: > The way the v7 MMU code is invoked by the Xen port is somewhat of > a pathological case, since it describes its physical memory space > using a single cacheable region that covers the entire addressable > range. When clipping this

Re: [edk2] [PATCH] ShellBinPkg: Arm/AArch64 Shell binary update.

I'll take that as a reviewed-by, thanks :) Pushed as r18925. On Mon, Nov 23, 2015 at 05:21:16PM +, Carsey, Jaben wrote: > Not sure how to RB this ... it's fine with me to commit it. > > > -Original Message- > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > Sent:

Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

Laszlo, Comments below. Mike > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Monday, November 23, 2015 4:34 AM > To: Kinney, Michael D ; edk2-de...@ml01.01.org > Cc: Justen, Jordan L > Subject: Re:

Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

On 11/23/15 21:13, Kinney, Michael D wrote: > Laszlo, > > Comments below. > > Mike > >> -Original Message- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Monday, November 23, 2015 4:34 AM >> To: Kinney, Michael D ; edk2-de...@ml01.01.org >> Cc:

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

Laszlo, There are 2 reasons to list all source files used in a module build in the [Sources] section. 1) Support incremental builds. If a change to the .h file is made, then the module may not be rebuilt if the .h file is not listed in [Sources] 2) Support of UEFI Distribution Package

[edk2] [Patch 0/3] Enable x2APIC if one x2APIC ID is larger than 254

If there are any logical processor reporting an APIC ID of 255 or greater. We should enable x2APIC mode. Jeff Fan (3): UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if x2APIC supported UefiCpuPkg/CpuMpPei: Set X2APIC flag if one x2APIC ID larger than 254 UefiCpuPkg/CpuMpPei: Enable x2APIC

[edk2] [Patch 2/3] UefiCpuPkg/CpuMpPei: Set X2APIC flag if one x2APIC ID larger than 254

If there are any logical processor reporting an APIC ID of 255 or greater, set X2ApicEnable flag. Cc: Feng Tian Cc: Michael Kinney Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan ---

[edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if x2APIC supported

If x2APIC is supported by processor, get the APIC ID from CPUID.(EAX=0BH, ECX=0H):EDX instead of legacy APIC ID. It is used to check if need to enable x2APIC mode. Cc: Feng Tian Cc: Michael Kinney Contributed-under: TianoCore Contribution

Re: [edk2] [PATCH 0/2] ArmVirtPkg: limit IPA space to prevent page table memory waste

On 11/21/15 10:44, Ard Biesheuvel wrote: > Hello all, > > After Drew pointed out that mach-virt now populates the memory region beyond > DRAM, I am proposing this approach instead. Since KVM limits its IPA space to > 40 bits, there is simply no point in supporting anything beyond that for >

Re: [edk2] [PATCH 1/2] ArmVirtPkg/ArmVirtPlatformLib: reduce ID map size to GCD region size

On 23 November 2015 at 12:41, Laszlo Ersek wrote: > On 11/21/15 10:44, Ard Biesheuvel wrote: >> The ID mapping routines on virtual platforms simply map the entire >> address space as device memory, and then punch some holes for regions >> that need to be mapped cacheable. On

[edk2] [patch] UefiCpuPkg/PiSmmCpu: Correct TSS segment.

TSS segment should use (SIZE - 1) as limit, and do not set G bit (highest bit of LimitHigh) because limit means byte count. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yao, Jiewen Cc: Fan, Jeff Cc: Kinney, Michael D

Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

On 11/21/15 07:36, Kinney, Michael D wrote: > Laszlo, > > Minor comments included below. I know from later items in this thread that > SMM_COMMUNICATE has already been removed in your local branch. > > Reviewed-by: Michael Kinney Thank you. I've picked this up

Re: [edk2] [PATCH v4 09/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

On 11/21/15 07:17, Kinney, Michael D wrote: > Laszlo, > > Minor comments included below. > > Reviewed-by: Michael Kinney Thank you. I'll pick up this tag. Answers and further questions below: > > Mike > >> -Original Message- >> From: edk2-devel

Re: [edk2] [PATCH 1/2] ArmVirtPkg/ArmVirtPlatformLib: reduce ID map size to GCD region size

On 11/21/15 10:44, Ard Biesheuvel wrote: > The ID mapping routines on virtual platforms simply map the entire > address space as device memory, and then punch some holes for regions > that need to be mapped cacheable. On virtual platforms hosted on CPUs > that support a large physical address

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

On 11/21/15 07:03, Kinney, Michael D wrote: > Laszlo, > > Minor comments included below. > > Reviewed-by: Michael Kinney Thank you. I'll pick up your R-b, but I'll also respond to your comments below: >> -Original Message- >> From: edk2-devel

[edk2] [PATCH] ArmPkg/BdsLib: Send RemainingDevicePath to PXE Load File protocol

Load File protocol requires remaining device path rather than whole device path. For PXE, it actually requires end node device path only, or else invalid parameter will be returned directly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo Cc:

[edk2] Integrate application into Shell

Hi everyone, I'd like to integrate a few applications into the shell so they are directly available when booting the shell vie PXE. One of the applications I wanted to include in the shell is made using EADK, specifically the socket library. I got it integrated and can run it from the shell,

[edk2] [Patch] [CryptoPkg] Correct one typo in the API comments.

Correct one typo (SingerChainCerts --> SignerChainCerts) in the comments for Pkcs7GetCertificatesList() API. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qin Long CC: Shumin Qiu --- CryptoPkg/Include/Library/BaseCryptLib.h

[edk2] [patch] MdeModulePkg/PiSmmCore: Check InternalAllocPoolByIndex status before refer buffer.

Original code refers FreePoolHdr without check Status. It is obvious wrong and has risk. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zeng, Star Reviewed-by: Yao, Jiewen Cc: Fan, Jeff Cc: Kinney, Michael

[edk2] [patch] MdeModulePkg/PiSmmCore: Uninstall LoadedImage protocol if SMM driver returns error and is unloaded.

Original code does not uninstall LoadedImage protocol if SMM driver returns error and is unloaded. It causes a wrong LoadedImage protocol existing in system. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yao, Jiewen Cc: Zeng, Star

[edk2] [patch] EdkCompatibilityPkg/SmmBaseHelper: Install LoadedImage protocol for ECP SMM driver.

PiSmmCore installs LoadedImage for each SMM driver. However ECP SMM driver is missing. Since SmmBaseHelper loads ECP SMM driver, we let SmmBaseHelper installs LoadedImage protocol for SMM driver. So that the SMM image information is complete. Contributed-under: TianoCore Contribution Agreement

Re: [edk2] [PATCH V3 10/12] OvmfPkg XenConsoleSerialPortLib: Implement Get(Set)Control/SetAttributes

On 11/23/15 02:44, Star Zeng wrote: > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Jordan Justen > Cc: Laszlo Ersek > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Star

Re: [edk2] [PATCH V3 11/12] ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg

Star, On 11/23/15 02:44, Star Zeng wrote: > Beyond just changing the directly related lines in the FDF and DSC files, > we have to adapt the EarlyFdtPL011SerialPortLib and FdtPL011SerialPortLib > instances as well, in the same patch. This is because the EmbeddedPkg > driver expects the

[edk2] [patch] UefiCpuPkg/PiSmmCpu: Eliminate EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64).

Move Gdt initialization from InitializeMpServiceData() to CPU Arch specific function. We create SmmFuncsArch.c for hold CPU specific function, so that EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64) can be removed. For IA32 version, we always allocate new page for GDT entry, for easy

[edk2] [patch] UefiCpuPkg/PiSmmCpu: Move RestoreSmmConfigurationInS3 from BSPHandler() to PerformRemainingTasks().

In this way, we can centralize the silicon configuration in PerformRemainingTasks() function. If there are more features need to be configured, they can put in PerformRemainingTasks() only. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yao, Jiewen

[edk2] [patch] UefiCpuPkg/PiSmmCpu: Remove TSS fixup in GDT.

The TSS is already fixed in PiSmmCpuDxeSmm/X64/SmmFuncsArch.c, InitGdt(). There is no need to fix it again. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yao, Jiewen Cc: Fan, Jeff Cc: Kinney, Michael D

Re: [edk2] Dynamic PCD Variable Storage in PEI Phase

Hi Andrew, I looked at the ArmVirtPkg and did the same before I sent the previous email. I am missing some step that is causing the null package to be picked up. Here are my changes, I think I covered most but still missing something. Thanks for your help,

Re: [edk2] Armv8 64bit: System error booting linux from the UEFI

> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Wednesday, November 18, 2015 11:32 PM > To: Vladimir Olovyannikov > Cc: Mark Rutland; edk2-devel@lists.01.org > Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI > > On 19

[edk2] [PATCH 0/2] Add NULL check to pointer returned from 'AllocateZeroPool'.

Qiu Shumin (2): PerformancePkg\Dp_App: Add NULL check to pointer returned from 'AllocateZeroPool'. ShellPkg: Add NULL check to pointer returned from 'AllocateZeroPool'. PerformancePkg/Dp_App/Dp.c | 3 ++- ShellPkg/Library/UefiDpLib/Dp.c | 3 ++- 2 files changed, 4 insertions(+), 2

[edk2] [PATCH 1/2] PerformancePkg\Dp_App: Add NULL check to pointer returned from 'AllocateZeroPool'.

When CustomCumulativeToken is not NULL, the CustomCumulativeData is expected non-NULL. Add 'ASSERT' statement to ensure this. Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qiu Shumin ---

[edk2] [PATCH 2/2] ShellPkg: Add NULL check to pointer returned from 'AllocateZeroPool'.

When CustomCumulativeToken is not NULL, the CustomCumulativeData is expected non-NULL. Add 'ASSERT' statement to ensure this. Cc: Jaben Carsey Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qiu Shumin ---

[edk2] [PATCH 1/2] UefiCpuPkg - Expand description of AcpuCpuData.h structures

Provide a more detailed description of each field of the ACPI_CPU_DATA and CPU_REGISTER_TABLE structures. Cc: Laszlo Ersek Cc: "Yao, Jiewen" Cc: "Fan, Jeff" Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by:

[edk2] [PATCH 2/2] UefiCpuPkg:CpuS3DataDxe - Add module to initialize ACPI_CPU_DATA for S3

This module initializes the ACPI_CPU_DATA structure and registers the address of this structure in the PcdCpuS3DataAddress PCD. This is simplest version of this module. It does not provide a machine check handler or CPU register initialization tables for ACPI S3 resume. This module can be copied

[edk2] [PATCH 0/2] UefiCpuPkg: Add CpuS3Data module

This patch series adds a generic/simple module that allocates, initializes, and registers the ACPI_CPU_DATA structure required to support ACPI S3 resume. This patch series is in response to the OvmfPkg patch series from Laszlo Ersek that enables SMM on OVMF. The v4 version of that patch

[edk2] [Patch] BaseTools: Add build error detection for Dynamic PCD name conflict

when multiple Dynamic PCD have different token space guid but same PCD name, it is difficult for user to check why the generated autogen.c and autogen.h are not consistent. so we add a check before generating autogen.c and report error directly that user can know what happened immediately.

Re: [edk2] [PATCH v4 09/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

Laszlo, I other modules where we want to halt no matter what, the following 2 statements are used together. ASSERT() could be removed by PCD settings, so dead loop catches that case. If ASSERT() is enabled, then the ASSERT() behavior of BP or dead loop is controlled by PCD. ASSERT

Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Correct TSS segment.

Reviewed-by: Michael Kinney > -Original Message- > From: Yao, Jiewen > Sent: Monday, November 23, 2015 5:13 AM > To: edk2-de...@ml01.01.org > Cc: Yao, Jiewen ; Fan, Jeff ; > Kinney, Michael D

Re: [edk2] Dynamic PCD Variable Storage in PEI Phase

> On Nov 23, 2015, at 2:03 PM, Narinder Dhillon wrote: > > Hi Andrew, > > I looked at the ArmVirtPkg and did the same before I sent the previous > email. I am missing some step that is causing the null package to be > picked up. Here are my changes, I think I covered most

Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi

> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, November 10, 2015 10:04 AM > To: Vladimir Olovyannikov > Cc: Cohen, Eugene; edk2-devel@lists.01.org > Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with > step-by-step

Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Move RestoreSmmConfigurationInS3 from BSPHandler() to PerformRemainingTasks().

Hi Laszlo For 3), I see your point. I think 2) again, and realize there might be a corner case. A) There is SMI handler issue which might call-out SMRAM. B) Malicious software may construct such environment in OS. (But not trigger it, because it will be blocked by code access) C) SMM CPU driver

Re: [edk2] [Patch] [CryptoPkg] Correct one typo in the API comments.

Reviewed-by: Qiu Shumin -Original Message- From: Long, Qin Sent: Monday, November 23, 2015 4:39 PM To: edk2-devel@lists.01.org Cc: Qiu, Shumin Subject: [Patch] [CryptoPkg] Correct one typo in the API comments. Correct one typo (SingerChainCerts -->

Re: [edk2] [PATCH V3 11/12] ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg

More comments below. On 2015/11/24 9:01, Zeng, Star wrote: Laszlo, Explain more below. On 2015/11/23 22:01, Laszlo Ersek wrote: Star, On 11/23/15 02:44, Star Zeng wrote: Beyond just changing the directly related lines in the FDF and DSC files, we have to adapt the

[edk2] DXE Driver INF Dependency

I'm trying to make one DXE driver dependent upon another. From the INF spec, it appears that I can put "AFTER path/to/dependency.inf" in my driver's Depex section. If I try this I get the error below. (Python 2.7.3 on win32) Traceback (most recent call last): File "build.py", line 2032, in

Re: [edk2] DXE Driver INF Dependency

David, When using BEFORE and AFTER, you have to provide a GUID C name for the FFS file GUID of the driver you want to run before or after The supported syntax is BEFORE AFTER This means you have to declare a GUD in a DEC file that is mapped to the same GUID value of the

Re: [edk2] [patch] MdeModulePkg/PiSmmCore: Uninstall LoadedImage protocol if SMM driver returns error and is unloaded.

On 2015/11/23 21:29, jiewen yao wrote: Original code does not uninstall LoadedImage protocol if SMM driver returns error and is unloaded. It causes a wrong LoadedImage protocol existing in system. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yao, Jiewen

Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Remove TSS fixup in GDT.

Jiewen, Could you combine this patch with [patch] UefiCpuPkg/PiSmmCpu: Eliminate EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64)? Reviewed-by: Jeff Fan Jeff -Original Message- From: Yao, Jiewen Sent: Monday, November 23, 2015 10:15 PM To:

Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Eliminate EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64).

Agree. Thanks! -Original Message- From: Fan, Jeff Sent: Tuesday, November 24, 2015 11:33 AM To: Yao, Jiewen; edk2-de...@ml01.01.org Cc: Kinney, Michael D Subject: RE: [patch] UefiCpuPkg/PiSmmCpu: Eliminate EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64). This commit title is

Re: [edk2] [patch] EdkCompatibilityPkg/SmmBaseHelper: Install LoadedImage protocol for ECP SMM driver.

Sorry, please ignore this patch. I just realized that mLoadPe32Image->LoadPeImage() can install LoadedImage protocol. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of jiewen yao Sent: Monday, November 23, 2015 9:41 PM To: edk2-de...@ml01.01.org

Re: [edk2] [patch] MdeModulePkg/PiSmmCore: Uninstall LoadedImage protocol if SMM driver returns error and is unloaded.

Reviewed-by: Michael Kinney > -Original Message- > From: Yao, Jiewen > Sent: Monday, November 23, 2015 5:29 AM > To: edk2-de...@ml01.01.org > Cc: Yao, Jiewen ; Zeng, Star ; > Fan, Jeff ; Kinney,

Re: [edk2] [patch] MdeModulePkg/PiSmmIpl: Install LoadedImage protocol for PiSmmCore.

HI I just discussed with Star. We decide to let PiSmmCore install LoadedImage protocol - same way as DxeCore. If so, we can assign correct FilePath there. Then we do not need update PiSmmIpl. I will send another patch. This update can be discard. -Original Message- From: Yao, Jiewen

Re: [edk2] [patch] MdeModulePkg/PiSmmIpl: Install LoadedImage protocol for PiSmmCore.

Jiewen, I agree making the behavior the same as DXE Core makes more sense. Thanks, Mike > -Original Message- > From: Yao, Jiewen > Sent: Monday, November 23, 2015 11:22 PM > To: edk2-de...@ml01.01.org > Cc: Zeng, Star ; Fan, Jeff ; Kinney, >

Re: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if x2APIC supported

Mike, OK. So, if 0xB leaf is not supported, then ASSERT() in GetX2ApicIdFromCpuId(); // // Get the maximum index of basic CPUID // AsmCpuid (CPUID_SIGNATURE, , NULL, NULL, NULL); ASSERT (MaxCpuIdIndex >= CPUID_EXTENDED_TOPOLOGY); Jeff -Original Message- From: Kinney,

Re: [edk2] [PATCH v2 0/2] ArmVirtPkg: limit IPA space to prevent page table memory waste

On 23 November 2015 at 21:55, Wei Huang wrote: > > > On 11/23/2015 11:10 AM, Ard Biesheuvel wrote: >> Hello all, >> >> After Drew pointed out that mach-virt now populates the memory region beyond >> DRAM, I am proposing this approach instead. Since KVM limits its IPA space to >>

Re: [edk2] [Patch 1/3] UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if x2APIC supported

Jeff, Yes. That is ASSERT() location I was suggesting. Does is also makes sense to fall back to GetInitialApicId() if CPUID leaf is not supported? Or is this really a condition that should never occur? Mike > -Original Message- > From: Fan, Jeff > Sent: Monday, November 23, 2015

[edk2] CryptoPkg: OpenSSL build issue with RVCT

Using RVCT 4, I get the following error building openssl-1.0.2d: 1> Building ... c:\bios_24s\edk2\CryptoPkg\Library\OpensslLib\OpensslLib.inf [ARM] [snip] c:\bios_24s\edk2\CryptoPkg\Library\OpensslLib\openssl-1.0.2d\crypto\cryptlib.c

[edk2] [PATCH 1/6] BaseTools/GenFw ARM: allow R_ARM_REL32 relocations

R_ARM_REL32 are relative relocations, so we don't need to do anything special when performing the ELF to PE/COFF conversion, since our memory layout is identical between the two binary formats. So just allow them. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard

[edk2] [PATCH 0/6] ArmVirtPkg: add ARM support to ArmVirtXen

By special request, this implements ARM support to the ArmVirtXen platform. This is probably still rough around the edges, since I have not tested it myself under Xen yet. I did test all the code changes in this series under QEMU. (This is possible since the early code only depends on the Linux

[edk2] [PATCH 2/6] ArmLib/ArmV7Mmu: use 64-bit type for mapping region size

The way the v7 MMU code is invoked by the Xen port is somewhat of a pathological case, since it describes its physical memory space using a single cacheable region that covers the entire addressable range. When clipping this region to the part that is 1:1 addressable, we end up with a region of

[edk2] [PATCH 3/6] ArmVirtPkg/XenRelocatablePlatformLib: rewrite DTB memory node retrieval in C

Parsing the DTB early on using a handcoded assembly routine is a pointless waste of brain cycles, since the UEFI firmware always executes from RAM under Xen. So instead, set up a temporary stack in the memory region at the beginning of the image, and use the libfdt C library. Contributed-under:

[edk2] [PATCH 6/6] ArmVirtPkg/ArmVirtXen: add ARM support

This adds ARM support to the ArmVirtXen platform. As is the case for AARCH64, the ARM port adheres to the ARM Linux boot protocol, i.e., it expects the address of a DTB describing the platform to be passed in r2, and relocates itself at runtime to the actual load time memory offset.

[edk2] [PATCH 5/6] ArmVirtPkg/ArmXenRelocatablePlatformLib: add ARM support

This is a port of the AARCH64 low level init routines to ARM. This mainly covers the platform boot code that extracts the system base and size from the DTB, copies it and updates the FD and FV base addresses according to the load time offset. Contributed-under: TianoCore Contribution Agreement

[edk2] [PATCH 4/6] ArmVirtPkg/PrePiRelocatable: add ARM support

This adds support to the self relocating PrePi instance that is built as a PIE ET_DYN executable. It primarily involves porting the relocation routine to use ELF32 REL entries instead of ELF64 RELA entries which is what AArch64 uses. Contributed-under: TianoCore Contribution Agreement 1.0

Re: [edk2] [PATCH 0/6] ArmVirtPkg: add ARM support to ArmVirtXen

On 11/23/15 17:56, Ard Biesheuvel wrote: > By special request, this implements ARM support to the ArmVirtXen > platform. This is probably still rough around the edges, since I have > not tested it myself under Xen yet. I did test all the code changes in > this series under QEMU. (This is possible

[edk2] [PATCH v2 1/2] ArmVirtPkg/ArmVirtQemu: limit the (I)PA space to 40 bits

KVM uses a fixed size of 40 bits for its intermediate physical address space, so there is no need to support anything beyond that even if the host hardware does. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Laszlo

[edk2] [PATCH v2 0/2] ArmVirtPkg: limit IPA space to prevent page table memory waste

Hello all, After Drew pointed out that mach-virt now populates the memory region beyond DRAM, I am proposing this approach instead. Since KVM limits its IPA space to 40 bits, there is simply no point in supporting anything beyond that for ArmVirtQemu. I am cc'ing the Xen guys since they may run

Re: [edk2] [PATCH v2 2/2] ArmVirtPkg/ArmVirtPlatformLib: reduce ID map size to GCD region size

On 11/23/15 18:10, Ard Biesheuvel wrote: > The ID mapping routines on virtual platforms simply map the entire > address space as device memory, and then punch some holes for regions > that need to be mapped cacheable. On virtual platforms hosted on CPUs > that support a large physical address

Re: [edk2] CryptoPkg: OpenSSL build issue with RVCT

Hi, Eugene, Sorry, I have no RVCT environment for more investigations. Could you help to double-check if this is caused by any CryptoPkg updates? Or It is one OpenSSL-native issue? Could we silence this simply with any build flag, such as " --diag_suppress"? Moreover, some old RVCT release

Re: [edk2] [PATCH] ShellBinPkg: Arm/AArch64 Shell binary update.

Not sure how to RB this ... it's fine with me to commit it. > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, November 23, 2015 5:22 AM > To: Leif Lindholm > Cc: edk2-devel@lists.01.org; Carsey, Jaben

Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Move RestoreSmmConfigurationInS3 from BSPHandler() to PerformRemainingTasks().

Comments below: -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Monday, November 23, 2015 10:39 PM To: Yao, Jiewen; edk2-de...@ml01.01.org Cc: Kinney, Michael D; Fan, Jeff Subject: Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Move RestoreSmmConfigurationInS3 from

Re: [edk2] [PATCH 0/6] ArmVirtPkg: add ARM support to ArmVirtXen

On 23 November 2015 at 17:56, Ard Biesheuvel wrote: > By special request, this implements ARM support to the ArmVirtXen > platform. This is probably still rough around the edges, since I have > not tested it myself under Xen yet. I did test all the code changes in >

Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

Laszlo, Based on size analysis of compiler output, (3) is not the smallest size. That is why we prefer pre-init global. Using your current patch style (1) in OvmfPkg specific modules is ok until you can find a solution to your ctags issue. Mike > -Original Message- > From:

Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

On 11/23/15 22:01, Kinney, Michael D wrote: > Laszlo, > > Based on size analysis of compiler output, (3) is not the smallest size. > That is why we prefer pre-init global. Ugh, I completely forgot about physical flash, where size is a premium... > > Using your current patch style (1) in

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

On 11/23/15 21:28, Kinney, Michael D wrote: > Laszlo, > > There are 2 reasons to list all source files used in a module build in the > [Sources] section. > > 1) Support incremental builds. If a change to the .h file is made, > then the module may not be rebuilt if the .h file is not listed in

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

Laszlo, The section [UserExtensions.TianoCore."ExtraFiles"] can be used to list files not required to build and support incremental builds, but need to be included in a UDP package. Mike > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Monday, November 23,