On 23/01/2024 15:51, Ard Biesheuvel wrote:
On Tue, 23 Jan 2024 at 16:31, Michael Brown <mc...@ipxe.org> 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
(matching the behaviour of DisableInterrupts(), which also sets both
flags).
Thanks for this.
You can drop the FIQ bits, though: anything that can run Tianocore
will have the FIQs routed to the secure world, and all of the higher
level en/disable interrupt code only reasons about the IRQ line.
Thank you.
My commit message was incorrect, sorry: DisableInterrupts() in MdePkg
does indeed disable only IRQs. I was accidentally looking at
ArmDisableInterrupts() in ArmPkg, which disables both IRQs and FIQs.
My (incomplete) understanding of Arm behaviour is that when an interrupt
is raised, both IRQs and FIQs will be disabled by hardware. When the
interrupt handler ends up enabling interrupts during RestoreTPL(), only
the IRQs will be re-enabled since EnableInterrupts() touches only the
IRQ bit. This state can persist for an extended period of time (e.g. 30
seconds) if a callback at TPL_CALLBACK ends up waiting for further timer
events.
Q1: Is it a problem to have this situation, with FIQs disabled for an
extended period of time?
Q2: What happens with FIQs when there is no secure world (e.g. using
ArmVirtQemu with "-M virt")?
Q3: Would you like me to add in the extra patch that modifies TimerDxe
to use NestedInterruptTplLib?
Many thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114217): https://edk2.groups.io/g/devel/message/114217
Mute This Topic: https://groups.io/mt/103911611/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
