Bug 1355730 - spice-gtk shows outdated screen state after migration [qemu-kvm]
Summary: spice-gtk shows outdated screen state after migration [qemu-kvm]
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: 7.2
Assignee: Gerd Hoffmann
QA Contact: Guo, Zhiyi
URL:
Whiteboard:
Depends On: 1235732
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-12 11:32 UTC by Gerd Hoffmann
Modified: 2016-11-03 20:01 UTC (History)
15 users (show)

Fixed In Version: qemu-kvm-1.5.3-119.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1235732
Environment:
Last Closed: 2016-11-03 20:01:46 UTC
Target Upstream Version:


Attachments (Terms of Use)
reproducer video (368.72 KB, application/octet-stream)
2016-09-13 05:51 UTC, Guo, Zhiyi
no flags Details
video show bug fixed (244.86 KB, application/octet-stream)
2016-09-13 05:52 UTC, Guo, Zhiyi
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2585 normal SHIPPED_LIVE Moderate: qemu-kvm security, bug fix, and enhancement update 2016-11-03 12:09:03 UTC

Description Gerd Hoffmann 2016-07-12 11:32:52 UTC
+++ This bug was initially created as a clone of Bug #1235732 +++

Description of problem:
spice-gtk shows outdated screen state after migration.

Version-Release number of selected component (if applicable):
client RHEL 7.2:
spice-gtk3-0.26-3.el7.x86_64
virt-viewer-2.0-3.el7.x86_64
host RHEL 7.2:
spice-server-0.12.4-9.el7.x86_64
qemu-kvm-1.5.3-93.el7.x86_64
guest RHEL 7.1 & 7.2:
Gnome-shell desktop environment, KMS driver

How reproducible:


Steps to Reproduce:
1. run an application for some time
2. close the application
3. migrate the VM

Actual results:
1. after migration, an old screen state is displayed for few dozen of seconds. when movement of some currently-existing window occurs, parts of ghost window start disappearing
2. after some time, the screen readjusts to the current state
3. after repeated migration, old screen state is displayed again

Expected results:
no caching artifacts occur

Additional info:

--- Additional comment from David Jaša on 2015-07-02 17:00:06 CEST ---

Example. What I did is:
0. connection established, migration started
1. started screencast
2. minimized Firefox in the guest (0:02)
3. migration finished, Firefox's guest appeared (0:13)
4. click into the desktop that pretends to be Firefox triggers update (0:20)
5. end of screencast

* Without click in point 4., the stale image would linger far longer.
* happens with rhel7 client and guest against rhel7 and fedora hosts, rhel6 wasn't tested (yet), no other guest was tested (yet)

--- Additional comment from Frediano Ziglio on 2015-07-13 15:26:25 CEST ---

Where does this stale image came? Was it before the screencast?

--- Additional comment from David Jaša on 2016-01-26 17:42 CET ---

(In reply to Frediano Ziglio from comment #2)
> Where does this stale image came? Was it before the screencast?

Yes, it's what was on the screen ~1 m before the migration. The bug is still present as of RHEL 7.2 (all of client/host/guest) as you can see in this full screencast (client and portal):
0:10 start of migration with static desktop
0:13 window layout change
0:24 migration finished, layout from before 0:13 is shown till desktop redraw
0:31 resuming video playback
0:44 start of another migration
1:03 (approx.) video gets choppy, migration gets stuck (bug 1247237)
1:07 video is paused, migration finishes, client displays pre-0:13 state again

--- Additional comment from Uri Lublin on 2016-01-28 12:58:26 CET ---

With upstream git code running on a Fedora-23 host:
  I can reproduce with Fedora-23 guest.
  But works-for-me with Windows 7 guest.

--- Additional comment from David Jaša on 2016-01-28 18:49:04 CET ---

RHEL 7 guest status @ 7.2 host:
7.0/KMS, 7.2/KMS - affected
7.2/UMS - not affected

--- Additional comment from Uri Lublin on 2016-06-10 01:00:32 CEST ---

I think the problem is in qemu-kvm, specifically reverting
commit e25139b34d27847ff19140adada77ea4c5398863 seems to solve this problem.

Moving to qemu-kvm component

--- Additional comment from Ademar Reis on 2016-06-21 21:23:52 CEST ---

(In reply to Uri Lublin from comment #6)
> I think the problem is in qemu-kvm, specifically reverting
> commit e25139b34d27847ff19140adada77ea4c5398863 seems to solve this problem.
> 
> Moving to qemu-kvm component

Gerd, please take a look.

commit e25139b34d27847ff19140adada77ea4c5398863
Author: Yonit Halperin <yhalperi@redhat.com>
Date:   Wed Feb 15 11:22:15 2012 +0200

    qxl: set only off-screen surfaces dirty instead of the whole vram
    
    We used to assure the guest surfaces were saved before migration by
    setting the whole vram dirty. This patch sets dirty only the areas
    that are actually used in the vram.
    
    Signed-off-by: Yonit Halperin <yhalperi@redhat.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

--- Additional comment from Gerd Hoffmann on 2016-06-22 10:09:19 CEST ---

(In reply to Ademar Reis from comment #7)
> (In reply to Uri Lublin from comment #6)
> > I think the problem is in qemu-kvm, specifically reverting
> > commit e25139b34d27847ff19140adada77ea4c5398863 seems to solve this problem.
> > 
> > Moving to qemu-kvm component
> 
> Gerd, please take a look.
> 
> commit e25139b34d27847ff19140adada77ea4c5398863
> Author: Yonit Halperin <yhalperi@redhat.com>
> Date:   Wed Feb 15 11:22:15 2012 +0200
> 
>     qxl: set only off-screen surfaces dirty instead of the whole vram
>     
>     We used to assure the guest surfaces were saved before migration by
>     setting the whole vram dirty. This patch sets dirty only the areas
>     that are actually used in the vram.
>     
>     Signed-off-by: Yonit Halperin <yhalperi@redhat.com>
>     Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

Doesn't handle primary surfaces correctly in case they are living in vram not ram.  Thats why it happens with newer (kms) linux guests only, all other guest drivers place the primary surface in ram.

--- Additional comment from Gerd Hoffmann on 2016-06-22 12:55:59 CEST ---

please test:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=11253184

patches:
http://git.engineering.redhat.com/git/users/ghoffman/rhel7/qemu-kvm-rhev.git/log/?h=bz1235732-qxl-migration

Comment 2 Miroslav Rezanina 2016-07-26 13:35:09 UTC
Fix included in qemu-kvm-1.5.3-119.el7

Comment 4 Guo, Zhiyi 2016-09-13 05:50:17 UTC
Reproduce this issue with qemu-kvm-1.5.3-118.el7.x86_64, rhel7.3 guest.

Record a video to show reproducer

Verify with qemu-kvm-1.5.3-123.el7.x86_64, a record video show bug fixed

Comment 5 Guo, Zhiyi 2016-09-13 05:51:31 UTC
Created attachment 1200350 [details]
reproducer video

Comment 6 Guo, Zhiyi 2016-09-13 05:52:42 UTC
Created attachment 1200351 [details]
video show bug fixed

Comment 7 Guo, Zhiyi 2016-09-13 05:53:29 UTC
Move to verified per comment 4 - 6

Comment 10 errata-xmlrpc 2016-11-03 20:01:46 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2585.html


Note You need to log in before you can comment on or make changes to this bug.