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
