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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Dec 19, 2019 at 12:50:21PM +0000, Daniel P. Berrangé wrote:
> On Tue, Dec 17, 2019 at 10:57:17PM +0000, Felipe Franciosi wrote:
> > 
> > 
> > > On Dec 17, 2019, at 5:33 PM, Stefan Hajnoczi <stefanha@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.ufimtseva@oracle.com> 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.

Felipe reminded me on IRC that muser needs FD passing, so a TCP
localhost socket is not an option.  So UNIX socket would give us
portability to any platform, except for Windows. It is not the
end of the world to lack Windows support.

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 :|