On Wed, 31 May 2017 19:06:29 +0200 Greg Kurz <gr...@kaod.org> wrote: > On Wed, 31 May 2017 18:51:06 +0200 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > [...] > > > > > > > > This is strange. cpu_index() is defined as: > > > > > > > > static inline int cpu_index(CPUState *cpu) > > > > { > > > > #if defined(CONFIG_USER_ONLY) > > > > return cpu->host_tid; > > > > #else > > > > return cpu->cpu_index + 1; > > > > #endif > > > > } > > > > > > > > therefore it shouldn't return 0 under any circumstance, > > > > and > > > > > > I think it is 0 for first_cpu in user mode. > > > > in linux-user/syscall.c: > > > > info->tid = gettid(); > > cpu->host_tid = info->tid; > > > > kernel thread-ids are system-wide unique and can't be 0 > > > > This is correct but these lines are in clone_func(). This gets called > for all threads but the "main" thread which I believe to be > associated to first_cpu.
then IMHO that is a bug and it needs to be corrected. the host_tid should be, well, the host tid, and not 0, which is never a valid tid for Linux. the current behaviour is simply the easiest for the "any CPU" case. Picking the last CPU or a random one would still be correct, and in that case there would be no way to explicitly address the first CPU.