X-Git-Url: https://git.proxmox.com/?a=blobdiff_plain;f=qemu-doc.texi;h=185dd47a033d5ff41265121355a0252831e6c4e3;hb=8b7acc79b9adb4dda6cc867b90e3a1e873f4f7e8;hp=11f4166995e23e3310b21cdbdcba22c44080cae0;hpb=126c79133f77d1b0b7c3849899c6d5f83b2fd410;p=qemu.git diff --git a/qemu-doc.texi b/qemu-doc.texi index 11f416699..185dd47a0 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -78,7 +78,7 @@ to ease cross-compilation and cross-debugging. @end itemize -QEMU can run without an host kernel driver and yet gives acceptable +QEMU can run without a host kernel driver and yet gives acceptable performance. For system emulation, the following hardware targets are supported: @@ -214,11 +214,7 @@ PCI UHCI USB controller and a virtual USB hub. SMP is supported with up to 255 CPUs. -Note that adlib, gus and cs4231a are only available when QEMU was -configured with --audio-card-list option containing the name(s) of -required card(s). - -QEMU uses the PC BIOS from the Bochs project and the Plex86/Bochs LGPL +QEMU uses the PC BIOS from the Seabios project and the Plex86/Bochs LGPL VGA BIOS. QEMU uses YM3812 emulation by Tatsuyuki Satoh. @@ -227,15 +223,15 @@ QEMU uses GUS emulation (GUSEMU32 @url{http://www.deinmeister.de/gusemu/}) by Tibor "TS" Schütz. Note that, by default, GUS shares IRQ(7) with parallel ports and so -qemu must be told to not have parallel ports to have working GUS +QEMU must be told to not have parallel ports to have working GUS. @example -qemu dos.img -soundhw gus -parallel none +qemu-system-i386 dos.img -soundhw gus -parallel none @end example Alternatively: @example -qemu dos.img -device gus,irq=5 +qemu-system-i386 dos.img -device gus,irq=5 @end example Or some other unclaimed IRQ. @@ -251,7 +247,7 @@ CS4231A is the chip used in Windows Sound System and GUSMAX products Download and uncompress the linux image (@file{linux.img}) and type: @example -qemu linux.img +qemu-system-i386 linux.img @end example Linux should boot and give you a prompt. @@ -261,7 +257,7 @@ Linux should boot and give you a prompt. @example @c man begin SYNOPSIS -usage: qemu [options] [@var{disk_image}] +usage: qemu-system-i386 [options] [@var{disk_image}] @c man end @end example @@ -416,11 +412,14 @@ snapshots. * vm_snapshots:: VM snapshots * qemu_img_invocation:: qemu-img Invocation * qemu_nbd_invocation:: qemu-nbd Invocation +* disk_images_formats:: Disk image file formats * host_drives:: Using host drives * disk_images_fat_images:: Virtual FAT disk images * disk_images_nbd:: NBD access * disk_images_sheepdog:: Sheepdog disk images * disk_images_iscsi:: iSCSI LUNs +* disk_images_gluster:: GlusterFS disk images +* disk_images_ssh:: Secure Shell (ssh) disk images @end menu @node disk_images_quickstart @@ -506,6 +505,172 @@ state is not saved or restored properly (in particular USB). @include qemu-nbd.texi +@node disk_images_formats +@subsection Disk image file formats + +QEMU supports many image file formats that can be used with VMs as well as with +any of the tools (like @code{qemu-img}). This includes the preferred formats +raw and qcow2 as well as formats that are supported for compatibility with +older QEMU versions or other hypervisors. + +Depending on the image format, different options can be passed to +@code{qemu-img create} and @code{qemu-img convert} using the @code{-o} option. +This section describes each format and the options that are supported for it. + +@table @option +@item raw + +Raw disk image format. This format has the advantage of +being simple and easily exportable to all other emulators. If your +file system supports @emph{holes} (for example in ext2 or ext3 on +Linux or NTFS on Windows), then only the written sectors will reserve +space. Use @code{qemu-img info} to know the real size used by the +image or @code{ls -ls} on Unix/Linux. + +@item qcow2 +QEMU image format, the most versatile format. Use it to have smaller +images (useful if your filesystem does not supports holes, for example +on Windows), optional AES encryption, zlib based compression and +support of multiple VM snapshots. + +Supported options: +@table @code +@item compat +Determines the qcow2 version to use. @code{compat=0.10} uses the traditional +image format that can be read by any QEMU since 0.10 (this is the default). +@code{compat=1.1} enables image format extensions that only QEMU 1.1 and +newer understand. Amongst others, this includes zero clusters, which allow +efficient copy-on-read for sparse images. + +@item backing_file +File name of a base image (see @option{create} subcommand) +@item backing_fmt +Image format of the base image +@item encryption +If this option is set to @code{on}, the image is encrypted. + +Encryption uses the AES format which is very secure (128 bit keys). Use +a long password (16 characters) to get maximum protection. + +@item cluster_size +Changes the qcow2 cluster size (must be between 512 and 2M). Smaller cluster +sizes can improve the image file size whereas larger cluster sizes generally +provide better performance. + +@item preallocation +Preallocation mode (allowed values: off, metadata). An image with preallocated +metadata is initially larger but can improve performance when the image needs +to grow. + +@item lazy_refcounts +If this option is set to @code{on}, reference count updates are postponed with +the goal of avoiding metadata I/O and improving performance. This is +particularly interesting with @option{cache=writethrough} which doesn't batch +metadata updates. The tradeoff is that after a host crash, the reference count +tables must be rebuilt, i.e. on the next open an (automatic) @code{qemu-img +check -r all} is required, which may take some time. + +This option can only be enabled if @code{compat=1.1} is specified. + +@end table + +@item qed +Old QEMU image format with support for backing files and compact image files +(when your filesystem or transport medium does not support holes). + +When converting QED images to qcow2, you might want to consider using the +@code{lazy_refcounts=on} option to get a more QED-like behaviour. + +Supported options: +@table @code +@item backing_file +File name of a base image (see @option{create} subcommand). +@item backing_fmt +Image file format of backing file (optional). Useful if the format cannot be +autodetected because it has no header, like some vhd/vpc files. +@item cluster_size +Changes the cluster size (must be power-of-2 between 4K and 64K). Smaller +cluster sizes can improve the image file size whereas larger cluster sizes +generally provide better performance. +@item table_size +Changes the number of clusters per L1/L2 table (must be power-of-2 between 1 +and 16). There is normally no need to change this value but this option can be +used for performance benchmarking. +@end table + +@item qcow +Old QEMU image format with support for backing files, compact image files, +encryption and compression. + +Supported options: +@table @code +@item backing_file +File name of a base image (see @option{create} subcommand) +@item encryption +If this option is set to @code{on}, the image is encrypted. +@end table + +@item cow +User Mode Linux Copy On Write image format. It is supported only for +compatibility with previous versions. +Supported options: +@table @code +@item backing_file +File name of a base image (see @option{create} subcommand) +@end table + +@item vdi +VirtualBox 1.1 compatible image format. +Supported options: +@table @code +@item static +If this option is set to @code{on}, the image is created with metadata +preallocation. +@end table + +@item vmdk +VMware 3 and 4 compatible image format. + +Supported options: +@table @code +@item backing_file +File name of a base image (see @option{create} subcommand). +@item compat6 +Create a VMDK version 6 image (instead of version 4) +@item subformat +Specifies which VMDK subformat to use. Valid options are +@code{monolithicSparse} (default), +@code{monolithicFlat}, +@code{twoGbMaxExtentSparse}, +@code{twoGbMaxExtentFlat} and +@code{streamOptimized}. +@end table + +@item vpc +VirtualPC compatible image format (VHD). +Supported options: +@table @code +@item subformat +Specifies which VHD subformat to use. Valid options are +@code{dynamic} (default) and @code{fixed}. +@end table +@end table + +@subsubsection Read-only formats +More disk image file formats are supported in a read-only mode. +@table @option +@item bochs +Bochs images of @code{growing} type. +@item cloop +Linux Compressed Loop image, useful only to reuse directly compressed +CD-ROM images present for example in the Knoppix CD-ROMs. +@item dmg +Apple disk image. +@item parallels +Parallels disk image format. +@end table + + @node host_drives @subsection Using host drives @@ -575,7 +740,7 @@ QEMU can automatically create a virtual FAT disk image from a directory tree. In order to use it, just type: @example -qemu linux.img -hdb fat:/my_directory +qemu-system-i386 linux.img -hdb fat:/my_directory @end example Then you access access to all the files in the @file{/my_directory} @@ -585,14 +750,14 @@ them via SAMBA or NFS. The default access is @emph{read-only}. Floppies can be emulated with the @code{:floppy:} option: @example -qemu linux.img -fda fat:floppy:/my_directory +qemu-system-i386 linux.img -fda fat:floppy:/my_directory @end example A read/write support is available for testing (beta stage) with the @code{:rw:} option: @example -qemu linux.img -fda fat:floppy:rw:/my_directory +qemu-system-i386 linux.img -fda fat:floppy:rw:/my_directory @end example What you should @emph{never} do: @@ -610,14 +775,14 @@ QEMU can access directly to block device exported using the Network Block Device protocol. @example -qemu linux.img -hdb nbd:my_nbd_server.mydomain.org:1024 +qemu-system-i386 linux.img -hdb nbd://my_nbd_server.mydomain.org:1024/ @end example If the NBD server is located on the same host, you can use an unix socket instead of an inet socket: @example -qemu linux.img -hdb nbd:unix:/tmp/my_socket +qemu-system-i386 linux.img -hdb nbd+unix://?socket=/tmp/my_socket @end example In this case, the block device must be exported using qemu-nbd: @@ -631,17 +796,26 @@ The use of qemu-nbd allows to share a disk between several guests: qemu-nbd --socket=/tmp/my_socket --share=2 my_disk.qcow2 @end example +@noindent and then you can use it with two guests: @example -qemu linux1.img -hdb nbd:unix:/tmp/my_socket -qemu linux2.img -hdb nbd:unix:/tmp/my_socket +qemu-system-i386 linux1.img -hdb nbd+unix://?socket=/tmp/my_socket +qemu-system-i386 linux2.img -hdb nbd+unix://?socket=/tmp/my_socket @end example -If the nbd-server uses named exports (since NBD 2.9.18), you must use the -"exportname" option: +If the nbd-server uses named exports (supported since NBD 2.9.18, or with QEMU's +own embedded NBD server), you must specify an export name in the URI: @example -qemu -cdrom nbd:localhost:exportname=debian-500-ppc-netinst -qemu -cdrom nbd:localhost:exportname=openSUSE-11.1-ppc-netinst +qemu-system-i386 -cdrom nbd://localhost/debian-500-ppc-netinst +qemu-system-i386 -cdrom nbd://localhost/openSUSE-11.1-ppc-netinst +@end example + +The URI syntax for NBD is supported since QEMU 1.3. An alternative syntax is +also available. Here are some example of the older syntax: +@example +qemu-system-i386 linux.img -hdb nbd:my_nbd_server.mydomain.org:1024 +qemu-system-i386 linux2.img -hdb nbd:unix:/tmp/my_socket +qemu-system-i386 -cdrom nbd:localhost:10809:exportname=debian-500-ppc-netinst @end example @node disk_images_sheepdog @@ -653,7 +827,7 @@ QEMU-based virtual machines. You can create a Sheepdog disk image with the command: @example -qemu-img create sheepdog:@var{image} @var{size} +qemu-img create sheepdog:///@var{image} @var{size} @end example where @var{image} is the Sheepdog image name and @var{size} is its size. @@ -661,38 +835,44 @@ size. To import the existing @var{filename} to Sheepdog, you can use a convert command. @example -qemu-img convert @var{filename} sheepdog:@var{image} +qemu-img convert @var{filename} sheepdog:///@var{image} @end example You can boot from the Sheepdog disk image with the command: @example -qemu sheepdog:@var{image} +qemu-system-i386 sheepdog:///@var{image} @end example You can also create a snapshot of the Sheepdog image like qcow2. @example -qemu-img snapshot -c @var{tag} sheepdog:@var{image} +qemu-img snapshot -c @var{tag} sheepdog:///@var{image} @end example where @var{tag} is a tag name of the newly created snapshot. To boot from the Sheepdog snapshot, specify the tag name of the snapshot. @example -qemu sheepdog:@var{image}:@var{tag} +qemu-system-i386 sheepdog:///@var{image}#@var{tag} @end example You can create a cloned image from the existing snapshot. @example -qemu-img create -b sheepdog:@var{base}:@var{tag} sheepdog:@var{image} +qemu-img create -b sheepdog:///@var{base}#@var{tag} sheepdog:///@var{image} @end example where @var{base} is a image name of the source snapshot and @var{tag} is its tag name. +You can use an unix socket instead of an inet socket: + +@example +qemu-system-i386 sheepdog+unix:///@var{image}?socket=@var{path} +@end example + If the Sheepdog daemon doesn't run on the local host, you need to specify one of the Sheepdog servers to connect to. @example -qemu-img create sheepdog:@var{hostname}:@var{port}:@var{image} @var{size} -qemu sheepdog:@var{hostname}:@var{port}:@var{image} +qemu-img create sheepdog://@var{hostname}:@var{port}/@var{image} @var{size} +qemu-system-i386 sheepdog://@var{hostname}:@var{port}/@var{image} @end example @node disk_images_iscsi @@ -730,6 +910,62 @@ export LIBISCSI_CHAP_PASSWORD= iscsi://// @end example +Various session related parameters can be set via special options, either +in a configuration file provided via '-readconfig' or directly on the +command line. + +If the initiator-name is not specified qemu will use a default name +of 'iqn.2008-11.org.linux-kvm[:'] where is the name of the +virtual machine. + + +@example +Setting a specific initiator name to use when logging in to the target +-iscsi initiator-name=iqn.qemu.test:my-initiator +@end example + +@example +Controlling which type of header digest to negotiate with the target +-iscsi header-digest=CRC32C|CRC32C-NONE|NONE-CRC32C|NONE +@end example + +These can also be set via a configuration file +@example +[iscsi] + user = "CHAP username" + password = "CHAP password" + initiator-name = "iqn.qemu.test:my-initiator" + # header digest is one of CRC32C|CRC32C-NONE|NONE-CRC32C|NONE + header-digest = "CRC32C" +@end example + + +Setting the target name allows different options for different targets +@example +[iscsi "iqn.target.name"] + user = "CHAP username" + password = "CHAP password" + initiator-name = "iqn.qemu.test:my-initiator" + # header digest is one of CRC32C|CRC32C-NONE|NONE-CRC32C|NONE + header-digest = "CRC32C" +@end example + + +Howto use a configuration file to set iSCSI configuration options: +@example +cat >iscsi.conf <[,shm=] +qemu-system-i386 -device ivshmem,size=[,shm=] @end example If desired, interrupts can be sent between guest VMs accessing the same shared @@ -857,9 +1195,9 @@ is qemu.git/contrib/ivshmem-server. An example syntax when using the shared memory server is: @example -qemu -device ivshmem,size=[,chardev=] - [,msi=on][,ioeventfd=on][,vectors=n][,role=peer|master] -qemu -chardev socket,path=,id= +qemu-system-i386 -device ivshmem,size=[,chardev=] + [,msi=on][,ioeventfd=on][,vectors=n][,role=peer|master] +qemu-system-i386 -chardev socket,path=,id= @end example When using the server, the guest will be assigned a VM ID (>=0) that allows guests @@ -889,7 +1227,7 @@ kernel testing. The syntax is: @example -qemu -kernel arch/i386/boot/bzImage -hda root-2.4.20.img -append "root=/dev/hda" +qemu-system-i386 -kernel arch/i386/boot/bzImage -hda root-2.4.20.img -append "root=/dev/hda" @end example Use @option{-kernel} to provide the Linux kernel image and @@ -904,8 +1242,8 @@ If you do not need graphical output, you can disable it and redirect the virtual serial port and the QEMU monitor to the console with the @option{-nographic} option. The typical command line is: @example -qemu -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \ - -append "root=/dev/hda console=ttyS0" -nographic +qemu-system-i386 -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \ + -append "root=/dev/hda console=ttyS0" -nographic @end example Use @key{Ctrl-a c} to switch between the serial console and the @@ -916,7 +1254,7 @@ monitor (@pxref{pcsys_keys}). QEMU emulates a PCI UHCI USB controller. You can virtually plug virtual USB devices or real host USB devices (experimental, works only -on Linux hosts). Qemu will automatically create and connect virtual USB hubs +on Linux hosts). QEMU will automatically create and connect virtual USB hubs as necessary to connect multiple USB devices. @menu @@ -934,7 +1272,7 @@ or the @code{usb_add} monitor command. Available devices are: Virtual Mouse. This will override the PS/2 mouse emulation when activated. @item tablet Pointer device that uses absolute coordinates (like a touchscreen). -This means qemu is able to report the mouse position without having +This means QEMU is able to report the mouse position without having to grab the mouse. Also overrides the PS/2 mouse emulation when activated. @item disk:@var{file} Mass storage device based on @var{file} (@pxref{disk_images}) @@ -968,7 +1306,7 @@ Network adapter that supports CDC ethernet and RNDIS protocols. @var{options} specifies NIC options as with @code{-net nic,}@var{options} (see description). For instance, user-mode networking can be used with @example -qemu [...OPTIONS...] -net user,vlan=0 -usbdevice net:vlan=0 +qemu-system-i386 [...OPTIONS...] -net user,vlan=0 -usbdevice net:vlan=0 @end example Currently this cannot be used in machines that support PCI NICs. @item bt[:@var{hci-type}] @@ -978,7 +1316,7 @@ no type is given, the HCI logic corresponds to @code{-bt hci,vlan=0}. This USB device implements the USB Transport Layer of HCI. Example usage: @example -qemu [...OPTIONS...] -usbdevice bt:hci,vlan=3 -bt device:keyboard,vlan=3 +qemu-system-i386 [...OPTIONS...] -usbdevice bt:hci,vlan=3 -bt device:keyboard,vlan=3 @end example @end table @@ -1056,7 +1394,7 @@ For this setup it is recommended to restrict it to listen on a UNIX domain socket only. For example @example -qemu [...OPTIONS...] -vnc unix:/home/joebloggs/.qemu-myvm-vnc +qemu-system-i386 [...OPTIONS...] -vnc unix:/home/joebloggs/.qemu-myvm-vnc @end example This ensures that only users on local box with read/write access to that @@ -1072,12 +1410,14 @@ the protocol limits passwords to 8 characters it should not be considered to provide high security. The password can be fairly easily brute-forced by a client making repeat connections. For this reason, a VNC server using password authentication should be restricted to only listen on the loopback interface -or UNIX domain sockets. Password authentication is requested with the @code{password} -option, and then once QEMU is running the password is set with the monitor. Until -the monitor is used to set the password all clients will be rejected. +or UNIX domain sockets. Password authentication is not supported when operating +in FIPS 140-2 compliance mode as it requires the use of the DES cipher. Password +authentication is requested with the @code{password} option, and then once QEMU +is running the password is set with the monitor. Until the monitor is used to +set the password all clients will be rejected. @example -qemu [...OPTIONS...] -vnc :1,password -monitor stdio +qemu-system-i386 [...OPTIONS...] -vnc :1,password -monitor stdio (qemu) change vnc password Password: ******** (qemu) @@ -1094,7 +1434,7 @@ support provides a secure session, but no authentication. This allows any client to connect, and provides an encrypted session. @example -qemu [...OPTIONS...] -vnc :1,tls,x509=/etc/pki/qemu -monitor stdio +qemu-system-i386 [...OPTIONS...] -vnc :1,tls,x509=/etc/pki/qemu -monitor stdio @end example In the above example @code{/etc/pki/qemu} should contain at least three files, @@ -1112,7 +1452,7 @@ then validate against the CA certificate. This is a good choice if deploying in an environment with a private internal certificate authority. @example -qemu [...OPTIONS...] -vnc :1,tls,x509verify=/etc/pki/qemu -monitor stdio +qemu-system-i386 [...OPTIONS...] -vnc :1,tls,x509verify=/etc/pki/qemu -monitor stdio @end example @@ -1123,7 +1463,7 @@ Finally, the previous method can be combined with VNC password authentication to provide two layers of authentication for clients. @example -qemu [...OPTIONS...] -vnc :1,password,tls,x509verify=/etc/pki/qemu -monitor stdio +qemu-system-i386 [...OPTIONS...] -vnc :1,password,tls,x509verify=/etc/pki/qemu -monitor stdio (qemu) change vnc password Password: ******** (qemu) @@ -1146,7 +1486,7 @@ used for authentication, but assuming use of one supporting SSF, then QEMU can be launched with: @example -qemu [...OPTIONS...] -vnc :1,sasl -monitor stdio +qemu-system-i386 [...OPTIONS...] -vnc :1,sasl -monitor stdio @end example @node vnc_sec_certificate_sasl @@ -1160,7 +1500,7 @@ credentials. This can be enabled, by combining the 'sasl' option with the aforementioned TLS + x509 options: @example -qemu [...OPTIONS...] -vnc :1,tls,x509,sasl -monitor stdio +qemu-system-i386 [...OPTIONS...] -vnc :1,tls,x509,sasl -monitor stdio @end example @@ -1325,11 +1665,11 @@ use TLS and x509 certificates to protect security credentials from snooping. QEMU has a primitive support to work with gdb, so that you can do 'Ctrl-C' while the virtual machine is running and inspect its state. -In order to use gdb, launch qemu with the '-s' option. It will wait for a +In order to use gdb, launch QEMU with the '-s' option. It will wait for a gdb connection: @example -> qemu -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \ - -append "root=/dev/hda" +qemu-system-i386 -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \ + -append "root=/dev/hda" Connected to host network interface: tun0 Waiting gdb connection on port 1234 @end example @@ -1618,15 +1958,11 @@ SPARCbook The emulation is somewhat complete. SMP up to 16 CPUs is supported, but Linux limits the number of usable CPUs to 4. -It's also possible to simulate a SPARCstation 2 (sun4c architecture), -SPARCserver 1000, or SPARCcenter 2000 (sun4d architecture), but these -emulators are not usable yet. - -QEMU emulates the following sun4m/sun4c/sun4d peripherals: +QEMU emulates the following sun4m peripherals: @itemize @minus @item -IOMMU or IO-UNITs +IOMMU @item TCX Frame buffer @item @@ -1679,7 +2015,7 @@ qemu-system-sparc -prom-env 'auto-boot?=false' \ -prom-env 'boot-device=sd(0,2,0):d' -prom-env 'boot-args=linux single' @end example -@item -M [SS-4|SS-5|SS-10|SS-20|SS-600MP|LX|Voyager|SPARCClassic] [|SPARCbook|SS-2|SS-1000|SS-2000] +@item -M [SS-4|SS-5|SS-10|SS-20|SS-600MP|LX|Voyager|SPARCClassic] [|SPARCbook] Set the emulated machine type. Default is SS-5. @@ -2218,7 +2554,6 @@ so should only be used with trusted guest OS. @menu * Supported Operating Systems :: * Linux User space emulator:: -* Mac OS X/Darwin User space emulator :: * BSD User space emulator :: @end menu @@ -2231,8 +2566,6 @@ The following OS are supported in user space emulation: @item Linux (referred as qemu-linux-user) @item -Mac OS X/Darwin (referred as qemu-darwin-user) -@item BSD (referred as qemu-bsd-user) @end itemize @@ -2264,8 +2597,8 @@ qemu-i386 -L / /bin/ls @code{-L /} tells that the x86 dynamic linker must be searched with a @file{/} prefix. -@item Since QEMU is also a linux process, you can launch qemu with -qemu (NOTE: you can only do that if you compiled QEMU from the sources): +@item Since QEMU is also a linux process, you can launch QEMU with +QEMU (NOTE: you can only do that if you compiled QEMU from the sources): @example qemu-i386 -L / qemu-i386 -L / /bin/ls @@ -2341,10 +2674,7 @@ Set the x86 elf interpreter prefix (default=/usr/local/qemu-i386) @item -s size Set the x86 stack size in bytes (default=524288) @item -cpu model -Select CPU model (-cpu ? for list and additional feature selection) -@item -ignore-environment -Start with an empty environment. Without this option, -the initial environment is a copy of the caller's environment. +Select CPU model (-cpu help for list and additional feature selection) @item -E @var{var}=@var{value} Set environment @var{var} to @var{value}. @item -U @var{var} @@ -2361,8 +2691,8 @@ Pre-allocate a guest virtual address space of the given size (in bytes). Debug options: @table @option -@item -d -Activate log (logfile=/tmp/qemu.log) +@item -d item1,... +Activate logging of the specified items (use '-d help' for a list of log items) @item -p pagesize Act as if the host page size was 'pagesize' bytes @item -g port @@ -2437,93 +2767,6 @@ The binary format is detected automatically. @command{qemu-sparc64} can execute some Sparc64 (Sparc64 CPU, 64 bit ABI) and SPARC32PLUS binaries (Sparc64 CPU, 32 bit ABI). -@node Mac OS X/Darwin User space emulator -@section Mac OS X/Darwin User space emulator - -@menu -* Mac OS X/Darwin Status:: -* Mac OS X/Darwin Quick Start:: -* Mac OS X/Darwin Command line options:: -@end menu - -@node Mac OS X/Darwin Status -@subsection Mac OS X/Darwin Status - -@itemize @minus -@item -target x86 on x86: Most apps (Cocoa and Carbon too) works. [1] -@item -target PowerPC on x86: Not working as the ppc commpage can't be mapped (yet!) -@item -target PowerPC on PowerPC: Most apps (Cocoa and Carbon too) works. [1] -@item -target x86 on PowerPC: most utilities work. Cocoa and Carbon apps are not yet supported. -@end itemize - -[1] If you're host commpage can be executed by qemu. - -@node Mac OS X/Darwin Quick Start -@subsection Quick Start - -In order to launch a Mac OS X/Darwin process, QEMU needs the process executable -itself and all the target dynamic libraries used by it. If you don't have the FAT -libraries (you're running Mac OS X/ppc) you'll need to obtain it from a Mac OS X -CD or compile them by hand. - -@itemize - -@item On x86, you can just try to launch any process by using the native -libraries: - -@example -qemu-i386 /bin/ls -@end example - -or to run the ppc version of the executable: - -@example -qemu-ppc /bin/ls -@end example - -@item On ppc, you'll have to tell qemu where your x86 libraries (and dynamic linker) -are installed: - -@example -qemu-i386 -L /opt/x86_root/ /bin/ls -@end example - -@code{-L /opt/x86_root/} tells that the dynamic linker (dyld) path is in -@file{/opt/x86_root/usr/bin/dyld}. - -@end itemize - -@node Mac OS X/Darwin Command line options -@subsection Command line options - -@example -usage: qemu-i386 [-h] [-d] [-L path] [-s size] program [arguments...] -@end example - -@table @option -@item -h -Print the help -@item -L path -Set the library root path (default=/) -@item -s size -Set the stack size in bytes (default=524288) -@end table - -Debug options: - -@table @option -@item -d -Activate log (logfile=/tmp/qemu.log) -@item -p pagesize -Act as if the host page size was 'pagesize' bytes -@item -singlestep -Run the emulation in single step mode. -@end table - @node BSD User space emulator @section BSD User space emulator @@ -2587,8 +2830,8 @@ FreeBSD, NetBSD and OpenBSD (default). Debug options: @table @option -@item -d -Activate log (logfile=/tmp/qemu.log) +@item -d item1,... +Activate logging of the specified items (use '-d help' for a list of log items) @item -p pagesize Act as if the host page size was 'pagesize' bytes @item -singlestep @@ -2657,9 +2900,9 @@ MinGW's default header and linker search paths. @file{make}. If you have problems using SDL, verify that @file{sdl-config} can be launched from the MSYS command line. -@item You can install QEMU in @file{Program Files/Qemu} by typing +@item You can install QEMU in @file{Program Files/QEMU} by typing @file{make install}. Don't forget to copy @file{SDL.dll} in -@file{Program Files/Qemu}. +@file{Program Files/QEMU}. @end itemize @@ -2693,7 +2936,7 @@ The example assumes @file{sdl-config} is installed under @file{/usr/i686-pc-ming MinGW cross compilation tools have names like @file{i686-pc-mingw32-gcc} and @file{i686-pc-mingw32-strip}. We set the @code{PATH} environment variable to ensure the MinGW version of @file{sdl-config} is used and use --cross-prefix to specify the name of the cross compiler. -You can also use --prefix to set the Win32 install path which defaults to @file{c:/Program Files/Qemu}. +You can also use --prefix to set the Win32 install path which defaults to @file{c:/Program Files/QEMU}. Under Fedora Linux, you can run: @example @@ -2707,7 +2950,8 @@ installation directory. @end itemize -Wine can be used to launch the resulting qemu.exe compiled for Win32. +Wine can be used to launch the resulting qemu-system-i386.exe +and all other qemu-system-@var{target}.exe compiled for Win32. @node Mac OS X @section Mac OS X