On 22 August 2017 at 17:57, Leif Lindholm <[email protected]> wrote: > On Tue, Aug 22, 2017 at 05:30:13PM +0100, Ard Biesheuvel wrote: >> One of the reasons for introducing virtio-gpu support to OvmfPkg and >> ArmVirtpkg was the fact that under KVM virtualization on ARM, the >> legacy VGA cannot be used reliably. This is due to an implementation >> detail of QEMU+KVM, which remaps cached host memory into the guest >> address space as a framebuffer behind a PCI BAR. Given that the purpose >> of a memory mapped framebuffer is its side effects, such BARs should >> never be mapped cacheable in the guest, and the mismatched attributes >> between host and guest result in a loss of coherency, visible as >> corruption in the framebuffer image. >> >> This issue does not occur under TCG emulation, nor did we expect it to >> actually bring down the guest under KVM, and so it was deemed harmless >> to keep support for the VGA device as well. However, as it turns out, >> the fact that the framebuffer BAR is mapped using device semantics by >> default may result in unalignment faults when we use the ordinary string >> copy routines on the contents. In theory, we could work around this by >> remapping the BAR as write combining, but it appears the generic PCI >> bus driver does not actually implement this. >> >> So let's remove the QemuVideoDxe driver altogether. This may result >> in loss of functionality for use cases that rely on the framebuffer >> to be directly addressable (such as EFIFB), but given that this never >> worked reliably under KVM in the first place, let's not let that stop >> us from dropping support for it. > > For the record, this would most likely mean we would not be able to > test graphical installers on QEMU. GRUB certainly looks like it's > using FrameBufferBase. Maybe that isn't the most important use-case, > but it's certainly not invalid. >
This came up at the time, and I /though/ the conclusion was that GRUB hooks into the stack at a higher level. I will give Debian's GRUB a quick spin tomorrow. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
