similar to: [PATCH v2] virtio-crypto: adjust priority of algorithm

Some hardware accelerators (like intel aseni or the s390 cpacf functions) have lower priorities than virtio crypto, and those drivers are faster than the same in the host via virtio. So let's lower the priority of virtio-crypto's algorithm, make it's higher than sofeware implimentations but lower than the hardware ones. Suggested-by: Christian Borntraeger <borntraeger at

Some hardware accelerators (like intel aseni or the s390 cpacf functions) have lower priorities than virtio crypto, and those drivers are faster than the same in the host via virtio. So let's lower the priority of virtio-crypto's algorithm, make it's higher than sofeware implimentations but lower than the hardware ones. Suggested-by: Christian Borntraeger <borntraeger at

ACK. Whoever takes this patch might want to fixup 3 typos. On 01/13/2017 07:25 AM, Gonglei wrote: > Some hardware accelerators (like intel aseni or the s390 aesni > cpacf functions) have lower priorities than virtio > crypto, and those drivers are faster than the same in > the host via virtio. So let's lower the priority of > virtio-crypto's algorithm, make it's

On 12/15/2016 03:03 AM, Gonglei wrote: [...] > + > +static struct crypto_alg virtio_crypto_algs[] = { { > + .cra_name = "cbc(aes)", > + .cra_driver_name = "virtio_crypto_aes_cbc", > + .cra_priority = 501, This is still higher than the hardware-accelerators (like intel aesni or the s390 cpacf functions or the arm hw). aesni and s390/cpacf are supported by the

On 12/15/2016 03:03 AM, Gonglei wrote: [...] > + > +static struct crypto_alg virtio_crypto_algs[] = { { > + .cra_name = "cbc(aes)", > + .cra_driver_name = "virtio_crypto_aes_cbc", > + .cra_priority = 501, This is still higher than the hardware-accelerators (like intel aesni or the s390 cpacf functions or the arm hw). aesni and s390/cpacf are supported by the

On 01/10/2017 01:36 PM, Gonglei (Arei) wrote: > Hi, > >> >> On 12/15/2016 03:03 AM, Gonglei wrote: >> [...] >>> + >>> +static struct crypto_alg virtio_crypto_algs[] = { { >>> + .cra_name = "cbc(aes)", >>> + .cra_driver_name = "virtio_crypto_aes_cbc", >>> + .cra_priority = 501, >> >> >> This

On 01/10/2017 01:36 PM, Gonglei (Arei) wrote: > Hi, > >> >> On 12/15/2016 03:03 AM, Gonglei wrote: >> [...] >>> + >>> +static struct crypto_alg virtio_crypto_algs[] = { { >>> + .cra_name = "cbc(aes)", >>> + .cra_driver_name = "virtio_crypto_aes_cbc", >>> + .cra_priority = 501, >> >> >> This

On Thu, Jan 12, 2017 at 03:10:25PM +0100, Christian Borntraeger wrote: > On 01/10/2017 01:56 PM, Christian Borntraeger wrote: > > On 01/10/2017 01:36 PM, Gonglei (Arei) wrote: > >> Hi, > >> > >>> > >>> On 12/15/2016 03:03 AM, Gonglei wrote: > >>> [...] > >>>> + > >>>> +static struct crypto_alg

On Thu, Jan 12, 2017 at 03:10:25PM +0100, Christian Borntraeger wrote: > On 01/10/2017 01:56 PM, Christian Borntraeger wrote: > > On 01/10/2017 01:36 PM, Gonglei (Arei) wrote: > >> Hi, > >> > >>> > >>> On 12/15/2016 03:03 AM, Gonglei wrote: > >>> [...] > >>>> + > >>>> +static struct crypto_alg

Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface") dated 20 august 2015 introduced the new skcipher API which is supposed to replace both blkcipher and ablkcipher. While all consumers of the API have been converted long ago, some producers of the ablkcipher remain, forcing us to keep the ablkcipher support routines alive, along with the matching code to expose

Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface") dated 20 august 2015 introduced the new skcipher API which is supposed to replace both blkcipher and ablkcipher. While all consumers of the API have been converted long ago, some producers of the ablkcipher remain, forcing us to keep the ablkcipher support routines alive, along with the matching code to expose

crypto engine was introduced since 'commit 735d37b5424b ("crypto: engine - Introduce the block request crypto engine framework")' which uses work queue to realize the asynchronous processing for ablk_cipher and ahash. For virtio-crypto device, I register an engine for each data virtqueue so that we can use the capability of multiple data queues in future. Cc: Baolin Wang

crypto engine was introduced since 'commit 735d37b5424b ("crypto: engine - Introduce the block request crypto engine framework")' which uses work queue to realize the asynchronous processing for ablk_cipher and ahash. For virtio-crypto device, I register an engine for each data virtqueue so that we can use the capability of multiple data queues in future. Cc: Baolin Wang

On 01/10/2017 01:56 PM, Christian Borntraeger wrote: > On 01/10/2017 01:36 PM, Gonglei (Arei) wrote: >> Hi, >> >>> >>> On 12/15/2016 03:03 AM, Gonglei wrote: >>> [...] >>>> + >>>> +static struct crypto_alg virtio_crypto_algs[] = { { >>>> + .cra_name = "cbc(aes)", >>>> + .cra_driver_name =

Hi, > > On 12/15/2016 03:03 AM, Gonglei wrote: > [...] > > + > > +static struct crypto_alg virtio_crypto_algs[] = { { > > + .cra_name = "cbc(aes)", > > + .cra_driver_name = "virtio_crypto_aes_cbc", > > + .cra_priority = 501, > > > This is still higher than the hardware-accelerators (like intel aesni or the > s390 cpacf

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit 8c855f0720ff006d75d0a2512c7f6c4f60ff60ee ] The system'll crash when the users insmod crypto/tcrypto.ko with mode=155 ( testing "authenc(hmac(sha1),cbc(aes))" ). It's caused by reuse the memory of request structure. In crypto_authenc_init_tfm(), the reqsize is set to: [PART 1] sizeof(authenc_request_ctx) +

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit 8c855f0720ff006d75d0a2512c7f6c4f60ff60ee ] The system'll crash when the users insmod crypto/tcrypto.ko with mode=155 ( testing "authenc(hmac(sha1),cbc(aes))" ). It's caused by reuse the memory of request structure. In crypto_authenc_init_tfm(), the reqsize is set to: [PART 1] sizeof(authenc_request_ctx) +

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit 8c855f0720ff006d75d0a2512c7f6c4f60ff60ee ] The system'll crash when the users insmod crypto/tcrypto.ko with mode=155 ( testing "authenc(hmac(sha1),cbc(aes))" ). It's caused by reuse the memory of request structure. In crypto_authenc_init_tfm(), the reqsize is set to: [PART 1] sizeof(authenc_request_ctx) +

In order to allow for CBC to be chained, which is something that the CTS template relies upon, implementations of CBC need to pass the IV to be used for subsequent invocations via the IV buffer. This was not implemented yet for virtio-crypto so implement it now. Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver") Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc:

In order to allow for CBC to be chained, which is something that the CTS template relies upon, implementations of CBC need to pass the IV to be used for subsequent invocations via the IV buffer. This was not implemented yet for virtio-crypto so implement it now. Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver") Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: