Use vdevfn in xm_pci_attach() for non-zero functions,
the vslot element of dev dictionaries no longer exists.
Signed-off-by: Simon Horman <horms@verge.net.au>
With all of Xen's symbols sitting within a 2Gb range on x86-64, they
can be referred to by the kallsyms-like offset table using 4- instead
of 8-byte slots.
The marker table can use 4-byte slots in all cases, just like the
table entry counts can (though that's only a minor improvement).
If ia64's PERCPU_ADDR got moved down to (KERNEL_START + 2Gb -
PERCPU_PAGE_SIZE), it could also utilize the more compact form.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
After some discussion, here's a second version of the patch I posted a
couple of weeks back to map grant references into HVM guests. As
before, this is done by modifying the P2M map, but this time there's
no new hypercall to do it. Instead, the existing GNTTABOP_map is
overloaded to perform a P2M mapping if called from a shadow mode
translate guest. This matches the IA64 API.
Signed-off-by: Steven Smith <steven.smith@citrix.com>
Acked-by: Tim Deegan <tim.deegan@citrix.com>
CC: Bhaskar Jayaraman <Bhaskar.Jayaraman@lsi.com>
Eliminate the hard-coded, arbitrarily chosen limit of 512 grant table
ops a domain may submit at a time, and instead check for necessary
preemption after each individual element got processed, invoking the
hypercall continuation logic when necessary.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Remove ASSERT(spin_is_locked(&pcidevs_lock)) in
pci_get_pdev_by_domain() to allow caller the flexibility to not hold
the lock if it does not care if the device is hot removed between the
time it got the pdev and the time it is used to get the corresponding
vt-d engine. In the new RHSA use case, we just wanted to get the vt-d
engine of any device passthrough in the domain. Also, rename RHSA
field "domain" to "proximity domain" to avoid overloading the term
"domain" in virtualization context.
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
While unrelated to the previous four patches, I realized that the two
scripts are nearly identical when coding those earlier patches, and
this patch depends on them in order to apply cleanly.
As an extra measure, it also adjusts the (unused) space freed at the
end of the per-CPU area to include all alignment space needed before
the first actual constituent of the .bss section (up to 7 pages on
x86-64).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
These cpu maps get read from all CPUs, so apart from addressing the
square(nr_cpus) growth of these objects, they also get moved into the
previously introduced read-mostly sub-section of the per-CPU section,
in order to not need to waste a full cacheline in order to align (and
properly pad) them, which would be undue overhead on systems with low
NR_CPUS.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Since mixing data that only gets setup once and then (perhaps
frequently) gets read by remote CPUs with data that the local CPU may
modify (again, perhaps frequently) still causes undesirable cache
protocol related bus traffic, separate the former class of objects
from the latter.
These objects converted here are just picked based on their write-once
(or write-very-rarely) properties; perhaps some more adjustments may
be desirable subsequently. The primary users of the new sub-section
will result from the next patch.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
This basically makes the final linking stage identical to x86's (with
the sole difference being that ia64 has the linker generate a map
file, while x86 doesn't), so would generally allow moving the final
linking rule into xen/Rules.mk.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Since the Xen heap pages (which are the only ones mapped at this
point) don't get passed to init_boot_pages(), it has no place to store
the bootmem regions without faulting. Hence, a mapped page must be
passed to that function as the very first thing.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
19818 added the following line to stubdom-dm:
. ./stubdompath.sh
and replaced many paths with variables. However the path to
stubdompath.sh is obviously wrong and stubdompath.sh is nowhere to be
found anyway. For the moment I am dropping . ./stubdompath.sh and
hardcoding the values of the variables.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Currently most of the error checking in fs-backend is done by the use
of asserts that would terminate the daemon in case of a single error
on a single request. This patch replaces the asserts with debugging
messages and terminates the connection on which the error occurred.
With this patch applied I was able to complete successfully over 1000
live migrations with stubdoms.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This patch fixes a race during live migration with stubdoms: right
after the stubdom dies the configuration file of the VM is removed by
stubdom-dm but, in case of a live migration, the configuration file
could be the one of the new VM in the process of being created.
Removing the config file before destroying the stubdom is enough to
solve the race.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
New NHM processors will support Pause-Loop Exiting by adding 2
VM-execution control fields:
PLE_Gap - upper bound on the amount of time between two successive
executions of PAUSE in a loop.
PLE_Window - upper bound on the amount of time a guest is allowed to
execute in a PAUSE loop
If the time, between this execution of PAUSE and previous one, exceeds
the PLE_Gap, processor consider this PAUSE belongs to a new loop.
Otherwise, processor determins the the total execution time of this
loop(since 1st PAUSE in this loop), and triggers a VM exit if total
time exceeds the PLE_Window.
* Refer SDM volume 3b section 21.6.13 & 22.1.3.
Pause-Loop Exiting can be used to detect Lock-Holder Preemption, where
one VP is sched-out after hold a spinlock, then other VPs for same
lock are sched-in to waste the CPU time.
Our tests indicate that most spinlocks are held for less than 2^12
cycles. Performance tests show that with 2X LP over-commitment we can
get +2% perf improvement for kernel build(Even more perf gain with
more LPs).
Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
There is a mistake to get the msix entry number. It should be
divide instead of modulus.
Signed-off-by: Yang Zhang <yang.zhang@intel.com>
Signed-off-by: Qing He <qing.he@intel.com>
The existing single page is not quite large enough to translate a
XENMEM_exchange hypercall with order=3D9. Since Linux uses
MAX_CONTIG_ORDER of 9 this seems like a reasonable upper bound to
support.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
pciback is used by VT-d to hide device for assigment. But in pv-ops
dom0, pciback is not supported yet. Fortunately, pci-stub module is
used to hide device in Linux for KVM VT-d device assignment and it's
included in pv-ops dom0. So can use pci-stub to hide devices for
assignment.
Device must be hidden before assignment. Control panel has checks if
devices can be assigned or not, and can list assignable devices via
reading devices owned by pciback. This patch changes the checks, and
also list assignable devices which are owned by pci-stub. Use pci-stub
to hide devices, and use this patch to pass checkes in control panel,
device assignemnt with VT-d works on Xen with pv-ops dom0.
Signed-off-by: Weidong Han <weidong.han@intel.com>
blktap2 devices use a regular 'phy' vbd blkback backend, causing
Blktap2Controller to trample the devices' parameters. This causes
problems with save/restore and managed domains, among other
things. This patch modifies Blktap2Controller to store both the vbd
and tap2 parameters in xenstore, and stops it from trampling the
device's config on device creation.
* store blktap2 parameters in xenstore
* restore blktap2 device config to original state once the underlying
* vbd
device is created (this fixes managed domains)
* use blktap2 parameters rather than vbd parameters when building
* blktap2
device configurations
* remove blktap2 specific code from XendConfig
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
* seperate blktap1/blktap2 disk types
* use blktap1 when driver is not in explicit list of blktap2 drivers,
* rather than current check against list of blktap1 only drivers
* remove 'tapdisk' disk type (it is not a tapdisk disk type) and fix
* tapdisk disk type check in XenConfig
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
softirqs. This fixes a bug where bailing into SCHEDULE_SOFTIRQ may not
actually return.
From: Ke Yu <ke.yu@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Keir Fraser