Re: [edk2-devel] [PATCH 00/37] OvmfPkg: remove the CSM (after edk2-stable202311)

[Laszlo Ersek]

On 11/11/23 00:57, Laszlo Ersek wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
> CI: https://github.com/tianocore/edk2/pull/5031 (@ 961d5add9f03)
> 
> Remove the Compatibility Support Module (CSM) from OVMF (after
> edk2-stable202311).
> 
> Modify the following platforms:
> 
>   OvmfPkg/AmdSev/AmdSevX64.dsc
>   OvmfPkg/Bhyve/BhyveX64.dsc
>   OvmfPkg/CloudHv/CloudHvX64.dsc
>   OvmfPkg/IntelTdx/IntelTdxX64.dsc
>   OvmfPkg/Microvm/MicrovmX64.dsc
>   OvmfPkg/OvmfPkgIa32.dsc
>   OvmfPkg/OvmfPkgIa32X64.dsc
>   OvmfPkg/OvmfPkgX64.dsc
>   OvmfPkg/OvmfXen.dsc
> 
> Each of those platforms builds at every stage of the series.
> 
> Follow a gradual approach. Peel off CSM components in (reverse)
> dependency order:
> 
> - exclude a high-level CSM component (library or driver) from the OVMF
>   platforms, without breaking dependencies of low-level components;
> 
> - delete the high-level component from OvmfPkg;
> 
> - add, to a removal queue, any source code artifacts (protocols, GUIDs,
>   headers, PCDs) that the high-level component's deletion
>   *unreferences*;
> 
> - delete all entries of the removal queue (protocols, GUIDs, headers,
>   PCDs) from the edk2 source tree that are now completely unreferenced
>   (... and extend the removal queue recursively, if needed);
> 
> - advance to the next component that now qualifies as "high-level"
>   (because nothing consumes the services it provides any longer), and
>   exclude that one.
> 
> Regression-test the traditional platforms as needed; see the notes in
> the following patches:
> 
> - OvmfPkg: remove PcdCsmEnable
> - OvmfPkg/IncompatiblePciDeviceSupportDxe: ignore CSM presence
> - OvmfPkg: exclude 8254TimerDxe
> 
> Cc: Anatol Belski 
> Cc: Andrei Warkentin 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Corvin Köhne 
> Cc: Erdem Aktas 
> Cc: Gerd Hoffmann 
> Cc: Jianyong Wu 
> Cc: Jiewen Yao 
> Cc: Michael Roth 
> Cc: Min Xu 
> Cc: Rebecca Cran 
> Cc: Sunil V L 
> Cc: Tom Lendacky 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (37):
>   OvmfPkg: cripple CSM_ENABLE macro
>   OvmfPkg: remove PcdCsmEnable
>   OvmfPkg: unplug LegacyBootManagerLib from BdsDxe and UiApp
>   OvmfPkg: remove LegacyBootManagerLib
>   OvmfPkg: unplug LegacyBootMaintUiLib from UiApp
>   OvmfPkg: remove LegacyBootMaintUiLib
>   OvmfPkg: remove gEfiLegacyDevOrderVariableGuid
>   OvmfPkg: exclude the CSM-based VideoDxe driver
>   OvmfPkg: remove Csm/BiosThunk/VideoDxe
>   OvmfPkg: remove gEfiVgaMiniPortProtocolGuid
>   OvmfPkg: remove Bios Video PCDs
>   OvmfPkg: exclude LegacyBiosDxe
>   OvmfPkg/IncompatiblePciDeviceSupportDxe: ignore CSM presence
>   Revert "OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled"
>   OvmfPkg: remove LegacyBiosDxe
>   OvmfPkg: exclude NullMemoryTestDxe driver
>   OvmfPkg: remove gEfiIsaIoProtocolGuid
>   OvmfPkg: remove gEfiIsaAcpiProtocolGuid
>   OvmfPkg: remove gEfiLegacyBiosGuid
>   OvmfPkg: remove LegacyBiosDxe PCDs
>   OvmfPkg: unplug CsmSupportLib from BdsDxe
>   OvmfPkg: remove CsmSupportLib
>   OvmfPkg: remove gEfiFirmwareVolumeProtocolGuid
>   OvmfPkg: remove gEfiLegacyBiosPlatformProtocolGuid
>   OvmfPkg: remove gEfiLegacyBiosProtocolGuid
>   OvmfPkg: remove gEfiLegacyInterruptProtocolGuid
>   OvmfPkg: remove 
>   OvmfPkg: exclude Csm16.inf / Csm16.bin
>   OvmfPkg: remove Rule.Common.USER_DEFINED.CSM from all FDF files
>   OvmfPkg: remove Csm16
>   OvmfPkg: exclude 8254TimerDxe
>   OvmfPkg: remove 8254TimerDxe
>   OvmfPkg: exclude 8259InterruptControllerDxe
>   OvmfPkg: remove 8259InterruptControllerDxe
>   OvmfPkg: remove gEfiLegacy8259ProtocolGuid
>   OvmfPkg: remove Pcd8259LegacyModeEdgeLevel and Pcd8259LegacyModeMask
>   OvmfPkg: remove CSM_ENABLE build macro
> 
>  OvmfPkg/8254TimerDxe/8254Timer.inf   |   
> 43 -
>  OvmfPkg/8254TimerDxe/Timer.c |  
> 406 ---
>  OvmfPkg/8254TimerDxe/Timer.h |  
> 186 --
>  OvmfPkg/8254TimerDxe/Timer.uni   |   
> 16 -
>  OvmfPkg/8254TimerDxe/TimerExtra.uni  |   
> 14 -
>  OvmfPkg/8259InterruptControllerDxe/8259.c|  
> 622 
>  OvmfPkg/8259InterruptControllerDxe/8259.h|  
> 218 --
>  OvmfPkg/8259InterruptControllerDxe/8259.inf  |   
> 45 -
>  OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni|   
> 16 -
>  OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni  

Re: [edk2-devel] [PATCH v2] OvmfPkg/MemEncryptSevLib: Fix address overflow during PVALIDATE

[Laszlo Ersek]

On 11/20/23 08:55, Gerd Hoffmann wrote:
> On Fri, Nov 17, 2023 at 10:39:13PM +0100, Laszlo Ersek wrote:
>> On 11/17/23 12:42, Gerd Hoffmann wrote:
>>> On Fri, Nov 17, 2023 at 10:16:10AM +0100, Laszlo Ersek wrote:
>>>> (+Liming +Mike)
>>>>
>>>> On 11/16/23 10:01, Gerd Hoffmann wrote:
>>>>> On Wed, Nov 15, 2023 at 11:51:53AM -0600, Michael Roth wrote:
>>>>>> The struct used for GHCB-based page-state change requests uses a 40-bit
>>>>>> bit-field for the GFN, which is shifted by PAGE_SHIFT to generate a
>>>>>> 64-bit address. However, anything beyond 40-bits simply gets shifted off
>>>>>> when doing this, which will cause issues when dealing with 1TB+
>>>>>> addresses. Fix this by casting the 40-bit GFN values to 64-bit ones
>>>>>> prior to shifting it by PAGE_SHIFT.
>>>>>>
>>>>>> Fixes: ade62c18f474 ("OvmfPkg/MemEncryptSevLib: add support to validate 
>>>>>> system RAM")
>>>>>> Signed-off-by: Michael Roth 
>>>>>
>>>>> Reviewed-by: Gerd Hoffmann 
>>>>>
>>>>> take care,
>>>>>   Gerd
>>>>
>>>> Is this hard feature freeze material?
>>>
>>> It is a clear bugfix, so IMHO it qualifies.
>>>
>>>> Also, the patch looks garbled to me on-list (superfluous line breaks).
>>>
>>> Patch applies fine here.  I see mutt breaking the long line, but
>>> that is just the local display rendering, the mail good.
>>
>> Can you check the raw message? I did that and it seems broken.
>> Superfluous newlines. I see *double* CRLFs.
> 
> Hmm, everything looks fine here, and 'git am' accepts the mail without
> problems.  Pushed a branch:
> 
> https://github.com/kraxel/edk2/commits/b4/v2-20231115-michael-roth-ovmfpkg-memencryptsevlib-fix-address-overflow-during-pvalidate

This branch contains whitespace damage. The new lines coming from the
patch are terminated with LF, not CRLF.

(Doesn't matter much, just wanted to clarify that mutt wasn't doing the
right thing on your end. The patch, as posted, does contain multiple
CRLFs, and while mutt seems to mitigate that for you, it overshoots.

Anyway, I'm picking this up now; I've cleaned up the double CRLFs manually.)

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112227): https://edk2.groups.io/g/devel/message/112227
Mute This Topic: https://groups.io/mt/102610323/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] ShellPkg: Fix typos

[Laszlo Ersek]

On 11/13/23 02:01, Gao, Zhichao wrote:
> Reviewed-by: Zhichao Gao 
> 
> Thanks,
> Zhichao

merged as commit fe2abc9b74b9b869e29f0ebc6dfaa54001b53e9b via




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112228): https://edk2.groups.io/g/devel/message/112228
Mute This Topic: https://groups.io/mt/102492744/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/3] UefiCpuPkg/PiSmmCpuDxeSmm: Use processor extended information

[Laszlo Ersek]

On 11/20/23 13:42, Wu, Jiaxin wrote:
> For core id in cpu features library, I agree it should be not easy or
> simple change to 0x1f.
> 
>  
> 
> But in SMM CPU, there is no usage case depends on the number of cores
> retrieved from cupid 0x0b return value, only PackageId will be used. So,
> this patch doesn’t do bad things, should no regression issue. I agree
> with Ray’s explanation that  “CPUID.0B.PackageId == CPUID.1F.PackageId”,
> thus no need update for the PackageId update.
> 
>  
> 
> I checked the latest SDM:
> 
>  
> 
> “The sub-leaves of CPUID leaf 0BH describe an ordered hierarchy of
> logical processors starting from the smallest-scoped domain of a Logical
> Processor (sub-leaf index 0) to the Core domain (sub-leaf index 1) to
> the largest-scoped domain (the last valid sub-leaf index) **that is
> implicitly subordinate to the unenumerated highest-scoped domain of the
> processor package (socket)**”
> 
>  
> 
> Looks it already updated to indicate the largest-scoped domain is package.
> 
>  
> 
> With all above, I agree to drop this path, but other 2 patches in this
> set should be ok. Thanks Ray help clarify this.

Merged the first two patches in the series as commits
ad0b1cc144b56fcbd8d369eaff6eaf5f3020efe7 and
7eb504060787c9c37d5b3c33f5d65021d553ea3f, via
.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112229): https://edk2.groups.io/g/devel/message/112229
Mute This Topic: https://groups.io/mt/102602853/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] OvmfPkg/MemEncryptSevLib: Fix address overflow during PVALIDATE

[Laszlo Ersek]

On 11/16/23 10:01, Gerd Hoffmann wrote:
> On Wed, Nov 15, 2023 at 11:51:53AM -0600, Michael Roth wrote:
>> The struct used for GHCB-based page-state change requests uses a 40-bit
>> bit-field for the GFN, which is shifted by PAGE_SHIFT to generate a
>> 64-bit address. However, anything beyond 40-bits simply gets shifted off
>> when doing this, which will cause issues when dealing with 1TB+
>> addresses. Fix this by casting the 40-bit GFN values to 64-bit ones
>> prior to shifting it by PAGE_SHIFT.
>>
>> Fixes: ade62c18f474 ("OvmfPkg/MemEncryptSevLib: add support to validate 
>> system RAM")
>> Signed-off-by: Michael Roth 
> 
> Reviewed-by: Gerd Hoffmann 

Merged as commit e8c23d1e27f70dcb2e59010ded6df32374eaa84a, via
.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112230): https://edk2.groups.io/g/devel/message/112230
Mute This Topic: https://groups.io/mt/102610323/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/3] Maintainers.txt: add Laszlo Ersek as an ArmVirt, Ovmf, UefiCpu Pkg "M"

[Laszlo Ersek]

