[edk2] [PATCH v6] MdePkg: BaseIoLibIntrinsic (IoLib class) library

This patch adds an SEV-specific .INF and corresponding assembly files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines when the SEV feature is enabled under a hypervisor environment. The new .INF only supports the IA32 and X64 architectures. Cc: Michael D Kinney

[edk2] [PATCH v6] MdePkg: BaseIoLibIntrinsic (IoLib class) library

This patch adds an SEV-specific .INF and corresponding assembly files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines when the SEV feature is enabled under a hypervisor environment. The new .INF only supports the IA32 and X64 architectures. This patch follows the series "[PATCH v3

[edk2] [PATCH v7] MdePkg: BaseIoLibIntrinsic (IoLib class) library

This patch adds an SEV-specific .INF and corresponding assembly files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines when the SEV feature is enabled under a hypervisor environment. The new .INF only supports the IA32 and X64 architectures. This patch follows the series "[PATCH v3

Re: [edk2] [PATCH v7] MdePkg: BaseIoLibIntrinsic (IoLib class) library

Reviewed-by: Liming Gao > -Original Message- > From: Leo Duran [mailto:leo.du...@amd.com] > Sent: Thursday, April 6, 2017 10:48 PM > To: edk2-de...@ml01.01.org > Cc: Leo Duran ; Kinney, Michael D > ; Gao, Liming

Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues

On 04/06/17 13:26, Long, Qin wrote: > Thanks, Laszlo. > > And the last "workaround" patch can be dropped, since we introduced > the new [Includes.Common.Private] setting in Package DEC file (from > my last patch). This will help to eliminate the potential macro > re-definition risk. Is the

Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

