Comment 6 for bug 1717708

Googulator (netrolller-3d) wrote :

virtio-gpu-pci will not work for booting Windows.

Per, Windows currently requires a linear framebuffer to be exposed through the UEFI Graphics Output Protocol:

"Windows requires the Graphics Output Protocol (GOP). Specific frame buffer requirements are:

    For integrated displays, HorizontalResolution and VerticalResoluton must be the native resolution of the panel.

    For External displays, HorizontalResolution and VerticalResoluton must be the native resolution of the display, or, if this is not supported, then the highest values supported by both the video adapter and the connected display.

    PixelsPerScanLine must be equal to HorizontalResolution.

    PixelFormat must be PixelBlueGreenRedReserved8BitPerColor. Note that a physical frame buffer is required; PixelBltOnly is not supported.

When execution is handed off to a UEFI boot application, the firmware boot manager and firmware must not use the frame buffer for any purpose. The frame buffer must continue to be scanned out after boot services have exited."

The virtio-gpu driver uses PixelBltOnly, which Windows explicitly doesn't support. Also, IIRC the Gop->Blt() handler of virtio-gpu is only available while UEFI Boot Services are active (before ExitBootServices() is called, which is something the Windows boot manager does very early), so even if Microsoft tried to implement Gop->Blt() support in the MSBDA driver, it couldn't be used with virtio-gpu, as its Gop->Blt() is not available at run time.

Instead, "-device VGA" is required.

Mainline edk2 is currently unable to boot any Windows images due to some required features being removed as they aren't compatible with KVM (I don't quite get it - UEFI for aarch64 virt is supposed to be for qemu in general, not exclusive to KVM...), however I actually have a fork with these features restored, available at This is able to boot the leaked Windows Server 2016 beta builds 14282, 14324 and 14877, but not 14901 or any of the Windows 10 Insider builds, due to an exception loop very similar to that seen when trying to run SBSA-ACS.

Also, the only storage option Windows can actually read and boot from is USB mass storage over EHCI - anything else is either lacking drivers (virtio-scsi and the various emulated LSI Logic adapters) or fails to start due to a resource conflict (AHCI, UAS, USB mass storage over XHCI). Detailed instructions for booting the leaked builds are available here: The same instructions cause the previously mentioned exception loop when tried with the Insider builds.