Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932698AbcLNPjp (ORCPT ); Wed, 14 Dec 2016 10:39:45 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:48041 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932656AbcLNPjn (ORCPT ); Wed, 14 Dec 2016 10:39:43 -0500 Subject: Re: [Qemu-devel] [PATCH v7 1/1] crypto: add virtio-crypto driver To: Gonglei , linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org, virtualization@lists.linux-foundation.org, linux-crypto@vger.kernel.org References: <1481716249-185392-1-git-send-email-arei.gonglei@huawei.com> <1481716249-185392-2-git-send-email-arei.gonglei@huawei.com> Cc: weidong.huang@huawei.com, claudio.fontana@huawei.com, mst@redhat.com, luonengjun@huawei.com, hanweidong@huawei.com, xin.zeng@intel.com, xuquan8@huawei.com, wanzongshun@huawei.com, stefanha@redhat.com, jianjay.zhou@huawei.com, cornelia.huck@de.ibm.com, longpeng2@huawei.com, arei.gonglei@hotmail.com, davem@davemloft.net, wu.wubin@huawei.com, herbert@gondor.apana.org.au From: Halil Pasic Date: Wed, 14 Dec 2016 16:38:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1481716249-185392-2-git-send-email-arei.gonglei@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16121415-0020-0000-0000-000002483FBB X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16121415-0021-0000-0000-00001EAF01C0 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-12-14_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612140258 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1704 Lines: 58 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 virtio_crypto *vcrypto = vq->vdev->priv; > + struct virtio_crypto_request *vc_req; > + unsigned long flags; > + unsigned int len; > + struct ablkcipher_request *ablk_req; > + int error; > + > + spin_lock_irqsave(&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. > + do { > + virtqueue_disable_cb(vq); > + while ((vc_req = virtqueue_get_buf(vq, &len)) != NULL) { > + if (vc_req->type == VIRTIO_CRYPTO_SYM_OP_CIPHER) { > + switch (vc_req->status) { > + case VIRTIO_CRYPTO_OK: > + error = 0; > + break; > + case VIRTIO_CRYPTO_INVSESS: > + case VIRTIO_CRYPTO_ERR: > + error = -EINVAL; > + break; > + case VIRTIO_CRYPTO_BADMSG: > + error = -EBADMSG; > + break; > + default: > + error = -EIO; > + break; > + } > + ablk_req = vc_req->ablkcipher_req; > + virtcrypto_clear_request(vc_req); > + > + spin_unlock_irqrestore(&vcrypto->lock, flags); > + /* Finish the encrypt or decrypt process */ > + ablk_req->base.complete(&ablk_req->base, error); > + spin_lock_irqsave(&vcrypto->lock, flags); > + } > + } > + } while (!virtqueue_enable_cb(vq)); > + spin_unlock_irqrestore(&vcrypto->lock, flags); > +}