Attached patch implements save/restore/migration/livemigration
for transcendent memory ("tmem"). Without this patch, domains
using tmem may in some cases lose data when doing save/restore
or migrate/livemigrate. Also included in this patch is
support for a new (privileged) hypercall for authorizing
domains to share pools; this provides the foundation to
accomodate upstream linux requests for security for shared
pools.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
In the method xen.xend.XendStateStore.XendStateStore.load_state and
xen.xend.XendStateStore.XendStateStore.save_state the minidom objects
used to load/save the current state of a device type, can't be freed
by the python garbage collector after all references to the top node
are cleared, because of cyclic references between the DOM nodes. So
memory usage of xend increases after calling these methods. To solve
this problem, the unlink() method must be called for a minidom object
before the last reference to the top node is cleared (see python
docs). This breaks the cyclic references, so the garbage collector can
free these objects.
Signed-off-by: juergen.gross@ts.fujitsu.com
This extends the mapping between physical and virtual PCI functions
for multi-function pass-through in two ways. If neither of these
rules apply the existing identity-mapping of physical to virtual
functions is used.
1) If physical function zero is not present in a multi-function
pass-through device then the numerically lowest physical function
whose virtual function hasn't explicitly been set will be mapped
to virtual function 0.
This is to satisfy the requirement that a (virtual) device
must always have function 0 present.
2) The virtual function to be used for a physical function may
be explicitly set.
e.g. 00:1d.2=3D0,1=3D1,0=3D2@7 will result in the following
mapping:
physical | virtual
---------+--------
00:1d.2 | 00:07.0
00:1d.1 | 00:07.1
00:1d.0 | 00:07.2
Ranges may also be used with explicit assignment.
The following would result in the same mapping as above:
00:1d.2=3D0-0=3D2@7
Please be aware that it is very likely that using these extensions
it is possible to create mappings that do not work. If in doubt
please use identity-mapping.
Cc: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
When we 'xm pci-attach' device into pv guest, we also need to check if
the device is owned by pciback or pci-stub, if the device has been
assigned, etc.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
In current xend, we can not assign co-assignment devices to different
guests, even for pv guests. This patch loosens the policy for pv
guest: if none of the co-assignment devices have been assigned to hvm
guest, we can assign the devices to different pv guests.
The patch also adds a detection: if a device has been assigned to
guest, we can't try to "xm pci-attach" it to the same guest again.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
This patch allows vcpus_params cpu_weight and cpu_cap to be saved and
restored. Most the code to support this already existed, but the save
path needed to be updated to explicitly save these params, and the
restore path needed to be updated to resend the params down to the
kernel.
From: Andrew Jones <drjones@redhat.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* Use pci_dict_to_bdf_str() in hvm_pci_device_create()
* Use pci_name instead of pci_str in error message, pci_str does not
* exist
Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: Dexuan Cui <dexuan.cui@intel.com>
Currently, xend dumps a core file of a DomU
in the directory "/var/xen/dump/", when the DomU has crashed.
The patch modifies this directory to "/var/xen/dump/<domain name>/".
It enables you to select HDD partition per DomU to dump core by using
mount command.
Signed-off-by: Rikiya Ayukawa <ayukawa.rikiya@jp.fujitsu.com>
xc.test_assign_device(dev) can only tell us if dev is assigned to hvm
guest; if a device is assigned to pv guest, xc.test_assign_device()
still tells us the device is not assigned yet, as a result, the device
still appears in the output of "xm pci-list-assignable-devices", and
xend would not prevent us from assigning the device to a new pv or hvm
guest.
To judge if a device has been assigned to guest, we have to scan
xenstore.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
This reverses changeset "xend: pass-through: Implement least-mapping
of virtual" (19854:22067ba1de0d) and reverts the code to identity
mapping physical PCI functions to virtual ones when multi-function
virtual devices are in use. It is my opinion that this is both safer
and simpler than least-mapping, and that in the absence of further
analysis identity-mapping the best choice for now.
Signed-off-by: Simon Horman <horms@verge.net.au>
changeset "python: Remove tab indents" (19937:e845326ae203)
introduces a minor regression in the multi-function PCI pass-through
code by causing bogus return values from the sort function
which is used to order the output of "xm pci list".
Signed-off-by: Simon Horman <horms@verge.net.au>
Add support for 'file:' and 'data:' URI schemes for the parameters
'PV/kernel' and 'PV/ramdisk' in the VM.create() call. The 'data:'
scheme handling enables using a file which is stored inside the
management system (from where the XenAPI call is send) as kernel or
ramdisk.
Notes:
o all included: a detailed description can be found in the xenapi
documentation
o bumped up the version of the API document to 1.0.8 (because of
(minimal) interface extension)
o Future enhancements (like http:, ftp: schemes) fit seamlessly into
the current design / classes
Signed-off-by: Andreas Florath <xen@flonatel.org>
Use vdevfn in xm_pci_attach() for non-zero functions,
the vslot element of dev dictionaries no longer exists.
Signed-off-by: Simon Horman <horms@verge.net.au>
pciback is used by VT-d to hide device for assigment. But in pv-ops
dom0, pciback is not supported yet. Fortunately, pci-stub module is
used to hide device in Linux for KVM VT-d device assignment and it's
included in pv-ops dom0. So can use pci-stub to hide devices for
assignment.
Device must be hidden before assignment. Control panel has checks if
devices can be assigned or not, and can list assignable devices via
reading devices owned by pciback. This patch changes the checks, and
also list assignable devices which are owned by pci-stub. Use pci-stub
to hide devices, and use this patch to pass checkes in control panel,
device assignemnt with VT-d works on Xen with pv-ops dom0.
Signed-off-by: Weidong Han <weidong.han@intel.com>
blktap2 devices use a regular 'phy' vbd blkback backend, causing
Blktap2Controller to trample the devices' parameters. This causes
problems with save/restore and managed domains, among other
things. This patch modifies Blktap2Controller to store both the vbd
and tap2 parameters in xenstore, and stops it from trampling the
device's config on device creation.
* store blktap2 parameters in xenstore
* restore blktap2 device config to original state once the underlying
* vbd
device is created (this fixes managed domains)
* use blktap2 parameters rather than vbd parameters when building
* blktap2
device configurations
* remove blktap2 specific code from XendConfig
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
* seperate blktap1/blktap2 disk types
* use blktap1 when driver is not in explicit list of blktap2 drivers,
* rather than current check against list of blktap1 only drivers
* remove 'tapdisk' disk type (it is not a tapdisk disk type) and fix
* tapdisk disk type check in XenConfig
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
blktap2 devices must be handled differently than blktap2
devices. blktap2 devices require a sysfs write to close the underlying
device, as well as extra sysfs writes when the domU is
paused/unpaused. The differences between blktap1 and blktap2 are great
enough to warrant the creation of a new device class, 'tap2', and
device controller for blktap2 devices.
* add a new device controller (Blktap2Controller) and device class
(tap2) for blktap2 devices
* move blktap2 specific code from DevController to Blktap2Controller
* if possible, check xenstore to determine block device class
* use vmpath (/vm/<uuid>/) when releasing devices
* modify linux hotplug cleanup script to handle blktap2 device
removal
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
* Change default settings to relative pathes.
* Make xend to prepend install directory if entries have no absolute
* path
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
This is an alternative to identity mapping virtual functions.
It works by assigning the numerically lowest virtual function that is
available.
* The order of assignment is thus dependent on the order that physical
functions are specified.
e.g.
config physical virtual
01.00.0,2 -> 01:00.0 -> 00:07.0
-> 01:00.2 -> 00:07.1
is different to
config physical virtual
01.00.2,0 -> 01:00.2 -> 00:07.0
-> 01:00.0 -> 00:07.1
* Physical function 0 need not be present
e.g.
config physical virtual
01.00.1,2 -> 01:00.1 -> 00:07.0
-> 01:00.2 -> 00:07.1
* Functions from the same physical multi-function device
may be exported as multiple multi-function and single-function
devices
e.g.
01.00.0,2 -> 01:00.0 -> 00:07.0
-> 01:00.2 -> 00:07.1
and
01.00.1,3 -> 01:00.1 -> 00:08.1
-> 01:00.3 -> 00:08.1
and
01.00.5 -> 01:00.5 -> 00:09.0
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Hook things up to allow multi-function pass-through.
This includes making sure that request is valid.
In the case of pci-detach:
* All the functions requested must be attached to the same virtual
slot * and;
* A request must include the functions attached to a virtual slot
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
When unplugging a function, all functions in the same vslot must be
unplugged, and function 0 must be one of the functions present when a
vslot is hot-plugged. Telling qemu-dm to unplug function 0 also tells
it to unplug all other functions in the same vslot.
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
The general format is as follows:
Now: SEQ:BUS:DEV.FUNC[@VSLOT][,OPT...]
New: SEQ:BUS:DEV.FUNC0-FUNCN[@VSLOT][,OPT...]
SEQ:BUS:DEV.FUNC0,FUNCM,FUNCN[@VSLOT][,OPT...]
SEQ:BUS:DEV.*[@VSLOT][,OPT...]
In the case of unplug the VSLOT and OPT must be omitted.
Xm expands this notation notation out and passes
more conventional parameters to qemu-xen.
E.g:
0000:00:01.00-03 becomes:
0000:00:01.00
0000:00:01.01
0000:00:01.02
0000:00:01.03
0000:00:01.00,03,05,07 becomes:
0000:00:01.00
0000:00:01.03
0000:00:01.05
0000:00:01.07
For a device that has functions 0, 1, 2, 3, 5 and 7,
0000:00:01.* becomes:
0000:00:01.00
0000:00:01.01
0000:00:01.02
0000:00:01.03
0000:00:01.05
0000:00:01.07
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Cc: Akio Takebe <takebe_akio@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Instead of suppling a slot number to qemu-xen, supply a devfn.
This and subsequent other changes will allow xend to ask
for more than one function to be inserted into a single slot -
by specifying which function of the slot should be used.
This is a minimal patch for this change. A subsequent
patch that has a lot of noise to rename slot to devfn
is intended to follow.
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Keir Fraser