Repository navigation
a13: replay immediate IPIs dropped while the destination was busy (port from MakrSas/Inferno) - #58
Merged
Merged
Conversation
…rt from MakrSas/Inferno) apple_a13_deliver_ipi silently drops an immediate fast IPI when the target CPU's one-deep IPI_SR slot is still occupied, and nothing revisits that drop. Deferred and no-wake sends are retried on every IPI_CR tick by apple_a13_cluster_tick, but an immediate send has nowhere else to go. The sender is now recorded per destination (pendingImmediateIPI, one bit per source CPU), and one recorded sender is replayed from apple_a13_ipi_write_sr as soon as the destination acknowledges and frees its slot. In Pyre the IPI registers are ARM_CP_IO, so senders and the acknowledging CPU are already serialized by the BQL, and XNU reads its per-CPU signal word after acknowledging. A coalesced IPI should therefore not lose work for XNU. At worst the replay adds one FIQ that finds nothing to do. MakrSas reported that the drop led to early "Spinlock timeout" panics in iOS 16 boots, and the replay ends that report. Scion issue #51 (the fixed ~3 s restore stall) already ruled out lost fast IPIs, so this is not expected to change it. Ported from MakrSas/Inferno commit 901384f ("a13: recover immediate IPIs dropped while the destination was busy", branch ios), under the same licence as the files it touches. Original author: Makr <ngrom33@gmail.com>. Pyre's trace_apple_a13_ipi_deliver call is kept. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ported from MakrSas/Inferno
iosbranch, commit 901384f ("a13: recover immediate IPIs dropped while the destination was busy"), by Makr. Commit authorship is kept, and Pyre'strace_apple_a13_ipi_delivercall is kept too.What it fixes
apple_a13_deliver_ipidrops an immediate fast IPI when the target's one-deepIPI_SRslot is still occupied. Deferred and no-wake IPIs are retried on every IPI_CR tick, but a dropped immediate IPI is never revisited. The sender is now recorded per destination (pendingImmediateIPI), and one recorded sender is replayed fromapple_a13_ipi_write_srwhen the destination acknowledges.Expected impact (honest version)
In Pyre the IPI registers are
ARM_CP_IO, so they are serialized under the BQL. XNU acknowledgesIPI_SRand only then reads its per-CPU signal word, so a coalesced IPI should not lose work. At worst, the replay costs one extra FIQ that finds nothing to do. MakrSas reported early "Spinlock timeout" panics on iOS 16 boots and says this replay fixed them. Scion-Project/scion#51 already ruled out lost fast IPIs, so this is not expected to fix the ~3 s restore stall. It is cheap hardening.Testing
Android cross build, on the Android emulator. Tested together with #57:
restore_bench.py, iOS 14.0 restore, real SEP,-smp 4): every run reachedwaiting_hostwith no panic. See physmem, dart: flush another CPU's TLB on that CPU (port from MakrSas/Inferno) #57 for the timings.🤖 Generated with Claude Code