[jbssm]

I wonder is this opens the door to PCI passthrough in order for the guest system to directly access the GPU.

That is the turning point in all this. No more bootcamp to windows to play games and no more hassle configuring CUDA in OSX, you can just use it from a Linux VM and have all your development system there.

[raimue]

No, Hypervisor.framework will not help with this use case. It is a replacement for the kernel extensions that are currently provided by VMWare/Parallels/VirtualBox to expose the Intel VT-x feature of the CPU.

You would need a way to stop the official kernel extensions from initializing the PCIe device. Then Apple would need to offer a way to map address range and deliver interrupts from the hardware to a process.

[eropple]

And to do so securely, which is a rather different question all on its own.

[veertu]

I hope in the near future Apple will release an API for GPU virtualization. In fact Intel Iris Pro devices already support GVT-d. The problem is that Iris Pro is only used in the expensive Macbook models, the cheaper one come with regular Iris that don't have hardware support for it

[mrpippy]

Although if GVT-d gives the GPU fully over to the VM, which GPU will OS X itself be using? In the high-end 15" MBP, I suppose OS X could switch to the discrete GPU and let the VM use Iris Pro, but it's not a great solution and would only work on (the fairly small number of) dual-GPU Macs.

[veertu]

Actually gpu virtualization works quite similar to cpu. You don't pass a cpu core exclusively to a VM rather the cpu itself maintains independent contexts: for the host and each VM. When a CPU runs a VM it just switches the context. So is the GPU. You don't need two GPUs to make it work.

[jbssm]

I believe it doesn't have too, it can work in a way similar to optimus + prime on the Linux using the GPU.