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

[Laszlo Ersek <lersek@redhat.com>]

On 08/31/16 22:43, Jordan Justen 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.
> 
> If an OS can't load or find the native driver, the framebuffer also
> provides a way to communicate with the user.

I agree that exposing the framebuffer address through the GOP (at boot
time) so that the runtime OS can directly access the framebuffer (at
runtime) is useful. For example, in Windows 8 and Windows 10 guests,
this is how QXL can be initially used, interactively, until the native
QXL drivers are installed.

I also agree that making a directly accessible framebuffer an *optional*
feature in the UEFI spec was the right thing to do! Graphics output
*should* be supportable at least at boot time even if the device lacks a
linear framebuffer (and even if the above OS fallback will therefore not
work).

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

No, we should not, at this point.

Believe it or not :), this was also my first request before embarking on
the implementation:

(1) https://www.mail-archive.com/edk2-devel@lists.01.org/msg12348.html

On 05/19/16 12:04, Laszlo Ersek wrote:

> The longer-term idea is a driver for QEMU's virtio-gpu device. The
> specification of that QEMU device is under review for the official
> virtio spec. Once it is accepted, I plan to implement a virtio-gpu
> driver for OvmfPkg and ArmVirtPkg. With that device and driver, we can
> (hopefully!) drop support for the legacy VGA device in ArmVirtPkg.

(2) https://www.mail-archive.com/kvmarm@lists.cs.columbia.edu/msg07061.html

On 06/28/16 13:02, Laszlo Ersek wrote:

> I've offered to (attempt to) implement a GOP driver for virtio-gpu, to
> be used by OvmfPkg and ArmVirtPkg, once the virtio-gpu bits become
> part of the official virtio specification.

(These are just the two public references I could find now, but I had
named the virtio GPU spec becoming official as a "requirement" elsewhere
too, before implementing the driver.)

However, things have changed recently. I've received pings from three
organizations that the driver has become more urgent for them. Combined
with the facts that the 2D feature set of virtio-gpu has been part of
QEMU since 2.4 [1], and a 2D Linux guest driver has existed for
virtio-gpu since Linux 4.2 [2] [3], it seemed justified to shift the
focus to working code, rather than standardization.

[1] http://wiki.qemu.org/ChangeLog/2.4#virtio
[2]
https://kvmforum2016.sched.org/event/7L4X/qemu-graphics-update-2016-gerd-hoffmann-red-hat
[3] https://www.kraxel.org/slides/qemu-gfx-2016/#virtio-gpu-guest

(It is generally helpful to have working guest drivers in at least one
system before standardizing a virtio device -- in that regard the
OvmfPkg driver could even be considered "in support of" the
standardization effort!)

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

As described in both the spec and several places in this series, such a
device already exists (both specified and implemented): it is called
"virtio-vga". "Virtio-vga" is the combination of "virtio-gpu-pci" plus a
legacy VGA framebuffer (the one you also get with QXL and stdvga).

It is exactly this framebuffer that breaks in aarch64 KVM guests, due to
architectural / KVM cache coherence issues (= as in, stuff that has been
shipped in physical hardware already). For that reason, the
"qemu-system-aarch64" binary, unlike "qemu-system-x86_64", does not even
include the "virtio-vga" device model -- the framebuffer would be broken
*anyway* on KVM. Instead, there we have to use "virtio-gpu-pci".

In other words, lacking a framebuffer is a *bonus* (which side-steps the
aarch64 architectural / KVM problem).

I already provided a "map" of what devices and drivers we should use in
what kinds of guest, in the message you replied to. I agree it was
somewhat large, so just to emphasize the main points, for when the patch
series is applied:

- "virtio-vga" is available in x86_64 KVM guests. In the firmware,
QemuVideoDxe drives it, using and exposing the linear framebuffer. The
linear framebuffer works well, so Windows 8 and Windows 10 guests can
use the display, even without having native drivers. Linux guests have
native drivers.

- "virtio-vga" is unavailable in aarch64 KVM guests (and even if it was
available, the framebuffer would be broken). Therefore "virtio-gpu-pci"
should be used. In the firmware, VirtioGpuDxe drives it, providing a
Blt()-only GOP. Linux guests have a native driver. The status of Windows
guests is unknown, but we expect / hope that the installer media will
come with native virtio-gpu-pci drivers.

Thanks
Laszlo

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