Re: [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci)

[Jordan Justen <jordan.l.justen@intel.com>]

On 2016-08-19 07:25:54, Laszlo Ersek wrote:
> On 08/19/16 15:06, Ard Biesheuvel wrote:
> > 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'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

How it is a hack? It seems to be pretty standard for graphics devices
to provide a simple framebuffer mode. True, it is not required by the
GOP protocol, but many devices and GOP drivers enable it. Thus, it
seems reasonable for a UEFI OS to take advantage of it while loading
the native driver.

If an OS can't load or find the native driver, the framebuffer also
provides a way to communicate with the user.

> > (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.

Like mentioned above, there are potential cases where the OS may want
to update the screen before loading the the native drivers, or if
loading the native driver failed.

Regarding VirtIo GPU: Shouldn't we wait until it makes it into the
actual specs?

Is there any chance to update the spec provide a simple (directly
scanned out) framebuffer mode?

-Jordan

> 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
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel