--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: release.debian.org: Xen dom0 does not power off on bullseye (stable)
- From: Chuck Zmudzinski <brchuckz@netscape.net>
- Date: Wed, 29 Sep 2021 19:26:41 -0400
- Message-id: <d4c395b4-5ee1-a12d-4ebc-77c9f74f799a@netscape.net>
- References: <d4c395b4-5ee1-a12d-4ebc-77c9f74f799a.ref@netscape.net>
Package: release.debian.org
Severity: important
Tags: patch
Dear Release Team,
Affected Package in bullseye: xen-hypervisor-4.14-amd64
Package Version: 4.14.3-1~deb11u1
Related bug reports: #994899, #991967
Description of problem: Xen dom0 does not power off
on shutdown. A serious bug, IMO. This behavior is
NOT suitable for a release, so I am setting the
severity at important, the highest level allowed
for end users. (see #994899, a bug affecting the
stable release, currently bullseye, for more details).
Ordinarily, as I understand the process, a bug in the
stable version is first fixed in the unstable release
and then the fix is migrated (backported) to the
stable release. But it appears to me a fix in the
unstable release will not be forthcoming soon, or
it might be a different bug (see #991967, affecting the
unstable release, sid, for more details).
This bug in the stable release is a special case
in which the ordinary process of fixing in unstable
first is not applicable. Currently our package of
xen-hypervisor-4.14-amd64 for the stable
release has a series of patches from the Xen-4.16
upstream UNSTABLE branch in it. The entries from
the changelog are:
* Pick the following upstream commits to improve Raspberry Pi 4 support,
requested by Elliott Mitchell:
- 25849c8b16 ("xen/rpi4: implement watchdog-based reset")
- 17d192e023 ("tools/python: Pass linker to Python build process")
- 861f0c1109 ("xen/arm: acpi: Don't fail if SPCR table is absent")
- 1c4aa69ca1 ("xen/acpi: Rework acpi_os_map_memory() and
acpi_os_unmap_memory()")
- 4d625ff3c3 ("xen/arm: acpi: The fixmap area should always be cleared
during failure/unmap")
- dac867bf9a ("xen/arm: Check if the platform is not using ACPI before
initializing Dom0less")
- 9c2bc0f24b ("xen/arm: Introduce fw_unreserved_regions() and use it")
- 7056f2f89f ("xen/arm: acpi: add BAD_MADT_GICC_ENTRY() macro")
- 957708c2d1 ("xen/arm: traps: Don't panic when receiving an
unknown debug
trap")
...
-- Hans van Kranenburg <hans@knorrie.org> Tue, 15 Dec 2020 13:00:00 +0100
I identified these patches in the stable package as the
cause of #994899 on my hardware (amd64).
But they are needed for better support for Raspberry
Pi 4 (arm64) support, so the package maintainer
(Debian Xen Team) wants to keep them in all our
Xen-4.14 packages in all releases, including the stable
release, as far as I can tell.
IMHO, there is NO PLACE for a series of patches from
an UNSTABLE upstream branch in a Debian package of the
upstream STABLE version that targets our STABLE release.
This is equivalent to a dependency on an upstream
unstable version of a package which, I presume, is
against Debian policy for the stable release. But that
is exactly what we have in this bug, which causes
the dom0 to not power off at shutdown on amd64
(and probably also on i386), and introduces unknown
security risks (I already notified the security team
about this issue in a private email).
There is NO EVIDENCE any effort was made by Debian
to test the ABI compatibility of the cherry-picked patches
from the Xen 4.16 unstable branch with the Xen 4.14
stable branch which is what is advertised as the version of
Xen Debian has packaged for stable, testing, and sid.
I have proposed a compromise solution.
I suggested shipping a version for the
stable release that omits the aforementioned nine
upstream patches from the build on amd64|i386 but
keeps them for the other architectures so the improved
support for the Raspberry Pi 4 can be retained:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899#5
This compromise would allow the unstable patches,
which are only needed on arm, to remain in the stable
release to improve support for the Raspberry Pi 4,
and it would fix #994899 and make bullseye (IMHO)
more stable by removing the unstable patches from
the amd64|i386 builds where they are NOT needed to
support the Raspberry Pi 4. The arm builds would not
be affected at all by my proposed compromise, but
possible instabilities on arm would remain with the
benefit of improved Raspberry Pi 4 support.
The patch to implement this proposal is at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899#67
and the debdiff (bug#994899.diff) against
xen_4.14.3-1~deb11u1 is also provided here as an attachment.
Special instructions for applying the debdiff:
1. Download the attached debdiff, bug#994899.diff, into a working directory
Then in the working directory with the attached bug#994899.diff and the
archived/compressed source file archives for xen_4.14.3-1~deb11u1 in it:
2. dpkg-source -x xen_4.14.3-1~deb11u1.dsc
3. cd xen-4.14.3
4. quilt pop -a
5. patch -p1 < ../bug#994899.diff
6. quilt push -a
After these 6 steps, the tree is ready
to build the source/binary packages.
Patch tested on: Native amd64 build
I am just a user, not a developer, so I could only test
the patch on my amd64 system for the amd64 package.
Other architectures (i386, arm64, etc.) and
crossbuilding (if this package is crossbuilt on
buildd) need to be tested/verified before uploading.
If you upload this patch (or another patch that does the same)
you can close this bug and #994899.
For more information about this problem, please see the
messages in #994899:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899
and in #991967:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967
All the best,
Chuck Zmudzinski
diff -Nru xen-4.14.3/debian/changelog xen-4.14.3/debian/changelog
--- xen-4.14.3/debian/changelog 2021-09-13 10:28:21.000000000 -0400
+++ xen-4.14.3/debian/changelog 2021-09-27 11:51:02.000000000 -0400
@@ -1,3 +1,12 @@
+xen (4.14.3-1~deb11u1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches - move RPI4 patches into a separate directory
+ * debian/rules - disable RPI4 patches on amd64|i386 to fix #994899
+ * debian/control - add Build Dependency quilt
+
+ -- Chuck Zmudzinski <brchuckz@netscape.net> Mon, 27 Sep 2021 11:51:04 -0400
+
xen (4.14.3-1~deb11u1) bullseye-security; urgency=medium
* Rebuild for bullseye-security
diff -Nru xen-4.14.3/debian/control xen-4.14.3/debian/control
--- xen-4.14.3/debian/control 2021-07-10 08:01:39.000000000 -0400
+++ xen-4.14.3/debian/control 2021-09-26 22:21:51.000000000 -0400
@@ -34,6 +34,7 @@
markdown,
ocaml-native-compilers | ocaml-nox,
ocaml-findlib,
+ quilt,
Homepage: https://xenproject.org/
Vcs-Browser: https://salsa.debian.org/xen-team/debian-xen
Vcs-Git: https://salsa.debian.org/xen-team/debian-xen.git
diff -Nru xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
--- xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch 1969-12-31 19:00:00.000000000 -0500
@@ -1,105 +0,0 @@
-From: Stefano Stabellini <sstabellini@kernel.org>
-Date: Fri, 2 Oct 2020 13:47:17 -0700
-Subject: xen/rpi4: implement watchdog-based reset
-
-The preferred method to reboot RPi4 is PSCI. If it is not available,
-touching the watchdog is required to be able to reboot the board.
-
-The implementation is based on
-drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux v5.9-rc7.
-
-Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
-Acked-by: Julien Grall <jgrall@amazon.com>
-Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
-Tested-by: Roman Shaposhnik <roman@zededa.com>
-CC: roman@zededa.com
-(cherry picked from commit 25849c8b16f2a5b7fcd0a823e80a5f1b590291f9)
----
- xen/arch/arm/platforms/brcm-raspberry-pi.c | 61 ++++++++++++++++++++++++++++++
- 1 file changed, 61 insertions(+)
-
-diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c b/xen/arch/arm/platforms/brcm-raspberry-pi.c
-index f5ae58a..811b40b 100644
---- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
-+++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
-@@ -17,6 +17,10 @@
- * GNU General Public License for more details.
- */
-
-+#include <xen/delay.h>
-+#include <xen/mm.h>
-+#include <xen/vmap.h>
-+#include <asm/io.h>
- #include <asm/platform.h>
-
- static const char *const rpi4_dt_compat[] __initconst =
-@@ -37,12 +41,69 @@ static const struct dt_device_match rpi4_blacklist_dev[] __initconst =
- * The aux peripheral also shares a page with the aux UART.
- */
- DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"),
-+ /* Special device used for rebooting */
-+ DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"),
- { /* sentinel */ },
- };
-
-+
-+#define PM_PASSWORD 0x5a000000
-+#define PM_RSTC 0x1c
-+#define PM_WDOG 0x24
-+#define PM_RSTC_WRCFG_FULL_RESET 0x00000020
-+#define PM_RSTC_WRCFG_CLR 0xffffffcf
-+
-+static void __iomem *rpi4_map_watchdog(void)
-+{
-+ void __iomem *base;
-+ struct dt_device_node *node;
-+ paddr_t start, len;
-+ int ret;
-+
-+ node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm");
-+ if ( !node )
-+ return NULL;
-+
-+ ret = dt_device_get_address(node, 0, &start, &len);
-+ if ( ret )
-+ {
-+ printk("Cannot read watchdog register address\n");
-+ return NULL;
-+ }
-+
-+ base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE);
-+ if ( !base )
-+ {
-+ printk("Unable to map watchdog register!\n");
-+ return NULL;
-+ }
-+
-+ return base;
-+}
-+
-+static void rpi4_reset(void)
-+{
-+ uint32_t val;
-+ void __iomem *base = rpi4_map_watchdog();
-+
-+ if ( !base )
-+ return;
-+
-+ /* use a timeout of 10 ticks (~150us) */
-+ writel(10 | PM_PASSWORD, base + PM_WDOG);
-+ val = readl(base + PM_RSTC);
-+ val &= PM_RSTC_WRCFG_CLR;
-+ val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
-+ writel(val, base + PM_RSTC);
-+
-+ /* No sleeping, possibly atomic. */
-+ mdelay(1);
-+}
-+
- PLATFORM_START(rpi4, "Raspberry Pi 4")
- .compatible = rpi4_dt_compat,
- .blacklist_dev = rpi4_blacklist_dev,
-+ .reset = rpi4_reset,
- .dma_bitsize = 30,
- PLATFORM_END
-
diff -Nru xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch
--- xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch 1969-12-31 19:00:00.000000000 -0500
@@ -1,91 +0,0 @@
-From: Elliott Mitchell <ehem+xen@m5p.com>
-Date: Sun, 11 Oct 2020 18:11:39 -0700
-Subject: tools/python: Pass linker to Python build process
-MIME-Version: 1.0
-Content-Type: text/plain; charset="utf-8"
-Content-Transfer-Encoding: 8bit
-
-Unexpectedly the environment variable which needs to be passed is
-$LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
-of the host `ld`.
-
-Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects
-it can load at runtime, not executables.
-
-This uses $(CC) instead of $(LD) since Python distutils appends $CFLAGS
-to $LDFLAGS which breaks many linkers.
-
-Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
-Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
-(cherry picked from commit 17d192e0238d6c714e9f04593b59597b7090be38)
-
-[ Hans van Kranenburg ]
-Fixed cherry-pick conflict because we have LIBEXEC_LIB=$(LIBEXEC_LIB) in
-between in the same lines. The line wrap mess makes it a bit hard to
-follow.
----
- tools/pygrub/Makefile | 11 ++++++-----
- tools/python/Makefile | 9 +++++----
- 2 files changed, 11 insertions(+), 9 deletions(-)
-
-diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
-index 4cd1a95..2950f37 100644
---- a/tools/pygrub/Makefile
-+++ b/tools/pygrub/Makefile
-@@ -3,21 +3,22 @@ XEN_ROOT = $(CURDIR)/../..
- include $(XEN_ROOT)/tools/Rules.mk
-
- PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
--PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
-+PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
- INSTALL_LOG = build/installed_files.txt
-
- .PHONY: all
- all: build
- .PHONY: build
- build:
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py build
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" \
-+ LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py build
-
- .PHONY: install
- install: all
- $(INSTALL_DIR) $(DESTDIR)/$(bindir)
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" \
-- LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) \
-- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" \
-+ LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py install \
-+ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
- --root="$(DESTDIR)" --install-scripts=$(LIBEXEC_BIN) --force
- set -e; if [ $(bindir) != $(LIBEXEC_BIN) -a \
- "`readlink -f $(DESTDIR)/$(bindir)`" != \
-diff --git a/tools/python/Makefile b/tools/python/Makefile
-index 8d22c03..b675f5b 100644
---- a/tools/python/Makefile
-+++ b/tools/python/Makefile
-@@ -5,19 +5,20 @@ include $(XEN_ROOT)/tools/Rules.mk
- all: build
-
- PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
--PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
-+PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
- INSTALL_LOG = build/installed_files.txt
-
- .PHONY: build
- build:
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py build
-
- .PHONY: install
- install:
- $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) \
-- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" \
-+ LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py install \
-+ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
- --root="$(DESTDIR)" --force
-
- $(INSTALL_PYTHON_PROG) scripts/convert-legacy-stream $(DESTDIR)$(LIBEXEC_BIN)
diff -Nru xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
--- xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch 1969-12-31 19:00:00.000000000 -0500
@@ -1,47 +0,0 @@
-From: Elliott Mitchell <ehem+xen@m5p.com>
-Date: Wed, 21 Oct 2020 15:12:53 -0700
-Subject: xen/arm: acpi: Don't fail if SPCR table is absent
-
-Absence of a SPCR table likely means the console is a framebuffer. In
-such case acpi_iomem_deny_access() should NOT fail.
-
-Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
-Acked-by: Julien Grall <jgrall@amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-(cherry picked from commit 861f0c110976fa8879b7bf63d9478b6be83d4ab6)
----
- xen/arch/arm/acpi/domain_build.c | 19 ++++++++++---------
- 1 file changed, 10 insertions(+), 9 deletions(-)
-
-diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
-index 1b1cfab..bbdc90f 100644
---- a/xen/arch/arm/acpi/domain_build.c
-+++ b/xen/arch/arm/acpi/domain_build.c
-@@ -42,17 +42,18 @@ static int __init acpi_iomem_deny_access(struct domain *d)
- status = acpi_get_table(ACPI_SIG_SPCR, 0,
- (struct acpi_table_header **)&spcr);
-
-- if ( ACPI_FAILURE(status) )
-+ if ( ACPI_SUCCESS(status) )
- {
-- printk("Failed to get SPCR table\n");
-- return -EINVAL;
-+ mfn = spcr->serial_port.address >> PAGE_SHIFT;
-+ /* Deny MMIO access for UART */
-+ rc = iomem_deny_access(d, mfn, mfn + 1);
-+ if ( rc )
-+ return rc;
-+ }
-+ else
-+ {
-+ printk("Failed to get SPCR table, Xen console may be unavailable\n");
- }
--
-- mfn = spcr->serial_port.address >> PAGE_SHIFT;
-- /* Deny MMIO access for UART */
-- rc = iomem_deny_access(d, mfn, mfn + 1);
-- if ( rc )
-- return rc;
-
- /* Deny MMIO access for GIC regions */
- return gic_iomem_deny_access(d);
diff -Nru xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
--- xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch 1969-12-31 19:00:00.000000000 -0500
@@ -1,163 +0,0 @@
-From: Julien Grall <jgrall@amazon.com>
-Date: Sat, 26 Sep 2020 17:44:29 +0100
-Subject: xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()
-
-The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
-while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
-
-Currently, the former are still containing x86 specific code.
-
-To avoid this rather strange split, the generic helpers are reworked so
-they are arch-agnostic. This requires the introduction of a new helper
-__acpi_os_unmap_memory() that will undo any mapping done by
-__acpi_os_map_memory().
-
-Currently, the arch-helper for unmap is basically a no-op so it only
-returns whether the mapping was arch specific. But this will change
-in the future.
-
-Note that the x86 version of acpi_os_map_memory() was already able to
-able the 1MB region. Hence why there is no addition of new code.
-
-Signed-off-by: Julien Grall <jgrall@amazon.com>
-Reviewed-by: Rahul Singh <rahul.singh@arm.com>
-Reviewed-by: Jan Beulich <jbeulich@suse.com>
-Acked-by: Stefano Stabellini <sstabellini@kernel.org>
-Tested-by: Rahul Singh <rahul.singh@arm.com>
-Tested-by: Elliott Mitchell <ehem+xen@m5p.com>
-(cherry picked from commit 1c4aa69ca1e1fad20b2158051eb152276d1eb973)
----
- xen/arch/arm/acpi/lib.c | 12 ++++++++++++
- xen/arch/x86/acpi/lib.c | 18 ++++++++++++++++++
- xen/drivers/acpi/osl.c | 34 ++++++++++++++++++----------------
- xen/include/xen/acpi.h | 1 +
- 4 files changed, 49 insertions(+), 16 deletions(-)
-
-diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
-index 4fc6e17..fcc186b 100644
---- a/xen/arch/arm/acpi/lib.c
-+++ b/xen/arch/arm/acpi/lib.c
-@@ -30,6 +30,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- unsigned long base, offset, mapped_size;
- int idx;
-
-+ /* No arch specific implementation after early boot */
-+ if ( system_state >= SYS_STATE_boot )
-+ return NULL;
-+
- offset = phys & (PAGE_SIZE - 1);
- mapped_size = PAGE_SIZE - offset;
- set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
-@@ -49,6 +53,14 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- return ((char *) base + offset);
- }
-
-+bool __acpi_unmap_table(const void *ptr, unsigned long size)
-+{
-+ vaddr_t vaddr = (vaddr_t)ptr;
-+
-+ return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
-+ (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
-+}
-+
- /* True to indicate PSCI 0.2+ is implemented */
- bool __init acpi_psci_present(void)
- {
-diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
-index 265b9ad..a22414a 100644
---- a/xen/arch/x86/acpi/lib.c
-+++ b/xen/arch/x86/acpi/lib.c
-@@ -46,6 +46,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- if ((phys + size) <= (1 * 1024 * 1024))
- return __va(phys);
-
-+ /* No further arch specific implementation after early boot */
-+ if (system_state >= SYS_STATE_boot)
-+ return NULL;
-+
- offset = phys & (PAGE_SIZE - 1);
- mapped_size = PAGE_SIZE - offset;
- set_fixmap(FIX_ACPI_END, phys);
-@@ -66,6 +70,20 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- return ((char *) base + offset);
- }
-
-+bool __acpi_unmap_table(const void *ptr, unsigned long size)
-+{
-+ unsigned long vaddr = (unsigned long)ptr;
-+
-+ if ((vaddr >= DIRECTMAP_VIRT_START) &&
-+ (vaddr < DIRECTMAP_VIRT_END)) {
-+ ASSERT(!((__pa(ptr) + size - 1) >> 20));
-+ return true;
-+ }
-+
-+ return ((vaddr >= __fix_to_virt(FIX_ACPI_END)) &&
-+ (vaddr < (__fix_to_virt(FIX_ACPI_BEGIN) + PAGE_SIZE)));
-+}
-+
- unsigned int acpi_get_processor_id(unsigned int cpu)
- {
- unsigned int acpiid, apicid;
-diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
-index 4c8bb78..389505f 100644
---- a/xen/drivers/acpi/osl.c
-+++ b/xen/drivers/acpi/osl.c
-@@ -92,27 +92,29 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
- void __iomem *
- acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
- {
-- if (system_state >= SYS_STATE_boot) {
-- mfn_t mfn = _mfn(PFN_DOWN(phys));
-- unsigned int offs = phys & (PAGE_SIZE - 1);
--
-- /* The low first Mb is always mapped on x86. */
-- if (IS_ENABLED(CONFIG_X86) && !((phys + size - 1) >> 20))
-- return __va(phys);
-- return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
-- ACPI_MAP_MEM_ATTR, VMAP_DEFAULT) + offs;
-- }
-- return __acpi_map_table(phys, size);
-+ void *ptr;
-+ mfn_t mfn = _mfn(PFN_DOWN(phys));
-+ unsigned int offs = PAGE_OFFSET(phys);
-+
-+ /* Try the arch specific implementation first */
-+ ptr = __acpi_map_table(phys, size);
-+ if (ptr)
-+ return ptr;
-+
-+ /* No common implementation for early boot map */
-+ if (unlikely(system_state < SYS_STATE_boot))
-+ return NULL;
-+
-+ ptr = __vmap(&mfn, PFN_UP(offs + size), 1, 1,
-+ ACPI_MAP_MEM_ATTR, VMAP_DEFAULT);
-+
-+ return !ptr ? NULL : (ptr + offs);
- }
-
- void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
- {
-- if (IS_ENABLED(CONFIG_X86) &&
-- (unsigned long)virt >= DIRECTMAP_VIRT_START &&
-- (unsigned long)virt < DIRECTMAP_VIRT_END) {
-- ASSERT(!((__pa(virt) + size - 1) >> 20));
-+ if (__acpi_unmap_table(virt, size))
- return;
-- }
-
- if (system_state >= SYS_STATE_boot)
- vunmap((void *)((unsigned long)virt & PAGE_MASK));
-diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
-index c945ab0..21d5e9f 100644
---- a/xen/include/xen/acpi.h
-+++ b/xen/include/xen/acpi.h
-@@ -68,6 +68,7 @@ typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, co
-
- unsigned int acpi_get_processor_id (unsigned int cpu);
- char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
-+bool __acpi_unmap_table(const void *ptr, unsigned long size);
- int acpi_boot_init (void);
- int acpi_boot_table_init (void);
- int acpi_numa_init (void);
diff -Nru xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
--- xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch 1969-12-31 19:00:00.000000000 -0500
@@ -1,131 +0,0 @@
-From: Julien Grall <jgrall@amazon.com>
-Date: Sat, 26 Sep 2020 19:53:27 +0100
-Subject: xen/arm: acpi: The fixmap area should always be cleared during
- failure/unmap
-
-Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
-{set, clear}_fixmap()" enforced that each set_fixmap() should be
-paired with a clear_fixmap(). Any failure to follow the model would
-result to a platform crash.
-
-Unfortunately, the use of fixmap in the ACPI code was overlooked as it
-is calling set_fixmap() but not clear_fixmap().
-
-The function __acpi_os_map_table() is reworked so:
- - We know before the mapping whether the fixmap region is big
- enough for the mapping.
- - It will fail if the fixmap is already in use. This is not a
- change of behavior but clarifying the current expectation to avoid
- hitting a BUG().
-
-The function __acpi_os_unmap_table() will now call clear_fixmap().
-
-Reported-by: Wei Xu <xuwei5@hisilicon.com>
-Signed-off-by: Julien Grall <jgrall@amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-(cherry picked from commit 4d625ff3c3a939dc270b03654337568c30c5ab6e)
----
- xen/arch/arm/acpi/lib.c | 73 +++++++++++++++++++++++++++++++++++++------------
- 1 file changed, 56 insertions(+), 17 deletions(-)
-
-diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
-index fcc186b..a59cc40 100644
---- a/xen/arch/arm/acpi/lib.c
-+++ b/xen/arch/arm/acpi/lib.c
-@@ -25,40 +25,79 @@
- #include <xen/init.h>
- #include <xen/mm.h>
-
-+static bool fixmap_inuse;
-+
- char *__acpi_map_table(paddr_t phys, unsigned long size)
- {
-- unsigned long base, offset, mapped_size;
-- int idx;
-+ unsigned long base, offset;
-+ mfn_t mfn;
-+ unsigned int idx;
-
- /* No arch specific implementation after early boot */
- if ( system_state >= SYS_STATE_boot )
- return NULL;
-
- offset = phys & (PAGE_SIZE - 1);
-- mapped_size = PAGE_SIZE - offset;
-- set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
-- base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
-+ base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) + offset;
-+
-+ /* Check the fixmap is big enough to map the region */
-+ if ( (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - base) < size )
-+ return NULL;
-+
-+ /* With the fixmap, we can only map one region at the time */
-+ if ( fixmap_inuse )
-+ return NULL;
-
-- /* Most cases can be covered by the below. */
-+ fixmap_inuse = true;
-+
-+ size += offset;
-+ mfn = maddr_to_mfn(phys);
- idx = FIXMAP_ACPI_BEGIN;
-- while ( mapped_size < size )
-- {
-- if ( ++idx > FIXMAP_ACPI_END )
-- return NULL; /* cannot handle this */
-- phys += PAGE_SIZE;
-- set_fixmap(idx, maddr_to_mfn(phys), PAGE_HYPERVISOR);
-- mapped_size += PAGE_SIZE;
-- }
-
-- return ((char *) base + offset);
-+ do {
-+ set_fixmap(idx, mfn, PAGE_HYPERVISOR);
-+ size -= min(size, (unsigned long)PAGE_SIZE);
-+ mfn = mfn_add(mfn, 1);
-+ idx++;
-+ } while ( size > 0 );
-+
-+ return (char *)base;
- }
-
- bool __acpi_unmap_table(const void *ptr, unsigned long size)
- {
- vaddr_t vaddr = (vaddr_t)ptr;
-+ unsigned int idx;
-+
-+ /* We are only handling fixmap address in the arch code */
-+ if ( (vaddr < FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) ||
-+ (vaddr >= (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)) )
-+ return false;
-+
-+ /*
-+ * __acpi_map_table() will always return a pointer in the first page
-+ * for the ACPI fixmap region. The caller is expected to free with
-+ * the same address.
-+ */
-+ ASSERT((vaddr & PAGE_MASK) == FIXMAP_ADDR(FIXMAP_ACPI_BEGIN));
-+
-+ /* The region allocated fit in the ACPI fixmap region. */
-+ ASSERT(size < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - vaddr));
-+ ASSERT(fixmap_inuse);
-+
-+ fixmap_inuse = false;
-+
-+ size += vaddr - FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
-+ idx = FIXMAP_ACPI_BEGIN;
-+
-+ do
-+ {
-+ clear_fixmap(idx);
-+ size -= min(size, (unsigned long)PAGE_SIZE);
-+ idx++;
-+ } while ( size > 0 );
-
-- return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
-- (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
-+ return true;
- }
-
- /* True to indicate PSCI 0.2+ is implemented */
diff -Nru xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
--- xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch 1969-12-31 19:00:00.000000000 -0500
@@ -1,39 +0,0 @@
-From: Julien Grall <jgrall@amazon.com>
-Date: Sat, 26 Sep 2020 21:16:55 +0100
-Subject: xen/arm: Check if the platform is not using ACPI before initializing
- Dom0less
-
-Dom0less requires a device-tree. However, since commit 6e3e77120378
-"xen/arm: setup: Relocate the Device-Tree later on in the boot", the
-device-tree will not get unflatten when using ACPI.
-
-This will lead to a crash during boot.
-
-Given the complexity to setup dom0less with ACPI (for instance how to
-assign device?), we should skip any code related to Dom0less when using
-ACPI.
-
-Signed-off-by: Julien Grall <jgrall@amazon.com>
-Tested-by: Rahul Singh <rahul.singh@arm.com>
-Reviewed-by: Rahul Singh <rahul.singh@arm.com>
-Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-Tested-by: Elliott Mitchell <ehem+xen@m5p.com>
-(cherry picked from commit dac867bf9adc1562a4cf9db5f89726597af13ef8)
----
- xen/arch/arm/setup.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
-index 34b1c1a..fb2f45e 100644
---- a/xen/arch/arm/setup.c
-+++ b/xen/arch/arm/setup.c
-@@ -961,7 +961,8 @@ void __init start_xen(unsigned long boot_phys_offset,
- if ( construct_dom0(dom0) != 0)
- panic("Could not set up DOM0 guest OS\n");
-
-- create_domUs();
-+ if ( acpi_disabled )
-+ create_domUs();
-
- /*
- * This needs to be called **before** heap_init_late() so modules
diff -Nru xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
--- xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch 1969-12-31 19:00:00.000000000 -0500
@@ -1,124 +0,0 @@
-From: Julien Grall <jgrall@amazon.com>
-Date: Sat, 26 Sep 2020 21:30:14 +0100
-Subject: xen/arm: Introduce fw_unreserved_regions() and use it
-
-Since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree
-later on in the boot", the device-tree will not be kept mapped when
-using ACPI.
-
-However, a few places are calling dt_unreserved_regions() which expects
-a valid DT. This will lead to a crash.
-
-As the DT should not be used for ACPI (other than for detecting the
-modules), a new function fw_unreserved_regions() is introduced.
-
-It will behave the same way on DT system. On ACPI system, it will
-unreserve the whole region.
-
-Take the opportunity to clarify that bootinfo.reserved_mem is only used
-when booting using Device-Tree.
-
-Signed-off-by: Julien Grall <jgrall@amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-(cherry picked from commit 9c2bc0f24b2ba7082df408b3c33ec9a86bf20cf0)
----
- xen/arch/arm/kernel.c | 2 +-
- xen/arch/arm/setup.c | 22 +++++++++++++++++-----
- xen/include/asm-arm/setup.h | 3 ++-
- 3 files changed, 20 insertions(+), 7 deletions(-)
-
-diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
-index 8eff074..27dace0 100644
---- a/xen/arch/arm/kernel.c
-+++ b/xen/arch/arm/kernel.c
-@@ -307,7 +307,7 @@ static __init int kernel_decompress(struct bootmodule *mod)
- * Free the original kernel, update the pointers to the
- * decompressed kernel
- */
-- dt_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
-+ fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
-
- return 0;
- }
-diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
-index fb2f45e..c94827e 100644
---- a/xen/arch/arm/setup.c
-+++ b/xen/arch/arm/setup.c
-@@ -183,8 +183,9 @@ static void __init processor_id(void)
- processor_setup();
- }
-
--void __init dt_unreserved_regions(paddr_t s, paddr_t e,
-- void (*cb)(paddr_t, paddr_t), int first)
-+static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
-+ void (*cb)(paddr_t, paddr_t),
-+ int first)
- {
- int i, nr = fdt_num_mem_rsv(device_tree_flattened);
-
-@@ -231,6 +232,17 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
- cb(s, e);
- }
-
-+void __init fw_unreserved_regions(paddr_t s, paddr_t e,
-+ void (*cb)(paddr_t, paddr_t), int first)
-+{
-+ if ( acpi_disabled )
-+ dt_unreserved_regions(s, e, cb, first);
-+ else
-+ cb(s, e);
-+}
-+
-+
-+
- struct bootmodule __init *add_boot_module(bootmodule_kind kind,
- paddr_t start, paddr_t size,
- bool domU)
-@@ -392,7 +404,7 @@ void __init discard_initial_modules(void)
- !mfn_valid(maddr_to_mfn(e)) )
- continue;
-
-- dt_unreserved_regions(s, e, init_domheap_pages, 0);
-+ fw_unreserved_regions(s, e, init_domheap_pages, 0);
- }
-
- mi->nr_mods = 0;
-@@ -699,7 +711,7 @@ static void __init setup_mm(void)
- n = mfn_to_maddr(mfn_add(xenheap_mfn_start, xenheap_pages));
- }
-
-- dt_unreserved_regions(s, e, init_boot_pages, 0);
-+ fw_unreserved_regions(s, e, init_boot_pages, 0);
-
- s = n;
- }
-@@ -752,7 +764,7 @@ static void __init setup_mm(void)
- if ( e > bank_end )
- e = bank_end;
-
-- dt_unreserved_regions(s, e, init_boot_pages, 0);
-+ fw_unreserved_regions(s, e, init_boot_pages, 0);
- s = n;
- }
- }
-diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
-index 2f8f24e..28bf622 100644
---- a/xen/include/asm-arm/setup.h
-+++ b/xen/include/asm-arm/setup.h
-@@ -67,6 +67,7 @@ struct bootcmdlines {
-
- struct bootinfo {
- struct meminfo mem;
-+ /* The reserved regions are only used when booting using Device-Tree */
- struct meminfo reserved_mem;
- struct bootmodules modules;
- struct bootcmdlines cmdlines;
-@@ -96,7 +97,7 @@ int construct_dom0(struct domain *d);
- void create_domUs(void);
-
- void discard_initial_modules(void);
--void dt_unreserved_regions(paddr_t s, paddr_t e,
-+void fw_unreserved_regions(paddr_t s, paddr_t e,
- void (*cb)(paddr_t, paddr_t), int first);
-
- size_t boot_fdt_info(const void *fdt, paddr_t paddr);
diff -Nru xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
--- xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch 1969-12-31 19:00:00.000000000 -0500
@@ -1,60 +0,0 @@
-From: Julien Grall <julien.grall@arm.com>
-Date: Wed, 30 Sep 2020 12:25:04 +0100
-Subject: xen/arm: acpi: add BAD_MADT_GICC_ENTRY() macro
-
-Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6:
-
- The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
- of the MADT. In the ACPI 5.1 version of the spec, the struct for the
- GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
- ACPI 6.0, the struct is 80 bytes long. But, there is only one definition
- in ACPICA for this struct -- and that is the 6.0 version. Hence, when
- BAD_MADT_ENTRY() compares the struct size to the length in the GICC
- subtable, it fails if 5.1 structs are in use, and there are systems in
- the wild that have them.
-
- This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable
- only, accounting for the difference in specification versions that are
- possible. The BAD_MADT_ENTRY() will continue to work as is for all other
- MADT subtables.
-
- This code is being added to an arm64 header file since that is currently
- the only architecture using the GICC subtable of the MADT. As a GIC is
- specific to ARM, it is also unlikely the subtable will be used elsewhere.
-
- Fixes: aeb823bbacc2 ("ACPICA: ACPI 6.0: Add changes for FADT table.")
- Signed-off-by: Al Stone <al.stone@linaro.org>
- Acked-by: Will Deacon <will.deacon@arm.com>
- Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
- [catalin.marinas@arm.com: extra brackets around macro arguments]
- Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
-
-Signed-off-by: Julien Grall <julien.grall@arm.com>
-Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-Signed-off-by: Julien Grall <jgrall@amazon.com>
-Acked-by: Stefano Stabellini <sstabellini@kernel.org>
-Tested-by: Elliott Mitchell <ehem+xen@m5p.com>
-(cherry picked from commit 7056f2f89f03f2f804ac7e776c7b2b000cd716cd)
----
- xen/include/asm-arm/acpi.h | 8 ++++++++
- 1 file changed, 8 insertions(+)
-
-diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
-index 5034028..b52ae2d 100644
---- a/xen/include/asm-arm/acpi.h
-+++ b/xen/include/asm-arm/acpi.h
-@@ -54,6 +54,14 @@ void acpi_smp_init_cpus(void);
- */
- paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index);
-
-+/* Macros for consistency checks of the GICC subtable of MADT */
-+#define ACPI_MADT_GICC_LENGTH \
-+ (acpi_gbl_FADT.header.revision < 6 ? 76 : 80)
-+
-+#define BAD_MADT_GICC_ENTRY(entry, end) \
-+ (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \
-+ (entry)->header.length != ACPI_MADT_GICC_LENGTH)
-+
- #ifdef CONFIG_ACPI
- extern bool acpi_disabled;
- /* Basic configuration for ACPI */
diff -Nru xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
--- xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch 1969-12-31 19:00:00.000000000 -0500
@@ -1,29 +0,0 @@
-From: Julien Grall <jgrall@amazon.com>
-Date: Thu, 5 Nov 2020 22:31:06 +0000
-Subject: xen/arm: traps: Don't panic when receiving an unknown debug trap
-
-Even if debug trap are only meant for debugging purpose, it is quite
-harsh to crash Xen if one of the trap sent by the guest is not handled.
-
-So switch from a panic() to a printk().
-
-Signed-off-by: Julien Grall <jgrall@amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-(cherry picked from commit 957708c2d1ae25d7375abd5e5e70c3043d64f1f1)
----
- xen/arch/arm/traps.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
-index 2197df2..22bd1bd 100644
---- a/xen/arch/arm/traps.c
-+++ b/xen/arch/arm/traps.c
-@@ -1411,7 +1411,7 @@ static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
- show_execution_state(regs);
- break;
- default:
-- panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
-+ printk("DOM%d: Unhandled debug trap %#x\n", domid, code);
- break;
- }
- }
diff -Nru xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
--- xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch 1969-12-31 19:00:00.000000000 -0500
+++ xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch 2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,105 @@
+From: Stefano Stabellini <sstabellini@kernel.org>
+Date: Fri, 2 Oct 2020 13:47:17 -0700
+Subject: xen/rpi4: implement watchdog-based reset
+
+The preferred method to reboot RPi4 is PSCI. If it is not available,
+touching the watchdog is required to be able to reboot the board.
+
+The implementation is based on
+drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux v5.9-rc7.
+
+Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
+Acked-by: Julien Grall <jgrall@amazon.com>
+Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
+Tested-by: Roman Shaposhnik <roman@zededa.com>
+CC: roman@zededa.com
+(cherry picked from commit 25849c8b16f2a5b7fcd0a823e80a5f1b590291f9)
+---
+ xen/arch/arm/platforms/brcm-raspberry-pi.c | 61 ++++++++++++++++++++++++++++++
+ 1 file changed, 61 insertions(+)
+
+diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c b/xen/arch/arm/platforms/brcm-raspberry-pi.c
+index f5ae58a..811b40b 100644
+--- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
++++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
+@@ -17,6 +17,10 @@
+ * GNU General Public License for more details.
+ */
+
++#include <xen/delay.h>
++#include <xen/mm.h>
++#include <xen/vmap.h>
++#include <asm/io.h>
+ #include <asm/platform.h>
+
+ static const char *const rpi4_dt_compat[] __initconst =
+@@ -37,12 +41,69 @@ static const struct dt_device_match rpi4_blacklist_dev[] __initconst =
+ * The aux peripheral also shares a page with the aux UART.
+ */
+ DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"),
++ /* Special device used for rebooting */
++ DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"),
+ { /* sentinel */ },
+ };
+
++
++#define PM_PASSWORD 0x5a000000
++#define PM_RSTC 0x1c
++#define PM_WDOG 0x24
++#define PM_RSTC_WRCFG_FULL_RESET 0x00000020
++#define PM_RSTC_WRCFG_CLR 0xffffffcf
++
++static void __iomem *rpi4_map_watchdog(void)
++{
++ void __iomem *base;
++ struct dt_device_node *node;
++ paddr_t start, len;
++ int ret;
++
++ node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm");
++ if ( !node )
++ return NULL;
++
++ ret = dt_device_get_address(node, 0, &start, &len);
++ if ( ret )
++ {
++ printk("Cannot read watchdog register address\n");
++ return NULL;
++ }
++
++ base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE);
++ if ( !base )
++ {
++ printk("Unable to map watchdog register!\n");
++ return NULL;
++ }
++
++ return base;
++}
++
++static void rpi4_reset(void)
++{
++ uint32_t val;
++ void __iomem *base = rpi4_map_watchdog();
++
++ if ( !base )
++ return;
++
++ /* use a timeout of 10 ticks (~150us) */
++ writel(10 | PM_PASSWORD, base + PM_WDOG);
++ val = readl(base + PM_RSTC);
++ val &= PM_RSTC_WRCFG_CLR;
++ val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
++ writel(val, base + PM_RSTC);
++
++ /* No sleeping, possibly atomic. */
++ mdelay(1);
++}
++
+ PLATFORM_START(rpi4, "Raspberry Pi 4")
+ .compatible = rpi4_dt_compat,
+ .blacklist_dev = rpi4_blacklist_dev,
++ .reset = rpi4_reset,
+ .dma_bitsize = 30,
+ PLATFORM_END
+
diff -Nru xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
--- xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch 1969-12-31 19:00:00.000000000 -0500
+++ xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch 2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,91 @@
+From: Elliott Mitchell <ehem+xen@m5p.com>
+Date: Sun, 11 Oct 2020 18:11:39 -0700
+Subject: tools/python: Pass linker to Python build process
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Unexpectedly the environment variable which needs to be passed is
+$LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
+of the host `ld`.
+
+Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects
+it can load at runtime, not executables.
+
+This uses $(CC) instead of $(LD) since Python distutils appends $CFLAGS
+to $LDFLAGS which breaks many linkers.
+
+Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
+Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
+(cherry picked from commit 17d192e0238d6c714e9f04593b59597b7090be38)
+
+[ Hans van Kranenburg ]
+Fixed cherry-pick conflict because we have LIBEXEC_LIB=$(LIBEXEC_LIB) in
+between in the same lines. The line wrap mess makes it a bit hard to
+follow.
+---
+ tools/pygrub/Makefile | 11 ++++++-----
+ tools/python/Makefile | 9 +++++----
+ 2 files changed, 11 insertions(+), 9 deletions(-)
+
+diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
+index 4cd1a95..2950f37 100644
+--- a/tools/pygrub/Makefile
++++ b/tools/pygrub/Makefile
+@@ -3,21 +3,22 @@ XEN_ROOT = $(CURDIR)/../..
+ include $(XEN_ROOT)/tools/Rules.mk
+
+ PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
+-PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
++PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
+ INSTALL_LOG = build/installed_files.txt
+
+ .PHONY: all
+ all: build
+ .PHONY: build
+ build:
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py build
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" \
++ LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py build
+
+ .PHONY: install
+ install: all
+ $(INSTALL_DIR) $(DESTDIR)/$(bindir)
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" \
+- LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) \
+- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" \
++ LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py install \
++ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
+ --root="$(DESTDIR)" --install-scripts=$(LIBEXEC_BIN) --force
+ set -e; if [ $(bindir) != $(LIBEXEC_BIN) -a \
+ "`readlink -f $(DESTDIR)/$(bindir)`" != \
+diff --git a/tools/python/Makefile b/tools/python/Makefile
+index 8d22c03..b675f5b 100644
+--- a/tools/python/Makefile
++++ b/tools/python/Makefile
+@@ -5,19 +5,20 @@ include $(XEN_ROOT)/tools/Rules.mk
+ all: build
+
+ PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
+-PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
++PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
+ INSTALL_LOG = build/installed_files.txt
+
+ .PHONY: build
+ build:
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py build
+
+ .PHONY: install
+ install:
+ $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) \
+- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" \
++ LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py install \
++ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
+ --root="$(DESTDIR)" --force
+
+ $(INSTALL_PYTHON_PROG) scripts/convert-legacy-stream $(DESTDIR)$(LIBEXEC_BIN)
diff -Nru xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
--- xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch 1969-12-31 19:00:00.000000000 -0500
+++ xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch 2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,47 @@
+From: Elliott Mitchell <ehem+xen@m5p.com>
+Date: Wed, 21 Oct 2020 15:12:53 -0700
+Subject: xen/arm: acpi: Don't fail if SPCR table is absent
+
+Absence of a SPCR table likely means the console is a framebuffer. In
+such case acpi_iomem_deny_access() should NOT fail.
+
+Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
+Acked-by: Julien Grall <jgrall@amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
+(cherry picked from commit 861f0c110976fa8879b7bf63d9478b6be83d4ab6)
+---
+ xen/arch/arm/acpi/domain_build.c | 19 ++++++++++---------
+ 1 file changed, 10 insertions(+), 9 deletions(-)
+
+diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
+index 1b1cfab..bbdc90f 100644
+--- a/xen/arch/arm/acpi/domain_build.c
++++ b/xen/arch/arm/acpi/domain_build.c
+@@ -42,17 +42,18 @@ static int __init acpi_iomem_deny_access(struct domain *d)
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr);
+
+- if ( ACPI_FAILURE(status) )
++ if ( ACPI_SUCCESS(status) )
+ {
+- printk("Failed to get SPCR table\n");
+- return -EINVAL;
++ mfn = spcr->serial_port.address >> PAGE_SHIFT;
++ /* Deny MMIO access for UART */
++ rc = iomem_deny_access(d, mfn, mfn + 1);
++ if ( rc )
++ return rc;
++ }
++ else
++ {
++ printk("Failed to get SPCR table, Xen console may be unavailable\n");
+ }
+-
+- mfn = spcr->serial_port.address >> PAGE_SHIFT;
+- /* Deny MMIO access for UART */
+- rc = iomem_deny_access(d, mfn, mfn + 1);
+- if ( rc )
+- return rc;
+
+ /* Deny MMIO access for GIC regions */
+ return gic_iomem_deny_access(d);
diff -Nru xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
--- xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch 1969-12-31 19:00:00.000000000 -0500
+++ xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch 2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,163 @@
+From: Julien Grall <jgrall@amazon.com>
+Date: Sat, 26 Sep 2020 17:44:29 +0100
+Subject: xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()
+
+The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
+while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
+
+Currently, the former are still containing x86 specific code.
+
+To avoid this rather strange split, the generic helpers are reworked so
+they are arch-agnostic. This requires the introduction of a new helper
+__acpi_os_unmap_memory() that will undo any mapping done by
+__acpi_os_map_memory().
+
+Currently, the arch-helper for unmap is basically a no-op so it only
+returns whether the mapping was arch specific. But this will change
+in the future.
+
+Note that the x86 version of acpi_os_map_memory() was already able to
+able the 1MB region. Hence why there is no addition of new code.
+
+Signed-off-by: Julien Grall <jgrall@amazon.com>
+Reviewed-by: Rahul Singh <rahul.singh@arm.com>
+Reviewed-by: Jan Beulich <jbeulich@suse.com>
+Acked-by: Stefano Stabellini <sstabellini@kernel.org>
+Tested-by: Rahul Singh <rahul.singh@arm.com>
+Tested-by: Elliott Mitchell <ehem+xen@m5p.com>
+(cherry picked from commit 1c4aa69ca1e1fad20b2158051eb152276d1eb973)
+---
+ xen/arch/arm/acpi/lib.c | 12 ++++++++++++
+ xen/arch/x86/acpi/lib.c | 18 ++++++++++++++++++
+ xen/drivers/acpi/osl.c | 34 ++++++++++++++++++----------------
+ xen/include/xen/acpi.h | 1 +
+ 4 files changed, 49 insertions(+), 16 deletions(-)
+
+diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
+index 4fc6e17..fcc186b 100644
+--- a/xen/arch/arm/acpi/lib.c
++++ b/xen/arch/arm/acpi/lib.c
+@@ -30,6 +30,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ unsigned long base, offset, mapped_size;
+ int idx;
+
++ /* No arch specific implementation after early boot */
++ if ( system_state >= SYS_STATE_boot )
++ return NULL;
++
+ offset = phys & (PAGE_SIZE - 1);
+ mapped_size = PAGE_SIZE - offset;
+ set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
+@@ -49,6 +53,14 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ return ((char *) base + offset);
+ }
+
++bool __acpi_unmap_table(const void *ptr, unsigned long size)
++{
++ vaddr_t vaddr = (vaddr_t)ptr;
++
++ return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
++ (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
++}
++
+ /* True to indicate PSCI 0.2+ is implemented */
+ bool __init acpi_psci_present(void)
+ {
+diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
+index 265b9ad..a22414a 100644
+--- a/xen/arch/x86/acpi/lib.c
++++ b/xen/arch/x86/acpi/lib.c
+@@ -46,6 +46,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ if ((phys + size) <= (1 * 1024 * 1024))
+ return __va(phys);
+
++ /* No further arch specific implementation after early boot */
++ if (system_state >= SYS_STATE_boot)
++ return NULL;
++
+ offset = phys & (PAGE_SIZE - 1);
+ mapped_size = PAGE_SIZE - offset;
+ set_fixmap(FIX_ACPI_END, phys);
+@@ -66,6 +70,20 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ return ((char *) base + offset);
+ }
+
++bool __acpi_unmap_table(const void *ptr, unsigned long size)
++{
++ unsigned long vaddr = (unsigned long)ptr;
++
++ if ((vaddr >= DIRECTMAP_VIRT_START) &&
++ (vaddr < DIRECTMAP_VIRT_END)) {
++ ASSERT(!((__pa(ptr) + size - 1) >> 20));
++ return true;
++ }
++
++ return ((vaddr >= __fix_to_virt(FIX_ACPI_END)) &&
++ (vaddr < (__fix_to_virt(FIX_ACPI_BEGIN) + PAGE_SIZE)));
++}
++
+ unsigned int acpi_get_processor_id(unsigned int cpu)
+ {
+ unsigned int acpiid, apicid;
+diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
+index 4c8bb78..389505f 100644
+--- a/xen/drivers/acpi/osl.c
++++ b/xen/drivers/acpi/osl.c
+@@ -92,27 +92,29 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
+ void __iomem *
+ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+ {
+- if (system_state >= SYS_STATE_boot) {
+- mfn_t mfn = _mfn(PFN_DOWN(phys));
+- unsigned int offs = phys & (PAGE_SIZE - 1);
+-
+- /* The low first Mb is always mapped on x86. */
+- if (IS_ENABLED(CONFIG_X86) && !((phys + size - 1) >> 20))
+- return __va(phys);
+- return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
+- ACPI_MAP_MEM_ATTR, VMAP_DEFAULT) + offs;
+- }
+- return __acpi_map_table(phys, size);
++ void *ptr;
++ mfn_t mfn = _mfn(PFN_DOWN(phys));
++ unsigned int offs = PAGE_OFFSET(phys);
++
++ /* Try the arch specific implementation first */
++ ptr = __acpi_map_table(phys, size);
++ if (ptr)
++ return ptr;
++
++ /* No common implementation for early boot map */
++ if (unlikely(system_state < SYS_STATE_boot))
++ return NULL;
++
++ ptr = __vmap(&mfn, PFN_UP(offs + size), 1, 1,
++ ACPI_MAP_MEM_ATTR, VMAP_DEFAULT);
++
++ return !ptr ? NULL : (ptr + offs);
+ }
+
+ void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
+ {
+- if (IS_ENABLED(CONFIG_X86) &&
+- (unsigned long)virt >= DIRECTMAP_VIRT_START &&
+- (unsigned long)virt < DIRECTMAP_VIRT_END) {
+- ASSERT(!((__pa(virt) + size - 1) >> 20));
++ if (__acpi_unmap_table(virt, size))
+ return;
+- }
+
+ if (system_state >= SYS_STATE_boot)
+ vunmap((void *)((unsigned long)virt & PAGE_MASK));
+diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
+index c945ab0..21d5e9f 100644
+--- a/xen/include/xen/acpi.h
++++ b/xen/include/xen/acpi.h
+@@ -68,6 +68,7 @@ typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, co
+
+ unsigned int acpi_get_processor_id (unsigned int cpu);
+ char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
++bool __acpi_unmap_table(const void *ptr, unsigned long size);
+ int acpi_boot_init (void);
+ int acpi_boot_table_init (void);
+ int acpi_numa_init (void);
diff -Nru xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
--- xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch 1969-12-31 19:00:00.000000000 -0500
+++ xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch 2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,131 @@
+From: Julien Grall <jgrall@amazon.com>
+Date: Sat, 26 Sep 2020 19:53:27 +0100
+Subject: xen/arm: acpi: The fixmap area should always be cleared during
+ failure/unmap
+
+Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
+{set, clear}_fixmap()" enforced that each set_fixmap() should be
+paired with a clear_fixmap(). Any failure to follow the model would
+result to a platform crash.
+
+Unfortunately, the use of fixmap in the ACPI code was overlooked as it
+is calling set_fixmap() but not clear_fixmap().
+
+The function __acpi_os_map_table() is reworked so:
+ - We know before the mapping whether the fixmap region is big
+ enough for the mapping.
+ - It will fail if the fixmap is already in use. This is not a
+ change of behavior but clarifying the current expectation to avoid
+ hitting a BUG().
+
+The function __acpi_os_unmap_table() will now call clear_fixmap().
+
+Reported-by: Wei Xu <xuwei5@hisilicon.com>
+Signed-off-by: Julien Grall <jgrall@amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
+(cherry picked from commit 4d625ff3c3a939dc270b03654337568c30c5ab6e)
+---
+ xen/arch/arm/acpi/lib.c | 73 +++++++++++++++++++++++++++++++++++++------------
+ 1 file changed, 56 insertions(+), 17 deletions(-)
+
+diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
+index fcc186b..a59cc40 100644
+--- a/xen/arch/arm/acpi/lib.c
++++ b/xen/arch/arm/acpi/lib.c
+@@ -25,40 +25,79 @@
+ #include <xen/init.h>
+ #include <xen/mm.h>
+
++static bool fixmap_inuse;
++
+ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ {
+- unsigned long base, offset, mapped_size;
+- int idx;
++ unsigned long base, offset;
++ mfn_t mfn;
++ unsigned int idx;
+
+ /* No arch specific implementation after early boot */
+ if ( system_state >= SYS_STATE_boot )
+ return NULL;
+
+ offset = phys & (PAGE_SIZE - 1);
+- mapped_size = PAGE_SIZE - offset;
+- set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
+- base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
++ base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) + offset;
++
++ /* Check the fixmap is big enough to map the region */
++ if ( (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - base) < size )
++ return NULL;
++
++ /* With the fixmap, we can only map one region at the time */
++ if ( fixmap_inuse )
++ return NULL;
+
+- /* Most cases can be covered by the below. */
++ fixmap_inuse = true;
++
++ size += offset;
++ mfn = maddr_to_mfn(phys);
+ idx = FIXMAP_ACPI_BEGIN;
+- while ( mapped_size < size )
+- {
+- if ( ++idx > FIXMAP_ACPI_END )
+- return NULL; /* cannot handle this */
+- phys += PAGE_SIZE;
+- set_fixmap(idx, maddr_to_mfn(phys), PAGE_HYPERVISOR);
+- mapped_size += PAGE_SIZE;
+- }
+
+- return ((char *) base + offset);
++ do {
++ set_fixmap(idx, mfn, PAGE_HYPERVISOR);
++ size -= min(size, (unsigned long)PAGE_SIZE);
++ mfn = mfn_add(mfn, 1);
++ idx++;
++ } while ( size > 0 );
++
++ return (char *)base;
+ }
+
+ bool __acpi_unmap_table(const void *ptr, unsigned long size)
+ {
+ vaddr_t vaddr = (vaddr_t)ptr;
++ unsigned int idx;
++
++ /* We are only handling fixmap address in the arch code */
++ if ( (vaddr < FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) ||
++ (vaddr >= (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)) )
++ return false;
++
++ /*
++ * __acpi_map_table() will always return a pointer in the first page
++ * for the ACPI fixmap region. The caller is expected to free with
++ * the same address.
++ */
++ ASSERT((vaddr & PAGE_MASK) == FIXMAP_ADDR(FIXMAP_ACPI_BEGIN));
++
++ /* The region allocated fit in the ACPI fixmap region. */
++ ASSERT(size < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - vaddr));
++ ASSERT(fixmap_inuse);
++
++ fixmap_inuse = false;
++
++ size += vaddr - FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
++ idx = FIXMAP_ACPI_BEGIN;
++
++ do
++ {
++ clear_fixmap(idx);
++ size -= min(size, (unsigned long)PAGE_SIZE);
++ idx++;
++ } while ( size > 0 );
+
+- return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
+- (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
++ return true;
+ }
+
+ /* True to indicate PSCI 0.2+ is implemented */
diff -Nru xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
--- xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch 1969-12-31 19:00:00.000000000 -0500
+++ xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch 2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,39 @@
+From: Julien Grall <jgrall@amazon.com>
+Date: Sat, 26 Sep 2020 21:16:55 +0100
+Subject: xen/arm: Check if the platform is not using ACPI before initializing
+ Dom0less
+
+Dom0less requires a device-tree. However, since commit 6e3e77120378
+"xen/arm: setup: Relocate the Device-Tree later on in the boot", the
+device-tree will not get unflatten when using ACPI.
+
+This will lead to a crash during boot.
+
+Given the complexity to setup dom0less with ACPI (for instance how to
+assign device?), we should skip any code related to Dom0less when using
+ACPI.
+
+Signed-off-by: Julien Grall <jgrall@amazon.com>
+Tested-by: Rahul Singh <rahul.singh@arm.com>
+Reviewed-by: Rahul Singh <rahul.singh@arm.com>
+Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
+Tested-by: Elliott Mitchell <ehem+xen@m5p.com>
+(cherry picked from commit dac867bf9adc1562a4cf9db5f89726597af13ef8)
+---
+ xen/arch/arm/setup.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
+index 34b1c1a..fb2f45e 100644
+--- a/xen/arch/arm/setup.c
++++ b/xen/arch/arm/setup.c
+@@ -961,7 +961,8 @@ void __init start_xen(unsigned long boot_phys_offset,
+ if ( construct_dom0(dom0) != 0)
+ panic("Could not set up DOM0 guest OS\n");
+
+- create_domUs();
++ if ( acpi_disabled )
++ create_domUs();
+
+ /*
+ * This needs to be called **before** heap_init_late() so modules
diff -Nru xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
--- xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch 1969-12-31 19:00:00.000000000 -0500
+++ xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch 2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,124 @@
+From: Julien Grall <jgrall@amazon.com>
+Date: Sat, 26 Sep 2020 21:30:14 +0100
+Subject: xen/arm: Introduce fw_unreserved_regions() and use it
+
+Since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree
+later on in the boot", the device-tree will not be kept mapped when
+using ACPI.
+
+However, a few places are calling dt_unreserved_regions() which expects
+a valid DT. This will lead to a crash.
+
+As the DT should not be used for ACPI (other than for detecting the
+modules), a new function fw_unreserved_regions() is introduced.
+
+It will behave the same way on DT system. On ACPI system, it will
+unreserve the whole region.
+
+Take the opportunity to clarify that bootinfo.reserved_mem is only used
+when booting using Device-Tree.
+
+Signed-off-by: Julien Grall <jgrall@amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
+(cherry picked from commit 9c2bc0f24b2ba7082df408b3c33ec9a86bf20cf0)
+---
+ xen/arch/arm/kernel.c | 2 +-
+ xen/arch/arm/setup.c | 22 +++++++++++++++++-----
+ xen/include/asm-arm/setup.h | 3 ++-
+ 3 files changed, 20 insertions(+), 7 deletions(-)
+
+diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
+index 8eff074..27dace0 100644
+--- a/xen/arch/arm/kernel.c
++++ b/xen/arch/arm/kernel.c
+@@ -307,7 +307,7 @@ static __init int kernel_decompress(struct bootmodule *mod)
+ * Free the original kernel, update the pointers to the
+ * decompressed kernel
+ */
+- dt_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
++ fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
+
+ return 0;
+ }
+diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
+index fb2f45e..c94827e 100644
+--- a/xen/arch/arm/setup.c
++++ b/xen/arch/arm/setup.c
+@@ -183,8 +183,9 @@ static void __init processor_id(void)
+ processor_setup();
+ }
+
+-void __init dt_unreserved_regions(paddr_t s, paddr_t e,
+- void (*cb)(paddr_t, paddr_t), int first)
++static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
++ void (*cb)(paddr_t, paddr_t),
++ int first)
+ {
+ int i, nr = fdt_num_mem_rsv(device_tree_flattened);
+
+@@ -231,6 +232,17 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
+ cb(s, e);
+ }
+
++void __init fw_unreserved_regions(paddr_t s, paddr_t e,
++ void (*cb)(paddr_t, paddr_t), int first)
++{
++ if ( acpi_disabled )
++ dt_unreserved_regions(s, e, cb, first);
++ else
++ cb(s, e);
++}
++
++
++
+ struct bootmodule __init *add_boot_module(bootmodule_kind kind,
+ paddr_t start, paddr_t size,
+ bool domU)
+@@ -392,7 +404,7 @@ void __init discard_initial_modules(void)
+ !mfn_valid(maddr_to_mfn(e)) )
+ continue;
+
+- dt_unreserved_regions(s, e, init_domheap_pages, 0);
++ fw_unreserved_regions(s, e, init_domheap_pages, 0);
+ }
+
+ mi->nr_mods = 0;
+@@ -699,7 +711,7 @@ static void __init setup_mm(void)
+ n = mfn_to_maddr(mfn_add(xenheap_mfn_start, xenheap_pages));
+ }
+
+- dt_unreserved_regions(s, e, init_boot_pages, 0);
++ fw_unreserved_regions(s, e, init_boot_pages, 0);
+
+ s = n;
+ }
+@@ -752,7 +764,7 @@ static void __init setup_mm(void)
+ if ( e > bank_end )
+ e = bank_end;
+
+- dt_unreserved_regions(s, e, init_boot_pages, 0);
++ fw_unreserved_regions(s, e, init_boot_pages, 0);
+ s = n;
+ }
+ }
+diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
+index 2f8f24e..28bf622 100644
+--- a/xen/include/asm-arm/setup.h
++++ b/xen/include/asm-arm/setup.h
+@@ -67,6 +67,7 @@ struct bootcmdlines {
+
+ struct bootinfo {
+ struct meminfo mem;
++ /* The reserved regions are only used when booting using Device-Tree */
+ struct meminfo reserved_mem;
+ struct bootmodules modules;
+ struct bootcmdlines cmdlines;
+@@ -96,7 +97,7 @@ int construct_dom0(struct domain *d);
+ void create_domUs(void);
+
+ void discard_initial_modules(void);
+-void dt_unreserved_regions(paddr_t s, paddr_t e,
++void fw_unreserved_regions(paddr_t s, paddr_t e,
+ void (*cb)(paddr_t, paddr_t), int first);
+
+ size_t boot_fdt_info(const void *fdt, paddr_t paddr);
diff -Nru xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
--- xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch 1969-12-31 19:00:00.000000000 -0500
+++ xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch 2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,60 @@
+From: Julien Grall <julien.grall@arm.com>
+Date: Wed, 30 Sep 2020 12:25:04 +0100
+Subject: xen/arm: acpi: add BAD_MADT_GICC_ENTRY() macro
+
+Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6:
+
+ The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
+ of the MADT. In the ACPI 5.1 version of the spec, the struct for the
+ GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
+ ACPI 6.0, the struct is 80 bytes long. But, there is only one definition
+ in ACPICA for this struct -- and that is the 6.0 version. Hence, when
+ BAD_MADT_ENTRY() compares the struct size to the length in the GICC
+ subtable, it fails if 5.1 structs are in use, and there are systems in
+ the wild that have them.
+
+ This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable
+ only, accounting for the difference in specification versions that are
+ possible. The BAD_MADT_ENTRY() will continue to work as is for all other
+ MADT subtables.
+
+ This code is being added to an arm64 header file since that is currently
+ the only architecture using the GICC subtable of the MADT. As a GIC is
+ specific to ARM, it is also unlikely the subtable will be used elsewhere.
+
+ Fixes: aeb823bbacc2 ("ACPICA: ACPI 6.0: Add changes for FADT table.")
+ Signed-off-by: Al Stone <al.stone@linaro.org>
+ Acked-by: Will Deacon <will.deacon@arm.com>
+ Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
+ [catalin.marinas@arm.com: extra brackets around macro arguments]
+ Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+
+Signed-off-by: Julien Grall <julien.grall@arm.com>
+Signed-off-by: Andre Przywara <andre.przywara@arm.com>
+Signed-off-by: Julien Grall <jgrall@amazon.com>
+Acked-by: Stefano Stabellini <sstabellini@kernel.org>
+Tested-by: Elliott Mitchell <ehem+xen@m5p.com>
+(cherry picked from commit 7056f2f89f03f2f804ac7e776c7b2b000cd716cd)
+---
+ xen/include/asm-arm/acpi.h | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
+index 5034028..b52ae2d 100644
+--- a/xen/include/asm-arm/acpi.h
++++ b/xen/include/asm-arm/acpi.h
+@@ -54,6 +54,14 @@ void acpi_smp_init_cpus(void);
+ */
+ paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index);
+
++/* Macros for consistency checks of the GICC subtable of MADT */
++#define ACPI_MADT_GICC_LENGTH \
++ (acpi_gbl_FADT.header.revision < 6 ? 76 : 80)
++
++#define BAD_MADT_GICC_ENTRY(entry, end) \
++ (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \
++ (entry)->header.length != ACPI_MADT_GICC_LENGTH)
++
+ #ifdef CONFIG_ACPI
+ extern bool acpi_disabled;
+ /* Basic configuration for ACPI */
diff -Nru xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
--- xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch 1969-12-31 19:00:00.000000000 -0500
+++ xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch 2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,29 @@
+From: Julien Grall <jgrall@amazon.com>
+Date: Thu, 5 Nov 2020 22:31:06 +0000
+Subject: xen/arm: traps: Don't panic when receiving an unknown debug trap
+
+Even if debug trap are only meant for debugging purpose, it is quite
+harsh to crash Xen if one of the trap sent by the guest is not handled.
+
+So switch from a panic() to a printk().
+
+Signed-off-by: Julien Grall <jgrall@amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
+(cherry picked from commit 957708c2d1ae25d7375abd5e5e70c3043d64f1f1)
+---
+ xen/arch/arm/traps.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
+index 2197df2..22bd1bd 100644
+--- a/xen/arch/arm/traps.c
++++ b/xen/arch/arm/traps.c
+@@ -1411,7 +1411,7 @@ static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
+ show_execution_state(regs);
+ break;
+ default:
+- panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
++ printk("DOM%d: Unhandled debug trap %#x\n", domid, code);
+ break;
+ }
+ }
diff -Nru xen-4.14.3/debian/patches/series xen-4.14.3/debian/patches/series
--- xen-4.14.3/debian/patches/series 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/series 2021-09-27 11:51:04.000000000 -0400
@@ -24,15 +24,15 @@
0024-tools-don-t-build-ship-xenmon.patch
0025-tools-Partially-revert-Cross-compilation-fixes.patch
0026-t-h-L-vif-common.sh-fix-handle_iptable-return-value.patch
-0027-xen-rpi4-implement-watchdog-based-reset.patch
-0028-tools-python-Pass-linker-to-Python-build-process.patch
-0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
-0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
-0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
-0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
-0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
-0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
-0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
+rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
+rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
+rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
+rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
+rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
+rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
+rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
+rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
+rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
0036-fix-spelling-errors.patch
0037-xen-don-t-have-timestamp-inserted-in-config.gz.patch
0038-x86-EFI-don-t-insert-timestamp-when-SOURCE_DATE_EPOC.patch
diff -Nru xen-4.14.3/debian/rules xen-4.14.3/debian/rules
--- xen-4.14.3/debian/rules 2021-07-10 08:01:39.000000000 -0400
+++ xen-4.14.3/debian/rules 2021-09-27 10:16:19.000000000 -0400
@@ -176,9 +176,13 @@
# /bin/sh: 1: Syntax error: Unterminated quoted string
# probably because the CFLAGS value contains multiple options and
# therefore spaces. See also the note by `undefine CFLAGS', above.
+# Also, restore the RPI4 patches if they were disabled in the last build
override_dh_auto_clean:
rm -f debian/xen-tools-built.stamp
$(MAKE) -j1 distclean
+ quilt pop 0026-t-h-L-vif-common.sh-fix-handle_iptable-return-value.patch \
+ && sed s/#rpi4/rpi4/ debian/patches/series > series.tmp \
+ && mv series.tmp debian/patches/series && quilt push -a
# To avoid that the build dirties the tree, our delta queue deletes
# config.sub and config.guess. dh_update_autotools_config can get
@@ -213,6 +217,7 @@
--enable-ovmf --with-system-ovmf=/usr/share/ovmf/OVMF.fd \
--with-system-seabios=/usr/share/seabios/bios-256k.bin
+# To fix #994899, we disable the patches that support the RPI4 on amd64|i386
# tools/firmware/xen-dir is the `shim' used for booting PV guests
# in an HVM container, for security (particularly, for meltdown/spectre
# mitigation). It's actually a hypervisor. On i386 it is not built
@@ -221,6 +226,12 @@
# build it with $(make_args_xen) not $(make_args_tools). So do it
# separately.
override_dh_auto_build:
+ case $(flavour) in \
+ amd64|i386) \
+ quilt pop 0026-t-h-L-vif-common.sh-fix-handle_iptable-return-value.patch \
+ && sed s/rpi4/#rpi4/ debian/patches/series > series.tmp && \
+ mv series.tmp debian/patches/series && quilt push -a ;; \
+ esac
$(MAKE) $(make_args_xen) xen
$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n
case $(flavour) in \
--- End Message ---