xen/arm: Fix regression after commit d963923

The commit d963923  "xen: arm: correct return value of
raw_copy_{to/from}_guest_*, raw_clear_guest" doesn't permit to boot guest
on Xen ARM.

Remove the stray semicolon from the end of the if statement.

Also we want to get the right rc in the error arrays, so we need to do the
copy_to_guest_offset before checking the rc returned by
xenmem_add_to_physmap_one.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- expanded commit log ]
libxl: ocaml: fix memory corruption when converting string and key/values lists

Found by Coverty. CIDs: 1128562 1128563 1128564 1128565.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libxl: ocaml: remove dead code in xentoollog bindings

Found by Coverty. CIDs: 1128567 1128568 1128576 1128577.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen: list interfaces subject to the security process exception in XSA-77

List all the sub ops of:
  __HYPERVISOR_domctl
  __HYPERVISOR_sysctl
  __HYPERVISOR_memory_op
  __HYPERVISOR_tmem_op
which are subject to the policy given in
http://xenbits.xen.org/xsa/advisory-77.html

It is expected that these lists will be whittled away as each interface is
audited for safety.

New interfaces should be expected to be safe when introduced (IOW the list
should never be expanded).

This is XSA-77.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
IOMMU: clear "don't flush" override on error paths

Both xenmem_add_to_physmap() and iommu_populate_page_table() each have
an error path that fails to clear that flag, thus suppressing further
flushes on the respective pCPU.

In iommu_populate_page_table() also slightly re-arrange code to avoid
the false impression of the flag in question being guarded by a
domain's page_alloc_lock.

This is CVE-2013-6400 / XSA-80.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
amd/passthrough: Do not leak domain mappings from do_invalidate_dte()

Coverity ID: 1135379

As the code stands, the domain mapping will be leaked on each error path.

The mapping can be for a much shorter period of time, and all the relevent
information can be pulled out at once.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
MAINTAINERS: Add Andres Lagar-Cavilla for mem-sharing/paging

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
x86/cpuidle: publish new states only after fully initializing them

Since state information coming from Dom0 can arrive at any time, on
any CPU, we ought to make sure that a new state is fully initialized
before the target CPU might be using it.

Once touching that code, also do minor cleanup: A missing (but benign)
"break" and some white space adjustments.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Liu Jinsong <jinsong.liu@intel.com>
x86/PV: don't commit debug register values early in arch_set_info_guest()

They're being taken care of later (via set_debugreg()), and temporarily
copying them into struct vcpu means that bad values may end up getting
loaded during context switch if the vCPU is already running and the
function errors out between the premature and real commit step, leading
to the same issue that XSA-12 dealt with.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
kexec/x86: do not map crash kernel area

This mapping was apparently never used.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
xen: arm: inject unhandled instruction and data aborts to the guest.

Currently an unhandled data abort in guest context leads to us killing the
guest and an unhandled instruction abort in guest context leads to us killing
the host!

Andre pointed out that an unhandled data abort can be caused by e.g. dmidecode
looking for things which are not there in the guests physical address space.
Propagating the fault to the guest allows it to properly SIGSEGV the
processes.

A guest kernel can trivially jump to an unmapped physical address which would
cause an instruction abort. Killing the host for that is obviously bad.
Instead inject the exception so the guest kernel can SIGSEGV or panic() etc as
it deems appropriate.

Tested on arm64 (Mustang) and arm32 (Midway) with a dom0 kernel late_initcall
which either dereferences or jumps to address 0, provoking both behaviours and
resulting correctly in a guest kernel panic. Also tested on fast models with a
32-bit dom0 on a 64-bit hypervisor, which behaved correctly.

In addition tested on both platforms with a userspace program which either
calls to or dereferences address 0. The process is correctly killed with SEGV.

Lastly tested on Mustang with a 32-bit version of the userspace test on a
64-bit dom0 kernel.

I think that covers all the cases.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: Andre Przywara <andre.przywara@calxeda.com>
[ ijc -- fixed up whitespace in if statements in cpsr_mode_switch ]
libxl: ocaml: add simple test case for xentoollog

Add a simple noddy test case (tools/ocaml/test) for the the Xentoollog OCaml
module.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
libxl: ocaml: implement some simple tests

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
libxl: ocaml: event management

Having bindings to the low-level functions libxl_osevent_register_hooks and
related, allows to run an event loop in OCaml; either one we write ourselves,
or one that is available elsewhere.

The Lwt cooperative threads library (http://ocsigen.org/lwt/), which is quite
popular these days, has an event loop that can be easily extended to poll any
additional fds that we get from libxl. Lwt provides a "lightweight" threading
model, which does not let you run any other (POSIX) threads in your
application, and therefore excludes an event loop implemented in the C
bindings.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libxl: ocaml: allow device operations to be called asynchronously

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
CC: David Scott <dave.scott@eu.citrix.com>
libxl: ocaml: add disk and cdrom helper functions

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libxl: ocaml: add VM lifecycle operations

Also:
* Reorganise toplevel OCaml functions into modules of Xenlight.
* Factor out the management of ao_how into the function aohow_val. The ao_how
  is now malloc'ed, just to make this function a little easier to use.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
libxl: ocaml: add console reader functions

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libxl: ocaml: drop the ocaml heap lock before calling into libxl

Ocaml has a heap lock which must be held whenever ocaml code is running. Ocaml
usually drops this lock when it enters a potentially blocking low-level
function, such as writing to a file. Libxl has its own lock, which it may
acquire when being called.

Things get interesting when libxl calls back into ocaml code. There is a risk
of ending up in a deadlock when a thread holds both locks at the same time,
then temporarily drop the ocaml lock, while another thread calls another libxl
function.

To avoid deadlocks, we drop the ocaml heap lock before entering libxl, and
reacquire it in callbacks to ocaml. This way, the ocaml heap lock is never held
together with the libxl lock, except in osevent registration callbacks, and
xentoollog callbacks. If we guarantee to not call any libxl functions inside
those callbacks, we can avoid deadlocks.

This patch handle the dropping and reacquiring of the ocaml heap lock by the
caml_enter_blocking_section and caml_leave_blocking_section functions, and
related macros. We are also careful to not call any functions that access the
ocaml heap while the ocaml heap lock is dropped. This often involves copying
ocaml values to C before dropping the ocaml lock.

The ao_how in aohow_val is now malloc'ed, just to make this function a little
easier to use.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libxl: ocaml: add some missing CAML macros

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>