Re: [PATCH 00/19] arm64: Implement parallel CPU onlining with PSCI v0.2+

[David Woodhouse]

On Fri, 2026-10-09 at 17:04 +0100, David Woodhouse wrote
> And while spinwait alone is a modest win, it doesn't buy us anything on
> top of parallel bringup on *this* hardware. In fact it's *slightly*
> slower on the biggest hardware, because I haven't yet batched some of
> the flushes properly. I'll look at that, and rerun on the machines with
> slow CPU_ON which is where the spinwait will come into its own.

Retested there. For the CPU onlining:

Upstream: 820ms
Parallel: 800ms
Spinwait: 35-40ms

So I think we definitely need both.

A trivial spinwait with MMU *off* also causes the BSP to spend an extra
200ms in paging_init() on this hardware. And we want the MMU on for all
the interesting caretaker use cases anyway, so I'll do that.

We *already* wanted exception handling in arm64_relocate_new_kernel()
before any of this. So I'll do that first, as I did for x86 in
https://lore.kernel.org/all/20250314173226.3062535-1-dwmw2@xxxxxxxxxxxxx/

Shape of the upcoming series:

 • Exception handling and serial print
 • Simple handover to spinwaiter, and handback protocol
 • More complex handover to caretaker workloads (like my proof of
   concept e1000 ping responder, which is now working)

... and then it devolves into Pasha's caretaker series.

I'll give some thought to whether the spinwait should be a LUO thing,
gated on the incoming kernel advertising *support* for such, using the
feature negotiation we talked about at LPC. I'll probably start with
punting the decision to userspace for now.

Attachment: smime.p7s
Description: S/MIME cryptographic signature