Hi Ingo,
1) First off, let me state that I have made every effort to propose this
as a solution to integrate with KVM, the most recent of which is April:
http://lkml.org/lkml/2009/4/21/408
If you read through the various vbus related threads on LKML/KVM posted
this year, I think you will see that I made numerous polite offerings to
work with people on finding a common solution here, including Michael.
In the end, Michael decided that go a different route using some of the
ideas proposed in vbus + venet-tap to create vhost-net. This is fine,
and I respect his decision. But do not try to pin "fracturing" on me,
because I tried everything to avoid it. :)
Since I still disagree with the fundamental approach of how KVM IO
works,
Prior to my effort, KVM was humming along at the status quo and I came
along with a closer eye and almost doubled the throughput and cut
latency by 78%. Given an apparent disagreement with aspects of my
approach, Michael went off and created a counter example that was
motivated by my performance findings.
Therefore, even if Avi ultimately accepts Michaels vhost approach
instead of mine, Linux as a hypervisor platform has been significantly
_improved_ by a little friendly competition, not somehow damaged by it.
4) Lastly, these patches are almost entirely just stand alone Linux
drivers that do not affect KVM if KVM doesn't wish to acknowledge them.
Its just like any of the other numerous drivers that are accepted
upstream into Linux every day. The only maintained subsystem that is
technically touched by this series is netdev, and David Miller already
approved of the relevant patch's inclusion:
http://lkml.org/lkml/2009/8/3/505
So with all due respect, where is the problem? The patches are all
professionally developed according to the Linux coding standards, pass
checkpatch, are GPL'ed, and work with a freely available platform which
you can download today
(http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=summary)