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

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

[Raymond Mao]

From: Raymond Mao <raymond.mao@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.

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.

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

[PATCH v2 1/2] lib: sbi: introduce abstraction for wired interrupt handling

[Raymond Mao]

From: Raymond Mao <raymond.mao@riscstar.com>

Add wired interrupt handling abstraction into irqchip.
This introduces a small provider interface based on
claim/complete/mask/unmak semantics, allowing to register a wired
interrupt controller as a provider.

Signed-off-by: Raymond Mao <raymond.mao@riscstar.com>
---
 include/sbi/sbi_irqchip.h | 52 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/include/sbi/sbi_irqchip.h b/include/sbi/sbi_irqchip.h
index e0ae12f5..27b88765 100644
--- a/include/sbi/sbi_irqchip.h
+++ b/include/sbi/sbi_irqchip.h
@@ -27,6 +27,38 @@ struct sbi_irqchip_device {
 	int (*irq_handle)(void);
 };
 
+/* Handler for a specified hwirq */
+typedef int (*sbi_irqchip_irq_handler_t)(void *priv);
+
+/* Provider operations */
+struct sbi_irqchip_provider_ops {
+	/*
+	 * Claim a pending wired interrupt on current hart.
+	 * Returns:
+	 *   SBI_OK      : *hwirq is valid
+	 *   SBI_ENOENT  : no pending wired interrupt
+	 *   <0          : error
+	 */
+	int (*claim)(void *ctx, u32 *hwirq);
+
+	/*
+	 * Complete/acknowledge a previously claimed wired interrupt
+	 * (if required by HW).
+	 * Some HW may not require an explicit completion.
+	 */
+	void (*complete)(void *ctx, u32 hwirq);
+
+	/*
+	 * mask/unmask a wired interrupt line.
+	 *
+	 * These are required for reliable couriering of level-triggered device
+	 * interrupts to S-mode: mask in M-mode before enqueueing, and unmask
+	 * after S-mode has cleared the device interrupt source.
+	 */
+	void (*mask)(void *ctx, u32 hwirq);
+	void (*unmask)(void *ctx, u32 hwirq);
+};
+
 /**
  * Process external interrupts
  *
@@ -46,4 +78,24 @@ int sbi_irqchip_init(struct sbi_scratch *scratch, bool cold_boot);
 /** Exit interrupt controllers */
 void sbi_irqchip_exit(struct sbi_scratch *scratch);
 
+/*
+ * Register the active wired interrupt provider.
+ * - max_hwirq specifies the highest valid hwirq ID.
+ */
+int sbi_irqchip_register_provider(const struct sbi_irqchip_provider_ops *ops,
+				  void *ctx, u32 max_hwirq);
+
+u32 sbi_irqchip_get_max_src(void);
+
+/* Set/clear handler for a specified hwirq */
+int sbi_irqchip_set_handler(u32 hwirq, sbi_irqchip_irq_handler_t handler,
+			    void *priv);
+int sbi_irqchip_clear_handler(u32 hwirq);
+
+void sbi_irqchip_mask_irq(u32 hwirq);
+void sbi_irqchip_unmask_irq(u32 hwirq);
+
+/* external interrupt handler (irqchip device hook) */
+int sbi_irqchip_handle_external_irq(void);
+
 #endif
-- 
2.25.1


-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

Re: [PATCH v2 1/2] lib: sbi: introduce abstraction for wired interrupt handling

[Anup Patel]

