On Mon, Dec 03, 2018 at 03:09:14PM +0100, Luc Michel wrote: > > > On 12/3/18 12:23 PM, Peter Maydell wrote: > > On Mon, 3 Dec 2018 at 11:21, Luc Michel <luc.mic...@greensocs.com> wrote: > >> > >> On 11/30/18 5:52 PM, Peter Maydell wrote: > >>> Luc: what are the requirements on boards using CPU cluster > >>> objects? I assume these are both OK: > >>> * does not use cluster objects at all > >>> (the gdbstub puts all the CPUs in one process?) > >> Yes, when no clusters are found, a process with PID 1 is created and > >> used for all CPUs. > >>> * all CPUs created are in some CPU cluster > >>> (the gdbstub uses one process per CPU cluster) > >>> but what about > >>> * some CPUs are created in a CPU cluster, but some > >>> are "loose", not in any cluster at all> ? > >>> Is that just invalid, or do the "loose" CPUs end up in > >>> a default cluster (gdbstub process), or do they get > >>> one cluster each? > >> Currently this is valid and the "loose" CPUs end up in the first > >> available process (which will be PID 1 if we are in your first case, > >> i.e. no clusters in the machine). > > > > So if there are some defined clusters 1 and 2, and some > > loose CPUs, the clusters get PID 1 and PID 2, and the > > loose CPUs end up in PID 3? That seems reasonable. > No sorry I was not clear, the loose CPUs would end up on PID 1 in that case. > > The current behaviour is as follows: > During gdb stub initialization: > - A process is created per cluster. > - If no cluster are found, an unique process is created with PID 1 > > When trying to find a CPU PID: > - If it is attached to a cluster, return the associated process, > - If it is loose, return the first available process.
The behavior described by Peter would be more reasonable to me. Otherwise what was just an accident (getting the CPU assigned to the first process) will become expected behavior of the API, and it will be hard to change it later. In either case, I'm still missing a clear description of what a cluster is supposed to represent, exactly (see my previous reply on this thread). -- Eduardo