Dear, Laszlo Thanks for your detailed explanation. On 2017/3/29 19:58, Laszlo Ersek wrote: > (This ought to be one of the longest address lists I've ever seen :) > Thanks for the CC. I'm glad Shannon is already on the CC list. For good > measure, I'm adding MST and Igor.) > > On 03/29/17

Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues

> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, April 6, 2017 8:57 PM > To: Long, Qin ; edk2-devel@lists.01.org > Cc: Ye, Ting ; Wu, Hao A ; Tian, > Feng ; Dong, Eric

[edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

The VRAM of the PL111 on the FVP Base/Foundation models is described as device memory rather than uncached memory, which is not an accurate description of the nature of the region (i.e., a framebuffer), and may result in problems when using accelerated string routines to access the region, since

[edk2] [PATCH v2 3/5] ArmPlatformPkg/PL111LcdArmVExpressLib: fix incorrect FreePool () call

When we fail to modify the memory attributes for the VRAM allocation, the allocation - which was made using AllocatePages() - is freed using FreePool(). This is incorrect by itself, but it masks a second bug, i.e., that the address of the allocation is not in VramBaseAddress but in

[edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

As reported by Jeremy, the recently introduced accelerated memcpy/memset routines are causing problems when used on framebuffer memory. While framebuffers are arguably right on the blurry line between MMIO (with side effects that are sensitive to ordering) and memory, mapping VRAM as device memory

[edk2] [PATCH v2 2/5] ArmPlatformPkg/HdLcdArmVExpressLib: fix incorrect FreePool () call

When we fail to modify the memory attributes for the VRAM allocation, the allocation - which was made using AllocatePages() - is freed using FreePool(). This is incorrect by itself, but it masks a second bug, i.e., that the address of the allocation is not in VramBaseAddress but in

[edk2] [PATCH v2 4/5] ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM

Replace the uncached memory mapping of the framebuffer with a write- combining one. This improves performance, and avoids issues with unaligned accesses and DC ZVA instructions performed by the accelerated memcpy/memset routines. Instead of manipulating the memory attributes directly, use the

[edk2] [PATCH v2 5/5] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

Replace the uncached memory mapping of the framebuffer with a write- combining one. This improves performance, and avoids issues with unaligned accesses and DC ZVA instructions performed by the accelerated memcpy/memset routines. Instead of manipulating the memory attributes directly, use the

Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Fix unconditional window shrinking

Hello, Siyuan, I experienced actual deadlock while sending huge amounts of data from uefi to some server (tried Apache and IIS). At some point of transmission server starts to reduce its window size all the way to zero window size. After window update on server (when window size restores back

Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues

On 04/06/17 16:17, Long, Qin wrote: >> -Original Message- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Thursday, April 6, 2017 8:57 PM >> To: Long, Qin ; edk2-devel@lists.01.org >> Cc: Ye, Ting ; Wu, Hao A ; Tian, >>

Re: [edk2] How to get fs index from controller handle.

Hi, Can i use gbs->loadimage() and gbs->startimage() to load an efi application and execute it. Suppose i have a app1.efi and from app1.efi i want to execute app2.efi. Or is there some other way to do it ? Not considering ShellExecute(); Amit From:

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

Hi, On 04/06/2017 08:15 AM, Ard Biesheuvel wrote: As reported by Jeremy, the recently introduced accelerated memcpy/memset routines are causing problems when used on framebuffer memory. While framebuffers are arguably right on the blurry line between MMIO (with side effects that are sensitive

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

On 6 April 2017 at 17:29, Jeremy Linton wrote: > Hi, > > On 04/06/2017 08:15 AM, Ard Biesheuvel wrote: >> >> As reported by Jeremy, the recently introduced accelerated memcpy/memset >> routines are causing problems when used on framebuffer memory. While >> framebuffers are

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

On 6 April 2017 at 14:15, Ard Biesheuvel wrote: > As reported by Jeremy, the recently introduced accelerated memcpy/memset > routines are causing problems when used on framebuffer memory. While > framebuffers are arguably right on the blurry line between MMIO (with >

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

On Thu, Apr 06, 2017 at 02:15:47PM +0100, Ard Biesheuvel wrote: > The VRAM of the PL111 on the FVP Base/Foundation models is described as > device memory rather than uncached memory, which is not an accurate > description of the nature of the region (i.e., a framebuffer), and may > result in

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

On Thu, Apr 06, 2017 at 07:31:13PM +0100, Ard Biesheuvel wrote: > On 6 April 2017 at 19:26, Leif Lindholm wrote: > > On Thu, Apr 06, 2017 at 02:15:47PM +0100, Ard Biesheuvel wrote: > >> The VRAM of the PL111 on the FVP Base/Foundation models is described as > >> device

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

On 6 April 2017 at 19:26, Leif Lindholm wrote: > On Thu, Apr 06, 2017 at 02:15:47PM +0100, Ard Biesheuvel wrote: >> The VRAM of the PL111 on the FVP Base/Foundation models is described as >> device memory rather than uncached memory, which is not an accurate >>

[edk2] Pull in pre-built library during edk2 build?

I'd like to make an adjustment to the edk2 build (locally, not for upstream) and I'm hoping someone can offer some guidance. My goal is to pre-build an edk2 library in a separate build process, then pull that library into the full build later on. Specifically I'm building my firmware image using

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

On Thu, Apr 06, 2017 at 02:15:46PM +0100, Ard Biesheuvel wrote: > As reported by Jeremy, the recently introduced accelerated memcpy/memset > routines are causing problems when used on framebuffer memory. While > framebuffers are arguably right on the blurry line between MMIO (with > side effects

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

On 6 April 2017 at 19:45, Leif Lindholm wrote: > On Thu, Apr 06, 2017 at 07:31:13PM +0100, Ard Biesheuvel wrote: >> On 6 April 2017 at 19:26, Leif Lindholm wrote: >> > On Thu, Apr 06, 2017 at 02:15:47PM +0100, Ard Biesheuvel wrote: >> >> The

Re: [edk2] How to get fs index from controller handle.

> On Apr 6, 2017, at 1:30 PM, Carsey, Jaben wrote: > > That's the way to do it. the hard work is around finding the DevicePath for > the application you want to run to pass to LoadImage. > Jaben, It was easy in the old days. DevPath = gSE2->NameToPath

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

On Thu, Apr 06, 2017 at 09:01:57PM +0100, Ard Biesheuvel wrote: > On 6 April 2017 at 20:06, Leif Lindholm wrote: > > On Thu, Apr 06, 2017 at 07:46:50PM +0100, Ard Biesheuvel wrote: > >> >> >> + // VRAM > >> >> >> + VirtualMemoryTable[++Index].PhysicalBase = > >> >> >>

Re: [edk2] Pull in pre-built library during edk2 build?

> On Apr 6, 2017, at 11:07 AM, Peter Hornyack wrote: > > I'd like to make an adjustment to the edk2 build (locally, not for > upstream) and I'm hoping someone can offer some guidance. > > My goal is to pre-build an edk2 library in a separate build process, > then pull

Re: [edk2] Pull in pre-built library during edk2 build?

I'm doing the same in one of my projects where I link against a prebuilt gcc lib. Adding support for that is quite easy actually: https://github.com/efidroid/edk2/commit/841473c1c86823521dfad5eb3d74461557302e42 On Thu, Apr 6, 2017 at 8:57 PM, Andrew Fish wrote: > >> On Apr 6,

Re: [edk2] How to get fs index from controller handle.

That's the way to do it. the hard work is around finding the DevicePath for the application you want to run to pass to LoadImage. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Amit kumar > Sent: Thursday, April 06, 2017 9:45 AM > To:

Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

On 04/06/17 14:35, gengdongjiu wrote: > Dear, Laszlo >Thanks for your detailed explanation. > > On 2017/3/29 19:58, Laszlo Ersek wrote: >> (This ought to be one of the longest address lists I've ever seen :) >> Thanks for the CC. I'm glad Shannon is already on the CC list. For good >>

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

On Thu, Apr 06, 2017 at 07:46:50PM +0100, Ard Biesheuvel wrote: > >> >> + // VRAM > >> >> + VirtualMemoryTable[++Index].PhysicalBase = > >> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE; > >> >> + VirtualMemoryTable[Index].VirtualBase = > >> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE; > >> >> +

Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory

On 6 April 2017 at 20:06, Leif Lindholm wrote: > On Thu, Apr 06, 2017 at 07:46:50PM +0100, Ard Biesheuvel wrote: >> >> >> + // VRAM >> >> >> + VirtualMemoryTable[++Index].PhysicalBase = >> >> >> PL111_CLCD_VRAM_MOTHERBOARD_BASE; >> >> >> +

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

On 6 April 2017 at 19:29, Leif Lindholm wrote: > On Thu, Apr 06, 2017 at 02:15:46PM +0100, Ard Biesheuvel wrote: >> As reported by Jeremy, the recently introduced accelerated memcpy/memset >> routines are causing problems when used on framebuffer memory. While >>

[edk2] [edk2-FdfSpecification PATCH] [edk2-FdfSpecification PATCH] [FmpPayload] supports 1 or 2 FILE DATA statements

https://bugzilla.tianocore.org/show_bug.cgi?id=461 Update the EBNF for [FmpPayload] in Section 3.8 to allow one or two FILE DATA statements. The first for the update image. The second for venddor code. GitHub branch for review:

[edk2] [edk2-FdfSpecification PATCH] [FmpPayload] supports 1 or 2 FILE DATA statements

https://bugzilla.tianocore.org/show_bug.cgi?id=461 Update the EBNF for [FmpPayload] in Section 3.8 to allow one or two FILE DATA statements. The first for the update image. The second for venddor code. Cc: Liming Gao Cc: Yonghong Zhu Cc: Kevin W

Re: [edk2] How to get fs index from controller handle.

Andrew, I was assuming not wanting ShellExecute() might extend to the rest of the shell. If the shell is in use, that can definitely help. While those 2 APIs do exist in theory, there is a single one that does all I think: GetDevicePathFromFilePath. -Jaben From: af...@apple.com

[edk2] [edk2-FdfSpecification PATCH] Fix conditional statement examples

https://bugzilla.tianocore.org/show_bug.cgi?id=373 * Removge space between !if and else * Add $() around BARFOO Cc: Liming Gao Cc: Yonghong Zhu Cc: Kevin W Shaw Contributed-under: TianoCore Contribution Agreement 1.1

[edk2] [edk2-FdfSpecification PATCH] Fix conditional statement examples

https://bugzilla.tianocore.org/show_bug.cgi?id=373 * Removge space between !if and else * Add $() around BARFOO Cc: Liming Gao Cc: Yonghong Zhu Cc: Kevin W Shaw Contributed-under: TianoCore Contribution Agreement 1.1

Re: [edk2] Pull in pre-built library during edk2 build?

On 04/06/17 20:07, Peter Hornyack wrote: > I'd like to make an adjustment to the edk2 build (locally, not for > upstream) and I'm hoping someone can offer some guidance. > > My goal is to pre-build an edk2 library in a separate build process, > then pull that library into the full build later on.

Re: [edk2] [Patch] CryptoPkg: Move openssl and CRT headers to private include section

Qin: How about creating new Private directory in CryptoPkg, then move those internal header files into it? Thanks Liming >-Original Message- >From: Long, Qin >Sent: Thursday, April 06, 2017 1:56 PM >To: Gao, Liming ; Ye, Ting >Cc:

Re: [edk2] [Patch] CryptoPkg: Move openssl and CRT headers to private include section

Yes, it's feasible. I still prefer to use "Library/Include" path setting for this, since only CryptoPkg/Library/* will refer to these internal header files. It may be cleaner to keep the current directory in root of CryptoPkg. Best Regards & Thanks, LONG, Qin > -Original Message- >

Re: [edk2] [PATCH] SecurityPkg: SecureBootConfigDxe: Update CloseEnrolledFile comment

Reviewed-by: Dandan Bi -Original Message- From: Zhang, Chao B Sent: Thursday, April 6, 2017 3:21 PM To: edk2-devel@lists.01.org Cc: Bi, Dandan ; Zhang, Chao B Subject: [PATCH] SecurityPkg: SecureBootConfigDxe: Update

Re: [edk2] [Patch] BaseTools: Update tools_def.template to add -fno-builtin in GCC tool chain

Thanks! I will update the commit message and push it. >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >Laszlo Ersek >Sent: Thursday, April 06, 2017 3:39 PM >To: Gao, Liming ; edk2-devel@lists.01.org >Cc: Ard Biesheuvel

[edk2] [Patch] CryptoPkg IntrinsicLib: Remove GCC -fno-builtin option

GCC -fno-builtin option is added into tools_def.template. So, there is no need to set it in module INF file. Cc: Qin Long Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao ---

Re: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC -fno-builtin option

How about to indicate the SHA-1: 90defe7198a42b3157ae5d9b93714f891cf06e57 in the commit log like below? GCC -fno-builtin option is added into tools_def.template at 90defe7198a42b3157ae5d9b93714f891cf06e57. So, there is no need to set it in module INF file. Thanks, Star -Original

[edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC -fno-builtin option

GCC -fno-builtin option is added into tools_def.template. So, there is no need to set it in module INF file. Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao ---

Re: [edk2] [Patch] BaseTools: Update tools_def.template to add -fno-builtin in GCC tool chain

On 04/06/17 02:57, Laszlo Ersek wrote: > On 04/06/17 02:45, Liming Gao wrote: >> Now, -fno-builtin option is added for the specific GCC tool chain. >> It is a generic option. It can be moved to common GCC option to keep >> the consistent compiler option. >> >> Cc: Ard Biesheuvel

Re: [edk2] [Patch] CryptoPkg: Move openssl and CRT headers to private include section

Got it. Thanks for your clarification. >-Original Message- >From: Long, Qin >Sent: Thursday, April 06, 2017 2:25 PM >To: Gao, Liming ; Ye, Ting >Cc: edk2-devel@lists.01.org >Subject: RE: [Patch] CryptoPkg: Move openssl and CRT headers to private

Re: [edk2] [Patch] CryptoPkg IntrinsicLib: Remove GCC -fno-builtin option

Reviewed-by: Long Qin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Liming Gao > Sent: Thursday, April 06, 2017 4:16 PM > To: edk2-devel@lists.01.org > Cc: Long, Qin > Subject: [edk2] [Patch] CryptoPkg IntrinsicLib:

Re: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC -fno-builtin option

Good suggestion. I will update commit log. >-Original Message- >From: Zeng, Star >Sent: Thursday, April 06, 2017 4:22 PM >To: Gao, Liming ; edk2-devel@lists.01.org >Cc: Zeng, Star >Subject: RE: [edk2] [Patch] MdeModulePkg RegularExpressionDxe:

Re: [edk2] [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases

On Wed, Apr 05, 2017 at 10:55:49PM +0100, Ard Biesheuvel wrote: > >>> I think this is a problem because nowhere in the UEFI specs do I see such > >>> restrictions on those memory operations. > >> > >> Using device attributes for memory is something we should ban for > >> AArch64 in the spec. Yes,

Re: [edk2] [PATCH 1/2] ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM

On Wed, Apr 05, 2017 at 09:38:32PM +0100, Ard Biesheuvel wrote: > Replace the uncached memory mapping of the framebuffer with a write- > combining one. This improves performance, and avoids issues with > unaligned accesses and DC ZVA instructions performed by the accelerated > memcpy/memset

Re: [edk2] [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases

On 6 April 2017 at 10:35, Leif Lindholm wrote: > On Wed, Apr 05, 2017 at 10:55:49PM +0100, Ard Biesheuvel wrote: >> >>> I think this is a problem because nowhere in the UEFI specs do I see such >> >>> restrictions on those memory operations. >> >> >> >> Using device

[edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: Enhance short-form expanding logic

Old implementation only finds first matched full device path for a given short-form device path. The patch adds internal function BmGetNextLoadOptionBuffer() to finds all matched full device path for a given short-form device path. There are 6 kinds of device paths. Some of them match to multiple

Re: [edk2] How to get fs index from controller handle.

> On Apr 6, 2017, at 3:30 AM, Amit kumar wrote: > > Hi, > > I want to get the fs index from the controller handle. > e.g In map command i see my controller is mapped to fs10. > So i there any API i can use in my code to get the fs index( which is 10 as > in example)

Re: [edk2] [PATCH 2/2] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

On 5 April 2017 at 21:38, Ard Biesheuvel wrote: > Replace the uncached memory mapping of the framebuffer with a write- > combining one. This improves performance, and avoids issues with > unaligned accesses and DC ZVA instructions performed by the accelerated >

Re: [edk2] [PATCH 1/2] ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM

On 6 April 2017 at 11:40, Ard Biesheuvel wrote: > On 6 April 2017 at 10:37, Leif Lindholm wrote: >> On Wed, Apr 05, 2017 at 09:38:32PM +0100, Ard Biesheuvel wrote: >>> Replace the uncached memory mapping of the framebuffer with a write- >>>

Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues

Thanks, Laszlo. And the last "workaround" patch can be dropped, since we introduced the new [Includes.Common.Private] setting in Package DEC file (from my last patch). This will help to eliminate the potential macro re-definition risk. It's still valuable to refine openssl e_os2.h definition

Re: [edk2] [PATCH 2/2] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

On 6 April 2017 at 12:14, Ryan Harkin wrote: > On 5 April 2017 at 21:38, Ard Biesheuvel wrote: >> Replace the uncached memory mapping of the framebuffer with a write- >> combining one. This improves performance, and avoids issues with >>

Re: [edk2] [PATCH 2/2] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

On 6 April 2017 at 12:32, Ard Biesheuvel wrote: > On 6 April 2017 at 12:14, Ryan Harkin wrote: >> On 5 April 2017 at 21:38, Ard Biesheuvel wrote: >>> Replace the uncached memory mapping of the framebuffer with a

Re: [edk2] [Patch] MdeModulePkg RegularExpressionDxe: Remove GCC -fno-builtin option

With that, you can have my Reviewed-by: Star Zeng Thanks, Star -Original Message- From: Gao, Liming Sent: Thursday, April 6, 2017 4:40 PM To: Zeng, Star ; edk2-devel@lists.01.org Subject: RE: [edk2] [Patch] MdeModulePkg RegularExpressionDxe:

Re: [edk2] [PATCH v2 0/4] Resolving Some CryptoPkg Build Issues

On 04/01/17 07:38, Long Qin wrote: > From: Qin Long > > V2: > Updated the patches as the comments from Laszlo (ler...@redhat.com). > And filed two TianoCore BZ (#455, #456) to track the further follow-ups > on openssl and EDKII-CryptoPkg: >

Re: [edk2] [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases

On Thu, Apr 06, 2017 at 10:43:57AM +0100, Ard Biesheuvel wrote: > On 6 April 2017 at 10:35, Leif Lindholm wrote: > > On Wed, Apr 05, 2017 at 10:55:49PM +0100, Ard Biesheuvel wrote: > >> >>> I think this is a problem because nowhere in the UEFI specs do I see > >> >>>

[edk2] How to get fs index from controller handle.

Hi, I want to get the fs index from the controller handle. e.g In map command i see my controller is mapped to fs10.  So i there any API i can use in my code to get the fs index( which is 10 as in example) from the controller handle.  Regards  Amit

Re: [edk2] [PATCH 1/2] ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM

On 6 April 2017 at 10:37, Leif Lindholm wrote: > On Wed, Apr 05, 2017 at 09:38:32PM +0100, Ard Biesheuvel wrote: >> Replace the uncached memory mapping of the framebuffer with a write- >> combining one. This improves performance, and avoids issues with >> unaligned

Re: [edk2] [patch] NetworkPkg: Fix bug related DAD issue in IP6 driver.

Reviewed-by: Wu Jiaxin Thanks, Jiaxin > -Original Message- > From: Zhang, Lubo > Sent: Thursday, April 6, 2017 4:58 PM > To: edk2-devel@lists.01.org > Cc: Wu, Jiaxin ; Ye, Ting ; Fu, > Siyuan > Subject:

Re: [edk2] [PATCH 0/9] Export Dump CPU Context service

Jiewen, That's fine. If you consider the patch based on module for this case is better your review, I will combine some of them soon. Thanks! Jeff From: Yao, Jiewen Sent: Friday, April 07, 2017 8:41 AM To: Fan, Jeff; edk2-devel@lists.01.org Cc: Kinney, Michael D; Tian, Feng Subject: RE: [PATCH

[edk2] [edk2-FdfSpecification PATCH] Add missing EBNF definition for

https://bugzilla.tianocore.org/show_bug.cgi?id=249 GitHub branch for review: https://github.com/mdkinney/edk2-FdfSpecification/tree/Bugzilla_249_AddUiFmpName GitHub branch compare against latest DRAFT for review:

[edk2] [edk2-FdfSpecification PATCH] Add missing EBNF definition for

https://bugzilla.tianocore.org/show_bug.cgi?id=249 Cc: Liming Gao Cc: Yonghong Zhu Cc: Kevin W Shaw Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael Kinney ---

Re: [edk2] Pull in pre-built library during edk2 build?

On 04/07/17 00:46, Laszlo Ersek wrote: > 0001-ExternalSslPkg-create-INF-files-for-OpensslLib-binar.patch > > > From 4672a027f54c54574129f9c9cc947c80f7bc4d9f Mon Sep 17 00:00:00 2001 > From: Laszlo Ersek > Date: Thu, 6 Apr 2017 22:56:04 +0200 > Subject: [PATCH]

Re: [edk2] [PATCH 0/9] Export Dump CPU Context service

Hi I do not think it is necessary to split this simple patch to so many. It brings burden to me to review the change. For example, there are 4 patches for CpuExceptionHandlerLib. Can we combine the patch based upon the module? Thank you Yao Jiewen > -Original Message- > From: Fan,

Re: [edk2] [PATCH 0/9] Export Dump CPU Context service

Thank you! From: Fan, Jeff Sent: Friday, April 7, 2017 8:46 AM To: Yao, Jiewen ; edk2-devel@lists.01.org Cc: Kinney, Michael D ; Tian, Feng Subject: RE: [PATCH 0/9] Export Dump CPU Context service Jiewen, That's fine. If

Re: [edk2] [PATCH] UefiCpuPkg/CpuFeatures: Change CPU features name to follow IA32 SDM

Reviewed-by: Feng Tian Thanks Feng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff Fan Sent: Thursday, April 6, 2017 1:47 PM To: edk2-devel@lists.01.org Cc: Kinney, Michael D ; Tian, Feng

Re: [edk2] [Patch] CryptoPkg: Move openssl and CRT headers to private include section

Reviewed-by: Ye Ting -Original Message- From: Long, Qin Sent: Thursday, April 6, 2017 1:56 PM To: Gao, Liming ; Ye, Ting Cc: edk2-devel@lists.01.org; Long, Qin Subject: [Patch] CryptoPkg: Move openssl and

[edk2] [patch] NetworkPkg: Add check logic for iSCSI driver.

Need to check variable of mPrivate whether is null before used and redefine the array length of target address for keyword. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zhang Lubo Cc: Wu Jiaxin Cc: Ye Ting

[edk2] [patch] NetworkPkg: Fix bug related DAD issue in IP6 driver.

If we set PXEv6 as the first boot option and reboot immediately after the first successful boot, it will assert. the root cause is when we set the policy from manual to automatic in PXE driver, the ip6 Configure item size is already set to zero and other structures are also released, So it is not

[edk2] [PATCH] SecurityPkg: SecureBootConfigDxe: Update CloseEnrolledFile comment

Update function CloseEnrolledFile comment introduced in 4de754e15fec9c94ce7677904efd0022c211721b Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chao Zhang --- .../SecureBootConfigDxe/SecureBootConfigImpl.c| 8 ++-- 1 file

[edk2] 答复: [DxeNetLib] Why do we restrict each field to have the same leading zero format?

Many thanks. I missed to check the latest cod... Regards, Gary (Heyi Guo) -邮件原件- 发件人: Wu, Jiaxin [mailto:jiaxin...@intel.com] 发送时间: 2017年4月6日 13:30 收件人: Guoheyi; edk2-devel@lists.01.org 抄送: Tian, Feng; Fu, Siyuan; Zeng, Star 主题: RE: [edk2] [DxeNetLib] Why do we restrict each field to

Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: Enhance short-form expanding logic

Reviewed-by: Feng Tian Thanks Feng -Original Message- From: Ni, Ruiyu Sent: Thursday, April 6, 2017 5:45 PM To: edk2-devel@lists.01.org Cc: Tian, Feng ; Dong, Eric ; Fan, Jeff Subject: [PATCH]

Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

Hi Laszlo, thanks. On 2017/4/7 2:55, Laszlo Ersek wrote: > On 04/06/17 14:35, gengdongjiu wrote: >> Dear, Laszlo >>Thanks for your detailed explanation. >> >> On 2017/3/29 19:58, Laszlo Ersek wrote: >>> (This ought to be one of the longest address lists I've ever seen :) >>> Thanks for the

[edk2] [patch] ShellPkg/SetVar: Fix typo in comments

Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi --- ShellPkg/Library/UefiShellDebug1CommandsLib/SetVar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[edk2] [PATCH] ShellPkg: Fix Shell to not return without startup.nsh after timeout

When user doesn't press key to exit the timeout waiting in Shell, and there is no startup.nsh, Shell exits with failure status. aaf51f08ee104447207bba571649556095befc93 introduced this bug. The patch fixes this issue. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni

Re: [edk2] [patch] ShellPkg/SetVar: Fix typo in comments

Reviewed-by: Ruiyu Ni Thanks/Ray > -Original Message- > From: Bi, Dandan > Sent: Friday, April 7, 2017 11:01 AM > To: edk2-devel@lists.01.org > Cc: Ni, Ruiyu > Subject: [patch] ShellPkg/SetVar: Fix typo in comments > > Cc: Ruiyu Ni

Re: [edk2] Pull in pre-built library during edk2 build?

Thank you Laszlo and others for the suggestions! I'll try out that patch with PACKAGES_PATH and it looks like I should be able to get this working. Thanks, Peter On Thu, Apr 6, 2017 at 4:16 PM, Laszlo Ersek wrote: > On 04/07/17 00:46, Laszlo Ersek wrote: > >>

[edk2] [PATCH v2 1/5] MdePkg/PeCoffGetEntryPointLib: Add PeCoffSerachImageBase()

This new API only works on DEBUG build. It will search the PE/COFF image base forward the input address in this PE/COFF image and returns it. Cc: Jiewen Yao Cc: Michael Kinney Cc: Liming Gao Contributed-under: TianoCore

[edk2] [PATCH v2 2/5] MdeModulePkg/CpuExceptionHandlerLib: Add DumpCpuContext()

This API is used to display exception type and all processor context for debug purpose. Cc: Jiewen Yao Cc: Michael Kinney Cc: Feng Tian Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan

[edk2] [PATCH v2 5/5] SourceLevelDebugPkg/DebugAgent.c: Consume PeCoffSerachImageBase()

Cc: Jiewen Yao Cc: Michael Kinney Cc: Feng Tian Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan --- .../DebugAgent/DebugAgentCommon/DebugAgent.c | 50

[edk2] [PATCH v2 4/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume new APIs

Consuming PeCoffSerachImageBase() from PeCoffGetEntrypointLib and consuming DumpCpuContext() from CpuExceptionHandlerLib to replace its own implementation. Cc: Jiewen Yao Cc: Michael Kinney Cc: Feng Tian Contributed-under:

[edk2] [PATCH v2 0/5] Export Dump CPU Context service

This serial of patches are: 1. Export PeCoffSerachImageBase() that could serach PE/COFF image base. 2. Export DumpCpuContext that could dump CPU context when exception happened. https://bugzilla.tianocore.org/show_bug.cgi?id=242 v2: Combine v1's patch 3-6 to v2's patch 3. Combine v1's patch

[edk2] [PATCH v2 3/5] UefiCpuPkg/CpuExceptionHandlerLib: Add DumpCpuContext() implementation

Export DumpCpuCotext() to display CPU Context. We will invoke PeCoffGetEntrypointLib's PeCoffSerachImageBase() to get PE/COFF image base. Display exception data bit value for page fault exception. Cc: Jiewen Yao Cc: Michael Kinney Cc: Feng Tian

Re: [edk2] [edk2-FdfSpecification PATCH] Add missing EBNF definition for

Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Kinney, Michael D Sent: Friday, April 7, 2017 7:22 AM To: edk2-devel@lists.01.org Cc: Gao, Liming ; Zhu, Yonghong ; Shaw, Kevin W

Re: [edk2] [edk2-FdfSpecification PATCH] [FmpPayload] supports 1 or 2 FILE DATA statements

Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Kinney, Michael D Sent: Friday, April 7, 2017 4:00 AM To: edk2-devel@lists.01.org Cc: Gao, Liming ; Zhu, Yonghong ; Shaw, Kevin W

Re: [edk2] [edk2-FdfSpecification PATCH] Fix conditional statement examples

Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Kinney, Michael D Sent: Friday, April 7, 2017 5:56 AM To: edk2-devel@lists.01.org Cc: Gao, Liming ; Zhu, Yonghong ; Shaw, Kevin W

[edk2] [PATCH] AppPkg/Applications/Python/PyMod-2.7.2: Replace non-ascii characters

Cc: Daryl McDaniel Cc: Jaben Carsey Contributed-under: TianoCore Contribution Agreement 1.0 Contributed-by: gray.wang Signed-off-by: Hao Wu --- AppPkg/Applications/Python/PyMod-2.7.2/Python/marshal.c | 4

Re: [edk2] [PATCH v2 0/5] Export Dump CPU Context service

Reviewed-by: jiewen@intel.com > -Original Message- > From: Fan, Jeff > Sent: Friday, April 7, 2017 9:18 AM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Kinney, Michael D > ; Tian, Feng > Subject: [PATCH v2