[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.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, (continued)
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, Laszlo Ersek, 2015/07/20
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, Laszlo Ersek, 2015/07/20
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, Alexander Graf, 2015/07/21
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, Laszlo Ersek, 2015/07/21
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, Marc Zyngier, 2015/07/21
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, Gerd Hoffmann, 2015/07/25
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, Laszlo Ersek, 2015/07/26
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, Peter Maydell, 2015/07/26
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, Peter Maydell, 2015/07/26
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA, Laszlo Ersek, 2015/07/26
- Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA,
Marc Zyngier <=