> On Dec 19, 2019, at 5:36 AM, Stefan Hajnoczi <stefa...@gmail.com> 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
