[Qemu-devel] [RFC 0/5] Vhost and vhost-net support for userspace based backends

[Antonios Motakis <a.motakis@virtualopensystems.com>]

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.

The guest memory needs to be allocated using '-mem-path' and '-mem-prealloc'
command line options. This also incurs the use of HUGETLBFS, and allows the
backend userspace process to access the guest's memory. The preallocated RAM
file decriptor is shared with the vhost-user backend process.

The data path is realized by directly accessing the vrings and the buffer data
off the guest's memory.

The current user of vhost-user is only vhost-net, for which we add a new 'tap'
network backend option - 'vhostsock'. This parameter specifies the name of an
unix domain socket where the backend vhost-user process waits for a connaction.
This is a temporary scaffolding, as in the future we expect vhost-user to be
independent of the tap backend.

Based on wether the parameter is set or not, the 'tap' initialised vhost-net
will switch between vhost-kernel and vhost-user.

However, since we use another process as the network backend, QEMU should now
agnostic of the network backend used. In future versions of this series, we
intend to introduce a new QEMU network backend that is specific to vhost-user.

Current issues to be fixed:
 - No migration
 - (Probably) no ram hotplug
 - Will not start if the socket is not available
 - No reconnect when the backend disappears
 - Decouple vhost-net from the tap net backend when used with vhost-user

Antonios Motakis (5):
  Decouple vhost from kernel interface
  Add vhost-kernel and the vhost-user skeleton
  Add vhostsock option
  Add domain socket communication for vhost-user backend
  Add vhost-user calls implementation

 hw/net/vhost_net.c                |  29 ++--
 hw/scsi/vhost-scsi.c              |   9 +-
 hw/virtio/Makefile.objs           |   2 +-
 hw/virtio/vhost-backend.c         | 322 ++++++++++++++++++++++++++++++++++++++
 hw/virtio/vhost.c                 |  44 +++---
 include/hw/virtio/vhost-backend.h |  28 ++++
 include/hw/virtio/vhost.h         |   4 +-
 include/net/vhost_net.h           |   5 +-
 net/tap.c                         |   4 +-
 qapi-schema.json                  |   3 +
 qemu-options.hx                   |   3 +-
 11 files changed, 413 insertions(+), 40 deletions(-)
 create mode 100644 hw/virtio/vhost-backend.c
 create mode 100644 include/hw/virtio/vhost-backend.h

-- 
1.8.3.2