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
