On 06/05/18 15:16, Gerd Hoffmann wrote: > On Tue, Jun 05, 2018 at 02:07:27PM +0200, Laszlo Ersek wrote: >> On 06/05/18 13:06, Gerd Hoffmann wrote: >>> Hi, >>> >>>>>> I could imagine an OvmfPkg-specific PCI capability that said, "all PCI >>>>>> drivers in OvmfPkg that could otherwise drive this device, ignore it -- >>>>>> another (platform) driver in OvmfPkg will pick it up instead". >>>>> >>>>> pci capability for ramfb could be useful (also for linux). I'll keep it >>>>> in mind for now. >>>> >>>> Please do. :) >>> >>> Hmm, well. Virtio 1.0 uses vendor specific capabilities already to >>> define the regions, and they don't have a fixed field saying "this is >>> for virtio". So adding another vendor specific capability for something >>> else on the same device is a bit problematic ... >> >> Can we invent a non-PCI method, e.g. fw_cfg, that tells QemuVideoDxe and >> Virtio10Dxe not to bind some PCI S/B/D/Fs? Something like: > > Well, from edk2 point of view Virtio10Dxe is the only problematic case > because there is a is a native driver. For cirrus/stdvga a version with > ramfb is rather pointless.
Good catch; thinko on my part! > A qxl-ramfb device might make sense, but > QemuVideoDxe would ignore such a device like it ignores qxl today as it > can only handle the vga mode of qxl-vga devices. Indeed. > Also I'd prefer to provide informations (device foo has ramfb at <addr>) > not instructions (please ignore device foo). > > Maybe we should for now just scratch the idea of an virtio-ramfb device. > Linux doesn't need it, and windows wouldn't use the virtio part of it so > a standalone ramfb device would work equally well. If that works for you, it works for me best! Thanks! Laszlo
