smc91c111: Fix receive starvation

[qemu.git] / qemu-doc.texi

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 83b2ad523708f9b4817d547f846fd4413bfeae6a..185dd47a033d5ff41265121355a0252831e6c4e3 100644 (file)
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -78,7 +78,7 @@ to ease cross-compilation and cross-debugging.
 
 @end itemize
 
 
 @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:
 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.
 
 
 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.
 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
 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
 
 @example

-qemu dos.img -soundhw gus -parallel none
+qemu-system-i386 dos.img -soundhw gus -parallel none

 @end example
 
 Alternatively:
 @example
 @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.
 @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
 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.
 @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
 
 @example
 @c man begin SYNOPSIS

-usage: qemu [options] [@var{disk_image}]
+usage: qemu-system-i386 [options] [@var{disk_image}]

 @c man end
 @end example
 
 @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
 * 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
 * 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
 @end menu
 
 @node disk_images_quickstart


@@ -506,6 +505,172 @@ state is not saved or restored properly (in particular USB).
 
 @include qemu-nbd.texi
 
 
 @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
 
 @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
 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}
 @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
 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
 @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:
 @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
 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
 @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:
 @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
 
 qemu-nbd --socket=/tmp/my_socket --share=2 my_disk.qcow2
 @end example
 

+@noindent

 and then you can use it with two guests:
 @example
 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
 
 @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
 @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
 @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
 
 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.
 @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
 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
 @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
 @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
 @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
 @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.
 
 @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
 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
 @end example
 
 @node disk_images_iscsi


@@ -734,6 +914,11 @@ Various session related parameters can be set via special options, either
 in a configuration file provided via '-readconfig' or directly on the
 command line.
 
 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[:<name>'] where <name> 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
 @example
 Setting a specific initiator name to use when logging in to the target
 -iscsi initiator-name=iqn.qemu.test:my-initiator


@@ -800,7 +985,108 @@ qemu-system-i386 -iscsi initiator-name=iqn.qemu.test:my-initiator \
     -cdrom iscsi://127.0.0.1/iqn.qemu.test/2
 @end example
 
     -cdrom iscsi://127.0.0.1/iqn.qemu.test/2
 @end example
 

+@node disk_images_gluster
+@subsection GlusterFS disk images
+
+GlusterFS is an user space distributed file system.
+
+You can boot from the GlusterFS disk image with the command:
+@example
+qemu-system-x86_64 -drive file=gluster[+@var{transport}]://[@var{server}[:@var{port}]]/@var{volname}/@var{image}[?socket=...]
+@end example
+
+@var{gluster} is the protocol.
+
+@var{transport} specifies the transport type used to connect to gluster
+management daemon (glusterd). Valid transport types are
+tcp, unix and rdma. If a transport type isn't specified, then tcp
+type is assumed.
+
+@var{server} specifies the server where the volume file specification for
+the given volume resides. This can be either hostname, ipv4 address
+or ipv6 address. ipv6 address needs to be within square brackets [ ].
+If transport type is unix, then @var{server} field should not be specifed.
+Instead @var{socket} field needs to be populated with the path to unix domain
+socket.
+
+@var{port} is the port number on which glusterd is listening. This is optional
+and if not specified, QEMU will send 0 which will make gluster to use the
+default port. If the transport type is unix, then @var{port} should not be
+specified.
+
+@var{volname} is the name of the gluster volume which contains the disk image.
+
+@var{image} is the path to the actual disk image that resides on gluster volume.
+
+You can create a GlusterFS disk image with the command:
+@example
+qemu-img create gluster://@var{server}/@var{volname}/@var{image} @var{size}
+@end example
+
+Examples
+@example
+qemu-system-x86_64 -drive file=gluster://1.2.3.4/testvol/a.img
+qemu-system-x86_64 -drive file=gluster+tcp://1.2.3.4/testvol/a.img
+qemu-system-x86_64 -drive file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
+qemu-system-x86_64 -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
+qemu-system-x86_64 -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
+qemu-system-x86_64 -drive file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
+qemu-system-x86_64 -drive file=gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket
+qemu-system-x86_64 -drive file=gluster+rdma://1.2.3.4:24007/testvol/a.img
+@end example
+
+@node disk_images_ssh
+@subsection Secure Shell (ssh) disk images
+
+You can access disk images located on a remote ssh server
+by using the ssh protocol:
+
+@example
+qemu-system-x86_64 -drive file=ssh://[@var{user}@@]@var{server}[:@var{port}]/@var{path}[?host_key_check=@var{host_key_check}]
+@end example
+
+Alternative syntax using properties:
+
+@example
+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}]
+@end example
+
+@var{ssh} is the protocol.

 
 

