Re: Need a new plan on adding kvm support to qemu

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> 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.

I'm with you.  I think at this point we should try to make the qemu-kvm 
code use the upstream QEMU code where ever possible and then refactor 
the qemu-kvm into a mergable state.

A good second step would be getting rid of libkvm entirely.

Regards,

Anthony Liguori