Re: [PATCH] ArmVirtPkg: remove QemuVideoDxe from ArmVirtQemu and ArmVirtQemuKernel

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 22 August 2017 at 17:57, Leif Lindholm <leif.lindholm@linaro.org> 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.