RFC: initial support for RISC-V Advanced Interrupt Architecture

[tagunil]

Introduction

Problem description

There are use cases for running Zephyr on bigger RISC-V SoCs which implement the Advanced Interrupt Architecture (https://github.com/riscv/riscv-aia). However, supporting it like Linux does, as a three-level interrupt controller hierarchy, is problematic due to the current state of the interrupt controller infrastructure in Zephyr.

Proposed change

The idea is to create a combined AIA driver handling both L2 (IMSICs) and L3 (APLIC) in a single instance and presenting them to Zephyr as a single L2 interrupt controller, just like PLIC. This will allow us to have a decent support for the SoCs in question, until we have the infrastructure ready for a better implementation.

Detailed RFC

Proposed change (Detailed)

The interrupt handling infrastructure in Zephyr nowadays is pretty much ad-hoc and arch-specific, making it much harder to represent interrupt controller hierarchies like AIA. In addition to that, a fully featured AIA implementation will require some kind of general-purpose MSI support, but the existing MSI support in Zephyr is PCIe-specific and, probably, x86-specific.

We propose to create a single driver (intc_aia or something similar) that will hide the implementation details from the rest of Zephyr, such as:

• AIA hierarchy (APLIC-only vs APLIC+IMSICs)
• Delivery mode (direct vs MSI)
• MSI configuration

Internally, such a driver could be subdivided into an APLIC part and an IMSIC part, but for Zephyr it should present a simple PLIC-like interface, suitable for integration into the existing privileged RISC-V interrupt handling.

We do not consider the described approach as the final one. Instead, we propose it as a first step towards the fully featured AIA support. This approach will allow us to bring up the upcoming RISC-V SoCs with a decent level of interrupt support (wired IRQs for peripherals) without changing too much in the underlying infrastructure. In the future the proposed driver should be reworked into two separate drivers: one for APLIC and one for IMSIC.

Dependencies

We need to call the driver from the privileged RISC-V common code just like the PLIC one is called right now.

Concerns and Unresolved Questions

It's still unclear how to represent the AIA hierarchy in a devicetree. The options are:

• One single node, like PLIC (simpler, but Zephyr-specific and not future-proof)
• Two separate nodes, like Linux does (one for APLIC, one for all IMSICs)
• More nodes (for example, one for APLIC and one per each IMSIC)

Alternatives

The alternative is:

• Wait until drivers: Add interrupt controller API #66505 or something similar is merged
• Then implement a general-purpose MSI infrastructure
• Then create a proper, multi-level implementation of AIA

[abrodkin]

@cfriedt @ycsin @npitre please chime in and comment. We'd like to get some feedback and hopefully some agreement before jumping to the implementation work.

[cfriedt]

#80614 adds basic ACLINT support as well.

[cfriedt]

We've known for some time that Zephyr's multi-level interrupt architecture doesn't scale as well as other architectures (like cascaded / chained interrupts), it's just a massive undertaking to rework that. I don't think it makes sense to sharpen the machetes just to add support for RISC-V AIA. In other words, I don't think we should need to move a mountain to add initial support for RISC-V AIA.

Any new intc API should be an uplift for all architectures. We do support a lot of tiny systems though, and in many cases those systems do not need an elaborate interrupt architecture, so hopefully we can still scale down after scaling up.

To me, the proposed solution sounds reasonable in the interim until Zephyr has a more sophisticated interrupt controller API.

[evgeniy-paltsev]

@cfriedt

#80614 adds basic ACLINT support as well.

Just note that ACLINT (despite its name) doesn't belong to RISC-V Advanced Interrupt Architecture

[ycsin]

To me, the proposed solution sounds reasonable in the interim until Zephyr has a more sophisticated interrupt controller API.

+1

It is apparent that the interrupt controller situation in Zephyr is pretty ad-hoc and desperately needs a revamp, but the amount of effort involved is going to be tremendous as the solution has to be designed with flexibility in mind and encompasses all existing features, while very likely affects everything (drivers, archs) that has something to do with interrupt. So until someone / some companies are willing to take up the challenge, I guess we will have to march forward with what we have today, knowing fully that we will be paying for this tech debt in the future.

cc @andyross @bjarki-andreasen

[AFOliveira]

I have a PR to address this RFC. Waiting for #97598 and #97560 to be merged so I can leverage them to upstream AIA.