Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi, Xin

> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Zeng, Xin
> Sent: Sunday, July 31, 2016 9:27 PM
> To: Gonglei (Arei); Michael S. Tsirkin
> Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Ola Liljedahl;
> Keating, Brian A; Hanweidong (Randy); Luonengjun; Huangpeng (Peter); Griffin,
> John; Ma, Liang J; Stefan Hajnoczi; Cornelia Huck; Varun Sethi; Jani Kokkonen;
> Lingli Deng; Huangweidong (C)
> Subject: [virtio-dev] RE: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio 
> crypto
> device specification
> 
> On Friday, July 29, 2016 12:10 PM Gonglei (Arei) Wrote:
> 
> > > I think version field is useful in some cases.
> > > Considering a case,  if virtio crypto device implementation has defects,
> > > and a new version fixes this defect, how can the  driver know whether the
> > > behavior of the device is correct or not?
> >
> > If it has defects, then we can call it bugs, if a software implementation 
> > has
> > Bugs, the best choice is fixing them, Or we don't support the function 
> > before
> > the bugs
> > fixed. And this is what the feature bits do. If we introduce a version, how 
> > do
> > we
> > know which version fix that bugs? Do we need add another feature bit to
> > negotiable
> > it?
> >
> 
> Refer to the comments in
> https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg06680.html
> 

I see, it seems to make sense. Thanks. 

> > > Feature bit is mostly like a negotiable field between device and driver.
> > >
> > > > >
> > > > > > +One read-only bit (for the device) is currently defined for the
> > > > \field{status}
> > > > > > +field: VIRTIO_CRYPTO_S_HW_READY. One read-only bit (for the
> > driver)
> > > > > > +is currently defined for the status field:
> > VIRTIO_CRYPTO_S_STARTED.
> > > > >
> > > > >
> > > > > what does for the device/for the driver mean here?
> > > > >
> > > > Actually I meant the device set the status filed with
> > > > VIRTIO_CRYPTO_S_HW_READY,
> > > > And the driver set the status with VIRTIO_CRYPTO_S_STARTED.
> > > > But it seems that VIRTIO_CRYPTO_S_STARTED is superfluous,
> > > > VIRTIO_CONFIG_S_DRIVER_OK
> > > > is enough for all virtio devices.
> > > >
> > > > > > +
> > > > > > +\begin{lstlisting}
> > > > > > +#define VIRTIO_CRYPTO_S_HW_READY  (1 << 0)
> > > > >
> > > > >
> > > > > so this is a way to tell guest "I am not ready yet, do not use"?
> > > > >
> > > > Yes. That's what I mean.
> > > >
> > > > >
> > > > > > +#define VIRTIO_CRYPTO_S_STARTED  (1 << 1)
> > > > >
> > > > > does not look like anyone uses bit 1.
> > > > >
> > > > Yes, will drop it.
> > > >
> > > > > > +\end{lstlisting}
> > > > >
> > > > > What does each of these mean?
> > > > >
> > > > > > +
> > > > > > +The following driver-read-only field, \field{max_dataqueuess}
> > specifies
> > > > the
> > > > > > +maximum number of data virtqueues (dataq1\ldots dataqN). The
> > > > > crypto_services
> > > > > > +shows the crypto services the virtio crypto supports. The service
> > > > currently
> > > > > > +defined are:
> > > > > > +
> > > > > > +\begin{lstlisting}
> > > > > > +#define VIRTIO_CRYPTO_NO_SERVICE (0) /* cipher services */
> > > > > > +#define VIRTIO_CRYPTO_SERVICE_CIPHER (1) /* cipher services */
> > > > > > +#define VIRTIO_CRYPTO_SERVICE_HASH  (2) /* hash service */
> > > > > > +#define VIRTIO_CRYPTO_SERVICE_MAC   (3) /* MAC (Message
> > > > > Authentication Codes) service */
> > > > > > +#define VIRTIO_CRYPTO_SERVICE_AEAD  (4) /*
> > AEAD(Authenticated
> > > > > Encryption with Associated Data) service */
> > > > > > +\end{lstlisting}
> > > > > > +
> > > > > > +The last driver-read-only fields specify detailed algorithms mask
> > which
> > > > > > +the device offered for corresponding service. The below CIPHER
> > > > algorithms
> > > > > > +are defined currently:
> > > 

Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Zeng, Xin]

On Friday, July 29, 2016 12:10 PM Gonglei (Arei) Wrote:

> > I think version field is useful in some cases.
> > Considering a case,  if virtio crypto device implementation has defects,
> > and a new version fixes this defect, how can the  driver know whether the
> > behavior of the device is correct or not?
> 
> If it has defects, then we can call it bugs, if a software implementation has
> Bugs, the best choice is fixing them, Or we don't support the function before
> the bugs
> fixed. And this is what the feature bits do. If we introduce a version, how do
> we
> know which version fix that bugs? Do we need add another feature bit to
> negotiable
> it?
> 

Refer to the comments in 
https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg06680.html

> > Feature bit is mostly like a negotiable field between device and driver.
> >
> > > >
> > > > > +One read-only bit (for the device) is currently defined for the
> > > \field{status}
> > > > > +field: VIRTIO_CRYPTO_S_HW_READY. One read-only bit (for the
> driver)
> > > > > +is currently defined for the status field:
> VIRTIO_CRYPTO_S_STARTED.
> > > >
> > > >
> > > > what does for the device/for the driver mean here?
> > > >
> > > Actually I meant the device set the status filed with
> > > VIRTIO_CRYPTO_S_HW_READY,
> > > And the driver set the status with VIRTIO_CRYPTO_S_STARTED.
> > > But it seems that VIRTIO_CRYPTO_S_STARTED is superfluous,
> > > VIRTIO_CONFIG_S_DRIVER_OK
> > > is enough for all virtio devices.
> > >
> > > > > +
> > > > > +\begin{lstlisting}
> > > > > +#define VIRTIO_CRYPTO_S_HW_READY  (1 << 0)
> > > >
> > > >
> > > > so this is a way to tell guest "I am not ready yet, do not use"?
> > > >
> > > Yes. That's what I mean.
> > >
> > > >
> > > > > +#define VIRTIO_CRYPTO_S_STARTED  (1 << 1)
> > > >
> > > > does not look like anyone uses bit 1.
> > > >
> > > Yes, will drop it.
> > >
> > > > > +\end{lstlisting}
> > > >
> > > > What does each of these mean?
> > > >
> > > > > +
> > > > > +The following driver-read-only field, \field{max_dataqueuess}
> specifies
> > > the
> > > > > +maximum number of data virtqueues (dataq1\ldots dataqN). The
> > > > crypto_services
> > > > > +shows the crypto services the virtio crypto supports. The service
> > > currently
> > > > > +defined are:
> > > > > +
> > > > > +\begin{lstlisting}
> > > > > +#define VIRTIO_CRYPTO_NO_SERVICE (0) /* cipher services */
> > > > > +#define VIRTIO_CRYPTO_SERVICE_CIPHER (1) /* cipher services */
> > > > > +#define VIRTIO_CRYPTO_SERVICE_HASH  (2) /* hash service */
> > > > > +#define VIRTIO_CRYPTO_SERVICE_MAC   (3) /* MAC (Message
> > > > Authentication Codes) service */
> > > > > +#define VIRTIO_CRYPTO_SERVICE_AEAD  (4) /*
> AEAD(Authenticated
> > > > Encryption with Associated Data) service */
> > > > > +\end{lstlisting}
> > > > > +
> > > > > +The last driver-read-only fields specify detailed algorithms mask
> which
> > > > > +the device offered for corresponding service. The below CIPHER
> > > algorithms
> > > > > +are defined currently:
> > > > > +
> > > > > +\begin{lstlisting}
> > > > > +#define VIRTIO_CRYPTO_NO_CIPHER 0
> > > > > +#define VIRTIO_CRYPTO_CIPHER_ARC4   1
> > > > > +#define VIRTIO_CRYPTO_CIPHER_AES_ECB2
> > > > > +#define VIRTIO_CRYPTO_CIPHER_AES_CBC3
> > > > > +#define VIRTIO_CRYPTO_CIPHER_AES_CTR4
> > > > > +#define VIRTIO_CRYPTO_CIPHER_DES_ECB5
> > > > > +#define VIRTIO_CRYPTO_CIPHER_DES_CBC6
> > > > > +#define VIRTIO_CRYPTO_CIPHER_3DES_ECB   7
> > > > > +#define VIRTIO_CRYPTO_CIPHER_3DES_CBC   8
> > > > > +#define VIRTIO_CRYPTO_CIPHER_3DES_CTR   9
> > > > > +#define VIRTIO_CRYPTO_CIPHER_KASUMI_F8  10
> > > > > +#define VIRTIO_CRYPTO_CIPHER_SNOW3G_UEA211
> > > > > +#define VIRTIO_CRYPTO_CIPHER_AES_F8 12
> > > > > +#define VIRTIO_CRYPTO_CIPHER_AES_XTS13
> > > > > +#define VIRTIO_CRYPTO_CIPHER_ZUC_EEA3   14
> > > > > +\end{lstlisting}
> > > > > +
> > > > > +The below HASH algorithms are defined currently:
> > > > > +
> > > > > +\begin{lstlisting}
> > > > > +#define VIRTIO_CRYPTO_NO_HASH0
> > > > > +#define VIRTIO_CRYPTO_HASH_MD5   1
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA1  2
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA_224   3
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA_256   4
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA_384   5
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA_512   6
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA3_224  7
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA3_256  8
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA3_384  9
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA3_512  10
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA3_SHAKE128  11
> > > > > +#define VIRTIO_CRYPTO_HASH_SHA3_SHAKE256  12
> > > > > +\end{lstlisting}
> > > > > +
> > > > > +The below MAC algorithms are defined currently:
> > > > > +
> > > > > +\begin{lstlisting}
> > > > > +#define 

Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> Sent: Friday, July 29, 2016 9:49 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Ola Liljedahl;
> Keating Brian; Michael S . Tsirkin; Zeng Xin; Hanweidong (Randy); Luonengjun;
> Huangpeng (Peter); Griffin John; Ma Liang J; Stefan Hajnoczi; Cornelia Huck;
> Varun Sethi; Jani Kokkonen; Lingli Deng
> Subject: Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device
> specification
> 
> On Wed, Jul 27, 2016 at 06:08:23PM +0800, Gonglei wrote:
> > +The first driver-read-only field, \field{version} specifies the virtio 
> > crypto??s
> > +version, which is reserved for back-compatibility in future.It??s currently
> 
> Here...
> 
> > +Step2: Execute the detail encryption operation:
> > +\begin{enumerate}
> > +\item The driver fills out the encrypt requests;
> > +\item Put the requests into dataq and kick the virtqueue;
> > +\item The device executes the encryption operation according the requests??
> arguments;
> 
> ...and here there are invalid characters.
> 
> The email was sent with charset UTF-8 but these bytes are not valid
> UTF-8.
> 
> Please check your text editor and git-send-email(1) configuration so
> that you send patches with the correct charset.
> 
> Stefan

