Review request: sparse CPU ID maps

[Andrew Turner]

On Sat, 2 Jul 2016 17:08:54 -0700
Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:

> A reasonable first pass at checking for this kind of bug is doing
> grep -lR '< mp_ncpus'. Running that on sys/arm and sys/arm64 shows
> the following files:
> arm/mv/armadaxp/armadaxp_mp.c
> arm/include/counter.h
> arm/broadcom/bcm2835/bcm2836.c
> arm/broadcom/bcm2835/bcm2836_mp.c
> arm/freescale/imx/imx6_mp.c
> arm/allwinner/aw_mp.c
> arm/rockchip/rk30xx_mp.c
> arm/amlogic/aml8726/aml8726_mp.c
> arm/samsung/exynos/exynos5_mp.c
> arm/arm/mp_machdep.c
> arm/nvidia/tegra124/tegra124_mp.c

I'm planning forcing people to clean up the arm code in 12. I can add
this to the list of things that need to be fixed.

> arm64/include/counter.h
> arm64/arm64/gic_v3.c
> arm64/arm64/gic_v3_its.c
> arm64/arm64/gicv3_its.c

I'll look at these in a few days when the code freeze is lifted.

> 
> All of them should, in some sense, be CPU_FOREACH(), but it may not 
> matter. For example, it may not be possible to have sparse CPU IDs on 
> some or all of those SOCs. At least the generic ones (counter, 
> mp_machdep.c, gic (why are there both gic_v3_its.c and gicv3_its.c?)) 
> should be changed, I think.

On arm it depends on the SoC. As far as I know no arm SoCs support
sparse CPU IDs as they assign the ID based on the internal ID and, on a
single cluster of CPUS, this seems to be contiguous. To boot on all
CPUs on a multi-cluster SoC (e.g. big.LITTLE) we would need to
rework the assignment of cpuids. As such I would expect us to keep
a contiguous space.

The place I would expect us to get a non-contiguous range on arm is if
we grew support to offline CPUs. I think this will be needed on a few
SoCs if we wish to run on many of the mobile chips. This may be needed
for thermal and power reasons as many are only able to run for a short
length of time before thermal throttling.

On arm64 I'm planning on reworking the cpuid allocation code such that
we may get sparse values, however I don't expect to have time for this
in the next few months.

Andrew