Re: [Qemu-devel] [PATCH v7 09/12] virtio-crypto: add data queue processing handler

[Gonglei (Arei)]

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> Sent: Sunday, October 16, 2016 9:23 PM
> Subject: Re: [Qemu-devel] [PATCH v7 09/12] virtio-crypto: add data queue
> processing handler
> 
> On Thu, Oct 13, 2016 at 03:12:03PM +0800, Gonglei wrote:
> > Introduces VirtIOCryptoReq structure to store
> > crypto request so that we can support sync and async
> > crypto operation in the future.
> 
> What do you mean by "sync and async" operations?
> 
Synchronous and asynchronous.

> >
> > At present, we only support cipher and algorithm
> > chainning.
> 
> s/chainning/chaining/
> 
Will fix it.

> >
> > Signed-off-by: Gonglei 
> > ---
> >  hw/virtio/virtio-crypto.c | 338
> +-
> >  include/hw/virtio/virtio-crypto.h |  10 +-
> >  2 files changed, 345 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
> > index db86796..094bc48 100644
> > --- a/hw/virtio/virtio-crypto.c
> > +++ b/hw/virtio/virtio-crypto.c
> > @@ -306,6 +306,342 @@ static void virtio_crypto_handle_ctrl(VirtIODevice
> *vdev, VirtQueue *vq)
> >  } /* end for loop */
> >  }
> >
> > +static void virtio_crypto_init_request(VirtIOCrypto *vcrypto, VirtQueue 
> > *vq,
> > +VirtIOCryptoReq *req)
> > +{
> > +req->vcrypto = vcrypto;
> > +req->vq = vq;
> > +req->in = NULL;
> > +req->in_iov = NULL;
> > +req->in_num = 0;
> > +req->in_len = 0;
> > +req->flags = CRYPTODEV_BACKEND_ALG__MAX;
> > +req->u.sym_op_info = NULL;
> > +}
> > +
> > +static void virtio_crypto_free_request(VirtIOCryptoReq *req)
> > +{
> > +if (req) {
> > +if (req->flags == CRYPTODEV_BACKEND_ALG_SYM) {
> > +g_free(req->u.sym_op_info);
> > +}
> > +g_free(req);
> > +}
> > +}
> > +
> > +static void
> > +virtio_crypto_sym_input_data_helper(VirtIODevice *vdev,
> > +VirtIOCryptoReq *req,
> > +uint32_t status,
> > +CryptoDevBackendSymOpInfo *sym_op_info)
> > +{
> > +size_t s, len;
> > +
> > +if (status != VIRTIO_CRYPTO_OK) {
> > +return;
> > +}
> > +
> > +len = sym_op_info->dst_len;
> > +/* Save the cipher result */
> > +s = iov_from_buf(req->in_iov, req->in_num, 0, sym_op_info->dst, len);
> > +if (s != len) {
> > +virtio_error(vdev, "virtio-crypto dest data incorrect");
> > +return;
> > +}
> > +
> > +iov_discard_front(&req->in_iov, &req->in_num, len);
> > +
> > +if (sym_op_info->op_type ==
> > +
> VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING) {
> > +/* Save the digest result */
> > +s = iov_from_buf(req->in_iov, req->in_num, 0,
> > + sym_op_info->digest_result,
> > + sym_op_info->digest_result_len);
> > +if (s != sym_op_info->digest_result_len) {
> > +virtio_error(vdev, "virtio-crypto digest result incorrect");
> > +}
> > +}
> > +}
> > +
> > +static void virtio_crypto_req_complete(VirtIOCryptoReq *req, uint32_t
> status)
> > +{
> > +VirtIOCrypto *vcrypto = req->vcrypto;
> > +VirtIODevice *vdev = VIRTIO_DEVICE(vcrypto);
> > +
> > +if (req->flags == CRYPTODEV_BACKEND_ALG_SYM) {
> > +virtio_crypto_sym_input_data_helper(vdev, req, status,
> > +req->u.sym_op_info);
> > +}
> > +stl_he_p(&req->in->status, status);
> 
> This should be virtio_stl_p().
> 
> > +virtqueue_push(req->vq, &req->elem, req->in_len);
> > +virtio_notify(vdev, req->vq);
> > +}
> > +
> > +static VirtIOCryptoReq *
> > +virtio_crypto_get_request(VirtIOCrypto *s, VirtQueue *vq)
> > +{
> > +VirtIOCryptoReq *req = virtqueue_pop(vq, sizeof(VirtIOCryptoReq));
> > +
> > +if (req) {
> > +virtio_crypto_init_request(s, vq, req);
> > +}
> > +return req;
> > +}
> > +
> > +static CryptoDevBackendSymOpInfo *
> > +virtio_crypto_sym_op_helper(VirtIODevice *vdev,
> > +   struct virtio_crypto_cipher_para *para,
> > +   uint32_t aad_len,
> > +   struct iovec *iov, unsigned int out_num,
> > +   uint32_t hash_result_len,
> > +   uint32_t hash_start_src_offset)
> > +{
> > +CryptoDevBackendSymOpInfo *op_info;
> > +uint32_t src_len, dst_len;
> > +uint32_t iv_len;
> > +size_t max_len, curr_size = 0;
> > +size_t s;
> > +
> > +iv_len = virtio_ldl_p(vdev, ¶->iv_len);
> > +src_len = virtio_ldl_p(vdev, ¶->src_data_len);
> > +dst_len = virtio_ldl_p(vdev, ¶->dst_data_len);
> > +
> > +max_len = iv_len + aad_len + src_len + dst_len + hash_result_len;
> 
> Integer overflow checks are needed here to prevent memory corruption
> later on.
> 
> Imagine a 32-bit host where sizeof(max_len) == 4 and iv_len + aad_len +
> ... == UINT32_MAX + 1.  The malloc below will allocate just 1 byte
> instead of UINT32_MAX + 1 due to overflow.
> 
OK. Will fix it.

> > +op_info =

Re: [Qemu-devel] [PATCH v7 08/12] virtio-crypto: add control queue handler

[Gonglei (Arei)]

Hi Stefan,

Thanks for your comments!

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> Sent: Sunday, October 16, 2016 9:03 PM
> Subject: Re: [Qemu-devel] [PATCH v7 08/12] virtio-crypto: add control queue
> handler
> 
> On Thu, Oct 13, 2016 at 03:12:02PM +0800, Gonglei wrote:
> > +static int64_t
> > +virtio_crypto_create_sym_session(VirtIOCrypto *vcrypto,
> > +   struct virtio_crypto_sym_create_session_req *sess_req,
> > +   uint32_t queue_id,
> > +   uint32_t opcode,
> > +   struct iovec *iov, unsigned int out_num)
> > +{
> > +VirtIODevice *vdev = VIRTIO_DEVICE(vcrypto);
> > +CryptoDevBackendSymSessionInfo info;
> > +int64_t session_id;
> > +int queue_index;
> > +uint32_t op_type;
> > +Error *local_err = NULL;
> > +int ret;
> > +
> > +memset(&info, 0, sizeof(info));
> > +op_type = virtio_ldl_p(vdev, &sess_req->op_type);
> > +info.op_type = op_type;
> > +info.op_code = opcode;
> > +
> > +if (op_type == VIRTIO_CRYPTO_SYM_OP_CIPHER) {
> > +ret = virtio_crypto_cipher_session_helper(vdev, &info,
> > +   &sess_req->u.cipher.para,
> > +   &iov, &out_num);
> > +if (ret < 0) {
> > +return -EFAULT;
> 
> info.cipher_key is leaked here.
> 
Will fix it.

> > +}
> > +} else if (op_type ==
> VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING) {
> > +size_t s;
> > +/* cipher part */
> > +ret = virtio_crypto_cipher_session_helper(vdev, &info,
> > +   &sess_req->u.chain.para.cipher_param,
> > +   &iov, &out_num);
> > +if (ret < 0) {
> > +return -EFAULT;
> 
> info.cipher_key is leaked here.

Will fix it.
> 
> > +}
> > +/* hash part */
> > +info.alg_chain_order = virtio_ldl_p(vdev,
> > +
> &sess_req->u.chain.para.alg_chain_order);
> > +info.add_len = virtio_ldl_p(vdev,
> &sess_req->u.chain.para.aad_len);
> > +info.hash_mode = virtio_ldl_p(vdev,
> &sess_req->u.chain.para.hash_mode);
> > +if (info.hash_mode == VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH)
> {
> > +info.hash_alg = virtio_ldl_p(vdev,
> > +
> &sess_req->u.chain.para.u.mac_param.algo);
> > +info.auth_key_len = virtio_ldl_p(vdev,
> > +
> &sess_req->u.chain.para.u.mac_param.auth_key_len);
> > +info.hash_result_len = virtio_ldl_p(vdev,
> > +
> &sess_req->u.chain.para.u.mac_param.hash_result_len);
> > +/* get auth key */
> > +if (info.auth_key_len > 0) {
> > +DPRINTF("auth_keylen=%" PRIu32 "\n",
> info.auth_key_len);
> > +info.auth_key = g_malloc(info.auth_key_len);
> > +s = iov_to_buf(iov, out_num, 0, info.auth_key,
> > +   info.auth_key_len);
> > +if (unlikely(s != info.auth_key_len)) {
> > +virtio_error(vdev,
> > +  "virtio-crypto authenticated key incorrect");
> > +ret = -EFAULT;
> > +goto err;
> > +}
> > +iov_discard_front(&iov, &out_num, info.auth_key_len);
> > +}
> > +} else if (info.hash_mode ==
> VIRTIO_CRYPTO_SYM_HASH_MODE_PLAIN) {
> > +info.hash_alg = virtio_ldl_p(vdev,
> > +
> &sess_req->u.chain.para.u.hash_param.algo);
> > +info.hash_result_len = virtio_ldl_p(vdev,
> > +
> &sess_req->u.chain.para.u.hash_param.hash_result_len);
> > +} else {
> > +/* VIRTIO_CRYPTO_SYM_HASH_MODE_NESTED */
> > +error_report("unsupported hash mode");
> 
> Why is error_report() used instead of virtio_error()?  The same applies
> elsewhere.
> 
For this kind of error, we don't need to require the driver reset the virtio 
crypto
device, but receive a VIRTIO_CRYPTO_NOTSUPP because
the virtio crypto spec defines the error status, and the device need to report
an error.

But when we encounter an EFAULT error, we need to use virtio_error() to require
a reset of the device.

> > +ret = -VIRTIO_CRYPTO_NOTSUPP;
> > +goto err;
> > +}
> > +} else {
> > +/* VIRTIO_CRYPTO_SYM_OP_NONE */
> > +error_report("unsupported cipher op_type:
> VIRTIO_CRYPTO_SYM_OP_NONE");
> > +ret = -VIRTIO_CRYPTO_NOTSUPP;
> > +goto err;
> > +}
> > +
> > +queue_index = virtio_crypto_vq2q(queue_id);
> > +session_id = cryptodev_backend_sym_create_session(
> > + vcrypto->cryptodev,
> > + &info, queue_index,
> &local_err);
> > +if (session_id >= 0) {
> > +DPRINTF("create session_id=%" PRIu64 " successfully\n",
> > +session_id);
> > +
> > +ret = session_id;
> > +} else {
> > +if (local_err) {
> > +error_report_err(local_err);
> > +}
> > +  

Re: [Qemu-devel] [PATCH] mmap-alloc: check before use for ptr pointer

[Gonglei (Arei)]

> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Wednesday, October 12, 2016 3:41 PM
> To: Gonglei (Arei); Michael Tokarev; qemu-devel@nongnu.org
> Cc: qemu-triv...@nongnu.org; Herongguang (Stephen)
> Subject: Re: [PATCH] mmap-alloc: check before use for ptr pointer
> 
> 
> 
> On 12/10/2016 09:37, Gonglei (Arei) wrote:
> >> -Original Message-
> >> From: Michael Tokarev [mailto:m...@tls.msk.ru]
> >> Sent: Wednesday, October 12, 2016 2:46 PM
> >> Subject: Re: [PATCH] mmap-alloc: check before use for ptr pointer
> >>
> >> 12.10.2016 05:05, Gonglei wrote:
> >>> If ptr mmap failed, we don't need to do a superfluous
> >>> calculation for offset variable by ptr (MAP_FAILED).
> >>
> >> What's the point?  There's no problem in extra calculation
> >> if mmap failed, yes, but do we really care?  As of it is now,
> >> it is more compact and readable, and works.  I think.
> >>
> >
> > I just think it's more reasonable because the ptr is checked after
> > used. Why do we need a extra calculation?
> 
> Another reasonable objection (that however your patch doesn't fix) is
> that align is being used before the assertion:
> 
>  assert(!(align & (align - 1)));
> 

Eh, align is used at the beginning of the qemu_ram_mmap()  ;)


Regards,
-Gonglei

> Paolo
> 
> >
> > Regards,
> > -Gonglei
> >
> >> Thanks,
> >>
> >> /mjt
> >>
> >>> Signed-off-by: Gonglei 
> >>> ---
> >>>  util/mmap-alloc.c | 4 +++-
> >>>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
> >>> index 5a85aa3..577862b 100644
> >>> --- a/util/mmap-alloc.c
> >>> +++ b/util/mmap-alloc.c
> >>> @@ -61,13 +61,15 @@ void *qemu_ram_mmap(int fd, size_t size, size_t
> >> align, bool shared)
> >>>  #else
> >>>  void *ptr = mmap(0, total, PROT_NONE, MAP_ANONYMOUS |
> >> MAP_PRIVATE, -1, 0);
> >>>  #endif
> >>> -size_t offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - 
> >>> (uintptr_t)ptr;
> >>> +size_t offset;
> >>>  void *ptr1;
> >>>
> >>>  if (ptr == MAP_FAILED) {
> >>>  return MAP_FAILED;
> >>>  }
> >>>
> >>> +offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr;
> >>> +
> >>>  /* Make sure align is a power of 2 */
> >>>  assert(!(align & (align - 1)));
> >>>  /* Always align to host page size */
> >>>
> >
> >
> >

Re: [Qemu-devel] [PATCH] mmap-alloc: check before use for ptr pointer

[Gonglei (Arei)]

> -Original Message-
> From: Michael Tokarev [mailto:m...@tls.msk.ru]
> Sent: Wednesday, October 12, 2016 2:46 PM
> Subject: Re: [PATCH] mmap-alloc: check before use for ptr pointer
> 
> 12.10.2016 05:05, Gonglei wrote:
> > If ptr mmap failed, we don't need to do a superfluous
> > calculation for offset variable by ptr (MAP_FAILED).
> 
> What's the point?  There's no problem in extra calculation
> if mmap failed, yes, but do we really care?  As of it is now,
> it is more compact and readable, and works.  I think.
> 

I just think it's more reasonable because the ptr is checked after
used. Why do we need a extra calculation?


Regards,
-Gonglei

> Thanks,
> 
> /mjt
> 
> > Signed-off-by: Gonglei 
> > ---
> >  util/mmap-alloc.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
> > index 5a85aa3..577862b 100644
> > --- a/util/mmap-alloc.c
> > +++ b/util/mmap-alloc.c
> > @@ -61,13 +61,15 @@ void *qemu_ram_mmap(int fd, size_t size, size_t
> align, bool shared)
> >  #else
> >  void *ptr = mmap(0, total, PROT_NONE, MAP_ANONYMOUS |
> MAP_PRIVATE, -1, 0);
> >  #endif
> > -size_t offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr;
> > +size_t offset;
> >  void *ptr1;
> >
> >  if (ptr == MAP_FAILED) {
> >  return MAP_FAILED;
> >  }
> >
> > +offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr;
> > +
> >  /* Make sure align is a power of 2 */
> >  assert(!(align & (align - 1)));
> >  /* Always align to host page size */
> >

Re: [Qemu-devel] [PATCH v6 01/12] virtio-crypto: introduce virtio_crypto.h

[Gonglei (Arei)]

> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Tuesday, October 11, 2016 3:58 AM
> Subject: Re: [PATCH v6 01/12] virtio-crypto: introduce virtio_crypto.h
> 
> On 10/10/2016 03:43 AM, Gonglei wrote:
> > Introduce the virtio_crypto.h which follows
> > virtio-crypto specification.
> >
> > Signed-off-by: Gonglei 
> > ---
> >  include/standard-headers/linux/virtio_crypto.h | 381
> +
> >  1 file changed, 381 insertions(+)
> >  create mode 100644 include/standard-headers/linux/virtio_crypto.h
> >
> > diff --git a/include/standard-headers/linux/virtio_crypto.h
> b/include/standard-headers/linux/virtio_crypto.h
> > new file mode 100644
> > index 000..a62d192
> > --- /dev/null
> > +++ b/include/standard-headers/linux/virtio_crypto.h
> > @@ -0,0 +1,381 @@
> > +#ifndef _VIRTIO_CRYPTO_H
> > +#define _VIRTIO_CRYPTO_H
> 
> Missing a copyright and license notice.  Is this header copied from
> Linux, or is it new to qemu?  At any rate, being explicit about your
> license is important (in qemu, files without a license are GPLv2+;
> whereas the Linux kernel tends to favor GPLv2-only).
> 
It should be copied from Linux like other virtio devices do.
I'll add copyright for this in the next version.

> > +
> > +#include "standard-headers/linux/types.h"
> > +#include "standard-headers/linux/virtio_config.h"
> > +#include "standard-headers/linux/virtio_types.h"
> > +
> > +
> > +#define VIRTIO_CRYPTO_SERVICE_CIPHER (0)
> > +#define VIRTIO_CRYPTO_SERVICE_HASH (1)
> > +#define VIRTIO_CRYPTO_SERVICE_MAC  (2)
> > +#define VIRTIO_CRYPTO_SERVICE_AEAD (3)
> 
> Technically over-parenthesized, but doesn't hurt.
> 
> > +
> > +#define VIRTIO_CRYPTO_OPCODE(service, op)   ((service << 8) | (op))
> 
> Under-parenthesized.  You need more () around service.
> 
So, the best definition is:

#define VIRTIO_CRYPTO_SERVICE_CIPHER 0
#define VIRTIO_CRYPTO_SERVICE_HASH 1
#define VIRTIO_CRYPTO_SERVICE_MAC 2
#define VIRTIO_CRYPTO_SERVICE_AEAD 3

#define VIRTIO_CRYPTO_OPCODE(service, op)   (((service) << 8) | (op))

Will fix. Thanks~

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v6 00/12] virtio-crypto: introduce framework and device emulation

[Gonglei (Arei)]

> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Tuesday, October 11, 2016 3:53 AM
> Subject: Re: [PATCH v6 00/12] virtio-crypto: introduce framework and device
> emulation
> 
> On 10/10/2016 03:43 AM, Gonglei wrote:
> > The virtio crypto is a virtual crypto device as well as a kind
> > of virtual hardware accelerator for virtual machines. The
> > encryption and decryption requests are placed in the data
> > queue and handled by the real crypto accelerators finally.
> > The second queue is the control queue used to create or
> > destroy sessions for symmetric algorithms and control
> > some advanced features in the future. The virtio crypto
> > device provides the following crypto services: CIPHER,
> > MAC, HASH, AEAD etc.
> >
> > TODO:
> >  - add vhost-user as a high performance cryptodev backend.
> >  - more crypto services support.
> >  - mirgration support.
> >
> > Changes since v5:
> >  - rebase the patch 14 in v5, using the correct at the beginning of whole
> patch serials. [Eric]
> 
> s/serials/series/  ('series' is one of those weird English words that is
> the same for both singular and plural usage)
> 
I see, thanks. :)


Regards,
-Gonglei

> >  - perfect algorithm chain support in patch 12.
> >  - more friendly error handler in both controlq and dataq.
> >  - drop patch "virtio-crypto: emulate virtio crypto as a legacy device by
> default" because
> >   we shouldn't support transitional virtio devices any more. [Michael]
> >  - drop patch "virtio-crypto-test: add qtest case for virtio-crypto" because
> >   libqtest doesn't support virtio-1.0 device yet.
> >  - rebase the patch set based on Michael's pull request:
> > [PULL 00/33] virtio, pc: fixes and features
> >
> 
> --
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org

Re: [Qemu-devel] [PATCH v6 00/12] virtio-crypto: introduce framework and device emulation

[Gonglei (Arei)]

Oooops, incorrect git branch...

NACK, I will resend v6.



Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Monday, October 10, 2016 4:44 PM
> To: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org
> Cc: Luonengjun; m...@redhat.com; stefa...@redhat.com;
> pbonz...@redhat.com; berra...@redhat.com; Huangweidong (C); Wubin (H);
> mike.cara...@nxp.com; ag...@suse.de; xin.z...@intel.com; Claudio
> Fontana; nmo...@kalray.eu; vincent.jar...@6wind.com; Zhoujian (jay, Euler);
> Hanweidong (Randy); Huangpeng (Peter); arei.gong...@hotmail.com;
> ebl...@redhat.com; Gonglei (Arei)
> Subject: [PATCH v6 00/12] virtio-crypto: introduce framework and device
> emulation
> 
> The virtio crypto is a virtual crypto device as well as a kind
> of virtual hardware accelerator for virtual machines. The
> encryption and decryption requests are placed in the data
> queue and handled by the real crypto accelerators finally.
> The second queue is the control queue used to create or
> destroy sessions for symmetric algorithms and control
> some advanced features in the future. The virtio crypto
> device provides the following crypto services: CIPHER,
> MAC, HASH, AEAD etc.
> 
> TODO:
>  - add vhost-user as a high performance cryptodev backend.
>  - more crypto services support.
>  - mirgration support.
> 
> Changes since v5:
>  - rebase the patch 14 in v5, using the correct at the beginning of whole 
> patch
> serials. [Eric]
>  - perfect algorithm chain support in patch 12.
>  - more friendly error handler in both controlq and dataq.
>  - drop patch "virtio-crypto: emulate virtio crypto as a legacy device by 
> default"
> because
>   we shouldn't support transitional virtio devices any more. [Michael]
>  - drop patch "virtio-crypto-test: add qtest case for virtio-crypto" because
>   libqtest doesn't support virtio-1.0 device yet.
>  - rebase the patch set based on Michael's pull request:
> [PULL 00/33] virtio, pc: fixes and features
> 
> Changes since v4: (Thanks to Stefan)
>  - drop scatter-gather I/O identification in virtio crypto spec and 
> corresponding
> code [Stefan]
>  - remove qcrypto perfix for cryptdov stuff [Stefan]
>  - use virtio_error() in virtio-crypto device's functions. [Stefan]
>  - fix endianness handling. [Stefan]
>  - use VMSTATE_VIRTIO_DEVICE() instead of calling register_savevm().
> [Stefan]
>  - redefine DPRINTF in virtio-crypto.h [Stefan]
>  - fix some typos [Stefan]
>  - fix other farraginous problems suggested by Stefan.
> 
> Changes since v3:
>  - rename cryptodev-gcrypt to cryptodev-buitlin. [Daniel]
>  - move cryptodev stuff from crypto/ directory to backends/ directory
>in order to keep the crypto subsystem influence by syetem
>emulators. [Daniel]
>  - emulate virtio-crypto device as a legacy device by default in patch 11
>  - introduce virtio-crypto qtest case in patch 12
>  - add myself as cryptdoev backends mainatainer and vitio-crypto
>co-maintainer in patch 13
>  - add CRT support for cryptodev-builtin, it based on my previous crypto
>patch serial queued by Daniel.
>https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06607.html
>  - add queue_index for qcrypto_cryptodev_backend_sym_close_session()
> 
> Changes since v2:
>  According to Daniel's comments:
>  - drop cryptodev kernel module as a cryptodev backend
>  - rename crypto stuff to cryptodev stuff
>  - change some files' license to GPLv2+
>  - remove cryptodev command line instead of QOM to define the cryptodev
> backend
>  - rename all functions and structures in crypto sub-directory.
>  - add full inline documentation for cryptodev.h
>  And:
>  - drop crypto-queue.c [Paolo]
>  - merge some patches
> 
> Great thanks to Daniel and Paolo. Please review again, thanks!
> 
> Changes since v1:
>  - rmmove mixed endian-ness handler for virtio-crypto device, just
>use little-endian. [mst]
>  - add sg list support according virtio-crypto spec v10 (will be posted soon).
>  - fix a memory leak in session handler.
>  - add a feature page link in qemu.org
> (http://qemu-project.org/Features/VirtioCrypto)
>  - fix some trivial problems, sush as 's/Since 2.7/Since 2.8/g' in
> qapi-schema.json
>  - rebase the latest qemu master tree.
> 
> 
> This patch series realize the framework and emulation of a new
> virtio crypto device, which is similar with virtio net device.
> 
>  - I introduce the cryptodev backend as the client of virtio crypto device
>which can be realized by different methods, such as
> cryptodev-backend-gcrypt in my series,
>vhost-crypto kernel module, vhost-user etc.
>  - The patch set abide

Re: [Qemu-devel] [PATCH v5 11/14] virtio-crypto: emulate virtio crypto as a legacy device by default

[Gonglei (Arei)]

Hi Michael,

Happy to listen to your voice :)


> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Monday, October 10, 2016 7:48 AM
> Subject: Re: [PATCH v5 11/14] virtio-crypto: emulate virtio crypto as a legacy
> device by default
> 
> On Thu, Oct 06, 2016 at 07:36:44PM +0800, Gonglei wrote:
> > the scenario of virtio crypto device is mostly NFV, which require
> > the existing Guest can't need to do any changes to support virtio
> > crypto, so that they can easily migrate the existing network units
> > to VM. That's also a basic requirement came from our customers
> > in production environment.
> >
> > For virtio crypto driver, we can both support virtio-1.0 or earlier. But
> > Virtio pci driver module can't discovery the virtio-1.0 devices in most
> > existing Guests. If we want do this, we have to require the customers
> > change the virtio pci module for existing guests influence all virtio
> > devices, which is impossible.
> >
> > So, let's emulate the virtio crypto device as a legacy virtio
> > device by default. Using 0x1014 as virtio crypto pci device ID
> > because virtio crypto ID is 20 (0x14).
> >
> > Signed-off-by: Gonglei 
> 
> Sorry, I don't think this makes any sense.
> 
> You certainly can have two drivers: one for legacy and one for modern
> devices. 

Oh, This is indeed a solution.

> It only gets difficult if you try to support transitional
> devices.
> 
> Pls drop this patch.
> 
OK, then I have to temporarily drop the patch 12/14 as well because libqtest
doesn't support virtio-1.0 device yet. 


Regards,
-Gonglei

> > ---
> >  docs/specs/pci-ids.txt| 2 ++
> >  hw/virtio/virtio-crypto-pci.c | 4 +++-
> >  include/hw/pci/pci.h  | 2 ++
> >  3 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/docs/specs/pci-ids.txt b/docs/specs/pci-ids.txt
> > index fd27c67..662d4f8 100644
> > --- a/docs/specs/pci-ids.txt
> > +++ b/docs/specs/pci-ids.txt
> > @@ -22,6 +22,7 @@ maintained as part of the virtio specification.
> >  1af4:1004  SCSI host bus adapter device (legacy)
> >  1af4:1005  entropy generator device (legacy)
> >  1af4:1009  9p filesystem device (legacy)
> > +1af4:1014  crypto device (legacy)
> >
> >  1af4:1041  network device (modern)
> >  1af4:1042  block device (modern)
> > @@ -32,6 +33,7 @@ maintained as part of the virtio specification.
> >  1af4:1049  9p filesystem device (modern)
> >  1af4:1050  virtio gpu device (modern)
> >  1af4:1052  virtio input device (modern)
> > +1af4:1054  crypto device (modern)
> >
> >  1af4:10f0  Available for experimental usage without registration.  Must
> get
> > to  official ID when the code leaves the test lab (i.e. when seeking
> > diff --git a/hw/virtio/virtio-crypto-pci.c b/hw/virtio/virtio-crypto-pci.c
> > index 21d9984..30c10f0 100644
> > --- a/hw/virtio/virtio-crypto-pci.c
> > +++ b/hw/virtio/virtio-crypto-pci.c
> > @@ -32,7 +32,6 @@ static void virtio_crypto_pci_realize(VirtIOPCIProxy
> *vpci_dev, Error **errp)
> >  DeviceState *vdev = DEVICE(&vcrypto->vdev);
> >
> >  qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
> > -virtio_pci_force_virtio_1(vpci_dev);
> >  object_property_set_bool(OBJECT(vdev), true, "realized", errp);
> >  object_property_set_link(OBJECT(vcrypto),
> >   OBJECT(vcrypto->vdev.conf.cryptodev), "cryptodev",
> > @@ -49,6 +48,9 @@ static void virtio_crypto_pci_class_init(ObjectClass
> *klass, void *data)
> >  set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> >  dc->props = virtio_crypto_pci_properties;
> >
> > +pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > +pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_CRYPTO;
> > +pcidev_k->revision = 0;
> >  pcidev_k->class_id = PCI_CLASS_OTHERS;
> >  }
> >
> > diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> > index 772692f..5881101 100644
> > --- a/include/hw/pci/pci.h
> > +++ b/include/hw/pci/pci.h
> > @@ -83,6 +83,8 @@
> >  #define PCI_DEVICE_ID_VIRTIO_RNG 0x1005
> >  #define PCI_DEVICE_ID_VIRTIO_9P  0x1009
> >  #define PCI_DEVICE_ID_VIRTIO_VSOCK   0x1012
> > +#define PCI_DEVICE_ID_VIRTIO_CRYPTO  0x1014
> > +
> >
> >  #define PCI_VENDOR_ID_REDHAT 0x1b36
> >  #define PCI_DEVICE_ID_REDHAT_BRIDGE  0x0001
> > --
> > 1.7.12.4
> >

Re: [Qemu-devel] [PATCH v5 14/14] cryptodev: rename cryptodev stuff

[Gonglei (Arei)]

Hi Eric,

> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Friday, October 07, 2016 3:48 AM
> Subject: Re: [Qemu-devel] [PATCH v5 14/14] cryptodev: rename cryptodev stuff
> 
> On 10/06/2016 06:36 AM, Gonglei wrote:
> > Remove qcrypto and/or QCRYPTO prefix in order to
> > make the name shorter because it doesn't repeat
> > any information.
> >
> > Signed-off-by: Gonglei 
> > ---
> >  backends/cryptodev-builtin.c  |  84 
> 
> This file is new as part of your series.  Please rebase this to avoid
> the churn, by making it use the correct naming from the get-go rather
> than an after-the-fact correction.
> 
You are absolutely right, I will rebase it, thanks :)

Regards,
-Gonglei

> --
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org

Re: [Qemu-devel] [PATCH v11 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Wednesday, October 05, 2016 12:16 AM
> Subject: Re: [Qemu-devel] [PATCH v11 1/2] virtio-crypto: Add virtio crypto
> device specification
> 
> On Tue, Oct 04, 2016 at 12:24:02PM +, gong lei wrote:
> > On 2016/10/4 17:05, Stefan Hajnoczi wrote:
> > > On Tue, Oct 04, 2016 at 02:53:25AM +, gong lei wrote:
> > >> Hi Stefan,
> > >>
> > >> Thanks for your comments.
> > >>
> > >>> On Wed, Sep 28, 2016 at 05:08:24PM +0800, Gonglei wrote:
> >  /+For scatter/gather list support, a buffer can be represented by /
> >  /virtio_crypto_iovec structure./
> >  /+/
> >  /+The structure is defined as follows:/
> >  /+/
> >  /+\begin{lstlisting}/
> >  /+struct virtio_crypto_iovec {/
> >  /+ /* Guest physical address *//
> >  /+ le64 addr;/
> >  /+ /* Length of guest physical address *//
> >  /+ le32 len;/
> >  /+/* This marks a buffer as continuing via the next field *//
> >  /+#define VIRTIO_CRYPTO_IOVEC_F_NEXT 1/
> >  /+ /* The flags as indicated above VIRTIO_CRYPTO_IOVEC_F_*. *//
> >  /+ le32 flags;/
> >  /+ /* Pointer to next struct virtio_crypto_iovec if flags & NEXT *//
> >  /+ le64 next_iovec;/
> >  /+};/
> >  /+\end{lstlisting}/
> > >>> The vring already provides scatter-gather I/O.  It is usually not
> > >>> necessary to define scatter-gather I/O at the device level. Addresses
> > >>> can be translated by the virtio transport (PCI, MMIO, CCW).  For
> example
> > >>> PCI bus addresses with IO-MMU.  Therefore it's messy to use guest
> > >>> physical addresses in the device specification.
> > >>>
> >  /+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./
> > >>> Indirect vrings also only require one entry in the descriptor table.  I
> > >>> don't understand why you are reinventing scatter-gather I/O.
> > >>>
> > >>> Am I missing something?
> > >> Yes, I knew indirect vring. But for virtio-crypto device' request, each
> > >> crypto request include
> > >> many buffers. Take algorithm chain' request as an examle, the driver
> > >> need to transmit source
> > >> data, dstination data, initializaion vector, additional authentication
> > >> data, digest result
> > >> data etc. to the device. In those data, the source data and destionation
> > >> data etc. may be composed
> > >> by scatter-gather I/O.  That's the background.
> > >>
> > >> In virtio-crypto spec, we use a structure to store all those contents so
> > >> that we can put all those data
> > >> into one entry in the Descriptor Table, otherwise the effect of
> > >> acceleration is not good. We
> > >> thought other methods to inprove the performance as well, such as
> > >> increasing the virng size
> > >> of dataq, but the maxinum is 1024 at present, and it maybe influence the
> > >> latency if the vring
> > >> size is too big.
> > >>
> > >> For the indirect ving in existing Virtio spec, is only used for one
> > >> buffer, which can't cover
> > >> our situation.
> > > Indirect vring uses 1 descriptor in the vring descriptor table, but that
> > > descriptor points to a separate table that can have many descriptors.
> > > You are not limited to just 1 scatter-gather element.
> > >
> > > Also, I've noticed that the structs in the spec are mixing
> > > device-readable and device-writable fields in structs.  This is not
> > > allowed since virtio requires that all device-readable data comes before
> > > all all device-writable data.
> > The spec 2.4.5 says something related, but not forced.
> >
> > A device MUST NOT write to a device-readable buffer, and a device SHOULD
> > NOT read a device-writable
> > buffer (it MAY do so for debugging or diagnostic purposes).
> 
> Please see:
> 
>   3.2.1.1 Placing Buffers Into The Descriptor Table
> 
>   A buffer consists of zero or more read-only physically-contiguous
>   elements followed by zero or more physically-contiguous write-only
>   elements (it must have at least one element).
> 
> You must lay out the request (read-only) and response (write-only) parts
> in order.  It's not possible to have read-only elements after a
> write-only element.
> 
> > > I think you'll be able to use indirect vring with the same performance
> > > as customer scatter-gather I/O once you think through the layout of
> > > device-readable and device-writable data.
> > >
> > > In order to lay out requests correctly the device-readable headers
> > > struct must contain the length of all variable-sized fields.
> > >
> > > For example, the header would have an iv_len field and 

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v4 00/13] virtio-crypto: introduce framework and device emulation

[Gonglei (Arei)]

> -Original Message-
> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Stefan Hajnoczi
> Sent: Tuesday, October 04, 2016 6:13 PM
> Subject: [virtio-dev] Re: [PATCH v4 00/13] virtio-crypto: introduce framework
> and device emulation
> 
> On Wed, Sep 28, 2016 at 04:25:39PM +0800, Gonglei wrote:
> > The virtio crypto is a virtual crypto device as well as a kind
> > of virtual hardware accelerator for virtual machines. The
> > encryption and decryption requests are placed in the data
> > queue and handled by the real crypto accelerators finally.
> > The second queue is the control queue used to create or
> > destroy sessions for symmetric algorithms and control
> > some advanced features in the future. The virtio crypto
> > device provides the following crypto services: CIPHER,
> > MAC, HASH, AEAD etc.
> 
> Please look at my reply to the virtio-crypto spec email thread.  Changes
> to the request layout are necessary (dropping custom scatter-gather I/O,
> avoiding assumptions about iovec layout, ordering of
> device-readable/writable buffers).
> 
> This will change the code quite a bit so I won't review further for now.
> 
> Stefan

OK, thank you very much for your comments, Stefan.
I'll fix the spec and corresponding code ASAP.

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v4 08/13] virtio-crypto: add control queue handler

[Gonglei (Arei)]

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Tuesday, October 04, 2016 6:09 PM
> Subject: Re: [PATCH v4 08/13] virtio-crypto: add control queue handler
> 
> On Wed, Sep 28, 2016 at 04:25:47PM +0800, Gonglei wrote:
> > -static void virtio_crypto_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> > +static inline int virtio_crypto_vq2q(int queue_index)
> > +{
> > +return queue_index;
> > +}
> 
> Please document this function.  I think it takes a virtqueue index and
> returns the crypto queue.  The ctrl virtqueue is after the op virtqueues
> so the input value doesn't need to be adjusted.
> 
Yes, it makes very sense. Thanks.

> Without this information it's hard to understand the function.
> 
> > +
> > +static void
> > +virtio_crypto_cipher_session_helper(VirtIODevice *vdev,
> > +   QCryptoCryptoDevBackendSymSessionInfo *info,
> > +   struct virtio_crypto_cipher_session_para *cipher_para,
> > +   struct virtio_crypto_cipher_session_output *cipher_out)
> > +{
> > +hwaddr key_gpa;
> > +void *key_hva;
> > +hwaddr len;
> > +
> > +info->cipher_alg = cipher_para->algo;
> > +info->key_len = cipher_para->keylen;
> > +info->direction = cipher_para->op;
> 
> Endianness?  Use the virtio_ldl_p() family of functions to load values
> from the guest.
> 
> This same issue is present in the rest of the code.  I won't mentioned
> it again but please fix all occurrences.
> 
Will fix them.

> > +len = info->key_len;
> > +/* get cipher key */
> > +if (len > 0) {
> > +DPRINTF("keylen=%" PRIu32 "\n", info->key_len);
> > +key_gpa = cipher_out->key_addr;
> > +
> > +key_hva = cpu_physical_memory_map(key_gpa, &len, 0);
> 
> virtio devices should not use cpu_physical_memory_map().  Please see my
> reply to the virtio-crypto specification about scatter-gather I/O.
> 
OK.

> > +static void virtio_crypto_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> > +{
> > +VirtIOCrypto *vcrypto = VIRTIO_CRYPTO(vdev);
> > +struct virtio_crypto_op_ctrl_req ctrl;
> > +VirtQueueElement *elem;
> > +size_t s;
> > +struct iovec *iov;
> > +unsigned int iov_cnt;
> > +uint32_t queue_id;
> > +uint32_t opcode;
> > +
> > +for (;;) {
> > +elem = virtqueue_pop(vq, sizeof(VirtQueueElement));
> > +if (!elem) {
> > +break;
> > +}
> > +if (elem->in_num < 1 ||
> > +iov_size(elem->in_sg, elem->in_num) < sizeof(ctrl)) {
> > +error_report("virtio-crypto ctrl missing headers");
> > +exit(1);
> > +}
> 
> Please use virtio_error() instead.  virtio devices should not call
> exit(1).  There are other instances of this throughout the code, please
> fix all of them.
> 
I noticed your patch set introduced virtio_error(), and it seems that merged
a few days ago. 

I'll fix them.

> > +
> > +iov_cnt = elem->in_num;
> > +iov = elem->in_sg;
> > +s = iov_to_buf(iov, iov_cnt, 0, &ctrl, sizeof(ctrl));
> > +assert(s == sizeof(ctrl));
> 
> This assert is always true because you checked iov_size() above.  Please
> move that check down here and drop the assert.

OK.

Regards,
-Gonglei

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v4 07/13] virtio-crypto: set capacity of algorithms supported

[Gonglei (Arei)]

> -Original Message-
> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Stefan Hajnoczi
> Sent: Tuesday, October 04, 2016 5:46 PM
> Subject: [virtio-dev] Re: [PATCH v4 07/13] virtio-crypto: set capacity of
> algorithms supported
> 
> On Wed, Sep 28, 2016 at 04:25:46PM +0800, Gonglei wrote:
> >  static void virtio_crypto_get_config(VirtIODevice *vdev, uint8_t *config)
> >  {
> > -
> > +VirtIOCrypto *c = VIRTIO_CRYPTO(vdev);
> > +struct virtio_crypto_config crypto_cfg;
> > +
> > +crypto_cfg.status = c->status;
> > +crypto_cfg.max_dataqueues = c->max_queues;
> > +crypto_cfg.crypto_services = c->conf.crypto_services;
> > +crypto_cfg.cipher_algo_l = c->conf.cipher_algo_l;
> > +crypto_cfg.cipher_algo_h = c->conf.cipher_algo_h;
> > +crypto_cfg.hash_algo = c->conf.hash_algo;
> > +crypto_cfg.mac_algo_l = c->conf.mac_algo_l;
> > +crypto_cfg.mac_algo_h = c->conf.mac_algo_h;
> > +crypto_cfg.aead_algo = c->conf.aead_algo;
> > +
> > +memcpy(config, &crypto_cfg, c->config_size);
> >  }
> 
> What about endianness?  For example, if the host is big-endian then this
> VIRTIO 1.0 device needs to byteswap multi-byte fields.  There is a
> family of functions to help with this: virtio_stl_p().

I did that in v1. Michael told me that Virtio-1.0 devices are always 
little-endian, so
I removed those helper functions in the following functions. But after this 
version,
the virtio-crypto device isn't virtio-1.0 device by default, so I should use 
them again.


Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v4 05/13] virtio-crypto: add virtio crypto device emulation

[Gonglei (Arei)]

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Tuesday, October 04, 2016 5:38 PM
> Subject: Re: [PATCH v4 05/13] virtio-crypto: add virtio crypto device 
> emulation
> 
> On Wed, Sep 28, 2016 at 04:25:44PM +0800, Gonglei wrote:
> > Introduce the virtio crypto realization, I'll
> > finish the core code in the following patches. The
> > thoughts came from virtio net realization.
> >
> > For more information see:
> > http://qemu-project.org/Features/VirtioCrypto
> 
> This patch contains functions and struct fields that are unused.  It
> would make code review easier if you add them when they are needed
> throughout the patch series.
> 
OK, will remove them.

> > +static void virtio_crypto_device_realize(DeviceState *dev, Error **errp)
> > +{
> > +VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> > +VirtIOCrypto *vcrypto = VIRTIO_CRYPTO(dev);
> > +int i;
> > +
> > +vcrypto->cryptodev = vcrypto->conf.cryptodev;
> > +if (vcrypto->cryptodev == NULL) {
> > +error_setg(errp, "'cryptodev' parameter expects a valid object");
> > +return;
> > +}
> > +
> > +vcrypto->max_queues = MAX(vcrypto->cryptodev->conf.peers.queues,
> 1);
> > +if (vcrypto->max_queues + 1 > VIRTIO_QUEUE_MAX) {
> > +error_setg(errp, "Invalid number of queues (= %" PRIu16 "), "
> > +   "must be a postive integer less than %d.",
> > +   vcrypto->max_queues, VIRTIO_QUEUE_MAX - 1);
> 
> The error message is off by 1:
> 
> must be a positive integer less than VIRTIO_QUEUE_MAX
> 
Yes.

> > +return;
> > +}
> > +
> > +virtio_init(vdev, "virtio-crypto", VIRTIO_ID_CRYPTO,
> vcrypto->config_size);
> > +vcrypto->curr_queues = 1;
> > +
> > +for (i = 0; i < vcrypto->max_queues; i++) {
> > +virtio_add_queue(vdev, 1024, virtio_crypto_handle_dataq);
> > +}
> > +
> > +vcrypto->ctrl_vq = virtio_add_queue(vdev, 64,
> virtio_crypto_handle_ctrl);
> > +if (!vcrypto->cryptodev->ready) {
> > +vcrypto->status &= ~VIRTIO_CRYPTO_S_HW_READY;
> > +} else {
> > +vcrypto->status |= VIRTIO_CRYPTO_S_HW_READY;
> > +}
> > +register_savevm(dev, "virtio-crypto", -1, 1, virtio_crypto_save,
> > +virtio_crypto_load, vcrypto);
> 
> Please use VMSTATE_VIRTIO_DEVICE() instead of calling register_savevm().
> 
OK.

> > +#ifdef DEBUG_VIRTIO_CRYPTO
> > +#define DPRINTF(fmt, ...) \
> > +do { printf("virtio_crypto: " fmt , ## __VA_ARGS__); } while (0)
> > +#else
> > +#define DPRINTF(fmt, ...) do { } while (0)
> > +#endif
> 
> Please use tracing (see docs/tracing.txt) or if you really want to use

I planned to polish tracing log in my TODO list. So, currently I'd like to use
DPRINTF().

> debug printfs then define DPRINTF() in a way that prevents bitrot:
> 
> #define DEBUG_VIRTIO_CRYPTO 0
> #define DPRINTF(fmt, ...) \
> do { \
> if (DEBUG_VIRTIO_CRYPTO) { \
> fprintf(stderr, "virtio_crypto: " fmt, ##__VA_ARGS__); \
> } \
> } while (0)

Make sense.


Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v4 04/13] cryptodev: introduce a new cryptodev backend

[Gonglei (Arei)]

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Tuesday, October 04, 2016 12:32 AM
> Subject: Re: [PATCH v4 04/13] cryptodev: introduce a new cryptodev backend
> 
> On Wed, Sep 28, 2016 at 04:25:43PM +0800, Gonglei wrote:
> > +/* Max number of symetrical sessions */
> 
> s/symetrical/symmetric/
> 
> But why does the comment say "symetrical" when the constant name
> MAX_NUM_SESSIONS seems to be a global limit for *all* sessions (not just
> symmetric)?
> 
> > +#define MAX_NUM_SESSIONS 256
> 
> The guest can only have 256 sessions open?
> 
For cipher API backend, it's a experimental cryptodev backend, which
can't be applied in production environment because of the poor performance. 
The limit is just for simplifying code logic, of course we can increase the 
number
as well, but it doesn't necessary IMO.

> What are the limits of real crypto libraries and accelerators?
> 
The hardware accelerators maybe have a limit, for example the
Intel QAT pmd driver in DPDK limit the maximum num of session is 2048.

> > +
> > +
> > +struct QCryptoCryptoDevBackendBuiltin {
> > +QCryptoCryptoDevBackend parent_obj;
> > +
> > +QCryptoCryptoDevBackendBuiltinSession
> *sessions[MAX_NUM_SESSIONS];
> > +};
> > +
> > +static void qcrypto_cryptodev_backend_builtin_init(
> > + QCryptoCryptoDevBackend *backend, Error **errp)
> > +{
> > +/* Only support one queue */
> > +int queues = MAX(backend->conf.peers.queues, 1);
> > +size_t i;
> > +QCryptoCryptoDevBackendClientState *cc;
> > +
> > +for (i = 0; i < queues; i++) {
> > +cc = qcrypto_cryptodev_backend_new_client(
> > +  "cryptodev-builtin", NULL);
> > +snprintf(cc->info_str, sizeof(cc->info_str),
> > + "cryptodev-builtin%lu", i);
> > +cc->queue_index = i;
> > +
> > +backend->conf.peers.ccs[i] = cc;
> > +}
> > +
> > +backend->conf.crypto_services =
> > + 1u << VIRTIO_CRYPTO_SERVICE_CIPHER |
> > + 1u << VIRTIO_CRYPTO_SERVICE_HASH |
> > + 1u << VIRTIO_CRYPTO_SERVICE_MAC;
> > +backend->conf.cipher_algo_l = 1u <<
> VIRTIO_CRYPTO_CIPHER_AES_CBC;
> > +backend->conf.hash_algo = 1u << VIRTIO_CRYPTO_HASH_SHA1;
> > +}
> > +
> > +static int
> > +qcrypto_cryptodev_backend_builtin_get_unused_session_index(
> > +  QCryptoCryptoDevBackendBuiltin *builtin)
> > +{
> > +size_t i;
> > +
> > +for (i = 0; i < MAX_NUM_SESSIONS; i++) {
> > +if (builtin->sessions[i] == NULL) {
> > +return i;
> > +}
> > +}
> > +
> > +return -1;
> > +}
> > +
> > +static int
> > +qcrypto_cryptodev_backend_builtin_get_algo(uint32_t key_len,
> > +   Error **errp)
> > +{
> > +int algo;
> > +
> > +if (key_len == 128 / 8) {
> > +algo = QCRYPTO_CIPHER_ALG_AES_128;
> > +} else if (key_len == 192 / 8) {
> > +algo = QCRYPTO_CIPHER_ALG_AES_192;
> > +} else if (key_len == 256 / 8) {
> > +algo = QCRYPTO_CIPHER_ALG_AES_256;
> > +} else {
> > +error_setg(errp, "unsupported key length :%u", key_len);
> > +return -1;
> > +}
> > +
> > +return algo;
> > +}
> > +
> > +static int qcrypto_cryptodev_backend_builtin_create_cipher_session(
> > +QCryptoCryptoDevBackendBuiltin *builtin,
> > +QCryptoCryptoDevBackendSymSessionInfo
> *sess_info,
> > +Error **errp)
> > +{
> > +int algo;
> > +int mode;
> > +QCryptoCipher *cipher;
> > +int index;
> > +QCryptoCryptoDevBackendBuiltinSession *sess;
> > +
> > +if (sess_info->op_type != VIRTIO_CRYPTO_SYM_OP_CIPHER) {
> > +error_setg(errp, "unsupported optype :%u", sess_info->op_type);
> > +return -1;
> > +}
> > +
> > +index =
> qcrypto_cryptodev_backend_builtin_get_unused_session_index(builtin);
> 
> Feel free to omit the function name prefix for static functions.  These
> names are very long.
> 
> > +if (index < 0) {
> > +error_setg(errp, "the total number of created session
> exceed %u",
> 
> "Total number of sessions created exceeds %u"
> 
> > +  MAX_NUM_SESSIONS);
> > +return -1;
> > +}
> > +
> > +switch (sess_info->cipher_alg) {
> > +case VIRTIO_CRYPTO_CIPHER_AES_ECB:
> > +algo =
> qcrypto_cryptodev_backend_builtin_get_algo(sess_info->key_len,
> > +
> errp);
> > +if (algo < 0)  {
> > +return -1;
> > +}
> > +mode = QCRYPTO_CIPHER_MODE_ECB;
> > +break;
> > +case VIRTIO_CRYPTO_CIPHER_AES_CBC:
> > +algo =
> qcrypto_cryptodev_backend_builtin_get_algo(sess_info->key_len,
> > +
> errp);
> > +if (algo < 0)  {
> > +return -1;
> > +}
> > +mode = QCRYPTO_CIPHER_MODE_CBC;
> > +break;
> > +case VIRTIO_CRYPTO_CIPHER_AES_CTR:
> > +algo =
> qcrypto_cryptodev_backend_bui

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v4 02/13] cryptodev: add symmetric algorithm operation stuff

[Gonglei (Arei)]

> -Original Message-
> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Stefan Hajnoczi
> Sent: Tuesday, October 04, 2016 12:14 AM
> Subject: [virtio-dev] Re: [PATCH v4 02/13] cryptodev: add symmetric algorithm
> operation stuff
> 
> On Wed, Sep 28, 2016 at 04:25:41PM +0800, Gonglei wrote:
> > This patch add session operation and crypto operation
> 
> s/add/adds/
> 
> > stuff in the cryptodev backend, including function
> > pointers and correpsonding structures.
> 
> s/correpsonding/corresponding/
> 
> > +/**
> > + * QCryptoCryptoDevBackendSymOpInfo:
> > + *
> > + * @session_id: session index which was previously
> > + *  created by
> qcrypto_cryptodev_backend_sym_create_session()
> > + * @aad_len: byte length of additional authenticated data
> > + * @iv_len: byte length of initialization vector or counter
> > + * @src_len: byte length of source data
> > + * @dst_len: byte length of destination data, which is equal to
> > + *   src_len + hash_result_len if HASH alg configured
> > + * @op_type: operation type (refer to virtio_crypto.h)
> > + * @iv: pointer to the initialization vector or counter
> > + * @src: pointer to the source data
> > + * @dst: pointer to the destination data
> > + * @dst: pointer to the additional authenticated data
> 
> s/dst/aad_data/

OK, good catch, thanks!


Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v4 01/13] cryptodev: introduce cryptodev backend interface

[Gonglei (Arei)]

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Tuesday, October 04, 2016 12:11 AM
> Subject: Re: [PATCH v4 01/13] cryptodev: introduce cryptodev backend
> interface
> 
> On Wed, Sep 28, 2016 at 04:25:40PM +0800, Gonglei wrote:
> > diff --git a/backends/cryptodev.c b/backends/cryptodev.c
> > new file mode 100644
> > index 000..a15904b
> > --- /dev/null
> > +++ b/backends/cryptodev.c
> > @@ -0,0 +1,175 @@
> > +/*
> > + * QEMU Crypto Device Implement
> 
> s/Implement/Implementation/
> 
> > diff --git a/include/sysemu/cryptodev.h b/include/sysemu/cryptodev.h
> > new file mode 100644
> > index 000..cc3c3be
> > --- /dev/null
> > +++ b/include/sysemu/cryptodev.h
> > @@ -0,0 +1,145 @@
> > +/*
> > + * QEMU Crypto Device Implement
> 
> s/Implement/Implementation/
> 
OK.

> > + *
> > + * Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
> > + *
> > + * Authors:
> > + *Gonglei 
> > + *
> > + * This library is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2 of the License, or (at your option) any later version.
> > + *
> > + * This library is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with this library; if not, see
> .
> > + *
> > + */
> > +#ifndef QCRYPTO_CRYPTODEV_H
> > +#define QCRYPTO_CRYPTODEV_H
> > +
> > +#include "qom/object.h"
> > +#include "qemu-common.h"
> > +
> > +/**
> > + * QCryptoCryptoDevBackend:
> > + *
> > + * The QCryptoCryptoDevBackend object is an interface
> > + * for different cryptodev backends, which provides crypto
> > + * operation wrapper.
> 
> I suggest calling it CryptoDevBackend since that's shorter and doesn't
> repeat any information.  I'm not sure why "QCrypto" is necessary.
> 
Ok, and Daniel explained the reason in another reply. I'll rename those stuff.

> > + *
> > + */
> > +
> > +#define TYPE_QCRYPTO_CRYPTODEV_BACKEND "cryptodev-backend"
> > +
> > +#define QCRYPTO_CRYPTODEV_BACKEND(obj) \
> > +OBJECT_CHECK(QCryptoCryptoDevBackend, \
> > + (obj), TYPE_QCRYPTO_CRYPTODEV_BACKEND)
> > +#define QCRYPTO_CRYPTODEV_BACKEND_GET_CLASS(obj) \
> > +OBJECT_GET_CLASS(QCryptoCryptoDevBackendClass, \
> > + (obj), TYPE_QCRYPTO_CRYPTODEV_BACKEND)
> > +#define QCRYPTO_CRYPTODEV_BACKEND_CLASS(klass) \
> > +OBJECT_CLASS_CHECK(QCryptoCryptoDevBackendClass, \
> > +(klass), TYPE_QCRYPTO_CRYPTODEV_BACKEND)
> > +
> > +
> > +#define MAX_CRYPTO_QUEUE_NUM  64
> > +
> > +typedef struct QCryptoCryptoDevBackendConf
> QCryptoCryptoDevBackendConf;
> > +typedef struct QCryptoCryptoDevBackendPeers
> QCryptoCryptoDevBackendPeers;
> > +typedef struct QCryptoCryptoDevBackendClientState
> > + QCryptoCryptoDevBackendClientState;
> > +typedef struct QCryptoCryptoDevBackend QCryptoCryptoDevBackend;
> > +
> > +
> > +typedef struct QCryptoCryptoDevBackendClass {
> > +ObjectClass parent_class;
> > +
> > +void (*init)(QCryptoCryptoDevBackend *backend, Error **errp);
> > +void (*cleanup)(QCryptoCryptoDevBackend *backend, Error **errp);
> > +} QCryptoCryptoDevBackendClass;
> > +
> > +
> > +struct QCryptoCryptoDevBackendClientState {
> 
> The naming could be simplified: CryptoDevClient.
> 
> > +char *model;
> > +char *name;
> > +char info_str[128];
> 
> This should probably be char *info_str unless there is a specific reason
> to use a fixed-size buffer.
> 
OK.

> > +unsigned int queue_index;
> > +QTAILQ_ENTRY(QCryptoCryptoDevBackendClientState) next;
> > +};
> > +
> > +struct QCryptoCryptoDevBackendPeers {
> > +QCryptoCryptoDevBackendClientState
> *ccs[MAX_CRYPTO_QUEUE_NUM];
> > +uint32_t queues;
> > +};
> > +
> > +struct QCryptoCryptoDevBackendConf {
> > +QCryptoCryptoDevBackendPeers peers;
> > +
> > +/* Supported service mask */
> > +uint32_t crypto_services;
> > +
> > +/* Detailed algorithms mask */
> > +uint32_t cipher_algo_l;
> > +uint32_t cipher_algo_h;
> > +uint32_t hash_algo;
> > +uint32_t mac_algo_l;
> > +uint32_t mac_algo_h;
> > +uint32_t asym_algo;
> > +uint32_t kdf_algo;
> > +uint32_t aead_algo;
> > +uint32_t primitive_algo;
> > +};
> > +
> > +struct QCryptoCryptoDevBackend {
> > +Object parent_obj;
> > +
> > +int ready;
> 
> Please use bool.  That way it's clear the field only takes true and
> false values.
> 
OK.

> > +QCryptoCryptoDevBackendConf conf;
> > +};
> > +
> > +/**
> > + * qcrypto_cryptodev_backend_new_client:
> > + * @model: the cryptodev backend model
> > + * @name: the cryptodev backend

Re: [Qemu-devel] [PATCH v4 00/13] virtio-crypto: introduce framework and device emulation

[Gonglei (Arei)]

Ping...

Please help to review the patch set in order to catch up with the qemu-2.8' 
time window if possible. Thanks a lot!

Regards,
-Gonglei
发件人：龚磊
收件人：qemu-devel,virtio-...@lists.oasis-open.org,
抄送：骆能军,Michael S. Tsirkin,Stefan Hajnoczi,Paolo Bonzini,Daniel P. 
Berrange,黄伟栋,吴斌,Mihai Claudiu Caraman,Alexander Graf,Zeng, Xin,Claudio 
Fontana,Nicolas Morey-Chaisemartin,Vincent JARDIN,周健,韩伟东,黄鹏,龚磊,
时间：2016-09-28 16:26:20
主题:[PATCH v4 00/13] virtio-crypto: introduce framework and device emulation

The virtio crypto is a virtual crypto device as well as a kind
of virtual hardware accelerator for virtual machines. The
encryption and decryption requests are placed in the data
queue and handled by the real crypto accelerators finally.
The second queue is the control queue used to create or
destroy sessions for symmetric algorithms and control
some advanced features in the future. The virtio crypto
device provides the following crypto services: CIPHER,
MAC, HASH, AEAD etc.

TODO:
 - add vhost-user as a high performance cryptodev backend.
 - more crypto services support.
 - mirgration support.

Changes since v3:
 - rename cryptodev-gcrypt to cryptodev-buitlin. [Daniel]
 - move cryptodev stuff from crypto/ directory to backends/ directory
   in order to keep the crypto subsystem influence by syetem
   emulators. [Daniel]
 - emulate virtio-crypto device as a legacy device by default in patch 11
 - introduce virtio-crypto qtest case in patch 12
 - add myself as cryptdoev backends mainatainer and vitio-crypto
   co-maintainer in patch 13
 - add CRT support for cryptodev-builtin, it based on my previous crypto
   patch serial queued by Daniel.
   https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06607.html
 - add queue_index for qcrypto_cryptodev_backend_sym_close_session()

Changes since v2:
 According to Daniel's comments:
 - drop cryptodev kernel module as a cryptodev backend
 - rename crypto stuff to cryptodev stuff
 - change some files' license to GPLv2+
 - remove cryptodev command line instead of QOM to define the cryptodev backend
 - rename all functions and structures in crypto sub-directory.
 - add full inline documentation for cryptodev.h
 And:
 - drop crypto-queue.c [Paolo]
 - merge some patches

Great thanks to Daniel and Paolo. Please review again, thanks!

Changes since v1:
 - rmmove mixed endian-ness handler for virtio-crypto device, just
   use little-endian. [mst]
 - add sg list support according virtio-crypto spec v10 (will be posted soon).
 - fix a memory leak in session handler.
 - add a feature page link in qemu.org 
(http://qemu-project.org/Features/VirtioCrypto)
 - fix some trivial problems, sush as 's/Since 2.7/Since 2.8/g' in 
qapi-schema.json
 - rebase the latest qemu master tree.


This patch series realize the framework and emulation of a new
virtio crypto device, which is similar with virtio net device.

 - I introduce the cryptodev backend as the client of virtio crypto device
   which can be realized by different methods, such as cryptodev-backend-gcrypt 
in my series,
   vhost-crypto kernel module, vhost-user etc.
 - The patch set abides by the virtio crypto speccification.
 - The virtio crypto support symmetric algorithms (including CIPHER and 
algorithm chainning)
   at present, except HASH, MAC and AEAD services.
 - unsupport hot plug/unplug cryptodev backend at this moment.

Firstly build QEMU with libgcrypt cryptography support.

QEMU can then be started using the following parameters:

qemu-system-x86_64 \
[...] \
-object cryptodev-backend-builtin,id=cryptodev0 \
-device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \
[...]

The front-end linux kernel driver (Experimental at present) is publicly 
accessible from:

   https://github.com/gongleiarei/virtio-crypto-linux-driver.git

After insmod virtio-crypto.ko, you can use cryptodev-linux test the crypto 
function
in the guest. For example:

linux-guest:/home/gonglei/cryptodev-linux/tests # ./cipher -
requested cipher CRYPTO_AES_CBC, got cbc(aes) with driver virtio_crypto_aes_cbc
AES Test passed
requested cipher CRYPTO_AES_CBC, got cbc(aes) with driver virtio_crypto_aes_cbc
requested cipher CRYPTO_AES_CBC, got cbc(aes) with driver virtio_crypto_aes_cbc
Test passed

QEMU code also can be accessible from:

 https://github.com/gongleiarei/qemu.git

 branch virtio-crypto

For more information, please see:
 http://qemu-project.org/Features/VirtioCrypto


Gonglei (13):
  cryptodev: introduce cryptodev backend interface
  cryptodev: add symmetric algorithm operation stuff
  virtio-crypto: introduce virtio_crypto.h
  cryptodev: introduce a new cryptodev backend
  virtio-crypto: add virtio crypto device emulation
  virtio-crypto-pci: add virtio crypto pci support
  virtio-crypto: set capacity of algorithms supported
  virtio-crypto: add control queue handler
  virtio-crypto: add data queue processing handler
  cryptodev: introduce an unified wrapper for crypto operation
  virtio-crypto: emulate virtio crypt

Re: [Qemu-devel] [PATCH v4 00/13] virtio-crypto: introduce framework and device emulation

[Gonglei (Arei)]

> -Original Message-
> From: no-re...@patchew.org [mailto:no-re...@patchew.org]
> Sent: Wednesday, September 28, 2016 5:15 PM
> Subject: Re: [Qemu-devel] [PATCH v4 00/13] virtio-crypto: introduce framework
> and device emulation
> 
> Hi,
> 
> Your series failed automatic build test. Please find the testing commands and
> their output below. If you have docker installed, you can probably reproduce 
> it
> locally.
> 
>   CChw/acpi/pcihp.o
>   CChw/acpi/ich9.o
> /tmp/qemu-test/src/backends/cryptodev-builtin.c: In function
> ‘qcrypto_cryptodev_backend_builtin_create_cipher_session’:
> /tmp/qemu-test/src/backends/cryptodev-builtin.c:169: error:
> ‘QCRYPTO_CIPHER_MODE_CTR’ undeclared (first use in this function)
> /tmp/qemu-test/src/backends/cryptodev-builtin.c:169: error: (Each undeclared
> identifier is reported only once
> /tmp/qemu-test/src/backends/cryptodev-builtin.c:169: error: for each function
> it appears in.)
> make: *** [backends/cryptodev-builtin.o] Error 1
> make: *** Waiting for unfinished jobs
> tests/docker/Makefile.include:107: recipe for target
> 'docker-run-test-quick@centos6' failed
> make: *** [docker-run-test-quick@centos6] Error 2
> === OUTPUT END ===
> 
About CRT support for cryptodev-builtin, it based on my previous crypto
patch serial queued by Daniel.
 
 https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06607.html

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel

[Gonglei (Arei)]

> -Original Message-
> From: Fam Zheng [mailto:f...@redhat.com]
> Sent: Wednesday, September 28, 2016 9:45 AM
> To: Gonglei (Arei)
> Cc: Daniel P. Berrange; pbonz...@redhat.com; John Snow;
> qemu-devel@nongnu.org; Wubin (H)
> Subject: Re: [Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel
> 
> On Wed, 09/28 01:31, Gonglei (Arei) wrote:
> > # ./tests/virtio-net-test
> > **
> > ERROR:tests/libqtest.c:561:qtest_get_arch: assertion failed: (qemu != NULL)
> > Aborted (core dumped)
> >
> > # ./tests/virtio-blk-test
> > **
> > ERROR:tests/libqtest.c:561:qtest_get_arch: assertion failed: (qemu != NULL)
> > Aborted (core dumped)
> >
> > But they work after I set the environment variable to specify architecture:
> >
> > #
> QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 ./tests/virtio-n
> et-test
> > /x86_64/virtio/net/pci/basic: OK
> > /x86_64/virtio/net/pci/rx_stop_cont: OK
> > /x86_64/virtio/net/pci/hotplug: OK
> >
> > #
> QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 ./tests/virtio-b
> lk-test
> > /x86_64/virtio/blk/pci/basic: OK
> > /x86_64/virtio/blk/pci/indirect: OK
> > /x86_64/virtio/blk/pci/config: OK
> > /x86_64/virtio/blk/pci/msix: OK
> > /x86_64/virtio/blk/pci/idx: OK
> > /x86_64/virtio/blk/pci/hotplug: OK
> >
> > So, Maybe we should add check if the environment relied on is set
> > before executing specific operations in this kind of tests. Right?
> 
> Or make a guess based on $(realpath $0]) (in this case, print the found path 
> to
> avoid testing against wrong binary by mistake).
> 
What do you mean about the realpath? Can we use it to set the environment 
variable?

Regards,
-Gonglei

Re: [Qemu-devel] Questions about gcc linker errors in crypto sub-directory

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, September 27, 2016 8:52 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org
> Subject: Re: Questions about gcc linker errors in crypto sub-directory
> 
> On Mon, Sep 26, 2016 at 09:19:36AM +, Gonglei (Arei) wrote:
> > > -Original Message-
> > > From: Daniel P. Berrange [mailto:berra...@redhat.com]
> > > Sent: Monday, September 26, 2016 5:14 PM
> > > To: Gonglei (Arei)
> > > Cc: qemu-devel@nongnu.org
> > > Subject: Re: Questions about gcc linker errors in crypto sub-directory
> > >
> > > On Mon, Sep 26, 2016 at 09:03:45AM +, Gonglei (Arei) wrote:
> > > > Hi Daniel,
> > > >
> > > > I'm coding cryptodev-vhost-user.c as a new cryptodev backend,
> > > > but the gcc report some linker errors:
> > > >
> > > > crypto/cryptodev-vhost-user.o: In function
> > > `qcrypto_cryptodev_vhost_crypto_cleanup':
> > > > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:87:
> > > undefined reference to `vhost_dev_cleanup'
> > > > crypto/cryptodev-vhost-user.o: In function
> > > `qcrypto_cryptodev_vhost_crypto_init':
> > > > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:126:
> > > undefined reference to `vhost_dev_init'
> > > > crypto/cryptodev-vhost-user.o: In function
> > > `qcrypto_cryptodev_vhost_user_opened':
> > > > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:187:
> > > undefined reference to `qemu_chr_find'
> > > > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:194:
> > > undefined reference to `qemu_chr_fe_claim_no_fail'
> > > > crypto/cryptodev-vhost-user.o: In function
> > > `qcrypto_cryptodev_vhost_user_event':
> > > > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:213:
> > > undefined reference to `qemu_chr_set_reconnect_time'
> > > > crypto/cryptodev-vhost-user.o: In function
> > > `qcrypto_cryptodev_vhost_user_init':
> > > > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:257:
> > > undefined reference to `qemu_chr_add_handlers'
> > > > crypto/cryptodev-vhost-user.o: In function
> > > `qcrypto_cryptodev_vhost_user_finalize':
> > > > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:353:
> > > undefined reference to `qemu_chr_add_handlers'
> > > > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:354:
> > > undefined reference to `qemu_chr_fe_release'
> > > > collect2: ld returned 1 exit status
> > > > make: *** [qemu-nbd] Error 1
> > > >
> > > > Currently I only change the crypto/Makefile.objs:
> > > >
> > > > diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
> > > > index b9ad26a..575f64e 100644
> > > > --- a/crypto/Makefile.objs
> > > > +++ b/crypto/Makefile.objs
> > > > @@ -28,6 +28,7 @@ crypto-obj-y += block-qcow.o
> > > >  crypto-obj-y += block-luks.o
> > > >  crypto-obj-y += cryptodev.o
> > > >  crypto-obj-y += cryptodev-builtin.o
> > > > +crypto-obj-y += cryptodev-vhost-user.o
> > >
> > > The $(crypto-obj-y) variable is intended to only contain general purpose
> > > crypto code, since it needs to be linked to all QEMU programs. Your
> > > cryptodev file is specific to system emulators, so must only be linked
> > > to the system emulator targets. Thus, it should not be added to the
> > > crypto-obj-y variable.
> > >
> > > It probably needs to be added to either common-obj-y or obj-y - I can't
> > > remember which is "best"
> > >
> > common-obj-y is fine! So all cryptodev stuff should be use
> > $( crypto-obj-y) variable, right? I'll change them in the next version.
> 
> Looking at this again, it actually makes me think that your
> cryptodev stuff would be better in the backends/ directory.
> 
> That would mean the crypto/ directory is kept as the place for
> generic crypto infrastructure, and avoiding system emulator
> specific device backend code. The backends/Makefile.objs is
> already setup to use common-obj-y and builds various other
> device backend models.
> 
Sounds reasonable and make senses. At present situation, I need
to do below changes for crypto subdirectory:

diff --git a/Makefile.objs b/Makefile.objs
index 6d5ddcf..f1a8f13 100644
---

Re: [Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, September 27, 2016 6:15 PM
> To: Fam Zheng
> Cc: Gonglei (Arei); pbonz...@redhat.com; John Snow; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel
> 
> On Fri, Sep 23, 2016 at 05:59:05PM +0800, Fam Zheng wrote:
> > On Fri, 09/23 09:39, Gonglei (Arei) wrote:
> > >
> > > Hi Fam,
> > >
> > >
> > > > -Original Message-
> > > > From: Qemu-devel
> > > > [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On
> > > > Behalf Of Fam Zheng
> > > > Sent: Friday, September 23, 2016 3:58 PM
> > > > To: John Snow
> > > > Cc: pbonz...@redhat.com; qemu-devel@nongnu.org
> > > > Subject: Re: [Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel
> > > >
> > > > On Wed, 09/21 14:24, John Snow wrote:
> > > > >
> > > > >
> > > > > On 08/12/2016 05:19 AM, Fam Zheng wrote:
> > > > > > Previously all test cases in a category, such as check-qtest-y, are
> > > > > > executed in a single long gtester command. This patch separates each
> > > > > > test into its own make target to allow better parallism.
> > > > > >
> > >
> > > That's will be great if we can specify a test to run, especially for the
> scenario
> > > which add one use qtest case.
> > >
> > > For example:
> > >
> > >  # make check test-crypto-cipher
> > >
> > > then only run the tests/ test-crypto-cipher.
> > >
> > > Do you think it makes sense?
> >
> > Or more likely:
> >
> > # make check TESTS="test-crypto-cipher test-crypto-hash ..."
> >
> > Usually I just extract the gtester command line with V=1 and run it from my
> > shell prompt.  Feel free to send a patch, though.
> 
> Shouldn't even need todo that in most cases - I tend to just do
> 
>   make tests/test-crypto-cipher && ./tess/test-crypto-cipher
> 
> If there are tests which rely on some environment set by the Makefile,
> then really they should be fixed to have sensible defaults so that they
> can be directly executed.
> 
Thanks for your reminding! It works fine.

# ./tests/test-crypto-cipher 
/crypto/cipher/aes-ecb-128: OK
/crypto/cipher/aes-ecb-192: OK
/crypto/cipher/aes-ecb-256: OK
/crypto/cipher/aes-cbc-128: OK
/crypto/cipher/aes-cbc-192: OK
/crypto/cipher/aes-cbc-256: OK
/crypto/cipher/des-rfb-ecb-56: OK
/crypto/cipher/cast5-128: OK
/crypto/cipher/serpent-128: OK
/crypto/cipher/serpent-192: OK
/crypto/cipher/serpent-256a: OK
/crypto/cipher/serpent-256b: OK
/crypto/cipher/twofish-128: OK
/crypto/cipher/twofish-256: OK
/crypto/cipher/aes-xts-128-1: OK
/crypto/cipher/aes-xts-128-2: OK
/crypto/cipher/aes-xts-128-3: OK
/crypto/cipher/aes-xts-128-4: OK
/crypto/cipher/cast5-xts-128: OK
/crypto/cipher/aes-ctr-128: OK
/crypto/cipher/aes-ctr-192: OK
/crypto/cipher/aes-ctr-256: OK
/crypto/cipher/null-iv: OK
/crypto/cipher/short-plaintext: OK

# ./tests/virtio-net-test
**
ERROR:tests/libqtest.c:561:qtest_get_arch: assertion failed: (qemu != NULL)
Aborted (core dumped)

# ./tests/virtio-blk-test
**
ERROR:tests/libqtest.c:561:qtest_get_arch: assertion failed: (qemu != NULL)
Aborted (core dumped)

But they work after I set the environment variable to specify architecture:
 
# QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 ./tests/virtio-net-test
/x86_64/virtio/net/pci/basic: OK
/x86_64/virtio/net/pci/rx_stop_cont: OK
/x86_64/virtio/net/pci/hotplug: OK

# QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 ./tests/virtio-blk-test
/x86_64/virtio/blk/pci/basic: OK
/x86_64/virtio/blk/pci/indirect: OK
/x86_64/virtio/blk/pci/config: OK
/x86_64/virtio/blk/pci/msix: OK
/x86_64/virtio/blk/pci/idx: OK
/x86_64/virtio/blk/pci/hotplug: OK

So, Maybe we should add check if the environment relied on is set
before executing specific operations in this kind of tests. Right?

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v3 0/3] crypto: add ctr mode support and little inprovement

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, September 27, 2016 8:50 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Wubin (H)
> Subject: Re: [PATCH v3 0/3] crypto: add ctr mode support and little 
> inprovement
> 
> On Tue, Sep 27, 2016 at 09:32:10AM +, Gonglei (Arei) wrote:
> > Hi Daniel,
> >
> > I'll post virtio-crypto v4 based on this patch set.
> > Would you please merge it if it's ok? Thanks.
> >
> > Regards,
> > -Gonglei
> >
> >
> > > -Original Message-
> > > From: Gonglei (Arei)
> > > Sent: Monday, September 26, 2016 5:23 PM
> > > To: qemu-devel@nongnu.org
> > > Cc: berra...@redhat.com; Wubin (H); Gonglei (Arei)
> > > Subject: [PATCH v3 0/3] crypto: add ctr mode support and little 
> > > inprovement
> > >
> > > Please see the detailed description in each patch.
> > >
> > > v3:
> > >  - adjust the sequence of patch 1 and 2. (Daniel)
> > >  - fix a mising 'break' in code logic. (Daniel)
> > > v2:
> > >  - fix qtest complaint in cipher-builtin backend.
> > >  - introduce patch 2 and patch 3.
> > >
> > > Gonglei (3):
> > >   crypto: extend mode as a parameter in qcrypto_cipher_supports()
> > >   crypto: add CTR mode support
> > >   crypto: add mode check in qcrypto_cipher_new() for cipher-builtin
> > >
> > >  block/qcow.c   |  3 ++-
> > >  block/qcow2.c  |  3 ++-
> > >  crypto/cipher-builtin.c| 25 +++-
> > >  crypto/cipher-gcrypt.c | 38 +--
> > >  crypto/cipher-nettle.c | 28 +--
> > >  crypto/cipher.c|  1 +
> > >  include/crypto/cipher.h| 12 ++
> > >  qapi/crypto.json   |  3 ++-
> > >  tests/test-crypto-cipher.c | 57
> > > +-
> > >  ui/vnc.c   |  2 +-
> > >  10 files changed, 152 insertions(+), 20 deletions(-)
> 
> These 3 patches look good and pass my build tests, so I've added them
> to my crypto queue.
> 
Cool. There is another patch need to be picked up:

[PATCH v3] qtest: fix make check complaint in crypto module

Thanks,
-Gonglei

> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] Qtest virtio interfaces don't support virtio-1.0 devices

[Gonglei (Arei)]

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> Sent: Wednesday, September 28, 2016 12:27 AM
> To: Stefan Hajnoczi
> Cc: Gonglei (Arei); Cornelia Huck; qemu-devel@nongnu.org; Gerd Hoffmann;
> Wubin (H); m...@redhat.com
> Subject: Re: [Qemu-devel] Qtest virtio interfaces don't support virtio-1.0
> devices
> 
> On Mon, Sep 26, 2016 at 2:45 PM, Stefan Hajnoczi 
> wrote:
> > On Fri, Sep 23, 2016 at 09:19:57AM +, Gonglei (Arei) wrote:
> >> Based on the virtio-1.0 spec, the virtio pci devices' layout have been
> changed,
> >> such as PCI_SUBSYSTEM_ID and modern_mem_bar.
> >>
> >> But the current qtest still don't support the virtio-1.0 or later devices. 
> >> Such
> as virtio-gpu,
> >> Virtio-input and virtio-crypto devices.
> >>
> >> Refer to functions in tests/libqos/virtio-pci.c.
> >>
> >> Any plans to support them? Thanks!
> >
> > Patches welcome!  I'm not aware of anyone currently implementing VIRTIO
> > 1.0 support in libqos.
> 
> I have just added VIRTIO 1.0 support in libqos as an Outreachy
> December-March project idea:
> http://qemu-project.org/Outreachy_2016_DecemberMarch#VIRTIO_1.0_supp
> ort_in_libqos
> 
> Perhaps an intern will apply who wants to tackle this.
> 
> Stefan

Nice :)  It's indeed a good learning opportunity for non-worked people.


Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v3 0/3] crypto: add ctr mode support and little inprovement

[Gonglei (Arei)]

Hi Daniel,

I'll post virtio-crypto v4 based on this patch set. 
Would you please merge it if it's ok? Thanks.

Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Monday, September 26, 2016 5:23 PM
> To: qemu-devel@nongnu.org
> Cc: berra...@redhat.com; Wubin (H); Gonglei (Arei)
> Subject: [PATCH v3 0/3] crypto: add ctr mode support and little inprovement
> 
> Please see the detailed description in each patch.
> 
> v3:
>  - adjust the sequence of patch 1 and 2. (Daniel)
>  - fix a mising 'break' in code logic. (Daniel)
> v2:
>  - fix qtest complaint in cipher-builtin backend.
>  - introduce patch 2 and patch 3.
> 
> Gonglei (3):
>   crypto: extend mode as a parameter in qcrypto_cipher_supports()
>   crypto: add CTR mode support
>   crypto: add mode check in qcrypto_cipher_new() for cipher-builtin
> 
>  block/qcow.c   |  3 ++-
>  block/qcow2.c  |  3 ++-
>  crypto/cipher-builtin.c| 25 +++-
>  crypto/cipher-gcrypt.c | 38 +--
>  crypto/cipher-nettle.c | 28 +--
>  crypto/cipher.c|  1 +
>  include/crypto/cipher.h| 12 ++
>  qapi/crypto.json   |  3 ++-
>  tests/test-crypto-cipher.c | 57
> +-
>  ui/vnc.c   |  2 +-
>  10 files changed, 152 insertions(+), 20 deletions(-)
> 
> --
> 1.7.12.4
> 

Re: [Qemu-devel] Questions about gcc linker errors in crypto sub-directory

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Monday, September 26, 2016 5:14 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org
> Subject: Re: Questions about gcc linker errors in crypto sub-directory
> 
> On Mon, Sep 26, 2016 at 09:03:45AM +, Gonglei (Arei) wrote:
> > Hi Daniel,
> >
> > I'm coding cryptodev-vhost-user.c as a new cryptodev backend,
> > but the gcc report some linker errors:
> >
> > crypto/cryptodev-vhost-user.o: In function
> `qcrypto_cryptodev_vhost_crypto_cleanup':
> > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:87:
> undefined reference to `vhost_dev_cleanup'
> > crypto/cryptodev-vhost-user.o: In function
> `qcrypto_cryptodev_vhost_crypto_init':
> > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:126:
> undefined reference to `vhost_dev_init'
> > crypto/cryptodev-vhost-user.o: In function
> `qcrypto_cryptodev_vhost_user_opened':
> > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:187:
> undefined reference to `qemu_chr_find'
> > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:194:
> undefined reference to `qemu_chr_fe_claim_no_fail'
> > crypto/cryptodev-vhost-user.o: In function
> `qcrypto_cryptodev_vhost_user_event':
> > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:213:
> undefined reference to `qemu_chr_set_reconnect_time'
> > crypto/cryptodev-vhost-user.o: In function
> `qcrypto_cryptodev_vhost_user_init':
> > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:257:
> undefined reference to `qemu_chr_add_handlers'
> > crypto/cryptodev-vhost-user.o: In function
> `qcrypto_cryptodev_vhost_user_finalize':
> > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:353:
> undefined reference to `qemu_chr_add_handlers'
> > /mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:354:
> undefined reference to `qemu_chr_fe_release'
> > collect2: ld returned 1 exit status
> > make: *** [qemu-nbd] Error 1
> >
> > Currently I only change the crypto/Makefile.objs:
> >
> > diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
> > index b9ad26a..575f64e 100644
> > --- a/crypto/Makefile.objs
> > +++ b/crypto/Makefile.objs
> > @@ -28,6 +28,7 @@ crypto-obj-y += block-qcow.o
> >  crypto-obj-y += block-luks.o
> >  crypto-obj-y += cryptodev.o
> >  crypto-obj-y += cryptodev-builtin.o
> > +crypto-obj-y += cryptodev-vhost-user.o
> 
> The $(crypto-obj-y) variable is intended to only contain general purpose
> crypto code, since it needs to be linked to all QEMU programs. Your
> cryptodev file is specific to system emulators, so must only be linked
> to the system emulator targets. Thus, it should not be added to the
> crypto-obj-y variable.
> 
> It probably needs to be added to either common-obj-y or obj-y - I can't
> remember which is "best"
> 
common-obj-y is fine! So all cryptodev stuff should be use 
$( crypto-obj-y) variable, right? I'll change them in the next version. 

Thank you so much!

Regards,
-Gonglei

> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

[Qemu-devel] Questions about gcc linker errors in crypto sub-directory

[Gonglei (Arei)]

Hi Daniel,

I'm coding cryptodev-vhost-user.c as a new cryptodev backend,
but the gcc report some linker errors:

crypto/cryptodev-vhost-user.o: In function 
`qcrypto_cryptodev_vhost_crypto_cleanup':
/mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:87: undefined 
reference to `vhost_dev_cleanup'
crypto/cryptodev-vhost-user.o: In function 
`qcrypto_cryptodev_vhost_crypto_init':
/mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:126: undefined 
reference to `vhost_dev_init'
crypto/cryptodev-vhost-user.o: In function 
`qcrypto_cryptodev_vhost_user_opened':
/mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:187: undefined 
reference to `qemu_chr_find'
/mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:194: undefined 
reference to `qemu_chr_fe_claim_no_fail'
crypto/cryptodev-vhost-user.o: In function `qcrypto_cryptodev_vhost_user_event':
/mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:213: undefined 
reference to `qemu_chr_set_reconnect_time'
crypto/cryptodev-vhost-user.o: In function `qcrypto_cryptodev_vhost_user_init':
/mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:257: undefined 
reference to `qemu_chr_add_handlers'
crypto/cryptodev-vhost-user.o: In function 
`qcrypto_cryptodev_vhost_user_finalize':
/mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:353: undefined 
reference to `qemu_chr_add_handlers'
/mnt/sdb/gonglei/qemu.git/qemu/crypto/cryptodev-vhost-user.c:354: undefined 
reference to `qemu_chr_fe_release'
collect2: ld returned 1 exit status
make: *** [qemu-nbd] Error 1

Currently I only change the crypto/Makefile.objs:

diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index b9ad26a..575f64e 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -28,6 +28,7 @@ crypto-obj-y += block-qcow.o
 crypto-obj-y += block-luks.o
 crypto-obj-y += cryptodev.o
 crypto-obj-y += cryptodev-builtin.o
+crypto-obj-y += cryptodev-vhost-user.o
 
 # Let the userspace emulators avoid linking gnutls/etc
 crypto-aes-obj-y = aes.o

Any others do I need to change? Thanks!

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v2 0/3] crypto: add ctr mode support and little inprovement

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Monday, September 26, 2016 4:15 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; f...@redhat.com; Wubin (H)
> Subject: Re: [Qemu-devel] [PATCH v2 0/3] crypto: add ctr mode support and
> little inprovement
> 
> On Sat, Sep 24, 2016 at 02:29:16AM +, Gonglei (Arei) wrote:
> >
> >
> > > -Original Message-
> > > From: no-re...@patchew.org [mailto:no-re...@patchew.org]
> > > Sent: Saturday, September 24, 2016 10:22 AM
> > > To: Gonglei (Arei)
> > > Cc: f...@redhat.com; qemu-devel@nongnu.org; Gonglei (Arei); Wubin (H)
> > > Subject: Re: [Qemu-devel] [PATCH v2 0/3] crypto: add ctr mode support and
> > > little inprovement
> > >
> > > Hi,
> > >
> > > Your series failed automatic build test. Please find the testing commands
> and
> > > their output below. If you have docker installed, you can probably 
> > > reproduce
> it
> > > locally.
> > >
> 
> > > GTESTER tests/test-crypto-cipher
> > > GTESTER tests/test-crypto-secret
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > Unexpected error in qcrypto_cipher_new() at
> > > /tmp/qemu-test/src/crypto/cipher-builtin.c:442:
> > > Unsupported cipher mode cbc
> > > GTester: last random seed: R02S728541368fda15b567d6152f14684330
> > > GTester: last random seed: R02S03fa5a3e38035a395de344b8486a8d96
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > Unexpected error in qcrypto_cipher_new() at
> > > /tmp/qemu-test/src/crypto/cipher-builtin.c:442:
> > > Unsupported cipher mode cbc
> > > GTester: last random seed: R02Sa1d40c315665a972d0077ab62786a4a9
> > > GTester: last random seed: R02Sd6a1af04334fbd0a715b89b4c4770e2e
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > make: *** [check-tests/test-crypto-secret] Error 1
> > > make: *** Waiting for unfinished jobs
> > > GTester: last random seed: R02S8309a8b2773c5611f6b2da378e7a76fb
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > GTester: last random seed: R02Safb17e9ffefc1c5c3e45211d6509b7d0
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > GTester: last random seed: R02S770f50b2a35e94c39875d1aee5da7371
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > GTester: last random seed: R02S3ee10e29160387b498cf0e181611c0fc
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > GTester: last random seed: R02S11f675b1e67013a797f4b6eabacf4e53
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > GTester: last random seed: R02S850eea2a24a4ee7f9ec2a8d8fc5aa91c
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > GTester: last random seed: R02S437d1a4318a6aeb4a49d62fb22e8fc95
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > GTester: last random seed: R02S7184a8a8cd35b2faade67bee6ba6e241
> > > **
> > > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> > > assertion failed: (err == NULL)
> > > GTester: last random seed: R02Sb0f61d1d0330a6c210a76f0caa25f991
> > > Unexpected error in qcrypto_cipher_new() at
> > > /tmp/qemu-test/src/crypto/cipher-builtin.c:442:
> > > Unsupported cipher mode cbc
> > > GTester: last random seed: R02S94f3d34298a0e4548a72dfce873f2362
> > > Unexpected error in qcrypto_cipher_new() at
> > > /tmp/qemu-test/src/crypto/cipher-builtin.c:442:
> > > Unsupported cipher mode cbc
> > > GTester: last random seed: R02S38bab4972cc5f7d592fecf71ba1705b4
> > > make: *** [check-tests/test-crypto-cipher] Error 1
> > > tests/docker/Makefile.include:107: recipe for target
> > > 'docker-run-test-quick@centos6' failed
> > > make: *** [docker-run-test-quick@centos6] Error 2
> > > === OUTPUT END ===
> > >
> > > Test command exited with code: 2
> > >
> > It is fixed by Patch 2 in the same patch serials.
> 
> It is broken by patch 3 though
> 
> When you re-send, can you put patch 1 after patch 2, so that the series
> is friendly to git bisect
> 
OK. Will do.


Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v2 3/3] crypto: add mode check in qcrypto_cipher_new() for cipher-builtin

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Monday, September 26, 2016 4:14 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Wubin (H)
> Subject: Re: [PATCH v2 3/3] crypto: add mode check in qcrypto_cipher_new() for
> cipher-builtin
> 
> On Sat, Sep 24, 2016 at 10:10:00AM +0800, Gonglei wrote:
> > Signed-off-by: Gonglei 
> > ---
> >  crypto/cipher-builtin.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/crypto/cipher-builtin.c b/crypto/cipher-builtin.c
> > index fd59a9e..d710608 100644
> > --- a/crypto/cipher-builtin.c
> > +++ b/crypto/cipher-builtin.c
> > @@ -433,6 +433,16 @@ QCryptoCipher
> *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
> >  {
> >  QCryptoCipher *cipher;
> >
> > +switch (mode) {
> > +case QCRYPTO_CIPHER_MODE_ECB:
> > +case QCRYPTO_CIPHER_MODE_CBC:
> > +case QCRYPTO_CIPHER_MODE_XTS:
> 
> Presumably you intended to have 'break' here, otherwise this
> code rejects everything
> 
Oops, my fault  :(


Regards,
-Gonglei

> > +default:
> > +error_setg(errp, "Unsupported cipher mode %s",
> > +   QCryptoCipherMode_lookup[mode]);
> > +return NULL;
> > +}
> > +
> >  cipher = g_new0(QCryptoCipher, 1);
> >  cipher->alg = alg;
> >  cipher->mode = mode;
> 
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v10 0/2] virtio-crypto: virtio crypto device specification

[Gonglei (Arei)]

Hi Michael,

Thanks for your feedback.

> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Michael S. Tsirkin
> Sent: Monday, September 26, 2016 10:58 AM
> Subject: [virtio-dev] Re: [PATCH v10 0/2] virtio-crypto: virtio crypto device
> specification
> 
> On Mon, Sep 26, 2016 at 01:15:48AM +, Gonglei (Arei) wrote:
> > Hi,
> >
> > Virtio-1 device (virtio_pci_modern) is supported since 2015 in Linux 
> > kernel, so
> > that lots of existing Guest can't support virtio-1.0 device.
> > But the scenario of
> > virtio crypto device is mostly NFV, which require the existing Guest can't 
> > need
> > to do any changes to support virtio crypto, so that they can easily migrate 
> > the
> > existing network units to VM. That's also a basic requirement came from our
> > customers.
> 
> If you require support for existing guests, you need to emulate a
> device they already support. Whatever you do with virtio crypto
> spec won't achieve this.
> 
> Hopefully you can load a virtio crypto driver module in the guest.
> If you can, load a 1.1 driver. If you can't you can't use the device
> whatever we do in the spec.
> 

For virtio crypto driver, we can both support virtio-1.0 or earlier. But
Virtio pci driver module can't discovery the virtio-1.0 devices in the
existing Guests. So, If we want do this, we have to require the customers
change the virtio pci module for existing guests influence all virtio devices,
which is too difficult. 

> > So I'd like to emulate the virtio crypto device as a transitional device by
> default
> > (Of course you can easily emulate it as a modern device by
> > 'disable-legacy=on disable-modren = off'), then it's require a transitional 
> > PCI
> device ID.
> > I want to reserve 0x1014 (20) because virtio crypto device ID is 20.
> >
> > What's your opinion? Thanks!
> >
> > If your don't object it, I'll add this in next virtio crypto spec version 
> > and update
> > corresponding code in QEMU.
> >
> > Regards,
> > -Gonglei
> 
> Legacy is for existing devices, we don't want to add to this baggage IMHO.
> 
> In particular, guests should be able to assume that all legacy and
> transitional device IDs are known and listed in spec 1.0, chapter Device
> Requirements: PCI Device Discovery.
> 

So can we don't change the spec, only assign the virito crypto pci ID in Qemu?
Just like what virtio vsock does?

Regards,
-Gonglei

> >
> >
> > > -Original Message-
> > > From: Gonglei (Arei)
> > > Sent: Tuesday, September 20, 2016 5:46 PM
> > > To: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org
> > > Cc: Huangpeng (Peter); Luonengjun; m...@redhat.com;
> > > cornelia.h...@de.ibm.com; stefa...@redhat.com;
> > > denglin...@chinamobile.com; Jani Kokkonen; ola.liljed...@arm.com;
> > > varun.se...@freescale.com; xin.z...@intel.com;
> brian.a.keat...@intel.com;
> > > liang.j...@intel.com; john.grif...@intel.com; Hanweidong (Randy);
> > > Huangweidong (C); mike.cara...@nxp.com; ag...@suse.de; Claudio
> Fontana;
> > > Zhoujian (jay, Euler); nmo...@kalray.eu; vincent.jar...@6wind.com; Wubin
> (H);
> > > Gonglei (Arei)
> > > Subject: [PATCH v10 0/2] virtio-crypto: virtio crypto device specification
> > >
> > > This is the specification about a new virtio crypto device.
> > >
> > > You can get the source code from the below website:
> > >
> > > [PATCH v3 00/10] virtio-crypto: introduce framework and device emulation
> > >  https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04132.html
> > >
> > > Please help to review, thanks.
> > >
> > > 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 
> > > CC: Mihai Claudiu Caraman 
> > >
> > > Changes since v9:
> > >  - request a native speaker go over the text and fix corresponding
> grammar
> > > issues. [mst]
> > >  - make some description more appropriated over here and there. [mst]
> > >  - rewrite some requirement for both device and driver. [mst]
> > >  - use RFC 2119 keywords. [mst]
> > >  - fix some complaints by Xelatex and typoes. [Xin Zeng]
&g

Re: [Qemu-devel] [PATCH v10 0/2] virtio-crypto: virtio crypto device specification

[Gonglei (Arei)]

Hi,

Virtio-1 device (virtio_pci_modern) is supported since 2015 in Linux kernel, so
that lots of existing Guest can't support virtio-1.0 device. But the scenario of
virtio crypto device is mostly NFV, which require the existing Guest can't need 
to do any changes to support virtio crypto, so that they can easily migrate the
existing network units to VM. That's also a basic requirement came from our
customers.

So I'd like to emulate the virtio crypto device as a transitional device by 
default
(Of course you can easily emulate it as a modern device by
'disable-legacy=on disable-modren = off'), then it's require a transitional PCI 
device ID.
I want to reserve 0x1014 (20) because virtio crypto device ID is 20.

What's your opinion? Thanks!

If your don't object it, I'll add this in next virtio crypto spec version and 
update
corresponding code in QEMU.

Regards,
-Gonglei



> -Original Message-
> From: Gonglei (Arei)
> Sent: Tuesday, September 20, 2016 5:46 PM
> To: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org
> Cc: Huangpeng (Peter); Luonengjun; m...@redhat.com;
> cornelia.h...@de.ibm.com; stefa...@redhat.com;
> denglin...@chinamobile.com; Jani Kokkonen; ola.liljed...@arm.com;
> varun.se...@freescale.com; xin.z...@intel.com; brian.a.keat...@intel.com;
> liang.j...@intel.com; john.grif...@intel.com; Hanweidong (Randy);
> Huangweidong (C); mike.cara...@nxp.com; ag...@suse.de; Claudio Fontana;
> Zhoujian (jay, Euler); nmo...@kalray.eu; vincent.jar...@6wind.com; Wubin (H);
> Gonglei (Arei)
> Subject: [PATCH v10 0/2] virtio-crypto: virtio crypto device specification
> 
> This is the specification about a new virtio crypto device.
> 
> You can get the source code from the below website:
> 
> [PATCH v3 00/10] virtio-crypto: introduce framework and device emulation
>  https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04132.html
> 
> Please help to review, thanks.
> 
> 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 
> CC: Mihai Claudiu Caraman 
> 
> Changes since v9:
>  - request a native speaker go over the text and fix corresponding grammar
> issues. [mst]
>  - make some description more appropriated over here and there. [mst]
>  - rewrite some requirement for both device and driver. [mst]
>  - use RFC 2119 keywords. [mst]
>  - fix some complaints by Xelatex and typoes. [Xin Zeng]
>  - add scatter/getter chain support for possible large block data.
> 
> Thanks for your review, Michael and Xin.
> 
> Changes from v8:
>  - add additional auth gpa and length to struct virtio_crypto_sym_data_req;
>  - add definition of op in struct virtio_crypto_cipher_session_para,
>   VIRTIO_CRYPTO_OP_ENCRYPT and VIRTIO_CRYPTO_OP_DECRYPT;
>  - make all structures 64bit aligned in order to support different
>   architectures more conveniently [Alex & Stefan]
>  - change to devicenormative{\subsection} and \drivernormative{\subsection}
> in some sections [Stefan]
>  - driver does not have to initialize all data virtqueues if it wants to use 
> fewer
> [Stefan]
>  - drop VIRTIO_CRYPTO_NO_SERVICE definition [Stefan]
>  - many grammatical problems and typos. [Stefan]
>  - rename VIRTIO_CRYPTO_MAC_CMAC_KASUMI_F9 to
> VIRTIO_CRYPTO_MAC_CMAC_KASUMI_F9,
>   and VIRTIO_CRYPTO_MAC_CMAC_SNOW3G_UIA2 to
> VIRTIO_CRYPTO_MAC_SNOW3G_UIA2. [Liang Ma]
>  - drop queue_id property of struct virtio_crypto_op_data_req.
>  - reconstruct some structures about session operation request.
>  - introduce struct virtio_crypto_alg_chain_session_req and struct
> virtio_crypto_alg_chain_data_req,
>   introduce chain para, output, input structures as well.
>  - change some sections' layout for better compatibility, for asymmetric 
> algos.
> [Xin Zeng]
> 
> Changes from v7:
>  - fix some grammar or typo problems.
>  - add more detailed description at steps of encryption section.
> 
> Changes from v6:
>  - drop verion filed in struct virtio_crypto_config. [Michael & Cornelia]
>  - change the incorrect description in initialization routine. [Zeng Xin]
>  - redefine flag u16 to make structure alignment. [Zeng Xin]
>  - move the content of virtio_crypto_hash_session_para into
>virtio_crypto_hash_session_input directly, Same to MAC/SYM/AEAD
> session creation. [Zeng Xin]
>  - adjuest the sequence of idata and odata refer to the virtio scsi parts,
>meanwhile add the comments of device-readable/writable for them.
>  - add restrictive documents for the guest memory in some structure, which
>MUST be gaurante

Re: [Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel

[Gonglei (Arei)]

> -Original Message-
> From: Fam Zheng [mailto:f...@redhat.com]
> Sent: Friday, September 23, 2016 5:59 PM
> To: Gonglei (Arei)
> Cc: John Snow; pbonz...@redhat.com; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel
> 
> On Fri, 09/23 09:39, Gonglei (Arei) wrote:
> >
> > Hi Fam,
> >
> >
> > > -Original Message-
> > > From: Qemu-devel
> > > [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On
> > > Behalf Of Fam Zheng
> > > Sent: Friday, September 23, 2016 3:58 PM
> > > To: John Snow
> > > Cc: pbonz...@redhat.com; qemu-devel@nongnu.org
> > > Subject: Re: [Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel
> > >
> > > On Wed, 09/21 14:24, John Snow wrote:
> > > >
> > > >
> > > > On 08/12/2016 05:19 AM, Fam Zheng wrote:
> > > > > Previously all test cases in a category, such as check-qtest-y, are
> > > > > executed in a single long gtester command. This patch separates each
> > > > > test into its own make target to allow better parallism.
> > > > >
> >
> > That's will be great if we can specify a test to run, especially for the 
> > scenario
> > which add one use qtest case.
> >
> > For example:
> >
> >  # make check test-crypto-cipher
> >
> > then only run the tests/ test-crypto-cipher.
> >
> > Do you think it makes sense?
> 
> Or more likely:
> 
> # make check TESTS="test-crypto-cipher test-crypto-hash ..."
> 
> Usually I just extract the gtester command line with V=1 and run it from my
> shell prompt.  Feel free to send a patch, though.
> 
Sorry, I have no patch for this, it's just my idea ;)
Appreciate it if you can realize it. 

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v2 0/3] crypto: add ctr mode support and little inprovement

[Gonglei (Arei)]

> -Original Message-
> From: no-re...@patchew.org [mailto:no-re...@patchew.org]
> Sent: Saturday, September 24, 2016 10:22 AM
> To: Gonglei (Arei)
> Cc: f...@redhat.com; qemu-devel@nongnu.org; Gonglei (Arei); Wubin (H)
> Subject: Re: [Qemu-devel] [PATCH v2 0/3] crypto: add ctr mode support and
> little inprovement
> 
> Hi,
> 
> Your series failed automatic build test. Please find the testing commands and
> their output below. If you have docker installed, you can probably reproduce 
> it
> locally.
> 
> Type: series
> Message-id: 1474683000-346560-1-git-send-email-arei.gong...@huawei.com
> Subject: [Qemu-devel] [PATCH v2 0/3] crypto: add ctr mode support and little
> inprovement
> 
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> set -e
> git submodule update --init dtc
> make J=8 docker-test-quick@centos6
> make J=8 docker-test-mingw@fedora
> === TEST SCRIPT END ===
> 
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> From https://github.com/patchew-project/qemu
>  * [new tag]
> patchew/1474683000-346560-1-git-send-email-arei.gong...@huawei.com ->
> patchew/1474683000-346560-1-git-send-email-arei.gong...@huawei.com
> Switched to a new branch 'test'
> 9080eef crypto: add mode check in qcrypto_cipher_new() for cipher-builtin
> 91179fc crypto: extend mode as a parameter in qcrypto_cipher_supports()
> 87948de crypto: add CTR mode support
> 
> === OUTPUT BEGIN ===
> Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
> Cloning into 'dtc'...
> Submodule path 'dtc': checked out
> '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
>   BUILD centos6
>   ARCHIVE qemu.tgz
>   ARCHIVE dtc.tgz
>   COPY RUNNER
>   RUN test-quick in centos6
> Configure options:
> --enable-werror --target-list=x86_64-softmmu,aarch64-softmmu
> --prefix=/tmp/qemu-test/src/tests/docker/install
> No C++ compiler available; disabling C++ specific optional code
> Install prefix/tmp/qemu-test/src/tests/docker/install
> BIOS directory/tmp/qemu-test/src/tests/docker/install/share/qemu
> binary directory  /tmp/qemu-test/src/tests/docker/install/bin
> library directory /tmp/qemu-test/src/tests/docker/install/lib
> module directory  /tmp/qemu-test/src/tests/docker/install/lib/qemu
> libexec directory /tmp/qemu-test/src/tests/docker/install/libexec
> include directory /tmp/qemu-test/src/tests/docker/install/include
> config directory  /tmp/qemu-test/src/tests/docker/install/etc
> local state directory   /tmp/qemu-test/src/tests/docker/install/var
> Manual directory  /tmp/qemu-test/src/tests/docker/install/share/man
> ELF interp prefix /usr/gnemul/qemu-%M
> Source path   /tmp/qemu-test/src
> C compilercc
> Host C compiler   cc
> C++ compiler
> Objective-C compiler cc
> ARFLAGS   rv
> CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
> -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -g
> QEMU_CFLAGS   -I/usr/include/pixman-1-fPIE -DPIE -m64
> -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
> -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels
> -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security
> -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration
> -Wold-style-definition -Wtype-limits -fstack-protector-all
> LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
> make  make
> install   install
> pythonpython -B
> smbd  /usr/sbin/smbd
> module supportno
> host CPU  x86_64
> host big endian   no
> target list   x86_64-softmmu aarch64-softmmu
> tcg debug enabled no
> gprof enabled no
> sparse enabledno
> strip binariesyes
> profiler  no
> static build  no
> pixmansystem
> SDL support   yes (1.2.14)
> GTK support   no
> GTK GL supportno
> VTE support   no
> TLS priority  NORMAL
> GNUTLS supportno
> GNUTLS rndno
> libgcrypt no
> libgcrypt kdf no
> nettleno
> nettle kdfno
> libtasn1  no
> curses supportno
> virgl support no
> curl support  no
> mingw32 support   no
> Audio drivers oss
> Block whitelist (rw)
> Block whitelist (ro)
> VirtFS supportno
> VNC support   yes
> VNC SASL support  no
> VNC JPEG support  no
> VNC PNG support   no
> xen support   no
> brlapi supportno
> bluez  supportno
> Documentation no
> PIE   yes
> vde support   no
> netmap suppo

Re: [Qemu-devel] [PATCH v2] qtest: fix make check complaint in crypto module

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Friday, September 23, 2016 6:21 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Wubin (H)
> Subject: Re: [PATCH v2] qtest: fix make check complaint in crypto module
> 
> On Thu, Sep 22, 2016 at 04:56:39PM +0800, Gonglei wrote:
> >   CCtests/test-crypto-tlscredsx509.o
> >   CCtests/crypto-tls-x509-helpers.o
> >   CCtests/pkix_asn1_tab.o
> > tests/pkix_asn1_tab.c:7:22: warning: libtasn1.h: No such file or directory
> > tests/pkix_asn1_tab.c:9: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
> ‘__attribute__’ before ‘pkix_asn1_tab’
> > make: *** [tests/pkix_asn1_tab.o] Error 1
> >
> > Signed-off-by: Gonglei 
> > ---
> >  v2: add condition check for TLS support (Daniel)
> > ---
> >  tests/pkix_asn1_tab.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/tests/pkix_asn1_tab.c b/tests/pkix_asn1_tab.c
> > index 903bc02..036e222b 100644
> > --- a/tests/pkix_asn1_tab.c
> > +++ b/tests/pkix_asn1_tab.c
> > @@ -4,6 +4,14 @@
> >   */
> >
> >  #include "qemu/osdep.h"
> > +#if !(defined WIN32) && \
> > +defined(CONFIG_TASN1) && \
> > +(LIBGNUTLS_VERSION_NUMBER >= 0x020600)
> > +#define QCRYPTO_HAVE_TLS_TEST_SUPPORT
> > +#endif
> 
> This doesn't actually build
> 
> tests/pkix_asn1_tab.c:9:6: error: "LIBGNUTLS_VERSION_NUMBER" is not
> defined [-Werror=undef]
>  (LIBGNUTLS_VERSION_NUMBER >= 0x020600)
>   ^~~~
> cc1: all warnings being treated as errors
> /home/berrange/src/virt/qemu/rules.mak:60: recipe for target
> 'tests/pkix_asn1_tab.o' failed
> make: *** [tests/pkix_asn1_tab.o] Error 1
> 
Oops, I didn't encounter it because CONFIG_TASN1 is not defined in my 
environment.

> 
> This is because you missed the gnutls.h include. Rather than
> repeating the condition here, you sould just #include the
> existing tests/crypto-tls-x509-helpers.h header
> 
Yes, you are definitely right, thanks! V3 will come. 

Regards,
-Gonglei

> > +
> > +#ifdef QCRYPTO_HAVE_TLS_TEST_SUPPORT
> > +
> >  #include 
> >
> >  const ASN1_ARRAY_TYPE pkix_asn1_tab[] = {
> > @@ -1103,3 +,4 @@ const ASN1_ARRAY_TYPE pkix_asn1_tab[] = {
> >{0, 1048586, "2"},
> >{0, 0, 0}
> >  };
> > +#endif /* QCRYPTO_HAVE_TLS_TEST_SUPPORT */
> > --
> 
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel

[Gonglei (Arei)]

Hi Fam,


> -Original Message-
> From: Qemu-devel
> [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On
> Behalf Of Fam Zheng
> Sent: Friday, September 23, 2016 3:58 PM
> To: John Snow
> Cc: pbonz...@redhat.com; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel
> 
> On Wed, 09/21 14:24, John Snow wrote:
> >
> >
> > On 08/12/2016 05:19 AM, Fam Zheng wrote:
> > > Previously all test cases in a category, such as check-qtest-y, are
> > > executed in a single long gtester command. This patch separates each
> > > test into its own make target to allow better parallism.
> > >

That's will be great if we can specify a test to run, especially for the 
scenario
which add one use qtest case.

For example: 

 # make check test-crypto-cipher

then only run the tests/ test-crypto-cipher. 

Do you think it makes sense?

Regards,
-Gonglei

> > > Signed-off-by: Fam Zheng 
> > > ---
> > >
> > > This saves 50% of the time "make check takes" compared to on master
> > > (I use -j8). RFC because I'm not sure if the new gcov usage is correct
> > > with the now much higher level of parallism compared to before.
> > > ---
> > >  tests/Makefile.include | 34 ++
> > >  1 file changed, 18 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/tests/Makefile.include b/tests/Makefile.include
> > > index 14be491..9bf0326 100644
> > > --- a/tests/Makefile.include
> > > +++ b/tests/Makefile.include
> > > @@ -691,27 +691,29 @@ GCOV_OPTIONS = -n $(if $(V),-f,)
> > >  # gtester tests, possibly with verbose output
> > >
> > >  .PHONY: $(patsubst %, check-qtest-%, $(QTEST_TARGETS))
> > > -$(patsubst %, check-qtest-%, $(QTEST_TARGETS)): check-qtest-%:
> $(check-qtest-y)
> > > +
> > > +qtest-run-%: tests/%
> > >   $(if $(CONFIG_GCOV),@rm -f *.gcda */*.gcda */*/*.gcda
> */*/*/*.gcda,)
> > > - $(call
> quiet-command,QTEST_QEMU_BINARY=$*-softmmu/qemu-system-$* \
> > > + $(call quiet-command,\
> > > + $(if $(QTEST_TARGET), \
> > > +
>   QTEST_QEMU_BINARY=$(QTEST_TARGET)-softmmu/qemu-system-$(QTE
> ST_TARGET)) \
> > >   QTEST_QEMU_IMG=qemu-img$(EXESUF) \
> > >   MALLOC_PERTURB_=$${MALLOC_PERTURB_:-$$((RANDOM %
> 255 + 1))} \
> > > - gtester $(GTESTER_OPTIONS) -m=$(SPEED) $(check-qtest-$*-y)
> $(check-qtest-generic-y),"GTESTER $@")
> > > - $(if $(CONFIG_GCOV),@for f in $(gcov-files-$*-y) 
> > > $(gcov-files-generic-y);
> do \
> > > -   echo Gcov report for $$f:;\
> > > -   $(GCOV) $(GCOV_OPTIONS) $$f -o `dirname $$f`; \
> > > - done,)
> > > + gtester $< $(GTESTER_OPTIONS) -m=$(SPEED),"GTESTER $<")
> > > + $(if $(CONFIG_GCOV), @echo Gcov report for $<:;\
> > > +   $(GCOV) $(GCOV_OPTIONS) $< -o `dirname $<`; \
> > > + )
> > > +
> > > +$(foreach target, $(QTEST_TARGETS), \
> > > + $(eval check-qtest-$(target): QTEST_TARGET := $(target)) \
> > > + $(eval check-qtest-$(target): $(patsubst tests/%, qtest-run-%, \
> > > + $(check-qtest-y) \
> > > +
> $(check-qtest-$(target)-y) \
> > > +
> $(check-qtest-generic-y))) \
> > > +)
> > >
> > >  .PHONY: $(patsubst %, check-%, $(check-unit-y))
> > > -$(patsubst %, check-%, $(check-unit-y)): check-%: %
> > > - $(if $(CONFIG_GCOV),@rm -f *.gcda */*.gcda */*/*.gcda */*/*/*.gcda,)
> > > - $(call quiet-command, \
> > > - MALLOC_PERTURB_=$${MALLOC_PERTURB_:-$$((RANDOM % 255 +
> 1))} \
> > > - gtester $(GTESTER_OPTIONS) -m=$(SPEED) $*,"GTESTER $*")
> > > - $(if $(CONFIG_GCOV),@for f in $(gcov-files-$(subst tests/,,$*)-y)
> $(gcov-files-generic-y); do \
> > > -   echo Gcov report for $$f:;\
> > > -   $(GCOV) $(GCOV_OPTIONS) $$f -o `dirname $$f`; \
> > > - done,)
> > > +$(patsubst %, check-%, $(check-unit-y)): check-tests/%: qtest-run-%
> > >
> > >  # gtester tests with XML output
> > >
> > >
> >
> > I can't vouch for gcov either, but:
> 
> Too bad that this seems to be too big a hammer that breaks the way gcov was
> used: 1) the "rm *.gcda" command now runs in each test, so it's harder to
> get an overall coverage report; 2) there is a risk that the parallism may
> corrupt those files. :(
> 
> Fam
> 
> >
> > Tested-by: John Snow 
> >
> > -j1:
> >
> > real1m51.195s
> > user1m5.478s
> > sys 0m21.158s
> >
> > -j9:
> >
> > real0m53.039s
> > user1m41.754s
> > sys 0m31.150s
> >
> >
> > This seems useful.
> >
> > --js

[Qemu-devel] Qtest virtio interfaces don't support virtio-1.0 devices

[Gonglei (Arei)]

Hi,

Based on the virtio-1.0 spec, the virtio pci devices' layout have been changed,
such as PCI_SUBSYSTEM_ID and modern_mem_bar.

But the current qtest still don't support the virtio-1.0 or later devices. Such 
as virtio-gpu,
Virtio-input and virtio-crypto devices.

Refer to functions in tests/libqos/virtio-pci.c.

Any plans to support them? Thanks!

Regards,
-Gonglei

Re: [Qemu-devel] [V0 1/1] virtio crypto device specification: asymmetric crypto service

[Gonglei (Arei)]

> -Original Message-
> From: Zeng, Xin [mailto:xin.z...@intel.com]
> Sent: Friday, September 23, 2016 1:39 PM
> To: Gonglei (Arei); virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org
> Cc: m...@redhat.com; Keating, Brian A; Griffin, John; Ma, Liang J; Hanweidong
> (Randy); Wubin (H)
> Subject: RE: [V0 1/1] virtio crypto device specification: asymmetric crypto
> service
> 
> On Wednesday, September 21, 2016 3:03 PM, Gonglei (Arei) Wrote:
> > > -Original Message-
> > > From: Xin Zeng [mailto:xin.z...@intel.com]
> > > Sent: Wednesday, September 21, 2016 1:15 PM
> > > To: virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org; Gonglei
> > (Arei)
> > > Cc: m...@redhat.com; brian.a.keat...@intel.com; john.grif...@intel.com;
> > > liang.j...@intel.com; Huangweidong (C); Xin Zeng
> > > Subject: [V0 1/1] virtio crypto device specification: asymmetric crypto
> > service
> > >
> > > This patch introduces asymmetric crypto service into virtio crypto
> > > device. The asymmetric crypto service can be referred as signature,
> > > verification, encryption, decryption, key generation and key exchange.
> > > This patch depends on another virtio crypto device spec patch:
> > > https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04563.html.
> > >
> > > Signed-off-by: Xin Zeng 
> > > ---
> > >  virtio-crypto.tex | 932
> > > +-
> > >  1 file changed, 931 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > index c3554e3..699d8dc 100644
> > > --- a/virtio-crypto.tex
> > > +++ b/virtio-crypto.tex
> > > @@ -46,6 +46,7 @@ struct virtio_crypto_config {
> > >  le32 kdf_algo;
> > >  le32 aead_algo;
> > >  le32 primitive_algo;
> > > +le32 rsa_padding;
> >
> > The structure doesn't 64-bit aligned now. Please add a padding.
> >
> 
> Yes. We also need remove some fields for now as Michael suggested in another
> mail.
> 
> > >  };
> > >  \end{lstlisting}
> > >
> > > @@ -67,6 +68,7 @@ The following services are defined:
> > >  #define VIRTIO_CRYPTO_SERVICE_HASH   (1) /* HASH service */
> > >  #define VIRTIO_CRYPTO_SERVICE_MAC(2) /* MAC (Message
> > > Authentication Codes) service */
> > >  #define VIRTIO_CRYPTO_SERVICE_AEAD   (3) /* AEAD (Authenticated
> > > Encryption with Associated Data) service */
> > > +#define VIRTIO_CRYPTO_SERVICE_ASYM  (4) /* Asymmetric crypto
> > service*/
> > >  \end{lstlisting}
> > >
> > >  The last driver-read-only fields specify detailed algorithms masks
> > > @@ -140,6 +142,28 @@ The following AEAD algorithms are defined:
> > >  #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3
> > >  \end{lstlisting}
> > >
> > > +The following asymmetric algorithms are defined:
> > > +
> > > +\begin{lstlisting}
> > > +#define VIRTIO_CRYPTO_ASYM_NONE0
> > > +#define VIRTIO_CRYPTO_ASYM_RSA 1
> > > +#define VIRTIO_CRYPTO_ASYM_DSA 2
> > > +#define VIRTIO_CRYPTO_ASYM_DH  3
> > > +#define VIRTIO_CRYPTO_ASYM_ECDSA   4
> > > +#define VIRTIO_CRYPTO_ASYM_ECDH 5
> > > +\end{lstlisting}
> > > +
> > > +The following rsa padding capabilities are defined:
> > > +
> > > +\begin{lstlisting}
> > > +#define VIRTIO_CRYPTO_RSA_NO_PADDING 0
> > > +#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING  1
> > > +#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING 2
> > > +#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING 3
> > > +#define VIRTIO_CRYPTO_RSA_X931_PADDING   4
> > > +#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING  5
> > > +\end{lstlisting}
> > > +
> > >  \begin{note}
> > >  More algorithms will be defined in the future.
> > >  \end{note}
> > > @@ -238,6 +262,18 @@ struct virtio_crypto_op_header {
> > >  VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
> > >  #define VIRTIO_CRYPTO_AEAD_DECRYPT \
> > >  VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> > > +#define VIRTIO_CRYPTO_ASYM_SIGN\
> > > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x00)
> > > +#define VIRTIO_CRYPTO_ASYM_VERIFY \
> > > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x01)
> > > +#define VIRTIO_CRYPTO_ASYM_ENCRYPT  \
> > > +VIRTIO_CRYPTO_O

Re: [Qemu-devel] [PATCH] qtest: fix make check complaint in crypto module

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Thursday, September 22, 2016 4:12 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Wubin (H)
> Subject: Re: [PATCH] qtest: fix make check complaint in crypto module
> 
> On Thu, Sep 22, 2016 at 02:35:49PM +0800, Gonglei wrote:
> >   CCtests/test-crypto-tlscredsx509.o
> >   CCtests/crypto-tls-x509-helpers.o
> >   CCtests/pkix_asn1_tab.o
> > tests/pkix_asn1_tab.c:7:22: warning: libtasn1.h: No such file or directory
> > tests/pkix_asn1_tab.c:9: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
> ‘__attribute__’ before ‘pkix_asn1_tab’
> > make: *** [tests/pkix_asn1_tab.o] Error 1
> >
> > Signed-off-by: Gonglei 
> > ---
> >  tests/Makefile.include | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/tests/Makefile.include b/tests/Makefile.include
> > index e560ecb..ad6950f 100644
> > --- a/tests/Makefile.include
> > +++ b/tests/Makefile.include
> > @@ -92,8 +92,10 @@ gcov-files-test-write-threshold-y =
> block/write-threshold.c
> >  check-unit-y += tests/test-crypto-hash$(EXESUF)
> >  check-unit-y += tests/test-crypto-cipher$(EXESUF)
> >  check-unit-y += tests/test-crypto-secret$(EXESUF)
> > +ifeq ($(CONFIG_TASN1),y)
> >  check-unit-$(CONFIG_GNUTLS) += tests/test-crypto-tlscredsx509$(EXESUF)
> >  check-unit-$(CONFIG_GNUTLS) += tests/test-crypto-tlssession$(EXESUF)
> > +endif
> 
> We already check this condition in tests/crypto-tls-x509-helpers.h  and
> .c files should conditionalize themselves with
> 
>#ifdef QCRYPTO_HAVE_TLS_TEST_SUPPORT
> 
> the tests/pkix_asn1_tab.c file is just missing that check
> 

Yes, I see it.

Regards,
-Gonglei

> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] crypto: add CTR mode support

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Thursday, September 22, 2016 4:17 PM
> To: qemu-devel@nongnu.org
> Cc: Gonglei (Arei); f...@redhat.com; Wubin (H)
> Subject: Re: [Qemu-devel] [PATCH] crypto: add CTR mode support
> 
> On Thu, Sep 22, 2016 at 12:17:43AM -0700,
> no-re...@ec2-52-6-146-230.compute-1.amazonaws.com wrote:
> > Hi,
> >
> > Your series failed automatic build test. Please find the testing commands 
> > and
> > their output below. If you have docker installed, you can probably 
> > reproduce it
> > locally.
> 
> > GTESTER tests/test-crypto-cipher
> > **
> > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> assertion failed: (err == NULL)
> > GTESTER tests/test-crypto-secret
> > GTESTER tests/test-qga
> > GTESTER tests/test-timed-average
> > GTESTER tests/test-io-task
> > GTester: last random seed: R02S94c4e01f686829a0cec78fda5b9551b8
> > **
> > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> assertion failed: (err == NULL)
> > GTESTER tests/test-io-channel-socket
> > GTester: last random seed: R02S2749a35e038d902a633846f61116c95d
> > GTESTER tests/test-io-channel-file
> > **
> > ERROR:/tmp/qemu-test/src/tests/test-crypto-cipher.c:528:test_cipher:
> assertion failed: (err == NULL)
> 
> It seems you exposed a pre-existing bug in the test suite. It is using
> qcrypto_cipher_supports() to check if the cipher algorithm is supported
> before running each test case. Unfortunately this assumes that if the
> algorithm is supported, then all cipher modes are also supported, which
> is not true with --disable-gcrypt --disable-nettle configure flags.
> 
Yes, that's right.

> So we need to extend qcrypto_cipher_supports() to take both the algorithm
> and mode as parameters.
> 
Make sense. Let me add another patch to fix it.

Regards,
-Gonglei

> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination

[Gonglei (Arei)]

> -Original Message-
> From: Greg Kurz [mailto:gr...@kaod.org]
> Sent: Thursday, September 22, 2016 3:22 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang; Max
> Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> termination
> 
> On Thu, 22 Sep 2016 06:55:43 +
> "Gonglei (Arei)"  wrote:
> 
> > > -Original Message-
> > > From: Greg Kurz [mailto:gr...@kaod.org]
> > > Sent: Thursday, September 22, 2016 2:43 PM
> > > To: Gonglei (Arei)
> > > Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang;
> Max
> > > Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> > > Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> > > termination
> > >
> > > On Thu, 22 Sep 2016 09:19:49 +0800
> > > Gonglei  wrote:
> > >
> > > > On 2016/9/21 21:13, Greg Kurz wrote:
> > > > > This series is a follow up to Stefan's work to eradicate most calls to
> > > > > exit() we currently have in the virtio code.
> > > > >
> > > > > It addresses all exit() call sites in the blk, net and scsi device 
> > > > > code,
> > > > > where the error is about a missing or malformed in/out header sent by
> > > > > the guest. They are converted to use virtio_error() and stop any
> processing,
> > > > > instead of exiting.
> > > > >
> > > > Actually if you just stop procesing when encounter a missing in/out 
> > > > header
> > > but
> > > > send a interrupt to the guest, the guest maybe be stuck.
> > > virtio_net_handle_ctrl()
> > >
> > > The virtio_error() function sets the device status to DEVICE_NEEDS_RESET
> and
> > > does send a device configuration change interrupt to the guest, so it can
> take
> > > appropriate action (i.e. reset the device).
> > >
> > That's appropriate. Where is realization of virtio_error() ?
> > I'm sure I missed something.
> >
> 
> Sorry for that... Michael already "lectured" me about not providing these
> details. He is right indeed :)
> 
> 
> This is work in progress by Stefan. The latest version of the patchset (v5) 
> was
> posted yesterday:
> 
> <1474473146-19337-1-git-send-email-stefa...@redhat.com>
> 
> The virtio_error() function itself is in patch 2/9:
> 
> <1474473146-19337-3-git-send-email-stefa...@redhat.com>
> 

I see, thanks.

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination

[Gonglei (Arei)]

Hi Greg,



> -Original Message-
> From: Greg Kurz [mailto:gr...@kaod.org]
> Sent: Thursday, September 22, 2016 3:22 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang; Max
> Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> termination
> 
> On Thu, 22 Sep 2016 06:55:43 +
> "Gonglei (Arei)"  wrote:
> 
> > > -Original Message-
> > > From: Greg Kurz [mailto:gr...@kaod.org]
> > > Sent: Thursday, September 22, 2016 2:43 PM
> > > To: Gonglei (Arei)
> > > Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang;
> Max
> > > Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> > > Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> > > termination
> > >
> > > On Thu, 22 Sep 2016 09:19:49 +0800
> > > Gonglei  wrote:
> > >
> > > > On 2016/9/21 21:13, Greg Kurz wrote:
> > > > > This series is a follow up to Stefan's work to eradicate most calls to
> > > > > exit() we currently have in the virtio code.
> > > > >
> > > > > It addresses all exit() call sites in the blk, net and scsi device 
> > > > > code,
> > > > > where the error is about a missing or malformed in/out header sent by
> > > > > the guest. They are converted to use virtio_error() and stop any
> processing,
> > > > > instead of exiting.
> > > > >
> > > > Actually if you just stop procesing when encounter a missing in/out 
> > > > header
> > > but
> > > > send a interrupt to the guest, the guest maybe be stuck.
> > > virtio_net_handle_ctrl()
> > >
> > > The virtio_error() function sets the device status to DEVICE_NEEDS_RESET
> and
> > > does send a device configuration change interrupt to the guest, so it can
> take
> > > appropriate action (i.e. reset the device).
> > >

I saw virtio_error() only handle the virtio 1.0 device, the legacy virtio 
device may
still stuck, am I right?

+void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice *vdev, const char *fmt, ...)
+{
+va_list ap;
+
+va_start(ap, fmt);
+error_vreport(fmt, ap);
+va_end(ap);
+
+vdev->broken = true;
+
+if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+virtio_set_status(vdev, vdev->status | VIRTIO_CONFIG_S_NEEDS_RESET);
+virtio_notify_config(vdev);
+}
+}


Regards,
-Gonglei

> > That's appropriate. Where is realization of virtio_error() ?
> > I'm sure I missed something.
> >
> 
> Sorry for that... Michael already "lectured" me about not providing these
> details. He is right indeed :)
> 
> 
> This is work in progress by Stefan. The latest version of the patchset (v5) 
> was
> posted yesterday:
> 
> <1474473146-19337-1-git-send-email-stefa...@redhat.com>
> 
> The virtio_error() function itself is in patch 2/9:
> 
> <1474473146-19337-3-git-send-email-stefa...@redhat.com>
> 
> Cheers.
> 
> --
> Greg
> 
> > Regards,
> > -Gonglei
> >
> > > Maybe I should have mentioned that in the changelog...
> > >
> > > Cheers.
> > >
> > > --
> > > Greg
> > >
> > > > is an example, the guest frontend driver infinite loop to wait the
> interrupt's
> > > coming.
> > > > The guest can't work anymore though you don't exit the Qemu process .
> > > >
> > > > Regards,
> > > > -Gonglei
> > > >
> > > > > The remaining call sites are related to a host misconfiguration or a
> > > > > migration stream issue.
> > > > >
> > > > > The 9P code currently calls assert() instead of exit(), but it also 
> > > > > about
> > > > > malformed or missing headers, so it gets converted the same way.
> > > > >
> > > > > Next work will be to check all assert() call sites in the device 
> > > > > code, in
> > > > > case some of them actually refer to a bug in the guest, and should be
> > > > > converted to use virtio_error() as well.
> > > > >
> > > > > ---
> > > > >
> > > > > Greg Kurz (7):
> > > > >   virtio-9p: handle handle_9p_output() error
> > > > >   virtio-blk: handle virtio_blk_handle_request() errors
> > > > >   virtio-net: handle virtio_net_handle_ctrl() error
> > > > >   virtio-net: handle virtio_net_receive() errors
> > > > >   virtio-net: handle virtio_net_flush_tx() errors
> > > > >   virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
> > > > >   virtio-scsi: handle virtio_scsi_set_config() error
> > > > >
> > > > >
> > > > >  hw/9pfs/virtio-9p-device.c |   14 ++--
> > > > >  hw/block/virtio-blk.c  |   27 +++
> > > > >  hw/net/virtio-net.c|   51
> > > +---
> > > > >  hw/scsi/virtio-scsi.c  |   21 ++
> > > > >  4 files changed, 70 insertions(+), 43 deletions(-)
> > > > >
> > > > > --
> > > > > Greg
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> >

Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination

[Gonglei (Arei)]

> -Original Message-
> From: Greg Kurz [mailto:gr...@kaod.org]
> Sent: Thursday, September 22, 2016 2:43 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Kevin Wolf; Michael S. Tsirkin; Jason Wang; Max
> Reitz; Aneesh Kumar K.V; Stefan Hajnoczi; Cornelia Huck; Paolo Bonzini
> Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU
> termination
> 
> On Thu, 22 Sep 2016 09:19:49 +0800
> Gonglei  wrote:
> 
> > On 2016/9/21 21:13, Greg Kurz wrote:
> > > This series is a follow up to Stefan's work to eradicate most calls to
> > > exit() we currently have in the virtio code.
> > >
> > > It addresses all exit() call sites in the blk, net and scsi device code,
> > > where the error is about a missing or malformed in/out header sent by
> > > the guest. They are converted to use virtio_error() and stop any 
> > > processing,
> > > instead of exiting.
> > >
> > Actually if you just stop procesing when encounter a missing in/out header
> but
> > send a interrupt to the guest, the guest maybe be stuck.
> virtio_net_handle_ctrl()
> 
> The virtio_error() function sets the device status to DEVICE_NEEDS_RESET and
> does send a device configuration change interrupt to the guest, so it can take
> appropriate action (i.e. reset the device).
> 
That's appropriate. Where is realization of virtio_error() ? 
I'm sure I missed something. 
 
Regards,
-Gonglei

> Maybe I should have mentioned that in the changelog...
> 
> Cheers.
> 
> --
> Greg
> 
> > is an example, the guest frontend driver infinite loop to wait the 
> > interrupt's
> coming.
> > The guest can't work anymore though you don't exit the Qemu process .
> >
> > Regards,
> > -Gonglei
> >
> > > The remaining call sites are related to a host misconfiguration or a
> > > migration stream issue.
> > >
> > > The 9P code currently calls assert() instead of exit(), but it also about
> > > malformed or missing headers, so it gets converted the same way.
> > >
> > > Next work will be to check all assert() call sites in the device code, in
> > > case some of them actually refer to a bug in the guest, and should be
> > > converted to use virtio_error() as well.
> > >
> > > ---
> > >
> > > Greg Kurz (7):
> > >   virtio-9p: handle handle_9p_output() error
> > >   virtio-blk: handle virtio_blk_handle_request() errors
> > >   virtio-net: handle virtio_net_handle_ctrl() error
> > >   virtio-net: handle virtio_net_receive() errors
> > >   virtio-net: handle virtio_net_flush_tx() errors
> > >   virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()
> > >   virtio-scsi: handle virtio_scsi_set_config() error
> > >
> > >
> > >  hw/9pfs/virtio-9p-device.c |   14 ++--
> > >  hw/block/virtio-blk.c  |   27 +++
> > >  hw/net/virtio-net.c|   51
> +---
> > >  hw/scsi/virtio-scsi.c  |   21 ++
> > >  4 files changed, 70 insertions(+), 43 deletions(-)
> > >
> > > --
> > > Greg
> > >
> > >
> > >
> > >
> >

Re: [Qemu-devel] [PATCH v3 00/10] virtio-crypto: introduce framework and device emulation

[Gonglei (Arei)]

Hi Michael, Stefan and Paolo,

Would you please help to review virtio stuff in the patch set? Thanks!

Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Monday, September 19, 2016 4:16 PM
> Subject: [PATCH v3 00/10] virtio-crypto: introduce framework and device
> emulation
> 
> Changes since v2:
>  According to Daniel's comments:
>  - drop cryptodev kernel module as a cryptodev backend
>  - rename crypto stuff to cryptodev stuff
>  - change some files' license to GPLv2+
>  - remove cryptodev command line instead of QOM to define the cryptodev
> backend
>  - rename all functions and structures in crypto sub-directory.
>  - add full inline documentation for cryptodev.h
>  And:
>  - drop crypto-queue.c [Paolo]
>  - merge some patches
> 
> Great thanks to Daniel and Paolo. Please review again, thanks!
> 
> Changes since v1:
>  - rmmove mixed endian-ness handler for virtio-crypto device, just
>use little-endian. [mst]
>  - add sg list support according virtio-crypto spec v10 (will be posted soon).
>  - fix a memory leak in session handler.
>  - add a feature page link in qemu.org
> (http://qemu-project.org/Features/VirtioCrypto)
>  - fix some trivial problems, sush as 's/Since 2.7/Since 2.8/g' in
> qapi-schema.json
>  - rebase the latest qemu master tree.
> 
> 
> This patch series realize the framework and emulation of a new
> virtio crypto device, which is similar with virtio net device.
> 
>  - I introduce the cryptodev backend as the client of virtio crypto device
>which can be realized by different methods, such as
> cryptodev-backend-gcrypt in my series,
>vhost-crypto kernel module, vhost-user etc.
>  - The patch set abides by the virtio crypto speccification.
>  - The virtio crypto support symmetric algorithms (including CIPHER and
> algorithm chainning)
>at present, except HASH, MAC and AEAD services.
>  - unsupport hot plug/unplug cryptodev backend at this moment.
> 
> Firstly build QEMU with libgcrypt cryptography support.
> 
> QEMU can then be started using the following parameters:
> 
> qemu-system-x86_64 \
> [...] \
> -object cryptodev-backend-gcrypt,id=cryptodev0 \
> -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \
> [...]
> 
> The front-end linux kernel driver (Experimental at present) is publicly 
> accessible
> from:
> 
>https://github.com/gongleiarei/virtio-crypto-linux-driver.git
> 
> After insmod virtio-crypto.ko, you can use cryptodev-linux test the crypto
> function
> in the guest. For example:
> 
> linux-guest:/home/gonglei/cryptodev-linux/tests # ./cipher -
> requested cipher CRYPTO_AES_CBC, got cbc(aes) with driver
> virtio_crypto_aes_cbc
> AES Test passed
> requested cipher CRYPTO_AES_CBC, got cbc(aes) with driver
> virtio_crypto_aes_cbc
> requested cipher CRYPTO_AES_CBC, got cbc(aes) with driver
> virtio_crypto_aes_cbc
> Test passed
> 
> QEMU code also can be accessible from:
> 
>  https://github.com/gongleiarei/qemu.git
> 
>  branch virtio-crypto
> 
> For more information, please see:
>  http://qemu-project.org/Features/VirtioCrypto
> 
> 
> Gonglei (10):
>   cryptodev: introduce cryptodev backend interface
>   cryptodev: add symmetric algorithm operation stuff
>   virtio-crypto: introduce virtio_crypto.h
>   cryptodev: introduce gcrypt lib as a new cryptodev backend
>   virtio-crypto: add virtio crypto device emulation
>   virtio-crypto-pci: add virtio crypto pci support
>   virtio-crypto: set capacity of algorithms supported
>   virtio-crypto: add control queue handler
>   virtio-crypto: add data queue processing handler
>   cryptodev: introduce an unified wrapper for crypto operation
> 
>  crypto/Makefile.objs   |   2 +
>  crypto/cryptodev-gcrypt.c  | 329 +
>  crypto/cryptodev.c | 243 +++
>  hw/virtio/Makefile.objs|   2 +
>  hw/virtio/virtio-crypto-pci.c  |  76 +++
>  hw/virtio/virtio-crypto.c  | 904
> +
>  hw/virtio/virtio-pci.h |  15 +
>  include/crypto/cryptodev.h | 276 
>  include/hw/virtio/virtio-crypto.h  | 100 +++
>  include/standard-headers/linux/virtio_crypto.h | 466 +
>  qemu-options.hx|  18 +
>  11 files changed, 2431 insertions(+)
>  create mode 100644 crypto/cryptodev-gcrypt.c
>  create mode 100644 crypto/cryptodev.c
>  create mode 100644 hw/virtio/virtio-crypto-pci.c
>  create mode 100644 hw/virtio/virtio-crypto.c
>  create mode 100644 include/crypto/cryptodev.h
>  create mode 100644 include/hw/virtio/virtio-crypto.h
>  create mode 100644 include/standard-headers/linux/virtio_crypto.h
> 
> --
> 1.7.12.4
> 

Re: [Qemu-devel] [V0 1/1] virtio crypto device specification: asymmetric crypto service

[Gonglei (Arei)]

Hi Xin,

Here you go. ;)

> -Original Message-
> From: Xin Zeng [mailto:xin.z...@intel.com]
> Sent: Wednesday, September 21, 2016 1:15 PM
> To: virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org; Gonglei (Arei)
> Cc: m...@redhat.com; brian.a.keat...@intel.com; john.grif...@intel.com;
> liang.j...@intel.com; Huangweidong (C); Xin Zeng
> Subject: [V0 1/1] virtio crypto device specification: asymmetric crypto 
> service
> 
> This patch introduces asymmetric crypto service into virtio crypto
> device. The asymmetric crypto service can be referred as signature,
> verification, encryption, decryption, key generation and key exchange.
> This patch depends on another virtio crypto device spec patch:
> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04563.html.
> 
> Signed-off-by: Xin Zeng 
> ---
>  virtio-crypto.tex | 932
> +-
>  1 file changed, 931 insertions(+), 1 deletion(-)
> 
> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> index c3554e3..699d8dc 100644
> --- a/virtio-crypto.tex
> +++ b/virtio-crypto.tex
> @@ -46,6 +46,7 @@ struct virtio_crypto_config {
>  le32 kdf_algo;
>  le32 aead_algo;
>  le32 primitive_algo;
> +le32 rsa_padding;

The structure doesn't 64-bit aligned now. Please add a padding.

>  };
>  \end{lstlisting}
> 
> @@ -67,6 +68,7 @@ The following services are defined:
>  #define VIRTIO_CRYPTO_SERVICE_HASH   (1) /* HASH service */
>  #define VIRTIO_CRYPTO_SERVICE_MAC(2) /* MAC (Message
> Authentication Codes) service */
>  #define VIRTIO_CRYPTO_SERVICE_AEAD   (3) /* AEAD (Authenticated
> Encryption with Associated Data) service */
> +#define VIRTIO_CRYPTO_SERVICE_ASYM  (4) /* Asymmetric crypto service*/
>  \end{lstlisting}
> 
>  The last driver-read-only fields specify detailed algorithms masks
> @@ -140,6 +142,28 @@ The following AEAD algorithms are defined:
>  #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3
>  \end{lstlisting}
> 
> +The following asymmetric algorithms are defined:
> +
> +\begin{lstlisting}
> +#define VIRTIO_CRYPTO_ASYM_NONE0
> +#define VIRTIO_CRYPTO_ASYM_RSA 1
> +#define VIRTIO_CRYPTO_ASYM_DSA 2
> +#define VIRTIO_CRYPTO_ASYM_DH  3
> +#define VIRTIO_CRYPTO_ASYM_ECDSA   4
> +#define VIRTIO_CRYPTO_ASYM_ECDH 5
> +\end{lstlisting}
> +
> +The following rsa padding capabilities are defined:
> +
> +\begin{lstlisting}
> +#define VIRTIO_CRYPTO_RSA_NO_PADDING 0
> +#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING  1
> +#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING 2
> +#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING 3
> +#define VIRTIO_CRYPTO_RSA_X931_PADDING   4
> +#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING  5
> +\end{lstlisting}
> +
>  \begin{note}
>  More algorithms will be defined in the future.
>  \end{note}
> @@ -238,6 +262,18 @@ struct virtio_crypto_op_header {
>  VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
>  #define VIRTIO_CRYPTO_AEAD_DECRYPT \
>  VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> +#define VIRTIO_CRYPTO_ASYM_SIGN\
> +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x00)
> +#define VIRTIO_CRYPTO_ASYM_VERIFY \
> +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x01)
> +#define VIRTIO_CRYPTO_ASYM_ENCRYPT  \
> +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x02)
> +#define VIRTIO_CRYPTO_ASYM_DECRYPT  \
> +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x03)
> +#define VIRTIO_CRYPTO_ASYM_KEY_GEN  \
> +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x04)
> +#define VIRTIO_CRYPTO_ASYM_KEY_EXCHG \
> +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x05)
>  le32 opcode;
>  /* algo should be service-specific algorithms */
>  le32 algo;
> @@ -540,6 +576,26 @@ struct virtio_crypto_op_data_req {
>  struct virtio_crypto_hash_data_req  hash_req;
>  struct virtio_crypto_mac_data_req   mac_req;
>  struct virtio_crypto_aead_data_req  aead_req;
> +struct virtio_crypto_ecdsa_sign_req ecdsa_sign_req;
> +struct virtio_crypto_dsa_sign_req dsa_sign_req;
> +struct virtio_crypto_rsa_sign_req rsa_sign_req;
> +
> +struct virtio_crypto_ecdsa_verify_req ecdsa_verify_req;
> +struct virtio_crypto_dsa_verify_req dsa_verify_req;
> +struct virtio_crypto_rsa_verify_req rsa_verify_req;
> +
> +struct virtio_crypto_rsa_enc_req rsa_enc_req
> +struct virtio_crypto_rsa_dec_req rsa_dec_req;
> +
> +struct virtio_crypto_rsa_keygen_req rsa_keygen_req;
> +struct virtio_crypto_dsa_keygen_req dsa_keygen_req;
> +struct virtio_crypto_ec_keygen_req ec_ke

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v10 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi Michael,


> -Original Message-
> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Michael S. Tsirkin
> Sent: Wednesday, September 21, 2016 3:11 AM
> Subject: [virtio-dev] Re: [PATCH v10 1/2] virtio-crypto: Add virtio crypto 
> device
> specification
> 
> On Tue, Sep 20, 2016 at 05:46:01PM +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.
> 
> Only CIPHER, MAC, HASH, AEAD are documented at this point.
> Let's drop others for now?
> 
OK, let's drop them. And Xin will add asym services soon by himself.
> 
> >
> > In this patch, CIPHER, MAC, HASH, AEAD services are introduced.
> >
> > Signed-off-by: Gonglei 
> > 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 
> > CC: Mihai Claudiu Caraman 
> > ---
> >  content.tex   |   2 +
> >  virtio-crypto.tex | 942
> ++
> >  2 files changed, 944 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..ac1fc0a
> > --- /dev/null
> > +++ b/virtio-crypto.tex
> > @@ -0,0 +1,942 @@
> > +\section{Crypto Device}\label{sec:Device Types / Crypto Device}
> > +
> > +The virtio crypto device is a virtual cryptography device as well as a 
> > kind of
> > +virtual hardware accelerator for virtual machines. The encryption and
> > +decryption requests are placed in the data queue and are ultimately handled
> by the
> > +real crypto accelerators.
> 
> I would like "real" to be renamed "backend".
> 
Good, it makes sense.

> > The second queue is the control queue used to create
> > +or destroy sessions for symmetric algorithms and will control some
> advanced
> > +features in the future. The virtio crypto device provides seven crypto
> > +services: CIPHER, MAC, HASH, AEAD, KDF, ASYM, and 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]
> > +\item[N-1] dataqN
> > +\item[N] controlq
> > +\end{description}
> > +
> > +N is set by \field{max_dataqueues}.
> > +
> > +\subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature
> bits}
> > +  None currently defined
> > +
> > +\subsection{Device configuration layout}\label{sec:Device Types / Crypto
> Device / Device configuration layout}
> > +
> > +The following driver-read-only configuration fields are defined:
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_config {
> > +le32  status;
> > +le32  max_dataqueues;
> 
> Is this just num_queues - 1?

Yes.

> Why isn't the generic num_queues sufficient?
> 
Actually I referred to the virtio net device definition. This field specifies 
the
maximum number of data virtqueues, not including control virtqueue.

> 
> > +le32  crypto_services;
> 
> Would it make sense to use feature bits for this instead?
> Looks like that you need to add algo masks when
> adding services, and tying config space fields
> to features  is well supported by guests.
> 
Actually I did that in a previous version. but Cornelia gave me a convincing
viewpoint to drop the feature bit:

"I'm wondering whether you'll really want a feature bit for each algorithm. Bits
0-23 are device specific, so there's still some more to go; but could this also 
go
into the configuration space instead? It's not like the driver will want to 
negotiate
which algorithms it wants to use, but rather it will want to check what the
device may offer."

And I think it makes sense. The driver could be tell if the service is 
supported or
not by the device by reading the configuration field.

> > +/* detailed algorithms mask */
> > +le32 cipher_algo_l;
> > +le32 cipher_algo_h;
> > +le32 hash_algo;
> > +le32 mac_algo_l;
> > +le32 mac_algo_h;
> > +le32 asym_algo;
> > +le32 kdf_algo;
> > +le32 aead_algo;
> > +le32 primitive_algo;
> > +};
> > +\end{lstlisting}
> > +
> > +In the \field{status}, th

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

