On Wed, 31 May 2017 19:40:46 +0200 Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote:
> 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. > I tend to agree indeed. It isn't a problem for user mode though since it doesn't use @host_tid. Only gdbstub does. $ git grep host_tid include/exec/gdbstub.h: return cpu->host_tid; include/qom/cpu.h: * @host_tid: Host thread ID. include/qom/cpu.h: uint32_t host_tid; linux-user/syscall.c: cpu->host_tid = info->tid; > 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. > I'm not familiar enough with gdbstub to know if this is a real problem. But I guess it is possible to add a "first_cpu->host_tid = gettid();" line somewhere in linux-user/main.c.
pgp1FkWyjw940.pgp
Description: OpenPGP digital signature