WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen 1.3 I/O

To: "Barry Silverman" <barry@xxxxxxxxx>
Subject: Re: [Xen-devel] Xen 1.3 I/O
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Sat, 27 Mar 2004 10:15:18 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Sat, 27 Mar 2004 10:17:34 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Fri, 26 Mar 2004 21:28:32 EST." <000201c413a3$34398b80$6400a8c0@gandalf>
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
> I have been tracking the 1.3 I/O update quite closely, and have a
> reasonable idea of how the low level mechanisms work.
>  
> Is there a roadmap document that describes where Xen I/O is going at a
> high level?

We've had a number of meetings and phone-conferences, but I'm
afraid nothing is written down as yet.
  
> IE - Will the Hardware I/O drivers be removed from Xen, and moved into a
> special I/O manager domain (or Domain 0)

Yes. You'll be able to run all the drivers in domain 0, or create
other 'driver domains' to delegate control of specific bits of
hardware. The advantage of the latter is that you should get
fault containment : if a device driver domain fails, the system
should be able to kill and restart it (unless its done anything
really nasty like hang the PCI bus or DMA all over memory, but
such faults are pretty rare).

>        Will there be a stub (just drivers, and not much else) linux
> kernel running in a privileged domain just for servicing hardware to
> other domains that don't map the hardware?

Yes, that'll be one configuration option.

>        Will Domain 0 continue to do its own hardware I/O?

Each piece of hardware has to be directly controlled by exactly
one domain, and then virtualized to all the other domains that
use it.

>        Will it be possible to have complicated mappings of privileged
> domains that each control different bits of hardware, and have them
> service I/O to arbitrary sets of non-privileged domains?

That's the plan!

We expect that most people will run all the devices drivers in
domain 0, but for high-availability situations people can
can configure separate driver domains. There shouldn't be much
performance difference between the two setups, apart from some
improved batching of interrupts. 

Ian



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

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