Re: [edk2-devel] [PATCH v3 3/5] MdeModulePkg: Do nothing on NestedInterruptRestoreTPL(TPL_HIGH_LEVEL)

[Laszlo Ersek]

On 1/23/24 17:59, Michael Brown wrote:
> On 23/01/2024 16:32, Laszlo Ersek wrote:
>> On 1/23/24 16:31, Michael Brown wrote:
>>> At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
>>> specification) and so we should never encounter a situation in which
>>> an interrupt occurs at TPL_HIGH_LEVEL.
>>>
>>> Restoring TPL to TPL_HIGH_LEVEL is always a no-op.  Return immediately
>>> from NestedInterruptRestoreTPL(TPL_HIGH_LEVEL), so that we do not need
>>> to consider the effect of this possible invariant violation on the
>>> remainder of the logic.
>>
>> Feels like the handling logic might as well be "panic" here (except edk2
>> does not have a central panic API that's suitable for all platforms). I
>> probably missed the previous discussion that led to this patch. Either
>> way, it seems reasonable.
>>
>> Acked-by: Laszlo Ersek 
> 
> Thank you.  We can't panic because there are some bootloaders (*cough*
> Microsoft *cough*) that illegally call RaiseTPL(TPL_HIGH_LEVEL) and then
> even more illegally enable interrupts via STI.  Gerd tracked this down
> before, which lead to commit
> 
>   https://github.com/tianocore/edk2/commit/bee67e0c1
> 
> I found another way to trigger a RestoreTPL(TPL_HIGH_LEVEL) while I was
> testing the self-tests by deliberately breaking
> DisableInterruptsOnIret() to fail to disable interrupts.  This also
> induces a situation in which we end up at TPL_HIGH_LEVEL with interrupts
> enabled.
> 
> This ended up triggering an assertion (due to the invariant violation)
> in NestedInterruptRestoreTPL() before reaching the point in the
> self-test that would have reported a more meaningful error message.
> 
> Adding the bypass is justifiable on its own merits (as per the reasoning
> in the commit), and it avoids needing to add clutter to the complex
> logic in NestedInterruptRestoreTPL() just to ensure that the self-test
> fails on the desired ASSERT().
> 
> I decided against trying to explain all that in the commit message, but
> I can have a go if you think it needs to be captured.  :)

Ugh, no, thanks :) This should suffice! :)
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114286): https://edk2.groups.io/g/devel/message/114286
Mute This Topic: https://groups.io/mt/103911606/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 1/1] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0

[Laszlo Ersek]

On 1/23/24 17:11, Gerd Hoffmann wrote:
>   Hi,
> 
> Well, it's OVMF in a virtual machine.  No boot guard involved.
> So we could probably go for a OVMF-specific patch here.
>
> But I'd prefer to figure what exactly is happening here before going
> down that route.  An extreme slowdown just because we flip that bit
> doesn't make sense to me.
>
>> Why is boot time increasing?
>
> Not clear.  It seems to be the lzma uncompress of the firmware volume
> in rom / pflash which is very slow.  Also it is apparently only
> triggered in case pci device assignment is used.

 I've seen extreme slowness on physical platforms when we've mixed up the
 MTRRs or page tables, causing code to be mapped uncached.

 Lzma uncompress of ROM could be pretty slow as well, if the ROM is being
 read uncached.  Lzma probably reads the data a byte at a time, which is the
 worst case for uncached accesses.  Since this is a VM, it's not actually
 uncached at the hardware level, but I don't know how QEMU/KVM handles
 uncached guest mappings It may be doing a VMEXIT for every byte.

 Anyway, I suggest double-checking your page tables and MTRRs.
>>>
>>> It happens very early at boot, before MTRRs are setup, running on the
>>> initial page tables created by the OVMF reset vector.  The initial page
>>> tables have just 'accessed', 'dirty', 'read/write' and 'present' bits
>>> set for the 0-4G identity mapping.
>>>
>>> It seems to have something to do with EPT.  It does not happen on AMD
>>> processors.  It also does not happen when disabling EPT support in kvm
>>> on the host machine.
>>>
>>> looked at kvm kernel traces, I don't see excessive vmexits.
>>
>> This discussion evokes vague memories in me. I'll dump them here, but I
>> have no idea if they will be useful. (They probably won't.)
>>
>> - edk2 commit 98f378a7be12 ("OvmfPkg/ResetVector: enable caching in
>> initial page tables", 2013-09-24)
>>
>> - Linux (host) commit 879ae1880449 ("KVM: x86: obey
>> KVM_X86_QUIRK_CD_NW_CLEARED in kvm_set_cr0()", 2015-11-04)
> 
> I actually waded through the source code in both places ;)
> 
> Turned out kvm propagates guest MTRR settings to EPT memory types,
> but only in case kvm_arch_has_noncoherent_dma() is true, which why
> this triggers only with a mdev device assigned.

... I should not have stopped myself. :)

(I'm aware that this is on edk2-devel, but a public reference to
virt-staff cannot hurt.)

So, yesterday I read your status on virt-staff, and I found an entry in
it that resembled this upstream thread pretty closely. However, your
status was the *only* mention of "mdev" specifically, and so I wasn't
sure if *mdev* meant the same thing as the more generic upstream
expression "pci device assignment" (see it above in the context).

Furthermore, I saw kvm_arch_has_noncoherent_dma() in my linux commit
879ae1880449, which superficially resembled device assignment, but... I
dismissed it. In the end, I only managed (and even that, only
reluctantly) the above pointers... Thanks for tracking it down!

But then, next question: why has this problem *not* been reported
repeatedly? There's a whole bunch of users (gamers) that run Windows
guests with device (GPU) assignment. I'm sure they'd absolutely complain
about very slow OVMF boot (like they actually have, in the past, about
similar LZMA slowdowns due to improper caching setup).

Something must be special about Min's assigned device.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114285): https://edk2.groups.io/g/devel/message/114285
Mute This Topic: https://groups.io/mt/100367559/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 5/5] MdeModulePkg: Extend NestedInterruptTplLib to support Arm CPUs

[Laszlo Ersek]

we include a
lib class header because we are implementing an instance for that lib
class (i.e., we're providing, not consuming, the definitions for the
header-declared variables and functions). In this case, neither seems to
apply, this is not an ArmLib instance (= implementation), and the macros
we need don't actually come from ArmLib.h.

Acked-by: Laszlo Ersek 

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114221): https://edk2.groups.io/g/devel/message/114221
Mute This Topic: https://groups.io/mt/103911611/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 4/5] MdeModulePkg: Add self-tests for NestedInterruptTplLib

[Laszlo Ersek]

icates that the timer
> +  // interrupt handler failed to rearm the timer before calling
> +  // NestedInterruptRestoreTPL().  This would prevent nested
> +  // interrupts from occurring at all, which would break
> +  // e.g. callbacks at TPL_CALLBACK that themselves wait on further
> +  // timer events.
> +  //
> +  // This error represents a bug in the platform-specific timer
> +  // interrupt handler.
> +  //
> +  DEBUG ((
> +DEBUG_ERROR,
> +"Nested interrupt self-test %u/%u failed: no nested interrupt\n",
> +SelfTestCount,
> +NUMBER_OF_SELF_TESTS
> +));
> +  ASSERT (FALSE);
> +}

I'd prefer something stronger than just ASSERT (FALSE) here, but -- per
previous discussion -- we don't have a generally accepted "panic" API
yet, and CpuDeadLoop() is not suitable for all platforms, so this should do.

With my trivial comments addressed:

Acked-by: Laszlo Ersek 

Comment on the general idea: I much like that the self-test is active on
every boot (without high costs).

Side idea: technically we could merge the first two patches in
separation (pending MdeModulePkg maintainer approval), and then consider
the last three patches as new improvements (possibly needing longer
review). This kind of splitting has both advantages and disadvantages;
the advantage is that the code movement / upstreaming to MdeModulePkg is
not blocked by (somewhat) unrelated discussion. The disadvantages are
that more admin work is needed (more posting, and more PRs), and that
patches in the series that one might consider to belong together will
fly apart in the git history. So I just figured I'd raise the option.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114219): https://edk2.groups.io/g/devel/message/114219
Mute This Topic: https://groups.io/mt/103911608/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 3/5] MdeModulePkg: Do nothing on NestedInterruptRestoreTPL(TPL_HIGH_LEVEL)

[Laszlo Ersek]

On 1/23/24 16:31, Michael Brown wrote:
> At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
> specification) and so we should never encounter a situation in which
> an interrupt occurs at TPL_HIGH_LEVEL.
> 
> Restoring TPL to TPL_HIGH_LEVEL is always a no-op.  Return immediately
> from NestedInterruptRestoreTPL(TPL_HIGH_LEVEL), so that we do not need
> to consider the effect of this possible invariant violation on the
> remainder of the logic.
> 
> Signed-off-by: Michael Brown 
> ---
>  MdeModulePkg/Library/NestedInterruptTplLib/Tpl.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/MdeModulePkg/Library/NestedInterruptTplLib/Tpl.c 
> b/MdeModulePkg/Library/NestedInterruptTplLib/Tpl.c
> index d56c12a44529..99af553ab189 100644
> --- a/MdeModulePkg/Library/NestedInterruptTplLib/Tpl.c
> +++ b/MdeModulePkg/Library/NestedInterruptTplLib/Tpl.c
> @@ -99,6 +99,19 @@ NestedInterruptRestoreTPL (
>EFI_TPL  SavedInProgressRestoreTPL;
>BOOLEAN  DeferredRestoreTPL;
>  
> +  //
> +  // At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
> +  // specification) and so we should never encounter a situation in
> +  // which InterruptedTPL==TPL_HIGH_LEVEL.
> +  //
> +  // Restoring TPL to TPL_HIGH_LEVEL is always a no-op.  Return
> +  // immediately so that we do not need to consider the effect of this
> +  // possible invariant violation in the logic below.
> +  //
> +  if (InterruptedTPL >= TPL_HIGH_LEVEL) {
> +return;
> +  }
> +
>//
>// If the TPL at which this interrupt occurred is equal to that of
>// the in-progress RestoreTPL() for an outer instance of the same

Feels like the handling logic might as well be "panic" here (except edk2
does not have a central panic API that's suitable for all platforms). I
probably missed the previous discussion that led to this patch. Either
way, it seems reasonable.

Acked-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114215): https://edk2.groups.io/g/devel/message/114215
Mute This Topic: https://groups.io/mt/103911606/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-discuss] Multi-ISA Driver Compatibility Survey

[Laszlo Ersek]

On 1/22/24 20:04, Rebecca Cran wrote:
> Originally posted at
> https://twitter.com/UEFIForum/status/1745518769232077208
> 
> The Multi-ISA Driver Compatibility Survey is at
> https://docs.google.com/forms/d/e/1FAIpQLScXjwaSBgLeqB1coEDxCPxho5JWF3AMqshOTJ2wd6Tf0He4LA/viewform
> 
> From that page:
> 
> Did you know Tiano today supports four 64-bit architectures, yet plug-in
> device OpRoms are still mostly limited to x64 and CSM? While
> binary-translation approaches are a useful stop-gap solution for both
> AArch64 and RV64 ecosystems, we need a common approach that is not a
> technical debt nightmare and that will be adopted by IHVs and endorsed
> by OSVs.
> 
> The  Multi-ISA Driver Compatibility talk went over some of the possible
> approaches, as a lead-in for an open discussion, and raised the
> long-term importance of solving cross-architecture compatibility issues
> for OpRom drivers.
> 
> This survey is an opportunity provide feedback to guide further
> exploration in this space.
> 
> The discussed options were:
> 
> - Do nothing. This is an IHV problem. IHV should continue shipping
> support for whatever architectures they deem necessary.
> - Resurrect EFI Byte Code. Invest in compilers and tooling (e.g.
> addr2line, JIT, etc) to get parity with existing native drivers.
> - Look at WASM, and solve tooling constraints (around sandboxing) that
> prevent adoption.
> - eBPF, and solve tooling constraints (around sandboxing) that prevent
> adoption.
> - Constrained, well-defined subset of x64. This meets IHVs half-way by
> avoiding significant perturbations to existing driver development and
> release processes, and achieves compatibility with existing x64 systems
> in the market "for free", while addressing most of the concerns around
> binary translation of x64 code.

This list seems too restrictive.

As long as IHVs are not interested in their cards booting on non-x86
boards, nothing sustainable can be done.

Assuming IHVs are *slightly* interested (which does not mean "full
support" at all), things can be done. Among those things, binary-based
approaches are all futile, IMO, because they do not allow for debugging
and improvements by the *board* vendor. EBC, WASM, eBFP, constrained X64
are all the same in this regard. If the original driver doesn't perform
proper mapping for DMA for example, that issue can only be identified
and fixed by *source-level* work.

IMO the only sustainable approach is if an IHV licenses the source code
of their driver (containing X64 shortcuts) to the vendor of the
(non-x86) board, preferably including documentation. Then the board
vendor can identify issues, and propose source-level fixes. That's less
burden on the IHV (mostly just regression testing on x86) than taking on
full support themselves. Regarding distribution, the non-x86 binaries
could be distributed on USB sticks (and loaded via Driver), possibly
even by the board vendor. Not super comfortable for the end-user, but it
would not intrude on the card flash (so the IHV wouldn't have to account
for it).

Of course this requires the IHV to be willing to show their source code
to the board vendor (possibly under NDA). Until that happens, this mess
will persist. In my opinion.

Either way, I believe that this option is not represented in the survey.

Laszlo

> 
> Note: the last three options (WASM, eBPF and constrained x64) are not
> neutral with respect to host natural register width, which will mean a
> break in compatibility with future TBD 128-bit environments, unless a
> TBD OpRom sandboxing technology is invented.
> 
> Note 2: emails and names/sign-ins are not collected, this is an
> anonymous response.
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114203): https://edk2.groups.io/g/devel/message/114203
Mute This Topic: https://groups.io/mt/103910445/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 1/1] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0

[Laszlo Ersek]

On 1/23/24 11:52, Gerd Hoffmann wrote:
> On Mon, Jan 22, 2024 at 01:11:52PM -0600, Brian J. Johnson wrote:
>> On 1/18/24 09:46, Gerd Hoffmann wrote:
>>> On Wed, Jan 10, 2024 at 04:43:47PM +, West, Catharine wrote:
 Disabling cache by default results in violation of BTG protections (if BTG 
 enabled).
 BIOS cannot assume that cache is disabled before it executes as ACM may be 
 required to enable NEM.

 Whatever solution needs to be done here cannot evict ACM-enabled NEM.
>>>
>>> Well, it's OVMF in a virtual machine.  No boot guard involved.
>>> So we could probably go for a OVMF-specific patch here.
>>>
>>> But I'd prefer to figure what exactly is happening here before going
>>> down that route.  An extreme slowdown just because we flip that bit
>>> doesn't make sense to me.
>>>
 Why is boot time increasing?
>>>
>>> Not clear.  It seems to be the lzma uncompress of the firmware volume
>>> in rom / pflash which is very slow.  Also it is apparently only
>>> triggered in case pci device assignment is used.
>>
>> I've seen extreme slowness on physical platforms when we've mixed up the
>> MTRRs or page tables, causing code to be mapped uncached.
>>
>> Lzma uncompress of ROM could be pretty slow as well, if the ROM is being
>> read uncached.  Lzma probably reads the data a byte at a time, which is the
>> worst case for uncached accesses.  Since this is a VM, it's not actually
>> uncached at the hardware level, but I don't know how QEMU/KVM handles
>> uncached guest mappings It may be doing a VMEXIT for every byte.
>>
>> Anyway, I suggest double-checking your page tables and MTRRs.
> 
> It happens very early at boot, before MTRRs are setup, running on the
> initial page tables created by the OVMF reset vector.  The initial page
> tables have just 'accessed', 'dirty', 'read/write' and 'present' bits
> set for the 0-4G identity mapping.
> 
> It seems to have something to do with EPT.  It does not happen on AMD
> processors.  It also does not happen when disabling EPT support in kvm
> on the host machine.
> 
> looked at kvm kernel traces, I don't see excessive vmexits.

This discussion evokes vague memories in me. I'll dump them here, but I
have no idea if they will be useful. (They probably won't.)

- edk2 commit 98f378a7be12 ("OvmfPkg/ResetVector: enable caching in
initial page tables", 2013-09-24)

- Linux (host) commit 879ae1880449 ("KVM: x86: obey
KVM_X86_QUIRK_CD_NW_CLEARED in kvm_set_cr0()", 2015-11-04)

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114202): https://edk2.groups.io/g/devel/message/114202
Mute This Topic: https://groups.io/mt/100367559/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] MdePkg/BaseCpuLibNull: Add stub function of StandardSignatureIsAuthenticAMD() in CpuLibNull instance

[Laszlo Ersek]

On 1/23/24 12:36, Huang, Qing wrote:
> CpuLib.h exposes StandardSignatureIsAuthenticAMD() API and we require stub 
> function in its BaseCpuLibNull library
> instance to avoid potential link issue.
> 
> Signed-off-by: Qing Huang 
> ---
>  MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c 
> b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> index 3ba7a35096..ba7981551d 100644
> --- a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> +++ b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> @@ -1,7 +1,7 @@
>  /** @file
>Null instance of CPU Library.
>  
> -  Copyright (c) 2020, Intel Corporation. All rights reserved.
> +  Copyright (c) 2020 - 2024, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
> @@ -35,3 +35,18 @@ CpuFlushTlb (
>)
>  {
>  }
> +
> +/**
> +  Determine if the standard CPU signature is "AuthenticAMD".
> +
> +  @retval TRUE  The CPU signature matches.
> +  @retval FALSE The CPU signature does not match.
> +**/
> +BOOLEAN
> +EFIAPI
> +StandardSignatureIsAuthenticAMD (
> +  VOID
> +  )
> +{
> +  return FALSE;
> +}

(1) Could we complete the Null instance with all the missing functions,
in one go? Such as: InitializeFloatingPointUnits,
StandardSignatureIsAuthenticAMD, GetCpuFamilyModel, GetCpuSteppingId?

(2) All four of the mentioned APIs are only declared for IA32 and X64,
by the lib class header. Therefore their stub implementations, including
that of StandardSignatureIsAuthenticAMD(), should be restricted to IA32
and X64 too.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114197): https://edk2.groups.io/g/devel/message/114197
Mute This Topic: https://groups.io/mt/103907626/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3] UefiCpuPkg: Fix issue that IsModified is wrongly set in PageTableMap

[Laszlo Ersek]

On 1/23/24 08:15, Zhiguang Liu wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4614
> 
> About the IsModified, current function doesn't consider that hardware
> also may change the pagetable. The issue is that in the first call of
> internal function PageTableLibMapInLevel, the function assume page
> table is not changed, and add ASSERT to check. But hardware may change
> the page table, which cause the ASSERT happens.
> Fix the issue by adding addtional condition to only check if the page
> table is changed when the software want to modify the page table.
> Also, add more comment to explain this behavior.
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Crystal Lee 
> Cc: Pedro Falcato 
> Signed-off-by: Zhiguang Liu 
> ---
>  .../Library/CpuPageTableLib/CpuPageTableMap.c  | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c 
> b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> index 36b2c4e6a3..ea6547970a 100644
> --- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> +++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> @@ -274,7 +274,7 @@ IsAttributesAndMaskValidForNonPresentEntry (
>  Page table entries that map the linear 
> address range are reset to 0 before set to the new attribute
>  when a new physical base address is set.
>@param[in]  Mask  The mask used for attribute. The 
> corresponding field in Attribute is ignored if that in Mask is 0.
> -  @param[out] IsModifiedTRUE means page table is modified. FALSE 
> means page table is not modified.
> +  @param[in, out] IsModifiedChange IsModified to True if page table 
> is modified and input parameter Modify is TRUE.
>  
>@retval RETURN_INVALID_PARAMETER  For non-present range, 
> Mask->Bits.Present is 0 but some other attributes are provided.
>@retval RETURN_INVALID_PARAMETER  For non-present range, 
> Mask->Bits.Present is 1, Attribute->Bits.Present is 1 but some other 
> attributes are not provided.
> @@ -294,7 +294,7 @@ PageTableLibMapInLevel (
>IN UINT64  Offset,
>IN IA32_MAP_ATTRIBUTE  *Attribute,
>IN IA32_MAP_ATTRIBUTE  *Mask,
> -  OUTBOOLEAN *IsModified
> +  IN OUT BOOLEAN *IsModified
>)
>  {
>RETURN_STATUS   Status;
> @@ -567,7 +567,10 @@ PageTableLibMapInLevel (
>  OriginalCurrentPagingEntry.Uint64 = CurrentPagingEntry->Uint64;
>  PageTableLibSetPle (Level, CurrentPagingEntry, Offset, Attribute, 
> );
>  
> -if (OriginalCurrentPagingEntry.Uint64 != CurrentPagingEntry->Uint64) 
> {
> +if (Modify && (OriginalCurrentPagingEntry.Uint64 != 
> CurrentPagingEntry->Uint64)) {
> +  //
> +  // The page table entry can be changed by this function only when 
> Modify is true.
> +  //
>*IsModified = TRUE;
>  }
>}
> @@ -609,7 +612,10 @@ PageTableLibMapInLevel (
>// Check if ParentPagingEntry entry is modified here is enough. Except the 
> changes happen in leaf PagingEntry during
>// the while loop, if there is any other change happens in page table, the 
> ParentPagingEntry must has been modified.
>//
> -  if (OriginalParentPagingEntry.Uint64 != ParentPagingEntry->Uint64) {
> +  if (Modify && (OriginalParentPagingEntry.Uint64 != 
> ParentPagingEntry->Uint64)) {
> +//
> +// The page table entry can be changed by this function only when Modify 
> is true.
> +//
>  *IsModified = TRUE;
>}
>  
> @@ -633,7 +639,9 @@ PageTableLibMapInLevel (
>   Page table entries that map the linear 
> address range are reset to 0 before set to the new attribute
>   when a new physical base address is set.
>@param[in]  Mask   The mask used for attribute. The 
> corresponding field in Attribute is ignored if that in Mask is 0.
> -  @param[out] IsModified TRUE means page table is modified. FALSE 
> means page table is not modified.
> +  @param[out] IsModified TRUE means page table is modified by 
> software or hardware. FALSE means page table is not modified by software.
> + If the output IsModified is FALSE, there is 
> possibility that the page table is changed by hardware. It is ok
> + because page table can be changed by 
> hardware anytime, and caller don't need to Flush TLB.
>  
>@retval RETURN_UNSUPPORTED   

Re: [edk2-devel] [PATCH v2 2/2] MdeModulePkg: Add missing Iret.h to NestedInterruptTplLib sources list

[Laszlo Ersek]

On 1/20/24 18:08, Michael Brown wrote:
> Suggested-by: Ray Ni 
> Signed-off-by: Michael Brown 
> ---
>  .../Library/NestedInterruptTplLib/NestedInterruptTplLib.inf  | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/MdeModulePkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf 
> b/MdeModulePkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
> index 1e03e1364e0f..f130d6dcd213 100644
> --- a/MdeModulePkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
> +++ b/MdeModulePkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
> @@ -20,6 +20,7 @@ [Defines]
>  
>  [Sources]
>Tpl.c
> +  Iret.h
>Iret.c
>  
>  [Packages]

(1) Please add a sentence to the commit message body: "This will allow
the build system to notice changes to Iret.h".

(The statement may be trivial :) I just don't like it when a commit
message only consists of a subject line.)

Thanks for considering!

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114141): https://edk2.groups.io/g/devel/message/114141
Mute This Topic: https://groups.io/mt/103852903/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/2] MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg

[Laszlo Ersek]

Two comments:

On 1/20/24 18:08, Michael Brown wrote:
> NestedInterruptTplLib provides a way for timer interrupt handlers
> (which must support nested interrupts) to prevent unbounded stack
> consumption.
>
> The underlying issue was first observed in OvmfPkg, since interrupt
> storms can arise more easily in virtual machines due to CPU
> starvation.  However, careful investigation shows that the unbounded
> stack consumption can also occur in physical machines.
>
> Move NestedInterruptTplLib from OvmfPkg to MdeModulePkg so that it can
> more easily be consumed by drivers outside of OvmfPkg.
>
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Gerd Hoffmann 
> Cc: Michael D Kinney 
> Signed-off-by: Michael Brown 
> ---
>  MdeModulePkg/MdeModulePkg.dec | 4 
>  OvmfPkg/OvmfPkg.dec   | 4 
>  OvmfPkg/AmdSev/AmdSevX64.dsc  | 2 +-
>  OvmfPkg/CloudHv/CloudHvX64.dsc| 2 +-
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc  | 2 +-
>  OvmfPkg/Microvm/MicrovmX64.dsc| 2 +-
>  OvmfPkg/OvmfPkgIa32.dsc   | 2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc| 2 +-
>  OvmfPkg/OvmfPkgX64.dsc| 2 +-
>  OvmfPkg/OvmfXen.dsc   | 2 +-
>  UefiPayloadPkg/UefiPayloadPkg.dsc | 2 +-
>  .../Library/NestedInterruptTplLib/NestedInterruptTplLib.inf   | 2 +-
>  OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf   | 1 +
>  .../Include/Library/NestedInterruptTplLib.h   | 0
>  .../Library/NestedInterruptTplLib/Iret.h  | 0
>  .../Library/NestedInterruptTplLib/Iret.c  | 0
>  {OvmfPkg => MdeModulePkg}/Library/NestedInterruptTplLib/Tpl.c | 0
>  17 files changed, 15 insertions(+), 14 deletions(-)
>  rename {OvmfPkg => 
> MdeModulePkg}/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf (91%)
>  rename {OvmfPkg => MdeModulePkg}/Include/Library/NestedInterruptTplLib.h 
> (100%)
>  rename {OvmfPkg => MdeModulePkg}/Library/NestedInterruptTplLib/Iret.h (100%)
>  rename {OvmfPkg => MdeModulePkg}/Library/NestedInterruptTplLib/Iret.c (100%)
>  rename {OvmfPkg => MdeModulePkg}/Library/NestedInterruptTplLib/Tpl.c (100%)
>
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index a2cd83345f5b..d6fb729af5a7 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -169,6 +169,10 @@ [LibraryClasses]
>#
>ImagePropertiesRecordLib|Include/Library/ImagePropertiesRecordLib.h
>
> +  ##  @libraryclass  Handle TPL changes within nested interrupt handlers
> +  #
> +  NestedInterruptTplLib|Include/Library/NestedInterruptTplLib.h
> +
>  [Guids]
>## MdeModule package token space guid
># Include/Guid/MdeModulePkgTokenSpace.h
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index b44fa039f76c..05d43d5a6861 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -41,10 +41,6 @@ [LibraryClasses]
>#
>MemEncryptTdxLib|Include/Library/MemEncryptTdxLib.h
>
> -  ##  @libraryclass  Handle TPL changes within nested interrupt handlers
> -  #
> -  NestedInterruptTplLib|Include/Library/NestedInterruptTplLib.h
> -
>##  @libraryclass  Save and restore variables using a file
>#
>NvVarsFileLib|Include/Library/NvVarsFileLib.h
> diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
> index a31a89344a60..80456f878a22 100644
> --- a/OvmfPkg/AmdSev/AmdSevX64.dsc
> +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
> @@ -354,7 +354,7 @@ [LibraryClasses.common.DXE_DRIVER]
>  !endif
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> -  
> NestedInterruptTplLib|OvmfPkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
> +  
> NestedInterruptTplLib|MdeModulePkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
>
> QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
>
> diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
> index b522fa10594d..9c6c68ae2c35 100644
> --- a/OvmfPkg/CloudHv/CloudHvX64.dsc
> +++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
> @@ -394,7 +394,7 @@ [LibraryClasses.common.DXE_DRIVER]
>  !endif
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf

Re: [edk2-devel] Memory Attribute for depex section

[Laszlo Ersek]

On 1/19/24 05:43, Nhi Pham wrote:
> On 1/18/2024 9:49 PM, Laszlo Ersek wrote:
>>>>> but I'd prefer to just remove this
>>>>> optimization from standalone MM, given that not only a) it shouldn't
>>>>> have to deal with a large number of protocol GUIDs, but also b) the
>>>>> driver dispatch is much more straight-forward. (Typically, StMM
>>>>> drivers can be dispatched in the order they appear in the firmware
>>>>> volume, in which case each DEPEX is evaluated only once anyway)
>>>>
>>>> Sounds like a promising basis for removing the optimization indeed!
>>>>
>>>
>>> Your patch suggested earlier works for me. And I don't see significant
>>> performance reduction compared with keeping optimization.
>>>
>>> I don't have strong reason on removing the optimization, but I think it
>>> would be simply good for now. Could you post your patch to edk2-devel
>>> for review and merge?
>>
>> That wouldn't be correct; I don't have any platform for testing StMM. I
>> proposed the patch purely based on code analysis. I prefer not to post
>> untested patches, if I can avoid it.
> 
> I got it, thanks!
> 
> I thought I could give Tested-by tag when you post the patch since I
> already verified the patch on a StMM platform

Oh, that seems to have eluded me, sorry -- it's not uncommon that a
patch submitter needs help with testing (external testing) on *some*
platforms, beside his or her main platform(s) of interest. What's quite
uncommon though is total untestability for the submitter; I admit I drew
a blank there. What you mention would have been viable.

Thank you for posting the patch, ultimately!
Laszlo

> 
>>
>> You can however post my patch; simply add your S-o-b at the bottom. You
>> can also preserve my authorship on the patch with --author=... on
>> git-commit; but even that is unnecessary for such a simple patch (you
>> don't even have to pick the patch up from the email, it's trivial to
>> reimplement from scratch, just reading the email).
> 
> I'm going to send the patch to edk2-devel and keep your authorship on
> the patch because there is no change compared with your suggestion in
> the email.
> 
> Thanks,
> Nhi
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114048): https://edk2.groups.io/g/devel/message/114048
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] StandaloneMmPkg/Core: Remove optimization for depex evaluation

[Laszlo Ersek]

On 1/19/24 05:56, Nhi Pham wrote:
> From: Laszlo Ersek 
> 
> The current dependency evaluator violates the memory access permission
> when patching depex grammar directly in the read-only depex memory area.
> 
> Laszlo pointed out the optimization issue in the thread (1) "Memory
> Attribute for depex section" and provided suggested patch to remove the
> perf optimization.
> 
> In my testing, removing the optimization does not make significant perf
> reduction. That makes sense that StandaloneMM dispatcher only searches
> in MM protocol database and does not depend on UEFI/DXE protocol
> database. Also, we don't have many protocols in StandaloneMM like
> UEFI/DXE.
> 
> From Laszlo,
> 
> "The patch removes the EFI_DEP_REPLACE_TRUE handling altogether, plus it
> CONST-ifies the Iterator pointer (which points into the DEPEX section),
> so that the compiler catch any possible accesses at *build time* that
> would write to the write-protected DEPEX memory area."
> 
> (1) https://edk2.groups.io/g/devel/message/113531
> 
> Signed-off-by: Nhi Pham 
> ---
>  StandaloneMmPkg/Core/Dependency.c | 37 
>  1 file changed, 7 insertions(+), 30 deletions(-)
> 
> diff --git a/StandaloneMmPkg/Core/Dependency.c 
> b/StandaloneMmPkg/Core/Dependency.c
> index 440fe3e45238..2bcb07d34666 100644
> --- a/StandaloneMmPkg/Core/Dependency.c
> +++ b/StandaloneMmPkg/Core/Dependency.c
> @@ -13,16 +13,6 @@
>  
>  #include "StandaloneMmCore.h"
>  
> -///
> -/// EFI_DEP_REPLACE_TRUE - Used to dynamically patch the dependency 
> expression
> -///to save time.  A EFI_DEP_PUSH is evaluated one an
> -///replaced with EFI_DEP_REPLACE_TRUE. If PI spec's 
> Vol 2
> -///Driver Execution Environment Core Interface use 
> 0xff
> -///as new DEPEX opcode. EFI_DEP_REPLACE_TRUE should 
> be
> -///defined to a new value that is not conflicting 
> with PI spec.
> -///
> -#define EFI_DEP_REPLACE_TRUE  0xff
> -
>  ///
>  /// Define the initial size of the dependency expression evaluation stack
>  ///
> @@ -170,12 +160,12 @@ MmIsSchedulable (
>IN  EFI_MM_DRIVER_ENTRY  *DriverEntry
>)
>  {
> -  EFI_STATUS  Status;
> -  UINT8   *Iterator;
> -  BOOLEAN Operator;
> -  BOOLEAN Operator2;
> -  EFI_GUIDDriverGuid;
> -  VOID*Interface;
> +  EFI_STATUS   Status;
> +  CONST UINT8  *Iterator;
> +  BOOLEAN  Operator;
> +  BOOLEAN  Operator2;
> +  EFI_GUID DriverGuid;
> +  VOID *Interface;
>  
>Operator  = FALSE;
>Operator2 = FALSE;
> @@ -253,8 +243,7 @@ MmIsSchedulable (
>Status = PushBool (FALSE);
>  } else {
>DEBUG ((DEBUG_DISPATCH, "  PUSH GUID(%g) = TRUE\n", ));
> -  *Iterator = EFI_DEP_REPLACE_TRUE;
> -  Status= PushBool (TRUE);
> +  Status = PushBool (TRUE);
>  }
>  
>  if (EFI_ERROR (Status)) {
> @@ -356,18 +345,6 @@ MmIsSchedulable (
>  DEBUG ((DEBUG_DISPATCH, "  RESULT = %a\n", Operator ? "TRUE" : 
> "FALSE"));
>  return Operator;
>  
> -  case EFI_DEP_REPLACE_TRUE:
> -CopyMem (, Iterator + 1, sizeof (EFI_GUID));
> -DEBUG ((DEBUG_DISPATCH, "  PUSH GUID(%g) = TRUE\n", ));
> -Status = PushBool (TRUE);
> -if (EFI_ERROR (Status)) {
> -  DEBUG ((DEBUG_DISPATCH, "  RESULT = FALSE (Unexpected error)\n"));
> -  return FALSE;
> -}
> -
> -Iterator += sizeof (EFI_GUID);
> -break;
> -
>default:
>  DEBUG ((DEBUG_DISPATCH, "  RESULT = FALSE (Unknown opcode)\n"));
>  goto Done;

looks good to me, thanks! (Can't give an R-b or A-b for a patch that was
originally written by me, just confirming that the code and commit
message look good.)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114047): https://edk2.groups.io/g/devel/message/114047
Mute This Topic: https://groups.io/mt/103824815/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] RFC: Folder layout change in UefiCpuPkg

[Laszlo Ersek]

On 1/19/24 11:17, Ni, Ray wrote:
> Chao,
> 
>  
> 
> In the plan A, CpuDxe.inf contains reference to
> gUefiCpuPkgTokenSpaceGuid.PcdCpuExceptionVectorBaseAddress in [Pcd]
> section. But I guess it’s only needed by LoongArch64. That’s why I
> didn’t like the common-inf idea.
> 
>  
> 
> But after looking at the other INF changes, I changed my mind. I think
> the common-inf looks good as the other INF files don’t have so much
> difference between LoonArch and x86.
> 
>  
> 
> So, I am ok with plan A. Thanks for preparing both changes for review.
> 
>  
> 
> Mike, Laszlo, Gerd, Abner, any comments?

I'm also OK with plan A.

Thanks
Laszlo

> 
>  
> 
>  
> 
> Thanks,
> 
> Ray
> 
> *From:* Chao Li 
> *Sent:* Thursday, January 18, 2024 4:27 PM
> *To:* Ni, Ray ; Sunil V L 
> *Cc:* devel@edk2.groups.io; Kinney, Michael D
> ; Laszlo Ersek ; Gerd
> Hoffmann ; Abner Chang 
> *Subject:* Re: [edk2-devel] RFC: Folder layout change in UefiCpuPkg
> 
>  
> 
> Hi Ray and Sunil,
> 
> Sorry, I'm late, I have very busy these days.
> 
> I created two PRs in my private repo.
> 
> *Plan A:*
> 
> Moved most of LoongArch libraries and drivers to current matching
> folders, removed LoongArch private INF, adjusted common INF.
> 
> URL: https://github.com/kilaterlee/edk2/pull/8
> <https://github.com/kilaterlee/edk2/pull/8>
> 
>  
> 
> *Plan B:*
> 
> Moved most of LoongArch libraries and drivers to current matching
> folders, keeping to use LoongArch private INF.
> 
> URL: https://github.com/kilaterlee/edk2/pull/9
> <https://github.com/kilaterlee/edk2/pull/9>
> 
>  
> 
> After you reading these two PRs, let's discuss how to deal with INF.
> 
> I prefer plan A, it is better to use the same INF for all ARCHs and have
> only one INF per modules. I was discussed this plan with Ray and Abner,
> but it was not allowed at the time.
> 
>  
> 
> Thanks,
> Chao
> 
> On 2024/1/16 08:59, Chao Li wrote:
> 
> OK, let me finish this work tomorrow, I'm a little busy today.
> 
> On 2024/1/15 16:11, Ni, Ray wrote:
> 
> Yes. Fine to me. Thanks!
> 
>  
> 
> Thanks,
> 
> Ray
> 
> -Original Message-
> 
> From: Sunil V L  
> <mailto:suni...@ventanamicro.com>
> 
> Sent: Monday, January 15, 2024 2:46 PM
> 
> To: Chao Li  <mailto:lic...@loongson.cn>
> 
> Cc: devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Ni, Ray 
>  <mailto:ray...@intel.com>; Kinney, Michael D
> 
>  <mailto:michael.d.kin...@intel.com>; 
> Laszlo Ersek  <mailto:ler...@redhat.com>; Gerd
> 
> Hoffmann  <mailto:kra...@redhat.com>
> 
> Subject: Re: [edk2-devel] RFC: Folder layout change in UefiCpuPkg
> 
>  
> 
> On Mon, Jan 15, 2024 at 02:17:09PM +0800, Chao Li wrote:
> 
> Ray and Sunil,
> 
>  
> 
> I plan send two example PRs to github to  show how to deal 
> the INFs, one to
> 
> adjust current INF, and another PR to move the libraris to 
> the current
> 
> folders. I hope after these two PRs are sent we can decide 
> what to do with
> 
> the INF. What do you think of this plan?
> 
>  
> 
>  
> 
> Hi Chao, That's fine with me.
> 
>  
> 
> Thanks,
> 
> Sunil
> 
> Thanks,
> 
> Chao
> 
> On 2024/1/15 13:44, Ni, Ray wrote:
> 
> That will be great!
> 
>  
> 
> Thanks,
> 
>     Ray
> 
> -Original Message-
> 
> From: Sunil V L 
> <mailto:suni...@ventanamicro.com>
> 
> Sent: Monday, January 15, 2024 12:44 PM
> 
> To: Ni, Ray 
> <mailto:ray...@intel.com>
> 
> Cc:devel@edk2.groups.io;lic...@loongson.cn 
> <mailto:Cc:devel@edk2.groups.io;lic...@loongson.cn>; Kinney, Michael D
> 
>  
> <mailto:michael.d.kin...@intel.com>; Laszlo Ersek 
> <mailto:ler...@redhat.com>; Gerd
> 
> Hoffmann <mailto:kra...@redhat.com>
> 
> Subject: Re: RFC: Folder layout change in UefiCpuPkg
> 
>  
> 
> O

Re: [edk2-devel] [PATCH 0/3] DxeTpm and DxeTpm2MeasureBootLib symbol rename

[Laszlo Ersek]

On 1/17/24 23:47, Doug Flick via groups.io wrote:
> OVMF is failing because it includes both DxeTpm2MeasureBootLib and
> DxeTpm2MeasureBootLib which makes the symbols collide. This patch
> renames the function names to be unique to avoid symbol collision.
> 
> Cc: Jiewen Yao 
> Cc: Rahul Kumar 
> 
> Signed-off-by: Doug Flick [MSFT] 
> 
> Douglas Flick [MSFT] (3):
>   SecurityPkg: DxeTpm2MeasureBootLib: SECURITY PATCH 4117/4118 symbol
> rename
>   SecurityPkg: DxeTpmMeasureBootLib: SECURITY PATCH 4117/4118 symbol
> rename
>   SecurityPkg: : Updating SecurityFixes.yaml after symbol rename
> 
>  .../DxeTpm2MeasureBootLibSanitization.h   |  8 +++---
>  .../DxeTpmMeasureBootLibSanitization.h|  8 +++---
>  .../DxeTpm2MeasureBootLib.c   |  8 +++---
>  .../DxeTpm2MeasureBootLibSanitization.c   |  8 +++---
>  .../DxeTpm2MeasureBootLibSanitizationTest.c   | 26 -
>  .../DxeTpmMeasureBootLib.c|  8 +++---
>  .../DxeTpmMeasureBootLibSanitization.c| 10 +++
>  .../DxeTpmMeasureBootLibSanitizationTest.c| 26 -
>  SecurityPkg/SecurityFixes.yaml| 28 +++
>  9 files changed, 68 insertions(+), 62 deletions(-)
> 

Merged as commit range b481b00f593e..264636d8e698, via
.

Best regards,
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114011): https://edk2.groups.io/g/devel/message/114011
Mute This Topic: https://groups.io/mt/103797461/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 0/6] OvmfPkg/VirtNorFlashDxe: fix corruption + misc small improvements

[Laszlo Ersek]

On 1/16/24 18:10, Gerd Hoffmann wrote:
> This is a little series containing the flash corruption fix sent
> yesterday with an slightly improved commit message and some small
> improvements on top of this.
> 
> v3:
>  - fix diagram
>  - fix DoErase control flow
>  - pick up reviewed-by tags
> v2:
>  - drop broken bugfix, fix the bug when introducing Start+End variables
>instead.
>  - add patch with UINTN and UINT32 casts.
>  - add patch splitting the DoErase code path into a new function.
>  - add the diagram sent by Laszlo.
> 
> Gerd Hoffmann (6):
>   OvmfPkg/VirtNorFlashDxe: add casts to UINTN and UINT32
>   OvmfPkg/VirtNorFlashDxe: clarify block write logic & fix shadowbuffer
> reads
>   OvmfPkg/VirtNorFlashDxe: add a loop for NorFlashWriteBuffer calls.
>   OvmfPkg/VirtNorFlashDxe: allow larger writes without block erase
>   OvmfPkg/VirtNorFlashDxe: ValidateFvHeader: unwritten state is EOL too
>   OvmfPkg/VirtNorFlashDxe: move DoErase code block into new function
> 
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.h|   2 +-
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c| 145 ++
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c |   5 +
>  3 files changed, 101 insertions(+), 51 deletions(-)
> 

Merged as commit range 59f024c76ee5..b481b00f593e, via
.

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114010): https://edk2.groups.io/g/devel/message/114010
Mute This Topic: https://groups.io/mt/103766773/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/2] OvmfPkg/Tcg2Config: remove unused TPM 1.2 support

[Laszlo Ersek]

On 1/17/24 15:12, Gerd Hoffmann wrote:
>> This patch is good:
>>
>> Reviewed-by: Laszlo Ersek 
>>
>> but the series shouldn't stop here. In "OvmfPkg/Tcg/Tcg2Config", we're
>> left with an INF file (Tcg2ConfigPei.inf) that still references
>> "Tpm12Support.h", and the common C source file "Tcg2ConfigPeim.c" still
>> calls the one API -- InternalTpm12Detect() -- declared in that header
>> file. The only remaining implementation of InternalTpm12Detect() is now
>> in "Tpm12SupportNull.c", and all it does is "return EFI_UNSUPPORTED".
>>
>> Therefore, in a subsequent patch, "Tpm12SupportNull.c" and
>> "Tpm12Support.h" should be removed, both from the tree, and from the
>> remaining INF file. Furthermore, the InternalTpm12Detect() call in
>> "Tcg2ConfigPeim.c", and everything that depends on the success of that
>> call, now counts as dead code, and should be removed.
>>
>> And *that* in turn means that we should also remove
>> "gEfiTpmDeviceInstanceTpm12Guid" from the [Guids] section of the
>> remaining INF file.
> 
> Yes, I noticed there is more to cleanup, but I wanted have something
> quick and proven (== identical to setting TPM1_ENABLE=FALSE) out of
> the door to fix the build / CI problems.

Right, I now see that this would eliminate the symbol conflict.

Either way, Jiewen has now reviewed Doug's patches for the symbol
conflict, so I'm going to merge those (and your v3 VirtNorFlashDxe
series, too).

Laszlo

> 
> Touching the code for additional cleanups requires a bit more attention
> and testing, I'll keep that on my radar though.
> 
> thanks & take care,
>   Gerd
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114005): https://edk2.groups.io/g/devel/message/114005
Mute This Topic: https://groups.io/mt/103764205/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Laszlo Ersek]

