lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 15 Aug 2009 14:15:48 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Ingo Molnar <mingo@...e.hu>
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

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.

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.

Regards,

Anthony Liguori

> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