[Qemu-devel] [ANNOUNCE] QEMU 2.6.1 Stable released

[Qemu-devel] [ANNOUNCE] QEMU 2.6.1 Stable released

[Michael Roth]

Hi everyone,

I am pleased to announce that the QEMU v2.6.1 stable release is now
available:

  http://wiki.qemu.org/download/qemu-2.6.1.tar.bz2

v2.6.1 is now tagged in the official qemu.git repository,
and the stable-2.6 branch has been updated accordingly:

  http://git.qemu.org/?p=qemu.git;a=shortlog;h=refs/heads/stable-2.6

This is a fairly large update that addresses a broad range of bugs
and security issues. Users should upgrade accordingly.

Thank you to everyone involved!

CHANGELOG:

fcf75ad: Update version for 2.6.1 release (Michael Roth)
5125bef: timer: set vm_clock disabled default (Gonglei)
beeff74: Xen PCI passthrough: fix passthrough failure when no interrupt pin (Bruce Rogers)
1f1b96a: ppc64: fix compressed dump with pseries kernel (Laurent Vivier)
236039b: scsi: esp: check TI buffer index before read/write (Prasad J Pandit)
407fb6f: scsi: megasas: null terminate bios version buffer (Prasad J Pandit)
27fa5e7: scsi: esp: make cmdbuf big enough for maximum CDB size (Prasad J Pandit)
8c04a29: scsi: esp: clean up handle_ti/esp_do_dma if s->do_cmd (Paolo Bonzini)
aa6905d: scsi: esp: respect FIFO invariant after message phase (Paolo Bonzini)
e5c4e64: scsi: esp: check buffer length before reading scsi command (Prasad J Pandit)
80eb9b8: scsi: megasas: check 'read_queue_head' index value (Prasad J Pandit)
19dcd48: scsi: megasas: initialise local configuration data buffer (Prasad J Pandit)
1467b93: scsi: megasas: use appropriate property buffer size (Prasad J Pandit)
7a2c32e: net: mipsnet: check packet length against buffer (Prasad J Pandit)
780d831: hw/arm/virt: Reject gic-version=host for non-KVM (Cole Robinson)
c5ba71b: ui: spice: Exit if gl=on EGL init fails (Cole Robinson)
84da2c6: sdl2: skip init without outputs (Gerd Hoffmann)
ccecdf7: ui: sdl2: Release grab before opening console window (Cole Robinson)
0f9745a: ui: gtk: fix crash when terminal inner-border is NULL (Cole Robinson)
94c8340: ahci: free irqs array (Marc-André Lureau)
3d34297: ahci: fix sglist leak on retry (Marc-André Lureau)
ff71767: macio: set res_count value to 0 after non-block ATAPI DMA transfers (Mark Cave-Ayland)
ec211e7: atapi: fix halted DMA reset (John Snow)
16a87c4: ide: fix halted IO segfault at reset (John Snow)
86cc089: virtio: error out if guest exceeds virtqueue size (Stefan Hajnoczi)
502c8e8: target-i386: fix typo in xsetbv implementation (Dave Hansen)
a87cef8: pcie: fix link active status bit migration (Michael S. Tsirkin)
97b5a97: nbd: Limit nbdflags to 16 bits (Eric Blake)
2317b32: nbd: Don't use *_to_cpup() functions (Peter Maydell)
ce00e52: nbd: More debug typo fixes, use correct formats (Eric Blake)
28eae0a: Fix some typos found by codespell (Stefan Weil)
5634eb8: block/iscsi: fix rounding in iscsi_allocationmap_set (Peter Lieven)
b6ece2c: util: Fix MIN_NON_ZERO (Fam Zheng)
8d7d776: qemu-iotests: Test naming of throttling groups (Alberto Garcia)
704ab2f: blockdev: Fix regression with the default naming of throttling groups (Alberto Garcia)
025c4e3: s390x/ipl: fix reboots for migration from different bios (David Hildenbrand)
82c8516: Revert "virtio-net: unbreak self announcement and guest offloads after migration" (Michael S. Tsirkin)
909d87d: virtio: set low features early on load (Michael S. Tsirkin)
9566cee: target-sparc: fix register corruption in ldstub if there is no write permission (Artyom Tarasenko)
44152ec: scsi: Advertise limits by blocksize, not 512 (Eric Blake)
c9fb07b: scsi-generic: Merge block max xfer len in INQUIRY response (Fam Zheng)
ab2aac5: nbd: Allow larger requests (Eric Blake)
e19b9ad: vfio/pci: Fix VGA quirks (Alex Williamson)
4f696c8: pci-assign: Move "Invalid ROM" error message to pci-assign-load-rom.c (Lin Ma)
a50bb5f: qapi: Fix crash on missing alternate member of QAPI struct (Eric Blake)
4bfe16b: qcow2: Avoid making the L1 table too big (Max Reitz)
683c1c5: backup: Don't leak BackupBlockJob in error path (Kevin Wolf)
45f4e4b: net: fix qemu_announce_self not emitting packets (Peter Lieven)
d1911a6: ui: fix regression in printing VNC host/port on startup (Daniel P. Berrange)
510531e: io: remove mistaken call to object_ref on QTask (Daniel P. Berrange)
d59d37d: vmsvga: don't process more than 1024 fifo commands at once (Gerd Hoffmann)
71798fd: vmsvga: shadow fifo registers (Gerd Hoffmann)
3141be6: vmsvga: add more fifo checks (Gerd Hoffmann)
394647d: vmsvga: move fifo sanity checks to vmsvga_fifo_length (Gerd Hoffmann)
63a396d: block: Drop bdrv_ioctl_bh_cb (Fam Zheng)
f882993: scsi: mptsas: infinite loop while fetching requests (Prasad J Pandit)
8b95d8e: scsi: pvscsi: check command descriptor ring buffer size (CVE-2016-4952) (Prasad J Pandit)
54eb4cf: Fix configure test for PBKDF2 in nettle (Steven Luo)
e81a24a: savevm: fail if migration blockers are present (Greg Kurz)
fb26337: nbd: Don't trim unrequested bytes (Eric Blake)
509e132: block/iscsi: avoid potential overflow of acb->task->cdb (Peter Lieven)
6e7ee98: vfio: Fix broken EEH (Gavin Shan)
7ff5dc4: vga: add sr_vbe register set (Gerd Hoffmann)
a1f006f: usb/ohci: Fix crash with when specifying too many num-ports (Thomas Huth)
cba9a80: block/nfs: refuse readahead if cache.direct is on (Peter Lieven)
9b28a7f: esp: check dma length before reading scsi command(CVE-2016-4441) (Prasad J Pandit)
0a5e368: esp: check command buffer length before write(CVE-2016-4439) (Prasad J Pandit)
2522f0f: json-streamer: fix double-free on exiting during a parse (Paolo Bonzini)
ebe0376: json-streamer: Don't leak tokens on incomplete parse (Eric Blake)
9520c6c: migration: regain control of images when migration fails to complete (Greg Kurz)
dbbadeb: configure: Allow builds with extra warnings (Stefan Weil)
bd5d278: target-i386: key sfence availability on CPUID_SSE, not CPUID_SSE2 (Paolo Bonzini)
a525dec: target-mips: fix call to memset in soft reset code (Aurelien Jarno)
2cf1a12: usb:xhci: no DMA on HC reset (Roman Kagan)
ea819be: exec.c: Ensure right alignment also for file backed ram (Dominik Dingel)
5a908cb: tools: kvm_stat: Powerpc related fixes (Hemant Kumar)
07a3a48: vl: change runstate only if new state is different from current state (Li Zhijian)
5b6c12e: spice/gl: add & use qemu_spice_gl_monitor_config (Gerd Hoffmann)
d00ba3f: i386: kvmvapic: initialise imm32 variable (Prasad J Pandit)

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