On 1/18/24 07:00, Nhi Pham wrote:
> Hi Laszlo,
> 
> On 1/16/2024 2:00 AM, Laszlo Ersek wrote:
>> On 1/15/24 15:04, Ard Biesheuvel wrote:
>>> On Mon, 15 Jan 2024 at 14:07, Nhi Pham 
>>> wrote:
>>>>
>>>> On 1/12/2024 4:45 PM, Laszlo Ersek wrote:
>>>>> (Independently: I think that's a valid thing to do for *SMM* drivers,
>>>>> because the entry point functions of those drivers are permitted to
>>>>> use
>>>>> both SMM and DXE/UEFI protocols. But whether the same is valid for the
>>>>> *standalone* MM drivers -- that looks questionable. Standalone MM
>>>>> drivers should not depend on UEFI/DXE protocols ever, IIUC.)
>>>>>
>>>>>> 3) The issue is patching the grammar in place, why can’t we just
>>>>>> make a
>>>>>> copy for the dispatcher grammer, and operate on the copy. Maybe via a
>>>>>> copy on 1st update strategy?
>>>>>
>>>>> Yes, copying the depex to the heap, and patching it there, was
>>>>> Nhi's #1
>>>>> fix proposal. I think that could be made work. But I'm not sure if the
>>>>> perf savings are worth the additional complexity. The heap allocation
>>>>> (where the writeable depex would exist) would have to be permanently
>>>>> associated with the loaded PE image -- because the dispatcher might
>>>>> need
>>>>> to reevaluate the depex across multiple rounds of dispatching. So
>>>>> that's
>>>>> a new field in some image-related structure, it also needs to be freed
>>>>> upon unload (?), what if the memory allocation fails during depex eval
>>>>> (just consider the depex to eval to FALSE?), etc. Doable, but
>>>>> hairy; not
>>>>> sure if the perf is worth that effort.
>>>>>
>>>>
>>>> Thanks so much, Laszlo for your valuable insights.
>>>>
>>>> The approach #1 works for me. I will do further check for your concerns
>>>> above.
>>>>
>>>> I'm trying your suggested patch and investigating the performance being
>>>> discussed here.
>>>>
>>>
>>> Not sure what approach #1 means,
>>
>> (copying the depex to the heap, and maintaining it there, so that it can
>> be patched)
> 
> Thanks!
> 
>>
>>> but I'd prefer to just remove this
>>> optimization from standalone MM, given that not only a) it shouldn't
>>> have to deal with a large number of protocol GUIDs, but also b) the
>>> driver dispatch is much more straight-forward. (Typically, StMM
>>> drivers can be dispatched in the order they appear in the firmware
>>> volume, in which case each DEPEX is evaluated only once anyway)
>>
>> Sounds like a promising basis for removing the optimization indeed!
>>
> 
> Your patch suggested earlier works for me. And I don't see significant
> performance reduction compared with keeping optimization.
> 
> I don't have strong reason on removing the optimization, but I think it
> would be simply good for now. Could you post your patch to edk2-devel
> for review and merge?

That wouldn't be correct; I don't have any platform for testing StMM. I
proposed the patch purely based on code analysis. I prefer not to post
untested patches, if I can avoid it.

You can however post my patch; simply add your S-o-b at the bottom. You
can also preserve my authorship on the patch with --author=... on
git-commit; but even that is unnecessary for such a simple patch (you
don't even have to pick the patch up from the email, it's trivial to
reimplement from scratch, just reading the email).

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113994): https://edk2.groups.io/g/devel/message/113994
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] MdePkg/BaseCacheMaintenanceLib: RV64 replace asserts with logs

[Laszlo Ersek]

On 1/18/24 10:50, Dhaval wrote:
> Some platforms do not implement cache management operations. Especially
> for DMA drivers have code to manage data cache. The code seem to depend
> on the underlying CPU/cache drivers to enact functionality and simply
> return if such functionality is not implemented. However this causes
> issue with CMO implementation which has an assert causing flow to
> hang within debug environment. While it is not an issue in production
> environment there is a recommendation to conver this assert in to
> a harmless logger message. Eventually platform/drivers need to have
> better guard for such functionality.
> 
> Signed-off-by: Dhaval Sharma 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Zhiguang Liu 
> Cc: Sunil V L 
> Cc: Andrei Warkentin 
> Cc: Laszlo Ersek 
> Cc: Pedro Falcato 
> Cc: Yang Cheng 
> ---
>  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c 
> b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> index 73a5a6b6b5d6..d99515bcf38b 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> @@ -183,9 +183,8 @@ WriteBackInvalidateDataCache (
>VOID
>)
>  {
> -  ASSERT (FALSE);
>DEBUG ((
> -DEBUG_ERROR,
> +DEBUG_VERBOSE,
>  "WriteBackInvalidateDataCache: RISC-V unsupported function.\n"
>  ));
>  }
> @@ -226,7 +225,9 @@ WriteBackInvalidateDataCacheRange (
>if (RiscVIsCMOEnabled ()) {
>  CacheOpCacheRange (Address, Length, CacheOpFlush);
>} else {
> -ASSERT (FALSE);
> +DEBUG (
> +  (DEBUG_VERBOSE, "WriteBackInvalidateDataCacheRange not supported \n")
> +  );
>}
>  
>return Address;

This formatting looks very strange, normally you'd write
  DEBUG ((

));

LGTM otherwise:

Acked-by: Laszlo Ersek 


> @@ -248,7 +249,7 @@ WriteBackDataCache (
>VOID
>)
>  {
> -  ASSERT (FALSE);
> +  DEBUG ((DEBUG_VERBOSE, "WriteBackDataCache not supported \n"));
>  }
>  
>  /**
> @@ -283,7 +284,7 @@ WriteBackDataCacheRange (
>if (RiscVIsCMOEnabled ()) {
>  CacheOpCacheRange (Address, Length, CacheOpClean);
>} else {
> -ASSERT (FALSE);
> +DEBUG ((DEBUG_VERBOSE, "WriteBackDataCacheRange not supported \n"));
>}
>  
>return Address;



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113993): https://edk2.groups.io/g/devel/message/113993
Mute This Topic: https://groups.io/mt/103805230/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] UefiCpuPkg: Fix issue that IsModified is wrongly set in PageTableMap

[Laszlo Ersek]

On 1/17/24 09:09, Zhiguang Liu wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4614
> 
> About the IsModified, current function doesn't consider that hardware
> also may change the pagetable. The issue is that in the first call of
> internal function PageTableLibMapInLevel, the function assume page
> table is not changed, and add ASSERT to check. But hardware may change
> the page table, which cause the ASSERT happens.
> Fix the issue by considering the hardware may also change page table,
> and document the detail in function header.
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Crystal Lee 
> Signed-off-by: Zhiguang Liu 
> ---
>  .../Library/CpuPageTableLib/CpuPageTableMap.c| 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c 
> b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> index 36b2c4e6a3..a3076ff2f6 100644
> --- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> +++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> @@ -274,7 +274,7 @@ IsAttributesAndMaskValidForNonPresentEntry (
>  Page table entries that map the linear 
> address range are reset to 0 before set to the new attribute
>  when a new physical base address is set.
>@param[in]  Mask  The mask used for attribute. The 
> corresponding field in Attribute is ignored if that in Mask is 0.
> -  @param[out] IsModifiedTRUE means page table is modified. FALSE 
> means page table is not modified.
> +  @param[in, out] IsModifiedChange IsModified to True if page table 
> is modified and input parameter Modify is TRUE.
>  
>@retval RETURN_INVALID_PARAMETER  For non-present range, 
> Mask->Bits.Present is 0 but some other attributes are provided.
>@retval RETURN_INVALID_PARAMETER  For non-present range, 
> Mask->Bits.Present is 1, Attribute->Bits.Present is 1 but some other 
> attributes are not provided.
> @@ -567,7 +567,10 @@ PageTableLibMapInLevel (
>  OriginalCurrentPagingEntry.Uint64 = CurrentPagingEntry->Uint64;
>  PageTableLibSetPle (Level, CurrentPagingEntry, Offset, Attribute, 
> );
>  
> -if (OriginalCurrentPagingEntry.Uint64 != CurrentPagingEntry->Uint64) 
> {
> +if (Modify && (OriginalCurrentPagingEntry.Uint64 != 
> CurrentPagingEntry->Uint64)) {
> +  //
> +  // The page table entry can be changed by this function only when 
> Modify is true.
> +  //
>*IsModified = TRUE;
>  }
>}
> @@ -609,7 +612,10 @@ PageTableLibMapInLevel (
>// Check if ParentPagingEntry entry is modified here is enough. Except the 
> changes happen in leaf PagingEntry during
>// the while loop, if there is any other change happens in page table, the 
> ParentPagingEntry must has been modified.
>//
> -  if (OriginalParentPagingEntry.Uint64 != ParentPagingEntry->Uint64) {
> +  if (Modify && (OriginalParentPagingEntry.Uint64 != 
> ParentPagingEntry->Uint64)) {
> +//
> +// The page table entry can be changed by this function only when Modify 
> is true.
> +//
>  *IsModified = TRUE;
>}
>  
> @@ -633,7 +639,9 @@ PageTableLibMapInLevel (
>   Page table entries that map the linear 
> address range are reset to 0 before set to the new attribute
>   when a new physical base address is set.
>@param[in]  Mask   The mask used for attribute. The 
> corresponding field in Attribute is ignored if that in Mask is 0.
> -  @param[out] IsModified TRUE means page table is modified. FALSE 
> means page table is not modified.
> +  @param[out] IsModified TRUE means page table is modified by 
> software or hardware. FALSE means page table is not modified by software.
> + If the output IsModified is FALSE, there is 
> possibility that the page table is changed by hardware. It is ok
> + because page table can be changed by 
> hardware anytime, and caller don't need to Flush TLB.
>  
>@retval RETURN_UNSUPPORTEDPagingMode is not supported.
>@retval RETURN_INVALID_PARAMETER  PageTable, BufferSize, Attribute or Mask 
> is NULL.

This patch looks good to me, thanks, except for one small wart: in the
documentation section of PageTableLibMapInLevel(), you change IsModified
from "@param[out]" to "@param[in, out]", which is correct, *but* a
similar change has been omitted for the actual parameter in the
param

Re: [edk2-devel] [PATCH v2 2/2] UefiCpuPkg/CpuMpPei: Don't write CR3 in ConvertMemoryPageToNotPresent

[Laszlo Ersek]

On 1/17/24 07:22, Zhiguang Liu wrote:
> The purpose of writing CR3 in ConvertMemoryPageToNotPresent is just
> to flush TLB, because CR3 won't be changed in function
> ConvertMemoryPageToNotPresent.
> After ConvertMemoryPageToNotPresent, there is always a flush TLB
> function. Also, because ConvertMemoryPageToNotPresent in called in a
> loop, to improve performance, there is no need to flush TLB
> inside ConvertMemoryPageToNotPresent. Just flushing TLB after the loop
> is enough.
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Zhiguang Liu 
> ---
>  UefiCpuPkg/CpuMpPei/CpuPaging.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/CpuPaging.c b/UefiCpuPkg/CpuMpPei/CpuPaging.c
> index 15c7015fb8..b923d9b502 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuPaging.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuPaging.c
> @@ -76,7 +76,8 @@ AllocatePageTableMemory (
>  
>  /**
>This function modifies the page attributes for the memory region specified
> -  by BaseAddress and Length to not present.
> +  by BaseAddress and Length to not present. This function only change page
> +  table, but not flush TLB. Caller have the responsbility to flush TLB.
>  
>Caller should make sure BaseAddress and Length is at page boundary.
>  
> @@ -167,7 +168,6 @@ ConvertMemoryPageToNotPresent (
>}
>  
>    ASSERT_EFI_ERROR (Status);
> -  AsmWriteCr3 (PageTable);
>return Status;
>  }
>  

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113946): https://edk2.groups.io/g/devel/message/113946
Mute This Topic: https://groups.io/mt/103781133/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/2] UefiCpuPkg/CpuPageTableLib: Enhance function header for PageTableMap()

[Laszlo Ersek]

On 1/17/24 07:21, Zhiguang Liu wrote:
> PageTableMap() only modifies the PageTable root pointer when creating from 
> zero.
> Explicitly explain it in function header.
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Zhiguang Liu 
> ---
>  UefiCpuPkg/Include/Library/CpuPageTableLib.h | 1 +
>  UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/UefiCpuPkg/Include/Library/CpuPageTableLib.h 
> b/UefiCpuPkg/Include/Library/CpuPageTableLib.h
> index 78aa83b8de..755c8ab084 100644
> --- a/UefiCpuPkg/Include/Library/CpuPageTableLib.h
> +++ b/UefiCpuPkg/Include/Library/CpuPageTableLib.h
> @@ -61,6 +61,7 @@ typedef enum {
>Create or update page table to map [LinearAddress, LinearAddress + Length) 
> with specified attribute.
>  
>@param[in, out] PageTable  The pointer to the page table to update, or 
> pointer to NULL if a new page table is to be created.
> + If not pointer to NULL, the value it points 
> to won't be changed in this function.
>@param[in]  PagingMode The paging mode.
>@param[in]  Buffer The free buffer to be used for page table 
> creation/updating.
>@param[in, out] BufferSize The buffer size.
> diff --git a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c 
> b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> index 36b2c4e6a3..25bd9fc8d8 100644
> --- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> +++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> @@ -620,6 +620,7 @@ PageTableLibMapInLevel (
>Create or update page table to map [LinearAddress, LinearAddress + Length) 
> with specified attribute.
>  
>@param[in, out] PageTable  The pointer to the page table to update, or 
> pointer to NULL if a new page table is to be created.
> + If not pointer to NULL, the value it points 
> to won't be changed in this function.
>@param[in]  PagingMode The paging mode.
>@param[in]  Buffer     The free buffer to be used for page table 
> creation/updating.
>@param[in, out] BufferSize The buffer size.

Reviewed-by: Laszlo Ersek 

(applying this is going to be difficult, because the patch emails were
not sent in response to a common cover letter, or in response to each other)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113945): https://edk2.groups.io/g/devel/message/113945
Mute This Topic: https://groups.io/mt/103781121/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 6/6] OvmfPkg/VirtNorFlashDxe: move DoErase code block into new function

[Laszlo Ersek]

On 1/16/24 18:11, Gerd Hoffmann wrote:
> Move the DoErase code block into a separate function, call the function
> instead of jumping around with goto.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 76 ++
>  1 file changed, 52 insertions(+), 24 deletions(-)
> 
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> index 3d1d20daa1e5..e6aaed27ceba 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> @@ -502,6 +502,38 @@ NorFlashRead (
>return EFI_SUCCESS;
>  }
>  
> +STATIC
> +EFI_STATUS
> +NorFlashWriteSingleBlockWithErase (
> +  INNOR_FLASH_INSTANCE  *Instance,
> +  INEFI_LBA Lba,
> +  INUINTN   Offset,
> +  IN OUTUINTN   *NumBytes,
> +  INUINT8   *Buffer
> +  )
> +{
> +  EFI_STATUS  Status;
> +
> +  // Read NOR Flash data into shadow buffer
> +  Status = NorFlashReadBlocks (Instance, Lba, Instance->BlockSize, 
> Instance->ShadowBuffer);
> +  if (EFI_ERROR (Status)) {
> +// Return one of the pre-approved error statuses
> +return EFI_DEVICE_ERROR;
> +  }
> +
> +  // Put the data at the appropriate location inside the buffer area
> +  CopyMem ((VOID *)((UINTN)Instance->ShadowBuffer + Offset), Buffer, 
> *NumBytes);
> +
> +  // Write the modified buffer back to the NorFlash
> +  Status = NorFlashWriteBlocks (Instance, Lba, Instance->BlockSize, 
> Instance->ShadowBuffer);
> +  if (EFI_ERROR (Status)) {
> +// Return one of the pre-approved error statuses
> +return EFI_DEVICE_ERROR;
> +  }
> +
> +  return EFI_SUCCESS;
> +}
> +
>  /*
>Write a full or portion of a block. It must not span block boundaries; 
> that is,
>Offset + *NumBytes <= Instance->BlockSize.
> @@ -607,7 +639,14 @@ NorFlashWriteSingleBlock (
>  // that we want to set. In that case, we will need to erase the block 
> first.
>  for (CurOffset = 0; CurOffset < *NumBytes; CurOffset++) {
>if (~(UINT32)OrigData[CurOffset] & (UINT32)Buffer[CurOffset]) {
> -goto DoErase;
> +Status = NorFlashWriteSingleBlockWithErase (
> +   Instance,
> +   Lba,
> +   Offset,
> +   NumBytes,
> +   Buffer
> +   );
> +return Status;
>}
>  
>OrigData[CurOffset] = Buffer[CurOffset];
> @@ -636,33 +675,22 @@ NorFlashWriteSingleBlock (
>  goto Exit;
>}
>  }
> -
> -Exit:
> -// Put device back into Read Array mode
> -SEND_NOR_COMMAND (Instance->DeviceBaseAddress, 0, P30_CMD_READ_ARRAY);
> -
> +  } else {
> +Status = NorFlashWriteSingleBlockWithErase (
> +   Instance,
> +   Lba,
> +   Offset,
> +   NumBytes,
> +   Buffer
> +   );
>  return Status;
>}
>  
> -DoErase:
> -  // Read NOR Flash data into shadow buffer
> -  Status = NorFlashReadBlocks (Instance, Lba, BlockSize, 
> Instance->ShadowBuffer);
> -  if (EFI_ERROR (Status)) {
> -// Return one of the pre-approved error statuses
> -return EFI_DEVICE_ERROR;
> -  }
> +Exit:
> +  // Put device back into Read Array mode
> +  SEND_NOR_COMMAND (Instance->DeviceBaseAddress, 0, P30_CMD_READ_ARRAY);
>  
> -  // Put the data at the appropriate location inside the buffer area
> -  CopyMem ((VOID *)((UINTN)Instance->ShadowBuffer + Offset), Buffer, 
> *NumBytes);
> -
> -  // Write the modified buffer back to the NorFlash
> -  Status = NorFlashWriteBlocks (Instance, Lba, BlockSize, 
> Instance->ShadowBuffer);
> -  if (EFI_ERROR (Status)) {
> -// Return one of the pre-approved error statuses
> -return EFI_DEVICE_ERROR;
> -  }
> -
> -  return EFI_SUCCESS;
> +  return Status;
>  }
>  
>  EFI_STATUS

Reviewed-by: Laszlo Ersek 

This series is now ready to be merged, but I'm unsure what the CI status
is, after the recent security fixes seem to have caused breakage with
multiple external definitions of the same symbol. For now I'll keep this
tagged, as a reminder for myself.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113944): https://edk2.groups.io/g/devel/message/113944
Mute This Topic: https://groups.io/mt/103766779/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/2] OvmfPkg/Tcg2Config: remove unused TPM 1.2 support

[Laszlo Ersek]

On 1/16/24 16:42, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf | 56 ---
>  OvmfPkg/Tcg/Tcg2Config/Tpm12Support.c | 83 ---
>  2 files changed, 139 deletions(-)
>  delete mode 100644 OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf
>  delete mode 100644 OvmfPkg/Tcg/Tcg2Config/Tpm12Support.c
> 
> diff --git a/OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf 
> b/OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf
> deleted file mode 100644
> index e8e0b88e6058..
> --- a/OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf
> +++ /dev/null
> @@ -1,56 +0,0 @@
> -## @file
> -# Set TPM device type - supports TPM 1.2 and 2.0
> -#
> -# In SecurityPkg, this module initializes the TPM device type based on a UEFI
> -# variable and/or hardware detection. In OvmfPkg, the module only performs 
> TPM
> -# hardware detection.
> -#
> -# Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
> -# Copyright (C) 2018, Red Hat, Inc.
> -#
> -# SPDX-License-Identifier: BSD-2-Clause-Patent
> -##
> -
> -[Defines]
> -  INF_VERSION= 0x00010005
> -  BASE_NAME  = Tcg2ConfigPei
> -  FILE_GUID  = 8AD3148F-945F-46B4-8ACD-71469EA73945
> -  MODULE_TYPE= PEIM
> -  VERSION_STRING = 1.0
> -  ENTRY_POINT= Tcg2ConfigPeimEntryPoint
> -
> -[Sources]
> -  Tcg2ConfigPeim.c
> -  Tpm12Support.h
> -  Tpm12Support.c
> -
> -[Packages]
> -  MdePkg/MdePkg.dec
> -  MdeModulePkg/MdeModulePkg.dec
> -  OvmfPkg/OvmfPkg.dec
> -  SecurityPkg/SecurityPkg.dec
> -
> -[LibraryClasses]
> -  PeimEntryPoint
> -  DebugLib
> -  PeiServicesLib
> -  Tpm2DeviceLib
> -  BaseLib
> -  Tpm12DeviceLib
> -
> -[Guids]
> -  gEfiTpmDeviceSelectedGuid   ## PRODUCES ## GUID # Used as a PPI 
> GUID
> -  gEfiTpmDeviceInstanceTpm20DtpmGuid  ## SOMETIMES_CONSUMES
> -  gEfiTpmDeviceInstanceTpm12Guid  ## SOMETIMES_CONSUMES
> -
> -[Ppis]
> -  gPeiTpmInitializationDonePpiGuid## SOMETIMES_PRODUCES
> -
> -[Pcd]
> -  gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid ## 
> PRODUCES
> -
> -[Depex.IA32, Depex.X64]
> -  gOvmfTpmMmioAccessiblePpiGuid
> -
> -[Depex.ARM, Depex.AARCH64]
> -  gOvmfTpmDiscoveredPpiGuid
> diff --git a/OvmfPkg/Tcg/Tcg2Config/Tpm12Support.c 
> b/OvmfPkg/Tcg/Tcg2Config/Tpm12Support.c
> deleted file mode 100644
> index c88da5758b44..
> --- a/OvmfPkg/Tcg/Tcg2Config/Tpm12Support.c
> +++ /dev/null
> @@ -1,83 +0,0 @@
> -/** @file
> -  Implement the InternalTpm12Detect() function on top of the Tpm12DeviceLib
> -  class.
> -
> -  Copyright (C) 2020, Red Hat, Inc.
> -
> -  SPDX-License-Identifier: BSD-2-Clause-Patent
> -**/
> -
> -#include 
> -#include 
> -
> -#include "Tpm12Support.h"
> -
> -#pragma pack (1)
> -typedef struct {
> -  TPM_RSP_COMMAND_HDRHdr;
> -  TPM_CURRENT_TICKS  CurrentTicks;
> -} TPM_RSP_GET_TICKS;
> -#pragma pack ()
> -
> -/**
> -  Probe for the TPM for 1.2 version, by sending TPM1.2 GetTicks
> -
> -  Sending a TPM1.2 command to a TPM2 should return a TPM1.2
> -  header (tag = 0xc4) and error code (TPM_BADTAG = 0x1e)
> -
> -  @retval EFI_SUCCESS  TPM version 1.2 probing successful.
> -
> -  @return  Error codes propagated from Tpm12SubmitCommand().
> -**/
> -STATIC
> -EFI_STATUS
> -TestTpm12 (
> -  )
> -{
> -  EFI_STATUS   Status;
> -  TPM_RQU_COMMAND_HDR  Command;
> -  TPM_RSP_GET_TICKSResponse;
> -  UINT32   Length;
> -
> -  Command.tag   = SwapBytes16 (TPM_TAG_RQU_COMMAND);
> -  Command.paramSize = SwapBytes32 (sizeof (Command));
> -  Command.ordinal   = SwapBytes32 (TPM_ORD_GetTicks);
> -
> -  Length = sizeof (Response);
> -  Status = Tpm12SubmitCommand (
> - sizeof (Command),
> - (UINT8 *),
> - ,
> - (UINT8 *)
> - );
> -  if (EFI_ERROR (Status)) {
> -return Status;
> -  }
> -
> -  return EFI_SUCCESS;
> -}
> -
> -/**
> -  Detect the presence of a TPM with interface version 1.2.
> -
> -  @retval EFI_SUCCESS  TPM-1.2 available. The Tpm12RequestUseTpm() and
> -   Tpm12SubmitCommand(TPM_ORD_GetTicks) operations
> -   (from the Tpm12DeviceLib class) have succeeded.
> -
> -  @return  Error codes propagated from Tpm12RequestUseTpm() 
> and
> -   Tpm12SubmitCommand().
> -**/
> -EFI_STATUS
> -InternalTpm12Detect (
> -  VOID
> -  )
> -{
> -  EFI_STATUS  Stat

Re: [edk2-devel] [PATCH 1/2] OvmfPkg: remove TPM1_ENABLE build option

[Laszlo Ersek]

xe.fdf.inc 
> b/OvmfPkg/Include/Fdf/OvmfTpmDxe.fdf.inc
> index 7fc2bf8590a4..bd0be8fedbd5 100644
> --- a/OvmfPkg/Include/Fdf/OvmfTpmDxe.fdf.inc
> +++ b/OvmfPkg/Include/Fdf/OvmfTpmDxe.fdf.inc
> @@ -3,9 +3,6 @@
>  ##
>  
>  !if $(TPM2_ENABLE) == TRUE
> -!if $(TPM1_ENABLE) == TRUE
> -INF  SecurityPkg/Tcg/TcgDxe/TcgDxe.inf
> -!endif
>  INF  SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
>  INF  SecurityPkg/Tcg/Tcg2PlatformDxe/Tcg2PlatformDxe.inf
>  INF  SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
> diff --git a/OvmfPkg/Include/Fdf/OvmfTpmPei.fdf.inc 
> b/OvmfPkg/Include/Fdf/OvmfTpmPei.fdf.inc
> index 9f8b9bdd5bed..add012afab67 100644
> --- a/OvmfPkg/Include/Fdf/OvmfTpmPei.fdf.inc
> +++ b/OvmfPkg/Include/Fdf/OvmfTpmPei.fdf.inc
> @@ -4,12 +4,7 @@
>  
>  !if $(TPM2_ENABLE) == TRUE
>  INF  OvmfPkg/Tcg/TpmMmioSevDecryptPei/TpmMmioSevDecryptPei.inf
> -!if $(TPM1_ENABLE) == TRUE
> -INF  OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf
> -INF  SecurityPkg/Tcg/TcgPei/TcgPei.inf
> -!else
>  INF  OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
> -!endif
>  INF  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
>  INF  SecurityPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf
>  !endif
> diff --git a/OvmfPkg/PlatformCI/ReadMe.md b/OvmfPkg/PlatformCI/ReadMe.md
> index 10fa32ac489f..33b89df17bc5 100644
> --- a/OvmfPkg/PlatformCI/ReadMe.md
> +++ b/OvmfPkg/PlatformCI/ReadMe.md
> @@ -14,7 +14,7 @@ supported and are described below.
>  | IA32| IA32   | OvmfPkgIa32.dsc | None  
>   |
>  | X64 | X64| OvmfPkgIa64.dsc | None  
>   |
>  | IA32 X64| PEI-IA32 DXE-X64   | OvmfPkgIa32X64.dsc  | None  
>   |
> -| IA32 X64 Full   | PEI-IA32 DXE-X64   | OvmfPkgIa32X64.dsc  | 
> SECURE_BOOT_ENABLE=1 SMM_REQUIRE=1 TPM1_ENABLE=1 TPM2_ENABLE=1 
> NETWORK_TLS_ENABLE=1 NETWORK_IP6_ENABLE=1 NETWORK_HTTP_BOOT_ENABLE=1 |
> +| IA32 X64 Full   | PEI-IA32 DXE-X64   | OvmfPkgIa32X64.dsc  | 
> SECURE_BOOT_ENABLE=1 SMM_REQUIRE=1 TPM2_ENABLE=1 NETWORK_TLS_ENABLE=1 
> NETWORK_IP6_ENABLE=1 NETWORK_HTTP_BOOT_ENABLE=1 |
>  
>  ## EDK2 Developer environment
>  

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113939): https://edk2.groups.io/g/devel/message/113939
Mute This Topic: https://groups.io/mt/103764206/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

[Laszlo Ersek]

On 1/16/24 16:16, Michael Brown wrote:
> On 16/01/2024 14:34, Laszlo Ersek wrote:
>> On 1/16/24 10:48, Michael Brown wrote:
>> IOW, my impression is that NestedInterruptTplLib can certainly handle
>> all scenarios thrown at it, but where it really matters is in the face
>> of an interrupt storm (not just "normal nesting"), and a storm is
>> unlikely (or even impossible?) on physical hardware.
>>
>> ... Oh, scratch that. "Interrupt storm" simply means that interrupts are
>> being delivered at a rate higher than the handler routine can service
>> them. IOW, the "storm" is not that interrupts are delivered *very
>> rapidly* in an absoulte sense. If interrupts are delivered at normal
>> frequency, but the handler is too slow to service *even that rate*, then
>> that also qualifies as "storm", because the nesting depth will *keep
>> growing*. It's not really the growth rate that matters; what matter is
>> the *trend*, i.e., the fact that there *is* growth (the stack gets
>> deeper and deeper). The stack might not overflow immediately, and if the
>> handler speeds up (for whatever reason), the stack might recover, but
>> there is nothing to prevent an overflow.
>>
>> So, in the end, I think you've convinced me.
> 
> :)
> 
>>> I'm happy to send a patch to migrate NestedInterruptTplLib to
>>> MdeModulePkg, so that it can be consumed outside of OvmfPkg.  Shall I do
>>> this?
>>
>> Sounds like a valid idea to me.
>>
>> Could be greatly supported by a test case (to be run on the bare metal)
>> installing a slow handler that *eventually* exhausted the stack, when
>> not using NestedInterruptTplLib.
>>
>> (FWIW, IIRC, the UEFI spec warns about this -- it says something like,
>> "return from TPL_HIGH as soon as you can, otherwise the system will
>> become unstable".)
>>
>> Sorry for the wall of text, I find this very difficult to reason about.
> 
> I also find it very difficult to reason about, which is why
> NestedInterruptRestoreTpl() has 126 lines of comments providing a
> semi-formal proof of correctness for a mere 15 statements of C code!
> 
> In particular, I find it difficult to reason about when it would be safe
> for a platform to *not* use NestedInterruptTplLib.  It's clearly
> empirically difficult to trigger stack underflow via an interrupt
> "storm" on physical hardware, but I'm not convinced it's impossible.
> 
> I find it mentally easier to rely on the hard guarantee that
> NestedInterruptTplLib provides: that nested interrupts will continue to
> be delivered but that the number of interrupt-induced stack frames is
> bounded by the (small, finite) number of distinct TPL levels in existence.
> 
> 
> 
> While developing NestedInterruptTplLib, I did hack together a test case
> for a slow handler that would deliberately induce an interrupt storm,
> since I needed this to test that my code was working.  When triggered,
> this test would cause the machine to effectively hang due to servicing
> an endless storm of timer interrupts.  Before NestedInterruptTplLib, the
> stack would soon underflow and would typically cause a reboot (or other
> crash).  With NestedInterruptTplLib the machine would continue to
> service interrupts indefinitely.
> 
> How might such a test case be included in upstream EDK2?  I'm
> peripherally aware of EDK2 test infrastructure such as UEFI SCT, but
> I've never interacted with it yet.

I'm vaguely aware of a unit test framework inside edk2, but the best I
can give you is just this link:

https://github.com/tianocore/edk2/tree/master/UnitTestFrameworkPkg#unit-test-framework-package

There are some files under the directory "MdeModulePkg/Test" too;
git-log on that subdir, and perhaps the MdeModulePkg maintainers, might
provide more pointers.

The end of the readme linked above says to ask Bret, Mike and Sean, as well.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113910): https://edk2.groups.io/g/devel/message/113910
Mute This Topic: https://groups.io/mt/103734961/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 6/6] OvmfPkg/VirtNorFlashDxe: move DoErase code block into new function

[Laszlo Ersek]

On 1/16/24 14:44, Laszlo Ersek wrote:
> On 1/15/24 16:59, Gerd Hoffmann wrote:
>> Move the DoErase code block into a separate function, call the function
>> instead of jumping around with goto.
>>
>> Signed-off-by: Gerd Hoffmann 
>> ---
>>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 76 +-
>>  1 file changed, 51 insertions(+), 25 deletions(-)
>>
>> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c 
>> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
>> index d80e9f0a2f3a..203bd64f2bdf 100644
>> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
>> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
>> @@ -502,6 +502,37 @@ NorFlashRead (
>>return EFI_SUCCESS;
>>  }
>>
>> +STATIC EFI_STATUS
> 
> (1) EFI_STATUS is not needed (and if it were needed, then we'd put it on
> a separate line)
> 
>> +NorFlashWriteSingleBlockWithErase (
>> +  INNOR_FLASH_INSTANCE  *Instance,
>> +  INEFI_LBA Lba,
>> +  INUINTN   Offset,
>> +  IN OUTUINTN   *NumBytes,
>> +  INUINT8   *Buffer
>> +  )
>> +{

Sigh. In your patch, I mistook / misread "EFI_STATUS" for "EFIAPI". :/

So, please ignore this; we obviously need the EFI_STATUS return type.

... Perhaps consider breaking "EFI_STATUS" to its own line.

(Strange how the brain works; my "mental alarm" about having typed
something foolish went off approx. 90 minutes after hitting Send --
while I was running outside. I know that some people get the best
programming ideas while showering...)

Sorry!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113909): https://edk2.groups.io/g/devel/message/113909
Mute This Topic: https://groups.io/mt/103741665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v7 25/37] ArmVirtPkg: Move PlatformBootManagerLib to OvmfPkg

[Laszlo Ersek]

On 1/16/24 12:54, Chao Li wrote:
> On 2024/1/15 16:46, Laszlo Ersek wrote:
>> On 1/12/24 09:25, Chao Li wrote:

>>> @@ -29,7 +29,6 @@
>>>QemuKernel.c
>>>  
>>>  [Packages]
>>> -  ArmVirtPkg/ArmVirtPkg.dec
>>>MdeModulePkg/MdeModulePkg.dec
>>>MdePkg/MdePkg.dec
>>>OvmfPkg/OvmfPkg.dec
>> Hmmm. This makes me wonder.
>>
>> If we can remove the ArmVirtPkg package dependency from the lib instance
>> in *this patch*, then we should be able to remove it *earlier* too
>> (i.e., independently), while the lib instance still exists under ArmVirtPkg.
>>
>> I don't see why the "ArmVirtPkg.dec" dep becomes superfluous *right here*.
>>
>> If I look at this INF file, as of commit 4a443f73fd67, I see at least
>> two "ArmVirtPkg.dec" dependencies:
>>
>> [FixedPcd]
>>   gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocol
>>
>> [Pcd]
>>   gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer
>>
>> In patch 24 ("ArmVirtPkg: Move two PCD variables into OvmfPkg"), you
>> move these PCDs to OvmfPkg.
>>
>> Ah, I understand now. In brief: this particular hunk belongs to patch 24
>> (where you correctly modify "PlatformBootManagerLib.inf" anyway). The
>> point is that, with the movement of both PCDs from the ArmVirt token
>> space to the OVMF token space, "PlatformBootManagerLib.inf"'s dependency
>> on "ArmVirtPkg.dec" disappears. Therefore the above hunk belongs to
>> patch 24.
>>
>> ... When you implement that, please build-test both patches 24 and 25.
>>
>> More precisely, your patch set should build at every stage, considering
>> both ArmVirt and OVMF platforms.
>>
>> The command "git rebase --exec" is useful for building a series at every
>> stage.
> 
> Do you means this change should belong in patch 24 is better?

Yes, please.

> 
> BTW, I did build and tested after applying patches 24 and 25(building
> and testing with ArmVirtQemu.dec) and it works fine.

Thank you.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113906): https://edk2.groups.io/g/devel/message/113906
Mute This Topic: https://groups.io/mt/103679477/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

[Laszlo Ersek]

On 1/16/24 10:48, Michael Brown wrote:
> On 16/01/2024 08:47, Gerd Hoffmann wrote:
>> I think the reason is that the next timer interrupt arriving while the
>> handler is running still is *much* more likely in virtual machines
>> because the vCPU does not get 100% of the of the physical CPU time
>> slice.
> 
> The interrupt handler can run for an arbitrary length of time, because
> the call to RestoreTPL() can end up calling an application callback
> which in turn waits on further timer interrupts.
> 
> This is a legitimate use case within UEFI, so all timer interrupt
> handlers (not just in virtual machines) need to allow for the
> possibility that nested interrupts will occur.

The more naive, original interrupt handler implementation (i.e., the one
without NestedInterruptTplLib) still "allowed" for nesting, simply by
virtue of letting itself be interrupted, if I remember correctly. That
in itself didn't cause a problem; the problem arose when this reentrant
interruption got limitlessly deep, due to interrupts having been queued
on the host side, and then being injected as a "storm" in the guest.

The naive handler impl. effectively translated the host-side "interrupt
queue" to a "guest side stack". "queue length" became "stack depth",
leading to stack overflow.

Thus, even the original (more naive) handler could work fine (for
nesting too) as long as there was no storm (put differently, as long as
queue length, aka stack depth, were small); is that correct? (I admit
that I can't really recall the details at this point.)

The sophistication of NestedInterruptTplLib is that it supports nesting
while *resisting* a storm (= preventing infinite nesting by careful
masking of interrupt delivery, IIRC). It does not eagerly slurp all
pending (queued) interrupts into the handler stack.

IOW, my impression is that NestedInterruptTplLib can certainly handle
all scenarios thrown at it, but where it really matters is in the face
of an interrupt storm (not just "normal nesting"), and a storm is
unlikely (or even impossible?) on physical hardware.

... Oh, scratch that. "Interrupt storm" simply means that interrupts are
being delivered at a rate higher than the handler routine can service
them. IOW, the "storm" is not that interrupts are delivered *very
rapidly* in an absoulte sense. If interrupts are delivered at normal
frequency, but the handler is too slow to service *even that rate*, then
that also qualifies as "storm", because the nesting depth will *keep
growing*. It's not really the growth rate that matters; what matter is
the *trend*, i.e., the fact that there *is* growth (the stack gets
deeper and deeper). The stack might not overflow immediately, and if the
handler speeds up (for whatever reason), the stack might recover, but
there is nothing to prevent an overflow.

So, in the end, I think you've convinced me.

> 
>> So on OVMF we will continue to need NestedInterruptTplLib.  I like the
>> idea to have a Null version of the library, so OVMF does not need its
>> own version of the driver just because of NestedInterruptTplLib.
> 
> I agree that there should not need to be two versions of LocalApicTimerDxe.
> 
> I would suggest moving NestedInterruptTplLib from OvmfPkg to MdeModulePkg.
> 
> The code is complex, but for the caller the complexity is completely
> hidden behind the calls to NestedInterruptRaiseTPL() and
> NestedInterruptRestoreTPL(), which straightforwardly replace what would
> otherwise be (unsafe) calls to RaiseTPL() and RestoreTPL(), as shown in
> 
> https://github.com/tianocore/edk2/commit/a086f4a#diff-1418ec21e24e4ce2f3d621113585e3bea11fbcfa3b77d54046e61be7928e0c92
> 
> For a new CPU architecture, the only requirement is to provide a short
> fragment (~5 lines) of code that can clear the interrupts-enabled flag
> in the EFI_SYSTEM_CONTEXT, as shown in
> OvmfPkg/Library/NestedInterruptTplLib/Iret.c.
> 
> I'm happy to send a patch to migrate NestedInterruptTplLib to
> MdeModulePkg, so that it can be consumed outside of OvmfPkg.  Shall I do
> this?

Sounds like a valid idea to me.

Could be greatly supported by a test case (to be run on the bare metal)
installing a slow handler that *eventually* exhausted the stack, when
not using NestedInterruptTplLib.

(FWIW, IIRC, the UEFI spec warns about this -- it says something like,
"return from TPL_HIGH as soon as you can, otherwise the system will
become unstable".)

Sorry for the wall of text, I find this very difficult to reason about.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113902): https://edk2.groups.io/g/devel/message/113902
Mute This Topic: https://groups.io/mt/103734961/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 6/6] OvmfPkg/VirtNorFlashDxe: move DoErase code block into new function

[Laszlo Ersek]

On 1/15/24 16:59, Gerd Hoffmann wrote:
> Move the DoErase code block into a separate function, call the function
> instead of jumping around with goto.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 76 +-
>  1 file changed, 51 insertions(+), 25 deletions(-)
>
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> index d80e9f0a2f3a..203bd64f2bdf 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> @@ -502,6 +502,37 @@ NorFlashRead (
>return EFI_SUCCESS;
>  }
>
> +STATIC EFI_STATUS

(1) EFI_STATUS is not needed (and if it were needed, then we'd put it on
a separate line)

> +NorFlashWriteSingleBlockWithErase (
> +  INNOR_FLASH_INSTANCE  *Instance,
> +  INEFI_LBA Lba,
> +  INUINTN   Offset,
> +  IN OUTUINTN   *NumBytes,
> +  INUINT8   *Buffer
> +  )
> +{
> +  EFI_STATUS  Status;
> +
> +  // Read NOR Flash data into shadow buffer
> +  Status = NorFlashReadBlocks (Instance, Lba, Instance->BlockSize, 
> Instance->ShadowBuffer);
> +  if (EFI_ERROR (Status)) {
> +// Return one of the pre-approved error statuses
> +return EFI_DEVICE_ERROR;
> +  }
> +
> +  // Put the data at the appropriate location inside the buffer area
> +  CopyMem ((VOID *)((UINTN)Instance->ShadowBuffer + Offset), Buffer, 
> *NumBytes);
> +
> +  // Write the modified buffer back to the NorFlash
> +  Status = NorFlashWriteBlocks (Instance, Lba, Instance->BlockSize, 
> Instance->ShadowBuffer);
> +  if (EFI_ERROR (Status)) {
> +// Return one of the pre-approved error statuses
> +return EFI_DEVICE_ERROR;
> +  }
> +
> +  return EFI_SUCCESS;
> +}

Good; "git-show --color-moved=zebra" is really helpful here.

What changes across the code movement is the BufferSizeInBytes argument
for the NorFlashReadBlocks / NorFlashWriteBlocks calls. Previously, we'd
pass in the local variable BlockSize, with type UINTN. After, we pass in
Instance->BlockSize, a UINT32. However, this is all fine, given that the
BufferSizeInBytes param of both callees is UINTN, and even the local
variable is assigned from Instance->BlockSize, pre-patch. OK.

> +
>  /*
>Write a full or portion of a block. It must not span block boundaries; 
> that is,
>Offset + *NumBytes <= Instance->BlockSize.
> @@ -606,7 +637,14 @@ NorFlashWriteSingleBlock (
>  // that we want to set. In that case, we will need to erase the block 
> first.
>  for (CurOffset = 0; CurOffset < *NumBytes; CurOffset++) {
>if (~(UINT32)OrigData[CurOffset] & (UINT32)Buffer[CurOffset]) {
> -goto DoErase;
> +Status = NorFlashWriteSingleBlockWithErase (
> +   Instance,
> +   Lba,
> +   Offset,
> +   NumBytes,
> +   Buffer
> +   );
> +goto Exit;
>}
>
>OrigData[CurOffset] = Buffer[CurOffset];
> @@ -635,33 +673,21 @@ NorFlashWriteSingleBlock (
>  goto Exit;
>}
>  }
> +  } else {
> +Status = NorFlashWriteSingleBlockWithErase (
> +   Instance,
> +   Lba,
> +   Offset,
> +   NumBytes,
> +   Buffer
> +   );
> +  }
>
>  Exit:
> -// Put device back into Read Array mode
> -SEND_NOR_COMMAND (Instance->DeviceBaseAddress, 0, P30_CMD_READ_ARRAY);
> +  // Put device back into Read Array mode
> +  SEND_NOR_COMMAND (Instance->DeviceBaseAddress, 0, P30_CMD_READ_ARRAY);
>
> -return Status;
> -  }
> -
> -DoErase:
> -  // Read NOR Flash data into shadow buffer
> -  Status = NorFlashReadBlocks (Instance, Lba, BlockSize, 
> Instance->ShadowBuffer);
> -  if (EFI_ERROR (Status)) {
> -// Return one of the pre-approved error statuses
> -return EFI_DEVICE_ERROR;
> -  }
> -
> -  // Put the data at the appropriate location inside the buffer area
> -  CopyMem ((VOID *)((UINTN)Instance->ShadowBuffer + Offset), Buffer, 
> *NumBytes);
> -
> -  // Write the modified buffer back to the NorFlash
> -  Status = NorFlashWriteBlocks (Instance, Lba, BlockSize, 
> Instance->ShadowBuffer);
> -  if (EFI_ERROR (Status)) {
> -// Return one of the pre-approved error statuses
> -return EFI_DEVICE_ERROR;
> -  }
> -
> -  return EFI_SUCCESS;
> +  return Status;
>  }
>
>  EFI_STATUS

(2) The extraction of the erase code path is fine, but how it is being
put to use is not identical to the pre-patch state.

The key observation is that, pre-patch, the Exit label is *semantically
local* to the "word-based writes" branch.

Of course this statement makes no sense at the C language level, because
labels are local to functions, not to blocks within functions. Either
way, the original logic is:

- if the logical update is too big (i.e., we don't run the word-based
optimization), just run DoErase. "Exit" is not reached, and we don't put
device back into 

Re: [edk2-devel] [PATCH v2 5/6] OvmfPkg/VirtNorFlashDxe: ValidateFvHeader: unwritten state is EOL too

[Laszlo Ersek]

On 1/15/24 16:59, Gerd Hoffmann wrote:
> It is possible to find variable entries with State being 0xff, i.e. not
> updated since flash block erase.   This indicates the variable driver
> could not complete the header write while appending a new entry, and
> therefore State was not set to VAR_HEADER_VALID_ONLY.
> 
> This can only happen at the end of the variable list, so treat this as
> additional "end of variable list" condition.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> index 8fcd999ac6df..c8b5e0be1379 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> @@ -302,6 +302,11 @@ ValidateFvHeader (
>break;
>  }
>  
> +if (VarHeader->State == 0xff) {
> +  DEBUG ((DEBUG_INFO, "%a: end of var list (unwritten state)\n", 
> __func__));
> +  break;
> +}
> +
>  VarName = NULL;
>  switch (VarHeader->State) {
>// usage: State = VAR_HEADER_VALID_ONLY

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113896): https://edk2.groups.io/g/devel/message/113896
Mute This Topic: https://groups.io/mt/103741666/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 4/6] OvmfPkg/VirtNorFlashDxe: allow larger writes without block erase

[Laszlo Ersek]

On 1/15/24 16:59, Gerd Hoffmann wrote:
> Raise the limit for writes without block erase from two to four
> P30_MAX_BUFFER_SIZE_IN_BYTES blocks.  With this in place almost all efi
> variable updates are handled without block erase.  With the old limit
> some variable updates (with device paths) took the block erase code
> path.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> index 67610d6920f7..d80e9f0a2f3a 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> @@ -550,13 +550,15 @@ NorFlashWriteSingleBlock (
>  return EFI_BAD_BUFFER_SIZE;
>}
>  
> -  // Pick P30_MAX_BUFFER_SIZE_IN_BYTES (== 128 bytes) as a good start for 
> word
> -  // operations as opposed to erasing the block and writing the data 
> regardless
> -  // if an erase is really needed.  It looks like most individual NV variable
> -  // writes are smaller than 128 bytes.
> -  // To avoid pathological cases were a 2 byte write is disregarded because 
> it
> -  // occurs right at a 128 byte buffered write alignment boundary, permit up 
> to
> -  // twice the max buffer size, and perform two writes if needed.
> +  // Pick 4 * P30_MAX_BUFFER_SIZE_IN_BYTES (== 512 bytes) as a good
> +  // start for word operations as opposed to erasing the block and
> +  // writing the data regardless if an erase is really needed.
> +  //
> +  // Many NV variable updates are small enough for a a single
> +  // P30_MAX_BUFFER_SIZE_IN_BYTES block write.  In case the update is
> +  // larger than a single block, or the update crosses a
> +  // P30_MAX_BUFFER_SIZE_IN_BYTES boundary (as shown in the diagram
> +  // below), or both, we might have to write two or more blocks.
>//
>//0   128  256
>//[|]
> @@ -577,7 +579,7 @@ NorFlashWriteSingleBlock (
>Start = Offset & ~BOUNDARY_OF_32_WORDS;
>End   = ALIGN_VALUE (Offset + *NumBytes, P30_MAX_BUFFER_SIZE_IN_BYTES);
>  
> -  if ((End - Start) <= (2 * P30_MAX_BUFFER_SIZE_IN_BYTES)) {
> +  if ((End - Start) <= (4 * P30_MAX_BUFFER_SIZE_IN_BYTES)) {
>  // Check to see if we need to erase before programming the data into NOR.
>  // If the destination bits are only changing from 1s to 0s we can just 
> write.
>  // After a block is erased all bits in the block is set to 1.

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113895): https://edk2.groups.io/g/devel/message/113895
Mute This Topic: https://groups.io/mt/103741664/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 3/6] OvmfPkg/VirtNorFlashDxe: add a loop for NorFlashWriteBuffer calls.

[Laszlo Ersek]

On 1/15/24 16:59, Gerd Hoffmann wrote:
> Replace the two NorFlashWriteBuffer() calls with a loop containing a
> single NorFlashWriteBuffer() call.
> 
> With the changes in place the code is able to handle updates larger
> than two P30_MAX_BUFFER_SIZE_IN_BYTES blocks, even though the patch
> does not actually change the size limit.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> index 54251633d0ee..67610d6920f7 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> @@ -521,6 +521,7 @@ NorFlashWriteSingleBlock (
>UINTN   BlockAddress;
>UINT8   *OrigData;
>UINTN   Start, End;
> +  UINT32  Index, Count;
>  
>DEBUG ((DEBUG_BLKIO, "NorFlashWriteSingleBlock(Parameters: Lba=%ld, 
> Offset=0x%x, *NumBytes=0x%x, Buffer @ 0x%08x)\n", Lba, Offset, *NumBytes, 
> Buffer));
>  
> @@ -620,23 +621,17 @@ NorFlashWriteSingleBlock (
>goto Exit;
>  }
>  
> -Status = NorFlashWriteBuffer (
> -   Instance,
> -   BlockAddress + Start,
> -   P30_MAX_BUFFER_SIZE_IN_BYTES,
> -   Instance->ShadowBuffer
> -   );
> -if (EFI_ERROR (Status)) {
> -  goto Exit;
> -}
> -
> -if ((End - Start) > P30_MAX_BUFFER_SIZE_IN_BYTES) {
> +Count = (End - Start) / P30_MAX_BUFFER_SIZE_IN_BYTES;
> +for (Index = 0; Index < Count; Index++) {
>Status = NorFlashWriteBuffer (
>   Instance,
> - BlockAddress + Start + P30_MAX_BUFFER_SIZE_IN_BYTES,
> + BlockAddress + Start + Index * P30_MAX_BUFFER_SIZE_IN_BYTES,
>   P30_MAX_BUFFER_SIZE_IN_BYTES,
> - Instance->ShadowBuffer + P30_MAX_BUFFER_SIZE_IN_BYTES
> + Instance->ShadowBuffer + Index * 
> P30_MAX_BUFFER_SIZE_IN_BYTES
>   );
> +  if (EFI_ERROR (Status)) {
> +goto Exit;
> +  }
>  }
>  
>  Exit:

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113894): https://edk2.groups.io/g/devel/message/113894
Mute This Topic: https://groups.io/mt/103741663/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 2/6] OvmfPkg/VirtNorFlashDxe: clarify block write logic & fix shadowbuffer reads

[Laszlo Ersek]

On 1/15/24 16:59, Gerd Hoffmann wrote:
> Introduce 'Start' and 'End' variables to make it easier to follow the
> logic and code flow.  Also add a ascii art diagram (based on a
> suggestion by Laszlo).
>
> This also fixes the 'Size' calculation for the NorFlashRead() call.
> Without this patch the code will read only one instead of two
> P30_MAX_BUFFER_SIZE_IN_BYTES blocks in case '*NumBytes' is smaller than
> P30_MAX_BUFFER_SIZE_IN_BYTES but 'Offset + *NumBytes' is not, i.e. the
> update range crosses a P30_MAX_BUFFER_SIZE_IN_BYTES boundary.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 35 --
>  1 file changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> index 7f4743b00399..54251633d0ee 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> @@ -520,6 +520,7 @@ NorFlashWriteSingleBlock (
>UINTN   BlockSize;
>UINTN   BlockAddress;
>UINT8   *OrigData;
> +  UINTN   Start, End;
>
>DEBUG ((DEBUG_BLKIO, "NorFlashWriteSingleBlock(Parameters: Lba=%ld, 
> Offset=0x%x, *NumBytes=0x%x, Buffer @ 0x%08x)\n", Lba, Offset, *NumBytes, 
> Buffer));
>
> @@ -555,7 +556,27 @@ NorFlashWriteSingleBlock (
>// To avoid pathological cases were a 2 byte write is disregarded because 
> it
>// occurs right at a 128 byte buffered write alignment boundary, permit up 
> to
>// twice the max buffer size, and perform two writes if needed.
> -  if ((*NumBytes + (Offset & BOUNDARY_OF_32_WORDS)) <= (2 * 
> P30_MAX_BUFFER_SIZE_IN_BYTES)) {
> +  //
> +  //0   128  256
> +  //[|]
> +  //^ ^ ^ ^
> +  //| | | |
> +  //| | |End, the next "word" boundary beyond
> +  //| | |the (logical) update
> +  //| | |
> +  //| | (Offset & 0x7F) + NumBytes; i.e., the Offset inside
> +  //| | (or just past) the *double-word* such that Offset is
> +  //| | the *exclusive* end of the (logical) update.

Obviously, when I proposed this diagram, I messed up this text.

Clearly, there's no better time for making a mistake in a comment than
when complaining about comments... :)

Two warts:

- 0x7F has not been replaced with BOUNDARY_OF_32_WORDS

- the uppercase "Offset" identifier (= proper noun), from my original
proposal, is misleading here. The common noun "offset" is what's need.

So I suggest refreshing it as:

  //| | (Offset & BOUNDARY_OF_32_WORDS) + NumBytes;
  //| | i.e., the relative offset inside (or just past)
  //| | the *double-word* such that it is the
  //| | *exclusive* end of the (logical) update.

With that comment update:

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> +  //| |
> +  //| Offset & BOUNDARY_OF_32_WORDS; i.e., Offset within the 
> "word";
> +  //| this is where the (logical) update is supposed to start
> +  //|
> +  //Start = Offset & ~BOUNDARY_OF_32_WORDS; i.e., Offset truncated to 
> "word" boundary
> +
> +  Start = Offset & ~BOUNDARY_OF_32_WORDS;
> +  End   = ALIGN_VALUE (Offset + *NumBytes, P30_MAX_BUFFER_SIZE_IN_BYTES);
> +
> +  if ((End - Start) <= (2 * P30_MAX_BUFFER_SIZE_IN_BYTES)) {
>  // Check to see if we need to erase before programming the data into NOR.
>  // If the destination bits are only changing from 1s to 0s we can just 
> write.
>  // After a block is erased all bits in the block is set to 1.
> @@ -565,8 +586,8 @@ NorFlashWriteSingleBlock (
>  Status = NorFlashRead (
> Instance,
> Lba,
> -   Offset & ~BOUNDARY_OF_32_WORDS,
> -   (*NumBytes | BOUNDARY_OF_32_WORDS) + 1,
> +   Start,
> +   End - Start,
> Instance->ShadowBuffer
> );
>  if (EFI_ERROR (Status)) {
> @@ -601,7 +622,7 @@ NorFlashWriteSingleBlock (
>
>  Status = NorFlashWriteBuffer (
> Instance,
> -   BlockAddress + (Offset & ~BOUNDARY_OF_32_WORDS),
> +   BlockAddress + Start,
> P30_MAX_BUFFER_SIZE_IN_BYTES,
> Instance->ShadowBuffer
> );
> @@ -609,12 +630,10 @@ NorFlashWriteSingleBlock (
>goto Exit;
>  }
>
> -if ((*NumBytes + (Offset & BOUNDARY_O

Re: [edk2-devel] When TPM is enabled, Ubuntu doesn't boot

[Laszlo Ersek]

On 1/15/24 13:34, Hamit Can Karaca wrote:
> Hi Yao, Jiewen,
> I actually tried to get help from the ubuntu people but they really
> don't understand what is going in the UEFI side. I am trying to fix
> this problem for 3 weeks now and I am about the give up. I hope
> somebody can help me :(

The log you attached up-thread ends like this:

> FSOpen: Open '\EFI\ubuntu\BOOTX64.CSV' Success
> Tcg2GetCapability ...
> Size - 0x24
>  1.1 - 0x24, 1.0 - 0x1C
> Tcg2GetCapability - Success
> Reset System
> PROGRESS CODE: V0311100A I0
> DXE ResetSystem2: ResetType Cold, Call Depth = 1.

this is consistent with the "shim" project's "fallback" utility
resetting your system, when the TPM is enabled. In particular, the
"Reset System" message is printed by "fallback.c".

For getting a more verbose log, you can try setting the FALLBACK_VERBOSE
UEFI variable:

- boot Ubuntu with the TPM disabled (for now)

- in a root shell, issue the following command:

  mokutil --set-fallback-verbosity true

- reboot (then reenable the TPM)

This would give us some extra insight into fallback's thinking /
process.

However, even without the verbose fallback log, we can speculate. In
particular, in the fallback code and commit log, I've found the
following commit:

> commit 431b8a2e75a71a0b1f47d47d3f045b1e3efbce53
> Author: Peter Jones 
> Date:   Mon Jul 31 13:10:41 2017 -0400
>
> Make fallback aware of tpm measurements, and reboot if tpm is used.
>
> Since booting the entry with fallback in the stack of things that got
> measured will result in all the wrong PCR values, in the cases where TPM
> is present and enabled, use ->Reset() instead of loading the Boot
> variable and executing its target.
>
> Signed-off-by: Peter Jones 

The idea is that:

(1) you have an installed Ubuntu system

(2) for some reason, you don't have proper UEFI Boot options,
matching your installed Ubuntu OS.

(3) consequently, your platform firmware loads the default UEFI boot
loader, not a specific, designated OS boot loader

(4) it is actually "shim" that fills both roles (default / fallback boot
loader, and specific first stage OS boot loader too), however, shim
behaves differently, dependent on which role it is being invoked in. In
the former role, it invokes (IIUC) the "fallback" utility (also built
from the shim project).

(5) what the fallback utility does is that it tries to *recreate* your
missing UEFI Boot variables, and then *at once* proceed to booting
your Ubuntu OS. For the recreation of the variables, fallback looks at
the file "\EFI\ubuntu\BOOTX64.CSV", which is basically an alternative
(disk-based fallback) storage for boot option information. That's why
you see that file mentioned in the log; the file system driver reports
opening that file.

(6) Now, where I write "at once proceeds to booting your Ubuntu OS" is
where the TPM plays a part, and where the above-quoted commit is
relevant. The TPM measures the entire boot path, and if the boot path
changes, the values (= hash results) in the PCRs (platform config
registers) will not match those that the TPM expects. This means that
the TPM will not "unseal" secrets for you, such as a full disk (LUKS)
encryption key. Now, including the fallback utility in the boot process
is certainly a boot path change, so when fallback runs, and it detects
that a TPM is enabled (because it finds TPM-related UEFI protocols in
the protocol database), it *knows* that the TPM will "catch" the change
in the boot path. Therefore, after recreating the missing UEFI Boot
variables (boot options), fallback decides to *reboot* -- i.e., relaunch
the boot path from zero. Because next time around, the just-recreated
Boot options should take effect (i.e., fallback should not be part
of the next boot path), and then TPM should be happy too.

(7) Your problem actually seems to be that the Boot option
recreation step fails! The *first* reset itself is fine and justified
(with the TPM enabled); the problem is that fallback is reached during
*next boot* again. That should not happen; the Boot options should
be in place by then.

Your platform firmware (= motherboard) may be busted by design. Some
platform vendors do not permit the modification of Boot options.
This is actually "platform policy", so it is not a UEFI spec violation
per se. But the end result is that "fallback" cannot modify Boot
options, so it always try to re-create them, and always resets due to
the TPMs presence.

If you really want to enable the TPM, you might have to use the
"FB_NO_REBOOT" UEFI variable of shim. This is described in the following
shim commit:

> commit a5db51a52e8d4cae938fc807b991383309dffca7
> Author: Gary Lin 
> Date:   Wed May 23 18:13:05 2018 +0800
>
> fallback: show a countdown menu before reset
>
> Some machines with the faulty firmware may keep booting the default boot
> path instead of the boot option we create. To avoid the infinite reset
> loop, this commit 

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

[Laszlo Ersek]

On 1/15/24 19:10, Kinney, Michael D wrote:
> Hi Ray,
>
> I think nesting may be possible in physical platforms, but very hard
> to induce.
>
> One option is to consolidate to a single LocalApicTimerDxe
> implementation in the UefiCpuPkg, but allow the platform DSC to either
> specify a Null NestedInterruptTplLib for physical platforms or the
> full one from the OvmfPkg for VM use cases.
>
> The other changes could be included for OvmfPkg use cases.  If the VM
> does not support the CPUID leafs, then the PCD value should be used.

All of this sounds great!

(And I do think that *some* nesting should not be a problem, on either
physical or virtual platforms, as (IIRC) the interrupt handler stack can
accommodate a certain level of reentrancy. It's the "storm" that is a
problem, but that should never occur on physical machines, I reckon.)

Assuming a v2 is coming up, my advance request would be for Ray to
re-review the math in patch #4, before posting v2, focusing on integer
overflows, and SafeIntLib (if needed). I've not looked at the patch in
detail yet, but I reviewed something similar not so long ago [1]. The
latter frequency calculation code had been quite commonly used in edk2,
and I needed hours to review just that one patch. Plus, the review
turned up a number of issues to fix. So, preferably such a patch should
not only prevent any integer overflows, but also clarify, in comments,
why overflows are impossible, and/or how they are prevented.

[1] https://edk2.groups.io/g/devel/message/111613
2e42db7c-a927-f47b-7d80-632895b11e1b@redhat.com">http://mid.mail-archive.com/2e42db7c-a927-f47b-7d80-632895b11e1b@redhat.com

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113884): https://edk2.groups.io/g/devel/message/113884
Mute This Topic: https://groups.io/mt/103734961/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/4] OvmfPkg/VirtNorFlashDxe: fix corruption + misc small improvements

[Laszlo Ersek]

On 1/15/24 18:56, Ard Biesheuvel wrote:
> On Mon, 15 Jan 2024 at 11:21, Laszlo Ersek  wrote:
>>
>> On 1/12/24 12:37, Gerd Hoffmann wrote:
>>> This is a little series containing the flash corruption fix sent
>>> yesterday with an slightly improved commit message and some small
>>> improvements on top of this.
>>>
>>> Gerd Hoffmann (4):
>>>   OvmfPkg/VirtNorFlashDxe: fix shadowbuffer reads
>>>   OvmfPkg/VirtNorFlashDxe: clarify block write logic
>>>   OvmfPkg/VirtNorFlashDxe: allow larger writes without block erase
>>>   OvmfPkg/VirtNorFlashDxe: ValidateFvHeader: unwritten state is EOL too
>>>
>>>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c| 33 +++
>>>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c |  5 
>>>  2 files changed, 21 insertions(+), 17 deletions(-)
>>>
>>
>> Looking at the original code makes me throw a fit (no offense -- I don't
>> know who wrote it, and I don't want to check).
>>
> 
> Hi Laszlo,
> 
> I am not the author of the original code, but I suppose I should take
> at least some of the blame here, having added some of the logic to
> reduce the number of MMIO accesses (which are disproportionately
> expensive under virtualization), and this is where the bug got
> introduced afaict.

... sorry about being needlessly harsh. If it's any excuse: in all such
cases I make a fully committed, honest effort to dig down to the "roots"
of the code, and the more I struggle to form a mental image, the more
annoyed/stressed I get. Comments and diagrams would definitely help with
my efforts, but just because I get annoyed during first analysis, that
is not sufficient reason to let that *leak* to the list. It's a
personality defect on my end. I'll keep working on it.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113881): https://edk2.groups.io/g/devel/message/113881
Mute This Topic: https://groups.io/mt/103680930/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

[Laszlo Ersek]

On 1/15/24 09:59, Pedro Falcato wrote:
> On Mon, Jan 15, 2024 at 8:04 AM Ni, Ray  wrote:
>>
>> This commit only duplicates the OvmfPkg/LocalApicTimerDxe.
>> Following commits will enhance the driver.
> 
> Hi,
> 
> Please describe why you're doing this change. i.e what's your use case
> for LocalApicTimerDxe,

Right, I have the same question -- although, admittedly, I've not been
CC'd on the cover letter (0/6), and the reason could be captured there.
(I'm not going to check my edk2-devel folder again today, only finishing
up my personal INBOX. So tomorrow when I check edk2-devel, I might
actually find the reason in the cover letter.)

On a second thought, I'm (retroactively?) surprised that
LocalApicTimerDxe was (apparently?) first introduced under OvmfPkg --
i.e., for VMs? That's not impossible, but feels a bit strange.

> and why are you duplicating this instead of
> moving OvmfPkg's (why do we need to maintain 2 separate versions of
> what is essentially the same driver)?

Not wanting the NestedInterruptTplLib dependency / functionality in
UefiCpuPkg's instance of this driver seems justified (patch 2). Also,
patch 4 calculates the timer frequency based on CPUID; might not be
straightforward to use on VMs without prior verification.

The tricky parts to review in this series are the math in patch 4 (such
code is usually prone to integer overflows, so that's my concern by
default there), plus the big comment in patch 6.

I'll try to look at them later.

Meta-comment for Ray: patches like patch#1 are best formatted with the
option "--find-copies-harder" (try it please, the output speaks for itself).

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113847): https://edk2.groups.io/g/devel/message/113847
Mute This Topic: https://groups.io/mt/103734961/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/6] OvmfPkg/VirtNorFlashDxe: add casts to UINTN and UINT32

[Laszlo Ersek]

On 1/15/24 16:59, Gerd Hoffmann wrote:
> This is needed to avoid bit operations being applied to signed integers.
> 
> Suggested-by: László Érsek 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.h | 2 +-
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.h 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.h
> index b7f5d208b236..455eafacc2cf 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.h
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.h
> @@ -61,7 +61,7 @@
>  #define P30_MAX_BUFFER_SIZE_IN_BYTES  ((UINTN)128)
>  #define P30_MAX_BUFFER_SIZE_IN_WORDS  
> (P30_MAX_BUFFER_SIZE_IN_BYTES/((UINTN)4))
>  #define MAX_BUFFERED_PROG_ITERATIONS  1000
> -#define BOUNDARY_OF_32_WORDS  0x7F
> +#define BOUNDARY_OF_32_WORDS  ((UINTN)0x7F)
>  
>  // CFI Addresses
>  #define P30_CFI_ADDR_QUERY_UNIQUE_QRY  0x10

I've made an effort to audit all current (= pre-patch) uses of
BOUNDARY_OF_32_WORDS: the change looks safe.

> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> index 1afd60ce66eb..7f4743b00399 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> @@ -581,7 +581,7 @@ NorFlashWriteSingleBlock (
>  // contents, while checking whether the old version had any bits cleared
>  // that we want to set. In that case, we will need to erase the block 
> first.
>  for (CurOffset = 0; CurOffset < *NumBytes; CurOffset++) {
> -  if (~OrigData[CurOffset] & Buffer[CurOffset]) {
> +  if (~(UINT32)OrigData[CurOffset] & (UINT32)Buffer[CurOffset]) {
>  goto DoErase;
>}
>  

The explicit cast for the RHS is not strictly necessary (the same would
happen as a consequence of the cast being added to the LHS, through the
usual arithmetic conversions), *but* it definitely doesn't hurt, and
arguably improves readability.

Reviewed-by: Laszlo Ersek 

(I'll probably look at the rest of the patches tomorrow.)

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113846): https://edk2.groups.io/g/devel/message/113846
Mute This Topic: https://groups.io/mt/103741662/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 0/3] Support CloudHv guests with >1TB of RAM

[Laszlo Ersek]

On 1/15/24 17:13, Ard Biesheuvel wrote:
> On Mon, 15 Jan 2024 at 16:32, Ard Biesheuvel  wrote:
>>
>> On Mon, 15 Jan 2024 at 16:27, Gerd Hoffmann  wrote:
>>>
>>> On Fri, Jan 12, 2024 at 06:31:41PM +, Thomas Barrett wrote:
>>>> This series adds support for cloud-hypervisor guests with >1TiB
>>>> of RAM to Ovmf. This bug was solved for Qemu back in 2017
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1468526. The bug is
>>>> still occuring for CloudHv guests because the PlatformScanE820
>>>> utility is not currently supported for CloudHv.
>>>>
>>>> My working branch for these changes can be found here:
>>>> https://github.com/thomasbarrett/edk2/tree/cloud-hv-1tb-ram
>>>>
>>>> Cc: Anatol Belski 
>>>> Cc: Ard Biesheuvel 
>>>> Cc: Gerd Hoffmann 
>>>> Cc: Jianyong Wu 
>>>> Cc: Jiewen Yao 
>>>> Cc: Laszlo Ersek 
>>>> Cc: Rob Bradford 
>>>>
>>>> Thomas Barrett (3):
>>>>   OvmfPkg: Add CloudHv support to PlatformScanE820 utility function.
>>>>   OvmfPkg: Update PlatformAddressWidthInitialization for CloudHv
>>>>   OvmfPkg: CloudHv: Enable PcdUse1GPageTable
>>>
>>> Series:
>>> Acked-by: Gerd Hoffmann 
>>>
>>
>> Thanks, I've queued this up.
> 
> Merged as #5262
> 

I was late to the party, but that's not a problem; as I said I was going
to be, I am fine with this being approved by other reviewers.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113845): https://edk2.groups.io/g/devel/message/113845
Mute This Topic: https://groups.io/mt/103689730/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Laszlo Ersek]

On 1/15/24 15:04, Ard Biesheuvel wrote:
> On Mon, 15 Jan 2024 at 14:07, Nhi Pham  wrote:
>>
>> On 1/12/2024 4:45 PM, Laszlo Ersek wrote:
>>> (Independently: I think that's a valid thing to do for *SMM* drivers,
>>> because the entry point functions of those drivers are permitted to use
>>> both SMM and DXE/UEFI protocols. But whether the same is valid for the
>>> *standalone* MM drivers -- that looks questionable. Standalone MM
>>> drivers should not depend on UEFI/DXE protocols ever, IIUC.)
>>>
>>>> 3) The issue is patching the grammar in place, why can’t we just make a
>>>> copy for the dispatcher grammer, and operate on the copy. Maybe via a
>>>> copy on 1st update strategy?
>>>
>>> Yes, copying the depex to the heap, and patching it there, was Nhi's #1
>>> fix proposal. I think that could be made work. But I'm not sure if the
>>> perf savings are worth the additional complexity. The heap allocation
>>> (where the writeable depex would exist) would have to be permanently
>>> associated with the loaded PE image -- because the dispatcher might need
>>> to reevaluate the depex across multiple rounds of dispatching. So that's
>>> a new field in some image-related structure, it also needs to be freed
>>> upon unload (?), what if the memory allocation fails during depex eval
>>> (just consider the depex to eval to FALSE?), etc. Doable, but hairy; not
>>> sure if the perf is worth that effort.
>>>
>>
>> Thanks so much, Laszlo for your valuable insights.
>>
>> The approach #1 works for me. I will do further check for your concerns
>> above.
>>
>> I'm trying your suggested patch and investigating the performance being
>> discussed here.
>>
> 
> Not sure what approach #1 means,

(copying the depex to the heap, and maintaining it there, so that it can
be patched)

> but I'd prefer to just remove this
> optimization from standalone MM, given that not only a) it shouldn't
> have to deal with a large number of protocol GUIDs, but also b) the
> driver dispatch is much more straight-forward. (Typically, StMM
> drivers can be dispatched in the order they appear in the firmware
> volume, in which case each DEPEX is evaluated only once anyway)

Sounds like a promising basis for removing the optimization indeed!

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113844): https://edk2.groups.io/g/devel/message/113844
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix issue that IsModified is wrongly set in PageTableMap

[Laszlo Ersek]

On 1/15/24 10:43, Pedro Falcato wrote:
> On Thu, Jan 11, 2024 at 8:56 AM Laszlo Ersek  wrote:
>>
>> On 1/11/24 03:03, Ni, Ray wrote:
>>>> This function is incredibly complicated, so reviewing this patch is
>>>> hard, even after reading the bugzilla ticket.
>>>>
>>>> The commit message is useless. It should contain a brief description of
>>>> the problem, and how the fix resolves the problem.
>>>>
>>>> The documentation of the PageTableLibMapInLevel() function is wrong,
>>>> even before this patch. It documents the "IsModified" output-only
>>>> parameter as follows:
>>>>
>>>> "TRUE means page table is modified. FALSE means page table is not
>>>> modified."
>>>>
>>>> This states that "IsModified" is always set on output, to either FALSE
>>>> or TRUE. Which is an incorrect statement; in reality the caller is
>>>> expected to pre-set (*IsModified) to FALSE, and PageTableLibMapInLevel()
>>>> will (conditionally!) perform a FALSE->TRUE transition only.
>>>>
>>>> Now, this patch may fix a bug, but it makes the above-described
>>>> documentation issue worse, by further restricting the condition for said
>>>> FALSE->TRUE transition.
>>>
>>> Laszlo, thanks for the comments!
>>> Though the fixing looks simple, Zhiguang and I did have several rounds of 
>>> offline discussions
>>> regarding how to fix it.
>>>
>>> When the lib accesses the page table content, CPU would set the "Access" 
>>> bit in the page entry
>>> that points to the page table memory being accessed by the lib.
>>>
>>> So, even when the "Modify" is FALSE (indicating caller doesn't want the lib 
>>> to modify the page table),
>>> lib code should not modify the page table but CPU still sets the "Access" 
>>> bit in some of the entries due to
>>> the reasons above.
>>
>> Huh, tricky!
>>
>> Should the comparison explicitly mask out the Accessed bit from each of
>> the "before" page table entry and the "after" one, perhaps?
> 
> FWIW, clearing the A and D bits off of PTEs requires a TLB flush and,
> as such, that change would break them.

I didn't mean to clear the A/D bits inside the actual live PTEs, only in
those temporary / helper variables (or even just expressions) that we
use for comparing the before/after states.

> 
> In general:
>  - You need a TLB flush when unmapping a page
>  - You need a TLB flush when changing an already-mapped PTE (unless
> you tolerate a stale TLB and want to eat a spurious page fault, which
> is a valid technique)
>  - You don't need a TLB flush when freshly mapping a page (unmapped ->
> mapped) as x86 doesn't cache non-present PTEs
> 
> so you shouldn't need to inspect the PTE before and after;

this seems to invite further discussion wrt. what the function is
supposed to do at all...

> in fact,
> that's erroneous as Intel CPUs can speculatively set the A and D bits
> (they're slightly more careful since CET rolled around, but as far as
> I've heard older Intel used to wildly set those bits speculatively)
> and AMD ones can too (although they cannot speculatively set D).

What is the error behavior here? Assuming we consider a speculative A/D
setting by the hardware, the worst that can happen is that we spuriously
flush the TLB. Is that right? Doesn't seem extremely harmful.

> 
> I'd love to give out more feedback on this patch, but I *really* don't
> understand what any of that function is doing :/
> 

Yup.

(In general I'm just acknowledging that right now this is quite out of
my league...)

Thanks,
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113839): https://edk2.groups.io/g/devel/message/113839
Mute This Topic: https://groups.io/mt/103636407/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix issue that IsModified is wrongly set in PageTableMap

[Laszlo Ersek]

On 1/15/24 03:59, Liu, Zhiguang wrote:
> Hi Laszlo,
> 
> I don't think it is a good idea to explicitly mask out the Accessed/Dirty 
> bit. We can't assume Accessed/Dirty bit are only changed by hardware, because 
> the caller also can change the Accessed/Dirty bit.
> 
> For API PageTableMap, the IsModified is already set as False in the beginning 
> of the function.
> For internal function PageTableLibMapInLevel, we don't set IsModified as 
> False in the beginning on purpose, because it keeps the global state of 
> whether the PageTable is changed.
> 
> I plan to change the comment as below to explicitly explain the behavior:
> 
> For internal function PageTableLibMapInLevel, the description of IsModified 
> should be:
> @param[in, out] IsModified change IsModified to True if page table is 
> modified and input parameter Modify is TRUE.
> 
> For API PageTableMap, the description of IsModified should be: 
> @param[out] IsModified TRUE means page table is modified by software 
> or hardware. FALSE means page table is not modified by software.
> If the output IsModified is FALSE, there is possibility that the page table 
> is changed by hardware. It is ok because page table can be changed by 
> hardware anytime, and we don't need to Flush TLB.
> 
> With these comments changed, I don't need to change C code in my patch.

OK, sounds reasonable to me. Thanks.

> 
> BTW, I assume IsModified can be used as an indicator whether the caller need 
> to flush TLB. Do you prefer to change the parameter name to IsFlushTlbNeeded? 
> I am both fine.

I think the new description of the parameter suffices (without renaming
the parameter).

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113838): https://edk2.groups.io/g/devel/message/113838
Mute This Topic: https://groups.io/mt/103636407/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 0/3] Support CloudHv guests with >1TB of RAM

[Laszlo Ersek]

On 1/12/24 19:31, Thomas Barrett wrote:
> This series adds support for cloud-hypervisor guests with >1TiB
> of RAM to Ovmf. This bug was solved for Qemu back in 2017
> https://bugzilla.redhat.com/show_bug.cgi?id=1468526. The bug is
> still occuring for CloudHv guests because the PlatformScanE820
> utility is not currently supported for CloudHv.
> 
> My working branch for these changes can be found here:
> https://github.com/thomasbarrett/edk2/tree/cloud-hv-1tb-ram
> 
> Cc: Anatol Belski 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jianyong Wu 
> Cc: Jiewen Yao 
> Cc: Laszlo Ersek 
> Cc: Rob Bradford 
> 
> Thomas Barrett (3):
>   OvmfPkg: Add CloudHv support to PlatformScanE820 utility function.
>   OvmfPkg: Update PlatformAddressWidthInitialization for CloudHv
>   OvmfPkg: CloudHv: Enable PcdUse1GPageTable
> 
>  OvmfPkg/CloudHv/CloudHvX64.dsc  |   2 +
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c | 107 ++--
>  2 files changed, 79 insertions(+), 30 deletions(-)
> 

Thanks for posting v3, this one looks well-formed, so I can make some
comments.

TBH, I'm super uncomfortable with a new bunch of CLOUDHV_DEVICE_ID
branches introduced to PlatformInitLib.

OVMF supports multiple hypervisors, and the general idea has been that a
single module (or even a single platform DSC) should preferably not
attempt to support multiple hypervisors. That's why we have a separate
Xen platform, and a big number of Xen-customized, standalone modules.

The idea with this is that any particular developer is very unlikely to
develop for, and test on, multiple hypervisors. Therefore unification (=
elimination of all possible code duplication) between distinct
hypervisor code snippets is actually detrimental for maintenance,
because it technically enables a developer to regress a platform that
they never actively work with.

I believe bhyve is similarly separated out (just like Xen).

It's one thing to collect support for multiple board types (machine
types) for QEMU into a given module; that's still the same hypervisor --
testing only requires a different "-M" option on the qemu command line.

But fusing Cloud Hypervisor code with QEMU code makes me fidget in my seat.

I've now grepped the OvmfPkg directory tree for existent instances of
CLOUDHV_DEVICE_ID, and I'm very much not liking the result list. It has
seeped into a whole bunch of modules that should only be QEMU. If you
need those modules customized for CloudHv, it'd be best to detach them
for CloudHv, and eliminate the dead code (such as anything that depends
on QEMU fw_cfg), and *enforce* that the underlying platform is CloudHv.
Both communities will benefit. Again, this is all based on the empirical
fact that QEMU and CloudHv developers don't tend to cross-develop.

I understand that it's always just a small addition; in each specific
case, it's just one or two more "if"s in common code. But the end result
is terrible to maintain in the long term.

Of course this all depends on having a separate platform DSC for
CloudHv, but that one already exists: "CloudHv/CloudHvX64.dsc".

So I'd suggest (a) isolating current CloudHv logic to new library
instances, drivers, etc, (b) adding this enhancement to CloudHv's own
instance of PlatformInitLib.

Counter-arguments, objections etc welcome -- feel free to prove me wrong
(e.g. whatever I'm saying about prior art / status quo).

Also I'm not necessarily blocking this patch set; if others don't mind
this, they can ACK it (and I won't NACK).

BR
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113835): https://edk2.groups.io/g/devel/message/113835
Mute This Topic: https://groups.io/mt/103689730/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/4] OvmfPkg/VirtNorFlashDxe: fix corruption + misc small improvements

[Laszlo Ersek]

On 1/15/24 11:21, Laszlo Ersek wrote:

> - please only ever apply the bit-neg operator on values that are UINT32,
>   UINTN, or UINT64. Otherwise we get sign bit flipping, and that's
>   terrible. (Most people are not even aware of it happening.)

Doing this is BTW not as obvious as it might seem, at first sight. It's
good to remember some points about integer constants:

- assuming a naked constant (no 0x or 0 prefix, and no suffix such as l,
or u), the types considered are int, long, long long, in this order, by
the compiler, for the value (whichever fits first). That is: a "naked"
integer constant will *always* be signed.

- assuming an octal or hex prefix (0 or 0x), the candidate type list is
only *extended*; in other words, these prefixes don't *force* the type
to be unsigned, only *permit* it. The list becomes int, unsigned, long,
unsigned long, long long, unsigned long long. This is why 0x7F is just
"int", for example. However, 0x8000_ is not "int" anymore, but
"unsigned" (the value doesn't fit in "int", and the 0x prefix "permits"
"unsigned int").

- The suffixes do restrict the candidate type list. The "u" (and U)
suffixes remove the signed types, and add in the unsigned types. The
list becomes unsigned, unsigned long, unsigned long long. Furthermore,
the "l" and "ll" suffixes force (restrict) the type selection along a
different axis: they set the minimum integer "conversion rank", so to
say. The head of the list is trimmed so that the first candidate have
the specified rank. So with just an "l" suffix, the normal candidate
type list "int, long, long long" gets trimmed to "long, long long".
Assuming an "u" suffix in place already, adding the "l" suffix trims the
candidate type list "unsigned, unsigned long, unsigned long long" to
"unsigned long, unsigned long long". Assuming a 0x prefix and no "u"
suffix to begin with, appending the "l" suffix trims the type list "int,
unsigned, long, unsigned long, long long, unsigned long long" to "long,
unsigned long, long long, unsigned long long".

The "shorthand" to remember is: "prefixes permit, suffixes force".

Why I'm posting this wall of text: if we have a macro
BOUNDARY_OF_32_WORDS #defined as 0x7F, or a macro BIT1 #defined as
0x0002, those are *signed int* values. And applying the bit-neg
operator ~ to them directly will flip the sign bit, and the resultant
value will be *implementation-dependent*. Given that we use two's
complement representation, the resultant value will always be signed int
with a negative value. (In a sign-and-magnitude representation e.g.,
where there is +0 and -0, we'd have to think further.) And then, for
example in:

  Offset & ~BOUNDARY_OF_32_WORDS

the negative value of the RHS is converted to the (unsigned) type of the
LHS [*], due to the default arithmetic conversions that are specified
for the & operator (too). This is done with the usual modular addition /
reduction.

So, when most people think that the above expression is simple
bit-fiddling, there are actually *two steps* that they miss: first, the
creation of a negative value of type "signed int" (using two's
complement representation), and then the reduction of that negative
"signed int" value to the (possibly wider) unsigned value range that the
other type is capable of representing [*].

[*] I'm taking some shortcuts here. The actual result type of the usual
arithmetic conversions (the "common real type for the operands
and result") is more complicated, but I won't describe all that here. It
can be read in the C std (drafts).

This is why I insist on one of two things in all such cases:

- either writing the expression as

Offset & ~(UINTN)BOUNDARY_OF_32_WORDS

  where UINTN is supposed to match the type of Offset precisely,

- or #defining BOUNDARY_OF_32_WORDS already as an unsigned type --
either with an explicit cast ((UINTN)0x7F), or with a suitable suffix
(0x7Fllu).

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113820): https://edk2.groups.io/g/devel/message/113820
Mute This Topic: https://groups.io/mt/103680930/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/4] OvmfPkg/VirtNorFlashDxe: fix corruption + misc small improvements

[Laszlo Ersek]

On 1/12/24 12:37, Gerd Hoffmann wrote:
> This is a little series containing the flash corruption fix sent
> yesterday with an slightly improved commit message and some small
> improvements on top of this.
>
> Gerd Hoffmann (4):
>   OvmfPkg/VirtNorFlashDxe: fix shadowbuffer reads
>   OvmfPkg/VirtNorFlashDxe: clarify block write logic
>   OvmfPkg/VirtNorFlashDxe: allow larger writes without block erase
>   OvmfPkg/VirtNorFlashDxe: ValidateFvHeader: unwritten state is EOL too
>
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c| 33 +++
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c |  5 
>  2 files changed, 21 insertions(+), 17 deletions(-)
>

Looking at the original code makes me throw a fit (no offense -- I don't
know who wrote it, and I don't want to check).

There is not a single diagram in the code, when that would be central to
the whole thing.


0   128  256
[|]
^ ^ ^
| | |
| | (Offset & 0x7F) + NumBytes; i.e., the Offset inside
| | (or just past) the *double-word* such that Offset is
| | the *exclusive* end of the (logical) update
| |
| Offset & 0x7F; i.e., Offset within the "word";
| this is where the (logical) update is supposed to start
|
Offset & ~(UINTN)0x7F; i.e., Offset truncated to "word" boundary

In this diagram, NumBytes is already limited to 256; that's because of
the existent condition

   if ((*NumBytes + (Offset & BOUNDARY_OF_32_WORDS)) <= (2 * 
P30_MAX_BUFFER_SIZE_IN_BYTES)) {

So, independently of the bug in the code that this series is supposed to
fix, some problems with the original code:

- no diagram (see above)

- rampant duplication of hard to understand expressions, such as:

  - Offset & ~BOUNDARY_OF_32_WORDS

(side comment: applying the bit-neg on a *signed integer* deserves
its own brown paper bag)

  - *NumBytes + (Offset & BOUNDARY_OF_32_WORDS)

  - Offset & ~BOUNDARY_OF_32_WORDS

- more bit-neg applied to a *signed integer*:

  ~OrigData[CurOffset]

because OrigData[CurOffset] is a UINT8, which gets promoted to
INT32, and that's when the bit-neg is applied

- when the second word write is deemed necessary, then the
  *BlockAddress* variable is bumped by 128 bytes out of laziness for
  said second write -- and that is a *semantic wreck*. The BlockAddress
  does not change *at all*; it's the start offset within the block that
  increases by 128 bytes for the second word write.

- The weird Exit and DoErase labels are fugly. The function should
  either be split into two functions, or at least reorganized with "ifs"
  such that this jumping is not necessary. Gotos are fine, but only for
  error paths / cleanup on exit, not for business logic selection. IOW,
  the main offender is DoErase.


Then comments on the patch set:

- In my opinion, the series should progress in opposite order. First
  introduce a diagram (!), then refactor with the helper variables, and
  then fix the bug. With the refactoring in place *first*, the bugfix
  should be easier to understand. Then, potentially, generalize the code
  to larger-than-two multiples of a word, for writes.

- The first patch in the series is wrong.

  In case we need not erase the whole flash block, we will want to write
  one or two (consecutive) 128-byte "words". That is, 128 bytes, or 256
  bytes. That means we need to read the exact same byte counts as well.

  The *second* patch in the series actually seems to do this, with

End   = (Offset + *NumBytes + BOUNDARY_OF_32_WORDS) & ~BOUNDARY_OF_32_WORDS;

  (This *in itself* would *much better* be written as follows:

End = ALIGN_VALUE (Offset + *NumBytes, P30_MAX_BUFFER_SIZE_IN_BYTES);

  but I digress.)

  However, the first patch still introduces:

(((Offset & BOUNDARY_OF_32_WORDS) + *NumBytes) | BOUNDARY_OF_32_WORDS) + 1

  as the byte count for the read.

  Unfortunately, the "saturation logic" (i.e., OR-ing 0x7F to the
  exclusive end offset, for "seeking" to the end of the word), and then
  adding 1, does not implement a correct "align-up" operation.

  Consider

Offset == 0 && *NumBytes == 256

  This circumstance is *valid* for the optimization path (and it is
  correctly permitted by the top-most check).

  But the expression introduced by patch#1 produces *384* for it, which
  is wrong.

  Similarly, given (for example)

Offset == 1 && *NumBytes == 127

  the formula from patch#1 evaluates to 256.

  The expression does not consider the case when the exclusive end
  offset of the requested (logical write) is immediately at a word
  boundary (i.e., a multiple of 128). In that case namely, saturating
  with the bit-or, and adding 1, is wrong -- because in that case, no
  additional block should be read at all.

  So the first patch in the series replaces the *pre-series* bug with a
  different (less harmful) bug, 

Re: [edk2-devel] RFC: Folder layout change in UefiCpuPkg

[Laszlo Ersek]

On 1/12/24 11:19, Sunil V L wrote:
> Hi Ray,
> 
> On Fri, Jan 12, 2024 at 09:12:34AM +, Ni, Ray wrote:
>> Sunil,
>> I would like to hear your feedback regarding locations of following RiscV64 
>> components in UefiCpuPkg:
>> * UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/
>> * UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/
>> * UefiCpuPkg/CpuDxeRiscV64/
>> * UefiCpuPkg/CpuTimerDxeRiscV64/
>>
>> I would like to move them to the following new locations accordingly:
>> * UefiCpuPkg/Library/CpuExceptionHandlerLib/RiscV64/
>> * UefiCpuPkg/Library/CpuTimerLib/RiscV64/
>> * UefiCpuPkg/CpuDxe/RiscV64/
>> * UefiCpuPkg/CpuTimerDxe/RiscV64/
>>
>>
>> I want to avoid too many similar drivers in root folder, and too many 
>> libraries in Library folder.
>>
>> Movement of the first 3 ones put the RiscV components under existing folders.
>> Movement of the last one creates the UefiCpuPkg/CpuTimerDxe folder, that 
>> could be potentially shared by other archs as well.
>>
>> I raised similar comments to Chao Li who is working on LoongArch upstream.
>>
>> The location movement follows the 2nd pattern defined by edk2 coding 
>> standard:
>> Driver's location could be:
>> [[]]
>>   or
>> [/[/]]
>>
>> Library's location could be:
>>
>> [[]][]
>>
>>   or
>>
>> []/[[/]]
>>
>>
> Your proposal looks good to me except better to keep directory name as
> RiscV as in other packages.

no objections from me



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113810): https://edk2.groups.io/g/devel/message/113810
Mute This Topic: https://groups.io/mt/103679850/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v7 25/37] ArmVirtPkg: Move PlatformBootManagerLib to OvmfPkg

[Laszlo Ersek]

On 1/12/24 09:25, Chao Li wrote:
> Moved the PlatformBootManagerLib to OvmfPkg and renamed to
> PlatformBootManagerLibLight for easy use by other ARCH.
> 
> Build-tested only (with "ArmVirtQemu.dsc").
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
> 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Lazlo Ersek 
> Signed-off-by: Chao Li 
> ---
>  ArmVirtPkg/ArmVirtPkg.ci.yaml  | 1 -
>  ArmVirtPkg/ArmVirtPkg.dec  | 1 -
>  ArmVirtPkg/ArmVirtQemu.dsc | 2 +-
>  ArmVirtPkg/ArmVirtQemuKernel.dsc   | 2 +-
>  .../Library/PlatformBootManagerLibLight}/PlatformBm.c  | 0
>  .../Library/PlatformBootManagerLibLight}/PlatformBm.h  | 0
>  .../PlatformBootManagerLibLight}/PlatformBootManagerLib.inf| 3 +--
>  .../Library/PlatformBootManagerLibLight}/QemuKernel.c  | 0
>  8 files changed, 3 insertions(+), 6 deletions(-)
>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
> OvmfPkg/Library/PlatformBootManagerLibLight}/PlatformBm.c (100%)
>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
> OvmfPkg/Library/PlatformBootManagerLibLight}/PlatformBm.h (100%)
>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
> OvmfPkg/Library/PlatformBootManagerLibLight}/PlatformBootManagerLib.inf (92%)
>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
> OvmfPkg/Library/PlatformBootManagerLibLight}/QemuKernel.c (100%)
> 
> diff --git a/ArmVirtPkg/ArmVirtPkg.ci.yaml b/ArmVirtPkg/ArmVirtPkg.ci.yaml
> index 506b0e72f0..b186d4eb42 100644
> --- a/ArmVirtPkg/ArmVirtPkg.ci.yaml
> +++ b/ArmVirtPkg/ArmVirtPkg.ci.yaml
> @@ -24,7 +24,6 @@
>  ],
>  ## Both file path and directory path are accepted.
>  "IgnoreFiles": [
> -"Library/PlatformBootManagerLib/PlatformBm.c"
>  ]
>  },
>  ## options defined .pytool/Plugin/CompilerPlugin

OK

> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
> index 315db4e8ea..6aa5ea05f4 100644
> --- a/ArmVirtPkg/ArmVirtPkg.dec
> +++ b/ArmVirtPkg/ArmVirtPkg.dec
> @@ -27,7 +27,6 @@
>  
>  [LibraryClasses]
>ArmVirtMemInfoLib|Include/Library/ArmVirtMemInfoLib.h
> -  FdtSerialPortAddressLib|Include/Library/FdtSerialPortAddressLib.h
>  
>  [Guids.common]
>gArmVirtTokenSpaceGuid = { 0x0B6F5CA7, 0x4F53, 0x445A, { 0xB7, 0x6E, 0x2E, 
> 0x36, 0x5B, 0x80, 0x63, 0x66 } }

This hunk belongs to patch "ArmVirtPkg: Move the FdtSerialPortAddressLib
to OvmfPkg".

> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 147180f645..e48c75b5e9 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -70,7 +70,7 @@
>  
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> -  
> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +  
> PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLibLight/PlatformBootManagerLib.inf
>
> PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf

OK

> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index c22a422353..668a65ba64 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -69,7 +69,7 @@
>  
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> -  
> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +  
> PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLibLight/PlatformBootManagerLib.inf
>
> PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf

OK

> diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
> b/OvmfPkg/Library/PlatformBootManagerLibLight/PlatformBm.c
> similarity index 100%
> rename from ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
> rename to OvmfPkg/Library/PlatformBootManagerLibLight/PlatformBm.c

OK

> diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.h 
> b/OvmfPkg/Library/PlatformBootManagerLibLight/PlatformBm.h
> similarity index 100%
> rename from ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.h
> rename to OvmfPkg/Library/PlatformBootManagerLibLight/PlatformBm.h

OK

> diff --git 
> a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> 

Re: [edk2-devel] [PATCH v7 00/37] Enable LoongArch virtual machine in edk2

[Laszlo Ersek]

On 1/12/24 09:21, Chao Li wrote:

> **Changes from V6 to V7:**
> [...]
> For the review opinions:
> 1. Moved the changes to OvmfPkg.dec from old patch 24 to new patch 23.
> Questioner: Laszlo.

IIUC, you may have inteded to do this, but didn't actually do it.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113808): https://edk2.groups.io/g/devel/message/113808
Mute This Topic: https://groups.io/mt/103679423/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v7 23/37] ArmVirtPkg: Move the FdtSerialPortAddressLib to OvmfPkg

[Laszlo Ersek]

On 1/12/24 09:25, Chao Li wrote:
> Move the FdtSerialPortAddressLib to Ovmfpkg so that other ARCH can
> easily use it.
> 
> Build-tested only (with "ArmVirtQemu.dsc").
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
> 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Laszlo Ersek 
> Signed-off-by: Chao Li 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc| 2 +-
>  .../Include/Library/FdtSerialPortAddressLib.h | 0
>  .../Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.c | 0
>  .../FdtSerialPortAddressLib/FdtSerialPortAddressLib.inf   | 2 +-
>  OvmfPkg/OvmfPkg.dec   | 4 
>  5 files changed, 6 insertions(+), 2 deletions(-)
>  rename {ArmVirtPkg => OvmfPkg}/Include/Library/FdtSerialPortAddressLib.h 
> (100%)
>  rename {ArmVirtPkg => 
> OvmfPkg}/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.c (100%)
>  rename {ArmVirtPkg => 
> OvmfPkg}/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.inf (90%)
> 
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index 9b23ef97ec..2bc6a29eb1 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -122,7 +122,7 @@
># ARM PL011 UART Driver
>PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>
> SerialPortLib|ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.inf
> -  
> FdtSerialPortAddressLib|ArmVirtPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.inf
> +  
> FdtSerialPortAddressLib|OvmfPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.inf
>  
>
> PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
>
> #PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
> diff --git a/ArmVirtPkg/Include/Library/FdtSerialPortAddressLib.h 
> b/OvmfPkg/Include/Library/FdtSerialPortAddressLib.h
> similarity index 100%
> rename from ArmVirtPkg/Include/Library/FdtSerialPortAddressLib.h
> rename to OvmfPkg/Include/Library/FdtSerialPortAddressLib.h
> diff --git 
> a/ArmVirtPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.c 
> b/OvmfPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.c
> similarity index 100%
> rename from 
> ArmVirtPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.c
> rename to OvmfPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.c
> diff --git 
> a/ArmVirtPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.inf 
> b/OvmfPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.inf
> similarity index 90%
> rename from 
> ArmVirtPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.inf
> rename to OvmfPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.inf
> index ae6d0d374b..e27742e9fa 100644
> --- a/ArmVirtPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.inf
> +++ b/OvmfPkg/Library/FdtSerialPortAddressLib/FdtSerialPortAddressLib.inf
> @@ -18,9 +18,9 @@
>FdtSerialPortAddressLib.c
>  
>  [Packages]
> -  ArmVirtPkg/ArmVirtPkg.dec
>EmbeddedPkg/EmbeddedPkg.dec
>MdePkg/MdePkg.dec
> +  OvmfPkg/OvmfPkg.dec
>  
>  [LibraryClasses]
>BaseLib
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 7bc2bf1674..13e69e6648 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -29,6 +29,10 @@
>##  @libraryclass  Verify blobs read from the VMM
>BlobVerifierLib|Include/Library/BlobVerifierLib.h
>  
> +  ##  @libraryclass  FdtSerialPortAddressLib
> +  #
> +  FdtSerialPortAddressLib|Include/Library/FdtSerialPortAddressLib.h
> +
>##  @libraryclass  Loads and boots a Linux kernel image
>#
>LoadLinuxLib|Include/Library/LoadLinuxLib.h

IIUC, the library class is not removed from "ArmVirtPkg.dec"; please do
that as well, in the same patch.

Otherwise, the patch looks OK to me.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113807): https://edk2.groups.io/g/devel/message/113807
Mute This Topic: https://groups.io/mt/103679474/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/VirtNorFlashDxe: fix shadowbuffer reads

[Laszlo Ersek]

On 1/11/24 14:36, Gerd Hoffmann wrote:
> In some cases (specifically when the flash update region is
> small but crosses a multiple of P30_MAX_BUFFER_SIZE_IN_BYTES)
> NorFlashWriteSingleBlock reads only one instead of two
> P30_MAX_BUFFER_SIZE_IN_BYTES blocks into the shadow buffer.
> 
> That leads to random crap being written to the second block,
> which in turn can corrupt both the variable store and the
> FTW work space.
> 
> This patch fixes the calculation.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> index 1afd60ce66eb..cdc809d75e3d 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
> @@ -566,7 +566,7 @@ NorFlashWriteSingleBlock (
> Instance,
> Lba,
> Offset & ~BOUNDARY_OF_32_WORDS,
> -   (*NumBytes | BOUNDARY_OF_32_WORDS) + 1,
> +   (((Offset & BOUNDARY_OF_32_WORDS) + *NumBytes) | 
> BOUNDARY_OF_32_WORDS) + 1,
> Instance->ShadowBuffer
> );
>  if (EFI_ERROR (Status)) {

This patch looks like the output of an excellent bug analysis. I'll need
more time to review this. If you have a ticket with the analysis
captured (actual numbers, debugging logs, a concrete backtrace / call
chain triggering the issue, etc), I'd appreciate a reference. (Perhaps
include some of the key items in the commit message too?)

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113705): https://edk2.groups.io/g/devel/message/113705
Mute This Topic: https://groups.io/mt/103661868/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Laszlo Ersek]

On 1/12/24 03:44, Andrew (EFI) Fish wrote:
> Sorry need some more time to digest this…. First thoughts.
> 
> 1) The actual performance issue we hit was the explosion
> of CoreValidateHandle() calls as the number of protocols got large for
> some diags. The newer handles tended to be at the end of the list if I
> remember correctly. 
>   a) It looks like CoreValidateHandle() is the only
> place  *gHandleList* was walked, as the handle info is crossed
> referenced in the protocol database. So that is why we changed that.
> 2) If the issue at hand is MM why not just drop the optimizations?

Yes, that's the first (and easy) idea. But I guess it needs some
measurements (no perf regression). It would be nice to know whether
Intel (?) measured any serious perf gains when they originally
implemented (in the 2000s?) the optimization.

>   b) If we have so many MM protocols and handles that seems like its own
> problem? 

I would agree; however, IIRC, the depex evaluator for the MM drivers
also searches the UEFI (DXE) protocol database, not just the MM protocol
database.

(Independently: I think that's a valid thing to do for *SMM* drivers,
because the entry point functions of those drivers are permitted to use
both SMM and DXE/UEFI protocols. But whether the same is valid for the
*standalone* MM drivers -- that looks questionable. Standalone MM
drivers should not depend on UEFI/DXE protocols ever, IIUC.)

> 3) The issue is patching the grammar in place, why can’t we just make a
> copy for the dispatcher grammer, and operate on the copy. Maybe via a
> copy on 1st update strategy? 

Yes, copying the depex to the heap, and patching it there, was Nhi's #1
fix proposal. I think that could be made work. But I'm not sure if the
perf savings are worth the additional complexity. The heap allocation
(where the writeable depex would exist) would have to be permanently
associated with the loaded PE image -- because the dispatcher might need
to reevaluate the depex across multiple rounds of dispatching. So that's
a new field in some image-related structure, it also needs to be freed
upon unload (?), what if the memory allocation fails during depex eval
(just consider the depex to eval to FALSE?), etc. Doable, but hairy; not
sure if the perf is worth that effort.

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113704): https://edk2.groups.io/g/devel/message/113704
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Laszlo Ersek]

On 1/12/24 03:10, Pedro Falcato wrote:
> On Thu, Jan 11, 2024 at 8:46 AM Laszlo Ersek  wrote:
>>
>> On 1/10/24 22:50, Pedro Falcato wrote:

>>> FWIW, can we do better than an RB tree? They're notoriously cache
>>> unfriendly...
>>
>> Sure, if someone contributes a different data structure that is suitable
>> for the task :)
> 
> Hey, I happen to have written one!
> https://github.com/heatd/Onyx/blob/master/kernel/kernel/radix.cpp
> It just needs some C'ifying, then some EFI'ing on top, but I'm fairly
> confident in its stability.

Yes, this is absolutely viable and welcome. You seem to hold the
copyright on it, too, so you could even relicense (although MIT should
just be fine for edk2).

(I had done the same with the rbtree code -- I had written that code
much earlier,  not for edk2. I re-verified it and ported it to edk2, and
relicensed it.)

>> When I contributed the code, edk2 didn't have any associative array
>> type, so something generic that would address the widest range of use
>> cases looked like a good idea. (And indeed the library has been well
>> applied in several of those use cases since, in various parts of edk2 --
>> for sorting, uniqueness-checking, async interface token tracking &
>> lookups.)
> 
> Definitely, I use it in Ext4Dxe too, it's great!

Heh, I didn't know that. Thanks!

> (Although I do have a
> small nit in that it allocates nodes itself, and there's no way around
> it, but oh well...)

Right, that's the usual intrusive vs. non-intrusive containers debate :)

I didn't mind more allocations (and hence perhaps more fragmentation),
but I wanted to (a) hide the node internals, (b) the possibility to link
any given piece of user structure into multiple trees (and other
containers) without having to modify the user structure itself (i.e.
without embedding further node / link structs into the user struct).

I figure each of intrusive and non-intrusive has its advantages over the
other; I just went with my preferences.

> My idea was to make each handle an index - like a file descriptor -
> AFAIK there's no reason why it *needs* to be an actual pointer.
> We'd allocate indices when creating a handle, and return that (casted to 
> VOID*).

Huh, sneaky.

I see two potential problems with this.

First, per C std, these "pointers" would be invalid (they wouldn't
actually point to valid memory), so even just evaluating them (not
dereferencing them!) would invoke undefined behavior. May or may not
matter in practice. With compilers getting smarter about optimization
(and stricter about std conformance), there could be issues, perhaps.

The other concern is a bit contrived, but I *guess* there could be code
out there that actually dereferences EFI_HANDLEs. That code would crash.
May or may not matter, because such code is arguably already
semantically invalid. (It would not necessarily be invalid at the
language level -- cf. my previous paragraph --, because passing an
otherwise valid EFI_HANDLE to CopyMem, for copying just 1 byte out of
the underlying opaque data structure, would not violate the language.)

> I should note that I find it super hard to get a concrete idea on
> performance for EFI firmware without adequate tooling - I meant to
> write a standalone flamegraph tool a few weeks back (even posted in
> edk2-devel), but, as far as I could tell, the architectural timer
> protocol couldn't get me the interrupt frame[1]. Until then, whether
> any of this radix tree vs RB tree vs flat array stuff really
> matters... I find it hard to say.
> 
> [1] x86 has 3 timers (PIT, LAPIC timer, HPET) and performance
> monitoring interrupts, and I couldn't freely use any of them :^)

Edk2 has some form of profiling already (see
"MdePkg/Include/Library/PerformanceLib.h"). Usually one sees core code
peppered with PERF_CODE_BEGIN and PERF_CODE_END macros. I *think* there
is something like a "display performance" (dp) shell application too,
that can show the collected stats. But I've never used these facilities.

The wiki seems to have two related articles:

https://github.com/tianocore/tianocore.github.io/wiki/Edk2-Performance-Infrastructure

https://github.com/tianocore/tianocore.github.io/wiki/PerformancePkg

The former looks quite comprehensive, at a quick skim.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113703): https://edk2.groups.io/g/devel/message/113703
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Laszlo Ersek]

On 1/11/24 09:46, Laszlo Ersek wrote:
> On 1/10/24 22:50, Pedro Falcato wrote:

>> For the protocol database, you'd replace the linked list with a simple
>> hashtable, hashed by protocol. Something as simple as LIST_ENTRY
>> mProtocolHashtable[64]; would probably be enough to fan out most of
>> the problems (I think? How many different protocols are there?)
> 
> I can answer this question reasonably well, I think. I have a script
> that collects symbolic names of GUIDs from the edk2 tree (plus hardcodes
> a number of well-known but not edk2 GUIDs), and creates a "sed" script
> out of them. Then another script uses this "sed" script for filtering
> edk2 logs -- the idea being to replace the whole bunch of logged GUIDs
> with their symbolic names. That makes logs much easier to read.
> 
> The generator script is written such a way that the generated "sed"
> script only grows over time; put differently, this "dictionary" of
> name<->GUID associations never forgets, it only picks up new GUIDs. The
> "sed" script (= the dictionary file) consists of entries like
> 
> s:FFB19961-79CC-4684-84A8-C31B0A2BBE82:[EarlyFdt16550SerialPortHookLib]:ig
> s:FFB56F09-65E3-4462-A799-2F0D1930D38C:[DxeContextBufferModuleConfigLib]:ig
> s:FFE06BDD-6107-46A6-7BB2-5A9C7EC5275C:[EfiAcpiTableProtocol]:ig
> s:FFF12B8D-7696-4C8B-A985-2747075B4F50:[EfiSystemNvDataFv]:ig
> 
> it's sorted uniquely by GUID.
> 
> Right now, it has 3074 entries. (People like generating GUIDs! :) In
> PI/UEFI/edk2, *everything* is a GUID, not just protocols!)

If I grep the dictionary for "Protocol", I get 515 hits.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113615): https://edk2.groups.io/g/devel/message/113615
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: change name of gMpInformationHobGuid2

[Laszlo Ersek]

On 1/11/24 10:00, Dun Tan wrote:
> Change name of gMpInformationHobGuid2 to
> gMpInformation2HobGuid. It's to align with
> the file name MpInformation2.h and the
> structure name MP_INFORMATION2_HOB_DATA.
> 
> Signed-off-by: Dun Tan 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> ---
>  UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 8 
>  UefiCpuPkg/CpuMpPei/CpuMpPei.inf | 2 +-
>  UefiCpuPkg/Include/Guid/MpInformation2.h | 2 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 6 +++---
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 2 +-
>  UefiCpuPkg/UefiCpuPkg.dec| 2 +-
>  6 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> index 93919be94f..2ce4d6ab50 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> @@ -566,7 +566,7 @@ GetProcessorCoreType (
>  }
>  
>  /**
> -  Create gMpInformationHobGuid2.
> +  Create gMpInformation2HobGuid.
>  **/
>  VOID
>  BuildMpInformationHob (
> @@ -618,13 +618,13 @@ BuildMpInformationHob (
>//
>// Create MP_INFORMATION2_HOB. when the max HobLength 0xFFF8 is not 
> enough, there
>// will be a MP_INFORMATION2_HOB series in the HOB list.
> -  // In the HOB list, there is a gMpInformationHobGuid2 with 0 value 
> NumberOfProcessors
> +  // In the HOB list, there is a gMpInformation2HobGuid with 0 value 
> NumberOfProcessors
>// fields to indicate it's the last MP_INFORMATION2_HOB.
>//
>while (NumberOfProcessorsInHob != 0) {
>  NumberOfProcessorsInHob = MIN (NumberOfProcessors - ProcessorIndex, 
> MaxProcessorsPerHob);
>  MpInformation2HobData   = BuildGuidHob (
> -,
> +,
>  sizeof (MP_INFORMATION2_HOB_DATA) + sizeof 
> (MP_INFORMATION2_ENTRY) * NumberOfProcessorsInHob
>  );
>  ASSERT (MpInformation2HobData != NULL);
> @@ -744,7 +744,7 @@ InitializeCpuMpWorker (
>ASSERT_EFI_ERROR (Status);
>  
>//
> -  // Create gMpInformationHobGuid2
> +  // Create gMpInformation2HobGuid
>//
>BuildMpInformationHob ();
>  
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.inf 
> b/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
> index 812fa179bd..9ab2623bd0 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
> @@ -50,7 +50,7 @@
>  
>  [Guids]
>gEdkiiMigratedFvInfoGuid ## 
> SOMETIMES_CONSUMES ## HOB
> -  gMpInformationHobGuid2## PRODUCES
> +  gMpInformation2HobGuid## PRODUCES
>  
>  [Ppis]
>gEfiPeiMpServicesPpiGuid  ## PRODUCES
> diff --git a/UefiCpuPkg/Include/Guid/MpInformation2.h 
> b/UefiCpuPkg/Include/Guid/MpInformation2.h
> index 43185a4b01..2d9266f061 100644
> --- a/UefiCpuPkg/Include/Guid/MpInformation2.h
> +++ b/UefiCpuPkg/Include/Guid/MpInformation2.h
> @@ -53,6 +53,6 @@ typedef struct {
>  #define GET_MP_INFORMATION_ENTRY(MpInfoHobData, Index) \
>  (MP_INFORMATION2_ENTRY *)((UINTN)&((MP_INFORMATION2_HOB_DATA 
> *)(MpInfoHobData))->Entry + (MpInfoHobData)->EntrySize * Index)
>  
> -extern EFI_GUID  gMpInformationHobGuid2;
> +extern EFI_GUID  gMpInformation2HobGuid;
>  
>  #endif
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> index 9b230772cb..cd394826ff 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> @@ -776,7 +776,7 @@ GetMpInformation (
>HobIndex  = 0;
>HobCount  = 0;
>  
> -  FirstMpInfo2Hob = GetFirstGuidHob ();
> +  FirstMpInfo2Hob = GetFirstGuidHob ();
>ASSERT (FirstMpInfo2Hob != NULL);
>GuidHob = FirstMpInfo2Hob;
>while (GuidHob != NULL) {
> @@ -792,7 +792,7 @@ GetMpInformation (
>  
>  HobCount++;
>  *NumberOfCpus += MpInformation2HobData->NumberOfProcessors;
> -GuidHob= GetNextGuidHob (, GET_NEXT_HOB 
> (GuidHob));
> +GuidHob= GetNextGuidHob (, GET_NEXT_HOB 
> (GuidHob));
>}
>  
>ASSERT (*NumberOfCpus <= PcdGet32 (PcdCpuMaxLogicalProcessorNumber));
> @@ -820,7 +820,7 @@ GetMpInformation (
>GuidHob = FirstMpInfo2Hob;
>while (HobIndex < HobCount) {
>  MpInfo2Hobs[HobIndex++] = GET_GUID_HOB_DATA (GuidHob);
> -GuidHob = GetNextGuidHob (, 
> GET_NEXT_HOB (GuidHob));
> +GuidHob = GetNextGuidHob (, 
> GET_NEXT_HOB (GuidHob));
>}

Re: [edk2-devel] [PATCH 1/2] CloudHv: Add CloudHv support to PlatformScanE820 utility function.

[Laszlo Ersek]

Hello Thomas,

(+ Jianyong, Anatol, Gerd)

On 1/10/24 23:21, Thomas Barrett wrote:
> Signed-off-by: Thomas Barrett 
> ---
> OvmfPkg/Library/PlatformInitLib/MemDetect.c | 95 ++---
> 1 file changed, 65 insertions(+), 30 deletions(-)

please don't paste patches in email bodies; they are hard to read
(review) and effectively impossible to apply that way.

Here's the official dev guide:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

A few more personal ideas:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers

Please don't forget to run the GetMaintainer.py script either, for
composing the Cc: tags in the commit message body.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113611): https://edk2.groups.io/g/devel/message/113611
Mute This Topic: https://groups.io/mt/103657892/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix issue that IsModified is wrongly set in PageTableMap

[Laszlo Ersek]

On 1/11/24 03:03, Ni, Ray wrote:
>> This function is incredibly complicated, so reviewing this patch is
>> hard, even after reading the bugzilla ticket.
>>
>> The commit message is useless. It should contain a brief description of
>> the problem, and how the fix resolves the problem.
>>
>> The documentation of the PageTableLibMapInLevel() function is wrong,
>> even before this patch. It documents the "IsModified" output-only
>> parameter as follows:
>>
>> "TRUE means page table is modified. FALSE means page table is not
>> modified."
>>
>> This states that "IsModified" is always set on output, to either FALSE
>> or TRUE. Which is an incorrect statement; in reality the caller is
>> expected to pre-set (*IsModified) to FALSE, and PageTableLibMapInLevel()
>> will (conditionally!) perform a FALSE->TRUE transition only.
>>
>> Now, this patch may fix a bug, but it makes the above-described
>> documentation issue worse, by further restricting the condition for said
>> FALSE->TRUE transition.
> 
> Laszlo, thanks for the comments!
> Though the fixing looks simple, Zhiguang and I did have several rounds of 
> offline discussions
> regarding how to fix it.
> 
> When the lib accesses the page table content, CPU would set the "Access" bit 
> in the page entry
> that points to the page table memory being accessed by the lib.
> 
> So, even when the "Modify" is FALSE (indicating caller doesn't want the lib 
> to modify the page table),
> lib code should not modify the page table but CPU still sets the "Access" bit 
> in some of the entries due to
> the reasons above.

Huh, tricky!

Should the comparison explicitly mask out the Accessed bit from each of
the "before" page table entry and the "after" one, perhaps?

> I agree it will be better that the commit message carries above details.
> 
> Zhiguang,
> Can we update the code to always assign "IsModified"? I thought we did that 
> but it seems not.

That seems doable by (e.g.) setting (*IsModified) to FALSE right at the
top of the function, and then the logic would match the existent
comments, I think. However, I've not checked whether callers actually
rely on this "summing" logic of the IsModified output parameter -- like
call the function a number of times in a row, using a common local
variable to receive IsModified, and then check the local variable to see
if *any one* of the calls in the loop has modified the page table.

Thanks
Laszlo

> 
>>
>> The fix per se looks vaguely reasonable to me (really the function is so
>> complicated that verifying this change from scratch would take me ages),
>> but minimally, the documentation of "IsModified" should certainly be
>> updated too. To something like this:
>>
>>   @param[out] IsModified  If "Modify" is TRUE on input and the function
>>   has actually modified the page table, then
>> set
>>   to TRUE on output. Not overwritten
>> otherwise.
>>
>> Laszlo
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113598): https://edk2.groups.io/g/devel/message/113598
Mute This Topic: https://groups.io/mt/103636407/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg/CpuMpPei: Don't write CR3 in ConvertMemoryPageToNotPresent

[Laszlo Ersek]

On 1/11/24 03:08, Ni, Ray wrote:
> 
> 
> Thanks,
> Ray
>> -Original Message-----
>> From: Laszlo Ersek 
>> Sent: Wednesday, January 10, 2024 7:57 PM
>> To: Liu, Zhiguang ; devel@edk2.groups.io
>> Cc: Ni, Ray ; Kumar, Rahul R ;
>> Gerd Hoffmann 
>> Subject: Re: [PATCH] UefiCpuPkg/CpuMpPei: Don't write CR3 in
>> ConvertMemoryPageToNotPresent
>>
>> On 1/10/24 06:43, Zhiguang Liu wrote:
>>> After ConvertMemoryPageToNotPresent, there is always a flush TLB
>>> function. So, to improve performance, there is no need to write CR3
>>> inside ConvertMemoryPageToNotPresent
>>>
>>> Cc: Ray Ni 
>>> Cc: Laszlo Ersek 
>>> Cc: Rahul Kumar 
>>> Cc: Gerd Hoffmann 
>>> Signed-off-by: Zhiguang Liu 
>>> ---
>>>  UefiCpuPkg/CpuMpPei/CpuPaging.c | 1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/UefiCpuPkg/CpuMpPei/CpuPaging.c
>> b/UefiCpuPkg/CpuMpPei/CpuPaging.c
>>> index 15c7015fb8..c6894458f7 100644
>>> --- a/UefiCpuPkg/CpuMpPei/CpuPaging.c
>>> +++ b/UefiCpuPkg/CpuMpPei/CpuPaging.c
>>> @@ -167,7 +167,6 @@ ConvertMemoryPageToNotPresent (
>>>}
>>>
>>>ASSERT_EFI_ERROR (Status);
>>> -  AsmWriteCr3 (PageTable);
>>>return Status;
>>>  }
>>>
>>
>> (1) I mostly understand the point that the commit message makes, but the
>> message is not clear enough. The real point is that we have two
>> ConvertMemoryPageToNotPresent() calls altogether, and each of those
>> takes place in a *loop*, and each of those loops is followed by a
>> CpuFlushTlb() call.
>>
>> The loops matter. If there were no loops, then we might be motivated to
>> choose a different solution (for example, to move centralize the
>> CpuFlushTlb() calls *inside* ConvertMemoryPageToNotPresent(), or
>> something similar).
>>
>> So, please update the commit message; mention the loops.
>>
>> (2) I can't easily see why this change is actually correct. IIRC,
>> writing CR3 has a "side effect" of flushing the TLB. But obviously,
>> that's not the *only* effect of writing CR3. You could say that
>> CpuFlushTlb() performs a *strict subset* of what AsmWriteCr3() performs.
>> Therefore, in order to replace AsmWriteCr3() with just CpuFlushTlb(),
>> you need to demonstrate that the functionality that now is *not* going
>> to be done has always been superfluous. In more direct terms, you need
>> to show that the AsmWriteCr3() write call that's being removed here
>> never actuall changes the *value* of CR3.
>>
>> And I cannot show that myself very easily.
>> ConvertMemoryPageToNotPresent(). In ConvertMemoryPageToNotPresent(),
>> "PageTable" is first set from AsmReadCr3(), then passed twice to
>> PageTableMap() by reference (!), and then it is written back to CR3. If
>> at least one of those PageTableMap() calls change "PageTable", then the
>> AsmWriteCr3() call at the end that's now being removed actually changes
>> the value of CR3, and then the patch would be wrong.
>>
>> It's possible that PageTableMap() never changes the value of
>> "PageTable", but it must be proved, and the evidence should be included
>> in the commit message.
>>
>> (3) Furthermore, with the patch applied, ConvertMemoryPageToNotPresent()
>> will no longer flush the TLB itself -- that will always be left to the
>> caller. This new caller responsibility should be documented in the
>> leading comment of ConvertMemoryPageToNotPresent(). We already have a
>> paragraph there starting with "Caller should make sure..."
>>
>> Sorry for making such a big deal out of this, but such simple-looking
>> changes can sometimes case obscure (and rarely occurring) bugs down the
>> road. If you already have evidence that CR3 does not change here, that's
>> great, but then please don't think it's "obvious"; just go ahead and
>> document it.
> 
> Laszlo,
> Happy to see these comments! All make sense!
> 
> PageTableMap() only modifies the PageTable root pointer when creating from 
> zero.
> Since there is only one instance of the PageTableLib, I think we could update 
> the
> PageTableLib API comments to explicitly mention that. So point (2) will be 
> resolved.

That should work, thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113597): https://edk2.groups.io/g/devel/message/113597
Mute This Topic: https://groups.io/mt/103636435/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V2] UefiCpuPkg:Limit PhysicalAddressBits in speicial case

[Laszlo Ersek]

On 1/11/24 03:11, Dun Tan wrote:
> When creating smm page table, limit maximum
> supported physical address bits returned by
> CalculateMaximumSupportAddress() to 47 if
> 5-Level Paging is disabled.
> When 5-Level Paging is disabled and the
> PhysicalAddressBits retrived from CPU HOB or
> CpuId is bigger than 47, and since virtual
> addresses are sign-extended, only [0, 2^47-1]
> range in 52-bit physical address is mapped
> in page table.
> 
> Signed-off-by: Dun Tan 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)

I'll let Gerd review this (thanks!), I just want to point out a typo in
the subject: "speicial" should be "special".

Thanks
Laszlo

> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index ddd9be66b5..35c282a771 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -137,11 +137,13 @@ GetSubEntriesNum (
>  /**
>Calculate the maximum support address.
>  
> +  @param[in] Is5LevelPagingNeededIf 5-level paging enabling is needed.
> +
>@return the maximum support address.
>  **/
>  UINT8
>  CalculateMaximumSupportAddress (
> -  VOID
> +  BOOLEAN  Is5LevelPagingNeeded
>)
>  {
>UINT32  RegEax;
> @@ -164,6 +166,15 @@ CalculateMaximumSupportAddress (
>  }
>}
>  
> +  //
> +  // Only [0, 2^47 -1] in 52-bit physical addresses is mapped in page table
> +  // when 5-Level Paging is disabled.
> +  //
> +  ASSERT (PhysicalAddressBits <= 52);
> +  if (!Is5LevelPagingNeeded && (PhysicalAddressBits > 47)) {
> +PhysicalAddressBits = 47;
> +  }
> +
>return PhysicalAddressBits;
>  }
>  
> @@ -197,7 +208,7 @@ SmmInitPageTable (
>mCpuSmmRestrictedMemoryAccess = PcdGetBool 
> (PcdCpuSmmRestrictedMemoryAccess);
>m1GPageTableSupport   = Is1GPageSupport ();
>m5LevelPagingNeeded   = Is5LevelPagingNeeded ();
> -  mPhysicalAddressBits  = CalculateMaximumSupportAddress ();
> +  mPhysicalAddressBits  = CalculateMaximumSupportAddress 
> (m5LevelPagingNeeded);
>PatchInstructionX86 (gPatch5LevelPagingNeeded, m5LevelPagingNeeded, 1);
>if (m5LevelPagingNeeded) {
>  mPagingMode = m1GPageTableSupport ? Paging5Level1GB : Paging5Level;



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113596): https://edk2.groups.io/g/devel/message/113596
Mute This Topic: https://groups.io/mt/103655312/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Laszlo Ersek]

On 1/10/24 22:50, Pedro Falcato wrote:
> On Wed, Jan 10, 2024 at 1:45 PM Laszlo Ersek 
> wrote:
>>
>> (+ Andrew)
>>
>> On 1/10/24 14:09, Laszlo Ersek wrote:
>>
>>> I think that keeping the depex section read-only is valuable, so I'd
>>> rule out #2. I'd also not start with option #1 -- copying the depex
>>> to heap memory, just so this optimization can succeed. I'd simply
>>> start by removing the optimization, and measuring how much driver
>>> dispatch slows down in practice, on various platforms.
>>>
>>> Can you try this? (I have only build-tested and "uncrustified" it.)
>>>
>>> The patch removes the EFI_DEP_REPLACE_TRUE handling altogether, plus
>>> it CONST-ifies the Iterator pointer (which points into the DEPEX
>>> section), so that the compiler catch any possible accesses at *build
>>> time* that would write to the write-protected DEPEX memory area.
>>
>> On a tangent: the optimization in question highlights a more general
>> problem, namely that the DXE (and possibly MM/SMM) protocol databases
>> are considered slow, for some access patterns.
>>
>> Edk2 implements those protocol databases with linked lists, where
>> lookup costs O(n) operations (average and worst cases). And protocol
>> lookups are quite frequent (for example, in depex evaluations, they
>> could be considered "particularly frequent").
>>
>> (1) The "Tasks" wiki page mentions something *similar* (but not the
>> same); see
>>
>> https://github.com/tianocore/tianocore.github.io/wiki/Tasks#datahub--gcd-scalability
>>
>> The description is: "The DXE core's DataHub and GCD (Global Coherency
>> Domain) layers don't scale well as the number of data items gets
>> large, since they are based on simple linked lists. Find better data
>> structures."
>
> How large do they usually get? What's the worst case?

No idea.

>
>>
>> The same might apply more or less to the protocol database
>> implementation.
>>
>> (2) More to the point, Andrew Fish reported earlier that at Apple,
>> they had rewritten the DXE protocol database, using the red-black
>> tree OrderedCollectionLib that I had contributed previously to edk2
>> -- and they saw significant performance improvements.
>>
>> So upstreaming that feature to edk2 could be very valuable.
>> (Red-black trees have O(log(n)) time cost (worst case) for lookup,
>> insertion and deletion, and O(n) cost for iterating through the whole
>> data structure.)
>
> FWIW, can we do better than an RB tree? They're notoriously cache
> unfriendly...

Sure, if someone contributes a different data structure that is suitable
for the task :)

RB trees may be cache unfriendly, but the functionality they provide
with O(log(n)) worst case performance is amazing. You can use them as
read-write associate arrays, sorted lists supporting forward and
backward traversal (in fact tools for sorting), priority queues, etc.

When I contributed the code, edk2 didn't have any associative array
type, so something generic that would address the widest range of use
cases looked like a good idea. (And indeed the library has been well
applied in several of those use cases since, in various parts of edk2 --
for sorting, uniqueness-checking, async interface token tracking &
lookups.)

This is not an argument against a more suitable data structure of
course. Just pointing out that the RB tree has worked well thus far.
E.g., under the BZ link below, Andrew mentions a diagnostic tool that
creates 3000 handles. Looking up an element in a 3000-element list would
cost 1500 iterations on average; using a balanced binary search tree it
might cost ~11 iterations. Assuming that linked lists and linked binary
search trees are similarly cache-unfriendly, that's a ~136 factor of
improvement.

>
>>
>> Let me see if I can find the bugzilla ticket...
>>
>> Ah, I got it. Apologies, I misremembered: Andrew's comment was not
>> about the protocol database, but about the handle database. Here it
>> is:
>>
>> https://bugzilla.tianocore.org/show_bug.cgi?id=988#c7
>>
>> (the BZ is still CONFIRMED btw...)
>>
>> Still, I think it must be related in a way. Namely, an EFI handle
>> exists if and only if at least one protocol interface is installed on
>> it. If you uninstall the last protocol interface from a handle, then
>> the handle is destroyed -- in fact that's the *only* way to destroy a
>> handle, to my understanding. See
>> EFI_BOOT_SERVICES.UninstallProtocolInterface() in the UEFI spec: "If
>> the last protocol interface is removed from a handle, the handle 

Re: [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg: Initialise serial port early in StandaloneMmEntryPoint

[Laszlo Ersek]

On 1/10/24 17:13, levi.yun wrote:
>> My personal conclusion in that thread was [1], and correspondingly,
>> commit 5087a0773645 ("ArmVirtPkg/FdtPL011SerialPortLib: initialize
>> implicitly", 2023-10-07). In the end, the only tractable solution was to
>> initialize the serial port (hardware, and library instance) exactly
>> once, in (a) the constructor, or (b) the explicit SerialPortInitialize()
>> call, or (c) any SerialPortLib API, whichever occurred first. (And (a)
>> and (b) can be coalesced, because SerialPortInitialize() can be marked
>> as the constructor for the lib instance.)
>>
>> [1]
>> http://mid.mail-archive.com/542db9e1-cd28-27a2-3a98-5b0c85cd7c79@redhat.com
>>  https://edk2.groups.io/g/devel/message/109235
>>
>> Laszlo
>>
> In my personal thinking, It's better to make new interface like
> 
> RETURN_STATUS
> EFIAPI
> SerialPortInitializeEarly (
> VOID
>   );
> 
> to solve this problem.
> 
> Because, It makes a memory permission fault
> when we call SerialPortInitialize like
> ArmVirtPkg/Library/FdtPL011SerialPortLib
> where try to modify global variable.
> 
> At the _ModuleEntryPoint of StandAloneMmCore which is FIRST entry from TF-A
> All of Image area is mapped as RO+X, so before load StandaloneMmCore,
> We couldn't write global variable.
> 
> the purposes of above interface are:
>     - Initalize serial port to use in early environment only (like
> StandAloneMmCore Entry Point) where couldn't write global variable by
> static information (FixedPcd).
>     - It presume that all setting configured by it will be overwritten
> by SerialPortInitialize.

This is not a scalable solution (assuming I understand your proposal
right). It would require the SerialPortLib *class* (i.e., header) to
grow a new API called SerialPortInitializeEarly(), and then all existent
SerialPortLib *instances* -- and there are too many of them -- would
have to implement that function, even if the new function were empty in
several particular library instances.

If you don't have writeable global variables at the time
SerialPortInitialize() is called, then there are two options:

(a) the common option is to just not use global variables for caching
state, and to perform the serial port init on every API call.

(b) A somewhat nasty / limited, but functional approach could be to
check the page protection covering the global variable. Something like this:

STATIC BOOLEAN  mInitialized;

...

  UINTNAddressOfGlobal;
  BOOLEAN  GlobalsWriteable;

  if (mInitialized) {
//
// we're done, nothing to be done
//
return RETURN_SUCCESS;
  }

  //
  // here, perform the serial port initialization
  //
  ...

  //
  // finally:
  //
  AddressOfGlobal = (UINTN)
  GlobalsWriteable = CheckWritable (AddressOfGlobal);
  if (GlobalsWriteable) {
mInitialized = TRUE;
  }

This will keep initing the serial port upon every API call until the
global variable becomes writeable, and then the next API call will init
the serial port for one last time, and also prevent further page table
checks.

The CheckWritable() function is an implementation detail. In the DXE
phase, it could be implemented (I think?) with the
GetMemorySpaceDescriptor() DXE service, or perhaps even the
EFI_MEMORY_ATTRIBUTE_PROTOCOL.GetMemoryAttributes() UEFI protocol member
function. In the standalone MM core, CheckWritable() could walk the page
tables explicitly. The idea is, either way, to *predict* whether writing
to "mInitialized" would trap.

Now I think that speculative / out of order execution could actually
trigger the trap *before* GlobalsWriteable is calculated; however, I
think such a trap should be architecturally hidden (i.e., invisible). I
think at worst we could need a compiler barrier (maybe throw in some
"volatile" for GlobalsWriteable and mInitialized), so that the
*compiler* not try to reorder the accesses. But even that sounds like a
stretch.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113535): https://edk2.groups.io/g/devel/message/113535
Mute This Topic: https://groups.io/mt/103540969/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Laszlo Ersek]

(+ Andrew)

On 1/10/24 14:09, Laszlo Ersek wrote:

> I think that keeping the depex section read-only is valuable, so I'd
> rule out #2. I'd also not start with option #1 -- copying the depex to
> heap memory, just so this optimization can succeed. I'd simply start by
> removing the optimization, and measuring how much driver dispatch slows
> down in practice, on various platforms.
> 
> Can you try this? (I have only build-tested and "uncrustified" it.)
> 
> The patch removes the EFI_DEP_REPLACE_TRUE handling altogether, plus it
> CONST-ifies the Iterator pointer (which points into the DEPEX section),
> so that the compiler catch any possible accesses at *build time* that
> would write to the write-protected DEPEX memory area.

On a tangent: the optimization in question highlights a more general
problem, namely that the DXE (and possibly MM/SMM) protocol databases
are considered slow, for some access patterns.

Edk2 implements those protocol databases with linked lists, where lookup
costs O(n) operations (average and worst cases). And protocol lookups
are quite frequent (for example, in depex evaluations, they could be
considered "particularly frequent").

(1) The "Tasks" wiki page mentions something *similar* (but not the
same); see

https://github.com/tianocore/tianocore.github.io/wiki/Tasks#datahub--gcd-scalability

The description is: "The DXE core's DataHub and GCD (Global Coherency
Domain) layers don't scale well as the number of data items gets large,
since they are based on simple linked lists. Find better data structures."

The same might apply more or less to the protocol database implementation.

(2) More to the point, Andrew Fish reported earlier that at Apple, they
had rewritten the DXE protocol database, using the red-black tree
OrderedCollectionLib that I had contributed previously to edk2 -- and
they saw significant performance improvements.

So upstreaming that feature to edk2 could be very valuable. (Red-black
trees have O(log(n)) time cost (worst case) for lookup, insertion and
deletion, and O(n) cost for iterating through the whole data structure.)

Let me see if I can find the bugzilla ticket...

Ah, I got it. Apologies, I misremembered: Andrew's comment was not about
the protocol database, but about the handle database. Here it is:

https://bugzilla.tianocore.org/show_bug.cgi?id=988#c7

(the BZ is still CONFIRMED btw...)

Still, I think it must be related in a way. Namely, an EFI handle exists
if and only if at least one protocol interface is installed on it. If
you uninstall the last protocol interface from a handle, then the handle
is destroyed -- in fact that's the *only* way to destroy a handle, to my
understanding. See EFI_BOOT_SERVICES.UninstallProtocolInterface() in the
UEFI spec: "If the last protocol interface is removed from a handle, the
handle is freed and is no longer valid". Furthermore, calling
InstallProtocolInterface() and InstallMultipleProtocolInterfaces() is
how one *creates* new handles.

So given how handles and protocol interfaces are conceptually
interlinked, an rbtree-based protocol DB might have to maintain multiple
rbtrees internally (for the ability to search the database quickly with
different types of "keys"). I don't have a design ready in my mind at
all (I'm not that familiar with the *current*, list-based implementation
to begin with!). Upstreaming Apple's (experimental?) code could prove
very helpful.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113532): https://edk2.groups.io/g/devel/message/113532
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Laszlo Ersek]

Hi,

On 1/8/24 11:11, Nhi Pham via groups.io wrote:
> Hi Ard, all,
>
> Could you please help explain how the depex section in an image is
> mapped in terms of memory attribute?
>
> As my observation, dispatcher locates[1] the depex section inside the
> module image and write[2] an evaluated data to the depex if necessary
> for scheduled boot order. The problem that the depex section is now in
> RO+X memory due to a part of the module image, so a writing to depex
> would cause data abort. I'm unsure whether this issue is generic in
> EDK2 or not.
>
> I think of two approaches:
>
> #1 Relocate the depex section to heap memory for dependency
> #evaluation?
>
> #2 EDK2 build tool to support granting write permission for depex
> #section.
>
> [1] StandaloneMmPkg/Core/FwVol.c:236
> [2] StandaloneMmPkg/Core/Dependency.c:256

here's my understanding of the issue.

In Platform Init 1.8, section II-10.7 describes the depex instruction
set for the DXE DISPATCHER. In particular, section II-10.7.3 describes
the PUSH opcode as follows:

  PUSH 

  Pushes a Boolean value onto the stack. If the GUID is present in the
  handle database, then a TRUE is pushed onto the stack. If the GUID is
  not present in the handle database, then a FALSE is pushed onto the
  stack. The test for the GUID in the handle database may be performed
  with the Boot Service LocateProtocol().

This basically says that every time the dispatcher sees a PUSH opcode in
a depex, it has to look up the protocol GUID in the protocol database.

Now, as far as I can tell, edk2's DXE Core implementation wanted to
optimize this. (And this goes back to ancient commit 28a00297189c, from
2007.) Here's the idea AIUI:

- Assume the protocol is not found, i.e. we push a FALSE. This will
likely mean that the driver whose DEPEX contains this PUSH opcode cannot
be dispatched just yet. In other words, we're going to have to
re-evaluate this PUSH at least once more, possibly multiple times. We
cannot optimize anything here, because the needed protocol is not
present yet, but it may become available later. When we next evaluate
the DEPEX for this driver, we'll check again if the protocol has become
available by then.

- Assume the protocol is found, i.e. we push a TRUE. The optimization
here is that we assume the protocol will not *disappear*, once
available. The evaluation of the driver's *entire* DEPEX may still
result in FALSE, so it's not guaranteed that the driver can be
dispatched right now. However, given our assumption that the protocol
we've just found will not disappear during DXE driver dispatch, we might
want to "cache" the current successful protocol lookup, and when we
*next* evaluate the DEPEX for this same driver (assuming we cannot
dispatch it right now due to something else missing from its DEPEX), we
don't want to perform the *same* protocol lookup again -- we'll just
want to remember it was already there last time.

And the way the DXE core seems to implement this optimization (i.e., how
it "remembers success") is that it patches the DEPEX in-place: it
replaces the PUSH opcode with a special (edk2-specific) opcode called
EFI_DEP_REPLACE_TRUE (in addition to pushing the TRUE of course, to the
eval stack). This opcode is functionally identical to the plain (and
standard) TRUE opcode, so the next time the dispatcher evaluates the
same depex and sees EFI_DEP_REPLACE_TRUE it will just push TRUE, the
difference with the TRUE opcode is that EFI_DEP_REPLACE_TRUE also
provides "room" for the -- otherwise useless -- original protocol GUID
that used to be the argument of the PUSH opcode. The dispatcher ignores
the protocol GUID on EFI_DEP_REPLACE_TRUE, beyond logging it.

EFI_DEP_REPLACE_TRUE is documented in the code as follows
("MdeModulePkg/Core/Dxe/DxeMain.h"):

///
/// EFI_DEP_REPLACE_TRUE - Used to dynamically patch the dependency expression
///to save time.  A EFI_DEP_PUSH is evaluated one an
///replaced with EFI_DEP_REPLACE_TRUE. If PI spec's Vol 
2
///Driver Execution Environment Core Interface use 0xff
///as new DEPEX opcode. EFI_DEP_REPLACE_TRUE should be
///defined to a new value that is not conflicting with 
PI spec.
///
#define EFI_DEP_REPLACE_TRUE  0xff

This documentation is hard to understand due to English grammar errors.
It means to say:

"Used to dynamically patch the dependency expression to save time.  An
EFI_DEP_PUSH opcode is evaluated *once*, *and* replaced with
EFI_DEP_REPLACE_TRUE. If PI spec's Vol 2 Driver Execution Environment
Core Interface *starts using* 0xff as new DEPEX opcode *in the future*,
*then* EFI_DEP_REPLACE_TRUE should be *redefined* to a new value that is
not conflicting with *said new* PI spec."

Over time, this optimization (hack) has made its way into the
traditional PiSmmCore, and finally into the standalone SMM core,
apparently.

In summary, this seems like a performance optimization, and should 

Re: [edk2-devel] [PATCH] UefiCpuPkg:Limit PhysicalAddressBits in speicial case

[Laszlo Ersek]

On 1/10/24 11:54, Gerd Hoffmann wrote:
> On Wed, Jan 10, 2024 at 04:05:44PM +0800, Dun Tan wrote:
>> When creating smm page table, limit maximum
>> supported physical address bits returned by
>> CalculateMaximumSupportAddress() to 48 if
>> 5-Level Paging is disabled.
>> When 5-Level Paging is disabled and the
>> PhysicalAddressBits retrived from CPU HOB or
>> CpuId is bigger than 48, only [0, 2^48 -1]
>> range in 52-bit physical address is mapped
>> in page table.
> 
> I think this is wrong.  Virtual addresses are sign-extended,
> i.e. the virtual address space without 5-level paging is:
> 
>  0x -> 0x7fff and
>  0x8000 -> 0x
> 
> Therefore identity-mapping works for [0, 2^47-1] only.

I'd have never noticed this. I'll happily defer reviewing this patch to
you then! :)

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113529): https://edk2.groups.io/g/devel/message/113529
Mute This Topic: https://groups.io/mt/103637402/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix issue that IsModified is wrongly set in PageTableMap

[Laszlo Ersek]

On 1/10/24 06:38, Zhiguang Liu wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4614
> 
> Fix issue that IsModified is wrongly set in PageTableMap.
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Crystal Lee 
> Signed-off-by: Zhiguang Liu 
> ---
>  UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c 
> b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> index 36b2c4e6a3..164187f151 100644
> --- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> +++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> @@ -567,7 +567,10 @@ PageTableLibMapInLevel (
>  OriginalCurrentPagingEntry.Uint64 = CurrentPagingEntry->Uint64;
>  PageTableLibSetPle (Level, CurrentPagingEntry, Offset, Attribute, 
> );
>  
> -if (OriginalCurrentPagingEntry.Uint64 != CurrentPagingEntry->Uint64) 
> {
> +if (Modify && (OriginalCurrentPagingEntry.Uint64 != 
> CurrentPagingEntry->Uint64)) {
> +  //
> +  // The page table entry can be changed by this function only when 
> Modify is true.
> +  //
>*IsModified = TRUE;
>  }
>}
> @@ -609,7 +612,10 @@ PageTableLibMapInLevel (
>// Check if ParentPagingEntry entry is modified here is enough. Except the 
> changes happen in leaf PagingEntry during
>// the while loop, if there is any other change happens in page table, the 
> ParentPagingEntry must has been modified.
>//
> -  if (OriginalParentPagingEntry.Uint64 != ParentPagingEntry->Uint64) {
> +  if (Modify && (OriginalParentPagingEntry.Uint64 != 
> ParentPagingEntry->Uint64)) {
> +//
> +// The page table entry can be changed by this function only when Modify 
> is true.
> +//
>  *IsModified = TRUE;
>}
>  

This function is incredibly complicated, so reviewing this patch is
hard, even after reading the bugzilla ticket.

The commit message is useless. It should contain a brief description of
the problem, and how the fix resolves the problem.

The documentation of the PageTableLibMapInLevel() function is wrong,
even before this patch. It documents the "IsModified" output-only
parameter as follows:

"TRUE means page table is modified. FALSE means page table is not modified."

This states that "IsModified" is always set on output, to either FALSE
or TRUE. Which is an incorrect statement; in reality the caller is
expected to pre-set (*IsModified) to FALSE, and PageTableLibMapInLevel()
will (conditionally!) perform a FALSE->TRUE transition only.

Now, this patch may fix a bug, but it makes the above-described
documentation issue worse, by further restricting the condition for said
FALSE->TRUE transition.

The fix per se looks vaguely reasonable to me (really the function is so
complicated that verifying this change from scratch would take me ages),
but minimally, the documentation of "IsModified" should certainly be
updated too. To something like this:

  @param[out] IsModified  If "Modify" is TRUE on input and the function
  has actually modified the page table, then set
  to TRUE on output. Not overwritten otherwise.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113528): https://edk2.groups.io/g/devel/message/113528
Mute This Topic: https://groups.io/mt/103636407/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg/CpuMpPei: Don't write CR3 in ConvertMemoryPageToNotPresent

[Laszlo Ersek]

On 1/10/24 06:43, Zhiguang Liu wrote:
> After ConvertMemoryPageToNotPresent, there is always a flush TLB
> function. So, to improve performance, there is no need to write CR3
> inside ConvertMemoryPageToNotPresent
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Zhiguang Liu 
> ---
>  UefiCpuPkg/CpuMpPei/CpuPaging.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/CpuPaging.c b/UefiCpuPkg/CpuMpPei/CpuPaging.c
> index 15c7015fb8..c6894458f7 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuPaging.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuPaging.c
> @@ -167,7 +167,6 @@ ConvertMemoryPageToNotPresent (
>}
>  
>ASSERT_EFI_ERROR (Status);
> -  AsmWriteCr3 (PageTable);
>return Status;
>  }
>  

(1) I mostly understand the point that the commit message makes, but the
message is not clear enough. The real point is that we have two
ConvertMemoryPageToNotPresent() calls altogether, and each of those
takes place in a *loop*, and each of those loops is followed by a
CpuFlushTlb() call.

The loops matter. If there were no loops, then we might be motivated to
choose a different solution (for example, to move centralize the
CpuFlushTlb() calls *inside* ConvertMemoryPageToNotPresent(), or
something similar).

So, please update the commit message; mention the loops.

(2) I can't easily see why this change is actually correct. IIRC,
writing CR3 has a "side effect" of flushing the TLB. But obviously,
that's not the *only* effect of writing CR3. You could say that
CpuFlushTlb() performs a *strict subset* of what AsmWriteCr3() performs.
Therefore, in order to replace AsmWriteCr3() with just CpuFlushTlb(),
you need to demonstrate that the functionality that now is *not* going
to be done has always been superfluous. In more direct terms, you need
to show that the AsmWriteCr3() write call that's being removed here
never actuall changes the *value* of CR3.

And I cannot show that myself very easily.
ConvertMemoryPageToNotPresent(). In ConvertMemoryPageToNotPresent(),
"PageTable" is first set from AsmReadCr3(), then passed twice to
PageTableMap() by reference (!), and then it is written back to CR3. If
at least one of those PageTableMap() calls change "PageTable", then the
AsmWriteCr3() call at the end that's now being removed actually changes
the value of CR3, and then the patch would be wrong.

It's possible that PageTableMap() never changes the value of
"PageTable", but it must be proved, and the evidence should be included
in the commit message.

(3) Furthermore, with the patch applied, ConvertMemoryPageToNotPresent()
will no longer flush the TLB itself -- that will always be left to the
caller. This new caller responsibility should be documented in the
leading comment of ConvertMemoryPageToNotPresent(). We already have a
paragraph there starting with "Caller should make sure..."

Sorry for making such a big deal out of this, but such simple-looking
changes can sometimes case obscure (and rarely occurring) bugs down the
road. If you already have evidence that CR3 does not change here, that's
great, but then please don't think it's "obvious"; just go ahead and
document it.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113527): https://edk2.groups.io/g/devel/message/113527
Mute This Topic: https://groups.io/mt/103636435/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 3/3] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 1/9/24 15:11, Gerd Hoffmann wrote:
>   Hi,
> 
>> Nit: to my knowledge, the coding style forbids initialization of "auto"
>> storage class variables (more commonly put, "non-static local
>> variables"). IOW, we should spell the above as:
>>
>> | diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c 
>> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
>> | index ca2e40743dfd..8fcd999ac6df 100644
>> | --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
>> | +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
>> | @@ -283,7 +283,9 @@ ValidateFvHeader (
>> |
>> |  if (VarHeaderEnd >= VariableStoreHeader->Size) {
>> |if (VarOffset <= VariableStoreHeader->Size - sizeof (UINT16)) {
>> | -CONST UINT16  *StartId = (VOID *)((UINTN)VariableStoreHeader + 
>> VarOffset);
>> | +CONST UINT16  *StartId;
>> | +
>> | +StartId = (VOID *)((UINTN)VariableStoreHeader + VarOffset);
>> |  if (*StartId == 0x55aa) {
>> |DEBUG ((DEBUG_ERROR, "%a: startid at invalid location\n", 
>> __func__));
>> |return EFI_NOT_FOUND;
>>
>> Do you want me to fix up the patch upon merge for you,
> 
> I happily accept that service offer ;)

Series merged as commit range 08a6528bac38..4a443f73fd67, via
. (Last three commits in
the PR.)

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113484): https://edk2.groups.io/g/devel/message/113484
Mute This Topic: https://groups.io/mt/103617812/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V3 0/2] Change the usage of input parameter ProcessorNumber in MpInitLibGetProcessorInfo() of MpInitLibUp

[Laszlo Ersek]

On 1/8/24 06:08, duntan wrote:
> Please ignore the V2 PATCH set. No other change except adding BaseMemoryLib 
> headfile and lib instance in .inf to pass build since ZeroMem() is used. 
> 
> Comparing to the V1 patch set:
> In "set EXTENDED_PROCESSOR_INFORMATION to 0", set 
> EXTENDED_PROCESSOR_INFORMATION to 0 in API MpInitLibGetProcessorInfo() of 
> MpInitLibUp. This commit use ZeroMem() to set all fileds in output 
> EFI_PROCESSOR_INFORMATION to 0 before StatusFlag field is reassigned.
> 
> In "Check lower 24 bits of ProcessorNumber", use BIT24 instead of 
> CPU_V2_EXTENDED_TOPOLOGY to clearly tell that processor number only occupies 
> the lower 24 bits.
> 
> Dun Tan (2):
>   UefiCpuPkg: set EXTENDED_PROCESSOR_INFORMATION to 0
>   UefiCpuPkg: Check lower 24 bits of ProcessorNumber
> 
>  UefiCpuPkg/Include/Library/MpInitLib.h |  2 ++
>  UefiCpuPkg/Library/MpInitLib/MpLib.c   |  2 ++
>  UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c   | 20 
>  UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.inf |  1 +
>  4 files changed, 17 insertions(+), 8 deletions(-)
> 

Merged as commit range f2b074398ca0..08a6528bac38, via
 (first two commits in the PR).

BR
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113483): https://edk2.groups.io/g/devel/message/113483
Mute This Topic: https://groups.io/mt/103592277/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Updates to .mailmap needed for Jeff Brasen, Jake Garver, Joey Vagades and Michael Roth?

[Laszlo Ersek]

On 1/9/24 13:28, Michael Brown wrote:
> On 09/01/2024 12:13, Laszlo Ersek wrote:
>> On 1/9/24 11:45, Ard Biesheuvel wrote:
>>> Note that git am does support a 'From: ' header as the first line of
>>> the commit log, and will use it correctly to supersede the From:
>>> header in the SMTP envelope.
>>
>> OTOH, that doesn't help in this case, IIUC. When the poster originally
>> formats and sends the patch, their gitconfig says
>> user.email=foo...@example.com, and the author meta-datum on the patch
>> most likely *also* says foo...@example.com. (I.e., they are formatting a
>> patch they have authored themselves.) Therefore
>> git-format-patch/git-send-email have no reason to include an explicit
>> "From:" line at the top of the commit message body. I agree that
>> "From:", if present, mitigates the issue, but in most cases, I reckon,
>> it's not present.
> 
> Is there a way to configure git to force git-format-patch to
> unconditionally include the inline "From:" header?  I tried:
> 
>   git config format.forceInBodyFrom true
> 
> which is described in the man page as "may help if the mailing list
> software mangles the sender’s identity", but it seems to have an effect
> only if "--from" is also specified.

That still sounds great; I (and I expect many others) use alias(es)
around git-format-patch anyway (because of [1] eg.), so wiring "--from"
into that could work. (Not that I personally need this quirk right at
the moment.)

[1]
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23

What confuses me is that git-format-patch(1) specifically advises
against the "--from" option "if you are feeding the result to git
send-email". Huh.

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113448): https://edk2.groups.io/g/devel/message/113448
Mute This Topic: https://groups.io/mt/103534194/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 3/3] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 1/9/24 12:29, Gerd Hoffmann wrote:
> Extend the ValidateFvHeader function, additionally to the header checks
> walk over the list of variables and sanity check them.
>
> In case we find inconsistencies indicating variable store corruption
> return EFI_NOT_FOUND so the variable store will be re-initialized.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf |   1 +
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c   | 147 +++-
>  2 files changed, 143 insertions(+), 5 deletions(-)
>
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> index 2a3d4a218e61..f549400280a1 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> @@ -34,6 +34,7 @@ [LibraryClasses]
>DxeServicesTableLib
>HobLib
>IoLib
> +  SafeIntLib
>UefiBootServicesTableLib
>UefiDriverEntryPoint
>UefiLib
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> index 9a614ae4b24d..ca2e40743dfd 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -185,11 +186,12 @@ ValidateFvHeader (
>IN  NOR_FLASH_INSTANCE  *Instance
>)
>  {
> -  UINT16  Checksum;
> -  EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader;
> -  VARIABLE_STORE_HEADER   *VariableStoreHeader;
> -  UINTN   VariableStoreLength;
> -  UINTN   FvLength;
> +  UINT16Checksum;
> +  CONST EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader;
> +  CONST VARIABLE_STORE_HEADER   *VariableStoreHeader;
> +  UINTN VarOffset;
> +  UINTN VariableStoreLength;
> +  UINTN FvLength;
>
>FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER *)Instance->RegionBaseAddress;
>
> @@ -258,6 +260,141 @@ ValidateFvHeader (
>  return EFI_NOT_FOUND;
>}
>
> +  //
> +  // check variables
> +  //
> +  DEBUG ((DEBUG_INFO, "%a: checking variables\n", __func__));
> +  VarOffset = sizeof (*VariableStoreHeader);
> +  for ( ; ;) {
> +UINTNVarHeaderEnd;
> +UINTNVarNameEnd;
> +UINTNVarEnd;
> +UINTNVarPadding;
> +CONST AUTHENTICATED_VARIABLE_HEADER  *VarHeader;
> +CONST CHAR16 *VarName;
> +CONST CHAR8  *VarState;
> +RETURN_STATUSStatus;
> +
> +Status = SafeUintnAdd (VarOffset, sizeof (*VarHeader), );
> +if (RETURN_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "%a: integer overflow\n", __func__));
> +  return EFI_NOT_FOUND;
> +}
> +
> +if (VarHeaderEnd >= VariableStoreHeader->Size) {
> +  if (VarOffset <= VariableStoreHeader->Size - sizeof (UINT16)) {
> +CONST UINT16  *StartId = (VOID *)((UINTN)VariableStoreHeader + 
> VarOffset);
> +if (*StartId == 0x55aa) {
> +  DEBUG ((DEBUG_ERROR, "%a: startid at invalid location\n", 
> __func__));
> +  return EFI_NOT_FOUND;
> +}
> +  }
> +
> +  DEBUG ((DEBUG_INFO, "%a: end of var list (no space left)\n", 
> __func__));
> +  break;
> +}

