[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] KVM Forum VFIO BoF summary
Re: [Qemu-devel] KVM Forum VFIO BoF summary
Fri, 23 Nov 2018 22:09:53 +0000
I'm also terribly sorry for the delay in responding to this. I'm only now
having the time resources to come back to this topic and figure out a way
forward with my proposal. Please see my notes below (quoting only the relevant
> On Nov 6, 2018, at 9:32 PM, Alex Williamson <address@hidden> wrote:
> There were mostly two main threads of discussion, the first was Filipe's
> discussion of a socket interface making use of the VFIO ABI to
> implement a userspace device model. For a VM use case, QEMU would be
> modified to use a socket for the VFIO ABI, including shared memory for
> DMA. Ideally this would be transparent for much of the QEMU vfio code
> outside of setup. Effectively this becomes a userspace implementation
> of mdev as this could already be done using mdev, but it requires a
> vendor driver to expose the userspace interface and likely a longer
> round trip through the kernel and back to userspace. Either path
> allows device models in userspace that can be open or proprietary, but
> this new proposal eliminates the vendor kernel driver component. Of
> course non-upstream kernel mdev vendor drivers do taint the host
> kernel, so they at least leave a breadcrumb.
Spot on. This can be done today via mdev, but it would unnecessarily involve
the kernel in the setup of devices. Also, since vfio is the only existing bus
driver for mdev, it would make little sense to implement an mdev "physical"
driver (which wouldn't have a physical backing device) just to talk a vfio-like
abi back to userspace.
This "vfio-user" proposal is a perfect fit for Qemu. I think the correct design
is to slightly rearchitect the vfio implementation in Qemu to allow for
userspace backends through unix sockets, very much like vhost-user does it for
virtio devices today.
As a matter of fact, with something like this in place, I think the Qemu code
could potentially be simplified by moving some of the existing vhost-user
offloading code underneath it.
> I believe Filipe
> mentioned a conversation after the BoF with Alex Graf who had a related
> concern about using the socket approach to use this as a non-GPL
> backdoor for device models in QEMU and a suggested approach was a GPL
> handshake via the socket interface.
Not exactly. The GPL-violating concerns came from Paolo and Stefan (cc'd). Alex
Graf (cc'd) came up with a solution for the concern which involves adding a
copyrighted "poem" to the protocol handshake. Qemu would then grant the
copyright for GPL applications, hence limiting who can use the protocol.
Vendors can obviously bypass this by using a GPL proxy application that talks
to Qemu, but then uses a separate mechanism (possibly another unix socket) to
talk to other non-GPL applications. Vendors which distribute Qemu can possibly
also bypass this by modifying the protocol not to include the copyrighted
messages. Using either legal loophole approach, however, can lead to a lot of
public point and shame.
The point I would like to discuss more widely (before going forwards with code)
is whether vendors can actually make use of a GPL-only protocol. I understand
the community desire of gathering efforts into GPL software, Qemu code and
Virtio. A non-GPL implementation means that maybe some vendors cannot use this.
I envision this protocol being used by userspace applications which _need_ to
emulate a device outside Qemu for performance reasons, not license reasons (eg.
a separate process can efficiently poll VQs from multiple VMs from a single
core). Applications that already do that today, albeit open-source, are not GPL
(eg. OVS, DPDK, SPDK).
This is why I'd like to hear more from Paolo and Stefan on why making this
non-GPL is so bad. It is already possible today (via mdev), and similar
approaches already exist for a large number of device implementations via
vhost-user. Additionally, I would also like to hear from willing vendors that
feel they could _only_ benefit from this if it does not enforce GPL.
Finally, I want to clarify I am not opposing making this GPL-only. I just want
to make sure the effort is justifiable (ie. there is reason for this to enforce
GPL peer applications given the existing vhost-user and mdev alternatives) and
not in vain (ie. there are GPL use cases for this out there).
- Re: [Qemu-devel] KVM Forum VFIO BoF summary,
Felipe Franciosi <=