Re: [edk2] [PATCH] OvmfPkg/QemuVideoDxe: handle invalid BltOperation gracefully

On 23 March 2018 at 21:57, Laszlo Ersek wrote: > According to the UEFI spec, EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() is supposed > to catch an invalid BltOperation, and report it with > EFI_INVALID_PARAMETER. > > Remove the assertion from QemuVideoGraphicsOutputBlt() that prevents

Re: [edk2] [staging/dynamictables PATCH 0/2] Dynamic Tables Framework core

Hi Evan, Sorry it didn't notice during my first read that SMBIOS/devicetree was also supported. This is a rather large code drop and it is taking some time to go through the entire thing. DynamicTablesDxe seems fine to me. With regard to the EFI_CONFIGURATION_MANAGER_PROTOCOL, note that the

[edk2] [PATCH] OvmfPkg/QemuVideoDxe: handle invalid BltOperation gracefully

According to the UEFI spec, EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() is supposed to catch an invalid BltOperation, and report it with EFI_INVALID_PARAMETER. Remove the assertion from QemuVideoGraphicsOutputBlt() that prevents this from working in NOOPT and DEBUG builds. Cc: Ard Biesheuvel

[edk2] [PATCH v2 12/15] UefiCpuPkg/PiSmmCpuDxeSmm: eliminate "gSmmJmpAddr" and related DBs

