Without this patch, loading a bzimage dom0 kernel while also
requesting a dynamically-allocated crashkernel area is broken.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
this patch makes libxl_create_stubdom wait for pv qemu to be properly
initialized before unpausing the stubdom.
A new libxl_device_model_starting pointer is used to wait for pv qemu
initialization while the libxl_device_model_starting pointer given by
the user is initialized to a new structure with an empty for_spawn
member, because nothing that was spawn has to be waited for anymore.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This attempts to address all the concerns raised in
http://lists.xensource.com/archives/html/xen-devel/2009-11/msg01195.html,
but I'm nevertheless still not convinced that all aspects of the
injection handling really work reliably. In particular, while the
patch here on top of the fixes for the problems menioned in the
referenced mail also adds code to keep send_guest_trap() from
injecting multiple events at a time, I don't think the is the right
mechanism - it should be possible to handle NMI/MCE nested within
each other.
Another fix on top of the ones for the earlier described problems is
that the vCPU affinity restore logic didn't account for software
injected NMIs - these never set cpu_affinity_tmp, but due to it most
likely being different from cpu_affinity it would have got restored
(to a potentially random value) nevertheless.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
I did some benchmark runs (lmbench & kernel compile) with a number of
guests running in parallel to compare the performance of numa=on vs.
numa=off. As soon as one starts to load the machine, the performance
goes down in the numa=off case. The tests were done on an 8-node
machine (4 cores each). lmbench (actually copying large amounts of
memory) shows a dramatic dropdown, but I even noticed significant
performance decrease for a tmpfs based Linux kernel compile. Here a
summary of the data:
lmbench's rd benchmark (normalized to native Linux (=100)):
guests numa=off numa=on avg increase
min avg max min avg max
1 78.0 102.3
7 37.4 45.6 62.0 90.6 102.3 110.9 124.4%
15 21.0 25.8 31.7 41.7 48.7 54.1 88.2%
23 13.4 17.5 23.2 25.0 28.0 30.1 60.2%
kernel compile in tmpfs, 1 VCPU, 2GB RAM, average of elapsed time:
guests numa=off numa=on increase
1 480.610 464.320 3.4%
7 482.109 461.721 4.2%
15 515.297 477.669 7.3%
23 548.427 495.180 9.7%
again with 2 VCPUs and make -j2:
1 264.580 261.690 1.1%
7 279.763 258.907 7.7%
15 330.385 272.762 17.4%
23 463.510 390.547 15.7% (46 VCPUs on 32pCPUs)
Selected tests on a 4-node machine showed similar behavior (7.9 %
increase with 6 parallel guests on the 2 VCPU kernel compile
benchmark).
Note that this does not affect non-NUMA machines at all, since NUMA
will be turned off again by the code if no NUMA topology is detected.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Enable turning on a different amount of vcpus than
the maximum during domain creation/restore.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
Allow domain to publish its suspend event channel.
Otherwise, the fast event-channel-based suspend
path is disabled.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
Write cpu availability paths to xenstore. Otherwise,
no vcpus other than the first are enabled.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
Set domain handle much like xend does, identical to
the uuid. This allows obtaining the uuid of a domain
from the handle in the dominfo struct.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
- Use proper constants
- Use functions from the uuid library
- Fix broken pointer handling in libxl_dominfo
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
Prevent segmentation fault caused by empty values
in key-value pairs for the /vm/ subdirectory
when creating a pv domain.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
I've created a patch that alters dom0 statistics (if empty like in
case of network bonding) and puts network bridge statistics
instead. It's been tested with network bonding both enabled and
disabled and also by creating a standalone network bridge without
bonding... It was working fine in all my tests...
Signed-off-by: Michal Novotny <minovotn@redhat.com>
I was starting some documentation for tsc_mode and
realized this discussion was never resolved. Currently
when TSC is emulated the pvclock algorithm reports
to a PV OS Xen's system clock hz rate (1GHz). Linux
at boottime samples the TSC rate and shows it in
dmesg and the rate is also shown in the "cpu MHz"
field in /proc/cpuinfo. So when TSC is emulated,
it appears that the processor MHz is 1000.0, which
is likely to be confusing to many Xen users.
This patch changes the reported hz rate to the
hz rate of the initial machine on which the guest
is booted and retains that reported hz rate across
save/restore/migration.
Jeremy has pointed out that reporting 1000.0 MHz is
useful because it shows that TSC is being emulated.
However, with the new tsc_mode default where
a guest may start with native TSC and switch to
emulated TSC after migration, users are likely to
get even more confused. And "xm debug-key s"
reveals not only whether TSC is being emulated but
also the frequency so is more descriptive anyway.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
This patch fixes a possible segfault when reading from
/sys/class/blktap2/devices, if the line read is empty.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
libxenlight doesn't handle properly the multiple pv console case,
needed to support an emulated serial in hvm guests with stubdoms.
This patch fixes it.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This patch implements blktap2 support in libxenlight; blktap2 is only
enabled if it is actually supported by the host, otherwise we fall
back to the previous code. Also for the moment we pretend that disk
type file is actually tap:aio.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
set_p2m_entry() ignores halfway errors.
It should return 0 on error.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
this patch adds domain pause and unpause commands to xl, implementing
them using the already exiting functions libxl_domain_pause and
libxl_domain_unpause.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
At the same time, replace a lengthy linear GPE notification method,
with a logarithmic binary chop. Based on a patch by Simon Horman.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
For xen's irq and gsi, they are identity mapped, and doesn't
need to record the irq and gsi mapping in this array, in addition
the mapping maybe not correct, since dom0 may not figure the GSI
from 16 on.
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
There are some cases that shadow_write_p2m_entry() is called after
the domain is killed. It causes Xen to crash.
- Race between xc_map_foreign_batch from qemu-dm and "xm destroy"
command.
- The hypervisor calls domain_crash when PoD fails.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
The rdtscp instruction (and the associated TSC_AUX
msr) are present on most recent AMD processors,
and on the Nehalem and future Intel processors.
Cpuid has a bit to detect the presence of this feature.
Xen intentionally does not expose the cpuid rdtscp bit
to PV OS's or to HVM guests, but PV apps can see this
bit and, as a result, may choose to use the rdtscp
instruction. When a PV guest with such an app is migrated
to a machine that does not have rdtscp support, the
app will get killed due to an invalid op. Fix this
by emulating the rdtscp instruction. We also need
to emulate rdtscp in the case where the machine has
rdtscp support, but rdtsc emulation is enabled (which
is unfortunately a different path: a privileged op).
The rdtscp instruction reads the TSC_AUX register which
presumably is set by the OS (and, in the case of
tsc_mode==pvrdtscp, will be set by Xen). HV Linux
and PV Linux will not set TSC_AUX because the
cpuid rdtscp bit is not propogated by Xen; I'm told that
Windows always sets TSC_AUX to zero. So for PV guests
running on rdtscp-capable hardware (that don't use
tsc_mode==pvrdtscp), always set TSC_AUX to zero.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Keir Fraser