On 30/05/2024 11:33, Gerd Hoffmann wrote:
Most likely it is exactly this ...
As of commit
https://github.com/ipxe/ipxe/commit/6769a7c3c, we now deliberately leak
resources once ExitBootServices has been triggered by skipping the cleanup
calls to UninstallMultipleProtocolInterfaces etc.
... as
On 30/05/2024 10:31, Gerd Hoffmann wrote:
On Thu, May 30, 2024 at 01:07:45PM GMT, gaoliming via groups.io wrote:
If ASSERT trigs the exception, could call stack show each caller?
Turned out to be ipxe, apparently it has a exit-boot-services handler
which triggers all this.
iPXE shouldn't be
On 08/05/2024 22:19, Ard Biesheuvel wrote:
I've always found that logic rather bizarre - there is no way the
implementation of the raw protocol can ensure that the caller uses it
correctly, and so enforcing a minimum read size is pointless and
arbitrary. And as you note, it has no basis in the UE
On 19/04/2024 11:02, Mike Beaton wrote:
Dear Michael,
I don't know if you had time to answer one follow-up question.
Obviously one thing that someone might want to do is to notify on
protocol installs and trap installs of this protocol - e.g. so that
something other than UefiBootManagerLib ca
On 06/04/2024 16:53, Mike Beaton wrote:
The existing uninstall call was passing the wrong handle (parent object,
not the correct child object) and additionally passing the address
of a pointer to the interface to be removed rather than the pointer
itself, so always failed with EFI_NOT_FOUND. Afte
Reviewed-by: Michael Brown
Thanks,
Michael
On 01/03/2024 02:54, Zhou Jianfeng wrote:
Add volatile qualifier to page table related variable to prevent
compiler from optimizing away the variables which may lead to
unexpected result.
Signed-off-by: Zhou Jianfeng
Cc: Ray Ni
Cc: Laszlo Ersek
On 01/03/2024 09:33, Paolo Bonzini wrote:
On Fri, Mar 1, 2024 at 10:27 AM Michael Brown wrote:
It's possible that it doesn't matter. The new logic will effectively
mean that RestoreTPL() will restore not only the TPL but also the
interrupts-enabled state to whatever existed at the t
On 01/03/2024 08:37, Paolo Bonzini wrote:
So I am starting to see more and more similarities between the two
approaches. I went a step further with fresh mind, removing the while
loop... and basically reinvented your and Michael's patch. :) The only
difference in the logic is a slightly differen
On 29/02/2024 19:26, Michael D Kinney wrote:
I think one advantage of this new proposal is to prevent
an extra level of nesting and use of stack resources in
that extra level.
I think that's a negligible benefit. In the scenario as I outlined for
NestedInterruptTplLib, there is potentially on
On 29/02/2024 19:09, Michael D Kinney wrote:
"When the DXE Foundation is notified that the EFI_CPU_ARCH_PROTOCOL has
been installed, then the full version of the Boot Service RestoreTPL()
can be made available. When an attempt is made to restore the TPL
level
to level below EFI_TPL_HIGH_LEVEL, t
On 29/02/2024 19:04, Paolo Bonzini wrote:
On 2/29/24 14:02, Ray Ni wrote:
In the end, it will lower the TPL to TPL_APPLICATION with interrupt
enabled.
However, it's possible that another timer interrupt happens just in
the end
of RestoreTPL() function when TPL is TPL_APPLICATION.
How do no
On 29/02/2024 16:43, Kinney, Michael D wrote:
Hi Michael,
Can you provide a pointer to the UEFI Spec statement this breaks?
II-9.7.1.3 RestoreTPL():
"When the DXE Foundation is notified that the EFI_CPU_ARCH_PROTOCOL has
been installed, then the full version of the Boot Service RestoreTPL()
On 29/02/2024 13:02, Ni, Ray wrote:
A ideal solution is to not keep the interrupt disabled when
RestoreTPL(TPL_HIGH -> not TPL_HIGH) is executed in the timer interrupt
context because the interrupt handler will re-enable the interrupt with
arch specific instructions (e.g.: IRET for x86).
The pat
On 23/02/2024 15:12, Zhou, Jianfeng wrote:
While it may well cause the compiler to generate less optimised code, there is
absolutely no way that this volatile declaration on a local stack variable can
possibly change the outcome of the code.
There can never be any meaningful side-effects from r
On 22/02/2024 08:41, Zhou Jianfeng wrote:
--- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
+++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
@@ -20,13 +20,13 @@
**/
VOID
PageTableLibSetPte4K (
- IN OUT IA32_PTE_4K *Pte4K,
- IN UINT64 Offset,
-
On 19/02/2024 06:44, Hamit Can Karaca wrote:
I am having problem while booting Starlingx on iPXE on UEFI. It says
malformed binary and does not allow me to boot afterwards. What should I
do in BIOS to solve this problem?
I can boot Starlingx on other platforms using OEM BIOS.
Our platform is
On 25/01/2024 15:06, Ni, Ray wrote:
I agree with you about the above PI spec clarifications.
Would you like to write a PI spec ECR?
I am not a UEFI Forum member, so I don't think I have standing to do
this. (I also don't have the spare time to do this for free, sorry.)
But I do not think t
On 25/01/2024 13:54, Ni, Ray wrote:
I don't disagree with the approach, but it does break the API as per the
UEFI PI specification (version 1.8 section II-12.10), and so this is not
something that can just be dropped in as an EDK2 code change.
You think that the TimerInterruptHandler() doesn't
On 25/01/2024 07:57, Ni, Ray wrote:
This mail is to bring another approach to solve the stack-overflow due
to nested interrupts. Michael solved this problem in OVMF through
NestedInterruptTplLib.
I made a draft patch as attached “DxeCore.diff”. The patch simply to
avoid the interrupt in enabl
On 23/01/2024 16:55, Laszlo Ersek wrote:
+ ///
+ /// Number of self-tests performed.
+ ///
+ UINTN SelfTestCount;
} NESTED_INTERRUPT_STATE;
/**
I suggest that the new field be UINT32. The (exclusive) limit is a
32-bit PCD. Making the counter (potentially) wider than the limit is
On 23/01/2024 17:10, Laszlo Ersek wrote:
Other than that, the patch looks great to me; I'd only propose one
(superficial) improvement:
rather than include , scavenge
#ifdef MDE_CPU_ARM
#include
#elif defined (MDE_CPU_AARCH64)
#include
#endif
from it.
Reasons:
(a) Those are the headers that
On 23/01/2024 16:32, Laszlo Ersek wrote:
On 1/23/24 16:31, Michael Brown wrote:
At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
specification) and so we should never encounter a situation in which
an interrupt occurs at TPL_HIGH_LEVEL.
Restoring TPL to TPL_HIGH_LEVEL is always
On 23/01/2024 15:51, Ard Biesheuvel wrote:
On Tue, 23 Jan 2024 at 16:31, Michael Brown wrote:
Add implementations of DisableInterruptsOnIret() for MDE_CPU_ARM and
MDE_CPU_AARCH64. In both cases, the saved IRQs-disabled and
FIQs-disabled flags are set in the stored processor status register
o use NestedInterruptTplLib and
verifying that ArmVirtQemu passes the NestedInterruptTplLib self-tests
for both ARM and AARCH64.
Cc: Ard Biesheuvel
Signed-off-by: Michael Brown
---
MdeModulePkg/MdeModulePkg.dsc | 2 +-
.../NestedInterruptTplLib.inf | 3 +++
.../Li
time.
Only one test is performed by default (to avoid unnecessary system
startup delay). The number of tests performed can be controlled via
PcdNestedInterruptNumberOfSelfTests at build time.
Signed-off-by: Michael Brown
---
MdeModulePkg/MdeModulePkg.dec | 4
that we do not need
to consider the effect of this possible invariant violation on the
remainder of the logic.
Signed-off-by: Michael Brown
---
MdeModulePkg/Library/NestedInterruptTplLib/Tpl.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/MdeModulePkg/Library
Allow build system to detect changes to Iret.h.
Suggested-by: Ray Ni
Reviewed-by: Laszlo Ersek
Signed-off-by: Michael Brown
---
.../Library/NestedInterruptTplLib/NestedInterruptTplLib.inf | 1 +
1 file changed, 1 insertion(+)
diff --git
a/MdeModulePkg/Library/NestedInterruptTplLib
:
- Add missing Iret.h to NestedInterruptTplLib sources list
Changes since v2:
- Remove obsolete dependency of LocalApicTimerDxe on OvmfPkg
- Add to MdeModulePkg.dsc for build coverage
- Add self-tests
- Add support for Arm CPUs
Michael Brown (5):
MdeModulePkg: Move
IA32 and X64 only, since those are the only two architectures for
which DisableInterruptsOnIret() is currently supported.
Cc: Ray Ni
Cc: Laszlo Ersek
Cc: Gerd Hoffmann
Cc: Michael D Kinney
Reviewed-by: Laszlo Ersek
Signed-off-by: Michael Brown
---
MdeModulePkg/MdeModulePkg.dec
On 22/01/2024 10:36, Laszlo Ersek wrote:
(1) Does LocalApicTimerDxe have any other dependencies on OvmfPkg than
the library class header?
In other words, can't we remove "OvmfPkg/OvmfPkg.dec" from this
[Packages] section, too?
I can't see anything else, so I'd suggest to remove
"OvmfPkg/OvmfPkg
sources list
Cc: Ray Ni
Cc: Laszlo Ersek
Cc: Gerd Hoffmann
Cc: Michael D Kinney
Michael Brown (2):
MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg
MdeModulePkg: Add missing Iret.h to NestedInterruptTplLib sources list
MdeModulePkg/MdeModulePkg.dec | 4
Suggested-by: Ray Ni
Signed-off-by: Michael Brown
---
.../Library/NestedInterruptTplLib/NestedInterruptTplLib.inf | 1 +
1 file changed, 1 insertion(+)
diff --git
a/MdeModulePkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
b/MdeModulePkg/Library/NestedInterruptTplLib
Signed-off-by: Michael Brown
---
MdeModulePkg/MdeModulePkg.dec | 4
OvmfPkg/OvmfPkg.dec | 4
OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +-
OvmfPkg/CloudHv/CloudHvX64.dsc
On 20/01/2024 07:03, Ni, Ray wrote:
Can you submit another patch to add Iret.h to the INF file [Sources] section?
Without that, incremental build might not work if changes are made in Iret.h.
Good catch, thank you. I will send a v2.
It doesn't support non-x86 CPU. Will ARM have similar prob
On 19/01/2024 23:44, Ni, Ray wrote:
I still want to see if the RestoreTpl2 that does not enable interrupt is
added as a protocol, and how simple the lib could be.
RestoreTpl() always has to enable interrupts during its execution, since
interrupts must be allowed to occur while callbacks are ru
Signed-off-by: Michael Brown
---
MdeModulePkg/MdeModulePkg.dec | 4
OvmfPkg/OvmfPkg.dec | 4
OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +-
OvmfPkg/CloudHv/CloudHvX64.dsc
On 19/01/2024 13:14, Ni, Ray wrote:
So, the interrupt re-entrance we want to avoid is “env:NOTIFY” ->
“env:NOTIFY”, or “env:CALLBACK” -> “env:CALLBACK”, or “env:APPLICATION”
-> “env:APPLICATION”. Because it’s endless.
NestedTplInterruptLib was written to avoid it.
Yes, precisely this.
2.
On 17/01/2024 07:11, Ni, Ray wrote:
The above flow shows endless re-entrance of timer interrupt handler.
But, my question is: above flow only can happen in real platform when the below
4 steps occupies more time than the timer period (usually 10ms).
[Timer Interrupt #2]1. RaiseTPL
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 i
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 arbi
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 th
On 05/01/2024 08:41, Chang, Abner wrote:
We are not aware there is a TlsConnectSession() for TLS handshake using the
default TLS configuration data and it returns a failure as expected because the
default TLS configuration is TLS_VERIFY_HOST without certificate installed on
system.
This happen
Since this changes the ABI, you may want to also update the protocol
GUID to prevent strange errors if old and new binaries are used on the
same system.
Reviewed-by: Michael Brown
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Re
turns EFI_SUCCESS to
the caller. The failure is pushed back to TLS DXE driver if the
HTTP communication actually requires certificate.
Reviewed-by: Michael Brown
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113310): https:/
nstance->TlsChildHandle
+ with opened EFI_TLS_PROTOCOL and
EFI_TLS_CONFIGURATION_PROTOCOL.
As above.
Reviewed-by: Michael Brown
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113309): https://edk2.groups.io/g
On 02/01/2024 16:31, Chang, Abner via groups.io wrote:
From: Michael Brown
- Allow the call to Request() to perform its normal TLS configuration
via TlsConfigureSession(), as though the connection were going to
perform host verification etc as per the platform default policy. This
On 02/01/2024 06:06, Chang, Abner via groups.io wrote:
What do you think about:
- installing TLS on HTTP handle (as you have already implemented)
- using EDKII_HTTP_CALLBACK_PROTOCOL to catch the HttpEventInitSession
and perform whatever calls are needed to SetData() to modify the TLS
configura
On 29/12/2023 15:07, Chang, Abner via groups.io wrote:
To locate TLS protocol from the HTTP handle and configure TLS configuration
data at the return from EfiHttpRequest during that short window of non-blocking
request is not reliable. It also doesn't make sense to ask upper layer
application
estion, I'm happy to add
Reviewed-by: Michael Brown
for this patch.
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113014): https://edk2.groups.io/g/devel/message/113014
Mute This Topic: https://groups.io/mt/1034
On 28/12/2023 23:37, Chang, Abner via groups.io wrote:
As far as I am aware, EfiHttpRequest sets up all of the relevant data
structures but functions as a non-blocking open. If you reconfigure the
TLS session immediately after return from EfiHttpRequest() then this
reconfiguration should take ef
On 28/12/2023 15:04, Chang, Abner via groups.io wrote:
With the TLS protocol installed onto the same handle, I don't think you
then even need to use RegisterProtocolNotify(). On return from
EFI_HTTP_PROTOCOL.Request() you can open the TLS protocol on the handle
and immediately call SetSessionDat
On 28/12/2023 02:47, Chang, Abner via groups.io wrote:
On 26/12/2023 11:28, Chang, Abner via groups.io wrote:
Platform developer can provide this protoocl to EFI HTTP driver to
configure TLS using TLS conifg data provided by
EDKII_HTTPS_TLS_PLATFORM_POLICY_PROTOCOL for the specific HTTP
protocol
On 26/12/2023 11:28, Chang, Abner via groups.io wrote:
For the HTTPS connetion that doesn't require TLS peer verification,
EDKII_HTTPS_TLS_PLATFORM_POLICY_PROTOCOL is introduced to platform
developer to provide the TLS configure data that is different than
the default TLS configuration. The use c
On 03/11/2023 16:03, Kinney, Michael D wrote:
PCI Configuration read/write operations are non-posted, so the PCI
Configuration write operation should complete without the need for
an additional transaction. If you are seeing an issue, then it may
be in the implementation of the PciLib/PciSegment
On 01/11/2023 20:17, Joe L wrote:
Thanks for the discussion,
Are we saying that DataSynchronizationBarrier () before the return
from RootBridgeIoPciAccess() is not strong enough to determine that
the final ECAM write would have completed? According to Learn the
architecture - ARMv8-A memory s
On 01/11/2023 12:51, Ard Biesheuvel wrote:
On Wed, 1 Nov 2023 at 13:25, Michael Brown wrote:
By my reading, the PCIe specification seems to therefore require
something stronger than an ordering guarantee: it requires the ability
for software to make a standalone determination that the write
On 01/11/2023 09:56, Ard Biesheuvel wrote:
On Wed, 1 Nov 2023 at 03:09, Pedro Falcato wrote:
On Wed, Nov 1, 2023 at 12:40 AM Joe L wrote:
Our CMN TRM showcases an example where ECAM and MMIO are two different regions
in the HN-I SAM. The implication is that we would expect a DSB between the
On 29/09/2023 10:47, Marvin Häuser wrote:
Maybe when Linux starts adhering the spec for file names (the spec clearly
defines e.g. BOOTx64.EFI, while at least some distros/images use bootx64.efi),
this can be discussed. :) Let's not break various GRUB setups...
Seems slightly unfair to blame L
On 25/07/2023 17:07, Jayaprakash, N wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4506
res_init() is called from different places in sockets library. It depends
on global _res variable containing a state.
The problem is that if __BIND_RES_TEXT macro is not defined, _res is not
init
On 19/07/2023 17:52, Ard Biesheuvel wrote:
On Wed, 19 Jul 2023 at 18:32, Gerd Hoffmann wrote:
On Wed, Jul 19, 2023 at 04:04:28PM +, Michael Brown wrote:
It looks as though IoMmuFreeBounceBuffer() should also raise to TPL_NOTIFY
while modifying mReservedMemBitmap, since the modification
On 19/07/2023 12:33, Gerd Hoffmann wrote:
Searching for an unused bounce buffer in mReservedMemBitmap and
reserving the buffer by flipping the bit is a critical section
which must not be interrupted. Raise the TPL level to ensure
that.
Without this fix it can happen that IoMmuDxe hands out the
On 06/07/2023 15:19, Henz, Patrick wrote:
I agree that XhcGetElapsedTime() would be better off in TimerLib, but I wasn't
sure how the community would feel about adding to the interface.
My understanding is that the TimerLib API is not prescribed by any
standards document, and that this change
On 05/07/2023 21:15, Henz, Patrick wrote:
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2948
XhciDxe uses the timer functionality provided by the
boot services table to detect timeout conditions. This
breaks the driver's ExitBootServices call back, as
CoreExitBootServices halts the timer be
On 09/05/2023 14:31, Laszlo Ersek wrote:
On 5/9/23 14:09, Michael Brown wrote:
At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
specification) and so we should never encounter a situation in which
an interrupt occurs at TPL_HIGH_LEVEL. The specification also
restricts usage of
ror message, to allow UEFI applications such as these versions
of the Microsoft Windows bootloader to continue to function.
Debugged-by: Gerd Hoffmann
Debugged-by: Laszlo Ersek
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
Signed-off-by: Michael Brown
---
OvmfPkg/Libr
.
Signed-off-by: Michael Brown
---
OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
index e19d98878eb7..e921a09c5599 100644
--- a/OvmfPkg
dan Justen
Michael Brown (2):
OvmfPkg: Clarify invariants for NestedInterruptTplLib
OvmfPkg: Relax assertion that interrupts do not occur at
TPL_HIGH_LEVEL
OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +
1 file changed, 26 insertions(+), 5 deletions(-)
--
2.3
On 09/05/2023 09:43, Laszlo Ersek wrote:
I'm not subscribed to the list, so I don't have a copy of patch#1. I've
checked patch#1 at this URL:
https://listman.redhat.com/archives/edk2-devel-archive/2023-May/063591.html
and I'll comment on it using the cover letter:
I really like that patch, wit
On 09/05/2023 09:35, Laszlo Ersek wrote:
Thank you for the patch; I do apologize about splitting hairs. The
debugging was difficult, and you *are* working around a bug here -- but
I'd really like our tone of voice to be positive here, simply because of
the stunningly positive attitude I've experi
low TPL_HIGH_LEVEL
to an error message, to allow rogue UEFI applications such as the
Microsoft Windows bootloader to continue to function.
Debugged-by: Gerd Hoffmann
Debugged-by: Laszlo Ersek
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
Signed-off-by: Michael Brown
---
OvmfPkg/Libr
.
Signed-off-by: Michael Brown
---
OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
index e19d98878eb7..e921a09c5599 100644
--- a/OvmfPkg
Cc: Jordan Justen
Michael Brown (2):
OvmfPkg: Clarify invariants for NestedInterruptTplLib
OvmfPkg: Relax assertion that interrupts do not occur at
TPL_HIGH_LEVEL
OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +
1 file changed, 26 insertions(+), 5 deleti
On 05/05/2023 19:56, Laszlo Ersek wrote:
I don't like the patch. For two reasons:
(1) It papers over the actual issue. The problem should be fixed where
it is, if possible.
Agreed, but (as you have shown in
https://bugzilla.redhat.com/show_bug.cgi?id=2189136) the bug lies in
Windows code rat
ces->Stall() being called with IPL=TPL_HIGH_LEVEL
and Interrupts /enabled/ while windows is booting.
Cc: Michael Brown
Cc: Laszlo Ersek
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Ov
On 28/04/2023 14:38, Gerd Hoffmann wrote:
I suspect the windows boot loader does something fishy here, but I can't
proof it, I have not yet pinned down the exact location where interrupts
get enabled while running at IPL=TPL_HIGH_LEVEL (which is what I suspect
is happening, but of course this is
On 28/04/2023 10:10, Gerd Hoffmann wrote:
OVMF can't guarantee that the ASSERT() doesn't happen. Misbehaving
EFI applications can trigger this. So log a warning instead and try
to continue.
Reproducer: Fetch windows 11 22H2 iso image, boot it in qemu with OVMF.
Traced to BootServices->Stall()
On 03/04/2023 11:13, Chao Li wrote:
This problem is because the gcc-12 does not yet to support the option
'mno-explicit-reloc', this option is used to open the new reloaction
type for LoongArch, this new feature is very important for LoongArch,
because it can reduce the binary size and improve
On 07/03/2023 08:21, Nickle Wang via groups.io wrote:
I got an idea to handle this issue.
EFI_HTTP_SERVICE_BINDING_PROTOCOL is defined in UEFI specification for
caller to create HTTP protocol on child instance. How about I propose a
new service binding protocol called
EFI_HTTP_*NO_TLS_HOST_VE
On 17/02/2023 04:27, Sunil V L wrote:
On Thu, Feb 16, 2023 at 03:45:49PM -0700, dann frazier wrote:
Thanks for your work getting this merged! In the above wiki, it
notes that GCC 12+ is not supported. Is that still accurate? If so,
can you clarify what is blocking that?
Please see https://b
On 15/02/2023 05:36, RichardHo [何明忠] via groups.io wrote:
On 15/02/2023 05:36, RichardHo [何明忠] via groups.io wrote:
On 15/02/2023 05:36, RichardHo [何明忠] via groups.io wrote:
On 15/02/2023 05:36, RichardHo [何明忠] via groups.io wrote:
On 15/02/2023 05:36, RichardHo [何明忠] via groups.io wrote:
+ if (
On 14/02/2023 13:01, Gerd Hoffmann wrote:
On Mon, Feb 13, 2023 at 04:15:30PM +, Michael Brown wrote:
On 13/02/2023 15:48, Michael Kubacki wrote:
@@ -1608,9 +1610,12 @@ ParseAndAddExistingSmbiosTable (
//
// Make sure not to access memory beyond SmbiosEnd
//
-if
On 13/02/2023 15:48, Michael Kubacki wrote:
@@ -1608,9 +1610,12 @@ ParseAndAddExistingSmbiosTable (
//
// Make sure not to access memory beyond SmbiosEnd
//
-if ((Smbios.Raw + sizeof (SMBIOS_STRUCTURE) > SmbiosEnd.Raw) ||
-(Smbios.Raw + sizeof (SMBIOS_STRUCTURE) < Sm
On 09/02/2023 10:28, Sunil V L wrote:
+ gBS->RestoreTPL (OriginalTPL);
+ RiscVEnableTimerInterrupt (); // enable SMode timer int
+}
This design looks as though it does not support nested timer interrupts.
The call to RestoreTPL() may invoke callbacks that may themselves include
delay loops th
+/**
+ Timer Interrupt Handler.
+
+ @param InterruptTypeThe type of interrupt that occured
+ @param SystemContextA pointer to the system context when the interrupt
occured
+**/
+VOID
+EFIAPI
+TimerInterruptHandler (
+ IN EFI_EXCEPTION_TYPE InterruptType,
+ IN EFI_SYSTEM_CONTEXT Sys
On 08/02/2023 09:55, Alireza Banejad wrote:
As my previous email, I mentioned that I am able to find the protocol
since the LocateProtocol returns 0 (EFI_SUCCESS) (using the exact code
you wrote) . But when I want to open it either with OpenProtocol or
HandleProtocol I get a RETURN_UNSUPPORTED.
On 08/02/2023 08:03, Alireza Banejad wrote:
Below is how I use the HandleProtocol function:
Status = gBS->HandleProtocol (
gST->ConsoleOutHandle,
&gEfiGraphicsOutputProtocolGuid,
(VOID **)&GraphicsOutput
);
You are
On 07/02/2023 06:21, Tinh Nguyen via groups.io wrote:
From: Tinh Nguyen
Date: Tue, 7 Feb 2023 12:43:17 +0700
Subject: [PATCH] UsbNetworkPkg: Support rate limitting
Signed-off-by: Tinh Nguyen
Thank you for extending my patch to add the PCD support. The overall
patch appears still to be subs
On 05/02/2023 08:04, Tinh Nguyen via groups.io wrote:
On 1/12/2023 3:36 PM, Richard Ho (何明忠) wrote:
We add this patch in my X86 platform and use the NCM device to test IPV4 PXE
boot from 1330MB ISO file.
No this patch: 35 sec to download 1330M ISO file
Add this patch: 181 sec to download 1330
On 03/02/2023 12:55, Ard Biesheuvel wrote:
Question: as a producer of externally loaded UEFI binaries (e.g.
ipxe.efi): what would I need to do to take advantage of BTI?
I'm assuming:
- enable -mbranch-protection=bti in my builds (easy)
- wait for PE/COFF specification change and then update my
On 03/02/2023 12:10, Ard Biesheuvel wrote:
+[BuildOptions]
+!if $(RUNTIME_BTI_ENABLE) == TRUE
+ GCC:*_*_AARCH64_CC_FLAGS = -mbranch-protection=bti
+!endif
Question: as a producer of externally loaded UEFI binaries (e.g.
ipxe.efi): what would I need to do to take advantage of BTI?
I'm assumi
On 01/02/2023 11:06, Nickle Wang via groups.io wrote:
Thanks for catching this. To prevent the change to data structure, would
you suggest me to create new interface in EFI_HTTP_PROTOCOL and disable
TLS host verify?
Adding an interface to EFI_HTTP_PROTOCOL would also break the ABI by
changing
ould break the ABI by changing the layout of a data
structure defined in the UEFI specification.
Even worse, it does so by inserting a field into the middle of a
structure: an ABI mismatch would result in one side attempting to
dereference the BOOLEAN value as a pointer.
Nacked-by: Michael B
On 25/01/2023 16:55, Gerd Hoffmann wrote:
iasl is a different matter, as we need it to build for arm64 as well.
iasl is already available in the arm64 distros, so as I see it, there
are 3 options here:
- build iasl for Linux/arm64 and add it to the nuget repo
- allow a fallback to system-wide ias
appreciated-by: Michael Brown
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98892): https://edk2.groups.io/g/devel/message/98892
Mute This Topic: https://groups.io/mt/96374972/21656
Group Owner: devel+ow...@edk
On 12/01/2023 17:58, Laszlo Ersek wrote:
The case is that both QEMU and edk2 check for each other's supported
features. It's a complex interwoven feature set with security
impact, which is exactly why we added feature negotiation at every
step -- effectively mutual negotiation wherever necessary
On 12/01/2023 13:22, Laszlo Ersek wrote:
Detect the issue in PlatformMaxCpuCountInitialization(), and
print an error message and *hang* if the issue is present.
Would this mean that OVMF would refuse to start with all current
distro versions of qemu (when not using KVM), or am I
misunderstandin
On 12/01/2023 08:28, Laszlo Ersek wrote:
In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation
protocol is (effectively) broken such that it suggests that switching from
the legacy interface to the modern interface works, but in reality the
switch never happens. The symptom h
On 11/01/2023 07:34, Tinh Nguyen via groups.io wrote:
I have changed the Metronome driver from EmbeddedPkg to MdeModulePkg,
but the performance is still very slow.
Could you please try using the patch from
https://edk2.groups.io/g/devel/message/98256 to see if this fixes the
problem for you?
On 08/12/2022 03:44, RichardHo [何明忠] via groups.io wrote:
+case PXE_OPFLAGS_RECEIVE_FILTER_DISABLE:
+ if (Cdb->CPBsize != PXE_CPBSIZE_NOT_USED) {
+Cdb->StatFlags = PXE_STATFLAGS_COMMAND_FAILED;
+Cdb->StatCode = PXE_STATCODE_INVALID_CDB;
+ }
+
+ Nic->CanReceive
On 09/01/2023 23:50, Michael Brown wrote:
Coincidentally, I have just implemented a fix for this. It works by
implementing a simple credit-based rate limiter. Calls to
UsbEthReceive() are limited to 10 per second while the receive datapath
is idle. No limiting takes place while the receive
1 - 100 of 165 matches
Mail list logo
