[{"id":1769223,"web_url":"http://patchwork.ozlabs.org/comment/1769223/","msgid":"","list_archive_url":null,"date":"2017-09-15T14:39:40","subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/11/2017 03:12 AM, Longpeng(Mike) wrote:\n> From: Gonglei \n> \n> The virtio crypto device is a virtual crypto device (ie. hardware\n> crypto accelerator card). Currently, the virtio crypto device provides\n> the following crypto services: CIPHER, MAC, HASH, and AEAD.\n> \n> In this patch, CIPHER, MAC, HASH, AEAD services are introduced.\n> \n> VIRTIO-153\n> \n> Signed-off-by: Gonglei \n> Signed-off-by: Longpeng(Mike) \n> ---\n> acknowledgements.tex | 3 +\n> content.tex | 2 +\n> virtio-crypto.tex | 1479 ++++++++++++++++++++++++++++++++++++++++++++++++++\n> 3 files changed, 1484 insertions(+)\n> create mode 100644 virtio-crypto.tex\n> \n> diff --git a/acknowledgements.tex b/acknowledgements.tex\n> index 6c86d12..c4b6844 100644\n> --- a/acknowledgements.tex\n> +++ b/acknowledgements.tex\n> @@ -26,6 +26,8 @@ Sasha Levin,\tOracle\t\\newline\n> Sergey Tverdyshev,\tThales e-Security\t\\newline\n> Stefan Hajnoczi,\tRed Hat\t\\newline\n> Tom Lyon,\tSamya Systems, Inc.\t\\newline\n> +Lei Gong,\tHuawei\t\\newline\n> +Peng Long,\tHuawei\t\\newline\n> \\end{oasistitlesection}\n> \n> The following non-members have provided valuable feedback on this\n> @@ -43,4 +45,5 @@ Laura Novich, Red Hat\t\\newline\n> Patrick Durusau,\tTechnical Advisory Board, OASIS\t\\newline\n> Thomas Huth,\tIBM\t\\newline\n> Yan Vugenfirer, Red Hat / Daynix\t\\newline\n> +Halil Pasic,\tIBM\t\\newline\n> \\end{oasistitlesection}\n> diff --git a/content.tex b/content.tex\n> index d989d98..7710f8c 100644\n> --- a/content.tex\n> +++ b/content.tex\n> @@ -5641,6 +5641,8 @@ descriptor for the \\field{sense_len}, \\field{residual},\n> \\field{status_qualifier}, \\field{status}, \\field{response} and\n> \\field{sense} fields.\n> \n> +\\input{virtio-crypto.tex}\n> +\n> \\chapter{Reserved Feature Bits}\\label{sec:Reserved Feature Bits}\n> \n> Currently there are three device-independent feature bits defined:\n> diff --git a/virtio-crypto.tex b/virtio-crypto.tex\n> new file mode 100644\n> index 0000000..1e75cbc\n> --- /dev/null\n> +++ b/virtio-crypto.tex\n> @@ -0,0 +1,1479 @@\n> +\\section{Crypto Device}\\label{sec:Device Types / Crypto Device}\n> +\n> +The virtio crypto device is a virtual cryptography device as well as a\n> +virtual cryptographic accelerator. The virtio crypto device provides the\n> +following crypto services: CIPHER, MAC, HASH, and AEAD. Virtio crypto\n> +devices have a single control queue and at least one data queue. Crypto\n> +operation requests are placed into a data queue, and serviced by the\n> +device. Some crypto operation requests are only valid in the context of a\n> +session. The role of the control queue is facilitating control operation\n> +requests. Sessions management is realized with control operation\n> +requests.\n> +\n> +\\subsection{Device ID}\\label{sec:Device Types / Crypto Device / Device ID}\n> +\n> +20\n> +\n> +\\subsection{Virtqueues}\\label{sec:Device Types / Crypto Device / Virtqueues}\n> +\n> +\\begin{description}\n> +\\item[0] dataq1\n> +\\item[\\ldots]\n> +\\item[N-1] dataqN\n> +\\item[N] controlq\n> +\\end{description}\n> +\n> +N is set by \\field{max_dataqueues}.\n> +\n> +\\subsection{Feature bits}\\label{sec:Device Types / Crypto Device / Feature bits}\n> +\n> +\\begin{description}\n> +\\item VIRTIO_CRYPTO_F_MUX_MODE (0) multiplexing mode is available.\n> +\\item VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE (1) stateless mode is available for CIPHER service.\n> +\\item VIRTIO_CRYPTO_F_HASH_STATELESS_MODE (2) stateless mode is available for HASH service.\n> +\\item VIRTIO_CRYPTO_F_MAC_STATELESS_MODE (3) stateless mode is available for MAC service.\n> +\\item VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE (4) stateless mode is available for AEAD service.\n> +\\end{description}\n> +\n> +\\subsubsection{Feature bit requirements}\\label{sec:Device Types / Crypto Device / Feature bits}\n> +\n> +Some crypto feature bits require other crypto feature bits\n> +(see \\ref{drivernormative:Basic Facilities of a Virtio Device / Feature Bits}):\n> +\n> +\\begin{description}\n> +\\item[VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.\n> +\\item[VIRTIO_CRYPTO_F_HASH_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.\n> +\\item[VIRTIO_CRYPTO_F_MAC_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.\n> +\\item[VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.\n> +\\end{description}\n> +\n> +\\subsection{Supported crypto services}\\label{sec:Device Types / Crypto Device / Supported crypto services}\n> +\n> +The following crypto services are defined:\n> +\n> +\\begin{lstlisting}\n> +/* CIPHER service */\n> +#define VIRTIO_CRYPTO_SERVICE_CIPHER 0\n> +/* HASH service */\n> +#define VIRTIO_CRYPTO_SERVICE_HASH 1\n> +/* MAC (Message Authentication Codes) service */\n> +#define VIRTIO_CRYPTO_SERVICE_MAC 2\n> +/* AEAD (Authenticated Encryption with Associated Data) service */\n> +#define VIRTIO_CRYPTO_SERVICE_AEAD 3\n> +\\end{lstlisting}\n> +\n> +The above constants designate bits used to indicate the which of crypto services are\n> +offered by the device as described in, see \\ref{sec:Device Types / Crypto Device / Device configuration layout}.\n> +\n> +\\subsubsection{CIPHER services}\\label{sec:Device Types / Crypto Device / Supported crypto services / CIPHER services}\n> +\n> +The following CIPHER algorithms are defined:\n> +\n> +\\begin{lstlisting}\n> +#define VIRTIO_CRYPTO_NO_CIPHER 0\n> +#define VIRTIO_CRYPTO_CIPHER_ARC4 1\n> +#define VIRTIO_CRYPTO_CIPHER_AES_ECB 2\n> +#define VIRTIO_CRYPTO_CIPHER_AES_CBC 3\n> +#define VIRTIO_CRYPTO_CIPHER_AES_CTR 4\n> +#define VIRTIO_CRYPTO_CIPHER_DES_ECB 5\n> +#define VIRTIO_CRYPTO_CIPHER_DES_CBC 6\n> +#define VIRTIO_CRYPTO_CIPHER_3DES_ECB 7\n> +#define VIRTIO_CRYPTO_CIPHER_3DES_CBC 8\n> +#define VIRTIO_CRYPTO_CIPHER_3DES_CTR 9\n> +#define VIRTIO_CRYPTO_CIPHER_KASUMI_F8 10\n> +#define VIRTIO_CRYPTO_CIPHER_SNOW3G_UEA2 11\n> +#define VIRTIO_CRYPTO_CIPHER_AES_F8 12\n> +#define VIRTIO_CRYPTO_CIPHER_AES_XTS 13\n> +#define VIRTIO_CRYPTO_CIPHER_ZUC_EEA3 14\n> +\\end{lstlisting}\n> +\n> +The above constants have two usages:\n> +\\begin{enumerate}\n> +\\item As bit numbers, used to tell the driver which CIPHER algorithms\n> +are supported by the device, see \\ref{sec:Device Types / Crypto Device / Device configuration layout}.\n> +\\item As values, used to tell the device which CIPHER algorithm\n> +a crypto request from the driver requires, see \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}.\n> +\\end{enumerate}\n> +\n> +\\subsubsection{HASH services}\\label{sec:Device Types / Crypto Device / Supported crypto services / HASH services}\n> +\n> +The following HASH algorithms are defined:\n> +\n> +\\begin{lstlisting}\n> +#define VIRTIO_CRYPTO_NO_HASH 0\n> +#define VIRTIO_CRYPTO_HASH_MD5 1\n> +#define VIRTIO_CRYPTO_HASH_SHA1 2\n> +#define VIRTIO_CRYPTO_HASH_SHA_224 3\n> +#define VIRTIO_CRYPTO_HASH_SHA_256 4\n> +#define VIRTIO_CRYPTO_HASH_SHA_384 5\n> +#define VIRTIO_CRYPTO_HASH_SHA_512 6\n> +#define VIRTIO_CRYPTO_HASH_SHA3_224 7\n> +#define VIRTIO_CRYPTO_HASH_SHA3_256 8\n> +#define VIRTIO_CRYPTO_HASH_SHA3_384 9\n> +#define VIRTIO_CRYPTO_HASH_SHA3_512 10\n> +#define VIRTIO_CRYPTO_HASH_SHA3_SHAKE128 11\n> +#define VIRTIO_CRYPTO_HASH_SHA3_SHAKE256 12\n> +\\end{lstlisting}\n> +\n> +The above constants have two usages:\n> +\\begin{enumerate}\n> +\\item As bit numbers, used to tell the driver which HASH algorithms\n> +are supported by the device, see \\ref{sec:Device Types / Crypto Device / Device configuration layout}.\n> +\\item As values, used to tell the device which HASH algorithm\n> +a crypto request from the driver requires, see \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}.\n> +\\end{enumerate}\n> +\n> +\\subsubsection{MAC services}\\label{sec:Device Types / Crypto Device / Supported crypto services / MAC services}\n> +\n> +The following MAC algorithms are defined:\n> +\n> +\\begin{lstlisting}\n> +#define VIRTIO_CRYPTO_NO_MAC 0\n> +#define VIRTIO_CRYPTO_MAC_HMAC_MD5 1\n> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA1 2\n> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_224 3\n> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_256 4\n> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_384 5\n> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_512 6\n> +#define VIRTIO_CRYPTO_MAC_CMAC_3DES 25\n> +#define VIRTIO_CRYPTO_MAC_CMAC_AES 26\n> +#define VIRTIO_CRYPTO_MAC_KASUMI_F9 27\n> +#define VIRTIO_CRYPTO_MAC_SNOW3G_UIA2 28\n> +#define VIRTIO_CRYPTO_MAC_GMAC_AES 41\n> +#define VIRTIO_CRYPTO_MAC_GMAC_TWOFISH 42\n> +#define VIRTIO_CRYPTO_MAC_CBCMAC_AES 49\n> +#define VIRTIO_CRYPTO_MAC_CBCMAC_KASUMI_F9 50\n> +#define VIRTIO_CRYPTO_MAC_XCBC_AES 53\n> +#define VIRTIO_CRYPTO_MAC_ZUC_EIA3 54\n> +\\end{lstlisting}\n> +\n> +The above constants have two usages:\n> +\\begin{enumerate}\n> +\\item As bit numbers, used to tell the driver which MAC algorithms\n> +are supported by the device, see \\ref{sec:Device Types / Crypto Device / Device configuration layout}.\n> +\\item As values, used to tell the device which MAC algorithm\n> +a crypto request from the driver requires, see \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}.\n\nCosmetic comment: instead of 'used to tell the device which MAC algorithm\na crypto request form the driver requires' I would prefer 'used to designate\nthe algorithm in (MAC type) crypto operation requests'.\n\nI think, your version is good enough (won't be misunderstood) it is just\nthat request requires sound a bit weird to me. I'm not sure my version is\nbetter though.\n\n> +\\end{enumerate}\n> +\n> +\\subsubsection{AEAD services}\\label{sec:Device Types / Crypto Device / Supported crypto services / AEAD services}\n> +\n> +The following AEAD algorithms are defined:\n> +\n> +\\begin{lstlisting}\n> +#define VIRTIO_CRYPTO_NO_AEAD 0\n> +#define VIRTIO_CRYPTO_AEAD_GCM 1\n> +#define VIRTIO_CRYPTO_AEAD_CCM 2\n> +#define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305 3\n> +\\end{lstlisting}\n> +\n> +The above constants have two usages:\n> +\\begin{enumerate}\n> +\\item As bit numbers, used to tell the driver which AEAD algorithms\n> +are supported by the device, see \\ref{sec:Device Types / Crypto Device / Device configuration layout}.\n> +\\item As values, used to tell the device what AEAD algorithm\n> +a crypto request from the driver requires, see \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}.\n\nMore or less same as above (and we have some more similar occurrences below).\n\n> +\\end{enumerate}\n> +\n> +\\subsection{Device configuration layout}\\label{sec:Device Types / Crypto Device / Device configuration layout}\n> +\n> +\\begin{lstlisting}\n> +struct virtio_crypto_config {\n> + le32 status;\n> + le32 max_dataqueues;\n> + le32 crypto_services;\n> + /* Detailed algorithms mask */\n> + le32 cipher_algo_l;\n> + le32 cipher_algo_h;\n> + le32 hash_algo;\n> + le32 mac_algo_l;\n> + le32 mac_algo_h;\n> + le32 aead_algo;\n> + /* Maximum length of cipher key in bytes */\n> + le32 max_cipher_key_len;\n> + /* Maximum length of authenticated key in bytes */\n> + le32 max_auth_key_len;\n> + le32 reserved;\n> + /* Maximum size of each crypto request's content in bytes */\n> + le64 max_size;\n> +};\n> +\\end{lstlisting}\n> +\n> +\\begin{description}\n> +\\item[\\field{status}] is used to show whether the device is ready to work or\n> + not, it can be either zero or have one or more flags. Only one read-only\n> +\tbit (for the driver) is currently defined for the \\field{status} field: VIRTIO_CRYPTO_S_HW_READY:\n\nCosmetic comment: maybe 'Currently, only one \\field(status) bit is defined:\nIRTIO_CRYPTO_S_HW_READY set indicates that the device is ready to process\nrequests, this bit is read-only for the driver\n\nWhile trying to reword this, I started thinking about whether read-only\nmakes sense for individual bits. I think it does not (I think we can't\ndo something like compare and swap to make this work). Does read\nonly even make sense for configuration space? I mean it is not random\naccess AFAIK (see 4.3 Virtio Over Channel I/O)?\n\nI'm confused abut the config space in general. I've expected that after\na certain stage it can be only changed by the device, but I didn't\nmanage to find a corresponding statement in the spec.\n\n> +\\begin{lstlisting}\n> +#define VIRTIO_CRYPTO_S_HW_READY (1 << 0)\n> +\\end{lstlisting}\n> +\n> +\\item[\\field{max_dataqueues}] is the maximum number of data virtqueues exposed by\n> + the device. The driver MAY use only one data queue,\n> + or it can use more to achieve better performance.\n\ns/exposed/ that can be configured/\n\nThis is the wording virtio-net uses (if I'm not mistaken). Exposed can be\nmisleading.\n\n> +\n> +\\item[\\field{crypto_services}] crypto service offered, see \\ref{sec:Device Types / Crypto Device / Supported crypto services}.\n> +\n> +\\item[\\field{cipher_algo_l}] CIPHER algorithms bits 0-31, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / CIPHER services}.\n> +\n> +\\item[\\field{cipher_algo_h}] CIPHER algorithms bits 32-63, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / CIPHER services}.\n> +\n> +\\item[\\field{hash_algo}] HASH algorithms bits, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / HASH services}.\n> +\n> +\\item[\\field{mac_algo_l}] MAC algorithms bits 0-31, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / MAC services}.\n> +\n> +\\item[\\field{mac_algo_h}] MAC algorithms bits 32-63, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / MAC services}.\n> +\n> +\\item[\\field{aead_algo}] AEAD algorithms bits, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / AEAD services}.\n> +\n> +\\item[\\field{max_cipher_key_len}] is the maximum length of cipher key supported by the device.\n> +\n> +\\item[\\field{max_auth_key_len}] is the maximum length of authenticated key supported by the device.\n> +\n> +\\item[\\field{reserved}] is reserved for future use.\n> +\n> +\\item[\\field{max_size}] is the maximum size of each crypto request's content supported by the device\n> +\\end{description}\n> +\n> +\\begin{note}\n> +Unless explicitly stated otherwise all lengths and sizes are in bytes.\n> +\\end{note}\n> +\n> +\\devicenormative{\\subsubsection}{Device configuration layout}{Device Types / Crypto Device / Device configuration layout}\n> +\n> +\\begin{itemize*}\n> +\\item The device MUST set \\field{max_dataqueues} to between 1 and 65535 inclusive.\n> +\\item The device MUST set the \\field{status} flag based on the status of the crypto\ns/flag/flags ?\n> + accelerator, Non-valid flags MUST NOT be set.\nWhat does this mean? It is a device requirement so it can't be about the driver.\nWhat does the device have to do if it encounters an unknown flag?\n\n> +\\item The device MUST accept and handle requests after \\field{status} is set to VIRTIO_CRYPTO_S_HW_READY.\n> +\\item The device MUST set \\field{crypto_services} based on the crypto services the device offers.\n> +\\item The device MUST set detailed algorithms masks for each service advertised by \\field{crypto_services}.\n> + The device MUST NOT set the not defined algorithms bits.\n> +\\item The device MUST set \\field{max_size} to show the maximum size of crypto request the device supports.\n> +\\item The device MUST set \\field{max_cipher_key_len} to show the maximum length of cipher key if the\n> + device supports CIPHER service.\n> +\\item The device MUST set \\field{max_auth_key_len} to show the maximum length of authenticated key if\n> + the device supports MAC service.\n> +\\end{itemize*}\n> +\n> +\\drivernormative{\\subsubsection}{Device configuration layout}{Device Types / Crypto Device / Device configuration layout}\n> +\n> +\\begin{itemize*}\n> +\\item The driver MUST read the ready \\field{status} from the bottom bit of status to check whether the\n> + crypto accelerator is ready or not, and the driver MUST reread it after device reset.\n\nYou use 'ready' instead of VIRTIO_CRYPTO_S_HW_READY here and in the next point.\ns/ MUST read the ready \\field{status}/ MUST read the \\field{status}/ ?\ns/crypto accelerator is ready or not/VIRTIO_CRYPTO_S_HW_READY is set/ ?\n\n> +\\item The driver MUST NOT transmit any requests to the device if the ready \\field{status} is not set.\ns/if the ready \\field{status}/VIRTIO_CRYPTO_S_HW_READY/ ?\n> +\\item The driver MUST read \\field{max_dataqueues} field to discover the number of data queues the device supports.> +\\item The driver MUST read \\field{crypto_services} field to discover which services the device is able to offer.\n> +\\item The driver SHOULD ignore the not defined algorithms bits.\n> +\\item The driver MUST read the detailed algorithms fields based on \\field{crypto_services} field.\n> +\\item The driver SHOULD read \\field{max_size} to discover the maximum size of crypto request the device supports.\n> +\\item The driver SHOULD read \\field{max_cipher_key_len} to discover the maximum length of cipher key\n> + the device supports.\n> +\\item The driver SHOULD read \\field{max_auth_key_len} to discover the maximum length of authenticated\n> + key the device supports.\n> +\\end{itemize*}\n> +\n> +\\subsection{Device Initialization}\\label{sec:Device Types / Crypto Device / Device Initialization}\n> +\n> +\\drivernormative{\\subsubsection}{Device Initialization}{Device Types / Crypto Device / Device Initialization}\n> +\n> +\\begin{itemize*}\n> +\\item The driver MUST identify and initialize all virtqueues.\ns/initialize/configure/ ?\n\nI wonder, do we really want to mandate configuring all virtqueues even\nif some are going to be unused? If yes why?\n\n> +\\item The driver MUST read the supported crypto services from bits of \\field{crypto_services}.\n> +\\item The driver MUST read the supported algorithms based on \\field{crypto_services} field.\n> +\\end{itemize*}\n> +\n> +\\subsection{Device Operation}\\label{sec:Device Types / Crypto Device / Device Operation}\n> +\n> +Requests can be transmitted by placing them in the controlq or dataq.\n\nHow about: The operation of a virtio crypto device is driven by requests\nplaced on the virtqueues.\n\nI don't like 'can be transmitted' and 'or' in your sentence. I can't put\nmy finger on it.\n\n> +Requests consist of a queue-type specific header specifying among\n> +others the operation, and an operation specific payload.\n\nMaybe put 'specifying among others the operation' in parenthesis or\nbetween comas (I'm no good with grammar -- someone competent help!).\n\n> +The payload is generally composed of operation parameters, output data, and input data.\n> +Operation parameters are algorithm-specific parameters, output data is the\n\nStart a new sentence at the comma.\n\n> +data that should be utilized in operations, and input data is equal to\n> +\"operation result + result data\".\n> +\n> +The device can support both session mode (See \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}) and stateless mode.\n\nHow about if VIRTIO_CRYPTO_F_MUX_MODE is negotioated the device\nmay support both session mode ... and stateless mode operation requests.\n\n> +In stateless mode all operation parameters are supplied as a part\n> +of each request, while in session mode, some or all operation parameters\n> +are managed within the session. Stateless mode is guarded by\n> +feature bits 0-4 on a service level. If stateless mode is negotiated\n> +for a service, the service is available both in session and\n> +stateless mode; otherwise it's only available in session mode.\n> +\n> +The device can set the operation status as follows:\n\nThis is the first time you mention operation status. The only status\nwe have defined is the config layout status. Can we introduce the\noperation status later? Alternatively before we intreudce the op status\ncode we could tell something about how requests serviced, and of course\nintroduce the op status field as the part of (each?) request.\n\n> +\n> +\\begin{lstlisting}\n> +enum VIRTIO_CRYPTO_STATUS {\n> + VIRTIO_CRYPTO_OK = 0,\n> + VIRTIO_CRYPTO_ERR = 1,\n> + VIRTIO_CRYPTO_BADMSG = 2,\n> + VIRTIO_CRYPTO_NOTSUPP = 3,\n> + VIRTIO_CRYPTO_INVSESS = 4,\n> + VIRTIO_CRYPTO_NOSPC = 5,\n> + VIRTIO_CRYPTO_MAX\n> +};\n> +\\end{lstlisting}\n> +\n\n[..]\n\nI will continue reviewing right away but wanted to slit this up because\nthe patch is huge.\n\nMy overall impression is pretty decent (up until this point) even\nwith my suggestions ignored. If this weren't a standard I wouldn't probably\nbother with most of the comments (a la, it's good enough and can be improved\nupon later if deemed necessary), but since it's a standard it's more important\nto get things as good as possible already in the first version.\n\nRegards,\nHalil","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtykD2YD6z9sPs\n\tfor ;\n\tSat, 16 Sep 2017 00:40:36 +1000 (AEST)","from localhost ([::1]:53622 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dsrnG-0003Gm-Ek\n\tfor incoming@patchwork.ozlabs.org; Fri, 15 Sep 2017 10:40:34 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:35892)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dsrme-0003Dr-B7\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 10:39:59 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dsrmb-0003Ng-3T\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 10:39:56 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:40096\n\thelo=mx0a-001b2d01.pphosted.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dsrma-0003NS-SL\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 10:39:53 -0400","from pps.filterd (m0098416.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8FEd9Sw070617\n\tfor ; Fri, 15 Sep 2017 10:39:52 -0400","from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2d0dnpj9q5-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 15 Sep 2017 10:39:51 -0400","from localhost\n\tby e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tFri, 15 Sep 2017 15:39:49 +0100","from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196)\n\tby e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tFri, 15 Sep 2017 15:39:42 +0100","from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com\n\t[9.149.105.62])\n\tby b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8FEdfh626935382; Fri, 15 Sep 2017 14:39:41 GMT","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 3B1DBAE04D;\n\tFri, 15 Sep 2017 15:34:42 +0100 (BST)","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 23294AE045;\n\tFri, 15 Sep 2017 15:34:41 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tFri, 15 Sep 2017 15:34:41 +0100 (BST)"],"To":"\"Longpeng(Mike)\" , qemu-devel@nongnu.org,\n\tvirtio-dev@lists.oasis-open.org","References":"<1505092362-10544-1-git-send-email-longpeng2@huawei.com>\n\t<1505092362-10544-2-git-send-email-longpeng2@huawei.com>","From":"Halil Pasic ","Date":"Fri, 15 Sep 2017 16:39:40 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"<1505092362-10544-2-git-send-email-longpeng2@huawei.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-TM-AS-GCONF":"00","x-cbid":"17091514-0040-0000-0000-000003FA4730","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091514-0041-0000-0000-0000209B6C29","Message-Id":"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-15_05:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709150214","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.158.5","Subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Ola.Liljedahl@arm.com, brian.a.keating@intel.com,\n\twangxinxin.wang@huawei.com, mst@redhat.com, xin.zeng@intel.com,\n\tjasowang@redhat.com, cohuck@redhat.com, luonengjun@huawei.com,\n\tagraf@suse.de, john.griffin@intel.com, mike.caraman@nxp.com,\n\tarei.gonglei@huawei.com, liang.j.ma@intel.com,\n\tstefanha@redhat.com, Varun.Sethi@freescale.com,\n\tJani.Kokkonen@huawei.com, vincent.jardin@6wind.com,\n\tdenglingli@chinamobile.com, weidong.huang@huawei.com,\n\tarei.gonglei@hotmail.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1769284,"web_url":"http://patchwork.ozlabs.org/comment/1769284/","msgid":"<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-15T15:59:57","subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/11/2017 03:12 AM, Longpeng(Mike) wrote:\n> From: Gonglei \n> \n> The virtio crypto device is a virtual crypto device (ie. hardware\n> crypto accelerator card). Currently, the virtio crypto device provides\n> the following crypto services: CIPHER, MAC, HASH, and AEAD.\n> \n> In this patch, CIPHER, MAC, HASH, AEAD services are introduced.\n> \n> VIRTIO-153\n> \n> Signed-off-by: Gonglei \n> Signed-off-by: Longpeng(Mike) \n> ---\n[..]\n\n\n> +\\subsubsection{Control Virtqueue}\\label{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue}\n> +\n> +The driver uses the control virtqueue to send control commands to the\n> +device, such as session operations (See \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}).\n> +\n> +The header for controlq is of the following form:\n> +\\begin{lstlisting}\n> +#define VIRTIO_CRYPTO_OPCODE(service, op) (((service) << 8) | (op))\n> +\n> +struct virtio_crypto_ctrl_header {\n> +#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \\\n> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x02)\n> +#define VIRTIO_CRYPTO_CIPHER_DESTROY_SESSION \\\n> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x03)\n> +#define VIRTIO_CRYPTO_HASH_CREATE_SESSION \\\n> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x02)\n> +#define VIRTIO_CRYPTO_HASH_DESTROY_SESSION \\\n> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x03)\n> +#define VIRTIO_CRYPTO_MAC_CREATE_SESSION \\\n> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x02)\n> +#define VIRTIO_CRYPTO_MAC_DESTROY_SESSION \\\n> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x03)\n> +#define VIRTIO_CRYPTO_AEAD_CREATE_SESSION \\\n> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x02)\n> +#define VIRTIO_CRYPTO_AEAD_DESTROY_SESSION \\\n> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x03)\n> + le32 opcode;\n> + /* algo should be service-specific algorithms */\n> + le32 algo;\n> + le32 flag;\n> + /* data virtqueue id */\n> + le32 queue_id;\n> +};\n> +\\end{lstlisting}\n> +\n> +The format of the controlq request depends on the VIRTIO_CRYPTO_F_MUX_MODE feature bit:\n> +\n> +\\begin{itemize*}\n> +\\item If the VIRTIO_CRYPTO_F_MUX_MODE feature bit is NOT negotiated the controlq request is\n> + a fixed-size structure of form:\n> +\\begin{lstlisting}\n> +struct virtio_crypto_op_ctrl_req {\n> + struct virtio_crypto_ctrl_header header;\n> +\n> + union {\n> + struct virtio_crypto_sym_create_session_req sym_create_session;\n> + struct virtio_crypto_hash_create_session_req hash_create_session;\n> + struct virtio_crypto_mac_create_session_req mac_create_session;\n> + struct virtio_crypto_aead_create_session_req aead_create_session;\n> + struct virtio_crypto_destroy_session_req destroy_session;\n> + } u;\n> +};\n> +\\end{lstlisting}\n> +The header is the general header, and the union is of the algorithm-specific type or the\n> +virtio_crypto_destroy_session_req structure, which is set by the driver. All the properties\n> +in the union are shown as follows.\n> +\n> +\\item If the VIRTIO_CRYPTO_F_MUX_MODE feature bit is negotiated the controlq request is composed\n> + of two parts, the additional paramenters are preceded by the general header.\n> +\n> +\\begin{lstlisting}\n> +struct virtio_crypto_op_ctrl_req_mux {\n> + struct virtio_crypto_ctrl_header header;\n> +\n> + /* additional paramenter */\n> + u8 additional_para[addl_para_len];\n> +};\n> +\\end{lstlisting}\n> +\n> +The additional paramenters are stored in a virtio_crypto_destroy_session_req structure or\n> +in a algorithm-specific structure:\n> +\\begin{itemize*}\n> +\\item struct virtio_crypto_sym_create_session_req\n> +\\item struct virtio_crypto_hash_create_session_req\n> +\\item struct virtio_crypto_mac_create_session_req\n> +\\item struct virtio_crypto_aead_create_session_req\n> +\\end{itemize*}\n> +All of the structures above are shown as follows.\n> +\\end{itemize*}\n> +\n> +\\paragraph{Session operation}\\label{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}\n> +\n> +The session is a\n> +handle which describes the cryptographic parameters to be applied to\n> +a number of buffers.\n> +\n> +The following structure stores the result of session creation set by the device:\n> +\n> +\\begin{lstlisting}\n> +struct virtio_crypto_session_input {\n> + /* Device-writable part */\n> + le64 session_id;\n> + le32 status;\n> + le32 padding;\n> +};\n> +\\end{lstlisting}\n> +\n> +A request to destroy a session includes the following information:\n> +\n> +\\begin{lstlisting}\n> +struct virtio_crypto_destroy_session_req {\n> + /* Device-readable part */\n> + le64 session_id;\n> + /* Device-writable part */\n> + le32 status;\n> + le32 padding;\n> +};\n> +\\end{lstlisting}\n> +\n> +\\subparagraph{Session operation: HASH session}\\label{sec:Device Types / Crypto Device / Device\n> +Operation / Control Virtqueue / Session operation / Session operation: HASH session}\n> +\n> +HASH session requests are as follows:\n> +\n> +\\begin{lstlisting}\n> +struct virtio_crypto_hash_session_para {\n> + /* See VIRTIO_CRYPTO_HASH_* above */\n> + le32 algo;\n> + /* hash result length */\n> + le32 hash_result_len;\n> +};\n> +struct virtio_crypto_hash_create_session_req {\n> + /* Device-readable part */\n> + struct virtio_crypto_hash_session_para para;\n> + /* Device-writable part */\n> + struct virtio_crypto_session_input input;\n> +};\n> +\\end{lstlisting}\n> +\n> +The information required by HASH session creation is stored in the virtio_crypto_hash_create_session_req\n> +structure, including the hash parameters stored in \\field{para}. \\field{input} stores the result of this operation.\n> +\n> +\\subparagraph{Session operation: MAC session}\\label{sec:Device Types / Crypto Device / Device\n> +Operation / Control Virtqueue / Session operation / Session operation: MAC session}\n> +\n> +MAC session requests are as follows:\n> +\n> +\\begin{lstlisting}\n> +struct virtio_crypto_mac_session_para {\n> + /* See VIRTIO_CRYPTO_MAC_* above */\n> + le32 algo;\n> + /* hash result length */\n> + le32 hash_result_len;\n> + /* length of authenticated key */\n> + le32 auth_key_len;\n> + le32 padding;\n> +};\n> +\n> +struct virtio_crypto_mac_create_session_req {\n> + /* Device-readable part */\n> + struct virtio_crypto_mac_session_para para;\n> + /* The authenticated key */\n> + u8 auth_key[auth_key_len];\n> +\n> + /* Device-writable part */\n> + struct virtio_crypto_session_input input;\n> +};\n> +\\end{lstlisting}\n> +\n> +The information required by MAC session creation is stored in the virtio_crypto_mac_create_session_req\n> +structure, including the mac parameters stored in \\field{para} and the authenticated key in \\field{auth_key}.\n> +\\field{input} stores the result of this operation.\n> +\n> +\\subparagraph{Session operation: Symmetric algorithms session}\\label{sec:Device Types / Crypto Device / Device\n> +Operation / Control Virtqueue / Session operation / Session operation: Symmetric algorithms session}\n> +\n> +The request of symmetric session includes two parts, CIPHER algorithms and chain\n> +algorithms (chaining CIPHER and HASH/MAC).\n> +\n> +CIPHER session requests are as follows:\n> +\n> +\\begin{lstlisting}\n> +struct virtio_crypto_cipher_session_para {\n> + /* See VIRTIO_CRYPTO_CIPHER* above */\n> + le32 algo;\n> + /* length of key */\n> + le32 keylen;\n> +#define VIRTIO_CRYPTO_OP_ENCRYPT 1\n> +#define VIRTIO_CRYPTO_OP_DECRYPT 2\n> + /* encryption or decryption */\n> + le32 op;\n> + le32 padding;\n> +};\n> +\n> +struct virtio_crypto_cipher_session_req {\n> + /* Device-readable part */\n> + struct virtio_crypto_cipher_session_para para;\n> + /* The cipher key */\n> + u8 cipher_key[keylen];\n> +\n> + /* Device-writable part */\n> + struct virtio_crypto_session_input input;that\n> +};\n> +\\end{lstlisting}\n> +\n> +Algorithm chaining requests are as follows:\n> +\n> +\\begin{lstlisting}\n> +struct virtio_crypto_alg_chain_session_para {\n> +#define VIRTIO_CRYPTO_SYM_ALG_CHAIN_ORDER_HASH_THEN_CIPHER 1\n> +#define VIRTIO_CRYPTO_SYM_ALG_CHAIN_ORDER_CIPHER_THEN_HASH 2\n> + le32 alg_chain_order;\n> +/* Plain hash */\n> +#define VIRTIO_CRYPTO_SYM_HASH_MODE_PLAIN 1\n> +/* Authenticated hash (mac) */\n> +#define VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH 2\n> +/* Nested hash */\n> +#define VIRTIO_CRYPTO_SYM_HASH_MODE_NESTED 3\n> + le32 hash_mode;\n> + struct virtio_crypto_cipher_session_para cipher_param;\n> + union {\n> + struct virtio_crypto_hash_session_para hash_param;\n> + struct virtio_crypto_mac_session_para mac_param;\n> + } u;\n> + /* length of the additional authenticated data (AAD) in bytes */\n> + le32 aad_len;\n> + le32 padding;\n> +};\n> +\n> +struct virtio_crypto_alg_chain_session_req {\n> + /* Device-readable part */\n> + struct virtio_crypto_alg_chain_session_para para;\n> + /* The cipher key */\n> + u8 cipher_key[keylen];\n> + /* The authenticated key */\n> + u8 auth_key[auth_key_len];\n> +\n> + /* Device-writable part */\n> + struct virtio_crypto_session_input input;\n> +};\n> +\\end{lstlisting}\n> +\n> +Symmetric algorithm requests are as follows:\n> +\n> +\\begin{lstlisting}\n> +struct virtio_crypto_sym_create_session_req {\n> + union {\n> + struct virtio_crypto_cipher_session_req cipher;\n> + struct virtio_crypto_alg_chain_session_req chain;\n> + } u;\n> +\n> + /* Device-readable part */\n> +\n> +/* No operation */\n> +#define VIRTIO_CRYPTO_SYM_OP_NONE 0\n> +/* Cipher only operation on the data */\n> +#define VIRTIO_CRYPTO_SYM_OP_CIPHER 1\n> +/* Chain any cipher with any hash or mac operation. The order\n> + depends on the value of alg_chain_order param */\n> +#define VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING 2\n> + le32 op_type;\n> + le32 padding;\n> +};\n> +\\end{lstlisting}\n> +\n> +The information required by symmetric algorithms session creation is stored in the\n> +virtio_crypto_sym_create_session_req structure, including the symmetric operation\n> +type in \\field{op_type} and the cipher parameters stored in \\field{cipher} or the\n> +algorithm chaining paramenters in \\field{chain}.\n> +\n> +The driver can set the \\field{op_type} field in struct virtio_crypto_sym_create_session_req\n> +as follows: VIRTIO_CRYPTO_SYM_OP_NONE: no operation; VIRTIO_CRYPTO_SYM_OP_CIPHER: Cipher only\n> +operation on the data; VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING: Chain any cipher with any hash\n> +or mac operation.\n> +\n> +\\subparagraph{Session operation: AEAD session}\\label{sec:Device Types / Crypto Device / Device\n> +Operation / Control Virtqueue / Session operation / Session operation: AEAD session}\n> +\n> +AEAD session requests are as follows:\n> +\n> +\\begin{lstlisting}\n> +struct virtio_crypto_aead_session_para {\n> + /* See VIRTIO_CRYPTO_AEAD_* above */\n> + le32 algo;\n> + /* length of key */\n> + le32 key_len;\n> + /* Authentication tag length */\n> + le32 tag_len;\n> + /* The length of the additional authenticated data (AAD) in bytes */\n> + le32 aad_len;\n> + /* encryption or decryption, See above VIRTIO_CRYPTO_OP_* */\n> + le32 op;\n> + le32 padding;\n> +};\n> +\n> +struct virtio_crypto_aead_create_session_req {\n> + /* Device-readable part */\n> + struct virtio_crypto_aead_session_para para;\n> + u8 key[key_len];\n> +\n> + /* Device-writeable part */\n> + struct virtio_crypto_session_input input;\n> +};\n> +\\end{lstlisting}\n> +\n> +The information required by AEAD session creation is stored in the virtio_crypto_aead_create_session_req\n> +structure, including the aead parameters stored in \\field{para} and the cipher key in \\field{key}.\n> +\\field{input} stores the result of this operation.\n> +\n> +\\drivernormative{\\subparagraph}{Session operation: create session}{Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation / Session operation: create session}\n> +\n> +\\begin{itemize*}\n> +\\item The driver MUST set the control general header and the corresponding algorithm-specific structure.\n> + See \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue}.\n> +\\item The driver MUST set the \\field{opcode} field based on service type: CIPHER, HASH, MAC, or AEAD.\n> +\\item The driver MUST set the \\field{queue_id} field to show used dataq.\n\nI've failed to figure out the semantic behind queue_id. This could mean,\nthat sessions and session_id's are queue scoped. But then we should be\n(IMHO) more explicit on this -- my guess is that session_id's aren't\ndataqueue scoped.\n\n> +\\end{itemize*}\n> +\n> +\\devicenormative{\\subparagraph}{Session operation: create session}{Device Types / Crypto Device / Device\n> +Operation / Control Virtqueue / Session operation / Session operation: create session}\n> +\n> +\\begin{itemize*}\n> +\\item The device MUST use the corresponding algorithm-specific structure according to the\n> + \\field{opcode} in the control general header.\n> +\\item The device MUST set the \\field{status} field to one of the following values of enum\n> + VIRTIO_CRYPTO_STATUS after finish a session creation:\n> +\\begin{itemize*}\n> +\\item VIRTIO_CRYPTO_OK if a session is created successfully.\n> +\\item VIRTIO_CRYPTO_NOTSUPP if the requested algorithm or operation is unsupported.\n> +\\item VIRTIO_CRYPTO_NOSPC if no free session ID (only when the VIRTIO_CRYPTO_F_MUX_MODE\n> + feature bit is negotiated).\n> +\\item VIRTIO_CRYPTO_ERR if failure not mentioned above occurs.\n\nI guess an invalid queue_id would be among these.\n\n> +\\end{itemize*}\n> +\\item The device MUST set the \\field{session_id} field to a unique session identifieronly\ns/identifieronly/identifier only\n> + if the status is set to VIRTIO_CRYPTO_OK.\n> +\\end{itemize*}\n> +\n> +\\drivernormative{\\subparagraph}{Session operation: destroy session}{Device Types / Crypto Device / Device\n> +Operation / Control Virtqueue / Session operation / Session operation: destroy session}\n> +\n> +\\begin{itemize*}\n> +\\item The driver MUST set the \\field{opcode} field based on service type: CIPHER, HASH, MAC, or AEAD.\n> +\\item The driver MUST set the \\field{session_id} to a valid value assigned by the device\n> + when the session was created.\n\nDestroy does not need to specify queue_id. That means session_id's aren't\nqueue scoped from namespace perspective. The question remains what is\nqueue_id good for, and whether a session type op request should be\nrejected if the the session id originates from a session creation\nrequest specifying a different dataqueue (not the dataqueue containing\nthe given request)? \n\n> +\\end{itemize*}\n> +\n> +\\devicenormative{\\subparagraph}{Session operation: destroy session}{Device Types / Crypto Device / Device\n> +Operation / Control Virtqueue / Session operation / Session operation: destroy session}\n> +\n> +\\begin{itemize*}\n> +\\item The device MUST set the \\field{status} field to one of the following values of enum VIRTIO_CRYPTO_STATUS.\n> +\\begin{itemize*}\n> +\\item VIRTIO_CRYPTO_OK if a session is created successfully.\n> +\\item VIRTIO_CRYPTO_ERR if any failure occurs.\n> +\\end{itemize*}\n> +\\end{itemize*}\n> +\n> +\\subsubsection{Data Virtqueue}\\label{sec:Device Types / Crypto Device / Device Operation / Data Virtqueue}\n>\n\n[..]\n\nI've run through the rest. It some stuff seems very repetitive. I wonder if\nwe can do better.\n\nI also dislike this 5.7.7.5.3 Steps of Operation part. I also don't\nunderstand why is symmetric special in this respect (HASH, MAC and\nAEAD don't have a 'Steps of Operation' section.\n\nI would like to try some things out with the reference implementation.\nDepending on how that goes I may or may not end up providing a detailed\nreview for the rest before discussing what I've already addressed.\n\nRegards,\nHalil","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xv0ZY061Yz9s03\n\tfor ;\n\tSat, 16 Sep 2017 02:04:03 +1000 (AEST)","from localhost ([::1]:54059 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dst61-0004i2-FI\n\tfor incoming@patchwork.ozlabs.org; Fri, 15 Sep 2017 12:04:01 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:33616)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dst2Q-00024P-5U\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 12:00:28 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dst2L-0007tI-4D\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 12:00:18 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41711\n\thelo=mx0a-001b2d01.pphosted.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dst2K-0007sZ-VF\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 12:00:13 -0400","from pps.filterd (m0098416.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8FG09vi123698\n\tfor ; Fri, 15 Sep 2017 12:00:12 -0400","from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2d0hac22h7-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 15 Sep 2017 12:00:11 -0400","from localhost\n\tby e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tFri, 15 Sep 2017 17:00:06 +0100","from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198)\n\tby e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tFri, 15 Sep 2017 16:59:59 +0100","from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com\n\t[9.149.105.62])\n\tby b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8FFxx4Z21233896; Fri, 15 Sep 2017 15:59:59 GMT","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 9269BAE045;\n\tFri, 15 Sep 2017 16:54:59 +0100 (BST)","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 2C2BFAE04D;\n\tFri, 15 Sep 2017 16:54:58 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tFri, 15 Sep 2017 16:54:58 +0100 (BST)"],"To":"\"Longpeng(Mike)\" , qemu-devel@nongnu.org,\n\tvirtio-dev@lists.oasis-open.org","References":"<1505092362-10544-1-git-send-email-longpeng2@huawei.com>\n\t<1505092362-10544-2-git-send-email-longpeng2@huawei.com>","From":"Halil Pasic ","Date":"Fri, 15 Sep 2017 17:59:57 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"<1505092362-10544-2-git-send-email-longpeng2@huawei.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-TM-AS-GCONF":"00","x-cbid":"17091516-0020-0000-0000-000003B84D02","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091515-0021-0000-0000-00004249D18A","Message-Id":"<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-15_06:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=2\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709150232","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.158.5","Subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"wangxinxin.wang@huawei.com, Ola.Liljedahl@arm.com,\n\tweidong.huang@huawei.com, \n\tbrian.a.keating@intel.com, mst@redhat.com, xin.zeng@intel.com,\n\tjasowang@redhat.com, cohuck@redhat.com, luonengjun@huawei.com,\n\tagraf@suse.de, john.griffin@intel.com, mike.caraman@nxp.com,\n\tarei.gonglei@huawei.com, liang.j.ma@intel.com,\n\tstefanha@redhat.com, Varun.Sethi@freescale.com,\n\tJani.Kokkonen@huawei.com, vincent.jardin@6wind.com,\n\tdenglingli@chinamobile.com, arei.gonglei@hotmail.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1770118,"web_url":"http://patchwork.ozlabs.org/comment/1770118/","msgid":"<33183CC9F5247A488A2544077AF19020DA3D9A7B@DGGEMA505-MBX.china.huawei.com>","list_archive_url":null,"date":"2017-09-18T12:13:10","subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","submitter":{"id":35948,"url":"http://patchwork.ozlabs.org/api/people/35948/","name":"Gonglei","email":"arei.gonglei@huawei.com"},"content":">\r\n> > +\r\n> > +The information required by AEAD session creation is stored in the\r\n> virtio_crypto_aead_create_session_req\r\n> > +structure, including the aead parameters stored in \\field{para} and the\r\n> cipher key in \\field{key}.\r\n> > +\\field{input} stores the result of this operation.\r\n> > +\r\n> > +\\drivernormative{\\subparagraph}{Session operation: create session}{Device\r\n> Types / Crypto Device / Device Operation / Control Virtqueue / Session\r\n> operation / Session operation: create session}\r\n> > +\r\n> > +\\begin{itemize*}\r\n> > +\\item The driver MUST set the control general header and the\r\n> corresponding algorithm-specific structure.\r\n> > + See \\ref{sec:Device Types / Crypto Device / Device Operation / Control\r\n> Virtqueue}.\r\n> > +\\item The driver MUST set the \\field{opcode} field based on service type:\r\n> CIPHER, HASH, MAC, or AEAD.\r\n> > +\\item The driver MUST set the \\field{queue_id} field to show used dataq.\r\n> \r\n> I've failed to figure out the semantic behind queue_id. This could mean,\r\n> that sessions and session_id's are queue scoped. But then we should be\r\n> (IMHO) more explicit on this -- my guess is that session_id's aren't\r\n> dataqueue scoped.\r\n> \r\n> > +\\end{itemize*}\r\n> > +\r\n> > +\\devicenormative{\\subparagraph}{Session operation: create session}{Device\r\n> Types / Crypto Device / Device\r\n> > +Operation / Control Virtqueue / Session operation / Session operation:\r\n> create session}\r\n> > +\r\n> > +\\begin{itemize*}\r\n> > +\\item The device MUST use the corresponding algorithm-specific structure\r\n> according to the\r\n> > + \\field{opcode} in the control general header.\r\n> > +\\item The device MUST set the \\field{status} field to one of the following\r\n> values of enum\r\n> > + VIRTIO_CRYPTO_STATUS after finish a session creation:\r\n> > +\\begin{itemize*}\r\n> > +\\item VIRTIO_CRYPTO_OK if a session is created successfully.\r\n> > +\\item VIRTIO_CRYPTO_NOTSUPP if the requested algorithm or operation is\r\n> unsupported.\r\n> > +\\item VIRTIO_CRYPTO_NOSPC if no free session ID (only when the\r\n> VIRTIO_CRYPTO_F_MUX_MODE\r\n> > + feature bit is negotiated).\r\n> > +\\item VIRTIO_CRYPTO_ERR if failure not mentioned above occurs.\r\n> \r\n> I guess an invalid queue_id would be among these.\r\n> \r\n> > +\\end{itemize*}\r\n> > +\\item The device MUST set the \\field{session_id} field to a unique session\r\n> identifieronly\r\n> s/identifieronly/identifier only\r\n> > + if the status is set to VIRTIO_CRYPTO_OK.\r\n> > +\\end{itemize*}\r\n> > +\r\n> > +\\drivernormative{\\subparagraph}{Session operation: destroy\r\n> session}{Device Types / Crypto Device / Device\r\n> > +Operation / Control Virtqueue / Session operation / Session operation:\r\n> destroy session}\r\n> > +\r\n> > +\\begin{itemize*}\r\n> > +\\item The driver MUST set the \\field{opcode} field based on service type:\r\n> CIPHER, HASH, MAC, or AEAD.\r\n> > +\\item The driver MUST set the \\field{session_id} to a valid value assigned by\r\n> the device\r\n> > + when the session was created.\r\n> \r\n> Destroy does not need to specify queue_id. That means session_id's aren't\r\n> queue scoped from namespace perspective. The question remains what is\r\n> queue_id good for, and whether a session type op request should be\r\n> rejected if the the session id originates from a session creation\r\n> request specifying a different dataqueue (not the dataqueue containing\r\n> the given request)?\r\n> \r\n\r\nMy original idea about the queue_id is using the queue_id to specify which\r\ndatequeue of the following data requests will be used. But after deep thinking,\r\nI find that the queue_id is superfluous, and the current code in QEMU also\r\ndon't use the queue_id value as well. That's because the we can use session_id\r\nto find the pervious session information and get the current dataqueue id\r\nfrom the used virtqueue .\r\n\r\nSo maybe we should drop the queue_id this time.\r\n\r\n\r\n> > +\\end{itemize*}\r\n> > +\r\n> > +\\devicenormative{\\subparagraph}{Session operation: destroy\r\n> session}{Device Types / Crypto Device / Device\r\n> > +Operation / Control Virtqueue / Session operation / Session operation:\r\n> destroy session}\r\n> > +\r\n> > +\\begin{itemize*}\r\n> > +\\item The device MUST set the \\field{status} field to one of the following\r\n> values of enum VIRTIO_CRYPTO_STATUS.\r\n> > +\\begin{itemize*}\r\n> > +\\item VIRTIO_CRYPTO_OK if a session is created successfully.\r\n> > +\\item VIRTIO_CRYPTO_ERR if any failure occurs.\r\n> > +\\end{itemize*}\r\n> > +\\end{itemize*}\r\n> > +\r\n> > +\\subsubsection{Data Virtqueue}\\label{sec:Device Types / Crypto Device /\r\n> Device Operation / Data Virtqueue}\r\n> >\r\n> \r\n> [..]\r\n> \r\n> I've run through the rest. It some stuff seems very repetitive. I wonder if\r\n> we can do better.\r\n> \r\n> I also dislike this 5.7.7.5.3 Steps of Operation part. I also don't\r\n> understand why is symmetric special in this respect (HASH, MAC and\r\n> AEAD don't have a 'Steps of Operation' section.\r\n> \r\nHmm.. I just took a example as the symmetric is the most complicated operation. ;)\r\n\r\n> I would like to try some things out with the reference implementation.\r\n> Depending on how that goes I may or may not end up providing a detailed\r\n> review for the rest before discussing what I've already addressed.\r\n> \r\nHalil, Thank you for your work, pls go ahead :)\r\n\r\n> Regards,\r\n> Halil\r\n\r\nThanks,\r\n-Gonglei","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwlKz5L6Hz9s78\n\tfor ;\n\tMon, 18 Sep 2017 22:14:15 +1000 (AEST)","from localhost ([::1]:36229 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dtuwH-0007dz-SV\n\tfor incoming@patchwork.ozlabs.org; Mon, 18 Sep 2017 08:14:13 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:52738)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dtuvn-0007c0-FC\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 08:13:44 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dtuvj-0007mR-Ds\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 08:13:43 -0400","from szxga01-in.huawei.com ([45.249.212.187]:4493)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71)\n\t(envelope-from ) id 1dtuvi-0007iR-Cg\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 08:13:39 -0400","from 172.30.72.55 (EHLO DGGEMA402-HUB.china.huawei.com)\n\t([172.30.72.55])\n\tby dggrg01-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id AWN63568; Mon, 18 Sep 2017 20:13:20 +0800 (CST)","from DGGEMA505-MBX.china.huawei.com ([169.254.1.3]) by\n\tDGGEMA402-HUB.china.huawei.com ([10.3.20.43]) with mapi id\n\t14.03.0301.000; Mon, 18 Sep 2017 20:13:11 +0800"],"From":"\"Gonglei (Arei)\" ","To":"Halil Pasic , longpeng , \n\t\"qemu-devel@nongnu.org\" ,\n\t\"virtio-dev@lists.oasis-open.org\" ","Thread-Topic":"[Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","Thread-Index":"AQHTKpsc74eWq9/D8UCz3cO7YtCnIaK1nAiAgAT4xtA=","Date":"Mon, 18 Sep 2017 12:13:10 +0000","Message-ID":"<33183CC9F5247A488A2544077AF19020DA3D9A7B@DGGEMA505-MBX.china.huawei.com>","References":"<1505092362-10544-1-git-send-email-longpeng2@huawei.com>\n\t<1505092362-10544-2-git-send-email-longpeng2@huawei.com>\n\t<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>","In-Reply-To":"<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>","Accept-Language":"zh-CN, en-US","Content-Language":"zh-CN","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.177.18.62]","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A090203.59BFB862.003B, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.3,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"60019b56cdcb5ef973cdec68fafcc5de","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic]\n\t[fuzzy]","X-Received-From":"45.249.212.187","Subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"wangxin \\(U\\)\" ,\n\t\"Ola.Liljedahl@arm.com\" ,\n\t\"Huangweidong \\(C\\)\" ,\n\t\"brian.a.keating@intel.com\" ,\n\t\"mst@redhat.com\" ,\n\t\"xin.zeng@intel.com\" ,\n\t\"jasowang@redhat.com\" ,\n\t\"cohuck@redhat.com\" ,\n\tLuonengjun , \"agraf@suse.de\" , \n\t\"john.griffin@intel.com\" ,\n\t\"mike.caraman@nxp.com\" ,\n\t\"liang.j.ma@intel.com\" ,\n\t\"stefanha@redhat.com\" ,\n\t\"Varun.Sethi@freescale.com\" ,\n\tJani Kokkonen ,\n\t\"vincent.jardin@6wind.com\" ,\n\t\"denglingli@chinamobile.com\" ,\n\t\"arei.gonglei@hotmail.com\" ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1770143,"web_url":"http://patchwork.ozlabs.org/comment/1770143/","msgid":"<73b9f2a8-6746-593b-4277-3ea757476130@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-18T13:08:16","subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/18/2017 02:13 PM, Gonglei (Arei) wrote:\n>> Destroy does not need to specify queue_id. That means session_id's aren't\n>> queue scoped from namespace perspective. The question remains what is\n>> queue_id good for, and whether a session type op request should be\n>> rejected if the the session id originates from a session creation\n>> request specifying a different dataqueue (not the dataqueue containing\n>> the given request)?\n>>\n> My original idea about the queue_id is using the queue_id to specify which\n> datequeue of the following data requests will be used. But after deep thinking,\n> I find that the queue_id is superfluous, and the current code in QEMU also\n> don't use the queue_id value as well. That's because the we can use session_id\n> to find the pervious session information and get the current dataqueue id\n> from the used virtqueue .\n> \n> So maybe we should drop the queue_id this time.\n> \n> \n\nSounds reasonable to me. We can make it reserved and ignored in\nthe specification. Linux uses it, but it's always set to 0 as we only\nsupport one data-queue (if I'm not wrong). So reserved and must be zero\nis an option too.\n\nHalil","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwmYR4hrPz9s3w\n\tfor ;\n\tMon, 18 Sep 2017 23:09:13 +1000 (AEST)","from localhost ([::1]:36561 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dtvnR-0006eG-Bd\n\tfor incoming@patchwork.ozlabs.org; Mon, 18 Sep 2017 09:09:09 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:45008)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dtvmq-0006az-01\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 09:08:36 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dtvmm-0008L8-MS\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 09:08:31 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36518\n\thelo=mx0a-001b2d01.pphosted.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dtvmm-0008Ku-GS\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 09:08:28 -0400","from pps.filterd (m0098417.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8ID4cW3060517\n\tfor ; Mon, 18 Sep 2017 09:08:27 -0400","from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d2e9yhkpd-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Mon, 18 Sep 2017 09:08:27 -0400","from localhost\n\tby e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tMon, 18 Sep 2017 14:08:24 +0100","from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196)\n\tby e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tMon, 18 Sep 2017 14:08:18 +0100","from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60])\n\tby b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8ID8Hkj14942374; Mon, 18 Sep 2017 13:08:17 GMT","from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 1A9A84204D;\n\tMon, 18 Sep 2017 14:04:31 +0100 (BST)","from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 108314203F;\n\tMon, 18 Sep 2017 14:04:30 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tMon, 18 Sep 2017 14:04:29 +0100 (BST)"],"To":"\"Gonglei (Arei)\" ,\n\tlongpeng ,\n\t\"qemu-devel@nongnu.org\" ,\n\t\"virtio-dev@lists.oasis-open.org\" ","References":"<1505092362-10544-1-git-send-email-longpeng2@huawei.com>\n\t<1505092362-10544-2-git-send-email-longpeng2@huawei.com>\n\t<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>\n\t<33183CC9F5247A488A2544077AF19020DA3D9A7B@DGGEMA505-MBX.china.huawei.com>","From":"Halil Pasic ","Date":"Mon, 18 Sep 2017 15:08:16 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"<33183CC9F5247A488A2544077AF19020DA3D9A7B@DGGEMA505-MBX.china.huawei.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-TM-AS-GCONF":"00","x-cbid":"17091813-0012-0000-0000-00000579CDC7","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091813-0013-0000-0000-000018F2FC2B","Message-Id":"<73b9f2a8-6746-593b-4277-3ea757476130@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-18_03:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709180189","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.158.5","Subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"wangxin \\(U\\)\" ,\n\t\"Ola.Liljedahl@arm.com\" ,\n\t\"Huangweidong \\(C\\)\" ,\n\t\"brian.a.keating@intel.com\" ,\n\t\"mst@redhat.com\" ,\n\t\"xin.zeng@intel.com\" ,\n\t\"jasowang@redhat.com\" ,\n\t\"cohuck@redhat.com\" ,\n\tLuonengjun , \"agraf@suse.de\" , \n\t\"john.griffin@intel.com\" ,\n\t\"mike.caraman@nxp.com\" ,\n\t\"liang.j.ma@intel.com\" ,\n\t\"stefanha@redhat.com\" ,\n\t\"Varun.Sethi@freescale.com\" ,\n\tJani Kokkonen ,\n\t\"vincent.jardin@6wind.com\" ,\n\t\"denglingli@chinamobile.com\" ,\n\t\"arei.gonglei@hotmail.com\" ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1770154,"web_url":"http://patchwork.ozlabs.org/comment/1770154/","msgid":"<33183CC9F5247A488A2544077AF19020DA3D9B61@DGGEMA505-MBX.china.huawei.com>","list_archive_url":null,"date":"2017-09-18T13:23:31","subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","submitter":{"id":35948,"url":"http://patchwork.ozlabs.org/api/people/35948/","name":"Gonglei","email":"arei.gonglei@huawei.com"},"content":"> -----Original Message-----\r\n> From: Halil Pasic [mailto:pasic@linux.vnet.ibm.com]\r\n> Sent: Monday, September 18, 2017 9:08 PM\r\n> Subject: Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\r\n> crypto device specification\r\n> \r\n> \r\n> \r\n> On 09/18/2017 02:13 PM, Gonglei (Arei) wrote:\r\n> >> Destroy does not need to specify queue_id. That means session_id's aren't\r\n> >> queue scoped from namespace perspective. The question remains what is\r\n> >> queue_id good for, and whether a session type op request should be\r\n> >> rejected if the the session id originates from a session creation\r\n> >> request specifying a different dataqueue (not the dataqueue containing\r\n> >> the given request)?\r\n> >>\r\n> > My original idea about the queue_id is using the queue_id to specify which\r\n> > datequeue of the following data requests will be used. But after deep\r\n> thinking,\r\n> > I find that the queue_id is superfluous, and the current code in QEMU also\r\n> > don't use the queue_id value as well. That's because the we can use\r\n> session_id\r\n> > to find the pervious session information and get the current dataqueue id\r\n> > from the used virtqueue .\r\n> >\r\n> > So maybe we should drop the queue_id this time.\r\n> >\r\n> >\r\n> \r\n> Sounds reasonable to me. We can make it reserved and ignored in\r\n> the specification. Linux uses it, but it's always set to 0 as we only\r\n> support one data-queue (if I'm not wrong). So reserved and must be zero\r\n> is an option too.\r\n> \r\nMakes sense to keeping compatibility. \r\n\r\nThanks,\r\n-Gonglei","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwmv60hRvz9s3w\n\tfor ;\n\tMon, 18 Sep 2017 23:24:34 +1000 (AEST)","from localhost ([::1]:36620 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dtw2K-0004HV-6S\n\tfor incoming@patchwork.ozlabs.org; Mon, 18 Sep 2017 09:24:32 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:51695)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dtw1x-0004Gt-2L\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 09:24:15 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dtw1r-0006kH-DO\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 09:24:09 -0400","from szxga02-in.huawei.com ([45.249.212.188]:4423)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71)\n\t(envelope-from ) id 1dtw1p-0006hv-Oe\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 09:24:03 -0400","from 172.30.72.55 (EHLO DGGEMA403-HUB.china.huawei.com)\n\t([172.30.72.55])\n\tby dggrg02-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id AVM76342; Mon, 18 Sep 2017 21:23:43 +0800 (CST)","from DGGEMA505-MBX.china.huawei.com ([169.254.1.3]) by\n\tDGGEMA403-HUB.china.huawei.com ([10.3.20.44]) with mapi id\n\t14.03.0301.000; Mon, 18 Sep 2017 21:23:32 +0800"],"From":"\"Gonglei (Arei)\" ","To":"Halil Pasic , longpeng , \n\t\"qemu-devel@nongnu.org\" ,\n\t\"virtio-dev@lists.oasis-open.org\" ","Thread-Topic":"[Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","Thread-Index":"AQHTKpsc74eWq9/D8UCz3cO7YtCnIaK1nAiAgAT4xtD//45AAIAAidDA","Date":"Mon, 18 Sep 2017 13:23:31 +0000","Message-ID":"<33183CC9F5247A488A2544077AF19020DA3D9B61@DGGEMA505-MBX.china.huawei.com>","References":"<1505092362-10544-1-git-send-email-longpeng2@huawei.com>\n\t<1505092362-10544-2-git-send-email-longpeng2@huawei.com>\n\t<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>\n\t<33183CC9F5247A488A2544077AF19020DA3D9A7B@DGGEMA505-MBX.china.huawei.com>\n\t<73b9f2a8-6746-593b-4277-3ea757476130@linux.vnet.ibm.com>","In-Reply-To":"<73b9f2a8-6746-593b-4277-3ea757476130@linux.vnet.ibm.com>","Accept-Language":"zh-CN, en-US","Content-Language":"zh-CN","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.177.18.62]","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020204.59BFC8E0.022C, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.3,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"cfdf413f409c724f29081847e6d767e8","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic]\n\t[fuzzy]","X-Received-From":"45.249.212.188","Subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"wangxin \\(U\\)\" ,\n\t\"Ola.Liljedahl@arm.com\" ,\n\t\"Huangweidong \\(C\\)\" ,\n\t\"brian.a.keating@intel.com\" ,\n\t\"mst@redhat.com\" ,\n\t\"xin.zeng@intel.com\" ,\n\t\"jasowang@redhat.com\" ,\n\t\"cohuck@redhat.com\" ,\n\tLuonengjun , \"agraf@suse.de\" , \n\t\"john.griffin@intel.com\" ,\n\t\"mike.caraman@nxp.com\" ,\n\t\"liang.j.ma@intel.com\" ,\n\t\"stefanha@redhat.com\" ,\n\t\"Varun.Sethi@freescale.com\" ,\n\tJani Kokkonen ,\n\t\"vincent.jardin@6wind.com\" ,\n\t\"denglingli@chinamobile.com\" ,\n\t\"arei.gonglei@hotmail.com\" ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1770221,"web_url":"http://patchwork.ozlabs.org/comment/1770221/","msgid":"<82063967A54EF84C8AFCD6BD7F6AD93310E1111B@SHSMSX103.ccr.corp.intel.com>","list_archive_url":null,"date":"2017-09-18T14:51:33","subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","submitter":{"id":69869,"url":"http://patchwork.ozlabs.org/api/people/69869/","name":"Zeng, Xin","email":"xin.zeng@intel.com"},"content":"On Monday, September 18, 2017 9:24 PM, Gonglei (Arei) wrote:\r\n\r\n< > On 09/18/2017 02:13 PM, Gonglei (Arei) wrote:\r\n< > >> Destroy does not need to specify queue_id. That means session_id's aren't\r\n< > >> queue scoped from namespace perspective. The question remains what is\r\n< > >> queue_id good for, and whether a session type op request should be\r\n< > >> rejected if the the session id originates from a session creation\r\n< > >> request specifying a different dataqueue (not the dataqueue containing\r\n< > >> the given request)?\r\n< > >>\r\n< > > My original idea about the queue_id is using the queue_id to specify which\r\n< > > datequeue of the following data requests will be used. But after deep\r\n< > thinking,\r\n< > > I find that the queue_id is superfluous, and the current code in QEMU also\r\n< > > don't use the queue_id value as well. That's because the we can use\r\n< > session_id\r\n< > > to find the pervious session information and get the current dataqueue id\r\n< > > from the used virtqueue .\r\n< > >\r\n< > > So maybe we should drop the queue_id this time.\r\n< > >\r\n< > >\r\n< >\r\n< > Sounds reasonable to me. We can make it reserved and ignored in\r\n< > the specification. Linux uses it, but it's always set to 0 as we only\r\n< > support one data-queue (if I'm not wrong). So reserved and must be zero\r\n< > is an option too.\r\n< >\r\n< Makes sense to keeping compatibility.\r\n< \r\n\r\nIf we always set it to 0, and backend device doesn't specify the queue\r\nid when creating session, this works only when one data queue is\r\nsupported. But if we want to support multi data queues,\r\nhow does frontend driver know which queue it should use when \r\nsending requests to the virt queue? And furthermore, if the data queue \r\nid which can be used is determined by backend device, how does \r\nguest frontend driver know which queue can be used when operating\r\nin stateless mode in case multi data queue is supported?\r\nSo from my point of view, session should only be associated with service\r\nrelated information, but not associated with the transport layer information,\r\ni.e. data queue id in this case. The data queue to be used should be chosen by\r\nfrontend driver. Frontend driver can use any valid data queue to send requests\r\nto backend device, backend device need to extract the session information\r\nfrom the request packet and retrieve the request's session info then handle it \r\ncorrespondingly.\r\n\r\n< Thanks,\r\n< -Gonglei","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwprG6wW4z9s3w\n\tfor ;\n\tTue, 19 Sep 2017 00:52:14 +1000 (AEST)","from localhost ([::1]:37085 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dtxPB-0005of-5H\n\tfor incoming@patchwork.ozlabs.org; Mon, 18 Sep 2017 10:52:13 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:33253)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dtxOq-0005o6-4a\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 10:51:53 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dtxOm-0003X8-UQ\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 10:51:52 -0400","from mga03.intel.com ([134.134.136.65]:4835)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dtxOm-0003VV-Iw\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 10:51:48 -0400","from orsmga001.jf.intel.com ([10.7.209.18])\n\tby orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t18 Sep 2017 07:51:37 -0700","from fmsmsx103.amr.corp.intel.com ([10.18.124.201])\n\tby orsmga001.jf.intel.com with ESMTP; 18 Sep 2017 07:51:37 -0700","from FMSMSX109.amr.corp.intel.com (10.18.116.9) by\n\tFMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Mon, 18 Sep 2017 07:51:36 -0700","from shsmsx151.ccr.corp.intel.com (10.239.6.50) by\n\tfmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server\n\t(TLS) id 14.3.319.2; Mon, 18 Sep 2017 07:51:36 -0700","from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by\n\tSHSMSX151.ccr.corp.intel.com ([169.254.3.98]) with mapi id\n\t14.03.0319.002; Mon, 18 Sep 2017 22:51:34 +0800"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos; i=\"5.42,413,1500966000\"; d=\"scan'208\";\n\ta=\"1173319558\"","From":"\"Zeng, Xin\" ","To":"\"Gonglei (Arei)\" , Halil Pasic\n\t, longpeng ,\n\t\"qemu-devel@nongnu.org\" ,\n\t\"virtio-dev@lists.oasis-open.org\" ","Thread-Topic":"[Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","Thread-Index":"AQHTMHeNbXGGOs56IE+aam5h0UjCVKK6F1YAgAAEQoCAAJv3AA==","Date":"Mon, 18 Sep 2017 14:51:33 +0000","Message-ID":"<82063967A54EF84C8AFCD6BD7F6AD93310E1111B@SHSMSX103.ccr.corp.intel.com>","References":"<1505092362-10544-1-git-send-email-longpeng2@huawei.com>\n\t<1505092362-10544-2-git-send-email-longpeng2@huawei.com>\n\t<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>\n\t<33183CC9F5247A488A2544077AF19020DA3D9A7B@DGGEMA505-MBX.china.huawei.com>\n\t<73b9f2a8-6746-593b-4277-3ea757476130@linux.vnet.ibm.com>\n\t<33183CC9F5247A488A2544077AF19020DA3D9B61@DGGEMA505-MBX.china.huawei.com>","In-Reply-To":"<33183CC9F5247A488A2544077AF19020DA3D9B61@DGGEMA505-MBX.china.huawei.com>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjY2Y2QxNWUtOGI1Mi00ODRmLWIwNjAtY2QzNGY5OTljNzM1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlpTM0lPMXVhUldMdTE1WUkwYjNNRE9HY1dDTUhadFVcL2VMUnlmY0FjVGNzPSJ9","x-ctpclassification":"CTP_IC","dlp-product":"dlpe-windows","dlp-version":"11.0.0.116","dlp-reaction":"no-action","x-originating-ip":"[10.239.127.40]","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"134.134.136.65","Subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"wangxin \\(U\\)\" ,\n\t\"Ola.Liljedahl@arm.com\" ,\n\t\"Huangweidong \\(C\\)\" , \"Keating,\n\tBrian A\" ,\n\t\"mst@redhat.com\" , \"Ma, Liang J\" , \n\t\"jasowang@redhat.com\" ,\n\t\"cohuck@redhat.com\" ,\n\tLuonengjun ,\n\t\"agraf@suse.de\" , \"Griffin,\n\tJohn\" , \n\t\"mike.caraman@nxp.com\" ,\n\t\"stefanha@redhat.com\" ,\n\t\"Varun.Sethi@freescale.com\" ,\n\tJani Kokkonen ,\n\t\"vincent.jardin@6wind.com\" ,\n\t\"denglingli@chinamobile.com\" ,\n\t\"arei.gonglei@hotmail.com\" ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1770299,"web_url":"http://patchwork.ozlabs.org/comment/1770299/","msgid":"","list_archive_url":null,"date":"2017-09-18T16:32:57","subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/18/2017 04:51 PM, Zeng, Xin wrote:\n> On Monday, September 18, 2017 9:24 PM, Gonglei (Arei) wrote:\n> \n> < > On 09/18/2017 02:13 PM, Gonglei (Arei) wrote:\n> < > >> Destroy does not need to specify queue_id. That means session_id's aren't\n> < > >> queue scoped from namespace perspective. The question remains what is\n> < > >> queue_id good for, and whether a session type op request should be\n> < > >> rejected if the the session id originates from a session creation\n> < > >> request specifying a different dataqueue (not the dataqueue containing\n> < > >> the given request)?\n> < > >>\n> < > > My original idea about the queue_id is using the queue_id to specify which\n> < > > datequeue of the following data requests will be used. But after deep\n> < > thinking,\n> < > > I find that the queue_id is superfluous, and the current code in QEMU also\n> < > > don't use the queue_id value as well. That's because the we can use\n> < > session_id\n> < > > to find the pervious session information and get the current dataqueue id\n> < > > from the used virtqueue .\n> < > >\n> < > > So maybe we should drop the queue_id this time.\n> < > >\n> < > >\n> < >\n> < > Sounds reasonable to me. We can make it reserved and ignored in\n> < > the specification. Linux uses it, but it's always set to 0 as we only\n> < > support one data-queue (if I'm not wrong). So reserved and must be zero\n> < > is an option too.\n> < >\n> < Makes sense to keeping compatibility.\n> < \n> \n> If we always set it to 0, and backend device doesn't specify the queue\n> id when creating session, this works only when one data queue is\n> supported. But if we want to support multi data queues,\n> how does frontend driver know which queue it should use when \n> sending requests to the virt queue? And furthermore, if the data queue \n> id which can be used is determined by backend device, how does \n> guest frontend driver know which queue can be used when operating\n> in stateless mode in case multi data queue is supported?\n\nAFAIU you answered your own questions (questions above, answers below). Gonglei\nhas just stated that he intends to abandon the queue_id.\n\n> So from my point of view, session should only be associated with service\n> related information, but not associated with the transport layer information,\n> i.e. data queue id in this case. The data queue to be used should be chosen by\n> frontend driver. Frontend driver can use any valid data queue to send requests\n> to backend device, backend device need to extract the session information\n> from the request packet and retrieve the request's session info then handle it \n> correspondingly.\n\nAFAIU that's what we have agreed, basically. I'm not sure about your wording\n(for instance I would have said session identifier instead of session information),\nbut I think we think the same. In short conceptually all configured data queues\nare equivalent in the sense that it does not matter on which queue a request is\nplaced -- modulo capacity.\n\nHalil\n\n> \n> < Thanks,\n> < -Gonglei\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xws5g1VqYz9s78\n\tfor ;\n\tTue, 19 Sep 2017 02:33:58 +1000 (AEST)","from localhost ([::1]:37763 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dtyzc-0001lY-M0\n\tfor incoming@patchwork.ozlabs.org; Mon, 18 Sep 2017 12:33:56 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:50969)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dtyyx-0001iM-Cm\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 12:33:16 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dtyyt-0008KF-Dn\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 12:33:15 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:38912)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dtyyt-0008JI-3u\n\tfor qemu-devel@nongnu.org; Mon, 18 Sep 2017 12:33:11 -0400","from pps.filterd (m0098393.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8IGQpnI062163\n\tfor ; Mon, 18 Sep 2017 12:33:08 -0400","from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d2d23ub73-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Mon, 18 Sep 2017 12:33:08 -0400","from localhost\n\tby e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tMon, 18 Sep 2017 17:33:05 +0100","from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197)\n\tby e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tMon, 18 Sep 2017 17:32:59 +0100","from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com\n\t[9.149.105.60])\n\tby b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8IGWwvS14483700; Mon, 18 Sep 2017 16:32:58 GMT","from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 3A34842041;\n\tMon, 18 Sep 2017 17:29:12 +0100 (BST)","from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 3395C4203F;\n\tMon, 18 Sep 2017 17:29:11 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tMon, 18 Sep 2017 17:29:11 +0100 (BST)"],"To":"\"Zeng, Xin\" , \"Gonglei (Arei)\"\n\t, longpeng ,\n\t\"qemu-devel@nongnu.org\" ,\n\t\"virtio-dev@lists.oasis-open.org\" ","References":"<1505092362-10544-1-git-send-email-longpeng2@huawei.com>\n\t<1505092362-10544-2-git-send-email-longpeng2@huawei.com>\n\t<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>\n\t<33183CC9F5247A488A2544077AF19020DA3D9A7B@DGGEMA505-MBX.china.huawei.com>\n\t<73b9f2a8-6746-593b-4277-3ea757476130@linux.vnet.ibm.com>\n\t<33183CC9F5247A488A2544077AF19020DA3D9B61@DGGEMA505-MBX.china.huawei.com>\n\t<82063967A54EF84C8AFCD6BD7F6AD93310E1111B@SHSMSX103.ccr.corp.intel.com>","From":"Halil Pasic ","Date":"Mon, 18 Sep 2017 18:32:57 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"<82063967A54EF84C8AFCD6BD7F6AD93310E1111B@SHSMSX103.ccr.corp.intel.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-TM-AS-GCONF":"00","x-cbid":"17091816-0016-0000-0000-000004EDD7B8","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091816-0017-0000-0000-0000282806AB","Message-Id":"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-18_06:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709180234","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.156.1","Subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"wangxin \\(U\\)\" ,\n\t\"Ola.Liljedahl@arm.com\" ,\n\t\"Huangweidong \\(C\\)\" , \"Keating,\n\tBrian A\" ,\n\t\"mst@redhat.com\" , \"Ma, Liang J\" , \n\t\"jasowang@redhat.com\" ,\n\t\"cohuck@redhat.com\" ,\n\tLuonengjun ,\n\t\"agraf@suse.de\" , \"Griffin,\n\tJohn\" , \n\t\"mike.caraman@nxp.com\" ,\n\t\"stefanha@redhat.com\" ,\n\t\"Varun.Sethi@freescale.com\" ,\n\tJani Kokkonen ,\n\t\"vincent.jardin@6wind.com\" ,\n\t\"denglingli@chinamobile.com\" ,\n\t\"arei.gonglei@hotmail.com\" ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1770722,"web_url":"http://patchwork.ozlabs.org/comment/1770722/","msgid":"<82063967A54EF84C8AFCD6BD7F6AD93310E11D28@SHSMSX103.ccr.corp.intel.com>","list_archive_url":null,"date":"2017-09-19T08:01:46","subject":"Re: [Qemu-devel] [virtio-dev] Re: [PATCH REPOST v19 1/2]\n\tvirtio-crypto: Add virtio crypto device specification","submitter":{"id":69869,"url":"http://patchwork.ozlabs.org/api/people/69869/","name":"Zeng, Xin","email":"xin.zeng@intel.com"},"content":"on September 19, 2017 12:33 AM Halil Pasic Wrote:\r\n< > < > >> Destroy does not need to specify queue_id. That means session_id's\r\n< aren't\r\n< > < > >> queue scoped from namespace perspective. The question remains what\r\n< is\r\n< > < > >> queue_id good for, and whether a session type op request should be\r\n< > < > >> rejected if the the session id originates from a session creation\r\n< > < > >> request specifying a different dataqueue (not the dataqueue containing\r\n< > < > >> the given request)?\r\n< > < > >>\r\n< > < > > My original idea about the queue_id is using the queue_id to specify\r\n< which\r\n< > < > > datequeue of the following data requests will be used. But after deep\r\n< > < > thinking,\r\n< > < > > I find that the queue_id is superfluous, and the current code in QEMU\r\n< also\r\n< > < > > don't use the queue_id value as well. That's because the we can use\r\n< > < > session_id\r\n< > < > > to find the pervious session information and get the current dataqueue id\r\n< > < > > from the used virtqueue .\r\n< > < > >\r\n< > < > > So maybe we should drop the queue_id this time.\r\n< > < > >\r\n< > < > >\r\n< > < >\r\n< > < > Sounds reasonable to me. We can make it reserved and ignored in\r\n< > < > the specification. Linux uses it, but it's always set to 0 as we only\r\n< > < > support one data-queue (if I'm not wrong). So reserved and must be zero\r\n< > < > is an option too.\r\n< > < >\r\n< > < Makes sense to keeping compatibility.\r\n< > <\r\n< >\r\n< > If we always set it to 0, and backend device doesn't specify the queue\r\n< > id when creating session, this works only when one data queue is\r\n< > supported. But if we want to support multi data queues,\r\n< > how does frontend driver know which queue it should use when\r\n< > sending requests to the virt queue? And furthermore, if the data queue\r\n< > id which can be used is determined by backend device, how does\r\n< > guest frontend driver know which queue can be used when operating\r\n< > in stateless mode in case multi data queue is supported?\r\n< \r\n< AFAIU you answered your own questions (questions above, answers below).\r\n< Gonglei\r\n< has just stated that he intends to abandon the queue_id.\r\n< \r\n< > So from my point of view, session should only be associated with service\r\n< > related information, but not associated with the transport layer information,\r\n< > i.e. data queue id in this case. The data queue to be used should be chosen by\r\n< > frontend driver. Frontend driver can use any valid data queue to send requests\r\n< > to backend device, backend device need to extract the session information\r\n< > from the request packet and retrieve the request's session info then handle it\r\n< > correspondingly.\r\n< \r\n< AFAIU that's what we have agreed, basically. I'm not sure about your wording\r\n< (for instance I would have said session identifier instead of session information),\r\n< but I think we think the same. In short conceptually all configured data queues\r\n< are equivalent in the sense that it does not matter on which queue a request is\r\n< placed -- modulo capacity.\r\n\r\nActually I agreed with your point to make queue_id reserved in \r\ncurrent implementation and ignored in the spec. I just want to clarify the \r\nusage of virt queues especially when multi data queue is supported.\r\nNow it's clear, thanks.\r\n\r\nCheers\r\nXin\r\n\r\n< \r\n< Halil\r\n< \r\n< >\r\n< > < Thanks,\r\n< > < -Gonglei\r\n< >n\r\n< \r\n< \r\n< ---------------------------------------------------------------------\r\n< To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org\r\n< For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxFjL0WhMz9ryT\n\tfor ;\n\tTue, 19 Sep 2017 18:02:46 +1000 (AEST)","from localhost ([::1]:40673 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duDUS-0002qu-5H\n\tfor incoming@patchwork.ozlabs.org; Tue, 19 Sep 2017 04:02:44 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:54882)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duDTi-0002mu-Aa\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 04:02:02 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duDTb-0000Xs-R8\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 04:01:58 -0400","from mga07.intel.com ([134.134.136.100]:33161)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1duDTb-0000Vj-FY\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 04:01:51 -0400","from fmsmga004.fm.intel.com ([10.253.24.48])\n\tby orsmga105.jf.intel.com with ESMTP; 19 Sep 2017 01:01:49 -0700","from fmsmsx103.amr.corp.intel.com ([10.18.124.201])\n\tby fmsmga004.fm.intel.com with ESMTP; 19 Sep 2017 01:01:49 -0700","from fmsmsx124.amr.corp.intel.com (10.18.125.39) by\n\tFMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Tue, 19 Sep 2017 01:01:49 -0700","from shsmsx152.ccr.corp.intel.com (10.239.6.52) by\n\tfmsmsx124.amr.corp.intel.com (10.18.125.39) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Tue, 19 Sep 2017 01:01:49 -0700","from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by\n\tSHSMSX152.ccr.corp.intel.com ([169.254.6.93]) with mapi id\n\t14.03.0319.002; Tue, 19 Sep 2017 16:01:47 +0800"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,417,1500966000\"; d=\"scan'208\";a=\"313659696\"","From":"\"Zeng, Xin\" ","To":"Halil Pasic , \"Gonglei (Arei)\"\n\t, longpeng ,\n\t\"qemu-devel@nongnu.org\" ,\n\t\"virtio-dev@lists.oasis-open.org\" ","Thread-Topic":"[virtio-dev] Re: [Qemu-devel] [PATCH REPOST v19 1/2]\n\tvirtio-crypto: Add virtio crypto device specification","Thread-Index":"AQHTMHeNbXGGOs56IE+aam5h0UjCVKK6F1YAgAAEQoCAAJv3AP//mPeAgAGFtgA=","Date":"Tue, 19 Sep 2017 08:01:46 +0000","Message-ID":"<82063967A54EF84C8AFCD6BD7F6AD93310E11D28@SHSMSX103.ccr.corp.intel.com>","References":"<1505092362-10544-1-git-send-email-longpeng2@huawei.com>\n\t<1505092362-10544-2-git-send-email-longpeng2@huawei.com>\n\t<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>\n\t<33183CC9F5247A488A2544077AF19020DA3D9A7B@DGGEMA505-MBX.china.huawei.com>\n\t<73b9f2a8-6746-593b-4277-3ea757476130@linux.vnet.ibm.com>\n\t<33183CC9F5247A488A2544077AF19020DA3D9B61@DGGEMA505-MBX.china.huawei.com>\n\t<82063967A54EF84C8AFCD6BD7F6AD93310E1111B@SHSMSX103.ccr.corp.intel.com>\n\t","In-Reply-To":"","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDQyZThiZTAtZTFhNi00YjA0LWJmNGYtNDM2YjQ4Njc4MmViIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImFMRnM0ODNKMTRNaW04NEVPU0hQNm9QUkxkOXFwNmR1dXpxbUVSVVNWVzQ9In0=","x-ctpclassification":"CTP_IC","dlp-product":"dlpe-windows","dlp-version":"11.0.0.116","dlp-reaction":"no-action","x-originating-ip":"[10.239.127.40]","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"134.134.136.100","Subject":"Re: [Qemu-devel] [virtio-dev] Re: [PATCH REPOST v19 1/2]\n\tvirtio-crypto: Add virtio crypto device specification","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"wangxin \\(U\\)\" ,\n\t\"Ola.Liljedahl@arm.com\" ,\n\t\"Huangweidong \\(C\\)\" , \"Keating,\n\tBrian A\" ,\n\t\"mst@redhat.com\" , \"Ma, Liang J\" , \n\t\"jasowang@redhat.com\" ,\n\t\"cohuck@redhat.com\" ,\n\tLuonengjun ,\n\t\"agraf@suse.de\" , \"Griffin,\n\tJohn\" , \n\t\"mike.caraman@nxp.com\" ,\n\t\"stefanha@redhat.com\" ,\n\t\"Varun.Sethi@freescale.com\" ,\n\tJani Kokkonen ,\n\t\"vincent.jardin@6wind.com\" ,\n\t\"denglingli@chinamobile.com\" ,\n\t\"arei.gonglei@hotmail.com\" ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1775544,"web_url":"http://patchwork.ozlabs.org/comment/1775544/","msgid":"<59CA5C3F.7080708@huawei.com>","list_archive_url":null,"date":"2017-09-26T13:55:11","subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","submitter":{"id":69776,"url":"http://patchwork.ozlabs.org/api/people/69776/","name":"Longpeng (Mike, Cloud Infrastructure Service Product Dept.)","email":"longpeng2@huawei.com"},"content":"Hi Halil,\n\nOn 2017/9/15 22:39, Halil Pasic wrote:\n\n> \n> \n> On 09/11/2017 03:12 AM, Longpeng(Mike) wrote:\n>> From: Gonglei \n>>\n>> The virtio crypto device is a virtual crypto device (ie. hardware\n>> crypto accelerator card). Currently, the virtio crypto device provides\n>> the following crypto services: CIPHER, MAC, HASH, and AEAD.\n>>\n>> In this patch, CIPHER, MAC, HASH, AEAD services are introduced.\n>>\n>> VIRTIO-153\n>>\n>> Signed-off-by: Gonglei \n>> Signed-off-by: Longpeng(Mike) \n>> ---\n>> acknowledgements.tex | 3 +\n>> content.tex | 2 +\n>> virtio-crypto.tex | 1479 ++++++++++++++++++++++++++++++++++++++++++++++++++\n>> 3 files changed, 1484 insertions(+)\n>> create mode 100644 virtio-crypto.tex\n>>\n>> diff --git a/acknowledgements.tex b/acknowledgements.tex\n>> index 6c86d12..c4b6844 100644\n>> --- a/acknowledgements.tex\n>> +++ b/acknowledgements.tex\n>> @@ -26,6 +26,8 @@ Sasha Levin,\tOracle\t\\newline\n>> Sergey Tverdyshev,\tThales e-Security\t\\newline\n>> Stefan Hajnoczi,\tRed Hat\t\\newline\n>> Tom Lyon,\tSamya Systems, Inc.\t\\newline\n>> +Lei Gong,\tHuawei\t\\newline\n>> +Peng Long,\tHuawei\t\\newline\n>> \\end{oasistitlesection}\n>>\n>> The following non-members have provided valuable feedback on this\n>> @@ -43,4 +45,5 @@ Laura Novich, Red Hat\t\\newline\n>> Patrick Durusau,\tTechnical Advisory Board, OASIS\t\\newline\n>> Thomas Huth,\tIBM\t\\newline\n>> Yan Vugenfirer, Red Hat / Daynix\t\\newline\n>> +Halil Pasic,\tIBM\t\\newline\n>> \\end{oasistitlesection}\n>> diff --git a/content.tex b/content.tex\n>> index d989d98..7710f8c 100644\n>> --- a/content.tex\n>> +++ b/content.tex\n>> @@ -5641,6 +5641,8 @@ descriptor for the \\field{sense_len}, \\field{residual},\n>> \\field{status_qualifier}, \\field{status}, \\field{response} and\n>> \\field{sense} fields.\n>>\n>> +\\input{virtio-crypto.tex}\n>> +\n>> \\chapter{Reserved Feature Bits}\\label{sec:Reserved Feature Bits}\n>>\n>> Currently there are three device-independent feature bits defined:\n>> diff --git a/virtio-crypto.tex b/virtio-crypto.tex\n>> new file mode 100644\n>> index 0000000..1e75cbc\n>> --- /dev/null\n>> +++ b/virtio-crypto.tex\n>> @@ -0,0 +1,1479 @@\n>> +\\section{Crypto Device}\\label{sec:Device Types / Crypto Device}\n>> +\n>> +The virtio crypto device is a virtual cryptography device as well as a\n>> +virtual cryptographic accelerator. The virtio crypto device provides the\n>> +following crypto services: CIPHER, MAC, HASH, and AEAD. Virtio crypto\n>> +devices have a single control queue and at least one data queue. Crypto\n>> +operation requests are placed into a data queue, and serviced by the\n>> +device. Some crypto operation requests are only valid in the context of a\n>> +session. The role of the control queue is facilitating control operation\n>> +requests. Sessions management is realized with control operation\n>> +requests.\n>> +\n>> +\\subsection{Device ID}\\label{sec:Device Types / Crypto Device / Device ID}\n>> +\n>> +20\n>> +\n>> +\\subsection{Virtqueues}\\label{sec:Device Types / Crypto Device / Virtqueues}\n>> +\n>> +\\begin{description}\n>> +\\item[0] dataq1\n>> +\\item[\\ldots]\n>> +\\item[N-1] dataqN\n>> +\\item[N] controlq\n>> +\\end{description}\n>> +\n>> +N is set by \\field{max_dataqueues}.\n>> +\n>> +\\subsection{Feature bits}\\label{sec:Device Types / Crypto Device / Feature bits}\n>> +\n>> +\\begin{description}\n>> +\\item VIRTIO_CRYPTO_F_MUX_MODE (0) multiplexing mode is available.\n>> +\\item VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE (1) stateless mode is available for CIPHER service.\n>> +\\item VIRTIO_CRYPTO_F_HASH_STATELESS_MODE (2) stateless mode is available for HASH service.\n>> +\\item VIRTIO_CRYPTO_F_MAC_STATELESS_MODE (3) stateless mode is available for MAC service.\n>> +\\item VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE (4) stateless mode is available for AEAD service.\n>> +\\end{description}\n>> +\n>> +\\subsubsection{Feature bit requirements}\\label{sec:Device Types / Crypto Device / Feature bits}\n>> +\n>> +Some crypto feature bits require other crypto feature bits\n>> +(see \\ref{drivernormative:Basic Facilities of a Virtio Device / Feature Bits}):\n>> +\n>> +\\begin{description}\n>> +\\item[VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.\n>> +\\item[VIRTIO_CRYPTO_F_HASH_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.\n>> +\\item[VIRTIO_CRYPTO_F_MAC_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.\n>> +\\item[VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.\n>> +\\end{description}\n>> +\n>> +\\subsection{Supported crypto services}\\label{sec:Device Types / Crypto Device / Supported crypto services}\n>> +\n>> +The following crypto services are defined:\n>> +\n>> +\\begin{lstlisting}\n>> +/* CIPHER service */\n>> +#define VIRTIO_CRYPTO_SERVICE_CIPHER 0\n>> +/* HASH service */\n>> +#define VIRTIO_CRYPTO_SERVICE_HASH 1\n>> +/* MAC (Message Authentication Codes) service */\n>> +#define VIRTIO_CRYPTO_SERVICE_MAC 2\n>> +/* AEAD (Authenticated Encryption with Associated Data) service */\n>> +#define VIRTIO_CRYPTO_SERVICE_AEAD 3\n>> +\\end{lstlisting}\n>> +\n>> +The above constants designate bits used to indicate the which of crypto services are\n>> +offered by the device as described in, see \\ref{sec:Device Types / Crypto Device / Device configuration layout}.\n>> +\n>> +\\subsubsection{CIPHER services}\\label{sec:Device Types / Crypto Device / Supported crypto services / CIPHER services}\n>> +\n>> +The following CIPHER algorithms are defined:\n>> +\n>> +\\begin{lstlisting}\n>> +#define VIRTIO_CRYPTO_NO_CIPHER 0\n>> +#define VIRTIO_CRYPTO_CIPHER_ARC4 1\n>> +#define VIRTIO_CRYPTO_CIPHER_AES_ECB 2\n>> +#define VIRTIO_CRYPTO_CIPHER_AES_CBC 3\n>> +#define VIRTIO_CRYPTO_CIPHER_AES_CTR 4\n>> +#define VIRTIO_CRYPTO_CIPHER_DES_ECB 5\n>> +#define VIRTIO_CRYPTO_CIPHER_DES_CBC 6\n>> +#define VIRTIO_CRYPTO_CIPHER_3DES_ECB 7\n>> +#define VIRTIO_CRYPTO_CIPHER_3DES_CBC 8\n>> +#define VIRTIO_CRYPTO_CIPHER_3DES_CTR 9\n>> +#define VIRTIO_CRYPTO_CIPHER_KASUMI_F8 10\n>> +#define VIRTIO_CRYPTO_CIPHER_SNOW3G_UEA2 11\n>> +#define VIRTIO_CRYPTO_CIPHER_AES_F8 12\n>> +#define VIRTIO_CRYPTO_CIPHER_AES_XTS 13\n>> +#define VIRTIO_CRYPTO_CIPHER_ZUC_EEA3 14\n>> +\\end{lstlisting}\n>> +\n>> +The above constants have two usages:\n>> +\\begin{enumerate}\n>> +\\item As bit numbers, used to tell the driver which CIPHER algorithms\n>> +are supported by the device, see \\ref{sec:Device Types / Crypto Device / Device configuration layout}.\n>> +\\item As values, used to tell the device which CIPHER algorithm\n>> +a crypto request from the driver requires, see \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}.\n>> +\\end{enumerate}\n>> +\n>> +\\subsubsection{HASH services}\\label{sec:Device Types / Crypto Device / Supported crypto services / HASH services}\n>> +\n>> +The following HASH algorithms are defined:\n>> +\n>> +\\begin{lstlisting}\n>> +#define VIRTIO_CRYPTO_NO_HASH 0\n>> +#define VIRTIO_CRYPTO_HASH_MD5 1\n>> +#define VIRTIO_CRYPTO_HASH_SHA1 2\n>> +#define VIRTIO_CRYPTO_HASH_SHA_224 3\n>> +#define VIRTIO_CRYPTO_HASH_SHA_256 4\n>> +#define VIRTIO_CRYPTO_HASH_SHA_384 5\n>> +#define VIRTIO_CRYPTO_HASH_SHA_512 6\n>> +#define VIRTIO_CRYPTO_HASH_SHA3_224 7\n>> +#define VIRTIO_CRYPTO_HASH_SHA3_256 8\n>> +#define VIRTIO_CRYPTO_HASH_SHA3_384 9\n>> +#define VIRTIO_CRYPTO_HASH_SHA3_512 10\n>> +#define VIRTIO_CRYPTO_HASH_SHA3_SHAKE128 11\n>> +#define VIRTIO_CRYPTO_HASH_SHA3_SHAKE256 12\n>> +\\end{lstlisting}\n>> +\n>> +The above constants have two usages:\n>> +\\begin{enumerate}\n>> +\\item As bit numbers, used to tell the driver which HASH algorithms\n>> +are supported by the device, see \\ref{sec:Device Types / Crypto Device / Device configuration layout}.\n>> +\\item As values, used to tell the device which HASH algorithm\n>> +a crypto request from the driver requires, see \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}.\n>> +\\end{enumerate}\n>> +\n>> +\\subsubsection{MAC services}\\label{sec:Device Types / Crypto Device / Supported crypto services / MAC services}\n>> +\n>> +The following MAC algorithms are defined:\n>> +\n>> +\\begin{lstlisting}\n>> +#define VIRTIO_CRYPTO_NO_MAC 0\n>> +#define VIRTIO_CRYPTO_MAC_HMAC_MD5 1\n>> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA1 2\n>> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_224 3\n>> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_256 4\n>> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_384 5\n>> +#define VIRTIO_CRYPTO_MAC_HMAC_SHA_512 6\n>> +#define VIRTIO_CRYPTO_MAC_CMAC_3DES 25\n>> +#define VIRTIO_CRYPTO_MAC_CMAC_AES 26\n>> +#define VIRTIO_CRYPTO_MAC_KASUMI_F9 27\n>> +#define VIRTIO_CRYPTO_MAC_SNOW3G_UIA2 28\n>> +#define VIRTIO_CRYPTO_MAC_GMAC_AES 41\n>> +#define VIRTIO_CRYPTO_MAC_GMAC_TWOFISH 42\n>> +#define VIRTIO_CRYPTO_MAC_CBCMAC_AES 49\n>> +#define VIRTIO_CRYPTO_MAC_CBCMAC_KASUMI_F9 50\n>> +#define VIRTIO_CRYPTO_MAC_XCBC_AES 53\n>> +#define VIRTIO_CRYPTO_MAC_ZUC_EIA3 54\n>> +\\end{lstlisting}\n>> +\n>> +The above constants have two usages:\n>> +\\begin{enumerate}\n>> +\\item As bit numbers, used to tell the driver which MAC algorithms\n>> +are supported by the device, see \\ref{sec:Device Types / Crypto Device / Device configuration layout}.\n>> +\\item As values, used to tell the device which MAC algorithm\n>> +a crypto request from the driver requires, see \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}.\n> \n> Cosmetic comment: instead of 'used to tell the device which MAC algorithm\n> a crypto request form the driver requires' I would prefer 'used to designate\n> the algorithm in (MAC type) crypto operation requests'.\n> \n\n\nOK, yours is more decent. :)\n\n> I think, your version is good enough (won't be misunderstood) it is just\n> that request requires sound a bit weird to me. I'm not sure my version is\n> better though.\n> \n>> +\\end{enumerate}\n>> +\n>> +\\subsubsection{AEAD services}\\label{sec:Device Types / Crypto Device / Supported crypto services / AEAD services}\n>> +\n>> +The following AEAD algorithms are defined:\n>> +\n>> +\\begin{lstlisting}\n>> +#define VIRTIO_CRYPTO_NO_AEAD 0\n>> +#define VIRTIO_CRYPTO_AEAD_GCM 1\n>> +#define VIRTIO_CRYPTO_AEAD_CCM 2\n>> +#define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305 3\n>> +\\end{lstlisting}\n>> +\n>> +The above constants have two usages:\n>> +\\begin{enumerate}\n>> +\\item As bit numbers, used to tell the driver which AEAD algorithms\n>> +are supported by the device, see \\ref{sec:Device Types / Crypto Device / Device configuration layout}.\n>> +\\item As values, used to tell the device what AEAD algorithm\n>> +a crypto request from the driver requires, see \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}.\n> \n> More or less same as above (and we have some more similar occurrences below).\n> \n\nOK.\n\n>> +\\end{enumerate}\n>> +\n>> +\\subsection{Device configuration layout}\\label{sec:Device Types / Crypto Device / Device configuration layout}\n>> +\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_config {\n>> + le32 status;\n>> + le32 max_dataqueues;\n>> + le32 crypto_services;\n>> + /* Detailed algorithms mask */\n>> + le32 cipher_algo_l;\n>> + le32 cipher_algo_h;\n>> + le32 hash_algo;\n>> + le32 mac_algo_l;\n>> + le32 mac_algo_h;\n>> + le32 aead_algo;\n>> + /* Maximum length of cipher key in bytes */\n>> + le32 max_cipher_key_len;\n>> + /* Maximum length of authenticated key in bytes */\n>> + le32 max_auth_key_len;\n>> + le32 reserved;\n>> + /* Maximum size of each crypto request's content in bytes */\n>> + le64 max_size;\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +\\begin{description}\n>> +\\item[\\field{status}] is used to show whether the device is ready to work or\n>> + not, it can be either zero or have one or more flags. Only one read-only\n>> +\tbit (for the driver) is currently defined for the \\field{status} field: VIRTIO_CRYPTO_S_HW_READY:\n> \n> Cosmetic comment: maybe 'Currently, only one \\field(status) bit is defined:\n> IRTIO_CRYPTO_S_HW_READY set indicates that the device is ready to process\n> requests, this bit is read-only for the driver\n> \n\nOK.\n\n> While trying to reword this, I started thinking about whether read-only\n> makes sense for individual bits. I think it does not (I think we can't\n> do something like compare and swap to make this work). Does read\n> only even make sense for configuration space? I mean it is not random\n> access AFAIK (see 4.3 Virtio Over Channel I/O)?\n> \n> I'm confused abut the config space in general. I've expected that after\n> a certain stage it can be only changed by the device, but I didn't\n> manage to find a corresponding statement in the spec.\n> \n\nI'm not sure whether I understand you correctly.\n\nFor the virtio-crypto device, the fields in the configure space are all fixed\nafter the initialization, so maybe make them read-only is acceptable.\n\n>> +\\begin{lstlisting}\n>> +#define VIRTIO_CRYPTO_S_HW_READY (1 << 0)\n>> +\\end{lstlisting}\n>> +\n>> +\\item[\\field{max_dataqueues}] is the maximum number of data virtqueues exposed by\n>> + the device. The driver MAY use only one data queue,\n>> + or it can use more to achieve better performance.\n> \n> s/exposed/ that can be configured/\n> \n\n> This is the wording virtio-net uses (if I'm not mistaken). Exposed can be\n> misleading.\n> \n\nOK.\n\n>> +\n>> +\\item[\\field{crypto_services}] crypto service offered, see \\ref{sec:Device Types / Crypto Device / Supported crypto services}.\n>> +\n>> +\\item[\\field{cipher_algo_l}] CIPHER algorithms bits 0-31, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / CIPHER services}.\n>> +\n>> +\\item[\\field{cipher_algo_h}] CIPHER algorithms bits 32-63, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / CIPHER services}.\n>> +\n>> +\\item[\\field{hash_algo}] HASH algorithms bits, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / HASH services}.\n>> +\n>> +\\item[\\field{mac_algo_l}] MAC algorithms bits 0-31, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / MAC services}.\n>> +\n>> +\\item[\\field{mac_algo_h}] MAC algorithms bits 32-63, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / MAC services}.\n>> +\n>> +\\item[\\field{aead_algo}] AEAD algorithms bits, see \\ref{sec:Device Types / Crypto Device / Supported crypto services / AEAD services}.\n>> +\n>> +\\item[\\field{max_cipher_key_len}] is the maximum length of cipher key supported by the device.\n>> +\n>> +\\item[\\field{max_auth_key_len}] is the maximum length of authenticated key supported by the device.\n>> +\n>> +\\item[\\field{reserved}] is reserved for future use.\n>> +\n>> +\\item[\\field{max_size}] is the maximum size of each crypto request's content supported by the device\n>> +\\end{description}\n>> +\n>> +\\begin{note}\n>> +Unless explicitly stated otherwise all lengths and sizes are in bytes.\n>> +\\end{note}\n>> +\n>> +\\devicenormative{\\subsubsection}{Device configuration layout}{Device Types / Crypto Device / Device configuration layout}\n>> +\n>> +\\begin{itemize*}\n>> +\\item The device MUST set \\field{max_dataqueues} to between 1 and 65535 inclusive.\n>> +\\item The device MUST set the \\field{status} flag based on the status of the crypto\n> s/flag/flags ?\n>> + accelerator, Non-valid flags MUST NOT be set.\n> What does this mean? It is a device requirement so it can't be about the driver.\n> What does the device have to do if it encounters an unknown flag?\n\n\nHow about: The device MUST set the \\field{status} with valid flags, undefined\nflags MUST NOT be set ?\n\nThe existing crypto device in QEMU only sets VIRTIO_CRYPTO_S_HW_READY and other\nbits are zero, it's impossible to encounters an undefined flag.\n\n> \n>> +\\item The device MUST accept and handle requests after \\field{status} is set to VIRTIO_CRYPTO_S_HW_READY.\n>> +\\item The device MUST set \\field{crypto_services} based on the crypto services the device offers.\n>> +\\item The device MUST set detailed algorithms masks for each service advertised by \\field{crypto_services}.\n>> + The device MUST NOT set the not defined algorithms bits.\n>> +\\item The device MUST set \\field{max_size} to show the maximum size of crypto request the device supports.\n>> +\\item The device MUST set \\field{max_cipher_key_len} to show the maximum length of cipher key if the\n>> + device supports CIPHER service.\n>> +\\item The device MUST set \\field{max_auth_key_len} to show the maximum length of authenticated key if\n>> + the device supports MAC service.\n>> +\\end{itemize*}\n>> +\n>> +\\drivernormative{\\subsubsection}{Device configuration layout}{Device Types / Crypto Device / Device configuration layout}\n>> +\n>> +\\begin{itemize*}\n>> +\\item The driver MUST read the ready \\field{status} from the bottom bit of status to check whether the\n>> + crypto accelerator is ready or not, and the driver MUST reread it after device reset.\n> \n> You use 'ready' instead of VIRTIO_CRYPTO_S_HW_READY here and in the next point.\n> s/ MUST read the ready \\field{status}/ MUST read the \\field{status}/ ?\n> s/crypto accelerator is ready or not/VIRTIO_CRYPTO_S_HW_READY is set/ ?\n> \n\nUh, this is much better, thanks :)\n\n>> +\\item The driver MUST NOT transmit any requests to the device if the ready \\field{status} is not set.\n> s/if the ready \\field{status}/VIRTIO_CRYPTO_S_HW_READY/ ?\n\nOK.\n\n>> +\\item The driver MUST read \\field{max_dataqueues} field to discover the number of data queues the device supports.> +\\item The driver MUST read \\field{crypto_services} field to discover which services the device is able to offer.\n>> +\\item The driver SHOULD ignore the not defined algorithms bits.\n>> +\\item The driver MUST read the detailed algorithms fields based on \\field{crypto_services} field.\n>> +\\item The driver SHOULD read \\field{max_size} to discover the maximum size of crypto request the device supports.\n>> +\\item The driver SHOULD read \\field{max_cipher_key_len} to discover the maximum length of cipher key\n>> + the device supports.\n>> +\\item The driver SHOULD read \\field{max_auth_key_len} to discover the maximum length of authenticated\n>> + key the device supports.\n>> +\\end{itemize*}\n>> +\n>> +\\subsection{Device Initialization}\\label{sec:Device Types / Crypto Device / Device Initialization}\n>> +\n>> +\\drivernormative{\\subsubsection}{Device Initialization}{Device Types / Crypto Device / Device Initialization}\n>> +\n>> +\\begin{itemize*}\n>> +\\item The driver MUST identify and initialize all virtqueues.\n> s/initialize/configure/ ?\n> \n\nOK.\n\n> I wonder, do we really want to mandate configuring all virtqueues even\n> if some are going to be unused? If yes why?\n> \n\nIMHO the virtio-net does, please see:\n\t\\Device Types\\Network Device\\Device Initialization\n\nIn my opinion, this can makes everything as simple as possible. We need to\nconsider some complex situations if the vqs are configured as required, e.g,\nwhat should the driver to do if initialize the vq failure.\n\n>> +\\item The driver MUST read the supported crypto services from bits of \\field{crypto_services}.\n>> +\\item The driver MUST read the supported algorithms based on \\field{crypto_services} field.\n>> +\\end{itemize*}\n>> +\n>> +\\subsection{Device Operation}\\label{sec:Device Types / Crypto Device / Device Operation}\n>> +\n>> +Requests can be transmitted by placing them in the controlq or dataq.\n> \n> How about: The operation of a virtio crypto device is driven by requests\n> placed on the virtqueues.\n> \n> I don't like 'can be transmitted' and 'or' in your sentence. I can't put\n> my finger on it.\n> \n\nOK.\n\n>> +Requests consist of a queue-type specific header specifying among\n>> +others the operation, and an operation specific payload.\n> \n> Maybe put 'specifying among others the operation' in parenthesis or\n> between comas (I'm no good with grammar -- someone competent help!).\n> \n\nOK.\n\n>> +The payload is generally composed of operation parameters, output data, and input data.\n>> +Operation parameters are algorithm-specific parameters, output data is the\n> \n> Start a new sentence at the comma.\n\nOK.\n\n> \n>> +data that should be utilized in operations, and input data is equal to\n>> +\"operation result + result data\".\n>> +\n>> +The device can support both session mode (See \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}) and stateless mode.\n> \n> How about if VIRTIO_CRYPTO_F_MUX_MODE is negotioated the device\n> may support both session mode ... and stateless mode operation requests.\n> \n\nUh, yours is pretty good :)\n\n>> +In stateless mode all operation parameters are supplied as a part\n>> +of each request, while in session mode, some or all operation parameters\n>> +are managed within the session. Stateless mode is guarded by\n>> +feature bits 0-4 on a service level. If stateless mode is negotiated\n>> +for a service, the service is available both in session and\n>> +stateless mode; otherwise it's only available in session mode.\n>> +\n>> +The device can set the operation status as follows:\n> \n> This is the first time you mention operation status. The only status\n> we have defined is the config layout status. Can we introduce the\n> operation status later? Alternatively before we intreudce the op status\n> code we could tell something about how requests serviced, and of course\n> introduce the op status field as the part of (each?) request.\n> \n\nOK, I'll introduce them later in the next version.\n\n>> +\n>> +\\begin{lstlisting}\n>> +enum VIRTIO_CRYPTO_STATUS {\n>> + VIRTIO_CRYPTO_OK = 0,\n>> + VIRTIO_CRYPTO_ERR = 1,\n>> + VIRTIO_CRYPTO_BADMSG = 2,\n>> + VIRTIO_CRYPTO_NOTSUPP = 3,\n>> + VIRTIO_CRYPTO_INVSESS = 4,\n>> + VIRTIO_CRYPTO_NOSPC = 5,\n>> + VIRTIO_CRYPTO_MAX\n>> +};\n>> +\\end{lstlisting}\n>> +\n> \n> [..]\n> \n> I will continue reviewing right away but wanted to slit this up because\n> the patch is huge.\n> \n> My overall impression is pretty decent (up until this point) even\n> with my suggestions ignored. If this weren't a standard I wouldn't probably\n> bother with most of the comments (a la, it's good enough and can be improved\n> upon later if deemed necessary), but since it's a standard it's more important\n> to get things as good as possible already in the first version.\n\n\nYea, thank for your patience and comments, they're very useful. :)\n\n> \n> Regards,\n> Halil\n> \n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1jDt0Vtjz9tXK\n\tfor ;\n\tTue, 26 Sep 2017 23:57:02 +1000 (AEST)","from localhost ([::1]:47677 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dwqM8-0002Ft-7U\n\tfor incoming@patchwork.ozlabs.org; Tue, 26 Sep 2017 09:57:00 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:54970)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dwqLT-00029n-Oa\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 09:56:25 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dwqLL-0001EY-RB\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 09:56:19 -0400","from szxga05-in.huawei.com ([45.249.212.191]:2266)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71)\n\t(envelope-from ) id 1dwqLK-0001Ce-F5\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 09:56:11 -0400","from 172.30.72.60 (EHLO DGGEMS407-HUB.china.huawei.com)\n\t([172.30.72.60])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DIB51142; Tue, 26 Sep 2017 21:55:23 +0800 (CST)","from [127.0.0.1] (10.177.246.209) by DGGEMS407-HUB.china.huawei.com\n\t(10.3.19.207) with Microsoft SMTP Server id 14.3.301.0;\n\tTue, 26 Sep 2017 21:55:13 +0800"],"Message-ID":"<59CA5C3F.7080708@huawei.com>","Date":"Tue, 26 Sep 2017 21:55:11 +0800","From":"\"Longpeng (Mike)\" ","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64;\n\trv:11.0) Gecko/20120327 Thunderbird/11.0.1","MIME-Version":"1.0","To":"Halil Pasic ","References":"<1505092362-10544-1-git-send-email-longpeng2@huawei.com>\n\t<1505092362-10544-2-git-send-email-longpeng2@huawei.com>\n\t","In-Reply-To":"","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[10.177.246.209]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A0B0208.59CA5C4D.0101, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"93270fd1f333f12339b5f9a89d1c90dd","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic]\n\t[fuzzy]","X-Received-From":"45.249.212.191","Subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"weidong.huang@huawei.com, mst@redhat.com, jasowang@redhat.com,\n\tqemu-devel@nongnu.org, john.griffin@intel.com,\n\tVarun.Sethi@freescale.com, denglingli@chinamobile.com,\n\tarei.gonglei@hotmail.com, virtio-dev@lists.oasis-open.org,\n\tagraf@suse.de, arei.gonglei@huawei.com, vincent.jardin@6wind.com,\n\tOla.Liljedahl@arm.com, luonengjun@huawei.com, xin.zeng@intel.com,\n\tliang.j.ma@intel.com, stefanha@redhat.com,\n\tJani.Kokkonen@huawei.com, brian.a.keating@intel.com,\n\twangxinxin.wang@huawei.com, cohuck@redhat.com, mike.caraman@nxp.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1775985,"web_url":"http://patchwork.ozlabs.org/comment/1775985/","msgid":"<59CB03FC.9020002@huawei.com>","list_archive_url":null,"date":"2017-09-27T01:50:52","subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","submitter":{"id":69776,"url":"http://patchwork.ozlabs.org/api/people/69776/","name":"Longpeng (Mike, Cloud Infrastructure Service Product Dept.)","email":"longpeng2@huawei.com"},"content":"Hi Halil,\n\nOn 2017/9/15 23:59, Halil Pasic wrote:\n\n> \n> \n> On 09/11/2017 03:12 AM, Longpeng(Mike) wrote:\n>> From: Gonglei \n>>\n>> The virtio crypto device is a virtual crypto device (ie. hardware\n>> crypto accelerator card). Currently, the virtio crypto device provides\n>> the following crypto services: CIPHER, MAC, HASH, and AEAD.\n>>\n>> In this patch, CIPHER, MAC, HASH, AEAD services are introduced.\n>>\n>> VIRTIO-153\n>>\n>> Signed-off-by: Gonglei \n>> Signed-off-by: Longpeng(Mike) \n>> ---\n> [..]\n> \n> \n>> +\\subsubsection{Control Virtqueue}\\label{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue}\n>> +\n>> +The driver uses the control virtqueue to send control commands to the\n>> +device, such as session operations (See \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}).\n>> +\n>> +The header for controlq is of the following form:\n>> +\\begin{lstlisting}\n>> +#define VIRTIO_CRYPTO_OPCODE(service, op) (((service) << 8) | (op))\n>> +\n>> +struct virtio_crypto_ctrl_header {\n>> +#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \\\n>> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x02)\n>> +#define VIRTIO_CRYPTO_CIPHER_DESTROY_SESSION \\\n>> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x03)\n>> +#define VIRTIO_CRYPTO_HASH_CREATE_SESSION \\\n>> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x02)\n>> +#define VIRTIO_CRYPTO_HASH_DESTROY_SESSION \\\n>> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x03)\n>> +#define VIRTIO_CRYPTO_MAC_CREATE_SESSION \\\n>> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x02)\n>> +#define VIRTIO_CRYPTO_MAC_DESTROY_SESSION \\\n>> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x03)\n>> +#define VIRTIO_CRYPTO_AEAD_CREATE_SESSION \\\n>> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x02)\n>> +#define VIRTIO_CRYPTO_AEAD_DESTROY_SESSION \\\n>> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x03)\n>> + le32 opcode;\n>> + /* algo should be service-specific algorithms */\n>> + le32 algo;\n>> + le32 flag;\n>> + /* data virtqueue id */\n>> + le32 queue_id;\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +The format of the controlq request depends on the VIRTIO_CRYPTO_F_MUX_MODE feature bit:\n>> +\n>> +\\begin{itemize*}\n>> +\\item If the VIRTIO_CRYPTO_F_MUX_MODE feature bit is NOT negotiated the controlq request is\n>> + a fixed-size structure of form:\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_op_ctrl_req {\n>> + struct virtio_crypto_ctrl_header header;\n>> +\n>> + union {\n>> + struct virtio_crypto_sym_create_session_req sym_create_session;\n>> + struct virtio_crypto_hash_create_session_req hash_create_session;\n>> + struct virtio_crypto_mac_create_session_req mac_create_session;\n>> + struct virtio_crypto_aead_create_session_req aead_create_session;\n>> + struct virtio_crypto_destroy_session_req destroy_session;\n>> + } u;\n>> +};\n>> +\\end{lstlisting}\n>> +The header is the general header, and the union is of the algorithm-specific type or the\n>> +virtio_crypto_destroy_session_req structure, which is set by the driver. All the properties\n>> +in the union are shown as follows.\n>> +\n>> +\\item If the VIRTIO_CRYPTO_F_MUX_MODE feature bit is negotiated the controlq request is composed\n>> + of two parts, the additional paramenters are preceded by the general header.\n>> +\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_op_ctrl_req_mux {\n>> + struct virtio_crypto_ctrl_header header;\n>> +\n>> + /* additional paramenter */\n>> + u8 additional_para[addl_para_len];\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +The additional paramenters are stored in a virtio_crypto_destroy_session_req structure or\n>> +in a algorithm-specific structure:\n>> +\\begin{itemize*}\n>> +\\item struct virtio_crypto_sym_create_session_req\n>> +\\item struct virtio_crypto_hash_create_session_req\n>> +\\item struct virtio_crypto_mac_create_session_req\n>> +\\item struct virtio_crypto_aead_create_session_req\n>> +\\end{itemize*}\n>> +All of the structures above are shown as follows.\n>> +\\end{itemize*}\n>> +\n>> +\\paragraph{Session operation}\\label{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}\n>> +\n>> +The session is a\n>> +handle which describes the cryptographic parameters to be applied to\n>> +a number of buffers.\n>> +\n>> +The following structure stores the result of session creation set by the device:\n>> +\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_session_input {\n>> + /* Device-writable part */\n>> + le64 session_id;\n>> + le32 status;\n>> + le32 padding;\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +A request to destroy a session includes the following information:\n>> +\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_destroy_session_req {\n>> + /* Device-readable part */\n>> + le64 session_id;\n>> + /* Device-writable part */\n>> + le32 status;\n>> + le32 padding;\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +\\subparagraph{Session operation: HASH session}\\label{sec:Device Types / Crypto Device / Device\n>> +Operation / Control Virtqueue / Session operation / Session operation: HASH session}\n>> +\n>> +HASH session requests are as follows:\n>> +\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_hash_session_para {\n>> + /* See VIRTIO_CRYPTO_HASH_* above */\n>> + le32 algo;\n>> + /* hash result length */\n>> + le32 hash_result_len;\n>> +};\n>> +struct virtio_crypto_hash_create_session_req {\n>> + /* Device-readable part */\n>> + struct virtio_crypto_hash_session_para para;\n>> + /* Device-writable part */\n>> + struct virtio_crypto_session_input input;\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +The information required by HASH session creation is stored in the virtio_crypto_hash_create_session_req\n>> +structure, including the hash parameters stored in \\field{para}. \\field{input} stores the result of this operation.\n>> +\n>> +\\subparagraph{Session operation: MAC session}\\label{sec:Device Types / Crypto Device / Device\n>> +Operation / Control Virtqueue / Session operation / Session operation: MAC session}\n>> +\n>> +MAC session requests are as follows:\n>> +\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_mac_session_para {\n>> + /* See VIRTIO_CRYPTO_MAC_* above */\n>> + le32 algo;\n>> + /* hash result length */\n>> + le32 hash_result_len;\n>> + /* length of authenticated key */\n>> + le32 auth_key_len;\n>> + le32 padding;\n>> +};\n>> +\n>> +struct virtio_crypto_mac_create_session_req {\n>> + /* Device-readable part */\n>> + struct virtio_crypto_mac_session_para para;\n>> + /* The authenticated key */\n>> + u8 auth_key[auth_key_len];\n>> +\n>> + /* Device-writable part */\n>> + struct virtio_crypto_session_input input;\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +The information required by MAC session creation is stored in the virtio_crypto_mac_create_session_req\n>> +structure, including the mac parameters stored in \\field{para} and the authenticated key in \\field{auth_key}.\n>> +\\field{input} stores the result of this operation.\n>> +\n>> +\\subparagraph{Session operation: Symmetric algorithms session}\\label{sec:Device Types / Crypto Device / Device\n>> +Operation / Control Virtqueue / Session operation / Session operation: Symmetric algorithms session}\n>> +\n>> +The request of symmetric session includes two parts, CIPHER algorithms and chain\n>> +algorithms (chaining CIPHER and HASH/MAC).\n>> +\n>> +CIPHER session requests are as follows:\n>> +\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_cipher_session_para {\n>> + /* See VIRTIO_CRYPTO_CIPHER* above */\n>> + le32 algo;\n>> + /* length of key */\n>> + le32 keylen;\n>> +#define VIRTIO_CRYPTO_OP_ENCRYPT 1\n>> +#define VIRTIO_CRYPTO_OP_DECRYPT 2\n>> + /* encryption or decryption */\n>> + le32 op;\n>> + le32 padding;\n>> +};\n>> +\n>> +struct virtio_crypto_cipher_session_req {\n>> + /* Device-readable part */\n>> + struct virtio_crypto_cipher_session_para para;\n>> + /* The cipher key */\n>> + u8 cipher_key[keylen];\n>> +\n>> + /* Device-writable part */\n>> + struct virtio_crypto_session_input input;that\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +Algorithm chaining requests are as follows:\n>> +\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_alg_chain_session_para {\n>> +#define VIRTIO_CRYPTO_SYM_ALG_CHAIN_ORDER_HASH_THEN_CIPHER 1\n>> +#define VIRTIO_CRYPTO_SYM_ALG_CHAIN_ORDER_CIPHER_THEN_HASH 2\n>> + le32 alg_chain_order;\n>> +/* Plain hash */\n>> +#define VIRTIO_CRYPTO_SYM_HASH_MODE_PLAIN 1\n>> +/* Authenticated hash (mac) */\n>> +#define VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH 2\n>> +/* Nested hash */\n>> +#define VIRTIO_CRYPTO_SYM_HASH_MODE_NESTED 3\n>> + le32 hash_mode;\n>> + struct virtio_crypto_cipher_session_para cipher_param;\n>> + union {\n>> + struct virtio_crypto_hash_session_para hash_param;\n>> + struct virtio_crypto_mac_session_para mac_param;\n>> + } u;\n>> + /* length of the additional authenticated data (AAD) in bytes */\n>> + le32 aad_len;\n>> + le32 padding;\n>> +};\n>> +\n>> +struct virtio_crypto_alg_chain_session_req {\n>> + /* Device-readable part */\n>> + struct virtio_crypto_alg_chain_session_para para;\n>> + /* The cipher key */\n>> + u8 cipher_key[keylen];\n>> + /* The authenticated key */\n>> + u8 auth_key[auth_key_len];\n>> +\n>> + /* Device-writable part */\n>> + struct virtio_crypto_session_input input;\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +Symmetric algorithm requests are as follows:\n>> +\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_sym_create_session_req {\n>> + union {\n>> + struct virtio_crypto_cipher_session_req cipher;\n>> + struct virtio_crypto_alg_chain_session_req chain;\n>> + } u;\n>> +\n>> + /* Device-readable part */\n>> +\n>> +/* No operation */\n>> +#define VIRTIO_CRYPTO_SYM_OP_NONE 0\n>> +/* Cipher only operation on the data */\n>> +#define VIRTIO_CRYPTO_SYM_OP_CIPHER 1\n>> +/* Chain any cipher with any hash or mac operation. The order\n>> + depends on the value of alg_chain_order param */\n>> +#define VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING 2\n>> + le32 op_type;\n>> + le32 padding;\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +The information required by symmetric algorithms session creation is stored in the\n>> +virtio_crypto_sym_create_session_req structure, including the symmetric operation\n>> +type in \\field{op_type} and the cipher parameters stored in \\field{cipher} or the\n>> +algorithm chaining paramenters in \\field{chain}.\n>> +\n>> +The driver can set the \\field{op_type} field in struct virtio_crypto_sym_create_session_req\n>> +as follows: VIRTIO_CRYPTO_SYM_OP_NONE: no operation; VIRTIO_CRYPTO_SYM_OP_CIPHER: Cipher only\n>> +operation on the data; VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING: Chain any cipher with any hash\n>> +or mac operation.\n>> +\n>> +\\subparagraph{Session operation: AEAD session}\\label{sec:Device Types / Crypto Device / Device\n>> +Operation / Control Virtqueue / Session operation / Session operation: AEAD session}\n>> +\n>> +AEAD session requests are as follows:\n>> +\n>> +\\begin{lstlisting}\n>> +struct virtio_crypto_aead_session_para {\n>> + /* See VIRTIO_CRYPTO_AEAD_* above */\n>> + le32 algo;\n>> + /* length of key */\n>> + le32 key_len;\n>> + /* Authentication tag length */\n>> + le32 tag_len;\n>> + /* The length of the additional authenticated data (AAD) in bytes */\n>> + le32 aad_len;\n>> + /* encryption or decryption, See above VIRTIO_CRYPTO_OP_* */\n>> + le32 op;\n>> + le32 padding;\n>> +};\n>> +\n>> +struct virtio_crypto_aead_create_session_req {\n>> + /* Device-readable part */\n>> + struct virtio_crypto_aead_session_para para;\n>> + u8 key[key_len];\n>> +\n>> + /* Device-writeable part */\n>> + struct virtio_crypto_session_input input;\n>> +};\n>> +\\end{lstlisting}\n>> +\n>> +The information required by AEAD session creation is stored in the virtio_crypto_aead_create_session_req\n>> +structure, including the aead parameters stored in \\field{para} and the cipher key in \\field{key}.\n>> +\\field{input} stores the result of this operation.\n>> +\n>> +\\drivernormative{\\subparagraph}{Session operation: create session}{Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation / Session operation: create session}\n>> +\n>> +\\begin{itemize*}\n>> +\\item The driver MUST set the control general header and the corresponding algorithm-specific structure.\n>> + See \\ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue}.\n>> +\\item The driver MUST set the \\field{opcode} field based on service type: CIPHER, HASH, MAC, or AEAD.\n>> +\\item The driver MUST set the \\field{queue_id} field to show used dataq.\n> \n> I've failed to figure out the semantic behind queue_id. This could mean,\n> that sessions and session_id's are queue scoped. But then we should be\n> (IMHO) more explicit on this -- my guess is that session_id's aren't\n> dataqueue scoped.\n> \n>> +\\end{itemize*}\n>> +\n>> +\\devicenormative{\\subparagraph}{Session operation: create session}{Device Types / Crypto Device / Device\n>> +Operation / Control Virtqueue / Session operation / Session operation: create session}\n>> +\n>> +\\begin{itemize*}\n>> +\\item The device MUST use the corresponding algorithm-specific structure according to the\n>> + \\field{opcode} in the control general header.\n>> +\\item The device MUST set the \\field{status} field to one of the following values of enum\n>> + VIRTIO_CRYPTO_STATUS after finish a session creation:\n>> +\\begin{itemize*}\n>> +\\item VIRTIO_CRYPTO_OK if a session is created successfully.\n>> +\\item VIRTIO_CRYPTO_NOTSUPP if the requested algorithm or operation is unsupported.\n>> +\\item VIRTIO_CRYPTO_NOSPC if no free session ID (only when the VIRTIO_CRYPTO_F_MUX_MODE\n>> + feature bit is negotiated).\n>> +\\item VIRTIO_CRYPTO_ERR if failure not mentioned above occurs.\n> \n> I guess an invalid queue_id would be among these.\n> \n>> +\\end{itemize*}\n>> +\\item The device MUST set the \\field{session_id} field to a unique session identifieronly\n> s/identifieronly/identifier only\n>> + if the status is set to VIRTIO_CRYPTO_OK.\n>> +\\end{itemize*}\n>> +\n>> +\\drivernormative{\\subparagraph}{Session operation: destroy session}{Device Types / Crypto Device / Device\n>> +Operation / Control Virtqueue / Session operation / Session operation: destroy session}\n>> +\n>> +\\begin{itemize*}\n>> +\\item The driver MUST set the \\field{opcode} field based on service type: CIPHER, HASH, MAC, or AEAD.\n>> +\\item The driver MUST set the \\field{session_id} to a valid value assigned by the device\n>> + when the session was created.\n> \n> Destroy does not need to specify queue_id. That means session_id's aren't\n> queue scoped from namespace perspective. The question remains what is\n> queue_id good for, and whether a session type op request should be\n> rejected if the the session id originates from a session creation\n> request specifying a different dataqueue (not the dataqueue containing\n> the given request)? \n> \n\nGonglei and you have reached consensus, so we will make it reserved and must be\nzero in the next version.\n\n>> +\\end{itemize*}\n>> +\n>> +\\devicenormative{\\subparagraph}{Session operation: destroy session}{Device Types / Crypto Device / Device\n>> +Operation / Control Virtqueue / Session operation / Session operation: destroy session}\n>> +\n>> +\\begin{itemize*}\n>> +\\item The device MUST set the \\field{status} field to one of the following values of enum VIRTIO_CRYPTO_STATUS.\n>> +\\begin{itemize*}\n>> +\\item VIRTIO_CRYPTO_OK if a session is created successfully.\n>> +\\item VIRTIO_CRYPTO_ERR if any failure occurs.\n>> +\\end{itemize*}\n>> +\\end{itemize*}\n>> +\n>> +\\subsubsection{Data Virtqueue}\\label{sec:Device Types / Crypto Device / Device Operation / Data Virtqueue}\n>>\n> \n> [..]\n> \n> I've run through the rest. It some stuff seems very repetitive. I wonder if\n> we can do better.\n> \n\n> I also dislike this 5.7.7.5.3 Steps of Operation part. I also don't\n> understand why is symmetric special in this respect (HASH, MAC and\n> AEAD don't have a 'Steps of Operation' section.\n> \n\nI have a offline discussion with Gonglei about it, we prefer to drop the\n5.7.7.5.3 Steps of Operation part.\n\n> I would like to try some things out with the reference implementation.\n> Depending on how that goes I may or may not end up providing a detailed\n> review for the rest before discussing what I've already addressed.\n> \n> Regards,\n> Halil\n> \n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y217P3vjkz9t3h\n\tfor ;\n\tWed, 27 Sep 2017 11:53:19 +1000 (AEST)","from localhost ([::1]:51769 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dx1XH-0001cc-89\n\tfor incoming@patchwork.ozlabs.org; Tue, 26 Sep 2017 21:53:15 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:48913)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dx1Wp-0001cJ-GT\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 21:52:49 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dx1Wm-00065t-BB\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 21:52:47 -0400","from szxga05-in.huawei.com ([45.249.212.191]:2267)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71)\n\t(envelope-from ) id 1dx1Wl-00062r-6u\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 21:52:44 -0400","from 172.30.72.59 (EHLO DGGEMS401-HUB.china.huawei.com)\n\t([172.30.72.59])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DIC27201; Wed, 27 Sep 2017 09:52:09 +0800 (CST)","from [127.0.0.1] (10.177.246.209) by DGGEMS401-HUB.china.huawei.com\n\t(10.3.19.201) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 27 Sep 2017 09:51:55 +0800"],"Message-ID":"<59CB03FC.9020002@huawei.com>","Date":"Wed, 27 Sep 2017 09:50:52 +0800","From":"\"Longpeng (Mike)\" ","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64;\n\trv:11.0) Gecko/20120327 Thunderbird/11.0.1","MIME-Version":"1.0","To":"Halil Pasic ","References":"<1505092362-10544-1-git-send-email-longpeng2@huawei.com>\n\t<1505092362-10544-2-git-send-email-longpeng2@huawei.com>\n\t<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>","In-Reply-To":"<67d5549e-84de-ee85-00a7-37edc52234c4@linux.vnet.ibm.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[10.177.246.209]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A090201.59CB044D.0018, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"93270fd1f333f12339b5f9a89d1c90dd","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic]\n\t[fuzzy]","X-Received-From":"45.249.212.191","Subject":"Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio\n\tcrypto device specification","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"weidong.huang@huawei.com, mst@redhat.com, jasowang@redhat.com,\n\tqemu-devel@nongnu.org, john.griffin@intel.com,\n\tVarun.Sethi@freescale.com, denglingli@chinamobile.com,\n\tarei.gonglei@hotmail.com, virtio-dev@lists.oasis-open.org,\n\tagraf@suse.de, arei.gonglei@huawei.com, vincent.jardin@6wind.com,\n\tOla.Liljedahl@arm.com, luonengjun@huawei.com, xin.zeng@intel.com,\n\tliang.j.ma@intel.com, stefanha@redhat.com,\n\tJani.Kokkonen@huawei.com, brian.a.keating@intel.com,\n\twangxinxin.wang@huawei.com, cohuck@redhat.com, mike.caraman@nxp.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]