* [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input
@ 2018-11-26 12:42 Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends Marc-André Lureau
` (10 more replies)
0 siblings, 11 replies; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel; +Cc: kraxel, Marc-André Lureau
Hi,
This series is based on previously discussed "[PATCH v4 00/29]
vhost-user for input & GPU" and "vhost-user: define conventions for
vhost-user backends" work. The GPU part is left off for now.
This series introduces a "vhost-user-backend": a convenience object
for vhost-user devices, for common command line and initilization
handling. As a simple showcase, a "vhost-user-input-pci" device is
introduced, which can be used with the "contrib: add vhost-user-input"
example. vhost-user-input isn't meant to be installed, discovered or
used by libvirt: no installation is done (no vhost-user JSON file is
provided either).
thanks
Marc-André Lureau (11):
vhost-user: define conventions for vhost-user backends
vhost-user: simplify vhost_user_init/vhost_user_cleanup
libvhost-user: exit by default on VHOST_USER_NONE
vhost-user: wrap some read/write with retry handling
Add vhost-user-backend
vhost-user: split vhost_user_read()
vhost-user: add vhost_user_input_get_config()
libvhost-user-glib: export vug_source_new()
libvhost-user: add vu_queue_unpop()
Add vhost-user-input-pci
contrib: add vhost-user-input
contrib/libvhost-user/libvhost-user-glib.h | 3 +
contrib/libvhost-user/libvhost-user.h | 15 +
hw/virtio/virtio-pci.h | 10 +
include/hw/virtio/vhost-backend.h | 4 +
include/hw/virtio/vhost-user-blk.h | 2 +-
include/hw/virtio/vhost-user-scsi.h | 2 +-
include/hw/virtio/vhost-user.h | 2 +-
include/hw/virtio/virtio-input.h | 14 +
include/sysemu/vhost-user-backend.h | 60 ++++
backends/cryptodev-vhost-user.c | 18 +-
backends/vhost-user.c | 244 +++++++++++++
contrib/libvhost-user/libvhost-user-glib.c | 11 +-
contrib/libvhost-user/libvhost-user.c | 19 +-
contrib/vhost-user-input/main.c | 398 +++++++++++++++++++++
hw/block/vhost-user-blk.c | 22 +-
hw/input/vhost-user-input.c | 110 ++++++
hw/scsi/vhost-user-scsi.c | 20 +-
hw/virtio/vhost-stub.c | 4 +-
hw/virtio/vhost-user.c | 118 +++++-
hw/virtio/virtio-pci.c | 22 ++
net/vhost-user.c | 13 +-
vl.c | 3 +-
MAINTAINERS | 5 +
Makefile | 3 +
Makefile.objs | 1 +
backends/Makefile.objs | 3 +-
configure | 3 +
contrib/vhost-user-input/Makefile.objs | 1 +
docs/interop/vhost-user.json | 219 ++++++++++++
docs/interop/vhost-user.txt | 109 +++++-
hw/input/Makefile.objs | 1 +
qemu-options.hx | 20 ++
32 files changed, 1392 insertions(+), 87 deletions(-)
create mode 100644 include/sysemu/vhost-user-backend.h
create mode 100644 backends/vhost-user.c
create mode 100644 contrib/vhost-user-input/main.c
create mode 100644 hw/input/vhost-user-input.c
create mode 100644 contrib/vhost-user-input/Makefile.objs
create mode 100644 docs/interop/vhost-user.json
--
2.20.0.rc1
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
2018-11-26 20:57 ` Eric Blake
2018-12-10 14:29 ` Gerd Hoffmann
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 02/11] vhost-user: simplify vhost_user_init/vhost_user_cleanup Marc-André Lureau
` (9 subsequent siblings)
10 siblings, 2 replies; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel
Cc: kraxel, Marc-André Lureau, Daniel P . Berrangé,
Michael S. Tsirkin
As discussed during "[PATCH v4 00/29] vhost-user for input & GPU"
review, let's define a common set of backend conventions to help with
management layer implementation, and interoperability.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
---
MAINTAINERS | 1 +
docs/interop/vhost-user.json | 219 +++++++++++++++++++++++++++++++++++
docs/interop/vhost-user.txt | 101 +++++++++++++++-
3 files changed, 319 insertions(+), 2 deletions(-)
create mode 100644 docs/interop/vhost-user.json
diff --git a/MAINTAINERS b/MAINTAINERS
index 1032406c56..81e4368a43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1335,6 +1335,7 @@ vhost
M: Michael S. Tsirkin <mst@redhat.com>
S: Supported
F: hw/*/*vhost*
+F: docs/interop/vhost-user.json
F: docs/interop/vhost-user.txt
virtio
diff --git a/docs/interop/vhost-user.json b/docs/interop/vhost-user.json
new file mode 100644
index 0000000000..91b5bf499e
--- /dev/null
+++ b/docs/interop/vhost-user.json
@@ -0,0 +1,219 @@
+# -*- Mode: Python -*-
+#
+# Copyright (C) 2018 Red Hat, Inc.
+#
+# Authors:
+# Marc-André Lureau <marcandre.lureau@redhat.com>
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or
+# later. See the COPYING file in the top-level directory.
+
+##
+# = vhost user backend discovery & capabilities
+##
+
+##
+# @VHostUserBackendType:
+#
+# List the various vhost user backend types.
+#
+# @net: virtio net
+# @block: virtio block
+# @console: virtio console
+# @rng: virtio rng
+# @balloon: virtio balloon
+# @rpmsg: virtio remote processor messaging
+# @scsi: virtio scsi
+# @9p: 9p virtio console
+# @rproc-serial: virtio remoteproc serial link
+# @caif: virtio caif
+# @gpu: virtio gpu
+# @input: virtio input
+# @vsock: virtio vsock transport
+# @crypto: virtio crypto
+#
+# Since: 3.2
+##
+{
+ 'enum': 'VHostUserBackendType',
+ 'data': [ 'net', 'block', 'console', 'rng', 'balloon', 'rpmsg',
+ 'scsi', '9p', 'rproc-serial', 'caif', 'gpu', 'input', 'vsock',
+ 'crypto' ]
+}
+
+##
+# @VHostUserBackendInputFeature:
+#
+# List of vhost user "input" features.
+#
+# @evdev-path: The --evdev-path command line option is supported.
+# @no-grab: The --no-grab command line option is supported.
+#
+# Since: 3.2
+##
+{
+ 'enum': 'VHostUserBackendInputFeature',
+ 'data': [ 'evdev-path', 'no-grab' ]
+}
+
+##
+# @VHostUserBackendCapabilitiesInput:
+#
+# Capabilities reported by vhost user "input" backends
+#
+# @features: list of supported features.
+#
+# Since: 3.2
+##
+{
+ 'struct': 'VHostUserBackendCapabilitiesInput',
+ 'data': {
+ 'features': [ 'VHostUserBackendInputFeature' ]
+ }
+}
+
+##
+# @VHostUserBackendGPUFeature:
+#
+# List of vhost user "gpu" features.
+#
+# @render-node: The --render-node command line option is supported.
+# @virgl: The --virgl command line option is supported.
+#
+# Since: 3.2
+##
+{
+ 'enum': 'VHostUserBackendGPUFeature',
+ 'data': [ 'render-node', 'virgl' ]
+}
+
+##
+# @VHostUserBackendCapabilitiesGPU:
+#
+# Capabilities reported by vhost user "gpu" backends.
+#
+# @features: list of supported features.
+#
+# Since: 3.2
+##
+{
+ 'struct': 'VHostUserBackendCapabilitiesGPU',
+ 'data': {
+ 'features': [ 'VHostUserBackendGPUFeature' ]
+ }
+}
+
+##
+# @VHostUserBackendCapabilities:
+#
+# Capabilities reported by vhost user backends.
+#
+# @type: The vhost user backend type.
+#
+# Since: 3.2
+##
+{
+ 'union': 'VHostUserBackendCapabilities',
+ 'base': { 'type': 'VHostUserBackendType' },
+ 'discriminator': 'type',
+ 'data': {
+ 'input': 'VHostUserBackendCapabilitiesInput',
+ 'gpu': 'VHostUserBackendCapabilitiesGPU'
+ }
+}
+
+##
+# @VhostUserBackend:
+#
+# Describes a vhost user backend to management software.
+#
+# It is possible for multiple @VhostUserBackend elements to match the
+# search criteria of management software. Applications thus need rules
+# to pick one of the many matches, and users need the ability to
+# override distro defaults.
+#
+# It is recommended to create vhost user backend JSON files (each
+# containing a single @VhostUserBackend root element) with a
+# double-digit prefix, for example "50-qemu-gpu.json",
+# "50-crosvm-gpu.json", etc, so they can be sorted in predictable
+# order. The backend JSON files should be searched for in three
+# directories:
+#
+# - /usr/share/qemu/vhost-user -- populated by distro-provided
+# packages (XDG_DATA_DIRS covers
+# /usr/share by default),
+#
+# - /etc/qemu/vhost-user -- exclusively for sysadmins' local additions,
+#
+# - $XDG_CONFIG_HOME/qemu/vhost-user -- exclusively for per-user local
+# additions (XDG_CONFIG_HOME
+# defaults to $HOME/.config).
+#
+# Top-down, the list of directories goes from general to specific.
+#
+# Management software should build a list of files from all three
+# locations, then sort the list by filename (i.e., last pathname
+# component). Management software should choose the first JSON file on
+# the sorted list that matches the search criteria. If a more specific
+# directory has a file with same name as a less specific directory, then
+# the file in the more specific directory takes effect. If the more
+# specific file is zero length, it hides the less specific one.
+#
+# For example, if a distro ships
+#
+# - /usr/share/qemu/vhost-user/50-qemu-gpu.json
+#
+# - /usr/share/qemu/vhost-user/50-crosvm-gpu.json
+#
+# then the sysadmin can prevent the default QEMU being used at all with
+#
+# $ touch /etc/qemu/vhost-user/50-qemu-gpu.json
+#
+# The sysadmin can replace/alter the distro default OVMF with
+#
+# $ vim /etc/qemu/vhost-user/50-qemu-gpu.json
+#
+# or they can provide a parallel QEMU GPU with higher priority
+#
+# $ vim /etc/qemu/vhost-user/10-qemu-gpu.json
+#
+# or they can provide a parallel OVMF with lower priority
+#
+# $ vim /etc/qemu/vhost-user/99-qemu-gpu.json
+#
+# @type: The vhost user backend type.
+#
+# @description: Provides a human-readable description of the backend.
+# Management software may or may not display @description.
+#
+# @binary: Absolute path to the backend binary.
+#
+# @tags: An optional list of auxiliary strings associated with the
+# backend for which @description is not appropriate, due to the
+# latter's possible exposure to the end-user. @tags serves
+# development and debugging purposes only, and management
+# software shall explicitly ignore it.
+#
+# Since: 3.2
+#
+# Example:
+#
+# {
+# "description": "QEMU vhost-user-gpu",
+# "type": "gpu",
+# "binary": "/usr/libexec/qemu/vhost-user-gpu",
+# "tags": [
+# "CONFIG_OPENGL_DMABUF=y"
+# ]
+# }
+#
+##
+{
+ 'struct' : 'VhostUserBackend',
+ 'data' : {
+ 'description': 'str',
+ 'type': 'VHostUserBackendType',
+ 'binary': 'str',
+ '*tags': [ 'str' ]
+ }
+}
diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
index c2194711d9..cefec9ffe1 100644
--- a/docs/interop/vhost-user.txt
+++ b/docs/interop/vhost-user.txt
@@ -17,8 +17,13 @@ The protocol defines 2 sides of the communication, master and slave. Master is
the application that shares its virtqueues, in our case QEMU. Slave is the
consumer of the virtqueues.
-In the current implementation QEMU is the Master, and the Slave is intended to
-be a software Ethernet switch running in user space, such as Snabbswitch.
+In the current implementation QEMU is the Master, and the Slave is the
+external process consuming the virtio queues, for example a software
+Ethernet switch running in user space, such as Snabbswitch, or a block
+device backend processing read & write to a virtual disk. In order to
+facilitate interoperability between various backend implementations,
+it is recommended to follow the "Backend program conventions"
+described in this document.
Master and slave can be either a client (i.e. connecting) or server (listening)
in the socket communication.
@@ -835,3 +840,95 @@ resilient for selective requests.
For the message types that already solicit a reply from the client, the
presence of VHOST_USER_PROTOCOL_F_REPLY_ACK or need_reply bit being set brings
no behavioural change. (See the 'Communication' section for details.)
+
+Backend program conventions
+---------------------------
+
+vhost-user backends can provide various devices & services and may
+need to be configured manually depending on the use case. However, it
+is a good idea to follow the conventions listed here when
+possible. Users, QEMU or libvirt, can then rely on some common
+behaviour to avoid heterogenous configuration and management of the
+backend programs and facilitate interoperability.
+
+Each backend installed on a host system should come with at least one
+JSON file that conforms to the vhost-user.json schema. Each file
+informs the management applications about the backend type, and binary
+location. In addition, it defines rules for management apps for
+picking the highest priority backend when multiple match the search
+criteria (see @VhostUserBackend documentation in the schema file).
+
+If the backend is not capable of enabling a requested feature on the
+host (such as 3D acceleration with virgl), or the initialization
+failed, the backend should fail to start early and exit with a status
+!= 0. It may also print a message to stderr for further details.
+
+The backend program must not daemonize itself, but it may be
+daemonized by the management layer. It may also have a restricted
+access to the system.
+
+File descriptors 0, 1 and 2 will exist, and have regular
+stdin/stdout/stderr usage (they may have been redirected to /dev/null
+by the management layer, or to a log handler).
+
+The backend program must end (as quickly and cleanly as possible) when
+the SIGTERM signal is received. Eventually, it may be SIGKILL by the
+management layer after a few seconds.
+
+The following command line options have an expected behaviour. They
+are mandatory, unless explicitly said differently:
+
+* --socket-path=PATH
+
+This option specify the location of the vhost-user Unix domain socket.
+It is incompatible with --fd.
+
+* --fd=FDNUM
+
+When this argument is given, the backend program is started with the
+vhost-user socket as file descriptor FDNUM. It is incompatible with
+--socket-path.
+
+* --print-capabilities
+
+Output to stdout the backend capabilities in JSON format, and then
+exit successfully. Other options and arguments should be ignored, and
+the backend program should not perform its normal function. The
+capabilities can be reported dynamically depending on the host
+capabilities.
+
+The JSON output is described in the vhost-user.json schema, by
+@VHostUserBackendCapabilities. Example:
+{
+ "type": "foo",
+ "features": [
+ "feature-a",
+ "feature-b"
+ ]
+}
+
+vhost-user-input
+----------------
+
+Command line options:
+
+* --evdev-path=PATH (optional)
+
+Specify the linux input device.
+
+* --no-grab (optional)
+
+Do no request exclusive access to the input device.
+
+vhost-user-gpu
+--------------
+
+Command line options:
+
+* --render-node=PATH (optional)
+
+Specify the GPU DRM render node.
+
+* --virgl (optional)
+
+Enable virgl rendering support.
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 02/11] vhost-user: simplify vhost_user_init/vhost_user_cleanup
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 03/11] libvhost-user: exit by default on VHOST_USER_NONE Marc-André Lureau
` (8 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel
Cc: kraxel, Marc-André Lureau, Tiwei Bie, Gonglei,
Michael S. Tsirkin, Kevin Wolf, Max Reitz, Paolo Bonzini,
Fam Zheng, Jason Wang, open list:Block layer core
Take a VhostUserState* that can be pre-allocated, and initialize it
with the associated chardev.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Tiwei Bie <tiwei.bie@intel.com>
---
include/hw/virtio/vhost-user-blk.h | 2 +-
include/hw/virtio/vhost-user-scsi.h | 2 +-
include/hw/virtio/vhost-user.h | 2 +-
backends/cryptodev-vhost-user.c | 18 ++++--------------
hw/block/vhost-user-blk.c | 22 ++++------------------
hw/scsi/vhost-user-scsi.c | 20 ++++----------------
hw/virtio/vhost-stub.c | 4 ++--
hw/virtio/vhost-user.c | 16 ++++++++++++----
net/vhost-user.c | 13 ++++---------
9 files changed, 33 insertions(+), 66 deletions(-)
diff --git a/include/hw/virtio/vhost-user-blk.h b/include/hw/virtio/vhost-user-blk.h
index d52944aeeb..a8a106eecb 100644
--- a/include/hw/virtio/vhost-user-blk.h
+++ b/include/hw/virtio/vhost-user-blk.h
@@ -36,7 +36,7 @@ typedef struct VHostUserBlk {
uint32_t queue_size;
uint32_t config_wce;
struct vhost_dev dev;
- VhostUserState *vhost_user;
+ VhostUserState vhost_user;
} VHostUserBlk;
#endif
diff --git a/include/hw/virtio/vhost-user-scsi.h b/include/hw/virtio/vhost-user-scsi.h
index e429cacd8e..738f9288bd 100644
--- a/include/hw/virtio/vhost-user-scsi.h
+++ b/include/hw/virtio/vhost-user-scsi.h
@@ -30,7 +30,7 @@
typedef struct VHostUserSCSI {
VHostSCSICommon parent_obj;
- VhostUserState *vhost_user;
+ VhostUserState vhost_user;
} VHostUserSCSI;
#endif /* VHOST_USER_SCSI_H */
diff --git a/include/hw/virtio/vhost-user.h b/include/hw/virtio/vhost-user.h
index fd660393a0..811e325f42 100644
--- a/include/hw/virtio/vhost-user.h
+++ b/include/hw/virtio/vhost-user.h
@@ -22,7 +22,7 @@ typedef struct VhostUserState {
VhostUserHostNotifier notifier[VIRTIO_QUEUE_MAX];
} VhostUserState;
-VhostUserState *vhost_user_init(void);
+bool vhost_user_init(VhostUserState *user, CharBackend *chr, Error **errp);
void vhost_user_cleanup(VhostUserState *user);
#endif
diff --git a/backends/cryptodev-vhost-user.c b/backends/cryptodev-vhost-user.c
index d539f14d59..1052a5d0e9 100644
--- a/backends/cryptodev-vhost-user.c
+++ b/backends/cryptodev-vhost-user.c
@@ -47,7 +47,7 @@
typedef struct CryptoDevBackendVhostUser {
CryptoDevBackend parent_obj;
- VhostUserState *vhost_user;
+ VhostUserState vhost_user;
CharBackend chr;
char *chr_name;
bool opened;
@@ -104,7 +104,7 @@ cryptodev_vhost_user_start(int queues,
continue;
}
- options.opaque = s->vhost_user;
+ options.opaque = &s->vhost_user;
options.backend_type = VHOST_BACKEND_TYPE_USER;
options.cc = b->conf.peers.ccs[i];
s->vhost_crypto[i] = cryptodev_vhost_init(&options);
@@ -182,7 +182,6 @@ static void cryptodev_vhost_user_init(
size_t i;
Error *local_err = NULL;
Chardev *chr;
- VhostUserState *user;
CryptoDevBackendClient *cc;
CryptoDevBackendVhostUser *s =
CRYPTODEV_BACKEND_VHOST_USER(backend);
@@ -213,15 +212,10 @@ static void cryptodev_vhost_user_init(
}
}
- user = vhost_user_init();
- if (!user) {
- error_setg(errp, "Failed to init vhost_user");
+ if (!vhost_user_init(&s->vhost_user, &s->chr, errp)) {
return;
}
- user->chr = &s->chr;
- s->vhost_user = user;
-
qemu_chr_fe_set_handlers(&s->chr, NULL, NULL,
cryptodev_vhost_user_event, NULL, s, NULL, true);
@@ -307,11 +301,7 @@ static void cryptodev_vhost_user_cleanup(
}
}
- if (s->vhost_user) {
- vhost_user_cleanup(s->vhost_user);
- g_free(s->vhost_user);
- s->vhost_user = NULL;
- }
+ vhost_user_cleanup(&s->vhost_user);
}
static void cryptodev_vhost_user_set_chardev(Object *obj,
diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
index 1451940845..e728fbe7f9 100644
--- a/hw/block/vhost-user-blk.c
+++ b/hw/block/vhost-user-blk.c
@@ -249,7 +249,6 @@ static void vhost_user_blk_device_realize(DeviceState *dev, Error **errp)
{
VirtIODevice *vdev = VIRTIO_DEVICE(dev);
VHostUserBlk *s = VHOST_USER_BLK(vdev);
- VhostUserState *user;
int i, ret;
if (!s->chardev.chr) {
@@ -267,15 +266,10 @@ static void vhost_user_blk_device_realize(DeviceState *dev, Error **errp)
return;
}
- user = vhost_user_init();
- if (!user) {
- error_setg(errp, "vhost-user-blk: failed to init vhost_user");
+ if (!vhost_user_init(&s->vhost_user, &s->chardev, errp)) {
return;
}
- user->chr = &s->chardev;
- s->vhost_user = user;
-
virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK,
sizeof(struct virtio_blk_config));
@@ -291,7 +285,7 @@ static void vhost_user_blk_device_realize(DeviceState *dev, Error **errp)
vhost_dev_set_config_notifier(&s->dev, &blk_ops);
- ret = vhost_dev_init(&s->dev, s->vhost_user, VHOST_BACKEND_TYPE_USER, 0);
+ ret = vhost_dev_init(&s->dev, &s->vhost_user, VHOST_BACKEND_TYPE_USER, 0);
if (ret < 0) {
error_setg(errp, "vhost-user-blk: vhost initialization failed: %s",
strerror(-ret));
@@ -316,10 +310,7 @@ vhost_err:
virtio_err:
g_free(s->dev.vqs);
virtio_cleanup(vdev);
-
- vhost_user_cleanup(user);
- g_free(user);
- s->vhost_user = NULL;
+ vhost_user_cleanup(&s->vhost_user);
}
static void vhost_user_blk_device_unrealize(DeviceState *dev, Error **errp)
@@ -331,12 +322,7 @@ static void vhost_user_blk_device_unrealize(DeviceState *dev, Error **errp)
vhost_dev_cleanup(&s->dev);
g_free(s->dev.vqs);
virtio_cleanup(vdev);
-
- if (s->vhost_user) {
- vhost_user_cleanup(s->vhost_user);
- g_free(s->vhost_user);
- s->vhost_user = NULL;
- }
+ vhost_user_cleanup(&s->vhost_user);
}
static void vhost_user_blk_instance_init(Object *obj)
diff --git a/hw/scsi/vhost-user-scsi.c b/hw/scsi/vhost-user-scsi.c
index 2e1ba4a87b..fb73c36c44 100644
--- a/hw/scsi/vhost-user-scsi.c
+++ b/hw/scsi/vhost-user-scsi.c
@@ -69,7 +69,6 @@ static void vhost_user_scsi_realize(DeviceState *dev, Error **errp)
VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(dev);
VHostUserSCSI *s = VHOST_USER_SCSI(dev);
VHostSCSICommon *vsc = VHOST_SCSI_COMMON(s);
- VhostUserState *user;
Error *err = NULL;
int ret;
@@ -86,30 +85,24 @@ static void vhost_user_scsi_realize(DeviceState *dev, Error **errp)
return;
}
- user = vhost_user_init();
- if (!user) {
- error_setg(errp, "vhost-user-scsi: failed to init vhost_user");
+ if (!vhost_user_init(&s->vhost_user, &vs->conf.chardev, errp)) {
return;
}
- user->chr = &vs->conf.chardev;
vsc->dev.nvqs = 2 + vs->conf.num_queues;
vsc->dev.vqs = g_new(struct vhost_virtqueue, vsc->dev.nvqs);
vsc->dev.vq_index = 0;
vsc->dev.backend_features = 0;
- ret = vhost_dev_init(&vsc->dev, user,
+ ret = vhost_dev_init(&vsc->dev, &s->vhost_user,
VHOST_BACKEND_TYPE_USER, 0);
if (ret < 0) {
error_setg(errp, "vhost-user-scsi: vhost initialization failed: %s",
strerror(-ret));
- vhost_user_cleanup(user);
- g_free(user);
+ vhost_user_cleanup(&s->vhost_user);
return;
}
- s->vhost_user = user;
-
/* Channel and lun both are 0 for bootable vhost-user-scsi disk */
vsc->channel = 0;
vsc->lun = 0;
@@ -129,12 +122,7 @@ static void vhost_user_scsi_unrealize(DeviceState *dev, Error **errp)
g_free(vsc->dev.vqs);
virtio_scsi_common_unrealize(dev, errp);
-
- if (s->vhost_user) {
- vhost_user_cleanup(s->vhost_user);
- g_free(s->vhost_user);
- s->vhost_user = NULL;
- }
+ vhost_user_cleanup(&s->vhost_user);
}
static Property vhost_user_scsi_properties[] = {
diff --git a/hw/virtio/vhost-stub.c b/hw/virtio/vhost-stub.c
index 049089b5e2..c175148fce 100644
--- a/hw/virtio/vhost-stub.c
+++ b/hw/virtio/vhost-stub.c
@@ -7,9 +7,9 @@ bool vhost_has_free_slot(void)
return true;
}
-VhostUserState *vhost_user_init(void)
+bool vhost_user_init(VhostUserState *user, CharBackend *chr, Error **errp)
{
- return NULL;
+ return false;
}
void vhost_user_cleanup(VhostUserState *user)
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index e09bed0e4a..90a9492bcf 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -1739,17 +1739,24 @@ static bool vhost_user_mem_section_filter(struct vhost_dev *dev,
return result;
}
-VhostUserState *vhost_user_init(void)
+bool vhost_user_init(VhostUserState *user, CharBackend *chr, Error **errp)
{
- VhostUserState *user = g_new0(struct VhostUserState, 1);
-
- return user;
+ if (user->chr) {
+ error_setg(errp, "Cannot initialize vhost-user state");
+ return false;
+ }
+ user->chr = chr;
+ return true;
}
void vhost_user_cleanup(VhostUserState *user)
{
int i;
+ if (!user->chr) {
+ return;
+ }
+
for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
if (user->notifier[i].addr) {
object_unparent(OBJECT(&user->notifier[i].mr));
@@ -1757,6 +1764,7 @@ void vhost_user_cleanup(VhostUserState *user)
user->notifier[i].addr = NULL;
}
}
+ user->chr = NULL;
}
const VhostOps user_ops = {
diff --git a/net/vhost-user.c b/net/vhost-user.c
index a39f9c9974..cea78b81f6 100644
--- a/net/vhost-user.c
+++ b/net/vhost-user.c
@@ -291,19 +291,14 @@ static int net_vhost_user_init(NetClientState *peer, const char *device,
{
Error *err = NULL;
NetClientState *nc, *nc0 = NULL;
- VhostUserState *user = NULL;
NetVhostUserState *s = NULL;
+ VhostUserState *user;
int i;
assert(name);
assert(queues > 0);
- user = vhost_user_init();
- if (!user) {
- error_report("failed to init vhost_user");
- goto err;
- }
-
+ user = g_new0(struct VhostUserState, 1);
for (i = 0; i < queues; i++) {
nc = qemu_new_net_client(&net_vhost_user_info, peer, device, name);
snprintf(nc->info_str, sizeof(nc->info_str), "vhost-user%d to %s",
@@ -312,11 +307,11 @@ static int net_vhost_user_init(NetClientState *peer, const char *device,
if (!nc0) {
nc0 = nc;
s = DO_UPCAST(NetVhostUserState, nc, nc);
- if (!qemu_chr_fe_init(&s->chr, chr, &err)) {
+ if (!qemu_chr_fe_init(&s->chr, chr, &err) ||
+ !vhost_user_init(user, &s->chr, &err)) {
error_report_err(err);
goto err;
}
- user->chr = &s->chr;
}
s = DO_UPCAST(NetVhostUserState, nc, nc);
s->vhost_user = user;
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 03/11] libvhost-user: exit by default on VHOST_USER_NONE
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 02/11] vhost-user: simplify vhost_user_init/vhost_user_cleanup Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 04/11] vhost-user: wrap some read/write with retry handling Marc-André Lureau
` (7 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel; +Cc: kraxel, Marc-André Lureau, Jens Freimann
Since commit 2566378d6d13bf4d28c7770bdbda5f7682594bbe, libvhost-user
no longer panics on disconnect (rc == 0), and instead silently ignores
an invalid VHOST_USER_NONE message.
Without extra work from the API user, this will simply busy-loop on
HUP events. The obvious thing to do is to exit(0) instead, while
additional or different work can be done by overriding
iface->process_msg().
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Jens Freimann <jfreimann@redhat.com>
---
contrib/libvhost-user/libvhost-user.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/libvhost-user/libvhost-user.c b/contrib/libvhost-user/libvhost-user.c
index a6b46cdc03..41470daf57 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -1285,7 +1285,8 @@ vu_process_message(VuDev *dev, VhostUserMsg *vmsg)
case VHOST_USER_SET_CONFIG:
return vu_set_config(dev, vmsg);
case VHOST_USER_NONE:
- break;
+ /* if you need processing before exit, override iface->process_msg */
+ exit(0);
case VHOST_USER_POSTCOPY_ADVISE:
return vu_set_postcopy_advise(dev, vmsg);
case VHOST_USER_POSTCOPY_LISTEN:
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 04/11] vhost-user: wrap some read/write with retry handling
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
` (2 preceding siblings ...)
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 03/11] libvhost-user: exit by default on VHOST_USER_NONE Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 05/11] Add vhost-user-backend Marc-André Lureau
` (6 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel
Cc: kraxel, Marc-André Lureau, Philippe Mathieu-Daudé,
Michael S. Tsirkin
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
hw/virtio/vhost-user.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 90a9492bcf..0131bbb0fc 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -964,7 +964,10 @@ static void slave_read(void *opaque)
iov.iov_base = &hdr;
iov.iov_len = VHOST_USER_HDR_SIZE;
- size = recvmsg(u->slave_fd, &msgh, 0);
+ do {
+ size = recvmsg(u->slave_fd, &msgh, 0);
+ } while (size < 0 && (errno == EINTR || errno == EAGAIN));
+
if (size != VHOST_USER_HDR_SIZE) {
error_report("Failed to read from slave.");
goto err;
@@ -993,7 +996,10 @@ static void slave_read(void *opaque)
}
/* Read payload */
- size = read(u->slave_fd, &payload, hdr.size);
+ do {
+ size = read(u->slave_fd, &payload, hdr.size);
+ } while (size < 0 && (errno == EINTR || errno == EAGAIN));
+
if (size != hdr.size) {
error_report("Failed to read payload from slave.");
goto err;
@@ -1041,7 +1047,10 @@ static void slave_read(void *opaque)
iovec[1].iov_base = &payload;
iovec[1].iov_len = hdr.size;
- size = writev(u->slave_fd, iovec, ARRAY_SIZE(iovec));
+ do {
+ size = writev(u->slave_fd, iovec, ARRAY_SIZE(iovec));
+ } while (size < 0 && (errno == EINTR || errno == EAGAIN));
+
if (size != VHOST_USER_HDR_SIZE + hdr.size) {
error_report("Failed to send msg reply to slave.");
goto err;
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 05/11] Add vhost-user-backend
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
` (3 preceding siblings ...)
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 04/11] vhost-user: wrap some read/write with retry handling Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 06/11] vhost-user: split vhost_user_read() Marc-André Lureau
` (5 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel
Cc: kraxel, Marc-André Lureau, Michael S. Tsirkin, Paolo Bonzini
Create a vhost-user-backend object that holds a connection to a
vhost-user backend and can be referenced from virtio devices that
support it. See later patches for input & gpu usage.
A chardev must be specified to communicate with the vhost-user
backend, ex: -chardev socket,id=char0,path=/tmp/foo.sock -object
vhost-user-backend,id=vuid,chardev=char0.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
include/sysemu/vhost-user-backend.h | 60 +++++++
backends/vhost-user.c | 244 ++++++++++++++++++++++++++++
vl.c | 3 +-
MAINTAINERS | 2 +
backends/Makefile.objs | 3 +-
qemu-options.hx | 20 +++
6 files changed, 330 insertions(+), 2 deletions(-)
create mode 100644 include/sysemu/vhost-user-backend.h
create mode 100644 backends/vhost-user.c
diff --git a/include/sysemu/vhost-user-backend.h b/include/sysemu/vhost-user-backend.h
new file mode 100644
index 0000000000..60f811cae7
--- /dev/null
+++ b/include/sysemu/vhost-user-backend.h
@@ -0,0 +1,60 @@
+/*
+ * QEMU vhost-user backend
+ *
+ * Copyright (C) 2018 Red Hat Inc
+ *
+ * Authors:
+ * Marc-André Lureau <marcandre.lureau@redhat.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#ifndef QEMU_VHOST_USER_BACKEND_H
+#define QEMU_VHOST_USER_BACKEND_H
+
+#include "qom/object.h"
+#include "exec/memory.h"
+#include "qemu/option.h"
+#include "qemu/bitmap.h"
+#include "hw/virtio/vhost.h"
+#include "hw/virtio/vhost-user.h"
+#include "chardev/char-fe.h"
+#include "io/channel.h"
+
+#define TYPE_VHOST_USER_BACKEND "vhost-user-backend"
+#define VHOST_USER_BACKEND(obj) \
+ OBJECT_CHECK(VhostUserBackend, (obj), TYPE_VHOST_USER_BACKEND)
+#define VHOST_USER_BACKEND_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(VhostUserBackendClass, (obj), TYPE_VHOST_USER_BACKEND)
+#define VHOST_USER_BACKEND_CLASS(klass) \
+ OBJECT_CLASS_CHECK(VhostUserBackendClass, (klass), TYPE_VHOST_USER_BACKEND)
+
+typedef struct VhostUserBackend VhostUserBackend;
+typedef struct VhostUserBackendClass VhostUserBackendClass;
+
+struct VhostUserBackendClass {
+ ObjectClass parent_class;
+};
+
+struct VhostUserBackend {
+ /* private */
+ Object parent;
+
+ char *cmd;
+ char *chr_name;
+
+ CharBackend chr;
+ VhostUserState vhost_user;
+ struct vhost_dev dev;
+ QIOChannel *child;
+ VirtIODevice *vdev;
+ bool started;
+ bool completed;
+};
+
+int vhost_user_backend_dev_init(VhostUserBackend *b, VirtIODevice *vdev,
+ unsigned nvqs, Error **errp);
+void vhost_user_backend_start(VhostUserBackend *b);
+void vhost_user_backend_stop(VhostUserBackend *b);
+
+#endif
diff --git a/backends/vhost-user.c b/backends/vhost-user.c
new file mode 100644
index 0000000000..bf39c0751d
--- /dev/null
+++ b/backends/vhost-user.c
@@ -0,0 +1,244 @@
+/*
+ * QEMU vhost-user backend
+ *
+ * Copyright (C) 2018 Red Hat Inc
+ *
+ * Authors:
+ * Marc-André Lureau <marcandre.lureau@redhat.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+
+#include "qemu/osdep.h"
+#include "hw/qdev.h"
+#include "qapi/error.h"
+#include "qapi/qmp/qerror.h"
+#include "qemu/error-report.h"
+#include "qom/object_interfaces.h"
+#include "sysemu/vhost-user-backend.h"
+#include "sysemu/kvm.h"
+#include "io/channel-command.h"
+#include "hw/virtio/virtio-bus.h"
+
+static bool
+ioeventfd_enabled(void)
+{
+ return kvm_enabled() && kvm_eventfds_enabled();
+}
+
+int
+vhost_user_backend_dev_init(VhostUserBackend *b, VirtIODevice *vdev,
+ unsigned nvqs, Error **errp)
+{
+ int ret;
+
+ assert(!b->vdev && vdev);
+
+ if (!ioeventfd_enabled()) {
+ error_setg(errp, "vhost initialization failed: requires kvm");
+ return -1;
+ }
+
+ if (!vhost_user_init(&b->vhost_user, &b->chr, errp)) {
+ return -1;
+ }
+
+ b->vdev = vdev;
+ b->dev.nvqs = nvqs;
+ b->dev.vqs = g_new(struct vhost_virtqueue, nvqs);
+
+ ret = vhost_dev_init(&b->dev, &b->vhost_user, VHOST_BACKEND_TYPE_USER, 0);
+ if (ret < 0) {
+ error_setg_errno(errp, -ret, "vhost initialization failed");
+ return -1;
+ }
+
+ return 0;
+}
+
+void
+vhost_user_backend_start(VhostUserBackend *b)
+{
+ BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(b->vdev)));
+ VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
+ int ret, i ;
+
+ if (b->started) {
+ return;
+ }
+
+ if (!k->set_guest_notifiers) {
+ error_report("binding does not support guest notifiers");
+ return;
+ }
+
+ ret = vhost_dev_enable_notifiers(&b->dev, b->vdev);
+ if (ret < 0) {
+ return;
+ }
+
+ ret = k->set_guest_notifiers(qbus->parent, b->dev.nvqs, true);
+ if (ret < 0) {
+ error_report("Error binding guest notifier");
+ goto err_host_notifiers;
+ }
+
+ b->dev.acked_features = b->vdev->guest_features;
+ ret = vhost_dev_start(&b->dev, b->vdev);
+ if (ret < 0) {
+ error_report("Error start vhost dev");
+ goto err_guest_notifiers;
+ }
+
+ /* guest_notifier_mask/pending not used yet, so just unmask
+ * everything here. virtio-pci will do the right thing by
+ * enabling/disabling irqfd.
+ */
+ for (i = 0; i < b->dev.nvqs; i++) {
+ vhost_virtqueue_mask(&b->dev, b->vdev,
+ b->dev.vq_index + i, false);
+ }
+
+ b->started = true;
+ return;
+
+err_guest_notifiers:
+ k->set_guest_notifiers(qbus->parent, b->dev.nvqs, false);
+err_host_notifiers:
+ vhost_dev_disable_notifiers(&b->dev, b->vdev);
+}
+
+void
+vhost_user_backend_stop(VhostUserBackend *b)
+{
+ BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(b->vdev)));
+ VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
+ int ret = 0;
+
+ if (!b->started) {
+ return;
+ }
+
+ vhost_dev_stop(&b->dev, b->vdev);
+
+ if (k->set_guest_notifiers) {
+ ret = k->set_guest_notifiers(qbus->parent,
+ b->dev.nvqs, false);
+ if (ret < 0) {
+ error_report("vhost guest notifier cleanup failed: %d", ret);
+ }
+ }
+ assert(ret >= 0);
+
+ vhost_dev_disable_notifiers(&b->dev, b->vdev);
+ b->started = false;
+}
+
+static void
+vhost_user_backend_complete(UserCreatable *uc, Error **errp)
+{
+ VhostUserBackend *b = VHOST_USER_BACKEND(uc);
+ Chardev *chr;
+
+ if (!b->chr_name) {
+ error_setg(errp, "You must specificy 'chardev'.");
+ return;
+ }
+
+ chr = qemu_chr_find(b->chr_name);
+ if (chr == NULL) {
+ error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
+ "Chardev '%s' not found", b->chr_name);
+ return;
+ }
+
+ if (!qemu_chr_fe_init(&b->chr, chr, errp)) {
+ return;
+ }
+
+ b->completed = true;
+ /* could vhost_dev_init() happen here, so early vhost-user message
+ * can be exchanged */
+}
+
+static void set_chardev(Object *obj, const char *value, Error **errp)
+{
+ VhostUserBackend *b = VHOST_USER_BACKEND(obj);
+
+ if (b->completed) {
+ error_setg(errp, QERR_PERMISSION_DENIED);
+ } else {
+ g_free(b->chr_name);
+ b->chr_name = g_strdup(value);
+ }
+}
+
+static char *get_chardev(Object *obj, Error **errp)
+{
+ VhostUserBackend *b = VHOST_USER_BACKEND(obj);
+ Chardev *chr = qemu_chr_fe_get_driver(&b->chr);
+
+ if (chr && chr->label) {
+ return g_strdup(chr->label);
+ }
+
+ return NULL;
+}
+
+static void vhost_user_backend_init(Object *obj)
+{
+ object_property_add_str(obj, "chardev", get_chardev, set_chardev, NULL);
+}
+
+static void vhost_user_backend_finalize(Object *obj)
+{
+ VhostUserBackend *b = VHOST_USER_BACKEND(obj);
+
+ g_free(b->dev.vqs);
+ g_free(b->chr_name);
+
+ vhost_user_cleanup(&b->vhost_user);
+ qemu_chr_fe_deinit(&b->chr, true);
+
+ if (b->child) {
+ object_unref(OBJECT(b->child));
+ }
+}
+
+static bool
+vhost_user_backend_can_be_deleted(UserCreatable *uc)
+{
+ return true;
+}
+
+static void
+vhost_user_backend_class_init(ObjectClass *oc, void *data)
+{
+ UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc);
+
+ ucc->complete = vhost_user_backend_complete;
+ ucc->can_be_deleted = vhost_user_backend_can_be_deleted;
+}
+
+static const TypeInfo vhost_user_backend_info = {
+ .name = TYPE_VHOST_USER_BACKEND,
+ .parent = TYPE_OBJECT,
+ .instance_size = sizeof(VhostUserBackend),
+ .instance_init = vhost_user_backend_init,
+ .instance_finalize = vhost_user_backend_finalize,
+ .class_size = sizeof(VhostUserBackendClass),
+ .class_init = vhost_user_backend_class_init,
+ .interfaces = (InterfaceInfo[]) {
+ { TYPE_USER_CREATABLE },
+ { }
+ }
+};
+
+static void register_types(void)
+{
+ type_register_static(&vhost_user_backend_info);
+}
+
+type_init(register_types);
diff --git a/vl.c b/vl.c
index fa25d1ae2d..903ea9a445 100644
--- a/vl.c
+++ b/vl.c
@@ -2798,7 +2798,8 @@ static bool object_create_initial(const char *type, QemuOpts *opts)
}
#if defined(CONFIG_VHOST_USER) && defined(CONFIG_LINUX)
- if (g_str_equal(type, "cryptodev-vhost-user")) {
+ if (g_str_equal(type, "cryptodev-vhost-user") ||
+ g_str_equal(type, "vhost-user-backend")) {
return false;
}
#endif
diff --git a/MAINTAINERS b/MAINTAINERS
index 81e4368a43..1507f941dc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1337,6 +1337,8 @@ S: Supported
F: hw/*/*vhost*
F: docs/interop/vhost-user.json
F: docs/interop/vhost-user.txt
+F: backends/vhost-user.c
+F: include/sysemu/vhost-user-backend.h
virtio
M: Michael S. Tsirkin <mst@redhat.com>
diff --git a/backends/Makefile.objs b/backends/Makefile.objs
index 717fcbdae4..a5ec0bf907 100644
--- a/backends/Makefile.objs
+++ b/backends/Makefile.objs
@@ -12,7 +12,8 @@ common-obj-y += cryptodev-builtin.o
ifeq ($(CONFIG_VIRTIO),y)
common-obj-y += cryptodev-vhost.o
common-obj-$(call land,$(CONFIG_VHOST_USER),$(CONFIG_LINUX)) += \
- cryptodev-vhost-user.o
+ cryptodev-vhost-user.o \
+ vhost-user.o
endif
common-obj-$(CONFIG_LINUX) += hostmem-memfd.o
diff --git a/qemu-options.hx b/qemu-options.hx
index f7df472f43..2346521703 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4241,6 +4241,26 @@ secondary:
If you want to know the detail of above command line, you can read
the colo-compare git log.
+@item -object vhost-user-backend,id=id=@var{id},chardev=@var{chardevid}
+
+Create a vhost-user-backend object that holds a connection to a
+vhost-user backend and can be referenced from virtio/vhost-user
+devices that support it.
+
+The @var{id} parameter is a unique ID that will be used to reference
+this vhost-user backend from the @option{vhost-user} device. The
+@var{chardev} parameter is the unique ID of a character device backend
+that provides the connection to the vhost-user slave process. (Since 3.2)
+
+@example
+
+ # qemu-system-x86_64 \
+ [...] \
+ -object vhost-user-backend,id=vuid,chardev=char0 \
+ -device vhost-user-input-pci,vhost-user=vuid
+ [...]
+@end example
+
@item -object cryptodev-backend-builtin,id=@var{id}[,queues=@var{queues}]
Creates a cryptodev backend which executes crypto opreation from
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 06/11] vhost-user: split vhost_user_read()
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
` (4 preceding siblings ...)
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 05/11] Add vhost-user-backend Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 07/11] vhost-user: add vhost_user_input_get_config() Marc-André Lureau
` (4 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel
Cc: kraxel, Marc-André Lureau, Daniel P . Berrangé,
Michael S. Tsirkin
Split vhost_user_read(), so only header can be read with
vhost_user_read_header().
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
---
hw/virtio/vhost-user.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 0131bbb0fc..9256364e30 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -210,7 +210,7 @@ static bool ioeventfd_enabled(void)
return kvm_enabled() && kvm_eventfds_enabled();
}
-static int vhost_user_read(struct vhost_dev *dev, VhostUserMsg *msg)
+static int vhost_user_read_header(struct vhost_dev *dev, VhostUserMsg *msg)
{
struct vhost_user *u = dev->opaque;
CharBackend *chr = u->user->chr;
@@ -221,7 +221,7 @@ static int vhost_user_read(struct vhost_dev *dev, VhostUserMsg *msg)
if (r != size) {
error_report("Failed to read msg header. Read %d instead of %d."
" Original request %d.", r, size, msg->hdr.request);
- goto fail;
+ return -1;
}
/* validate received flags */
@@ -229,7 +229,21 @@ static int vhost_user_read(struct vhost_dev *dev, VhostUserMsg *msg)
error_report("Failed to read msg header."
" Flags 0x%x instead of 0x%x.", msg->hdr.flags,
VHOST_USER_REPLY_MASK | VHOST_USER_VERSION);
- goto fail;
+ return -1;
+ }
+
+ return 0;
+}
+
+static int vhost_user_read(struct vhost_dev *dev, VhostUserMsg *msg)
+{
+ struct vhost_user *u = dev->opaque;
+ CharBackend *chr = u->user->chr;
+ uint8_t *p = (uint8_t *) msg;
+ int r, size;
+
+ if (vhost_user_read_header(dev, msg) < 0) {
+ return -1;
}
/* validate message size is sane */
@@ -237,7 +251,7 @@ static int vhost_user_read(struct vhost_dev *dev, VhostUserMsg *msg)
error_report("Failed to read msg header."
" Size %d exceeds the maximum %zu.", msg->hdr.size,
VHOST_USER_PAYLOAD_SIZE);
- goto fail;
+ return -1;
}
if (msg->hdr.size) {
@@ -247,14 +261,11 @@ static int vhost_user_read(struct vhost_dev *dev, VhostUserMsg *msg)
if (r != size) {
error_report("Failed to read msg payload."
" Read %d instead of %d.", r, msg->hdr.size);
- goto fail;
+ return -1;
}
}
return 0;
-
-fail:
- return -1;
}
static int process_message_reply(struct vhost_dev *dev,
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 07/11] vhost-user: add vhost_user_input_get_config()
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
` (5 preceding siblings ...)
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 06/11] vhost-user: split vhost_user_read() Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
2018-12-10 14:26 ` Gerd Hoffmann
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 08/11] libvhost-user-glib: export vug_source_new() Marc-André Lureau
` (3 subsequent siblings)
10 siblings, 1 reply; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel; +Cc: kraxel, Marc-André Lureau, Michael S. Tsirkin
Ask vhost user input backend the list of virtio_input_config.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
contrib/libvhost-user/libvhost-user.h | 1 +
include/hw/virtio/vhost-backend.h | 4 ++
hw/virtio/vhost-user.c | 60 +++++++++++++++++++++++++++
docs/interop/vhost-user.txt | 8 ++++
4 files changed, 73 insertions(+)
diff --git a/contrib/libvhost-user/libvhost-user.h b/contrib/libvhost-user/libvhost-user.h
index 4aa55b4d2d..a4afbc3a46 100644
--- a/contrib/libvhost-user/libvhost-user.h
+++ b/contrib/libvhost-user/libvhost-user.h
@@ -91,6 +91,7 @@ typedef enum VhostUserRequest {
VHOST_USER_POSTCOPY_ADVISE = 28,
VHOST_USER_POSTCOPY_LISTEN = 29,
VHOST_USER_POSTCOPY_END = 30,
+ VHOST_USER_INPUT_GET_CONFIG = 31,
VHOST_USER_MAX
} VhostUserRequest;
diff --git a/include/hw/virtio/vhost-backend.h b/include/hw/virtio/vhost-backend.h
index 81283ec50f..1fca321d8a 100644
--- a/include/hw/virtio/vhost-backend.h
+++ b/include/hw/virtio/vhost-backend.h
@@ -12,6 +12,7 @@
#define VHOST_BACKEND_H
#include "exec/memory.h"
+#include "standard-headers/linux/virtio_input.h"
typedef enum VhostBackendType {
VHOST_BACKEND_TYPE_NONE = 0,
@@ -160,4 +161,7 @@ int vhost_backend_invalidate_device_iotlb(struct vhost_dev *dev,
int vhost_backend_handle_iotlb_msg(struct vhost_dev *dev,
struct vhost_iotlb_msg *imsg);
+int vhost_user_input_get_config(struct vhost_dev *dev,
+ struct virtio_input_config **config);
+
#endif /* VHOST_BACKEND_H */
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 9256364e30..d51d1087f6 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -89,6 +89,7 @@ typedef enum VhostUserRequest {
VHOST_USER_POSTCOPY_ADVISE = 28,
VHOST_USER_POSTCOPY_LISTEN = 29,
VHOST_USER_POSTCOPY_END = 30,
+ VHOST_USER_INPUT_GET_CONFIG = 31,
VHOST_USER_MAX
} VhostUserRequest;
@@ -338,6 +339,65 @@ static int vhost_user_write(struct vhost_dev *dev, VhostUserMsg *msg,
return 0;
}
+static void *vhost_user_read_size(struct vhost_dev *dev, uint32_t size)
+{
+ struct vhost_user *u = dev->opaque;
+ CharBackend *chr = u->user->chr;
+ int r;
+ uint8_t *p = g_malloc(size);
+
+ r = qemu_chr_fe_read_all(chr, p, size);
+ if (r != size) {
+ error_report("Failed to read msg payload."
+ " Read %d instead of %u.", r, size);
+ g_free(p);
+ return NULL;
+ }
+
+ return p;
+}
+
+int vhost_user_input_get_config(struct vhost_dev *dev,
+ struct virtio_input_config **config)
+{
+ void *p = NULL;
+ VhostUserMsg msg = {
+ .hdr.request = VHOST_USER_INPUT_GET_CONFIG,
+ .hdr.flags = VHOST_USER_VERSION,
+ };
+
+ if (vhost_user_write(dev, &msg, NULL, 0) < 0) {
+ goto err;
+ }
+
+ if (vhost_user_read_header(dev, &msg) < 0) {
+ goto err;
+ }
+
+ if (msg.hdr.request != VHOST_USER_INPUT_GET_CONFIG) {
+ error_report("Received unexpected msg type. Expected %d received %d",
+ VHOST_USER_INPUT_GET_CONFIG, msg.hdr.request);
+ goto err;
+ }
+
+ if (msg.hdr.size % sizeof(struct virtio_input_config)) {
+ error_report("Invalid msg size");
+ goto err;
+ }
+
+ p = vhost_user_read_size(dev, msg.hdr.size);
+ if (!p) {
+ goto err;
+ }
+
+ *config = p;
+ return msg.hdr.size / sizeof(struct virtio_input_config);
+
+err:
+ g_free(p);
+ return -1;
+}
+
static int vhost_user_set_log_base(struct vhost_dev *dev, uint64_t base,
struct vhost_log *log)
{
diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
index cefec9ffe1..95720be81b 100644
--- a/docs/interop/vhost-user.txt
+++ b/docs/interop/vhost-user.txt
@@ -766,6 +766,14 @@ Master message types
was previously sent.
The value returned is an error indication; 0 is success.
+ * VHOST_USER_INPUT_GET_CONFIG
+ Id: 31
+ Master payload: N/A
+ Slave payload: (struct virtio_input_config)*
+
+ Ask vhost user input backend the list of virtio_input_config, in
+ host endianness.
+
Slave message types
-------------------
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 08/11] libvhost-user-glib: export vug_source_new()
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
` (6 preceding siblings ...)
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 07/11] vhost-user: add vhost_user_input_get_config() Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 09/11] libvhost-user: add vu_queue_unpop() Marc-André Lureau
` (2 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel; +Cc: kraxel, Marc-André Lureau
Simplify the creation of FD sources for other users. This is just
convenience to avoid duplicating similar code elsewhere.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
contrib/libvhost-user/libvhost-user-glib.h | 3 +++
contrib/libvhost-user/libvhost-user-glib.c | 11 ++++++-----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/contrib/libvhost-user/libvhost-user-glib.h b/contrib/libvhost-user/libvhost-user-glib.h
index 6b2110b94c..d3200f3afc 100644
--- a/contrib/libvhost-user/libvhost-user-glib.h
+++ b/contrib/libvhost-user/libvhost-user-glib.h
@@ -29,4 +29,7 @@ void vug_init(VugDev *dev, int socket,
vu_panic_cb panic, const VuDevIface *iface);
void vug_deinit(VugDev *dev);
+GSource *vug_source_new(VugDev *dev, int fd, GIOCondition cond,
+ vu_watch_cb vu_cb, gpointer data);
+
#endif /* LIBVHOST_USER_GLIB_H */
diff --git a/contrib/libvhost-user/libvhost-user-glib.c b/contrib/libvhost-user/libvhost-user-glib.c
index 545f089587..42660a1b36 100644
--- a/contrib/libvhost-user/libvhost-user-glib.c
+++ b/contrib/libvhost-user/libvhost-user-glib.c
@@ -68,15 +68,16 @@ static GSourceFuncs vug_src_funcs = {
NULL
};
-static GSource *
-vug_source_new(VuDev *dev, int fd, GIOCondition cond,
+GSource *
+vug_source_new(VugDev *gdev, int fd, GIOCondition cond,
vu_watch_cb vu_cb, gpointer data)
{
+ VuDev *dev = &gdev->parent;
GSource *gsrc;
VugSrc *src;
guint id;
- g_assert(dev);
+ g_assert(gdev);
g_assert(fd >= 0);
g_assert(vu_cb);
@@ -106,7 +107,7 @@ set_watch(VuDev *vu_dev, int fd, int vu_evt, vu_watch_cb cb, void *pvt)
g_assert(cb);
dev = container_of(vu_dev, VugDev, parent);
- src = vug_source_new(vu_dev, fd, vu_evt, cb, pvt);
+ src = vug_source_new(dev, fd, vu_evt, cb, pvt);
g_hash_table_replace(dev->fdmap, GINT_TO_POINTER(fd), src);
}
@@ -141,7 +142,7 @@ vug_init(VugDev *dev, int socket,
dev->fdmap = g_hash_table_new_full(NULL, NULL, NULL,
(GDestroyNotify) g_source_destroy);
- dev->src = vug_source_new(&dev->parent, socket, G_IO_IN, vug_watch, NULL);
+ dev->src = vug_source_new(dev, socket, G_IO_IN, vug_watch, NULL);
}
void
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 09/11] libvhost-user: add vu_queue_unpop()
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
` (7 preceding siblings ...)
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 08/11] libvhost-user-glib: export vug_source_new() Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 10/11] Add vhost-user-input-pci Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 11/11] contrib: add vhost-user-input Marc-André Lureau
10 siblings, 0 replies; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel; +Cc: kraxel, Marc-André Lureau
vhost-user-input will make use of this function to undo some queue pop
in case the virtio queue does not have enough room.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
contrib/libvhost-user/libvhost-user.h | 14 ++++++++++++++
contrib/libvhost-user/libvhost-user.c | 16 ++++++++++++++++
2 files changed, 30 insertions(+)
diff --git a/contrib/libvhost-user/libvhost-user.h b/contrib/libvhost-user/libvhost-user.h
index a4afbc3a46..6c7cbe14b6 100644
--- a/contrib/libvhost-user/libvhost-user.h
+++ b/contrib/libvhost-user/libvhost-user.h
@@ -459,6 +459,20 @@ void vu_queue_notify(VuDev *dev, VuVirtq *vq);
*/
void *vu_queue_pop(VuDev *dev, VuVirtq *vq, size_t sz);
+
+/**
+ * vu_queue_unpop:
+ * @dev: a VuDev context
+ * @vq: a VuVirtq queue
+ * @elem: The #VuVirtqElement
+ * @len: number of bytes written
+ *
+ * Pretend the most recent element wasn't popped from the virtqueue. The next
+ * call to vu_queue_pop() will refetch the element.
+ */
+void vu_queue_unpop(VuDev *dev, VuVirtq *vq, VuVirtqElement *elem,
+ size_t len);
+
/**
* vu_queue_rewind:
* @dev: a VuDev context
diff --git a/contrib/libvhost-user/libvhost-user.c b/contrib/libvhost-user/libvhost-user.c
index 41470daf57..e011a6ed1c 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -1966,6 +1966,22 @@ vu_queue_pop(VuDev *dev, VuVirtq *vq, size_t sz)
return elem;
}
+static void
+vu_queue_detach_element(VuDev *dev, VuVirtq *vq, VuVirtqElement *elem,
+ size_t len)
+{
+ vq->inuse--;
+ /* unmap, when DMA support is added */
+}
+
+void
+vu_queue_unpop(VuDev *dev, VuVirtq *vq, VuVirtqElement *elem,
+ size_t len)
+{
+ vq->last_avail_idx--;
+ vu_queue_detach_element(dev, vq, elem, len);
+}
+
bool
vu_queue_rewind(VuDev *dev, VuVirtq *vq, unsigned int num)
{
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 10/11] Add vhost-user-input-pci
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
` (8 preceding siblings ...)
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 09/11] libvhost-user: add vu_queue_unpop() Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
2018-12-10 14:26 ` Gerd Hoffmann
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 11/11] contrib: add vhost-user-input Marc-André Lureau
10 siblings, 1 reply; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel; +Cc: kraxel, Marc-André Lureau, Michael S. Tsirkin
Add a new virtio-input device, which connects to a vhost-user
backend. Usage:
-object vhost-user-backend,id=vuid,chardev=... \
-device vhost-user-input-pci,vhost-user=vuid
vhost-user-input is similar to virtio-input-host, it is wrapped by
vhost-user-input-pci. Instead of reading configuration directly from
an input device / evdev, it reads it over vhost-user protocol with
INPUT_GET_CONFIG message. Then vhost-user-backend takes care of
interfacing the virtio device with the backend, for the queue & events
processing.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
hw/virtio/virtio-pci.h | 10 +++
include/hw/virtio/virtio-input.h | 14 ++++
hw/input/vhost-user-input.c | 110 +++++++++++++++++++++++++++++++
hw/virtio/virtio-pci.c | 22 +++++++
MAINTAINERS | 1 +
hw/input/Makefile.objs | 1 +
6 files changed, 158 insertions(+)
create mode 100644 hw/input/vhost-user-input.c
diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index 813082b0d7..c7e28e1b9c 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -54,6 +54,7 @@ typedef struct VirtIORngPCI VirtIORngPCI;
typedef struct VirtIOInputPCI VirtIOInputPCI;
typedef struct VirtIOInputHIDPCI VirtIOInputHIDPCI;
typedef struct VirtIOInputHostPCI VirtIOInputHostPCI;
+typedef struct VHostUserInputPCI VHostUserInputPCI;
typedef struct VirtIOGPUPCI VirtIOGPUPCI;
typedef struct VHostVSockPCI VHostVSockPCI;
typedef struct VirtIOCryptoPCI VirtIOCryptoPCI;
@@ -376,6 +377,15 @@ struct VirtIOInputHostPCI {
#endif
+#define TYPE_VHOST_USER_INPUT_PCI "vhost-user-input-pci"
+#define VHOST_USER_INPUT_PCI(obj) \
+ OBJECT_CHECK(VHostUserInputPCI, (obj), TYPE_VHOST_USER_INPUT_PCI)
+
+struct VHostUserInputPCI {
+ VirtIOPCIProxy parent_obj;
+ VHostUserInput vhi;
+};
+
/*
* virtio-gpu-pci: This extends VirtioPCIProxy.
*/
diff --git a/include/hw/virtio/virtio-input.h b/include/hw/virtio/virtio-input.h
index 054c38836f..4fca03e796 100644
--- a/include/hw/virtio/virtio-input.h
+++ b/include/hw/virtio/virtio-input.h
@@ -2,6 +2,7 @@
#define QEMU_VIRTIO_INPUT_H
#include "ui/input.h"
+#include "sysemu/vhost-user-backend.h"
/* ----------------------------------------------------------------- */
/* virtio input protocol */
@@ -42,11 +43,18 @@ typedef struct virtio_input_event virtio_input_event;
#define VIRTIO_INPUT_HOST_GET_PARENT_CLASS(obj) \
OBJECT_GET_PARENT_CLASS(obj, TYPE_VIRTIO_INPUT_HOST)
+#define TYPE_VHOST_USER_INPUT "vhost-user-input"
+#define VHOST_USER_INPUT(obj) \
+ OBJECT_CHECK(VHostUserInput, (obj), TYPE_VHOST_USER_INPUT)
+#define VHOST_USER_INPUT_GET_PARENT_CLASS(obj) \
+ OBJECT_GET_PARENT_CLASS(obj, TYPE_VHOST_USER_INPUT)
+
typedef struct VirtIOInput VirtIOInput;
typedef struct VirtIOInputClass VirtIOInputClass;
typedef struct VirtIOInputConfig VirtIOInputConfig;
typedef struct VirtIOInputHID VirtIOInputHID;
typedef struct VirtIOInputHost VirtIOInputHost;
+typedef struct VHostUserInput VHostUserInput;
struct VirtIOInputConfig {
virtio_input_config config;
@@ -98,6 +106,12 @@ struct VirtIOInputHost {
int fd;
};
+struct VHostUserInput {
+ VirtIOInput parent_obj;
+
+ VhostUserBackend *vhost;
+};
+
void virtio_input_send(VirtIOInput *vinput, virtio_input_event *event);
void virtio_input_init_config(VirtIOInput *vinput,
virtio_input_config *config);
diff --git a/hw/input/vhost-user-input.c b/hw/input/vhost-user-input.c
new file mode 100644
index 0000000000..ef1b23a8b2
--- /dev/null
+++ b/hw/input/vhost-user-input.c
@@ -0,0 +1,110 @@
+/*
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * (at your option) any later version. See the COPYING file in the
+ * top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu-common.h"
+
+#include "hw/qdev.h"
+#include "hw/virtio/virtio-input.h"
+
+static void vhost_input_realize(DeviceState *dev, Error **errp)
+{
+ VHostUserInput *vhi = VHOST_USER_INPUT(dev);
+ VirtIOInput *vinput = VIRTIO_INPUT(dev);
+ VirtIODevice *vdev = VIRTIO_DEVICE(dev);
+ virtio_input_config *config;
+ int i, ret;
+
+ if (!vhi->vhost) {
+ error_setg(errp, "'vhost-user' property is required");
+ return;
+ }
+
+ if (vhost_user_backend_dev_init(vhi->vhost, vdev, 2, errp) == -1) {
+ return;
+ }
+
+ ret = vhost_user_input_get_config(&vhi->vhost->dev, &config);
+ if (ret < 0) {
+ error_setg(errp, "failed to get input config");
+ return;
+ }
+ for (i = 0; i < ret; i++) {
+ virtio_input_add_config(vinput, &config[i]);
+ }
+ g_free(config);
+}
+
+static void vhost_input_change_active(VirtIOInput *vinput)
+{
+ VHostUserInput *vhi = VHOST_USER_INPUT(vinput);
+
+ if (vinput->active) {
+ vhost_user_backend_start(vhi->vhost);
+ } else {
+ vhost_user_backend_stop(vhi->vhost);
+ }
+}
+
+static const VMStateDescription vmstate_vhost_input = {
+ .name = "vhost-user-input",
+ .unmigratable = 1,
+};
+
+static void vhost_input_class_init(ObjectClass *klass, void *data)
+{
+ VirtIOInputClass *vic = VIRTIO_INPUT_CLASS(klass);
+ DeviceClass *dc = DEVICE_CLASS(klass);
+
+ dc->vmsd = &vmstate_vhost_input;
+ vic->realize = vhost_input_realize;
+ vic->change_active = vhost_input_change_active;
+}
+
+static void vhost_input_is_busy(const Object *obj, const char *name,
+ Object *val, Error **errp)
+{
+ VHostUserInput *vhi = VHOST_USER_INPUT(obj);
+
+ if (vhi->vhost) {
+ error_setg(errp, "can't use already busy vhost-user");
+ } else {
+ qdev_prop_allow_set_link_before_realize(obj, name, val, errp);
+ }
+}
+
+static void vhost_input_init(Object *obj)
+{
+ VHostUserInput *vhi = VHOST_USER_INPUT(obj);
+ VirtIOInput *vinput = VIRTIO_INPUT(obj);
+ struct virtio_input_config vhost_input_config[] = { { /* empty list */ } };
+
+ virtio_input_init_config(vinput, vhost_input_config);
+
+ object_property_add_link(obj, "vhost-user", TYPE_VHOST_USER_BACKEND,
+ (Object **)&vhi->vhost,
+ vhost_input_is_busy,
+ OBJ_PROP_LINK_STRONG,
+ &error_abort);
+}
+
+static const TypeInfo vhost_input_info = {
+ .name = TYPE_VHOST_USER_INPUT,
+ .parent = TYPE_VIRTIO_INPUT,
+ .instance_size = sizeof(VHostUserInput),
+ .instance_init = vhost_input_init,
+ .class_init = vhost_input_class_init,
+};
+
+/* ----------------------------------------------------------------- */
+
+static void vhost_input_register_types(void)
+{
+ type_register_static(&vhost_input_info);
+}
+
+type_init(vhost_input_register_types)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index a954799267..ec912db48d 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -2645,6 +2645,27 @@ static const TypeInfo virtio_host_pci_info = {
};
#endif
+#ifdef CONFIG_VHOST_USER
+static void vhost_user_input_pci_initfn(Object *obj)
+{
+ VHostUserInputPCI *dev = VHOST_USER_INPUT_PCI(obj);
+
+ virtio_instance_init_common(obj, &dev->vhi, sizeof(dev->vhi),
+ TYPE_VHOST_USER_INPUT);
+
+ object_property_add_alias(obj, "vhost-user",
+ OBJECT(&dev->vhi), "vhost-user",
+ &error_abort);
+}
+
+static const TypeInfo vhost_user_input_pci_info = {
+ .name = TYPE_VHOST_USER_INPUT_PCI,
+ .parent = TYPE_VIRTIO_INPUT_PCI,
+ .instance_size = sizeof(VHostUserInputPCI),
+ .instance_init = vhost_user_input_pci_initfn,
+};
+#endif
+
/* virtio-pci-bus */
static void virtio_pci_bus_new(VirtioBusState *bus, size_t bus_size,
@@ -2719,6 +2740,7 @@ static void virtio_pci_register_types(void)
#endif
#if defined(CONFIG_VHOST_USER) && defined(CONFIG_LINUX)
type_register_static(&vhost_user_scsi_pci_info);
+ type_register_static(&vhost_user_input_pci_info);
#endif
#ifdef CONFIG_VHOST_VSOCK
type_register_static(&vhost_vsock_pci_info);
diff --git a/MAINTAINERS b/MAINTAINERS
index 1507f941dc..4fcdd399db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1380,6 +1380,7 @@ L: qemu-s390x@nongnu.org
virtio-input
M: Gerd Hoffmann <kraxel@redhat.com>
S: Maintained
+F: hw/input/vhost-user-input.c
F: hw/input/virtio-input*.c
F: include/hw/virtio/virtio-input.h
diff --git a/hw/input/Makefile.objs b/hw/input/Makefile.objs
index c8b00f71ec..6adc308cdd 100644
--- a/hw/input/Makefile.objs
+++ b/hw/input/Makefile.objs
@@ -11,6 +11,7 @@ common-obj-$(CONFIG_VIRTIO_INPUT) += virtio-input.o
common-obj-$(CONFIG_VIRTIO_INPUT) += virtio-input-hid.o
ifeq ($(CONFIG_LINUX),y)
common-obj-$(CONFIG_VIRTIO_INPUT) += virtio-input-host.o
+common-obj-$(call land,$(CONFIG_VHOST_USER),$(CONFIG_VIRTIO_INPUT)) += vhost-user-input.o
endif
obj-$(CONFIG_MILKYMIST) += milkymist-softusb.o
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [Qemu-devel] [PATCH for-3.2 11/11] contrib: add vhost-user-input
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
` (9 preceding siblings ...)
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 10/11] Add vhost-user-input-pci Marc-André Lureau
@ 2018-11-26 12:42 ` Marc-André Lureau
10 siblings, 0 replies; 30+ messages in thread
From: Marc-André Lureau @ 2018-11-26 12:42 UTC (permalink / raw)
To: qemu-devel; +Cc: kraxel, Marc-André Lureau
Add a vhost-user input backend example, based on virtio-input-host
device. It takes an evdev path as argument, and can be associated with
a vhost-user-backend object, for example via a unix socket:
$ vhost-user-input -p /dev/input/eventX -s /tmp/vui.sock
$ qemu ... -chardev socket,id=vuic,path=/tmp/vui.sock
-object vhost-user-backend,chardev=vuic
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
contrib/vhost-user-input/main.c | 398 +++++++++++++++++++++++++
MAINTAINERS | 1 +
Makefile | 3 +
Makefile.objs | 1 +
configure | 3 +
contrib/vhost-user-input/Makefile.objs | 1 +
6 files changed, 407 insertions(+)
create mode 100644 contrib/vhost-user-input/main.c
create mode 100644 contrib/vhost-user-input/Makefile.objs
diff --git a/contrib/vhost-user-input/main.c b/contrib/vhost-user-input/main.c
new file mode 100644
index 0000000000..bef44f163d
--- /dev/null
+++ b/contrib/vhost-user-input/main.c
@@ -0,0 +1,398 @@
+/*
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * (at your option) any later version. See the COPYING file in the
+ * top-level directory.
+ */
+
+#include "qemu/osdep.h"
+
+#include <glib.h>
+#include <linux/input.h>
+
+#include "qemu/iov.h"
+#include "qemu/bswap.h"
+#include "contrib/libvhost-user/libvhost-user.h"
+#include "contrib/libvhost-user/libvhost-user-glib.h"
+#include "standard-headers/linux/virtio_input.h"
+#include "qapi/error.h"
+
+typedef struct virtio_input_event virtio_input_event;
+typedef struct virtio_input_config virtio_input_config;
+
+typedef struct VuInput {
+ VugDev dev;
+ GSource *evsrc;
+ int evdevfd;
+ GArray *config;
+ struct {
+ virtio_input_event event;
+ VuVirtqElement *elem;
+ } *queue;
+ uint32_t qindex, qsize;
+} VuInput;
+
+static void vi_input_send(VuInput *vi, struct virtio_input_event *event)
+{
+ VuDev *dev = &vi->dev.parent;
+ VuVirtq *vq = vu_get_queue(dev, 0);
+ VuVirtqElement *elem;
+ int i, len;
+
+ /* queue up events ... */
+ if (vi->qindex == vi->qsize) {
+ vi->qsize++;
+ vi->queue = g_realloc_n(vi->queue, vi->qsize, sizeof(vi->queue[0]));
+ }
+ vi->queue[vi->qindex++].event = *event;
+
+ /* ... until we see a report sync ... */
+ if (event->type != htole16(EV_SYN) ||
+ event->code != htole16(SYN_REPORT)) {
+ return;
+ }
+
+ /* ... then check available space ... */
+ for (i = 0; i < vi->qindex; i++) {
+ elem = vu_queue_pop(dev, vq, sizeof(VuVirtqElement));
+ if (!elem) {
+ while (--i >= 0) {
+ vu_queue_unpop(dev, vq, vi->queue[i].elem, 0);
+ }
+ vi->qindex = 0;
+ g_warning("virtio-input queue full");
+ return;
+ }
+ vi->queue[i].elem = elem;
+ }
+
+ /* ... and finally pass them to the guest */
+ for (i = 0; i < vi->qindex; i++) {
+ elem = vi->queue[i].elem;
+ len = iov_from_buf(elem->in_sg, elem->in_num,
+ 0, &vi->queue[i].event, sizeof(virtio_input_event));
+ vu_queue_push(dev, vq, elem, len);
+ g_free(elem);
+ }
+
+ vu_queue_notify(&vi->dev.parent, vq);
+ vi->qindex = 0;
+}
+
+static void
+vi_evdev_watch(VuDev *dev, int condition, void *data)
+{
+ VuInput *vi = data;
+ int fd = vi->evdevfd;
+
+ g_debug("Got evdev condition %x", condition);
+
+ struct virtio_input_event virtio;
+ struct input_event evdev;
+ int rc;
+
+ for (;;) {
+ rc = read(fd, &evdev, sizeof(evdev));
+ if (rc != sizeof(evdev)) {
+ break;
+ }
+
+ g_debug("input %d %d %d", evdev.type, evdev.code, evdev.value);
+
+ virtio.type = htole16(evdev.type);
+ virtio.code = htole16(evdev.code);
+ virtio.value = htole32(evdev.value);
+ vi_input_send(vi, &virtio);
+ }
+}
+
+
+static void vi_handle_status(VuInput *vi, virtio_input_event *event)
+{
+ struct input_event evdev;
+ int rc;
+
+ if (gettimeofday(&evdev.time, NULL)) {
+ perror("vi_handle_status: gettimeofday");
+ return;
+ }
+
+ evdev.type = le16toh(event->type);
+ evdev.code = le16toh(event->code);
+ evdev.value = le32toh(event->value);
+
+ rc = write(vi->evdevfd, &evdev, sizeof(evdev));
+ if (rc == -1) {
+ perror("vi_host_handle_status: write");
+ }
+}
+
+static void vi_handle_sts(VuDev *dev, int qidx)
+{
+ VuInput *vi = container_of(dev, VuInput, dev.parent);
+ VuVirtq *vq = vu_get_queue(dev, qidx);
+ virtio_input_event event;
+ VuVirtqElement *elem;
+ int len;
+
+ g_debug("%s", G_STRFUNC);
+
+ for (;;) {
+ elem = vu_queue_pop(dev, vq, sizeof(VuVirtqElement));
+ if (!elem) {
+ break;
+ }
+
+ memset(&event, 0, sizeof(event));
+ len = iov_to_buf(elem->out_sg, elem->out_num,
+ 0, &event, sizeof(event));
+ vi_handle_status(vi, &event);
+ vu_queue_push(dev, vq, elem, len);
+ g_free(elem);
+ }
+
+ vu_queue_notify(&vi->dev.parent, vq);
+}
+
+static void
+vi_panic(VuDev *dev, const char *msg)
+{
+ g_critical("%s\n", msg);
+ exit(EXIT_FAILURE);
+}
+
+static void
+vi_queue_set_started(VuDev *dev, int qidx, bool started)
+{
+ VuInput *vi = container_of(dev, VuInput, dev.parent);
+ VuVirtq *vq = vu_get_queue(dev, qidx);
+
+ g_debug("queue started %d:%d", qidx, started);
+
+ if (qidx == 1) {
+ vu_set_queue_handler(dev, vq, started ? vi_handle_sts : NULL);
+ }
+
+ started = vu_queue_started(dev, vu_get_queue(dev, 0)) &&
+ vu_queue_started(dev, vu_get_queue(dev, 1));
+
+ if (started && !vi->evsrc) {
+ vi->evsrc = vug_source_new(&vi->dev, vi->evdevfd,
+ G_IO_IN, vi_evdev_watch, vi);
+ }
+
+ if (!started && vi->evsrc) {
+ g_source_destroy(vi->evsrc);
+ vi->evsrc = NULL;
+ }
+}
+
+static int
+vi_process_msg(VuDev *dev, VhostUserMsg *vmsg, int *do_reply)
+{
+ VuInput *vi = container_of(dev, VuInput, dev.parent);
+
+ switch (vmsg->request) {
+ case VHOST_USER_INPUT_GET_CONFIG:
+ vmsg->size = vi->config->len * sizeof(virtio_input_config);
+ vmsg->data = g_memdup(vi->config->data, vmsg->size);
+ *do_reply = true;
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+static const VuDevIface vuiface = {
+ .queue_set_started = vi_queue_set_started,
+ .process_msg = vi_process_msg,
+};
+
+static void
+vi_bits_config(VuInput *vi, int type, int count)
+{
+ virtio_input_config bits;
+ int rc, i, size = 0;
+
+ memset(&bits, 0, sizeof(bits));
+ rc = ioctl(vi->evdevfd, EVIOCGBIT(type, count / 8), bits.u.bitmap);
+ if (rc < 0) {
+ return;
+ }
+
+ for (i = 0; i < count / 8; i++) {
+ if (bits.u.bitmap[i]) {
+ size = i + 1;
+ }
+ }
+ if (size == 0) {
+ return;
+ }
+
+ bits.select = VIRTIO_INPUT_CFG_EV_BITS;
+ bits.subsel = type;
+ bits.size = size;
+ g_array_append_val(vi->config, bits);
+}
+
+static int unix_sock_new(char *path)
+{
+ int sock;
+ struct sockaddr_un un;
+ size_t len;
+
+ sock = socket(AF_UNIX, SOCK_STREAM, 0);
+ if (sock <= 0) {
+ perror("socket");
+ return -1;
+ }
+
+ un.sun_family = AF_UNIX;
+ snprintf(un.sun_path, sizeof(un.sun_path), "%s", path);
+ len = sizeof(un.sun_family) + strlen(un.sun_path);
+
+ unlink(path);
+ if (bind(sock, (struct sockaddr *)&un, len) < 0) {
+ perror("bind");
+ goto fail;
+ }
+
+ if (listen(sock, 1) < 0) {
+ perror("listen");
+ goto fail;
+ }
+
+ return sock;
+
+fail:
+ close(sock);
+
+ return -1;
+}
+
+static char *opt_evdev;
+static int opt_fdnum = -1;
+static char *opt_socket_path;
+static gboolean opt_nograb;
+static gboolean opt_print_caps;
+
+static GOptionEntry entries[] = {
+ { "print-capabilities", 'c', 0, G_OPTION_ARG_NONE, &opt_print_caps,
+ "Print capabilities", NULL },
+ { "no-grab", 'n', 0, G_OPTION_ARG_NONE, &opt_nograb,
+ "Don't grab device", NULL },
+ { "fd", 'f', 0, G_OPTION_ARG_INT, &opt_fdnum,
+ "Use inherited fd socket", "FDNUM" },
+ { "socket-path", 's', 0, G_OPTION_ARG_FILENAME, &opt_socket_path,
+ "Use UNIX socket path", "PATH" },
+ { "evdev-path", 'p', 0, G_OPTION_ARG_FILENAME, &opt_evdev,
+ "evdev input device path", "PATH" },
+ { NULL, }
+};
+
+int
+main(int argc, char *argv[])
+{
+ GMainLoop *loop = NULL;
+ VuInput vi = { 0, };
+ int rc, ver, fd;
+ virtio_input_config id;
+ struct input_id ids;
+ GError *error = NULL;
+ GOptionContext *context;
+
+ context = g_option_context_new(NULL);
+ g_option_context_add_main_entries(context, entries, NULL);
+ if (!g_option_context_parse(context, &argc, &argv, &error)) {
+ g_printerr("Option parsing failed: %s\n", error->message);
+ exit(EXIT_FAILURE);
+ }
+ if (opt_print_caps) {
+ g_print("{\n");
+ g_print(" \"type\": \"input\",\n");
+ g_print(" \"features\": [\n");
+ g_print(" \"evdev-path\",\n");
+ g_print(" \"no-grab\"\n");
+ g_print(" ]\n");
+ g_print("}\n");
+ exit(EXIT_SUCCESS);
+ }
+ if (!opt_evdev) {
+ g_printerr("Please specify an evdev path\n");
+ exit(EXIT_FAILURE);
+ }
+ if ((!!opt_socket_path + (opt_fdnum != -1)) != 1) {
+ g_printerr("Please specify either --fd or --socket-path\n");
+ exit(EXIT_FAILURE);
+ }
+
+ vi.evdevfd = open(opt_evdev, O_RDWR);
+ if (vi.evdevfd < 0) {
+ g_printerr("Failed to open evdev: %s\n", g_strerror(errno));
+ exit(EXIT_FAILURE);
+ }
+
+ rc = ioctl(vi.evdevfd, EVIOCGVERSION, &ver);
+ if (rc < 0) {
+ g_printerr("%s: is not an evdev device\n", argv[1]);
+ exit(EXIT_FAILURE);
+ }
+
+ if (!opt_nograb) {
+ rc = ioctl(vi.evdevfd, EVIOCGRAB, 1);
+ if (rc < 0) {
+ g_printerr("Failed to grab device\n");
+ exit(EXIT_FAILURE);
+ }
+ }
+
+ vi.config = g_array_new(false, false, sizeof(virtio_input_config));
+ memset(&id, 0, sizeof(id));
+ ioctl(vi.evdevfd, EVIOCGNAME(sizeof(id.u.string) - 1), id.u.string);
+ id.select = VIRTIO_INPUT_CFG_ID_NAME;
+ id.size = strlen(id.u.string);
+ g_array_append_val(vi.config, id);
+
+ if (ioctl(vi.evdevfd, EVIOCGID, &ids) == 0) {
+ memset(&id, 0, sizeof(id));
+ id.select = VIRTIO_INPUT_CFG_ID_DEVIDS;
+ id.size = sizeof(struct virtio_input_devids);
+ id.u.ids.bustype = cpu_to_le16(ids.bustype);
+ id.u.ids.vendor = cpu_to_le16(ids.vendor);
+ id.u.ids.product = cpu_to_le16(ids.product);
+ id.u.ids.version = cpu_to_le16(ids.version);
+ g_array_append_val(vi.config, id);
+ }
+
+ vi_bits_config(&vi, EV_KEY, KEY_CNT);
+ vi_bits_config(&vi, EV_REL, REL_CNT);
+ vi_bits_config(&vi, EV_ABS, ABS_CNT);
+ vi_bits_config(&vi, EV_MSC, MSC_CNT);
+ vi_bits_config(&vi, EV_SW, SW_CNT);
+ g_debug("config length: %u", vi.config->len);
+
+ if (opt_socket_path) {
+ int lsock = unix_sock_new(opt_socket_path);
+ fd = accept(lsock, NULL, NULL);
+ close(lsock);
+ } else {
+ fd = opt_fdnum;
+ }
+ if (fd == -1) {
+ g_printerr("Invalid socket");
+ exit(EXIT_FAILURE);
+ }
+ vug_init(&vi.dev, fd, vi_panic, &vuiface);
+
+ loop = g_main_loop_new(NULL, FALSE);
+ g_main_loop_run(loop);
+ g_main_loop_unref(loop);
+
+ vug_deinit(&vi.dev);
+
+ if (vi.evsrc) {
+ g_source_unref(vi.evsrc);
+ }
+ g_array_free(vi.config, TRUE);
+ g_free(vi.queue);
+ return 0;
+}
diff --git a/MAINTAINERS b/MAINTAINERS
index 4fcdd399db..0536428b0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1383,6 +1383,7 @@ S: Maintained
F: hw/input/vhost-user-input.c
F: hw/input/virtio-input*.c
F: include/hw/virtio/virtio-input.h
+F: contrib/vhost-user-input/*
virtio-serial
M: Amit Shah <amit@kernel.org>
diff --git a/Makefile b/Makefile
index f2947186a4..f047b5ccaf 100644
--- a/Makefile
+++ b/Makefile
@@ -421,6 +421,7 @@ dummy := $(call unnest-vars,, \
libvhost-user-obj-y \
vhost-user-scsi-obj-y \
vhost-user-blk-obj-y \
+ vhost-user-input-obj-y \
qga-vss-dll-obj-y \
block-obj-y \
block-obj-m \
@@ -725,6 +726,8 @@ vhost-user-scsi$(EXESUF): $(vhost-user-scsi-obj-y) libvhost-user.a
$(call LINK, $^)
vhost-user-blk$(EXESUF): $(vhost-user-blk-obj-y) libvhost-user.a
$(call LINK, $^)
+vhost-user-input$(EXESUF): $(vhost-user-input-obj-y) libvhost-user.a libqemuutil.a
+ $(call LINK, $^)
module_block.h: $(SRC_PATH)/scripts/modules/module_block.py config-host.mak
$(call quiet-command,$(PYTHON) $< $@ \
diff --git a/Makefile.objs b/Makefile.objs
index 1e1ff387d7..eca7c0a7c4 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -194,6 +194,7 @@ vhost-user-scsi.o-cflags := $(LIBISCSI_CFLAGS)
vhost-user-scsi.o-libs := $(LIBISCSI_LIBS)
vhost-user-scsi-obj-y = contrib/vhost-user-scsi/
vhost-user-blk-obj-y = contrib/vhost-user-blk/
+vhost-user-input-obj-y = contrib/vhost-user-input/
######################################################################
trace-events-subdirs =
diff --git a/configure b/configure
index 0a3c6a72c3..b64ca58fbe 100755
--- a/configure
+++ b/configure
@@ -5725,6 +5725,9 @@ if test "$want_tools" = "yes" ; then
if [ "$posix" = "yes" ] && [ "$curl" = "yes" ]; then
tools="elf2dmp $tools"
fi
+ if [ "$vhost_user" = "yes" ] && [ "$linux" = "yes" ] ; then
+ tools="vhost-user-input\$(EXESUF) $tools"
+ fi
fi
if test "$softmmu" = yes ; then
if test "$linux" = yes; then
diff --git a/contrib/vhost-user-input/Makefile.objs b/contrib/vhost-user-input/Makefile.objs
new file mode 100644
index 0000000000..b1fad90d51
--- /dev/null
+++ b/contrib/vhost-user-input/Makefile.objs
@@ -0,0 +1 @@
+vhost-user-input-obj-y = main.o
--
2.20.0.rc1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends Marc-André Lureau
@ 2018-11-26 20:57 ` Eric Blake
2018-12-10 14:29 ` Gerd Hoffmann
1 sibling, 0 replies; 30+ messages in thread
From: Eric Blake @ 2018-11-26 20:57 UTC (permalink / raw)
To: Marc-André Lureau, qemu-devel; +Cc: kraxel, Michael S. Tsirkin
On 11/26/18 6:42 AM, Marc-André Lureau wrote:
> As discussed during "[PATCH v4 00/29] vhost-user for input & GPU"
> review, let's define a common set of backend conventions to help with
> management layer implementation, and interoperability.
>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
> MAINTAINERS | 1 +
> docs/interop/vhost-user.json | 219 +++++++++++++++++++++++++++++++++++
> docs/interop/vhost-user.txt | 101 +++++++++++++++-
> 3 files changed, 319 insertions(+), 2 deletions(-)
> create mode 100644 docs/interop/vhost-user.json
> +++ b/docs/interop/vhost-user.json
> +# @VHostUserBackendType:
> +#
> +# List the various vhost user backend types.
> +#
> +# @net: virtio net
> +# @block: virtio block
> +# @console: virtio console
> +# @rng: virtio rng
> +# @balloon: virtio balloon
> +# @rpmsg: virtio remote processor messaging
> +# @scsi: virtio scsi
> +# @9p: 9p virtio console
> +# @rproc-serial: virtio remoteproc serial link
> +# @caif: virtio caif
> +# @gpu: virtio gpu
> +# @input: virtio input
> +# @vsock: virtio vsock transport
> +# @crypto: virtio crypto
> +#
> +# Since: 3.2
The next release will be 4.0, not 3.2. (We'll probably have to do a
global search-and-replace in January, as you're not the only one
proposing a patch with this version number).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 07/11] vhost-user: add vhost_user_input_get_config()
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 07/11] vhost-user: add vhost_user_input_get_config() Marc-André Lureau
@ 2018-12-10 14:26 ` Gerd Hoffmann
0 siblings, 0 replies; 30+ messages in thread
From: Gerd Hoffmann @ 2018-12-10 14:26 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: qemu-devel, Michael S. Tsirkin
On Mon, Nov 26, 2018 at 04:42:46PM +0400, Marc-André Lureau wrote:
> Ask vhost user input backend the list of virtio_input_config.
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> contrib/libvhost-user/libvhost-user.h | 1 +
> include/hw/virtio/vhost-backend.h | 4 ++
> hw/virtio/vhost-user.c | 60 +++++++++++++++++++++++++++
> docs/interop/vhost-user.txt | 8 ++++
> 4 files changed, 73 insertions(+)
>
> diff --git a/contrib/libvhost-user/libvhost-user.h b/contrib/libvhost-user/libvhost-user.h
> index 4aa55b4d2d..a4afbc3a46 100644
> --- a/contrib/libvhost-user/libvhost-user.h
> +++ b/contrib/libvhost-user/libvhost-user.h
> @@ -91,6 +91,7 @@ typedef enum VhostUserRequest {
> VHOST_USER_POSTCOPY_ADVISE = 28,
> VHOST_USER_POSTCOPY_LISTEN = 29,
> VHOST_USER_POSTCOPY_END = 30,
> + VHOST_USER_INPUT_GET_CONFIG = 31,
> VHOST_USER_MAX
> } VhostUserRequest;
>
> diff --git a/include/hw/virtio/vhost-backend.h b/include/hw/virtio/vhost-backend.h
> index 81283ec50f..1fca321d8a 100644
> --- a/include/hw/virtio/vhost-backend.h
> +++ b/include/hw/virtio/vhost-backend.h
> @@ -12,6 +12,7 @@
> #define VHOST_BACKEND_H
>
> #include "exec/memory.h"
> +#include "standard-headers/linux/virtio_input.h"
>
> typedef enum VhostBackendType {
> VHOST_BACKEND_TYPE_NONE = 0,
> @@ -160,4 +161,7 @@ int vhost_backend_invalidate_device_iotlb(struct vhost_dev *dev,
> int vhost_backend_handle_iotlb_msg(struct vhost_dev *dev,
> struct vhost_iotlb_msg *imsg);
>
> +int vhost_user_input_get_config(struct vhost_dev *dev,
> + struct virtio_input_config **config);
> +
> #endif /* VHOST_BACKEND_H */
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index 9256364e30..d51d1087f6 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -89,6 +89,7 @@ typedef enum VhostUserRequest {
> VHOST_USER_POSTCOPY_ADVISE = 28,
> VHOST_USER_POSTCOPY_LISTEN = 29,
> VHOST_USER_POSTCOPY_END = 30,
> + VHOST_USER_INPUT_GET_CONFIG = 31,
> VHOST_USER_MAX
> } VhostUserRequest;
>
> @@ -338,6 +339,65 @@ static int vhost_user_write(struct vhost_dev *dev, VhostUserMsg *msg,
> return 0;
> }
>
> +static void *vhost_user_read_size(struct vhost_dev *dev, uint32_t size)
> +{
> + struct vhost_user *u = dev->opaque;
> + CharBackend *chr = u->user->chr;
> + int r;
> + uint8_t *p = g_malloc(size);
> +
> + r = qemu_chr_fe_read_all(chr, p, size);
> + if (r != size) {
> + error_report("Failed to read msg payload."
> + " Read %d instead of %u.", r, size);
> + g_free(p);
> + return NULL;
> + }
> +
> + return p;
> +}
> +
> +int vhost_user_input_get_config(struct vhost_dev *dev,
> + struct virtio_input_config **config)
> +{
> + void *p = NULL;
> + VhostUserMsg msg = {
> + .hdr.request = VHOST_USER_INPUT_GET_CONFIG,
> + .hdr.flags = VHOST_USER_VERSION,
> + };
> +
> + if (vhost_user_write(dev, &msg, NULL, 0) < 0) {
> + goto err;
> + }
> +
> + if (vhost_user_read_header(dev, &msg) < 0) {
> + goto err;
> + }
> +
> + if (msg.hdr.request != VHOST_USER_INPUT_GET_CONFIG) {
> + error_report("Received unexpected msg type. Expected %d received %d",
> + VHOST_USER_INPUT_GET_CONFIG, msg.hdr.request);
> + goto err;
> + }
> +
> + if (msg.hdr.size % sizeof(struct virtio_input_config)) {
> + error_report("Invalid msg size");
> + goto err;
> + }
> +
> + p = vhost_user_read_size(dev, msg.hdr.size);
> + if (!p) {
> + goto err;
> + }
> +
> + *config = p;
> + return msg.hdr.size / sizeof(struct virtio_input_config);
> +
> +err:
> + g_free(p);
> + return -1;
> +}
> +
> static int vhost_user_set_log_base(struct vhost_dev *dev, uint64_t base,
> struct vhost_log *log)
> {
> diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
> index cefec9ffe1..95720be81b 100644
> --- a/docs/interop/vhost-user.txt
> +++ b/docs/interop/vhost-user.txt
> @@ -766,6 +766,14 @@ Master message types
> was previously sent.
> The value returned is an error indication; 0 is success.
>
> + * VHOST_USER_INPUT_GET_CONFIG
> + Id: 31
> + Master payload: N/A
> + Slave payload: (struct virtio_input_config)*
> +
> + Ask vhost user input backend the list of virtio_input_config, in
> + host endianness.
> +
> Slave message types
> -------------------
>
> --
> 2.20.0.rc1
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 10/11] Add vhost-user-input-pci
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 10/11] Add vhost-user-input-pci Marc-André Lureau
@ 2018-12-10 14:26 ` Gerd Hoffmann
0 siblings, 0 replies; 30+ messages in thread
From: Gerd Hoffmann @ 2018-12-10 14:26 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: qemu-devel, Michael S. Tsirkin
On Mon, Nov 26, 2018 at 04:42:49PM +0400, Marc-André Lureau wrote:
> Add a new virtio-input device, which connects to a vhost-user
> backend. Usage:
>
> -object vhost-user-backend,id=vuid,chardev=... \
> -device vhost-user-input-pci,vhost-user=vuid
>
> vhost-user-input is similar to virtio-input-host, it is wrapped by
> vhost-user-input-pci. Instead of reading configuration directly from
> an input device / evdev, it reads it over vhost-user protocol with
> INPUT_GET_CONFIG message. Then vhost-user-backend takes care of
> interfacing the virtio device with the backend, for the queue & events
> processing.
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> hw/virtio/virtio-pci.h | 10 +++
> include/hw/virtio/virtio-input.h | 14 ++++
> hw/input/vhost-user-input.c | 110 +++++++++++++++++++++++++++++++
> hw/virtio/virtio-pci.c | 22 +++++++
> MAINTAINERS | 1 +
> hw/input/Makefile.objs | 1 +
> 6 files changed, 158 insertions(+)
> create mode 100644 hw/input/vhost-user-input.c
>
> diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> index 813082b0d7..c7e28e1b9c 100644
> --- a/hw/virtio/virtio-pci.h
> +++ b/hw/virtio/virtio-pci.h
> @@ -54,6 +54,7 @@ typedef struct VirtIORngPCI VirtIORngPCI;
> typedef struct VirtIOInputPCI VirtIOInputPCI;
> typedef struct VirtIOInputHIDPCI VirtIOInputHIDPCI;
> typedef struct VirtIOInputHostPCI VirtIOInputHostPCI;
> +typedef struct VHostUserInputPCI VHostUserInputPCI;
> typedef struct VirtIOGPUPCI VirtIOGPUPCI;
> typedef struct VHostVSockPCI VHostVSockPCI;
> typedef struct VirtIOCryptoPCI VirtIOCryptoPCI;
> @@ -376,6 +377,15 @@ struct VirtIOInputHostPCI {
>
> #endif
>
> +#define TYPE_VHOST_USER_INPUT_PCI "vhost-user-input-pci"
> +#define VHOST_USER_INPUT_PCI(obj) \
> + OBJECT_CHECK(VHostUserInputPCI, (obj), TYPE_VHOST_USER_INPUT_PCI)
> +
> +struct VHostUserInputPCI {
> + VirtIOPCIProxy parent_obj;
> + VHostUserInput vhi;
> +};
> +
> /*
> * virtio-gpu-pci: This extends VirtioPCIProxy.
> */
> diff --git a/include/hw/virtio/virtio-input.h b/include/hw/virtio/virtio-input.h
> index 054c38836f..4fca03e796 100644
> --- a/include/hw/virtio/virtio-input.h
> +++ b/include/hw/virtio/virtio-input.h
> @@ -2,6 +2,7 @@
> #define QEMU_VIRTIO_INPUT_H
>
> #include "ui/input.h"
> +#include "sysemu/vhost-user-backend.h"
>
> /* ----------------------------------------------------------------- */
> /* virtio input protocol */
> @@ -42,11 +43,18 @@ typedef struct virtio_input_event virtio_input_event;
> #define VIRTIO_INPUT_HOST_GET_PARENT_CLASS(obj) \
> OBJECT_GET_PARENT_CLASS(obj, TYPE_VIRTIO_INPUT_HOST)
>
> +#define TYPE_VHOST_USER_INPUT "vhost-user-input"
> +#define VHOST_USER_INPUT(obj) \
> + OBJECT_CHECK(VHostUserInput, (obj), TYPE_VHOST_USER_INPUT)
> +#define VHOST_USER_INPUT_GET_PARENT_CLASS(obj) \
> + OBJECT_GET_PARENT_CLASS(obj, TYPE_VHOST_USER_INPUT)
> +
> typedef struct VirtIOInput VirtIOInput;
> typedef struct VirtIOInputClass VirtIOInputClass;
> typedef struct VirtIOInputConfig VirtIOInputConfig;
> typedef struct VirtIOInputHID VirtIOInputHID;
> typedef struct VirtIOInputHost VirtIOInputHost;
> +typedef struct VHostUserInput VHostUserInput;
>
> struct VirtIOInputConfig {
> virtio_input_config config;
> @@ -98,6 +106,12 @@ struct VirtIOInputHost {
> int fd;
> };
>
> +struct VHostUserInput {
> + VirtIOInput parent_obj;
> +
> + VhostUserBackend *vhost;
> +};
> +
> void virtio_input_send(VirtIOInput *vinput, virtio_input_event *event);
> void virtio_input_init_config(VirtIOInput *vinput,
> virtio_input_config *config);
> diff --git a/hw/input/vhost-user-input.c b/hw/input/vhost-user-input.c
> new file mode 100644
> index 0000000000..ef1b23a8b2
> --- /dev/null
> +++ b/hw/input/vhost-user-input.c
> @@ -0,0 +1,110 @@
> +/*
> + * This work is licensed under the terms of the GNU GPL, version 2 or
> + * (at your option) any later version. See the COPYING file in the
> + * top-level directory.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "qemu-common.h"
> +
> +#include "hw/qdev.h"
> +#include "hw/virtio/virtio-input.h"
> +
> +static void vhost_input_realize(DeviceState *dev, Error **errp)
> +{
> + VHostUserInput *vhi = VHOST_USER_INPUT(dev);
> + VirtIOInput *vinput = VIRTIO_INPUT(dev);
> + VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> + virtio_input_config *config;
> + int i, ret;
> +
> + if (!vhi->vhost) {
> + error_setg(errp, "'vhost-user' property is required");
> + return;
> + }
> +
> + if (vhost_user_backend_dev_init(vhi->vhost, vdev, 2, errp) == -1) {
> + return;
> + }
> +
> + ret = vhost_user_input_get_config(&vhi->vhost->dev, &config);
> + if (ret < 0) {
> + error_setg(errp, "failed to get input config");
> + return;
> + }
> + for (i = 0; i < ret; i++) {
> + virtio_input_add_config(vinput, &config[i]);
> + }
> + g_free(config);
> +}
> +
> +static void vhost_input_change_active(VirtIOInput *vinput)
> +{
> + VHostUserInput *vhi = VHOST_USER_INPUT(vinput);
> +
> + if (vinput->active) {
> + vhost_user_backend_start(vhi->vhost);
> + } else {
> + vhost_user_backend_stop(vhi->vhost);
> + }
> +}
> +
> +static const VMStateDescription vmstate_vhost_input = {
> + .name = "vhost-user-input",
> + .unmigratable = 1,
> +};
> +
> +static void vhost_input_class_init(ObjectClass *klass, void *data)
> +{
> + VirtIOInputClass *vic = VIRTIO_INPUT_CLASS(klass);
> + DeviceClass *dc = DEVICE_CLASS(klass);
> +
> + dc->vmsd = &vmstate_vhost_input;
> + vic->realize = vhost_input_realize;
> + vic->change_active = vhost_input_change_active;
> +}
> +
> +static void vhost_input_is_busy(const Object *obj, const char *name,
> + Object *val, Error **errp)
> +{
> + VHostUserInput *vhi = VHOST_USER_INPUT(obj);
> +
> + if (vhi->vhost) {
> + error_setg(errp, "can't use already busy vhost-user");
> + } else {
> + qdev_prop_allow_set_link_before_realize(obj, name, val, errp);
> + }
> +}
> +
> +static void vhost_input_init(Object *obj)
> +{
> + VHostUserInput *vhi = VHOST_USER_INPUT(obj);
> + VirtIOInput *vinput = VIRTIO_INPUT(obj);
> + struct virtio_input_config vhost_input_config[] = { { /* empty list */ } };
> +
> + virtio_input_init_config(vinput, vhost_input_config);
> +
> + object_property_add_link(obj, "vhost-user", TYPE_VHOST_USER_BACKEND,
> + (Object **)&vhi->vhost,
> + vhost_input_is_busy,
> + OBJ_PROP_LINK_STRONG,
> + &error_abort);
> +}
> +
> +static const TypeInfo vhost_input_info = {
> + .name = TYPE_VHOST_USER_INPUT,
> + .parent = TYPE_VIRTIO_INPUT,
> + .instance_size = sizeof(VHostUserInput),
> + .instance_init = vhost_input_init,
> + .class_init = vhost_input_class_init,
> +};
> +
> +/* ----------------------------------------------------------------- */
> +
> +static void vhost_input_register_types(void)
> +{
> + type_register_static(&vhost_input_info);
> +}
> +
> +type_init(vhost_input_register_types)
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index a954799267..ec912db48d 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -2645,6 +2645,27 @@ static const TypeInfo virtio_host_pci_info = {
> };
> #endif
>
> +#ifdef CONFIG_VHOST_USER
> +static void vhost_user_input_pci_initfn(Object *obj)
> +{
> + VHostUserInputPCI *dev = VHOST_USER_INPUT_PCI(obj);
> +
> + virtio_instance_init_common(obj, &dev->vhi, sizeof(dev->vhi),
> + TYPE_VHOST_USER_INPUT);
> +
> + object_property_add_alias(obj, "vhost-user",
> + OBJECT(&dev->vhi), "vhost-user",
> + &error_abort);
> +}
> +
> +static const TypeInfo vhost_user_input_pci_info = {
> + .name = TYPE_VHOST_USER_INPUT_PCI,
> + .parent = TYPE_VIRTIO_INPUT_PCI,
> + .instance_size = sizeof(VHostUserInputPCI),
> + .instance_init = vhost_user_input_pci_initfn,
> +};
> +#endif
> +
> /* virtio-pci-bus */
>
> static void virtio_pci_bus_new(VirtioBusState *bus, size_t bus_size,
> @@ -2719,6 +2740,7 @@ static void virtio_pci_register_types(void)
> #endif
> #if defined(CONFIG_VHOST_USER) && defined(CONFIG_LINUX)
> type_register_static(&vhost_user_scsi_pci_info);
> + type_register_static(&vhost_user_input_pci_info);
> #endif
> #ifdef CONFIG_VHOST_VSOCK
> type_register_static(&vhost_vsock_pci_info);
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1507f941dc..4fcdd399db 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1380,6 +1380,7 @@ L: qemu-s390x@nongnu.org
> virtio-input
> M: Gerd Hoffmann <kraxel@redhat.com>
> S: Maintained
> +F: hw/input/vhost-user-input.c
> F: hw/input/virtio-input*.c
> F: include/hw/virtio/virtio-input.h
>
> diff --git a/hw/input/Makefile.objs b/hw/input/Makefile.objs
> index c8b00f71ec..6adc308cdd 100644
> --- a/hw/input/Makefile.objs
> +++ b/hw/input/Makefile.objs
> @@ -11,6 +11,7 @@ common-obj-$(CONFIG_VIRTIO_INPUT) += virtio-input.o
> common-obj-$(CONFIG_VIRTIO_INPUT) += virtio-input-hid.o
> ifeq ($(CONFIG_LINUX),y)
> common-obj-$(CONFIG_VIRTIO_INPUT) += virtio-input-host.o
> +common-obj-$(call land,$(CONFIG_VHOST_USER),$(CONFIG_VIRTIO_INPUT)) += vhost-user-input.o
> endif
>
> obj-$(CONFIG_MILKYMIST) += milkymist-softusb.o
> --
> 2.20.0.rc1
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends Marc-André Lureau
2018-11-26 20:57 ` Eric Blake
@ 2018-12-10 14:29 ` Gerd Hoffmann
2018-12-10 18:36 ` Marc-André Lureau
1 sibling, 1 reply; 30+ messages in thread
From: Gerd Hoffmann @ 2018-12-10 14:29 UTC (permalink / raw)
To: Marc-André Lureau
Cc: qemu-devel, Daniel P . Berrangé, Michael S. Tsirkin
On Mon, Nov 26, 2018 at 04:42:40PM +0400, Marc-André Lureau wrote:
> As discussed during "[PATCH v4 00/29] vhost-user for input & GPU"
> review, let's define a common set of backend conventions to help with
> management layer implementation, and interoperability.
>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
btw: have you seen the idea to use a vfio-style interface for
communication between qemu and external device emulation processes?
cheers,
Gerd
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-10 14:29 ` Gerd Hoffmann
@ 2018-12-10 18:36 ` Marc-André Lureau
2018-12-10 23:37 ` Michael S. Tsirkin
0 siblings, 1 reply; 30+ messages in thread
From: Marc-André Lureau @ 2018-12-10 18:36 UTC (permalink / raw)
To: Hoffmann, Gerd; +Cc: qemu-devel, P. Berrange, Daniel, Michael S . Tsirkin
Hi
On Mon, Dec 10, 2018 at 6:30 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Mon, Nov 26, 2018 at 04:42:40PM +0400, Marc-André Lureau wrote:
> > As discussed during "[PATCH v4 00/29] vhost-user for input & GPU"
> > review, let's define a common set of backend conventions to help with
> > management layer implementation, and interoperability.
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>
> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
>
> btw: have you seen the idea to use a vfio-style interface for
> communication between qemu and external device emulation processes?
I heard there was some discussion during KVM forum.
Fwiwi, this is also an idea I proposed last year (and quickly
discussed during my talk about multi-process qemu).
I also experimented with the idea, and wrote a vfio-user backend, with
a PCI serial device running in a seperate process:
the qemu tree: https://github.com/elmarco/qemu/tree/wip/vfio-user (dirty tree)
and the serial device:
https://github.com/elmarco/qemu/blob/wip/vfio-user/contrib/libvfio-user/vfio-user-serial.c
>
> cheers,
> Gerd
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-10 18:36 ` Marc-André Lureau
@ 2018-12-10 23:37 ` Michael S. Tsirkin
2018-12-11 7:42 ` Hoffmann, Gerd
0 siblings, 1 reply; 30+ messages in thread
From: Michael S. Tsirkin @ 2018-12-10 23:37 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: Hoffmann, Gerd, qemu-devel, P. Berrange, Daniel
On Mon, Dec 10, 2018 at 10:36:29PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Mon, Dec 10, 2018 at 6:30 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > On Mon, Nov 26, 2018 at 04:42:40PM +0400, Marc-André Lureau wrote:
> > > As discussed during "[PATCH v4 00/29] vhost-user for input & GPU"
> > > review, let's define a common set of backend conventions to help with
> > > management layer implementation, and interoperability.
> > >
> > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> >
> > Acked-by: Gerd Hoffmann <kraxel@redhat.com>
> >
> > btw: have you seen the idea to use a vfio-style interface for
> > communication between qemu and external device emulation processes?
>
> I heard there was some discussion during KVM forum.
>
> Fwiwi, this is also an idea I proposed last year (and quickly
> discussed during my talk about multi-process qemu).
> I also experimented with the idea, and wrote a vfio-user backend, with
> a PCI serial device running in a seperate process:
> the qemu tree: https://github.com/elmarco/qemu/tree/wip/vfio-user (dirty tree)
> and the serial device:
> https://github.com/elmarco/qemu/blob/wip/vfio-user/contrib/libvfio-user/vfio-user-serial.c
Right. The main issue is that we need to make sure only
in-tree devices are supported. vhost-user by design
is for out of tree users. It needn't be hard,
maybe it's enough to just make qemu launch these processes
as opposed to connecting to them on command line.
>
>
> >
> > cheers,
> > Gerd
> >
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-10 23:37 ` Michael S. Tsirkin
@ 2018-12-11 7:42 ` Hoffmann, Gerd
2018-12-11 9:29 ` Daniel P. Berrangé
0 siblings, 1 reply; 30+ messages in thread
From: Hoffmann, Gerd @ 2018-12-11 7:42 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Marc-André Lureau, qemu-devel, P. Berrange, Daniel
Hi,
> Right. The main issue is that we need to make sure only
> in-tree devices are supported.
Well, that is under debate right now, see:
https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html
> vhost-user by design
> is for out of tree users. It needn't be hard,
> maybe it's enough to just make qemu launch these processes
> as opposed to connecting to them on command line.
Not sure this is a good idea, with security being one of the motivating
factors to move device emulation to other processes. When libvirt
launches the processes it can place them in separate sandboxes ...
cheers,
Gerd
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-11 7:42 ` Hoffmann, Gerd
@ 2018-12-11 9:29 ` Daniel P. Berrangé
2018-12-11 18:56 ` Michael S. Tsirkin
0 siblings, 1 reply; 30+ messages in thread
From: Daniel P. Berrangé @ 2018-12-11 9:29 UTC (permalink / raw)
To: Hoffmann, Gerd; +Cc: Michael S. Tsirkin, Marc-André Lureau, qemu-devel
On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote:
> Hi,
>
> > Right. The main issue is that we need to make sure only
> > in-tree devices are supported.
>
> Well, that is under debate right now, see:
> https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html
I've previously been against the idea of external plugins for QEMU,
however, that was when the plugin was something that would be dlopen'd
by QEMU. That would cause our internal ABI to be exposed to 3rd parties
which is highly undesirable, even if they were open source to comply
with the license needs.
When the plugin is a completely isolated process communicating with a
well defined protocol, it is not placing a significant burden on the
QEMU developers' ongoing maintainence, nor has problems with license
compliance. The main problem would come from debugging the combined
system as the external process is essentially a black box from QEMU's
POV. Downstream OS vendors are free to place restrictions on which
backend processes they'd be willing to support with QEMU, and upstream
is under no obligation to debug stuff beyond the QEMU boundary.
We have already accepted that tradeoff with networking by supporting
vhost-user and have externals impls like DPDK, so I don't see a
compelling reason to try to restrict it for other vhost-user backends.
> > vhost-user by design
> > is for out of tree users. It needn't be hard,
> > maybe it's enough to just make qemu launch these processes
> > as opposed to connecting to them on command line.
>
> Not sure this is a good idea, with security being one of the motivating
> factors to move device emulation to other processes. When libvirt
> launches the processes it can place them in separate sandboxes ...
Yep, libvirt already turns on seccomp policies which forbid QEMU from
forking/execing anything, and we have no desire to go backwards here.
Any external processes have to be launched by libvirt ahead of time.
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 :|
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-11 9:29 ` Daniel P. Berrangé
@ 2018-12-11 18:56 ` Michael S. Tsirkin
2018-12-18 18:35 ` Marc-André Lureau
0 siblings, 1 reply; 30+ messages in thread
From: Michael S. Tsirkin @ 2018-12-11 18:56 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Hoffmann, Gerd, Marc-André Lureau, qemu-devel
On Tue, Dec 11, 2018 at 09:29:44AM +0000, Daniel P. Berrangé wrote:
> On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote:
> > Hi,
> >
> > > Right. The main issue is that we need to make sure only
> > > in-tree devices are supported.
> >
> > Well, that is under debate right now, see:
> > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html
>
> I've previously been against the idea of external plugins for QEMU,
> however, that was when the plugin was something that would be dlopen'd
> by QEMU. That would cause our internal ABI to be exposed to 3rd parties
> which is highly undesirable, even if they were open source to comply
> with the license needs.
>
> When the plugin is a completely isolated process communicating with a
> well defined protocol, it is not placing a significant burden on the
> QEMU developers' ongoing maintainence, nor has problems with license
> compliance. The main problem would come from debugging the combined
> system as the external process is essentially a black box from QEMU's
> POV. Downstream OS vendors are free to place restrictions on which
> backend processes they'd be willing to support with QEMU, and upstream
> is under no obligation to debug stuff beyond the QEMU boundary.
>
> We have already accepted that tradeoff with networking by supporting
> vhost-user and have externals impls like DPDK, so I don't see a
> compelling reason to try to restrict it for other vhost-user backends.
OK seems to be more or less a rough concensus then.
I wonder what's the approach wrt migration though.
Even the compatibility story about vhost-user isn't
great, I would like to see something solid before
we allow that.
Are we happy to just block live migration?
For sure that's already the case with VFIO.
> > > vhost-user by design
> > > is for out of tree users. It needn't be hard,
> > > maybe it's enough to just make qemu launch these processes
> > > as opposed to connecting to them on command line.
> >
> > Not sure this is a good idea, with security being one of the motivating
> > factors to move device emulation to other processes. When libvirt
> > launches the processes it can place them in separate sandboxes ...
>
> Yep, libvirt already turns on seccomp policies which forbid QEMU from
> forking/execing anything, and we have no desire to go backwards here.
> Any external processes have to be launched by libvirt ahead of time.
>
>
> 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 :|
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-11 18:56 ` Michael S. Tsirkin
@ 2018-12-18 18:35 ` Marc-André Lureau
2018-12-18 23:20 ` Michael S. Tsirkin
0 siblings, 1 reply; 30+ messages in thread
From: Marc-André Lureau @ 2018-12-18 18:35 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Daniel P. Berrangé, Hoffmann, Gerd, qemu-devel
Hi
On Tue, Dec 11, 2018 at 10:56 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Dec 11, 2018 at 09:29:44AM +0000, Daniel P. Berrangé wrote:
> > On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote:
> > > Hi,
> > >
> > > > Right. The main issue is that we need to make sure only
> > > > in-tree devices are supported.
> > >
> > > Well, that is under debate right now, see:
> > > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html
> >
> > I've previously been against the idea of external plugins for QEMU,
> > however, that was when the plugin was something that would be dlopen'd
> > by QEMU. That would cause our internal ABI to be exposed to 3rd parties
> > which is highly undesirable, even if they were open source to comply
> > with the license needs.
> >
> > When the plugin is a completely isolated process communicating with a
> > well defined protocol, it is not placing a significant burden on the
> > QEMU developers' ongoing maintainence, nor has problems with license
> > compliance. The main problem would come from debugging the combined
> > system as the external process is essentially a black box from QEMU's
> > POV. Downstream OS vendors are free to place restrictions on which
> > backend processes they'd be willing to support with QEMU, and upstream
> > is under no obligation to debug stuff beyond the QEMU boundary.
> >
> > We have already accepted that tradeoff with networking by supporting
> > vhost-user and have externals impls like DPDK, so I don't see a
> > compelling reason to try to restrict it for other vhost-user backends.
>
> OK seems to be more or less a rough concensus then.
>
> I wonder what's the approach wrt migration though.
The series doesn't take care of migration.
>
> Even the compatibility story about vhost-user isn't
> great, I would like to see something solid before
> we allow that.
To allow migration? vhost-user has partial support for migration
(dirty memory tracking), and there is also "[PATCH v2 for-4.0 0/7]
vhost-user-blk: Add support for backend reconnecting" - allowing the
backend to store some state, if I understand correctly, which could be
leveraged I guess...
But I don't think we should block this series because migration isn't
tackled here.
thanks
.
>
> Are we happy to just block live migration?
> For sure that's already the case with VFIO.
>
>
> > > > vhost-user by design
> > > > is for out of tree users. It needn't be hard,
> > > > maybe it's enough to just make qemu launch these processes
> > > > as opposed to connecting to them on command line.
> > >
> > > Not sure this is a good idea, with security being one of the motivating
> > > factors to move device emulation to other processes. When libvirt
> > > launches the processes it can place them in separate sandboxes ...
> >
> > Yep, libvirt already turns on seccomp policies which forbid QEMU from
> > forking/execing anything, and we have no desire to go backwards here.
> > Any external processes have to be launched by libvirt ahead of time.
> >
> >
> > 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 :|
>
--
Marc-André Lureau
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-18 18:35 ` Marc-André Lureau
@ 2018-12-18 23:20 ` Michael S. Tsirkin
2018-12-19 8:01 ` Marc-André Lureau
0 siblings, 1 reply; 30+ messages in thread
From: Michael S. Tsirkin @ 2018-12-18 23:20 UTC (permalink / raw)
To: Marc-André Lureau
Cc: Daniel P. Berrangé, Hoffmann, Gerd, qemu-devel
On Tue, Dec 18, 2018 at 10:35:05PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Tue, Dec 11, 2018 at 10:56 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Tue, Dec 11, 2018 at 09:29:44AM +0000, Daniel P. Berrangé wrote:
> > > On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote:
> > > > Hi,
> > > >
> > > > > Right. The main issue is that we need to make sure only
> > > > > in-tree devices are supported.
> > > >
> > > > Well, that is under debate right now, see:
> > > > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html
> > >
> > > I've previously been against the idea of external plugins for QEMU,
> > > however, that was when the plugin was something that would be dlopen'd
> > > by QEMU. That would cause our internal ABI to be exposed to 3rd parties
> > > which is highly undesirable, even if they were open source to comply
> > > with the license needs.
> > >
> > > When the plugin is a completely isolated process communicating with a
> > > well defined protocol, it is not placing a significant burden on the
> > > QEMU developers' ongoing maintainence, nor has problems with license
> > > compliance. The main problem would come from debugging the combined
> > > system as the external process is essentially a black box from QEMU's
> > > POV. Downstream OS vendors are free to place restrictions on which
> > > backend processes they'd be willing to support with QEMU, and upstream
> > > is under no obligation to debug stuff beyond the QEMU boundary.
> > >
> > > We have already accepted that tradeoff with networking by supporting
> > > vhost-user and have externals impls like DPDK, so I don't see a
> > > compelling reason to try to restrict it for other vhost-user backends.
> >
> > OK seems to be more or less a rough concensus then.
> >
> > I wonder what's the approach wrt migration though.
>
> The series doesn't take care of migration.
>
> >
> > Even the compatibility story about vhost-user isn't
> > great, I would like to see something solid before
> > we allow that.
>
> To allow migration? vhost-user has partial support for migration
> (dirty memory tracking), and there is also "[PATCH v2 for-4.0 0/7]
> vhost-user-blk: Add support for backend reconnecting" - allowing the
> backend to store some state, if I understand correctly, which could be
> leveraged I guess...
>
> But I don't think we should block this series because migration isn't
> tackled here.
>
> thanks
>
>
> .
How about blocking migration for now then?
We need someone to work on a solution for cross version/device
compatibility, vhost net/blk without that is bad enough but at least we
have a feature bits, for random devices it would be very very bad.
> >
> > Are we happy to just block live migration?
> > For sure that's already the case with VFIO.
> >
> >
> > > > > vhost-user by design
> > > > > is for out of tree users. It needn't be hard,
> > > > > maybe it's enough to just make qemu launch these processes
> > > > > as opposed to connecting to them on command line.
> > > >
> > > > Not sure this is a good idea, with security being one of the motivating
> > > > factors to move device emulation to other processes. When libvirt
> > > > launches the processes it can place them in separate sandboxes ...
> > >
> > > Yep, libvirt already turns on seccomp policies which forbid QEMU from
> > > forking/execing anything, and we have no desire to go backwards here.
> > > Any external processes have to be launched by libvirt ahead of time.
> > >
> > >
> > > 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 :|
> >
>
>
> --
> Marc-André Lureau
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-18 23:20 ` Michael S. Tsirkin
@ 2018-12-19 8:01 ` Marc-André Lureau
2018-12-19 15:42 ` Michael S. Tsirkin
0 siblings, 1 reply; 30+ messages in thread
From: Marc-André Lureau @ 2018-12-19 8:01 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Daniel P. Berrangé, Hoffmann, Gerd, qemu-devel
Hi
On Wed, Dec 19, 2018 at 3:20 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Dec 18, 2018 at 10:35:05PM +0400, Marc-André Lureau wrote:
> > Hi
> >
> > On Tue, Dec 11, 2018 at 10:56 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Tue, Dec 11, 2018 at 09:29:44AM +0000, Daniel P. Berrangé wrote:
> > > > On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote:
> > > > > Hi,
> > > > >
> > > > > > Right. The main issue is that we need to make sure only
> > > > > > in-tree devices are supported.
> > > > >
> > > > > Well, that is under debate right now, see:
> > > > > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html
> > > >
> > > > I've previously been against the idea of external plugins for QEMU,
> > > > however, that was when the plugin was something that would be dlopen'd
> > > > by QEMU. That would cause our internal ABI to be exposed to 3rd parties
> > > > which is highly undesirable, even if they were open source to comply
> > > > with the license needs.
> > > >
> > > > When the plugin is a completely isolated process communicating with a
> > > > well defined protocol, it is not placing a significant burden on the
> > > > QEMU developers' ongoing maintainence, nor has problems with license
> > > > compliance. The main problem would come from debugging the combined
> > > > system as the external process is essentially a black box from QEMU's
> > > > POV. Downstream OS vendors are free to place restrictions on which
> > > > backend processes they'd be willing to support with QEMU, and upstream
> > > > is under no obligation to debug stuff beyond the QEMU boundary.
> > > >
> > > > We have already accepted that tradeoff with networking by supporting
> > > > vhost-user and have externals impls like DPDK, so I don't see a
> > > > compelling reason to try to restrict it for other vhost-user backends.
> > >
> > > OK seems to be more or less a rough concensus then.
> > >
> > > I wonder what's the approach wrt migration though.
> >
> > The series doesn't take care of migration.
> >
> > >
> > > Even the compatibility story about vhost-user isn't
> > > great, I would like to see something solid before
> > > we allow that.
> >
> > To allow migration? vhost-user has partial support for migration
> > (dirty memory tracking), and there is also "[PATCH v2 for-4.0 0/7]
> > vhost-user-blk: Add support for backend reconnecting" - allowing the
> > backend to store some state, if I understand correctly, which could be
> > leveraged I guess...
> >
> > But I don't think we should block this series because migration isn't
> > tackled here.
> >
> > thanks
> >
> >
> > .
>
> How about blocking migration for now then?
The device here (vhost-user-input) blocks migration (unmigratable = 1)
>
> We need someone to work on a solution for cross version/device
> compatibility, vhost net/blk without that is bad enough but at least we
> have a feature bits, for random devices it would be very very bad.
For now, if migration is somehow supported, it must be handled mostly
by the qemu device, and the vhost-user backend must track dirty memory
and be "stateless": *able to reconnect & resume where it left off).
A backend shouldn't declare VHOST_USER_PROTOCOL_F_LOG_SHMFD if it can't do that.
When a backend will have a state to migrate, we will have to implement
a new feature. I assume that's what you are asking.
>
>
> > >
> > > Are we happy to just block live migration?
> > > For sure that's already the case with VFIO.
> > >
> > >
> > > > > > vhost-user by design
> > > > > > is for out of tree users. It needn't be hard,
> > > > > > maybe it's enough to just make qemu launch these processes
> > > > > > as opposed to connecting to them on command line.
> > > > >
> > > > > Not sure this is a good idea, with security being one of the motivating
> > > > > factors to move device emulation to other processes. When libvirt
> > > > > launches the processes it can place them in separate sandboxes ...
> > > >
> > > > Yep, libvirt already turns on seccomp policies which forbid QEMU from
> > > > forking/execing anything, and we have no desire to go backwards here.
> > > > Any external processes have to be launched by libvirt ahead of time.
> > > >
> > > >
> > > > 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 :|
> > >
> >
> >
> > --
> > Marc-André Lureau
--
Marc-André Lureau
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-19 8:01 ` Marc-André Lureau
@ 2018-12-19 15:42 ` Michael S. Tsirkin
2018-12-20 12:40 ` Marc-André Lureau
0 siblings, 1 reply; 30+ messages in thread
From: Michael S. Tsirkin @ 2018-12-19 15:42 UTC (permalink / raw)
To: Marc-André Lureau
Cc: Daniel P. Berrangé, Hoffmann, Gerd, qemu-devel, maxime.coquelin
On Wed, Dec 19, 2018 at 12:01:59PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Wed, Dec 19, 2018 at 3:20 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Tue, Dec 18, 2018 at 10:35:05PM +0400, Marc-André Lureau wrote:
> > > Hi
> > >
> > > On Tue, Dec 11, 2018 at 10:56 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Tue, Dec 11, 2018 at 09:29:44AM +0000, Daniel P. Berrangé wrote:
> > > > > On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote:
> > > > > > Hi,
> > > > > >
> > > > > > > Right. The main issue is that we need to make sure only
> > > > > > > in-tree devices are supported.
> > > > > >
> > > > > > Well, that is under debate right now, see:
> > > > > > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html
> > > > >
> > > > > I've previously been against the idea of external plugins for QEMU,
> > > > > however, that was when the plugin was something that would be dlopen'd
> > > > > by QEMU. That would cause our internal ABI to be exposed to 3rd parties
> > > > > which is highly undesirable, even if they were open source to comply
> > > > > with the license needs.
> > > > >
> > > > > When the plugin is a completely isolated process communicating with a
> > > > > well defined protocol, it is not placing a significant burden on the
> > > > > QEMU developers' ongoing maintainence, nor has problems with license
> > > > > compliance. The main problem would come from debugging the combined
> > > > > system as the external process is essentially a black box from QEMU's
> > > > > POV. Downstream OS vendors are free to place restrictions on which
> > > > > backend processes they'd be willing to support with QEMU, and upstream
> > > > > is under no obligation to debug stuff beyond the QEMU boundary.
> > > > >
> > > > > We have already accepted that tradeoff with networking by supporting
> > > > > vhost-user and have externals impls like DPDK, so I don't see a
> > > > > compelling reason to try to restrict it for other vhost-user backends.
> > > >
> > > > OK seems to be more or less a rough concensus then.
> > > >
> > > > I wonder what's the approach wrt migration though.
> > >
> > > The series doesn't take care of migration.
> > >
> > > >
> > > > Even the compatibility story about vhost-user isn't
> > > > great, I would like to see something solid before
> > > > we allow that.
> > >
> > > To allow migration? vhost-user has partial support for migration
> > > (dirty memory tracking), and there is also "[PATCH v2 for-4.0 0/7]
> > > vhost-user-blk: Add support for backend reconnecting" - allowing the
> > > backend to store some state, if I understand correctly, which could be
> > > leveraged I guess...
> > >
> > > But I don't think we should block this series because migration isn't
> > > tackled here.
> > >
> > > thanks
> > >
> > >
> > > .
> >
> > How about blocking migration for now then?
>
> The device here (vhost-user-input) blocks migration (unmigratable = 1)
Right. But that device is just an excersize, right?
It bothers me that next device might not remember and
we will get a mess.
Could we make it somehow that if there is no vmsd
then migration is blocked?
> >
> > We need someone to work on a solution for cross version/device
> > compatibility, vhost net/blk without that is bad enough but at least we
> > have a feature bits, for random devices it would be very very bad.
>
> For now, if migration is somehow supported, it must be handled mostly
> by the qemu device, and the vhost-user backend must track dirty memory
> and be "stateless": *able to reconnect & resume where it left off).
>
> A backend shouldn't declare VHOST_USER_PROTOCOL_F_LOG_SHMFD if it can't do that.
>
> When a backend will have a state to migrate, we will have to implement
> a new feature. I assume that's what you are asking.
No, I am talking about a cross version/backend migration.
And it's such a boutique problem backends do not even
understand what it's about. A way to handle it
in the frontend is needed.
We also need a way to make sure incorrect backends do not
connect to incorrect devices, and we need a mechanism
that allows cross-version migration compatibility.
There's been a long discussion about cross-version
migration for vhost-user and I think Maxime had
a plan there. Maxime could you repost the
set of issues and what the plan is maybe?
> >
> >
> > > >
> > > > Are we happy to just block live migration?
> > > > For sure that's already the case with VFIO.
> > > >
> > > >
> > > > > > > vhost-user by design
> > > > > > > is for out of tree users. It needn't be hard,
> > > > > > > maybe it's enough to just make qemu launch these processes
> > > > > > > as opposed to connecting to them on command line.
> > > > > >
> > > > > > Not sure this is a good idea, with security being one of the motivating
> > > > > > factors to move device emulation to other processes. When libvirt
> > > > > > launches the processes it can place them in separate sandboxes ...
> > > > >
> > > > > Yep, libvirt already turns on seccomp policies which forbid QEMU from
> > > > > forking/execing anything, and we have no desire to go backwards here.
> > > > > Any external processes have to be launched by libvirt ahead of time.
> > > > >
> > > > >
> > > > > 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 :|
> > > >
> > >
> > >
> > > --
> > > Marc-André Lureau
>
>
>
> --
> Marc-André Lureau
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-19 15:42 ` Michael S. Tsirkin
@ 2018-12-20 12:40 ` Marc-André Lureau
2018-12-20 16:33 ` Michael S. Tsirkin
0 siblings, 1 reply; 30+ messages in thread
From: Marc-André Lureau @ 2018-12-20 12:40 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Daniel P. Berrangé, Hoffmann, Gerd, qemu-devel, Maxime Coquelin
Hi
On Wed, Dec 19, 2018 at 7:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Dec 19, 2018 at 12:01:59PM +0400, Marc-André Lureau wrote:
> > Hi
> >
> > On Wed, Dec 19, 2018 at 3:20 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Tue, Dec 18, 2018 at 10:35:05PM +0400, Marc-André Lureau wrote:
> > > > Hi
> > > >
> > > > On Tue, Dec 11, 2018 at 10:56 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > >
> > > > > On Tue, Dec 11, 2018 at 09:29:44AM +0000, Daniel P. Berrangé wrote:
> > > > > > On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > > Right. The main issue is that we need to make sure only
> > > > > > > > in-tree devices are supported.
> > > > > > >
> > > > > > > Well, that is under debate right now, see:
> > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html
> > > > > >
> > > > > > I've previously been against the idea of external plugins for QEMU,
> > > > > > however, that was when the plugin was something that would be dlopen'd
> > > > > > by QEMU. That would cause our internal ABI to be exposed to 3rd parties
> > > > > > which is highly undesirable, even if they were open source to comply
> > > > > > with the license needs.
> > > > > >
> > > > > > When the plugin is a completely isolated process communicating with a
> > > > > > well defined protocol, it is not placing a significant burden on the
> > > > > > QEMU developers' ongoing maintainence, nor has problems with license
> > > > > > compliance. The main problem would come from debugging the combined
> > > > > > system as the external process is essentially a black box from QEMU's
> > > > > > POV. Downstream OS vendors are free to place restrictions on which
> > > > > > backend processes they'd be willing to support with QEMU, and upstream
> > > > > > is under no obligation to debug stuff beyond the QEMU boundary.
> > > > > >
> > > > > > We have already accepted that tradeoff with networking by supporting
> > > > > > vhost-user and have externals impls like DPDK, so I don't see a
> > > > > > compelling reason to try to restrict it for other vhost-user backends.
> > > > >
> > > > > OK seems to be more or less a rough concensus then.
> > > > >
> > > > > I wonder what's the approach wrt migration though.
> > > >
> > > > The series doesn't take care of migration.
> > > >
> > > > >
> > > > > Even the compatibility story about vhost-user isn't
> > > > > great, I would like to see something solid before
> > > > > we allow that.
> > > >
> > > > To allow migration? vhost-user has partial support for migration
> > > > (dirty memory tracking), and there is also "[PATCH v2 for-4.0 0/7]
> > > > vhost-user-blk: Add support for backend reconnecting" - allowing the
> > > > backend to store some state, if I understand correctly, which could be
> > > > leveraged I guess...
> > > >
> > > > But I don't think we should block this series because migration isn't
> > > > tackled here.
> > > >
> > > > thanks
> > > >
> > > >
> > > > .
> > >
> > > How about blocking migration for now then?
> >
> > The device here (vhost-user-input) blocks migration (unmigratable = 1)
>
> Right. But that device is just an excersize, right?
Mostly
> It bothers me that next device might not remember and
> we will get a mess.
The next device (the one I care most about) is vhost-user-gpu.
> Could we make it somehow that if there is no vmsd
> then migration is blocked?
Where would you do that? in DeviceClass? That might break other
devices, needs code review. In VirtIODevice? that would be probably
simpler.
--
Marc-André Lureau
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-20 12:40 ` Marc-André Lureau
@ 2018-12-20 16:33 ` Michael S. Tsirkin
2019-01-08 13:23 ` Marc-André Lureau
0 siblings, 1 reply; 30+ messages in thread
From: Michael S. Tsirkin @ 2018-12-20 16:33 UTC (permalink / raw)
To: Marc-André Lureau
Cc: Daniel P. Berrangé, Hoffmann, Gerd, qemu-devel, Maxime Coquelin
On Thu, Dec 20, 2018 at 04:40:55PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Wed, Dec 19, 2018 at 7:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Wed, Dec 19, 2018 at 12:01:59PM +0400, Marc-André Lureau wrote:
> > > Hi
> > >
> > > On Wed, Dec 19, 2018 at 3:20 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Tue, Dec 18, 2018 at 10:35:05PM +0400, Marc-André Lureau wrote:
> > > > > Hi
> > > > >
> > > > > On Tue, Dec 11, 2018 at 10:56 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > >
> > > > > > On Tue, Dec 11, 2018 at 09:29:44AM +0000, Daniel P. Berrangé wrote:
> > > > > > > On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > > Right. The main issue is that we need to make sure only
> > > > > > > > > in-tree devices are supported.
> > > > > > > >
> > > > > > > > Well, that is under debate right now, see:
> > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html
> > > > > > >
> > > > > > > I've previously been against the idea of external plugins for QEMU,
> > > > > > > however, that was when the plugin was something that would be dlopen'd
> > > > > > > by QEMU. That would cause our internal ABI to be exposed to 3rd parties
> > > > > > > which is highly undesirable, even if they were open source to comply
> > > > > > > with the license needs.
> > > > > > >
> > > > > > > When the plugin is a completely isolated process communicating with a
> > > > > > > well defined protocol, it is not placing a significant burden on the
> > > > > > > QEMU developers' ongoing maintainence, nor has problems with license
> > > > > > > compliance. The main problem would come from debugging the combined
> > > > > > > system as the external process is essentially a black box from QEMU's
> > > > > > > POV. Downstream OS vendors are free to place restrictions on which
> > > > > > > backend processes they'd be willing to support with QEMU, and upstream
> > > > > > > is under no obligation to debug stuff beyond the QEMU boundary.
> > > > > > >
> > > > > > > We have already accepted that tradeoff with networking by supporting
> > > > > > > vhost-user and have externals impls like DPDK, so I don't see a
> > > > > > > compelling reason to try to restrict it for other vhost-user backends.
> > > > > >
> > > > > > OK seems to be more or less a rough concensus then.
> > > > > >
> > > > > > I wonder what's the approach wrt migration though.
> > > > >
> > > > > The series doesn't take care of migration.
> > > > >
> > > > > >
> > > > > > Even the compatibility story about vhost-user isn't
> > > > > > great, I would like to see something solid before
> > > > > > we allow that.
> > > > >
> > > > > To allow migration? vhost-user has partial support for migration
> > > > > (dirty memory tracking), and there is also "[PATCH v2 for-4.0 0/7]
> > > > > vhost-user-blk: Add support for backend reconnecting" - allowing the
> > > > > backend to store some state, if I understand correctly, which could be
> > > > > leveraged I guess...
> > > > >
> > > > > But I don't think we should block this series because migration isn't
> > > > > tackled here.
> > > > >
> > > > > thanks
> > > > >
> > > > >
> > > > > .
> > > >
> > > > How about blocking migration for now then?
> > >
> > > The device here (vhost-user-input) blocks migration (unmigratable = 1)
> >
> > Right. But that device is just an excersize, right?
>
> Mostly
>
> > It bothers me that next device might not remember and
> > we will get a mess.
>
> The next device (the one I care most about) is vhost-user-gpu.
>
> > Could we make it somehow that if there is no vmsd
> > then migration is blocked?
>
> Where would you do that? in DeviceClass? That might break other
> devices, needs code review. In VirtIODevice? that would be probably
> simpler.
In vhost user core somehow?
>
>
> --
> Marc-André Lureau
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2018-12-20 16:33 ` Michael S. Tsirkin
@ 2019-01-08 13:23 ` Marc-André Lureau
2019-01-09 8:45 ` Hoffmann, Gerd
0 siblings, 1 reply; 30+ messages in thread
From: Marc-André Lureau @ 2019-01-08 13:23 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Daniel P. Berrangé, Hoffmann, Gerd, qemu-devel, Maxime Coquelin
Hi
On Thu, Dec 20, 2018 at 8:34 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Thu, Dec 20, 2018 at 04:40:55PM +0400, Marc-André Lureau wrote:
> > Hi
> >
> > On Wed, Dec 19, 2018 at 7:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Wed, Dec 19, 2018 at 12:01:59PM +0400, Marc-André Lureau wrote:
> > > > Hi
> > > >
> > > > On Wed, Dec 19, 2018 at 3:20 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > >
> > > > > On Tue, Dec 18, 2018 at 10:35:05PM +0400, Marc-André Lureau wrote:
> > > > > > Hi
> > > > > >
> > > > > > On Tue, Dec 11, 2018 at 10:56 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > >
> > > > > > > On Tue, Dec 11, 2018 at 09:29:44AM +0000, Daniel P. Berrangé wrote:
> > > > > > > > On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > > Right. The main issue is that we need to make sure only
> > > > > > > > > > in-tree devices are supported.
> > > > > > > > >
> > > > > > > > > Well, that is under debate right now, see:
> > > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html
> > > > > > > >
> > > > > > > > I've previously been against the idea of external plugins for QEMU,
> > > > > > > > however, that was when the plugin was something that would be dlopen'd
> > > > > > > > by QEMU. That would cause our internal ABI to be exposed to 3rd parties
> > > > > > > > which is highly undesirable, even if they were open source to comply
> > > > > > > > with the license needs.
> > > > > > > >
> > > > > > > > When the plugin is a completely isolated process communicating with a
> > > > > > > > well defined protocol, it is not placing a significant burden on the
> > > > > > > > QEMU developers' ongoing maintainence, nor has problems with license
> > > > > > > > compliance. The main problem would come from debugging the combined
> > > > > > > > system as the external process is essentially a black box from QEMU's
> > > > > > > > POV. Downstream OS vendors are free to place restrictions on which
> > > > > > > > backend processes they'd be willing to support with QEMU, and upstream
> > > > > > > > is under no obligation to debug stuff beyond the QEMU boundary.
> > > > > > > >
> > > > > > > > We have already accepted that tradeoff with networking by supporting
> > > > > > > > vhost-user and have externals impls like DPDK, so I don't see a
> > > > > > > > compelling reason to try to restrict it for other vhost-user backends.
> > > > > > >
> > > > > > > OK seems to be more or less a rough concensus then.
> > > > > > >
> > > > > > > I wonder what's the approach wrt migration though.
> > > > > >
> > > > > > The series doesn't take care of migration.
> > > > > >
> > > > > > >
> > > > > > > Even the compatibility story about vhost-user isn't
> > > > > > > great, I would like to see something solid before
> > > > > > > we allow that.
> > > > > >
> > > > > > To allow migration? vhost-user has partial support for migration
> > > > > > (dirty memory tracking), and there is also "[PATCH v2 for-4.0 0/7]
> > > > > > vhost-user-blk: Add support for backend reconnecting" - allowing the
> > > > > > backend to store some state, if I understand correctly, which could be
> > > > > > leveraged I guess...
> > > > > >
> > > > > > But I don't think we should block this series because migration isn't
> > > > > > tackled here.
> > > > > >
> > > > > > thanks
> > > > > >
> > > > > >
> > > > > > .
> > > > >
> > > > > How about blocking migration for now then?
> > > >
> > > > The device here (vhost-user-input) blocks migration (unmigratable = 1)
> > >
> > > Right. But that device is just an excersize, right?
> >
> > Mostly
> >
> > > It bothers me that next device might not remember and
> > > we will get a mess.
> >
> > The next device (the one I care most about) is vhost-user-gpu.
> >
> > > Could we make it somehow that if there is no vmsd
> > > then migration is blocked?
> >
> > Where would you do that? in DeviceClass? That might break other
> > devices, needs code review. In VirtIODevice? that would be probably
> > simpler.
>
> In vhost user core somehow?
I suppose something like that:
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index d51d1087f6..5680dc5d8e 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -1470,12 +1470,16 @@ static int vhost_user_backend_init(struct
vhost_dev *dev, void *opaque)
}
}
- if (dev->migration_blocker == NULL &&
- !virtio_has_feature(dev->protocol_features,
- VHOST_USER_PROTOCOL_F_LOG_SHMFD)) {
- error_setg(&dev->migration_blocker,
- "Migration disabled: vhost-user backend lacks "
- "VHOST_USER_PROTOCOL_F_LOG_SHMFD feature.");
+ if (dev->migration_blocker == NULL) {
+ if (!virtio_has_feature(dev->protocol_features,
+ VHOST_USER_PROTOCOL_F_LOG_SHMFD)) {
+ error_setg(&dev->migration_blocker,
+ "Migration disabled: vhost-user backend lacks "
+ "VHOST_USER_PROTOCOL_F_LOG_SHMFD feature.");
+ } else if (!qdev_get_vmsd(DEVICE(dev->vdev))) {
+ error_setg(&dev->migration_blocker,
+ "Migration disabled: vhost-user device lacks VMSD");
+ }
}
Unfortunately, vdev is not set before vhost_dev_start().
We could add the migration blocker there somehow? There is no
dedicated backend callback for that (I don't think set_features(),
set_mem_table() etc are good places..)
Looking for help here, this is currently blocking me on
vhost-user-input/vhost-user-gpu.
--
Marc-André Lureau
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2019-01-08 13:23 ` Marc-André Lureau
@ 2019-01-09 8:45 ` Hoffmann, Gerd
2019-01-09 20:53 ` Marc-André Lureau
0 siblings, 1 reply; 30+ messages in thread
From: Hoffmann, Gerd @ 2019-01-09 8:45 UTC (permalink / raw)
To: Marc-André Lureau
Cc: Michael S. Tsirkin, Daniel P. Berrangé, qemu-devel, Maxime Coquelin
Hi,
> Unfortunately, vdev is not set before vhost_dev_start().
>
> We could add the migration blocker there somehow?
Sure. Just use migrate_add_blocker() to do that at any time (see qxl.c
for an example).
HTH,
Gerd
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
2019-01-09 8:45 ` Hoffmann, Gerd
@ 2019-01-09 20:53 ` Marc-André Lureau
0 siblings, 0 replies; 30+ messages in thread
From: Marc-André Lureau @ 2019-01-09 20:53 UTC (permalink / raw)
To: Hoffmann, Gerd
Cc: Michael S. Tsirkin, Daniel P. Berrangé, qemu-devel, Maxime Coquelin
Hi
On Wed, Jan 9, 2019 at 12:45 PM Hoffmann, Gerd <kraxel@redhat.com> wrote:
>
> Hi,
>
> > Unfortunately, vdev is not set before vhost_dev_start().
> >
> > We could add the migration blocker there somehow?
>
> Sure. Just use migrate_add_blocker() to do that at any time (see qxl.c
> for an example).
VhostUserInput inherits from VirtioInput, which implements vmsd.
The "Add vhost-user-input-pci" patch override the DeviceClass vmsd to
set it as unmigratable. If I understand correctly, Michael suggested
to add a check for device vmsd == NULL in hw/virtio/vhost-user.c
instead.
However, vhost-user devices would still need to overwrite vmsd to NULL.
I don't think there is a benefit in the generic vmsd == NULL check, as
you still need not to forget to overwrite vmsd to NULL in the
vhost-user device.
Am I missing something?
--
Marc-André Lureau
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2019-01-09 20:53 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-26 12:42 [Qemu-devel] [PATCH for-3.2 00/11] vhost-user-backend & vhost-user-input Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends Marc-André Lureau
2018-11-26 20:57 ` Eric Blake
2018-12-10 14:29 ` Gerd Hoffmann
2018-12-10 18:36 ` Marc-André Lureau
2018-12-10 23:37 ` Michael S. Tsirkin
2018-12-11 7:42 ` Hoffmann, Gerd
2018-12-11 9:29 ` Daniel P. Berrangé
2018-12-11 18:56 ` Michael S. Tsirkin
2018-12-18 18:35 ` Marc-André Lureau
2018-12-18 23:20 ` Michael S. Tsirkin
2018-12-19 8:01 ` Marc-André Lureau
2018-12-19 15:42 ` Michael S. Tsirkin
2018-12-20 12:40 ` Marc-André Lureau
2018-12-20 16:33 ` Michael S. Tsirkin
2019-01-08 13:23 ` Marc-André Lureau
2019-01-09 8:45 ` Hoffmann, Gerd
2019-01-09 20:53 ` Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 02/11] vhost-user: simplify vhost_user_init/vhost_user_cleanup Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 03/11] libvhost-user: exit by default on VHOST_USER_NONE Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 04/11] vhost-user: wrap some read/write with retry handling Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 05/11] Add vhost-user-backend Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 06/11] vhost-user: split vhost_user_read() Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 07/11] vhost-user: add vhost_user_input_get_config() Marc-André Lureau
2018-12-10 14:26 ` Gerd Hoffmann
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 08/11] libvhost-user-glib: export vug_source_new() Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 09/11] libvhost-user: add vu_queue_unpop() Marc-André Lureau
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 10/11] Add vhost-user-input-pci Marc-André Lureau
2018-12-10 14:26 ` Gerd Hoffmann
2018-11-26 12:42 ` [Qemu-devel] [PATCH for-3.2 11/11] contrib: add vhost-user-input Marc-André Lureau
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.