Re: [edk2] [patch 2/2] BaseTools/UPT: Add a checkpoint for missing '"'

Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Chen, Hesheng Sent: Tuesday, March 07, 2017 2:02 PM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong Subject: [patch 2/2] BaseTools/UPT: Add a checkpoint for missing '"' Add a checkpoint for UNI file which is

Re: [edk2] [patch 1/2] BaseTools/ECC: Fix an issue of parameter parser

Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Chen, Hesheng Sent: Tuesday, March 07, 2017 2:02 PM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong Subject: [patch 1/2] BaseTools/ECC: Fix an issue of parameter parser The original solution of getting parame

Re: [edk2] [patch] BaseTools/UPT: Fix an issue of adding Event twice

Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Chen, Hesheng Sent: Tuesday, March 07, 2017 4:01 PM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong Subject: [patch] BaseTools/UPT: Fix an issue of adding Event twice Fix the issue of after installing a packa

Re: [edk2] [patch] BaseTools/UPT: Man Page Update

Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Chen, Hesheng Sent: Tuesday, March 07, 2017 2:15 PM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong Subject: [patch] BaseTools/UPT: Man Page Update Update UPT man page to complete the description of options.

Re: [edk2] SIMD Instruction supported in UEFI?

>From UEFI shell From: Ken Taylor Sent: Thursday, March 9, 2017 4:51 AM To: Amit kumar; edk2-devel@lists.01.org Subject: RE: [edk2] SIMD Instruction supported in UEFI?   Hi Amit, Maybe in UEFI the code in question crosses a cache line boundary when executed in UEFI, with the loop or par

[edk2] bad usb descriptor may cause usb dead loop

Hi Experts, Now I meet a bad usb disk which may cause bios post hang. After tracing, I find it is dead loop in a while() condition. This usb disk's decriptor is as below, we could find that it reports it has 3 endpoints, but it only report one of them. And when usb core function sets c

[edk2] Do edk2 support PcdGetEx64 in library

