QEMU Upstream

History

Historically Xen contained a fork of qemu with Xen support added, known as 'qemu-xen-traditional' in the xl toolstack. However since Qemu 1.0 support for Xen has been part of the mainline Qemu and can be used with Xen from 4.2 onwards. The xl toolstack describes this version as 'qemu-xen', and this became the default from Xen 4.3 onward.

The 'qemu-xen-traditional' fork remains available in order to support guest's installed using it with operating systems which prefer not to have the hardware change under their feet.

Xen Qemu Trees

The 'qemu-xen-traditional' fork is maintained on xenbits in 'qemu-xen-VERSION.git' e.g. qemu-xen-unstable.git, qemu-xen-4.3-testing.git etc.

The 'qemu-xen' code is maintained upstream in the qemu.org git trees. In addition the Xen project also maintains its own stable branch of qemu, based on the upstream stable branches with a small number of additional fixes for Xen. These can be found on xenbits in 'qemu-upstream-VERSION.git' e.g. qemu-upstream-unstable.git, qemu-upstream-4.3-testing.git.

By default the Xen build system will clone and build both versions of Qemu from the branches on xenbits.

Using a distribution supplied version of Qemu

By default Xen will build its own copy of the upstream qemu tree from a branch hosted on xenbits. However it is possible to use Xen with the qemu supplied by the distribution, assuming it is new enough and is compiled with Qemu support.

You can configure this at build time by using:

   ./configure --with-system-qemu=/path/some/qemu-bin/

This will cause the Xen toolstack to use binary when launching qemu. If you specify the 'with-system-qemu' option but do not specify a path then the default will be to call qemu-system-i386 using the system's default search path.

Note that Xen does not use Qemu for processor emulation and therefore makes no distinction between qemu-system-i386 and qemu-system-x86_64, both of which can be used with either 32- or 64-bit guests. By default Xen uses qemu-system-i386.

As well as building Xen with support for the system version of Qemu it is also possible to override the binary to be used via device_model_override field in your xl vm configuration (other toolstacks may or may not expose this option). For example:

   device_model_override = "/usr/bin/qemu-system-x86_64"

Note that it is you responsibility to ensure that 'device_model_version' is set to either 'qemu-xen-traditional' or 'qemu-xen' as appropriate when overriding the binary to use.

Xen build system integration

By default building Xen will cause a suitable version of Qemu to be downloaded and built.

When xen builds qemu

xen will build qemu by default if it is supported on your target.

Where Xen builds qemu

Qemu will build it under the tools/qemu-xen-dir subdirectory of your xen source tree.

How xen builds qemu

When running make when building xen in the xen git tree the enabled qemu targets will be built and by default on x86 and x86_64 two targets are built:

 * CONFIG_QEMU_TRAD: checks out the git tree defined by CONFIG_QEMU
   git://xenbits.xen.org/qemu-xen-unstable.git
 * CONFIG_QEMU_XEN:  checks out the git tree defined by QEMU_UPSTREAM_URL
   git://xenbits.xen.org/qemu-upstream-unstable.git

Overriding QEMU URL and revision

If you'd like to modify the URL so that the another upstream version of qemu is used, and override the branch used you can edit your "xen/.Config.mk" file, for example:

 QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git
 QEMU_UPSTREAM_REVISION = master

Building your own qemu

• Get Xen source from the xen git tree
• Get QEMU upstream source from: qemu git tree
• Build Xen:

   make xen tools

If it fail see below.

• Build QEMU upstream with Xen:

   ./configure --enable-xen --target-list=i386-softmmu \
       --extra-cflags="-I$path_to_xen_source/tools/include -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore" \
       --extra-ldflags="-L$path_to_xen_source/tools/libxc -L$path_to_xen_source/tools/xenstore"
   make

Troubleshooting compilation errors: If you get an error from configure like "ERROR: User requested feature xen ERROR: configure was not able to find it" then see this: http://xen.1045712.n5.nabble.com/Upstream-Qemu-With-Xen-configuration-problem-td4561779.html , ie. you need to point the paths for "configure" to xen source directory, not to xen dist directory.

Use with SeaBIOS

SeaBIOS support is now fully integrated into the Xen build system and is always used when using device_model_version = "qemu-xen".

If you want to build a version of SeaBIOS other than the default then you can override SEABIOS_UPSTREAM_URL and/or SEABIOS_UPSTREAM_TAG via .config. For reference the upstream SeaBIOS repository is [[1]].

New features

VirtIO

It's the PV drivers from KVM world. To use it for network, just use 'virtio-net' as a model:

 vif = [ 'model=virtio-net' ]

You will need those kernel modules to use a VirtIO device

 virtio_mmio virtio_pci virtio_net

SPICE / QXL

SPICE is another remote-display protocol and QXL is a PV framebuffer which uses the best of the SPICE capabilities. To activate SPICE you can add this in the VM config file (this works only with xl).

 spice=1
 spicehost='0.0.0.0'
 spiceport=6000
 spicedisable_ticketing=1

If you wish to use QXL as well you have to add:

 device_model_args_hvm = [ '-vga', 'qxl' ]
 videoram = 128

QXL does not currently work under Xen due to some limitation. (check [this email] for more information.)

Difference with qemu-xen-traditional

Missing feature from the good old qemu-dm

Currently, there is few missing feature that not supported by QEMU upstream, but the work is ongoing.

• VGA passthrough: Sometime (all the time?), simple PCI passthrough does not works for graphics card. The few things that are done in qemu-dm are not yet upstreamed.

New feature from QEMU upstream

There are some benefits from upstreaming the support of Xen to QEMU. We can now use:

• VirtIO as an alternative to Xen PV drivers
• SPICE, as a remote-display protocol instead of the old VNC.
• different kind of file format for a disc.
• the ability to connect several times to the VNC server.
• ...