In my previous post I got Windows running on Apple's Virtualization Framework by pure luck. There was one glaring issue: the display driver would not initialize. Today I want to fix that and look into some extra features that can be enabled in the VM to improve the experience.

Legend for AVF blog series

• Part 1: Basic experimentation and intro to AVF
• Part 2: Analyzing UEFI firmware
• Part 3: Analyzing Windows booting + pure luck
• Finale: Enabling the GPU (this post)

Is the GPU even loading?

I used Power-Shell over SSH to determine why the display refused to activate. I simply started the VM with the GPU attached, connected to it over SSH, and ran the following command:

Get-WmiObject Win32_PNPEntity

This command dumps a lot of information. It can be filtered. However, it was easier to scroll through it until I found the GPU. It turns out the GPU did not initialize because of error 28. According to this support article, error 28 means The drivers for this device are not installed..

I tried connecting over RDP again so I could use Device Manager to install the driver manually. Last time I said that RDP did not work if the GPU was attached. Well, I was wrong. Windows did not even activate the GPU, so it should work as if there was no GPU attached. Surely enough, after connecting, I did get display output in RDP. I am not sure why it did not work last time, maybe I was a bit impatient. But after selecting the GPU in Device Manager and selecting the driver, the display activated!

I decided to analyze why Windows did not automatically assign this driver to the GPU. Looking at the INF file of the driver, I found the issue:

[VioGpu.NTamd64.10.0]
%VioGpuDod.DeviceDesc% = VioGpuDod_Inst, PCI\VEN_1AF4&DEV_1050&SUBSYS_11001AF4&REV_01

The setup information for the driver has hardcoded SUBSYS and REV ID's. This is fine for QEMU (the main target of the drivers), but other virtualization software, like AVF, might use different IDs here. I have submitted an issue, and it seems like the devs are willing to make the change.

There is another important issue which I can not fix. The VirtGL driver on Windows is a Display-Only-Deviice (DOD) driver. That means that although it can present video output, there is no 3D acceleration whatsoever, not even OpenGL. Luckily, the folks that are developing the VirtIO drivers for Windows are actively working on creating an accelerated driver. I hope that when this is out, it will work on AVF virtual machines as well. Currently, performance in RDP is better than in the actual VM display because of this, so I recommend using that anyway, even though we now got the driver loaded.

Other stuff

Now that the GPU problems are in the past, I decided to add a few extra devices to the VM to finalize the experience.

Shared folder

AVF supports VirtioFS, a device that allows the guest to directly interact with a folder on the host system.

// Shared directory
let sharedDir = VZSharedDirectory(url: URL(fileURLWithPath: "/Users/aniserrais/"), readOnly: false)
let sharedDirDevice = VZVirtioFileSystemDeviceConfiguration(tag: "userfolder")
sharedDirDevice.share = VZSingleDirectoryShare(directory: sharedDir)
configuration.directorySharingDevices = [sharedDirDevice]

Adding this device to the VM works out of the box on Windows if you have VirtIO Guest Tools installed. You do however need to enable the VirtIO FS service, as it is disabled by default. This service will automatically assign drive letters to shared folders, starting from Z: and going backward down the alphabet:

Shared clipboard

AVF also supports sharing the clipboard using SPICE. Here is the code for it:

// Shared clipboard
let spiceAttachment = VZSpiceAgentPortAttachment()
spiceAttachment.sharesClipboard = true
let spiceSerial = VZVirtioConsoleDeviceSerialPortConfiguration()
spiceSerial.attachment = spiceAttachment
configuration.serialPorts = [spiceSerial]

You need to install SPICE Guest Tools in addition to the VirtIO Guest Tools for it to work. Unfortunately, it does not seem to work inside Windows. I do not exactly know why. All drivers are installed, but the Spice VDAgent service keep shutting down:

Dynamic memory

A memory balloon device can be added to a VM in QEMU and AVF to reallocate memory from the VM during runtime. That way you can decrease the footprint of the VM when necessary. Adding it is very simple:

// Dynamic memory
let memoryBalloon = VZVirtioTraditionalMemoryBalloonDeviceConfiguration()
configuration.memoryBalloonDevices = [memoryBalloon]

Then, during runtime, you can request the VM to free up some memory, eg from 8 to 2 GB:

if let virtioBalloon = machine.memoryBalloonDevices.first as? VZVirtioTraditionalMemoryBalloonDevice {
    // You can change this value even while the VM is running to reallocate memory for the host
    virtioBalloon.targetVirtualMachineMemorySize = 2 * 1024 * 1024 * 1024 // 2 GiB
} else {
    print("Casting failed")
}

Sound

Lastly, AVF also provides an audio driver. Unfortunately, this is another device that is not yet supported inside Windows. The driver developers currently do not have it on their roadmap, since it is a relatively new and unused device.

// Sound
// Unsupported in Windows
let audioDevice = VZVirtioSoundDeviceConfiguration()
let audioInput = VZVirtioSoundDeviceInputStreamConfiguration()
audioInput.source = VZHostAudioInputStreamSource()
let audioOutput = VZVirtioSoundDeviceOutputStreamConfiguration()
audioOutput.sink = VZHostAudioOutputStreamSink()
audioDevice.streams = [audioInput, audioOutput]
configuration.audioDevices = [audioDevice]

The End

Now that Windows is fully functional in Windows (except for sound and 3D accel), I can finally bring this blog series to a satisfying conclusion. I learned a lot during this, and debugging some of the issues was very interesting. Very glad to end it with a happy conclusion.

I have uploaded the updated VM code on the projects GitHub page.

xx Leet