Re: [Qemu-devel] [PATCH v2 0/7] ramfb: simple boot framebuffer, no legacy vga

[Laszlo Ersek <lersek@redhat.com>]

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