The Design and Implementation of the Anykernel and Rump Kernels

81
The Benefit of a printf-like Hypercall
The rumpuser_dprintf() call has the same calling convention as the NetBSD kernel
printf() routine. It is used to write debug output onto the console, or elsewhere
if the implementation so chooses. While the kernel printf() routine can be used
to produce debug output via rumpuser_putchar(), the kernel printf routine inkernel
locks to synchronize with other in-kernel consumers of the same interface.
These locking operations may cause the rump kernel virtual CPU context to be
relinquished, which in turn may cause inaccuracies in debug prints especially when
hunting racy bugs. Since the hypercall runs outside of the kernel, and will not unschedule
the current rump kernel virtual CPU, we found that debugging information
produced by it is much more accurate. Additionally, a hypercall can be executed
without a rump kernel context. This property was invaluable when working on the
low levels of the rump kernel itself, such as thread management and CPU scheduling.
3.3 Rump Kernel Entry and Exit
As we discussed in Chapter 2, a client must possess an execution context before it
can successfully operate in a rump kernel. These resources consist of a rump kernel
process/thread context and a virtual CPU context. The act of ensuring that these
resources have been created and selected is presented as pseudocode in Figure 3.4
and available as real code in sys/rump/librump/rumpkern/scheduler.c. We will
discuss obtaining the thread context first.
Recall from Section 2.3 that there are two types of thread contexts: an implicit one
which is dynamically created when a rump kernel is entered and a bound one which
the client thread has statically set. We assume that all clients which are critical
about their performance use bound threads.