| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
> 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
need).
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.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home