xen/arm: smpboot: Allocate the CPU sibling/core maps while preparing the CPU
Commit
5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
xmalloc()" extended the checks in _xmalloc() to catch any use of the
helpers from context with interrupts disabled.
Unfortunately, the rule is not followed when allocating the CPU
sibling/core maps.
(XEN) Xen call trace:
(XEN) [<
00238a5c>] _xmalloc+0xfc/0x314 (PC)
(XEN) [<
00000000>]
00000000 (LR)
(XEN) [<
00238c8c>] _xzalloc+0x18/0x4c
(XEN) [<
00288cb4>] smpboot.c#setup_cpu_sibling_map+0x38/0x138
(XEN) [<
00289024>] start_secondary+0x1b4/0x270
(XEN) [<
40010170>]
40010170
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 2:
(XEN) Assertion '!in_irq() && (local_irq_is_enabled() || num_online_cpus() <= 1)' failed at common/xmalloc_tlsf.c:601
(XEN) ****************************************
This is happening because zalloc_cpumask_var() may allocate memory
if NR_CPUS is > 2 * sizeof(unsigned long).
Avoid the problem by allocating the CPU sibling/core maps while
preparing the CPU.
This also has the benefit to remove a panic() in the secondary CPU
code.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Michal Orzel <michal.orzel@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>