Re: [PATCH 5/6] riscv: hwprobe: Report XTheadVector only when available
From: Charlie Jenkins
Date: Wed Oct 07 2026 - 04:12:08 EST
On Wed, Oct 07, 2026 at 09:59:30AM +0200, Radim Krčmář wrote:
> 2026-10-06T16:54:53-07:00, Charlie Jenkins <thecharlesjenkins@xxxxxxxxx>:
> >> User-mode use of XTheadVector requires non-Off sstatus.VS, which we set
> >> only when has_xtheadvector() (CONFIG_RISCV_ISA_XTHEADVECTOR and
> >> XTheadVector on all harts). XTheadVector also bundles operations with
> >> floating state, which additionally requires non-Off sstatus.FS and hence
> >> has_fpu(). hwprobe reports XTheadVector from the per-hart vendor ISA
> >> bitmaps alone, so it can advertise an extension that is always disabled
> >> in user-mode.
> >>
> >> Report correct environment to user-mode.
> >>
> >> Fixes: a5ea53da65c5 ("riscv: hwprobe: Add thead vendor extension probing")
> >> Signed-off-by: Radim Krčmář <radim.krcmar@xxxxxxxxxxxxxxxx>
> >>
> >> diff --git a/arch/riscv/kernel/vendor_extensions/thead_hwprobe.c b/arch/riscv/kernel/vendor_extensions/thead_hwprobe.c
> >> index 2eba34011786..f07aa1c8acac 100644
> >> --- a/arch/riscv/kernel/vendor_extensions/thead_hwprobe.c
> >> +++ b/arch/riscv/kernel/vendor_extensions/thead_hwprobe.c
> >> @@ -1,5 +1,7 @@
> >> // SPDX-License-Identifier: GPL-2.0-only
> >>
> >> +#include <asm/switch_to.h>
> >> +#include <asm/vector.h>
> >> #include <asm/vendor_extensions/thead.h>
> >> #include <asm/vendor_extensions/thead_hwprobe.h>
> >> #include <asm/vendor_extensions/vendor_hwprobe.h>
> >> @@ -14,6 +16,7 @@ void hwprobe_isa_vendor_ext_thead_0(struct riscv_hwprobe *pair, const struct cpu
> >> {
> >> VENDOR_EXTENSION_SUPPORTED(pair, cpus,
> >> riscv_isa_vendor_ext_list_thead.per_hart_isa_bitmap, {
> >> - VENDOR_EXT_KEY(XTHEADVECTOR);
> >> + if (has_xtheadvector() && has_fpu())
> >
> > xtheadvector is also gated on FPU=y so this is a reduntant addition. Is
> > it worthwhile to make this change?
>
> With CONFIG_FPU=y, has_fpu() is set to false when a single hart doesn't
> have the D, and has_xtheadvector() could still be true.
Ahh that's a good point.
>
> > Is
> > it worthwhile to make this change?
>
> I think that it's sensible to mimic the validation we do for the
> non-vendor extension, but users of vendor extensions likely already have
> to go out of their way to utilize them, so they can do the sanity checks
> too... I can drop the last two patches in v2.
I don't know, it seems better to keep standardization if possible and
leave the check in here to mimic the standard extensions?
- Charlie
>
> Thanks.