From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ao3wa-00038x-PQ for qemu-devel@nongnu.org; Thu, 07 Apr 2016 03:01:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ao3wV-0000Bl-QL for qemu-devel@nongnu.org; Thu, 07 Apr 2016 03:01:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ao3wV-0000Bh-Kg for qemu-devel@nongnu.org; Thu, 07 Apr 2016 03:01:27 -0400 Date: Thu, 7 Apr 2016 10:01:23 +0300 From: "Michael S. Tsirkin" Message-ID: <20160407095656-mutt-send-email-mst@redhat.com> References: <128905570.197151459986776566.JavaMail.weblogic@eumlwas01> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <128905570.197151459986776566.JavaMail.weblogic@eumlwas01> Subject: Re: [Qemu-devel] [PATCH 0/4] Fix QEMU crash on vhost-user socket disconnect. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ilya Maximets Cc: Jason Wang , "qemu-devel@nongnu.org" , Sergey Dyasly On Wed, Apr 06, 2016 at 11:52:56PM +0000, Ilya Maximets wrote: > ------- Original Message ------- > Sender : Michael S. Tsirkin > Date : Apr 05, 2016 13:46 (GMT+03:00) > Title : Re: [PATCH 0/4] Fix QEMU crash on vhost-user socket disconnect. > > > On Thu, Mar 31, 2016 at 09:02:01AM +0300, Ilya Maximets wrote: > > > On 30.03.2016 20:01, Michael S. Tsirkin wrote: > > > > On Wed, Mar 30, 2016 at 06:14:05PM +0300, Ilya Maximets wrote: > > > >> Currently QEMU always crashes in following scenario (assume that > > > >> vhost-user application is Open vSwitch with 'dpdkvhostuser' port): > > > > > > > > In fact, wouldn't the right thing to do be stopping the VM? > > > > > > I don't think that is reasonable to stop VM on failure of just one of > > > network interfaces. > > > > We don't start QEMU until vhost user connects, either. > > Making guest run properly with a backend is a much bigger > > project, let's tackle this separately. > > > > Also, I think handling graceful disconnect is the correct first step. > > Handling misbehaving clients is much harder as we have asserts on remote > > obeying protocol rules all over the place. > > > > > There may be still working vhost-kernel interfaces. > > > Even connection can still be established if vhost-user interface was in > > > bonding with kernel interface. > > > > Could not parse this. > > > > > Anyway user should be able to save all his data before QEMU restart. > > > > So reconnect a new backend, and VM will keep going. > > We cant't do this because of 2 reasons: > 1. Segmentation fault of QEMU on disconnect. (fixed by this patch-set) > 2. There is no reconnect functionality in current QEMU version. > > So, what are you talking about? > > Best regards, Ilya Maximets. One can currently disconnect vhost user clients without killing guests using migration: - save vm - quit qemu - start new qemu - load vm Or using hotplug - request unplug - wait for guest eject - create new device I would like to make sure we do not create an expectation that guests keep going unconditionally with device present even with backend disconnected. Unfortunately your patchset might create such expectation. -- MST