QEMU
Features
- two operating modes: full system emulation (which interests us) and Linux user process emulation ( which interests other people ;) and is a NxM platform emulator (multiple host, multiple targets).
- it is faster than Bochs because it uses 'just in time' code compilation technique (allowing reuse of previous interpretation)
- lacks technical documentation so far (imho), which probably makes it less suitable for "baby steps".
- provides native GDB support and you can attach it to GDB/DDD by adding the "-s -S" switches to the command line and from the GDB window start the debugging session with "target remote :1234" if QEMU is waiting on local port 1234.
- support VBE 2.0. This can be checked if you use the GRUB floppy image ready for use and tyiping the command vbeprobe. The test returns:
Supported VBE modes
0x101 | Packed pixel | 640x480x8 |
0x110 | Direct Color | 640x480x15 |
0x111 | Direct Color | 640x480x16 |
0x112 | Direct Color | 640x480x24 |
0x103 | Packed pixel | 800x600x8 |
0x113 | Direct Color | 800x600x15 |
0x114 | Direct Color | 800x600x16 |
0x115 | Direct Color | 800x600x24 |
0x105 | Packed pixel | 1024x768x8 |
0x116 | Direct Color | 1024x768x15 |
0x117 | Direct Color | 1024x768x16 |
0x118 | Direct Color | 1024x768x24 |
0x107 | Packed pixel | 1024x768x8 |
0x119 | Direct Color | 1024x768x15 |
0x11A | Direct Color | 1024x768x16 |
Supported Architectures
SPARC64, PowerPC64, m68k and SH-4 are in development.
Supported Devices
- built in NE2000 support
- PCI SVGA card (Cirrus Logic 5446)
- PCI support (With BIOS32).
Usage
QEMU is easy to use, it does not have a configuration script like Bochs. To use QEMU with your OS,
qemu -L .\ -fda my_disk_image.img -m 32
Or, if you use UNIX,
qemu -fda my_disk_image.img -m 32
The -L tells QEMU where to find its BIOS images, which is not necessary in a standard unix installation. The -m tells how many megabytes of memory to use; the default is 128
You can use -fda/-fdb for disk image files, and -hda/-hdb/-hdc/-hdd for hard disks. To change boot devices, use -boot {a/b/c/d}. a/b tell it to boot floppy a or b. c for hard disk and d for CDROM.
Alternativly you can point -hdc or use -cdrom to an ISO image file (2048 bytes per sector ISO format).
Whilst inside the emulator you can use CTRL-ALT-{1,2,3} to swap in/out of the emulation screen, the QEMU console and a serial console. The system console lets you change disk images and other things and do memory dumps etc.
The QEMU monitor
When you hit CTRL-ALT-2 you are placed in the QEMU monitor which is a command-line for querying information about the system while it is running. It does not quite act as a debugger, but, used in combination with GDB-stub, you can get pretty much all the functionality you will need.
Some useful commands:
- xp
- eXamine Physical memory. Much like GDB's x command, but with no address translation.
- cpu n
- switch to CPU n. Note that GDB's threads are numbered from 1, but QEMU's CPUs are numbered from 0.
- info registers
- dump register state
- info tlb
- Show virtual memory translation state.
- info mem
- Show the page table mappings in a compact form.
- help
- List all commands -- keep in mind that there may be more commands available than those mentioned in the QEMU documentation.
GDB-stub
When you supply the -s command line option, QEMU will listen on port localhost:1234 for a connection by GDB. If you also supply the -S command line option, then QEMU will start as if you set a breakpoint at time zero, and you will need to use the GDB command "continue" to actually begin the simulation.
For convenience, I put a file called .gdbinit in the current working directory which automatically runs certain commands when you start GDB without the -n option. For example:
file <my-kernel-binary> target remote localhost:1234
will load into GDB your kernel and then connect to QEMU. Be sure to compile your kernel with the GCC option -g for debugging symbols. Now you may debug your kernel as a C program. If you have an SMP kernel, check out the info threads and thread commands. Note: as far as I know you cannot examine control registers or physical memory through GDB. So the QEMU monitor is the only way to go for that information.