nyuuzyou/wikis huggingface dataset:
QEMU vs qemu-traditionnal Feature Comparison

Feature comparison of the qemu-traditionnal versus qemu-xen.
Features 	qemu-trad	qemu-xen (v1.6 in Xen 4.4) and newer
Xen support 	 	
PCI passthrough 	 	
Primary VGA passthrough	 	
VNC 	 	
Multiple VNC client 	 	
SPICE 	 	
Stub Domain 	 	
Virtio 	 	
Category:Xen
Category:Users
Category:Compatibility
Qemu-aarch64.patch

diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
 index 670c07a..a451763 100644
 --- a/target/arm/cpu64.c
 +++ b/target/arm/cpu64.c
 @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj)
 cpu->id_isar3 = 0x01112131;
 cpu->id_isar4 = 0x00011142;
 cpu->id_isar5 = 0x00011121;
 - cpu->id_aa64pfr0 = 0x00002222;
 + cpu->id_aa64pfr0 = 0x01002222;
 cpu->id_aa64dfr0 = 0x10305106;
 cpu->pmceid0 = 0x00000000;
 cpu->pmceid1 = 0x00000000;
 @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj)
 cpu->id_isar3 = 0x01112131;
 cpu->id_isar4 = 0x00011142;
 cpu->id_isar5 = 0x00011121;
 - cpu->id_aa64pfr0 = 0x00002222;
 + cpu->id_aa64pfr0 = 0x01002222;
 cpu->id_aa64dfr0 = 0x10305106;
 cpu->id_aa64isar0 = 0x00011120;
 cpu->id_aa64mmfr0 = 0x00001122; /* 40 bit physical addr */
 diff --git a/target/arm/internals.h b/target/arm/internals.h
 index 43106a2..55c70b4 100644
 --- a/target/arm/internals.h
 +++ b/target/arm/internals.h
 @@ -220,7 +220,7 @@ static inline unsigned int arm_pamax(ARMCPU *cpu)
 static inline bool extended_addresses_enabled(CPUARMState *env)
 {
 TCR *tcr = &env->cp15.tcr_el[arm_is_secure(env) ? 3 : 1];
 - return arm_el_is_aa64(env, 1) ||
 + return arm_el_is_aa64(env, arm_current_el(env)) ||
 (arm_feature(env, ARM_FEATURE_LPAE) && (tcr->raw_tcr & TTBCR_EAE));
 }
 
 @@ -428,9 +428,10 @@ static inline uint32_t syn_breakpoint(int same_el)
 | ARM_EL_IL | 0x22;
 }
 
 -static inline uint32_t syn_wfx(int cv, int cond, int ti)
 +static inline uint32_t syn_wfx(int cv, int cond, int ti, bool is_16bit)
 {
 return (EC_WFX_TRAP << ARM_EL_EC_SHIFT) |
 + (is_16bit ? 0 : (1 << ARM_EL_IL_SHIFT)) |
 (cv << 24) | (cond << 20) | ti;
 }
 
 diff --git a/target/arm/op_helper.c b/target/arm/op_helper.c
 index 3914145..ea16c9a 100644
 --- a/target/arm/op_helper.c
 +++ b/target/arm/op_helper.c
 @@ -476,8 +476,8 @@ void HELPER(wfi)(CPUARMState *env)
 }
 
 if (target_el) {
 - env->pc -= 4;
 - raise_exception(env, EXCP_UDEF, syn_wfx(1, 0xe, 0), target_el);
 + env->pc -= env->thumb ? 2 : 4;
 + raise_exception(env, EXCP_UDEF, syn_wfx(1, 0xe, 0, env->thumb), target_el);
 }
 
 cs->exception_index = EXCP_HLT;
Raisin