[Peter Lieven]

Am 17.08.2016 um 21:30 schrieb Michael Roth:
> Hi everyone,
>
> I am pleased to announce that the QEMU v2.6.1 stable release is now
> available:
>
>    http://wiki.qemu.org/download/qemu-2.6.1.tar.bz2
>
> v2.6.1 is now tagged in the official qemu.git repository,
> and the stable-2.6 branch has been updated accordingly:
>
>    http://git.qemu.org/?p=qemu.git;a=shortlog;h=refs/heads/stable-2.6
>
> This is a fairly large update that addresses a broad range of bugs
> and security issues. Users should upgrade accordingly.
>
> Thank you to everyone involved!

Hi Michael,

thanks for putting this together. Unfortunately, I was on holiday during
the patch round up for 2.6.1

I additionally have the following 5 patches in case you want or need to
release a 2.6.1.1 or 2.6.2:

bd9f480 ui: fix refresh of VNC server surface
7c509d1 virtio: decrement vq->inuse in virtqueue_discard()
700f26b virtio: recalculate vq->inuse after migration
4c23084 net: limit allocation in nc_sendv_compat
bf97c17 iscsi: pass SCSI status back for SG_IO

The virtio thing is important because live migration is broken without
the fix as  86cc089 is in 2.6.1.

Thanks,
Peter

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

[Michael Roth]

