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

[Laszlo Ersek]

On 03/10/21 10:51, Gerd Hoffmann wrote:
> 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.

Thanks for the CC and the summary, and I agree.


Two (tangential) additions:

- The arbitration between VirtioGpuDxe and QemuVideoDxe, on a virtio-vga
device, happens actually in Virtio10Dxe (the virtio-1.0 transport
driver). When Virtio10Dxe recognizes virtio-vga, it does not expose it
as a virtio device at all.

The reason for this is that VirtioGpuDxe consumes VIRTIO_DEVICE_PROTOCOL
(does not deal with PCI [*]), and QemuVideoDxe consumes
EFI_PCI_IO_PROTOCOL (does not deal with virtio). Therefore, the
arbitration needs to happen in a layer that deals with both of those
abstractions at the same time; and that's the virtio transport driver,
which produces VIRTIO_DEVICE_PROTOCOL on top of EFI_PCI_IO_PROTOCOL.

[*] I'm lying a bit here; it does consume PciIo momentarily. But, for
nothing relevant to the UEFI driver model. VirtioGpuDxe *attempts* using
PciIo for formatting the human-readable device name, with the B/D/F in
it; but even if that fails, the driver works just fine (with a less
detailed human-readable device name).

- QemuRamfbDxe is a platform DXE driver, not a UEFI driver that follows
the UEFI driver model. The reason is that the fw_cfg stuff underlying
ramfb is a "platform device" (a singleton one at that), not an
enumerable device.


So, if you combined ramfb with any other (enumerable) display device
into a single device, that would allow the QemuRamfbDxe platform driver
and the other (UEFI) driver to bind the *same display hardware* via
different interfaces at the same time.

And arbitrating between such drivers is practically impossible without
violating the UEFI driver model: first, the QemuRamfbDxe platform driver
has no way of knowing whether the same display hardware qualifies for
the other (UEFI) driver though PCI (or another enumerable interface);
second, the other (UEFI) driver would have to check for a platform
device (fw_cfg in this case), which is *wrong*. (Consider e.g. what
happens if we have multiple (separate) PCI-based display devices, plus
one ramfb device -- if ramfb were allowed to share the underlying
hardware with one of the PCI ones, how would we tell which PCI device
the ramfb device belonged to?)

(... In fact, the second argument is akin to why I keep rejecting
various manifestations of a GVT-g driver for OVMF -- refer to
<https://bugzilla.tianocore.org/show_bug.cgi?id=935>. Due to the
opregion being based on fw_cfg, the hardware itself is a fusion of a PCI
device and a platform device -- and that's wrong for both a platform DXE
driver, and a UEFI driver that follows the UEFI driver model. It's not
that the driver is impossible to implement (three variants have been
written already, mutually independently of each other), but that any
such driver involves a layering / driver model violation one way or
another. But, I digress.)

Thanks
Laszlo