From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Zeng, Xin" <xin.zeng@intel.com>,
"Gonglei (Arei)" <arei.gonglei@huawei.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Halil Pasic <pasic@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [virtio-dev] Re: virtio crypto device implemenation
Date: Wed, 24 May 2017 12:21:20 +0200 [thread overview]
Message-ID: <20170524122120.55aba623.cornelia.huck@de.ibm.com> (raw)
In-Reply-To: <20170524001758-mutt-send-email-mst@kernel.org>
On Wed, 24 May 2017 04:13:47 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, May 23, 2017 at 04:08:25PM +0000, Zeng, Xin wrote:
> > Hi, Michael,
> > As you know, Lei Gong from Huawei and I are co-working on virtio crypto device spec, he is focusing on symmetric algorithm part, I am focusing on asymmetric part. Now I am planning the implementation for asymmetric part, would you please give me your point regarding the questions below?
> > Current virtio crypto device implementation from Lei Gong:
> > The virtio crypto device implementation has been upstreamed to QEMU and it has a qemu backend implementation for symmetric algorithm part, the front end Linux device driver for symmetric part has been upstreamed to Linux kernel as well.
> > My questions:
> > From my side, I planned to add the asymmetric part support in upstreamed front end device driver, and I don't want to add the asymmetric algorithm support to current virtio crypto device's qemu backend, instead, I would like to implement and upstream a DPDK vhost-user based backend for asymmetric algorithm, and accordingly Lei Gong will help to upstream a vhost user agent for virtio crypto device in QEMU, is this approach acceptable? Is a qemu backend a mandatory requirement for the virtio crypto device? Is there a general policy for this?
> >
> > Thanks
>
> Parity on QEMU side is naturally preferable. I don't think we should require it
> at all times, but if there's no implementation outside vhost-user,
> and if the feature includes a non-trivial amount of code, how
> will it be tested? I don't think we want to require all testers to use
> dpdk. An implementation under tests using libvhost-user might
> be a solution.
From the s390 perspective, I'd naturally prefer a qemu implementation.
I think there is value in being able to try it out on a variety of
platforms, so that you can shake out problems such as endianness easily.
prev parent reply other threads:[~2017-05-24 10:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 16:08 [Qemu-devel] virtio crypto device implemenation Zeng, Xin
2017-05-24 1:13 ` Michael S. Tsirkin
2017-05-24 10:21 ` Cornelia Huck [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170524122120.55aba623.cornelia.huck@de.ibm.com \
--to=cornelia.huck@de.ibm.com \
--cc=arei.gonglei@huawei.com \
--cc=mst@redhat.com \
--cc=pasic@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=xin.zeng@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.