Sure, I'll check it before the next version submitted.

Thanks for your reminder. :)

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Stefan Hajnoczi]

On Wed, Jul 27, 2016 at 06:08:23PM +0800, Gonglei wrote:
> +The first driver-read-only field, \field{version} specifies the virtio 
> crypto??s
> +version, which is reserved for back-compatibility in future.It??s currently

Here...

> +Step2: Execute the detail encryption operation:
> +\begin{enumerate}
> +\item The driver fills out the encrypt requests;
> +\item Put the requests into dataq and kick the virtqueue;
> +\item The device executes the encryption operation according the requests?? 
> arguments;

...and here there are invalid characters.

The email was sent with charset UTF-8 but these bytes are not valid
UTF-8.

Please check your text editor and git-send-email(1) configuration so
that you send patches with the correct charset.

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Zeng, Xin]

On Friday, July 29, 2016 1:34 PM Michael S. Tsirkin Wrote:
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Friday, July 29, 2016 1:34 PM
> To: Zeng, Xin
> Cc: Gonglei (Arei); qemu-devel@nongnu.org; virtio-dev@lists.oasis-
> open.org; Ola Liljedahl; Keating, Brian A; Hanweidong (Randy); Luonengjun;
> Huangpeng (Peter); Griffin, John; Ma, Liang J; Stefan Hajnoczi; Cornelia Huck;
> Varun Sethi; Jani Kokkonen; Lingli Deng; Huangweidong (C)
> Subject: Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device
> specification
> 
> On Thu, Jul 28, 2016 at 05:28:33AM +, Zeng, Xin wrote:
> > On Thursday, July 28, 2016 10:51 AM  Gonglei (Arei) Wrote:
> > > > > Changes from v4:
> > > > >  - introduce crypto services into virtio crypto device. The services
> > > > >currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM,
> > > > PRIMITIVE.
> > > > >  - define a unified crypto request format that is consisted of
> > > > >general header + service specific request,  Where 'general
> > > > > header' is for
> > > > all
> > > > >crypto request,  'service specific request' is composed of
> > > > >operation parameter + input data + output data in generally.
> > > > >operation parameter is algorithm-specific parameters,
> > > > >input data is the data should be operated ,
> > > > >output data is the "operation result + result buffer".
> > > > >  - redefine the algorithms and structure based on above crypto
> services.
> > > > >  - rearrange the title and subtitle
> > > > >  - Only support CIPHER, MAC, HASH and AEAD crypto services, and Xin
> will
> > > > >focus KDF, ASYM and PRIMITIVE services.
> > > > >  - Some other corresponding fixes.
> > > > >  - Make a formal patch using tex type.
> > > > >
> > > > > Changes from v3:
> > > > >  - Don't use enum is the spec but macros in specific structures.
> > > > > [Michael &
> > > > Stefan]
> > > > >  - Add two complete structures for session creation and closing, so
> that
> > > > >   the spec is clear on how to lay out the request.  [Stefan]
> > > > >  - Definite the crypto operation request with assigned
> > > > > structure, in this
> > > way,
> > > > >   each data request only occupies *one entry* of the Vring
> > > > > descriptor
> > > table,
> > > > >   which *improves* the *throughput* of data transferring.
> > > > >
> > > > > Changes from v2:
> > > > >  - Reserve virtio device ID 20 for crypto device. [Cornelia]
> > > > >  - Drop all feature bits, those capabilities are offered by the
> > > > > device all the
> > > > time.  [Stefan & Cornelia]
> > > > >  - Add a new section 1.4.2 for driver requirements. [Stefan]
> > > > >  - Use definite type definition instead of enum type in some
> structure.
> > > > [Stefan]
> > > > >  - Add virtio_crypto_cipher_alg definition. [Stefan]
> > > > >  - Add a "Device requirements" section as using MUST. [Stefan]
> > > > >  - Some grammar nits fixes and typo fixes. [Stefan & Cornelia]
> > > > >  - Add one VIRTIO_CRYPTO_S_STARTED status for the driver as the
> > > > > flag of
> > > > virtio-crypto device started and can work now.
> > > > >
> > > > > Great thanks for Stefan and Cornelia!
> > > > >
> > > > > Changes from v1:
> > > > >  - Drop the feature bit definition for each algorithm, and using
> > > > > config
> > > space
> > > > instead  [Cornelia]
> > > > >  - Add multiqueue support and add corresponding feature bit
> > > > >  - Update Encryption process and header definition
> > > > >  - Add session operation process and add corresponding header
> > > description
> > > > >  - Other better description in order to fit for virtio spec
> > > > > [Michael]
> > > > >  - Some other trivial fixes.
> > > >
> > > > OK I will let people who understand crypto comment on this.
> > >
> > > Excellently, thanks!
> > >
> > > > Down the road before we release this we'll need to link
> > > > confirmance
> > > claus

Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Michael S. Tsirkin]

