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

[Martin Kletzander]

On Fri, Sep 16, 2016 at 03:20:16PM +0200, Pavel Hrdina wrote:
>On Fri, Sep 16, 2016 at 03:06:18PM +0200, 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.
>>
>> 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 have some patches in my TODO branch that will rewrite the video
>device code. virtio-gpu-pci is usable also on other architectures
>but it lacks the VGA compatibility mode.  In libvirt all primary
>video devices for x86 architecture have VGA mode.  Currently we
>allow only QXL to be used as secondary video device and now with
>the virtio-gpu-pci it could be also used as secondary video device.
>
>The solution would be simple, there is no need to add a new video
>model 'virtio-gpu', we will use the existing model 'virtio', but
>depending on architecture and also whether it's primary or
>secondary video device we will use appropriate device.
>We already do this for QXL.
>

I'm not sure we're on the same track, so just to confirm I'll ask few
questions.  We guarantee that on x86_64 primary video devices have
always VGA compatibility mode?  So virtio-gpu-pci will *never* be able
to act as a primary video on x64?  If the answers are "yes, yes", then I
think this patch can stay as it is.  Unless I missed something else.

>Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160916/c41b8ff8/attachment-0001.sig>