H. Using Bochs as a simulator

H.1 Building Bochs for Pintos

Please note that it will NOT suffice to install Bochs from the repository, since in most cases it will neither have any debugging support built in, nor the "jitter" feature provided as a custom patch.

Two different Bochs binaries should be installed. One, named simply bochs, should have the GDB stub enabled, by passing --enable-gdb-stub to the Bochs configure script. The other, named bochs-dbg, should have the internal debugger enabled, by passing --enable-debugger to configure. (The pintos script selects a binary based on the options passed to it.) In each case, the X, terminal, SDL and "no GUI" interfaces should be configured, by passing --with-x --with-x11 --with-term --with-sdl --with-nogui to configure.

This version of Pintos is designed for use with Bochs 2.6.2. A number of patches for this version of Bochs are included in the Pintos tarball in src/misc. To apply all the patches, build Bochs, and install it, cd $PDIR/src/misc, where $PDIR is the directory with the decompressed Pintos tarball, then type:

env SRCDIR=[srcdir] PINTOSDIR=[srcdir] DSTDIR=[dstdir] sh bochs-2.6.2-build.sh

H.2 Running Pintos with Bochs

$ pintos --bochs -- run alarm-multiple

This command creates a bochsrc.txt file, which is needed for running Bochs, and then invoke Bochs. Bochs opens a new window that represents the simulated machine's display, and a BIOS message briefly flashes. Then Pintos boots and runs the alarm-multiple test program, which outputs a few screenfuls of text. When it's done, you can close Bochs by clicking on the "Power" button in the window's top right corner, or rerun the whole process by clicking on the "Reset" button just to its left. The other buttons are not very useful for our purposes.

If you want to make Bochs your default simulator, you can do so by making the following change in $PINTOS_HOME/src/utils/pintos script:

Line 103: replace qemu in $sim = "qemu" if !defined $sim; with bochs

H.3 Debugging with Bochs

When you're debugging code, it's useful to be able to run a program twice and have it do exactly the same thing. On second and later runs, you can make new observations without having to discard or verify your old observations. This property is called "reproducibility." One of the simulators that Pintos supports, Bochs, can be set up for reproducibility, and that's the way that pintos invokes it by default.

Of course, a simulation can only be reproducible from one run to the next if its input is the same each time. For simulating an entire computer, as we do, this means that every part of the computer must be the same. For example, you must use the same command-line argument, the same disks, the same version of Bochs, and you must not hit any keys on the keyboard (because you could not be sure to hit them at exactly the same point each time) during the runs.

While reproducibility is useful for debugging, it is a problem for testing thread synchronization, an important part of most of the projects. In particular, when Bochs is set up for reproducibility, timer interrupts will come at perfectly reproducible points, and therefore so will thread switches. That means that running the same test several times doesn't give you any greater confidence in your code's correctness than does running it only once.

So, to make your code easier to test, we've added a feature, called "jitter," to Bochs, that makes timer interrupts come at random intervals, but in a perfectly predictable way. In particular, if you invoke pintos with the option -j seed, timer interrupts will come at irregularly spaced intervals. Within a single seed value, execution will still be reproducible, but timer behavior will change as seed is varied. Thus, for the highest degree of confidence you should test your code with many seed values.

On the other hand, when Bochs runs in reproducible mode, timings are not realistic, meaning that a "one-second" delay may be much shorter or even much longer than one second. You can invoke pintos with a different option, -r, to set up Bochs for realistic timings, in which a one-second delay should take approximately one second of real time. Simulation in real-time mode is not reproducible, and options -j and -r are mutually exclusive.

The QEMU simulator is much faster than Bochs, but it only supports real-time simulation and does not have a reproducible mode.