| Message ID | 20200415023350.15407-2-matthew.ruffell@canonical.com |
|---|---|
| State | New |
| Headers | show |
| Series | QEMU/KVM display is garbled when booting from kernel EFI stub due to missing bochs-drm module | expand |
On 15.04.20 04:33, Matthew Ruffell wrote: > BugLink: https://bugs.launchpad.net/bugs/1872863 > > A recent grub2 SRU, LP #1864533, has forced the kernel to boot via the efi > stub, instead of the grub linux loader. This causes problems for QEMU/KVM > virtual machines which use the VGA=std video device, as the efifb driver > yields an unreadable garbled screen. The correct framebuffer driver in > this situation is bochs-drm, and modprobing it fixes the issues. > > 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. > > Re-enable bochs-drm again as a module for all architectures to ensure that > QEMU/KVM virtual machines with VGA=std video settings have a functional > framebuffer. > > Signed-off-by: Matthew Ruffell <matthew.ruffell@canonical.com> 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@canonical.com> > --- > debian.master/config/annotations | 3 +-- > debian.master/config/config.common.ubuntu | 2 +- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/debian.master/config/annotations b/debian.master/config/annotations > index d4ba76f3a350..4443dae5b9b5 100644 > --- a/debian.master/config/annotations > +++ b/debian.master/config/annotations > @@ -1743,7 +1743,7 @@ CONFIG_DRM_SHMOBILE policy<{'armhf': 'm'}> > CONFIG_DRM_OMAP policy<{'armhf': 'n'}> > CONFIG_DRM_TILCDC policy<{'armhf': 'm'}> > CONFIG_DRM_QXL policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm'}> > -CONFIG_DRM_BOCHS policy<{'amd64': 'n', 'arm64': 'n', 'armhf': 'n', 'i386': 'n', 'ppc64el': 'n'}> > +CONFIG_DRM_BOCHS policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm'}> > CONFIG_DRM_VIRTIO_GPU policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm'}> > CONFIG_DRM_FSL_DCU policy<{'armhf': 'm'}> > CONFIG_DRM_TEGRA policy<{'armhf-generic': 'm'}> > @@ -1769,7 +1769,6 @@ CONFIG_DRM_PL111 policy<{'arm64': 'm', 'armhf': ' > CONFIG_DRM_TVE200 policy<{'armhf': 'm'}> > # > CONFIG_DRM_MGAG200 note<LP#1693337> > -CONFIG_DRM_BOCHS note<LP#1378648> Instead of removing the note, I would change the bug number to LP#1872863, so the note about the rationale behind this choice is kept. > CONFIG_DRM_STI note<LP#1398458> > CONFIG_DRM_HISI_HIBMC note<LP#1762940> > > diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu > index 865a77cfb9f6..3acc825aac9f 100644 > --- a/debian.master/config/config.common.ubuntu > +++ b/debian.master/config/config.common.ubuntu > @@ -2249,7 +2249,7 @@ CONFIG_DRM_ARM=y > CONFIG_DRM_ARMADA=m > CONFIG_DRM_AST=m > CONFIG_DRM_ATMEL_HLCDC=m > -# CONFIG_DRM_BOCHS is not set > +CONFIG_DRM_BOCHS=m > CONFIG_DRM_BRIDGE=y > CONFIG_DRM_CIRRUS_QEMU=m > # CONFIG_DRM_DEBUG_MM_SELFTEST is not set >
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@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@800000020000000/vga@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@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. Thanks, Matthew
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@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@800000020000000/vga@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@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. > > 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
Acked-by: Kamal Mostafa <kamal@canonical.com> -Kamal On Wed, Apr 15, 2020 at 02:33:50PM +1200, Matthew Ruffell wrote: > BugLink: https://bugs.launchpad.net/bugs/1872863 > > A recent grub2 SRU, LP #1864533, has forced the kernel to boot via the efi > stub, instead of the grub linux loader. This causes problems for QEMU/KVM > virtual machines which use the VGA=std video device, as the efifb driver > yields an unreadable garbled screen. The correct framebuffer driver in > this situation is bochs-drm, and modprobing it fixes the issues. > > 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. > > Re-enable bochs-drm again as a module for all architectures to ensure that > QEMU/KVM virtual machines with VGA=std video settings have a functional > framebuffer. > > Signed-off-by: Matthew Ruffell <matthew.ruffell@canonical.com> > --- > debian.master/config/annotations | 3 +-- > debian.master/config/config.common.ubuntu | 2 +- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/debian.master/config/annotations b/debian.master/config/annotations > index d4ba76f3a350..4443dae5b9b5 100644 > --- a/debian.master/config/annotations > +++ b/debian.master/config/annotations > @@ -1743,7 +1743,7 @@ CONFIG_DRM_SHMOBILE policy<{'armhf': 'm'}> > CONFIG_DRM_OMAP policy<{'armhf': 'n'}> > CONFIG_DRM_TILCDC policy<{'armhf': 'm'}> > CONFIG_DRM_QXL policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm'}> > -CONFIG_DRM_BOCHS policy<{'amd64': 'n', 'arm64': 'n', 'armhf': 'n', 'i386': 'n', 'ppc64el': 'n'}> > +CONFIG_DRM_BOCHS policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm'}> > CONFIG_DRM_VIRTIO_GPU policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm'}> > CONFIG_DRM_FSL_DCU policy<{'armhf': 'm'}> > CONFIG_DRM_TEGRA policy<{'armhf-generic': 'm'}> > @@ -1769,7 +1769,6 @@ CONFIG_DRM_PL111 policy<{'arm64': 'm', 'armhf': ' > CONFIG_DRM_TVE200 policy<{'armhf': 'm'}> > # > CONFIG_DRM_MGAG200 note<LP#1693337> > -CONFIG_DRM_BOCHS note<LP#1378648> > CONFIG_DRM_STI note<LP#1398458> > CONFIG_DRM_HISI_HIBMC note<LP#1762940> > > diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu > index 865a77cfb9f6..3acc825aac9f 100644 > --- a/debian.master/config/config.common.ubuntu > +++ b/debian.master/config/config.common.ubuntu > @@ -2249,7 +2249,7 @@ CONFIG_DRM_ARM=y > CONFIG_DRM_ARMADA=m > CONFIG_DRM_AST=m > CONFIG_DRM_ATMEL_HLCDC=m > -# CONFIG_DRM_BOCHS is not set > +CONFIG_DRM_BOCHS=m > CONFIG_DRM_BRIDGE=y > CONFIG_DRM_CIRRUS_QEMU=m > # CONFIG_DRM_DEBUG_MM_SELFTEST is not set > -- > 2.25.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
diff --git a/debian.master/config/annotations b/debian.master/config/annotations index d4ba76f3a350..4443dae5b9b5 100644 --- a/debian.master/config/annotations +++ b/debian.master/config/annotations @@ -1743,7 +1743,7 @@ CONFIG_DRM_SHMOBILE policy<{'armhf': 'm'}> CONFIG_DRM_OMAP policy<{'armhf': 'n'}> CONFIG_DRM_TILCDC policy<{'armhf': 'm'}> CONFIG_DRM_QXL policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm'}> -CONFIG_DRM_BOCHS policy<{'amd64': 'n', 'arm64': 'n', 'armhf': 'n', 'i386': 'n', 'ppc64el': 'n'}> +CONFIG_DRM_BOCHS policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm'}> CONFIG_DRM_VIRTIO_GPU policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm'}> CONFIG_DRM_FSL_DCU policy<{'armhf': 'm'}> CONFIG_DRM_TEGRA policy<{'armhf-generic': 'm'}> @@ -1769,7 +1769,6 @@ CONFIG_DRM_PL111 policy<{'arm64': 'm', 'armhf': ' CONFIG_DRM_TVE200 policy<{'armhf': 'm'}> # CONFIG_DRM_MGAG200 note<LP#1693337> -CONFIG_DRM_BOCHS note<LP#1378648> CONFIG_DRM_STI note<LP#1398458> CONFIG_DRM_HISI_HIBMC note<LP#1762940> diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu index 865a77cfb9f6..3acc825aac9f 100644 --- a/debian.master/config/config.common.ubuntu +++ b/debian.master/config/config.common.ubuntu @@ -2249,7 +2249,7 @@ CONFIG_DRM_ARM=y CONFIG_DRM_ARMADA=m CONFIG_DRM_AST=m CONFIG_DRM_ATMEL_HLCDC=m -# CONFIG_DRM_BOCHS is not set +CONFIG_DRM_BOCHS=m CONFIG_DRM_BRIDGE=y CONFIG_DRM_CIRRUS_QEMU=m # CONFIG_DRM_DEBUG_MM_SELFTEST is not set
BugLink: https://bugs.launchpad.net/bugs/1872863 A recent grub2 SRU, LP #1864533, has forced the kernel to boot via the efi stub, instead of the grub linux loader. This causes problems for QEMU/KVM virtual machines which use the VGA=std video device, as the efifb driver yields an unreadable garbled screen. The correct framebuffer driver in this situation is bochs-drm, and modprobing it fixes the issues. 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. Re-enable bochs-drm again as a module for all architectures to ensure that QEMU/KVM virtual machines with VGA=std video settings have a functional framebuffer. Signed-off-by: Matthew Ruffell <matthew.ruffell@canonical.com> --- debian.master/config/annotations | 3 +-- debian.master/config/config.common.ubuntu | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-)