[Gonglei (Arei)]

> -Original Message-
> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Xin Zeng
> Sent: Tuesday, September 20, 2016 11:47 PM
> Subject: [virtio-dev] [PATCH] virtio crypto device specification
> 
> Fix spelling mistakes of keywords to make xelatex happy:
> filed--->field
> 
Oops, my typos, thank you. :)


Regards,
-Gonglei

> Signed-off-by: Xin Zeng 
> ---
>  virtio-crypto.tex | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> index ac1fc0a..c3554e3 100644
> --- a/virtio-crypto.tex
> +++ b/virtio-crypto.tex
> @@ -159,7 +159,7 @@ More algorithms will be defined in the future.
>  \begin{itemize*}
>  \item The driver MUST read the ready \field{status} from the bottom bit of
> status to check whether the hardware-backed
>implementation is ready or not, and the driver MUST reread it after
> the device reset.
> -\item The driver MUST NOT transmit any packets to the device if the ready
> \filed{status} is not set.
> +\item The driver MUST NOT transmit any packets to the device if the ready
> \field{status} is not set.
>  \item The driver MAY 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.
>  \item The driver MUST read the detailed algorithms fields based on
> \field{crypto_services} field.
> @@ -634,7 +634,7 @@ The driver MUST set \field{src_data}.\field{flag} to
> ~VIRTIO_CRYPTO_IOVEC_F_NEXT
> 
>  \devicenormative{\subparagraph}{HASH Service Operation}{Device Types /
> Crypto Device / Device Operation / Data Virtqueue / HASH Service Operation}
> 
> -The device MUST copy the results of HASH operations to the guest memory
> recorded by \field{digest_result_addr} filed in struct 
> virtio_crypto_hash_input.
> +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.
>  The device MUST set \field{status} in strut virtio_crypto_hash_input:
> VIRTIO_CRYPTO_OP_OK: success; VIRTIO_CRYPTO_OP_ERR: creation failed or
> device error; VIRTIO_CRYPTO_OP_NOTSUPP: not support.
> 
>  \paragraph{MAC Service Operation}\label{sec:Device Types / Crypto Device /
> Device Operation / Data Virtqueue / MAC Service Operation}
> @@ -685,7 +685,7 @@ The driver MUST set
> \field{hash_output}.\field{src_data}.\field{flag} to ~VIRTIO
> 
>  \devicenormative{\subparagraph}{MAC Service Operation}{Device Types /
> Crypto Device / Device Operation / Data Virtqueue / MAC Service Operation}
> 
> -The device MUST copy the results of MAC operations to the guest memory
> recorded by \field{digest_result_addr} filed in struct 
> virtio_crypto_mac_input.
> +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.
>  The device MUST set \field{status} in strut virtio_crypto_mac_input:
> VIRTIO_CRYPTO_OP_OK: success; VIRTIO_CRYPTO_OP_ERR: creation failed or
> device error; VIRTIO_CRYPTO_OP_NOTSUPP: not support.
> 
>  \paragraph{Symmetric algorithms Operation}\label{sec:Device Types / Crypto
> Device / Device Operation / Data Virtqueue / Symmetric algorithms Operation}
> @@ -813,9 +813,9 @@ The device MUST parse the
> virtio_crypto_sym_data_req based on the \field{op_code
>  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.
>  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.
> -The device MUST copy the result of cryptographic operation to the guest
> memory recorded by \filed{dst_data}.\field{addr} filed in struct
> virtio_crypto_cipher_input in plain CIPHER mode.
> -The device MUST copy the result of HASH/MAC operation to the guest
> memory recorded by \filed{digest_result_addr} filed in struct
> virtio_crypto_alg_chain_data_input is of the
> VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING type.
> -The device MUST set the \filed{status} field in strut 
> virtio_crypto_cipher_input
> or virtio_crypto_alg_chain_data_input structure:
> +The device MUST copy the result of cryptographic operation to the guest
> memory recorded by \field{dst_data}.\field{addr} field in struct
> virtio_crypto_cipher_input in plain CIPHER mode.
> +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.
> +The device MUST set the \field{status} field in str

Re: [Qemu-devel] [PATCH v3 04/10] cryptodev: introduce gcrypt lib as a new cryptodev backend

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Monday, September 19, 2016 4:56 PM
> Subject: Re: [PATCH v3 04/10] cryptodev: introduce gcrypt lib as a new
> cryptodev backend
> 
> On Mon, Sep 19, 2016 at 04:16:16PM +0800, Gonglei wrote:
> > Signed-off-by: Gonglei 
> > ---
> >  crypto/Makefile.objs  |   1 +
> >  crypto/cryptodev-gcrypt.c | 329
> ++
> >  qemu-options.hx   |  18 +++
> >  3 files changed, 348 insertions(+)
> >  create mode 100644 crypto/cryptodev-gcrypt.c
> >
> > diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
> > index f7f3c4f..bd8aea7 100644
> > --- a/crypto/Makefile.objs
> > +++ b/crypto/Makefile.objs
> > @@ -27,6 +27,7 @@ crypto-obj-y += block.o
> >  crypto-obj-y += block-qcow.o
> >  crypto-obj-y += block-luks.o
> >  crypto-obj-y += cryptodev.o
> > +crypto-obj-$(CONFIG_GCRYPT) += cryptodev-gcrypt.o
> 
> This can be just crypto-obj-y +=
> 
Yes.

> >  # Let the userspace emulators avoid linking gnutls/etc
> >  crypto-aes-obj-y = aes.o
> > diff --git a/crypto/cryptodev-gcrypt.c b/crypto/cryptodev-gcrypt.c
> > new file mode 100644
> > index 000..66a0e5e
> > --- /dev/null
> > +++ b/crypto/cryptodev-gcrypt.c
> > +/**
> > + * @TYPE_QCRYPTO_CRYPTODEV_BACKEND_GCRYPT:
> > + * name of backend that uses gcrypt library
> > + */
> > +#define TYPE_QCRYPTO_CRYPTODEV_BACKEND_GCRYPT
> "cryptodev-backend-gcrypt"
> 
> I'd suggest we just call this backend "builtin", so do a
> replace of "gcrypt" with "builtin" throughout.
> 
OK, good name ;)

