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

From: "Radim Krčmář" <rkrcmar@ventanamicro.com>
To: "Drew Fustini" <fustini@kernel.org>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Samuel Holland" <samuel.holland@sifive.com>,
	"Drew Fustini" <dfustini@tenstorrent.com>,
	"Andy Chiu" <andybnac@gmail.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: "linux-riscv" <linux-riscv-bounces@lists.infradead.org>
Subject: Re: [PATCH] riscv: Add sysctl to control discard of vstate during syscall
Date: Mon, 21 Jul 2025 14:35:38 +0200	[thread overview]
Message-ID: <DBHQK4W9CL9F.1WM8JFVDQZ44F@ventanamicro.com> (raw)
In-Reply-To: <20250719033912.1313955-1-fustini@kernel.org>

2025-07-18T20:39:13-07:00, Drew Fustini <fustini@kernel.org>:
> From: Drew Fustini <dfustini@tenstorrent.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:
>
> /proc/sys/abi/riscv_v_vstate_discard
>
> Valid values are:
>
> 0: Do not discard vector state during syscall
> 1: Discard vector state during syscall
>
> The initial state is controlled by CONFIG_RISCV_ISA_V_VSTATE_DISCARD.

I think it is a bit more complicated to do this nicely...
Programs don't have to save/restore vector registers around syscalls
when compiled for riscv_v_vstate_discard=0, so running under
riscv_v_vstate_discard=1 would break them.

Shouldn't we have a way to prevent riscv_v_vstate_discard=0 executable
from running with riscv_v_vstate_discard=1?

> Fixes: 9657e9b7d253 ("riscv: Discard vector state on syscalls")

Programs compiled for riscv_v_vstate_discard=1 are compatible with 0, so
I think it would be simplest to revert that patch, and pretended it
never happened... (The issues will eventually go away.)

Shouldn't the RISC-V Linux syscall ABI be defined somewhere?
How come we could have broken it with 9657e9b7d253?

Thanks.

---
I don't think it makes much sense to clobber vector registers on a
syscall -- a kernel might not even touch vector registers, so they are
efforlessly preserved in that case.
If kernel needs to use vector registers in the syscall, then the kernel
needs to prevent any register leaks to userspace anyway by restoring
some state into them -- and why not restore the original one?

I think that main point of clobbering would be to optimize
context-switches after the userspace is not using vector registers
anymore, but it's terribly inefficient if the ratio of syscalls to
context switches is high.
Linux can also try to detect the situation, and turn to lazy vector
context-switch, with sstatus.VS=off, instead of eagerly restoring
clobbered state.
(A good indicator might be that the userspace hasn't dirtied the vectors
 since the last context-switch -- kernel didn't need to save the state,
 so it will restore lazily.)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv