The Design and Implementation of the Anykernel and Rump Kernels

92
Hardware interrupt handlers are typically structured to only do a minimal amount
of work for acknowledging the hardware. They then schedule the bulk work to be
done in a soft interrupt (softint) handler at a time when the OS deems suitable.
As mentioned in Section 2.3.3, we implement hardware interrupts as host threads
which schedule a rump kernel CPU like other consumers, run the handler, and release
the CPU. The only difference to a regular system is that interrupts are scheduled
instead of preempting the CPU.
Softints in NetBSD are almost like regular threads. However, they have a number
of special properties to keep scheduling and running them cheap:
1. Softints are run by level (e.g. networking and clock). Only one softint per
level per CPU may be running, i.e. softints will run to finish before the next
one may be started. Multiple outstanding softints will be queued until the
currently running one has finished.
2. Softints may block briefly to acquire a short-term lock, but should not sleep.
This property is a corollary from the previous property.
3. Softint handlers must run on the same CPU they were scheduled on. This
property relaxes cross-CPU cache effects and locking requirements.
4. A softint may run only after the hardware interrupt has completed execution.
That is to say, the softint handler may not run immediately after it is
scheduled, only when the hardware interrupt handler that scheduled it has
completed execution.
Although in a rump kernel even “hardware” interrupts are essentially software interrupts
due to them being scheduled, a fair amount of code in NetBSD assumes
that softints are supported. For example, the callout framework [19] schedules soft