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.
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=22361052 kraxel@rhel8 ~# /usr/libexec/qemu-kvm -device bochs-display qemu-kvm: -device bochs-display: failed to find romfile "vgabios-bochs-display.bin" Oops, we need a seabios update too ...
clarification on seabios support (cut+paste from email reply): bochs-display is useful because it has a much smaller attach surface than VGA. That applies to seabios too. The difference is that UEFI guests typically[1] don't expect VGA hardware and will use the EFI GOP for boot display. So I think we can consider to replace VGA with bochs-display *by default* for UEFI. For BIOS guests things are a bit more tricky. A typical rhel/fedora installation uses text mode (vgacon) for early boot display, which does not work with bochs-display. Any vgabios output (seabios/ipxe/grub) will work, and as soon as the bochs drm driver is loaded the framebuffer console will work too. And you can add a vga=<...> to your boot loader config to use vesafb+fbcon instead of vgacon to see boot messages before bochs-drm loads. So it is usable, but has some rough edges and I don't think we should push it.
Package used: qemu-kvm-4.0.0-6.module+el8.1.0+3736+a2aefea3.x86_64 seabios-bin-1.12.0-4.module+el8.1.0+3876+ec1667b7.noarch edk2-ovmf-20190308git89910a39dcfd-6.el8.noarch kernel-4.18.0-129.el8.x86_64(host & VM) qemu option used: ... -machine pc-q35-rhel8.0.0 ... -device bochs-display -vnc 0.0.0.0:1 ... scenarios tested: 1)Boot rhel 8.1 in multi-user.target, I can change grub setting without problem. During system boot, before driver attach to bochs-vga, dmesg cannot output to remote-viewer, after driver attached, demsg can be outputed to remote-viewer. 2)Inside vm, can find the bochs-vga from lspci: # lspci -v -s 00:01.0 00:01.0 Display controller: Device 1234:1111 (rev 02) Subsystem: Red Hat, Inc. Device 1100 Flags: fast devsel Memory at fb000000 (32-bit, prefetchable) [size=16M] Memory at fea08000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at fea00000 [disabled] [size=32K] Capabilities: [80] Express Root Complex Integrated Endpoint, MSI 00 Kernel driver in use: bochs-drm Kernel modules: bochs_drm 3)Boot vm to gnome environment, desktop and mouse cursor rendered correctly, change some resolutions(1280 x 960, 1280 x 1024, 1920 x 1080), resolution can be applied successfully and no corruptions found. 4)Play HD video inside VM, video can be rendered correctly Test against UEFI rhel 8.1 VM with above scenarios, results are similar.
Boot windows 10 vm with bochs-display, windows 10 VM can boot normally. VM boot UI can be displayed through bochs-display + vnc normally. Check the display resolution inside vm: bios type: resolutions: seabios 1024x768(used by VM) 800x600 edk2-ovmf 800x600(used by VM) Play video inside vm works normally
Try to migrate VM to another host, migration is always failed with message: error: internal error: qemu unexpectedly closed the monitor: 2019-08-12T01:05:23.505087Z qemu-kvm: get_pci_config_device: Bad config data: i=0x605 read: 55 device: 56 cmask: 32 wmask: 0 w1cmask:34 2019-08-12T01:05:23.505187Z qemu-kvm: Failed to load PCIDevice:config 2019-08-12T01:05:23.505206Z qemu-kvm: Failed to load bochs-display:pci 2019-08-12T01:05:23.505223Z qemu-kvm: error while loading state for instance 0x0 of device '0000:00:01.0/bochs-display' 2019-08-12T01:05:23.510966Z qemu-kvm: load of migration failed: Invalid argument This behavior can be reproduced on both rhel8.1 and win10 vm, bios type doesn't make any difference.
Hi Gerd, Please help to check comment 9 - 11. In comment 10, is it an expected behavior? And does bochs-display support migration currently? BR/ Zhiyi
http://brew-task-repos.usersys.redhat.com/repos/scratch/ghoffman/qemu-kvm/4.0.0/6.el8.bz1707118.7/ https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=23009768
(In reply to Gerd Hoffmann from comment #14) > http://brew-task-repos.usersys.redhat.com/repos/scratch/ghoffman/qemu-kvm/4. > 0.0/6.el8.bz1707118.7/ > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=23009768 Cannot reproduce migration failure with this build, both rhel8.1 and win10 vm have been tested
Fix committed upstream 5e7bcdcfe69ce0fad66012b2cfb2035003c37eef
Can reproduce migration failure with qemu-kvm-4.1.0-1.module+el8.1.0+3966+4a23dca1.x86_64.
A new version has been sent. Moving to POST.
Since it's still in the errata, moving to ON_QA for testing.
Given no new issues found during testing and remain questions have been answered by comment 27 and 29, mark the bug 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-2019:3723