[U-Boot] ARMv8 spin-table patches

[Scott Wood]

On Fri, 2014-07-04 at 10:29 +0100, Mark Rutland wrote:
> Hi,
> 
> Apologies for the late reply.
> 
> On Fri, Jun 27, 2014 at 05:44:05PM +0100, Tom Rini wrote:
> > On Fri, Jun 27, 2014 at 09:11:39AM -0700, York Sun wrote:
> > 
> > > Dear Albert, Wolfgang, Tom,
> > > 
> > > I have seen some patches for PSCI. We don't have PSCI enabled on
> > > Freescale ARMv8 SoCs. Will spin-table patches be acceptable?
> > 
> > Baring some technical reasons why no, you can't do that, yes, lets see
> > the patches :)
> 
> I'd point out that it's decidedly sub-optimal as spin-table provides no
> provision for CPU hotplug (which for Linux will affect kexec and other
> features relying on CPU hotplug support).

I don't think we're ruling PSCI out entirely, but we don't have it yet
and it's not imminent.  Currently we don't have any firmware that stays
resident after Linux takes over (the tiny spin table code is not
comparable to something that needs to be able to provide runtime
services to a core that has already run OS code).

> Additionally, spin-table has the unfortunate property of allowing the
> firmware to throw an unbound number of CPUs into the kernel at once
> (when they share a cpu-release-addr), where they can spend a lot of time
> spinning pointlessly (executing kernel code from memory and possibly
> fetching it into I-caches) depending on the number of events a CPU
> happens to generate at runtime.

Why do some ARM implementations of the spin table use the same address
for all CPUs?  It looks like ARM's use of the spin table was patterned
after what we do on PPC (Documentation/devicetree/bindings/arm/cpus.txt
even claims to follow ePAPR v1.1), but PPC always had a separate release
address for each CPU, plus the ability to set a register to give the CPU
some context after spinning up.

-Scott