> > +static void qcrypto_cryptodev_backend_gcrypt_init(
> > + QCryptoCryptoDevBackend *backend, Error **errp)
> > +{
> > +/* Only support one queue */
> > +int queues = MAX(backend->conf.peers.queues, 1);
> > +int i;
> 
> Nitpick, I prefer to see 'size_t' for list iterators
> that are always positive. Similar comment in other
> places in this series using int i
> 
OK

> > +QCryptoCryptoDevBackendClientState *cc;
> > +
> > +for (i = 0; i < queues; i++) {
> > +cc = qcrypto_cryptodev_backend_new_client(
> > +  "cryptodev-gcrypt", NULL);
> > +snprintf(cc->info_str, sizeof(cc->info_str),
> > + "cryptodev-gcrypt%d", i);
> > +cc->queue_index = i;
> > +
> > +backend->conf.peers.ccs[i] = cc;
> > +}
> > +
> > +backend->conf.crypto_services =
> > + 1u << VIRTIO_CRYPTO_SERVICE_CIPHER |
> > + 1u << VIRTIO_CRYPTO_SERVICE_HASH |
> > + 1u << VIRTIO_CRYPTO_SERVICE_MAC;
> > +backend->conf.cipher_algo_l = 1u <<
> VIRTIO_CRYPTO_CIPHER_AES_CBC;
> > +backend->conf.hash_algo = 1u << VIRTIO_CRYPTO_HASH_SHA1;
> > +}
> > +
> > +static int
> > +qcrypto_cryptodev_backend_gcrypt_get_unused_session_index(
> > +  QCryptoCryptoDevBackendGcrypt *gcrypt)
> > +{
> > +int i;
> > +
> > +for (i = 0; i < MAX_NUM_SESSIONS; i++) {
> > +if (gcrypt->sessions[i] == NULL) {
> > +return i;
> > +}
> > +}
> > +
> > +return -1;
> > +}
> > +
> > +static int qcrypto_cryptodev_backend_gcrypt_create_cipher_session(
> > +QCryptoCryptoDevBackendGcrypt *gcrypt,
> > +QCryptoCryptoDevBackendSymSessionInfo
> *sess_info,
> > +Error **errp)
> > +{
> > +int algo;
> > +int mode;
> > +QCryptoCipher *cipher;
> > +int index;
> > +QCryptoCryptoDevBackendGcryptSession *sess;
> > +
> > +if (sess_info->op_type != VIRTIO_CRYPTO_SYM_OP_CIPHER) {
> > +error_setg(errp, "unsupported optype :%u", sess_info->op_type);
> > +return -1;
> > +}
> > +
> > +index =
> qcrypto_cryptodev_backend_gcrypt_get_unused_session_index(gcrypt);
> > +if (index < 0) {
> > +error_setg(errp, "the total number of created session
> exceed %u",
> > +  MAX_NUM_SESSIONS);
> > +return -1;
> > +}
> > +
> > +switch (sess_info->cipher_alg) {
> > +case VIRTIO_CRYPTO_CIPHER_AES_ECB:
> > +if (sess_info->key_len == 128 / 8) {
> > +algo = QCRYPTO_CIPHER_ALG_AES_128;
> > +} else if (sess_info->key_len == 192 / 8) {
> > +algo = QCRYPTO_CIPHER_ALG_AES_192;
> > +} else if (sess_info->key_len == 256 / 8) {
> > +algo = QCRYPTO_CIPHER_ALG_AES_256;
> > +} else {
> > +error_setg(errp, "unsupported key length :%u",
> > +   sess_info->key_len);
> > +return -1;
> > +}
> > +mode = QCRYPTO_CIPHER_MODE_ECB;
> > +break;
> > +case VIRTIO_CRYPTO_CIPHER_AES_CBC:
> > +if (sess_info->key_len == 128 / 8) {
> > +algo = QCRYPTO_CIPHER_ALG_AES_128;
> > +} else if (sess_info->key_len == 192 / 8) {
> > +algo = QCRYPTO_CIPHER_ALG_AES_192;
> > +} else if (sess_info->key_len == 256 / 8) {
> > +algo = QCRYPTO_CIPHER_ALG_A

Re: [Qemu-devel] [PATCH v3 04/10] cryptodev: introduce gcrypt lib as a new cryptodev backend

[Gonglei (Arei)]

Hi Daniel,


> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Monday, September 19, 2016 4:30 PM
> Subject: Re: [PATCH v3 04/10] cryptodev: introduce gcrypt lib as a new
> cryptodev backend
> 
> AFAICT you are not using gcrypt here - you're using QEMU
> cipher APIs (which is good). These APIs can be backed by
> either nettle or gcrypt though, so the subject is misleading.
> 
Oops, thanks for your reminding :)

Will fix in the next version.


Regards,
-Gonglei

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 02/15] crypto: introduce crypto queue handler

[Gonglei (Arei)]

Hi Ola,



> -Original Message-
> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> Sent: Tuesday, September 13, 2016 7:53 PM
> To: Paolo Bonzini; Daniel P. Berrange; Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Huangpeng
> (Peter); Luonengjun; m...@redhat.com; stefa...@redhat.com; Huangweidong
> (C); mike.cara...@nxp.com; ag...@suse.de; xin.z...@intel.com; Claudio
> Fontana; nmo...@kalray.eu; vincent.jar...@6wind.com
> Subject: Re: [virtio-dev] Re: [PATCH v2 02/15] crypto: introduce crypto queue
> handler
> 
> 
> 
> 
> 
> On 13/09/2016, 12:58, "virtio-...@lists.oasis-open.org on behalf of Paolo
> Bonzini"  pbonz...@redhat.com> wrote:
> 
> >
> >
> >On 13/09/2016 11:20, Daniel P. Berrange wrote:
> >>> > +typedef struct CryptoPacket CryptoPacket;
> >>> > +typedef struct CryptoQueue CryptoQueue;
> >>> > +typedef struct CryptoPacketBuf CryptoPacketBuf;
> >>> > +
> >>> > +typedef void (CryptoPacketSent) (CryptoClientState *, int);
> >> As previously, I'd expect naming of
> >>
> >>  QCryptoCryptodevPacket
> >>  QCryptoCryptodevPacketBuf
> >>  QCryptoCryptodevQueue
> >>
> >
> >Gonglei,
> >
> >you are copying a lot of code from network backends.
> >
> >I am not sure why you would need a queue for virtio-crypto rather than a
> >direct connection between frontend and backend (and the backend would be
> >QEMU crypto APIs, like Daniel suggested).
>
> What about backends implemented directly in HW? Bypass the middle man.
> Make crypto offload meaningful for small size blocks.
> 
As I said in other reply, I only provide interfaces, you can realize them 
according
to different backend cryptodevs.

Regards,
-Gonglei

> < Ola
> 
> >
> >Paolo
> >
> >-
> >To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> >For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
> >
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended 
> recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 02/15] crypto: introduce crypto queue handler

