Pkg xen devel - Sep 2020 - [PATCH 12/12] Partially revert "Cross-compilation fixes."

Without this, we'll be building tools for the build machine, not the host
machine.

Signed-off-by: Elliott Mitchell <ehem+debian at m5p.com>
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 23ffd830c2..70235b494c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -178,6 +178,7 @@ override_dh_auto_configure:
 		--includedir=/usr/include \
 		--libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
 		--with-libexec-libdir-suffix=/$(DEB_HOST_MULTIARCH) \
+		--host=$(DEB_HOST_MULTIARCH) \
 		--mandir=/usr/share/man \
 		--infodir=/usr/share/info \
 		--sysconfdir=/etc \
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

The original author of debian/rules seemed to have planned to make use
of $(make_args_common), but never got to sharing combined values.  Since
some values are shareable, make use of the shared args.

Signed-off-by: Elliott Mitchell <ehem+debian at m5p.com>
---
 debian/rules | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/debian/rules b/debian/rules
index c3d5ed8941..23ffd830c2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -134,15 +134,15 @@ dpkg_CFLAGS   := $(shell $(dbmo) dpkg-buildflags --get
CFLAGS)
 dpkg_CPPFLAGS := $(shell $(dbmo) dpkg-buildflags --get CPPFLAGS)
 dpkg_LDFLAGS  := $(shell $(dbmo) dpkg-buildflags --get LDFLAGS)
 
-make_args_xen= $(make_args_common) \
+make_args_common := \
 	XEN_COMPILE_ARCH=$(xen_arch_$(DEB_BUILD_ARCH)) \
-	XEN_TARGET_ARCH=$(xen_arch_$(flavour)) \
+	XEN_TARGET_ARCH=$(xen_arch_$(flavour))
+
+make_args_xen := $(make_args_common)
 # (Xen upstream does not offer a separate CPPFLAGS,
 # so we pass those in CFLAGS.)
 
-make_args_tools= $(make_args_common) \
-	XEN_COMPILE_ARCH=$(xen_arch_$(DEB_BUILD_ARCH)) \
-	XEN_TARGET_ARCH=$(xen_arch_$(DEB_HOST_ARCH)) \
+make_args_tools := $(make_args_common) \
 	EXTRA_CFLAGS_XEN_TOOLS='$(dpkg_CFLAGS) $(dpkg_CPPFLAGS)' \
 	PREPEND_LDFLAGS_XEN_TOOLS='$(dpkg_LDFLAGS)'
 
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Set $(CC) and $(LD) when building.  People building ARM executables on
ARM hosts aren't that common.

Signed-off-by: Elliott Mitchell <ehem+debian at m5p.com>
---
 debian/rules | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 70235b494c..cd30fb54f2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -136,7 +136,9 @@ dpkg_LDFLAGS  := $(shell $(dbmo) dpkg-buildflags --get
LDFLAGS)
 
 make_args_common := \
 	XEN_COMPILE_ARCH=$(xen_arch_$(DEB_BUILD_ARCH)) \
-	XEN_TARGET_ARCH=$(xen_arch_$(flavour))
+	XEN_TARGET_ARCH=$(xen_arch_$(flavour)) \
+	CC=$(DEB_HOST_MULTIARCH)-gcc \
+	LD=$(DEB_HOST_MULTIARCH)-ld
 
 make_args_xen := $(make_args_common)
 # (Xen upstream does not offer a separate CPPFLAGS,
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

UEFI is available on ARM64 devices, but presently there is no Xen
configuration for building the PV shim on ARM.  The install step needs
to match the build step, so modify the install step.

Take out a typo while at it.

Signed-off-by: Elliott Mitchell <ehem+debian at m5p.com>
---
 debian/rules | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/debian/rules b/debian/rules
index cd90e27038..c3d5ed8941 100755
--- a/debian/rules
+++ b/debian/rules
@@ -217,11 +217,15 @@ override_dh_auto_install: $(TEMPLATED_FILES)
 	:
 	@# shim install target needs to be run separately because we
 	@# need to pass it the make_args_xen settings, in particular
-	@# on i386 bwe need to pass x86_64 here to actually build it.
+	@# on i386 we need to pass x86_64 here to actually build it.
 	@# Luckily this target, unlike the build, is a noop on
 	@# shimless arches, so it does not need to be conditional.
