On Wed, Jul 22, 2020 at 6:04 PM Niels Möller <[email protected]> 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 _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
