Tail chaining breaks preemption level handling

[reosdev]

Explicitly, xepc, xpistatus remain unchanged.

Keeping xpistatus unchanged disables chaining interrupts of different preemption levels:

• xpistatus.pithreshold holds previous context's threshold
• During tail chaining, new interrupt may have different (lower) preemption level
• If pithreshold remains unchanged, it reflects wrong (previous handler's) threshold
• When new handler returns via xret, wrong threshold is restored

This restricts tail chaining to same-preemption-level interrupts only, which is not documented.

[gagachang]

Agree. The spec should support tail chaining by different interrupt priority. I think pithreshold should not be unchanged.

[christian-herber-nxp]

I am not sure I get the issue.
The value of xpistatus.pithreshold should essentially be the value corresponding to the level at the time that XPP, XIE, and XEPC were sampled.

xithreshold is updated when tail-chaining.

Let me know if you still think something is wrong, then we need to construct some examples to dive deeper into the scenarios.

[reosdev]

I am not sure I get the issue.

Please read initial description again.

[christian-herber-nxp]

After reviewing the behavior of Smnip/Ssnip (specifically that xret restores xpistatus.pithreshold and that Smnip/Ssnip update xpistatus only on interrupt entry/exit), the observed behavior is actually correct for tail chaining.

The key point is:
In tail chaining, interrupt B does not preempt interrupt A.
A has already logically completed, and the hardware simply skips A’s xret and jumps directly into B.
This means B’s previous context is the thread, not A.
Therefore xpistatus.pithreshold should remain the thread’s threshold (T0), and B’s xret should restore T0.

Simple example
Thread running
xithreshold = T0

Interrupt A arrives:
xpistatus.pithreshold = T0
xithreshold = prio(A)

A finishes, but before xret, Interrupt B becomes pending → tail chain:

A is considered complete
No xpistatus update
B inherits xpistatus = T0 (correct, since B’s previous context is the thread)

xithreshold = prio(B)
xpistatus.pithreshold = T0

B returns via xret → restores T0 → returns to thread (correct).

So the behavior does not restrict tail chaining to same‑priority interrupts; it simply reflects that tail-chained interrupts always return to the thread, because the interrupted handler (A) was already complete.
Happy to discuss further if you see a case where A must remain resumable after B.

[reosdev]

I understand that this is not trivial, but your logic is incorrect. If interrupt threshold is not updated before each "chaining", then there is the straightforward way to the priority inversion (when lower priority interrupt preempts higher priority). The only thing I can advise (if you do not trust my experience) is to create the functional model and tests.

[christian-herber-nxp]

I understand that this is not trivial, but your logic is incorrect. If interrupt threshold is not updated before each "chaining", then there is the straightforward way to the priority inversion (when lower priority interrupt preempts higher priority). The only thing I can advise (if you do not trust my experience) is to create the functional model and tests.

interrupt threshold is updated each chaining in the form of xithreshold.
I am trying to understand your point, but I cannot see it. Telling me to read your fairly brief explanation for a complex problem again does not help. This is why I tried to lay out in a lot of detailed how I view the tail-chaining.

If your proposed solution is to update xpistatus.pithreshold to I guess the xithreshold of the interrupt handler at the start of the chain, you would have the wrong threshold when returning to the thread.

[reosdev]

Let's start form simple things: #763

I cannot provide better explanation or propose something for this issue as the terminology used over the specification is quite confusing. Relatively simple things must be fixed first.