Re: [RFC PATCH 2/2] Removes the x86 dependency on the QAT drivers

[Andre Przywara <andre.przywara@arm.com>]

On Tue, 24 May 2022 08:51:31 +0100
Giovanni Cabiddu <giovanni.cabiddu@intel.com> wrote:

Hi,

> On Wed, May 18, 2022 at 02:00:40PM +0100, Yoan Picchi wrote:
> > >> From: Yoan Picchi <yoan.picchi@arm.com>
> > >>
> > >> The QAT acceleration card can be very helpfull for some tasks like
> > >> dealing with IPSEC but it is currently restricted to be used only on x86  
> > machine.  
> > >> Looking at the code we didn't see any reasons why those drivers might
> > >> not work on other architectures. We've successfully built all of them
> > >> on x86, arm64, arm32, mips64, powerpc64, riscv64 and sparc64.
> > >>
> > >> We also have tested the driver with an Intel Corporation C62x Chipset
> > >> QuickAssist Technology (rev 04) PCIe card on an arm64 server. After
> > >> the numa patch, it works with the AF_ALG crypto userland interface,
> > >> allowing us to encrypt some data with cbc for instance. We've also
> > >> successfully created some VF, bound them to DPDK, and used the card
> > >> this way, thus showing some real life usecases of x86 do work on arm64  
> > too.  
> > >>
> > >> Please let us know if we missed something that would warrants some
> > >> further testing.  
> > >Thanks Yoan.
> > >
> > >Can you please confirm that you tested the driver on the platform you  
> > reported using a kernel with CONFIG_CRYPTO_MANAGER_DISABLE_TESTS not set and
> > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y and the self test >is passing?  
> > >You can check it by running
> > >��� $ cat /proc/crypto | grep -B 4 passed | grep -e "qat_\|qat-" | sort  
> > This should report:  
> > >��� driver������ : qat_aes_cbc
> > >��� driver������ : qat_aes_cbc_hmac_sha1
> > >��� driver������ : qat_aes_cbc_hmac_sha256
> > >��� driver������ : qat_aes_cbc_hmac_sha512
> > >��� driver������ : qat_aes_ctr
> > >��� driver������ : qat_aes_xts
> > >��� driver������ : qat-dh
> > >��� driver������ : qat-rsa
> > >
> > >Note that if you are using the HEAD of cryptodev-2.6 you will have to  
> > either revert 8893d27ffcaf6ec6267038a177cb87bcde4dd3de or apply  
> > >https://patchwork.kernel.org/project/linux-crypto/list/?series=639755 as  
> > the algorithms have been temporarily disabled.  
> > >
> > >Regards,
> > >
> > >--
> > >Giovanni  
> > 
> > Hi Giovanni.
> > 
> > Thanks for the instructions, I did not know of this test.
> > I rebuilt my kernel on arm64 with those parameter and I confirm I get the
> > same output with
> > $ cat /proc/crypto | grep -B 4 passed | grep -e "qat_\|qat-" | sort  
> Thats great. Thanks.
> 
> Is the platform where you ran the tests little or big endian?

It's definitely little endian.
The cores in there can be switched between LE and BE, but I think
realistically no one ever runs a BE configuration. Compiling the kernel
for BE is rather straight-forward, but I wouldn't know of any serious
userland to run with it (short of a self-compiled busybox or buildroot).

> If little endian, can you re-test on a big endian system?

So you can just compile a kernel with CONFIG_CPU_BIG_ENDIAN=y, but you
cannot boot it easily, since CONFIG_EFI depends on !CPU_BIG_ENDIAN,
and UEFI is the only way to boot that (server) machine.
So kexec and a KVM guest are the other options. Kexec has the disadvantage of
requiring a DT (because ACPI is also incompatible with BE), and for KVM we
would need to check whether this actually works, since BE guests are much
less tested, plus the device pass-through imposing more challenges.

So testing this in BE is a bit more involved, and the practicality of such
a setup is very questionable. If you are concerned, should we just say:
	depends on PCI && !CPU_BIG_ENDIAN
At least until we have reports that confirm proper BE operation?

Cheers,
Andre