-	$(MAKE) $(make_args_xen) DESTDIR=$t $(make_args_xen) \
-		-C tools/firmware install-shim
+	case $(flavour) in \
+	amd64|i386) \
+		$(MAKE) $(make_args_xen) DESTDIR=$t $(make_args_xen) \
+			-C tools/firmware install-shim \
+	;; \
+	esac
 	:
 	@# Inexplicably, upstream puts the efi binares in usr/lib64
 	mv $t/usr/lib64/efi/* $t/boot/.
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

If EFI isn't being built the files simply won't be there and the line
accomplishes nothing.  If EFI is added to a new platform this adds an
extra spot which breaks.

This reverts commit 8ff478af61fa8a87806a89bbd618cd9da2354302.
---
 debian/rules | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/debian/rules b/debian/rules
index 543c735f3e..cd90e27038 100755
--- a/debian/rules
+++ b/debian/rules
@@ -224,10 +224,7 @@ override_dh_auto_install: $(TEMPLATED_FILES)
 		-C tools/firmware install-shim
 	:
 	@# Inexplicably, upstream puts the efi binares in usr/lib64
-	case $(flavour) in \
-		armhf) ;; \
-		*) mv $t/usr/lib64/efi/* $t/boot/. ;; \
-	esac
+	mv $t/usr/lib64/efi/* $t/boot/.
 	:
 	@# This file contains an arch-specific path and we put it
 	@# in xen-utils-common, an arch-all package.  But the
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

`ldd` doesn't work with cross-builds, so use `file` to detect scripts
and `strings | grep` for identifying linked libraries.

Script almost conforms to POSIX shell standard, so adjust to conform and
switch to /bin/sh.  Simplify pipe structure, do more work in parent
shell.

Signed-off-by: Elliott Mitchell <ehem+debian at m5p.com>
---
 debian/shuffle-binaries | 45 +++++++++++++++++++++++------------------
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/debian/shuffle-binaries b/debian/shuffle-binaries
index cff6de5428..de98e6d799 100755
--- a/debian/shuffle-binaries
+++ b/debian/shuffle-binaries
@@ -1,6 +1,5 @@
-#!/bin/bash
+#!/bin/sh
 set -e
-set -o pipefail
 
 version=$1; shift
 
@@ -20,31 +19,37 @@ t=debian/tmp
 vd=/usr/lib/xen-$version/bin
 cd=/usr/lib/xen-common/bin
 
-mkdir -p $t/$vd
+mkdir -p "$t/$vd"
 
-for binary in `find $t/usr/{bin,sbin} -type f`; do
-	reason=''
-	{ ldd "$binary" ||: ; } | { fgrep '=>' ||: ; } \
-	| (
-		while read lib dummy; do
+find "$t"/usr/*bin -type f | while read exec; do
+
+	# filter out scripts
+	file "$exec" | grep -q -eELF.\\+version.\\+interpreter || continue
+
+	# ldd doesn't work for cross-building
+	reason=$(
+		strings "$exec" | grep -e^lib.\\+\\.so\\.\[.0-9\]\\+\$ | \
+		while read lib; do
 			lib=${lib%.so.*}
-			if grep -F "usr/lib/*/$lib.so.*" $list >/dev/null; then
-				reason+=" $lib"
+			if grep -q -F "usr/lib/*/$lib.so.*" $list; then
+				printf " %s" "$lib"
 			fi
 		done
+	)
 
-		if [ "x$reason" = x ]; then
-			exit 0
-		fi
+	# if no reason, then skip
+	[ -n "$reason" ] || continue
 
-		echo "shuffling $binary $reason"
+	echo "shuffling $exec$reason"
 
