public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: edk2-devel-01 <edk2-devel@ml01.01.org>,
	Jordan Justen <jordan.l.justen@intel.com>
Subject: Re: [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci)
Date: Fri, 19 Aug 2016 15:06:29 +0200	[thread overview]
Message-ID: <CAKv+Gu-FsmNzv2DSze-6G2HPhTjWGAC4cEJKq9fkDGmTDRT6+w@mail.gmail.com> (raw)
In-Reply-To: <20160819124932.29711-1-lersek@redhat.com>

On 19 August 2016 at 14:49, Laszlo Ersek <lersek@redhat.com> wrote:
> This series solves
> <https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>. In particular,
> it gives AARCH64 guests running on KVM a clean, uncorrupted graphical
> console.
>

Impressive! I suppose this means no direct frame buffer access for the
OS using the GOP? That is fine with me, btw, after finding out that
VGA is really the only problematic QEMU/KVM device (unlike the
reported USB issues, which were solved by making the PCI RC
dma-coherent in the DT), I think this approach is the best solution,
since OS accessing the GOP is a hack anyway (and breaks with the PCI
reconfiguration that occurs under ARM/Linux, even in the ACPI case,
which I expected would leave the firmware PCI setup alone. /me makes
mental note to revert the 'pci-probe-only' patch)

> Anatomy of the series:
>
> - Patches 01 and 02 fix small bugs in QemuVideoDxe and Virtio10Dxe, so
>   that virtio-vga is bound only by QemuVideoDxe, and virtio-gpu-pci is
>   bound only by Virtio10Dxe (and then, on top, by the driver being
>   posted).
>
> - Patch 03 makes OVMF' BDS pick up virtio-gpu-pci automatically as
>   ConOut. (ArmVirtPkg already has the necessary code.) A small tweak.
>
> - Patch 04 adds the VirtIo GPU stuff to IndustryStandard, using Gerd's
>   WIP additions to the VirtIo 1.0 spec, at
>   <https://www.kraxel.org/virtio>. (See the "GPU Device" section.) The
>   URLs are also captured in the code.
>
> - Patches 05 through 07 add the basic (= UEFI driver model) skeleton of
>   the driver, and include it in OvmfPkg and ArmVirtPkg.
>
>   In this series I managed to erect the driver in such a way that the
>   series doesn't only build at every stage, the driver even runs at
>   every stage (and the then-present functionality is testable). I used
>   this to test each layer of functionality in separation, during
>   development.
>
> - Patch 08 implements the basic VirtIo GPU initialization.
>
> - Patch 09 implements VirtIo GPU command primitives ("remote procedure
>   calls"), for performing graphics operations.
>
> - Patch 10 implements the Graphics Output Protocol.
>
> - Patch 11 drops PcdKludgeMapPciMmioAsCached from ArmVirtPkg.
>
> Tests done:
>
> - Virtio-vga regression testing on x86_64 KVM (OvmfPkgIa32X64 build).
>
> - Repeated "disconnect" and "connect -r" checks in the UEFI shell,
>   issued (also) from the serial console (ArmVirtQemu build on AARCH64
>   KVM, OvmfPkgIa32X64 build on x86_64 KVM).
>
> - Repeated mode switches with the "mode" command in the UEFI shell (same
>   platforms).
>
> - Changing the preferred resolution in the Device Manager, then
>   verifying with "mode" in the UEFI shell after reboot (same platforms).
>
> - Tested GRUB, using Fedora 23 / Fedora 24 installer ISOs (both
>   platforms).
>

OK, so grub drives the framebuffer using Blt(), also on ARM? That is lovely!

> - Also tested loading and launching Linux from GRUB. Here the results
>   differ of course: x86_64 Fedora 24 drives virtio-gpu-pci with its
>   native driver without problems, whereas AARCH64 Fedora 23 doesn't even
>   look for virtio-gpu-pci, apparently.
>
> - Standard VGA continues to work in AARCH64 guests with TCG (tested on
>   x86_64 host). In addition, I've verified that the display corruption
>   readily reproduces when using standard VGA in AARCH64/KVM guests, at
>   the end of the series.
>

Indeed. So on ARM, we should drive virtio-gpu in non-VGA mode, using
Blt() equivalent calls.
We should probably propose some patches for Linux then, to make this
the default (or simply the only supported mode)

> - Verified Driver Name and Controller Name in the UEFI shell, issuing
>   "devices", "drivers", and "dh" commands.
>
>   Interestingly, they work perfectly with OVMF, but in ArmVirtQemu, the
>   formatted names are not displayed for *any* driver or device. Likely a
>   general problem with the ArmVirtQemu (or more generally, AARCH64)
>   build of the shell.
>
>   I also ran into a couple of UEFI shell crashes with "devtree" and "dh
>   -d -v" (when listing all devices in the system). However, those
>   crashes reproduce identically when the series is not applied.
>
> Testing instructions:
>
> * OVMF guests: just add
>
>     -device virtio-gpu-pci
>
>   to the QEMU command line.
>
>   For the host display, I prefer SDL when I use the raw QEMU command
>   line:
>
>     -display sdl
>
>   but that's entirely up to the user.
>
> * ArmVirtQemu guests: again, add
>
>     -device virtio-gpu-pci
>
>   I ran my AARCH64/KVM tests on my Mustang, and for host display, there
>   I prefer VNC (when using the raw QEMU command line):
>
>     -display vnc=:0
>
>   Connect with "vncviewer" or another VNC client, optionally forwarded
>   over SSH.
>
>   If you'd even like to type on the graphical console, I recommend
>   adding a USB 3.0 keyboard:
>
>     -device nec-usb-xhci -device usb-kbd
>
> * On both guest arches, check out the nice graphical progress bar (five
>   seconds, and you can enter the Setup utility with F2 or ESC):
>
>     -boot menu=on,splash-time=5000
>
>
> ... This got to be one of my longest blurbs. Sorry about that :)
>
> Ard: I haven't forgotten about the beer you promised! ;)
>

Next time we meet face to face, beers are on me! In fact, there were
some rumors about having our Linaro conference in Budapest next
spring, so I will make sure to put you on the guest list if that
happens.

BTW, your patches look a bit white space impaired to me, i.e., I get
blank lines between each line of patch content.

-- 
Ard.


> Public branch: <https://github.com/lersek/edk2/commits/virtio_gpu>.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
>
> Thanks
> Laszlo
>
> Laszlo Ersek (11):
>   OvmfPkg/QemuVideoDxe: don't incorrectly bind virtio-gpu-pci
>   OvmfPkg/Virtio10Dxe: don't bind virtio-vga
>   OvmfPkg/PlatformBootManagerLib: relax device class requirement for
>     ConOut
>   OvmfPkg/IndustryStandard: add type definitions for the virtio GPU
>     device
>   OvmfPkg/VirtioGpuDxe: introduce with Component Name 2 and Driver
>     Binding
>   OvmfPkg: include VirtioGpuDxe in the platform DSC/FDF files
>   ArmVirtPkg/ArmVirtQemu: include VirtioGpuDxe in the platform DSC/FDF
>     files
>   OvmfPkg/VirtioGpuDxe: initialize and tear down VirtIo GPU device
>   OvmfPkg/VirtioGpuDxe: provide functions for sending VirtIo GPU
>     commands
>   OvmfPkg/VirtioGpuDxe: implement EFI_GRAPHICS_OUTPUT_PROTOCOL
>   ArmVirtPkg: remove PcdKludgeMapPciMmioAsCached
>
>  ArmVirtPkg/ArmVirtPkg.dec                            |  24 -
>  ArmVirtPkg/ArmVirtQemu.dsc                           |   4 +-
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc                 |   1 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc                     |   4 +-
>  ArmVirtPkg/PciHostBridgeDxe/PciHostBridge.c          |   3 +-
>  ArmVirtPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf     |   1 -
>  OvmfPkg/Include/IndustryStandard/Virtio10.h          |   5 +
>  OvmfPkg/Include/IndustryStandard/VirtioGpu.h         | 216 +++++
>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c |  10 +-
>  OvmfPkg/OvmfPkgIa32.dsc                              |   1 +
>  OvmfPkg/OvmfPkgIa32.fdf                              |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc                           |   1 +
>  OvmfPkg/OvmfPkgIa32X64.fdf                           |   1 +
>  OvmfPkg/OvmfPkgX64.dsc                               |   1 +
>  OvmfPkg/OvmfPkgX64.fdf                               |   1 +
>  OvmfPkg/QemuVideoDxe/Driver.c                        |   3 +
>  OvmfPkg/Virtio10Dxe/Virtio10.c                       |  18 +-
>  OvmfPkg/VirtioGpuDxe/Commands.c                      | 559 +++++++++++++
>  OvmfPkg/VirtioGpuDxe/DriverBinding.c                 | 844 ++++++++++++++++++++
>  OvmfPkg/VirtioGpuDxe/Gop.c                           | 647 +++++++++++++++
>  OvmfPkg/VirtioGpuDxe/VirtioGpu.h                     | 327 ++++++++
>  OvmfPkg/VirtioGpuDxe/VirtioGpu.inf                   |  51 ++
>  22 files changed, 2682 insertions(+), 41 deletions(-)
>  create mode 100644 OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>  create mode 100644 OvmfPkg/Include/IndustryStandard/VirtioGpu.h
>  create mode 100644 OvmfPkg/VirtioGpuDxe/VirtioGpu.h
>  create mode 100644 OvmfPkg/VirtioGpuDxe/Commands.c
>  create mode 100644 OvmfPkg/VirtioGpuDxe/DriverBinding.c
>  create mode 100644 OvmfPkg/VirtioGpuDxe/Gop.c
>
> --
> 2.9.2
>


  parent reply	other threads:[~2016-08-19 13:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-19 12:49 [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci) Laszlo Ersek
2016-08-19 12:49 ` [PATCH 01/11] OvmfPkg/QemuVideoDxe: don't incorrectly bind virtio-gpu-pci Laszlo Ersek
2016-08-19 12:49 ` [PATCH 02/11] OvmfPkg/Virtio10Dxe: don't bind virtio-vga Laszlo Ersek
2016-08-19 12:49 ` [PATCH 03/11] OvmfPkg/PlatformBootManagerLib: relax device class requirement for ConOut Laszlo Ersek
2016-08-19 12:49 ` [PATCH 04/11] OvmfPkg/IndustryStandard: add type definitions for the virtio GPU device Laszlo Ersek
2016-08-19 12:49 ` [PATCH 05/11] OvmfPkg/VirtioGpuDxe: introduce with Component Name 2 and Driver Binding Laszlo Ersek
2016-08-19 12:49 ` [PATCH 06/11] OvmfPkg: include VirtioGpuDxe in the platform DSC/FDF files Laszlo Ersek
2016-08-19 12:49 ` [PATCH 07/11] ArmVirtPkg/ArmVirtQemu: " Laszlo Ersek
2016-08-19 13:14   ` Ard Biesheuvel
2016-08-19 12:49 ` [PATCH 08/11] OvmfPkg/VirtioGpuDxe: initialize and tear down VirtIo GPU device Laszlo Ersek
2016-08-19 12:49 ` [PATCH 09/11] OvmfPkg/VirtioGpuDxe: provide functions for sending VirtIo GPU commands Laszlo Ersek
2016-08-19 12:49 ` [PATCH 10/11] OvmfPkg/VirtioGpuDxe: implement EFI_GRAPHICS_OUTPUT_PROTOCOL Laszlo Ersek
2016-08-19 12:49 ` [PATCH 11/11] ArmVirtPkg: remove PcdKludgeMapPciMmioAsCached Laszlo Ersek
2016-08-19 13:16   ` Ard Biesheuvel
2016-08-19 13:06 ` Ard Biesheuvel [this message]
2016-08-19 14:25   ` [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci) Laszlo Ersek
2016-08-31 20:43     ` Jordan Justen
2016-09-01  7:44       ` Ard Biesheuvel
2016-09-01 16:48         ` Laszlo Ersek
2016-09-01 16:29       ` Laszlo Ersek
2016-09-01 18:03         ` Jordan Justen
2016-09-01 18:46           ` Laszlo Ersek
2016-09-01 19:52             ` Jordan Justen
2016-09-01 20:23               ` Ard Biesheuvel
2016-09-01 20:26                 ` Ard Biesheuvel
2016-09-01 20:52                 ` Jordan Justen
2016-09-01 20:44               ` Laszlo Ersek
2016-09-05 14:17               ` Gerd Hoffmann
2016-08-30 15:07 ` Laszlo Ersek
2016-09-01 20:32 ` Jordan Justen
2016-09-01 21:07   ` Laszlo Ersek
2016-09-01 22:02 ` Laszlo Ersek
     [not found]   ` <57CD6463.90903@suse.de>
2016-09-05 12:56     ` Laszlo Ersek
     [not found]       ` <57CD6C25.7000406@suse.de>
2016-09-05 13:17         ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKv+Gu-FsmNzv2DSze-6G2HPhTjWGAC4cEJKq9fkDGmTDRT6+w@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox