xen/arm: add_to_physmap_one: Avoid to map mfn 0 if an error occurs

By default, the function add_to_physmap_one set mfn to 0. Some code paths that
result to an error, continue and the map the mfn 0 (valid on ARM) to the
slot given by the guest.

To fix the problem, return directly an error if sanity check has failed.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
netif.h: Add IPv6 related changes

My recent patch series to Linux netback added IPv6 checksum
offload and GSO support. This involved making some changes to the
copy of netif.h in Linux.
This patch adds those changes to the canonical copy of netif.h.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm: fix a typo in comment of PLATFORM_QUIRK_DOM0_MAPPING_11

Signed-off-by: Chen Baozi <baozich@gmail.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen/arm: implement smp initialization callbacks for omap5

Signed-off-by: Chen Baozi <baozich@gmail.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen/arm: Allocate memory for dom0 from the bottom with the 1:1 Workaround

On Linux, the option CONFIG_ARM_PATCH_PHYS_VIRT (by default enabled) allows
the Kernel to be loaded anywhere (or nearly) by patching the translation
pv<->virt at boot time.

The current solution in Linux assuming that the delta physical address -
virtual address is always negative. A positive delta will destroy all the
optimisation to modify only a part of the translation instruction (add/sub).

By default, Xen is allocating memory from the top of memory and then
goes down. To avoid booting issue with Linux, we must allocate memory
from the bottom (ie starting from 0).

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen: arm: correct XEN_COMPILE_ARCH autodetection for arm64

At least on aarch64 openSUSE running with qemu-user-aarch64 "uname -m" reports
"aarch64" and not "armv8" so include that in the seddery. There's no harm
leaving the existing armv8 rune too so do so.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: fix usage of bootargs for Xen.

The chosen node's bootargs property should be used for Xen if there is a dom0
kernel multiboot module with a command line, not just if xen,dom0-bootargs is
present.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.linaro.org>
xen: correct xenheap_bits after "xen: support RAM at addresses 0 and 4096"

This is incorrect after commit 1aac966e24e which shuffled the zones up by one.
I've observed failures on arm64 systems with RAM at 0x8,00000000-0x8,7fffffff
since xenheap_bits ends up as 35 instead of 36 (which is the zone with all the
RAM).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
xen: arm: Enable 40 bit addressing in VTCR for arm64

This requires setting the v8 specific VTCR_EL2.PS field. These bits are
UNK/SBZP on v7.

Also the TS0SZ field is described slightly differently for v8, so update the
comment to reflect this.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: map entire memory banks on arm64

Currently we only map regions which are not part of boot modules. However we
subsequently free at least some of those modules to the heaps in
discard_initial_modules and if we were unluckly with sizing/location we might
end up adding unmapped pages to the heap.

The heaps on 64-bit use 1GB mappings, so in practice this is probably pretty
unlikely and I've not actually seen it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: make sure pagetable mask macros have appropriate size

{ZEROETH,FIRST,SECOND,THIRD}_MASK are used with physical addresses which may
be larger than 32 bits. Therefore ensure that they are wide enough by casting
to paddr_t otherwise we may truncate addresses on 32-bit.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: correctly round down MFN to 1GB boundary make sure pagetable mask macros as physaddr size

~FIRST_MASK is nothing like correct for rounding down an MFN. It is the
inverse *and* an address not a framenumber so wrong in every dimension! We
cannot use FIRST_MASK since that would mask off any zeroeth level bits.
Instead calculate the correct value from FIRST_SIZE.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: Ensure HCR_EL2.RW is set correctly when building dom0

copy_to_user and friends rely on this, since the address transalation
functions (guest VA -> MFN) will truncate VA to the appropriate size.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xenctx: fix typo in arm64 output

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
common/initcall: extern linker symbols with correct types

Coverity IDs 1054956, 1054957

Coverity pointed out that we applying array operations based on an expression
which yielded singleton pointers.  The problem is actually that the externs
were typed incorrectly.

Correct the extern declaration to prevent straying into undefined behaviour,
and relying on the lenience of GCC to work.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
x86: refine address validity checks before accessing page tables

In commit 40d66baa ("x86: correct LDT checks") and d06a0d71 ("x86: add
address validity check to guest_map_l1e()") I didn't really pay
attention to the fact that these checks would better be done before the
paging_mode_translate() ones, as there's also no equivalent check down
the shadow code paths involved here (at least not up to the first use
of the address), and such generic checks shouldn't really be done by
particular backend functions anyway.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
x86/irq: print direct vector mappings in the 'i' debug key

Also adjust the initial print message, as the IRQ loop has contained
non-guest interrutps for a while now.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
libelf: improve errors in elf_xen_note_check()

I recently debugged an isolated failure to boot, with no information other
than the logs.

The "Will only load images built for the generic loader or Linux images"
string was missing a newline, leading to the subsequent error being appended
to this line, rather than having its own line with correctly identified
function.

Furthermore, error messages which state "param containing $FOO is not $BAR" is
fairly useless for debugging without identifying which bad $FOO caused the
failure.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl: remove spurious newline from LOG() message

The macro already includes this.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxenstore: Use PTHREAD_STACK_MIN

The existing value of 16K is smaller than the arm64 minimum stack size, which
is 128K. PTHREAD_STACK_MIN appears to be standard
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstacksize.html

Consindered setting a lower bound but the stack requirements of the watcher
thread are pretty minimal (tens of bytes from the looks of it) and unlikely to
blow PTHREAD_STACK_MIN on any useful platform.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>