All of lore.kernel.org
 help / color / mirror / Atom feed
From: szabolcs.nagy@arm.com (Szabolcs Nagy)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] arm64/sve: ABI change: Zero SVE regs on syscall entry
Date: Wed, 25 Oct 2017 15:33:32 +0100	[thread overview]
Message-ID: <59F0A0BC.1090606@arm.com> (raw)
In-Reply-To: <20171025125727.GH19485@e103592.cambridge.arm.com>

On 25/10/17 13:57, Dave Martin wrote:
> On Tue, Oct 24, 2017 at 09:30:55PM +0100, Richard Sandiford wrote:
>> I think the uses via libc wrappers should be OK, since the SVE PCS says
>> that all SVE state is clobbered by normal function calls.  I think we
>> can be relatively confident that the compilers implement this correctly,
>> since it's the natural extension of the base AArch64 PCS (which only
>> preserves the low 64 bits of V8-V15).
>>
>> Perhaps one concern would be LTO, since we then rely on the syscall asm
>> statement having the correct clobber lists.  And at the moment there's
>> no syntax for saying that a register R is clobbered above X bits.
>> (Alan's working on a GCC patch that could be reused for this if necessary.)
>
> I wonder whether the lack of a precise clobber will discourage people
> from writing a correct clobber list for SVCs -- the kernel guarantees to
> preserve V0-V31, so listing z0-z31 as clobbered would resulting
> unnecessary spilling of V8-V15[63:0] around SVC (as required by the
> ARMv8 base PCS).
>
> If SVC is always in out-of-line asm though, this isn't an issue.  I'm
> not sure what glibc does.

glibc assumes that the libc code is not lto'd.

it has syscall asm files as well as inline asm with svc,
the later does not have magic sve clobber, but it should
not matter as long as no sve is used in glibc.

gcc runtimes (libstdc++, libgomp, libitm,..) have some
raw syscalls (mainly futex) but on aarch64 it's a call
to syscall() in libc, not inline asm.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

  reply	other threads:[~2017-10-25 14:33 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
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 [this message]
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=59F0A0BC.1090606@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.