Xen (for those who aren't aware) runs on x86 and creates a virtual machine. It's not at all unlike VMWare in this sense.
It has a hypervisor which (to my understanding) is a layer between the host operating system and the guest operating system. The hypervisor essentially translates the guest OSes traps into executing code on the host OS.
I have proposed what amounts to two parallel layers of abstraction.
The first is that each user is effectively in their own sandbox. My vision for this is roughly equivalent to booting DOS or CP/M on a system. They are effectively the root user in that compartment. We'll call this the user compartment or UC.
Permissions on the actual system are controlled here. For example, you don't necessarily want to allow any given user to start up a spam bot, so you might remove the ability to interact with the network interface.
If the user chose, this system could execute completely on its own with in theory no more hardware assigned to it than I/O.
The second layer is roughly equivalent to the loader. When the user executes a file, this layer loads the file into memory and loads whatever programs are needed to execute it. This is what I call the execution environment loader or EEL. I have three main examples of how this is intended to work.
1) I execute DSC0001.JPG.
The EEL loads the registered image viewer with DSC0001.JPG as an argument. Windows Explorer does this in a frequently embarrassing way with files like YOU-HAVE-TO-SEE-THIS.JPG.VBS. Unix does this in that most shells will load the file in question into the program specified with #!.
2) I execute MY-FAVORITE-MAC-GAME.
Assuming that the system I'm running on isn't a 68k, this would load an appropriate emulator for 68k. Note that the registered emulator here could very easily be another environment itself. For example, executing a 68k virtual machine which then loads Mac OS which then loads MY-FAVORITE-MAC-GAME.
3) I execute ls.
An ELF EE is loaded. ls then executes.
One might ask what would stop a user from using the EEL to load IRIX, MS-DOS, Rhapsody, FreeBSD, Linux, and a few hundred other operating systems and bringing the system to a crawl.
Specifically, I intend to implement two layers of scheduling quanta. If you start up a fork bomb, you'll bring your session to a halt, but no one else's performance will suffer for it.
I have two main concerns with this:
Lots of care needs to be taken with sharing resources as much as possible. Context switches need to happen quickly and there are potentially 3 layers to go through (e.g. My VM is selected to run, my scheduler selects my 69k emulator to run, Mac OS in my 68k emulator selects a process and runs it) and one of them isn't necessarily within our control (Mac OS in this case).
I've seen way too many trojans in Windows using a separate extension. In theory, the same ones could work in UNIX. There's a fine line between transparent execution and informing the user of what exactly they're doing in executing that file that will need to be walked. It will almost certainly need to be configurable to make everyone happy.
Hopefully that clarifies the distinction between this part of Ultimate and the way that Xen goes about things.