[Qemu-devel] vhost/virtio migration planning

[Qemu-devel] vhost/virtio migration planning

[Catalin Vasile]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

I am working on a virtio-crypto with vhost backend.
This functionality should expose a virtual cryptographic device to the
guest which would send crypto jobs to the host.
One problem I am facing is where to store session data (such as keys, IVs,
etc.).
For performance improvements, I would be ideal for these to be stored
inside the vhost module, so that the guest won't have to transfer session
data every time it needs to get a job done.
While this would be great for performance, this might represent a problem
when migrating VMs, because I would need to query the vhost module to get
my session data back in order to migrate successfully to a new host. The
problem with this is that it doesn't sound like the virtio-crypto model
will remain very backend agnostic.
Can I get some opinions of this situation, please?

[-- Attachment #2: Type: text/html, Size: 935 bytes --]

Re: [Qemu-devel] vhost/virtio migration planning

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Fri, Apr 17, 2015 at 02:03:59PM +0300, Catalin Vasile wrote:
> I am working on a virtio-crypto with vhost backend.

You didn't respond in the "[GSoC] project proposal" thread where I
explained why vhost isn't appropriate for this device:

  My suggestion is to work on the gnutls driver.  Then, if you have time
  left, get cryptodev upstream (it can be part of your GSoC project
  plan).

  That approach is more beneficial in the long run.  It will allow other
  applications to use the Crypto API too.

  vhost is good for exploiting kernel-only functionality (usually due to
  security/reliability boundaries).  In this case the only reason for
  vhost is that the userspace API isn't ready yet.  Use the opportunity
  to contribute to that effort instead of working around it.

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] vhost/virtio migration planning

[Catalin Vasile]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

Sorry for not respoding there.
When I started researching and working on this qemu-devel was the only
mailing list where I actually got support (answers)
for my questions.

On Tue, Apr 21, 2015 at 4:33 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Fri, Apr 17, 2015 at 02:03:59PM +0300, Catalin Vasile wrote:
> > I am working on a virtio-crypto with vhost backend.
>
> You didn't respond in the "[GSoC] project proposal" thread where I
> explained why vhost isn't appropriate for this device:
>
>   My suggestion is to work on the gnutls driver.  Then, if you have time
>   left, get cryptodev upstream (it can be part of your GSoC project
>   plan).
>
>   That approach is more beneficial in the long run.  It will allow other
>   applications to use the Crypto API too.
>
>   vhost is good for exploiting kernel-only functionality (usually due to
>   security/reliability boundaries).  In this case the only reason for
>   vhost is that the userspace API isn't ready yet.  Use the opportunity
>   to contribute to that effort instead of working around it.
>
> Stefan
>

[-- Attachment #2: Type: text/html, Size: 1581 bytes --]