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 arbitrary length of time, because
the call to RestoreTPL() can end up calling an application callback
which in turn waits on further timer interrupts.
This is a legitimate use case within UEFI, so all timer interrupt
handlers (not just in virtual machines) need to allow for the
possibility that nested interrupts will occur.
So on OVMF we will continue to need NestedInterruptTplLib. I like the
idea to have a Null version of the library, so OVMF does not need its
own version of the driver just because of NestedInterruptTplLib.
I agree that there should not need to be two versions of LocalApicTimerDxe.
I would suggest moving NestedInterruptTplLib from OvmfPkg to MdeModulePkg.
The code is complex, but for the caller the complexity is completely
hidden behind the calls to NestedInterruptRaiseTPL() and
NestedInterruptRestoreTPL(), which straightforwardly replace what would
otherwise be (unsafe) calls to RaiseTPL() and RestoreTPL(), as shown in
https://github.com/tianocore/edk2/commit/a086f4a#diff-1418ec21e24e4ce2f3d621113585e3bea11fbcfa3b77d54046e61be7928e0c92
For a new CPU architecture, the only requirement is to provide a short
fragment (~5 lines) of code that can clear the interrupts-enabled flag
in the EFI_SYSTEM_CONTEXT, as shown in
OvmfPkg/Library/NestedInterruptTplLib/Iret.c.
I'm happy to send a patch to migrate NestedInterruptTplLib to
MdeModulePkg, so that it can be consumed outside of OvmfPkg. Shall I do
this?
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113883): https://edk2.groups.io/g/devel/message/113883
Mute This Topic: https://groups.io/mt/103734961/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
