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

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.