Re: [libvirt] [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS
On 03/21/19 14:04, Peter Maydell wrote:
On Thu, 21 Mar 2019 at 12:40, Laszlo Ersek <lersek(a)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=706b5b627719e95a33606c4...
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