On 26/04/2022 15:14, Julien Grall wrote:
Hi,
On 26/04/2022 15:01, Jan Beulich wrote:
On 25.04.2022 15:28, David Vrabel wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -162,6 +162,13 @@
static char __initdata opt_badpage[100] = "";
string_param("badpage", opt_badpage);
+/*
+ * Heap allocations may need TLB flushes which require IRQs to be
+ * enabled (except when only 1 PCPU is online).
+ */
+#define ASSERT_ALLOC_CONTEXT() \
+ ASSERT(!in_irq() && (local_irq_is_enabled() || num_online_cpus()
<= 1))
At least one of these tightened assertions triggers on Arm, as per the
most recent smoke flight. I'm going to revert this for the time being.
From the serial console [1]:
(XEN) Xen call trace:
(XEN) [<0022a510>] alloc_xenheap_pages+0x120/0x150 (PC)
(XEN) [<00000000>] 00000000 (LR)
(XEN) [<002736ac>] arch/arm/mm.c#xen_pt_update+0x144/0x6e4
(XEN) [<002740d4>] map_pages_to_xen+0x10/0x20
(XEN) [<00236864>] __vmap+0x400/0x4a4
(XEN) [<0026aee8>]
arch/arm/alternative.c#__apply_alternatives_multi_stop+0x144/0x1ec
(XEN) [<0022fe40>] stop_machine_run+0x23c/0x300
An allocation inside a stop_machine_run() action function. That is what
the asserts were designed to catch.
I did try the run the GitLab CI pipelines but it is setup to use runners
that are only available to the Xen Project group, so forking the repo
doesn't work.
Can my (personal) GitLab be added as a Developer to the Xen Project
group? I think this is the intended way for people to run the CI
pipelines on their own branches.
David
