QEMU: Difference between revisions

1,723 bytes added ,  29 days ago
m
Highlighting errors
[unchecked revision][unchecked revision]
m (Highlighting errors)
 
(14 intermediate revisions by 6 users not shown)
Line 1:
{{Tone}}
{{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.weilnetz.deorg/docdocs/master/qemu-doc.html official documentation].
 
 
Line 113 ⟶ 112:
* PCI SVGA card (Cirrus Logic 5446)
* PCI support (With BIOS32).
* [[QEMU_fw_cfg]] Allows you to pass info to the guest
 
==Usage==
 
QEMU isdoes not easyrequire tothe use, it does not haveof a configuration script like Bochs. ToAn useexample usage of QEMU withcan be yourseen OS,below:
 
<sourcesyntaxhighlight lang="bash">
qemu-system-i386 \
qemu -L .\ -fda my_disk_image.img -m 32
-accel tcg,thread=single \
</source>
-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,
<source lang="bash">
qemu -fda my_disk_image.img -m 32
</source>
 
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.
 
WhilstThe insidekeyboard the emulator you can useshortcuts <tt>CTRL-ALT-{1,2,3}</tt> can be used inside the emulator to swap in/out of the emulation screen, the QEMU consolemonitor and a serial console. TheAdditional debugging commands can be issued from the system console, letssuch youas changechanging disk images and other things and doperforming memory dumps, among etcothers.
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 QEMUdebug Consoleconsole===
 
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]].
QEMU's internal console can be accessed by the key combination CTRL-ALT-3 within QEMU.
 
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.
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:
<source lang="bash">
-serial file:CON
</source>
 
===The QEMU monitor===
 
{{Main|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 <tt>CTRL-ALT-2</tt> within QEMU.
 
If you are running QEMU from the command-line, itIt is possible to redirect QEMU's monitor output to stdio using the following command -line option when invoking QEMU:
<sourcesyntaxhighlight lang="bash">
-monitor stdio
</syntaxhighlight>
</source>
 
 
Line 198 ⟶ 204:
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:
 
<source!-- lang="gdb" Avoid highlighting errors -->
<syntaxhighlight lang="text">
file <my-kernel-binary>
target remote localhost:1234
Line 204 ⟶ 211:
# Inspect page tables
x /8wg &page_tables_start
</syntaxhighlight>
</source>
 
This will automatically load the kernel binary's symbol file into the debugger and then open the remote connection to QEMU.<br/>
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.
 
IfWhen you haverunning an SMP kernel, check out 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, checkuse outthe <tt>monitor help</tt> 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.
Most of the QEMU source code has commented lines of the form:
 
<source lang="c">
MostSome offiles within the QEMU source code hashave commented lines of the form:
<sourcesyntaxhighlight lang="c">
// #define DEBUG_*
</syntaxhighlight>
</source>
 
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==
Line 229 ⟶ 238:
*[http://www.qemu.org/ QEMU homepage]
*[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:QEMU]]
[[de:QEMU]]