As a simple example, take scheduling. I'm about to re-write the Xen
scheduler, and in the process I took a good look at the scheduler you
wrote. I think it's got a lot of really good ideas, which I plan to
steal. :-) However, I'm going to have to make some key changes in
order for it to function well as a hypervisor scheduler. If KVM is
used on a production server with 20 or 30 multi-vcpu VMs, I predict
the current scheduler will do very poorly, because it wasn't designed
with VMs in mind, but with processes. Making changes so that VMs run
better will fundamentally make things that make processes run less
The whole Xen design is messed up really: you have taken off bits of
the Linux kernel you found interesting, turned them into a
micro-kernel in essence and renamed it to 'Xen'.
That's how Xen started, and that's really the beauty of open-source.
(After all, KVM has stolen some ideas from the Xen shadow code.) But
since then, basically all of the code has been replaced with
Xen-written code. I think if you did an SCO-style audit comparing
Linux and Xen 3.4, you'd find a lot less in common than you think.
Xen isnt actually useful _at all_ without Linux/DOM0. Without Dom0
Xen is slow and native hardware support within Xen is virtually
non-existent, as you point out above.
And qemu-kvm isn't useful _at_all_ without Linux either; and Linux-KVM
isn't useful _at_all_ without qemu. Your point?