Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

From: Avi Kivity
Date: Wed Dec 23 2009 - 08:31:37 EST

On 12/23/2009 03:07 PM, Bartlomiej Zolnierkiewicz wrote:

That is a very different situation from the AlacrityVM patches, which:

- Are a pure software concept and any compatibility mismatch is
self-inflicted. The patches are in fact breaking the ABI to KVM
intentionally (for better or worse).
Care to explain the 'breakage' and why KVM is more special in this regard
than other parts of the kernel (where we don't keep any such requirements)?

The device model is exposed to the guest. If you change it, the guest breaks.

So we have two options:
- phase out virtio, users don't see new improvements, ask them to change to vbus/venet
- maintain the two in parallel

Neither appeals to me.

Truth to be told KVM is just another driver/subsystem and Gregory's changes
are only 4KLOC of clean and easily maintainable code..

This 4K is only the beginning. There are five more virtio drivers, plus features in virtio-net not ported to venet, plus the host support, plus qemu support, plus Windows drivers, plus adapters for non-pci (lguest and s390), plus live migration support. vbus itself still has scaling issues.

Virtio was under development for years. Sure you can focus on one dimension only (performance) and get good results but real life is more complicated.

I certainly missed the time when KVM became officially part of core ABI..

It's more akin to the hardware interface. We don't change the hardware underneath the guest.

Overlap and forking can still be done in special circumstances, when a project
splits and a hostile fork is inevitable due to prolongued and irreconcilable
differences between the parties and if there's no strong technical advantage
on either side. I havent seen evidence of this yet though: Gregory claims that
he wants to 'work with the community' and the KVM guys seem to agree violently
that performance can be improved - and are doing so (and are asking Gregory to
take part in that effort).
How it is different from any past forks?

The odium of proving that the existing framework is sufficient was always on
original authors or current maintainers.

KVM guys were offered assistance from Gregory and had few months to prove that
they can get the same kind of performance using existing architecture and they
DID NOT do it.

Look at the results from Chris Wright's presentation. Hopefully in a few days some results from vhost-net.

Then please try harder. Gregory posted his initial patches in August,
it is December now and we only see artificial road-blocks instead of code
from KVM folks.

What artificial road blocks?

error compiling committee.c: too many arguments to function

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at