From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 29F101A1E04 for ; Fri, 19 Aug 2016 07:25:58 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 752DF12B7; Fri, 19 Aug 2016 14:25:57 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-13.phx2.redhat.com [10.3.116.13]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7JEPtwm003720; Fri, 19 Aug 2016 10:25:56 -0400 To: Ard Biesheuvel References: <20160819124932.29711-1-lersek@redhat.com> Cc: edk2-devel-01 , Jordan Justen From: Laszlo Ersek Message-ID: Date: Fri, 19 Aug 2016 16:25:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 19 Aug 2016 14:25:57 +0000 (UTC) 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 14:25:58 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 08/19/16 15:06, Ard Biesheuvel wrote: > 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's correct. > 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), Good to know, thanks! > 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) The expectation is that the AARCH64 installer media of all guest OSes should come with a native virtio-gpu-pci driver included. So this driver should allow the user to boot, and then the native driver should pick up the GPU even during the initial installation of the guest OS. [snip] >> - 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! At this point I believe that GRUB uses Simple Text Out only. (I've been confused about this myself. Not a proud moment! :)) That Simple Text Out protocol is provided by "MdeModulePkg/Universal/Console/GraphicsConsoleDxe", on top of the GOP. So GRUB itself shouldn't render graphics, just write text, and the rendering is done by GraphicsConsoleDxe. GraphicsConsoleDxe apparently knows how to handle Blt()-only GOPs, which is indeed awesome. :) (I've probably forgotten ConSplitterDxe out of the middle somewhere above, but it shouldn't affect the concept that GRUB writes text only, and GraphicsConsoleDxe translates that to GOP.Blt().) This should work for any other Simple Text Out-using boot loader as well. >> - 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) Graphics Output Protocol is provided by a UEFI_DRIVER, not a DXE_RUNTIME_DRIVER, so the GOP abstraction is unusable after ExitBootServices() -- Blt() lives in EfiBootServicesCode type memory. The framebuffer access works (on x86 :)) only because that doesn't need *code* from the firmware. The OS's UEFI bootloader reads the framebuffer base, size, and pixel format from the GOP, and saves the information in a private data struct. Then it calls ExitBootServices(), and the OS can poke at the framebuffer directly only because (a) there *is* a framebuffer to begin with, (b) the private struct from the boot loader informs the OS where to poke. So, this driver is absolutely no help at all after ExitBootServices(). Put differently, efifb support for it in Linux is impossible. "efifb" has "fb" (framebuffer) in its name, but virtio-gpu-pci has no framebuffer. Just use Linux's native virtio-gpu-pci driver (CONFIG_DRM_VIRTIO_GPU); it lives at drivers/gpu/drm/virtio/ in the kernel tree. Also, virtio-gpu-pci has no VGA mode. Only virtio-vga has. Some of the commit messages in the series elaborate on this. Briefly, the virtio-vga device will be bound by QemuVideoDxe, and utilized through the VGA framebuffer. This allows you to install (x86) Windows 8 and Windows 10 with virtio-vga, because those OSes *insist* on inheriting the framebuffer from the GOP. Once you installed the guest (using slow, direct access to the framebuffer), you can install an accelerated native virtio driver for the display (if that driver exists, I don't know). Corollary: you can't use virtio-vga for AARCH64 guests, because the framebuffer exposed by QemuVideoDxe won't work well. Whereas virtio-gpu-pci (which lacks the VGA framebuffer) will be bound by VirtioGpuDxe. It will not let you install Windows 8 and Windows 10 on x86, but it will function well on AARCH64, boot time only. Here's a summary: - UEFI Linux guest on x86 KVM: - QXL: QemuVideoDxe works at boot, GOOD OS has native accelerated driver - virtio-vga: QemuVideoDxe works at boot, GOOD OS has native accelerated driver - virtio-gpu-pci: VirtioGpuDxe works at boot, GOOD OS has native accelerated driver - UEFI Linux guest on AARCH64 KVM: - QXL: QemuVideDxe doesn't work well at boot, OS has native accelerated driver - virtio-vga: QemuVideDxe doesn't work well at boot, OS has native accelerated driver - virtio-gpu-pci: VirtioGpuDxe works at boot, GOOD OS has native accelerated driver - UEFI Windows 7 guest on x86 KVM: - QXL: QemuVideDxe works at boot, GOOD OS installer uses QemuVideDxe's VBE shim, installed OS can install accelerated driver - virtio-vga: QemuVideDxe works at boot, no OS support - virtio-gpu-pci: VirtioGpuDxe works at boot, no OS support - UEFI Windows 8 / 10 guest on x86 KVM: - QXL: QemuVideDxe works at boot, GOOD OS installer inherits the framebuffer OK, installed OS can install accelerated driver - virtio-vga: QemuVideDxe works at boot, COMING UP? OS installer inherits the framebuffer OK, installed OS: no accelerated driver yet (AIUI) - virtio-gpu-pci: VirtioGpuDxe works at boot, no OS support - UEFI Windows ??? guest on AARCH64: - QXL: QemuVideDxe doesn't work well at boot, no clue about native OS driver - virtio-vga: QemuVideDxe doesn't work well at boot, native driver *should* be on installer media - virtio-gpu-pci: VirtioGpuDxe works at boot, HOPE native driver *should* be on installer media [snip] > 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. That would be huge. Please do this! :) > BTW, your patches look a bit white space impaired to me, i.e., I get > blank lines between each line of patch content. Hrmpf, interesting. I did move to a new git version (2.9.2), and I also set the dependent [sendemail] transferEncoding = quoted-printable option. This prevents mailing list software from messing up the CRLF line endings on the patches, so "git am" no longer needs --keep-cr, and even new files, and file deletions, will work correctly. ... I checked my patches: for me they look fine: - in the mailing list archive: https://lists.01.org/pipermail/edk2-devel/2016-August/000930.html - in Thunderbird - when saved to a local file from ThunderBird This might need more analysis later, but I'm done for the week, I think :) I hope you can test the patches by fetching them from my github repo. Cheers! Laszlo