From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjlZ5-00030u-Uv for qemu-devel@nongnu.org; Tue, 13 Sep 2016 07:07:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjlZ1-0000K8-7J for qemu-devel@nongnu.org; Tue, 13 Sep 2016 07:07:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjlZ1-0000JB-2P for qemu-devel@nongnu.org; Tue, 13 Sep 2016 07:07:43 -0400 Date: Tue, 13 Sep 2016 12:07:35 +0100 From: "Daniel P. Berrange" Message-ID: <20160913110735.GT30949@redhat.com> Reply-To: "Daniel P. Berrange" References: <1473738741-220600-1-git-send-email-arei.gonglei@huawei.com> <20160913085746.GB30949@redhat.com> <33183CC9F5247A488A2544077AF19020B03C927D@SZXEMA503-MBS.china.huawei.com> <20160913095405.GI30949@redhat.com> <2333ce23-e880-9dd7-af00-28cae177852f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2333ce23-e880-9dd7-af00-28cae177852f@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 00/15] virtio-crypto: introduce framework and device emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Gonglei (Arei)" , "qemu-devel@nongnu.org" , "virtio-dev@lists.oasis-open.org" , "Huangpeng (Peter)" , Luonengjun , "mst@redhat.com" , "stefanha@redhat.com" , "Huangweidong (C)" , "mike.caraman@nxp.com" , "agraf@suse.de" , "xin.zeng@intel.com" , Claudio Fontana , "nmorey@kalray.eu" , "vincent.jardin@6wind.com" On Tue, Sep 13, 2016 at 12:58:59PM +0200, Paolo Bonzini wrote: > > > On 13/09/2016 11:54, Daniel P. Berrange wrote: > > > OK, I agree with you :) But if we support multiple backends, can > > > we keep cryptodev-linux module as one option? > > > > I'm personally against any support for out of tree kernel modules > > in QEMU, regardless of whether QEMU also implements alternative > > backends, unless there is a strong sign that the module in question > > is on the verge of being accepted into mainline Linux. That does > > not seem to be the case there - mainline settled on AF_ALG as the > > only supported approach AFAICT. > > Is there any reason to embed knowledge of AF_ALG directly in QEMU, > rather than delegating that to gcrypt/nettle? Actually looking at the code again, neither of those libraries will ever delegate to the kernel. So if we did want AF_ALG, we would have to provide a backend in QEMU to use that. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|