Primarily this means XENMEM_decrease_reservation from a toolstack
domain.
Unlike x86 we have no requirement right now to queue such pages onto
a separate list, if we hit this race then the other code has already
fully accepted responsibility for freeing this page and therefore
there is no more for relinquish_memory to do.
This is CVE-2015-7814 / XSA-147.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
These are guest accessible and should therefore be rate-limited.
Moreover, include them only in debug builds.
This is CVE-2015-7813 / XSA-146.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Multicall for ARM has been supported since commit f0dbdc6 "xen: arm: fully
implement multicall interface.". Although, if an hypercall in multicall
requires preemption, it will crash the host:
(XEN) Xen BUG at domain.c:347
(XEN) ----[ Xen-4.7-unstable arm64 debug=y Tainted: C ]----
[...]
(XEN) Xen call trace:
(XEN) [<00000000002420cc>] hypercall_create_continuation+0x64/0x380 (PC)
(XEN) [<0000000000217274>] do_memory_op+0x1b00/0x2334 (LR)
(XEN) [<0000000000250d2c>] do_multicall_call+0x114/0x124
(XEN) [<0000000000217ff0>] do_multicall+0x17c/0x23c
(XEN) [<000000000024f97c>] do_trap_hypercall+0x90/0x12c
(XEN) [<0000000000251ca8>] do_trap_hypervisor+0xd2c/0x1ba4
(XEN) [<00000000002582cc>] guest_sync+0x88/0xb8
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 5:
(XEN) Xen BUG at domain.c:347
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)
Looking to the code, the support of multicall looks valid to me, as we only
need to fill call.args[...]. So drop the BUG();
This is CVE-2015-7812 / XSA-145.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The variable "svc" is declared twice within rt_dom_cntl. However, the
top declaration could be re-used avoiding re-declaring another time the
variable.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
The variable "cur" is declared twice within "cur". However the top
declaration could be re-used avoiding re-declaring another time the
variable.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The variable "d" is declared multiple times within do_memory_op.
The subsequent declaration are not useful because the top one is never
used. So drop them.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The variable "frame" is declared twice within the function
__gntab_map_grant_ref. This makes the code quite confusing to read.
The second definition is not useful as the first one is never used
until then. So drop it.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The variable "d" is defined twice. However, the second one is not
necessary as the vCPU as already been deduced from the first "d".
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
No need to generate xen/lowlevel/xl/_pyxl_types.{h,c}, following c/s
598e97f "tools/python: remove broken xl binding"
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Somehow I managed to drop the HVM dependency from v2 to v3 of what
became commit 5c23c760a8 ("x86/HVM: correct page dirty marking in
hvm_map_guest_frame_rw()"), obviously breaking migration of PV guests.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The current domain and the domain pointed by the variable "d" are not
the same.
However, when it's not possible to get a reference on the page, the
target domain ID is not printed. This makes the message difficult to
understand.
Improve the message by printing the target domain ID.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Direct mapped domain needs to retrieve the exact same underlying
physical page when the region is re-populated.
Currently, when the memory reservation for this domain is decreased, the
request is just ignored and the page stayed mapped in the P2M. However,
this make more difficult to spot issue when the domain has not yet mapped
foreign page but trying to access the region.
What we really care for direct mapped domain is to not give back the
page to the allocator. So we can re-enable to direct mapped when the guest
memory region is re-populated.
The rest of the process to remove a page can be safely done. This
also ensures us to stay close to the normal domain memory handling.
At the same time, drop the trailing whitespaces around the code
modified.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It doesn't depend on GUEST_PAGING_LEVELS. Moving the function to p2m.c
at once allows a bogus #define/#include pair to be removed from
hap/nested_ept.c.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
To make it possible to tell apart the static symbols therein, use their
object file names instead of their source ones.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Rather than dirtying a page when establishing a (permanent) mapping,
dirty it when the page gets unmapped, or - if still mapped - on the
final iteration of a save operation (or in other cases where the guest
is paused or already shut down). (Transient mappings continue to get
dirtied upon getting mapped, to avoid the overhead of tracking.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Future work will rearange it, invalidating these assumptions.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Expose them to assembly code, and replace open-coded versions.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The last parameter of alloc_domheap_page{s,} contain the memory flags and
not the order of the allocation.
Use 0 for the call in p2m_pod_set_cache_target as it was before
1069d63c5e "x86/mm/p2m: use defines for
page sizes". Note that PAGE_ORDER_4K is also equal to 0 so the behavior
stays the same.
For the call in p2m_pod_offline_or_broken_replace we want to allocate
the new page on the same numa node as the previous page. So retrieve the
numa node and pass it in the memory flags.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Tested-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
assert is not async-signal-safe.
In practice the effect of calling assert there is that if the
assertion fails we might get a secondary crash, or other undesirable
behaviour from stdio (which is how assert usually reports failures).
Mention in a comment in libxl__self_pipe_wakeup that it has to be
async-signal-safe.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
It will avoid to introduce a new XEN_PSCI_* define every time we support
a new version of PSCI in Xen.
Also fix the coding style in modified place.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
From Xen's point of view, PSCI v0.2 and PSCI v1.0 are very similar. All
the PSCI calls used within Xen (PSCI_VERSION, CPU_ON, SYSTEM_OFF and
SYSTEM_RESET) behave exactly the same.
Furthermore, based on the spec (5.3.1 DEN0022C), any 1.y version must be
compatible with 1.x when y > x for any functions existing in 1.x.
So check the presence of the new compatible string [1] and allow Xen to
boot on any platform using PSCI 1.x.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374547.html
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
All the quirks have been replaced by proper detection. Lets drop the
callback and hope that no one will need new quirks.
At the same time, remove the definition of platform_dom0_evtchn_ppi
which is not used any more.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- typos ]
We are currently using a per-platform quirk to know if the 2 4KB region of
the GIC CPU interface are each aligned to 64KB. Although, it may be
possible to have different layout on a same platform (depending on the
firmware version).
Rather than having a quirk it's possible to detect by reading the GIC
memory. This patch is based from the Linux commit "irqchip/GIC: Add workaround
for aliased GIC400" [1].
Take the opportunity to clean up the GICv2 of code which was only
required because of the quirk.
Note that none of the platform using the gic-hip04 were actually using
the quirk, so the code has been dropped. I will let the maintainers
decide whether it's relevant or not to add proper detection for aliased
GIC for this hardware.
[1] commit 12e14066f4835f5ee1ca795f0309415b54c067a9
Author: Marc Zyngier <marc.zyngier@arm.com>
Date: Sun Sep 13 12:14:31 2015 +0100
irqchip/GIC: Add workaround for aliased GIC400
The GICv2 architecture mandates that the two 4kB GIC regions are
contiguous, and on two separate physical pages (so that access to
the second page can be trapped by a hypervisor). This doesn't work
very well when PAGE_SIZE is 64kB.
A relatively common hack^Wway to work around this is to alias each
4kB region over its own 64kB page. Of course in this case, the base
address you want to use is not really the begining of the region,
but base + 60kB (so that you get a contiguous 8kB region over two
distinct pages).
Normally, this would be described in DT with a new property, but
some HW is already out there, and the firmware makes sure that
it will override whatever you put in the GIC node. Duh. And of course,
said firmware source code is not available, despite being based
on u-boot.
The workaround is to detect the case where the CPU interface size
is set to 128kB, and verify the aliasing by checking that the ID
register for GIC400 (which is the only GIC wired this way so far)
is the same at base and base + 0xF000. In this case, we update
the GIC base address and let it roll.
And if you feel slightly sick by looking at this, rest assured that
I do too...
Reported-by: Julien Grall <julien.grall@citrix.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Stuart Yoder <stuart.yoder@freescale.com>
Cc: Pavel Fedin <p.fedin@samsung.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Link: http://lkml.kernel.org/r/1442142873-20213-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The size of the CPU interface will be used in a follow-up patch to map the
region in Xen memory.
Based on GICv2 spec, the CPU interface should at least be 8KB, although
most of the platform we are supporting use incorrectly the GICv1 size
(i.e 4KB) in their DT. Only warn and update the size to avoid any
breakage on these platforms.
Furthermore, Xen is relying on the fact that the Virtual CPU interface
is at least 8KB. As in reality the Virtual CPU interface matches the CPU
interface, check that the 2 interfaces have the same size.
For GICv3, vGICv2 is only available for guest. So we only need to check
that the GICV is at least 8KB.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- typos ]
The GICv2 DT node is usually used by the guest to know the address/size
of the regions (GICD, GICC...) to map into their virtual memory.
While the GICv2 spec requires the size of the GICC to be 8KB, we
correctly do an 8KB stage-2 mapping but erroneously report 256 in the
device tree (based on GUEST_GICC_SIZE).
I bet we didn't see any issue so far because all the registers except
GICC_DIR lives in the first 256 bytes of the GICC region and all the
guests I have seen so far are driving the GIC with GICC_CTLR.EIOmode =
0.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- fixed some typos in commit message ]
Various people say this binding doesn't compile or doesn't work. Remove
it for the benefit of xl feature development -- so that new features
won't need to worry about making this broken binding happy.
This isn't going to expose any user visible changes because that module
is not built by default.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Zhigang Wang <zhigang.x.wang@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
With the current log is not possible for the user to understand
properly the error:
(XEN) Grant table range: 0x0000007fc00000-0x0000007fc72000
(XEN) DT: no ranges; cannot enumerate
(XEN) Device tree generation failed (-22).
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Could not set up DOM0 guest OS
(XEN) ****************************************
(XEN)
The other error message within the function already print the DT path.
Do the same here.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
The pv domain builder currently supports the additional flag
"superpages" to build a pv domain with 2MB pages. This feature isn't
being used by any component other than the python xc bindings.
Remove the flag and its support from the xc bindings and the domain
builder
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This is the xl/xc changes to support Intel Code/Data Prioritization.
CAT xl commands to set/get CBMs are extended to support CDP.
Add new CDP options with CAT commands in xl interface man page.
Add description of CDP in xl-psr.markdown.
Signed-off-by: He Chen <he.chen@linux.intel.com>
Reviewed-by: Chao Peng <chao.p.peng@linux.intel.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
When a guest configuration list xvdX for its disks, there is no need to
provide an emulated driver for the same target.
Such configuration can work with the OVMF firmware, as it supports PV
disk.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
GC* assume an existing gc in scope, which means they can't be passed
NOGC. Instead recommend the use of the underlying functions with NOGC,
noting that this is excepitonal.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ ijc -- refer to libxl__calloc not (nonexistent) libxl__alloc ]
This is the result of
$ find -name \*.l -exec touch {} \;
$ find -name \*.y -exec touch {} \;
and then rebuilding.
This avoids churn on the machine I use for committing which has been
updated, causing flex to go from 2.5.35-10.1 to 2.5.39-8.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Upstream qemu is now in qemu-xen.git and the trad fork is in
qemu-xen-traditional.git.
QEMU_UPSTREAM_REVISION is currently a tag and
QEMU_TRADITIONAL_REVISION is a specific revision, so no changes are
required to those.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
They (as a now being removed comment validly says) depend only on Xen's
number of page table levels, and hence their tags didn't serve any
useful purpose (there could only ever be one instance in a single
binary, even back in the x86-32 days).
Further conditionalize the inclusion of PV-specific hook pointers, at
once making sure that PV guests can't ever get other than 4-level mode
enabled for them.
For consistency reasons shadow_{write,cmpxchg}_guest_entry() also get
moved next to the other PV-only actors, allowing them to become static
just like the $subject ones do.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Instead of the misleading _guest_<level> ones use _sh_<level>,
expressing their sole dependency on the number of shadow levels.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
... to eliminate the resulting duplicate symbols. This includes
dropping an odd per-CPU variable left from 32-bit days: Now that we
only care about 64-bit builds, converting the uint64_t needing
passing to a void pointer is no problem anymore.
Since the COMPAT handling section needs to be re-organized for this
anyway, also adjust a few other shortcomings (like declarations not
being visible at the point of the respective definition, risking both
to get out of sync).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Existing PML implementation turns on EPT A/D bit unconditionally if PML is
supported by hardware. This works but enabling of EPT A/D bit can be deferred
until PML get enabled. There's no point in enabling the extra feature for every
domain when we're not meaning to use it (yet).
Also added ASSERT of domain having been paused to ept_flush_pml_buffers to make
it consistent with ept_enable{disable}_pml.
Sanity live migration and GUI display were tested on Broadwell Machine.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Kai Huang <kai.huang@linux.intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Commit 6f8f53cc64 ("x86 cpu: Fix bug: unify cpu_dev attr as
__cpuinitdata") fixed centaur_cpu_dev's annotation without also fixing
the pointers hanging off of it. Even if CPU hotplig support may be
purely theoretical for Centaur, we should still not leave this as is.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Their initialization happens without races, so there's no point in
using atomic (locked) operations to update the respective flags.
(There's one case where the clear_bit() was completely pointless.)
Also drop a neighboring stale comment from AMD code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Ian Campbell
Julien Grall
Andrew Cooper
Jan Beulich
Shuai Ruan
Ian Jackson
Wei Liu
Juergen Gross
He Chen
Anthony PERARD
Kai Huang