On Mon, Feb 2, 2026 at 8:32 PM Raymond Mao <raymondmaoca@gmail.com> wrote:
>
> From: Raymond Mao <raymond.mao@riscstar.com>
>
> Add wired interrupt handling abstraction into irqchip.
> This introduces a small provider interface based on
> claim/complete/mask/unmak semantics, allowing to register a wired
> interrupt controller as a provider.
>
> Signed-off-by: Raymond Mao <raymond.mao@riscstar.com>
> ---
>  include/sbi/sbi_irqchip.h | 52 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
>
> diff --git a/include/sbi/sbi_irqchip.h b/include/sbi/sbi_irqchip.h
> index e0ae12f5..27b88765 100644
> --- a/include/sbi/sbi_irqchip.h
> +++ b/include/sbi/sbi_irqchip.h
> @@ -27,6 +27,38 @@ struct sbi_irqchip_device {
>         int (*irq_handle)(void);
>  };
>
> +/* Handler for a specified hwirq */
> +typedef int (*sbi_irqchip_irq_handler_t)(void *priv);
> +
> +/* Provider operations */
> +struct sbi_irqchip_provider_ops {
> +       /*
> +        * Claim a pending wired interrupt on current hart.
> +        * Returns:
> +        *   SBI_OK      : *hwirq is valid
> +        *   SBI_ENOENT  : no pending wired interrupt
> +        *   <0          : error
> +        */
> +       int (*claim)(void *ctx, u32 *hwirq);
> +
> +       /*
> +        * Complete/acknowledge a previously claimed wired interrupt
> +        * (if required by HW).
> +        * Some HW may not require an explicit completion.
> +        */
> +       void (*complete)(void *ctx, u32 hwirq);
> +
> +       /*
> +        * mask/unmask a wired interrupt line.
> +        *
> +        * These are required for reliable couriering of level-triggered device
> +        * interrupts to S-mode: mask in M-mode before enqueueing, and unmask
> +        * after S-mode has cleared the device interrupt source.
> +        */
> +       void (*mask)(void *ctx, u32 hwirq);
> +       void (*unmask)(void *ctx, u32 hwirq);
> +};
> +
>  /**
>   * Process external interrupts
>   *
> @@ -46,4 +78,24 @@ int sbi_irqchip_init(struct sbi_scratch *scratch, bool cold_boot);
>  /** Exit interrupt controllers */
>  void sbi_irqchip_exit(struct sbi_scratch *scratch);
>
> +/*
> + * Register the active wired interrupt provider.
> + * - max_hwirq specifies the highest valid hwirq ID.
> + */
> +int sbi_irqchip_register_provider(const struct sbi_irqchip_provider_ops *ops,
> +                                 void *ctx, u32 max_hwirq);
> +
> +u32 sbi_irqchip_get_max_src(void);
> +
> +/* Set/clear handler for a specified hwirq */
> +int sbi_irqchip_set_handler(u32 hwirq, sbi_irqchip_irq_handler_t handler,
> +                           void *priv);
> +int sbi_irqchip_clear_handler(u32 hwirq);
> +
> +void sbi_irqchip_mask_irq(u32 hwirq);
> +void sbi_irqchip_unmask_irq(u32 hwirq);
> +
> +/* external interrupt handler (irqchip device hook) */
> +int sbi_irqchip_handle_external_irq(void);
> +

I did not mean renaming and moving stuff to sbi_irqchip.h
instead, my expectation was to use struct sbi_irqchip_device
as the abstraction for the interrupt controller.

Regards,
Anup

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

Re: [PATCH v2 1/2] lib: sbi: introduce abstraction for wired interrupt handling

[Raymond Mao]

Hi Anup,