Build, deployment and test tool for the Xen Project hypervisor.
== Overview ==
The purpose of Raisin is to retrieve and build from source everything
needed for a good Xen installation. Today that includes Xen,
QEMU, Grub, SeaBios, OVMF and Libvirt. It can be used to quickly setup a Xen development
environment. Optionally it can also install and configure the system
for you.
Raisin is meant to be easy to read so that it can be used as a guideline
on how to build and configure the system.
== Quick Start ==
=== 1. Select a Linux Distribution ===
Raisin has been tested on Debian Wheezy, Ubuntu 14.04 LTS, Fedora 21 and CentOS 6 & 7. It is likely that it will work with other distros, but we have not tested it at this stage. If you tried it, and it works, please add the distro to the list above.
=== 2. Install Selected OS ===
We require a specific minimal functionality from your base Linux distribution to make it as easy as possible. We recommend using a minimal install of your chosen distro to get started. You may need to get git and a few other tools using the distros application managers, if the software does not come with the distro by default. All other dependencies are automatically retrieved or pulled from the relevant git repositories and then built.
=== 3. Download Raisin ===
 git clone git://xenbits.xenproject.org/raisin.git
The Raisin repo contains a script that installs builds Xen with all dependencies, configuration files and some tests.
=== 4. Configure ===
 cp defconfig config
We recommend that you review the configuration file called raisin/defconfig, copy it to config, then make changes as necessary. Note that the configuration contains sensible defaults and will work.
=== 5. Start the build and install ===
 cd raisin
 raise -y build
It takes a few minutes, we recommend reading the README file while it is building. Note that you will be asked for the sudo password to install dependencies. If you install them beforehand, manually or executing raise install-builddep, no sudo password will be necessary.
== Resources ==
* README & USAGE
* Git repo
* Raisin intro (mail)
* Raisin intro (blog)
Category:Developers Category:Users
Remus PV domU requirements

Remus supports most domU guests that can be run in PV, however, you may see this warning when you start Remus:
"WARNING: suspend event channel unavailable, falling back to slow xenstore signalling"
This means the kernel in the guest doesn't have "suspend event channel" support, which in turn basically Remus is going to work, but isn't going to perform well. 
* At the time of the Xen 4.5 release, the PVOPS kernel does not support this feature
* At the time of writing, Ubuntu kernels do not generally have suspend event channel support
* On the subject of adding support to a kernel's source, according to the author of Remus, "It is not a config option. It requires some code modification and cannot be selectively enabled, in a clean way."
* The linux-2.6.18-xen.hg kernel from Xen does have support, but is old these days and probably not a great choice
* OpenSUSE natively supports suspend event channel support, and is a good choice for testing
* Yes, this does mean that it's not necessarily easy to start using Remus for production with any given domU in PV
* Note: You can instead run your VM in HVM without requiring this support, if that is an option for you
= References =
* xen-users thread about suspend event channel support: http://www.gossamer-threads.com/lists/xen/users/271981
* See remus suspend event channel in pvops kernel (Aug 2014)
Category:Xen Category:Compatibility Category:Users Category:High_Availability
Remus Toolkit Differences

== Remus in XL ==
=== Xen 4.5 and newer ===
In 4.5 the XM toolstack is not supported any more. Remus is invoked via the "xl remus ..." syntax. This syntax can be found in recent xl man pages for Xen 4.5 (search for the "remus" option). Also see Xen Man Pages, which lists manuals for all Xen releases.
If you work with Xen unstable (development branch), check out xl man pages for unstable
For your convenience, we copied a section of the Xen 4.5 xl man pages for Remus into this page
Usage: xl remus [OPTIONS] domain-id host
OPTIONS
-i MS Checkpoint domain memory every MS milliseconds (default 200ms).
-u Disable memory checkpoint compression.
-s sshcommand Use <sshcommand> instead of ssh. String will be passed to sh. If empty, run <host> instead 
 of ssh <host> xl migrate-receive -r [-e].
-e On the new host, do not wait in the background (on <host>) for the death of the domain. 
 See the corresponding option of the create subcommand.
-N netbufscript Use <netbufscript> to setup network buffering instead of the default script 
 (/etc/xen/scripts/remus-netbuf-setup).
-F Run Remus in unsafe mode. Use this option with caution as failover may not work as intended.
-b Replicate memory checkpoints to /dev/null (blackhole). Generally useful for debugging. 
 Requires enabling unsafe mode.
