identifying cpus (and smt threads)

[Joel Schopp]

> Each device_tree node of type cpu represents a physical processor/cpu
> For each valid processor identified by the firmware (obtained from looking at
> the 'status' property of the device_tree cpu node)
> 	Get the 'reg' property that represents the physical cpu id
> 	Get the 'interrupt-server#s' property that is supposed to represent
> something about the smt threads, if supported
> 	(what does this property actually mean? On my Power4 test machine, p630,
> I found this property seems to be the same as the 'reg' property in the open
> firmware prompt. Does it give the individual thread ids, if SMT is supported?).
> I tried to find concrete information about this property in documents, but
> failed to get it.

The document you are looking for is the RPA.  The interrupt-server#s
does give the id for each thread.  For single threaded systems (Power 4
and earlier) the reg and interrupt-server#s are the same.  For SMT
systems reg is the same as the first entry in interrupt-server#s.

> 	Based on the propsize returned from the getprop for the property
> ibm,interrupt-server#s', the number of threads (CPU_MAX_THREADS is anyways 2) is
> obtained.
> 	The code then differentiates between the primary thread of boot cpu and
> non-boot cpu.
> 	If primary thread of boot cpu, then set the cpuid in all the 4 cpumasks.
> 	If primary thread of non-boot cpu, then make them spin on secondary-hold
> and when they are out, set the cpuid in the cpu_avaiable_map, cpu_possible_map
> and cpu_present_at_boot. But they are not set in the cpu_online_map. Why is
> that? Aren't they online if they have come out of the secondary_hold spinloop?

Some cpus may be visible that are not assigned to the partition in a
LPAR system.  They may be in use by another partition or be otherwise
utilized.  These cannot be brought online at this point.

> 	Then the secondary threads cpuids are set in the cpu_available_map and
> cpu_present_at_boot map.
> 	Later, in setup_system, the secondary threads are started through the
> rtas-call 'start-cpu' if they are already in the cpu_available_map but not on
> the cpu_possible_map.
>
> A few questions here:
> - why is there a cpu_present_at_boot map? It seems to be the same as the
> cpu_available_map. Or did I miss something?

It is largely historical.  However, it is very possible to add cpus to
the available map that were not present at boot.  This is the case on
Power5 with shared processor enabled for instance.

> - second, I want to move the cpuset() calls for setting the cpumasks from the
> prom_hold_cpus code to setup_system. However, I see that only the primary thread
> of boot cpu is set in the cpu_online_map, and the primary threads of non-boot
> cpus are not set in the cpu_online_map.
> - When do the other primary threads of the non-boot cpus get set in the
> online_map? Can I assume that they will all be up by the time setup_system is
> executed and set all the primary threads in the cpu_online_map? If not, how can
> I differentiate between the primary threads of the boot and non-boot cpus?

Not sure exactly what you mean by this.  But I assume you are talking
about cpu hotplug (ie cpu DLPAR) events which can bring cpus online at
any time after boot when a customer asks it to.


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/