GRUB usually always loads a whole disk track, even if that means going
beyond the end of the disk. We thus have to gracefully return an error,
instead of letting the blkfront go panic.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
typo in tools/configure.ac cause --enable-xenapi does not works
lead to variables XML2_CONFIG, CURL_CONFIG not set
Signed-off-by: Yixun Lan (dlan) <dennis.yxun@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The allocations for shared_irqs and pending_irqs are not checked and use
later. This may lead to a Xen segfault if the hypervisor run out of memory.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Fix compilation with clang 3.5:
/local/home/julien/works/arndale/xen/xen/include/asm/platforms/exynos5.h:1:9: error: '__ASM_ARM_PLATFORMS_EXYNOS5_H' is used as a header guard here, followed by #define of a different macro [-Werror,-Wheader-guard]
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/local/home/julien/works/arndale/xen/xen/include/asm/platforms/exynos5.h:2:9: note: '__ASM_ASM_PLATFORMS_EXYSNO5_H' is defined here; did you mean '__ASM_ARM_PLATFORMS_EXYNOS5_H'?
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__ASM_ARM_PLATFORMS_EXYNOS5_H
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On FreeBSD PTHREAD_STACK_MIN is 2048 by default, which is obviously
too low. Set the default back to the previous value (16 * 1024), or if
that's too low set it to PTHREAD_STACK_MIN.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@citrix.com>
nr_static_irqs and nr_irqs is defined in asm/irq.h (on both x86 and ARM).
Include directly the header in hooks.c to avoid compilation failure on ARM.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Rather than x86, on ARM XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are
not compatible. This will result to a compilation failure on ARM when XSM
will be enabled.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On ARM, the compilation is failing with the following error:
In file included from flask_op.c:21:0:
./include/conditional.h:24:43: error: two or more data types in declaration specifiers
./include/conditional.h:25:42: error: two or more data types in declaration specifiers
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The commit f7d29f7b "flask: add compat mode guest support" introduces
build breakage on ARM when XSM is enabled. It's because ARM doesn't use
compat mode.
flask_op.c:794:34: fatal error: compat/event_channel.h: No such file or directory
#include <compat/event_channel.h>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When the the module size is 0, it means that the module was not provided by
the user. It can happen, if the user choose to boot without initrd.
In this case, both fields (start and size) are zeroed. Therefore, next_module
will return 0 every time if there is other non-zero module after this one. This
can happen when the XSM module is added.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Flask code use %zu to print size_t variable. On ARM, size_t always defined
to unsigned long which make ARM build failed.
Fix it by using __SIZE_TYPE__.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
copy_from_paddr is only used with BUFFERABLE, there is some place where
DEV_SHARED was used by mistake.
The parameter "attrindx" can be safely remove and let copy_from_paddr to map
every page with BUFFERABLE attribute.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Xen is loaded either by U-boot or the bootwrapper. Both of them
correctly set xen multiboot module for the kernel in the device tree.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Compute a -v option to pass to the migration receiver.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
v2: Use minmsglevel_default to initialise minmsglevel.
If we ourselves are using cr-based overwriting for logging to stderr,
pass -t to the migration receiver so that it knows to do the same
(since its stderr is normally the pipe from sshd).
This requires, of course, that the receiver support that option. This
is OK from a compatibility point of view because we support migration
to newer, but not necessarily to older, versions. (If unsupported
backwards migration is still desired the use of -s "" allows the
remote invocation rune to be overridden by a command of one's choice.)
This fixes a regression introduced in 2f80ac9c0e, where migration
messages from the receiver would not use of the overwriting protocol.
CC: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Provide flags
XTL_STDIOSTREAM_PROGRESS_USE_CR
XTL_STDIOSTREAM_PROGRESS_NO_CR
to allow the caller to force, or disable, the use of \r-based
overwriting of progress messages.
In the implementation, rename the variable "tty" to "progress_use_cr".
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Plumb hotplug scripts' stdout to stderr. That way if they print
anything (which really they shouldn't), it won't get mixed up with
the application's stdout. (Eg, perhaps with an xl migration
stream...)
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Vasiliy Tolstov <v.tolstov@selfip.ru>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Since 28d386fc43 (XSA-57), libxl writes an empty value for the
console tty node, with read-only permission for the guest, when
setting up pv console "frontends". (The actual tty value is later set
by xenconsoled.) Writing an empty node is not strictly necessary to
stop the frontend from writing dangerous values here, but it is a good
belt-and-braces approach.
Unfortunately this confuses xenconsole. It reads the empty value, and
tries to open it as the tty. xenconsole then exits.
Fix this by having xenconsole treat an empty value the same way as no
value at all.
Also, make the error opening the tty be nonfatal: we just print a
warning, but do not exit. I think this is helpful in theoretical
situations where xenconsole is racing with libxl and/or xenconsoled.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: George Dunlap <george.dunlap@eu.citrix.com>
---
v2: Combine two conditions and move the free
If xenconsole (the client program) fails, it calls err. This would
previously neglect to reset the user's terminal to sanity. Use atexit
to do so.
This routinely happens in Xen 4.4 RC5 with pygrub because libxl
writes the value "" to the tty xenstore key when using xenconsole.
After this patch this just results in a harmless error message.
Reported-by: M A Young <m.a.young@durham.ac.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: M A Young <m.a.young@durham.ac.uk>
CC: Ian Campbell <Ian.Campbell@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Fix whitespace error (reintroduce hard tab)
Fix commit message not to claim ignorance about root cause
The if in domain.c was only syntactically valid because the macro happened to
contain enclosing braces.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Xen on ARM guests are neither PV nor HVM, they are just "guests". Avoid the
incorrect use of the term pv in the guest type macros.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
The comment was previously incorrect and indicated that these mappings were
unshared (00) when in reality the register was set for outer-shareable (01).
Clarify ORGN0/IRGN0 in the comments while at it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Note that 32-bit does not provide a load variant of the inner shareable
barrier, so that remains a full any-any barrier.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Since all processors are in the inner-shareable domain and we map everything
that way this is sufficient.
The non-SMP barriers remain full system. Although in principle they could
become outer shareable barriers for some hardware this would require us to
know which class a given device is. Given the small number of device drivers
in Xen itself its probably not worth worrying over, although maybe someone
will benchmark at some point.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
The full power of dsb is not required in this context.
Also change wmb() to be dsb() directly instead of indirectly via mb(), for
clarity.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
SMP barriers can be used when all we care about is synchronising against other
processors.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
These are effectively identical on both 32- and 64-bit.
The only difference is that they implicit "sy" on 32-bit becomes explicit.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
The inner shareable domain contains all SMP processors, including different
clusters (e.g. big.LITTLE). Therefore this is the correct thing to use for Xen
memory mappings. The outer shareable domain is for devices on busses which are
coherent and barrier-aware (e.g. AMBA4 AXI with ACE). While the system domain
is for things behind bridges which are not.
One wrinkle is that Normal memory with attributes Inner Non-cacheable, Outer
Non-cacheable (which we call BUFFERABLE) must be mapped Outer Shareable on ARM
v7. Therefore change the prototype of mfn_to_xen_entry to take the attribute
index so we can DTRT. On ARMv8 the sharability is ignored and considered to
always be Outer Shareable.
Don't adjust the barriers, flushes etc, those remain as they were (which is
more than is now required). I'll change those in a later patch.
Many thanks to Leif for explaining the difference between Inner- and
Outer-Shareable in words of two or less syllables, I hope I've replicated that
explanation properly above!
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Declaring a formal parameter to have an array type doesn't result in
the parameter actually having an array type. The type is "adjusted"
to a pointer. (C99 6.9.1(7), 6.7.5.3.)
So the use of sizeof in xc_suspend.c:get_suspend_file was wrong.
Instead, use the #define. Also get rid of the array size, as it is
misleading.
Newer versions of gcc warn about the erroneous code:
xc_suspend.c:39:25: error: argument to 'sizeof' in 'snprintf' call
is the same expression as the destination; did you mean to provide
an explicit length? [-Werror=sizeof-pointer-memaccess]
Reported-By: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Julien Grall <julien.grall@linaro.org>
--
v2: Actually change the declaration of buf.
With the number of these growing it becomes increasingly desirable to
not repeatedly alter the sysctl interface to accommodate them. Replace
the explicit listing of numbered states by arrays, unused fields of
which will remain untouched by the hypercall.
The adjusted sysctl interface at once fixes an unrelated shortcoming
of the original one: The "nr" field, specifying the size of the
"triggers" and "residencies" arrays, has to be an input (along with
being an output), which the previous implementation didn't obey to.
Note that the bouncing direction in the libxc interface at once gets
corrected to OUT (was BOTH).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
When negotiating guest suspend via the evtchn ("fast") protocol,
the guest may still fail to respond.
So set the timeout. The existing error path will already properly
tear down our (event channel) wait.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When negotiating guest suspend via the evtchn ("fast") protocol,
abolish synchronous wait for domain suspend.
If the guest supports the event channel suspend protocol, we used to
sit in a loop in xc_await_suspend waiting (perhaps indefinitely) for
it to suspend.
Instead, use the new libxl event channel event facility. When we see
that the event is signaled, we look at the domain to see if it has
suspended. (In this patch we do not yet set a timeout; that will come
next.)
So the suspend operation no longer blocks with the libxl ctx lock
held, and instead returns to the event loop. Additionally, domains
which signal the event channel themselves, or undergo other state
changes, will be handled more correctly.
We end up making a few more hypercalls.
Also, if we encounter errors setting up the suspend event channel
(which should not happen), abort the operation rather than falling
back to the xenstore protocol.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Improve commit message.
When we are waiting for a guest to suspend, this suspend operation
would continue to wait (until the timeout) if the guest was destroyed
or shut down for another reason, or if xc_domain_getinfolist failed.
Handle these cases correctly, as errors.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Remove unwanted error call after a new "goto err".
Replace the use of a loop with usleep().
Instead, use a xenstore watch and an event system timeout. (xenstore
fires watches on @releaseDomain when a domain shuts down.)
The logic which checks for the state of the domain is unchanged, and
not ideal, but we will leave that for the next patch.
There is not intended to be any semantic change, other than to make
the algorithm properly asynchronous and the consequential waiting be
on xenstore, rather than polling.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Remove some trailing whitespace
Improve commit message.
v3X: Do NOT use an xswait instead of separate watch and timeout.
When negotiating guest suspend via the xenstore pvcontrol protocol
(ie when the guest does NOT support the evtchn fast suspend protocol):
Replace the use of loops and usleep with a call to libxl__xswait.
Also, replace the xenstore transaction loop with one using
libxl__xs_transaction_start et al.
There is not intended to be any semantic change, other than to make
the algorithm properly asynchronous.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Add a comment to clarify last minute ack.
v3X: Do NOT rename "pvcontrol" xswait state struct to "guest_wait"
(because we're NOT going to use it for the event channel based wait
too).