On 1/23/24 17:59, Michael Brown wrote:
> On 23/01/2024 16:32, Laszlo Ersek wrote:
>> On 1/23/24 16:31, Michael Brown wrote:
>>> At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
>>> specification) and so we should never encounter a situation in wh
On 1/23/24 17:11, Gerd Hoffmann wrote:
> Hi,
>
> Well, it's OVMF in a virtual machine. No boot guard involved.
> So we could probably go for a OVMF-specific patch here.
>
> But I'd prefer to figure what exactly is happening here before going
> down that route. An extreme
the
declarations of variables and functions for exactly those libraries that
we link against. There are two exceptions (that I can think of at once):
when we only want macros from a lib class header, or when we include a
lib class header because we are implementing an instance for that lib
class (i.e., we're p
SERT (FALSE);
> + }
> +
> + //
> + // If no timer interrupt occurred then this indicates that the timer
> + // interrupt handler failed to rearm the timer before calling
> + // NestedInterruptRestoreTPL(). This would prevent nested
> + // interrupts from occurring at a
logic might as well be "panic" here (except edk2
does not have a central panic API that's suitable for all platforms). I
probably missed the previous discussion that led to this patch. Either
way, it seems reasonable.
Acked-by: Laszlo Ersek
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You r
On 1/22/24 20:04, Rebecca Cran wrote:
> Originally posted at
> https://twitter.com/UEFIForum/status/1745518769232077208
>
> The Multi-ISA Driver Compatibility Survey is at
> https://docs.google.com/forms/d/e/1FAIpQLScXjwaSBgLeqB1coEDxCPxho5JWF3AMqshOTJ2wd6Tf0He4LA/viewform
>
> From that page:
>
On 1/23/24 11:52, Gerd Hoffmann wrote:
> On Mon, Jan 22, 2024 at 01:11:52PM -0600, Brian J. Johnson wrote:
>> On 1/18/24 09:46, Gerd Hoffmann wrote:
>>> On Wed, Jan 10, 2024 at 04:43:47PM +, West, Catharine wrote:
Disabling cache by default results in violation of BTG protections (if BTG
On 1/23/24 12:36, Huang, Qing wrote:
> CpuLib.h exposes StandardSignatureIsAuthenticAMD() API and we require stub
> function in its BaseCpuLibNull library
> instance to avoid potential link issue.
>
> Signed-off-by: Qing Huang
> ---
> MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c | 17
age table.
> Also, add more comment to explain this behavior.
>
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Rahul Kumar
> Cc: Gerd Hoffmann
> Cc: Crystal Lee
> Cc: Pedro Falcato
> Signed-off-by: Zhiguang Liu
> ---
> .../Library/CpuPageTableLib/CpuPageTableMap.c |
st don't like it when a commit
message only consists of a subject line.)
Thanks for considering!
Reviewed-by: Laszlo Ersek
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114141): https://edk2.groups.io/g/devel/message/114141
Mute
med by drivers outside of OvmfPkg.
>
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Gerd Hoffmann
> Cc: Michael D Kinney
> Signed-off-by: Michael Brown
> ---
> MdeModulePkg/MdeModulePkg.dec | 4
> OvmfPkg/OvmfPkg.dec
On 1/19/24 05:43, Nhi Pham wrote:
> On 1/18/2024 9:49 PM, Laszlo Ersek wrote:
>>>>> but I'd prefer to just remove this
>>>>> optimization from standalone MM, given that not only a) it shouldn't
>>>>> have to deal with a large number of protocol GUID
On 1/19/24 05:56, Nhi Pham wrote:
> From: Laszlo Ersek
>
> The current dependency evaluator violates the memory access permission
> when patching depex grammar directly in the read-only depex memory area.
>
> Laszlo pointed out the optimization issue in the thread (1) &
for review.
>
>
>
> Mike, Laszlo, Gerd, Abner, any comments?
I'm also OK with plan A.
Thanks
Laszlo
>
>
>
>
>
> Thanks,
>
> Ray
>
> *From:* Chao Li
> *Sent:* Thursday, January 18, 2024 4:27 PM
> *To:* Ni, Ray ; Sunil V L
> *Cc:* devel@e
On 1/17/24 23:47, Doug Flick via groups.io wrote:
> OVMF is failing because it includes both DxeTpm2MeasureBootLib and
> DxeTpm2MeasureBootLib which makes the symbols collide. This patch
> renames the function names to be unique to avoid symbol collision.
>
> Cc: Jiewen Yao
> Cc: Rahul Kumar
>
On 1/16/24 18:10, Gerd Hoffmann wrote:
> This is a little series containing the flash corruption fix sent
> yesterday with an slightly improved commit message and some small
> improvements on top of this.
>
> v3:
> - fix diagram
> - fix DoErase control flow
> - pick up reviewed-by tags
> v2:
>
On 1/17/24 15:12, Gerd Hoffmann wrote:
>> This patch is good:
>>
>> Reviewed-by: Laszlo Ersek
>>
>> but the series shouldn't stop here. In "OvmfPkg/Tcg/Tcg2Config", we're
>> left with an INF file (Tcg2ConfigPei.inf) that still references
>
On 1/18/24 07:00, Nhi Pham wrote:
> Hi Laszlo,
>
> On 1/16/2024 2:00 AM, Laszlo Ersek wrote:
>> On 1/15/24 15:04, Ard Biesheuvel wrote:
>>> On Mon, 15 Jan 2024 at 14:07, Nhi Pham
>>> wrote:
>>>>
>>>> On 1/12/2024 4:45 PM, Laszlo Ersek
ly platform/drivers need to have
> better guard for such functionality.
>
> Signed-off-by: Dhaval Sharma
> Cc: Liming Gao
> Cc: Michael D Kinney
> Cc: Zhiguang Liu
> Cc: Sunil V L
> Cc: Andrei Warkentin
> Cc: Laszlo Ersek
> Cc: Pedro Falcato
> Cc: Yang Cheng
>
leLibMapInLevel, the function assume page
> table is not changed, and add ASSERT to check. But hardware may change
> the page table, which cause the ASSERT happens.
> Fix the issue by considering the hardware may also change page table,
> and document the detail in function header.
>
> Cc:
. Also, because ConvertMemoryPageToNotPresent in called in a
> loop, to improve performance, there is no need to flush TLB
> inside ConvertMemoryPageToNotPresent. Just flushing TLB after the loop
> is enough.
>
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Rahul Kumar
> Cc: Gerd
On 1/17/24 07:21, Zhiguang Liu wrote:
> PageTableMap() only modifies the PageTable root pointer when creating from
> zero.
> Explicitly explain it in function header.
>
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Rahul Kumar
> Cc: Gerd Hoffmann
> Signed-off-by: Zhigua
device back into Read Array mode
> + SEND_NOR_COMMAND (Instance->DeviceBaseAddress, 0, P30_CMD_READ_ARRAY);
>
> - // Put the data at the appropriate location inside the buffer area
> - CopyMem ((VOID *)((UINTN)Instance->ShadowBuffer + Offset), Buffer,
> *NumBytes);
> -
&
> -
> - @retval EFI_SUCCESS TPM-1.2 available. The Tpm12RequestUseTpm() and
> - Tpm12SubmitCommand(TPM_ORD_GetTicks) operations
> - (from the Tpm12DeviceLib class) have succeeded.
> -
> - @return Error codes propagated fr
> | X64 | X64| OvmfPkgIa64.dsc | None
> |
> | IA32 X64| PEI-IA32 DXE-X64 | OvmfPkgIa32X64.dsc | None
> |
> -| IA32 X64 Full | PEI-IA32 DXE-X64 | OvmfPkgIa32X64.dsc |
> SECURE_BOO
On 1/16/24 16:16, Michael Brown wrote:
> On 16/01/2024 14:34, Laszlo Ersek wrote:
>> On 1/16/24 10:48, Michael Brown wrote:
>> IOW, my impression is that NestedInterruptTplLib can certainly handle
>> all scenarios thrown at it, but where it really matters is in the face
>
On 1/16/24 14:44, Laszlo Ersek wrote:
> On 1/15/24 16:59, Gerd Hoffmann wrote:
>> Move the DoErase code block into a separate function, call the function
>> instead of jumping around with goto.
>>
>> Signed-off-by: Gerd Hoffmann
>> ---
>> Ovmf
On 1/16/24 12:54, Chao Li wrote:
> On 2024/1/15 16:46, Laszlo Ersek wrote:
>> On 1/12/24 09:25, Chao Li wrote:
>>> @@ -29,7 +29,6 @@
>>>QemuKernel.c
>>>
>>> [Packages]
>>> - ArmVirtPkg/ArmVirtPkg.dec
>>>MdeModulePkg/MdeMo
On 1/16/24 10:48, Michael Brown wrote:
> On 16/01/2024 08:47, Gerd Hoffmann wrote:
>> I think the reason is that the next timer interrupt arriving while the
>> handler is running still is *much* more likely in virtual machines
>> because the vCPU does not get 100% of the of the physical CPU time
On 1/15/24 16:59, Gerd Hoffmann wrote:
> Move the DoErase code block into a separate function, call the function
> instead of jumping around with goto.
>
> Signed-off-by: Gerd Hoffmann
> ---
> OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 76 +-
> 1 file changed, 51
shFvb.c
> @@ -302,6 +302,11 @@ ValidateFvHeader (
>break;
> }
>
> +if (VarHeader->State == 0xff) {
> + DEBUG ((DEBUG_INFO, "%a: end of var list (unwritten state)\n",
> __func__));
> + break;
> +}
> +
> VarName = NULL;
TES)) {
> + if ((End - Start) <= (4 * P30_MAX_BUFFER_SIZE_IN_BYTES)) {
> // Check to see if we need to erase before programming the data into NOR.
> // If the destination bits are only changing from 1s to 0s we can just
> write.
> // After a block is erased all bits
er + P30_MAX_BUFFER_SIZE_IN_BYTES
> + Instance->ShadowBuffer + Index *
> P30_MAX_BUFFER_SIZE_IN_BYTES
> );
> + if (EFI_ERROR (Status)) {
> +goto Exit;
> + }
> }
>
> Exit:
Reviewed-by: Laszlo Ersek
-=-=-=-=-=-=
i.e., the relative offset inside (or just past)
//| | the *double-word* such that it is the
//| | *exclusive* end of the (logical) update.
With that comment update:
Reviewed-by: Laszlo Ersek
Thanks!
Laszlo
> + //| |
> + //| Of
On 1/15/24 13:34, Hamit Can Karaca wrote:
> Hi Yao, Jiewen,
> I actually tried to get help from the ubuntu people but they really
> don't understand what is going in the UEFI side. I am trying to fix
> this problem for 3 weeks now and I am about the give up. I hope
> somebody can help me :(
The
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
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 messag
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
mp; (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
argua
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
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 driv
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.
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
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
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 m
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
>
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/
>> *
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
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
-=-=-=-=-=-=-=-=-=-=-=-
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
> .
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
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
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 s
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 e
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
>
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
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
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
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
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
>>> rul
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
(+ 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
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
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
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
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
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
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
>
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:
>
rbage, 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, th
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
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:
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
_HEADER *)((UINTN)FwVolHeader +
> FwVolHeader->HeaderLength);
>
>// Check the Variable Store Guid
> - if (!CompareGuid (>Signature, ) &&
> - !CompareGuid (>Signature,
> ))
> - {
> + if (!CompareGuid (>Signature,
> )) {
>
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
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 us
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
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
y 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
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
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
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
asteful. 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
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;
>>>}
>>>
>
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:
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
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
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
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:
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
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
y 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
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
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
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 pr
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),
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
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
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.
>>
>
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
201 - 300 of 4300 matches
Mail list logo
