From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org,
Richard Henderson <richard.henderson@linaro.org>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
"Ard Biesheuvel" <ardb@kernel.org>
Subject: Re: [PATCH v2 03/19] target/i386: implement SHA instructions
Date: Thu, 19 Oct 2023 12:59:57 +0200 [thread overview]
Message-ID: <1261e3b2-fc10-c37b-c19d-ac78f5912fc2@linaro.org> (raw)
In-Reply-To: <20231019104648.389942-4-pbonzini@redhat.com>
Hi Paolo,
On 19/10/23 12:46, Paolo Bonzini wrote:
> The implementation was validated with OpenSSL and with the test vectors in
> https://github.com/rust-lang/stdarch/blob/master/crates/core_arch/src/x86/sha.rs.
>
> The instructions provide a ~25% improvement on hashing a 64 MiB file:
> runtime goes down from 1.8 seconds to 1.4 seconds; instruction count on
> the host goes down from 5.8 billion to 4.8 billion with slightly better
> IPC too. Good job Intel. ;)
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> target/i386/cpu.c | 2 +-
> target/i386/ops_sse.h | 128 +++++++++++++++++++++++++++
> target/i386/tcg/decode-new.c.inc | 11 +++
> target/i386/tcg/decode-new.h | 1 +
> target/i386/tcg/emit.c.inc | 54 +++++++++++
> target/i386/tcg/ops_sse_header.h.inc | 14 +++
> 6 files changed, 209 insertions(+), 1 deletion(-)
> diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h
> index 33908c0691f..6a465a35fdb 100644
> --- a/target/i386/ops_sse.h
> +++ b/target/i386/ops_sse.h
> @@ -2527,6 +2527,134 @@ SSE_HELPER_FMAP(helper_fma4ps, ZMM_S, 2 << SHIFT, float32_muladd)
> SSE_HELPER_FMAP(helper_fma4pd, ZMM_D, 1 << SHIFT, float64_muladd)
> #endif
>
> +#if SHIFT == 1
> +#define SSE_HELPER_SHA1RNDS4(name, F, K) \
> + void name(Reg *d, Reg *a, Reg *b) \
> + { \
> + uint32_t A, B, C, D, E, t, i; \
> + \
> + A = a->L(3); \
> + B = a->L(2); \
> + C = a->L(1); \
> + D = a->L(0); \
> + E = 0; \
> + \
> + for (i = 0; i <= 3; i++) { \
> + t = F(B, C, D) + rol32(A, 5) + b->L(3 - i) + E + K; \
> + E = D; \
> + D = C; \
> + C = rol32(B, 30); \
> + B = A; \
> + A = t; \
> + } \
> + \
> + d->L(3) = A; \
> + d->L(2) = B; \
> + d->L(1) = C; \
> + d->L(0) = D; \
> + }
> +
> +#define SHA1_F0(b, c, d) (((b) & (c)) ^ (~(b) & (d)))
> +#define SHA1_F1(b, c, d) ((b) ^ (c) ^ (d))
> +#define SHA1_F2(b, c, d) (((b) & (c)) ^ ((b) & (d)) ^ ((c) & (d)))
> +
> +SSE_HELPER_SHA1RNDS4(helper_sha1rnds4_f0, SHA1_F0, 0x5A827999)
> +SSE_HELPER_SHA1RNDS4(helper_sha1rnds4_f1, SHA1_F1, 0x6ED9EBA1)
> +SSE_HELPER_SHA1RNDS4(helper_sha1rnds4_f2, SHA1_F2, 0x8F1BBCDC)
> +SSE_HELPER_SHA1RNDS4(helper_sha1rnds4_f3, SHA1_F1, 0xCA62C1D6)
> +
> +void helper_sha1nexte(Reg *d, Reg *a, Reg *b)
> +{
> + d->L(3) = b->L(3) + rol32(a->L(3), 30);
> + d->L(2) = b->L(2);
> + d->L(1) = b->L(1);
> + d->L(0) = b->L(0);
> +}
> +
> +void helper_sha1msg1(Reg *d, Reg *a, Reg *b)
> +{
> + /* These could be overwritten by the first two assignments, save them. */
> + uint32_t b3 = b->L(3);
> + uint32_t b2 = b->L(2);
> +
> + d->L(3) = a->L(3) ^ a->L(1);
> + d->L(2) = a->L(2) ^ a->L(0);
> + d->L(1) = a->L(1) ^ b3;
> + d->L(0) = a->L(0) ^ b2;
> +}
> +
> +void helper_sha1msg2(Reg *d, Reg *a, Reg *b)
> +{
> + d->L(3) = rol32(a->L(3) ^ b->L(2), 1);
> + d->L(2) = rol32(a->L(2) ^ b->L(1), 1);
> + d->L(1) = rol32(a->L(1) ^ b->L(0), 1);
> + d->L(0) = rol32(a->L(0) ^ d->L(3), 1);
> +}
> +
> +#define SHA256_CH(e, f, g) (((e) & (f)) ^ (~(e) & (g)))
> +#define SHA256_MAJ(a, b, c) (((a) & (b)) ^ ((a) & (c)) ^ ((b) & (c)))
> +
> +#define SHA256_RNDS0(w) (ror32((w), 2) ^ ror32((w), 13) ^ ror32((w), 22))
> +#define SHA256_RNDS1(w) (ror32((w), 6) ^ ror32((w), 11) ^ ror32((w), 25))
> +#define SHA256_MSGS0(w) (ror32((w), 7) ^ ror32((w), 18) ^ ((w) >> 3))
> +#define SHA256_MSGS1(w) (ror32((w), 17) ^ ror32((w), 19) ^ ((w) >> 10))
> +
> +void helper_sha256rnds2(Reg *d, Reg *a, Reg *b, uint32_t wk0, uint32_t wk1)
> +{
> + uint32_t t, AA, EE;
> +
> + uint32_t A = b->L(3);
> + uint32_t B = b->L(2);
> + uint32_t C = a->L(3);
> + uint32_t D = a->L(2);
> + uint32_t E = b->L(1);
> + uint32_t F = b->L(0);
> + uint32_t G = a->L(1);
> + uint32_t H = a->L(0);
> +
> + /* Even round */
> + t = SHA256_CH(E, F, G) + SHA256_RNDS1(E) + wk0 + H;
> + AA = t + SHA256_MAJ(A, B, C) + SHA256_RNDS0(A);
> + EE = t + D;
> +
> + /* These will be B and F at the end of the odd round */
> + d->L(2) = AA;
> + d->L(0) = EE;
> +
> + D = C, C = B, B = A, A = AA;
> + H = G, G = F, F = E, E = EE;
> +
> + /* Odd round */
> + t = SHA256_CH(E, F, G) + SHA256_RNDS1(E) + wk1 + H;
> + AA = t + SHA256_MAJ(A, B, C) + SHA256_RNDS0(A);
> + EE = t + D;
Better would be to implement that generically, so we can reuse
host crypto accelerators when available. Can be done later...
(See commit range fb250c59aa..ff494c8e2a for example.)
> + d->L(3) = AA;
> + d->L(1) = EE;
> +}
> +
> +void helper_sha256msg1(Reg *d, Reg *a, Reg *b)
> +{
> + /* b->L(0) could be overwritten by the first assignment, save it. */
> + uint32_t b0 = b->L(0);
> +
> + d->L(0) = a->L(0) + SHA256_MSGS0(a->L(1));
> + d->L(1) = a->L(1) + SHA256_MSGS0(a->L(2));
> + d->L(2) = a->L(2) + SHA256_MSGS0(a->L(3));
> + d->L(3) = a->L(3) + SHA256_MSGS0(b0);
> +}
> +
> +void helper_sha256msg2(Reg *d, Reg *a, Reg *b)
> +{
> + /* Earlier assignments cannot overwrite any of the two operands. */
> + d->L(0) = a->L(0) + SHA256_MSGS1(b->L(2));
> + d->L(1) = a->L(1) + SHA256_MSGS1(b->L(3));
> + /* Yes, this reuses the previously computed values. */
> + d->L(2) = a->L(2) + SHA256_MSGS1(d->L(0));
> + d->L(3) = a->L(3) + SHA256_MSGS1(d->L(1));
> +}
> +#endif
next prev parent reply other threads:[~2023-10-19 11:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 10:46 [PATCH v2 00/19] target/i386: decoder changes for 8.2 Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 01/19] target/i386: group common checks in the decoding phase Paolo Bonzini
2023-10-19 15:45 ` Richard Henderson
2023-10-19 10:46 ` [PATCH v2 02/19] target/i386: validate VEX.W for AVX instructions Paolo Bonzini
2023-10-19 15:45 ` Richard Henderson
2023-10-19 10:46 ` [PATCH v2 03/19] target/i386: implement SHA instructions Paolo Bonzini
2023-10-19 10:59 ` Philippe Mathieu-Daudé [this message]
2023-10-19 11:42 ` Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 04/19] tests/tcg/i386: initialize more registers in test-avx Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 05/19] tests/tcg/i386: test-avx: add test cases for SHA new instructions Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 06/19] target/i386: accept full MemOp in gen_ext_tl Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 07/19] target/i386: introduce flags writeback mechanism Paolo Bonzini
2023-10-19 17:44 ` Richard Henderson
2023-10-19 19:08 ` Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 08/19] target/i386: implement CMPccXADD Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 09/19] target/i386: do not clobber A0 in POP translation Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 10/19] target/i386: reintroduce debugging mechanism Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 11/19] target/i386: move 00-5F opcodes to new decoder Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 12/19] target/i386: adjust decoding of J operand Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 13/19] target/i386: split eflags computation out of gen_compute_eflags Paolo Bonzini
2023-10-19 10:46 ` [PATCH v2 14/19] tcg: add negsetcondi Paolo Bonzini
2023-10-19 16:00 ` Richard Henderson
2023-10-19 10:48 ` [PATCH v2 15/19] target/i386: move 60-BF opcodes to new decoder Paolo Bonzini
2023-10-19 10:48 ` [PATCH v2 16/19] target/i386: move operand load and writeback out of gen_cmovcc1 Paolo Bonzini
2023-10-19 10:48 ` [PATCH v2 17/19] target/i386: move remaining conditional operations to new decoder Paolo Bonzini
2023-10-19 10:48 ` [PATCH v2 18/19] target/i386: remove now converted opcodes from old decoder Paolo Bonzini
2023-10-19 10:48 ` [PATCH v2 19/19] target/i386: remove gen_op Paolo Bonzini
2023-10-19 11:39 ` [PATCH v2 00/19] target/i386: decoder changes for 8.2 Paolo Bonzini
2023-10-19 15:44 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1261e3b2-fc10-c37b-c19d-ac78f5912fc2@linaro.org \
--to=philmd@linaro.org \
--cc=ardb@kernel.org \
--cc=berrange@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).