- Mar 06, 2025
-
-
Maximilian Engelhardt authored[git-debrebase make-patches: export and commit patches]
-
Maximilian Engelhardt authored
[git-debrebase pseudomerge: quick]
-
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. Gbp-Pq: Name 0022-give-meaningful-error-message-if-qemu-device-model-i.patch
-
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 <hans@knorrie.org> Gbp-Pq: Name 0020-tools-don-t-build-ship-xenmon.patch
-
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> Gbp-Pq: Name 0018-pygrub-Specify-rpath-LIBEXEC_LIB-when-building-fsima.patch
-
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:
-
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: -
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>
Gbp-Pq: Name 0015-sysconfig.xencommons.in-Strip-and-debianize.patch -
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: -
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>
Gbp-Pq: Name 0012-shim-Provide-separate-install-shim-target.patch -
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: -
This is going to be used to put libfsimage.so into a path containing the multiarch triplet. Signed-off-by: -
\o/ Gbp-Pq: Name 0008-tools-libfsimage-prefix.diff.patch
-
Signed-off-by: -
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: -
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 DEB_VERSION and DEB_MAINTAINER variables needs to be set by debian/rules. Original patch by Bastian Blank <waldi@debian.org> Modified by Hans van Kranenburg <hans@knorrie.org> Maximilian Engelhardt <maxi@daemonizer.de> Gbp-Pq: Name 0003-Display-Debian-package-version-in-hypervisor-log.patch
-
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: -
dh_autoreconf will provide these back. If this patch does not apply when rebasing, you can simply delete the files again. Signed-off-by: -
Maximilian Engelhardt authored
-
Maximilian Engelhardt authored
On xen_4.20.0-1~exp1 it breaks the build with: dh_dwz -a dwz: debian/xen-utils-4.20-dbg/usr/lib/debug/usr/lib/xen-4.20/boot/xen-shim-syms: .debug_info section not present dwz: debian/xen-utils-common/usr/bin/xenalyze: DWARF compression not beneficial - old size 179662 new size 180735 dwz: Multi-file optimization not allowed for different pointer sizes dwz: debian/xen-utils-4.20/usr/lib/xen-4.20/boot/xen-shim: .debug_info section not present dh_dwz: warning: No dwz multifile created, but not explicitly requested either so ignoring it. dh_dwz: warning: Common issues include no debug information at all (missing -g) and dh_dwz: warning: compressed debug information (#931891). dwz: debian/libxenmisc4.20/usr/lib/x86_64-linux-gnu/libxenguest.so.4.20.0: DWARF compression not beneficial - old size 316023 new size 316135 dwz: debian/libxenmisc4.20/usr/lib/x86_64-linux-gnu/libxenlight.so.4.20.0: DWARF compression not beneficial - old size 1289934 new size 1306512 dwz: debian/xen-hypervisor-4.20-amd64-dbg/usr/lib/debug/boot/xen-4.20-amd64.efi.elf: DWARF version 0 in .debug_aranges unhandled dwz: Too few files for multifile optimization dh_dwz: error: dwz -mdebian/xen-hypervisor-4.20-amd64-dbg/usr/lib/debug/.dwz/x86_64-linux-gnu/xen-hypervisor-4.20-amd64-dbg.debug -M/usr/lib/debug/.dwz/x86_64-linux-gnu/xen-hypervisor-4.20-amd64-dbg.debug -- debian/xen-hypervisor-4.20-amd64-dbg/usr/lib/debug/boot/xen-4.20-amd64.efi.elf debian/xen-hypervisor-4.20-amd64-dbg/usr/lib/debug/boot/xen-syms-4.20-amd64 returned exit code 1 dh_dwz: error: Aborting due to earlier error make: *** [debian/rules:174: binary] Error 25 Signed-off-by:Maximilian Engelhardt <maxi@daemonizer.de>
-
- Mar 04, 2025
-
-
Maximilian Engelhardt authored
[git-debrebase changelog: new upstream 4.20.0]
-
Maximilian Engelhardt authored
[git-debrebase anchor: new upstream 4.20.0, merge]
-
Andrew Cooper authored
Signed-off-by:Andrew Cooper <andrew.cooper3@citrix.com>
-
Andrew Cooper authored
Signed-off-by: -
Andrew Cooper authored
Signed-off-by:
Roger Pau Monné <roger.pau@citrix.com> --- CC: Anthony PERARD <anthony.perard@vates.tech> CC: Michal Orzel <michal.orzel@amd.com> CC: Jan Beulich <jbeulich@suse.com> CC: Julien Grall <julien@xen.org> CC: Roger Pau Monné <roger.pau@citrix.com> CC: Stefano Stabellini <sstabellini@kernel.org> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
-
Andrew Cooper authored
Signed-off-by:
Oleksii Kurochko <oleksii.kurochko@gmail.com> (cherry picked from commit e28802927e0a24dab9c73082c3e322ef4dd0bd02)
-
- Feb 27, 2025
-
-
Oleksii Kurochko authored
Signed-off-by:
-
Jan Beulich authored
The function's use from set_msi_source_id() is guaranteed to be in an IRQs-off region. While the invocation of that function could be moved ahead in msi_msg_to_remap_entry() (doesn't need to be in the IOMMU- intremap-locked region), the call tree from map_domain_pirq() holds an IRQ descriptor lock. Hence all use sites of the lock need become IRQ- safe ones. In find_upstream_bridge() do a tiny bit of tidying in adjacent code: Change a variable's type to unsigned and merge a redundant assignment into another variable's initializer. This is XSA-467 / CVE-2025-1713. Fixes: 476bbccc ("VT-d: fix MSI source-id of interrupt remapping") Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
-
- Feb 26, 2025
-
-
Andrew Cooper authored
Also enable -fno-sanitize=alignment like x86 since support for unaligned accesses is guaranteed by the ISA and the existing OPAL setup code relies on it. Signed-off-by:
Shawn Anastasio <sanastasio@raptorengineering.com> Acked-by:
-
- Feb 21, 2025
-
-
Andrew Cooper authored
Signed-off-by: -
Stefano Stabellini authored
Signed-off-by:
Stefano Stabellini <stefano.stabellini@amd.com> Acked-by:
-
- Feb 20, 2025
-
-
Stefano Stabellini authored
MISRA R16.6 states that "Every switch statement shall have at least two switch-clauses". There are only 3 violations left on x86 (zero on ARM). One of them is only a violation depending on the kconfig configuration. So deviate it instead with a SAF comment. Two of them are deliberate to enable future additions. Deviate them as such. Signed-off-by:
Nicola Vetrini <nicola.vetrini@bugseng.com> Acked-by:
-
Andrew Cooper authored
Signed-off-by: -
Andrew Cooper authored
Reviewed-by:
-
Jan Beulich authored
struct mctelem_ent is opaque outside of mcetelem.c; the cookie abstraction exists - afaict - just to achieve this opaqueness. Then it is irrelevant though which kind of pointer mctelem_cookie_t resolves to. IOW we can as well use struct mctelem_ent there, allowing to remove the casts from COOKIE2MCTE() and MCTE2COOKIE(). Their removal addresses Misra C:2012 rule 11.2 ("Conversions shall not be performed between a pointer to an incomplete type and any other type") violations. No functional change intended. Signed-off-by:Oleksii <Kurochko<oleksii.kurochko@gmail.com>
-
- Feb 19, 2025
-
-
Andrew Cooper authored
There is a corner case in the VMRUN instruction where its INTR_SHADOW state leaks into guest state if a VMExit occurs before the VMRUN is complete. An example of this could be taking #NPF due to event injection. Xen can safely execute STI anywhere between CLGI and VMRUN, as CLGI blocks external interrupts too. However, an exception (while fatal) will appear to be in an irqs-on region (as GIF isn't considered), so position the STI after the speculation actions but prior to the GPR pops. Link: https://lore.kernel.org/all/CADH9ctBs1YPmE4aCfGPNBwA10cA8RuAk2gO7542DjMZgs4uzJQ@mail.gmail.com/ Fixes: 66b245d9 ("SVM: limit GIF=0 region") Signed-off-by:
-
