Re: [edk2] [patch] SecurityPkg: enhance secure boot Config Dxe & Time Based AuthVariable.

Hi, Lubo, Please use "mSha256OidValue", instead of "mHash256OidValue", to identify the SHA-256 cipher name. Reviewed-by: Long Qin Best Regards & Thanks, LONG, Qin > -Original Message- > From: Zhang, Lubo > Sent: Thursday, February 16, 2017 11:05 PM > To:

[edk2] [patch] SecurityPkg: enhance secure boot Config Dxe & Time Based AuthVariable.

V3: code clean up prohibit Image SHA-1 hash option in SecureBootConfigDxe. Timebased Auth Variable driver should ensure AuthAlgorithm is SHA256 before further verification Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zhang Lubo Cc: Chao Zhang

[edk2] [PATCH v2] NetworkPkg:Add scriptable configuration to iSCSI driver by

v2: Add error handling if can not create Attempts in driver entry point. Since we support to define a macro be a PCD value, we enhance our code by modifying the structure in IFR_NVDATA. This effect code logic mainly in Creating Keywords,Convert IFR NvData To AttemptConfigData ByKeyword and reverse

Re: [edk2] CapsuleApp behavior for CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule

Hi JIewen, I am OOO today, I will create a bugzillar next monday. At 2017-02-17 09:23:08, "Yao, Jiewen" wrote: >Would you please help to file a bugzillar for tracking purpose? > >Thank you >Yao Jiewen > >From: wang xiaofeng [mailto:winggundu...@163.com] >Sent:

Re: [edk2] CapsuleApp behavior for CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule

Would you please help to file a bugzillar for tracking purpose? Thank you Yao Jiewen From: wang xiaofeng [mailto:winggundu...@163.com] Sent: Sunday, February 12, 2017 8:46 PM To: Yao, Jiewen Cc: edk2-devel@lists.01.org Subject: Re:Re: [edk2] CapsuleApp behavior for

Re: [edk2] [patch] MdeMoudlePkg/DisplayEngine: Fix incorrect index used in array "InputText"

