Virtual Machines an evolution of Virtual Memory?

[Avarok]

A virtual machine is NOT an exokernel. An exokernel abstracts the hardware while a virtual machine emulates it. The key difference is that the one hides the implementation details while the other exposes it.

Actually, we're both wrong.

http://en.wikipedia.org/wiki/Exokernel

It clearly states that an Exokernel is NOT a Virtual Machine. It also clearly states that an Exokernel attempts not to abstract the hardware as much as possible. It attempts to expose implementation, which is then handled by (3rd party?) libraries.

In my opinion though, with Pacifica and Intel-VT, a virtual machine is now a perfect way to achieve the design objectives of an exokernel (leave abstraction to <3rd party?> libraries, and just secure it). Hence all the talk about exokernels. : p

I think if a real VM/exokernel like that came out with a proof of security, and minimal overhead that I would consider that to be the core of any future OS development. Then we could focus on drivers for core hardware for a while.

[FWMiller]

Well, I did not say that a virtual machine is an exokernel, I said the VMM (Virtual Machine Monitor) is equivalent to an exokernel. That I continue to hold to.

But again, the subject of this thread is supposed to be the exporting of a higher level API, i.e. a UNIX kernel type API through the VMM interface.

Thanks,
FM

[Combuster]

Actually, we're both wrong.

http://en.wikipedia.org/wiki/Exokernel

Wikipedia is unfortunately not an authority on things.

If there were no abstraction layer, we would be accessing the devices directly which is the worst possible security breach. Hence exokernels abstract the hardware with something equal.

Exokernels need not be small. In fact the MIT exokernel holds all the drivers inside the kernel, making it 'larger' than a microkernel. In other words, an exokernel is orthogonal to all the other kernel designs in that any from the list of micro/monolith/modular kernels can also be an exokernel. The way device drivers are handled does not have implications on the design of the interface, which can be exokernel or something at a higher-level. In this cases it looks like wikipedia is contradicting its own sources. But then again, you could argue that everything is relative.

In my opinion though, with Pacifica and Intel-VT, a virtual machine is now a perfect way to achieve the design objectives of an exokernel (leave abstraction to <3rd party?> libraries, and just secure it).

It seems that I'm going to need to repeat myself: A virtual machine allows the kernel designer to ignore all issues about abstracting the processor, as it is done for him by the VM technology. When you want your life made easy, go ahead. However, a VM means overhead. An exokernel designer might therefore very well abstract a system where are kernel and other processes already exists. This means less options for the process but a significant speed improvement. But who cares that you can not execute privileged instructions - even on an exokernel, programs will probably use a 32-bit (or 64-bit if applicable) paged address space and nothing more. Things that are now routed through the kernel instead of the VM are things like v8086 mode and GDT/LDT/IDT business. The page tables will always be done by the kernel even though the VM hides them. The system tables are usually the same and require no modification and real mode can be substituted with v8086 mode if really necessary (which obviously isnt for most purposes). That means that using the VM has little to gain and a lot to lose.

I said the VMM (Virtual Machine Monitor) is equivalent to an exokernel. That I continue to hold to.

I will then hold on to the fact that its an independent concept. Shame that you have to end the discussion in such a fashion.

But again, the subject of this thread is supposed to be the exporting of a higher level API, i.e. a UNIX kernel type API through the VMM interface.

An exokernel employing a VM would do just that