[Qemu-devel] [Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

[Googulator]

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

Per https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup
/uefi-requirements-that-apply-to-all-windows-platforms, 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
https://github.com/Googulator/edk2/releases. 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: https://www.betaarchive.com/forum/viewtopic.php?p=426768#p426768
The same instructions cause the previously mentioned exception loop when
tried with the Insider builds.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1717708

Title:
  QEMU aarch64 can't run Windows ARM64 iso's

Status in QEMU:
  New

Bug description:
  Hi,
  recently Windows ARM64 ISOs have been posted on the internet..
  just checked with latest QEMU 2.10 release from 
  https://qemu.weilnetz.de/w64/qemu-w64-setup-20170830.exe 
  "h:\qemu\qemu-system-aarch64.exe" -boot d -cdrom 
h:\iso\16353.1000.170825-1423.RS_PRERELEASE_CLIENTPRO_OEMRET_ARM64FRE_ES-ES.ISO 
-m 2048 -cpu cortex-a57 -smp 1 -machine virt
  seems no video output..
  checked various machine options for example versatilepb (says guest has not 
initialized the guest)..

  so don't know if it's a QEMU bug or lacking feature but can support
  running Windows ARM64 builds (would be nice if you can add a
  Snapdragon835 machine type which is which first machines will be
  running..)

  
  note running a Windows x64 ISO with similar parameters works (removing -cpu 
and -machine as not needed)

  thanks..

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1717708/+subscriptions