qemu-devel
[Top][All Lists]
Advanced

[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: Daniel P . Berrangé
Subject: Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update
Date: Fri, 20 Dec 2019 10:22:37 +0000
User-agent: Mutt/1.12.1 (2019-06-15)

On Fri, Dec 20, 2019 at 09:47:12AM +0000, Stefan Hajnoczi wrote:
> On Thu, Dec 19, 2019 at 12:55:04PM +0000, Daniel P. Berrangé wrote:
> > On Thu, Dec 19, 2019 at 12:33:15PM +0000, Felipe Franciosi wrote:
> > > > On Dec 19, 2019, at 11:55 AM, Stefan Hajnoczi <address@hidden> wrote:
> > > > 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:
> > > To be clear: I'm very happy to have a userspace-only option for this,
> > > I just don't want to ditch the kernel module (yet, anyway). :)
> > 
> > If it doesn't create too large of a burden to support both, then I think
> > it is very desirable. IIUC, this is saying a kernel based solution as the
> > optimized/optimal solution, and userspace UNIX socket based option as the
> > generic "works everywhere" fallback solution.
> 
> I'm slightly in favor of the kernel implementation because it keeps us
> better aligned with VFIO.  That means solving problems in one place only
> and less reinventing the wheel.
> 
> Knowing that a userspace implementation is possible is a plus though.
> Maybe that option will become attractive in the future and someone will
> develop it.  In fact, a userspace implementation may be a cool Google
> Summer of Code project idea that I'd like to co-mentor.

If it is technically viable as an approach, then I think  we should be
treating a fully unprivileged muser-over-UNIX socket as a higher priority
than just "maybe a GSoC student will want todo it".

Libvirt is getting strong message from KubeVirt project that they want to
be running both libvirtd and QEMU fully unprivileged. This allows their
containers to be unprivileged. Anything that requires privileges requires
jumping through extra hoops writing custom code in KubeVirt to do things
outside libvirt in side loaded privileged containers and this limits how
where those features can be used.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]