Since we do not handle non-contiguous banks of memory lets avoid relocating
Xen into such a bank. Avoids issues such as free_init_memory releasing pages
which are outside of the frametable.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
This will stop us putting any heaps or relocating Xen itself over the FDT.
The devicetree will be copied to allocated memory in setup_mm and the
original copy will be freed by discard_initial_modules.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
My patch 08693f5948 "xen: arm: reduce the size of the xen heap to max 1/8
RAM size" unintentionally violated the constraint that the xenheap must be
32MB aligned, since we only explicitly align the end of the heap and
xenheap_pages was not a multiple of 32 pages.
Round xenheap pages up to a 32MB boundary.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
When a VCPU is not yet online, the registers contain garbagge. This will
result to call randomly BUG() in show_guest_stack.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Upstream commit 4370eec05a88 "arm64: Expand arm64 image header" ended up
changing the zImage magic (which was actually the initial branch instructio
encoding!). The new header has a proper magic number at a fixed location.
Switch Xen itself to using this format. Neither the bootwrapper nor the
models care about this header themselves and real bootloaders are not widely
used, so now is as good a time as any to switch (as upstream have proven)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Upstream commit 4370eec05a88 "arm64: Expand arm64 image header" ended up
changing the zImage magic (which was actually the initial branch instruction
encoding!). The new header has a proper magic number at a fixed location. Support that as well as the original magic.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
man/xl.cfg.pod.5 around line 1193: '=item' outside of any '=over'
POD document had syntax errors at /usr/bin/pod2man line 71.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Secondary CPUs will spin in head.S until their MPIDR[23:0] correspond to
the smp_up_cpu. Actually Xen will set the value with the logical CPU ID
which is wrong. Use the cpu_logical_map to get the correct CPU ID.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Introduce cpu_logical_map to associate a logical CPU ID to an hardware CPU ID.
This map will be filled during Xen boot via the device tree. Each CPU node
contains a "reg" property which contains the hardware ID (ie MPIDR[0:23]).
Also move /cpus parsing later so we can use the dt_* API.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The GIC mapping of CPU interfaces does not necessarily match the logical
CPU numbering.
When Xen wants to send an SGI to specific CPU, it needs to use the GIC CPU
ID. It can be retrieved from ITARGETSR0, in fact when this field is read,
the GIC will return a value that corresponds only to the processor reading
the register. So Xen can use the PPI 0 to initialize the mapping.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When Xen initialize the GIC distributor, we need to route all the IRQs to
the boot CPU. The CPU ID can differ between Xen and the GIC.
When ITARGETSR0 is read, each field will return a value that corresponds
only to the processor reading the register. So Xen can use the PPI 0 to
initialize correctly the routing.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This structure will gather all information to boot a secondary cpus.
For now it just contains the initial stack.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Rather than blindly defining the native name to the compat one, when
we want to pass the compat structure to a native function we ought to
verify that their layouts match. With a respective xlat.lst entry
there's then also no need anymore to do such aliasing.
While cleaaning up that file I also noticed that the Cx and Px
interface handling here has quite a few unnecessary #define-s - delete
them.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
When the permission checks for memory mapping were moved from
get_pg_owner to xsm_mmu_update in aaba7a677, the exception for DOMID_IO
was not taken into account. This will cause IO memory mappings by PV
domains (mini-os in particular) to fail when XSM/FLASK is not being
used. This patch reintroduces the exception for DOMID_IO; the actual
restrictions on IO memory mappings have always been checked separately
using iomem_access_permitted, so this change should not break existing
access control.
Reported-by: Eduardo Peixoto Macedo <epm@cin.ufpe.br>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Having nmi_shootdown_cpus() report which pcpus failed to be shot down is a
useful debugging hint as to what possibly went wrong (especially when the
crash logs seem to indicate that an NMI timeout occurred while waiting for one
of the problematic pcpus to perform an action).
This is achieved by swapping an atomic_t count of unreported pcpus with a
cpumask. In the case that the 1 second timeout occurs, use the cpumask to
identify the problematic pcpus.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Just learned the hard way that at least for non-volatile asm()s gcc
indeed does what the documentation says: It may move it across jumps
(i.e. ahead of the cpu_has() check). While the documentation claims
that this can also happen for volatile asm()s, if that was the case
we'd have many more problems in our code (and e,g, Linux would too).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
The wrong amount of indirections were being taken in
libxl_string_list_length, and its only caller was miscounting the amount
of initial non-list arguments, seemingly since the initial commit
(599c784).
This has been seen and reported in the wild (##xen):
< Trixboxer> Hi, any idea why would I get
< Trixboxer> xl: libxl_bootloader.c:42: bootloader_arg: Assertion `bl->nargs < bl->argsspace' failed.
< Trixboxer> 4.2.2-23.el6
Coverity-ID: 1054954
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When the permission checks for memory mapping were moved from
get_pg_owner to xsm_mmu_update in aaba7a677, the exception for DOMID_IO
was not taken into account. This will cause IO memory mappings by PV
domains (mini-os in particular) to fail when XSM/FLASK is not being
used. This patch reintroduces the exception for DOMID_IO; the actual
restrictions on IO memory mappings have always been checked separately
using iomem_access_permitted, so this change should not break existing
access control.
Reported-by: Eduardo Peixoto Macedo <epm@cin.ufpe.br>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Coverity ID: 1055622
Coverity correctly points out that this ASSERT() is unconditionally true as an
unsigned integer is always >= 0.
Judging from the shadow counterpart and p2m callsites, there is nothing
invalid about freeing the final p2m page.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
CID 1091471, Regression caused by 7c1de00388
This appears to be a typo which causes check_existence() to unconditionally
return 1 in all cases.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Till now, when setting previously unset bits in XCR0 we wouldn't touch
the active register state, thus leaving in the newly enabled registers
whatever a prior user of it left there, i.e. potentially leaking
information between guests.
This is CVE-2013-1442 / XSA-62.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
... when assembler supports it, following commit cfd54835 ("VMX: use
proper instruction mnemonics if assembler supports them"). This merely
got split off from the earlier change becase of the significant number
of call sites needing to be changed.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
We shouldn't do any acceleration for
- "rep movs" when either side is passed through MMIO or when both sides
are handled by qemu
- "rep ins" and "rep outs" when the memory operand is any kind of MMIO
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
... rather than just for the first byte.
While at it, also
- make the real mode case at least dpo a wrap around check
- drop the mis-named "gpf" label (we're not generating faults here)
and use in-place returns instead
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
For one, repeat count clipping for MOVS must be done taking into
consideration both source and destination addresses.
And then we should allow a wrap on the final iteration only if either
the wrap is a precise one (i.e. the access itself doesn't wrap, just
the resulting index register value would) or if there is just one
iteration. In all other cases we should do a bulk operation first
without hitting the wrap, and then issue an individual iteration. If
we don't do it that way,
- the last iteration not completing successfully will cause the whole
operation to fail (i.e. registers not get updated to the failure
point)
- hvmemul_virtual_to_linear() may needlessly enforce non-repeated
operation
Additionally with the prior implementation there was a case
(df=1, ea=~0, reps=~0, bytes_per_rep=1) where we'd end up passing zero
reps back to the caller, yet various places assume that there's at
least on iteration.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Ian Campbell
Julien Grall
Olaf Hering
Jan Beulich
Daniel De Graaf
Andrew Cooper
Zhu Yanhai
Matthew Daley