Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

On 16 November 2017 at 09:48, Zeng, Star wrote: > As I remember UEFI 2.5 clarified this and added EFI_MEMORY_RO was because > EFI_MEMORY_WP had been typically used for cache even before UEFI 2.5. > > And I do not think this patch should filter out EFI_MEMORY_WP since this >

[edk2] [PATCH V2] MdeModulePkg EhciPei: Support IoMmu

V2: Halt HC at EndOfPei. Update the EhciPei driver to consume IOMMU_PPI to allocate DMA buffer. If no IOMMU_PPI exists, this driver still calls PEI service to allocate DMA buffer, with assumption that DRAM==DMA. Cc: Jiewen Yao Contributed-under: TianoCore Contribution

[edk2] [PATCH] ArmPkg: move RVCT PLATFORM_FLAGS override into ArmHvcLib/ArmSmcLib

Currently, each ARM platform built with RVCT that uses ArmHvcLib or ArmSmcLib needs to specify a CPU target that implements both the security and virtualization extensions, so that the assembler does not choke on the 'hvc' and 'smc' instructions in ArmHvcLib/ArmSvcLib. Let's move these overrides

Re: [edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

On 16 November 2017 at 14:15, Ard Biesheuvel wrote: > On 16 November 2017 at 12:34, Ard Biesheuvel > wrote: >> >> >>> On 16 Nov 2017, at 11:59, Leif Lindholm wrote: >>> On Thu, Nov 16, 2017 at 09:40:58AM

[edk2] [PATCH] OvmfPkg/XenHypercallLib: enable virt extensions for ARM

XenHypercallLib uses the 'hvc' instruction, which is not implemented on all ARMv7 CPUs, and so we need to explicitly specify a CPU that has the virtualization extensions. This override used to be set at the platform level, but this was removed in commit 0d36a219c7bdbb27d775b50837823b2a9928147c

Re: [edk2] [PATCH] OvmfPkg/XenHypercallLib: enable virt extensions for ARM

Forward to Julien at his @linaro.org address. -- Forwarded message -- From: Ard Biesheuvel Date: 16 November 2017 at 16:56 Subject: [PATCH] OvmfPkg/XenHypercallLib: enable virt extensions for ARM To: edk2-devel@lists.01.org, leif.lindh...@linaro.org,

Re: [edk2] [PATCH] EmbeddedPkg: add mx66u1g45g nor flash info

On Wed, Nov 15, 2017 at 11:19:32AM +, Ard Biesheuvel wrote: > From: Pipat Methavanitpong > > Add Macronix MX66U1G45G definition to NorFlashInfoLib > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Pipat Methavanitpong

Re: [edk2] [PATCH 1/1] BaseTools: Use VS2017 SDK path if defined and reorganize variables

On 2017.11.16 14:48, Gao, Liming wrote: I agree to separate HOST and ARCH. For this patch, I have minor comment on WINSDK10_BIN. DEFINE WINSDK10_BIN = ENV(WINSDK10_PREFIX)x86 ==> DEFINE WINSDK10_BIN = ENV(WINSDK10_PREFIX)DEF(VS2017_HOST) Good point. I agree that the SDK should

Re: [edk2] GRUB issue on device priority

Apologies for delay in responding. On Thu, Nov 09, 2017 at 04:41:55PM +0800, Haojian Zhuang wrote: > > > In the HiKey platform, I prepared the same driver for both eMMC and > > > SD. So the device paths are in below. > > > SD: /HardwareVendor(0d51905b-b77e-452a-a2c0-eca0cc8d514a)[9: 00 e0 23 f7

[edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really set attributes and change memory paging attribute accordingly. But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by value from Capabilities in GCD memory map. This might cause boot problems. Clearing all paging related

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

Ard: Does this error only happen on ACPI table compiling? But, I see -no-pie is also in normal DLINK flag. Why is the driver not compiled failed? Thanks Liming > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Thursday, November 16, 2017 11:09 PM >

Re: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

On 11/15/2017 07:18 PM, Paulo Alcantara wrote: This patch adds stack trace support during a X64 CPU exception. It will dump out back trace, stack contents as well as image module names that were part of the call stack. Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Eric Dong

Re: [edk2] [PATCH] ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib reference

On Wed, Nov 15, 2017 at 01:06:45PM +, Ard Biesheuvel wrote: > The PL031 driver implements a VExpress/Juno specific hack to set the > battery backed clock in addition to the PL031. However, none of the > remaining VExpress based hardware we support in EDK2 actuall implements > this feature so

Re: [edk2] [PATCH] EmbeddedPkg: add mx66u1g45g nor flash info

On 16 November 2017 at 16:24, Leif Lindholm wrote: > On Wed, Nov 15, 2017 at 11:19:32AM +, Ard Biesheuvel wrote: >> From: Pipat Methavanitpong >> >> Add Macronix MX66U1G45G definition to NorFlashInfoLib >> >> Contributed-under:

[edk2] [PATCH] ArmPlatformPkg ArmVirtPkg: reorganize PL011 code

The PL011 code in ArmPlatformPkg is organized in a weird way: there is a single PL011Uart.h header file under Include/Drivers containing both register definitions and function entry points. The PL011Uart library itself is in Drivers/ but it is actually a library. So let's clean this up: add a new

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

On 16 November 2017 at 15:07, Marcin Wojtas wrote: > Hi Ard, > > 2017-11-16 15:48 GMT+01:00 Ard Biesheuvel : >> On 16 November 2017 at 14:38, Marcin Wojtas wrote: >>> Hi Ard, >>> >>> With both PIE disabling patches for AARCH64,

Re: [edk2] [PATCH] ArmPkg: move RVCT PLATFORM_FLAGS override into ArmHvcLib/ArmSmcLib

On Thu, Nov 16, 2017 at 02:35:46PM +, Ard Biesheuvel wrote: > Currently, each ARM platform built with RVCT that uses ArmHvcLib > or ArmSmcLib needs to specify a CPU target that implements both the > security and virtualization extensions, so that the assembler does > not choke on the 'hvc' and

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

On 16 November 2017 at 15:31, Gao, Liming wrote: > Ard: > Does this error only happen on ACPI table compiling? But, I see -no-pie is > also in normal DLINK flag. Why is the driver not compiled failed? > The main difference is that the ACPI tables don't tolerate any

Re: [edk2] [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

Seemingly, the Memory Attributes Table should be consumed for memory protection. UEFI spec: "The Memory Attributes Table is currently used to describe memory protections that may be applied to the EFI Runtime code and data by an operating system or hypervisor." Someone (Jiewen?) familiar with

[edk2] [PATCH v6 0/2] Fix multiple entries of RT_CODE in memory map

> v6 > a. Add workaround in core to filter out all paging related capabilities. >This is to fix boot issue in Fedora 26 and Windows Server 2016. > b. Add code to check if EFI_MEMORY_XP should be added for GCD memory map More than one entry of RT_CODE memory might cause boot problem for some

[edk2] [PATCH 2/2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

> v6: >Add ExecuteDisable feature check to include/exclude EFI_MEMORY_XP > v5: >Coding style clean-up > v4: > a. Remove DoUpdate and check attributes mismatch all the time to avoid >a logic hole > b. Add warning message if failed to update capability > c. Add local variable to hold

[edk2] [PATCH] MdeModulePkg XhciPei: Minor refinement about IoMmu

1. Call IoMmuInit() after locating gPeiUsbControllerPpiGuid. 2. Call XhcPeiFreeSched() to do cleanup in XhcEndOfPei. Cc: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng ---

[edk2] [PATCH 1/1] BaseTools: Use VS2017 SDK path if defined and reorganize variables

1. The use of WindowsSdkVerBinPath allows us to access the latest SDK, which we will need when we introduce VS2017 support for AARCH64. 2. Make the breakdown between host and target more explicit, and more in line with how Microsoft reorganized the latest Visual Studio toolchains, by

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

Hi Ard, 2017-11-16 15:48 GMT+01:00 Ard Biesheuvel : > On 16 November 2017 at 14:38, Marcin Wojtas wrote: >> Hi Ard, >> >> With both PIE disabling patches for AARCH64, when compiling ACPI tables with >>

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

On 16 November 2017 at 14:38, Marcin Wojtas wrote: > Hi Ard, > > With both PIE disabling patches for AARCH64, when compiling ACPI tables with > gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- > I get following errors: > [...] > aarch64-linux-gnu-gcc:

Re: [edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

> On 16 Nov 2017, at 11:59, Leif Lindholm wrote: > >> On Thu, Nov 16, 2017 at 09:40:58AM +, Ard Biesheuvel wrote: >>> On 15 November 2017 at 14:03, Ard Biesheuvel >>> wrote: >>> Now that the PL031 RTC driver library no longer depends

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Change BIOS Version

Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Guo Mang --- Platform/BroxtonPlatformPkg/BiosId.env | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Platform/BroxtonPlatformPkg/BiosId.env b/Platform/BroxtonPlatformPkg/BiosId.env

Re: [edk2] [PATCH v2 0/4] UefiCpuPkg, OvmfPkg: add reset vector docs, tweak temp stack / RAM

Series Reviewed-by: Jordan Justen On 2017-11-15 13:56:59, Laszlo Ersek wrote: > Repo: https://github.com/lersek/edk2.git > Branch: temp_ram_tweaks_v2 > > This is a series for > > https://bugzilla.tianocore.org/show_bug.cgi?id=747 > > specifically an update on

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

Hi Ard, With both PIE disabling patches for AARCH64, when compiling ACPI tables with gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- I get following errors: [...] aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie' Do I understand correctly, that I

[edk2] [PATCH 0/1] Update for the 2017-10-18 VS2017 proposal

The following is a set of changes that I'd like to see applied to Liming's 2017-10-18 VS2017 support proposal for IA32 and X64. (See https://lists.01.org/pipermail/edk2-devel/2017-October/016175.html) Since I am planning to submit a v2 of my VS2017 ARM/AARCH64 proposal, that relies on these

Re: [edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

On 16 November 2017 at 12:34, Ard Biesheuvel wrote: > > >> On 16 Nov 2017, at 11:59, Leif Lindholm wrote: >> >>> On Thu, Nov 16, 2017 at 09:40:58AM +, Ard Biesheuvel wrote: On 15 November 2017 at 14:03, Ard Biesheuvel

Re: [edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

On Thu, Nov 16, 2017 at 09:40:58AM +, Ard Biesheuvel wrote: > On 15 November 2017 at 14:03, Ard Biesheuvel > wrote: > > Now that the PL031 RTC driver library no longer depends on the ARM > > platform specific ArmPlatformSysConfigLib, we no longer need to > >

[edk2] 答复: [RFC v3 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

Paulo, I don't understand why you - 1 when calculating EIP offset in image, it confused me. + for (;;) { +// +// Print stack frame in the following format: +// +// # @ + (RBP) in [ | ] +// +InternalPrintMessage ( + "%d 0x%016lx @ 0x%016lx+0x%x (0x%016lx) in

[edk2] [PATCH edk2-platforms v2 13/13] Platform: switch to new PL011UartLib

Switch to the new version of PL011UartLib which supersedes the one residing in Drivers/ inappropriately. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 2 +-

[edk2] [PATCH edk2-platforms v2 12/13] Platform: remove stale EBL related PCD setting

Remove all gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt assignments, which are no longer meaningful with EBL removed. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/ARM/JunoPkg/ArmJuno.dsc | 1 -

[edk2] [PATCH edk2-platforms v2 10/13] Platform: remove stale PL35xSmcLib references

No drivers actually use PL35xSmcLib so remove any resolutions for it. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 2 -- Silicon/Hisilicon/Hisilicon.dsc.inc | 2 -- 2

Re: [edk2] [PATCH 2/2] OvmfPkg: save on I/O port accesses when the debug port is not in use

On 11/16/17 11:47, Paolo Bonzini wrote: > When SEV is enabled, every debug message printed by OVMF to the > QEMU debug port traps from the guest to QEMU character by character > because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore, > when OVMF is built with the DEBUG_VERBOSE bit (value

Re: [edk2] [PATCH 1/2] OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC

On 11/16/17 11:47, Paolo Bonzini wrote: > The next patch will want to add a global variable to > PlatformDebugLibIoPort, but this is not suitable for the SEC > phase, because SEC runs from read-only flash. The solution is > to have two library instances, one for SEC and another > for all other

[edk2] [PATCH v2 0/2] ArmplatformPkg: clean up PL011 support library

Clean up the PL011 UART support library, by moving it into the appropriate place for libraries, and splitting the header file into an implementation and an interface part. Ard Biesheuvel (2): ArmPlatformPkg: reorganize PL011 code ArmVirtPkg: switch to new PL011UartLib implementation

[edk2] [PATCH v2 1/2] ArmPlatformPkg: reorganize PL011 code

The PL011 code in ArmPlatformPkg is organized in a weird way: there is a single PL011Uart.h header file under Include/Drivers containing both register definitions and function entry points. The PL011Uart library itself is in Drivers/ but it is actually a library. So let's clean this up: add a new

[edk2] [PATCH v2 2/2] ArmVirtPkg: switch to new PL011UartLib implementation

Switch to the new, cleaned up PL011UartLib implementation so we will be able to remove the old one. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/ArmVirt.dsc.inc| 2 +-

Re: [edk2] [PATCH] ArmPlatformPkg ArmVirtPkg: reorganize PL011 code

On Thu, Nov 16, 2017 at 05:38:10PM +, Ard Biesheuvel wrote: > On 16 November 2017 at 17:36, Leif Lindholm wrote: > > On Thu, Nov 16, 2017 at 05:12:16PM +, Ard Biesheuvel wrote: > >> The PL011 code in ArmPlatformPkg is organized in a weird way: there is > >> a

Re: [edk2] [PATCH] ArmPlatformPkg ArmVirtPkg: reorganize PL011 code

On Thu, Nov 16, 2017 at 05:12:16PM +, Ard Biesheuvel wrote: > The PL011 code in ArmPlatformPkg is organized in a weird way: there is > a single PL011Uart.h header file under Include/Drivers containing both > register definitions and function entry points. The PL011Uart library > itself is in

Re: [edk2] [PATCH] ArmPlatformPkg ArmVirtPkg: reorganize PL011 code

On 16 November 2017 at 17:36, Leif Lindholm wrote: > On Thu, Nov 16, 2017 at 05:12:16PM +, Ard Biesheuvel wrote: >> The PL011 code in ArmPlatformPkg is organized in a weird way: there is >> a single PL011Uart.h header file under Include/Drivers containing both >>

[edk2] [PATCH edk2-platforms v2 08/13] Platform/Hisilicon: remove SP804 PCD definitions

These platforms don't actually include the SP804 driver so no need to set the PCDs. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/Hisilicon/D02/Pv660D02.dsc | 8 Platform/Hisilicon/D03/D03.dsc | 8

[edk2] [PATCH edk2-platforms v2 02/13] Platform: remove bogus ArmTrustedMonitorLib references

Remove copy-pasted ArmTrustedMonitorLib library class resolutions that none of the platforms actually need. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 2 --

[edk2] [PATCH edk2-platforms v2 00/13] Move ArmPlatformPkg stuff into edk2-platforms

This is mostly a preparatory series that will allow us to get rid of a lot of code that is specific to only a single ARM development platform out of the main EDK2 tree. First of all, it removes a couple of false dependencies of various platforms on libraries that are no longer used, or not

[edk2] [PATCH edk2-platforms v2 01/13] Platform: remove bogus ArmPlatformSecExtraActionLib references

Remove copy-pasted ArmPlatformSecExtraActionLib library class resolutions that none of the platforms actually need. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/AMD/OverdriveBoard/OverdriveBoard.dsc |

Re: [edk2] [PATCH v2 0/2] ArmplatformPkg: clean up PL011 support library

On Thu, Nov 16, 2017 at 05:47:06PM +, Ard Biesheuvel wrote: > Clean up the PL011 UART support library, by moving it into the appropriate > place for libraries, and splitting the header file into an implementation > and an interface part. For the series: Reviewed-by: Leif Lindholm

Re: [edk2] [PATCH v2 2/2] ArmVirtPkg: switch to new PL011UartLib implementation

On 11/16/17 18:47, Ard Biesheuvel wrote: > Switch to the new, cleaned up PL011UartLib implementation so we will > be able to remove the old one. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- >

Re: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

Hi Brijan, On Thu, November 16, 2017 1:43 pm, Brian J. Johnson > > (These comments apply to patch 3/3 as well.) > > Typo: UnwondStacksCount should be UnwoundStacksCount Fixed in v3. Thanks! > > It's good to check the alignment of the stack, as you're doing. But > I'll reiterate that you

Re: [edk2] [PATCH v2 1/2] MdeModulePkg/PartitionDxe: Merge the discovery of ElTorito into UDF

On Thu, November 16, 2017 5:47 am, Hao Wu wrote: > In order to create all of the children (El Torito standard and UDF) for > a CD/DVD media in an entry of the PartitionDriverBindingStart(), this > commit merges the discovery of the El Torito feature > (PartitionInstallElToritoChildHandles) into

[edk2] [Patch] CryptoPkg/TlsLib: Change the return type of TlsInitialize().

Currently, in TlsInitialize(), neither the return status of OPENSSL_init_ssl(0, or 1) nor the return code of RandomSeed (TRUE or FALSE) is not checked. Also VOID is used as the return type of TlsInitialize(), which can't be used to capture the returned value for the error handling. >From Long Qin

[edk2] [Patch] BaseTools: Fix a bug for single module build with GenC/GenMake option

when build a single module with GenC/GenMake option, currently it will direct return after create Autogen code files, then it cause MaList is empty, which cause an incorrect error message is reported. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1

[edk2] [PATCH v2 0/2] OvmfPkg: save on I/O port accesses when the debug port is not in use

This is version 2 of the patch I sent yesterday, now with proper SEC support. The series makes OvmfPkg's PlatformDebugLibIoPort library skip I/O port writes when the debug port device wasn't added to the virtual machine. Patch 1 creates a separate PlatformDebugLibIoPort instance for SEC, so that

Re: [edk2] [Patch] MdeModulePkg/UsbMassStorageDxe: Enhance Request Sense Handling

Mike, Returning EFI_NOT_READY for USB_BOOT_ASC_NO_MEDIA seems a little confusing, but based on the real case, I am ok with the patch. Reviewed-by: Star Zeng Thanks, Star -Original Message- From: Kinney, Michael D Sent: Wednesday, November 15, 2017 9:28 AM To:

Re: [edk2] [Patch V3 2/2] MdeModulePkg/UsbMassStorageDxe: Check Get Max LUN status/value

Mike, After this patch, the return status of UsbBotGetMaxLun seems confusing and useless. Fortunately, there is no one using the return status of it. What do you think? Thanks, Star -Original Message- From: Kinney, Michael D Sent: Thursday, November 16, 2017 11:58 AM To:

[edk2] [PATCH edk2-platforms v2 07/13] Platform/ARM: remove outdated SP804 TimerLib reference

ArmVExpress.dsc.inc declares a TimerLib dependency and resolves it using ArmPlatformPkg/Library/SP804TimerLib/SP804TimerLib.inf, but all users of the include file supersede it with ArmArchTimerLib.inf so let's just use that instead. Contributed-under: TianoCore Contribution Agreement 1.1

[edk2] [PATCH edk2-platforms v2 05/13] Platform/ARM/Juno: import ArmJunoPkg from EDK2

Move ArmJunoPkg into edk2-platforms, so it can be removed from the main EDK2 tree. This allows use to remove the dodgy -I arguments to GCC to build shared modules with a different copy of ArmPlatform.h, which was making it very difficult to properly split the various modules into their own

[edk2] [PATCH edk2-platforms v2 04/13] Platform/Hisilicon: remove bogus VExpress dependencies

Remove false copy-pasted dependencies on various VExpress support libraries. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/Hisilicon/D02/Pv660D02.dsc | 3 --- Platform/Hisilicon/D03/D03.dsc | 5 -

[edk2] [PATCH edk2-platforms v2 09/13] Platform: remove references to EBL libraries

None of these platforms still include EBL, but some references remained to its support libraries. Get rid of that. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 6 --

[edk2] [PATCH edk2-platforms v2 03/13] Platform/ArmVExpress-FVP: remove bogus ArmPlatformSecLib reference

No FVP driver uses this library so remove the resolution. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 1 - 1 file changed, 1 deletion(-) diff --git

[edk2] [PATCH v3 3/3] OvmfPkg: save on I/O port accesses when the debug port is not in use

When SEV is enabled, every debug message printed by OVMF to the QEMU debug port traps from the guest to QEMU character by character because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore, when OVMF is built with the DEBUG_VERBOSE bit (value 0x0040) enabled in

Re: [edk2] EDK2 build issues

Hi Liming, I chatted with Aaron on the phone today. The VfrCompiler race condition was discovered using "make -j " (where n > 1). I have filed the bug in Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=786 For the ARCH environment variable, we brainstormed two possible new names

Re: [edk2] [PATCH] OvmfPkg/XenHypercallLib: enable virt extensions for ARM

On 11/16/17 17:56, Ard Biesheuvel wrote: > XenHypercallLib uses the 'hvc' instruction, which is not implemented > on all ARMv7 CPUs, and so we need to explicitly specify a CPU that > has the virtualization extensions. > > This override used to be set at the platform level, but this was removed >

[edk2] [RFC v3 0/3] Stack trace support in X64 exception handling

Hi, This series adds stack trace support during a X64 CPU exception. Informations like back trace, stack contents and image module names (that were part of the call stack) will be dumped out. We already have such support in ARM/AArch64 (IIRC) exception handling (thanks to Ard), and then I

[edk2] [RFC v3 3/3] UefiCpuPkg/CpuExceptionHandlerLib/Ia32: Add stack trace support

This patch adds stack trace support during a IA32 CPU exception. It will dump out back trace, stack contents as well as image module names that were part of the call stack. Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Eric Dong Cc: Laszlo Ersek

Re: [edk2] [RFC v2 0/3] Stack trace support in X64 exception handling

Hi Andrew, On Thu, November 16, 2017 3:01 am, Andrew Fish wrote: > Paulo, > > Those attached stack traces don't look right. What about the new ones? Thanks! Paulo > > Thanks, > > Andrew Fish > >> On Nov 15, 2017, at 5:46 PM, Paulo Alcantara wrote: >> >> Hi, >> >> On

[edk2] [PATCH v3 2/3] OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC

The next patch will want to add a global variable to PlatformDebugLibIoPort, but this is not suitable for the SEC phase, because SEC runs from read-only flash. The solution is to have two library instances, one for SEC and another for all other firmware phases. This patch adds the "plumbing" for

[edk2] [PATCH v3 0/3] OvmfPkg: save on I/O port accesses when the debug port is not in use

This is version 3 of the series to skip debug port I/O port writes when the debug port device wasn't added to the virtual machine. The differences from v2 are entirely cosmetic, and I'm including them at the end of this message for ease of review. Thanks, Paolo Paolo Bonzini (3): OvmfPkg:

[edk2] [PATCH v3 1/3] OvmfPkg: make PlatformDebugLibIoPort a proper BASE library

Remove Uefi.h, which includes UefiSpec.h, and change the return value to match the RETURN_STATUS type. Contributed-under: TianoCore Contribution Agreement 1.1 Tested-by: Laszlo Ersek Cc: Laszlo Ersek Cc: Ard Biesheuvel Cc: Jordan

[edk2] [RFC v3 2/3] UefiCpuPkg/CpuExceptionHandlerLib: Export GetPdbFileName()

This function will be used by both IA32 and X64 exception handling in order to print out image module names during stack unwinding. Cc: Eric Dong Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Paulo Alcantara

[edk2] [RFC v3 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

This patch adds stack trace support during a X64 CPU exception. It will dump out back trace, stack contents as well as image module names that were part of the call stack. Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Eric Dong Cc: Laszlo Ersek

Re: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

Hi Jiewen, On Wed, November 15, 2017 11:57 pm, Yao, Jiewen wrote: > Hi Paulo > Thanks to bring this cool feature. > > I have same feeling as Jeff Fan. It is great! > > I have some questions, hope you can clarify. > 1) Would you please let us know which tool change is validated? Such as > MSVC, or

[edk2] SCT Test crashes After HTTPS boot success.

Hello All, When I do SCT test, get the below failure GenericTest\EFICompliantTest 0 0 CB6F7B77-0B15-43F7-A95B-8C7F9FD70B21 FAIL UEFI Compliant - TLS support is required The reason for the failure is that the platform doesn't have TLS related protocols installed. ->if the platform supports TLS

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

HI I have 2 comments: 1) I do not think we need mention: WORKAROUND. I suggest we just use "NOTE". We have similar example before, see MdePkg\Library\BasePeCoffLib\BasePeCoff.c // // NOTE: Some versions of Linux ELILO for Itanium have an incorrect magic value // in the PE/COFF

Re: [edk2] SCT Test crashes After HTTPS boot success.

Hi Karunakar, Can you provide more detailed info for the SCT test steps? The crash can happen after "Sct.efi -u" or need run any specific test case? Thanks, Jiaxin From: Karunakar P [mailto:karunak...@amiindia.co.in] Sent: Thursday, November 16, 2017 4:48 PM To: 'edk2-devel@lists.01.org'

Re: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu

How about calling IoMmuInit () after locating gEdkiiPeiUfsHostControllerPpiGuid? Same comment to SdBlockIoPei and EmmcBlockIoPei. If you agree, Reviewed-by: Star Zeng Thanks, Star -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On

[edk2] [PATCH 1/2] OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC

The next patch will want to add a global variable to PlatformDebugLibIoPort, but this is not suitable for the SEC phase, because SEC runs from read-only flash. The solution is to have two library instances, one for SEC and another for all other firmware phases. This patch adds the "plumbing" for

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

1) Sure. I'll update the wording. 2) I still think this is just a workaround . In the long run, I don't think the merge is a good idea. It looks like it will "fix" more issues, but actually it just "hide" them and would cause more and more workaround in the future. Anyway, if no one else has

Re: [edk2] [PATCH v6 3/7] UefiCpuPkg/CpuDxe: Reduce debug message

I agree. Thanks for the comment. > -Original Message- > From: Zeng, Star > Sent: Friday, November 17, 2017 10:31 AM > To: Wang, Jian J ; edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Dong, Eric ; > Zeng, Star

Re: [edk2] [PATCH V2] MdeModulePkg EhciPei: Support IoMmu

Reviewed-by: jiewen@intel.com > -Original Message- > From: Zeng, Star > Sent: Thursday, November 16, 2017 6:03 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Yao, Jiewen > Subject: [PATCH V2] MdeModulePkg EhciPei: Support IoMmu > > V2:

Re: [edk2] [PATCH v6 3/7] UefiCpuPkg/CpuDxe: Reduce debug message

According to the definitions, DEBUG_POOL and DEBUG_PAGE are for alloc & free pool/page. #define DEBUG_POOL 0x0010 // Alloc & Free (pool) #define DEBUG_PAGE 0x0020 // Alloc & Free (page) How about changing the debug level to DEBUG_VERBOSE? If you agree, you do not need send a

Re: [edk2] [PATCH] MdeModulePkg XhciPei: Minor refinement about IoMmu

Reviewed-by: jiewen@intel.com > -Original Message- > From: Zeng, Star > Sent: Thursday, November 16, 2017 6:45 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Yao, Jiewen > Subject: [PATCH] MdeModulePkg XhciPei: Minor refinement about

Re: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu

> -Original Message- > From: Zeng, Star > Sent: Thursday, November 16, 2017 6:38 PM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Wu, Hao A; Yao, Jiewen; Zeng, Star > Subject: RE: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu > > How about calling IoMmuInit () after

Re: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu

Yes, same comments to SD/eMMC series. Thanks, Star -Original Message- From: Wu, Hao A Sent: Friday, November 17, 2017 10:37 AM To: Zeng, Star ; edk2-devel@lists.01.org Cc: Yao, Jiewen Subject: RE: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei:

Re: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

Thanks for your reply. Comments below: > -Original Message- > From: Paulo Alcantara [mailto:pca...@zytor.com] > Sent: Friday, November 17, 2017 6:13 AM > To: Yao, Jiewen > Cc: Paulo Alcantara ; edk2-devel@lists.01.org; Laszlo Ersek >

Re: [edk2] SCT Test crashes After HTTPS boot success.

Hi Jiaxin, Below are the detailed steps for SCT test [Steps to reproduce] . 5. Run SCT test a. Execute the following commands to run SCT test on SUT sct -r sct -u b. In Test Case Management page, Enable GenericTest c. Press F9 to run the selected test case

Re: [edk2] SCT Test crashes After HTTPS boot success.

I will try to reproduce the issue with EDK2 trunk code, then feedback to you. Thanks the report. Jiaxin From: Karunakar P [mailto:karunak...@amiindia.co.in] Sent: Friday, November 17, 2017 2:32 PM To: Wu, Jiaxin ; 'edk2-devel@lists.01.org' Cc: Fu,

[edk2] [Patch v2] CryptoPkg/TlsLib: Change the return type of TlsInitialize().

V2: * Correct the commit log. Currently, the return code of OPENSSL_init_ssl(0 or 1) and RandomSeed (TRUE or FALSE) are not checked in TlsInitialize(). Also "VOID" is used as the return type of TlsInitialize(), which can't be used to capture the returned value for error handling. >From Long Qin

Re: [edk2] [PATCH v2 3/4] OvmfPkg/Sec/X64: seed the temporary RAM with PcdInitValueInTempStack

On 15 November 2017 at 21:57, Laszlo Ersek wrote: > This allows the PEI core to report the maximum temporary SEC/PEI stack > usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function > [MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]: > > * Normal boot: > >> Temp

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

As I remember UEFI 2.5 clarified this and added EFI_MEMORY_RO was because EFI_MEMORY_WP had been typically used for cache even before UEFI 2.5. And I do not think this patch should filter out EFI_MEMORY_WP since this patch is to filter out new paging bits caused by

[edk2] [Patch] BaseTools: Guid.xref contain information from FILE statements in FDF

Update Guid.xref to contain information from FILE statements in FDF file. Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=778 Cc: Liming Gao Cc: Dmitry Antipov Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yonghong Zhu

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

On 16 November 2017 at 07:26, Jian J Wang wrote: > Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really > set attributes and change memory paging attribute accordingly. > But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by > value from Capabilities in GCD

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

Ard, EFI_MEMORY_WP is for cache. UefiSpec.h // // Note: UEFI spec 2.5 and following: use EFI_MEMORY_RO as write-protected physical memory // protection attribute. Also, EFI_MEMORY_WP means cacheability attribute. // #define EFI_MEMORY_WP 0x1000ULL Thanks, Star

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

On 16 November 2017 at 09:28, Zeng, Star wrote: > Ard, > > EFI_MEMORY_WP is for cache. > > UefiSpec.h > // > // Note: UEFI spec 2.5 and following: use EFI_MEMORY_RO as write-protected > physical memory > // protection attribute. Also, EFI_MEMORY_WP means cacheability

Re: [edk2] [PATCH v2 1/4] UefiCpuPkg/ResetVector/Vtf0: document segment register setup

On 15 November 2017 at 21:57, Laszlo Ersek wrote: > "Main.asm" calls TransitionFromReal16To32BitFlat (and does some other > things) before it jumps to the platform's SEC entry point. > > TransitionFromReal16To32BitFlat enters big real mode, and sets the DS, ES, > FS, GS, and SS

Re: [edk2] [PATCH v2 2/4] OvmfPkg/Sec/Ia32: seed the temporary RAM with PcdInitValueInTempStack

On 15 November 2017 at 21:57, Laszlo Ersek wrote: > This allows the PEI core to report the maximum temporary SEC/PEI stack > usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function > [MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]: > > * Normal boot: > >> Temp

Re: [edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

On 15 November 2017 at 14:03, Ard Biesheuvel wrote: > Now that the PL031 RTC driver library no longer depends on the ARM > platform specific ArmPlatformSysConfigLib, we no longer need to > implement ArmPlatform.h or have a resolution for that library. > This allows us

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: use non-accelerated CopyMem for VariableRuntimeDxe

On 16 November 2017 at 01:01, Shannon Zhao wrote: > > > On 2017/11/15 22:03, Ard Biesheuvel wrote: >> On 15 November 2017 at 13:51, Laszlo Ersek wrote: >>> > On 11/14/17 11:22, Ard Biesheuvel wrote: >> The VariableRuntimeDxe driver may use

  1   2   >