The IA32 version of "SmmInit.nasm" does not need "gSmmJmpAddr" at all (its PiSmmCpuSmmInitFixupAddress() variant doesn't do anything either). We can simply use the NASM syntax for the following Mixed-Size Jump: > jmp PROTECT_MODE_CS : dword @32bit The generated object code for the instruction is

[edk2] [PATCH v2 01/15] MdePkg/BaseLib.h: state preprocessing conditions in comments after #endifs

"#endif" preprocessing directives near the top of "BaseLib.h" helpfully repeat the preprocessing conditions from their matching "#if", "#ifdef", and "#ifndef" directives. This practice has been less followed recently; supplement the missing comments. Cc: Liming Gao Cc:

[edk2] [PATCH v2 05/15] UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmiStack" with PatchInstructionX86()

Rename the variable to "gPatchSmiStack" so that its association with PatchInstructionX86() is clear from the declaration. Also change its type to X86_ASSEMBLY_PATCH_LABEL. Unlike "gSmbase" in the previous patch, "gSmiStack"'s patched value is also de-referenced by C code (in other words, it is

[edk2] [PATCH v2 07/15] UefiCpuPkg/PiSmmCpuDxeSmm: patch "XdSupported" with PatchInstructionX86()

"mXdSupported" is a global BOOLEAN variable, initialized to TRUE. The CheckFeatureSupported() function is executed on all processors (not concurrently though), called from SmmInitHandler(). If XD support is found to be missing on any CPU, then "mXdSupported" is set to FALSE, and further processors

[edk2] [PATCH v2 06/15] UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmiCr3" with PatchInstructionX86()

Rename the variable to "gPatchSmiCr3" so that its association with PatchInstructionX86() is clear from the declaration, change its type to X86_ASSEMBLY_PATCH_LABEL, and patch it with PatchInstructionX86(). This lets us remove the binary (DB) encoding of some instructions in "SmiEntry.nasm". Cc:

[edk2] [PATCH v2 14/15] UefiCpuPkg/PiSmmCpuDxeSmm: remove DBs from SmmRelocationSemaphoreComplete32()

(1) SmmRelocationSemaphoreComplete32() runs in 32-bit mode, so wrap it in a (BITS 32 ... BITS 64) bracket. (2) SmmRelocationSemaphoreComplete32() currently compiles to: > 02AE C60501mov byte [dword 0x0],0x1 > 02B5 FF25 jmp dword [dword 0x0] where the

[edk2] [PATCH v2 03/15] UefiCpuPkg/PiSmmCpuDxeSmm: remove *.S and *.asm assembly files

All edk2 toolchains use NASM for compiling X86 assembly source code. We plan to remove X86 *.S and *.asm files globally, in order to reduce maintenance and confusion:

[edk2] [PATCH v2 04/15] UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmbase" with PatchInstructionX86()

Rename the variable to "gPatchSmbase" so that its association with PatchInstructionX86() is clear from the declaration, change its type to X86_ASSEMBLY_PATCH_LABEL, and patch it with PatchInstructionX86(). This lets us remove the binary (DB) encoding of some instructions in "SmiEntry.nasm". Cc:

[edk2] [PATCH v2 08/15] UefiCpuPkg/PiSmmCpuDxeSmm: remove unneeded DBs from X64 SmmStartup()

(This patch is the 64-bit variant of commit e75ee97224e5, "UefiCpuPkg/PiSmmCpuDxeSmm: remove unneeded DBs from IA32 SmmStartup()", 2018-01-31.) The SmmStartup() function executes in SMM, which is very similar to real mode. Add "BITS 16" before it and "BITS 64" after it (just before the @LongMode

[edk2] [PATCH v2 15/15] UefiCpuPkg/PiSmmCpuDxeSmm: use mnemonics for FXSAVE(64)/FXRSTOR(64)

NASM introduced FXSAVE / FXRSTOR support in commit 900fa5b26b8f ("NASM 0.98p3-hpa", 2002-04-30), which commit stands for the nasm-0.98p3-hpa release. NASM introduced FXSAVE64 / FXRSTOR64 support in commit 3a014348ca15 ("insns: add FXSAVE64/FXRSTOR64, drop np prefix", 2010-07-07), which was part

[edk2] [PATCH v2 02/15] MdePkg/BaseLib: add PatchInstructionX86()

Some edk2 modules generate X86 machine code at module execution time by: - compiling "template" code with NASM at module build time, - linking the object code into the module, - and patching the immediate (constant) operands of some instructions when the module is executed. Add a helper

[edk2] [PATCH v2 13/15] UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmmInitStack" with PatchInstructionX86()

Rename the variable to "gPatchSmmInitStack" so that its association with PatchInstructionX86() is clear from the declaration, change its type to X86_ASSEMBLY_PATCH_LABEL, and patch it with PatchInstructionX86(). This lets us remove the binary (DB) encoding of some instructions in "SmmInit.nasm".

[edk2] [PATCH v2 09/15] UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmmCr3" with PatchInstructionX86()

Rename the variable to "gPatchSmmCr3" so that its association with PatchInstructionX86() is clear from the declaration, change its type to X86_ASSEMBLY_PATCH_LABEL, and patch it with PatchInstructionX86(). This lets us remove the binary (DB) encoding of some instructions in "SmmInit.nasm". Cc:

[edk2] [PATCH v2 11/15] UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmmCr0" with PatchInstructionX86()

Like "gSmmCr4" in the previous patch, "gSmmCr0" is not only used for machine code patching, but also as a means to communicate the initial CR0 value from SmmRelocateBases() to InitSmmS3ResumeState(). In other words, the last four bytes of the "mov eax, Cr0Value" instruction's binary representation

[edk2] [PATCH v2 00/15] rid PiSmmCpuDxeSmm of DB-encoded instructions

Repo: https://github.com/lersek/edk2.git Branch: patch_insn_x86_v2 This is version 2 of the series originally posted at . The changes are documented per patch. I retested the test cases listed in the v1 blurb. Cc: Eric Dong

[edk2] [PATCH v2 10/15] UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmmCr4" with PatchInstructionX86()

Unlike "gSmmCr3" in the previous patch, "gSmmCr4" is not only used for machine code patching, but also as a means to communicate the initial CR4 value from SmmRelocateBases() to InitSmmS3ResumeState(). In other words, the last four bytes of the "mov eax, Cr4Value" instruction's binary

[edk2] [PATCH v2 5/9] BaseTools: Regular Expressions refactor out the hex char for later reuse

From: Carsey, Jaben move hex character info from GUID expressions into seperate variable to facilitate reuse. I had a type with insufficient {} in the first version. Cc: Yonghong Zhu Cc: Liming Gao Contributed-under: TianoCore Contribution

Re: [edk2] MdeModulePkg/SerialDxe: SetAttributes() not follow UEFI spec

On 03/23/18 01:50, Zeng, Star wrote: > I agree. Wasn't there a problem with the default timeout being 1 second, and that 1 second slowing down terminal I/O on some platform? I don't remember more precisely. Thanks Laszlo > -Original Message- > From: Guo Heyi [mailto:heyi@linaro.org]

Re: [edk2] Boot delay due to network devices

On 03/23/18 14:01, Wasim Khan wrote: > Hi Michael, > > Thank you for your prompt reply. > > Yes, in one of our implementation we are doing the same in our network driver > (without DriverBinding protocol support). > > We were thinking to update our network driver to support DriverBinding >

Re: [edk2] Boot delay due to network devices

On 03/23/18 12:58, Wasim Khan wrote: > Hi Laszlo, > > I want to re-discuss this thread with you. > > So as you mentioned that we can define a platform policy to connect > to only intended devices (Say Network (PXE) and Removable Media > devices). > > But when I say boot from Network devices, we

Re: [edk2] Boot delay due to network devices

Hi Michael, Thank you for your prompt reply. Yes, in one of our implementation we are doing the same in our network driver (without DriverBinding protocol support). We were thinking to update our network driver to support DriverBinding Protocol and explore if we can get a boot call for boot

Re: [edk2] Boot delay due to network devices

On 23/03/18 11:58, Wasim Khan wrote: Ex: if auto-neg timeout is 5 seconds and if we have 10 network interfaces (all are legal candidate for booting), and cable is connected to 3rd interface only then 45 seconds will be wasted (5 seconds each for 9 interfaces) in auto-neg of interfaces which

Re: [edk2] Boot delay due to network devices

Hi Laszlo, I want to re-discuss this thread with you. So as you mentioned that we can define a platform policy to connect to only intended devices (Say Network (PXE) and Removable Media devices). But when I say boot from Network devices, we have to scan all the devices as all devices are

Re: [edk2] [patch] OvmfPkg:Fix VS2012 build failure

On 03/23/18 06:12, Dandan Bi wrote: > Initialize local variable to suppress warning C4701/C4703: > potentially uninitialized local variable/pointer variable. > > 1.In VirtualMemory.c: > Read of "PageMapLevel4Entry" in SetMemoryEncDe() is only > reached when "PageMapLevel4Entry" is got correctly.

Re: [edk2] [PATCH edk2-non-osi 1/1] Hisilicon/D0x/Sm750: Fix GOP framebuffer base

On 22 March 2018 at 19:02, Heyi Guo wrote: > The code in SM750 driver treated the address returned from > PciIo->GetBarAttributes() as device address; this should be fixed > after edk2 commit dc080d3 since GetBarAttributes() returns host > address from then on. > >

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Fix VS2015 build failure.

Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: David Wei --- .../PlatformBootManagerLib/PlatformBootOption.c| 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git

Re: [edk2] [patch 2/2] BaseTool/VfrCompile: Fix potential memory leak issue

Reviewed-by: Liming Gao > -Original Message- > From: Bi, Dandan > Sent: Tuesday, February 27, 2018 1:54 PM > To: edk2-devel@lists.01.org > Cc: Dong, Eric ; Gao, Liming > Subject: [patch 2/2] BaseTool/VfrCompile: Fix

Re: [edk2] [patch 1/2] BaseTool/VfrCompile: make delete[] match with new[]

Reviewed-by: Liming Gao > -Original Message- > From: Bi, Dandan > Sent: Tuesday, February 27, 2018 1:54 PM > To: edk2-devel@lists.01.org > Cc: Dong, Eric ; Gao, Liming > Subject: [patch 1/2] BaseTool/VfrCompile: make

[edk2] [PATCH 6/6] Platform/ARM/Sgi: add initial support for ARM SGI platform

From: Vishwanatha HG Add the initial support for ARM's System Guidance for Infrastructure (SGI) platforms which can be used on a SGI-575 platform. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Vishwanatha HG

[edk2] [PATCH 5/6] Platform/ARM/Sgi: add the initial set of acpi tables

From: Daniil Egranov Add the initial version of Acpi tables required to boot the linux kernel to a busybox prompt. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Daniil Egranov Signed-off-by: Thomas Abraham

[edk2] [PATCH 4/6] Platform/ARM/Sgi: add support for virtio block device

From: Daniil Egranov Add the registration of the virtio block device. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Daniil Egranov Signed-off-by: Thomas Abraham ---

[edk2] [PATCH 3/6] Platform/ARM/Sgi: add initial platform dxe driver implementation

From: Daniil Egranov Add a initial platform dxe driver which starts of being almost an empty implemenation. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Daniil Egranov Signed-off-by: Thomas Abraham

[edk2] [PATCH 0/6] Platform/ARM/Sgi: Add Arm's SGI platform support

Arm CoreLink System Guidance for Infrastructure is a collection of resources to provide a representative view of typical compute subsystems that can be designed and implemented using specific generations of Arm IP. These compute subsystems address the expected requirements of a specific segment of

[edk2] [PATCH 1/6] Platform/ARM/Sgi: Add Platform library implementation

Add initial SGI platform library support. This includes the virtual memory map and helper functions for platform intialization. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Thomas Abraham --- Platform/ARM/SgiPkg/Include/SgiPlatform.h |

[edk2] [PATCH 2/6] Platform/ARM/Sgi: add NOR flash platform library implementation

From: Vishwanatha HG Add a initial NOR flash driver platform wrapper as part of the platform library. Access to NOR fash 0 is enabled in this initial implementation. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Vishwanatha HG