Hi , Anyone knows whether edk2 support PcdGetEx64 in library? First I declare a PcdsDynamicEx in dec file [PcdsDynamicEx] gEfixxxTokenSpaceGuid.PcdPasswordToken|0|UINT64|0x1009 Then I tried to use PcdGetEx64 in a library construct function OldToken = PcdGetEx64((CONST GUID *)

[edk2] [PATCH] SignedCapsulePkg: Add Readme.md

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao --- SignedCapsulePkg/Readme.md | 11 +++ 1 file changed, 11 insertions(+) diff --git a/SignedCapsulePkg/Readme.md b/SignedCapsulePkg/Readme.md new file mode 100644 index 000..67c78ed --- /dev/null +++ b

[edk2] [PATCH] IntelFsp2WrapperPkg: Add Readme.md

Cc: Maurice Ma Cc: Richard Thomaiyar Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao --- IntelFsp2WrapperPkg/Readme.md | 7 +++ 1 file changed, 7 insertions(+) diff --git a/IntelFsp2WrapperPkg/Readme.md b/IntelFsp2WrapperPkg/Readme.md new file mode 100644

[edk2] [PATCH] IntelFsp2Pkg: Add Readme.md

Cc: Maurice Ma Cc: Richard Thomaiyar Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao --- IntelFsp2Pkg/Readme.md | 7 +++ 1 file changed, 7 insertions(+) diff --git a/IntelFsp2Pkg/Readme.md b/IntelFsp2Pkg/Readme.md new file mode 100644 index 000..6e38e8

[edk2] [PATCH] Add SignedCapsule content.

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao --- Maintainers.txt | 4 1 file changed, 4 insertions(+) diff --git a/Maintainers.txt b/Maintainers.txt index 94d3380..77df275 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -213,6 +213,10 @@ W: https:

Re: [edk2] [PATCH v2 0/2] MdeModulePkg/AcpiTableDxe: improve FADT.{DSDT, X_DSDT} mutual exclusion

Reviewed-by: Star Zeng -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Thursday, March 9, 2017 3:59 AM To: edk2-devel-01 Cc: Al Stone ; Ard Biesheuvel ; Tian, Feng ; Igor Mammedov ; Yao, Jiewen ; Leo Duran ; Michael Tsirkin ; Phil Dennis-Jordan ; Zeng, Star S

Re: [edk2] [RFC PATCH v1 4/5] OvmfPkg/BaseIoLibIntrinsic: import BaseIoLibIntrinsic package

> -Original Message- > From: Justen, Jordan L > Sent: Thursday, March 9, 2017 2:59 AM > To: Gao, Liming ; Kinney, Michael D > ; edk2-devel@lists.01.org; Brijesh Singh > ; Laszlo Ersek > Cc: thomas.lenda...@amd.com; leo.du...@amd.com; brijesh.s...@amd.com > Subject: RE: [RFC PATCH v1 4/5

Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3] Fix Graphic issue

Thanks David, already fixed this issue. -Original Message- From: Wei, David Sent: Wednesday, March 8, 2017 11:27 AM To: Guo, Mang; edk2-devel@lists.01.org Cc: Lu, ShifeiX A; Wei, David Subject: RE: [Patch][edk2-platforms/devel-MinnowBoard3] Fix Graphic issue Hi Mang, Could you double

Re: [edk2] [RFC PATCH v1 4/5] OvmfPkg/BaseIoLibIntrinsic: import BaseIoLibIntrinsic package

From: Brijesh Singh [mailto:brijesh.ksi...@gmail.com] Sent: Thursday, March 9, 2017 12:27 AM To: Gao, Liming Cc: Justen, Jordan L ; Laszlo Ersek ; edk2-devel@lists.01.org; Kinney, Michael D ; thomas.lenda...@amd.com; leo.du...@amd.com; brijesh.si...@amd.com Subject: Re: [RFC PATCH v1 4/5] Ovm

Re: [edk2] [PATCH v2 2/2] MdeModulePkg/AcpiTableDxe: improve FADT.{DSDT, X_DSDT} mutual exclusion

Reviewed-by: jiewen@intel.com > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, March 9, 2017 3:59 AM > To: edk2-devel-01 > Cc: Al Stone ; Ard Biesheuvel ; > Tian, Feng ; Igor Mammedov ; > Yao, Jiewen ; Leo Duran ; > Michael Tsirkin ; Phil Dennis-J

Re: [edk2] [PATCH v2 1/2] MdeModulePkg/AcpiTableDxe: condense whitespace around FADT.{DSDT, X_DSDT}

Reviewed-by: jiewen@intel.com > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Thursday, March 9, 2017 3:59 AM > To: edk2-devel-01 > Cc: Tian, Feng ; Michael Tsirkin ; > Ard Biesheuvel ; Phil Dennis-Jordan > ; Leo Dur

Re: [edk2] SIMD Instruction supported in UEFI?

Hi Amit, Maybe in UEFI the code in question crosses a cache line boundary when executed in UEFI, with the loop or part of the instruction itself on one side of the boundary and the rest on the other? At what point are you trying to execute this code, is it still from the UEFI shell or have you

[edk2] [PATCH v2 1/2] MdeModulePkg/AcpiTableDxe: condense whitespace around FADT.{DSDT, X_DSDT}

This patch incurs no functional changes, it just removes some whitespace, and also makes sure we always assign AcpiTableInstance->Fadt3->Dsdt first, and AcpiTableInstance->Fadt3->XDsdt second. The goal is to separate the syntactic changes from the functional changes implemented by the next

[edk2] [PATCH v2 2/2] MdeModulePkg/AcpiTableDxe: improve FADT.{DSDT, X_DSDT} mutual exclusion

The ACPI specification, up to and including revision 5.1 Errata A, allows the DSDT and X_DSDT fields to be both set in the FADT. (Obviously, this only makes sense if the DSDT address is representable in 4 bytes.) Starting with 5.1 Errata B, specifically for Mantis 1393

[edk2] [PATCH v2 0/2] MdeModulePkg/AcpiTableDxe: improve FADT.{DSDT, X_DSDT} mutual exclusion

This is version 2 of the series originally posted at and further discussed at . This version contains minor updates (noted on each patch) that don't affect functi

Re: [edk2] [PATCH 4/6] ArmVirtPkg/QemuFwCfgLib: add explicitly initialized instance

On 03/08/17 20:05, Laszlo Ersek wrote: > The QemuFwCfgLibExplicitInit instance differs from the normally used one > in that the client module has to call the QemuFwCfgInitialize() function > explicitly -- there is no library constructor --, and the client shall > also ensure that the dependency on

[edk2] [PATCH 1/6] ArmVirtPkg/FdtClientDxe: supplement missing EFIAPI calling conv specifiers

Cc: Ard Biesheuvel Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c index 7cc0c44c

[edk2] [PATCH 4/6] ArmVirtPkg/QemuFwCfgLib: add explicitly initialized instance

The QemuFwCfgLibExplicitInit instance differs from the normally used one in that the client module has to call the QemuFwCfgInitialize() function explicitly -- there is no library constructor --, and the client shall also ensure that the dependency on FDT_CLIENT_PROTOCOL is satisfied -- there is no

[edk2] [PATCH 5/6] ArmVirtPkg/FdtClientDxe: don't forward DT to OS if QEMU provides ACPI

ArmVirtQemu can be built with -D PURE_ACPI_BOOT_ENABLE at the moment. We should replace that build-time setting with a dynamic one: forward the DT from QEMU to the guest kernel if and only if - the guest architecture is arm32, or - we run on Xen, or - ACPI payload is not available from QEMU. This

[edk2] [PATCH 6/6] ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot

The build flag and the FeaturePCD have no effect any longer, remove them. Cc: Ard Biesheuvel Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- ArmVirtPkg/ArmVirtPkg.dec | 10 -- ArmVirtPkg/ArmVirtQemu.dsc | 5 - 2 files changed, 15 deletions(-

[edk2] [PATCH 3/6] ArmVirtPkg/ArmVirtPL031FdtClientLib: get rid of PcdPureAcpiBoot dependency

Replace the FeaturePCD dependency with a call to the new FdtClientProtocol member GetOsExposure(). ArmVirtPL031FdtClientLib depends on the protocol with a DEPEX, hence the call will always succeed. Cc: Ard Biesheuvel Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Er

[edk2] [PATCH 0/6] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI

This series replaces the PURE_ACPI_BOOT_ENABLE build option with dynamic behavior, matching QEMU's (inverse sense) "-no-acpi" switch. In particular, DT and ACPI are no longer exposed to the guest at the same time. (DT is exposed with "-no-acpi", or else ACPI is exposed without "-no-acpi".) Repo:

[edk2] [PATCH 2/6] ArmVirtPkg: introduce FDT_CLIENT_PROTOCOL.GetOsExposure() member function

Introduce a protocol member function that allows consumers of the protocol to determine whether the FDT is exposed to the guest OS. The initial implementation simply reflects !PcdPureAcpiBoot. Cc: Ard Biesheuvel Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek

Re: [edk2] [RFC PATCH v1 4/5] OvmfPkg/BaseIoLibIntrinsic: import BaseIoLibIntrinsic package

On 2017-03-08 07:41:58, Gao, Liming wrote: > > >-Original Message- > >From: Justen, Jordan L > > >One other thought is, should we consider a DxeSmm alternative .inf for > >BaseIoLibIntrinsic.inf? In that case we could use a global variable to > >help out. Maybe this could prevent the conc

Re: [edk2] [RFC PATCH v1 1/5] OvmfPkg/ResetVector: Set memory encryption when SEV is active

On Wed, Mar 8, 2017 at 12:38 PM, Jordan Justen wrote: > On 2017-03-06 15:27:35, Brijesh Singh wrote: > > SEV guest VMs have the concept of private and shared memory. Private > > memory is encrypted with the guest-specific key, while shared memory > > may be encrypted with hypervisor key. The C-bi

Re: [edk2] [RFC PATCH v1 1/5] OvmfPkg/ResetVector: Set memory encryption when SEV is active

On 2017-03-06 15:27:35, Brijesh Singh wrote: > SEV guest VMs have the concept of private and shared memory. Private > memory is encrypted with the guest-specific key, while shared memory > may be encrypted with hypervisor key. The C-bit (encryption attribute) > in PTE indicates whether the page is

[edk2] LNK2001 error: unable to find _BdsDxeStrings

Hello- We are using EDK2 (version 2.40). In addition to the BdsDxe library defined by BdsDxe.inf, I've been attempting to create a near - identical copy of this library file called BdsDxe_Recovery.inf. I've given this unique copy a new GUID and it matches otherwise identically to BdsDxe in te

Re: [edk2] [RFC PATCH v1 4/5] OvmfPkg/BaseIoLibIntrinsic: import BaseIoLibIntrinsic package

On Wed, Mar 8, 2017 at 9:41 AM, Gao, Liming wrote: > > > >-Original Message- > >From: Justen, Jordan L > >Sent: Wednesday, March 08, 2017 4:06 AM > >To: Gao, Liming ; Brijesh Singh > >; Laszlo Ersek ; edk2- > >de...@lists.01.org; Kinney, Michael D > >Cc: thomas.lenda...@amd.com; leo.du..

Re: [edk2] [PATCH v4 0/6] DxeBmDmaLib (BmDmaLib class) library

Hi Ray, Please see my replies below. BTW, we plan on having the SEV BmDmaLib patches done in the next 2 weeks, so please stay tuned for that. Thanks, Leo From: Ni, Ruiyu [mailto:ruiyu...@intel.com] Sent: Tuesday, March 07, 2017 7:02 PM To: Yao, Jiewen ; Duran, Leo ; edk2-de...@ml01.01.org Subj

Re: [edk2] [RFC PATCH v1 4/5] OvmfPkg/BaseIoLibIntrinsic: import BaseIoLibIntrinsic package

>-Original Message- >From: Justen, Jordan L >Sent: Wednesday, March 08, 2017 4:06 AM >To: Gao, Liming ; Brijesh Singh >; Laszlo Ersek ; edk2- >de...@lists.01.org; Kinney, Michael D >Cc: thomas.lenda...@amd.com; leo.du...@amd.com; >brijesh.s...@amd.com >Subject: Re: [RFC PATCH v1 4/5] Ovm

Re: [edk2] [RFC PATCH v1 2/5] OvmfPkg/MemcryptSevLib: Add SEV helper library

For libraries, I've noticed this usage pattern: INF File: - Name: .inf - Path: xxxPkg/Library//.inf INCLUDE File: - Name: .h - Path: xxxPkg/Include/Library/.h Leo > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Tuesday, March 07, 2017 4:08 PM > To: Brijesh S

Re: [edk2] [RFC PATCH v1 2/5] OvmfPkg/MemcryptSevLib: Add SEV helper library

On 03/08/17 15:56, Duran, Leo wrote: > For libraries, I've noticed this usage pattern: > > INF File: > - Name: .inf > - Path: xxxPkg/Library//.inf > > INCLUDE File: > - Name: .h > - Path: xxxPkg/Include/Library/.h Correct. What I described earlier was the relationship between and . Namely, is

[edk2] SIMD Instruction supported in UEFI?

Hi ; I have written a UEFI app in ASM which runs XOR on a block of data using SIMD instructions ("PXOR") in UEFI environment. It takes around 2 Seconds to run this code, but when i use normal C XOR operator ("^") it takes 1 Seconds. Is there something wrong ? I mean SIMD instructions must be giv

Re: [edk2] [PATCH 0/2] MdeModulePkg/AcpiTableDxe: improve FADT.{DSDT, X_DSDT} mutual exclusion

Hi Laszlo I agree with you that the strange order issue and spec compliance issue need to be fixed. I am OK on the final result in RequireDsdtXDsdtExclusion(). However, the logic below is a little hard to read for me, because I have to switch my mind between "return FALSE" and "return TRUE". ==

Re: [edk2] [PATCH] ArmPkg/CpuDxe: handle implied attributes in EfiAttributeToArmAttribute

On Wed, Mar 08, 2017 at 12:51:44PM +0100, Ard Biesheuvel wrote: > Some memory attributes are implied by the memory type, e.g., device memory > is always mapped non-executable and cached memory should have the inner > shareable attribute. > > In order to prevent unnecessary memory attribute updates

[edk2] [PATCH] ArmPkg/CpuDxe: handle implied attributes in EfiAttributeToArmAttribute

Some memory attributes are implied by the memory type, e.g., device memory is always mapped non-executable and cached memory should have the inner shareable attribute. In order to prevent unnecessary memory attribute updates of mappings created early on, make EfiAttributeToArmAttribute() return th

Re: [edk2] [PATCH] ArmVirtPkg: apply PE/COFF memory protection to DxeCore as well

On 7 March 2017 at 14:56, Laszlo Ersek wrote: > On 03/07/17 12:24, Ard Biesheuvel wrote: >> Include DXE_CORE in the BuildOptions that are set to force 4 KB section >> alignment for PE/COFF images in order to allow them to be mapped with >> strict memory permissions. >> >> Contributed-under: TianoC

Re: [edk2] [RFC PATCH v1 2/5] OvmfPkg/MemcryptSevLib: Add SEV helper library

On 03/07/17 23:36, Brijesh Singh wrote: > > > On Tue, Mar 7, 2017 at 4:08 PM, Laszlo Ersek > wrote: > > On 03/07/17 20:14, Brijesh Singh wrote: > > On Tue, Mar 7, 2017 at 11:06 AM, Laszlo Ersek > wrote: > I think SevActive() a