RFE: OvmfPkg: GOP driver for virtio-gpu-pci about edk2 HOT 4 CLOSED

The GOP driver should be separate from QemuVideoDxe. It should be
virtio-1.0 only, and should bind our edk2-internal VIRTIO_DEVICE_PROTOCOL
only (enforcing the >=1 protocol revision). PCI details and VGA
compatibility should be ignored (which includes reverting commit 94210dc
94210dc
-- with the new virtio-gpu-pci driver in place, QemuVideoDxe should just
steer clear of the device, and both virtio-gpu-pci and virtio-gpu should be
driven by the new driver.)

Well, it is also possible to have QemuVideoDxe handle virtio-vga and the
new driver virtio-gpu-pci (and virtio-gpu @ mmio).
You can figure which device is which by checking the pci device class,
virtio-vga has DISPLAY_VGA and virtio-gpu-pci has DISPLAY_OTHER.

from edk2.

You can figure which device is which by checking the pci device class, virtio-vga has DISPLAY_VGA and virtio-gpu-pci has DISPLAY_OTHER.

This is easy to do in QemuVideoDxe (which is already a PCI device driver).

In the new driver however I'd like to look at the VIRTIO_DEVICE_PROTOCOL interface only. It wouldn't be very hard to find the related PciIo protocol / handle, and check the PCI device class using that (i.e., read the config space through PciIo), but in a sense it would be a "layering violation". The PciIo interface of the device is already in use by Virtio10Dxe (the generic driver that provides the "modern" VIRTIO_DEVICE_PROTOCOL impl. on top of PciIo).

Admittedly, this would be a one-off check, not a permanent reference (the UEFI spec recognizes this difference; EFI_OPEN_PROTOCOL_GET_PROTOCOL vs. EFI_OPEN_PROTOCOL_BY_DRIVER.) Still I feel the separation would be cleaner without accessing PciIo in the new driver.

from edk2.

2016-07-05 20:09 GMT+02:00 Laszlo Ersek [email protected]:

You can figure which device is which by checking the pci device class,
virtio-vga has DISPLAY_VGA and virtio-gpu-pci has DISPLAY_OTHER.

This is easy to do in QemuVideoDxe (which is already a PCI device driver).

In the new driver however I'd like to look at the VIRTIO_DEVICE_PROTOCOL
interface only. It wouldn't be very hard to find the related PciIo protocol
/ handle, and check the PCI device class using that (i.e., read the config
space through PciIo), but in a sense it would be a "layering violation".
The PciIo interface of the device is already in use by Virtio10Dxe (the
generic driver that provides the "modern" VIRTIO_DEVICE_PROTOCOL impl. on
top of PciIo).

Possibly it is easier to do in the virtio-pci driver: Don't bind to
DISPLAY_VGA devices, so virtio-vga wouldn't show up as VIRTIO_DEVICE in the
first place.

from edk2.

This issue is now tracked by
https://tianocore.acgmultimedia.com/show_bug.cgi?id=66

from edk2.