[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090816071607.GB29537@elte.hu>
Date: Sun, 16 Aug 2009 09:16:07 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Anthony Liguori <anthony@...emonkey.ws>
Cc: Gregory Haskins <ghaskins@...ell.com>, kvm@...r.kernel.org,
Avi Kivity <avi@...hat.com>,
alacrityvm-devel@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for
vbus_driver objects
* Anthony Liguori <anthony@...emonkey.ws> wrote:
> Ingo Molnar wrote:
>> * Gregory Haskins <ghaskins@...ell.com> 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@...ell.com>
>>> ---
>>>
>>> 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists