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

[Felipe Franciosi]

> 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.)

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