[Gonglei (Arei)]

Hi Paolo,


> -Original Message-
> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Paolo Bonzini
> Sent: Tuesday, September 13, 2016 6:58 PM
> To: Daniel P. Berrange; Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Huangpeng
> (Peter); Luonengjun; m...@redhat.com; stefa...@redhat.com; Huangweidong
> (C); mike.cara...@nxp.com; ag...@suse.de; xin.z...@intel.com; Claudio
> Fontana; nmo...@kalray.eu; vincent.jar...@6wind.com
> Subject: [virtio-dev] Re: [PATCH v2 02/15] crypto: introduce crypto queue
> handler
> 
> 
> 
> On 13/09/2016 11:20, Daniel P. Berrange wrote:
> >> > +typedef struct CryptoPacket CryptoPacket;
> >> > +typedef struct CryptoQueue CryptoQueue;
> >> > +typedef struct CryptoPacketBuf CryptoPacketBuf;
> >> > +
> >> > +typedef void (CryptoPacketSent) (CryptoClientState *, int);
> > As previously, I'd expect naming of
> >
> >  QCryptoCryptodevPacket
> >  QCryptoCryptodevPacketBuf
> >  QCryptoCryptodevQueue
> >
> 
> Gonglei,
> 
> you are copying a lot of code from network backends.
> 
> I am not sure why you would need a queue for virtio-crypto rather than a
> direct connection between frontend and backend (and the backend would be
> QEMU crypto APIs, like Daniel suggested).
> 
My initial idea is support asynchronous crypto operation, so I used a queue to
cache the crypto packets like network did. Now I think again, either 
synchronous or asynchronous
operation is directly depend on the backend cryptodevs' capacity, we don't need
to use a queue to do that, but provide interfaces which include sync and async 
operations.

