This completes the SPARC crypto series. It goes on top of patches 1-6 of v3 and replaces the withdrawn 7/8 and 8/8.
With the crypto feature, guests treat the CPU as a T4 or later. On those CPUs a block-initializing store (ASI 0xe2 and the other twin ASIs) to the first doubleword of a 32-byte block also zeroes the rest of the block. glibc's niagara4 memset and Linux's NG4memset depend on it, and OpenSSL's T4 AES code uses the FP form (stdfa). Patch 1 models this for both forms; patch 2 then reports HWCAP_SPARC_CRYPTO in linux-user, unchanged from v3 8/8. Testing: - Zero-fill behaviour measured on a SPARC T4 (stxa and stdfa, cached and uncached); QEMU now produces the same result. - glibc memcpy/mempcpy/memset checked against byte loops over many sizes and alignments, with a Gentoo stage3 sysroot (multiarch glibc, niagara4 routines): passes, and fails without patch 1. - Real userspace from that stage3 under qemu-sparc64 with and without +crypto, output identical: OpenSSL (AES CBC/CTR/ECB/CFB/OFB, digests, HMAC, PBKDF2, RSA/EC, speed), Python, perl, coreutils, gzip/xz/bzip2, tar, sed/awk. - Instruction vectors still match M7 silicon, also on a big-endian host; Linux crypto KUnit 208/0. While testing I hit a separate upstream TCG crash in qemu-user, not caused by this series. Testing these patches with real programs under qemu-user is more reliable with that fix applied: https://lore.kernel.org/qemu-devel/[email protected]/ Based-on: <[email protected]> Stian Halseth (2): target/sparc: Model block-initializing stores linux-user/sparc: Report HWCAP_SPARC_CRYPTO for crypto CPU feature linux-user/sparc/elfload.c | 1 + target/sparc/translate.c | 42 ++++++++++++++++++++++++++++++++++++-- 2 files changed, 41 insertions(+), 2 deletions(-) -- 2.43.0
