Some questions have come up recently regarding how
CPUs and hardware threads are represented in device
trees. This has come up in the context of the embedded
hypervisor committee in power.org working on some
interrupt controller APIs, but is really a general
issue. We had some side discussions with Ben and
Kumar and think we have an approach that addresses
the issue.
There is no standard binding for how hardware
threads (which in most cases share an MMU)
are represented in device trees.
The IBM SPAPR uses the "ibm,ppc-interrupt-server#s"
property, which is an array with 1 element per
thread. The number is used in addressing by the
interrupt controller.
The question of how/if a CPU/thread's PIR value
is represented is relevant. Some CPUs have
an unmodifiable PIR number space that is
distinct from the number space addressed from
the interrupt controller.
The proposal below outlines a general approach.
If there is consensus, this would eventually get
written up in a more formal form and added to the
ePAPR.
Regards,
Stuart Yoder
=============================================================
-CPUs and threads are numbered through a unified number-space
that should match as closely as possible the interrupt
controller's numbering of CPUs/threads
-What goes under a CPU node?
-generally, a CPU node represents a hardware
execution block that is sufficiently independent
that it is capable of running an
operating system without interferring with
other CPUs possibly running other operating
systems.
-threads that share an MMU would generally be
represented under 1 CPU node
-If other more complex CPU topographies
are designed the CPU binding must describe the
topography (e.g. threads that don't share
an MMU).
-If a CPU/thread can be the target of an external
interrupt the "reg" property value must contain a
unique CPU/thread id that is addressable by the
interrupt controller
-If a CPU/thread cannot be the target of an external
interrupt, then "reg" must be unique and out of bounds
of the range addressed by the interrupt controller
-If a CPU supports more than one thread (i.e. multiple
streams of execution) the "reg" property is an array with 1
element per thread
-The #address-cells property on the "cpus" container specifies
how many cells each element of the "reg" property array
takes
-Software can determine the number of threads by dividing
the size of "reg" by "#address-cells"
-If a CPU/thread's PIR is modifiable it should be modified
to match the "reg" property value. If PIR cannot be
modified and the PIR value is distinct from the interrupt
controller numberspace, the CPUs binding may define a
binding-specific representation of PIR values if desired.
-Regarding a standardized way to start secondary threads--
-The current spin table mechanism is not thread safe and
is insufficient for starting threads.
-Given the variety of implementations in IBM and
Freescale roadmaps, it is highly questionable whether a
commond thread release mechanism can be defined for all
threaded CPUs and specific release methods for different
processors most likely needs to be created
=============================================================
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
