[Bug 1872863] Re: QEMU/KVM display is garbled when booting from kernel EFI stub due to missing bochs-drm module
Łukasz Zemczak
1872863 at bugs.launchpad.net
Fri May 8 07:30:13 UTC 2020
Hello Matthew, or anyone else affected,
Accepted kmod into bionic-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/kmod/24-1ubuntu3.4 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1872863
[Impact]
A recent grub2 SRU, LP #1864533, now forces the kernel to boot via the
kernel EFI stub whenever EFI is enabled. This causes problems for
QEMU/KVM virtual machines which use the VGA=std video device, as the
efifb driver yields an unreadable garbled screen. See the attached
image.
The correct framebuffer driver to use in this situation is bochs-drm,
and modprobing it from a HWE kernel fixes the issues.
bochs-drm is missing from Bionic since CONFIG_DRM_BOCHS was disabled in
LP #1378648 due to bochs-drm causing problems in a PowerKVM machine.
This problem appears to be fixed now, and bochs-drm has been re-enabled
for Disco and up, in LP #1795857 and has been proven safe.
This has also come up again in LP #1823152, as well as chatter on LP
#1795857 to get this enabled on Bionic.
The customer which is experiencing this issue cannot switch to VGA=qxl
as a workaround, and must use VGA=std, hence I suggest we re-enable
bochs-drm for Bionic.
[Fix]
I noticed on Focal, if you boot, the framebuffer is initially efifb:
[ 0.603716] efifb: probing for efifb
[ 0.603733] efifb: framebuffer at 0xc0000000, using 1876k, total 1875k
[ 0.603735] efifb: mode is 800x600x32, linelength=3200, pages=1
[ 0.603736] efifb: scrolling: redraw
[ 0.603738] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 0.604462] Console: switching to colour frame buffer device 100x37
[ 0.605829] fb0: EFI VGA frame buffer device
This soon changes to bochs-drm about a second later:
[ 0.935988] bochs-drm 0000:00:01.0: remove_conflicting_pci_framebuffers: bar 0: 0xc0000000 -> 0xc0ffffff
[ 0.937023] bochs-drm 0000:00:01.0: remove_conflicting_pci_framebuffers: bar 2: 0xc1c8c000 -> 0xc1c8cfff
[ 0.937776] checking generic (c0000000 1d5000) vs hw (c0000000 1000000)
[ 0.937776] fb0: switching to bochsdrmfb from EFI VGA
[ 0.939085] Console: switching to colour dummy device 80x25
[ 0.939117] bochs-drm 0000:00:01.0: vgaarb: deactivate vga console
[ 0.939210] [drm] Found bochs VGA, ID 0xb0c5.
[ 0.939212] [drm] Framebuffer size 16384 kB @ 0xc0000000, mmio @ 0xc1c8c000.
[ 0.941955] lpc_ich 0000:00:1f.0: I/O space for GPIO uninitialized
[ 0.942069] [TTM] Zone kernel: Available graphics memory: 2006780 KiB
[ 0.942081] [TTM] Initializing pool allocator
[ 0.942089] [TTM] Initializing DMA pool allocator
[ 0.943026] virtio_blk virtio2: [vda] 20971520 512-byte logical blocks (10.7 GB/10.0 GiB)
[ 0.944019] [drm] Found EDID data blob.
[ 0.944162] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:01.0 on minor 0
[ 0.944979] fbcon: bochs-drmdrmfb (fb0) is primary device
[ 0.947712] Console: switching to colour frame buffer device 128x48
On bionic, the framebuffer never changes from efifb, since the bochs-drm
kernel module is not built, and it is also present on the module banlist
in /etc/modprobe.d/blacklist-framebuffer.conf
bochs-drm needs to be enabled to be built in the kernel config, and
removed from the module blacklist in kmod.
[Testcase]
Create a new QEMU/KVM virtual machine, I used virt-manager. Before you
install the OS, check the box to modify settings before install. In the
"Overview" tab, enable EFI by setting the firmware to "UEFI x86_64:
/usr/share/OVMF/OVMF_CODE.secboot.fd".
Set the video device to qxl while you install Bionic. Once the install
is done, reboot, do a "apt update" and "apt upgrade", to ensure you have
grub2 2.02-2ubuntu8.15 installed.
Shut the VM down, and set the video device to VGA. Or VGA=std if you use
the QEMU command line.
Start the VM up, and the screen will be garbled. See attached picture.
If you install my test packages, which are available here:
https://launchpad.net/~mruffell/+archive/ubuntu/sf272653-test
Instructions to install (on a bionic system):
- 1) sudo add-apt-repository ppa:mruffell/sf272653-test
+ 1) Enable bionic-proposed
2) sudo apt-get update
3) sudo apt install linux-image-unsigned-4.15.0-96-generic linux-modules-4.15.0-96-generic linux-modules-extra-4.15.0-96-generic linux-headers-4.15.0-96-generic linux-headers-4.15.0-96 libkmod2 kmod
4) sudo reboot
5) uname -rv
4.15.0-96-generic #97+TEST272653v20200409b1-Ubuntu SMP Thu Apr 9 04:09:18 UTC 2020
If you reboot, the screen will be perfectly readable, since the bochs-
drm driver will be in use.
[Regression Potential]
We are enabling a display driver on Bionic which was previously
disabled, so there will be some virtual machines making the jump to
using bochs-drm since it would now be available.
I don't think that this is a bad thing, and in many ways will probably
end up improving some user's experience. Although there are two
scenarios where a regression could happen:
1 - frequently gamers use GPU passthrough to their kvm based virtual
machines, and I have seen them expect, or hardcode their kernel command
lines to disable the efifb driver. See https://passthroughpo.st
/explaining-csm-efifboff-setting-boot-gpu-manually/ Worst case scenario,
gamers will also need to disable bochs-drm as well. Since the PCI device
of the GPU is being passed through to the VM, I believe the kernel will
make the correct choice and load the GPU drivers, like noverau or
nvidia-drm instead.
2 - if the bug with PowerKVM machines isn't actually fixed in Bionic, it
will cause a regression on POWER. We just need to test this on POWER and
ensure that the bug in LP #1378648 was fixed. If not, then we could just
disable bochs-drm on POWER, leaving it enabled for all other archs.
Note: 2 has now been tested and verified working. See comment #7.
If a regression were to occur, it would only affect KVM machines that
use the built in SPICE graphics display. The screen would either not
show at all or be garbled. bochs-drm is limited only to kvm users, and
does not affect other virtualisation platforms like VMware or
Virtualbox. Instances will still be accessible via ssh, and work
normally.
** Changed in: kmod (Ubuntu Bionic)
Status: In Progress => Fix Committed
** Tags removed: verification-done-bionic
** Tags added: verification-needed verification-needed-bionic
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to kmod in Ubuntu.
https://bugs.launchpad.net/bugs/1872863
Title:
QEMU/KVM display is garbled when booting from kernel EFI stub due to
missing bochs-drm module
Status in kmod package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in kmod source package in Bionic:
Fix Committed
Status in linux source package in Bionic:
Fix Committed
Bug description:
BugLink: https://bugs.launchpad.net/bugs/1872863
[Impact]
A recent grub2 SRU, LP #1864533, now forces the kernel to boot via the
kernel EFI stub whenever EFI is enabled. This causes problems for
QEMU/KVM virtual machines which use the VGA=std video device, as the
efifb driver yields an unreadable garbled screen. See the attached
image.
The correct framebuffer driver to use in this situation is bochs-drm,
and modprobing it from a HWE kernel fixes the issues.
bochs-drm is missing from Bionic since CONFIG_DRM_BOCHS was disabled
in LP #1378648 due to bochs-drm causing problems in a PowerKVM
machine. This problem appears to be fixed now, and bochs-drm has been
re-enabled for Disco and up, in LP #1795857 and has been proven safe.
This has also come up again in LP #1823152, as well as chatter on LP
#1795857 to get this enabled on Bionic.
The customer which is experiencing this issue cannot switch to VGA=qxl
as a workaround, and must use VGA=std, hence I suggest we re-enable
bochs-drm for Bionic.
[Fix]
I noticed on Focal, if you boot, the framebuffer is initially efifb:
[ 0.603716] efifb: probing for efifb
[ 0.603733] efifb: framebuffer at 0xc0000000, using 1876k, total 1875k
[ 0.603735] efifb: mode is 800x600x32, linelength=3200, pages=1
[ 0.603736] efifb: scrolling: redraw
[ 0.603738] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 0.604462] Console: switching to colour frame buffer device 100x37
[ 0.605829] fb0: EFI VGA frame buffer device
This soon changes to bochs-drm about a second later:
[ 0.935988] bochs-drm 0000:00:01.0: remove_conflicting_pci_framebuffers: bar 0: 0xc0000000 -> 0xc0ffffff
[ 0.937023] bochs-drm 0000:00:01.0: remove_conflicting_pci_framebuffers: bar 2: 0xc1c8c000 -> 0xc1c8cfff
[ 0.937776] checking generic (c0000000 1d5000) vs hw (c0000000 1000000)
[ 0.937776] fb0: switching to bochsdrmfb from EFI VGA
[ 0.939085] Console: switching to colour dummy device 80x25
[ 0.939117] bochs-drm 0000:00:01.0: vgaarb: deactivate vga console
[ 0.939210] [drm] Found bochs VGA, ID 0xb0c5.
[ 0.939212] [drm] Framebuffer size 16384 kB @ 0xc0000000, mmio @ 0xc1c8c000.
[ 0.941955] lpc_ich 0000:00:1f.0: I/O space for GPIO uninitialized
[ 0.942069] [TTM] Zone kernel: Available graphics memory: 2006780 KiB
[ 0.942081] [TTM] Initializing pool allocator
[ 0.942089] [TTM] Initializing DMA pool allocator
[ 0.943026] virtio_blk virtio2: [vda] 20971520 512-byte logical blocks (10.7 GB/10.0 GiB)
[ 0.944019] [drm] Found EDID data blob.
[ 0.944162] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:01.0 on minor 0
[ 0.944979] fbcon: bochs-drmdrmfb (fb0) is primary device
[ 0.947712] Console: switching to colour frame buffer device 128x48
On bionic, the framebuffer never changes from efifb, since the bochs-
drm kernel module is not built, and it is also present on the module
banlist in /etc/modprobe.d/blacklist-framebuffer.conf
bochs-drm needs to be enabled to be built in the kernel config, and
removed from the module blacklist in kmod.
[Testcase]
Create a new QEMU/KVM virtual machine, I used virt-manager. Before you
install the OS, check the box to modify settings before install. In
the "Overview" tab, enable EFI by setting the firmware to "UEFI
x86_64: /usr/share/OVMF/OVMF_CODE.secboot.fd".
Set the video device to qxl while you install Bionic. Once the install
is done, reboot, do a "apt update" and "apt upgrade", to ensure you
have grub2 2.02-2ubuntu8.15 installed.
Shut the VM down, and set the video device to VGA. Or VGA=std if you
use the QEMU command line.
Start the VM up, and the screen will be garbled. See attached picture.
If you install my test packages, which are available here:
https://launchpad.net/~mruffell/+archive/ubuntu/sf272653-test
Instructions to install (on a bionic system):
1) Enable bionic-proposed
2) sudo apt-get update
3) sudo apt install linux-image-unsigned-4.15.0-96-generic linux-modules-4.15.0-96-generic linux-modules-extra-4.15.0-96-generic linux-headers-4.15.0-96-generic linux-headers-4.15.0-96 libkmod2 kmod
4) sudo reboot
5) uname -rv
4.15.0-96-generic #97+TEST272653v20200409b1-Ubuntu SMP Thu Apr 9 04:09:18 UTC 2020
If you reboot, the screen will be perfectly readable, since the bochs-
drm driver will be in use.
[Regression Potential]
We are enabling a display driver on Bionic which was previously
disabled, so there will be some virtual machines making the jump to
using bochs-drm since it would now be available.
I don't think that this is a bad thing, and in many ways will probably
end up improving some user's experience. Although there are two
scenarios where a regression could happen:
1 - frequently gamers use GPU passthrough to their kvm based virtual
machines, and I have seen them expect, or hardcode their kernel
command lines to disable the efifb driver. See
https://passthroughpo.st/explaining-csm-efifboff-setting-boot-gpu-
manually/ Worst case scenario, gamers will also need to disable bochs-
drm as well. Since the PCI device of the GPU is being passed through
to the VM, I believe the kernel will make the correct choice and load
the GPU drivers, like noverau or nvidia-drm instead.
2 - if the bug with PowerKVM machines isn't actually fixed in Bionic,
it will cause a regression on POWER. We just need to test this on
POWER and ensure that the bug in LP #1378648 was fixed. If not, then
we could just disable bochs-drm on POWER, leaving it enabled for all
other archs.
Note: 2 has now been tested and verified working. See comment #7.
If a regression were to occur, it would only affect KVM machines that
use the built in SPICE graphics display. The screen would either not
show at all or be garbled. bochs-drm is limited only to kvm users, and
does not affect other virtualisation platforms like VMware or
Virtualbox. Instances will still be accessible via ssh, and work
normally.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1872863/+subscriptions
More information about the foundations-bugs
mailing list