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