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

[Laszlo Ersek]

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:

(1) When the UEFI driver (QemuVideoDxe or Virtio10Dxe) is loaded, it
looks up and caches the fw_cfg selector key (from the fw_cfg directory)
for the fw_cfg file that exposes what S/B/D/Fs not to bind.

(2) When the UEFI driver is asked by BDS (Boot Device Selection) to
state if it supports a specific controller handle, the driver (same as
now) first checks if a PciIo protocol interface is available on the
handle at all. If so, the driver selects the cached fw_cfg selector.

(3) When the key is selected for the first time ever, QEMU refreshes the
contents of the fw_cfg file, with the S/B/D/Fs assigned to the combined
devices. The ordering should be fine here, because in step (2), we first
open a PciIo protocol interface (before selecting the fw_cfg key), and
successfully opening a PciIo interface implies that PciBusDxe has
enumerated the PCI(e) hierarchies and has assigned bus numbers to
devices. The fw_cfg file would be padded at machine startup to a large
enough size so that the regenerated contents fit.

I think this is similar to how ACPI is regenerated in QEMU, to reflect
the resources assigned to PCI(e) devices in various AML aperture
objects. (IIRC.)

(4) The UEFI driver reads (caches) the selected fw_cfg file into a
memory buffer, calls PciIo->GetLocation(), then searches the buffer for
a S/B/D/F match. If there's a match, then the driver returns
EFI_UNSUPPORTED.

(5) Once the fw_cfg file is read (cached), it could be reused for
deciding about further controller binding attempts (involving that
driver), without any further fw_cfg traffic (in that driver anyway).

Thanks,
Laszlo