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

[Daniel P . Berrangé]

On Tue, Dec 17, 2019 at 10:57:17PM +0000, Felipe Franciosi wrote:
> 
> 
> > On Dec 17, 2019, at 5:33 PM, Stefan Hajnoczi <address@hidden> wrote:
> > 
> > On Mon, Dec 16, 2019 at 07:57:32PM +0000, Felipe Franciosi wrote:
> >>> On 16 Dec 2019, at 20:47, Elena Ufimtseva <address@hidden> wrote:
> >>> On Fri, Dec 13, 2019 at 10:41:16AM +0000, Stefan Hajnoczi wrote:
> >>>> Is there a work-in-progress muser patch series you can post to start the
> >>>> discussion early?  That way we can avoid reviewers like myself asking
> >>>> you to make changes after you have invested a lot of time.
> >>>> 
> >>> 
> >>> Absolutely, that is our plan. At the moment we do not have the patches
> >>> ready for the review. We have setup internally a milestone and will be
> >>> sending that early version as a tarball after we have it completed.
> >>> Would be also a meeting something that could help us to stay on the same
> >>> page?
> >> 
> >> Please loop us in if you so set up a meeting.
> > 
> > There is a bi-weekly KVM Community Call that we can use for phone
> > discussions:
> > 
> >  
> > https://calendar.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
> > 
> > Or we can schedule a one-off call at any time :).
> 
> Sounds good either way, whenever it's needed.
> 
> > 
> > Questions I've seen when discussing muser with people have been:
> > 
> > 1. Can unprivileged containers create muser devices?  If not, this is a
> >   blocker for use cases that want to avoid root privileges entirely.
> 
> Yes you can. Muser device creation follows the same process as general
> mdev device creation (ie. you write to a sysfs path). That creates an
> entry in /dev/vfio and the control plane can further drop privileges
> there (set selinux contexts, &c.)

This isn't what I'd describe / consider as unprivileged, as AFAICT
although QEMU can use it unprivileged, this still requires a privileged
management process to do the setup in sysfs.

I think it is desirable to be able support a fully unprivileged
model where there is nothing requiring elevated privileges, neither
libvirtd or QEMU.

I think this basically ends up at the same requirement as support
for non-Linux hosts. We have to assume that some desirable deployment
scenarios will not be able to use Linux kernel features, either because
they lack privileges, or are simply non-Linux hosts.

> > 2. Does muser need to be in the kernel (e.g. slower to develop/ship,
> >   security reasons)?  A similar library could be implemented in
> >   userspace along the lines of the vhost-user protocol.  Although VMMs
> >   would then need to use a new libmuser-client library instead of
> >   reusing their VFIO code to access the device.
> 
> Doing it in userspace was the flow we proposed back in last year's KVM
> Forum (Edinburgh), but it got turned down. That's why we procured the
> kernel approach, which turned out to have some advantages:
> - No changes needed to Qemu
> - No Qemu needed at all for userspace drivers
> - Device emulation process restart is trivial
>   (it therefore makes device code upgrades much easier)
> 
> Having said that, nothing stops us from enhancing libmuser to talk
> directly to Qemu (for the Qemu case). I envision at least two ways of
> doing that:
> - Hooking up libmuser with Qemu directly (eg. over a unix socket)

A UNIX socket, or localhost TCP socket, sounds most appealing from a
a portability POV.

> - Hooking Qemu with CUSE and implementing the muser.ko interface

Perhaps I'm misunderstanding, but wouldn't a CUSE interface
still have issues with something needing to be privileged to
do the initial setup, and also still lack OS portability.

> For the latter, libmuser would talk to a character device just like it
> talks to the vfio character device. We "just" need to implement that
> backend in Qemu. :)
> 
> > 
> > 3. Should this feature be Linux-only?  vhost-user can be implemented on
> >   non-Linux OSes...
> 
> The userspace approach discussed above certainly can be more portable.
> Currently, muser depends on MDEV+VFIO and that's where the restriction
> comes from.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|