VirtIO-Crypto support on Ten64?

Ten64 Forum
1

The Layerscape 1088A contains an accelerator called Security Engine (SEC). To this, the CAAM exists that provides the ability of fast data moval between SEC and host memory. Considering that the 1088A supports KVM at the same time, I wonder if one could either provide direct HW access from a specific VM or even better utilise virtio-crypto-pci, such as:

-object cryptodev-backend-builtin,id=cryptodev0 \
-device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \

While there is quite some documentation about virtio-crypto-pci, I wonder if that would work?

Before changing muvirt, I first tried to figure out the device ids and hence if maybe the entire HW device could be passed into the VM, however:

root@muvirt:~# lspci
0000:00:00.0 PCI bridge: Freescale Semiconductor Inc Device 80c0 (rev 10)
0000:01:00.0 Non-Volatile memory controller: Sandisk Corp PC SN520 NVMe SSD (rev 01)
0001:00:00.0 PCI bridge: Freescale Semiconductor Inc Device 80c0 (rev 10)
0001:01:00.0 PCI bridge: Pericom Semiconductor Device b304 (rev 01)
0001:02:01.0 PCI bridge: Pericom Semiconductor Device b304 (rev 01)
0001:02:02.0 PCI bridge: Pericom Semiconductor Device b304 (rev 01)
0002:00:00.0 PCI bridge: Freescale Semiconductor Inc Device 80c0 (rev 10)
0002:01:00.0 SATA controller: JMicron Technology Corp. JMB58x AHCI SATA controller

No clear pci-device, while dmesg and lsmod tell me that CAAM is given:

root@muvirt:~# lsmod | grep -i caam
akcipher               16384  2 caam_jr,rsa_generic
authenc                16384  2 dpaa2_caam,caam_jr
caam                   28672  1 caam_jr
caam_jr               172032  0 
caamalg_desc           36864  2 dpaa2_caam,caam_jr
caamhash_desc          16384  2 dpaa2_caam,caam_jr
crypto_engine          16384  1 caam_jr
dpaa2_caam             94208  0 
error                  24576  5 dpaa2_caam,caam_jr,caamhash_desc,caamalg_desc,caam
libdes                 24576  3 dpaa2_caam,caam_jr,des_generic
rng_core               20480  2 caam_jr,tpm
rsa_generic            20480  1 caam_jr
root@muvirt:~# dmesg | grep -i caam
[    8.386544] caam 8000000.crypto: device ID = 0x0a13030000000000 (Era 8)
[    8.386549] caam 8000000.crypto: job rings = 3, qi = 1
[    8.395563] caam algorithms registered in /proc/crypto
[    8.396433] caam 8000000.crypto: caam pkc algorithms registered in /proc/crypto
[    8.396438] caam 8000000.crypto: registering rng-caam
[    8.399659] dpaa2_caam dpseci.0: Adding to iommu group 2
[    8.401313] dpaa2_caam dpseci.0: dpseci v5.3
[    8.432577] dpaa2_caam dpseci.0: algorithms registered in /proc/crypto
[    8.433277] dpaa2_caam dpseci.0: hash algorithms registered in /proc/crypto

I wonder, in case one would just like to pass through SEC and CAAM into the VM, if one could use in some fashion the printed device id?
Or did anyone tried virtio-crypto-pci on the Ten64?

2

Fascinating question!

You can already do this by having a DPSECI object in a DPAA2 container that is passed through to the VM, the same way you can pass through DPAA2 network interfaces (DPNIs).

I haven’t tested how well it performs, though the passthrough in general appears to have a performance hit due to interrupts having to be routed through QEMU.
(This generation of ARM hardware doesn’t have the ability to inject interrupts straight into a guest VM, but newer designs can)

virtio-crypto may work better and would be simpler to use (no custom DPAA2 setup, better out of the box support in distributions)

I’m planning to do a “muvirt-next” branch based on 5.15 and a newer QEMU soon so we can test some of these newer features.

1 Like
3

I am truly looking forward for the “muvirt-next” branch :slight_smile: Just let me know, I will try it as well :slight_smile: