From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBLk5-0000f8-9S for qemu-devel@nongnu.org; Mon, 28 Nov 2016 08:13:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBLk2-0001cX-4s for qemu-devel@nongnu.org; Mon, 28 Nov 2016 08:13:09 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:52267) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBLk1-0001bt-St for qemu-devel@nongnu.org; Mon, 28 Nov 2016 08:13:06 -0500 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uASDAHZZ098545 for ; Mon, 28 Nov 2016 08:13:00 -0500 Received: from e06smtp08.uk.ibm.com (e06smtp08.uk.ibm.com [195.75.94.104]) by mx0a-001b2d01.pphosted.com with ESMTP id 270ghm29q3-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 28 Nov 2016 08:13:00 -0500 Received: from localhost by e06smtp08.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 28 Nov 2016 13:12:52 -0000 Date: Mon, 28 Nov 2016 14:12:44 +0100 From: Cornelia Huck In-Reply-To: <1480334903-6672-2-git-send-email-arei.gonglei@huawei.com> References: <1480334903-6672-1-git-send-email-arei.gonglei@huawei.com> <1480334903-6672-2-git-send-email-arei.gonglei@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20161128141244.4defcfa1.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] [PATCH v3] crypto: add virtio-crypto driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gonglei Cc: 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, luonengjun@huawei.com, mst@redhat.com, stefanha@redhat.com, weidong.huang@huawei.com, wu.wubin@huawei.com, xin.zeng@intel.com, claudio.fontana@huawei.com, herbert@gondor.apana.org.au, pasic@linux.vnet.ibm.com, davem@davemloft.net, jianjay.zhou@huawei.com, hanweidong@huawei.com, arei.gonglei@hotmail.com, xuquan8@huawei.com, longpeng2@huawei.com, salvatore.benedetto@intel.com On Mon, 28 Nov 2016 20:08:23 +0800 Gonglei wrote: > +static int virtcrypto_update_status(struct virtio_crypto *vcrypto) > +{ > + u32 status; > + int err; > + > + virtio_cread(vcrypto->vdev, > + struct virtio_crypto_config, status, &status); > + > + /* Ignore unknown (future) status bits */ > + status &= VIRTIO_CRYPTO_S_HW_READY; I'm wondering what the driver really should do if it encounters unknown status bits. I'd expect that new status bits are guarded by a feature bit and that the device should not set status bits if the respective feature bit has not been negotiated. Therefore, unknown status bits would be a host error and the driver should consider the device to be broken. Thoughts? > + > + if (vcrypto->status == status) > + return 0; > + > + vcrypto->status = status; > + > + if (vcrypto->status & VIRTIO_CRYPTO_S_HW_READY) { > + err = virtcrypto_dev_start(vcrypto); > + if (err) { > + dev_err(&vcrypto->vdev->dev, > + "Failed to start virtio crypto device.\n"); > + virtcrypto_dev_stop(vcrypto); > + return -EPERM; > + } > + dev_info(&vcrypto->vdev->dev, "Accelerator is ready\n"); > + } else { > + virtcrypto_dev_stop(vcrypto); > + dev_info(&vcrypto->vdev->dev, "Accelerator is not ready\n"); > + } > + > + return 0; > +} > +