Re: [edk2] [PATCH v3 2/4] IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed

On 02/23/16 16:09, Yao, Jiewen wrote: > Ok, thanks for clarification. > > > > I just answer the last question below: > > -How does the Conclusion follow from Premises 1 through 4? What > guarantees it? > > > > - Premise 1: > OVMF installs memory that is >= 4GB as an untested

[edk2] [PATCH v4 1/2] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

AARCH64 systems never require compatibility with legacy ACPI OSes, and may not have any 32-bit addressable system RAM. To support ACPI on these systems, we need to be able to relax the 4 GB allocation restriction. So add a PCD PcdAcpiExposedTableVersions containing a bitmask describing which ACPI

Re: [edk2] [PATCH v3 2/4] IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed

On 23 February 2016 at 17:06, Laszlo Ersek wrote: [supersnip] > By that I don't mean *another* new PCD, beyond the ACPI version PCD that > Ard's patch series already contains -- I mean a more generic PCD that > *replaces* the ACPI version PCD, and controls the allocations

Re: [edk2] [PATCH v3 2/4] IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed

On 02/23/16 17:47, Ard Biesheuvel wrote: > On 23 February 2016 at 17:06, Laszlo Ersek wrote: > [supersnip] >> By that I don't mean *another* new PCD, beyond the ACPI version PCD that >> Ard's patch series already contains -- I mean a more generic PCD that >> *replaces* the ACPI

[edk2] [Patch 3/4] MdeModulePkg/Bds: Support short-form URI boot.

The patch adds short-form URI boot support to follow UEFI Spec. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Siyuan Fu --- MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 72 1 file

[edk2] [PATCH v4 2/2] ArmVirtPkg/ArmVirtQemu: limit ACPI support to v5.0 and higher

The ACPI spec predates the AARCH64 architecture by 5 versions, so there is no point in supporting anything below v5.0. So set the PCD that controls the ACPI table generation to the appropriate value. Note that the current consumers of this PCD only check whether bit 1 is set or not (i.e., ACPI

Re: [edk2] [patch] MdeModulePkg: Make HII configuration settings available to OS runtime

On 02/22/2016 09:00 PM, Dong, Eric wrote: Hi All, Thanks for your comments. I add my explanation below: Only hook ReadyToBoot event is not enough. Different drivers may hook this event and some may update string package in their callback function. The order to call these callback functions

[edk2] [Patch v2 1/2] UefiCpuPkg/Cpuid.h: Add CPUID leaf/sub-leaf defines and structures

Add CPUID leaf and sub-leaf indexes and structures as described by Intel(R) 64 and IA-32 Architectures Software Developer's Manual, Volume 2A, December 2015, CPUID instruction. Cc: Jeff Fan Cc: Jiewen Yao Contributed-under: TianoCore Contribution

[edk2] [Patch v2 2/2] UefiCpuPkg/Cpuid: Add UEFI CPUID application

Add UEFI application to UefiCpuPkg to display all supported CPUID leafs and sub-leafs described by UefiCpuPkg/Include/Register/Cpuid.h that is based on information from Intel(R) 64 and IA-32 Architectures Software Developer's Manual, Volume 2A, December 2015, CPUID instruction. Cc: Jeff Fan

[edk2] [Patch v2 0/2] UefiCpuPkg: Update CPUID include file and add CPUID app

This patch series updates the Cpuid.h file in UefiCpuPkg to describe all CPUID leafs and sub-leafs. It also adds a UEFI CPUID application that tests the updated Cpuid.h file by displaying all the CPUID leafs and sub-leafs. Michael Kinney (2): UefiCpuPkg/Cpuid.h: Add CPUID leaf/sub-leaf

Re: [edk2] [patch] MdeModulePkg: Make HII configuration settings available to OS runtime

Even with a single export @ ReadyToBoot, I still think we need a PCD to allow implementations to disable the feature altogether if they decide to. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Brian J. Johnson Sent: Tuesday, February 23,

[edk2] [PATCH v4 0/2] lift AARCH64 4GB allocation restriction

On AARCH64, there is no requirement to support OSes that can only access ACPI tables in low memory (i.e., below 4 GB), and there are reasons to prefer allocations higher up. First of all, since DMA capable devices may only be able to access 32-bit addressable memory, we may prefer to reserve low

Re: [edk2] [PATCH] ArmPkg: AArch64 exception handling init configures HCR in EL2

> > + if (ArmReadCurrentEL() == AARCH64_EL2) { > > +HcrReg = ArmReadHcr(); > > + > > +// set AMO, IMO, and FMO so all available async exceptions go to EL2 > > +// (EL3 takes precedence over this and may choose to own FIQ > regardless) > > +HcrReg |= (ARM_HCR_FMO | ARM_HCR_IMO |

Re: [edk2] [PATCH v3 1/4] MdeModulePkg: AcpiTableDxe: make 4 GB table allocation limit optional

On 23 February 2016 at 04:03, Zeng, Star wrote: > Ard, > > On 2016/2/19 21:15, Ard Biesheuvel wrote: >> >> AARCH64 systems never require compatibility with legacy ACPI OSes, and >> may not have any 32-bit addressable system RAM. To support ACPI on these >> systems, we need to

Re: [edk2] [PATCH] MdePkg: Fix AArch64 DAIF interrupt mask definitions

On 23 February 2016 at 08:21, Ard Biesheuvel wrote: > (+ Liming) > > On 22 February 2016 at 22:59, Cohen, Eugene wrote: >> The AArch64 DAIF bits are different for reading (mrs) versus writing (msr). >> The bitmask definitions assumed they were the same

Re: [edk2] Using PCD to set default policy for IPv4/IPv6

+ Sriram and Nagaraj > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Wu, Jiaxin > Sent: Tuesday, February 23, 2016 3:44 PM > To: El-Haj-Mahmoud, Samer ; Kinney, > Michael D > Cc:

Re: [edk2] [PATCH 1/1] OvmfPkg: VirtioFlush(): return the number of bytes written by the host

Reviewed-by: Jordan Justen On 2016-02-19 09:15:07, Laszlo Ersek wrote: > VirtioLib provides an API for simple, synchronous (request/response-style) > virtio communication. The guest driver builds one descriptor chain, link > for link, with VirtioPrepare() and

Re: [edk2] Using PCD to set default policy for IPv4/IPv6

Hi Sriram, As we know the git version '3d0a49ad' commit provided a scenario to resolved the performance issue for IPv4, but it's not workable for IPv6 (The reason we discussed before). To avoid IPv4 and IPv6 inconsistency, we decided to revert that version fix. Assume we revert the git

Re: [edk2] [Patch v2 2/2] UefiCpuPkg/Cpuid: Add UEFI CPUID application

Reviewed-by: Jeff Fan -Original Message- From: Kinney, Michael D Sent: Wednesday, February 24, 2016 2:00 AM To: edk2-devel@lists.01.org Cc: Fan, Jeff; Yao, Jiewen Subject: [Patch v2 2/2] UefiCpuPkg/Cpuid: Add UEFI CPUID application Add UEFI application to UefiCpuPkg

Re: [edk2] [PATCH] MdeModulePkg: Add HttpUtilLib

Hi, Samer After the review we think it's ok to put these interfaces to the existing HttpLib and it could be extend in future if necessary. And there should be a patch to update HttpDxe, HttpUtilityDxe and HttpBootDxe drivers to consume the new library interfaces. Could you please recreate a

Re: [edk2] [PATCH v3 2/4] IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed

Yes. ACPI1.0 below 4G limitation is defined in ACPI spec, clearly. OVMF X64 PEI has 4G limitation is OVMF implementation choice. Other platform *may* choose 2G, or 8G, or 0~1G+4G+5G. I hope PI specification can give us some guidance on how to handle that. Thanks to raise this and we will

Re: [edk2] [Patch V4 4/4] MdeModulePkg: Add generic PciHostBridgeDxe driver.

Laszlo, PciBus summarize all the resource requirements for a root bridge, and submit the resource requirement summary to PciHostBridge driver. So the allocations occur for each root bridge, but not for each BAR. For the Add[Io/Memory]Space operations, I see two options: 1. A flag to tell

Re: [edk2] [Patch v2 1/2] UefiCpuPkg/Cpuid.h: Add CPUID leaf/sub-leaf defines and structures

Reviewed-by: Jeff Fan -Original Message- From: Kinney, Michael D Sent: Wednesday, February 24, 2016 2:00 AM To: edk2-devel@lists.01.org Cc: Fan, Jeff; Yao, Jiewen Subject: [Patch v2 1/2] UefiCpuPkg/Cpuid.h: Add CPUID leaf/sub-leaf defines and structures Add CPUID

Re: [edk2] [Patch] MdePkg: Add definition for new warning code EFI_WARN_FILE_SYSTEM.

Reviewed-by: Liming Gao -Original Message- From: Fu, Siyuan Sent: Wednesday, February 24, 2016 11:43 AM To: edk2-devel@lists.01.org Cc: Gao, Liming ; Ye, Ting Subject: [Patch] MdePkg: Add definition for new warning code

Re: [edk2] Using PCD to set default policy for IPv4/IPv6

I would prefer to keep it simple and so go with solution2. Thanks, Sriram. -Original Message- From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Wednesday, February 24, 2016 7:06 AM To: Subramanian, Sriram (EG Servers Platform SW); El-Haj-Mahmoud, Samer; Kinney, Michael D Cc: Zimmer,

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

Hi Ard Liming gave me minor update comment, and I have finished V3. Should I wait for your validation on AArch64? Thank you Yao Jiewen -Original Message- From: Gao, Liming Sent: Tuesday, February 23, 2016 1:10 PM To: Yao, Jiewen; edk2-de...@ml01.01.org Cc: Ard Biesheuvel Subject: RE:

Re: [edk2] [PATCH] MdeModulePkg: Add HttpUtilLib

Thanks Siyuan. I agree that these functions should be part of HttpLib. I have created a new HttpUtilLib just because I felt there may be resistance to adding them to HttpLib. I will submit a new patch of moving these to HttpLib and updating the drivers to consume. Thanks, --Samer

[edk2] [Patch] MdePkg: Add definition for new warning code EFI_WARN_FILE_SYSTEM.

Add the definition for the new return status code defined in UEFI 2.6. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan Cc: Liming Gao Cc: Ye Ting --- MdePkg/Include/Base.h | 6 ++

Re: [edk2] [Patch] CryptoPkg/OpensslLib: Upgrade OpenSSL version to 1.0.2f

On 02/19/16 10:43, Laszlo Ersek wrote: > On 02/19/16 09:59, David Woodhouse wrote: >> On Fri, 2016-02-19 at 07:59 +, Long, Qin wrote: >>> I agree those changes really make sense for better alignment, under >>> both 1.0.2xx and 1.1 HEAD. The final out-of-box support will be >>> wonderful. >>>

Re: [edk2] Using PCD to set default policy for IPv4/IPv6

Hi Jiaxin, For (1), what is the proposed design? Should the driver implemented by the platform do a RegisterProtocolNotify() for gEfiIp4Config2ProtocolGuid/gEfiIp6ConfigProtocolGuid and set the policy for each instance in the system? What happens if this driver doesn't exist, or doesn't set

Re: [edk2] [PATCH v3 2/4] IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed

Ok, thanks for clarification. I just answer the last question below: -How does the Conclusion follow from Premises 1 through 4? What guarantees it? - Premise 1: OVMF installs memory that is >= 4GB as an untested memory resource descriptor HOB. - Premise 2: OVMF creates a memory type

Re: [edk2] [PATCH] MdePkg: Fix AArch64 DAIF interrupt mask definitions

> > -csel w0, w1, w0, ne > > +csel w0, w1, w0, eq // if Z=1 (eq) return 1, else 0 > > Again, could we replace these three instructions with 'cinc w0, wzr, eq' while > we're at it? No objections here - I'm new to these conditional selection instructions. My preference is for

Re: [edk2] [PATCH v3 2/4] IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed

On 02/23/16 14:39, Yao, Jiewen wrote: > Understood. I think the 4G for PEI x64 makes sense. Thanks! > I checked OVMF code. In OvmfPkg\PlatformPei\Platform.c(44) > > EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = { > > { EfiACPIMemoryNVS, 0x004 }, > > {

Re: [edk2] [PATCH v3 2/4] IntelFrameworkModulePkg: BdsDxe: only allocate below 4 GB if needed

On 02/23/16 15:06, Yao, Jiewen wrote: > Yes, thanks to point out this. > > > > Now I am thinking the problem becomes much broader. > > For example, do we need support a platform only set 2G page table in PEI > phase? Or 1G? > > Or do we need support a platform only set 0~1G and 3G~4G page

Re: [edk2] [PATCH v4 0/2] Enhance Shell to support finding help message embeded in resource section.

Reviewed-by: Jaben Carsey > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Qiu > Shumin > Sent: Monday, February 22, 2016 11:01 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v4 0/2] Enhance Shell to support