From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axC2v-0007fz-C3 for qemu-devel@nongnu.org; Mon, 02 May 2016 07:29:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axC2j-0003sX-FH for qemu-devel@nongnu.org; Mon, 02 May 2016 07:29:43 -0400 Received: from mail-yw0-x243.google.com ([2607:f8b0:4002:c05::243]:35573) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axC2i-0003pU-7H for qemu-devel@nongnu.org; Mon, 02 May 2016 07:29:37 -0400 Received: by mail-yw0-x243.google.com with SMTP id v81so19146231ywa.2 for ; Mon, 02 May 2016 04:29:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160502080610-mutt-send-email-mst@redhat.com> References: <1459509388-6185-1-git-send-email-marcandre.lureau@redhat.com> <1459509388-6185-12-git-send-email-marcandre.lureau@redhat.com> <20160428052304.GF25677@yliu-dev.sh.intel.com> <20160429174835.GH5641@yliu-dev.sh.intel.com> <20160501134233-mutt-send-email-mst@redhat.com> <20160501210442.GK5641@yliu-dev.sh.intel.com> <20160502080610-mutt-send-email-mst@redhat.com> Date: Mon, 2 May 2016 13:29:18 +0200 Message-ID: From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 11/18] vhost-user: add shutdown support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Yuanhan Liu , QEMU , Ilya Maximets , jonshin@cisco.com, Tetsuya Mukawa , "Xie, Huawei" Hi On Mon, May 2, 2016 at 12:45 PM, Michael S. Tsirkin wrote: > 1. Graceful disconnect > - One should be able to do vmstop, disconnect, connect then vm start > This looks like a nice intermediate step. > - Why would we always assume it's always remote initiating the disconnect= ? > Monitor commands for disconnecting seem called for. Those two solutions involve VM management. This looks more complex to communicate/synchronize vhost-user backend & vm management & qemu. The use case I cover is request from the backend to shutdown, because that's what the users wanted (and it is already possible to stop the backend and disconnect it from qemu, we would only need to know when, with a new command..) > > 2. Unexpected disconnect > - If buffers are processed in order or flushed before socket close, > then on disconnect status can be recovered > from ring alone. If that is of interest, we might want to add > a protocol flag for that. F_DISCONNECT_FLUSH ? Without this, > only graceful disconnect or reset with guest's help can be supported. (doing all this, at this point, I don't see much difference with having an explicit shutdown) > - As Marc-Andr=C3=A9 said, without graceful shutdown it is not enough to > handle ring state though. We must handle socket getting disconnected > in the middle of send/receive. While it's more work, > it does seem like a nice interface to support. > - I understand the concern that existing guests do not handle NEED_RESET > status. One way to fix this would be a new feature bit. If NEED_RESET n= ot > handled, request hot-unplug instead. > > 3. Running while disconnected > - At the moment, we wait on vm start for remote to connect, > if we support disconnecting backend without stopping > we probably should also support starting it without waiting > for connection That's what Tetsuya proposed in its initial series, but handling the flags was quite tedious. I think this can be considered easily a seperate enhancement. What I proposed is to keep waiting for the initial connect, and check the flags remains compatible on reconnect. > - Guests expect tx buffers to be used in a timely manner, thus: > - If vm is running we must use them in qemu, maybe discarding packets > in the process. > There already are commands for link down, I'm not sure there's value > in doing this automatically in qemu. Testing doesn't show such buffer issues when the link is down (this can be tested with vubr example above) > - Alternatively, we should also have an option to stop vm automatically (= like we do on > disk errors) to reduce number of dropped packets. Why not, we would need to know if this is actually useful. > > 4. Reconnecting > - When acting as a server, we might want an option to go back to > listening state, but it should not be the only option, > there should be a monitor command for moving it back to > listening state. > - When acting as a client, auto-reconnect might be handy sometimes, but s= hould not be the only > option, there should be a way to manually request connect, possibly to > a different target, so a monitor command for re-connecting seems called= for. > - We'll also need monitor events for disconnects so management knows it > must re-connect/restart listening. > - If we stopped VM, there could be an option to restart on reconnect. That's all involving a third party, adding complexity but the benefit isn't so clear. --=20 Marc-Andr=C3=A9 Lureau