Tulio Magno Quites Machado Filho's on January 30, 2020 1:51 am: > Nicholas Piggin <npig...@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