Quoting Peter Lieven (2016-08-25 01:38:13)
> Am 17.08.2016 um 21:30 schrieb Michael Roth:
> > Hi everyone,
> >
> > I am pleased to announce that the QEMU v2.6.1 stable release is now
> > available:
> >
> >    http://wiki.qemu.org/download/qemu-2.6.1.tar.bz2
> >
> > v2.6.1 is now tagged in the official qemu.git repository,
> > and the stable-2.6 branch has been updated accordingly:
> >
> >    http://git.qemu.org/?p=qemu.git;a=shortlog;h=refs/heads/stable-2.6
> >
> > This is a fairly large update that addresses a broad range of bugs
> > and security issues. Users should upgrade accordingly.
> >
> > Thank you to everyone involved!
> 
> Hi Michael,
> 
> thanks for putting this together. Unfortunately, I was on holiday during
> the patch round up for 2.6.1
> 
> I additionally have the following 5 patches in case you want or need to
> release a 2.6.1.1 or 2.6.2:
> 
> bd9f480 ui: fix refresh of VNC server surface
> 4c23084 net: limit allocation in nc_sendv_compat

I don't see these in master yet.

> bf97c17 iscsi: pass SCSI status back for SG_IO

I'll pull this in if there's another release, but doesn't look
like a regression from 2.6.0 at least.

> 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...

> 
> Thanks,
> Peter
> 

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

[Peter Lieven]

Am 25.08.2016 um 19:23 schrieb Michael Roth:
> Quoting Peter Lieven (2016-08-25 01:38:13)
>> Am 17.08.2016 um 21:30 schrieb Michael Roth:
>>> Hi everyone,
>>>
>>> I am pleased to announce that the QEMU v2.6.1 stable release is now
>>> available:
>>>
>>>     http://wiki.qemu.org/download/qemu-2.6.1.tar.bz2
>>>
>>> v2.6.1 is now tagged in the official qemu.git repository,
>>> and the stable-2.6 branch has been updated accordingly:
>>>
>>>     http://git.qemu.org/?p=qemu.git;a=shortlog;h=refs/heads/stable-2.6
>>>
>>> This is a fairly large update that addresses a broad range of bugs
>>> and security issues. Users should upgrade accordingly.
>>>
>>> Thank you to everyone involved!
>> Hi Michael,
>>
>> thanks for putting this together. Unfortunately, I was on holiday during
>> the patch round up for 2.6.1
>>
>> I additionally have the following 5 patches in case you want or need to
>> release a 2.6.1.1 or 2.6.2:
>>
>> bd9f480 ui: fix refresh of VNC server surface
>> 4c23084 net: limit allocation in nc_sendv_compat

the vnc fix was also on the list during the freeze. Looking at it at the moment.
There seems to be a second issue with the VNC server as well..
The otherone indeed is missing. Its not critical there is just to much memory
allocated. I will ping Stefan to PULL it for 2.8.

> I don't see these in master yet.
>
>> bf97c17 iscsi: pass SCSI status back for SG_IO
> I'll pull this in if there's another release, but doesn't look
> like a regression from 2.6.0 at least.

No, it was not there all the time.

>
>> 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

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

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).

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Michael Roth]

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.

> 
> Stefan

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 2396 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Peter Lieven]

> Am 13.09.2016 um 17:42 schrieb Stefan Hajnoczi <stefanha@redhat.com>:
> 
>> 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.

Peter

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

[Michael Roth]

Quoting Peter Lieven (2016-09-13 10:52:04)
> 
> 
> > Am 13.09.2016 um 17:42 schrieb Stefan Hajnoczi <stefanha@redhat.com>:
> > 
> >> 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.

> 
> Peter

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

[Peter Lieven]

> Am 13.09.2016 um 20:04 schrieb Michael Roth <mdroth@linux.vnet.ibm.com>:
> 
> Quoting Peter Lieven (2016-09-13 10:52:04)
>> 
>> 
>>>> Am 13.09.2016 um 17:42 schrieb Stefan Hajnoczi <stefanha@redhat.com>:
>>>> 
>>>> 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.

i am out of Office till Monday, but if I remember correctly I saw mutex errors (not segfaults) with 2.6.1 that were not there on 2.5.1.1. They happened while my colleagues where experimenting with a new VNC client. So its likely that a certain connect/disconnect pattern is the trigger. I am not sure if the 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 

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

[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 <stefanha@redhat.com>:
>>>
>>>> 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.

BTW, meanwhile another vnc bugfix popped up:

vnc: fix qemu crash because of SIGSEGV

BR,

Peter

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

[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<stefanha@redhat.com>:
>>>>
>>>>> 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.

Peter

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

[Peter Lieven]

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<stefanha@redhat.com>:
>>>>>
>>>>>> 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.


Peter

Re: [Qemu-devel] [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 <stefanha@redhat.com>:
> 
> 
>                         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

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

[Peter Lieven]

Am 28.09.2016 um 21:52 schrieb 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 <stefanha@redhat.com>:
>>
>>
>>                          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.

No, no futher issues.

Reproducer: Open Qemu with a Live CD of your favorite OS (with GUI). Connect via VNC Open Youtube. Play a video and disconnect VNC.

Peter