I'll drop the middle queue stuff. Thanks!

Regards,
-Gonglei

> Paolo
> 
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org

Re: [Qemu-devel] [PATCH v2 03/15] crypto: add cryptoLegacyHW stuff

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, September 13, 2016 5:23 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Huangpeng
> (Peter); Luonengjun; m...@redhat.com; stefa...@redhat.com;
> pbonz...@redhat.com; Huangweidong (C); mike.cara...@nxp.com;
> ag...@suse.de; xin.z...@intel.com; Claudio Fontana; nmo...@kalray.eu;
> vincent.jar...@6wind.com
> Subject: Re: [PATCH v2 03/15] crypto: add cryptoLegacyHW stuff
> 
> On Tue, Sep 13, 2016 at 11:52:09AM +0800, Gonglei wrote:
> > In previous patch, we define CryptoLegacyHWOptions in
> > qapi-schema.json. we introduce the new/delete funciton
> > about crypto legacy hardware device.
> 
> Isn't virtio-crypto / cryptodev an entirely new specification ?

Yes, it's an complete new device.

> I'm surprised to be seeing something completely new described
> as "legacy". Can you explain this in more detail.
> 
Because there are two kind of crypto device, one is virtio-crypto which is
a virtual crypto device (And virtio-crypto device is a real crypto device seen 
by the guest). 
The other is cryptodev backend device.  I have no good idea to name the kind
of virtio-crypto device, so named to legacy crypto device refer to Net stuff.

Do you have any suggestion? Thanks!

Regards,
-Gonglei

> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH v2 00/15] virtio-crypto: introduce framework and device emulation

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, September 13, 2016 5:54 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Huangpeng
> (Peter); Luonengjun; m...@redhat.com; stefa...@redhat.com;
> pbonz...@redhat.com; Huangweidong (C); mike.cara...@nxp.com;
> ag...@suse.de; xin.z...@intel.com; Claudio Fontana; nmo...@kalray.eu;
> vincent.jar...@6wind.com
> Subject: Re: [PATCH v2 00/15] virtio-crypto: introduce framework and device
> emulation
> 
> On Tue, Sep 13, 2016 at 09:45:05AM +, Gonglei (Arei) wrote:
> > Hi Daniel,
> >
> > Thanks for your comments fristly, please see my embedded reply.
> >
> > Regards,
> > -Gonglei
> >
> >
> > > -Original Message-
> > > From: Daniel P. Berrange [mailto:berra...@redhat.com]
> > > Sent: Tuesday, September 13, 2016 4:58 PM
> > > To: Gonglei (Arei)
> > > Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Huangpeng
> > > (Peter); Luonengjun; m...@redhat.com; stefa...@redhat.com;
> > > pbonz...@redhat.com; Huangweidong (C); mike.cara...@nxp.com;
> > > ag...@suse.de; xin.z...@intel.com; Claudio Fontana; nmo...@kalray.eu;
> > > vincent.jar...@6wind.com
> > > Subject: Re: [PATCH v2 00/15] virtio-crypto: introduce framework and 
> > > device
> > > emulation
> > >
> > > On Tue, Sep 13, 2016 at 11:52:06AM +0800, Gonglei wrote:
> > > > Changes since v1:
> > > >  - rmmove mixed endian-ness handler for virtio-crypto device, just
> > > >use little-endian. [mst]
> > > >  - add sg list support according virtio-crypto spec v10 (will be posted
> soon).
> > > >  - fix a memory leak in session handler.
> > > >  - add a feature page link in qemu.org
> > > (http://qemu-project.org/Features/VirtioCrypto)
> > > >  - fix some trivial problems, sush as 's/Since 2.7/Since 2.8/g' in
> > > qapi-schema.json
> > > >  - rebase the latest qemu master tree.
> > > >
> > > > Please review, thanks!
> > > >
> > > > This patch series realize the framework and emulation of a new
> > > > virtio crypto device, which is similar with virtio net device.
> > > >
> > > >  - I introduce the cryptodev backend as the client of virtio crypto 
> > > > device
> > > >which can be realized by different methods, such as cryptodev-linux 
> > > > in
> my
> > > series,
> > > >vhost-crypto kernel module, vhost-user etc.
> > > >  - The patch set abides by the virtio crypto speccification.
> > > >  - The virtio crypto support symmetric algorithms (including CIPHER and
> > > algorithm chainning)
> > > >at present, except HASH, MAC and AEAD services.
> > > >  - unsupport hot plug/unplug cryptodev client at this moment.
> > > >
> > > > Cryptodev-linux is a device that allows access to Linux kernel
> cryptographic
> > > drivers;
> > > > thus allowing of userspace applications to take advantage of hardware
> > > accelerators.
> > > > It can be found here:
> > > >
> > > >  http://cryptodev-linux.org/
> > > >
> > > > (please use the latest version)
> > > >
> > > > To use the cryptodev-linux as the client, the cryptodev.ko should be 
> > > > insert
> on
> > > the host.
> > > >
> > > >  # enter cryptodev-linux module root directory, then
> > > >  make;make install
> > >
> > >
> > > The cryptodev kernel module is not upstream and shows no sign of
> > > ever being likely to be accepted & merged upstream. On that basis,
> > > support for it in QEMU has a firm NACK from me, as trying to support
> > > out of tree kernel modules long term never ends well. This is
> > > particularly bad because it appears to be the only impl backend
> > > you've provided in this series.
> > >
> >
> > OK, I agree with you :)  But if we support multiple backends, can
> > we keep cryptodev-linux module as one option?
> 
> I'm personally against any support for out of tree kernel modules
> in QEMU, regardless of whether QEMU also implements alternative
> backends, unless there is a strong sign that the module in question
> is on the verge of being accepted into mainline Linux. That does
> not seem to be the case there - mainline settled on AF_ALG as the
> only supported approach AFAICT.
> 
OK.


Regards,
-Gonglei

> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH v2 03/15] crypto: add cryptoLegacyHW stuff

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, September 13, 2016 6:09 PM
> To: Gonglei (Arei)
> Subject: Re: [PATCH v2 03/15] crypto: add cryptoLegacyHW stuff
> 
> On Tue, Sep 13, 2016 at 10:05:01AM +, Gonglei (Arei) wrote:
> >
> >
> > > -Original Message-
> > > From: Daniel P. Berrange [mailto:berra...@redhat.com]
> > > Sent: Tuesday, September 13, 2016 5:23 PM
> > > To: Gonglei (Arei)
> > > Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Huangpeng
> > > (Peter); Luonengjun; m...@redhat.com; stefa...@redhat.com;
> > > pbonz...@redhat.com; Huangweidong (C); mike.cara...@nxp.com;
> > > ag...@suse.de; xin.z...@intel.com; Claudio Fontana; nmo...@kalray.eu;
> > > vincent.jar...@6wind.com
> > > Subject: Re: [PATCH v2 03/15] crypto: add cryptoLegacyHW stuff
> > >
> > > On Tue, Sep 13, 2016 at 11:52:09AM +0800, Gonglei wrote:
> > > > In previous patch, we define CryptoLegacyHWOptions in
> > > > qapi-schema.json. we introduce the new/delete funciton
> > > > about crypto legacy hardware device.
> > >
> > > Isn't virtio-crypto / cryptodev an entirely new specification ?
> >
> > Yes, it's an complete new device.
> >
> > > I'm surprised to be seeing something completely new described
> > > as "legacy". Can you explain this in more detail.
> > >
> > Because there are two kind of crypto device, one is virtio-crypto which is
> > a virtual crypto device (And virtio-crypto device is a real crypto device 
> > seen by
> the guest).
> > The other is cryptodev backend device.  I have no good idea to name the
> kind
> > of virtio-crypto device, so named to legacy crypto device refer to Net 
> > stuff.
> >
> > Do you have any suggestion? Thanks!
> 
> How about just calling it 'Backend' instead of 'Legacy' then ?
> 
It sounds reasonable I think. Because the virtio specification usually say
The backend device and The frontend driver

So let's:

