On 09/16/16 15:06, Andrea Bolognani wrote: > On Fri, 2016-09-16 at 14:43 +0200, Pavel Hrdina wrote: >> On Fri, Sep 16, 2016 at 09:30:23AM +0200, Laszlo Ersek wrote: >>> Most of QEMU's PCI display device models, such as: >> >> Pushed, thanks. Thanks Pavel! > Ouch, you were too fast! ;) > > There is something I wanted to clarify with Laszlo: is > virtio-gpu-pci ever going to be usable on other architectures > such as x86_64? Maybe it already is? Because if that's the > case, we'll want to be able to choose between virtio-vga and > virtio-gpu-pci. > > One solution would be to keep mapping model='virtio' to > virtio-vga and create a new model='virtio-gpu' that maps to > virtio-gpu-pci, then forbid aarch64 mach-virt guests to use > model='virtio'. Or something like that, I'm not married to > the idea, I just think it's something we should definitely > think about before this ends up in a release. I considered this (I think we may have even discussed something like this downstream, with Marc-André et al... I'm quite vague on it now), but being this precise about it in the domain XML doesn't bring a lot of benefits. Namely, the simple truth is, wherever virtio-vga works, you want virtio-vga. The VGA compat framebuffer is beneficial -- as its name says -- for compatibility reasons, for boot firmware and for unaccelerated (= default) guest OS drivers. For example, in x86_64 guests, you likely never explicitly want virtio-gpu-pci over virtio-vga, because the UEFI Windows (8, 10) boot loaders will never work with the former, but they (and the runtime OSes themselves) nicely work with virtio-vga, due to the compat framebuffer. So, really, virtio-vga is the sane default, and the only reason to ever want virtio-gpu-pci -- as a primary graphics card -- is if virtio-vga is unusable for architectural reasons. Thanks Laszlo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list