On Thu, Jul 28, 2016 at 05:28:33AM +, Zeng, Xin wrote:
> On Thursday, July 28, 2016 10:51 AM  Gonglei (Arei) Wrote:
> > > > Changes from v4:
> > > >  - introduce crypto services into virtio crypto device. The services
> > > >currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM,
> > > PRIMITIVE.
> > > >  - define a unified crypto request format that is consisted of
> > > >general header + service specific request,  Where 'general header' 
> > > > is for
> > > all
> > > >crypto request,  'service specific request' is composed of
> > > >operation parameter + input data + output data in generally.
> > > >operation parameter is algorithm-specific parameters,
> > > >input data is the data should be operated ,
> > > >output data is the "operation result + result buffer".
> > > >  - redefine the algorithms and structure based on above crypto services.
> > > >  - rearrange the title and subtitle
> > > >  - Only support CIPHER, MAC, HASH and AEAD crypto services, and Xin will
> > > >focus KDF, ASYM and PRIMITIVE services.
> > > >  - Some other corresponding fixes.
> > > >  - Make a formal patch using tex type.
> > > >
> > > > Changes from v3:
> > > >  - Don't use enum is the spec but macros in specific structures. 
> > > > [Michael &
> > > Stefan]
> > > >  - Add two complete structures for session creation and closing, so that
> > > >   the spec is clear on how to lay out the request.  [Stefan]
> > > >  - Definite the crypto operation request with assigned structure, in 
> > > > this
> > way,
> > > >   each data request only occupies *one entry* of the Vring descriptor
> > table,
> > > >   which *improves* the *throughput* of data transferring.
> > > >
> > > > Changes from v2:
> > > >  - Reserve virtio device ID 20 for crypto device. [Cornelia]
> > > >  - Drop all feature bits, those capabilities are offered by the device 
> > > > all the
> > > time.  [Stefan & Cornelia]
> > > >  - Add a new section 1.4.2 for driver requirements. [Stefan]
> > > >  - Use definite type definition instead of enum type in some structure.
> > > [Stefan]
> > > >  - Add virtio_crypto_cipher_alg definition. [Stefan]
> > > >  - Add a "Device requirements" section as using MUST. [Stefan]
> > > >  - Some grammar nits fixes and typo fixes. [Stefan & Cornelia]
> > > >  - Add one VIRTIO_CRYPTO_S_STARTED status for the driver as the flag of
> > > virtio-crypto device started and can work now.
> > > >
> > > > Great thanks for Stefan and Cornelia!
> > > >
> > > > Changes from v1:
> > > >  - Drop the feature bit definition for each algorithm, and using config
> > space
> > > instead  [Cornelia]
> > > >  - Add multiqueue support and add corresponding feature bit
> > > >  - Update Encryption process and header definition
> > > >  - Add session operation process and add corresponding header
> > description
> > > >  - Other better description in order to fit for virtio spec  [Michael]
> > > >  - Some other trivial fixes.
> > >
> > > OK I will let people who understand crypto comment on this.
> > 
> > Excellently, thanks!
> > 
> > > Down the road before we release this we'll need to link confirmance
> > clauses
> > > from confirmance section. Can be a patch on top, no big deal.
> > >
> > 
> > Sorry, where is the confirmance section and what's confirmance clauses?

I meant conformance :) The stuff in conformance.tex

> > 
> > >
> > > > ---
> > > >  content.tex   |   2 +
> > > >  virtio-crypto.tex | 792
> > > ++
> > > >  2 files changed, 794 insertions(+)
> > > >  create mode 100644 virtio-crypto.tex
> > > >
> > > > diff --git a/content.tex b/content.tex
> > > > index 4b45678..ab75f78 100644
> > > > --- a/content.tex
> > > > +++ b/content.tex
> > > > @@ -5750,6 +5750,8 @@ descriptor for the \field{sense_len},
> > > \field{residual},
> > > >  \field{status_qualifier}, \field{status}, \field{response} and
> > > >  \field{sense} fields.
> > > >
> > > > +\input{virtio-crypto.tex}
> > > > +
> > > >  \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> > > >
> > > >  Currently there are three device-independent feature bits defined:
> > >
> > > Generally we keep it all in a single file. But ok, let's
> > > experiment with this split layout and see whether it
> > > makes things easier or harder. We can always squash it later.
> > >
> > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > new file mode 100644
> > > > index 000..0918f36
> > > > --- /dev/null
> > > > +++ b/virtio-crypto.tex
> > > > @@ -0,0 +1,792 @@
> > > > +\section{Crypto Device}\label{sec:Device Types / Crypto Device}
> > > > +
> > > > +The virtio crypto device is a virtual crypto device (ie. hardware
> > > > +crypto accelerator card). The encryption and decryption requests of
> > > > +are placed in the data queue, and handled by the real hardware crypto
> > > > +accelerators finally. The second queue is the control queue, which
> > > > +is used to create or destroy session 

Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi Xin,

 Thanks for your comments firstly...


Regards,
-Gonglei

