From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8pwJ-0003KG-5l for qemu-devel@nongnu.org; Mon, 21 Nov 2016 09:51:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8pwG-0006zZ-1X for qemu-devel@nongnu.org; Mon, 21 Nov 2016 09:51:23 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:33870 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c8pwF-0006yf-Rk for qemu-devel@nongnu.org; Mon, 21 Nov 2016 09:51:19 -0500 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uALEn9wh145096 for ; Mon, 21 Nov 2016 09:51:18 -0500 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0b-001b2d01.pphosted.com with ESMTP id 26uyp8e6n6-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Nov 2016 09:51:17 -0500 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 21 Nov 2016 14:51:16 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 79EC92190072 for ; Mon, 21 Nov 2016 14:50:26 +0000 (GMT) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uALEpDD033226822 for ; Mon, 21 Nov 2016 14:51:13 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id uALEpBlR013303 for ; Mon, 21 Nov 2016 07:51:13 -0700 Date: Mon, 21 Nov 2016 15:51:08 +0100 From: Cornelia Huck In-Reply-To: References: <1478856187-284644-1-git-send-email-arei.gonglei@huawei.com> <1478856187-284644-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: <20161121155108.5276630e.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] [PATCH v14 1/2] virtio-crypto: Add virtio crypto device specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: gong lei Cc: Halil Pasic , Gonglei , "qemu-devel@nongnu.org" , "virtio-dev@lists.oasis-open.org" , "weidong.huang@huawei.com" , "mst@redhat.com" , "john.griffin@intel.com" , "Shiqing.Fan@huawei.com" , "jianjay.zhou@huawei.com" , "Varun.Sethi@freescale.com" , "denglingli@chinamobile.com" , "hanweidong@huawei.com" , "agraf@suse.de" , "nmorey@kalray.eu" , "vincent.jardin@6wind.com" , "Ola.Liljedahl@arm.com" , "luonengjun@huawei.com" , "xin.zeng@intel.com" , "peter.huangpeng@huawei.com" , "liang.j.ma@intel.com" , "stefanha@redhat.com" , "Jani.Kokkonen@huawei.com" , "brian.a.keating@intel.com" , "claudio.fontana@huawei.com" , "mike.caraman@nxp.com" , "wu.wubin@huawei.com" On Sun, 20 Nov 2016 08:45:57 +0000 gong lei wrote: > On 2016/11/17 2:11, Halil Pasic wrote: > > On 11/11/2016 10:23 AM, Gonglei wrote: > >> +The value of the \field{status} field is VIRTIO_CRYPTO_S_HW_READY or VIRTIO_CRYPTO_S_STARTED. > >> + > >> +\begin{lstlisting} > >> +#define VIRTIO_CRYPTO_S_HW_READY (1 << 0) > >> +#define VIRTIO_CRYPTO_S_STARTED (1 << 1) > >> +\end{lstlisting} > >> + > > Could not really figure out what this status actually does and how does > > it relate to the device status field if at all. > > > > Furthermore I see no mention of VIRTIO_CRYPTO_S_STARTED except for this > > one, so the only thing I can think of is that it's the initial value and > > means hardware not ready (you state these are the only two values). > Good catch. I set VIRTIO_CRYPTO_S_STARTED in the driver if the > virtio-crypto driver is ready to > work in the guest (registing to the Linux Crypto Framework and the > device is ready), vice versa. Can you use DRIVER_OK in the generic status field for that? > > > This however does not seem consistent with what your QEMU reference > > implementation does. Another thing is your implementations seem to > > use VIRTIO_CRYPTO_S_HW_READY as flag but your specification would > > (prohibit combining flags because you get another value). > The QEMU side doesn't use VIRTIO_CRYPTO_S_STARTED, so maybe I can remove > it from > the spec and define it in the driver. Does it make sense? I think it makes most sense if you consider this status field to be device-set only. The HW_READY flag makes sense as it gives the driver additional information (much like the LINK_UP flag for virtio-net), but I'm not sure what driver status you need beyond what you can already provide via the generic status field. In any case, the status field should use flags and not mutually exclusive values.