Bug 1247479

Summary: display mess when boot a win2012-r2-64 guest with -vga std
Product: Red Hat Enterprise Linux 7 Reporter: Yanhui Ma <yama>
Component: qemu-kvm-rhevAssignee: Gerd Hoffmann <kraxel>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 7.2CC: areis, cfergeau, dblechte, eglynn, ghammer, huding, juzhang, knoel, lijin, lmiksik, mazhang, pezhang, rbalakri, sstutsma, virt-maint, vrozenfe, xfu, yama, yfu
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: x86_64   
OS: Windows   
Whiteboard:
Fixed In Version: qemu-kvm-rhev-2.3.0-27.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-04 16:52:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshot of guest none

Description Yanhui Ma 2015-07-28 06:33:43 UTC
Created attachment 1056936 [details]
screenshot of guest

Description of problem:
display mess when boot a win2012-r2-64 guest with -vga std, if with -vga qxl/cirrus, the issue is gone.
Version-Release number of selected component (if applicable):
3.10.0-297.el7.x86_64
qemu-kvm-rhev-2.3.0-13.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot a win2012-r2-64 guest with -vga std

/usr/libexec/qemu-kvm -M pc -cpu Opteron_G3 -m 4096 -smp 4,sockets=2,cores=2,threads=1 \

-drive if=none,id=drive-disk,cache=none,file=/mnt/win2012-64r2-virtio-scsi.qcow2,format=qcow2,aio=native -device virtio-scsi-pci,id=scsi0,bus=pci.0 -device scsi-hd,bus=scsi0.0,drive=drive-disk,id=disk \

-monitor stdio -spice port=5900,disable-ticketing -vga std \

-netdev tap,id=hostnet0,vhost=on,queues=8 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:42:0a:00,vectors=17,mq=on
2.remote-viewer spice://10.66.106.66:5900
3.

Actual results:

display mess in guest, see attachment.

Expected results:

display normally

Additional info:

if with -vga qxl/cirrus, the issue is gone

Comment 5 Christophe Fergeau 2015-08-10 08:52:08 UTC
Given that spice+qxl is working and spice+vga-std is giving a corrupted display, I'd look at a vga-std bug first... Is this happening with vnc too (vnc + vga-std) ?

Comment 6 Yanhui Ma 2015-08-11 05:37:32 UTC
(In reply to Christophe Fergeau from comment #5)
> Given that spice+qxl is working and spice+vga-std is giving a corrupted
> display, I'd look at a vga-std bug first... Is this happening with vnc too
> (vnc + vga-std) ?

vnc+vga-std works well, does not hit the issue.

Comment 8 Sandy Stutsman 2015-08-20 18:07:08 UTC
Hi All,

I've spent a little time looking at this issue.  We found the same artifacts when we tested a Windows 10 (build 9926) running on Fedora 22. However, the same build of Windows 10 running on RHEL-6 had *no* artifacts.

When I've seen screen corruption similar to this, it has often been a problem of dirty pixel tracking in QEMU.  And, in fact, I have a vague memory of just such an issue at another company a few years ago when we started testing the new Windows driver model WDDM (vs XPDM).  

So my SWAG here is that the issue is related to the way the newer driver model and QEMU interact.

Sandy

Comment 9 David Blechter 2015-08-24 11:45:08 UTC
based on the comment #8 moving to qemu-kvm for further investigation.
David

Comment 10 Gerd Hoffmann 2015-08-31 08:00:32 UTC
I don't think it is something with the vga emulation,
given that things work just fine with vnc.

What happens if you close and restart remote-viewer?
Corruption still there?

Comment 11 Yanhui Ma 2015-09-01 02:59:57 UTC
(In reply to Gerd Hoffmann from comment #10)
> I don't think it is something with the vga emulation,
> given that things work just fine with vnc.
> 
> What happens if you close and restart remote-viewer?
> Corruption still there?

yes, corruption still there when I close and restart remote-viewer.

Comment 12 Gerd Hoffmann 2015-09-01 11:34:41 UTC
Possibly related: bug 1257025

Does it still happen with '-spice port=5900,disable-ticketing,image-compression=off,zlib-glz-wan-compression=off,streaming-video=off' ?

Comment 13 Sandy Stutsman 2015-09-01 13:21:30 UTC
The corruptions looks like partial scan lines are slow to update.  In fact, sometimes just waiting a bit the corruption clears up.  I think that updates to the framebuffer being missed by qemu.

Comment 14 Yanhui Ma 2015-09-02 02:15:36 UTC
(In reply to Gerd Hoffmann from comment #12)
> Possibly related: bug 1257025
> 
> Does it still happen with '-spice
> port=5900,disable-ticketing,image-compression=off,zlib-glz-wan-
> compression=off,streaming-video=off' ?

yes, it still happen with '-spice port=5900,disable-ticketing,image-compression=off,zlib-glz-wan-compression=never,streaming-video=off -vga std'

Comment 15 Gerd Hoffmann 2015-09-02 12:53:58 UTC
(In reply to Sandy Stutsman from comment #13)
> The corruptions looks like partial scan lines are slow to update.  In fact,
> sometimes just waiting a bit the corruption clears up.  I think that updates
> to the framebuffer being missed by qemu.

Puzzling that it seems to happen with spice only though.

You can start a guest with both spice and vnc btw (by simply passing both -spice and -vnc args to qemu), then connect with via both vnc and spice at the same time.  What happens then?

Do you have a usb-tablet connected to the guest?
If not: any change in behaviour if you do?

Upgraded my win8 guest to win10, tried to reproduce, failed.  "Microsoft Basic Display Adapter" in use according to Device Manager.  Same for you?

Comment 16 Uri Lublin 2015-09-04 08:54:09 UTC
*** Bug 1257843 has been marked as a duplicate of this bug. ***

Comment 17 Yanhui Ma 2015-09-06 08:34:22 UTC
(In reply to Gerd Hoffmann from comment #15)
> (In reply to Sandy Stutsman from comment #13)
> > The corruptions looks like partial scan lines are slow to update.  In fact,
> > sometimes just waiting a bit the corruption clears up.  I think that updates
> > to the framebuffer being missed by qemu.
> 
> Puzzling that it seems to happen with spice only though.
> 
> You can start a guest with both spice and vnc btw (by simply passing both
> -spice and -vnc args to qemu), then connect with via both vnc and spice at
> the same time.  What happens then?

If start a guest with both spice and vnc (-spice port=5900,disable-ticketing -vnc :2 -vga std) and connect with via both vnc and spice at the same time.

remote-viewer vnc://10.66.106.85:5902----> works well
remote-viewer spice://10.66.106.85:5900------>corruption still there

> 
> Do you have a usb-tablet connected to the guest?
> If not: any change in behaviour if you do?

no usb-tablet.
after connecting the guest via spice, open *This PC* or other windows, move mouse in *This PC* window, the corruption will appear. if moving mouse in the Desktop, it works well.


> 
> Upgraded my win8 guest to win10, tried to reproduce, failed.  "Microsoft
> Basic Display Adapter" in use according to Device Manager.  Same for you?

Yes, "Microsoft Basic Display Adapter" in use according to Device Manager.

Comment 18 Gerd Hoffmann 2015-09-18 10:27:41 UTC
> Upgraded my win8 guest to win10, tried to reproduce, failed.  "Microsoft
> Basic Display Adapter" in use according to Device Manager.  Same for you?

Checked again, now it reproduces.  Strange.

Bisected to commit "0002a51 ui/spice: Support shared surface for most pixman 
formats"

Actual root cause is commit "555e72f spice: rework mirror allocation, add no-resize fast path" though.

Comment 19 Gerd Hoffmann 2015-09-18 10:36:51 UTC
https://patchwork.ozlabs.org/patch/519231/

Comment 21 Gerd Hoffmann 2015-09-18 11:17:54 UTC
http://people.redhat.com/ghoffman/bz1247479/

Comment 23 Miroslav Rezanina 2015-09-30 07:17:26 UTC
Fix included in qemu-kvm-rhev-2.3.0-27.el7

Comment 25 Pei Zhang 2015-09-30 10:20:31 UTC
***Reproduced***:
Host:
Kernel:3.10.0-320.el7.x86_64
qemu-kvm-rhev:qemu-kvm-rhev-2.3.0-23.el7.x86_64

Guest:win2012r2

Steps:
1.1 boot guest with '-vag std', the screen of guest displays mess
# /usr/libexec/qemu-kvm -name win2012r2 -machine pc-i440fx-rhel7.2.0,accel=kvm \
-cpu SandyBridge -m 4G,slots=256,maxmem=40G -numa node \
-smp 4,sockets=2,cores=2,threads=1 \
-uuid 82b1a01e-5f6c-4f5f-8d27-3855a74e6b6b \
-netdev tap,id=hostnet0 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=12:54:00:5c:88:6d \
-vga std \
-spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on \
-monitor stdio \
-serial unix:/tmp/monitor,server,nowait \
-qmp tcp:0:5555,server,nowait \
-drive file=/home/win2012r2,if=none,id=drive-scsi-disk0,format=qcow2,cache=none,werror=stop,rerror=stop \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,drive=drive-scsi-disk0,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk0 \

1.2. boot guest with '-vga qxl', the guest screen is OK.

So this bug has been reproduced.


***Verified***:
Host:
Kernel:3.10.0-320.el7.x86_64
qemu-kvm-rhev:qemu-kvm-rhev-2.3.0-27.el7.x86_64

Guest:win2012r2

Steps:
2.1 boot guest with '-vag std', the guest screen is OK.
same step with step 1.1.

The guest screen works well, So this bug has been fixed.

Comment 26 juzhang 2015-10-08 01:56:47 UTC
According to comment25, set this issue as verified.

Comment 28 errata-xmlrpc 2015-12-04 16:52:35 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/RHBA-2015-2546.html