[libvirt] [PATCH v2] qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64)

[Laszlo Ersek]

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