While I appreciate the efforts to add clean qemu/kvm integration in
upstream, it's driving me mad.
Every merge I'm faced with regressions (mostly due to changing code,
not to upstream breakage) and need to fix things. Work done during
merges is very likely to contain errors since there's no incremental
change to review and test.
We now have two very different kvm implementations:
The upstream implementation:
- mostly clean
- crippled
- no smp
- no kernel irqchip
- no kernel pit
- no device assignment
- reduced support for older host kernels
- no ia64 support
- no nmi support
- no tpr patching
- almost totally untested (small userbase)
The downstream implementation:
- a tangled mess
- featureful and performant
#include <features from above>
- heavily tested (kvm-autotest, large kvm userbase, inclusion in distros)
What we have here is the classic rewrite fallacy (rewriting from
scratch is easier than fixing, now six months into the voyage with no
end in sight) coupled with inflicting pain to the largest contributor
to qemu (I mean the kvm community, not me personally). Meanwhile, new
kvm kernel features need to be implemented twice in userspace.
I propose that we stop this. It is fragmenting the development
effort, causing regressions (again, mostly through merge issues, but
also through new code duplicating old code incorrectly), and not
really helping upstream qemu. It's also the first case I've heard of
where a project competes with itself (well not really but it's a nice
soundbite).
As a first step I've merged a copy of libkvm into qemu linkage (i.e.
not as a library), so we can start to use the upstream code (say, use
kvm_ioctl() from libkvm.c). It's not going to be easy, but what we
have now isn't working.