[edk2] [Patch] MdeModulePkg BootManagerMenuApp: Update usage info for BootLogo protocol

BootLogo protocol is not always required. If it is installed, BootManagerMenuApp can work. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao Cc: Ruiyu Ni --- MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf | 4 ++-- 1 file changed, 2

Re: [edk2] [PATCH] OvmfPkg: raise DXEFV size to 11 MB

Laszlo: OvmfPkgIa32.fdf, OvmfPkgX64.fdf and OvmfPkgIa32X64.fdf are almost same. I suggest to use the single FDF for them. If so, this change is only made once. For X64 only module in FDF, we can use below style to include it. !if $(E1000_ENABLE) && "X64" in $(ARCH) FILE DRIVER =

Re: [edk2] smm lock query

Thanks, Jiewen and Star. I was able to figure out that smrr was preventing me from accessing the contents of smram. It seems to me that this violates the EFI_MM_ACCESS_PROTOCOL protocol. I have talked to the edk2-platform maintainers about this on a private thread, but, of course, I may be

[edk2] [Patch] OvmfPkg BasePciCapLib: Fix VS build failure

Fix VS warning C4244: 'function': conversion from 'UINT32' to 'UINT16', possible loss of data. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao Cc: Laszlo Ersek --- OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [edk2] smm lock query

Let me share my thought. 1) From interface point of view, ReadyToLock means it is the last time to lock. But it does not mean it must be open before. As implementation choice, a platform MAY lock it earlier. Also SMRR may force the SMRAM invisible to outside SMRAM, even with D_OPEN set.

Re: [edk2] [PATCH v3 5/5] MdeModulePkg/FirmwarePerformanceDataTableDxe: use AllocatePeiAccessiblePages

Reviewed-by: Star Zeng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Monday, May 28, 2018 10:40 PM To: edk2-devel@lists.01.org Cc: Ard Biesheuvel Subject: [edk2] [PATCH v3 5/5]

Re: [edk2] [PATCH v3 3/5] MdePkg/DxeServicesLib: introduce AllocatePeiAccessiblePages routine

I think " be accessible by PEI after a warm reboot " should be " be accessible by PEI after resuming from S3 ". You can update it when pushing without need to send a new patch if other has no comment to the code part. Thanks, Star -Original Message- From: edk2-devel

Re: [edk2] [Patch] SecurityPkg/Tcg2Smm: Correct function parameter attribute

Reviewed-by: Long Qin Best Regards & Thanks, LONG, Qin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Zhang, Chao B > Sent: Monday, May 28, 2018 10:10 PM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Long, Qin > Subject: [edk2]

Re: [edk2] smm lock query

I do not see issue according to the spec. Platform should know when to signal DxeSmmReadyToLock (after EndOfDxe). DxeSmmReadyToLock event is to notify DXE handlers. Modules are responsible to lock or protect their resource and effect the appropriate protections in their notification handlers.

Re: [edk2] [PATCH v3 3/5] MdePkg/DxeServicesLib: introduce AllocatePeiAccessiblePages routine

The patch is good to me. Reviewed-by: Liming Gao >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >Laszlo Ersek >Sent: Monday, May 28, 2018 11:00 PM >To: Ard Biesheuvel ; edk2-devel@lists.01.org >Subject: Re: [edk2] [PATCH v3 3/5]

Re: [edk2] [PATCH v3 4/5] MdeModulePkg/DxeCorePerformanceLib: use AllocatePeiAccessiblePages

Reviewed-by: Star Zeng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Monday, May 28, 2018 10:40 PM To: edk2-devel@lists.01.org Cc: Ard Biesheuvel Subject: [edk2] [PATCH v3 4/5] MdeModulePkg/DxeCorePerformanceLib: use

Re: [edk2] [PATCH] CryptoPkg: Remove deprecated function usage in X509GetCommonName()

Reviewed-by: Ye Ting -Original Message- From: Long, Qin Sent: Thursday, May 24, 2018 4:11 PM To: edk2-devel@lists.01.org Cc: Ye, Ting ; michael.tur...@microsoft.com Subject: [PATCH] CryptoPkg: Remove deprecated function usage in X509GetCommonName() BZ#:

