Re: [libvirt] [PATCH v2] qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64)
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