Comment 10 for bug 1717708

(1) See also <https://bugs.launchpad.net/qemu/+bug/1717708>.

(2) One idea is (a) letting Windows use VirtioGpuDxe's GOP (blt only) until it calls ExitBootServices() -- which I have already confirmed to work with an ARM64 Windows Server variant that I was legally given access to --, and (b) once available, injecting a native ARM64 virtio-gpu-pci driver into the installer image, which Windows could start using right after ExitBootServices().

(3) BTW, Gerd recently posted

[Qemu-devel] [PATCH 0/4] ramfb: simple boot framebuffer, no legacy vga
http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg03299.html

which could be an alternative. (Albeit -- in my opinion! -- inferior to (2).)

(4) In the above-referenced article at <https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-requirements-that-apply-to-all-windows-platforms>, Microsoft write, "Microsoft welcomes feedback and comments from implementers on this set of requirements". That sounds awesome: for a change, how about we stop reverse engineering Windows boot (off of lawfully obtained media of course) and engage in a conversation. Writing VirtioGpuDxe wasn't trivial, and I'm not amused at the thought of (a) it being a waste, (b) struggling with more and more hacks / custom devices & drivers until one set happens to work. We should stop fabricating one-sided hacks for placating Windows.

(5) Can we please stop making references to leaked or otherwise unlawfully obtained Windows media, and warez sites. In the upstream QEMU bug tracker no less. Thanks.