All of lore.kernel.org
 help / color / mirror / Atom feed
From: Drew Fustini <pdp7pdp7@gmail.com>
To: "Radim Krčmář" <rkrcmar@ventanamicro.com>
Cc: "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,
	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:20:03 -0700	[thread overview]
Message-ID: <aH6vA+e5v7NMMGnc@x1> (raw)
In-Reply-To: <DBHTIDY0HRM0.2B8L1WG7IBCXM@ventanamicro.com>

On Mon, Jul 21, 2025 at 04:54:25PM +0200, Radim Krčmář wrote:
> 2025-07-21T14:35:38+02:00, Radim Krčmář <rkrcmar@ventanamicro.com>:
> > Shouldn't the RISC-V Linux syscall ABI be defined somewhere?
> 
> To clarify this point.  My issue is with the following part in
> Documentation/arch/riscv/vector.rst:
> 
> >>  As indicated by version 1.0 of the V extension [1], vector registers are
> >>  clobbered by system calls.
> >>  [...]
> >>  1: https://github.com/riscv/riscv-v-spec/blob/master/calling-convention.adoc
> 
> The ISA does not say that vector registers are clobbered by system
> calls.  All the ISA says is:
> 
>   "This Appendix is only a placeholder to help explain the conventions
>    used in the code examples, and is not considered frozen or
>    part of the ratification process.  The official RISC-V psABI document
>    is being expanded to specify the vector calling conventions."
> 
> while the RISC-V psABI says:
> 
>   "The calling convention for system calls does not fall within the
>    scope of this document. Please refer to the documentation of the
>    RISC-V execution environment interface (e.g OS kernel ABI, SBI)."
> 
> We made a circular dependency, misinterpreted the ISA, and probably
> implemented a suboptimal syscall ABI -- preserving vector registers
> seems strictly better.

Thanks for providing these references. It does seem like this is
something that an OS can decide and is not mandated by the ISA or psABI.

> > How come we could have broken it with 9657e9b7d253?
> 
> We changed the ABI once, so maybe we can change it back?

Reverting 9657e9b7d253 would solve the performance issue for some
implementations that I've highlighted in this patch. However, I am
interested to hear from others that feel the current mandatory
clobbering behavior is ideal for testing (and maybe security?).

Thanks,
Drew

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

WARNING: multiple messages have this Message-ID (diff)
From: Drew Fustini <pdp7pdp7@gmail.com>
To: "Radim Krčmář" <rkrcmar@ventanamicro.com>
Cc: "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,
	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:20:03 -0700	[thread overview]
Message-ID: <aH6vA+e5v7NMMGnc@x1> (raw)
In-Reply-To: <DBHTIDY0HRM0.2B8L1WG7IBCXM@ventanamicro.com>

On Mon, Jul 21, 2025 at 04:54:25PM +0200, Radim Krčmář wrote:
> 2025-07-21T14:35:38+02:00, Radim Krčmář <rkrcmar@ventanamicro.com>:
> > Shouldn't the RISC-V Linux syscall ABI be defined somewhere?
> 
> To clarify this point.  My issue is with the following part in
> Documentation/arch/riscv/vector.rst:
> 
> >>  As indicated by version 1.0 of the V extension [1], vector registers are
> >>  clobbered by system calls.
> >>  [...]
> >>  1: https://github.com/riscv/riscv-v-spec/blob/master/calling-convention.adoc
> 
> The ISA does not say that vector registers are clobbered by system
> calls.  All the ISA says is:
> 
>   "This Appendix is only a placeholder to help explain the conventions
>    used in the code examples, and is not considered frozen or
>    part of the ratification process.  The official RISC-V psABI document
>    is being expanded to specify the vector calling conventions."
> 
> while the RISC-V psABI says:
> 
>   "The calling convention for system calls does not fall within the
>    scope of this document. Please refer to the documentation of the
>    RISC-V execution environment interface (e.g OS kernel ABI, SBI)."
> 
> We made a circular dependency, misinterpreted the ISA, and probably
> implemented a suboptimal syscall ABI -- preserving vector registers
> seems strictly better.

Thanks for providing these references. It does seem like this is
something that an OS can decide and is not mandated by the ISA or psABI.

> > How come we could have broken it with 9657e9b7d253?
> 
> We changed the ABI once, so maybe we can change it back?

Reverting 9657e9b7d253 would solve the performance issue for some
implementations that I've highlighted in this patch. However, I am
interested to hear from others that feel the current mandatory
clobbering behavior is ideal for testing (and maybe security?).

Thanks,
Drew

  reply	other threads:[~2025-07-21 21:20 UTC|newest]

Thread overview: 36+ 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-19  3:39 ` Drew Fustini
2025-07-21 12:13 ` Darius Rad
2025-07-21 12:13   ` Darius Rad
2025-07-21 20:59   ` Drew Fustini
2025-07-21 20:59     ` Drew Fustini
2025-07-21 21:28     ` Drew Fustini
2025-07-21 21:28       ` Drew Fustini
2025-07-21 12:35 ` Radim Krčmář
2025-07-21 12:35   ` Radim Krčmář
2025-07-21 14:54   ` Radim Krčmář
2025-07-21 14:54     ` Radim Krčmář
2025-07-21 21:20     ` Drew Fustini [this message]
2025-07-21 21:20       ` Drew Fustini
2025-07-31  1:05     ` Palmer Dabbelt
2025-07-31  1:05       ` Palmer Dabbelt
2025-07-31 12:24       ` Radim Krčmář
2025-07-31 12:24         ` Radim Krčmář
2025-08-01 21:41       ` Drew Fustini
2025-08-01 21:41         ` Drew Fustini
2025-08-05 18:51         ` Drew Fustini
2025-08-05 18:51           ` Drew Fustini
2025-07-21 21:16   ` Drew Fustini
2025-07-21 21:16     ` Drew Fustini
2025-07-27 17:29     ` Drew Fustini
2025-07-27 17:29       ` Drew Fustini
2025-07-23 21:55 ` Vivian Wang
2025-07-23 21:55   ` Vivian Wang
2025-07-25 10:18   ` Radim Krčmář
2025-07-25 10:18     ` Radim Krčmář
2025-07-25 15:01     ` Vivian Wang
2025-07-25 15:01       ` Vivian Wang
2025-07-25 18:47       ` Radim Krčmář
2025-07-25 18:47         ` Radim Krčmář
2025-07-26 18:37         ` Drew Fustini
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=aH6vA+e5v7NMMGnc@x1 \
    --to=pdp7pdp7@gmail.com \
    --cc=alex@ghiti.fr \
    --cc=andybnac@gmail.com \
    --cc=bjorn@rivosinc.com \
    --cc=conor.dooley@microchip.com \
    --cc=dfustini@tenstorrent.com \
    --cc=fustini@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.