> -Original Message-
> From: Zeng, Xin [mailto:xin.z...@intel.com]
> Sent: Thursday, July 28, 2016 1:29 PM
> To: Gonglei (Arei); Michael S. Tsirkin
> Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Ola Liljedahl;
> Keating, Brian A; Hanweidong (Randy); Luonengjun; Huangpeng (Peter); Griffin,
> John; Ma, Liang J; Stefan Hajnoczi; Cornelia Huck; Varun Sethi; Jani Kokkonen;
> Lingli Deng; Huangweidong (C)
> Subject: RE: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device
> specification
> 
> On Thursday, July 28, 2016 10:51 AM  Gonglei (Arei) Wrote:
> > > > Changes from v4:
> > > >  - introduce crypto services into virtio crypto device. The services
> > > >currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM,
> > > PRIMITIVE.
> > > >  - define a unified crypto request format that is consisted of
> > > >general header + service specific request,  Where 'general header' is
> for
> > > all
> > > >crypto request,  'service specific request' is composed of
> > > >operation parameter + input data + output data in generally.
> > > >operation parameter is algorithm-specific parameters,
> > > >input data is the data should be operated ,
> > > >output data is the "operation result + result buffer".
> > > >  - redefine the algorithms and structure based on above crypto services.
> > > >  - rearrange the title and subtitle
> > > >  - Only support CIPHER, MAC, HASH and AEAD crypto services, and Xin
> will
> > > >focus KDF, ASYM and PRIMITIVE services.
> > > >  - Some other corresponding fixes.
> > > >  - Make a formal patch using tex type.
> > > >
> > > > Changes from v3:
> > > >  - Don't use enum is the spec but macros in specific structures. 
> > > > [Michael
> &
> > > Stefan]
> > > >  - Add two complete structures for session creation and closing, so that
> > > >   the spec is clear on how to lay out the request.  [Stefan]
> > > >  - Definite the crypto operation request with assigned structure, in 
> > > > this
> > way,
> > > >   each data request only occupies *one entry* of the Vring descriptor
> > table,
> > > >   which *improves* the *throughput* of data transferring.
> > > >
> > > > Changes from v2:
> > > >  - Reserve virtio device ID 20 for crypto device. [Cornelia]
> > > >  - Drop all feature bits, those capabilities are offered by the device 
> > > > all the
> > > time.  [Stefan & Cornelia]
> > > >  - Add a new section 1.4.2 for driver requirements. [Stefan]
> > > >  - Use definite type definition instead of enum type in some structure.
> > > [Stefan]
> > > >  - Add virtio_crypto_cipher_alg definition. [Stefan]
> > > >  - Add a "Device requirements" section as using MUST. [Stefan]
> > > >  - Some grammar nits fixes and typo fixes. [Stefan & Cornelia]
> > > >  - Add one VIRTIO_CRYPTO_S_STARTED status for the driver as the flag
> of
> > > virtio-crypto device started and can work now.
> > > >
> > > > Great thanks for Stefan and Cornelia!
> > > >
> > > > Changes from v1:
> > > >  - Drop the feature bit definition for each algorithm, and using config
> > space
> > > instead  [Cornelia]
> > > >  - Add multiqueue support and add corresponding feature bit
> > > >  - Update Encryption process and header definition
> > > >  - Add session operation process and add corresponding header
> > description
> > > >  - Other better description in order to fit for virtio spec  [Michael]
> > > >  - Some other trivial fixes.
> > >
> > > OK I will let people who understand crypto comment on this.
> >
> > Excellently, thanks!
> >
> > > Down the road before we release this we'll need to link confirmance
> > clauses
> > > from confirmance section. Can be a patch on top, no big deal.
> > >
> >
> > Sorry, where is the confirmance section and what's confirmance clauses?
> >
> > >
> > > > ---
> > > >  content.tex   |   2 +
> > > >  virtio-crypto.tex | 792
> > > ++
> > > >  2 files changed, 794 insertions(+)
> > > >  create mode 100644 virtio-crypto.tex
> > > >

Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Zeng, Xin]