Hi Xiaofeng, Do you have any comments on this patch? This patch is to fix the bug you reported (https://bugzilla.tianocore.org/show_bug.cgi?id=358). Could you help to verify on your platform? Thank you very much! Regards, Dandan -Original Message- From: edk2-devel

Re: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg

On 2/16/2017 3:59 PM, Shah, Tapan wrote: UEFI Spec does not have old FMP image descriptor structures V1 and V2 defined. MdePkg only follows the spec, so it contains the latest version # 3. But there are still drivers using old V1, V2 revisions and Shell 'dh' command needs to support decoding

Re: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg

Yes, I agree that SHELL pkg should dump V1 only and V2 only data structure. I just think there is no need to add new data structure there. The shell pkg can just skip LowestSupportedImageVersion in V1 and skip LastAttemptVersion/ LastAttemptStatus/ HardwareInstance in V2. Thank you Yao Jiewen

Re: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg

UEFI Spec does not have old FMP image descriptor structures V1 and V2 defined. MdePkg only follows the spec, so it contains the latest version # 3. But there are still drivers using old V1, V2 revisions and Shell 'dh' command needs to support decoding all revisions and needs to remain in

Re: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg

I agree. It does not make sense to define it ShellPkg. Another option is just to do cleanup and remove them at all. This is an internal data structure. Thank you Yao Jiewen > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Rebecca Cran >

[edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg

I'm a bit confused about why Firmware Management Protocol image descriptor structures are split between MdePkg and ShellPkg: In MdePkg/Include/Protocol/FirmwareInformation.h there's the definition of EFI_FIRMWARE_IMAGE_DESCRIPTOR (version 3). But then the EFI_FIRMWARE_IMAGE_DESCRIPTOR_V1 and

[edk2] [PATCH 5/5] ArmPkg: Tidy up GenericWatchdogDxe.c

From: Evan Lloyd This cosmetic change has no functional content. It adjusts comment oddities, etc, noticed during previous work. Specific changes are: Re-order #includes Use ns consistently (always "100ns" not sometimes "100 nS") Reflow overlength comments

[edk2] [PATCH 2/5] EmbeddedPkg: Introduce HardwareInterrupt2 protocol

From: Ard Biesheuvel The existing HardwareInterrupt protocol lacks the means to configure the level/edge and polarity properties of an interrupt. So introduce a new protocol HardwareInterrupt2, and add some new members that allow the manipulation of those properties.

[edk2] [PATCH 0/5] HardwareInterrupt2 protocol

From: Evan Lloyd This v2 series of patches corrects a problem detected on the ARM Juno platform that is actually generic (at least to ARM GIC platforms). The HardwareInterrupt protocol had no means of handling characteristics like Edge/Level triggered and polarity. A new

[edk2] [PATCH 1/5] ArmPkg: Tidy GIC code before changes.

From: Evan Lloyd This change is purely cosmetic, to tidy some code before change. Mods involve: Reflow overlength comments. Split overlength code lines. Make protocol functions STATIC. Remove "Horor vacui" comments. Contributed-under: TianoCore Contribution

[edk2] [PATCH 3/5] ArmPkg/ArmGicDxe: Expose HardwareInterrupt2 protocol

From: Ard Biesheuvel The existing HardwareInterrupt protocol lacked a means to configure the level/edge properties of an interrupt. The new HardwareInterrupt2 protocol introduced this capability. This patch updates the GIC drivers to provide the new interfaces. The

[edk2] [PATCH 4/5] ArmPkg/GenericWatchdogDxe: Set Watchdog interrupt type

From: Ard Biesheuvel Utilise the new HardwareInterrupt2 protocol to adjust the Edge/Level characteristics of the Watchdog interrupt. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Signed-off-by: Girish

Re: [edk2] [PATCH v3 0/4] Add PCD PcdPteMemoryEncryptionAddressOrMask

On 02/16/17 22:02, Leo Duran wrote: > This new PCD holds the address mask for page table entries when memory > encryption is enabled on AMD processors supporting the Secure Encrypted > Virtualization (SEV) feature. > > This mask is be applied when creating 1:1 virtual to physical mapping tables.

[edk2] [PATCH v3 4/4] MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory encryption is enabled on AMD processors supporting the Secure Encrypted Virtualization (SEV) feature. This module updates the under-4GB page tables configured by the S3-Resume code in UefiCpuPkg/Universal/Acpi/S3Resume2Pei. The

[edk2] [PATCH v3 3/4] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory encryption is enabled on AMD processors supporting the Secure Encrypted Virtualization (SEV) feature. The mask is applied when page tables are created (S3Resume.c). CC: Jeff Fan Cc: Feng Tian

[edk2] [PATCH v3 0/4] Add PCD PcdPteMemoryEncryptionAddressOrMask

This new PCD holds the address mask for page table entries when memory encryption is enabled on AMD processors supporting the Secure Encrypted Virtualization (SEV) feature. This mask is be applied when creating 1:1 virtual to physical mapping tables. For example, the OvmfPkg sets the PCD when

[edk2] [PATCH v3 2/4] MdeModulePkg/Universal/CapsulePei: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory encryption is enabled on AMD processors supporting the Secure Encrypted Virtualization (SEV) feature. The mask is applied when 4GB tables are created (UefiCapsule.c), and when the tables are expanded on-demand by page-faults above

[edk2] [PATCH v3 1/4] MdeModulePkg: Add PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory encryption is enabled on AMD processors supporting the Secure Encrypted Virtualization (SEV) feature. Cc: Feng Tian Cc: Star Zeng Cc: Laszlo Ersek Contributed-under:

Re: [edk2] [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType functions

On 16 February 2017 at 20:16, Evan Lloyd wrote: > Hi Ard. > Your comments make sense and we will comply (including "Please no spaces > after casts"). > However, I can find nothing requiring no space after casts in the CCS. > It does have some casts in example code: > 5.7.2.3

Re: [edk2] [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType functions

On 16 Feb 2017 20:27, "Evan Lloyd" wrote: > > Hi Leif. > We accept all the comments except that about ternaries. > Response inline. > > >-Original Message- > >From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > >Sent: 13 February 2017 12:16 > >To: Evan Lloyd > >Cc:

[edk2] [PATCH 4/5] OvmfPkg/AcpiPlatformDxe: implement the QEMU_LOADER_WRITE_POINTER command

The QEMU_LOADER_WRITE_POINTER command instructs the firmware to write the address of a field within a previously allocated/downloaded fw_cfg blob into another (writeable) fw_cfg file at a specific offset. Put differently, QEMU_LOADER_WRITE_POINTER propagates, to QEMU, the address that

[edk2] [PATCH 5/5] OvmfPkg/AcpiPlatformDxe: replay QEMU_LOADER_WRITE_POINTER commands at S3

Ultimately, each QEMU_LOADER_WRITE_POINTER command creates a guest memory reference in some QEMU device. When the virtual machine is reset, the device willfully forgets the guest address, since the guest memory is wholly invalidated during platform reset. ... Unless the reset is part of S3

[edk2] [PATCH 0/5] OvmfPkg: support QEMU_LOADER_WRITE_POINTER

This patch series adds support for the new WRITE_POINTER command of QEMU's ACPI linker/loader. The command's first use case is QEMU's implementation of the "Microsoft Hyper-V Generation Counter" device (a.k.a. "VMGENID"). The latest version of the QEMU patch series (v7) can be found at:

[edk2] [PATCH 1/5] OvmfPkg/AcpiPlatformDxe: prepare for QEMU_LOADER_WRITE_POINTER definitions

No functional changes in this patch, just prepare the grounds with some reformatting (trailing comma after the last enumeration constant, horizontal whitespace insertion) so that the next patch can be cleaner. Cc: Jordan Justen Ref:

[edk2] [PATCH 3/5] OvmfPkg/AcpiPlatformDxe: rewrap license block in "QemuFwCfgAcpi.c"

The longest line is currently 84 characters long. Cc: Jordan Justen Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek ---

[edk2] [PATCH 2/5] OvmfPkg/AcpiPlatformDxe: add QEMU_LOADER_WRITE_POINTER definitions

Cc: Jordan Justen Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- OvmfPkg/AcpiPlatformDxe/QemuLoader.h | 26 1 file changed, 26

Re: [edk2] [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType functions

Hi Leif. We accept all the comments except that about ternaries. Response inline. >-Original Message- >From: Leif Lindholm [mailto:leif.lindh...@linaro.org] >Sent: 13 February 2017 12:16 >To: Evan Lloyd >Cc: edk2-de...@ml01.01.org; ard.biesheu...@linaro.org; >ryan.har...@linaro.org

Re: [edk2] [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType functions

Hi Ard. Your comments make sense and we will comply (including "Please no spaces after casts"). However, I can find nothing requiring no space after casts in the CCS. It does have some casts in example code: 5.7.2.3 has "if ((INTN)foo >= 0)" with no space 5.7.2.4 has "if ((

Re: [edk2] DEBUG() macros in DXE driver: can’t make it work in QEMU

On 02/16/17 19:05, Andrew Fish wrote: > >> On Feb 15, 2017, at 4:39 AM, Laszlo Ersek > > wrote: >> >> On 02/15/17 01:00, David A. Van Arnem wrote: >>> >>> >>> On 02/14/2017 04:46 PM, Nikolay Bodunov wrote: Hi I red this topic before

Re: [edk2] DEBUG() macros in DXE driver: can’t make it work in QEMU

> On Feb 15, 2017, at 4:39 AM, Laszlo Ersek wrote: > > On 02/15/17 01:00, David A. Van Arnem wrote: >> >> >> On 02/14/2017 04:46 PM, Nikolay Bodunov wrote: >>> Hi >>> >>> I red this topic before asking the question in the maillist. Unfortunately, >>> it's not for DXE

Re: [edk2] [PATCH] Make [-D Macros] as optional argument for GenCfgOpt

Reviewed-by: Maurice Ma -Maurice -Original Message- From: Thomaiyar, Richard Marian Sent: Monday, February 13, 2017 2:53 AM To: edk2-devel@lists.01.org Cc: Ma, Maurice ; Yao, Jiewen ; Thomaiyar, Richard Marian

Re: [edk2] [Patch] NetworkPkg/HttpBootDxe: Declare the functions as EFIAPI to pass the GCC build

Commit: https://github.com/tianocore/edk2/commit/6c6452c6e23a89be0e565501500e83c136e3fcbd Thanks, Jiaxin > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, February 16, 2017 5:58 PM > To: Wu, Jiaxin ; edk2-de...@ml01.01.org > Cc:

Re: [edk2] [PATCH 2/2] ArmPlatformPkg/PL061Gpio: fix the offset value in Get function

On 13 February 2017 at 07:53, Haojian Zhuang wrote: > When call PL061GetPins() or PL061SetPins(), should use GPIO_PIN_MASK(offset) > as parameter, not offset. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Haojian Zhuang

Re: [edk2] [PATCH 1/2] ArmPlatformPkg/PL061: remove duplicated PL061_GPIO_DATA_REG

On 13 February 2017 at 07:52, Haojian Zhuang wrote: > PL061_GPIO_DATA_REG offset is referenced in PL061EffectiveAddress () > already. So remove the duplicated reference when invoke PL061GetPins () > or PL061SetPins (). > > Contributed-under: TianoCore Contribution

Re: [edk2] [Patch] NetworkPkg/HttpBootDxe: Declare the functions as EFIAPI to pass the GCC build

On 02/16/17 02:19, Jiaxin Wu wrote: > Cc: Laszlo Ersek > Cc: Gerd Hoffmann > Cc: Ye Ting > Cc: Fu Siyuan > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Wu Jiaxin >

Re: [edk2] [PATCH] SecurityPkg: Remove superfluous return statement

On 25.01.2017 10:58, Thomas Huth wrote: > If the code eventually returns "Status" anyway, it does not make > sense to explicitly return "Status" in case of an error, too. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Thomas Huth > --- >

Re: [edk2] [PATCH] VfrCompile: fix invalid comparison between pointer and integer

Hi Paolo, Yes, I agree with you. I also add Nikolai SAOUKH in loop in case he may have different comment. Best Regards, Zhu Yonghong -Original Message- From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini Sent: Wednesday, February 15, 2017 5:11 PM To: Zhu,