On Thu, Jan 02, 2020 at 11:03:22AM +0000, Felipe Franciosi wrote: > > On Jan 2, 2020, at 10:42 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > > On Fri, Dec 20, 2019 at 10:22:37AM +0000, Daniel P. Berrangé wrote: > >> On Fri, Dec 20, 2019 at 09:47:12AM +0000, Stefan Hajnoczi wrote: > >>> On Thu, Dec 19, 2019 at 12:55:04PM +0000, Daniel P. Berrangé wrote: > >>>> On Thu, Dec 19, 2019 at 12:33:15PM +0000, Felipe Franciosi wrote: > >>>>>> On Dec 19, 2019, at 11:55 AM, Stefan Hajnoczi <stefa...@gmail.com> > >>>>>> wrote: > >>>>>> On Tue, Dec 17, 2019 at 10:57:17PM +0000, Felipe Franciosi wrote: > >>>>>>>> On Dec 17, 2019, at 5:33 PM, Stefan Hajnoczi <stefa...@redhat.com> > >>>>>>>> wrote: > >>>>>>>> On Mon, Dec 16, 2019 at 07:57:32PM +0000, Felipe Franciosi wrote: > >>>>>>>>>> On 16 Dec 2019, at 20:47, Elena Ufimtseva > >>>>>>>>>> <elena.ufimts...@oracle.com> wrote: > >>>>>>>>>> On Fri, Dec 13, 2019 at 10:41:16AM +0000, Stefan Hajnoczi wrote: > >>>>> To be clear: I'm very happy to have a userspace-only option for this, > >>>>> I just don't want to ditch the kernel module (yet, anyway). :) > >>>> > >>>> If it doesn't create too large of a burden to support both, then I think > >>>> it is very desirable. IIUC, this is saying a kernel based solution as the > >>>> optimized/optimal solution, and userspace UNIX socket based option as the > >>>> generic "works everywhere" fallback solution. > >>> > >>> I'm slightly in favor of the kernel implementation because it keeps us > >>> better aligned with VFIO. That means solving problems in one place only > >>> and less reinventing the wheel. > >>> > >>> Knowing that a userspace implementation is possible is a plus though. > >>> Maybe that option will become attractive in the future and someone will > >>> develop it. In fact, a userspace implementation may be a cool Google > >>> Summer of Code project idea that I'd like to co-mentor. > >> > >> If it is technically viable as an approach, then I think we should be > >> treating a fully unprivileged muser-over-UNIX socket as a higher priority > >> than just "maybe a GSoC student will want todo it". > >> > >> Libvirt is getting strong message from KubeVirt project that they want to > >> be running both libvirtd and QEMU fully unprivileged. This allows their > >> containers to be unprivileged. Anything that requires privileges requires > >> jumping through extra hoops writing custom code in KubeVirt to do things > >> outside libvirt in side loaded privileged containers and this limits how > >> where those features can be used. > > > > Okay this makes sense. > > > > There needs to be a consensus on whether to go with a qdev-over-socket > > approach that is QEMU-specific and strongly discourages third-party > > device distribution or a muser-over-socket approach that offers a stable > > API for VMM interoperability and third-party device distribution. > > The reason I dislike yet another offloading protocol (ie. there is > vhost, there is vfio, and then there would be qdev-over-socket) is > that we keep reinventing the wheel. I very much prefer picking > something solid (eg. VFIO) and keep investing on it.
I like the idea of sticking close to VFIO too. The first step is figuring out whether VFIO can be mapped to a UNIX domain socket protocol and many non-VFIO protocol messages are required. Hopefully that extra non-VFIO stuff isn't too large. If implementations can use the kernel uapi vfio header files then we're on track for compatibility with VFIO. > > This is just a more elaborate explanation for the "the cat is out of the > > bag" comments that have already been made on licensing. Does anyone > > still disagree or want to discuss further? > > > > If there is agreement that a stable API is okay then I think the > > practical way to do this is to first merge a cleaned-up version of > > multi-process QEMU as an unstable experimental API. Once it's being > > tested and used we can write a protocol specification and publish it as > > a stable interface when the spec has addressed most use cases. > > > > Does this sound good? > > In that case, wouldn't it be preferable to revive our proposal from > Edinburgh (KVM Forum 2018)? Our prototypes moved more of the Qemu VFIO > code to "common" and added a "user" backend underneath it, similar to > how vhost-user-scsi moved some of vhost-scsi to vhost-scsi-common and > added vhost-user-scsi. It was centric on PCI, but it doesn't have to > be. The other side can be implemented in libmuser for facilitating things. That sounds good. Stefan
signature.asc
Description: PGP signature
