[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 0/7] ramfb: simple boot framebuffer, no legac
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-devel] [PATCH v2 0/7] ramfb: simple boot framebuffer, no legacy vga |
Date: |
Wed, 25 Apr 2018 16:07:49 +0200 |
User-agent: |
NeoMutt/20180323 |
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
- Re: [Qemu-devel] [PATCH v2 0/7] ramfb: simple boot framebuffer, no legacy vga,
Gerd Hoffmann <=