From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
airlied@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com
Subject: Re: [Qemu-devel] [PATCH v4 00/29] vhost-user for input & GPU
Date: Wed, 29 Aug 2018 11:22:01 +0100 [thread overview]
Message-ID: <20180829102201.GA2660@work-vm> (raw)
In-Reply-To: <20180829095035.GI31005@redhat.com>
* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Fri, Jul 13, 2018 at 03:08:47PM +0200, Marc-André Lureau wrote:
> > Hi,
> >
> > vhost-user allows to drive a virtio device in a seperate
> > process. After vhost-user-net, we have seen
> > vhost-user-{scsi,blk,crypto} added more recently.
> >
> > This series, initially proposed 2 years ago
> > (https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01905.html)
> > contributes with vhost-user-input and vhost-user-gpu.
> >
> > Additionally, to factor out common code and ease the usage, a
> > vhost-user-backend is introduced as an intermediary object between the
> > backend and the qemu device.
> >
> > You may start a vhost-user-gpu with virgl rendering in a separate
> > process like this:
> >
> > $ ./vhost-user-gpu --virgl -s vgpu.sock &
> > $ qemu...
> > -chardev socket,id=chr,path=vgpu.sock
> > -object vhost-user-backend,id=vug,chardev=chr
> > -device vhost-user-vga,vhost-user=vug
> >
> > You may also specify the backend command and the arguments as part of
> > vhost-user-backend qemu arguments. For example, to start a
> > vhost-user-input backend on input device /dev/input/event19:
> >
> > -object vhost-user-backend,id=vuid,cmd="vhost-user-input /dev/input/event19"
> > -device virtio-input-host-pci,vhost-user=vuid
> >
> > The vhost-user-gpu backend requires virgl from git.
> >
> > The libvirt support is on-going work:
> > https://github.com/elmarco/libvirt/commits/vhost-user-gpu
> >
> > The GPU benchmarks are encouraging, giving up to x5 performance on
> > Unigine Heaven 4.0.
>
> What is the main driving motivation behind this featureset ? Is it aimed
> at providing performance, or security, or allowing arbitrary out of tree
> backends, or all three ?
>
> Although we've got a number of vhost-user backends I'm pretty concerned
> about the direction this is taking QEMU overall.
>
> Managing QEMU is non-trivial for a number of reasons. We've done a lot of
> work to provide standardized modelling of CLI args, guest ABI stability
> via association with machine types, migration data stream stability,
> QEMU feature capabilities detection and so on.
>
> The move to outsource backends to external binaries is discarding some
> or all of these items, rewinding alot of progress we've made in the
> managability of QEMU. Each external binary has to now reinvent the
> things that are already solved in QEMU, and you can be sure each impl
> will reinvent the concepts differently.
>
> I can't help feeling that we are shooting ourselves in the foot here
> long term.
>
> We've always rejected the idea of having loadable modules in QEMU, but
> as a result we've end up with outsourcing the backend entirely via the
> vhost-user framework, so the end result is even more opaque than if we
> had loadable modules, and is unable to take advantage of our standardized
> modelling frameworks & capabilities :-(
>
> If we just look at performance & security, and ignore 3rd party impls
> for a minute, I really don't like that to gain perf + security we have
> to change from:
>
> $ qemu...
> -device virtio-vga
>
> To
>
> $ ./vhost-user-gpu --virgl -s vgpu.sock &
> $ qemu...
> -chardev socket,id=chr,path=vgpu.sock
> -object vhost-user-backend,id=vug,chardev=chr
> -device vhost-user-vga,vhost-user=vug
>
> Once we have the ability to run the backend via an external process,
> to gain performance & security benefits, assuming feature parity is
> achieved, I question why anyone would want to continue with the old
> in-process approach ? IOW the goal should be that the original args
>
> $ qemu...
> -device virtio-vga
>
> should "do the right thing" to launch the external process when you
> have upgraded to a new enough QEMU, so that everyone immediately
> benefits from the more secure & performant architecture.
But which external process should it run, under what privilieges
and with sockets placed where?
While it's true it would be good to have a nice simple way, often
the qemu process might not have the privs to run that external process
or know where to put the sockets; that's exactly the type of thing
we're happy to leave to libvirt to wire up.
Dave
> 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 :|
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2018-08-29 10:31 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-13 13:08 [Qemu-devel] [PATCH v4 00/29] vhost-user for input & GPU Marc-André Lureau
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 01/29] chardev: avoid crash if no associated address Marc-André Lureau
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 02/29] chardev: remove qemu_chr_fe_read_all() counter Marc-André Lureau
2018-08-28 15:05 ` Daniel P. Berrangé
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 03/29] chardev: unref if underlying chardev has no parent Marc-André Lureau
2018-08-28 15:06 ` Daniel P. Berrangé
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 04/29] dmabuf: add y0_top, pass it to spice Marc-André Lureau
2018-08-21 6:25 ` Gerd Hoffmann
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 05/29] vhost-user: simplify vhost_user_init/vhost_user_cleanup Marc-André Lureau
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 06/29] libvhost-user: exit by default on VHOST_USER_NONE Marc-André Lureau
2018-08-28 13:12 ` Jens Freimann
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 07/29] vhost-user: wrap some read/write with retry handling Marc-André Lureau
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 08/29] Add vhost-user-backend Marc-André Lureau
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 09/29] qio: add qio_channel_command_new_spawn_with_pre_exec() Marc-André Lureau
2018-08-28 15:09 ` Daniel P. Berrangé
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 10/29] HACK: vhost-user-backend: allow to specify binary to execute Marc-André Lureau
2018-08-28 15:44 ` Daniel P. Berrangé
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 11/29] vhost-user: split vhost_user_read() Marc-André Lureau
2018-08-28 15:46 ` Daniel P. Berrangé
2018-07-13 13:08 ` [Qemu-devel] [PATCH v4 12/29] vhost-user: add vhost_user_input_get_config() Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 13/29] libvhost-user: export vug_source_new() Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 14/29] contrib: add vhost-user-input Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 15/29] Add vhost-user-input-pci Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 16/29] vhost-user: add vhost_user_gpu_set_socket() Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 17/29] vhost-user: add vhost_user_gpu_get_num_capsets() Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 18/29] virtio: add virtio-gpu bswap helpers header Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 19/29] util: promote qemu_egl_rendernode_open() to libqemuutil Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 20/29] util: add qemu_write_pidfile() Marc-André Lureau
2018-08-28 15:52 ` Daniel P. Berrangé
2018-08-28 16:04 ` Marc-André Lureau
2018-08-31 10:42 ` Daniel P. Berrangé
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 21/29] util: use fcntl() for qemu_write_pidfile() locking Marc-André Lureau
2018-08-28 15:59 ` Daniel P. Berrangé
2018-08-28 16:07 ` Marc-André Lureau
2018-08-28 23:41 ` Marc-André Lureau
2018-08-29 8:12 ` Daniel P. Berrangé
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 22/29] contrib: add vhost-user-gpu Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 23/29] virtio-gpu: remove unused qdev Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 24/29] virtio-gpu: remove unused config_size Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 25/29] virtio-gpu: block both 2d and 3d rendering Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 26/29] virtio-gpu: remove useless 'waiting' field Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 27/29] virtio-gpu: split virtio-gpu, introduce virtio-gpu-base Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 28/29] virtio-gpu: split virtio-gpu-pci & virtio-vga Marc-André Lureau
2018-07-13 13:09 ` [Qemu-devel] [PATCH v4 29/29] hw/display: add vhost-user-vga & gpu-pci Marc-André Lureau
2018-08-29 9:13 ` Daniel P. Berrangé
2018-08-14 23:26 ` [Qemu-devel] [PATCH v4 00/29] vhost-user for input & GPU Marc-André Lureau
2018-08-21 7:51 ` Gerd Hoffmann
2018-08-21 10:10 ` Marc-André Lureau
2018-08-21 10:13 ` Daniel P. Berrangé
2018-08-28 10:49 ` Marc-André Lureau
2018-08-29 9:50 ` Daniel P. Berrangé
2018-08-29 10:22 ` Dr. David Alan Gilbert [this message]
2018-08-29 10:37 ` Daniel P. Berrangé
2018-08-29 11:34 ` Marc-André Lureau
2018-09-07 13:11 ` Marc-André Lureau
2018-09-11 8:59 ` Gerd Hoffmann
2018-09-11 9:16 ` Marc-André Lureau
2018-09-11 10:44 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180829102201.GA2660@work-vm \
--to=dgilbert@redhat.com \
--cc=airlied@redhat.com \
--cc=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).