As observed by Dexuan Cui, when PCI devices are passed through at
domain-creation-time setupOneDevice() will be called twice.
Once via setupDevice() and once via econfigureDevice() which
is called in pci_device_configure().
This patch removes the first of these.
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
This patch adds a new command line argument to xenconsole to specify
to which console to connect to in case a domain has more than one.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Recently the format of the tap syntax in the config file changed to
using a 4 part specifier (tap:tapdisk:<format>:<filename>) instead
of the old 3-part one (tap:<qcow>:<filename>).
This breaks compatibility with existing config files: a guest start
will throw a Python exception and will be aborted.
AFAICS currently tap:tapdisk is redundant, so the attached patch
simply catches the above mentioned exception and tries to parse the
old format in this case.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
On some hosts:
[root@localhost ~]# ls /sys/bus/pci/devices/0000:00:05.0/
0000:00:05.0:pcie00 0000:05:00.0 class driver local_cpus
resource subsystem_vendor
0000:00:05.0:pcie01 broken_parity_status config enable modalias
subsystem uevent
0000:00:05.0:pcie02 bus device irq power
subsystem_device vendor
Here we should only get 0000:05:00.0, but we also get 0000:00:05.0
unexpectedly. With this patch, xend only extracts the exact BDF(s).
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
As observed by Mick Joran, if short-lived domain exits cleanly
then os.waitpid() will throw the following exception. This appears
to be because the child process that is used to start the domain
has detached from its parent.
OSError: [Errno 10] No child processes
Cc: Mick Jordan <Mick.Jordan@sun.com>
Signed-off-by: Simon Horman <horms@verge.ent.au>
Other than being arguably more human readable,
this patch reconciles the output differences between
using Xen API and xmlrpc to manipulate domains.
Signed-off-by: Simon Horman <horms@verge.net.au>
Using func for hotplug_slot is not correct, although func is often
zero, previously zero meant please pick a vslot and asking xend to
pick a vslot was the only method available.
This resolves the following error when using Xen API:
$ xm create hvm.conf
...
Internal error: Timed out waiting for device model action.
Signed-off-by: Simon Horman <horms@verge.net.au>
xm uses the following code to read pci information using Xen API:
ppci_ref =3D server.xenapi.DPCI.get_PPCI(dpci_ref)
ppci_record =3D server.xenapi.PPCI.get_record(ppci_ref)
dev =3D {
"domain": int(ppci_record["domain"]),
"bus": int(ppci_record["bus"]),
"slot": int(ppci_record["slot"]),
"func": int(ppci_record["func"]),
"vslot": int(server.xenapi.DPCI.get_hotplug_slot(dpci_ref))
}
As the domain, bus, slot and func values are returned as string
representations of decimal, it makes sense for get_hotplug_slot() to
also return string representations of decimal.
As it is, the int() conversion will break cause xm to fail with
an error if the vslot is in the range 0xa-0xf or 0x1a-0x1f.
$ xm pci-list debian
Error: Invalid argument.
And the int() conversion will return the wrong value if
the vslot is in the range 0x10-0x19.
This patch also alters XendDPCI to store hotplug_vslot as an integer
rather than a string. This is consitent with the way other
values are stored inside XendDPCI.
get_hotplug_slot() returning a string is not consistent
with other calls inside XendDPCI, which return integers.
Signed-off-by: Simon Horman <horms@verge.net.au>
I don't know of the historical reasons for this, but by convention
hex values are stored without a leading '0x' in the backend and
with a leading '0x' in the device configuration.
This patch also removes handling of the case where vslot is missing
from the backend, should never occur.
Signed-off-by: Simon Horman <horms@verge.net.au>
Internally xend doesn't know how to handle empty opts.
This code ensures that opts is only included in the sxpr
if its value will be non-empty.
Signed-off-by: Simon Horman <horms@verge.net.au>
* Install create.dtd in SHAREDIR
* Use SHAREDIR/create.dtd
* import os.path.join into xenapi_create.py,
it already seems to be used many times
Resolves the following error when using XenAPI:
$ xm create hvm.conf
Couldn't open resource '/usr/share/xen/create.dtd' at
/usr/share/xen/create.dtd:1:0
Signed-off-by: Simon Horman <horms@verge.net.au>
This patch fixes the "file object has no attribute find" failure
we've been seeing when starting blktap2 devices and adds more
meaningful error output to conditions where the tapdisk2 process is
unable to create a blktap2 device.
Signed-off-by: Dutch Meyer <dmeyer@cs.ubc.ca>
1) fix some small typos in util/pci.py;
2) find_all_the_multi_functions(): BDFs of a multi-function PCIe
device could be different in all the 3 fields (bus, device, function),
so we need self.find_parent() and list all t
he BDFs below the parent;
3) to assign a device of the must-be-co-assigned devices, we require
all the related devices should be owned by pciback;
4) detect and disallow duplicate pci string specified in guest config
file due to carelessness.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
This fixes the check for a request to detatch a non-existent device
in pci_device_configure. The previous check was bogus because the
format of AUTO_PHP_SLOT_STR is not the same as that of x['vslot'].
However, it works in a slightly non-obvious way, checking that vslot
hasn't been altered from its initial value AUTO_PHP_SLOT_STR. To
make this shceme a little clearer, use an empty string as the inital
value.
Formting issues asside, neither AUTO_PHP_SLOT_STR nor the empty
string are valid values for x['vslot']. In the event
of invalid data (indicating a bug), it should be caught by
self.hvm_destroyPCIDevice.
Signed-off-by: Simon Horman <horms@verge.net.au>
Currently there are two interfaces to pass-through PCI devices:
1. A method driven through per-device xenstore entries that is used at
boot-time
2. An event-based method used for hot-plug.
This seems somewhat redundant and makes extending the code cumbersome
and prone to error - often the change needs to be made twice, in
two different ways.
This patch unifies PCI pass-through by using the existing event-based
method at boot-time.
Signed-off-by: Simon Horman <horms@verge.net.au>
On Python 2.3, xend cannot started:
File
"usr/lib/python2.3/site-packages/xen/xend/server/BlktapController.=
py", line 3, in ?
import subprocess
ImportError: No module named subprocess
This patch uses `popen2' instead of `subprocess' for Python 2.3.
Signed-off-by: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
This is another attempt at having pci-list produce consistent output.
Without this change there differences in the output of both vslots
and domain occur for domains that have never been started and domains
that have been started.
In order to address this I have taken the approach of
using integers where possible and explicitly formating them,
rather than relying on string representations that are present in
data structures.
I have also re-used the common part of the format, to try
and mitigate. the possibility of future inconsistencies there.
This patch also:
* Removes trailing whitespace
* Removes unnecessary brackets and whitespace from print invocations
* Prints the header outside of the loop to avoid having
to maintain a state variable
Signed-off-by: Simon Horman <horms@verge.net.au>
This patch updates info['platform']['pci'] for PCI devices
assignment to domains.
When a domain is started, xend confirms by using xc.test_assign_device
whether PCI devices can be assigned to the domain. For the
confirmation, info['platform']['pci'] must be an appropriate value.
However, info['platform']['pci'] may be not appropriate. Because
info['platform']['pci'] isn't almost always updated even if the PCI
device configuration of the domain was changed by using xm
pci-attach/detach. This patch updates info['platform']['pci'] to the
appropriate value when domains are started.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
I've checked the duplicate-check code here and I found that's checked
only in the context of one domain but not cross-domain. The thing is
that we should check tap/vbd device cross-domain not to allow another
guest to use the same disk image in some circumstances to prevent VM's
disk corruption.
The patch included denies disk image addition under those
circumstances:
1. We're adding read-only disk that's already used as write-exclusive
2. We're adding write-shared disk that's already used as
write-exclusive
3. We're adding write-exclusive disk that's already used
4. We're adding read-only disk that's already used as write-shared*
(because of I/O caching issues etc.)
The vif device duplicate check remains the same it was and it's
checked in the context of current domain only so that behaviour has
been preserved.
Signed-off-by: Michal Novotny <minovotn@redhat.com>
Benefits to blktap2 over the old version of blktap:
* Isolation from xenstore - Blktap devices are now created directly on
the linux dom0 command line, rather than being spawned in response
to XenStore events. This is handy for debugging, makes blktap
generally easier to work with, and is a step toward a generic
user-level block device implementation that is not Xen-specific.
* Improved tapdisk infrastructure: simpler request forwarding, new
request scheduler, request merging, more efficient use of AIO.
* Improved tapdisk error handling and memory management. No
allocations on the block data path, IO retry logic to protect
guests
transient block device failures. This has been tested and is known
to work on weird environments such as NFS soft mounts.
* Pause and snapshot of live virtual disks (see xmsnap script).
* VHD support. The VHD code in this release has been rigorously
tested, and represents a very mature implementation of the VHD
image
format.
* No more duplication of mechanism with blkback. The blktap kernel
module has changed dramatically from the original blktap. Blkback
is now always used to talk to Xen guests, blktap just presents a
Linux gendisk that blkback can export. This is done while
preserving the zero-copy data path from domU to physical device.
These patches deprecate the old blktap code, which can hopefully be
removed from the tree completely at some point in the future.
Signed-off-by: Jake Wires <jake.wires@citrix.com>
Signed-off-by: Dutch Meyer <dmeyer@cs.ubc.ca>
Tmem, when called from a tmem-capable (paravirtualized) guest, makes
use of otherwise unutilized ("fallow") memory to create and manage
pools of pages that can be accessed from the guest either as
"ephemeral" pages or as "persistent" pages. In either case, the pages
are not directly addressible by the guest, only copied to and fro via
the tmem interface. Ephemeral pages are a nice place for a guest to
put recently evicted clean pages that it might need again; these pages
can be reclaimed synchronously by Xen for other guests or other uses.
Persistent pages are a nice place for a guest to put "swap" pages to
avoid sending them to disk. These pages retain data as long as the
guest lives, but count against the guest memory allocation.
Tmem pages may optionally be compressed and, in certain cases, can be
shared between guests. Tmem also handles concurrency nicely and
provides limited QoS settings to combat malicious DoS attempts.
Save/restore and live migration support is not yet provided.
Tmem is primarily targeted for an x86 64-bit hypervisor. On a 32-bit
x86 hypervisor, it has limited functionality and testing due to
limitations of the xen heap. Nearly all of tmem is
architecture-independent; three routines remain to be ported to ia64
and it should work on that architecture too. It is also structured to
be portable to non-Xen environments.
Tmem defaults off (for now) and must be enabled with a "tmem" xen boot
option (and does nothing unless a tmem-capable guest is running). The
"tmem_compress" boot option enables compression which takes about 10x
more CPU but approximately doubles the number of pages that can be
stored.
Tmem can be controlled via several "xm" commands and many interesting
tmem statistics can be obtained. A README and internal specification
will follow, but lots of useful prose about tmem, as well as Linux
patches, can be found at http://oss.oracle.com/projects/tmem .
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
In the case where a device is attached to an inactive domain
and then removed before the domain is activated it won't have
a vslot assigned, but it should still be valid to remove it.
I don't think that there are any other cases where vslot can
be invalid.
Signed-off-by: Simon Horman <horms@verge.net.au>
This patch adds the option "superpages" to the domain configuration
file. If it is set, the domain is populated using 2M pages.
This code does not support fallback to small pages. If the domain can
not be created with 2M pages, the create will fail.
The patch also includes support for saving and restoring domains with
the superpage flag set. However, if a domain has freed small pages
within its physical page array and then extended the array, the
restore will fill in those freed pages. It will then attempt to
allocate more than its memory limit and will fail. This is
significant because apparently Linux does this during boot, thus a
freshly booted Linux image can not be saved and restored successfully.
Signed-off-by: Dave McCracken <dcm@mccr.org>
Remove *all* hardcoded "/etc/xen" strings in python code.
Additionally, it removes pygrub_path from osdep.py. Its use has been
replaced with auxbin.pathTo("pygrub").
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
In some configurations, when dom0 is busy with I/O, it may take
several minutes to complete all hotplug scripts required when a new
domain is being created. As device create timeout is set to 100
seconds, users get "hotplug scripts not working" error instead of a
new domain.
This patch makes both DEVICE_CREATE_TIMEOUT and DEVICE_DESTROY_TIMEOUT
configurable in xend-config.sxp to allow users to easily adapt hotplug
timeouts to their environment.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
This can greatly improve ssl relocation performance (to about 1/3
compared with buffersize 1024).
Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
In the case of inactive managed domains:
The following error occurs currently. We cannot change the
configuration of the VBD by using xm block-configure. Of course,
using xm block-detach and xm block-attach instead of xm
block-configure, we can change it. However, I'd like to change it by
using xm block-configure.
In the case of active domains:
Another problem occurs after a domain was rebooted. Even if we
change a configuration of a VBD in the domain by using xm
block-configure, the configuration of the VBD is reverted to previous
configuration after the domain was rebooted.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Keir Fraser