Let's step back a bit

Let's step back a bit

1) critical hypervisor code is small, so more easily ported and audited

I've heard this argument before, but it has one flaw. It still depends on Dom0. You still need to port Dom0 and audit it too. If you crack Dom0, you cracked the box

2) possible to use same hypervisor with different dom0 impls, eg windows/bsd/solaris as dom0.

I'm not sure this is that big of a deal. As Ted mentioned in an email, Linux supports more devices than anything else, and makes it the ideal Dom0.

3) this is the traditional approach, hence more research/experience

Or perhaps its the approach that does not think outside the box.

4) reduces changes needed to an OS to make it a dom0, as some of the virtualization-specific logic is in a separate layer. In particular, one article implied that KVM would have to rework the standard linux scheduler implementation to get good scheduling for guests. I guess this means that xen does at least some scheduling decisions in the hypervisor.

You are right that this is not quite true in practice, as we see.

(a) XenSource would presumably have to maintain two similar-but-not-identical hypervisor implementations,

Keeps them employed.

Actually, if they make the Linux version their main code base, they could add a kluge layer to interact with other Dom0s.

(b) If someone upgrades their linux kernel, they also need to upgrade the hypervisor to match.

As I stated before. That would happen automatically. You would just install the vmlinuz, and it would load both the new Xen hypervisor along with the new Linux kernel.

(c) If someone switchs to a different dom0 (eg windows) they need to change hypervisor to match.

Or add the kluge layer.

Presumably (b) and (c) sink any idea of putting the hypervisor into ROM.

This point hits the main argument that we have against adding the Dom0 interface. Once it is there, it is set in stone, and we can not change it. Otherwise we will get all those people that loaded their box's ROM with a hypervisor crying to us that they can't run the latest kernel.

The current Dom0 ABI is intrusive and limits the development of Linux. This is the reason it is being rejected. Not to mention that it also comes with a certain degree of performance overhead when not in use.

If the Dom0 ABI were to come in without the Xen hypervisor, then it must be clean, and not scattered through out the kernel.

And just the idea of modifying the hypervisor in sync with linux changes means that the "auditability" benefit of a hypervisor is mostly lost: it's expensive to "recertify" a hypervisor impl that changes every 6 months.

Again, if you do not audit the Dom0 you are wasting your time. If you need to audit the hypervisor, pick a image, and audit it. You better audit the Dom0 in use too. Then after that is done, don't upgrade.