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. 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. 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. cheers, Gerd
