Re: [PATCH] OvmfPkg/QemuVideoDxe: map framebuffer as write-combining/non-executable

[Laszlo Ersek <lersek@redhat.com>]

On 08/22/17 16:31, Ard Biesheuvel wrote:
> [...]
>>>
>>> (1) When we added VirtioGpuDxe to the ArmVirtPkg platforms, the only
>>> reason I didn't propose removing QemuVideoDxe from the same platforms
>>> was that QemuVideoDxe was usable on QEMU/TCG, and I figured it wouldn't
>>> hurt to keep it.
>>>
>>> Other than that, I see zero point in using this driver on ARM. (And,
>>> apparently, it does hurt to keep it.)
>>>
>>> Can we please consider simply removing this driver from the ArmVirtPkg
>>> platforms? (And then some now-conditional compilation could be
>>> simplified in the driver too!)
>>>
>>
>> It is actually quite useful in TCG mode, and the fact that QEMU
>> currently allows unaligned accesses to device memory is not something
>> we should be relying upon.
>>
> 
> Actually, I managed to confuse myself here. The only thing lacking
> when running with virtio-gpu rather than VGA is efifb support, due to
> the fact that the framebuffer is no longer directly addressable. efifb
> is a useful hack on bare metal systems that lack a real framebuffer
> driver, but it is hardly something to care deeply about on VMs.

(Some side thoughts:

The "virtiodrmfb" driver in the Linux guest works fine with
virtio-gpu-pci. It does not activate itself as soon into the boot
process as efifb, but it does provide a fully functional character
console. And X11 works fine too, with the kernel modesetting driver.

Even if efifb had a chance to work (inheriting a framebuffer), it would
be supplanted during boot really quickly by virtiodrmfb. So the only
consequence of "efifb" not working is that the character console comes
to life a bit later, and some early messages are not shown on the VT.)

> So I am going to change my mind, and agree with Laszlo: let's remove
> QemuVideoDxe from ArmVirtQemu; the longer we wait, the more difficult
> it becomes, and only TCG users that rely on a GOP protocol being
> exposed with direct framebuffer access are going to be affected in the
> first place (if any such use cases exist)

I expect this set of users to be empty already.

> Laszlo: any ideas or suggestions you may want to share before I start
> working on this?

Just the above musings. Please go ahead with the QemuVideoDxe removal!

Thank you!
Laszlo