[RFC v2 PATCH 0/2] Introduce irqchip and VIRQ layer prototypes

[Anup Patel]

On Sat, Feb 7, 2026 at 9:41 PM Raymond Mao <raymondmaoca at gmail.com> wrote:
>
> Hi Anup,
>
> On Sat, Feb 7, 2026 at 5:08 AM Anup Patel <anup at brainfault.org> wrote:
> >
> > On Mon, Feb 2, 2026 at 8:32 PM Raymond Mao <raymondmaoca at gmail.com> wrote:
> > >
> > > From: Raymond Mao <raymond.mao at riscstar.com>
> > >
> > > This RFC introduces irqchip abstraction and VIRQ layers for APLIC
> > > wired interrupt support in OpenSBI.
> > >
> > > In the current OpenSBI implementation, APLIC support primarily focuses
> > > on initialization and delegation, while external interrupt handling
> > > for wired interrupts remains largely stubbed. As a result:
> > > - There is no generic mechanism for OpenSBI drivers or platforms to
> > >   register handlers for wired interrupt lines.
> > > - Interrupt dispatch remains tightly coupled to specific irqchip
> > >   implementations.
> > >
> > > The goal is to introduce a small, extensible abstraction for irqchip
> > > to hide the HW details and provide abstract operations like interrupt
> > > provider registration, claim/complete/mask/unmask operations.
> >
> > We don't need claim() and complete() callbacks instead single eoi()
> > callback is sufficient because the APLIC driver will have to anyway
> > read the CLAIM register to get the hardware irq number.
> >
>
> The abstraction is not only for APLIC and is flexible for other
> interrupt controllers, that is the reason we have claim/complete as
> general interfaces.

The claim/complete terminology is very specific to PLIC even though
we can retrofit it for APLIC and IMSIC. Instead a simple eoi() callback
(just like kernel) is sufficient.

>
> > >
> > > VIRQ (Virtual IRQ) layer is on top of INTC, providing IRQ state
> > > management via per-(domain,hart) IRQ pending queue, with courier
> > > dispatching and interface to enqueue/pop/complete an IRQ and map hwirq
> > > to virtual IRQ number to avoid exposure of hwirq.
> >
> > Thinking about this more, a separate VIRQ layer will consume
> > quite a bit of memory for managing the virtual IRQ space.
> >
> > Instead of a VIRQ layer, each irqchip having its own HWIRQ space
> > is much more flexible and scalable. I spent past 2 days trying to
> > come-up with this abstraction which I will post in a few minutes.
> >
> > I hope this will save time in reviews.
> >
>
> Do you plan to have the queue management in irqchip?

The interrupt pending queue management for domains must not
be part of the sbi_irqchip framework. The sbi_irqchip only focuses
on managing host interrupts and providing a well defined API for
host irqchip drivers. The series which I posted does exactly that.

> My original idea is to keep irqchip as a HAL and as minimal as it
> could be, and put other higher level logics (e.g. per-(domain,hart)
> IRQ pending queue management) as a higher layer on top of irqchip.
> Once you send your proposal I can check how to combine the ideas.

At a high-level, we have are three parts:

1) sbi_irqchip framework for managing host interrupts
2) Host irqchip drivers (such as APLIC, IMSIC, PLIC, etc)
    which use the sbi_irqchip framework APIs
3) Per-domain paravirt or trap-n-emulated irqchip which is
    instantiated based on domain configuration in the DeviceTree

The per-domain paravirt or trap-n-emulated irqchip (#3 above) will
be responsible for routing host interrupts to the domain it is associated
with. The per-domain paravirt or trap-n-emulated irqchip will register
handlers for host interrupts and route them as domain interrupts to
the domain and also maintain data structures to track pending interrupts.

Regards,
Anup