Re: issues with emulated PCI MMIO backed by host memory under KVM

[Gerd Hoffmann <kraxel@redhat.com>]

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