qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 0/5] Vhost and vhost-net support for userspace bas


From: Antonios Motakis
Subject: Re: [Qemu-devel] [RFC 0/5] Vhost and vhost-net support for userspace based backends
Date: Wed, 4 Dec 2013 16:23:06 +0100




On Wed, Dec 4, 2013 at 2:56 PM, Stefan Hajnoczi <address@hidden> wrote:
On Fri, Nov 29, 2013 at 08:52:21PM +0100, Antonios Motakis wrote:
> In this patch series we would like to introduce our approach for putting a
> virtio-net backend in an external userspace process. Our eventual target is to
> run the network backend in the Snabbswitch ethernet switch, while receiving
> traffic from a guest inside QEMU/KVM which runs an unmodified virtio-net
> implementation.
>
> For this, we are working into extending vhost to allow equivalent functionality
> for userspace. Vhost already passes control of the data plane of virtio-net to
> the host kernel; we want to realize a similar model, but for userspace.
>
> In this patch series the concept of a vhost-backend is introduced.
>
> We define two vhost backend types - vhost-kernel and vhost-user. The former is
> the interface to the current kernel module implementation. Its control plane is
> ioctl based. The data plane is the kernel directly accessing the QEMU allocated,
> guest memory.
>
> In the new vhost-user backend, the control plane is based on communication
> between QEMU and another userspace process using a unix domain socket. This
> allows to implement a virtio backend for a guest running in QEMU, inside the
> other userspace process.

One thing that came to mind when reading the patches is that you are
implementing the vhost interface pretty much exactly as-is.  Did you
look at FUSE's character devices in userspace (CUSE)?  IIRC even ioctl
is supported so you might be able to skip the userspace backend entirely
if you mimic vhost_net.ko's ioctl interface.

Then all that's needed is some configuration/startup code to use shared
memory and pass the eventfds.

Stefan

Using UNIX domain sockets we can easily exchange the file descriptors we need, I don't know if this is the case with CUSE. Even though we reimplement ioctls via the UNIX domain socket, those are simple enough so I am also not sure CUSE would actually make things simpler.

Even so, the vhost server is not really a device to be represented as a character device. I don't know if it is the right approach to do it like that.

Antonios

reply via email to

[Prev in Thread] Current Thread [Next in Thread]