]> git.proxmox.com Git - mirror_qemu.git/blob - qemu-doc.texi
target-ppc: Altivec 2.07: Change VMUL_DO to Support 64-bit Integers
[mirror_qemu.git] / qemu-doc.texi
1 \input texinfo @c -*- texinfo -*-
2 @c %**start of header
3 @setfilename qemu-doc.info
4
5 @documentlanguage en
6 @documentencoding UTF-8
7
8 @settitle QEMU Emulator User Documentation
9 @exampleindent 0
10 @paragraphindent 0
11 @c %**end of header
12
13 @ifinfo
14 @direntry
15 * QEMU: (qemu-doc). The QEMU Emulator User Documentation.
16 @end direntry
17 @end ifinfo
18
19 @iftex
20 @titlepage
21 @sp 7
22 @center @titlefont{QEMU Emulator}
23 @sp 1
24 @center @titlefont{User Documentation}
25 @sp 3
26 @end titlepage
27 @end iftex
28
29 @ifnottex
30 @node Top
31 @top
32
33 @menu
34 * Introduction::
35 * Installation::
36 * QEMU PC System emulator::
37 * QEMU System emulator for non PC targets::
38 * QEMU User space emulator::
39 * compilation:: Compilation from the sources
40 * License::
41 * Index::
42 @end menu
43 @end ifnottex
44
45 @contents
46
47 @node Introduction
48 @chapter Introduction
49
50 @menu
51 * intro_features:: Features
52 @end menu
53
54 @node intro_features
55 @section Features
56
57 QEMU is a FAST! processor emulator using dynamic translation to
58 achieve good emulation speed.
59
60 QEMU has two operating modes:
61
62 @itemize
63 @cindex operating modes
64
65 @item
66 @cindex system emulation
67 Full system emulation. In this mode, QEMU emulates a full system (for
68 example a PC), including one or several processors and various
69 peripherals. It can be used to launch different Operating Systems
70 without rebooting the PC or to debug system code.
71
72 @item
73 @cindex user mode emulation
74 User mode emulation. In this mode, QEMU can launch
75 processes compiled for one CPU on another CPU. It can be used to
76 launch the Wine Windows API emulator (@url{http://www.winehq.org}) or
77 to ease cross-compilation and cross-debugging.
78
79 @end itemize
80
81 QEMU can run without a host kernel driver and yet gives acceptable
82 performance.
83
84 For system emulation, the following hardware targets are supported:
85 @itemize
86 @cindex emulated target systems
87 @cindex supported target systems
88 @item PC (x86 or x86_64 processor)
89 @item ISA PC (old style PC without PCI bus)
90 @item PREP (PowerPC processor)
91 @item G3 Beige PowerMac (PowerPC processor)
92 @item Mac99 PowerMac (PowerPC processor, in progress)
93 @item Sun4m/Sun4c/Sun4d (32-bit Sparc processor)
94 @item Sun4u/Sun4v (64-bit Sparc processor, in progress)
95 @item Malta board (32-bit and 64-bit MIPS processors)
96 @item MIPS Magnum (64-bit MIPS processor)
97 @item ARM Integrator/CP (ARM)
98 @item ARM Versatile baseboard (ARM)
99 @item ARM RealView Emulation/Platform baseboard (ARM)
100 @item Spitz, Akita, Borzoi, Terrier and Tosa PDAs (PXA270 processor)
101 @item Luminary Micro LM3S811EVB (ARM Cortex-M3)
102 @item Luminary Micro LM3S6965EVB (ARM Cortex-M3)
103 @item Freescale MCF5208EVB (ColdFire V2).
104 @item Arnewsh MCF5206 evaluation board (ColdFire V2).
105 @item Palm Tungsten|E PDA (OMAP310 processor)
106 @item N800 and N810 tablets (OMAP2420 processor)
107 @item MusicPal (MV88W8618 ARM processor)
108 @item Gumstix "Connex" and "Verdex" motherboards (PXA255/270).
109 @item Siemens SX1 smartphone (OMAP310 processor)
110 @item AXIS-Devboard88 (CRISv32 ETRAX-FS).
111 @item Petalogix Spartan 3aDSP1800 MMU ref design (MicroBlaze).
112 @item Avnet LX60/LX110/LX200 boards (Xtensa)
113 @end itemize
114
115 @cindex supported user mode targets
116 For user emulation, x86 (32 and 64 bit), PowerPC (32 and 64 bit),
117 ARM, MIPS (32 bit only), Sparc (32 and 64 bit),
118 Alpha, ColdFire(m68k), CRISv32 and MicroBlaze CPUs are supported.
119
120 @node Installation
121 @chapter Installation
122
123 If you want to compile QEMU yourself, see @ref{compilation}.
124
125 @menu
126 * install_linux:: Linux
127 * install_windows:: Windows
128 * install_mac:: Macintosh
129 @end menu
130
131 @node install_linux
132 @section Linux
133 @cindex installation (Linux)
134
135 If a precompiled package is available for your distribution - you just
136 have to install it. Otherwise, see @ref{compilation}.
137
138 @node install_windows
139 @section Windows
140 @cindex installation (Windows)
141
142 Download the experimental binary installer at
143 @url{http://www.free.oszoo.org/@/download.html}.
144 TODO (no longer available)
145
146 @node install_mac
147 @section Mac OS X
148
149 Download the experimental binary installer at
150 @url{http://www.free.oszoo.org/@/download.html}.
151 TODO (no longer available)
152
153 @node QEMU PC System emulator
154 @chapter QEMU PC System emulator
155 @cindex system emulation (PC)
156
157 @menu
158 * pcsys_introduction:: Introduction
159 * pcsys_quickstart:: Quick Start
160 * sec_invocation:: Invocation
161 * pcsys_keys:: Keys
162 * pcsys_monitor:: QEMU Monitor
163 * disk_images:: Disk Images
164 * pcsys_network:: Network emulation
165 * pcsys_other_devs:: Other Devices
166 * direct_linux_boot:: Direct Linux Boot
167 * pcsys_usb:: USB emulation
168 * vnc_security:: VNC security
169 * gdb_usage:: GDB usage
170 * pcsys_os_specific:: Target OS specific information
171 @end menu
172
173 @node pcsys_introduction
174 @section Introduction
175
176 @c man begin DESCRIPTION
177
178 The QEMU PC System emulator simulates the
179 following peripherals:
180
181 @itemize @minus
182 @item
183 i440FX host PCI bridge and PIIX3 PCI to ISA bridge
184 @item
185 Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA
186 extensions (hardware level, including all non standard modes).
187 @item
188 PS/2 mouse and keyboard
189 @item
190 2 PCI IDE interfaces with hard disk and CD-ROM support
191 @item
192 Floppy disk
193 @item
194 PCI and ISA network adapters
195 @item
196 Serial ports
197 @item
198 Creative SoundBlaster 16 sound card
199 @item
200 ENSONIQ AudioPCI ES1370 sound card
201 @item
202 Intel 82801AA AC97 Audio compatible sound card
203 @item
204 Intel HD Audio Controller and HDA codec
205 @item
206 Adlib (OPL2) - Yamaha YM3812 compatible chip
207 @item
208 Gravis Ultrasound GF1 sound card
209 @item
210 CS4231A compatible sound card
211 @item
212 PCI UHCI USB controller and a virtual USB hub.
213 @end itemize
214
215 SMP is supported with up to 255 CPUs.
216
217 QEMU uses the PC BIOS from the Seabios project and the Plex86/Bochs LGPL
218 VGA BIOS.
219
220 QEMU uses YM3812 emulation by Tatsuyuki Satoh.
221
222 QEMU uses GUS emulation (GUSEMU32 @url{http://www.deinmeister.de/gusemu/})
223 by Tibor "TS" Schütz.
224
225 Note that, by default, GUS shares IRQ(7) with parallel ports and so
226 QEMU must be told to not have parallel ports to have working GUS.
227
228 @example
229 qemu-system-i386 dos.img -soundhw gus -parallel none
230 @end example
231
232 Alternatively:
233 @example
234 qemu-system-i386 dos.img -device gus,irq=5
235 @end example
236
237 Or some other unclaimed IRQ.
238
239 CS4231A is the chip used in Windows Sound System and GUSMAX products
240
241 @c man end
242
243 @node pcsys_quickstart
244 @section Quick Start
245 @cindex quick start
246
247 Download and uncompress the linux image (@file{linux.img}) and type:
248
249 @example
250 qemu-system-i386 linux.img
251 @end example
252
253 Linux should boot and give you a prompt.
254
255 @node sec_invocation
256 @section Invocation
257
258 @example
259 @c man begin SYNOPSIS
260 usage: qemu-system-i386 [options] [@var{disk_image}]
261 @c man end
262 @end example
263
264 @c man begin OPTIONS
265 @var{disk_image} is a raw hard disk image for IDE hard disk 0. Some
266 targets do not need a disk image.
267
268 @include qemu-options.texi
269
270 @c man end
271
272 @node pcsys_keys
273 @section Keys
274
275 @c man begin OPTIONS
276
277 During the graphical emulation, you can use special key combinations to change
278 modes. The default key mappings are shown below, but if you use @code{-alt-grab}
279 then the modifier is Ctrl-Alt-Shift (instead of Ctrl-Alt) and if you use
280 @code{-ctrl-grab} then the modifier is the right Ctrl key (instead of Ctrl-Alt):
281
282 @table @key
283 @item Ctrl-Alt-f
284 @kindex Ctrl-Alt-f
285 Toggle full screen
286
287 @item Ctrl-Alt-+
288 @kindex Ctrl-Alt-+
289 Enlarge the screen
290
291 @item Ctrl-Alt--
292 @kindex Ctrl-Alt--
293 Shrink the screen
294
295 @item Ctrl-Alt-u
296 @kindex Ctrl-Alt-u
297 Restore the screen's un-scaled dimensions
298
299 @item Ctrl-Alt-n
300 @kindex Ctrl-Alt-n
301 Switch to virtual console 'n'. Standard console mappings are:
302 @table @emph
303 @item 1
304 Target system display
305 @item 2
306 Monitor
307 @item 3
308 Serial port
309 @end table
310
311 @item Ctrl-Alt
312 @kindex Ctrl-Alt
313 Toggle mouse and keyboard grab.
314 @end table
315
316 @kindex Ctrl-Up
317 @kindex Ctrl-Down
318 @kindex Ctrl-PageUp
319 @kindex Ctrl-PageDown
320 In the virtual consoles, you can use @key{Ctrl-Up}, @key{Ctrl-Down},
321 @key{Ctrl-PageUp} and @key{Ctrl-PageDown} to move in the back log.
322
323 @kindex Ctrl-a h
324 During emulation, if you are using the @option{-nographic} option, use
325 @key{Ctrl-a h} to get terminal commands:
326
327 @table @key
328 @item Ctrl-a h
329 @kindex Ctrl-a h
330 @item Ctrl-a ?
331 @kindex Ctrl-a ?
332 Print this help
333 @item Ctrl-a x
334 @kindex Ctrl-a x
335 Exit emulator
336 @item Ctrl-a s
337 @kindex Ctrl-a s
338 Save disk data back to file (if -snapshot)
339 @item Ctrl-a t
340 @kindex Ctrl-a t
341 Toggle console timestamps
342 @item Ctrl-a b
343 @kindex Ctrl-a b
344 Send break (magic sysrq in Linux)
345 @item Ctrl-a c
346 @kindex Ctrl-a c
347 Switch between console and monitor
348 @item Ctrl-a Ctrl-a
349 @kindex Ctrl-a a
350 Send Ctrl-a
351 @end table
352 @c man end
353
354 @ignore
355
356 @c man begin SEEALSO
357 The HTML documentation of QEMU for more precise information and Linux
358 user mode emulator invocation.
359 @c man end
360
361 @c man begin AUTHOR
362 Fabrice Bellard
363 @c man end
364
365 @end ignore
366
367 @node pcsys_monitor
368 @section QEMU Monitor
369 @cindex QEMU monitor
370
371 The QEMU monitor is used to give complex commands to the QEMU
372 emulator. You can use it to:
373
374 @itemize @minus
375
376 @item
377 Remove or insert removable media images
378 (such as CD-ROM or floppies).
379
380 @item
381 Freeze/unfreeze the Virtual Machine (VM) and save or restore its state
382 from a disk file.
383
384 @item Inspect the VM state without an external debugger.
385
386 @end itemize
387
388 @subsection Commands
389
390 The following commands are available:
391
392 @include qemu-monitor.texi
393
394 @subsection Integer expressions
395
396 The monitor understands integers expressions for every integer
397 argument. You can use register names to get the value of specifics
398 CPU registers by prefixing them with @emph{$}.
399
400 @node disk_images
401 @section Disk Images
402
403 Since version 0.6.1, QEMU supports many disk image formats, including
404 growable disk images (their size increase as non empty sectors are
405 written), compressed and encrypted disk images. Version 0.8.3 added
406 the new qcow2 disk image format which is essential to support VM
407 snapshots.
408
409 @menu
410 * disk_images_quickstart:: Quick start for disk image creation
411 * disk_images_snapshot_mode:: Snapshot mode
412 * vm_snapshots:: VM snapshots
413 * qemu_img_invocation:: qemu-img Invocation
414 * qemu_nbd_invocation:: qemu-nbd Invocation
415 * disk_images_formats:: Disk image file formats
416 * host_drives:: Using host drives
417 * disk_images_fat_images:: Virtual FAT disk images
418 * disk_images_nbd:: NBD access
419 * disk_images_sheepdog:: Sheepdog disk images
420 * disk_images_iscsi:: iSCSI LUNs
421 * disk_images_gluster:: GlusterFS disk images
422 * disk_images_ssh:: Secure Shell (ssh) disk images
423 @end menu
424
425 @node disk_images_quickstart
426 @subsection Quick start for disk image creation
427
428 You can create a disk image with the command:
429 @example
430 qemu-img create myimage.img mysize
431 @end example
432 where @var{myimage.img} is the disk image filename and @var{mysize} is its
433 size in kilobytes. You can add an @code{M} suffix to give the size in
434 megabytes and a @code{G} suffix for gigabytes.
435
436 See @ref{qemu_img_invocation} for more information.
437
438 @node disk_images_snapshot_mode
439 @subsection Snapshot mode
440
441 If you use the option @option{-snapshot}, all disk images are
442 considered as read only. When sectors in written, they are written in
443 a temporary file created in @file{/tmp}. You can however force the
444 write back to the raw disk images by using the @code{commit} monitor
445 command (or @key{C-a s} in the serial console).
446
447 @node vm_snapshots
448 @subsection VM snapshots
449
450 VM snapshots are snapshots of the complete virtual machine including
451 CPU state, RAM, device state and the content of all the writable
452 disks. In order to use VM snapshots, you must have at least one non
453 removable and writable block device using the @code{qcow2} disk image
454 format. Normally this device is the first virtual hard drive.
455
456 Use the monitor command @code{savevm} to create a new VM snapshot or
457 replace an existing one. A human readable name can be assigned to each
458 snapshot in addition to its numerical ID.
459
460 Use @code{loadvm} to restore a VM snapshot and @code{delvm} to remove
461 a VM snapshot. @code{info snapshots} lists the available snapshots
462 with their associated information:
463
464 @example
465 (qemu) info snapshots
466 Snapshot devices: hda
467 Snapshot list (from hda):
468 ID TAG VM SIZE DATE VM CLOCK
469 1 start 41M 2006-08-06 12:38:02 00:00:14.954
470 2 40M 2006-08-06 12:43:29 00:00:18.633
471 3 msys 40M 2006-08-06 12:44:04 00:00:23.514
472 @end example
473
474 A VM snapshot is made of a VM state info (its size is shown in
475 @code{info snapshots}) and a snapshot of every writable disk image.
476 The VM state info is stored in the first @code{qcow2} non removable
477 and writable block device. The disk image snapshots are stored in
478 every disk image. The size of a snapshot in a disk image is difficult
479 to evaluate and is not shown by @code{info snapshots} because the
480 associated disk sectors are shared among all the snapshots to save
481 disk space (otherwise each snapshot would need a full copy of all the
482 disk images).
483
484 When using the (unrelated) @code{-snapshot} option
485 (@ref{disk_images_snapshot_mode}), you can always make VM snapshots,
486 but they are deleted as soon as you exit QEMU.
487
488 VM snapshots currently have the following known limitations:
489 @itemize
490 @item
491 They cannot cope with removable devices if they are removed or
492 inserted after a snapshot is done.
493 @item
494 A few device drivers still have incomplete snapshot support so their
495 state is not saved or restored properly (in particular USB).
496 @end itemize
497
498 @node qemu_img_invocation
499 @subsection @code{qemu-img} Invocation
500
501 @include qemu-img.texi
502
503 @node qemu_nbd_invocation
504 @subsection @code{qemu-nbd} Invocation
505
506 @include qemu-nbd.texi
507
508 @node disk_images_formats
509 @subsection Disk image file formats
510
511 QEMU supports many image file formats that can be used with VMs as well as with
512 any of the tools (like @code{qemu-img}). This includes the preferred formats
513 raw and qcow2 as well as formats that are supported for compatibility with
514 older QEMU versions or other hypervisors.
515
516 Depending on the image format, different options can be passed to
517 @code{qemu-img create} and @code{qemu-img convert} using the @code{-o} option.
518 This section describes each format and the options that are supported for it.
519
520 @table @option
521 @item raw
522
523 Raw disk image format. This format has the advantage of
524 being simple and easily exportable to all other emulators. If your
525 file system supports @emph{holes} (for example in ext2 or ext3 on
526 Linux or NTFS on Windows), then only the written sectors will reserve
527 space. Use @code{qemu-img info} to know the real size used by the
528 image or @code{ls -ls} on Unix/Linux.
529
530 @item qcow2
531 QEMU image format, the most versatile format. Use it to have smaller
532 images (useful if your filesystem does not supports holes, for example
533 on Windows), optional AES encryption, zlib based compression and
534 support of multiple VM snapshots.
535
536 Supported options:
537 @table @code
538 @item compat
539 Determines the qcow2 version to use. @code{compat=0.10} uses the
540 traditional image format that can be read by any QEMU since 0.10.
541 @code{compat=1.1} enables image format extensions that only QEMU 1.1 and
542 newer understand (this is the default). Amongst others, this includes
543 zero clusters, which allow efficient copy-on-read for sparse images.
544
545 @item backing_file
546 File name of a base image (see @option{create} subcommand)
547 @item backing_fmt
548 Image format of the base image
549 @item encryption
550 If this option is set to @code{on}, the image is encrypted with 128-bit AES-CBC.
551
552 The use of encryption in qcow and qcow2 images is considered to be flawed by
553 modern cryptography standards, suffering from a number of design problems:
554
555 @itemize @minus
556 @item The AES-CBC cipher is used with predictable initialization vectors based
557 on the sector number. This makes it vulnerable to chosen plaintext attacks
558 which can reveal the existence of encrypted data.
559 @item The user passphrase is directly used as the encryption key. A poorly
560 chosen or short passphrase will compromise the security of the encryption.
561 @item In the event of the passphrase being compromised there is no way to
562 change the passphrase to protect data in any qcow images. The files must
563 be cloned, using a different encryption passphrase in the new file. The
564 original file must then be securely erased using a program like shred,
565 though even this is ineffective with many modern storage technologies.
566 @end itemize
567
568 Use of qcow / qcow2 encryption is thus strongly discouraged. Users are
569 recommended to use an alternative encryption technology such as the
570 Linux dm-crypt / LUKS system.
571
572 @item cluster_size
573 Changes the qcow2 cluster size (must be between 512 and 2M). Smaller cluster
574 sizes can improve the image file size whereas larger cluster sizes generally
575 provide better performance.
576
577 @item preallocation
578 Preallocation mode (allowed values: off, metadata). An image with preallocated
579 metadata is initially larger but can improve performance when the image needs
580 to grow.
581
582 @item lazy_refcounts
583 If this option is set to @code{on}, reference count updates are postponed with
584 the goal of avoiding metadata I/O and improving performance. This is
585 particularly interesting with @option{cache=writethrough} which doesn't batch
586 metadata updates. The tradeoff is that after a host crash, the reference count
587 tables must be rebuilt, i.e. on the next open an (automatic) @code{qemu-img
588 check -r all} is required, which may take some time.
589
590 This option can only be enabled if @code{compat=1.1} is specified.
591
592 @end table
593
594 @item qed
595 Old QEMU image format with support for backing files and compact image files
596 (when your filesystem or transport medium does not support holes).
597
598 When converting QED images to qcow2, you might want to consider using the
599 @code{lazy_refcounts=on} option to get a more QED-like behaviour.
600
601 Supported options:
602 @table @code
603 @item backing_file
604 File name of a base image (see @option{create} subcommand).
605 @item backing_fmt
606 Image file format of backing file (optional). Useful if the format cannot be
607 autodetected because it has no header, like some vhd/vpc files.
608 @item cluster_size
609 Changes the cluster size (must be power-of-2 between 4K and 64K). Smaller
610 cluster sizes can improve the image file size whereas larger cluster sizes
611 generally provide better performance.
612 @item table_size
613 Changes the number of clusters per L1/L2 table (must be power-of-2 between 1
614 and 16). There is normally no need to change this value but this option can be
615 used for performance benchmarking.
616 @end table
617
618 @item qcow
619 Old QEMU image format with support for backing files, compact image files,
620 encryption and compression.
621
622 Supported options:
623 @table @code
624 @item backing_file
625 File name of a base image (see @option{create} subcommand)
626 @item encryption
627 If this option is set to @code{on}, the image is encrypted.
628 @end table
629
630 @item cow
631 User Mode Linux Copy On Write image format. It is supported only for
632 compatibility with previous versions.
633 Supported options:
634 @table @code
635 @item backing_file
636 File name of a base image (see @option{create} subcommand)
637 @end table
638
639 @item vdi
640 VirtualBox 1.1 compatible image format.
641 Supported options:
642 @table @code
643 @item static
644 If this option is set to @code{on}, the image is created with metadata
645 preallocation.
646 @end table
647
648 @item vmdk
649 VMware 3 and 4 compatible image format.
650
651 Supported options:
652 @table @code
653 @item backing_file
654 File name of a base image (see @option{create} subcommand).
655 @item compat6
656 Create a VMDK version 6 image (instead of version 4)
657 @item subformat
658 Specifies which VMDK subformat to use. Valid options are
659 @code{monolithicSparse} (default),
660 @code{monolithicFlat},
661 @code{twoGbMaxExtentSparse},
662 @code{twoGbMaxExtentFlat} and
663 @code{streamOptimized}.
664 @end table
665
666 @item vpc
667 VirtualPC compatible image format (VHD).
668 Supported options:
669 @table @code
670 @item subformat
671 Specifies which VHD subformat to use. Valid options are
672 @code{dynamic} (default) and @code{fixed}.
673 @end table
674
675 @item VHDX
676 Hyper-V compatible image format (VHDX).
677 Supported options:
678 @table @code
679 @item subformat
680 Specifies which VHDX subformat to use. Valid options are
681 @code{dynamic} (default) and @code{fixed}.
682 @item block_state_zero
683 Force use of payload blocks of type 'ZERO'.
684 @item block_size
685 Block size; min 1 MB, max 256 MB. 0 means auto-calculate based on image size.
686 @item log_size
687 Log size; min 1 MB.
688 @end table
689 @end table
690
691 @subsubsection Read-only formats
692 More disk image file formats are supported in a read-only mode.
693 @table @option
694 @item bochs
695 Bochs images of @code{growing} type.
696 @item cloop
697 Linux Compressed Loop image, useful only to reuse directly compressed
698 CD-ROM images present for example in the Knoppix CD-ROMs.
699 @item dmg
700 Apple disk image.
701 @item parallels
702 Parallels disk image format.
703 @end table
704
705
706 @node host_drives
707 @subsection Using host drives
708
709 In addition to disk image files, QEMU can directly access host
710 devices. We describe here the usage for QEMU version >= 0.8.3.
711
712 @subsubsection Linux
713
714 On Linux, you can directly use the host device filename instead of a
715 disk image filename provided you have enough privileges to access
716 it. For example, use @file{/dev/cdrom} to access to the CDROM or
717 @file{/dev/fd0} for the floppy.
718
719 @table @code
720 @item CD
721 You can specify a CDROM device even if no CDROM is loaded. QEMU has
722 specific code to detect CDROM insertion or removal. CDROM ejection by
723 the guest OS is supported. Currently only data CDs are supported.
724 @item Floppy
725 You can specify a floppy device even if no floppy is loaded. Floppy
726 removal is currently not detected accurately (if you change floppy
727 without doing floppy access while the floppy is not loaded, the guest
728 OS will think that the same floppy is loaded).
729 @item Hard disks
730 Hard disks can be used. Normally you must specify the whole disk
731 (@file{/dev/hdb} instead of @file{/dev/hdb1}) so that the guest OS can
732 see it as a partitioned disk. WARNING: unless you know what you do, it
733 is better to only make READ-ONLY accesses to the hard disk otherwise
734 you may corrupt your host data (use the @option{-snapshot} command
735 line option or modify the device permissions accordingly).
736 @end table
737
738 @subsubsection Windows
739
740 @table @code
741 @item CD
742 The preferred syntax is the drive letter (e.g. @file{d:}). The
743 alternate syntax @file{\\.\d:} is supported. @file{/dev/cdrom} is
744 supported as an alias to the first CDROM drive.
745
746 Currently there is no specific code to handle removable media, so it
747 is better to use the @code{change} or @code{eject} monitor commands to
748 change or eject media.
749 @item Hard disks
750 Hard disks can be used with the syntax: @file{\\.\PhysicalDrive@var{N}}
751 where @var{N} is the drive number (0 is the first hard disk).
752
753 WARNING: unless you know what you do, it is better to only make
754 READ-ONLY accesses to the hard disk otherwise you may corrupt your
755 host data (use the @option{-snapshot} command line so that the
756 modifications are written in a temporary file).
757 @end table
758
759
760 @subsubsection Mac OS X
761
762 @file{/dev/cdrom} is an alias to the first CDROM.
763
764 Currently there is no specific code to handle removable media, so it
765 is better to use the @code{change} or @code{eject} monitor commands to
766 change or eject media.
767
768 @node disk_images_fat_images
769 @subsection Virtual FAT disk images
770
771 QEMU can automatically create a virtual FAT disk image from a
772 directory tree. In order to use it, just type:
773
774 @example
775 qemu-system-i386 linux.img -hdb fat:/my_directory
776 @end example
777
778 Then you access access to all the files in the @file{/my_directory}
779 directory without having to copy them in a disk image or to export
780 them via SAMBA or NFS. The default access is @emph{read-only}.
781
782 Floppies can be emulated with the @code{:floppy:} option:
783
784 @example
785 qemu-system-i386 linux.img -fda fat:floppy:/my_directory
786 @end example
787
788 A read/write support is available for testing (beta stage) with the
789 @code{:rw:} option:
790
791 @example
792 qemu-system-i386 linux.img -fda fat:floppy:rw:/my_directory
793 @end example
794
795 What you should @emph{never} do:
796 @itemize
797 @item use non-ASCII filenames ;
798 @item use "-snapshot" together with ":rw:" ;
799 @item expect it to work when loadvm'ing ;
800 @item write to the FAT directory on the host system while accessing it with the guest system.
801 @end itemize
802
803 @node disk_images_nbd
804 @subsection NBD access
805
806 QEMU can access directly to block device exported using the Network Block Device
807 protocol.
808
809 @example
810 qemu-system-i386 linux.img -hdb nbd://my_nbd_server.mydomain.org:1024/
811 @end example
812
813 If the NBD server is located on the same host, you can use an unix socket instead
814 of an inet socket:
815
816 @example
817 qemu-system-i386 linux.img -hdb nbd+unix://?socket=/tmp/my_socket
818 @end example
819
820 In this case, the block device must be exported using qemu-nbd:
821
822 @example
823 qemu-nbd --socket=/tmp/my_socket my_disk.qcow2
824 @end example
825
826 The use of qemu-nbd allows to share a disk between several guests:
827 @example
828 qemu-nbd --socket=/tmp/my_socket --share=2 my_disk.qcow2
829 @end example
830
831 @noindent
832 and then you can use it with two guests:
833 @example
834 qemu-system-i386 linux1.img -hdb nbd+unix://?socket=/tmp/my_socket
835 qemu-system-i386 linux2.img -hdb nbd+unix://?socket=/tmp/my_socket
836 @end example
837
838 If the nbd-server uses named exports (supported since NBD 2.9.18, or with QEMU's
839 own embedded NBD server), you must specify an export name in the URI:
840 @example
841 qemu-system-i386 -cdrom nbd://localhost/debian-500-ppc-netinst
842 qemu-system-i386 -cdrom nbd://localhost/openSUSE-11.1-ppc-netinst
843 @end example
844
845 The URI syntax for NBD is supported since QEMU 1.3. An alternative syntax is
846 also available. Here are some example of the older syntax:
847 @example
848 qemu-system-i386 linux.img -hdb nbd:my_nbd_server.mydomain.org:1024
849 qemu-system-i386 linux2.img -hdb nbd:unix:/tmp/my_socket
850 qemu-system-i386 -cdrom nbd:localhost:10809:exportname=debian-500-ppc-netinst
851 @end example
852
853 @node disk_images_sheepdog
854 @subsection Sheepdog disk images
855
856 Sheepdog is a distributed storage system for QEMU. It provides highly
857 available block level storage volumes that can be attached to
858 QEMU-based virtual machines.
859
860 You can create a Sheepdog disk image with the command:
861 @example
862 qemu-img create sheepdog:///@var{image} @var{size}
863 @end example
864 where @var{image} is the Sheepdog image name and @var{size} is its
865 size.
866
867 To import the existing @var{filename} to Sheepdog, you can use a
868 convert command.
869 @example
870 qemu-img convert @var{filename} sheepdog:///@var{image}
871 @end example
872
873 You can boot from the Sheepdog disk image with the command:
874 @example
875 qemu-system-i386 sheepdog:///@var{image}
876 @end example
877
878 You can also create a snapshot of the Sheepdog image like qcow2.
879 @example
880 qemu-img snapshot -c @var{tag} sheepdog:///@var{image}
881 @end example
882 where @var{tag} is a tag name of the newly created snapshot.
883
884 To boot from the Sheepdog snapshot, specify the tag name of the
885 snapshot.
886 @example
887 qemu-system-i386 sheepdog:///@var{image}#@var{tag}
888 @end example
889
890 You can create a cloned image from the existing snapshot.
891 @example
892 qemu-img create -b sheepdog:///@var{base}#@var{tag} sheepdog:///@var{image}
893 @end example
894 where @var{base} is a image name of the source snapshot and @var{tag}
895 is its tag name.
896
897 You can use an unix socket instead of an inet socket:
898
899 @example
900 qemu-system-i386 sheepdog+unix:///@var{image}?socket=@var{path}
901 @end example
902
903 If the Sheepdog daemon doesn't run on the local host, you need to
904 specify one of the Sheepdog servers to connect to.
905 @example
906 qemu-img create sheepdog://@var{hostname}:@var{port}/@var{image} @var{size}
907 qemu-system-i386 sheepdog://@var{hostname}:@var{port}/@var{image}
908 @end example
909
910 @node disk_images_iscsi
911 @subsection iSCSI LUNs
912
913 iSCSI is a popular protocol used to access SCSI devices across a computer
914 network.
915
916 There are two different ways iSCSI devices can be used by QEMU.
917
918 The first method is to mount the iSCSI LUN on the host, and make it appear as
919 any other ordinary SCSI device on the host and then to access this device as a
920 /dev/sd device from QEMU. How to do this differs between host OSes.
921
922 The second method involves using the iSCSI initiator that is built into
923 QEMU. This provides a mechanism that works the same way regardless of which
924 host OS you are running QEMU on. This section will describe this second method
925 of using iSCSI together with QEMU.
926
927 In QEMU, iSCSI devices are described using special iSCSI URLs
928
929 @example
930 URL syntax:
931 iscsi://[<username>[%<password>]@@]<host>[:<port>]/<target-iqn-name>/<lun>
932 @end example
933
934 Username and password are optional and only used if your target is set up
935 using CHAP authentication for access control.
936 Alternatively the username and password can also be set via environment
937 variables to have these not show up in the process list
938
939 @example
940 export LIBISCSI_CHAP_USERNAME=<username>
941 export LIBISCSI_CHAP_PASSWORD=<password>
942 iscsi://<host>/<target-iqn-name>/<lun>
943 @end example
944
945 Various session related parameters can be set via special options, either
946 in a configuration file provided via '-readconfig' or directly on the
947 command line.
948
949 If the initiator-name is not specified qemu will use a default name
950 of 'iqn.2008-11.org.linux-kvm[:<name>'] where <name> is the name of the
951 virtual machine.
952
953
954 @example
955 Setting a specific initiator name to use when logging in to the target
956 -iscsi initiator-name=iqn.qemu.test:my-initiator
957 @end example
958
959 @example
960 Controlling which type of header digest to negotiate with the target
961 -iscsi header-digest=CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
962 @end example
963
964 These can also be set via a configuration file
965 @example
966 [iscsi]
967 user = "CHAP username"
968 password = "CHAP password"
969 initiator-name = "iqn.qemu.test:my-initiator"
970 # header digest is one of CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
971 header-digest = "CRC32C"
972 @end example
973
974
975 Setting the target name allows different options for different targets
976 @example
977 [iscsi "iqn.target.name"]
978 user = "CHAP username"
979 password = "CHAP password"
980 initiator-name = "iqn.qemu.test:my-initiator"
981 # header digest is one of CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
982 header-digest = "CRC32C"
983 @end example
984
985
986 Howto use a configuration file to set iSCSI configuration options:
987 @example
988 cat >iscsi.conf <<EOF
989 [iscsi]
990 user = "me"
991 password = "my password"
992 initiator-name = "iqn.qemu.test:my-initiator"
993 header-digest = "CRC32C"
994 EOF
995
996 qemu-system-i386 -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
997 -readconfig iscsi.conf
998 @end example
999
1000
1001 Howto set up a simple iSCSI target on loopback and accessing it via QEMU:
1002 @example
1003 This example shows how to set up an iSCSI target with one CDROM and one DISK
1004 using the Linux STGT software target. This target is available on Red Hat based
1005 systems as the package 'scsi-target-utils'.
1006
1007 tgtd --iscsi portal=127.0.0.1:3260
1008 tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.qemu.test
1009 tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 \
1010 -b /IMAGES/disk.img --device-type=disk
1011 tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 2 \
1012 -b /IMAGES/cd.iso --device-type=cd
1013 tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
1014
1015 qemu-system-i386 -iscsi initiator-name=iqn.qemu.test:my-initiator \
1016 -boot d -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
1017 -cdrom iscsi://127.0.0.1/iqn.qemu.test/2
1018 @end example
1019
1020 @node disk_images_gluster
1021 @subsection GlusterFS disk images
1022
1023 GlusterFS is an user space distributed file system.
1024
1025 You can boot from the GlusterFS disk image with the command:
1026 @example
1027 qemu-system-x86_64 -drive file=gluster[+@var{transport}]://[@var{server}[:@var{port}]]/@var{volname}/@var{image}[?socket=...]
1028 @end example
1029
1030 @var{gluster} is the protocol.
1031
1032 @var{transport} specifies the transport type used to connect to gluster
1033 management daemon (glusterd). Valid transport types are
1034 tcp, unix and rdma. If a transport type isn't specified, then tcp
1035 type is assumed.
1036
1037 @var{server} specifies the server where the volume file specification for
1038 the given volume resides. This can be either hostname, ipv4 address
1039 or ipv6 address. ipv6 address needs to be within square brackets [ ].
1040 If transport type is unix, then @var{server} field should not be specifed.
1041 Instead @var{socket} field needs to be populated with the path to unix domain
1042 socket.
1043
1044 @var{port} is the port number on which glusterd is listening. This is optional
1045 and if not specified, QEMU will send 0 which will make gluster to use the
1046 default port. If the transport type is unix, then @var{port} should not be
1047 specified.
1048
1049 @var{volname} is the name of the gluster volume which contains the disk image.
1050
1051 @var{image} is the path to the actual disk image that resides on gluster volume.
1052
1053 You can create a GlusterFS disk image with the command:
1054 @example
1055 qemu-img create gluster://@var{server}/@var{volname}/@var{image} @var{size}
1056 @end example
1057
1058 Examples
1059 @example
1060 qemu-system-x86_64 -drive file=gluster://1.2.3.4/testvol/a.img
1061 qemu-system-x86_64 -drive file=gluster+tcp://1.2.3.4/testvol/a.img
1062 qemu-system-x86_64 -drive file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
1063 qemu-system-x86_64 -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
1064 qemu-system-x86_64 -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
1065 qemu-system-x86_64 -drive file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
1066 qemu-system-x86_64 -drive file=gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket
1067 qemu-system-x86_64 -drive file=gluster+rdma://1.2.3.4:24007/testvol/a.img
1068 @end example
1069
1070 @node disk_images_ssh
1071 @subsection Secure Shell (ssh) disk images
1072
1073 You can access disk images located on a remote ssh server
1074 by using the ssh protocol:
1075
1076 @example
1077 qemu-system-x86_64 -drive file=ssh://[@var{user}@@]@var{server}[:@var{port}]/@var{path}[?host_key_check=@var{host_key_check}]
1078 @end example
1079
1080 Alternative syntax using properties:
1081
1082 @example
1083 qemu-system-x86_64 -drive file.driver=ssh[,file.user=@var{user}],file.host=@var{server}[,file.port=@var{port}],file.path=@var{path}[,file.host_key_check=@var{host_key_check}]
1084 @end example
1085
1086 @var{ssh} is the protocol.
1087
1088 @var{user} is the remote user. If not specified, then the local
1089 username is tried.
1090
1091 @var{server} specifies the remote ssh server. Any ssh server can be
1092 used, but it must implement the sftp-server protocol. Most Unix/Linux
1093 systems should work without requiring any extra configuration.
1094
1095 @var{port} is the port number on which sshd is listening. By default
1096 the standard ssh port (22) is used.
1097
1098 @var{path} is the path to the disk image.
1099
1100 The optional @var{host_key_check} parameter controls how the remote
1101 host's key is checked. The default is @code{yes} which means to use
1102 the local @file{.ssh/known_hosts} file. Setting this to @code{no}
1103 turns off known-hosts checking. Or you can check that the host key
1104 matches a specific fingerprint:
1105 @code{host_key_check=md5:78:45:8e:14:57:4f:d5:45:83:0a:0e:f3:49:82:c9:c8}
1106 (@code{sha1:} can also be used as a prefix, but note that OpenSSH
1107 tools only use MD5 to print fingerprints).
1108
1109 Currently authentication must be done using ssh-agent. Other
1110 authentication methods may be supported in future.
1111
1112 Note: Many ssh servers do not support an @code{fsync}-style operation.
1113 The ssh driver cannot guarantee that disk flush requests are
1114 obeyed, and this causes a risk of disk corruption if the remote
1115 server or network goes down during writes. The driver will
1116 print a warning when @code{fsync} is not supported:
1117
1118 warning: ssh server @code{ssh.example.com:22} does not support fsync
1119
1120 With sufficiently new versions of libssh2 and OpenSSH, @code{fsync} is
1121 supported.
1122
1123 @node pcsys_network
1124 @section Network emulation
1125
1126 QEMU can simulate several network cards (PCI or ISA cards on the PC
1127 target) and can connect them to an arbitrary number of Virtual Local
1128 Area Networks (VLANs). Host TAP devices can be connected to any QEMU
1129 VLAN. VLAN can be connected between separate instances of QEMU to
1130 simulate large networks. For simpler usage, a non privileged user mode
1131 network stack can replace the TAP device to have a basic network
1132 connection.
1133
1134 @subsection VLANs
1135
1136 QEMU simulates several VLANs. A VLAN can be symbolised as a virtual
1137 connection between several network devices. These devices can be for
1138 example QEMU virtual Ethernet cards or virtual Host ethernet devices
1139 (TAP devices).
1140
1141 @subsection Using TAP network interfaces
1142
1143 This is the standard way to connect QEMU to a real network. QEMU adds
1144 a virtual network device on your host (called @code{tapN}), and you
1145 can then configure it as if it was a real ethernet card.
1146
1147 @subsubsection Linux host
1148
1149 As an example, you can download the @file{linux-test-xxx.tar.gz}
1150 archive and copy the script @file{qemu-ifup} in @file{/etc} and
1151 configure properly @code{sudo} so that the command @code{ifconfig}
1152 contained in @file{qemu-ifup} can be executed as root. You must verify
1153 that your host kernel supports the TAP network interfaces: the
1154 device @file{/dev/net/tun} must be present.
1155
1156 See @ref{sec_invocation} to have examples of command lines using the
1157 TAP network interfaces.
1158
1159 @subsubsection Windows host
1160
1161 There is a virtual ethernet driver for Windows 2000/XP systems, called
1162 TAP-Win32. But it is not included in standard QEMU for Windows,
1163 so you will need to get it separately. It is part of OpenVPN package,
1164 so download OpenVPN from : @url{http://openvpn.net/}.
1165
1166 @subsection Using the user mode network stack
1167
1168 By using the option @option{-net user} (default configuration if no
1169 @option{-net} option is specified), QEMU uses a completely user mode
1170 network stack (you don't need root privilege to use the virtual
1171 network). The virtual network configuration is the following:
1172
1173 @example
1174
1175 QEMU VLAN <------> Firewall/DHCP server <-----> Internet
1176 | (10.0.2.2)
1177 |
1178 ----> DNS server (10.0.2.3)
1179 |
1180 ----> SMB server (10.0.2.4)
1181 @end example
1182
1183 The QEMU VM behaves as if it was behind a firewall which blocks all
1184 incoming connections. You can use a DHCP client to automatically
1185 configure the network in the QEMU VM. The DHCP server assign addresses
1186 to the hosts starting from 10.0.2.15.
1187
1188 In order to check that the user mode network is working, you can ping
1189 the address 10.0.2.2 and verify that you got an address in the range
1190 10.0.2.x from the QEMU virtual DHCP server.
1191
1192 Note that @code{ping} is not supported reliably to the internet as it
1193 would require root privileges. It means you can only ping the local
1194 router (10.0.2.2).
1195
1196 When using the built-in TFTP server, the router is also the TFTP
1197 server.
1198
1199 When using the @option{-redir} option, TCP or UDP connections can be
1200 redirected from the host to the guest. It allows for example to
1201 redirect X11, telnet or SSH connections.
1202
1203 @subsection Connecting VLANs between QEMU instances
1204
1205 Using the @option{-net socket} option, it is possible to make VLANs
1206 that span several QEMU instances. See @ref{sec_invocation} to have a
1207 basic example.
1208
1209 @node pcsys_other_devs
1210 @section Other Devices
1211
1212 @subsection Inter-VM Shared Memory device
1213
1214 With KVM enabled on a Linux host, a shared memory device is available. Guests
1215 map a POSIX shared memory region into the guest as a PCI device that enables
1216 zero-copy communication to the application level of the guests. The basic
1217 syntax is:
1218
1219 @example
1220 qemu-system-i386 -device ivshmem,size=<size in format accepted by -m>[,shm=<shm name>]
1221 @end example
1222
1223 If desired, interrupts can be sent between guest VMs accessing the same shared
1224 memory region. Interrupt support requires using a shared memory server and
1225 using a chardev socket to connect to it. The code for the shared memory server
1226 is qemu.git/contrib/ivshmem-server. An example syntax when using the shared
1227 memory server is:
1228
1229 @example
1230 qemu-system-i386 -device ivshmem,size=<size in format accepted by -m>[,chardev=<id>]
1231 [,msi=on][,ioeventfd=on][,vectors=n][,role=peer|master]
1232 qemu-system-i386 -chardev socket,path=<path>,id=<id>
1233 @end example
1234
1235 When using the server, the guest will be assigned a VM ID (>=0) that allows guests
1236 using the same server to communicate via interrupts. Guests can read their
1237 VM ID from a device register (see example code). Since receiving the shared
1238 memory region from the server is asynchronous, there is a (small) chance the
1239 guest may boot before the shared memory is attached. To allow an application
1240 to ensure shared memory is attached, the VM ID register will return -1 (an
1241 invalid VM ID) until the memory is attached. Once the shared memory is
1242 attached, the VM ID will return the guest's valid VM ID. With these semantics,
1243 the guest application can check to ensure the shared memory is attached to the
1244 guest before proceeding.
1245
1246 The @option{role} argument can be set to either master or peer and will affect
1247 how the shared memory is migrated. With @option{role=master}, the guest will
1248 copy the shared memory on migration to the destination host. With
1249 @option{role=peer}, the guest will not be able to migrate with the device attached.
1250 With the @option{peer} case, the device should be detached and then reattached
1251 after migration using the PCI hotplug support.
1252
1253 @node direct_linux_boot
1254 @section Direct Linux Boot
1255
1256 This section explains how to launch a Linux kernel inside QEMU without
1257 having to make a full bootable image. It is very useful for fast Linux
1258 kernel testing.
1259
1260 The syntax is:
1261 @example
1262 qemu-system-i386 -kernel arch/i386/boot/bzImage -hda root-2.4.20.img -append "root=/dev/hda"
1263 @end example
1264
1265 Use @option{-kernel} to provide the Linux kernel image and
1266 @option{-append} to give the kernel command line arguments. The
1267 @option{-initrd} option can be used to provide an INITRD image.
1268
1269 When using the direct Linux boot, a disk image for the first hard disk
1270 @file{hda} is required because its boot sector is used to launch the
1271 Linux kernel.
1272
1273 If you do not need graphical output, you can disable it and redirect
1274 the virtual serial port and the QEMU monitor to the console with the
1275 @option{-nographic} option. The typical command line is:
1276 @example
1277 qemu-system-i386 -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \
1278 -append "root=/dev/hda console=ttyS0" -nographic
1279 @end example
1280
1281 Use @key{Ctrl-a c} to switch between the serial console and the
1282 monitor (@pxref{pcsys_keys}).
1283
1284 @node pcsys_usb
1285 @section USB emulation
1286
1287 QEMU emulates a PCI UHCI USB controller. You can virtually plug
1288 virtual USB devices or real host USB devices (experimental, works only
1289 on Linux hosts). QEMU will automatically create and connect virtual USB hubs
1290 as necessary to connect multiple USB devices.
1291
1292 @menu
1293 * usb_devices::
1294 * host_usb_devices::
1295 @end menu
1296 @node usb_devices
1297 @subsection Connecting USB devices
1298
1299 USB devices can be connected with the @option{-usbdevice} commandline option
1300 or the @code{usb_add} monitor command. Available devices are:
1301
1302 @table @code
1303 @item mouse
1304 Virtual Mouse. This will override the PS/2 mouse emulation when activated.
1305 @item tablet
1306 Pointer device that uses absolute coordinates (like a touchscreen).
1307 This means QEMU is able to report the mouse position without having
1308 to grab the mouse. Also overrides the PS/2 mouse emulation when activated.
1309 @item disk:@var{file}
1310 Mass storage device based on @var{file} (@pxref{disk_images})
1311 @item host:@var{bus.addr}
1312 Pass through the host device identified by @var{bus.addr}
1313 (Linux only)
1314 @item host:@var{vendor_id:product_id}
1315 Pass through the host device identified by @var{vendor_id:product_id}
1316 (Linux only)
1317 @item wacom-tablet
1318 Virtual Wacom PenPartner tablet. This device is similar to the @code{tablet}
1319 above but it can be used with the tslib library because in addition to touch
1320 coordinates it reports touch pressure.
1321 @item keyboard
1322 Standard USB keyboard. Will override the PS/2 keyboard (if present).
1323 @item serial:[vendorid=@var{vendor_id}][,product_id=@var{product_id}]:@var{dev}
1324 Serial converter. This emulates an FTDI FT232BM chip connected to host character
1325 device @var{dev}. The available character devices are the same as for the
1326 @code{-serial} option. The @code{vendorid} and @code{productid} options can be
1327 used to override the default 0403:6001. For instance,
1328 @example
1329 usb_add serial:productid=FA00:tcp:192.168.0.2:4444
1330 @end example
1331 will connect to tcp port 4444 of ip 192.168.0.2, and plug that to the virtual
1332 serial converter, faking a Matrix Orbital LCD Display (USB ID 0403:FA00).
1333 @item braille
1334 Braille device. This will use BrlAPI to display the braille output on a real
1335 or fake device.
1336 @item net:@var{options}
1337 Network adapter that supports CDC ethernet and RNDIS protocols. @var{options}
1338 specifies NIC options as with @code{-net nic,}@var{options} (see description).
1339 For instance, user-mode networking can be used with
1340 @example
1341 qemu-system-i386 [...OPTIONS...] -net user,vlan=0 -usbdevice net:vlan=0
1342 @end example
1343 Currently this cannot be used in machines that support PCI NICs.
1344 @item bt[:@var{hci-type}]
1345 Bluetooth dongle whose type is specified in the same format as with
1346 the @option{-bt hci} option, @pxref{bt-hcis,,allowed HCI types}. If
1347 no type is given, the HCI logic corresponds to @code{-bt hci,vlan=0}.
1348 This USB device implements the USB Transport Layer of HCI. Example
1349 usage:
1350 @example
1351 qemu-system-i386 [...OPTIONS...] -usbdevice bt:hci,vlan=3 -bt device:keyboard,vlan=3
1352 @end example
1353 @end table
1354
1355 @node host_usb_devices
1356 @subsection Using host USB devices on a Linux host
1357
1358 WARNING: this is an experimental feature. QEMU will slow down when
1359 using it. USB devices requiring real time streaming (i.e. USB Video
1360 Cameras) are not supported yet.
1361
1362 @enumerate
1363 @item If you use an early Linux 2.4 kernel, verify that no Linux driver
1364 is actually using the USB device. A simple way to do that is simply to
1365 disable the corresponding kernel module by renaming it from @file{mydriver.o}
1366 to @file{mydriver.o.disabled}.
1367
1368 @item Verify that @file{/proc/bus/usb} is working (most Linux distributions should enable it by default). You should see something like that:
1369 @example
1370 ls /proc/bus/usb
1371 001 devices drivers
1372 @end example
1373
1374 @item Since only root can access to the USB devices directly, you can either launch QEMU as root or change the permissions of the USB devices you want to use. For testing, the following suffices:
1375 @example
1376 chown -R myuid /proc/bus/usb
1377 @end example
1378
1379 @item Launch QEMU and do in the monitor:
1380 @example
1381 info usbhost
1382 Device 1.2, speed 480 Mb/s
1383 Class 00: USB device 1234:5678, USB DISK
1384 @end example
1385 You should see the list of the devices you can use (Never try to use
1386 hubs, it won't work).
1387
1388 @item Add the device in QEMU by using:
1389 @example
1390 usb_add host:1234:5678
1391 @end example
1392
1393 Normally the guest OS should report that a new USB device is
1394 plugged. You can use the option @option{-usbdevice} to do the same.
1395
1396 @item Now you can try to use the host USB device in QEMU.
1397
1398 @end enumerate
1399
1400 When relaunching QEMU, you may have to unplug and plug again the USB
1401 device to make it work again (this is a bug).
1402
1403 @node vnc_security
1404 @section VNC security
1405
1406 The VNC server capability provides access to the graphical console
1407 of the guest VM across the network. This has a number of security
1408 considerations depending on the deployment scenarios.
1409
1410 @menu
1411 * vnc_sec_none::
1412 * vnc_sec_password::
1413 * vnc_sec_certificate::
1414 * vnc_sec_certificate_verify::
1415 * vnc_sec_certificate_pw::
1416 * vnc_sec_sasl::
1417 * vnc_sec_certificate_sasl::
1418 * vnc_generate_cert::
1419 * vnc_setup_sasl::
1420 @end menu
1421 @node vnc_sec_none
1422 @subsection Without passwords
1423
1424 The simplest VNC server setup does not include any form of authentication.
1425 For this setup it is recommended to restrict it to listen on a UNIX domain
1426 socket only. For example
1427
1428 @example
1429 qemu-system-i386 [...OPTIONS...] -vnc unix:/home/joebloggs/.qemu-myvm-vnc
1430 @end example
1431
1432 This ensures that only users on local box with read/write access to that
1433 path can access the VNC server. To securely access the VNC server from a
1434 remote machine, a combination of netcat+ssh can be used to provide a secure
1435 tunnel.
1436
1437 @node vnc_sec_password
1438 @subsection With passwords
1439
1440 The VNC protocol has limited support for password based authentication. Since
1441 the protocol limits passwords to 8 characters it should not be considered
1442 to provide high security. The password can be fairly easily brute-forced by
1443 a client making repeat connections. For this reason, a VNC server using password
1444 authentication should be restricted to only listen on the loopback interface
1445 or UNIX domain sockets. Password authentication is not supported when operating
1446 in FIPS 140-2 compliance mode as it requires the use of the DES cipher. Password
1447 authentication is requested with the @code{password} option, and then once QEMU
1448 is running the password is set with the monitor. Until the monitor is used to
1449 set the password all clients will be rejected.
1450
1451 @example
1452 qemu-system-i386 [...OPTIONS...] -vnc :1,password -monitor stdio
1453 (qemu) change vnc password
1454 Password: ********
1455 (qemu)
1456 @end example
1457
1458 @node vnc_sec_certificate
1459 @subsection With x509 certificates
1460
1461 The QEMU VNC server also implements the VeNCrypt extension allowing use of
1462 TLS for encryption of the session, and x509 certificates for authentication.
1463 The use of x509 certificates is strongly recommended, because TLS on its
1464 own is susceptible to man-in-the-middle attacks. Basic x509 certificate
1465 support provides a secure session, but no authentication. This allows any
1466 client to connect, and provides an encrypted session.
1467
1468 @example
1469 qemu-system-i386 [...OPTIONS...] -vnc :1,tls,x509=/etc/pki/qemu -monitor stdio
1470 @end example
1471
1472 In the above example @code{/etc/pki/qemu} should contain at least three files,
1473 @code{ca-cert.pem}, @code{server-cert.pem} and @code{server-key.pem}. Unprivileged
1474 users will want to use a private directory, for example @code{$HOME/.pki/qemu}.
1475 NB the @code{server-key.pem} file should be protected with file mode 0600 to
1476 only be readable by the user owning it.
1477
1478 @node vnc_sec_certificate_verify
1479 @subsection With x509 certificates and client verification
1480
1481 Certificates can also provide a means to authenticate the client connecting.
1482 The server will request that the client provide a certificate, which it will
1483 then validate against the CA certificate. This is a good choice if deploying
1484 in an environment with a private internal certificate authority.
1485
1486 @example
1487 qemu-system-i386 [...OPTIONS...] -vnc :1,tls,x509verify=/etc/pki/qemu -monitor stdio
1488 @end example
1489
1490
1491 @node vnc_sec_certificate_pw
1492 @subsection With x509 certificates, client verification and passwords
1493
1494 Finally, the previous method can be combined with VNC password authentication
1495 to provide two layers of authentication for clients.
1496
1497 @example
1498 qemu-system-i386 [...OPTIONS...] -vnc :1,password,tls,x509verify=/etc/pki/qemu -monitor stdio
1499 (qemu) change vnc password
1500 Password: ********
1501 (qemu)
1502 @end example
1503
1504
1505 @node vnc_sec_sasl
1506 @subsection With SASL authentication
1507
1508 The SASL authentication method is a VNC extension, that provides an
1509 easily extendable, pluggable authentication method. This allows for
1510 integration with a wide range of authentication mechanisms, such as
1511 PAM, GSSAPI/Kerberos, LDAP, SQL databases, one-time keys and more.
1512 The strength of the authentication depends on the exact mechanism
1513 configured. If the chosen mechanism also provides a SSF layer, then
1514 it will encrypt the datastream as well.
1515
1516 Refer to the later docs on how to choose the exact SASL mechanism
1517 used for authentication, but assuming use of one supporting SSF,
1518 then QEMU can be launched with:
1519
1520 @example
1521 qemu-system-i386 [...OPTIONS...] -vnc :1,sasl -monitor stdio
1522 @end example
1523
1524 @node vnc_sec_certificate_sasl
1525 @subsection With x509 certificates and SASL authentication
1526
1527 If the desired SASL authentication mechanism does not supported
1528 SSF layers, then it is strongly advised to run it in combination
1529 with TLS and x509 certificates. This provides securely encrypted
1530 data stream, avoiding risk of compromising of the security
1531 credentials. This can be enabled, by combining the 'sasl' option
1532 with the aforementioned TLS + x509 options:
1533
1534 @example
1535 qemu-system-i386 [...OPTIONS...] -vnc :1,tls,x509,sasl -monitor stdio
1536 @end example
1537
1538
1539 @node vnc_generate_cert
1540 @subsection Generating certificates for VNC
1541
1542 The GNU TLS packages provides a command called @code{certtool} which can
1543 be used to generate certificates and keys in PEM format. At a minimum it
1544 is necessary to setup a certificate authority, and issue certificates to
1545 each server. If using certificates for authentication, then each client
1546 will also need to be issued a certificate. The recommendation is for the
1547 server to keep its certificates in either @code{/etc/pki/qemu} or for
1548 unprivileged users in @code{$HOME/.pki/qemu}.
1549
1550 @menu
1551 * vnc_generate_ca::
1552 * vnc_generate_server::
1553 * vnc_generate_client::
1554 @end menu
1555 @node vnc_generate_ca
1556 @subsubsection Setup the Certificate Authority
1557
1558 This step only needs to be performed once per organization / organizational
1559 unit. First the CA needs a private key. This key must be kept VERY secret
1560 and secure. If this key is compromised the entire trust chain of the certificates
1561 issued with it is lost.
1562
1563 @example
1564 # certtool --generate-privkey > ca-key.pem
1565 @end example
1566
1567 A CA needs to have a public certificate. For simplicity it can be a self-signed
1568 certificate, or one issue by a commercial certificate issuing authority. To
1569 generate a self-signed certificate requires one core piece of information, the
1570 name of the organization.
1571
1572 @example
1573 # cat > ca.info <<EOF
1574 cn = Name of your organization
1575 ca
1576 cert_signing_key
1577 EOF
1578 # certtool --generate-self-signed \
1579 --load-privkey ca-key.pem
1580 --template ca.info \
1581 --outfile ca-cert.pem
1582 @end example
1583
1584 The @code{ca-cert.pem} file should be copied to all servers and clients wishing to utilize
1585 TLS support in the VNC server. The @code{ca-key.pem} must not be disclosed/copied at all.
1586
1587 @node vnc_generate_server
1588 @subsubsection Issuing server certificates
1589
1590 Each server (or host) needs to be issued with a key and certificate. When connecting
1591 the certificate is sent to the client which validates it against the CA certificate.
1592 The core piece of information for a server certificate is the hostname. This should
1593 be the fully qualified hostname that the client will connect with, since the client
1594 will typically also verify the hostname in the certificate. On the host holding the
1595 secure CA private key:
1596
1597 @example
1598 # cat > server.info <<EOF
1599 organization = Name of your organization
1600 cn = server.foo.example.com
1601 tls_www_server
1602 encryption_key
1603 signing_key
1604 EOF
1605 # certtool --generate-privkey > server-key.pem
1606 # certtool --generate-certificate \
1607 --load-ca-certificate ca-cert.pem \
1608 --load-ca-privkey ca-key.pem \
1609 --load-privkey server server-key.pem \
1610 --template server.info \
1611 --outfile server-cert.pem
1612 @end example
1613
1614 The @code{server-key.pem} and @code{server-cert.pem} files should now be securely copied
1615 to the server for which they were generated. The @code{server-key.pem} is security
1616 sensitive and should be kept protected with file mode 0600 to prevent disclosure.
1617
1618 @node vnc_generate_client
1619 @subsubsection Issuing client certificates
1620
1621 If the QEMU VNC server is to use the @code{x509verify} option to validate client
1622 certificates as its authentication mechanism, each client also needs to be issued
1623 a certificate. The client certificate contains enough metadata to uniquely identify
1624 the client, typically organization, state, city, building, etc. On the host holding
1625 the secure CA private key:
1626
1627 @example
1628 # cat > client.info <<EOF
1629 country = GB
1630 state = London
1631 locality = London
1632 organiazation = Name of your organization
1633 cn = client.foo.example.com
1634 tls_www_client
1635 encryption_key
1636 signing_key
1637 EOF
1638 # certtool --generate-privkey > client-key.pem
1639 # certtool --generate-certificate \
1640 --load-ca-certificate ca-cert.pem \
1641 --load-ca-privkey ca-key.pem \
1642 --load-privkey client-key.pem \
1643 --template client.info \
1644 --outfile client-cert.pem
1645 @end example
1646
1647 The @code{client-key.pem} and @code{client-cert.pem} files should now be securely
1648 copied to the client for which they were generated.
1649
1650
1651 @node vnc_setup_sasl
1652
1653 @subsection Configuring SASL mechanisms
1654
1655 The following documentation assumes use of the Cyrus SASL implementation on a
1656 Linux host, but the principals should apply to any other SASL impl. When SASL
1657 is enabled, the mechanism configuration will be loaded from system default
1658 SASL service config /etc/sasl2/qemu.conf. If running QEMU as an
1659 unprivileged user, an environment variable SASL_CONF_PATH can be used
1660 to make it search alternate locations for the service config.
1661
1662 The default configuration might contain
1663
1664 @example
1665 mech_list: digest-md5
1666 sasldb_path: /etc/qemu/passwd.db
1667 @end example
1668
1669 This says to use the 'Digest MD5' mechanism, which is similar to the HTTP
1670 Digest-MD5 mechanism. The list of valid usernames & passwords is maintained
1671 in the /etc/qemu/passwd.db file, and can be updated using the saslpasswd2
1672 command. While this mechanism is easy to configure and use, it is not
1673 considered secure by modern standards, so only suitable for developers /
1674 ad-hoc testing.
1675
1676 A more serious deployment might use Kerberos, which is done with the 'gssapi'
1677 mechanism
1678
1679 @example
1680 mech_list: gssapi
1681 keytab: /etc/qemu/krb5.tab
1682 @end example
1683
1684 For this to work the administrator of your KDC must generate a Kerberos
1685 principal for the server, with a name of 'qemu/somehost.example.com@@EXAMPLE.COM'
1686 replacing 'somehost.example.com' with the fully qualified host name of the
1687 machine running QEMU, and 'EXAMPLE.COM' with the Kerberos Realm.
1688
1689 Other configurations will be left as an exercise for the reader. It should
1690 be noted that only Digest-MD5 and GSSAPI provides a SSF layer for data
1691 encryption. For all other mechanisms, VNC should always be configured to
1692 use TLS and x509 certificates to protect security credentials from snooping.
1693
1694 @node gdb_usage
1695 @section GDB usage
1696
1697 QEMU has a primitive support to work with gdb, so that you can do
1698 'Ctrl-C' while the virtual machine is running and inspect its state.
1699
1700 In order to use gdb, launch QEMU with the '-s' option. It will wait for a
1701 gdb connection:
1702 @example
1703 qemu-system-i386 -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \
1704 -append "root=/dev/hda"
1705 Connected to host network interface: tun0
1706 Waiting gdb connection on port 1234
1707 @end example
1708
1709 Then launch gdb on the 'vmlinux' executable:
1710 @example
1711 > gdb vmlinux
1712 @end example
1713
1714 In gdb, connect to QEMU:
1715 @example
1716 (gdb) target remote localhost:1234
1717 @end example
1718
1719 Then you can use gdb normally. For example, type 'c' to launch the kernel:
1720 @example
1721 (gdb) c
1722 @end example
1723
1724 Here are some useful tips in order to use gdb on system code:
1725
1726 @enumerate
1727 @item
1728 Use @code{info reg} to display all the CPU registers.
1729 @item
1730 Use @code{x/10i $eip} to display the code at the PC position.
1731 @item
1732 Use @code{set architecture i8086} to dump 16 bit code. Then use
1733 @code{x/10i $cs*16+$eip} to dump the code at the PC position.
1734 @end enumerate
1735
1736 Advanced debugging options:
1737
1738 The default single stepping behavior is step with the IRQs and timer service routines off. It is set this way because when gdb executes a single step it expects to advance beyond the current instruction. With the IRQs and and timer service routines on, a single step might jump into the one of the interrupt or exception vectors instead of executing the current instruction. This means you may hit the same breakpoint a number of times before executing the instruction gdb wants to have executed. Because there are rare circumstances where you want to single step into an interrupt vector the behavior can be controlled from GDB. There are three commands you can query and set the single step behavior:
1739 @table @code
1740 @item maintenance packet qqemu.sstepbits
1741
1742 This will display the MASK bits used to control the single stepping IE:
1743 @example
1744 (gdb) maintenance packet qqemu.sstepbits
1745 sending: "qqemu.sstepbits"
1746 received: "ENABLE=1,NOIRQ=2,NOTIMER=4"
1747 @end example
1748 @item maintenance packet qqemu.sstep
1749
1750 This will display the current value of the mask used when single stepping IE:
1751 @example
1752 (gdb) maintenance packet qqemu.sstep
1753 sending: "qqemu.sstep"
1754 received: "0x7"
1755 @end example
1756 @item maintenance packet Qqemu.sstep=HEX_VALUE
1757
1758 This will change the single step mask, so if wanted to enable IRQs on the single step, but not timers, you would use:
1759 @example
1760 (gdb) maintenance packet Qqemu.sstep=0x5
1761 sending: "qemu.sstep=0x5"
1762 received: "OK"
1763 @end example
1764 @end table
1765
1766 @node pcsys_os_specific
1767 @section Target OS specific information
1768
1769 @subsection Linux
1770
1771 To have access to SVGA graphic modes under X11, use the @code{vesa} or
1772 the @code{cirrus} X11 driver. For optimal performances, use 16 bit
1773 color depth in the guest and the host OS.
1774
1775 When using a 2.6 guest Linux kernel, you should add the option
1776 @code{clock=pit} on the kernel command line because the 2.6 Linux
1777 kernels make very strict real time clock checks by default that QEMU
1778 cannot simulate exactly.
1779
1780 When using a 2.6 guest Linux kernel, verify that the 4G/4G patch is
1781 not activated because QEMU is slower with this patch. The QEMU
1782 Accelerator Module is also much slower in this case. Earlier Fedora
1783 Core 3 Linux kernel (< 2.6.9-1.724_FC3) were known to incorporate this
1784 patch by default. Newer kernels don't have it.
1785
1786 @subsection Windows
1787
1788 If you have a slow host, using Windows 95 is better as it gives the
1789 best speed. Windows 2000 is also a good choice.
1790
1791 @subsubsection SVGA graphic modes support
1792
1793 QEMU emulates a Cirrus Logic GD5446 Video
1794 card. All Windows versions starting from Windows 95 should recognize
1795 and use this graphic card. For optimal performances, use 16 bit color
1796 depth in the guest and the host OS.
1797
1798 If you are using Windows XP as guest OS and if you want to use high
1799 resolution modes which the Cirrus Logic BIOS does not support (i.e. >=
1800 1280x1024x16), then you should use the VESA VBE virtual graphic card
1801 (option @option{-std-vga}).
1802
1803 @subsubsection CPU usage reduction
1804
1805 Windows 9x does not correctly use the CPU HLT
1806 instruction. The result is that it takes host CPU cycles even when
1807 idle. You can install the utility from
1808 @url{http://www.user.cityline.ru/~maxamn/amnhltm.zip} to solve this
1809 problem. Note that no such tool is needed for NT, 2000 or XP.
1810
1811 @subsubsection Windows 2000 disk full problem
1812
1813 Windows 2000 has a bug which gives a disk full problem during its
1814 installation. When installing it, use the @option{-win2k-hack} QEMU
1815 option to enable a specific workaround. After Windows 2000 is
1816 installed, you no longer need this option (this option slows down the
1817 IDE transfers).
1818
1819 @subsubsection Windows 2000 shutdown
1820
1821 Windows 2000 cannot automatically shutdown in QEMU although Windows 98
1822 can. It comes from the fact that Windows 2000 does not automatically
1823 use the APM driver provided by the BIOS.
1824
1825 In order to correct that, do the following (thanks to Struan
1826 Bartlett): go to the Control Panel => Add/Remove Hardware & Next =>
1827 Add/Troubleshoot a device => Add a new device & Next => No, select the
1828 hardware from a list & Next => NT Apm/Legacy Support & Next => Next
1829 (again) a few times. Now the driver is installed and Windows 2000 now
1830 correctly instructs QEMU to shutdown at the appropriate moment.
1831
1832 @subsubsection Share a directory between Unix and Windows
1833
1834 See @ref{sec_invocation} about the help of the option @option{-smb}.
1835
1836 @subsubsection Windows XP security problem
1837
1838 Some releases of Windows XP install correctly but give a security
1839 error when booting:
1840 @example
1841 A problem is preventing Windows from accurately checking the
1842 license for this computer. Error code: 0x800703e6.
1843 @end example
1844
1845 The workaround is to install a service pack for XP after a boot in safe
1846 mode. Then reboot, and the problem should go away. Since there is no
1847 network while in safe mode, its recommended to download the full
1848 installation of SP1 or SP2 and transfer that via an ISO or using the
1849 vvfat block device ("-hdb fat:directory_which_holds_the_SP").
1850
1851 @subsection MS-DOS and FreeDOS
1852
1853 @subsubsection CPU usage reduction
1854
1855 DOS does not correctly use the CPU HLT instruction. The result is that
1856 it takes host CPU cycles even when idle. You can install the utility
1857 from @url{http://www.vmware.com/software/dosidle210.zip} to solve this
1858 problem.
1859
1860 @node QEMU System emulator for non PC targets
1861 @chapter QEMU System emulator for non PC targets
1862
1863 QEMU is a generic emulator and it emulates many non PC
1864 machines. Most of the options are similar to the PC emulator. The
1865 differences are mentioned in the following sections.
1866
1867 @menu
1868 * PowerPC System emulator::
1869 * Sparc32 System emulator::
1870 * Sparc64 System emulator::
1871 * MIPS System emulator::
1872 * ARM System emulator::
1873 * ColdFire System emulator::
1874 * Cris System emulator::
1875 * Microblaze System emulator::
1876 * SH4 System emulator::
1877 * Xtensa System emulator::
1878 @end menu
1879
1880 @node PowerPC System emulator
1881 @section PowerPC System emulator
1882 @cindex system emulation (PowerPC)
1883
1884 Use the executable @file{qemu-system-ppc} to simulate a complete PREP
1885 or PowerMac PowerPC system.
1886
1887 QEMU emulates the following PowerMac peripherals:
1888
1889 @itemize @minus
1890 @item
1891 UniNorth or Grackle PCI Bridge
1892 @item
1893 PCI VGA compatible card with VESA Bochs Extensions
1894 @item
1895 2 PMAC IDE interfaces with hard disk and CD-ROM support
1896 @item
1897 NE2000 PCI adapters
1898 @item
1899 Non Volatile RAM
1900 @item
1901 VIA-CUDA with ADB keyboard and mouse.
1902 @end itemize
1903
1904 QEMU emulates the following PREP peripherals:
1905
1906 @itemize @minus
1907 @item
1908 PCI Bridge
1909 @item
1910 PCI VGA compatible card with VESA Bochs Extensions
1911 @item
1912 2 IDE interfaces with hard disk and CD-ROM support
1913 @item
1914 Floppy disk
1915 @item
1916 NE2000 network adapters
1917 @item
1918 Serial port
1919 @item
1920 PREP Non Volatile RAM
1921 @item
1922 PC compatible keyboard and mouse.
1923 @end itemize
1924
1925 QEMU uses the Open Hack'Ware Open Firmware Compatible BIOS available at
1926 @url{http://perso.magic.fr/l_indien/OpenHackWare/index.htm}.
1927
1928 Since version 0.9.1, QEMU uses OpenBIOS @url{http://www.openbios.org/}
1929 for the g3beige and mac99 PowerMac machines. OpenBIOS is a free (GPL
1930 v2) portable firmware implementation. The goal is to implement a 100%
1931 IEEE 1275-1994 (referred to as Open Firmware) compliant firmware.
1932
1933 @c man begin OPTIONS
1934
1935 The following options are specific to the PowerPC emulation:
1936
1937 @table @option
1938
1939 @item -g @var{W}x@var{H}[x@var{DEPTH}]
1940
1941 Set the initial VGA graphic mode. The default is 800x600x15.
1942
1943 @item -prom-env @var{string}
1944
1945 Set OpenBIOS variables in NVRAM, for example:
1946
1947 @example
1948 qemu-system-ppc -prom-env 'auto-boot?=false' \
1949 -prom-env 'boot-device=hd:2,\yaboot' \
1950 -prom-env 'boot-args=conf=hd:2,\yaboot.conf'
1951 @end example
1952
1953 These variables are not used by Open Hack'Ware.
1954
1955 @end table
1956
1957 @c man end
1958
1959
1960 More information is available at
1961 @url{http://perso.magic.fr/l_indien/qemu-ppc/}.
1962
1963 @node Sparc32 System emulator
1964 @section Sparc32 System emulator
1965 @cindex system emulation (Sparc32)
1966
1967 Use the executable @file{qemu-system-sparc} to simulate the following
1968 Sun4m architecture machines:
1969 @itemize @minus
1970 @item
1971 SPARCstation 4
1972 @item
1973 SPARCstation 5
1974 @item
1975 SPARCstation 10
1976 @item
1977 SPARCstation 20
1978 @item
1979 SPARCserver 600MP
1980 @item
1981 SPARCstation LX
1982 @item
1983 SPARCstation Voyager
1984 @item
1985 SPARCclassic
1986 @item
1987 SPARCbook
1988 @end itemize
1989
1990 The emulation is somewhat complete. SMP up to 16 CPUs is supported,
1991 but Linux limits the number of usable CPUs to 4.
1992
1993 QEMU emulates the following sun4m peripherals:
1994
1995 @itemize @minus
1996 @item
1997 IOMMU
1998 @item
1999 TCX Frame buffer
2000 @item
2001 Lance (Am7990) Ethernet
2002 @item
2003 Non Volatile RAM M48T02/M48T08
2004 @item
2005 Slave I/O: timers, interrupt controllers, Zilog serial ports, keyboard
2006 and power/reset logic
2007 @item
2008 ESP SCSI controller with hard disk and CD-ROM support
2009 @item
2010 Floppy drive (not on SS-600MP)
2011 @item
2012 CS4231 sound device (only on SS-5, not working yet)
2013 @end itemize
2014
2015 The number of peripherals is fixed in the architecture. Maximum
2016 memory size depends on the machine type, for SS-5 it is 256MB and for
2017 others 2047MB.
2018
2019 Since version 0.8.2, QEMU uses OpenBIOS
2020 @url{http://www.openbios.org/}. OpenBIOS is a free (GPL v2) portable
2021 firmware implementation. The goal is to implement a 100% IEEE
2022 1275-1994 (referred to as Open Firmware) compliant firmware.
2023
2024 A sample Linux 2.6 series kernel and ram disk image are available on
2025 the QEMU web site. There are still issues with NetBSD and OpenBSD, but
2026 some kernel versions work. Please note that currently Solaris kernels
2027 don't work probably due to interface issues between OpenBIOS and
2028 Solaris.
2029
2030 @c man begin OPTIONS
2031
2032 The following options are specific to the Sparc32 emulation:
2033
2034 @table @option
2035
2036 @item -g @var{W}x@var{H}x[x@var{DEPTH}]
2037
2038 Set the initial TCX graphic mode. The default is 1024x768x8, currently
2039 the only other possible mode is 1024x768x24.
2040
2041 @item -prom-env @var{string}
2042
2043 Set OpenBIOS variables in NVRAM, for example:
2044
2045 @example
2046 qemu-system-sparc -prom-env 'auto-boot?=false' \
2047 -prom-env 'boot-device=sd(0,2,0):d' -prom-env 'boot-args=linux single'
2048 @end example
2049
2050 @item -M [SS-4|SS-5|SS-10|SS-20|SS-600MP|LX|Voyager|SPARCClassic] [|SPARCbook]
2051
2052 Set the emulated machine type. Default is SS-5.
2053
2054 @end table
2055
2056 @c man end
2057
2058 @node Sparc64 System emulator
2059 @section Sparc64 System emulator
2060 @cindex system emulation (Sparc64)
2061
2062 Use the executable @file{qemu-system-sparc64} to simulate a Sun4u
2063 (UltraSPARC PC-like machine), Sun4v (T1 PC-like machine), or generic
2064 Niagara (T1) machine. The emulator is not usable for anything yet, but
2065 it can launch some kernels.
2066
2067 QEMU emulates the following peripherals:
2068
2069 @itemize @minus
2070 @item
2071 UltraSparc IIi APB PCI Bridge
2072 @item
2073 PCI VGA compatible card with VESA Bochs Extensions
2074 @item
2075 PS/2 mouse and keyboard
2076 @item
2077 Non Volatile RAM M48T59
2078 @item
2079 PC-compatible serial ports
2080 @item
2081 2 PCI IDE interfaces with hard disk and CD-ROM support
2082 @item
2083 Floppy disk
2084 @end itemize
2085
2086 @c man begin OPTIONS
2087
2088 The following options are specific to the Sparc64 emulation:
2089
2090 @table @option
2091
2092 @item -prom-env @var{string}
2093
2094 Set OpenBIOS variables in NVRAM, for example:
2095
2096 @example
2097 qemu-system-sparc64 -prom-env 'auto-boot?=false'
2098 @end example
2099
2100 @item -M [sun4u|sun4v|Niagara]
2101
2102 Set the emulated machine type. The default is sun4u.
2103
2104 @end table
2105
2106 @c man end
2107
2108 @node MIPS System emulator
2109 @section MIPS System emulator
2110 @cindex system emulation (MIPS)
2111
2112 Four executables cover simulation of 32 and 64-bit MIPS systems in
2113 both endian options, @file{qemu-system-mips}, @file{qemu-system-mipsel}
2114 @file{qemu-system-mips64} and @file{qemu-system-mips64el}.
2115 Five different machine types are emulated:
2116
2117 @itemize @minus
2118 @item
2119 A generic ISA PC-like machine "mips"
2120 @item
2121 The MIPS Malta prototype board "malta"
2122 @item
2123 An ACER Pica "pica61". This machine needs the 64-bit emulator.
2124 @item
2125 MIPS emulator pseudo board "mipssim"
2126 @item
2127 A MIPS Magnum R4000 machine "magnum". This machine needs the 64-bit emulator.
2128 @end itemize
2129
2130 The generic emulation is supported by Debian 'Etch' and is able to
2131 install Debian into a virtual disk image. The following devices are
2132 emulated:
2133
2134 @itemize @minus
2135 @item
2136 A range of MIPS CPUs, default is the 24Kf
2137 @item
2138 PC style serial port
2139 @item
2140 PC style IDE disk
2141 @item
2142 NE2000 network card
2143 @end itemize
2144
2145 The Malta emulation supports the following devices:
2146
2147 @itemize @minus
2148 @item
2149 Core board with MIPS 24Kf CPU and Galileo system controller
2150 @item
2151 PIIX4 PCI/USB/SMbus controller
2152 @item
2153 The Multi-I/O chip's serial device
2154 @item
2155 PCI network cards (PCnet32 and others)
2156 @item
2157 Malta FPGA serial device
2158 @item
2159 Cirrus (default) or any other PCI VGA graphics card
2160 @end itemize
2161
2162 The ACER Pica emulation supports:
2163
2164 @itemize @minus
2165 @item
2166 MIPS R4000 CPU
2167 @item
2168 PC-style IRQ and DMA controllers
2169 @item
2170 PC Keyboard
2171 @item
2172 IDE controller
2173 @end itemize
2174
2175 The mipssim pseudo board emulation provides an environment similar
2176 to what the proprietary MIPS emulator uses for running Linux.
2177 It supports:
2178
2179 @itemize @minus
2180 @item
2181 A range of MIPS CPUs, default is the 24Kf
2182 @item
2183 PC style serial port
2184 @item
2185 MIPSnet network emulation
2186 @end itemize
2187
2188 The MIPS Magnum R4000 emulation supports:
2189
2190 @itemize @minus
2191 @item
2192 MIPS R4000 CPU
2193 @item
2194 PC-style IRQ controller
2195 @item
2196 PC Keyboard
2197 @item
2198 SCSI controller
2199 @item
2200 G364 framebuffer
2201 @end itemize
2202
2203
2204 @node ARM System emulator
2205 @section ARM System emulator
2206 @cindex system emulation (ARM)
2207
2208 Use the executable @file{qemu-system-arm} to simulate a ARM
2209 machine. The ARM Integrator/CP board is emulated with the following
2210 devices:
2211
2212 @itemize @minus
2213 @item
2214 ARM926E, ARM1026E, ARM946E, ARM1136 or Cortex-A8 CPU
2215 @item
2216 Two PL011 UARTs
2217 @item
2218 SMC 91c111 Ethernet adapter
2219 @item
2220 PL110 LCD controller
2221 @item
2222 PL050 KMI with PS/2 keyboard and mouse.
2223 @item
2224 PL181 MultiMedia Card Interface with SD card.
2225 @end itemize
2226
2227 The ARM Versatile baseboard is emulated with the following devices:
2228
2229 @itemize @minus
2230 @item
2231 ARM926E, ARM1136 or Cortex-A8 CPU
2232 @item
2233 PL190 Vectored Interrupt Controller
2234 @item
2235 Four PL011 UARTs
2236 @item
2237 SMC 91c111 Ethernet adapter
2238 @item
2239 PL110 LCD controller
2240 @item
2241 PL050 KMI with PS/2 keyboard and mouse.
2242 @item
2243 PCI host bridge. Note the emulated PCI bridge only provides access to
2244 PCI memory space. It does not provide access to PCI IO space.
2245 This means some devices (eg. ne2k_pci NIC) are not usable, and others
2246 (eg. rtl8139 NIC) are only usable when the guest drivers use the memory
2247 mapped control registers.
2248 @item
2249 PCI OHCI USB controller.
2250 @item
2251 LSI53C895A PCI SCSI Host Bus Adapter with hard disk and CD-ROM devices.
2252 @item
2253 PL181 MultiMedia Card Interface with SD card.
2254 @end itemize
2255
2256 Several variants of the ARM RealView baseboard are emulated,
2257 including the EB, PB-A8 and PBX-A9. Due to interactions with the
2258 bootloader, only certain Linux kernel configurations work out
2259 of the box on these boards.
2260
2261 Kernels for the PB-A8 board should have CONFIG_REALVIEW_HIGH_PHYS_OFFSET
2262 enabled in the kernel, and expect 512M RAM. Kernels for The PBX-A9 board
2263 should have CONFIG_SPARSEMEM enabled, CONFIG_REALVIEW_HIGH_PHYS_OFFSET
2264 disabled and expect 1024M RAM.
2265
2266 The following devices are emulated:
2267
2268 @itemize @minus
2269 @item
2270 ARM926E, ARM1136, ARM11MPCore, Cortex-A8 or Cortex-A9 MPCore CPU
2271 @item
2272 ARM AMBA Generic/Distributed Interrupt Controller
2273 @item
2274 Four PL011 UARTs
2275 @item
2276 SMC 91c111 or SMSC LAN9118 Ethernet adapter
2277 @item
2278 PL110 LCD controller
2279 @item
2280 PL050 KMI with PS/2 keyboard and mouse
2281 @item
2282 PCI host bridge
2283 @item
2284 PCI OHCI USB controller
2285 @item
2286 LSI53C895A PCI SCSI Host Bus Adapter with hard disk and CD-ROM devices
2287 @item
2288 PL181 MultiMedia Card Interface with SD card.
2289 @end itemize
2290
2291 The XScale-based clamshell PDA models ("Spitz", "Akita", "Borzoi"
2292 and "Terrier") emulation includes the following peripherals:
2293
2294 @itemize @minus
2295 @item
2296 Intel PXA270 System-on-chip (ARM V5TE core)
2297 @item
2298 NAND Flash memory
2299 @item
2300 IBM/Hitachi DSCM microdrive in a PXA PCMCIA slot - not in "Akita"
2301 @item
2302 On-chip OHCI USB controller
2303 @item
2304 On-chip LCD controller
2305 @item
2306 On-chip Real Time Clock
2307 @item
2308 TI ADS7846 touchscreen controller on SSP bus
2309 @item
2310 Maxim MAX1111 analog-digital converter on I@math{^2}C bus
2311 @item
2312 GPIO-connected keyboard controller and LEDs
2313 @item
2314 Secure Digital card connected to PXA MMC/SD host
2315 @item
2316 Three on-chip UARTs
2317 @item
2318 WM8750 audio CODEC on I@math{^2}C and I@math{^2}S busses
2319 @end itemize
2320
2321 The Palm Tungsten|E PDA (codename "Cheetah") emulation includes the
2322 following elements:
2323
2324 @itemize @minus
2325 @item
2326 Texas Instruments OMAP310 System-on-chip (ARM 925T core)
2327 @item
2328 ROM and RAM memories (ROM firmware image can be loaded with -option-rom)
2329 @item
2330 On-chip LCD controller
2331 @item
2332 On-chip Real Time Clock
2333 @item
2334 TI TSC2102i touchscreen controller / analog-digital converter / Audio
2335 CODEC, connected through MicroWire and I@math{^2}S busses
2336 @item
2337 GPIO-connected matrix keypad
2338 @item
2339 Secure Digital card connected to OMAP MMC/SD host
2340 @item
2341 Three on-chip UARTs
2342 @end itemize
2343
2344 Nokia N800 and N810 internet tablets (known also as RX-34 and RX-44 / 48)
2345 emulation supports the following elements:
2346
2347 @itemize @minus
2348 @item
2349 Texas Instruments OMAP2420 System-on-chip (ARM 1136 core)
2350 @item
2351 RAM and non-volatile OneNAND Flash memories
2352 @item
2353 Display connected to EPSON remote framebuffer chip and OMAP on-chip
2354 display controller and a LS041y3 MIPI DBI-C controller
2355 @item
2356 TI TSC2301 (in N800) and TI TSC2005 (in N810) touchscreen controllers
2357 driven through SPI bus
2358 @item
2359 National Semiconductor LM8323-controlled qwerty keyboard driven
2360 through I@math{^2}C bus
2361 @item
2362 Secure Digital card connected to OMAP MMC/SD host
2363 @item
2364 Three OMAP on-chip UARTs and on-chip STI debugging console
2365 @item
2366 A Bluetooth(R) transceiver and HCI connected to an UART
2367 @item
2368 Mentor Graphics "Inventra" dual-role USB controller embedded in a TI
2369 TUSB6010 chip - only USB host mode is supported
2370 @item
2371 TI TMP105 temperature sensor driven through I@math{^2}C bus
2372 @item
2373 TI TWL92230C power management companion with an RTC on I@math{^2}C bus
2374 @item
2375 Nokia RETU and TAHVO multi-purpose chips with an RTC, connected
2376 through CBUS
2377 @end itemize
2378
2379 The Luminary Micro Stellaris LM3S811EVB emulation includes the following
2380 devices:
2381
2382 @itemize @minus
2383 @item
2384 Cortex-M3 CPU core.
2385 @item
2386 64k Flash and 8k SRAM.
2387 @item
2388 Timers, UARTs, ADC and I@math{^2}C interface.
2389 @item
2390 OSRAM Pictiva 96x16 OLED with SSD0303 controller on I@math{^2}C bus.
2391 @end itemize
2392
2393 The Luminary Micro Stellaris LM3S6965EVB emulation includes the following
2394 devices:
2395
2396 @itemize @minus
2397 @item
2398 Cortex-M3 CPU core.
2399 @item
2400 256k Flash and 64k SRAM.
2401 @item
2402 Timers, UARTs, ADC, I@math{^2}C and SSI interfaces.
2403 @item
2404 OSRAM Pictiva 128x64 OLED with SSD0323 controller connected via SSI.
2405 @end itemize
2406
2407 The Freecom MusicPal internet radio emulation includes the following
2408 elements:
2409
2410 @itemize @minus
2411 @item
2412 Marvell MV88W8618 ARM core.
2413 @item
2414 32 MB RAM, 256 KB SRAM, 8 MB flash.
2415 @item
2416 Up to 2 16550 UARTs
2417 @item
2418 MV88W8xx8 Ethernet controller
2419 @item
2420 MV88W8618 audio controller, WM8750 CODEC and mixer
2421 @item
2422 128×64 display with brightness control
2423 @item
2424 2 buttons, 2 navigation wheels with button function
2425 @end itemize
2426
2427 The Siemens SX1 models v1 and v2 (default) basic emulation.
2428 The emulation includes the following elements:
2429
2430 @itemize @minus
2431 @item
2432 Texas Instruments OMAP310 System-on-chip (ARM 925T core)
2433 @item
2434 ROM and RAM memories (ROM firmware image can be loaded with -pflash)
2435 V1
2436 1 Flash of 16MB and 1 Flash of 8MB
2437 V2
2438 1 Flash of 32MB
2439 @item
2440 On-chip LCD controller
2441 @item
2442 On-chip Real Time Clock
2443 @item
2444 Secure Digital card connected to OMAP MMC/SD host
2445 @item
2446 Three on-chip UARTs
2447 @end itemize
2448
2449 A Linux 2.6 test image is available on the QEMU web site. More
2450 information is available in the QEMU mailing-list archive.
2451
2452 @c man begin OPTIONS
2453
2454 The following options are specific to the ARM emulation:
2455
2456 @table @option
2457
2458 @item -semihosting
2459 Enable semihosting syscall emulation.
2460
2461 On ARM this implements the "Angel" interface.
2462
2463 Note that this allows guest direct access to the host filesystem,
2464 so should only be used with trusted guest OS.
2465
2466 @end table
2467
2468 @node ColdFire System emulator
2469 @section ColdFire System emulator
2470 @cindex system emulation (ColdFire)
2471 @cindex system emulation (M68K)
2472
2473 Use the executable @file{qemu-system-m68k} to simulate a ColdFire machine.
2474 The emulator is able to boot a uClinux kernel.
2475
2476 The M5208EVB emulation includes the following devices:
2477
2478 @itemize @minus
2479 @item
2480 MCF5208 ColdFire V2 Microprocessor (ISA A+ with EMAC).
2481 @item
2482 Three Two on-chip UARTs.
2483 @item
2484 Fast Ethernet Controller (FEC)
2485 @end itemize
2486
2487 The AN5206 emulation includes the following devices:
2488
2489 @itemize @minus
2490 @item
2491 MCF5206 ColdFire V2 Microprocessor.
2492 @item
2493 Two on-chip UARTs.
2494 @end itemize
2495
2496 @c man begin OPTIONS
2497
2498 The following options are specific to the ColdFire emulation:
2499
2500 @table @option
2501
2502 @item -semihosting
2503 Enable semihosting syscall emulation.
2504
2505 On M68K this implements the "ColdFire GDB" interface used by libgloss.
2506
2507 Note that this allows guest direct access to the host filesystem,
2508 so should only be used with trusted guest OS.
2509
2510 @end table
2511
2512 @node Cris System emulator
2513 @section Cris System emulator
2514 @cindex system emulation (Cris)
2515
2516 TODO
2517
2518 @node Microblaze System emulator
2519 @section Microblaze System emulator
2520 @cindex system emulation (Microblaze)
2521
2522 TODO
2523
2524 @node SH4 System emulator
2525 @section SH4 System emulator
2526 @cindex system emulation (SH4)
2527
2528 TODO
2529
2530 @node Xtensa System emulator
2531 @section Xtensa System emulator
2532 @cindex system emulation (Xtensa)
2533
2534 Two executables cover simulation of both Xtensa endian options,
2535 @file{qemu-system-xtensa} and @file{qemu-system-xtensaeb}.
2536 Two different machine types are emulated:
2537
2538 @itemize @minus
2539 @item
2540 Xtensa emulator pseudo board "sim"
2541 @item
2542 Avnet LX60/LX110/LX200 board
2543 @end itemize
2544
2545 The sim pseudo board emulation provides an environment similar
2546 to one provided by the proprietary Tensilica ISS.
2547 It supports:
2548
2549 @itemize @minus
2550 @item
2551 A range of Xtensa CPUs, default is the DC232B
2552 @item
2553 Console and filesystem access via semihosting calls
2554 @end itemize
2555
2556 The Avnet LX60/LX110/LX200 emulation supports:
2557
2558 @itemize @minus
2559 @item
2560 A range of Xtensa CPUs, default is the DC232B
2561 @item
2562 16550 UART
2563 @item
2564 OpenCores 10/100 Mbps Ethernet MAC
2565 @end itemize
2566
2567 @c man begin OPTIONS
2568
2569 The following options are specific to the Xtensa emulation:
2570
2571 @table @option
2572
2573 @item -semihosting
2574 Enable semihosting syscall emulation.
2575
2576 Xtensa semihosting provides basic file IO calls, such as open/read/write/seek/select.
2577 Tensilica baremetal libc for ISS and linux platform "sim" use this interface.
2578
2579 Note that this allows guest direct access to the host filesystem,
2580 so should only be used with trusted guest OS.
2581
2582 @end table
2583 @node QEMU User space emulator
2584 @chapter QEMU User space emulator
2585
2586 @menu
2587 * Supported Operating Systems ::
2588 * Linux User space emulator::
2589 * BSD User space emulator ::
2590 @end menu
2591
2592 @node Supported Operating Systems
2593 @section Supported Operating Systems
2594
2595 The following OS are supported in user space emulation:
2596
2597 @itemize @minus
2598 @item
2599 Linux (referred as qemu-linux-user)
2600 @item
2601 BSD (referred as qemu-bsd-user)
2602 @end itemize
2603
2604 @node Linux User space emulator
2605 @section Linux User space emulator
2606
2607 @menu
2608 * Quick Start::
2609 * Wine launch::
2610 * Command line options::
2611 * Other binaries::
2612 @end menu
2613
2614 @node Quick Start
2615 @subsection Quick Start
2616
2617 In order to launch a Linux process, QEMU needs the process executable
2618 itself and all the target (x86) dynamic libraries used by it.
2619
2620 @itemize
2621
2622 @item On x86, you can just try to launch any process by using the native
2623 libraries:
2624
2625 @example
2626 qemu-i386 -L / /bin/ls
2627 @end example
2628
2629 @code{-L /} tells that the x86 dynamic linker must be searched with a
2630 @file{/} prefix.
2631
2632 @item Since QEMU is also a linux process, you can launch QEMU with
2633 QEMU (NOTE: you can only do that if you compiled QEMU from the sources):
2634
2635 @example
2636 qemu-i386 -L / qemu-i386 -L / /bin/ls
2637 @end example
2638
2639 @item On non x86 CPUs, you need first to download at least an x86 glibc
2640 (@file{qemu-runtime-i386-XXX-.tar.gz} on the QEMU web page). Ensure that
2641 @code{LD_LIBRARY_PATH} is not set:
2642
2643 @example
2644 unset LD_LIBRARY_PATH
2645 @end example
2646
2647 Then you can launch the precompiled @file{ls} x86 executable:
2648
2649 @example
2650 qemu-i386 tests/i386/ls
2651 @end example
2652 You can look at @file{scripts/qemu-binfmt-conf.sh} so that
2653 QEMU is automatically launched by the Linux kernel when you try to
2654 launch x86 executables. It requires the @code{binfmt_misc} module in the
2655 Linux kernel.
2656
2657 @item The x86 version of QEMU is also included. You can try weird things such as:
2658 @example
2659 qemu-i386 /usr/local/qemu-i386/bin/qemu-i386 \
2660 /usr/local/qemu-i386/bin/ls-i386
2661 @end example
2662
2663 @end itemize
2664
2665 @node Wine launch
2666 @subsection Wine launch
2667
2668 @itemize
2669
2670 @item Ensure that you have a working QEMU with the x86 glibc
2671 distribution (see previous section). In order to verify it, you must be
2672 able to do:
2673
2674 @example
2675 qemu-i386 /usr/local/qemu-i386/bin/ls-i386
2676 @end example
2677
2678 @item Download the binary x86 Wine install
2679 (@file{qemu-XXX-i386-wine.tar.gz} on the QEMU web page).
2680
2681 @item Configure Wine on your account. Look at the provided script
2682 @file{/usr/local/qemu-i386/@/bin/wine-conf.sh}. Your previous
2683 @code{$@{HOME@}/.wine} directory is saved to @code{$@{HOME@}/.wine.org}.
2684
2685 @item Then you can try the example @file{putty.exe}:
2686
2687 @example
2688 qemu-i386 /usr/local/qemu-i386/wine/bin/wine \
2689 /usr/local/qemu-i386/wine/c/Program\ Files/putty.exe
2690 @end example
2691
2692 @end itemize
2693
2694 @node Command line options
2695 @subsection Command line options
2696
2697 @example
2698 usage: qemu-i386 [-h] [-d] [-L path] [-s size] [-cpu model] [-g port] [-B offset] [-R size] program [arguments...]
2699 @end example
2700
2701 @table @option
2702 @item -h
2703 Print the help
2704 @item -L path
2705 Set the x86 elf interpreter prefix (default=/usr/local/qemu-i386)
2706 @item -s size
2707 Set the x86 stack size in bytes (default=524288)
2708 @item -cpu model
2709 Select CPU model (-cpu help for list and additional feature selection)
2710 @item -E @var{var}=@var{value}
2711 Set environment @var{var} to @var{value}.
2712 @item -U @var{var}
2713 Remove @var{var} from the environment.
2714 @item -B offset
2715 Offset guest address by the specified number of bytes. This is useful when
2716 the address region required by guest applications is reserved on the host.
2717 This option is currently only supported on some hosts.
2718 @item -R size
2719 Pre-allocate a guest virtual address space of the given size (in bytes).
2720 "G", "M", and "k" suffixes may be used when specifying the size.
2721 @end table
2722
2723 Debug options:
2724
2725 @table @option
2726 @item -d item1,...
2727 Activate logging of the specified items (use '-d help' for a list of log items)
2728 @item -p pagesize
2729 Act as if the host page size was 'pagesize' bytes
2730 @item -g port
2731 Wait gdb connection to port
2732 @item -singlestep
2733 Run the emulation in single step mode.
2734 @end table
2735
2736 Environment variables:
2737
2738 @table @env
2739 @item QEMU_STRACE
2740 Print system calls and arguments similar to the 'strace' program
2741 (NOTE: the actual 'strace' program will not work because the user
2742 space emulator hasn't implemented ptrace). At the moment this is
2743 incomplete. All system calls that don't have a specific argument
2744 format are printed with information for six arguments. Many
2745 flag-style arguments don't have decoders and will show up as numbers.
2746 @end table
2747
2748 @node Other binaries
2749 @subsection Other binaries
2750
2751 @cindex user mode (Alpha)
2752 @command{qemu-alpha} TODO.
2753
2754 @cindex user mode (ARM)
2755 @command{qemu-armeb} TODO.
2756
2757 @cindex user mode (ARM)
2758 @command{qemu-arm} is also capable of running ARM "Angel" semihosted ELF
2759 binaries (as implemented by the arm-elf and arm-eabi Newlib/GDB
2760 configurations), and arm-uclinux bFLT format binaries.
2761
2762 @cindex user mode (ColdFire)
2763 @cindex user mode (M68K)
2764 @command{qemu-m68k} is capable of running semihosted binaries using the BDM
2765 (m5xxx-ram-hosted.ld) or m68k-sim (sim.ld) syscall interfaces, and
2766 coldfire uClinux bFLT format binaries.
2767
2768 The binary format is detected automatically.
2769
2770 @cindex user mode (Cris)
2771 @command{qemu-cris} TODO.
2772
2773 @cindex user mode (i386)
2774 @command{qemu-i386} TODO.
2775 @command{qemu-x86_64} TODO.
2776
2777 @cindex user mode (Microblaze)
2778 @command{qemu-microblaze} TODO.
2779
2780 @cindex user mode (MIPS)
2781 @command{qemu-mips} TODO.
2782 @command{qemu-mipsel} TODO.
2783
2784 @cindex user mode (PowerPC)
2785 @command{qemu-ppc64abi32} TODO.
2786 @command{qemu-ppc64} TODO.
2787 @command{qemu-ppc} TODO.
2788
2789 @cindex user mode (SH4)
2790 @command{qemu-sh4eb} TODO.
2791 @command{qemu-sh4} TODO.
2792
2793 @cindex user mode (SPARC)
2794 @command{qemu-sparc} can execute Sparc32 binaries (Sparc32 CPU, 32 bit ABI).
2795
2796 @command{qemu-sparc32plus} can execute Sparc32 and SPARC32PLUS binaries
2797 (Sparc64 CPU, 32 bit ABI).
2798
2799 @command{qemu-sparc64} can execute some Sparc64 (Sparc64 CPU, 64 bit ABI) and
2800 SPARC32PLUS binaries (Sparc64 CPU, 32 bit ABI).
2801
2802 @node BSD User space emulator
2803 @section BSD User space emulator
2804
2805 @menu
2806 * BSD Status::
2807 * BSD Quick Start::
2808 * BSD Command line options::
2809 @end menu
2810
2811 @node BSD Status
2812 @subsection BSD Status
2813
2814 @itemize @minus
2815 @item
2816 target Sparc64 on Sparc64: Some trivial programs work.
2817 @end itemize
2818
2819 @node BSD Quick Start
2820 @subsection Quick Start
2821
2822 In order to launch a BSD process, QEMU needs the process executable
2823 itself and all the target dynamic libraries used by it.
2824
2825 @itemize
2826
2827 @item On Sparc64, you can just try to launch any process by using the native
2828 libraries:
2829
2830 @example
2831 qemu-sparc64 /bin/ls
2832 @end example
2833
2834 @end itemize
2835
2836 @node BSD Command line options
2837 @subsection Command line options
2838
2839 @example
2840 usage: qemu-sparc64 [-h] [-d] [-L path] [-s size] [-bsd type] program [arguments...]
2841 @end example
2842
2843 @table @option
2844 @item -h
2845 Print the help
2846 @item -L path
2847 Set the library root path (default=/)
2848 @item -s size
2849 Set the stack size in bytes (default=524288)
2850 @item -ignore-environment
2851 Start with an empty environment. Without this option,
2852 the initial environment is a copy of the caller's environment.
2853 @item -E @var{var}=@var{value}
2854 Set environment @var{var} to @var{value}.
2855 @item -U @var{var}
2856 Remove @var{var} from the environment.
2857 @item -bsd type
2858 Set the type of the emulated BSD Operating system. Valid values are
2859 FreeBSD, NetBSD and OpenBSD (default).
2860 @end table
2861
2862 Debug options:
2863
2864 @table @option
2865 @item -d item1,...
2866 Activate logging of the specified items (use '-d help' for a list of log items)
2867 @item -p pagesize
2868 Act as if the host page size was 'pagesize' bytes
2869 @item -singlestep
2870 Run the emulation in single step mode.
2871 @end table
2872
2873 @node compilation
2874 @chapter Compilation from the sources
2875
2876 @menu
2877 * Linux/Unix::
2878 * Windows::
2879 * Cross compilation for Windows with Linux::
2880 * Mac OS X::
2881 * Make targets::
2882 @end menu
2883
2884 @node Linux/Unix
2885 @section Linux/Unix
2886
2887 @subsection Compilation
2888
2889 First you must decompress the sources:
2890 @example
2891 cd /tmp
2892 tar zxvf qemu-x.y.z.tar.gz
2893 cd qemu-x.y.z
2894 @end example
2895
2896 Then you configure QEMU and build it (usually no options are needed):
2897 @example
2898 ./configure
2899 make
2900 @end example
2901
2902 Then type as root user:
2903 @example
2904 make install
2905 @end example
2906 to install QEMU in @file{/usr/local}.
2907
2908 @node Windows
2909 @section Windows
2910
2911 @itemize
2912 @item Install the current versions of MSYS and MinGW from
2913 @url{http://www.mingw.org/}. You can find detailed installation
2914 instructions in the download section and the FAQ.
2915
2916 @item Download
2917 the MinGW development library of SDL 1.2.x
2918 (@file{SDL-devel-1.2.x-@/mingw32.tar.gz}) from
2919 @url{http://www.libsdl.org}. Unpack it in a temporary place and
2920 edit the @file{sdl-config} script so that it gives the
2921 correct SDL directory when invoked.
2922
2923 @item Install the MinGW version of zlib and make sure
2924 @file{zlib.h} and @file{libz.dll.a} are in
2925 MinGW's default header and linker search paths.
2926
2927 @item Extract the current version of QEMU.
2928
2929 @item Start the MSYS shell (file @file{msys.bat}).
2930
2931 @item Change to the QEMU directory. Launch @file{./configure} and
2932 @file{make}. If you have problems using SDL, verify that
2933 @file{sdl-config} can be launched from the MSYS command line.
2934
2935 @item You can install QEMU in @file{Program Files/QEMU} by typing
2936 @file{make install}. Don't forget to copy @file{SDL.dll} in
2937 @file{Program Files/QEMU}.
2938
2939 @end itemize
2940
2941 @node Cross compilation for Windows with Linux
2942 @section Cross compilation for Windows with Linux
2943
2944 @itemize
2945 @item
2946 Install the MinGW cross compilation tools available at
2947 @url{http://www.mingw.org/}.
2948
2949 @item Download
2950 the MinGW development library of SDL 1.2.x
2951 (@file{SDL-devel-1.2.x-@/mingw32.tar.gz}) from
2952 @url{http://www.libsdl.org}. Unpack it in a temporary place and
2953 edit the @file{sdl-config} script so that it gives the
2954 correct SDL directory when invoked. Set up the @code{PATH} environment
2955 variable so that @file{sdl-config} can be launched by
2956 the QEMU configuration script.
2957
2958 @item Install the MinGW version of zlib and make sure
2959 @file{zlib.h} and @file{libz.dll.a} are in
2960 MinGW's default header and linker search paths.
2961
2962 @item
2963 Configure QEMU for Windows cross compilation:
2964 @example
2965 PATH=/usr/i686-pc-mingw32/sys-root/mingw/bin:$PATH ./configure --cross-prefix='i686-pc-mingw32-'
2966 @end example
2967 The example assumes @file{sdl-config} is installed under @file{/usr/i686-pc-mingw32/sys-root/mingw/bin} and
2968 MinGW cross compilation tools have names like @file{i686-pc-mingw32-gcc} and @file{i686-pc-mingw32-strip}.
2969 We set the @code{PATH} environment variable to ensure the MinGW version of @file{sdl-config} is used and
2970 use --cross-prefix to specify the name of the cross compiler.
2971 You can also use --prefix to set the Win32 install path which defaults to @file{c:/Program Files/QEMU}.
2972
2973 Under Fedora Linux, you can run:
2974 @example
2975 yum -y install mingw32-gcc mingw32-SDL mingw32-zlib
2976 @end example
2977 to get a suitable cross compilation environment.
2978
2979 @item You can install QEMU in the installation directory by typing
2980 @code{make install}. Don't forget to copy @file{SDL.dll} and @file{zlib1.dll} into the
2981 installation directory.
2982
2983 @end itemize
2984
2985 Wine can be used to launch the resulting qemu-system-i386.exe
2986 and all other qemu-system-@var{target}.exe compiled for Win32.
2987
2988 @node Mac OS X
2989 @section Mac OS X
2990
2991 The Mac OS X patches are not fully merged in QEMU, so you should look
2992 at the QEMU mailing list archive to have all the necessary
2993 information.
2994
2995 @node Make targets
2996 @section Make targets
2997
2998 @table @code
2999
3000 @item make
3001 @item make all
3002 Make everything which is typically needed.
3003
3004 @item install
3005 TODO
3006
3007 @item install-doc
3008 TODO
3009
3010 @item make clean
3011 Remove most files which were built during make.
3012
3013 @item make distclean
3014 Remove everything which was built during make.
3015
3016 @item make dvi
3017 @item make html
3018 @item make info
3019 @item make pdf
3020 Create documentation in dvi, html, info or pdf format.
3021
3022 @item make cscope
3023 TODO
3024
3025 @item make defconfig
3026 (Re-)create some build configuration files.
3027 User made changes will be overwritten.
3028
3029 @item tar
3030 @item tarbin
3031 TODO
3032
3033 @end table
3034
3035 @node License
3036 @appendix License
3037
3038 QEMU is a trademark of Fabrice Bellard.
3039
3040 QEMU is released under the GNU General Public License (TODO: add link).
3041 Parts of QEMU have specific licenses, see file LICENSE.
3042
3043 TODO (refer to file LICENSE, include it, include the GPL?)
3044
3045 @node Index
3046 @appendix Index
3047 @menu
3048 * Concept Index::
3049 * Function Index::
3050 * Keystroke Index::
3051 * Program Index::
3052 * Data Type Index::
3053 * Variable Index::
3054 @end menu
3055
3056 @node Concept Index
3057 @section Concept Index
3058 This is the main index. Should we combine all keywords in one index? TODO
3059 @printindex cp
3060
3061 @node Function Index
3062 @section Function Index
3063 This index could be used for command line options and monitor functions.
3064 @printindex fn
3065
3066 @node Keystroke Index
3067 @section Keystroke Index
3068
3069 This is a list of all keystrokes which have a special function
3070 in system emulation.
3071
3072 @printindex ky
3073
3074 @node Program Index
3075 @section Program Index
3076 @printindex pg
3077
3078 @node Data Type Index
3079 @section Data Type Index
3080
3081 This index could be used for qdev device names and options.
3082
3083 @printindex tp
3084
3085 @node Variable Index
3086 @section Variable Index
3087 @printindex vr
3088
3089 @bye