linux-kernel - Re: [PATCH 1/2] riscv: dts: sophgo: Add xtheadvector to the sg2042 devicetree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aCO44SAoS2kIP61r@ghost>
Date: Tue, 13 May 2025 14:25:53 -0700
From: Charlie Jenkins <charlie@...osinc.com>
To: Chen Wang <unicorn_wang@...look.com>
Cc: Han Gao <rabenda.cn@...il.com>, devicetree@...r.kernel.org,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Inochi Amaoto <inochiama@...il.com>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
	sophgo@...ts.linux.dev, linux-riscv@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] riscv: dts: sophgo: Add xtheadvector to the sg2042
 devicetree

On Tue, May 13, 2025 at 06:05:20PM +0800, Chen Wang wrote:
> Adding Charlie.
> 
> Hi, Charlie,
> 
> Can you please help confirm this? Is there something wrong with my
> understanding? Copied here below for your quick reference:
> 
> > One more question is about writing value of "thead,vlenb". See bindings
> > description in Documentation/devicetree/bindings/riscv/cpus.yaml:
> > 
> > ```
> > 
> >    thead,vlenb:
> >      $ref: /schemas/types.yaml#/definitions/uint32
> >      description:
> >        VLEN/8, the vector register length in bytes. This property is
> > required on
> >        thead systems where the vector register length is not identical
> > on all harts, or
> >        the vlenb CSR is not available.
> > 
> > ```
> > 
> > What I am not sure about is whether we should write 128 or 128/8=16?
> > Assuming VLEN of C910 is 128bit.
> 
> 
> Thanks, Chen
> 
> On 2025/5/13 17:13, Han Gao wrote:
> > > Assuming VLEN of C910 is 128bit.
> > I refer to the value of c906 because c906 and c910/c920v1 have the same value.
> > 
> > Link: https://lore.kernel.org/linux-riscv/20241113-xtheadvector-v11-3-236c22791ef9@rivosinc.com/
> > [1]
> > 
> > On Tue, May 13, 2025 at 4:06 PM Chen Wang <unicorn_wang@...look.com> wrote:
> > > 
> > > On 2025/5/13 14:45, Han Gao wrote:
> > > > You can use xxd to convert it.
> > > > 
> > > > cat /sys/devices/system/cpu/cpu63/of_node/thead,vlenb | xxd
> > > > 00000000: 0000 0080                                ....
> > > > 
> > > > Regards,
> > > > Han
> > > I can read this after disable ERRATA_THEAD_GHOSTWRITE.

You can also pass "mitigations=off" as a kernel arg.

> > > 
> > > I recommend adding some explanation notes in the commit message. For
> > > example, when we need to enable xtheadvector, the prerequisite is to
> > > turn off "ERRATA_THEAD_GHOSTWRITE".
> > > I found the relevant patch is
> > > https://lore.kernel.org/linux-riscv/20241113-xtheadvector-v11-0-236c22791ef9@rivosinc.com/,
> > > also hope adding this will help later people quickly understand and
> > > avoid my mistakes.
> > > 
> > > One more question is about writing value of "thead,vlenb". See bindings
> > > description in Documentation/devicetree/bindings/riscv/cpus.yaml:
> > > 
> > > ```
> > > 
> > >     thead,vlenb:
> > >       $ref: /schemas/types.yaml#/definitions/uint32
> > >       description:
> > >         VLEN/8, the vector register length in bytes. This property is
> > > required on
> > >         thead systems where the vector register length is not identical
> > > on all harts, or
> > >         the vlenb CSR is not available.
> > > 
> > > ```
> > > 
> > > What I am not sure about is whether we should write 128 or 128/8=16?
> > > Assuming VLEN of C910 is 128bit.

That's a bug. It should 16, but I had put it as 128 for the D1
devicetree.

- Charlie

> > > 
> > > Thanks,
> > > 
> > > Chen
> > >