Re: [Qemu-stable] [ANNOUNCE] QEMU 2.6.1 Stable released

[Michael Roth]

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 
> <address@hidden>:
> 
> 
>                         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 :(
> 
> 
>                                         The virtio thing is important because 
> 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 
> target initializing inuse to 0?
> 
>                                     Or is the issue that the fix introduced 
> in 86cc089 is only partially
>                                     effective due to inuse not being 
> recalculated properly on target? That might
>                                     warrant a 2.6.1.1...
> 
>                                 This is what Stefan wrote in the cover letter 
> to the series:
> 
>                                 "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 device that holds VirtQueueElements acros
>                                 live migration will terminate with a 
> "Virtqueue size exceeded" error message. virtio-balloon and virtio-scsi are 
> affected. 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 migration 
> is solved.
> 
>                             The error can be reproduced when there is a 
> VirtQueueElement pending
>                             across migration (e.g. virtio-blk s->rq failed 
> 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 that 
> 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 VNC 
> server in 2.6.1, but i am still investigating.
> 
>             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.
> 
> 
>         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 state.
>         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: avoid crash if vnc client disconnects with writes pending
> 
> This should definetly go in 2.6.2
> 
> Other vnc related patches might also go in:
> 
> vnc: make sure we finish disconnect
> 
> vnc: ensure connection sharing/limits is always configured
> 
> vnc: fix crash when vnc_server_info_get has an error
> 
> vnc: don't crash getting server info if lsock is NULL
> 
> vnc-enc-tight: fix off-by-one bug
> 
> vnc: fix incorrect checking condition when updating client
> 
> 
> 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