QEMU: Difference between revisions
[unchecked revision] | [unchecked revision] |
Line 136: | Line 136: | ||
===The QEMU Console=== |
===The QEMU Console=== |
||
QEMU's internal console can be accessed by the key combination CTRL-ALT-3 within QEMU. |
|||
QEMU features its own internal 'monitor' console for debugging the guest operating-system. Through various commands, the monitor allows you to inspect the running guest OS, change removable media and USB devices, take screenshots and audio grabs, and control various aspects of the virtual machine. |
|||
If you are running QEMU from the command-line, it is possible to redirect QEMU's monitor output to stdio using the following command line option when invoking QEMU: |
|||
<source lang="bash"> |
|||
-monitor stdio |
|||
</source> |
|||
Unlike [[Bochs]], QEMU does not provide an [[Port IO|IO port]] for communicating directly with its internal console. Output to the internal console can be accomplished by the redirection of serial output. Using the following command-line option will redirect COM1's output to the QEMU console: |
Unlike [[Bochs]], QEMU does not provide an [[Port IO|IO port]] for communicating directly with its internal console. Output to the internal console can be accomplished by the redirection of serial output. Using the following command-line option will redirect COM1's output to the QEMU console: |
||
Line 147: | Line 142: | ||
-serial file:CON |
-serial file:CON |
||
</source> |
</source> |
||
A list of the capabilities of QEMU's monitor is available in the [https://qemu.weilnetz.de/doc/qemu-doc.html#pcsys_005fmonitor official documentation] as well as [https://en.wikibooks.org/wiki/QEMU/Monitor here]. |
|||
===The QEMU monitor=== |
===The QEMU monitor=== |
Revision as of 08:27, 14 October 2019
Emulators |
---|
PC Emulators |
PC Virtual Machine Monitors |
PowerPC Emulators |
QEMU is a free and open-source emulator that performs hardware virtualization. It is widely available for variety of host operating-systems and requires minimal configuration for use in operating-system development. It is capable of emulating a wide variety of systems including ARM, x86 and RISC-V, among others. For a more comprehensive list of targets refer to the official documentation.
Features
- Two operating modes: full system emulation (which interests osdevers) and Linux user process emulation (which interests people who want to emulate applications) 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)
- 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. - Supports VBE 2.0. This can be checked if you use the GRUB command line and type 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
- x86
- x86_64
- ARM
- ARM64
- LatticeMico32
- Motorola 68000
- MicroBlaze
- MIPS
- MIPS64
- Moxie
- PowerPC
- PowerPC64
- RISC-V
- IBM System/390
- SuperH
- SPARC
- SPARC64
- TriCore
- Unicore
- Xtensa
Supported Devices
- Ne2000 network card
- e1000 network cards
- RTL8139 network card
- AMD PCnet network cards
- PC Speaker
- Sound Blaster 16 sound cards
- AC97
- Intel High Definition Audio
- Virtio devices
- 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.
Alternatively 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.
In order to track down a triple fault, you can use the -d int option to show what interrupts happen. Work can be done even more easily when passing the -no-shutdown -no-reboot options, since that causes the virtual machine not to reboot, but instead halt. Then, in conjunction with the QEMU monitor (see below), you can debug the machine state more thoroughly.
The QEMU Console
QEMU's internal console can be accessed by the key combination CTRL-ALT-3 within QEMU.
Unlike Bochs, QEMU does not provide an IO port for communicating directly with its internal console. Output to the internal console can be accomplished by the redirection of serial output. Using the following command-line option will redirect COM1's output to the QEMU console:
-serial file:CON
The QEMU monitor
QEMU features its own internal 'monitor' console for debugging the guest operating-system. Through various commands, the monitor allows you to inspect the running guest OS, change removable media and USB devices, take screenshots and audio grabs, and control various aspects of the virtual machine. The monitor can be accessed by the key combination CTRL-ALT-2 within QEMU.
If you are running QEMU from the command-line, it is possible to redirect QEMU's monitor output to stdio using the following command line option when invoking QEMU:
-monitor stdio
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.
A full list of the capabilities of QEMU's monitor is available in the official documentation as well as here.
Useful QEMU command-line options
Shown below are a list of command-line options for QEMU which are of special significance to Operating-System development. For a full list of options refer to the official QEMU documentation.
Option | Description |
---|---|
-no-reboot | Prevents QEMU from rebooting in the event of a Triple Fault. |
-no-shutdown | Don’t exit QEMU on guest shutdown, but instead only stop the emulation. |
-d | Enables the printing of extra debugging information. Arguments for this option include cpu_reset, int, guest_errors ( among others ). This can be extremely useful when setting up an IDT to see interrupt execution in real-time. |
-gdb or -s | Launches QEMU in GDB Stub mode. This causes QEMU to accept incoming connections from a GDB client. See below for more information or refer to official documentation. |
-S | Causes the guest CPU not to start execution on startup. This is very useful for debugging as it launches the guest in a paused state. The user must use the continue command in the console ( or GDB ) to initiate execution on the guest system. |
GDB-Stub
Starting QEMU with the -gdb or -s <dev> command-line options will instruct QEMU to listen for an incoming GDB connection. By default QEMU will listen for a connection over HTTP on localhost:1234, but the option will accept an argument for a different connection. It is useful to use this switch together with the -S option, which will cause QEMU to start in a paused state. This will allow additional time to connect a GDB client, to start the simulation a continue command will need to be issued within GDB or in the QEMU console.
For convenience, it is also possible to create a file containing commands for GDB to automatically execute. GDB will read and execute the contents of a file with the name .gdbinit in the current working directory. Alternatively, a different file may be specified by the use the -command=file command-line argument. An example file can be seen below:
file <my-kernel-binary>
target remote localhost:1234
# Inspect page tables
x /8wg &page_tables_start
This will automatically load the kernel binary's symbol file into the debugger and then open the remote connection to QEMU.
Ensure that the kernel was compiled with debugging symbols included. This can be accomplished via the use of the GCC option -g. If you find that the debugger can't find local variables, try using the -fno-omit-frame-pointer option during compilation, or disable optimizations.
If you have an SMP kernel, check out the info threads and thread commands. It is also possible to use the QEMU monitor and its commands using the monitor command in GDB. For a list of available commands and their description, check out monitor help.
Getting detailed logs
Most of the QEMU source code has commented lines of the form:
// #define DEBUG_*
If you are willing to edit and recompile QEMU, then you can get a good deal of debugging info output to stdout by uncommenting those lines at the top of the files that implement the pieces of the simulation you need more info about.
See Also
Articles
- QEMU and GDB in long mode
- QEMU_fw_cfg Pass strings and files into the VM from the QEMU command line