-		leaf=${binary##*}
-		mv -v $binary $t/$vd/$leaf
-		ln -vs $cd/xen-utils-wrapper $binary
+	leaf=${exec##*}
+	mv -v $exec $t/$vd/$leaf
+	ln -vs $cd/xen-utils-wrapper $exec
 
-		touch debian/shuffle-binaries.stamp
-	)
+	touch "$0.stamp"
 done
 
-ls debian/shuffle-binaries.stamp
+if [ ! -e "$0.stamp" ]; then
+	echo "Failed to shuffle binaries!" 1>&2
+	exit 1
+fi
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Often /bin/sh is distinctly faster than Bash, so move to the better
interpreter.  Simplify variable usage to conform.

Signed-off-by: Elliott Mitchell <ehem+debian at m5p.com>
---
 debian/shuffle-boot-files | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/shuffle-boot-files b/debian/shuffle-boot-files
index f7492c0c72..8e4ed7e64c 100755
--- a/debian/shuffle-boot-files
+++ b/debian/shuffle-boot-files
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -e
 
@@ -26,6 +26,7 @@ verstring=$(readlink debian/tmp/boot/xen.gz ||
 verstring=${verstring##*/}
 verstring=${verstring%.gz}
 
-for f in `cd $t/boot && find * -type f -print`; do
-	cp -v $t/boot/$f $dest/${f/$verstring/xen-$version-$flavour}
+find "$t/boot" -type f -print | while read f
+do
+	cp -v "$f" "$dest${f#$t/boot}"
 done
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7.

Signed-off-by: Elliott Mitchell <ehem+xen at m5p.com>
---
 tools/Makefile | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index 7b1f6c4d28..930a533724 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -40,12 +40,9 @@ SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
 SUBDIRS-$(CONFIG_X86) += debugger/kdd
 SUBDIRS-$(CONFIG_TESTS) += tests
 
-# These don't cross-compile
-ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 SUBDIRS-y += python
 SUBDIRS-y += pygrub
 SUBDIRS-$(OCAML_TOOLS) += ocaml
-endif
 
 ifeq ($(CONFIG_RUMP),y)
 SUBDIRS-y := libs libxc xenstore
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

At this time cross-building for OCAML is broken.  Hopefully it may work
in future, but at this time it does not.

Signed-off-by: Elliott Mitchell <ehem+debian at m5p.com>
---
 debian/rules | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index cd30fb54f2..67fd74e89f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -202,11 +202,15 @@ override_dh_auto_configure:
 # separately.
 override_dh_auto_build:
 	$(MAKE) $(make_args_xen) xen
-	$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n
+	$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n OCAML_TOOLS=n
 	case $(flavour) in \
 	amd64|i386) \
 		$(MAKE) $(make_args_xen) -C tools/firmware/xen-dir ;; \
 	esac
+	@# OCAML cross-compilation is currently non-functional
+	if [ "$(DEB_BUILD_ARCH)" = "$(DEB_HOST_ARCH)" ]; then \
+		$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n ; \
+	fi
 	touch debian/xen-tools-built.stamp
 
 # We keep the amount of fixup and messing about with debian/tmp/
@@ -216,7 +220,16 @@ override_dh_auto_build:
 override_dh_auto_install: $(TEMPLATED_FILES)
 	$(MAKE) $(make_args_xen) DESTDIR=$t install-xen
 	$(MAKE) $(make_args_tools) DESTDIR=$t \
-		install-{tools,docs} CONFIG_PV_SHIM=n
+		install-{tools,docs} CONFIG_PV_SHIM=n OCAML_TOOLS=n
+	:
+	@# OCAML doesn't work when cross-building
+	if [ "$(DEB_BUILD_ARCH)" = "$(DEB_HOST_ARCH)" ]; then \
+		$(MAKE) $(make_args_tools) DESTDIR=$t \
+			install-{tools,docs} CONFIG_PV_SHIM=n ; \
+	else \
+		touch $t/etc/xen/oxenstored.conf ; \
+		cp -l $t/usr/sbin/xl $t/usr/sbin/oxenstored ; \
+	fi
 	:
 	@# shim install target needs to be run separately because we
 	@# need to pass it the make_args_xen settings, in particular
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Initially out there as #965245.

I strongly prefer to build ARM64 packages on non-ARM systems.  Something
about my main build machine having twice the cores and twice the clock
speed.  As such after many builds I've managed to generate a set of
patches which appear to mostly function to get functioning cross-builds
of Xen.

These are NOT a 100% solution.  Some packaging hacks were needed.  In
particular ocaml-nox|ocaml-native-compilers is a major problem.
ocaml-nox cannot be used for cross-building.  Until ocaml-nox is fixed
the OCAML Xen bits are going to be problematic for cross-compilation.
I've worked around this to the degree possible, even though the resultant
package will have non-functioning OCAML bits replacements should drop-in.

Several of these can likely be squashed together. 1-2 are the two halves
of a bug. 3-4 are another pair, 3 is a genuine bug.  5-7 are another set.

Patch 12 is special, it has already been submitted to Xen for inclusion.
It is though *required* for functioning cross-compilation.

Patches 9-11 are already in Xen's 4.14 branch.  They are popular due to
the Raspberry PI 4's rather significant audience.  I imagine many people
using Debian on ARM highly desire them.

Elliott Mitchell (9):
  Revert "debian/rules: Do not try to move EFI binaries on armhf"
  debian/rules: Only install PV shim for supported architectures
  debian/rules: Fix binary shuffling script for cross-building
  debian/rules: Adjust boot shuffling script for POSIX
  debian/rules: Combine shared Make args
  debian/rules: Add --host to tools configure target
  debian/rules: Set CC/LD for cross-building
  debian/rules: Disable OCAML build when cross-building
  Partially revert "Cross-compilation fixes."

Julien Grall (3):
  xen/arm: Allow a platform to override the DMA width
  xen/arm: Take into account the DMA width when allocating Dom0 memory
    banks
  xen/arm: plat: Allocate as much as possible memory below 1GB for dom0
    for RPI

 debian/rules                               | 43 ++++++++++++++-------
 debian/shuffle-binaries                    | 45 ++++++++++++----------
 debian/shuffle-boot-files                  |  7 ++--
 tools/Makefile                             |  3 --
 xen/arch/arm/domain_build.c                | 33 +++++++++-------
 xen/arch/arm/platform.c                    |  5 +++
 xen/arch/arm/platforms/brcm-raspberry-pi.c |  1 +
 xen/include/asm-arm/mm.h                   |  2 +
 xen/include/asm-arm/numa.h                 |  5 ---
 xen/include/asm-arm/platform.h             |  2 +
 10 files changed, 88 insertions(+), 58 deletions(-)

-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

At the moment, Xen is assuming that all the devices are at least 32-bit
DMA capable. However, some SoC have devices that may be able to access
a much restricted range. For instance, the RPI has devices that can
only access the first 1GB of RAM.

The structure platform_desc is now extended to allow a platform to
override the DMA width. The new is used to implement
arch_get_dma_bit_size().

The prototype is now moved in asm-arm/mm.h as the function is not NUMA
specific. The implementation is done in platform.c so we don't have to
include platform.h everywhere. This should be fine as the function is
not expected to be called in hotpath.

Signed-off-by: Julien Grall <jgrall at amazon.com>
Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk at epam.com>
Tested-by: Corey Minyard <cminyard at mvista.com>

---

Cc: Jan Beulich <jbeulich at suse.com>
Cc: Andrew Cooper <andrew.cooper3 at citrix.com>
Cc: George Dunlap <george.dunlap at citrix.com>

    Changes in v2:
        - Add Corey's tested-by
        - Add Volodymyr's reviewed-by

I noticed that arch_get_dma_bit_size() is only called when there is more
than one NUMA node. I am a bit unsure what is the reason behind it.

The goal for Arm is to use arch_get_dma_bit_size() when deciding how low
the first Dom0 bank should be allocated.
---
 xen/arch/arm/platform.c        | 5 +++++
 xen/include/asm-arm/mm.h       | 2 ++
 xen/include/asm-arm/numa.h     | 5 -----
 xen/include/asm-arm/platform.h | 2 ++
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index 8eb0b6e57a..4db5bbb4c5 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -155,6 +155,11 @@ bool platform_device_is_blacklisted(const struct
dt_device_node *node)
     return (dt_match_node(blacklist, node) != NULL);
 }
 
+unsigned int arch_get_dma_bitsize(void)
+{
+    return ( platform && platform->dma_bitsize ) ?
platform->dma_bitsize : 32;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 333efd3a60..a557e100c1 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -363,6 +363,8 @@ int arch_acquire_resource(struct domain *d, unsigned int
type, unsigned int id,
     return -EOPNOTSUPP;
 }
 
+unsigned int arch_get_dma_bitsize(void);
+
 #endif /*  __ARCH_ARM_MM__ */
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index 490d1f31aa..31a6de4e23 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -25,11 +25,6 @@ extern mfn_t first_valid_mfn;
 #define node_start_pfn(nid) (mfn_x(first_valid_mfn))
 #define __node_distance(a, b) (20)
 
-static inline unsigned int arch_get_dma_bitsize(void)
-{
-    return 32;
-}
-
 #endif /* __ARCH_ARM_NUMA_H */
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index ed4d30a1be..997eb25216 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -38,6 +38,8 @@ struct platform_desc {
      * List of devices which must not pass-through to a guest
      */
     const struct dt_device_match *blacklist_dev;
+    /* Override the DMA width (32-bit by default). */
+    unsigned int dma_bitsize;
 };
 
 /*
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

At the moment, Xen is assuming that all the devices are at least 32-bit
DMA capable. However, some SoCs have devices that may be able to access
a much restricted range. For instance, the Raspberry PI 4 has devices
that can only access the first GB of RAM.

The function arch_get_dma_bit_size() will return the lowest DMA width on
the platform. Use it to decide what is the limit for the low memory.

Signed-off-by: Julien Grall <jgrall at amazon.com>
Tested-by: Corey Minyard <cminyard at mvista.com>

---
    Changes in v2:
        - Remove left-over in the comment
        - Add Corey's tested-by
---
 xen/arch/arm/domain_build.c | 33 +++++++++++++++++++--------------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index dd9c3b73ba..c9982ba98f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -210,10 +210,12 @@ fail:
  *    the ramdisk and DTB must be placed within a certain proximity of
  *    the kernel within RAM.
  * 3. For dom0 we want to place as much of the RAM as we reasonably can
- *    below 4GB, so that it can be used by non-LPAE enabled kernels (32-bit)
- *    or when a device assigned to dom0 can only do 32-bit DMA access.
- * 4. For 32-bit dom0 the kernel must be located below 4GB.
- * 5. We want to have a few largers banks rather than many smaller ones.
+ *    below 4GB, so that it can be used by non-LPAE enabled kernels (32-bit).
+ * 4. Some devices assigned to dom0 can only do 32-bit DMA access or
+ *    even be more restricted. We want to allocate as much of the RAM
+ *    as we reasonably can that can be accessed from all the devices..
+ * 5. For 32-bit dom0 the kernel must be located below 4GB.
+ * 6. We want to have a few largers banks rather than many smaller ones.
  *
  * For the first two requirements we need to make sure that the lowest
  * bank is sufficiently large.
@@ -244,9 +246,9 @@ fail:
  * we give up.
  *
  * For 32-bit domain we require that the initial allocation for the
- * first bank is under 4G. For 64-bit domain, the first bank is preferred
- * to be allocated under 4G. Then for the subsequent allocations we
- * initially allocate memory only from below 4GB. Once that runs out
+ * first bank is part of the low mem. For 64-bit, the first bank is preferred
+ * to be allocated in the low mem. Then for subsequent allocation, we
+ * initially allocate memory only from low mem. Once that runs out out
  * (as described above) we allow higher allocations and continue until
  * that runs out (or we have allocated sufficient dom0 memory).
  */
@@ -261,6 +263,7 @@ static void __init allocate_memory_11(struct domain *d,
     int i;
 
     bool lowmem = true;
+    unsigned int lowmem_bitsize = min(32U, arch_get_dma_bitsize());
     unsigned int bits;
 
     /*
@@ -281,7 +284,7 @@ static void __init allocate_memory_11(struct domain *d,
      */
     while ( order >= min_low_order )
     {
-        for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
+        for ( bits = order ; bits <= lowmem_bitsize; bits++ )
         {
             pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
             if ( pg != NULL )
@@ -295,24 +298,26 @@ static void __init allocate_memory_11(struct domain *d,
         order--;
     }
 
-    /* Failed to allocate bank0 under 4GB */
+    /* Failed to allocate bank0 in the lowmem region. */
     if ( is_32bit_domain(d) )
         panic("Unable to allocate first memory bank\n");
 
-    /* Try to allocate memory from above 4GB */
-    printk(XENLOG_INFO "No bank has been allocated below 4GB.\n");
+    /* Try to allocate memory from above the lowmem region */
+    printk(XENLOG_INFO "No bank has been allocated below %u-bit.\n",
+           lowmem_bitsize);
     lowmem = false;
 
  got_bank0:
 
     /*
-     * If we failed to allocate bank0 under 4GB, continue allocating
-     * memory from above 4GB and fill in banks.
+     * If we failed to allocate bank0 in the lowmem region,
+     * continue allocating from above the lowmem and fill in banks.
      */
     order = get_allocation_size(kinfo->unassigned_mem);
     while ( kinfo->unassigned_mem && kinfo->mem.nr_banks <
NR_MEM_BANKS )
     {
-        pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
+        pg = alloc_domheap_pages(d, order,
+                                 lowmem ? MEMF_bits(lowmem_bitsize) : 0);
         if ( !pg )
         {
             order --;
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

The raspberry PI 4 has devices that can only DMA into the first GB of
the RAM. Therefore we want allocate as much as possible memory below 1GB
for dom0.

Use the recently introduced dma_bitsize field to specify the DMA width
supported.

Signed-off-by: Julien Grall <jgrall at amazon.com>
Reported-by: Corey Minyard <minyard at acm.org>
Tested-by: Corey Minyard <cminyard at mvista.com>

---
    Changes in v2:
        - 1G is 30 bits not 10!
        - Add Corey's tested-by
---
 xen/arch/arm/platforms/brcm-raspberry-pi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c
b/xen/arch/arm/platforms/brcm-raspberry-pi.c
index b697fa2c6c..f5ae58a7d5 100644
--- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
+++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
@@ -43,6 +43,7 @@ static const struct dt_device_match rpi4_blacklist_dev[]
__initconst  PLATFORM_START(rpi4, "Raspberry Pi 4")
     .compatible     = rpi4_dt_compat,
     .blacklist_dev  = rpi4_blacklist_dev,
+    .dma_bitsize    = 30,
 PLATFORM_END
 
 /*
-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Taking the output of `git format-patch` and piping it to a mailer is a
potentially hazardous art.  If you don't /quite/ get things right you can
end up faking the sender of a message.

Please note the patches 9-11 were sent by me, though Julien Grall is the
original author.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Hi,

On 7/19/20 8:01 AM, Elliott Mitchell wrote:
> Taking the output of `git format-patch` and piping it to a mailer is a
> potentially hazardous art.  If you don't /quite/ get things right you
can
> end up faking the sender of a message.
> 
> Please note the patches 9-11 were sent by me, though Julien Grall is the
> original author.
Hah. :)

The git send-email program can do the actual emailing, and then it sets
all mail dates to the current time (so that the mails end up 00-12 if
you get them instead of in order of original commit date, which is now
9,10-11,5,6,2,etc). It will also put you as sender, and then add the
"From: Foo <foo at bar>" line as first in the email, which
causes it to be
put back as commit author when using git am.

e.g.

    git send-email --suppress-cc=all --dry-run 00*

You want the suppress-cc because otherwise you'll be causing mails to be
sent to Julian and everyone who has Reviewed-by etc lines in the
original commits.

Dry-run shows the smtp header stuff to verify.

Feel free to re-send.

Have fun,
Hans

Hi,

On 7/19/20 1:21 AM, Elliott Mitchell wrote:
> Initially out there as #965245.
> 
> I strongly prefer to build ARM64 packages on non-ARM systems.  Something
> about my main build machine having twice the cores and twice the clock
> speed.  As such after many builds I've managed to generate a set of
> patches which appear to mostly function to get functioning cross-builds
> of Xen.
> 
> These are NOT a 100% solution.  Some packaging hacks were needed.  In
> particular ocaml-nox|ocaml-native-compilers is a major problem.
> ocaml-nox cannot be used for cross-building.  Until ocaml-nox is fixed
> the OCAML Xen bits are going to be problematic for cross-compilation.
> I've worked around this to the degree possible, even though the
resultant
> package will have non-functioning OCAML bits replacements should drop-in.
> 
> Several of these can likely be squashed together. 1-2 are the two halves
> of a bug. 3-4 are another pair, 3 is a genuine bug.  5-7 are another set.
Having small patches which do one thing at a time is just fine.
> Patch 12 is special, it has already been submitted to Xen for inclusion.
> It is though *required* for functioning cross-compilation.
Ok, I see it's in, so I will include that one by cherry-picking commit
69953e28563 instead.
> Patches 9-11 are already in Xen's 4.14 branch.  They are popular due to
> the Raspberry PI 4's rather significant audience.  I imagine many
people
> using Debian on ARM highly desire them.
Since the packaging is now forwarded to 4.14, it's a noop indeed.
> Elliott Mitchell (9):
>   Revert "debian/rules: Do not try to move EFI binaries on armhf"
>   debian/rules: Only install PV shim for supported architectures
>   debian/rules: Fix binary shuffling script for cross-building
    ^ I changed this to d/shuffle-binaries, it's not touching rules
>   debian/rules: Adjust boot shuffling script for POSIX
    ^ I changed this to d/shuffle-boot-files, same reason
>   debian/rules: Combine shared Make args
>   debian/rules: Add --host to tools configure target
>   debian/rules: Set CC/LD for cross-building
>   debian/rules: Disable OCAML build when cross-building
>   Partially revert "Cross-compilation fixes."
> 
> Julien Grall (3):
>   xen/arm: Allow a platform to override the DMA width
>   xen/arm: Take into account the DMA width when allocating Dom0 memory
>     banks
>   xen/arm: plat: Allocate as much as possible memory below 1GB for dom0
>     for RPI
> 
>  debian/rules                               | 43 ++++++++++++++-------
>  debian/shuffle-binaries                    | 45 ++++++++++++----------
>  debian/shuffle-boot-files                  |  7 ++--
>  tools/Makefile                             |  3 --
>  xen/arch/arm/domain_build.c                | 33 +++++++++-------
>  xen/arch/arm/platform.c                    |  5 +++
>  xen/arch/arm/platforms/brcm-raspberry-pi.c |  1 +
>  xen/include/asm-arm/mm.h                   |  2 +
>  xen/include/asm-arm/numa.h                 |  5 ---
>  xen/include/asm-arm/platform.h             |  2 +
>  10 files changed, 88 insertions(+), 58 deletions(-)
I added this to my knorrie/4.14-extra branch. Note that that branch has
d/patches which is out of sync, it's just for stashing/preparing some
commits that are not in knorrie/4.14 yet.

https://salsa.debian.org/xen-team/debian-xen/-/commits/knorrie/4.14-extra

I did regression smoke test build and it build and boots.

Ian, can you review the packaging changes?

Hans

Elliott Mitchell writes ("[PATCH 01/12] Revert "debian/rules: Do not
try to move EFI binaries on armhf""):
> If EFI isn't being built the files simply won't be there and the
line
> accomplishes nothing.  If EFI is added to a new platform this adds an
> extra spot which breaks.
Hi.  Thanks for all this work.  I'm reviewing your patches.
(FYI I am involved both in Xen in Debian, and am also upstream.[1])
> diff --git a/debian/rules b/debian/rules
> index 543c735f3e..cd90e27038 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -224,10 +224,7 @@ override_dh_auto_install: $(TEMPLATED_FILES)
>  		-C tools/firmware install-shim
>  	:
>  	@# Inexplicably, upstream puts the efi binares in usr/lib64
> -	case $(flavour) in \
> -		armhf) ;; \
> -		*) mv $t/usr/lib64/efi/* $t/boot/. ;; \
> -	esac
> +	mv $t/usr/lib64/efi/* $t/boot/.
>  	:
This looks to me like it will fail if the files do not exist.  The
case was a way to work around this problem.  That is, I think the
shell will execute the command with literally a `*' and then mv will
complain.

We need a rune which doesn't fail if the file is absent.  But it
*should* fail if the file exists but the rename fails.
(Maybe we could do this with some debhelper thing instead.)

Ian.

[1] Full disclosure: I an employee of Citrix and paid to work on Xen.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my
own.

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Elliott Mitchell writes ("[PATCH 02/12] debian/rules: Only install PV shim
for supported architectures"):
> UEFI is available on ARM64 devices, but presently there is no Xen
> configuration for building the PV shim on ARM.  The install step needs
> to match the build step, so modify the install step.
>  	@# shimless arches, so it does not need to be conditional.
> -	$(MAKE) $(make_args_xen) DESTDIR=$t $(make_args_xen) \
> -		-C tools/firmware install-shim
> +	case $(flavour) in \
> +	amd64|i386) \
> +		$(MAKE) $(make_args_xen) DESTDIR=$t $(make_args_xen) \
> +			-C tools/firmware install-shim \
> +	;; \
> +	esac
I don't understand.  The effect of your patch is to avoid running
make install-shim on armhf and arm64.

But on those platforms there is as you say no shim[1], so make
install-shim ought to do nothing.  We build armhf and arm64 on the
Debian buildds from the sources before your patch.

I'm not sure what the connection is between the PV shim and UEFI ?
These are separate concepts.

The PV shim is there to run PV guests in an HVM container, mostly for
Spectre reasons.  There is no shim for ARM because ARM does not have
HVM guests nor PV ones; it has only one type of guest which is roughly
like an x86 PVH guest.

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my
own.

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Elliott Mitchell writes ("[PATCH 03/12] debian/rules: Fix binary shuffling
script for cross-building"):
> `ldd` doesn't work with cross-builds, so use `file` to detect scripts
> and `strings | grep` for identifying linked libraries.
How sad that ldd doesn't work.  I approve of the change to use file,
although maybe that should have a change to build-depends.  (Right now
it seems that debhelper depends on file so this is a theoretical bug
rather than a FTBFS-on-buildd issue.)
> Script almost conforms to POSIX shell standard, so adjust to conform and
> switch to /bin/sh.  Simplify pipe structure, do more work in parent
> shell.
I'm sorry to say that I don't agree with this.  What made you think
there was anything undesirable about using bash in a build system ?
>  set -e
> -set -o pipefail
This, in particular, has quite adverse impacts on error handling.
Also you have reformatted the script.  Reformatting things is usually
to be discouraged.

Sorry,
Ian.

Elliott Mitchell writes ("[PATCH 04/12] debian/rules: Adjust boot shuffling
script for POSIX"):
> Often /bin/sh is distinctly faster than Bash, so move to the better
> interpreter.  Simplify variable usage to conform.
See my previous comment.

Your argument here is "it's faster".  Have you done benchmarks ? 
I
suspect changing everything to sh probably takes off a few
milliseconds from a half-hour-long Xen package build.
> diff --git a/debian/shuffle-boot-files b/debian/shuffle-boot-files
> index f7492c0c72..8e4ed7e64c 100755
> --- a/debian/shuffle-boot-files
> +++ b/debian/shuffle-boot-files
> @@ -1,4 +1,4 @@
> -#!/bin/bash
> +#!/bin/sh
>  
>  set -e
>  
> @@ -26,6 +26,7 @@ verstring=$(readlink debian/tmp/boot/xen.gz ||
>  verstring=${verstring##*/}
>  verstring=${verstring%.gz}
>  
> -for f in `cd $t/boot && find * -type f -print`; do
> -	cp -v $t/boot/$f $dest/${f/$verstring/xen-$version-$flavour}
> +find "$t/boot" -type f -print | while read f
> +do
> +	cp -v "$f" "$dest${f#$t/boot}"
>  done
(1) I'm not sure this does precisely the same thing as before
(2) even the amount of time I have just spent staring at it was
wasted because there is no need for this change.

Ian.

Elliott Mitchell writes ("[PATCH 05/12] debian/rules: Combine shared Make
args"):
> The original author of debian/rules seemed to have planned to make use
> of $(make_args_common), but never got to sharing combined values.  Since
> some values are shareable, make use of the shared args.
You are right!  Thanks,

Reviewed-by: Ian Jackson <iwj at xenproject.org>


-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my
own.

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Elliott Mitchell writes ("[PATCH 06/12] debian/rules: Add --host to tools
configure target"):
> Without this, we'll be building tools for the build machine, not the
host
> machine.
Thanks.

Reviewed-by: Ian Jackson <iwj at xenproject.org>


-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my
own.

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Elliott Mitchell writes ("[PATCH 07/12] debian/rules: Set CC/LD for
cross-building"):
> Set $(CC) and $(LD) when building.  People building ARM executables on
> ARM hosts aren't that common.
...
>  make_args_common := \
>  	XEN_COMPILE_ARCH=$(xen_arch_$(DEB_BUILD_ARCH)) \
> -	XEN_TARGET_ARCH=$(xen_arch_$(flavour))
> +	XEN_TARGET_ARCH=$(xen_arch_$(flavour)) \
> +	CC=$(DEB_HOST_MULTIARCH)-gcc \
> +	LD=$(DEB_HOST_MULTIARCH)-ld
Doesn't this want to be in make-args-xen ?

That is, I think autoconf, configure, et al, ought to do this right
for the tools.  It is the hypervisor which needs this other kind of
cross-compilation.

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my
own.

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Elliott Mitchell writes ("[PATCH 08/12] debian/rules: Disable OCAML build
when cross-building"):
> At this time cross-building for OCAML is broken.  Hopefully it may work
> in future, but at this time it does not.
Just to clarify this: the build-dependencies are satisfiable, so the
ocaml tools are installable, but they do not work ?
> diff --git a/debian/rules b/debian/rules
> index cd30fb54f2..67fd74e89f 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -202,11 +202,15 @@ override_dh_auto_configure:
>  # separately.
>  override_dh_auto_build:
>  	$(MAKE) $(make_args_xen) xen
> -	$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n
> +	$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n OCAML_TOOLS=n
>  	case $(flavour) in \
>  	amd64|i386) \
>  		$(MAKE) $(make_args_xen) -C tools/firmware/xen-dir ;; \
>  	esac
> +	@# OCAML cross-compilation is currently non-functional
> +	if [ "$(DEB_BUILD_ARCH)" = "$(DEB_HOST_ARCH)" ]; then
\
> +		$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n ; \
> +	fi
>  	touch debian/xen-tools-built.stamp
Can you refer us to a bug report about the ocaml problem ?  I think a
reference to that bug ought to go here in a comment.
> +		install-{tools,docs} CONFIG_PV_SHIM=n OCAML_TOOLS=n
...
> +	@# OCAML doesn't work when cross-building
> +	if [ "$(DEB_BUILD_ARCH)" = "$(DEB_HOST_ARCH)" ]; then
\
You have this logic twice.

How about defining BUILD_OCAML_TOOLS as a make variable ?
> -	$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n
> +	$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n
OCAML_TOOLS=$(BUILD_OCAML_TOOLS)
Or something.  I don't care much about the variable name, but I do
care that the logic is in one place.
> +		$(MAKE) $(make_args_tools) DESTDIR=$t \
> +			install-{tools,docs} CONFIG_PV_SHIM=n ; \
> +	else \
> +		touch $t/etc/xen/oxenstored.conf ; \
> +		cp -l $t/usr/sbin/xl $t/usr/sbin/oxenstored ; \
> +	fi
I don't understand this last part at all.  You're making oxenstored a
link to xl ?

Why is simply passing OCAML_TOOLS=n to the upstream build,
conditionally, not the right thing to do ?  ISTM that that would be a
lot simpler.

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my
own.

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Elliott Mitchell writes ("[PATCH 12/12] Partially revert
"Cross-compilation fixes.""):
> This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7.
Wow, that is an upsteam commit from 2005.

However, I would like some kind of explanation.  Is it in fact now
false that
  | # These don't cross-compile
?

Should this patch go upstream ?

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my
own.

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

On 9/7/20 12:00 AM, Hans van Kranenburg wrote:
> Hi,
> 
> On 7/19/20 1:21 AM, Elliott Mitchell wrote:
>> Initially out there as #965245.
>>
>> I strongly prefer to build ARM64 packages on non-ARM systems. 
Something
>> about my main build machine having twice the cores and twice the clock
>> speed.  As such after many builds I've managed to generate a set of
>> patches which appear to mostly function to get functioning cross-builds
>> of Xen.
>>
>> These are NOT a 100% solution.  Some packaging hacks were needed.  In
>> particular ocaml-nox|ocaml-native-compilers is a major problem.
>> ocaml-nox cannot be used for cross-building.  Until ocaml-nox is fixed
>> the OCAML Xen bits are going to be problematic for cross-compilation.
>> I've worked around this to the degree possible, even though the
resultant
>> package will have non-functioning OCAML bits replacements should
drop-in.
>>
>> Several of these can likely be squashed together. 1-2 are the two
halves
>> of a bug. 3-4 are another pair, 3 is a genuine bug.  5-7 are another
set.
> 
> Having small patches which do one thing at a time is just fine.
> 
>> Patch 12 is special, it has already been submitted to Xen for
inclusion.
>> It is though *required* for functioning cross-compilation.
> 
> Ok, I see it's in, so I will include that one by cherry-picking commit
> 69953e28563 instead.
> 
>> Patches 9-11 are already in Xen's 4.14 branch.  They are popular
due to
>> the Raspberry PI 4's rather significant audience.  I imagine many
people
>> using Debian on ARM highly desire them.
> 
> Since the packaging is now forwarded to 4.14, it's a noop indeed.
> 
>> Elliott Mitchell (9):
>>   Revert "debian/rules: Do not try to move EFI binaries on
armhf"
>>   debian/rules: Only install PV shim for supported architectures
>>   debian/rules: Fix binary shuffling script for cross-building
> 
>     ^ I changed this to d/shuffle-binaries, it's not touching rules
> 
>>   debian/rules: Adjust boot shuffling script for POSIX
> 
>     ^ I changed this to d/shuffle-boot-files, same reason
> 
>>   debian/rules: Combine shared Make args
>>   debian/rules: Add --host to tools configure target
>>   debian/rules: Set CC/LD for cross-building
>>   debian/rules: Disable OCAML build when cross-building
>>   Partially revert "Cross-compilation fixes."
>>
>> Julien Grall (3):
>>   xen/arm: Allow a platform to override the DMA width
>>   xen/arm: Take into account the DMA width when allocating Dom0 memory
>>     banks
>>   xen/arm: plat: Allocate as much as possible memory below 1GB for dom0
>>     for RPI
>>
>>  debian/rules                               | 43 ++++++++++++++-------
>>  debian/shuffle-binaries                    | 45 ++++++++++++----------
>>  debian/shuffle-boot-files                  |  7 ++--
>>  tools/Makefile                             |  3 --
>>  xen/arch/arm/domain_build.c                | 33 +++++++++-------
>>  xen/arch/arm/platform.c                    |  5 +++
>>  xen/arch/arm/platforms/brcm-raspberry-pi.c |  1 +
>>  xen/include/asm-arm/mm.h                   |  2 +
>>  xen/include/asm-arm/numa.h                 |  5 ---
>>  xen/include/asm-arm/platform.h             |  2 +
>>  10 files changed, 88 insertions(+), 58 deletions(-)
> 
> I added this to my knorrie/4.14-extra branch. Note that that branch has
> d/patches which is out of sync, it's just for stashing/preparing some
> commits that are not in knorrie/4.14 yet.
> 
> https://salsa.debian.org/xen-team/debian-xen/-/commits/knorrie/4.14-extra
> 
> I did regression smoke test build and it build and boots.
> 
> Ian, can you review the packaging changes?
Yay, stuff is happening.

FTR, I just reverted knorrie/4.14 to 9625f122e8a and then added the
already accepted patches.

I also took out the 'commit patch queue' commit, and (while in q quest
to search for the best workflow/way to present a WIP branch to others to
base new patches on) pushed the branch without debrebase re-ordering
(which tears up patch sets and pushes all debian/* changes down) and
without the patch queue export.

So to build it for testing, refreshing debian/patches has to be done first.

Hans