[afr0ck]

I worked at Linaro, who was contracting for Qualcomm. Qualcomm were pushing for some protected hypervisor called Gunyah (which had its own Linux interface and needed a new qemu port) that apparently no one liked. I tried to port it to KVM [1], but upstream folks (mostly Google) outright rejected the port. Otherwise KVM would have been available on QCOM boards. You can still try it. I have a Linux kernel and a Qemu port on my github [2,3]

[1] https://lore.kernel.org/kvm/20250424141341.841734-1-karim.ma...

[2] https://github.com/karim-manaouil/linux-next/tree/gunyah-kvm

[3] https://github.com/karim-manaouil/qemu-for-gunyah

[floatboth]

Upstream would accept a patchset that exposed an independent Gunyah-specific UAPI (why not the same one as downstream — crosvm already supports that) instead of pretending to be KVM (it's not a "port", you can't port a hypervisor to a hypervisor).

KVM is available on current compute platforms (laptops) if you escape to EL2 via slbounce; and on Glymur (X2E) it will be available by default (yay!).

[afr0ck]

That's not how operating systems work. KVM is both an interface and a hypervisor. Just as we have different hypervisor implementations for amd, intel, arm and others all abstracted behind the same KVM interface, there is no reason the same can't be done for Gunyah. Userspace does not have to know anything about that. KVM already supports svm and vmx for amd and intel on x86. Why is something similar can't be done for Arm? Plus now there is pKVM.

I just don't understand this argument of a separate interface. The only reason you want to do that is to decouple from the KVM community, but that introduces a shit tone of duplicated effort and needless fragmentation to the virtualisation software ecosystem hindering your users from enjoying the existing upstream tools they already know about. In other terms, vendor locking and shitty downstream experience.