Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Gerd Hoffmann]

  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.  Programming (modesetting) works without legacy vga io
ports, you can use the mmio regs in pci bar 1 instead (applies to both
virtio-vga and stdvga btw), and QemuVideoDxe actually uses the mmio bar.

cheers,
  Gerd