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