netdev - Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

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]

Date:	Wed, 23 Dec 2009 09:09:21 -0600
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Kyle Moffett <kyle@...fetthome.net>
CC:	Gregory Haskins <gregory.haskins@...il.com>,
	Ingo Molnar <mingo@...e.hu>, Avi Kivity <avi@...hat.com>,
	kvm@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>
Subject: Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

On 12/23/2009 12:15 AM, Kyle Moffett wrote:
> This is actually something that is of particular interest to me.  I
> have a few prototype boards right now with programmable PCI-E
> host/device links on them; one of my long-term plans is to finagle
> vbus into providing multiple "virtual" devices across that single
> PCI-E interface.
>
> Specifically, I want to be able to provide virtual NIC(s), serial
> ports and serial consoles, virtual block storage, and possibly other
> kinds of interfaces.  My big problem with existing virtio right now
> (although I would be happy to be proven wrong) is that it seems to
> need some sort of out-of-band communication channel for setting up
> devices, not to mention it seems to need one PCI device per virtual
> device.

We've been thinking about doing a virtio-over-IP mechanism such that you 
could remote the entire virtio bus to a separate physical machine. 
virtio-over-IB is probably more interesting since you can make use of 
RDMA. virtio-over-PCI-e would work just as well.

virtio is a layered architecture.  Device enumeration/discovery sits at 
a lower level than the actual device ABIs.  The device ABIs are 
implemented on top of a bulk data transfer API.  The reason for this 
layering is so that we can reuse PCI as an enumeration/discovery 
mechanism.  This tremendenously simplifies porting drivers to other OSes 
and let's us use PCI hotplug automatically.  We get integration into all 
the fancy userspace hotplug support for free.

But both virtio-lguest and virtio-s390 use in-band enumeration and 
discovery since they do not have support for PCI on either platform.

Regards,

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