| 2020-04-15 00:25:37 |
Matthew Ruffell |
bug |
|
|
added bug |
| 2020-04-15 00:26:23 |
Matthew Ruffell |
description |
BugLink:
[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
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 Windows based virtual machines, and I have seen them expect, or hardcode their kernel command lines to use the efifb driver. I actually find this strange, as if you read the kernel documentation, the efifb driver is meant for Apple Macintosh computers only: https://www.kernel.org/doc/html/latest/fb/efifb.html Since most gamers have to jump through a lot of hoops to get GPU passthrough working, and most have moved on from Bionic, I don't expect this to be a problem.
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. |
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
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 Windows based virtual machines, and I have seen them expect, or hardcode their kernel command lines to use the efifb driver. I actually find this strange, as if you read the kernel documentation, the efifb driver is meant for Apple Macintosh computers only: https://www.kernel.org/doc/html/latest/fb/efifb.html Since most gamers have to jump through a lot of hoops to get GPU passthrough working, and most have moved on from Bionic, I don't expect this to be a problem.
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. |
|
| 2020-04-15 00:26:28 |
Matthew Ruffell |
nominated for series |
|
Ubuntu Bionic |
|
| 2020-04-15 00:26:28 |
Matthew Ruffell |
bug task added |
|
linux (Ubuntu Bionic) |
|
| 2020-04-15 00:27:09 |
Matthew Ruffell |
bug task added |
|
kmod (Ubuntu) |
|
| 2020-04-15 00:27:24 |
Matthew Ruffell |
kmod (Ubuntu Bionic): status |
New |
In Progress |
|
| 2020-04-15 00:27:27 |
Matthew Ruffell |
linux (Ubuntu Bionic): status |
New |
In Progress |
|
| 2020-04-15 00:27:30 |
Matthew Ruffell |
kmod (Ubuntu): status |
New |
Fix Released |
|
| 2020-04-15 00:27:33 |
Matthew Ruffell |
linux (Ubuntu): status |
New |
Fix Released |
|
| 2020-04-15 00:27:38 |
Matthew Ruffell |
linux (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2020-04-15 00:27:41 |
Matthew Ruffell |
kmod (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2020-04-15 00:27:45 |
Matthew Ruffell |
kmod (Ubuntu Bionic): assignee |
|
Matthew Ruffell (mruffell) |
|
| 2020-04-15 00:27:48 |
Matthew Ruffell |
linux (Ubuntu Bionic): assignee |
|
Matthew Ruffell (mruffell) |
|
| 2020-04-15 00:28:19 |
Matthew Ruffell |
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) sudo add-apt-repository ppa:mruffell/sf272653-test
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 Windows based virtual machines, and I have seen them expect, or hardcode their kernel command lines to use the efifb driver. I actually find this strange, as if you read the kernel documentation, the efifb driver is meant for Apple Macintosh computers only: https://www.kernel.org/doc/html/latest/fb/efifb.html Since most gamers have to jump through a lot of hoops to get GPU passthrough working, and most have moved on from Bionic, I don't expect this to be a problem.
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. |
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
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 Windows based virtual machines, and I have seen them expect, or hardcode their kernel command lines to use the efifb driver. I actually find this strange, as if you read the kernel documentation, the efifb driver is meant for Apple Macintosh computers only: https://www.kernel.org/doc/html/latest/fb/efifb.html Since most gamers have to jump through a lot of hoops to get GPU passthrough working, and most have moved on from Bionic, I don't expect this to be a problem.
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. |
|
| 2020-04-15 00:28:30 |
Matthew Ruffell |
tags |
|
sts |
|
| 2020-04-15 00:29:16 |
Matthew Ruffell |
attachment added |
|
Garbled screen https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1872863/+attachment/5354248/+files/Screenshot%20from%202020-04-15%2012-19-48.png |
|
| 2020-04-15 00:44:37 |
Matthew Ruffell |
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) sudo add-apt-repository ppa:mruffell/sf272653-test
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 Windows based virtual machines, and I have seen them expect, or hardcode their kernel command lines to use the efifb driver. I actually find this strange, as if you read the kernel documentation, the efifb driver is meant for Apple Macintosh computers only: https://www.kernel.org/doc/html/latest/fb/efifb.html Since most gamers have to jump through a lot of hoops to get GPU passthrough working, and most have moved on from Bionic, I don't expect this to be a problem.
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. |
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
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 use the efifb driver. I actually find this strange, as if you read the kernel documentation, the efifb driver is meant for Apple Macintosh computers only: https://www.kernel.org/doc/html/latest/fb/efifb.html Since most gamers have to jump through a lot of hoops to get GPU passthrough working, and most have moved on from Bionic, I don't expect this to be a problem.
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. |
|
| 2020-04-15 02:40:34 |
Matthew Ruffell |
attachment added |
|
kmod debdiff for bionic https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1872863/+attachment/5354280/+files/lp1872863_bionic.debdiff |
|
| 2020-04-22 03:17:19 |
Matthew Ruffell |
attachment added |
|
bochs-drm functions correctly on ppc64el https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872863/+attachment/5357795/+files/Screenshot%20from%202020-04-22%2015-14-13.png |
|
| 2020-04-22 03:18:28 |
Matthew Ruffell |
attachment added |
|
Proof VM is running VGA=std on ppc64el https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872863/+attachment/5357796/+files/Screenshot%20from%202020-04-22%2015-14-04.png |
|
| 2020-04-22 21:18:57 |
Dan Streetman |
tags |
sts |
sts sts-sponsor-ddstreet |
|
| 2020-04-22 21:40:57 |
Matthew Ruffell |
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) sudo add-apt-repository ppa:mruffell/sf272653-test
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 use the efifb driver. I actually find this strange, as if you read the kernel documentation, the efifb driver is meant for Apple Macintosh computers only: https://www.kernel.org/doc/html/latest/fb/efifb.html Since most gamers have to jump through a lot of hoops to get GPU passthrough working, and most have moved on from Bionic, I don't expect this to be a problem.
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. |
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
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 use the efifb driver. I actually find this strange, as if you read the kernel documentation, the efifb driver is meant for Apple Macintosh computers only: https://www.kernel.org/doc/html/latest/fb/efifb.html Since most gamers have to jump through a lot of hoops to get GPU passthrough working, and most have moved on from Bionic, I don't expect this to be a problem.
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. |
|
| 2020-04-22 22:06:21 |
Matthew Ruffell |
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) sudo add-apt-repository ppa:mruffell/sf272653-test
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 use the efifb driver. I actually find this strange, as if you read the kernel documentation, the efifb driver is meant for Apple Macintosh computers only: https://www.kernel.org/doc/html/latest/fb/efifb.html Since most gamers have to jump through a lot of hoops to get GPU passthrough working, and most have moved on from Bionic, I don't expect this to be a problem.
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. |
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
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. |
|
| 2020-04-24 17:33:22 |
Kelsey Steele |
linux (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2020-05-01 01:52:11 |
Ubuntu Kernel Bot |
tags |
sts sts-sponsor-ddstreet |
sts sts-sponsor-ddstreet verification-needed-bionic |
|
| 2020-05-03 01:26:37 |
Matthew Ruffell |
attachment added |
|
screenshot of vga=std with 4.15.0-100-generic https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872863/+attachment/5365529/+files/Screenshot%20from%202020-05-03%2013-25-59.png |
|
| 2020-05-03 01:26:58 |
Matthew Ruffell |
tags |
sts sts-sponsor-ddstreet verification-needed-bionic |
sts sts-sponsor-ddstreet verification-done-bionic |
|
| 2020-05-08 07:28:41 |
Łukasz Zemczak |
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) sudo add-apt-repository ppa:mruffell/sf272653-test
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. |
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. |
|
| 2020-05-08 07:30:01 |
Łukasz Zemczak |
kmod (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2020-05-08 07:30:04 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-05-08 07:30:06 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2020-05-08 07:30:11 |
Łukasz Zemczak |
tags |
sts sts-sponsor-ddstreet verification-done-bionic |
sts sts-sponsor-ddstreet verification-needed verification-needed-bionic |
|
| 2020-05-10 22:43:07 |
Matthew Ruffell |
attachment added |
|
screenshot of vga=std with 4.15.0-100-generic and kmod 24-1ubuntu3.4 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872863/+attachment/5369638/+files/Screenshot%20from%202020-05-11%2010-41-12.png |
|
| 2020-05-10 22:43:37 |
Matthew Ruffell |
tags |
sts sts-sponsor-ddstreet verification-needed verification-needed-bionic |
sts sts-sponsor-ddstreet verification-done-bionic |
|
| 2020-05-18 10:10:47 |
Launchpad Janitor |
linux (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2020-05-18 10:10:47 |
Launchpad Janitor |
cve linked |
|
2020-11494 |
|
| 2020-05-18 17:12:06 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2020-05-18 17:22:10 |
Launchpad Janitor |
kmod (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