s/cryptoLegacyHW/cryptoBackendHW/g


Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v2 01/15] crypto: introduce cryptodev backend and crypto legacy hardware

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, September 13, 2016 5:59 PM
> Subject: Re: [PATCH v2 01/15] crypto: introduce cryptodev backend and crypto
> legacy hardware
> 
> On Tue, Sep 13, 2016 at 09:55:27AM +, Gonglei (Arei) wrote:
> >
> > >
> > > From: Daniel P. Berrange [mailto:berra...@redhat.com]
> > > Sent: Tuesday, September 13, 2016 5:14 PM
> > > Subject: Re: [PATCH v2 01/15] crypto: introduce cryptodev backend and
> crypto
> > > legacy hardware
> > >
> > > On Tue, Sep 13, 2016 at 11:52:07AM +0800, Gonglei wrote:
> > > > cryptodev backend is used to realize the active work for
> > > > virtual crypto device. CryptoLegacyHW device is a cryptographic
> > > > hardware device seen by the virtual machine.
> > > > The relationship between cryptodev backend and legacy hadware
> > > > as follow:
> > > >  crypto_legacy_hw device (1)--->(n) cryptodev client backend
> > > >
> > > > Signed-off-by: Gonglei 
> > >
> > > > diff --git a/crypto/crypto.c b/crypto/crypto.c
> > > > new file mode 100644
> > > > index 000..fbc6497
> > > > --- /dev/null
> > > > +++ b/crypto/crypto.c
> > > > @@ -0,0 +1,171 @@
> > > > +/*
> > > > + * QEMU Crypto Device Implement
> > > > + *
> > > > + * Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
> > > > + *
> > > > + * Authors:
> > > > + *Gonglei 
> > > > + *
> > > > + * Permission is hereby granted, free of charge, to any person 
> > > > obtaining
> a
> > > copy
> > > > + * of this software and associated documentation files (the 
> > > > "Software"),
> to
> > > deal
> > > > + * in the Software without restriction, including without limitation 
> > > > the
> rights
> > > > + * to use, copy, modify, merge, publish, distribute, sublicense, 
> > > > and/or sell
> > > > + * copies of the Software, and to permit persons to whom the Software 
> > > > is
> > > > + * furnished to do so, subject to the following conditions:
> > > > + *
> > > > + * The above copyright notice and this permission notice shall be 
> > > > included
> in
> > > > + * all copies or substantial portions of the Software.
> > > > + *
> > > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> > > EXPRESS OR
> > > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > > MERCHANTABILITY,
> > > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
> NO
> > > EVENT SHALL
> > > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > > DAMAGES OR OTHER
> > > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> OTHERWISE,
> > > ARISING FROM,
> > > > + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > > OTHER DEALINGS IN
> > > > + * THE SOFTWARE.
> > > > + */
> > >
> > > New files are expected to be submitted under the GPLv2+ license,
> > > unless they're header files imported from an external project,
> > > which this is not.
> > >
> > > The same license mistake is made across other files / patches
> > > in this series, so I won't repeat the comment - just fix all
> > > of them to be GPLv2+ please.
> > >
> > > > +#include "qemu/osdep.h"
> > > > +#include "sysemu/sysemu.h"
> > > > +#include "qapi/error.h"
> > > > +#include "qemu/iov.h"
> > > > +#include "qapi-visit.h"
> > > > +#include "qapi/opts-visitor.h"
> > > > +
> > > > +#include "crypto/crypto.h"
> > > > +#include "qemu/config-file.h"
> > > > +#include "monitor/monitor.h"
> > > > +
> > > > +
> > > > +static QTAILQ_HEAD(, CryptoClientState) crypto_clients;
> > > > +
> > > > +QemuOptsList qemu_cryptodev_opts = {
> > > > +.name = "cryptodev",
> > > > +.implied_opt_name = "type",
> > > > +.head = QTAILQ_HEAD_INITIALIZER(qemu_cryptodev_opts.head),
> > > > +.desc = {
> > > > +/*
> > > > + * no elements 

Re: [Qemu-devel] [PATCH v2 02/15] crypto: introduce crypto queue handler

[Gonglei (Arei)]

Hi,

All comments are accepted :)


Regards,
-Gonglei


> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, September 13, 2016 5:21 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Huangpeng
> (Peter); Luonengjun; m...@redhat.com; stefa...@redhat.com;
> pbonz...@redhat.com; Huangweidong (C); mike.cara...@nxp.com;
> ag...@suse.de; xin.z...@intel.com; Claudio Fontana; nmo...@kalray.eu;
> vincent.jar...@6wind.com
> Subject: Re: [PATCH v2 02/15] crypto: introduce crypto queue handler
> 
> On Tue, Sep 13, 2016 at 11:52:08AM +0800, Gonglei wrote:
> > crypto queue is a gallery used for executing crypto
> > operation, which supports both synchronization and
> > asynchronization. The thoughts stolen from net/queue.c
> >
> > Signed-off-by: Gonglei 
> > ---
> >  crypto/Makefile.objs  |   1 +
> >  crypto/crypto-queue.c | 206
> ++
> >  crypto/crypto.c   |  28 ++
> >  include/crypto/crypto-queue.h |  69 ++
> >  include/crypto/crypto.h   |  12 +++
> >  5 files changed, 316 insertions(+)
> >  create mode 100644 crypto/crypto-queue.c
> >  create mode 100644 include/crypto/crypto-queue.h
> >
> 
> > diff --git a/include/crypto/crypto-queue.h b/include/crypto/crypto-queue.h
> > new file mode 100644
> > index 000..6fba64d
> > --- /dev/null
> > +++ b/include/crypto/crypto-queue.h
> > @@ -0,0 +1,69 @@
> > +/*
> > + * Copyright (c) 2003-2008 Fabrice Bellard
> > + * Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
> > + *
> > + * Authors:
> > + *Gonglei 
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> > + * of this software and associated documentation files (the "Software"), to
> deal
> > + * in the Software without restriction, including without limitation the 
> > rights
> > + * to use, copy, modify, merge, publish, distribute, sublicense, and/or 
> > sell
> > + * copies of the Software, and to permit persons to whom the Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included 
> > in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING FROM,
> > + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER DEALINGS IN
> > + * THE SOFTWARE.
> > + */
> 
> Again, wrong license header.
> 
> > +#ifndef QEMU_CRYPTO_QUEUE_H
> > +#define QEMU_CRYPTO_QUEUE_H
> > +
> > +#include "qemu-common.h"
> > +
> > +typedef struct CryptoPacket CryptoPacket;
> > +typedef struct CryptoQueue CryptoQueue;
> > +typedef struct CryptoPacketBuf CryptoPacketBuf;
> > +
> > +typedef void (CryptoPacketSent) (CryptoClientState *, int);
> 
> As previously, I'd expect naming of
> 
>  QCryptoCryptodevPacket
>  QCryptoCryptodevPacketBuf
>  QCryptoCryptodevQueue
> 
> > +
> > +
> > +/* Returns:
> > + *   >0 - success
> > + *0 - queue packet for future redelivery
> > + *   <0 - failure (discard packet)
> > + */
> > +typedef int (CryptoQueueDeliverFunc)(CryptoClientState *sender,
> > + unsigned flags,
> > + void *header_opaque,
> > + void *opaque);
> > +
> > +CryptoQueue *
> > +qemu_new_crypto_queue(CryptoQueueDeliverFunc *deliver, void *opaque);
> > +
> > +void qemu_crypto_queue_cache(CryptoQueue *queue,
> > +   unsigned flags,
> > +   CryptoClientState *sender,
> > +   void *opaque,
> > +   CryptoPacketSent *sent_cb);
> > +
> > +void qemu_del_crypto_queue(CryptoQueue *queue);
> > +
> > +int qemu_crypto_queue_send(CryptoQueue *queue,
> > +unsigned flags,
> > +CryptoClientState *sende

Re: [Qemu-devel] [PATCH v2 01/15] crypto: introduce cryptodev backend and crypto legacy hardware

[Gonglei (Arei)]

>
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, September 13, 2016 5:14 PM
> Subject: Re: [PATCH v2 01/15] crypto: introduce cryptodev backend and crypto
> legacy hardware
> 
> On Tue, Sep 13, 2016 at 11:52:07AM +0800, Gonglei wrote:
> > cryptodev backend is used to realize the active work for
> > virtual crypto device. CryptoLegacyHW device is a cryptographic
> > hardware device seen by the virtual machine.
> > The relationship between cryptodev backend and legacy hadware
> > as follow:
> >  crypto_legacy_hw device (1)--->(n) cryptodev client backend
> >
> > Signed-off-by: Gonglei 
> 
> > diff --git a/crypto/crypto.c b/crypto/crypto.c
> > new file mode 100644
> > index 000..fbc6497
> > --- /dev/null
> > +++ b/crypto/crypto.c
> > @@ -0,0 +1,171 @@
> > +/*
> > + * QEMU Crypto Device Implement
> > + *
> > + * Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
> > + *
> > + * Authors:
> > + *Gonglei 
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> > + * of this software and associated documentation files (the "Software"), to
> deal
> > + * in the Software without restriction, including without limitation the 
> > rights
> > + * to use, copy, modify, merge, publish, distribute, sublicense, and/or 
> > sell
> > + * copies of the Software, and to permit persons to whom the Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included 
> > in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING FROM,
> > + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER DEALINGS IN
> > + * THE SOFTWARE.
> > + */
> 
> New files are expected to be submitted under the GPLv2+ license,
> unless they're header files imported from an external project,
> which this is not.
> 
> The same license mistake is made across other files / patches
> in this series, so I won't repeat the comment - just fix all
> of them to be GPLv2+ please.
> 
> > +#include "qemu/osdep.h"
> > +#include "sysemu/sysemu.h"
> > +#include "qapi/error.h"
> > +#include "qemu/iov.h"
> > +#include "qapi-visit.h"
> > +#include "qapi/opts-visitor.h"
> > +
> > +#include "crypto/crypto.h"
> > +#include "qemu/config-file.h"
> > +#include "monitor/monitor.h"
> > +
> > +
> > +static QTAILQ_HEAD(, CryptoClientState) crypto_clients;
> > +
> > +QemuOptsList qemu_cryptodev_opts = {
> > +.name = "cryptodev",
> > +.implied_opt_name = "type",
> > +.head = QTAILQ_HEAD_INITIALIZER(qemu_cryptodev_opts.head),
> > +.desc = {
> > +/*
> > + * no elements => accept any params
> > + * validation will happen later
> > + */
> > +{ /* end of list */ }
> > +},
> > +};
> 
> No new code should be adding more command line options for
> device backends.
> 
> Your backend impl should be using QOM to define a object,
> which can be created via the -object command line arg,
> or object_add monitor command.
> 
Any backgrounds about this rule? Maybe I missed something.

> If you're not familiar with this, take a look at the
> crypto/secret.c file which is a pretty simple example of
> how to use QOM to define a new user creatable object.
> 
OK, thanks.

> I'm going to skip reviewing any of the .c code in the
> crypto/ dir for now, since that will all change quite a
> bit when you switch over to QOM.
> 
OK.

> > diff --git a/include/crypto/crypto.h b/include/crypto/crypto.h
> > new file mode 100644
> > index 000..f93f6f9
> > --- /dev/null
> > +++ b/include/crypto/crypto.h
> 
> > +#ifndef QCRYPTO_CRYPTO_H__
> > +#define QCRYPTO_CRYPTO_H__
> > +
> > +#include "qemu/queue.h"
> > +#include "qapi-types.h"
> > +
> > +typedef void (CryptoPoll)(CryptoClientState *, bool);
> > +typedef void (CryptoCleanup) (CryptoClientState *);
> > +typedef void (CryptoClientDestructor)(CryptoClientState *);
> > +typedef void (CryptoHWStatusChanged)(CryptoClientState *);
> > +
> > +typedef struct CryptoClientInfo {
> > +CryptoClientOptionsKind type;
> > +size_t size;
> > +
> > +CryptoCleanup *cleanup;
> > +CryptoPoll *poll;
> > +CryptoHWStatusChanged *hw_status_changed;
> > +} CryptoClientInfo;
> > +
> > +struct CryptoClientState {
> > +CryptoClientInfo *info;
> > +int ready;
> > +QTAILQ_ENTRY(CryptoClientState) next;
> > +CryptoClientState *peer;
> > +char *model;
> > +char *name;
> > +char info_str[256];
> > +CryptoClientDestructor *destructor;
> > +};
> > +
> > +int crypto_client_init(QemuOpts 

Re: [Qemu-devel] [PATCH v2 00/15] virtio-crypto: introduce framework and device emulation

[Gonglei (Arei)]

Hi Daniel,

Thanks for your comments fristly, please see my embedded reply.

Regards,
-Gonglei


> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Tuesday, September 13, 2016 4:58 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; Huangpeng
> (Peter); Luonengjun; m...@redhat.com; stefa...@redhat.com;
> pbonz...@redhat.com; Huangweidong (C); mike.cara...@nxp.com;
> ag...@suse.de; xin.z...@intel.com; Claudio Fontana; nmo...@kalray.eu;
> vincent.jar...@6wind.com
> Subject: Re: [PATCH v2 00/15] virtio-crypto: introduce framework and device
> emulation
> 
> On Tue, Sep 13, 2016 at 11:52:06AM +0800, Gonglei wrote:
> > Changes since v1:
> >  - rmmove mixed endian-ness handler for virtio-crypto device, just
> >use little-endian. [mst]
> >  - add sg list support according virtio-crypto spec v10 (will be posted 
> > soon).
> >  - fix a memory leak in session handler.
> >  - add a feature page link in qemu.org
> (http://qemu-project.org/Features/VirtioCrypto)
> >  - fix some trivial problems, sush as 's/Since 2.7/Since 2.8/g' in
> qapi-schema.json
> >  - rebase the latest qemu master tree.
> >
> > Please review, thanks!
> >
> > This patch series realize the framework and emulation of a new
> > virtio crypto device, which is similar with virtio net device.
> >
> >  - I introduce the cryptodev backend as the client of virtio crypto device
> >which can be realized by different methods, such as cryptodev-linux in my
> series,
> >vhost-crypto kernel module, vhost-user etc.
> >  - The patch set abides by the virtio crypto speccification.
> >  - The virtio crypto support symmetric algorithms (including CIPHER and
> algorithm chainning)
> >at present, except HASH, MAC and AEAD services.
> >  - unsupport hot plug/unplug cryptodev client at this moment.
> >
> > Cryptodev-linux is a device that allows access to Linux kernel cryptographic
> drivers;
> > thus allowing of userspace applications to take advantage of hardware
> accelerators.
> > It can be found here:
> >
> >  http://cryptodev-linux.org/
> >
> > (please use the latest version)
> >
> > To use the cryptodev-linux as the client, the cryptodev.ko should be insert 
> > on
> the host.
> >
> >  # enter cryptodev-linux module root directory, then
> >  make;make install
> 
> 
> The cryptodev kernel module is not upstream and shows no sign of
> ever being likely to be accepted & merged upstream. On that basis,
> support for it in QEMU has a firm NACK from me, as trying to support
> out of tree kernel modules long term never ends well. This is
> particularly bad because it appears to be the only impl backend
> you've provided in this series.
> 

OK, I agree with you :)  But if we support multiple backends, can
we keep cryptodev-linux module as one option?

> IMHO, the first default backend should ought to use the internal
> QEMU crypto APIs for its impl, which delegate to nettle/gcrypt,
> which in turn can take care of using the kernel for acceleration
> if they so choose.
> 
Will work on this later.

> > then configuring QEMU shows:
> >
> >  [...]
> >  jemalloc support  no
> >  avx2 optimization no
> >  cryptodev-linux support yes
> >
> > QEMU can then be started using the following parameters:
> >
> > qemu-system-x86_64 \
> > [...] \
> > -cryptodev type=cryptodev-linux,id=cryptodev0 \
> > -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \
> > [...]
> >
> > The front-end linux kernel driver (Experimental at present) is publicly
> accessible from:
> >
> >https://github.com/gongleiarei/virtio-crypto-linux-driver.git
> >
> > After insmod virtio-crypto.ko, you also can use cryptodev-linux test the 
> > crypto
> function
> > in the guest. For example:
> 
> 
> >
> > linux-guest:/home/gonglei/cryptodev-linux/tests # ./cipher -
> > requested cipher CRYPTO_AES_CBC, got cbc(aes) with driver
> virtio_crypto_aes_cbc
> > AES Test passed
> > requested cipher CRYPTO_AES_CBC, got cbc(aes) with driver
> virtio_crypto_aes_cbc
> > requested cipher CRYPTO_AES_CBC, got cbc(aes) with driver
> virtio_crypto_aes_cbc
> > Test passed
> >
> > QEMU code also can be accessible from:
> >
> >  https://github.com/gongleiarei/qemu.git
> >
> >  branch virtio-crypto
> >
> > For more information, please see:
> >  http://qemu-project.org/Features/VirtioCrypto
> >
> >
> > Gonglei (15):
>

Re: [Qemu-devel] [PATCH v9 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi Xin,

Will fix in the next version, thanks!


Regards,
-Gonglei

> -Original Message-
> From: Zeng, Xin [mailto:xin.z...@intel.com]
> Sent: Friday, September 09, 2016 4:26 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org
> Cc: Huangpeng (Peter); Luonengjun; m...@redhat.com;
> cornelia.h...@de.ibm.com; stefa...@redhat.com;
> denglin...@chinamobile.com; Jani Kokkonen; ola.liljed...@arm.com;
> varun.se...@freescale.com; Keating, Brian A; Ma, Liang J; Griffin, John;
> Hanweidong (Randy); Huangweidong (C); mike.cara...@nxp.com;
> ag...@suse.de; Claudio Fontana
> Subject: RE: [PATCH v9 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> On Thursday, September 08, 2016 6:05 PM, Gonglei Wrote:
> 
> > +The below AEAD algorithms are defined currently:
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_NO_AEAD 0
> > +#define VIRTIO_CRYPTO_AEAD_GCM1
> > +#define VIRTIO_CRYPTO_AEAD_CCM2
> > +#define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3
> > +\end{lstlisting}
> > +
> > +\devicenormative{\subsection}{Device Requirements: Device configuration
> > layout}\label{sec:Device Types / Crypto Device / Device configuration 
> > layout /
> > Device Requirements: Device configuration layout}
> 
> Xelatex complains " Argument of \label has an extra } ", need fix.
> Same complaints below when using devicenormative and  label.
> 
> > +
> > +\begin{itemize*}
> > +\item The device MUST set \field{max_dataqueues} to between 1 and 65535
> > inclusive.
> > +\item The device SHOULD set \field{status} according to the status of the
> > hardware-backed implementation.
> > +\item The device MUST set \field{crypto_services} according to the crypto
> > services which the device offered.
> > +\item The device MUST set detailed algorithms mask according to
> > \field{crypto_services} field.
> > +\end{itemize*}
> > +
> > +\drivernormative{\subsection}{Driver Requirements: Device configuration
> > layout}\label{sec:Device Types / Crypto Device / Device configuration 
> > layout /
> > Driver Requirements: Device configuration layout}
> > +
> > +\begin{itemize*}
> > +\item The driver MUST read the ready \field{status} from the bottom bit of
> > status to
> > +  check whether the hardware-backed implementation is ready or not.
> > +\item The driver MAY read \field{max_dataqueues} field to discover how
> > many data queues the device supports.
> > +\item The driver MUST read \field{crypto_services} field to discover which
> > services the device is able to offer.
> > +\item The driver MUST read the detailed \field{algorithms} field according 
> > to
> > \field{crypto_services} field.
> > +\end{itemize*}
> > +
> > +\subsection{Device Initialization}\label{sec:Device Types / Crypto Device /
> > Device Initialization}
> > +
> > +\subsubsection{Driver Requirements: Device Initialization}\label{sec:Device
> > Types / Crypto Device / Device Initialization / Driver Requirements: Device
> > Initialization}
> > +
> > +\begin{itemize*}
> > +\item The driver MUST identify and initialize up to \field{max_dataqueues}
> > data virtqueues.
> > +\item The driver MUST identify the control virtqueue.
> > +\item The driver MUST identify the ready status of hardware-backend from
> > \field{status} field.
> > +\item The driver MUST read the supported crypto services from bits of
> > \field{crypto_servies}.
> > +\item The driver MUST read the supported algorithms according to
> > \field{crypto_services} field.
> > +\end{itemize*}
> > +
> > +\subsubsection{Device Requirements: Device Initialization}\label{sec:Device
> > Types / Crypto Device / Device Initialization / Device Requirements: Device
> > Initialization}
> > +
> > +\begin{itemize*}
> > +\item The device MUST be configured at least one accelerator which
> executes
> > real crypto operations.
> > +\item The device MUST write the \field{crypto_services} field according to
> the
> > capacities of the backend accelerator.
> > +\end{itemize*}
> > +
> > +\subsection{Device Operation}\label{sec:Device Types / Crypto Device /
> > Device Operation}
> > +
> > +Packets can be transmitted by placing them in both the controlq and dataq.
> > +Packets consist of a generic header and a service-specific request.
> > +Where 'general header' is for all crypto requests, 'service specific 
> > requests'
> > +are composed of operation parameter + output data + input

Re: [Qemu-devel] [PATCH v2 2/2] e1000: fix buliding complaint

[Gonglei (Arei)]

Who can pick up this patch? Dmitry or Jason? Thanks!


Regards,
-Gonglei


> -Original Message-
> From: Dmitry Fleytman [mailto:dmi...@daynix.com]
> Sent: Wednesday, August 31, 2016 8:59 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; berra...@redhat.com
> Subject: Re: [PATCH v2 2/2] e1000: fix buliding complaint
> 
> Reviewed-by: Dmitry Fleytman 
> 
> > On 30 Aug 2016, at 07:10 AM, Gonglei  wrote:
> >
> > hw/net/e1000e_core.c:56: warning: e1000e_set_interrupt_cause declared
> inline after being called
> > hw/net/e1000e_core.c:56: warning: previous declaration of
> e1000e_set_interrupt_cause was here
> >
> > Signed-off-by: Gonglei 
> > ---
> > hw/net/e1000e_core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
> > index badb1fe..825e169 100644
> > --- a/hw/net/e1000e_core.c
> > +++ b/hw/net/e1000e_core.c
> > @@ -2168,7 +2168,7 @@ e1000e_update_interrupt_state(E1000ECore
> *core)
> > }
> > }
> >
> > -static inline void
> > +static void
> > e1000e_set_interrupt_cause(E1000ECore *core, uint32_t val)
> > {
> > trace_e1000e_irq_set_cause_entry(val, core->mac[ICR]);
> > --
> > 1.7.12.4
> >
> >

Re: [Qemu-devel] [PATCH for-2.7] vnc: fix qemu crash because of SIGSEGV

[Gonglei (Arei)]

Hi Gerd,

Can you pls pick up this patch? thanks

Regards,
-Gonglei


> -Original Message-
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Friday, September 02, 2016 8:39 PM
> To: Marc-André Lureau
> Cc: Gonglei (Arei); QEMU Developers; Huangweidong (C); Gerd Hoffmann
> Subject: Re: [Qemu-devel] [PATCH for-2.7] vnc: fix qemu crash because of
> SIGSEGV
> 
> On 2 September 2016 at 13:34, Marc-André Lureau
>  wrote:
> > Hi
> >
> > On Fri, Sep 2, 2016 at 3:04 PM Gonglei  wrote:
> >
> >>
> >> > It looks like this is not a regression from 2.7, perhaps it should be
> >> post-poned?
> >> >
> >> Yes, it's not a regression from 2.7, but it indeed is a serious bug and
> >> the fix is harmless. :)
> >>
> >>
> > The timing is bad. Unless Gerd or a maintainer sends a pull request today
> > with it, it's probably not going to make it in 2.7 (due today according to
> > planning).
> 
> For a non-regression this would have had to be sent at least a
> week ago to have had a chance of getting into 2.7. I would only accep
> anything into 2.7 now if it was an absolute release-breaker
> (eg "crashes on startup for 50% of users"); this is a long way from
> that. 2.8 and cc qemu-stable, please.
> 
> thanks
> -- PMM

Re: [Qemu-devel] [PATCH v9 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Friday, September 09, 2016 11:43 AM
> Subject: Re: [PATCH v9 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> On Fri, Sep 09, 2016 at 02:42:41AM +, Gonglei (Arei) wrote:
> > Hi Michael,
> >
> >
> > > -Original Message-
> > > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > > Sent: Friday, September 09, 2016 12:44 AM
> > > Subject: Re: [PATCH v9 1/2] virtio-crypto: Add virtio crypto device
> specification
> > >
> > > On Thu, Sep 08, 2016 at 06:05:14PM +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.
> > > >
> > > > Signed-off-by: Gonglei 
> > > > 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 
> > > > CC: Mihai Claudiu Caraman 
> > >
> > > I mostly looked at the conformance clauses.
> > > Here are some comments worth addressing.
> > >
> > Good, Thanks !
> >
> > > Thanks!
> > >
> > > > ---
> > > >  content.tex   |   2 +
> > > >  virtio-crypto.tex | 926
> > > ++
> > > >  2 files changed, 928 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..eec4741
> > > > --- /dev/null
> > > > +++ b/virtio-crypto.tex
> > > > @@ -0,0 +1,926 @@
> > > > +\section{Crypto Device}\label{sec:Device Types / Crypto Device}
> > > > +
> > > > +The virtio crypto device is a virtual crypto device, and is a kind of
> > > > +virtual hardware accelerator for virtual machines.  The encryption and
> > > > +decryption requests are placed in the data queue, and handled by the
> > > > +real crypto accelerators finally. The second queue is the control 
> > > > queue,
> > > > +which is used to create or destroy sessions for symmetric algorithms,
> and
> > > > +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]
> > > > +\item[N-1] dataqN
> > > > +\item[N] controlq
> > > > +\end{description}
> > > > +
> > > > +N is set by \field{max_dataqueues}.
> > > > +
> > > > +\subsection{Feature bits}\label{sec:Device Types / Crypto Device /
> Feature
> > > bits}
> > > > +  None currently defined
> > > > +
> > > > +\subsection{Device configuration layout}\label{sec:Device Types / 
> > > > Crypto
> > > Device / Device configuration layout}
> > > >

Re: [Qemu-devel] [PATCH v9 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi Michael,


> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Friday, September 09, 2016 12:44 AM
> Subject: Re: [PATCH v9 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> On Thu, Sep 08, 2016 at 06:05:14PM +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.
> >
> > Signed-off-by: Gonglei 
> > 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 
> > CC: Mihai Claudiu Caraman 
> 
> I mostly looked at the conformance clauses.
> Here are some comments worth addressing.
> 
Good, Thanks !

> Thanks!
> 
> > ---
> >  content.tex   |   2 +
> >  virtio-crypto.tex | 926
> ++
> >  2 files changed, 928 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..eec4741
> > --- /dev/null
> > +++ b/virtio-crypto.tex
> > @@ -0,0 +1,926 @@
> > +\section{Crypto Device}\label{sec:Device Types / Crypto Device}
> > +
> > +The virtio crypto device is a virtual crypto device, and is a kind of
> > +virtual hardware accelerator for virtual machines.  The encryption and
> > +decryption requests are placed in the data queue, and handled by the
> > +real crypto accelerators finally. The second queue is the control queue,
> > +which is used to create or destroy sessions for symmetric algorithms, and
> > +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]
> > +\item[N-1] dataqN
> > +\item[N] controlq
> > +\end{description}
> > +
> > +N is set by \field{max_dataqueues}.
> > +
> > +\subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature
> bits}
> > +  None currently defined
> > +
> > +\subsection{Device configuration layout}\label{sec:Device Types / Crypto
> Device / Device configuration layout}
> > +
> > +The following driver-read-only configuration fields are currently defined.
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_config {
> > +le32  status;
> > +le32  max_dataqueues;
> > +le32  crypto_services;
> > +/* detailed algorithms mask */
> > +le32 cipher_algo_l;
> > +le32 cipher_algo_h;
> > +le32 hash_algo;
> > +le32 mac_algo_l;
> > +le32 mac_algo_h;
> > +le32 asym_algo;
> > +le32 kdf_algo;
> > +le32 aead_algo;
> > +le32 primitive_algo;
> > +};
> > +\end{lstlisting}
> > +
> > +The first field, \field{status} is currently defined:
> VIRTIO_CRYPTO_S_HW_READY
> > +and VIRTIO_CRYPTO_S_STARTED.
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_S_HW_READY  (1 << 0)
> > +#define VIRTIO_CRYPTO_S_STARTED  (1 << 1)
> > +\end{lstlisting}
> > +
> > +The following driver-read-only field, \field{max_dataqueuess} specifies the
> > +maximum number of data virtqueues (dataq1\ldots dataqN). The
> \field{crypto_services}
> > +shows the crypto service the virtio crypto supports. The service currently
> > +defined are:
> 
> I'm not a native english speaker myself but I can tell there are some
> mistakes in english in this text. Could you pls get a native speaker go
> over the text for you? We'll likely get it corrected during public
> review anyway, but it's better to fix them early.
> 
Yes, you are right. I'll do this thing before next version's publication, hope 
it's not too late. :)
> 
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_SERVICE_CIPHER (0) /* cipher service */
> > +#define VIRTIO_CRYPTO_SERVICE_HASH   (1) /* hash service */
> 
> You write cipher and hash here, but elsewhere in text you
> refer to them as CIPHER and HASH.
> 
> > +#define VIRTIO_CRYPTO_SERVICE_MAC(2) /* MAC (Message
> Authentication Codes) service */
> > +#define VIRT

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v1 11/14] virtio-crypto: add control queue handler

[Gonglei (Arei)]

> -Original Message-
> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Michael S. Tsirkin
> Sent: Thursday, September 08, 2016 12:30 PM
> To: Gonglei (Arei)
> Subject: [virtio-dev] Re: [PATCH v1 11/14] virtio-crypto: add control queue
> handler
> 
> On Thu, Sep 08, 2016 at 11:42:33AM +0800, Gonglei wrote:
> > +info->cipher_alg = virtio_ldl_p(vdev, &cipher_para->algo);
> > +info->key_len = virtio_ldl_p(vdev, &cipher_para->keylen);
> > +info->direction = virtio_ldl_p(vdev, &cipher_para->op);
> 
> There is no reason to use the virtio mixed endian-ness for
> modern devices. Just use little-endian everywhere.
> 
Okay, thanks :)


Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v2 1/2] crypto: fix building complaint

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Monday, September 05, 2016 7:04 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org
> Subject: Re: [PATCH v2 1/2] crypto: fix building complaint
> 
> On Mon, Sep 05, 2016 at 10:50:54AM +, Gonglei (Arei) wrote:
> >
> >
> > > -Original Message-
> > > From: Daniel P. Berrange [mailto:berra...@redhat.com]
> > > Sent: Monday, September 05, 2016 6:15 PM
> > > To: Gonglei (Arei)
> > > Cc: qemu-devel@nongnu.org; dmi...@daynix.com
> > > Subject: Re: [PATCH v2 1/2] crypto: fix building complaint
> > >
> > > On Tue, Aug 30, 2016 at 12:10:52PM +0800, Gonglei wrote:
> > > > gnutls commit 846753877d renamed LIBGNUTLS_VERSION_NUMBER to
> > > GNUTLS_VERSION_NUMBER.
> > > > If using gnutls before that verion, we'll get the below warning:
> > > > crypto/tlscredsx509.c:618:5: warning: "GNUTLS_VERSION_NUMBER" is
> not
> > > defined
> > > >
> > > > Signed-off-by: Gonglei 
> > > > ---
> > > >  crypto/tlscredsx509.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/crypto/tlscredsx509.c b/crypto/tlscredsx509.c
> > > > index 520d34d..f2fd80f 100644
> > > > --- a/crypto/tlscredsx509.c
> > > > +++ b/crypto/tlscredsx509.c
> > > > @@ -615,7 +615,7 @@
> qcrypto_tls_creds_x509_load(QCryptoTLSCredsX509
> > > *creds,
> > > >  }
> > > >
> > > >  if (cert != NULL && key != NULL) {
> > > > -#if GNUTLS_VERSION_NUMBER >= 0x030111
> > > > +#if defined(GNUTLS_VERSION_NUMBER) &&
> > > GNUTLS_VERSION_NUMBER >= 0x030111
> > > >  char *password = NULL;
> > > >  if (creds->passwordid) {
> > > >  password =
> > > qcrypto_secret_lookup_as_utf8(creds->passwordid,
> > >
> > > Other places in this file still use LIBGNUTLS_VERSION_NUMBER, which is
> > > good, because gnutls 3.x still defines LIBGNUTLS_VERSION_NUMBER for
> > > back compat.
> > >
> > You mean using LIBGNUTLS_VERSION_NUMBER directly here? That's ok.
> 
> Yes,
> 
> > > The tests/test-crypto-tlscredsx509.c file also needs a similar fix.
> > >
> > Sorry?
> 
> It also uses the GNUTLS_VERSION_NUMBER constant instead of
> LIBGNUTLS_VERSION_NUMBER
> 

What about the below patch?

diff --git a/crypto/init.c b/crypto/init.c
index 1e564d9..16e099b 100644
--- a/crypto/init.c
+++ b/crypto/init.c
@@ -59,8 +59,7 @@
 
 #if (defined(CONFIG_GCRYPT) &&  \
  (!defined(CONFIG_GNUTLS) ||\
-  !defined(GNUTLS_VERSION_NUMBER) ||   \
-  (GNUTLS_VERSION_NUMBER < 0x020c00)) &&\
+ (LIBGNUTLS_VERSION_NUMBER < 0x020c00)) &&\
  (!defined(GCRYPT_VERSION_NUMBER) ||\
   (GCRYPT_VERSION_NUMBER < 0x010600)))
 #define QCRYPTO_INIT_GCRYPT_THREADS
diff --git a/crypto/tlscredsx509.c b/crypto/tlscredsx509.c
index 520d34d..50eb54f 100644
--- a/crypto/tlscredsx509.c
+++ b/crypto/tlscredsx509.c
@@ -615,7 +615,7 @@ qcrypto_tls_creds_x509_load(QCryptoTLSCredsX509 *creds,
 }
 
 if (cert != NULL && key != NULL) {
-#if GNUTLS_VERSION_NUMBER >= 0x030111
+#if LIBGNUTLS_VERSION_NUMBER >= 0x030111
 char *password = NULL;
 if (creds->passwordid) {
 password = qcrypto_secret_lookup_as_utf8(creds->passwordid,
@@ -630,7 +630,7 @@ qcrypto_tls_creds_x509_load(QCryptoTLSCredsX509 *creds,
 password,
 0);
 g_free(password);
-#else /* GNUTLS_VERSION_NUMBER < 0x030111 */
+#else /* LIBGNUTLS_VERSION_NUMBER < 0x030111 */
 if (creds->passwordid) {
 error_setg(errp, "PKCS8 decryption requires GNUTLS >= 3.1.11");
 goto cleanup;
@@ -638,7 +638,7 @@ qcrypto_tls_creds_x509_load(QCryptoTLSCredsX509 *creds,
 ret = gnutls_certificate_set_x509_key_file(creds->data,
cert, key,
GNUTLS_X509_FMT_PEM);
-#endif /* GNUTLS_VERSION_NUMBER < 0x030111 */
+#endif
 if (ret < 0) {
 error_setg(errp, "Cannot load certificate '%s' & key '%s': %s",
cert, key, gnutls_strerror(ret));
diff --git a/tests/crypto-tls-x509-helpers.h b/tests/crypto-tls-x509-helpers.h
index 356b49c..a8faa92 100644
--- a/tests/crypto-tls-x509-helpers.h
+++ b/tests/crypto-tls-x509-helpers.h
@@ -26,7 +26,6 @@
 
 #if !(defined WIN32) && \
 defined(CONFIG_TASN1) && \
-defined(LIBGNUTLS_VERSION_NUMBER) && \
 (LIBGNUTLS_VERSION_NUMBER >= 0x020600)
 # define QCRYPTO_HAVE_TLS_TEST_SUPPORT
 #endif


> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH v2 1/2] crypto: fix building complaint

[Gonglei (Arei)]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Monday, September 05, 2016 6:15 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; dmi...@daynix.com
> Subject: Re: [PATCH v2 1/2] crypto: fix building complaint
> 
> On Tue, Aug 30, 2016 at 12:10:52PM +0800, Gonglei wrote:
> > gnutls commit 846753877d renamed LIBGNUTLS_VERSION_NUMBER to
> GNUTLS_VERSION_NUMBER.
> > If using gnutls before that verion, we'll get the below warning:
> > crypto/tlscredsx509.c:618:5: warning: "GNUTLS_VERSION_NUMBER" is not
> defined
> >
> > Signed-off-by: Gonglei 
> > ---
> >  crypto/tlscredsx509.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/crypto/tlscredsx509.c b/crypto/tlscredsx509.c
> > index 520d34d..f2fd80f 100644
> > --- a/crypto/tlscredsx509.c
> > +++ b/crypto/tlscredsx509.c
> > @@ -615,7 +615,7 @@ qcrypto_tls_creds_x509_load(QCryptoTLSCredsX509
> *creds,
> >  }
> >
> >  if (cert != NULL && key != NULL) {
> > -#if GNUTLS_VERSION_NUMBER >= 0x030111
> > +#if defined(GNUTLS_VERSION_NUMBER) &&
> GNUTLS_VERSION_NUMBER >= 0x030111
> >  char *password = NULL;
> >  if (creds->passwordid) {
> >  password =
> qcrypto_secret_lookup_as_utf8(creds->passwordid,
> 
> Other places in this file still use LIBGNUTLS_VERSION_NUMBER, which is
> good, because gnutls 3.x still defines LIBGNUTLS_VERSION_NUMBER for
> back compat.
> 
You mean using LIBGNUTLS_VERSION_NUMBER directly here? That's ok.

> The tests/test-crypto-tlscredsx509.c file also needs a similar fix.
> 
Sorry?


Regards,
-Gonglei


> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] question with usb stick host pass-through do ejection in guest

[Gonglei (Arei)]

Hi Gerd,

Thank you very much for your reply, it's very useful!

Regards,
-Gonglei


> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Monday, September 05, 2016 4:58 PM
> To: wangxin (U)
> Cc: qemu-devel@nongnu.org; fuweiwei (C); Gonglei (Arei)
> Subject: Re: question with usb stick host pass-through do ejection in guest
> 
>   Hi,
> 
> > It appears that "eject" the stick in the guest may also actually eject it on
> > the host,
> 
> Yes, that is the case.
> 
> > which however, is not rational.
> 
> Why?  I see the same behavior on physical machines.  If I want to use a
> usb stick after ejecting it I have to unplug and re-plug it.
> 
> > Could you tell me the root cause
> > of the problem and some proposals to evade the scenario？ Thanks.
> 
> Well, the guest owns the device.  When the guest sends a eject command
> it will be forwarded to the device like any other request issued by the
> guest ...
> 
> cheers,
>   Gerd

Re: [Qemu-devel] [PATCH v8 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

>
> 
> On 09/03/2016 05:18 AM, Gonglei (Arei) wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Alexander Graf [mailto:ag...@suse.de]
> >> Sent: Friday, September 02, 2016 10:05 PM
> >> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device
> specification
> >>
> >>
> >>
> >> On 02.09.16 14:16, Ola Liljedahl wrote:
> >>>
> >>> On 02/09/2016, 12:26, "Gonglei (Arei)" 
> wrote:
> >>>
> >>>>> -Original Message-
> >>>>> From: Alexander Graf [mailto:ag...@suse.de]
> >>>>> Sent: Friday, September 02, 2016 4:07 PM
> >>>>> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device
> >>>>> specification
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 02.09.16 05:08, Gonglei (Arei) wrote:
> >>>>>> Hi Alex,
> >>>>>>
> >>>>>>
> >>>>>>> -Original Message-
> >>>>>>> From: Alexander Graf [mailto:ag...@suse.de]
> >>>>>>> Sent: Thursday, September 01, 2016 9:37 PM
> >>>>>>> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device
> >>>>> specification
> >>>>>>> On 08/30/2016 02:12 PM, 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.
> >>>>>>> I have mostly a few high level comments.
> >>>>>>>
> >>>>>>> For starters, a lot of the structs rely on the compiler to pad them
> >>>>> to
> >>>>>>> natural alignment. That may get us into trouble when trying to
> >>>>> emulate a
> >>>>>>> virtio device on a host with different guest architecture (like arm
> >>>>> on
> >>>>>>> x86). It'd be a good idea to manually pad everything to be 64bit
> >>>>> aligned
> >>>>>>> - then all fields are always at the same spot.
> >>>>>>>
> >>>>>> Good point! I'll do this in the next version. Thanks!
> >>>>>>
> >>>>>>> I also have a hard time getting my head around the final flow of
> >>>>>>> everything. Do I always have to create a session to be able to emit a
> >>>>>>> command? In that case, doesn't that slow down everything, since a
> >>>>>>> request would then need to wait for the host reply to receive its
> >>>>>>> session id? There should be some way to fire off a simple non-iv
> >>>>>>> operation without any session set up imho.
> >>>>>>>
> >>>>>> For symmetric algorithms, we'd better create a session before
> >>>>> executing
> >>>>> encryption
> >>>>>> Or decryption, because the session usually be kept for a specific
> >>>>>> algorithm with specific key in the production environment. And if we
> >>>>> only
> >>>>> change the iv,
> >>>>>> we don't need to re-create the session.
> >>>>> I think we have a slight misunderstanding here :)
> >>>>>
> >>>>> The current workflow is
> >>>>>
> >>>>>-> create session
> >>>>><- session key
> >>>>>-> data in
> >>>>><- data out
> >>>>>...
> >>>>><- close session
> >>>>>-> ack
> >>>>>
> >>>>> That means that at least for the first packet you have at least one full
> >>>>> round-trip cost from guest to host to guest to be able to send any data.
> >>>>>
> >>>> Yes, that's true...
> >>>>
> >>>>> That sounds pretty expensive to me on the latency side. There are
> >>>>> multiple ways to mitigate that. One idea was to have a separate path in
> >>>&

Re: [Qemu-devel] Can we increase vring size over 1024?

[Gonglei (Arei)]

> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Saturday, September 03, 2016 1:33 AM
> To: Gonglei (Arei)
> Cc: stefa...@redhat.com; jasow...@redhat.com; k...@vger.kernel.org;
> virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org; Lilijun (Jerry);
> Huangpeng (Peter)
> Subject: Re: Can we increase vring size over 1024?
> 
> On Fri, Sep 02, 2016 at 06:55:35AM +, Gonglei (Arei) wrote:
> > Hi Michael & all,
> >
> > Michael, you made a presentation about the virto 1.1's new features in KVM
> Forum last week.
> > That's wonderful!
> >
> > And I'd like to know can we increase vring size over 1024, such as 4096 or
> 8192?
> >
> > My colleage had asked the same question in 2014, but she didn't get a
> definite answare,
> > So, I want to rewake up the dissusstion about this. Becase for the
> virtio-crypto device,
> > I also need to increase the vring size to get better performance and
> thoughput, but the Qemu
> > side limit the thought as VIRTQUEUE_MAX_SIZE is 1024.
> >
> >  [QA-virtio]:Why vring size is limited to 1024?
> >
> http://qemu.11.n7.nabble.com/QA-virtio-Why-vring-size-is-limited-to-1024-td2
> 92450.html
> >
> > Avi Kivity said that google cloud exposed the vring size to 16k.
> >
> > Regards,
> > -Gonglei
> 
> Fundamentally, the reason is that the ring size
> currently also sets the max s/g list length, and linux
> hosts can't support bigger lists.
> 
But I don't think this is a problem.
Vring is just a container, we can say the max request's length is 1024, but the 
capacity of container
shouldn't be the length of max request. For example, we can put 4K requests 
with one s/g list
into vring at one time if the vring size is 4096, and 4 requests with 1024 s/g 
list into vring at one time.
Ignoring the indirect table support. Am I right?

> We should fix that in 1.1.
> 
Sounds good!

> --
> MST

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v8 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi Stefan,


> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Friday, September 02, 2016 8:07 PM
> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> On Tue, Aug 30, 2016 at 08:12:15PM +0800, Gonglei wrote:
> 
> Hi,
> I have read through part of the spec and suggest mostly grammar fixes
> below.
> 
Thank you very much! Forgive me for my poor English please :)
I'll fix them in the following version.

> > 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.
> >
> > Signed-off-by: Gonglei 
> > 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 
> > CC: Mihai Claudiu Caraman 
> > ---
> >  content.tex   |   2 +
> >  virtio-crypto.tex | 835
> ++
> >  2 files changed, 837 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..491fc25
> > --- /dev/null
> > +++ b/virtio-crypto.tex
> > @@ -0,0 +1,835 @@
> > +\section{Crypto Device}\label{sec:Device Types / Crypto Device}
> > +
> > +The virtio crypto device is a virtual crypto device, and is a kind of
> > +virtual hardware accelerators for virtual machine.  The encryption and
> 
> s/accelerators/accelerator/
> s/virtual machine/virtual machines/
> 
> > +decryption requests of are placed in the data queue, and handled by the
> 
> s/of//
> 
> > +real crypto accelerators finally. The second queue is the control queue,
> > +which is used to create or destroy session for symmetric algorithms, and
> 
> s/session/sessions/
> 
> > +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]
> > +\item[N-1] dataqN
> > +\item[N] controlq
> > +\end{description}
> > +
> > +N is set by \field{max_dataqueues} (\field{max_dataqueues} >= 1).
> 
> I suggest dropping (\field{max_dataqueues} >= 1) since this constraint
> already is expressed in the device normative section below.  Things
> can go out of sync if they are duplicated.
> 
> > +
> > +\subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature
> bits}
> > +  None currently defined
> > +
> > +\subsection{Device configuration layout}\label{sec:Device Types / Crypto
> Device / Device configuration layout}
> > +
> > +Thirteen driver-read-only configuration fields are currently defined.
> 
> I count only 12 fields.  I suggest saying "The following
> driver-read-only configuration fields are currently defined:" instead.
> 
> > +\begin{lstlisting}
> > +struct virtio_crypto_config {
> > +le16  status;
> > +le16  max_dataqueues;
> > +le32  crypto_services;
> > +/* detailed algorithms mask */
> > +le32 cipher_algo_l;
> > +le32 cipher_algo_h;
> > +le32 hash_algo;
> > +le32 mac_algo_l;
> > +le32 mac_algo_h;
> > +le32 asym_algo;
> > +le32 kdf_algo;
> > +le32 aead_algo;
> > +le32 primitive_algo;
> > +};
> > +\end{lstlisting}
> > +
> > +The first field, \field{status} is currently defined:
> VIRTIO_CRYPTO_S_HW_READY.
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_S_HW_READY  (1 << 0)
> > +\end{lstlisting}
> > +
> > +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
> 
> s/service/services/
> 
> > +defined are:
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_NO_SERVICE (0) /* cipher services */
> > +#define VIRTIO_CRYPTO_SERVICE_CIPHER (1) /* cipher services */
> 
> How are these constants used: 1 << VIRTIO_CRYPTO_NO_SERVICE?
> 
> I suggest eliminating the 0 bit constants

Re: [Qemu-devel] [PATCH v8 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi,

> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Friday, September 02, 2016 10:05 PM
> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> 
> 
> On 02.09.16 14:16, Ola Liljedahl wrote:
> >
> >
> > On 02/09/2016, 12:26, "Gonglei (Arei)"  wrote:
> >
> >>
> >>> -Original Message-
> >>> From: Alexander Graf [mailto:ag...@suse.de]
> >>> Sent: Friday, September 02, 2016 4:07 PM
> >>> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device
> >>> specification
> >>>
> >>>
> >>>
> >>> On 02.09.16 05:08, Gonglei (Arei) wrote:
> >>>> Hi Alex,
> >>>>
> >>>>
> >>>>> -Original Message-
> >>>>> From: Alexander Graf [mailto:ag...@suse.de]
> >>>>> Sent: Thursday, September 01, 2016 9:37 PM
> >>>>> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device
> >>> specification
> >>>>>
> >>>>> On 08/30/2016 02:12 PM, 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.
> >>>>>
> >>>>> I have mostly a few high level comments.
> >>>>>
> >>>>> For starters, a lot of the structs rely on the compiler to pad them
> >>> to
> >>>>> natural alignment. That may get us into trouble when trying to
> >>> emulate a
> >>>>> virtio device on a host with different guest architecture (like arm
> >>> on
> >>>>> x86). It'd be a good idea to manually pad everything to be 64bit
> >>> aligned
> >>>>> - then all fields are always at the same spot.
> >>>>>
> >>>> Good point! I'll do this in the next version. Thanks!
> >>>>
> >>>>> I also have a hard time getting my head around the final flow of
> >>>>> everything. Do I always have to create a session to be able to emit a
> >>>>> command? In that case, doesn't that slow down everything, since a
> >>>>> request would then need to wait for the host reply to receive its
> >>>>> session id? There should be some way to fire off a simple non-iv
> >>>>> operation without any session set up imho.
> >>>>>
> >>>> For symmetric algorithms, we'd better create a session before
> >>> executing
> >>> encryption
> >>>> Or decryption, because the session usually be kept for a specific
> >>>> algorithm with specific key in the production environment. And if we
> >>> only
> >>> change the iv,
> >>>> we don't need to re-create the session.
> >>>
> >>> I think we have a slight misunderstanding here :)
> >>>
> >>> The current workflow is
> >>>
> >>>   -> create session
> >>>   <- session key
> >>>   -> data in
> >>>   <- data out
> >>>   ...
> >>>   <- close session
> >>>   -> ack
> >>>
> >>> That means that at least for the first packet you have at least one full
> >>> round-trip cost from guest to host to guest to be able to send any data.
> >>>
> >> Yes, that's true...
> >>
> >>> That sounds pretty expensive to me on the latency side. There are
> >>> multiple ways to mitigate that. One idea was to have a separate path in
> >>> parallel to the create session + data + close session dance that would
> >>> combine them all into a single command. You would still have the session
> >>> based version, but accelerate the one-blob case.
> >>>
> >>> Another idea would be to make the guest be the session id janitor. Then
> >>> you could just do
> >>>
> >>>   -> create session with key X
> >>>   -> data in
> >>>   <- data out
> >>>   ...
> >>>
> >>> so you save the round trip, if you combine command a

Re: [Qemu-devel] [PATCH v8 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi,

> -Original Message-
> From: Ma, Liang J [mailto:liang.j...@intel.com]
> Sent: Friday, September 02, 2016 9:47 PM
> Subject: RE: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> Hi  Lei,
>  For wireless algorithm
>  +#define VIRTIO_CRYPTO_MAC_CMAC_KASUMI_F9
> 27
>  +#define VIRTIO_CRYPTO_MAC_CMAC_SNOW3G_UIA228
>   I suggest rename as
>  +#define VIRTIO_CRYPTO_MAC_KASUMI_F9  27
>  +#define VIRTIO_CRYPTO_MAC_SNOW3G_UIA228
>  Kasumi/snow3g  auth mode is not belongs to CMAC family (which is
> used for auth based on general block cipher.e.g AES).

OK, thanks.

> Regards
> Liang
> 

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v8 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi Alex,

> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Friday, September 02, 2016 9:53 PM
> Euler)
> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> 
> 
> On 02.09.16 12:26, Gonglei (Arei) wrote:
> >
> >> -Original Message-
> >> From: Alexander Graf [mailto:ag...@suse.de]
> >> Sent: Friday, September 02, 2016 4:07 PM
> >> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device
> specification
> >>
> >>
> >>
> >> On 02.09.16 05:08, Gonglei (Arei) wrote:
> >>> Hi Alex,
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Alexander Graf [mailto:ag...@suse.de]
> >>>> Sent: Thursday, September 01, 2016 9:37 PM
> >>>> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device
> >> specification
> >>>>
> >>>> On 08/30/2016 02:12 PM, 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.
> >>>>
> >>>> I have mostly a few high level comments.
> >>>>
> >>>> For starters, a lot of the structs rely on the compiler to pad them to
> >>>> natural alignment. That may get us into trouble when trying to emulate a
> >>>> virtio device on a host with different guest architecture (like arm on
> >>>> x86). It'd be a good idea to manually pad everything to be 64bit aligned
> >>>> - then all fields are always at the same spot.
> >>>>
> >>> Good point! I'll do this in the next version. Thanks!
> >>>
> >>>> I also have a hard time getting my head around the final flow of
> >>>> everything. Do I always have to create a session to be able to emit a
> >>>> command? In that case, doesn't that slow down everything, since a
> >>>> request would then need to wait for the host reply to receive its
> >>>> session id? There should be some way to fire off a simple non-iv
> >>>> operation without any session set up imho.
> >>>>
> >>> For symmetric algorithms, we'd better create a session before executing
> >> encryption
> >>> Or decryption, because the session usually be kept for a specific
> >>> algorithm with specific key in the production environment. And if we only
> >> change the iv,
> >>> we don't need to re-create the session.
> >>
> >> I think we have a slight misunderstanding here :)
> >>
> >> The current workflow is
> >>
> >>   -> create session
> >>   <- session key
> >>   -> data in
> >>   <- data out
> >>   ...
> >>   <- close session
> >>   -> ack
> >>
> >> That means that at least for the first packet you have at least one full
> >> round-trip cost from guest to host to guest to be able to send any data.
> >>
> > Yes, that's true...
> >
> >> That sounds pretty expensive to me on the latency side. There are
> >> multiple ways to mitigate that. One idea was to have a separate path in
> >> parallel to the create session + data + close session dance that would
> >> combine them all into a single command. You would still have the session
> >> based version, but accelerate the one-blob case.
> >>
> >> Another idea would be to make the guest be the session id janitor. Then
> >> you could just do
> >>
> >>   -> create session with key X
> >>   -> data in
> >>   <- data out
> >>   ...
> >>
> >> so you save the round trip, if you combine command and data queues, as
> >> then the create and data bits are serialized by their position in the 
> >> queue.
> >>
> > ... But for lots of crypto requests, the exhaust is low:
> >
> > -> create session with key X
> > <- session id
> > //do something in the guest if you like
> > -> data in with session_id
> > -> data in with session_id
> > -> data in with session_id
> > ... ...(fill out data virtqueue)
> 

Re: [Qemu-devel] [PATCH for-2.7] vnc: fix qemu crash because of SIGSEGV

[Gonglei (Arei)]

okay, thank you, guys.
发件人：Peter Maydell
收件人：Marc-André Lureau,
抄送：龚磊,qemu-devel,黄伟栋,Gerd Hoffmann,
时间：2016-09-02 20:39:52
主题:Re: [Qemu-devel] [PATCH for-2.7] vnc: fix qemu crash because of SIGSEGV

On 2 September 2016 at 13:34, Marc-André Lureau
 wrote:
> Hi
>
> On Fri, Sep 2, 2016 at 3:04 PM Gonglei  wrote:
>
>>
>> > It looks like this is not a regression from 2.7, perhaps it should be
>> post-poned?
>> >
>> Yes, it's not a regression from 2.7, but it indeed is a serious bug and
>> the fix is harmless. :)
>>
>>
> The timing is bad. Unless Gerd or a maintainer sends a pull request today
> with it, it's probably not going to make it in 2.7 (due today according to
> planning).

For a non-regression this would have had to be sent at least a
week ago to have had a chance of getting into 2.7. I would only accep
anything into 2.7 now if it was an absolute release-breaker
(eg "crashes on startup for 50% of users"); this is a long way from
that. 2.8 and cc qemu-stable, please.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v8 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Friday, September 02, 2016 4:07 PM
> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> 
> 
> On 02.09.16 05:08, Gonglei (Arei) wrote:
> > Hi Alex,
> >
> >
> >> -Original Message-
> >> From: Alexander Graf [mailto:ag...@suse.de]
> >> Sent: Thursday, September 01, 2016 9:37 PM
> >> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device
> specification
> >>
> >> On 08/30/2016 02:12 PM, 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.
> >>
> >> I have mostly a few high level comments.
> >>
> >> For starters, a lot of the structs rely on the compiler to pad them to
> >> natural alignment. That may get us into trouble when trying to emulate a
> >> virtio device on a host with different guest architecture (like arm on
> >> x86). It'd be a good idea to manually pad everything to be 64bit aligned
> >> - then all fields are always at the same spot.
> >>
> > Good point! I'll do this in the next version. Thanks!
> >
> >> I also have a hard time getting my head around the final flow of
> >> everything. Do I always have to create a session to be able to emit a
> >> command? In that case, doesn't that slow down everything, since a
> >> request would then need to wait for the host reply to receive its
> >> session id? There should be some way to fire off a simple non-iv
> >> operation without any session set up imho.
> >>
> > For symmetric algorithms, we'd better create a session before executing
> encryption
> > Or decryption, because the session usually be kept for a specific
> > algorithm with specific key in the production environment. And if we only
> change the iv,
> > we don't need to re-create the session.
> 
> I think we have a slight misunderstanding here :)
> 
> The current workflow is
> 
>   -> create session
>   <- session key
>   -> data in
>   <- data out
>   ...
>   <- close session
>   -> ack
> 
> That means that at least for the first packet you have at least one full
> round-trip cost from guest to host to guest to be able to send any data.
> 
Yes, that's true... 

> That sounds pretty expensive to me on the latency side. There are
> multiple ways to mitigate that. One idea was to have a separate path in
> parallel to the create session + data + close session dance that would
> combine them all into a single command. You would still have the session
> based version, but accelerate the one-blob case.
> 
> Another idea would be to make the guest be the session id janitor. Then
> you could just do
> 
>   -> create session with key X
>   -> data in
>   <- data out
>   ...
> 
> so you save the round trip, if you combine command and data queues, as
> then the create and data bits are serialized by their position in the queue.
> 
... But for lots of crypto requests, the exhaust is low:

-> create session with key X
<- session id
//do something in the guest if you like
-> data in with session_id
-> data in with session_id
-> data in with session_id
... ...(fill out data virtqueue)
<-data out
<-data out
<-data out

And this is what the production environment do currently.

> >
> > For the asymmetric algorithms, we don't need create a session IIRC.
> >
> > So, I don't think this is a performance degradation, but a performance
> enhancement.
> >
> >> Also, I don't fully understand the split between control and data
> >> queues. As far as I read things, the control queue is used to create
> >> session ids and the data queues can then be used to push data. Is there
> >> any particular reason for the split? One thing that seems natural to me
> >> would be to have sessions be per-queue, so you would create a session on
> >> a particular queue and only have it ever be available there. That way
> >> you get rid of any locking for sessions.
> >>
> > We want to keep a unify request type (structure) for data queue, so we can
> > keep the session operation in the control queue. Of course the control queue
>

[Qemu-devel] Can we increase vring size over 1024?

[Gonglei (Arei)]

Hi Michael & all,

Michael, you made a presentation about the virto 1.1's new features in KVM 
Forum last week.
That's wonderful!

And I'd like to know can we increase vring size over 1024, such as 4096 or 8192?

My colleage had asked the same question in 2014, but she didn't get a definite 
answare,
So, I want to rewake up the dissusstion about this. Becase for the 
virtio-crypto device,
I also need to increase the vring size to get better performance and thoughput, 
but the Qemu
side limit the thought as VIRTQUEUE_MAX_SIZE is 1024.

 [QA-virtio]:Why vring size is limited to 1024?
http://qemu.11.n7.nabble.com/QA-virtio-Why-vring-size-is-limited-to-1024-td292450.html

Avi Kivity said that google cloud exposed the vring size to 16k.

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v8 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi Alex,


> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, September 01, 2016 9:37 PM
> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> On 08/30/2016 02:12 PM, 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.
> 
> I have mostly a few high level comments.
> 
> For starters, a lot of the structs rely on the compiler to pad them to
> natural alignment. That may get us into trouble when trying to emulate a
> virtio device on a host with different guest architecture (like arm on
> x86). It'd be a good idea to manually pad everything to be 64bit aligned
> - then all fields are always at the same spot.
> 
Good point! I'll do this in the next version. Thanks!

> I also have a hard time getting my head around the final flow of
> everything. Do I always have to create a session to be able to emit a
> command? In that case, doesn't that slow down everything, since a
> request would then need to wait for the host reply to receive its
> session id? There should be some way to fire off a simple non-iv
> operation without any session set up imho.
> 
For symmetric algorithms, we'd better create a session before executing 
encryption
Or decryption, because the session usually be kept for a specific
algorithm with specific key in the production environment. And if we only 
change the iv, 
we don't need to re-create the session. 

For the asymmetric algorithms, we don't need create a session IIRC.

So, I don't think this is a performance degradation, but a performance 
enhancement.

> Also, I don't fully understand the split between control and data
> queues. As far as I read things, the control queue is used to create
> session ids and the data queues can then be used to push data. Is there
> any particular reason for the split? One thing that seems natural to me
> would be to have sessions be per-queue, so you would create a session on
> a particular queue and only have it ever be available there. That way
> you get rid of any locking for sessions.
> 
We want to keep a unify request type (structure) for data queue, so we can
keep the session operation in the control queue. Of course the control queue
only used to create sessions currently, but we can extend its functions if 
needed
in the future.

> 
> Alex

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v3] target-i386: present virtual L3 cache info for vcpus

