ACK/cmnt: [SRU][Bionic][PATCH 1/1] UBUNTU: [Config] Enable CONFIG_DRM_BOCHS as module for all archs

Kleber Souza kleber.souza at canonical.com
Wed Apr 22 09:33:36 UTC 2020


On 22.04.20 05:28, Matthew Ruffell wrote:
> On 16/04/20 9:28 pm, Kleber Souza wrote:
> 
>> This change looks good to me, however I would like to see some test results
>> on a ppc64el machine with Bionic before we commit this patch. So we would
>> avoid re-spinning the kernel in the future in case this is not really
>> fixed on PowerKVM.
>>
>> Acked-by: Kleber Sacilotto de Souza <kleber.souza at canonical.com>
>>
> 
> 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://launchpadlibrarian.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-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].
> 
> [1]: https://launchpadlibrarian.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
> [    0.890480] Console: switching to colour frame buffer device 100x37
> [    0.892181] fb0: Open Firmware frame buffer device on /pci at 800000020000000/vga at 6
> 
> $ 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://launchpadlibrarian.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/Q8V7fKnRzz/
> 
> Interesting parts:
> 
> [    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 at 800000020000000/vga at 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.
> 
> Thanks,
> Matthew
> 

Hi Matthew,

Thank you for the extensive tests. I'm happy with the results and I believe this is
safe for SRU.


Thanks,
Kleber



More information about the kernel-team mailing list