@itemize @minus
-@item
+@item
Full system emulation. In this mode, QEMU emulates a full system (for
example a PC), including one or several processors and various
peripherals. It can be used to launch different Operating Systems
without rebooting the PC or to debug system code.
-@item
+@item
User mode emulation. In this mode, QEMU can launch
processes compiled for one CPU on another CPU. It can be used to
launch the Wine Windows API emulator (@url{http://www.winehq.org}) or
@end itemize
QEMU can run without an host kernel driver and yet gives acceptable
-performance.
+performance.
For system emulation, the following hardware targets are supported:
@itemize
* pcsys_network:: Network emulation
* direct_linux_boot:: Direct Linux Boot
* pcsys_usb:: USB emulation
+* vnc_security:: VNC security
* gdb_usage:: GDB usage
* pcsys_os_specific:: Target OS specific information
@end menu
following peripherals:
@itemize @minus
-@item
+@item
i440FX host PCI bridge and PIIX3 PCI to ISA bridge
@item
Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA
extensions (hardware level, including all non standard modes).
@item
PS/2 mouse and keyboard
-@item
+@item
2 PCI IDE interfaces with hard disk and CD-ROM support
@item
Floppy disk
-@item
+@item
PCI/ISA PCI network adapters
@item
Serial ports
Simulate an SMP system with @var{n} CPUs. On the PC target, up to 255
CPUs are supported.
-@item -nographic
-
-Normally, QEMU uses SDL to display the VGA output. With this option,
-you can totally disable graphical output so that QEMU is a simple
-command line application. The emulated serial port is redirected on
-the console. Therefore, you can still use QEMU to debug a Linux kernel
-with a serial console.
-
-@item -no-frame
-
-Do not use decorations for SDL windows and start them using the whole
-available screen space. This makes the using QEMU in a dedicated desktop
-workspace more convenient.
-
-@item -vnc display
-
-Normally, QEMU uses SDL to display the VGA output. With this option,
-you can have QEMU listen on VNC display @var{display} and redirect the VGA
-display over the VNC session. It is very useful to enable the usb
-tablet device when using this option (option @option{-usbdevice
-tablet}). When using the VNC display, you must use the @option{-k}
-option to set the keyboard layout if you are not using en-us.
-
-@var{display} may be in the form @var{interface:d}, in which case connections
-will only be allowed from @var{interface} on display @var{d}. Optionally,
-@var{interface} can be omitted. @var{display} can also be in the form
-@var{unix:path} where @var{path} is the location of a unix socket to listen for
-connections on.
-
-
-@item -k language
-
-Use keyboard layout @var{language} (for example @code{fr} for
-French). This option is only needed where it is not easy to get raw PC
-keycodes (e.g. on Macs, with some X11 servers or with a VNC
-display). You don't normally need to use it on PC/Linux or PC/Windows
-hosts.
-
-The available layouts are:
-@example
-ar de-ch es fo fr-ca hu ja mk no pt-br sv
-da en-gb et fr fr-ch is lt nl pl ru th
-de en-us fi fr-be hr it lv nl-be pt sl tr
-@end example
-
-The default is @code{en-us}.
-
@item -audio-help
Will show the audio subsystem help: list of drivers, tunable
time). This option is needed to have correct date in MS-DOS or
Windows.
-@item -full-screen
-Start in full screen.
-
@item -pidfile file
Store the QEMU process PID in @var{file}. It is useful if you launch QEMU
from a script.
@end table
+Display options:
+@table @option
+
+@item -nographic
+
+Normally, QEMU uses SDL to display the VGA output. With this option,
+you can totally disable graphical output so that QEMU is a simple
+command line application. The emulated serial port is redirected on
+the console. Therefore, you can still use QEMU to debug a Linux kernel
+with a serial console.
+
+@item -no-frame
+
+Do not use decorations for SDL windows and start them using the whole
+available screen space. This makes the using QEMU in a dedicated desktop
+workspace more convenient.
+
+@item -full-screen
+Start in full screen.
+
+@item -vnc display[,option[,option[,...]]]
+
+Normally, QEMU uses SDL to display the VGA output. With this option,
+you can have QEMU listen on VNC display @var{display} and redirect the VGA
+display over the VNC session. It is very useful to enable the usb
+tablet device when using this option (option @option{-usbdevice
+tablet}). When using the VNC display, you must use the @option{-k}
+parameter to set the keyboard layout if you are not using en-us. Valid
+syntax for the @var{display} is
+
+@table @code
+
+@item @var{interface:d}
+
+TCP connections will only be allowed from @var{interface} on display @var{d}.
+By convention the TCP port is 5900+@var{d}. Optionally, @var{interface} can
+be omitted in which case the server will bind to all interfaces.
+
+@item @var{unix:path}
+
+Connections will be allowed over UNIX domain sockets where @var{path} is the
+location of a unix socket to listen for connections on.
+
+@item @var{none}
+
+VNC is initialized by not started. The monitor @code{change} command can be used
+to later start the VNC server.
+
+@end table
+
+Following the @var{display} value there may be one or more @var{option} flags
+separated by commas. Valid options are
+
+@table @code
+
+@item @var{password}
+
+Require that password based authentication is used for client connections.
+The password must be set separately using the @code{change} command in the
+@ref{pcsys_monitor}
+
+@item @var{tls}
+
+Require that client use TLS when communicating with the VNC server. This
+uses anonymous TLS credentials so is susceptible to a man-in-the-middle
+attack. It is recommended that this option be combined with either the
+@var{x509} or @var{x509verify} options.
+
+@item @var{x509=/path/to/certificate/dir}
+
+Valid if @var{tls} is specified. Require that x509 credentials are used
+for negotiating the TLS session. The server will send its x509 certificate
+to the client. It is recommended that a password be set on the VNC server
+to provide authentication of the client when this is used. The path following
+this option specifies where the x509 certificates are to be loaded from.
+See the @ref{vnc_security} section for details on generating certificates.
+
+@item @var{x509verify=/path/to/certificate/dir}
+
+Valid if @var{tls} is specified. Require that x509 credentials are used
+for negotiating the TLS session. The server will send its x509 certificate
+to the client, and request that the client send its own x509 certificate.
+The server will validate the client's certificate against the CA certificate,
+and reject clients when validation fails. If the certificate authority is
+trusted, this is a sufficient authentication mechanism. You may still wish
+to set a password on the VNC server as a second authentication layer. The
+path following this option specifies where the x509 certificates are to
+be loaded from. See the @ref{vnc_security} section for details on generating
+certificates.
+
+@end table
+
+@item -k language
+
+Use keyboard layout @var{language} (for example @code{fr} for
+French). This option is only needed where it is not easy to get raw PC
+keycodes (e.g. on Macs, with some X11 servers or with a VNC
+display). You don't normally need to use it on PC/Linux or PC/Windows
+hosts.
+
+The available layouts are:
+@example
+ar de-ch es fo fr-ca hu ja mk no pt-br sv
+da en-gb et fr fr-ch is lt nl pl ru th
+de en-us fi fr-be hr it lv nl-be pt sl tr
+@end example
+
+The default is @code{en-us}.
+
+@end table
+
USB options:
@table @option
@item -net socket[,vlan=n][,fd=h][,mcast=maddr:port]
Create a VLAN @var{n} shared with another QEMU virtual
-machines using a UDP multicast socket, effectively making a bus for
+machines using a UDP multicast socket, effectively making a bus for
every QEMU with same multicast address @var{maddr} and @var{port}.
NOTES:
@enumerate
-@item
-Several QEMU can be running on different hosts and share same bus (assuming
+@item
+Several QEMU can be running on different hosts and share same bus (assuming
correct multicast setup for these hosts).
@item
mcast support is compatible with User Mode Linux (argument @option{eth@var{N}=mcast}), see
@table @option
-@item -kernel bzImage
+@item -kernel bzImage
Use @var{bzImage} as kernel image.
-@item -append cmdline
+@item -append cmdline
Use @var{cmdline} as kernel command line
@item -initrd file
Available character devices are:
@table @code
-@item vc
-Virtual console
+@item vc[:WxH]
+Virtual console. Optionally, a width and height can be given in pixel with
+@example
+vc:800x600
+@end example
+It is also possible to specify width or height in characters:
+@example
+vc:80Cx24C
+@end example
@item pty
[Linux only] Pseudo TTY (a new PTY is automatically allocated)
@item none
@end table
@item -s
-Wait gdb connection to port 1234 (@pxref{gdb_usage}).
+Wait gdb connection to port 1234 (@pxref{gdb_usage}).
@item -p port
Change gdb connection port. @var{port} can be either a decimal number
to specify a TCP port, or a host device (same devices as the serial port).
@item -S
Do not start CPU at startup (you must type 'c' in the monitor).
-@item -d
+@item -d
Output log in /tmp/qemu.log
@item -hdachs c,h,s,[,t]
Force hard disk 0 physical geometry (1 <= @var{c} <= 16383, 1 <=
@table @key
@item Ctrl-a h
Print this help
-@item Ctrl-a x
+@item Ctrl-a x
Exit emulator
-@item Ctrl-a s
+@item Ctrl-a s
Save disk data back to file (if -snapshot)
@item Ctrl-a t
toggle console timestamps
Remove or insert removable media images
(such as CD-ROM or floppies)
-@item
+@item
Freeze/unfreeze the Virtual Machine (VM) and save or restore its state
from a disk file.
@item help or ? [cmd]
Show the help for all commands or just for command @var{cmd}.
-@item commit
+@item commit
Commit changes to the disk images (if -snapshot is used)
-@item info subcommand
+@item info subcommand
show various information about the system state
@table @option
@item eject [-f] device
Eject a removable medium (use -f to force it).
-@item change device filename
-Change a removable medium.
+@item change device setting
+
+Change the configuration of a device
+
+@table @option
+@item change @var{diskdevice} @var{filename}
+Change the medium for a removable disk device to point to @var{filename}. eg
+
+@example
+(qemu) change cdrom /path/to/some.iso
+@end example
+
+@item change vnc @var{display,options}
+Change the configuration of the VNC server. The valid syntax for @var{display}
+and @var{options} are described at @ref{sec_invocation}. eg
+
+@example
+(qemu) change vnc localhost:1
+@end example
+
+@item change vnc password
+
+Change the password associated with the VNC server. The monitor will prompt for
+the new password to be entered. VNC passwords are only significant upto 8 letters.
+eg.
+
+@example
+(qemu) change vnc password
+Password: ********
+@end example
+
+@end table
@item screendump filename
Save screen into PPM image @var{filename}.
data. Its syntax is: @option{/@{count@}@{format@}@{size@}}
@table @var
-@item count
+@item count
is the number of items to be dumped.
@item format
@end table
-Examples:
+Examples:
@itemize
@item
Dump 10 instructions at the current instruction pointer:
-@example
+@example
(qemu) x/10i $eip
0x90107063: ret
0x90107064: sti
@item
Dump 80 16 bit values at the start of the video memory.
-@smallexample
+@smallexample
(qemu) xp/80hx 0xb8000
0x000b8000: 0x0b50 0x0b6c 0x0b65 0x0b78 0x0b38 0x0b36 0x0b2f 0x0b42
0x000b8010: 0x0b6f 0x0b63 0x0b68 0x0b73 0x0b20 0x0b56 0x0b47 0x0b41
VM snapshots currently have the following known limitations:
@itemize
-@item
+@item
They cannot cope with removable devices if they are removed or
inserted after a snapshot is done.
-@item
+@item
A few device drivers still have incomplete snapshot support so their
state is not saved or restored properly (in particular USB).
@end itemize
@subsubsection Mac OS X
-@file{/dev/cdrom} is an alias to the first CDROM.
+@file{/dev/cdrom} is an alias to the first CDROM.
Currently there is no specific code to handle removable media, so it
is better to use the @code{change} or @code{eject} monitor commands to
QEMU can automatically create a virtual FAT disk image from a
directory tree. In order to use it, just type:
-@example
+@example
qemu linux.img -hdb fat:/my_directory
@end example
Floppies can be emulated with the @code{:floppy:} option:
-@example
+@example
qemu 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
+@example
qemu linux.img -fda fat:floppy:rw:/my_directory
@end example
| (10.0.2.2)
|
----> DNS server (10.0.2.3)
- |
+ |
----> SMB server (10.0.2.4)
@end example
Virtual Wacom PenPartner tablet. This device is similar to the @code{tablet}
above but it can be used with the tslib library because in addition to touch
coordinates it reports touch pressure.
+@item @code{keyboard}
+Standard USB keyboard. Will override the PS/2 keyboard (if present).
@end table
@node host_usb_devices
Cameras) are not supported yet.
@enumerate
-@item If you use an early Linux 2.4 kernel, verify that no Linux driver
+@item If you use an early Linux 2.4 kernel, verify that no Linux driver
is actually using the USB device. A simple way to do that is simply to
disable the corresponding kernel module by renaming it from @file{mydriver.o}
to @file{mydriver.o.disabled}.
@end example
@item Launch QEMU and do in the monitor:
-@example
+@example
info usbhost
Device 1.2, speed 480 Mb/s
Class 00: USB device 1234:5678, USB DISK
hubs, it won't work).
@item Add the device in QEMU by using:
-@example
+@example
usb_add host:1234:5678
@end example
When relaunching QEMU, you may have to unplug and plug again the USB
device to make it work again (this is a bug).
+@node vnc_security
+@section VNC security
+
+The VNC server capability provides access to the graphical console
+of the guest VM across the network. This has a number of security
+considerations depending on the deployment scenarios.
+
+@menu
+* vnc_sec_none::
+* vnc_sec_password::
+* vnc_sec_certificate::
+* vnc_sec_certificate_verify::
+* vnc_sec_certificate_pw::
+* vnc_generate_cert::
+@end menu
+@node vnc_sec_none
+@subsection Without passwords
+
+The simplest VNC server setup does not include any form of authentication.
+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
+@end example
+
+This ensures that only users on local box with read/write access to that
+path can access the VNC server. To securely access the VNC server from a
+remote machine, a combination of netcat+ssh can be used to provide a secure
+tunnel.
+
+@node vnc_sec_password
+@subsection With passwords
+
+The VNC protocol has limited support for password based authentication. Since
+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 ayuthentication 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) change vnc password
+Password: ********
+(qemu)
+@end example
+
+@node vnc_sec_certificate
+@subsection With x509 certificates
+
+The QEMU VNC server also implements the VeNCrypt extension allowing use of
+TLS for encryption of the session, and x509 certificates for authentication.
+The use of x509 certificates is strongly recommended, because TLS on its
+own is susceptible to man-in-the-middle attacks. Basic x509 certificate
+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
+@end example
+
+In the above example @code{/etc/pki/qemu} should contain at least three files,
+@code{ca-cert.pem}, @code{server-cert.pem} and @code{server-key.pem}. Unprivileged
+users will want to use a private directory, for example @code{$HOME/.pki/qemu}.
+NB the @code{server-key.pem} file should be protected with file mode 0600 to
+only be readable by the user owning it.
+
+@node vnc_sec_certificate_verify
+@subsection With x509 certificates and client verification
+
+Certificates can also provide a means to authenticate the client connecting.
+The server will request that the client provide a certificate, which it will
+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
+@end example
+
+
+@node vnc_sec_certificate_pw
+@subsection With x509 certificates, client verification and passwords
+
+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) change vnc password
+Password: ********
+(qemu)
+@end example
+
+@node vnc_generate_cert
+@subsection Generating certificates for VNC
+
+The GNU TLS packages provides a command called @code{certtool} which can
+be used to generate certificates and keys in PEM format. At a minimum it
+is neccessary to setup a certificate authority, and issue certificates to
+each server. If using certificates for authentication, then each client
+will also need to be issued a certificate. The recommendation is for the
+server to keep its certificates in either @code{/etc/pki/qemu} or for
+unprivileged users in @code{$HOME/.pki/qemu}.
+
+@menu
+* vnc_generate_ca::
+* vnc_generate_server::
+* vnc_generate_client::
+@end menu
+@node vnc_generate_ca
+@subsubsection Setup the Certificate Authority
+
+This step only needs to be performed once per organization / organizational
+unit. First the CA needs a private key. This key must be kept VERY secret
+and secure. If this key is compromised the entire trust chain of the certificates
+issued with it is lost.
+
+@example
+# certtool --generate-privkey > ca-key.pem
+@end example
+
+A CA needs to have a public certificate. For simplicity it can be a self-signed
+certificate, or one issue by a commercial certificate issuing authority. To
+generate a self-signed certificate requires one core piece of information, the
+name of the organization.
+
+@example
+# cat > ca.info <<EOF
+cn = Name of your organization
+ca
+cert_signing_key
+EOF
+# certtool --generate-self-signed \
+ --load-privkey ca-key.pem
+ --template ca.info \
+ --outfile ca-cert.pem
+@end example
+
+The @code{ca-cert.pem} file should be copied to all servers and clients wishing to utilize
+TLS support in the VNC server. The @code{ca-key.pem} must not be disclosed/copied at all.
+
+@node vnc_generate_server
+@subsubsection Issuing server certificates
+
+Each server (or host) needs to be issued with a key and certificate. When connecting
+the certificate is sent to the client which validates it against the CA certificate.
+The core piece of information for a server certificate is the hostname. This should
+be the fully qualified hostname that the client will connect with, since the client
+will typically also verify the hostname in the certificate. On the host holding the
+secure CA private key:
+
+@example
+# cat > server.info <<EOF
+organization = Name of your organization
+cn = server.foo.example.com
+tls_www_server
+encryption_key
+signing_key
+EOF
+# certtool --generate-privkey > server-key.pem
+# certtool --generate-certificate \
+ --load-ca-certificate ca-cert.pem \
+ --load-ca-privkey ca-key.pem \
+ --load-privkey server server-key.pem \
+ --template server.info \
+ --outfile server-cert.pem
+@end example
+
+The @code{server-key.pem} and @code{server-cert.pem} files should now be securely copied
+to the server for which they were generated. The @code{server-key.pem} is security
+sensitive and should be kept protected with file mode 0600 to prevent disclosure.
+
+@node vnc_generate_client
+@subsubsection Issuing client certificates
+
+If the QEMU VNC server is to use the @code{x509verify} option to validate client
+certificates as its authentication mechanism, each client also needs to be issued
+a certificate. The client certificate contains enough metadata to uniquely identify
+the client, typically organization, state, city, building, etc. On the host holding
+the secure CA private key:
+
+@example
+# cat > client.info <<EOF
+country = GB
+state = London
+locality = London
+organiazation = Name of your organization
+cn = client.foo.example.com
+tls_www_client
+encryption_key
+signing_key
+EOF
+# certtool --generate-privkey > client-key.pem
+# certtool --generate-certificate \
+ --load-ca-certificate ca-cert.pem \
+ --load-ca-privkey ca-key.pem \
+ --load-privkey client-key.pem \
+ --template client.info \
+ --outfile client-cert.pem
+@end example
+
+The @code{client-key.pem} and @code{client-cert.pem} files should now be securely
+copied to the client for which they were generated.
+
@node gdb_usage
@section GDB usage
Add/Troubleshoot a device => Add a new device & Next => No, select the
hardware from a list & Next => NT Apm/Legacy Support & Next => Next
(again) a few times. Now the driver is installed and Windows 2000 now
-correctly instructs QEMU to shutdown at the appropriate moment.
+correctly instructs QEMU to shutdown at the appropriate moment.
@subsubsection Share a directory between Unix and Windows
@menu
* QEMU PowerPC System emulator::
-* Sparc32 System emulator invocation::
-* Sparc64 System emulator invocation::
-* MIPS System emulator invocation::
-* ARM System emulator invocation::
-* ColdFire System emulator invocation::
+* Sparc32 System emulator::
+* Sparc64 System emulator::
+* MIPS System emulator::
+* ARM System emulator::
+* ColdFire System emulator::
@end menu
@node QEMU PowerPC System emulator
QEMU emulates the following PowerMac peripherals:
@itemize @minus
-@item
-UniNorth PCI Bridge
+@item
+UniNorth PCI Bridge
@item
PCI VGA compatible card with VESA Bochs Extensions
-@item
+@item
2 PMAC IDE interfaces with hard disk and CD-ROM support
-@item
+@item
NE2000 PCI adapters
@item
Non Volatile RAM
QEMU emulates the following PREP peripherals:
@itemize @minus
-@item
+@item
PCI Bridge
@item
PCI VGA compatible card with VESA Bochs Extensions
-@item
+@item
2 IDE interfaces with hard disk and CD-ROM support
@item
Floppy disk
-@item
+@item
NE2000 network adapters
@item
Serial port
@table @option
-@item -g WxH[xDEPTH]
+@item -g WxH[xDEPTH]
Set the initial VGA graphic mode. The default is 800x600x15.
@end table
-@c man end
+@c man end
More information is available at
@url{http://perso.magic.fr/l_indien/qemu-ppc/}.
-@node Sparc32 System emulator invocation
-@section Sparc32 System emulator invocation
+@node Sparc32 System emulator
+@section Sparc32 System emulator
Use the executable @file{qemu-system-sparc} to simulate a SparcStation 5
or SparcStation 10 (sun4m architecture). The emulation is somewhat complete.
IOMMU
@item
TCX Frame buffer
-@item
+@item
Lance (Am7990) Ethernet
@item
Non Volatile RAM M48T08
@end table
-@c man end
+@c man end
-@node Sparc64 System emulator invocation
-@section Sparc64 System emulator invocation
+@node Sparc64 System emulator
+@section Sparc64 System emulator
Use the executable @file{qemu-system-sparc64} to simulate a Sun4u machine.
The emulator is not usable for anything yet.
@itemize @minus
@item
-UltraSparc IIi APB PCI Bridge
+UltraSparc IIi APB PCI Bridge
@item
PCI VGA compatible card with VESA Bochs Extensions
@item
PC-compatible serial ports
@end itemize
-@node MIPS System emulator invocation
-@section MIPS System emulator invocation
+@node MIPS System emulator
+@section MIPS System emulator
Use the executable @file{qemu-system-mips} to simulate a MIPS machine.
-The emulator is able to boot a Linux kernel and to run a Linux Debian
-installation from NFS. The following devices are emulated:
+Three different machine types are emulated:
+
+@itemize @minus
+@item
+A generic ISA PC-like machine "mips"
+@item
+The MIPS Malta prototype board "malta"
+@item
+An ACER Pica "pica61"
+@end itemize
+
+The generic emulation is supported by Debian 'Etch' and is able to
+install Debian into a virtual disk image. The following devices are
+emulated:
@itemize @minus
-@item
-MIPS R4K CPU
+@item
+MIPS 24Kf CPU
@item
PC style serial port
@item
+PC style IDE disk
+@item
NE2000 network card
@end itemize
-More information is available in the QEMU mailing-list archive.
+The Malta emulation supports the following devices:
-@node ARM System emulator invocation
-@section ARM System emulator invocation
+@itemize @minus
+@item
+Core board with MIPS 24Kf CPU and Galileo system controller
+@item
+PIIX4 PCI/USB/SMbus controller
+@item
+The Multi-I/O chip's serial device
+@item
+PCnet32 PCI network card
+@item
+Malta FPGA serial device
+@item
+Cirrus VGA graphics card
+@end itemize
+
+The ACER Pica emulation supports:
+
+@itemize @minus
+@item
+MIPS R4000 CPU
+@item
+PC-style IRQ and DMA controllers
+@item
+PC Keyboard
+@item
+IDE controller
+@end itemize
+
+@node ARM System emulator
+@section ARM System emulator
Use the executable @file{qemu-system-arm} to simulate a ARM
machine. The ARM Integrator/CP board is emulated with the following
ARM926E, ARM1026E or ARM946E CPU
@item
Two PL011 UARTs
-@item
+@item
SMC 91c111 Ethernet adapter
@item
PL110 LCD controller
PL190 Vectored Interrupt Controller
@item
Four PL011 UARTs
-@item
+@item
SMC 91c111 Ethernet adapter
@item
PL110 LCD controller
ARM AMBA Generic/Distributed Interrupt Controller
@item
Four PL011 UARTs
-@item
+@item
SMC 91c111 Ethernet adapter
@item
PL110 LCD controller
A Linux 2.6 test image is available on the QEMU web site. More
information is available in the QEMU mailing-list archive.
-@node ColdFire System emulator invocation
-@section ColdFire System emulator invocation
+@node ColdFire System emulator
+@section ColdFire System emulator
Use the executable @file{qemu-system-m68k} to simulate a ColdFire machine.
The emulator is able to boot a uClinux kernel.
The M5208EVB emulation includes the following devices:
@itemize @minus
-@item
+@item
MCF5208 ColdFire V2 Microprocessor (ISA A+ with EMAC).
@item
Three Two on-chip UARTs.
The AN5206 emulation includes the following devices:
@itemize @minus
-@item
+@item
MCF5206 ColdFire V2 Microprocessor.
@item
Two on-chip UARTs.
@end itemize
-@node QEMU User space emulator
-@chapter QEMU User space emulator
+@node QEMU User space emulator
+@chapter QEMU User space emulator
@menu
* Supported Operating Systems ::
@subsection Quick Start
In order to launch a Linux process, QEMU needs the process executable
-itself and all the target (x86) dynamic libraries used by it.
+itself and all the target (x86) dynamic libraries used by it.
@itemize
@item On x86, you can just try to launch any process by using the native
libraries:
-@example
+@example
qemu-i386 -L / /bin/ls
@end example
@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
+@example
qemu-i386 -L / qemu-i386 -L / /bin/ls
@end example
@code{LD_LIBRARY_PATH} is not set:
@example
-unset LD_LIBRARY_PATH
+unset LD_LIBRARY_PATH
@end example
Then you can launch the precompiled @file{ls} x86 executable:
@end example
@item Download the binary x86 Wine install
-(@file{qemu-XXX-i386-wine.tar.gz} on the QEMU web page).
+(@file{qemu-XXX-i386-wine.tar.gz} on the QEMU web page).
@item Configure Wine on your account. Look at the provided script
@file{/usr/local/qemu-i386/@/bin/wine-conf.sh}. Your previous
@table @option
@item -h
Print the help
-@item -L path
+@item -L path
Set the x86 elf interpreter prefix (default=/usr/local/qemu-i386)
@item -s size
Set the x86 stack size in bytes (default=524288)
@item On x86, you can just try to launch any process by using the native
libraries:
-@example
+@example
qemu-i386 /bin/ls
@end example
or to run the ppc version of the executable:
-@example
+@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
+@example
qemu-i386 -L /opt/x86_root/ /bin/ls
@end example
@table @option
@item -h
Print the help
-@item -L path
+@item -L path
Set the library root path (default=/)
@item -s size
Set the stack size in bytes (default=524288)
@url{http://www.mingw.org/}. You can find detailed installation
instructions in the download section and the FAQ.
-@item Download
+@item Download
the MinGW development library of SDL 1.2.x
(@file{SDL-devel-1.2.x-@/mingw32.tar.gz}) from
@url{http://www.libsdl.org}. Unpack it in a temporary place, and
correct SDL directory when invoked.
@item Extract the current version of QEMU.
-
+
@item Start the MSYS shell (file @file{msys.bat}).
-@item Change to the QEMU directory. Launch @file{./configure} and
+@item Change to the QEMU directory. Launch @file{./configure} and
@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}.
Install the MinGW cross compilation tools available at
@url{http://www.mingw.org/}.
-@item
+@item
Install the Win32 version of SDL (@url{http://www.libsdl.org}) by
unpacking @file{i386-mingw32msvc.tar.gz}. Set up the PATH environment
variable so that @file{i386-mingw32msvc-sdl-config} can be launched by
the QEMU configuration script.
-@item
+@item
Configure QEMU for Windows cross compilation:
@example
./configure --enable-mingw32
chosen for the MinGW tools with --cross-prefix. You can also use
--prefix to set the Win32 install path.
-@item You can install QEMU in the installation directory by typing
+@item You can install QEMU in the installation directory by typing
@file{make install}. Don't forget to copy @file{SDL.dll} in the
-installation directory.
+installation directory.
@end itemize
projects / qemu.git / blobdiff