Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Drew Fustini <fustini@kernel.org>
To: "Radim Krčmář" <rkrcmar@ventanamicro.com>
Cc: "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,
	linux-riscv <linux-riscv-bounces@lists.infradead.org>
Subject: Re: [PATCH] riscv: Add sysctl to control discard of vstate during syscall
Date: Sun, 27 Jul 2025 10:29:16 -0700	[thread overview]
Message-ID: <aIZh7F+jY8CxpuCz@x1> (raw)
In-Reply-To: <aH6uPi+UOP6GzNjv@x1>

On Mon, Jul 21, 2025 at 02:16:46PM -0700, Drew Fustini wrote:
> On Mon, Jul 21, 2025 at 02:35:38PM +0200, Radim Krčmář wrote:
> > 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.
> 
> Thanks for your comments. You raise a good point that this sysctl can
> lead to the case where a program might be compiled to not save/restore
> vector registers around syscalls. That same program would not work
> correctly if the sysadmin changes riscv_v_vstate_discard to 1.
> 
> > Shouldn't we have a way to prevent riscv_v_vstate_discard=0 executable
> > from running with riscv_v_vstate_discard=1?
> 
> Yes, this does make me concerned that a program could crash as a result
> of this sysctl which would be confusing for the user as they may not
> even be aware of this sysctl. I'll have to think more about how such a
> protection could work.

After further consideration, I think that it would be appropriate for
programs that don't save/restore vector registers around syscalls to
break when riscv_v_vstate_discard=1. I believe the primary motivation
of the original change 2 years ago was to catch programs that rely on
the vector state being retained across syscalls. Thus, I think that this
behavior would be consistent with that.

Bjorn told me he is away at the moment but hopefully he can provide his
perspective when he is back.

Thanks,
Drew

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

  reply	other threads:[~2025-07-27 17:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-19  3:39 [PATCH] riscv: Add sysctl to control discard of vstate during syscall Drew Fustini
2025-07-21 12:13 ` Darius Rad
2025-07-21 20:59   ` Drew Fustini
2025-07-21 21:28     ` Drew Fustini
2025-07-21 12:35 ` Radim Krčmář
2025-07-21 14:54   ` Radim Krčmář
2025-07-21 21:20     ` Drew Fustini
2025-07-31  1:05     ` Palmer Dabbelt
2025-07-31 12:24       ` Radim Krčmář
2025-08-01 21:41       ` Drew Fustini
2025-08-05 18:51         ` Drew Fustini
2025-07-21 21:16   ` Drew Fustini
2025-07-27 17:29     ` Drew Fustini [this message]
2025-07-23 21:55 ` Vivian Wang
2025-07-25 10:18   ` Radim Krčmář
2025-07-25 15:01     ` Vivian Wang
2025-07-25 18:47       ` Radim Krčmář
2025-07-26 18:37         ` Drew Fustini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aIZh7F+jY8CxpuCz@x1 \
    --to=fustini@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=andybnac@gmail.com \
    --cc=bjorn@rivosinc.com \
    --cc=conor.dooley@microchip.com \
    --cc=dfustini@tenstorrent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv-bounces@lists.infradead.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rkrcmar@ventanamicro.com \
    --cc=samuel.holland@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox