mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stian Halseth <stian@itx.no>
To: Eric Biggers <ebiggers@kernel.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	 "David S. Miller" <davem@davemloft.net>,
	Andreas Larsson <andreas@gaisler.com>,
	linux-crypto@vger.kernel.org,  sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lib/crypto: sparc/aes-xts: Add optimization using the AES opcodes
Date: Wed, 30 Sep 2026 08:44:28 +0200	[thread overview]
Message-ID: <ca018424c1e299520568a24ac04151fc55c9a685.camel@itx.no> (raw)
In-Reply-To: <20260929225722.GA1921@sol>

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]



On Tue, 2026-09-29 at 15:57 -0700, Eric Biggers wrote:
> 
> 
> It's in v3 now:
> https://lore.kernel.org/linux-crypto/20260929222752.36427-1-ebiggers@kernel.org
Thanks, I will test it. Should get the same results as in 7.2 on SPARC.
> 
> > For 7.4 I could send a v2 on top of it that takes sparc out of the
> > suppression again, without the Fixes: tag.
> 
> I suppose.  QEMU support is normally required for new crypto library
> code, so that it is actually testable.  That would rule out adding
> any
> "new" code using the SPARC crypto opcodes until support for them is
> added to QEMU (https://github.com/sparclinux/issues/issues/77).
I will have a look at this issue.
> 
> I might be willing to make an exception for AES-XTS, since otherwise
> for
> parity with the "xts" template the library would need to gain an
> implementation of AES-XTS on top of AES-ECB.  That would be annoying
> since it's inefficient, and SPARC is the *only* architecture that
> would
> need it, as on every other architecture AES-XTS was optimized
> properly.
That would be appreciated. I'll see what I can do on the qemu side, but
that probably won't be in a release any time soon.
> 
> Anyway, I'll be migrating the SPARC optimized AES-{ECB,CBC,CTR} into
> the
> library too.  I'll need your help to test it, since it's completely
> untestable for anyone without SPARC hardware.  (And it will soon the
> only arch with that property now that even s390 is being fixed...)
Just say the word and I will test it.

Best regards,
Stian

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2026-09-30  6:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-29 21:12 Stian Halseth
2026-09-29 21:24 ` Eric Biggers
2026-09-29 21:33   ` Stian Halseth
2026-09-29 22:57     ` Eric Biggers
2026-09-30  6:44       ` Stian Halseth [this message]

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=ca018424c1e299520568a24ac04151fc55c9a685.camel@itx.no \
    --to=stian@itx.no \
    --cc=Jason@zx2c4.com \
    --cc=andreas@gaisler.com \
    --cc=ardb@kernel.org \
    --cc=davem@davemloft.net \
    --cc=ebiggers@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparclinux@vger.kernel.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

all inboxes | Powered by JetHome®