Re: [ANNOUNCE] NOVA Userland 0.1

On Thu, 24 Dec 2009 18:00:58 +0100 Tom Bachmann (TB) wrote:

TB> What exactly makes a "microhypervisor" different from an ordinary
TB> microkernel? I see how the term hypervisor makes sense for something
TB> like xen that cannot really be used sensibly by "stand-alone"
TB> applications, but looking at your spec it looks just like a (quite nice)
TB> microkernel.

According to Wikipedia, a hypervisor "is a piece of software/hardware
platform-virtualization software that allows multiple operating systems to
run on a host computer concurrently." The NOVA microhypervisor can be
classified as a type-1 aka "bare-metal" hypervisor.

Since we did not want to build another monolithic hypervisor, we chose to
employ microkernel construction principles. The result is what you could
call a microkernel with virtualization features or a hypervisor with
microkernel interface, or as we call it, a microhypervisor (to denote both
its size and its two origins).

TB> How is capability revocation implemented? Are there any bounds on the
TB> execution time? If not, how are arbitrarily long kernel paths scheduled?
TB> (obviously an atomic interrupt-style kernel is not viable then ...)

Capabilities are revoked recursively and this a potentially long running
operation, if capabilities have been delegated multiple times. There is no
reason why such an operation cannot be preempted, even on an interrupt-style
kernel. If you want bounded execution time, you would need to restrict how
often capabilities can be delegated and you need to ensure that an ongoing
revoke operation cannot be outperformed by concurrent operations that
establish new delegations for those capabilities. Those concurrent
operations can either be higher-priority threads that preempt the
revoker on its CPU or threads on different CPUs.

We currently do not restrict how often you can delegate a capability but
something like that is trivial to add if people find it useful.

TB> Is there any support for asynchronous IPC?

If your definition of "asynchronous" is that you want a message to be
delivered without someone already waiting for it on the other side, then
you can achieve this with shared memory and semaphores (even across
different CPUs). The user environment uses this kind of producer/consumer
scheme for reliable communication between untrusted parties, so you could
look at that code for examples.

Cheers,

	- Udo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAks0JxkACgkQnhRzXSM7nSkF7QCfXqxnRxfdFQKINc6VrRxiRBgr
lmMAn31aW3+rDNsITx3KUi3skl0IcZlP
=Uka9
-----END PGP SIGNATURE-----