On 11/16/23 22:50, Laszlo Ersek wrote:
> I'm offering to restore a subset of my earlier ArmVirtPkg and OvmfPkg
> maintainer responsibilities.
> 
> I'm both offering and requesting an escalation of my earlier UefiCpuPkg
> role.
> 
> The commit messages contain lists of files and directories that I intend
> to assist with.
> 
> Under ArmVirtPkg, my focus is the ArmVirtQemu platform.
> 
> Under OvmfPkg and UefiCpuPkg, my focus is the traditional three OVMF
> platforms (IA32, IA32X64, X64) and their dependencies; in particular I
> refrain from Confidential Computing technologies. Under OvmfPkg, I may
> also not be the primary reviewer of those nontrivial device drivers and
> libraries that I neither wrote nor reviewed.
> 
> Finally, I'm interested in reviewing patches for most of the edk2 core,
> and patches for the RISC-V architecture; but it's too early to formalize
> those interests even as some "R" lines.
> 
> Cc: Andrew Fish 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Rahul Kumar 
> Cc: Ray Ni 
> Cc: Sami Mujawar 
> 
> Thanks,
> Laszlo
> 
> Laszlo Ersek (3):
>   Maintainers.txt: add Laszlo Ersek as an ArmVirtPkg maintainer
>   Maintainers.txt: add Laszlo Ersek as an OvmfPkg maintainer
>   Maintainers.txt: add Laszlo Ersek as a UefiCpuPkg maintainer
> 
>  Maintainers.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> 
> base-commit: 3db76e6476e493d3cda45b81bba99a645180cf35

Merged as commit range e8c23d1e27f7..ff22700fc0e7, via
<https://github.com/tianocore/edk2/pull/5125>.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112231): https://edk2.groups.io/g/devel/message/112231
Mute This Topic: https://groups.io/mt/102636309/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] Maintainers.txt: add Aaron Young as MptScsi and PvScsi reviewer

[Laszlo Ersek]

On 11/21/23 17:14, Aaron Young via groups.io wrote:
> Thanks Laszlo. Yes, ajyoung-oracle is my github user ID.
> 
> Reviewed-by: Aaron Young 

Merged as commit 2cd9d5f6fa71, via
.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112232): https://edk2.groups.io/g/devel/message/112232
Mute This Topic: https://groups.io/mt/102728630/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] ArmVirt: Allow memory attributes protocol to be disabled on first boot

[Laszlo Ersek]

On 12/7/23 11:06, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> Shim's PE loader uses the EFI memory attributes protocol in a way that
> results in an immediate crash when invoking the loaded image, unless the
> base and size of its executable segment are both aligned to 4k.
> 
> If this is not the case, it will strip the memory allocation of its
> executable permissions, but fail to add them back for the executable
> region, resulting in non-executable code. Unfortunately, the PE loader
> does not even bother invoking the protocol in this case (as it notices
> the misalignment), making it very hard for system firmware to work
> around this by attempting to infer the intent of the caller.
> 
> So let's introduce a QEMU command line option to indicate that the
> protocol should not be exposed at all on the first boot, which is when
> the issue is triggered. (fbaa64.efi is broken but grubaa64.efi boots
> fine)
> 
>   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocolOnFirstBoot,string=y
> 
> Also introduce a fixed boolean PCD that sets the default.
> 
> Cc: Laszlo Ersek 
> Cc: Gerd Hoffmann 
> Cc: Oliver Steffen 
> Cc: Alexander Graf 
> Cc: Oliver Smith-Denny 
> Cc: Taylor Beebe 
> Cc: Peter Jones 
> Cc: Leif Lindholm 
> Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirtPkg.dec|  6 ++
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  7 ++
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 85 
> 
>  3 files changed, 98 insertions(+)
> 
> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
> index 0f2d7873279f..c55978f75c19 100644
> --- a/ArmVirtPkg/ArmVirtPkg.dec
> +++ b/ArmVirtPkg/ArmVirtPkg.dec
> @@ -68,3 +68,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
># Cloud Hypervisor has no other way to pass Rsdp address to the guest 
> except use a PCD.
> 
>#
> 
>gArmVirtTokenSpaceGuid.PcdCloudHvAcpiRsdpBaseAddress|0x0|UINT64|0x0005
> 
> +
> 
> +  ##
> 
> +  # Whether the EFI memory attribus protocol should be uninstalled before
> 
> +  # invoking the OS loader on the first boot. This may be needed to work 
> around
> 
> +  # problematic builds of shim that use the protocol incorrectly.
> 
> +  
> gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocolOnFirstBoot|FALSE|BOOLEAN|0x0006
> 

(1) could be a feature PCD (although it couldn't be patchable-in-module
then, and perhaps we don't consider this a "feature")

(2) typo: "attribus"

(3) for some reason, I see double line breaks.

> diff --git 
> a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index 997eb1a4429f..5d119af6a3b3 100644
> --- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -16,6 +16,7 @@ [Defines]
>MODULE_TYPE= DXE_DRIVER
> 
>VERSION_STRING = 1.0
> 
>LIBRARY_CLASS  = PlatformBootManagerLib|DXE_DRIVER
> 
> +  CONSTRUCTOR= PlatformBootManagerLibConstructor
> 
>  
> 
>  #
> 
>  # The following information is for reference only and not required by the 
> build tools.
> 
> @@ -46,6 +47,7 @@ [LibraryClasses]
>PcdLib
> 
>PlatformBmPrintScLib
> 
>QemuBootOrderLib
> 
> +  QemuFwCfgSimpleParserLib
> 
>QemuLoadImageLib
> 
>ReportStatusCodeLib
> 
>TpmPlatformHierarchyLib
> 
> @@ -55,6 +57,7 @@ [LibraryClasses]
>UefiRuntimeServicesTableLib
> 
>  
> 
>  [FixedPcd]
> 
> +  gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocolOnFirstBoot
> 
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
> 
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
> 
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity
> 
> @@ -73,5 +76,9 @@ [Guids]
>  [Protocols]
> 
>gEfiFirmwareVolume2ProtocolGuid
> 
>gEfiGraphicsOutputProtocolGuid
> 
> +  gEfiMemoryAttributeProtocolGuid
> 
>gEfiPciRootBridgeIoProtocolGuid
> 
>gVirtioDeviceProtocolGuid
> 
> +
> 
> +[Depex]
> 
> +  gEfiVariableArchProtocolGuid
> 

I've made an effort to read through the v1 discussion (exhausting). Some
quetions remain:

(4) Why the change from an explicit call from AfterConsole to a
constructor? Was AfterConsole too late somehow?

I think constructors should be the last resort.

(5) Is the depex really necessary? BDS is s

Re: [edk2-devel] [PATCH v2] ArmVirt: Allow memory attributes protocol to be disabled on first boot

[Laszlo Ersek]

On 12/8/23 15:34, Laszlo Ersek wrote:

> (7) Tying back to my point (4) -- I understand this is a hack anyway,
> but I'm still uncomfortable with platform BDS uninstalling a protocol
> that is owned by / provided by the CPU driver. Feels like a significant
> layering violation.
> 
> Can we modify the CPU driver instead, to listen to a new event group,
> upon which being signaled, the CPU driver would uninstall the protocol
> (and close the listening event)?
> 
> This PlatformBootManagerLib instance would act more or less the same
> (I'd suggest signaling the event group from within AfterConsole, in case
> the PCD default and/or the fw_cfg knob dictated that), but the protocol
> uninstallation would occur in "ArmPkg/Drivers/CpuDxe".
> 
> In more technical terms, the layering violation IMO is that we mess with
> CpuDxe's "mCpuHandle" and "mMemoryAttribute" static variables from
> within BDS. Adding the new event group requires more boiler-plate code
> for sure, but there's a small code-size benefit as well: we'd not have
> to look up either the handle (with LocateHandle) or the protocol
> interface (with HandleProtocol), as CpuDxe inherently knows those
> (mCpuHandle, mMemoryAttribute).

Or maybe avoid modifying PlatformBootManagerLib completely; instead,
move the logic into CpuDxe, into a ready-to-boot event handler?

At that time, variable services should be available to CpuDxe as well
(for the BootOrder UEFI var check).

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112234): https://edk2.groups.io/g/devel/message/112234
Mute This Topic: https://groups.io/mt/103031504/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] Create and consume a new gMpInformationHobGuid2 in UefiCpuPkg.

[Laszlo Ersek]

Hi Dun,

On 12/11/23 04:16, Tan, Dun wrote:
> Hi Laszlo,
> 
> Previously I sent a patch set " Move gMpInformationHobGuid from 
> StandaloneMmPkg to UefiCpuPkg. " and thanks for your review. To solve the 
> issue that the maximum length of one HOB might not be enough when CPU count 
> is 1-2000 or bigger and extend the HOB, we decide to create a new MpInfo2Hob 
> in UefiCpuPkg in this patch set. Do you have any comments about the patch set?
> 
> Thanks, 
> Dun

A few days ago I made an effort to at least identify the newest patch
sets I should "sometime" review on edk2, including those that apparently
superseded older versions. Thus, although not with 100% certainty, I did
deduce the above "change of plan", i.e., that the movement of the
existent info HOB between packages would be superseded by a brand new
HOB. However, all I could do at the time was simply tagging the new
version for review -- and that's where I stand now.

For reference, I have approx. 14+ patch sets tagged for review on
edk2-devel -- these have accumulated due to my 2 weeks long sick leave.
I'm back to work for 4 days this week, but then I'll disappear again
until the end of the year. So, I think I had best declare "email
bankruptcy".

Apologies for blocking you -- I had made some efforts to inform my
co-maintainers of my status meanwhile. So, please don't wait for my
feedback at this time; I might catch up, if I'm lucky, but I probably
won't be able to. So if Ray is pleased with your patches, please go
ahead and merge them.

I might make comments on smaller patches this week; rest assured that
that kind of "preference" is just practicality, not laziness. It feels
hopeless for me to make a serious "dent" in reviewing any larger patch
set this week, so I'll try to spend review effort where it has a
fleeting chance at enabling actual progress.

Best regards,
Laszlo


> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of duntan
> Sent: Friday, December 8, 2023 5:55 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [Patch V3 0/6] Create and consume a new 
> gMpInformationHobGuid2 in UefiCpuPkg.
> 
> In the V3 patch set,
> In patch "UefiCpuPkg: Build MpInfo2HOB in CpuMpPei", the DEBUG message format 
> is modified In patch "UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe", remove 
> unneccesary assert check.
> In patch "UefiCpuPkg: Avoid assuming only one smmbasehob", free allocated 
> buffer when error returning case happen.
> 
> Dun Tan (6):
>   UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkg
>   UefiCpuPkg: Build MpInfo2HOB in CpuMpPei
>   UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe
>   UefiCpuPkg: Add a new field in MpInfo2 HOB
>   UefiCpuPkg: Cache core type in MpInfo2 HOB
>   UefiCpuPkg: Avoid assuming only one smmbasehob
> 
>  UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 146 
> ++
>  UefiCpuPkg/CpuMpPei/CpuMpPei.h   |   6 +-
>  UefiCpuPkg/CpuMpPei/CpuMpPei.inf |   3 ++-
>  UefiCpuPkg/Include/Guid/MpInformation2.h |  58 
> ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 354 
> ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |   2 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |   8 
>  UefiCpuPkg/UefiCpuPkg.dec|   3 +++
>  8 files changed, 513 insertions(+), 67 deletions(-)  create mode 100644 
> UefiCpuPkg/Include/Guid/MpInformation2.h
> 
> --
> 2.31.1.windows.1
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112298): https://edk2.groups.io/g/devel/message/112298
Mute This Topic: https://groups.io/mt/103052268/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] ArmVirt: Allow memory attributes protocol to be disabled on first boot

[Laszlo Ersek]

On 12/8/23 16:34, Ard Biesheuvel wrote:
> On Fri, 8 Dec 2023 at 15:34, Laszlo Ersek  wrote:

