qemu-doc.texi

QEMU 0.91 source code, supports ARM processor including S3C24xx series

@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

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
gdb connection:
@example
> qemu -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

Then launch gdb on the 'vmlinux' executable:
@example
> gdb vmlinux
@end example

In gdb, connect to QEMU:
@example
(gdb) target remote localhost:1234
@end example

Then you can use gdb normally. For example, type 'c' to launch the kernel:
@example
(gdb) c
@end example

Here are some useful tips in order to use gdb on system code:

@enumerate
@item
Use @code{info reg} to display all the CPU registers.
@item
Use @code{x/10i $eip} to display the code at the PC position.
@item
Use @code{set architecture i8086} to dump 16 bit code. Then use
@code{x/10i $cs*16+$eip} to dump the code at the PC position.
@end enumerate

@node pcsys_os_specific
@section Target OS specific information

@subsection Linux

To have access to SVGA graphic modes under X11, use the @code{vesa} or
the @code{cirrus} X11 driver. For optimal performances, use 16 bit
color depth in the guest and the host OS.

When using a 2.6 guest Linux kernel, you should add the option
@code{clock=pit} on the kernel command line because the 2.6 Linux
kernels make very strict real time clock checks by default that QEMU
cannot simulate exactly.

When using a 2.6 guest Linux kernel, verify that the 4G/4G patch is
not activated because QEMU is slower with this patch. The QEMU
Accelerator Module is also much slower in this case. Earlier Fedora
Core 3 Linux kernel (< 2.6.9-1.724_FC3) were known to incorporate this
patch by default. Newer kernels don't have it.

@subsection Windows

If you have a slow host, using Windows 95 is better as it gives the
best speed. Windows 2000 is also a good choice.

@subsubsection SVGA graphic modes support

QEMU emulates a Cirrus Logic GD5446 Video
card. All Windows versions starting from Windows 95 should recognize
and use this graphic card. For optimal performances, use 16 bit color
depth in the guest and the host OS.

If you are using Windows XP as guest OS and if you want to use high
resolution modes which the Cirrus Logic BIOS does not support (i.e. >=
1280x1024x16), then you should use the VESA VBE virtual graphic card
(option @option{-std-vga}).

@subsubsection CPU usage reduction

Windows 9x does not correctly use the CPU HLT
instruction. The result is that it takes host CPU cycles even when
idle. You can install the utility from
@url{http://www.user.cityline.ru/~maxamn/amnhltm.zip} to solve this
problem. Note that no such tool is needed for NT, 2000 or XP.

@subsubsection Windows 2000 disk full problem

Windows 2000 has a bug which gives a disk full problem during its
installation. When installing it, use the @option{-win2k-hack} QEMU
option to enable a specific workaround. After Windows 2000 is
installed, you no longer need this option (this option slows down the
IDE transfers).

@subsubsection Windows 2000 shutdown

Windows 2000 cannot automatically shutdown in QEMU although Windows 98
can. It comes from the fact that Windows 2000 does not automatically
use the APM driver provided by the BIOS.

In order to correct that, do the following (thanks to Struan
Bartlett): go to the Control Panel => Add/Remove Hardware & Next =>
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.

@subsubsection Share a directory between Unix and Windows

See @ref{sec_invocation} about the help of the option @option{-smb}.

@subsubsection Windows XP security problem

Some releases of Windows XP install correctly but give a security
error when booting:
@example
A problem is preventing Windows from accurately checking the
license for this computer. Error code: 0x800703e6.
@end example

The workaround is to install a service pack for XP after a boot in safe
mode. Then reboot, and the problem should go away. Since there is no
network while in safe mode, its recommended to download the full
installation of SP1 or SP2 and transfer that via an ISO or using the
vvfat block device ("-hdb fat:directory_which_holds_the_SP").

@subsection MS-DOS and FreeDOS

@subsubsection CPU usage reduction

DOS does not correctly use the CPU HLT instruction. The result is that
it takes host CPU cycles even when idle. You can install the utility
from @url{http://www.vmware.com/software/dosidle210.zip} to solve this
problem.

@node QEMU System emulator for non PC targets
@chapter QEMU System emulator for non PC targets

QEMU is a generic emulator and it emulates many non PC
machines. Most of the options are similar to the PC emulator. The
differences are mentioned in the following sections.

@menu
* QEMU PowerPC System emulator::
* Sparc32 System emulator::
* Sparc64 System emulator::
* MIPS System emulator::
* ARM System emulator::
* ColdFire System emulator::
@end menu

@node QEMU PowerPC System emulator
@section QEMU PowerPC System emulator

Use the executable @file{qemu-system-ppc} to simulate a complete PREP
or PowerMac PowerPC system.

QEMU emulates the following PowerMac peripherals:

@itemize @minus
@item
UniNorth PCI Bridge
@item
PCI VGA compatible card with VESA Bochs Extensions
@item
2 PMAC IDE interfaces with hard disk and CD-ROM support
@item
NE2000 PCI adapters
@item
Non Volatile RAM
@item
VIA-CUDA with ADB keyboard and mouse.
@end itemize

QEMU emulates the following PREP peripherals:

@itemize @minus
@item
PCI Bridge
@item
PCI VGA compatible card with VESA Bochs Extensions
@item
2 IDE interfaces with hard disk and CD-ROM support
@item
Floppy disk
@item
NE2000 network adapters
@item
Serial port
@item
PREP Non Volatile RAM
@item
PC compatible keyboard and mouse.
@end itemize

QEMU uses the Open Hack'Ware Open Firmware Compatible BIOS available at
@url{http://perso.magic.fr/l_indien/OpenHackWare/index.htm}.

@c man begin OPTIONS

The following options are specific to the PowerPC emulation:

@table @option

@item -g WxH[xDEPTH]

Set the initial VGA graphic mode. The default is 800x600x15.

@end table

@c man end


More information is available at
@url{http://perso.magic.fr/l_indien/qemu-ppc/}.

@node Sparc32 System emulator
@secti