The removal wasn't random; QemuVideoDxe was broken on Arm and would have required less than trivial fixes.

http://mid.mail-archive.com/20170818130243.4645-1-ard.biesheuvel@linaro.org
http://mid.mail-archive.com/20170822163013.12233-1-ard.biesheuvel@linaro.org

AIUI, the "unalignment faults" affected TCG too, once TCG got smart enough to emulate those traits of the hardware.

I don't mind if we add back QemuVideoDxe, but I would want it to depend on a default-off build time flag in ArmVirtPkg DSC files, and I would not want to see additional complexity in QemuVideoDxe just so it could work on TCG (and continue breaking on KVM). The mere presence of QemuVideoDxe crashed guests on KVM, and even if we hacked around that, the cache coherency issue wouldn't be fixed, and would generate new bug reports.

I don't know about Windows IoT, but for Windows 10, or for at least the server variant thereof, a purely serial IO-based boot should be possible. Has anyone looked into configuring that in BCD somehow?

For starters, where is it written down that a linear framebuffer is strictly required? Can we see a list of requirements? Can we perhaps comment on those requirements?

https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-requirements-that-apply-to-all-windows-platforms states:

"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 issue with PixelBltOnly is that Gop->Blt() depends on UEFI boot services, and is thus no longer available after ExitBootServices(). On UEFI platforms, Windows uses the GOP framebuffer to display boot graphics and error messages before the WDDM stack is initialized, and even after that if a specific WDDM driver isn't available. We could perhaps convince Microsoft to loosen the requirement for a VGA-style linear framebuffer, but Windows absolutely does require a standardized way to display graphics after ExitBootServices() that doesn't depend on platform-specific drivers.

Serial console-based boot is AFAIK only an option in Nano Server, which has been semi-removed in the 1709 update (it's now a Docker exclusive).

I was not aware that the mere presence of QemuVideoDxe in an UEFI image causes KVM guests to crash even if no emulated VGA hardware is present. I was under the impression that in such a scenario, QemuVideoDxe wouldn't even be loaded.

(In reply to netrolller.3d from comment #0)
> In August 2017, QEMU VGA support was removed from ArmVirtQemu and
> ArmVirtQemuKernel, as it doesn't work reliably under KVM. Instead,
> virtio-gpu is now recommended.
> 
> However, virtio-gpu has no linear framebuffer support (it's PixelBltOnly).
> This is a problem for Windows IoT and the new Windows 10 Insider Preview for
> ARM64, which explicitly requires a linear framebuffer to be exposed in the
> UEFI GOP (used for boot graphics, as well as runtime graphics if a more
> specific driver isn't available).
> 
> I have personally tested that reverting the 2 commits that disabled VGA
> support makes Windows 10 insider preview boot under qemu-system-aarch64
> v2.11-rc1 on Linux. I would argue that useful features shouldn't be removed
> just because they don't work under KVM, as long as they work under plain
> QEMU and their mere presence doesn't break KVM. So, I would like to ask for
> QEMU-VGA to be re-enabled in ArmVirtPkg.

I do take your point, but the mere presence of the driver does break KVM, given that the driver will attempt to attach to any VGA devices QEMU/KVM exposes. I hope you can appreciate that we as maintainers are not thrilled to enable something that is likely to result in more support tickets and/or bug reports.

So one possible way forward could be to:
- work with the QEMU maintainers to expose the VGA device under TCG only, and under a different PCI VID/PID
- re-enable QemuVideoDxe on ArmVirtPkg by reverting those two patches
- blacklist the old VID/PID so the driver only attaches to the VGA device that is guaranteed to execute under TCG only.

Note that this is conditional on receiving confirmation from the QEMU maintainers that they have no intention to implement alignment faults on misaligned device memory accesses (which QEMU currently does not care about)

Another option would be to implement framebuffer support based on guest DRAM, which is naturally mapped with the same attributes as host memory, avoiding the coherency issues. This would work both under KVM and TCG, but it does have some lifetime issues (the memory can never be released to the OS). There is some work underway on the QEMU side to implement something like this (ramfb)

Related:

[qemu-devel] [PATCH v2 0/7] ramfb: simple boot framebuffer, no legacy vga
http://mid.mail-archive.com/20180323122520.11270-1-kraxel@redhat.com

Patch email V3 for review

https://lists.01.org/pipermail/edk2-devel/2018-May/025138.html

Updates for V3
==============
* Add Version field to EDKII_FIRMWARE_MANAGEMENT_PROGRESS_PROTOCOL
* Break up patch series into 4 smaller patch series to handle dependencies
  between the edk2 repository and the edk2-platforms repository.
  + Patch series for edk2 repo that adds DisplayUpdateProgressLib class and 
    instances.  Defines the EDKII_FIRMWARE_MANAGEMENT_PROGRESS_PROTOCOL.
    Adds PerformFlashWriteWithProgress() API to the PlatformFlashAccessLib.
  + Patch series for platforms in edk2-platforms that use capsules to add the
    DisplayUpdateProgressLib mapping to the DSC files and add the
    PerformFlashWriteWithProgress() API implementation to the
    PlatformFlashAccessLib implementations.
  + Patch series for platforms in edk2 that use capsules to add the
    DisplayUpdateProgressLib mapping to the DSC files and add the
    PerformFlashWriteWithProgress() API implementation to the
    PlatformFlashAccessLib implementations.
  + Patch for edk2 that adds the use of the DisplayUpateProgressLib and the 
    PerformFlashWriteWithProgress() API .

Ignore comment above.  It is for 801

The EFI framebuffer functionality is now re-enabled in ArmVirtQemu and
ArmVirtQemu kernel, with the contribution of Gerd Hoffmann at Red Hat:

  [edk2] [PATCH v3 0/4] Add QemuRamfbDxe driver
  http://mid.mail-archive.com/20180613072936.12480-1-kraxel@redhat.com

Commit range e03a460f061a..c64688f36a8b.

For using the underlying "ramfb" device model of QEMU, refer to the pending
QEMU patch set:

  [Qemu-devel] [PATCH v5 0/4] ramfb: simple boot framebuffer
  http://mid.mail-archive.com/20180613122948.18149-1-kraxel@redhat.com

On aarch64/KVM, "ramfb" presently suffers from the same coherency issue as
"VGA" before. However, as Ard explained in the edk2 thread linked at the
top,

On 06/13/18 22:30, Ard Biesheuvel wrote:
> There is a notable difference though: this time, the efifb framebuffer is
> identifiable as ordinary [although reserved] memory by the guest, and so I
> think it is reasonable for the efifb driver to check whether the memory is
> covered by a region in the UEFI memory map that has the EFI_MEMORY_WB
> attribute, in which case it is permitted to use a cacheable mapping.

How aarch64 Windows will work on KVM, using ramfb, remains to be seen;
nonetheless, to people that run aarch64 Windows on x86_64/TCG, the
framebuffer is available again.

Thank you, Gerd, for the contribution!

See also: <https://bugzilla.redhat.com/show_bug.cgi?id=1679680>.