vt_vga: repost only a vgapci(4) video device

[denis.borovikov_gmail.com]

Summary

When vt(4) falls back to vt_vga, vga_init() passes vd_video_dev to vga_pci_repost(), which expects a vgapci(4) device. The framebuffer driver that set it need not provide one: drm-kmod's linux_fb passes the parent of the DRM parent device, which is vgapci for LinuxKPI PCI drivers but the PCI bus for virtio-gpu, whose DRM parent is the virtio PCI transport. On x86, vga_pci_repost() then calls pci_get_class() on the bus, which fails the accessor's KASSERT under INVARIANTS; without INVARIANTS the class reads as 0 and the repost is skipped. Repost only a vgapci device.

Test Plan

vt_vga.c compiles for amd64 with -Wall -Werror. Not run: the failing path needs an x86 BIOS boot where vt falls back from drm-kmod's console, which I can't set up here; it follows from vga_pci_is_boot_display() and the __BUS_ACCESSOR KASSERT.

[wulf]

Just curious if repost required on virtio_gpu to get working vga console after falling back from drm one?

[denis.borovikov_gmail.com]

@wulf Thanks! For QEMU's virtio-vga I don't think so, though I haven't tried it on x86. The device shows VGA output until the first SET_SCANOUT and switches back on device reset (virtio_gpu_base_reset() clears enable, and virtio_vga_base_reset_hold() resets the VGA state). The driver resets the device on detach, and vt_vga programs the VGA registers itself, so there is no BIOS state to restore. virtio-gpu-pci has no VGA at all, so there is nothing to fall back to.