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

[John G Johnson]

> On Dec 19, 2019, at 5:36 AM, Stefan Hajnoczi <address@hidden> wrote:
> 
> 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.
> 

        This is very similar to our multi-process QEMU implementation before
we looked into using muser.  The differences are:

We use one object per emulated device type in QEMU rather than having a single
VFIO type that can masquerade as any PCI device.

We don’t pin guest memory; we pass the QEMU file descriptors used to create
guest memory to the emulation program, and it mmap()s them itself. (ala
vhost-user).

                                                                JJ



> 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