Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 05/20] UefiCpuPkg: Add CpuTimerDxe module

+/** + Timer Interrupt Handler. + + @param InterruptTypeThe type of interrupt that occured + @param SystemContextA pointer to the system context when the interrupt occured +**/ +VOID +EFIAPI +TimerInterruptHandler ( + IN EFI_EXCEPTION_TYPE InterruptType, + IN EFI_SYSTEM_CONTEXT Sys

[edk2-devel] [PATCH v2 02/10] CryptoPkg: add CryptoServicePcd.hash_only.dsc.inc

Contains only hash functions needed for measurements. Signed-off-by: Gerd Hoffmann --- CryptoPkg/Include/Dsc/CryptoServicePcd.hash_only.dsc.inc | 8 1 file changed, 8 insertions(+) create mode 100644 CryptoPkg/Include/Dsc/CryptoServicePcd.hash_only.dsc.inc diff --git a/CryptoPkg/Inclu

[edk2-devel] [PATCH v2 00/10] OvmfPkg: add Crypto Driver support

Known problem: the NOOPT builds fail due to PEI becoming too big. What is the reason for doing these NOOPT builds? I'm not sure what value they provide. But the lack of LTO bloats the binaries with dead code, which is a constant source of trouble ... v2 changes: - turn on crypto driver support

[edk2-devel] [PATCH v2 05/10] OvmfPkg: OvmfPkgX64: use crypto includes

Use the new crypto support include files. Signed-off-by: Gerd Hoffmann --- OvmfPkg/OvmfPkgX64.dsc | 22 +- OvmfPkg/OvmfPkgX64.fdf | 6 ++ 2 files changed, 15 insertions(+), 13 deletions(-) diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index e3c64456dfef..

[edk2-devel] [PATCH v2 01/10] CryptoPkg: move Driver PCD configs to include files

Makes it easier to reuse the predefined config sets in other places. Signed-off-by: Gerd Hoffmann --- .../Include/Dsc/CryptoServicePcd.all.dsc.inc | 29 +++ .../Dsc/CryptoServicePcd.min_dxe_smm.dsc.inc | 35 + .../Dsc/CryptoServicePcd.min_pei.dsc.inc | 20 + CryptoPkg/Cryp

[edk2-devel] [PATCH v2 03/10] CryptoPkg: add TPM hashes to CryptoServicePcd.min_dxe_smm.dsc.inc

Enable Sha384 + Sha512 + Sm3. Signed-off-by: Gerd Hoffmann --- CryptoPkg/Include/Dsc/CryptoServicePcd.min_dxe_smm.dsc.inc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CryptoPkg/Include/Dsc/CryptoServicePcd.min_dxe_smm.dsc.inc b/CryptoPkg/Include/Dsc/CryptoServicePcd.mi

[edk2-devel] [PATCH v2 06/10] OvmfPkg: OvmfPkgIa32X64: use crypto includes

Use the new crypto support include files. Signed-off-by: Gerd Hoffmann --- OvmfPkg/OvmfPkgIa32X64.dsc | 22 +- OvmfPkg/OvmfPkgIa32X64.fdf | 6 ++ 2 files changed, 15 insertions(+), 13 deletions(-) diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc inde

[edk2-devel] [PATCH v2 07/10] OvmfPkg: OvmfPkgIa32: use crypto includes

Use the new crypto support include files. Signed-off-by: Gerd Hoffmann --- OvmfPkg/OvmfPkgIa32.dsc | 22 +- OvmfPkg/OvmfPkgIa32.fdf | 6 ++ 2 files changed, 15 insertions(+), 13 deletions(-) diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 22dc29330d

[edk2-devel] [PATCH v2 08/10] OvmfPkg: Microvm: use crypto includes

Use the new crypto support include files. Signed-off-by: Gerd Hoffmann --- OvmfPkg/Microvm/MicrovmX64.dsc | 24 +++- OvmfPkg/Microvm/MicrovmX64.fdf | 7 +++ 2 files changed, 18 insertions(+), 13 deletions(-) diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/

[edk2-devel] [PATCH v2 09/10] OvmfPkg: IntelTdx: use crypto includes

Use the new crypto support include files. Signed-off-by: Gerd Hoffmann --- OvmfPkg/IntelTdx/IntelTdxX64.dsc | 15 +-- OvmfPkg/IntelTdx/IntelTdxX64.fdf | 5 + 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/Intel

[edk2-devel] [PATCH v2 04/10] OvmfPkg: add OvmfCrypto*.inc

Create include files for crypto support, so the configuration can be shared for all OVMF build variants. Also add support for using the Crypto Driver. The Crypto Driver is enabled by default and can be disabled by setting USE_CRYPTO_DRIVER to FALSE. The config option is intended to be temporary

[edk2-devel] [PATCH v2 10/10] OvmfPkg: AmdSev: use crypto includes

Use the new crypto support include files. Signed-off-by: Gerd Hoffmann --- OvmfPkg/AmdSev/AmdSevX64.dsc | 12 OvmfPkg/AmdSev/AmdSevX64.fdf | 6 ++ 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc index 1

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 05/20] UefiCpuPkg: Add CpuTimerDxe module

