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
Walking the pinned-shadows list isn't enough: there could be an
unpinned (but still shadowed) l3 somewhere and if we later try to
unshadow it it'll have an up-pointer of PAGE_LIST_NULL:PAGE_LIST_NULL.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 22224:a4016a257672
xen-unstable date: Sat Oct 02 15:05:50 2010 +0100
The patch is derived from a similar quirk in Linux kernel by David
Woodhouse and Adam Jackson. It checks for VT enabling bit in IGD GGC
register. If VT is not enabled correctly in the IGD, Xen does not
enable VT-d translation for IGD VT-d engine. In case where iommu boot
parameter is set to force, Xen calls panic().
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
xen-unstable changeset: 22223:4beee5779122
xen-unstable date: Sat Oct 02 15:04:21 2010 +0100
With the change to index irq_desc[] by IRQ rather than by vector, the
prior implicit change of the used flow handler when altering the IRQ
routing path to go through the 8259A didn't work anymore, and hence
on boards needing the ExtINT delivery workaround failed to boot.
Make make_8259A_irq() a real function again, thus allowing the flow
handler to be changed there.
Also eliminate the generally superfluous and (at least theoretically)
dangerous hard coded setting of the flow handler for IRQ0: Earlier
code should have set this already based on information coming from
ACPI/MPS, and non-standard systems may e.g. have this IRQ level
triggered.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Tested-by: Markus Schuster <ml@markus.schuster.name>
xen-unstable changeset: 22222:aed9fd361340
xen-unstable date: Sat Oct 02 15:03:15 2010 +0100
Changed vt-d feature boot messages from "supported" to "enabled" since
they reflect what is currently enabled in this Xen boot - not what is
supported by VT-d hardware.
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
xen-unstable changeset: 22221:3518149c4d5d
xen-unstable date: Sat Oct 02 15:00:05 2010 +0100
While not as relevant after c/s 21894, is still seems safer to check
the CPUID level here, just like Linux does. The is particularly
relevant for the 4.0 tree (which doesn't have said c/s), but also
possibly for nested environments where writing MSR_IA32_MISC_ENABLE
may not actually take effect (Xen itself ignores such writes).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22213:eb247ea9db8c
xen-unstable date: Fri Sep 24 15:53:31 2010 +0100
It is better to return an unlabeled SID in the case where dsec is NULL
instead of bailing out with an error.
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Keir Fraser <Keir.Fraser@eu.citrix.com>
xen-unstable changeset: 22207:20f139010445
xen-unstable date: Wed Sep 22 18:26:01 2010 +0100
Mfns for PV domains were not properly checked, potentially
allowing a buggy or malicious PV guest to crash Xen. Also,
use get_page/put_page to claim a reference to the pages
so they can't disappear out from under tmem's feet.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
xen-unstable changeset: 22194:e8e3aeed3eba
xen-unstable date: Wed Sep 22 08:54:08 2010 +0100
It does not work reliably for a couple of reasons:
(1) page_lock() fails if a page is !PGT_validated, and a page can
remain in that state for unbounded time.
(2) in the kernel-side race that motivated this patch, pgd_pin() can
lose to vmalloc_sync_all() -- pgd_pin() can try to chaneg a pmd page's
type to l2_pagetable while
vmalloc_sync_all()->set_pmd()->do_mmu_update() has it temporarily
pinned as writable. This is hard to fix on the Xen side.
Hence I give up on this approach, revert the patch, and settle for
kernel-side patching only.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 22193:35a1a14c408e
xen-unstable date: Wed Sep 22 08:49:09 2010 +0100
This can really happen -- all our PV Linux kernels have a race
between vmalloc_sync_all() and pgdir pinning/unpinning. The former is
protected by pgd_lock while the latter by mm->page_table_lock. Hence
they can happen concurrently, and vmalloc_sync_all() can attempt to
set_pmd() on a page directory which is in the process of being
pinned. This can confuse the hypervisor which may see a type change,
and hence fail do_mmu_update(). Until this patch. :-)
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 22186:7167d6dd5c7c
xen-unstable date: Mon Sep 20 20:11:43 2010 +0100
While removing the casts on the last arguments to __trace_var() I
noticed the bogus addition of 1 here.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22185:9cebb977e9d8
xen-unstable date: Mon Sep 20 18:53:18 2010 +0100
This is possible now that its last parameter's type is 'const void *'.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22184:62a44418d8a0
xen-unstable date: Mon Sep 20 18:52:48 2010 +0100
The credit scheduler ties to keep work balanced, even on a mostly idle
system. Unfortunately, if you have one VM burning cpu and another VM
idle, the effect is that the busy VM will flip back and forth between
sockets.
This patch addresses this, by only migrating to a different socket if
the number of idle processors is twice that of the socket the vcpu is
currently on.
This will only affect mostly-idle systems; as the system becomes more
busy, other load-balancing code will come into effect.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 22180:0bc640853cfd
xen-unstable date: Mon Sep 20 18:49:15 2010 +0100
Several seconds of backward time drift per minute can be seen on a
RHEL6 HVM guest by switching the clocksource to 'acpi_pm' and then
running gettimeofday() in a loop. This is due to the accumulation
of small inaccuracies that are caused by shifting out the lower 32
bits when pmt_update_time() computes 'tmr_val'.
The patch makes sure that the lower 32 bits of the computed value
are not lost. They are saved in a new field 'not_accounted' in the
PMTState structure and are accounted the next time pmt_update_time()
is called.
From: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 22174:632c02167f97
xen-unstable date: Fri Sep 17 16:59:21 2010 +0100
This cuts the size of the domain structure by around 30kB! It is now a
little over a page in size.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 22162:cf70ef051a82
xen-unstable date: Wed Sep 15 15:45:42 2010 +0100
There is an errata in some of Intel processors.
AAJ72. EOI Transaction May Not be Sent if Software Enters Core C6
During an Interrupt Service Routine
If core C6 is entered after the start of an interrupt service routine
but before a write to the APIC EOI register, the core may not send an
EOI transaction (if needed) and further interrupts from the same
priority level or lower may be blocked.
This patch fix this issue, by checking if ISR is pending before enter
deep Cx state. If so, it would use power->safe_state instead of deep
Cx state to prevent the above issue happen.
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 22160:1087f9a03ab6
xen-unstable date: Wed Sep 15 09:00:35 2010 +0100
Else we can fail on either ASSERTion in that function.
From: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 22159:62edd2611cbb
xen-unstable date: Wed Sep 15 08:18:53 2010 +0100
Somewhere between 3.2 and 3.3 this got dropped (as I noticed on a
[rarely used] box that didn't crash on me since then).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22158:869a0fdf8686
xen-unstable date: Wed Sep 15 07:48:27 2010 +0100
Missing from commit 'libxl: Backported stuff from unstable'
Without this change, xs_daemon_open/xs_daemon_close will leak
file descriptors.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Lowest Priority can't use with invalid cpu_mask, and the default value
of CPU_MASK_ALL may cover CPU which wasn't online.
From: "Yang, Sheng" <sheng.yang@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 22148:a254d1236c1a
xen-unstable date: Mon Sep 13 17:37:25 2010 +0100
After a great deal of discussion and review with linux
kernel developers, it appears there are "next-generation"
filesystems (such as btrfs, xfs, Lustre) that will not
be able to use tmem due to an ABI limitation... a field
that represents a unique file identifier is 64-bits in
the tmem ABI and may need to be as large as 192-bits.
So to support these guest filesystems, the tmem ABI must be
revised, from "v0" to "v1".
I *think* it is still the case that tmem is experimental
and is not used anywhere yet in production.
The tmem ABI is designed to support multiple revisions,
so the Xen tmem implementation could be updated to
handle both v0 and v1. However this is a bit
messy and would require data structures for both v0
and v1 to appear in public Xen header files.
I am inclined to update the Xen tmem implementation
to only support v1 and gracefully fail v0. This would
result in only a performance loss (as if tmem were
disabled) for newly launched tmem-v0-enabled guests,
but live-migration between old tmem-v0 Xen and new
tmem-v1 Xen machines would fail, and saved tmem-v0
guests will not be able to be restored on a tmem-v1
Xen machine. I would plan to update both pre-4.0.2
and unstable (future 4.1) to only support v1.
I believe these restrictions are reasonable at this
point in the tmem lifecycle, though they may not
be reasonable in the near future; should the tmem
ABI need to be revised from v1 to v2, I understand
backwards compatibility will be required.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
xen-unstable changeset: 22137:fd2e5008c2e0
xen-unstable date: Mon Sep 13 17:11:04 2010 +0100
After a great deal of discussion and review with linux
kernel developers, it appears there are "next-generation"
filesystems (such as btrfs, xfs, Lustre) that will not
be able to use tmem due to an ABI limitation... a field
that represents a unique file identifier is 64-bits in
the tmem ABI and may need to be as large as 192-bits.
So to support these guest filesystems, the tmem ABI must be
revised, from "v0" to "v1".
I *think* it is still the case that tmem is experimental
and is not used anywhere yet in production.
The tmem ABI is designed to support multiple revisions,
so the Xen tmem implementation could be updated to
handle both v0 and v1. However this is a bit
messy and would require data structures for both v0
and v1 to appear in public Xen header files.
I am inclined to update the Xen tmem implementation
to only support v1 and gracefully fail v0. This would
result in only a performance loss (as if tmem were
disabled) for newly launched tmem-v0-enabled guests,
but live-migration between old tmem-v0 Xen and new
tmem-v1 Xen machines would fail, and saved tmem-v0
guests will not be able to be restored on a tmem-v1
Xen machine. I would plan to update both pre-4.0.2
and unstable (future 4.1) to only support v1.
I believe these restrictions are reasonable at this
point in the tmem lifecycle, though they may not
be reasonable in the near future; should the tmem
ABI need to be revised from v1 to v2, I understand
backwards compatibility will be required.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
xen-unstable changeset: 22136:b7f0ea22880d
xen-unstable date: Mon Sep 13 17:10:14 2010 +0100
The attached patch first tries the MTF flag for HVM guest
single step, reverting to manually setting the TF flag if MTF fails.
Tested on 4.0.1. Compile tested on unstable.
Signed-off-by: mukesh.rathor@oracle.com
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 22115:cd87550cea5e
xen-unstable date: Tue Sep 07 19:17:16 2010 +0100
contiguous ranges of page_info structs. This allows page-pointer
arithmetic in places like our buddy allocator.
This restriction was already implicitly guaranteed, but it is good to
make it explicit in the pdx-related initialisation.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 972d90ff3134
xen-unstable date: Wed Sep 01 10:17:49 2010 +0100
There's a subtle race in ept_get_entry, such that if tries to read an
entry that ept_set_entry is modifying, it gets neither the old entry
nor the new entry, but empty. In the case of multi-cpu
populate-on-demand guests, this manifests as a guest crash when one
vcpu tries to read a page which another page is trying to populate,
and ept_get_entry returns p2m_mmio_dm.
This bug can also be fixed by making both ept_set_entry and
ept_next_level access-once (i.e., ept_next_level reads full ept_entry
and then works with local value; ept_set_entry construct the entry
locally and then sets it in one write). But there doesn't seem to be
any major performance implications of just making ept_get_entry use
locks; so the simpler, the better.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen-unstable changeset: 22071:c5aed2e049bc
xen-unstable date: Mon Aug 30 08:39:52 2010 +0100
The "mask" covered all online cpus in the "domain". It should be used
as destination later, instead of using "domain" directly.
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
xen-unstable: changeset: 3eb5127e4636
xen-unstable: date: Thu Aug 26 11:16:14 2010 +0100
Without this change, p2m.c fails to compile if P2M_AUDIT is enabled.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
xen-unstable changeset: a67b98978f5b
xen-unstable date: Tue Aug 24 16:15:56 2010 +0100
Keir Fraser
Keir Fraser