On Sat, Feb 7, 2026 at 5:10 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Mon, Feb 2, 2026 at 8:32 PM Raymond Mao <raymondmaoca@gmail.com> wrote:
> >
> > From: Raymond Mao <raymond.mao@riscstar.com>
> >
> > Add wired interrupt handling abstraction into irqchip.
> > This introduces a small provider interface based on
> > claim/complete/mask/unmak semantics, allowing to register a wired
> > interrupt controller as a provider.
> >
> > Signed-off-by: Raymond Mao <raymond.mao@riscstar.com>
> > ---
> >  include/sbi/sbi_irqchip.h | 52 +++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 52 insertions(+)
> >
> > diff --git a/include/sbi/sbi_irqchip.h b/include/sbi/sbi_irqchip.h
> > index e0ae12f5..27b88765 100644
> > --- a/include/sbi/sbi_irqchip.h
> > +++ b/include/sbi/sbi_irqchip.h
> > @@ -27,6 +27,38 @@ struct sbi_irqchip_device {
> >         int (*irq_handle)(void);
> >  };
> >
> > +/* Handler for a specified hwirq */
> > +typedef int (*sbi_irqchip_irq_handler_t)(void *priv);
> > +
> > +/* Provider operations */
> > +struct sbi_irqchip_provider_ops {
> > +       /*
> > +        * Claim a pending wired interrupt on current hart.
> > +        * Returns:
> > +        *   SBI_OK      : *hwirq is valid
> > +        *   SBI_ENOENT  : no pending wired interrupt
> > +        *   <0          : error
> > +        */
> > +       int (*claim)(void *ctx, u32 *hwirq);
> > +
> > +       /*
> > +        * Complete/acknowledge a previously claimed wired interrupt
> > +        * (if required by HW).
> > +        * Some HW may not require an explicit completion.
> > +        */
> > +       void (*complete)(void *ctx, u32 hwirq);
> > +
> > +       /*
> > +        * mask/unmask a wired interrupt line.
> > +        *
> > +        * These are required for reliable couriering of level-triggered device
> > +        * interrupts to S-mode: mask in M-mode before enqueueing, and unmask
> > +        * after S-mode has cleared the device interrupt source.
> > +        */
> > +       void (*mask)(void *ctx, u32 hwirq);
> > +       void (*unmask)(void *ctx, u32 hwirq);
> > +};
> > +
> >  /**
> >   * Process external interrupts
> >   *
> > @@ -46,4 +78,24 @@ int sbi_irqchip_init(struct sbi_scratch *scratch, bool cold_boot);
> >  /** Exit interrupt controllers */
> >  void sbi_irqchip_exit(struct sbi_scratch *scratch);
> >
> > +/*
> > + * Register the active wired interrupt provider.
> > + * - max_hwirq specifies the highest valid hwirq ID.
> > + */
> > +int sbi_irqchip_register_provider(const struct sbi_irqchip_provider_ops *ops,
> > +                                 void *ctx, u32 max_hwirq);
> > +
> > +u32 sbi_irqchip_get_max_src(void);
> > +
> > +/* Set/clear handler for a specified hwirq */
> > +int sbi_irqchip_set_handler(u32 hwirq, sbi_irqchip_irq_handler_t handler,
> > +                           void *priv);
> > +int sbi_irqchip_clear_handler(u32 hwirq);
> > +
> > +void sbi_irqchip_mask_irq(u32 hwirq);
> > +void sbi_irqchip_unmask_irq(u32 hwirq);
> > +
> > +/* external interrupt handler (irqchip device hook) */
> > +int sbi_irqchip_handle_external_irq(void);
> > +
>
> I did not mean renaming and moving stuff to sbi_irqchip.h
> instead, my expectation was to use struct sbi_irqchip_device
> as the abstraction for the interrupt controller.
>

I can wrap sbi_irqchip_provider_ops into sbi_irqchip_device if that
looks better.
It is not a big change to the implementation itself.

Regards,
Raymond

> Regards,
> Anup

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

[PATCH v2 2/2] lib: sbi: Add VIRQ interrupt abstraction

[Raymond Mao]

From: Raymond Mao <raymond.mao@riscstar.com>

VIRQ (Virtual IRQ) layer is on top of irqchip, providing IRQ state
management via per-(domain,hart) IRQ pending queue, with courier
dispatching and interface to enqueue/pop/complete an IRQ.
It dispatches claimed wired interrupts to S-Mode domains via SSE
injection on current hart.

Signed-off-by: Raymond Mao <raymond.mao@riscstar.com>
---
 include/sbi/sbi_virq.h | 90 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)
 create mode 100644 include/sbi/sbi_virq.h

