lkml.org 
[lkml]   [2009]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-12-23 16:11    [W:0.767 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site