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

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

[Avi Kivity]

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

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

[Anthony Liguori]

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