My first guess would be that the VNC connection is bound to one of the display devices, but the guest has chosen to use the other one by default.  I think qemu has a way of switching between multiple logical screens in its GUI, but I don't remember how immediately.

Hi Zhengtong,
I've got two questions:
1) Which kernel version are you using for your guest?
2) Does it work for you on x86 if you specify the devices this way on the command line? (i.e. "-device virtio-gpu-pci" first, then "-device virtio-vga" second)

So to keep things simple first, I'm currently trying to start QEMU only with the virtio-gpu-pci device, and not with the virtio-vga device, like this:

/usr/libexec/qemu-kvm -enable-kvm -nodefaults -serial stdio -vnc :10 \
  -device virtio-gpu-pci -hda /var/lib/libvirt/images/guest.img \
  -device pci-ohci -device usb-kbd -device usb-mouse

However, with the current downstream QEMU (qemu-kvm-rhev-2.6.0-25.el7), the guest fails to initialize the graphics card, and there is an error message in the
dmesg output like this:

# dmesg -t | grep virtio
virtio-pci 0000:00:00.0: BAR 4: can't reserve [mem 0x10120000000-0x101207fffff pref]
virtio-pci: probe of 0000:00:00.0 failed with error -16

But if I use upstream QEMU (v2.7.0-217-g7263da7) instead, the guest succeeds in initializing the graphics card after booting up. dmesg output looks here like this:

# dmesg -t | grep virtio
[drm] pci: virtio-gpu-pci detected
[drm] virtio vbuffers: 80 bufs, 192B each, 15kB total.
virtio_gpu virtio0: fb0: virtiodrmfb frame buffer device
[drm] Initialized virtio_gpu 0.0.1 0 on minor 0

With the following upstream QEMU commit, the Linux kernel in the guest is able to initialize the virtio-gpu-pci device again:

    d9997d89a4a09a330a056929d06d4b7b0b7a8239
    virtio-pci: reduce modern_mem_bar size

Looks like Marcel is already in progress of backporting that patch for BZ 1365613, so adding that BZ as a dependency for this one here.

Hi. sorry for the late response.
Guest kernel : kernel-3.10.0-505.el7

For the same command line on x86, there is no problem to show the graphics window.  That's why I put "[ppc64le]" to the bug title.

Work in progress: With the following SLOF patch, I get at least some graphical output when I specify the virtio-vga first on the command line:

 https://patchwork.ozlabs.org/patch/693179/

Colors are still wrong when Linux is trying to use the graphics card, though, and if I specify the virtio-gpu device first, I still do not get any output at all, so there are some more bugs to be fixed here...

(In reply to Thomas Huth from comment #8)
> Colors are still wrong when Linux is trying to use the graphics card,

Can be related to BZ1375153

You should check the driver is loaded (instead of the generic VGA one).

(In reply to Laurent Vivier from comment #9)
> (In reply to Thomas Huth from comment #8)
> > Colors are still wrong when Linux is trying to use the graphics card,
> 
> Can be related to BZ1375153
> 
> You should check the driver is loaded (instead of the generic VGA one).

Thanks, very good hint, you're right, I did not use a kernel with that fix. So the color problem is then solved, too.
However, I still have problems with "-device virtio-gpu-pci -device virtio-vga" ... The virtio-gpu device only works if I omit the virtio-vga. So there is still something wrong here...

OK, I've spent quite some time now with this issue to figure out the difference between x86 and ppc here.

First, I've got to say that the patch mentioned in comment #8 is needed here to fix a real problem. The patch has been accepted upstream now:

 http://git.qemu.org/?p=SLOF.git;a=commitdiff;h=38bf852e73ce6f0ac801d

So I think we should use this ticket to track the inclusion of that patch.

Now, with that patch (and the fix for BZ 1375153) everything looks fine if you start QEMU with "-device virtio-vga -device virtio-gpu-pci", you get output in the VNC window as expected.
But if you specify the virtio-gpu-pci device first, the VNC window initially stays black. This is because on ppc64, the Linux kernel seems to prefer virtio-vga over virtio-gpu for some reasons. However, you can switch to the second graphics card in the VNC window by pressing CTRL-ALT-2 and you get the normal output there, so basically everything is working fine. It's just that you get a slightly different behavior on x86 - there the Linux kernel seems to prefer the first graphics card instead, no matter whether it's virtio-vga or virtio-gpu. But if you press CTRL-ALT-2 in the x86 VNC window, you also get a black screen, i.e. Linux always only activates one of the two graphic cards and never uses both, so the black window on ppc64 is not a real bug, but just slightly different behaviour with the preferences of the graphic cards.

Now for the question why Linux is preferring virtio-vga over virtio-gpu on ppc64 but not on x86, I haven't found an ultimate answer. Part of the issue seems to be that the ppc64 code in the kernel tries to be smart and prefers to activate the graphics card that has been used by the firmware already. Since we've only got support for virtio-vga in SLOF, but not for virtio-gpu, the kernel seems to prefer that one. Another reason could be the order of the device-tree nodes - QEMU currently presents the PCI nodes in reverse order to the guests. There was a patch to fix this one year ago (https://patchwork.ozlabs.org/patch/549925/) but it had not been accepted, since the order should theoretically not matter - well, here it might matter.

Anyway, once the SLOF issue mentioned at the beginning is fixed, I think we do not have a real bug here anymore (since you can switch to the console with the output by pressing CTRL-ALT-2). And since it is quite unlikely that a user uses two graphic cards anyway, I stop further investigation here for now. But if you think that we should investigate the different behaviour further, we should likely open a new BZ in the "kernel" category instead.

For the records, in case somebody wants to debug this issue further: You can force Linux to use the virtio-gpu device by applying the patch from https://patchwork.ozlabs.org/patch/549925/ to QEMU, and then typing something like this at the SLOF prompt:

 dev /pci/vga   
 s" device_type" delete-property

Linux then does not recognize the virtio-vga device as preferred "display" device from the firmware anymore and uses the first PCI graphics card instead. With the PCI device-tree in-order patch enabled, this is then the virtio-gpu graphics card.

> you also get a black screen, i.e. Linux always only activates one of the two
> graphic cards and never uses both, so the black window on ppc64 is not a
> real bug, but just slightly different behaviour with the preferences of the
> graphic cards.

Just FYI: It is possible to configure linux to use multiple display devices for a multiseat configuration, see docs/multiseat.txt.  gdm will show a login screen on each display then.  fbcon will appear on one display device only though.

Also note that qemu can have multiple vnc server instances, and they can be linked to display devices, so you can do this ...

qemu $lots_of_args
  -device virtio-gpu-pci,id=video1
  -device virtio-vga,id=video2
  -vnc :0,display=video2

... and the vnc server will show the virtio-vga so you don't need to mess with hotkeys to see it.  

Not that it is that useful in this specific case, as virtio-gpu-pci isn't shown anywhere then, so it is kida pointless to add the device in the first place ...

Thanks a lot for that additional information, Gerd! After reading the "fbcon" keyword, I also remembered that there are some related kernel parameters, and indeed, if you specify "fbcon=map:10" as kernel parameter, you can at least swap the preference of the kernel for the graphic cards - it then also outputs the console text to virtio-gpu instead of virtio-vga.

Fixed by rebase

The following is the step of verification:

1.Version:
Host:3.10.0-623.el7.ppc64le
Qemu:qemu-kvm-rhev-2.9.0-0.el7.mrezanin201703210848
SLOF:SLOF.noarch  20170303-1.git66d250e.el7

2.Steps to Verify:
Same to the top Description

3.Actual results:
VNC showing: "Guest has not initialized the display  in vnc"

This fixed is failed.

As mentioned in earlier comments, Linux has a slightly different priority order of using the graphic cards on ppc compared to x86. So to get output here, you've got to do one (but not all) of the following points:

- Press CTRL-ALT-2 in the VNC window to switch to the second graphics card (see comment 11)

- Bind the VNC session to the VGA graphics card with "-vnc :0,display=video2" (see comment 13)

- Use fbcon=map:10" as kernel parameter (see comment 14)

Please try again with one of the above three possibilities - if you get output in that case, I think it should be fine to mark this bug as verified.

(In reply to Thomas Huth from comment #20)
> As mentioned in earlier comments, Linux has a slightly different priority
> order of using the graphic cards on ppc compared to x86. So to get output
> here, you've got to do one (but not all) of the following points:
> 
> - Press CTRL-ALT-2 in the VNC window to switch to the second graphics card
> (see comment 11)
> 
> - Bind the VNC session to the VGA graphics card with "-vnc
> :0,display=video2" (see comment 13)
> 
> - Use fbcon=map:10" as kernel parameter (see comment 14)
> 
> Please try again with one of the above three possibilities - if you get
> output in that case, I think it should be fine to mark this bug as verified.

Hi Thomas Huth:

Thank you for answering. I have tried the 1th and 2th points, and the guest can successfully display in vnc. so this bug is fixed.Mark the status of bug as verified.

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://access.redhat.com/errata/RHBA-2017:2093