From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpKu8-0004Oy-LR for qemu-devel@nongnu.org; Wed, 28 Sep 2016 15:52:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpKu1-0002Wn-7H for qemu-devel@nongnu.org; Wed, 28 Sep 2016 15:52:31 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41729 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpKu0-0002Wh-OV for qemu-devel@nongnu.org; Wed, 28 Sep 2016 15:52:24 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8SJnShJ078463 for ; Wed, 28 Sep 2016 15:52:23 -0400 Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by mx0a-001b2d01.pphosted.com with ESMTP id 25rc98ua6f-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Sep 2016 15:52:23 -0400 Received: from localhost by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 28 Sep 2016 13:52:22 -0600 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth In-Reply-To: References: <20160817193046.7220.688@loki> <38b365e3-4182-d9d9-28d6-275dfad0da8a@kamp.de> <20160905175435.GF24387@stefanha-x1.localdomain> <20160908205826.17599.75522@loki> <20160913154248.GC5677@stefanha-x1.localdomain> <51785872-1D0C-419D-B03E-34A63F81C6BD@kamp.de> <20160913180459.17438.49499@loki> <92840511-4c81-f845-0512-788abf6fe08e@kamp.de> <838b4d20-496e-2b48-125b-41d82c415b6e@kamp.de> Date: Wed, 28 Sep 2016 14:52:12 -0500 Message-Id: <20160928195212.1679.66196@loki> Subject: Re: [Qemu-devel] [Qemu-stable] [ANNOUNCE] QEMU 2.6.1 Stable released List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , Stefan Hajnoczi Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-stable@nongnu.org, Gerd Hoffmann , "Daniel P. Berrange" , arei.gonglei@huawei.com Quoting Peter Lieven (2016-09-27 06:30:27) > Am 27.09.2016 um 12:28 schrieb Peter Lieven: > = > Am 16.09.2016 um 15:56 schrieb Peter Lieven: > = > Am 13.09.2016 um 20:04 schrieb Michael Roth: > = > Quoting Peter Lieven (2016-09-13 10:52:04) > = > Am 13.09.2016 um 17:42 schrieb Stefan Hajnoczi : > = > = > On Thu, Sep 08, 2016 at 03:58:26PM -0500, Michael= Roth wrote: > Quoting Stefan Hajnoczi (2016-09-05 12:54:35) > = > On Fri, Aug 26, 2016 at 01:45:56PM +0200,= Peter Lieven wrote: > = > Am 25.08.2016 um 19:23 schrieb Michae= l Roth: > Quoting Peter Lieven (2016-08-25 01:3= 8:13) > = > 7c509d1 virtio: decrement vq->inu= se in virtqueue_discard() > 700f26b virtio: recalculate vq->i= nuse after migration > = > Looks like these got posted during th= e freeze :( > = > = > The virtio thing is important bec= ause live migration is broken without > the fix as 86cc089 is in 2.6.1. > = > Not sure I understand the relation to= 86cc089. Wouldn't the check > introduced there always pass due to t= arget initializing inuse to 0? > = > Or is the issue that the fix introduc= ed in 86cc089 is only partially > effective due to inuse not being reca= lculated properly on target? That might > warrant a 2.6.1.1... > = > This is what Stefan wrote in the cover le= tter to the series: > = > "I should mention this is for QEMU 2.7. T= hese fixes are needed if the > CVE-2016-5403 patch has been applied. Wit= hout these patches any device that holds VirtQueueElements acros > live migration will terminate with a "Vir= tqueue size exceeded" error message. virtio-balloon and virtio-scsi are aff= ected. virtio-bl > probably too but I haven't tested it." > = > Maybe > = > The virtio inuse fixes are needed for stable = (v2.6.2?) so that the > spurious "Virtqueue size exceeded" on migrati= on is solved. > = > The error can be reproduced when there is a V= irtQueueElement pending > across migration (e.g. virtio-blk s->rq faile= d request list). > = > Thanks for clarifying. I'm planning to do a 2.6.2= to capture these, the > patches Peter mentioned, and some other fixes tha= t came during 2.7 RC > phase. > = > I have an initial staging tree at: > = > https://github.com/mdroth/qemu/commits/stable-2.= 6-staging > = > There's still a few PULLs in flight with patches = I plan to pull in, but > hoping to send out the patch round-up early next = week and a release the > following week. > = > Two more candidates for stable: > = > 4b7f91e virtio: zero vq->inuse in virtio_reset() > 104e70c virtio-balloon: discard virtqueue element on = reset > = > They also deal with "Virtqueue size exceeded" errors. > = > Stefan > = > There also seems to be an regression (segfault) in the VN= C server in 2.6.1, but i am still investigating. > = > Do you have a reproducer? I can try a bisect. Trying to get t= he initial > staging tree posted today but want to make sure any known reg= ressions are > addressed beforehand. > = > = > Hi Michael, > = > we have not been able to reproduce anymore. My guess is that our = client > had a bug in the new version > and that the regression can only happen in a special connection s= tate. > But we are still trying > to reproduce. > = > = > We are again able to reproduce the VNC error. The vServer dies with: > = > qemu: qemu_mutex_lock: Invalid argument > = > We are working on it. > = > = > The bug we faced is fixed upstream in: > = > ui:=C2=A0avoid=C2=A0crash=C2=A0if=C2=A0vnc=C2=A0client=C2=A0disconnects= =C2=A0with=C2=A0writes=C2=A0pending > = > This should definetly go in 2.6.2 > = > Other vnc related patches might also go in: > = > vnc:=C2=A0make=C2=A0sure=C2=A0we=C2=A0finish=C2=A0disconnect > = > vnc:=C2=A0ensure=C2=A0connection=C2=A0sharing/limits=C2=A0is=C2=A0always= =C2=A0configured > = > vnc:=C2=A0fix=C2=A0crash=C2=A0when=C2=A0vnc_server_info_get=C2=A0has=C2= =A0an=C2=A0error > = > vnc:=C2=A0don't=C2=A0crash=C2=A0getting=C2=A0server=C2=A0info=C2=A0if=C2= =A0lsock=C2=A0is=C2=A0NULL > = > vnc-enc-tight:=C2=A0fix=C2=A0off-by-one=C2=A0bug > = > vnc:=C2=A0fix=C2=A0incorrect=C2=A0checking=C2=A0condition=C2=A0when=C2=A0= updating=C2=A0client > = > = > unfortunately none of these had qemu-stable in CC. I have these applied in 2.6.2 staging: https://github.com/mdroth/qemu/commits/stable-2.6-staging I wasn't ever able to reproduce the VNC crash though, so if you have a chance to verify and spot any issues still present prior to the 2.6.2 release ~24 hours from now please let me know. > = > = > Peter