Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update

[Stefan Hajnoczi]

On Wed, Dec 18, 2019 at 01:00:55AM +0100, Paolo Bonzini wrote:
> On 17/12/19 23:57, Felipe Franciosi wrote:
> > Doing it in userspace was the flow we proposed back in last year's KVM
> > Forum (Edinburgh), but it got turned down.
> 
> I think the time since then has shown that essentially the cat is out of
> the bag.  I didn't really like the idea of devices outside QEMU---and I
> still don't---but if something like "VFIO over AF_UNIX" turns out to be
> the cleanest way to implement multi-process QEMU device models, I am not
> going to pull an RMS and block that from happening.  Assuming I could
> even do so!

There are a range of approaches that will influence how out-of-process
devices can be licensed and distributed.

A VFIO-over-UNIX domain sockets approach means a stable API so that any
license (including proprietary) is possible.

Another approach is a QEMU-centric unstable protocol.  I'll call this
the qdev-over-UNIX domain sockets approach.  Maintaining an out-of-tree
device is expensive and ugly since the protocol changes between QEMU
versions in ways that are incompatible and undetectable.

On top of that, the initialization protocol message could include the
QEMU version string that the device was compiled against.  If the
version string doesn't match then QEMU will refuse to talk to the
device.

Distributing a single device executable that works with many QEMUs (e.g.
CentOS, Ubuntu) and versions becomes difficult.

I want to mention that we have the option of doing this if there are
strong concerns about out-of-tree devices.  It does have downsides:
1. Inability to share devices with other VMMs.
2. Probably won't replace vhost-user due to the out-of-tree limitations.
3. Can still be circumvented by a motivated device author.

Stefan

signature.asc
Description: PGP signature