[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [virtio-dev] Re: virtio crypto device implemenation
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [virtio-dev] Re: virtio crypto device implemenation |
Date: |
Wed, 24 May 2017 12:21:20 +0200 |
On Wed, 24 May 2017 04:13:47 +0300
"Michael S. Tsirkin" <address@hidden> 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.