Booting ARM64 builds of Windows 10 in QEMU
As you may know, the venerable Quick Emulator (QEMU) supports emulation of the AArch64/ARM64 architecture. With some fiddling over the weekend, I was able to boot and install arm64 builds of Windows 10.
Here's how I did it (feedback welcome):
Warning: This is slow as dirt on an Intel Core i7 4770K
Warning: I have not yet compiled the VirtIO drivers for network and other ancillary devices. That means these machines don't support networking.
Download and install QEMU for Windows
Download the Windows 10 (arm64) ESDs from adguard's whizzbang download page and glue them together using UUPtoISO (patched for arm64) to create a usable ISO
Download my hand-crafted UEFI firmware and recompiled/signed arm64 storage drivers
Create a system.vhdx that's around 23GB or larger (fixed size, not expanding, initialized using GPT partitioning scheme)
Generally glue all the above together in a folder somewhere and create a
windows.cmdwith the following contents:
Run the script.
During setup, you will need to provide VirtIO drivers (browse to the mounted disk).
Complete setup as usual. (This will take a long time.)
For those curious, here's the break down of the QEMU arguments, in order of appearance:
- virtualize a Cortex A57 CPU (with 3 cores)
- set up 4GiB of RAM
- use my recompiled TianoCore EDKII ArmVirtPkg firmware, with minor edits to re-enable VGA support and include a whimsical boot logo to discourage serious usage. (This is similar to the build provided by Googulator in that I reverted two VGA commits. No other changes were made. Latest master.)
- use some scratch space for UEFI variable storage (e.g. boot order)
- use VGA for graphics needs
- set up a NEC USB XHCI Host Controller
- ... and plug four virtualized USB devices into it
- a USB keyboard
- a USB mouse
- a CDROM hosting our install media
- a removable hard drive hosting the VirtIO driver package vhdx
- set up a VirtIO Block Device hosting the main system vhdx
I encourage you to read the QEMU documentation for additional options.
--accel tcg,thread=multifor additional per-core performance gains (Thanks @never_released!)
- The Windows guest may panic at device detection. Click skip when given the option and you should slowly get through.
- The Windows guest may intermittently panic with a Kernel Security Check Failure.
- At first boot, the Windows guest's Compatibility Telemetry runner process will spin up and eat all your CPU cores. Kill the process and performance should greatly increase.