search for: cryptodev

Hello I have a server with an hardware crypto accelator. For giving userspace access to it I use the cryptodev module (http://cryptodev-linux.org/) I have also the cryptodev engine compiled in openssl. When I modprobe the cryptodev module, I cannot login with ssh on the server. The symptom can be found with dmesg: audit: type=1326 audit(1424784807.257:3): auid=4294967295 uid=22 gid=22 ses=4294967295 pid=1...

Hello, I just set up Debian Lenny on a PCEngines ALIX. This board have a GeodeLX processor with hardware crypto accelerator, so I patched my kernel to get cryptodev support. Everything is fine when playin with openssl, but openssh just crash when a large amount of data is transfered. A small example: alix:~# scp 100meg.test localhost:/dev/null root at localhost's password: 100meg.test...

I got roughly the same performance results when I use the openssl speed test with and without a hifn 7956 cryto card Here's what I did: After the card is plugged in, kldload hifn; kldload cryptodev; I got the message: hifn0 mem 0xfc8f0000-0xfc8f7ffff, 0xfc8f0000-0xfc8f7ffff, 0xfc8f0000-0xfc8f7ffff irg 28 at device 3.0 on pci1 hifn0: Hifn 7956, rev 0, 32KB dram, pll=0x800<pci clk, 4x mult> Then I ran: Openssl speed des-cbc And got the following result: 16 bytes 64 bytes 256 bytes 10...

...); < > < > Would it make sense to use a per virtqueue lock < > like in virtio_blk for example instead of locking on the whole < > device? OK, it seems you use only one dataqueue, so it < > may not be that relevant. < > < Currently yes, both the backend device (cryptodev-backend-builtin) < and the frontend driver use one dataqueue. < I think it makes sense to use per virtqueue lock here though it only uses one queue so far, but in the spec we already have multi queues support. < Regards, < -Gonglei

...); < > < > Would it make sense to use a per virtqueue lock < > like in virtio_blk for example instead of locking on the whole < > device? OK, it seems you use only one dataqueue, so it < > may not be that relevant. < > < Currently yes, both the backend device (cryptodev-backend-builtin) < and the frontend driver use one dataqueue. < I think it makes sense to use per virtqueue lock here though it only uses one queue so far, but in the spec we already have multi queues support. < Regards, < -Gonglei

