IBM's Summit chipset was only used for 32-bit only Intel ccNUMA and
IA-64 machines, neither of which are supported by Xen anymore.
Signed-off-by: Matt Wilson <msw@amazon.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
... allowing bitmap operations to be used on it, making things
consistent with struct pi_desc's pir field, and shrinking overall
source code size.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
In particular, MMIO assignments should not be done using this area.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by Xiantao Zhang <xiantao.zhang@intel.com>
In one case it could easily be replaced by range checking the result of
a subsequent operation, and in general cpumask_next(), not always
needing to scan the whole bitmap, is more efficient than the specific
uses of cpumask_weight() here. (When running on big systems, operations
on CPU masks aren't cheap enough to use them carelessly.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
In one case it was redundant with the operation it got combined with,
and in the other it could easily be replaced by range checking the
result of a subsequent operation. (When running on big systems,
operations on CPU masks aren't cheap enough to use them carelessly.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
... with cpumask_any() or cpumask_cycle().
In one case this also allows elimination of a cpumask_empty() call,
and while doing this I also spotted a redundant use of
cpumask_weight(). (When running on big systems, operations on CPU masks
aren't cheap enough to use them carelessly.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
This is to avoid picking CPU0 for almost any such operation, resulting
in very uneven distribution of interrupt load.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
In order to achieve more symmetric distribution of certain things,
cpumask_any() shouldn't always pick the first CPU (which frequently
will end up being CPU0). To facilitate that, introduce a library-like
function to obtain random numbers.
The per-architecture function is supposed to return zero if no valid
random number can be obtained (implying that if occasionally zero got
produced as random number, it wouldn't be considered such).
As fallback this uses the trivial algorithm from the C standard,
extended to produce "unsigned int" results.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
The first (PAT6) column was wrong across the board, and the column for
PAT7 was missing altogether.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Considering that a significant share of PCI devices out there (not the
least the myriad of CPU-exposed ones) don't support MSI-X at all, and
that the amount of data is well beyond a handful of bytes, break this
out of the common structure, at once allowing the actual data to be
tracked to become architecture specific.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Just like Linux did many years ago, move them into a separate (data)
section, such that they no longer pollute instruction caches and TLBs.
Assertion frames, requiring two pointers to be stored, occupy two slots
in the array, with the second slot mimicking a frame the location
pointer of which doesn't match any address within .text or .init.text
(it effectively points back to the slot itself, which - being in a data
section - can't be reached by non-buggy execution).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
This comes from the Linux patches 15e7e5c1ebf5 for arm32 and 4ecf7ccb1973 for
arm64 by Will Deacon and Catalin Marinas respectively. The Linux commit message
says:
An exclusive store instruction may fail for reasons other than lock
contention (e.g. a cache eviction during the critical section) so, in
line with other architectures using similar exclusive instructions
(alpha, mips, powerpc), retry the trylock operation if the lock appears
to be free but the strex reported failure.
I have observed this due to register_cpu_notifier containing:
if ( !spin_trylock(&cpu_add_remove_lock) )
BUG(); /* Should never fail as we are called only during boot. */
which was spuriously failing.
The ARMv8 variant is taken directly from the Linux patch. For v7 I had to
reimplement since we don't currently use ticket locks.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
This picks up the changes from Linux commit 3a0310eb369a:
arm64: atomics: fix grossly inconsistent asm constraints for exclusives
Our uses of inline asm constraints for atomic operations are fairly
wild and varied. We basically need to guarantee the following:
1. Any instructions with barrier implications
(load-acquire/store-release) have a "memory" clobber
2. When performing exclusive accesses, the addresing mode is generated
using the "Q" constraint
3. Atomic blocks which use the condition flags, have a "cc" clobber
This patch addresses these concerns which, as well as fixing the
semantics of the code, stops GCC complaining about impossible asm
constraints.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
This patch replaces the previous hashed lock implementaiton of bitops with
assembly optimized ones taken from Linux v3.10-rc4.
The Linux derived ASM only supports 8 byte aligned bitmaps (which under Linux
are unsigned long * rather than our void *). We do have actually uses of 4
byte alignment (i.e. the bitmaps in struct xmem_pool) which trigger alignment
faults.
Therefore adjust the assembly to work in 4 byte increments, which involved:
- bit offset now bits 4:0 => mask #31 not #63
- use wN register not xN for load/modify/store loop.
There is no need to adjust the shift used to calculate the word offset, the
difference is already acounted for in the #63->#31 change.
NB: Xen's build system cannot cope with the change from .c to .S file,
remove xen/arch/arm/arm64/lib/.bitops.o.d or clean your build tree.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
TI OMAP UART introduces some features such as register access modes, which
makes its configuration and interrupt handling differs from 8250 compatible
UART. Thus, we seperate this driver from ns16550's implementation.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Both OMAP5 and sun6i/sun7i SoCs share this UART driver for early_printk.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Since UARTs on OMAP5 & Allwinner's SoC are not ns16550 but only 8250
compatible, rename ns16550-uart.h to 8250-uart.h, which is a more pervasive
name. At the same time, fix some typos, which have redundance UART_
prefixes in some macros.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Keir Fraser <keir@xen.org>
As Julien pointed out the other day, the data type for the platform
DT name match struct is wrong.
To be really immutable, we have to use "const char * const".
Fix it on the three currently existing platforms.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 6859874b61 ("x86/HVM: fix x2APIC
APIC_ID read emulation") introduced an error for the hvm emulation of
x2apic. Any try to write to APIC_ICR MSR will result in a GP fault.
Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
If enabling APIC-v, all interrupts to L1 are delivered through APIC-v.
But when L2 is running, external interrupt will casue L1 vmexit with
reason external interrupt. Then L1 will pick up the interrupt through
vmcs12. when L1 ack the interrupt, since the APIC-v is enabled when
L1 is running, so APIC-v hardware still will do vEOI updating. The problem
is that the interrupt is delivered not through APIC-v hardware, this means
SVI/RVI/vPPR are not setting, but hardware required them when doing vEOI
updating. The solution is that, when L1 tried to pick up the interrupt
from vmcs12, then hypervisor will help to update the SVI/RVI/vPPR to make
sure the following vEOI updating and vPPR updating corrently.
Also, since interrupt is delivered through vmcs12, so APIC-v hardware will
not cleare vIRR and hypervisor need to clear it before L1 running.
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: "Dong, Eddie" <eddie.dong@intel.com>
There is no vAPIC-v support, so mask APIC-v control bit when
constructing vmcs02.
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: "Dong, Eddie" <eddie.dong@intel.com>
External interrupt is allowed to notify CPU only when it has higher
priority than current in servicing interrupt. With APIC-v, the priority
comparing is done by hardware and hardware will inject the interrupt to
VCPU when it recognizes an interrupt. Currently, there is no virtual
APIC-v feature available for L1 to use, so when L2 is running, we still need
to compare interrupt priority with ISR in hypervisor instead via hardware.
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: "Dong, Eddie" <eddie.dong@intel.com>
If interrupt is blocked by L1's TPR, L2 should not see it and keep
running. Adding the check before L2 to retrive interrupt.
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: "Dong, Eddie" <eddie.dong@intel.com>
... as being insecure.
Also drop the second (redundant) read DMAR_GSTS_REG from enable_intremap().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by Xiantao Zhang <xiantao.zhang@intel.com>
If this option is given don't bother building qemu-xen ourselves. Likely to be
handy for distros who have an existing qemu package which they want to reuse.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Now that we have upstream qemu people may want to avoid building this extra
code.
There is a little bit of trickery in stubdom/configure.ac to ensure that the
ioemu stubdom is only built if qemu-traditional is enabled.
libxl will return an error if a caller tries to build a domain using
qemu-xen-traditional when this support was disabled at build time. Since
qemu-xen-traditional has been historically tightly bound to the Xen releases I
don't see any value in supporting "3rd party" provision of
qemu-xen-traditional.
We also do not want/need this on ARM therefore default is on for x86 and off
otherwise.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ ijc -- trivial conflicts in Tools.mk.in and tools/configure.ac.
Reran autogen.sh ]
The PL011 IMSC register description is somehow fuzzy in the
documentation; by comparing it with the Linux implementation one can
see that the logic is actually reversed to Xen's implementation:
A "0" in field means interrupt disabled, a "1" enables it.
Therefore we enabled all interrupts instead of disabling them in the
beginning and later on masked the wrong interrupts.
Unclear how this worked on the Versatile Express, but this fix is
needed to get Calxeda Midway running (and works on VExpress, too).
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This drops the post-boot use of __acpi_map_table() here again (together
with the somewhat awkward locking), in favor of using ioremap().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
It using map_domain_page() was entirely wrong. Use __acpi_map_table()
instead for the time being, with locking added as the mappings it
produces get replaced with subsequent invocations. Using locking in
this way is acceptable here since the only two runtime callers are
acpi_os_{read,write}_memory(), which don't leave mappings pending upon
returning to their callers.
Also fix __acpi_map_table()'s first parameter's type - while benign for
unstable, backports to pre-4.3 trees will need this.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Guest needs the ability to enable and disable MSI-X interrupts
by setting the MSI-X control bit, for a passed-through device.
Guest is allowed to write MSI-X mask bit only if Xen *thinks*
that mask is clear (interrupts enabled). If the mask is set by
Xen (interrupts disabled), writes to mask bit by the guest is
ignored.
Currently, a write to MSI-X mask bit by the guest is silently
ignored.
A likely scenario is where we have a 82599 SR-IOV nic passed
through to a guest. From the guest if you do
ifconfig <ETH_DEV> down
ifconfig <ETH_DEV> up
the interrupts remain masked. On VF reset, the mask bit is set
by the controller. At this point, Xen is not aware that mask is set.
However, interrupts are enabled by VF driver by clearing the mask
bit by writing directly to BAR3 region containing the MSI-X table.
From dom0, we can verify that
interrupts are being masked using 'xl debug-keys M'.
Initially, guest was allowed to modify MSI-X bit.
Later this behaviour was changed.
See changeset 74c213c506.
Signed-off-by: Joby Poriyath <joby.poriyath@citrix.com>
[jb: add assertion to msixtbl_pt_register()]
We have plenty of virtual address space so we can avoid needing to map and
unmap pages all the time.
A totally arbitrarily chosen 32GB frame table leads to support for 5TB of RAM.
I haven't tested with anything near that amount of RAM though. There is plenty
of room to expand further when that becomes necessary.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This seems to be expected by common code which passes both pointers and
unsigned long as virtual addresses. The latter case in particular is in
init_node_heap() under a DIRECTMAP_VIRT_END #ifdef, which is why it hasn't
affected us yet (but will in a subsequent patch).
The new prototypes match the x86 versions apart from using vaddr_t instead of
unsigned long.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
The current implementation is nonsense since the xenheap and the xen
text/data/etc mappings are nowhere near each other.
This is only actually used by the page offlining code, which isn't active on
ARM.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
The open coded version is pretty ugly, not helped by rigid enforcement of an
80 character line length.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Allow it to work on contiguous second level tables mapping an arbitrary region
of memory. Rename it to create_32mb_mappings.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
When building a 1GB dom0 on a system with 2GB RAM we are running out of domheap
pages, while there are still plenty of xenheap pages spare.
I would have sworn that when the domheap was exhausted we would fall back to
allocating xenheap pages but this doesn't appear to be the case. It's possible
that we have setup something incorrectly on ARM but alloc_domheap_pages pretty
clearly tries to allocate memory from MEMZONE_XEN+1..zone_hi.
Without the fallback from domheap to xenheap taking 1GB of any system with >1GB
of RAM for xenheap is excessive so instead set a limit of 1/8 of the total
amount of RAM. By way of comparison x86_32 used to have a static 12MB xenheap
(which also included .text etc) and in theory supported up to 16GB RAM, by that
measure 1/8 is plenty.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Matt Wilson
Jan Beulich
Ian Campbell
Chen Baozi
Andre Przywara
Juergen Gross
Yang Zhang
Joby Poriyath