User: Password:
Subscribe / Log in / New account

Let's step back a bit

Let's step back a bit

Posted Jun 3, 2009 20:58 UTC (Wed) by nevets (subscriber, #11875)
In reply to: Let's step back a bit by skitching
Parent article: Xen again

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.

(Log in to post comments)

Let's step back a bit

Posted Jun 4, 2009 6:28 UTC (Thu) by drag (subscriber, #31333) [Link]

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

Ya.. it starts up like that. But it rarely stays like that.

In the case of Xen I think your looking at about 300-400K lines of code in a full-featured version.

In the case of KVM the initial patch was about 12K loc and was accepted almost immediately into the kernel code. (quite a achievement)

Let's step back a bit

Posted Jun 4, 2009 7:45 UTC (Thu) by sf_alpha (guest, #40328) [Link]

It isn't true that KVM does not have Dom0. But it reside in different layer, put the fact that both KVM and Xen -- Dom0 is privileged and handle device drivers + hardware, weather is in top or bottom of virtualization later.

For Xen, Xen Hypervisor is a controller too grant access Real hardware/cpus, but Dom0 is virtually both HW driver and admin system.

For KVM, It is application + kernel part too grant access Real hardware/cpus (using processor assisted), but system running KVM is both HW driver and admin system.

In both cases, if parent or dom0 cracked, whole system is compromised.

I agree that if Xen code is too much impact on x86 core arch code it should not merge until this fixes, but again KVM is not Xen replacement at all. Even with xenner which is really KVM but Xen guest.

I can say that Xen lacks support from its users. If Xen shipped in kernel it would heavily tested. But now it's not, even Xen currently keep track latest kernel inside git, most people seems to use stable and old Xen kernel and not many are working on new Xen Dom0 kernel.

And again, KVM is not thing that would replace Xen and not replace each other. I cannot see any benefits for replace Xen with KVM for now (I running a couple servers using Xen, some of those not support VT-d or AMD-V).

Topics of this problem is that Xen cause too much changes of the core x86 code and seems not to clean enough.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds