Re: Xen?

[Espen Skoglund]

[Ian Duggan]
> Does anyone have plans to get any of the current L4 kernels working
> with Xen?

Two questions: 1) What do you mean by "working with Xen"?  Do you mean
porting, e.g., L4Ka::Pistachio to run on top of the "Xen virtual
ia32-like archiecture"?  2) What do you want to achieve by doing this?

Understand that Xen and L4 in some cases share common goals.  In
particular, both projects want to simultaneously run multiple OS
instances on top of the microkernel/hypervisor.  Naturally, we, the L4
people, believe that our way of achieving these goals are the better
way (for some definition of "better").

It is not given that running L4 on top of Xen necessarily give you
advantages.  On the contrary, by doing so you take away the
possibility of the system(s) running on top of L4 to communicate with
other subsystems (i.e., those VMs running on top of native Xen).
Using the microkernel based scheme, it *is* possible for a
subsystem/VM to communicate directly with other subsystems, enabling
us to implement, e.g., secure, tamper-proof or real-time capable
subsytems.

The microkernel based approach also has the advantage that it does not
rely on any hardware "hacks" in order to provide a virtualized
environment.  The microkernel provided abstractions used to separate
subsystems/VMs are well understood and applicable to all hardware
architectures.

> This one bit from the TODO shares some goals with uKernels:

> =====================================
> We'd also like to experiment moving the network and block device
> drivers out of Xen, and each into their own special domains that are
> given access to the specific set of h/w resources they need to
> operate.  This will provide some isolation against faulty device
> drivers, potentially allowing them to be restarted on failure. There
> may be more context switches incurred, but due to Xen's pipelined
> asynchronous i/o interface we expect this overhead to be amortised.
> This architecture would also allow device drivers to be easily
> upgraded independent of Xen, which is necessary for our vision of Xen
> as a next-gen BIOS replacement.
> =====================================

This does indeed overlap with some of the microkernel philosophy, and
complies with a trend that can be seen in the current OS literature.
I don't know wheter Xen aims at abstracting things like interupt
routing and access to I/O ports, or if they just want to provide
mechanisms to delagete some privileges to the device drivers.  All I
can tell is that L4 already has a well defined way of dealing with
user-level device drivers.  It will be interesting to see what Xen
comes up with.

        eSk