Xen is not user-space

Someone in the lkml discussion said that Xen wasn't an operating system, which was quickly refuted: the core job of an OS is to manage the sharing of resources, specifically memory and cpu time. Sharing memory and cpu time between multiple VMs specifically what Xen does, delegating the sharing of almost all other resources (disk, network, &c) to dom0 or driver domains. This makes Xen very akin to a micro-kernel. (Xen proponents have acknowledged this similarity, and said that Xen is "a microkernel done right".)

So when the article says "it seems unlikely that something as large as Xen would be the first user-space component to break through that barrier", something is confused. Xen isn't a user-space component. If Xen were to be merged in (or an in-kernel hypervisor project started), it would run in ring 0 and include memory and processor scheduling algorithms, just as Linux currently does, but targeted towards sharing between VMs, as opposed to processes.

The reason this is being discussed in the first place is that some people (myself included) don't believe that the same code can work well both as a kernel and as a hypervisor. This includes all aspects of the hypervisor, but specifically scheduler can work well both as a scheduler of processes and a scheduler of VMs. KVM currently runs VMs as processes, with Linux as the de-facto hypervisor. So a VM running under KVM gets a processor scheduler rather than a VM scheduler. Maybe the Linux scheduler could be made to do both, but the Xen community thinks it's better to have a dedicated VM scheduler, as well as other dedicated VM-oriented algorithms.

Having this code in the kernel would address two issues:
* The fear that Linux will be stuck with supporting a very invasive ABI. If the hypervisor is in the kernel tree, it would be a lot easier to tie them together.
* The feeling that dom0 changes add a ton of ugly "hooks", but don't make the Linux code base any better. Since the Xen hypervisor functionality is outside of Linux, having cool functionality in Xen doesn't really count as improving Linux. But if a hypervisor component were in the kernel, rather than a separate projec,t then the kernel as a whole would seem to benefit. (This is a bit of a subtle one to understand; it depends on drawing a boundary and saying, "If it's inside this tree, it contributes to making Linux cool, and may be worth the cost of the hooks. But if it's outside the tree, it doesn't contribute to making Linux cool, so the hooks are a cost without a benefit.")

Whether it's practical to do a merge with Xen specifically, is another quesiton. :-)