Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

["Michael Brown" <mcb30@ipxe.org>]

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 (or even impossible?) on physical hardware.
> 
> ... Oh, scratch that. "Interrupt storm" simply means that interrupts are
> being delivered at a rate higher than the handler routine can service
> them. IOW, the "storm" is not that interrupts are delivered *very
> rapidly* in an absoulte sense. If interrupts are delivered at normal
> frequency, but the handler is too slow to service *even that rate*, then
> that also qualifies as "storm", because the nesting depth will *keep
> growing*. It's not really the growth rate that matters; what matter is
> the *trend*, i.e., the fact that there *is* growth (the stack gets
> deeper and deeper). The stack might not overflow immediately, and if the
> handler speeds up (for whatever reason), the stack might recover, but
> there is nothing to prevent an overflow.
> 
> So, in the end, I think you've convinced me.

:)

>> 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?
> 
> Sounds like a valid idea to me.
> 
> Could be greatly supported by a test case (to be run on the bare metal)
> installing a slow handler that *eventually* exhausted the stack, when
> not using NestedInterruptTplLib.
> 
> (FWIW, IIRC, the UEFI spec warns about this -- it says something like,
> "return from TPL_HIGH as soon as you can, otherwise the system will
> become unstable".)
> 
> Sorry for the wall of text, I find this very difficult to reason about.

I also find it very difficult to reason about, which is why 
NestedInterruptRestoreTpl() has 126 lines of comments providing a 
semi-formal proof of correctness for a mere 15 statements of C code!

In particular, I find it difficult to reason about when it would be safe 
for a platform to *not* use NestedInterruptTplLib.  It's clearly 
empirically difficult to trigger stack underflow via an interrupt 
"storm" on physical hardware, but I'm not convinced it's impossible.

I find it mentally easier to rely on the hard guarantee that 
NestedInterruptTplLib provides: that nested interrupts will continue to 
be delivered but that the number of interrupt-induced stack frames is 
bounded by the (small, finite) number of distinct TPL levels in existence.



While developing NestedInterruptTplLib, I did hack together a test case 
for a slow handler that would deliberately induce an interrupt storm, 
since I needed this to test that my code was working.  When triggered, 
this test would cause the machine to effectively hang due to servicing 
an endless storm of timer interrupts.  Before NestedInterruptTplLib, the 
stack would soon underflow and would typically cause a reboot (or other 
crash).  With NestedInterruptTplLib the machine would continue to 
service interrupts indefinitely.

How might such a test case be included in upstream EDK2?  I'm 
peripherally aware of EDK2 test infrastructure such as UEFI SCT, but 
I've never interacted with it yet.

Thanks,

Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113908): https://edk2.groups.io/g/devel/message/113908
Mute This Topic: https://groups.io/mt/103734961/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-