[Gonglei (Arei)]

> -Original Message-
> From: longpeng
> Sent: Friday, September 02, 2016 10:23 AM
> To: ehabk...@redhat.com; r...@twiddle.net; pbonz...@redhat.com;
> m...@redhat.com
> Cc: Zhaoshenglong; Gonglei (Arei); Huangpeng (Peter); Herongguang (Stephen);
> qemu-devel@nongnu.org; Longpeng(Mike)
> Subject: [PATCH v3] target-i386: present virtual L3 cache info for vcpus
> 
> From: "Longpeng(Mike)" 
> 

A typo in email address, pls resend the v3.

> Some software algorithms are based on the hardware's cache info, for
> example,
> for x86 linux kernel, when cpu1 want to wakeup a task on cpu2, cpu1 will
> trigger
> a resched IPI and told cpu2 to do the wakeup if they don't share low level
> cache. Oppositely, cpu1 will access cpu2's runqueue directly if they share 
> llc.
> The relevant linux-kernel code as bellow:
> 
>   static void ttwu_queue(struct task_struct *p, int cpu)
>   {
>   struct rq *rq = cpu_rq(cpu);
>   ..
>   if (... && !cpus_share_cache(smp_processor_id(), cpu)) {
>   ..
>   ttwu_queue_remote(p, cpu); /* will trigger RES IPI */
>   return;
>   }
>   ..
>   ttwu_do_activate(rq, p, 0); /* access target's rq directly */
>   ..
>   }
> 
> In real hardware, the cpus on the same socket share L3 cache, so one won't
> trigger a resched IPIs when wakeup a task on others. But QEMU doesn't
> present a
> virtual L3 cache info for VM, then the linux guest will trigger lots of RES 
> IPIs
> under some workloads even if the virtual cpus belongs to the same virtual
> socket.
> 
> For KVM, this degrades performance, because there will be lots of vmexit due
> to
> guest send IPIs.
> 
> The workload is a SAP HANA's testsuite, we run it one round(about 40
> minuates)
> and observe the (Suse11sp3)Guest's amounts of RES IPIs which triggering
> during
> the period:
> 
> No-L3   With-L3(applied this patch)
> cpu0: 363890  44582
> cpu1: 373405  43109
> cpu2: 340783  43797
> cpu3: 333854  43409
> cpu4: 327170  40038
> cpu5: 325491  39922
> cpu6: 319129  42391
> cpu7: 306480  41035
> cpu8: 161139  32188
> cpu9: 164649  31024
> cpu10:149823  30398
> cpu11:149823  32455
> cpu12:164830  35143
> cpu13:172269  35805
> cpu14:179979  33898
> cpu15:194505  32754
> avg:  268963.640129.8
> 
> The VM's topology is "1*socket 8*cores 2*threads".
> After present virtual L3 cache info for VM, the amounts of RES IPIs in guest
> reduce 85%.
> 
> What's more, for KVM, vcpus send IPIs will cause vmexit which is expensive.
> We had tested the overall system performance if vcpus actually run on sparate
> physical socket. With L3 cache, the performance improves
> 7.2%~33.1%(avg:15.7%).
> 
> Signed-off-by: Longpeng(Mike) 
>
Here as well.

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH 0/2] fix buliding complaint

[Gonglei (Arei)]

Oops, please see the v2.


Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Tuesday, August 30, 2016 12:06 PM
> To: qemu-devel@nongnu.org
> Cc: berra...@redhat.com; dmi...@daynix.com; Gonglei (Arei)
> Subject: [PATCH 0/2] fix buliding complaint
> 
> 
> Gonglei (2):
>   crypto: fix building complaint
>   e1000: fix buliding complaint
> 
>  crypto/tlscredsx509.c | 2 +-
>  hw/net/e1000e_core.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> --
> 1.7.12.4
> 

Re: [Qemu-devel] [PATCH v6 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi guys,

Thanks for your good comments, we should come to an agreement on droping 
version filed
In virtio crypto specific. And I'll update a new version soon.

Regards,
-Gonglei


> -Original Message-
> From: Zeng, Xin [mailto:xin.z...@intel.com]
> Sent: Tuesday, August 09, 2016 9:42 PM
> To: Michael S. Tsirkin
> Cc: Gonglei (Arei); qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org;
> Huangpeng (Peter); Luonengjun; cornelia.h...@de.ibm.com;
> stefa...@redhat.com; denglin...@chinamobile.com; Jani Kokkonen;
> ola.liljed...@arm.com; varun.se...@freescale.com; Keating, Brian A; Ma,
> Liang J; Griffin, John; Hanweidong (Randy); Huangweidong (C)
> Subject: RE: [PATCH v6 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> On Tuesday, August 9, 2016 6:58 PM Michael S. Tsirkin Wrote:
> > -Original Message-
> > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > Sent: Tuesday, August 9, 2016 6:58 PM
> > To: Zeng, Xin 
> > Cc: Gonglei (Arei) ; qemu-devel@nongnu.org;
> > virtio-...@lists.oasis-open.org; Huangpeng (Peter)
> > ; Luonengjun ;
> > cornelia.h...@de.ibm.com; stefa...@redhat.com;
> > denglin...@chinamobile.com; Jani Kokkonen ;
> > ola.liljed...@arm.com; varun.se...@freescale.com; Keating, Brian A
> > ; Ma, Liang J ; Griffin,
> > John ; Hanweidong (Randy)
> > ; Huangweidong (C)
> > 
> > Subject: Re: [PATCH v6 1/2] virtio-crypto: Add virtio crypto device
> > specification
> >
> > On Mon, Aug 08, 2016 at 06:27:15AM +, Zeng, Xin wrote:
> > > On Thu, Friday, August 05, 2016 3:56 AM, Michael S. Tsirkin wrote:
> > > > -Original Message-
> > > > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > > > Sent: Friday, August 05, 2016 3:56 AM
> > > > To: Gonglei (Arei)
> > > > Cc: Zeng, Xin; qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org;
> > > > Huangpeng (Peter); Luonengjun; cornelia.h...@de.ibm.com;
> > > > stefa...@redhat.com; denglin...@chinamobile.com; Jani Kokkonen;
> > > > ola.liljed...@arm.com; varun.se...@freescale.com; Keating, Brian A;
> > Ma,
> > > > Liang J; Griffin, John; Hanweidong (Randy); Huangweidong (C)
> > > > Subject: Re: [PATCH v6 1/2] virtio-crypto: Add virtio crypto device
> > > > specification
> > > >
> > > > On Thu, Aug 04, 2016 at 11:24:26AM +, Gonglei (Arei) 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 defined for the version field:
> > > > > > > +
> > > > > > > +\begin{lstlisting}
> > > > > > > +#define VIRTIO_CRYPTO_VERSION_1  (1)
> > > > > >
> > > > > > Suggest to remove this macro,
> > > > > > Do you think a version which is composed of major version and minor
> > > > > > version is better?
> > > > > >
> > > > >
> > > > > I think we should tell the developer how to set the value of version
> > > > > field, but I have no idea about which value or form is better, so I
> > > > > used 1 as the first version. What's your opinion?
> > > >
> > > > My opinion is that you should drop this completely. We do feature bits,
> > not
> > > > version numbers in virtio. We do not want each device doing its own
> > thing for
> > > > compatibility.
> > > >
> > >
> > > But as I mentioned before,  considering the bug fix case, if each backend
> > device
> > > release need a feature bit meaning "some bugs are fixed", are the feature
> > bits
> > > enough?
> >
> > It depends on whether the bug is very entrenched and important. In most
> > cases, for minor bugs, it's better to just fix the bug in the driver or
> > the hypervisor and be done with it.  For cases where
> > that's not feasible because many drivers relied on a specific bug,
> > and the bug is very important, we can always add more
> > if we run out of feature bits.
> >
> > > Physical devices usually have a revision ID to mark its version,
> >
> > Because compatibility is one way (new devices usually need
> > new drivers).
> >
> 
> Yes, that's also why I propose to put version(revision) field into device
> configuration read-only filed instead of feature bits field.
> 
> > > could we have a
> > > revision Id field for each virtio device to distinguish the the virtio 
> > > devices
> > which
> > > have the same feature sets but have different version?
> >
> > ccw has version negotiation. It was only changed once at the 0.9->1.0
> > transition so far, it's not used for bug fixes.  We could discuss adding
> > this to pci and mmio as well, but if yes this should be discussed
> > separately.
> >
> 
> Ok, that's good, I do think this is needed. I can initiate this discussion in
> another separated mail loop.
> 
> > So far no argument made here was crypto specific, so
> > let's not put this in the crypto device.
> >
> 
> Sure,  It is indeed not crypto device specific,  but probably all virtio
> devices needs. We can drop it from crypto device spec.
> Thanks!
> 
> >
> > > > --
> > > > MST

Re: [Qemu-devel] [Question] virtio-serial misses irq delivery on migration?

[Gonglei (Arei)]

That's because the virtual vm clock is enabled at initialization. It doesn't 
need to wait for invoking vm_start() to fire.
发件人：Dr. David Alan Gilbert
收件人：龚磊,
抄送：Paolo Bonzini,Jan Kiszka,Amit Shah,Juan 
Quintela,黄伟栋,qemu-devel@nongnu.org,k...@vger.kernel.org,
时间：2016-08-08 22:18:15
主题:Re: [Qemu-devel] [Question] virtio-serial misses irq delivery on migration?

* Gonglei (Arei) (arei.gong...@huawei.com) wrote:
> Hi Dave,
>
>
> > -Original Message-
> > From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> > Sent: Monday, August 08, 2016 8:13 PM
> > To: Gonglei (Arei)
> > Cc: Paolo Bonzini; jan.kis...@siemens.com; amit.s...@redhat.com;
> > quint...@redhat.com; Huangweidong (C); qemu-devel@nongnu.org;
> > k...@vger.kernel.org
> > Subject: Re: [Qemu-devel] [Question] virtio-serial misses irq delivery on
> > migration?
> >
> > * Gonglei (Arei) (arei.gong...@huawei.com) wrote:
> > > Hi all,
> > >
> > > I might catch the bug. Now, we rely on a vm_clock timer to assure that the
> > vcpus are started
> > > before we invoke send_control_event(),which queue a message in the virtio
> > ring and trigger a irq.
> > >
> > > In actually, we can't attach our initial intention under a special 
> > > situation:
> > >
> > > 1. the process of migration destination is in a coroutine
> > >  Commit 82a4da79fd6
> > > 2. The corountine will yiled the cpu (calling 
> > > yield_until_fd_readable(s->fd))
> > >  if the Qemu encounter a EAGIN while reading QEMUFile.
> > >  commit 595ab64169b
> > >
> > > static ssize_t socket_get_buffer(void *opaque, uint8_t *buf, int64_t pos,
> > >  size_t size)
> > > {
> > > QEMUFileSocket *s = opaque;
> > > ssize_t len;
> > >
> > > for (;;) {
> > > len = qemu_recv(s->fd, buf, size, 0);
> > > if (len != -1) {
> > > break;
> > > }
> > > if (socket_error() == EAGAIN) {
> > > yield_until_fd_readable(s->fd);
> > > } else if (socket_error() != EINTR) {
> > > break;
> > > }
> > > }
> > >
> > > if (len == -1) {
> > > len = -socket_error();
> > > }
> > > return len;
> > > }
> > >
> > > 3. The main thread can get the cpu and timer will run, asumes that we get
> > EAGIN
> > >   after invoking fetch_active_ports_list().
> >
> > I don't understand the details of this interrupt injection, or why the timer
> > will run if we're still not finished migration; it doesn't sound right that 
> > a
> > QEMU_CLOCK_VIRTUAL
> > timer should trigger while we're still receiving the VM and the guest is 
> > paused.
> >
>
> Because the migration coroutine will yiled cpu if it get a EAGAIN error from 
> unix socket.
> You can see the above step 2)
>
> For the upstream qemu, you can see the hander of QIO_CHANNEL_ERR_BLOCK in 
> channel_get_buffer()
>
> static ssize_t channel_get_buffer(void *opaque,
>   uint8_t *buf,
>   int64_t pos,
>   size_t size)
> {
> QIOChannel *ioc = QIO_CHANNEL(opaque);
> ssize_t ret;
>
> do {
> ret = qio_channel_read(ioc, (char *)buf, size, NULL);
> if (ret < 0) {
> if (ret == QIO_CHANNEL_ERR_BLOCK) {
> qio_channel_yield(ioc, G_IO_IN);   // yiled cpu
> } else {
> /* XXX handle Error * object */
> return -EIO;
> }
> }
> } while (ret == QIO_CHANNEL_ERR_BLOCK);
>
> return ret;
> }

Yes, I understand it yields; but I would have expected the timer code
not to fire virtual timers while the VM is in paused state.

> > However, would it be fixed by using a vm_change_state_handler like
> > ui/spice-core.c does?
> >
>
> I'll check this method, thanks!
>

Dave

> Regards,
> -Gonglei
>
> > Dave
> >
> >
> > > 4. reproduce the problem by fault injection.
> > >
> > > The debug logs:
> > >
> > > [2016-08-06 16:52:56] handle_qmp_command:5106 qmp_cmd_name:
> > query-migrate-capabilities
> > > [2016-08-06 16:52:56] handle_qmp_command:5116 qmp_cmd_name:
> > migrate-set-capabilities, qmp_cmd_arguments: {"capabilities": [{"state": 
> > false

Re: [Qemu-devel] [Question] virtio-serial misses irq delivery on migration?

[Gonglei (Arei)]

Hi Dave,


> -Original Message-
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Monday, August 08, 2016 8:13 PM
> To: Gonglei (Arei)
> Cc: Paolo Bonzini; jan.kis...@siemens.com; amit.s...@redhat.com;
> quint...@redhat.com; Huangweidong (C); qemu-devel@nongnu.org;
> k...@vger.kernel.org
> Subject: Re: [Qemu-devel] [Question] virtio-serial misses irq delivery on
> migration?
> 
> * Gonglei (Arei) (arei.gong...@huawei.com) wrote:
> > Hi all,
> >
> > I might catch the bug. Now, we rely on a vm_clock timer to assure that the
> vcpus are started
> > before we invoke send_control_event(),which queue a message in the virtio
> ring and trigger a irq.
> >
> > In actually, we can't attach our initial intention under a special 
> > situation:
> >
> > 1. the process of migration destination is in a coroutine
> >  Commit 82a4da79fd6
> > 2. The corountine will yiled the cpu (calling 
> > yield_until_fd_readable(s->fd))
> >  if the Qemu encounter a EAGIN while reading QEMUFile.
> >  commit 595ab64169b
> >
> > static ssize_t socket_get_buffer(void *opaque, uint8_t *buf, int64_t pos,
> >  size_t size)
> > {
> > QEMUFileSocket *s = opaque;
> > ssize_t len;
> >
> > for (;;) {
> > len = qemu_recv(s->fd, buf, size, 0);
> > if (len != -1) {
> > break;
> > }
> > if (socket_error() == EAGAIN) {
> > yield_until_fd_readable(s->fd);
> > } else if (socket_error() != EINTR) {
> > break;
> > }
> > }
> >
> > if (len == -1) {
> > len = -socket_error();
> > }
> > return len;
> > }
> >
> > 3. The main thread can get the cpu and timer will run, asumes that we get
> EAGIN
> >   after invoking fetch_active_ports_list().
> 
> I don't understand the details of this interrupt injection, or why the timer
> will run if we're still not finished migration; it doesn't sound right that a
> QEMU_CLOCK_VIRTUAL
> timer should trigger while we're still receiving the VM and the guest is 
> paused.
> 

Because the migration coroutine will yiled cpu if it get a EAGAIN error from 
unix socket.
You can see the above step 2)

For the upstream qemu, you can see the hander of QIO_CHANNEL_ERR_BLOCK in 
channel_get_buffer()

static ssize_t channel_get_buffer(void *opaque,
  uint8_t *buf,
  int64_t pos,
  size_t size)
{
QIOChannel *ioc = QIO_CHANNEL(opaque);
ssize_t ret;

do {
ret = qio_channel_read(ioc, (char *)buf, size, NULL);
if (ret < 0) {
if (ret == QIO_CHANNEL_ERR_BLOCK) {
qio_channel_yield(ioc, G_IO_IN);   // yiled cpu
} else {
/* XXX handle Error * object */
return -EIO;
}
}
} while (ret == QIO_CHANNEL_ERR_BLOCK);

return ret;
}

> However, would it be fixed by using a vm_change_state_handler like
> ui/spice-core.c does?
> 

I'll check this method, thanks!

Regards,
-Gonglei

> Dave
> 
> 
> > 4. reproduce the problem by fault injection.
> >
> > The debug logs:
> >
> > [2016-08-06 16:52:56] handle_qmp_command:5106 qmp_cmd_name:
> query-migrate-capabilities
> > [2016-08-06 16:52:56] handle_qmp_command:5116 qmp_cmd_name:
> migrate-set-capabilities, qmp_cmd_arguments: {"capabilities": [{"state": 
> false,
> "capability": "xbzrle"}]}
> > [2016-08-06 16:52:56] handle_qmp_command:5106 qmp_cmd_name:
> query-migrate-capabilities
> > [2016-08-06 16:52:56] handle_qmp_command:5116 qmp_cmd_name:
> migrate-set-capabilities, qmp_cmd_arguments: {"capabilities": [{"state": 
> false,
> "capability": "rdma-pin-all"}]}
> > [2016-08-06 16:52:56] process_incoming_migration_co:170 gonglei: enter
> process_incoming_migration_co()// Enter corountine
> > [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> > [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> > [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> > [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> > [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> > [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> > [2016-08-06 16:53:01

Re: [Qemu-devel] [Question] virtio-serial misses irq delivery on migration?

[Gonglei (Arei)]

Hello Paolo,

Any ideas? Thanks!


Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Saturday, August 06, 2016 6:20 PM
> To: Gonglei (Arei); 'Paolo Bonzini'; 'jan.kis...@siemens.com';
> 'amit.s...@redhat.com'; 'quint...@redhat.com'
> Cc: 'qemu-devel@nongnu.org'; 'k...@vger.kernel.org'; Huangweidong (C)
> Subject: RE: [Question] virtio-serial misses irq delivery on migration?
> 
> Hi all,
> 
> I might catch the bug. Now, we rely on a vm_clock timer to assure that the
> vcpus are started
> before we invoke send_control_event(),which queue a message in the virtio
> ring and trigger a irq.
> 
> In actually, we can't attach our initial intention under a special situation:
> 
> 1. the process of migration destination is in a coroutine
>  Commit 82a4da79fd6
> 2. The corountine will yiled the cpu (calling yield_until_fd_readable(s->fd))
>  if the Qemu encounter a EAGIN while reading QEMUFile.
>  commit 595ab64169b
> 
> static ssize_t socket_get_buffer(void *opaque, uint8_t *buf, int64_t pos,
>  size_t size)
> {
> QEMUFileSocket *s = opaque;
> ssize_t len;
> 
> for (;;) {
> len = qemu_recv(s->fd, buf, size, 0);
> if (len != -1) {
> break;
> }
> if (socket_error() == EAGAIN) {
> yield_until_fd_readable(s->fd);
> } else if (socket_error() != EINTR) {
> break;
> }
> }
> 
> if (len == -1) {
> len = -socket_error();
> }
> return len;
> }
> 
> 3. The main thread can get the cpu and timer will run, asumes that we get
> EAGIN
>   after invoking fetch_active_ports_list().
> 4. reproduce the problem by fault injection.
> 
> The debug logs:
> 
> [2016-08-06 16:52:56] handle_qmp_command:5106 qmp_cmd_name:
> query-migrate-capabilities
> [2016-08-06 16:52:56] handle_qmp_command:5116 qmp_cmd_name:
> migrate-set-capabilities, qmp_cmd_arguments: {"capabilities": [{"state": 
> false,
> "capability": "xbzrle"}]}
> [2016-08-06 16:52:56] handle_qmp_command:5106 qmp_cmd_name:
> query-migrate-capabilities
> [2016-08-06 16:52:56] handle_qmp_command:5116 qmp_cmd_name:
> migrate-set-capabilities, qmp_cmd_arguments: {"capabilities": [{"state": 
> false,
> "capability": "rdma-pin-all"}]}
> [2016-08-06 16:52:56] process_incoming_migration_co:170 gonglei: enter
> process_incoming_migration_co()// Enter corountine
> [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> [2016-08-06 16:53:01] apic_dispatch_post_load:370 gonglei:
> apic_dispatch_post_load
> [2016-08-06 16:53:01] kvm_ioapic_put:97 gonglei: kvm_ioapic_put
> [2016-08-06 16:53:01] virtio_serial_load:745 gonglei: virtio_serial_load will 
> init
> virtqueue
> [2016-08-06 16:53:01] fetch_active_ports_list:735 gonglei: **
> begin to inject debug **// fault injection begin, migration
> coroutine yiled cpu
> [2016-08-06 16:53:01] timerlist_run_timers:496 gonglei: expire_time: 1,
> current_time: 9750771061592//vm_clock timer boom
> [2016-08-06 16:53:01] virtio_serial_post_load_timer_cb:658 gonglei:
> virtio_serial_post_load_timer_cb   //calling the timer callback
> [2016-08-06 16:53:01] send_control_event:225 virtio serial port 1 send control
> message event = 6, value = 0 // send a message to the guest, raise the irq 
> line.
> [2016-08-06 16:53:01] virtio_serial_post_load_timer_cb:669 gonglei:
> port->host_connected: 0
> [2016-08-06 16:53:01] monitor_qapi_event_emit:483 {"timestamp":
> {"seconds": 1470473581, "microseconds": 64056}, "event":
> "VSERPORT_CHANGE", "data": {"open": true, "id": "channel0"}}
> [2016-08-06 16:53:01] send_control_event:225 virtio serial port 3 send control
> message event = 6, value = 0
> [2016-08-06 16:53:01] virtio_serial_post_load_timer_cb:669 gonglei:
> port->host_connected: 0
> [2016-08-06 16:53:01] timerlist_run_timers:496 gongl

Re: [Qemu-devel] [Question] virtio-serial misses irq delivery on migration?

[Gonglei (Arei)]

ncoming_migration_co(void *opaque)
 const char *arpGuestCMD = "{\"execute\":\"guest-write-flag-arp\"}\n";
 const char *portName = "charchannel1";
 size_t uRet;
-
+QEMU_LOG("gonglei: enter process_incoming_migration_co()\n");
 ret = qemu_loadvm_state(f);
 qemu_fclose(f);
 free_xbzrle_decoded_buf();
diff --git a/qemu-timer.c b/qemu-timer.c
index 5741f0d..dd36bc9 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -160,6 +160,7 @@ void qemu_clock_enable(QEMUClockType type, bool enabled)
 QEMUTimerList *tl;
 bool old = clock->enabled;
 clock->enabled = enabled;
+QEMU_LOG("gonglei: type: %u, enabled: %u, old: %u\n", type, enabled, old);
 if (enabled && !old) {
 qemu_clock_notify(type);
 } else if (!enabled && old) {
@@ -475,6 +476,7 @@ bool timerlist_run_timers(QEMUTimerList *timer_list)
 bool progress = false;
 QEMUTimerCB *cb;
 void *opaque;
+static int count = 10;
 
 qemu_event_reset(&timer_list->timers_done_ev);
 if (!timer_list->clock->enabled) {
@@ -489,7 +491,10 @@ bool timerlist_run_timers(QEMUTimerList *timer_list)
 qemu_mutex_unlock(&timer_list->active_timers_lock);
 break;
 }
-
+   if (timer_list->clock->type == QEMU_CLOCK_VIRTUAL && count-- > 0) {
+   QEMU_LOG("gonglei: expire_time: %lld, current_time: %lld\n",
+ ts->expire_time, current_time);
+   }
 /* remove timer from the list before calling the callback */
 timer_list->active_timers = ts->next;
 ts->next = NULL;
diff --git a/vl.c b/vl.c
index 06f34fe..824b246 100644
--- a/vl.c
+++ b/vl.c
@@ -978,7 +978,7 @@ void vm_start(void)
 {
 RunState requested;
 int64_t start_time, end_time;
-
+QEMU_LOG("gonglei: enter vm_start\n");
 qemu_vmstop_requested(&requested);
 if (runstate_is_running() && requested == RUN_STATE_MAX) {
 return;


Can we wait looply the migration process finished when EAGAIN?

Regards,
-Gonglei


> -Original Message-
> From: Gonglei (Arei)
> Sent: Friday, August 05, 2016 5:14 PM
> To: Paolo Bonzini; 'jan.kis...@siemens.com'; 'amit.s...@redhat.com'
> Cc: qemu-devel@nongnu.org; k...@vger.kernel.org; Huangweidong (C)
> Subject: [Question] virtio-serial misses irq delivery on migration?
> 
> Hi Paolo , Jan, Amit
> 
> Recently we encountered a problem that the virtio-serial can't work after
> Migration in RH5.5 VM. The bigger problem is, I can't reproduce it. :(
> 
> It's phenomenon was much like BZ 867366, the usb-table mouse didn't work
> because
> the uhci and virtio-serial shard the irq line (using IOAPIC, not MSI). The new
> interrupt
> can't be injected to VM because the irq line bit had been set to 1, but the
> frontend
> driver never handle it or never know it.
> 
>  Bug 867366 - virtio-serial misses irq delivery on migration
> https://bugzilla.redhat.com/show_bug.cgi?id=867366
> 
> But my qemu is the newest qemu, Both commit 80dcfb8532"virtio-serial-bus:
> post_load
> send_event when vm is running" and commit bc6b815d9e " virtio-serial:
> propagate
> guest_connected to the port on post_load" are applied.
> 
> I noticed that Paolo posted another problem maybe have a pertential problem
> about
> apic in Comment 23. But this patch
>  https://bugzilla.redhat.com/attachment.cgi?id=635535&action=diff
> haven't merged into qemu master.
> 
> Would you give me some clues please? Thanks!
> 
> Regards,
> -Gonglei
> 

[Qemu-devel] [Question] virtio-serial misses irq delivery on migration?

[Gonglei (Arei)]

Hi Paolo , Jan, Amit

Recently we encountered a problem that the virtio-serial can't work after
Migration in RH5.5 VM. The bigger problem is, I can't reproduce it. :(

It's phenomenon was much like BZ 867366, the usb-table mouse didn't work because
the uhci and virtio-serial shard the irq line (using IOAPIC, not MSI). The new 
interrupt
can't be injected to VM because the irq line bit had been set to 1, but the 
frontend
driver never handle it or never know it.

 Bug 867366 - virtio-serial misses irq delivery on migration
https://bugzilla.redhat.com/show_bug.cgi?id=867366

But my qemu is the newest qemu, Both commit 80dcfb8532"virtio-serial-bus: 
post_load
send_event when vm is running" and commit bc6b815d9e " virtio-serial: propagate 
guest_connected to the port on post_load" are applied.

I noticed that Paolo posted another problem maybe have a pertential problem 
about
apic in Comment 23. But this patch
 https://bugzilla.redhat.com/attachment.cgi?id=635535&action=diff
haven't merged into qemu master.

Would you give me some clues please? Thanks!

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v6 1/2] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

Hi Xin,

Thanks for your feedback! Please see my embedded reply.

Regards,
-Gonglei


> -Original Message-
> From: Zeng, Xin [mailto:xin.z...@intel.com]
> Sent: Thursday, August 04, 2016 3:48 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org
> Cc: Huangpeng (Peter); Luonengjun; m...@redhat.com;
> cornelia.h...@de.ibm.com; stefa...@redhat.com;
> denglin...@chinamobile.com; Jani Kokkonen; ola.liljed...@arm.com;
> varun.se...@freescale.com; Keating, Brian A; Ma, Liang J; Griffin, John;
> Hanweidong (Randy); Huangweidong (C)
> Subject: RE: [PATCH v6 1/2] virtio-crypto: Add virtio crypto device 
> specification
> 
> On Monday, August 01, 2016 5:20 PM, Gonglei Wrote:
> > -Original Message-
> > From: Gonglei [mailto:arei.gong...@huawei.com]
> > Sent: Monday, August 1, 2016 5:20 PM
> > To: qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org
> > Cc: peter.huangp...@huawei.com; luoneng...@huawei.com;
> > m...@redhat.com; cornelia.h...@de.ibm.com; stefa...@redhat.com;
> > denglin...@chinamobile.com; jani.kokko...@huawei.com;
> > ola.liljed...@arm.com; varun.se...@freescale.com; Zeng, Xin
> > ; Keating, Brian A ; Ma,
> > Liang J ; Griffin, John ;
> > hanweid...@huawei.com; weidong.hu...@huawei.com; Gonglei
> > 
> > Subject: [PATCH v6 1/2] virtio-crypto: Add virtio crypto device 
> > specification
> >
> > 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.
> >
> > Signed-off-by: Gonglei 
> > 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 
> > ---
> >  content.tex   |   2 +
> >  virtio-crypto.tex | 793
> > ++
> >  2 files changed, 795 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..9465de3
> > --- /dev/null
> > +++ b/virtio-crypto.tex
> > @@ -0,0 +1,793 @@
> > +\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]
> > +\item[N-1] dataqN
> > +\item[N] controlq
> > +\end{description}
> > +
> > +N is set by \field{max_dataqueues} (\field{max_dataqueues} >= 1).
> > +
> > +\subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature
> > bits}
> > +  None currently defined
> > +
> > +\subsection{Device configuration layout}\label{sec:Device Types / Crypto
> > Device / Device configuration layout}
> > +
> > +Thirteen driver-read-only configuration fields are currently defined.
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_config {
> > +le32  version;
> > +le16  status;
> > +le16  max_dataqueues;
> > +le32  crypto_servi

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] [virtio-dev] Re: [PATCH v5] virtio-crypto: Add virtio crypto device specification

[Gonglei (Arei)]

> -Original Message-
> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Michael S. Tsirkin
> Sent: Friday, July 29, 2016 1:34 PM
> To: Zeng, Xin
> Cc: Gonglei (Arei); 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 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
> 
Okay, I got it, I'll add a separate patch :)


Regards,
-Gonglei

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

[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 v

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 
> > 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.

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-cr

Re: [Qemu-devel] [RFC v4] virtio-crypto specification

[Gonglei (Arei)]

> -Original Message-
> From: Zeng, Xin [mailto:xin.z...@intel.com]
> Sent: Monday, July 25, 2016 2:20 PM
> To: Gonglei (Arei); virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org
> Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck; m...@redhat.com;
> Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng (Peter); Zhoujian (jay,
> Euler); chenshanxi 00222737; 'Ola liljed...@arm.com'; Varun Sethi
> Subject: RE: [RFC v4] virtio-crypto specification
> 
> 
> 
> On Monday, July 25, 2016 9:38 AM Gonglei (Arei) wrote:
> >
> > Hi Xin,
> >
> >
> > > -Original Message-
> > > From: Zeng, Xin [mailto:xin.z...@intel.com]
> > > Sent: Friday, July 22, 2016 1:31 PM
> > > To: Gonglei (Arei); virtio-...@lists.oasis-open.org;
> > > qemu-devel@nongnu.org
> > > Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck;
> > > m...@redhat.com; Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng
> > > (Peter); Zhoujian (jay, Euler); chenshanxi 00222737; 'Ola
> > > liljed...@arm.com'; Varun Sethi
> > > Subject: RE: [RFC v4] virtio-crypto specification
> > >
> > > On Friday, July 22, 2016 10:53 AM Gonglei (Arei) wrote:
> > > >
> > > > Hi Xin,
> > > >
> > > > Thank you so much for your great comments.
> > > > I agree with you almostly except some trivial detals.
> > > > Please see my below replies.
> > > >
> > > > And I'll submit V5 next week, and you can finish the asym algos
> > > > parts if you like.
> > > > Let's co-work to finish the virtio-crypto spec, shall we?
> > > >
> > >
> > > That's great.
> > >
> > > > Regards,
> > > > -Gonglei
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Zeng, Xin [mailto:xin.z...@intel.com]
> > > > > Sent: Friday, July 22, 2016 8:48 AM
> > > > > To: Gonglei (Arei); virtio-...@lists.oasis-open.org; qemu-
> > > > de...@nongnu.org
> > > > > Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck;
> > > > > m...@redhat.com; Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng
> > > > > (Peter); Zhoujian (jay, Euler); chenshanxi 00222737; 'Ola
> > > > > liljed...@arm.com'; Varun Sethi
> > > > > Subject: RE: [RFC v4] virtio-crypto specification
> > > > >
> > > > > On Sunday, June 26, 2016 5:35 PM, Gonglei (Arei) Wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > This is the specification (version 4) about a new virtio crypto 
> > > > > > device.
> > > > > >
> > > > >
> > > > > In general, our comments around this proposal are listed below:
> > > > > 1. Suggest to introduce crypto services into virtio crypto device.
> > > > > The
> > > > services
> > > > > currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM,
> > PRIMITIVE.
> > > >
> > > > Yes, I agree, whether DRBG/NDRBG are included in PRIMITIVE service
> > > > or not?
> > > > If not, we'd better add another separate service.
> > >
> > > Yes, I think we can add these two into PRIMITIVE services.
> > >
> > > >
> > > > > 2. Suggest to 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".
> > > > >
> > > > It makes sense. Good.
> > > >
> > > > > #define VIRTIO_CRYPTO_OPCODE(service, op)   (((service)<<8) | (op))
> > > > > struct virtio_crypto_op_header {
> > > > > #define VIRTIO_CRYPTO_CIPHER_ENCRYPT
> > > > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_CIPHER, 0x00) #define
> > > > > VIRTIO_CRYPTO_CIPHER_DECRYPT
> > > > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_CIPHER, 0x01) #define
> > > > > VIRTIO_CRYPTO_HASH
> > > > &

Re: [Qemu-devel] [RFC v4] virtio-crypto specification

[Gonglei (Arei)]

Hi Xin,


> -Original Message-
> From: Zeng, Xin [mailto:xin.z...@intel.com]
> Sent: Friday, July 22, 2016 1:31 PM
> To: Gonglei (Arei); virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org
> Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck; m...@redhat.com;
> Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng (Peter); Zhoujian (jay,
> Euler); chenshanxi 00222737; 'Ola liljed...@arm.com'; Varun Sethi
> Subject: RE: [RFC v4] virtio-crypto specification
> 
> On Friday, July 22, 2016 10:53 AM Gonglei (Arei) wrote:
> >
> > Hi Xin,
> >
> > Thank you so much for your great comments.
> > I agree with you almostly except some trivial detals.
> > Please see my below replies.
> >
> > And I'll submit V5 next week, and you can finish the asym algos parts if you
> > like.
> > Let's co-work to finish the virtio-crypto spec, shall we?
> >
> 
> That's great.
> 
> > Regards,
> > -Gonglei
> >
> >
> > > -Original Message-
> > > From: Zeng, Xin [mailto:xin.z...@intel.com]
> > > Sent: Friday, July 22, 2016 8:48 AM
> > > To: Gonglei (Arei); virtio-...@lists.oasis-open.org; qemu-
> > de...@nongnu.org
> > > Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck; m...@redhat.com;
> > > Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng (Peter); Zhoujian (jay,
> > > Euler); chenshanxi 00222737; 'Ola liljed...@arm.com'; Varun Sethi
> > > Subject: RE: [RFC v4] virtio-crypto specification
> > >
> > > On Sunday, June 26, 2016 5:35 PM, Gonglei (Arei) Wrote:
> > > > Hi all,
> > > >
> > > > This is the specification (version 4) about a new virtio crypto device.
> > > >
> > >
> > > In general, our comments around this proposal are listed below:
> > > 1. Suggest to introduce crypto services into virtio crypto device. The
> > services
> > > currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM, PRIMITIVE.
> >
> > Yes, I agree, whether DRBG/NDRBG are included in PRIMITIVE service or
> > not?
> > If not, we'd better add another separate service.
> 
> Yes, I think we can add these two into PRIMITIVE services.
> 
> >
> > > 2. Suggest to 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".
> > >
> > It makes sense. Good.
> >
> > > #define VIRTIO_CRYPTO_OPCODE(service, op)   (((service)<<8) | (op))
> > > struct virtio_crypto_op_header {
> > > #define VIRTIO_CRYPTO_CIPHER_ENCRYPT
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_CIPHER, 0x00)
> > > #define VIRTIO_CRYPTO_CIPHER_DECRYPT
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_CIPHER, 0x01)
> > > #define VIRTIO_CRYPTO_HASH
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_HASH, 0x00)
> > > #define VIRTIO_CRYPTO_MAC
> > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_MAC, 0x00)
> > > #define VIRTIO_CRYPTO_KDF
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_KDF, 0x00)
> > > #define VIRTIO_CRYPTO_ASYM_KEY_GEN
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x00)
> > > #define VIRTIO_CRYPTO_ASYM_KEY_EXCHG
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x01)
> > > #define VIRTIO_CRYPTO_ASYM_SIGN
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x02)
> > > #define VIRTIO_CRYPTO_ASYM_VERIFY
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x03)
> > > #define VIRTIO_CRYPTO_ASYM_ENCRYPT
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x04)
> > > #define VIRTIO_CRYPTO_ASYM_DECRYPT
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x05)
> > > #define VIRTIO_CRYPTO_AEAD_ENCRYPT
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_AEAD, 0x00)
> > > #define VIRTIO_CRYPTO_AEAD_DECRYPT
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_AEAD, 0x01)
> > > #define VIRTIO_CRYPTO_PRIMITIVE
> > >   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_PRIMITIVE, 0x00)
> > >   u32 opcode;
> > >   u8 algo; /*service-specific algorithms*/
> > >   u8 flag; /*control flag*/
> >
> > We'd better add a 

