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

[Joelle van Dyne]

On Wed, Mar 10, 2021 at 4:45 AM Laszlo Ersek <lersek@redhat.com> wrote:
>
> 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
>

Thanks for the feedback, Laszlo and Gerd. To avoid the XY problem
here, what I am trying to solve is that currently there is no good way
to boot into Windows ARM with virtio-gpu without using ramfb first to
install the drivers. The only solutions I can think of is:

* Implement a linear FB in virtio-gpu
* Hack in ramfb in virtio-gpu

And the second one seems easier. But perhaps I'm missing some other solutions?

-j