| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
We can globally export it from xen/Makefile instead, as all hypervisor
builds have this Makefile at their root.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23048:5069eaaa9f79
xen-unstable date: Thu Mar 17 08:04:10 2011 +0000
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise make can search the path relative to certain standard paths
such as /usr/include (e.g., the line '-include $(XEN_ROOT)/.config' in
Config.mk suffers from this).
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23049:ff3b7749008b
Backport-requested-by: Allen M Kay <allen.m.kay@intel.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pcidevs is an array of ndev elements (ndev is the number of pci devices
assigend to a specific domain), but we access pcidevs + *num
where *num is the global number of pci devices assigned so far to all
domains in the system.
Fix the issue removing pcidevs and just realloc'ing *list every time we
want to add a new pci device to the array.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23685:5239811f92e1
Backport-requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
clear_mmio_p2m_entry() should mark the gfn as invalid.
Use proper name instead of numerical value. The currently used value of
zero means p2m_ram_rw.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 23898:3d1664cc9e45
xen-unstable date: Thu Oct 06 12:52:18 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the build produces lots of
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
This is due to the "grep -- $(2)" in cc-options. It seems that the
default of reading stdin is disabled when using "--". I don't know if
this is a bug in grep or how it is supposed to be but we can work
around it by explicitly passing in "-"
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23898:3d1664cc9e45
xen-unstable date: Fri Sep 30 21:17:47 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
revision
This patch originally comes from the Linus mainline kernel (2.6.33),
find below the patch details:
From: Andreas Herrmann <herrmann.der.user@googlemail.com>
There is no point in warning when there is no ucode available
for a specific CPU revision. Currently the container-file, which
provides the AMD ucode patches for OS load, contains only a few
ucode patches.
It's already clearly indicated by the printed patch_level
whenever new ucode was available and an update happened. So the
warning message is of no help but rather annoying on systems
with many CPUs.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23871:503ee256fecf
xen-unstable date: Thu Sep 22 18:35:30 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
| |
(base_addr,end_addr) is an inclusive range, and hence there shouldn't
be a subtraction of 1 in the second invocation of page_is_ram_type().
For RMRRs covering a single page that actually resulted in the
immediately preceding page to get checked (which could have resulted
in a false warning).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23868:28147fd781af
xen-unstable date: Thu Sep 22 18:32:34 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Looking more closely at usage of action field with relation to
IRQ_GUEST flag. It appears that set IRQ_GUEST implies that action
is not NULL. As result it is not safe to set action to NULL and
leave IRQ_GUEST set.
Hence IRQ_GUEST should be cleared in dynamic_irq_cleanup where
action is set to NULL.
An addition remove BUGON at __pirq_guest_unbind that appears to be
bogus and not needed anymore.
Thanks Paolo Bonzini for NACKing previous patch, and pointing at the
correct solution.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reinstate the BUG_ON, but after the action==NULL check. Since we then
go and start interpreting action as an irq_guest_action_t, the BUG_ON
is relevant here.
More generally, the brute-force nature of dynamic_irq_cleanup() looks
a bit worrying. Possibly there should be more integratioin with
pirq_guest_unbind() logic, for cleaning up un-acked EOIs and the like.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23852:c944e82bb092
xen-unstable date: Sun Sep 18 00:00:26 2011 +0100
|
|
|
|
|
|
|
|
| |
Do not free() list manually - it will be freed by libxl__free_all.
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qemu is used as a fallback for DISK_BACKEND_TAP if no blktap is
available but if blktap is available, or for DISK_BACKEND_PHY, we
don't need a qemu process.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23044:d4ca456c0c25
xen-unstable date: Tue Mar 15 18:19:47 2011 +0000
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If vmx_vcpu_up() failed, __vmxon() would generally not have got
(successfully) executed, and in that case __vmxoff() will #UD.
Additionally, any panic() during early resume (namely the tboot
related one) would cause vmx_cpu_down() to get executed without
vmx_cpu_up() having run before.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23848:cf37d2eec2ef
xen-unstable date: Sat Sep 17 16:26:37 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AMD CPUs by default enable X86_FEATURE_TSC_RELIABLE, and depend upon a
later check to disable this feature if TSC drift is detected.
Unfortunately, this check is done in time.c:init_xen_time(), which is
done before any secondary CPUs are brought up, and is thus guaranteed
to succed.
This patch moves the check into its own function, and calls it after
cpus are brought up.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 23846:bf2aaf21e8e7
xen-unstable date: Sat Sep 17 16:22:54 2011 +0100
|
|
|
|
|
|
|
|
|
|
| |
Selecting the scheduler to call must be done under lock. Otherwise a
race might occur when switching schedulers in a cpupool
Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 23843:6684e3bafbbd
xen-unstable date: Sat Sep 17 16:19:26 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23655:7e4404a8f5f9
xen-unstable date: Mon Jul 04 07:57:32 2011 +0100
x86: Remove redundant cpuid-faulting-related BUG_ON I added.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23654:122fcf37c596
xen-unstable date: Sat Jul 02 09:08:27 2011 +0100
x86: cpuid faulting feature enable
Latest Intel processor add cpuid faulting feature. This patch is used
to support cpuid faulting in Xen. Like cpuid spoofing, cpuid faulting
mainly used to support live migration. When cpuid faulting enabled,
cpuid instruction runs at cpl>0 will produce GP, vmm then emulate
execution of the cpuid instruction. Hence will appear to guest
software the value chosen by the vmm.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23653:71b58748cfee
xen-unstable date: Fri Jul 01 22:28:53 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old io_apic_eoi() function using the EOI register only works for
IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI
register so line level interrupts have to be EOI'd by flipping the
mode to edge and back, which clears the IRR and Delivery Status bits.
This patch replaces the current io_apic_eoi() function with one which
takes into account the version of the IO-APIC and EOI's
appropriately.
v2: make recursive call to __io_apic_eoi() to reduce code size.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
xen-unstable changeset: 23833:ffe8e65f6687
xen-unstable date: Tue Sep 13 10:33:10 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
| |
PV on HVM guests can have more GSIs than the host, in that case we
could run out of pirq < nr_irqs_gsi. When that happens use pirq >=
nr_irqs_gsi rather than returning an error.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Benjamin Schweikert <b.schweikert@googlemail.com>
xen-unstable changeset: 23832:ad3b4bb097cb
xen-unstable date: Tue Sep 13 10:32:24 2011 +0100
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
... as long as it has non-zero size. So far this would not happen if
the passed in CPU mask was empty.
Also fix the comment describing the return value to actually match
reality.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23820:ba75234a6f56
xen-unstable date: Wed Sep 07 10:36:55 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the isa irq corresponding to a particular gsi is disabled while the
gsi is enabled, __hvm_pci_intx_assert will always inject the gsi
through the violapic, even if the gsi has been remapped onto a pirq.
This patch makes sure that even in this case we inject the
notification appropriately.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xen-unstable changeset: 23807:2297b90a6a7b
xen-unstable date: Wed Aug 31 15:23:34 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hvm_domain_use_pirq should return true when the guest is using a
certain pirq, no matter if the corresponding event channel is
currently enabled or disabled. As an additional complication, qemu is
going to request pirqs for passthrough devices even for Xen unaware
HVM guests, so we need to wait for an event channel to be connected
before considering the pirq of a passthrough device as "in use".
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xen-unstable changeset: 23806:4226ea1785b5
xen-unstable date: Wed Aug 31 15:23:12 2011 +0100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When migrating IO-APIC line level interrupts between PCPUs, the
migration code rewrites the IO-APIC entry to point to the new
CPU/Vector before EOI'ing it.
The EOI process says that EOI'ing the Local APIC will cause a
broadcast with the vector number, which the IO-APIC must listen to to
clear the IRR and Status bits.
In the case of migrating, the IO-APIC has already been
reprogrammed so the EOI broadcast with the old vector fails to match
the new vector, leaving the IO-APIC with an outstanding vector,
preventing any more use of that line interrupt. This causes a lockup
especially when your root device is using PCI INTA (megaraid_sas
driver *ehem*)
However, the problem is mostly hidden because send_cleanup_vector()
causes a cleanup of all moving vectors on the current PCPU in such a
way which does not cause the problem, and if the problem has occured,
the writes it makes to the IO-APIC clears the IRR and Status bits
which unlocks the problem.
This fix is distinctly a temporary hack, waiting on a cleanup of the
irq code. It checks for the edge case where we have moved the irq,
and manually EOI's the old vector with the IO-APIC which correctly
clears the IRR and Status bits. Also, it protects the code which
updates irq_cfg by disabling interrupts.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
xen-unstable changeset: 23805:7048810180de
xen-unstable date: Wed Aug 31 15:19:24 2011 +0100
|
|
|
|
|
|
| |
Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
xen-unstable changeset: 23803:51983821efa4
xen-unstable date: Wed Aug 31 15:17:45 2011 +0100
|
|
|
|
|
|
|
|
|
|
| |
Just assume disk as not removable when no 'removable' paremeter
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
xen-unstable changest: 23607:2f63562df1c4
Backport-requested-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Previously PyString_FromString(NULL) was called, which caused assertion
failure.
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
xen-unstable changest: 23606:cc2f376d0cd9
Backport-requested-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Memory for strings in libxl_device_disk must be allocated from outside of
libxl__gc to not be freed at the end of function (by libxl__free_all).
Fixes xl block-detach
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
xen-unstable changest: 23603:6656d80b4de4
Backport-requested-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
| |
Accept disk name in xl block-detach.
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
xen-unstable changest: 23604:5d7998be2252
Backport-requested-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleanup frontend and backend devices from xenstore for all dev types - not only
disks. Because backend cleanup moved to libxl__device_destroy,
libxl__devices_destroy is somehow simpler.
Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
xen-unstable changest: 23605:ff8d170852b3
Backport-requested-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23600:15fc211a13bf
Backport-requested-by: Shriram Rajagopalan <rshriram@gmail.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the end of a checkpoint, when a new flush (of buffered disk writes)
is merged with ongoing flush, we have to make sure that none of the new
disk I/O requests overlap with ones in in progress. If it does, hold the
request and dont issue I/O until the overlapping one finishes. If we allow
the I/O to proceed, we might end up with two overlapping requests in the
disk's queue and the disk may not offer any guarantee on which one is
written first.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23414:ecff559bf474
Backport-requested-by: Shriram Rajagopalan <rshriram@gmail.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DRBD disk backends can be used instead of tapdisk backends for Remus.
This requires a Remus style disk replication protocol (asynchronous
replication with output buffering at backup), that is not available in
standard DRBD code. A modified version that supports this new replication
protocol is available from git://aramis.nss.cs.ubc.ca/drbd-8.3-remus
Use of DRBD disk backends provides a means for efficient
resynchronization of data after the crashed machine comes back
online. Since DRBD allows for online resynchronization, a DRBD backed
Remus VM does not have to be stopped or shutdown while the disks are
resynchronizing. Once resynchronization is complete, Remus can be
started at will.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23413:62c0dfc9efbf
Backport-requested-by: Shriram Rajagopalan <rshriram@gmail.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parsing /otc/source/vtd/xen-unstable/tools/python/../../tools/libxl/libxl.idl
File "/usr/lib64/python2.4/site-packages/xen/remus/save.py", line 169
finally:
^
SyntaxError: invalid syntax
This was introduced in 23195:13ec53a59a42
It is a problem for Python 2.4 and earlier, only.
So use try...(try...except)...finally as suggested by Ian Campbell.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23379:b04e57ec4671
Backport-requested-by: Shriram Rajagopalan <rshriram@gmail.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new --null option allows one to test and play with just the
memory checkpointing and network buffering aspect of remus, without
the need for a second host. The disk is not replicated. All replication
data is sent to /dev/null. This option is pretty handy when a user
wants to see the page churn for his workload or observe the latency hit
though the latter will not be accurate.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23196:29d81623dc14
Backport-requested-by: Shriram Rajagopalan <rshriram@gmail.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
current check includes ingress and pfifo_fast.
Add mq to the list of allowed qdiscs already installed
on ifb. This patch fixes cases where remus fails to start,
due to an mq qdisc already present on the vif.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23109:c8ae80a11d47
Backport-requested: Shriram Rajagopalan <rshriram@gmail.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|\ |
|
| |
| |
| |
| | |
Signed-off-by: Tim Deegan <tim@xen.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In line with 22924:86000076dcee, paging_mode_hap(d) shouldn't be
used in HAP internals that are called during HAP setup.
Signed-off-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 23789:1b77cf8305df
xen-unstable date: Tue Aug 23 10:54:27 2011 +0100
|
| |
| |
| |
| |
| |
| |
| |
| | |
This makes the check more precise, and brings VTd in line with AMD code.
Signed-off-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 23788:9d2a8912597d
xen-unstable date: Tue Aug 23 10:43:25 2011 +0100
|
| |
| |
| |
| |
| |
| |
| |
| | |
because the cached version isn't set up until the EPT init happens.
Signed-off-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 23787:41f00cf6b822
xen-unstable date: Tue Aug 23 10:43:20 2011 +0100
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The help text for xm create's --dry-run says "Dry run - prints the
resulting configuration in SXP but does not create the domain." so
update xl implementation to match. At least the xendomains initscript
relies on this (for better or worse).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Carsten Schiers <carsten@schiers.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23467:2ae357405850
Backport-requested: Carsten Schiers <carsten@schiers.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
xendomains service now working also without xend service
Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23673:0648846b4d17
Backport-requested: Carsten Schiers <carsten@schiers.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
being printed by "xl list -l" command. so update xl implementation to
match.
Signed-off-by: Carsten Schiers <carsten@schiers.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23567:c2995f0555af
Backported-by: Carsten Schiers <carsten@schiers.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
|
| |
|