[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

From: Marc Zyngier
Subject: Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA
Date: Mon, 27 Jul 2015 08:52:54 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0

Hi Gerd,

On 25/07/15 10:49, Gerd Hoffmann wrote:
>   Hi,
>>> I agree. Also, as far as I understood Marc, his hope was that the fix to 
>>> halfway working VGA emulation would be virtio-gpu.
> Note we have both virtio-vga and virtio-gpu-pci.  virtio-vga has vga
> compatibility built-in, otherwise the two are identical.  virtio-gpu-pci
> is enabled along with all other virtio drivers, so arm + aarch64 have
> that already.
>> 2) Use the fact that there is actually hardly any legacy for ARM VMs,
>> and embrace paravirtualized devices entirely. We do it for disks,
>> network interfaces. Why not display? Why not input?
> We have both now (qemu 2.4+, linux 4.1+ for input, linux 4.2+ for gpu).
> Works just fine on arm (tcg tested).  aarch64 not yet (with vanilla
> upstream linux kernel) due to lack of generic pci host support.
>> Using VGA makes sense on x86 because this is a standard on that
>> platform. Every system has one. You can't expect the same thing on ARM
>> (evil persons would even say that you can't expect anything at all). So
>> let's take this opportunity to use the best tool for the job. Virtio
>> fits that bill pretty well apparently.
> Big question is (a) whenever we need a firmware framebuffer and (b) how
> to implement that best.
> virtio-vga/virtio-gpu-pci in paravirt (native) mode requires the guest
> explicitly request screen updates.  There is no dirty page tracking, and
> guest writes to memory do *not* magically appear on the screen.  I don't
> think implementing a EFI driver for that is going to fly.
> virtio-vga in vga-compat mode uses a framebuffer with the usual dirty
> tracking logic in pci bar 0 (simliar to stdvga).  Which is exactly the
> thing causing the cache coherency issues on aarch64 if I understand
> things correctly. 

If this new virtio-vga driver still insists on always mapping the memory
as "non-cacheable", then it will face the same fate indeed. Which is a
bit odd, as it really *knows* this is a paravirtualized device, and that
the data will be read back from the CPU side.

The dirty tracking logic plays no part in that, AFAIK.


Jazz is not dead. It just smells funny...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]