| Summary: | VGA devices don't work properly if attached to a pci-bridge | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | jingzhao <jinzhao> | ||||
| Component: | qemu-kvm-rhev | Assignee: | Gerd Hoffmann <kraxel> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Guo, Zhiyi <zhguo> | ||||
| Severity: | medium | Docs Contact: | Jiri Herrmann <jherrman> | ||||
| Priority: | medium | ||||||
| Version: | 7.3 | CC: | chayang, jsuchane, juzhang, knoel, michen, mst, phrdina, virt-maint, yduan, zhguo | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Known Issue | |||||
| Doc Text: |
Cause:
Emulated VGA devices don't work correctly if attached to a pci-bridge
Consequence:
The OS may start with a limited resolution or color palete or show other display abnormalities.
Workaround (if any):
libvirt will only attach emulated VGA devices to a pci-bridge under very specific situations, where the user has manually assigned other devices to the preferred PCI address 0000:00:01:0 or if all PCI root ports are used. The workaround is to leave the preferred PCI address available for the VGA device.
Result:
Everything works well.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-06-13 12:42:38 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: | |||||
| Attachments: |
|
||||||
Fundamental issue is that the vbe registers (at ioport 0x1ce) can not be accessed when the vga device is located behind a pci bridge. The vgabios depends on them though for highres modes. Without them only the standard vga modes are available. Windows appears to run at 640x480, probably in 256 colors mode with a grayscale palette. So, what can we do about it? First, the qemu stdvga provides a alternative way to access the registers. Since qemu 2.1 there is a mmio bar which can be used to access both vga and vbe registers. That continues to work with the device behind a pci bridge. So things can be fixed on the guest side. Which did already happen in some cases: * The linux kernel driver (bochs-drm.ko) uses it. * OVMF video driver uses it too. So you can install windows with ovmf instead of seabios (but display resolution can't be switched at runtime then, you have to pick the resolution you want in the firmware setup instead). * For vgabios it is hard to do though because the mmio bar can't be reached easily in real mode. Second, we can pass through the vbe registers together with the vga registers in case the PCI_BRIDGE_CTL_VGA flag is set. Clearly non-standard behavior, so not sure this is a good idea, even though I don't expect bad side effects from that. mst? Third, we can just declare vga devices behind pci bridges unsupported, or unsupported with seabios. I'm inclined to say let's make this unsupported. Why do we need to put it behind a bridge? I think libvirt will never create a vga display behind a bridge and I don't see a reason for users to manually edit the XML to make this change. If the above assumptions are correct, then we could simply close this BZ as WONTFIX. Jarda: please validate the assumption about libvirt. (In reply to Ademar Reis from comment #5) > I think libvirt will never create a vga display behind a bridge and I don't > see a reason for users to manually edit the XML to make this change. > > If the above assumptions are correct, then we could simply close this BZ as > WONTFIX. > Pavel, can you please elaborate more if the above scenario is somehow handled by libvirt? Thanks. Libvirt can put VGA video device behind PCI-brige. The behavior depends on the used machine type: For i440fx: If all slots in pci-root controller are already used For q35: If the preferred PCI address 0000:00:01:0 is already taken by any other device because libvirt handles VGA device as PCI only. In most cases libvirt will put the VGA video device at the preferred PCI address, because usually users don't specifies the PCI addresses by themselves but it can happen. |
Created attachment 1198476 [details] screen shot Description of problem: VGA display abnormality when vga device attach to pci-bridge Version-Release number of selected component (if applicable): qemu-kvm-rhev-2.6.0-22.el7.x86_64 host kernel:3.10.0-503.el7.x86_64 guest: win10.64 (en_windows_10_enterprise_version_1607_updated_jul_2016_x64_dvd_9054264.iso) How reproducible: 3/3 Steps to Reproduce: 1.Boot guest with VGA device which attach to pci-bridge /usr/libexec/qemu-kvm \ -M pc \ -cpu SandyBridge \ -nodefaults -rtc base=utc \ -m 4G \ -smp 2,sockets=2,cores=1,threads=1 \ -enable-kvm \ -name rhel7.3 \ -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 \ -nodefaults \ -serial unix:/tmp/serial0,server,nowait \ -boot menu=on \ -bios /usr/share/seabios/bios.bin \ -chardev file,path=/home/seabios.log,id=seabios \ -device isa-debugcon,chardev=seabios,iobase=0x402 \ -qmp tcp:0:6666,server,nowait \ -drive file=/home/win10.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop \ -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \ -device virtio-net-pci,netdev=tap10,mac=9a:6a:6b:6c:6d:6e -netdev tap,id=tap10 \ -device pci-bridge,bus=pci.0,id=bridge2,chassis_nr=3 \ -device VGA,id=video0,bus=bridge2,addr=0x6 \ -vnc :2 \ -monitor stdio \ Actual results: VGA display abnormality when vga device attach to pci-bridge, please check the attachment (screen shot) Expected results: VGA display normally Additional info: Not a regression issue, because I can reproduce the issue on qemu-kvm-rhev-2.3.0-31.el7_2.21.x86_64