On 26/04/2022 15:33, David Vrabel wrote:
>
>
> 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.
It is. Username?
~Andrew
