Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Marc Zyngier <marc.zyngier@arm.com>]

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.

Thanks,

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