- 23 Aug, 2022 35 commits
-
-
Hans van Kranenburg authored
[git-debrebase pseudomerge: stitch]
-
Hans van Kranenburg authored
[git-debrebase make-patches: export and commit patches]
-
Hans van Kranenburg authored
[The symptoms] When doing a Xen package build for Debian with ccache enabled, we started getting the following error: x86_64-linux-gnu-gcc [...] -o build.o /builds/xen-team/debian-xen/debian/output/source_dir/tools/libs/light/../../../tools/libacpi/build.c ccache: error: Failed to create temporary file for /run/user/0/ccache-tmp/tmp.cpp_stdout.bqxKOP: Permission denied It turns out to be the case that during the install step of tools (the install-tools that happens inside the override_dh_auto_install part of d/rules), the upstream build machinery *again* tries to build this build.c file, while this has already been done earlier during the actual build phase. Since the Debian build process stopped to allow usage of ccache during the install phase of the process, this issue surfaces. [The cause] In tools/libs/light/Makefile, we see the following lines: .PHONY: acpi acpi: $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) DSDT_FILES="$(DSDT_FILES-y)" [...] $(DSDT_FILES-y) build.o build.opic: acpi 'acpi' is defined as phony target. In the last line, we see that build.o depdends on acpi. Also see: "4.6 Phony Targets" https://www.gnu.org/software/make/manual/make.html#Phony-Targets A 'normal' target gives make the possibility to track timestamps of a target file. E.g. compiling foo.c results in foo.o, and as long as foo.c keeps being 'older' than foo.o, make will think "nothing to do here, foo.o is up to date, let's move along". Now, a phony target is some kind of fake target that does not come with this kind of information, and such behaves like a target that is always out-of-date. Hence, with a configuration as seen above, it will try to always unneededly build this build.o and build.opic again. [Discussion] Upstream commit e006b2e3 ("libxl: fix libacpi dependency") which introduced the problem tells us that the purpose of the current configuration is to make sure the libacpi/ dir is built before we attempt to work on build.c in here. The changes in there remove an apparently obsolete line referencing build.o from the libacpi Makefile, which might mean that in the past this build.* stuff was located in that part of the code, and was moved into libs/light later. [The fix] If it is enough to just have an order-only dependency, we can use an order-only prerequisite instead, in this place: $(DSDT_FILES-y): acpi build.o build.opic: | acpi Also see: "4.3 Types of Prerequisites" https://www.gnu.org/software/make/manual/make.html#Prerequisite-Types Now the build machinery will not attempt to unconditionally rebuild build.o during make install. [Suggestions for further work] As can be seen, there's still the $(DSDT_FILES-y) which has the same acpi dependency and which may lead to similar unwanted side effects. However, since none of the files in that list have a corresponding build target in *this* Makefile, it does not trigger the problem for us, and we leave it alone, for now. Suggested-by:Michael Tokarev <mjt@tls.msk.ru> Signed-off-by:
Hans van Kranenburg <hans@knorrie.org> Fixes: e006b2e3 ("libxl: fix libacpi dependency")
-
There's no sense to switch to qemu-xen-traditional device model if that one is not enabled in the first place. This way we'll have a chance later to print a message suggesting to install the missing qemu package if we *actually* need qemu for the device model.
-
The objdump output is fed to grep, so make sure it doesn't change with different user locales and break the grep parsing. This problem was identified while updating xen in Debian and the fix is needed for generating reproducible builds in varying environments. Signed-off-by:
Maximilian Engelhardt <maxi@daemonizer.de> -
Use the solution described in [1] to replace the call to the 'date' command with a version that uses SOURCE_DATE_EPOCH if available. This is needed for reproducible builds. [1] https://reproducible-builds.org/docs/source-date-epoch/ Signed-off-by:
Maximilian Engelhardt <maxi@daemonizer.de>
[Hans van Kranenburg]
Note: this patch is submitted upstream but not committed yet. We
expect that it gets in. Otherwise, we don't wait and already have it
here because I want to have the reproducible build work completed. -
Hans van Kranenburg authored
This is something that hasn't been touched (except for making it Python 3 compatible, which failed) since 2007. Don't build or ship it. -# xenmon File "/usr/sbin/xenmon", line 680 stop_cmd = "/usr/bin/pkill -INT -z global xenbaked" TabError: inconsistent use of tabs and spaces in indentation Signed-off-by: -
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: -
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) the new options for oom score and open file descriptor limit, which would not have any effect, because we're shipping different init scripts... :| It seems useful to give the user the option to revert to xenstored instead of the default oxenstored if they really want. 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...). Signed-off-by: -
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> -
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). Signed-off-by:
Ian Jackson <ijackson@chiark.greenend.org.uk>
[ Hans: adjust from tools/firmware/Makefile to config/Tools.mk.in to
follow changes that happened in 8845155c
("pvshim: make PV shim build
selectable from configure") ]
Signed-off-by: -
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> -
Hans van Kranenburg authored
\o/
-
Signed-off-by:Ian Jackson <ian.jackson@citrix.com> -
Patch-Name: tools-pygrub-remove-static-solaris-support Gbp-Pq: Topic misc Gbp-Pq: Name tools-pygrub-remove-static-solaris-support
-
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
-
During hypervisor boot, disable the banner and nicely display the xen version as well as the Maintainer address from debian/control. For this to work the SOURCE_BASE_DIR variable needs to be set by the build system to the top directory, i.e. where the debian folder is. Original patch by Bastian Blank <waldi@debian.org> Modified by Hans van Kranenburg <hans@knorrie.org> Maximilian Engelhardt <maxi@daemonizer.de>
-
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> -
Hans van Kranenburg authored
-
Hans van Kranenburg authored
The message output of lintian is changing, and the override lines are meant to match those messages to silence them. THEN: statically-linked-binary usr/lib/xen-4.16/boot/xen-shim NOW: statically-linked-binary [usr/lib/xen-4.16/boot/xen-shim] Also see: https://bugs.debian.org/1007002 So, the goal while writing these overrides is not to be as specific as possible, it's better to be more generic and aim for the lowest chance to accidentally match (hide) another problem. For example, for the no-symbols-control-file one in libxenmisc it's the case for ALL of the so files in the package, so there's not really a need to put more effort in matching them specifically. For others, we mostly can just put a * before and after the file names, so that this will work with old and new lintian versions. For binary-has-unneeded-section and spelling-error-in-binary, it seems the order of stuff on the line has changed (filename is now in brackets and is moved to the beginning of the line), so for them just also use only the file name with some added *'s... O_o
-
Hans van Kranenburg authored
This would hit for i386 because it would have amd64 binary stuff inside the packages. Now that we don't ship anything for i386 any more, this override is also obsolete. I: xen-utils-4.16: unused-override binary-from-other-architecture usr/lib/debug/xen-syms-4.16-shim/xen-shim-syms [usr/share/lintian/overrides/xen-utils-4.16:9] -
Hans van Kranenburg authored
While the description still contains a link and the text 'more information', apparently this one does not hit anymore, as lintian is telling us: I: xenstore-utils: unused-override description-possibly-contains-homepage https://wiki.xen.org/wiki/XenStore [usr/share/lintian/overrides/xenstore-utils:4] -
Hans van Kranenburg authored
Apparently this check is now gone. What remains is an informational message that says the override is now unused: I: xen-utils-4.16: unused-override binary-or-shlib-defines-rpath usr/lib/xen-4.16/lib/python/xenfsimage.*.so /usr/lib/xen-4.16/lib/x86_64-linux-gnu [usr/share/lintian/overrides/xen-utils-4.16:12] -
Hans van Kranenburg authored
The Lintian documentation tells us to put documentation for overrides above the override line itself. https://lintian.debian.org/manual/index.html#documenting-overrides
-
Hans van Kranenburg authored
John E. Krokes noticed that the grub configuration fragment that we ship outputs text to stdout, which means it will end up being part of the generated grub configuration. This is wrong, and leads to error messages during boot like "error: can't find command `Including'."... Instead, output informational messages about progress to stderr (exactly like what happens with other messages such as "Generating grub configuration file ..." or "Found linux image: /boot/vmlinuz-[...]"). For the more prominent message about changing GRUB_DEFAULT as a side effect, use the grub_warn helper instead. (Closes: #1016547)
-
Hans van Kranenburg authored
[git-debrebase changelog: new upstream 4.16.2]
-
Hans van Kranenburg authored
[git-debrebase anchor: new upstream 4.16.2, merge]
-
- 18 Aug, 2022 1 commit
-
-
Jan Beulich authored
-
- 15 Aug, 2022 4 commits
-
-
Jan Beulich authored
The last "wildcard" use of either function went away with f5917558 ("IOMMU/PCI: don't let domain cleanup continue when device de-assignment failed"). Don't allow them to be called this way anymore. Besides simplifying the code this also fixes two bugs: 1) When seg != -1, the outer loops should have been terminated after the first iteration, or else a device with the same BDF but on another segment could be found / returned. Reported-by:
Rahul Singh <rahul.singh@arm.com> 2) When seg == -1 calling get_pseg() is bogus. The function (taking a u16) would look for segment 0xffff, which might exist. If it exists, we might then find / return a wrong device. In pci_get_pdev_by_domain() also switch from using the per-segment list to using the per-domain one, with the exception of the hardware domain (see the code comment there). While there also constify "pseg" and drop "pdev"'s already previously unnecessary initializer. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by:
-
Jan Beulich authored
Commit 68f5aac012b9 ("build: suppress future GNU ld warning about RWX load segments") didn't quite cover all the cases: Apparently I missed ones in the building of 32-bit helper objects because of only looking at incremental builds (where those wouldn't normally be re-built). Clone the workaround there to the specific Makefile in question. Reported-by: -
Ross Lagerwall authored
This should only be called for the boot CPU to avoid calling _init code after it has been unloaded. Fixes: 062868a5a8b4 ("x86/amd: Work around CLFLUSH ordering on older parts") Signed-off-by:Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by:
-
Andrew Cooper authored
The PBRSB_NO bit indicates that the CPU is not vulnerable to the Post-Barrier RSB speculative vulnerability. Signed-off-by:
-