+@var{user} is the remote user.  If not specified, then the local
+username is tried.
+
+@var{server} specifies the remote ssh server.  Any ssh server can be
+used, but it must implement the sftp-server protocol.  Most Unix/Linux
+systems should work without requiring any extra configuration.
+
+@var{port} is the port number on which sshd is listening.  By default
+the standard ssh port (22) is used.
+
+@var{path} is the path to the disk image.
+
+The optional @var{host_key_check} parameter controls how the remote
+host's key is checked.  The default is @code{yes} which means to use
+the local @file{.ssh/known_hosts} file.  Setting this to @code{no}
+turns off known-hosts checking.  Or you can check that the host key
+matches a specific fingerprint:
+@code{host_key_check=md5:78:45:8e:14:57:4f:d5:45:83:0a:0e:f3:49:82:c9:c8}
+(@code{sha1:} can also be used as a prefix, but note that OpenSSH
+tools only use MD5 to print fingerprints).
+
+Currently authentication must be done using ssh-agent.  Other
+authentication methods may be supported in future.
+
+Note: Many ssh servers do not support an @code{fsync}-style operation.
+The ssh driver cannot guarantee that disk flush requests are
+obeyed, and this causes a risk of disk corruption if the remote
+server or network goes down during writes.  The driver will
+print a warning when @code{fsync} is not supported:
+
+warning: ssh server @code{ssh.example.com:22} does not support fsync
+
+With sufficiently new versions of libssh2 and OpenSSH, @code{fsync} is
+supported.

 
 @node pcsys_network
 @section Network emulation
 
 @node pcsys_network
 @section Network emulation


@@ -899,7 +1185,7 @@ zero-copy communication to the application level of the guests.  The basic
 syntax is:
 
 @example
 syntax is:
 
 @example

-qemu -device ivshmem,size=<size in format accepted by -m>[,shm=<shm name>]
+qemu-system-i386 -device ivshmem,size=<size in format accepted by -m>[,shm=<shm name>]

 @end example
 
 If desired, interrupts can be sent between guest VMs accessing the same shared
 @end example
 
 If desired, interrupts can be sent between guest VMs accessing the same shared


@@ -909,9 +1195,9 @@ is qemu.git/contrib/ivshmem-server.  An example syntax when using the shared
 memory server is:
 
 @example
 memory server is:
 
 @example

-qemu -device ivshmem,size=<size in format accepted by -m>[,chardev=<id>]
-                        [,msi=on][,ioeventfd=on][,vectors=n][,role=peer|master]
-qemu -chardev socket,path=<path>,id=<id>
+qemu-system-i386 -device ivshmem,size=<size in format accepted by -m>[,chardev=<id>]
+                 [,msi=on][,ioeventfd=on][,vectors=n][,role=peer|master]
+qemu-system-i386 -chardev socket,path=<path>,id=<id>

 @end example
 
 When using the server, the guest will be assigned a VM ID (>=0) that allows guests
 @end example
 
 When using the server, the guest will be assigned a VM ID (>=0) that allows guests


@@ -941,7 +1227,7 @@ kernel testing.
 
 The syntax is:
 @example
 
 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
 @end example
 
 Use @option{-kernel} to provide the Linux kernel image and


@@ -956,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
 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
 @end example
 
 Use @key{Ctrl-a c} to switch between the serial console and the


@@ -968,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
 
 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
 as necessary to connect multiple USB devices.
 
 @menu


@@ -986,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).
 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})
 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})


@@ -1020,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
 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}]
 @end example
 Currently this cannot be used in machines that support PCI NICs.
 @item bt[:@var{hci-type}]


@@ -1030,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
 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
 
 @end example
 @end table
 


