On Fri, 8 May 2020 at 15:27, Cédric Le Goater <c...@kaod.org> 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
