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
