The Xen tools contain a number of Python extensions written in C. The
C API to Python, used by these extensions, is not stable from one
version of Python to the next.
Our build system uses whatever version of Python is the default on the
build system at that time to build these extensions. However, the
actual scripts such as `xm' use #!/usr/bin/env python which uses
whichever version of Python is the default on the deployment system at
the time of invocation.
If for any reason these two versions of Python are not the same (eg,
because the system is built on one computer and executed on another,
or because the system's gains a more recent Python installation
alongside the original which changes the previous default), warnings
and failures occur.
In this patch I arrange for Python scripts to be installed via a
special wrapper around `install', which determines the build-time
Python version and path and then writes that into the #! line at the
point of `make install' (or `make dist'). (It can also be overridden
by setting PYTHON_PATH.)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
In xend/balloon.py, there's only one place where dom0_start_alloc_mb
is used. Move its initialization to right before its usage.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Attached patch uses calloc() for hash allocation.
This makes sure, the allocated memory is always initialized.
Also cleanup error handling a bit.
On *BSD avoid conflicts with BSD list macros.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Overview: update xenstat vbd statistics parsing from
/sys/devices/xen-backend to process blktap disks
Reason:
-blktap devices (now referenced as tap rather than vbd in
/sys) have statistics counters
(e.g., rd_req, wr_req, oo_req) prepended by tap_
-xenstat behavior did not previously account for this
behavior, which resulted in 0 disks
visible and similarly impacted disk statistics
To reproduce these conditions, make a domain with tap:aio backed disks
on 3.2.x, run xentop, and press B to view VBD stats (nothing will
appear for the domain using tap:aio)
Signed-off-by: steve.maresca@gmail.com
Older PAE guests (prior to xen-unstable.hg 8924:229c602a075a, Feb
2006, this includes some vendor's kernel in the field) use a limit of
0xf6800000 on their code and data segments (i.e. up to the end of the
read-only m2p table).
Newer kernels use a limit of 4G and rely on the hypervisor to clamp to
the actual maximum allowed. 32on64 mode takes advantage of this to
allow a larger m2p than would fit in the PAEonPAE sized hole.
This means that PAE guests with the hardcoded low limit cannot run on
top of a 64 bit hypervisor on a host machine which has more than 16G
of RAM. Fix this by extending any code or data segment which ends
above the start of the hypervisor hole for that guest.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
If we don't use PIT, we should disable it at boot time and at S3
resuming. In Xen this is done by disable_pit_irq(), but this function
is used by __initcall(). After bootstrap it will be discarded and may be
overwritten. This usually results in S3 resuming failure.
Signed-off-by: Huacai Chen <huacai.chen@intel.com>
Signed-off-by: Li Zhang <li.zhang@intel.com>
Xen tracing some times ago used to put values of type 'long' into the
trace buffer. This has changed to uint32_t. Some trace points log
virtual addresses, which get cropped to 32bit in this case. There were
some inline functions to handle at least PF_XEN and VMEXIT, which
caused a lot of code duplication. The attached patch fixes several
issues:
1. fix and extend tools/xentrace/formats
2. Fix xentrace_format to handle up to 7 parameters
3. create convenience macros to properly log long values
4. remove the inline functions in hvm/trace.h and replace them by macros
5. Change the CPUID trace to work correctly
6. group HVM trace points enable mechanism
I used a similar approach as in PV tracing with bit 8 indicating 64bit
pointers.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Assuming iommu_populate_page_table() is only used for PV guest, a new
check is added into assign_device() to avoid duplicating the work done
by amd_iommu_sync_p2m() for hvm guest.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
Bring the DisplayState dpy_resize interface back to how it is in qemu
mainstream, thus making the code easier to merge.
In order to support sharing the framebuffer, I am adding a new resize
interface called dpy_resize_shared that also has a depth and a pixels
parameters. As a consequence I could remove the dpy_colourdepth
callback and make the code cleaner and easier to read.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
If device_model is set to '', xend will fail to execute the device
model. If None, xend will detect it and set a sensible qemu-dm path
instead.
Signed-off-by: Yosuke Iwamatsu <y-iwamatsu@ab.jp.nec.com>
The following patch provides a 'fast-path' for sh_remove_write_access()
for 64 bit Solaris HVM guests. This provides a significant performance
boost for such guests; our testing shows a 200-400% improvement in
microbenchmarks such as fork(), exit(), etc...
From: Gary Pennington <Gary.Pennington@sun.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
I defined a cdrom to a guest domain as follows.
",hdc:cdrom,r"
When the guest domain was created by using xm create command, uname
of the cdrom was ''. Then creating the guest domain succeeded.
[2008-06-03 15:23:41 xend.XendDomainInfo 25956] DEBUG
(XendDomainInfo:200)
XendDomainInfo.create(['vm', ['name', 'rhel5.2ga_hvm_lvol1'],
<<snip>>
['device', ['vbd', ['uname', ''], ['dev', 'hdc:cdrom'], ['mode',
'r']]],
<<snip>>
But, when the guest domain was created by using virsh start command,
uname of the cdrom was None. Then creating the guest domain failed.
[2008-06-03 15:22:10 xend.XendDomainInfo 25559] DEBUG
(XendDomainInfo:200)
XendDomainInfo.create(['vm', ['name', 'rhel5.2ga_hvm_lvol1'],
<<snip>>
['device', ['vbd', ['dev', 'hdc:cdrom'], ['mode', 'r']]],
<<snip>>
This patch fixes to be able to create guest domains by both xm create
command and virsh start command.
FYI:
"if uname is None:" --> "if uname == '':" --> "if not uname:"
till CS#17625 current by this patch
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
HPET intr-near-missing means if the current counter value is too close
to the comparator value to be reprogrammed the expected HPET intr may
be missing. Linux kernel uses a mininal 48-hpet-ticks(~3.5us) distance
to workaround this, but personal observation showed there is still
failure case while delta=3D0xba (~13.5us). So choosing 20us as the
MIN_DELTA_NS should be helpful to prevent near-missing from happening.
local_irq_save/restore were used to avoid disturbance. (+ 2) was used
as a final guard to avoid wrong judgement due to the real happened
near-missing case.
Signed-off-by: Wei Gang <gang.wei@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Keir Fraser