[v1, 0/6] Support Zve32[xf] and Zve64[xfd] Vector subextensions

Stefan O'Rear sorear at fastmail.com
Thu Mar 14 15:13:35 PDT 2024


On Wed, Mar 13, 2024, at 5:15 AM, Andy Chiu wrote:
> On Tue, Mar 12, 2024 at 9:17 PM Stefan O'Rear <sorear at fastmail.com> wrote:
>>
>> On Tue, Mar 12, 2024, at 8:36 AM, Andy Chiu wrote:
>> > The series composes of two parts. The first part provides a quick fix for
>> > the issue on a recent thread[1]. The issue happens when a platform has
>> > ununified vector register length across multiple cores. Specifically,
>> > patch 1 adds a comment at a callsite of riscv_setup_vsize to clarify how
>> > vlenb is observed by the system. Patch 2 fixes the issue by failing the
>> > boot process of a secondary core if vlenb mismatches.
>> >
>> > The second part of the series provide a finer grain view of the Vector
>> > extension. Patch 3 give the obsolete ISA parser the ability to expand
>> > ISA extensions for sigle letter extensions. Patch 3, 4 introduces Zve32x,
>> > Zve32f, Zve64x, Zve64f, Zve64d for isa parsing and hwprobe. Patch 5
>> > updates all callsites such that Vector subextensions are maximumly
>> > supported by the kernel.
>>
>> What is the end user programming interface for this intended to be? prctl
>> call using inline asm ecall in the ifunc resolver, possibly automated using
>> function multi-versioning? Can we do better with a different interface?
>
> If a platform supports full V, then the user simply gets it by reading
> ELF_HWCAP. ELF_HWCAP has the 'v' bit set when all following conditions
> are met:
>  1. The single-letter 'v' extension is presented on platform
>  2. The kernel has CONFIG_RISCV_ISA_V
>  3. The Vector enablement status[1] for the user process is set to
>      PR_RISCV_V_VSTATE_CTRL_ON. This is true by default but can be
>      changed in Kconfig or the sysctl knob.
>
> If a platform only supports some of Zve* but not V, then ELF_HWCAP
> cannot help. The user would end up having to make a prctl call to see
> if current's PR_RISCV_V_VSTATE_CTRL_ON is true. I agree we need a
> better way for Zve* cases. I am considering if we could duplicate the
> information of current vector enablement status from prctl to hwprobe.
> Not very sure if this duplication is a good idea though.

I considered this a while ago, but the vdso hwprobe only has access to
data at the granularity of time namespaces, which aren't relevant for the
prctl. We could use a flag to request process-level information, which
would force a syscall, but it's unclear that's any better than using a
raw prctl syscall.

What would work perfectly is passing the Linux-defined bits in
AT_HWCAP[234], but that seems like a difficult sell at this point.

-s

> [1]: https://www.kernel.org/doc/html/next/riscv/vector.html
>
> Thanks,
> Andy
>
>
>
>
>
>>
>> -s
>>
>> > Two parts of the series are sent together to ease the effort of picking
>> > dependency patches. The first part can be merged independent of the
>> > second one if necessary.
>> >
>> > The series is tested on a QEMU and verified that booting, Vector
>> > programs context-switch, signal, ptrace, prctl(sysctl knob) interfaces
>> > works when we only report partial V from the ISA.
>> >
>> > This patch should be able to apply on risc-v for-next branch on top of
>> > the commit 886516fae2b7 ("RISC-V: fix check for zvkb with tip-of-tree clang")
>> >
>> > [1]:
>> > https://lore.kernel.org/all/20240228-vicinity-cornstalk-4b8eb5fe5730@spud/T/#u
>> >
>> > Andy Chiu (6):
>> >   riscv: vector: add a comment when calling riscv_setup_vsize()
>> >   riscv: smp: fail booting up smp if inconsistent vlen is detected
>> >   riscv: cpufeature: call match_isa_ext() for single-letter extensions
>> >   riscv: cpufeature: add zve32[xf] and zve64[xfd] isa detection
>> >   riscv: hwprobe: add zve Vector subextesnions into hwprobe interface
>> >   riscv: vector: adjust minimum Vector requirement to ZVE32X
>> >
>> >  Documentation/arch/riscv/hwprobe.rst   | 15 +++++++
>> >  arch/riscv/include/asm/hwcap.h         |  5 +++
>> >  arch/riscv/include/asm/switch_to.h     |  2 +-
>> >  arch/riscv/include/asm/vector.h        | 21 ++++++----
>> >  arch/riscv/include/asm/xor.h           |  2 +-
>> >  arch/riscv/include/uapi/asm/hwprobe.h  |  5 +++
>> >  arch/riscv/kernel/cpufeature.c         | 57 +++++++++++++++++++++++---
>> >  arch/riscv/kernel/head.S               | 14 +++----
>> >  arch/riscv/kernel/kernel_mode_vector.c |  4 +-
>> >  arch/riscv/kernel/process.c            |  4 +-
>> >  arch/riscv/kernel/signal.c             |  6 +--
>> >  arch/riscv/kernel/smpboot.c            | 14 ++++---
>> >  arch/riscv/kernel/sys_hwprobe.c        | 12 ++++--
>> >  arch/riscv/kernel/vector.c             | 15 ++++---
>> >  arch/riscv/lib/uaccess.S               |  2 +-
>> >  15 files changed, 135 insertions(+), 43 deletions(-)
>> >
>> > --
>> > 2.17.1
>> >
>> >
>> > _______________________________________________
>> > linux-riscv mailing list
>> > linux-riscv at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



More information about the linux-riscv mailing list