From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects Date: Sun, 16 Aug 2009 09:16:07 +0200 Message-ID: <20090816071607.GB29537@elte.hu> References: <20090814154125.26116.70709.stgit@dev.haskins.net> <20090814154308.26116.46980.stgit@dev.haskins.net> <20090815103243.GA26749@elte.hu> <4A870964.9090408@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Gregory Haskins , kvm@vger.kernel.org, Avi Kivity , alacrityvm-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, "Michael S. Tsirkin" To: Anthony Liguori Return-path: Content-Disposition: inline In-Reply-To: <4A870964.9090408@codemonkey.ws> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org * Anthony Liguori 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:) > > I'll let Avi comment about it from a KVM perspective but from a > QEMU perspective, I don't think we want to support two paravirtual > IO frameworks. I'd like to see them converge. Since there's an > install base of guests today with virtio drivers, there really > ought to be a compelling reason to change the virtio ABI in a > non-backwards compatible way. This means convergence really ought > to be adding features to virtio. I agree. While different paravirt drivers are inevitable for things that are externally constrained (say support different hypervisors), doing different _Linux internal_ paravirt drivers looks plain stupid and counter-productive. It splits testing and development. So either the vbus code replaces virtio (for technical merits such as performance and other details), or virtio is enhanced with the vbus performance enhancements. > On paper, I don't think vbus really has any features over virtio. > vbus does things in different ways (paravirtual bus vs. pci for > discovery) but I think we're happy with how virtio does things > today. > > I think the reason vbus gets better performance for networking > today is that vbus' backends are in the kernel while virtio's > backends are currently in userspace. Since Michael has a > functioning in-kernel backend for virtio-net now, I suspect we're > weeks (maybe days) away from performance results. My expectation > is that vhost + virtio-net will be as good as venet + vbus. If > that's the case, then I don't see any reason to adopt vbus unless > Greg things there are other compelling features over virtio. Keeping virtio's backend in user-space was rather stupid IMHO. Having the _option_ to piggyback to user-space (for flexibility, extensibility, etc.) is OK, but not having kernel acceleration is bad. Ingo