.\" Automatically generated by Pod::Man 2.28 (Pod::Simple 3.28) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is turned on, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{ . if \nF \{ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. . \" fudge factors for nroff and troff .if n \{\ . ds #H 0 . ds #V .8m . ds #F .3m . ds #[ \f1 . ds #] \fP .\} .if t \{\ . ds #H ((1u-(\\\\n(.fu%2u))*.13m) . ds #V .6m . ds #F 0 . ds #[ \& . ds #] \& .\} . \" simple accents for nroff and troff .if n \{\ . ds ' \& . ds ` \& . ds ^ \& . ds , \& . ds ~ ~ . ds / .\} .if t \{\ . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' .\} . \" troff and (daisy-wheel) nroff accents .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' .ds 8 \h'\*(#H'\(*b\h'-\*(#H' .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] .ds ae a\h'-(\w'a'u*4/10)'e .ds Ae A\h'-(\w'A'u*4/10)'E . \" corrections for vroff .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' . \" for low resolution devices (crt and lpr) .if \n(.H>23 .if \n(.V>19 \ \{\ . ds : e . ds 8 ss . ds o a . ds d- d\h'-1'\(ga . ds D- D\h'-1'\(hy . ds th \o'bp' . ds Th \o'LP' . ds ae ae . ds Ae AE .\} .rm #[ #] #H #V #F C .\" ======================================================================== .\" .IX Title "xl.cfg 5" .TH xl.cfg 5 "2017-09-05" "4.4.1" "Xen" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "NAME" xl.cfg \- XL Domain Configuration File Syntax .SH "SYNOPSIS" .IX Header "SYNOPSIS" .Vb 1 \& /etc/xen/xldomain .Ve .SH "DESCRIPTION" .IX Header "DESCRIPTION" To create a \s-1VM \s0(a domain in Xen terminology, sometimes called a guest) with xl requires the provision of a domain config file. Typically these live in `/etc/xen/DOMAIN.cfg` where \s-1DOMAIN\s0 is the name of the domain. .SH "SYNTAX" .IX Header "SYNTAX" A domain config file consists of a series of \f(CW\*(C`KEY=VALUE\*(C'\fR pairs. .PP Some \f(CW\*(C`KEY\*(C'\fRs are mandatory, others are general options which apply to any guest type while others relate only to specific guest types (e.g. \s-1PV\s0 or \s-1HVM\s0 guests). .PP A value \f(CW\*(C`VALUE\*(C'\fR is one of: .ie n .IP "\fB""\s-1STRING""\s0\fR" 4 .el .IP "\fB``\s-1STRING''\s0\fR" 4 .IX Item "STRING" A string, surrounded by either single or double quotes. .IP "\fB\s-1NUMBER\s0\fR" 4 .IX Item "NUMBER" A number, in either decimal, octal (using a \f(CW0\fR prefix) or hexadecimal (using an \f(CW\*(C`0x\*(C'\fR prefix). .IP "\fB\s-1BOOLEAN\s0\fR" 4 .IX Item "BOOLEAN" A \f(CW\*(C`NUMBER\*(C'\fR interpreted as \f(CW\*(C`False\*(C'\fR (\f(CW0\fR) or \f(CW\*(C`True\*(C'\fR (any other value). .IP "\fB[ \s-1VALUE, VALUE, ... \s0]\fR" 4 .IX Item "[ VALUE, VALUE, ... ]" A list of \f(CW\*(C`VALUES\*(C'\fR of the above types. Lists are homogeneous and are not nested. .PP The semantics of each \f(CW\*(C`KEY\*(C'\fR defines which form of \f(CW\*(C`VALUE\*(C'\fR is required. .SH "OPTIONS" .IX Header "OPTIONS" .SS "Mandatory Configuration Items" .IX Subsection "Mandatory Configuration Items" The following key is mandatory for any guest type: .ie n .IP "\fBname=""\s-1NAME""\s0\fR" 4 .el .IP "\fBname=``\s-1NAME''\s0\fR" 4 .IX Item "name=NAME" Specifies the name of the domain. Names of domains existing on a single host must be unique. .SS "Selecting Guest Type" .IX Subsection "Selecting Guest Type" .ie n .IP "\fBbuilder=""generic""\fR" 4 .el .IP "\fBbuilder=``generic''\fR" 4 .IX Item "builder=generic" Specifies that this is to be a \s-1PV\s0 domain. This is the default. .ie n .IP "\fBbuilder=""hvm""\fR" 4 .el .IP "\fBbuilder=``hvm''\fR" 4 .IX Item "builder=hvm" Specifies that this is to be an \s-1HVM\s0 domain. That is, a fully virtualised computer with emulated \s-1BIOS,\s0 disk and network peripherals, etc. The default is a \s-1PV\s0 domain, suitable for hosting Xen-aware guest operating systems. .SS "General Options" .IX Subsection "General Options" The following options apply to guests of any type. .PP \fI\s-1CPU\s0 Allocation\fR .IX Subsection "CPU Allocation" .ie n .IP "\fBpool=""\s-1CPUPOOLNAME""\s0\fR" 4 .el .IP "\fBpool=``\s-1CPUPOOLNAME''\s0\fR" 4 .IX Item "pool=CPUPOOLNAME" Put the guest's vcpus into the named cpu pool. .IP "\fBvcpus=N\fR" 4 .IX Item "vcpus=N" Start the guest with N vcpus initially online. .IP "\fBmaxvcpus=M\fR" 4 .IX Item "maxvcpus=M" Allow the guest to bring up a maximum of M vcpus. At start of day if `vcpus=N` is less than `maxvcpus=M` then the first `N` vcpus will be created online and the remainder will be offline. .ie n .IP "\fBcpus=""\s-1CPU\-LIST""\s0\fR" 4 .el .IP "\fBcpus=``\s-1CPU\-LIST''\s0\fR" 4 .IX Item "cpus=CPU-LIST" List of which cpus the guest is allowed to use. Default is no pinning at all (more on this below). A \f(CW\*(C`CPU\-LIST\*(C'\fR may be specified as follows: .RS 4 .ie n .IP """all""" 4 .el .IP "``all''" 4 .IX Item "all" To allow all the vcpus of the guest to run on all the cpus on the host. .ie n .IP """0\-3,5,^1""" 4 .el .IP "``0\-3,5,^1''" 4 .IX Item "0-3,5,^1" To allow all the vcpus of the guest to run on cpus 0,2,3,5. Combining this with \*(L"all\*(R" is possible, meaning \*(L"all,^7\*(R" results in all the vcpus of the guest running on all the cpus on the host except cpu 7. .ie n .IP """nodes:0\-3,node:^2""" 4 .el .IP "``nodes:0\-3,node:^2''" 4 .IX Item "nodes:0-3,node:^2" To allow all the vcpus of the guest to run on the cpus from \s-1NUMA\s0 nodes 0,1,3 of the host. So, if cpus 0\-3 belongs to node 0, cpus 4\-7 belongs to node 1 and cpus 8\-11 to node 3, the above would mean all the vcpus of the guest will run on cpus 0\-3,8\-11. .Sp Combining this notation with the one above is possible. For instance, \&\*(L"1,node:2,^6\*(R", means all the vcpus of the guest will run on cpu 1 and on all the cpus of \s-1NUMA\s0 node 2, but not on cpu 6. Following the same example as above, that would be cpus 1,4,5,7. .Sp Combining this with \*(L"all\*(R" is also possible, meaning \*(L"all,^nodes:1\*(R" results in all the vcpus of the guest running on all the cpus on the host, except for the cpus belonging to the host \s-1NUMA\s0 node 1. .ie n .IP "[""2"", ""3""] (or [2, 3])" 4 .el .IP "[``2'', ``3''] (or [2, 3])" 4 .IX Item "[2, 3] (or [2, 3])" To ask for specific vcpu mapping. That means (in this example), vcpu #0 of the guest will run on cpu #2 of the host and vcpu #1 of the guest will run on cpu #3 of the host. .RE .RS 4 .Sp If this option is not specified, no vcpu to cpu pinning is established, and the vcpus of the guest can run on all the cpus of the host. .Sp If we are on a \s-1NUMA\s0 machine (i.e., if the host has more than one \s-1NUMA\s0 node) and this option is not specified, libxl automatically tries to place the guest on the least possible number of nodes. That, however, will not affect vcpu pinning, so the guest will still be able to run on all the cpus, it will just prefer the ones from the node it has been placed on. A heuristic approach is used for choosing the best node (or set of nodes), with the goals of maximizing performance for the guest and, at the same time, achieving efficient utilization of host cpus and memory. See \fIdocs/misc/xl\-numa\-placement.markdown\fR for more details. .RE .PP \fI\s-1CPU\s0 Scheduling\fR .IX Subsection "CPU Scheduling" .IP "\fBcpu_weight=WEIGHT\fR" 4 .IX Item "cpu_weight=WEIGHT" A domain with a weight of 512 will get twice as much \s-1CPU\s0 as a domain with a weight of 256 on a contended host. Legal weights range from 1 to 65535 and the default is 256. Honoured by the credit, credit2 and sedf schedulers. .IP "\fBcap=N\fR" 4 .IX Item "cap=N" The cap optionally fixes the maximum amount of \s-1CPU\s0 a domain will be able to consume, even if the host system has idle \s-1CPU\s0 cycles. The cap is expressed in percentage of one physical \s-1CPU: 100\s0 is 1 physical \s-1CPU, 50\s0 is half a \s-1CPU, 400\s0 is 4 CPUs, etc. The default, 0, means there is no upper cap. Honoured by the credit and credit2 schedulers. .Sp \&\s-1NB:\s0 Many systems have features that will scale down the computing power of a cpu that is not 100% utilized. This can be in the operating system, but can also sometimes be below the operating system in the \s-1BIOS. \s0 If you set a cap such that individual cores are running at less than 100%, this may have an impact on the performance of your workload over and above the impact of the cap. For example, if your processor runs at 2GHz, and you cap a vm at 50%, the power management system may also reduce the clock speed to 1GHz; the effect will be that your \s-1VM\s0 gets 25% of the available power (50% of 1GHz) rather than 50% (50% of 2GHz). If you are not getting the performance you expect, look at performance and cpufreq options in your operating system and your \s-1BIOS.\s0 .IP "\fBperiod=NANOSECONDS\fR" 4 .IX Item "period=NANOSECONDS" The normal \s-1EDF\s0 scheduling usage in nanoseconds. This means every period the domain gets cpu time defined in slice. Honoured by the sedf scheduler. .IP "\fBslice=NANOSECONDS\fR" 4 .IX Item "slice=NANOSECONDS" The normal \s-1EDF\s0 scheduling usage in nanoseconds. it defines the time a domain get every period time. Honoured by the sedf scheduler. .IP "\fBlatency=N\fR" 4 .IX Item "latency=N" Scaled period if domain is doing heavy I/O. Honoured by the sedf scheduler. .IP "\fBextratime=BOOLEAN\fR" 4 .IX Item "extratime=BOOLEAN" Flag for allowing domain to run in extra time. Honoured by the sedf scheduler. .PP \fIMemory Allocation\fR .IX Subsection "Memory Allocation" .IP "\fBmemory=MBYTES\fR" 4 .IX Item "memory=MBYTES" Start the guest with \s-1MBYTES\s0 megabytes of \s-1RAM.\s0 .IP "\fBmaxmem=MBYTES\fR" 4 .IX Item "maxmem=MBYTES" Specifies the maximum amount of memory a guest can ever see. The value of \fBmaxmem=\fR must be equal or greater than \fBmemory=\fR. .Sp In combination with \fBmemory=\fR it will start the guest \*(L"pre-ballooned\*(R", if the values of \fBmemory=\fR and \fBmaxmem=\fR differ. A \*(L"pre-ballooned\*(R" \s-1HVM\s0 guest needs a balloon driver, without a balloon driver it will crash. .PP \fIEvent Actions\fR .IX Subsection "Event Actions" .ie n .IP "\fBon_poweroff=""\s-1ACTION""\s0\fR" 4 .el .IP "\fBon_poweroff=``\s-1ACTION''\s0\fR" 4 .IX Item "on_poweroff=ACTION" Specifies what should be done with the domain if it shuts itself down. The \f(CW\*(C`ACTION\*(C'\fRs are: .RS 4 .IP "\fBdestroy\fR" 4 .IX Item "destroy" destroy the domain .IP "\fBrestart\fR" 4 .IX Item "restart" destroy the domain and immediately create a new domain with the same configuration .IP "\fBrename-restart\fR" 4 .IX Item "rename-restart" rename the domain which terminated, and then immediately create a new domain with the same configuration as the original .IP "\fBpreserve\fR" 4 .IX Item "preserve" keep the domain. It can be examined, and later destroyed with `xl destroy`. .IP "\fBcoredump-destroy\fR" 4 .IX Item "coredump-destroy" write a \*(L"coredump\*(R" of the domain to \fI/var/lib/xen/dump/NAME\fR and then destroy the domain. .IP "\fBcoredump-restart\fR" 4 .IX Item "coredump-restart" write a \*(L"coredump\*(R" of the domain to \fI/var/lib/xen/dump/NAME\fR and then restart the domain. .RE .RS 4 .Sp The default for \f(CW\*(C`on_poweroff\*(C'\fR is \f(CW\*(C`destroy\*(C'\fR. .RE .ie n .IP "\fBon_reboot=""\s-1ACTION""\s0\fR" 4 .el .IP "\fBon_reboot=``\s-1ACTION''\s0\fR" 4 .IX Item "on_reboot=ACTION" Action to take if the domain shuts down with a reason code requesting a reboot. Default is \f(CW\*(C`restart\*(C'\fR. .ie n .IP "\fBon_watchdog=""\s-1ACTION""\s0\fR" 4 .el .IP "\fBon_watchdog=``\s-1ACTION''\s0\fR" 4 .IX Item "on_watchdog=ACTION" Action to take if the domain shuts down due to a Xen watchdog timeout. Default is \f(CW\*(C`destroy\*(C'\fR. .ie n .IP "\fBon_crash=""\s-1ACTION""\s0\fR" 4 .el .IP "\fBon_crash=``\s-1ACTION''\s0\fR" 4 .IX Item "on_crash=ACTION" Action to take if the domain crashes. Default is \f(CW\*(C`destroy\*(C'\fR. .PP \fIOther Options\fR .IX Subsection "Other Options" .ie n .IP "\fBuuid=""\s-1UUID""\s0\fR" 4 .el .IP "\fBuuid=``\s-1UUID''\s0\fR" 4 .IX Item "uuid=UUID" Specifies the \s-1UUID\s0 of the domain. If not specified, a fresh unique \&\s-1UUID\s0 will be generated. .ie n .IP "\fBseclabel=""\s-1LABEL""\s0\fR" 4 .el .IP "\fBseclabel=``\s-1LABEL''\s0\fR" 4 .IX Item "seclabel=LABEL" Assign an \s-1XSM\s0 security label to this domain. .ie n .IP "\fBinit_seclabel=""\s-1LABEL""\s0\fR" 4 .el .IP "\fBinit_seclabel=``\s-1LABEL''\s0\fR" 4 .IX Item "init_seclabel=LABEL" Specify an \s-1XSM\s0 security label used for this domain temporarily during its build. The domain's \s-1XSM\s0 label will be changed to the execution seclabel (specified by \*(L"seclabel\*(R") once the build is complete, prior to unpausing the domain. With a properly constructed security policy (such as nomigrate_t in the example policy), this can be used to build a domain whose memory is not accessible to the toolstack domain. .IP "\fBnomigrate=BOOLEAN\fR" 4 .IX Item "nomigrate=BOOLEAN" Disable migration of this domain. This enables certain other features which are incompatible with migration. Currently this is limited to enabling the invariant \s-1TSC\s0 feature flag in cpuid results when \s-1TSC\s0 is not emulated. .IP "\fBdriver_domain=BOOLEAN\fR" 4 .IX Item "driver_domain=BOOLEAN" Specify that this domain is a driver domain. This enables certain features needed in order to run a driver domain. .SS "Devices" .IX Subsection "Devices" The following options define the paravirtual, emulated and physical devices which the guest will contain. .ie n .IP "\fBdisk=[ ""\s-1DISK_SPEC_STRING"", ""DISK_SPEC_STRING"", ...\s0]\fR" 4 .el .IP "\fBdisk=[ ``\s-1DISK_SPEC_STRING'', ``DISK_SPEC_STRING'', ...\s0]\fR" 4 .IX Item "disk=[ DISK_SPEC_STRING, DISK_SPEC_STRING, ...]" Specifies the disks (both emulated disks and Xen virtual block devices) which are to be provided to the guest, and what objects on the they should map to. See \fIdocs/misc/xl\-disk\-configuration.txt\fR. .ie n .IP "\fBvif=[ ""\s-1NET_SPEC_STRING"", ""NET_SPEC_STRING"", ...\s0]\fR" 4 .el .IP "\fBvif=[ ``\s-1NET_SPEC_STRING'', ``NET_SPEC_STRING'', ...\s0]\fR" 4 .IX Item "vif=[ NET_SPEC_STRING, NET_SPEC_STRING, ...]" Specifies the networking provision (both emulated network adapters, and Xen virtual interfaces) to provided to the guest. See \&\fIdocs/misc/xl\-network\-configuration.markdown\fR. .ie n .IP "\fBvtpm=[ ""\s-1VTPM_SPEC_STRING"", ""VTPM_SPEC_STRING"", ...\s0]\fR" 4 .el .IP "\fBvtpm=[ ``\s-1VTPM_SPEC_STRING'', ``VTPM_SPEC_STRING'', ...\s0]\fR" 4 .IX Item "vtpm=[ VTPM_SPEC_STRING, VTPM_SPEC_STRING, ...]" Specifies the virtual trusted platform module to be provided to the guest. Please see \fIdocs/misc/vtpm.txt\fR for more details. .Sp Each \fB\s-1VTPM_SPEC_STRING\s0\fR is a comma-separated list of \f(CW\*(C`KEY=VALUE\*(C'\fR settings, from the following list: .RS 4 .ie n .IP """backend=DOMAIN""" 4 .el .IP "\f(CWbackend=DOMAIN\fR" 4 .IX Item "backend=DOMAIN" Specify the backend domain name of id. This value is required! If this domain is a guest, the backend should be set to the vtpm domain name. If this domain is a vtpm, the backend should be set to the vtpm manager domain name. .ie n .IP """uuid=UUID""" 4 .el .IP "\f(CWuuid=UUID\fR" 4 .IX Item "uuid=UUID" Specify the uuid of this vtpm device. The uuid is used to uniquely identify the vtpm device. You can create one using the uuidgen program on unix systems. If left unspecified, a new uuid will be randomly generated every time the domain boots. If this is a vtpm domain, you should specify a value. The value is optional if this is a guest domain. .RE .RS 4 .RE .ie n .IP "\fBvfb=[ ""\s-1VFB_SPEC_STRING"", ""VFB_SPEC_STRING"", ...\s0]\fR" 4 .el .IP "\fBvfb=[ ``\s-1VFB_SPEC_STRING'', ``VFB_SPEC_STRING'', ...\s0]\fR" 4 .IX Item "vfb=[ VFB_SPEC_STRING, VFB_SPEC_STRING, ...]" Specifies the paravirtual framebuffer devices which should be supplied to the domain. .Sp This options does not control the emulated graphics card presented to an \s-1HVM\s0 guest. See \*(L"Emulated \s-1VGA\s0 Graphics Device\*(R" below for how to configure the emulated device. If \*(L"Emulated \s-1VGA\s0 Graphics Device\*(R" options are used in a \s-1PV\s0 guest configuration, xl will pick up \fBvnc\fR, \fBvnclisten\fR, \&\fBvncpasswd\fR, \fBvncdisplay\fR and \fBvncunused\fR to construct paravirtual framebuffer device for the guest. .Sp Each \fB\s-1VFB_SPEC_STRING\s0\fR is a comma-separated list of \f(CW\*(C`KEY=VALUE\*(C'\fR settings, from the following list: .RS 4 .ie n .IP """vnc=BOOLEAN""" 4 .el .IP "\f(CWvnc=BOOLEAN\fR" 4 .IX Item "vnc=BOOLEAN" Allow access to the display via the \s-1VNC\s0 protocol. This enables the other VNC-related settings. The default is to enable this. .ie n .IP """vnclisten=""ADDRESS[:DISPLAYNUM]""""" 4 .el .IP "\f(CWvnclisten=``ADDRESS[:DISPLAYNUM]''\fR" 4 .IX Item "vnclisten=""ADDRESS[:DISPLAYNUM]""" Specifies the \s-1IP\s0 address, and optionally \s-1VNC\s0 display number, to use. .Sp \&\s-1NB\s0 that if you specify the display number here, you should not use vncdisplay. .ie n .IP """vncdisplay=DISPLAYNUM""" 4 .el .IP "\f(CWvncdisplay=DISPLAYNUM\fR" 4 .IX Item "vncdisplay=DISPLAYNUM" Specifies the \s-1VNC\s0 display number to use. The actual \s-1TCP\s0 port number will be \s-1DISPLAYNUM+5900.\s0 .Sp \&\s-1NB\s0 that you should not use this option if you set the displaynum in the vnclisten string. .ie n .IP """vncunused=BOOLEAN""" 4 .el .IP "\f(CWvncunused=BOOLEAN\fR" 4 .IX Item "vncunused=BOOLEAN" Requests that the \s-1VNC\s0 display setup search for a free \s-1TCP\s0 port to use. The actual display used can be accessed with \f(CW\*(C`xl vncviewer\*(C'\fR. .ie n .IP """vncpasswd=""PASSWORD""""" 4 .el .IP "\f(CWvncpasswd=``PASSWORD''\fR" 4 .IX Item "vncpasswd=""PASSWORD""" Specifies the password for the \s-1VNC\s0 server. .ie n .IP """sdl=BOOLEAN""" 4 .el .IP "\f(CWsdl=BOOLEAN\fR" 4 .IX Item "sdl=BOOLEAN" Specifies that the display should be presented via an X window (using Simple DirectMedia Layer). The default is to not enable this mode. .ie n .IP """display=DISPLAY""" 4 .el .IP "\f(CWdisplay=DISPLAY\fR" 4 .IX Item "display=DISPLAY" Specifies the X Window display that should be used when the sdl option is used. Note: passing this value to the device-model is not currently implemented, so providing this option will have no effect. .ie n .IP """xauthority=XAUTHORITY""" 4 .el .IP "\f(CWxauthority=XAUTHORITY\fR" 4 .IX Item "xauthority=XAUTHORITY" Specifies the path to the X authority file that should be used to connect to the X server when the sdl option is used. Note: passing this value to the device-model is not currently implemented, so providing this option will have no effect. .ie n .IP """opengl=BOOLEAN""" 4 .el .IP "\f(CWopengl=BOOLEAN\fR" 4 .IX Item "opengl=BOOLEAN" Enable OpenGL acceleration of the \s-1SDL\s0 display. Only effects machines using \f(CW\*(C`device_model_version="qemu\-xen\-traditional"\*(C'\fR and only if the device-model was compiled with OpenGL support. Disabled by default. .ie n .IP """keymap=""LANG""""" 4 .el .IP "\f(CWkeymap=``LANG''\fR" 4 .IX Item "keymap=""LANG""" Configure the keymap to use for the keyboard associated with this display. If the input method does not easily support raw keycodes (e.g. this is often the case when using \s-1VNC\s0) then this allows us to correctly map the input keys into keycodes seen by the guest. The specific values which are accepted are defined by the version of the device-model which you are using. See \*(L"Keymaps\*(R" below or consult the \&\fIqemu\fR\|(1) manpage. The default is \fBen-us\fR. .RE .RS 4 .RE .ie n .IP "\fBpci=[ ""\s-1PCI_SPEC_STRING"", ""PCI_SPEC_STRING"", ... \s0]\fR" 4 .el .IP "\fBpci=[ ``\s-1PCI_SPEC_STRING'', ``PCI_SPEC_STRING'', ... \s0]\fR" 4 .IX Item "pci=[ PCI_SPEC_STRING, PCI_SPEC_STRING, ... ]" Specifies the host \s-1PCI\s0 devices to passthrough to this guest. Each \fB\s-1PCI_SPEC_STRING\s0\fR has the form \f(CW\*(C`[DDDD:]BB:DD.F[@VSLOT],KEY=VALUE,KEY=VALUE,...\*(C'\fR where: .RS 4 .IP "\fB\s-1DDDD:BB:DD.F\s0\fR" 4 .IX Item "DDDD:BB:DD.F" Identifies the \s-1PCI\s0 device from the host perspective in domain (\fB\s-1DDDD\s0\fR), Bus (\fB\s-1BB\s0\fR), Device (\fB\s-1DD\s0\fR) and Function (\fBF\fR) syntax. This is the same scheme as used in the output of \f(CW\*(C`lspci\*(C'\fR for the device in question. Note: By default \f(CW\*(C`lspci\*(C'\fR will omit the domain (\fB\s-1DDDD\s0\fR) if it is zero and it is optional here also. You may specify the function (\fBF\fR) as \fB*\fR to indicate all functions. .ie n .IP "\fB\fB@VSLOT\fB\fR" 4 .el .IP "\fB\f(CB@VSLOT\fB\fR" 4 .IX Item "@VSLOT" Specifies the virtual device where the guest will see this device. This is equivalent to the \fB\s-1DD\s0\fR which the guest sees. In a guest \fB\s-1DDDD\s0\fR and \fB\s-1BB\s0\fR are \f(CW\*(C`0000:00\*(C'\fR. .IP "\fBKEY=VALUE\fR" 4 .IX Item "KEY=VALUE" Possible \fB\s-1KEY\s0\fRs are: .RS 4 .IP "\fBpermissive=BOOLEAN\fR" 4 .IX Item "permissive=BOOLEAN" (\s-1PV\s0 only) By default pciback only allows \s-1PV\s0 guests to write \*(L"known safe\*(R" values into \s-1PCI\s0 config space. But many devices require writes to other areas of config space in order to operate properly. This tells the pciback driver to allow all writes to \s-1PCI\s0 config space of this device by this domain. This option should be enabled with caution: it gives the guest much more control over the device, which may have security or stability implications. It is recommended to enable this option only for trusted VMs under administrator control. .IP "\fBmsitranslate=BOOLEAN\fR" 4 .IX Item "msitranslate=BOOLEAN" Specifies that MSI-INTx translation should be turned on for the \s-1PCI\s0 device. When enabled, MSI-INTx translation will always enable \s-1MSI\s0 on the \s-1PCI\s0 device regardless whether the guest uses INTx or \s-1MSI.\s0 Some device drivers, such as \s-1NVIDIA\s0's, detect an inconsistency and do not function when this option is enabled. Therefore the default is false (0). .IP "\fBpower_mgmt=BOOLEAN\fR" 4 .IX Item "power_mgmt=BOOLEAN" (\s-1HVM\s0 only) Specifies that the \s-1VM\s0 should be able to program the D0\-D3hot power management states for the \s-1PCI\s0 device. False (0) by default. .RE .RS 4 .RE .RE .RS 4 .RE .IP "\fBpci_permissive=BOOLEAN\fR" 4 .IX Item "pci_permissive=BOOLEAN" (\s-1PV\s0 only) Changes the default value of 'permissive' for all \s-1PCI\s0 devices passed through to this \s-1VM.\s0 See permissive above. .IP "\fBpci_msitranslate=BOOLEAN\fR" 4 .IX Item "pci_msitranslate=BOOLEAN" Changes the default value of 'msitranslate' for all \s-1PCI\s0 devices passed through to this \s-1VM.\s0 See msitranslate above. .IP "\fBpci_power_mgmt=BOOLEAN\fR" 4 .IX Item "pci_power_mgmt=BOOLEAN" (\s-1HVM\s0 only) Changes the default value of 'power_mgmt' for all \s-1PCI\s0 devices passed through to this \s-1VM.\s0 See power_mgt above. .IP "\fBgfx_passthru=BOOLEAN\fR" 4 .IX Item "gfx_passthru=BOOLEAN" Enable graphics device \s-1PCI\s0 passthrough. This option makes an assigned \&\s-1PCI\s0 graphics card become primary graphics card in the \s-1VM.\s0 The \s-1QEMU\s0 emulated graphics adapter is disabled and the \s-1VNC\s0 console for the \s-1VM\s0 will not have any graphics output. All graphics output, including boot time \s-1QEMU BIOS\s0 messages from the \s-1VM,\s0 will go to the physical outputs of the passedthrough physical graphics card. .Sp The graphics card \s-1PCI\s0 device to passthrough is chosen with \fBpci\fR option, exactly in the same way as normal Xen \s-1PCI\s0 device passthrough/assignment is done. Note that gfx_passthru does not do any kind of sharing of the \s-1GPU,\s0 so you can only assign the \s-1GPU\s0 to one single \s-1VM\s0 at a time. .Sp gfx_passthru also enables various legacy \s-1VGA\s0 memory ranges, BARs, MMIOs, and ioports to be passed thru to the \s-1VM,\s0 since those are required for correct operation of things like \s-1VGA BIOS,\s0 text mode, \s-1VBE,\s0 etc. .Sp Enabling gfx_passthru option also copies the physical graphics card video \s-1BIOS\s0 to the guest memory, and executes the \s-1VBIOS\s0 in the guest to initialize the graphics card. .Sp Most graphics adapters require vendor specific tweaks for properly working graphics passthrough. See the XenVGAPassthroughTestedAdapters wiki page for currently supported graphics cards for gfx_passthru. .Sp gfx_passthru is currently only supported with the qemu-xen-traditional device-model. Upstream qemu-xen device-model currently does not have support for gfx_passthru. .Sp Note that some graphics adapters (\s-1AMD/ATI\s0 cards, for example) do not necessarily require gfx_passthru option, so you can use the normal Xen \&\s-1PCI\s0 passthrough to assign the graphics card as a secondary graphics card to the \s-1VM.\s0 The QEMU-emulated graphics card remains the primary graphics card, and \s-1VNC\s0 output is available from the QEMU-emulated primary adapter. .Sp More information about Xen gfx_passthru feature is available on the XenVGAPassthrough wiki page. .ie n .IP "\fBioports=[ ""\s-1IOPORT_RANGE"", ""IOPORT_RANGE"", ... \s0]\fR" 4 .el .IP "\fBioports=[ ``\s-1IOPORT_RANGE'', ``IOPORT_RANGE'', ... \s0]\fR" 4 .IX Item "ioports=[ IOPORT_RANGE, IOPORT_RANGE, ... ]" Allow guest to access specific legacy I/O ports. Each \fB\s-1IOPORT_RANGE\s0\fR is given in hexadecimal and may either a span e.g. \f(CW\*(C`2f8\-2ff\*(C'\fR (inclusive) or a single I/O port \f(CW\*(C`2f8\*(C'\fR. .Sp It is recommended to use this option only for trusted VMs under administrator control. .ie n .IP "\fBiomem=[ ""\s-1IOMEM_START,NUM_PAGES"", ""IOMEM_START,NUM_PAGES"", ... \s0]\fR" 4 .el .IP "\fBiomem=[ ``\s-1IOMEM_START,NUM_PAGES'', ``IOMEM_START,NUM_PAGES'', ... \s0]\fR" 4 .IX Item "iomem=[ IOMEM_START,NUM_PAGES, IOMEM_START,NUM_PAGES, ... ]" Allow guest to access specific hardware I/O memory pages. \fB\s-1IOMEM_START\s0\fR is a physical page number. \fB\s-1NUM_PAGES\s0\fR is the number of pages beginning with \fB\s-1START_PAGE\s0\fR to allow access. Both values must be given in hexadecimal. .Sp It is recommended to use this option only for trusted VMs under administrator control. .IP "\fBirqs=[ \s-1NUMBER, NUMBER, ... \s0]\fR" 4 .IX Item "irqs=[ NUMBER, NUMBER, ... ]" Allow a guest to access specific physical IRQs. .Sp It is recommended to use this option only for trusted VMs under administrator control. .IP "\fBmax_event_channels=N\fR" 4 .IX Item "max_event_channels=N" Limit the guest to using at most N event channels (\s-1PV\s0 interrupts). Guests use hypervisor resources for each event channel they use. .Sp The default of 1023 should be sufficient for typical guests. The maximum value depends what the guest supports. Guests supporting the FIFO-based event channel \s-1ABI\s0 support up to 131,071 event channels. Other guests are limited to 4095 (64\-bit x86 and \s-1ARM\s0) or 1023 (32\-bit x86). .SS "Paravirtualised (\s-1PV\s0) Guest Specific Options" .IX Subsection "Paravirtualised (PV) Guest Specific Options" The following options apply only to Paravirtual guests. .ie n .IP "\fBkernel=""\s-1PATHNAME""\s0\fR" 4 .el .IP "\fBkernel=``\s-1PATHNAME''\s0\fR" 4 .IX Item "kernel=PATHNAME" Load the specified file as the kernel image. Either \fBkernel\fR or \&\fBbootloader\fR must be specified for \s-1PV\s0 guests. .ie n .IP "\fBramdisk=""\s-1PATHNAME""\s0\fR" 4 .el .IP "\fBramdisk=``\s-1PATHNAME''\s0\fR" 4 .IX Item "ramdisk=PATHNAME" Load the specified file as the ramdisk. .ie n .IP "\fBbootloader=""\s-1PROGRAM""\s0\fR" 4 .el .IP "\fBbootloader=``\s-1PROGRAM''\s0\fR" 4 .IX Item "bootloader=PROGRAM" Run \f(CW\*(C`PROGRAM\*(C'\fR to find the kernel image and ramdisk to use. Normally \&\f(CW\*(C`PROGRAM\*(C'\fR would be \f(CW\*(C`pygrub\*(C'\fR, which is an emulation of grub/grub2/syslinux. .ie n .IP "\fBbootloader_args=[ ""\s-1ARG"", ""ARG"", ...\s0]\fR" 4 .el .IP "\fBbootloader_args=[ ``\s-1ARG'', ``ARG'', ...\s0]\fR" 4 .IX Item "bootloader_args=[ ARG, ARG, ...]" Append \fB\s-1ARG\s0\fRs to the arguments to the \fBbootloader\fR program. Alternatively if the argument is a simple string then it will be split into words at whitespace (this second option is deprecated). .ie n .IP "\fBroot=""\s-1STRING""\s0\fR" 4 .el .IP "\fBroot=``\s-1STRING''\s0\fR" 4 .IX Item "root=STRING" Append \fBroot=\*(L"\s-1STRING\*(R"\s0\fR to the kernel command line (Note: it is guest specific what meaning this has). .ie n .IP "\fBextra=""\s-1STRING""\s0\fR" 4 .el .IP "\fBextra=``\s-1STRING''\s0\fR" 4 .IX Item "extra=STRING" Append \fB\s-1STRING\s0\fR to the kernel command line. Note: it is guest specific what meaning this has). .IP "\fBe820_host=BOOLEAN\fR" 4 .IX Item "e820_host=BOOLEAN" Selects whether to expose the host e820 (memory map) to the guest via the virtual e820. When this option is false (0) the guest pseudo-physical address space consists of a single contiguous \s-1RAM\s0 region. When this option is specified the virtual e820 instead reflects the host e820 and contains the same \s-1PCI\s0 holes. The total amount of \s-1RAM\s0 represented by the memory map is always the same, this option configures only how it is laid out. .Sp Exposing the host e820 to the guest gives the guest kernel the opportunity to set aside the required part of its pseudo-physical address space in order to provide address space to map passedthrough \&\s-1PCI\s0 devices. It is guest Operating System dependent whether this option is required, specifically it is required when using a mainline Linux (\*(L"pvops\*(R") kernel. This option defaults to true (1) if any \s-1PCI\s0 passthrough devices are configured and false (0) otherwise. If you do not configure any passthrough devices at domain creation time but expect to hotplug devices later then you should set this option. Conversely if your particular guest kernel does not require this behaviour then it is safe to allow this to be enabled but you may wish to disable it anyway. .IP "\fBpvh=BOOLEAN\fR Selects whether to run this \s-1PV\s0 guest in an \s-1HVM\s0 container. Default is 0." 4 .IX Item "pvh=BOOLEAN Selects whether to run this PV guest in an HVM container. Default is 0." .SS "Fully-virtualised (\s-1HVM\s0) Guest Specific Options" .IX Subsection "Fully-virtualised (HVM) Guest Specific Options" The following options apply only to \s-1HVM\s0 guests. .PP \fIBoot Device\fR .IX Subsection "Boot Device" .IP "\fBboot=[c|d|n]\fR" 4 .IX Item "boot=[c|d|n]" Selects the emulated virtual device to boot from. Options are hard disk (\fBc\fR), cd-rom (\fBd\fR) or network/PXE (\fBn\fR). Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom but fallback to the hard disk you can give \fBdc\fR. The default is \fBcd\fR. .PP \fIPaging\fR .IX Subsection "Paging" .PP The following options control the mechanisms used to virtualise guest memory. The defaults are selected to give the best results for the common case and so you should normally leave these options unspecified. .IP "\fBhap=BOOLEAN\fR" 4 .IX Item "hap=BOOLEAN" Turns \*(L"hardware assisted paging\*(R" (the use of the hardware nested page table feature) on or off. This feature is called \s-1EPT \s0(Extended Page Tables) by Intel and \s-1NPT \s0(Nested Page Tables) or \s-1RVI \s0(Rapid Virtualisation Indexing) by \s-1AMD. \s0 Affects \s-1HVM\s0 guests only. If turned off, Xen will run the guest in \*(L"shadow page table\*(R" mode where the guest's page table updates and/or \s-1TLB\s0 flushes etc. will be emulated. Use of \s-1HAP\s0 is the default when available. .IP "\fBoos=BOOLEAN\fR" 4 .IX Item "oos=BOOLEAN" Turns \*(L"out of sync pagetables\*(R" on or off. When running in shadow page table mode, the guest's page table updates may be deferred as specified in the Intel/AMD architecture manuals. However this may expose unexpected bugs in the guest, or find bugs in Xen, so it is possible to disable this feature. Use of out of sync page tables, when Xen thinks it appropriate, is the default. .IP "\fBshadow_memory=MBYTES\fR" 4 .IX Item "shadow_memory=MBYTES" Number of megabytes to set aside for shadowing guest pagetable pages (effectively acting as a cache of translated pages) or to use for \s-1HAP\s0 state. By default this is 1MB per guest vcpu plus 8KB per \s-1MB\s0 of guest \&\s-1RAM.\s0 You should not normally need to adjust this value. However if you are not using hardware assisted paging (i.e. you are using shadow mode) and your guest workload consists of a a very large number of similar processes then increasing this value may improve performance. .PP \fIProcessor and Platform Features\fR .IX Subsection "Processor and Platform Features" .PP The following options allow various processor and platform level features to be hidden or exposed from the guest's point of view. This can be useful when running older guest Operating Systems which may misbehave when faced with more modern features. In general you should accept the defaults for these options wherever possible. .ie n .IP "\fBbios=""\s-1STRING""\s0\fR" 4 .el .IP "\fBbios=``\s-1STRING''\s0\fR" 4 .IX Item "bios=STRING" Select the virtual firmware that is exposed to the guest. By default, a guess is made based on the device model, but sometimes it may be useful to request a different one, like \s-1UEFI.\s0 .RS 4 .IP "\fBrombios\fR" 4 .IX Item "rombios" Loads \s-1ROMBIOS,\s0 a 16\-bit x86 compatible \s-1BIOS.\s0 This is used by default when device_model_version=qemu\-xen\-traditional. This is the only \s-1BIOS\s0 option supported when device_model_version=qemu\-xen\-traditional. This is the \s-1BIOS\s0 used by all previous Xen versions. .IP "\fBseabios\fR" 4 .IX Item "seabios" Loads SeaBIOS, a 16\-bit x86 compatible \s-1BIOS.\s0 This is used by default with device_model_version=qemu\-xen. .IP "\fBovmf\fR" 4 .IX Item "ovmf" Loads \s-1OVMF,\s0 a standard \s-1UEFI\s0 firmware by Tianocore project. Requires device_model_version=qemu\-xen. .RE .RS 4 .RE .IP "\fBpae=BOOLEAN\fR" 4 .IX Item "pae=BOOLEAN" Hide or expose the \s-1IA32\s0 Physical Address Extensions. These extensions make it possible for a 32 bit guest Operating System to access more than 4GB of \s-1RAM.\s0 Enabling \s-1PAE\s0 also enabled other features such as \&\s-1NX. PAE\s0 is required if you wish to run a 64\-bit guest Operating System. In general you should leave this enabled and allow the guest Operating System to choose whether or not to use \s-1PAE. \s0(X86 only) .IP "\fBacpi=BOOLEAN\fR" 4 .IX Item "acpi=BOOLEAN" Expose \s-1ACPI \s0(Advanced Configuration and Power Interface) tables from the virtual firmware to the guest Operating System. \s-1ACPI\s0 is required by most modern guest Operating Systems. This option is enabled by default and usually you should omit it. However it may be necessary to disable \s-1ACPI\s0 for compatibility with some guest Operating Systems. .IP "\fBacpi_s3=BOOLEAN\fR" 4 .IX Item "acpi_s3=BOOLEAN" Include the S3 (suspend-to-ram) power state in the virtual firmware \&\s-1ACPI\s0 table. True (1) by default. .IP "\fBacpi_s4=BOOLEAN\fR" 4 .IX Item "acpi_s4=BOOLEAN" Include S4 (suspend-to-disk) power state in the virtual firmware \s-1ACPI\s0 table. True (1) by default. .IP "\fBapic=BOOLEAN\fR" 4 .IX Item "apic=BOOLEAN" Include information regarding \s-1APIC \s0(Advanced Programmable Interrupt Controller) in the firmware/BIOS tables on a single processor guest. This causes the \s-1MP \s0(multiprocessor) and \s-1PIR \s0(\s-1PCI\s0 Interrupt Routing) tables to be exported by the virtual firmware. This option has no effect on a guest with multiple virtual \s-1CPUS\s0 as they must always include these tables. This option is enabled by default and you should usually omit it but it may be necessary to disable these firmware tables when using certain older guest Operating Systems. These tables have been superseded by newer constructs within the \s-1ACPI\s0 tables. (X86 only) .IP "\fBnx=BOOLEAN\fR" 4 .IX Item "nx=BOOLEAN" Hides or exposes the No-eXecute capability. This allows a guest Operating system to map pages such that they cannot be executed which can enhance security. This options requires that \s-1PAE\s0 also be enabled. (X86 only) .IP "\fBhpet=BOOLEAN\fR" 4 .IX Item "hpet=BOOLEAN" Enables or disables \s-1HPET \s0(High Precision Event Timer). This option is enabled by default and you should usually omit it. It may be necessary to disable the \s-1HPET\s0 in order to improve compatibility with guest Operating Systems (X86 only) .IP "\fBnestedhvm=BOOLEAN\fR" 4 .IX Item "nestedhvm=BOOLEAN" Enable or disables guest access to hardware virtualisation features, e.g. it allows a guest Operating System to also function as a hypervisor. This option is disabled by default. You may want this option if you want to run another hypervisor (including another copy of Xen) within a Xen guest or to support a guest Operating System which uses hardware virtualisation extensions (e.g. Windows \s-1XP\s0 compatibility mode on more modern Windows \s-1OS\s0). .ie n .IP "\fBcpuid=""\s-1LIBXL_STRING""\s0\fR or \fBcpuid=[ ""\s-1XEND_STRING"", ""XEND_STRING"" \s0]\fR" 4 .el .IP "\fBcpuid=``\s-1LIBXL_STRING''\s0\fR or \fBcpuid=[ ``\s-1XEND_STRING'', ``XEND_STRING'' \s0]\fR" 4 .IX Item "cpuid=LIBXL_STRING or cpuid=[ XEND_STRING, XEND_STRING ]" Configure the value returned when a guest executes \s-1CPUID\s0 instruction. Two versions of config syntax are recognized: libxl and xend. .Sp The libxl syntax is a comma separated list of key=value pairs, preceded by the word \*(L"host\*(R". A few keys take a numerical value, all others take a single character which describes what to do with the feature bit. .Sp Possible values for a single feature bit: '1' \-> force the corresponding bit to 1 '0' \-> force to 0 'x' \-> Get a safe value (pass through and mask with the default policy) 'k' \-> pass through the host bit value 's' \-> as 'k' but preserve across save/restore and migration (not implemented) .Sp List of keys taking a value: apicidsize brandid clflush family localapicid maxleaf model nc proccount procpkg stepping .Sp List of keys taking a character: 3dnow 3dnowext 3dnowprefetch abm acpi aes altmovcr8 apic avx clfsh cmov cmplegacy cmpxchg16 cmpxchg8 cntxid dca de ds dscpl dtes64 est extapic f16c ffxsr fma4 fpu fxsr htt hypervisor ia64 ibs lahfsahf lm lwp mca mce misalignsse mmx mmxext monitor movbe msr mtrr nodeid nx osvw osxsave pae page1gb pat pbe pclmulqdq pdcm pge popcnt pse pse36 psn rdtscp skinit smx ss sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips svm_pausefilt svm_tscrate svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc vme vmx wdt x2apic xop xsave xtpr .Sp The xend syntax is a list of values in the form of \&'leafnum:register=bitstring,register=bitstring' \*(L"leafnum\*(R" is the requested function, \*(L"register\*(R" is the response register to modify \*(L"bitstring\*(R" represents all bits in the register, its length must be 32 chars. Each successive character represent a lesser-significant bit, possible values are listed above in the libxl section. .Sp Example to hide two features from the guest: 'tm', which is bit #29 in \s-1EDX,\s0 and \&'pni' (\s-1SSE3\s0), which is bit #0 in \s-1ECX:\s0 .Sp xend: [ '1:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0,edx=xx0xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' ] .Sp libxl: 'host,tm=0,sse3=0' .Sp More info about the \s-1CPUID\s0 instruction can be found in the processor manuals, and in Wikipedia: .ie n .IP "\fBacpi_firmware=""\s-1STRING""\s0\fR" 4 .el .IP "\fBacpi_firmware=``\s-1STRING''\s0\fR" 4 .IX Item "acpi_firmware=STRING" Specify a path to a file that contains extra \s-1ACPI\s0 firmware tables to pass in to a guest. The file can contain several tables in their binary \s-1AML\s0 form concatenated together. Each table self describes its length so no additional information is needed. These tables will be added to the \s-1ACPI\s0 table set in the guest. Note that existing tables cannot be overridden by this feature. For example this cannot be used to override tables like \s-1DSDT, FADT,\s0 etc. .ie n .IP "\fBsmbios_firmware=""\s-1STRING""\s0\fR" 4 .el .IP "\fBsmbios_firmware=``\s-1STRING''\s0\fR" 4 .IX Item "smbios_firmware=STRING" Specify a path to a file that contains extra \s-1SMBIOS\s0 firmware structures to pass in to a guest. The file can contain a set \s-1DMTF\s0 predefined structures which will override the internal defaults. Not all predefined structures can be overridden, only the following types: 0, 1, 2, 3, 11, 22, 39. The file can also contain any number of vendor defined \s-1SMBIOS\s0 structures (type 128 \- 255). Since \s-1SMBIOS\s0 structures do not present their overall size, each entry in the file must be preceded by a 32b integer indicating the size of the next structure. .PP \fIGuest Virtual Time Controls\fR .IX Subsection "Guest Virtual Time Controls" .ie n .IP "\fBtsc_mode=""\s-1MODE""\s0\fR" 4 .el .IP "\fBtsc_mode=``\s-1MODE''\s0\fR" 4 .IX Item "tsc_mode=MODE" Specifies how the \s-1TSC \s0(Time Stamp Counter) should be provided to the guest (X86 only). Specifying this option as a number is deprecated. Options are: .RS 4 .ie n .IP "\fB""default""\fR" 4 .el .IP "\fB``default''\fR" 4 .IX Item "default" Guest rdtsc/p executed natively when monotonicity can be guaranteed and emulated otherwise (with frequency scaled if necessary). .ie n .IP "\fB""always_emulate""\fR" 4 .el .IP "\fB``always_emulate''\fR" 4 .IX Item "always_emulate" Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p always emulated and the virtual \s-1TSC\s0 will appear to increment (kernel and user) at a fixed 1GHz rate, regardless of the \s-1PCPU HZ\s0 rate or power state; Although there is an overhead associated with emulation this will \s-1NOT\s0 affect underlying \s-1CPU\s0 performance. .ie n .IP "\fB""native""\fR" 4 .el .IP "\fB``native''\fR" 4 .IX Item "native" Guest rdtsc always executed natively (no monotonicity/frequency guarantees); guest rdtscp emulated at native frequency if unsupported by h/w, else executed natively. .ie n .IP "\fB""native_paravirt""\fR" 4 .el .IP "\fB``native_paravirt''\fR" 4 .IX Item "native_paravirt" Same as \fBnative\fR, except xen manages \s-1TSC_AUX\s0 register so guest can determine when a restore/migration has occurred and assumes guest obtains/uses pvclock-like mechanism to adjust for monotonicity and frequency changes. .RE .RS 4 .Sp Please see \fIdocs/misc/tscmode.txt\fR for more information on this option. .RE .IP "\fBlocaltime=BOOLEAN\fR" 4 .IX Item "localtime=BOOLEAN" Set the real time clock to local time or to \s-1UTC.\s0 False (0) by default, i.e. set to \s-1UTC.\s0 .IP "\fBrtc_timeoffset=SECONDS\fR" 4 .IX Item "rtc_timeoffset=SECONDS" Set the real time clock offset in seconds. False (0) by default. .IP "\fBvpt_align=BOOLEAN\fR" 4 .IX Item "vpt_align=BOOLEAN" Specifies that periodic Virtual Platform Timers should be aligned to reduce guest interrupts. Enabling this option can reduce power consumption, especially when a guest uses a high timer interrupt frequency (\s-1HZ\s0) values. The default is true (1). .IP "\fBtimer_mode=MODE\fR" 4 .IX Item "timer_mode=MODE" Specifies the mode for Virtual Timers. The valid values are as follows: .RS 4 .ie n .IP "\fB""delay_for_missed_ticks""\fR" 4 .el .IP "\fB``delay_for_missed_ticks''\fR" 4 .IX Item "delay_for_missed_ticks" Delay for missed ticks. Do not advance a vcpu's time beyond the correct delivery time for interrupts that have been missed due to preemption. Deliver missed interrupts when the vcpu is rescheduled and advance the vcpu's virtual time stepwise for each one. .ie n .IP "\fB""no_delay_for_missed_ticks""\fR" 4 .el .IP "\fB``no_delay_for_missed_ticks''\fR" 4 .IX Item "no_delay_for_missed_ticks" No delay for missed ticks. As above, missed interrupts are delivered, but guest time always tracks wallclock (i.e., real) time while doing so. .ie n .IP "\fB""no_missed_ticks_pending""\fR" 4 .el .IP "\fB``no_missed_ticks_pending''\fR" 4 .IX Item "no_missed_ticks_pending" No missed interrupts are held pending. Instead, to ensure ticks are delivered at some non-zero rate, if we detect missed ticks then the internal tick alarm is not disabled if the \s-1VCPU\s0 is preempted during the next tick period. .ie n .IP "\fB""one_missed_tick_pending""\fR" 4 .el .IP "\fB``one_missed_tick_pending''\fR" 4 .IX Item "one_missed_tick_pending" One missed tick pending. Missed interrupts are collapsed together and delivered as one 'late tick'. Guest time always tracks wallclock (i.e., real) time. .RE .RS 4 .RE .PP \fISupport for Paravirtualisation of \s-1HVM\s0 Guests\fR .IX Subsection "Support for Paravirtualisation of HVM Guests" .PP The following options allow Paravirtualised features (such as devices) to be exposed to the guest Operating System in an \s-1HVM\s0 guest. Utilising these features requires specific guest support but when available they will result in improved performance. .IP "\fBxen_platform_pci=BOOLEAN\fR" 4 .IX Item "xen_platform_pci=BOOLEAN" Enable or disable the Xen platform \s-1PCI\s0 device. The presence of this virtual device enables a guest Operating System (subject to the availability of suitable drivers) to make use of paravirtualisation features such as disk and network devices etc. Enabling these drivers improves performance and is strongly recommended when available. \s-1PV\s0 drivers are available for various Operating Systems including \s-1HVM\s0 Linux and Microsoft Windows . .Sp Setting \fBxen_platform_pci=0\fR with the default device_model \*(L"qemu-xen\*(R" requires at least \s-1QEMU 1.6.\s0 .IP "\fBviridian=BOOLEAN\fR" 4 .IX Item "viridian=BOOLEAN" Turns on or off the exposure of MicroSoft Hyper-V (\s-1AKA\s0 viridian) compatible enlightenments to the guest. These can improve performance of Microsoft Windows guests from Windows Vista and Windows 2008 onwards and setting this option for such guests is strongly recommended. This option should be harmless for other versions of Windows (although it will not give any benefit) and the majority of other non-Windows OSes. However it is known to be incompatible with some other Operating Systems and in some circumstance can prevent Xen's own paravirtualisation interfaces for \s-1HVM\s0 guests from being used. .PP \fIEmulated \s-1VGA\s0 Graphics Device\fR .IX Subsection "Emulated VGA Graphics Device" .PP The following options control the features of the emulated graphics device. Many of these options behave similarly to the equivalent key in the \fB\s-1VFB_SPEC_STRING\s0\fR for configuring virtual frame buffer devices (see above). .IP "\fBvideoram=MBYTES\fR" 4 .IX Item "videoram=MBYTES" Sets the amount of \s-1RAM\s0 which the emulated video card will contain, which in turn limits the resolutions and bit depths which will be available. .Sp When using the qemu-xen-traditional device-model, the default as well as minimum amount of video \s-1RAM\s0 for stdvga is 8 \s-1MB,\s0 which is sufficient for e.g. 1600x1200 at 32bpp. For the upstream qemu-xen device-model, the default and minimum is 16 \s-1MB.\s0 .Sp When using the emulated Cirrus graphics card (\fBvga=\*(L"cirrus\*(R"\fR) and the qemu-xen-traditional device-model, the amount of video \s-1RAM\s0 is fixed at 4 \s-1MB,\s0 which is sufficient for 1024x768 at 32 bpp. For the upstream qemu-xen device-model, the default and minimum is 8 \s-1MB.\s0 .IP "\fBstdvga=BOOLEAN\fR" 4 .IX Item "stdvga=BOOLEAN" Select a standard \s-1VGA\s0 card with \s-1VBE \s0(\s-1VESA BIOS\s0 Extensions) as the emulated graphics device. The default is false (0) which means to emulate a Cirrus Logic \s-1GD5446 VGA\s0 card. If your guest supports \s-1VBE 2.0\s0 or later (e.g. Windows \s-1XP\s0 onwards) then you should enable this. stdvga supports more video ram and bigger resolutions than Cirrus. This option is deprecated, use vga=\*(L"stdvga\*(R" instead. .ie n .IP "\fBvga=""\s-1STRING""\s0\fR" 4 .el .IP "\fBvga=``\s-1STRING''\s0\fR" 4 .IX Item "vga=STRING" Selects the emulated video card (stdvga|cirrus). The default is cirrus. .IP "\fBvnc=BOOLEAN\fR" 4 .IX Item "vnc=BOOLEAN" Allow access to the display via the \s-1VNC\s0 protocol. This enables the other VNC-related settings. The default is to enable this. .IP "\fBvncviewer=BOOLEAN\fR" 4 .IX Item "vncviewer=BOOLEAN" Automatically spawn a vncviewer when creating/restoring a guest. .ie n .IP "\fBvnclisten=""ADDRESS[:DISPLAYNUM]""\fR" 4 .el .IP "\fBvnclisten=``ADDRESS[:DISPLAYNUM]''\fR" 4 .IX Item "vnclisten=ADDRESS[:DISPLAYNUM]" Specifies the \s-1IP\s0 address, and optionally \s-1VNC\s0 display number, to use. .IP "\fBvncdisplay=DISPLAYNUM\fR" 4 .IX Item "vncdisplay=DISPLAYNUM" Specifies the \s-1VNC\s0 display number to use. The actual \s-1TCP\s0 port number will be \s-1DISPLAYNUM+5900.\s0 .IP "\fBvncunused=BOOLEAN\fR" 4 .IX Item "vncunused=BOOLEAN" Requests that the \s-1VNC\s0 display setup search for a free \s-1TCP\s0 port to use. The actual display used can be accessed with \f(CW\*(C`xl vncviewer\*(C'\fR. .ie n .IP "\fBvncpasswd=""\s-1PASSWORD""\s0\fR" 4 .el .IP "\fBvncpasswd=``\s-1PASSWORD''\s0\fR" 4 .IX Item "vncpasswd=PASSWORD" Specifies the password for the \s-1VNC\s0 server. .ie n .IP "\fBkeymap=""\s-1LANG""\s0\fR" 4 .el .IP "\fBkeymap=``\s-1LANG''\s0\fR" 4 .IX Item "keymap=LANG" Configure the keymap to use for the keyboard associated with this display. If the input method does not easily support raw keycodes (e.g. this is often the case when using \s-1VNC\s0) then this allows us to correctly map the input keys into keycodes seen by the guest. The specific values which are accepted are defined by the version of the device-model which you are using. See \*(L"Keymaps\*(R" below or consult the \&\fIqemu\fR\|(1) manpage. The default is \fBen-us\fR. .IP "\fBsdl=BOOLEAN\fR" 4 .IX Item "sdl=BOOLEAN" Specifies that the display should be presented via an X window (using Simple DirectMedia Layer). The default is not to enable this mode. .IP "\fBopengl=BOOLEAN\fR" 4 .IX Item "opengl=BOOLEAN" Enable OpenGL acceleration of the \s-1SDL\s0 display. Only effects machines using \fBdevice_model_version=\*(L"qemu\-xen\-traditional\*(R"\fR and only if the device-model was compiled with OpenGL support. False (0) by default. .IP "\fBnographic=BOOLEAN\fR" 4 .IX Item "nographic=BOOLEAN" Enable or disable the virtual graphics device. The default is to provide a \s-1VGA\s0 graphics device but this option can be used to disable it. .PP \fISpice Graphics Support\fR .IX Subsection "Spice Graphics Support" .PP The following options control the features of \s-1SPICE.\s0 .IP "\fBspice=BOOLEAN\fR" 4 .IX Item "spice=BOOLEAN" Allow access to the display via the \s-1SPICE\s0 protocol. This enables the other SPICE-related settings. .ie n .IP "\fBspicehost=""\s-1ADDRESS""\s0\fR" 4 .el .IP "\fBspicehost=``\s-1ADDRESS''\s0\fR" 4 .IX Item "spicehost=ADDRESS" Specify the interface address to listen on if given, otherwise any interface. .IP "\fBspiceport=NUMBER\fR" 4 .IX Item "spiceport=NUMBER" Specify the port to listen on by the \s-1SPICE\s0 server if the \s-1SPICE\s0 is enabled. .IP "\fBspicetls_port=NUMBER\fR" 4 .IX Item "spicetls_port=NUMBER" Specify the secure port to listen on by the \s-1SPICE\s0 server if the \s-1SPICE\s0 is enabled. At least one of the spiceport or spicetls_port must be given if \s-1SPICE\s0 is enabled. \s-1NB.\s0 the options depending on spicetls_port have not been supported. .IP "\fBspicedisable_ticketing=BOOLEAN\fR" 4 .IX Item "spicedisable_ticketing=BOOLEAN" Enable client connection without password. When disabled, spicepasswd must be set. The default is false (0). .ie n .IP "\fBspicepasswd=""\s-1PASSWORD""\s0\fR" 4 .el .IP "\fBspicepasswd=``\s-1PASSWORD''\s0\fR" 4 .IX Item "spicepasswd=PASSWORD" Specify the ticket password which is used by a client for connection. .IP "\fBspiceagent_mouse=BOOLEAN\fR" 4 .IX Item "spiceagent_mouse=BOOLEAN" Whether \s-1SPICE\s0 agent is used for client mouse mode. The default is true (1) (turn on) .IP "\fBspicevdagent=BOOLEAN\fR" 4 .IX Item "spicevdagent=BOOLEAN" Enables spice vdagent. The Spice vdagent is an optional component for enhancing user experience and performing guest-oriented management tasks. Its features includes: client mouse mode (no need to grab mouse by client, no mouse lag), automatic adjustment of screen resolution, copy and paste (text and image) between client and domU. It also requires vdagent service installed on domU o.s. to work. The default is 0. .IP "\fBspice_clipboard_sharing=BOOLEAN\fR" 4 .IX Item "spice_clipboard_sharing=BOOLEAN" Enables Spice clipboard sharing (copy/paste). It requires spicevdagent enabled. The default is false (0). .IP "\fBspiceusbredirection=NUMBER\fR" 4 .IX Item "spiceusbredirection=NUMBER" Enables spice usbredirection. Creates \s-1NUMBER\s0 usbredirection channels for redirection of up to 4 usb devices from spice client to domU's qemu. It requires an usb controller and if not defined it will automatically adds an usb2 controller. The default is disabled (0). .PP \fIMiscellaneous Emulated Hardware\fR .IX Subsection "Miscellaneous Emulated Hardware" .IP "\fBserial=DEVICE\fR" 4 .IX Item "serial=DEVICE" Redirect the virtual serial port to \fB\s-1DEVICE\s0\fR. Please see the \&\fB\-serial\fR option in the \fIqemu\fR\|(1) manpage for details of the valid \&\fB\s-1DEVICE\s0\fR options. Default is \fBvc\fR when in graphical mode and \&\fBstdio\fR if \fBnographics=1\fR is used. .IP "\fBsoundhw=DEVICE\fR" 4 .IX Item "soundhw=DEVICE" Select the virtual sound card to expose to the guest. The valid devices are defined by the device model configuration, please see the \&\fIqemu\fR\|(1) manpage for details. The default is not to export any sound device. .IP "\fBusb=BOOLEAN\fR" 4 .IX Item "usb=BOOLEAN" Enables or disables an emulated \s-1USB\s0 bus in the guest. .IP "\fBusbversion=NUMBER\fR" 4 .IX Item "usbversion=NUMBER" Specifies the type of an emulated \s-1USB\s0 bus in the guest. 1 for usb1, 2 for usb2 and 3 for usb3, it is available only with upstream qemu. Due to implementation limitations this is not compatible with the usb and usbdevice parameters. Default is 0 (no usb controller defined). .ie n .IP "\fBusbdevice=[ ""\s-1DEVICE"", ""DEVICE"", ...\s0]\fR" 4 .el .IP "\fBusbdevice=[ ``\s-1DEVICE'', ``DEVICE'', ...\s0]\fR" 4 .IX Item "usbdevice=[ DEVICE, DEVICE, ...]" Adds \fB\s-1DEVICE\s0\fRs to the emulated \s-1USB\s0 bus. The \s-1USB\s0 bus must also be enabled using \fBusb=1\fR. The most common use for this option is \&\fBusbdevice=['tablet']\fR which adds pointer device using absolute coordinates. Such devices function better than relative coordinate devices (such as a standard mouse) since many methods of exporting guest graphics (such as \s-1VNC\s0) work better in this mode. Note that this is independent of the actual pointer device you are using on the host/client side. .Sp Host devices can also be passed through in this way, by specifying host:USBID, where \s-1USBID\s0 is of the form xxxx:yyyy. The \s-1USBID\s0 can typically be found by using lsusb or usb-devices. .Sp If you wish to use the \*(L"host:bus.addr\*(R" format, remove any leading '0' from the bus and addr. For example, for the \s-1USB\s0 device on bus 008 dev 002, you should write \*(L"host:8.2\*(R". .Sp The form usbdevice=DEVICE is also accepted for backwards compatibility. .Sp More valid options can be found in the \*(L"usbdevice\*(R" section of the qemu documentation. .ie n .IP "\fBvendor_device=""\s-1VENDOR_DEVICE""\s0\fR" 4 .el .IP "\fBvendor_device=``\s-1VENDOR_DEVICE''\s0\fR" 4 .IX Item "vendor_device=VENDOR_DEVICE" Selects which variant of the \s-1QEMU\s0 xen-pvdevice should be used for this guest. Valid values are: .RS 4 .IP "\fBnone\fR" 4 .IX Item "none" The xen-pvdevice should be omitted. This is the default. .IP "\fBxenserver\fR" 4 .IX Item "xenserver" The xenserver variant of the xen-pvdevice (device\-id=C000) will be specified, enabling the use of XenServer \s-1PV\s0 drivers in the guest. .RE .RS 4 .Sp This parameter only takes effect when device_model_version=qemu\-xen. See \fIdocs/misc/pci\-device\-reservations.txt\fR for more information. .RE .SS "Device-Model Options" .IX Subsection "Device-Model Options" The following options control the selection of the device-model. This is the component which provides emulation of the virtual devices to an \&\s-1HVM\s0 guest. For a \s-1PV\s0 guest a device-model is sometimes used to provide backends for certain \s-1PV\s0 devices (most usually a virtual framebuffer device). .ie n .IP "\fBdevice_model_version=""\s-1DEVICE\-MODEL""\s0\fR" 4 .el .IP "\fBdevice_model_version=``\s-1DEVICE\-MODEL''\s0\fR" 4 .IX Item "device_model_version=DEVICE-MODEL" Selects which variant of the device-model should be used for this guest. Valid values are: .RS 4 .IP "\fBqemu-xen\fR" 4 .IX Item "qemu-xen" Use the device-model merged into the upstream \s-1QEMU\s0 project. This device-model is the default for Linux dom0. .IP "\fBqemu-xen-traditional\fR" 4 .IX Item "qemu-xen-traditional" Use the device-model based upon the historical Xen fork of Qemu. This device-model is still the default for NetBSD dom0. .RE .RS 4 .Sp It is recommended to accept the default value for new guests. If you have existing guests then, depending on the nature of the guest Operating System, you may wish to force them to use the device model which they were installed with. .RE .ie n .IP "\fBdevice_model_override=""\s-1PATH""\s0\fR" 4 .el .IP "\fBdevice_model_override=``\s-1PATH''\s0\fR" 4 .IX Item "device_model_override=PATH" Override the path to the binary to be used as the device-model. The binary provided here \s-1MUST\s0 be consistent with the `device_model_version` which you have specified. You should not normally need to specify this option. .IP "\fBdevice_model_stubdomain_override=BOOLEAN\fR" 4 .IX Item "device_model_stubdomain_override=BOOLEAN" Override the use of stubdomain based device-model. Normally this will be automatically selected based upon the other features and options you have selected. .ie n .IP "\fBdevice_model_stubdomain_seclabel=""\s-1LABEL""\s0\fR" 4 .el .IP "\fBdevice_model_stubdomain_seclabel=``\s-1LABEL''\s0\fR" 4 .IX Item "device_model_stubdomain_seclabel=LABEL" Assign an \s-1XSM\s0 security label to the device-model stubdomain. .ie n .IP "\fBdevice_model_args=[ ""\s-1ARG"", ""ARG"", ...\s0]\fR" 4 .el .IP "\fBdevice_model_args=[ ``\s-1ARG'', ``ARG'', ...\s0]\fR" 4 .IX Item "device_model_args=[ ARG, ARG, ...]" Pass additional arbitrary options on the device-model command line. Each element in the list is passed as an option to the device-model. .ie n .IP "\fBdevice_model_args_pv=[ ""\s-1ARG"", ""ARG"", ...\s0]\fR" 4 .el .IP "\fBdevice_model_args_pv=[ ``\s-1ARG'', ``ARG'', ...\s0]\fR" 4 .IX Item "device_model_args_pv=[ ARG, ARG, ...]" Pass additional arbitrary options on the device-model command line for a \s-1PV\s0 device model only. Each element in the list is passed as an option to the device-model. .ie n .IP "\fBdevice_model_args_hvm=[ ""\s-1ARG"", ""ARG"", ...\s0]\fR" 4 .el .IP "\fBdevice_model_args_hvm=[ ``\s-1ARG'', ``ARG'', ...\s0]\fR" 4 .IX Item "device_model_args_hvm=[ ARG, ARG, ...]" Pass additional arbitrary options on the device-model command line for an \s-1HVM\s0 device model only. Each element in the list is passed as an option to the device-model. .SS "Keymaps" .IX Subsection "Keymaps" The keymaps available are defined by the device-model which you are using. Commonly this includes: .PP .Vb 3 \& 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 .Ve .PP The default is \fBen-us\fR. .PP See \fIqemu\fR\|(1) for more information. .SH "SEE ALSO" .IX Header "SEE ALSO" .IP "\fIxl\fR\|(1)" 4 .IX Item "xl" .PD 0 .IP "\fIxlcpupool.cfg\fR\|(5)" 4 .IX Item "xlcpupool.cfg" .IP "\fIxl-disk-configuration\fR" 4 .IX Item "xl-disk-configuration" .IP "\fIxl-network-configuration\fR" 4 .IX Item "xl-network-configuration" .IP "\fIdocs/misc/tscmode.txt\fR" 4 .IX Item "docs/misc/tscmode.txt" .PD .SH "FILES" .IX Header "FILES" \&\fI/etc/xen/NAME.cfg\fR \&\fI/var/xen/dump/NAME\fR .SH "BUGS" .IX Header "BUGS" This document may contain items which require further documentation. Patches to improve incomplete items (or any other item) are gratefully received on the xen\-devel@lists.xen.org mailing list. Please see for information on how to submit a patch to Xen.