On Wed, Jul 22, 2020 at 6:04 PM Niels Möller nisse@lysator.liu.se wrote:
But in the patch for fat builds, you do the runtime check as
hwcap2 = getauxval(AT_HWCAP2);
features->have_crypto_ext =
(hwcap2 & PPC_FEATURE2_VEC_CRYPTO) == PPC_FEATURE2_VEC_CRYPTO ? 1 : 0;
I think I would prefer to have a matching directory name in the source tree, e.g., powerpc64/crypto_ext.
Are the aes instructions and the ghash instructions (which I imagine also has non-cryptographic uses) part of the same extension?
Yes, both are part of the same extension. I considered calling the directory "P8" for three reasons: - POWER8 is the minimal processor that support the crypto extensions - I measured the throughput and latency of the instructions on POWER8 - The current implementations can be enhanced further for POWER9 and newer by using arch 3.00 specific instructions which was introduced in POWER9 so we can call the directory of new implementations "P9"
The main thing I'm unsure about is that I don't know what extensions the ci test machines can be expected to have. For cross tests, it shouldn't be an issue as long as qemu supports all extensions of interest. But for a native x86_64 fat build, do the test machines have, e.g., the "sha_ni" extension? If not, we'd need to find out, and prune what fat variants we test.
I tested on my fork, "sha_ni" is not supported on gitlab ci
Regards, Mamone