diff --git a/include/sbi/sbi_virq.h b/include/sbi/sbi_virq.h
new file mode 100644
index 00000000..1760d9b5
--- /dev/null
+++ b/include/sbi/sbi_virq.h
@@ -0,0 +1,90 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (c) 2026 RISCstar Solutions Corporation.
+ *
+ * Author: Raymond Mao <raymond.mao@riscstar.com>
+ */
+
+#ifndef __SBI_VIRQ_H__
+#define __SBI_VIRQ_H__
+
+#include <sbi/sbi_domain.h>
+#include <sbi/sbi_types.h>
+
+/*
+ * Keep the queue small for bring-up. If it overflows, we drop and warn.
+ */
+#define SBI_VIRQ_QSIZE  32
+
+/* per-(domain,hart) IRQ state */
+struct sbi_domain_virq_state {
+	spinlock_t lock;
+	u32 head;
+	u32 tail;
+	/* pending IRQ queue */
+	u32 q[SBI_VIRQ_QSIZE];
+};
+
+/* Per-domain VIRQ context */
+struct sbi_domain_virq_priv {
+	/* harts number of the domain */
+	u32 nharts;
+	/* IRQ states of all harts of the domain */
+	struct sbi_domain_virq_state st[];
+};
+
+struct sbi_virq_courier_priv {
+	struct sbi_domain *dom;
+	u32 virq;
+};
+
+/* Enqueue an interrupt (as seen by the generic irqchip layer) for a domain. */
+int sbi_virq_enqueue(struct sbi_domain *dom, u32 irq);
+
+/*
+ * Complete a previously couriered irq for the current domain.
+ *
+ * This will unmask the interrupt line at the active irqchip provider, allowing
+ * further interrupts once S-mode has cleared the device interrupt source.
+ */
+void sbi_virq_complete_thishart(u32 irq);
+
+/* Pop next pending irq for current domain on this hart. Returns 0 if none. */
+u32 sbi_virq_pop_thishart(void);
+
+/*
+ * Courier handler for wired irqchip dispatch.
+ *
+ * Intended usage:
+ *   sbi_irqchip_set_handler(hwirq, sbi_virq_courier_handler, dom);
+ *
+ * It will enqueue (irq) for the provided domain and inject SSE on the
+ * current hart to notify S-mode.
+ */
+int sbi_virq_courier_handler(void *priv);
+
+/*
+ * Bind helper function: bind a given irq and register the courier handler
+ * for a domain.
+ */
+int sbi_virq_bind_irq_to_domain(u32 irq, struct sbi_domain *dom);
+
+/* Initialize per-domain virq state (alloc + lock init). */
+int sbi_virq_domain_init(struct sbi_domain *dom);
+
+
+/*
+ * Optional: map a virtual IRQ number (virq) to a hardware wired IRQ (hwirq).
+ *
+ * If no explicit mapping exists, 'virq==hwirq' is assumed.
+ *
+ * This allows upper layers (e.g. VIRQ courier/emulation) to use stable virq
+ * identifiers without exposing the wired controller's hwirq numbering.
+ */
+int sbi_virq_map_irq(u32 virq, u32 hwirq);
+int sbi_virq_unmap_irq(u32 virq);
+u32 sbi_virq_irq_to_hwirq(u32 virq);
+u32 sbi_virq_hwirq_to_irq(u32 hwirq);
+
+#endif
-- 
2.25.1


-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

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

[Anup Patel]

On Mon, Feb 2, 2026 at 8:32 PM Raymond Mao <raymondmaoca@gmail.com> wrote:
>
> From: Raymond Mao <raymond.mao@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.

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

>
> 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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/opensbi

Regards,
Anup

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

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

[Raymond Mao]

Hi Anup,

On Sat, Feb 7, 2026 at 5:08 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Mon, Feb 2, 2026 at 8:32 PM Raymond Mao <raymondmaoca@gmail.com> wrote:
> >
> > From: Raymond Mao <raymond.mao@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@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/opensbi
>
> Regards,
> Anup

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

Re: [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@gmail.com> wrote:
>
> Hi Anup,
>
> On Sat, Feb 7, 2026 at 5:08 AM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Mon, Feb 2, 2026 at 8:32 PM Raymond Mao <raymondmaoca@gmail.com> wrote:
> > >
> > > From: Raymond Mao <raymond.mao@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

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

Re: [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@brainfault.org> wrote:
>
> On Sat, Feb 7, 2026 at 9:41 PM Raymond Mao <raymondmaoca@gmail.com> wrote:
> >
> > Hi Anup,
> >
> > On Sat, Feb 7, 2026 at 5:08 AM Anup Patel <anup@brainfault.org> wrote:
> > >
> > > On Mon, Feb 2, 2026 at 8:32 PM Raymond Mao <raymondmaoca@gmail.com> wrote:
> > > >
> > > > From: Raymond Mao <raymond.mao@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

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

Re: [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@gmail.com> wrote:
>
> Hi Anup,
>
> On Sun, Feb 8, 2026 at 8:24 AM Anup Patel <anup@brainfault.org> wrote:
> >
> > On Sat, Feb 7, 2026 at 9:41 PM Raymond Mao <raymondmaoca@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Sat, Feb 7, 2026 at 5:08 AM Anup Patel <anup@brainfault.org> wrote:
> > > >
> > > > On Mon, Feb 2, 2026 at 8:32 PM Raymond Mao <raymondmaoca@gmail.com> wrote:
> > > > >
> > > > > From: Raymond Mao <raymond.mao@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

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi