Re: [virtio-dev] Backend libraries for VirtIO device emulation

[Stefan Hajnoczi <stefanha@redhat.com>]

On Fri, Mar 06, 2020 at 06:33:57PM +0000, Alex Bennée wrote:
> So the context of my question is what sort of common software layer is
> required to implement a virtio backend entirely in userspace?

Yes and no.

vhost-user is currently the most widely-used (cross-VMM) interface for
out-of-process VIRTIO device emulation.

However, it's not a library, just a protocol specification involving
UNIX domain sockets.  You mentioned the various implementations below:

> Currently most virtio backends are embedded directly in various VMMs
> which emulate a number of devices as well as deal with handling devices
> that are vhost aware and link with the host kernel. However there seems
> to be a growing interest in having backends implemented in separate
> processes, potentially even hosted in other guest VMs.
> 
> As far as I can tell there is a lot of duplicated effort in handling the
> low level navigation of virt queues and buffers. QEMU has code in
> hw/virtio as well as contrib/libvhost-user which is used by the recent
> virtiofsd daemon. kvm-tool has a virtio subdirectory that implements a
> similar set of functionality for it's emulation. The Rust-vmm project
> has libraries for implementing the device traits.

You missed DPDK/SPDK.

The issue is that no single library would work for all of these users.

DPDK/SPDK does poll-mode device emulation.  Therefore the details are
slightly different from the eventfd-based approach that event-driven
implementations will use.

rust-vmm crates are written in Rust, so direct code sharing is not
possible.  Bindings for a C library are possible but is that desirable
(it defeats the point of using a safe language, it may be harder to add
features for developers mainly using Rust).

Unifying everything does not seem realistic for these sorts of reasons.
What we have today is that the Linux kernel uapi headers are shared, so
at least the struct and constant definitions don't need to be duplicated
by C/C++ projects.

> Another aspect to this is the growing interest in carrying virtio over
> other hypervisors. I'm wondering if there is enough abstraction possible
> to have a common library that is hypervisor agnostic? Can a device

That already exists today.  Pick a vhost-user device implementation from
QEMU, DPDK/SPDK, or rust-vmm and run it with your VMM of choice.

> backend be emulated purely with some shared memory and some sockets for
> passing messages/kicks from/to the VMM which then deals with the hypervisor
> specifics of the virtio-transport?

Yes, that is what vhost-user does.

Stefan

Attachment: signature.asc
Description: PGP signature