The Design and Implementation of the Anykernel and Rump Kernels

82
The entry point rump_schedule() 6 starts by checking if the host thread has a
bound rump kernel thread context. This check maps to consulting the host’s thread
local storage with a hypercall. If a value is set, it is used and the entrypoint can
move to scheduling a CPU.
In case an implicit thread is required, it is necessary to create one. We use the
system thread lwp0 as the bootstrap context for creating the implicit thread. Since
there is only one instance of this resource, it may be used only by a single consumer
at a time, and must be locked before use. After a lock on lwp0 has been obtained,
a CPU is scheduled for it. Next, the implicit thread is created and it is given the
same CPU we obtained for lwp0. Finally, lwp0 is unlocked and servicing the rump
kernel request can begin.
The exit point is the converse: in case we were using a bound thread, just releasing
the CPU is enough. In case an implicit thread was used it must be released. Again,
we need a thread context to do the work and again we use lwp0. A critical detail is
noting the resource acquiry order: the CPU must be unscheduled before lwp0 can be
locked. Next, a CPU must be scheduled for lwp0 via the normal path. Attempting
to obtain lwp0 while holding on to the CPU may lead to a deadlock.
Instead of allocating and free’ing an implicit context at every entry and exit point,
respectively, a possibility is to cache them. Since we assume that all performanceconscious
clients use bound threads, caching would add unwarranted complexity to
the code.
6 rump_schedule() / rump_unschedule() are slight misnomers and for example rump_enter()
/ rump_exit() would be more descriptive. The interfaces are exposed to clients, so changing the
names is not worth the effort anymore.