Re: [libvirt] [PATCH v2] qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64)
On 09/16/16 15:32, Martin Kletzander wrote:
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.
I'm not sure if you are asking me :), but I'll answer anyway :)
We guarantee that on x86_64 primary video devices have
always VGA compatibility mode?
Yes.
So virtio-gpu-pci will *never* be able
to act as a primary video on x64?
I wouldn't put it this way. Dependent on your firmware and on your guest
OS, virtio-gpu-pci *can* act as a primary video card on x86_64 too, but:
- some guest OSes (notably UEFI Windows) will be plain unable to work
with it,
- even with other OSes (for example, UEFI Linux), virtio-gpu-pci will
work, but the functionality that you will get with virtio-gpu-pci in
both the firmware and in the OS will be somewhat limited related to the
virtio-vga feature set. Namely, in UEFI you will only get a
GRAPHICS_OUTPUT_PROTOCOL that only supports Blt(), no direct framebuffer
access -- and some UEFI applications / boot loaders might insist on
framebuffer access --, plus in Linux, until the virtio-gpu driver kicks
in and you get "virtiodrmfb" fired up, you will have an initial window
in time where the graphics display doesn't work for simple text output
even. (In more technical terms, the "efifb" driver has no chance of
working, until the virtio-gpu drmfb driver supplants it, because efifb
also depends on framebuffer access).
So, while virtio-gpu-pci *could* work on x86_64 as a primary graphics
card, you really don't want it, because virtio-vga is just better.
In aarch64/KVM guests, the choice is however between "somewhat limited,
with virtio-gpu-pci" and "completely non-functional".
Using a graphics card as primary that was originally designed as
secondary is quite unusual for a number of programs; this is why I had
to send a patch for Xorg/Xserver too (the card wouldn't be picked up
automatically otherwise, as primary). This is simply how video tends to
work on aarch64, even on phys hardware; the Xorg/Xserver patch in
question happened to solve the identical problem for Marcin's physical
Mustang + Radeon setup.
If the answers are "yes, yes", then I
think this patch can stay as it is. Unless I missed something else.
The answer is "practically yes". Virtio-gpu-pci *could* act as a
(limited) primary video device in x86_64 guests, but due to those
limitations (whose annoyances vary across guest OSes) you really
wouldn't want to pick virtio-gpu-pci as primary there.
Thanks
Laszlo