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

[Laszlo Ersek <lersek@redhat.com>]

On 09/01/16 20:03, Jordan Justen wrote:
> On 2016-09-01 09:29:28, Laszlo Ersek wrote:
>> On 08/31/16 22:43, Jordan Justen wrote:
>>>
>>> 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*
> 
> I can't dispute that it is optional by UEFI spec, but I think it is
> commonly available (and for good reason).

Agree.

> 
>> 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).
>>
> 
> Isn't there generally a window after ExitBootServices is called, and
> before the OS has it's own native driver loaded?

Yes, there is.

> For example, often
> the Linux boot loader calls EBS before starting the kernel. What if
> the kernel doesn't have the virtio gpu driver? Now there's no possible
> way to signal the user.

Correct, there is no way to signal the user *on the graphics console*.
(And, if the guest kernel does have a virtio-gpu-pci driver, then no
messages can be printed to the graphics console in the window that you
mention.) Put differently, the "efifb" driver in Linux has no chance of
working.

But this is no worse than the firmware having no virtio-gpu-pci driver
at all -- in that case, you cannot even boot your guest kernel with
GRUB, because you can't read anything.

So, the virtio-gpu-pci device (and the VirtioGpuDxe driver) does not
give you everything you could justifiedly wish for (which is the
framebuffer), but it does give you what you can reasonably expect on a
platform where the framebuffer is plain broken. Given that the
framebuffer is plan broken (architecturally), GRUB wouldn't give you a
usable menu anyway, and a guest kernel without the virtio-gpu-pci driver
couldn't print readable messages to the framebuffer anyway. (You get
garbage on the screen.)

IOW, the argument is not that "framebuffer is wrong, boo". The argument
is that "framebuffer is broken, fact of life"; virtio-gpu-pci deals with
it (sidesteps it). It fills the gap, not completely, but sufficiently.
It doesn't give you the exact same experience as a linear framebuffer
does *on x86_64*, but for aarch64, that option does not exist, so *on
aarch64*, virtio-gpu-pci is a strict improvement.

> This is just the Linux example, but for various OS's there could be
> any number of reasons for something similar to occur.

Yes.

[snip]

> I think there would be value to have a non-VGA device that could still
> configure a simple framebuffer. VGA does bring a fair amount of other
> baggage.

Ah, I see your point. You distinguish "VGA" from "non-VGA device with
framebuffer".

For this discussion however, this distinction makes no difference. The
suggested "non-VGA device with framebuffer" would be broken exactly the
same way. In other words, it's not the "other baggage" that is broken,
it is the framebuffer.

> But, your point is good, that this does essentially 'fill the
> gap' allowing for a temporary framebuffer while also allowing virtio
> gpu to be used by the native OS driver.

Correction: it fills the gap allowing for a temporary, Blt()-only *GOP*
(not framebuffer!), while also allowing virtio-gpu-pci to be used by the
native OS driver.

And, it turns out that "Blt()-only" is fully sufficient for GRUB, the
UEFI shell (i.e., whatever uses Simple Text Out), huge kudos to
GraphicsConsoleDxe. :) The setup utility works fine too.

>> In other words, lacking a framebuffer is a *bonus* (which side-steps the
>> aarch64 architectural / KVM problem).
>>
> 
> It doesn't sound like a bonus. :)

It is certainly not a bonus that the framebuffer is broken on
aarch64/KVM. It has been a huge headache.

Given that fact however, it *is* a bonus that we have virtio-gpu-pci,
which allows us to display stuff on the screen, without using the
(broken) framebuffer :)

> Couldn't framebuffer support be an optional capability of the virtio
> gpu device?

It already is, you just have to call it "virtio-vga" on the QEMU command
line, rather than "virtio-gpu-pci".

As seen from both the spec and the patches in this series, the guest
tells apart these two device models (i.e., it checks whether we have the
compat framebuffer) from the PCI device class.

Please read
<https://www.kraxel.org/virtio/virtio-v1.0-cs03-virtio-gpu.html#x1-2980007>
("5.7.7 VGA Compatibility").

Please see also the first three patches.

The "qemu-system-aarch64" binary does not include the virtio-vga device
(or, in your words, the "optional framebuffer capability"), because the
framebuffer is architecturally broken on aarch64/KVM. aarch64 combines
guest- and host-side caching attributes differently from x86_64: on the
latter, the laxest attribute prevails, on aarch64, the strictest does.

The PCI host bridge / root bridge driver in edk2 maps MMIO BARs as
Uncached (which is where the framebuffer lives), while KVM maps the same
BAR as cached (in host RAM). Therefore, on x86_64, the end-to-end access
is cached (= laxests prevails), hence guest updates go through the PCPU
cache, where QEMU sees them and can display them correctly. On aarch64,
guest updates *avoid* the PCPU cache (they go directly do host RAM:
strictest attribute prevails), but QEMU still reads through the PCPU
cache, and whatever it displays from there can be stale.

The stage1/stage2 caching attribute combination cannot be changed on
aarch64 (it is part of the architecture spec and has been shipped in
hardware), and all attempts at changing QEMU's host side read accesses /
KVM's mappings to Uncached have failed. (The people who have looked into
this include the kvm-arm maintainers.)

Thanks,
Laszlo