Re: [edk2] [Patch 0/3] Use comparison logic to check UINTN parameter in GetBestLanguage API

Marvin: Current solution is to keep max compatibility. Thanks Liming >-Original Message- >From: Marvin H?user [mailto:marvin.haeu...@outlook.com] >Sent: Monday, May 28, 2018 4:11 PM >To: edk2-devel@lists.01.org >Cc: Zeng, Star ; Gao, Liming >Subject: RE: [edk2] [Patch 0/3] Use

Re: [edk2] [Patch 0/5] Remove X86 ASM and S files

Mike: This patch serials remove ASM from libraries, and keep S files in Libraries until new NASM is updated. I understand only S file optimization feature depends on NASM file. Right? Yes. I will update the patch to update copyright to 2018. Thanks Liming >-Original Message-

Re: [edk2] [PATCH] OvmfPkg: raise DXEFV size to 11 MB

On Mon, May 28, 2018 at 08:49:56PM +0200, Laszlo Ersek wrote: > Almost exactly two years after commit 2f7b34b20842f, we've grown out the > 10MB DXEFV: > > > build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -b NOOPT -t GCC48 \ > > -D SMM_REQUIRE -D SECURE_BOOT_ENABLE -D TLS_ENABLE -D

Re: [edk2] [Patch 0/5] Remove X86 ASM and S files

