From: Nicholas Piggin <npiggin@gmail.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org, linuxppc-dev@lists.ozlabs.org,
Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Subject: Re: powerpc Linux scv support and scv system call ABI proposal
Date: Wed, 29 Jan 2020 11:18:00 -0000 [thread overview]
Message-ID: <1580271319.kvmwnv0a4v.astroid@bobo.none> (raw)
In-Reply-To: <87sgjzbmk1.fsf@oldenburg2.str.redhat.com>
Florian Weimer's on January 29, 2020 1:58 am:
> * Nicholas Piggin:
>
>> That gets the LR save/restore right when we're also using r0.
>
> Yes, I agree it looks good. Nice.
>
>>> But the kernel uses the -errno convention internally, so I think it
>>> would make sense to pass this to userspace and not convert back and
>>> forth. This would align with what most of the architectures do, and
>>> also avoids the GCC oddity.
>>
>> Yes I would be interested in opinions for this option. It seems like
>> matching other architectures is a good idea. Maybe there are some
>> reasons not to.
>
> If there were a POWER-specific system call that uses all result bits and
> doesn't have room for the 4096 error states (or an error number that's
> outside that range), that would be a blocker. I can't find such a
> system call wrapped in the glibc sources.
Nothing apparent in the kernel sources either.
> musl's inline syscalls always
> convert the errno state to -errno, so it's not possible to use such a
> system call there.
>
>>>> - Should this be for 64-bit only? 'scv 1' could be reserved for 32-bit
>>>> calls if there was interest in developing an ABI for 32-bit programs.
>>>> Marginal benefit in avoiding compat syscall selection.
>>>
>>> We don't have an ELFv2 ABI for 32-bit. I doubt it makes sense to
>>> provide an ELFv1 port for this given that it's POWER9-specific.
>>
>> Okay. There's no reason not to enable this for BE, at least for the
>> kernel it's no additional work so it probably remains enabled (unless
>> there is something really good we could do with the ABI if we exclude
>> ELFv1 but I don't see anything).
>>
>> But if glibc only builds for ELFv2 support that's probably reasonable.
>
> To be clear, we still support ELFv1 for POWER, but given that this
> feature is POWER9 and later, I expect the number of users benefiting
> from 32-bit support (or ELFv1 and thus big-endian support) to be quite
> small.
>
> Especially if we go the conditional branch route, I would restrict this
> to ELFv2 in glibc, at least for default builds.
>
>>> From the glibc perspective, the major question is how we handle run-time
>>> selection of the system call instruction sequence. On i386, we use a
>>> function pointer in the TCB to call an instruction sequence in the vDSO.
>>> That's problematic from a security perspective. I expect that on
>>> POWER9, using a pointer in read-only memory would be equally
>>> non-attractive due to a similar lack of PC-relative addressing. We
>>> could use the HWCAP bit in the TCB, but that would add another (easy to
>>> predict) conditional branch to every system call.
>>
>> I would have to defer to glibc devs on this. Conditional branch
>> should be acceptable I think, scv improves speed as much as several
>> mispredicted branches (about 90 cycles).
>
> But we'd have to pay for that branch (and likely the LR clobber) on
> legacy POWER, and that's something to consider, too.
We would that's true.
> Is there an additional performance hit if a process uses both the old
> and new system call sequence?
No state or logic required to switch between them or run them
concurrently. Just the extra instruction footprint.
Thanks,
Nick
next prev parent reply other threads:[~2020-01-29 4:44 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-28 12:56 Nicholas Piggin
2020-01-28 13:58 ` Florian Weimer
2020-01-28 15:40 ` Nicholas Piggin
2020-01-28 15:55 ` Segher Boessenkool
2020-01-28 16:19 ` Florian Weimer
2020-01-28 17:02 ` Dan Horák
2020-01-28 20:38 ` Segher Boessenkool
2020-01-29 16:30 ` Florian Weimer
2020-01-29 16:36 ` Segher Boessenkool
2020-01-29 17:40 ` Florian Weimer
2020-01-29 18:59 ` Segher Boessenkool
2020-01-30 11:03 ` Florian Weimer
2020-01-30 12:04 ` Segher Boessenkool
2020-01-30 12:34 ` Florian Weimer
2020-01-30 14:34 ` Segher Boessenkool
2020-01-30 17:59 ` Adhemerval Zanella
2020-01-30 22:05 ` Segher Boessenkool
2020-01-31 11:33 ` Adhemerval Zanella
2020-01-31 12:12 ` Segher Boessenkool
2020-01-28 16:05 ` Florian Weimer
2020-01-29 11:18 ` Nicholas Piggin [this message]
2020-01-28 16:25 ` Adhemerval Zanella
[not found] ` <cd9e4b28-d577-8850-7c2b-a488fcb4740d@linaro.org>
[not found] ` <1580273424.ea818exa2c.astroid@bobo.none>
2020-01-29 16:19 ` Tulio Magno Quites Machado Filho
2020-02-19 11:04 ` Nicholas Piggin
2020-01-28 23:18 ` Joseph Myers
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=1580271319.kvmwnv0a4v.astroid@bobo.none \
--to=npiggin@gmail.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=tuliom@linux.ibm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).