To workaround a race condition about guest hotplug, c/s
18338:7c10be016e4 disabled do_FLR when we create guest or 'xm
pci-attach' device into guest, so now we actually only do_FLR when a
guest is destroyed or 'xm pci-detach'.
By moving the FLR-related checking/do_FLR logic a little earlier, this
patch re-enables do_FLR in these 2 cases disabled by 18338.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Introduce new 'monitor_path' parameter, so that 'monitor' can revert
to its old type and meaning.
Fixes domain reboot and save/restore.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Allows par/ser ports to be configured with a path to backing device.
Allows qemu monitor to be disabled or redirected.
Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
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>
accordingly
-- currently firmware has got 'vcpus' from xend, this patch add parse
'vcpu_avail' to firmware;
-- setup madt 'lapic' subitems of processors accoring to vcpus and
vcpu_avail which finally come from config;
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
/etc/xen/xmexample.hvm says "" means "leave to Xen to pick", but we
get a "Error: string index out of range" currently.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
the "guest to a single NUMA node" constrain algorithm does not work
well when we do ballooning. Ballooning and NUMA don't play together
anyway, as Dom0 and thus ballooning is not NUMA aware, I am working on
this but it will not be ready for the Xen 4.0 release window. The
usual ballooning situation will result in an empty candidate list, as
no node has enough free memory to host the guest. In this case the
code will simply pick the first node: again and again, because all
nodes without enough memory will be ultimately penalized with the same
maxint value (regardless of the actual load). The attached patch will
change this to use a relative penalty in case of not-enough memory, so
that low-load low-memory nodes will be used at one point. A half
loaded node has shown to be a good value, as an unbalanced system is
much worse than non-local memory access for guests. Regardless of
that you should restrict the Dom0 on a NUMA system to a reasonable
memory size, so that ballooning is not necessary most of the time. In
this case the guest's memory will be NUMA local.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
You can see the following slides to understand the usage.
http://www.xen.org/files/xensummit_intel09/PVUSBStatusUpdate.pdf
Limitations:
"xm usb-hc-create" accepts up to 16 ports, but, current usbfront
can work with up to 15 ports. This may be bug and I'm preparing
to fix it.
This xm/xend support requires linux-2.6.18-xen.hg c/s 939 or above.
I recommend latest tip.
Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
Doesn't work when build-time python path differs from install-time. Do
we care about this given tools should be packaged/built for the
specific run-time distro?
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
I submitted a patch a while back to add keymap to vfb config for hvm
guests. This patch works fine for new config (xm create|new) but not
existing, managed guests. To cover the latter case I've introduced a
validator method in XendConfig.
Signed-off-by: Jim Fehlig <jfehlig@novell.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>
BaseException.message has been deprecated since Python 2.6. To
prevent DeprecationWarning from popping up over this pre-existing
attribute, use a new property that takes lookup precedence.
Signed-off-by: Wei Kong <weikong.cn@gmail.com>
this is patch to add maxvcpus support to xen xm command. It's using
vcpu_avail bitmask and sets the number of vcpus to maxvcpus if
present. If it's not present, old behavior is preserved.
In domain config file you can define it as follows:
maxvcpus = 4
vcpus = 2
this automatically sets vcpus to 4 and corresponding bitmask to
present 2 vcpus in the guest with option to increase it up to 4
vcpus. If maxvcpus is not present, the old behavior for vcpus is
preserved, ie. you can set vcpus to some number of vcpus to be used
and the vcpu_avail is set appropriately to use all of them. Only when
you use maxvcpus and vcpus new vcpu_avail value is calculated to show
PV guest the desired number of vcpus only.
It's been tested using RHEL-5 32-bit PV guest with maxvcpus = 4 and
vcpus = 2 and also the previous setup of vcpus = 2 only... In both
cases I was able to use 'xm vcpu-set {domainId} {numberOfVCPUs}' to
increase move vcpu count from 0 to maxvcpus/vcpus so it was working as
designed.
Signed-off-By: Michal Novotny<minovotn@redhat.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>
This patch adds support for XCP Windows paravirtual drivers to run on
Xen. The drivers are currently provided in binary-only format from
Citrix. At a minimum, this patch is useful for performance comparisons
vs GPLPV drivers.
Live migration and save/resume are functional but set the guest clock
to the 1970's. The clock must be manually adjusted for the guest's ntp
to resume accurate timekeeping.
Before rebooting windows at the end of driver installation create the
registry key
HKLM\System\CurrentControlSet\Services\xenevtchn\Parameters. Add to it
a DWORD called SetFlags with a value of 0x10000000.
Signed-off-by: Keith Coleman <keith@scaltro.com>
This patch fixes the following warning:
xen/lowlevel/checkpoint/libcheckpoint.c: In function
`delete_suspend_timer':
xen/lowlevel/checkpoint/libcheckpoint.c:352: warning: assignment
makes integer from pointer without a cast
Signed-off-by: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
with PCI pass-through to succesfully launch.
If the user hasn't used dom0_mem=3D bootup parameter, the privileged
domain usurps all of the memory. During launch of PV guests with PCI
pass-through we ratchet down the memory for the privileged domain to
the required memory for the PV guest. However, for PV guests with PCI
pass-through we do not take into account that the PV guest is going to
swap its SWIOTLB memory for DMA32 memory - in fact, swap 64MB of
it. This patch balloon's down the privileged domain so that there are
64MB of DMA32 memory available.
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
this patch fixes a couple of issues with pci passthrough in xend,
previously reported by Cui Dexuan.
The main problem is that xc_assign_device is called only for the first
device hotplugged into the guest and not the followings.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Alphabetize object files and guest config options for better
readability. Also remove svm interrupt prototypes which do not
exist.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
XenAPI (not xapi) has supported only LUN assignment mode for pvSCSI.
But at last, HOST assignment mode also is supported by these patches.
To support HOST assignment mode, these patches add PSCSI_HBA class
and DSCSI_HBA class to XenAPI.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Blktap2 port of remus disk driver. Backwards compatable with blktap1
implementation.
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
Signed-off-by: Brendan Cully <brendan@cs.ubc.ca>
Keir Fraser