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

Raymond Mao raymondmaoca at gmail.com
Sat Feb 7 08:11:34 PST 2026


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.

> >
> > 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?
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.

Regards,
Raymond

> >
> > Raymond Mao (2):
> >   lib: sbi: introduce abstraction for wired interrupt handling
> >   lib: sbi: Add VIRQ interrupt abstraction
> >
> > Changes in v2:
> > - Move INTC to irqchip
> > - Move hwirq mapping to VIRQ
> > - Remove get_caps and pass in max_src during provider registration
> > - All irqchip interface use hwirq as parameter
> >
> >  include/sbi/sbi_irqchip.h | 52 ++++++++++++++++++++++
> >  include/sbi/sbi_virq.h    | 90 +++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 142 insertions(+)
> >  create mode 100644 include/sbi/sbi_virq.h
> >
> > --
> > 2.25.1
> >
> >
> > --
> > opensbi mailing list
> > opensbi at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/opensbi
>
> Regards,
> Anup



More information about the opensbi mailing list