On Thursday, July 28, 2016 10:51 AM  Gonglei (Arei) Wrote:
> > > Changes from v4:
> > >  - introduce crypto services into virtio crypto device. The services
> > >currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM,
> > PRIMITIVE.
> > >  - define a unified crypto request format that is consisted of
> > >general header + service specific request,  Where 'general header' is 
> > > for
> > all
> > >crypto request,  'service specific request' is composed of
> > >operation parameter + input data + output data in generally.
> > >operation parameter is algorithm-specific parameters,
> > >input data is the data should be operated ,
> > >output data is the "operation result + result buffer".
> > >  - redefine the algorithms and structure based on above crypto services.
> > >  - rearrange the title and subtitle
> > >  - Only support CIPHER, MAC, HASH and AEAD crypto services, and Xin will
> > >focus KDF, ASYM and PRIMITIVE services.
> > >  - Some other corresponding fixes.
> > >  - Make a formal patch using tex type.
> > >
> > > Changes from v3:
> > >  - Don't use enum is the spec but macros in specific structures. [Michael 
> > > &
> > Stefan]
> > >  - Add two complete structures for session creation and closing, so that
> > >   the spec is clear on how to lay out the request.  [Stefan]
> > >  - Definite the crypto operation request with assigned structure, in this
> way,
> > >   each data request only occupies *one entry* of the Vring descriptor
> table,
> > >   which *improves* the *throughput* of data transferring.
> > >
> > > Changes from v2:
> > >  - Reserve virtio device ID 20 for crypto device. [Cornelia]
> > >  - Drop all feature bits, those capabilities are offered by the device 
> > > all the
> > time.  [Stefan & Cornelia]
> > >  - Add a new section 1.4.2 for driver requirements. [Stefan]
> > >  - Use definite type definition instead of enum type in some structure.
> > [Stefan]
> > >  - Add virtio_crypto_cipher_alg definition. [Stefan]
> > >  - Add a "Device requirements" section as using MUST. [Stefan]
> > >  - Some grammar nits fixes and typo fixes. [Stefan & Cornelia]
> > >  - Add one VIRTIO_CRYPTO_S_STARTED status for the driver as the flag of
> > virtio-crypto device started and can work now.
> > >
> > > Great thanks for Stefan and Cornelia!
> > >
> > > Changes from v1:
> > >  - Drop the feature bit definition for each algorithm, and using config
> space
> > instead  [Cornelia]
> > >  - Add multiqueue support and add corresponding feature bit
> > >  - Update Encryption process and header definition
> > >  - Add session operation process and add corresponding header
> description
> > >  - Other better description in order to fit for virtio spec  [Michael]
> > >  - Some other trivial fixes.
> >
> > OK I will let people who understand crypto comment on this.
> 
> Excellently, thanks!
> 
> > Down the road before we release this we'll need to link confirmance
> clauses
> > from confirmance section. Can be a patch on top, no big deal.
> >
> 
> Sorry, where is the confirmance section and what's confirmance clauses?
> 
> >
> > > ---
> > >  content.tex   |   2 +
> > >  virtio-crypto.tex | 792
> > ++
> > >  2 files changed, 794 insertions(+)
> > >  create mode 100644 virtio-crypto.tex
> > >
> > > diff --git a/content.tex b/content.tex
> > > index 4b45678..ab75f78 100644
> > > --- a/content.tex
> > > +++ b/content.tex
> > > @@ -5750,6 +5750,8 @@ descriptor for the \field{sense_len},
> > \field{residual},
> > >  \field{status_qualifier}, \field{status}, \field{response} and
> > >  \field{sense} fields.
> > >
> > > +\input{virtio-crypto.tex}
> > > +
> > >  \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> > >
> > >  Currently there are three device-independent feature bits defined:
> >
> > Generally we keep it all in a single file. But ok, let's
> > experiment with this split layout and see whether it
> > makes things easier or harder. We can always squash it later.
> >
> > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > new file mode 100644
> > > index 000..0918f36
> > > --- /dev/null
> > > +++ b/virtio-crypto.tex
> > > @@ -0,0 +1,792 @@
> > > +\section{Crypto Device}\label{sec:Device Types / Crypto Device}
> > > +
> > > +The virtio crypto device is a virtual crypto device (ie. hardware
> > > +crypto accelerator card). The encryption and decryption requests of
> > > +are placed in the data queue, and handled by the real hardware crypto
> > > +accelerators finally. The second queue is the control queue, which
> > > +is used to create or destroy session for symmetric algorithms, and
> > > +to control some advanced features in the future. The virtio crypto
> > > +device can provide seven crypto services: CIPHER, MAC, HASH, AEAD,
> > > +KDF, ASYM, PRIMITIVE.
> > > +
> > > +\subsection{Device ID}\label{sec:Device Types / Crypto Device / Device
> ID}
> > > +
> > > +20
> > > +
> > > 

Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi Michael,

Thanks for your rapid feedback !

> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Thursday, July 28, 2016 6:37 AM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Ola Liljedahl;
> Keating Brian; Zeng Xin; Hanweidong (Randy); Luonengjun; Huangpeng (Peter);
> Griffin John; Ma Liang J; Stefan Hajnoczi; Cornelia Huck; Varun Sethi; Jani
> Kokkonen; Lingli Deng
> Subject: Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device
> specification
> 
> On Wed, Jul 27, 2016 at 06:08:23PM +0800, Gonglei wrote:
> > The virtio crypto device is a virtual crypto device (ie. hardware
> > crypto accelerator card). The virtio crypto device can provide
> > five crypto services: CIPHER, MAC, HASH, AEAD, KDF, ASYM, PRIMITIVE.
> >
> > In this patch, CIPHER, MAC, HASH, AEAD services are introduced.
> >
> > CC: Michael S. Tsirkin <m...@redhat.com>
> > CC: Cornelia Huck <cornelia.h...@de.ibm.com>
> > CC: Stefan Hajnoczi <stefa...@redhat.com>
> > CC: Lingli Deng <denglin...@chinamobile.com>
> > CC: Jani Kokkonen <jani.kokko...@huawei.com>
> > CC: Ola Liljedahl <ola.liljed...@arm.com>
> > CC: Varun Sethi <varun.se...@freescale.com>
> > CC: Zeng Xin <xin.z...@intel.com>
> > CC: Keating Brian <brian.a.keat...@intel.com>
> > CC: Ma Liang J <liang.j...@intel.com>
> > CC: Griffin John <john.grif...@intel.com>
> > CC: Hanweidong <hanweid...@huawei.com>
> > Signed-off-by: Gonglei <arei.gong...@huawei.com>
> > ---
> > This is the specification (version 5) about a new virtio crypto device.
> > This version is a big reconstruction based on Xin's comments,
> > thanks a lot.
> >
> > If you have any comments, please let me know, thanks :)
> >
> > Changes from v4:
> >  - introduce crypto services into virtio crypto device. The services
> >currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM,
> PRIMITIVE.
> >  - define a unified crypto request format that is consisted of
> >general header + service specific request,  Where 'general header' is for
> all
> >crypto request,  'service specific request' is composed of
> >operation parameter + input data + output data in generally.
> >operation parameter is algorithm-specific parameters,
> >input data is the data should be operated ,
> >output data is the "operation result + result buffer".
> >  - redefine the algorithms and structure based on above crypto services.
> >  - rearrange the title and subtitle
> >  - Only support CIPHER, MAC, HASH and AEAD crypto services, and Xin will
> >focus KDF, ASYM and PRIMITIVE services.
> >  - Some other corresponding fixes.
> >  - Make a formal patch using tex type.
> >
> > Changes from v3:
> >  - Don't use enum is the spec but macros in specific structures. [Michael &
> Stefan]
> >  - Add two complete structures for session creation and closing, so that
> >   the spec is clear on how to lay out the request.  [Stefan]
> >  - Definite the crypto operation request with assigned structure, in this 
> > way,
> >   each data request only occupies *one entry* of the Vring descriptor table,
> >   which *improves* the *throughput* of data transferring.
> >
> > Changes from v2:
> >  - Reserve virtio device ID 20 for crypto device. [Cornelia]
> >  - Drop all feature bits, those capabilities are offered by the device all 
> > the
> time.  [Stefan & Cornelia]
> >  - Add a new section 1.4.2 for driver requirements. [Stefan]
> >  - Use definite type definition instead of enum type in some structure.
> [Stefan]
> >  - Add virtio_crypto_cipher_alg definition. [Stefan]
> >  - Add a "Device requirements" section as using MUST. [Stefan]
> >  - Some grammar nits fixes and typo fixes. [Stefan & Cornelia]
> >  - Add one VIRTIO_CRYPTO_S_STARTED status for the driver as the flag of
> virtio-crypto device started and can work now.
> >
> > Great thanks for Stefan and Cornelia!
> >
> > Changes from v1:
> >  - Drop the feature bit definition for each algorithm, and using config 
> > space
> instead  [Cornelia]
> >  - Add multiqueue support and add corresponding feature bit
> >  - Update Encryption process and header definition
> >  - Add session operation process and add corresponding header description
> >  - Other better description in order to fit for virtio spec  [Michael]
> >  - Some other trivial fixes.
> 
> OK I will let people who understand crypt

