From: Paris Oplopoios <parisoplop@gmail.com>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: linux-riscv@lists.infradead.org, paul.walmsley@sifive.com,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr
Subject: Re: [PATCH] riscv: hwprobe: allow querying available RISCV_HWPROBE_KEY_IMA_EXT_0 bits
Date: Tue, 19 Aug 2025 22:56:11 +0300 [thread overview]
Message-ID: <CAAbFZ0g4xSRQnP_sVMR10zTPeJtYX2wo9Pi0SEcvbubEiiv6Gw@mail.gmail.com> (raw)
In-Reply-To: <20250819-fa2f9d3392614bd654c530c9@orel>
> When the kernel is aware of the extension
The way I understand it, there's currently no way for a program to
know whether or not the kernel is aware of an extension. When the
syscall returns a cleared bit for some key, you are left to wonder
whether this means the kernel is unaware or if the extension is
unavailable. A value of 1 means that the extension is available, but a
value of 0, unless it has any higher 1 bits, is ambiguous.
The new key helps because we get to decide what to do in the case of
no kernel availability. We can decide to print a message or do the
fallback or something else. Point is, right now we can't know whether
the extension is available in the kernel. For our extension detection
we never use the riscv_hwprobe API for this reason and always do a
SIGILL handler based detection when possible.
> What I think we need is a way to better automatically expose Z-extensions
> which are in the DT/ACPI. I like the idea of generating a sysfs node for
> each extension string. Those nodes could then have properties such as the
> kernel's awareness of it, etc. I proposed something in the past like that,
> but it was considered too Linux-specific.
That would be good too.
On Tue, 19 Aug 2025 at 22:37, Andrew Jones <ajones@ventanamicro.com> wrote:
>
> On Wed, Aug 13, 2025 at 07:33:48PM +0300, Paris Oplopoios wrote:
> > When probing for extensions using RISCV_HWPROBE_KEY_IMA_EXT_0, a missing
> > bit in the resulting bitmask means extension is not available or the kernel is
> > not recent enough to support the bit. Currently, there's no way to
> > differentiate between the two.
> >
> > This adds a new riscv_hwprobe key, RISCV_HWPROBE_KEY_IMA_EXT_0_AVAIL, which
> > returns a bitmask of all queryable supported by the kernel
> > in RISCV_HWPROBE_KEY_IMA_EXT_0. This can allow programs to use a fallback
> > extension detection method when the bit they want to query is not available
> > in the kernel they are running on.
> >
> > Example usage:
> >
> > struct riscv_hwprobe req = { RISCV_HWPROBE_KEY_IMA_EXT_0_AVAIL, 0 };
> > int ret = syscall(__NR_riscv_hwprobe, &req, 1, 0, NULL, 0);
> > if (ret == 0) {
> > uint64_t bitmask = req.value;
> > if (bitmask & RISCV_HWPROBE_EXT_ZABHA) {
> > // Check for existence of Zabha extension using riscv_hwprobe
> > } else {
> > // Fallback to checking if an instruction in the Zabha
> > // extension results in an illegal instruction exception
>
> The new key allows us to know when the kernel is aware of an extension
> or not. When the kernel is aware of the extension, then a hwprobe of
> the extension's key generates a result that unambiguously states whether
> or not the extension is available. However, when the kernel is unaware of
> the extension, then we still know nothing about its availability. IOW,
> how does the new key help? The fact that this example use still has this
> fallback path in it implies it doesn't.
>
> What I think we need is a way to better automatically expose Z-extensions
> which are in the DT/ACPI. I like the idea of generating a sysfs node for
> each extension string. Those nodes could then have properties such as the
> kernel's awareness of it, etc. I proposed something in the past like that,
> but it was considered too Linux-specific.
>
> Thanks,
> drew
>
> > }
> > }
> >
> > Signed-off-by: Paris Oplopoios <parisoplop@gmail.com>
> >
> > ---
> >
> > diff --git a/Documentation/arch/riscv/hwprobe.rst
> > b/Documentation/arch/riscv/hwprobe.rst
> > index 2aa9be272d5d..6d77def0a46e 100644
> > --- a/Documentation/arch/riscv/hwprobe.rst
> > +++ b/Documentation/arch/riscv/hwprobe.rst
> > @@ -360,4 +360,7 @@ The following keys are defined:
> >
> > * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFWMACCQQQ`: The Xsfvfwmaccqqq
> > vendor extension is supported in version 1.0 of Matrix
> > Multiply Accumulate
> > - Instruction Extensions Specification.
> > \ No newline at end of file
> > + Instruction Extensions Specification.
> > +
> > +* :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_0_AVAIL`: A bitmask containing
> > the extensions
> > + that can be probed using the :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_0` key.
> > \ No newline at end of file
> > diff --git a/arch/riscv/include/asm/hwprobe.h b/arch/riscv/include/asm/hwprobe.h
> > index 7fe0a379474a..501d49b7a02a 100644
> > --- a/arch/riscv/include/asm/hwprobe.h
> > +++ b/arch/riscv/include/asm/hwprobe.h
> > @@ -8,7 +8,8 @@
> >
> > #include <uapi/asm/hwprobe.h>
> >
> > -#define RISCV_HWPROBE_MAX_KEY 13
> > +#define RISCV_HWPROBE_MAX_KEY 14
> > +#define RISCV_HWPROBE_KEY_IMA_EXT_0_AVAIL_VALUE ((1ULL << 59) - 1)
> >
> > static inline bool riscv_hwprobe_key_is_valid(__s64 key)
> > {
> > diff --git a/arch/riscv/include/uapi/asm/hwprobe.h
> > b/arch/riscv/include/uapi/asm/hwprobe.h
> > index aaf6ad970499..a3b92df4dc05 100644
> > --- a/arch/riscv/include/uapi/asm/hwprobe.h
> > +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> > @@ -82,6 +82,7 @@ struct riscv_hwprobe {
> > #define RISCV_HWPROBE_EXT_ZAAMO (1ULL << 56)
> > #define RISCV_HWPROBE_EXT_ZALRSC (1ULL << 57)
> > #define RISCV_HWPROBE_EXT_ZABHA (1ULL << 58)
> > +/* Change RISCV_HWPROBE_KEY_IMA_EXT_0_AVAIL_VALUE when adding items. */
> > #define RISCV_HWPROBE_KEY_CPUPERF_0 5
> > #define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0)
> > #define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0)
> > @@ -106,6 +107,7 @@ struct riscv_hwprobe {
> > #define RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 11
> > #define RISCV_HWPROBE_KEY_ZICBOM_BLOCK_SIZE 12
> > #define RISCV_HWPROBE_KEY_VENDOR_EXT_SIFIVE_0 13
> > +#define RISCV_HWPROBE_KEY_IMA_EXT_0_AVAIL 14
> > /* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
> >
> > /* Flags */
> > diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
> > index 0b170e18a2be..40e7fa5f85f3 100644
> > --- a/arch/riscv/kernel/sys_hwprobe.c
> > +++ b/arch/riscv/kernel/sys_hwprobe.c
> > @@ -310,6 +310,10 @@ static void hwprobe_one_pair(struct riscv_hwprobe *pair,
> > hwprobe_isa_vendor_ext_thead_0(pair, cpus);
> > break;
> >
> > + case RISCV_HWPROBE_KEY_IMA_EXT_0_AVAIL:
> > + pair->value = RISCV_HWPROBE_KEY_IMA_EXT_0_AVAIL_VALUE;
> > + break;
> > +
> > /*
> > * For forward compatibility, unknown keys don't fail the whole
> > * call, but get their element key set to -1 and value set to 0
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
prev parent reply other threads:[~2025-08-19 22:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 16:33 [PATCH] riscv: hwprobe: allow querying available RISCV_HWPROBE_KEY_IMA_EXT_0 bits Paris Oplopoios
2025-08-13 18:05 ` [PATCH v2] " offtkp
2025-08-14 9:37 ` Alexandre Ghiti
2025-08-14 10:32 ` Paris Oplopoios
2025-08-14 11:22 ` Alexandre Ghiti
2025-08-14 11:57 ` Paris Oplopoios
2025-08-14 12:55 ` Alexandre Ghiti
2025-08-14 13:21 ` Paris Oplopoios
2025-08-14 13:56 ` Alexandre Ghiti
2025-08-14 14:20 ` Paris Oplopoios
2025-08-14 22:13 ` [PATCH v3] " offtkp
2025-08-25 17:02 ` [PATCH v3 RESEND] " offtkp
2025-08-25 22:00 ` Andrew Jones
2025-08-25 23:12 ` Paris Oplopoios
2025-08-19 19:37 ` [PATCH] " Andrew Jones
2025-08-19 19:56 ` Paris Oplopoios [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAbFZ0g4xSRQnP_sVMR10zTPeJtYX2wo9Pi0SEcvbubEiiv6Gw@mail.gmail.com \
--to=parisoplop@gmail.com \
--cc=ajones@ventanamicro.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).