> > > > > > > > > > > > > > > > > > On Mon, Jan 09, 2017 at 01:43:10PM +0000, Stefan Hajnoczi wrote: > > > > > > On Mon, Jan 09, 2017 at 03:04:55PM +0800, Longpeng (Mike) wrote: > > > > > > > I'm one of Gonglei's virtio-crypto project members, and we plan to > add a > > > > > AF_ALG > > > > > > > backend for virtio-crypto(there's only builtin-backend currently). > > > > > > > > > > > > > > I found that Catalin, Paolo and Stefan had discussed about this in > 2015 > > > > > > > (http://www.spinics.net/lists/kvm/msg115457.html), but it seems > that > > > > > Catalin > > > > > > > didn't do it, so I'm confuse about wether it is need to add a > > > > > > > AF_ALG > > > > > backend. > > > > > > > > > > > > > > Do you have any suggestion? Thanks :) > > > > > > > > > > > > I have no objections to an AF_ALG backend in QEMU. > > > > > > > > > > Rather than do another backend for virtio-crypto, IMHO, we should have > > > > > an AF_ALG impl of the crypto/ APIs. That way any potential performance > > > > > benefits will enhance our LUKS encryption code too. > > > > > > > > > According to the currently schemas of crypto/ APIs, we can't choose the > > > > specific backend dynamically. This is a limitation for virtio-crypto > > > > device I think. > > > > > > Do we really need to be able to choose the backend explicitly. If the > > > AF_ALG > > > backend is faster, why would you simply not use that automatically if it > > > is > > > available. > > > > Can we realize the purpose based on the crypto/ APIs? IIUC the crypto > > subsystem chooses a backend during the building according to the specific > priority, > > nettle > gcrypt > cipher-builtin. > > > > If we add an AF_ALG implementation for crypto subsystem, shall we set it > > as the highest priority? If so, other backends won't be used since AF_ALG > > is always available. If not, how can we use AF_ALG backend for crypto/ API? > > > > Please correct me if I'm missing something. > > While AF_ALG has been available for a while, not all features have. For > example AEAD support was only added in kernel 4.1 > OK.
> So if we had AF_ALG in QEMU, we would have to have a stacked impl, where > we try AF_ALG and then fallback to the current code when QEMU runs on a > kernel lacking the feature needed. > It makes sense though the implementation will be more complicate since the code should identify the different error codes are returned by AF_ALG APIs. > We could potentially also have a global arg to switch backends e.g. > > -crypto-backend [afalg|builtin] > So the backend here is not the cryptodev backend? Thanks, -Gonglei
