Merge the check for EPT/VT-D pagetable compatibility into the other
VT-D boot-time checks. Previously it was checking and printing many
times on each VM boot.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23247:80401982465d
xen-unstable date: Mon Apr 25 13:17:05 2011 +0100
This means suppressing the uses in time_calibration_tsc_rendezvous(),
cstate_restore_tsc(), and synchronize_tsc_slave(), and fixes a boot
hang of Linux Dom0 when loading processor.ko on such systems that
have support for C states above C1.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23228:1329d99b4f16
xen-unstable date: Fri Apr 15 08:52:08 2011 +0100
c/s 22275: "tools: cleanup domain save switch_qemu_logdirty callback"
introduced a whole bunch of error code fixups. In the process, it also
ended up treating the success return code (0) from
switch_qemu_logdirty as an error and vice versa.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
xen-unstable changeset: 23202:67911039ac94
xen-unstable date: Tue Apr 12 13:28:51 2011 +0100
Some device could generate bogus interrupts if an IO-APIC RTE and an
iommu interrupt remapping entry are not consistent during 2 adjacent
64bits IO-APIC RTE updates. For example, if the 2nd operation updates
destination bits in RTE for SATA device and unmask it, in some case,
SATA device will assert ioapic pin to generate interrupt immediately
using new destination but iommu could still translate it into the old
destination, then dom0 would be confused. To fix that, we sync up
interrupt remapping entry with IO-APIC IRE on every 32 bits operation
and forward IOAPIC RTE updates after interrupt.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
Acked-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23200:995a0c01a076
xen-unstable date: Tue Apr 12 13:26:19 2011 +0100
While running remus, when an error occurs during checkpointing
(e.g., timeouts on primary, failing to checkpoint network buffer
or disk or even communication failure) the domU is sometimes
left in suspended state on primary. Instead of blindly closing
the checkpoint file handle, attempt to resume the domain before
the close.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23195:13ec53a59a42
xen-unstable date: Fri Apr 08 16:49:04 2011 +0100
This sets a saner default for the cpu-online-map by setting all bits
to 1. The default assumption ought to be that nr-vcpus ==
nr-vcpus-at-start. If that is not true, then the toolstack must modify
the bitmap, but if it is true, the toolstack oughtn't need to do
anything further.
Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
xen-unstable changeset: 23179:2b66b83b19b6
xen-unstable date: Thu Apr 07 12:13:58 2011 +0100
When offline a page, or, when a broken page occur, the page maybe
populated, or, may at pod cache. This patch is to handle the
offline/broken page at pod cache. It scan pod cache, if hit, remove
and replace it, and then put the offline/broken page to
page_offlined_list/page_broken_list
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
xen-unstable changeset: 23178:fd8b81db422d
xen-unstable date: Thu Apr 07 12:12:38 2011 +0100
c/s 19913 break mce offline page logic:
For page_state_is(pg, free), it's impossible to trigger the case;
For page_state_is(pg, offlined), it in fact didn't offline related
page;
This patch fix the bug, and remove an ambiguous comment.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
xen-unstable changeset: 23177:d8bb2de119de
xen-unstable date: Thu Apr 07 12:12:01 2011 +0100
Xen 4.0 added "msr_tsc_aux" in the middle of the hvm_hw_cpu structure,
making it incompatible with pre-3.4 savefiles. This patch uses the
recently introduced backwards-compatibility infrastructure to convert
the old to the new.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
Committed-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23172:dc8b05d22a59
xen-unstable date: Wed Apr 06 11:40:54 2011 +0100
The hvm_save code is used to save and restore hypervisor-related hvm
state, either for classic save/restore, or for migration (including
remus). This is meant to be backwards-compatible across some
hypervisor versions; but if it does change, there is no way to handle
the old format as well as the new.
This patch introduces the infrastructure to allow a single older
version ("compat") of any given "save type" to be defined, along with
a function to turn the "old" version into the "new" version. If the
size check fails for the "normal" version, it will check the "compat"
version, and if it matches, will read the old entry and call the
conversion function.
This patch involves some preprocessor hackery, but I'm only extending
the hackery that's already there.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
Committed-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23171:6a5830de7b54
xen-unstable date: Wed Apr 06 11:40:51 2011 +0100
AMD64 defines two special bits (bit 3 and 4) RdMem and WrMem in fixed
MTRR type. Their values are supposed to be 0 after BIOS hands the
control to OS according to AMD BKDG. Unless OS specificially turn them
on, they are kept 0 all the time. As a result, k8_enable_fixed_iorrs()
is unnecessary and removed from upstream kernel (see
https://patchwork.kernel.org/patch/11425/). This patch does the same
thing.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
xen-unstable changeset: 23154:42fa70e0761b
xen-unstable date: Wed Apr 06 09:02:13 2011 +0100
Some buggy BIOS might set SYS_CFG DramModEn bit to 1, which can cause
unexpected behavior on AMD platforms. This patch clears DramModEn bit
if it is 1.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
xen-unstable changeset: 23153:8fb61c9ebe49
xen-unstable date: Wed Apr 06 09:01:31 2011 +0100
The PSE handling doesn't check bits 1...8 (or 1...9 for non-PAE
guests) being zero, thus allowing bad (not 2Mb/4Mb aligned) large
pages to be handled.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23138:777aaa2172c8
xen-unstable date: Mon Apr 04 10:38:27 2011 +0100
The output of AT&T UNIX and GNU od(1) are different.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
xen-unstable changeset: 23130:0e88c781a8a8
xen-unstable date: Sat Apr 02 15:53:35 2011 +0100
This function is being called on the resume path.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23061:12f7c7ac7f19
xen-unstable date: Fri Mar 18 17:15:52 2011 +0000
While c/s 22964:f71212f712fd and 23051:93c864c16ab1 fixed issues with
CPU onlining, they introduced a problem with resume: mcheck_init() is
also being called on that path, and hence checking whether it's
running on CPU 0, which is generally not a really good thing, is
particularly inappropriate here.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23060:b59e98bc6ff1
xen-unstable date: Fri Mar 18 17:15:19 2011 +0000
c/s 22964 fixed a mce memory leaks bug which may trigger xen crash
when cpu online. However, there are 2 mce memory leaks: 1 at mce
level (arch independent), 1 at mce_intel level (arch dependent). At
c/s 22964, it free both leaks at mce_intel level, which would has
problem under AMD arch.
This patch fix this issue.
It alloc/free poll_bankmask (arch independent) at mce level,=20 and
add a notifier block at mce level to avoid xmalloc risk when irq
disable.
With this patch, both Intel and AMD mce works OK in a clean way.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
xen-unstable changeset: 23051:93c864c16ab1
xen-unstable date: Thu Mar 17 13:31:43 2011 +0000
Only call SCHED_OP(pick_cpu) if a previously picked cpu is not
suitable on the current iteration of the retry loop.
Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23043:3caed2112c65
xen-unstable date: Tue Mar 15 10:14:27 2011 +0000
This patch makes sure the passthrough device belongs to pciback before
allow them passthrough to the guest. There are still many other
checks missing.
xm terminates the guest startup process when this type of condition is
found. This patch just allows the guest to continue to boot but with
no device passthrough.
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Acked-by: Gianni Tedesco <gianni.tedesco@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Again, (out-of-memory) errors must not cause hypervisor crashes, and
hence ought to be propagated.
This also adjusts the cache attribute changing loop in
get_page_from_l1e() to not go through an unnecessary iteration. While
this could be considered mere cleanup, it is actually a requirement
for the subsequent now necessary error recovery path.
Also make a few functions static, easing the check for potential
callers needing adjustment.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22997:5f28dcea1355
xen-unstable date: Wed Mar 09 16:15:36 2011 +0000
x86: don't BUG() post-boot in alloc_xen_pagetable()
Instead, propagate the condition to the caller, all of which also get
adjusted to check for that situation.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 22996:1eeccafe9042
xen-unstable date: Wed Mar 09 16:14:59 2011 +0000
This fixes a fairly blatant bug I introduced in c/s 20377:cff23354d026
- I wonder how this went unnoticed for so long.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23039:c40da47621d8
xen-unstable date: Mon Mar 14 17:19:22 2011 +0000
This permits suspend/resume to work with 32bit dom0/tools when system
memory extends beyond 160GB (and up to 1TB).
AFAICT the limit to MACH2PHYS_COMPAT_NR_ENTRIES is redundant since
that refers to a limit in 32bit guest compat mappings under 64bit
hypervisors, not userspace where there may be gigabytes of useful
virtual space available for this.
Suggested-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
xen-unstable changeset: 23038:39f5947b1576
xen-unstable date: Mon Mar 14 17:13:15 2011 +0000
c/s 21811:12f0618400de broke this by not properly initializing struct
cpuinfo_x86's x86_num_siblings member (other than Linux, where this is
a global variable, it is being maintained per CPU by Xen).
Hyper-threaded CPUs with CPUID leaf 0xb present had therefore all
cpu_sibling_map-s with just a single bit set, thus improperly feeding
the scheduler.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset: 23037:a29b35408950
xen-unstable date: Mon Mar 14 17:05:21 2011 +0000
cpuid results are possible to be changed now. For example, changing
CR4.OSXSAVE bit or setting MSR XCR_XFEATURE_ENABLED_MASK may change
XSAVE related cpuid leave return values.
The volatile prefix is required to avoid the second cpuid calls
following some possible changing operations being optimized in
incorrect way by compiler.
The sample bug is in xsave_init while debug=3Dn. The second call to
cpuid_count() may be optimized and lead to a BUG_ON case while compare
xsave_cntxt_size with ebx.
Signed-off-by: Wei Gang <gang.wei@intel.com>
xen-unstable changeset: 23036:9a15ff175e00
xen-unstable date: Mon Mar 14 17:04:42 2011 +0000
At least the legacy path can enter its interrupt handler callout while
initialization is still in progress - that handler checks whether
->event_handler is non-NULL, and hence all other initialization must
happen before setting this field.
Do the same to the MSI initialization just in case (and to keep the
code in sync).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Wei Gang <gang.wei@intel.com>
xen-unstable changeset: 23030:87aa1277eae0
xen-unstable date: Sat Mar 12 13:19:02 2011 +0000
libxl_device_disk_add tries to use blktap when available even for qdisk
devices, this patch fixes it.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry-picked from xen-unstable
changeset a8fee4ad3ad0650e7a5cc0fb253c6a0ada1ac583)
At some platform (like Xen 7400), when hyperthreading, an offlined
thread may waked spuriously up by its brother, and returning around
the loop. This patch explicitly clflush the cache line in a light
weight way to workaround potential issue. Unlike wbinvd, clflush is
not serializing instruction, hence memory fence is necessary to make
sure all load/store operation visible before flush cache line.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
xen-unstable changeset: 23024:fb3950888154
xen-unstable date: Fri Mar 11 17:18:53 2011 +0000
x86: Fix cache flush bug of cpu offline
Current xen cpu offline logic flush cache too early, which potentially
break cache coherency. wbinvd should be the last ops before cpu going
into dead, otherwise cache may be dirty, i.e, something like setting
an A bit on page tables. Pointed out by Arjan van de Ven.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
xen-unstable changeset: 23023:552c3059264e
xen-unstable date: Fri Mar 11 17:18:01 2011 +0000
x86: Fix cpu offline bug: cancel SYSIO method when play dead
Play dead is a fragile and tricky point of cpu offline logic. For how
to play cpu dead, linux kernel changed several times: Very old kernel
support 3 ways to play cpu dead: mwait, SYSIO, and halt, just like
what cpuidle did when enter C3; Later, it cancel mwait and SYSIO
support, only use halt to play dead; Latest linux 2.6.38 add mwait
support when cpu dead.
This patch cancel SYSIO method when cpu dead, keep same with latest
kernel.
SYSIO is an obsoleted method to enter deep C, with some tricky
hardware behavior, and seldom supported in new platform. Xen
experiment indicate that when cpu dead, SYSIO method would trigger
unknown issue which would bring strange error. We now cancel SYSIO
method when cpu dead, after all, correctness is more important than
power save, and btw new platform use mwait.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
xen-unstable changeset: 23022:6c5e68521f1d
xen-unstable date: Fri Mar 11 16:27:33 2011 +0000
Before invoking C3, bus master disable / flush cache should be the
last step; After resume from C3, bus master enable should be the first
step;
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Acked-by: Wei Gang <gang.wei@intel.com>
xen-unstable changeset: 23020:22cc047eb146
xen-unstable date: Thu Mar 10 18:35:32 2011 +0000
While doing development on libvirt libxenlight driver I noticed
that terminating a libxenlight client causes any qemu-dm
processes that were indirectly created by the client to also
terminate. Calling setsid(2) before exec'ing qemu-dm resolves
the issue.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
# User Stefano Stabellini <stefano.stabellini@eu.citrix.com>
# Date 1299690214 0
# Node ID 0fa941c0ec45b3490d8ffa74ae0a271dfc14445e
# Parent 65d26504e843420a1f3db6052464c052f83160e3
libxl: introduce flexarray_append_pair
Introduce flexarray_append_pair: a simple syntactic sugar to add a pair
of pointers to a flexarray, very useful when adding pairs of strings to
xenstore.
Replace flexarray_vappend calls (and one pair of flexarray_append)
with flexarray_append_pair calls when dealing with flexarrays that are
going to be used with libxl__xs_kvs_of_flexarray:
NULL is a valid pointer value in these cases while flexarray_vappend
uses NULL as vargs terminator, so the old code is buggy.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Keir Fraser
Tim Deegan
Shriram Rajagopalan
Wei Wang
Gianni Tedesco
Liu, Jinsong
George Dunlap
Wei Huang
Machon Gregory
Christoph Egger
Jan Beulich
Juergen Gross
Allen M Kay
Wei Gang
Ian Jackson
Jim Fehlig
Stefano Stabellini
Ian Campbell