On Thu, Feb 09, 2023 at 10:17:56AM +, Michael Brown wrote: > > +/** > > + Timer Interrupt Handler. > > + > > + @param InterruptTypeThe type of interrupt that occured > > + @param SystemContextA pointer to the system context when the > > interrupt occured > > +**/ > > +VOID > > +EFIA

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 05/20] UefiCpuPkg: Add CpuTimerDxe module

On 09/02/2023 10:28, Sunil V L wrote: + gBS->RestoreTPL (OriginalTPL); + RiscVEnableTimerInterrupt (); // enable SMode timer int +} This design looks as though it does not support nested timer interrupts. The call to RestoreTPL() may invoke callbacks that may themselves include delay loops th

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 05/20] UefiCpuPkg: Add CpuTimerDxe module

On Thu, Feb 09, 2023 at 10:30:58AM +, Michael Brown wrote: > On 09/02/2023 10:28, Sunil V L wrote: > > > > + gBS->RestoreTPL (OriginalTPL); > > > > + RiscVEnableTimerInterrupt (); // enable SMode timer int > > > > +} > > > > > > This design looks as though it does not support nested timer in

Re: [edk2-devel] [PATCH] Platform/Qemu/Sbsa: Update TF-A binaries to enable SVE/SME

On Thu, 9 Feb 2023 at 00:10, Marcin Juszkiewicz via groups.io wrote: > > From: Marcin Juszkiewicz > > Update the TF-A binaries with SVE/SME enablement. > > This support was merged into TF-A: > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17825 > > This allows to test SBSA Refe

Re: [edk2-devel] [PATCH 1/1] OvmfPkg: Update build.sh to allow building OVMF then running QEMU

On Wed, Feb 08, 2023 at 11:01:38AM -0700, Rebecca Cran wrote: > Allow users to build OVMF then run QEMU by moving the build block above > the run block and removing the exit line. > > Signed-off-by: Rebecca Cran > Cc: Ard Biesheuvel > Cc: Jiewen Yao > Cc: Jordan Justen > Cc: Gerd Hoffmann Ac

[edk2-devel] [PATCH v4 00/11] ArmPkg: implement EFI memory attributes protocol

v4: - major cleanup of the 32-bit ARM code - add support for EFI_MEMORY_RP using the access flag - enable stack guard in ArmVirtPkg (which uses EFI_MEMORY_RP) - incorporate optimization from other series [0] to avoid splitting block entries unnecessarily v3: - fix ARM32 bug in attribute conversi

[edk2-devel] [PATCH v4 01/11] ArmPkg/ArmMmuLib ARM: Remove half baked large page support

Large page support on 32-bit ARM is essentially a glorified contiguous bit where 16 consecutive entries describing a contiguous range with the same attributes are presented in a way that permits the TLB to cache its translation with a single entry. This was never wired up completely, and does not

[edk2-devel] [PATCH v4 02/11] ArmPkg/ArmMmuLib ARM: Split off XN page descriptor bit from type field

With large page support out of the picture, we can treat bits 1 and 0 of the page descriptor as individual valid and XN bits, instead of treating XN as a page type. Doing so aligns the handling of the attribute with the section descriptor layout, as well as the XN handling on AArch64, and this is b

[edk2-devel] [PATCH v4 03/11] ArmPkg/CpuDxe ARM: Fix page-to-section attribute conversion

The section-to-page attribute conversion takes the shareability and execute-never attributes into account, whereas the page-to-section counterpart does not. The result is that GetMemoryRegionPage () -which takes a section attribute argument (via *RegionAttributes) that is ostensibly based on the fi

[edk2-devel] [PATCH v4 04/11] ArmPkg/ArmMmuLib ARM: Isolate the access flag from AP mask

Split the ARM permission fields in the short descriptors into an access flag and AP[2:1] as per the recommendation in the ARM ARM. This makes the access flag available separately, which allows us to implement EFI_MEMORY_RP memory analogous to how it will be implemented for AArch64. Signed-off-by:

[edk2-devel] [PATCH v4 06/11] ArmPkg/ArmMmuLib: Implement EFI_MEMORY_RP using access flag

Implement support for read-protected memory by wiring it up to the access flag in the page table descriptor. The resulting mapping is implicitly non-writable and non-executable as well, but this is good enough for implementing this attribute, as we never rely on write or execute permissions without

[edk2-devel] [PATCH v4 05/11] ArmPkg/ArmMmuLib ARM: Clear individual permission bits

Currently, the MMU code that is supposed to clear the RO or XP attributes from a region just clears both unconditionally. This approximates the desired behavior to some extent, but it does mean that setting the RO bit first on a code region, and then clearing the XP bit results both RO and XP being

[edk2-devel] [PATCH v4 07/11] ArmVirtPkg: Enable stack guard

Enable the stack guard in ArmVirtPkg builds, so that stack overflows are caught as they occur, rather than when they happen to hit a read-only memory region. Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/ArmVirt.dsc.inc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ArmVirtPkg/ArmVirt.dsc.

