Following that rabbit hole:
I guess my question goes back here to @marmarek.
If I was to follow that path one year later, with Xen 4.17 to expose vmx and svm to trusted testing qube where I would be responsible for trusting it with what I’m testing.
I expect to not be lucky because of Xen upstream bugs or qubes building options being turned off.
What would be the proper path into bringing those for people needing it.
Background of need felt by the community with opened threads and issues
- Android studio needs KVM. I ran into that doing a vulnerability report. And needed another machine to create poc code and be able to run it into Android virtual machine to have a proper workflow. I do not see, in practice why this would be a problem for qube. That android testing VM should be trusted/untrusted accordingly.
- Heads now provides qemu/KVM q35 support for testing and development. When those board are run under Qubes, KVM mode falls back to qemu tcg mode, where installing an OS takes several hours because of IO being emulated instead of virtualized through virtio and KVM kernel support, which when run baremetal is basically near native performance. If unavailable this means my workflow needs to run on baremetal otherwise only basic testing can occur under a qube, making things harder to test/develop.
Those two workflows alone justify to state the actual limitations of permitting, or deploying a Xen-nested additional version under qubes-testing or even qubes-unstable for users to be able to use KVM.
Again: not the other way around: the need is to have Xen support KVM. Not to have Xen (or Qubes) run under nested virtualization.