Major and external interrupts unification

[evgeniy-paltsev]

This PR unifies major and external interrupts by forwarding all major interrupts to ACLIC when the ACLIC mode is selected. The additional technical details and discussion can be found in the #605 issue.

Fixes: #605

[mark-honman]

On the face of it this PR appears to remove vectoring of the minor interrupts, while retaining the minor interrupt concept which is foundational to AIA. This does not make sense.

[evgeniy-paltsev]

Hi @mark-honman,
thanks for the feedback!

I've updated the document description to clarify the proposed modification (specifically, the Major interrupt redirection to ACLIC chapter).

Since this PR unifies major and external interrupts, it also simplifies several related areas, such as:

• keeping a single interrupt vector table (instead of separate major and external IVTs)
• using one threshold register (rather than separate ones for external and all interrupts)
• simplifying the tpush instruction

hence, there are several changes in other chapters as well.

[christian-herber-nxp]

CLINT is not really a thing in the world of RISC-V standards

[christian-herber-nxp]

high level comment: I can see small benefits on HW side, while I do also concern about SW (suddenly, and OS kernel will rely on a driver for external interrupt controller to be able to e.g. set the SW interrupt).
This should be traded off against simply restricting the vectoring to the external interrupts - in my considerations, HW-vectoring is not important for major identities.

[jackwdandrew]

This PR was presented by Evgenii to Fast Interrupts TG on 29th September 2025.

@evgeniy-paltsev, could you attach the slides?

[christian-herber-nxp]

was there any input from the TG?
Is there support other than Synopsys for this?

[christian-herber-nxp]

what is the layout of the unified vector table? First 64 entries reserved for major interrupts? Platform defined?

[evgeniy-paltsev]

This PR was presented by Evgenii to Fast Interrupts TG on 29th September 2025.
@evgeniy-paltsev, could you attach the slides?

In addition to sharing the slides via the tech-fast-int mailing list, I'm attaching them here as well.
Interrupts unification proposal.pdf

[evgeniy-paltsev]

Hi @christian-herber-nxp,

This should be traded off against simply restricting the vectoring to the external interrupts - in my considerations, HW-vectoring is not important for major identities.

Could you clarify this a bit? Am I correct in understanding that you're suggesting a single entry point for all major interrupts?

I do also concern about SW (suddenly, and OS kernel will rely on a driver for external interrupt controller to be able to e.g. set the SW interrupt).

I'm not sure I fully follow your concern here. If the new HW features aren't used, then no SW changes are needed. But if they are used (e.g., interrupt nesting), then naturally the SW must be updated to support them.

[christian-herber-nxp]

This should be traded off against simply restricting the vectoring to the external interrupts - in my considerations, HW-vectoring is not important for major identities.

Could you clarify this a bit? Am I correct in understanding that you're suggesting a single entry point for all major interrupts?

Yes. This was previously floated by Mark and makes a ton of sense.

I do also concern about SW (suddenly, and OS kernel will rely on a driver for external interrupt controller to be able to e.g. set the SW interrupt).

I'm not sure I fully follow your concern here. If the new HW features aren't used, then no SW changes are needed. But if they are used (e.g., interrupt nesting), then naturally the SW must be updated to support them.

Everything CAN be supported in SW - so is the nature of software. But for maintenance, quality, ramp-up purposes it is preferable to have architecture support that is not full of ifdefs for different flavors of the architecture. A new feature is a new feature and needs additional code to be supported.
Making major interrupts external is not really a feature by itself, it is just changing existing behavior to have a slightly more efficient HW implementation. Still, it will need additional ifdef-else macros in the base port of risc-v and the ability to redirect e.g. writes to the pending bit of a SW interrupt to either the traditional bit, or a bit managed by the external interrupt controller, which will be modelled as a device driver rather than be considered part of the core.
It can be done, of course, but the question is if the benefit is worth it.

[evgeniy-paltsev]

what is the layout of the unified vector table? First 64 entries reserved for major interrupts? Platform defined?

Entry 0 - pointer to exception handler
Entries 1...N - pointers to interrupt handlers, where each index corresponds to the interrupt identity number

The major interrupts retain their original identity numbers, so their positions in the vector table are fixed. The remaining identity numbers (those not assigned to implemented major interrupts) are available for use by external interrupts.
There's no requirement for platforms to reserve the first 64 entries (or any specific range) for major interrupts, though they are free to do so if desired.

[evgeniy-paltsev]

managed by the external interrupt controller, which will be modelled as a device driver rather than be considered part of the core.

It doesn't really matter if we call it device driver or not. I.e. in Zephyr we have even a 'clint' interrupts as a driver and not in arch/riscv/core - does it really change anything?

Making major interrupts external is not really a feature by itself, it is just changing existing behavior to have a slightly more efficient HW implementation. Still, it will need additional ifdef-else macros in the base port of risc-v and the ability to redirect e.g. writes to the pending bit of a SW interrupt to either the traditional bit, or a bit managed by the external interrupt controller, which will be modelled as a device driver rather than be considered part of the core.

Interrupt unification is not a standalone extension - it's part of the nesting and vectoring mechanism designed to enable low-latency interrupt handling.

Supporting low-latency interrupts in the OS requires substantial software changes - from trap handlers modifications (regardless of whether tpush/tpop or manual context save/restore is used) and IVT layout adjustments to updates to interrupt lock/unlock logic and changes to task switching implementation.
That's a much broader scope compared to the interrupt configuration interface we are talking about.

e.g. writes to the pending bit of a SW interrupt to either the traditional bit, or a bit managed by the external interrupt controller

By the way, in your example, no software changes are required - since the SW interrupt is an MMIO device, its pending bit is set and cleared via MMIO.

[evgeniy-paltsev]

Could you clarify this a bit? Am I correct in understanding that you're suggesting a single entry point for all major interrupts?

Yes. This was previously floated by Mark and makes a ton of sense.

It may work for specific use cases, but it's not suitable as a general solution.

Even with just two standard major interrupts (timer and SW), there's a clear counterexample: if we want to implement task switching similar to ARM's NVIC model in Zephyr (with the task context switch happens in the SW interrupt handler) we wouldn't want to share the SW interrupt vector with the timer.

And such limitations are easily avoidable, since interrupt unification provides a straightforward way to support vectoring for all interrupts.

[christian-herber-nxp]

Even with just two standard major interrupts (timer and SW), there's a clear counterexample: if we want to implement task switching similar to ARM's NVIC model in Zephyr (with the task context switch happens in the SW interrupt handler) we wouldn't want to share the SW interrupt vector with the timer.

The difference would be marginal. In the context of an entire context switch, selecting between two possible interrupt sources is nothing.
At the same time, I believe in Zephyr it would be a must to go though the common isr handler.

[christian-herber-nxp]

By the way, in your example, no software changes are required - since the SW interrupt is an MMIO device, its pending bit is set and cleared via MMIO.

How it is set is platform defined. How it is cleared is standardized and this is via the mip/sip bit.

[reosdev]

Making major interrupts external is not really a feature by itself, it is just changing existing behavior to have a slightly more efficient HW implementation. Still, it will need additional ifdef-else macros in the base port of risc-v and the ability to redirect e.g. writes to the pending bit of a SW interrupt to either the traditional bit, or a bit managed by the external interrupt controller, which will be modelled as a device driver rather than be considered part of the core.
It can be done, of course, but the question is if the benefit is worth it.

The discussion about accessing the pending bit for particular source looks strange considering the fact that in case of nested vectored interrupt entire OS kernel implementation is in separate source tree (see the Arm's Zephyr ports). RISC-V at the moment has no support for nested vectored interrupts, so the whole branch is vacant.

In such case it is better (portability, maintainability, etc.) to unify the way of interrupt handling (including access to pending bits) for all interrupts.