+++ This bug was initially created as a clone of Bug #1707119 +++ +++ This bug was initially created as a clone of Bug #1707118 +++ The bochs-display device is a simple display device which is similar to VGA but without legacy emulation. It should be used if the guest is running with UEFI. This changelog from this upstream commit in QEMU has more details: commit 765c94290863eef1fc4a67819d452cc13b7854a1 Author: Gerd Hoffmann <kraxel> Date: Tue May 22 18:50:55 2018 +0200 hw/display: add new bochs-display device After writing up the virtual mdev device emulating a display supporting the bochs vbe dispi interface (mbochs.ko) and seeing how simple it actually is I've figured that would be useful for qemu too. So, here it is, -device bochs-display. It is basically -device VGA without legacy vga emulation. PCI bar 0 is the framebuffer, PCI bar 2 is mmio with the registers. The vga registers are simply not there though, neither in the legacy ioport location nor in the mmio bar. Consequently it is PCI class DISPLAY_OTHER not DISPLAY_VGA. So there is no text mode emulation, no weird video modes (planar, 256color palette), no memory window at 0xa0000. Just a linear framebuffer in the pci memory bar. And the amount of code to emulate this (and therefore the attack surface) is an order of magnitude smaller when compared to vga emulation. Compatibility wise it works with OVMF (latest git master). The bochs-drm.ko linux kernel module can handle it just fine too. So UEFI guests should not see any functional difference to VGA. --- Additional comment from Jonathon Jongsma on 2019-08-23 20:14:31 UTC --- Just to clarify, is this simply a matter of changing the default video device for domains that are configured for UEFI when no other video device is specified? Or is there something else needed here? --- Additional comment from Ademar Reis on 2019-08-23 22:19:12 UTC --- (In reply to Jonathon Jongsma from comment #1) > Just to clarify, is this simply a matter of changing the default video > device for domains that are configured for UEFI when no other video device > is specified? Or is there something else needed here? That's my understanding. Gerd, please confirm. --- Additional comment from Gerd Hoffmann on 2019-08-26 07:06:34 UTC --- (In reply to Jonathon Jongsma from comment #1) > Just to clarify, is this simply a matter of changing the default video > device for domains that are configured for UEFI when no other video device > is specified? Or is there something else needed here? That is correct. --- Additional comment from Jonathon Jongsma on 2019-08-30 14:34:38 UTC --- I proposed a change for libvirt, but it was decided that this is really a better decision for a higher-level management app in conjunction with libosinfo. Re-assigning this bug to osinfo for now. Thread: https://www.redhat.com/archives/libvir-list/2019-August/msg01300.html --- Additional comment from Fabiano Fidêncio on 2019-09-17 11:08:23 UTC --- So, what we've decided to do on libosinfo/osinfo-db side is just track whether the system supports UEFI or not. Then, management applications will have to do the logic on selecting "bochs display" whenever it makes sense. ---------------------------------------------------------------------------- I've removed comments which were not relevant for implementing this feature. ----------------------------------------------------------------------------
Some vga & display device background: https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/
Created attachment 1756173 [details] engine.log
Created attachment 1756175 [details] ui.log
Reassigning, see https://bugzilla.redhat.com/show_bug.cgi?id=1753645#c2
The changes were done in 4.4.5 already, will be verified on 4.4.6
Verified: ovirt-engine-4.4.5.11-0.1.el8ev vdsm-4.40.50.8-1.el8ev.x86_64 qemu-kvm-5.1.0-20.module+el8.3.1+9918+230f5c26.x86_64 libvirt-daemon-6.6.0-13.module+el8.3.1+9548+0a8fede5.x86_64 Verification scenario: Polarion test case added to external trackers
This bugzilla is included in oVirt 4.4.6 release, published on May 4th 2021. Since the problem described in this bug report should be resolved in oVirt 4.4.6 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.