Hi,
I attach a diff for next version in order to review more convenient, with
- Drop the all gap stuff;
- Drop all structures undefined in virtio_crypto.h
- re-describe per request for per crypto service avoid confusion
Pls review, thanks!
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index 448296e..ab17e7b 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -69,13 +69,13 @@ The following services are defined:
\begin{lstlisting}
/* CIPHER service */
-#define VIRTIO_CRYPTO_SERVICE_CIPHER (0)
+#define VIRTIO_CRYPTO_SERVICE_CIPHER 0
/* HASH service */
-#define VIRTIO_CRYPTO_SERVICE_HASH (1)
+#define VIRTIO_CRYPTO_SERVICE_HASH 1
/* MAC (Message Authentication Codes) service */
-#define VIRTIO_CRYPTO_SERVICE_MAC (2)
+#define VIRTIO_CRYPTO_SERVICE_MAC 2
/* AEAD (Authenticated Encryption with Associated Data) service */
-#define VIRTIO_CRYPTO_SERVICE_AEAD (3)
+#define VIRTIO_CRYPTO_SERVICE_AEAD 3
\end{lstlisting}
The last driver-read-only fields specify detailed algorithms masks
@@ -210,7 +210,7 @@ data that should be utilized in operations, and input data
is equal to
The general header for controlq is as follows:
\begin{lstlisting}
-#define VIRTIO_CRYPTO_OPCODE(service, op) ((service << 8) | (op))
+#define VIRTIO_CRYPTO_OPCODE(service, op) (((service) << 8) | (op))
struct virtio_crypto_ctrl_header {
#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \
@@ -380,20 +380,18 @@ struct virtio_crypto_mac_session_para {
le32 auth_key_len;
le32 padding;
};
-struct virtio_crypto_mac_session_output {
- le64 auth_key_addr; /* guest key physical address */
-};
struct virtio_crypto_mac_create_session_req {
/* Device-readable part */
struct virtio_crypto_mac_session_para para;
- struct virtio_crypto_mac_session_output out;
+ /* The authenticated key buffer */
+ /* output data here */
+
/* Device-writable part */
struct virtio_crypto_session_input input;
};
\end{lstlisting}
-The output data are
\subparagraph{Session operation: Symmetric algorithms
session}\label{sec:Device Types / Crypto Device / Device
Operation / Control Virtqueue / Session operation / Session operation:
Symmetric algorithms session}
@@ -413,13 +411,13 @@ struct virtio_crypto_cipher_session_para {
le32 padding;
};
-struct virtio_crypto_cipher_session_output {
- le64 key_addr; /* guest key physical address */
-};
-
struct virtio_crypto_cipher_session_req {
+ /* Device-readable part */
struct virtio_crypto_cipher_session_para para;
- struct virtio_crypto_cipher_session_output out;
+ /* The cipher key buffer */
+ /* Output data here */
+
+ /* Device-writable part */
struct virtio_crypto_session_input input;
};
\end{lstlisting}
@@ -448,18 +446,20 @@ struct virtio_crypto_alg_chain_session_para {
le32 padding;
};
-struct virtio_crypto_alg_chain_session_output {
- struct virtio_crypto_cipher_session_output cipher;
- struct virtio_crypto_mac_session_output mac;
-};
-
struct virtio_crypto_alg_chain_session_req {
+ /* Device-readable part */
struct virtio_crypto_alg_chain_session_para para;
- struct virtio_crypto_alg_chain_session_output out;
+ /* The cipher key buffer */
+ /* The authenticated key buffer */
+ /* Output data here */
+
+ /* Device-writable part */
struct virtio_crypto_session_input input;
};
\end{lstlisting}
+The output data includs both cipher key buffer and authenticated key buffer.
+
The packet for symmetric algorithm is as follows:
\begin{lstlisting}
@@ -503,13 +503,13 @@ struct virtio_crypto_aead_session_para {
le32 padding;
};
-struct virtio_crypto_aead_session_output {
- le64 key_addr; /* guest key physical address */
-};
-
struct virtio_crypto_aead_create_session_req {
+ /* Device-readable part */
struct virtio_crypto_aead_session_para para;
- struct virtio_crypto_aead_session_output out;
+ /* The cipher key buffer */
+ /* Output data here */
+
+ /* Device-writeable part */
struct virtio_crypto_session_input input;
};
\end{lstlisting}
@@ -568,19 +568,13 @@ struct virtio_crypto_op_data_req {
The header is the general header and the union is of the algorithm-specific
type,
which is set by the driver. All properties in the union are shown as follows.
-There is a unified idata structure for all symmetric algorithms, including
CIPHER, HASH, MAC, and AEAD.
+There is a unified idata structure for all service, including CIPHER, HASH,
MAC, and AEAD.
The structure is defined as follows:
\begin{lstlisting}
-struct virtio_crypto_sym_input {
- /* Destination data guest address, it's useless for plain HASH and MAC */
- le64 dst_data_addr;
- /* Digest result guest address, it's useless for plain cipher algos */
- le64 digest_result_addr;
-
- le32 status;
- le32 padding;
+struct virtio_crypto_inhdr {
+ u8 status;
};
\end{lstlisting}
@@ -595,39 +589,29 @@ struct virtio_crypto_hash_para {
le32 hash_result_len;
};
-struct virtio_crypto_hash_input {
- struct virtio_crypto_sym_input input;
-};
-
-struct virtio_crypto_hash_output {
- /* source data guest address */
- le64 src_data_addr;
-};
-
struct virtio_crypto_hash_data_req {
/* Device-readable part */
struct virtio_crypto_hash_para para;
- struct virtio_crypto_hash_output odata;
+ /* Source buffer */
+ /* Output data here */
+
/* Device-writable part */
- struct virtio_crypto_hash_input idata;
+ /* Digest result buffer */
+ /* Input data here */
+ struct virtio_crypto_inhdr inhdr;
};
\end{lstlisting}
Each data request uses virtio_crypto_hash_data_req structure to store
information
-used to run the HASH operations. The request only occupies one entry
-in the Vring Descriptor Table in the virtio crypto device's dataq, which
improves
-the throughput of data transmitted for the HASH service, so that the virtio
crypto
-device can be better accelerated.
+used to run the HASH operations.
-The information includes the source data guest physical address stored by
\field{odata}.\field{src_data_addr},
-length of source data stored by \field{para}.\field{src_data_len}, and the
digest result guest physical address
-stored by \field{digest_result_addr} used to save the results of the HASH
operations.
-The address and length can determine exclusive content in the guest memory.
+The information includes the hash paramenters stored by \field{para}, output
data and input data.
+The output data here includs the source buffer and the input data includes the
digest result buffer used to save the results of the HASH operations.
+\field{inhdr} store the executing status of HASH operations.
\begin{note}
-The guest memory is always guaranteed to be allocated and physically-contiguous
-pointed by \field{digest_result_addr} in struct virtio_crypto_hash_input and
-\field{src_data_addr} in struct virtio_crypto_hash_output.
+The request should by preference occupies one entry in the Vring Descriptor
Table in the virtio crypto device's dataq, which improves
+the throughput of data transmitted for the HASH service, so that the virtio
crypto device can be better accelerated.
\end{note}
\drivernormative{\paragraph}{HASH Service Operation}{Device Types / Crypto
Device / Device Operation / HASH Service Operation}
@@ -641,8 +625,8 @@ pointed by \field{digest_result_addr} in struct
virtio_crypto_hash_input and
\devicenormative{\paragraph}{HASH Service Operation}{Device Types / Crypto
Device / Device Operation / HASH Service Operation}
\begin{itemize*}
-\item The device MUST copy the results of HASH operations to the guest memory
recorded by \field{digest_result_addr} field in struct virtio_crypto_hash_input.
-\item The device MUST set \field{status} in strut virtio_crypto_hash_input:
VIRTIO_CRYPTO_OK: success; VIRTIO_CRYPTO_ERR: creation failed or device error;
VIRTIO_CRYPTO_NOTSUPP: not support.
+\item The device MUST copy the results of HASH operations to the guest memory
recorded by digest result buffer if HASH operations success.
+\item The device MUST set \field{status} in strut virtio_crypto_inhdr:
VIRTIO_CRYPTO_OK: success; VIRTIO_CRYPTO_ERR: creation failed or device error;
VIRTIO_CRYPTO_NOTSUPP: not support; VIRTIO_CRYPTO_INVSESS: invalid session ID
when the crypto operation is implemented.
\end{itemize*}
\subsubsection{MAC Service Operation}\label{sec:Device Types / Crypto Device /
Device Operation / MAC Service Operation}
@@ -652,39 +636,29 @@ struct virtio_crypto_mac_para {
struct virtio_crypto_hash_para hash;
};
-struct virtio_crypto_mac_input {
- struct virtio_crypto_sym_input input;
-};
-
-struct virtio_crypto_mac_output {
- struct virtio_crypto_hash_output hash_output;
-};
-
struct virtio_crypto_mac_data_req {
/* Device-readable part */
struct virtio_crypto_mac_para para;
- struct virtio_crypto_mac_output odata;
+ /* Source buffer */
+ /* Output data here */
+
/* Device-writable part */
- struct virtio_crypto_mac_input idata;
+ /* Digest result buffer */
+ /* Input data here */
+ struct virtio_crypto_inhdr inhdr;
};
\end{lstlisting}
Each data request uses virtio_crypto_mac_data_req structure to store
information
-used to run the MAC operations. The request only occupies one entry
-in the Vring Descriptor Table in the virtio crypto device's dataq, which
improves
-the throughput of data transmitted for the MAC service, so that the virtio
crypto
-device can get the better result of acceleration.
-
-The information includes the source data guest physical address stored by
\field{hash_output}.\field{src_data}.\field{addr},
-the length of source data stored by
\field{hash_output}.\field{src_data}.\field{len}, and the digest result guest
physical address
-stored by \field{digest_result_addr} used to save the results of the MAC
operations.
+used to run the MAC operations.
-The address and length can determine exclusive content in the guest memory.
+The information includes the hash paramenters stored by \field{para}, output
data and input data.
+The output data here includs the source buffer and the input data includes the
digest result buffer used to save the results of the MAC operations.
+\field{inhdr} store the executing status of MAC operations.
\begin{note}
-The guest memory is always guaranteed to be allocated and physically-contiguous
-pointed by \field{digest_result_addr} in struct virtio_crypto_sym_input and
-\field{hash_output}.\field{src_data_addr} in struct virtio_crypto_mac_output.
+The request should by preference occupies one entry in the Vring Descriptor
Table in the virtio crypto device's dataq, which improves
+the throughput of data transmitted for the MAC service, so that the virtio
crypto device can be better accelerated.
\end{note}
\drivernormative{\paragraph}{MAC Service Operation}{Device Types / Crypto
Device / Device Operation / MAC Service Operation}
@@ -698,8 +672,8 @@ pointed by \field{digest_result_addr} in struct
virtio_crypto_sym_input and
\devicenormative{\paragraph}{MAC Service Operation}{Device Types / Crypto
Device / Device Operation / MAC Service Operation}
\begin{itemize*}
-\item The device MUST copy the results of MAC operations to the guest memory
recorded by \field{digest_result_addr} field in struct virtio_crypto_mac_input.
-\item The device MUST set \field{status} in strut virtio_crypto_mac_input:
VIRTIO_CRYPTO_OK: success; VIRTIO_CRYPTO_ERR: creation failed or device error;
VIRTIO_CRYPTO_NOTSUPP: not support.
+\item The device MUST copy the results of MAC operations to the guest memory
recorded by digest result buffer if HASH operations success.
+\item The device MUST set \field{status} in strut virtio_crypto_inhdr:
VIRTIO_CRYPTO_OK: success; VIRTIO_CRYPTO_ERR: creation failed or device error;
VIRTIO_CRYPTO_NOTSUPP: not support; VIRTIO_CRYPTO_INVSESS: invalid session ID
when the crypto operation is implemented.
\end{itemize*}
\subsubsection{Symmetric algorithms Operation}\label{sec:Device Types / Crypto
Device / Device Operation / Symmetric algorithms Operation}
@@ -709,12 +683,12 @@ The packet of plain CIPHER service is as follows:
\begin{lstlisting}
struct virtio_crypto_cipher_para {
/*
- * Byte Length of valid IV data pointed to by the below iv_addr.
+ * Byte Length of valid IV/Counter data pointed to by the below iv buffer.
*
- * - For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
+ * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
* SNOW3G in UEA2 mode, this is the length of the IV (which
* must be the same as the block length of the cipher).
- * - For block ciphers in CTR mode, this is the length of the counter
+ * For block ciphers in CTR mode, this is the length of the counter
* (which must be the same as the block length of the cipher).
*/
le32 iv_len;
@@ -725,34 +699,28 @@ struct virtio_crypto_cipher_para {
le32 padding;
};
-struct virtio_crypto_cipher_input {
- struct virtio_crypto_sym_input input;
-};
-
-struct virtio_crypto_cipher_output {
- /*
- * Initialization Vector or Counter Guest Address.
+struct virtio_crypto_cipher_data_req {
+ /* Device-readable part */
+ struct virtio_crypto_cipher_para para;
+ /*
+ * Initialization Vector or Counter buffer.
*
- * - For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
+ * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
* SNOW3G in UEA2 mode, this is the Initialization Vector (IV)
* value.
- * - For block ciphers in CTR mode, this is the counter.
- * - For AES-XTS, this is the 128bit tweak, i, from IEEE Std 1619-2007.
+ * For block ciphers in CTR mode, this is the counter.
+ * For AES-XTS, this is the 128bit tweak, i, from IEEE Std 1619-2007.
*
* The IV/Counter will be updated after every partial cryptographic
* operation.
*/
- le64 iv_addr;
- /* source data guest address */
- le64 src_data_addr;
-};
+ /* Source buffer */
+ /* Output data here */
-struct virtio_crypto_cipher_data_req {
- /* Device-readable part */
- struct virtio_crypto_cipher_para para;
- struct virtio_crypto_cipher_output odata;
/* Device-writable part */
- struct virtio_crypto_cipher_input idata;
+ /* Destination data buffer */
+ /* Input data here */
+ struct virtio_crypto_inhdr inhdr;
};
\end{lstlisting}
@@ -780,23 +748,19 @@ struct virtio_crypto_alg_chain_data_para {
__virtio32 reserved;
};
-struct virtio_crypto_alg_chain_data_output {
- /* Device-readable part */
- struct virtio_crypto_cipher_output cipher;
- /* Additional auth data guest address */
- le64 aad_data_addr;
-};
-
-struct virtio_crypto_alg_chain_data_input {
- struct virtio_crypto_sym_input input;
-};
-
struct virtio_crypto_alg_chain_data_req {
/* Device-readable part */
struct virtio_crypto_alg_chain_data_para para;
- struct virtio_crypto_alg_chain_data_output odata;
+ /* Initialization Vector or Counter buffer */
+ /* Source buffer */
+ /* Additional authenticated buffer if exists */
+ /* Output data here */
+
/* Device-writable part */
- struct virtio_crypto_alg_chain_data_input idata;
+ /* Destination data buffer */
+ /* Digest result buffer */
+ /* Input data here */
+ struct virtio_crypto_inhdr inhdr;
};
\end{lstlisting}
@@ -817,29 +781,22 @@ struct virtio_crypto_sym_data_req {
};
\end{lstlisting}
-Each data request uses the virtio_crypto_cipher_data_req structure to store
information
-used to run the CIPHER operations. The request only occupies one entry
-in the Vring Descriptor Table in the virtio crypto device's dataq, which
improves
-the throughput of data transmitted for the CIPHER service, so that the virtio
crypto
-device can get the better result of acceleration.
+Each data request uses virtio_crypto_sym_data_req structure to store
information
+used to run the CIPHER operations.
+The information includes the hash paramenters stored by \field{para}, output
data and input data.
In the first virtio_crypto_cipher_para structure, \field{iv_len} specifies the
length of the initialization vector or counter,
\field{src_data_len} specifies the length of the source data, and
\field{dst_data_len} specifies the
-length of the destination data.
+length of the destination data.
+For plain CIPHER operations, the output data here includs the IV/Counter
buffer and source buffer, and the input data includes the destination buffer
used to save the results of the CIPHER operations.
-In the following virtio_crypto_cipher_input structure, \field{dst_data_addr}
specifies the destination
-data guest physical address used to store the results of the CIPHER
operations, and \field{status} specifies
-the CIPHER operation status.
-
-In the virtio_crypto_cipher_output structure, \field{iv_addr} specifies the
guest physical address of initialization vector,
-\field{src_data_addr} specifies the source data guest physical address.
-
-The addresses and length can determine exclusive content in the guest memory.
+For algorithms chain, the output data here includs the IV/Counter buffer,
source buffer and additional authenticated data buffer if exists.
+The input data includes both destionation buffer and digest result buffer used
to store the results of the HASH/MAC operations.
+\field{inhdr} store the executing status of crypto operations.
\begin{note}
-The guest memory is always guaranteed to be allocated and physically-contiguous
-pointed by \field{dst_data_addr} in struct virtio_crypto_cipher_input,
-\field{iv_addr} and \field{src_data_addr} in struct
virtio_crypto_cipher_output.
+The request should by preference occupies one entry in the Vring Descriptor
Table in the virtio crypto device's dataq, which improves
+the throughput of data transmitted for the crypto service, so that the virtio
crypto device can be better accelerated.
\end{note}
\drivernormative{\paragraph}{Symmetric algorithms Operation}{Device Types /
Crypto Device / Device Operation / Symmetric algorithms Operation}
@@ -860,10 +817,10 @@ pointed by \field{dst_data_addr} in struct
virtio_crypto_cipher_input,
\item The device SHOULD only parse fields of struct
virtio_crypto_cipher_data_req in struct virtio_crypto_sym_data_req if the
created session is VIRTIO_CRYPTO_SYM_OP_CIPHER type.
\item The device MUST parse fields of both struct
virtio_crypto_cipher_data_req and struct virtio_crypto_mac_data_req in struct
virtio_crypto_sym_data_req if the created
session is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING operation type and
in the VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH mode.
-\item The device MUST copy the result of cryptographic operation to the guest
memory recorded by \field{dst_data_addr} field in struct
virtio_crypto_cipher_input in plain CIPHER mode.
-\item The device MUST copy the result of HASH/MAC operation to the guest
memory recorded by \field{digest_result_addr} field in struct
virtio_crypto_alg_chain_data_input is of the
VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING type.
-\item The device MUST set the \field{status} field in strut
virtio_crypto_cipher_input or virtio_crypto_alg_chain_data_input structure:
-VIRTIO_CRYPTO_OK: success; VIRTIO_CRYPTO_ERR: creation failed or device error;
VIRTIO_CRYPTO_NOTSUPP: not supported.
+\item The device MUST copy the result of cryptographic operation to the guest
memory recorded by destination buffer in plain CIPHER mode.
+\item The device MUST check the \field{para}.\field{add_len} is bigger than 0
before parse the additional authenticated buffer in plain algorithms chain mode.
+\item The device MUST copy the result of HASH/MAC operation to the guest
memory recorded by digest result buffer is of the
VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING type.
+\item The device MUST set the \field{status} field in strut
virtio_crypto_inhdr: VIRTIO_CRYPTO_OK: success; VIRTIO_CRYPTO_ERR: creation
failed or device error; VIRTIO_CRYPTO_NOTSUPP: not supported;
VIRTIO_CRYPTO_INVSESS: invalid session ID when the crypto operation is
implemented.
\end{itemize*}
\paragraph{Steps of Operation}\label{sec:Device Types / Crypto Device / Device
Operation / Symmetric algorithms Operation / Steps of Operation}
@@ -894,17 +851,15 @@ VIRTIO_CRYPTO_OK: success; VIRTIO_CRYPTO_ERR: creation
failed or device error; V
\item The device invokes the cryptographic APIs of the backend crypto
accelerator;
\item The backend crypto accelerator executes the cryptographic operation
implicitly;
\item The device receives the cryptographic results from the backend crypto
accelerator (synchronous or asynchronous);
-\item The device sets the \field{status} in struct virtio_crypto_cipher_input;
+\item The device sets the \field{status} in struct virtio_crypto_inhdr;
\item The device updates and flushes the Used Ring to return the cryptographic
results to the driver;
\item The device notifies the driver (Or the driver actively polls the dataq's
Used Ring);
\item The driver saves the cryptographic result.
\end{enumerate}
\begin{note}
-\begin{itemize*}
-\item For better performance, the device should by preference use vhost scheme
(user space or kernel space)
- as the backend crypto accelerator in the real production environment.
-\end{itemize*}
+For better performance, the device should by preference use vhost scheme (user
space or kernel space)
+as the backend crypto accelerator in the real production environment.
\end{note}
\subsubsection{AEAD Service Operation}\label{sec:Device Types / Crypto Device
/ Device Operation / AEAD Service Operation}
@@ -912,11 +867,11 @@ VIRTIO_CRYPTO_OK: success; VIRTIO_CRYPTO_ERR: creation
failed or device error; V
\begin{lstlisting}
struct virtio_crypto_aead_para {
/*
- * Byte Length of valid IV data pointed to by the below iv_addr parameter.
+ * Byte Length of valid IV data.
*
- * - For GCM mode, this is either 12 (for 96-bit IVs) or 16, in which
- * case iv_addr points to J0.
- * - For CCM mode, this is the length of the nonce, which can be in the
+ * For GCM mode, this is either 12 (for 96-bit IVs) or 16, in which
+ * case iv points to J0.
+ * For CCM mode, this is the length of the nonce, which can be in the
* range 7 to 13 inclusive.
*/
le32 iv_len;
@@ -928,66 +883,51 @@ struct virtio_crypto_aead_para {
le32 dst_data_len;
};
-struct virtio_crypto_aead_input {
- struct virtio_crypto_sym_input input;
-};
-
-struct virtio_crypto_aead_output {
+struct virtio_crypto_aead_data_req {
+ /* Device-readable part */
+ struct virtio_crypto_aead_para para;
/*
- * Initialization Vector Guest Address.
+ * Initialization Vector buffer.
*
- * - For GCM mode, this is either the IV (if the length is 96 bits) or J0
+ * For GCM mode, this is either the IV (if the length is 96 bits) or J0
* (for other sizes), where J0 is as defined by NIST SP800-38D.
* Regardless of the IV length, a full 16 bytes needs to be allocated.
- * - For CCM mode, the first byte is reserved, and the nonce should be
- * written starting at &iv_addr[1] (to allow space for the implementation
+ * For CCM mode, the first byte is reserved, and the nonce should be
+ * written starting at &iv_buffer[1] (to allow space for the
implementation
* to write in the flags in the first byte). Note that a full 16 bytes
* should be allocated, even though the iv_len field will have
* a value less than this.
*
* The IV will be updated after every partial cryptographic operation.
*/
- le64 iv_addr;
- /* source data guest address */
- le64 src_data_addr;
- /* additional auth data guest address */
- le64 add_data_addr;
-};
+ /* Source buffer */
+ /* Additional authenticated buffer if exists */
+ /* Output data here */
-struct virtio_crypto_aead_data_req {
- /* Device-readable part */
- struct virtio_crypto_aead_para para;
- struct virtio_crypto_aead_output odata;
/* Device-writable part */
- struct virtio_crypto_aead_input idata;
+ /* Destination data buffer */
+ /* Digest result buffer */
+ /* Input data here */
+ struct virtio_crypto_inhdr inhdr;
};
\end{lstlisting}
Each data request uses virtio_crypto_aead_data_req structure to store
information
-used to implement the CIPHER operations. The request only occupies one entry
-in the Vring Descriptor Table in the virtio crypto device's dataq, which
improves
-the throughput of data transmitted for the AEAD service, so that the virtio
crypto
-device can be better accelerated.
+used to run the AEAD operations.
-In the first virtio_crypto_aead_para structure, \field{iv_len} specifies the
length of the initialization vector;
+The information includes the hash paramenters stored by \field{para}, output
data and input data.
+In the first virtio_crypto_aead_para structure, \field{iv_len} specifies the
length of the initialization vector.
\field{aad_len} specifies the length of additional authentication data,
\field{src_data_len} specifies the
length of the source data; \field{dst_data_len} specifies the length of the
destination data.
+The output data here includs the IV buffer and source buffer, and the input
data includes the destination buffer used to save the results of the CIPHER
operations.
-In the following virtio_crypto_aead_input structure, \field{dst_data_addr}
specifies destination
-data guest physical address used to store the results of the CIPHER
operations; \field{digest_result_addr} specifies
-the digest result guest physical address used to store the results of the
HASH/MAC operations; \field{status} specifies
-the status of AEAD operation.
-
-In the virtio_crypto_aead_output structure, \field{iv_addr} specifies the
guest physical address of initialization vector,
-\field{src_data_addr} specifies the source data guest physical address,
\field{add_data_addr} specifies the guest physical address
-of additional authentication data.
-
-The addresses and length can determine exclusive content in the guest memory.
+The output data here includs the IV/Counter buffer, source buffer and
additional authenticated data buffer if exists.
+The input data includes both destionation buffer used to save the results of
the AEAD operations.
+\field{inhdr} store the executing status of AEAD operations.
\begin{note}
-The guest memory MUST be guaranteed to be allocated and physically-contiguous
-pointed by \field{dst_data_addr} and \field{digest_result_addr} in struct
virtio_crypto_aead_input,
-\field{iv_addr}, \field{src_data_addr} and \field{add_data_addr} in struct
virtio_crypto_aead_output.
+The request should by preference occupies one entry in the Vring Descriptor
Table in the virtio crypto device's dataq, which improves
+the throughput of data transmitted for the AEAD service, so that the virtio
crypto device can be better accelerated.
\end{note}
\drivernormative{\paragraph}{AEAD Service Operation}{Device Types / Crypto
Device / Device Operation / AEAD Service Operation}
@@ -1002,8 +942,8 @@ pointed by \field{dst_data_addr} and
\field{digest_result_addr} in struct virtio
\begin{itemize*}
\item The device MUST parse the virtio_crypto_aead_data_req based on the
\field{opcode} in general header.
-\item The device MUST copy the result of cryptographic operation to the guest
memory recorded by \field{dst_data_addr} field in struct
virtio_crypto_aead_input.
-\item The device MUST copy the digest result to the guest memory recorded by
\field{digest_result_addr} field in struct virtio_crypto_aead_input.
-\item The device MUST set the \field{status} field in strut
virtio_crypto_aead_input: VIRTIO_CRYPTO_OK: success; VIRTIO_CRYPTO_ERR:
creation failed or device error; VIRTIO_CRYPTO_NOTSUPP: not supported.
+\item The device MUST copy the result of cryptographic operation to the guest
memory recorded by destination buffer.
+\item The device MUST copy the digest result to the guest memory recorded by
digest result buffer.
+\item The device MUST set the \field{status} field in strut
virtio_crypto_inhdr: VIRTIO_CRYPTO_OK: success; VIRTIO_CRYPTO_ERR: creation
failed or device error; VIRTIO_CRYPTO_NOTSUPP: not supported;
VIRTIO_CRYPTO_INVSESS: invalid session ID when the crypto operation is
implemented.
\item When the \field{opcode} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device MUST
verify and return the verification result to the driver, and if the
verification result is incorrect, VIRTIO_CRYPTO_BADMSG (bad message) MUST be
returned to the driver.
\end{itemize*}
\ No newline at end of file
Regards,
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Thursday, November 10, 2016 10:33 AM
> To: 'Cornelia Huck'
> Cc: Halil Pasic; qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org;
> Huangweidong (C); m...@redhat.com; john.grif...@intel.com; Shiqing Fan;
> Zhoujian (jay, Euler); varun.se...@freescale.com; denglin...@chinamobile.com;
> arei.gong...@hotmail.com; Hanweidong (Randy); ag...@suse.de;
> nmo...@kalray.eu; vincent.jar...@6wind.com; ola.liljed...@arm.com;
> Luonengjun; xin.z...@intel.com; Huangpeng (Peter); liang.j...@intel.com;
> stefa...@redhat.com; Jani Kokkonen; brian.a.keat...@intel.com; Claudio
> Fontana; mike.cara...@nxp.com; Wubin (H)
> Subject: RE: [Qemu-devel] [PATCH v13 1/2] virtio-crypto: Add virtio crypto
> device specification
>
> > From: Cornelia Huck [mailto:cornelia.h...@de.ibm.com]
> > Sent: Wednesday, November 09, 2016 11:25 PM
> > Subject: Re: [Qemu-devel] [PATCH v13 1/2] virtio-crypto: Add virtio crypto
> > device specification
> >
> > On Wed, 9 Nov 2016 01:11:20 +0000
> > "Gonglei (Arei)" <arei.gong...@huawei.com> wrote:
> >
> > > Nope, Actually I kept those description here is because I wanted to
> represent
> > each packet
> > > Intuitionally, otherwise I don't know how to explain them only occupy one
> > entry in desc table
> > > by indirect table method. So I changed the code completely as Stefan's
> > suggestion and
> > > revised the spec a little.
> >
> > I think you need to revise the spec a bit more :) IIUC, you should
> > simply state that you use the indirect table method and not mention any
> > guest physical addresses.
> >
> Yes, will remove the gpa description stuff. Using indirect table is a method
> for
> high performance
> and throughput, I'll mention it as a note. Pls see my another reply to
> Michael.
>
> > > This just is a representative of the realization so that the people can
> > > easily
> > understand what
> > > the virtio crypto request's components. It isn't completely same with the
> > code.
> > > For virtio-scsi device, the struct virtio_scsi_req_cmd also used this way
> IIUR.
> >
> > It seemes to have caused at least some confusion - perhaps you
> > simplyfied too much?
>
> Yes, I will.
>
> Thanks,
> -Gonglei
