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