arm64 spin-table cpu-return-addr

arm64 spin-table cpu-return-addr

[Geoff Levand]

Hi Mark,

Regarding adding a cpu-return-addr property to the spin-table
cpu enable method for arm64, we need to decide how to handle
a difference in endian mode between the kernel and the
spin-table code.

Will the spin-table code always be built as little endian?  If
so, then either the kernel or the spin code could handle this
difference, and we need to decide which will do it.  If not,
then the only way is for the spin code to do it as the kernel
has no way to tell endian mode of the spin code, unless to test
and save how it was entered at startup.

Let me know your thoughts.

-Geoff

arm64 spin-table cpu-return-addr

[Mark Rutland]

On Sat, Aug 09, 2014 at 01:30:00AM +0100, Geoff Levand wrote:
> Hi Mark,

Hi Geoff,

> Regarding adding a cpu-return-addr property to the spin-table
> cpu enable method for arm64, we need to decide how to handle
> a difference in endian mode between the kernel and the
> spin-table code.
> 
> Will the spin-table code always be built as little endian?  If
> so, then either the kernel or the spin code could handle this
> difference, and we need to decide which will do it.  If not,
> then the only way is for the spin code to do it as the kernel
> has no way to tell endian mode of the spin code, unless to test
> and save how it was entered at startup.

A spin-table implementation could be either endianness as it's possible
to build BE-only or LE-only systems.

There are several other bits of CPU state a spin-table implementation
might care about, so ideally the spin-table implementation would put the
CPU through reset to restore everything to a suitable state.

Depending on the platform and what the rest of the spin-table
implementation looks like, the return code in the spin-table could be as
simple as:

return_addr:
	msr	daifset, 0xf	/* Mask everything, just in case */
	mov	x0, 0x1		/* Cold reset, A64 */
	msr	rmr_el2, x0	/* If EL2 is highest EL implemented */
	isb
1:	wfi			/* Wait for reset */
	b	1b

That would depend on any IMPLEMENTATION DEFINED work you might have to
do, where rvbar_el2 points, and so on.

>From the kernel side I expect we'd try to meet the same requirements as
we expect of the firmware at boot time:
- MMU off
- D-cache clean
- I-cache on or off
- PSTATE.DAIF masked
- Everything else unknown

Does that sound sane to you?

Thanks,
Mark.