As far as I can tell, when emulating ONLY mips targets in Qemu, by setting QEMU_SOFTMMU_TARGETS="mips mips64 mipsel mips64el" (or equivalent), KVM support offers no benefit. It seems KVM only works for non-x86 archs PPC and S/390, so forcing KVM as a requirement (if USE kernel_linux) for anything else is unnecessary. I see that qemu_support_kvm() is defined to check QEMU_SOFTMMU_TARGETS for supported KVM arches, but in src_configure, we have this: conf_softmmu() { if [[ ${buildtype} == "user" ]] ; then echo "--disable-${2:-$1}" else use_enable "$@" fi } [snip] conf_opts+=( ... $(conf_softmmu kernel_linux kvm) ... ) Which doesn't utilize qemu_support_kvm() to make KVM support optional or not. I hacked around this locally for 2.4.1, and aside from some complaints by the other KVM checks in the ebuild, the resulting 'qemu-system-mips' binary runs fine (so far) and can execute a Debian/MIPS netboot image. If I think about the logic some more, I might make my local hack more suitable for the tree, but if you guys have a better idea, especially one that can leverage qemu_support_kvm(), that's probably the better route to go. Only real motivation for this bug is I don't compile KVM into my running kernel as I rarely run VMs or hypervisors on that particular box. Didn't feel like rebuilding the host kernel :) (excluding 'emerge --info' output, as it's not relevant for this bug).
And I just figured out that qemu won't work for the little experiment I was planning. No need to pursue this issue, unless you guys really want to.
the kvm flag doesn't mean that the softmmu binary will *use* kvm at runtime, just that it's available for you if you want it. binaries built w/kvm enabled will run just fine on systems w/out kvm available. on the mips front, there is code that depends on kvm: target-mips/kvm.c
