Microsoft tweaks Windows 10 on Arm64 to play nicely with KVM
Put away the glue and duct tape, and luxuriate in virtualised goodness
A funny thing has happened on the way to 19H1: an Azure OS kernel engineer tweaked Windows 10 to make the operating system considerably more KVM-friendly.
Reg reader Waseem drew our attention to a GitHub thread, which consisted mostly of FOSS fans working on the drivers needed to get the Arm version of Windows 10 up and running on a variety of hardware (including Android phones).
This, in itself, is nothing too new. Since Windows 10 on Arm first appeared, an army of tinkerers have been attempting to run the thing on hardware other than the first wave of Snapdragon-based notebooks. A lot of effort has been focused on the Quick EMUlator (QEMU), the Linux incarnation of which has seen some success in getting the OS running.
Indeed, this Reg hack managed to run up Windows 10 on a Raspberry Pi Model 3 Model B+ last year. However, neither Windows 10 nor the Pi enjoyed the experience very much, and performance could charitably be described as glacial.
QEMU performance under Linux can be hugely improved by throwing the Kernel-based Virtual Machine (KVM) module into the mix, adding hardware-assisted virtualisation.
The theory has been that if you're running Windows 10 on Arm using QEMU and the right hardware, enabling KVM should make Windows 10 run at near-native speed rather than having to navigate the various duct-taped drivers and firmware to persuade the OS to boot.
Alas, KVM and Windows 10 simply didn't play nicely.
It's not you, it's us
Over a year after developers first began to puzzle over the problem, GitHub user pmsjt (aka Microsoft's Pedro Justo) weighed in. Justo first pondered whether KVM could be "enhanced" to deal with the needs of Windows 10 before opting to simply get Microsoft's operating system changed instead.
The upshot was that from build 18348 of 19H1, unleashed on Insiders back on 1 March, KVM should, well, just work.
According to Justo:
This build will have been compiler [sic] with new versions of WRITE_REGISTER_ and READ_REGISTER_ which avoid the compiler using the instructions KVM does not like. This means PCI/SYS MSIX code and GPIO will no longer cause problems. GICv3 without EL3 has also been fixed in the same wave.
The Insider team itself merely pointed out there were some new emojis – rather than explaining Microsoft had taken the step of spotting a problem in the OS that was stopping it working with a popular FOSS component and getting the code tweaked in a matter of weeks.
Justo remarked "any Windows build numbered 19H1_release/18348.190226-1407 or higher should be able to boot fine on KVM, without workarounds or limitations."
20H1 has also received the modification.
Of course, things aren't all gravy just yet. The virtio-net driver has continued to misbehave, meaning that KDNET must be configured for networking, and some users have reported issues with audio. However, being able to run with KVM enabled will strip out the overhead of emulation on the right hardware.
As for why Microsoft would do such a thing, the answer is a pointer to the seismic shifts that have happened within the company over the last few years. Justo told El Reg: "KVM is a huge tool for us and for our partnering ISVs, so we've been investing in making sure Windows 10 on ARM64 works great on Linux/KVM."
He then donned his engineering hat to add "KVM is an engineering tool for us, for testing the OS and drivers. Also, QEMU/KVM as [sic] usually tuned to ARMH spec by ARMH architects themselves, which means that something not running under QEMU usually indicates a problem in the OS following the spec, not QEMU."
Some have speculated on the technology being used to spawn Arm-based Azure data centres running Windows virtual servers on Linux, but this does not appear to be on the roadmap (for now, at any rate).
It does, however, both demonstrate the company's willingness to contribute to the FOSS community and also the sway the Azure team has over Windows 10, even with 20H1 still more than a year away. ®
Sponsored: Beyond the Data Frontier