qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]