OSDev.org

After the great exokernel flame-fest I thought of this question:

If the purpose of an exokernel is to securely multiplex the hardware, then what's the "moral" difference between an exokernel and a hypervisor for a system that supports full hardware virtualization? I realize that the literal difference is that one requires special hardware and the other doesn't... But other than this, is there a practical difference?

In other words, if you assume that hardware features like Vanderpool become ubiquitous, then why should we be interested in exokernels with various libOSes when we can just have a hypervisor running several "traditional" OSes (not Linux or Windows necessarily, but not libOSes either... in other words, OSes that believe they have full access to the hardware)?

Hi!

In fact, I always believed that hardware supported virtualization (like Vanderpool and Pacifica) resembles the way an advanced exokernel works: It just multiplexes the hardware, but provides _no_ abstraction at all (this is what you always read about exokernels), so that's exactly what a hypervisor does.

From the other point of view, couldn't an exokernel also be seen as a hypervisor that implements virtualization in software, rather than hardware (putting all software in ring 3, intercepting privileged instructions with GPF and emulate them)?

But maybe I never understood what an exokernel really does.... ::) (never used one, just read about them)

cheers joe

Hello,
I finally had a look at the Vanderpool paper and think the idea is quite interesting, although not really new. In fact todays x86 already support hardware virtualization techniques (paging, segmentation, I/O map, IDT) that are sufficient to multiplex the system ressources as it has already been done in ?kernels for years. In my opinion Vanderpool is therefore nothing else than an attempt to reorganize these already existing techniques in a new stadard, just like ACPI for power-management.

I don't agree at all that this makes exokernels redundant !
As long as you only run guestOS of one kind on your problem the adaptions that have to done to the kernel are really not that big (drivers would run on the hostOS and and the guestOS traps to them), but I personally don't think that there's a real advantage in having the same system twice..
If you however want to run two different monolithic operating systems on a Vanderpool system, big problems will arise because only the CPU, but not the I/O devices are currently virtualized. This problem can only be solved by changing the two systems to use the same driver architecture and then running such drivers on the hostOS whose job I'd be to multiplex just like in an exokernel. If you go on like that for all devices you'd end up with something that yould be seen as an ugly exokernel (the common drivers) with several big "user-level" server that decides about the policy to be used (the guestOSes).

regards,
gaf

As I understand it, a hypervisor would be transparent, whereas a exokernel is not. Applications on an exokernel are fully aware that they are sharing resources, and must ask the exokernel to do things for them. The exokernel does not make it appear as though the application has full control over the hardware, in fact, it deliberately makes a point of the fact that it's not.

A reason I can conceive of to be interested in exokernels even if those hardware features are available ubiquitously is that it could be useful for the applications to be aware of each others' existence and the fact that they are sharing resources. For one, they may be able to cooperate better and obtain better performance. Also, the applications would also be able to pass data among each other.