From: alex.bennee@linaro•org (Alex Bennée)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC PATCH] arm64/sve: ABI change: Zero SVE regs on syscall entry
Date: Mon, 23 Oct 2017 18:08:39 +0100 [thread overview]
Message-ID: <87tvypiyg8.fsf@linaro.org> (raw)
In-Reply-To: <1508758664-24186-2-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm•com> writes:
> As currently documented, no guarantee is made about what a user
> task sees in the SVE registers after a syscall, except that V0-V31
> (corresponding to Z0-Z31 bits [127:0]) are preserved.
>
> The actual kernel behaviour currently implemented is that the SVE
> registers are zeroed if a context switch or signal delivery occurs
> during a syscall. After a fork() or clone(), the SVE registers
> of the child task are zeroed also. The SVE registers are otherwise
> preserved. Flexibility is retained in the ABI about the exact
> criteria for the decision.
>
> There are some potential problems with this approach.
>
> Syscall impact
> --------------
>
> Will, Catalin and Mark have expressed concerns about the risk of
> creating de facto ABI here: in scenarios or workloads where a
> context switch never occurs or is very unlikely, userspace may
> learn to rely on preservation of the SVE registers across certain
> syscalls.
I think this is a reasonable concern but are there any equivalent cases
in the rest of the kernel? Is this new territory for Linux as these
super large registers are introduced?
> It is difficult to assess the impact of this: the syscall ABI is
> not a general-purpose interface, since it is usually hidden behind
> libc wrappers: direct invocation of SVC is discouraged. However,
> specialised runtimes, statically linked programs and binary blobs
> may bake in direct syscalls that make bad assumptions.
>
> Conversely, the relative cost of zeroing the SVE regs to mitigate
> against this also cannot be well characterised until SVE hardware
> exists.
>
> ptrace impact
> -------------
>
> The current implementation can discard and zero the SVE registers
> at any point during a syscall, including before, after or between
> ptrace traps inside a single syscall. This means that setting the
> SVE registers through PTRACE_SETREGSET will often not do what the
> user expects: the new register values are only guaranteed to
> survive as far as userspace if set from an asynchronous
> signal-delivery-stop (e.g., breakpoint, SEGV or asynchronous signal
> delivered outside syscall context).
>
> This is consistent with the currently documented SVE user ABI, but
> likely to be surprising for a debugger user, since setting most
> registers of a tracee doesn't behave in this way.
>
> This patch
> ----------
>
> The common syscall entry path is modified to forcibly discard SVE,
> and the discard logic elsewhere is removed.
>
> This means that there is a mandatory additional trap to the kernel
> when a user task tries to use SVE again after a syscall. This can
> be expensive for programs that use SVE heavily around syscalls, but
> can be optimised later.
Won't it impact every restart from syscall? It's a shame you have to
trap when I suspect most first accesses after a syscall are likely to be
either restoring the caller-saved values which assume the value is
trashed anyway. Adding gettimeofday() or write(stdout) while debugging
is going to kill performance.
--
Alex Benn?e
next prev parent reply other threads:[~2017-10-23 17:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-23 11:37 [RFC PATCH 0/1] arm64/sve: ABI change: Zero SVE regs on syscall entry Dave Martin
2017-10-23 11:37 ` [RFC PATCH] " Dave Martin
2017-10-23 17:08 ` Alex Bennée [this message]
2017-10-24 11:38 ` Dave Martin
2017-10-24 20:30 ` Richard Sandiford
2017-10-25 12:57 ` Dave Martin
2017-10-25 14:33 ` Szabolcs Nagy
2017-10-23 17:43 ` Catalin Marinas
2017-10-24 10:45 ` Dave Martin
2017-10-23 11:54 ` [RFC PATCH 0/1] " Dave Martin
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=87tvypiyg8.fsf@linaro.org \
--to=alex.bennee@linaro$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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