Re: [RFC] hw/display: add virtio-ramfb device

[Gerd Hoffmann <kraxel@redhat.com>]

On Tue, Mar 09, 2021 at 01:35:13PM -0800, Joelle van Dyne wrote:
> Like virtio-vga, but using ramfb instead of legacy vga.
> Useful for booting from OVMF (with updated drivers) into Windows
> ARM which expects a linear FB that the virtio-gpu driver in OVMF
> does not provide.

What is wrong with "-device ramfb" for that use case?

> This code was originally written by Gerd Hoffmann and was
> updated to contain later changes to the display driver tree.

Well, the tricky part with that is OVMF driver binding.  We don't
want two drivers bind to the same device.

We have QemuRamfbDxe + QemuVideoDxe + VirtioGpuDxe.

 - QemuRamfbDxe handles ramfb.
 - QemuVideoDxe handles all vga devices (including virtio-vga)
   plus bochs-display.
 - VirtioGpuDxe handles all virtio-gpu devices (except virtio-vga).

VirtioGpuDxe could easily handle virtio-vga too but doesn't to avoid
the conflict with QemuVideoDxe.  It detects that by looking at the pci
class code.  virtio-vga is tagged as display/vga whereas virtio-gpu-pci
is display/other.

Problem of the virtio-ramfb device is that the guest can't figure
whenever the virtio-gpu device comes with ramfb support or not.
Merging this is a non-starter unless we have a solution for that
problem.

A use case which actually needs that would be helpful to drive that
effort.  I don't see one.  If your guest comes with virtio-gpu drivers
you don't need ramfb support.  The VirtioGpuDxe driver covers the boot
loader, and the guest driver everything else.  If your guest has no
virtio-gpu drivers the virtio-ramfb combo device is useless, you can
simply use standalone ramfb instead.

take care,
  Gerd