From nobody Sun Apr 28 16:36:42 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 153683777432471.78738226368318; Thu, 13 Sep 2018 04:22:54 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 258B9307D973; Thu, 13 Sep 2018 11:22:52 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CEDB22010CAA; Thu, 13 Sep 2018 11:22:51 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 797A8181A12E; Thu, 13 Sep 2018 11:22:51 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id w8DBMank020994 for ; Thu, 13 Sep 2018 07:22:36 -0400 Received: by smtp.corp.redhat.com (Postfix) id 97BF9600D4; Thu, 13 Sep 2018 11:22:36 +0000 (UTC) Received: from localhost (ovpn-112-57.ams2.redhat.com [10.36.112.57]) by smtp.corp.redhat.com (Postfix) with ESMTP id 41244600C6; Thu, 13 Sep 2018 11:22:22 +0000 (UTC) From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= To: qemu-devel@nongnu.org Date: Thu, 13 Sep 2018 15:22:05 +0400 Message-Id: <20180913112205.3252-1-marcandre.lureau@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com Cc: Victor Kaplansky , "Michael S . Tsirkin" , libvir-list@redhat.com, "Dr . David Alan Gilbert" , Maxime Coquelin , Gonglei , Gerd Hoffmann , Felipe Franciosi , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Changpeng Liu Subject: [libvirt] [PATCH] vhost-user: define conventions for vhost-user backends X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.25 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Thu, 13 Sep 2018 11:22:52 +0000 (UTC) X-ZohoMail: RDMRC_0 RSF_0 Z_629925259 SPT_0 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. Cc: libvir-list@redhat.com Cc: Gerd Hoffmann Cc: Daniel P. Berrang=C3=A9 Cc: Changpeng Liu Cc: Dr. David Alan Gilbert Cc: Felipe Franciosi Cc: Gonglei Cc: Maxime Coquelin Cc: Michael S. Tsirkin Cc: Victor Kaplansky Signed-off-by: Marc-Andr=C3=A9 Lureau --- docs/interop/vhost-user.txt | 106 +++++++++++++++++++++++++++++++++++- 1 file changed, 104 insertions(+), 2 deletions(-) diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt index ba5e37d714..691ce173ed 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, maste= r and slave. Master is the application that shares its virtqueues, in our case QEMU. Slave is the consumer of the virtqueues. =20 -In the current implementation QEMU is the Master, and the Slave is intende= d 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. =20 Master and slave can be either a client (i.e. connecting) or server (liste= ning) in the socket communication. @@ -859,3 +864,100 @@ 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 br= ings no behavioural change. (See the 'Communication' section for details.) + +Backend program conventions +--------------------------- + +vhost-user backends provide various services and they 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 program and +facilitate interoperability. + +In order to be discoverable, default vhost-user backends should be +located under "/usr/libexec", and be named "vhost-user-$device" where +"$device" is the device name in lower-case following the name listed +in the Linux virtio_ids.h header (ex: the VIRTIO_ID_RPROC_SERIAL +backend would be named "vhost-user-rproc-serial"). + +Mechanisms to list, and to select among alternatives implementations +or modify the default backend are not described at this point (a +distribution may use update-alternatives, for example, to list and to +pick a different default backend). + +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=3DPATH + +This option specify the location of the vhost-user Unix domain socket. +It is incompatible with --fd. + +* --fd=3DFDNUM + +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 a line-seperated list of backend capabilities, and +then exit successfully. Other options and arguments should be ignored, +and the backend program should not perform its normal function. + +At the time of writing, there are no common capabilities. Some +device-specific capabilities are listed in the respective sections. By +convention, device-specific capabilities are prefixed by their device +name. + +* --pidfile=3DPATH + +Write the process id (PID) to the given file PATH. This is mostly +useful if the backend daemonize/fork itself. + +vhost-user-input program conventions +------------------------------------ + +Capabilities: + +input-evdev-path + + The --evdev-path command line option is supported. + +input-no-grab + + The --no-grab command line option is supported. + +* --evdev-path=3DPATH (optional) + +Specify the linux input device. + +* --no-grab (optional) + +Do no request exclusive access to the input device. + +vhost-user-gpu program conventions +---------------------------------- + +Capabilities: + +gpu-render-node + + The --render-node command line option is supported. + +gpu-virgl + + The --virgl command line option is supported. + +* --render-node=3DPATH (optional) + +Specify the GPU DRM render node. + +* --virgl (optional) + +Enable virgl rendering support. --=20 2.19.0.rc1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list