On 1 September 2016 at 21:23, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 1 September 2016 at 20:52, Jordan Justen <jordan.l.jus...@intel.com> wrote: >> On 2016-09-01 11:46:04, Laszlo Ersek wrote: >>> On 09/01/16 20:03, Jordan Justen wrote: >>> >>> > 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. >>> >> >> This is only focusing on the current ARM issue. I'm just pointing out >> that I think virtio gpu without VGA, but with a framebuffer could be >> useful on IA32/X64 as well. >> >> 1. You don't have to deal with the PCI bus >> >> 2. The OS re-enumerating the PCI bus would not break the framebuffer >> > > How does adding a framebuffer to virtio-gpu solve any of that? > virtio-gpu is a PCI device as well > >> Is there no chance that ARM KVM might someday also be able to support >> a framebuffer? >> > > There are workarounds imaginable, but none of them are feasible in > terms
... of performance > A new revision of the architecture may address this, but that > will take years to turn up in real hardware. > >> Obviously this is not too important for IA32/X64 OVMF, because we have >> reasonable alternatives. But, it seems like virtio gpu could be a >> significantly better option for IA32/X64 OVMF if an optional >> framebuffer was possible. >> > > IIUC, not having a linear framebuffer was one of the design goals, > since it is essentially a layering violation in the virtio stack. > virtio-gpu is strictly ring based, like other virtio devices. > > If you want a framebuffer, you should use virtio-vga. Adding a > framebuffer to virtio-gpu is a step back rather than a step forward. > > Also, the loader->OS handover already suffers from the issues you > mention, since the PCI reconfiguration breaks GOP on almost every > platform. The reason that it is less of a concern on ARM is that most > systems use UART as the primary console. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
