Running "make uninstall" does not remove all installed files, a
situation which might cause link related issues if xen is re-installed
in a different location.
In order to make uninstall correctly remove the files it is best
the process should be done recursively by mirroring each "install"
target with an "uninstall" who removes the installed files.
An exception to this rule is uninstalling the files produced by
"qemu-xen-dir-remote" and "qemu-xen-traditional-dir", which are external
to the project. These projects do not implement an "uninstall" target so
the files have to be removed manually.
Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
That header file is not used. Removing it would avoid build error with
musl libc, which doesn't have that header file.
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
[ wei: rewrote commit message ]
Acked-by: Wei Liu <wei.liu2@citrix.com>
Gcc complains:
qcow2raw.c: In function ‘main’:
qcow2raw.c:387:17: error: ‘buf’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
treq.buf = buf;
^
But buf is a valid buffer allocated by posix_memalign at that point.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Gcc complains:
qcow2raw.c: In function ‘main’:
qcow2raw.c:387:17: error: ‘buf’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
treq.buf = buf;
^
But at the point of that assignment, buf is a valid buffer allocated by
posix_memalign and filled in by read.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Clang points out:
tapdisk-disktype.c:117:2: error: initializer overrides prior initialization
of this subobject [-Werror,-Winitializer-overrides]
0,
^
tapdisk-disktype.c:115:23: note: previous initialization is here
[DISK_TYPE_VINDEX] = &vhd_index_disk,
^~~~~~~~~~~~~~~
Mixing different initialiser styles should be avoided; The actual behaviour is
different to the expected behaviour. This specific example has been broken
since its introduction in c/s 7b4dea554 "blktap2: Fix tapdisk disktype issues"
in 2010, and is caused by the '#if 0' block removing &tapdisk_{sync,vmdk}.
First of all, remove what were intended to be trailing NULL entries in
tapdisk_disk_{types,drivers}[], making consistent use of Designated
Initialisers for the initialisation.
This requires changing the loop in tapdisk_disktype_find() to be based on the
number of elements in tapdisk_disk_types[], rather than looking for the first
NULL. This fixes a latent bug, as the use of Designated Initializers causes
to intermediate zero entries if not all indices are explicitly specified.
There is a second latent bug where tapdisk_disktype_find() assumes that
tapdisk_disk_drivers[] has at least as many entries as tapdisk_disk_types[].
This is not the case and tapdisk_disk_drivers[] had one entry fewer than
tapdisk_disk_types[], but the NULL loop bound prevented an out-of-bounds read
of tapdisk_disk_drivers[]. Fix the issue by explicitly declaring
tapdisk_disk_drivers[] to have the same number of entries as
tapdisk_disk_types[].
Finally, this leads to a linker error. It turns out that tapdisk_vhd_index
doesn't exist, and I can't find any evidence in the source history to suggest
that it ever did. I can only presume that it would have been #if 0'd out like
tapdisk_sync and tapdisk_vmdk had it not been for this bug preventing a build
failure. Drop all three.
No functional change, but only because of the specific layout of
tapdisk_disk_types[].
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Instead of trying to write a snippet of code that crashes the process
just use abort() directly. This is to fix the build on clang which
detects that the snippet of code will crash and fails to compile. At
the same time removed extraneous whitespace in the macro.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
At least gcc-4.8 and older fails to recognize that err is always
initialized, the build fails:
xc_cpupool.c: In function 'xc_cpupool_removecpu':
xc_cpupool.c:168:5: error: 'err' may be used uninitialized in this function [-Werror=maybe-uninitialized]
return err;
Fix this in blktap2 and libxc.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Instead of RING_GET_REQUEST. Using a local copy of the
ring (and also with proper memory barriers) will mean
we can do not have to worry about the compiler optimizing
the code and doing a double-fetch in the shared memory space.
This is part of XSA155.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
As recommended in http://www.gnu.org/licenses/gpl-howto.en.html.
This is the result of:
$ git grep -El Mass\|Temple\|Franklin | xargs ./fsf.pl
Where fsf.pl is:
#!/usr/bin/perl -w -pi.bak -0777
my $repl = 'If not, see <http://www.gnu.org/licenses/>.';
my $br = qr/(?:\s*\n\s*(?:[\*\#]|\/\/|\.\\" )?\s*|\s+)/;
my $inwt = qr/[Ii]f${br}not,${br}write${br}(?:to${br})?the${br}Free${br}Software${br}Foundation,(?:${br}Inc\.,)?/;
my $mass = qr/675${br}Mass${br}Ave,?${br}Cambridge,?${br}MA${br}02139,?${br}USA,?\.?/;
my $franklin = qr/51${br}Franklin${br}St(?:reet)?(?:,${br}| - )Fifth${br}Floor,?${br}Boston,?${br}MA,?${br}02110-1301,?${br}USA,?\.?/;
my $temple = qr/59${br}Temple${br}Place(?:,${br}| - )Suite${br}330,?${br}Boston,?${br}MA,?${br}021110?-1307,?${br}USA,?\.?/;
s|$inwt$br$mass|$repl|m;
s|$inwt$br$franklin|$repl|m;
s|$inwt$br$temple|$repl|m;
The only remaining mentions of these addresses are in COPYING files which I
haven't touched.
Some of the changed files are imports from elsewhere, however
filtering them out is tricky, I think it is tolerable to have these
files be modified here and then perhaps reverted on the next sync,
since it's only 1-2 lines and obvious what is going on.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
The 'private' field in io/ring.h (for blktap2, see 1b9cecdb)
is the last thing in the Xen public headers that a C++ compiler
will object to.
Rename it to pvt, update the only in-tree user, and remove the
workaround in the C++ compatibility check.
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The original rule to target "distclean" in tools/Rules.mk was in effect
"make clean". It should be "make distclean".
However not all Makefiles in subdirectories have distclean target
defined. So this patch also adds a bunch of distclean targets to various
Makefiles. They only depend on clean target and don't have any actions
in most cases.
With the patch applied, following command outputs 0 results:
find tools -name 'Makefile*' -exec grep -L 'distclean' {} \+ \
| grep -v ocaml | grep -v libfsimage
Ocaml and libfsimage are known to have distclean defined in a dedicated
rules file.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Also moves xc_dom.h to include as it is used often by other xen tools.
Use the new include subdirectories to build Xen tools, qemu-xen and
stubdoms.
Add the old libxc include path to the programs that need it to build,
on a case by case basis and commeting that they shouldn't require
internal libxc headers to build.
[ And: update QEMU_TRADITIONAL_REVISION to corresponding qemu patch
- Ian jackson ]
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
for which gcc 4.9.0 complains about, like this:
block-qcow.c: In function `get_cluster_offset':
block-qcow.c:431:3: error: `tmp_ptr' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
memcpy(tmp_ptr, l1_ptr, 4096);
^
block-qcow.c:606:7: error: `tmp_ptr2' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
if (write(s->fd, tmp_ptr2, 4096) != 4096) {
^
cc1: all warnings being treated as errors
/home/dario/Sources/xen/xen/xen.git/tools/blktap2/drivers/../../../tools/Rules.mk:89:
recipe for target 'block-qcow.o' failed
make[5]: *** [block-qcow.o] Error 1
The proper behavior is to return upon allocation failure.
About what to return, 0 seems the best option, looking
at both the function and the call sites.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.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>
arm64 only has the eventfd2 system call and using the libc wrapper when
available hides this from us. eventfd() has been in libc since glibc 2.8.
This code is already Linux specific.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
gcc 4.8 identifies several places where code of the form memset(x, 0,
sizeof(x)); is used incorrectly, meaning that less memory is set to
zero than required.
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Committed-by: Keir Fraser <keir@xen.org>
gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .block-remus.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-i386/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-i386/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -c -o block-remus.o block-remus.c
block-remus.c: In function 'ramdisk_flush':
block-remus.c:508: error: 'buf' may be used uninitialized in this function
make[5]: *** [block-remus.o] Error 1
This is because gcc can see that merge_requests doesn't always set
*mergedbuf but gcc isn't able to prove that it always does so if
merge_requests returns 0 and that in that case the value of
ramdisk_flush::buf isn't used.
This is too useful a warning to disable, despite the occasional false
positive of this form. The conventional approach is to suppress the
warning by explicitly initialising the variable to 0.
This has just come to light because 25275:27d63b9f111a reenabled
optimisation for this area of code, and gcc's data flow analysis
(which is required to trigger the uninitialised variable warning) only
occurs when optimisation is turned on.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
block-log.c: In function 'ctl_close_sock':
block-log.c:363:23: warning: array subscript is above array bounds
[-Warray-bounds]
Adjust loop condition in ctl_close_sock() to fix warning.
Adjust array acccess in ctl_close() to actually access the array
member.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
In blktap2 MEMSHR_DIR is used before it is set. This removes the
required -D_GNU_SOURCE from CFLAGS, its used as option for -I
Fix this by moving memshr related flags to the place where its actually
used.
The failure is a missing O_DIRECT define.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
This patch is the folded version of API updates, along with the associated tool
changes to ensure that the build is always consistent.
API updates:
- The source domain in the sharing calls is no longer assumed to be dom0.
- Previously, the mem sharing code would return an opaque handle to index
shared pages (and nominees) in its global hash table. By removing the hash
table, the handle becomes a version, to avoid sharing a stale version of a
page. Thus, libxc wrappers and tools need to be updated to recall the share
functions with the information needed to fetch the page (which they readily
have).
Tool updates:
The only (in-tree, that we know of) consumer of the mem sharing API is the
memshr tool. This is updated to use the new API.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Tim Deegan <tim@xen.org>
Use the same approach as tools/blktap2/include/libvhd.h, remove local
definitions of bswap* and include byteswap.h. Also remove the
HAVE_BYTESWAP_H ifdef, since it was not defined in this context (it's
defined by QEMU).
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This patch addresses some of the compile and link issues with the memshr
module.
Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
I could have sworn I did this years ago.
IIRC the need for our own copy was due to the use of io_set_eventfd which is
not present in version 0.3.106. However it is in 0.3.107 the first version of
which was uploaded to Debian in June 2008 (I can't find a better reference for
the release date).
The necessary version is available in Debian Lenny onwards and is in at least
RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
version.
This is based on tools-system-libaio.diff from the Debian packaging although I
have made it optional (but default on).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Bitmaps are used in save/restore, xenpaging and blktap2. Merge the code into a
private xc_bitops.h file. All users are single threaded, so locking is not an
issue. The array of bits is handled as volatile because the x86 save/restore
code passes the bitmap to the hypervisor which in turn modifies the bitmap.
blktap2 uses a private bitmap. There was a possible overflow in the
bitmap_size() function, the remainder was not considered.
ia64 save/restore uses a bitmap to send the number of vcpus to the host.
x86 save/restore uses a bitmap to track dirty pages. This bitmap is shared with
the hypervisor. An unused function count_bits() was removed and a new
bitmap_size() function is now used.
xenpaging uses 3 private bitmaps to track the gfns which are in paged-out
state. It had a copy of some Linux bitops.h, which is now obsolete. Also the
BITS_PER_LONG macro was hardcoded to 64 which made it impossible to run 32bit
tools on a 64bit host. Wether this works at all has to be tested, yet.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
At the end of a checkpoint, when a new flush (of buffered disk writes)
is merged with ongoing flush, we have to make sure that none of the new
disk I/O requests overlap with ones in in progress. If it does, hold the
request and dont issue I/O until the overlapping one finishes. If we allow
the I/O to proceed, we might end up with two overlapping requests in the
disk's queue and the disk may not offer any guarantee on which one is
written first.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
hashtable.c has already been copied, forked and modified, there
doesn't seem much point in avoiding the same for the header until
someone feels motivated to properly refactor.
Add comments to the various duplicated files cross-referencing each
other for future reference and as a barrier to forking again...
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
A fair few things under tools link against libraries which they don't
even use.
Most of this appears to come from copy-and-pasting previous Makefile
snippets and cargo-culting plus the tendency to define global $(LIBS)
even for Makefiles which build multiple separate utilities or
libraries.
Identified by comparing a build with --as-needed to one without by
looking at the NEEDED header of all ELF objects.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
In particular if binary A uses libB and libB uses libC entirely
internally then A does not need to link against libC only libB.
However when linking binary A the linker does need to have visibility
of the libraries which libB links against (libC in this example). For
out of tree uses this is achieved without fuss due because the
libraries are installed in a standard path. However in the case of
in-tree users the linker needs a hint in the form of the -rpath-link
option. Therefore a new class of build variable, $(SHLIB_FOO), is
introduced which includes the linker options needed to link against a
library which uses libFOO. The intention is that $(LDLIBS_bar) will
include the $(SHLIB_foo)s which it uses where necessary rather
requiring that users are aware of this.
For the python extensions this change appears particularly large since
previously each of python bindings were linked against the union of
all possible libraries used by all bindings instead of just what they
individually needed.
This change removes a dependency on libdl.so from nearly everything
in the system, only libxenctrl actually uses it.
In the context of xl/libxl the intention of libxl is to remove any
need for a user of libxl to know about libxenstore or libxenctrl,
however in the current build it is xl which links against those
libraries rather than libxl (which only links against libc). After
this change libxl correctly depends on the libraries it uses and xl
does not depend on libraries which it is not support to be required to
know about. Note that xl does depend on libxenctrl.so since it uses
xtl_* directly.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Otherwise make can search the path relative to certain standard paths
such as /usr/include (e.g., the line '-include $(XEN_ROOT)/.config' in
Config.mk suffers from this).
Signed-off-by: Keir Fraser <keir@xen.org>
Make the DISK_TYPE_* id numbering in tapdisk-disktypes.h contiguous.
Currently, id 8 is unallocated causing a null disk type entry in
tapdisk_disk_drivers array in tapdisk-disktypes.c. This causes the
function tapdisk_disktype_find() to return an error on encountering
disk types >7 (remus:, log:, etc.).
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Daniel Stodden <daniel.stodden@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Fix tapdisk-disktype.c's initialization for remus' disk_info_t,
which is currently initializing the disk name with disk description.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
The former is a userspace sanitised header which contains the
definitions we need. In some distros linux/fs.h defines WRITE which
conflicts with blktaps own use of that name.
Also there is no reason to use <linux/errno.h> over the more normal
<errno.h>.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>