Porting the L4Ka::Pistachio Microkernel to the SPARC-V9 Architecture

Philip Derrin
Supervisor: Carl van Schaik

Overview

The aim of this project was to give the L4Ka::Pistachio microkernel the ability to run on computers based on the 64-bit SPARC v9 architecture. Pistachio was already capable of running on five other architectures, with experimental support for three more, and some initial work on the SPARC v9 port had been done by Adam Wiggins.

L4Ka::Pistachio
L4Ka::Pistachio is an implementation of the L4 microkernel, an high-performance minimal operating system kernel. It is designed to be flexible enough for a variety of systems to be built on top of it, but also to be reliable and secure. It is a joint project of the University of Karlsruhe and UNSW.

SPARC-V9
SPARC-V9 is the 64-bit version of the SPARC architecture, developed as an open standard by SPARC International. There are a number of microprocessors available which are based on this standard; the initial target of this project was the UltraSPARC II, used in computers built by Sun Microsystems.

Major Design Issues

Since Pistachio has already been ported to several other architectures, many of the difficulties usually encountered when porting software — such as assumptions about memory layout, the size of words, and endianness — have already been overcome. The SPARC-V9 port was therefore able to share most of its design with the existing ports. However, the architecture has one unusual feature which took some effort to support properly: register windows.

Register Windows
The SPARC has 32 integer registers; 24 of them form a window into a large, circular register file. Applications are able to slide this window forward or backwards by 16 registers using “save” and “restore” instructions. The operating system is responsible for copying registers to and from the application’s stack, to make the circular register file appear infinitely large to the application. An example is shown in figure 1.

Register windows cause problems in Pistachio because of L4’s method of handling user-level page faults. In most systems, a page fault can be handled immediately without any need to interfere with the register windows; however, in L4, faults make the kernel send a message to a user-level pager thread. This can lead to a situation where the kernel can’t make a window available without handling a page fault, and can’t handle the page fault until a window is available.

This problem took a few weeks to completely solve.

Figure 1 A register file with eight windows. In this example, three windows (W6-W0) are used by the current process, two (W3 and W4) by another process, and two (W1 and W2) are free. W5 cannot be used because it overlaps two other valid windows.

First, an area had to be reserved in kernel memory for every running thread, to provide enough space to save all of a thread’s register windows temporarily while switching threads. Second, the saving of registers in an alternate location had to be made invisible to user processes, without wasting time saving and restoring windows unnecessarily. Finally, use of window save and restore instructions in compiled kernel code had to be disabled — this should have been trivial, but the relevant feature in the C compiler did not work and had to be fixed.

Testing

There is presently no freely-available SPARC-V9 simulator which is complete enough to boot Pistachio. It was therefore necessary to perform all testing on a real UltraSPARC computer (a Sun Ultra 10).

Debugging a kernel on real hardware is quite difficult, because the methods used for debugging often interfere with the behaviour of the bugs. In hindsight, spending a few days at the start of the project making an existing SPARC-V9 simulator (such as Sulima) capable of booting Pistachio may have saved a week or more of debugging later on.

Current State

At the time of writing, the kernel is not ready for a public release. Interrupt handling, exception IPCs and the fast IPC path have not yet been implemented. However, the majority of the work is done; the kernel is capable of running user-level code, and the two initial tasks can print messages to the console and interact with each other via IPC.

[Top of Page]