During the Incremental build GenerateByteArrayValue used to generate the
ByteArrayValue even when there is no change in the PCD/VPDs. which is
time consuming API based on the number of PCD/VPDs and SKU IDs.
The optimization is that GenerateByteArrayValue is used to store the
PcdRecordList in a
Hi Jiewen,
All EDK2 PR CI builds of OvmfPkg are broken due to this issue.
Maybe we didn't have enough time to wait feedback and should fix the CI issue
first.
Regards,
Yi
-Original Message-
From: devel@edk2.groups.io On Behalf Of Yao, Jiewen
Sent: Tuesday, January 16, 2024 10:38 PM
Laszlo, Michael,
When timer interrupt happens, the calling flow is:
[Timer Interrupt #1] CPU IDT handler calls into
LocalApicTimerDxe::TimerInterruptHandler(), which
[Timer Interrupt #1]1. RaiseTPL (HIGH) from APPLICATION causing CPU
interrupt be disabled.
[Timer Interrupt #1]2. Send APIC
CoreConnectSingleController() searches for the Driver Family Override
Protocol drivers by looping and checking each Driver Binding Handles.
This loop can be skipped by checking if any Driver Family Override
Protocol installed in the platform first, to improve the performance.
Cc: Liming Gao
Cc:
CoreGetProtocolInterface() is called by CoreOpenProtocol(),
CoreCloseProtocol() and CoreOpenProtocolInformation().
Before CoreOpenProtocol() calls CoreGetProtocolInterface(), the input
parameter UserHandle has been already checked for validation. So does
CoreCloseProtocol().
Removing the handle
The purpose of writing CR3 in ConvertMemoryPageToNotPresent is just
to flush TLB, because CR3 won't be changed in function
ConvertMemoryPageToNotPresent.
After ConvertMemoryPageToNotPresent, there is always a flush TLB
function. Also, because ConvertMemoryPageToNotPresent in called in a
loop, to
PageTableMap() only modifies the PageTable root pointer when creating from zero.
Explicitly explain it in function header.
Cc: Ray Ni
Cc: Laszlo Ersek
Cc: Rahul Kumar
Cc: Gerd Hoffmann
Signed-off-by: Zhiguang Liu
---
UefiCpuPkg/Include/Library/CpuPageTableLib.h | 1 +
Zhang, Zifeng would like to recall the message, "[edk2-devel] [Patch V2]
BaseTools: VfrCompiler Adds DefaultValueError Feature".
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113927): https://edk2.groups.io/g/devel/message/113927
Mute
Hi Gua, Arthur.
Do you have opens for this solution suggested from Liming?
Jira: https://jira.devtools.intel.com/browse/CRJ-23954
Best Regards,
Zifeng
-Original Message-
From: gaoliming
Sent: Tuesday, January 16, 2024 11:04 PM
To: devel@edk2.groups.io; Zhang, Zifeng ; Yang, Yuting2
Can you remove "EFIAPI" from the two Amd* local functions?
The two are *local* functions called from the accordingly public LIB APIs.
Thanks,
Ray
> -Original Message-
> From: Abdul Lateef Attar
> Sent: Tuesday, January 16, 2024 3:01 PM
> To: devel@edk2.groups.io
> Cc: Abdul Lateef Attar
Gerd
I am OK with the patch.
Quick question: Have you validated that the TPM2 is still working?
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Gerd
> Hoffmann
> Sent: Tuesday, January 16, 2024 11:42 PM
> To: devel@edk2.groups.io
> Cc: Oliver Steffen ; Gerd Hoffmann
We emulate XHCI controller already. No need to add it.
Signed-off-by: Marcin Juszkiewicz
---
Platform/Qemu/SbsaQemu/Readme.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Platform/Qemu/SbsaQemu/Readme.md b/Platform/Qemu/SbsaQemu/Readme.md
index
Unit tests for the math calculations would help with reviews too.
Mike
> -Original Message-
> From: Laszlo Ersek
> Sent: Tuesday, January 16, 2024 2:03 AM
> To: Kinney, Michael D ; Pedro Falcato
> ; devel@edk2.groups.io; Ni, Ray
>
> Cc: Desimone, Nathaniel L ; Kumar, Rahul
> R ; Gerd
This is needed to avoid bit operations being applied to signed integers.
Suggested-by: László Érsek
Signed-off-by: Gerd Hoffmann
Reviewed-by: Laszlo Ersek
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.h | 2 +-
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 2 +-
2 files changed, 2 insertions(+), 2
Replace the two NorFlashWriteBuffer() calls with a loop containing a
single NorFlashWriteBuffer() call.
With the changes in place the code is able to handle updates larger
than two P30_MAX_BUFFER_SIZE_IN_BYTES blocks, even though the patch
does not actually change the size limit.
Signed-off-by:
Move the DoErase code block into a separate function, call the function
instead of jumping around with goto.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 76 ++
1 file changed, 52 insertions(+), 24 deletions(-)
diff --git
Raise the limit for writes without block erase from two to four
P30_MAX_BUFFER_SIZE_IN_BYTES blocks. With this in place almost all efi
variable updates are handled without block erase. With the old limit
some variable updates (with device paths) took the block erase code
path.
Signed-off-by:
It is possible to find variable entries with State being 0xff, i.e. not
updated since flash block erase. This indicates the variable driver
could not complete the header write while appending a new entry, and
therefore State was not set to VAR_HEADER_VALID_ONLY.
This can only happen at the end
Introduce 'Start' and 'End' variables to make it easier to follow the
logic and code flow. Also add a ascii art diagram (based on a
suggestion by Laszlo).
This also fixes the 'Size' calculation for the NorFlashRead() call.
Without this patch the code will read only one instead of two
This is a little series containing the flash corruption fix sent
yesterday with an slightly improved commit message and some small
improvements on top of this.
v3:
- fix diagram
- fix DoErase control flow
- pick up reviewed-by tags
v2:
- drop broken bugfix, fix the bug when introducing
(cc Jiewen. Laszlo)
On Tue, 16 Jan 2024 at 16:42, Gerd Hoffmann wrote:
>
>
>
> Gerd Hoffmann (2):
> OvmfPkg: remove TPM1_ENABLE build option
> OvmfPkg/Tcg2Config: remove unused TPM 1.2 support
>
Good riddance
Acked-by: Ard Biesheuvel
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/Dsc/OvmfTpmComponentsDxe.dsc.inc | 6 --
OvmfPkg/Include/Dsc/OvmfTpmComponentsPei.dsc.inc | 5 -
OvmfPkg/Include/Dsc/OvmfTpmDefines.dsc.inc | 3 ---
OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc | 9 -
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf | 56 ---
OvmfPkg/Tcg/Tcg2Config/Tpm12Support.c | 83 ---
2 files changed, 139 deletions(-)
delete mode 100644 OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf
delete mode 100644
Gerd Hoffmann (2):
OvmfPkg: remove TPM1_ENABLE build option
OvmfPkg/Tcg2Config: remove unused TPM 1.2 support
.../Include/Dsc/OvmfTpmComponentsDxe.dsc.inc | 6 --
.../Include/Dsc/OvmfTpmComponentsPei.dsc.inc | 5 --
OvmfPkg/Include/Dsc/OvmfTpmDefines.dsc.inc| 3 -
On 1/16/24 16:16, Michael Brown wrote:
> On 16/01/2024 14:34, Laszlo Ersek wrote:
>> On 1/16/24 10:48, Michael Brown wrote:
>> IOW, my impression is that NestedInterruptTplLib can certainly handle
>> all scenarios thrown at it, but where it really matters is in the face
>> of an interrupt storm
On 1/16/24 14:44, Laszlo Ersek wrote:
> On 1/15/24 16:59, Gerd Hoffmann wrote:
>> Move the DoErase code block into a separate function, call the function
>> instead of jumping around with goto.
>>
>> Signed-off-by: Gerd Hoffmann
>> ---
>> OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 76
On 16/01/2024 14:34, Laszlo Ersek wrote:
On 1/16/24 10:48, Michael Brown wrote:
IOW, my impression is that NestedInterruptTplLib can certainly handle
all scenarios thrown at it, but where it really matters is in the face
of an interrupt storm (not just "normal nesting"), and a storm is
unlikely
This option is for the module check. I suggest to set this option in INF
instead of DSC.
If so, DSC is not required to configure the additional options. And, this
module will have the same build result
when it is specified in the different platform DSC files.
I understand your requirement
On 1/16/24 12:54, Chao Li wrote:
> On 2024/1/15 16:46, Laszlo Ersek wrote:
>> On 1/12/24 09:25, Chao Li wrote:
>>> @@ -29,7 +29,6 @@
>>>QemuKernel.c
>>>
>>> [Packages]
>>> - ArmVirtPkg/ArmVirtPkg.dec
>>>MdeModulePkg/MdeModulePkg.dec
>>>MdePkg/MdePkg.dec
>>>OvmfPkg/OvmfPkg.dec
Gua:
I think new code logic is same to old one. Can you point what difference
here?
Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io 代表 Guo, Gua
> 发送时间: 2024年1月12日 10:25
> 收件人: devel@edk2.groups.io
> 抄送: gua@intel.com; Marc Beatove ; Liming
> Gao ; John Mathew ;
> Gerd Hoffmann
>
Sure. Let's start from OVMF.
We have leaf enough time for feedback, but I see no comment from other people.
> -Original Message-
> From: Gerd Hoffmann
> Sent: Tuesday, January 16, 2024 10:35 PM
> To: devel@edk2.groups.io; Yao, Jiewen
> Cc: dougfl...@microsoft.com; Douglas Flick [MSFT]
On Tue, Jan 16, 2024 at 01:30:43PM +, Yao, Jiewen wrote:
> Gerd
> I have merged this patch set today.
>
> I am fine to remove TPM1.2 in OVMF because of the known security limitation.
I was thinking about the complete edk2 code base not only OVMF.
But I can surely start with OVMF. Maybe it
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
I am OK for this change. Reviewed-by: Liming Gao
> -邮件原件-
> 发件人: devel@edk2.groups.io 代表 Xu, GuoX
> 发送时间: 2024年1月9日 17:24
> 收件人: devel@edk2.groups.io
> 抄送: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang
> 主题: Re: [edk2-devel] [PATCH 1/1] MdePkg:Updated the comments of
>
I am OK to merge it. Reviewed-by: Liming Gao
发件人: devel@edk2.groups.io 代表 Sami Mujawar
发送时间: 2024年1月12日 22:37
收件人: PierreGondois ; devel@edk2.groups.io
主题: Re: [edk2-devel] [PATCH v2 1/1] MdePkg/IndustryStandard: Add
_PSD/_CPC/Coord types definitions
Hi Liming,
If there are no further
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
Gerd
I have merged this patch set today.
I am fine to remove TPM1.2 in OVMF because of the known security limitation.
Thank you
Yao, Jiewen
> -Original Message-
> From: Gerd Hoffmann
> Sent: Tuesday, January 16, 2024 8:01 PM
> To: devel@edk2.groups.io; dougfl...@microsoft.com
> Cc:
Thanks Gerd for providing the inputs.
I'll enhance the logic accordingly and submit the V2 patch.
Thanks
AbduL
On 16-01-2024 15:11, Gerd Hoffmann wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On
On 1/15/24 16:59, Gerd Hoffmann wrote:
> It is possible to find variable entries with State being 0xff, i.e. not
> updated since flash block erase. This indicates the variable driver
> could not complete the header write while appending a new entry, and
> therefore State was not set to
On 1/15/24 16:59, Gerd Hoffmann wrote:
> Raise the limit for writes without block erase from two to four
> P30_MAX_BUFFER_SIZE_IN_BYTES blocks. With this in place almost all efi
> variable updates are handled without block erase. With the old limit
> some variable updates (with device paths)
On 1/15/24 16:59, Gerd Hoffmann wrote:
> Replace the two NorFlashWriteBuffer() calls with a loop containing a
> single NorFlashWriteBuffer() call.
>
> With the changes in place the code is able to handle updates larger
> than two P30_MAX_BUFFER_SIZE_IN_BYTES blocks, even though the patch
> does
On 1/15/24 16:59, Gerd Hoffmann wrote:
> Introduce 'Start' and 'End' variables to make it easier to follow the
> logic and code flow. Also add a ascii art diagram (based on a
> suggestion by Laszlo).
>
> This also fixes the 'Size' calculation for the NorFlashRead() call.
> Without this patch the
Hi Laszlo,
Thanks,
Chao
On 2024/1/15 16:32, Laszlo Ersek wrote:
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
Looks good to me.
Reviewed-by: Chao Li
Hi Zhichao,
Please help review this patch.
Thanks,
Chao
On 2024/1/16 15:11, Dongyan Qian wrote:
According to SMBIOS spec3.6, LoongArch information support has been added,
so this patch is submitted for display as information in smbiosview.
Cc:
Looks good to me.
Reviewed-by: Chao Li
Hi Liming,
Please help review this patch.
Thanks,
Chao
On 2024/1/16 15:11, Dongyan Qian wrote:
This fixes messages like:
"Image type X64 can't be loaded on UEFI system"
Cc: Liming Gao
Cc: Chao Li
Signed-off-by: Dongyan Qian
---
On Thu, Jan 11, 2024 at 10:16:00AM -0800, Doug Flick via groups.io wrote:
> This patch series include the combined / merged security patches
> (as seperate commits) for TCBZ4117 (CVE-2022-36763) and TCBZ4118
> (CVE-2022-36764) for DxeTpm2MeasureBootLib and DxeTpmMeasureBootLib.
> These patches
Hi Laszlo,
Thanks,
Chao
On 2024/1/15 16:46, Laszlo Ersek wrote:
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").
Hi Laszlo,
Thanks,
Chao
On 2024/1/15 16:33, Laszlo Ersek wrote:
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
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 Tue, 16 Jan 2024 at 10:37, Laszlo Ersek wrote:
>
> 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
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 16/01/2024 08:47, Gerd Hoffmann wrote:
I think the reason is that the next timer interrupt arriving while the
handler is running still is *much* more likely in virtual machines
because the vCPU does not get 100% of the of the physical CPU time
slice.
The interrupt handler can run for an
On Tue, Jan 16, 2024 at 12:31:21PM +0530, Abdul Lateef Attar wrote:
> From: Abdul Lateef Attar
>
> This patch adds support for AMD's new extended topology.
> If processor supports CPUID 8026 leaf then obtain
> the topology information using new method.
> + /// Check if extended toplogy
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
Hi,
> 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.
It wasn't.
> On a second thought, I'm (retroactively?) surprised that
> LocalApicTimerDxe was (apparently?) first introduced under OvmfPkg --
[AMD Official Use Only - General]
Got it and thanks.
I will fix the typo, put your RB then merge this patch.
Abner
> -Original Message-
> From: Nickle Wang
> Sent: Tuesday, January 16, 2024 2:20 PM
> To: Chang, Abner ; devel@edk2.groups.io
> Cc: Igor Kulchytskyy
> Subject: RE:
56 matches
Mail list logo
