xen/include/public/foreign.
Unfortunately diff's -x and -X options do not support excluding paths just
individual files so we have to list unqualified filenames. This is ok for now
since there are no filename clashes.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
Some operating systems access the local APIC TPR very frequently, and
we handle that using software-based local APIC virtualization in Xen
today. Such virtualization incurs a number of VM exits from the
memory-access instructions against the APIC page in the guest.
The attached patch enables the TPR shadow feature that provides APIC
TPR virtualization in hardware. Our tests indicate it can
significantly boost the performance of such guests including 32-bit
Windows XP/2003.
Moreover, with the patch, local APIC accesses other than TPR in guests
are intercepted directly as APIC_ACCESS VM exits rather than
PAGE_FAULT VM exits; this can lower the emulation cost of such
accesses.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
This is only enabled for the linux-2.6-xen tree and is intended to
ensure that the separate Linux tree stays up to date once we
switch away from the sparse tree.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
mcs->call (struct multicall_entry) always needs to be translated into
mcs->compat_call (struct compat_multicall_entry) when a multicall is
preempted in compat mode. Previously this translation only occured for
those hypercalls which explicitly called hypercall_xlat_continuation()
which doesn't cover all hypercalls which could potentially be
preempted.
Change hypercall_xlat_continuation() to only translate only the
hypercall arguments themselves and not the multicall_entry
layout. Translate the layout for all hypercalls in in
compat_multicall() instead.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
This patch adds lazy copying using the new unmap_and_replace grant
table operation.
We keep a list of pending entries sorted by arrival order. We'll
process this list every time net_tx_action is invoked. We ensure
that net_tx_action is invoked within one second of the arrival of
the first packet in the list.
When we process the list any entry that has been around for more
than half a second is copied. This allows up to free the grant
table entry and return it to domU.
If the new grant table operation is not available (e.g., old HV
or architectures that don't support it yet) we simply copy each
packet as we receive them using skb_linearize. We also disable
SG/TSO if this is the case.
By default the new code is disabled. In order to enable it,
the module needs to be loaded with the argument copy_skb=1.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
This patch adds basic tracking of outstanding DMA requests on
grant table entries marked as PageForeign.
When a PageForeign struct page is about to be mapped for DMA,
we set its map count to 1 (or zero in actual value). This is
then checked for when we need to free a grant table entry early
to ensure that we don't free an entry that's currently used for
DMA.
So any entry that has been marked for DMA will not be freed early.
If the unmapping API had a struct page (which exists for the sg
case) then we could do this properly.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The operation unmap_and_replace is an extension of unmap_grant_ref.
A new argument in the form of a virtual address (for PV) is given.
Instead of modifying the PTE for the mapped grant table entry to
null, we change it to the PTE for the new address. In turn we
point the new address to null.
As it stands grant table entries once mapped cannot be
remapped by the guest OS (it can however perform a new
mapping on the same entry but that is within our control).
Therefore it's safe to manipulate the mapped PTE entry to
redirect it to a normal page where we've copied the contents.
It's intended to be used as follows:
1) map_grant_ref to v1
2) ...
3) alloc page at v2
4) copy the page at v1 to v2
5) unmap_and_replace v1 with v2
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Added compat integration (PAE-on-64).
Signed-off-by: Keir Fraser <keir@xensource.com>
Do not destroy domains on shutdown timeout: the administrator needs to
be able to decide what to do if a domain does not shut down.
Signed-off-by: John Levon <john.levon@sun.com>
xenstored is incorrectly accounting domain nodes when transactions
fail. Store pending count changes in the transaction structure, and
apply at transaction completion, instead of directly applying the
changes.
Signed-off-by: Max Zhen <max.zhen@sun.com>
were copying too many bytes from the guest so the test for
area.addr.h.c != area.addr.p was failing.
Added a WARN_ON to the kernel to catch this case. It would be a BUG_ON
but this would break the new kernel on older hypervisors and the only
real problem is that stolen time is not updated, which we can live
with.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
abusing mk_kernel_pgd.
Also set the user bit on the vsyscall entry in the user pgd.
Both changes suggested by Jan Beulich.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
tarball methods in preparation for migrating away from the sparse tree
layout.
This re-introduces 14883:6568c1882af5 and 14862:98efd2e410ae plus
further fixes.
Also add makefile fragments to support building the paravirt ops tree
(make linux-2.6-paravirt-build).
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
30 seconds is not a very long time for a busy domain to cleanly
shutdown all its services, which may be arbitrary in
complexity. Increase the timeout to 5 minutes.
Signed-off-by: John Levon <john.levon@sun.com>
Instead of violently destroying a domain that is not responding to a
shutdown request, rename the domain to indicate the problem and leave
it alone; this allows the admin to make corrective actions (which may
or may not include destroying the domain).
Signed-off-by: John Levon <john.levon@sun.com>
The Domain ID is currently expected to fit in 3 digits.
When doing extensive testing on SAVE/RESTORE I can easily get ID's
into the 4-digit range, which makes some of the formatting to get out
of sync. Extend the width to 5 digits (and change some %-ns to %ns, as
the ID for example is right justified, %-ns is left-justified, which
didn't look too good).
Signed-off-by: Mats Petersson <mats.petersson@amd.com>
1) Sets a minimum of 128MB RAM for an ia64 domU; this limit was set
after experimentation, which seems to indicate it's a reasonable lower
limit (the 32MB limit previously in place did not allow an ia64 domU
to start). If there's any problem with this, I don't mind splitting
the patch and sending it to the ia64 list, but it was small, so I hope
it's okay to include it.
2) xm-test uses ramdisks built with uClibc, which doesn't compile on
ia64. I was able to create a ramdisk by hand, but as it was too
large, the resultant domU crashed after boot. This patch enables the
use of an arbitrarily large ramdisk, so long as it's uncompressed. As
xm-test builds only uncompressed ramdisks, I figured this was
reasonable for that specific application. Suggestions on how to
detect and handle a compressed ramdisk would be welcome.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
As there is a (small) chance that vl.c:tap_open() fails (due to some
sort of race-condition in the Linux kernel, which is noted as a bug in
the source .../net/core/dev.c), we should attempt it again a couple of
times if it doesn't succeed on the first attempt. I think three times
in total is sufficient to avoid the problem.
If tap_open() fails, qemu-dm will exit, which means that the domain
dies - which is not such a good thing when attempting to restore a saved
domain [of course, it would be even worse if it started, but didn't
have networking - because there may not be a way to shut it down
cleanly without network].
Signed-off-by: Mats Petersson <mats.petersson@amd.com>
The function XendDomainInfo:_releaseDevices() is called during the
save/destroy phase of a domain. It made some attempt to clean up the
devices, but wasn't complete, leaving dangling devices in the
xenstore. Not a big problem with normal use of Xen, but a buildup over
a large number of save/destroy instances, it would make the xenstore
database grow quite large, which in turn meant swap-thrashing in Dom0.
This patch makes use of the destroyDevices() function in
XendDomainInfo. This function needed some re-writing to make it work
correctly - I think it had some old code (not sure how old, as xm
annotate says that it's changeset 12071, but that, I think, is when it
was split out from XendDomain.py, rather than when it was created).
I have tested this over a few hundred save/restore cycles [two domains
constantly saved/restored with a short sleep to let them process some
work] combined with a loop of "xenstore-ls|wc". The output of the
latter is pretty much constant (it obviously varies a bit depending on
when in the save/restore cycle it hits). Previously, it would increase
by some 10 lines or so per save/restore cycle.
Signed-off-by: Mats Petersson <mats.petersson@amd.com>
- replace incomplete pXX_val_ma() set with complete __pXX_val() set
- use __pXX_val() instead of pXX_val() when only flags are accessed or
the frame number is only compared against zero
Signed-off-by: Jan Beulich <jbeulich@novell.com>
When compiling the various blktap drivers with warnings cranked up, I
get errors that return values are not checked.
Signed-off-by: Charles Coffing <ccoffing@novell.com>
If creating an unmanaged guest (eg xm create), if device hotplug fails
during the startup of the guest, then the guest will be torn down
again. If creating and starting a managed guest (eg xm new && xm
start), then if device hotplug fails, the still born guest gets left
in 'paused' state. This confuses users no end, who go an unpause and
then get all upset when it shortly crashes (due to lack of disk or
network devices).
The attached patch fixes XenDomain.py's domain_start() method so that
if waitForDevices() fails, then the entire domain is torn down. This
is the same approach used in xm create.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Remove the call to svm_load_cr2 (which doesn't do anything useful).
The old svm_load_cr2 is now replaced with a svm_trace_vmentry. A call
to this function is done if "tb_init_done" is non-zero, so we don't call
this unless it's actually being used.
Signed-off-by: Mats Petersson <mats.petersson@amd.com>
When I changed the scheduler parameters of a domain with
xm sched-credit, the information of xm sched-credit was changed.
But as for the information of xm list, the values of the domain
configuration definition were kept.
And, then I rebooted the domain. The information of xm list was
not changed. But as for the information of xm sched-credit, the
values of the domain configuration definition were returned.
# xm create /xen/PVdomain.1 cpu_cap=150 cpu_weight=512
Using config file "/xen/PVdomain.1".
Started domain PVdomain.1
# xm sched-credit -d PVdomain.1
Name ID Weight Cap
PVdomain.1 1 512 150
# xm sched-credit -d PVdomain.1 -c 75 -w 384
# xm sched-credit -d PVdomain.1
Name ID Weight Cap
PVdomain.1 1 384 75
# xm list --long PVdomain.1 | grep cpu_
(cpu_weight 512)
(cpu_cap 150)
(cpu_time 29.353831745)
# xm reboot PVdomain.1
# xm sched-credit -d PVdomain.1
Name ID Weight Cap
PVdomain.1 2 512 150
# xm list --long PVdomain.1 | grep cpu_
(cpu_weight 512)
(cpu_cap 150)
(cpu_time 5.950247186)
If the scheduler parameters of the domain were changed with
xm sched-credit, I think that xm list should show the current
values about the scheduler parameters.
And, then if the domain is rebooted, I think that the rebooted
domain should keep the preceding values about the scheduler
parameters.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
The threshold register has been introduced in AMD RevF CPUs along with
SVM (Actually this MCA/MCE msr register existed before, but had no
meaning). Therefore no need for additional cpuid checks.
On read access it reports the HVM guest the register has been locked
by the BIOS. This means, it is not available for OS use. Thus, write
accesses are simply ignored. This behaviour actually matches real HW,
so guests can deal with this.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
We don't need to touch it in arch_vcpu_reset() because that's only used
to recover from a failed suspend, and the correct behaviour there is to
leave the mapping as-is.
blktapctrl already prints out exits reasons for all goto's to
open_failed except of not finding a device number for blktap0
This patch adds just that message so the user will get more info than
just "Unable to start blktapctrl"
Common source of this issue is that blktap is missing/failed to
load/...
Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
This change implements the VCPUOP_register_vcpu_info vcpu_op. This
allows a guest to choose where each VCPU's vcpu_info structure is
placed within its address space, allowing it to put it somewhere which
is easily accessible via some per-cpu data access mechanism.
When changing the mapping of the vcpu info, there's no obvious way to
prevent the other vcpus from getting a stale pointer of the vcpu_info,
which could result in them accessing bad memory (stale pointers to the
shared_info page are not a problem, because its always valid). To
avoid this, we prevent guests from changing the vcpu_info location
more than once, since there's no obvious need to allow them to do this
at this point.
(If we really want to allow guests to update the vcpu_info location
more than once, then some sort of RCU wait between updating the
pointer and performing the unmap may be the way to do it.)
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
