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: > > 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.)
In this case there is still a privileged step during setup. What about completely unprivileged scenarios like a regular user without root or a rootless container? > > 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. :) What about: * libmuser's API stays mostly unchanged but the library speaks a VFIO-over-UNIX domain sockets protocol instead of talking to mdev/vfio in the host kernel. * VMMs can implement this protocol directly for POSIX-portable and unprivileged operation. * A CUSE VFIO adapter simulates /dev/vfio so that VFIO-only VMMs can still take advantage of libmuser devices. Assuming this is feasible, would you lose any important features/advantages of the muser.ko approach? I don't know enough about VFIO to identify any blocker or obvious performance problems. Regarding recovery, it seems straightforward to keep state in a tmpfs file that can be reopened when the device is restarted. I don't think kernel code is necessary? Stefan
signature.asc
Description: PGP signature
