- 08 Jan, 2020 1 commit
-
-
Hans van Kranenburg authored
-
- 07 Jan, 2020 39 commits
-
-
Hans van Kranenburg authored
They weren't available at the time of writing. Let's add them for the sake of completeness.
-
Hans van Kranenburg authored
[git-debrebase make-patches: export and commit patches]
-
Hans van Kranenburg authored
[git-debrebase pseudomerge: quick]
-
Hans van Kranenburg authored
We have the `xen` alias for xl in Debian, since in the past it was a command that could execute either xl or xm. Now, it always does xl, so, complete the same stuff for it as we have for xl. Signed-off-by:Hans van Kranenburg <hans@knorrie.org> [git-debrebase split: mixed commit: upstream part]
-
If LIBEXEC_LIB is not on the default linker search path, the python fsimage.so module fails to find libfsimage.so. Add the relevant directory to the rpath explicitly. (This situation occurs in the Debian package, where --with-libexec-libdir is used to put each Xen version's libraries and utilities in their own directory, to allow them to be coinstalled.) Signed-off-by:
Ian Jackson <ian.jackson@citrix.com> -
We install libfsimage in a non-standard path for Reasons. (See debian/rules.) This patch was originally part of `tools-pygrub-prefix.diff' (eg commit 51657319 ) and included changes to the Makefile to change the installation arrangements (we do that part in the rules now since that is a lot less prone to conflicts when we update) and to shared library rpath (which is now done in a separate patch). (Commit message rewritten by Ian Jackson.) Signed-off-by:
Ian Jackson <ian.jackson@citrix.com>
squash! pygrub: Set sys.path and rpath -
This is in the upstream script because on non-Debian systems, the default install locations in /usr/local/lib might not be on the linker path, and as a result the hotplug scripts would break. A reason we might need it in Debian is our multiple version coinstallation scheme. However, the hotplug scripts all call the utilities via the wrappers, and the binaries are configured to load from the right place anyway. This setting is an annoyance because it requires libdir, which is an arch-specific path but comes from a file we want to put in xen-utils-common, an arch:all package. So drop this setting. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Hans van Kranenburg authored
Strip all options that are for stuff we don't ship, which is 1) xenstored as stubdom and 2) xenbackendd, which seems to be dead code anyway. [1] It seems useful to give the user the option to revert to xenstored instead of the default oxenstored if they really want. [1] https://lists.xen.org/archives/html/xen-devel/2015-07/msg04427.html Signed-off-by:
Ian Jackson <ijackson@chiark.greenend.org.uk> -
Hans van Kranenburg authored
Also see Debian bug #894013. The current attempt at providing anti-spoofing rules results in a situation that does not have any effect. Also note that forwarding bridged traffic to iptables is not enabled by default, and that for openvswitch users it does not make any sense. So, stop cluttering the live iptables ruleset. This functionality seems to be introduced before 2004 and since then it has never got some additional love. It would be nice to have a proper discussion upstream about how Xen could provide some anti mac/ip spoofing in the dom0. It does not seem to be a trivial thing to do, since it requires having quite some knowledge about what the domU is allowed to do or not (e.g. a domU can be a router...).
-
Hans van Kranenburg authored
Instead of: (XEN) Xen version 4.11.1 (Debian ) (@) (gcc (Debian 8.2.0-13) 8.2.0) debug=n Thu Jan 3 19:08:37 UTC 2019 I'd like to see: (XEN) Xen version 4.11.1 (Debian 4.11.1-1~) (pkg-xen-devel@lists.alioth.debian.org) (gcc (Debian 8.2.0-13) 8.2.0) debug=n Thu Jan 3 22:44:00 CET 2019 The substitution was broken since the great packaging refactoring, because the directory in which the build is done changed. Also, use the Maintainer address from debian/control instead of the most recent changelog entry. If someone wants to use the address to ask a question, they will end up at the team mailing list, which is better than an individual person. -
Following recent discussion in pkg-xen-devel and xen-devel, https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg00838.html I am dropping this patch. For now I revert it. When we next debrebase, we can (if we like) throw away both the original patch, and this revert. This reverts commit 5047884c . Signed-off-by:
Ian Jackson <ian.jackson@citrix.com> -
This manpage was omitted from docs/man: Provide properly-formatted NAME sections because I was previously building with markdown not installed. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Previously this was *dis*abled for x86_*32*. But if someone should run some of this Makefile on ARM, say, it ought not to be built either. Signed-off-by:Ian Jackson <ijackson@chiark.greenend.org.uk> -
When building on a 32-bit userland, the user wants to build 32-bit tools and a 64-bit hypervisor. This involves setting XEN_TARGET_ARCH to different values for the tools build and the hypervisor build. So the user must invoke the tools build and the hypervisor build separately. However, although the shim is done by the tools/firmware Makefile, its bitness needs to be the same as the hypervisor, not the same as the tools. When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is wrong. So the user must invoke the shim build separately. This can be done with make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64 However, tools/firmware/xen-dir has no `install' target. The installation of all `firmware' is done in tools/firmware/Makefile. It might be possible to fix this, but it is not trivial. For example, the definitions of INST_DIR and DEBG_DIR would need to be copied, as would an appropriate $(INSTALL_DIR) call. For now, provide an `install-shim' target in tools/firmware/Makefile. This has to be called from `install' of course. We can't make it a dependency of `install' because it might be run before `all' has completed. We could make it depend on a `shim' target but such a target is nearly impossible to write because everything is done by the inflexible subdir-$@ machinery. The overally result of this patch is that existing make invocations work as before. But additionally, the user can say make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64 to install the shim. The user must have built it already. Unlike the build rune, this install-rune is properly conditional so it is OK to call on ARM. What a mess. Signed-off-by:Ian Jackson <ijackson@chiark.greenend.org.uk> -
This makes it easier to disable the shim build. (In Debian we need to build the shim separately because it needs different compiler flags and a different XEN_COMPILE_ARCH. Signed-off-by:Ian Jackson <ijackson@chiark.greenend.org.uk> -
Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
This is going to be used to put libfsimage.so into a path containing the multiarch triplet. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Patch-Name: tools-libfsimage-prefix.diff Gbp-Pq: Topic prefix-abiname Gbp-Pq: Name tools-libfsimage-prefix.diff
-
Patch-Name: tools-libfsimage-abiname.diff Gbp-Pq: Topic prefix-abiname Gbp-Pq: Name tools-libfsimage-abiname.diff
-
Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
The current build fails with GCC6 on Debian sid i386 (unstable): /tmp/ccqjaueF.s: Assembler messages: /tmp/ccqjaueF.s:3713: Error: missing or invalid displacement expression `vmovd_to_reg_len@GOT' This is due to the combination of GCC6, and Debian's decision to enable some hardening flags by default (to try to make runtime addresses less predictable): https://wiki.debian.org/Hardening/PIEByDefaultTransition This is of no benefit for the x86 instruction emulator test, which is a rebuild of the emulator code for testing purposes only. So pass options to disable this. These options will be no-ops if they are the same as the compiler default. On amd64, the -fno-pic breaks the build in a different way. So do this only on i386. Signed-off-by:
Ian Jackson <ian.jackson@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Topic misc
Gbp-Pq: Name toolstestsx86_emulator-pass--no-pie--fno.patch -
Patch-Name: tools-pygrub-remove-static-solaris-support Gbp-Pq: Topic misc Gbp-Pq: Name tools-pygrub-remove-static-solaris-support
-
Patch-Name: tools-xenmon-install.diff Gbp-Pq: Topic misc Gbp-Pq: Name tools-xenmon-install.diff
-
This is not wanted in Debian. COPYING ends up in /usr/share/doc/xen-*copyright. Patch-Name: tools-include-no-COPYING.diff Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Patch-Name: config-prefix.diff Gbp-Pq: Topic prefix-abiname Gbp-Pq: Name config-prefix.diff
-
Patch-Name: version.diff Gbp-Pq: Topic misc Gbp-Pq: Name version.diff
-
gcc-8 complains: kdd.c:698:13: error: 'memcpy' offset [-204, -717] is out of the bounds [0, 216] of object 'ctrl' with type 'kdd_ctrl' {aka 'union <anonymous>'} [-Werror=array-bounds] memcpy(buf, ((uint8_t *)&ctrl.c32) + offset, len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ kdd.c: In function 'kdd_select_callback': kdd.c:642:14: note: 'ctrl' declared here kdd_ctrl ctrl; ^~~~ But this is impossible - 'offset' is unsigned and correctly validated few lines before. Signed-off-by:Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Acked-by:
Wei Liu <wei.liu2@citrix.com> Release-Acked-by:
Juergen Gross <jgross@suse.com> (cherry picked from commit 437e00fe)
-
Add zero-padding to #defined ACPI table strings that are copied. Provides sufficient characters to satisfy the length required to fully populate the destination and prevent array-bounds warnings. Add BUILD_BUG_ON sizeof checks for compile-time length checking. Signed-off-by:
Christopher Clark <christopher.clark6@baesystems.com> Reviewed-by:
Stefano Stabellini <sstabellini@kernel.org> Acked-by:
-
xen-tools/libs.h currently contains a shared BUILD_BUG_ON() implementation and is used by some tools. Extend this to include ARRAY_SIZE and clean up all the opencoding. Signed-off-by:
Andrew Cooper <andrew.cooper3@citrix.com> Acked-by:
Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com> (cherry picked from commit e1b7eb92)
-
32 bit gcc 8.1 non-debug build yields: xenpmd.c:354:23: error: '%02x' directive output may be truncated writing between 2 and 8 bytes into a region of size 3 [-Werror=format-truncation=] snprintf(val, 3, "%02x", ^~~~ xenpmd.c:354:22: note: directive argument in the range [40, 2147483778] snprintf(val, 3, "%02x", ^~~~~~ xenpmd.c:354:5: note: 'snprintf' output between 3 and 9 bytes into a destination of size 3 snprintf(val, 3, "%02x", ^~~~~~~~~~~~~~~~~~~~~~~~ (unsigned int)(9*4 + ~~~~~~~~~~~~~~~~~~~~ strlen(info->model_number) + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ strlen(info->serial_number) + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ strlen(info->battery_type) + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ strlen(info->oem_info) + 4)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All info->* used in calculation are 32 bytes long, and the parsing code makes sure they are null-terminated, so the end result of the expression won't exceed 255, which should be able to be fit into 3 bytes in hexadecimal format. Add an assertion to make gcc happy. Signed-off-by:Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit e75c9dc8) -
These autogenerated files are not useful in Debian; dh_autoreconf will regenerate them. If this patch does not apply when rebasing, you can simply delete the files again. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
dh_autoreconf will provide these back. If this patch does not apply when rebasing, you can simply delete the files again. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Patch-Name: tools-xenstore-compatibility.diff Gbp-Pq: Topic xenstore Gbp-Pq: Name tools-xenstore-compatibility.diff
-
Gbp-Pq: Topic xenstore Gbp-Pq: Name tools-fake-xs-restrict.patch
-
`kdd' is an unfortunate namespace landgrab. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Adding the implementation language as a suffix to a program name is poor practice. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
This seems to have been simply omitted. Obviously this is needed when building and not just when installing. Passing only when installing is ineffective. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Do not reset LDFLAGS to empty. Instead, append the fsimage-special LDFLAGS. Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
This command does the link, so it needs LDFLAGS. Signed-off-by:Ian Jackson <ian.jackson@citrix.com>
-
