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>
On ARM event-channel upcalls are masked using the hardware's interrupt mask
bit and not by a software bit.
Leaving this field present in the interface has caused some confusion already
and is liable to mean it gets inadvertently used in the future. So arrange for
this field to be turned into a padding field on ARM by introducing a
XEN_HAVE_PV_UPCALL_MASK define.
This bit is also unused for x86 PV-on-HVM guests, but we can't realistically
distinguish those from x86 PV guests in the headers.
Add a per-arch vcpu_event_delivery_is_enabled function to replace an open
coded use of evtchn_upcall_mask in common code (in a debug keyhandler). The
existing local_event_delivery_is_enabled, which operates only on current, was
unimplemented on ARM and unused on x86, so remove it.
ifdef the use of evtchn_upcall_mask when setting up a new vcpu info page.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
mkheader.py doesn't cope with
struct foo { };
so add a newline.
Define unsigned long and long to a non-existent type on ARM so as to catch
their use.
Teach mkheader.py to cope with structs which are ifdef'd. This cannot cope
with #defines between the #ifdef and the struct definitions, so move
MAX_GUEST_CMDLINE to be next to its only usage.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This allows us expose or hide interface features on different architectures
without requiring nasty arch-specific ifdeffery.
Preserves any #ifdef with a XEN_HAVE_* symbol name, as well as any #else or
The ifdef symbol becomes COMPAT_HAVE in the compat versions so that
architectures can enable or disable interfaces for compat mode too. (This
actually just fell out of the way the existing stuff works and it didn't seem
worth jumping through hoops to make the name remain XEN_HAVE).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
I'm not even sure what this thing is. Looks like some sort of Twisted Python
based frontend to xend.
Whatever it is I am perfectly sure no one can be using it. Apart from drive by
build fixes caused by updates elsewhere it has seen no real development since
2005. I suspect it was never even finished/usable.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
I don't think there are any dom0's around whose kernels support only blktap1
and not something newer like blktap2 or qdisk. Certainly not that you would
want to run Xen 4.4 on.
libxl will never use blktap1.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Just a few things which I noticed which I'm sure aren't relevant now. I'm sure
there is plent of other cruft but I didn't do any sort of audit.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This was apparently a Qt xenstore viewer. It hasn't been touched since it was
first committed in 2007 and I can't beleive anyone is actually using even if
it still happens to work.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Matt Wilson <msw@amazon.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
We have defaulted to using the system libaio for a while now and I din't think
there are any relevant distros which don't have it that running Xen 4.4 would
be reasonable on.
Also it has caused confusion because it is not ever wanted on ARM, but the
build system doesn't express that (could be fixed, but deleting is the right
thing to do anyway).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Matt Wilson <msw@amazon.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
xend has been deprecated for 2 releases now. Lets make it possible to not even
build it.
For now I'm leaving the default of on but I would like to change that before
the 4.4 release.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Matt Wilson <msw@amazon.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Calxeda Midway is an ARMv7 server platform with Cortex-A15 cores.
The peripheral side has many similarities with the machine known as
Highbank.
Add Calxeda Midway to the list of supported platforms to avoid a
warning on boot and provide the proper reset method.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
There's no need for xl to output these messages on HVM domain creation
to stderr by default.
Change their loglevels from XTL_INFO to XTL_DETAIL; then the messages
output by xl are the same as those for PV domain creation. These
now-silenced messages can still be seen using verbose (-v) mode.
Signed-off-by: Matthew Daley <mattjd@gmail.com>
A recent change in GNU cut disallows use of a newline as a field
delimiter. Avoid the problematic use of cut in vif-bridge.
Signed-off-by: Bob Proulx <bob@proulx.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The PL011 driver currently sets the baudrate to a hardcoded value of
38400 bits/second. This will break Calxeda Midway, which uses 115200
bps.
Instead don't tinker with the baud rate register at all and rely on
the firmware or bootloader setting the correct value in here.
This works fine on Versatile Express and Calxeda Midway.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
From the errata document:
When a non-secure non-hypervisor memory operation instruction generates a
stage2 page table translation fault, a trap to the hypervisor will be triggered.
For an architecturally defined subset of instructions, the Hypervisor Syndrome
Register (HSR) will have the Instruction Syndrome Valid (ISV) bit set to 1’b1,
and the Rt field should reflect the source register (for stores) or destination
register for loads.
On Cortex-A15, for Thumb and ThumbEE stores, the Rt value may be incorrect
and should not be used, even if the ISV bit is set. All loads, and all ARM
instruction set loads and stores, will have the correct Rt value if the ISV
bit is set.
To avoid this issue, Xen needs to decode thumb store instruction and update
the transfer register.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Some errata on ARM processor requires to decode the instruction.
The decoder will, obviously, decode and fill the ISS fields of the hsr_dabt.
For the moment, the decoder only supports:
- THUMB2 store instruction
- THUMB single load/store instruction
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The return value of vasprintf must be checked. This check is enforced
with the compiler options used in Debian by request and in Ubuntu by
default.
Check the return value and abort on error.
Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
These allow an x86_64 hypervisor to build on FreeBSD 9.1/amd64.
- like OpenBSD, needs a different arch passed to ld.
- like OpenBSD, stdarg.h and stdbool.h are in /usr/include.
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
The stack segment is legacy remnant of a 32bit hypervisor, and not used in
64bit. Furthermore, the unsigned short in the structure actually aliases
whatever the linker decides to put next in the data section.
Drop the extern struct definition and change it to a simple void pointer,
which matches its definition in arch/x86/boot/x86_64.S
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andre Przywara
Juergen Gross
Yang Zhang
Jan Beulich
Ian Campbell
Joby Poriyath
Matthew Daley
Bob Proulx
Andrew Cooper
Julien Grall
Bastian Blank
Tim Deegan