[PATCH v3] RISC-V: Document that V registers are clobbered on syscalls

[PATCH v3] RISC-V: Document that V registers are clobbered on syscalls

[Palmer Dabbelt]

This is included in the ISA manual, but it's pretty common for bits of
the ISA manual that are actually ABI to change.  So let's document it
explicitly.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 Documentation/riscv/vector.rst | 8 ++++++++
 1 file changed, 8 insertions(+)
---
Changes since v2 <20230619180411.12946-1-palmer@rivosinc.com>:
* Add a link to the V spec's calling convention doc.

Changes since v1 <20230614163534.18668-1-palmer@rivosinc.com>:
* Remove the code change, just update the documentation.  We might still
  want to do something in the code, but that's still under discussion
  so let's get the docs sorted out for now.

diff --git a/Documentation/riscv/vector.rst b/Documentation/riscv/vector.rst
index 48f189d79e41..165b7ed0ac4f 100644
--- a/Documentation/riscv/vector.rst
+++ b/Documentation/riscv/vector.rst
@@ -130,3 +130,11 @@ processes in form of sysctl knob:
 
     Modifying the system default enablement status does not affect the enablement
     status of any existing process of thread that do not make an execve() call.
+
+3.  Vector Register State Across System Calls
+---------------------------------------------
+
+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
-- 
2.40.1


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

Re: [PATCH v3] RISC-V: Document that V registers are clobbered on syscalls

[Björn Töpel]

Palmer Dabbelt <palmer@rivosinc.com> writes:

> This is included in the ISA manual, but it's pretty common for bits of
> the ISA manual that are actually ABI to change.  So let's document it
> explicitly.
>
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

Reviewed-by: Björn Töpel <bjorn@rivosinc.com>

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

Re: [PATCH v3] RISC-V: Document that V registers are clobbered on syscalls

[patchwork-bot+linux-riscv]

Hello:

This patch was applied to riscv/linux.git (for-next)
by Palmer Dabbelt <palmer@rivosinc.com>:

On Mon, 19 Jun 2023 12:01:43 -0700 you wrote:
> This is included in the ISA manual, but it's pretty common for bits of
> the ISA manual that are actually ABI to change.  So let's document it
> explicitly.
> 
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> ---
>  Documentation/riscv/vector.rst | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> [...]

Here is the summary with links:
  - [v3] RISC-V: Document that V registers are clobbered on syscalls
    https://git.kernel.org/riscv/c/bcc8790057c1

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



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

Re: [PATCH v3] RISC-V: Document that V registers are clobbered on syscalls

[Maciej W. Rozycki]

On Mon, 19 Jun 2023, Palmer Dabbelt wrote:

> This is included in the ISA manual, but it's pretty common for bits of
> the ISA manual that are actually ABI to change.  So let's document it
> explicitly.

 I'm probably coming much too late for this to have any effect, but I find 
this design decision quite odd.  The V extension spec has this note:

"This scheme allows system calls that cause context switches to avoid 
saving and later restoring the vector registers."

however declaring vector registers syscall-clobbered does not actually let 
context switches in a preemptively multitasked OS such as Linux refrain 
from saving/restoring these registers, because switches will quite often 
if not predominantly (depending on application) happen asynchronously in 
response to a hardware interrupt such as a timer tick.  In which case 
vector registers will have to be saved for the old context and loaded for 
the new one anyway, and two variants of the context switch handler will be 
needed to take any performance advantage envisaged by the spec (and then 
the case of a syscall switching to a context previously preempted by a 
hardware interrupt will have to be handled correctly, where we can ignore 
values from the old context, but need to load ones for the new context).

 What has been the usual approach across CPU architectures for decades now 
to reduce expensive moves of extra register files, such as FPU, vector, 
DSP, etc. on context switches is just setting a privileged control bit 
that makes any instruction accessing such a register file trap and then 
the handler loads the file according to its previously saved contents for 
the current context, clears the control bit and restarts the instruction 
that faulted.  Depending on the OS design decision saving for the old 
context is done either in the trap handler beforehand or in the original 
context switch that took control away from the old context.  Consequently 
extra register files are only saved and loaded if ever touched by the 
context concerned, even if contexts are preempted by a hardware interrupt.

 Have I been missing anything here?

 FWIW,

  Maciej

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