> 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.) > > 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) - Hooking Qemu with CUSE and implementing the muser.ko interface 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. F. > > Stefan
