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

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 th

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

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

Re: [edk2-devel] [PATCH v2 1/1] ShellPkg: Fix typos

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

Re: [edk2-devel] [PATCH v2 3/3] UefiCpuPkg/PiSmmCpuDxeSmm: Use processor extended information

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 p

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

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

Re: [edk2-devel] [PATCH 0/3] Maintainers.txt: add Laszlo Ersek as an ArmVirt, Ovmf, UefiCpu Pkg "M"

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

Re: [edk2-devel] [PATCH] Maintainers.txt: add Aaron Young as MptScsi and PvScsi reviewer

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 messag

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

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

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

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. &

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 b

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

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/ArmVi

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

AttrProtocol", >> &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.

Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

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,

Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

ng 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 wr

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

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

Re: [edk2-devel] [PATCH v3 11/39] UefiCpuPkg: Add LoongArch64 CPU Timer library

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.tianoc

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

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 Kv

Re: [edk2-devel] [Patch V4 0/3] UefiCpuPkg/MpInitLib: Eliminate redundant microcode loading in DXE.

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

Re: [edk2-devel] [PATCH v7 1/5] UefiCpuPkg: Add macro definitions for CET feature for NASM files.

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

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

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

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

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 conditio

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

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

Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

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 st

Re: [edk2-devel] [PATCH 0/4] Add DEBUG_MANAGEABILITY to debug level comments

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 bl

Re: [edk2-devel] [Patch V3 0/6] Create and consume a new gMpInformationHobGuid2 in UefiCpuPkg.

t 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

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

s 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-b

Re: [edk2-devel] [PATCH] DebugLib: Allow -Wunneeded-internal-declaration with clang

~ > /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 -=-=-=-=

Re: [edk2-devel] [PATCH] DebugLib: Allow -Wunneeded-internal-declaration with clang

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

Re: [edk2-devel] [PATCH] DebugLib: Allow -Wunneeded-internal-declaration with clang

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

Re: [edk2-devel] [PATCH v3 1/6] UefiCpuPkg/PiSmmCpuDxeSmm: Optimize Semaphore Sync between BSP and AP

OneAp --> 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/Mp

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

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:

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

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 >

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

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

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

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 Hof

Re: [edk2-devel] [PATCH v3 1/1] CloudHv: Add CI for CloudHv on AArch64

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 E

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

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

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

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

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

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 va

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

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

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

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

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

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

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

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 ("OvmfPk

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

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

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

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

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

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

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

cessorNumber 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/MpInitLibU

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 >

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

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

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

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

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

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 la

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

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:

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

icitly 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; >>>} >>>

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

ful. 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

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

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.

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

XTENDED_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 fil

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

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_PROCES

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

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

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

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

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

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 Li

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

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 o

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

ePkgTokenSpaceGuid.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

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

VariableGuid)) > - { > + if (!CompareGuid (&VariableStoreHeader->Signature, > &gEfiAuthenticatedVariableGuid)) { > DEBUG (( >DEBUG_INFO, >"%a: Variable Store Guid non-compatible\n", Reviewed-by: Laszlo Ersek -=-=-=-=-=-=-=-=-=-=

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

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-

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

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: J

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

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 li

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

nues 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&

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

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

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

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_INF

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

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/VirtNorFlashFv

Re: [edk2-devel] [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

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

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 &g

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

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 disab

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

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

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

(+ 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 >

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

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 lib

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

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

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

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

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

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 Hoffm

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

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 docu

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

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 ar

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

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

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

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

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

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 some

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

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 t

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

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

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

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

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

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 -=-=-=-=-=-=-=-=-=-=-=- Grou

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

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 L

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

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/ >> * UefiCpuPk

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

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/VirtNor

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

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

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

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

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

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 Is

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

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.

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

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

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

tility 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 Bieshe

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

t] & (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,

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

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 LocalApi

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

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 a

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

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 NestedI

  1   2   3   4   5   6   7   8   9   10   >