Liming, This patch series includes removal of ASM and S files from libraries. Should those be removes from this series until NASM is updated? I also see updates to INF files without updates to the Copyright. Thanks, Mike > -Original Message- > From: edk2-devel [mailto:edk2-devel- >

Re: [edk2] PciSegmentInfoLib instances

Of all the gin joints in all the towns in all the world, Ni, Ruiyu had to walk into mine at 19:55 on Sunday 27 May 2018 and say: > No. There is no such instance. > > My understanding: > Segment is just to separate the PCI devices to different groups. > Each group of devices use the continuous

[edk2] [edk2-platforms Patch v4 4/6] Styx/PlatformFlashAccessLib: Add progress API

From: "Kinney, Michael D" https://bugzilla.tianocore.org/show_bug.cgi?id=801 Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib. This allows the platform to inform the user of progress when a firmware storage device is being updated with a new firmware image. This is the minimal

[edk2] [edk2-platforms Patch v4 1/6] AMD/OverdriveBoard: Add DisplayUpdateProgressLib mapping

From: "Kinney, Michael D" https://bugzilla.tianocore.org/show_bug.cgi?id=801 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport Cc: Ard Biesheuvel Cc: Leif Lindholm Signed-off-by: Michael D Kinney Contributed-under: TianoCore

[edk2] [edk2-platforms Patch v4 0/6] Add DisplayUpdateProgressLib to platforms

https://bugzilla.tianocore.org/show_bug.cgi?id=801 Based on content from: https://github.com/Microsoft/MS_UEFI/blob/share/MsCapsuleSupport/MsCapsuleUpdatePkg/Include/Library/DisplayUpdateProgressLib.h

[edk2] [edk2-platforms Patch v4 5/6] Hisilicon/PlatformFlashAccessLib: Add progress API

From: "Kinney, Michael D" https://bugzilla.tianocore.org/show_bug.cgi?id=801 Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib. This allows the platform to inform the user of progress when a firmware storage device is being updated with a new firmware image. This is the minimal

[edk2] [edk2-platforms Patch v4 6/6] SynQuacer/PlatformFlashAccessLib: Add progress API

From: "Kinney, Michael D" https://bugzilla.tianocore.org/show_bug.cgi?id=801 Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib. This allows the platform to inform the user of progress when a firmware storage device is being updated with a new firmware image. This is the minimal

[edk2] [edk2-platforms Patch v4 3/6] Socionext/SynQuacerEvalBoard: Add DisplayUpdateProgressLib mapping

From: "Kinney, Michael D" https://bugzilla.tianocore.org/show_bug.cgi?id=801 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport Cc: Ard Biesheuvel Cc: Leif Lindholm Signed-off-by: Michael D Kinney Contributed-under: TianoCore

[edk2] [edk2-platforms Patch v4 2/6] Socionext/DeveloperBox: Add DisplayUpdateProgressLib mapping

From: "Kinney, Michael D" https://bugzilla.tianocore.org/show_bug.cgi?id=801 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport Cc: Ard Biesheuvel Cc: Leif Lindholm Signed-off-by: Michael D Kinney Contributed-under: TianoCore

Re: [edk2] [Patch] SecurityPkg/Tcg2Smm: Correct function parameter attribute

Reviewed-by: jiewen@intel.com > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang, > Chao B > Sent: Monday, May 28, 2018 7:10 AM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Long, Qin > Subject: [edk2] [Patch] SecurityPkg/Tcg2Smm:

Re: [edk2] [Patch v3 3/3] SignedCapsulePkg/PlatformFlashAccessLib: Add progress API

Reviewed-by: jiewen@intel.com > -Original Message- > From: Kinney, Michael D > Sent: Thursday, May 24, 2018 11:16 PM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen > Subject: [Patch v3 3/3] SignedCapsulePkg/PlatformFlashAccessLib: Add progress > API > >

Re: [edk2] [Patch v3 3/4] QuarkPlatformPkg: Add DisplayUpdateProgressLib mapping

Reviewed-by: jiewen@intel.com > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Michael D Kinney > Sent: Thursday, May 24, 2018 11:23 PM > To: edk2-devel@lists.01.org > Cc: Kinney, Michael D > Subject: [edk2] [Patch v3 3/4]

Re: [edk2] smm lock query

Thank you everyone for your inputs and clarifications. They are helping me to better understand the uefi code, to which I am very new. I do not mean to hijack the thread: so please continue your discussions about whether the implementation matches the spec. However, I want to state why I am

Re: [edk2] [Patch v3 0/3] Add DisplayUpdateProgressLib for capsules

Thank you to add Version. Patch 1,2,3,4 reviewed-by: jiewen@intel.com Thank you Yao Jiewen > -Original Message- > From: Kinney, Michael D > Sent: Thursday, May 24, 2018 11:16 PM > To: edk2-devel@lists.01.org > Cc: Sean Brogan ; Zeng, Star > ; Dong, Eric ; Yao, Jiewen > ; Wei, David

Re: [edk2] [PATCH] OvmfPkg: raise DXEFV size to 11 MB

On 28 May 2018 at 20:49, Laszlo Ersek wrote: > Almost exactly two years after commit 2f7b34b20842f, we've grown out the > 10MB DXEFV: > >> build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -b NOOPT -t GCC48 \ >> -D SMM_REQUIRE -D SECURE_BOOT_ENABLE -D TLS_ENABLE -D E1000_ENABLE \ >> -D

[edk2] [PATCH] OvmfPkg: raise DXEFV size to 11 MB

Almost exactly two years after commit 2f7b34b20842f, we've grown out the 10MB DXEFV: > build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -b NOOPT -t GCC48 \ > -D SMM_REQUIRE -D SECURE_BOOT_ENABLE -D TLS_ENABLE -D E1000_ENABLE \ > -D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE > > [...] > > GenFv:

Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

Hey Jeff, Of course I meant to introduce a “gEdkiiCpuS3DataAvailablePpiGuid” or similar to create a Depex on. Thanks, Marvin. From: Fan Jeff Sent: Monday, May 28, 2018 4:19 PM To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org Cc: ler...@redhat.com;

Re: [edk2] [PATCH v3 3/5] MdePkg/DxeServicesLib: introduce AllocatePeiAccessiblePages routine

On 05/28/18 16:40, Ard Biesheuvel wrote: > Add a routine to DxeServicesLib that abstracts the allocation of memory > that should be accessible by PEI after a warm reboot. We will use it to > replace open coded implementations that limit the address to < 4 GB, > which may not be possible on

[edk2] [PATCH v3 4/5] MdeModulePkg/DxeCorePerformanceLib: use AllocatePeiAccessiblePages

Replace the call to and implementation of the function FpdtAllocateReservedMemoryBelow4G() with a call to AllocatePeiAccessiblePages, which boils down to the same on X64, but does not crash non-X64 systems that lack memory below 4 GB. Contributed-under: TianoCore Contribution Agreement 1.1

[edk2] [PATCH v3 1/5] OvmfPkg/PlatformBootManagerLib: add missing report status code call

Consumers of status code reports may rely on a status code to be reported when the ReadyToBoot event is signalled. For instance, FirmwarePerformanceDxe will fail to install the FPDT ACPI table in this case. So add the missing call. Contributed-under: TianoCore Contribution Agreement 1.1

[edk2] [PATCH v3 0/5] Abstract allocation of PEI accessible memory

At the moment, FirmwarePerformanceTableDataDxe or DxeCorePerformanceLib are unusable on systems such as AMD Seattle, because they unconditionally attempt to allocate memory below 4 GB, and ASSERT() if this fails. On AMD Seattle, no 32-bit addressable DRAM exists, and so the driver will always

[edk2] [PATCH v3 5/5] MdeModulePkg/FirmwarePerformanceDataTableDxe: use AllocatePeiAccessiblePages

Replace the call to and implementation of the function FpdtAllocateReservedMemoryBelow4G() with a call to AllocatePeiAccessiblePages, which boils down to the same on X64, but does not crash non-X64 systems that lack memory below 4 GB. Contributed-under: TianoCore Contribution Agreement 1.1

[edk2] [PATCH v3 3/5] MdePkg/DxeServicesLib: introduce AllocatePeiAccessiblePages routine

Add a routine to DxeServicesLib that abstracts the allocation of memory that should be accessible by PEI after a warm reboot. We will use it to replace open coded implementations that limit the address to < 4 GB, which may not be possible on non-Intel systems that have no 32-bit addressable memory

[edk2] [PATCH v3 2/5] ArmVirtPkg/PlatformBootManagerLib: add missing report status code call

Consumers of status code reports may rely on a status code to be reported when the ReadyToBoot event is signalled. For instance, FirmwarePerformanceDxe will fail to install the FPDT ACPI table in this case. So add the missing call. Contributed-under: TianoCore Contribution Agreement 1.1

Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

Marvin, Thanks your reply. i have thought my mail hasn't sent out just now. Adding CpuS3DataPei depends on wether we need to suppoert S3 without DXE, i think. Even we add CpuS3DataPei, we cannot assume the dispatch order between CpuFeaturesPei and CpuS3DataPei from core code view. So,we

[edk2] [Patch] SecurityPkg/Tcg2Smm: Correct function parameter attribute

Correct UpdatePossibleResource parameter attribute to align to comment Change-Id: Id8f8be975f0e8666573decc3fbaaf326b7767ba8 Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Long Qin Cc: Yao Jiewen Reviewed-by: Chao Zhang

Re: [edk2] smm lock query

Hello Andrew and Laszlo, Thanks for your comments! Of course I'm with you that it is the platform that signals the SmmReadyToLock event and therefor is aware. However, they might rely on the protocol's description that the resources are about(!) to be locked and code accordingly, not

Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

Hey Jeff, Thanks for looking into it! Maybe both should be implemented (PEI and additional DXE Depex) and leave it to the platform maintainer, as with CpuFeaturesPei vs CpuFeaturesDxe? If the platform PEI happens to not consume PCD, PcdPei would need to be introduced just to support

Re: [edk2] 答复: CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

Hi, The current implementation assumes CpuS3DataDxe was dispatched before CpuFeaturesDxe. I do not remember clearly why I made this assumption before. (It maybe only due to CpuS3DataDxe was just dispatched firstly on all my validation platforms.), I agree this is one bug. Simply, we could

[edk2] [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd register

The existing code sets the SCI_EN bit directly, which is a violation of the ACPI spec ("It is the responsibility of the hardware to set or reset this bit. OSPM always preserves this bit position"). The proper way to cause this bit to bit set is to reference the FADT table and write the value of

Re: [edk2] smm lock query

On 05/27/18 22:44, Andrew Fish wrote: > > >> On May 27, 2018, at 9:47 AM, Marvin H?user >> wrote: >> >> Good day Abhishek, >> >> I CC'd the MdeModulePkg maintainers, Ruiyu for the Platform BDS aspect >> (exposes the ReadyToLock protocol) and Laszlo for his

[edk2] 答复: CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

Hi, The current implementation assumes CpuS3DataDxe was dispatched before CpuFeaturesDxe. I do not remember clearly why I made this assumption before. (It maybe only due to CpuS3DataDxe was just dispatched firstly on all my validation platforms.), I agree this is one bug. Simply, we could

Re: [edk2] [Patch 0/3] Use comparison logic to check UINTN parameter in GetBestLanguage API

Hey Star and Liming, May I propose re-considering the introduction of a third named parameter to reflect the first Language passed? This would 1) have the advantage that the BOOLEAN parameter can remain as is, which increases readability and 2) require at least two parameters related to the

Re: [edk2] [Patch 0/3] Use comparison logic to check UINTN parameter in GetBestLanguage API

Reviewed-by: Star Zeng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming Gao Sent: Monday, May 28, 2018 3:31 PM To: edk2-devel@lists.01.org Subject: [edk2] [Patch 0/3] Use comparison logic to check UINTN parameter in

[edk2] [Patch 0/3] Use comparison logic to check UINTN parameter in GetBestLanguage API

Liming Gao (3): MdePkg UefiLib: Use comparison logic to check UINTN parameter IntelFrameworkPkg UefiLib: Use comparison logic to check UINTN parameter MdeModulePkg Variable: Use comparison logic to check UINTN parameter IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c| 6

[edk2] [Patch 2/3] IntelFrameworkPkg UefiLib: Use comparison logic to check UINTN parameter

Commit cb96e7d4f7afdbaef0706f9251ae479639d85a28 changes the input parameter from BOOLEAN to UINTN. Its comparison logic should be updated. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao ---

[edk2] [Patch 3/3] MdeModulePkg Variable: Use comparison logic to check UINTN parameter

Commit 180ac200da84785989443b06bcfa5db343c0bf7e changes the input parameter from BOOLEAN to UINTN. Its comparison logic should be updated. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao Cc: Star Zeng ---

[edk2] [Patch 1/3] MdePkg UefiLib: Use comparison logic to check UINTN parameter

Commit d2aafe1e410c80d1046f2d1e743055882ead8489 changes the input parameter from BOOLEAN to UINTN. Its comparison logic should be updated. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao Cc: Michael Kinney ---

Re: [edk2] [PATCH v2] PcAtChipsetPkg/PcRtc: Add two new PCD for RTC Index/Target registers

Reviewed-by: Star Zeng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni Sent: Monday, May 28, 2018 2:30 PM To: edk2-devel@lists.01.org Cc: Zeng, Star Subject: [edk2] [PATCH v2]

Re: [edk2] [PATCH] UefiCpuPkg/CpuCommonFeatures: Follow SDM for MAX CPUID feature detect

Reviewed-by: Eric Dong -Original Message- From: Ni, Ruiyu Sent: Friday, May 25, 2018 5:01 PM To: edk2-devel@lists.01.org Cc: Dong, Eric ; Shao, Ming Subject: [PATCH] UefiCpuPkg/CpuCommonFeatures: Follow SDM for MAX CPUID

[edk2] [PATCH v2] PcAtChipsetPkg/PcRtc: Add two new PCD for RTC Index/Target registers

In certain HW implementation, the BIT7 of RTC Index register(0x70) is for NMI sources enable/disable but the BIT7 of 0x70 cannot be read before writing. Software which doesn't want to change the NMI sources enable/disable setting can write to the alias register 0x74, through which only BIT0 ~ BIT6