Re: [Qemu-devel] [RFC v1 1/1] virtio-crypto: Allow disabling of cipher algorithms for virtio-crypto device

[Christian Borntraeger <borntraeger@de.ibm.com>]

On 06/13/2018 05:05 PM, Daniel P. Berrangé wrote:
> On Wed, Jun 13, 2018 at 11:01:05AM -0400, Farhan Ali wrote:
>> Hi Daniel
>>
>> On 06/13/2018 05:37 AM, Daniel P. Berrangé wrote:
>>> On Tue, Jun 12, 2018 at 03:48:34PM -0400, Farhan Ali wrote:
>>>> The virtio-crypto driver currently propagates to the guest
>>>> all the cipher algorithms that the backend cryptodev can
>>>> support. But in certain cases where the guest has more
>>>> performant mechanism to handle some algorithms, it would be
>>>> useful to propagate only a subset of the algorithms.
>>>
>>> I'm not really convinced by this.
>>>
>>> The performance of crypto algorithms has many influencing
>>> factors, making it pretty hard to decide which is best
>>> without actively testing specific impls and comparing
>>> them in a manner which matches the application usage
>>> pattern. eg in theory the kernel crypto impl of an alg
>>> is faster than a userspace impl, if the kernel uses
>>> hardware accel and userspace does not. This, however,
>>> ignores the overhead of the kernel/userspace switch.
>>> The real world performance winner, thus depends on the
>>> amount of data being processed in each operation. Some
>>> times userspace can win & sometimes kernel space can
>>> win. This is even more relevant to virtio-crypto as
>>> it has more expensive context switches.
>>
>> True. But what if the guest can perform some crypto algorithms without a
>> incurring a VM exit? For example in s390 we have the cpacf instructions to
>> perform crypto and this instruction is implemented for us by our hardware
>> virtualization technology. In such a case it would be better not to use
>> virtio-crypto's implementation of such a crypto algorithm.
>>
>> At the same time we would like to take advantage of virtio-crypto's
>> acceleration capabilities for certain crypto algorithms for which there is
>> no hardware assistance.
> 
> IIUC, the kernel's crypto layer can support multiple implementations of
> any algorithm. Providers can report a priority against implementations
> which influences which impl is used in practice. So if there's a native
> instruction for a partiuclar algorithm I would expect the impl registered
> for that to be designated higher priority than other impls, so that it is
> used in preference to other impls.

Yes. This is what the kernel currently does. Back then I asked Gonglei to reduce
the default priority of virtio-crypto  (it was 501 and thus higher than anybody
else). Right now virtio-crypto has lower priority than the s390 cpacf code.

What does make sense though, is to actually have a mean to synchronize between
guest driver and host provider about what are actually supported operations.

Right now you only have aes cbc. What happens now, when a new driver also supports
lets say sha3, but the host does not. Having some kind of handshaking certainly 
makes sense. Do we need this configurable? This is another question.