This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] iscsi

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] iscsi
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 21 Jan 2004 18:13:19 +0000
Cc: Kip Macy <kmacy@xxxxxxxxxxx>, Rolf Neugebauer <rn@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 21 Jan 2004 18:14:54 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Wed, 21 Jan 2004 17:43:49 GMT." <E1AjMOM-00082o-00@xxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> 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

<Prev in Thread] Current Thread [Next in Thread>