When we discussed spin, I mentioned that
memory management and CPU management are core
services that any operating system has to
provide; and we discussed how spin had its
own way of dealing with those core services. We will do the same analysis
for exokernel as to how it does
memory management and CPU scheduling, first memory management.
Specifically let's see how exokernel will handle a page fault incurred by
a library operating system. So in this picture that I'm showing you, here is an
application thread running, and maybe this
application thread, belongs to a specific library
operating system and so long as this
application thread is doing normal memory accesses,
where all its virtual addresses have been
mapped to physical page frames. The thread is
executing at hardware speeds on the CPU. Life is good. But life may not be
always good. Because this thread my incur a page fault. And when it incurs a
page fault, the page fault is first fielded
by Exokernel. Exokernel knows which library operating system
is currently executing on the CPU, it has no knowledge
of processes within a library operating system. All it knows
is that this library operating system is doing something on
the CPU... And it knows that there is a page
fault incurred, and it can kick it up to the
library operating system through a registered handler and we will
talk about how these handlers are known to Exokernel later
on. Right now, I just want to give you road map
of how a page fault is handled in Exokernel. Because the library operating
system knows about processes, whereas Exokernel has
no knowledge about that, and it services
the page fault. And servicing the page fault may involve requesting Exokernel
for a page frame to host the specific page that is missing. And if it does
that as we detailed before, that will involve
the library asking Exokernel for a page frame and
Exokernel creating a binding for a page frame.
And returning an encrypted key for the page frame.
Assume for the moment that the library operating
system has page frames already with it and all
that it is doing at this point is
in servicing the page fault, it establishes a mapping
between the virtual piece that was missing and the page frame that contains
the contents of the virtual page. Once it does that, that mapping between
the virtual page and the frame that it corresponds to has to be presented
to the Exokernel. So the library presents that mapping to the Exokernel
along with the TLB entry, where it wants
this mapping to be placed in the hardware
TLB. Remember that, when the process runs the
CPU is consulting the hardware TLB, to see if
there's a valid mapping between the virtual page
number and a physical frame, so that the CPU
can go and access that page. And we
got the page fault because the mapping did not
exist, and the whole point of this
exercise is for the library operating system to
reestablish a mapping. But it cannot do
that directly into the TLB, so it presents
a mapping to Exokernel along with the
encrypted key that represents the capability that the
library operating system has to a specific TLB
entry where it wants this to be placed.
Exokernel will validate the encrypted key presented by
the library operating system, and assuming all is good,
it will go ahead and install the mapping in the hardware TLB, and this is a, a
privileged operation, meaning that it can be done
only in the kernel mode of the processor. That's
the reason that you have the red line between
the library operating system that runs at the non-privileged
level, and Exokernel that runs at the privileged level
to do certain operations such as, installing an entry
into the TLB. And once the entry had be
installed in the TLB, if the library operating system
is once again scheduled on the processor and if
the same process is run by the library operating
system when it generates the same virtual address we're
going to find a valid mapping and life will be good.