Re: [PATCH v3] aspeed: Add boot stub for smp booting

[Peter Maydell]

On Fri, 8 May 2020 at 15:27, Cédric Le Goater <address@hidden> wrote:
> Indeed, with OpenBMC kernel v5.4.32-260-g7dc9442bbe7d and wfi (patch v3),
>
>     [    0.045214] smp: Bringing up secondary CPUs ...
>     [    1.178127] CPU1: failed to come online
>     [    1.187309] smp: Brought up 1 node, 1 CPU
>     [    1.187590] SMP: Total of 1 processors activated (2250.00 BogoMIPS).
>     [    1.187786] CPU: All CPU(s) started in HYP mode.
>     [    1.187850] CPU: Virtualization extensions available.
>
> When using wfe (patch v2),
>
>     [    0.091092] smp: Bringing up secondary CPUs ...
>     [    0.096628] smp: Brought up 1 node, 2 CPUs
>     [    0.096718] SMP: Total of 2 processors activated (4500.00 BogoMIPS).
>     [    0.096768] CPU: All CPU(s) started in HYP mode.
>     [    0.096785] CPU: Virtualization extensions available.

OK, I've applied patch v2 to target-arm.next.

v3 looked a bit odd anyway -- a wfi-based secondary loop generally
needs to prod the GIC to enable interrupts for the core before
going into its loop (compare the 32-bit smpboot[] code in hw/arm/boot.c).
But looking at the code in the kernel's arch/arm/mach-aspeed/platsmp.c,
it uses dsb_sev() to prod the secondary core, so only wfe will
work here. If you find that you are often in situations where the
secondary cores are not started and so QEMU is wasting host CPU
in this busy-loop, you could look at implementing a non-noop
wfe/sev in QEMU, though it's not completely trivial because of
all the things other than sev that are 'wfe wake-up events'.

thanks
-- PMM