From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6wsX-00012N-BX for qemu-devel@nongnu.org; Mon, 22 Jun 2015 04:14:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z6wsR-000256-Al for qemu-devel@nongnu.org; Mon, 22 Jun 2015 04:14:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6wsR-00024v-3D for qemu-devel@nongnu.org; Mon, 22 Jun 2015 04:14:47 -0400 Date: Mon, 22 Jun 2015 10:14:43 +0200 From: "Michael S. Tsirkin" Message-ID: <20150622095617-mutt-send-email-mst@redhat.com> References: <1434945048-27958-1-git-send-email-mukawa@igel.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1434945048-27958-1-git-send-email-mukawa@igel.co.jp> Subject: Re: [Qemu-devel] [PATCH v2 0/5] Add feature to start QEMU without vhost-user backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tetsuya Mukawa Cc: jasowang@redhat.com, n.nikolaev@virtualopensystems.com, qemu-devel@nongnu.org, stefanha@redhat.com On Mon, Jun 22, 2015 at 12:50:43PM +0900, Tetsuya Mukawa wrote: > Hi guys, > > Here are patches to add feature to start QEMU without vhost-user backend. > Currently, if we want to use vhost-user backend, the backend must start before > QEMU. Aren't you looking for something like xinetd? > Also, if QEMU or the backend is closed unexpectedly, there is no way to > recover without restarting both applications. This was previously discussed: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00585.html It doesn't look like any of the issues have been addressed. In my opinion, the right way to handle this requires guest cooperation. For example, we can extend virtio 1 to allow a single queue to reset. We then can do something like the following: - hypervisor detects queue backend disconnect. - hypervisor sets flag and notifies guest - guest resets queue, optionally discarding queued packets - hypervisor detects (or requests if it's a client), backend reconnect - hypervisor detects guest queue reset - hypervisor notifies guests about backend reconnect - hypervisor sends hypervisor device state (e.g. queue addresses and indices) to backend Reconnect isn't robust without such an extension. > Practically, it's not useful. One thing we do seem to lack is specifying an action taken on disconnect. It could be an action similar to r/werror. One extra useful option could be to exit qemu. > This patch series adds following features. > - QEMU can start before the backend. I don't see the point of this one. > - QEMU or the backend can restart anytime. > connectivity will be recovered automatically, when app starts again. > (if QEMU is server, QEMU just wait reconnection) > while lost connection, link status of virtio-net device is down, > so virtio-net driver on the guest can know it > > To work like above, the patch introduces flags to specify features vhost-user > backend will support. > > Here are examples. > ('backend_features' is the new flags. Each bit of the flag represents > VIRTIO_NET_F_* in linux/virtio_net.h) > > * QEMU is configured as vhost-user client. > -chardev socket,id=chr0,path=/tmp/sock,reconnect=3 \ > -netdev vhost-user,id=net0,chardev=chr0,vhostforce,backend-features=0x68000 \ > -device virtio-net-pci,netdev=net0 \ > > * QEMU is configured as vhost-user server. > -chardev socket,id=chr0,path=/tmp/sock,server,nowait \ > -netdev vhost-user,id=net0,chardev=chr0,vhostforce,backend-features=0x68000 \ > -device virtio-net-pci,netdev=net0 \ This relies on management knowing the feature bitmap encoding of the backend, not sure how practical that is. > > When virtio-net device is configured by virtio-net driver, QEMU should know > vhost-user backend features. But if QEMU starts without the backend, QEMU cannot > know it. So above the feature values specified by user will be used as features > the backend will support. > > When connection between QEMU and the backend is established, QEMU checkes feature > values of the backend to make sure the expected features are provided. > If it doesn't, the connection will be closed by QEMU. > > Regards, > Tetsuya > > ---------- > Changes > ---------- > - v2 changes from v1 patch > - Rebase to latest master. > - Change user interface to be able to specify each feature by UINT64. > - Replace backend_* to backend-* in qapi schema. > - Use close(2) interface for opended socket instead of using shutdown(2) > interface. > - Split 2nd patch of v1 into 2nd and 3rd patch of v2. > - Fix commit title and body. > - Add comment, and fix indent. > - Use {} even for single statement if bodies. > - Use PRIx64 instead of %lx. > > > - v1 changes from RFC patch > The last patch of this series was changed like below. > - Rebase to latest master. > - Remove needless has_backend_feature variable. > - Change user interface to be able to specify each feature by name. > - Add (Since 2.4) to schema file. > - Fix commit title and body. > > Tetsuya Mukawa (5): > vhost-user: Add ability to know vhost-user backend disconnection > qemu-char: Add qemu_chr_disconnect to close a fd accepted by listen fd > vhost-user: Shutdown vhost-user connection when wrong messages are > passed > vhost-user: Enable 'nowait' and 'reconnect' option > vhost-user: Add new option to specify vhost-user backend supports > > hw/net/vhost_net.c | 6 +++++- > hw/net/virtio-net.c | 15 +++++++++++++++ > hw/scsi/vhost-scsi.c | 2 +- > hw/virtio/vhost-user.c | 24 ++++++++++++++++------- > hw/virtio/vhost.c | 3 ++- > include/hw/virtio/vhost.h | 3 ++- > include/hw/virtio/virtio-net.h | 1 + > include/net/net.h | 3 +++ > include/net/vhost_net.h | 1 + > include/sysemu/char.h | 7 +++++++ > net/net.c | 9 +++++++++ > net/tap.c | 1 + > net/vhost-user.c | 43 ++++++++++++++++++++++++++++++++++++++++-- > qapi-schema.json | 12 ++++++++++-- > qemu-char.c | 8 ++++++++ > qemu-options.hx | 3 ++- > 16 files changed, 125 insertions(+), 16 deletions(-) > > -- > 2.1.4