This patch adds an explicit update mechanism:
make tools/ioemu-dir-force-update
This isn't brilliant but is better than doing "cd tools/ioemu-remote
&& git reset --hard <sha1...>" by hand.
Note that invoking this target will destroy all working tree changes
made to qemu-xen.
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 22381:2bedffabbcab
xen-unstable date: Tue Nov 09 18:15:25 2010 +0000
There are at least some syntax errors when trying to use the xen utils
with python2.6. The attached patch changes these string exception
into ValueErrors:
- tools/python/xen/util/bugtool.py (getBugTitle)
- tools/python/xen/xend (class XendBase): not catched
- tools/python/xen/xm/xenapi_create.py (sxp2xmlconvert_sxp_to_xml):
the method already raises a ValueError for similiar condition.
- tools/python/xen/xm/main.py (xm_network_attach): not catched.
For all but maybe the first one, the replacement of the string
exceptions into ValueErrors seems to be safe.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 22153:95c90bd63aed
xen-unstable date: Tue Sep 14 17:46:21 2010 +0100
Checking for RELATED,ESTABLISHED traffic being sent to a domU requires
connection tracking, which adds unexpected (to most users) load to
dom0. Heavily loaded systems can fill the conntrack tables.
So avoid this, be more liberal in what we accept, and leave it to domU
to police its own input.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22573:ff1b80ccecd9
xen-unstable date: Fri Dec 17 16:12:37 2010 +0000
tools/hotplug/Linux: supply --physdev-is-bridged in iptables runes
With newer (pvops) kernels logs get flooded with this iptables
warning: physdev match: using --physdev-out in the OUTPUT, FORWARD and
POSTROUTING chains for non-bridged traffic is not supported anymore
Using the --physdev-is-bridged option prevents this.
See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571634#10
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 22385:b0fe8260cefa
xen-unstable date: Wed Nov 10 14:37:19 2010 +0000
Allocate no memory and print no debug messages when disabled.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22567:f5f3cf4e001f
xen-unstable date: Thu Dec 16 20:07:03 2010 +0000
These absolutely guarantee to read/write a uint*_t with a single
atomic
processor instruction.
Also re-define atomic_read/atomic_write (act on atomic_t) similarly.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22564:aa33ab320f7e
xen-unstable date: Thu Dec 16 19:29:08 2010 +0000
NMI watchdog should be suppressed when dumping IRQ handlers. Softirqs
should be handled periodically while processing non-IRQ handlers.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22538:a3a29e67aa7e
xen-unstable date: Wed Dec 15 12:04:34 2010 +0000
This mirrors the RVI/shadow situation, where p2m read access is
lockless because it's done in the hardware (linear map of the p2m
table).
This fixes the original bug (call it bug A) without introducing bug B
(a deadlock).
Bug A was caused by a race when updating p2m entries: between testing
if it's valid, and testing if it's populate-on-demand, it may have
been changed from populate-on-demand to valid.
My original patch simply introduced a lock into ept_get_entry, but
that caused bug B, caused by circular locking order: p2m_change_type
[grabs p2m lock] -> set_p2m_entry -> ept_set_entry ->
ept_set_middle_level -> p2m_alloc [grabs hap lock] write cr4 ->
hap_update_paging_modes [grabes hap lock] -> hap_update_cr3 ->
gfn_to_mfn -> ept_get_entry -> [grabs p2m lock]
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 22526:7a5ee3800417
xen-unstable date: Wed Dec 15 10:47:05 2010 +0000
These two bugs apparently complement each other enough that
they escaped problems in my testing, but eventually gum
up the works and are obviously horribly wrong.
Found while developing tmem for native Linux.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
xen-unstable changeset: 22525:01f3b3509023
xen-unstable date: Wed Dec 15 10:27:18 2010 +0000
initial allocation size
As of c/s 21812:e382656e4dcc, IOMMU related allocations for Dom0
happen only after it got all of its memory allocated, and hence the
reserve (mainly for setting up its swiotlb) may get exhausted without
accounting for the necessary allocations up front.
While not precise, the estimate has been found to be within a couple
of pages for the systems it got tested on.
For the calculation to be reasonably correct, this depends on the
patch titled "x86/iommu: don't map RAM holes above 4G" sent out
yesterday.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22506:618ba64260fa
xen-unstable date: Tue Dec 14 09:54:10 2010 +0000
This follows some changes proposed for upstream Linux:
1. Do not check the FADT reset register size/offset
2. Try ACPI poking twice during our reset attempt sequence
Hopefully this will help us reset reliably on a wider range of
platforms.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22482:91e0556f4d46
xen-unstable date: Fri Dec 10 11:32:19 2010 +0000
x86: acpi: Fix reboot attempt sequence.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22483:901c118b363e
xen-unstable date: Fri Dec 10 16:40:05 2010 +0000
Rename to 'creat', which does not conflict.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22481:0353037c6b95
xen-unstable date: Fri Dec 10 11:01:19 2010 +0000
A couple of new hvm_op commands were erroneously ifdef'ed to be
accessible only to the toolstack.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 22082:0eb89b465e46
xen-unstable date: Wed Sep 01 10:17:29 2010 +0100
hvm_op: Remove use of uint64_aligned_t from guest header file.
Manually pad to the required alignment instead.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 22090:4a628af0355c
xen-unstable date: Thu Sep 02 13:30:26 2010 +0100
Xen absolute system time, so that it can use SCHEDOP_poll in a
sensible fashion. HVM PV drivers can't use the normal PV clock
because they might have TSC offsets that hey don't know about.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 21772:2662f9c881fa
xen-unstable date: Fri Jul 09 17:16:03 2010 +0100
Guest vcpu may totally lose all ticks if the vlapic->pt.irq was not
restored during save/restore process. Fix it.
Signed-off-by: Wei Gang <gang.wei@intel.com>
xen-unstable changeset: 22470:0c97247c64d6
xen-unstable date: Thu Dec 09 08:34:59 2010 +0000
These two ASSERTs have important side-effects so make them into
BUG_ONs
consistent with the rest of the file.
Bug found by Jui-Hao Chiang <juihaochiang@gmail.com>.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 22467:89116f28083f
xen-unstable date: Wed Dec 08 10:46:31 2010 +0000
Since (non-pvops, 32-bit only up to 2.6.27) Linux would report "BAD"
unconditionally on all SiS chipset versions (it only looks for a PCI
device at 0000:00:00.0 with SiS as the vendor), we must not crash if
the report on a 64-bit hypervisor doesn't match the #define (which is
zero).
While we could honor the quirk indication even on 64-bit, it doesn't
seem worthwhile, as there's no evidence that newer SiS chipsets
(supporting 64-bit CPUs) are actually affected.
This should also address bug 1687 (mis-reported, however, afaict).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22466:bfd13358b8bf
xen-unstable date: Tue Dec 07 18:32:04 2010 +0000
In directed-EOI mode, there is no chance to do the migration in
mask_and_ack_level_ioapic_irq(), as the remote IRR bit can't possibly
be clear after issuing the EOI to the LAPIC. Consequently, there's no
point to even try. Instead, migration must be done in
end_level_ioapic_irq(), and it requires masking the interrupt source
prior to issuing the EOI to the IO-APIC.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22452:62bf12040b0f
xen-unstable date: Wed Dec 01 20:10:27 2010 +0000
Apparently required back in the earliest days of Xen, we now properly
initialise CPU capabilities early during bootstrap. Re-writing
capability data later now causes problems if specific features have
been deliberately masked out.
Thanks to Weidong Han at Intel for finding such a bug where XSAVE
feature is masked out by default, but then erroneously written back
during VMX initialisation. This would cause memory corruption problems
during boot for XSAVE-capable systems.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22451:8420b82c22c2
xen-unstable date: Tue Nov 30 11:34:08 2010 +0000
Even not-so-recent Linux may, due to post-2.6.18 changes to the
process creation code, cause quite a number (depending on environment
and argument size) of faulting accesses to user space originating from
kernel mode. Generally those happen for non-present pages and would
lead to a nested page fault from guest_get_eff_l1e(). They can be
avoided by checking for PFEC_page_present as long as the guest isn't
running on shadow page tables.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22449:3afb5ecbf69f
xen-unstable date: Mon Nov 29 14:40:55 2010 +0000
handle_gdt_ldt_mapping_fault() is intended to deal with indirect
accesses (i.e. those caused by descriptor loads) to the GDT/LDT
mapping area only. While for 32-bit segment limits indeed prevent the
function being entered for direct accesses (i.e. a #GP fault will be
raised even before the address translation gets done, on 64-bit even
user mode accesses would lead to control reaching the BUG_ON() at the
beginning of that function.
Fortunately the fix is simple: Since the guest kernel runs in ring 3,
any guest direct access will have the "user mode" bit set, whereas
descriptor loads always do the translations to access the actual
descriptors as kernel mode ones.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Further, relax the BUG_ON() in handle_gdt_ldt_mapping_fault() to a
check-and-bail. This avoids any problems in future, if we don't
execute x86_64 guest kernels in ring 3 (e.g., because we use a
lightweight HVM container).
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22448:5cd9612db2bb
xen-unstable date: Mon Nov 29 14:34:32 2010 +0000
Fix an issue on Nehalem cpus where performance counter overflows may
lead to endless interrupt loops on this cpu.
Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
xen-unstable changeset: 22417:c0c1f5f0745e
xen-unstable date: Mon Nov 22 19:16:34 2010 +0000
hvmloader is responsible for - amoungst other things - initialising
the PCI device BARs prior to loading the guest BIOS. The previous
code only probed for devfn up to 128. The lower 3 bits are function
IDs so this meant that only devices in slots 0-15 were actually being
initialized.
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Acked-by: Gianni Tedesco <gianni.tedesco@citrix.com>
xen-unstable changeset: 22383:cba667fb80cf
xen-unstable date: Wed Nov 10 13:58:16 2010 +0000
hvmloader: Fix 22383:cba667fb80cf iterating over defns 0..255
We need to declare devfn as wider than 8 bits for a loop 0<devfn<256
to terminate.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22384:c19e3371f31b
xen-unstable date: Wed Nov 10 14:15:23 2010 +0000
Should be checking against physaddr width presented to teh guest,
rather than the host physaddr width.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 22374:9997a1418633
xen-unstable date: Tue Nov 09 11:48:43 2010 +0000
Not checking leads to warn_unused_result checks triggering in some
libraries and compilers. Combined with -Werror this breaks the build.
Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 22349:3f98881703aa
xen-unstable date: Wed Nov 03 11:58:25 2010 +0000
The following is the process of booting a DomU with 'mounted-blktap2'
(VHD
for example) and 'pygrub' as bootloader:
1. Connect boot-device to Dom0 as '/dev/xpvd'
2. Pygrub get info for load DomU
3. Disconnect boot-device from Dom0
4. Boot DomU
During step 3 the created device is disconnected from Dom0, but
xenstore does not scrape away after the device is disconnected so you
get the following error:
"Error: Device /dev/xvdp (51952, tap2) is already connected."
During step 3 xend calls destroyDevice always with 'tap' as argument.
Signed-off-by: eXeC001er <execooler@gmail.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xen-unstable changeset: 21999:cd5b4135fe03
xen-unstable date: Mon Aug 16 17:11:30 2010 +0100
This patch fixes compilation issues with
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21).
Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 22023:af6799abc6e9
xen-unstable date: Wed Aug 18 16:48:25 2010 +0100
If the device at <secbus>:00.0 is the device the mapping operation was
initiated for, trying to map it a second time will fail, and hence
this second mapping attempt must be prevented (as was done prior to
said c/s).
While at it, simplify the code a little, too.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Weidong Han <weidong.han@intel.com>
xen-unstable changeset: 22348:2dfba250c50b
xen-unstable date: Wed Nov 03 08:18:51 2010 +0000
Some of these could be benignly discarded by the compiler but some are
actual bugs.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 22336:49803ac994f4
xen-unstable date: Fri Oct 29 18:05:50 2010 +0100
c/s 13829 lost the (32-bit only) cpu_has_pae argument passed to the
primary kernel's stub (in the 32-bit Xen case only), and Linux
2.6.27/.30 (32-/64-bit) introduced a new argument (for KEXEC_JUMP)
which for now simply gets passed a hardcoded value.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22280:d6e3cd10a9a6
xen-unstable date: Sun Oct 24 13:15:06 2010 +0100
The memory allocation code sometimes needs to enforce that a guest
that's been told to balloon down isn't going to expand further
(because it's still executing a previous balloon-up operation). That
means being able to set the desired max_pages even before the balloon
driver has brought tot_pages down to the right level.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 22279:2208a036f8d9
xen-unstable date: Sun Oct 24 13:13:04 2010 +0100
To properly ignore some requests through the use of continue;, indexes
need to
be updated.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
committer: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xen-unstable changeset: 22236:6e8dd34122e7
xen-unstable date: Tue Oct 12 10:27:56 2010 +0100
This workaround is taken from Linux, and the main motivation (besides
such workarounds indeed belonging in the hypervisor rather than each
kernel) is to suppress the warnings in the Xen log each Linux guest
would cause due to the disallowed wrmsr.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22232:eb964c4b4f31
xen-unstable date: Mon Oct 11 09:02:36 2010 +0100
Keir Fraser