On Di, 2016-06-28 at 15:32 +0200, Laszlo Ersek wrote: > (adding Gerd) > > On 06/28/16 15:14, Ard Biesheuvel wrote: > > > In any case, reconciling software that requires a framebuffer with a > > GPU emulation that does not expose one by design is going to be > > problematic even without this issue. How is this supposed to work on > > x86? > > AFAIK: > > "virtio-gpu-pci" is the device model without the framebuffer. It is good > for secondary displays (i.e. those that you don't boot with, only use > after the guest kernel starts up). > > "virtio-vga" is the same, but it also has the legacy VGA framebuffer, > hence it can be used for accommodating boot loaders. (Except it won't > work for aarch64 KVM guests, because of $SUBJECT.) Exactly. virtio-vga is basically virtio-gpu-pci + stdvga combined. Power-on default is vga mode. It switches into virtio mode when the guest configures a output using virtio commands. It switches back to vga mode on reset. You can get a simple framebuffer by using the stdvga part of the device. QemuVideoDxe does exactly that. The linux kernel switches from vga mode (efifb) to virtio mode when the virtio-gpu kms driver loads. Of course virtio-vga in vga mode has exactly the same cache coherency issues as stdvga on arm. So, once the linux kernel with the virtio-gpu is up'n'running everything is fine, but how to handle early bootloader display isn't solved yet. cheers, Gerd _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
