From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axCaw-0005rY-9u for qemu-devel@nongnu.org; Mon, 02 May 2016 08:05:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axCak-0002CB-Ba for qemu-devel@nongnu.org; Mon, 02 May 2016 08:04:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axCak-0002Ag-4P for qemu-devel@nongnu.org; Mon, 02 May 2016 08:04:46 -0400 Date: Mon, 2 May 2016 15:04:30 +0300 From: "Michael S. Tsirkin" Message-ID: <20160502143051-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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: 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: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau Cc: Yuanhan Liu , QEMU , Ilya Maximets , jonshin@cisco.com, Tetsuya Mukawa , "Xie, Huawei" On Mon, May 02, 2016 at 01:29:18PM +0200, Marc-Andr=E9 Lureau wrote: > Hi >=20 > On Mon, May 2, 2016 at 12:45 PM, Michael S. Tsirkin wr= ote: > > 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 discon= nect? > > Monitor commands for disconnecting seem called for. >=20 > 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, Right, but flushing buffers + closing the socket looks like a cleaner interface than a ton of messages going back and forth. > 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..) You assume the backend has a monitor interface to disconnect though. That's not a given. > > > > 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 supporte= d. >=20 > (doing all this, at this point, I don't see much difference with > having an explicit shutdown) With graceful shutdown we implicitly request flush when we ask backend to stop. > > - As Marc-Andr=E9 said, without graceful shutdown it is not enough to > > handle ring state though. We must handle socket getting disconnect= ed > > 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_RE= SET > > status. One way to fix this would be a new feature bit. If NEED_RES= ET not > > 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 >=20 > That's what Tetsuya proposed in its initial series, but handling the > flags was quite tedious. That would be up to management. E.g. let backend export the list of flags it supports in some file, and apply to QEMU. > 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. Seems asymmetrical unless we stop the vm. > > - 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 valu= e > > in doing this automatically in qemu. >=20 > Testing doesn't show such buffer issues when the link is down (this > can be tested with vubr example above) Not enough testing then - it's a race condition: buffers can be sent before link down. > > - Alternatively, we should also have an option to stop vm automatical= ly (like we do on > > disk errors) to reduce number of dropped packets. >=20 > Why not, we would need to know if this is actually useful. >=20 > > > > 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, b= ut should 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 ca= lled 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. >=20 > That's all involving a third party, adding complexity but the benefit > isn't so clear. It's rather clear to me. Let's assume you want to restart bridge, so you trigger disconnect. If qemu auto-reconnects there's a race as it might re-connect to the old bridge. Management is required to make this robust, auto-reconnect is handy for people bypassing management. > --=20 > Marc-Andr=E9 Lureau