linux-kernel - Re: [RFC PATCH v2 19/19] virtio: add a vbus transport

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A7EFBE8.7050409@codemonkey.ws>
Date:	Sun, 09 Aug 2009 11:40:08 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Gregory Haskins <ghaskins@...ell.com>
CC:	linux-kernel@...r.kernel.org, agraf@...e.de, pmullaney@...ell.com,
	pmorreale@...ell.com, rusty@...tcorp.com.au,
	netdev@...r.kernel.org, kvm@...r.kernel.org, avi@...hat.com,
	bhutchings@...arflare.com, andi@...stfloor.org, gregkh@...e.de,
	herber@...dor.apana.org.au, chrisw@...s-sol.org,
	shemminger@...tta.com, "Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [RFC PATCH v2 19/19] virtio: add a vbus transport

Gregory Haskins wrote:
> We add a new virtio transport for accessing backends located on vbus.  This
> complements the existing transports for virtio-pci, virtio-s390, and
> virtio-lguest that already exist.
>
> Signed-off-by: Gregory Haskins <ghaskins@...ell.com>

Very interesting...

I'm somewhat confused by what you're advocating vbus as.  I'm trying to 
figure out how we converge vbus and virtio and become one big happy 
family :-)

What parts of it do you think are better than virtio?  Should we forget 
about venet and just focus on virtio-net on top of virtio-vbus assuming 
that we can prove venet-tap/virtio-vbus/virtio-net is just as good as 
venet-tap/vbus/venet?

If we can prove that an in-kernel virtio-net 
backend/virtio-pci/virtio-net does just as well as 
venet-tap/virtio-vbus/virtio-net does that mean that vbus is no longer 
needed?

If you concede that the transport mechanisms can be identical, are you 
really advocating the discovering and configuration mechanisms in vbus?  
Is that what we should be focusing on? Do you care only about the host 
mechanisms or do you also require the guest infrastructure to be present?

I think two paravirtual I/O frameworks for KVM is a bad thing.  It 
duplicates a ton of code and will very likely lead to user unhappiness.

Regards,

Anthony Liguori
--
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/