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

[Anup Patel]

On Mon, Feb 9, 2026 at 12:20 AM Raymond Mao <raymondmaoca at gmail.com> wrote:
>
> Hi Anup,
>
> On Sun, Feb 8, 2026 at 8:24 AM Anup Patel <anup at brainfault.org> wrote:
> >
> > 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.
> >
>
> I see. I can rename claim() to eoi() and remove the complete() from v3
> - keep all ops as members of sbi_irqchip_device, so that we can wrap
> RP016-M2 up.
>
> > >
> > > > >
> > > > > 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.
> >
>
> For RP016-M3 development, I still have a couple of questions on your
> new proposal - which interface now can provide the virtual IRQ number
> if the mapping is not saved in the static memory? - The

The series which I posted is an alternate approach where each host
interrupt is identified by a pair (pointer to irqchip, hwirq). This is much
simpler compared to maintaining virtual IRQ number space where each
virq maps to a hwirq of an irqchip.

> enqueue/dequeue implementation now is using the virtual IRQ number as
> an argument. Secondly, which data structure do you prefer the
> "per-(domain,hart) queue" to be integrated into?

The data structure used to track pending interrupt for per-domain
paravirt or trap-n-emulated irqchip depends on the type of irqchip.

Regards,
Anup