[1] |
There are of course other alternatives, the most obvious one being having one process for the virtual kernel and another for contained processes, which is mostly equivalent to the choice made in DragonFly. |
[2] |
A process running under a virtual kernel will also be referred to as a "vproc" to distinguish it from host kernel processes. |
[3] |
The small matter of the actual data belonging to the vproc is not an issue, but you will have to wait until we get to the RAM file in the next subsection to see why. |
[4] |
Well not really, but a thorough VM walkthrough is out of scope here. |
[5] |
This is not optimal; x86 hardware supports fully lazy FPU save, but the current implementation does not take advantage of that yet. |
[6] |
The kernel will occasionally make use of the FPU itself, but this does not directly affect the vkernel related code paths. |
[7] |
Or any alternative stack the user has designated for signal delivery. |