To facilitate the bookkeeping needed for the
different types of program discontinuities that I
mentioned, exokernel maintains the PE data structure
on behalf of each library operating systems.
So for example, this PE data structure
corresponds to this library operating system. This
B data structure corresponds to this library
operating system. And the PE data structure contains
the entry points in the library operating system for dealing with the different
kinds of program discontinuities. For example,
exceptions that are thrown by the currently
executing process has a specific entry
point in the library operating system. And
similarly, external interrupts are going to be
handled by interrupt handlers that have specific
entry points in the library operating system.
And a process may make system calls and
if it makes system calls, there is a
protected entry context, which is the entry point
in a library operating system for system
calls that are made by the currently running
process that belongs to that specific library operating
system. This last entry may correspond to the
addressing context that is the location of
the handler for page fault service the,
in the library operating system. So in
a nutshell, this PE data structure that is
unique for every library operating system, contains
the handler entry points for different types
of events that are fielded by exokernel.
In this sense, the PE and the associated
exokernel action of calling the appropriated handler
entry point, when a particular event is
triggered, is very similar to the event
handler mechanism that we discussed in the spin
operating system. In addition to the PE
data structure, we already mentioned the software
TLB, that exokernel maintains on behalf of
every operating system. So this is in software
TLB for OS1, software TLB for OS2 and
these are what are called a guaranteed mappings. In other words, I mentioned
that on a context switch exokernel when it goes from one operating system to
another, it saves the current TLB in the hardware,
the hardware TLB in the software TLB that is associated with
this particular operating system. And here is
where this entry point is important. This
actually is specifying to exokernel the set
of guaranteed mappings that a particular library
operating system wants exokernel to maintain on
its behalf, every time it is scheduled.
And that's the set of TLB entries that are dumped into the software TLB
data structure at the point of a context
switch. Not all of the hardware TLB entries, but
only the entries that have been guaranteed to
be kept on behalf of a particular operating system
are dumped into a software TLB data structure.
And those are the ones that will be repopulated
into the hardware TLB when the same operating
system is scheduled on the hardware. I mentioned an
external interrupt is another source of discontinuity
for the currently executing process. Well, note that
an external interrupt may not always be
for the currently scheduled operating system. It may
be for some other operating system, maybe
this operating system scheduled a disk IO. And
the disk IO got complete. And that interrupt
that came into exokernel is on behalf of
this operating system and not the process that is currently executing on the CPU
for this operating system. Exokernel has to
have a way of associating the interrupt
that is coming in with a correct
operating system which is expecting it. Downloading
code into the kernel, which I mentioned
as one of the mechanism that exokernel provides,
allows first level interrupt handling on behalf of a library operating system.