QEMU: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
(→‎Supported Devices: expanded list)
m (Highlighting errors)
 
(30 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{Emulators}}
{{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 [https://www.qemu.org/docs/master/ official documentation].



==Features==
==Features==
* Supports multiple hosts, multiple targets.
* 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).
* Two operating modes: full system emulation (of interest for operating-system development) and Linux user process emulation (of interests to people who want to emulate applications).
* it is faster than [[Bochs]] because it uses 'just in time' code compilation technique (allowing reuse of previous interpretation)
* Uses 'just in time' code compilation technique (allowing reuse of previous interpretation). This makes it faster than the popular alternative emulator [[Bochs]].
* 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.
* Provides native [[GDB]] support. QEMU can be attached to [[GDB]]/[[DDD]] to debug the guest operating-system. Refer to the [[QEMU#GDB-Stub|GDB-Stub]] section below for more information.
* Supports [[VBE]] 2.0.
* support [[VBE]] 2.0. This can be checked if you use the [[GRUB]] command line and type vbeprobe. The test returns:

===VBE Support===


[[VBE]] support be checked by typing '<tt>vbeprobe</tt>' on the [[GRUB]] command-line. The test returns:


===Supported VBE modes===
{| {{wikitable}}
{| {{wikitable}}
|-
|-
Line 74: Line 79:


==Supported Architectures==
==Supported Architectures==
*[[:Category:X86|x86]]
* [[:Category:X86|x86]]
*[[X86-64|x86_64]]
* [[X86-64|x86_64]]
*[[:Category:ARM|ARM]]
* [[:Category:ARM|ARM]]
*ARM64
* [[ARM64]]
*LatticeMico32
* [[LatticeMico32]]
*Motorola 68000
* [[M68k_Overview|Motorola 68000]]
*MicroBlaze
* [[MicroBlaze]]
*MIPS
* [[MIPS]]
*MIPS64
* [[MIPS64]]
*Moxie
* [[Moxie]]
*PowerPC
* [[PowerPC]]
*PowerPC64
* [[PowerPC64]]
* [[RISC-V]]
*IBM System/390
* [[IBM System/390]]
*SuperH
* [[SuperH]]
*[[:Category:Sparc|SPARC]]
* [[:Category:Sparc|SPARC]]
*SPARC64
* [[SPARC64]]
*TriCore
* [[TriCore]]
*Unicore
* [[Unicore]]
*Xtensa
* [[Xtensa]]


==Supported Devices==
==Supported Devices==
Line 103: Line 109:
* [[AC97]]
* [[AC97]]
* [[Intel_High_Definition_Audio|Intel High Definition Audio]]
* [[Intel_High_Definition_Audio|Intel High Definition Audio]]
* [[Virtio|virtio]] devices
* [[Virtio]] devices
* PCI SVGA card (Cirrus Logic 5446)
* PCI SVGA card (Cirrus Logic 5446)
* PCI support (With BIOS32).
* PCI support (With BIOS32).
* [[QEMU_fw_cfg]] Allows you to pass info to the guest


==Usage==
==Usage==


QEMU is easy to use, it does not have a configuration script like Bochs. To use QEMU with your OS,
QEMU does not require the use of a configuration script like Bochs. An example usage of QEMU can be seen below:


<syntaxhighlight lang="bash">
qemu -L .\ -fda my_disk_image.img -m 32
qemu-system-i386 \
-accel tcg,thread=single \
-cpu core2duo \
-m 128 \
-no-reboot \
-drive format=raw,media=cdrom,file=myos.iso \
-serial stdio \
-smp 1 \
-usb \
-vga std
</syntaxhighlight>


When running QEMU on a non-UNIX system, it may be necessary to use the <tt>-L</tt> command-line option to instruct QEMU where to find a BIOS image.
Or, if you use UNIX,
qemu -fda my_disk_image.img -m 32


The <tt>-m 128</tt> argument instructs QEMU to create the guest system with 128MB of RAM. The <tt>-drive format=raw,media=cdrom,file=myos.iso</tt> argument instructs QEMU to create a drive in our guest system. In this case the created drive is a CDROM drive, with <tt>myos.iso</tt> as its loaded media. If more than one drive in is required in the guest system, it is possible to use the <tt>-boot</tt> option to define the order in which the system will check for bootable media.
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


The <tt>-serial stdio</tt> argument used above instructs QEMU to redirect the serial input and output to the host system's <tt>stdio</tt> stream. This is particularly useful for debugging purposes. In the documentation, the option to redirect this to <tt>stdio</tt> is described as Unix only. Presumably, one should be able to achieve a similar effect with <tt>-serial file:CON</tt> on Windows.
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.


In order to help track down the source of a triple fault, the <tt>-d int</tt> option can be used to show additional debugging information on interrupts that occur. Additionally, the <tt>-no-shutdown</tt> and <tt>-no-reboot</tt> options can be used. These instruct the virtual machine to halt on error instead of rebooting or shutting down, allowing for the operator to inspect the state of the machine after a triple-fault.
Alternatively you can point -hdc or use -cdrom to an ISO image file (2048 bytes per sector ISO format).


Additional useful command-line options are listed within the [[QEMU#Useful_QEMU_command-line_options|Useful QEMU command-line options]] section.
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 keyboard shortcuts <tt>CTRL-ALT-{1,2,3}</tt> can be used inside the emulator to swap in/out of the emulation screen, the QEMU monitor and a serial console. Additional debugging commands can be issued from the system console, such as changing disk images and performing memory dumps, among others.
In order to track down a triple fault, you can use the <tt>-d int</tt> option to show what interrupts happen. Work can be done even more easily when passing the <tt>-no-shutdown -no-reboot</tt> 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===
===The debug console===


Instead of the serial port, as outlined above, one can also use the <tt>debugcon</tt> device. By running QEMU with <tt>-debugcon stdio</tt>, you can print a message to your host system's terminal by just writing each byte to port 0xe9. This is the same port as the one used by [[Bochs#I/O_debugger_macros|the equivalent feature in Bochs]].
It is possible to communicate with the QEMU console like one communicates with the Bochs console. However, this does not occur through port 0xE9 (which may be achieved by patching the source code however), but by using a serial port. ReactOS uses this to dump warning messages in the QEMU console. See [http://www.reactos.org/wiki/QEMU#Redirect_to_the_console the ReactOS wiki] for details.

Unlike the serial port, the debug console is one-way – you can only output. On the flip side, implementing support is much easier, and outputting the messages isn't artificially throttled by a baudrate.


===The QEMU monitor===
===The QEMU monitor===


{{Main|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. In Unix hosts, you can even redirect this monitor interface to the standard output using the

-monitor stdio

command-line option. Some useful commands:
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 <tt>CTRL-ALT-2</tt> within QEMU.

It is possible to redirect QEMU's monitor output to stdio using the following command-line option when invoking QEMU:
<syntaxhighlight lang="bash">
-monitor stdio
</syntaxhighlight>


Some useful commands:
; xp : eXamine Physical memory. Much like GDB's <tt>x</tt> command, but with no address translation.
; xp : eXamine Physical memory. Much like GDB's <tt>x</tt> 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.
; cpu n : switch to CPU n. Note that GDB's threads are numbered from 1, but QEMU's CPUs are numbered from 0.
Line 142: Line 170:
; help : List all commands -- keep in mind that there may be more commands available than those mentioned in the [http://www.qemu.org/qemu-doc.html#SEC12 QEMU documentation].
; help : List all commands -- keep in mind that there may be more commands available than those mentioned in the [http://www.qemu.org/qemu-doc.html#SEC12 QEMU documentation].


===GDB-stub===


A full 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].
When you supply the <tt>-s</tt> command line option, QEMU will listen on port localhost:1234 for a connection by GDB. If you also supply the <tt>-S</tt> 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.

==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 [https://qemu.weilnetz.de/doc/qemu-doc.html official QEMU documentation].''

{| {{wikitable}}
|-
! Option
! Description
|-
| <tt>-no-reboot</tt>
| Prevents QEMU from rebooting in the event of a [[Triple Fault]].
|-
| <tt>-no-shutdown</tt>
| Don’t exit QEMU on guest shutdown, but instead only stop the emulation.
|-
| <tt>-d</tt>
| Enables the printing of extra debugging information. Arguments for this option include <tt>cpu_reset, int, guest_errors</tt> ( among others ). This can be extremely useful when setting up an [[IDT]] to see interrupt execution in real-time.
|-
| <tt>-gdb</tt> or <tt>-s</tt>
| 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 [https://wiki.qemu.org/Documentation/Debugging official documentation].
|-
| <tt>-S</tt>
| 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 <tt>continue</tt> command in the console ( or GDB ) to initiate execution on the guest system.
|}

==GDB-Stub==

Starting QEMU with the <tt>-gdb</tt> or <tt>-s <dev></tt> command-line options will instruct QEMU to listen for an incoming [[GDB]] connection. By default QEMU will listen for a connection over HTTP on <tt>localhost:1234</tt>, but the option will accept an argument for a different connection. It is useful to use this switch together with the <tt>-S</tt> 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 <tt>continue</tt> 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 <tt>.gdbinit</tt> in the current working directory. Alternatively, a different file may be specified by the use the <tt>-command=file</tt> command-line argument. An example file can be seen below:

<!-- lang="gdb" Avoid highlighting errors -->
<syntaxhighlight lang="text">
file <my-kernel-binary>
target remote localhost:1234


# Inspect page tables
For convenience, I put a file called <tt>.gdbinit</tt> in the current working directory which automatically runs certain commands when you start GDB without the <tt>-n</tt> option. For example:
x /8wg &page_tables_start
</syntaxhighlight>


This will automatically load the kernel binary's symbol file into the debugger and then open the remote connection to QEMU.<br/>
file <my-kernel-binary>
Ensure that the kernel was compiled with debugging symbols included. This can be accomplished via the use of the GCC option <tt>-g</tt>. If you find that the debugger can't find local variables, try using the <tt>-fno-omit-frame-pointer</tt> option during compilation, or disable optimizations.
target remote localhost:1234


When running an SMP kernel, the <tt>info threads</tt> and <tt>thread</tt> commands can be used to provide useful information. It is also possible to use the QEMU monitor and its commands using the <tt>monitor</tt> command in GDB. For a list of available commands and their description, use the <tt>monitor help</tt> command.
will load into GDB your kernel and then connect to QEMU. Be sure to compile your kernel with the GCC option <tt>-g</tt> for debugging symbols. (If you find that the debugger can't find local variables, try using the <tt>-fno-omit-frame-pointer</tt> option when compiling, or disable optimizations.) Now you may debug your kernel as a C program.
If you have an SMP kernel, check out the <tt>info threads</tt> and <tt>thread</tt> commands. It is also possible to use the QEMU monitor and its commands using the <tt>monitor</tt> command in GDB. For a list of available commands and their description, check out <tt>monitor help</tt>.


===Getting detailed logs===
==Getting detailed logs==


It is possible to enable the output of additional debugging information to stdout by uncommenting certain preprocessor directives within the QEMU source files.
Most of the QEMU source code has commented lines of the form:


Some files within the QEMU source code have commented lines of the form:
// #define DEBUG_*
<syntaxhighlight lang="c">
// #define DEBUG_*
</syntaxhighlight>


Recompiling QEMU from source with this preprocessor variable defined will cause additional debugging information from the applicable file to be printed to stdout.
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==
==See Also==
Line 166: Line 233:
===Articles===
===Articles===
*[[QEMU and GDB in long mode]]
*[[QEMU and GDB in long mode]]
*[[QEMU_fw_cfg]] Pass strings and files into the VM from the QEMU command line


===External Links===
===External Links===
*[http://www.qemu.org/ QEMU homepage]
*[http://www.qemu.org/ QEMU homepage]
*[http://qemu-forum.ipi.fi/ QEMU forum]
*[http://qemu-forum.ipi.fi/ QEMU forum]
*[https://en.wikibooks.org/wiki/QEMU QEMU Wikibook]
*[https://wiki.archlinux.org/index.php/QEMU#Creating_a_hard_disk_image QEMU at ArchWiki]


[[Category:Emulators]]
[[Category:Emulators]]
[[Category:QEMU]]
[[de:QEMU]]
[[de:QEMU]]

Latest revision as of 07:15, 9 June 2024

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

  • Supports multiple hosts, multiple targets.
  • Two operating modes: full system emulation (of interest for operating-system development) and Linux user process emulation (of interests to people who want to emulate applications).
  • Uses 'just in time' code compilation technique (allowing reuse of previous interpretation). This makes it faster than the popular alternative emulator Bochs.
  • Provides native GDB support. QEMU can be attached to GDB/DDD to debug the guest operating-system. Refer to the GDB-Stub section below for more information.
  • Supports VBE 2.0.

VBE Support

VBE support be checked by typing 'vbeprobe' on the GRUB command-line. The test returns:

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

Supported Devices

Usage

QEMU does not require the use of a configuration script like Bochs. An example usage of QEMU can be seen below:

qemu-system-i386                                 \
  -accel tcg,thread=single                       \
  -cpu core2duo                                  \
  -m 128                                         \
  -no-reboot                                     \
  -drive format=raw,media=cdrom,file=myos.iso    \
  -serial stdio                                  \
  -smp 1                                         \
  -usb                                           \
  -vga std

When running QEMU on a non-UNIX system, it may be necessary to use the -L command-line option to instruct QEMU where to find a BIOS image.

The -m 128 argument instructs QEMU to create the guest system with 128MB of RAM. The -drive format=raw,media=cdrom,file=myos.iso argument instructs QEMU to create a drive in our guest system. In this case the created drive is a CDROM drive, with myos.iso as its loaded media. If more than one drive in is required in the guest system, it is possible to use the -boot option to define the order in which the system will check for bootable media.

The -serial stdio argument used above instructs QEMU to redirect the serial input and output to the host system's stdio stream. This is particularly useful for debugging purposes. In the documentation, the option to redirect this to stdio is described as Unix only. Presumably, one should be able to achieve a similar effect with -serial file:CON on Windows.

In order to help track down the source of a triple fault, the -d int option can be used to show additional debugging information on interrupts that occur. Additionally, the -no-shutdown and -no-reboot options can be used. These instruct the virtual machine to halt on error instead of rebooting or shutting down, allowing for the operator to inspect the state of the machine after a triple-fault.

Additional useful command-line options are listed within the Useful QEMU command-line options section.

The keyboard shortcuts CTRL-ALT-{1,2,3} can be used inside the emulator to swap in/out of the emulation screen, the QEMU monitor and a serial console. Additional debugging commands can be issued from the system console, such as changing disk images and performing memory dumps, among others.

The debug console

Instead of the serial port, as outlined above, one can also use the debugcon device. By running QEMU with -debugcon stdio, you can print a message to your host system's terminal by just writing each byte to port 0xe9. This is the same port as the one used by the equivalent feature in Bochs.

Unlike the serial port, the debug console is one-way – you can only output. On the flip side, implementing support is much easier, and outputting the messages isn't artificially throttled by a baudrate.

The QEMU monitor

Main article: 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.

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.

When running an SMP kernel, the info threads and thread commands can be used to provide useful information. 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, use the monitor help command.

Getting detailed logs

It is possible to enable the output of additional debugging information to stdout by uncommenting certain preprocessor directives within the QEMU source files.

Some files within the QEMU source code have commented lines of the form:

// #define DEBUG_*

Recompiling QEMU from source with this preprocessor variable defined will cause additional debugging information from the applicable file to be printed to stdout.

See Also

Articles

External Links