On Tue, Jan 5, 2021 at 3:23 PM Niels Möller nisse@lysator.liu.se wrote:
I've made a new branch "arm64" with the configure changes. If you think that looks ok, can you add your new ghash code on top of that?
Great. I'll add the ghash code to the branch once I finish the big-endian support.
(It would be good to also get S390x into the ci system, before adding s390x-specific assembly. I hope that should be easy to do with the same cross setup as for arm, arm64, mips, etc).
This is not possible since qemu doesn't support cipher functions, it implements subcode 0 (query) without actual encipher/decipher operations, take a look here https://git.qemu.org/?p=qemu.git;a=commit;h=be2b567018d987591647935a7c9648e9...
I had a talk with David Edelsohn for this issue, I concluded that there is no support for cipher functions on qemu and it's unlikely to happen anytime soon. However, I updated the testutils to cover the s390x-specific assembly so the patch can easily be tested manually by executing 'make check'. I also have tested every aspect of this patch to make sure everything will go well once it's merged.
I wonder which assembly files we should use if target host is aarch64,
but ABI=32? I guess the arm/v6/ code can be used unconditionally. Can we also use arm/neon/ code unconditionally?
The reference manual says
Armv8 can support the following levels of support for Advanced SIMD and floating-point instructions:
Full SIMD and floating-point support without exception trapping.
Full SIMD and floating-point support with exception trapping.
No floating-point or SIMD support. This option is licensed only for implementations targeting specialized markets.
As far as I understand, that means Neon should be always available, in both 32-bit and 64-bit mode.
I'll investigate how we can build the existing NEON implementations on 64-bit systems.
regards, Mamone