Re: [Qemu-devel] [PATCH v2 0/7] ramfb: simple boot framebuffer, no legacy vga

[Gerd Hoffmann]

  Hi,

> I believe the only point of this device model (and the associated guest
> fw driver) is Windows-on-KVM/aarch64.

The other one is vgpu boot display.

And maybe killing vga emulation.  Well, at least be able to not use it
any more for UEFI guests.  It's so much crazy stuff in vga emulation
which isn't used by anyone these days (especially on uefi which doesn't
even need vga text mode any more), except by guys who try to find holes
in qemu for a host escape ...

> Would it be possible to make this stuff available for testing to the
> guy(s) who reported
> <https://bugzilla.tianocore.org/show_bug.cgi?id=785>? (Registration in
> the TianoCore bugzilla is open, and once you log in, you can read email
> addresses, and/or comment on BZs of course.)

I plan to look at arm, but that likely will happen after easter holidays
(I'm offline next week).

> > We should make sure that any device model that combines ramfb with
> > another PCI display device is not matched by the OVMF driver for that
> > PCI display device. IOW, we should use separate PCI IDs or subsystem
> > IDs (I don't recall the details off-hand). I'd like to avoid messing
> > with the current device probing code in OVMF. It just wouldn't be nice
> > if two independent drivers (e.g. VirtioGpuDxe and a supposed
> > "RamFbDxe") bound the two interfaces at the same time.
> 
> For example, virtio-vga is already problematic like this (it could be
> driven by both Virtio10Dxe+VirtioGpuDxe, and QemuVideoDxe), and it had
> to be hacked around in Virtio10Dxe. So I'm strongly in favor of a device
> model that clearly looks like one device and one device only to the full
> set of edk2 drivers, without cross-driver hacks.

Yep, that is one of the things which still need to be sorted.  The
approach of the experimental firmware builds to just disable the
QemuVideo and VirtioGpu drivers clearly doesn't fly for anything but the
initial testing.

Giving out different IDs to the ramfb-enabled device variants would be
one option.  Not fully sure whenever that works for virtio-gpu.  But
given that there are no legacy/transitional virtio-gpu devices I think
we are free to change the subsystem ID as we like.

cheers,
  Gerd