[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] iscsi

> On a more general note, Xen currently assumes that all vbds are
> backed by local disk. We need a mechanism to 'plumb' a specified
> vbd such that read/write requests go to another domain (where
> arbitrary processing can be performed) rather than out to local
> disk.
> We need this for a whole bunch of different applications people
> want to use Xen for (honeypots, debugging, fault injection,
> hardware transparency etc.).
> Fortunately, this kind of thing is going to be quite a bit easier
> under the ring-1 I/O model. I think the performance will be
> pretty good -- we'll never copy data, and attempt to minimize the
> number of protection domain switches through pipelining.

Exactly. VBD requests will go directly to the domain containign teh
device driver (via some shared memory comms model). That domain can
implement whatever it needs without having to bloat Xen at all (e.g.,
you could run a full-blown OS, with a TCP stack and anything else you

In future I don't think that any of the block-device or network code
(not even the VBD interface) will reside in Xen -- it can all be done
in driver domains.

 -- Keir

The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.