When converting a gfn to mfn, check if the page is paged-out.
If it is, request a page-in and return GNTST_eagain to the caller
to indicate a retry of the hypercall is required.
This fixes granttable errors when xenpaging is enabled in the guest.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
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>
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>
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>
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>
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>
These structures are used by Xen, and hence guests must not be able
to fiddle with them.
qemu-dm currently plays with the MSI-X table, requiring Dom0 to
still have write access. This is broken (explicitly allowing the guest
write access to the mask bit) and should be fixed in qemu-dm, at which
time Dom0 won't need any special casing anymore.
The changes are made under the assumption that p2m_mmio_direct will
only ever be used for order 0 pages.
An open question is whether dealing with pv guests (including the
IOMMU-less case) is necessary, as handling mappings a domain may
already have in place at the time the first interrupt gets set up
would require scanning all of the guest's L1 page table pages.
Currently a hole still remains allowing PV guests to map these ranges
before actually setting up any MSI-X vector for a device.
An alternative would be to determine and insert the address ranges
earlier into mmio_ro_ranges, but that would require a hook in the
PCI config space writes, which is particularly problematic in case
MMCONFIG accesses are being used.
A second alternative would be to require Dom0 to report all devices
(or at least all MSI-X capable ones) regardless of whether they would
be used by that domain, and do so after resources got determined/
assigned for them (i.e. a second notification later than the one
currently happening from the PCI bus scan would be needed).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Jiang, Yunhong <yunhong.jiang@intel.com>
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>
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>
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>
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>
Machine check MSRs are not special to long mode. Thus move them into
svm_msr_write_intercept(). Remove empty long mode msr function and
simplify the logic.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
When a memory owned by EPT guest is broken, we change the P2M type to
be broken memory type, so that later access from the guest to the
broken memory will be trapped as EPT violation.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
In some platform, whole system will crash if a broken memory is
accessed, no matter this access is from guest, or hypervisor. This may
cause issue if mallicious guest access this memory. To avoid this, we
need to guard the access from the guest. Morever, we need make sure
host will not access the memory for guest, like when do instruction
emulation.
This patch is to guard EPT guest's access. A new broken memory type is
added. Because the ept_p2m_type_to_flags() will mark default type as
r/w/x bit as zero, a broken memory type will have non-present EPT
entry, thus guest's access will cause EPT violation VM Exit.
In Xen hypervisor's vmexit ept violation handler, when it try to
translate the gpfn to mfn through p2m_guest query type, this patch
will cause domain to be crashed.
The changes to __gfn_to_mfn_type will return INVALID_MFN for broken
memory type, to avoid the crash caused by hypervisor access if caller
check the return value. It is complex to test this scenerior in EPT
situation, since mostly EPT violation will happen before hypervisor
will access the broken memory, but to be helpful for other memory
type.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
Some GNU systems (including Debian) do not use /usr/lib64. This change
makes it easier to have the Xen build system on amd64 put its 64-bit
libraries files in /usr/lib.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
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>
Cloning and building a kernel as part of the Xen distribution
implicitly advises that this kernel is the best kernel for all users
and many users appear to be under this impression, even though there
is no fundamental coupling between the Xen distribution and a
particular domain 0 kernel.
There are several choices available for domain 0 kernel, as well as
other user specific variations in requirements e.g. for kernel
configurations. It's not clear that whatever the xen build system
happens to produce (which is really tailored to the needs of the
automated build system) is best for anybody.
Coupling the kernel build with the Xen build has proved problematic
for stable Xen releases as it implicitly blesses the particular kernel
(at a particular point in time) as a constituent part of the Xen
release, while in reality the OS kernels are separate entities with
their own release cycles which may or may not coincide with the
maintenance of Xen stable branches.
Therefore disable the building of a kernel as part of the Xen
distribution by default and instead direct users to use an OS
distribution provided kernel (properly packaged with security updates
via the normal distribution mechanisms etc) where possible and give
pointers to suitable resources providing guidance for cases where it
is not.
This decouples the implicit advice as to the best kernel at any moment
from Xen's own release cycle and removes the implicit suggestion that
only particular domain 0 kernel will do.
The actual infrastructure is left in place since the automated test
system (currently) relies on it (but always asks for the specific
kernel variant it wants for a particular test).
(I also tried to remove Linux-isms from the README's Quick start
guide. In particular I'm not sure what was supposedly Linux specific
about steps 3 and 4 therefore I have removed the suggestion that they
are.)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
allows users to define more complex (e.g. type-safer) variations on
set_xen_guest_handle if they wish.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
single place for additional control that is required in nested VMX.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
single place for additional control that is required in nested VMX.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
For some reason, the memory region used for vmxon is named as
host_vmcs, which is somewhat misleading, rename it to vmxon_region as
SDM does.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
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>
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>
This introduced non-ANSI gcc-isms into the guest-visible sections of
public headers. Not allowed after all.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
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>
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>
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>
Enable a bunch of new Xen options, primarily blktap, PCI passthrough
and platform PCI device (PVHVM).
Also set default for a bunch of non-Xen options which are not covered
by the defconfig.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
APEI are ACPI4.0 new features. It consists of ERST, BERT, HEST, and
EINJ. ERST is used to save fault error log to a platform persistent
storage, so that when reboot os can retrieve the error log and handle
it.
This patch is used to implement ERST feature to Xen. It consists of
3-level hierarchy: operation level, action level, and instru= ction
level. Instruction do basic io; Action done by sequential
instructions parsed from ACPI ERST table; Operation done by
sequential actions defined by ACPI spec, providing erst_write/
erst_read/ erst_clear interfaces to MCE/ NMI/ PCIe error handling
mechanism, etc.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
We observed a 2.6.18.8 dom0 kernel crash when Xen has maxcpus < num
of physical cores (maxcpus=3D4 for a 12-core system). It appeared that
hypervisor doesn't check whether CPU is online or not. This small
patch fixed the issue.
Signed-off-by: Uwe Dannowski <uwe.dannowski@amd.com>
Acked-by: Wei Huang <wei.huang2@amd.com>
As pointed out in
http://lists.xensource.com/archives/html/xen-devel/2010-07/msg00077.html
the limits introduced in c/s 20072 are at least
questionable. Eliminate them in favor of a more dynamic approach:
There's no real need for an upper limit on nr_irqs (as anything beyond
nr_irqs_gsi isn't visible to domains anyway), and the split point (and
hence ratio) between GSI and MSI/MSI-X IRQs doesn't need to be hard
coded, but can instead be controlled on the command line in case there
are *very* many GSIs.
The default used for nr_irqs will be rather large with this patch, so
it may not be acceptable without also switching to a sparse irq_desc[]
as was done not so lomg ago in Linux.
The added capping of any domain's nr_pirqs is based on the observation
that no domain can possibly have more than the system wide number of
IRQs. The opposite case may in fact also require some adjustment:
Defaulting the number of non-GSI IRQs available (namely to Dom0) to a
fixed value may not be the best choice going forward, since if there
indeed are very many non-GSI interrupt sources, it won't be possible
for the kernel to make use of them without giving
"extra_guest_irqs=" on the command line (but the goal should be to
allow things to work right by default even on large systems).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
x2apic depends on interrupt remapping, so it should disable interrupt
remapping behind x2apic disabling. And also this patch wraps
__enable_x2apic to get rid of duplicated code.
Signed-off-by: Weidong Han <weidong.han@intel.com>
In ioapic_suspend, it reads and saves ioapic RTEs. But when interrupt
remapping is enabled, io_apic_read will call io_apic_read_remap_rte to
convert remapped format interrupt to compatible format, this results
in 'dest' field may be changed in remap_entry_to_ioapic_rte. When in
ioapic_resume, it will write the saved RTEs with incorrect 'dest' to
interrupt remapping table.
Actually it needn't to convert RTEs regardless interrupt remapping is
enabled or not. It just needs to save and restore RTE values
directly. This patch just uses __io_apic_read and __io_apic_write,
which won't call Interrupt remapping functions to convert, to save and
restore RTEs in ioapic_suspend and ioapic_resume. Thus fix this issue.
Signed-off-by: Weidong Han <weidong.han@intel.com>
In particular, this fixes setting vcpu affinities via
libxl. Previously, the affinity mask would be narrowed to the maximum
currently-online CPU. So future hotplugged CPUs could not be
expressed.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
The current version of the powernow driver uses the APERF/MPEF
and the HWCR MSRs. Add cases in traps.c to let dom0 access
those MSRs.
Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>
Change the meaning of credit1's "weight" parameter to be per-vcpu,
rather than per-VM.
At the moment, the "weight" parameter for a VM is set on a per-VM
basis. This means that when cpu time is scarce, two VMs with the same
weight will be given the same amount of total cpu time, no matter how
many vcpus it has. I.e., if a VM has 1 vcpu, that vcpu will get x% of
cpu time; if a VM has 2 vcpus, each vcpu will get (x/2)% of the cpu
time.
I believe this is a counter-intuitive interface. Users often choose
to add vcpus; when they do so, it's with the expectation that a VM
will need and use more cpu time. In my experience, however, users
rarely change the weight parameter. So the normal course of events is
for a user to decide a VM needs more processing power, add more cpus,
but doesn't change the weight. The VM still gets the same amount of
cpu time, but less efficiently allocated (because it's divided).
The attached patch changes the meaning of the "weight" parameter, to
be per-vcpu. Each vcpu is given the weight. So if you add an extra
vcpu, your VM will get more cpu time as well.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
When __pci_enable_msix() returns early, output parameter (struct
msi_desc **desc) will not be initialized. On my machine, a Broadcom
BCM5709 nic has both MSI and MSIX capability blocks and when guest
tries to enable msix interrupts but __pci_enable_msix() returns early
for encountering a msi block, the whole system will crash for fatal
page fault immediately.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
This is an attempt to impose some sensible coherent ordering on the
cpu namespace, where previously there was none (we were at the mercy
of BIOS ordering, which varies wildly across systems).
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Change p2m infrastructure to operate on per-p2m instead of per-domain.
This allows us to use multiple p2m tables per-domain.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
Currently, there has a logic to check whether the EPT GFN is exceeding
guest physical address width. It uses right shift(>>) to implement the
check. But the right shift count is greater than the width of the
type(unsigned long = 32) under the PAE. And this will cause guest boot
fail under PAE with EPT supported.
Signed-off-by: Li Xin <xin.li@intel.com>
Signed-off-by: Zhang Yang <yang.z.zhang@intel.com>
Corrects an error introduced with cs 21422.
Without the patch my machine crashed when removing a cpu from a
cpupool other than Pool-0.
Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
VMs that don't use their full timeslice are guaranteed to flip back
and forth between "active" and "inactive". If we set credit to 0
when setting "inactive", then when the VM comes back to "active"
again, it will effectively be behind most other vcpus in credit.
This causes the credit1 to effectively discriminate *against*
VMs which use less than their full timeslice.
Instead of setting credit to 0, divide it in half. This gets rid of
some of the system credit while allowing non-cpu-bound VMs to keep
some priority advantage.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
This patch implements 'yield' for credit1. It does this by attempting
to put yielding vcpu behind a single lower-priority vcpu on the
runqueue. If no lower-priority vcpus are in the queue, it will go at
the back (which if the queue is empty, will also be the front).
Runqueues are sorted every 30ms, so that's the longest this priority
inversion can happen.
For workloads with heavy concurrency hazard, and guest which implement
yield-on-spinlock, this patch significantly increases performance and
total system throughput.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
When ioapic_rte_to_remap_entry fails, currently it just writes value
to ioapic. But the 'mask' bit may be changed if it writes to the upper
half of RTE. This patch ensures to recover the original value of 'mask'
bit in this case.
Signed-off-by: Weidong Han <weidong.han@intel.com>
At the end of io_apic_write_remap_rte, it writes new entry (remapped
interrupt) to ioapic. But it writes low 32 bits before high 32 bits,
it unmasks interrupt before writing high 32 bits if 'mask' bit in low
32 bits is cleared. Thus it may result in issues. This patch fixes
this issue by writing high 32 bits before low 32 bits.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Weidong Han <weidong.han@intel.com>
Keir Fraser