Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driverobjects

[Gregory Haskins]

Ingo Molnar wrote:
> * Gregory Haskins <gregory.haskins@xxxxxxxxx> wrote:
> 
>> Ingo Molnar wrote:
>>> * Gregory Haskins <ghaskins@xxxxxxxxxx> wrote:
>>>
>>>> This will generally be used for hypervisors to publish any host-side
>>>> virtual devices up to a guest.  The guest will have the opportunity
>>>> to consume any devices present on the vbus-proxy as if they were
>>>> platform devices, similar to existing buses like PCI.
>>>>
>>>> Signed-off-by: Gregory Haskins <ghaskins@xxxxxxxxxx>
>>>> ---
>>>>
>>>>  MAINTAINERS                 |    6 ++
>>>>  arch/x86/Kconfig            |    2 +
>>>>  drivers/Makefile            |    1 
>>>>  drivers/vbus/Kconfig        |   14 ++++
>>>>  drivers/vbus/Makefile       |    3 +
>>>>  drivers/vbus/bus-proxy.c    |  152 +++++++++++++++++++++++++++++++++++++++++++
>>>>  include/linux/vbus_driver.h |   73 +++++++++++++++++++++
>>>>  7 files changed, 251 insertions(+), 0 deletions(-)
>>>>  create mode 100644 drivers/vbus/Kconfig
>>>>  create mode 100644 drivers/vbus/Makefile
>>>>  create mode 100644 drivers/vbus/bus-proxy.c
>>>>  create mode 100644 include/linux/vbus_driver.h
>>> Is there a consensus on this with the KVM folks? (i've added the KVM 
>>> list to the Cc:)
>>>
>>>
>> Hi Ingo,
>>
>> Avi can correct me if I am wrong, but the agreement that he and I 
>> came to a few months ago was something to the effect of:
>>
>> kvm will be neutral towards various external IO subsystems, and 
>> instead provide various hooks (see irqfd, ioeventfd) to permit 
>> these IO subsystems to interface with kvm.
>>
>> AlacrityVM is one of the first projects to take advantage of that 
>> interface.  AlacrityVM is kvm-core + vbus-core + 
>> vbus-kvm-connector + vbus-enhanced qemu + guest drivers.  This 
>> thread is part of the guest-drivers portion.  Note that it is 
>> specific to alacrityvm, not kvm, which is why the kvm list was not 
>> included in the conversation (also an agreement with Avi: 
>> http://lkml.org/lkml/2009/8/6/231).
> 
> Well my own opinion is that the fracturing of the Linux internal 
> driver space into diverging pieces of duplicate functionality 
> (absent compelling technical reasons) is harmful.

[Adding Michael Tsirkin]

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, I am continuing my effort in the downstream project "AlacrityVM"
which will hopefully serve to build a better understanding of what it is
I am doing with the vbus technology, and a point to maintain the subsystem.

2) There *are* technical reasons for this change (and IMHO, they are
compelling), many of which have already been previously discussed
(including my last reply to Anthony) so I wont rehash them here.

3) Even if there really is some duplication here, I disagree with you
that it is somehow harmful to the Linux community per se.  Case in
point, look at the graphs posted on the AlacrityVM wiki:

http://developer.novell.com/wiki/index.php/AlacrityVM

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)


Kind Regards,
-Greg

Attachment: signature.asc
Description: OpenPGP digital signature