Hi, > > 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.
Hmm, trying to figure what we should do here best ... First, ramfb has absolutely no connection to the "combined" device, other than that the combined devices have a single device only. From the guests point of view there is no difference between (a) qemu -device virtio-ramfb, and (b) qemu -device virtio-gpu-pci -device ramfb-testdev On the host side the difference is that (a) is a single QemuConsole which shows virtio-gpu-pci once activated and ramfb otherwise, and (b) is two QemuConsoles, so you can see both virtio-gpu-pci and ramfb side-by-side, for debugging purposes. Second, one usecase is vgpu boot display. When combining ramfb with a (mdev) vgpu qemu can't modify the pci device. Which I think pretty much implies that adding a whitelist of pci devices to ramfb isn't going to fly. It would also have the drawback that -device ramfb-testdev will not work. So lets do it the other way around? Blacklist devices which QemuVideoDxe and VirtioGpuDxe should *not* bind to? One way would be to just use different pci (subsystem) ids. Problem is that the guest os driver might not bind too then. So something else? Add a pci capability maybe? Other ideas? cheers, Gerd