XSA-273 involves one hyperthread being able to use Spectre-like
techniques to "spy" on another thread. The details are somewhat
complicated, but the upshot is that after all Xen-based mitigations
have been applied:
* PV guests cannot spy on sibling threads
* HVM guests can spy on sibling threads
(NB that for purposes of this vulnerability, PVH and HVM guests are
identical. Whenever this comment refers to 'HVM', this includes PVH.)
There are many possible mitigations to this, including disabling
hyperthreading entirely. But another solution would be:
* Specify some cores as PV-only, others as PV or HVM
* Allow HVM guests to only run on thread 0 of the "HVM-or-PV" cores
* Allow PV guests to run on the above cores, as well as any thread of the PV-only cores.
For example, suppose you had 16 threads across 8 cores (0-7). You
could specify 0-3 as PV-only, and 4-7 as HVM-or-PV. Then you'd set
the affinity of the HVM guests as follows (binary representation):
0000000010101010
And the affinity of the PV guests as follows:
1111111110101010
In order to make this easy, this patches introduces three "global affinity
masks", placed in xl.conf:
vm.cpumask
vm.hvm.cpumask
vm.pv.cpumask
These are parsed just like the 'cpus' and 'cpus_soft' options in the
per-domain xl configuration files. The resulting mask is AND-ed with
whatever mask results at the end of the xl configuration file.
`vm.cpumask` would be applied to all guest types, `vm.hvm.cpumask`
would be applied to HVM and PVH guest types, and `vm.pv.cpumask`
would be applied to PV guest types.
The idea would be that to implement the above mask across all your
VMs, you'd simply add the following two lines to the configuration
file:
vm.hvm.cpumask=8,10,12,14
vm.pv.cpumask=0-8,10,12,14
See xl.conf manpage for details.
This is part of XSA-273 / CVE-2018-3646.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Running "make uninstall" does not remove all installed files, a
situation which might cause link related issues if xen is re-installed
in a different location.
In order to make uninstall correctly remove the files it is best
the process should be done recursively by mirroring each "install"
target with an "uninstall" who removes the installed files.
An exception to this rule is uninstalling the files produced by
"qemu-xen-dir-remote" and "qemu-xen-traditional-dir", which are external
to the project. These projects do not implement an "uninstall" target so
the files have to be removed manually.
Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
They are no longer needed, having been replaced by a daemon for
driverdomains which will run scripts as necessary.
Worse yet, they seem to be broken for script-based block devices, such
as block-iscsi. This wouldn't matter so much if they were never run
by default; but if you run block-attach without having created a
domain, then the appropriate node to disable running udev scripts will
not have been written yet, and the attach will silently fail.
Rather than try to sort out that issue, just remove them entirely.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The original rule to target "distclean" in tools/Rules.mk was in effect
"make clean". It should be "make distclean".
However not all Makefiles in subdirectories have distclean target
defined. So this patch also adds a bunch of distclean targets to various
Makefiles. They only depend on clean target and don't have any actions
in most cases.
With the patch applied, following command outputs 0 results:
find tools -name 'Makefile*' -exec grep -L 'distclean' {} \+ \
| grep -v ocaml | grep -v libfsimage
Ocaml and libfsimage are known to have distclean defined in a dedicated
rules file.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
install-hotplug and install-udev are obsolete since commit 57bcfa11
("tools/hotplug: Separate OS-specific scripts.")
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
I've retained xen.lowlevel.{xc,xs} since they seem more widely useful. I also
kept xen.lowlevel.xl even though it is disabled by default and IMHO useless in
its current form.
I've tried to clean up the various associated bits like example configs, init
scripts, udev rules etc but no doubt I have missed something, those can easily
be cleaned up later.
I've also removed xm-test since although it could in theory be reworked to
test xl it hasn't been touched for years. If someone wants to resurrect it
then they could do so via the git history.
This has been built but not runtime tested.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Clean out some .*ignore cruft
Remove some xm/xend docs.
xend has been deprecated for 2 releases now. Lets make it possible to not even
build it.
For now I'm leaving the default of on but I would like to change that before
the 4.4 release.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Matt Wilson <msw@amazon.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
During the Xen 4.3 release we discussed that this feature could be
turned on by default - as it benefits all of the guests - not just
tmem related.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
We've changed the config option from "vifscript" to "vif.default.script". This
was changed in the manpage but not in the example xl.conf.
Also move the option down to be with the other vif options.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The XENMEM_claim_pages hypercall operates per domain and it should be
used system wide. As such this patch introduces a global configuration
option 'claim_mode' that by default is disabled.
If this option is enabled then when a guest is created there will be an
guarantee that there is memory available for the guest. This is an
particularly acute problem on hosts with memory over-provisioned guests
that use tmem and have self-balloon enabled (which is the default option
for them). The self-balloon mechanism can deflate/inflate the balloon
quickly and the amount of free memory (which 'xl info' can show) is stale
the moment it is printed. When claim is enabled a reservation for the
amount of memory ('memory' in guest config) is set, which is then reduced
as the domain's memory is populated and eventually reaches zero.
If the reservation cannot be meet the guest creation fails immediately
instead of taking seconds/minutes (depending on the size of the guest)
while the guest is populated.
Note that to enable tmem type guests, one needs to provide 'tmem' on the
Xen hypervisor argument and as well on the Linux kernel command line.
There are two boolean options:
(0) No claim is made. Memory population during guest creation will be
attempted as normal and may fail due to memory exhaustion.
(1) Normal memory and freeable pool of ephemeral pages (tmem) is used when
calculating whether there is enough memory free to launch a guest.
This guarantees immediate feedback whether the guest can be launched due
to memory exhaustion (which can take a long time to find out if launching
massively huge guests) and in parallel.
[v1: Removed own claim_mode type, using just bool, improved docs, all per
Ian's suggestion]
[v2: Updated the comments]
[v3: Rebase on top 733b9c524d (xl: add vif.default.script)]
[v4: Fixed up comments]
[v5: s/global_claim_mode/claim_mode/]
[v6: Ian Jackson's feedback: use libxl_defbool, better comments, etc]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
autoballoon=1 is not recommened if dom0_mem was used to reduce the
amount of dom0 memory. Instead of requiring users to change xl.conf
if they do this, extend the autoballoon option with a new choice:
"auto".
With autoballoon="auto", autoballooning will be disabled if dom0_mem
was used on the Xen command line.
For consistency, accept "on" and "off" as valid autoballoon options (1
and 0 are still accepted).
The default remains "on" for now.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Add and option to xl.conf file to decide if hotplug scripts are
executed from the toolstack (xl) or from udev as it used to be in the
past.
This option is only introduced in this patch, but it has no effect
since the code to call hotplug scripts from libxl is introduced in a
latter patch.
This choice will be saved in "libxl/disable_udev", as specified in the
DISABLE_UDEV_PATH constant.
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Introduce a blkdev_start in xl.conf and a corresponding string in
libxl_domain_build_info.
Add a blkdev_start parameter to libxl__device_disk_local_attach: it is
going to be used in a following patch.
blkdev_start specifies the first block device to be used for temporary
block device allocations by the toolstack.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Use correct string for gfx_passthru, and fix comment typo in xmexample.hvm
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Turning this on for Windows guests is recommended.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Based on an initial version by Ian Jackson.
I believe that all keys are now present in the document although there are are
various omissions in the actual documentation of them. Hopefully however this
covers the majority of the most interesting keys.
Spice section:
Signed-off-by: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
The rest:
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
This is rather critical...
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
These are much more minimal than the equivalent xmexamples but should
eventually reference a more complete document describing the available options.
These are based on the guest configuration files that I actually use day-to-day.
There is an unresolved reference to a document describing the complete syntax.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Otherwise make can search the path relative to certain standard paths
such as /usr/include (e.g., the line '-include $(XEN_ROOT)/.config' in
Config.mk suffers from this).
Signed-off-by: Keir Fraser <keir@xen.org>
Add "vifscript" option to xl.conf which configures the default vif
script to use (default remains "vif-bridge")
Write each VIFs "ip" option to xenstore so the vif-route script can
pick it up.
Reported-by: W. Michael Petullo <mike@flyn.org>.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Free the needed amount of memory before proceeding with the domain
build.
Use a filelock to prevent other xl instances from conflicting during
this operation.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Add a global configuration file: /etc/xen/xl.conf; the only option
currently parsed is autoballoon that is 1 by default.
[fixed up for conflicts with libxl__ naming policy changes -iwj]
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
On server startup xend start or a later xend restart needs approx. 30 min to
start/restart. Without attached FC devices xend start/restart needs only some
seconds.
server type: Fujitsu Primergy RX600-S5
The time gets lost in xen/xend/XendNode.py line 329 while calling
vscsi_util.get_all_scsi_device().
329 for pscsi_record in vscsi_util.get_all_scsi_devices():
330 scsi_id = pscsi_record['scsi_id']
331 if scsi_id:
332 saved_HBA_uuid = None
I think, in most cases we don't need all the PSCSI devices registered in
xend, but only a few of it.
So a good solution for this perforamce issue is to scan only the SCSI device
paths we need, controlled by a new option in xend-config.sxp.
I have made a patch to allow specification of scsi devices we need in xend
in the config file xend-config.sxp.
The new options pscsi-device-mask expects a list of device ids oder partial
device ids like the option of lsscsi, e.g.
(pscsi-device-mask ('<partial-dev-id1' 'partial-dev-id2' ...))
Without this option set in xend-config.sxp or if lsscsi is not support, all
device paths are process like today.
Signed-off-by: Lutz Dube Lutz.Dube@ts.fujitsu.com
Comment from Masaki Kanno <kanno.masaki@jp.fujitsu.com>: "Well done"
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Previously, the default "network-script",
/etc/xen/scripts/network-bridge, would attempt to do its horrid work
even if you had already set everything up in /etc/network/interfaces.
Setting up your bridge in /etc/network/interfaces is:
* easy
* required for libxl since libxl never does it for you
* not a fragile piece of lunacy
* properly documented
* the way everyone would expect it to work
In this small patch we make it so that the default config for xend
doesn't mess about on startup if you already have a bridge, and
doesn't mess about on shutdown unless your first-named bridge (eth0 or
xenbr0, normally) doesn't also have a physical interface named
p<whatever> (peth0 or pxenbr0) enslaved to it. The latter test is not
ideal but will hopefully do from now until the time xend finally dies.
We also fix the "documentation" - ie, the comments in the default
xend-config.sxp - to correspond to reality.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Add a new feature for xend-relocation-address option to support
definition by interface name which can be useful for people having
e.g. a cluster environment with multiple network interfaces on all of
the machines with only one reserved to be registered to a private
cluster network. This way they won't need to specify the relocation
address manually on all the machines but just simple providing the
interface name to get the IP address from would do the job (all the
machines have to have this interface named the same to make it
working, of course).
Technically it reads the interface name and gets its IP address using
ioctl call of SIOCGIFADDR and if the interface doesn't have the
address, i.e. if non-existing interface or hostname was provided the
original ifname is returned to preserve the old behaviour.
Signed-off-by: Michal Novotny <minovotn@redhat.com>
Add an option into hvm config file to enable graphics passthrough
including discrete and IGD. To passthrough graphics to guest, need to
set gfx_passthru=1, and also specify graphics device BDF in pci
passthrough option, like pci=['xx:xx.x'] in hvm config file.
Signed-off-by: Weidong Han <weidong.han@intel.com>
the tapdisk2 process if sharing is enabled (tapdisk2 is not normally aware what
domain it is working for).
Signed-off-by: Grzegorz Milos <Grzegorz.Milos@citrix.com>
The main idea of this patch is:
1) The admin sets aside some memory below 128G for 32-bit paravirtual
domain creation (via dom0_mem=-<value> in kernel comand line).
2) The admin also explicitly states to the tools (i..e xend) how much
memory is supposed to be left untouched by 64-bit domains
3) If a 32-bit pv DomU gets created, no ballooning ought to be
necessary (since if it is, no guarantee can be made about the address
range of the memory ballooned out), and memory gets allocated from the
reserved range.
4) Upon 64-bit (or 32-bit HVM or HVM) DomU creation, the tools
determine the amount of memory to be ballooned out of Dom0 by adding
the amount needed for the new guest and the amount still in the
reserved pool (and then of course subtracting the total amount of
memory the hypervisor has available for guest use).
Signed-off-by: james song (wei) <jsong@novell.com>
(NOTE: pvrdtscp mode not finished yet, but all other
modes have been tested so sooner seemed better than
later to submit this fairly major patch so we can get
more mileage on it before next release.)
New tsc_mode config option supercedes tsc_native and
offers a more intelligent default and an additional
option for intelligent apps running on PV domains
("pvrdtscp").
For PV domains, default mode will determine if the initial
host has a "safe"** TSC (meaning it is always synchronized
across all physical CPUs). If so, all domains will
execute all rdtsc instructions natively; if not,
all domains will emulate all rdtsc instructions but
providing the TSC hertz rate of the initial machine.
After being restored or live-migrated, all PV domains will
emulate all rdtsc instructions. Hence, this default mode
guarantees correctness while providing native performance
in most conditions.
For PV domains, tsc_mode==1 will always emulate rdtsc
and tsc_mode==2 will never emulate rdtsc. For tsc_mode==3,
rdtsc will never be emulated, but information is provided
through pvcpuid instructions and rdtscp instructions
so that an app can obtain "safe" pvclock-like TSC information
across save/restore and live migration. (Will be completed in
a follow-on patch.)
For HVM domains, the default mode and "always emulate"
mode do the same as tsc_native==0; the other two modes
do the same as tsc_native==1. (HVM domains since 3.4
have implemented a tsc_mode=default-like functionality,
but also can preserve native TSC across save/restore
and live-migration IFF the initial and target machines
have a common TSC cycle rate.)
** All newer AMD machines, and Nehalem and future Intel
machines have "Invariant TSC"; many newer Intel machines
have "Constant TSC" and do not support deep-C sleep states;
these and all single-processor machines are "safe".
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Currently when assigning device to HVM guest, we use the strict check
for HVM guest by default.(For PV guest we use loose check
automatically if necessary.)
When we assign device to HVM guest, if we meet with the co-assignment
issues or the ACS issue (see changeset 20081: 4a517458406f), we could
try changing the option to 'no' -- however, we have to realize this
may incur security issue and we can't make sure the device assignment
could really work properly even after we do this.
The option is located in /etc/xen/xend-config.sxp:
(pci-passthrough-strict-check yes)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Wei Liu
Roger Pau Monne
Petre Pircalabu
Dario Faggioli
George Dunlap
Olaf Hering
Ian Campbell
Jan Beulich
Konrad Rzeszutek Wilk
Konrad Rzeszutek Wilk
David Vrabel
Matthew Fioravante
Stefano Stabellini
Fabio Fantoni
Keir Fraser
Juergen Gross
Ian Jackson
"Dube, Lutz"
Keir Fraser