Re: [Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Michael S. Tsirkin]

On Wed, Jul 27, 2016 at 06:08:23PM +0800, Gonglei wrote:
> The virtio crypto device is a virtual crypto device (ie. hardware
> crypto accelerator card). The virtio crypto device can provide
> five crypto services: CIPHER, MAC, HASH, AEAD, KDF, ASYM, PRIMITIVE.
> 
> In this patch, CIPHER, MAC, HASH, AEAD services are introduced.
> 
> CC: Michael S. Tsirkin 
> CC: Cornelia Huck 
> CC: Stefan Hajnoczi 
> CC: Lingli Deng 
> CC: Jani Kokkonen 
> CC: Ola Liljedahl 
> CC: Varun Sethi 
> CC: Zeng Xin 
> CC: Keating Brian 
> CC: Ma Liang J 
> CC: Griffin John 
> CC: Hanweidong 
> Signed-off-by: Gonglei 
> ---
> This is the specification (version 5) about a new virtio crypto device.
> This version is a big reconstruction based on Xin's comments,
> thanks a lot.
> 
> If you have any comments, please let me know, thanks :)
> 
> Changes from v4:
>  - introduce crypto services into virtio crypto device. The services
>currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM, PRIMITIVE.
>  - define a unified crypto request format that is consisted of
>general header + service specific request,  Where 'general header' is for 
> all
>crypto request,  'service specific request' is composed of
>operation parameter + input data + output data in generally.
>operation parameter is algorithm-specific parameters,
>input data is the data should be operated ,
>output data is the "operation result + result buffer".
>  - redefine the algorithms and structure based on above crypto services.
>  - rearrange the title and subtitle
>  - Only support CIPHER, MAC, HASH and AEAD crypto services, and Xin will
>focus KDF, ASYM and PRIMITIVE services.
>  - Some other corresponding fixes.
>  - Make a formal patch using tex type.
> 
> Changes from v3:
>  - Don't use enum is the spec but macros in specific structures. [Michael & 
> Stefan]
>  - Add two complete structures for session creation and closing, so that
>   the spec is clear on how to lay out the request.  [Stefan]
>  - Definite the crypto operation request with assigned structure, in this way,
>   each data request only occupies *one entry* of the Vring descriptor table,
>   which *improves* the *throughput* of data transferring.
> 
> Changes from v2:
>  - Reserve virtio device ID 20 for crypto device. [Cornelia]
>  - Drop all feature bits, those capabilities are offered by the device all 
> the time.  [Stefan & Cornelia]
>  - Add a new section 1.4.2 for driver requirements. [Stefan]
>  - Use definite type definition instead of enum type in some structure. 
> [Stefan]
>  - Add virtio_crypto_cipher_alg definition. [Stefan]
>  - Add a "Device requirements" section as using MUST. [Stefan]
>  - Some grammar nits fixes and typo fixes. [Stefan & Cornelia]
>  - Add one VIRTIO_CRYPTO_S_STARTED status for the driver as the flag of 
> virtio-crypto device started and can work now.
> 
> Great thanks for Stefan and Cornelia!
> 
> Changes from v1:
>  - Drop the feature bit definition for each algorithm, and using config space 
> instead  [Cornelia]
>  - Add multiqueue support and add corresponding feature bit
>  - Update Encryption process and header definition
>  - Add session operation process and add corresponding header description
>  - Other better description in order to fit for virtio spec  [Michael]
>  - Some other trivial fixes.

OK I will let people who understand crypto comment on this.
Down the road before we release this we'll need to link confirmance clauses
from confirmance section. Can be a patch on top, no big deal.