[edk2-devel] [PATCH v4 08/11] ArmPkg/ArmMmuLib: Avoid splitting block entries if possible

Currently, the ARM MMU page table logic will break down any block entry that overlaps with the region being mapped, even if the block entry in question is using the same attributes as the new region. This means that creating a non-executable mapping inside a region that is already mapped non-execu

[edk2-devel] [PATCH v4 09/11] ArmPkg/CpuDxe: Expose unified region-to-EFI attribute conversion

In preparation for introducing an implementation of the EFI memory attributes protocol that is shared between ARM and AArch64, unify the existing code that converts a page table descriptor into a EFI_MEMORY_xxx bitfield, so it can be called from the generic code. Signed-off-by: Ard Biesheuvel ---

[edk2-devel] [PATCH v4 10/11] MdePkg: Add Memory Attribute Protocol definition

Add the Memory Attribute Protocol definition, which was adopted and included in version 2.10 of the UEFI specification. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=3519 Signed-off-by: Ard Biesheuvel Reviewed-by: Liming Gao --- MdePkg/Include/Protocol/MemoryAttribute.h | 142 +++

[edk2-devel] [PATCH v4 11/11] ArmPkg/CpuDxe: Implement EFI memory attributes protocol

Expose the protocol introduced in v2.10 that permits the caller to manage mapping permissions in the page tables. Signed-off-by: Ard Biesheuvel --- ArmPkg/Drivers/CpuDxe/CpuDxe.c | 2 + ArmPkg/Drivers/CpuDxe/CpuDxe.h | 3 + ArmPkg/Drivers/CpuDxe/CpuDxe.inf| 2 + A

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt: Add entry for OvmfPkg/RiscVVirt

Hi Sunil I did not find any RiscV64QemuVirt related PR there. (I searched RiscV64QemuVirt) May I know if you have tried the patch series in EDK2 CI? Thank you Yao, Jiewen > -Original Message- > From: Yao, Jiewen > Sent: Thursday, February 9, 2023 1:07 PM > To: Sunil V L ; devel@edk2.gro

Re: [edk2-devel] [PATCH v2 1/3] UsbNetworkPkg/UsbRndis: Add USB RNDIS devices support

On 2/7/23 01:20, Michael Brown wrote: Is PcdGet32() guaranteed to be a compile-time constant?  If not, then it's probably a good idea to read it once upon initialisation, rather than once per timer interrupt handler invocation. There's an explicit compile-time version, FixedPcdGet32. -- Rebe

Re: [edk2-devel] [PATCH v2 2/2] ArmVirtPkg/ArmVirtQemu: Avoid early ID map on ThunderX

On Tue, 7 Feb 2023 at 13:58, Oliver Steffen wrote: > > On Tue, Feb 7, 2023 at 12:57 PM Ard Biesheuvel wrote: >> >> On Tue, 7 Feb 2023 at 11:51, Oliver Steffen wrote: >> > >> > On Thu, Feb 2, 2023 at 12:09 PM Oliver Steffen wrote: >> >> >> >> >> >> On Wed, Feb 1, 2023 at 2:29 PM Ard Biesheuvel

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt: Add entry for OvmfPkg/RiscVVirt

On Thu, Feb 09, 2023 at 02:05:34PM +, Yao, Jiewen wrote: > Hi Sunil > I did not find any RiscV64QemuVirt related PR there. (I searched > RiscV64QemuVirt) > > May I know if you have tried the patch series in EDK2 CI? > > Thank you > Yao, Jiewen > Hi Jiewen, Yes, https://github.com/tianocor

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 20/20] Maintainers.txt: Add entry for OvmfPkg/RiscVVirt

Sounds great. Thank you! > -Original Message- > From: Sunil V L > Sent: Thursday, February 9, 2023 11:20 PM > To: Yao, Jiewen > Cc: devel@edk2.groups.io; Kinney, Michael D ; > abner.ch...@amd.com; Andrew Fish ; Leif Lindholm > > Subject: Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PA

Re: [edk2-devel] [edk2-platforms: PATCH] IntelSiliconPkg/SpiFvbServiceSmm: Support Other NVS variable region.

Is there a reason this other content can't go into it's own FV? On 2/9/2023 12:14 AM, Chiu, Chasel wrote: Platform may implement Other NVS variable region following Regular variable region and in this case SpiFvbService should include both region size when calculating the total NVS region size.

[edk2-devel] [PATCH 1/2] MdePkg: Update Base.h to be compliant with C11

With the introduction of the use of _Static_assert, edk2 requires a C11 compatible compiler. Update Include/Base.h to be compliant with C11. As of C11, the maximum type of an enum is type `int`. Since the UEFI Specification 2.3.1 Errata C allows either `int` or `unsigned int`, fix the 32-bit enum

[edk2-devel] [PATCH 2/2] MdePkg: Update code to be more C11 compliant by using __func__