>>> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
>>> index 0f2d7873279f..c55978f75c19 100644
>>> --- a/ArmVirtPkg/ArmVirtPkg.dec
>>> +++ b/ArmVirtPkg/ArmVirtPkg.dec
>>> @@ -68,3 +68,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
>>># Cloud Hypervisor has no other way to pass Rsdp address to the guest 
>>> except use a PCD.
>>>
>>>#
>>>
>>>
>>> gArmVirtTokenSpaceGuid.PcdCloudHvAcpiRsdpBaseAddress|0x0|UINT64|0x0005
>>>
>>> +
>>>
>>> +  ##
>>>
>>> +  # Whether the EFI memory attribus protocol should be uninstalled before
>>>
>>> +  # invoking the OS loader on the first boot. This may be needed to work 
>>> around
>>>
>>> +  # problematic builds of shim that use the protocol incorrectly.
>>>
>>> +  
>>> gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocolOnFirstBoot|FALSE|BOOLEAN|0x0006
>>>
>>
>> (1) could be a feature PCD (although it couldn't be patchable-in-module
>> then, and perhaps we don't consider this a "feature")
>>
> 
> Is this a general remark on the similarity between feature PCDs and
> boolean PCDs?

Yes, just a general remark; I generally don't have a surefire handle on
when to use a feature PCD versus a fixed-at-build (and/or
patchable-in-module) BOOLEAN PCD.

>> (4) Why the change from an explicit call from AfterConsole to a
>> constructor? Was AfterConsole too late somehow?
>>
> 
> Yes. Checking for the existence of "BootOrder" needs to occur earlier,
> or it will have been created by the BDS.
> 
>> I think constructors should be the last resort.
>>
> 
> Not disagreeing with that.
> 
>> (5) Is the depex really necessary? BDS is supposed to start when all
>> drivers have been dispatched, and so by that time, all of the UEFI
>> architectural protocols should be available. (BDS will launch UEFI
>> drivers, and all the UEFI drivers have an implicit depex on all the
>> architectural protocols.)
>>
> 
> The BDS arch protocol will be invoked at that point. but the BdsDxe
> itself could be dispatched much earlier, at which point the
> constructor of this library will be invoked.
> 
> And I'll need to include the CPU arch protocol as well here, as this
> is installed at the same time as the EFI memory attributes protocol by
> the CPU dxe driver.

Ah, so the idea is to inject code between the memory attributes
protocol's installation and BdsDxe launching.


>> (7) Tying back to my point (4) -- I understand this is a hack anyway,
>> but I'm still uncomfortable with platform BDS uninstalling a protocol
>> that is owned by / provided by the CPU driver. Feels like a significant
>> layering violation.
>>
> 
> It is.
> 
>> Can we modify the CPU driver instead, to listen to a new event group,
>> upon which being signaled, the CPU driver would uninstall the protocol
>> (and close the listening event)?
>>
>> This PlatformBootManagerLib instance would act more or less the same
>> (I'd suggest signaling the event group from within AfterConsole, in case
>> the PCD default and/or the fw_cfg knob dictated that), but the protocol
>> uninstallation would occur in "ArmPkg/Drivers/CpuDxe".
>>
>> In more technical terms, the layering violation IMO is that we mess with
>> CpuDxe's "mCpuHandle" and "mMemoryAttribute" static variables from
>> within BDS. Adding the new event group requires more boiler-plate code
>> for sure, but there's a small code-size benefit as well: we'd not have
>> to look up either the handle (with LocateHandle) or the protocol
>> interface (with HandleProtocol), as CpuDxe inherently knows those
>> (mCpuHandle, mMemoryAttribute).
>>
> 
> I agree with your analysis here. But I am reluctant to introduce
> elaborate infrastructure across drivers to implement a feature that
> should not exist in the first place.
> 
> As I mentioned a couple of times, I am rather unhappy with the
> complete lack of involvement of the people who created this mess in
> the first place, and what I am after is really a minimal, local hack
> that unblocks the actual end users (people running LIMA on ARM based
> Macs) without creating building blocks that will be used by the distro
> forks to erode the original functionality even further,

Understood. I agree to keep this contained, location-wise.

(I notice Gerd reports downthread though that limiting the protocol's
masking time-wise as well (i.e. to first boot) is not helpful, because
even rhel-9.3 grubaa64 has problems when the protocol is exposed. So a
simpler but broader approach could be better.)

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112300): https://edk2.groups.io/g/devel/message/112300
Mute This Topic: https://groups.io/mt/103031504/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] ArmVirt: Allow memory attributes protocol to be disabled

[Laszlo Ersek]

On 12/11/23 11:55, Gerd Hoffmann wrote:
>> +  //
>> +  // Work around shim's terminally broken use of the EFI memory attributes
>> +  // protocol, by uninstalling it if requested on the QEMU command line.
>> +  //
>> +  // E.g.,
>> +  //   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocol,string=y
>> +  //
>> +  // This is only needed on the first boot, when fbaa64.efi is being 
>> invoked to
>> +  // set the boot order variables. Subsequent boots involving GRUB are not
>> +  // affected.
>> +  //

(1) I think this last paragraph of the comment no longer applies; is
that right? We don't restrict the proto masking to first boot any longer
(i.e., in v3).

>> +  Uninstall = FixedPcdGetBool (PcdUninstallMemAttrProtocol);
>> +  QemuFwCfgParseBool ("opt/org.tianocore/UninstallMemAttrProtocol", 
>> &Uninstall);
>> +  if (Uninstall) {
>> +UninstallEfiMemoryAttributesProtocol ();
>> +  }
> 
> Can we please have a log message here, for both uninstall and
> keep-installed cases?

Good idea!

> 
> Otherwise the patch looks good to me.

With those two updates (assuming I'm right about (1)):

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112301): https://edk2.groups.io/g/devel/message/112301
Mute This Topic: https://groups.io/mt/103106391/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] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

[Laszlo Ersek]

On 12/10/23 11:18, Mike Beaton wrote:
> From: Mike Beaton 
> 
> This warning was already disabled in CLANGDWARF by commit
> d3225577123767fd09c91201d27e9c91663ae132.
> 
> gcc can distinguish between optimised-away variable usage (as  can occur in
> valid debug code) and genuinely unused variables, and only complains about
> the latter. clang cannot, and therefore this warning ends up complaining
> about valid debug code under clang.
> 
> Since EDK-II code is in general going to be compiled by gcc as well as clang
> then disabling this warning in clang does not amount to entirely removing
> potentially valid warnings about genuinely unused variables.
> 
> Signed-off-by: Mike Beaton 
> ---
>  BaseTools/Conf/tools_def.template | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index c34ecfd557..48cf45245f 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -1754,7 +1754,7 @@ DEFINE CLANGPDB_X64_PREFIX   = ENV(CLANG_BIN)
>  DEFINE CLANGPDB_IA32_TARGET  = -target i686-unknown-windows-gnu
>  DEFINE CLANGPDB_X64_TARGET   = -target x86_64-unknown-windows-gnu
>  
> -DEFINE CLANGPDB_WARNING_OVERRIDES= -Wno-parentheses-equality 
> -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
> -Wno-empty-body -Wno-unused-const-variable -Wno-varargs 
> -Wno-unknown-warning-option -Wno-unused-but-set-variable 
> -Wno-unused-const-variable -Wno-unaligned-access 
> -Wno-microsoft-enum-forward-reference
> +DEFINE CLANGPDB_WARNING_OVERRIDES= -Wno-parentheses-equality 
> -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
> -Wno-empty-body -Wno-unused-const-variable -Wno-varargs 
> -Wno-unknown-warning-option -Wno-unused-but-set-variable 
> -Wno-unused-const-variable -Wno-unaligned-access 
> -Wno-unneeded-internal-declaration -Wno-microsoft-enum-forward-reference
>  DEFINE CLANGPDB_ALL_CC_FLAGS = DEF(GCC48_ALL_CC_FLAGS) 
> DEF(CLANGPDB_WARNING_OVERRIDES) -fno-stack-protector -funsigned-char 
> -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
> -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas 
> -Wno-incompatible-library-redeclaration -Wno-null-dereference 
> -mno-implicit-float -mms-bitfields -mno-stack-arg-probe -nostdlib 
> -nostdlibinc -fseh-exceptions
>  
>  ###

AFAICT, CLANGPDB_WARNING_OVERRIDES gets included in
CLANGPDB_ALL_CC_FLAGS, which in turn gets included in all three of
DEBUG, RELEASE and NOOPT build target flags.

The original report was "RELEASE CLANGPDB OVMF currently does not compile".

Can we use "-Wno-unneeded-internal-declaration" with RELEASE builds only?

Thanks,
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112304): https://edk2.groups.io/g/devel/message/112304
Mute This Topic: https://groups.io/mt/103087794/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] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

[Laszlo Ersek]

On 12/11/23 16:18, Mike Beaton wrote:
> I believe this would be logically wrong, as the other versions still
> wouldn't compile if you changed the relevant debug Pcds. (Which are
> logically independent of the compile and link options - e.g. what if for
> some reason you wanted to single step with the Debug Pcds set to
> disabled, in a NOOPT build?)

I don't think that use case exists in practice.

Anyway, my suggestion is based on prior art: I *think* we ask gcc to
whine about unused local variables in RELEASE builds only, too. See
commits 20d00edf21d2 ("BaseTools/GCC: set -Wno-unused-but-set-variables
only on RELEASE builds", 2016-03-25) and 8b6366f87584 ("BaseTools/GCC:
set -Wno-unused-const-variable on RELEASE builds", 2017-09-08).

... TBH I don't understand the current state of
"-Wno-unused-but-set-variables" and "-Wno-unused-const-variable" between
X64 and AARCH64, considering the DEBUG target. Today,
DEBUG_GCC5_AARCH64_CC_FLAGS disables these warnings, but
DEBUG_GCC5_X64_CC_FLAGS doesn't, even though *both* macros specify
-flto. Compare commit 06c8a34cc4bc ("BaseTool/tools_def GCC5: enable
optimization for ARM/AARCH64 DEBUG builds", 2017-12-08) -- I don't
understand why "-flto" had to be accompanied by
"-Wno-unused-but-set-variable -Wno-unused-const-variable" in that commit.

In brief, IA32 and X64 prior art supports my suggestion to shut up the
warning only for RELEASE (for CLANGPDB too), but ARM/AARCH64 prior art
contradicts that proposal. IOW, prior art is inconsistent per se... I
don't understand.

Laszlo

> On Mon, 11 Dec 2023, 15:00 Laszlo Ersek,  <mailto:ler...@redhat.com>> wrote:
> 
> On 12/10/23 11:18, Mike Beaton wrote:
> > From: Mike Beaton mailto:mjsbea...@gmail.com>>
> >
> > This warning was already disabled in CLANGDWARF by commit
> > d3225577123767fd09c91201d27e9c91663ae132.
> >
> > gcc can distinguish between optimised-away variable usage (as  can
> occur in
> > valid debug code) and genuinely unused variables, and only
> complains about
> > the latter. clang cannot, and therefore this warning ends up
> complaining
> > about valid debug code under clang.
> >
> > Since EDK-II code is in general going to be compiled by gcc as
> well as clang
> > then disabling this warning in clang does not amount to entirely
> removing
> > potentially valid warnings about genuinely unused variables.
> >
> > Signed-off-by: Mike Beaton  <mailto:mjsbea...@gmail.com>>
> > ---
> >  BaseTools/Conf/tools_def.template | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> > index c34ecfd557..48cf45245f 100755
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -1754,7 +1754,7 @@ DEFINE CLANGPDB_X64_PREFIX           =
> ENV(CLANG_BIN)
> >  DEFINE CLANGPDB_IA32_TARGET          = -target
> i686-unknown-windows-gnu
> >  DEFINE CLANGPDB_X64_TARGET           = -target
> x86_64-unknown-windows-gnu
> > 
> > -DEFINE CLANGPDB_WARNING_OVERRIDES    = -Wno-parentheses-equality
> -Wno-tautological-compare
> -Wno-tautological-constant-out-of-range-compare -Wno-empty-body
> -Wno-unused-const-variable -Wno-varargs -Wno-unknown-warning-option
> -Wno-unused-but-set-variable -Wno-unused-const-variable
> -Wno-unaligned-access -Wno-microsoft-enum-forward-reference
> > +DEFINE CLANGPDB_WARNING_OVERRIDES    = -Wno-parentheses-equality
> -Wno-tautological-compare
> -Wno-tautological-constant-out-of-range-compare -Wno-empty-body
> -Wno-unused-const-variable -Wno-varargs -Wno-unknown-warning-option
> -Wno-unused-but-set-variable -Wno-unused-const-variable
> -Wno-unaligned-access -Wno-unneeded-internal-declaration
> -Wno-microsoft-enum-forward-reference
> >  DEFINE CLANGPDB_ALL_CC_FLAGS         = DEF(GCC48_ALL_CC_FLAGS)
> DEF(CLANGPDB_WARNING_OVERRIDES) -fno-stack-protector -funsigned-char
> -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang
> -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas
> -Wno-incompatible-library-redeclaration -Wno-null-dereference
> -mno-implicit-float -mms-bitfields -mno-stack-arg-probe -nostdlib
> -nostdlibinc -fseh-exceptions
> > 
> >  ###
> 
> AFAICT, CLANGPDB_WARNING_OVERRIDES gets included in
> CLANGPDB_ALL_CC_FLAGS, which in turn gets included in all th

Re: [edk2-devel] [PATCH v2] CloudHv: Add CI for CloudHv on AArch64

[Laszlo Ersek]

On 11/23/23 04:22, Jianyong Wu wrote:
> Add the long lost CI for CloudHv on AArch64.
> As CloudHv CI works nearly the same way with other VMMs like KvmTool,
> thus we can easily create its CI configuration based on KvmTool.
> 
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Jianyong Wu 
> ---
>  .../PlatformCI/.azurepipelines/Ubuntu-GCC5.yml  | 13 +
>  .../PlatformCI/{KvmToolBuild.py => CloudHvBuild.py} |  4 ++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
>  copy ArmVirtPkg/PlatformCI/{KvmToolBuild.py => CloudHvBuild.py} (89%)
> 
> diff --git a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
> b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> index d1772a65fc..ab8a2db530 100644
> --- a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> +++ b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> @@ -140,6 +140,19 @@ jobs:
>  Build.Target: "RELEASE"
>  Run: false
>  
> +  CLOUDHV_AARCH64_DEBUG:
> +Build.File: "$(package)/PlatformCI/CloudHvBuild.py"
> +Build.Arch: "AARCH64"
> +Build.Flags: ""
> +Build.Target: "DEBUG"
> +Run: false
> +  CLOUDHV_AARCH64_RELEASE:
> +Build.File: "$(package)/PlatformCI/CloudHvBuild.py"
> +Build.Arch: "AARCH64"
> +Build.Flags: ""
> +Build.Target: "RELEASE"
> +Run: false
> +
>  workspace:
>clean: all
>  
> diff --git a/ArmVirtPkg/PlatformCI/KvmToolBuild.py 
> b/ArmVirtPkg/PlatformCI/CloudHvBuild.py
> similarity index 89%
> copy from ArmVirtPkg/PlatformCI/KvmToolBuild.py
> copy to ArmVirtPkg/PlatformCI/CloudHvBuild.py
> index 4d02dba124..06ada39886 100644
> --- a/ArmVirtPkg/PlatformCI/KvmToolBuild.py
> +++ b/ArmVirtPkg/PlatformCI/CloudHvBuild.py
> @@ -19,13 +19,13 @@ class CommonPlatform():
>  for the different parts of stuart
>  '''
>  PackagesSupported = ("ArmVirtPkg",)
> -ArchSupported = ("AARCH64", "ARM")
> +ArchSupported = ("AARCH64")

Right, and this one change is new in version 2 of the patch.

My R-b stands.

I'm picking this up now.

Laszlo

>  TargetsSupported = ("DEBUG", "RELEASE")
>  Scopes = ('armvirt', 'edk2-build')
>  WorkspaceRoot = os.path.realpath(os.path.join(
>  os.path.dirname(os.path.abspath(__file__)), "..", ".."))
>  
> -DscName = os.path.join("ArmVirtPkg", "ArmVirtKvmTool.dsc")
> +DscName = os.path.join("ArmVirtPkg", "ArmVirtCloudHv.dsc")
>  FvQemuArg = "" # ignored
>  
>  import PlatformBuildLib



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112317): https://edk2.groups.io/g/devel/message/112317
Mute This Topic: https://groups.io/mt/102761729/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 11/39] UefiCpuPkg: Add LoongArch64 CPU Timer library

[Laszlo Ersek]

On 11/23/23 12:43, Chao Li wrote:
> On 2023/11/23 00:12, Laszlo Ersek wrote:
>> On 11/17/23 11:00, Chao Li wrote:
>>> Add the LoongArch64 CPU Timer library, using CPUCFG 0x4 and 0x5 for
>>> Stable Counter frequency.
>>>
>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
>>>
>>> Cc: Eric Dong 
>>> Cc: Ray Ni 
>>> Cc: Rahul Kumar 
>>> Cc: Gerd Hoffmann 
>>> Signed-off-by: Chao Li 
>>> ---
>>>  .../BaseLoongArch64CpuTimerLib.inf|  30 +++
>>>  .../BaseLoongArch64CpuTimerLib.uni|  15 ++
>>>  .../BaseLoongArch64CpuTimerLib/CpuTimerLib.c  | 226 ++
>>>  UefiCpuPkg/UefiCpuPkg.dsc |   3 +
>>>  4 files changed, 274 insertions(+)
>>>  create mode 100644 
>>> UefiCpuPkg/Library/BaseLoongArch64CpuTimerLib/BaseLoongArch64CpuTimerLib.inf
>>>  create mode 100644 
>>> UefiCpuPkg/Library/BaseLoongArch64CpuTimerLib/BaseLoongArch64CpuTimerLib.uni
>>>  create mode 100644 
>>> UefiCpuPkg/Library/BaseLoongArch64CpuTimerLib/CpuTimerLib.c
>> (1) sorry about the annoying comment, but the library should be
>> called (preferably) BaseTimerLibLoongArch64Cpu.
>>
>> We're frequently not consistent with the following library instance
>> naming scheme, but in theory anyway, library instances should be
>> named as follows:
>>
>>   
>>
>> Thus, in this case, Base + TimerLib + LoongArch64Cpu.
>>
>> update UNI file name, INF file name, directory name, BASE_NAME and
>> MODULE_UNI_FILE accordingly (if you agree)
>
> There has a SPEC for naming style:
>
> https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/blob/master/4_naming_conventions/42_directory_names.md
>
> Please check 4.2.3 EDKII Library directory, and most directory naming
> follows this SPEC.

I didn't remember (or know about) this part of the coding standards
spec; thanks for the pointer.

It seems like my suggestion matches the second alternative
([]).

Your naming seems to follow the first alternative
([]). OK.

However, that's still not a perfect match. For , you have "Base".
For , you have "LoongArch64". But for , you
have "CpuTimerLib", and that's wrong. We don't have a "CpuTimerLib"
class; instead it's the "TimerLib" class.

The LIBRARY_CLASS define in your INF file also says "TimerLib", so
"CpuTimerLib" is wrong / inconsistent in the lib instance name.
"BaseLoongArch64TimerLib" should be fine. If you want to add "Cpu", I
guess you could add it as [], as a suffix, under the first
naming scheme alternative: "BaseLoongArch64TimerLibCpu".

>> (5) Relatedly: the TimerLib class is declared in "MdePkg.dec". Thus,
>> if you indeed don't need anything from "UefiCpuPkg.dec", I'd suggest
>> moving this library instance under MdePkg.

> It is inappropriate to place this library in MdePkg, because the
> MdePkg doesn't have any CpuTimerLib instance, and this class library
> are HW implementation-related, so it more appropriate to place it in
> UefiCpuPkg.

This ties in with my above comment. The reason for MdePkg not having a
"CpuTimerLib" instance is that there is no such lib class in edk2.

The library class is called "TimerLib". We have multiple instances in
edk2:

$ git grep -l 'LIBRARY_CLASS *= *TimerLib\>' -- '*inf'

  ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
  EmulatorPkg/Library/DxeCoreTimerLib/DxeCoreTimerLib.inf
  EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.inf
  EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.inf
  MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
  MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
  OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
  OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLibBhyve.inf
  OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
  OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
  PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
  PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
  PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.inf
  PcAtChipsetPkg/Library/AcpiTimerLib/StandaloneMmAcpiTimerLib.inf
  UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
  UefiCpuPkg/Library/SecPeiDxeTimerLibUefiCpu/SecPeiDxeTimerLibUefiCpu.inf
  UefiPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf

This "prior art" suggests the new library instance could go in MdePkg or
UefiCpuPkg alike.

That's where my comment about "UefiCpuPkg.dec" dependencies becomes
relevant. Compare:

- MdePkg/Li

Re: [edk2-devel] [PATCH v2] CloudHv: Add CI for CloudHv on AArch64

[Laszlo Ersek]

Hi Jianyong,

On 12/11/23 17:31, Laszlo Ersek wrote:
> On 11/23/23 04:22, Jianyong Wu wrote:
>> Add the long lost CI for CloudHv on AArch64.
>> As CloudHv CI works nearly the same way with other VMMs like KvmTool,
>> thus we can easily create its CI configuration based on KvmTool.
>>
>> Reviewed-by: Laszlo Ersek 
>> Signed-off-by: Jianyong Wu 
>> ---
>>  .../PlatformCI/.azurepipelines/Ubuntu-GCC5.yml  | 13 +
>>  .../PlatformCI/{KvmToolBuild.py => CloudHvBuild.py} |  4 ++--
>>  2 files changed, 15 insertions(+), 2 deletions(-)
>>  copy ArmVirtPkg/PlatformCI/{KvmToolBuild.py => CloudHvBuild.py} (89%)
>>
>> diff --git a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
>> b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
>> index d1772a65fc..ab8a2db530 100644
>> --- a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
>> +++ b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
>> @@ -140,6 +140,19 @@ jobs:
>>  Build.Target: "RELEASE"
>>  Run: false
>>  
>> +  CLOUDHV_AARCH64_DEBUG:
>> +Build.File: "$(package)/PlatformCI/CloudHvBuild.py"
>> +Build.Arch: "AARCH64"
>> +Build.Flags: ""
>> +Build.Target: "DEBUG"
>> +Run: false
>> +  CLOUDHV_AARCH64_RELEASE:
>> +Build.File: "$(package)/PlatformCI/CloudHvBuild.py"
>> +Build.Arch: "AARCH64"
>> +Build.Flags: ""
>> +Build.Target: "RELEASE"
>> +Run: false
>> +
>>  workspace:
>>clean: all
>>  
>> diff --git a/ArmVirtPkg/PlatformCI/KvmToolBuild.py 
>> b/ArmVirtPkg/PlatformCI/CloudHvBuild.py
>> similarity index 89%
>> copy from ArmVirtPkg/PlatformCI/KvmToolBuild.py
>> copy to ArmVirtPkg/PlatformCI/CloudHvBuild.py
>> index 4d02dba124..06ada39886 100644
>> --- a/ArmVirtPkg/PlatformCI/KvmToolBuild.py
>> +++ b/ArmVirtPkg/PlatformCI/CloudHvBuild.py
>> @@ -19,13 +19,13 @@ class CommonPlatform():
>>  for the different parts of stuart
>>  '''
>>  PackagesSupported = ("ArmVirtPkg",)
>> -ArchSupported = ("AARCH64", "ARM")
>> +ArchSupported = ("AARCH64")
> 
> Right, and this one change is new in version 2 of the patch.
> 
> My R-b stands.
> 
> I'm picking this up now.
> 

The CI run failed for this patch when I tried to merge it; can you
please review <https://github.com/tianocore/edk2/pull/5137>?

Thanks,
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112321): https://edk2.groups.io/g/devel/message/112321
Mute This Topic: https://groups.io/mt/102761729/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 0/3] UefiCpuPkg/MpInitLib: Eliminate redundant microcode loading in DXE.

[Laszlo Ersek]

On 11/24/23 04:45, Ni, Ray wrote:
> Reviewed-by: Ray Ni 

Please go ahead with merging this. The patch set has changed so much
since v2 (which I last reviewed) that I can't perform an incremental
review, and I can't review this from zero at the moment.

Thanks
Laszlo

> 
> Thanks,
> Ray
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Yuanhao
>> Xie
>> Sent: Friday, November 24, 2023 10:57 AM
>> To: devel@edk2.groups.io
>> Cc: Xie, Yuanhao 
>> Subject: [edk2-devel] [Patch V4 0/3] UefiCpuPkg/MpInitLib: Eliminate
>> redundant microcode loading in DXE.
>>
>> The DXE stage's Microcode loading process has been eliminated.
>> Store BSP's MTRR setting only when CpuCount>1.
>> Extract Dump Microcode Revision as a function
>>
>> Compare with V3, this version updates the comments,
>> Move GetMicrocodePatchInfoFromHob removal from patch 3 to patch 1
>>
>> on
>> xieyuanh (3):
>>   UefiCpuPkg/MpInitLib: Eliminate redundant microcode loading in DXE.
>>   UefiCpuPkg/MpInitLib: Store MTRRs settings only when  CpuCount>1
>>   UefiCpuPkg/MpInitLib: Extract Dump Microcode Revision as function.
>>
>>  UefiCpuPkg/Library/MpInitLib/Microcode.c | 85
>> +++--
>> 
>>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 81
>> -
>>  UefiCpuPkg/Library/MpInitLib/MpLib.h | 31
>> ++-
>>  3 files changed, 81 insertions(+), 116 deletions(-)
>>
>> --
>> 2.39.1.windows.1
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112325): https://edk2.groups.io/g/devel/message/112325
Mute This Topic: https://groups.io/mt/102775770/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 1/5] UefiCpuPkg: Add macro definitions for CET feature for NASM files.

