Re: powerpc Linux scv support and scv system call ABI proposal

[Nicholas Piggin <npiggin at gmail dot com>]

Tulio Magno Quites Machado Filho's on January 30, 2020 1:51 am:
> Nicholas Piggin <npiggin@gmail.com> writes:
> 
>> Adhemerval Zanella's on January 29, 2020 3:26 am:
>>> 
>>> We already had to push a similar hack where glibc used to abort transactions
>>> prior syscalls to avoid some side-effects on kernel (commit 56cf2763819d2f).
>>> It was eventually removed from syscall handling by f0458cf4f9ff3d870, where
>>> we only enable TLE if kernel suppors PPC_FEATURE2_HTM_NOSC.
>>> 
>>> The transaction syscall abort used to read a variable directly from TCB,
>>> so this could be an option. I would expect that we could optimize it where
>>> if glibc is building against a recent kernel and compiler is building
>>> for a ISA 3.0+ cpu we could remove the 'sc' code.
>>> 
>>
>> We would just have to be careful of running on ISA 3.0 CPUs on older
>> kernels which do not support scv.
> 
> Can we assume that, if a syscall is available through sc it's also available
> in scv 0?

Was on vacation, thanks for waiting.

Yes, except for the difference in calling convention, we would require
that the syscalls available to `sc` is exactly the same as `scv 0`. This
happens as a natural consequence of the kernel implementation which
re-uses code to select the syscall.

> 
> Because if that's true, I believe your suggestion to interpret PPC_FEATURE2_SCV
> as scv 0 support would be helpful to provide this support via IFUNC even
> when glibc is built using --with-cpu=power8, which is the most common scenario
> in ppc64le.
> 
> In that scenario, it seems new HWCAP bits for new vectors wouldn't be too
> frequent, which was the only downside of this proposal.

Okay good feedback, thanks.

Thanks,
Nick