__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout MdePkg. Signed-off-by: Rebecca Cran --- MdePkg/Include/Library/PerformanceLib.h

Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V7 03/20] MdePkg: Add BaseRiscVSbiLib Library for RISC-V

I agree with keeping the .S file in this component. I was only referring to BaseLib as other examples that used .S instead of inline assembly. Mike > -Original Message- > From: Sunil V L > Sent: Wednesday, February 8, 2023 11:19 PM > To: devel@edk2.groups.io; Kinney, Michael D > Cc: Ga

Re: [edk2-devel] Enum size checks in Base.h (UINT32 not ISO C compatible)

I've sent a patch (https://edk2.groups.io/g/devel/message/99903). On 2/8/23 19:28, Kinney, Michael D wrote: Hi Rebecca, Great catch!!! I think the static assert verifier is incorrect. The UEFI Spec does clearly state in Section 2.3.1 that enum values can be type INT32 or UINT32. The use of 0

Re: [edk2-devel] [edk2-platforms: PATCH] IntelSiliconPkg/SpiFvbServiceSmm: Support Other NVS variable region.

It is a legacy that exists in current and past implementations. There is a complex arbitrary relationship between the runtime updateable regions in existing platform designs. There is something like: - Variable store (large) - Error log (small) - Fault tolerant working area (>= size of prior 2 r

Re: [edk2-devel] [PATCH 3/5] OvmfPkg: Add CpuPageTableLib required by MpInitLib.

On Wed, 8 Feb 2023 at 11:53, Gerd Hoffmann wrote: > > On Tue, Feb 07, 2023 at 09:49:37PM +0800, Yuanhao Xie wrote: > > Add CpuPageTableLib required by MpInitLib in OvmfPkg. > > > > Cc: Ard Biesheuvel > > Cc: Jiewen Yao > > Cc: Jordan Justen > > Cc: Gerd Hoffmann > > Signed-off-by: Yuanhao Xie

Re: [edk2-devel] [PATCH v2 00/10] OvmfPkg: add Crypto Driver support

On Thu, 9 Feb 2023 at 11:27, Gerd Hoffmann wrote: > > Known problem: the NOOPT builds fail due to PEI becoming too big. > > What is the reason for doing these NOOPT builds? They are very useful for doing single step debugging with GDB. On ARM, I use the NOOPT builds fairly regularly. > I'm not

Re: [edk2-devel] [edk2-platforms: PATCH] IntelSiliconPkg/SpiFvbServiceSmm: Support Other NVS variable region.

Thanks, that's useful background. @chasel, you should probably put this info in the commit message so it is captured in source history. Given the default value is zero, it seems reasonable. I was also initially confused by the name of the PCD. Another idea would be something like "PcdFlashNvS

Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe

> With this patch I observe an issue where my Linux (6.2.0-rc7) guest > recur to Bootloader menu again. I am testing this with SEV SNP (w/o > UPM). Also, guest don't have lazy memory acceptance support. > Thanks for the report. I'll try to reproduce it on our UEFI and if I'm unable, then we'll dis

Re: [edk2-devel] [PATCH 1/1] ArmPkg/PlatformBootManagerLib: Add path to boot UEFI Shell over UiApp

On Tue, 7 Feb 2023 at 10:07, wrote: > > From: Pierre Gondois > > The UEFI Shell is a non-active boot option, at the opposite of UiApp. > If no valid boot option is found, UiApp is selected. UiApp requires a > human interaction. When installing a new EDKII image in CIs or when > scripting is requi

Re: [edk2-devel] [IMPORTANT] February Release Reviews and Merges

Received. I will be incontact -miki -- Miki Demeter (she/her/Miki) Security Researcher / FW Developer FST Intel Corporation Co-Chair, Network of Intel African-Ancestry(NIA) - Oregon NIA-Oregon Portland Women in Tech Best Speaker miki.deme...@intel.com

Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe

Hi Dionna, The added behavior is to accept all unaccepted memory at ExitBootServices if the behavior is not disabled. This allows safe upgrades for OS loaders to affirm their support for the unaccepted memory type. With this patch I observe an issue where my Linux (6.2.0-rc7) guest recur to Bo

Re: [edk2-devel] regarding uefipayload build warning for pcd

Any idea, what is the cause of below error? any workaround can be tried for this? Loading driver 378D7B65-8DA9-4773-B6E4-A47826A833E1 InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 51A3E1C0 Loading driver at 0x00051DD1000 EntryPoint=0x00051DD5670 PcRtc.efi InstallProtocolInterface:

Re: [edk2-devel] [PATCH 1/1] ArmPkg/PlatformBootManagerLib: Add path to boot UEFI Shell over UiApp

W dniu 7.02.2023 o 10:06, PierreGondois pisze: The UEFI Shell is a non-active boot option, at the opposite of UiApp. If no valid boot option is found, UiApp is selected. UiApp requires a human interaction. When installing a new EDKII image in CIs or when scripting is required, this is problematic

[edk2-devel] [edk2-platforms: PATCH v2] IntelSiliconPkg/SpiFvbServiceSmm: Support Additional NVS region.

Platform may implement an additional NVS region following Regular variable region and in this case SpiFvbService should include both region size when calculating the total NVS region size. One usage model is EventLog NVS region and there could be others. Example NVS flash map for such usage model:

[edk2-devel] [edk2-platforms: PATCH v3] IntelSiliconPkg/SpiFvbServiceSmm: Support Additional NVS region.

Platform may implement an additional NVS region following Regular variable region and in this case SpiFvbService should include both region size when calculating the total NVS region size. One usage model is EventLog NVS region and there could be others. Example NVS flash map for such usage model:

Re: [edk2-devel] [edk2-platforms: PATCH v3] IntelSiliconPkg/SpiFvbServiceSmm: Support Additional NVS region.

Please fix the typo in the commit message and code comment before pushing. "|UEI Variable|" -> "|UEFI Variable|" Reviewed-by: Michael Kubacki On 2/9/2023 12:20 PM, Chiu, Chasel wrote: Platform may implement an additional NVS region following Regular variable region and in this case SpiFvbServ

Re: [edk2-devel] [edk2-platforms: PATCH] IntelSiliconPkg/SpiFvbServiceSmm: Support Other NVS variable region.

Thanks for good suggestions Isaac and Michael! I have sent V3 patch to apply all the suggestions, please help to review again. Thanks, Chasel > -Original Message- > From: devel@edk2.groups.io On Behalf Of Michael > Kubacki > Sent: Thursday, February 9, 2023 8:47 AM > To: devel@edk2.gr

Re: [edk2-devel] [PATCH 1/1] OvmfPkg: Update build.sh to allow building OVMF then running QEMU

On Thu, 9 Feb 2023 at 14:22, Gerd Hoffmann wrote: > > On Wed, Feb 08, 2023 at 11:01:38AM -0700, Rebecca Cran wrote: > > Allow users to build OVMF then run QEMU by moving the build block above > > the run block and removing the exit line. > > > > Signed-off-by: Rebecca Cran > > Cc: Ard Biesheuvel

Re: [edk2-devel] [PATCH v2 1/1] StandaloneMmPkg: StandaloneMmMemLib: Change max address computation

On Mon, 30 Jan 2023 at 17:29, Girish Mahadevan wrote: > > Currently the standalonemmlibinternal assumes the max physical bits > to be 36 which is causing issues on v8 architectures. > Instead use the MAX_ALLOC_ADDRESS macro to determine the maximum > allowed address rather than recomputing it loca

[edk2-devel] [edk2-platforms: PATCH v4] IntelSiliconPkg/SpiFvbServiceSmm: Support Additional NVS region.

Platform may implement an additional NVS region following Regular variable region and in this case SpiFvbService should include both region size when calculating the total NVS region size. The PcdFlashNvStorageAdditionalSize is for compatible with legacy usages that should be deprecated. The new u

Re: [edk2-devel] [edk2-platforms: PATCH] IntelSiliconPkg/SpiFvbServiceSmm: Support Other NVS variable region.

Hello, Another V4 patch sent for applying more comment/commit message feedbacks form Isaac. Please help to review again. Thanks, Chasel > -Original Message- > From: devel@edk2.groups.io On Behalf Of Chiu, Chasel > Sent: Thursday, February 9, 2023 9:26 AM > To: devel@edk2.groups.io; m

Re: [edk2-devel] [edk2-platforms: PATCH v4] IntelSiliconPkg/SpiFvbServiceSmm: Support Additional NVS region.

Reviewed-by: Isaac Oram -Original Message- From: Chiu, Chasel Sent: Thursday, February 9, 2023 10:27 AM To: devel@edk2.groups.io Cc: Chiu, Chasel ; S, Ashraf Ali ; Oram, Isaac W ; Chaganty, Rangasai V ; Ni, Ray ; Kubacki, Michael Subject: [edk2-platforms: PATCH v4] IntelSiliconPkg/

Re: [edk2-devel] [edk2-platforms: PATCH v4] IntelSiliconPkg/SpiFvbServiceSmm: Support Additional NVS region.

Thanks for promptly reviewing and good suggestions Michael, Isaac! I have merged this patch: https://github.com/tianocore/edk2-platforms/commit/88d44c563d9fd5c95be93e706f9420352ee4c053 Thanks, Chasel > -Original Message- > From: Oram, Isaac W > Sent: Thursday, February 9, 2023 10:34

FW: [edk2-devel] [PATCH] MdeModulePkg: allow PlatformBootManagerLib to use BootNext

Miki, this patch, as well as my queries on the mailing list about this topic prior to the patch, hasn't received any response on the mailing list. One kind person did respond privately with some information about my questions. -Original Message- From: devel@edk2.groups.io On Behalf Of J

Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe

On Thu, Feb 9, 2023 at 8:52 AM Dionna Amalie Glaze wrote: > > > With this patch I observe an issue where my Linux (6.2.0-rc7) guest > > recur to Bootloader menu again. I am testing this with SEV SNP (w/o > > UPM). Also, guest don't have lazy memory acceptance support. > > > > Thanks for the report

[edk2-devel] FW: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple devices with 0 HardwareInstance

Here is a patch that has been pending for a bit Thanks, Jeff -Original Message- From: Jeff Brasen Sent: Wednesday, February 1, 2023 9:21 AM To: devel@edk2.groups.io Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn; guomin.ji...@intel.com Subject: RE: [PATCH v2] MdeModulePkg/EsrtFmpDxe

[edk2-devel] [PATCH] MdeModulePkg/Variable: Attribute combination should return EFI_UNSUPPORTED

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4341 Commit 21320ef66989 broke some tests in the AuthVar_Conf test in edk2-test. There are 2 testcases that invoke SetVariable with the following attribute value: (EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS) EFI_VARIAB

[edk2-devel] Changes to my email

For almost two years, I've been using one of quic_rc...@quicinc.com or rebe...@quicinc.com (in addition to rebe...@bsdio.com) for communications and submissions to edk2. As part of leaving my current employment, outgoing email from those addresses is restricted and I'm likely to lose access en

Re: [edk2-devel] [PATCH v2 1/2] MdePkg: Add RPMB related commands and DCB definition for NVMe

Acked-by: Michael D Kinney > -Original Message- > From: Wu, Hao A > Sent: Sunday, February 5, 2023 9:18 PM > To: Zhu, Weipu ; devel@edk2.groups.io > Cc: Kinney, Michael D ; Gao, Liming > ; Liu, Zhiguang > Subject: RE: [PATCH v2 1/2] MdePkg: Add RPMB related commands and DCB > definiti

Re: [edk2-devel] [PATCH v2 2/2] MdePkg: Add NVMe boot partition header definition

Acked-by: Michael D Kinney > -Original Message- > From: Wu, Hao A > Sent: Sunday, February 5, 2023 9:18 PM > To: Zhu, Weipu ; devel@edk2.groups.io > Cc: Kinney, Michael D ; Gao, Liming > ; Liu, Zhiguang > Subject: RE: [PATCH v2 2/2] MdePkg: Add NVMe boot partition header definition >

[edk2-devel] [edk2-platforms][PATCH v1 1/1] SpiFvbServiceStandaloneMm: Add changes for rewrite varstore header

From: Michael Kubacki Updates the Standalone MM module to have the necessary INF changes to build with the following two recent commits made to rewrite the the variable store header in the MM SPI FVB service. - e95c798 - 88d44c5 Cc: Ashraf Ali S Cc: Isaac Oram Cc: Rangasai V Chaganty Cc:

Re: [edk2-devel] [PATCH 2/2] MdePkg: Update code to be more C11 compliant by using __func__

Hi Rebecca, Did this pass EDK II CI? This change does break EBC compiler builds. The following has to be added to MdePkg/Include/Ebc/ProcessorBind.h in order to use __func__ everywhere. #define __func__ __FUNCTION__ I also see __FUNCTION__ used in many packages. I am wondering if we want

Re: [edk2-devel] [PATCH 1/2] MdePkg: Update Base.h to be compliant with C11

Hi Rebecca, Reviewed-by: Michael D Kinney Do you think this needs to be considered for edk2-stable202302? Thanks, Mike > -Original Message- > From: devel@edk2.groups.io On Behalf Of Rebecca Cran > Sent: Thursday, February 9, 2023 7:45 AM > To: devel@edk2.groups.io; Kinney, Michael D

Re: [edk2-devel] [PATCH 1/2] MdePkg: Update Base.h to be compliant with C11

Since it's just a cleanup I don't see any need for it to be in edk2-stable202303. -- Rebecca Cran On 2/9/23 18:03, Michael D Kinney wrote: Hi Rebecca, Reviewed-by: Michael D Kinney Do you think this needs to be considered for edk2-stable202302? Thanks, Mike -Original Message- Fr

Re: [edk2-devel] [PATCH 2/2] MdePkg: Update code to be more C11 compliant by using __func__

Mike, Yes, it passed CI - see https://github.com/tianocore/edk2/pull/4022 . I wasn't sure if we cared about EBC builds these days. Given the link on https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html to

Re: [edk2-devel] [PATCH] MdePkg/SecPeiDxeTimerLibCpu: Better support for dynamic PcdFSBClock

On Tue, Nov 08, 2022 at 02:31:48PM +, Anthony PERARD via groups.io wrote: > From: Anthony PERARD > > The PcdFSBClock can be a dynamic PCD. This can be an issue when > InternalX86GetTimerFrequency() tries to get the value while been > called with TPL been set to TPL_HIGH_LEVEL. > > When the P

Re: [edk2-devel] [PATCH] MdePkg/SecPeiDxeTimerLibCpu: Better support for dynamic PcdFSBClock

This library is intended to be compatible with XIP SEC and XIP PEIMs that are not allowed to use writable global C variables. I think storage for STATIC UINT32 mFSBClock is from the .data section and not the stack, so this will break XIP use cases. Mike > -Original Message- > From: deve

Re: [edk2-devel] [edk2-platforms][PATCH v1 1/1] SpiFvbServiceStandaloneMm: Add changes for rewrite varstore header

Reviewed-by: Isaac Oram -Original Message- From: mikub...@linux.microsoft.com Sent: Thursday, February 9, 2023 4:52 PM To: devel@edk2.groups.io Cc: S, Ashraf Ali ; Oram, Isaac W ; Chaganty, Rangasai V ; Ni, Ray ; Chiu, Chasel Subject: [edk2-platforms][PATCH v1 1/1] SpiFvbServiceStand

Re: [edk2-devel] [PATCH] MdeModulePkg/Variable: Attribute combination should return EFI_UNSUPPORTED

Liming, This appears to be a regression from a commit on Jan 11, 2023. I think this should be considered for edk2-stable202302 Mike > -Original Message- > From: devel@edk2.groups.io On Behalf Of Stuart Yoder > Sent: Thursday, February 9, 2023 2:31 PM > To: devel@edk2.groups.io > Cc: Ga

Re: [edk2-devel] [PATCH v2 1/2] MdePkg: Add RPMB related commands and DCB definition for NVMe

Both NVMe patches merged PR: https://github.com/tianocore/edk2/pull/4026 Commits: https://github.com/tianocore/edk2/commit/93a21b465bda44cecdd6347ad481ca6f55286547 https://github.com/tianocore/edk2/commit/069703228cfe6ba128a20e770af831699eae79b7 Mike > -Original Message- > From: Kinney

Re: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple devices with 0 HardwareInstance

Hi Jeff, Thank you for the reminder. I am wondering if the check should be for FmpVersion < 3 and not FmpHardwareInstance != 0. It is possible for an FmpInfoBuffer to have an FmpVersion >= 3 and a HardwareInstance of 0. If more than one of these it found, then that would be an EFI_UNSUPPORTED c

Re: [edk2-devel] [PATCH] MdeModulePkg: allow PlatformBootManagerLib to use BootNext

Hi Jeshua, I prefer to not add more PCDs if it can be avoided. Do you think the current behavior is a bug/gap and that the proposed new behavior when the PCD is TRUE is the correct behavior? What would be the impact of not adding the PCD and just implementing the new behavior? Mike > -O

Re: [edk2-devel] [PATCH 1/2] MdePkg: Update Base.h to be compliant with C11

Also the fact that it's been like this since 2016! -- Rebecca Cran On 2/9/23 18:14, Rebecca Cran wrote: Since it's just a cleanup I don't see any need for it to be in edk2-stable202303. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online

Re: [edk2-devel] [PATCH v4 1/6] MdePkg: Adds AMD SMRAM save state map

Reviewed-by: Michael D Kinney > -Original Message- > From: Abdul Lateef Attar > Sent: Friday, January 20, 2023 6:32 AM > To: devel@edk2.groups.io > Cc: Abdul Lateef Attar ; Paul Grimes ; > Garrett Kirkendall ; > Abner Chang ; Kinney, Michael D > ; Gao, Liming ; Liu, > Zhiguang > Subj

Re: [edk2-devel] [PATCH v1 1/1] .devcontainer/devcontainer.json: Add devcontainer file

Hi Michael, Reviewed-by: Michael D Kinney Please update commit message from Ab to Rb and I will merge. Thanks, Mike > -Original Message- > From: Michael Kubacki > Sent: Tuesday, February 7, 2023 7:50 PM > To: devel@edk2.groups.io; Gao, Liming > Cc: Chris Fernald ; Oliver Steffen >

回复: [edk2-devel] [PATCH v1 1/1] .devcontainer/devcontainer.json: Add devcontainer file

Michael: I am OK to merge this patch into this stable tag 202302. Thanks Liming > -邮件原件- > 发件人: Kinney, Michael D > 发送时间: 2023年2月10日 13:02 > 收件人: devel@edk2.groups.io; mikub...@linux.microsoft.com; Gao, Liming > > 抄送: Chris Fernald ; Oliver Steffen > ; Sean Brogan ; Leif > Lindholm ;

回复: [edk2-devel] [PATCH] MdeModulePkg/Variable: Attribute combination should return EFI_UNSUPPORTED

Mike: I agree. This fix is very clear. It should be merged into this stable tag 202302. Stuart: This change is good to me. Reviewed-by: Liming Gao Thanks Liming > -邮件原件- > 发件人: Kinney, Michael D > 发送时间: 2023年2月10日 10:37 > 收件人: devel@edk2.groups.io; stuart.yo...@arm.com; Gao, Limin

回复: [edk2-devel] [PATCH 1/1] MdePkg: Add DDR5 SPD defs to IndustryStandard per JESD400-5A.01

Rebecca: Have you verified this header file with build? For example, include this new header file into module, and make sure this module pass build. > -邮件原件- > 发件人: devel@edk2.groups.io 代表 Rebecca Cran > 发送时间: 2023年2月9日 1:48 > 收件人: devel@edk2.groups.io > 抄送: Rebecca Cran ; Liming Gao >

回复: [edk2-devel] [PATCH 2/2] MdePkg:IORT header update for IORT Rev E.e spec

It has been merged at 5db84c85c3544b92fa236c4d169440d523712ae0 in Edk2. Thanks Liming 发件人: devel@edk2.groups.io 代表 Swatisri Kantamsetti via groups.io 发送时间: 2023年2月4日 2:48 收件人: gaoliming ; 'Name' ; devel@edk2.groups.io; sami.muja...@arm.com; alexei.fedo...@arm.com; pierre.gond...@arm.com;

Re: [edk2-devel] [PATCH] MdeModulePkg: allow PlatformBootManagerLib to use BootNext

It's the intention to cache BootNext to avoid BootNext change from PlatformBootManagerLib taking affect in this boot. Per spec, BootNext selects the boot option of next boot. If PlatformBootManagerLib wants to change the boot option for this boot, either it can change the BootOrder, or it can use

[edk2-devel] [PATCH v4 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337 The default SMBASE for the x86 processor is 0x3. When SMI happens, CPU runs the SMI handler at SMBASE+0x8000. Also, the SMM save state area is within SMBASE+0x1. One of the SMM initialization from CPU perspective is to relocate and

[edk2-devel] [PATCH v4 1/5] UefiCpuPkg/PiSmmCpuDxeSmm: Fix invalid InitializeMpSyncData call

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4338 No need call InitializeMpSyncData during normal boot SMI init, because mSmmMpSyncData is NULL at that time. mSmmMpSyncData is allocated in InitializeMpServiceData, which is invoked after normal boot SMI init (SmmRelocateBases). Cc: Eric Don

[edk2-devel] [PATCH v4 5/5] OvmfPkg/SmmCpuFeaturesLib: Check SmBase relocation supported or not

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337 This patch is to check SmBase relocation supported or not. If gSmmBaseHobGuid found, means SmBase info has been relocated and recorded in the SmBase array. ASSERT it's not supported in OVMF. Cc: Eric Dong Cc: Ray Ni Cc: Zeng Star Cc: Las

[edk2-devel] [PATCH v4 4/5] UefiCpuPkg/SmmCpuFeaturesLib: Skip SMBASE configuration

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337 This patch is to avoid configure SMBASE if SmBase relocation has been done. If gSmmBaseHobGuid found, means SmBase info has been relocated and recorded in the SmBase array. No need to do the relocation in SmmCpuFeaturesInitializeProcessor().

[edk2-devel] [PATCH v4 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337 Existing SMBASE Relocation is in the PiSmmCpuDxeSmm driver, which will relocate the SMBASE of each processor by setting the SMBASE field in the saved state map (at offset 7EF8h) to a new value. The RSM instruction reloads the internal SMBASE

[edk2-devel] [PATCH v4 0/5] Simplify SMM Relocation Process

Existing SMBASE Relocation is in the PiSmmCpuDxeSmm driver, which will relocate the SMBASE of each processor by setting the SMBASE field in the saved state map (at offset 7EF8h) to a new value. The RSM instruction reloads the internal SMBASE register with the value in SMBASE field when each time it

Re: [edk2-devel] [PATCH v4 1/5] UefiCpuPkg/PiSmmCpuDxeSmm: Fix invalid InitializeMpSyncData call

Reviewed-by: Ray Ni > -Original Message- > From: devel@edk2.groups.io On Behalf Of Wu, > Jiaxin > Sent: Friday, February 10, 2023 2:05 PM > To: devel@edk2.groups.io > Cc: Dong, Eric ; Ni, Ray ; Zeng, Star > ; Laszlo Ersek ; Gerd Hoffmann > ; Kumar, Rahul R > Subject: [edk2-devel] [PATCH

Re: [edk2-devel] [PATCH v4 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data

Jiaxin, > + /// > + /// Pointer to SmBase address for each Processors. > + /// > + UINT64SmBase[1]; Why SmBase[1] instead of SmBase[0]? I think using SmBase[0] can better help C code to calculate the HOB size. Simply sizeof (SMM_BASE_HOB_DATA) * sizeof (UINT64) * CpuCount, instead of sizeo

Re: [edk2-devel] [PATCH v4 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data

Hi Ray, Both is fine to me, one thought is that we must have one CPU, so change to 1 and I also checked some existing usage cases like the EFI_SMRAM_HOB_DESCRIPTOR_BLOCK.Descriptor, WIN_CERTIFICATE_UEFI_GUID. CertData, it also the same way. Thanks, Jiaxin > -Original Message- > From

Re: [edk2-devel] [edk2-platforms][PATCH V2 3/5] Platform/Sgi: Add SSDT table for IO virtualization SoC expansion block

Hi Pierre, On 2/7/23 14:20, Pierre Gondois wrote: Hello Vivek, Thanks for the answers, On 2/7/23 07:59, Vivek Kumar Gautam wrote: Hi Pierre On 2/3/23 21:26, Pierre Gondois wrote: Hello Vivek, Thanks for review the changes, please find my responses inline below. On 1/27/23 10:23, Vivek