-n Disable network output buffering. Requires enabling unsafe mode.
-d Disable disk replication. Requires enabling unsafe mode.
=== Xen 4.4. ===
Xenlight is the current toolkit for Xen Project. In xenlight, Remus is invoked via the "xl remus ..." syntax. This syntax can be found in recent xl man pages (search for the "remus" option).
As of 4.4, Remus support in xl is still in experimental (proof-of-concept) phase. Per the man page, there is no support for network or disk buffering in the current release.
== Remus in XM (Xen 4.4 or older) ==
Remus was originally implemented when Xen Project was using the xm toolkit. If you are still using xm, you will need to use the "remus" command to control the software.
The "remus" command uses the following syntax:
 Usage: remus [options] domain [destination]
 Options:
 -h, --help show this help message and exit
 -i MS, --interval=MS checkpoint every MS milliseconds
 -p PORT, --port=PORT send stream to port PORT
 --blackhole replicate to /dev/null (no disk checkpoints, only
 memory & net buffering)
 --no-net run without net buffering (benchmark option)
 --no-compression run without checkpoint compression
 --timer force pause at checkpoint interval (experimental)
Category:High Availability
Category:Xen 4.5
Remus dom0 requirements

__NOTOC__
Remus requires a kernel that can run Xen and also has the following kernel modules:
* sch_plug
* sch_prio
* sch_ingress
* cls_basic
* cls_tcindex
* cls_u32
* act_mirred
* ifb
For testing you can run Remus with '--no-net' if you don't have these modules, but would like to try it out anyways without the networking buffering (see http://nss.cs.ubc.ca/remus/doc.html).
=Known working dom0s=
* Ubuntu 12.10 (tested using 3.5.0-23-generic)
See Install Xen 4.1.4 with Remus and DRBD on Ubuntu 12.10 for a full build example.
=Modern Kernels=
Upstream Linux 3.5+ includes the required modules natively, which can usually be enabled by listing them in /etc/modules. Verify you have each module using 'modprobe' first.
Please note, at the time of writing (Xen 4.1.4 and Xen 4.2.1 being the latest releases), the Xen Remus code needs a patch (supplied by Shriram Rajagopalan) to work correctly with the sch_plug driver built-in to Linux 3.5.
cd /home/user/xen4.1.4 (or xen4.2.1)
wget http://download.locatrix.com/xen/remus-qdisc-py.patch
patch -p1 < remus-qdisc-py.patch
<build/install per normal>
=Older kernels=
== Config options for Linux 2.6.32 pvops dom0 kernel for Remus ==
This is example is based on Linux 2.6.32 pvops (jeremy's xen.git xen/stable-2.6.32.x branch).
These are the .config options required by Remus:
CONFIG_IFB=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_FILTER=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_SCH_PLUG=m
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_MIRRED=m
== Using Linux kernel v3.x (< v3.5) as dom0 kernel for Remus Xen hosts ==
Upstream Linux v3.x kernel (< v3.5) contains Xen pvops dom0 support, but it does not contain "sch_plug" driver which is required for Remus. It's possible to manually add that driver to your custom upstream Linux v3.x kernel build. The "sch_plug" driver is available for example from: http://pasik.reaktio.net/xen/remus/linux3x/ .
Category:Xen Category:Compatibility Category:Users Category:High_Availability
Rump kernel

The rump kernel is a NetBSD project that allows kernel drivers to be repurposed, specifically it allows applications to be linked into standalone unikernels that run on the Xen Project Hypervisor.
Essentially application code, the C library, kernel drivers for the network stack, and Xen Project PV (or HVM) drivers and some Mini-OS boot code are linked into a single executable that can be run directly on the hypervisor without an operating system. The resulting unikernel is small (often a few megabytes), fast to boot, and only contains the minimal dependencies necessary to run.
This is similar to MirageOS, but supports many existing POSIX applications, rather than OCaml applications explicitly targeting MirageOS.
==Resources==
* Documentation and source code is linked from rumpkernel.org.
* The main build tool for building Xen Project applications is rumprun.
* There is an introduction in USENIX ;login: magazine October 2014.
Category:Unikernels
Run PV in PVH container

Xen 4.11 support running of unmodified legacy PV-only guest to be run in PVH mode. This allows users to run old, PV-only distros. This simplifies management and reduces the surface of attack significantly. This makes vulnerabilities in PV interfaces local to guests. Note that slide 15 of this presentation gives an architectural overview of PVH shim.
== Converting a PV config to a PVH shim config ==
* Shutdown VM
* Remove any reference to builder (e.g., builder="generic")
* Add the following two lines:
 type="pvh"
 pvshim=1
* Restart VM
== Converting a PV config to a PVH config ==
* Shutdown VM
* Remove any reference to builder (e.g., builder="generic")
* Add the following line:
 type="pvh"
* Restart VM
Category:Xen 
Category:Users
Category:Xen 4.11
Running XCP/xapi on ARM

This is still under development-- if you have trouble then send an email to the xen-api mailing list.
You will need
* a Cubieboard2 or a Cubietruck
* an SD card which you can flash
First download one of the Mirage pre-built images on your development box:
 wget http://blobs.openmirage.org/cubieboard2.tar
 wget http://blobs.openmirage.org/cubietruck.tar
Untar to reveal the image file itself:
 tar -xvf $FILE.tar
 
Insert your SD card into your development box and discover the device name. You must find the correct device! Don't overwrite the wrong device! You can flash the SD with something like:
 sudo dd if=$FILE.img of=$MY_SD_DEVICE bs=1M
 sudo sync
Eject the SD card and insert it into your Cubie. I recommend attaching the serial console but the image will also advertise itself using multicast DNS as 'cubieboard.local' or 'cubietruck.local'. Power on the cubie and wait for it to boot.
Log into the cubie with mirage/mirage and add 2 new repos:
 cd /etc/apt/sources.list.d
 sudo wget http://xenbits.xenproject.org/djs/linaro-xen-4-4-talex5.list
 sudo wget http://xenbits.xenproject.org/djs/linaro-xapi-4-4-talex5.list
 sudo apt-get update
Now install the xapi toolstack using apt-get:
 sudo apt-get install xenserver-core
Unfortunately xapi (or rather xcp-networkd) doesn't like bridges being made for it, so edit your /etc/network/interfaces to read:
 auto lo
 iface lo inet loopback
 
 auto eth0
 iface eth0 inet dhcp
 up ip link set eth0 up
i.e. remove the 'br0' bridge configuration.
Reboot the Cubie to clear the network state. Note the current kernel has a bug causing reboot to hang. Pull the power (and the serial cable in case you're seeing leakage from it), wait a few seconds and then reinsert.
Log back into the Cubie and run the setup wizard:
 sudo xenserver-install-wizard
Be patient while xapi starts -- if you see some errors on the terminal don't worry. If it fails then run it again: it should be idempotent. If it still doesn't work then email the list.
Now you should be able to run 'sudo xe' and connect XenCenter!
Safety Certification Challenges

This page captures the efforts to certify Xen on ARM for ISO 26262 ASIL B. Discussions happen during the regular Xen on ARM Community Calls organized on xen-devel by Stefano Stabellini and Julien Grall. See for Minutes.
We have identified the following requirements, all of them need an owner:
* Code style requirements, a subset of MISRA
::* Next step (Lars): find public documents that describe the code style requirements and publish them to xen-devel.
* Create a subset of functions that need to go through certification
::* Next step (Stefano): create a small Kconfig for Xen as a reference, using Renesas Rcar as starting point. 
::* Start a discussion on which features we need to have. For instance real time schedulers might be required in some configurations but not all.
* Understand how to address dom0: 
::* We need a plan for a non-Linux dom0. 
::: It looks like FreeRTOS dom0 could be a good option. 
:::* Next step (Artem): Find out more information about FreeRTOS on Xen. Reach out to people that worked on it (Dornerworks? Galois?).
::: An alternative may be a dom0-less option
::: Until now, we discussed this topic under the name of "create multiple guests from device tree". There are no patches (as far as I know), but it was submitted as the Xen on ARM project for Outreachy this year.
::: There are patches for a different project to setup shared memory regions from the xl config file (no need for grant table or xenbus support).
:::* Next step (Praveen Kumar): volunteered to investigate
* Create artifacts, such as docs, fault analysis, prove fault tolerance, safety management docs, document development processes.
::* Next step: find a company or a certification body that would guide us through the process.
Related conversations/minutes
* Re: Xen and safety certification, Minutes of the meeting on Apr 4th
Category:OpenEmbedded
Category:Embedded
Category:Embedded and Automotive
Category:Safety Certification
Scripts/centos-bridge-setup.sh

The following script sets up xen bridges for each eth0 device on a CentOS Dom0
 
#!/bin/bash
default_netdev="NONE"
netdevs=()
function os-get-network-devices()
{
 local line
 
 while read line ; do
	local reg="^default.* dev ([0-9a-zA-Z]*) "
	if [[ $line =~ $reg ]] ; then
	 default_netdev=${BASH_REMATCH[1]}
	fi
	reg="^[0-9./]* dev ([0-9a-zA-Z]*) "
	if [[ $line =~ $reg ]] ; then
	 netdevs=(${netdevs[@]} ${BASH_REMATCH[1]})
	fi
 done < <(ip route show)
}
function centos-host-setup-bridge-c7-tgt() {
 local dev
 local default_con_uuid
 local slave_mac
 local slave_type
 local br="xenbr0"
 os-get-main-network-device var=dev
 
 if [[ ! "$dev" ]]; then
	fail "Couldn't find any active network devices during installation to configure."
 fi
 default_con_uuid=`/usr/bin/nmcli -t --fields UUID,DEVICE con show | grep $dev | awk -F: '{print $1}'`
 slave_mac=`/usr/bin/nmcli dev show $dev | grep HWADDR | awk '{print $2}'`
 slave_type=`/usr/bin/nmcli -t --fields TYPE,DEVICE con show | grep $dev | awk -F: '{print $1}'`
 xinfo "Creating $br"
 /usr/bin/nmcli con add type bridge con-name $br ifname $br
 /usr/bin/nmcli con modify $br bridge.stp no
 /usr/bin/nmcli con modify $br bridge.hello-time 0
 #info "adding $dev to bridge $br"
 #/usr/bin/nmcli con add type bridge-slave con-name $br-slave_$dev ifname $dev master $br
 #/usr/bin/nmcli con modify $br-slave_$dev $slave_type.mac-address $slave_mac
 #stopping the default connection to get hold of default device
 #/usr/bin/nmcli con modify $default_con_uuid connection.autoconnect no
 xinfo "Reconfiguguring $dev"
 # Make sure *any* ethernet-style device gets identified as the main connection
 /usr/bin/nmcli con modify $default_con_uuid connection.interface-name ""
 /usr/bin/nmcli con modify $default_con_uuid connection.master $br connection.slave-type bridge
 xinfo "Restarting network"
 service network restart
}
changed="false"
function make-bridge-for-network
{
 local dev=$1
 local br=$2
 local default_con_uuid
 local slave_mac
 local slave_type
 echo Setting up bridge $br for netdev $dev
 default_con_uuid=$(/usr/bin/nmcli -t --fields UUID,DEVICE con show | grep $dev | awk -F: '{print $1}')
 echo "Creating $br"
 /usr/bin/nmcli con add type bridge con-name $br ifname $br
 /usr/bin/nmcli con modify $br bridge.stp no
 /usr/bin/nmcli con modify $br bridge.hello-time 0
 /usr/bin/nmcli con modify $default_con_uuid connection.master $br connection.slave-type bridge
 changed="true"
}
os-get-network-devices
# Find 'primary' interface, make xenbr0
if [[ ! $default_netdev =~ xenbr* ]] ; then
 make-bridge-for-network $default_netdev xenbr0
else
 echo $default_netdev already set up
fi
# Find other interfaces, make xenbrN
count=0
for netdev in ${netdevs[@]} ; do
 if [[ "$netdev" = "$default_netdev" ]] ; then
	continue
 fi
 if [[ ! $netdev =~ xenbr* ]] ; then
	count=$(($count+1))
	br="xenbr$count"
	make-bridge-for-network $netdev $br
 else
	echo $netdev already set up
 fi
done
if $changed ; then
 echo "Restarting network"
 service network restart
fi
Category:Networking
Scripts/make-mac.sh

The following, is a little script that can be used to assign unique MAC addresses based on the name of a VM and a Xen bridge.
#!/bin/bash
if [[ $# < 1 ]] ; then
 echo "Usage: $0 vmname [bridge]"
 exit 1
fi
name=$1
bridge="xenbr0"
if [[ $# > 1 ]] ; then
 bridge=$2
fi
hmac=$(cat /sys/class/net/${bridge}/address)
if [[ -z "$hmac" ]] ; then
 fail "Couldn't find address for device $bridge"
fi
# Get the host mac, and lop off the first two bytes
mac=$(echo $hmac | sed 's/^..:..:\(.*$\)/\1/;')
# Add an "extension" to the end based on the name
macext=$(echo "$name" | md5sum | sed 's/^\(..\).*$/\1/;')
# And pick a number for the first byte that has bit 2 set ("local")
mac="5a:${mac}:${macext}"
echo $mac
Category:Networking
Setting boot order for domUs

How to change the boot order (boot sequence) in Xen PV and HVM guests.
== HVM guests ==
Use the boot parameter:
# boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot="cda"
Put the letters in order from left to right, the drive corresponding to the first letter on the left is going to be the one that boots first.
For example if you want to boot from cd-rom first, then from the network and lastly from the hard-disk, this is what you need to set your boot parameter to:
boot="dnc"
== PV guests ==
PV guests don't run in an fully emulated environment like HVM guests. As a consequence they don't have a BIOS to boot from the network (pxeboot) or from a cdrom without special configuration.
They can however boot from a user provided kernel or from one of the kernels installed in the VM disk image.
And in many cases they can in fact boot from network or a cdrom.
=== boot from a user specified kernel ===
You just need to pass the right kernel and initrd parameters:
# Kernel image to boot
kernel = "/boot/vmlinuz"
# Ramdisk (optional)
ramdisk = "/boot/initrd.gz"
You can also pass an extra parameter to specify the kernel command line, that allows you to choose the root disk:
# Kernel command line options
extra = "root=/dev/xvda1"
=== boot from a kernel installed in the VM disk ===
You need to add the following two lines to the VM config file:
bootloader = '/usr/bin/pygrub'
extra = "(hd0)/boot/grub/menu.lst"
Make sure you pass -c to xl create to connect to the guest's console right away.
=== network boot solutions and workarounds ===
==== Xenpvnetboot ====
You can use Xenpvnetboot.
It supports many schemes for fetching the kernel.
==== pypxeboot ====
The older solution for this is pypxeboot, which can be found i.e. here:
https://github.com/blamarvt/pypxeboot with documentation to be found at http://zhigang.org/files/docbook/xen-pxeboot.html
This only works with the deprecated xm toolstack and should not be used for newer systems.
It looks for a dhcp server, requests a kernel info via PXE and then launches the VM with the kernel received.
If the kernel from PXE is invalid, or not was offered, it will do local boot using pygrub.
The advantages were it being PXE compatible and supporting fall-through to local disk. (This means it works like a normal BIOS boot order would)
==== xl create wrapper ====
Otherwise you can write yourself a simple wrapper script that:
* gets the kernel and initrd from the network;
* updates the kernel and initrd parameters in the VM config file;
* calls 'xl create config-file.
Note this will not fetch a new kernel / command line on reboot. you may need to use on_reboot = destroy and handle VM restarts from your script.
If you're going that route, expect some extra work and consider dynamically creating the VM configs all the time.
Category:Xen
Category:Users
Category:HowTo