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

[Raymond Mao]

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

Thanks.
Regards,
Raymond

> Regards,
> Anup