Bug 1707118
Summary: | enable device: bochs-display (QEMU) | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | Ademar Reis <areis> | |
Component: | qemu-kvm | Assignee: | Gerd Hoffmann <kraxel> | |
Status: | CLOSED ERRATA | QA Contact: | Guo, Zhiyi <zhguo> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | --- | CC: | coli, ddepaula, jinzhao, juzhang, knoel, kraxel, lersek, mtessun, ppandit, virt-maint, yafu | |
Target Milestone: | rc | Keywords: | FutureFeature | |
Target Release: | 8.1 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | qemu-kvm-4.1.0-3.module+el8.1.0+4019+dbfaedf9 | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1707119 1724098 (view as bug list) | Environment: | ||
Last Closed: | 2019-11-06 07:14:47 UTC | Type: | Feature Request | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | 1724098 | |||
Bug Blocks: | 1707119, 1725664, 1753634, 1753637, 1753641, 1753644, 1753645, 1753670, 1754394, 1754396, 1919805 |
Description
Ademar Reis
2019-05-06 20:27:41 UTC
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 |