linux-kernel - Re: [PATCH] riscv: Add sysctl to control discard of vstate during syscall

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <feb3549f-da91-4eaa-a624-b9f35db6ba3c@iscas.ac.cn>
Date: Fri, 25 Jul 2025 23:01:03 +0800
From: Vivian Wang <wangruikang@...as.ac.cn>
To: Radim Krčmář <rkrcmar@...tanamicro.com>,
 Drew Fustini <fustini@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
 Björn Töpel <bjorn@...osinc.com>,
 Alexandre Ghiti <alex@...ti.fr>, Paul Walmsley <paul.walmsley@...ive.com>,
 Samuel Holland <samuel.holland@...ive.com>,
 Drew Fustini <dfustini@...storrent.com>, Andy Chiu <andybnac@...il.com>,
 Conor Dooley <conor.dooley@...rochip.com>, linux-riscv@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Cc: linux-riscv <linux-riscv-bounces@...ts.infradead.org>
Subject: Re: [PATCH] riscv: Add sysctl to control discard of vstate during
 syscall

On 7/25/25 18:18, Radim Krčmář wrote:
> 2025-07-24T05:55:54+08:00, Vivian Wang <wangruikang@...as.ac.cn>:
>> On 7/19/25 11:39, Drew Fustini wrote:
>>> From: Drew Fustini <dfustini@...storrent.com>
>>> Clobbering the vector registers can significantly increase system call
>>> latency for some implementations. To mitigate this performance impact, a
>>> policy mechanism is provided to administrators, distro maintainers, and
>>> developers to control vector state discard in the form of a sysctl knob:
>> So I had an idea: Is it possible to avoid repeatedly discarding the
>> state on every syscall by setting VS to Initial after discarding, and
>> avoiding discarding when VS is Initial? So:
>>
>> if (VS == Clean || VS == Dirty) {
>>     clobber;
>>     VS = Initial;
>> }
>>
>> This would avoid this problem with syscall-heavy user programs while
>> adding minimum overhead for everything else.
> I think your proposal improves the existing code, but if a userspace is
> using vectors, it's likely also restoring them after a syscall, so the
> state would immediately get dirty, and the next syscall would again
> needlessly clobber vector registers.

Without any data to back it up, I would say that my understanding is
that this should be a rare case, only happening if e.g. someone is
adding printf debugging to their vector code. Otherwise, vector loops
should not have syscalls in them.

A more reasonable worry would be programs using RVV everywhere in all
sorts of common operations. In that case, alternating syscalls and
vectors would make the discarding wasteful.

> Preserving the vector state still seems better for userspaces that use
> both vectors and syscalls.

If we can expect e.g. userspace programs to primarily repeatedly use RVV
with no syscalls between loops, *or* primarily repeatedly use syscalls
with rare occurrences of RVV between syscalls. This way, the primarily
syscall programs can benefit from slightly switching, since there's no
need to save and restore state for those most of the time. In effect,
syscalls serves as a hint that RVV is over. The primarily RVV programs
should not be switching as much - if they are, that's a sign of CPU
resources being oversubscribed. 

Having said all of that, I am actually slightly more interested in why
vmv.v.vi is *so slow* on SiFive X280. I wonder if there would be a more
microarchitectural favorable ways to just put a bunch of ones in some
vector registers? Would 0 be better?

Vivian "dramforever" Wang