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

Re: [Xen-devel] Really really small xen0



> Does it even need an init.exe? or a mounted file system? 

These are necessary if you're not going to try hacking in the kernel, purely 
to stop Linux getting upset.  The init doesn't have to do anything and the 
filesystem can be empty (apart from the init).  Using a suitable filesystem, 
you can make the initrd really small.

> Couldn't the 
> kernel just jump into a kernel thread xen idle loop? Would it then be
> possible to have this minimal xen0 linked in to xen?

You might be able to hack the init kernel thread to just block but it's not 
clear there's much advantage over having a userspace init that just blocks.  
You still might find Linux wants to mount *something* at boot, though.

I can check the mini init into the unstable tree as it might be useful to some 
people someday.

> I guess there needs to be some way of communicating the parameters to
> the xen kernel. 

Yeah.  For the minimal driver kernels, we had the backend driver in the domain 
automatically set up bridging, etc.  For flexibility and cleanness, we now 
set this up all from userspace.

We already have a generic control message framework for passing messages to 
other domains from domain 0.  We'd need to add some more message types in 
order to issue bridge setup commands, etc.

> Is the ether bridging done in xen? or in domain 0?

Xen itself doesn't know / care about devices, the bridging is done in domain 
0.  The "backend" network driver runs in dom0 and creates a virtual ethernet 
device to talk to each "frontend" network interface in an unprivileged 
domain.  The standard Linux bridging / routing code is then used to bridge / 
route those virtual interfaces.  So it all happens in dom0.

> Maybe  
> it can be driven by an initrd in xen0.

You could put some extra tools in the initrd in the driver domain but you'd 
still to figure out some way of telling them how to bridge / route new VIFs 
as domains are started.  I suppose you could hack Xend to issue commands to 
the console interface, although that seems a bit skanky to me ;-)

> Could you then still have another privileged domain do status
> monitoring, and user domain startup/shutdown?

In principal you could get Xen (with some hacking to add the required 
functionality to XenLinux / Xend) do something like this.  This done, you 
could be able to run a driver for each block / net device in a separate 
domain and admin stuff in yet another.

Many of the pieces required for this are in place now.  There is a bit of a 
chicken and egg problem regarding how these domains get built in the first 
place (how does the driver domain get built without the admin domain / how 
does the admin domain load without the driver domain) but it's surmountable 
(e.g. use some large initrds!).

This is quite interesting stuff, it's just not been as high priority as some 
of the other features in the release.

HTH,
Mark


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

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