The reasoning behind this patch is that ctrl->event_port is a uint32_t
(ie. unsigned), so the current checks on it for negative error results,
non-negative port presence etc. are incorrect.
Fix by using evtchn_port_or_error_t in the init functions instead,
adjusting the error handling, and removing the now-unnecessary check
from the close function.
Coverity-ID: 1055609
Coverity-ID: 1055610
Coverity-ID: 1055611
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Reviewed-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
While at it, correct the error handling of libxl__fill_dom0_memory_info;
at that point there is no transaction to end in any manner.
Coverity-ID: 1055046
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
We don't check for null pointers in similar functions, and it's silly to
do so for these arguments here anyway; they should fail noisily if null
is passed.
While at it, remove pointless brackets.
Coverity-ID: 1055938
Coverity-ID: 1055939
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libvchan's init_xs_srv (server-side xenstore-related initialization)
expects to find the current domain's domid at this xenstore key. libxl
(and xend) write this for domains they create. Do the same for domain 0,
allowing the use of libvchan in dom0.
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently Xen hvm s3 has a bug coming from the difference between
qemu-traditional and qemu-xen. For qemu-traditional, the way to
resume from hvm s3 is via 'xl trigger' command. However, for
qemu-xen, the way to resume from hvm s3 inherited from standard
qemu, i.e. via QMP, and it doesn't work under Xen.
The root cause is, for qemu-xen, 'xl trigger' command didn't reset
devices, while QMP didn't unpause hvm domain though they did qemu
system reset.
We have two qemu patches one xl patch to fix the HVM S3 bug:
This patch is the xl patch. It invokes QMP system_wakeup so that
qemu logic for hvm s3 could be triggered.
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Patch generated by the following semantic patch
(http://coccinelle.lip6.fr/):
@@
expression *P;
@@
- if(P) free(P);
+ free(P);
...and then by filtering through the following command:
filterdiff -p1 -x 'stubdom/*' -x 'tools/firmware/*' -x 'tools/qemu-*' -x 'tools/blktap*'
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This is useful when the key enum has an "invalid" option and avoids
the need to declare a dummy struct. Use this for domain_build_info
resulting in the generated API changing like so:
--- tools/libxl/_libxl_BACKUP_types.h
+++ tools/libxl/_libxl_types.h
@@ -377,8 +377,6 @@ typedef struct libxl_domain_build_info {
const char * features;
libxl_defbool e820_host;
} pv;
- struct {
- } invalid;
} u;
} libxl_domain_build_info;
void libxl_domain_build_info_dispose(libxl_domain_build_info *p);
+ a related change to the JSON generation.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This fixes the issue for both C and ocaml xenstored, however only the ocaml
xenstored is vulnerable in its default configuration.
Adding a new error appears to be safe, since bit libxenstore and the Linux
driver at least treat an unknown error code as EINVAL.
This is XSA-72 / CVE-2013-4416.
Original ocaml patch by Jerome Maloberti <jerome.maloberti@citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
So commit eedd6039 ("scheduler: adjust internal locking interface")
uncovered - by now using proper spin lock constructs - a bug after all:
When bringing down a CPU, cpu_disable_scheduler() gets called with
interrupts disabled, and hence the use of vcpu_schedule_lock_irq() was
never really correct (i.e. the caller ended up with interrupts enabled
despite having disabled them explicitly).
Fixing this however surfaced another problem: The call path
vcpu_migrate() -> evtchn_move_pirqs() wants to acquire the event lock,
which however is a non-IRQ-safe once, and hence check_lock() doesn't
like this lock to be acquired when interrupts are already off. As we're
in stop-machine context here, getting things wrong wrt interrupt state
management during lock acquire/release is out of question though, so
the simple solution to this appears to be to just suppress spin lock
debugging for the period of time while the stop machine callback gets
run.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
With the feature of unrestricted guest, Xen should not cause
vmexits for cr3 accesses in non-paging mode.
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
After creating a domain, xl forks off a process to handle domain events
(shutdown, disk eject, ...). It prints out the pid of the process
created by the fork to stdout. However, the newly forked process soon
after calls daemon(), which itself forks once more (and exit()s the
original process). This means that the pid printed out is not the pid of
the actual process which remains in the background after all is said and
done, instead it is the pid of the transient process that exists between
xl's fork() and the fork'd process's daemon() call.
We could resolve this by printing the correct pid, ie. by open-coding
daemon() (we already do most of the heavy lifting it does ourselves by
fiddling with the standard fds). However, since no-one seems to be
complaining about the misleading message to begin with, and since it
seems like a pointless message anyway, just remove it outright instead.
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
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>
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>
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>
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>
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>
~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>
{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>
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>
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>
This is incorrect after commit 1aac966e24 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>
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>
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>
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>
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>
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>
Because of the construction of spin_lock_irq() (and varients), the flags
parameter could be trucated. Use a BUILD_BUG_ON() to verify the width of the
parameter.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>