[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status
From: |
Stefan Hajnoczi |
Subject: |
Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update |
Date: |
Thu, 19 Dec 2019 11:55:45 +0000 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
On Tue, Dec 17, 2019 at 10:57:17PM +0000, Felipe Franciosi wrote:
> > 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:
> > 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
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Elena Ufimtseva, 2019/12/10
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Stefan Hajnoczi, 2019/12/13
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Elena Ufimtseva, 2019/12/16
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Felipe Franciosi, 2019/12/16
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Stefan Hajnoczi, 2019/12/17
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Felipe Franciosi, 2019/12/17
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Paolo Bonzini, 2019/12/17
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Stefan Hajnoczi, 2019/12/19
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, John G Johnson, 2019/12/20
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update,
Stefan Hajnoczi <=
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Felipe Franciosi, 2019/12/19
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Daniel P . Berrangé, 2019/12/19
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Stefan Hajnoczi, 2019/12/20
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Paolo Bonzini, 2019/12/20
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Felipe Franciosi, 2019/12/20
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Alex Williamson, 2019/12/20
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Felipe Franciosi, 2019/12/20
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Daniel P . Berrangé, 2019/12/20
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Jag Raman, 2019/12/19
- Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update, Daniel P . Berrangé, 2019/12/19