On 03/21/19 14:04, Peter Maydell wrote:
On Thu, 21 Mar 2019 at 12:40, Laszlo Ersek <lersek@redhat.com> wrote:
In brief, the regression is that the aarch64 system emulator now lists the "virtio-vga" device for the "virt" machine type:
$ qemu-system-aarch64 -M virt -device \? | grep virtio-vga name "virtio-vga", bus PCI
Here's where I think the issue was introduced:
(1) In commit 82f5181777eb ("kconfig: introduce kconfig files", 2019-03-07), VIRTIO_VGA was introduced simply as a bool (with no other clauses) in "hw/display/Kconfig".
(2) In commit 7c28b925b7e1 ("build: convert pci.mak to Kconfig", 2019-03-07), VIRTIO_VGA received the following clauses:
default y if PCI_DEVICES depends on VIRTIO_PCI select VGA
This is too lax, because it permits virtio-vga for aarch64, while that shouldn't happen (and it doesn't matches the previous state of the tree).
(3) In commit b42075bb7767 ("virtio: express virtio dependencies with Kconfig", 2019-03-07), the determination of virtio-vga was switched to the Kconfig system. Importantly, in this patch, the line
CONFIG_VIRTIO_VGA=y
was removed *only* from the following file:
default-configs/i386-softmmu.mak
(4) Both of the remaining instances of
CONFIG_VIRTIO_VGA=y
were then removed in commit 9483cf27dd36 ("hppa-softmmu.mak: express dependencies with Kconfig", 2019-03-07) and commit 87f9108bad0c ("ppc64: Express dependencies of 'pseries' and 'powernv' machines with kconfig", 2019-03-07), from files
default-configs/hppa-softmmu.mak default-configs/ppc64-softmmu.mak
respectively.
Therefore I think commit 7c28b925b7e1 has the bug. The VIRTIO_VGA restriction
depends on VIRTIO_PCI
should now be replaced with
depends on VIRTIO_PCI && (PC || DINO || PSERIES)
Should it? What makes the virtio-vga device only suitable for those three machines?
It simply keeps the status quo from before the patchset. The specific emulation targets that virtio-vga should not be enabled for (regardless of other targets / machine types) are arm/aarch64. IOW, in the longer term, it's not that virtio-vga is suitable only for PC || DINO || PSERIES, but that it's *not* suitable for arm/aarch64. My original libvirt commit explains it: https://libvirt.org/git/?p=libvirt.git;a=commit;h=706b5b627719e95a33606c463b... Regarding the guest firmware: in edk2 there are two relevant drivers, QemuVideoDxe and VirtioGpuDxe. The former is framebuffer-based, the latter is a genuine virtio drier (no framebuffer). The former doesn't work on arm/aarch64 KVM, the latter does. The "virtio-vga" device presents a conflict for these drivers because it could be bound by both drivers, at the same time. (The device presents both interfaces.) Arbitration between UEFI drivers is very tricky. To keep things platform independent and sane in both drivers, VirtioGpuDxe never binds virtio-vga, only virtio-gpu-pci. Therefore, in OVMF, where both drivers are included, virtio-vga is deterministically bound by QemuVideoDxe, a framebuffer is exposed, and Windows is happy. You can still use virtio-gpu-pci, and that will be bound by VirtioGpuDxe (windows won't be happy, but you asked for it). Whereas in ArmVirtQemu, only VirtioGpuDxe is included, as QemuVideoDxe has no chance of working (on KVM). If you then boot with virtio-vga, VirtioGpuDxe will still yield... but there won't be another driver to bind the device instead. So, there you *must* use virtio-gpu-pci, for VirtioGpuDxe to like the device. Again, the goal is to keep VirtioGpuDxe and QemuVideoDxe platform-independent; i.e. refrain from aarch64-specific and x64-specific quirks in either. They bind or yield purely based on the device model they see. So, if you allow libvirt to see virtio-vga on aarch64, it will pick virtio-vga for the guest, and then VirtioGpuDxe will not bind it, and there's nothing else to bind it. Thanks, Laszlo