riscv aia support

[sbutz]

• Support APLIC in direct delivery mode (replacement for legacy PLIC)
• Support APLIC in msi delivery mode (includes IMSIC Support)
• Use MSIs to send IPI without trapping to m-mode
• Support MSI for PCI devices (PCI support is added with feat(riscv64): Add PCI support #2550)

[sbutz]

@mkroening should an application binary support PLIC, APLIC (direct delivery mode) and APLIC+IMSIC (msi delivery mode) or should we add a feature flag(s) for aia support?

[mkroening]

Good question! On x86-64, we went for a featureless introduction of MSI-X in #2101. That's because MSI-X is always faster and always preferred. Eventually, we would like to fade out non-MSI-X support on x86-64.

I am not too familiar with the situation on RISC-V. Is PLIC still the main way to do interrupts, or is APLIC or APLIC+IMSIC clearly the modern solution?

Are they compatible with each other? On x86-64 a given single system can support both legacy interrupts and MSI-X at the same time. If they are mutually exclusive, then features would make sense for sure.

Which feature names and documentation would you have in mind?

[sbutz]

The spec allows to have systems which have an PLIC and an APLIC.
Each core can only receive interrupts from one of them.
So having PLIC and APLIC in one system implies heterogenous cores. So asymmetric multi processing.
IMHO it's unlikely we'll see such a configuration. Especially in virtualized environments.
Furthermore RustyHermit does not support AMP.
I'd save we can use feature flags instead of runtime support for both.

Before i propose a set of feature flags, i'd like to extend the scope of this question a bit.
RISC-V is modular architecture. The base ISA has a very limited set of registers and instructions.
Extensions add additional features. E.g. A (Atomic Instructions), F (Floating Point Operations), Zkr (Seed Register), ...
How should RustyHermit handle this.
Detecting extensions at runtime via devicetree is possible, but cumbersome and might impact performance.
Adding feature flags for every extension make configuration complicated.
The RISC-V community faced a similar problem. The modular architecture, lead to a lot of fragmentation.
The solution: Profiles. Profiles bundle a set of mandatory extension. The most prominent is RVA23.
Ubuntu 25.x and forward only run on RVA23 compliant hardware.
We can use a similar approach. Introduce fine granular feature flags when suitable, and offer higher level feature flags which represent RISC-V profiles and enable a set of fine granular feature flags.

All the below options are orthogonal.
E.g. we could introduce arch agnostic feature flags which then enable arch specific feature flags.

Option 1: Drop support for PLIC
Legacy. Ubuntu 25.x and forward require RVA23 profile. RVA23 strong recommends AIA.

Option 2: Arch specific feature flags
Granularity can be discussed and depends on the general handling of RISC-V extensions.
A) Fine granular:

[features]
default = [
    riscv-aia-imsic,
    ...
]

# Enables the driver for legacy platform level interrupt controller
# 
# The is only useful on riscv64.
riscv-plic = []

# Enables driver for advances platform level interrupt controller.
# 
# APLIC will be used in direct mode unless riscv-aia-imsic is set.
# The is only useful on riscv64
riscv-aia-aplic = []

# Enables driver for incoming message signaled interrupt controller.
# 
# If riscv-aia-aplic is set and an IMSIC is present, APLIC will be used in msi delivery mode.
# The is only useful on riscv64
riscv-aia-imsic = []

B) Coarse granular:

# Enables driver for advanced interrupt architecture (APLIC, IMSIC).
# 
# The is only useful on riscv64
riscv-aia = []

Option 3: Arch agnostic feature flags
As a user of rusty hermit i'd care more about features than architecture specific implementations.
Examples: pci, virtio-net, msi, ...
Downside: If msi is not set, we still need a flag to select from PLIC and APLIC.

I recommend Option 2B.