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

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 31 August 2016 at 21:43, Jordan Justen <jordan.l.justen@intel.com> wrote:
> 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.
>

Because ExitBootServices() tears down the whole driver stack, protocol
database, etc but leaves a single struct in place which describes a
framebuffer whose methods are now inoperable but which can be driven
in the mode that the firmware happened to leave it in. Furthermore,
there is no context anymore that describes which device owns the
framebuffer, and so it is not generally possible to decide if it is
safe to reconfigure any part of the PCI layer without interfering with
the framebuffer mapping.

So yes, it is a hack. A useful one, but still a hack.

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

Of course.

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

Yes, but this is fundamentally problematic on ARM under
virtualization. Emulated framebuffers are backed by host memory, which
is mapped cacheable. Typical framebuffer mapping guest code uses
uncached or write-combining mappings, which are incoherent with the
host mapping, which means the host does not get to see what the guest
puts into the framebuffer without major surgery. This means the
standard VGA QEMU device is unusable on ARM with KVM acceleration.

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

As I explained above, virtio-gpu support without the framebuffer is
indispensable for supporting graphics under QEMU/KVM. So I would
rather have this in sooner than later, either under OvmfPkg or
ArmVirtPkg. Also, I do believe that it is generally useful to make
implementations such as this one widely available especially when the
spec is not finalized yet, so the additional exposure may help in
validation before it is set in stone.

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

Lack of a framebuffer is a deliberate choice. If you need a
framebuffer, you can use the virtio-vga flavor, which exposes a VGA
compatible framebuffer + registers in addition to the standard virtio
GPU.


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