From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 507401A1E04 for ; Fri, 19 Aug 2016 06:06:30 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id b62so47395126iod.3 for ; Fri, 19 Aug 2016 06:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5FW3orCXThX/LEG8otoxd3UJ+Qf2TXFX4NVXt756S0I=; b=XtcDJe4ylqzCYjZk1nuOSY+FhSnedBljMlmTjxuYpvvp9FYGpOl7Axc6ePX5zq3SbY Ws3wn9UBeXTvM3KpRHU0nGOPzPaoXn2bJR+DEtpyc0HDQ2/eLfdycgporBOciu9MbAH1 V/EtW57rFOOeZtAZVPL0ROBS/Jcsd3sQkj6j8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5FW3orCXThX/LEG8otoxd3UJ+Qf2TXFX4NVXt756S0I=; b=I13TuPZAQNM2V4o+bRwiG/LSvTk+ykdUslAuJKVTxLg5nmtE0TOt5palP0a1UX3+nc 0z7iK4zMITHi8CoizE+0bfjsoaP9iS/e3m1I+RaRXMjNmep9aQgRfo2W1pd4DPAklc9/ BY9jz3kjOwZBRQhLtIVqRf15D9LmgDwN/4YfyESm7gjIqQgnX9XVdOzkzkCIia9pfu82 qxemfvzv4cjxyOxPrGZkYcjuek7FYDrxU1AsvbS+zx3l6GJqxCxJ53pyGea8GT+fmvdh EK8BPQd/k5KNfPDXY0YG4rkaoXVClb2XAJ8yNs2k0/p3xdcuCwYm2kkmfUeDTRWXFjMm d/ow== X-Gm-Message-State: AEkoouv5LCVhXK55iqRIu09r1hr/iMnJ45+BZKOZUWJC/S1VE0VwvM/lT/dBb3C6ViuBEoRYoo2h20QPB6jDnYzr X-Received: by 10.107.41.67 with SMTP id p64mr9356002iop.130.1471611989498; Fri, 19 Aug 2016 06:06:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Fri, 19 Aug 2016 06:06:29 -0700 (PDT) In-Reply-To: <20160819124932.29711-1-lersek@redhat.com> References: <20160819124932.29711-1-lersek@redhat.com> From: Ard Biesheuvel Date: Fri, 19 Aug 2016 15:06:29 +0200 Message-ID: To: Laszlo Ersek Cc: edk2-devel-01 , Jordan Justen Subject: Re: [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci) X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 13:06:30 -0000 Content-Type: text/plain; charset=UTF-8 On 19 August 2016 at 14:49, Laszlo Ersek wrote: > This series solves > . 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 > . (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: . > > Cc: Ard Biesheuvel > Cc: Jordan Justen > > 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 >