Apple being Apple, the answer is probably yes. But realistically there’s going to be some stupid hurdle in the way and because they make it a PITA nobody’s really going to do it.
Which really sucks because the massive GPU and “unified memory” is incredible when they work in conjunction.
Oh that’s cool! I thought virtio and such were KVM-specific things. I have never been super clear on the relationship between QEMU and the hypervisor itself, like where one ends and the other begins.
The line between what a hypervisor (like KVM) does and what is delegated to a Virtual Machine Monitor - VMM (like QEMU) is fairly blurry. There is always an additional cost to leaving the hypervisor to the VMM so it tends to be for configuration and lifetime management. However VirtIO is fairly well designed so the bulk of VirtIO data transactions can be processed by a dedicated thread which just gets nudged by the kernel when it needs to do stuff leaving the VM cores to just continue running.
I should add HVF tends to delegate most things to the VMM rather than deal with things in the hypervisor. It makes for a simpler hypervisor interface although not quite as performance tuned as KVM can be for big servers.
Apple being Apple, the answer is probably yes. But realistically there’s going to be some stupid hurdle in the way and because they make it a PITA nobody’s really going to do it.
Which really sucks because the massive GPU and “unified memory” is incredible when they work in conjunction.
Like, you can use the GPU on Linux…with Metal
virtio-gpu with Vulkan pass through for the VM with a Vulkan to Metal translator in host user space. There are various talks about this including at KVM forum: https://kvm-forum.qemu.org/2024/The_many_faces_of_virtio-gpu_F4XtKDi.pdf
Is Apple’s tech going to be using KVM machinery then, or are you just saying that it’s possible in general?
No the Apple hypervisor is called hvf, but projects like rust-vmm and QEMU can control and service guests run on that hypervisor. No KVM required.
Oh that’s cool! I thought virtio and such were KVM-specific things. I have never been super clear on the relationship between QEMU and the hypervisor itself, like where one ends and the other begins.
VirtIO was originally developed as a device para-virtualization as part of KVM but it is now an OASIS standard: https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html which a number of hypervisors/VMM’s support.
The line between what a hypervisor (like KVM) does and what is delegated to a Virtual Machine Monitor - VMM (like QEMU) is fairly blurry. There is always an additional cost to leaving the hypervisor to the VMM so it tends to be for configuration and lifetime management. However VirtIO is fairly well designed so the bulk of VirtIO data transactions can be processed by a dedicated thread which just gets nudged by the kernel when it needs to do stuff leaving the VM cores to just continue running.
I should add HVF tends to delegate most things to the VMM rather than deal with things in the hypervisor. It makes for a simpler hypervisor interface although not quite as performance tuned as KVM can be for big servers.