[v1, 2/3] RISC-V: vector: export VLENB csr in __sc_riscv_v_state

Andy Chiu andy.chiu at sifive.com
Tue Aug 22 11:01:14 PDT 2023


Hi,

On Thu, Aug 17, 2023 at 8:35 PM Maciej W. Rozycki <macro at orcam.me.uk> wrote:
>
> On Wed, 16 Aug 2023, Andy Chiu wrote:
>
> > diff --git a/arch/riscv/include/uapi/asm/ptrace.h b/arch/riscv/include/uapi/asm/ptrace.h
> > index e17c550986a6..283800130614 100644
> > --- a/arch/riscv/include/uapi/asm/ptrace.h
> > +++ b/arch/riscv/include/uapi/asm/ptrace.h
> > @@ -97,6 +97,7 @@ struct __riscv_v_ext_state {
> >       unsigned long vl;
> >       unsigned long vtype;
> >       unsigned long vcsr;
> > +     unsigned long vlenb;
> >       void *datap;
>
>  I think we really ought to make a distinct structure holding the vector
> CSR state only, and then have it included as a leading member of a pair of
> other structures, one for the signal context with a trailing `datap' (or
> `vregp' or `vreg') member and another one for the regset with a flexible
> array member of the `char' type, e.g. (actual names TBD):
>
> struct __riscv_v_csr_state {
>         unsigned long vstart;
>         unsigned long vl;
>         unsigned long vtype;
>         unsigned long vcsr;
>         unsigned long vlenb;
> };
>
> struct __riscv_v_signal_state {
>         struct __riscv_v_csr_state csr;
>         void *vregp;
> };
>
> struct __riscv_v_regset_state {
>         struct __riscv_v_csr_state csr;
>         char vreg[];
> };
>
> This will make the API cleaner and avoid both UB with making accesses
> beyond the end of a structure and clutter with an unused entry in core
> files and data exchanged via ptrace(2).

Yes, and may I understand why there is a need for having struct
__riscv_v_csr_state? Unless there is a need for getting CSRs only, yet
vector CSRs are not meaningful without the content of Vector
registers. Personally I'd like to have one universal structure for
both ptrace/signal/context-swicth(internal to the kernel), or one for
UAPI and the other for kernel internal-used. Because then we don't
have to mess with all kinds of access helpers for similar things.
Maybe I lost something or just haven't read enough but doesn't it
sound confusing that we create two structures in UAPI just for the
Vector registers dump?

>
>  Since this is a part of the UAPI I suggest consulting with libc people,
> possibly by posting an RFC to <libc-alpha at sourceware.org>.
>
>   Maciej

Thanks,
Andy



More information about the linux-riscv mailing list