Hi Gonglei, [auto build test ERROR on cryptodev/master] [also build test ERROR on v4.9-rc7 next-20161202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gonglei/crypto-add-virtio-crypto-driver/20161202-190424 base: https://git.kernel.org/pub/s...

Hi Gonglei, [auto build test ERROR on cryptodev/master] [also build test ERROR on v4.9-rc7 next-20161202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gonglei/crypto-add-virtio-crypto-driver/20161202-190424 base: https://git.kernel.org/pub/s...

On (Mon) 14 Jul 2014 [20:50:06], Herbert Xu wrote: > On Thu, Jul 10, 2014 at 03:42:33PM +0530, Amit Shah wrote: > > v3: > > - Kees Cook pointed out a weird side-effect: devices which have > > ->init() registered get their randomness added to the system each > > time they're switched in, but devices that don't have the init > > callback

On (Mon) 14 Jul 2014 [20:50:06], Herbert Xu wrote: > On Thu, Jul 10, 2014 at 03:42:33PM +0530, Amit Shah wrote: > > v3: > > - Kees Cook pointed out a weird side-effect: devices which have > > ->init() registered get their randomness added to the system each > > time they're switched in, but devices that don't have the init > > callback

...rypto: stm32-hash: convert to the new crypto engine API > > crypto: stm32-cryp: convert to the new crypto engine API > > All applied. Thanks. Hello As mentionned in the cover letter, all patchs (except documentation one) should be squashed. A kbuild robot reported a build error on cryptodev due to this. Regards

On 12/14/2016 12:50 PM, Gonglei wrote: > diff --git a/drivers/crypto/virtio/virtio_crypto_core.c b/drivers/crypto/virtio/virtio_crypto_core.c > new file mode 100644 > index 0000000..c0854a1 > --- /dev/null > +++ b/drivers/crypto/virtio/virtio_crypto_core.c > @@ -0,0 +1,474 @@ [..] > + > +static void virtcrypto_dataq_callback(struct virtqueue *vq) > +{ > + struct

On 12/14/2016 12:50 PM, Gonglei wrote: > diff --git a/drivers/crypto/virtio/virtio_crypto_core.c b/drivers/crypto/virtio/virtio_crypto_core.c > new file mode 100644 > index 0000000..c0854a1 > --- /dev/null > +++ b/drivers/crypto/virtio/virtio_crypto_core.c > @@ -0,0 +1,474 @@ [..] > + > +static void virtcrypto_dataq_callback(struct virtqueue *vq) > +{ > + struct

...orentin wrote: > Hello > > When modprobing tcrypt on qemu 4.1.0 I get a kernel panic on 5.5-rc7 and next-20200122 > qemu is started by: > /usr/bin/qemu-system-x86_64 -cpu host -enable-kvm -nographic -net nic,model=e1000,macaddr=52:54:00:12:34:58 -net tap -m 512 -monitor none -object cryptodev-backend-builtin,id=cryptodev0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -append 'console=ttyS0 root=/dev/ram0 ip=dhcp' -kernel /var/lib/lava/dispatcher/tmp/41332/deployimages-td18675m/kernel/bzImage -initrd /var/lib/lava/dispatcher/tmp/41332/deployimages-td18675m/ramdisk/roo...

...a per virtqueue lock > > < > like in virtio_blk for example instead of locking on the whole > > < > device? OK, it seems you use only one dataqueue, so it > > < > may not be that relevant. > > < > > > < Currently yes, both the backend device (cryptodev-backend-builtin) > > < and the frontend driver use one dataqueue. > > < > > > > I think it makes sense to use per virtqueue lock here though it only uses one > > queue so far, > > but in the spec we already have multi queues support. > > > Yes, I...

...a per virtqueue lock > > < > like in virtio_blk for example instead of locking on the whole > > < > device? OK, it seems you use only one dataqueue, so it > > < > may not be that relevant. > > < > > > < Currently yes, both the backend device (cryptodev-backend-builtin) > > < and the frontend driver use one dataqueue. > > < > > > > I think it makes sense to use per virtqueue lock here though it only uses one > > queue so far, > > but in the spec we already have multi queues support. > > > Yes, I...

...; > > > When modprobing tcrypt on qemu 4.1.0 I get a kernel panic on 5.5-rc7 and next-20200122 > > > qemu is started by: > > > /usr/bin/qemu-system-x86_64 -cpu host -enable-kvm -nographic -net nic,model=e1000,macaddr=52:54:00:12:34:58 -net tap -m 512 -monitor none -object cryptodev-backend-builtin,id=cryptodev0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -append 'console=ttyS0 root=/dev/ram0 ip=dhcp' -kernel /var/lib/lava/dispatcher/tmp/41332/deployimages-td18675m/kernel/bzImage -initrd /var/lib/lava/dispatcher/tmp/41332/deployimages-td18675m/ramdisk/roo...

...nion? Sam and David? Thanks, -Gonglei > -----Original Message----- > From: kbuild test robot [mailto:lkp at intel.com] > Sent: Sunday, December 04, 2016 10:40 AM > Subject: Re: [PATCH v5 1/1] crypto: add virtio-crypto driver > > Hi Gonglei, > > [auto build test ERROR on cryptodev/master] > [also build test ERROR on v4.9-rc7 next-20161202] > [if your patch is applied to the wrong git tree, please drop us a note to help > improve the system] > > url: > https://github.com/0day-ci/linux/commits/Gonglei/crypto-add-virtio-crypto-dri > ver/20161202-190424 &gt...

...save(&vcrypto->lock, flags); > > Would it make sense to use a per virtqueue lock > like in virtio_blk for example instead of locking on the whole > device? OK, it seems you use only one dataqueue, so it > may not be that relevant. > Currently yes, both the backend device (cryptodev-backend-builtin) and the frontend driver use one dataqueue. Regards, -Gonglei

...uld it make sense to use a per virtqueue lock > < > like in virtio_blk for example instead of locking on the whole > < > device? OK, it seems you use only one dataqueue, so it > < > may not be that relevant. > < > > < Currently yes, both the backend device (cryptodev-backend-builtin) > < and the frontend driver use one dataqueue. > < > > I think it makes sense to use per virtqueue lock here though it only uses one > queue so far, > but in the spec we already have multi queues support. > Yes, I agree. Will do that in V8 soon. Hope t...

...the AEAD extension of the > stm32-cryp driver (successfully tested with your engine upgrade proposal). > > > I have also tested the stm32-hash patch. > > Note that stm32-cryp (new driver applied by Herbert recently > [https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=9e054ec21ef8344345b28603fb272fe999f735db]) > would also need to be converted to the new crypto engine API : this is a > trivial patch. Yes, patch for converting it is already done. > > Thank you for your proposal, I hope that this proposal is fine for > Herbe...