From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id F19CC3858CDB for ; Thu, 10 Aug 2023 20:51:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F19CC3858CDB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id D55BF9200C1; Thu, 10 Aug 2023 22:51:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id CF39A9200BF; Thu, 10 Aug 2023 21:51:28 +0100 (BST) Date: Thu, 10 Aug 2023 21:51:28 +0100 (BST) From: "Maciej W. Rozycki" To: Andy Chiu cc: Greg Savin , Greentime Hu , linux-riscv@lists.infradead.org, gdb-patches@sourceware.org, Andrew Burgess Subject: Re: [PATCH] RISC-V: support for vector register accesses via ptrace() in RISC-V Linux native In-Reply-To: <20230810140537.GA17787@hsinchu26> Message-ID: References: <20230803230110.904724-1-greg.savin@sifive.com> <20230810103510.GA2509@hsinchu26> <20230810140537.GA17787@hsinchu26> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3494.6 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Andy, > > > Does it make sense to you if we encapsulate this with a hwprobe syscall? > > > e.g provide a hwprobe entry to get system's VLENB. We will have to > > > increase and rearrange the buffer for NT_RISCV_VECTOR if we want to use > > > ptrace as the entry point for this purpose. I am not very sure if it'd be > > > too late to do though. > > > > No, how do you expect it to work with a core dump (that can be examined > > on a different system, or with a cross-debugger)? You need to change the > > API I'm afraid; it's unusable anyway. It's a pity the toolchain community > > wasn't consulted if you weren't sure how to design the interface. Better > > yet it would have been to implement the GDB side before the kernel part > > has been committed. > > Conor just reminded me that we may still have a chance to get it right > since 6.5 has not been released yet. I will send a fix patch to address > this issue once the discussion settle down. After looking into some > code, I think it is possbile to steal the unused space in datap and > change the uapi with something like this: > > diff --git a/arch/riscv/include/uapi/asm/ptrace.h b/arch/riscv/include/uapi/asm/ptrace.h > index e17c550986a6..ba6ddf4f9dc9 100644 > --- a/arch/riscv/include/uapi/asm/ptrace.h > +++ b/arch/riscv/include/uapi/asm/ptrace.h > @@ -97,14 +97,17 @@ struct __riscv_v_ext_state { > unsigned long vl; > unsigned long vtype; > unsigned long vcsr; > - void *datap; > + union { > + void *datap; > + unsigned long vlenb; > + }; > /* > * In signal handler, datap will be set a correct user stack offset > * and vector registers will be copied to the address of datap > * pointer. > * > - * In ptrace syscall, datap will be set to zero and the vector > - * registers will be copied to the address right after this > + * In ptrace syscall, the space for datap will be set to vlenb and the > + * vector registers will be copied to the address right after this > * structure. > */ > }; > > Now ptrace will have the knowlege of vlen to parse V rsgisters. And this > will not cause any size change to the original data structure that is > shared by both signal and ptrace because vlenb is XLEN, which has the > same size as a pointer in both ilp32/lp64. Barring details such as field naming (perhaps `vregp' rather than opaque `datap'?), or whether we want to have a union embedded such as above or distinct UAPI data types for the two use cases I think your proposal for the updated contents makes sense to me, thanks. Maciej