From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bju8M-0007k8-Si for qemu-devel@nongnu.org; Tue, 13 Sep 2016 16:16:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bju8I-0000qx-LF for qemu-devel@nongnu.org; Tue, 13 Sep 2016 16:16:45 -0400 Received: from mx01.kamp.de ([82.141.2.16]:59926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bju8I-0000qJ-BD for qemu-devel@nongnu.org; Tue, 13 Sep 2016 16:16:42 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Peter Lieven In-Reply-To: <20160913180459.17438.49499@loki> Date: Tue, 13 Sep 2016 22:16:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <29F56387-A79E-4C20-9DA9-25B6CD5894C0@kamp.de> References: <20160817193046.7220.688@loki> <8e3ac487-a3ee-1aef-2240-4c388e0004f7@kamp.de> <20160825172345.17599.42638@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> 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: Michael Roth Cc: Stefan Hajnoczi , Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-stable@nongnu.org, Jan-Hendrik Frintrop > Am 13.09.2016 um 20:04 schrieb Michael Roth : >=20 > Quoting Peter Lieven (2016-09-13 10:52:04) >>=20 >>=20 >>>> Am 13.09.2016 um 17:42 schrieb Stefan Hajnoczi : >>>>=20 >>>> 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 Michael Roth: >>>>>>>> Quoting Peter Lieven (2016-08-25 01:38:13) >>>>>>>> 7c509d1 virtio: decrement vq->inuse in virtqueue_discard() >>>>>>>> 700f26b virtio: recalculate vq->inuse after migration >>>>>>> Looks like these got posted during the freeze :( >>>>>>>=20 >>>>>>>> The virtio thing is important because live migration is broken with= out >>>>>>>> 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 target initializing inuse to 0? >>>>>>>=20 >>>>>>> Or is the issue that the fix introduced in 86cc089 is only partially= >>>>>>> effective due to inuse not being recalculated properly on target? Th= at might >>>>>>> warrant a 2.6.1.1... >>>>>>=20 >>>>>> This is what Stefan wrote in the cover letter to the series: >>>>>>=20 >>>>>> "I should mention this is for QEMU 2.7. These fixes are needed if the= >>>>>> CVE-2016-5403 patch has been applied. Without these patches any devic= e that holds VirtQueueElements acros >>>>>> live migration will terminate with a "Virtqueue size exceeded" error m= essage. virtio-balloon and virtio-scsi are affected. virtio-bl >>>>>> probably too but I haven't tested it." >>>>>>=20 >>>>>> Maybe >>>>>=20 >>>>> The virtio inuse fixes are needed for stable (v2.6.2?) so that the >>>>> spurious "Virtqueue size exceeded" on migration is solved. >>>>>=20 >>>>> The error can be reproduced when there is a VirtQueueElement pending >>>>> across migration (e.g. virtio-blk s->rq failed request list). >>>>=20 >>>> Thanks for clarifying. I'm planning to do a 2.6.2 to capture these, the= >>>> patches Peter mentioned, and some other fixes that came during 2.7 RC >>>> phase. >>>>=20 >>>> I have an initial staging tree at: >>>>=20 >>>> https://github.com/mdroth/qemu/commits/stable-2.6-staging >>>>=20 >>>> 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. >>>=20 >>> Two more candidates for stable: >>>=20 >>> 4b7f91e virtio: zero vq->inuse in virtio_reset() >>> 104e70c virtio-balloon: discard virtqueue element on reset >>>=20 >>> They also deal with "Virtqueue size exceeded" errors. >>>=20 >>> Stefan >>=20 >> There also seems to be an regression (segfault) in the VNC server in 2.6.= 1, but i am still investigating. >=20 > Do you have a reproducer? I can try a bisect. Trying to get the initial > staging tree posted today but want to make sure any known regressions are > addressed beforehand. i am out of Office till Monday, but if I remember correctly I saw mutex erro= rs (not segfaults) with 2.6.1 that were not there on 2.5.1.1. They happened w= hile my colleagues where experimenting with a new VNC client. So its likely t= hat a certain connect/disconnect pattern is the trigger. I am not sure if th= e same issue exists in master. For more details we might have to wait till i= am back at the office, sorry. However, CC'ing Jan from Kamp. Maybe he has a reproducer. Peter=20