I have verified that enabling the bochs-drm kernel module on bionic does not cause any regressions for PowerKVM machines when the video device is VGA=std.
This is in response to the main cause of regression concern, LP #1378648, which got bochs-drm disabled in the first place, on yakkety.
On Christian's advice, I created a ppc64el instance on Canonistack, with the m1.medium flavor and c8c120bd-3d55-4e2d-8cc5-93039a62524f image (ubuntu/ubuntu-bionic-18.04-ppc64el-server-20200407-disk1.img).
From there, I installed the KVM packages and a xfce4 desktop, and got xrdp working. I then installed virt-manager.
I modprobed the kvm_pr kernel module on my instance to enable nested kvm on ppc64el.
From there, I installed Ubuntu 18.04.4 Server ppc64el, using virt-manager. The "Machine Type" was pseries-2.12, and the Video Model was set to "VGA" [1].
and installed new kmod and 4.15.0-96-generic test builds with bochs-drm enabled in the kernel config, and removed from the kmod blacklist.
I then rebooted, and found that system boots successfully, and does not get hung up at the bug in LP #1378648, indicating that it has been fixed before 4.15.
I checked "lsmod" and bochs-drm has been loaded, and looking at dmesg, initially the Open Firmware frame buffer device is used, and later in the boot, bochs-drm is loaded, and takes over the frame buffer.
See screenshot [2] for proof that bochs-drm is running and functions correctly in virt-manager.
[ 0.893046] Using unsupported 800x600 vga at 200081000000, depth=32, pitch=3200
[ 0.895482] Console: switching to colour frame buffer device 100x37
[ 0.897270] fb0: Open Firmware frame buffer device on /pci@800000020000000/vga@6
...
[ 2.041835] checking generic (200081000000 1d4c00) vs hw (200081000000 1000000)
[ 2.041836] fb: switching to bochsdrmfb from OFfb vga
[ 2.042568] Console: switching to colour dummy device 80x25
[ 2.045581] [drm] Found bochs VGA, ID 0xb0c5.
[ 2.046100] [drm] Framebuffer size 16384 kB @ 0x200081000000, mmio @ 0x200082000000.
[ 2.058141] [TTM] Zone kernel: Available graphics memory: 504512 kiB
[ 2.058883] [TTM] Initializing pool allocator
[ 2.059372] [TTM] Initializing DMA pool allocator
[ 2.074890] Console: switching to colour frame buffer device 128x48
[ 2.089805] bochs-drm 0000:00:06.0: fb0: bochsdrmfb frame buffer device
[ 2.090549] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:06.0 on minor 0
$ cat /proc/fb
0 bochsdrmfb
With good dmesg outputs, and positive test results in virt-manager, I am happy to say that enabling bochs-drm will not cause any regressions on ppc64el, and with that, I hope it satisfies your request for testing.
I have verified that enabling the bochs-drm kernel module on bionic does not cause any regressions for PowerKVM machines when the video device is VGA=std.
TLDR: See Screenshot: https:/ /launchpadlibra rian.net/ 475658598/ Screenshot% 20from% 202020- 04-22%2015- 14-13.png
This is in response to the main cause of regression concern, LP #1378648, which got bochs-drm disabled in the first place, on yakkety.
On Christian's advice, I created a ppc64el instance on Canonistack, with the m1.medium flavor and c8c120bd- 3d55-4e2d- 8cc5-93039a6252 4f image (ubuntu/ ubuntu- bionic- 18.04-ppc64el- server- 20200407- disk1.img) .
From there, I installed the KVM packages and a xfce4 desktop, and got xrdp working. I then installed virt-manager.
I modprobed the kvm_pr kernel module on my instance to enable nested kvm on ppc64el.
From there, I installed Ubuntu 18.04.4 Server ppc64el, using virt-manager. The "Machine Type" was pseries-2.12, and the Video Model was set to "VGA" [1].
[1]: https:/ /launchpadlibra rian.net/ 475658622/ Screenshot% 20from% 202020- 04-22%2015- 14-04.png
Upon booting, the system was using the Open Firmware frame buffer:
[ 0.888072] Using unsupported 800x600 vga at 200081000000, depth=32, pitch=3200 00000/vga@ 6
[ 0.890480] Console: switching to colour frame buffer device 100x37
[ 0.892181] fb0: Open Firmware frame buffer device on /pci@8000000200
$ cat /proc/fb
0 OFfb vga
Which is what LP #1378648 wanted.
I then enabled my ppa where my test packages were built:
https:/ /launchpad. net/~mruffell/ +archive/ ubuntu/ sf272653- test
and installed new kmod and 4.15.0-96-generic test builds with bochs-drm enabled in the kernel config, and removed from the kmod blacklist.
I then rebooted, and found that system boots successfully, and does not get hung up at the bug in LP #1378648, indicating that it has been fixed before 4.15.
I checked "lsmod" and bochs-drm has been loaded, and looking at dmesg, initially the Open Firmware frame buffer device is used, and later in the boot, bochs-drm is loaded, and takes over the frame buffer.
See screenshot [2] for proof that bochs-drm is running and functions correctly in virt-manager.
[2]: https:/ /launchpadlibra rian.net/ 475658598/ Screenshot% 20from% 202020- 04-22%2015- 14-13.png
A complete dmesg from this boot can be found here [3].
[3] https:/ /paste. ubuntu. com/p/Q8V7fKnRz z/
Interesting parts:
[ 0.893046] Using unsupported 800x600 vga at 200081000000, depth=32, pitch=3200 00000/vga@ 6
[ 0.895482] Console: switching to colour frame buffer device 100x37
[ 0.897270] fb0: Open Firmware frame buffer device on /pci@8000000200
...
[ 2.041835] checking generic (200081000000 1d4c00) vs hw (200081000000 1000000)
[ 2.041836] fb: switching to bochsdrmfb from OFfb vga
[ 2.042568] Console: switching to colour dummy device 80x25
[ 2.045581] [drm] Found bochs VGA, ID 0xb0c5.
[ 2.046100] [drm] Framebuffer size 16384 kB @ 0x200081000000, mmio @ 0x200082000000.
[ 2.058141] [TTM] Zone kernel: Available graphics memory: 504512 kiB
[ 2.058883] [TTM] Initializing pool allocator
[ 2.059372] [TTM] Initializing DMA pool allocator
[ 2.074890] Console: switching to colour frame buffer device 128x48
[ 2.089805] bochs-drm 0000:00:06.0: fb0: bochsdrmfb frame buffer device
[ 2.090549] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:06.0 on minor 0
$ cat /proc/fb
0 bochsdrmfb
With good dmesg outputs, and positive test results in virt-manager, I am happy to say that enabling bochs-drm will not cause any regressions on ppc64el, and with that, I hope it satisfies your request for testing.