@@ -1108,7 +1394,7 @@ For this setup it is recommended to restrict it to listen on a UNIX domain
 socket only. For example
 
 @example
 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
 @end example
 
 This ensures that only users on local box with read/write access to that


@@ -1124,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
 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
 
 @example

-qemu [...OPTIONS...] -vnc :1,password -monitor stdio
+qemu-system-i386 [...OPTIONS...] -vnc :1,password -monitor stdio

 (qemu) change vnc password
 Password: ********
 (qemu)
 (qemu) change vnc password
 Password: ********
 (qemu)


@@ -1146,7 +1434,7 @@ support provides a secure session, but no authentication. This allows any
 client to connect, and provides an encrypted session.
 
 @example
 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,
 @end example
 
 In the above example @code{/etc/pki/qemu} should contain at least three files,


@@ -1164,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
 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
 
 
 @end example
 
 


@@ -1175,7 +1463,7 @@ Finally, the previous method can be combined with VNC password authentication
 to provide two layers of authentication for clients.
 
 @example
 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)
 (qemu) change vnc password
 Password: ********
 (qemu)


@@ -1198,7 +1486,7 @@ used for authentication, but assuming use of one supporting SSF,
 then QEMU can be launched with:
 
 @example
 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
 @end example
 
 @node vnc_sec_certificate_sasl


@@ -1212,7 +1500,7 @@ credentials. This can be enabled, by combining the 'sasl' option
 with the aforementioned TLS + x509 options:
 
 @example
 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
 
 
 @end example
 
 


@@ -1377,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.
 
 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
 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
 Connected to host network interface: tun0
 Waiting gdb connection on port 1234
 @end example


@@ -1670,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.
 
 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
 
 @itemize @minus
 @item

-IOMMU or IO-UNITs
+IOMMU

 @item
 TCX Frame buffer
 @item
 @item
 TCX Frame buffer
 @item


@@ -1731,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
 
  -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.
 
 
 Set the emulated machine type. Default is SS-5.
 


@@ -2270,7 +2554,6 @@ so should only be used with trusted guest OS.
 @menu
 * Supported Operating Systems ::
 * Linux User space emulator::
 @menu
 * Supported Operating Systems ::
 * Linux User space emulator::

-* Mac OS X/Darwin User space emulator ::

 * BSD User space emulator ::
 @end menu
 
 * BSD User space emulator ::
 @end menu
 


@@ -2283,8 +2566,6 @@ The following OS are supported in user space emulation:
 @item
 Linux (referred as qemu-linux-user)
 @item
 @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
 
 BSD (referred as qemu-bsd-user)
 @end itemize
 


@@ -2316,8 +2597,8 @@ qemu-i386 -L / /bin/ls
 @code{-L /} tells that the x86 dynamic linker must be searched with a
 @file{/} prefix.
 
 @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
 
 @example
 qemu-i386 -L / qemu-i386 -L / /bin/ls


@@ -2393,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
 @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}
 @item -E @var{var}=@var{value}
 Set environment @var{var} to @var{value}.
 @item -U @var{var}


@@ -2413,8 +2691,8 @@ Pre-allocate a guest virtual address space of the given size (in bytes).
 Debug options:
 
 @table @option
 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
 @item -p pagesize
 Act as if the host page size was 'pagesize' bytes
 @item -g port


@@ -2489,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).
 
 @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
 
 @node BSD User space emulator
 @section BSD User space emulator
 


@@ -2639,8 +2830,8 @@ FreeBSD, NetBSD and OpenBSD (default).
 Debug options:
 
 @table @option
 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
 @item -p pagesize
 Act as if the host page size was 'pagesize' bytes
 @item -singlestep


@@ -2709,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.
 
 @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{make install}. Don't forget to copy @file{SDL.dll} in

-@file{Program Files/Qemu}.
+@file{Program Files/QEMU}.

 
 @end itemize
 
 
 @end itemize
 


@@ -2745,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.
 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
 
 Under Fedora Linux, you can run:
 @example


@@ -2759,7 +2950,8 @@ installation directory.
 
 @end itemize
 
 
 @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
 
 @node Mac OS X
 @section Mac OS X