Re: [Qemu-devel] [RFC v4] virtio-crypto specification

[Gonglei (Arei)]

Hi Xin,

Thank you so much for your great comments. 
I agree with you almostly except some trivial detals. 
Please see my below replies.

And I'll submit V5 next week, and you can finish the asym algos parts if you 
like.
Let's co-work to finish the virtio-crypto spec, shall we?

Regards,
-Gonglei


> -Original Message-
> From: Zeng, Xin [mailto:xin.z...@intel.com]
> Sent: Friday, July 22, 2016 8:48 AM
> To: Gonglei (Arei); virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org
> Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck; m...@redhat.com;
> Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng (Peter); Zhoujian (jay,
> Euler); chenshanxi 00222737; 'Ola liljed...@arm.com'; Varun Sethi
> Subject: RE: [RFC v4] virtio-crypto specification
> 
> On Sunday, June 26, 2016 5:35 PM, Gonglei (Arei) Wrote:
> > Hi all,
> >
> > This is the specification (version 4) about a new virtio crypto device.
> >
> 
> In general, our comments around this proposal are listed below:
> 1. Suggest to introduce crypto services into virtio crypto device. The 
> services
> currently defined are CIPHER, MAC, HASH, AEAD, KDF, ASYM, PRIMITIVE.

Yes, I agree, whether DRBG/NDRBG are included in PRIMITIVE service or not?
If not, we'd better add another separate service.

> 2. Suggest to 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".
> 
It makes sense. Good.

> #define VIRTIO_CRYPTO_OPCODE(service, op)   (((service)<<8) | (op))
> struct virtio_crypto_op_header {
> #define VIRTIO_CRYPTO_CIPHER_ENCRYPT
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_CIPHER, 0x00)
> #define VIRTIO_CRYPTO_CIPHER_DECRYPT
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_CIPHER, 0x01)
> #define VIRTIO_CRYPTO_HASH
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_HASH, 0x00)
> #define VIRTIO_CRYPTO_MAC
> VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_MAC, 0x00)
> #define VIRTIO_CRYPTO_KDF
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_KDF, 0x00)
> #define VIRTIO_CRYPTO_ASYM_KEY_GEN
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x00)
> #define VIRTIO_CRYPTO_ASYM_KEY_EXCHG
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x01)
> #define VIRTIO_CRYPTO_ASYM_SIGN
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x02)
> #define VIRTIO_CRYPTO_ASYM_VERIFY
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x03)
> #define VIRTIO_CRYPTO_ASYM_ENCRYPT
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x04)
> #define VIRTIO_CRYPTO_ASYM_DECRYPT
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_ASYM, 0x05)
> #define VIRTIO_CRYPTO_AEAD_ENCRYPT
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_AEAD, 0x00)
> #define VIRTIO_CRYPTO_AEAD_DECRYPT
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_AEAD, 0x01)
> #define VIRTIO_CRYPTO_PRIMITIVE
>   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_S_PRIMITIVE, 0x00)
>   u32 opcode;
>   u8 algo; /*service-specific algorithms*/
>   u8 flag; /*control flag*/

We'd better add a U64 session_id property here for service-specific algorithms.

> };
> 
> Take rsa_sign_request as example,
> A rsa sign service specific request is defined as:
> struct virtio_crypto_asym_rsa_sign_req{
>   struct virtio_crypto_rsa_sign_para parameter;
>   struct virtio_crypto_rsa_sign_input idata;
>   struct virtio_crypto_rsa_sign_output odata;
> };
> 
> A complete crypto service request is defined as:
> struct virtio_crypto_op_data_req {
>struct virtio_crypto_op_header header;
>   union {
>struct virtio_crypto_asym_rsa_sign_req
> rsa_sign_req;
>/*other service request*/
>   }u;
> };
> 
I wanted to do this in fact. ;) 

> More detailed comments are embedded below:
> 
> > 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. [

Re: [Qemu-devel] A question about 9894dc0cdcc397ee5b26370bc53da6d360a363c2

[Gonglei (Arei)]

Hi,

I got it, thanks for your quick reply :)


Regards,
-Gonglei


> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Monday, July 18, 2016 5:07 PM
> To: Gonglei (Arei)
> Cc: Paolo Bonzini; Lilijun (Jerry); qemu-devel@nongnu.org
> Subject: Re: A question about 9894dc0cdcc397ee5b26370bc53da6d360a363c2
> 
> On Mon, Jul 18, 2016 at 08:41:32AM +, Gonglei (Arei) wrote:
> > Hi Daniel & Paolo,
> >
> > Commit 9894dc0c "char: convert from GIOChannel to QIOChannel",
> > about the below code segment:
> >
> > static bool qemu_chr_open_socket_fd(CharDriverState *chr, Error **errp)
> >  {
> >  TCPCharDriver *s = chr->opaque;
> > -int fd;
> > +QIOChannelSocket *sioc = qio_channel_socket_new();
> >
> >  if (s->is_listen) {
> > -fd = socket_listen(s->addr, errp);
> > +if (qio_channel_socket_listen_sync(sioc, s->addr, errp) < 0) {
> > +goto fail;
> > +}
> > +qemu_chr_finish_socket_connection(chr, sioc);
> >  } else if (s->reconnect_time) {
> > -fd = socket_connect(s->addr, errp, qemu_chr_socket_connected,
> chr);
> > -return fd >= 0;
> > +qio_channel_socket_connect_async(sioc, s->addr,
> > +
> qemu_chr_socket_connected,
> > + chr, NULL);
> >  } else {
> > -fd = socket_connect(s->addr, errp, NULL, NULL);
> > -}
> > -if (fd < 0) {
> > -return false;
> > +if (qio_channel_socket_connect_sync(sioc, s->addr, errp) < 0) {
> > +goto fail;
> > +}
> > +qemu_chr_finish_socket_connection(chr, sioc);
> >  }
> >
> > -qemu_chr_finish_socket_connection(chr, fd);
> >  return true;
> > +
> > + fail:
> > +object_unref(OBJECT(sioc));
> > +return false;
> >  }
> >
> > Why did you change socket_connect() to qio_channel_socket_connect_async
> > but not qio_channel_socket_connect_sync when s->reconnect_time is ture?
> Thanks.
> > I can't get the reason from the commit message.
> 
> When the socket_connect() function is called with a non-null value for
> the NonBlockingConnectHandler parameter, it'll put the socket into
> non-blocking mode before doing the connection. Therefore socket_connect()
> method is no longer guaranteed to actually connect to the socket - it
> may simply start the connection and leave an event handler to finish
> it. This avoids blocking the caller waiting for the connectionb to
> finish which may take non-negligible time with TCP sockets.
> 
> The qio_channel_socket_connect_sync() method will always block until
> completion of the connect, so we use qio_channel_socket_connect_async
> which always does the connection attempt in the background.
> 
> The old code which may or may not finish the connect() in the background
> was a recipe for bugs because it forced callers to have 2 completely
> separate codepaths for the same API call and chances are only one of
> those code paths would be tested by the developers. With the code code
> we're guaranteed to always complete in the background, so the callers
> only have 1 codepath to worry about and so they'll be forced to ensure
> that codepath works.
> 
> > PS: We encountered a problem that when config vhost-user-net reconneticon
> function,
> > the virtio_net_get_features() didn't get a correct value after this changed,
> and it was
> > fixed when we change the async to sync.
> 
> It seems that you were mostly lucky with the old code in that presumably
> socket_connect() would complete the connection fully. There was never any
> guarantee of this though - it was perfectly feasible that socket_connect()
> would finish the connect in the background. So IMHO the vhost user code
> was already buggy if it doesn't cope with the connect finishing in the
> background.
> 
> 
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|

[Qemu-devel] A question about 9894dc0cdcc397ee5b26370bc53da6d360a363c2

[Gonglei (Arei)]

Hi Daniel & Paolo,

Commit 9894dc0c "char: convert from GIOChannel to QIOChannel", 
about the below code segment:

static bool qemu_chr_open_socket_fd(CharDriverState *chr, Error **errp)
 {
 TCPCharDriver *s = chr->opaque;
-int fd;
+QIOChannelSocket *sioc = qio_channel_socket_new();
 
 if (s->is_listen) {
-fd = socket_listen(s->addr, errp);
+if (qio_channel_socket_listen_sync(sioc, s->addr, errp) < 0) {
+goto fail;
+}
+qemu_chr_finish_socket_connection(chr, sioc);
 } else if (s->reconnect_time) {
-fd = socket_connect(s->addr, errp, qemu_chr_socket_connected, chr);
-return fd >= 0;
+qio_channel_socket_connect_async(sioc, s->addr,
+ qemu_chr_socket_connected,
+ chr, NULL);
 } else {
-fd = socket_connect(s->addr, errp, NULL, NULL);
-}
-if (fd < 0) {
-return false;
+if (qio_channel_socket_connect_sync(sioc, s->addr, errp) < 0) {
+goto fail;
+}
+qemu_chr_finish_socket_connection(chr, sioc);
 }
 
-qemu_chr_finish_socket_connection(chr, fd);
 return true;
+
+ fail:
+object_unref(OBJECT(sioc));
+return false;
 }

Why did you change socket_connect() to qio_channel_socket_connect_async
but not qio_channel_socket_connect_sync when s->reconnect_time is ture? Thanks.
I can't get the reason from the commit message.

PS: We encountered a problem that when config vhost-user-net reconneticon 
function,
the virtio_net_get_features() didn't get a correct value after this changed, 
and it was
fixed when we change the async to sync.

[2016-07-17 21:18:55] virtio_net_get_features:551 virtio_net_get_features 5 
n->host_features=12582855, features=2042626023, nc->peer=0x7f11c4b80820
[2016-07-17 21:18:55] get_vhost_net:400 get_vhost_net nc=0x7f11c4b80820
[2016-07-17 21:18:55] get_vhost_net:405 get_vhost_net nc type=11, 
NET_CLIENT_OPTIONS_KIND_TAP=3, NET_CLIENT_OPTIONS_KIND_VHOST_USER=11
[2016-07-17 21:18:55] get_vhost_net:417 get_vhost_net vhost_net=(nil)


Regards,
-Gonglei

Re: [Qemu-devel] [RFC v4] virtio-crypto specification

[Gonglei (Arei)]

Ping...

I'd like to know what's the process of a new virtio device can be merged? 
Anybody can tell me? Thanks a lot.

Taking Virtio-gpu as an example, the virtio-gpu had been merged in Linux kernel
And Qemu communities, but the corresponding virtio-gpu spec hadn't been merged
yet. Why was that? Am I missing some rules? Thanks. 


Regards,
-Gonglei


> -Original Message-----
> From: Gonglei (Arei)
> Sent: Sunday, June 26, 2016 5:35 PM
> To: virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org; Gonglei (Arei)
> Cc: Hanweidong (Randy); Stefan Hajnoczi; Cornelia Huck; m...@redhat.com;
> Lingli Deng; Jani Kokkonen; Luonengjun; Huangpeng (Peter); Zhoujian (jay,
> Euler); chenshanxi 00222737; 'Ola liljed...@arm.com'; Varun Sethi
> Subject: [RFC v4] virtio-crypto specification
> 
> Hi all,
> 
> This is the specification (version 4) about a new virtio crypto device.
> 
> 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.
> 
> If you have any comments, please let me know, thanks :)
> 
> 
> Virtio-crypto device Spec
>   Signed-off-by: Gonglei
> 
> 
> 1 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.
> 1.1   Device ID
> 20
> 1.2   Virtqueues
> 0  dataq
> …
> N-1  dataq
> N  controlq
> N is set by max_virtqueues (max_virtqueues >= 1).
> 1.3   Feature bits
> There are no feature bits (yet).
> 1.4   Device configuration layout
> Three driver-read-only configuration fields are currently defined. One 
> read-only
> bit (for the device) is currently defined for the 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.
> #define VIRTIO_CRYPTO_S_HW_READY  (1 << 0)
> #define VIRTIO_CRYPTO_S_STARTED  (1 << 1)
> 
> The following driver-read-only field, max_virtqueues specifies the maximum
> number of data virtqueues (dataq1. . .dataqN) .
> struct virtio_crypto_config {
>   le16 status;
>   le16 max_virtqueues;
>   le32 algorithms;
> };
> 
> The last driver-read-only field, algorithms specifies the algorithms which the
> device offered. Two read-only bits (for the driver) are currently defined for 
> the
> algorithms field: VIRTIO_CRYPTO_ALG_SYM and VIRTIO_CRYPTO_ALG_ASYM.
> #define VIRTIO_CRYPTO_ALG_SYM  (1 << 0)
> #define VIRTIO_CRYPTO_ALG_ASYM  (1 << 1)
> 1.4.1 Device Requirements: Device configuration layout
> The device MUST set max_virtqueues to between 1 and 65535 inclusive.
> 
> The device SHOULD set status according to the status of the hardware-backed
> implementation.
> 
> The device MUST set algorithms according to the algorithms which the device
> offered.
> 1.4.2 Driver Requirements: Device configuration layo

[Qemu-devel] [RFC v4] virtio-crypto specification

[Gonglei (Arei)]

Hi all,

This is the specification (version 4) about a new virtio crypto device. 

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.

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


Virtio-crypto device Spec
Signed-off-by: Gonglei 


1   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.
1.1 Device ID
20
1.2 Virtqueues
0  dataq
…
N-1  dataq
N  controlq
N is set by max_virtqueues (max_virtqueues >= 1).
1.3 Feature bits
There are no feature bits (yet).
1.4 Device configuration layout
Three driver-read-only configuration fields are currently defined. One 
read-only bit (for the device) is currently defined for the 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.
#define VIRTIO_CRYPTO_S_HW_READY  (1 << 0)
#define VIRTIO_CRYPTO_S_STARTED  (1 << 1)

The following driver-read-only field, max_virtqueues specifies the maximum 
number of data virtqueues (dataq1. . .dataqN) .
struct virtio_crypto_config {
le16 status;
le16 max_virtqueues;
le32 algorithms;
};

The last driver-read-only field, algorithms specifies the algorithms which the 
device offered. Two read-only bits (for the driver) are currently defined for 
the algorithms field: VIRTIO_CRYPTO_ALG_SYM and VIRTIO_CRYPTO_ALG_ASYM.
#define VIRTIO_CRYPTO_ALG_SYM  (1 << 0)
#define VIRTIO_CRYPTO_ALG_ASYM  (1 << 1)
1.4.1   Device Requirements: Device configuration layout
The device MUST set max_virtqueues to between 1 and 65535 inclusive.

The device SHOULD set status according to the status of the hardware-backed 
implementation.

The device MUST set algorithms according to the algorithms which the device 
offered.
1.4.2   Driver Requirements: Device configuration layout
The driver MUST read the ready status from the bottom bit of status to check 
whether the hardware-backed implementation is ready or not.
The driver MUST read the algorithms to discover the algorithms which the device 
supports.
1.5 Device Initialization
A driver would perform a typical initialization routine like so:
1. Identify and initialize data virtqueue, up to max_virtqueues.
2. Identify the control virtqueue.
3. Identify the ready status of hardware-backend comes from the bottom bit of 
status.
4. Read the supported algorithms from bits of algorithms. 
1.6 Device Operation
1.6.1   Session operation
The symmetric algorithms have the concept of sessions. A session is a handle 
which describes the
cryptographic parameters to be applied to a number of buffers. The data within 
a session handle includes the following:
•1. The operation (cipher, hash or both, and if both, the order in which the 
algorithms should be applied).
•2. The cipher setup data, including the cipher algorithm and mode, the key and 
its length, and the direction (encrypt or decrypt).
•3. The hash setup data, including the hash algorithm, mode (plain, nested or 
authenticated), and digest result length (to allow for truncation).
    Authenticated mode can refer to HMAC, which requires that the key and 
its length are also s

Re: [Qemu-devel] [PATCH v2 0/2] fix coverity complaint

[Gonglei (Arei)]

> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Thursday, May 12, 2016 9:38 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org
> Subject: Re: [PATCH v2 0/2] fix coverity complaint
> 
> On Do, 2016-05-12 at 17:57 +0800, Gonglei wrote:
> > Rebase on the latest master brunch.
>   ^^
> Haha.  Intentional or tyops?
> 
Oh, sorry, it's a typo ;)

> Added to ui queue now.
> 
> thanks,
>   Gerd

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH 1/6] egl-helpers: fix possible resource leak

[Gonglei (Arei)]

And this one.  Thanks :)


Regards,
-Gonglei


> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, March 03, 2016 7:19 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org
> Cc: qemu-triv...@nongnu.org
> Subject: Re: [PATCH 1/6] egl-helpers: fix possible resource leak
> 
> 
> 
> On 03/03/2016 10:43, Gonglei wrote:
> > CID 1352419, using g_strdup_printf instead of asprintf.
> >
> > Signed-off-by: Gonglei 
> > ---
> >  ui/egl-helpers.c | 9 +++--
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/ui/egl-helpers.c b/ui/egl-helpers.c
> > index 54be44c..2da1930 100644
> > --- a/ui/egl-helpers.c
> > +++ b/ui/egl-helpers.c
> > @@ -50,18 +50,15 @@ int qemu_egl_rendernode_open(void)
> >  continue;
> >  }
> >
> > -r = asprintf(&p, "/dev/dri/%s", e->d_name);
> > -if (r < 0) {
> > -return -1;
> > -}
> > +p = g_strdup_printf("/dev/dri/%s", e->d_name);
> >
> >  r = open(p, O_RDWR | O_CLOEXEC | O_NOCTTY |
> O_NONBLOCK);
> >  if (r < 0) {
> > -free(p);
> > +g_free(p);
> >  continue;
> >  }
> >  fd = r;
> > -free(p);
> > +g_free(p);
> >  break;
> >  }
> >
> >
> 
> Reviewed-by: Paolo Bonzini 

Re: [Qemu-devel] [PATCH 3/6] spice: fix coverity complains

[Gonglei (Arei)]

Hi Gerd,

Pls pick this one, thanks :)

Regards,
-Gonglei


> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, March 03, 2016 7:19 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org
> Cc: qemu-triv...@nongnu.org
> Subject: Re: [PATCH 3/6] spice: fix coverity complains
> 
> 
> 
> On 03/03/2016 10:43, Gonglei wrote:
> > Remove the unnecessary NULL check.
> >
> > Signed-off-by: Gonglei 
> > ---
> >  ui/spice-display.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/ui/spice-display.c b/ui/spice-display.c
> > index 242ab5f..1ffbec1 100644
> > --- a/ui/spice-display.c
> > +++ b/ui/spice-display.c
> > @@ -769,9 +769,7 @@ static void
> display_mouse_define(DisplayChangeListener *dcl,
> >  SimpleSpiceDisplay *ssd = container_of(dcl, SimpleSpiceDisplay, dcl);
> >
> >  qemu_mutex_lock(&ssd->lock);
> > -if (c) {
> > -cursor_get(c);
> > -}
> > +cursor_get(c);
> >  cursor_put(ssd->cursor);
> >  ssd->cursor = c;
> >  ssd->hot_x = c->hot_x;
> >
> 
> Reviewed-by: Paolo Bonzini