[PATCH RFC 3/3] lib: sbi: Add VIRQ ecall extension

[Andrew Jones]

On Fri, Feb 13, 2026 at 02:04:59PM -0500, Raymond Mao wrote:
> From: Raymond Mao <raymond.mao at riscstar.com>
> 
> Add vendor SBI extension ecall for VIRQ.
> This allows S-mode payload to pop/complete the next pending VIRQ has
> couried into the current domain.
> 
> Signed-off-by: Raymond Mao <raymond.mao at riscstar.com>
> ---
>  include/sbi/sbi_ecall_interface.h | 18 ++++++++++
>  lib/sbi/Kconfig                   |  5 +++
>  lib/sbi/objects.mk                |  3 ++
>  lib/sbi/sbi_ecall_virq.c          | 57 +++++++++++++++++++++++++++++++
>  4 files changed, 83 insertions(+)
>  create mode 100644 lib/sbi/sbi_ecall_virq.c
> 
> diff --git a/include/sbi/sbi_ecall_interface.h b/include/sbi/sbi_ecall_interface.h
> index 76624e3f..9cb9a7eb 100644
> --- a/include/sbi/sbi_ecall_interface.h
> +++ b/include/sbi/sbi_ecall_interface.h
> @@ -126,6 +126,24 @@
>  #define SBI_EXT_FWFT_SET		0x0
>  #define SBI_EXT_FWFT_GET		0x1
>  
> +#ifdef CONFIG_SBI_ECALL_VIRQ
> +
> +/* Vendor extension base range is defined by the SBI spec. Choose a private ID. */
> +#define SBI_EXT_VIRQ			0x0900524d

I'm not sure where this number comes from. I'd expect it to be
0x56495251 == "VIRQ"

> +
> +/* Function IDs for SBI_EXT_VIRQ */
> +#define SBI_EXT_VIRQ_POP		0
> +#define SBI_EXT_VIRQ_COMPLETE		1
> +
> +/*
> + * SBI_EXT_VIRQ_POP
> + * Returns:
> + *   a0: SBI error code (0 for success)
> + *   a1: next pending hwirq (0 if none pending)
                         ^ virq, but...

how about creating an SBI function which allows registering a shared
memory region (as several SBI extensions already do) and then place a
bitmap in that shared memory which represents all virqs (a set bit means
that that virq is pending). That would allow S-mode to immediately get
all pending virqs in its SSE handler and we wouldn't need to worry about
a queue filling up. The downside is that S-mode wouldn't necessarily
handle the virqs in FIFO order. But, that can be a feature, because the
queue forces FIFO order whereas S-mode may need to handle them in some
priority order instead.

> + */
> +
> +#endif
> +
>  enum sbi_fwft_feature_t {
>  	SBI_FWFT_MISALIGNED_EXC_DELEG		= 0x0,
>  	SBI_FWFT_LANDING_PAD			= 0x1,
> diff --git a/lib/sbi/Kconfig b/lib/sbi/Kconfig
> index c6cc04bc..8479f861 100644
> --- a/lib/sbi/Kconfig
> +++ b/lib/sbi/Kconfig
> @@ -69,4 +69,9 @@ config SBI_ECALL_SSE
>  config SBI_ECALL_MPXY
>  	bool "MPXY extension"
>  	default y
> +
> +config SBI_ECALL_VIRQ
> +	bool "VIRQ extension"
> +	default y
> +
>  endmenu
> diff --git a/lib/sbi/objects.mk b/lib/sbi/objects.mk
> index 07d13229..18e590ab 100644
> --- a/lib/sbi/objects.mk
> +++ b/lib/sbi/objects.mk
> @@ -64,6 +64,9 @@ libsbi-objs-$(CONFIG_SBI_ECALL_SSE) += sbi_ecall_sse.o
>  carray-sbi_ecall_exts-$(CONFIG_SBI_ECALL_MPXY) += ecall_mpxy
>  libsbi-objs-$(CONFIG_SBI_ECALL_MPXY) += sbi_ecall_mpxy.o
>  
> +carray-sbi_ecall_exts-$(CONFIG_SBI_ECALL_VIRQ) += ecall_virq
> +libsbi-objs-$(CONFIG_SBI_ECALL_VIRQ) += sbi_ecall_virq.o
> +
>  libsbi-objs-y += sbi_bitmap.o
>  libsbi-objs-y += sbi_bitops.o
>  libsbi-objs-y += sbi_console.o
> diff --git a/lib/sbi/sbi_ecall_virq.c b/lib/sbi/sbi_ecall_virq.c
> new file mode 100644
> index 00000000..b192598e
> --- /dev/null
> +++ b/lib/sbi/sbi_ecall_virq.c
> @@ -0,0 +1,57 @@
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (c) 2026 RISCstar Solutions.
> + *
> + * Author: Raymond Mao <raymond.mao at riscstar.com>
> + */
> +
> +#include <sbi/sbi_console.h>
> +#include <sbi/sbi_ecall.h>
> +#include <sbi/sbi_ecall_interface.h>
> +#include <sbi/sbi_error.h>
> +#include <sbi/sbi_trap.h>
> +#include <sbi/sbi_virq.h>
> +
> +static int sbi_ecall_virq_handler(unsigned long extid,
> +				  unsigned long funcid,
> +				  struct sbi_trap_regs *regs,
> +				  struct sbi_ecall_return *out)
> +{
> +	(void)extid;
> +
> +	sbi_printf("[ECALL VIRQ] VIRQ ecall handler, funcid: %ld\n", funcid);

You'll want to get rid of these print statements when posting without the
RFC.

Thanks,
drew