[Laszlo Ersek]

On 12/7/23 10:01, Sheng Wei wrote:
> Hi Ray,
> I update the copyright year and add your review-by for the 5 patches.
> And here is the PR https://github.com/tianocore/edk2/pull/5109

Why was my Reviewed-by removed from v6 patches #2 through #5?

Those patches didn't change between v6 and v7, except for the copyright
year updates.

It's demotivating that evidence of my review efforts was explicitly
excluded from git commit history, for no good reason (as far as I can tell).

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112326): https://edk2.groups.io/g/devel/message/112326
Mute This Topic: https://groups.io/mt/103009377/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] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 12/7/23 10:44, 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/VirtNorFlashFvb.c | 82 +--
>  1 file changed, 77 insertions(+), 5 deletions(-)
> 
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> index 5ee98e9b595a..1bfb14495abd 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> @@ -185,11 +185,16 @@ 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;
> +  AUTHENTICATED_VARIABLE_HEADER  *VarHeader;
> +  UINTN  VarSize;
> +  CHAR16 *VarName;
> +  CHAR8  *VarState;
> +  UINTN  VariableStoreLength;
> +  UINTN  FvLength;
>  
>FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER *)Instance->RegionBaseAddress;
>  
> @@ -260,6 +265,73 @@ ValidateFvHeader (
>  return EFI_NOT_FOUND;
>}
>  
> +  // check variables

(1) Comment style -- should be preceded and succeeded by otherwise empty // 
lines

