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
