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). > 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? 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. This is just the Linux example, but for various OS's there could be any number of reasons for something similar to occur. > > > > Regarding VirtIo GPU: Shouldn't we wait until it makes it into the > > actual specs? > > No, we should not, at this point. > <snip> > 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. > Ok. I guess it is the de-facto standard then. That is a good argument to move forward, but I hope standardization doesn't lead to any annoying compat issues. > > 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". > 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. 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. > In other words, lacking a framebuffer is a *bonus* (which side-steps the > aarch64 architectural / KVM problem). > It doesn't sound like a bonus. :) Couldn't framebuffer support be an optional capability of the virtio gpu device? -Jordan _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