> +  DEBUG ((DEBUG_INFO, "%a: checking variables\n", __func__));
> +  VarOffset = sizeof (*VariableStoreHeader);
> +  while (VarOffset + sizeof (*VarHeader) < VariableStoreHeader->Size) {

(2) The addition is not checked for overflow. When it is evaluated for the 
first time, it cannot overflow, but I can't easily find a proof that it cannot 
overflow in further iterations on 32-bit platforms.

(The strict "<" relop in itself seems justified; we always expect *some* data 
after the variable header.)

I suggest rewriting as follows:

  for (;;) {
RETURN_STATUS  Status;
UINTN  VarHeaderEnd;

Status = SafeUintnAdd (VarOffset, sizeof (*VarHeader), &VarHeaderEnd);
if (RETURN_ERROR (Status)) {
  return EFI_NOT_FOUND;
}
if (VarHeaderEnd >= VariableStoreHeader->Size) {
  break;
}

Perhaps even the second check should return EFI_NOT_FOUND, assuming we require 
(StartId != 0x55aa) as the only successful termination condition.

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

(3) Given that we expect that the varstore may be corrupt, this addition can 
definitely overflow on 32-bit platforms (where the additions are performed in 
UINT32). I suggest using SafeUintnAdd() from SafeIntLib again.

> +if (VarOffset + VarSize > VariableStoreHeader->Size) {

(4) This addition should be checked for overflow too.

Alternatively -- given that, from previous checks, here we know for sure that 
VarOffset is strictly smaller than VariableStoreHeader->Size --, the expression 
can be rearranged as follows (by subtracting VarOffset from both sides):

if (VarSize > VariableStoreHeader->Size - VarOffset) {

Mathematically this means the same thing, but the subtraction on the right hand 
side cannot underflow.

> +  DEBUG ((
> +DEBUG_ERROR,
> +"%a: invalid variable size: 0x%x + 0x%x + 0x%x + 0x%x > 0x%x\n",
> +__func__,
> +VarOffset,

(5) VarOffset is of type UINTN, which may be UINT32 or UINT64. %x is not a 
proper format specifier for printing UINT64.

PrintLib offers no format specifier for UINTN, only for UINT32 (%x, %u) and 
UINT64 (%lx / %Lx, %lu / %Lu).

Therefore, the best way to format a UINTN value is:

- convert it to UINT64 explicitly,
- print it with one of the format specifiers matching UINT64.

For example,

  DEBUG ((DEBUG_ERROR, "%Lx\n", (UINT64)VarOffset));

> +sizeof (*VarHeader),

(6) same issue, sizeof evals to a UINTN.

> +VarHeader->NameSize,
> +VarHeader->DataSize,
> +VariableStoreHeader->Size

these are good (all three are UINT32)

> +));
> +  return EFI_NOT_FOUND;
> +}
> +
> +VarName = (VOID *)((UINTN)VariableStoreHeader + VarOffset
> +   + sizeof (*VarHeader));

(7) This seems premature. We should first check that NameSize is (a) nonzero 
and (b) divisible by 2.

> +switch (VarHeader->State) {
> +  case VAR_HE

Re: [edk2-devel] [Patch V2] UefiCpuPkg/PiSmmCpuDxeSmm: SmmCpuRendezvous ensure all Aps in Present.

[Laszlo Ersek]

On 12/6/23 04:35, Wu, Jiaxin wrote:
>> (1) Here's why I don't like this:
>>
>> we already have a function that is supposed to do this, and it is
>> SmmWaitForApArrival().
>>
>> SmmWaitForApArrival() is called in two contexts. One, in BSPHandler().
>> Two, here.
>>
>> Consider the following condition:
>>
>>   (SyncMode == SmmCpuSyncModeTradition) ||
>>   SmmCpuFeaturesNeedConfigureMtrrs ()
>>
>> If this condition evaluates to true, then BSPHandler() calls
>> SmmWaitForApArrival(), and SmmCpuRendezvous() doesn't.
>>
>> (This is what the "else" branch in SmmCpuRendezvous() states, in a
>> comment, too.)
>>
>> And if the condition evaluates to false, then SmmCpuRendezvous() calls
>> SmmWaitForApArrival(), and BSPHandler() doesn't.
>>
>> This patch adds extra waiting logic to *one* of both call sites. And I
>> don't understand why the *other* call site (in BSPHandler()) does not
>> need the exact same logic.
>>
>> In my opinion, this is a sign that SmmWaitForApArrival() isn't "strong
>> enough". It is not doing all of the work.
>>
>> In my opinion, *both* call sites should receive this logic (i.e., ensure
>> that all AP's are "present"), but then in turn, the additional waiting /
>> checking should be pushed down into SmmWaitForApArrival().
>>
>> What's your opinion on that?
> 
> 
> Existing SmmWaitForApArrival() only make sure all Aps enter SMI except SMI 
> blocked & disabled Aps, not consider the "Present" state. I think this is the 
> original implementation purpose. It won't require all Aps must set the 
> Present flag.
> 
> As you also commented there is a later loop for the Present flag:
>   WaitForAllAPs (ApCount)
> 
> Here, i still prefer to keep existing way instead of making 
> SmmWaitForApArrival return until all aps set the Present flag, because that 
> will be duplicate work within SmmWaitForApArrival() & existing  WaitForAllAPs 
> (). We can't delete the WaitForAllAPs for the later sync to make sure all APs 
> to get ready for programming MTRRs. MTRRs programming need all CPUs in the 
> same start line. 
> 
>   WaitForAllAPs() has two purpose:
>1. Make sure all Aps have set the Present.
>2. Get ready for programming MTRRs to make sure cpus in the same start 
> line.
> 
> if so, that will be better as existing logic, it can also save some time for 
> the Present flag check in SmmWaitForApArrival

OK, this argument makes sense to me.

I didn't realize that WaitForAllAPs() -- called by BSPHandler() after
calling SmmWaitForApArrival() -- already *effectively* ensured that the
APs had their Present flag set!

That happens because:

(a) WaitForAllAPs() pends the "Run" semaphore of each AP.

(b) The APHandler() function sets the Present flag *first*.

(c) If

  (SyncMode == SmmCpuSyncModeTradition) ||
  SmmCpuFeaturesNeedConfigureMtrrs ()

is true, then APHandler() posts the "Run" semaphore, *second*.

Therefore, once WaitForAllAPs() has acquired all AP "Run" semaphores,
all AP Present flags must be set.

This is not obvious at all, but it looks correct.

Therefore I agree that your patch does not introduce asymmetry between
SmmCpuRendezvous() and BSPHandler(). Instead, your patch eliminates
asymmetry, because now SmmCpuRendezvous() will wait for the Present
flags of the APs (if the above-quoted condition is false), similarly to
how BSPHandler already does (if the condition is true).


Now, I have not had the time yet to re-review your patch set

  [PATCH v3 0/6] Refine SMM CPU Sync flow and abstract SmmCpuSyncLib

As far as I remember (from v1), that patch set reorganizes exactly these
"Run" semaphore release/acquire patterns.

(3) Can you confirm that your v3 patch set will not invalidate this
discussion? I.e., can you confirm that WaitForAllAPs() will *still*
ensure, via the Run semaphores, that the Present flags will have been set?

(4) Please add the following to the commit message:

---
BSPHandler -> { SmmWaitForApArrival, WaitForAllAPs } already awaits that
the Present flag is set for all APs, namely via the AP Run semaphores.
Therefore this patch ensures symmetry between BSPHandler (when [1] is
true) and SmmCpuRendezvous() (when [1] is false).

[1] (SyncMode == SmmCpuSyncModeTradition) ||
SmmCpuFeaturesNeedConfigureMtrrs ()
---

More comments below:

> 
>>
>> (2) I notice that a similar "busy loop", waiting for Present flags, is
>> in BSPHandler().
>>
>> Do you think we could call CpuPause() in all such "busy loops" (just
>> before the end of the "while" body)? I think that's supposed to improve
>> the system's throughput, considered as a whole. The function's comment
>> says,
>>
>>   Requests CPU to pause for a short period of time. Typically used in MP
>>   systems to prevent memory starvation while waiting for a spin lock.
>>
> 
> Do you mean the below WaitForAllAPs()? There is already has the CpuPause 
> check within WaitForSemaphore().
> 
> //
> // Wait for all APs to get ready for programming MTRRs
> //
> WaitForAllAPs (ApCount);

Yes, that's the

Re: [edk2-devel] [PATCH v2 3/3] UefiCpuPkg/CpuMpPei: Use CpuPageTableLib to set memory attribute.

[Laszlo Ersek]

On 12/1/23 09:42, Ni, Ray wrote:
> Reviewed-by: Ray Ni 

This series seems to have been merged meanwhile -- that's good, because
I could have usefully reviewed only patch#1, and only ACK patches #2 and
#3, due to time constraints.

However... please do report on the list whenever a series is merged! I
started reviewing patch#1, only to find that it was already upstream. I
could have saved that time if I had seen, on the list, a statement of
merging.

So, for the record: commit range
ef3fde64aa78598a4c21556629936fb228390e8c..7e18c9a788e543ab71cdc0485989cf5d00cdccc2.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112347): https://edk2.groups.io/g/devel/message/112347
Mute This Topic: https://groups.io/mt/102889280/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] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

[Laszlo Ersek]

On 12/11/23 18:26, Mike Beaton wrote:
>>> I believe this would be logically wrong, as the other versions still
>>> wouldn't compile if you changed the relevant debug Pcds. (Which are
>>> logically independent of the compile and link options - e.g. what if for
>>> some reason you wanted to single step with the Debug Pcds set to
>>> disabled, in a NOOPT build?)
>>
>> I don't think that use case exists in practice.
>>
>> Anyway, my suggestion is based on prior art: I *think* we ask gcc to
>> whine about unused local variables in RELEASE builds only, too. See
>> commits 20d00edf21d2 ("BaseTools/GCC: set -Wno-unused-but-set-variables
>> only on RELEASE builds", 2016-03-25) and 8b6366f87584 ("BaseTools/GCC:
>> set -Wno-unused-const-variable on RELEASE builds", 2017-09-08).
>>
>> ... TBH I don't understand the current state of
>> "-Wno-unused-but-set-variables" and "-Wno-unused-const-variable" between
>> X64 and AARCH64, considering the DEBUG target. Today,
>> DEBUG_GCC5_AARCH64_CC_FLAGS disables these warnings, but
>> DEBUG_GCC5_X64_CC_FLAGS doesn't, even though *both* macros specify
>> -flto. Compare commit 06c8a34cc4bc ("BaseTool/tools_def GCC5: enable
>> optimization for ARM/AARCH64 DEBUG builds", 2017-12-08) -- I don't
>> understand why "-flto" had to be accompanied by
>> "-Wno-unused-but-set-variable -Wno-unused-const-variable" in that commit.
>>
>> In brief, IA32 and X64 prior art supports my suggestion to shut up the
>> warning only for RELEASE (for CLANGPDB too), but ARM/AARCH64 prior art
>> contradicts that proposal. IOW, prior art is inconsistent per se... I
>> don't understand.
>>
>> Laszlo
> 
> Hunting around further, it is not the Pcds which are causing this to
> be optimised away, but the definition of MDEPKG_NDEBUG.
> 
> A completely different approach, which allows clang to spot that the
> usage has been 'optimised away' and so to not complain (and therefore
> allows us to re-enable the warning in CLANGDWARF as well), is the
> following:
> 
> --- a/MdePkg/Include/Library/DebugLib.h
> +++ b/MdePkg/Include/Library/DebugLib.h
> @@ -426,7 +426,10 @@ UnitTestDebugAssert (
>}\
>  } while (FALSE)
>  #else
> -#define DEBUG(Expression)
> +#define DEBUG(Expression)\
> +if (FALSE) {   \
> +  _DEBUG (Expression); \
> +}
>  #endif
> 
>  /**
> 

But will this not litter the object files with a bunch of format strings
etc?

It feels like, for CLANGPDB (and maybe CLANGDWARF), the RELEASE target
should not define MDEPKG_NDEBUG, but make sure (instead) that
DebugPrintEnabled() evals to FALSE. If PcdDebugPropertyMask is
fixed-at-build, then DebugPrintEnabled() should be possible to evaluate
at compile time; is that right? (At least for clang?)

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112349): https://edk2.groups.io/g/devel/message/112349
Mute This Topic: https://groups.io/mt/103087794/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] Add DEBUG_MANAGEABILITY to debug level comments

[Laszlo Ersek]

On 12/9/23 01:33, Rebecca Cran via groups.io wrote:
> On 12/8/2023 5:19 PM, Rebecca Cran wrote:
>> Add the new DEBUG_MANAGEABILITY debug level to MdePkg.dec and MdePkg.uni.
>>
>> Improve the wording of the description of the DEBUG_MANAGEABILITY
>> level in
>> DebugLib.h.
>>
>> Update the comment block in ArmVirtPkg.dsc.inc with the new list and
>> updated
>> formatting.
> 
> PR: https://github.com/tianocore/edk2/pull/5127

... commenting only because I was CC'd:

Please confirm on the list whenever a series is merged; it saves time
for reviewers.

(This problem should disappear once we move reviews to github.com, but
until then, a short confirmation on-list can prevent wasted time.)

For the record: commit range
5b5481526fc9b89e5f3843d9bb3d6c4f5ce41060..aa2f32cefa567133d94d574672a4479e004211ee.

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112351): https://edk2.groups.io/g/devel/message/112351
Mute This Topic: https://groups.io/mt/103066384/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] Create and consume a new gMpInformationHobGuid2 in UefiCpuPkg.

[Laszlo Ersek]

On 12/12/23 02:20, Tan, Dun wrote:
> Hi Laszlo,
> 
> Thanks for your reply. Sorry that I didn't add you in the reviewer list from 
> the beginning of this patch series review. About the patch review, please 
> take your time. Also take care your body!
> 
> The patch set was reviewed-by Ray last week. So I think we can merge the 
> patch set first. You can ping me if you have any comments about this patch 
> set later.

Right, I think you should just go ahead and merge the series with Ray's
R-b at this time.

Thanks!
Laszlo

> 
> Thanks,
> Dun
> 
> -Original Message-
> From: Laszlo Ersek  
> Sent: Monday, December 11, 2023 9:50 PM
> To: Tan, Dun ; devel@edk2.groups.io
> Cc: Ni, Ray ; Ard Biesheuvel ; Kinney, 
> Michael D ; Gerd Hoffmann 
> Subject: Re: [edk2-devel] [Patch V3 0/6] Create and consume a new 
> gMpInformationHobGuid2 in UefiCpuPkg.
> 
> Hi Dun,
> 
> On 12/11/23 04:16, Tan, Dun wrote:
>> Hi Laszlo,
>>
>> Previously I sent a patch set " Move gMpInformationHobGuid from 
>> StandaloneMmPkg to UefiCpuPkg. " and thanks for your review. To solve the 
>> issue that the maximum length of one HOB might not be enough when CPU count 
>> is 1-2000 or bigger and extend the HOB, we decide to create a new MpInfo2Hob 
>> in UefiCpuPkg in this patch set. Do you have any comments about the patch 
>> set?
>>
>> Thanks,
>> Dun
> 
> A few days ago I made an effort to at least identify the newest patch sets I 
> should "sometime" review on edk2, including those that apparently superseded 
> older versions. Thus, although not with 100% certainty, I did deduce the 
> above "change of plan", i.e., that the movement of the existent info HOB 
> between packages would be superseded by a brand new HOB. However, all I could 
> do at the time was simply tagging the new version for review -- and that's 
> where I stand now.
> 
> For reference, I have approx. 14+ patch sets tagged for review on edk2-devel 
> -- these have accumulated due to my 2 weeks long sick leave.
> I'm back to work for 4 days this week, but then I'll disappear again until 
> the end of the year. So, I think I had best declare "email bankruptcy".
> 
> Apologies for blocking you -- I had made some efforts to inform my 
> co-maintainers of my status meanwhile. So, please don't wait for my feedback 
> at this time; I might catch up, if I'm lucky, but I probably won't be able 
> to. So if Ray is pleased with your patches, please go ahead and merge them.
> 
> I might make comments on smaller patches this week; rest assured that that 
> kind of "preference" is just practicality, not laziness. It feels hopeless 
> for me to make a serious "dent" in reviewing any larger patch set this week, 
> so I'll try to spend review effort where it has a fleeting chance at enabling 
> actual progress.
> 
> Best regards,
> Laszlo
> 
> 
>>
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of duntan
>> Sent: Friday, December 8, 2023 5:55 PM
>> To: devel@edk2.groups.io
>> Subject: [edk2-devel] [Patch V3 0/6] Create and consume a new 
>> gMpInformationHobGuid2 in UefiCpuPkg.
>>
>> In the V3 patch set,
>> In patch "UefiCpuPkg: Build MpInfo2HOB in CpuMpPei", the DEBUG message 
>> format is modified In patch "UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe", 
>> remove unneccesary assert check.
>> In patch "UefiCpuPkg: Avoid assuming only one smmbasehob", free allocated 
>> buffer when error returning case happen.
>>
>> Dun Tan (6):
>>   UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkg
>>   UefiCpuPkg: Build MpInfo2HOB in CpuMpPei
>>   UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe
>>   UefiCpuPkg: Add a new field in MpInfo2 HOB
>>   UefiCpuPkg: Cache core type in MpInfo2 HOB
>>   UefiCpuPkg: Avoid assuming only one smmbasehob
>>
>>  UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 146 
>> ++
>>  UefiCpuPkg/CpuMpPei/CpuMpPei.h   |   6 +-
>>  UefiCpuPkg/CpuMpPei/CpuMpPei.inf |   3 ++-
>>  UefiCpuPkg/Include/Guid/MpInformation2.h |  58 
>> ++
>>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 354 
>> 

Re: [edk2-devel] [PATCH v4] ArmVirt: Allow memory attributes protocol to be disabled

[Laszlo Ersek]

On 12/12/23 11:42, Ard Biesheuvel wrote:
> On Tue, 12 Dec 2023 at 11:08, Gerd Hoffmann  wrote:
>>
>> On Tue, Dec 12, 2023 at 09:36:00AM +0100, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel 
>>>
>>> Shim's PE loader uses the EFI memory attributes protocol in a way that
>>> results in an immediate crash when invoking the loaded image, unless the
>>> base and size of its executable segment are both aligned to 4k.
>>>
>>> If this is not the case, it will strip the memory allocation of its
>>> executable permissions, but fail to add them back for the executable
>>> region, resulting in non-executable code. Unfortunately, the PE loader
>>> does not even bother invoking the protocol in this case (as it notices
>>> the misalignment), making it very hard for system firmware to work
>>> around this by attempting to infer the intent of the caller.
>>>
>>> So let's introduce a QEMU command line option to indicate that the
>>> protocol should not be exposed at all, and a PCD to set the default for
>>> this option when it is omitted.
>>>
>>>   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocol,string=y
>>
>> Tested-by: Gerd Hoffmann 
>> Reviewed-by: Gerd Hoffmann 
>>
> 
> Thanks all - I've queued this up now.
> 

If it hasn't been merged yet, add:

Reviewed-by: Laszlo Ersek 

thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112447): https://edk2.groups.io/g/devel/message/112447
Mute This Topic: https://groups.io/mt/103126734/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] DebugLib: Allow -Wunneeded-internal-declaration with clang

[Laszlo Ersek]

On 12/12/23 11:33, Mike Beaton wrote:
>> This seems redundant to me. Either we set the pragma and the compiler
>> does not care, or we don't, and rely on the fact that the compiler can
>> infer that 'Expression' will never be evaluated at runtime, but won't
>> complain about symbols that are only referenced via 'Expression' and
>> nowhere else.
> 
> I thought so too on initially reading the code, so I tried removing
> the pragmas, and in fact the pragma is to tell the compiler not to
> warn about the contained `(VOID) Expression`, not to fix the actual
> problem warning - which `(VOID) Expression` itself does, once allowed.
> 
> So without the pragmas we get instead errors such as:
> 
> ```
> /home/mjsbeaton/OpenSource/edk2/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c:444:86:
> error: expression result unused; should this cast be to 'void'?
> [-Werror,-Wunused-value]
>   DEBUG ((DEBUG_INFO | DEBUG_LOAD, "Loading DXE CORE at 0x%11p
> EntryPoint=0x%11p\n", (VOID *)(UINTN)DxeCoreAddress,
> FUNCTION_ENTRY_POINT (DxeCoreEntryPoint)));
> 
>   ^ ~
> /home/mjsbeaton/OpenSource/edk2/MdePkg/Include/Library/DebugLib.h:432:16:
> note: expanded from macro 'DEBUG'
> (VOID) Expression; \
>^
> 1 error generated.
> ```
> 

FWIW:

Acked-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112448): https://edk2.groups.io/g/devel/message/112448
Mute This Topic: https://groups.io/mt/103126777/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] DebugLib: Allow -Wunneeded-internal-declaration with clang

[Laszlo Ersek]

On 12/12/23 13:57, Mike Beaton wrote:
>> You failed to mention where you found this patch.
> 
> It's from https://github.com/acidanthera/audk/commit/dcd0a768b0f
> (which actually contains the code described in its commit message, but
> I believe some other code, including this specific part, which got
> squashed in at some point, and I believe is from the committer, not
> the alleged author actually!).
> 
> Would it work to just add that origin commit to the commit message
> (given the licensing, which is the same as EDK-II, ofc), or would you
> prefer/need an additional Signed-off-by:? (Instead?)
> 

I believe one way to approach it would be to (a) amend the patch with

   --author="Marvin Häuser "

and (b) have S-o-b's from both Marvin and you at the end of the commit
message.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112449): https://edk2.groups.io/g/devel/message/112449
Mute This Topic: https://groups.io/mt/103126777/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] DebugLib: Allow -Wunneeded-internal-declaration with clang

[Laszlo Ersek]

On 12/12/23 16:33, Mike Beaton wrote:
> 
> I believe one way to approach it would be to (a) amend the patch with
> 
>    --author="Marvin Häuser  >"
> 
> and (b) have S-o-b's from both Marvin and you at the end of the commit
> message.
> 
> 
> As I say, I think the code in question is actual by Mikhail, despite
> appearances, but I should be able to get one of them to sign it off. Cheers.
> 

apologies, I missed that.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112451): https://edk2.groups.io/g/devel/message/112451
Mute This Topic: https://groups.io/mt/103126777/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/6] UefiCpuPkg/PiSmmCpuDxeSmm: Optimize Semaphore Sync between BSP and AP

[Laszlo Ersek]

On 12/6/23 11:01, Wu, Jiaxin wrote:
> This patch is to define 3 new functions (WaitForBsp & ReleaseBsp &
> ReleaseOneAp) used for the semaphore sync between BSP & AP. With the
> change, BSP and AP Sync flow will be easy understand as below:
> BSP: ReleaseAllAPs or ReleaseOneAp --> AP: WaitForBsp
> BSP: WaitForAllAPs     <-- AP: ReleaseBsp
> 
> Cc: Laszlo Ersek 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Zeng Star 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Jiaxin Wu 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 72 
> ---
>  1 file changed, 58 insertions(+), 14 deletions(-)

Reviewed-by: Laszlo Ersek 




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112454): https://edk2.groups.io/g/devel/message/112454
Mute This Topic: https://groups.io/mt/103010163/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 2/6] UefiCpuPkg: Adds SmmCpuSyncLib library class

[Laszlo Ersek]

On 12/6/23 11:01, Wu, Jiaxin wrote:
> Intel is planning to provide different SMM CPU Sync implementation
> along with some specific registers to improve the SMI performance,
> hence need SmmCpuSyncLib Library for Intel.
> 
> This patch is to:
> 1.Adds SmmCpuSyncLib Library class in UefiCpuPkg.dec.
> 2.Adds SmmCpuSyncLib.h function declaration header file.
> 
> For the new SmmCpuSyncLib, it provides 3 sets of APIs:
> 
> 1. ContextInit/ContextDeinit/ContextReset:
> ContextInit() is called in driver's entrypoint to allocate and
> initialize the SMM CPU Sync context. ContextDeinit() is called in
> driver's unload function to deinitialize SMM CPU Sync context.
> ContextReset() is called before CPU exist SMI, which allows CPU to
> check into the next SMI from this point.
> 
> 2. GetArrivedCpuCount/CheckInCpu/CheckOutCpu/LockDoor:
> When SMI happens, all processors including BSP enter to SMM mode by
> calling CheckInCpu(). The elected BSP calls LockDoor() so that
> CheckInCpu() will return the error code after that. CheckOutCpu() can
> be called in error handling flow for the CPU who calls CheckInCpu()
> earlier. GetArrivedCpuCount() returns the number of checked-in CPUs.
> 
> 3. WaitForAPs/ReleaseOneAp/WaitForBsp/ReleaseBsp
> WaitForAPs() & ReleaseOneAp() are called from BSP to wait the number
> of APs and release one specific AP. WaitForBsp() & ReleaseBsp() are
> called from APs to wait and release BSP. The 4 APIs are used to
> synchronize the running flow among BSP and APs. BSP and AP Sync flow
> can be easy understand as below:
> BSP: ReleaseOneAp  -->  AP: WaitForBsp
> BSP: WaitForAPs<--  AP: ReleaseBsp
> 
> Cc: Laszlo Ersek 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Zeng Star 
> Cc: Gerd Hoffmann 
> Cc: Rahul Kumar 
> Signed-off-by: Jiaxin Wu 
> ---
>  UefiCpuPkg/Include/Library/SmmCpuSyncLib.h | 275 
> +
>  UefiCpuPkg/UefiCpuPkg.dec  |   3 +
>  2 files changed, 278 insertions(+)
>  create mode 100644 UefiCpuPkg/Include/Library/SmmCpuSyncLib.h
> 
> diff --git a/UefiCpuPkg/Include/Library/SmmCpuSyncLib.h 
> b/UefiCpuPkg/Include/Library/SmmCpuSyncLib.h
> new file mode 100644
> index 00..0f9eb3414a
> --- /dev/null
> +++ b/UefiCpuPkg/Include/Library/SmmCpuSyncLib.h
> @@ -0,0 +1,275 @@
> +/** @file
> +  Library that provides SMM CPU Sync related operations.
> +  The lib provides 3 sets of APIs:
> +  1. ContextInit/ContextDeinit/ContextReset:
> +  ContextInit() is called in driver's entrypoint to allocate and initialize 
> the SMM CPU Sync context.
> +  ContextDeinit() is called in driver's unload function to deinitialize the 
> SMM CPU Sync context.
> +  ContextReset() is called before CPU exist SMI, which allows CPU to check 
> into the next SMI from this point.
> +
> +  2. GetArrivedCpuCount/CheckInCpu/CheckOutCpu/LockDoor:
> +  When SMI happens, all processors including BSP enter to SMM mode by 
> calling CheckInCpu().
> +  The elected BSP calls LockDoor() so that CheckInCpu() will return the 
> error code after that.
> +  CheckOutCpu() can be called in error handling flow for the CPU who calls 
> CheckInCpu() earlier.
> +  GetArrivedCpuCount() returns the number of checked-in CPUs.
> +
> +  3. WaitForAPs/ReleaseOneAp/WaitForBsp/ReleaseBsp
> +  WaitForAPs() & ReleaseOneAp() are called from BSP to wait the number of 
> APs and release one specific AP.
> +  WaitForBsp() & ReleaseBsp() are called from APs to wait and release BSP.
> +  The 4 APIs are used to synchronize the running flow among BSP and APs. BSP 
> and AP Sync flow can be
> +  easy understand as below:
> +  BSP: ReleaseOneAp  -->  AP: WaitForBsp
> +  BSP: WaitForAPs<--  AP: ReleaseBsp
> +
> +  Copyright (c) 2023, Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/

Thanks. This documentation (in the commit message and the lib class
header file) seems really good (especially with the formatting updates
suggested by Ray).

(1) I think there is one typo: exist <-> exits.

> +
> +#ifndef SMM_CPU_SYNC_LIB_H_
> +#define SMM_CPU_SYNC_LIB_H_
> +
> +#include 
> +
> +//
> +// Opaque structure for SMM CPU Sync context.
> +//
> +typedef struct SMM_CPU_SYNC_CONTEXT SMM_CPU_SYNC_CONTEXT;
> +
> +/**
> +  Create and initialize the SMM CPU Sync context.
> +
> +  SmmCpuSyncContextInit() function is to allocate and initialize the SMM CPU 
> Sync context.
> +
> +  @param[in]  NumberOfCpus  The number of Logical Processors in the 
> system.
> +  @param[out] SmmCpuSyncCtx Pointer to the new created and 
> initialized SMM CPU Sync context object.
> +   

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

[Laszlo Ersek]

On 12/6/23 11:01, Wu, Jiaxin wrote:
> Implements SmmCpuSyncLib Library instance. The instance refers the
> existing SMM CPU driver (PiSmmCpuDxeSmm) sync implementation
> and behavior:
> 1.Abstract Counter and Run semaphores into SmmCpuSyncCtx.
> 2.Abstract CPU arrival count operation to
> SmmCpuSyncGetArrivedCpuCount(), SmmCpuSyncCheckInCpu(),
> SmmCpuSyncCheckOutCpu(), SmmCpuSyncLockDoor().
> Implementation is aligned with existing SMM CPU driver.
> 3. Abstract SMM CPU Sync flow to:
> BSP: SmmCpuSyncReleaseOneAp  -->  AP: SmmCpuSyncWaitForBsp
> BSP: SmmCpuSyncWaitForAPs<--  AP: SmmCpuSyncReleaseBsp
> Semaphores release & wait during sync flow is same as existing SMM
> CPU driver.
> 4.Same operation to Counter and Run semaphores by leverage the atomic
> compare exchange.
>
> Cc: Laszlo Ersek 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Zeng Star 
> Cc: Gerd Hoffmann 
> Cc: Rahul Kumar 
> Signed-off-by: Jiaxin Wu 
> ---
>  UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.c   | 647 
> +
>  UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.inf |  39 ++
>  UefiCpuPkg/UefiCpuPkg.dsc  |   3 +
>  3 files changed, 689 insertions(+)
>  create mode 100644 UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.c
>  create mode 100644 UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.inf
>
> diff --git a/UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.c 
> b/UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.c
> new file mode 100644
> index 00..3c2835f8de
> --- /dev/null
> +++ b/UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.c
> @@ -0,0 +1,647 @@
> +/** @file
> +  SMM CPU Sync lib implementation.
> +  The lib provides 3 sets of APIs:
> +  1. ContextInit/ContextDeinit/ContextReset:
> +  ContextInit() is called in driver's entrypoint to allocate and initialize 
> the SMM CPU Sync context.
> +  ContextDeinit() is called in driver's unload function to deinitialize the 
> SMM CPU Sync context.
> +  ContextReset() is called before CPU exist SMI, which allows CPU to check 
> into the next SMI from this point.
> +
> +  2. GetArrivedCpuCount/CheckInCpu/CheckOutCpu/LockDoor:
> +  When SMI happens, all processors including BSP enter to SMM mode by 
> calling CheckInCpu().
> +  The elected BSP calls LockDoor() so that CheckInCpu() will return the 
> error code after that.
> +  CheckOutCpu() can be called in error handling flow for the CPU who calls 
> CheckInCpu() earlier.
> +  GetArrivedCpuCount() returns the number of checked-in CPUs.
> +
> +  3. WaitForAPs/ReleaseOneAp/WaitForBsp/ReleaseBsp
> +  WaitForAPs() & ReleaseOneAp() are called from BSP to wait the number of 
> APs and release one specific AP.
> +  WaitForBsp() & ReleaseBsp() are called from APs to wait and release BSP.
> +  The 4 APIs are used to synchronize the running flow among BSP and APs. BSP 
> and AP Sync flow can be
> +  easy understand as below:
> +  BSP: ReleaseOneAp  -->  AP: WaitForBsp
> +  BSP: WaitForAPs<--  AP: ReleaseBsp
> +
> +  Copyright (c) 2023, Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/

(1) If / when you update the documentation in patch#2, please update
this one as well.

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

(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.)

> +
> +typedef struct {
> +  ///
> +  /// Indicate how many CPU entered SMM.
> +  ///
> +  volatile UINT32*Counter;
> +} SMM_CPU_SYNC_SEMAPHORE_GLOBAL;
> +
> +typedef struct {
> +  ///
> +  /// Used for control each CPU continue run or wait for signal
> +  ///
> +  volatile UINT32*Run;
> +} SMM_CPU_SYNC_SEMAPHORE_CPU;

(3) We can improve this, as follows:

  typedef volatile UINT32 SMM_CPU_SYNC_SEMAPHORE;

  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.

> +
> +struct SMM_CPU_SYNC_CONTEXT  {
> +  ///
> +  ///  All global semaphores' pointer in SMM CPU Sync
> +  ///
> +  SMM_CPU_SYNC_SEMAPHORE_GLOBAL*GlobalSem;
> +  ///
> +  ///  All semaphores for each processor in SMM CPU Sync
> +  ///
> +  SMM_CPU_SYNC_SEMAPHORE_CPU 

Re: [edk2-devel] [PATCH v3 2/6] UefiCpuPkg: Adds SmmCpuSyncLib library class

[Laszlo Ersek]

On 12/13/23 05:23, Wu, Jiaxin wrote:
>>
>> Thanks. This documentation (in the commit message and the lib class
>> header file) seems really good (especially with the formatting updates
>> suggested by Ray).
>>
>> (1) I think there is one typo: exist <-> exits.
>>
> 
> agree, I will fix this.
> 
>>> +RETURN_STATUS
>>> +EFIAPI
>>> +SmmCpuSyncContextReset (
>>> +  IN OUT SMM_CPU_SYNC_CONTEXT  *SmmCpuSyncCtx
>>> +  );
>>
>> (2) The file-top documentation says about this API: "ContextReset() is
>> called before CPU exist SMI, which allows CPU to check into the next SMI
>> from this point".
>>
>> It is not clear *which* CPU is supposed to call ContextReset (and the
>> function does not take a CPU index). Can you explain this in the
>> documentation? (Assuming my observation makes sense.)
>>
> 
> For SMM CPU driver, it shall the BSP to call the function since BSP will 
> gather all APs to exit SMM synchronously, it's the role to control the 
> overall SMI execution flow.
> 
> For the API itself, I don't restrict which CPU can do that. It depends on the 
> consumer. So, it's not the mandatory, that's the reason I don't mention that.
> 
> But you are right, here, it has a requirement: the elected CPU calling this 
> function need make sure all CPUs are ready to exist SMI. I can clear document 
> this requirement as below:
> 
> "This function is called by one of CPUs after all CPUs are ready to exist 
> SMI, which allows CPU to check into the next SMI from this point."
> 
> Besides, one comment from Ray: we can ASSERT the SmmCpuSyncCtx is not NULL, 
> don't need return status to handle all such case. if so, the RETURN_STATUS is 
> not required.
> 
> So, based on all above, I will update the API as below:
> 
> /**
>   Reset SMM CPU Sync context. SMM CPU Sync context will be reset to the 
> initialized state.
> 
>   This function is called by one of CPUs after all CPUs are ready to exist 
> SMI, which allows CPU to
>   check into the next SMI from this point.
> 
>   If Context is NULL, then ASSERT().
> 
>   @param[in,out]  Context Pointer to the SMM CPU Sync context object to 
> be reset.
> 
> **/
> VOID
> EFIAPI
> SmmCpuSyncContextReset (
>   IN OUT SMM_CPU_SYNC_CONTEXT  *Context
>   );

Looks good, thanks -- except, there is again the same typo: "ready to
exist SMI". Should be "ready to exit".

I also agree that asserting (Context != NULL) is valid, as long as we
document that passing in a non-NULL context is the caller's
responsibility. (And we do that above, so fine.)

> 
> 
>>> +RETURN_STATUS
>>> +EFIAPI
>>> +SmmCpuSyncGetArrivedCpuCount (
>>> +  IN SMM_CPU_SYNC_CONTEXT  *SmmCpuSyncCtx,
>>> +  IN OUT UINTN *CpuCount
>>> +  );
>>
>> (3) Why is CpuCount IN OUT? I would think just OUT should suffice.
>>
>>
> 
> Agree. I will correct all similar case. Besides, I also received the comments 
> from Ray offline:
> 1. we can ASSERT the SmmCpuSyncCtx is not NULL, don't need return status to 
> handle that.
> 2. we don't need RETURN_UNSUPPORTED,  GetArrivedCpuCount() should be always 
> supported.
> With above comments, I will update the API as below to return the count 
> directly, this is also aligned with the function name to get arrived CPU 
> Count:
> 
> /**
>   Get current number of arrived CPU in SMI.
> 
>   BSP might need to know the current number of arrived CPU in SMI to make 
> sure all APs
>   in SMI. This API can be for that purpose.
> 
>   If Context is NULL, then ASSERT().
> 
>   @param[in]  Context Pointer to the SMM CPU Sync context object.
> 
>   @retvalCurrent number of arrived CPU in SMI.
> 
> **/
> UINTN
> EFIAPI
> SmmCpuSyncGetArrivedCpuCount (
>   IN  SMM_CPU_SYNC_CONTEXT  *Context
>   );

Sure, if you can guarantee at the lib *class* level that this API always
succeeds as long as Context is not NULL, then this update looks fine.

> 
>  
>>> +RETURN_STATUS
>>> +EFIAPI
>>> +SmmCpuSyncCheckInCpu (
>>> +  IN OUT SMM_CPU_SYNC_CONTEXT  *SmmCpuSyncCtx,
>>> +  IN UINTN CpuIndex
>>> +  );
>>
>> (4) Do we need an error condition for CpuIndex being out of range?
>>
> 
> Good idea. We can handle this check within ASSERT. Then I will update all 
> similar case by adding below comments in API:
> 
> "If CpuIndex exceeds the range of all CPUs in the system, then ASSERT()."
> 
> For example:
> /**
>   Performs an atomic operation to check in CPU.
> 
>   When SMI happens, all processors including BSP enter to SMM mode by calling 
> SmmCpuSyncCheckInCpu().
> 
>   If Context is NULL, then ASSERT().
>   If CpuIndex exceeds the range of all CPUs in the system, then ASSERT().
> 
>   @param[in,out]  Context   Pointer to the SMM CPU Sync context 
> object.
>   @param[in]  CpuIndex  Check in CPU index.
> 
>   @retval RETURN_SUCCESSCheck in CPU (CpuIndex) successfully.
>   @retval RETURN_ABORTEDCheck in CPU failed due to 
> SmmCpuSyncLockDoor() has been called by one elected CPU.
> 
> **/
> RETURN_STATUS
> EFIAPI
> SmmCpuSyncCh

Re: [edk2-devel] [PATCH v3 4/6] OvmfPkg: Specifies SmmCpuSyncLib instance

[Laszlo Ersek]

On 12/6/23 11:01, Wu, Jiaxin wrote:
> This patch is to specify SmmCpuSyncLib instance for OvmfPkg.
> 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Zeng Star 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Jiaxin Wu 
> ---
>  OvmfPkg/CloudHv/CloudHvX64.dsc | 2 ++
>  OvmfPkg/OvmfPkgIa32.dsc| 2 ++
>  OvmfPkg/OvmfPkgIa32X64.dsc | 2 ++
>  OvmfPkg/OvmfPkgX64.dsc | 1 +
>  4 files changed, 7 insertions(+)
> 
> diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
> index 821ad1b9fa..f735b69a37 100644
> --- a/OvmfPkg/CloudHv/CloudHvX64.dsc
> +++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
> @@ -183,10 +183,12 @@
>PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
>DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
>
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
>  !if $(SMM_REQUIRE) == FALSE
>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
> +!else
> +  SmmCpuSyncLib|UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.inf
>  !endif
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>
> MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf
>  
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index bce2aedcd7..b05b13b18c 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -188,10 +188,12 @@
>PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
>DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
>
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
>  !if $(SMM_REQUIRE) == FALSE
>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
> +!else
> +  SmmCpuSyncLib|UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.inf
>  !endif
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>  
>  !if $(SOURCE_DEBUG_ENABLE) == TRUE
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 631e909a54..5a16eb7abe 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -193,10 +193,12 @@
>PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
>DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
>
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
>  !if $(SMM_REQUIRE) == FALSE
>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
> +!else
> +  SmmCpuSyncLib|UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.inf
>  !endif
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>  
>  !if $(SOURCE_DEBUG_ENABLE) == TRUE
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 4ea3008cc6..6bb4c777b9 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -209,10 +209,11 @@
>  !if $(SMM_REQUIRE) == FALSE
>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
>CcProbeLib|OvmfPkg/Library/CcProbeLib/DxeCcProbeLib.inf
>  !else
>CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
> +  SmmCpuSyncLib|UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.inf
>  !endif
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>  
>  !if $(SOURCE_DEBUG_ENABLE) == TRUE

All four DSC files already include "PiSmmCpuDxeSmm.inf" like this:

  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {

  ...
  }

Given that this new library class is again exclusively used by
PiSmmCpuDxeSmm, can you please resolve this lib class too in module
scope only?

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112487): https://edk2.groups.io/g/devel/message/112487
Mute This Topic: https://groups.io/mt/103010166/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] CloudHv: Add CI for CloudHv on AArch64

[Laszlo Ersek]

On 12/13/23 16:13, Sami Mujawar wrote:
> From: Jianyong Wu 
> 
> Add the long lost CI for CloudHv on AArch64.
> As CloudHv CI works nearly the same way with other VMMs like KvmTool,
> thus we can easily create its CI configuration based on KvmTool.
> 
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Jianyong Wu 
> Signed-off-by: Sami Mujawar 
> ---
> 
> The changes can be seen at: 
> https://github.com/samimujawar/edk2/tree/2897_cloudhv_ci_v3
> 
> Notes:
> v3:
>  - CI fails to build when merging this patch[Laszlo]
>Ref: https://edk2.groups.io/g/devel/message/112321
>  - Added missing comma in supported architecture lists  [Sami]
>in CloudHvBuild.py to fix the issue.

Huh, singleton tuple!

https://docs.python.org/3/library/stdtypes.html#tuple

"Using a trailing comma for a singleton tuple: a, or (a,)"

I guess that broke with the ArchSupported update from v1 to v2:

-ArchSupported = ("AARCH64", "ARM")
+ArchSupported = ("AARCH64")

Sami, you have push right; can you merge this?

Thanks!
Laszlo

> 
>  ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 13 
>  ArmVirtPkg/PlatformCI/CloudHvBuild.py | 32 
> 
>  2 files changed, 45 insertions(+)
> 
> diff --git a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
> b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> index 
> d1772a65fc3a84f7f981971ff4ed6c37d7ba84f6..ab8a2db53026db686ae4e5943044235c63ab3a80
>  100644
> --- a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> +++ b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> @@ -140,6 +140,19 @@ jobs:
>  Build.Target: "RELEASE"
>  Run: false
>  
> +  CLOUDHV_AARCH64_DEBUG:
> +Build.File: "$(package)/PlatformCI/CloudHvBuild.py"
> +Build.Arch: "AARCH64"
> +Build.Flags: ""
> +Build.Target: "DEBUG"
> +Run: false
> +  CLOUDHV_AARCH64_RELEASE:
> +Build.File: "$(package)/PlatformCI/CloudHvBuild.py"
> +Build.Arch: "AARCH64"
> +Build.Flags: ""
> +Build.Target: "RELEASE"
> +Run: false
> +
>  workspace:
>clean: all
>  
> diff --git a/ArmVirtPkg/PlatformCI/CloudHvBuild.py 
> b/ArmVirtPkg/PlatformCI/CloudHvBuild.py
> new file mode 100644
> index 
> ..5100a56f3be5ad6d2b156352a521900f93d1de27
> --- /dev/null
> +++ b/ArmVirtPkg/PlatformCI/CloudHvBuild.py
> @@ -0,0 +1,32 @@
> +# @file
> +# Script to Build ArmVirtPkg UEFI firmware
> +#
> +# Copyright (c) Microsoft Corporation.
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +##
> +import os
> +import sys
> +
> +sys.path.append(os.path.dirname(os.path.abspath(__file__)))
> +from PlatformBuildLib import SettingsManager
> +from PlatformBuildLib import PlatformBuilder
> +
> +# 
> ###
>  #
> +#Common Configuration
>  #
> +# 
> ###
>  #
> +class CommonPlatform():
> +''' Common settings for this platform.  Define static data here and use
> +for the different parts of stuart
> +'''
> +PackagesSupported = ("ArmVirtPkg",)
> +ArchSupported = ("AARCH64",)
> +TargetsSupported = ("DEBUG", "RELEASE")
> +Scopes = ('armvirt', 'edk2-build')
> +WorkspaceRoot = os.path.realpath(os.path.join(
> +os.path.dirname(os.path.abspath(__file__)), "..", ".."))
> +
> +DscName = os.path.join("ArmVirtPkg", "ArmVirtCloudHv.dsc")
> +FvQemuArg = "" # ignored
> +
> +import PlatformBuildLib
> +PlatformBuildLib.CommonPlatform = CommonPlatform



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112525): https://edk2.groups.io/g/devel/message/112525
Mute This Topic: https://groups.io/mt/103150734/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] 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]
-=-=-=-=-=-=-=-=-=-=-=-

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 syst

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 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 commit

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, &VarOffset);
>   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, &VarOffset);

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 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, &VarOffset);
>>   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, &VarOffset);
> 
> 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, &VarOffset);

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 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 terminatin

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 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 (#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 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 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 (&gEfiSecPlatformInformationPpiGuid);
>  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

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 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 SMod

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 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 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 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 ma

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 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 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 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 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 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
> -  
> PlatformBo

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 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 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 (&VariableStoreHeader->Signature, &gEfiVariableGuid) &&
> -  !CompareGuid (&VariableStoreHeader->Signature, 
> &gEfiAuthenticatedVariableGuid))
> -  {
> +  if (!CompareGuid (&VariableStoreHeader->Signature, 
> &gEfiAuthenticatedVariableGuid)) {
>  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 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), &VarHeaderEnd);
> +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] 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] 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] [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), &VarHeaderEnd);
> +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 +28

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 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] [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] 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] 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, 
> &CurrentMask);
>  
> -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: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] 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 m

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] [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)&mInitialized;
  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]

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 p

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] [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] 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 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: 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 (
> -&gMpInformationHobGuid2,
> +&gMpInformation2HobGuid,
>  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 (&gMpInformationHobGuid2);
> +  FirstMpInfo2Hob = GetFirstGuidHob (&gMpInformation2HobGuid);
>ASSERT (FirstMpInfo2Hob != NULL);
>GuidHob = FirstMpInfo2Hob;
>while (GuidHob != NULL) {
> @@ -792,7 +792,7 @@ GetMpInformation (
>  
>  HobCount++;
>  *NumberOfCpus += MpInformation2HobData->NumberOfProcessors;
> -GuidHob= GetNextGuidHob (&gMpInformationHobGuid2, GET_NEXT_HOB 
> (GuidHob));
> +GuidHob= GetNextGuidHob (&gMpInformation2HobGuid, 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);
&g

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] 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/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] [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] [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 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 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 
> b/OvmfPkg/Library/PlatformBootManagerLi

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 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, a

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 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] 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] 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] 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 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] [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 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 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 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]
-=-=-=-=-=-=-=-=-=-=-=-