[lkml]   [2009]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
    Ingo Molnar wrote:
    > * Gregory Haskins <> wrote:
    >> Ingo Molnar wrote:
    >>> * Gregory Haskins <> 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 <>
    >>>> ---
    >>>> 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:
    > 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:

    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:

    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:

    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

    Kind Regards,

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2009-08-17 17:07    [W:0.028 / U:5.440 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site