> ---
>  content.tex   |   2 +
>  virtio-crypto.tex | 792 
> ++
>  2 files changed, 794 insertions(+)
>  create mode 100644 virtio-crypto.tex
> 
> diff --git a/content.tex b/content.tex
> index 4b45678..ab75f78 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -5750,6 +5750,8 @@ descriptor for the \field{sense_len}, \field{residual},
>  \field{status_qualifier}, \field{status}, \field{response} and
>  \field{sense} fields.
>  
> +\input{virtio-crypto.tex}
> +
>  \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
>  
>  Currently there are three device-independent feature bits defined:

Generally we keep it all in a single file. But ok, let's
experiment with this split layout and see whether it
makes things easier or harder. We can always squash it later.

> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> new file mode 100644
> index 000..0918f36
> --- /dev/null
> +++ b/virtio-crypto.tex
> @@ -0,0 +1,792 @@
> +\section{Crypto Device}\label{sec:Device Types / Crypto Device}
> +
> +The virtio crypto device is a virtual crypto device (ie. hardware
> +crypto 

[Qemu-devel] [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Gonglei]

The virtio crypto device is a virtual crypto device (ie. hardware
crypto accelerator card). The virtio crypto device can provide
five crypto services: CIPHER, MAC, HASH, AEAD, KDF, ASYM, PRIMITIVE.

In this patch, CIPHER, MAC, HASH, AEAD services are introduced.

CC: Michael S. Tsirkin 
CC: Cornelia Huck 
CC: Stefan Hajnoczi 
CC: Lingli Deng 
CC: Jani Kokkonen 
CC: Ola Liljedahl 
CC: Varun Sethi 
CC: Zeng Xin 
CC: Keating Brian 
CC: Ma Liang J 
CC: Griffin John 
CC: Hanweidong 
Signed-off-by: Gonglei 
---
This is the specification (version 5) about a new virtio crypto device.
This version is a big reconstruction based on Xin's comments,
thanks a lot.

If you have any comments, please let me know, thanks :)

Changes from v4:
 - introduce crypto services into virtio crypto device. The services
   currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM, PRIMITIVE.
 - define a unified crypto request format that is consisted of
   general header + service specific request,  Where 'general header' is for all
   crypto request,  'service specific request' is composed of
   operation parameter + input data + output data in generally.
   operation parameter is algorithm-specific parameters,
   input data is the data should be operated ,
   output data is the "operation result + result buffer".
 - redefine the algorithms and structure based on above crypto services.
 - rearrange the title and subtitle
 - Only support CIPHER, MAC, HASH and AEAD crypto services, and Xin will
   focus KDF, ASYM and PRIMITIVE services.
 - Some other corresponding fixes.
 - Make a formal patch using tex type.

Changes from v3:
 - Don't use enum is the spec but macros in specific structures. [Michael & 
Stefan]
 - Add two complete structures for session creation and closing, so that
  the spec is clear on how to lay out the request.  [Stefan]
 - Definite the crypto operation request with assigned structure, in this way,
  each data request only occupies *one entry* of the Vring descriptor table,
  which *improves* the *throughput* of data transferring.

Changes from v2:
 - Reserve virtio device ID 20 for crypto device. [Cornelia]
 - Drop all feature bits, those capabilities are offered by the device all the 
time.  [Stefan & Cornelia]
 - Add a new section 1.4.2 for driver requirements. [Stefan]
 - Use definite type definition instead of enum type in some structure. [Stefan]
 - Add virtio_crypto_cipher_alg definition. [Stefan]
 - Add a "Device requirements" section as using MUST. [Stefan]
 - Some grammar nits fixes and typo fixes. [Stefan & Cornelia]
 - Add one VIRTIO_CRYPTO_S_STARTED status for the driver as the flag of 
virtio-crypto device started and can work now.

Great thanks for Stefan and Cornelia!

Changes from v1:
 - Drop the feature bit definition for each algorithm, and using config space 
instead  [Cornelia]
 - Add multiqueue support and add corresponding feature bit
 - Update Encryption process and header definition
 - Add session operation process and add corresponding header description
 - Other better description in order to fit for virtio spec  [Michael]
 - Some other trivial fixes.
---
 content.tex   |   2 +
 virtio-crypto.tex | 792 ++
 2 files changed, 794 insertions(+)
 create mode 100644 virtio-crypto.tex

diff --git a/content.tex b/content.tex
index 4b45678..ab75f78 100644
--- a/content.tex
+++ b/content.tex
@@ -5750,6 +5750,8 @@ descriptor for the \field{sense_len}, \field{residual},
 \field{status_qualifier}, \field{status}, \field{response} and
 \field{sense} fields.
 
+\input{virtio-crypto.tex}
+
 \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
 
 Currently there are three device-independent feature bits defined:
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
new file mode 100644
index 000..0918f36
--- /dev/null
+++ b/virtio-crypto.tex
@@ -0,0 +1,792 @@
+\section{Crypto Device}\label{sec:Device Types / Crypto Device}
+
+The virtio crypto device is a virtual crypto device (ie. hardware
+crypto accelerator card). The encryption and decryption requests of
+are placed in the data queue, and handled by the real hardware crypto
+accelerators finally. The second queue is the control queue, which
+is used to create or destroy session for symmetric algorithms, and
+to control some advanced features in the future. The virtio crypto
+device can provide seven crypto services: CIPHER, MAC, HASH, AEAD,
+KDF, ASYM, PRIMITIVE.
+
+\subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
+
+20
+
+\subsection{Virtqueues}\label{sec:Device Types / Crypto Device / Virtqueues}
+
+\begin{description}
+\item[0] dataq1
+\item[\ldots]