[Qemu-devel] Need a new plan on adding kvm support to qemu

[Avi Kivity <avi@redhat.com>]

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.

-- 
error compiling committee.c: too many arguments to function