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 
:


 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 

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

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:


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

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

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

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


signature.asc
Description: PGP signature

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]

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


signature.asc
Description: PGP signature

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

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