Bug 1134980

Note that the first display is correctly registered in qemu upstream.

Can be reproduced with 'qemu-kvm -spice disable-ticketing,port=5931 -device qxl'

The Spice assert() would not happen if the first display would be exported.

(the assert() is solved in original bug)

Sounds like a bug 987312 duplicate, please check.

Moving to qemu-kvm-rhev.  Should have picked up the fix by 2.1 rebase.
Please verify.

For this bug reproduce:
This bug was clone of bz1058625 which is a spice bug, and component has changed from qemu-kvm to qemu-kvm-rhev, so just use qemu-kvm and old spice could reproduce it.

Here is my test:

Host:
qemu-kvm-1.5.3-83.el7.x86_64
spice-server-0.12.4-6.el7.x86_64

Boot guest with following command line, qemu-kvm aborted.
gdb --args /usr/libexec/qemu-kvm \
-M pc \
-cpu SandyBridge \
-m 2G \
-smp 4,sockets=120,cores=2,threads=1,maxcpus=240 \
-enable-kvm \
-name rhel7 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-rtc base=localtime,clock=host,driftfix=slew \
-nodefaults \
-monitor stdio \
-qmp tcp:0:5555,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-monitor unix:/tmp/monitor0,server,nowait \
-usb \
-device usb-tablet,id=tablet0 \
-global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 \
-serial unix:/tmp/ttyS0,server,nowait \
-monitor unix:/tmp/monitor-unix0,server,nowait \
-netdev tap,id=hostnet0,vhost=on \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:00:B6:40:22,bus=pci.0,addr=0x3 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \
-drive file=/root/rhel7-64.raw,if=none,id=drive-virtio-disk1,format=raw,cache=none,werror=stop,rerror=stop,aio=native \
-device virtio-blk-pci,scsi=off,bus=pci.0,drive=drive-virtio-disk1,id=virtio-disk1,bus=pci.0,addr=0x6,bootindex=0,ioeventfd=on \
-spice port=5901,disable-ticketing \
-device qxl,id=video1,bus=pci.0,addr=0x7,vram_size=134217728 -device qxl,id=video2,bus=pci.0,addr=0x8,vram_size=134217728 -device qxl,id=video3,bus=pci.0,addr=0x9,vram_size=134217728 -device qxl,id=video4,bus=pci.0,addr=0xa,vram_size=134217728 \


Update qemu to qemu-kvm-rhev-2.1.2-16.el7.x86_64 re-test this bug.

Host:
qemu-kvm-rhev-2.1.2-16.el7.x86_64
3.10.0-213.el7.x86_64
spice-server-0.12.4-8.el7.x86_64

Guest:
3.10.0-213.el7.x86_64

Steps:
1. Boot guest with 4 qxl device.
-spice port=5901,disable-ticketing \
-device qxl,id=video1,bus=pci.0,addr=0x7,vram_size=134217728 -device qxl,id=video2,bus=pci.0,addr=0x8,vram_size=134217728 -device qxl,id=video3,bus=pci.0,addr=0x9,vram_size=134217728 -device qxl,id=video4,bus=pci.0,addr=0xa,vram_size=134217728

2. Connect guest by remote-viewer.

Result:
1. Guest boot up, but spice shows black screen with just a underline flash if set guest graphical mode.
2. Can login guest with text mode.

notice:
The command line without -vga device or -device qxl-vga.

Gerd, If qemu export first vga display to spice, guest display supposed to work.
could you please have a look at this bug if work as expected?

Thanks,
Mazhang.

> Steps:
> 1. Boot guest with 4 qxl device.
> -spice port=5901,disable-ticketing \
> -device qxl,id=video1,bus=pci.0,addr=0x7,vram_size=134217728 -device
> qxl,id=video2,bus=pci.0,addr=0x8,vram_size=134217728 -device
> qxl,id=video3,bus=pci.0,addr=0x9,vram_size=134217728 -device
> qxl,id=video4,bus=pci.0,addr=0xa,vram_size=134217728
> 
> 2. Connect guest by remote-viewer.
> 
> Result:
> 1. Guest boot up, but spice shows black screen with just a underline flash
> if set guest graphical mode.
> 2. Can login guest with text mode.

Looks like the guest has trouble dealing with that setup.
Can you attach Xorg.log?

Created attachment 967521 [details]
Xorg.log

[    25.597] (EE) no screens found(EE)

Yep, that's it.  I think the xorg driver supports qxl-vga only, the multihead mode with secondary qxl devices was only ever used with windows guests.  So I suspect this setup simply lacks guest side support ...

(In reply to Gerd Hoffmann from comment #12)
> [    25.597] (EE) no screens found(EE)
> 
> Yep, that's it.  I think the xorg driver supports qxl-vga only, the
> multihead mode with secondary qxl devices was only ever used with windows
> guests.  So I suspect this setup simply lacks guest side support ...

Gerd, Is this a configuration problem, How do I setup guest to support qxl devices? if not, should I open a new bz trace it?

Thanks,
Mazhang.

(In reply to mazhang from comment #13)
> (In reply to Gerd Hoffmann from comment #12)
> > [    25.597] (EE) no screens found(EE)
> > 
> > Yep, that's it.  I think the xorg driver supports qxl-vga only, the
> > multihead mode with secondary qxl devices was only ever used with windows
> > guests.  So I suspect this setup simply lacks guest side support ...
> 
> Gerd, Is this a configuration problem, How do I setup guest to support qxl
> devices? if not, should I open a new bz trace it?

No.  Additional '-device qxl' devs is the old fashioned way to do multihead.  It's deprecated since spice got support for multihead with a single '-device qxl-vga'.

(In reply to Gerd Hoffmann from comment #14)
> (In reply to mazhang from comment #13)
> > (In reply to Gerd Hoffmann from comment #12)
> > > [    25.597] (EE) no screens found(EE)
> > > 
> > > Yep, that's it.  I think the xorg driver supports qxl-vga only, the
> > > multihead mode with secondary qxl devices was only ever used with windows
> > > guests.  So I suspect this setup simply lacks guest side support ...
> > 
> > Gerd, Is this a configuration problem, How do I setup guest to support qxl
> > devices? if not, should I open a new bz trace it?
> 
> No.  Additional '-device qxl' devs is the old fashioned way to do multihead.
> It's deprecated since spice got support for multihead with a single '-device
> qxl-vga'.

Summary:
1. After update qemu to qemu-kvm-rhev-2.1.2-16.el7.x86_64, qemu-kvm not crash any more.
2. Guest black screen with 4 qxl devices, but qxl device has deprecated.
So the test result was expected, set this bug as verified.
Any problem please let me know.

Thanks,
Mazhang.

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-2015-0624.html