From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7esT-00037J-U3 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 03:13:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7esQ-0001Yx-Fz for qemu-devel@nongnu.org; Wed, 24 Jun 2015 03:13:45 -0400 Received: from mail-pd0-f174.google.com ([209.85.192.174]:34655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7esQ-0001Ye-AM for qemu-devel@nongnu.org; Wed, 24 Jun 2015 03:13:42 -0400 Received: by pdbep18 with SMTP id ep18so2551414pdb.1 for ; Wed, 24 Jun 2015 00:13:41 -0700 (PDT) Message-ID: <558A58A3.5030506@igel.co.jp> Date: Wed, 24 Jun 2015 16:13:39 +0900 From: Tetsuya Mukawa MIME-Version: 1.0 References: <1434945048-27958-1-git-send-email-mukawa@igel.co.jp> <20150622095617-mutt-send-email-mst@redhat.com> <5589194A.9050102@igel.co.jp> <20150623111301-mutt-send-email-mst@redhat.com> <558A4436.5050903@igel.co.jp> <20150624074815-mutt-send-email-mst@redhat.com> In-Reply-To: <20150624074815-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: jasowang@redhat.com, n.nikolaev@virtualopensystems.com, qemu-devel@nongnu.org, stefanha@redhat.com On 2015/06/24 14:57, Michael S. Tsirkin wrote: >>>>>> 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. >>>> I appreciate your all comments. It's truly helpful. >>>> Do you have any plans to support such queue reset features in virtio spec? >>> Maybe, but I don't have the time to work on this :( >>> You are welcome to contribute this. >> To do that, I need to talk around my boss to join OASIS :'( > That's not true at all. Non members can submit feedback. > You do need permission from your employer, but > no need to join and pay fees if you don't want to. > See > https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio > for the details. Thanks so much for correcting. >> Probably it's not so easy, so I will just wait, if we need to change >> spec itself. > The QEMU patch that allows handling backend disconnect similar to > disk errors can be implemented without guest/spec changes > let me know if you need more explanation. Could you please describe it more? I want to try to implement it. Regards, Tetsuya