I didn't think of this, but it certainly makes sense. Continues
accepting trailing garbage, unless the tail starts with 0x55aa, which
indicates that it's indeed either a truncated variable header, or one
that's not truncated, but just fits (and has no room for subsequent
name/data).

Furthermore, we consider "VariableStoreHeader->Size" trusted & valid
here, therefore the subtraction of sizeof (UINT16) is not supposed to
wrap under. (The field is documented with: "Size of entire variable
store, including size of variable store header but not including the
size of FvHeader". The varstore hdr structure is larger than 2 bytes.)

Reviewed-by: Laszlo Ersek 

Nit: to my knowledge, the coding style forbids initialization of "auto"
storage class variables (more commonly put, "non-static local
variables"). IOW, we should spell the above as:

| diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c 
b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
| index ca2e40743dfd..8fcd999ac6df 100644
| --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
| +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
| @@ -283,7 +283,9 @@ ValidateFvHeader (
|
|

Re: [edk2-devel] Updates to .mailmap needed for Jeff Brasen, Jake Garver, Joey Vagades and Michael Roth?

[Laszlo Ersek]

On 1/9/24 11:45, Ard Biesheuvel wrote:
> On Tue, 9 Jan 2024 at 10:17, Laszlo Ersek  wrote:
>>
>> On 1/5/24 01:05, Rebecca Cran via groups.io wrote:
>>> I noticed recent commits by Jeff Brasen, Jake Garver, Joey Vagades and
>>> Michael Roth have funky Author lines, which I think means .mailmap needs
>>> updated?
>>>
>>> Author: Jeff Brasen via groups.io 
>>> Author: Joey Vagedes via groups.io 
>>> Author: Jake Garver via groups.io 
>>> Author: Roth, Michael via groups.io 
>>
>> I'm sure I'm confusing the terms here, but this is a consequence of
>> DMARC / DKIM / whatever, for some senders. groups.io cannot resend some
>> kind of messages to list subscribers where the original sender domain
>> (such as nvidia.com, microsoft.com, amd.com) is cryptographically
>> authenticated. If groups.io resent those messages with identical "from",
>> then the recipients (list subscribers) would reject those messages,
>> because they'd perceive the messages as fakes (the crypto check would
>> catch that the messages came from groups.io but claimed to originate
>> from nvidia.com, microsoft.com, amd.com -- that's exactly what DKIM /
>> DMARC etc etc are supposed to prevent). Therefore groups.io rewrites the
>> sender email addresses like seen above, and then "git-am" picks up those
>> rewritten addresses verbatim. That's how they end up in the git commit
>> history.
>>
>> This can be manually fixed by whoever applies such patches from the
>> list: after the initial "git-am", a git-rebase is needed, and each patch
>> needs to have its author meta-datum fixed with "git commit --amend
>> --author='corrected email address'". It's a lot of manual and error
>> prone work (unless someone scripts it, effectively "decoding" the
>> rewriting format that groups.io employs). As much as it pains me to
>> admit it, this is definitely an argument in favor of git forge-based
>> contributions, and against mailing list-based patches.
>>
>> ".mailmap" can be used to mitigate this issue, per gitmailmap(5); it'd
>> be better just not to permit such mangled "From:" fields to seep into
>> the git log, in the future. :/
>>
> 
> Agreed, and I think this came up somewhere last year perhaps? Mike
> Kinney (cc'ed) might remember if that went anywhere, but the idea was
> for PatchCheck.py (which is also used in CI) to reject patches using
> an email address in this format.

Oh, great idea. When CI runs PatchCheck.py on the final "push" PR, that
would definitely catch this issue just in time!

> 
> Note that git am does support a 'From: ' header as the first line of
> the commit log, and will use it correctly to supersede the From:
> header in the SMTP envelope.

OTOH, that doesn't help in this case, IIUC. When the poster originally
formats and sends the patch, their gitconfig says
user.email=foo...@example.com, and the author meta-datum on the patch
most likely *also* says foo...@example.com. (I.e., they are formatting a
patch they have authored themselves.) Therefore
git-format-patch/git-send-email have no reason to include an explicit
"From:" line at the top of the commit message body. I agree that
"From:", if present, mitigates the issue, but in most cases, I reckon,
it's not present.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113445): https://edk2.groups.io/g/devel/message/113445
Mute This Topic: https://groups.io/mt/103534194/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Updates to .mailmap needed for Jeff Brasen, Jake Garver, Joey Vagades and Michael Roth?

[Laszlo Ersek]

On 1/5/24 01:05, Rebecca Cran via groups.io wrote:
> I noticed recent commits by Jeff Brasen, Jake Garver, Joey Vagades and
> Michael Roth have funky Author lines, which I think means .mailmap needs
> updated?
> 
> Author: Jeff Brasen via groups.io 
> Author: Joey Vagedes via groups.io 
> Author: Jake Garver via groups.io 
> Author: Roth, Michael via groups.io 

I'm sure I'm confusing the terms here, but this is a consequence of
DMARC / DKIM / whatever, for some senders. groups.io cannot resend some
kind of messages to list subscribers where the original sender domain
(such as nvidia.com, microsoft.com, amd.com) is cryptographically
authenticated. If groups.io resent those messages with identical "from",
then the recipients (list subscribers) would reject those messages,
because they'd perceive the messages as fakes (the crypto check would
catch that the messages came from groups.io but claimed to originate
from nvidia.com, microsoft.com, amd.com -- that's exactly what DKIM /
DMARC etc etc are supposed to prevent). Therefore groups.io rewrites the
sender email addresses like seen above, and then "git-am" picks up those
rewritten addresses verbatim. That's how they end up in the git commit
history.

This can be manually fixed by whoever applies such patches from the
list: after the initial "git-am", a git-rebase is needed, and each patch
needs to have its author meta-datum fixed with "git commit --amend
--author='corrected email address'". It's a lot of manual and error
prone work (unless someone scripts it, effectively "decoding" the
rewriting format that groups.io employs). As much as it pains me to
admit it, this is definitely an argument in favor of git forge-based
contributions, and against mailing list-based patches.

".mailmap" can be used to mitigate this issue, per gitmailmap(5); it'd
be better just not to permit such mangled "From:" fields to seep into
the git log, in the future. :/

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113436): https://edk2.groups.io/g/devel/message/113436
Mute This Topic: https://groups.io/mt/103534194/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 3/3] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 1/8/24 20:21, Gerd Hoffmann wrote:
> Extend the ValidateFvHeader function, additionally to the header checks
> walk over the list of variables and sanity check them.
> 
> In case we find inconsistencies indicating variable store corruption
> return EFI_NOT_FOUND so the variable store will be re-initialized.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf |   1 +
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c   | 139 +++-
>  2 files changed, 135 insertions(+), 5 deletions(-)
> 
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> index 2a3d4a218e61..f549400280a1 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> @@ -34,6 +34,7 @@ [LibraryClasses]
>DxeServicesTableLib
>HobLib
>IoLib
> +  SafeIntLib
>UefiBootServicesTableLib
>UefiDriverEntryPoint
>UefiLib
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> index 9a614ae4b24d..56148e9f1f95 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -185,11 +186,13 @@ ValidateFvHeader (
>IN  NOR_FLASH_INSTANCE  *Instance
>)
>  {
> -  UINT16  Checksum;
> -  EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader;
> -  VARIABLE_STORE_HEADER   *VariableStoreHeader;
> -  UINTN   VariableStoreLength;
> -  UINTN   FvLength;
> +  UINT16Checksum;
> +  CONST EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader;
> +  CONST VARIABLE_STORE_HEADER   *VariableStoreHeader;
> +  UINTN VarOffset;
> +  UINTN VariableStoreLength;
> +  UINTN FvLength;
> +  RETURN_STATUS Status;

(1) Status could have been moved in the "for" loop, AFAICT -- also
mentioned in my previous review --, but it's not a sticking point.

>  
>FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER *)Instance->RegionBaseAddress;
>  
> @@ -258,6 +261,132 @@ ValidateFvHeader (
>  return EFI_NOT_FOUND;
>}
>  
> +  //
> +  // check variables
> +  //
> +  DEBUG ((DEBUG_INFO, "%a: checking variables\n", __func__));
> +  VarOffset = sizeof (*VariableStoreHeader);
> +  for ( ; ;) {
> +UINTNVarHeaderEnd;
> +UINTNVarNameEnd;
> +UINTNVarEnd;
> +UINTNVarPadding;
> +CONST AUTHENTICATED_VARIABLE_HEADER  *VarHeader;
> +CHAR16   *VarName;

(2) Should have noticed in my previous review: VarName could be
CONST-ified as well.

Totally minor.

> +CONST CHAR8  *VarState;
> +
> +Status = SafeUintnAdd (VarOffset, sizeof (*VarHeader), );
> +if (RETURN_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "%a: integer overflow\n", __func__));
> +  return EFI_NOT_FOUND;
> +}
> +
> +if (VarHeaderEnd >= VariableStoreHeader->Size) {
> +  DEBUG ((DEBUG_INFO, "%a: end of var list (no space left)\n", 
> __func__));
> +  break;
> +}

(3) I *still* don't understand this.

In the v3 discussion:

- we agreed that the ">" case was clearly unacceptable,

- and you convinced me that the "=" case was also unacceptable (because
that could only potentially accommodate a VAR_HEADER_VALID_ONLY state
header without subsequent space for name & data, and we agreed that a
var header like that, residing *permanently* in the varstore, was not
acceptable).

Fine: that's reason for keeping the unified ">=" condition. But my point
in turn (which you didn't reflect upon, and seem not to have addressed
in this patch) was that this condition means that the varstore is
*bogus*, and should be reformatted. In my previous review I recommended
that we replace the "break" here -- which leads to the function
returning EFI_SUCCESS -- with "return EFI_NOT_FOUND" -- which causes the
varstore to be reformatted.

And then, as I wrote, the only successful exit from the loop would be
the subsequent "break" below:

> +
> +VarHeader = (VOID *)((UINTN)VariableStoreHeader + VarOffset);
> +if (VarHeader->StartId != 0x55aa) {
> +  DEBUG ((DEBUG_INFO, "%a: end of var list (no startid)\n", __func__));
> +  break;
> +}

So: what's wrong with returning EFI_NOT_FOUND if

  VarHeaderEnd >= VariableStoreHeader->Size

evaluates to true?

> +
> +VarName = NULL;
> +switch (VarHeader->State) {
> +  // usage: State = VAR_HEADER_VALID_ONLY
> +  case VAR_HEADER_VALID_ONLY:
> +VarState = "header-ok";
> +VarName  = L"";
> +break;
> +
> +  // usage: State = VAR_ADDED
> +  case VAR_ADDED:
> +VarState = "ok";
> +

Re: [edk2-devel] [PATCH v4 2/3] OvmfPkg/VirtNorFlashDxe: stop accepting gEfiVariableGuid

[Laszlo Ersek]

On 1/8/24 20:21, Gerd Hoffmann wrote:
> Only accept gEfiAuthenticatedVariableGuid when checking the variable
> store header in ValidateFvHeader().
> 
> The edk2 code base has been switched to use the authenticated varstore
> format unconditionally (even in case secure boot is not used or
> supported) a few years ago.
> 
> Suggested-by: László Érsek 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> index 5ee98e9b595a..9a614ae4b24d 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> @@ -239,9 +239,7 @@ ValidateFvHeader (
>VariableStoreHeader = (VARIABLE_STORE_HEADER *)((UINTN)FwVolHeader + 
> FwVolHeader->HeaderLength);
>  
>// Check the Variable Store Guid
> -  if (!CompareGuid (>Signature, ) &&
> -  !CompareGuid (>Signature, 
> ))
> -  {
> +  if (!CompareGuid (>Signature, 
> )) {
>  DEBUG ((
>DEBUG_INFO,
>"%a: Variable Store Guid non-compatible\n",

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113432): https://edk2.groups.io/g/devel/message/113432
Mute This Topic: https://groups.io/mt/103605076/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 1/3] OvmfPkg/RiscVVirt: use gEfiAuthenticatedVariableGuid unconditionally

[Laszlo Ersek]

On 1/8/24 20:21, Gerd Hoffmann wrote:
> ArmVirt and OVMF are doing the same.
> 
> See commit d92eaabefbe0 ("OvmfPkg: simplify VARIABLE_STORE_HEADER
> generation") for details.
> 
> Suggested-by: László Érsek 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/RiscVVirt/VarStore.fdf.inc | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/OvmfPkg/RiscVVirt/VarStore.fdf.inc 
> b/OvmfPkg/RiscVVirt/VarStore.fdf.inc
> index aba32315cc37..6679c246b3ea 100644
> --- a/OvmfPkg/RiscVVirt/VarStore.fdf.inc
> +++ b/OvmfPkg/RiscVVirt/VarStore.fdf.inc
> @@ -36,19 +36,12 @@
># Blockmap[1]: End
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>## This is the VARIABLE_STORE_HEADER
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> +  # It is compatible with SECURE_BOOT_ENABLE == FALSE as well.
># Signature: gEfiAuthenticatedVariableGuid =
>#   { 0xaaf32c78, 0x947b, 0x439a,
># { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92 }}
>0x78, 0x2c, 0xf3, 0xaa, 0x7b, 0x94, 0x9a, 0x43,
>0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92,
> -!else
> -  # Signature: gEfiVariableGuid =
> -  #   { 0xddcf3616, 0x3275, 0x4164,
> -  # { 0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f, 0xfe, 0x7d }}
> -  0x16, 0x36, 0xcf, 0xdd, 0x75, 0x32, 0x64, 0x41,
> -  0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f, 0xfe, 0x7d,
> -!endif
># Size: 0x4 
> (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) -
># 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0x3FFB8
># This can speed up the Variable Dispatch a bit.

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113431): https://edk2.groups.io/g/devel/message/113431
Mute This Topic: https://groups.io/mt/103605055/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 24/36] ArmVirtPkg: Move PlatformBootManagerLib to OvmfPkg

[Laszlo Ersek]

On 1/9/24 07:40, Chao Li wrote:
> Hi Laszlo,
> 
> 
> Thanks,
> Chao
> On 2024/1/8 22:02, Laszlo Ersek wrote:
>> On 1/5/24 10:45, Chao Li wrote:
>>> Moved the PlatformBootManagerLib to OvmfPkg and renamed to
>>> PlatformBootManagerLibLight for easy use by other ARCH.
>>>
>>> Build-tested only (with "ArmVirtQemu.dsc").
>>>
>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
>>>
>>> Cc: Ard Biesheuvel 
>>> Cc: Leif Lindholm 
>>> Cc: Sami Mujawar 
>>> Cc: Gerd Hoffmann 
>>> Cc: Jiewen Yao 
>>> Cc: Lazlo Ersek 
>>> Signed-off-by: Chao Li 
>>> ---
>>>  ArmVirtPkg/ArmVirtPkg.ci.yaml  | 1 -
>>>  ArmVirtPkg/ArmVirtPkg.dec  | 1 -
>>>  ArmVirtPkg/ArmVirtQemu.dsc | 2 +-
>>>  ArmVirtPkg/ArmVirtQemuKernel.dsc   | 2 +-
>>>  .../Library/PlatformBootManagerLibLight}/PlatformBm.c  | 0
>>>  .../Library/PlatformBootManagerLibLight}/PlatformBm.h  | 0
>>>  .../PlatformBootManagerLib.inf | 7 +++
>>>  .../Library/PlatformBootManagerLibLight}/QemuKernel.c  | 0
>>>  OvmfPkg/OvmfPkg.dec| 4 
>>>  9 files changed, 9 insertions(+), 8 deletions(-)
>>>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
>>> OvmfPkg/Library/PlatformBootManagerLibLight}/PlatformBm.c (100%)
>>>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
>>> OvmfPkg/Library/PlatformBootManagerLibLight}/PlatformBm.h (100%)
>>>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
>>> OvmfPkg/Library/PlatformBootManagerLibLight}/PlatformBootManagerLib.inf 
>>> (92%)
>>>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
>>> OvmfPkg/Library/PlatformBootManagerLibLight}/QemuKernel.c (100%)
>>>
>>> diff --git a/ArmVirtPkg/ArmVirtPkg.ci.yaml b/ArmVirtPkg/ArmVirtPkg.ci.yaml
>>> index 506b0e72f0..b186d4eb42 100644
>>> --- a/ArmVirtPkg/ArmVirtPkg.ci.yaml
>>> +++ b/ArmVirtPkg/ArmVirtPkg.ci.yaml
>>> @@ -24,7 +24,6 @@
>>>  ],
>>>  ## Both file path and directory path are accepted.
>>>  "IgnoreFiles": [
>>> -"Library/PlatformBootManagerLib/PlatformBm.c"
>>>  ]
>>>  },
>>>  ## options defined .pytool/Plugin/CompilerPlugin
>> You don't seem to be reinstating this under OvmfPkg, so I think the same 
>> source file under OvmfPkg will cause a CI failure.
> 
> There was no CI failure, there was a PR for edk2 in the cover letter,
> all of the CI are passed.
> 
> https://github.com/tianocore/edk2/pull/5208

My mistake -- and looking closer, I understand the reason (for the
successful build). In OvmfPkg.ci.yaml, EccCheck is skipped altogether.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113427): https://edk2.groups.io/g/devel/message/113427
Mute This Topic: https://groups.io/mt/103540123/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 24/36] ArmVirtPkg: Move PlatformBootManagerLib to OvmfPkg

[Laszlo Ersek]

On 1/5/24 10:45, Chao Li wrote:
> Moved the PlatformBootManagerLib to OvmfPkg and renamed to
> PlatformBootManagerLibLight for easy use by other ARCH.
> 
> Build-tested only (with "ArmVirtQemu.dsc").
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
> 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Lazlo Ersek 
> Signed-off-by: Chao Li 
> ---
>  ArmVirtPkg/ArmVirtPkg.ci.yaml  | 1 -
>  ArmVirtPkg/ArmVirtPkg.dec  | 1 -
>  ArmVirtPkg/ArmVirtQemu.dsc | 2 +-
>  ArmVirtPkg/ArmVirtQemuKernel.dsc   | 2 +-
>  .../Library/PlatformBootManagerLibLight}/PlatformBm.c  | 0
>  .../Library/PlatformBootManagerLibLight}/PlatformBm.h  | 0
>  .../PlatformBootManagerLib.inf | 7 +++
>  .../Library/PlatformBootManagerLibLight}/QemuKernel.c  | 0
>  OvmfPkg/OvmfPkg.dec| 4 
>  9 files changed, 9 insertions(+), 8 deletions(-)
>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
> OvmfPkg/Library/PlatformBootManagerLibLight}/PlatformBm.c (100%)
>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
> OvmfPkg/Library/PlatformBootManagerLibLight}/PlatformBm.h (100%)
>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
> OvmfPkg/Library/PlatformBootManagerLibLight}/PlatformBootManagerLib.inf (92%)
>  rename {ArmVirtPkg/Library/PlatformBootManagerLib => 
> OvmfPkg/Library/PlatformBootManagerLibLight}/QemuKernel.c (100%)
> 
> diff --git a/ArmVirtPkg/ArmVirtPkg.ci.yaml b/ArmVirtPkg/ArmVirtPkg.ci.yaml
> index 506b0e72f0..b186d4eb42 100644
> --- a/ArmVirtPkg/ArmVirtPkg.ci.yaml
> +++ b/ArmVirtPkg/ArmVirtPkg.ci.yaml
> @@ -24,7 +24,6 @@
>  ],
>  ## Both file path and directory path are accepted.
>  "IgnoreFiles": [
> -"Library/PlatformBootManagerLib/PlatformBm.c"
>  ]
>  },
>  ## options defined .pytool/Plugin/CompilerPlugin

You don't seem to be reinstating this under OvmfPkg, so I think the same source 
file under OvmfPkg will cause a CI failure.

> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
> index 315db4e8ea..6aa5ea05f4 100644
> --- a/ArmVirtPkg/ArmVirtPkg.dec
> +++ b/ArmVirtPkg/ArmVirtPkg.dec
> @@ -27,7 +27,6 @@
>  
>  [LibraryClasses]
>ArmVirtMemInfoLib|Include/Library/ArmVirtMemInfoLib.h
> -  FdtSerialPortAddressLib|Include/Library/FdtSerialPortAddressLib.h
>  
>  [Guids.common]
>gArmVirtTokenSpaceGuid = { 0x0B6F5CA7, 0x4F53, 0x445A, { 0xB7, 0x6E, 0x2E, 
> 0x36, 0x5B, 0x80, 0x63, 0x66 } }

> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index a03c30995b..2ed7863a98 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -144,6 +144,10 @@
>#
>HardwareInfoLib|Include/Library/HardwareInfoLib.h
>  
> +  ##  @libraryclass  FdtSerialPortAddressLib
> +  #
> +  FdtSerialPortAddressLib|Include/Library/FdtSerialPortAddressLib.h
> +
>  [Guids]
>gUefiOvmfPkgTokenSpaceGuid= {0x93bb96af, 0xb9f2, 0x4eb8, 
> {0x94, 0x62, 0xe0, 0xba, 0x74, 0x56, 0x42, 0x36}}
>gEfiXenInfoGuid   = {0xd3b46f3b, 0xd441, 0x1244, 
> {0x9a, 0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}

These two hunks don't seem to belong in this patch -- I think they might belong 
to patch 22, "ArmVirtPkg: Move the FdtSerialPortAddressLib to OvmfPkg"; is that 
right?

Also, the lib classes in the [LibraryClasses] section of the DEC file was 
originally meant to be lexicographically sorted. Over time, soring errors got 
introduced; it would be nice to restore the sort order in a separate patch. 
(Although it's not a pre-requisite for this patch set to be accepted, I guess.)


> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 147180f645..e48c75b5e9 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -70,7 +70,7 @@
>  
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> -  
> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +  
> PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLibLight/PlatformBootManagerLib.inf
>
> PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index c22a422353..668a65ba64 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -69,7 +69,7 @@
>  
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> -  
> 

Re: [edk2-devel] [PATCH v10 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Laszlo Ersek]

Hi Dhaval,

On 12/13/23 15:59, Dhaval Sharma wrote:
> Use newly defined cache management operations for RISC-V where possible
> It builds up on the support added for RISC-V cache management
> instructions in BaseLib.
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Laszlo Ersek 
> Cc: Pedro Falcato 
> 
> Signed-off-by: Dhaval Sharma 
> Acked-by: Laszlo Ersek 
> Reviewed-by: Pedro Falcato 
> ---
> 
> Notes:
> V10:
> - Fix formatting to keep comments within 80
> - Replace RV with RISC-V
> - Fix an issue with multi line comments
> - Added assert to an unsupported function
> - Minor case modification in str in .uni
> 
> V9:
> - Fixed an issue with Instruction cache invalidation. Use fence.i
>   instruction as CMO does not support i-cache operations.
> V8:
> - Added note to convert PCD into RISC-V feature bitmap pointer
> - Modified function names to be more explicit about cache ops
> - Added RB tag
> V7:
> - Added PcdLib
> - Restructure DEBUG message based on feedback on V6
> - Make naming consistent to CMO, remove all CBO references
> - Add ASSERT for not supported functions instead of plain debug message
> - Added RB tag
> V6:
> - Utilize cache management instructions if HW supports it
>   This patch is part of restructuring on top of v5
> 
>  MdePkg/MdePkg.dec  |   8 +
>  MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |   5 +
>  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c| 177 
> 
>  MdePkg/MdePkg.uni  |   4 +
>  4 files changed, 166 insertions(+), 28 deletions(-)
> 
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index ac54338089e8..fa92673ff633 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64, 
> PcdsPatchableInModule.AARCH64]
># @Prompt CPU Rng algorithm's GUID.
>
> gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
>  
> +[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
> +  #
> +  # Configurability to override RISC-V CPU Features
> +  # BIT 0 = Cache Management Operations. This bit is relevant only if
> +  # previous stage has feature enabled and user wants to disable it.
> +  #
> +  
> gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
> +
>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
>## This value is used to set the base address of PCI express hierarchy.
># @Prompt PCI Express Base Address.
> diff --git 
> a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf 
> b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> index 6fd9cbe5f6c9..601a38d6c109 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> @@ -56,3 +56,8 @@ [LibraryClasses]
>BaseLib
>DebugLib
>  
> +[LibraryClasses.RISCV64]
> +  PcdLib
> +
> +[Pcd.RISCV64]
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride  ## CONSUMES
> diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c 
> b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> index ac2a3c23a249..7c53a17abbb5 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> @@ -2,6 +2,7 @@
>RISC-V specific functionality for cache.
>  
>Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +  Copyright (c) 2023, Rivos Inc. All rights reserved.
>  
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  **/
> @@ -9,10 +10,116 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +//
> +// TODO: Grab cache block size and make Cache Management Operation
> +// enabling decision based on RISC-V CPU HOB in
> +// future when it is available and convert PcdRiscVFeatureOverride
> +// PCD to a pointer that contains pointer to bitmap structure
> +// which can be operated more elegantly.
> +//
> +#define RISCV_CACHE_BLOCK_SIZE 64
> +#define RISCV_CPU_FEATURE_CMO_BITMASK  0x1
> +
> +typedef enum {
> +  CacheOpClean,
> +  CacheOpFlush,
> +  CacheOpInvld,
> +} CACHE_OP;
> +
> +/**
> +Verify CBOs are supported by this HW
> +TODO: Use RISC-V CPU HOB once available.
> +
> +**/
> +STATIC
> +BOOLEAN
> +RiscVIsCMOEnabled (
> +  VOID
> +  )
> +

Re: [edk2-devel] [PATCH v2 3/4] UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc

[Laszlo Ersek]

On 1/8/24 12:36, Sunil V L wrote:
> Sstc extension allows to program the timer and receive the interrupt
> without using an SBI call. This reduces the latency to generate the timer
> interrupt. So, detect whether Sstc extension is supported and use the
> stimecmp register directly to program the timer interrupt.
> 
> Cc: Gerd Hoffmann 
> Cc: Rahul Kumar 
> Cc: Laszlo Ersek 
> Cc: Ray Ni 
> Cc: Andrei Warkentin 
> Signed-off-by: Sunil V L 
> ---
>  .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf |  1 +
>  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h |  2 +
>  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 49 +--
>  3 files changed, 49 insertions(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf 
> b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> index aba660186dc0..f2a2cf12caef 100644
> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> @@ -41,6 +41,7 @@ [Sources.RISCV64]
>Timer.c
>  
>  [Pcd]
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride   ## CONSUMES
>gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ## CONSUMES
>  
>  [Protocols]
> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h 
> b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> index 9b3542230cb5..067bbd29f377 100644
> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> @@ -26,6 +26,8 @@
>  //
>  #define DEFAULT_TIMER_TICK_DURATION  10
>  
> +#define RISCV_CPU_FEATURE_SSTC_BITMASK  BIT1
> +
>  extern VOID
>  RiscvSetTimerPeriod (
>UINT32  TimerPeriod
> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c 
> b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> index 30e48061cd06..216f48a52931 100644
> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> @@ -44,6 +44,45 @@ STATIC EFI_TIMER_NOTIFY  mTimerNotifyFunction;
>  STATIC UINT64  mTimerPeriod = 0;
>  STATIC UINT64  mLastPeriodStart = 0;
>  
> +//
> +// Sstc support
> +//
> +STATIC BOOLEAN  mSstcEnabled = FALSE;
> +
> +/**
> +  Program the timer.
> +
> +  Program either using stimecmp (when Sstc extension is enabled) or using SBI
> +  TIME call.
> +
> +  @param NextValue Core tick value the timer should expire.
> +**/
> +STATIC
> +VOID
> +RiscVProgramTimer (
> +  UINT64  NextValue
> +  )
> +{
> +  if (mSstcEnabled) {
> +RiscVSetSupervisorTimeCompareRegister (NextValue);
> +  } else {
> +SbiSetTimer (NextValue);
> +  }
> +}
> +
> +/**
> +  Check whether Sstc is enabled in PCD.
> +
> +**/
> +STATIC
> +BOOLEAN
> +RiscVIsSstcEnabled (
> +  VOID
> +  )
> +{
> +  return ((PcdGet64 (PcdRiscVFeatureOverride) & 
> RISCV_CPU_FEATURE_SSTC_BITMASK) != 0);
> +}
> +
>  /**
>Timer Interrupt Handler.
>  
> @@ -94,7 +133,7 @@ TimerInterruptHandler (
>   ),
> 100u
> );  // convert to tick
> -  SbiSetTimer (PeriodStart);
> +  RiscVProgramTimer (PeriodStart);
>RiscVEnableTimerInterrupt (); // enable SMode timer int
>gBS->RestoreTPL (OriginalTPL);
>  }
> @@ -197,8 +236,7 @@ TimerDriverSetTimerPeriod (
>   ),
> 100u
> ); // convert to tick
> -  SbiSetTimer (PeriodStart);
> -
> +  RiscVProgramTimer (PeriodStart);
>mCpu->EnableInterrupt (mCpu);
>RiscVEnableTimerInterrupt (); // enable SMode timer int
>return EFI_SUCCESS;
> @@ -282,6 +320,11 @@ TimerDriverInitialize (
>//
>mTimerNotifyFunction = NULL;
>  
> +  if (RiscVIsSstcEnabled ()) {
> +mSstcEnabled = TRUE;
> +DEBUG ((DEBUG_INFO, "TimerDriverInitialize: Timer interrupt is via Sstc 
> extension\n"));
> +  }
> +
>//
>// Make sure the Timer Architectural Protocol is not already installed in 
> the system
>//

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113389): https://edk2.groups.io/g/devel/message/113389
Mute This Topic: https://groups.io/mt/103595210/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V3 0/2] Change the usage of input parameter ProcessorNumber in MpInitLibGetProcessorInfo() of MpInitLibUp

[Laszlo Ersek]

On 1/8/24 06:08, duntan wrote:
> Please ignore the V2 PATCH set. No other change except adding BaseMemoryLib 
> headfile and lib instance in .inf to pass build since ZeroMem() is used. 

Reviewed-by: Laszlo Ersek 


> 
> Comparing to the V1 patch set:
> In "set EXTENDED_PROCESSOR_INFORMATION to 0", set 
> EXTENDED_PROCESSOR_INFORMATION to 0 in API MpInitLibGetProcessorInfo() of 
> MpInitLibUp. This commit use ZeroMem() to set all fileds in output 
> EFI_PROCESSOR_INFORMATION to 0 before StatusFlag field is reassigned.
> 
> In "Check lower 24 bits of ProcessorNumber", use BIT24 instead of 
> CPU_V2_EXTENDED_TOPOLOGY to clearly tell that processor number only occupies 
> the lower 24 bits.
> 
> Dun Tan (2):
>   UefiCpuPkg: set EXTENDED_PROCESSOR_INFORMATION to 0
>   UefiCpuPkg: Check lower 24 bits of ProcessorNumber
> 
>  UefiCpuPkg/Include/Library/MpInitLib.h |  2 ++
>  UefiCpuPkg/Library/MpInitLib/MpLib.c   |  2 ++
>  UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c   | 20 
>  UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.inf |  1 +
>  4 files changed, 17 insertions(+), 8 deletions(-)
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113388): https://edk2.groups.io/g/devel/message/113388
Mute This Topic: https://groups.io/mt/103592277/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V2 0/2] Change the usage of input parameter ProcessorNumber in MpInitLibGetProcessorInfo() of MpInitLibUp

[Laszlo Ersek]

On 1/8/24 04:55, duntan wrote:
> In the V2 patch set:
> In "set EXTENDED_PROCESSOR_INFORMATION to 0", set 
> EXTENDED_PROCESSOR_INFORMATION to 0 in API MpInitLibGetProcessorInfo() of 
> MpInitLibUp. This commit use ZeroMem() to set all fileds in output 
> EFI_PROCESSOR_INFORMATION to 0 before StatusFlag field is reassigned.
> 
> In "Check lower 24 bits of ProcessorNumber", use BIT24 instead of 
> CPU_V2_EXTENDED_TOPOLOGY to clearly tell that processor number only occupies 
> the lower 24 bits.
> 
> Dun Tan (2):
>   UefiCpuPkg: set EXTENDED_PROCESSOR_INFORMATION to 0
>   UefiCpuPkg: Check lower 24 bits of ProcessorNumber
> 
>  UefiCpuPkg/Include/Library/MpInitLib.h   |  2 ++
>  UefiCpuPkg/Library/MpInitLib/MpLib.c |  2 ++
>  UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c | 19 +++
>  3 files changed, 15 insertions(+), 8 deletions(-)
> 

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113387): https://edk2.groups.io/g/devel/message/113387
Mute This Topic: https://groups.io/mt/103591526/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg: Initialise serial port early in StandaloneMmEntryPoint

[Laszlo Ersek]

On 1/5/24 19:38, Oliver Smith-Denny wrote:
> On 1/5/2024 9:22 AM, levi.yun wrote:
>>
>> Hi Ard :)
>>
>>> So now we will always initialize the serial port in the entrypoint
>>> only because DebugLib might use it later with doing the
>>> initialization.
>>>
>>> That doesn't sound quite correct to me.
>>>
>>> Could you explain why we cannot rely on DebugLib to call the
>>> initializer / constructor at the right time?
>> Because, DebugLib constructor which use serial port is called in
>> StandAloneMmMain function.
>> But, this constrcutor is in _ModuleEntryPoint in StandAloneMmCoreEntry.
>>
>> That means all DEBUG used in _ModuleEntryPoint can use uninitialized
>> serial port.
>> one of typical example is GetSpmVersion function.
>>
>>  _ModuleEntryPoint (in StandAloneMmCoreEntry)
>>
>>   // Hazard Area start
>>  GetSpmVersion
>>  DEBUG (DEBUG_INFO, xxx)  // It could be use uninitalized
>> Serial port.
>>
>>  ...
>>  //  Hazard Area end
>>  ProcessModuleEntryPointList (StandAloneMmMain)
>>  ProcessLibraryConstructorList // Here. call DebugLib
>> constructor with SerialPortIntialize
>>
>> When you see above, I would be clear. between Hazard Area Start to
>> Hazard Area End.
>> DEBUG macro would use uninitailized Serial port if that's not
>> initialized by TF-A.
>>
>> So, It should be call SerialPortInitialized at the _ModuleEntryPoint.
>
> + Laszlo
>
> This sounds very similar to our DxeCore early serial logging discussion
> a couple months ago :).
>
> Laszlo wrote up a good summary here:
> https://edk2.groups.io/g/devel/topic/101203427#109235.
>
> If I am understanding correctly, this would be the "lower left" in
> Laszlo's diagram.
>
> Standalone MM is likely smaller missing window than in DxeCore, but
> some important information could be lost there (like the SPM version
> called out, which could be very important for debugging early crashes).
>
> So this goes back to should be we have a more generic solution for the
> cores to use early logging, by fixing the SerialPortLibs? I'll parse
> this more and reread the old thread further, still paging the info back
> in.

My personal conclusion in that thread was [1], and correspondingly,
commit 5087a0773645 ("ArmVirtPkg/FdtPL011SerialPortLib: initialize
implicitly", 2023-10-07). In the end, the only tractable solution was to
initialize the serial port (hardware, and library instance) exactly
once, in (a) the constructor, or (b) the explicit SerialPortInitialize()
call, or (c) any SerialPortLib API, whichever occurred first. (And (a)
and (b) can be coalesced, because SerialPortInitialize() can be marked
as the constructor for the lib instance.)

[1] http://mid.mail-archive.com/542db9e1-cd28-27a2-3a98-5b0c85cd7c79@redhat.com
https://edk2.groups.io/g/devel/message/109235

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113386): https://edk2.groups.io/g/devel/message/113386
Mute This Topic: https://groups.io/mt/103540969/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] UefiCpuPkg: Retrive EXTENDED_PROCESSOR_INFORMATION

[Laszlo Ersek]

On 1/5/24 13:56, Ni, Ray wrote:
> Laszlo,
> Good suggestion.
> 
> Your solution will not work if in future some extra fields might require to 
> be set to non-zero.
> But future is not coming yet. I agree with your approach.

Well, if we need to set some fields to nonzero, manual assignments will
become necessary either way, with or without the ZeroMem(). With the
ZeroMem(), we just overwrite the zero values later.

I certainly agree that there is a tipping point. Like, if we have 5
fields, and we need to set 4 of them to nonzero values, then an initial
ZeroMem is wasteful. Right now the ZeroMem() looks much more frugal, and
a bit more future-proof too.

Thanks!
Laszlo

> 
> Thanks,
> Ray
>> -Original Message-
>> From: Tan, Dun 
>> Sent: Friday, January 5, 2024 5:25 PM
>> To: Laszlo Ersek ; devel@edk2.groups.io
>> Cc: Ni, Ray ; Kumar, Rahul R ;
>> Gerd Hoffmann ; Xu, Min M 
>> Subject: RE: [edk2-devel] [PATCH 1/2] UefiCpuPkg: Retrive
>> EXTENDED_PROCESSOR_INFORMATION
>>
>> Hi Laszlo,
>>
>> Thanks for your comments. I agree with your solution. It seems simpler and
>> clearer. Will change the code and keep the additional function comments in
>> next version patch set.
>>
>> Thanks,
>> Dun
>>
>> -Original Message-
>> From: Laszlo Ersek 
>> Sent: Thursday, January 4, 2024 10:53 PM
>> To: devel@edk2.groups.io; Tan, Dun 
>> Cc: Ni, Ray ; Kumar, Rahul R ;
>> Gerd Hoffmann ; Xu, Min M 
>> Subject: Re: [edk2-devel] [PATCH 1/2] UefiCpuPkg: Retrive
>> EXTENDED_PROCESSOR_INFORMATION
>>
>> On 1/4/24 08:32, duntan wrote:
>>> Retrive EXTENDED_PROCESSOR_INFORMATION in the API
>>> MpInitLibGetProcessorInfo() of MpInitLibUp instance when the BIT24 of
>>> input ProcessorNumber is set.
>>> It's to align with the behavior in PEI/DXE MpInitLib
>>>
>>> Signed-off-by: Dun Tan 
>>> Cc: Ray Ni 
>>> Cc: Laszlo Ersek 
>>> Cc: Rahul Kumar 
>>> Cc: Gerd Hoffmann 
>>> Cc: Min Xu 
>>> ---
>>>  UefiCpuPkg/Include/Library/MpInitLib.h   |  2 ++
>>>  UefiCpuPkg/Library/MpInitLib/MpLib.c |  2 ++
>>>  UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c | 12 
>>>  3 files changed, 16 insertions(+)
>>>
>>> diff --git a/UefiCpuPkg/Include/Library/MpInitLib.h
>>> b/UefiCpuPkg/Include/Library/MpInitLib.h
>>> index 1853c46415..842c6f7ff9 100644
>>> --- a/UefiCpuPkg/Include/Library/MpInitLib.h
>>> +++ b/UefiCpuPkg/Include/Library/MpInitLib.h
>>> @@ -63,6 +63,8 @@ MpInitLibGetNumberOfProcessors (
>>>instant this call is made. This service may only be called from the BSP.
>>>
>>>@param[in]  ProcessorNumber   The handle number of processor.
>>> +Lower 24 bits contains the actual 
>>> processor number.
>>> +BIT24 indicates if the
>> EXTENDED_PROCESSOR_INFORMATION will be retrived.
>>>@param[out] ProcessorInfoBuffer   A pointer to the buffer where
>> information for
>>>  the requested processor is deposited.
>>>@param[out] HealthDataReturn processor health data.
>>> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
>>> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
>>> index a359906923..cdfb570e61 100644
>>> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
>>> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
>>> @@ -2333,6 +2333,8 @@ MpInitLibInitialize (
>>>instant this call is made. This service may only be called from the BSP.
>>>
>>>@param[in]  ProcessorNumber   The handle number of processor.
>>> +Lower 24 bits contains the actual 
>>> processor number.
>>> +BIT24 indicates if the
>> EXTENDED_PROCESSOR_INFORMATION will be retrived.
>>>@param[out] ProcessorInfoBuffer   A pointer to the buffer where
>> information for
>>>  the requested processor is deposited.
>>>@param[out]  HealthDataReturn processor health data.
>>> diff --git a/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
>>> b/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
>>> index 86f9fbf903..3af4911d4b 100644
>>> --- a/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
>>> +++ b/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
>>> @@ -77,6 +77,8 @@ MpInitLibGetNumberOfProcessors (
>>>instant this call is made. T

Re: [edk2-devel] [PATCH 2/2] UefiCpuPkg: Check lower 24 bits of ProcessorNumber

[Laszlo Ersek]

On 1/5/24 13:55, Ni, Ray wrote:
>>> -  if (ProcessorNumber != 0) {
>>> +  //
>>> +  // Lower 24 bits contains the actual processor number.
>>> +  //
>>> +  if ((ProcessorNumber & (CPU_V2_EXTENDED_TOPOLOGY - 1)) != 0) {
> I suggest we explicitly use BIT24 instead of CPU_V2_EXTENDED_TOPOLOGY.
> Using BIT24 clearly tells that processor number only occupies the lower 24 
> bits.

Yes, I've noticed this discrepancy too; I agree BIT24 is clearer here!

> 
> 
>>>  return EFI_NOT_FOUND;
>>>}
>>>
>>
>> Reviewed-by: Laszlo Ersek 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113287): https://edk2.groups.io/g/devel/message/113287
Mute This Topic: https://groups.io/mt/103518743/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg/PiSmmCpuDxeSmm: Optimize PatchSmmSaveStateMap and FlushTlbForAll

[Laszlo Ersek]

On 1/5/24 13:52, Ni, Ray wrote:
> Reviewed-by: Ray Ni 

Thanks, please feel free to merge this!
Laszlo

> 
> 
> Thanks,
> Ray
>> -Original Message-
>> From: Jin, Zhi 
>> Sent: Friday, January 5, 2024 10:54 AM
>> To: devel@edk2.groups.io
>> Cc: Jin, Zhi ; Ni, Ray ; Laszlo Ersek
>> ; Kumar, Rahul R ; Gerd
>> Hoffmann ; Wu, Jiaxin 
>> Subject: [PATCH v2 1/1] UefiCpuPkg/PiSmmCpuDxeSmm: Optimize
>> PatchSmmSaveStateMap and FlushTlbForAll
>>
>> PatchSmmSaveStateMap patches the SMM entry (code) and SmmSaveState
>> region (data) for each core, which can be improved to flush TLB once
>> after all the memory entries have been patched.
>> FlushTlbForAll flushes TLB for each core in serial, which can be
>> improved to flush TLB in parrallel.
>>
>> v2:
>>Add the missing FlushTlbForAll() back in PatchSmmSaveStateMap().
>>
>> Cc: Ray Ni 
>> Cc: Laszlo Ersek 
>> Cc: Rahul Kumar 
>> Cc: Gerd Hoffmann 
>> Cc: Jiaxin Wu 
>> Signed-off-by: Zhi Jin 
>> ---
>>  .../PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c   | 97
>> +--
>>  1 file changed, 65 insertions(+), 32 deletions(-)
>>
>> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
>> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
>> index 15f998e501..12f3c0b8e8 100644
>> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
>> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
>> @@ -547,17 +547,14 @@ FlushTlbForAll (
>>VOID
>>)
>>  {
>> -  UINTN  Index;
>> -
>>FlushTlbOnCurrentProcessor (NULL);
>> -
>> -  for (Index = 0; Index < gSmst->NumberOfCpus; Index++) {
>> -if (Index != gSmst->CurrentlyExecutingCpu) {
>> -  // Force to start up AP in blocking mode,
>> -  SmmBlockingStartupThisAp (FlushTlbOnCurrentProcessor, Index, NULL);
>> -  // Do not check return status, because AP might not be present in some
>> corner cases.
>> -}
>> -  }
>> +  InternalSmmStartupAllAPs (
>> +(EFI_AP_PROCEDURE2)FlushTlbOnCurrentProcessor,
>> +0,
>> +NULL,
>> +NULL,
>> +NULL
>> +);
>>  }
>>
>>  /**
>> @@ -799,72 +796,108 @@ PatchSmmSaveStateMap (
>>UINTN  TileCodeSize;
>>UINTN  TileDataSize;
>>UINTN  TileSize;
>> +  UINTN  PageTableBase;
>>
>> -  TileCodeSize = GetSmiHandlerSize ();
>> -  TileCodeSize = ALIGN_VALUE (TileCodeSize, SIZE_4KB);
>> -  TileDataSize = (SMRAM_SAVE_STATE_MAP_OFFSET - SMM_PSD_OFFSET) +
>> sizeof (SMRAM_SAVE_STATE_MAP);
>> -  TileDataSize = ALIGN_VALUE (TileDataSize, SIZE_4KB);
>> -  TileSize = TileDataSize + TileCodeSize - 1;
>> -  TileSize = 2 * GetPowerOfTwo32 ((UINT32)TileSize);
>> +  TileCodeSize  = GetSmiHandlerSize ();
>> +  TileCodeSize  = ALIGN_VALUE (TileCodeSize, SIZE_4KB);
>> +  TileDataSize  = (SMRAM_SAVE_STATE_MAP_OFFSET - SMM_PSD_OFFSET) +
>> sizeof (SMRAM_SAVE_STATE_MAP);
>> +  TileDataSize  = ALIGN_VALUE (TileDataSize, SIZE_4KB);
>> +  TileSize  = TileDataSize + TileCodeSize - 1;
>> +  TileSize  = 2 * GetPowerOfTwo32 ((UINT32)TileSize);
>> +  PageTableBase = AsmReadCr3 () & PAGING_4K_ADDRESS_MASK_64;
>>
>>DEBUG ((DEBUG_INFO, "PatchSmmSaveStateMap:\n"));
>>for (Index = 0; Index < mMaxNumberOfCpus - 1; Index++) {
>>  //
>>  // Code
>>  //
>> -SmmSetMemoryAttributes (
>> +ConvertMemoryPageAttributes (
>> +  PageTableBase,
>> +  mPagingMode,
>>mCpuHotPlugData.SmBase[Index] + SMM_HANDLER_OFFSET,
>>TileCodeSize,
>> -  EFI_MEMORY_RO
>> +  EFI_MEMORY_RO,
>> +  TRUE,
>> +  NULL
>>);
>> -SmmClearMemoryAttributes (
>> +ConvertMemoryPageAttributes (
>> +  PageTableBase,
>> +  mPagingMode,
>>mCpuHotPlugData.SmBase[Index] + SMM_HANDLER_OFFSET,
>>TileCodeSize,
>> -  EFI_MEMORY_XP
>> +  EFI_MEMORY_XP,
>> +  FALSE,
>> +  NULL
>>);
>>
>>  //
>>  // Data
>>  //
>> -SmmClearMemoryAttributes (
>> +ConvertMemoryPageAttributes (
>> +  PageTableBase,
>> +  mPagingMode,
>>mCpuHotPlugData.SmBase[Index] + SMM_HANDLER_OFFSET +
>> TileCodeSize,
>>TileSize - TileCodeSize,
>> -  EFI_MEMORY_RO
>> +  EFI_MEMORY_RO,
>> +  FALSE,
>> +  NULL
>>);
>> -SmmSetMemoryAttri

Re: [edk2-devel] [PATCH 3/4] UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc

[Laszlo Ersek]

On 1/4/24 16:46, Sunil V L wrote:
> On Thu, Jan 04, 2024 at 03:38:17PM +0100, Laszlo Ersek wrote:
>> On 1/3/24 14:58, Sunil V L wrote:
>>> Sstc extension allows to program the timer and receive the interrupt
>>> without using an SBI call. This reduces the latency to generate the timer
>>> interrupt. So, detect whether Sstc extension is supported and use the
>>> stimecmp register directly to program the timer interrupt.
>>>
>>> Cc: Gerd Hoffmann 
>>> Cc: Rahul Kumar 
>>> Cc: Laszlo Ersek 
>>> Cc: Ray Ni 
>>> Cc: Andrei Warkentin 
>>> Signed-off-by: Sunil V L 
>>> ---
>>>  .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf |  1 +
>>>  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h |  2 ++
>>>  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 30 +--
>>>  3 files changed, 31 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf 
>>> b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
>>> index aba660186dc0..f2a2cf12caef 100644
>>> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
>>> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
>>> @@ -41,6 +41,7 @@ [Sources.RISCV64]
>>>Timer.c
>>>  
>>>  [Pcd]
>>> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride   ## CONSUMES
>>>gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ## CONSUMES
>>>  
>>>  [Protocols]
>>> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h 
>>> b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
>>> index 9b3542230cb5..5e5071b3f0b2 100644
>>> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
>>> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
>>> @@ -26,6 +26,8 @@
>>>  //
>>>  #define DEFAULT_TIMER_TICK_DURATION  10
>>>  
>>> +#define RISCV_CPU_FEATURE_SSTC_BITMASK  0x2
>>
>> (1) Not a bug by any means, but BIT1 might read more idiomatic.
>>
> I misunderstood your comment. Will use BIT1 instead of 0x2.

OK then :)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113285): https://edk2.groups.io/g/devel/message/113285
Mute This Topic: https://groups.io/mt/103501843/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/4] UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc

[Laszlo Ersek]

On 1/4/24 16:01, Sunil V L wrote:
> Hi Laszlo,
> 
> Thank you very much for the review!.
> 
> On Thu, Jan 04, 2024 at 03:38:17PM +0100, Laszlo Ersek wrote:
>> On 1/3/24 14:58, Sunil V L wrote:
>>> Sstc extension allows to program the timer and receive the interrupt
>>> without using an SBI call. This reduces the latency to generate the timer
>>> interrupt. So, detect whether Sstc extension is supported and use the
>>> stimecmp register directly to program the timer interrupt.
>>>
>>> Cc: Gerd Hoffmann 
>>> Cc: Rahul Kumar 
>>> Cc: Laszlo Ersek 
>>> Cc: Ray Ni 
>>> Cc: Andrei Warkentin 
>>> Signed-off-by: Sunil V L 
>>> ---
>>>  .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf |  1 +
>>>  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h |  2 ++
>>>  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 30 +--
>>>  3 files changed, 31 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf 
>>> b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
>>> index aba660186dc0..f2a2cf12caef 100644
>>> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
>>> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
>>> @@ -41,6 +41,7 @@ [Sources.RISCV64]
>>>Timer.c
>>>  
>>>  [Pcd]
>>> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride   ## CONSUMES
>>>gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ## CONSUMES
>>>  
>>>  [Protocols]
>>> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h 
>>> b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
>>> index 9b3542230cb5..5e5071b3f0b2 100644
>>> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
>>> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
>>> @@ -26,6 +26,8 @@
>>>  //
>>>  #define DEFAULT_TIMER_TICK_DURATION  10
>>>  
>>> +#define RISCV_CPU_FEATURE_SSTC_BITMASK  0x2
>>
>> (1) Not a bug by any means, but BIT1 might read more idiomatic.
>>
> Agree. Would RISCV_CPU_FEATURE_BIT1_SSTC be better?

Sorry, I was unclear: the macro *name* was fine, IMO; my proposal was to
change the *replacement text* from 0x2 to BIT1. (Because BIT1 is another
macro, from "MdePkg/Include/Base.h"; those are frequently used all over
edk2.)

Thanks!
Laszlo

> 
>>> +
>>>  extern VOID
>>>  RiscvSetTimerPeriod (
>>>UINT32  TimerPeriod
>>> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c 
>>> b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
>>> index 30e48061cd06..4babfb4bfc60 100644
>>> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
>>> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
>>> @@ -44,6 +44,19 @@ STATIC EFI_TIMER_NOTIFY  mTimerNotifyFunction;
>>>  STATIC UINT64  mTimerPeriod = 0;
>>>  STATIC UINT64  mLastPeriodStart = 0;
>>>  
>>> +/**
>>> +  Check whether Sstc is enabled in PCD.
>>> +
>>> +**/
>>> +STATIC
>>> +BOOLEAN
>>> +RiscVIsSstcEnabled (
>>> +  VOID
>>> +  )
>>> +{
>>> +  return ((PcdGet64 (PcdRiscVFeatureOverride) & 
>>> RISCV_CPU_FEATURE_SSTC_BITMASK) != 0);
>>> +}
>>> +
>>>  /**
>>>Timer Interrupt Handler.
>>>  
>>> @@ -94,7 +107,12 @@ TimerInterruptHandler (
>>>   ),
>>> 100u
>>> );  // convert to tick
>>> -  SbiSetTimer (PeriodStart);
>>> +  if (RiscVIsSstcEnabled ()) {
>>
>> (2) Even though the PCD is currently declared as fixed or
>> patchable-in-module, seeing a PcdGet64() call on the call stack of the
>> timer interrupt handler (and at a high TPL) makes me uncomfortable. It
>> carries a risk that later on we relax the PCD decl to dynamic, and then
>> this code would become brittle.
>>
>> I propose: either replace the PcdGet64 call above with FixedPcdGet64 (so
>> it can never land in the runtime / dynamic PCD protocol), or perform the
>> PCD check in the entry point function of the driver, and store the
>> result in a STATIC BOOLEAN variable. Then further PCD accesses (dynamic
>> or otherwise) will not be needed.
>>
> Ahh yes. Good point. Let me use a static variable as you suggested.
> 
>>> +RiscVSetSupervisorTimeCompareRegister (PeriodStart);
>>> +  } else {
>>> +SbiSetTimer (PeriodStart);
>>> +  }
>>> +
>>>RiscVEnableTimerInterrupt (); // enable S

Re: [edk2-devel] [PATCH v3 1/1] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 1/4/24 16:06, Gerd Hoffmann wrote:
>   Hi,
> 
 - if the StartId is 0x55aa, then we need to look further, beause we
 can't decide yet. For example, if State is VAR_HEADER_VALID_ONLY (0x7f),
 then it might be fine for the variable header (at the very end of the
 varstore) *not* to be followed by payload bytes (name, data).
>>>
>>> Not sure this makes sense.  VAR_HEADER_VALID_ONLY is a temporary state,
>>> while the variable driver writes name and data just after the header,
>>> to be updated to VAR_ADDED when the write completed successfully.  So
>>> I'd expect to never find a header without space for name + data.
>>
>> - Do we know for sure that VAR_HEADER_VALID_ONLY is never expected to be
>> seen?
> 
> Writing goes like this:
> 
>   (1) find free space
>   (2) write header, with VAR_HEADER_VALID_ONLY.
>   (3) write name + data
>   (4) update header, set state = VAR_ADDED.
> 
>> What if the variable update design defines VAR_HEADER_VALID_ONLY
>> specifically so that the variable driver can recover from a power loss
>> "in the middle"?
> 
> Power loss in step (3) can surely lead to variables in
> VAR_HEADER_VALID_ONLY state, and I'd expect the variable driver can
> actually recover from that.
> 
> [ side note:  The (2) write should be small enough that it fits into the
>   flash block write buffer (128 bytes).  Which could be
>   important to maintain variable store consistency. ]
> 
> Nevertheless we should never find a header at the end of the variable
> store, without space allocated for name + date.  Minimal space for the
> name is 4 bytes (one char16 + '\0'), for the data 1 byte, alignment
> rounds the latter to 4 bytes too, so this should be true:
> 
> VarOffset + sizeof(*VarHeader) + 8 <= VariableStoreHeader->Size
> 
>> So I figure, if we accept VAR_HEADER_VALID_ONLY in that logic, then we
>> should also accept VAR_HEADER_VALID_ONLY if it's at the very end of
>> the varstore.
> 
> Disagree, see above.  Storing the header at a place which leaves no room
> for name + data doesn't make sense to me.

OK, that sounds convincing, thanks!
Laszlo

> We could go the extra mile and look at the next StartId location, verify
> StartId != 0x55aa, in the no-space-left-for-header case.
> 
> take care,
>   Gerd
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113283): https://edk2.groups.io/g/devel/message/113283
Mute This Topic: https://groups.io/mt/103171811/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] UefiCpuPkg: Retrive EXTENDED_PROCESSOR_INFORMATION

[Laszlo Ersek]

On 1/4/24 08:32, duntan wrote:
> Retrive EXTENDED_PROCESSOR_INFORMATION in the API
> MpInitLibGetProcessorInfo() of MpInitLibUp instance
> when the BIT24 of input ProcessorNumber is set.
> It's to align with the behavior in PEI/DXE MpInitLib
> 
> Signed-off-by: Dun Tan 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Min Xu 
> ---
>  UefiCpuPkg/Include/Library/MpInitLib.h   |  2 ++
>  UefiCpuPkg/Library/MpInitLib/MpLib.c |  2 ++
>  UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c | 12 
>  3 files changed, 16 insertions(+)
> 
> diff --git a/UefiCpuPkg/Include/Library/MpInitLib.h 
> b/UefiCpuPkg/Include/Library/MpInitLib.h
> index 1853c46415..842c6f7ff9 100644
> --- a/UefiCpuPkg/Include/Library/MpInitLib.h
> +++ b/UefiCpuPkg/Include/Library/MpInitLib.h
> @@ -63,6 +63,8 @@ MpInitLibGetNumberOfProcessors (
>instant this call is made. This service may only be called from the BSP.
>  
>@param[in]  ProcessorNumber   The handle number of processor.
> +Lower 24 bits contains the actual 
> processor number.
> +BIT24 indicates if the 
> EXTENDED_PROCESSOR_INFORMATION will be retrived.
>@param[out] ProcessorInfoBuffer   A pointer to the buffer where 
> information for
>  the requested processor is deposited.
>@param[out] HealthDataReturn processor health data.
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index a359906923..cdfb570e61 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -2333,6 +2333,8 @@ MpInitLibInitialize (
>instant this call is made. This service may only be called from the BSP.
>  
>@param[in]  ProcessorNumber   The handle number of processor.
> +Lower 24 bits contains the actual 
> processor number.
> +BIT24 indicates if the 
> EXTENDED_PROCESSOR_INFORMATION will be retrived.
>@param[out] ProcessorInfoBuffer   A pointer to the buffer where 
> information for
>  the requested processor is deposited.
>@param[out]  HealthDataReturn processor health data.
> diff --git a/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c 
> b/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
> index 86f9fbf903..3af4911d4b 100644
> --- a/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
> +++ b/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
> @@ -77,6 +77,8 @@ MpInitLibGetNumberOfProcessors (
>instant this call is made. This service may only be called from the BSP.
>  
>@param[in]  ProcessorNumber   The handle number of processor.
> +Lower 24 bits contains the actual 
> processor number.
> +BIT24 indicates if the 
> EXTENDED_PROCESSOR_INFORMATION will be retrived.
>@param[out] ProcessorInfoBuffer   A pointer to the buffer where 
> information for
>  the requested processor is deposited.
>@param[out] HealthDataReturn processor health data.
> @@ -115,6 +117,16 @@ MpInitLibGetProcessorInfo (
>ProcessorInfoBuffer->Location.Package = 0;
>ProcessorInfoBuffer->Location.Core= 0;
>ProcessorInfoBuffer->Location.Thread  = 0;
> +
> +  if ((ProcessorNumber & CPU_V2_EXTENDED_TOPOLOGY) != 0) {
> +ProcessorInfoBuffer->ExtendedInformation.Location2.Package = 0;
> +ProcessorInfoBuffer->ExtendedInformation.Location2.Die = 0;
> +ProcessorInfoBuffer->ExtendedInformation.Location2.Tile= 0;
> +ProcessorInfoBuffer->ExtendedInformation.Location2.Module  = 0;
> +ProcessorInfoBuffer->ExtendedInformation.Location2.Core= 0;
> +ProcessorInfoBuffer->ExtendedInformation.Location2.Thread  = 0;
> +  }
> +
>if (HealthData != NULL) {
>  GuidHob = GetFirstGuidHob ();
>  if (GuidHob != NULL) {

(1) For the UP implementation of MpInitLibGetProcessorInfo():

How about, for a *complete* solution (covering both pre-patch and
post-patch functionality):

  ZeroMem (ProcessorInfoBuffer, sizeof *ProcessorInfoBuffer);
  ProcessorInfoBuffer->StatusFlag  = PROCESSOR_AS_BSP_BIT  |
 PROCESSOR_ENABLED_BIT |
 PROCESSOR_HEALTH_STATUS_BIT;

This approach is not slow (most of the time I expect the platform will
have an optimized ZeroMem() implementation), it is frugal with code
(replaces a bunch of manual zeroing of fields), and it is relatively
future-proof (the next time EFI_PROCESSOR_INFORMATION is extended, y

Re: [edk2-devel] [PATCH 2/2] UefiCpuPkg: Check lower 24 bits of ProcessorNumber

[Laszlo Ersek]

On 1/4/24 08:32, duntan wrote:
> Check lower 24 bits of ProcessorNumber instead of
> the value of ProcessorNumber in the API
> MpInitLibGetProcessorInfo() of MpInitLibUp instance.
> Lower 24 bits of ProcessorNumber contains the actual
> processor number.
> The BIT24 of input ProcessorNumber might be set to
> indicate if the EXTENDED_PROCESSOR_INFORMATION will
> be retrived.
> 
> Signed-off-by: Dun Tan 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Min Xu 
> ---
>  UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c 
> b/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
> index 3af4911d4b..b804e400e6 100644
> --- a/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
> +++ b/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
> @@ -106,7 +106,10 @@ MpInitLibGetProcessorInfo (
>  return EFI_INVALID_PARAMETER;
>}
>  
> -  if (ProcessorNumber != 0) {
> +  //
> +  // Lower 24 bits contains the actual processor number.
> +  //
> +  if ((ProcessorNumber & (CPU_V2_EXTENDED_TOPOLOGY - 1)) != 0) {
>  return EFI_NOT_FOUND;
>}
>  

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113178): https://edk2.groups.io/g/devel/message/113178
Mute This Topic: https://groups.io/mt/103518743/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 4/4] OvmfPkg/RiscVVirt: Override Sstc extension

[Laszlo Ersek]

On 1/3/24 14:58, Sunil V L wrote:
> Override Sstc extension and use SBI calls itself by default for RISC-V
> qemu virt platform.
> 
> Cc: Andrei Warkentin 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Laszlo Ersek 
> Signed-off-by: Sunil V L 
> ---
>  OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc 
> b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> index d3624e899e8d..6bc7c90f31dc 100644
> --- a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> +++ b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> @@ -203,7 +203,7 @@ [PcdsFeatureFlag]
>gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
>  
>  [PcdsFixedAtBuild.common]
> -  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFE
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFC
>gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
>gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
>    gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|0

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113177): https://edk2.groups.io/g/devel/message/113177
Mute This Topic: https://groups.io/mt/103501846/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/4] UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc

[Laszlo Ersek]

On 1/3/24 14:58, Sunil V L wrote:
> Sstc extension allows to program the timer and receive the interrupt
> without using an SBI call. This reduces the latency to generate the timer
> interrupt. So, detect whether Sstc extension is supported and use the
> stimecmp register directly to program the timer interrupt.
> 
> Cc: Gerd Hoffmann 
> Cc: Rahul Kumar 
> Cc: Laszlo Ersek 
> Cc: Ray Ni 
> Cc: Andrei Warkentin 
> Signed-off-by: Sunil V L 
> ---
>  .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf |  1 +
>  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h |  2 ++
>  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 30 +--
>  3 files changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf 
> b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> index aba660186dc0..f2a2cf12caef 100644
> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> @@ -41,6 +41,7 @@ [Sources.RISCV64]
>Timer.c
>  
>  [Pcd]
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride   ## CONSUMES
>gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ## CONSUMES
>  
>  [Protocols]
> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h 
> b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> index 9b3542230cb5..5e5071b3f0b2 100644
> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> @@ -26,6 +26,8 @@
>  //
>  #define DEFAULT_TIMER_TICK_DURATION  10
>  
> +#define RISCV_CPU_FEATURE_SSTC_BITMASK  0x2

(1) Not a bug by any means, but BIT1 might read more idiomatic.

> +
>  extern VOID
>  RiscvSetTimerPeriod (
>UINT32  TimerPeriod
> diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c 
> b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> index 30e48061cd06..4babfb4bfc60 100644
> --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> @@ -44,6 +44,19 @@ STATIC EFI_TIMER_NOTIFY  mTimerNotifyFunction;
>  STATIC UINT64  mTimerPeriod = 0;
>  STATIC UINT64  mLastPeriodStart = 0;
>  
> +/**
> +  Check whether Sstc is enabled in PCD.
> +
> +**/
> +STATIC
> +BOOLEAN
> +RiscVIsSstcEnabled (
> +  VOID
> +  )
> +{
> +  return ((PcdGet64 (PcdRiscVFeatureOverride) & 
> RISCV_CPU_FEATURE_SSTC_BITMASK) != 0);
> +}
> +
>  /**
>Timer Interrupt Handler.
>  
> @@ -94,7 +107,12 @@ TimerInterruptHandler (
>   ),
> 100u
> );  // convert to tick
> -  SbiSetTimer (PeriodStart);
> +  if (RiscVIsSstcEnabled ()) {

(2) Even though the PCD is currently declared as fixed or
patchable-in-module, seeing a PcdGet64() call on the call stack of the
timer interrupt handler (and at a high TPL) makes me uncomfortable. It
carries a risk that later on we relax the PCD decl to dynamic, and then
this code would become brittle.

I propose: either replace the PcdGet64 call above with FixedPcdGet64 (so
it can never land in the runtime / dynamic PCD protocol), or perform the
PCD check in the entry point function of the driver, and store the
result in a STATIC BOOLEAN variable. Then further PCD accesses (dynamic
or otherwise) will not be needed.

> +RiscVSetSupervisorTimeCompareRegister (PeriodStart);
> +  } else {
> +SbiSetTimer (PeriodStart);
> +  }
> +
>RiscVEnableTimerInterrupt (); // enable SMode timer int
>gBS->RestoreTPL (OriginalTPL);
>  }
> @@ -197,7 +215,11 @@ TimerDriverSetTimerPeriod (
>   ),
> 100u
> ); // convert to tick
> -  SbiSetTimer (PeriodStart);
> +  if (RiscVIsSstcEnabled ()) {
> +RiscVSetSupervisorTimeCompareRegister (PeriodStart);
> +  } else {
> +SbiSetTimer (PeriodStart);
> +  }
>  
>mCpu->EnableInterrupt (mCpu);
>RiscVEnableTimerInterrupt (); // enable SMode timer int

(3) This seems like duplicated code. How about replacing the
RiscVIsSstcEnabled() function with a more substantive function that
incorporates both the feature check *and* the "PeriodStart" setting?
Then you can easily call that function from both TimerInterruptHandler()
and TimerDriverSetTimerPeriod().

> @@ -282,6 +304,10 @@ TimerDriverInitialize (
>//
>mTimerNotifyFunction = NULL;
>  
> +  if (RiscVIsSstcEnabled ()) {
> +DEBUG ((DEBUG_INFO, "%a: Timer interrupt is via Sstc extension\n", 
> __func__));
> +  }
> +

Right, this would be the place to fetch the PCD explicitly and to store
the result (based on bit-masking) into the global boolean.

>//
>// Make sure the Timer Architectural Protocol is not already installed in 
>

Re: [edk2-devel] [PATCH 4/4] OvmfPkg/RiscVVirt: Override Sstc extension

[Laszlo Ersek]

On 1/3/24 14:58, Sunil V L wrote:
> Override Sstc extension and use SBI calls itself by default for RISC-V
> qemu virt platform.
> 
> Cc: Andrei Warkentin 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Laszlo Ersek 
> Signed-off-by: Sunil V L 
> ---
>  OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc 
> b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> index d3624e899e8d..6bc7c90f31dc 100644
> --- a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> +++ b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> @@ -203,7 +203,7 @@ [PcdsFeatureFlag]
>gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
>  
>  [PcdsFixedAtBuild.common]
> -  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFE
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFC
>gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
>gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
>    gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|0

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113175): https://edk2.groups.io/g/devel/message/113175
Mute This Topic: https://groups.io/mt/103501846/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 1/1] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 1/3/24 16:11, Gerd Hoffmann wrote:
>   Hi,
> 
>> Second (and worse): the bug. In "OvmfPkg/RiscVVirt/VarStore.fdf.inc", it
>> turns out that we *still* generate the gEfiVariableGuid varstore header
>> signature, in case SECURE_BOOT_ENABLE is FALSE. For some reason, commit
>> 92b27c2e6ada ("OvmfPkg/RiscVVirt: Add build files for Qemu Virt
>> platform", 2023-02-16) did not consider commit d92eaabefbe0 ("OvmfPkg:
>> simplify VARIABLE_STORE_HEADER generation", 2016-02-15), and
>> *resurrected* the non-unified varstore generation for RiscVVirt.
>> Furthermore, RiscVVirt uses "VirtNorFlashDxe" as its platform flash
>> driver. As a result, if you now build RiscVVirt with this patch applied,
>> and with SECURE_BOOT_ENABLE=FALSE, I expect the ValidateFvHeader()
>> function to always fail, becase it will try to validate the contents of
>> the varstore through AUTHENTICATED_VARIABLE_HEADER entries, despite the
>> varstore containing (arguably valid) VARIABLE_HEADER entries.
> 
> I expect it will fail only once.  In case the checks don't pass
> VirtNorFlashDxe will re-initialize the flash varstore with
> gEfiAuthenticatedVariableGuid, so on next boot everything is fine.

Good point about reinit, but it might still needlessly cause the loss of
preexistent variables, so if we can avoid it easily, we should.

> 
>> So here's what I propose:
>>
>> - keep this patch, but *prepend* two other patches:
>>
>> - first, reflect commit d92eaabefbe0 to
>> "OvmfPkg/RiscVVirt/VarStore.fdf.inc" -- only generate the authenticated
>> signature GUID, regardless of SECURE_BOOT_ENABLE,
>>
>> - second, in this function, stop accepting the "gEfiVariableGuid"
>> varstore header signature.
> 
> Makes sense.
> 
>>> +if (VarHeaderEnd >= VariableStoreHeader->Size) {
>>> +  DEBUG ((DEBUG_INFO, "%a: end of var list (no space left)\n", 
>>> __func__));
>>> +  break;
>>> +}
>>
>> (4) In case of inequality, the variable header is truncated. Accepting
>> it as "success" looks doubtful.
> 
> We don't know whenever it is supposed to be a valid header, we didn't
> check the StartId yet.
> 
> Reversing the check ordering looks wrong too (looking at header fields
> before we know the header is inside the store).

Oh I certainly don't imply that we should reverse the order of the
checks; I meant to say (a) we should separate

  VarHeaderEnd > VariableStoreHeader->Size

from

  VarHeaderEnd == VariableStoreHeader->Size

and (b) we should perhaps consider the former condition (i.e.,
inequality) as a hard failure (and not as success), i.e., cause for
reformatting the varstore.

> 
>> (5) In case of equality, the variable header fits, but it is followed by
>> no payload at all. I think there are sub-cases to distinguish there:
>>
>> - if the StartId differs from 0x55aa, then we may consider the variable
>> list to be terminated, and break out of the loop (returning success from
>> the function)
>>
>> - if the StartId is 0x55aa, then we need to look further, beause we
>> can't decide yet. For example, if State is VAR_HEADER_VALID_ONLY (0x7f),
>> then it might be fine for the variable header (at the very end of the
>> varstore) *not* to be followed by payload bytes (name, data).
> 
> Not sure this makes sense.  VAR_HEADER_VALID_ONLY is a temporary state,
> while the variable driver writes name and data just after the header,
> to be updated to VAR_ADDED when the write completed successfully.  So
> I'd expect to never find a header without space for name + data.

I have two comments here:

- if you are right, then I agree it's a good argument for keeping the
two conditions

  VarHeaderEnd > VariableStoreHeader->Size
  VarHeaderEnd == VariableStoreHeader->Size

unified as

  VarHeaderEnd >= VariableStoreHeader->Size

*but* then it only strengthens my argument that the *handling* for this
case should not be a "break" statement, but "return EFI_NOT_FOUND"! (And
then the only successful exit from the loop would be for (StartId !=
0x55aa).)

- Do we know for sure that VAR_HEADER_VALID_ONLY is never expected to be
seen? What if the variable update design defines VAR_HEADER_VALID_ONLY
specifically so that the variable driver can recover from a power loss
"in the middle"? In that case, we should not consider
VAR_HEADER_VALID_ONLY reason for reformatting the whole varstore -- in
fact, the swith statement at the end of the patch tolaretes
VAR_HEADER_VALID_ONLY. So I figure, if we accept VAR_HEADER_VALID_ONLY
in that logic, then we should also accept VAR_HEADER_VALID_ONLY if it's
at the very end of the varstore.

> 
>> I find this code hard to review because I don't know (and the Intel
>> whitepaper doesn't seem to tell) precisely how a valid variable list is
>> supposed to be terminated.
> 
> Which is why the code logs the condition why it considers the list to be
> terminated ...

OK!

> 
>> (6) I suggest two further checks (within the braces here):
>>
>> - enforce
>>
>>   VarHeader->NameSize > 0
> 
> NameSize >= 4 ?  (room for one char and the 

Re: [edk2-devel] [PATCH v3 1/1] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 1/3/24 14:09, Laszlo Ersek wrote:
> On 1/3/24 13:56, Laszlo Ersek wrote:
> 
>> (8) Apologies if it was me who suggested ALIGN_VALUE() previously, but
>> this is, in effect, an unchecked addition. I can't off-hand see evidence
>> that it can never overflow (the previous checks don't seem to prevent an
>> overflow here), so I suggest:
>>
>>   //
>>   // the next variable header starts aligned at 4 bytes
>>   //
>>   Status = SafeUintnAdd (VarEnd, (4 - (VarEnd & 4)) & 4, );
>>   if RETURN_ERROR (Status) {
>> DEBUG ((DEBUG_ERROR, "%a: integer overflow\n", __func__));
>> return EFI_NOT_FOUND;
>>   }
> 
> Heh, what I wrote is bogus. Man, binary is hard. :) So, let me try again:
> 
>   Status = SafeUintnAdd (VarEnd, (4 - (VarEnd & 3)) & 3, );
> 
> Ideally, we'd have a SafeIntLib set of APIs for aligning up...

BTW the reason I messed it up was that I'm much more attracted to the
"%" operator, so initially I wrote it as

  Status = SafeUintnAdd (VarEnd, (4 - (VarEnd % 4)) % 4, );

which was correct, but then I thought, from your code, that you probably
liked "&" more (and that "&" might be faster for the CPU...), and then I
"replaced" the "%" operator with "&", but forgot to replace the divisor
4 with the bitmask 3...

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113088): https://edk2.groups.io/g/devel/message/113088
Mute This Topic: https://groups.io/mt/103171811/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 1/1] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 1/3/24 13:56, Laszlo Ersek wrote:

> (8) Apologies if it was me who suggested ALIGN_VALUE() previously, but
> this is, in effect, an unchecked addition. I can't off-hand see evidence
> that it can never overflow (the previous checks don't seem to prevent an
> overflow here), so I suggest:
> 
>   //
>   // the next variable header starts aligned at 4 bytes
>   //
>   Status = SafeUintnAdd (VarEnd, (4 - (VarEnd & 4)) & 4, );
>   if RETURN_ERROR (Status) {
> DEBUG ((DEBUG_ERROR, "%a: integer overflow\n", __func__));
> return EFI_NOT_FOUND;
>   }

Heh, what I wrote is bogus. Man, binary is hard. :) So, let me try again:

  Status = SafeUintnAdd (VarEnd, (4 - (VarEnd & 3)) & 3, );

Ideally, we'd have a SafeIntLib set of APIs for aligning up...

Sorry :)
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113087): https://edk2.groups.io/g/devel/message/113087
Mute This Topic: https://groups.io/mt/103171811/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 1/1] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 12/14/23 16:31, Gerd Hoffmann wrote:
> Extend the ValidateFvHeader function, additionally to the header checks
> walk over the list of variables and sanity check them.
>
> In case we find inconsistencies indicating variable store corruption
> return EFI_NOT_FOUND so the variable store will be re-initialized.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf |   1 +
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c   | 125 +++-
>  2 files changed, 121 insertions(+), 5 deletions(-)
>
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> index 2a3d4a218e61..f549400280a1 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> @@ -34,6 +34,7 @@ [LibraryClasses]
>DxeServicesTableLib
>HobLib
>IoLib
> +  SafeIntLib
>UefiBootServicesTableLib
>UefiDriverEntryPoint
>UefiLib
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> index 5ee98e9b595a..d69bf8783d77 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -185,11 +186,19 @@ ValidateFvHeader (
>IN  NOR_FLASH_INSTANCE  *Instance
>)
>  {
> -  UINT16  Checksum;
> -  EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader;
> -  VARIABLE_STORE_HEADER   *VariableStoreHeader;
> -  UINTN   VariableStoreLength;
> -  UINTN   FvLength;
> +  UINT16 Checksum;
> +  EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> +  VARIABLE_STORE_HEADER  *VariableStoreHeader;
> +  UINTN  VarOffset;
> +  UINTN  VarHeaderEnd;
> +  UINTN  VarNameEnd;
> +  UINTN  VarEnd;
> +  AUTHENTICATED_VARIABLE_HEADER  *VarHeader;

(1) The fact that we try to traverse the variables using
AUTHENTICATED_VARIABLE_HEADER creates a *very slight* inconsistency in
the code.

More precisely, the inconsistency is already there, but this patch makes
it "stronger".

Or even more precisely... this patch in fact introduces a bug, as far as
I can tell, for the RISC-V virt platform firmware.

Here's the details:

In ancient times, authenticated and non-authenticated variable stores
were handled by separate variable drivers. Over time they got unified --
in commit fa0737a839d0 ("MdeModulePkg Variable: Merge from Auth Variable
driver in SecurityPkg", 2015-07-01). The unified driver would then
manage both kinds of varstores.

This got reflected under OvmfPkg in commit d92eaabefbe0 ("OvmfPkg:
simplify VARIABLE_STORE_HEADER generation", 2016-02-15). I recommend
reviewing *that* commit in detail.

ArmVirtPkg's varstore generation was implemented in commit bf57a42a0e2c
("ArmVirtPkg: add FDF definition for empty varstore", 2016-06-23),
duplicating the (simplified, auth-only) varstore header signature from
OvmfPkg.

The upshot was that the OVMF and ArmVirt build processes would only
generate varstores with "gEfiAuthenticatedVariableGuid" in the varstore
header signature.

At the time of commit bf57a42a0e2c ("ArmVirtPkg: add FDF definition for
empty varstore", 2016-06-23), we didn't have VirtNorFlashDxe yet. The
various platform flash drivers back then tolerated (recognized) the
"gEfiVariableGuid" varstore header signature as well. So it's pretty
difficult to say now whether the exclusive generation of the
"gEfiAuthenticatedVariableGuid" signature in OVMF and ArmVirt *should
have been followed* of a restriction of the ValidateFvHeader() functions
in all those drivers -- i.e., whether we should have updated all those
drivers too, to reject "gEfiVariableGuid". After all, the unified
variable driver would just deal with "gEfiVariableGuid" fine, so the
"tolerance" of "gEfiVariableGuid"  in the flash drivers' validation code
was harmless.

But that's not the case anymore, with this patch:

For the variable traversal, we now expect each variable to come with an
AUTHENTICATED_VARIABLE_HEADER.

First, that is inconsistent with our tolerance of "gEfiVariableGuid" in
the varstore header signature. If one part of the code says "OK, this
can validly be 'gEfiVariableGuid'", then the other part of the code
should read the variable headers *as* VARIABLE_HEADER. Or else, in the
opposite direction: if we're only willing to parse the variable list via
AUTHENTICATED_VARIABLE_HEADER, then we should now reject the
"gEfiVariableGuid" header signature *upfront*.

Second (and worse): the bug. In "OvmfPkg/RiscVVirt/VarStore.fdf.inc", it
turns out that we *still* generate the gEfiVariableGuid varstore header
signature, in case SECURE_BOOT_ENABLE is FALSE. For some reason, commit
92b27c2e6ada ("OvmfPkg/RiscVVirt: Add build files for Qemu Virt
platform", 2023-02-16) did not consider 

Re: [edk2-devel] [PATCH v2 1/1] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 12/14/23 16:31, Gerd Hoffmann wrote:
>   Hi,
>  
>> The general idea is, once we don't trust the varstore, there cannot be
>> a *single* unchecked addition in the code. (Unless we can *prove* that
>> overflow is impossible.)
> 
> There are some cases where we add a small, constant number to a value we
> know is smaller than VariableStoreHeader->Size.  I don't see how those
> can overflow, given that varstore flash typically is an order of
> magnitude smaller than MAX_UINT32

OK. Please add comments about these though, possibly expressed as ASSERT()s.

> (unless VariableStoreHeader->Size is
> corrupted, but then we have bigger problems anyway ...).

Right... I had given some thought to that as well. If there's an easy --
albeit perhaps arbitrary -- range check for that up-front, maybe we
should do it. Maybe.

But I'm certainly not asking for armoring existent code in the affected
function. That's too much work -- ridding all existent code of overflows
is just a special case of eliminating technical debt, and there is
enough technical debt in edk2 to spend a lifetime fixing. The only
reasonable approach I can imagine is to stop introducing technical debt,
or *at least* to fix technical debt at a higher rate than adding it.
(This is no small challenge.)

Thanks,
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112545): https://edk2.groups.io/g/devel/message/112545
Mute This Topic: https://groups.io/mt/103031342/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 3/6] UefiCpuPkg: Implements SmmCpuSyncLib library instance

[Laszlo Ersek]

On 12/14/23 12:11, Wu, Jiaxin wrote:
> Hi Laszlo,
> 
> Really appreciate your comments! I checked one by one and feedback as below, 
> thank you & Ray again & again for patch refinement
> 
> 
>>
>> (1) If / when you update the documentation in patch#2, please update
>> this one as well.
>>
> 
> Yes, I will do the alignment.
> 
>> (2) Please sort the #include list alphabetically.
>>
>> (The idea is that the [LibraryClasses] section in the INF file should be
>> sorted as well, and then we can easily verify whether those two lists
>> match each other -- modulo , of course.)
>>
> 
> Agree.
> 
>> (3) We can improve this, as follows:
>>
>>   typedef volatile UINT32 SMM_CPU_SYNC_SEMAPHORE;
> 
> Good comment. Agree.
> 
> 
>>
>>   typedef struct {
>> SMM_CPU_SYNC_SEMAPHORE *Counter;
>>   } SMM_CPU_SYNC_SEMAPHORE_GLOBAL;
>>
>>   typedef struct {
>> SMM_CPU_SYNC_SEMAPHORE *Run;
>>   } SMM_CPU_SYNC_SEMAPHORE_CPU;
>>
>> Because, while it *indeed* makes some sense to introduce these separate
>> wrapper structures, we should still ensure that the internals are
>> identical. This will come handy later.
>>
> 
> After check with Ray, I convinced we don't need wrapper the "Counter" into 
> the SMM_CPU_SYNC_SEMAPHORE_GLOBAL. He thinks it's overdesigned since 
> currently we only have one GLOBAL semaphore. "Counter" defines in the 
> SMM_CPU_SYNC_CONTEXT directly can also make "Counter" has its own CPU cache 
> lines, and don't need consider the future extension. So, I agree to move 
> Counter into SMM_CPU_SYNC_CONTEXT. What's your opinion?
> 
> But for the *Run*, he is ok to wrap into the structure since it's for each 
> CPU, and it can benefit & simply the coding logic, which can easily help us 
> direct to the different CPU with index and meet the semaphore size alignment 
> requirement.

My actual opinion is that *both* wrapper structures are unnecessary. You
can just embed the Counter pointer into the outer sync structure, and
you can have a Run *array of pointers* in the outer sync structure as well.

However, many people find double indirection confusing, and therefore
wrap one level into thin structures. That's fine with me. It has zero
runtime cost, and if it makes the code more manageable to the submitter,
I don't mind. So, up to you.


> 
>>
>> (4) This is too complicated, in my opinion.
>>
>> (4.1) First of all, please add a *conspicuous* comment to the
>> SMM_CPU_SYNC_CONTEXT here, explaining that the whole idea is to place
>> the Counter and Run semaphores on different CPU cache lines, for good
>> performance. That's the *core* principle of this whole structure --
>> that's why we have an array of pointers to semaphores, rather than an
>> array of semaphores directly.
>>
>> You didn't document that principle, and I had to spend a lot of time
>> deducing that fact from the SmmCpuSyncContextInit() function.
> 
> Sorry about that, I will document for the SMM_CPU_SYNC_CONTEXT definition.
> 
> 
>>
>> (4.2) The structure should go like this:
>>
>> struct SMM_CPU_SYNC_CONTEXT  {
>>   UINTNNumberOfCpus;
>>   VOID *SemBuffer;
>>   UINTNSemBufferPages;
>>   SMM_CPU_SYNC_SEMAPHORE_GLOBALGlobalSem;
>>   SMM_CPU_SYNC_SEMAPHORE_CPU   CpuSem[];
>> };
>>
>> Details:
>>
>> - move NumberOfCpus to the top
>>
>> - change the type of SemBuffer from (UINTN*) to (VOID*)
>>
>> - replace SemBufferSize with SemBufferPages
> 
> Oh? Lazlo, could you explain why it's better to define it as "SemBufferPages" 
> instead of "SemBufferSize" in bytes?

Semantically, there is no difference, or even SemBufferSize is more
flexible. My recommendation is basically a "forward declaration" here:
using "SemBufferPages" will simplify the code later on. Because, you
never need to *remember* the precise byte count. What you need to
*remember* is the page count only. So that way the declaration matches
the usage better, and you can save some code logic later on.

> 
> 
>>
>> - move GlobalSem and CpuSem to the end
>>
>> - We need exactly one SMM_CPU_SYNC_SEMAPHORE_GLOBAL, therefore
>> embed
>> GlobalSem directly as a field (it should not be a pointer)
>>
>> - We can much simplify the code by turning CpuSem into a *flexible array
>> member* (this is a C99 feature that is already widely used in edk2).
>> This is why we move CpuSem to the end (and then we keep GlobalSem
>> nearby, for clarity).
> 
> Agree! The same comment from Ray! Thank you and Ray, both!!!
> 
>>
> 
> Really great comment here:
> 
> Based on my above explanation, I propose to below definition:
> 
> ///
> /// Shall place each semaphore on exclusive cache line for good performance.
> ///
> typedef volatile UINT32 SMM_CPU_SYNC_SEMAPHORE;
> 
> typedef struct {
>   ///
>   /// Used for control each CPU continue run or wait for signal
>   ///
>   SMM_CPU_SYNC_SEMAPHORE*Run;
> } SMM_CPU_SYNC_SEMAPHORE_FOR_EACH_CPU;
> 
> struct SMM_CPU_SYNC_CONTEXT  {
>   ///
>   /// Indicate all CPUs in the 

Re: [edk2-devel] [PATCH V6] DebugLib: Update DEBUG macro used when MDEPKG_NDEBUG is defined

[Laszlo Ersek]

On 12/14/23 10:33, Mike Beaton wrote:
>> Please stop sending patches.
> 
> I believe this version is a clear improvement, with motivation.
> (Certainly, it was meant as such!)
> 
> How am I meant to send improvements or updates in this email-based workflow?

By pacing yourself. Posting two versions of the same patch set on the
same day is usually the highest tolerable posting frequency. Many would
say 1 version/day is the limit (unless there is a pressing security
issue or CI failure etc).

Basically the request is for the submitter to think more, let their
latest version soak for longer locally, before posting it.

BTW I don't think this is specific to email, the same issue exists on
any git forge, except perhaps to a lesser extent. Both channels are
asynchronous, so if you repost or force-push too quickly, you don't give
reviewers a chance to finish (or even *start*) the last version's
review. Well, interrupting them may actually be your intent, but that's
just not how async communication works. Once you posted it, it's out
there, and it's going to take up some consumer cycles for sure, either
way, regardless of what you do later. You can't recall it, you're not in
the same office at the same time.

github *seems* to mitigate this, because the old version more or less
just disappears. But that's actually a bug of git forges, not a feature.
Patch posting history should never be forgotten. Mailing lists get this
right, but that makes misbehavior (= too frequent posting) more
damaging, as the total traffic the receiver will have to wade through
will be higher.

In short: don't experiment, don't thrash. Make every version of your
patch set *count*. Give yourself more time to think about your latest
version *in the background*, before posting it. If you sleep over it,
the next day you might get a new idea, regardless of whether you posted
or didn't yet post that version. So, as long as it hasn't settled, don't
post it. If you realize an issue after posting the latest version,
respond -- just like a reviewer would -- to the problematic patch email,
pointing out the error; but *don't* post a new version just yet (i.e.,
don't create a new version / thread on the list). Your attempt to
"recall" the problematic version is bound to fail.

In short, s/TCP_NODELAY/TCP_CORK/.

Sorry about the sermon -- you asked. :)
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112526): https://edk2.groups.io/g/devel/message/112526
Mute This Topic: https://groups.io/mt/103166935/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-